[Игорь Косенков:] «Примитивная отказоустойчивость» — звучит как пародия на отказоустойчивость. Ведь в случае с 2-х нодовым кластером, некоторые сбои будут фатальными для СУБД…
Как в таком случае объяснять руководству, что ваш отказоустойчивый кластер не всегда отказоустойчивый?
[Игорь Косенков:] В планах на будущее — написание отдельной статьи на тему «Защита от split-brain в 2-х нодовом отказоустойчивом кластере на базе Pacemaker/Corosync»
[Игорь Косенков]: Двухнодовый кластер обладает существенным недостатком — в нем отсутствует кворум. В связи с этим, такой кластер не заведется, если не указать Pacemaker'у, чтобы он не учитывал кворум. Но даже, если скажете Pacemaker'у no-quorum-policy=ignore, то вас подстерегает опасность — кластер без учета кворума не может противостоять сбою "Потеря сетевой связности (линка) между нодами". При таком сбое обе ноды будут считать соседнюю ноду сбойнувшей (потерянной) и в кластере появятся одновременно 2 Мастера с двумя Virtual-IP. Получите типичный split-brain, из которого ничего хорошего не получится.
В нашей компании специально для двух-нодововых кластеров (без кворума) разработано решение тоже на базе pacemaker/corosync, которое защищает от split-brain в таких ситуациях. Описание данного решения — тема отдельной статьи.
Также в двухнодовой конфигурации будет работать наше решение multimaster, входящее в Enterprise.
[ответ автора статьи, Игоря Косенкова]
Есть положительный опыт построения 3-х нодового кластера, «растянутого» на 3 дата-центра — каждая нода живет в своем дата-центре.
В таком кластере есть свои нюансы, которые необходимо учитывать.
Первый — невозможность обеспечить надежный управляющий линк между нодами, поскольку нельзя гарантировать надежный канал между дата-центрами. Линк между нодами (считай, между дата-центрами) может периодически пропадать. В ОУК с дефолтными настройками такое пропадание линка будет считаться сбоем и Pacemaker на это среагирует — переместит ресурсы на «живую» ноду.
Поэтому встает задача выставить оптимальные таймауты на время реагирования Pacemaker'ом.
Выставить большие таймауты — значит будет большее время переключения роли Мастера между нодами.
Выставить короткий таймаут — значит будут ложные срабатывания Pacemaker'ом.
Оптимальные таймауты можно подобрать только эмпирическим путем.
Второй — необходимо организовать единое адресное пространство между дата-центрами. Это дополнительное оборудование, расходы, и с точки зрения надежности — включение дополнительных элементов (VPN-устройств) необходимо также резервировать.
Третий — ввиду того, что задержка между дата-центрами может составлять большее время, чем в локальной сети, то придется отказаться от синхронной реплики при построении ОУК. А это влечет небольшую потерю данных — реплика от мастера будет отставать, и при переключении роли мастера на асинхронную реплику небольшая часть данных будет потеряна.
Про pgDay не берусь сказать (может кто-то подскажет более информированный), зато знаю, что все доклады pgConf 2017, 16 и 15 выложены на сайте конференции. вот, например: pgconf.ru/2017/93506. 2018 появятся чуть попозже.
Прекрасно. если это произошло только что, то я могу включить в подборку новостей, которую сейчас собираю. и вообще можно кидать новости на почту, внизу есть адрес.
Как в таком случае объяснять руководству, что ваш отказоустойчивый кластер не всегда отказоустойчивый?
но напишем и еще, конечно. дату не назову.
Чуть позже добавлю это в раздел "Особенности использования PostgreSQL для ОУК"
[Игорь Косенков]: Двухнодовый кластер обладает существенным недостатком — в нем отсутствует кворум. В связи с этим, такой кластер не заведется, если не указать Pacemaker'у, чтобы он не учитывал кворум. Но даже, если скажете Pacemaker'у no-quorum-policy=ignore, то вас подстерегает опасность — кластер без учета кворума не может противостоять сбою "Потеря сетевой связности (линка) между нодами". При таком сбое обе ноды будут считать соседнюю ноду сбойнувшей (потерянной) и в кластере появятся одновременно 2 Мастера с двумя Virtual-IP. Получите типичный split-brain, из которого ничего хорошего не получится.
В нашей компании специально для двух-нодововых кластеров (без кворума) разработано решение тоже на базе pacemaker/corosync, которое защищает от split-brain в таких ситуациях. Описание данного решения — тема отдельной статьи.
Также в двухнодовой конфигурации будет работать наше решение multimaster, входящее в Enterprise.
Есть положительный опыт построения 3-х нодового кластера, «растянутого» на 3 дата-центра — каждая нода живет в своем дата-центре.
В таком кластере есть свои нюансы, которые необходимо учитывать.
Первый — невозможность обеспечить надежный управляющий линк между нодами, поскольку нельзя гарантировать надежный канал между дата-центрами. Линк между нодами (считай, между дата-центрами) может периодически пропадать. В ОУК с дефолтными настройками такое пропадание линка будет считаться сбоем и Pacemaker на это среагирует — переместит ресурсы на «живую» ноду.
Поэтому встает задача выставить оптимальные таймауты на время реагирования Pacemaker'ом.
Выставить большие таймауты — значит будет большее время переключения роли Мастера между нодами.
Выставить короткий таймаут — значит будут ложные срабатывания Pacemaker'ом.
Оптимальные таймауты можно подобрать только эмпирическим путем.
Второй — необходимо организовать единое адресное пространство между дата-центрами. Это дополнительное оборудование, расходы, и с точки зрения надежности — включение дополнительных элементов (VPN-устройств) необходимо также резервировать.
Третий — ввиду того, что задержка между дата-центрами может составлять большее время, чем в локальной сети, то придется отказаться от синхронной реплики при построении ОУК. А это влечет небольшую потерю данных — реплика от мастера будет отставать, и при переключении роли мастера на асинхронную реплику небольшая часть данных будет потеряна.