Галкин В.А., Григорьев Ю.А. Телекоммуникации и сети

Подождите немного. Документ загружается.

8. АРХИТЕКТУРА СЕТЕВЫХ ОС NETWARE

Глава посвящена принципам построения и функционирования ОС NetWare.

Основные сетевые возможности излолсены в контексте

их

реализации протоколами

IPX/SPX,

NETBIOS,

NCP, ТЫ, протоколом идентификации услуг SAP, протоколами

маршрутизации RIP и

NLSP.

Здесь изложено, как реализуются расширяемость и

открытость ОС, какими средствами обеспечивается высокая производительность и

надежность. Подробно описаны механизмы защиты информации и диалоговые

интерфейсы.

8.1.

Принципы построения и функционирования

Принципы организации передачи данных в ОС NetWare

Как уже отмечалось, NetWare относится к классу ОС с выделенным серве-

ром.

Поэтому на рабочих станциях

(WS)

и файловом сервере

(FS)

используют-

ся различные ОС. Взаимосвязь этих ОС осуществляется посредством кадров,

которые передаются

по

шине, соединяющей

сташщи.

Рассмотрим процесс пе-

редачи данных или команд от рабочей станции к файловому серверу.

С точки зрения организации взаимосвязи с файловым сервером все при-

кладные программы и утилиты рабочей станции условно можно разделить на

два

класса:

«клиент-файл»

«клиент-сервер».

К первому классу

(«клиент-файл»)

относятся программы, вьшолняющие операции

(открытие,

ввод/вывод, закры-

тие) с файлами, которые хранятся на файловом сервере. В DOS и Widows при

вьшолнении операций с файлами вырабатывается прерывание 21Н, которое

перехватьгоается оболочкой (запросчиком) рабочей станции (рис. 8.1).

Если файл расположен на локальном

диске,

то оболочка переадресовывает

это прерьшание ОС PC. Если файл расположен на файловом сервере, то обо-

лочка открывает так называемое гнездо, используемое

дальнейшем для при-

ема пакетов с файлового сервера. Затем запросчик формирует пакет для пере-

дачи его на сервер. Одно из полей этого пакета содержит номер гнезда,

совпадающий с номером гнезда нити (задачи) сервера, которая буцет обраба-

тывать этот

пакет.

Далее оболочка

помощью специальной функции протокола

450

8.1.

Принципы

построения и

функционирования

N гнезда

Прикладная

программа

(*.сот,

*.ехе)

Оболочка рабочей станции

I N гнезда 1

Протокол

драйвер СА

•V

СА

1П

N гнезда | Пакет

•

Пакет

Заголовок

кадра

Шина сети

Пакет

N гнезда I

СА

Драйвер СА

Многоканальый

интерфейс

N гнезда N гнезда i

Нити NetWare

Рис.

8.1.

Схема

взаимодействия

рабочей станции и файлового

сервера

направляет пакет в сеть. При прохождении через драйвер сетевого адаптера

(СА) пакет превращается в кадр, т. е. к нему добавляется заголовок и конце-

вик кадра. Именно кадр передается по шине сети. Таким образом, оболочка

реализует прозрачный доступ прикладной

программы к

файлу,

который

хранит-

ся на сервере, т. е. программист может использовать обычные функции ввода/

вывода языка С или Ассемблера, не вникая в детали API-интерфейса PC с

файловым сервером.

При выполнении операций с файлом в программе, функционирующей под

управлением OS/2, реализуются аналогичные действия. Только здесь соответ-

ствующее прерывание сначала перехватывается ОС, которая переадресовы-

вает его оболочке.

Ко второму классу («клиент-сервер») относятся программы PC, непосред-

ственно взаимодействующие с NLM-модулями файлового сервера. Перед пе-

редачей пакета NLM-модулю прикладная программа

должна открыть гнез-

до,

используемое

дальнейшем

для

приема

пакетов,

передаваемых с файлового

сервера NLM-модулем. Далее прикладная программа формирует пакет для

передачи по сети. Одно из полей этого пакета должно содержать номер гнезда

451

Архитектура сетевых

ОС

NetWare

НИТИ,

с которой связан соответствующий NLM-модуль. Затем прикладная про-

грамма PC направляет пакет в сеть с помощью специальной функции протоко-

ла. При прохождении через драйвер СА пакет превращается в кадр. Таким

образом, если программист создал свой NLM-модуль и желает осуществить к

нему доступ со стороны рабочей станции, то он должен создать и соответству-

ющую прикладную программу типа «клиент-сервер». При этом он должен знать

детали API-интерфейса.

Заголовок кадра, передаваемого по сети, содержит адрес станции получа-

теля и адрес станции отправителя. Если адрес станции получателя совпадает с

адресом, на который настроен сетевой адаптер файлового сервера, то кадр

принимается и обрабатывается драйвером СА сервера. При этом пакет вьще-

ляется из кадра, анализируется соответствующим протоколом и посылается

на обработку нити, открывшей гнездо, номер которого совпадает с номером

гнезда в пакете. Нить - это ьнутренняя задача NetWare или задача, связанная

с каким-либо NLM-модулем. Далее результаты обработки пересылаются при-

кладной программе, вьшолняемой на рабочей станции, в виде одного или не-

скольких пакетов.

Структурная схема ОС

На

рис.

8.2 представлена укрупненная структурная схема ОС NetWare. Ядро

ОС NetWare загружается в ОП файлового сервера из под DOS (программа

SERVER.EXE). Программа SERVER.EXE вьшолняет следующие действия.

Читает из каталога DOS файл STARTUP.NCF и интерпретирует закоди-

рованные в нем операторы. Этот небольшой текстовый файл обьпшо содер-

жит следующие команды:

• оператор загрузки (load) NLM-модуля DOMAIN.NLM (только для вер-

сии 4.1); этот модуль читается из каталога DOS и обеспечивает защиту

оперативной памяти файлового сервера;

• оператор загрузки NLM-модуля драйвера жесткого диска, например

ISADISK.DSK; после этого становится доступной файловая система

NetWare. В NetWare 5 не поддерживаются монолитные драйверы *.DSK

периферийных устройств, драйверы должны разрабатываться в соответствии

Системная база

данных сетевых

ресурсов

Права доступа

к файлам

и каталогам

Конфигурационные

файлы

Ядро ОС NetWare

(server.exe)

NLM-модули

SET-параметры,

используемые

по умолчанию

Рис. 8.2. Структурная схема ОС NetWare

452

8.L

Принципы

построения и

функционирования

архитектурой периферийного оборудования NetWare (NWPA), согласно

которой адаптеры (контроллеры) имеют свои модули (*.НАМ), а устрой-

ства - свои (*.CDM);

• некоторые SET-команды, например указание максимального уровня

вложенности каталогов файловой системы NetWare.

Монтирует том SYS файлового сервера и открьюает каталог SYSTEM на

этом томе.

Читает из каталога SYSTEM конфигурационный файл AUTOEXEC.NCF

и интерпретирует закодированные в нем операторы. Этот небольшой тексто-

вый

файл обычно содержит следующие группы команд:

• некоторые SET-команды, например обеспечивающие переход на лет-

нее и зимнее время;

• SET-команды, определяющие Bindery-контексты в дереве NDS (толь-

ко для версий 4.x и 5.x);

• операторы, указывающие имя файлового сервера и внутренний номер

сети;

• операторы загрузки драйверов сетевых адаптеров (например, NE2000.

LAN) и их связи с протоколом IPX и IP;

• операторы загрузки некоторых дополнительных NLM-модулей.

Далее устанавливаются значения SET-параметров, принятые

по

умолчанию.

Изменяя SET-параметры, можно оптимизировать работу ОС. Эти параметры

следует изменять с помощью SET-команд, которые можно включать в конфи-

гуращюнные файлы STARTUP.NCF

AUTOEXEC.NCF или вводить с консоли

файлового сервера.

В процессе функщюнирования ядро вьшолняет также роль диспетчера ни-

тей (задач) ОС. Каждая нить или связана с каким-либо NLM-модулем, или

представляет внутреннюю задачу ОС. NLM-модуль - это исполняемый файл

ОС NetWare 3.x и 4.х/5.х.

Системная БД сетевых ресурсов является частью ОС и играет роль надеж-

ного хранилища системной информащш об объектах, их свойствах (атрибутах)

и значениях этих свойств.

ОС NetWare поддерживает описание различных типов объектов: пользова-

телей, групп, файловых серверов, очередей

печати,

серверов печати

и т.

д. Каж-

дый из этих типов объектов имеет свой набор свойств. Например, объект

«пользователь» характеризуется следующими атрибутами: пароль, балансо-

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

Значением атрибута (свойства) является та совокупность данных, которая со-

держится в полях этого атрибута. Системная БД представляет собой множе-

ство файлов, хранящихся на томе SYS файлового сервера. В NetWare 3.x и

4.Х/5.Х

эти базы организованы по-разному. В NetWare 3.x она представлена в

виде БД Bindery, а в NetWare

4.х/5.х

- в виде глобального сетевого каталога

NDS.

Система каталогов NDS стала мощным средством управления больши-

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

ОС

NetWare данные о защите файлов и каталогов отделены от системной

БД и хранятся в элементах DET томов файлового сервера.

453

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

ОС

NetWare

Функциональная схема ОС. Модули загрузки NLM

NetWare

2.x

VAP-модули

(аналоги NLM-модулей) загружаются

ОП

толь-

ко один раз вместе с ОС. Начиная с NetWare 3.x, NLM-модули могут загру-

жаться в ОП и вьпружаться из нее с консоли файлового сервера в динамичес-

ком режиме. NLM-модули - представляет собой программы, в которых

используется API-интерфейс для связи со службами NetWare. Их разрабаты-

вают, как правило, с помощью компилятора Watcom С, языков NetBasic (начи-

ная с версии 4.11) и Java (начиная с версии 5.0).

Компилятор Watcom

генерирует

код,

использующий преимущества архи-

тектуры процессоров 80386 и 80486. Он использует 32-битовые ближайшие

указатели (near pointers) и 4-байтовые целые числа. Использование 32-бито-

вых

указателей делает концепцию

моделей памяти

во

многом

ненужной.

NLM-

модули компилируются для непрерывной модели памяти с абсолютной адре-

сацией («плоской»

модели),

которой

сегментация

памяти гораздо менее

важна,

чем в других. Одного 32-битового указателя достаточно для адресации всей

доступной памяти. Кроме того, компилятор генерирует код, вьшолняемый в

виртуальном режиме.

Все NLM-модули условно можно разделить на две группы: основные (без

которых

не

может функционировать

NetWare)

и дополнительные. Как

видно

из

рис. 8.3 в

качестве NLM-модулей выступают программы

расширениями *.DSK

NLM-модули

Основные

NLM-модули

Драйверы

жестких

дисков

(*.dsk)

Драйверы

сетевых

адаптеров

(*.1ап)

•

Библиотеки

NLM(*.iilm)

Модули поддержки

пространства имен для

рабочих станций с OS/2,

Macintosh, Unix и

т.

д.

(•.nam)

Дополнительные

NLM-модули

(*.nlm)

Утилиты файлового

сервера (pserver.nlm,

install.nlm, monitor.nlm,

гето!е.п1тит.д.)

Модули шлюза

электронной почты

MHS

•

Модули

маршрутизатора MRP

Модули

коммуникационных

серверов NACS,

NetWare Connect и

д.

• Модули

для

связи

с другими

ОС:

Unix,

Windows NT

•

Модули приложений

(серверы ьД, печати и

т.

д.)

Рис. 8.3.

Функциональная

схема

ОС

NetWare

454

8.1.

Принципы

построения и

функционирования

(для версии 5.0 - *.НАМ и *.CDM), *.LAN, *.NAM, *.ЖМ При загрузке NLM-

модулей в ОП автоматически создается нить (задача), связанная с этим моду-

лем. Нить может динамически порождать другие нити. Нити вьшолняются на

сервере независимо друг от друга. Синхронизация между ними осуществляет-

ся с помощью семафоров.

Диспетчеризация процессов (нитей)

Операционная система NetWare включает в себя следующие очереди (рис.

8.4), в которых находятся различные нити, ожидая освобождения центрального

процессора (ЦП): WorkToDoList (только для версии 4.x); RmiList; Delayed

WorkToDo; LowPriority.

Очереди перечислены в порядке убывания приоритетов обслуживания ни-

тей.

Внутри каждой очереди нити диспетчируются в соответствии

дисципли-

ной

FIFO:

«первый пришел, первый обслужен». Уже отмечалось, что нить -это

или внутренняя задача ОС, или задача, связанная с NLM-модулем. ОС иденти-

фицирует и отслеживает каждую нить по ее блоку управления процессом РСВ

(Process Control Block).

Обычно в NetWare нить сама себя переводит

неактивное состояние (свтает

в очередь). Это происходит в одном из следующих случаев (см. рис. 8.4).

SheduleWorkToDo

(новая нить диспетчируется)

WorkToDoList

(только для 4.x)

WaitOnLocalSemaphore,

SuspendThread

(нить не диспетчируется)

ThreadSwitch

( нить диспетчируется)

BeginThread

(новая нить диспетчируется)

RunList

ThreadSwitch WithDelay,

Delay

( нить не диспетчируется)

DelayedWorkToDo

ThreadSwitchLowPriority

(нить деспетчируется)

LowPriority

Диспетчер

NetWare

Рис. 8.4. Очереди

процессору

455

Архитектура

сетевых ОС

NetWare

Нить вьшолняет функцию SheduleWorkToDo (для версии 4.x). Создается

новая нить, которая заимствуется из ядра NetWare и помещается в очередь

WorkToDoList, имеющую выспшй приоритет для планирования на центральном

процессоре (ЦП). Старая нить помещается в конец очереди RunList.

Нить приостанавливается, устанавливая семафор (функция WaitOn

LocalSemaphore) или ожидая активизации со стороны другой нити (функция

SuspendThread). В этом случае нить помещается в конец очереди RunList, но

не диспетчируется (не планируется) до наступления требуемого события.

Иктъ

вьшолняет функцию ThreadSwitch, чтобы переключить контекст

(т.

е.

чтобы активизировать друг>то нить из очереди). В этом случае нить помеща-

ется в конец очереди RunList и диспетчрфуется, когда до нее

ДОХОДРГГ

очередь.

Нить выполняет функцию BeginThread. Создается новая нить, которая

помещается в конец очереди RunList. Старая нить продолжает выполняться.

Нить вьшолняет функцию ThreadSwitchWithDelay. Нить помещается в

конец очереди DelayedWorkToDo и приостанавливается на 50 переключений

контекста (1штей), после чего она помещается в конец очереди RunList. Число

переключений контекста (50) можно изменить с помощью функции SetThread

Handicap (при этом говорят, что устанавливается постоянный гандикап). Час-

то функцию ThreadSwitch WithDelay используют для того, чтобы активизиро-

вать задачи из очереди LowPriority, так как нити из этой очереди выполняются

только в том случае, если пуста очередь RunList. Аналогичные действия вы-

полняются, если встречается функция Delay (задержать нить на определенный

интервал времени).

6. Нить выполняет функцию ThreadSwitchLowPriority. В этом случае она

помещается в очередь LowPriorit>^, имеющую самый низкий приоритет. Нити в

этой очереди вьшолняются только в том случае, если пуста очередь RunList и

нет

нитей,

для которых установлен постоянный приоритет. Типичные низкопри-

оритетные нити - это создание резервной копии или упаковка файла.

Распределение и защита основной памяти

На

рис.

8.5 представлена структура оперативной памяти файлового сервера

NetWare 3.x. Структура ОП для NetWare 4.x отличается тем, что области па-

мяти Permanent Memory Pool и Alloc Short Term Memory Pool объединены в

один пул Allocated Memory Pool.

В системной области располагается ОС DOS, модуль SERVER.EXE, про-

граммы BIOS. В пулах памяти хранятся буферы приема пакетов, таблица со-

единений, таблица открытых файлов, блоки, динамически выделяемые NLM-

модулям, и

т.

д. Всю оставшуюся память занимает кэш-буфер (Cache Buffers),

в котором выделяется кэш неперемещаемой памяти (Cache Non-Movable

Memory) и кэш перемещаемой памяти (Cache Movable Memory). В кэше пере-

мещаемой памяти в основном хранятся кэш-таблицы, которые могут быть пе-

ремещены ОС в другое место ОП в случае возникновения фрагментации

456

8.1.

Принципы

построения и

функционирования

Системная

область

DOS

SERVER.EXE ROM BIOS

Permanent Memory Pool

(буферы корневого каталога, буфера приема пакетов)

Alloc Short Term Memory Pool

(таблица соединений, таблица открытых файлов и

т.

д.)

CACHE BUFFERS

Cache Movable Memory

(кеш-таблицы)

Cache Non-Movable Memory

(динамически

загружаемые NLM-модули)

Рис.

8.5.

Структура СП файлового сервера

NetWare

3.x

памяти. Кэш неперемещаемой памяти расширяется, если в ОП загружается

NLM-модуль. NLM-модули не являются перемещаемыми. После выгрузки

NLM-модуля из ОП освободившаяся память вновь возвращается в кэш-буфер.

В NetWare 3.x защита ОП не предусмотрена: любой NLM-модуль имеет

доступ к любой области ОП. Поэтому в NetWare 3.x нельзя отлаживать новые

NLM-модули на работающей системе, так как ошибка в программе может

привести к «зависанию» всей системы.

NetWare 4.1 предусматривает кольцевую и доменную защиту ОП на основе

сегментащ1и и страничной организащш процессоров Intel 80386/80486. В вер-

сии NetWare 4.11 домены не используются, здесь введена процедура восста-

новления системы после аварийных остановок сервера (ABEND). В версии

NetWare 5.x используется доменная защита, но число доменов не ограничено.

Рассмотрим, как процессор выполняет обращение к ОП из программы фай-

лового сервера NetWare 4.1 (рис. 8.6). Адрес ОП состоит из селектора и сме-

щения. 13-битовый индекс селектора определяет дескриптор в таблице стра-

ниц. Из этого дескриптора извлекается 32-битовый требуемой страницы в ОП

и к нему прибавляется 16-разрядное смещение. В результате образуется тре-

буемый физический адрес данных в ОП. Но перед формированием физическо-

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

це.

Для этого в поле RPL селектора адреса копируется

2-битовый

уровень

привилегий из селектора сегмента кода, загруженного в регистр CS. Таким

образом, поле RPL определяет уровень доступа программы к странице. Если

значение RPL не превышает значения DPL дескриптора, то программе разре-

шается доступ к странице. Описанный механизм ограничения доступа называ-

ется кольцевой защитой памяти. NetWare 4.1 поддерживает только два уров-

ня доступа:

(значения поля RPL). Уровни

и 2 эквивалентны уровню 3. В

NetWare 4.1 самый привилегированный уровень

обозначается как OS, а уро-

вень 3 - OS PROTECTED.

457

Архитектура сетевых

ОС

NetWare

Адрес ОП, используемый программой

Селектор

Индекс RPL Смещение

Копируется из селектора

сегмента кода (регистр CS)

Двухуровневая таблица

страниц ( Page Table)

Дискриптор

DPL

Адрес страницы в ОП

]

-Гп

32 32

Страница в ОП

Рис.

8.6.

Организация доступа программы к ОП

Доменная защита па\1яти в NetWare 4.1 заключается в том, что для каждо-

го уровня доступа (OS и OS_PROTECTED) определена своя двухуровневая

таблица страниц (Page Table). Работающий в кольце (домене) процесс не мо-

жет видеть адреса памяти, не отображенные явно на этот домен. Следова-

тельно, для одного домена логически не существует пространства памяти (ад-

ресов) другого домена.

Таким образом, в NetWare 4.1

ОП

можно разделить на два домена (рис. 8.7).

В домен OS загружаются ядро ОС и системные NLM-модули, а в домен

OSPROTECTED можно загружать отлаживаемый NLM-модуль. При попыт-

ке

несанкционированного доступа

к страницам

домена

отлаживаемый NLM-

модуль будет аварийно завершен. Таким образом, в NetWare 4.1 можно отла-

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

рекомендуется загружать в домен OS. Это связано с тем, что время переклю-

чения между доменами достаточно велико.

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

NetWare 4.1 поместить

конфигурационный файл команду

LOAD DOMAIN

(

Ядро ОС,

системные NLM-модули

)S^PROTECTED

Отлаживаемый NLM-модуль

Рис.

8.7.

Домены NetWare

4.1

458

8.L

Принципы

построения и

функционирования

Далее в процессе функционирования системы с консоли файлового сервера

можно вводить следующие команды:

DOMAIN = OS

- последующие NLM-модули, загружаемые по LOAD, будут принадлежать

домену OS:

DOMAIN = OS__PROTECTED

- последующие NLM-модули, загружаемые по LOAD, будут принадлежать до-

мену OS^PROTECTED.

Структура и управление внешней памятью

Рассмотрим традиционную файловую систему

ОС

NetWare.

На

рис.

8.8 пред-

ставлена логическая структура жесткого диска, установленного на файловом

сервере. Один из дисков файлового сервера должен иметь раздел DOS (NetWare

загружается из под DOS ). Как правило, все остальное пространство диска

отводится под раздел NetWare, который делится на тома. В свою очередь,

каждый том состоит из сегментов, а каждый сегмент - из блоков. В табл. 8.1

перечислены ограничения, накладываемые на структуру внешней памяти

NetWare.

Каждый том NetWare имеет таблицу записей каталога DET (Directory Entry

Table) и таблицу размещения файлов FAT (File Allocate Table).

Каждая запись DET соответствует файлу или подкаталогу корневого ката-

лога тома. Эта запись имеет сложную структуру и, в частности, включает имя

файла (или подкаталога) и указатель на элемент

FAT,

соответствующий перво-

му блоку файла (рис. 8.9). Между элементами FAT и блоками тома NetWare

Диск

Раздел

DOS

Раздел

NetWare

DET 1 1 FAT

Сегмент 1

тома SYS

Блоки

DET

FAT

Сегмент

тома DATA

Блоки

DET

FAT

Сегмент 2

тома SYS

Блоки

Том DATA

"1 Г

Том SYS

Рис.

8.8.

Логическая структура жесткого диска файлового сервера

459