ПОВЫШЕНИЕ СЕТЕВОЙ ПРОИЗВОДИТЕЛЬНОСТИ СЕРВЕРА
ПОСЛЕДНИЕ ИСПРАВЛЕНИЯ ОТ MICROSOFT И NOVELL

ПОВЫШЕНИЕ СЕТЕВОЙ ПРОИЗВОДИТЕЛЬНОСТИ СЕРВЕРА

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

1. Переход на более скоростную технологию. Особенно популярны сети Fast Ethernet. Фактически Fast Ethernet стал стандартом построения новых сетей. В силу разных причин технология ATM не нашла широкого применения в локальных сетях.

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

2. Сегментирование сети. Популярный способ повышения производительности, основанный на принципе уменьшения коллизионных доменов (в сетях Ethernet). В сервер устанавливается несколько сетевых плат, каждая из которых подключается к отдельному сегменту (напрямую или через маршрутизатор).

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

3. Использование технологии коммутации. Такой вариант активно рекламируется производителями сетевого оборудования. Он не требует ни изменения сетевой топологии, ни замены кабельной системы.

На самом деле замена концентраторов на обычные коммутаторы особого выигрыша не дает, поскольку узким местом остается канал подключения сервера к сети. Реальный эффект достигается тогда, когда пропускная способность такого канала больше (причем значительно больше), чем у канала к клиенту (см. Рисунок 1). Однако о таком варианте коммутации надо позаботиться заранее, и он не всегда дешев. Если же используются коммутаторы Fast Ethernet, то задача значительно осложняется. Канал подключения сервера здесь желательно организовать либо по Gigabit Ethernet, либо по ATM на 622 Мбит/с. Но стандарт Gigabit Ethernet еще не принят, а ATM на 622 Мбит/с, в силу его цены, вообще можно отнести в разряд большой экзотики. Да и применение ATM с обычными сетевыми ОС более чем сомнительно.

Picture_1

Рисунок 1.
Коммутатор в сети с выделенными серверами.

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

В сервер устанавливается несколько сетевых плат, которые подключаются линиями связи к одному коммутатору. На сервере должен быть задействован один из протоколов маршрутизации, работающий по алгоритму определения состояния канала связи (link state routing protocol). Известно несколько таких протоколов: NLSP в сетях IPX/SPX; OSPF в сетях TCP/IP и IS-IS в сетях OSI. Среди множества достоинств данных протоколов можно выделить возможность распределения нагрузки (load balancing или load sharing) при работе с маршрутами одинаковой стоимости (стоимостью маршрута называют показатель, характеризующий пропускную способность канала связи). Суть ее в том, что если существуют несколько одинаковых по стоимости маршрутов между двумя точками, то параллельно задействуются они все. Общая полоса пропускания будет значительно превышать полосу пропускания отдельного маршрута и, в идеальном случае, равна сумме пропускных способностей всех маршрутов.

На примере ОС NetWare (IPX/SPX) в среде Fast Ethernet (см. Рисунок 2) рассмотрим этот способ более подробно. В каждый из серверов NetWare устанавливается по несколько сетевых плат, причем они все подключены по протоколу Fast Ethernet к одному и тому же коммутатору. ПК подключаются как обычно: один ПК - одна линия Fast Ethernet. На серверах настраивается протокол маршрутизации NLSP. Общее количество линий на одно соединение сервер-коммутатор (т. е. количество сетевых плат в сервере) для NetWare не должно превышать восьми.

Picture_2

Рисунок 2.
Совместное использование коммутации и протокола NLSP. Пропускная способность сервера A доходит до 300 Мбит/с, сервера B - до 200 Мбит/с.

Передача данных с сервера осуществляется по принципу циклического распределения (load sharing cycling), т. е. пакеты передаются по порядку через разные сетевые интерфейсы сервера (на сервере B первый пакет передается через интерфейс 1, второй - через интерфейс 2, третий - опять через интерфейс 1 и т. д.). К сожалению, сервер во многих случаях не в состоянии управлять маршрутами приема данных. Может оказаться так, что ПК 1, ПК 2 и ПК 3 будут передавать данные на сервер B по интерфейсу 2, а ПК 4 - по интерфейсу 1, таким образом здесь возможен перекос по загрузке соединений коммутатор-сервер. Однако в типичной среде сервер передает значительно больше информации, чем принимает (обычное соотношение 80%-20%). Поэтому приближенно можно считать, что соединение сервер-коммутатор имеет полосу пропускания, равную суммарной пропускной способности линий связи (300 Мбит/с для сервера A и 200 Мбит/с для сервера B). Разумеется, выигрыш в производительности будет иметь место в том случае, если все системы сервера (процессор, системная шина, дисковая подсистема) справляются с возросшей нагрузкой.

Аналогичным образом вместо коммутатора Fast Ethernet можно использовать обычные коммутаторы Ethernet. Кстати, в настоящее время цены на коммутаторы низки как никогда. Например, 16-ти портовый коммутатор Fast Ethernet BayStack 350T компании Bay Networks с автоматическим выбором скорости и режима работы (10 или 100 Мбит/с, полудуплексный или полнодуплексный режим) в Москве стоит около 3500 долларов. Чтобы получить аналогичное повышение производительности с помощью ATM, необходимо выложить сумму в 10-30 раз большую.

Для настройки протокола NLSP в режиме распределения нагрузки на сервере NetWare 4.x необходимо выполнить следующие операции:

  • запустить утилиту межсетевой настройки INETCFG
  • load inetcfg.nlm
  • включить протокол маршрутизации NLSP (если он еще не включен). Делается это в INETCFG посредством выбора пункта меню Protocols->IPX и установки параметра Routing Protocol в значение "NLSP with RIP/SAP compability";
  • для настройки режима распределения нагрузки в утилите INETCFG необходимо выбрать Protocols->IPX->Expert Configuration Options и задать параметр Maximum Number of Path Splits равным количеству сетевых плат на одно соединение сервер-коммутатор (от 2 до 8);
  • выйти из INETCFG и перезапустить сервер.
  • Как было уже сказано, режим распределения нагрузки присущ и таким протоколам; как OSPF (сети TCP/IP) и IS-IS (сети OSI). Ряд производителей выпускают свои патентованные протоколы с аналогичными возможностями.

    К сожалению, далеко не все сетевые ОС имеют встроенную поддержку этих протоколов. Если NetWare поддерживает NLSP и OSPF, то Windows NT Server не поддерживает ни один из протоколов. Следует отметить, что существуют проблемы и с настройкой OSPF в NetWare на режим load balancing (в документации такая процедура не описана). Очень немногие версии Unix имеют встроенную поддержку OSPF, правда, для различных вариантов Unix независимые производители предлагают многочисленные продукты с поддержкой протоколов типа link state routing protocol. Будем надеяться, что аналогичные программы появятся и для Windows NT.

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

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

    Константин Пьянзин
    koka@osp.ru

    ПОСЛЕДНИЕ ИСПРАВЛЕНИЯ ОТ MICROSOFT И NOVELL

    Комментарий редактора. Ниже приводятся последние исправления с узлов Microsoft и Novell. Мы перепечатали только важнейшую информацию, полное же описание можно найти на соответствующих узлах компаний (www.microsoft.com и www.novell.com).

    Продукт. IntranetWare Support Pack 3.0

    Название документа. Стирание транзитивного вектора программой DSREPAIR.

    Симптомы. После установки IntranetWare Support Pack 3.0 невозможно включить новый сервер в дерево NDS.

    Диагностика. Найдите в журнальном файле DSREPAIR следующий комментарий "Schema Attribute Definition object ID: 7b00032E, RDN: Transitive Vector Illegal Operational attribute definition, being purged". Этот комментарий означает, что DS содержит недействительный указатель на определения классов схемы для данного класса раздела.

    Решение. Если в сети только серверы NetWare 4.11, то установите IPSP3.EXE на все серверы. В такой конфигурации какие-либо проблемы не возникают. В смешанной сети с серверами NetWare 4.10 и 4.11 вам придется загрузить файл DSREPFT.EXE с узла support.novell.com/home/beta. Это пока еще бета-версия, так что если данный файл не поможет, то придется обращаться в службу технической поддержки Novell.


    Продукт. Windows NT 4.0 Service Pack 3

    Название документа. Нарушение доступа в LSASS.EXE из-за неправильного размера буфера.

    Симптомы. После запуска Windows NT вы получаете сообщение об ошибке доступа Access Violation в LSASS.EXE. В результате локальная регистрация оказывается невозможной, а административные инструменты, использующие Local Security Authority (такие как Event Viewer и Server Manager), не работают.

    Причина. Сбой произошел вследствие передачи неправильного размера буфера при соединении удаленного клиента с Local Security Authority по именованному каналу.

    Решение. Для исправления этой ошибки Microsoft модифицировала LSASRV.DLL и поместила обновленную версию по адресу: microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/lsa-fix. Прежде чем воспользоваться этой заплаткой, вы должны будете установить Service Pack 3; кроме того, заплатку следует использовать, только если система испытывает эту конкретную проблему. Если данная проблема не сказывается серьезным образом на работе вашего сервера, Microsoft предлагает подождать следующего Service Pack с данной заплаткой.