Служба очереди сообщений может быть реализована в кластере серверов, который отображается для клиентов сети как отдельная система с высокой доступностью. Такие кластеры используются для повышения надежности и отказоустойчивости за счет перемещения при сбое, а также для балансировки нагрузки сети. Кластеры серверов очереди сообщений могут создаваться только на компьютерах с операционными системами Windows Server 2003, Enterprise Edition или Windows Server 2003, Datacenter Edition. Для таких кластеров служба очереди сообщений устанавливается на каждом узле кластера. Эти экземпляры службы очереди сообщений необходимы для поддержки ресурсов очереди сообщений на виртуальных серверах. Кроме того, хотя они действуют независимо от кластеров, они требуются даже в системе кластеров для обслуживания многих приложений и системных компонентов, выполняющихся вне контекста виртуального сервера, а также для вызовов API очереди сообщений.

Группа кластера представляет собой набор ресурсов кластера со следующими характеристиками.

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

Чтобы получить доступ к сетевому приложению или ресурсу в среде без кластеров, сетевые клиенты должны подключиться к физическому серверу (т. е. к конкретному компьютеру в сети, который определяется уникальным сетевым именем и IP-адресом). В случае отказа этого сервера доступ к приложению или ресурсу становится невозможным. С помощью кластеров серверов операционные системы Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition обеспечивают создание виртуальных серверов. В отличие от физического сервера, виртуальный сервер не связан с конкретным компьютером и может быть, подобно группе, перемещен при сбое. При отказе узла, на котором находится виртуальный сервер, клиенты по-прежнему могут получать доступ к его ресурсам с использованием того же имени сервера. Виртуальный сервер представляет собой группу, которая содержит ресурс сетевого имени, ресурс IP-адреса, другие виртуальные серверы и другие ресурсы, в том числе и приложения типа очереди сообщений, доступ к которым осуществляют клиенты виртуального сервера.

При создании групп кластеров для очереди сообщений необходимо создать виртуальный сервер. Ресурс очереди сообщений является зависимым от ресурса физического диска при сохранении сообщений и данных очереди, а также от ресурса сетевого имени, обеспечивающего доступ к нему удаленных клиентов. Виртуальный сервер создается на каждом узле кластера с помощью стандартных средств кластеров (стандартным интерфейсом является «Администратор кластеров») или программных интерфейсов API создания кластеров. Если в кластере также используются триггеры очереди сообщений, обмен сообщениями по протоколу HTTP или внешние транзакции, для которых требуется ресурс координатора распределенных транзакций (DTC), то единый ресурс DTC создается только на одном из виртуальных серверов. Затем с помощью администратора кластеров создается ресурс очереди сообщений в некоторых или во всех существующих группах кластера. Когда ресурс очереди сообщений переводится в оперативный режим в первый раз на любом виртуальном сервере, ресурс сетевого имени кластера создает объект псевдокомпьютера, а ресурс очереди сообщений создает в нем объекты очереди сообщений в Active Directory. Каждый виртуальный сервер работает так же, как и сервер на физическом компьютере, так что сервер очереди сообщений, работающий в контексте виртуального сервера, выполняет те же задачи, что и сервер очереди сообщений, работающий на физическом компьютере. В частности, на виртуальном сервере могут создаваться очереди, в которые можно отправлять сообщения. Для адресации таких очередей используется следующий синтаксис имя_виртуального_сервера\имя_очереди.

Дополнительные сведения об администрировании кластера содержатся в разделе Использование оснастки «Администратор кластеров» справки администратора кластера.

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

Когда пользователь выбирает ресурс «Физический диск» для группы кластера, служба очереди сообщений выделяет хранилище в папке MSMQ\STORAGE на общем диске. После выделения хранилища нельзя изменить размещение папки.

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

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

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

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

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

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

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

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

При получении IP-адреса, используемого для обмена сообщениями, применяются следующие условия.

• На виртуальном сервере используется IP-адрес виртуального сервера, определенный для ресурса IP-адреса.
  
• Если узел кластера имеет единственный IP-адрес, используется этот адрес.
  
• Если IP-адрес указан в реестре, используется этот адрес. Если указанный IP-адрес не удается найти на узле, возникает событие и запись реестра игнорируется.
  
• Если на узле имеется несколько IP-адресов, то с помощью API-кластера создаются два списка, первый из которых содержит все частные (не статические) IP-адреса, а второй — все IP-адреса узла. Затем эти два списка сравниваются для выбора адреса, который содержится во втором и отсутствует в первом списке. После выбора IP-адреса создается информационное событие. Если доступны только IP-адреса из первого списка, используется один из них и создается событие.
  

Чтобы указать IP-адрес, создайте в реестре параметр типа DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\ClusterBindIP, имеющий обычный формат IP-адреса. Чтобы изменения вступили в силу, перезапустите службу очереди сообщений после изменения параметров реестра.

Внимание!

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

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

На узле кластера с несколькими сетевыми интерфейсными платами могут возникнуть затруднения при попытке отправить сообщения многоадресной рассылки с использованием нескольких плат. Фактически служба очереди сообщений будет произвольно выбирать сетевую интерфейсную плату для отправки сообщений многоадресной рассылки. Если выбрана сетевая интерфейсная плата частной сети, адресаты не получат сообщение многоадресной рассылки. Во избежание подобных затруднений можно указать исходный IP-адрес, используемый для отправки сообщений многоадресной рассылки. Для этого создайте в реестре параметр типа DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MulticastBindIP, имеющий обычный формат IP-адреса. Чтобы изменения вступили в силу, перезапустите службу очереди сообщений после задания параметров реестра.

Внимание!

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

Следует иметь в виду, что для многоадресной рассылки сообщений на узле кластера в случае, когда в параметре MulticastBindIP не указан IP-адрес, используемый IP-адрес определяется согласно процедуре, описанной выше в разделе IP-адресация с несколькими сетевыми интерфейсными платами на узле кластера.

Если в кластере серверов имеется несколько ресурсов очереди сообщений, то операции по обмену сообщениями могут не выполняться так, как ожидается, если не увеличить размер пула памяти для представления системы на каждом узле на 4 Мбайт для каждого экземпляра ресурса очереди сообщений. Это рекомендуется сделать для узлов кластера с одним или двумя ресурсами очереди сообщений и необходимо сделать для узлов кластера с тремя или более ресурсами очереди сообщений. Для этого:

• Откройте редактор реестра с помощью команды regedit.
  
• Откройте раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
  
• Создайте новое значение SystemViewSize с типом DWORD.
  
• Рассчитайте и укажите значение.
  
  • Используйте формулу: (16 + (число ресурсов очереди сообщений x 4)).
    
  • Например, для кластера с тремя ресурсами очереди сообщений значение равняется 28.
    
• Перезагрузите каждый из узлов.
  

Внимание!

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

Дополнительные сведения о кластерах серверов Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition см. в разделе Кластеры серверов справки Windows.