Интеграция приложений на основе WebSphere MQ
Лекция #6: WebSphere MQ и кластеры В данной лекции вводится понятие кластера Websphere MQ, дается методика его создания и иллюстрируются преимущества работы в кластере. Рассмотрена процедура добавления и исключения менеджера очередей из кластера Websphere MQ. Приведена методика установки WebSphere MQ на кластер Windows NT, хорошо знакомый читателю под названием Microsoft Cluster Server (MSCS).
### Кластер WebSphere MQ При создании систем передачи данных, нередко возникают ситуации, когда некоторые серверы недоступны в течение какого-то времени или работают посменно. Кластер WebSphere MQ это объединение менеджеров очередей, которые могут располагаться на различных платформах. При правильной настройке объектов кластера, приложения помещают сообщения в кластерные очереди, даже если один из менеджеров очередей становится недоступным, а после возобновления связи с ним приложения могут забирать сообщения из локальных кластерных очередей. Каждый менеджер может иметь очереди, доступные для других менеджеров кластера без использования удаленных (remote) и трансмиссионных (transmission) очередей и каналов. При включении менеджера в кластер автоматически создаются кластерные каналыsender и receiver на каждом таком менеджере, причем receiver - канал у каждого менеджера может быть один. В процессе передачи данных используются системные очереди SYSTEM.CLUSTER.REPOSITORY.QUEUE и SYSTEM.CLUSTER.TRANSMIT.QUEUE, которые были созданы еще в процессе установки WebSphere MQ. Менеджеры очередей в кластере могут исполнять роль, как клиентов, так и серверов. Серверы делают доступными очереди для членов кластера, а также для приложений, которые управляют процессами передачи сообщений и генерируют ответные сообщения. Клиенты могут помещать сообщения в кластерные очереди на любых менеджерах и также получать ответные сообщения, но только из кластерных очередей, находящихся на локальном менеджере. Менеджеры очередей кластера доставляют сообщения в нужную очередь и обмениваются информацией о кластерных объектах, несмотря на то, что обычно клиенты, расположенные на разных платформах не могут установить соединение друг с другом. Объектами кластера могут быть менеджеры очередей, очереди и каналы. Информация обо всех объектах кластера называется репозиторием. Часть ее хранится в системной очереди SYSTEM.CLUSTER.REPOSITORY.QUEUE и обновляется с помощью SYSTEM.CLUSTER.COMMAND.QUEUE и встроенных в WebSphere MQ механизмов репликации. Репозиторий может быть полным (full) и частичным (partial). Информация между репозиториями менеджеров передается с помощью кластерных каналов sender и receiver. Она включает в себя как собственно сообщения, так и любую информацию об изменении статуса менеджера или о добавлении/удалении объектов в кластер. Кластерный канал receiver принимает информацию от других менеджеров. На каждом менеджере необходимо иметь как минимум один кластерный канал receive. Все сообщения передаются через SYSTEM.CLUSTER.TRANSMIT.QUEUE. Если один из менеджеров кластера перестанет быть доступным, то сообщения, предназначенные для его очередей, останутся в этой очереди на соответствующем менеджере. Один менеджер очередей может быть включен во множество кластеров. То же самое относится к очередям. В данном случае создается объект WebSphere MQ именуемый NAMELIST. Рассмотрим процесс создания кластера и включения в него менеджеров на разных платформах. Создадим кластер из существующих на одном компьютере (IP адрес 198.32.100.26) менеджеров очередей QM_Win2000 (менеджер по умолчанию) и QM_Win2000_REP (порт для listener – 1415). Процесс состоит из следующих шагов [12]. Вызвать контекстное меню WebSphere MQ Explorer на группе Clusters правой кнопкой мыши. Выбрать Create, далее Cluster. На экране появится информационная форма «Create Cluster Wizard» (рис.6.1), говорящая о том, что Wizard поможет вам создать новый кластер для менеджеров очередей, которые еще не являются репозиториями для других кластеров, а также о необходимости выполнить следующие шаги: ввести имя кластера; ввести имя менеджера очередей, который будет выступать в роли первого репозитория; ввести имя менеджера очередей, который будет выступать в роли второго репозитория; ввести или оставить по умолчанию имя receiver канала для первого репозитория; ввести или оставить по умолчанию имя receiver канала для второго репозитория. Рис. 6.1. Create Cluster Wizard После нажатия на кнопку «Далее» появится следующая форма (рис. 6.2), в которой надо ввести имя кластера. Рис. 6.2. Ввод имени кластера В следующей форме (рис. 6.3) вводим имя менеджера очередей для первого репозитория. Поскольку оба менеджера находятся на одном компьютере, и запуск процесса создания кластера был выполнен из WebSphere MQ Explorer этого же компьютера, то устанавливаем флажок на «Local (on this computer)». Очевидно, что менеджер очередей для первого репозитория может быть расположен и на удаленном компьютере. В таком случае флажок должен быть установлен на «Remote (on another computer)», и введены имя удаленного менеджера и IP адрес с указанием номера порта для службы Listener удаленного компьютера, на котором, собственно и установлен менеджер очередей. Отметим, что нет разницы, имя какого менеджера будет введено первым. Единственное, надо иметь в виду то, что менеджер не должен являться членом и репозиторием для другого кластера. Рис. 6.3. Ввод имени менеджера для первого репозитория В следующей форме вводим имя второго менеджера очередей. По своему виду она аналогична форме, изображенной на рис.6.3. Следующая форма – информационная. Она говорит о том, что каждый менеджер должен иметь кластерные каналы sender и receiver, с помощью которых он может соединяться с другими менеджерами, включенными в кластер. Имя receiver канала может использоваться в дальнейшем для создания одноименных sender каналов на других менеджерах, включенных в кластер. В форме, изображенной на рис.6.4, вводим имя receiver канала для первого менеджера QM_Win2000_REP и имя (или IP адрес) компьютера с портом для службы «Listener» этого же менеджера. Рис. 6.4. Ввод имени receiver канала для первого менеджера QM_Win2000_REP Следующая форма (рис.6.5) аналогична изображенной на рис. 6.4. В ней вводим имя receiver канала для второго менеджера QM_Win2000 и IP адрес компьютера с портом для данного менеджера. Напомним, что для менеджера по умолчанию имя порта равно 1414 и его указывать не обязательно. Рис. 6.5. Ввод имени receiver канала для второго менеджера QM_Win2000 Далее выводится суммарная информация о конфигурации кластерных объектов, которую можно распечатать, а при нажатии клавиши «Готово» создается кластер и пара кластерных каналов на обоих менеджерах. Убедиться в этом можно, увидев в WebSphere MQ Explorer (рис.6.6) в группе Clusters кластер THUNDER, в который входят менеджеры очередей QM_Win2000 и QM_Win2000_REP, а менеджер QM_Win2000_REP имеет кластерный канал sender TO_QM_Win2000 и кластерный канал receiver TO_QM_Win2000_REP. Рис. 6.6. WebSphere MQ Explorer, показывающий кластер THUNDER Следует сказать, что кластерные каналы могут использоваться как обычные для передачи сообщений между менеджерами очередей. Так, создав необходимые объекты на удаленном менеджере, не включенном в кластер можно использовать имя кластерного канала receiver для создания sender канала, и наоборот. Использовать эту возможность не рекомендуется, так как для четкости построения потоков передачи данных целесообразно использовать для каждого потока свои объекты WebSphere MQ, дифференцируя количество потоков с количеством и размером сообщений в каждом потоке. Подробнее на вопросах производительности мы остановимся в лекции 7. Таким образом, создав объекты WebSphere MQ (очереди и каналы) на одном менеджере можно видеть их «отображение» на другом, управление очередями становится доступным как на одном, так и на другом менеджере. При создании очередей теперь необходимо указывать, в зависимости от их назначения, доступна ли она кластеру и какому именно. При создании очередей через WebSphere MQ Explorer первый вопрос задается сразу после ввода имени очереди и нажатии на кнопку «Ok». При положительном ответе форма создания очереди переходит на закладку «Cluster» и предлагает выбрать имя доступного кластера. Отметим тот факт, что при создании кластерных очередей директории для них не создаются, как это было в отношении локальных очередей. Вся информация будет находиться в SYSTEM.CLUSTER.REPOSITORY.QUEUE и будет передаваться в такую же очередь на менеджеры, включенные в кластер. Рассмотрим пример передачи сообщений в кластере. Создадим локальную очередь с именем Win2000.CQ (CQ – cluster queue) на менеджере QM_Win2000:
    runmqsc QM_Win2000
    define qlocal('Win2000.CQ')
                        cluster('THUNDER')
    refresh cluster('THUNDER')
    end
Создадим локальную очередь с именем Win2000_REP.CQ на менеджере QM_Win2000_REP:
    runmqsc QM_Win2000_REP
    define qlocal('Win2000_REP.CQ')
                        cluster('THUNDER')
    refresh cluster('THUNDER')
    end
Поместив тестовое сообщение в очередь Win2000_REP.CQ с помощью контекстного меню WebSphere MQ Explorer (рис.6.7) на менеджере очередей QM_Win2000 можно его увидеть на менеджере QM_Win2000_REP. И наоборот, поместив тестовое сообщение в очередь Win2000.CQ на менеджере очередей QM_Win2000_REP можно его увидеть на менеджере QM_Win2000. Рис. 6.7. Помещение тестового сообщения в удаленную кластерную очередь. ### Добавление и исключение менеджера из кластера Рассмотрим два способа включения в кластер менеджера, расположенного на компьютере с операционной системой UNIX. Имя менеджера очередей – QM_HPUX, IP адрес – 198.32.100.16, порт для службы «Listener» - 1421. Для включения в кластер данного менеджера очередей и создания необходимых кластерных каналов выполним команду из командной строки на компьютере с операционной системой UNIX
    runmqsc QM_HPUX
- и далее: включаем менеджер очередей QM_HPUX в кластер THUNDER командой
      alter qmgr repos('THUNDER')
- создаем кластерный канал receiver
      define channel('TO_QM_HPUX') +
        chltype(clusrcvr)
          conname('198.32.100.16(1421)') +
      cluster('THUNDER')
- создаем кластерный канал sender
      define channel('TO_QM_Win2000_REP')
        + chltype(clussdr)
          conname('198.32.100.26(1415)') +
      cluster('THUNDER')
- создаем кластерную очередь HPUX.CQ
      define qlocal('HPUX.CQ')
             cluster('THUNDER')
- обновляем информацию о кластерных объектах
      refresh cluster('THUNDER')
- проверяем доступность очереди Win2000.CQ
      DISPLAY QCLUSTER('Win2000.CQ')
  В результате последней команды мы получаем информацию о кластерной очереди 'Win2000.CQ' менеджера QM_Win2000, что говорит о доступности информации о кластерных объектах кластера 'THUNDER':
      DESCR(WebSphere MQ Default
        Local Queue)
      CLUSTER(THUNDER)
      CLUSQMGR(QM_Win2000)
      CLUSDATE(2004-10-05)
      ALTDATE(2004-10-05)
      CLUSQT(QLOCAL)
      PUT(ENABLED)
      DEFPSIST(NO)
      QUEUE(Win2000.CQ)
      QMID(QM_Win2000_2004-10-05_15.42.55)
      CLUSTIME(17.36.17)
      ALTTIME(15.49.29)
      TYPE(QCLUSTER)
      DEFPRTY(0)
      DEFBIND(OPEN)
- выходим из командного процессора WebSphere MQ
      end
Существует способ добавления менеджера в кластер с помощью WebSphere MQ Explorer в графическом режиме. Для этого следует: Подключиться к удаленному менеджеру очередей QM_HPUX (IP адрес – 198.32.100.16, порт для службы «Listener» - 1421) через WebSphere MQ Explorer. После появления его в левой панели, вызвать на нем контекстное меню и выполнить пункт «Join Cluster». Ввести имя кластера THUNDER (рис.6.8) Рис. 6.8. Ввод имени кластера. Ввести имя менеджера очередей, являющегося репозиторием для кластера THUNDER, например QM_Win2000_REP (рис.6.9). Рис. 6.9. Выбор менеджера очередей, являющегося репозиторием. Ввести имя кластерного канала receiver TO_QM_HPUX и IP адрес с указанием номера порта для службы «Listener» 192.32.100.16(1421) для менеджера очередей QM_HPUX (рис.6.10). Рис. 6.10. Ввод имени кластерного receiver канала и IP адреса менеджера QM_HPUX. Ввести имя кластерного канала receiver TO_QM_Win2000_REP и IP адрес с указанием номера порта для службы «Listener» 192.32.100.26(1415) для менеджера очередей QM_Win2000_REP (рис.6.11). Рис. 6.11. Ввод имени кластерного receiver канала и IP адреса менеджера QM_Win2000_REP. После нажатия кнопки «Далее» выводится суммарная информация об объектах, которые будут созданы. Далее при нажатии кнопки «Готово» менеджер QM_HPUX будет включен в кластер THUNDER, на менеджере QM_HPUX будет создана пара кластерных каналов TO_QM_Win2000_REP (sender) и TO_QM_HPUX (receiver), а на менеджере QM_Win2000_REP будет создан кластерный канал sender TO_QM_HPUX. Теперь рассмотрим процесс исключения менеджера из кластера. Это можно сделать также двумя способами: командным и графическим, с помощью WebSphere MQ Explorer. Существуют две команды, с помощью которых можно вывести менеджер из кластера. Это SUSPEND QMGR и RESET CLUSTER. Команда suspend извещает менеджеров очередей, входящих в кластер о том, что данный менеджер временно приостановлен. Менеджеры очередей перестают посылать ему сообщения. Это не означает, что менеджер заблокирован. Он продолжает работать в независимом (локальном) режиме.
    suspend qmgr
           cluster(clustername) [mode(force)]
где: clustername – имя кластера; mode(force) – принудительно останавливает все кластерные входящие каналы на данном менеджере. Используя команду resume qmgr cluster(clustername), можно вернуть менеджер в кластер:
    resume qmgr cluster(clustername)
где: clustername – имя кластера. Команда reset cluster выводит менеджер и его объекты из кластера, не удаляя кластерные каналы и очереди:
    reset cluster(clustername)
                 action(forceremove)
                 qmname(MQMName) queues(NO)
или
    reset cluster(clustername)
                 action(forceremove)
                 qmid(qmid) queues(YES)
10. где: clustername – имя кластера; action(forceremove) – опция, указывающая на то, что менеджер будет принудительно выведен из кластера (рекомендуется к использованию); MQMName – имя менеджера очередей; Qmid – идентификатор менеджера очередей; queues(NO) – кластерные очереди, принадлежащие менеджеру, не будут принудительно выведены из кластера (устанавливается по умолчанию); queues(YES) – кластерные очереди будут принудительно выведены из кластера, даже если менеджер очередей не виден в кластере. Команда reset cluster выводит менеджер и его объекты из кластера, не удаляя кластерные каналы и очереди. Если в кластере существует несколько менеджеров очередей с одинаковыми именами, то для их выведения необходимо использовать опцию qmid. Значение qmid легко узнать из команды display qmgr. Параметр YES в опции queues рекомендуется к использованию. Поскольку репликация информации между репозиториями не мгновенная, то лучше сразу выводить очереди из кластера. Когда менеджеры посылают информацию о себе, например, при создании новой очереди, полный репозиторий хранит эту информацию 30 дней. Предупреждая истечение срока актуальности информации, менеджеры посылают информацию о себе каждые 27 дней даже если никаких изменений в структуре менеджеров не происходило. Если от менеджера не поступает информации в течение 90 дней, то информация о нем удаляется из полного репозитория, и он перестает быть частью кластера, однако, если он подключится к сети и пошлет о себе информацию, то он снова может стать частью кластера. Для выведения менеджера из кластера лучше использовать WebSphere MQ Explorer. Для этого нужно вызвать контекстное меню, правой кнопкой мыши щелкнув по «Queue Managers in Cluster», далее в меню «All tasks» выполнить пункт «Remove Queue Manager...», выбрать нужный менеджер и выставить флажки в опциях «Remove all cluster queue definitions» и «Force removal of the queue manager from the repository». После нажатия кнопки «Ok» появится запрос на подтверждение немедленного вывода менеджера из кластера, на который нужно ответить утвердительно. ### WebSphere MQ под управлением MSCS В данной части лекции мы подразумеваем, что читатель хорошо знаком с работой Microsoft Cluster Server (MSCS). Для установки WebSphere MQ на кластер NT система должна удовлетворять следующим требованиям: Windows NT4 Enterprise Edition with Service Pack 6a или более поздним, Microsoft Cluster Server (MSCS), или Windows 2000 Advanced Server, Microsoft Cluster Server (MSCS). Процедура установки WebSphere MQ и помещение менеджеров под контроль MSCS описывается следующими шагами: MSCS должен быть установлен и стартован. Установить WebSphere MQ на каждом сервере. Создать менеджер очередей. Рекомендуется сменить кодовую страницу на 1251. Закрыть MSCS Cluster Administrator и WebSphere MQ Explorer на каждом сервере (менеджер очередей не останавливать). Зарегистрировать новый ресурс «IBM WebSphere MQ MSCS» с помощью команды haregtyp /r. Выполнить пункт 4 на другом сервере кластера. Проверить наличие нового ResourceType с именем «IBM WebSphere MQ MSCS» запустив MSCS Cluster Administrator и нажав '+' рядом с именем кластера. Создать необходимые объекты (очереди, каналы и пр.) WebSphere MQ на «активном сервере». Остановить Queue Manager. Создать на кластерном диске (допустим, что кластерный диск имеет название E:) каталоги WebSphere MQ и WebSphere MQ\log. Выполнить команду для переноса Queue Manager в кластер
        hamvmqm /m qmname /dd
                      e:\WebSphere MQ /ld
                      e:\WebSphere MQ\log
где qmname – имя менеджера очередей. Стартовать менеджер и проверить его работоспособность, создав очередь, поместив в нее тестовое сообщение, просмотрев его и удалив очередь. Установить тип запуска сервиса IBM MQSeries в «Manual». Остановить Queue Manager. Запустить MSCS Cluster Administrator. Создать группу в MSCS, которая будет содержать все необходимые ресурсы менеджера очередей. Создать в группе ресурс типа «Physical Disk» для кластерного диска (E:). Зависимых (Resource dependencies) ресурсов не указывать. Создать IP ресурс, в котором указать «свободный» IP адрес. Этот адрес будет использоваться другими менеджерами или клиентами для установления соединения с «виртуальным» менеджером очередей. Создать ресурс типа «IBM WebSphere MQ MSCS». В процессе создания данного ресурса используется Wizard (мастер построения), при работе с которым необходимо ввести следующие параметры: Name – имя для идентификации менеджера очередей; Add to group – добавить в группу, созданную в п.14; Run in a separate Resource Monitor – данную опцию можно не использовать; Possible owners – добавить обе части (node) кластера; Dependencies – добавить ресурс для кластерного диска и ресурс для IP; Parameters – QueueManagerName (добавить имя менеджера очередей); PostOnlineCommand (команда, которая может быть выполнена, когда менеджер очередей перейдет из состояния online в offline); PreOfflineCommand (команда, которая может быть выполнена, когда менеджер очередей перейдет из состояния offline в online). На этом процесс переноса менеджера под управление MSCS можно считать завершенным. Остается только проверить работоспособность менеджера, проимитировав сбой с помощью команды MSCS «Initiate Failure», вызываемой с помощью контекстного меню группы, в которую входит менеджер очередей. Кратко о преимуществах работы WebSphere MQ под управлением MSCS. Очевидно, что это делает работу WebSphere MQ исключительно надежной в целом, если по тем или иным причинам один сервер кластера выйдет из строя или временно будет не доступен. Прежде чем деинсталлировать WebSphere MQ необходимо вывести менеджер очередей из под контроля MSCS. Для этого нужно сначала перевести ресурс менеджера в offline, а затем уничтожить все ресурсы. Уничтожение ресурсов (кластерный диск, IP адрес, IBM WebSphere MQ MSCS) не приведет к удалению менеджера очередей. Далее выполнить команду haregtyp /u. Рекомендуется сохранить все объекты менеджера (например с помощью программы saveqmgr, описанной в лекции 5), затем удалить менеджер, создать его заново и восстановить все объекты. В заключение лекции можно сказать, что мы рассмотрели работу WebSphere MQ в самом кластере WebSphere MQ и под управлением кластера MSCS. Главное отличие состоит в том, что при работе с кластером MSCS «виртуальный» менеджер кластера всегда доступен, если даже один из серверов выходит из строя. Управление объектами WebSphere MQ остается точно таким же, как и при работе с локальным менеджером, и никаких преимуществ в управлении и настройке мы не получаем. В случае использования кластера WebSphere MQ наяву очевидные преимущества, связанные с отсутствием обязательного создания и настройки трансмиссионных (transmission) и удаленных (remote) очередей и каналов. Но если возникают проблемы на одном из менеджеров кластера WebSphere MQ, то считывание сообщений из локальных кластерных очередей менеджера становится проблематичным до восстановления его работоспособности.

© Макушкин В.А., Володичев Д.С. Все права защищены.