Отказоустойчивость при использовании двух IP с двумя интерфейсами
Я хотел бы иметь отказоустойчивую настройку для запросов http. Для краткости предположим, что у нас очень простой Web-сервис, и нет разницы, какой сервер отвечает.
Поэтому у меня будет следующая настройка (все три находятся в одной локальной сети):
Upstream Gateway:
eth0 - 10.0.0.1
Server1:
eth0 - 10.0.0.10
eth1 - 10.0.0.11
Server2:
eth0 - 10.0.0.10
eth1 - 10.0.0.11
Выглядит глупо? Нет, совсем нет. Когда IP-пакет попадает в шлюз, он ищет адрес уровня 2, поэтому он делает запрос ARP. Ответ содержит аппаратный адрес (это будет аппаратный адрес Server1 или Server2, самые быстрые выигрыши), и ответ ARP будет кэшироваться, но на короткое время.
Сейчас Server1 не работает. Только Server2 отвечает с аппаратным адресом, и все идет как обычно. Так что в случае неудачи у меня
Любые меры предосторожности?
4 ответа
Хотя то, что вы придумали, является умным, одна проблема заключается в том, что маршрутизация пакетов может произвольно переключаться между двумя компьютерами. Я подчеркиваю пакеты, а не соединения TCP. Таким образом, случайные TCP-соединения будут сбрасываться, когда маршрутизация отскакивает назад и вперед.
Для чистого UDP-сервиса с одним пакетом у вас может быть немного больше шансов на его работу.
Однако существуют механизмы, разработанные для предотвращения использования одного и того же IP-адреса на нескольких сетевых картах в одной сети. Вы должны найти способы обойти эти гарантии.
Подход, который я использую, заключается в том, чтобы иметь IP-адрес, который будут согласовывать две машины. Назовите это "виртуальным IP". На основном компьютере этот IP-адрес обычно добавляется как псевдоним. Вторичный компьютер будет контролировать основной компьютер и захватывать IP, когда он обнаружит, что основной не работает.
Вторичное устройство получит IP-адрес, добавив псевдоним, а затем выдаст определенный арпинг, чтобы сеть знала, что все изменилось.
Вы также можете поменять роли в любое время, удалив псевдоним с первого компьютера, а затем добавив его ко второму, как описано выше.
Это не будет работать так, как вы думаете, потому что обе машины находятся в одном широковещательном домене. В то время как устаревшая запись ARP запускает широковещательный запрос ARP и связанный одноадресный ответ, назначение IP запускает зондирующие широковещательные запросы ARP и объявления. Так что произойдут как минимум две плохие вещи:
- Назначение IP на втором буфере не удастся из-за проверки ARP.
- В результате механизмы защиты IP-адресов могут привести к тому, что IP-адрес заблокирован или частично / полностью не назначен.
Прочитайте RFC 5227 для деталей славы.
Если честно, да, это выглядит плохо. Но мы все здесь, чтобы учиться. Если вы работаете на платформе Windows, вы должны рассмотреть что-то вроде балансировки сетевой нагрузки (ссылка ниже) для обеспечения отказоустойчивости и производительности. Я предполагаю, что есть подобные вещи для Linux. Я никогда не использовал NLB лично, но всегда имел один или несколько балансировщиков нагрузки перед http-серверами для обеспечения отказоустойчивости и балансировки нагрузки. Конечно, вы пытаетесь добиться высокой доступности с вашей настройкой, но шлюз все еще будет единственной точкой отказа.
Рассматривали ли вы кардиостимулятор или Keepalived. Ни одна из них не способна (осмелюсь сказать) отказоустойчивости циклического перебора, которую вы планируете, поскольку только один сервер будет доступен по IP в любое время. Но этот тип конфигурации позволяет использовать более сложные транзакции HTTP. То, что вы описываете, может привести к тому, что клиенты, получающие одни и те же данные с разных серверов, в течение сеанса разное время.
Надеюсь, это было полезно.