У меня есть 2 сервера, назовем их «node1» и «node2», установленные в центре обработки данных. Они запускают наше прикладное программное обеспечение. Они взаимозаменяемы, и у каждого есть полная копия баз данных всех клиентов. Мы хотим, чтобы клиенты могли входить в систему с одного IP-адреса, и чтобы соединения переходили на узел 1, если он работает, в противном случае - на узел 2. (Автоматическое переключение при сбое более важно для нас, чем балансировка нагрузки, хотя в будущем мы также можем настроить балансировку нагрузки).
Наши требования очень просты: мы можем предоставить URL-адрес для использования в качестве проверки работоспособности, и если он отвечает на «node1», тогда весь трафик должен идти туда, а не на «node2».
Центр обработки данных требует, чтобы мы заплатили 3000 долларов за выделенное устройство балансировки нагрузки. Но они также говорят, что их межсетевой экран имеет возможность выполнять автоматическое переключение при отказе _in_theory_, хотя у них никогда не было клиентов, использующих эту функцию. Я не понимаю, зачем для такой простой задачи выделенное оборудование или даже виртуальный сервер. Почему бы какой-либо небольшой компании не предпочитать балансировку нагрузки в брандмауэре? Это меньше затрат, меньше прыжков, меньше сложности ...? Что я не знаю о LTM (управлении локальным трафиком)?
Нет смысла использовать специальный балансировщик нагрузки, если брандмауэр можно настроить для выполнения этой основной задачи. То, с чем вы сталкиваетесь, - это опыт службы хостинга. Они делают это способом X, потому что это наиболее эффективное использование их ресурсов. У них, возможно, нет опыта, как было сказано, у них определенно нет опыта, чтобы создать это и, что более важно, поддержать его экономически. Для сравнения: AWS ELB, балансирует, проверяет работоспособность и направляет трафик за 19 долларов в месяц. Что он также делает, так это полностью распаковывает SSL для вас. Вам не нужно вообще беспокоиться о SSL на серверах приложений.
(Лично, если у вас два сервера, я бы все равно использовал липкую балансировку нагрузки между ними).
Я не думаю, что брандмауэр обеспечит описанное вами аварийное переключение, несмотря на то, что вы описали. Обычно брандмауэры смотрят только на трафик и решают, должен он проходить или нет. Они предназначены для быстрого анализа большого количества трафика (миллиарды Ethernet-кадров в секунду) и, вероятно, не будут игнорировать заголовки TCP / UDP. Если брандмауэр предлагает аварийное переключение, он, вероятно, более примитивен и проверяет только доступность MAC-адреса или IP-адреса. может быть если TCP-порт открыт.
Конечно, если брандмауэр работает так, как вы описали, то это не чистый брандмауэр, и это может повлиять на производительность. Выполняет ли он NAT или действует как шлюз маршрутизации, или это всего лишь мост? Вы вообще не упомянули о производительности, поэтому, если вас это не касается и ваш брандмауэр может выполнять аварийное переключение, тогда, конечно, зачем тратить 3000 долларов, если ваши потребности удовлетворяются бесплатно?
Если вы обнаружите, что этот брандмауэр не выполняет аварийное переключение, как вы хотите, вы можете подумать о внедрении шлюза или моста, который может, но для этого вам придется заплатить за другой компьютер. (Если вам нужна производительность, потратьте 3000 долларов на выделенный балансировщик нагрузки.) Вы можете представить машину с haproxy, как предложил JayMcTee в комментариях. Но что, если эта дополнительная машина выйдет из строя? Брандмауэр уже представляет собой единственную точку отказа, вы действительно хотите ввести еще одну? Отказоустойчивость на основе DNS, такая как Route 53 (снова предложенная JayMcTee), поможет устранить дополнительную единую точку отказа, но тогда при отказе возникнет [настраиваемая] задержка.
Очень нужна дополнительная информация о ваших потребностях, чтобы сделать правильный выбор.