5. Коммуникационная система сервера NetWare

Коммуникационная подсистема сервера обеспечивает связь между процессами, исполняющимися на платформе сервера (ядро ОС и приложения сервера) и внешним (по отношению к серверу) миром. В подсистему также входит и внутренний мост-маршрутизатор, обеспечивающий связь сетей, подключенных к разным адаптерам сервера.
Подсистема коммуникаций является многоуровневой, ее нижними уровнями являются сетевые платы, коммуникационные порты и их драйверы. Сетевой и транспортный уровень в NetWare реализован на протокольном стеке IPX/SPX, включенном в ядро ОС. Архитектура NetWare допускает одновременное использование различных протокольных стеков, включая TCP/IP, Apple Talk и другие.

5.1 Сетевые адаптеры и драйверы

Связь сервера с локальными сетями обеспечивается с помощью сетевых адаптеров. В сервер можно установить до 4 адаптеров, возможно различных сетевых архитектур.
Для каждого адаптера необходимо загрузить соответствующий .LAN-драйвер. Часть параметров загрузки относится к связи с системной шиной — адреса портов и памяти, номер прерывания, номер слота (EISA, MCA, PCI), номер канала и устройства (PCI). Многие из этих параметров современными драйверами определяются автоматически. Другая часть параметров определяет сетевые опции, для Ethernet это:

  • тип фрейма: FRAME=ETHERNET_802.2 — тип по умолчанию для версий 3.12, 4.x; ETHERNET_802.3 — тип по умолчанию для версий 3.11 и младше, ETHERNET_II или ETHERNET_SNAP — для использования TCP/IP;
  • среда передачи (точнее, тип разъема): MEDIA=BNC — тонкий кабель, RJ-45 — витая пара, AUI — внешний трансивер (толстый, тонкий или оптоволоконный кабель), AUTO — автоматическое определение по подключению кабеля;
  • скорость (для Fast Ethernet);
  • режим полнодуплексный или полудуплексный (для соответствующих адаптеров).
Термин BOARD (логическая плата) подразумевает экземпляр загрузки драйвера конкретного адаптера в совокупности с типом фрейма. Для идентификации логической платы при неоднократной загрузке одного и того же драйвера удобно использовать параметр NAME=board, где board — символьный идентификатор (до 17 символов).
При использовании архитектуры Token Ring для каждой платы кроме собственно .LAN-драйвера необходимо загружать модуль исходной маршрутизации ROUTE.NLM.
С каждой логической платой командой BIND связывается протокол, требуемый для данной локальной сети. Формат команды:

BIND protocol TO board [parms],

где protocol — имя сетевого протокола (IPX, IP и пр.), board — имя платы или имя драйвера, parms — параметры протокола или (и) параметры драйвера, идентифицирующие логическую плату в случае ссылки по имени драйвера.
Отвязать протокол можно командой

UNBIND protocol FROM board [parms].

Конфигурация всех логических плат выводится на консоль по команде CONFIG. Отображаются драйверы, параметры конфигурации, типы фреймов, коммуникационные протоколы, имена логических плат, номера кабельных сетей, сетевые адреса плат, имя сервера и номер его внутренней сети.
Сервер изначально поддерживает только протокол IPX/SPX. При необходимости использования дополнительных протокольных стеков (например, TCP/IP) необходимо загрузить модуль поддержки протокола.
Сервер принимает приходящие пакеты в буферы, размер которых должен быть не меньше максимального размера пакета, использующегося в любой сети сервера. Необходимое количество буферов определяется числом рабочих станций сети. Если на сервере установлены сетевые адаптеры Bus-Master шин EISA, MCA или PCI, для каждого из них желательно увеличить число буферов на 5-20. При необходимости ОС создает дополнительные коммуникационные буферы, выделяя для этого память безвозвратно (до перезагрузки сервера).

Общие параметры коммуникационной системы можно задавать командами SET.
Размер буферов приема пакетов и начальное количество буферов можно изменить только в STARTUP.NCF директивами
SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE = 4202 (618-24682) (для Ethernet достаточно 1514 байт).
SET MINIMUM PACKET RECEIVE BUFFERS = 100 (10-1000
Максимальное количество буферов можно изменить директивой
SET MAXIMUM PACKET RECEIVE BUFFERS = 400 (50-2000),
скорость разрастания области буферов можно ограничить, задав время задержки на выделение нового буфера директивой
SET NEW PACKET BUFFER RECEIVE WAIT TIME = 0.1 (0.1-20 с).
Для нормальной работы максимальное количество буферов должно превышать их минимальное количество по крайней мере на 200, иначе возможно снижение производительности сети из-за потерь пакетов.

5.2 Протоколы IPX/SPX

Протоколы IPX (Internetwork Packet Exchange), транспортный протокол NetWare, отвечающий за адресацию и маршрутизацию пакетов и основанный на нем SPX (Sequenced Packet Exchange), протокол сеансового уровня с установлением соединения, являются базовыми протоколами NetWare.
Привязка протокола IPX к логической плате выполняется командой

BIND IPX TO board NET = net_num [parms]

параметр net_num — номер сети, идентифицирующий кабельную сеть в совокупности с типом фрейма.
Для ускорения пересылки больших массивов данных можно использовать протокол Packet Burst. Он основан на IPX и позволяет пересылать пачку последовательных пакетов, требуя только общего подтверждения их приема. В случае обнаружения ошибок, повторно передаются только потерявшиеся пакеты. Протокол снижает нагрузку на сеть, но требует дополнительного расхода памяти как на сервере, так и на рабочей станции.
Для контроля достоверности передачи могут применяться контрольные суммы IPX.

Некоторыми параметрами использования IPX/SPX можно управлять с помощью команд SET:
Уровень использования контрольных сумм задается командой
SET ENABLE IPX CHECKSUMS = 1 (0-2)
0 — контрольные суммы не используются;
1 — используются только для станций, которые его запрашивают;
2 — используются всегда, требуя того же от всех станций.
Поддержка передачи больших пакетов (превышающих 576 байт) через мосты и маршрутизаторы интерсети (Large Internet Packet) управляется командой
SET ALLOW LIP = ON (OFF).
Отображение статистики использования Packet Burst протоколом NCP управляется командой
SET ENABLE PACKET BURST STATISTICS SCREEN = OFF (ON).

5.3 Протоколы TCP/IP

В состав NetWare 3.12+ входит пакет модулей поддержки комплекта протоколов TCP/IP. Подсистема TCP/IP включает 4.3BSD UNIX-сокет и библиотеки Streams TLI, обеспечивающие интерфейс для использования услуг TCP-транспортировки, NFS-сервер и принтер (Line Printer Daemon) для поддержки UNIX-клиентов.
Основные виды использования TCP/IP на сервере:

  • маршрутизация IP-пакетов;
  • использование его совместно с IPX/SPX;
  • организация шлюза TCP/IP — IPX/SPX;
  • организация IP-туннеля для пакетов IPX.
  • Замена протокола IPX/SPX на TCP/IP (только для NetWare 4.1)
Подсистема TCP обязательно использует SNMP для управления маршрутизацией.
Маршрутизация IP-пакетов осуществляется сервером, имеющем несколько сетевых адаптеров с привязанным IP-протоколом. Для его функционирования необходимо TCPIP.NLM загружать с параметром FORWARD=YES.
Для совместного использования протоколов TCPIP загружается как дополнительный протокол. При этом обращения клиентов к ядру ОС (регистрация, использование дисков и т. п.) будут работать по протоколам IPX/SPX, а обращения к TCP-приложениям сервера (NFS, FTP) — по TCP/IP.
Шлюз позволяет связать сеть, использующую TCP/IP, с сетью IPX.
IP-тоннель (IP Tunnel) можно использовать для связи нескольких удаленных IPX-сетей, имеющих серверы, связанные по протоколу TCP/IP (возможен тоннель и к отдельным станциям). В этом случае IPX-пакеты одной сети, предназначенные для абонентов удаленной сети, инкапсулируются сервером в UDP-пакеты и доставляются к удаленному серверу, где извлекаются и используются по назначению. Тоннель организуется через сетевые адаптеры, к которым привязан протокол TCP/IP. К ним привязывается загружаемый протокол IPTUNNEL.
Замена протокола IPX на TCP/IP целесообразна, когда сервер работает в сети, в которой все остальные узлы используют TCP.
Подробнее применение TCP/IP в NetWare описано в следующей главе.
Подсистема TCP/IP использует ASCII-файлы базы данных сети, которые необходимо создать в каталоге SYS:ETC. Их образцы находятся в SYS:ETC\SAMPLES; файлы PROTOCOL и SERVICES обычно не требуют модификации, необязательные файлы HOSTS и NETWORKS редактируются для каждого сервера. Для ускорения доступа файлы кэшируются, для экономии памяти их размер должен сохраняться минимальным.
Файл HOSTS содержит список IP-адресов, имен и псевдонимов известных узлов IP-сети.
Файл NETWORKS содержит список имен, номеров и (необязательно) масок и псевдонимов известных сетей. Неуказанные маски вычисляются из номеров, что не во всех случаях корректно.
Файл PROTOCOL содержит список имен, номеров и псевдонимов протоколов, используемых в IP-сети.
Файл SERVICES содержит список имен сервисов, номеров их портов, имен используемых протоколов транспортного или сетевого уровня (TCP, UDP) и псевдонимов сервисов IP-сети.
При необходимости использования статической маршрутизации создается файл описания шлюзов GATEWAYS, информация из которого считывается модулем IPCONFIG.NLM и помещается в базу данных маршрутизатора.

5.4 Внутренний маршрутизатор

Внутренний маршрутизатор сервера, являющийся составной частью ОС, позволяет пересылать пакеты между кабельными сетями, имеющими даже различные архитектуры и типы фреймов, осуществляя все необходимые преобразования. Маршрутизатор осуществляет фильтрацию пакетов, используя динамически строящуюся таблицу расположения адресатов. Таблица перестраивается каждые 2 минуты, отслеживая состояние других маршрутизаторов сети. Немедленно перевести таблицу в исходное состояние можно командой RESET ROUTER.
Для функционирования маршрутизатора IPX необходимо загрузить только модули драйверов плат и связать с ними необходимые протоколы, для включения маршрутизации IP модуль TCPIP должен быть загружен с параметром FORWARD=YES.

В NetWare 4.x обработка маршрутизатором IPX широковещательных запросов, продублированных NetBIOS, управляется командой
SET IPX NETBIOS REPLICATION OPTION=2 (0-2)
0 — не дублирует;
1 — дублирует всегда;
2 — не дублирует запросы, дублированные из-за наличия нескольких паралельных маршрутов.

Маршрутизатор может использовать протокольные фильтры, настраиваемые на определенные сети или сервисы.

5.5 Соединения сервера и приложений

Для получения каких-либо услуг сервера станция устанавливает с ним соединение. Если услуги будут запрашиваться у самой ОС по протоколу NCP (что обычно и происходит при предоставлении стандартных услуг NetWare), соединение устанавливается с ядром ОС и регистрируется в таблице соединений. Размер таблицы соединений сервера ограничен лицензионным параметром программы SERVER для NetWare 2.x-3.x и определяется суммой установленных лицензий для сервера NetWare 4.x. Именно размер этой таблицы и определяет максимальное число пользователей, обслуживаемых сервером (его ядром). Если на сервере загружено NLM-приложение (принт-сервер, коммуникационный сервер, СУБД и т. д.)., то количество пользователей, обслуживаемое этим приложением (установившими соединение с приложением, а не с ядром ОС), обычно не связано с лицензионным ограничением ядра ОС.
При внезапных отключениях (перезагрузках) рабочих станций и в некоторых других случаях могут образовываться недостоверные соединения, которые тоже занимают место в таблице. Сервер контролирует состояние соединений, посылая станции, от которой не было запросов в течение заданного времени, сторожевые пакеты. Если станция не отвечает на заданное число сторожевых пакетов, сервер сбрасывает соединение.

Ожидание перед посылкой первого сторожевого пакета (по умолчанию 5 мин), между посылками (59 с) и количество пакетов (10) можно задать командами
SET DELAY BEFORE FIRST WATCHDOG PACKET = time (15.7 с — 21 мин);
SET DELAY BETWEEN WATCHDOG PACKETS = time (10 с — 10.5 мин);
SET NUMBER OF WATCHDOG PACKET = num (5-100).

Станция, на которой загружена сетевая оболочка, устанавливает соединение либо с определенным сервером, указанным в ее файле конфигурирования как PREFERRED SERVER, либо (если он не указан) с "ближайшим" сервером — первым сервером, откликнувшимся на широковещательный запрос станции.

Серверу можно запретить ответ на запрос ближайшего сервера командой
SET REPLY TO GET NEAREST SERVER=OFF (по умолчанию ON). При этом на запрос по имени он, конечно же, откликаться будет.

Соединения, установленные с ядром ОС, используют протокол NCP (NetWare Core Protocol), охватывающий три верхних уровня модели OSI. Протокол обеспечивает установление и разрыв соединений для предоставления сервисов, манипулирование файлами и каталогами, управление отображением сетевых дисков станций на каталоги сервера, сетевую печать, обеспечение безопасности (аутентификацию) и т. д. Протокол использует транспорт SPX, в некоторых случаях (например, при передаче широковещательных сообщений) для ускорения процедур может непосредственно вызывать IPX.

Максимальное число одновременных каталоговых поисков протокола NCP для одного соединения задается командой
SET MAXIMUM OUTSTANDING NCP SEARCHES = 51 (10-1000)
(обычно приложения используют только один, хотя при одновременной работе множества приложений Windows значения умолчания может оказаться недостаточно).
Для защиты от подделок пакетов NCP можно применять сигнатуру, меняющуюся от пакета к пакету. Уровень использования сигнатур определяется командой
SET NCP PACKET SIGNATURE OPTION = 1 (0-3),
доступной и из STARTUP.NCF. Во время работы его можно только увеличивать. Значения уровней:
0 — сервер никогда не подписывает пакеты;
1 — подписывает только по запросу клиента;
2 — подписывает, если клиент способен подписывать;
3 — всегда подписывает и требует подписи от клиентов (иначе не позволит регистрацию).
В NetWare 4.x введено управление проверкой структуры пакетов NCP:
выдачей сообщений о недопустимых параметрах или неверной длине пакетов управляют команды, доступные и из STARTUP.NCF
SET DISPLAY NCP BAD COMPONENT WARNINGS=OFF (ON)
SET DISPLAY NCP BAD LENGTH WARNINGS=ON (OFF)
Некорректные (по параметрам или длине) пакеты будут отбрасываться сервером, если установить значения ON в следующих командах, также доступных и из STARTUP.NCF:
SET REJECT NCP PACKETS WITH BAD COMPONENTS=OFF (ON)
SET REJECT NCP PACKETS WITH BAD LENGTHS=OFF (ON)

 

 

14 октября 1999 г. Автор Михаил Гук (Сайт автора)