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

8.4.5. Балансировка нагрузки и локальное размещение очередей

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

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

Поведение по умолчанию для всех очередей менеджера можно изменить, пользуясь атрибутом "очередь с кластерной балансировкой нагрузки" ( CLWLUSEQ – cluster workload use queue) объекта – менеджера очередей сообщений.

На уровне очереди принятое для всего менеджера поведение по умолчанию можно изменить, пользуясь атрибутом "очередь с кластерной балансировкой нагрузки" ( CLWLUSEQ – cluster workload use queue) конкретной локальной очереди сообщений.

8.4.6. Ранг менеджеров и очередей сообщений

В WebSphere MQ V6.0 менеджеры очередей в кластере могут ранжироваться заданием или изменением атрибута "ранг кластерной балансировки нагрузки" ( CLWLRANK – cluster workload rank) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.

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

Отдельные экземпляры очередей также могут ранжироваться при помощи атрибута "ранг кластерной балансировки нагрузки" ( CLWLRANK – cluster workload rank) объекта-очереди, обобществленного внутри кластера. Алгоритмом балансировки ранг отдельных очередей принимается во внимание после анализа ранга менеджеров.

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

8.4.7. Приостановка менеджеров очередей в кластере

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

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

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

8.4.8. Состояние канала

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

Если такие экземпляры не обнаружены, выбираются экземпляры под управлением тех менеджеров, каналы к которым находятся в процессе установления.

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

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

Такое поведение позволяет автоматически обходить сбои отдельных кластерных менеджеров.

8.4.9. Приоритет менеджеров и очередей сообщений

В WebSphere MQ V6.0 менеджерам очередей внутри кластера может назначаться приоритет, для чего задается или меняется атрибут "приоритет кластерной балансировки нагрузки" ( CLWLPRTY – cluster workload priority) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.

Экземплярам очередей под управлением менеджера с бо'льшим приоритетом при выборе обычно отдается предпочтение над экземплярами очередей менеджера с меньшим приоритетом.

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

Приоритет отдельных экземпляров очередей может устанавливать атрибут "приоритет кластерной балансировки нагрузки" ( CLWLPRTY – cluster workload priority) объекта-очереди, обобществленного внутри кластера. Алгоритмом балансировки приоритет отдельных очередей принимается во внимание после приоритета менеджеров.

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

8.4.10. Ограничение кластерных подключений от менеджера

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

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

Предельное значение определяется максимальным числом каналов, которые можно установить от одного менеджера в кластере к другим. Непосредственно для настройки служит атрибут "количество недавно использованных каналов менеджера кластерной балансировки нагрузки" ( CWMRUC – cluster workload manager recently used channel) объекта – менеджера очередей сообщений.

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

8.4.11. Весовая оценка менеджеров

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

В WebSphere MQ V6.0 менеджерам очередей в кластере могут назначаться веса от 1 до 99, для чего задается или изменяется атрибут "вес кластерной балансировки нагрузки" ( CLWLWGHT – cluster workload weight) кластерного receiver-канала, который был использован менеджером для подключения к кластеру.

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

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

К примеру, пусть нам доступны два менеджера очередей сообщений с весами 60 и 20, а номера мест назначения одинаковы. Между очередями с одним названием под управлением этих менеджеров распределим четыре сообщения. Три из них будут адресованы менеджеру, вес которого 60, и лишь одно – менеджеру, вес которого 20. Причина этого в том, что оба номера назначения станут больше на 50:

• (1000 / 60) . 3 = 50;
• (1000 / 20) . 1 = 50.