Варианты развертывания Pangolin#

Pangolin поддерживает несколько вариантов развертывания с использованием разных сочетаний компонентов.

Компоненты, используемые в разных сценариях развертывания:

patroni – управляющая программа на Python, позволяющая автоматически обслуживать кластеры Pangolin с различными типами репликации.

etcd – высоконадежное распределенное хранилище параметров конфигурации, задаваемых в форме ключ/значение, используется в связке с patroni.

pgBouncer – мультиплексоры соединений (программы для создания пула соединений), позволяют уменьшить накладные расходы на базу данных в случае, когда огромное количество физических соединений ведет к падению производительности Pangolin.

В следующих подразделах представлена компиляция результатов тестирования различных конфигураций кластера на соответствие следующему набору требований:

  • функциональные требования:

    • RTO (допустимое время восстановления) = 6 минут;

    • RPO (допустимая точка восстановления) = 0.

  • нефункциональные требования:

    • 10000 tps;

    • объем БД = 10 ТБ;

    • 2500 одновременных активных подключений;

    • установка 100 новых подключений в секунду.

Односерверное решение#

Конфигурация: Pangolin + pgBouncer#

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

  • Схема Pangolin для АС, где не требуется соответствие заявленным нефункциональным требованиям (RTO = 6 минут, RPO = 0). Также возможно прерывание предоставляемого сервиса.

Ограничения:

  • Не соответствует заявленным нефункциональным требованиям.

Кластерное решение#

Конфигурация: patroni + etcd + pgBouncer#

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

  • Обеспечивается возможность достижения RTO = 6, но практическое подтверждение возможно по результатам длительной эксплуатации.

  • RPO = 0 выполняется кроме случая, описанного в недостатках решения (см. ниже перечисление ограничений).

  • Простая в конфигурировании и эксплуатации схема с минимумом потребляемых ресурсов сервера.

  • Patroni имеет внешний интерфейс для управления состоянием кластера и единую точку конфигурирования всех серверов БД, входящих в кластер.

  • Несмотря на добавление в конфигурацию дополнительного сервиса, схема остается простой для установки и настройки — pgBouncer имеет единый файл для конфигурирования и обладает простым синтаксисом настроек.

  • Позволяет гибко управлять настройками пулов соединений.

  • PgBouncer обеспечивает количество соединений большее, чем сконфигурировано в БД.

  • PgBouncer, позволяет обеспечить стабильную скорость обработки транзакций даже в случае превышения лимита возможных одновременных подключений к БД, согласно конфигурации.

  • В pgBouncer можно реализовать автоматическое перенаправление трафика к новому ведущему серверу на основе информации из etcd.

    Примечание:

    Использование схемы с pgBouncer имеет смысл, когда планируемое максимальное количество подключений max_connections превышает число, рассчитанное по формуле 3хCPU (включая виртуальные (hyperthreading) ядра). Например, для типовой конфигурации промышленного сервера (28 CPU) рекомендованное число подключений на уровне БД — 84, если требуется больше, следует использовать pgBouncer.

Ограничения:

  • RPO = 0 обеспечивается только в случае использования синхронной репликации и наличия механизма обработки timeout на стороне клиентского предложения, в случае следующих обнаруженных недостатков: RPO=0 не выполняется при использовании асинхронной репликации возможно возникновение ситуации «split brain».

  • При использовании асинхронной репликации с pg_rewind возможны расхождения в данных между ведущим и ведомым узлом.

  • При использовании синхронной репликации c включенным pg_rewind необходима обработка timeout на стороне клиента, так как запросы не будут завершаться до получения ответа от ведомого сервера.

  • При использовании синхронной репликации с отключенным pg_rewind данные, полученные до переключения кластера на новый active, останутся только на «старом» active.

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

  • Клиентское приложение должно уметь работать с БД в режиме транзакций в соответствии с рекомендуемыми настройками pgBouncer.

  • Для использования API v3 компонентом patroni для коммуникации c etcd версия пакета etcd должна быть не ниже 3.3.

Конфигурация: patroni + etcd + pgBouncer + Балансировщик нагрузки#

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

Те же, что и для конфигурации patroni + etcd + pgBouncer, а также:

  • предоставляет единую точку входа для клиентских соединений;

  • RPO = 0 выполняется, так как балансировщик автоматически перенаправит трафик от клиентов на ведущий сервер в соответствии с разработанной стратегией;

  • балансировщики нагрузки промышленных стендов размещаются в соответствии с принципами георезервирования;

  • позволяет реализовать большинство стратегий уровня L3/L7, кроме стратегий прикладного уровня; например, балансировку трафика с учетом информации от БД.

    Примечание:

    Использование схемы с pgBouncer имеет смысл, когда планируемое максимальное количество подключений max_connections превышает число, рассчитанное по формуле 3хCPU (включая виртуальные (hyperthreading) ядра. Например, для типовой конфигурации промышленного сервера (28 CPU) рекомендованное число подключений на уровне БД — 84, если требуется больше, следует использовать pgBouncer.

Ограничения:

  • Клиентское приложение должно уметь работать с БД в режиме транзакций в соответствии с рекомендуемыми настройками pgBouncer.

  • Разработка алгоритма балансировки может потребовать понимания работы сетевых протоколов и знания SLA сетевой доступности между ЦОД-ами.

  • Возможно, потребуется корректировка алгоритма постфактум, на основе логов работы в реальном окружении. Клиенты должны будут реализовать функциональность переподключения к кластеру и повторной отправки запросов.

  • Балансировщик нагрузки является черным ящиком по отношению к потребителям, что может привести к увеличению времени понимания и исправления проблемы с балансированием запросов.