Комментарии 24
Идея интересная, но что будет при split brain? Более безопасный вариант http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster
Здесь не идет речи о split brain, так как в один момент времени инстанс PostgreSQL крутится на одном хосте, репликация не используется и группа представляется как единый сервис и все операции записи/чтения идут в одно место.
В случае выхода из строка VIP (моргнет сеть) либо сервиса, вся группа переедет на другую ноду.
В случае выхода из строка VIP (моргнет сеть) либо сервиса, вся группа переедет на другую ноду.
При split brain оба хоста будут считать себя мастер нодой: примонтируют директорию с базой и каждый запустит свой экземпляр postgres'а
в статье указано, что сделать чтобы это не происходило.
Когда группа STARTED на конкретном хосте в кластере, на другой ноде — данного lvm диска даже не числится. Диском управляет кластер — где группа, там и диск.
Проверено.
Когда группа STARTED на конкретном хосте в кластере, на другой ноде — данного lvm диска даже не числится. Диском управляет кластер — где группа, там и диск.
Проверено.
Ситуация: node1.local.lan работает группа на нем, в момент времени node2.local.lan перестает "видеть" по сети node1.local.lan(с самим node1.local.lan при этом все хорошо). Тогда node2.local.lan начинает считать, что node1.local.lan отвалилась, поэтому поднимает у себя Resource Group: PGCLUSTER.
Это не редкий случай при виртуализации.
Это не редкий случай при виртуализации.
на 2х нодах сплит-брейн как разруливается?
С интересом читаю про Open Source кластеризацию. У Микрософта такие ситуации разруливаются witness-ресурсом.
Как мне помнится, во времена 2003, было совсем по старомодному — у кого кворумный диск, тот и победил. С тех пор как появились кластеры более чем из двух узлов, побеждает та группа, у которой на 1 голос больше, на четном числе узлов можно так же давать диску голос.
Очень интересно описание реализации как для SCSI-2, так и для SCSI-3
Суть такая, что текущий владелец держит диск, а конкуренты пытаются его "отобрать", но дают владельцу достаточно времени чтобы отбить нападки. Если владелец — не жилец, диск отбирается.
Работает эта микрософтова реализация просто и надежно. Здесь нельзя настроить по тому же принципу?
Как мне помнится, во времена 2003, было совсем по старомодному — у кого кворумный диск, тот и победил. С тех пор как появились кластеры более чем из двух узлов, побеждает та группа, у которой на 1 голос больше, на четном числе узлов можно так же давать диску голос.
Очень интересно описание реализации как для SCSI-2, так и для SCSI-3
Суть такая, что текущий владелец держит диск, а конкуренты пытаются его "отобрать", но дают владельцу достаточно времени чтобы отбить нападки. Если владелец — не жилец, диск отбирается.
Работает эта микрософтова реализация просто и надежно. Здесь нельзя настроить по тому же принципу?
Две машины, shared storage и
Данная конструкция продержится до первого split-brain, при котором она радостно рухнет вместе с WAL-логами Postgres или ФС/LVM.
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
Данная конструкция продержится до первого split-brain, при котором она радостно рухнет вместе с WAL-логами Postgres или ФС/LVM.
Вижу, что split braint — больная тема). Диски — FC. В конфигурациях Active/Active такое быть может, несомненно. В Active/Passive — отнюдь. Единственное, что может быть в Active/Passive — база уйдет in recovery в момент переезда, когда данные не успеют сброситься на диск, но для этого надо тюнинг postgresql.conf (fsync, sync.commit)
Дабы закрыть тему со split braint, предлагаю Вам поднять на виртуалах данную конфигурацию и проверит все на деле.
Дабы закрыть тему со split braint, предлагаю Вам поднять на виртуалах данную конфигурацию и проверит все на деле.
Диски — FC. В конфигурациях Active/Active такое быть может, несомненно. В Active/Passive — отнюдь.
FC диски доступны на обоих узлах одновременно. Если используется lvm2 (не clvm), то монтировать тома могут оба узла с негарантируемым результатом. С clvm результат более предсказуем, но при split brain также не гарантируется. Именно для избегания ситуации split brain в кластерном ПО предусмотерны такие фичи как fencing и в частности STONITH в pacemaker (который немного больше чем простой фэнсинг).
Вот эта часть:
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
Для lvm2, кластер А/А и A/P (без поддержки кластеризации в lvm), должна быть такой:
pcs property set stonith-enabled=true
pcs property set no-quorum-policy=ignore
Для clvm, кластер А/А:
pcs property set stonith-enabled=true
pcs property set no-quorum-policy=fence
Для clvm кластер А/P:
pcs property set stonith-enabled=true
pcs property set no-quorum-policy=ignore
Очевидно, что STONITH активирован в любой конфигурации.
Он будет нужен даже тогда, когда у Вас не разделяемое дисковое пространство используется, а независимые диски для каждого узла, и между ними репликация master/slave.
А ещё лучше, для fensinga предусмотреть сырой том (не lvm)! И всегда держать включённым
А кто может поделиться опытом построения High Avaibility (99,9% — 99,99%) PostgreSQL в условиях Azure Maintance, когда машины сами включаются и выключаются попеременно?
Рассматривал вариант с PgPool, но в нем была проблема в том, что при выключении мастера и его восстановлении, он не знал о том, что другая машина стала мастером. PgPool некорректно работал одновременно на 2 машинах. Да и честно как то это костыльно выглядело.
Рассматривал вариант с PgPool, но в нем была проблема в том, что при выключении мастера и его восстановлении, он не знал о том, что другая машина стала мастером. PgPool некорректно работал одновременно на 2 машинах. Да и честно как то это костыльно выглядело.
Use STONITH. см. пост
Объясните, пожалуйста, на пальцах, что будет делать stonith, если удаленная машина недоступна совсем — в том числе недоступен и stonith-девайс. Ведь, насколько я понимаю, сигнал о выключении посылается точно так же по сети, только через другой сетевой интерфейс. Что будет, если и он недоступен?
На пальцах не получится, вот подробная статья с простым описанием ourobengr.com/ha
Пробую объяснить на пальцах (не уверен что получится)
Если у Вас есть диск кворума, то именно с его помощью определяется живы ли соседи в кластере (при отсутствии сети и при условии, что SAN это отдельная сеть со своими коммутаторами).
Даже если у Вас пропала сеть передачи данных, то у Вас есть устройство для кворума (находящееся в сети хранения данных — SAN), ч-з которое ноды определяют кто из них главный в данный момент. И вот именно опция pcs property set no-quorum-policy=fence говорит нам, что если кворум недоступен данному узлу он должен поступить в соответствии с полиcи. fence — означает, — умереть. То есть узел перестаёт считать себя главным.
Split brain, — ситуация в которой каждый из узлов считает, что он главный.
Для решения этой ситуации есть два механизма:
а) STONITH — пристрели соседний узел. Очевидно, что данный метод будет работать только если осталась возможность узлов коммуницировать. Для этого оборудование и интерфейсы в кластерной инфраструктуре должны быть избыточно резервированы и желательно иметь внешнее устройство (например ИБП APC, которые считаются очень надёжными), к которому узлы кластера всё время обращаются, для того что-бы определить, есть-ли сеть вообще.
б) fencing — умри сам. см. выше.
Если у Вас есть диск кворума, то именно с его помощью определяется живы ли соседи в кластере (при отсутствии сети и при условии, что SAN это отдельная сеть со своими коммутаторами).
Даже если у Вас пропала сеть передачи данных, то у Вас есть устройство для кворума (находящееся в сети хранения данных — SAN), ч-з которое ноды определяют кто из них главный в данный момент. И вот именно опция pcs property set no-quorum-policy=fence говорит нам, что если кворум недоступен данному узлу он должен поступить в соответствии с полиcи. fence — означает, — умереть. То есть узел перестаёт считать себя главным.
Split brain, — ситуация в которой каждый из узлов считает, что он главный.
Для решения этой ситуации есть два механизма:
а) STONITH — пристрели соседний узел. Очевидно, что данный метод будет работать только если осталась возможность узлов коммуницировать. Для этого оборудование и интерфейсы в кластерной инфраструктуре должны быть избыточно резервированы и желательно иметь внешнее устройство (например ИБП APC, которые считаются очень надёжными), к которому узлы кластера всё время обращаются, для того что-бы определить, есть-ли сеть вообще.
б) fencing — умри сам. см. выше.
Ничего хорошего — кластер превратится в тыкву, вплоть до того что corosync от количества служебных сообщений начнет падать в корку, перезапускаться и снова падать.
Sevchik403, настраивал как с отдельно стоящими PGPOOL-II (2 хоста+WatchDog), так и с PGPOOL-II непосредственно на самих хостах с БД.
Когда мастер падал, отрабатывал Failover.sh на слэйве — создавал trigger_file и слэйв становился мастером — это билет в один конец, т.е. мастер упавший придется восстанавливать ручками, например, через pg_basebackup со слэйва, потому как если упавший мастер поднять — вуаля! и у нас 2 мастера (во всяком случае тесты показывали именно такое).
Когда мастер падал, отрабатывал Failover.sh на слэйве — создавал trigger_file и слэйв становился мастером — это билет в один конец, т.е. мастер упавший придется восстанавливать ручками, например, через pg_basebackup со слэйва, потому как если упавший мастер поднять — вуаля! и у нас 2 мастера (во всяком случае тесты показывали именно такое).
Как раз таки такого я и добился, но это критично при Azure Maintance. Машины выключаются/включаются с перерывом в 30 минут и это происходит в течении 3 суток. То есть неизвестно в какой именно момент времени это произойдет. Вы можете спать, а машины в этот момент могут перезагрузиться и вы просто не успеете ничего сделать.
К автору поста. Вы меня извините, но это статья из серии "установил линукс — напиши пост на хабре". Даже про кворум ничего не сказано, а ведь это минимально-необходимая и важнейшая штука. Про stonith я выше вопрос задал — может быть, кто-нибудь сможет разъяснить, наконец, имеет ли stonith вообще смысл, если все машины, например (для вырожденного случая), виртуалки и разбросаны по разным датацентрам по всему миру.
В случае виртуалок stonith настраивается с участием гипервизора. Гипервизор делает turn off (выдернуть кабель питания) виртуалке для предотвращения split brain.
К использованию stonith надо применять немного другой подход. Он должен применяться в ситуациях, когда ресурс должен гарантированно обслуживаться или использоваться только одним сервером в кластере. Необходимость применения не зависит от конфигурации серверов, будь то виртуалки в разных ДЦ или физические машины в одной стойке.
В случае shared storage — необходимо убедиться, что ни один другой сервер не использует том (иначе крайне вероятно разрушение ФС) — в данной ситуации должен использоваться STONITH.
В случае shared ip — опять же, если два сервера подцепят один IP, будут проблемы (здесь хотя бы руками можно откатиться на рабочий вариант).
С другой стороны, если фенсинг не нужен, как правило, можно обойтись вообще без pacemaker.
В случае shared storage — необходимо убедиться, что ни один другой сервер не использует том (иначе крайне вероятно разрушение ФС) — в данной ситуации должен использоваться STONITH.
В случае shared ip — опять же, если два сервера подцепят один IP, будут проблемы (здесь хотя бы руками можно откатиться на рабочий вариант).
С другой стороны, если фенсинг не нужен, как правило, можно обойтись вообще без pacemaker.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync