Домашний кластер из микрокомпьютеров: собираем и находим применение

Когда у тебя в ящике стола копится третья Raspberry Pi, а Orange Pi PC пылится после прошлого проекта, рано или поздно приходит мысль: «А не собрать ли из них кластер?» В этой статье я расскажу, зачем вообще домашнему мастеру кластер из одноплатников, как его правильно собрать и настроить, и — самое главное — какие реальные задачи он может решать в 2026 году.

Зачем вообще нужен домашний кластер?

Давай сразу честно: кластер из Raspberry Pi не заменит тебе облачный сервер или мощный домашний ПК. Он не будет быстрее в разы, и уж точно не стоит собирать его ради «настоящего суперкомпьютера». Но есть задачи, где распределённая система из нескольких плат действительно имеет смысл.

Отказоустойчивость умного дома

Представь: у тебя Home Assistant установлен на одной Orange Pi Zero 3. Плата перегрелась, SD-карта умерла, или ты случайно снёс конфиг — и весь умный дом встал. Свет ещё можно включить выключателем, но автоматизации, сценарии и удалённый доступ — всё лежит.

Кластер решает эту проблему иначе, чем простой бэкап. Вместо одного «монолита» ты получаешь несколько узлов, каждый из которых отвечает за свою часть. Один узел крутит Home Assistant, второй — Zigbee-координатор и MQTT-брокер, третий — базу данных InfluxDB и Grafana. Если один узел падает, остальные продолжают работать, а сервис можно быстро поднять на соседней плате.

Песочница для экспериментов

Кластер — это идеальная площадка для изучения Kubernetes, Docker Swarm или хотя бы Ansible. Вместо того чтобы пробовать на рабочем сервере или основной системе умного дома, ты можешь развернуть что угодно на отдельном узле. Сломал — переустановил систему за 20 минут, и никто не пострадал.

Распределённые сервисы

Некоторые задачи просто удобнее разносить по разным машинам:

• Pi-hole для блокировки рекламы на всю сеть;
• WireGuard VPN для доступа домой;
• Jellyfin для медиатеки;
• Nextcloud для файлов;
• Node-RED для автоматизаций.

Всё это может жить на одном мощном одноплатнике, но когда сервисов становится много, они начинают мешать друг другу. Один жрёт всю память, другой — диск, третий — процессор. Кластер позволяет разнести нагрузки и не бояться, что один зависший контейнер уронит весь дом.

Что нам понадобится?

Для кластера подойдут практически любые одноплатники, но есть нюансы.

Выбор плат

Лучше всего использовать одинаковые платы — так проще с образами и управлением. Но если у тебя уже есть разношёрстный зоопарк, это тоже работает. Главное — чтобы все платы были на одной архитектуре (ARM64) и поддерживали загрузку с USB или SSD.

Вот несколько популярных вариантов:

• Raspberry Pi 4 или 5 — классика. Хорошая поддержка, много документации. Pi 5 заметно мощнее, но и горячее — понадобится охлаждение.
• Orange Pi 5B — отличный вариант со встроенным eMMC. Не нужна SD-карта, что сразу повышает надёжность.
• Rock Pi 4B+ — хорош для медиа-задач.
• NanoPi R2S — если нужен компактный узел для сетевых задач.

Если планируешь использовать кластер для умного дома, обрати внимание на статьи про установку Home Assistant на Orange Pi Zero 3 и сравнение ESP32-P4 и ESP32-S3 — там есть полезные мысли о выборе железа под конкретные задачи.

Сетевое оборудование

Тебе понадобится:

• Gigabit Ethernet-коммутатор — обязателен. Без гигабита кластер будет работать заметно медленнее, особенно при передаче данных между узлами.
• Кабели — лучше короткие патч-корды, чтобы не разводить паутину.
• Блок питания — каждый одноплатник требует качественного питания. Не экономь: дешёвый блок питания — частая причина «магических» перезагрузок.

Хранение данных

Для кластера критически важно, чтобы узлы не зависели от SD-карт. SD-карта — это самое ненадёжное место в одноплатнике. Если есть возможность, загружайся с USB-накопителя или eMMC. Подробнее о подключении дисков к одноплатникам можно почитать в статье «Как подключить HDD или SSD к одноплатнику на Armbian или Debian».

Для кластера хорошо иметь:

• Общий NAS или сетевую шару для бэкапов и обмена файлами.
• SSD хотя бы на одном узле для баз данных.

Собираем кластер: пошаговый план

Шаг 1. Подготовка узлов

Начнём с установки операционной системы. Я рекомендую Armbian или Raspberry Pi OS Lite — обе без графической оболочки, что экономит ресурсы.

Для Raspberry Pi:

# Скачиваем Raspberry Pi OS Lite
wget https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_arm64-2024-11-19/2024-11-19-raspios-bookworm-arm64-lite.img.xz
xz -d 2024-11-19-raspios-bookworm-arm64-lite.img.xz
# Записываем на SD-карту или USB
sudo dd if=2024-11-19-raspios-bookworm-arm64-lite.img of=/dev/sdX bs=4M status=progress

Для остальных плат — Armbian:

# Скачиваем образ для конкретной платы с официального сайта
# Затем записываем
sudo dd if=Armbian_24.11.1_Orangepi5b_bookworm_current_6.12.1.img of=/dev/sdX bs=4M status=progress

После записи образа обязательно включи SSH. Для Raspberry Pi создай пустой файл ssh в корне загрузочного раздела:

touch /media/$USER/boot/ssh

Для Armbian SSH включён по умолчанию, но нужно задать пароль при первой загрузке.

Шаг 2. Настройка сети

Присвой каждому узлу статический IP-адрес. Это критически важно для кластера — динамические адреса превратят жизнь в ад.

Отредактируй /etc/dhcpcd.conf на Raspberry Pi OS:

sudo nano /etc/dhcpcd.conf

Добавь в конец:

interface eth0
static ip_address=192.168.1.101/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1 1.1.1.1

Для Armbian — /etc/network/interfaces:

sudo nano /etc/network/interfaces

auto eth0
iface eth0 inet static
    address 192.168.1.101
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1 1.1.1.1

Дальше — перезагрузка сети:

sudo systemctl restart networking
# Или
sudo reboot

Шаг 3. Базовые настройки

Обнови систему и установи базовые пакеты на каждом узле:

sudo apt update && sudo apt upgrade -y
sudo apt install -y htop tmux git curl wget

Настрой hostname — так будет проще ориентироваться:

sudo hostnamectl set-hostname node1

Добавь записи в /etc/hosts на каждом узле:

192.168.1.101 node1
192.168.1.102 node2
192.168.1.103 node3

Шаг 4. Настройка SSH-доступа

Сгенерируй SSH-ключ на управляющем узле (или на своём компьютере) и скопируй его на все остальные:

ssh-keygen -t ed25519 -C "cluster@home"
ssh-copy-id user@node1
ssh-copy-id user@node2
ssh-copy-id user@node3

Теперь можно заходить на любой узел без пароля.

Шаг 5. Установка Docker

Docker — основа большинства кластерных решений. Установи его на всех узлах:

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER

Проверь установку:

docker --version
docker run hello-world

Шаг 6. Инициализация кластера

Есть два основных пути: Docker Swarm и Kubernetes (k3s). Для домашнего использования я рекомендую начать с Docker Swarm — он проще и требует меньше ресурсов.

Инициализация на управляющем узле:

docker swarm init --advertise-addr 192.168.1.101

Ты получишь команду для подключения остальных узлов — что-то вроде:

docker swarm join --token SWMTKN-1-xxxxx 192.168.1.101:2377

Выполни её на остальных узлах. Проверка:

docker node ls

Если всё сделано правильно, ты увидишь список узлов с ролью leader и worker.

Три практических сценария использования

Теперь самое интересное — что именно запускать на кластере. Я предлагаю три сценария, которые покрывают большинство реальных потребностей домашнего мастера.

Сценарий 1: Умный дом с отказоустойчивостью

Распределим сервисы умного дома по трём узлам:

• node1 — Home Assistant + Node-RED;
• node2 — Zigbee2MQTT + Mosquitto (MQTT-брокер);
• node3 — InfluxDB + Grafana + резервный Home Assistant.

Для Home Assistant создай docker-compose.yml:

version: '3.8'

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    restart: unless-stopped
    network_mode: host
    privileged: true
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
    environment:
      - TZ=Europe/Moscow

Запуск:

docker compose up -d

Для Zigbee2MQTT — свой compose-файл на node2:

version: '3.8'

services:
  zigbee2mqtt:
    image: koenkk/zigbee2mqtt:latest
    container_name: zigbee2mqtt
    restart: unless-stopped
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    volumes:
      - ./dаta:/app/data
    environment:
      - TZ=Europe/Moscow

Не забудь указать в configuration.yaml Zigbee2MQTT адрес MQTT-брокера:

mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://192.168.1.102:1883

Если у тебя несколько Zigbee-координаторов, почитай статью «Второй координатор Zigbee2MQTT: зачем нужен и как настроить» — это может быть полезно для больших домов.

Сценарий 2: Веб-сервер с Nginx Proxy Manager

Кластер отлично подходит для хостинга личных веб-проектов. Развернём Nginx Proxy Manager на одном узле, а бэкенд-сервисы — на других.

Настройка Nginx Proxy Manager подробно описана в статье «Nginx Proxy Manager: установка и первоначальная настройка reverse proxy с HTTPS в Docker», здесь я покажу, как вписать его в кластер.

Создай docker-compose.yml на node1:

version: '3.8'

services:
  nginx-proxy-manager:
    image: jc21/nginx-proxy-manager:latest
    container_name: npm
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    volumes:
      - ./dаta:/data
      - ./letsencrypt:/etc/letsencrypt

Теперь на node2 можно поднять, например, Nextcloud:

version: '3.8'

services:
  nextcloud:
    image: nextcloud:stable
    container_name: nextcloud
    restart: unless-stopped
    ports:
      - '8080:80'
    volumes:
      - ./html:/var/www/html
      - ./dаta:/var/www/html/data
    environment:
      - MYSQL_HOST=db
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=secret

В веб-интерфейсе Nginx Proxy Manager (порт 81) создай proxy host, указав node2:8080 как адрес бэкенда. NPM сам выпустит SSL-сертификат через Let's Encrypt.

Сценарий 3: VLESS-шлюз между локациями

Это более продвинутый сценарий. Представь: у тебя есть сервер в другой локации (например, у родственников или на арендованном VPS), и ты хочешь объединить его с домашней сетью.

VLESS — это протокол, который часто используется для создания туннелей между серверами. Подробнее о теории можно почитать в статье «VLESS как туннель между вашими проектами: теория и настройка».

На одном из узлов кластера поднимем VLESS-сервер:

mkdir -p ~/vless && cd ~/vless
nano docker-compose.yml

version: '3.8'

services:
  xray:
    image: teddysun/xray:latest
    container_name: xray
    restart: unless-stopped
    ports:
      - '443:443'
    volumes:
      - ./config.json:/etc/xray/config.json

Конфиг config.json:

{
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "UUID-ЗДЕСЬ",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "dest": "www.google.com:443",
          "serverNames": ["www.google.com"],
          "privateKey": "ТВОЙ_PRIVATE_KEY",
          "shortIds": ["abcdef"]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

Сгенерируй ключи:

# Установи xray-utils
sudo apt install -y xray-utils
# Или используй docker
docker run --rm teddysun/xray xray x25519

UUID можно сгенерировать командой:

cat /proc/sys/kernel/random/uuid

Запусти контейнер:

docker compose up -d

Теперь с другого узла кластера (или с внешнего сервера) можно подключиться к этому VLESS-серверу и маршрутизировать трафик через него. Это удобно, когда нужно получить доступ к домашней сети извне или объединить несколько локаций в единую сеть.

Типичные ошибки и как их избежать

Ошибка 1: Экономия на блоке питания

Одноплатники чувствительны к качеству питания. Если блок питания выдаёт меньше ампер, чем нужно, или «проседает» под нагрузкой, плата будет перезагружаться. Это особенно критично в кластере, где все узлы работают одновременно.

Решение: используй качественные блоки питания с запасом по току. Для Raspberry Pi 4 — 5V/3A, для Pi 5 — 5V/5A (официальный блок питания обязателен). Для остальных плат — смотри спецификацию.

Ошибка 2: Перегрев

В кластере платы стоят плотно друг к другу, и теплоотвод ухудшается. Перегрев приводит к троттлингу (снижению частоты) и нестабильной работе.

Решение: обеспечь вентиляцию. Если платы стоят в стойке или корпусе, добавь вентилятор. Для Raspberry Pi 5 радиатор и вентилятор — обязательны. Подробнее — в статье «Охлаждение одноплатников: от пассивного радиатора до активного обдува».

Ошибка 3: Использование SD-карт

SD-карты умирают от постоянной записи. В кластере, где крутятся базы данных и логи, это происходит особенно быстро.

Решение: загружайся с USB-накопителя или eMMC. Если другого выхода нет — используй SD-карты высокого качества (Samsung EVO Plus, SanDisk Extreme) и настрой логирование в RAM. Полезные советы есть в статье «Продлеваем жизнь SD-карте в Raspberry Pi».

Ошибка 4: Забыл про бэкапы

Кластер — это не панацея от потери данных. Если у тебя упал узел с InfluxDB, а бэкапов нет — данные пропали.

Решение: настрой автоматический бэкап конфигов и баз данных на отдельный узел или NAS. Для Home Assistant есть готовые решения — о них можно почитать в статье «Home Assistant: надёжный бэкап и восстановление».

Проверка результата

После сборки кластера проверь, что всё работает:

1. Проверь узлы:

docker node ls

2. Проверь, что сервисы запущены:

docker service ls

3. Проверь доступность сервисов извне:

curl -I http://192.168.1.101:8123  # Home Assistant
curl -I http://192.168.1.101:81    # Nginx Proxy Manager

4. Проверь нагрузку на узлы:

ssh user@node1 'htop'
ssh user@node2 'htop'

Заключение

Домашний кластер из микрокомпьютеров — это не просто игрушка для гиков. Это практичный инструмент, который позволяет:

• сделать умный дом отказоустойчивым;
• разнести сервисы по разным машинам, чтобы они не мешали друг другу;
• получить песочницу для экспериментов с Docker, Kubernetes и автоматизацией;
• объединить несколько локаций в единую сеть.

Начинать стоит с малого: два-три одноплатника, Docker Swarm и пара сервисов. Постепенно ты поймёшь, какие задачи удобнее решать распределённо, и кластер станет естественной частью твоей домашней инфраструктуры.

А если захочешь пойти дальше — присмотрись к Kubernetes (k3s), который отлично работает на ARM-кластерах. Но это уже совсем другая история.