Вопрос или проблема
У меня есть 2 провайдера интернет-услуг и сервер с двумя IP-адресами, что-то вроде этого:
eth0: 161.0.0.2
eth1: 171.0.0.2
Я настроил www.example.com с двумя записями A, чтобы у меня был балансировщик нагрузки DNS.
Приложение работает хорошо таким образом, а сервер на Linux настроен на маршрутизацию на основе политики, чтобы избежать ассиметричной маршрутизации соединений. Исходящие пакеты выходят через тот же интерфейс, через который были установлены входящие соединения.
Теперь единственная оставшаяся проблема в том, что я настроил единственный шлюз по умолчанию, 161.0.0.1. Я хотел бы достичь либо балансировки нагрузки, либо хотя бы резервирования для исходящих соединений.
Один из способов, как я мог бы это сделать, – это создание cron-задачи, которая будет регулярно пинговать некоторый хост, и если пинг не удается, изменить маршрут по умолчанию на 171.0.0.1, но этот метод кажется слишком ненадежным.
Есть ли какие-нибудь предложения по резервированию маршрута по умолчанию?
Если вы не хотите углубляться в настоящие протоколы маршрутизации, лучшее предложение – это постоянно работающая программа, которая регулярно пингует два первых прыжка (с вашими вымышленными адресами, это будет 161.0.0.1 и 171.0.0.1) и устанавливает тот, который отвечает, как маршрут по умолчанию. Вы, вероятно, сможете сделать это на любом языке сценариев, хотя я бы, наверное, сделал это на C. На самом деле, я уже делал это (но сейчас не могу найти этот код). Это достаточно просто сделать правильно, и написание на C значительно снижает нагрузку на ваш сервер.
У меня есть ответ, хотя вам он может не понравиться. Множественные записи RR A в DNS не обеспечат вам высокую доступность. Ответ в значительной степени зависит от клиента/их DNS-сервера.
Если клиент решает IP-адрес провайдера, который не работает, он будет хранить его в кэше и не будет проверять другой, так что у вас будет группа клиентов с доступом и другие, которые жалуются, что сайт не работает.
Низкие TTL также не помогут вам, так как некоторые DNS-клиенты/крупные провайдеры интернет-услуг известны тем, что игнорируют низкие TTL, так что даже с НИЗКИМИ TTL в DNS у вас будут группы клиентов, не имеющих доступа.
Одно из возможных решений – привлечь услуги CDN, такого как cloudflare, и настроить там оба IP-адреса.
Другой, более сложный способ получить резервирование для внешних маршрутов – запросить номер AS, используя независимую от провайдера адресацию IP для обеих сетей и выполнять BGP-пиринговые соединения с вашими провайдерами.
Что касается маршрута при выходе, чтобы воспользоваться трафиком обоих провайдеров, я советую создавать политики для использования соответствующего шлюза, маршрутизация на основе источника. http://www.novell.com/support/kb/doc.php?id=7008874
Ответ или решение
Резервный маршрут по умолчанию при отключении основного канала
В условиях, когда у вас имеется два интернет-провайдера и сервер с двумя IP-адресами, такая конфигурация предоставляет возможности для повышения отказоустойчивости и оптимизации маршрутизации. В данном случае вы используете два IP-адреса (161.0.0.2 и 171.0.0.2) и настроили DNS с двумя записями A для балансировки нагрузки. Однако, проблема с одним маршрутом по умолчанию может стать узким местом в вашей конфигурации.
Проблематика
Ваша текущая конфигурация делает ставку на одно значение маршрута по умолчанию (162.0.0.1), что в случае его недоступности приведет к потере соединения. Использование скриптов, выполняемых по заданному расписанию, для переключения маршрутов, как вы упомянули, является ненадежным методом. Существуют более стабильные и эффективные способы реализации автоматического переключения.
Решения для обеспечения отказоустойчивости
-
Мониторинг доступности шлюзов:
Рекомендуется создать процесс, который будет регулярно проверять доступность обоих шлюзов (161.0.0.1 и 171.0.0.1). Это можно реализовать на любом языке программирования, но предпочтительно использовать низкоуровневые языки, такие как C. Такой подход снизит нагрузку на сервер и обеспечит более эффективное реагирование на сбои. -
Настройка мульти-источник маршрутизации:
Вместо установки одного маршрута по умолчанию, вы можете настроить политику маршрутизации, которая позволит использовать различные шлюзы в зависимости от исходного IP-адреса. Этот эффект достигается с помощью правила политической маршрутизации, которое соотносит входящие соединения с исходящими маршрутизациями на основе IP-адресов источника. -
Реализация BGP:
Если ваш бизнес требует высокой доступности и вы хотите обеспечить резервирование на уровне сети, имеет смысл рассмотреть получение независимого автономного системного номера (ASN) и совершение BGP-пиринга с вашими провайдерами. Это гораздо более сложный, но и более надежный метод управления маршрутизацией с высоким уровнем автоматизации и отказоустойчивости. -
Использование CDN:
Оптимизация DNS-системы с помощью внедрения Content Delivery Network (CDN), такой как Cloudflare, представляет собой возможность обеспечения динамического изменения IP-адресов, чтобы распределить нагрузку и повысить его доступность. CDN могут обрабатывать аварийные ситуации, перенаправляя трафик, если один из узлов недоступен.
Заключение
Для достижения высокой доступности и быстрого реагирования на сбои в сети, создание гибкой и многоуровневой структуры маршрутизации становится необходимостью. Используя вышеописанные методы, вы сможете минимизировать простои и улучшить общую целостность связи вашего сервера. Оптимизация маршрутизации через применение BGP или использование CDN не только повысит отказоустойчивость, но также позволит достичь эффективной распределенной нагрузки для вашего приложения.