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

ДВА ПОДХОДА К ВЗАИМОДЕЙСТВИЮ
WINDOWS NT МУЛЬТИПЛЕКСИРУЕТ НА ВСЕХ УРОВНЯХ
ШЛЮЗ WINDOWS-NETWARE
БОГАТСТВО ВЫБОРА И ПРОБЛЕМА БУРИДАНОВА ОСЛА
МУЛЬТИПЛЕКСОР ПРОТИВ ШЛЮЗА - ЗА И ПРОТИВ
НАПРАВЛЕНИЕ СОГЛАСОВАНИЯ
ГДЕ ВСЕ ЭТО РАЗМЕЩАТЬ?

Одной из основных целей, которую компания Microsoft преследовала, создавая операционную систему нового поколения (NT - New Technology), было завоевание рынка сетевых ОС для корпоративных серверов, который тогда прочно удерживала (и в той или иной степени продолжает это делать по сей день) сетевая ОС Novell NetWare. Так как одна из основных особенностей корпоративной сети - это ее неоднородность, то Windows NT в качестве претендента на роль лидера среди серверных сетевых операционных систем просто обязана была поддерживать кроме родного стека коммуникационных протоколов NetBEUI/SMB и другие наиболее популярные стеки, среди которых TCP/IP или IPX/NCP, а также обеспечивать возможность легкого включения других стеков, поставляемых третьими фирмами.

ДВА ПОДХОДА К ВЗАИМОДЕЙСТВИЮ

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

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

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

Если в системе предусматривается мультиплексирование средств каждого из трех уровней, то диалог между компьютерами может поддерживаться, например, протоколом SMB на верхнем уровне, протоколами TCP и IP на среднем уровне и протоколом Ethernet на нижнем уровне. Для организации связей между различными протоколами на каждом уровне вводится дополнительный компонент, называемый мультиплексором или менеджером протоколов. Мультиплексор осуществляет стыковку пар протоколов двух соседних уровней в зависимости от потребностей приложений (заметим, что на верхнем уровне мультиплексор соединяет приложение с различными редиректорами).

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

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

Шлюз реализует взаимодействие "многие-ко-многим", то есть все клиенты сервера, на котором установлен шлюз, могут обращаться с запросами ко всем серверам в другой сети.

WINDOWS NT МУЛЬТИПЛЕКСИРУЕТ НА ВСЕХ УРОВНЯХ

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

Picture 1 (1x1)

Рисунок 1.
Мультиплексирование протоколов: взаимодействие компьютера с тремя стеками протоколов с двумя одностековыми компьютерами.

Для того чтобы один сетевой протокол мог использовать несколько канальных протоколов (реализованных в виде драйверов сетевых адаптеров) и, наоборот - один драйвер сетевого адаптера мог работать с несколькими сетевыми протоколами, в Windows NT на нижнем уровне используется мультиплексор NDIS (Network Driver Interface Specification), новая 32-разрядная версия которого 3.0 была разработана специально для Windows NT. NDIS выполняет не только функции мультиплексора, но и функции программной среды, изолирующей драйвер сетевого адаптера от аппаратуры, то есть от самого сетевого адаптера. NDIS предоставляет разработчику драйвера функции управления сетевым адаптером, например функции ввода/вывода или обработки прерываний, что делает код драйвера более мобильным и переносимым. Windows NT поддерживает драйверы сетевых адаптеров не только в стандарте NDIS, но и в популярном стандарте ODI, используемом в сетях Novell NetWare.

На среднем уровне Windows NT вводит свой стандарт на интерфейс транспортных протоколов - TDI (Transport Driver Interface). "Наличие слова Driver" свидетельствует о том, что в Windows NT эти протоколы реализованы в виде драйверов системы ввода/вывода. Если редиректоры и транспортные протоколы написаны в соответствии с правилами TDI, то они могут образовывать произвольные связи между собой, то есть мультиплексироваться. Разработчикам приложений для доступа к функциям транспортного уровня Windows NT предлагает два популярных API - NetBIOS и Windows Sockets, которые, в свою очередь, обращаются к транспортным протоколам через интерфейс TDI.

Кроме собственных отдельных драйверов, разработанных в стандарте TDI (например NetBEUI), Windows NT использует также модифицированную среду STREAMS, созданную в свое время знаменитым Денисом Ритчи для операционной системы Unix. Изменения среды STREAMS заключались в согласовании ее верхнего уровня с интерфейсом TDI, что позволило использовать в Windows NT значительную часть кодов уже разработанных транспортных протоколов для этой среды.

На верхнем уровне в Windows NT имеется два мультиплексора - MUP и MPR, соответствующие двум сценариям доступа приложений к сетевым ресурсам в гетерогенной сети.

Первый сценарий состоит в том, что приложение обращается к операционной системе с запросом, указывая в явном виде имя сетевого ресурса без предварительной установки соединения. Такой запрос может быть выполнен при условии, что имя задано в соответствии с универсальным соглашением об именовании UNC (Universal Naming Convention).

В имени UNC сначала указывается имя сервера, предваряемое двумя слэшами, а затем сетевое имя разделяемого каталога и составное имя файла. Например, приложение может открыть файл, используя имя andemC$Annarticle.doc, где tandem - имя компьютера, C$ - сетевое имя разделяемого каталога, назначенное пользователем или системой, Annarticle.doc - составное имя файла относительно каталога C$.

Когда подсистема ввода/вывода Windows NT анализирует имя файла и обнаруживает, что оно является UNC-именем, то вызывается MUP (Multiple UNC Provider), которому это имя передается для дальнейшей обработки. В обязанности MUP входит определение принадлежности сетевого ресурса с заданным именем той или иной сети, инсталлированной в системе. Если обращение по этому имени происходит впервые, то MUP просто передает его для опознания всем редиректорам, которые установлены в системе (их список имеется в базе конфигурации системы Registry). Каждый редиректор в соответствии с поддерживаемым им протоколом производит поиск ресурса по заданному имени и возвращает результат поиска мультиплексору MUP. MUP анализирует ответы редиректоров и, если один из них распознал ресурс, передает ему запрос приложения для выполнения. Одновременно MUP кэширует соответствие имени сетевого ресурса определенному редиректору, чтобы не выполнять описанную процедуру каждый раз при поступлении запроса к этому ресурсу.

Реализован MUP в виде драйвера, в чем можно убедиться, просматривая список их имен в группе Devices утилиты Control Panel.

В соответствии со вторым сценарием доступа приложение предварительно отображает сетевой ресурс на локальный (устанавливает соединение), а затем обращается к нему как к локальному ресурсу. Например, сначала разделяемый каталог andemC$ отображается на локальный дисковод F:, а затем приложение обращается к файлу F:Annarticle.doc как к локальному файлу.

Процедура установления соединения в общем случае состоит из двух этапов:

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

Просмотр сетевых ресурсов необязателен, но в большой сети он может существенно облегчить жизнь пользователю, которому в этом случае незачем помнить имена всех серверов и разделяемых каталогов. В различных сетях сервис просмотра ресурсов организован по-разному. В сетях Novell NetWare 3.x, например, редиректор собирает список доступных серверов с помощью широковещательного протокола SAP, а в сетях NetWare 4.x редиректор для этой цели обращается с запросами к централизованной справочной службе NDS. В сетях Microsoft Windows NT список доступных серверов предоставляет специальный компонент - Computer Browser, а список разделяемых каталогов выясняется в результате диалога редиректора и сервера по протоколу SMB. В сетях TCP/IP при использовании сервисов ftp, telnet или www услуга по просмотру сетевых ресурсов вообще не предусмотрена, и пользователь должен явно задавать символьные имена хостов ftp или www, на которых хранятся нужные ему данные.

Процедуры просмотра ресурсов и установления соединения выполняются в Windows NT с участием еще одного мультиплексора прикладного уровня - маршрутизатора поставщиков услуг MPR (Multiple Provider Router). MPR, реализованный в виде динамической библиотеки DLL, выполняет общие для всех типов сетей действия по просмотру и отображению сетевых ресурсов в одном стиле. Действительно, пользователь видит, что в диалоговом окне Connect Network Drive утилиты File Manager перечень поддерживаемых сетей, набор имеющихся в них серверов и список разделяемых каталогов на серверах отображаются с помощью одних и тех же графических иконок, независимо от того, сеть ли это NetWare или Microsoft Windows. Также показательна и процедура дополнительной аутентификации при подключении к новой сети - она может быть выполнена одинаковым образом для сетей разных типов.

Picture 2 (1x1)

Рисунок 2.
Мультиплексирование в Windows NT.

Другой основной функцией MPR является мультиплексирование связей между приложением и несколькими редиректорами. Если приложение не делает запрос на доступ к сетевому ресурсу в явном виде по UNC-имени, а хочет сначала просмотреть и/или отобразить ресурсы, то такой запрос попадает сначала в MPR, который переправляет его нужному редиректору. Запросы от приложений могут явно указывать, с каким типом сети нужно работать - в этом случае MPR просто передает запрос указанному редиректору. Если же в запросе тип сети не указан, то MPR поступает так же, как и MUP, - он передает запрос для опознания ресурса всем редиректорам и ждет от них ответы.

MPR взаимодействует с редиректорами не непосредственно, а через промежуточные компоненты, называемые сетевыми поставщиками услуг (network provider). Эти промежуточные компоненты обеспечивают согласование исходного интерфейса каждого редиректора с единым стандартным интерфейсом, с помощью которого MPR общается с редиректорами. Таким образом, для включения в Windows NT нового типа сети нужно разработать два компонента - редиректор и сетевой поставщик услуг.

Разделение обязанностей между сетевым поставщиком услуг и редиректором - их внутреннее дело, главное, чтобы поставщик поддерживал стандартный интерфейс с MPR. Встроенный поставщик сети Microsoft для получения списка доменов, рабочих групп и компьютеров обращается к сервису Computer Browser, а список разделяемых каталогов на сервере получает с помощью редиректора. При отображении разделяемого каталога на локальный дисковод, например andemC$ на F:, поставщик услуг сам создает в дереве имен объектов Windows NT новый объект - символьную связь с именем F:, которая указывает на редиректор сети Microsoft. После создания такой связи работа мультиплексора MPR по поддержке доступа к файлам (и подкаталогам) каталога F: закончена. Теперь эти обращения будут обрабатываться системой ввода/вывода Windows NT, которая, разбирая имя файла, обнаружит, что диск F: - это не реальное устройство, а символьная связь, и вызовет для дальнейшей обработки указанный в символьной связи нужный редиректор.

ШЛЮЗ WINDOWS-NETWARE

Пользуясь Windows NT и другими продуктами Microsoft на ее основе, администратор может выбрать для работы с "чужеродными" сетями решение без использования мультиплексоров протоколов на клиентских компьютерах, а именно шлюз. В Windows NT Server есть один встроенный шлюз Gateway Service for NetWare, естественно, для доступа к серверам NetWare; другие шлюзы нужно приобретать как отдельные продукты.

Шлюз Gateway Service for NetWare обеспечивает клиентам сети Windows NT (а в их число входят компьютеры Windows NT Workstation, Windows for Workgroups, Windows 95 и другие) прозрачный доступ к томам и каталогам серверов NetWare 3.x и 4.x. При этом клиенты Windows NT не должны устанавливать редиректоры Net-Ware (клиентские части протокола NCP).

Для доступа к файлам NetWare клиенты, используя свой "родной" протокол SMB, обращаются к серверу Windows NT, на котором работает шлюз Gateway Service for NetWare. Разделяемые каталоги серверов NetWare выглядят для пользователей точно так же, как и разделяемые каталоги сервера, на котором расположен шлюз. Для того чтобы эти виртуальные каталоги выглядели как реальные, шлюз совместно с администраторами двух сетей выполняет некоторую предварительную работу.

Picture 3 (1x1)

Рисунок 3.
Шлюз Gateway Service for NetWare.

Администратор сети NetWare заводит фиктивного пользователя, который отныне будет представлять в этой сети шлюз. Имя его выбирается произвольно, но он обязательно должен быть членом группы NTGATEWAY. Далее администратор NetWare определяет все ресурсы своей сети, к которым будет разрешен доступ клиентам сети Microsoft, и задает права доступа к этим ресурсам для пользователя-шлюза. Заметим, что так как все клиенты сети Windows NT для администратора NetWare выступают в виде одного пользователя, то он не может дифференцировать этих клиентов по правам доступа. Такая возможность делегируется администратору сети Microsoft.

Этот администратор при конфигурации шлюза дает свои имена разделяемым каталогам NetWare и, используя стандартные наборы прав доступа Windows NT, может более тонко определить привилегии каждого пользователя по отношению к этим виртуальным разделяемым каталогам. Очевидно, что для свободного управления правами клиентов шлюза сам шлюз должен иметь максимальные права доступа к каталогам серверов NetWare. Следовательно, администратор сети NetWare должен полностью доверять администратору сети Microsoft. На практике это не всегда приемлемо, за что Novell и критикует разработчиков шлюза Gateway Service for NetWare.

БОГАТСТВО ВЫБОРА И ПРОБЛЕМА БУРИДАНОВА ОСЛА

Существует большое количество средств и продуктов для Windows NT, поддерживающих взаимодействие с другими сетями и операционными системами. В первую очередь, это встроенные средства, входящие в стандартную поставку Windows NT Server и Windows NT Workstation, в числе которых NWLink, NetWare Compatible Service (NWCS), Gateway Service 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.

Этот список можно еще продолжать и продолжать.

Какими же продуктами лучше пользоваться - встроенными или купленными специально? Если предпочесть первое, то какие продукты выбрать при конфигурировании, если второе, то неплохо бы знать, чей продукт и что мы приобретаем, платя дополнительные деньги за отдельный продукт. Увы, богатство выбора не только помогает создать хорошую сеть, но и создает "проблему Буриданова осла".

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

· способ реализации - мультиплексор протоколов или шлюз;

· уровень и конкретный набор согласуемых протоколов - транспортные протоколы или протоколы прикладного уровня;

· направление взаимодействия - согласование клиентских или серверных частей протоколов;

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

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

МУЛЬТИПЛЕКСОР ПРОТИВ ШЛЮЗА - ЗА И ПРОТИВ

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, то при работе в неоднородной в отношении этого сервиса сети потребуются системные средства согласования именно таких протоколов. Если же программа, реализующая электронную почту, использует для передачи сообщений удаленный файловый сервис, то для ее нормальной работы на прикладном уровне достаточно иметь системные средства согласования протоколов файлового сервиса.

Picture 4 (1x1)

Рисунок 4.
Сервер File and Print Services for NetWare и протокол NWLink превращают сервер Windows NT Server для клиентов NetWare в сервер NetWare 3.12.

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

НАПРАВЛЕНИЕ СОГЛАСОВАНИЯ

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

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

Большинство имеющихся на рынке продуктов предоставляет только однонаправленное согласование прикладных сервисов. Например, шлюз Gateway Service 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.

Picture 5 (1x1)

Рисунок 5.
При установке редиректора NetWare Compatible Service рабочая станция Windows NT Workstation может непосредственно обращаться к серверам NetWare 3.x.

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

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

Picture 6 (1x1)

Рисунок 6.
Редиректор NetWare Client for Windows NT компании Novell позволяет рабочей станции Windows NT стать полноценным клиентом сервера NetWare 4.x с поддержкой средств NDS.

При выборе места размещения часто возникает и другой, чисто практический вопрос: можно ли изменять программное обеспечение обеих взаимодействующих сетей или одна из них недоступна? В принципе задача взаимодействия двух сетей решается в полном объеме за счет установки согласующих продуктов только в одной сети - если для нее есть соответствующие продукты. Например, 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. Их богатый выбор говорит о постоянно растущем интересе к средствам построения неоднородных корпоративных сетей "без головной боли". Сегодня каждая операционная система стремится проявлять максимум дружественности к своим потенциальным партнерам по объединенной сети, и Windows NT, только еще завоевывающая свое место под корпоративным солнцем, подает в этом отношении пример своим более зрелым и поэтому более эгоистичным собратьям.

Наталья Олифер и Виктор Олифер - эксперты Центра информационных технологий. С ними можно связаться по телефону: (095) 932-92-12