АППАРАТНАЯ И ПРОГРАММНАЯ СОВМЕСТИМОСТЬ
Официально определены два уровня совместимости: Datacenter Hardware Compatibility List (HCL - список аппаратно-совместимых продуктов) для аппаратных систем и устройств и логотип Certified for Microsoft Windows 2000 Datacenter Server для программных приложений. Первый документ представляет собой список - не сертификационную программу - составленный и обновляемый Microsoft. Аппаратный продукт должен пройти испытания на аппаратную совместимость (Datacenter Hardware Compatibility Test - HCT) прежде, чем он будет внесен в перечень Datacenter HCL. Продукты, прошедшие тест HCT и внесенные в список HCL, получают логотип Designed for Windows. Иногда об аппаратном устройстве говорят, что оно "сертифицировано" для Datacenter, но в действительности это означает, что оно внесено в Datacenter HCL.
Вторая форма совместимости с Datacenter - официальная программа сертификации для получения логотипа Microsoft, выполнение которой возложено на тестовую лабораторию VeriTest. Прикладные программы, отвечающие требованиям спецификации Microsoft, получают сертификат и отмечаются логотипом Certified for Microsoft Windows 2000 Datacenter Server. Выбирая аппартные устройства, сверяйтесь со списком HCL. Программы должны иметь логотип Certified for Microsoft Windows 2000.
Чтобы понять процедуру сертификации аппаратных средств и программного обеспечения на совместимость с Datacenter, необходимо иметь представление о четырех основных элементах тестирования: Windows Hardware Quality Labs (WHQL - лаборатория качества аппаратуры), Datacenter HCT и связанном с ним списке HCL, кластерном HCT и родственном HCL, а также о программе присвоения логотипа Certified for Microsoft Windows 2000 Datacenter Server.
Windows Hardware Quality Labs. На лабораторию WHQL возложена обязанность помогать OEM-изготовителям производить и тестировать аппаратные средства и программы, максимально совместимые с Windows. WHQL (произносится "wickel") составляет тесты HCT и списки HCL для всех версий Windows.
Сотрудники лаборатории анализируют результаты тестов HCT и вносят успешно прошедшие испытания продукты в соответствующие списки HCL. WHQL существует со времени выхода Windows 95, и проведение тестов Datacenter - последнее дополнение к ее обязанностям. Более подробно о WHQL можно узнать по адресу http://www.microsoft.com/hwtest/default.asp и http://www.microsoft.com/windows2000/guide/datacenter/hcl/dchclprogram.asp.
Datacenter Hardware Compatibility Test. HCT, тестовый набор для оценки стабильности аппаратных средств, работающих с Windows, предназначен для самостоятельного выполнения. OEM выполняют тесты HCT на своей аппаратуре в собственных лабораториях. HCT (в настоящее время выпущена версия 9.x) - достаточно зрелый тест; по условиям испытаний Datacenter HCT, OEM-продукт должен безотказно работать в течение 14 дней, показывая все это время стопроцентную готовность. (По данным Microsoft, стопроцентная готовность в ходе испытаний соответствует 99,9-процентной готовности на практике.) Цель испытаний - убедиться, что аппаратные средства и любые сопутствующие программы стабильны в течение длительного времени.
Программа HCT записывает результаты теста в шифрованный файл, который OEM пересылает в WHQL после завершения теста. В лаборатории WHQL результаты расшифровываются и интерпретируются. Это делается для того, чтобы определить, насколько успешно продукт выполнил тест. В случае неудачи специалисты WHQL помогают OEM-изготовителю устранить недостатки и вносят в список HCL продукты, успешно прошедшие тестирование. Список Datacenter HCL меняется - ко времени написания данной статьи в нем числилось всего несколько систем. Продукт, внесенный в список Datacenter HCL, автоматически признается соответствующим стандарту Windows 2000 Server HCL.
Чтобы ознакомиться со списком Datacenter HCL, обратитесь по адресу http://www.microsoft.com/hcl/default.asp, выберите пункт System/Server Datacenter из ниспадающего списка In the following types, и щелкните на кнопке go. OEM-изготовители могут загрузить тест HCT из сети или заказать CD-ROM по адресу http://www.microsoft.com/hwtest/testkits.
Cluster Hardware Compatibility Test. Кластерный тест HCT предназначен специально для кластерных решений и необходим для проверки аппаратных устройств, которые будут работать в кластерной среде. Именно такие требования предъявляются к аппаратным средствам Datacenter. Лаборатория WHQL вносит в кластерный HCL продукты, прошедшие кластерный тест HCT. Фирма Microsoft предоставляет техническую поддержку лишь пользователям кластерных систем, все аппаратные средства которых внесены в кластерный список HCL.
Чтобы познакомиться с кластерным HCL, который не относится исключительно к Datacenter, обратитесь по адресу http://www.microsoft.com/hcl/default.asp, выберите раздел Cluster, и щелкните на кнопке go. Более подробно о кластерных HCT и HCL можно прочитать в статье Microsoft "Microsoft Cluster Server Hardware Compatibility List and Testing" (http://support.microsoft.com/support/kb/articles/q224/9/71.asp).
Программа Certified for Microsoft Windows 2000 Datacenter Server logo. Независимые поставщики ПО (ISV) отправляют приложения для тестирования непосредственно в лабораторию VeriTest. Приложения Datacenter, отмеченные логотипом Certified for Microsoft Windows 2000 Datacenter, должны отвечать строгим требованиям, составленным Microsoft и описанным во врезке "Прикладная спецификация Datacenter". Спецификацию можно загрузить из сети, обратившись по адресу http://msdn.microsoft.com/certification/download.asp. Более подробно узнать о тестовой программе VeriTest можно по адресу http://www.veritest.com/mslogos/windows2000/win2k_datacenter.asp, а список сертифицированных программ опубликован по адресу http://www.veritest.com/mslogos/windows2000/certification.
Как правило, для прикладных программ ISV-компаний не требуется проводить тесты HCT. Однако приложения, связанные с драйверами устройств, работающими в режиме ядра, например, программы обнаружения вирусов и утилиты резервного копирования, должны пройти тестирование HCT, прежде чем поставщики смогут представить их для сертификации в лабораторию VeriTest.
Кроме того, приложения вновь подвергаются тестированию Datacenter HCT в лаборатории VeriTest во время аттестационных испытаний для получения логотипа. Готовность - важнейшее требование Datacenter, и поскольку некорректные драйверы режима ядра могут нарушить стабильность системы, авторы драйверов и связанных с ними приложений должны продемонстрировать, что их программы не вызовут нестабильности.
Везде, где возможно, ISV-компаниям рекомендуется использовать встроенные системные службы Microsoft. Например, если в программе необходимо контролировать сетевые пакеты, то попытайтесь не составлять собственный драйвер устройства, а использовать Windows Network Monitor API. Преимущества такого подхода значительны. По всей вероятности, работу над программой удастся завершить быстрее, так как не нужно заново составлять программный код, уже подготовленный Microsoft. Значительно уменьшится риск нарушения приложением стабильности системы. И, наконец, прикладная программа быстрее пройдет через процедуру сертификации, что позволит скорее выпустить ее в продажу.
БАЛАНСИРОВКА СЕТЕВОЙ НАГРУЗКИ
Служба Network Load Balancing (NLB - балансировка сетевой нагрузки) операционной системы Windows 2000, известная под названием Windows NT Load Balancing Service (WLBS) в NT Server 4.0 и NTS/E, в сущности, представляет собой IP-балансировщик нагрузки. NLB распределяет входящие запросы IP между несколькими узлами с NLB-программами, обеспечивая масштабируемость и готовность. Для внешнего мира узлы имеют один IP-адрес. Чтобы удовлетворить растущий пользовательский спрос на сетевые ресурсы, достаточно просто увеличить число узлов NLB-кластера.
На Рисунке 5 показан внешний NLB-интерфейс критически важного для работы предприятия сервера, такого как SQL Server или Microsoft Exchange 2000 Server, работающий на кластере. Внешний NLB-интерфейс выполняет значительную часть операций связи, которые в противном случае были бы возложены на кластер SQL Server или Exchange 2000. Помимо балансировки нагрузки повышается и готовность, поскольку NLB-кластер направляет клиентские запросы на сервер. Если один NLB-узел отказывает, то нагрузка будет незамедлительно передана на другие узлы, и пользователь не заметит перерыва в обслуживании.
Рис. 5
Базовое программное обеспечение NLB - NDIS-драйвер, расположенный между сетевым контроллером и TCP/IP. Драйвер устанавливается на каждом сервере NLB-кластера. Все NLB-узлы - или серверы - имеют общий виртуальный IP-адрес (VIP, зарегистрированный в службе DNS), который представляет требуемый сетевой ресурс. Все NLB-серверы принимают пользовательские запросы, но отвечает лишь один. Для определения сервера, откликающегося на запрос, используется метод балансировки нагрузки, основанный на алгоритме быстрого хеширования, учитывающий клиентский IP-адрес, номер порта или оба эти параметра. Указав аффинность, можно распределить трафик между серверами (то есть на одни серверы придется более интенсивный трафик, чем на другие). Благодаря периодическому обмену контрольными сообщениями, все NLB-узлы быстро оповещаются о любых изменениях в кластере, таких как отказ или добавление узла. В случае изменений, NLB начинает процедуру конвергенции, автоматически согласовывая изменения и прозрачно перераспределяя входящую нагрузку.
В отличие от кластерной службы, NLB - кластерное решение, в котором не используется информация о состоянии. Это означает, что в случае отказа состояние пользователя и приложения не сохраняется. Обычно такой кластер без сохранения информации о состоянии, как NLB, используется для распределения нагрузки между несколькими Web-серверами. Однако в NLB есть функции восстановления состояния пользователя, необходимые для некоторых типов приложений на Web-серверах, например, для электронных магазинов. Служба NLB реализована в Datacenter и Windows 2000 AS.
БОЛЕЕ ВЫСОКИЙ УРОВЕНЬ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ
Одна из основных характеристик, отличающих Datacenter от других версий серверов Windows 2000 - вовсе не диапазон функциональных возможностей. Скорее, это процедура, с помощью которой Microsoft надеется упростить техническое обслуживание потребителей Datacenter. В идеальном мире потребители могут набрать один номер и решить любую проблему, связанную с их компьютером. Им не придется гадать, к какому поставщику следует обратиться с конкретным вопросом, их не будут отсылать от одного консультанта к другому. В единственном консультационном пункте, открытом круглосуточно семь дней в неделю, их проблема будет услышана и быстро решена.
Первым шагом Microsoft к идеалу стала служба Datacenter Joint Support Queue. Поскольку потребители покупают Datacenter не напрямую у Microsoft, а через OEM-изготовителей, то за консультациями они обращаются к поставщикам решений. Как правило, в центре технической поддержки OEM-изготовителя находится один или несколько специалистов Microsoft. Специалисты центра быстро отвечают на звонки потребителей. Если они приходят к выводу, что неисправность связана с программным или аппаратным продуктом независимого поставщика, то обращаются в службу технической поддержки этого изготовителя от имени потребителя. Поставщики продуктов, сертифицированных для работы с Datacenter, должны иметь круглосуточные центры поддержки, в которые специалисты Support Queue смогут обратиться напрямую. В идеальном случае потребители ничего не знают о происходящем «за кулисами», а просто дожидаются ответного звонка от OEM, который сообщит им, как устранить неисправность.
Возможно, этот сценарий слишком хорош, чтобы воплотиться в реальность. Существуют обстоятельства, в силу которых одни потребители получают более высокий уровень услуг, чем другие. Во-первых, поддержка OEM-изготовителей факультативна; потребители должны заключить договор и заплатить за консультации. Во-вторых, разные OEM предложат различные условия; некоторые поставщики могут предложить более выгодные условия, а ряд пунктов контракта можно уточнить в процессе переговоров.
К пирамиде обслуживания потребителей, купивших Datacenter через системного интегратора, добавляется еще один уровень. В общем, ситуация понятна.
Хотелось бы отметить, что Microsoft и OEM-изготовители прилагают со своей стороны максимум усилий к улучшению технического обслуживания
Преимущества Joint Support Queue заключаются в снижении риска для компаний, использующих Datacenter, едином договоре на обслуживание программных и аппаратных проблем, использовании особых отношений Microsoft и OEM-изготовителей с независимыми поставщиками для скорейшего устранения неисправностей; наличии специального оборудования для воспроизведения и решения проблем в лабораторных условиях. Даже первые шаги к идеалу значительно улучшат нынешнее положение, а инициатива Microsoft и OEM`ов заложит основу для более качественного обслуживания в будущем.
CLUSTER SERVICE
Готовность - важнейшая характеристика операционной системы. Наряду с заметно более высокой по сравнению с NT 4.0 стабильностью, Datacenter обладает существенно более высоким уровнем готовности, чем другие серверы семейства Windows 2000.
Кластерная служба, известная в NT Server 4.0 как Microsoft Cluster Server (MSCS), предназначена в основном для повышения уровня готовности путем отработки отказов (failover) и обратной передачи управления (failback), а также для поэтапной модернизации. Обработка отказа состоит в передаче задач приложения, отказавшего на одном узле кластера, на другой узел. Обратная передача управления производится, когда исходный узел возобновляет работу после восстановления отказавшего приложения. Кластерная служба управляет обработкой отказов приложений, выполняемых в кластере, исключая любые потери данных, связанных с отказавшей программой. Поэтапная модернизация предусматривает поочередное обновление узлов кластера, чтобы не останавливать работу приложения на время модернизации.
Предположим, что необходимо обеспечить бесперебойную работу базы данных SQL Server. С помощью Datacenter можно построить состоящий из четырех узлов кластер, как показано на Рисунке 4. После установки программного обеспечения кластерной службы и пригодной для работы с кластерами версии SQL Server, конфигурацию кластера можно настроить так, что SQL Server передаст управление готовому к работе узлу. Переход должен быть выполнен быстро и автоматически, совершенно без потерь данных. Свободный узел должен принять рабочую нагрузку и данные отказавшего узла. Эта операция называется сохранением состояния. Кластерная служба выполняет кластеризацию с запоминанием состояний, поскольку в процессе передачи управления сохраняются состояния пользователя и приложения. Два дополнительных узла Datacenter обеспечивают избыточный уровень готовности, отсутствующий в кластере с двумя узлами.
Рис. 4
Дисковая подсистема
Перед тем как приступить к исследованию работы жестких дисков, нужно определить, не испытывает ли система недостатка в ресурсах памяти. Дело в том, что, когда система активно выполняет операции страничного обмена, вызванные несоразмерно малой емкостью ОЗУ, эти манипуляции легко принять за свидетельство того, что диск попросту не справляется с нагрузкой. Чтобы отличить дисковые операции, обусловленные передачей страниц на диск диспетчером Virtual Memory Manager, от операций, связанных с выполнением прикладных программ, лучше разместить соответствующие файлы подкачки на отдельных дисках.
Прежде чем браться за исследование жестких дисков с помощью утилиты Performance Monitor, нужно четко усвоить различие между двумя счетчиками, используемыми в этой программе. Счетчики LogicalDisk отражают характеристики элементов высокого уровня (например, набора томов или набора томов с чередованием). С помощью данных счетчиков можно определить, какой раздел вызывает активность диска, и даже выяснить, какое приложение или служба генерирует те или иные запросы. Счетчики PhysicalDisk отражают сведения о конкретных дисках вне зависимости от того, как эти диски используются. Иначе говоря, счетчики LogicalDisk отображают параметры операций обмена логических разделов диска, тогда как счетчики PhysicalDisk представляют ситуацию по всему жесткому диску.
По умолчанию NT не активизирует счетчики дисков, используемые утилитой Performance Monitor, так что администратор должен делать это вручную. В результате активизации производительность дисковой подсистемы снизится на 2–5%. Для активизации дисковых счетчиков Performance Monitor на локальном компьютере нужно ввести в командной строке:
diskperf -y
При исследовании дискового массива RAID нужно использовать ключ -ye. После этого компьютер следует перезагрузить.
Анализ производительности и емкости дисковой подсистемы осуществляется с помощью счетчиков дисковой подсистемы из утилиты Perfor-mance Monitor. Ниже перечислены счетчики, которые могут использоваться в обоих случаях – и для Logi-calDisk и для PhysicalDisk.
% Disk Time. Счетчик отображает, какую часть времени диск расходует на обслуживание запросов на чтение и запись. Если его значения стабильно сохраняются на уровне вблизи отметки 100%, система работает с диском весьма интенсивно. Если же идет постоянный активный обмен данными и при этом создаются большие очереди, возможно, что дисковая подсистема не справляется с нагрузкой. В типичных условиях эксплуатации значение этого счетчика не должно превышать 50.
Avg. Disk Queue Length. Показатель этого счетчика отражает среднее число ожидающих обработки запросов к диску на ввод и вывод данных. Если он стабильно выше 2, значит, в диске образовался «затор».
Avg. Disk Bytes/Transfer. Отражает пропускную способность (т. е. среднее число байтов, пересылаемых на диск или с диска в ходе операций записи или чтения). Чем выше этот показатель, тем эффективнее работает система.
Disk Bytes/sec. Скорость, с которой система пересылает байты на диск или с диска в ходе операций записи или чтения. Чем выше средний показатель, тем эффективнее функционирует система.
Current Disk Queue Length. Количество запросов к диску, ожидающих обработки. В ходе интенсивного обмена с диском очереди запросов встречаются сплошь и рядом; однако, если из запросов постоянно формируются «пробки», это значит, что диск не справляется со своими задачами.
Если есть подозрение, что производительность всей системы сдерживается неэффективной работой диска, проблему можно решить несколькими способами. Например, можно установить более производительный контроллер диска, укомплектовать массив RAID дополнительными накопителями (размещение данных на нескольких физических дисках приводит к повышению производительности, особенно при выполнении операций считывания) или нарастить память (чтобы увеличить емкость кэша для файлов). Наряду с этим можно прибегнуть к дефрагментации дисков, перейти на другую архитектуру шины ввода/вывода, разместить тома на отдельных каналах шины ввода/вывода (особенно если условия эксплуатации системы предусматривают интенсивный обмен данными с дисковой памятью) или установить новый диск с малым временем поиска (время, необходимое для перемещения головок чтения/записи дискового накопителя с одной дорожки на другую).
При работе с файловой системой FAT не забывайте, что для томов размером свыше 400 Мбайт более всего подходит система NTFS.
Кроме того, администратор может выделить для выполнения приложений большее число дисков. Способ организации данных зависит от требований безопасности. Для ускорения операций чтения и записи, а также для увеличения емкости накопителей используйте тома с чередованием. В такой конфигурации коэффициент загрузки дисков в расчете на диск сокращается, а общая пропускная способность увеличивается за счет распределения нагрузки по всем томам.
Можно попробовать привести размеры используемых в системе кластеров в соответствие с размерами блоков ввода/вывода прикладной программы; это будет способствовать повышению эффективности процесса переноса данных. Однако нужно иметь в виду, что увеличение размеров кластера не всегда ведет к повышению производительности дисковой подсистемы. Если в разделе тома содержится множество мелких файлов, возможно, правильнее будет использовать кластеры меньших размеров. Существует два способа изменить размер кластера. Во-первых, с помощью командной строки. В этом случае нужно ввести с клавиатуры следующий текст:
format <disk>: /FS: NTFS /A:<cluster size>
А во-вторых, можно использовать утилиту Disk Administrator. В окне этой программы в меню Tools нужно выбрать пункт Format и изменить размеры кластера. В системе NTFS допускается использование кластеров следующих размеров: 512 байт, 1024 байт, 2048 байт, 4096 байт, 8192 байт, 16 Кбайт, 32 Кбайт или 64 Кбайт. В системе FAT, соответственно, – 8192 байт, 16 Кбайт, 32 Кбайт, 64 Кбайт, 128 Кбайт или 256 Кбайт.
ENTERPRISE MEMORY ARCHITECTURE
Datacenter может работать с физической памятью размером до 64 Гбайт; Windows 2000 AS работает с 8-Гбайт памяти. Windows 2000, как и NT - 32-разрядная операционная система, поэтому в распоряжение процессов предоставляется плоское адресное пространство в 4 Гбайт (2^32 байт). Какие же преимущества можно извлечь из увеличения памяти Datacenter и Windows 2000 AS? В архитектуре памяти предприятия (Enterprise Memory Architecture - EMA) предусмотрено два способа работы с расширенной памятью серверов семейства Windows 2000: 4Гбайт RAM Tuning (4GT) компании Microsoft и Physical Address Extension (PAE - расширение физического адреса) компании Intel. Прикладные программы, использующие технологии EMA, масштабируются лучше приложений, авторы которых отказались от возможностей, предоставляемых этой архитектурой. От способа использования EMA приложениями зависит, удастся ли реализовать преимущества технологии без модернизации прикладных программ или придется вносить в них изменения.
4GB RAM Tuning. В соответствии с методом 4GT корпорации Microsoft (предложенным еще для NTS/E), операционная система обычно выделяет каждому процессу 4 Гбайт виртуальной памяти: 2 Гбайт приложению и 2 Гбайт системе. Поскольку все 2 Гбайт системного адресного пространства не используются процессами полностью, метод 4GT позволяет расширить виртуальную память приложения с 2 до 3 Гбайт и уменьшить виртуальную системную память с 2 до 1 Гбайт, не добавляя новых API. Благодаря методу 4GT повышается быстродействие таких программ, как Microsoft SQL Server, авторы которых задействовали преимущества дополнительной памяти.
Чтобы включить режим 4GT при запуске Datacenter, необходимо добавить ключ /3GB к пути Advanced RISC Computing (ARC) в системном файле boot.ini:
multi(0)disk(0)rdisk(0)
partition(1)\WIN2K="MicrosoftWindows 2000 Datacenter Server"
/basevideo /3GB
Чтобы использовать режим 4GT в прикладных программах, нужно установить бит IMAGE_FILE_LARGE_ADDRESS_AWARE в заголовке исполняемого файла.
Установить бит можно с помощью ключа компоновщика / LARGE ADDRESSAWARE или утилиты Imagecfg следующим образом:
imagecfg l <BigApp>.exe
Более подробная информация о 4GT содержится в статье Microsoft "Information on Application Use of 4GT RAM Tuning" (http://support.microsoft.com/support/kb/articles/q171/7/93.asp).
Метод 4GT может применяться лишь в двух продуктах семейства Windows 2000: Windows 2000 AS и Datacenter. В режиме 4GT Datacenter автоматически игнорирует ОЗУ выше 16 Гбайт, поскольку машины, использующие память выше 16 Гбайт, нуждаются в 2-Гбайт виртуального адресного пространства для хранения всех необходимых элементов таблицы страниц. Включив режим 4GT, администратор тем самым отказывается от использования памяти более 16 Гбайт, даже если она установлена в машине.
PAE. Другая технология EMA, PAE фирмы Intel - нововведение в Windows 2000, обеспечивающее доступ к 64-Гбайт памяти в среде Datacenter (8 Гбайт для Windows 2000 AS). В прошлом 32-разрядные процессоры Intel адресовали лишь 4 Гбайт памяти. Однако инженеры Intel расширили адресное пространство PAE-совместимых процессоров до 64 Гбайт (36 разрядов). Для PAE необходим процессор Pentium Pro или более поздний, системная память более 4 Гбайт и набор микросхем 450NX или выше. Выясните у своего поставщика, проверены ли аппаратные средства на совместимость с PAE.
Компания Microsoft изменила Windows 2000, предусмотрев режим PAE в ядре, поэтому можно предположить, что преимущества PAE удастся реализовать, не изменяя операционной системы и приложений. До некоторой степени эти ожидания оправдываются. Системы Windows 2000 AS и Datacenter работают с памятью выше 4 Гбайт на уровне ОС без изменения приложений - если выполнять несколько прикладных программ, каждая из которых занимает не более 4 Гбайт памяти. Данный подход к использованию PAE проиллюстрирован в левой части Рисунка 1.
Рис. 1
В этом случае каждое приложение работает без изменений в обычном 4-гигабайтном виртуальном адресном пространстве (2 Гбайт для приложений и 2 Гбайт для системы).
Datacenter играет роль объединяющей платформы, обеспечивая одновременное выполнение большего числа программ, чем любая прежняя версия Windows 2000. Кроме того, данный подход PAE существенно снижает число операций обмена страниц, так как увеличивается память, выделяемая для системного кэша. Изменять приложения не нужно, поскольку ядро Windows 2000 управляет положением 4-Гбайт адресного пространства каждой программы в физической памяти. Однако к пути ARC в файле boot.ini необходимо добавить параметр /PAE:
multi(0)disk(0)rdisk(0)
partition(1)\WIN2K="Microsoft Windows 2000 Datacenter Server"
/PAE /basevideo
Второй способ использования PAE позволяет изменить приложения, чтобы расширить их память сверх 4 Гбайт. Address Windowing Extensions (AWE - оконные расширения адреса) - небольшой набор новых API операционной системы Windows 2000, которые позволяют задействовать в программах большие области памяти. Программист выделяет "окно" памяти в 4-Гбайт виртуальном адресном пространстве процесса приложения и область физической памяти, после чего программа может обращаться к памяти через окно виртуального адресного пространства процесса. Теоретически прикладной программе может быть выделена вся память (до примерно 62 Гбайт в системе Datacenter). Проблема быстродействия не возникает, поскольку окном памяти управляют аппаратные средства процессора. Операционная система не тратит времени на отображение памяти в окно. AWE-приложения могут работать с большими структурами данных, расположенными в памяти, более крупными кэшами и базами данных - все эти возможности повышают масштабируемость и производительность Windows 2000. Данный подход проиллюстрирован в правой части Рисунка 1.
Рис. 1
в виде совокупности звеньев, или
Если представить вычислительную систему в виде совокупности звеньев, или цепочки, становится очевидно, что быстродействие всей системы определяет компонент, имеющий самую низкую производительность (иначе говоря, слабейшее звено цепи). Это слабое звено называют еще узким местом, критическим фактором, «горлышком бутылки» (bottleneck). Если пользователь чувствует, что система или прикладная программа «притормаживает», значит, одно из звеньев цепочки сдерживает остальные. Чтобы отрегулировать производительность системы, нужно, прежде всего, определить, какой именно компонент оказался не на высоте – центральный процессор, память, дисковая подсистема, сетевой интерфейс, прикладные программы или службы Windows NT. Ведь если начать укреплять участок, не влияющий отрицательно на производительность системы, все усилия окажутся напрасными.
Экран 1. Task Manager.
Оптимизировать производительность системы, а также находить ее потенциально слабые звенья можно с помощью как собственных средств NT Server, так и инструментов производства независимых компаний. В инструментарии NT Server следует выделить такие средства, как диспетчер задач Task Manager (см. Экран 1) и диспетчер производительности Performance Mo-nitor (см. Экран 2). Диспетчер Task Manager позволяет быстро выяснить, что происходит в системе. И хотя в этой программе не предусмотрен механизм протоколирования, она обеспечивает представление подробной информации о выполняющихся программах и процессах. Кроме того, Task Manager позволяет управлять процессами, которые могут оказывать неблагоприятное воздействие на систему. Утилита Performance Monitor применяется для получения более детализированной информации о производительности (в виде диаграмм, оповещений и отчетов, которые базируются как на текущем состоянии, так и на результатах протоколирования) с помощью мониторинга системных событий. В комплекте ресурсов Microsoft Windows NT Server 4.0 Resource Kit содержатся также средства диагностики (некоторые средства контроля производительности, имеющиеся в Windows NT, представлены в Таблице 1).
Экран 2. Perfomance Monitor.
Но прежде чем приступить к процессу оптимизации производительности, нужно как следует в нем разобраться. Небходимо в точности знать, какое используется серверное оборудование, как функционирует NT, какие приложения выполняются на машинах, кто работает с системой, каким нагрузкам она подвержена и как вписывается в общую инфраструктуру сети. Кроме того, требуется определить базовый уровень производительности, что позволит понять, каким образом система использует свои ресурсы, функционируя в обычном режиме при типичных нагрузках (для определения базового уровня производительности можно использовать утилиту Performance Monitor). Не имея базового статистического материала, невозможно зафиксировать изменения эксплуатационных характеристик сервера NT. Чем больше объектов будет подвержено мониторингу базовых характеристик, тем лучше. Пусть это будут, к примеру, характеристики работы памяти, процессоров, операционной системы, файла страничного обмена, логических дисков, физических дисков, сервера, кэш-памяти, сетевого интерфейса. Но в любом случае при выполнении замеров базовых характеристик сервера нужно отслеживать четыре главных ресурса – состояние памяти, процессора, дисков и сетевого интерфейса. При этом не имеет значения, какие функции выполняет данный сервер – является ли он файловым сервером, сервером печати, сервером приложений или контроллером домена. Надо сказать, что все четыре главных ресурса сервера взаимосвязаны, поэтому отыскать слабое звено системы бывает нелегко. Решая одну проблему, можно создать другую. Подбирая нужные параметры, следует вносить изменения по одному и каждый раз сравнивать полученные результаты с базовыми характеристиками; так можно будет определить, пошло ли изменение на пользу. Если вносить несколько изменений сразу и сопоставлять результаты с исходными показателями, нельзя точно сказать, какие из действий повысили производительность системы, а какие нет. Всегда тестируйте новую конфигурацию несколько раз.Важно быть уверенным, что внесенные изменения не ухудшают характеристики сервера. Кроме того, следует всегда тщательно документировать как свои действия, так и результаты.
Память
Замедление работы системы NT Server нередко объясняется нехваткой памяти. Причем иногда кажется, что подлинная причина снижения быстродействия совсем в другом: например, в слишком высоких нагрузках на ЦП или в недостаточной эффективности операций ввода/вывода диска. В первом приближении самый надежный признак проблем в подсистеме памяти – это стабильно высокий показатель отсутствия страниц памяти [hard page faults] (скажем, более пяти ситуаций отсутствия страницы в секунду). Ситуация отсутствия страницы возникает в том случае, когда программа не в состоянии обнаружить затребованные данные в физической памяти и потому вынуждена считывать их с диска. Чтобы определить, испытывает ли система недостаток оперативной памяти, можно воспользоваться утилитой Performance Monitor. Чтобы узнать, каково состояние подсистемы памяти, нужно проанализировать значения следующих счетчиков.
Memory: Pages/sec. Счетчик регистрирует количество запрошенных страниц, которые не представлены непосредственно в ОЗУ и потому считываются с жесткого диска или записываются на диск, чтобы освободить пространство ОЗУ для других страниц. Если данный показатель высок при обычных нагрузках на систему, нужно позаботиться об увеличении размера оперативной памяти. Если же значение счетчика Memory: Pages/sec возрастает, тогда как показатель счетчика Memory: Available Bytes приближается к нижней границе, 4 Мбайт, предусмотренной для системы NT Server, а диски, содержащие файлы pagefile.sys, активно участвуют в обменах (т. е. их показатели %Disk Time, Disk Bytes/sec и Average Disk Queue Length возрастают), можно говорить о перегруженности оперативной памяти. Если же счетчик Memory: Available Bytes не фиксирует сокращения свободной памяти, значит, с подсистемой памяти все в порядке. В этом случае нужно выяснить, какая прикладная программа выполняет большое количество операций чтения и записи на диск (и убедитесь, что соответствующие данные не представлены в кэш-памяти). Для этого нужно с помощью утилиты Perfor-mance Monitor проконтролировать объекты Physical Disk и Cache.
На основании значений счетчиков объекта Cache можно судить о том, не малый ли объем кэш-памяти влияет на производительность всей системы.
Memory: Available Bytes. Данный счетчик регистрирует объем доступной программам физической памяти. Как правило, он невелик, поскольку диспетчер Disk Cache Manager системы NT использует почти всю память для кэширования данных, но возвращает ее при поступлении запросов на выделение памяти. Однако если значения счетчика для сервера стабильно ниже порога 4 Мбайт, это свидетельствует о слишком активном страничном обмене.
Memory: Committed Bytes. Счетчик указывает на объем виртуальной памяти, которую система выделяет для хранения данных в физической памяти или в файле подкачки. Если значение Committed Bytes превышает объем физической памяти, вероятно, необходимо увеличить емкость ОЗУ.
Memory: Pool Nonpaged Bytes. Счетчик отражает объем памяти в невыгружаемом пуле, выделяемый для выполнения задач компонентами ОС. Если значение счетчика имеет явную тенденцию к повышению, но соответствующего увеличения нагрузки сервера не наблюдается, это может означать, что выполнение одного из процессов приводит к утечке памяти. Утечка памяти (memory leak) возникает, когда вследствие ошибки программа не высвобождает избыточные ресурсы памяти. Со временем такое непроизводительное расходование памяти может привести к сбою системы, когда ресурсы всей доступной памяти будут исчерпаны (включая физическую память и дисковое пространство, выделенное для размещения файлов подкачки).
Paging File: %Usage. Счетчик показывает, какую долю (в процентах) от максимально возможного размера файла подкачки система использует фактически. Если этот показатель достигает отметки 80%, объем файла подкачки нужно увеличить.
В NT Server предусмотрены средства оптимизации ресурсов памяти системы. Их можно задействовать следующим образом. В панели управления Control Panel нужно перейти к модулю Network, выбрать вкладку Services, а затем элемент Server. При щелчке на элементе меню Properties на экране появится диалоговое окно, в котором предлагается четыре варианта оптимизации (см.
Экран 3): Minimize Memory Used (минимизировать использование памяти), Balance (равномерное использование ресурсов), Maximize Throughput for File Sharing (максимально увеличить пропускную способность для совместно используемых файлов) и Maximize Throughput for Network Applications (максимально увеличить пропускную способность для сетевых приложений). Можно изменять значение еще одного параметра – размера подсистемы виртуальной памяти (проще говоря, файла подкачки). Для этого нужно выбрать вкладку Performance диалогового окна System Properties.
Экран 3. Выбор оптимизации работы сервера.
С точки зрения администратора, в ведении которого находится сервер, обслуживающий множество клиентов, из названных выше вариантов оптимизации ресурсов памяти особого внимания заслуживают два: Maximize Throughput for File Sharing и Maximize Throughput for Network Applications. При выборе варианта Maximize Throughput for File Sharing NT Server выделяет максимальный объем памяти для кэша файловой системы (этот процесс называется dynamic disk buffer allocation). Такая конфигурация особенно эффективна в тех случаях, когда компьютер NT Server используется в качестве файлового сервера. Если вся память выделяется под буферы файловой системы, эффективность дисковых и сетевых операций ввода/вывода, как правило, повышается. С увеличением объема оперативной памяти, обеспечивающей функционирование буферов диска, возрастает вероятность того, что NT Server будет обрабатывать запросы на выполнение операций ввода/вывода не внутри относительно «неповоротливой» файловой системы на физическом диске, а в отличающейся высоким быстродействием кэш-памяти в ОЗУ.
При выборе другого варианта оптимизации – Maximize Throughput for Net-work Applications – NT Server выделяет для кэша файловой системы меньший объем памяти, и прикладным программам достается, соответственно, львиная доля ресурсов ОЗУ. Этот вариант оптимизирует память сервера для выполнения распределенных приложений, предусматривающих кэширование в памяти (Memory caching).
Прикладные программы, например Mic- rosoft SQL Server или Exchange Server, можно настроить таким образом, что они будут использовать заданный объем оперативной памяти для дисковых буферов ввода/вывода и кэша БД.
Но стоит администратору сети, где установлено несколько сетевых прикладных программ, проявить излишнюю «щедрость» и выделить для каждого приложения слишком много памяти, как возникает опасность перегрузки (thrashing). Перегрузка возникает в тех случаях, когда число запросов ко всем активным процессам и к кэш-памяти файловой системы возрастает настолько, что эти запросы блокируют ресурсы памяти системы. В результате запросы к оперативной памяти создают ситуацию отсутствия запрашиваемой страницы. Когда такие ситуации возникают слишком часто, операционная система посвящает почти все свое время не выполнению программ, а записи и удалению данных из виртуальной памяти (свопингу страниц). Чаще всего это приводит к увеличению времени отклика. Если приложение, к которому происходит обращение, не отвечает на запросы, а индикатор диска мигает как ни в чем не бывало, то, скорее всего, система «забуксовала».
Когда производительность системы сдерживается нехваткой памяти, проблему можно решить, увеличив размер файла подкачки или распределив этот файл по нескольким дискам или контроллерам. Одновременно на сервере NT может содержаться до 16 файлов подкачки; при этом в любой момент можно осуществлять чтение и запись данных сразу в несколько файлов. Если объем дискового пространства загрузочного тома ограничен, файл подкачки можно переместить на другой том, что обеспечит выигрыш в производительности. Тем, кто придает первостепенное значение надежности системы, можно порекомендовать такую схему: небольшой файл подкачки размещается на загрузочном томе, а файл более внушительных размеров – на другом томе большей емкости. Есть и другой вариант: файл подкачки размещается на жестком диске (или на нескольких дисках), не содержащем системных файлов NT, либо на специальном томе FAT, который не входит в дисковый массив RAID.
Еще одна рекомендация. Требовательные к ресурсам памяти приложения лучше распределять по нескольким машинам. Внеся соответствующие изменения в системный реестр, можно добиться того, что сервер NT будет работать с кэшем второго уровня емкостью более 256 Кбайт. Для этого нужно запустить редактор regedit.exe, пе-рейти к разделу HKEY_LOСAL_MACHINE\SYSTEM\ CurrentControlSet\Control\ Session Menager\Memory Management и дважды щелкнуть на параметре SecondLevelDataCache. Далее следует выбрать десятичную систему исчисления и ввести значение объема кэш-памяти второго уровня (если емкость составляет 512 Кбайт, нужно ввести число 512). Теперь нужно щелкнуть OK, закрыть редактор реестра и перезапустить систему. Кроме того, советую отключить или удалить неиспользуемые службы, драйверы устройств, а также сетевые протоколы.
Прикладные спецификации Datacenter
Грег Тодд
Во время подготовки данной статьи Microsoft еще не завершила работу над версией 1.3 прикладной спецификации Application Specification for Windows 2000. Версия 1.2 этой спецификации появилась в декабре 1999 г. и послужила основой для сертификации приложений Windows 2000 Server и Windows 2000 AS. В расширенную спецификацию версии 1.3 вошли следующие требования Windows 2000 Datacenter Server.
Прикладные программы должны работать в 4-узловых кластерах. С появлением Datacenter максимальное число узлов в кластере Microsoft Cluster Service увеличено с 2 до 4. Поэтому для получения сертификата Datacenter необходимо, чтобы приложение корректно работало с 2-, 3- и 4-узловыми кластерами. (Все приложения, сертифицированные для Datacenter, получают и сертификат Windows 2000 AS, число узлов в кластере которой не превышает двух.)
Прикладные программы должны работать в режиме PAE-памяти. Datacenter поддерживает 64-Гбайт память с расширенной физической адресацией (Physical Address Extension - PAE), поэтому сертифицированные приложения должны корректно работать в памяти, лежащей выше границы 4 Гбайт. PAE - естественный режим Datacenter, поэтому программы должны выполняться в памяти, расположенной выше 4 Гбайт, точно так же, как и в 4-Гбайт памяти. Кроме того, приложения должны корректно работать в режимах 4Гбайт RAM Tuning (4GT, расширяет прикладную виртуальную память с 2 до 3 Гбайт и уменьшает системную виртуальную память с 2 до 1 Гбайт).
Приложения должны корректно выполняться под управлением объекта «задание». Программа не должна отказывать или зависать, если ее задание запущено на более низком приоритетном уровне, если приложение сгруппировано в задании с несвязанными с ним процессами, если задание перенесено с одного процессора на другой, при увеличении или снижении таких ресурсов, как память или число процессоров. Поставщик прикладной программы объявляет требования к ресурсам, необходимым для правильной работы приложения. Необходимо предусмотреть возможность установки и работы приложения на 32-процессорной машине.
До появления Datacenter массовые приложения не работали на 32-процессорных машинах; таких компьютеров просто не было в продаже, и тем более не было ориентированных на них программ. Теперь сертификат Datacenter выдается программам, стабильно работающим на машинах с 32 процессорами в течение длительного времени.
Прикладные программы должны стабильно работать в тяжелых и необычных условиях. Ключевое требование Datacenter - стабильность операционной системы и приложений. Для проверки стабильности приложений используется двунаправленный стрессовый тест. Во-первых, тестовый набор Datacenter Windows Hardware Compatibility Test (HCT) подвергает нагрузке Datacenter, а стрессовый тест, предоставляемый поставщиком (называемый "тестовой упряжью" - stress harness), подвергает нагрузке сертифицируемую прикладную программу (тест поставщика должен быть общедоступным, чтобы все желающие могли воспроизвести его). Приложение должно также выдержать расширенный стрессовый тест в кластерной конфигурации; в ходе данного теста выполнение программы должно быть передано с одного узла кластера на другой. Приложения, содержащие драйверы устройств, должны пройти дополнительные испытания. Драйверы, работающие в режиме ядра - потенциальный источник сбоев любой программы, и плохо составленный драйвер может повлиять на стабильность Windows 2000 и выполняемых в ней прикладных программ. Чтобы оценить надежность драйверов и других программ, Microsoft подвергает все приложения, содержащие драйверы устройств режима ядра, тестам Datacenter HCT, которые создают интенсивную нагрузку на операционную среду в течение длительного времени. Кроме того, корректность работы всех драйверов должна быть проверена в лаборатории Windows Hardware Quality Labs (WHQL).
Обязательны отладочные функции. Быстрая диагностика неисправностей - важнейшее преимущество процедуры сертификации Datacenter. Чтобы выполнить это требование, поставщики ПО должны предоставить отладочные средства для своих программ, или другой столь же эффективный способ обнаружения ошибок.
Поставщики ПО должны предоставить круглосуточное техническое обслуживание без выходных. Пользователи Datacenter, обращающиеся в службу поддержки, ожидают быстрого ответа, независимо от времени суток и числа неисправных продуктов. Поэтому поставщики сертифицированных продуктов Datacenter должны гарантировать, что дежурный специалист Joint Support Queue быстро ответит на звонок и решит проблему в любое время. (Joint Queue - организация технического обслуживания Datacenter, в которую входят представители Microsoft и OEM-изготовителей.)
Такие требования к программам в действительности не новы. Это улучшения, касающиеся в основном поддержки, стабильности и простоты решения проблем. Любое приложение, развернутое в среде Datacenter, должно иметь характеристики продукта учрежденческого уровня. Поставщики и приложения Datacenter "играют" в высшей лиге, и должны соответствовать всем ее требованиям.
Грег Тодд – Директор по производству в NetIQ. Работает с технологиями NT с 1993 г. С ним можно связаться по адресу: gregt@netiq.com.
Процессор
Чтобы проверить, не в процессоре ли кроется причина снижения производительности NT Server, необходимо для начала убедиться в том, что подсистема памяти работает нормально. ЦП становится критическим фактором лишь в тех случаях, когда процессор так загружен, что не может отвечать на запросы. В числе симптомов подобной ситуации – высокий коэффициент загрузки процессора, постоянные очереди и вялый отклик приложений. Как правило, нормальную работу ЦП нарушают ориентированные на интенсивное потребление ресурсов процессора приложения и драйверы, а также чрезмерное количество запросов на прерывание (из-за плохо спроектированных компонентов дисковой или сетевой подсистемы).
Отслеживать коэффициент использования процессора системы помогут следующие счетчики.
Processor: % Processor Time. Отображает время, затрачиваемое процессором на выполнение активных потоков. Если в системе установлено несколько процессоров, нужно обратиться к счетчику System: % Total Processor Time. Если коэффициент загруженности процессора стабильно превышает 80%, возможно, именно этот компонент сдерживает производительность всей системы. Чтобы выявить причину такой загруженности процессора, можно с помощью утилиты Performance Monitor проверить индивидуальные процессы. Однако нужно иметь в виду, что высокий показатель счетчика Processor: % Processor Time не всегда свидетельствует о снижении производительности. Если ЦП обрабатывает запросы от планировщика заданий NT Server, а показатели счетчиков Server Work Queues и Processor Queue Length при этом не возрастают, это значит, что ЦП обслуживает процессы максимально быстро. Говорить о том, что процессор тормозит работу системы, можно лишь в том случае, если значение счетчика System: Processor Queue Length возрастает; показатель Processor: % Processor Time тоже высок, а память системы, сетевой интерфейс и жесткие диски работают нормально. ЦП становится «узким местом» системы лишь тогда, когда он не в состоянии справиться с нагрузкой, предлагаемой NT. ЦП работает на полную мощность, но при этом очередь необработанных запросов, претендующих на его ресурсы, становится все длиннее.
Processor: % Privileged Time. Этот счетчик показывает, сколько времени ЦП затрачивает на обслуживание операционной системы.
Processor: % User Time. Время, затрачиваемое процессором на выполнение кода приложений и подсистем (например, текстового процессора или электронных таблиц). Нормальным следует считать значения 75% и ниже.
Processor: Interrupts/sec. Число прерываний от прикладных программ и аппаратных устройств, обрабатываемое процессором (за одну секунду). Этот показатель зависит от интенсивности обменов с диском, от числа операций, выполняемых за одну секунду, и от числа сетевых пакетов, передаваемых за одну секунду. Чем выше быстродействие процессора, тем большее число прерываний он способен обработать. Для большинства современных ЦП этот показатель составляет порядка 1500 прерываний в секунду.
Process: % Processor Time. Счетчик показывает, какая часть процессорного времени в процентах приходится на выполнение того или иного процесса. С его помощью можно определить, какой из процессов занимает подавляющую часть рабочих циклов процессора.
System: Processor Queue Length. Показатель отражает число задач, ожидающих обработки. Если система выполняет несколько задач, то иногда показания счетчика превышают нулевой порог. Если же значение счетчика регулярно достигает цифры 2 или превосходит этот показатель, процессор, несомненно, не справляется с нагрузкой: слишком много процессов ожидают обработки. Чтобы выяснить причину «затора», нужно запустить утилиту Performance Monitor и исследовать объект «процесс», а также провести более подробный анализ отдельных процессов, обращающихся с запросами к процессору.
Один из способов избавиться от неприятностей, связанных с низкой производительностью процессора, сводится к установке в машине центрального процессора с более высокими характеристиками. Если речь идет о системе, с которой одновременно могут работать несколько пользователей и на которой выполняются многопотоковые прикладные программы, увеличения мощности процессорной подсистемы можно добиться за счет установки дополнительного процессора.
Когда обрабатывается многопотоковый процесс, для повышения производительности можно добавить еще один процессор, а если процесс однопотоковый, для повышения быстродействия нужно заменить процессор на более производительный. Но если в сети установлена операционная система с однопроцессорным ядром NT, то, возможно, придется модернизировать ядро до многопроцессорной версии. Для этого нужно переустановить NT или воспользоваться утилитой uptomp.exe из комплекта ресурсов Resource Kit.
Еще один способ оптимизации характеристик ЦП состоит в том, чтобы с помощью диспетчера Task Manager выявить процессы, «потребляющие» основную часть рабочих циклов процессора, и назначить им соответствующие приоритеты. Изначально процесс имеет базовый (заданный администратором) приоритет, но порождаемые подпроцессы могут иметь другую очередность (диапазон колебаний – на два уровня выше или ниже базового приоритета). Если нагрузки на процессор достаточно велики, ускорить выполнение того или иного процесса можно за счет повышения его приоритета. Для этого нужно, нажав комбинацию клавиш Ctrl+Alt+Del, запустить диспетчер Task Manager и перейти к вкладке Processes. Теперь следует щелкнуть правой клавишей мыши на интересующем процессе, выбрать пункт Set Priority и установить для приоритета процесса одно из значений – High, Normal или Low, как показано на Экране 4. Новые приоритеты вступают в силу немедленно, но нужно иметь в виду, что это решение временное. После перезагрузки системы или перезапуска данного приложения все установленные значения приоритетов будут потеряны. Чтобы обеспечить заданный уровень приоритетов при всех последующих запусках прикладной программы, нужно воспользоваться командой Start, которая вводится из командной строки или включается в пакетный файл. Познакомиться с ключами команды Start можно, введя из командной строки
start /?
Экран 4. Установка приоритета процесса.
ПРОЦЕССОРА
Разработчики Microsoft приложили немалые усилия для повышения масштабируемости Datacenter. Унаследовав все достижения Windows 2000 Server и Windows 2000 AS, версия Datacenter дополнена новшествами, доселе неизвестными пользователю.
Некоторые решения, использованные в Datacenter, впервые встречаются в продуктах Microsoft, в частности, возможность работы с 32 процессорами в одной машине. Это центральный элемент стратегии Microsoft, направленной на увеличение масштабируемости серверов семейства Windows 2000.
Для машины с восемью симметричными процессорами (SMP) достаточно купить одну лицензию NT Server 4.0, Enterprise Edition (NTS/E), хотя лучшее соотношение цена/производительность достигается для компьютеров с четырьмя-шестью процессорами. Microsoft расширила возможности работы с несколькими процессорами всех продуктов семейства Windows 2000, и особенно Datacenter. Машины с 32 процессорами, такие как ES7000 фирмы Unisys, становятся более доступными, и пользователи смогут по достоинству оценить функции процессорного масштабирования Windows 2000.
С целью повышения SMP-масштабируемости были оптимизированы некоторые центральные компоненты Windows 2000. Изменения заключались в повышении параллелизма в сочетании со снижением числа последовательных операций и совершенствованием таких базовых характеристик, как скорость ввода-вывода, работа драйверов устройств и набора протоколов TCP/IP.
Степень структурированности системных пулов и списков Windows 2000 по процессорам выше, чем у NT 4.0. Каждому процессору выделяются страничные и невыгружаемые на диск списки опережающей выборки для распределения памяти, пулы потоков и порты завершения ввода-вывода. Среди прочих улучшений методов масштабирования - более широкое использование "волокон" (fiber - "легковесный" поток) с целью снижения затрат памяти и ресурсов на переключение контекста приложений с "волокнами". Кроме того, сюда относится не столь частое использование блокировок Page Frame Number (номер страничного блока), достигаемое благодаря увеличению на 50% виртуального адресного пространства кэша и новому алгоритму удаления давно использовавшихся элементов (least recently used - LRU).
Windows 2000 перепроектирована для SMP, начиная с ядра. В результате удалось повысить линейность масштабирования, (производительность растет пропорционально увеличению числа процессоров; она не выравнивается после добавления четвертого или шестого процессора, как в NT 4.0) лучше привязать задачи к процессору (некоторые процессы можно ассоциировать с конкретным ЦП, увеличив производительность благодаря снижению затрат на переключение контекста при передаче процесса от одного процессора другому), и улучшить соотношение цена\производительность при увеличении числа ЦП. Максимум производительности NT Server 4.0 при использовании четырех-шести процессоров наверняка останется в прошлом.
Сетевой интерфейс
После исследования памяти системы, характеристик процессора и диска можно приступать к анализу сетевой подсистемы. Клиенты и другие системы должны иметь возможность быстро подключаться к сетевой подсистеме ввода/вывода NT Server так, чтобы время отклика на запросы пользователей не превышало допустимых пределов. Чтобы определить, какие компоненты сетевой архитектуры провоцируют снижение производительности системы и как устранить эти сдерживающие факторы, администратор должен иметь четкое представление о том, каков характер нагрузок, генерируемых клиентскими системами, какие компоненты являются ключевыми в применяемой сетевой архитектуре, какие сетевые протоколы используются (скажем, Ethernet или Net-BEUI) и каковы физические характеристики сети. Программа Performance Monitor аккумулирует данные по каждому физическому сетевому адаптеру. Для выявления нагрузки на адаптеры используются следующие счетчики.
Network Interface: Output Queue Length. Счетчик фиксирует длину очереди исходящих пакетов адаптера. Приемлемыми считаются значения 1 и 2. Но если этот показатель часто достигает уровня 3, 4 или более высоких отметок, это значит, что сетевой адаптер ввода/вывода не справляется с запросами сервера на передачу данных в сеть.
Network Interface: Bytes Total/sec. Показатель отражает весь объем сетевого трафика (число отправленных и полученных байтов), проходящего через сетевой адаптер в течение одной секунды; в него включаются и непроизводительные затраты, связанные с использованием как сетевых протоколов (к примеру, TCP/IP и NetBEUI), так и физического типа сети (например, Ethernet). Если, скажем, в сети 10BaseT этот показатель составляет около 1 Мбайт/с, а очередь исходящих пакетов, ожидающих обработки в адаптере, продолжает расти, скорее всего, причина низкого быстродействия кроется в сетевом интерфейсе.
Network Interface: Bytes Sent/sec. Отражает число байтов, проходящих через данную сетевую интерфейсную плату за одну секунду.
Server: Bytes Total/sec. Показывает число байтов, отправленных и полученных сервером за одну секунду по сети через все его сетевые интерфейсные платы.
Server: Logon/sec. Число предпринимаемых за одну секунду попыток регистрации, включая локальную проверку прав доступа, а также аутентификацию учетных записей служб и пользователей по сети. Если активизировать такие счетчики на контроллерах доменов (DC), можно получить полезную информацию об объеме данных, проходящих проверку на достоверность в процессе регистрации.
Server: Logon Total. Общее число попыток регистрации, предпринятых за время, прошедшее с момента последнего запуска компьютера, включая локальную проверку прав доступа, а также аутентификацию учетных записей служб и пользователей сети.
Если анализ показал, что слабым звеном в системе является сетевой интерфейс, можно действовать по-разному. Так, можно попробовать связать сетевой адаптер только с теми протоколами, которые используются в данное время; установить на сетевых адаптерах новейшие версии драйверов; заменить сами адаптеры на более современные; наконец, установить дополнительные адаптеры и разбить сеть на сегменты (что позволит изолировать трафик, поступающий на интересующие сегменты). Дабы убедиться, что причины низкой производительности кроются в сетевом компоненте, следует проверить общую пропускную способность сети и заменить недостаточно эффективные компоненты физического уровня (коммутаторы, концентраторы). Можно поискать решение и в другом направлении – распределить вычислительную нагрузку по большему числу серверов.
В сети TCP/IP администратор может попытаться повысить производительность за счет увеличения размеров окна TCP. Размер окна приема (данных по протоколу) TCP/IP отражает объем полученных данных (в байтах), которые в каждый момент могут помещаться в буфер, созданный системой для какого-либо соединения. В NT размер окна фиксированный; по умолчанию для сетей Ethernet он составляет 8760 байт, однако в системном реестре можно задать и другой размер окна. Сделать это можно, или задав другое значение раздела HKEY_LOCAL_MACHINE\SYSTEM\ CurrentcontrolSet\Services\Tcpip\ Parameters\TcpWindowSize и изменив эту установку для всей системы, или воспользовавшись вызовом Windows Sockets setsockopt(), для изменения конкретного сокета.Оптимальный размер окна зависит от архитектуры сети. В сетях TCP максимальная пропускная способность выражается числом, получаемым при делении размера окна на величину задержки, связанной с подтверждением приема, или на величину сетевой задержки.
И последнее замечание по сетевым адаптерам. Не следует использовать их в режиме Autosense (автоматического распознавания режима работы сети 10/100 Мбит/c). Настраивайте сетевые интерфейсные платы на точное значение быстродействия – на то, которое нужно получить. Изменять этот параметр следует с помощью программы конфигурации, поставляемой с сетевым адаптером.
ТАБЛИЦА 1: Сравнительные характеристики Windows
| Параметр | Windows 2000 Server | Windows 2000 AS | Datacenter |
| Макс. Число ЦП | 4 | 8 | 32 |
| Макс. емкость памяти, Гбайт | 4 | 8 | 64 |
| Совместимость с WSD | Нет | Нет | Да |
| Кластерная служба | Нет | Да, 2 узла | Да, 4 узла |
| Совместимость с NLB | Нет | Да, 32 узла | Да, 32 узла |
| Управление объектом задания | Только API | Только API | API, встраиваемый модуль MMC Process Control, утилита Proccon |
| Joint Support Queue | Нет | Нет | Да |
| Сертификация приложений | Сертификат Windows 2000 Server | Сертификаты Windows 2000 Server и Windows 2000 AS | Сертификаты Windows 2000 Server, Windows 2000 AS и Datacenter |
| Продавец | Microsoft | Microsoft | Уполномоченные OEM |
| Аппаратная совместимость | Стандартный Windows 2000 HCL | Стандартный Windows 2000 HCL | Специальный Datacenter HCL |
Некоторые инструментальные средства контроля за производительностью Windows NT.
| Программа | Поставляется в комплекте | Решаемые задачи |
| Data Logging Service | Microsoft Windows NT Server 4.0 Resource Kit Supplement 4 | Аналог Performance Monitor Alert and Logging. Полезна для дистанционного администрирования журналов на нескольких компьютерах. |
| Network Monitor | NT | Позволяет просматривать параметры сетевого трафика, проходящего через отдельный сервер. |
| Page Fault Monitor | Supplement 4 | Позволяет регистрировать ситуации отсутствия страницы при выполнении прикладных программ. |
| Pentium Counters | Supplement 4 | Счетчики позволяют следить за внутренними параметрами процессоров Pentium и Pentium Pro. |
| Performance Data Log Service | Supplement 4 | Протоколирование данных счетчиков производительности в файл с разделителями в виде табуляции или запятой (CSV). |
| Performance Monitor | NT | Программа сбора статистических данных за короткие и длительные периоды времени, а также анализа этих данных. |
| Process Explode | Supplement 4 | Средство обеспечивает точную и подробную информацию о процессах, потоках и памяти в системе. |
| Process Monitor | Supplement 4 | Обеспечивает отображение статистики процессов в текстовом формате в командном окне. |
| Process Viewer | Supplement 4 | Отображает данные о процессах на локальном и удаленном компьютерах. Особенно полезно при анализе использования памяти процессами. |
| Quick Slice | Supplement 4 | Выводит в графическом виде информацию об использовании ресурсов ЦП процессом. |
| Response Probe | Supplement 4 | Позволяет моделировать рабочие нагрузки. |
| SC Utility | Supplement 4 | Предоставляет командную строку на контроллере службы для отображения конфигурации конкретной машины. |
| Task Manager | NT | Обеспечивает мониторинг, запуск и прекращение работы активных приложений и процессов на компьютере. |
УРОВЕНЬ УПРАВЛЯЕМОСТИ
В версиях Windows, предшествовавших Windows 2000, было невозможно сгруппировать процессы таким образом, чтобы они представляли для операционной системы единое целое. В Windows 2000 эту роль выполняет объект «задание» - это группа процессов, чаще всего связанных между собой, которую можно защищать и управлять как единым целым. В Datacenter предусмотрено два способа для доступа к заданиям: Process Control, встраиваемый модуль консоли управления Microsoft Management Console (MMC), и Proccon, утилита, запускаемая из командной строки. С помощью утилит управления процессом можно распределять, создавать, обслуживать и удалять ресурсы задания. Более того, как Process Control, так и Proccon работают на любой системе Windows 2000, в том числе Windows 2000 Professional, что позволяет дистанционно управлять заданиями в системе Datacenter.
Альтернативный способ заключается в программном доступе к объекту «задание» с помощью Windows Script Host (WSH) в сочетании со стандартными языками программирования. Набор API для работы с заданиями реализован не только в Datacenter, но и во всех серверных продуктах семейства Windows 2000. Тому, кто любит программировать, рекомендуется использовать API. В SDK для платформы Windows 2000 приводятся подробные объяснения, как обратиться к объектам заданий. На перечислены атрибуты задания, которыми может манипулировать программист.
Возможности практического применения заданий многообразны. С их помощью можно ограничить использование ресурсов слишком "жадными" программами. Можно задать аффинность процессоров, чтобы распределить приложения между соответствующим числом ЦП. Объекты «задание» помогут выполнить соглашения об уровне обслуживания (service level agreement - SLA). Изменения, вносимые в это объекты, устойчивы, поэтому они сохраняются после перезагрузки операционной системы и перезапуска приложений, а вносить изменения можно "на ходу" (то есть, не требуется приостанавливать или перезапускать программу).
Предположим, что на машине Datacenter работает приложение с пятью процессами.
Необходимо ограничить рабочую область памяти, используемую каждым процессом. Единственный способ ограничить рабочую область - создать задание, содержащее все процессы, или задания для каждого процесса. Если границы рабочей области нарушаются, то событие заносится в журналы событий. Обнаружить и манипулировать свойствами объектов «задание» просто, если использовать snap-in модуль Process Control, как показано на Рисунке 7.
Рис. 7
В Datacenter, как и в Windows 2000 AS, внесены усовершенствования, облегчающие управление кластерной службой. В частности, упрощены процедуры установки кластерной службы, поэтапной модернизации приложений на узлах, обеспечена возможность использовать хранилище Active directory (AD) для централизованного управления библиотеками DLL ресурсов кластера, реализована технология Plug and Play (PnP) для сетевых и дисковых аппаратных средств, улучшены интеграция MMC и COM-интерфейс с кластерным API. Кластерная служба Datacenter поддерживает такие компоненты инфраструктуры Windows 2000, как Microsoft Dfs, Network News Transfer Protocol (NNTP - протокол передачи сетевых новостей), SMTP, DHCP и WINS, существующие функции совместного использования файлов, спулинга печати, службы Microsoft Message Queue Services (MSMQ - служба очередей сообщений), Microsoft Distributed Transaction Coordinator (MS DTC - координатор распределенных транзакций), SQL Server, Exchange 2000, Microsoft IIS и универсальные приложения и службы.
Working set size Time limits
Limit- and Constraint-Related Attributes
Working set size Time limits (e.g., execution, CPU) Number of active processes Processor affinity OS priority class
Security- and Access-Related Attributes
ACLs and tokens Handle access Clipboard access System changes System or process exit capability Datacenter Application Specifications
ВЫЗОВ UNIX
С появлением Datacenter существенно поднимается планка для операционных систем Windows, работающих на серверах Intel, а Windows 2000 оказывается непосредственным конкурентом мощных серверных решений на базе Unix. Благодаря сложным новейшим технологиям достигается более высокая масштабируемость, готовность и управляемость Datacenter по сравнению с предыдущими версиями Windows.
Кроме того, Datacenter сопутствуют унифицированная техническая поддержка, контролируемая аппаратная поддержка, аттестованные по строгим критериям программы, драйверы, работающие в режиме ядра и проверенные специалистами лаборатории WHQL и OEM-изготовителями, и очевидная стабильность. Все эти достоинства вместе стали слагаемыми успеха лучшей операционной системы, когда-либо созданной Microsoft.
Windows 2000 Datacenter Server
Грег Тодд
16.01.2001
Самая мощная операционная система Microsoft предназначена для решения самых сложных задач
Компания Microsoft спроектировала Windows 2000 Datacenter Server, самую мощную ОС семейства Windows 2000, в расчете на потребителей, нуждающихся в больших системах, подобных мейнфреймам - с повышенной стабильностью и незаурядными возможностями масштабирования. До настоящего времени Windows 2000 и ее предшественница, Windows NT 4.0, не могли соперничать с мощными версиями Unix. С появлением Datacenter Microsoft надеется выровнять положение, задействовав Windows на более крупных и мощных машины, чем когда-либо до этого.
Datacenter можно описать так: Windows 2000 Advanced Server, плюс пакет обновления Service Pack 1 (SP1), плюс дополнительные функции, предоставляемые лишь OEM-изготовителями протестированной и получившей одобрение аппаратуры. Благодаря дополнительным возможностям повышается уровень масштабируемости, готовности и управляемости Windows 2000. Специальные требования к сертификации и техническому обслуживанию еще более выделяют эту операционную систему среди остальных серверов семейства Windows 2000. В Таблице 1 приведены сравнительные характеристики Datacenter, Windows 2000 AS и Windows 2000 Server.
Windows Sockets Direct
Гнезда Windows Sockets Direct (WSD) позволяют обойти сравнительно медленные протоколы IP при организации сетей SAN (System Area Network - сетевая архитектура систем), тем самым предоставляя приложениям Winsock прямой доступ к аппаратным средствам SAN для скоростной пересылки данных. Таким образом, Datacenter обеспечивает широкие возможности масштабирования распределенных и параллельных прикладных программ, использующих сети SAN. Технология WSD реализована только в Datacenter.
SAN - особый класс сетевой архитектуры со скоростными каналами связи между защищенными серверами. Такая "сеть в сети" обеспечивает чрезвычайно высокую скорость пересылки данных (свыше 1 Гбит/с) по надежным каналам с малыми непроизводительными затратами и задержками. Для маршрутизации данных в сетях SAN используются коммутаторы; концентратор обычно обслуживает от четырех до восьми и более узлов. Соединяя концентраторы каскадом, можно строить более крупные сети. Предельная длина кабеля составляет от нескольких метров до нескольких километров.
Недостаток сетей SAN заключается в том, что их транспортные протоколы, несмотря на высокую надежность, уникальны, поскольку сетевые интерфейсы реализованы непосредственно в аппаратуре. Однако в большинстве приложений Windows используются протоколы TCP/IP и Winsock. Таким образом, поставщик прикладных программ Windows, желающий добиться совместимости своих продуктов с SAN без WSD, должен разместить между TCP/IP и уникальным транспортным протоколом SAN дополнительный слой преобразования. Как показано на Рисунке 2, Datacenter WSD играет роль провайдера TCP (то есть коммутатора Winsock), размещенного над провайдером TCP/IP, и провайдера SAN, обеспечивая доступ нескорректированных приложений Winsock к сетям SAN.
Рис. 2
В наборе программ, реализующих протокол WSD, коммутатор Winsock определяет, следует ли направить трафик через обычный набор протоколов TCP/IP или "родному" провайдеру SAN Winsock в обход TCP/IP. Кроме того, WSD обеспечивает прямой обмен данными с аппаратными средствами SAN из обычного процесса пользовательского режима Datacenter, что позволяет успешно использовать преимущества SAN в обычных приложениях, в случае, если аппаратные средства SAN пригодны для прямого ввода-вывода. Результат: повышение производительности по сравнению с обычным протоколом TCP/IP, как показано на Рисунке 3.
Рис. 3
Скорость выполнения прикладных программ может быть существенно повышена, если обращаться к сетям SAN через WSD вместо TCP/IP. Кроме того, для работы с WSD не требуется изменять приложения или реализовывать в них логику уникальных транспортных интерфейсов SAN. Более подробную информацию о WSD и сетях SAN можно найти в статьях Microsoft "Description of System Area Networks" (http://support.microsoft.com/support/kb/articles/q260/1/76.asp) и "Differences Between a System Area Network and a Storage Area Network" (http://support.microsoft.com/support/kb/articles/q264/1/35.asp).
Знай свою среду
Для анализа факторов производительности требуется способность логически мыслить. Но, кроме того, нужны статистические данные, получаемые опытным путем, и немалое терпение. Корректируя производительность корпоративных систем, администраторы вполне могут полагаться на главные средства контроля и оптимизации, поставляемые с NT.
Ключ к успеху – ясное представление о своем сетевом хозяйстве и понимание того, как функционируют прикладные программы и как служащие пользуются ресурсами сети. Для успешного решения проблем, связанных со снижением производительности системы, а также составления планов с учетом требований, которые будут предъявляться к системе в дальнейшем, я рекомендую опираться на информацию, предоставляемую описанными выше инструментами, и на знание используемых в организации прикладных программ и вычислительной среды.
Крис Бенсон – независимый автор, пишущий на темы построения крупных сетей предприятий и глобальных сетей, а также о работе систем хранения. Имеет сертификаты MCSE и CNE. С ним можно связаться по адресу: cbanson@itref.com
