Блог ИТCИ

Как мы строим отказоустойчивую инфраструктуру на трёх серверах с Proxmox

Источник изображения: magnific

Зачем вообще всё это нужно?

Представьте: у вас работает сайт, и в 3 часа ночи в дата-центре сгорает сервер. Или провайдер устраивает технические работы. Или кто-то случайно заливает воду в серверную.
Если сайт живёт на одном сервере — он упал. Всё. Клиенты видят белый экран, вы теряете деньги и репутацию.
Мы выстраиваем инфраструктуру по-другому: три сервера в разных локациях, и выход из строя любого из них — это просто рабочий момент, а не катастрофа.

Что такое «дедик» и Proxmox — коротко для тех, кто не в теме

Дедик (выделенный сервер, dedicated server) — это физическая машина в дата-центре, которую вы арендуете целиком. Не виртуалка, не облако — железо, которое работает только для вас.
Proxmox — это операционная система для серверов, которая позволяет запускать внутри одного железного сервера несколько виртуальных машин (VM). Грубо говоря, один физический сервер превращается в несколько «логических» серверов. На одном дедике может жить и веб-сервер, и база данных, и тестовый стенд — все изолированно друг от друга.

Схема: три сервера, три локации

┌─────────────────────────────────────────────────────────┐
│                   PROXMOX КЛАСТЕР                       │
│                                                         │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │   ДЕДИК #1   │  │   ДЕДИК #2   │  │   ДЕДИК #3   │   │
│  │  Москва      │  │  Амстердам   │  │  Франкфурт   │   │
│  │              │  │              │  │              │   │
│  │  VM: сайт   ◄──►  VM: сайт     │  │  БЭКАПЫ      │   │
│  │  VM: БД     ◄──►  VM: БД       │  │  (резерв)    │   │
│  │              │  │  репликация  │  │              │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
│                                                         │
│  ← активные ноды →              ← нода бэкапов →        │
└─────────────────────────────────────────────────────────┘
Три физических сервера объединены в один кластер Proxmox. Это значит, что они «знают» друг о друге и координируют свои действия. С точки зрения управления — это одна система, просто физически разнесённая по трём местам.
Дедики #1 и #2 — рабочие. На них крутятся реальные виртуальные машины с сайтом и базой данных. Между ними настроена репликация: всё, что происходит на VM первого сервера, синхронно копируется на второй. В любой момент времени оба сервера содержат актуальные данные.
Дедик #3 — резервный. Он не обрабатывает живой трафик, но регулярно получает бэкапы от первых двух. Это отдельный уровень защиты на случай более серьёзных проблем.

Как работает репликация виртуальных машин

Репликация — это непрерывное зеркалирование данных между двумя серверами.
Представьте это так: у вас есть два одинаковых дневника. Каждый раз, когда вы пишете что-то в первый — то же самое автоматически появляется во втором. Если первый дневник потеряется, второй содержит всё до последней записи.
В нашем случае Proxmox реплицирует виртуальные диски между дедиком #1 и дедиком #2 с заданным интервалом (обычно каждые 15−30 минут). Это означает:
  • Если дедик #1 умирает, на дедике #2 уже есть почти актуальная копия всех VM.
  • Администратор запускает VM на дедике #2, и сайт поднимается с потерей данных максимум за последний интервал репликации.
  • При желании этот процесс можно частично автоматизировать.
Важный момент: репликация в Proxmox — это не мгновенный failover (как, например, в дорогих enterprise-решениях). Это именно резервная копия с небольшим отставанием. Для полностью автоматического переключения потребуются дополнительные инструменты — балансировщик нагрузки, мониторинг и скрипты запуска. Но даже без этого время восстановления измеряется минутами, а не часами.

Зачем третий сервер под бэкапы?

Казалось бы, зачем бэкапы, если есть репликация?
Репликация защищает от аппаратного сбоя — железо умерло, данные есть на втором сервере. Но она не защищает от человеческой ошибки или атаки.
Несколько сценариев, где репликация не поможет, а бэкап — спасёт:
  • Кто-то случайно удалил важную таблицу в базе данных. Эта операция реплицировалась на второй сервер мгновенно. Оба сервера теперь без таблицы.
  • Вирус-шифровальщик зашифровал файлы на первом сервере. Через 15 минут зашифрованные файлы реплицировались на второй.
  • Разработчик накатил «горячий» патч, который всё сломал, и нужно откатиться на версию трёхдневной давности.
В этих случаях только бэкап на изолированном третьем сервере позволяет откатиться назад.
Бэкапы настраиваются по расписанию: например, ежедневно в 3 ночи Proxmox делает снапшоты VM с дедиков #1 и #2 и отправляет на дедик #3. Хранится, например, 14 дней истории — можно восстановиться на любую точку.

Что происходит при разных сбоях

Сценарий 1: Умер дедик #1

Дедик #2 продолжает работать. Сайт работает. Нужно только перенастроить DNS или балансировщик, чтобы трафик шёл на #2. Если DNS уже настроен через балансировщик — вообще ничего не нужно делать.
Потеря данных: данные за последний интервал репликации (15−30 минут). Время простоя: от нуля (если настроен автофейловер) до нескольких минут (если переключать вручную).

Сценарий 2: Умерли оба дедика #1 и #2

Редкий, но возможный сценарий — DDoS на уровне датацентра, авария провайдера, которая накрыла обе локации одновременно.
В этом случае поднимаем VM с последнего бэкапа на дедике #3. Время восстановления зависит от размера VM и скорости дисков, обычно 30−90 минут.
Потеря данных: данные с момента последнего бэкапа (до 24 часов при ежедневных бэкапах).

Сценарий 3: Случайно удалили данные / атака шифровальщика

Поднимаем VM с нужной точки восстановления с дедика #3. Выбираем бэкап, сделанный до инцидента, и разворачиваем его на свободном железе.

Сценарий 4: Технические работы на дедике #1

Просто переключаем трафик на #2, проводим работы, возвращаем. Никакого простоя.

Что такое кворум и почему три сервера лучше двух

В кластере Proxmox действует принцип кворума: сервер выполняет действия только если большинство нод в кластере «согласны» с этим.
При двух нодах это создаёт проблему: если связь между ними пропала (но обе работают), каждый думает, что другой упал, и оба начинают пытаться захватить управление. Это называется split-brain — «раздвоение мозга». Данные могут быть повреждены.
С тремя нодами проблема решается: даже если связь между двумя нодами пропала, третья выступает «судьёй». Большинство (2 из 3) всегда может принять решение. Кластер продолжает работать корректно.
Именно поэтому три сервера — это минимально правильная конфигурация для Proxmox кластера.

Итого: что даёт эта схема

Угроза
Без нашей схемы
С нашей схемой
Железо одного сервера умерло
Сайт упал
Продолжает работать
Авария в одном дата-центре
Сайт упал
Продолжает работать
Случайное удаление данных
Данные потеряны
Откат из бэкапа
Атака шифровальщика
Данные потеряны
Откат из бэкапа
Плановые работы
Плановый простой
Нулевой простой
Ключевые характеристики:
  • RTO (Recovery Time Objective, время восстановления): от нескольких секунд до 90 минут в зависимости от сценария
  • RPO (Recovery Point Objective, допустимая потеря данных): от 15 минут (репликация) до 24 часов (бэкапы) в зависимости от сценария

Ограничения схемы

Честно о том, чего эта схема не даёт:
  • Автоматический failover из коробки. Proxmox кластер с репликацией — это не High Availability в автоматическом режиме. Для полностью автоматического переключения нужна HA-группа в Proxmox (требует общего хранилища или Ceph) либо внешние инструменты.
  • Нулевая потеря данных. Репликация происходит с задержкой. Если нода умрёт прямо между двумя итерациями репликации — данные за этот промежуток будут потеряны.
  • Защита от ошибок в коде. Если в коде сайта баг, который портит данные — три сервера не помогут.
Для большинства проектов эти ограничения приемлемы. Для систем, где нужен гарантированный нулевой RPO (банки, медицина), схема дорабатывается отдельно.

Вывод

Три дедика с Proxmox в разных локациях — это разумный баланс между надёжностью и стоимостью. Вы получаете защиту от самых распространённых причин даунтайма: аппаратных сбоев, аварий в дата-центре и случайных удалений данных.
Это не самая простая схема в настройке, но она работает, и её стоимость несравнимо ниже потерь от незапланированного простоя.
2026-06-23 15:17 Поддержка