Заряжай Patroni. Тестируем Patroni + Zookeeper кластер (Часть первая)

[bak]

Можно обойтись без zookeeper, с недавних пор patroni умеет работать на чистом raft, без внешних зависимостей.

[gecube]

Здесь нам на помощь и может прийти Zookeeper, который ничего не пишет на диск и хранит все данные в памяти. Такой вариант оптимален в ситуации, когда не на всех серверах есть SSD, зато RAM хватает.

Are you sure? Потому что если зукипер хранит не только результаты выборов («кто главный?»), а конфигурационные данные кластера, то они обязаны бекапиться на диск по очевидным соображениям. Иначе после полного рестарта зукипера мы получим обнуленый кластер патрони

Касательно инструкции — для лабы сойдёт. Для полноценного сетапа — точно нет. Промоделировать же последний было бы надежнее и максимально близко к проду было бы возможно при помощи того же вагранта.
Я уж не говорю о том, что не рассказано о подводных камнях Настройки патрони и постгрес, а их там достаточно

[n_bogdanov]

Более чем согласен — диски Zookeeper использует для хранения итогов выборов, ключей и значений базы, своих снапшотов и бинарных логов. Причём до недавнего времени для удаления снапшотов требовался отдельный внешний скрипт.

[floitet]

Спасибо за уточнение по Zookeeper. Действительно, он пишет на диск, и в некоторых гайдах к нему также как и к Etcd рекомендуют приложить SSD. Но в доке самого Zookeeper'а рекомендаций про SSD я не нашел и более того они уверяют что Yahoo! сервера с Zookeeper работают на HDD. Также наши нагрузочные тесты показали что при определенном уровне нагрузки Etcd начинает давать ошибки по IO, а Zookeeper продолжает нормально работать. Наверняка утверждать, что Zookeeper лучше в этом отношении чем Etcd, пожалуй, не возьмусь, но из наших тестов разница была заметна. В статье этот момент поправлю.
Про саму инструкцию в целом — да, конечно, раскрыты только самые базовые вещи. Но я, в общем-то, и ставил себе целью сделать туториал именно для тех кто только вкатывается и хочет быстро потестировать решение у себя на локальном стенде.

[n_bogdanov]

Не понятно почему автор статьи не хочет использовать готовый образ SPILO от разработчиков Patroni.

[floitet]

Видел этот проект да, но у меня была задача развернуть кластер именно в Docker Swarm'e. Возможно, я не до конца разобрался со Spilo, но я тогда не нашел там гайдов которые бы относились именно к Swarm'у. Да и в принципе хотелось понимать с основ, как работает решение.

[ivandasch]

К сожалению вы ошиблись, zookeeper пишет и в транзакционный лог, и делает снимки данных (snapshots). Скорость диска для zk критически важна.

[floitet]

Да, здесь вы правы, но я добавил ещё некоторые свои соображения на эту тему в ответе на комментарий выше.

[Vitaly2606]

Также наши нагрузочные тесты показали что при определенном уровне нагрузки Etcd начинает давать ошибки по IO

Для нагруженной, и тем более боевой среды, не стоит размещать данные etcd на тех же дисках что и база данных (как и любые другие сервисы интенсивно использующие ресурсы дисковой подсистемы).

Сам же etcd кластер, если он выделен только под кластер patroni, не требует ssd, и может стабильно работать и на обычных дисках, так как нагрузка от Patroni на etcd совсем не большая.

Если в Вашей инфраструктуре множество (сотни и тысячи) кластеров Patroni, и вы используете общий — выделенный кластер etcd, тогда желательно использовать ssd диски, а так же выделить уже больше ядер CPU и оперативной памяти.