Как Virtual IP работает при отказе TCP-соединения с резервным сервером для достижения высокой доступности?
У меня есть несколько вопросов о том, как виртуальный IP работает при отказе. Цель состоит в том, чтобы обеспечить высокую доступность службы, работающей на TCP-сервере.
Проблему легко описать:
Вопросы:
Допустим, машина А, на которой запущен основной сервер, умирает. Как работает программное обеспечение Virtual IP на Машине 1? Нужно ли клиенту повторно подключаться для перенаправления на сервер резервного копирования на машине B? Эта машина / соединение переключатель происходить прозрачно?
Реализуется ли виртуальный IP-адрес программно или аппаратно? Можете ли вы привести примеры программных решений, которые я могу использовать / протестировать?
Как насчет того, чтобы программное обеспечение Virtual IP единственная точка отказа? Что произойдет, если Машина 1 умрет? Имеет ли само программное обеспечение Virtual IP какие-либо возможности переключения при отказе / высокой доступности?
Следует уточнить некоторые термины и технологии.
Вы показываете изображение «Балансировщика нагрузки». Хотя технически Load Balancer обычно имеет один или несколько «внешних» IP-адресов, которые подключаются к одному или нескольким «внутренним» серверам - эти внешние IP-адреса не являются «виртуальными IP-адресами».
Когда мы говорим о виртуальных IP-адресах, мы говорим о кластеризации серверов. При кластеризации серверов нет балансировщика нагрузки. Вместо этого все серверы в кластере принимают один и тот же IP-адрес. Они отслеживают друг друга с помощью пульса и принимают решение о том, какой сервер будет отвечать на запросы с общего IP-адреса.
Теперь, очевидно, у вас могут быть кластерные балансировщики нагрузки, которые совместно используют один или несколько IP-адресов.
Итак, вот несколько ответов:
1) На машине 1 не работает программа «Виртуальный IP». Он запускает программу «Балансировка нагрузки». Что происходит с клиентом, когда сервер выходит из строя, полностью зависит от конфигурации вашего балансировщика нагрузки И возможностей вашего внутреннего приложения. Если у вас есть серверная часть без сохранения состояния или общее хранилище, которое приводит к совместному использованию состояния, тогда, когда один сервер выходит из строя, пользователь обычно подключается к другому серверу без проблем и без прерывания своего сеанса. Фактически, в этом сценарии каждый запрос, сделанный клиентом, может фактически балансировать нагрузку на обоих серверах даже во время одного и того же сеанса. В других случаях состояние не передается, и пользователю придется инициировать новый сеанс с другим сервером.
2) Опять же, это не виртуальный IP. Виртуальный IP - это технология кластеризации. Балансировщики нагрузки могут иметь несколько общедоступных IP-адресов в зависимости от ваших фактических физических настроек. Это можно сделать как с помощью оборудования, так и программного обеспечения. Конкретные рекомендации по программному или аппаратному обеспечению выходят за рамки ServerFault. Вы можете использовать для этого Google.
3) Да, балансировщик нагрузки может стать единственной точкой отказа. Если балансировщик нагрузки выходит из строя, все выходит из строя. Реализация действительно высокой доступности - это то, что требует больших денег и технических ноу-хау. В сегодняшнем мире облачных вычислений это лучше доверить профессионалам, таким как Microsoft Azure и Amazon AWS. Они реализуют высокодоступные системы с резервированием, которые вы можете арендовать по очень низкой цене.
Когда дело доходит до высокой доступности, вы должны учитывать каждую точку отказа.
Это включает, но, вероятно, не ограничивается:
- Мощность
- Интернет
- Маршрутизаторы
- Переключатели
- Сетевые кабели
- Сбои сервера (блоки питания, материнские платы, процессоры, дисководы)
- Программное обеспечение вылетает
- DDoS-атаки и другие проблемы с чрезмерным использованием
Итак, короче. Сценарий, описанный в вашем чертеже, даже отдаленно не близок к обеспечению высокодоступной среды.