Как стать автором
Обновить

Комментарии 14

К вопросу о борьбе с сплитбрейном в кластерах 1+1, я как раз об этом сейчас много думаю.

Мне кажется, самым разумным решением является включение «клиентского» интерфейса кластера в бондинг интерфейсов, которые обеспечивают синхронизацию.

Логика такая: если мы теряем линк с кластером на «нашей» половинке кабеля, то мы теряем и линк с клиентами. Если мы потеряли линк на «их» половинке, то ситуация строго зеркальная — они не имеют линка с клиентами, а мы продолжаем их обслуживать.

Понятно, что трафик по такому линку гонять не надо, но для подстраховки вынимания кабеля — самое то.
Не совсем понял схему подключения. Но ваше решение исключает крос-кабель, не так ли? На мой взгляд, в кластере 1+1, крос кабель очень важен и прост. А в таких системах, чем проще сделал — тем легче и быстрее чинить ;)
Не, не так.

терминология: клиентский порт — тот порт, через который идут клиентские запросы. кластерный порт — то, через что идёт репликация.

Делается бонд между кластерным портом (который кроссом соединяется) и туннелем в клиентском порте. Если кто-то вынет кластерный провод, трафик пойдёт через туннель в клиентском порте.

Если кто-то вынет клиентский провод, кластер останется жить.

Если кто-то вынет оба провода, то мы имеем гарантию, что клиент не придёт на сплитбрейновый сервер (т.к. клиентский порт отключен). Когда воткнут клиентский порт, то ПО тут же обнаружит сплитбрейн и отвалится.
Интересная идея. Нада будет погонять её на тестовом стенде.
Ага. Пока у меня это тоже теоретические изыскания.

Меня очень пугает состояние, когда у нас есть primary/primary drbd с порванным кластреным линком. Что оно там на диске натворит, страшно подумать.
НЛО прилетело и опубликовало эту надпись здесь
зачем указывать второй локейшн если у нас только один вип айпи?

Второй location указан для того, чтобы в случае отказа ноды first.local он мигрировал на second.local. Т.к. не задав значение score для second.local при условии не-симметричного кластера (symmetric-cluster=«false») он на ней просто никогда не запустится. Если кластер симметричный (по умолчанию так и есть), то указывать не нужно. Однако я бы не советовал делать так — мы теряем предсказуемость оценки размещения.

так этим же занимается corosync/heartbeat

corosync/heartbeat — занимаются тем, что мониторят состояние жизни нод, если говорить грубо. И для этого им выделяется, как правило, отдельный прямой (крос) линк.
В статье описывается размещения ресурсов привязанных к отличным от этих интерфейсов. К примеру на кластере может быть много сетевых интерфейсов — внутрення сеть, внешняя, DMZ. И мнрожество ресурсов привязанных только к одной из них. В таком случае падения какого-то линка не должна приводить к мигарции всех ресурсов класстера, а переносить только один. Тем самым уменьшая врямя простоя.
НЛО прилетело и опубликовало эту надпись здесь
Использовать STONITH в двухнодном кластере при пропаже линков — бесмысленно. Ноды просто убъют друг друга. Мы получим, так называемый deathmatch,: одна убивает другую — другая перезагружается и убивает первую и тд. Т.к. не понятно какая из нод «правильная» и нету кворума.
В свою очердь STONITH нужен для убийства ноды с зависшим ресурсом. Однако тут много тонкостей с таймаутами мониторинга и остановки ресурсов. Можно убить ноду, которая просто замешкалась с отмонтирование файловой системы, ожидая, когда её просто освободит процесс. Это вообще отдельная большая тема.
НЛО прилетело и опубликовало эту надпись здесь
Как я писал нужно дублировать соединения, выносить их отдельно. Также как вариант — добавить третью ноду, которая будет находиться в состоянии standby и будет участвовать только для кворума. К примеру, в роли такой ноды, может вуступать роутер либо любой другой сервер в вашей сети.
Пожалуйста, расскажите подробнее про вариант?
Отличная статья, спасибо. Когда-то боролся с репликацией MySQL при использовании в кластере, но давно это было, и MySQL еще не имела таких развитых средств, как сейчас, и пришлось использовать DRDB. Теперь с этим проще, хотя DRDB тоже не потерял своей актуальности.
с DRBD мы получаеи уверенность в том, что данные на обоих машинах консинстентны (использование типа С), однако мы получаем не Hot Spare. Т.к. нужно время на старт сервиса Mysql, который, при таком старте, будет проверять таблицы базы.
Решение с мастер-мастер репликацией обладает своими недостатками, кроме вероятности потерять часть транзацкций, к примеру, — не правильно разогретый кэш.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории