Кластер серверов — это несколько отдельных машин, которые работают вместе и снаружи выглядят как один сервис. Пользователь открывает сайт по одному адресу и не догадывается, что его запрос обслужила третья машина из пяти, а первая в этот момент перезагружается после сбоя. Собирают такую связку на обычных виртуальных или физических машинах: подойдут даже недорогие узлы из каталога, а для схем с быстрым добавлением мощности удобнее облачные VPS с почасовой тарификацией. Суть не в железе, а в том, что нагрузка и ответственность распределены между несколькими независимыми серверами.
Материал для тех, кто уже держит проект на одном сервере и думает, не пора ли ставить второй. Разберём, из чего состоит кластер, чем он отличается от одной мощной машины, какие бывают схемы объединения, почему узлов берут нечётное число, куда девать сессии и файлы, а также с какой нагрузки вторая машина окупается. В конце — пошаговая сборка связки из трёх узлов, список типичных ошибок и ответы на частые вопросы.
Кластер серверов простыми словами: что видит пользователь и что происходит внутри
Представьте интернет-магазин на одном сервере. Диск заполнился, процесс базы данных упал, машина ушла в перезагрузку — магазин недоступен, пока администратор не разберётся. Кластер убирает эту единственную точку отказа: рядом стоит вторая машина с той же копией приложения, и запросы уходят на неё.
Снаружи у кластера один вход — общий IP-адрес или доменное имя. За этим входом стоит балансировщик: программа или сервис провайдера, который принимает запрос и решает, какому узлу его отдать. Узел — одна машина в составе кластера. Узлов может быть 2, 3, 5 или несколько сотен, и добавление ещё одного не требует переписывать приложение.
Кластер решает две разные задачи, и их полезно не путать. Первая — отказоустойчивость: сервис продолжает работать, когда один узел вышел из строя. Вторая — производительность: суммарная мощность нескольких машин больше, чем у одной, и растёт она линейно, пока хватает узлов. Часто нужна только одна из задач, и от этого зависит выбор схемы.
Чем кластер отличается от одного мощного сервера
Первая мысль при росте нагрузки — взять тариф побольше: вместо 2 ядер и 4 ГБ памяти заказать 8 ядер и 16 ГБ. Это вертикальное масштабирование, и до определённого предела оно проще и дешевле. Никаких изменений в архитектуре: приложение то же, база та же, миграция сводится к смене тарифа и перезагрузке.
Ограничений у такого пути два. Верхнее — потолок конфигурации: рано или поздно вы упрётесь в максимальный тариф провайдера, и дальше расти некуда. Нижнее и более важное — надёжность. Сервер на 32 ГБ памяти падает так же полностью, как сервер на 1 ГБ, и вместе с ним падает весь проект.
Кластер — это горизонтальное масштабирование: мощность добавляется не внутри машины, а новыми машинами. Потолка практически нет, а отказ одного узла отнимает не весь сервис, а только его часть. Плата за это — сложность: появляются балансировщик, синхронизация данных, общее хранилище и мониторинг, за которыми надо следить.
| Параметр | Один мощный сервер | Кластер из 3 узлов |
|---|---|---|
| Отказ железа | Сервис лежит целиком | Работает на 2 оставшихся узлах |
| Обновление ОС | Простой 5–15 минут | Без простоя, по одному узлу |
| Потолок роста | Максимальный тариф провайдера | Ограничен только бюджетом |
| Сложность настройки | Базовая, 1 конфиг | Балансировщик, репликация, кворум |
| Минимальный счёт | 1 тариф | 3 тарифа плюс балансировщик |
Три базовые схемы: активный-пассивный, активный-активный и шардирование
Схема активный-пассивный — самая простая. Работает один узел, второй стоит рядом с актуальной копией данных и ничего не обслуживает. Как только основной перестаёт отвечать, механизм переключения переносит на резерв общий IP-адрес, и трафик уходит туда. Переключение занимает от нескольких секунд до пары минут, в зависимости от того, как быстро система признаёт узел мёртвым.
Схема активный-активный сложнее и полезнее. Оба узла (или все пять) обслуживают запросы одновременно, а балансировщик распределяет нагрузку между ними. Отказ одного узла из трёх снижает доступную мощность примерно на 33%, но сервис продолжает работать без переключений и пауз. Резерв не простаивает, а приносит пользу каждый день.
Шардирование применяют, когда узкое место — не процессор, а объём данных. База делится на части — шарды — по какому-нибудь признаку: пользователи с номером до миллиона на первом узле, дальше — на втором. Каждый шард хранит только свой кусок, поэтому суммарная база может быть в разы больше, чем влезает на одну машину. Отказоустойчивости само по себе шардирование не даёт: его комбинируют с репликацией каждого шарда.
| Схема | Минимум узлов | Что при отказе одного | Когда выбирать |
|---|---|---|---|
| Активный-пассивный | 2 | Переключение за 5–120 секунд | Сайт или 1С, где важна простота |
| Активный-активный | 2–3 | Мощность падает на 33–50% | Высокий трафик, API, интернет-магазин |
| Шардирование | 2 плюс реплики | Недоступна часть данных | База больше 500 ГБ, аналитика |
| Кластер с кворумом | 3 или 5 | Кворум сохраняется, сервис жив | Базы данных, очереди, хранилища |
Как балансировщик распределяет запросы между узлами
Балансировщик — точка входа кластера. Он принимает соединение на портах 80 и 443, выбирает живой узел и передаёт запрос ему. Простейший вариант делается на nginx через блок upstream: это список адресов, между которыми nginx раскладывает запросы по кругу.
upstream backend {
server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
server 10.0.0.13:8080 backup;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_502;
}
}Разберём построчно. Строки с server перечисляют узлы кластера по внутренним адресам и порту приложения. Параметр max_fails=3 означает: после трёх неудачных попыток подряд узел считается нерабочим, а fail_timeout=30s — что его исключат из ротации на 30 секунд, потом снова проверят. Пометка backup у третьего узла делает его резервом: он получит трафик, только когда первые два недоступны.
Директива proxy_next_upstream говорит nginx повторить запрос на следующем узле, если текущий вернул ошибку, отвалился по таймауту или ответил кодом 502. Пользователь при этом получит нормальный ответ и не увидит ошибку. Подробнее о базовой конфигурации веб-сервера — в отдельном разборе настройки nginx.
Альтернатива — HAProxy, специализированный балансировщик с более гибкими проверками здоровья узлов и подробной статистикой. Третий вариант — облачный балансировщик самого провайдера: он живёт вне ваших машин, поэтому не становится новой точкой отказа, но стоит отдельных денег и настраивается только через панель.
Кворум и split-brain: почему узлов должно быть нечётное число
Кворум — это минимальное число узлов, которое должно видеть друг друга, чтобы кластер считал себя работоспособным. Обычно это большинство: 2 из 3, 3 из 5. Правило существует ради защиты от ситуации, которая называется split-brain — «расщеплённое сознание» кластера.
Представьте два узла и обрыв сети между ними. Оба живы, оба перестали видеть соседа, и каждый решает: «партнёр умер, беру всё на себя». Дальше обе машины начинают принимать записи в базу, и через час у вас две расходящиеся версии данных, которые невозможно свести автоматически. Именно поэтому связка из двух узлов для баз данных небезопасна.
С тремя узлами такой ситуации не возникает. При разрыве сети группа из двух машин видит большинство и продолжает работать, одинокий третий узел большинства не набирает и переходит в режим только для чтения. Данные остаются в одной версии. Пять узлов дают запас: кластер переживёт отказ сразу двух машин.
| Узлов в кластере | Кворум | Переживёт отказов | Риск split-brain |
|---|---|---|---|
| 2 | 2 из 2 | 0 | Высокий |
| 3 | 2 из 3 | 1 | Нет |
| 4 | 3 из 4 | 1 | Нет, но узел лишний |
| 5 | 3 из 5 | 2 | Нет |
Из таблицы видно, почему чётные числа не берут: четвёртый узел стоит денег, но переживаемых отказов не добавляет. Если бюджет позволяет только две полноценные машины, третьим ставят самый дешёвый узел-арбитр без данных — он нужен лишь для голосования и обходится в 59–127 ₽/мес.
Где хранить состояние: сессии, файлы и база данных
Главная сложность кластера не в железе, а в состоянии. Пока приложение живёт на одном сервере, сессии пользователей, загруженные картинки и база лежат на одном диске. Как только машин становится две, каждый файл на локальном диске превращается в проблему: пользователь загрузил аватар на первый узел, следующий запрос попал на второй, и картинки там нет.
Сессии выносят в общее хранилище в памяти — обычно это Redis, который слушает порт 6379 и отдаёт данные за доли миллисекунды. Все узлы читают и пишут сессии в него, поэтому пользователя не выкидывает из личного кабинета при переключении между машинами. Тот же Redis удобно использовать как общий кэш.
Пользовательские файлы переносят в объектное хранилище: приложение сохраняет файл по протоколу HTTP, а не на локальный диск, и любой узел получает его по тому же адресу. Базу данных настраивают на репликацию — постоянное копирование изменений с одной машины на другие. Одна машина принимает записи, остальные получают копию и обслуживают чтение. Так снимается до 80–90% нагрузки чтения с основного сервера.
С какой нагрузки кластер окупается
Кластер имеет смысл, когда простой стоит дороже второго сервера. До этого момента надёжнее и дешевле держать один сервер с двукратным запасом ресурсов и настроенными регулярными бэкапами. Один сервер с проверенной резервной копией восстанавливается за 20–40 минут, и для большинства корпоративных сайтов этого достаточно.
Считать удобно через минуты недоступности. Уровень 99,9% в соглашении об уровне сервиса допускает 43 минуты простоя в месяц и около 8,8 часа в год. Уровень 99,99% — уже 4,3 минуты в месяц. Одиночный сервер с ручным восстановлением реально держит 99,5–99,9%, то есть до 3,6 часа простоя в месяц.
Дальше подставьте свою цифру. Возьмите средний доход или убыток за час работы проекта и умножьте на разницу в часах простоя между схемами. Если результат больше стоимости дополнительных узлов, кластер экономит деньги; если меньше — вы платите за спокойствие, и это тоже допустимый выбор, просто его надо делать осознанно.
Есть и нефинансовый порог. Кластер требует человека, который умеет его чинить: диагностировать репликацию, разбирать конфликты и читать логи балансировщика. Без такого специалиста связка из трёх узлов ломается чаще, чем один аккуратно настроенный сервер, — сложность сама по себе источник отказов.
На каких серверах собирают кластер: конфигурации и цены
Для узлов кластера берут одинаковые машины: разные конфигурации усложняют балансировку, потому что слабый узел начинает отвечать медленнее и тянет вниз общие показатели. Стартовый вариант для веб-проекта — 2 ядра и 4 ГБ памяти на узел, для узла-арбитра хватит 1 ядра и 1 ГБ.
Важнее конфигурации — расположение. Узлы одного кластера должны стоять в одном дата-центре или хотя бы в одном городе: сетевая задержка между ними напрямую влияет на скорость репликации. В пределах площадки это 0,2–1 мс, между Москвой и Петербургом — уже 12–20 мс, и синхронная запись в базу начинает тормозить. Если проект рассчитан на российскую аудиторию, смотрите площадки в разделе VPS в России.
| Провайдер | Стартовая цена | Базовая конфигурация | Тарифов в каталоге |
|---|---|---|---|
| Cloudcore | от 59 ₽/мес | 1 ядро, 1 ГБ, 10 ГБ NVMe | 12 |
| Hosting-Russia | от 99 ₽/мес | по запросу | — |
| 4VPS | от 110 ₽/мес | 1 ядро, 1 ГБ, 5 ГБ NVMe | 568 |
| HostVDS | от 127 ₽/мес | 1 ядро, 1 ГБ, 10 ГБ NVMe | 12 |
Данные проверены 04.09.2026.
Цены в таблице стартовые — это уровень арбитра или небольшого узла под статику. Рабочие узлы с 2 ядрами и 4 ГБ обойдутся дороже, поэтому считайте бюджет сразу на три машины. Подборка бюджетных вариантов собрана в разделе недорогих VPS, всего в каталоге сравниваются 44 площадки.
Как собрать кластер из трёх узлов: пошаговая инструкция
Ниже минимальная рабочая схема для сайта: два узла с приложением, третий с балансировщиком и общим состоянием. Все действия выполняются от администратора, приложение считается уже работающим на одном сервере.
- Закажите три одинаковые машины в одном дата-центре: 2 ядра, 4 ГБ памяти, 40 ГБ NVMe. Запишите их внутренние адреса, например 10.0.0.11, 10.0.0.12 и 10.0.0.13.
- Соедините узлы приватной сетью провайдера и закройте порты приложения снаружи, оставив открытыми только 80 и 443 на балансировщике.
- Разверните одинаковое окружение на узлах 10.0.0.11 и 10.0.0.12: одна версия языка, одни версии библиотек, один и тот же код из репозитория — общего хранилища исходников, например в Git.
- Поднимите Redis на третьем узле и переключите на него хранение сессий, указав в конфигурации приложения адрес 10.0.0.13 и порт 6379.
- Настройте репликацию базы: узел 10.0.0.11 принимает записи, узел 10.0.0.12 получает копию и обслуживает чтение.
- Установите nginx на третьем узле с блоком upstream из примера выше и направьте на него A-запись домена.
- Проверьте отказ: остановите приложение на узле 10.0.0.11 (команда вида
systemctl stop имя-службы) и убедитесь, что сайт по-прежнему открывается — балансировщик уведёт трафик на узел 10.0.0.12.
Добавьте проверку здоровья — отдельный адрес, по которому приложение само сообщает, всё ли у него в порядке. Пусть по адресу /health оно возвращает код 200 только тогда, когда база и Redis доступны. Иначе балансировщик оставит в ротации узел, который формально жив, но запросы обслуживать не может.
Как убедиться, что кластер переживёт настоящий отказ
Собранный кластер и работающий кластер — разные вещи. Схема, которую ни разу не ломали намеренно, обычно не срабатывает в первый настоящий сбой. Причины типовые: балансировщик держит соединение с мёртвым узлом, реплика отстала на 40 минут, у резерва просрочен сертификат.
Проверяйте по слоям, от простого к сложному. Первый слой — сеть: пингуется ли узел, отвечает ли порт приложения. Второй — приложение: возвращает ли /health код 200. Третий — данные: одинаковый ли ответ отдают узлы на один и тот же запрос, не отстала ли реплика.
curl -s -o /dev/null -w "%{http_code} %{time_total}n" http://10.0.0.11:8080/health
curl -s -o /dev/null -w "%{http_code} %{time_total}n" http://10.0.0.12:8080/healthКоманда запрашивает адрес проверки на каждом узле и печатает только код ответа и время в секундах: флаг -s убирает индикатор загрузки, -o /dev/null выбрасывает тело страницы, -w задаёт формат вывода. Ответ вида 200 0.042 означает исправный узел с временем ответа 42 мс. Ответ 000 — узел вообще не принял соединение, 502 — веб-сервер жив, но приложение за ним упало, 200 3.150 — узел отвечает, но настолько медленно, что его лучше вывести из ротации.
Раз в месяц устраивайте учебный отказ: гасите узел в рабочее время и смотрите, сколько секунд занимает переключение и что видят пользователи. Собирать эти данные удобно вместе с мониторингом сервера, чтобы видеть не только факт отказа, но и поведение остальных узлов под возросшей нагрузкой.
Частые ошибки при сборке кластера
Большинство проблем возникает не из-за железа, а из-за того, что кластер собрали наполовину: балансировщик поставили, а состояние оставили на локальных дисках. Ниже ошибки, которые встречаются чаще всего.
- Два узла вместо трёх у базы данных — прямой путь к split-brain при обрыве сети.
- Балансировщик в одном экземпляре: он сам становится новой единственной точкой отказа.
- Сессии и загруженные файлы остались на локальных дисках узлов.
- Узлы в разных городах: задержка 12–20 мс ломает синхронную репликацию.
- Проверка здоровья смотрит только на порт, а не на реальную работоспособность приложения.
- Кластер собран, но отказ ни разу не проверяли учебно.
Отдельная ошибка — считать кластер заменой резервным копиям. Репликация честно копирует и ошибочно удалённые данные: команда, стёршая таблицу на первом узле, за секунду повторится на всех остальных. Бэкапы нужны в любой схеме, и хранить их следует вне кластера.
Частые вопросы
Кластер серверов — это обязательно дорого? Не обязательно. Учебную связку из трёх узлов можно собрать на тарифах от 59–127 ₽/мес, и в сумме это меньше 400 ₽ в месяц. Дорогим кластер делают не сами машины, а требования к рабочей нагрузке: узлы с 2 ядрами и 4 ГБ памяти стоят кратно больше стартовых.
Сколько узлов нужно для начала? Три. Два узла дают отказоустойчивость приложения, но не защищают базу от расщепления при обрыве связи. Если бюджет ограничен, третьим можно поставить самый дешёвый узел-арбитр без данных — он участвует только в голосовании за кворум.
Кластер заменяет резервное копирование? Нет. Кластер защищает от отказа железа, а бэкап — от ошибок людей и повреждения данных. Удаление таблицы или шифрование файлов вирусом реплицируется на все узлы за секунды, восстановить это можно только из копии, лежащей вне кластера.
Чем кластер отличается от Kubernetes? Кластер — общая идея объединения машин, а Kubernetes — конкретная система, которая управляет контейнерами поверх такого объединения. Она берёт на себя размещение приложений по узлам и перезапуск упавших, но добавляет свой слой сложности, который для двух-трёх машин обычно избыточен.
Как понять, что одному серверу уже не хватает? Смотрите на три показателя: средняя загрузка процессора выше 70% в течение дня, свободной памяти меньше 15%, время ответа приложения выросло в 2–3 раза от обычного. Если апгрейд тарифа даёт лишь пару месяцев запаса, пора считать горизонтальную схему.
Что такое время переключения и на что оно влияет? Это интервал между отказом узла и моментом, когда трафик пошёл на живую машину: от 5 секунд при активной схеме с балансировщиком до 2 минут при переносе IP-адреса. Всё это время часть запросов завершается ошибкой, поэтому величину переключения закладывают в расчёт допустимого простоя.
Итог
Кластер серверов — это несколько машин под одним входом, которые делят между собой нагрузку и подстраховывают друг друга. Начинать имеет смысл с трёх узлов, обязательно вынести сессии, файлы и базу за пределы локальных дисков и хотя бы раз в месяц устраивать учебный отказ. Пока час простоя стоит дешевле дополнительных серверов, один узел с запасом мощности и рабочими бэкапами остаётся разумным выбором.
Когда решите собирать связку, берите одинаковые машины на одной площадке и сравнивайте конфигурации по цене за ядро и гигабайт памяти. Актуальные тарифы 44 провайдеров с фильтрами по ресурсам, локации и способу оплаты собраны в разделе аренды VPS и VDS.
