Кажется, что в Linux есть много вариантов для предоставления виртуального IP-адреса для переключения между несколькими хостами. Некоторые из обнаруженных мною - это сердцебиение, vrrpd, carp и keepalived.
В Linux у меня есть только опыт работы с сердцебиением (и я использовал HSRP в Cisco). Имеют ли эти различные варианты какое-либо особое преимущество, когда речь идет о предоставлении виртуального IP-адреса, который будет шлюзом для хостов в локальной сети. Одна функция, которую я хотел бы иметь, - это возможность отслеживать другой интерфейс. Так, например, если виртуальный IP-адрес используется совместно eth0 на сервере A и eth0 на сервере B, я хотел бы, чтобы он имел возможность переключаться на другой сервер, если он обнаруживает, что eth1 вышел из строя. Я также хотел бы иметь возможность установить предпочтительный хост.
Одним из основных преимуществ, которые я обнаружил с Heartbeat, была возможность настроить его для использования нескольких точек мониторинга. В соответствии с рекомендуемой по умолчанию конфигурацией он имеет несколько точек мониторинга между последовательным восходящим каналом и мониторингом сети.
Например, можно создать сценарий ресурса пульса для мониторинга демона и в случае сбоя демона инициировать аварийное переключение.
CARP основан на HSRP, который, как вы определили, контролирует интерфейс. Это, безусловно, имеет место, и мне нравится технология, но в зависимости от роли сервера вы можете найти сердцебиение преимуществом.
Я полагаю, можно было бы утверждать, что даже те протоколы, которые не поддерживают это, могли бы иметь сценарий, написанный для имитации некоторого поведения, которое, по сути, является тем, что я описал с помощью сердцебиения.
Хотя я никогда не использовал keepalived, похоже, что он похож на ldirectord в том, что он отслеживает хосты LVS и удаляет их из VIP в случае сбоя. Я бы не стал рассматривать это в той же категории, что и сердцебиение или CARP.
Мы используем виртуальные IP-адреса на основе коммутатора / балансировщика нагрузки, которые выполняют циклический перебор на основе теста доступности службы, такого как httpget или аналогичный. Это снимает нагрузку с сервера и снимает с него ответственность - каждый думает, что отвечает только ему. Тогда для наших реальных кластеров (Oracle, WebLogic, ZXTM и т. Д.) Верна та же модель, но само приложение кластеризации гарантирует, что серверы находятся в контакте друг с другом, но IP-адреса, обращенные к клиенту, по-прежнему остаются «обычными». По сути, мы никогда не находили причин для чего-либо, кроме «обычных» IP-адресов, но мне было бы интересно узнать ваш запланированный вариант использования. О, и затем мы можем использовать переключатель / LB, чтобы определить, какие серверы находятся в / не обслуживаются.
Отработка отказа - отстой - никогда не знаешь, сработает ли он, пока что-то не выйдет из строя. Как и Chopper3, я всегда использовал балансировку нагрузки, если это вообще возможно.
С.