Как стать автором
Обновить

Моделирование отказоустойчивых кластеров на базе PostgreSQL и Pacemaker

Время на прочтение 12 мин
Количество просмотров 11K
Всего голосов 29: ↑27 и ↓2 +25
Комментарии 53

Комментарии 53

Боже упаси вас употреблять слова master и slave.
Вокнутые заклюют, к сожалению.
Поэтому я вместо них использую слова «мастер» и «раб». :)
«хозяин» и «раб» же!

Не совсем так. Это в английском master это хозяин, причем, как я понимаю, ремесленной мастерской в феодальные времена. А в американском… Может читали Марка Твена «Приключе́ния Ге́кльберри Фи́нна»? Книжка про то как белый пацан-беспризорник путешествовал по реке на плоту вместе с беглым негром. Так вот, негр постоянно обращается к пацану "мастэ". Так вот это оно и есть, Гек никаким хозяином негру не был.

сервиторы :)
Лучше «барин» и «холоп»

Холоп это военнопленный, наихудшая форма рабства на Руси. Потом так стали называть и обычных крестьян. А полным аналогом "мастэ" будет господин он же господарь. Это и было обозначение рабовладельца, которое потом перешло в обычное обращение. Собственно когда цари стали себя наименовать "господарь всея Руси" это означало что всё остальное население, включая дворян, это рабы по отношению к царю. При великих князьях такого разумеется не было.


Ну а если серьезно, почему я использовал "мастер" и "раб", потому что, понятно, английские термины, которые приняты много где, в том числе и Pacemaker, это master и slave. И если слово "мастер" по русским падежам нормально склоняется, то как "слейв" склоняется по падежам мне не понравилось.

Я использовал github.com/ClusterLabs/PAF но пришлось отказаться — после перехода на посгтрес 12 паф работал до первого переключения с мастера на слейв, после чего репликация накрывалась медным тазом и все приходилось чинить руками. Как у вас пейсмейкер мониторит инстансы постгреса и как восстанавливается репликация при падении мастера — мастер просто падает и ждет когда админ поднимет репликацию к новому мастеру руками или репликация поднимается автоматически средствами пейсмейкера?
Да, версия 2.3
Про 12 postgres. Тестовый стенд, про который статья, работает пока только с CentOS 7 и PostgreSQL 11. Дело в том что разработка была начата еще в те времена. А потом было важно добиться стабильного результата до перехода на новые версии. Но проект был не в приоритете, отвлекали на другие, поэтому разработка была затянута. Сейчас потихоньку начну апгрейдить на новые версии. Знаю только, что поддержка 12 PostgreSQL у PAF появилась довольно поздно: 10 марта 2020 года в версии 2.3.0.

Про мониторинг постгресса. Pacemaker мониторит его с помощью PAF. А тестовый стенд с помощью psql и sql запросов, одним он пишет текущее время в таблицу на мастере, вторым считывает из этой таблице у раба. Тем самым при тестировании на отказоустойчивость тестовый стенд удостоверяется, что все действительно работает.

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

Если первый вариант. Три узла, например, мастер и два раба. При отказе мастера один из рабов становится новым мастером и на него переходит float IP мастера. Все это делается автоматический силами Pacemaker. У второго раба репликация настроена на float IP и переподключение репликации на новый мастер осуществляется автоматический силами PostgreSQL. И обычно так и происходит. Но бывают ситуации когда нет, они описаны в разделе «выявленные при тестировании недостатки», автор PAF уже заинтересовался ими, чтобы исправить. Дело там встало в том, чтобы перевести README на английский и предоставить ему этот стенд. Займусь этим завтра. :)

Если речь о том, чтобы автоматический вернуть отказавший узел в кластер, то не pacemaker'а ума это дело. :) Прежде чем возвращать отказавший узел надо сначала проанализировать отказ в работе и поставить диагноз, понять причину и устранить, например заменить глючное железо. Все это в компетенции исключительно сисадмина. И только после этого уже возвращать узел в кластер. Поэтому pacemaker никогда не делает этого автоматический. Но в случае этого тестового стенда, тестирующие скрипты, которые имитируют неисправности, знают как после этого узел возвращать в работоспособное состояние. Поэтому в тестовом стенде возвращение узлов, которые были «неисправными» и поднятие на них репликаций (а в случае tuchanka1 и переезд мастера обратно) происходит автоматический.
В моем случае была простая схема мастер-слейв. При тестировании я отключал мастер (просто делал shutdown, база постгреса и сама нода при этом находятся в рабочем состоянии), пейсмейкер начинает миграцию и поднимает роль мастера на слейве. При включении бывшего мастера, я сбрасывал аварийный триггер ресурсов через cleanup (так как и нода и инстанс постгреса находятся в рабочем состоянии после старта) и пейсмейкер должен был выставить ноде роль слейв и начать процедуру восстановления реплики с нового мастера. Но реплику поднять он не мог, выкидывал ошибку и переводил ресурсы снова в аварийное состояние. Приходилось поднимать реплику руками через pg_basebucket.

Я проверил то, про что вы написали (PostgreSQL 11 и соответственно старый pacemaker и paf из Centos 7). При старте OS у меня, разумеется, узел в кластер автоматический не добавляется, по описанной выше причине, чтобы не был циклического рестарта при какой-нибудь неисправности. При корректном выключении:


pcs cluster stop --wait
shudown now
включение и ожидание загрузки OS
pcs cluster start

Репликация поднимается автоматический, да еще и мастер потом возвращается на место, если в настройках это указано (так у меня настроена tuchanka1).
В случае если просто набрать shutdown now, то после pcs cluster start у меня всё тоже поднялось без проблем, даже не надо было запускать cleanup так как ошибок не было. Поэтому надо разбираться в том, какие у вас были ошибки при подключении репликации и с чем они были вызваны. Может быть вы shutdown now набрали слишком поспешно, до того как репликация была установлена и тем самым у вас произошло раздвоение временных линий? Или быть может проблемы связаны с новым PostgreSQL 12 и новым модулем PAF. Когда до этого дойдет дело, протестирую.

Проблема была только на версии постгрес 12 с новой схемой потоковой репликации. Использовались — дебиан 9 с самосборными пейсмейкером 2.0.4 и коросинком с дебиан сида, версия PAF 2.3 с заявленной поддержкой постгрес 12 (причем на тот момент в документации PAF про настройку для 12ой версии была буквально одна строка, пришлось чуть ли не исходники читать).
Также вместо pcs я использовал crm. Репликация была в порядке, проверял перед выключением. Даже и если ошибок не было, пейсмейкер поднимал репликацию (тк слейв в любом случае отставал от нового мастера по времени) и выкидывал ошибку.

То что старый мастер отставал от нового мастера по времени, это понятно. В этом случае он повесится на репликацию только при условии:


  • Либо есть какой-то архив журнала транзакций и он сможет используя его догнать новый мастер.
  • Если архива нет, то в настройках postgresql.conf wal_keep_segments должен быть достаточно большим, чтобы хранить там все сегменты журнала транзакций необходимые для того чтобы старый мастер догнал новый. У меня при тестировании нагрузка небольшая, хватает wal_keep_segments = 1, при реальной нагрузке может потребоваться больше. А при реальной поломке даунт тайм будет такой большой, что там все равно восстанавливать придется либо через pg_basebackup или pg_rewind.

Но весь этот разговор пока ни о чём и гадание на кофейной гуще, потому что вы не пишите какую он выдавал ошибку. :) Что писал pacemaker (paf), что было в логах postgresql.conf.

Точно уже не помню, ошибка была «invalid record length at 0/1644F08: wanted 24, got 0»

Пока ничего сказать не могу. Придется подождать когда в стенде появится PostgreSQL 12.

Спасибо за пост, очень интересно!
А вы не смотрели в сторону Patroni? Это популярное open source решение, основанное на той же идее кворума с использованием DCS (etcd, consul и т.п.). Успешно применяется в продакшн. Здесь на Хабре было много статей про этот проект. Я не рекламирую, просто интересно чем он не подошёл именно вам.

Все это начиналось в 2018 году, рассматривались следующие технологии:


  • Pacemaker (с модулями pgsql или pgsqlms(PAF)). Это стандартное решение от RedHat для отказоустойчивых кластеров на базе RedHat.
  • RepMgr — решение от 2nd Quadrant, это один из соавторов PostgreSQL
  • Patroni — нечто написанное веб-программистами для веб-программистов и активно рекламируемое на форумах веб-программистов. :)

В чем Pacemaker показался мне предпочтительнее, чем Patroni:


  • Два года назад у Patroni был заметно беднее функционал. Я не припомню, чтобы там была хорошая, продуманная защита от split-brain. Хотя за два года многое могло изменится.
  • Поддержки Patroni у RedHat нет. Patroni нет ни в официальном репозитории, ни в EPEL, ни PostgresQL репозитории пакетов. На официальном сайте Patroni тоже нет rpm пакетов. Предполагается что Patroni будет либо скачиваться через git и потом раскладываться и настраиваться по системе вручную. Либо устанавливаться через pip, но потом все равно недостающие в pip инсталяции файлы, например patroni.service для systemd, нужно будет скачивать вручную через git, устанавливать и настраивать.
  • В Pacemaker все идет в одном флаконе. Да, это несколько пакетов, но все они вместе разрабатываются одной командой разработчиков и вместе тестируются. Это единое решение с единой документацией (лучшая документация по Pacemaker на сайте RedHat, кстати, а не на сайте самого Pacemaker), единой утилитой мониторинга и управления всеми компонентами pcs и т.д. А Patroni подразумевает солянку из разный приложений разрабатываемых отдельно. Отдельное распределенное хранилище данных ETCD (причем кворум реализован на нём), отдельно надо что-то придумывать для указания на действующие сервисы (consul?), все это как-то согласовывать и следить при обновлениях, чтобы это согласование между ними не расстроилось.
  • В Pacemaker есть команды для администрирования ресурсов (перемещения их по узлам). Например с помощью команды pcs resource ban можно заставить сервисы покинуть нужный узел для обслуживания, например чтобы там осуществить обновление софта yum update, перезагрузить OS и вернуть узел в кластер (разбанить) с помощью pcs resource clear. Ничего подобного Patroni не предусмотрено.
  • Pacemaker решение универсальное. На его базе можно не только PostgreSQL делать HA, но и другие ресурсы. Например веб сервера и другие компоненты. Я понимаю, что сейчас модно всё, кроме собственно баз данных, размещать в Kubernetes. Но на мой взгляд это именно что мода вызванная назойливым маркетингом. Из разговоров с сисадминами создается впечатление, что отказов в оказании услуг населению вызванных проблемами с Kubernetes было больше, чем проблемами с сервисами, high availability которых Kubernetes должен был бы обеспечивать.

Но при этом Patroni нравится сисадминам и они сейчас разрабатывают альтернативное решение на нём. Я пока еще не видел ни само решение, ни тестовый стенд, на котором можно было бы проверить какие отказы данное решение выдерживает, ни, тем более, систему автоматического тестирования решения на Patroni. А автоматическое тестирование оказалось очень важно. Ведь изначально была полная уверенность в Pacemaker и система автоматического тестирования разрабатывалась исключительно как демонстрация для начальства. Но потом оказалось, что она в состоянии обнаруживать проблемы pacemaker и postgresql, которые возникают либо маловероятно, либо в экзотических случаях и поэтому не были отловлены при обычном тестировании. А после обнаружения их можно уже исправлять.


Так что я надеюсь что спустя какое-то время в этом самом блоге от Домклик появится статья уже от сисадминов про то, какую систему на Patroni они разработали, какие отказы она выдерживает, а какие и нет. Ну и самое интересное, а как же они её тестировали? :)

Patroni — нечто написанное веб-программистами для веб-программистов и активно рекламируемое на форумах веб-программистов. :)

Написанное DBA (https://github.com/CyberDem0n) для DBA. Пример.



Я не припомню, чтобы там была хорошая, продуманная защита от split-brain.

Два года назад разработчики рассказывали на митапе про patroni (в том числе и про split-brain)



Patroni нет ни в официальном репозитории, ни в EPEL, ни PostgresQL репозитории пакетов.

Вот же https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-7-x86_64/patroni-1.6.5-4.rhel7.x86_64.rpm


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

Вот пример: Patroni и stolon: инсталляция и отработка падений

Ну вы что, поспорит хотите? :)


Написанное DBA (https://github.com/CyberDem0n) для DBA. Пример.

https://github.com/zalando/patroni
Если посмотреть в каком окружении содержится patroni, то видно, что это сообщество веб программистов. :) Кому еще придет в голову устанавливать софт через pip, устанавливать PostgreSQL внутрь Кубернетись и т.д? :) Что касается КиберДемон, то он и не скрывает, что он пришел из веб разработки, на 9й секунде ролика. :) Хотя сейчас предпочитает себя называть DBA, но прошлого не скроешь. :)


Два года назад разработчики рассказывали на митапе про patroni (в том числе и про split-brain)

На 16:46 рассказывают теорию, причем терминологию (STONITH) используют из Pacemaker. :) На 18:19 собственно правильная картинка. Есть облако из patroni (кстати их не обязательно должно быть три) и есть отдельное облако из ETCD (а вот их должно быть нечетное число) и собственно на ETCD (а не патрони) и реализуется кворум. Т.е. для этого шесть серверов поднимать? :) Некоторые так и делают. И тогда непонятно, как это все будет работать в случае изоляции ETCD облака от patroni облака? :) На мой взгляд правильнее было размещать ETCD на тех же серверах, где и патрони. В pacemaker, например, каждый узел в себе хранит копию кластерных данных, а не во внешнем облаке. И дальше рассказывается про простенький механизм, когда один патрони пишет временные метки, а остальные читают. Знал я всё это. Именно это я и называл:


Я не припомню, чтобы там была хорошая, продуманная защита от split-brain.

В самом patroni её и нету, по сути, там вся надежда на ETCD. А могут быть и другие сервисы для хранения: косул и еще какой-то. И все их надо анализировать на защиту от split-brain и возможные подводные камни.


Вот же https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-7-x86_64/patroni-1.6.5-4.rhel7.x86_64.rpm

Раньше, до Ковид-19, не было. :) Файл там датирован 6 августа 2020 года, наверное ребята из PostgreSQL недавно добавили. В самом же patroni, в документации ни слова об rpm, рекомендуют pip или git (очевидно, что веб-программисты). Ни своих rpm. RPM советуют их брать из сторонних источников.
https://github.com/zalando/patroni/issues/877


Вот пример: Patroni и stolon: инсталляция и отработка падений

Да, это интересная ссылка. Видно, что человек по настоящему заморачивался и подробно всё разбирает, правильно делая акценты на нюансах, сложностях и потенциальных ошибках при дизайне. Сам ролик и докладчик мне понравились. Но вы меня неправильно поняли. Я жду тестовый стенд нет от Максима Милютина из Озона, и то, как это всё он придумал, а от наших сисадминов, так, как они всё придумали и это уже проверять. Потому что на patroni все можно сделать очень по разному. И именно поэтому я не вижу смысла делать самому такой тестовый стенд, потому что я могу придумать как-то по другому.

Вы так говорите, как будто веб-разработчики это второй сорт. Да, есть такие, которые делают сайты-визитки и на этом их познания в общем-то заканчиваются. Но есть и сложнейшие распределённые системы, серверная часть которых состоит из тысяч узлов и компонентов, обрабатывающих десятки и сотни тысяч запросов в секунду. Это тоже называется веб разработкой, потому что наружу торчит веб интерфейс в виде REST API. И DBA, обслуживающие эти веб-приложения, тоже неслабо напрягаются.


Насчёт запуска СУБД внутри контейнеров — ну так это же просто удобно! Я давно полностью перешёл на деплой в контейнерах, и в продакшн и для разработки, и даже дома. Собираю свои образы со всем необходимым внутри. Все расширения, все библиотеки нужных версий, все утилиты и т.д. И мне в принципе плевать что за дистрибутив, какие пакеты и т.п. установлены на хосте, потому что я всё тащу с собой внутри контейнеров. А оверхед практически нулевой. Ну это дело вкуса, конечно. Мне понравилось и я не хочу возвращаться обратно.

Вы так говорите, как будто веб-разработчики это второй сорт.

Вы так говорите, словно я как будто бы говорю, что веб-разработчики второй сорт. :) И пытаетесь спорить со мной по тем с вашей стороны спорным моментам, которые вы же сами для меня и придумали. Нет. Если вам интересная моя действительная точка зрения, то веб-разработчики это параллельная ветвь эволюции, альтернативная цивилизация. Обычные программисты зародились где-то в середине прошлого века (если не считать Аду Байрон), перфокарты, релейные компьютеры и всё такое. Породили их инженеры, математики. Прошли свой эволюционный путь, создали свою цивилизацию, культуру, парадигмы программирования, понятия о добре и зле. Веб-разработчики появились гораздо позже, произошли они от того что веб-дизайнеры, которые были по сути гуманитарии, программировали что-то для своих нужд на php, perl и прочих языках с нестрогой типизацией, которых нормальные программисты избегали как черт ладана. Но не смотря на всю иронию и скепсис обращенный в их адрес веб-разработчики сумели доказать свою эволюционную приспособленность, главным образом тем, что они захватили и удерживают большУю часть рынка услуг и труда (а в России так и бОльшую). И заметно как тонкие клиенты повсеместно вытесняют толстые. Возникнув независимо веб-разработчики создали свою альтернативную цивилизацию, культуру, свои парадигмы. На нормальных программистов они похожи примерно так же, как головоногие на приматов. Но не смотря на всю иронию можно только уважительно относится к их способности отжимать рынок. :) Есть чему поучится, проанализировать почему так происходит.


Насчёт запуска СУБД внутри контейнеров — ну так это же просто удобно!

Когда я вижу, что сисадмины опять суетятся по утру с красными глазами, я понимаю, что у них опять проблемы с Кубернетисом. :) Это был легкая ирония, а сейчас объясню свой сарказм по поводу СУБД внутри контейнеров. Если читать документацию к докеру, там буквально на первых страницах объясняются принципы использования контейнеров. Один из них, все данные связанные с логикой работы сервиса внутри контейнера должны храниться вне контейнера, либо на серверах баз данных, либо на внешних (по отношению к контейнеру) разделах, которые в него мантируются. А в случае облаков Кубернетис с его "отказоустойчивостью" и балансировкой нагрузки тут уже, наверное, речь идет сетевых файловых системах. Но не суть важно, PostgreSQL это база данных и по самим принципам создания сервисов в контейнерах она должна быть расположена вне контейнеров. :)


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

Извините, но ваша теория параллельной вселенной для веб-разработчиков — полная лажа. При чём тут вообще Perl и PHP? Все серьезные веб приложения пишутся на серьезных языках программирования, как например Java, или её клон С#. Весь современный энтерпрайз — это веб приложения и веб сервисы. Участие в подобных проектах требует высочайшего уровня подготовки и опыта. Многопоточная обработка в отдельных сервисах, межсервисное взаимодействие, шины и очереди сообщений, секьюрити, распределенные транзакции и прочее, о чём вы, судя по всему, даже не подозреваете. Вы, похоже, застряли где-то на рубеже 90х — 00х с вашими представлениями о разработке приложений.


Насчёт контейнеров. Само собой все персистентные данные хранятся на дисках вне контейнера. Внутри контейнера интересен только код. Во время создания контейнера в его ФС монтируются любое количество внешних файлов, директорий и секретов. Грубо говоря, к примеру, каталог PGDATA, тейблспейсы, отдельно может быть каталог pg_wal, файл .pgpass и т.д. Хотите обновить версию сервера или может быть какой-то extension, нет ничего проще. Просто пересоздаём контейнер с теми же внешними точками монтирования, но уже с другим софтом внутри, указывая другой образ.

Извините, но ваша теория параллельной вселенной для веб-разработчиков — полная лажа. При чём тут вообще Perl и PHP?

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


Веб-разработчики появились гораздо позже, произошли они от того что веб-дизайнеры, которые были по сути гуманитарии, программировали что-то для своих нужд на php, perl

Речь шла именно о том, от чего они произошли, что было началом эволюции. Когда я с этим столкнулся, это были именно что php и perl, причем php только начинал набирать обороты, видать в начала был только perl. И, конечно, флэш, я забыл его упомянуть, весь крутой фронтэнд писался на нем. Java появилась позже, причем для написания апплетов, именно как конкурент флэшу, но даже эту конкуренцию джава проиграла. ДжаваСкрипт появился после джавы как идея решать те же задачи, но без запуска апплетов и виртуальной машины. C# появился после того, как Sun подала в суд на M$, когда те в своей привычной манере стали реализовывать Java несовместимой с оригиналом Sun. Да, сейчас все сильно эволюционировало и изменилось. В конторе почти все веб-разработчики и на чём они сейчас пишут и что сейчас майнстрим я в курсе, вы го ланг забыли упомянуть, питон и руби на рельсах. :) Вы слишком молоды и слишком мало знаете, чтобы считать что из того что я пишу лажа, а что нет.


о чём вы, судя по всему, даже не подозреваете.

Опять же в силу вашей собственной ограниченности вы делаете ложные выводы что я знаю, а что нет. И приписываете это мне. Да вы правильно перечислили, какие сложности возникают в микросервисной архитектуре, собственно поэтому раньше программировали по другому, потому что так проще программировать без ошибок. Вот только мало кто умеет все эти сложности микросервисной архитектуры реализовывать без проблем. Громкие слова выучили, а нарушений data integrity сплошь и рядом. Обычно эти проблемы решаются тем, что когда устраиваются на работу стараются попасть проект который только начал разрабатываться, а когда проект доходит до прода все стремительно начинают искать новую работу. :)


Само собой все персистентные данные хранятся на дисках вне контейнера. Внутри контейнера интересен только код. Во время создания контейнера в его ФС монтируются любое количество внешних файлов, директорий и секретов. Грубо говоря, к примеру, каталог PGDATA, тейблспейсы, отдельно может быть каталог pg_wal, файл .pgpass и т.д.

Да тут вы подтвердили мои слова. А в случае продакшина исползуются облака кубернетись. Там то как вы мантируете? Сетевая файловая система? NFS? CephFS?


Хотите обновить версию сервера или может быть какой-то extension, нет ничего проще.

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

Гослинг разрабатывал Джаву для бытовых устройств. У Sun даже был карманный компьютер, который работал на джаве еще в 90-х годах. Но проект не взлетел. Никакой специальной ориентации на веб у этого языка не предполагалось. Если быть точным, то джава и ПХП появились одновременно в 95-м. Уже позже люди додумались до апплетов. Я прекрасно помню эти времена, т.к. я сам писал CGI скрипты ещё раньше. Это всё развивалось на моих глазах, и прошло через мои руки в продашне, и это было классное время. JavaScript же не имеет ни малейшего отношения к Java, по-моему это знают даже дети.
Мне жаль что в вашей компании так безалаберно относятся к найму сотрудников, и оттого у вас сложилось это мнение о какой-то касте ущербных "веб-разработчиков", пишущих на флеше. Зато, наверное, им можно почти ничего не платить, не так ли? Я тоже знаю многих фронтендеров, которые не особо вникают в процессы, происходящие по ту сторону HTTP запроса на сервере. Но нельзя же всех под одну гребёнку! В моей команде три PhD Computer Science (доктора наук по нашему), больше половины программеров в команде за 50 лет, с огромным опытом в каких угодно областях программирования, есть у меня и старики которые еще застали перфокарты, и есть активные контрибьюторы в ядро Linux и другие проекты, результатами труда которых вы пользуетесь каждый день. И все вместе мы сейчас работаем над сложным веб-проектом, потому что в наше время никому не интересно саппортить и обновлять софт на стороне клиента. То есть технически мы все веб-программисты.


Про контейнеры даже продолжать не охота, но уж скажу. Представьте себе, SSD тоже можно монтировать как и NFS. Не знаю как в вашей компании, а в моей можно хоть 50 ТБ SSD подключать одним кликом к виртуальным машинам.

Про контейнеры даже продолжать не охота, но уж скажу. Представьте себе, SSD тоже можно монтировать как и NFS. Не знаю как в вашей компании, а в моей можно хоть 50 ТБ SSD подключать одним кликом к виртуальным машинам.
Все можно, но зачем? В общем случае данными PGDATA может пользоваться только Postgress и он считает что что он эксклюзивный пользователь этих файлов. Вы не можете переключаться с одной версии постгресса на другую (из разных контенеров) и обратно и серьезно надеяться что не наломаете дров… Каким боком тут нужен контейнер? Просветите, просто не вижу разумных сценариев использования в продакшене.
Насчёт запуска СУБД внутри контейнеров — ну так это же просто удобно! Я давно полностью перешёл на деплой в контейнерах, и в продакшн и для разработки, и даже дома. Собираю свои образы со всем необходимым внутри. Все расширения, все библиотеки нужных версий, все утилиты и т.д. И мне в принципе плевать что за дистрибутив, какие пакеты и т.п. установлены на хосте, потому что я всё тащу с собой внутри контейнеров.
Как вы следите за тем чтобы все было проапдейтчено внутри контейнера: и СУБД и зависимости?

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


Для обновления минорной версии достаточно простого пересоздания контейнера с нового образа. Они гарантированно бинарно совместимы. Для мажорных апдейтов (типа 11->12) требуется сначала прогнать промежуточный контейнер с pg_upgrade.


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

У Sun даже был карманный компьютер, который работал на джаве еще в 90-х годах.

То что он был у Sun это не означает, что он был где-то еще. :)


Никакой специальной ориентации на веб у этого языка не предполагалось.

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


Я прекрасно помню эти времена, т.к. я сам писал CGI скрипты ещё раньше.

На чём? Неужели на C#?


JavaScript же не имеет ни малейшего отношения к Java, по-моему это знают даже дети.

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


Представьте себе, SSD тоже можно монтировать как и NFS. Не знаю как в вашей компании, а в моей можно хоть 50 ТБ SSD подключать одним кликом к виртуальным машинам.

Вы опять удивительным образом не можете прочитать то, что вам не нравится. Неужели… даже не хочется называть это слово, как называется такое поведение. Я же несколько раз говорил про облака Кубернетис. Облако подразумевает несколько узлов, между которыми могут перемещаться поды. Это делается как для отказоустойчивости, так и для балансировки нагрузки. Поэтому точно так же не получится.


Мне жаль что в вашей компании так безалаберно относятся к найму сотрудников, и оттого у вас сложилось это мнение о какой-то касте ущербных "веб-разработчиков", пишущих на флеше.

А вот это было с вашей стороны особенно подло. Вы переврали мои слова, я никогда веб-разработчиков не называл и не считал ущербными. Теперь у меня такое мнение сложилось только о вас и вовсе не потому что вы называете себя "веб-разработчик". Да вы еще попытались, между делом, очернить мою компанию.


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


А вы не смотрели в сторону Patroni? Это популярное open source решение, основанное на той же идее кворума с использованием DCS (etcd, consul и т.п.). Успешно применяется в продакшн. Здесь на Хабре было много статей про этот проект. Я не рекламирую, просто интересно чем он не подошёл именно вам.

Это был ваш провокационный вопрос с целью развязать холивар про Patroni и провести рекламную компанию в статье, которая никакого отношения к Patroni не имеет, статья была про то как можно и искать и находить недостатки в Pacemaker. Поэтому:
Первое, завязывайте здесь с любым самопиаром и рекламой Patroni. Это оффтопик.
Второе, обратите внимание на моё предложение КиберДемону, которое я сделал ниже. Я написал инструмент, с помощью которого тестировать Pacemaker. Форкните проект, замените Pacemaker на Patroni, покажите всему миру насколько он круто работает. Разумеется показывать это надо будет на всех заявленных поддерживаемых хранилищах данных: ETCD, Consul, ZooKeeper. Это будет реальный вклад, а не пустое сотрясение воздуха громкими словами, которые все равно не предоставляется возможность проверить. Уж с вашим заявленным опытом управления тремя докторами наук переписать под Patroni будет пару раз плюнуть. Странно что вы раньше, до меня, не догадались это сделать.


А пока этого не сделаете, больше мне говорить с вами не о чем.

Я не имею никакого отношения к проекту Патрони и нигде его не пиарю. Также я ни разу не упоминал что оркестрация кластера производится Кубером.
Мой вопрос бы задан с целью узнать причину велосипедостроения и планы его развития, а также рассмотреть возможность испытания вашего продукта в тестовой лабе.


Извиняюсь за "подковырочку" про вашу замечательную компанию, однако это позволило вывести вас на чистую воду. Выяснилось, что вы считаете Java языком веб-апплетов, вроде Флеша, а также считаете JavaScript его близким родственником (на основании того что оба используют синтаксис Си и имеют похожее название). Это просто эпично! Надеюсь, ваш босс этого не увидит, иначе ждите беды.


Теперь же совершенно очевидно что у вас в голове каша и следовательно от ваших поделок нужно держаться подальше. Просто стыдно не знать такие элементарные вещи. Вы даже не представляете себе какую анти-рекламу делаете этим вашей компании. Что таки подтверждает моё предположение о некоторых проблемах в системе найма и обучения сотрудников.

Выяснилось, что вы считаете Java языком веб-апплетов, вроде Флеша, а также считаете JavaScript его близким родственником (на основании того что оба используют синтаксис Си и имеют похожее название). Это просто эпично! Надеюсь, ваш босс этого не увидит, иначе ждите беды.

Как же достало ваше враньё. Нет, я так не считаю и никогда так не считал. Я такого не писал и вы осознанно врёте приписывая свой собственный бред мне. А значит и всем остальным вашим заявлениям можно не верить.

Если посмотреть в каком окружении содержится patroni, то видно, что это сообщество веб программистов. :)

IBM, RedHat(ещё до того как был куплен IBM), Morgan Stanley, Bloomberg, Adobe, Турецкие электрические сети. Это только маленькая часть компаний (которые я могу назвать публично) и использующие Patroni. Сообщество веб программистов говоришь? Ок.


он и не скрывает, что он пришел из веб разработки, на 9й секунде ролика :) Хотя сейчас предпочитает себя называть DBA, но прошлого не скроешь. :)

Если что, по образованию я вообще Физик.


причем терминологию (STONITH) используют из Pacemaker. :)

Можно конечно изобрести новую терминологию, вот только зачем?


и есть отдельное облако из ETCD (а вот их должно быть нечетное число) и собственно на ETCD (а не патрони) и реализуется кворум.

Предлагаете имплеменитровать Raft, Paxos или ZAB с нуля и облажаться? ОК.


Т.е. для этого шесть серверов поднимать? :)

Каждый решает сам. Никто не запрещает запускать Etcd на тех же нодах что Patroni.
Есть второй вариант, держать один кластер Etcd и с ним будут работаеть десятки и сотни кластеров Patroni.


В самом patroni её и нету, по сути, там вся надежда на ETCD. А могут быть и другие сервисы для хранения: косул и еще какой-то. И все их надо анализировать на защиту от split-brain и возможные подводные камни.

Успокойтесь, всё уже проанализировали до вас.

Успокойтесь, всё уже проанализировали до вас.

Когда единственный аргумент, который может предоставить разработчик отказоустойчивой системы, вот такой, это вызывает еще больший скепсис. :)

Реально, etcd, consul, zookeeper используются в таком множестве проектов, что если там проблемы с кворумом… нам реально пора заворачиваться в простынку и ползти в направлении кладбища. Наверняка, уже были тесты на отказы озвученных систем и можно с ними ознакомиться. Или, в конце-концов, самому проверить кодовую базу. Поэтому реально — вместо новой имплементации алгоритмов кворума и консенсуса — лучше взять озвученные три решения и сделать их ядром своего продукта.

По сути это звучит так, что для того чтобы поднять кластер отказоустойчивых PostgreSQL надо поднять еще один кластер отказоустойчивых неSQL БД. :) И то как это будет работать, тут надо анализировать не сами DCS, а всю систему целиком. Например вот тут
https://pgconf.ru/2020/274123
на 39й минуте лектор рисует интересную картинку. Да, картинка искусственная, и split-brain, как я понял, там не возникнет, просто демонстрация, что могут быть нюансы. Система, на самом деле, получается гораздо сложнее и как следствие гораздо сложнее анализировать её поведение при различных вариантах отказов, которых причем этих вариантов тоже будет гораздо больше.


С другой стороны то, что предлагает Pacemaker, а именно все хранить в файле XML, который синхронизируется с помощью специального протокола — мне тоже не нравится. Можно было бы и получше придумать.

Все это начиналось в 2018 году, рассматривались следующие технологии:

Pacemaker (с модулями pgsql или pgsqlms(PAF)). Это стандартное решение от RedHat для отказоустойчивых кластеров на базе RedHat.
RepMgr — решение от 2nd Quadrant, это один из соавторов PostgreSQL
Patroni — нечто написанное веб-программистами для веб-программистов и активно рекламируемое на форумах веб-программистов. :)

Вы может быть очень сильно удивитесь, но у PostgreSQL очень много контрибьюторов, и я кстати один из них :)
Более того, как правило большинство разработчиков постгреса лично знакомы друг с другом. PAF изначально разрабатывался Dalibo, и они кстати не гнушаются использовать Patroni ввиду более продвинутого функционала. И немного про Repmgr, в данный момент одна крупная американская финансовая организация переезжает в Repmgr на Patroni (речь идёт о тысячах кластеров).


Два года назад у Patroni был заметно беднее функционал. Я не припомню, чтобы там была хорошая, продуманная защита от split-brain. Хотя за два года многое могло изменится.

Месье знатный теоретик. Ещё 5 лет назад Patroni обходил все остальные решения по функционалу.
Защита от split-brain 100%:


  1. Self-fencing если не можем писать в Etcd.
  2. Watchdog рестартанёт ноду если на ней упал Patroni.

Всё остальное от лукавого. STONITH в большинсте случаев трудно реализуем. А для правильной имплементации требует второго сетевого канала между серверами.


Поддержки Patroni у RedHat нет. Patroni нет ни в официальном репозитории, ни в EPEL, ни PostgresQL репозитории пакетов. На официальном сайте Patroni тоже нет rpm пакетов.

Каждый должен заниматься своим делом. У меня нет ни времени ни желания билдить пакеты для 100500 дистрибутивов. Кстати, на одном RedHat свет клином не сошёлся. Пакет Patroni входит в Debian и Ubuntu ещё с 2018 года.


Предполагается что Patroni будет либо скачиваться через git и потом раскладываться и настраиваться по системе вручную. Либо устанавливаться через pip, но потом все равно недостающие в pip инсталяции файлы, например patroni.service для systemd, нужно будет скачивать вручную через git, устанавливать и настраивать.

Ещё раз повторюсь. Существует 100500 дистрибутивов. Systemd очень странное поделие с извращенной идеологией. У меня нет времени на поддержание этого зоопарка. Пакетами могут (и занимаются) заинтересованые люди. Я их знаю не только по именам но и лично и они проделывают титаническую работу.
В защиту Pip и Git могу сказать что этот 100% работает на всех платформах, включая Windows :) И да, есть места где Patroni используют на Windows в production (сотни инсталляций)!


В Pacemaker все идет в одном флаконе. Да, это несколько пакетов, но все они вместе разрабатываются одной командой разработчиков и вместе тестируются.

Так себе аргумент. Количество разработчиков и пользователей у Etcd на порядок превышает какой-то там Pacemaker. Соответственно вероятность багов в имплементации quorum тоже меншье на порядок.


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

Это кстати преимущество, а не недостаток. Каждый должен делать то что умеет делать хорошо.


Отдельное распределенное хранилище данных ETCD (причем кворум реализован на нём),

У Pacemaker это тоже наверняка отдельный компонент. Может быть я повторюсь, но количество инсталляций Etcd первышает Pacemaker на порядки, и соответственно вероятность попасть на очень критический баг на порядок меньше.


отдельно надо что-то придумывать для указания на действующие сервисы (consul?)

Можно просто использовать Consul вместо Etcd :) Другие варианты — HAProxy, vip-manager от Cybertec либо абсолютно любой железный или софтовый балансировщик нагрузки.
Pacemaker же поддерживает исключительно VIP, который требует чтобы все сервера находились в одном сегменте сети.


В Pacemaker есть команды для администрирования ресурсов (перемещения их по узлам). Например с помощью команды pcs resource ban можно заставить сервисы покинуть нужный узел для обслуживания, например чтобы там осуществить обновление софта yum update, перезагрузить OS и вернуть узел в кластер (разбанить) с помощью pcs resource clear. Ничего подобного Patroni не предусмотрено.

Плохо искали. Контроллируемое переключение (switchover) было имплементировано еще в 2015 году. У "конкуретнов" такая фича появилась только несколько лет спустя. Кроме того, Patroni умеет делать отложеный (запланированный) switchover в определенно заданное время. Например можно задать переключение в 4 часа ночи, когда мы знаем что трафик и нагрузка минимальны.

Комментарии сильно уклонились от темы статьи. Если вы еще не поняли, то я поясню, статья была про то, как можно искать (и находить) недостатки Pacemaker. Вместо этого набежали адепты Patroni и с религиозным фанатизмом (по другому и не скажешь) стали доказывать, что Patroni самый лучший в мире. Словно я покушаюсь на ваши доходы. :)


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


Так что вместо того, чтобы сотрясать воздух эмоциональными высказываниями и давить "авторитетом", предлагаю более конструктивный путь. Форкните проект, замените ту часть, где развертывается Pacemaker на Patroni, покажите миру как все классно работает. Я за здоровую конкуренцию. Сложного там ничего нет, главные заморочки были с многооконным интерфейсом в tmux, само развертывание и тестирование достаточно очевидно. Не нравится bash? Мне он тоже не нравится. Перепишите на python или на что сочтете нужным.


Вы же понимаете, как сильно можно будет поднять бабла, если во время лекций можно будет не просто так сотрясать воздух или показывать видео, а в реальном времени показывать, что вот, происходят отказы и как система с ними борется. Или вот, система успешно преодолела 1000 отказов. (Кстати на Pacemaker я до этой цифры так и не дошел. Как уже сказал, есть чего совершенствовать. :) Для такого использования во время демонстраций, кстати, надо сохранить способность системы целиком работать на одном MacBook Pro.

Насчёт системы тестирования. Есть такая штука как jepsen тест. С его помощью инженеры проверяли различные распределённых системы — начиная от монг и редисов — и находили в маркетинговых проспектах откровенную ложь касательно реальной отказоустойчивости и гарантий сохранности данных в этих системах. По сути — новый Фреймворк изобретать не надо, а вот взять уже существующий и показать на нем, что описанная в статье конфигурация «имеет право на жизнь» очень даже имеет смысл.

Спасибо, любопытно. Про jepsen не слышал, почитаю.

Почитал. jepsen придумывался для других задач. Для начала он зачем-то по SSH заходит на все узлы распределенной БД, потом начинает одновременно в них что-то писать, потом сверяет результат с тем, что он ожидает. Он тестирует распределенные БД на целостность данных при конкурентной записи. Тоже полезно, но не то, что я написал. Мой тестовый стенд тестирует отказоустойчивую систему на отказоустойчивость путем имитации различных поломок на виртуалках, jepsen это не делает. Теоретический его можно было бы использовать параллельно, чтобы убедится в отсутствии искажения при работе отказоустойчивой системы. Как в упомянутом вами случае с потерей подтвержденных закоммиченных транзакций в 1м и 2м кластерах.

ну, не совсем. Там речь про конкурентную запись при условии всяких неполадок в сети (и не только). Например, https://jepsen.io/analyses/redis-raft-1b3fbf6


We introduced a number of faults during our testing process, including process pauses, crashes, network partitions, clock skew, and membership changes.


Ну, и вообще всякие прочие интересные штуки вроде stale reads

Как я понял они сделали то, о чём я и написал постом выше, а именно запустили jepsen тест и параллельно


We introduced a number of faults during our testing process, including process pauses, crashes, network partitions, clock skew, and membership changes.

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

Ещё раз повторюсь. Существует 100500 дистрибутивов. Systemd очень странное поделие с извращенной идеологией. У меня нет времени на поддержание этого зоопарка.

Вот здесь не соглашусь. Называть «стандарт де-факто» «странным поделием с извращённой идеологией» — ну, такое себе… Вот уж спасибо, что сделали пакеты под Дебиан/убунту, но можно было и с системди и с редхат разобраться, благо куча клиентов на deb based сидит. А рекомендовать git/pip для инсталляции — прямая дорога в ад (и, да, я могу аргументированно объяснить почему).
В остальном — да, патрони — вероятно лучшее решение для создания постгрес кластеров, но это не означает, что оно идеальное.


Pacemaker же поддерживает исключительно VIP, который требует чтобы все сервера находились в одном сегменте сети.

Ну, да, все правильно ) хорошо ещё, что дедушку keepAlived не вспомнили )

Pacemaker же поддерживает исключительно VIP, который требует чтобы все сервера находились в одном сегменте сети.
Ну, да, все правильно ) хорошо ещё, что дедушку keepAlived не вспомнили )

Да нет, неправильно. Неправильное там слово "исключительно". Pacemaker универсальная модульная инфраструктура (в отличии от Patroni). Модули бывают разными. Есть модули для IP, входят в стандартную поставку. Ничего не мешает сделать модуль для dynamic dns, чтобы по аналогии с Консулом подменять DNS записи. Такое решение выглядит хуже, так как DNS много где могут кэшироваться, но не вижу тут ничего невозможного. Но поскольку сисадмины в свое время обещали оптоволокно между дата-центрами, я на эту тему не заморачивался.


Другое ограничение самого Pacemaker, что для работы ему была нужна плоская сеть. Возможно оно возникло в те времена, когда Pacemaker использовал бродкастовый трафик для обнаружения узлов. Сейчас он может использовать и уникастовый (когда явно прописываешь IP узлов в конфиге) и мультикастовый. Не тестировал в неплоской сети, но не вижу причин, чтобы так не работало.


В остальном — да, патрони — вероятно лучшее решение для создания постгрес кластеров, но это не означает, что оно идеальное.

Ну тут смотря по каким критериям оценивать. И у Pacemaker и у Patroni есть свои фичи. Что-то у одного лучше сделано, что-то у другого. В зависимости от того, кто считает какие фичи более важными, а недостатки более незначительными, для того и будет такое решение лучшим. Согласен с тем, что идеала до сих пор нет. И решения по управлению репликацией postgresql не ограничиваются pacemaker, repmgr, patroni. Недавно я знал про STOLON и ничего не мешает появится еще каким-нибудь, пока в конкурентной борьбе не победит сильнейший. Pacemaker тут стоит особняком, потому что только он из перечисленного позиционирует себя как универсальная инфраструктура для отказоустойчивых кластеров, на базе которого можно строить такие кластера для разных сервисов и даже для объединения разных сервисов. Но эта универсальность является и его же недостатком, потому что накладывает определенные ограничения на модули. Из-за которых, например, PAF выбирает раба с наименьшим отставанием используя откровенный костыль.

всё так сложно, столько звеньев. Выглядит просто как врыв из прошлого по сравнению с МонгоДБ, где указал указал ипшники и готова.

Да, в последнее время появляются много сисадминов, которые при выборе технологий отдают предпочтение тем, в которых как киллер фича заявлено уменьшение труда сисадминов. И плохо, что это единственный довод, который вы привели в пользу MongoDB, создает впечатление, что вы не вникали ни как она работает, ни то как она осуществляет HA и решает связанные с этим проблемы типа split-brain.


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

Олег, спасибо за статью. Очень классно, рад что проект продолжается.
Есть планы на OpenSource?

В смысле? Проект в OpenSource.

Чего с целостностью данных в случае отказа? Как минимум в первом сценарии отвала дц1, т.к. репликация асинхронная, на «свежеиспеченном» мастере может не оказаться небольшой, но ощутимой части данных. Приложение же об этом никогда (?) не узнаёт.

Отличный вопрос. :) Да, кластера 1 и 2 могут потерять информацию об уже подтвержденных закоммиченных транзакциях. Придуманы они были потому, что "изначально у нас будет только два дата-центра". :) Так получается, что для отказоустойчивости нужна асинхронная репликация, для не потери информации синхронная, а чтобы то и то, нужно чтобы и репликация была и такая и такая. Так реализовано в кластерах 3 и 4.


Есть еще вариант, если мне память не изменяет, реализованный то ли в Patroni, то ли Repmgr (могу путать, года два назад про это читал): репликация синхронная, но когда отваливается раб переключается в асинхронную. С одной стороны такое решение очень похоже на простую асинхронную. Потому что никаких гарантий дублирования закоммиченных транзакций не будет. С другой стороны, если расчёт идет только на один отказ, то кажется, что всё не так уж и плохо. Отвалиться может либо мастер либо раб и в обоих случаях сохраниться и работоспособность и не будут потеряны подтвержденные закоммиченные транзакции.

А в теории можно не "любить" себя в голову и взять Postgres Pro Multi Master, либо cockroachdb (из фич — PostgreSQL wire compatibility, мультимастер и всякие облачные штуки). Насчет практики — опять же — не все, что есть в маркетинговых проспектах может нормально работать, поэтому ни одно из обоих решений не могу порекомендовать, т.к. не проводил глубокий анализ именно "в бою"

Про cockroachdb не слышал, про Postgres Pro Multi Master (неизвестной цены), читал. На сколько я помню, они реализовали мультимастер на распределенных транзакциях, причем трехфазных. Выглядит это круто, в маркетинговых проспектах, но вы правы, вызывает большой скепсис для использования при высоких нагрузках. Во-первых интуиция подсказывает что на таких распределенных транзакциях будет сильно просаживаться производительность. А во-вторых при высоких нагрузках можно ожидать ошибки и откаты транзакций из-за того, что распределенные транзакции будут конфликтовать друг с другом. Ну а поскольку решение небесплатное, то никто его мне покупать не будет только для того, чтобы я погонял на нём тесты.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий