C.7. Требования к катастрофоустойчивому кластеру

Описываемая функциональность находится в разработке. Для внедрения в промышленную эксплуатацию обратитесь в поддержку.

C.7.1. Основные понятия и сокращения

БД — база данных.

СУБД — система управления базами данных.

ЦОД — центр обработки данных.

ОЦОД — основной центр обработки данных.

РЦОД — резервный центр обработки данных.

ОУК — отказоустойчивый кластер.

КУК — катастрофоустойчивый кластер.

C.7.2. Общее описание решения

В ОЦОД заказчика размещаются основные сегменты кластера и кластер etcd. Сегмент представляет собой отказоустойчивый кластер из двух узлов с экземплярами СУБД Postgres Pro, один из которых в режиме ведущего, а другой в режиме синхронного резервного. На каждом узле сегмента запущена служба shardmand , которая проверяет экземпляры СУБД Postgres Pro и обменивается информацией с кластером etcd, обеспечивая кластеризацию Shardman. Кластер etcd состоит из трёх узлов, тем самым обеспечивая кворум.

Для обеспечения катастрофоустойчивости в РЦОД заказчика размещается кластер с идентичной конфигурацией и набором компонентов. По умолчанию узлы СУБД резервного кластера Shardman выключены. Непрерывная доставка журналов из ОЦОД в РЦОД осуществляется в асинхронном режиме. При этом используется протокол физической репликации с помощью утилиты pg_receivewal из стандартной поставки СУБД Shardman. Она записывает WAL в стандартный каталог экземпляра $PGDATA/pg_wal. Управление утилитой обеспечивается кластерным программным обеспечением. Узлы СУБД резервного кластера Shardman запускаются службой shardmand, когда обнаруживается точка синхронизации в резервном etcd кластере, в результате чего осуществляется синхронизация изменений WAL до LSN, полученного из точки синхронизации. Кластеры etcd в разных ЦОД изолированы друг от друга, в связи с этим передача информации о появлении новой точки синхронизации осуществляется скриптом периодически на стороне ОЦОД в etcd РЦОД.

C.7.3. Топология репликации

Потоковая физическая репликация обеспечивается в следующих случаях:

  • Между узлами сегментов СУБД Postgres Pro в ОЦОД (синхронная)

  • Между узлами сегментов СУБД Postgres Pro в РЦОД (синхронная)

  • Между узлами сегментов СУБД Postgres Pro разных ЦОД (асинхронная)

C.7.4. Требования к оборудованию и сети

В ОЦОД и РЦОД оборудование должно быть идентичным по системным ресурсам и конфигурации для всех компонентов катастрофоустойчивого кластера.

Связанность сети между ЦОД должна обеспечиваться прямой оптоволоконной линией. Пропускная способность канала должна быть не менее 20 Гбит/с. Также необходимо предусмотреть резервный канал.

C.7.5. Механизмы репликации

Для обеспечения работы ОУК/КУК Shardman используется встроенный в Postgres Pro протокол потоковой физической репликации. Репликация на РЦОД асинхронная.

Автоматическое восстановление ОУК Shardman после сбоя обеспечивается кластерным программным обеспечением.

Восстановление КУК после сбоя предусмотрено только в ручном полуавтоматическом режиме.

C.7.6. Мониторинг и управление

Мониторинг и управление кластером Shardman в рамках ЦОДа обеспечивается с помощью утилиты shardmanctl.

C.7.7. Безопасность

C.7.7.1. Шифрование данных при передаче (TLS/SSL)

Требуется обеспечить защищённый канал между ЦОДами.

C.7.7.2. Аутентификация и авторизация между узлами

Аутентификация между узлами обеспечивается штатными средствами СУБД Postgres Pro.

C.7.7.3. Защита от несанкционированного доступа к резервным серверам

Защита от несанкционированного доступа к резервным серверам обеспечивается средствами ОС и сети.

C.7.8. Тестирование и откат

Рекомендуется периодически производить тестовое переключение.

C.7.8.1. Проверка целостности данных после аварийного переключения

Проверка целостности данных после аварийного переключения обеспечивается утилитой резервного копирования shardmanctl probackup.

C.7.8.2. Переключение на РЦОД

При отказе основного ЦОД, администратор убеждается в его недоступности и инициирует процедуру повышения резервных узлов до состояния рабочих. Для этого резервный кластер переводится из режима standby в режим master. Данная операция осуществляются централизованно с помощью командной утилиты shardmanctl, никаких дополнительных ручных операций не требуется.

C.7.8.3. Восстановление ОЦОД

Для восстановления географически удалённых узлов в ОЦОД требуется создать резервную копию основного кластера и восстановить её на данные узлы. Резервная копия может быть создана любым способом – холодная РК, РК с использованием репозитория pg_probackup. Каждый из этих способов подразумевает перенос резервной копии в ОЦОД. После восстановления каталога БД из резервной копии, запускается pg_receivewal, который подключается к специально созданному слоту репликации ведущего или резервного сегмента в РЦОД и начинает приём WAL сегментов в асинхронном режиме, записывая их сразу в каталог $PGDATA/pg_wal основного узла.

На кластере РЦОД раз в заданный интервал времени скриптом создаётся точка синхронизации, которая записывается в etcd РЦОД, а также отправляется в etcd ОЦОД. Узлы резервного кластера в ОЦОД при появлении записи о точке синхронизации в etcd проверяют, получен ли WAL, содержащий данную запись. При наличии записи в WAL на всех узлах резервного кластера в ОЦОД кластерным ПО выполняется запуск сервера СУБД в режиме восстановления с проигрыванием журналов до точки синхронизации. По достижении резервным узлом точки синхронизации применение WAL останавливается, производится проверка, что все узлы успешно применили записи, после чего сервер СУБД останавливается и повторяются цикл получения WAL, проверки наличия точки синхронизации, запуск СУБД в режиме восстановления.

C.7.8.4. Переключение обратно на ОЦОД

Чтобы переключиться обратно на ОЦОД, создаётся и переносится резервная копия кластера из РЦОД в ОЦОД, запускаются узлы в режиме резерва, после получения недостающих WAL происходит выключение узлов кластера в РЦОД и повышение узлов кластера в основном ЦОД.

C.7.9. Резервное копирование в рамках георезервирования

В рамках географически распределённой системы для кластера РЦОД необходимо предусмотреть аналогичное хранилище резервных копий, как и для ОЦОД, а также настроить регулярную синхронизацию основного хранилища в резервное.

C.7.9.1. Хранение резервных копий в географически распределённых хранилищах

Глубина хранения резервных копий определяется политикой резервного копирования.

C.7.10. Документация и регламенты

За более подробной информацией по аварийному переключению и инструкциями по штатному переключению обратитесь в поддержку Prostres Pro.