Windows NLB отлично работает и удаляет компьютер из кластера, когда компьютер мертв.Обнаружение мертвых приложений, пока сервер жив в NLB
Но что происходит, если приложение умирает, но сервер все еще работает нормально? Как вы решили эту проблему?
Thanks
Не используйте NLB.
Балансировщики оборудования часто имеют настраиваемые функции «зонда», чтобы определить, отвечает ли сервер на запросы. Это может быть доступ к реальному порт/URL приложения или определенный URL-адрес «healthcheck», который возвращается только в том случае, если приложение здорово.
Другие варианты на них смотрят на очереди/время, необходимое для ответа на запросы
Cisco выразились так:
Коммутатор Cisco CSM постоянно отслеживает сервера и приложений доступности с помощью различных зондов , in-band контроль работоспособности, код возврата и динамическая обратная связь Протокол (DFP). Когда возникает реальный сервер или происходит отказ шлюза , Cisco CSM перенаправляет трафик на другое местоположение . Добавлены серверы и удалены без сбоев сервисные системы легко масштабируются или вниз.
Предположительно с Windows NLB есть какой-то способ программно задать вес узлов? Узлы должны самоконтролироваться, и если есть какая-то проблема (например, какой-то конкретный узел на диске меньше), установите его вес в ноль, чтобы он не получал никакого дополнительного трафика.
Однако это необходимо тщательно спроектировать и провести дальнейший мониторинг людей, чтобы убедиться, что вы не попали в ситуацию, когда одна ошибка заставляет весь кластер объявить о себе.
Вы действительно не можете иметь дело с ситуацией «byzantine general» в балансировке сетевой нагрузки; соответствующий сломанный узел может подумать, что все в порядке, кажется прекрасным, но при этом полностью неспособно выполнять какую-либо фактическую работу. Хитрость заключается в том, чтобы попытаться свести к минимуму возможность возникновения этих ситуаций в производстве.
Существует несколько уровней проверки работоспособности сетевого приложения.
Мой опыт работы с NLB может быть неполным, но я опишу то, что я знаю. NLB может делать 1 и 2. С помощью пользовательского кодирования вы можете добавлять другие уровни с различной сложностью. С некоторыми сетевыми архитектурами это может быть очень сложно.
Большинство аппаратных балансировщиков от поставщиков, таких как Cisco или F5, могут быть легко сконфигурированы для выполнения 3 или 4. Тест уровня 5 по-прежнему требует специального кодирования.
Мы начинаем с ситуации, когда все узлы являются частью кластера, но неактивны. Мы запускаем собственный монитор службы, который делает запрос на службу локально через внешний интерфейс. Если ответ был успешным, мы запустим узел (разрешим ему начать обработку трафика NLB). Если ответ не удался, мы перестаем получать трафик от узла.
Все промежуточные этапы, описанные Дарроном, не имеют значения. Работало это или нет, это единственное, о чем мы заботимся. Если машина недоступна, остальная часть кластера NLB будет считать ее неудачной.