Windows NT как зеркало межсетевого взаимодействия

Существует большое количество средств и продуктов для Windows NT, поддерживающих взаимодействие с другими сетями и операционными системами. В первую очередь, это встроенные средства, входящие в стандартную поставку систем Windows NT Server и Windows NT Workstation, а именно: NWLink, NetWare Compatible Service (NWCS), Gateway Services for NetWare, Directory Service Manager for NetWare для взаимодействия с сетями NetWare, протоколы IP, ICMP, TCP, UDP, ftp, telnet для взаимодействия с сетями TCP/IP. Microsoft выпускает и отдельные продукты межсетевого взаимодействия - например, шлюзы для своей почтовой системы Microsoft Mail Server 3.5 или File and Print Services for NetWare - реализацию протоколов NCP и SAP в среде Windows NT. Появилось и большое количество продуктов для Windows NT, произведенных третьими фирмами, например: BW-Connect NFS компании Beame & Whiteside, PathWorks for Windows NT компании Digital Equipment, NFS connectivity services компании Intergraph, редиректор для сетей Banyan VINES, NetWare Client for Windows NT компании Novell. Этот список можно продолжать и еще.

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

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

Рассмотрим эти характеристики подробней и проиллюстрируем примерами имеющихся на рынке продуктов для Windows NT.

Мультиплексор протоколов или шлюз

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

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

Windows NT являет собой хороший пример операционной системы, мультиплексирующей несколько стеков протоколов - NetBEUI/SMB, TCP/IP и Novell IPX/NCP (компонент NWLink реализует протокол сетевого уровня IPX, а NWCS - протокол NCP, обеспечивающий доступ к файлам и принтерам).

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

В составе Windows NT Server 3.51 поставляется шлюз Gateway Service for NetWare, который обеспечивает для всех клиентов этого сервера прозрачный доступ к сервисам файлов и печати серверов NetWare. Другим примером шлюза является компонент Microsoft BackOffice - SNA Server. Этот сервер обеспечивает клиентам Windows NT прозрачный доступ к мэйнфреймам и миникомпьютерам IBM.

Каждый из вышеперечисленных подходов имеет свои достоинства и недостатки.

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

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

В принципе у пользователя при работе с несколькими стеками протоколов может возникнуть проблема ориентации в незнакомой среде, с незнакомыми командами, правилами и методами адресации. В Windows NT сделана попытка в такой ситуации как-то облегчить жизнь пользователю в этой ситуации. Независимо от используемого протокола прикладного уровня (например, Microsoft SMB или Novell NCP) ему предоставляется один и тот же интуитивный графический интерфейс, с помощью которого он просматривает и выбирает нужные удаленные ресурсы. Однако, некоторые сервисы пока еще не охвачены этим универсальным средством: большинство сервисов стека TCP/IP - ftp, tftp, r*, ping и другие - используют режим командной строки. Пользователь должен выучить названия команд, их синтаксис и значения многочисленных ключей. Telnet - еще один сервис стека TCP/IP - использует для диалога собственный графический интерфейс, поскольку по своей природе эмуляция терминала значительно отличается от файлового сервиса.

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

Шлюз - средство более медленное, чем переключаемые стеки протоколов. Это происходит, во-первых, из-за довольно больших затрат времени на собственно процедуру трансляции, а, во-вторых, из-за задержек запросов в очереди к разделяемому всеми клиентами шлюзу. Это делает шлюз плохо масштабируемым решением.

Что нужно согласовывать

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

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

Более реальными представляются следующие варианты распределения функций между приложениями и системными средствами.

Первый вариант - системные средства берут на себя все функции по передаче сообщений, согласуя три или четыре нижних уровня модели OSI. Приложения в таком случае реализуют свой собственный протокол взаимодействия, который включает функции трех верхних уровней модели OSI - прикладного, представительного и сеансового. Приложения осуществляют согласование только тех сервисов верхнего уровня, которые им необходимы. Примером такого распределенного приложения может служить электронная почта, агенты передачи сообщений которой работают как в среде Windows NT, так и в среде UNIX, непосредственно обращаясь для отправки и получения сообщений к средствам сетевого уровня, например к протоколу TCP (через соответствующий интерфейс, например Berkeley Sockets). В соответствии с этим вариантом построены такие корпоративные СУБД, как Oracle, Informix, Sybase.

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

Системные средства могут реализовывать функции по согласованию стеков протоколов частями, с помощью нескольких программных продуктов. Часто один продукт согласует только сервисы прикладного уровня (или один из этих сервисов), а другой - только транспортные протоколы. Например, продукт компании Microsoft File and Print Services for NetWare обеспечивает в среде Windows NT поддержку только прикладных протоколов файлового сервиса и сервиса печати NetWare, но не выполняет функций согласования транспортных протоколов. Поэтому для его работы с клиентами NetWare необходимо наличие на сервере компонента NWLink или другого продукта, реализующего протокол Novell IPX.

Направление доступа

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

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

Большинство имеющихся на рынке продуктов обеспечивает только однонаправленное согласование прикладных сервисов. Например, шлюз Gateway Services for NetWare обеспечивает клиентам Windows NT доступ к сервисам файлов и печати NetWare, но не предоставляет клиентам NetWare доступ к аналогичным сервисам Windows NT. Обратная задача может быть решена с помощью продукта File and Print Services for NetWare, устанавливаемого на серверах Windows NT. Он представляет собой серверную часть протокола NCP, которая в режиме мультиплексирования работает параллельно с серверной частью "родного" для Windows NT протокола SMB.

Где размещать

Если в качестве средства межсетевого взаимодействия выбран шлюз, то вопрос о месте его размещения не возникает вообще - шлюз должен быть расположен на сервере той сети, в которой находятся его клиенты. Например, шлюз SNA Server, позволяющий клиентам Windows NT обращаться к мейнфреймам IBM, должен быть установлен на сервере Windows NT Server.

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

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

При выборе места размещения часто возникает и другой, чисто практический вопрос: есть ли возможность изменять программное обеспечение обоих взаимодействующих сетей или одна из них является недоступной? В принципе задачу взаимодействия двух сетей в полном объеме можно решить путем установки согласующих продуктов только в одной сети - если есть соответствующие продукты. Например, Windows NT позволяет обеспечить двустороннее взаимодействие с сетями NetWare, устанавливая дополнительные продукты только на своей стороне, оставив программное обеспечение клиентов и серверов NetWare в неизменном виде. Клиенты на базе Windows NT Workstation получают доступ к сети NetWare с помощью установленных в них продуктов NWLink и NWCS, а серверы Windows NT Server предоставляют свои ресурсы клиентам сети NetWare с помощью продукта File and Print Services for NetWare. (Правда, нужно учитывать, что редиректор NWCS не поддерживает службу каталогов NDS компании Novell, поэтому если мы хотим работать с серверами NetWare 4.x как полноценные клиенты или, тем более, как администраторы, то вместо NWCS и NWLink следует использовать продукт компании Novell - NetWare Client for Windows NT. Сервер File and Print Services for NetWare также не поддерживает NDS и выполняет функции сервера NetWare 3.12.)

Мы рассмотрели далеко не все имеющиеся на рынке продукты межсетевого взаимодействия для Windows NT. Их богатый выбор говорит о постоянно растущем интересе к средствам построения неоднородных корпоративных сетей "без головной боли". Сегодня каждая операционная система стремится проявлять максимум дружественности к своим потенциальным партнерам по сети Internet, и Windows NT, только еще завоевывающая свое место под "корпоративным" солнцем, подает в этом отношении пример для своих более зрелых и поэтому более эгоистичных собратьев.