Данные и основа кластера
- Master-ноды Kubernetes или manager-ноды Swarm
- Реплики критичных MySQL и PostgreSQL
- Хранилище бэкапов, файлов и образов контейнеров
- Защищённая связь и контроль свежести копий
Резервная площадка и аварийное восстановление
Ваши данные.
Ваши данные.
В другом
датацентре.
Подготовлю независимую площадку, с которой можно восстановить работу при потере основного ДЦ. Настрою онлайн-репликацию баз, резервные копии и запуск инфраструктуры.
Постоянно — данные и минимум серверов.
Рабочие мощности добавляем при восстановлении.
Две независимые площадкиПример архитектуры
Основной ДЦ
Обслуживает клиентов
Управляющие узлы
Базы и файлы
Рабочие узлы
Резервный ДЦ
Принимает данные
Управляющие узлы
Реплики и копии
Воркеры по запросу
Отдельно — история резервных копий
Резерв обновляется, пока работает бизнес
Базы передают изменения, файлы копируются по расписанию. Полный набор рабочих узлов на резерве пока не нужен.
Под вашу инфраструктуру
KubernetesDocker SwarmPostgreSQLMySQLФайлы и S3
Готовность к потере площадкиЕсли недоступен
Если недоступен
целый датацентр.
Пожар, сбой питания или физическое повреждение, в том числе при атаке БПЛА, могут одновременно затронуть серверы и копии внутри одной площадки.
Резерв должен находиться за её пределами. Подберу другой датацентр с учётом географии и независимости провайдера. Подготовлю данные, доступы и порядок запуска сервисов, чтобы восстановление можно было начать при недоступности основной площадки.
Посмотреть порядок восстановленияЭкономика резервной площадкиМинимум ресурсов сейчас.
Минимум ресурсов сейчас.
Масштабирование при аварии.
Основная экономия — на вычислительных мощностях. Для Kubernetes и Swarm можно заранее подготовить управление кластером, а серверы приложений создавать по необходимости.
Мощности для приложений
- Рабочие узлы Kubernetes или Docker Swarm
- Дополнительные CPU и память для нагрузки
- Необходимые диски, балансировщики и сети
- Запуск сервисов и переключение трафика
«Только master-ноды» — про вычислительную часть кластера. Хранилище, резервные базы, сеть и сопровождение также входят в бюджет. Состав постоянных ресурсов подбирается под проект.
Меньше заранее запущенных серверов — дольше восстановление. Если простой критичен, подготовим больше мощностей заранее. Квоты и доступность ресурсов второго провайдера проверим отдельно.
Что включаем в защитуОт одной базы
От одной базы
до инфраструктуры.
Можно начать с самого важного: базы заказов, файлов клиентов или одного сервиса. Затем расширить резервирование на остальные компоненты.
Разобрать ваш проектKubernetes
Подготовлю отдельный резервный кластер с минимальным набором управляющих узлов. Сохраню конфигурации, секреты и описание приложений; настрою создание воркеров и развёртывание из кода.
Данные постоянных томов и баз резервируются отдельно. Снимок etcd хранит состояние управления кластером и не содержит файлы приложений на дисках.Docker Swarm
Подготовлю резервные manager-ноды, описания стеков, конфигурации и секреты. Проверю восстановление состояния Swarm, подключение воркеров и доступность нужных образов.
Volumes и базы копируются отдельно. Состав manager-нод и порядок сохранения состояния согласуются с требованиями к кворуму.PostgreSQL и MySQL
Настрою передачу изменений на резервную площадку, контроль отставания реплик и независимые резервные копии. При необходимости — восстановление на выбранный момент по WAL или binlog.
Способ репликации выбирается по версиям и нагрузке. Для логической репликации PostgreSQL отдельно учитываем миграции схемы и последовательности.Файлы и средства восстановления
Включу в резерв документы, S3-хранилища, репозитории, образы контейнеров, конфигурации и секреты. Сохраню инструкции и аварийные доступы вне основной инфраструктуры.
Перечень систем, срок хранения, шифрование и права доступа фиксируются до внедрения.Подготовленный сценарий аварииПонятный путь
Понятный путь
обратно к работе.
Заранее описываем зависимости и последовательность действий. Проверяем восстановление в изолированном окружении и измеряем фактическое время.
Выбрать точку
Подтвердить аварию, выбрать доступную копию и исключить одновременную запись на двух площадках.
Поднять ресурсы
Создать рабочие серверы, сети и диски из подготовленного кода. Восстановить данные и доступы.
Проверить сервисы
Развернуть совместимые версии приложений. Проверить данные, зависимости и ключевые операции.
Перевести трафик
Переключить точки входа и DNS по регламенту. Убедиться, что пользователи могут работать.
Переключение требует времени. Конкретный срок восстановления подтверждается испытанием вашей инфраструктуры; автоматическое переключение согласуется как отдельный сценарий.
Два показателя,
которые согласуем.
- RPO · Сколько данных допустимо потерять
- Зависит от отставания репликации или возраста последней успешно доставленной копии.
- RTO · Как долго сервис может быть недоступен
- Учитывает создание ресурсов, восстановление данных, проверки и переключение пользователей.
Внедрение и сопровождениеНачнём с того,
Начнём с того,
что нельзя потерять.
Разберу текущую инфраструктуру, объём данных и допустимый простой. Предложу минимальный состав резерва и покажу, как меняется бюджет при разных требованиях к восстановлению.
- Перечень защищённых системЧто копируется, куда, как часто и сколько хранится.
- Контроль репликации и бэкаповСвежесть данных, завершение копирования и уведомления об ошибках.
- Комплект восстановленияИнструкции, код инфраструктуры, версии компонентов и порядок получения доступов.
- Проверки по согласованному графикуТестовые восстановления и обновление инструкций при изменениях проекта.
Стоимость — под вашу инфраструктуру
Отдельно рассчитаю внедрение, сопровождение и расходы второго ДЦ: серверы, хранилище, трафик и испытания. Начать можно с одной критичной базы или сервиса.
До начала работ
Частые вопросы.
Почему недостаточно бэкапа у того же провайдера?
Важна независимость конкретной площадки и доступов. Копия в том же ДЦ может стать недоступной вместе с основными серверами. Другой регион у того же провайдера защищает от части рисков, но сохраняет общие зависимости. При аудите проверим географию, сеть, учётные записи и доступность управления.
Репликация заменяет резервные копии?
Реплика быстро получает изменения, включая ошибочное удаление или повреждение данных. Поэтому дополнительно нужны копии с историей, отдельные права доступа и проверяемое восстановление. Возможность защиты копий от удаления зависит от выбранного хранилища.
Действительно можно платить только за master-ноды?
Для вычислительной части резервного Kubernetes — можно подготовить схему, где постоянно запущены только управляющие узлы, а воркеры создаются при аварии. При этом данные, хранилища, реплики БД и сеть оплачиваются отдельно. Если нужны работающие операторы или служебные компоненты, в минимальный состав могут войти и небольшие рабочие узлы.
Сервис переключится мгновенно и без потери данных?
Экономичная резервная площадка предполагает время на запуск ресурсов и проверку сервисов. Асинхронная репликация может отставать, а у бэкапов есть интервал. Допустимую потерю данных и время простоя согласуем для каждого сервиса; фактическое восстановление проверим на испытании.
Нужно переносить основной проект?
Обычно основная площадка продолжает работать на прежнем месте. Резервирование подключается поэтапно. Первичная передача данных, создание копий и настройка репликации могут потребовать ресурсов и согласованного окна работ — это учтём в плане внедрения.
Что, если вместе с серверами недоступны GitLab и Vault?
Средства восстановления также включаем в резерв: код, образы, конфигурации, секреты и инструкции. Аварийные доступы владельца к резервному провайдеру и ключи расшифровки храним независимо от основной площадки. Проверяем, что восстановление действительно можно начать без её сервисов.
Обсудим ваш проектСколько стоит
Сколько стоит
ваш план Б?
Напишите, где размещён проект, какие базы и оркестратор используются, сколько данных нужно сохранить и какой простой допустим. Предложу состав резервной площадки и расчёт расходов.