Стратегия отработки отказа в Интернете при хостинге услуг со стат
Учитывая, что у вас есть две сети со статическими ips:
сеть A.) 66.xxx.xxx.9 (для доступа к этой сетевой записи DNS используется myservice.mydomain.com)
а также
сеть B.) 66.xxx.xxx.29 ((для доступа к этой сетевой записи DNS используется myservice.backupmydomain.com))
Первая сеть, которую вы обычно используете, а вторая сеть является резервной.
У вас есть служба, размещенная на компьютере в сети.
Когда сеть A выходит из строя, маршрутизатор переключается на сеть B. Но вам все равно нужен какой-то способ пересылки запросов из внешнего мира от A к B. В противном случае клиент за пределами сети постучится в дверь и обнаружит, что A не работает.
Как автоматически пересылать данные в сеть B, когда сеть A не работает, если вы отправляете пакеты извне? По сути, я хотел бы сделать две вещи, когда сеть А не работает. 1.) Переключитесь на сеть B. 2.) Скажите всем пакетам, идущим в сеть A, вместо этого перейти в сеть B.
2 ответа
Есть несколько обходных путей, но ни один из них не является автоматическим / бесшовным. Самый простой - изменить запись DNS, когда одна из сетей не работает. Некоторые провайдеры DNS предлагают "проверки работоспособности", которые могут автоматизировать это для вас, но при распространении новых записей DNS все равно будет время простоя.
Если вы идете по этому пути, держите TTL на ваших записях DNS как можно короче.
Другой альтернативой может быть использование балансировщика нагрузки в облаке. DNS будет указывать здесь, и подсистемы балансировки нагрузки будут динамически отправлять трафик на соответствующие серверы по мере их уменьшения / увеличения. LB - это новая единая точка отказа, но при правильной разработке это может работать довольно хорошо.
Внутри вашей сети для исходящего трафика вы можете запустить FHRP* между двумя вашими маршрутизаторами. Это потребует от вас переустановки устройства, поскольку у хостов будет новый шлюз по умолчанию. Вы должны создать или повторно использовать VIP [виртуальный IP-адрес] и назначить его внутри обоих маршрутизаторов.
Однако протоколы по конфигурации или по умолчанию автоматически перенаправляют трафик на основании настраиваемых "критериев". Как правило, вы отслеживаете подключение к адресу уровня 3 (например, к шлюзу WAN по умолчанию), вам необходимо обратиться к документации и набору функций ваших маршрутизаторов.
Общая идея заключается в том, что когда выбранный вами FHRP обнаруживает отключение интернета, он позволяет вашему "резервному" маршрутизатору (или активному, если это необходимо) начать отвечать на запросы ARP виртуального MAC-адреса и начинает пересылку трафика с тем же VIP-адресом. общий для основного маршрутизатора в качестве его источника. Опять же, зависит от протокола, но некоторые могут использовать "preempt", который будет свергнут и вернется обратно в первичную сеть после исправления условия сбоя. Некоторые дают более детальные настройки, которые действительно могут подстроиться под большинство спецификаций.
Кроме того, в зависимости от ваших моделей трафика и потока вы можете загрузить общий ресурс или баланс сеанса между обоими каналами для исходящего трафика. Это дает преимущество ~100% для исходящих сигналов по двум каналам (~50/~50) - вместо 100% по одному каналу. Это асимметричная маршрутизация, и иногда она нежелательна. Все действительно зависит от ваших целей и макета. Примером этого являются пакеты, исходящие из вашей резервной схемы, полученные клиентом, но ответы отправляются на ваш основной DNS. Вышел один роутер, в другой. Это может быть проблемой или решением проблемы.
Это не заботится о вашем дополнительном требовании к DNS, но обеспечивает внутреннюю избыточность.
- Первый протокол избыточности прыжков (VRRP/GLBP/HSRP/CARP/NSRP и т. Д.)