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

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

Еще есть очень классная штука — Heartbeat )
Вещщщ, однажды настраивал.)))
все бы ничего, но: получаеться что один сервер бездельничает. Если бы сделать так, что бы, например, база данных работала со slave-а, а все остальные службы с master — было бы замечательно :)
heartbeat позволяет это сделать. Правда с 2 узлами в кластере получится, что каждый из них должен во время сбоя держать нагрузку обоих.
Но если такое недопустимо — всегда можно сделать резервирование по схеме n+1
А какие свитчи поддерживают carp? Там же вроде одинаковые маки используются и свитч при этом не должен сойти с ума.
Одинаковые маки не используются. Свич марштрутизирует по arp. У свича должен быть отключен port-security.
так узел отвечает arp'ом только когда ему передаётся управление. а мастер шлёт мультикаст по которому узлы определяют, что он еще жив. мастер загнулся, слейв управление перехватил, arp оповещение послал, таблицы обновились и по новой. стоит отметить, что переключение всё равно занимает время, не долгое, но может хватить, чтобы потерять пару пакетов.
чем лучше keepalived?
он не лучше, он — альтернатива. выбирает в конечном итоге админ. эмпиричиски.
лицензией
плохо что ТОЛЬКО лицензией
А как с этим делом в solaris?
В Солярисе это возложено на плечи Sun Cluster/OHAC. Есть еще ILB, но он пока только в dev билде opensolaris-а
поясните пожалуйста, как один из слейвов должен узнать что ему пора бы подняться?
и второй вопрос: как скопище слейвов поделят между собой право стать мастером?
Мастер-хост группы регулярно рассылает объявления по сети, с целью оповестить остальные машины группы, что он все еще работоспособен. В случае, если резервной машиной объявление не будет получено в течение заданного интервала, то она перехватывает функции мастер-хоста (та из них, которая имеет меньшие значения UCARP_ADVBASE).
спасибо. теперь всё ясно!
Кстати, Вы говорите, что переключение происходит не мгновенно. С какой периодичностью происходит опрос, и настраивается ли это? Есть ли механизмы, позволяющие полностью исключить потерю пакетов (хитрые свичи или еще что-нибудь)?
Полностью исключить потерю пакетов при любой аварии не сможет никто :)
Если есть такая задача, то лучше поглядет в сторону cisco content gateway. А если посчитаете их слишком дорогими — то может быть проще смириться с потерей пакетов? :)
Понятно, спасибо :). Пока что такой задачи не стоит, но я уверен, что она через какое-то время может возникнуть.
опрос — не совсем точное понятие. слейв не спрашивает мастера, он получает от него пакеты. если в определённый момент пакет не пришёл — тогда и нужно спешить на помощь. «определённый момент» настраиваится опцией --deadratio=NUM. Где num по умолчанию равен 3.
Сначала прочитал как «CRAP».)))
Хитрый вопрос вдогонку.

Вот переключили мы IP. А у нас в сети стоит не тупой хаб, а средней интеллектуальности свитч, кеширующий маршруты по MAC-адресу. Данный пакет решает эту ситуацию?
ucarp посылает arp update, так что средней интеллектуальности свитч поймет, что IP переключился. Главное чтобы не было port-security и IP мог работать на новом порту.
Спасибо
Необходимо отметить, что данное решение работает только если мастер никак не отвечает по сети и никак не помогает когда система «прогнулась» под нагрузкой или не работает приложение. То есть например в случае reverse proxy возможна ситуация когда сервер захлебнется от большого кол-ва конектов, но при этом будет исправно отвечать на ARP при этом выключить его через carp не будет никакой возможности из-за --preempt. Единственный выход в подобной ситуации выключать мастер физически например порт на свиче.

Мы используем CARP в связке с внешним арбитром, который следит за тем что мастер сервер работает на уровне приложения и таким образом подстраховывает от описаного мною случая.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории