Комментарии 41
Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать.
Ага, только переезд постгрес-мастера по скрипту pacemaker тоже провалился, и весь кластер рассыпался вдребезги. Такое тоже бывает ;)
Вообще, имхо corosync/pacemaker — самый рульный кластерный стек на линуксах, во всяком случае, я с ним почти без проблем сумел разобраться и даже что-то на нем поднять, что стоит и не падает.
Просто интересно, а как часто у вас просходит (по любым причинам) переезд мастера?
У меня — вплоть до никогда, но я с тех пор особо и не админил/настраивал постгрес с каким-либо менеджером мастера поверх. В окрестностях меня — было пару раз, но строго в тестовом режиме, в основном по питанию, если в неправильном порядке останавливать ВМ в ожидании отключения силовой, там может что и поломаться. Оттого и коммент был.
В нормальной компании на такой случай должен быть дежурный администратор, иначе никакой кластер не спасет.
В виртуализированной среде механизм фенсинга (fencing) усложняется и становится многоуровневым: на первом уровне нужно реализовать выключение виртуальной машины через гипервизор, а на втором — выключение всего гипервизора (второй уровень срабатывает, когда на первом уровне фенсинга корректно не отработал). К сожалению, у некоторых гипервизоров нет возможности фенсинга. Рекомендуем не использовать виртуальные машины при построении ОУК
Вот этого абзаца я вообще не понял.
Во-первых, что это за таинственные "некоторые" гипервизоры, у которых нет функции выключения VM?
Во-вторых, из-за сбоя в одной VM гасить весь хост, серьезно?!
В-третьих, финальное "рекомендуем не использовать VM" — а вы на календарь смотрели? Сейчас не 2008 год, а 2018.
Понятно, что многие вещи при виртуализации усложняются (начиная от понимания того, что, собственно случилось, заканчивая механизмами реакции). Но это попросту заслуживает отдельного рассмотрения, а не рекомендаций вида "не используйте виртуалки, там надо".
Во-первых, что это за таинственные «некоторые» гипервизоры, у которых нет функции выключения VM?
Имхо, тут вопрос не в «нет функции выключения», а то, что корректный фенсинг — это жесткое отключение из розетки (если проводить аналогию с железками), а не милая просьба «выключись, пожалуйста». И вот если хост не смог выключить быстро VM (ну зависли там процессы напрочь и система не хочет выключиться), то в зависимости от критичности кластеризованного сервиса может быть придется и весь хост погасить.
что корректный фенсинг — это жесткое отключение из розетки
Тогда это надо делать через управляемый PDU, а не IPMI, с которым тоже фокусы могут быть. ;) А выключение через IPMI концептуально мало чем отличается от выключения через гипервизор.
в зависимости от критичности кластеризованного сервиса может быть придется и весь хост погасить.
Может быть. Только управляться это должно не на уровне кластера PostgreSQL, а на уровне кластера виртуализации. Я про то и пишу, что в виртуализованной среде нужно дополнительное планирование, а советы "выключите хост" или "не используйте виртуализацию" не слишком полезны в общем случае. Хотя, конечно, вполне могут быть кейсы, где виртуализация просто не нужна.
<промах>
Есть положительный опыт построения 3-х нодового кластера, «растянутого» на 3 дата-центра — каждая нода живет в своем дата-центре.
В таком кластере есть свои нюансы, которые необходимо учитывать.
Первый — невозможность обеспечить надежный управляющий линк между нодами, поскольку нельзя гарантировать надежный канал между дата-центрами. Линк между нодами (считай, между дата-центрами) может периодически пропадать. В ОУК с дефолтными настройками такое пропадание линка будет считаться сбоем и Pacemaker на это среагирует — переместит ресурсы на «живую» ноду.
Поэтому встает задача выставить оптимальные таймауты на время реагирования Pacemaker'ом.
Выставить большие таймауты — значит будет большее время переключения роли Мастера между нодами.
Выставить короткий таймаут — значит будут ложные срабатывания Pacemaker'ом.
Оптимальные таймауты можно подобрать только эмпирическим путем.
Второй — необходимо организовать единое адресное пространство между дата-центрами. Это дополнительное оборудование, расходы, и с точки зрения надежности — включение дополнительных элементов (VPN-устройств) необходимо также резервировать.
Третий — ввиду того, что задержка между дата-центрами может составлять большее время, чем в локальной сети, то придется отказаться от синхронной реплики при построении ОУК. А это влечет небольшую потерю данных — реплика от мастера будет отставать, и при переключении роли мастера на асинхронную реплику небольшая часть данных будет потеряна.
Ну это достаточно очевидный момент при работе с любой БД в принципе — либо у вас синхронная репликация с соответствующими требованиями к каналу, либо асинхронная с возможностью потери данных.
Что касается приложений и 1С в частности — если при репликации поддерживается целостность данных на уровне транзакций, то потери из-за асинхронности ничем не более опасны, чем, например, восстановление копии из бэкапа SQL.
[Игорь Косенков]: Двухнодовый кластер обладает существенным недостатком — в нем отсутствует кворум. В связи с этим, такой кластер не заведется, если не указать Pacemaker'у, чтобы он не учитывал кворум. Но даже, если скажете Pacemaker'у no-quorum-policy=ignore, то вас подстерегает опасность — кластер без учета кворума не может противостоять сбою "Потеря сетевой связности (линка) между нодами". При таком сбое обе ноды будут считать соседнюю ноду сбойнувшей (потерянной) и в кластере появятся одновременно 2 Мастера с двумя Virtual-IP. Получите типичный split-brain, из которого ничего хорошего не получится.
В нашей компании специально для двух-нодововых кластеров (без кворума) разработано решение тоже на базе pacemaker/corosync, которое защищает от split-brain в таких ситуациях. Описание данного решения — тема отдельной статьи.
Также в двухнодовой конфигурации будет работать наше решение multimaster, входящее в Enterprise.
но напишем и еще, конечно. дату не назову.
Мне видится что-то типа того: три машины в кластере. На всех трех postgres — один мастер, две синх. реплики. При этом я создам виртуальный ip для мастера и там же, где мастер будет pgbouncer для распределения читающих запросов на реплики.
Кластер будет назначать мастеров и слейвов, а также перевозить ip и pgbouncer в случае переезда мастера.
В любом случае спасибо за такое вводное описание.
Кластер pacemaker/corosync без валидола