Кластеры менеджеров очередей

8.4. Балансировка нагрузки

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

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

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

Чтобы воспользоваться преимуществами балансировки нагрузки, особой настройки кластера не потребуется. Чтобы добавить в кластер экземпляр службы, подключите новый менеджер очередей, после чего откройте совместный доступ к очереди, представляющей службу, распознаваемую по имени очереди. Все менеджеры очередей внутри кластера, которые обращались – или в будущем обратятся – к названию этой очереди из кластера, автоматически получили или получат уведомление о вновь созданном экземпляре. С момента уведомления об экземпляре менеджеры могут посылать ему сообщения.

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

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

Чтобы получить преимущества от балансировки нагрузки, приложение не должно задавать название конкретного менеджера при открытии очереди функцией MQOPEN.

8.4.1. Работа с привязкой при открытии и без фиксированной привязки

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

Нередко каждое сообщение может направляться различным экземплярам упомянутой службы, и это не окажет отрицательного воздействия на работу программы, инициировавшей запрос. Если служба-получатель сообщений действует по модели "запрос – ответ", каждое посланное отправителем сообщение содержит явное указание на то, кому конкретно служба должна ответить, и контекста в ее работе не требуется. Такой порядок функционирования очень эффективен с позиции балансировки нагрузки и может повышать устойчивость приложения к недоступности отдельного экземпляра интересующей службы.

Однако ведущийся двумя приложениями обмен может иметь характер диалога по схеме "запрос – ответ – запрос и т. д.", которая основана на контексте, сформированном предыдущими сообщениями. Взаимосвязь между ними называют сродством сообщений (message affinity). При наличии такового приложению может понадобиться привязка (bind) к конкретному экземпляру службы в составе кластера. Для обеспечения привязки приложение может явно указать одну из двух опций менеджера при открытии очереди.

• Привязка при открытии.

  Все сообщения, отсылаемые при помощи описателя, полученного от функции MQOPEN, и до момента вызова MQCLOSE, направляются одному и тому же входящему в кластер экземпляру очереди сообщений. Балансировка нагрузки выполняется лишь однажды – при открытии очереди со стороны приложения.
• Без фиксированной привязки.

  Балансировка нагрузки производится каждый раз, когда, используя описатель объекта, приложение размещает сообщение в очереди.

Поведение по умолчанию определяется атрибутом "привязка по умолчанию" ( DEFBIND – default bind) экземпляра очереди сообщений, входящего в состав кластера и выбранного при вызове MQOPEN. Этот атрибут задается в объекте очереди, разделяемом внутри кластера и расположенном на менеджере, который создал этот объект и обеспечил совместный доступ к нему из кластера.

8.4.2. Алгоритм балансировки нагрузки

Каждый раз, когда менеджер выбирает место назначения сообщений в кластере по названию очередей, вызывается встроенный в него алгоритм балансировки нагрузки.

Упрощенно – при настройках по умолчанию и успешном установлении канала к каждому менеджеру очередей внутри кластера – балансировку нагрузки можно рассматривать как круговое распределение сообщений. В результате если приложение без привязки разместило 1000 сообщений, а на 10 кластерных менеджерах размещено 10 одноименных очередей, то приложениям на этих очередях под управлением каждого из 10 менеджеров поступит около 100 сообщений.

Впрочем, эта оценка не точна и зависит от многих факторов. В этом разделе мы только в общих чертах опишем, как работает алгоритм балансировки нагрузки и как можно его настроить, используя возможности WebSphere MQ V6.0. Подробности процесса выработки решения алгоритмом при каждом вызове такового читайте в руководстве WebSphere MQ Queue Manager Clusters, SC34-6589.

8.4.3. Порядковые номера мест назначения сообщений

Для выполнения кругового алгоритма балансировки менеджер очередей сообщений локально хранит порядковый номер места назначения сообщения для каждого известного ему кластерного менеджера очередей.

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

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

В условиях настройки по умолчанию увеличение номера одинаково при передаче каждого сообщения. Поэтому в описанном выше элементарном примере сообщения распределяются равномерно.

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

Расположим влияющие на алгоритм факторы в том порядке, в котором их анализирует алгоритм. Порядковый номер места назначения сообщения окажется в этом случае лишь последним, поскольку он обеспечивает балансировку только для подходящих мест назначения – "кандидатов".

8.4.4. Блокировка очереди на запись

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

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