Информатика в техническом университете / Информатика в техническом университете. Телекоммуникации и сети

Для поддержки протокола ТЫ на файловом сервере используется библио­ тека CLffi.NLM. На файловом сервере следует дополнительно загрузить NLMмодуль TLI.NLM для использования служб, основанных на STREAMS.

Идентификация услуг. Протокол SAP

В NetWare протокол SAP (Service Advertising Protocol) является надстрой­ кой над протоколом IPX и используется файловым сервером для оповещения других станций о предоставляемых услугах. Для оповещения используется широковещательный пакет IPX (в поле DestNode заголовка IPX и в поле ImmAddress блока ЕСВ указывается значение FFFFFFFFh) с номером гнезда 0x0452.

Каждый файловый сервер посылает SAP-пакет примерно через каждые 60 с (структура пакета см. рис 8.18).

С помощью этих пакетов файловый сервер информирует другие серверы о своем присутствии. Данные этого пакета помещаются в БД объектов на каж­ дом файловом сервере сети. Если сервер не будет непрерывно объявлять свое имя, то оно теряется из БД каждого файлового сервера NetWare.

Программа PC может получить информащпо о серверах сети двумя спосо­ бами:

читая эти сведения в режиме Bindery из базы данных текущего файлового сервера для объектов типа 0004h (серверы NetWare),

принимая пакеты SAP, используя при этом гнездо 0x0452.

При работе Netware 5.x на «чистом» протоколе сетевого уровня IP исполь­ зуется протокол обнаружения служб SLP, аналогичный протоколу SAP

480

Рис. 8.19. Пример объединения сегментов ЛВС с помощью маршрутизаторов

Протоколы маршрутизации RIP и NLSP

Маршрутизатором называется спещ1альное устройство, которое анализиру­ ет номер сети сташщи-получателя и направляет пакет по оптимальному марш­ руту. На рис. 8.19 представлен пример сети. Здесь четыре сегмента ЛВС с номерами сетей А, В, С, D связаны между собой с помощью маршрутизаторов R1, Б12, R3, R4. Связь осуществляется посредством вьщеленных телефонных каналов, каналов связи сети Х.25, Frame relay, и др.

Если PC WS1 направляет пакет на файловый сервер FS4, то маршрутизатор R1 должен выбрать оптимальный маршрут передачи: R1-R2-R4-FS4 или R1- R3-R2-R4-FS4.

В маршрутизаторах фирмы Novell используются два метода маршрутиза-

дистанщюнный векторный метод на базе протокола RIP (продукт NetWare Multiprotocol Router 2.1 - MPR v.2.1),

анализ состояния соединений на базе протокола NLSP (продукт NetWare Multiprotocol Router 3.x - MPR v.3.x).

Продукты MPR v.2.1 и v.3.x могут функщюнировать на файловом сервере или на выделенной PC.

Рассмотрим принципы работы маршрутизатора на базе MPR v.2.1 (рис. 8.20). Здесь используется протокол RIP (Routing Information Protocol) (см. § 5.5). Предположим, что на маршрутизатор R1 поступает от WS1 пакет IPX, направ­ ляемый на файловый сервер FS4 (см. рис. 8.19). R1 извлекает из заголовка пакета номер сети (D) станции-получателя и выполняет поиск строки в табли­ це «Сеть» (на рисунке номера сетей представлены в виде идентификаторов А, В, С, D). После этого из соответствующей строки таблицы «Канал» (в данном

481

R I P K R 3

Пакет RIP от R3

Рис. 8.20. Схема работы маршрутизатора на базе MPR v.2.1

примере из последней) читается номер канала, куда и направляется пакет. Для данного примера пакет направляется через третий канал маршрутизатору R3, где будут вьшолнены аналогичные действия.

В таблице «Сеть» для каждого номера сети хранится критерий передачи пакета от данного маршрутизатора до соответствующего сегмента. Значеьше этого критерия совпадает с числом промежуточных маршрутизаторов до сег­ мента. Таблица «Сеть» используется для формирования поля данных пакета RIP. Этими пакетами соседние маршрутизаторы обмениваются между собой (примерно один раз в минуту). RIP-пакет представляет собой IPX-пакет с гнез­ дом 0x0453 и типом пакета 1.

Рассмотрим, как происходит обновление строк в таблицах «Сеть» и «Ка­ нал» маршрутизатора. Предположим, что на R1 поступил RIP-пакет от марш­ рутизатора R2 и значение критерия передачи данных от R2 до сети D равно 1 (это значение передается в RIP-пакете). Далее маршрутизатор R1 вьшисляет новое значение критерия для передачи данных от R1 до сети D. Оно будет равно

1 (промежуточный маршрутизатор R2) +

+ 1(критерий передачи данных от R2 до сети D) = 2.

Это число сравнивается со старым значением, равным 3. Так как значение нового критерия (2) меньше старого, то происходит обновление строк таблиц «Сеть» и «Канал» для сети D (рис. 8.20). Теперь пакет, передаваемый от стан­ ции WS1 на файловый сервер FS4, будет направляться маршрутизатором R1 во 2-й канал.

482

8.2. Основные сетевые возможности

R1

Рис. 8.21. Схема работы маршрутизатора на базе MPR v.3.x

Таким образом, RIP-пакеты обеспечивают динамическое изменение мар­ шрутов передачи пакетов, вызванное изменением состояния сети (подключе­ ние или отключе1ше маршрутизаторов, аварийное состояние канала передачи и т. д.). Недостатком маршрутизации на базе RIP-пакетов является широкове­ щательный характер этих пакетов.

Рассмотрим принципы работы маршрутизатора на базе MPR v.3.x (рис. 8.21). Здесь используется протокол NLSP (Network Link Services Protocol). В начале своей работы марпфутизатор вьшолняет опрос узлов сети и автоматически строит каргу сети на уровне маршрутизаторов и файловых серверов сети. Можно вручную задать цену каждой связи. На основе этой карты маршрутизатор фор­ мирует оптимальную таблицу маршрутизации.

Предположим, что от WS1 на R1 поступает пакет IPX, направляемый на файловый сервер FS4. Маршрутизатор извлекает из заголовка пакета номер сети станции-получателя, вьшолняет поиск строки в таблице маршрутизации (для нашего примера D, 2) и направляет пакет в соответствующий канал (в данном случае 2).

После поступления NLSP-пакета маршрутизатор вьшолняет обновление карты сети и таблицы маршрутизации. Карта сети строится и хранится каж­ дым маршрутизатором, что делает ненужным постоянный пшроковещательный обмен маршрутной информацией до тех пор, пока не будет изменена кон­ фигурация сети. По утверждению специалистов Novell этот более эффективный метод информационного обмена между маршрутизаторами может обеспечить снижение сетевого трафика до 40 %.

483

8.Архитектура сетевых ОС NetWare

8.3.Расширяемость и открытость

Системные сетевые NLM-приложения

Выше отмечалось, что в качестве NLM-модулей выступают драйверы же­ стких дисков (*.DSK, для версии 5.x - *.НАМ и *.CDM), драйверы сетевых адаптеров (*.LAN), модули поддержки пространства имен (*.NAM), програм­ мы с расширением *.NLM. Все модули с расширением NLM можно условно разделить на несколько групп:

системные библиотеки NLM (STREAMS.NLM, CLIB.NLM, TLI.NLM, SPXS.NLM, IPXS.NLM и т. д.),

системные утилиты файлового сервера (табл. 8.8),

модули, расширяющие возможности NetWare: модули шлюза электронной почты MHS, модули маршругизатора MPR, модули коммуникащюнных серве­ ров NACS и NetWare Comiect, модули серверов БД, модули объединения сер­ веров в кластеры, модули для связи с другими ОС и т. д.

В табл. 8.8 перечислеш>1 основные системные утилиты файлового сервера, поставляемые с дистрибуцией NetWare, хранящиеся в каталоге SYS: SYSTEM и загружаемые по команде LOAD.

Некоторые NLM-модули, обеспечивающие работу шлюза MHS, маршрути­ затора MPR для файлового сервера, кластера серверов, входят в стандартную поставку NetWare 4.x. Существует большое число других NLM-модулей, рас­ ширяющих возможности NetWare. Их можно приобрести за дополнительную плату. Количество таких программ постоянно растет.

Поддержка рабочих станций разных платформ

NetWare поддерживает связь с PC, на которых установлены ОС MS DOS, Windows 95/98/NT, Macintosh, OS/2, UNIX (рис. 8.22). Ha каждой PC должно быть установлено свое ПО клиента. Структура этого ПО рассмотрена ниже.

NetWare поддерживает форматы, отличные от DOS. Файлы ОС Windows 95/98/NT (OS/2), Macintosh, UNIX, которые загружаются на PC, имеют другие наборы атрибутов, длины имен файлов и т. д. Чтобы поддержать работу таких

UNIX

Windows NT

Workstation

Рис. 8.22. Рабочие станции, поддерживаемые NetWare

484

станций, на файловом сервере должны быть загружены различные простран­ ства имен. Пространство имен представляет собой дополнительную запись таблицы DET (рис. 8.23). Таким образом, на томе с активными пространства­ ми имен Macintosh, UNIX, Windows 95/98/NT (OS/2) будут храниться четыре

485

8. Архитектура сетевых ОС NetWare

DET

Основная запись для DOS (файл А)

7

Второй поток данных для Macintosh (ветвь ресурса)

Рис. 8.23. Организация пространств имен файлового сервера

записи для каждого файла: основная запись каталога и записи каталогов для Macintosh, UNIX, endows 95/98/NT (OS/2). Все записи ссылаются на одну и ту же цепочку элементов FAT (поток данных), т. е. физически файл записыва­ ется на диск один раз. На Macintosh файлы хранятся с использованием двух потоков данных (ветвей). Одна ветвь содержит информацию о ресурсе Macin­ tosh для этого файла (ветвь ресурсов), а другая ~ фактические данные.

Каждое пространство имен поддерживается своим NLM-модулем с рас­ ширением NAM: MAC.NAM - для Macintosh, LONG.NAM - для Windows 95/98/NT и OS/2 и NFS.NAM - для UNIX. Чтобы добавить необходимые записи в таблицы DET и FAT тома, с консоли файлового сервера необходимо для каждого пространства имен выполнить один раз команду

ADD NAME SPACE имя ТО том

Здесь «имя» - это или MAC, или LONG, или NFS. Для дальнейшей работы достаточно загружать только соответствующие NLM-модули поддержки про­ странства имен.

Многопротокольный интерфейс GDI рабочей станции

На рис. 8.24 представлена структура программного обеспечения клиента NetWare, устанавливаемого на PC. Запросчик (Requester) перехватывает пре­ рывания на ввод/вывод в файл. Если файл располагается на локальном диске, то запрос обрабатьгоается ОС рабочей станции. Иначе, используя примитивы API-интерфейса, запросчик организует ввод/вывод в файл, хранящийся на дис­ ке файлового сервера. В OS/2 прерывания перехватьюает сама ОС, а затем передает управление запросчику.

486

8,3. Расширяемость и открытость

Утилита или прикладная программа

Рис. 8.24. Структура ПО клиента NetWare

Стек транспортных протоколов поддерживает API-интерфейс доступа запросчика (или прикладной программы) к службам NetWare. На PC могут вьшолняться несколько транспортных протоколов одновременно: SPX/IPX, TCP/

ЩAppleTalk. Как правило, для каждого протокола требуется свой запросчик,

т.е. свой API-интерфейс. Обычно протокол ЗРХЛРХ используют клиенты MS DOS, OS/2, Windows 95/98/NT, протокол AppleTalk - клиенты Macintosh. Про­ токол TCP/IP устанавливается в стек клиента NetWare для обеспечения рабо­ ты клиента по этому протоколу и для связи с ОС UNIX.

Программа уровня поддержки связи (LSL - Link Support Layer) принимает пакет от драйвера сетевого адаптера, распознает протокол, который был ис­ пользован при формировании пакета, выбирает соответствующий протокол из стека и передает ему управление. Модули драйвера и уровня поддержки связи со стеком протоколов образуют так назьгоаемый интерфейс ODI (Open DataLink Interface). Важно отметить, что стек транспортных протоколов PC явля­ ется открытым: если новый протокол разрабатывался с использованием спе­ цификаций ODI-интерфейса, то он может быгь включен в стек.

В табл. 8.9 перечислены компоненты ПО 16-разрядного клиента MS DOS.

487

8. Архитектура сетевглх ОС NetWare

Таблица 8.9. Компоненты программного обеспечения клиента MS DOS

Многопротокольный интерфейс STREAMS файлового сервера

На рис. 8.25 представлена структура многопротокольного интерфейса STREAMS, используемого на файловом сервере. Его применяют для обеспе­ чения взаимодействия с сервером по протоколам, отличным от NCP на базе IPX. Поддержка многопротокольного интерфейса STREAMS - это множество программных средств, содержащих ресурсы ядра и NLM-библиотеки STREAMS.NLM, CLffi.NLM, TLI.NLM, SPXS.NLM, IPXS.NLM. Это средство используют, чтобы создать дуплексный процесс пересылки данных между драй­ верами и программами сервера.

Драйверы сетевых адаптеров - это NLM-модули, обеспечивающие прием кадров и вьщеление из них пакетов. Файловый сервер может поддерживать одновременную работу 16 драйверов.

Уровень поддержки связи (LSL -• Link Support Layer) принимает пакет от драйвера, распознает тип пакета и выбирает соответствующий протокол из стека

Операционная система

Сервесный стек протоколов сессионного уровня

Интерфейс с уровнем транспортных протоколов

Стек коммуникационных (транспортных) протоколов

Интерфейс с уровнем поддержки связи LSL

Уровень

поддержки

связи

Драйверы

сетевых

адаптеров

Рис, 8.25. Структура многопротокольного интерфейса STREAMS на файловом сервере

488

8.3. Расширяемость и открытость

коммуникационных протоколов. NetWare поддерживает одновременную рабо­ ту до 32 протоколов. Модули драйверов и уровня поддержки связи LSL образу­ ют ODI-интерфейс, позволяющий включать в стек новые транспортные прото­ колы. При необходимости пакеты обрабатьшаются протоколами сессионного уровня NCP (пакеты IPX), АРР (пакеты AppleTalk от клиентов Macintosh), NFS (пакеты TCP/IP от клиентов UNIX), SMB (пакеты IPX от клиентов OS/2).

Взаимодействие NetWare с другими сетевыми ОС

Рассмотрим принципы организации взаимодействия NetWare с ОС Windows NT и UNIX, которые являются ее основными конкурентами. Еще в 1994 г фир­ ма Microsoft объявила о вьшуске ряда продуктов, которые облегчают взаимо­ действие серверов Windows NT и NetWare в сети или обеспечивают переход с NetWare на серверы Windows NT. Эти продукты перечислены в табл. 8.10.

Таблица 8.10. Продукты Microsoft, обеспечивающие взаимодействие

серверов Windows NT и NetWare

489