На заметку системному администратору: настройка файл-сервера Windows Server 2003

Сергей Пахомов

Зависимость производительности локальной сети от операционной системы клиентов

ОС Windows XP SP2

ОС Windows 2000 SP4

ОС Windows XP SP1

Настройка файл-сервера под управлением ОС Windows Server 2003

От теории к практике

Заключение

Современная локальная сеть немыслима без файл-сервера. В небольших и средних локальных сетях в качестве файл-сервера не обязательно использовать специализированные системы хранения данных, которые становятся все более популярными в последнее время, — с этой задачей успешно справится сервер среднего или даже начального уровня. В данной статье мы расскажем о том, как настроить файл-сервер под управлением операционной системы Windows Server 2003, чтобы обеспечить максимальную производительность локальной сети.

Зависимость производительности локальной сети от операционной системы клиентов

роизводительность локальной сети при доступе к файл-серверу в большой степени обусловлена аппаратной конфигурацией сервера. Однако конфигурация клиентов локальной сети тоже играет в данном случае не последнюю роль. Сетевой трафик, возникающий между файл-сервером и клиентом, зависит не только от аппаратной конфигурации ПК клиента, но и от его настроек и, что самое главное, от операционной системы, установленной на ПК. Дело в том, что не все операционные системы одинаково хорошо приспособлены для работы в локальной сети. Чтобы убедиться в этом не на словах, а на деле, мы провели ряд тестов с различными операционными системами и настройками на клиентах. В качестве файл-сервера использовался двухпроцессорный сервер Desten Navigator 7360DX компании Desten Computers (табл. 1) с операционной системой Windows Server 2003 и настройками по умолчанию.

Таблица 1. Конфигурация сервера Desten Navigator 7360DX

Конфигурация ПК клиента локальной сети использовалась достаточно мощная, чтобы минимизировать влияние именно аппаратной конфигурации на результаты теста. Так, ПК был оснащен процессором Intel Pentium 4 3,0 ГГц, 512 Мбайт DDR400 оперативной памяти, функционирующей в двухканальном режиме, а системная плата основывалась на наборе микросхем Intel 865GE.

Сетевой адаптер клиента функционировал в режиме 100 Мбит/с, а сетевой адаптер сервера — 1000 Мбит/с. Клиент подключался к порту коммутатора 10/100Base-TX, а сервер — по гигабитному интерфейсу к порту коммутатора 10/100/1000Base-T.

Для генерации трафика, возникающего при доступе к файл-серверу, применялся тестовый пакет NetBench 7.03, а на клиенте, подключенном к серверу, поочередно устанавливались операционные системы Windows XP SP2, Windows 2000 SP4 и Windows XP SP1.

ОС Windows XP SP2

ри использовании ОС Windows XP SP2 сетевой трафик, возникающий между сервером и клиентом с настройками по умолчанию, составлял порядка 20 Мбит/с, что, конечно же, далеко от идеала. Столь низкий результат оказался неожиданным для нас — наконец-то была найдена причина неудовлетворительной работы применяемой в нашей организации локальной сети при доступе к файл-серверу, которую уже давно пытался выяснить системный администратор. Поэтому первое, что мы попытались сделать,  — это задать такие настройки операционной системы Windows XP SP2, которые бы позволили исправить данную ситуацию. Тюнинг ОС заключался в настройке реестра, параметры которой приведены в табл. 2.

Таблица 2. Настройки реестра при тюнинге ОС

Первый параметр, который был подвергнут корректировке, давшей положительный результат (то есть сетевой трафик увеличился), — это размер TCP-окна (ключ TcpWindowSize). Размер окна приема определяет количество байтов, которые отправитель может передавать без получения уведомления. Как правило, больший размер получаемого пакета повышает производительность при передаче в сетях с высокой загрузкой. Для увеличения эффективности размер окна приема должен быть кратным максимальному размеру сегмента (MSS) TCP, то есть 1460 байт для сетей Ethernet.

Экспериментируя с различными значениями, мы в итоге нашли оптимальный размер окна — 17 520 байт, в двенадцать раз превосходящий размер MSS. По умолчанию размер TCP-окна для сети Ethernet составляет 8760 байт.

Следующий скорректированный ключ — DisableByteRangeLockingOnReadOnlyFiles (этот ключ, как, впрочем, и все остальные, о которых пойдет речь в данной статье, прежде необходимо создать). Некоторые сетевые приложения могут блокировать файлы с атрибутом Read Only при необходимости их синхронизации между клиентами. Установка значения данного ключа, равного 1, позволяет избежать этого.

Ключ DormantFileLimit, который также не создается по умолчанию, задает максимальное количество файлов, остающихся открытыми на разделяемом сетевом ресурсе после того, как приложение закрыло их. При тюнинге операционной системы мы установили значение данного ключа равным 100.

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

После проведения описанного тюнинга реестра сетевой трафик значительно (более чем вдвое) увеличился и составил уже 48 Мбит/с. Однако даже такое значение сетевого трафика оставляет желать лучшего.

ОС Windows 2000 SP4

ри использовании операционной системы Windows 2000 SP4 на компьютере клиента с настройками реестра по умолчанию сетевой трафик между клиентом и файл-сервером составляет 40 Мбит/с. Этот результат, конечно, вдвое выше, чем при применении ОС Windows XP SP2, однако для эффективной работы локальной сети такого сетевого трафика может оказаться недостаточно. Поэтому, как и в предыдущем случае, используя тот же самый сценарий, мы выполнили тюнинг реестра.

Хотелось бы отметить, что в соответствии с документацией, которую нам удалось найти на официальном сайте компании Microsoft, часть ключей реестра применяется только для ОС Windows XP, однако их использованию в ОС Windows 2000 SP4 ничто не мешает, более того, подобный тюнинг, как выяснилось, приводит к неплохому увеличению сетевого трафика. Так, после внесения перечисленных изменений в реестр сетевой трафик между клиентом и файл-сервером увеличился до 63 Мбит/с, то есть прирост составил 53,5%. Конечно, трафик в 63 Мбит/с позволяет говорить уже о высокой производительности сети, и, казалось бы, желаемый результат достигнут, но, как выяснилось, можно получить и более высокий результат.

ОС Windows XP SP1

амый неожиданный результат был получен при установке на ПК клиента операционной системы Windows XP SP1 сетевой трафик между клиентом и файл-сервером сразу составил 72 Мбит/с. Напомним, что при использовании ОС Windows XP SP2 без внесения изменений в реестр сетевой трафик был равен всего 20 Мбит/с, то есть разница составила 3,7 раза. Есть над чем задуматься… Вряд ли полученные результаты нуждаются в дополнительных комментариях, поскольку вывод напрашивается сам собой: если ваша сеть тормозит, откажитесь от использования SP2 для OC Windows XP. Таким образом, операционная система Windows XP SP1 прекрасно подходит для работы в локальной сети, обеспечивая высокую производительность, а операционную систему Windows XP SP2 в локальных сетях лучше не применять.

Интересно также отметить, что тюнинг реестра ОС Windows XP SP1 по описанной выше схеме не приводит к дополнительному увеличению сетевого трафика, то есть настройки реестра по умолчанию являются в каком-то смысле оптимальными для локальной сети.

Настройка файл-сервера под управлением ОС Windows Server 2003

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

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

Во-вторых, что касается объема необходимой для файл-сервера оперативной RAM-памяти, то здесь действует простое правило: памяти мало не бывает. При недостатке оперативной памяти операционная система создает на жестком диске своп-файл, эмулирующий оперативную память. Однако при использовании своп-файла производительность сервера резко падает, поэтому желательно установить такое количество оперативной памяти, чтобы обойтись без своп-файла.

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

Зависимость сетевого трафика от операционной системы клиента

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

Дисковая подсистема типичного файл-сервера представляет набор SCSI-дисков, которые объединены в RAID-массив, обеспечивающий требуемый уровень отказоустойчивости и производительности. Максимальную производительность и отказоустойчивость обеспечивает RAID-массив уровня 0+1, однако отказоустойчивость в данном случае достигается за счет двукратной избыточности, поэтому в плане стоимости данное решение не слишком привлекательно. Наиболее часто в локальных сетях среднего уровня применяется RAID-массив уровня 5, для создания которого требуются как минимум три диска. Если же в сервере используется RAID-массив уровня 0+1, то для повышения производительности можно попробовать изменить размер страйп-блока.

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

Таблица 3. Настройки реестра при тюнинге файл-сервера

Первые четыре ключа (TcpWindowSize, Tcp1323Opts, NumTcbTablePartitions, MaxUserPort) позволяют настраивать производительность сетевой подсистемы сервера, а остальные (PagedPoolSize, LargeSystemCache, AdditionalDelayedWorkerThreads, NtfsDisableLastAccess, NtfsDisable8dot3NameCreation) влияют на производительность дисковой подсистемы.

Ключ TcpWindowSize, который рассматривался выше, позволяет задать максимальный размер TCP-окна. Для файл-сервера, оснащенного гигабитным сетевым интерфейсом, желателен как можно больший размер окна (вплоть до 1 Гбайт). Однако для того, чтобы иметь возможность задать размер TCP-окна более 64 Кбайт, необходимо добавить в этот же раздел реестра ключ Tcp1323Opts, значение которого устанавливается равным 1. В этом случае можно задать размеры TCP-окна более 64 Кбайт.

При тюнинге реестра на сервере мы использовали значение TCP-окна кратное максимальному размеру сегмента (MSS) TCP, то есть 1460 байт, и равное 1 048 280 байт.

Ключ NumTcbTablePartitions задает количество TCB-блоков (Transmission Control Block), создаваемых для каждого TCP-соединения. По умолчанию количество создаваемых TCB-блоков определяется как квадрат количества процессоров в системе. Допустимые значения этого ключа — степени числа 2, то есть 2, 4, 8, 16, 32 и 64. Рекомендуем поэкспериментировать с этим параметром — в нашем случае методом проб и ошибок было найдено оптимальное значение этого ключа равное 32. Отметим, что данный ключ оказывает существенное влияние на сетевой трафик, когда к файл-серверу одновременно подключается большое количество активных клиентов.

Ключ MaxUserPort задает максимальное количество портов, используемых при установлении соединения. По умолчанию на каждый IP-адрес выделяется 5 тыс. портов, однако иногда бывает целесообразно увеличить их количество до максимума — 65 534 (0хfffe).

В руководствах Microsoft по настройке файл-сервера под управлением ОС Windows 2003 Server приводятся и другие ключи реестра (например, MaxHashTableSize или TcpAckFrequency), влияющие на производительность сетевой подсистемы сервера.

Ключ MaxHashTableSize, расположенный в разделе реестра HKLM\ System\CurrentControlSet\Services\ Tcpip\Parameters\, определяет размер хэш-таблицы, в которой сохраняется состояние TCP-соединения. По умолчанию значение данного ключа определяется как квадрат количества процессоров, умноженный на 128. Если ожидается одновременно большое количество TCP-соединений с сервером, то рекомендуется увеличить значение данного ключа вплоть до максимального — 65 536. Однако наши эксперименты показали, что любое значение этого ключа приводит только к негативным последствиям. Поэтому данный ключ лучше вообще не создавать (по умолчанию он не создается).

Ключ TcpAckFrequency, находящийся в разделе реестра HKLM\System\ CurrentControlSet\Services\Tcpip\Parameters\Interfaces\код_адаптера\, задает частоту следования пакетов подтверждения о принятии данных. По умолчанию значение данного ключа равно 2, но для повышения производительности сети его можно увеличить. Если сервер оснащен гигабитным интерфейсом, то значение данного ключа рекомендуется установить равным 13. Но, как и в предыдущем случае, создание этого ключа в реестре с любым значением только ухудшает ситуацию.

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

Ключ SystemPages определяет количество страниц памяти, которые резервируются для отображения буферов ввода-вывода и другой информации на адресное пространство. Установка данного ключа равным 0 (значение по умолчанию) позволяет системе самостоятельно определять оптимальное значение количества страниц, основываясь на объеме доступной оперативной памяти и аппаратной конфигурации сервера.

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

Создаваемый системой файловый кэш и пул страниц используют одно и то же адресное пространство в памяти. Ограничение размера пула страниц позволяет организовывать больший по размеру файловый кэш, что приводит к кэшированию большего размера данных и, как следствие, к повышению производительности файлового сервера. Для ограничения размера пула страниц используется ключ PagedPoolSize. В нашем случае оптимальным оказалось значение этого ключа 192000000.

Значение ключа AdditionalDelayedWorkerThreads задает количество потоков в отложенных рабочих очередях (Delayed Work Queue). Эти потоки имеют низкий приоритет и, как следствие, высокую латентность. Увеличение значения данного ключа позволяет в некоторых случаях повысить производительность системы. По умолчанию значение этого ключа равно 0, и, как выяснилось в ходе тестирования, в нашем случае именно это значение ключа является оптимальным.

Ключ NtfsDisableLastAccessUpdate позволяет запретить файловой системе NTFS обновлять метки времени последнего доступа к каждому файлу или папке, что приводит к возрастанию производительности дисковой подсистемы. Для реализации данной функции необходимо установить значение этого ключа равным 1.

Значение ключа NtfsDisable8dot3NameCreation равное 1 запрещает файловой системе NTFS генерировать имена файлов в формате 8.3 (формат DOS) для длинных имен файлов и для имен файлов, содержащих специальные символы, не допустимые для формата 8.3. По умолчанию значение данного ключа равно 0, что заставляет файловую систему генерировать и сохранять для каждого файла два имени: имя, назначенное пользователем, и сгенерированное в формате 8.3. Отключение данной функции, то есть установка значения ключа равного 1, позволяет повысить производительность системы при файловых операциях.

Отметим, что существуют и другие ключи реестра, оказывающие влияние на производительность дисковой подсистемы сервера. Например, в руководстве Microsoft по настройке файл-сервера, описываются также ключи DontVerifyRandomDrivers, NtfsMemoryUsage и IOPageLockLimit.

Ключ DontVerifyRandomDrivers расположен в разделе реестра HKLM\ System\CurrentControlSet\Control\ SessionManager\MemoryManagement\ и по умолчанию не создан. Как показала практика, создание этого ключа в реестре приводит к негативным результатам.

Результаты тестирования сервера с настройками по умолчанию и после тюнинга реестра

Ключ NtfsMemoryUsage находится в разделе HKLM\System \CurrentControlSet\Control\FileSystem\, и его значение по умолчанию равно 1. В этом случае файловой системе NTFS отводится в памяти размер пула страниц по умолчанию. При установке значения данного ключа равным 2 системе NTFS отводится больший размер памяти, что позволяет повысить производительность системы в случае открытия и закрытия большого количества файлов. Однако результаты тестов показали, что изменение значения этого ключа приводит к падению производительности файл-сервера.

Значение ключа IOPageLockLimit, расположенного в разделе реестра HKLM\System\CurrentContr olSet\Control\ SessionManager\MemoryManagement\, определяет количество байт, которые система будет читать или писать на дисковый массив за один раз. Значения ключа задаются в шестнадцатеричной системе, а значение 0 (по умолчанию) фиксирует размер IOPageLockLimit равным 512 Кбайт (0х80 000). Максимальное теоретическое значение данного ключа определяется размером доступной памяти минус 64 Мбайт. Эксперименты со значением данного ключа показали, что его влияние на производительность дисковой подсистемы минимально и значение по умолчанию вполне подходит для файл-сервера.

От теории к практике

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

Для тестирования файл-сервера использовался стенд, состоящий из 45 компьютеров, 48-портового коммутатора 3Com SuperStack 3 Switch 4250T с двумя дополнительными гигабитными портами, компьютера-контроллера и сервера. Сервер и компьютер-контроллер подключались к коммутатору по гигабитным интерфейсам, а все остальные компьютеры  — по интерфейсу 100Base-TX. На всех ПК была установлена ОС Windows XP SP1, кроме того, конфигурации всех ПК были практически одинаковыми: процессор Intel Pentium 4 3,0 ГГц и 512 Мбайт оперативной памяти DDR400.

Как уже отмечалось, для генерации трафика, возникающего при доступе к файл-серверу, использовался тестовый пакет NetBench 7.03.

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

Заключение

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

КомпьютерПресс 1'2005