33.5. Требования к катастрофоустойчивому кластеру #
- 33.5.1. Основные понятия и сокращения
- 33.5.2. Общее описание решения
- 33.5.3. Управление
- 33.5.4.
intervalWalSyncArbiter- 33.5.5. Топология репликации
- 33.5.6. Требования к оборудованию и сети
- 33.5.7. Механизмы репликации
- 33.5.8. Мониторинг и управление
- 33.5.9. Безопасность
- 33.5.10. Тестирование и откат
- 33.5.11. Резервное копирование для географически распределённой системы
- 33.5.2. Общее описание решения
Данный раздел описывает работу катастрофоустойчивого кластера, который обеспечивает более высокий уровень отказоустойчивости.
33.5.1. Основные понятия и сокращения #
БД — база данных.
СУБД — система управления базами данных.
ЦОД — центр обработки данных.
ОЦОД – основной центр обработки данных.
РЦОД — резервный центр обработки данных.
ОУК — отказоустойчивый кластер.
КУК — катастрофоустойчивый кластер.
33.5.2. Общее описание решения #
В ОЦОД находятся сегменты ведущего кластера. Сегменты являются отказоустойчивыми кластерами, состоящими из двух узлов экземпляров СУБД Postgres Pro, один из которых ведущий, второй— синхронный резервный. На каждом сегменте запущен демон shardmand, который проверяет экземпляры СУБД Postgres Pro.
Для обеспечения катастрофоустойчивости в РЦОД заказчика размещается кластер с идентичной конфигурацией и набором компонентов. По умолчанию узлы СУБД резервного кластера Shardman выключены. Непрерывная доставка журналов из ОЦОД в РЦОД осуществляется в асинхронном режиме. При этом используется протокол физической репликации с помощью утилиты pg_receivewal из стандартной поставки СУБД Shardman. Она записывает WAL в стандартный каталог экземпляра $PGDATA/pg_wal. Управление утилитой обеспечивается кластерным программным обеспечением. РЦОД взаимодействует с хранилищем ОЦОД, получает информацию об обновлениях конфигурации ОЦОД и применяет их. Точки синхронизации рассчитываются по эвристическому алгоритму, который анализирует WAL pg_receivewal. Это позволяет рассчитать возможные распределённые точки согласованности.
33.5.3. Управление #
КУК управляется через утилитуh shardmanctl с помощью следующих команд: shardmanctl cluster standby enable, shardmanctl cluster standby disable, shardmanctl cluster standby catchup, shardmanctl config update --from-primary-cluster.
Обратите внимание, что команду shardmanctl probackup restore можно использовать для развёртывания резервного кластера на основании резервной копии ведущего кластера с помощью указания --backup-path для пути резервной копии из центра обработки данных. В таком случае не будет поддерживаться использование параметров путь--schema-only, metadata-only, а также восстановление одного сегмента. Резервный кластер должен находиться в режиме standby на момент выполнения восстановления. По завершении команды при отставании от кластера ОЦОД необходимо запустить команду shardmanctl cluster standby catchup.
33.5.4. intervalWalSyncArbiter #
keeper в РЦОД рассчитывает возможные точки синхронизации, после чего процесс intervalWalSyncArbiter выбирает ту, которую можно применить ко всем экземплярам, и запускает синхронизацию до выбранной точки синхронизации.
33.5.5. Топология репликации #
Потоковая физическая репликация обеспечивается в следующих случаях:
Между узлами сегментов СУБД Postgres Pro в ОЦОД (синхронная)
Между узлами сегментов СУБД Postgres Pro в РЦОД (синхронная)
Между узлами сегментов СУБД Postgres Pro разных ЦОД (асинхронная)
33.5.6. Требования к оборудованию и сети #
В ОЦОД и РЦОД оборудование должно быть идентичным по системным ресурсам и конфигурации для всех компонентов катастрофоустойчивого кластера.
Связанность сети между ЦОД должна обеспечиваться прямой оптоволоконной линией. Пропускная способность канала должна быть не менее 20 Гбит/с. Также необходимо предусмотреть резервный канал.
33.5.7. Механизмы репликации #
Для обеспечения ОУК/КУК Shardmanиспользуется встроенный в Postgres Pro протокол потоковой физической репликации. Репликация на РЦОД асинхронная.
Автоматический восстановление ОУК Shardman после сбоя обеспечивается кластерным программным обеспечением.
Восстановление КУК после сбоя предусмотрено только в ручном полуавтоматическом режиме.
33.5.8. Мониторинг и управление #
Мониторинг и управление кластером Shardman в рамках ЦОДа обеспечивается с помощью утилиты shardmanctl.
Узнать статус кластера в режиме резерва можно с помощью команды shardmanctl cluster status.
33.5.9. Безопасность #
33.5.9.1. Защитное преобразование при передаче данных (TLS/SSL) #
Требуется обеспечить защищённый канал между ЦОДами.
33.5.9.2. Аутентификация и авторизация между узлами #
Аутентификация между узлами обеспечивается штатными средствами СУБД Postgres Pro.
33.5.9.3. Защита от несанкционированного доступа к резервным серверам #
Защита от несанкционированного доступа к резервным серверам обеспечивается средствами ОС и сети.
33.5.10. Тестирование и откат #
Рекомендуется периодически производить тестовое переключение.
33.5.10.1. Проверка целостности данных после аварийного переключения #
Проверка целостности данных после аварийного переключения обеспечивается утилитой резервного копирования shardmanctl probackup.
33.5.10.2. Переключение на РЦОД #
При отказе основного ЦОД, администратор убеждается в его недоступности и инициирует процедуру повышения резервных узлов в состояние рабочих. Для этого, резервный кластер переводится из режима standby в режим master. Данная операция осуществляются централизованно с помощью командной утилиты shardmanctl, никаких дополнительных ручных операций не требуется.
33.5.10.3. Восстановление ОЦОД #
Для восстановления географически удалённых узлов в ОЦОД требуется создать резервную копию основного кластера и восстановить её на данные узлы. Резервная копия может быть создана любым способом – холодная РК, РК с использованием репозитория pg_probackup. Каждый из этих способов подразумевает перенос резервной копии в ОЦОД. После восстановления каталога БД из резервной копии, запускается pg_receivewal, который подключается к специально созданному слоту репликации ведущего или резервного сегмента в РЦОД и начинает приём WAL сегментов в асинхронном режиме, записывая их сразу в каталог $PGDATA/pg_wal основного узла.
В кластере РЦОД скрипт создаёт точку синхронизации для каждого заданного периода времени. Она записывается во встроенное хранилище РЦОД и отправляется в хранилище ОЦОД. Когда точка синхронизации туда попадает, узлы резервного кластера ОЦОД проверяют наличие WAL с такой записью. При её получении всеми узлами резервного кластера ОЦОД кластерным ПО инициируется запуск сервера СУБД с синхронизацией WAL до точки синхронизации. По её достижении WAL больше не применяются. Если все узлы успешно применили записи WAL, сервер СУБД останавливается, запускается новый цикл получения WAL, проверки точки синхронизации и режима восстановления.
33.5.10.4. Переключение обратно на ОЦОД #
Чтобы переключиться обратно на ОЦОД, создаётся и переносится резервная копия кластера из РЦОД в ОЦОД, запускаются узлы в режиме резерва, после получения недостающих WAL происходит выключение узлов кластера в РЦОД и повышение узлов кластера в основном ЦОД.
33.5.11. Резервное копирование для географически распределённой системы #
В рамках географически распределённой системы для кластера РЦОД необходимо предусмотреть аналогичное хранилище резервных копий, как и для ОЦОД, а также настроить регулярную синхронизацию основного хранилища в резервное.
33.5.11.1. Хранение резервных копий в географически распределённых хранилищах #
Глубина хранения резервных копий определяется политикой резервного копирования.