Московский государственный университет путей сообщения
Опубликован: 11.04.2006 | Доступ: свободный | Студентов: 1270 / 281 | Оценка: 4.39 / 4.00 | Длительность: 17:21:00
ISBN: 978-5-9556-0036-1
Специальности: Разработчик аппаратуры
Лекция 8:

Средства управления распределенными системами

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >

Семантика общей транспортной среды

Взаимодействие сетевых процессов является <сердцем> инфраструктуры распределенных систем. В ранних поколениях вычислительных систем коммуникационные структуры в значительной степени влияли на сервисы и подсистемы, доступные прикладным программам. Современные распределенные высокоуровневые сервисы и менеджеры ресурсов, опирающиеся на клиент-серверную технологию, должны поддерживать различные операционные системы и широкий спектр сетевого оборудования. Отсюда следует, что менеджеры ресурсов нуждаются в сервисах, не зависящих от конкретных сетевых и канальных протоколов. Поэтому все современные распределенные системы обеспечивают четкое разделение между коммуникационными протоколами и сетевыми сервисами. Эта тенденция привела к структуре сетевого сервиса, определенной в Open Blueprint корпорации IBM. Она состоит из семантики общей транспортной среды (Common Transport Semantics), транспортных сервисов, подсетей, а также системы сигнализации и управления. В данном разделе рассматривается семантика (набор правил) общей транспортной среды (Common Transport Semantics, CTS) и ее реализация в виде коммуникационных серверов.

Common Transport Semantics изолирует сервисы вышестоящего уровня (CPI-C, RPC и MQI) от расположенных ниже транспортных сервисов. Это достигается обеспечением единой внешней структуры транспортных протоколов. Отсюда следует независимость сервисов высших уровней от транспортных протоколов, что, в свою очередь, ведет к возможности включения различных сетевых транспортных драйверов в общую реализацию этих сервисов. Кроме того, использование CTS делает возможной интеграцию сетей с различными протоколами через транспортные шлюзы, которые компенсируют различия в нижележащих сетевых транспортах. Это, в свою очередь, делает возможной совместную работу рабочих станций независимо от физической среды локальной сети LAN (маркерное кольцо, Ethernet) или транспортных протоколов (IPX, NetBIOS, SNA или TCP/IP).

В рамках Open Blueprint CTS тесно связана с мультипротокольной транспортной сетевой архитектурой (MPTN). MPTN определяет интерфейс как набор транспортных сервисов, объединяющих связи через множество сетевых протоколов. В дополнение к логическим связям через однородные сети она отделяет прикладные программы от сетей таким образом, что сообщения от приложений могут передаваться посредством любого протокола, объявленного в интерфейсе. Связь приложения и интерфейса осуществляется с помощью CTS. Таким образом, MPTN можно рассматривать как группу однопротокольных сетевых транспортов, каждый из которых имеет собственный протокол. Однако все они физически связаны и реализуют один и тот же протокол. Отсюда следует, что MPTN для пользователя имеет вид единой логической сети, имеющей единый протокол. Это обеспечивается двумя основными составляющими MPTN: Common Transport Semantics и шлюзами MPTN. На рис. 4.5 представлена логическая сеть MPTN, содержащая две однопротокольные сети, которые связаны через шлюз MPTN. Архитектура MPTN является открытой, и вообще говоря, исключает принудительные привязки сетевых протоколов и приложений к транспортным сервисам. Другими словами, API приложений и их сервисы могут взаимодействовать через протокол, отличающийся от предназначенного для них изначально. Приложения должны быть попарно согласованы, а именно, оба должны использовать один и тот же протокол.

Мультипротокольная транспортная сеть

Рис. 4.5. Мультипротокольная транспортная сеть

Например, две программы, изначально использующие APPC и взаимодействующие через SNA, могут взаимодействовать через TCP/IP, две гнездовые программы, изначально использовавшие TCP/IP, могут взаимодействовать через SNA. Но APPC-приложение не может взаимодействовать с гнездовой программой ни через SNA, ни через TCP/IP.

Архитектура MPTN реализована как семейство продуктов AnyNet корпорации IBM. Семейство продуктов AnyNet дает возможность существующим приложениям без всяких модификаций взаимодействовать через сети с множеством сетевых транспортных протоколов. Использование функций этого семейства продуктов позволяет уменьшить количество транспортных протоколов в сетях, что, в свою очередь, ведет к снижению общей сложности распределенных систем.

Семейство продуктов AnyNet состоит из различных компонентов для использования в различных операционных системах IBM: AIX, MVS, OS/2, OS/400 и на платформах Windows. Так, например:

  • CS/AIX предназначен для операционной среды AIX;
  • CS Linux предназначен для операционной среды Linux;
  • AnyNet/MVS предназначен для операционной среды MVS;
  • AnyNet/2 предназначен для операционной среды OS/2;
  • CS/NT предназначен для операционной среды Windows.

Семейство продуктов AnyNet реализует архитектуру MPTN, которая поддерживает сетевые соединения на основе смешанных протоколов и функции межсетевых соединений. Частью продуктов AnyNet, например, являются:

  • APPC через TCP/IP. Эта функция имеется в операционных системах MVS, AIX OS/2 и Windows. Она позволяет прикладным программам, использующим интерфейсы APPC или CPI-C, взаимодействовать с парными программами через IP-сети. Поддерживаются протоколы LU 6.2 для независимых логических устройств LU. Функция APPC через TCP/IP может работать и в качестве шлюза MPTN, разрешая сессию LU 6.2 и потоки данных между сетями SNA и TCP/IP. Она позволяет взаимодействовать с парными программами через IP-сети.
  • SNA через TCP/IP. Эта функция также имеется в операционных системах MVS, AIX OS/2 и Windows. Она позволяет приложениям SNA взаимодействовать с парными программами через IP-сети. Кроме поддержки независимой связи через LU 6.2, функция SNA через TCP/IP обеспечивает взаимодействие зависимых логических устройств, таких как принтеры и эмуляторы.
  • Гнездовые соединения через SNA. Эта функция также имеется в операционных системах MVS, AIX OS/2 и Windows. Она позволяет прикладным программам, использующим интерфейс гнездовых соединений или интерфейс WinSock взаимодействовать через сети SNA. Функция гнездовых соединений через SNA использует диалог LU 6.2 для обеспечения взаимодействия.
  • Гнездовые соединения через шлюз SNA. Эта функция также имеется в операционных системах MVS, AIX OS/2 и Windows. Она соединяет IP-сети с сетями SNA для обеспечения взаимодействия между приложениями, использующими интерфейс гнездовых соединений. Такие приложения, работающие в существующих сетях TCP/IP, могут взаимодействовать с приложениями, использующими гнездовые соединения в сетях SNA, не нуждаясь в каком-либо перепрограммировании.

На рис. 4.6 показана связь двух прикладных программ с помощью функции APPC через TCP/IP. Взаимодействующие программы используют функции API независимого LU 6.2 для доступа друг к другу. На этом рисунке отсутствует шлюз, поэтому оба прикладных процесса связываются через IP-сеть.

Взаимодействие прикладных программ с помощью функции APPC через TCP/IP

Рис. 4.6. Взаимодействие прикладных программ с помощью функции APPC через TCP/IP

Если сконфигурировать коммуникационный сервер как сетевой узел, то функция APPC через TCP/IP может выполняться в качестве шлюза. В этом случае возможна установка сессии и потока данных между сетями SNA и TCP/IP, как это показано на рис. 4.7. Следует отметить, что функция APPC через TCP/IP поддерживает два или более шлюзов между двумя сетями, а также два или более шлюзов, соединяющие три или более сетей.

Взаимодействие APPC-программ с помощью функции APPC через TCP/IP, используемой в качестве шлюза

Рис. 4.7. Взаимодействие APPC-программ с помощью функции APPC через TCP/IP, используемой в качестве шлюза

Свойство мультипротокольности реализовано в виде коммуникационных серверов. Коммуникационные серверы работают на различных платформах: OS-390, OS/400, UNIX (Linux), Sun Solaris и др. Используя различные коммуникационные серверы, APPC-приложения взаимодействуют с рабочими станциями в сети TCP/IP, имеющими доступ к API APPC. Таким образом, APPC-приложение через протокол TCP/IP, может являться хостом по отношению к рабочей станции, рабочей станцией по отношению к рабочей станции или хостом по отношению к хосту. Кроме того, в коммуникационных серверах поддерживается интерфейс гнездовых соединений BSD (Berkley Software Distribution) через протокол SNA.

Примером такого сервера может служить коммуникационный сервер CS Linux. Этот сервер представляет собой коммуникационное программное обеспечение, функционирующее в среде операционной системы Linux. Коммуникационный сервер CS Linux связывает прикладные программы через сети SNA и TCP/IP. Он преобразует рабочую станцию, функционирующую под управлением операционной системы Linux, в узел сети SNA. Такое преобразование выполняется с помощью добавления к рабочей станции ресурсов и протоколов SNA, что позволяет ей взаимодействовать с другими рабочими станциями и хостами в сети SNA. На рис. 4.8 показаны возможные варианты использования коммуникационного сервера CS Linux.

Варианты использования коммуникационного сервера CS Linux

Рис. 4.8. Варианты использования коммуникационного сервера CS Linux

В левой части рис. 4.8 CS Linux установлен на отдельной системе z800, что разгружает основную систему z/OS. В правой части этого рисунка показан вариант установки CS Linux в одном из разделов основной системы z/OS.

Коммуникационный сервер CS Linux обеспечивает выполнение следующих служб:

  • Поддержка иерархических сетей SNA. В сетях такого типа один хост управляет взаимодействием между рабочими станциями, осуществляет менеджмент сети в целом и обеспечивает хранение больших объемов данных. Все остальные узлы в сети по отношению к главному узлу являются подчиненными. Рабочие станции AIX могут находиться в иерархической сети, если сконфигурированы как сателлитные узлы.
  • Поддержка сетей APPN <точка-к-точке>. Для среды распределенной обработки данных коммуникационный сервер CS Linux поддерживает сети APPN и TCP/IP. В таких сетях рабочие станции осуществляют функции обработки и взаимодействия друг с другом напрямую, как <точечные> узлы. Такого вида сети полностью используют возможности рабочих станций AIX, являющихся альтернативой высокопроизводительным хостам. Сеть APPN может включать в свой состав как сетевые узлы APPN, так и конечные узлы APPN. Узлы первого типа обеспечивают управление трафиком, динамическую маршрутизацию и сервисы управления сетью. Узлы второго типа используют сервисы APPN для взаимодействия с сетевыми узлами APPN. Следует отметить, что хосты могут функционировать в качестве сетевых узлов, используя независимые LU 6.2 для связи с рабочими станциями и другими хостами.

На уровне управления данными сервер CS Linux предоставляет различные возможности для установки параметров трафика, таких как скорость передачи, размер блоков данных, параметров безопасности и т. п. Коммуникационный сервер CS Linux поддерживает различные типы LU для различных классов прикладных программ. Так, для иерархических сетей это зависимые LU. Например, LU0 обеспечивает простейшее межпрограммное взаимодействие, LU2 поддерживает эмуляцию терминала серии IBM - 3270. Другие типы LU позволяют прикладным программам принимать участие в распределенных вычислениях или взаимодействовать с удаленными терминалами.

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

Для разработки прикладных программ в состав сервера включен программный интерфейс приложений (API) для различных типов LU, для распределенных процессов, сетевого управления и администрирования собственно сервера CS Linux. Кроме того, в состав API этого сервера входят функции, обеспечивающие его совместимость с аналогичными серверами других типов из семейства AnyNet, предназначенны для работы в иных операционных средах.

В контексте коммуникационных серверов последний может рассматриваться как интерфейс, дающий возможность транзакционным программам (ТР) взаимодействовать с поддерживающими их LU. Он состоит из библиотеки команд (также называемых функциями, вызовами или подпрограммами), из которой ТР выбирает все необходимое для создания запроса к LU на выполнение какого-либо действия. Таким действием, например, может быть передача данных (SEND_DATA). LU обрабатывает полученный запрос и строит поток данных в соответствии с требуемым протоколом, добавляет заголовок с указанием адреса назначения и передает данные партнерскому LU. Одним из наиболее мощных коммуникационных серверов является интерфейс CPI-C, подробно рассмотренный выше. CPI-C использует общий для всех систем IBM набор синтаксических правил, вследствие чего в настоящее является фактическим стандартом.

Другие возможности коммуникационного сервера CS Linux включают в себя функции поддержки интерфейса APPC, который также был подробно рассмотрен выше, функции поддержки интерфейса гнездовых соединений IBM, функции поддержки интерфейса распределенных вычислений и процессов, таких как DB/2 и т.п.

< Лекция 7 || Лекция 8: 12345 || Лекция 9 >