Протоколы сердечного ритма / Алгоритмы или лучшие практики

Question

Недавно я добавил некоторые возможности балансировки нагрузки к программному обеспечению, которое я написал. Это сетевое приложение, которое обрабатывает некоторые данные на основе входных данных из базы данных SQL. Поскольку хруст может быть довольно интенсивным, я добавил возможность запускать несколько экземпляров этого приложения на разных серверах для разделения нагрузки, но в настоящее время балансировка нагрузки выполняется вручную. Пользователь должен указать, какие экземпляры занимают какую часть входного домена.

Я хотел бы перенести это на следующий уровень и запрограммировать экземпляры для автоматического согласования погружения входных данных и распознавания, если один из них «исчезает» (произошел сбой или был выключен), чтобы оставшиеся экземпляры могут взять на себя нагрузку сбойного экземпляра.

Чтобы реализовать это, я рассматриваю возможность использования простого протокола сердцебиения между экземплярами, чтобы определить, кто в сети, а кто нет, и хотя это не очень сложно, я хотел бы знать, существуют ли какие-либо установленные протоколы сети сердцебиения (на основе UDP, TCP или обоих).

Очевидно, что это часто случается в сетевом мире с технологиями кластеризации, отработки отказа и высокой доступности, так что я думаю, в конце я хотел бы знать, если, возможно, существуют какие-либо установленные протоколы или алгоритмы, о которых мне следует знать или реализовать.

EDIT

Судя по ответам, похоже, что либо нет хорошо установленных протоколов сердцебиения, либо о них никто не знает (что может означать, что они не так хорошо установлены в конце концов), и в этом случае я просто собираюсь накатить свой.

Хотя ни один из ответов не дал того, что я искал конкретно, я собираюсь проголосовать за ответ Мэтта Дэвиса , поскольку он был самым близким, и он указал на хорошую идею использовать многоадресную рассылку.

Спасибо всем за потраченное время ~

Answer 1

Распределенное интерактивное моделирование (DIS), которое определено в IEEE Стандарт 1278, использует пульс по умолчанию 5 секунд через широковещательную рассылку UDP. Пульс DIS является по существу PDU состояния объекта, который полностью определяет состояние, в том числе положение, данного объекта. Благодаря своему применению в сообществе симуляторов DIS также использует концепцию, называемую «безусловным расчетом», для обеспечения более частых биений, когда, например, фактическое положение находится за пределами заданного порога его прогнозируемого положения.

В вашем случае PDU состояния сущности DIS был бы излишним. Я упоминаю это только для того, чтобы отметить тот факт, что частота сердцебиения может варьироваться в зависимости от обстоятельств. Я не знаю, что вам нужно что-то подобное для приложения, которое вы описали, но вы никогда не знаете.

Для пульса используйте UDP, а не TCP. Сердцебиение по своей природе является устройством, не требующим установления соединения, поэтому получается, что UDP (без установления соединения) здесь важнее, чем TCP (с установлением соединения).

При широковещании UDP следует помнить, что широковещательное сообщение ограничено широковещательным доменом . Короче говоря, если у вас есть компьютеры, которые разделены устройством уровня 3, например, маршрутизатором, то широковещательные рассылки не будут работать, потому что маршрутизатор не будет передавать широковещательные сообщения из одного широковещательного домена в другой. В этом случае я бы рекомендовал использовать многоадресную рассылку, поскольку она будет охватывать широковещательные домены, при условии, что значение времени жизни (TTL) установлено достаточно высоким. Это также более автоматизированный подход, чем направленный одноадресный, который требует, чтобы отправитель знал IP-адрес получателя, чтобы отправить сообщение.

Answer 2

Трансляция сердцебиения при каждом использовании UDP; если вы не слышали от машины больше, чем k * t, то предполагается, что она не работает. Будьте осторожны, чтобы используемая совокупная пропускная способность не истощала ресурсы. Вы можете использовать широковещательные IP-адреса или вести список конкретных IP-адресов, для которых вы работаете.

Убедитесь, что сердцебиение содержит «количество перезагрузок», а также «идентификатор машины», чтобы вы знали, что предыдущее состояние сервера не существует.

Я бы рекомендовал использовать MapReduce , если он подходит. Это сэкономит много работы.

Answer 3

Коммутаторы контента Cisco являются аппаратным решением этой проблемы. Они реализуют виртуальный IP-адрес в качестве внешнего интерфейса для нескольких реальных серверов, чьи реальные IP-адреса известны коммутатору. Коммутатор периодически отправляет запросы HTTP HEAD на веб-серверы, чтобы убедиться, что они все еще работают (что программное обеспечение коммутатора называет «keepalive», хотя это не поддерживает сам сервер). Коммутатор Cisco принимает трафик на виртуальном IP-адресе и перенаправляет его на реальные веб-серверы, используя настраиваемую балансировку нагрузки, такую ​​как циклический перебор, или определяемая пользователем балансировка нагрузки.

Эти коммутаторы продаются в розницу в диапазоне 3-10 тысяч долларов, хотя мой деловой партнер купил их на eBay примерно за 300 долларов год назад. Если вы можете себе это позволить, они представляют собой проверенное аппаратное решение вопроса о том, как обеспечить прозрачное распространение службы на несколько серверов. Redhat включает в себя встроенную конфигурацию порта, чтобы вы могли реализовать свой собственный коммутатор Cisco с помощью дешевой коробки RedHat. Google для "виртуального IP-адреса" и "маршрутизатор контента Cisco" для получения дополнительной информации.

Answer 4

Я не уверен, что это ответит на вопрос, но вам может быть интересно, как работает кластеризация Weblogic Server. Из книги Освоение BEA WebLogic Server :

[...] Кластеризация серверов WebLogic обеспечивает слабую связь серверов в кластере. Каждый сервер в кластере является независимым и не полагается на какой-либо другой сервер для каких-либо фундаментальных операций. Даже если связь с любым другим сервером будет потеряна, каждый сервер продолжит работу и сможет обрабатывать полученные запросы. Каждый сервер в кластере поддерживает свой собственный список других серверов в кластере посредством периодических сообщений пульса. Каждые 10 секунд каждый сервер отправляет сообщение пульса другим серверам в кластере, чтобы они знали, что он еще жив. Сообщения пульса отправляются с использованием технологии многоадресной IP-рассылки, встроенной в JVM, что делает этот механизм эффективным и масштабируемым по мере увеличения количества серверов в кластере. Каждый сервер получает эти сообщения пульса от других серверов и использует их для поддержания своего текущего списка членства в кластере. Если сервер пропускает прием трех контрольных сообщений подряд от любого другого сервера, он вынимает этот сервер из списка своих членов, пока не получит другое контрольное сообщение от этого сервера. Эта технология пульса позволяет динамически добавлять и удалять серверы из кластера, не влияя на конфигурации существующих серверов.

Answer 5

В дополнение к аппаратным балансировщикам нагрузки вы также можете попробовать бесплатное программное обеспечение для балансировки нагрузки с открытым исходным кодом, такое как HAProxy , доступное для Linux и BSD.