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