Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
К вопросу о борьбе с сплитбрейном в кластерах 1+1, я как раз об этом сейчас много думаю.
Мне кажется, самым разумным решением является включение «клиентского» интерфейса кластера в бондинг интерфейсов, которые обеспечивают синхронизацию.
Логика такая: если мы теряем линк с кластером на «нашей» половинке кабеля, то мы теряем и линк с клиентами. Если мы потеряли линк на «их» половинке, то ситуация строго зеркальная — они не имеют линка с клиентами, а мы продолжаем их обслуживать.
Понятно, что трафик по такому линку гонять не надо, но для подстраховки вынимания кабеля — самое то.
Мне кажется, самым разумным решением является включение «клиентского» интерфейса кластера в бондинг интерфейсов, которые обеспечивают синхронизацию.
Логика такая: если мы теряем линк с кластером на «нашей» половинке кабеля, то мы теряем и линк с клиентами. Если мы потеряли линк на «их» половинке, то ситуация строго зеркальная — они не имеют линка с клиентами, а мы продолжаем их обслуживать.
Понятно, что трафик по такому линку гонять не надо, но для подстраховки вынимания кабеля — самое то.
Не совсем понял схему подключения. Но ваше решение исключает крос-кабель, не так ли? На мой взгляд, в кластере 1+1, крос кабель очень важен и прост. А в таких системах, чем проще сделал — тем легче и быстрее чинить ;)
Не, не так.
терминология: клиентский порт — тот порт, через который идут клиентские запросы. кластерный порт — то, через что идёт репликация.
Делается бонд между кластерным портом (который кроссом соединяется) и туннелем в клиентском порте. Если кто-то вынет кластерный провод, трафик пойдёт через туннель в клиентском порте.
Если кто-то вынет клиентский провод, кластер останется жить.
Если кто-то вынет оба провода, то мы имеем гарантию, что клиент не придёт на сплитбрейновый сервер (т.к. клиентский порт отключен). Когда воткнут клиентский порт, то ПО тут же обнаружит сплитбрейн и отвалится.
терминология: клиентский порт — тот порт, через который идут клиентские запросы. кластерный порт — то, через что идёт репликация.
Делается бонд между кластерным портом (который кроссом соединяется) и туннелем в клиентском порте. Если кто-то вынет кластерный провод, трафик пойдёт через туннель в клиентском порте.
Если кто-то вынет клиентский провод, кластер останется жить.
Если кто-то вынет оба провода, то мы имеем гарантию, что клиент не придёт на сплитбрейновый сервер (т.к. клиентский порт отключен). Когда воткнут клиентский порт, то ПО тут же обнаружит сплитбрейн и отвалится.
зачем указывать второй локейшн если у нас только один вип айпи?
Второй location указан для того, чтобы в случае отказа ноды first.local он мигрировал на second.local. Т.к. не задав значение score для second.local при условии не-симметричного кластера (symmetric-cluster=«false») он на ней просто никогда не запустится. Если кластер симметричный (по умолчанию так и есть), то указывать не нужно. Однако я бы не советовал делать так — мы теряем предсказуемость оценки размещения.
так этим же занимается corosync/heartbeat
corosync/heartbeat — занимаются тем, что мониторят состояние жизни нод, если говорить грубо. И для этого им выделяется, как правило, отдельный прямой (крос) линк.
В статье описывается размещения ресурсов привязанных к отличным от этих интерфейсов. К примеру на кластере может быть много сетевых интерфейсов — внутрення сеть, внешняя, DMZ. И мнрожество ресурсов привязанных только к одной из них. В таком случае падения какого-то линка не должна приводить к мигарции всех ресурсов класстера, а переносить только один. Тем самым уменьшая врямя простоя.
Использовать STONITH в двухнодном кластере при пропаже линков — бесмысленно. Ноды просто убъют друг друга. Мы получим, так называемый deathmatch,: одна убивает другую — другая перезагружается и убивает первую и тд. Т.к. не понятно какая из нод «правильная» и нету кворума.
В свою очердь STONITH нужен для убийства ноды с зависшим ресурсом. Однако тут много тонкостей с таймаутами мониторинга и остановки ресурсов. Можно убить ноду, которая просто замешкалась с отмонтирование файловой системы, ожидая, когда её просто освободит процесс. Это вообще отдельная большая тема.
В свою очердь STONITH нужен для убийства ноды с зависшим ресурсом. Однако тут много тонкостей с таймаутами мониторинга и остановки ресурсов. Можно убить ноду, которая просто замешкалась с отмонтирование файловой системы, ожидая, когда её просто освободит процесс. Это вообще отдельная большая тема.
Отличная статья, спасибо. Когда-то боролся с репликацией MySQL при использовании в кластере, но давно это было, и MySQL еще не имела таких развитых средств, как сейчас, и пришлось использовать DRDB. Теперь с этим проще, хотя DRDB тоже не потерял своей актуальности.
с DRBD мы получаеи уверенность в том, что данные на обоих машинах консинстентны (использование типа С), однако мы получаем не Hot Spare. Т.к. нужно время на старт сервиса Mysql, который, при таком старте, будет проверять таблицы базы.
Решение с мастер-мастер репликацией обладает своими недостатками, кроме вероятности потерять часть транзацкций, к примеру, — не правильно разогретый кэш.
Решение с мастер-мастер репликацией обладает своими недостатками, кроме вероятности потерять часть транзацкций, к примеру, — не правильно разогретый кэш.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Pacemaker HA: сетевые соединения и динамическое размещение ресурсов кластера