Я пытаюсь выяснить, есть ли какие-либо способы иметь более одного шлюза по умолчанию (в стратегии переключения при отказе) в одной подсети. Если один шлюз выходит из строя, я хотел бы, чтобы серверы переключились на резервный шлюз по умолчанию. Я изучал возможность использования CARP, но он несовместим с облачными средами.
Избыточность шлюза обычно выполняется резервным шлюзом, выполняющим замену IP, когда первый шлюз выходит из строя. Обычно это включает активный мониторинг шлюза, чтобы убедиться, что он работает. Вы также создадите резервирование на другой стороне шлюза, иначе дальняя сторона шлюза останется единственной точкой отказа.
Избыточность по-прежнему уязвима для единичных точек отказа, если между маршрутами есть что-то общее. Это может быть кабель, оптоволоконный жгут, источник питания или что-то еще. Я потерял связь по резервным каналам, когда оптоволоконный кабель был отрезан за много миль от нашего сайта. Он был разрезан в нескольких футах от места разделения волоконных трасс.
Учитывая надежность текущего шлюзового оборудования, в большинстве случаев я бы полагался на один шлюз.
Все упомянутые выше протоколы (HSRP, VRRP, CARP, GLBP) должны полностью поддерживать ваши потребности.
Все они основаны на концепции «членства в группе», которая обычно управляется с помощью многоадресной рекламы. Как правило, группа, предоставляющая резервный IP-адрес, может присоединяться и выходить из нее узлами на лету, при этом один участник предоставляет услуги от имени группы или десятки участников. Потеря или исчезновение узла вызывает захват общего адреса оставшимися узлами в группе.