Я хотел бы иметь отказоустойчивую настройку для 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 отвечает с аппаратным адресом, и все идет как обычно. Так что в случае неудачи у меня
Какие-нибудь меры предосторожности?
Хотя то, что вы придумали, является умным, одна проблема будет в том, что маршрутизация пакетов может произвольно переключаться между двумя машинами. Я подчеркиваю пакеты, а не TCP-соединения. Таким образом, соединения TCP будут сбрасываться случайным образом, поскольку маршрутизация колеблется взад и вперед.
Для чисто однопакетной службы UDP у вас может быть немного больше шансов на ее работу.
Однако существуют механизмы, предназначенные для предотвращения использования одного и того же IP-адреса на нескольких сетевых адаптерах в одной сети. Вам нужно будет найти способы обойти эти гарантии.
Подход, который я использую, заключается в том, чтобы иметь IP-адрес, по которому две машины будут согласовывать. Назовите это «виртуальным IP». Основной компьютер обычно добавляет этот IP-адрес в качестве псевдонима. Вторичная машина будет контролировать первичную машину и перехватить IP, когда обнаружит, что первичная машина не работает.
Вторичный будет принимать IP, добавляя псевдоним, а затем выдавая определенный сигнал, чтобы сеть знала, что что-то переместилось.
Вы также можете переключаться между ролями в любое время, удалив псевдоним с первого компьютера, а затем добавив его ко второму, как описано выше.
Вы считали Pacemaker или Keepalived. Ни один из них не способен обеспечить (осмелюсь сказать) циклическую отказоустойчивость, которую вы планируете, поскольку только один сервер будет доступен под IP в любое время. Но такая конфигурация позволяет выполнять более сложные HTTP-транзакции. То, что вы описываете, может привести к тому, что клиенты, получающие одни и те же данные с разных серверов, в разное время в сеансе.
Надеюсь, это было полезно.
Откровенно говоря, да, это выглядит плохой. Но мы все здесь, чтобы учиться. Если вы работаете на платформе Windows, вам следует изучить что-то вроде балансировки сетевой нагрузки (ссылка ниже) для обеспечения отказоустойчивости и производительности. Я предполагаю, что для Linux есть похожие вещи. Я никогда не использовал NLB лично, но всегда имел один или несколько балансировщиков нагрузки перед http-серверами, чтобы обеспечить отказоустойчивость и балансировку нагрузки. Конечно, вы пытаетесь добиться высокой доступности с помощью своей настройки, но шлюз по-прежнему будет единственной точкой отказа.
Это не будет работать так, как вы думаете, потому что обе машины находятся в одном широковещательном домене. В то время как устаревшая запись ARP запускает широковещательный запрос ARP и соответствующий одноадресный ответ, назначение IP запускает зонды широковещательной рассылки ARP и объявления. Так что произойдет как минимум две неприятности:
Читать RFC 5227 для деталей славы.