Обработка отказа IP с 2 узлами на другой подсети: не может проверить с помощью ping-запросов виртуальный IP от второго узла?
Я настоятельно рекомендовал бы взятие:
Масштабирование миллионам посетителей в день не является тривиальным предметом и потребует некоторого серьезного тестирования планирования и загрузки. Википедия, например, выполняет клетку приблизительно приблизительно 350 серверов в средстве соразмещения в Тампе, Флорида (я видел его; у меня есть серверы там также), который выполняет один из наиболее высоко посещаемых сайтов в мире. Их архитектура очень отличается от сайта как Facebook, который, как оценивалось, выполнял приблизительно 60 000 серверов в различных дата-центрах во всем мире.
Я думаю, проблема не в конфигурации кластера, а в вашей архитектуре маршрутизации.
Агент ресурсов VIPArip управляет локальным кваггой для отправки обновлений маршрутизации. Но вам также необходимо использовать эти обновления маршрутизации, чтобы изменить маршруты, чтобы они указывали на активный сервер. Попробую объяснить, как это работает.
Посмотрите на картинку. HA1 и HA2 - это члены кластера linux-ha с запущенным quagga. Синий маршрутизатор прослушивает RIP от обоих сетевых каналов.
Когда vip поднимается на HA1, quagga отправляет обновление RIP на синий маршрутизатор. Он добавляет префикс vip в свою таблицу маршрутизации с 192.168.1.2 nexthop.
Когда происходит переключение, vip отключается на HA1, и quagga полностью останавливается, поэтому обновления не отправляются. Синий маршрутизатор удалит запись таблицы маршрутизации по истечении тайм-аута, даже если VIP не поднимется на HA2. И когда VIP переходит на HA2, он запускает quagga и отправляет обновления RIP. Синий маршрутизатор добавит запись в таблицу маршрутизации с адресом 192.168.2.2 nexthop.
Можно использовать viparip в более сложной топологии сети, просто убедитесь, что пограничные маршрутизаторы получают обновления маршрутизации по всей сети.