Изображение сгенерировано с ИИ
Зачем вообще всё это нужно?
Представьте: у вас работает сайт, и в 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) всегда может принять решение. Кластер продолжает работать корректно.
Именно поэтому три узла позволяют получить полноценный quorum 2 из 3 без дополнительного QDevice и являются удобной базовой конфигурацией для кластера.
Итого: что даёт эта схема
Ключевые характеристики:
- RTO (Recovery Time Objective, время восстановления): от нескольких секунд до 90 минут в зависимости от сценария
- RPO (Recovery Point Objective, допустимая потеря данных): от 15 минут (репликация) до 24 часов (бэкапы) в зависимости от сценария
Ограничения схемы
Честно о том, чего эта схема не даёт:
- Автоматический failover из коробки. Proxmox кластер с репликацией — это не High Availability в автоматическом режиме. Для полностью автоматического переключения нужна HA-группа в Proxmox (требует общего хранилища или Ceph) либо внешние инструменты.
- Нулевая потеря данных. Репликация происходит с задержкой. Если нода умрёт прямо между двумя итерациями репликации — данные за этот промежуток будут потеряны.
- Защита от ошибок в коде. Если в коде сайта баг, который портит данные — три сервера не помогут.
Для большинства проектов эти ограничения приемлемы. Для систем, где нужен гарантированный нулевой RPO (банки, медицина), схема дорабатывается отдельно.
Краткая схема построения
- Три выделенных сервера, два из которых будут использоваться под продакшн, третий под бэкапы всего.
- Установка и настройка Promox на все сервера.
- Настройка RAID1 на продакшене.
- Настройка RAID1 на бэкапном сервере.
- Установка и настройка PBS сервера для хранения бэкапов.
- Установка и настройка ПО для мониторинга железа серверов Supermicro.
- Уведомления от мониторинга на почту + в телегу в случае алярмы на сервере.
- Переход на Rocky Linux 10. Идеально для продакшена.
- Переход на angie вместо nginx. Решение проблем с сертификатами + закрытие уязвимостей (в моменте).
- Установка Mikrotik в качестве шлюза.
- Постороение кластера и туннелей между серверами.
- Разработка собственного метода оповещений.
План поддержки
- Proxmox. Обновление, поддержка актуальной версии и закрытие уязвимостей.
- Rocky Linux. Обновления, поддержка актуальной версии, закрытие уязвимостей.
- Angie Обновления, поддержка актуальной версии, закрытие уязвимостей.
- Контроль целостности бэкапов.
- Реагирование на любые типы инцидентов и решение проблем, как минимум:
- Выход из строя сервера.
- Выход из строя части сервера, например дисков.
- Отсутсвие связи на одном из серверов.
- Работы по восстановлению сервера в случае отказа.
- Общий мониторинг всех серверов и систем.
Выводы
Два production-сервера в Москве и отдельный backup-сервер в Санкт-Петербурге — это разумный баланс между надёжностью и стоимостью. Вы получаете защиту от самых распространённых причин даунтайма: аппаратных сбоев, аварий в дата-центре и случайных удалений данных.