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