Планирование топологии кластера

При планировании топологии кластера важно понимать, что может нарушить работу кластера и насколько ваше приложение толерантно к подобным нарушениям.

Работа кластера может быть нарушена в следующих ситуациях:

1. Плановое обслуживание оборудования, в том числе:
   • обновление оборудования;
   • обновление ОС, BIOS и встроенного программного обеспечения;
   • изменение конфигурации ОС;
   • обновления безопасности.
2. Внеплановое обслуживание при возникновении неисправностей оборудования или сетевой инфраструктуры.
3. Проблемы связанные с движком базы данных или пользовательской нагрузкой, например:
   • нехватка оперативной памяти;
   • недостаток места на диске.

Поведение кластера в описанных выше ситуациях зависит от его топологии. В Yandex Managed Service for PostgreSQL доступны несколько вариантов топологии кластера. Вы можете выбрать наиболее подходящий под ваши требования вариант.

Чтобы кластер из двух и более хостов оставался доступен на чтение при переключении мастера, требуется дополнительная настройка.

Варианты топологии кластераВарианты топологии кластера

В Managed Service for PostgreSQL доступны следующие варианты топологии кластера:

• Кластер с одним хостом.
• Кластер с двумя хостами.
• Кластер с тремя и более хостами.

Кластер с одним хостомКластер с одним хостом

Кластер с одним хостом — это самый дешевый и простой в работе вариант. Рекомендуется использовать его для тестовых кластеров или production-приложений, не требующих высокой доступности кластера.

Преимущества:

• Цена — такой кластер дешевле кластера из нескольких хостов (в зависимости от выбранного класса хостов).
• Простота работы — хост-мастер всегда один, поэтому приложению не нужно поддерживать переключение мастера.

Недостатки:

• На кластер из одного хоста не распространяется Соглашение об уровне обслуживания (SLA).
• Кластер из одного хоста не обеспечивает отказоустойчивость. При выходе из строя ВМ хоста-мастера кластер будет недоступен на чтение и запись до окончания работ по восстановлению ВМ.
• При аварии на хосте-мастере данные будут восстанавливаться из резервных копий. При этом возможна потеря данных, записанных между последним резервным копированием и моментом отказа хоста-мастера.

Примеры использованияПримеры использования

• Запись данных с устройства в базу данных
• Мониторинг состояния географически распределенных устройств

Кластер с двумя хостамиКластер с двумя хостами

Кластер с двумя хостами соответствует критериям высокой доступности и на него распространяется SLA. Этот вариант подходит для среднеразмерных приложений в production-окружении.

По сравнению с кластером из одного хоста кластер с двумя хостами дает следующие преимущества:

• Балансировка при чтении данных на два хоста, что ускоряет работу кластера.
• Автоматическое переключение мастера при недоступности текущего хоста-мастера. Это вызовет кратковременную недоступность кластера на запись, пока не произойдет переключение, но при этом кластер все равно будет доступен на чтение.

Примеры использованияПримеры использования

• Миграция базы данных из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
• Настройка отказоустойчивой архитектуры в Yandex Cloud

Кластер с тремя и более хостамиКластер с тремя и более хостами

Кластер с тремя или более хостами соответствует критериям высокой доступности и на него распространяется SLA. Этот вариант рекомендуется использовать в production-окружении, где предъявляются повышенные требования к доступности и производительности.

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

• Вместо синхронной репликации применяется кворумная репликация. Это ускоряет подтверждение транзакций и снижает риски рассинхронизации данных на репликах.

  Транзакция в среднем подтверждается быстрее: ее должны подтвердить хост-мастер и не менее половины хостов-реплик.

• Можно балансировать запросы на чтение между мастером и как минимум двумя репликами. Кроме ускорения работы кластера это позволяет вашему приложению отправлять запросы на чтение данных на конкретные хосты этого кластера. Это может ускорить получение данных если ваше приложение расположено в той же зоне доступности, что и хост кластера.

• Кластер будет доступен на чтение даже при мажорных обновлениях версии PostgreSQL.

Примеры использованияПримеры использования

• Создание кластера PostgreSQL для «1С:Предприятия»

Доступность кластера при разных топологияхДоступность кластера при разных топологиях

Количество хостов, указанное в таблицах, включает в себя хост-мастер и хосты-реплики, для которых используется автоматическая репликация. Хосты-реплики, для которых указан источник репликации, не учитываются.

Топология кластера	Один хост	Два хоста	Три хоста и более (N >= 3)
Доступные типы дисков	network-hdd network-ssd network-ssd-io-m3	network-hdd network-ssd network-ssd-io-m3	network-hdd network-ssd network-ssd-io-m3 network-ssd-nonreplicated local-ssd
Механизм репликации	Не используется	Используется	Используется
Роли хостов	Мастер	Мастер и одна синхронная реплика	Мастер и N-1 кворумных реплик
Доступность кластера при техническом обслуживании или выходе хоста-мастера из строя	Недоступен для записи и чтения	Может быть недоступен для записи до автоматического переключения мастера
Доступность кластера при обновлении версии PostgreSQL	Недоступен для записи и чтения		Недоступен для записи, но минимум одна реплика доступна для чтения

Доступность кластера при переключении хоста-мастераДоступность кластера при переключении хоста-мастера

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

• Подключаться к кластеру по особым FQDN:

  • Для записи используется FQDN текущего хоста-мастера — c-<идентификатор_кластера>.rw.mdb.yandexcloud.net.
  • Для чтения используется FQDN наименее отстающей реплики — c-<идентификатор_кластера>.ro.mdb.yandexcloud.net.

  Этот способ прост в применении, но основан на использовании DNS, поэтому при переключении мастера требуется дополнительное время на обновление DNS-записи.

• Указывать в конфиге приложения FQDN всех хостов кластера через запятую. При этом на чтение указывать параметр target_session_attrs=any, а на запись — target_session_attrs=read-write.

  В этом случае обновление DNS-записи не требуется. Если время переключения для вас критично, рекомендуется использовать этот способ.