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

    Введение


    Некоторое время назад передо мной поставили задачу разработать отказоустойчивый кластер для PostgreSQL, работающий в нескольких дата-центрах, объединенных оптоволокном в рамках одного города, и способный выдержать отказ (например, обесточивание) одного дата-центра. В качестве софта, который отвечает за отказоустойчивость, выбрал Pacemaker, потому что это официальное решение от RedHat для создания отказоустойчивых кластеров. Оно хорошо тем, что RedHat обеспечивает его поддержку, и тем, что это решение универсальное (модульное). С его помощью можно будет обеспечить отказоустойчивость не только PostgreSQL, но и других сервисов, либо используя стандартные модули, либо создавая их под конкретные нужды.


    К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).


    Сейчас руководство разрешило открыть проект для open source-сообщества под лицензией MIT. README в скором времени будет переведен на английский язык (потому что ожидается, что основными потребителями будут разработчики Pacemaker и PostgreSQL), а старый русский вариант README я решил оформить (частично) в виде этой статьи.


    Krogan on Tuchanka


    Кластеры разворачиваются на виртуалках VirtualBox. Всего будет развернуто 12 виртуалок (суммарно 36GiB), которые образуют 4 отказоустойчивых кластера (разные варианты). Первые два кластера состоят из двух серверов PostgreSQL, которые размещены в разных дата-центрах, и общего сервера witness c quorum device (размещенный на дешёвой виртуалке в третьем дата-центре), который разрешает неопределенность 50%/50%, отдавая свой голос одной из сторон. Третий кластер в трех дата-центрах: один мастер, два раба, без quorum device. Четвертый кластер состоит из четырех серверов PostgreSQL, по два на дата-центр: один мастер, остальные реплики, и тоже использует witness c quorum device. Четвертый выдерживает отказ двух серверов или одного дата-центра. Это решение может быть, при необходимости, масштабировано на большее количество реплик.


    Сервис точного времени ntpd тоже перенастроен для отказоустойчивости, но там используются метод самого ntpd (orphan mode). Общий сервер witness выполняет роль центрального NTP-сервера, раздавая своё время всем кластерам, тем самым синхронизируя все серверы между собой. Если witness выйдет из строя или окажется изолированным, тогда своё время начнет раздавать один из серверов кластера (внутри кластера). Вспомогательный кэширующий HTTP proxy тоже поднят на witness, с его помощью остальные виртуалки имеют доступ к Yum-репозиториям. В реальности такие сервисы, как точное время и прокси, наверняка будут размещены на выделенных серверах, а в стенде они размещены на witness только для экономии количества виртуалок и места.


    Версии


    v0. Работает с CentOS 7 и PostgreSQL 11 на VirtualBox 6.1.


    Структура кластеров


    Все кластеры предназначены для размещения в нескольких дата-центрах, объединены в одну плоскую сеть и должны выдерживать отказ или сетевую изоляцию одного дата-центра. Поэтому невозможно использовать для защиты от split-brain стандартную технологию Pacemaker, которая называется STONITH (Shoot The Other Node In The Head) или fencing. Её суть: если узлы в кластере начинают подозревать, что с каким-то узлом происходит неладное, он не отвечает или некорректно себя ведёт, то они принудительно его отключают через «внешние» устройства, например, управляющую карточку IPMI или UPS. Но такое сработает только в случаях, когда при единичном отказе сервера IPMI или UPS продолжают работать. Здесь же планируется защита от гораздо более катастрофичного отказа, когда отказывает (например обесточивается) весь дата-центр. А при таком отказе все stonith-устройства (IPMI, UPS и т.д.) тоже не будут работать.


    Вместо этого в основе системы лежит идея кворума. Все узлы имеют голос, и работать могут только те, которые видят больше половины всех узлов. Это количество «половина+1» называется кворум. Если кворум не набирается, то узел решает, что он находится в сетевой изоляции и должен отключить свои ресурсы, т.е. это такая защита от split-brain. Если софт, который отвечает за такое поведение, не работает, то должен будет сработать watchdog, например, на базе IPMI.


    Если количество узлов четное (кластер в двух дата-центрах), то может возникнуть так называемая неопределенность 50%/50% (фифти-фифти), когда сетевая изоляция делит кластер ровно пополам. Поэтому для четного количества узлов добавляется quorum device — нетребовательный демон, который может быть запущен на самой дешевой виртуалке в третьем дата-центре. Он дает свой голос одному из сегментов (который видит), и тем самым разрешает неопределенность 50%/50%. Сервер, на котором будет запущен quorum device, я назвал witness (терминология из repmgr, мне понравилась).


    Ресурсы могут переезжать с места на место, например, с неисправных серверов на исправные, или по команде сисадминов. Чтобы клиенты знали, где находятся нужные им ресурсы (куда подключаться?), используются плавающие IP (float IP). Это IP, которые Pacemaker может перемещать по узлам (всё находится в плоской сети). Каждый из них символизирует ресурс (сервис) и будет находится там, куда надо подключаться, чтобы получить доступ к этому сервису (в нашем случае БД).


    Tuchanka1 (схема с уплотнением)


    Структура


    Tuchanka1


    Идея была в том, что у нас есть много мелких баз данных с низкой нагрузкой, для которых невыгодно содержать выделенный slave-сервер в режиме hot standby для read only-транзакций (нет необходимости в такой растрате ресурсов).


    В каждом дата-центре по одному серверу. На каждом сервере по два инстанса PostgreSQL (в терминологии PostgreSQL они называются кластерами, но во избежание путаницы я буду их называть инстансами (по аналогии с другими БД), а кластерами буду называть только кластеры Pacemaker). Один инстанс работает в режиме мастера, и только он оказывает услуги (только на него ведет float IP). Второй инстанс работает рабом для второго дата-центра, и будет оказывать услуги только если его мастер выйдет из строя. Поскольку бо̒льшую часть времени оказывать услуги (выполнять запросы) будет только один инстанс из двух (мастер), все ресурсы сервера оптимизируются на мастер (выделяется память под кэш shared_buffers и т.д.), но так, чтобы на второй инстанс тоже хватило ресурсов (пусть и для неоптимальной работы через кэш файловой системы) на случай отказа одного из дата-центров. Раб не оказывает услуги (не выполняет read only-запросы) при нормальной работе кластера, чтобы не было войны за ресурсы с мастером на той же самой машине.


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


    Отказ witness


    failure witness


    Отказ witness (quorum device) я рассмотрю только для кластера Tuchanka1, со всеми остальными будет та же история. При отказе witness в структуре кластера ничего не изменится, всё продолжит работать так же, как и работало. Но кворум станет равен 2 из 3, и поэтому любой следующий отказ станет фатальным для кластера. Всё равно придётся срочно чинить.


    Отказ Tuchanka1


    failure Tuchanka1


    Отказ одного из дата-центров для Tuchanka1. В этом случае witness отдает свой голос второму узлу на втором дата-центре. Там бывший раб превращается в мастера, в результате на одном сервере работают оба мастера и на них указывают оба их float IP.


    Tuchanka2 (классическая)


    Структура


    Tuchanka2


    Классическая схема из двух узлов. На одном работает мастер, на втором раб. Оба могут выполнять запросы (раб только read only), поэтому на обоих указывают float IP: krogan2 — на мастер, krogan2s1 — на раба. Отказоустойчивость будет и у мастера, и у раба.


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


    Отказ Tuchanka2


    failure Tuchanka2


    При отказе одного из дата-центров witness голосует за второй. На единственном работающем дата-центре будет поднят мастер, и на него будут указывать оба float IP: мастерский и рабский. Разумеется, инстанс должен быть настроен таким образом, чтобы у него хватило ресурсов (лимитов под connection и т.д.) одновременно принимать все подключения и запросы от мастерского и рабского float IP. То есть при нормальной работе у него должен быть достаточный запас по лимитам.


    Tuchanka4 (много рабов)


    Структура


    Tuchanka4


    Уже другая крайность. Бывают БД, на которые идет очень много запросов read-only (типичный случай высоконагруженного сайта). Tuchanka4 — это ситуация, когда рабов может быть три или больше для обработки таких запросов, но всё же не слишком много. При очень большом количестве рабов надо будет изобретать иерархическую систему реплицирования. В минимальном случае (на картинке) в каждом из двух дата-центров находится по два сервера, на каждом из которых по инстансу PostgreSQL.


    Еще одной особенностью этой схемы является то, что здесь уже можно организовать одну синхронную репликацию. Она настроена так, чтобы реплицировать, по возможности, в другой дата-центр, а не на реплику в том же дата-центре, где и мастер. На мастер и на каждый раб указывает float IP. По хорошему, между рабами надо будет делать балансировку запросов каким-нибудь sql proxy, например, на стороне клиента. Разному типу клиентов может требоваться разный тип sql proxy, и только разработчики клиентов знают, кому какой нужен. Эта функциональность может быть реализована как внешним демоном, так и библиотекой клиента (connection pool), и т.д. Всё это выходит за рамки темы отказоустойчивого кластера БД (отказоустойчивость SQL proxy можно будет реализовать независимо, вместе с отказоустойчивостью клиента).


    Отказ Tuchanka4


    failure Tuchanka4


    При отказе одного дата-центра (т.е. двух серверов) witness голосует за второй. В результате во втором дата-центре работают два сервера: на одном работает мастер, и на него указывает мастерский float IP (для приема read-write запросов); а на втором сервере работает раб с синхронной репликацией, и на него указывает один из рабских float IP (для read only-запросов).


    Первое, что надо отметить: рабочими рабский float IP будут не все, а только один. И для корректной работы с ним нужно будет, чтобы sql proxy перенаправлял все запросы на единственно оставшийся float IP; а если sql proxy нет, то можно перечислить все float IP рабов через запятую в URL для подключения. В таком случае с libpq подключение будет к первому рабочему IP, так сделано в системе автоматического тестирования. Возможно, в других библиотеках, например, JDBC, так работать не будет и необходим sql proxy. Так сделано потому, что у float IP для рабов стоит запрет одновременно подниматься на одном сервере, чтобы они равномерно распределялись по рабским серверам, если их работает несколько.


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


    Tuchanka3 (3 дата-центра)


    Структура


    Tuchanka3


    Это кластер для ситуации, когда есть три полноценно работающих дата-центра, в каждом из которых есть полноценно работающий сервер БД. В этом случае quorum device не нужен. В одном дата-центре работает мастер, в двух других — рабы. Репликация синхронная, типа ANY (slave1, slave2), то есть клиенту будет приходить подтверждение коммита, когда любой из рабов первым ответит, что он принял коммит. На ресурсы указывает один float IP для мастера и два для рабов. В отличие от Tuchanka4 все три float IP отказоустойчивы. Для балансировки read-only SQL-запросов можно использовать sql proxy (с отдельной отказоустойчивостью), либо половине клиентов назначить один рабский float IP, а другой половине — второй.


    Отказ Tuchanka3


    failure Tuchanka3


    При отказе одного из дата-центров остаются два. В одном поднят мастер и float IP от мастера, во втором — раб и оба рабских float IP (на инстансе должен быть двукратный запас по ресурсам, чтобы принять все подключения с обоих рабских float IP). Между мастеров и рабом синхронная репликация. Также кластер сохранит информацию о закоммиченных и подтвержденных транзакциях (не будет потери информации) в случае уничтожения двух дата-центров (если они уничтожены не одновременно).


    Подробное описание файловой структуры и развертывания я решил не вставлять. Кто захочет поиграться, можете всё это прочитать в README. Я привожу только описание автоматического тестирования.


    Система автоматического тестирования


    Для проверки отказоустойчивости кластеров с имитацией различных неисправностей сделана система автоматического тестирования. Запускается скриптом test/failure. Скрипт может принимать в качестве параметров номера кластеров, которые хочется потестировать. Например, эта команда:


    test/failure 2 3

    будет тестировать только второй и третий кластер. Если параметры не указаны, то тестироваться будут все кластеры. Все кластеры тестируются параллельно, а результат выводится в панели tmux. Tmux использует выделенный tmux сервер, поэтому скрипт можно запускать из-под default tmux, получится вложенный tmux. Рекомендую применять терминал в большом окне и с маленьким шрифтом. Перед началом тестирования все виртуалки откатываются на снэпшот на момент завершения скрипта setup.


    screenshot of `test/failure`


    Терминал разбит на колонки по количеству тестируемых кластеров, по умолчанию (на скриншоте) их четыре. Содержимое колонок я распишу на примере Tuchanka2. Панели на скриншоте пронумерованы:


    1. Здесь выводится статистика по тестам. Колонки:
      • failure — название теста (функции в скрипте), который эмулирует неисправность.
      • reaction — среднее арифметическое время в секундах, за которое кластер восстановил свою работоспособность. Замеряется от начала работы скрипта, эмулирующего неисправность, и до момента, когда кластер восстанавливает свою работоспособность и способен продолжать оказывать услуги. Если время очень маленькое, например, шесть секунд (так бывает в кластерах с несколькими рабами (Tuchanka3 и Tuchanka4)), это означает, что неисправность оказалась на асинхронном рабе и никак не повлияла на работоспособность, переключений состояния кластера не было.
      • deviation — показывает разброс (точность) значения reaction методом «стандартная девиация».
      • count — сколько раз был выполнен этот тест.
    2. Краткий журнал позволяет оценить, чем занимается кластер в текущий момент. Выводится номер итерации (теста), временна̒я метка и название операции. Слишком долгое выполнение (> 5 минут) говорит о какой-то проблеме.
    3. heart (сердце) — текущее время. Для визуальной оценки работоспособности мастера в его таблицу постоянно пишется текущее время с использованием float IP мастера. В случае успеха результат выводится в этой панели.
    4. beat (пульс) — «текущее время», которое ранее было записано скриптом heart в мастер, теперь считывается из раба через его float IP. Позволяет визуально оценить работоспособность раба и репликации. В Tuchanka1 нет рабов с float IP (нет рабов, оказывающих услуги), но зато там два инстанса (БД), поэтому здесь будет показываться не beat, а heart второго инстанса.
    5. Мониторинг состояния кластера с помощью утилиты pcs mon. Показывает структуру, распределение ресурсов по узлам и другую полезную информацию.
    6. Здесь выводится системный мониторинг с каждой виртуалки кластера. Таких панелей может быть и больше — сколько виртуалок у кластера. Два графика CPU Load (в виртуалках по два процессора), имя виртуалки, System Load (названый как Load Average, потому что он усреднен за 5, 10 и 15 минут), данные по процессам и распределение памяти.
    7. Трассировка скрипта, выполняющего тестирования. В случае неисправности — внезапного прерывания работы либо бесконечного цикла ожидания — здесь можно будет увидеть причину такого поведения.

    Тестирование проводится в два этапа. Сначала скрипт проходит по всем разновидностям тестов, случайным образом выбирая виртуалку, к которой этот тест применить. Затем выполняется бесконечный цикл тестирования, виртуалки и неисправность каждый раз выбираются случайным образом. Внезапное завершение скрипта тестирования (нижняя панель) или бесконечный цикл ожидания чего-либо (> 5 минут время выполнения одной операции, это видно в трассировке) говорит о том, что какой-то из тестов на этом кластере провалился.


    Каждый тест состоит из следующих операций:


    1. Запуск функции, эмулирующей неисправность.
    2. Ready? — ожидание восстановления работоспособности кластера (когда оказываются все услуги).
    3. Показывается время ожидания восстановления кластера (reaction).
    4. Fix — кластер «чинится». После чего он должен вернуться в полностью работоспособное состояние и готовности к следующей неисправности.

    Вот список тестов с описанием, что они делают:


    • ForkBomb: создает "Out of memory" с помощью форк-бомбы.
    • OutOfSpace: переполняет винчестер. Но тест, скорее, символичный, при той незначительной нагрузке, которая создаётся при тестировании, при переполнении винчестера отказа PostgreSQL обычно не происходит.
    • Postgres-KILL: убивает PostgreSQL командой killall -KILL postgres.
    • Postgres-STOP: подвешивает PostgreSQL командой killall -STOP postgres.
    • PowerOff: «обесточивает» виртуалку командой VBoxManage controlvm "виртуалка" poweroff.
    • Reset: перегружает виртуалку командой VBoxManage controlvm "виртуалка" reset.
    • SBD-STOP: подвешивает демон SBD командой killall -STOP sbd.
    • ShutDown: через SSH посылает на виртуалку команду systemctl poweroff, система корректно завершает работу.
    • UnLink: сетевая изоляция, команда VBoxManage controlvm "виртуалка" setlinkstate1 off.

    Завершение тестирование либо с помощью стандартной командой tmux "kill-window" Ctrl-b &, либо командой "detach-client" Ctrl-b d: при этом тестирование завершается, tmux закрывается, виртуалки выключаются.


    Выявленные при тестировании проблемы


    • На текущий момент watchdog демон sbd отрабатывает остановку наблюдаемых демонов, но не их зависание. И, как следствие, некорректно отрабатываются неисправности, приводящие к зависанию только Corosync и Pacemaker, но при этом не подвешивающие sbd. Для проверки Corosync уже есть PR#83 (в GitHub у sbd), принят в ветку master. Обещали (в PR#83), что и для Pacemaker будет что-то подобное, надеюсь, что к RedHat 8 сделают. Но подобные «неисправности» умозрительные, легко имитируются искусственно с помощью, например, killall -STOP corosync, но никогда не встречаются в реальной жизни.


    • У Pacemaker в версии для CentOS 7 неправильно выставлен sync_timeout у quorum device, в результате при отказе одного узла с некоторой вероятностью перезагружался и второй узел, на который должен был переехать мастер. Вылечилось увеличением sync_timeout у quorum device во время развертывания (в скрипте setup/setup1). Эта поправка не была принята разработчиками Pacemaker, вместо этого они пообещали переработать инфраструктуру таким образом (в некотором неопределенном будущем), чтобы этот таймаут вычислялся автоматически.


    • Если при конфигурировании базы данных указано, что в LC_MESSAGES (текстовые сообщения) может использоваться Юникод, например, ru_RU.UTF-8, то при запуске postgres в окружении, где locale не UTF-8, допустим, в пустом окружении (здесь pacemaker+pgsqlms(paf) запускает postgres), то в логе вместо букв UTF-8 будут знаки вопроса. Разработчики PostgreSQL так и не договорились, что делать в этом случае. Это обходится, нужно ставить LC_MESSAGES=en_US.UTF-8 при конфигурировании (создании) инстанса БД.


    • Если выставлен wal_receiver_timeout (по умолчанию он 60s), то при тесте PostgreSQL-STOP на мастере в кластерах tuchanka3 и tuchanka4 не происходит переподключение репликации к новому мастеру. Репликация там синхронная, поэтому останавливается не только раб, но и новый мастер. Обходится установкой wal_receiver_timeout=0 при настройке PostgreSQL.


    • Изредко наблюдал подвисание репликации у PostgreSQL в тесте ForkBomb (переполнение памяти). После ForkBomb иногда рабы могут не переподключаться к новому мастеру. Я встречал такое лишь в кластерах tuchanka3 и tuchanka4, где из-за того, что репликация синхронная, подвисал мастер. Проблема проходила сама, спустя какое-то длительное время (порядка двух часов). Требуется дополнительное исследование, чтобы это исправить. По симптомам похоже на предыдущий баг, который вызывается другой причиной, но с одинаковыми последствиями.



    Картинка крогана взята с Deviant Art c разрешения автора:


    Разрешение Noosborn

    ДомКлик
    Место силы

    Comments 53

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

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

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

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


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

            +1
            Я использовал github.com/ClusterLabs/PAF но пришлось отказаться — после перехода на посгтрес 12 паф работал до первого переключения с мастера на слейв, после чего репликация накрывалась медным тазом и все приходилось чинить руками. Как у вас пейсмейкер мониторит инстансы постгреса и как восстанавливается репликация при падении мастера — мастер просто падает и ждет когда админ поднимет репликацию к новому мастеру руками или репликация поднимается автоматически средствами пейсмейкера?
              +1
              То что вы описываете касается версии 2.3 PAFa?
                0
                Да, версия 2.3
                0
                Про 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 и переезд мастера обратно) происходит автоматический.
                  0
                  В моем случае была простая схема мастер-слейв. При тестировании я отключал мастер (просто делал shutdown, база постгреса и сама нода при этом находятся в рабочем состоянии), пейсмейкер начинает миграцию и поднимает роль мастера на слейве. При включении бывшего мастера, я сбрасывал аварийный триггер ресурсов через cleanup (так как и нода и инстанс постгреса находятся в рабочем состоянии после старта) и пейсмейкер должен был выставить ноде роль слейв и начать процедуру восстановления реплики с нового мастера. Но реплику поднять он не мог, выкидывал ошибку и переводил ресурсы снова в аварийное состояние. Приходилось поднимать реплику руками через pg_basebucket.
                    0

                    Я проверил то, про что вы написали (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. Когда до этого дойдет дело, протестирую.

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

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


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

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

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

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

                +2

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

                  0

                  Все это начиналось в 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 они разработали, какие отказы она выдерживает, а какие и нет. Ну и самое интересное, а как же они её тестировали? :)

                    +2
                    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: инсталляция и отработка падений

                      –1

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


                      Написанное 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 все можно сделать очень по разному. И именно поэтому я не вижу смысла делать самому такой тестовый стенд, потому что я могу придумать как-то по другому.

                        0

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


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

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

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


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

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


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

                            +1

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


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

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

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


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

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


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

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


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

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


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

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

                                +1

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


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

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

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


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


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

                                    0
                                    У 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 будет пару раз плюнуть. Странно что вы раньше, до меня, не догадались это сделать.


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

                                      0

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


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


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

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

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

                            +2
                            Если посмотреть в каком окружении содержится 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 и возможные подводные камни.

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

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

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

                                +1

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

                                  0

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


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

                          +1
                          Все это начиналось в 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 часа ночи, когда мы знаем что трафик и нагрузка минимальны.

                            –1

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


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


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


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

                              +1

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

                                0

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

                                  0

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

                                    0

                                    ну, не совсем. Там речь про конкурентную запись при условии всяких неполадок в сети (и не только). Например, 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

                                      0

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


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

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

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

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


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

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

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

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


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


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

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

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

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


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

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

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

                                +1

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

                                  0

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


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

                                    0

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

                                      0

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

                                Only users with full accounts can post comments. Log in, please.