Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Тестируем связующее ПО MOM

Барри Нэнс

Не думайте, что установка связующего ПО, ориентированного на сообщения (Messaging-oriented Middleware - MOM), в прикладную систему состоит лишь в том, чтобы предоставить в распоряжение программистов API-интерфейсы для приложений обмена сообщениями с соответствующими библиотеками и попросить их послать друг другу несколько пробных сообщений.

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

Хотя технология обмена сообщениями за последнее время заметно улучшилась по сравнению с их непосредственной передачей между приложениями по протоколам IPX, NetBIOS, SNA (LU 6.2) или TCP/IP, она еще не достигла той степени совершенства, когда такой обмен мог бы осуществляться без вмешательства человека. Мы имели возможность убедиться в том, что процедуры планирования, проектирования и конфигурирования среды обмена сообщениями составляют более 90% объема работ по ее развертыванию, в то время как на программирование передачи сообщений между приложениями в рамках всего проекта затрачивается меньше времени. Даже на фазе тестирования большую часть времени мы потратили на отладку и настройку конфигурации очередей сообщений и других компонентов MOM.

Для того чтобы выявить наиболее важные аспекты в использовании связующего ПО, ориентированного на сообщения, мы в нашей сетевой лаборатории протестировали продукт MQSeries 5.0 фирмы IBM и продукт MSMQ 1.0 фирмы Microsoft. В рамках созданной нами среды с трехуровневой архитектурой три компонента тестового приложения обменивались сообщениями на уровнях представления и бизнес-логики. В частности, работа с сообщениями на уровне бизнес-логики инициировалась по завершении сбора данных на уровне представления.

Наш испытательный полигон

В сети, состоящей из двух ЛВС Fast Ethernet с пропускной способностью 100 Мбит/с, соединенных посредством модулей CSU/DSU фирмы Larscom и маршрутизаторов фирмы Cisco Sistems, для передачи сообщений в рамках тестового приложения мы использовали протокол TCP/IP, хотя первоначально планировали работать с протоколом SNA LU 6.2 (APPC), но продукт MSMQ его не поддерживает.

Среди двух с половиной десятков клиентских ПК у нас имелись машины с ОС Windows 95, Windows 98, OS/2 Warp и Macintosh System 7. Для проверки содержимого и хронометража процесса передачи сообщений по сети мы использовали анализатор протоколов Sniffer фирмы Network Associates, установленный на компьютере Dolch PAC63. Мы также включили в состав оборудования три сервера обмена сообщениями: два компьютера Gateway 2000 NS-8000 (с двумя процессорами Pentium II с тактовой частотой 333 МГц, ОЗУ емкостью 512 МБ и тремя дисками RAID SCSI по 9 Гбайт каждый) и компьютер Gateway 2000 NS-7000 (с одним процессором Pentium II, тоже работающим на частоте 333 МГц, ОЗУ емкостью 512 МБ и тремя дисками RAID SCSI по 4 Гбайт каждый). На этих серверах мы инсталлировали систему Windows NT Server. Если продукт MQSeries может работать на нескольких различных платформах, то ПО MSMQ доступно только в составе системы Windows NT Server 4 с дополнением Option Pack 3.

Типы очередей

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

Самый простой тип очереди -- это сообщения, используемые приложениями для обмена данными. Затем следуют очереди событий, которые получают и распределяют сообщения об определенных событиях и используются приложениями для извещения о них, например об изменениях в объектах мониторинга. Далее идут очереди инициации с триггерными сообщениями, передающими приложениям инструкции о загрузке тех или иных программ. Очереди передачи сообщений пересылают сообщения удаленным адресатам. Сообщение-запрос, требующее ответа от приложения, может использовать соответствующую ответную (reply-to) очередь, позволяющую приложению-адресату узнать, куда посылать ответ. Очереди отвергаемых сообщений содержат сообщения, которые не могут быть доставлены адресатам из-за переполнения других очередей, несанкционированного использования очередей назначения или отсутствия таковых. Командные очереди соответственно содержат команды управления и конфигурации для ПО обмена сообщениями. И наконец, системные очереди по умолчанию выполняют роль шаблонов для задания атрибутов очередей через сеть.

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

Планирование

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

Завершив этап планирования и проектирования, после нескольких неудачных попыток мы наконец-то установили свою среду обмена сообщениями. Один из ложных стартов, на который мы потратили больше всего времени, был вызван попытками сконфигурировать сервер как MSMQ Primary Site Controller (PSC), тогда как во время инсталляции мы ошибочно определили эту машину как MSMQ Primary Enterprise Controller (PEC). Изменение типа контроллера MSMQ требует удаления и переустановки MSMQ. Менее трудоемкой, но столь же раздражающей, как смена контроллера, была процедура задания имен очередей в среде MQSeries. Диспетчер очередей, который направлял наше сообщение с неизвестным адресом назначения в очередь отвергаемых сообщений, мы определили правильно, но впопыхах не успели указать эту очередь, и, естественно, сообщение уходило в никуда.

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

После того как мы определили каналы в среде MQSeries для всех диспетчеров очередей и очередей передачи сообщений на каждом из узлов промежуточных пересылок, мы проделали ту же операцию с удаленными (remote) очередями для идентификации тех маршрутов, по которым хотели направлять сообщения. Определение удаленной очереди позволяет указать ту, которая принадлежит нелокальному диспетчеру очередей. MQSeries использует эти определения для того, чтобы пересылать сообщения в сетях со сложной конфигурацией. Соответствующим образом приложения могут посылать сообщения адресатам с псевдонимами (aliased names) посредством локальной очереди, вместо того чтобы направлять их в поименованные очереди удаленных адресатов или диспетчерам очередей. Возможность указания псевдонима очереди позволяет иметь единый ссылочный уровень для имен очередей (псевдоним не может ссылаться на другой псевдоним). Со своей стороны программисты приложений должны применять не имена диспетчеров очередей адресата, а логические имена очередей, что позволит серверу MQSeries иметь доступ к информации, которую сетевые администраторы используют в определениях удаленных очередей. В таком случае физическое размещение очередей остается в ведении сетевых администраторов.

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

В среде MSMQ шлюз выполняет те же функции, какие очередь передачи выполняет в среде MQSeries. Каждое сообщение, предназначенное для другой ЛВС, проходит через конфигурируемый сетевым администратором для маршрутизации сообщений шлюз. Установка нескольких очередей передачи (и соответствующих им диспетчеров очередей) для MQSeries и использование нескольких шлюзов для MSMQ позволяет сбалансировать трафик рабочей нагрузки и предоставляет альтернативные пути к очереди назначения в случае неисправности связи по основному маршруту.

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

Для того чтобы использовать MSMQ, нам пришлось установить ПО SQL Server 6.5 на сервере MSMQ PEC. Сервер MSMQ хранит информацию очередей (но не сами сообщения, которые остаются в файлах распределения памяти) в СУРБД производства фирмы Microsoft. В следующей версии MSMQ будет использована новая технология Microsoft Active Directory Service, а не SQL Server.

Производительность

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

В свою очередь, для определения местонахождения очередей и поиска маршрутной информации при открытии удаленной очереди для чтения или записи MSMQ использует службы справочника. С этой целью MSMQ осуществляет удаленный вызов через сеть одной из служб справочника. В результате мы получаем один или несколько маршрутов к нужной очереди вместе с информацией о сетевой стоимости каждого маршрута. Сетевая стоимость маршрута -- это чаще всего относительная скорость, которую сетевой администратор указывает для данного маршрута. Microsoft предполагает (и наше тестирование подтверждает), что приложение должно сводить к минимуму число попыток выяснения местоположения очереди и получения сведений об открытых очередях. Процедура поиска по службам справочника заметно снижает производительность обмена сообщениями. Мы отметили небольшую задержку в работе тестового приложения при использовании схемы удаленной очереди для MQSeries, и значительную - при работе с продуктом Microsoft. С помощью функции clock() мы измерили время открытия очереди в обеих средах.

Продукт MQSeries способен выполнять доставку сообщений с атрибутом постоянства (довольно медленно, но с гарантией доставки) или без него (быстрее, но с возможными потерями). В среде MSMQ приложения могут выбирать режим передачи сообщений. Это задерживает их прибытие и последующую обработку до тех пор, пока приложение не выполнит транзакцию. Общая производительность повысится при применении сообщения без атрибута постоянства в среде MQSeries и снижении числа транзакций в среде MSMQ. Мы также рекомендуем умеренно использовать каналы передачи данных DTC. После того как вы определите транзакции в терминах бизнес-логики, постарайтесь исследовать комбинации наиболее часто применяемых операций в агрегированных транзакциях.

Поэкспериментировав с несколькими транспортными протоколами, мы заметили, что выбор протокола мало влияет на производительность. MSMQ передает дейтаграммы по протоколам IPX или TCP/IP, а MQSeries устанавливает сеансы связи между смежными узлами по протоколам LU 6.2 (SNA), NetBIOS, SPX или TCP/IP. Так или иначе, выбор определенного сетевого протокола по сложности не может сравниться с процессом поиска различных узких мест в системе обмена сообщениями.





  
11 '1998
СОДЕРЖАНИЕ

колонка редактора

• Наперегонки со светом

локальные сети

• Внедрение приоритизации трафика в сети Ethernet

• Удаленная загрузка Windows 95

• В эпоху интеллектуальных зданий

• Консолидация информационно-вычислительных ресурсов

• Коммутаторы для рабочих групп: мал золотник, да дорог

• Цифровые мультиметры на страже безопасности

• Место коаксиальных кабелей вне локальных сетей

• Один дюйм или два?

бизнес

• О российском канале дистрибуции

• Профессор сетевых технологий

• Oracle побеждает в SQL-гонке

интернет и интрасети

• Приоритизация трафика в сетях IP

• Отладка работы PPP-соединений

• ISP все еще решают проблему пиринга

корпоративные сети

• Тестируем связующее ПО МОМ

• Платформам сетевого управления недостает лидера

услуги сетей связи

• IP-телефония: проблем хватает

• Предоставление услуг IN на сети МГТС

• Спутники облегчают доступ ко Всемирной паутине

• Мониторинг трафика Frame Relay: выгода налицо

• DSL: скорость и средства для ее контроля

• DSL: трудная дорога к стандартам

защита данных

• ИБП для централизованной системы бесперебойного гарантированного электроснабжения

системы учрежденческой связи

• Отечественные УАТС: с оптимизмом — в будущее

новые продукты

• PairView "найдет" потерянные пары; Простота и эффективность Novell Replication Services 1.21;



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх