Изменения внутреннего устройства ядра Windows Server 2008
ОГЛАВЛЕНИЕ
Поскольку в операционной системе Windows Server® 2008 используется то же ядро, что и в Windows Vista® SP1, в нее включены многие усовершенствования, уже обсуждавшиеся в моих предыдущих статьях, опубликованных в TechNet Magazine: «Внутреннее устройство ядра ОС Windows Vista» (в трех частях – в февральском, мартовском и апрельском выпусках за 2007 г.) и «Управление учетными записями пользователей Windows Vista: взгляд изнутри» (июнь 2007 г.). Только небольшая часть средств, описанных в этих статьях и реализующих характерные для клиентов возможности, не включена в операционную систему Windows Server 2008 — например SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot и служба планировщика классов мультимедиа MMCSS.
Вместо того, чтобы повторно обсуждать появившиеся в Windows Vista важные изменения ядра, которые присутствуют также и в Windows Server 2008, например, назначение приоритетов операциям ввода-вывода, новая архитектура загрузки, BitLockerTM, целостность кода и необходимые уровни целостности, я сосредоточусь на важнейших изменениях, не обсуждавшихся в этих статьях, включая те, которые относятся к надежности, эффективности, масштабируемости, а также на Hyper-VTM — новой технологии Майкрософт для виртуализации компьютера гипервизора.
Подобно предыдущим статьям, в данной статье содержание ограничено обсуждением ядра операционной системы, Ntoskrnl.exe, а также тесно связанными с ним компонентами. Например, в статье не обсуждаются изменения, относящиеся к установке (WIM, или Windows® Imaging Format, и Component-Based Servicing), управлению (групповая политика и усовершенствования в Active Directory®), общие средства текущего контроля и диагностики (диагностическая инфраструктура Windows), сетевые возможности ядра (реализация нового брандмауэра и TCP/IP), ядро сервера и серверные роли.
Работа в среде многопроцессорных систем
Одно из изменений на низком уровне системы состоит в том, что в Windows Server 2008 входит только версия ядра, предназначенная для работы в среде многопроцессорных систем. Раньше в Windows использовалась версия, ориентированная на однопроцессорные системы, установленные на машинах с единственным ЦПУ, поскольку такая версия обеспечивала несколько большую производительность за счет отсутствия кода для синхронизации, необходимого только в многопроцессорных средах. В связи с тем, что оборудование стало работать быстрее, повышением производительности за счет оптимизации можно пренебречь, и в настоящее время большинство серверных систем содержит несколько процессоров, что избавляет от потребности в однопроцессорной версии.
На рис. 1 показаны варианты ядра Windows Server 2008. Версия ядра, используемая в системе, зависит от того, является ли версия операционной системы отладочной (Checked) или розничной, от варианта установки — в 32- или 64-разрядной архитектуре (Itanium, Intel 64 или AMD64) и, в случае установки в 32-разрядной среде, от того, имеется ли в системе более 4 ГБ физической памяти, и поддерживается ли предотвращение выполнения данных (DEP — Data Execution Prevention). Кроме этого, предполагается, что Windows Server 2008 — последняя система, поддерживающая 32-разрядную версию.
Рис. 1 Варианты ядра Windows Server 2008
| Ядро | 32-разрядная архитектура | 64-разрядная архитектура |
| Многопроцессорная архитектура | Да | Да |
| Установлен флажок «Многопроцессорная архитектура» | Да | Да |
| Расширение физических адресов (PAE) многопроцессорной архитектуры | Да | Нет |
| Установлен флажок «PAE многопроцессорной архитектуры» | Да | Нет |
Каждый выпуск Windows Server нацелен на повышение производительности основных серверных операций, таких как операции с файлами, сетевые операции ввода-вывода и управление памятью. Кроме этого, в Windows Server 2008 вошло несколько изменений и новых компонентов, позволяющих системе Windows использовать преимущество новых архитектур оборудования, настраивать систему на работу с сетями, имеющими большую задержку и устранить факторы, ограничивавшие производительность в предыдущих версиях Windows. В данном разделе обсуждаются усовершенствования в диспетчере памяти, системе ввода-вывода и новая сетевая файловая система, SMB 2.0.
Управление памятью
Эксперимент: обзор объемных дисковых операций ввода-вывода
В системе Windows Server 2008 для просмотра объемных файловых операций ввода-вывода предусмотрен такой инструмент текущего контроля файловой системы, как TechNet Sysinternals Process Monitor (technet..microsoft.com/sysinternals/bb896645.aspx).
Существует несколько способов работы с операциями ввода-вывода большого объема. Если имеется вторая система, работающая под управлением пакета обновлений 1 для Windows Vista или под управлением Windows Server 2008, на сервере можно запустить Process Monitor и следить за копиями файлов во второй системе. Также распространенным вариантом работы с операциями объемного ввода-вывода для файла подкачки является выполнение программы, интенсивно использующей память, которая вынуждает диспетчер памяти записывать страницы в файл подкачки.
На рис. A показан Process Monitor после выполнения в среде Windows XP программы с большой потребностью в памяти. В меню параметров Process Monitor установлен флажок «Включить расширенный вывод» и установлен фильтр для отображения только операций записи в файл подкачки, pagefile.sys. В столбце «Подробные сведения» видно, что выполняются операции записи объемом 64 КБ.
Рис. А
При выполнении этих же действий в среде Windows Server 2008, скорее всего, сложится ситуация, похожая на ту, которая показана на рис. B и где видно, что большинство операций записи имеют объем приблизительно 1 Мбайт.
Рис. Б
В диспетчер памяти системы Windows Server 2008 внесено несколько усовершенствований для повышения производительности. Например, при доставке данных из файла подкачки или выполнении упреждающих операций ввода-вывода с отображенными файлами генерируются дисковые операции ввода-вывода как меньшего, так и большего объема. Выполнение объемного файлового ввода-вывода облегчается благодаря изменениям в системе ввода-вывода, освободимшим ее от ограничения в 64 КБ на объем операций ввода-вывода, существовавшего начиная с первого выпуска Windows NT®.
Кроме этого, важно отметить, что при упреждающем чтении из отображенных файлов, выполняемом диспетчером кэша, объем данных в системе Windows Server 2008, как правило, в два раза больше, чем в системе Windows Server 2003, и эти операции попадают напрямую в список ожидания (код системы и кэш данных). Такое поведение возникает вместо требования к диспетчеру кэша отображать виртуальную память и считывать данные в рабочий набор системы (память, приписанная системе диспетчером памяти), что может вызвать не обусловленное необходимостью вытеснение из рабочего набора используемого кода или данных.
Диспетчер памяти выполняет объемные операции ввода-вывода также и при записи данных в файл подкачки. Хотя Windows Server 2003 часто выполняет операции записи даже меньшего, чем 64 КБ, объема, в среде Windows Server 2008 диспетчер памяти обычно генерирует операции записи объемом 1 МБ.
Помимо повышения производительности за счет сокращения числа операций записи в файл подкачки, объемные операции записи позволяют также уменьшить фрагментирование файла подкачки. Это, в свою очередь, приводит к сокращению числа операций чтения и поиска на диске, необходимых для извлечения нескольких страниц, поскольку, скорее всего, они будут смежными.
Диспетчер памяти пытается также записывать другие измененные страницы, находящиеся поблизости от той, которая записывается в адресное пространство процесса, которому они принадлежат. При этом диспетчер выполняет запись в тот участок файла подкачки, где уже находятся другие соседние страницы. Это также минимизирует фрагментацию и позволяет повысить производительность, поскольку страницы, которые со временем могут быть записаны в файл подкачки, уже записаны. Дополнительно это сокращает число операций чтения страниц, необходимых для извлечения смежных страниц процесса. Дополнительные сведения об использовании диспетчером памяти объемных операций ввода-вывода см. на боковой панели «Эксперимент: обзор объемных дисковых операций ввода-вывода».
SMB 2.0
Протокол удаленной файловой системы Server Message Block (SMB), известный также под названием Common Internet File System (CIFS), служил основой для файловых служб Windows с момента появления в Windows средств по обслуживанию файлов. В течение последних нескольких лет проектные ограничения протокола SMB ограничивали производительность файловых служб и возможности использования преимуществ новых функций локальных файловых систем. Например, максимальный размер буфера, который можно передать в одном сообщении, составляет приблизительно 60 КБ, и в SMB 1.0 не предусмотрена работа с символическими ссылками клиентской стороны NTFS, которые были добавлены в Windows Vista и Windows Server 2008.
В Windows Vista и Windows Server 2008 появилась версия SMB 2.0, нового протокола удаленного обслуживания файлов, который используется Windows в случае, когда его поддерживает и клиент, и сервер. Помимо правильной обработки символических ссылок и других усовершенствований NTFS, протокол SMB 2.0 использует пакетирование данных для минимизации числа сообщений, которыми обмениваются клиент и сервер. Пакетная обработка позволяет повысить пропускную способность в сетях с высокой задержкой, таких как глобальные сети (WAN), поскольку она дает возможность передавать больший объем данных в один прием.
В то время как SMB 1.0 инициирует операции ввода-вывода для одного файла последовательно, SMB 2.0 реализует операции ввода-вывода в конвейерном режиме, позволяя инициировать для одного файла несколько параллельно выполняющихся операций ввода-вывода. С целью определения глубины конвейеризации измеряется объем серверной памяти, используемой клиентом для ожидающих выполнения операций ввода-вывода.
Благодаря изменениям в диспетчере памяти системы ввода-вывода и системе ввода-вывода Windows, автоматической настройке окна получения TCP/IP и усовершенствованиям механизма копирования файлов, SMB 2.0 обеспечивает значительные усовершенствования и сокращение времени копирования файлов при объемной передаче данных. Поскольку в обеих операционных системах реализован протокол SMB 2.0, развертывание файловых серверов Windows Server 2008 с помощью клиентов Windows Vista дает возможность использовать SMB 2.0 и добиться этих преимуществ в производительности.
Надежность, обеспечиваемая автоматическим устранением неполадок в NTFS
Надежность является важнейшей характеристикой сервера, и операционная система Windows Server 2008 предоставляет разнообразные усовершенствования, облегчающие администраторам поддержку бесперебойной работы серверов, включая интерактивное восстановление согласованности NTFS, новую инфраструктутру для создания отчетов о сбоях оборудования и расширения инструмента проверки драйверов.
Объем современных накопительных устройств достигает нескольких терабайт, и перевод тома в автономный режим для проверки согласованности может привести к многочасовому перерыву в обслуживании. Определив, что многочисленные повреждения диска локализованы в одном файле или части метаданных, Windows Server 2008 применяет новый компонент NTFS для автоматического устранения неполадок и исправляет повреждение, не переводя том в автономный режим.
Если NTFS обнаруживает повреждение, она перекрывает доступ к поврежденному файлу или файлам и создает системный рабочий поток, вносящий в поврежденные структуры данных исправления, аналогичные исправлениям Chkdsk, и обеспечивающие доступ к восстановленным файлам по завершении работы потока. В течение этой операции доступ к другим файлам обеспечивается в обычном режиме, что минимизирует нарушения обслуживания.
Инфраструктура WHEA
Инфраструктура WHEA, входящая в Windows Server 2008, обещает упростить управление сбоями оборудования и обеспечить упреждающий отклик на ошибки, не являющиеся неустранимыми. Зачастую серверы должны обеспечивать строгие гарантии бесперебойной работы, поэтому в таких системах жизненно важной является своевременная идентификация ошибок и отклик на их возникновение.
Анализ сбоев, предоставленный корпорации Майкрософт посредством OCA (Online Crash Analysis), показывает, что приблизительно 10 процентов сбоев операционных систем является реакцией на сбой оборудования, но определение глубинной причины этих сбоев оказывается сложным или невозможным из-за того, что оборудование предоставляет недостаточно информации для фиксации сбоя. Кроме этого, до появления Windows Server 2008, в системе Windows отсутствовали встроенная поддержка для текущего контроля за работоспособностью устройств и средства исправления или уведомления о грозящем сбое. Причина этого заключается в том, что не существует общего формата ошибок устройств и не поддерживается программное обеспечение, управляющее обработкой ошибок.
WHEA предоставляет единый механизм обнаружения источника ошибки и формирования отчетов для устройств платформы, включая процессоры, память, кэши и такие шины, как PCI и PCI Express. Это достигается посредством реализации архитектуры, показанной на рис. 2, основой которой является интерфейс API ядра, к которому обращаются источники ошибок с отчетами о возникших ошибках. API требует предоставления информации об ошибках в общем формате и регистрирует ошибки с помощью подсистемы отслеживания событий для Windows (ETW) (информация о неустранимых ошибках регистрируется после перезагрузки).
Рис. 2 Инфраструктура WHEA для создания отчетов об ошибках
Подсистема ETW появилась в Windows 2000, и использование ETW в архитектуре WHEA облегчает производителям оборудования и поставщикам программного обеспечения разработку управляющих диагностикой устройств приложений, которые работают с событиями WHEA. При возникновении события, грозящего сбоем системы, WHEA гарантирует сохранение записи о неустранимой ошибке в файле аварийной копии памяти, чтобы администраторы могли определить основную причину сбоя.
Другой важной частью архитектуры WHEA является драйвер аппаратных ошибок, специфичных для платформы (PSHED), находящийся в библиотеке %Systemroot%\System32\Pshed.dll. Ядро скомпоновано с PSHED, и драйвер взаимодействует с оборудованием платформы и оборудованием с микропрограммным обеспечением, выполняя, по существу, роль транслирующего слоя между интерфейсом уведомлений об ошибках и интерфейсом API архитектуры WHEA, обеспечивающим отчеты об ошибках. Майкрософт поставляет PSHED для всех архитектур платформы (x86, x64, Itanium), а драйвер PSHED разработан по модели подключаемого модуля, чтобы производители и поставщики оборудования могли переопределять поведения по умолчанию на поведения, характерные для их платформ.
Наконец, в компоненты системы, взаимодействующие с другими источниками ошибок (включая драйверы устройств, слой абстрагирования оборудования (HAL) и ядро), можно внедрить обработчики ошибок оборудования низкого уровня (LLHEL), обрабатывающие состояние ошибки на начальном этапе. Задача обработчика LLHEL заключается в извлечении из устройства информации об ошибке, уведомлении драйвера PSHED, чтобы он мог собрать дополнительную информацию об ошибке, характерную для платформы, и затем обратиться к интерфейсу API архитектуры WHEA, обеспечивающему отчеты об ошибках.
Инструмент проверки драйверов
Driver Verifier, мощный инструмент для отслеживания драйверов устройств, содержащих ошибки, и сбойного оборудования, входит во все копии Windows, начиная с Windows 2000. Как правило, администраторы настраивают Driver Verifier (%Systemroot%\System32\Verifier.exe) на тщательный текущий контроль драйверов устройств, на которые падает подозрение в связи со сбоями системы. Driver Verifier перехватывает недопустимые операции драйверов, так что файл аварийной копии памяти указывает непосредственно на виновную сторону.
Недостаток предыдущих реализаций Driver Verifier заключался в том, что большая часть изменений конфигурации требует перезагрузки системы, что очевидно является нежелательным для производственного сервера. В реализации Driver Verifier в Windows Server 2008 эта процедура усовершенствована посредством устранения требования перезагрузки для большинства практичных проверок, что позволяет устранять неполадки на проблемном сервере без необходимости его перезагружать.
Кроме этого, в инструменте Driver Verifier появились три новых проверки, которые видны на рис. 3. Проверки безопасности гарантируют, что драйверы устройств устанавливают безопасные разрешения на объектах, которые они используют для взаимодействия с приложениями. Принудительное выполнение ожидающих запросов на операции ввода-вывода осуществляет проверку устойчивости драйвера к асинхронным операциями ввода-вывода, которые выполняются незамедлительно, а не после задержки. Проверки «Разные» выполняют поиск драйверов, которые освобождают используемые ресурсы не надлежащим образом, неправильно используют интерфейсы API инструментария WMI и пропускают дескрипторы ресурсов.
Рис. 3 В инструменте Driver Verifier установлены флажки для Windows Server 2008
Масштабируемость
Под масштабируемостью имеется в виду способность операционной системы или приложения эффективно использовать несколько процессоров и большие объемы памяти. В каждом выпуске Windows возможности масштабируемости расширяются за счет минимизации или устранения использования блокировок, сокращающих степень параллелизма в многопроцессорных средах. В Windows Server 2008 эта тенденция сохранена.
Относительно небольшое, но значимое усовершенствование внесено в код, реализующий завершение срока действия таймера, который более не запрашивает блокировки диспетчера — блокировки планировщика в рамках всей системы, используемой всеми низкоуровневыми операциями синхронизации. Результирующее сокращение непроизводительных издержек на синхронизацию ЦПУ позволяет системам серверов терминалов Windows Server 2008 поддерживать приблизительно на 30 процентов больше параллельно работающих пользователей, чем в среде Windows Server 2003.
К другим усовершенствованиям возможностей масштабирования в среде Windows Server 2008 относятся усовершенствования портов, новая реализация пула потоков, более эффективное использование оборудования с архитектурой NUMA и динамическое создание системных разделов.
Усовершенствованная обработка порта завершения ввода-вывода
Большинство серверных приложений Windows, включая IIS, SQL Server® и Exchange Server, для минимизации переключений между несколькими потоками выполнения при выполнении операций ввода-вывода опираются на интерфейс API синхронизации Windows, называемый портом завершения. Для этого сначала устанавливается соответствие между уведомлениями о прибытии новых запросов, например, клиентских подключений веб-сервера, и портом завершения и назначается пул потоков для ожидания уведомлений. По прибытии запроса Windows предусматривает поток, который затем, как правило, выполняет другие операции ввода-вывода, такие как чтение веб-страницы с диска и отправка ее клиенту для выполнения запроса.
Чтобы этот же поток мог вернуться к ожиданию дополнительных клиентских запросов как можно быстрее, поток инициирует операции ввода-вывода асинхронно и устанавливает соответствие между завершениями ввода-вывода и портом завершения. Затем поток возвращается к ожиданию на порте завершения, который планирует поток, когда прибывает новый запрос или завершается одна из операций ввода-вывода. Таким образом один и тот же поток остается активным на ЦПУ, попеременно переходя от обработки клиентских запросов к ожиданию на порте завершения и обратно.
Недостатком реализации порта завершения в предыдущих версиях Windows являлось то, что когда операция ввода-вывода завершалась, система ввода-вывода порождала поток, инициировавший операцию ввода-вывода для незамедлительного выполнения небольшой обработки завершения, независимо от того, какие еще действия выполнялись в это время. Если в это время были активны другие потоки, это зачастую приводило к тому, что планировщик отдавал предпочтение активному потоку, и контекст переключался на поток, инициировавший операцию.
Windows Server 2008 избегает таких переключений контекста, откладывая обработку завершения до следующего потока, чтобы продолжить ожидание на порте завершения, с которым связана операция ввода-вывода. Таким образом, даже если другой поток является следующим, который должен находиться в ожидании на порте завершения, он будет выполнять обработку завершения, прежде чем исполнять другой код, и планировщику не потребуется переключаться на поток, инициировавший ввод-вывод. Эта минимизация переключений контекста позволяет радикально расширить масштабируемость серверных приложений, работающих с большой нагрузкой.
Повышение эффективности пулов потоков
Написание приложений, использующих преимущества наличия нескольких процессоров, может оказаться сложной задачей, поэтому в Windows XP введены рабочие пулы потоков, инфраструктура и соответствующий интерфейс API, позволяющий абстрагироваться от подробных сведений о выполнении небольших порций работы процессорами. Приложение указывает рабочие элементы для API пула потоков, который затем выполняет их на одном из ряда потоков, создаваемых им для каждого ЦПУ системы и которыми он управляет.
Назначение пула потоков состоит в минимизации переключений контекста посредством использования одних и тех же потоков для выполнения нескольких рабочих элементов подряд. Если это невозможно вследствие того, что один из его потоков уже занят выполнением другой работы, он выполняет рабочий элемент с использованием другого потока на другом ЦПУ.
Реализация пула потоков в Windows Server 2008 повышает эффективность использования процессоров опосредованно, используя преимущества усовершенствований порта завершения, и непосредственно, оптимизируя управление потоками, чтобы рабочие потоки динамически поступали и уходили, по мере необходимости в них для манипулирования рабочей нагрузкой приложения. Далее, центральная часть инфраструктуры была переведена в режим ядра, что минимизирует количество обращений к системе, осуществляемых использующими API приложениями. Наконец, новый API облегчает приложениям выполнение некоторых операций, например вывод из очереди единиц работы во время закрытия приложения.
Оптимизации NUMA
В Windows Server 2003 появились оптимизации для компьютеров NUMA в планировщике потоков и диспетчере памяти, а в Windows Server 2008 оптимизации NUMA добавлены в диспетчер операций ввода-вывода и расширены оптимизации NUMA диспетчера памяти.
Системы NUMA, как правило, являются многопроцессорными системами, в которых память обладает различной задержкой, зависящей от того, который процессор обращается к ней (см. рис. 4). Память делится на узлы, при этом задержки между процессорами и узлами могут иметь разное значение, и каждый ЦПУ считается частью того узла, к которому он имеет самый быстрый доступ.
Рис. 4 Пример системы NUMA
Системы NUMA, в особенности имеющие более восьми ЦПУ, зачастую оказываются более рентабельными и производительными, чем системы с единообразным доступом к памяти. В то время как в системах с единообразным доступом к памяти память должна быть доступна всем ЦПУ в одинаковой мере, в системе NUMA можно реализовать высокоскоростное внутреннее взаимодействие для памяти, подключенной непосредственно к ЦПУ, и более дешевое взаимодействие с большой задержкой для процессоров и памяти, удаленных друг от друга.
Для эффективного масштабирования в системе NUMA операционная система или приложение должны иметь информацию о топологии узлов, чтобы вычисления выполнялись поблизости от памяти, содержащей участвующие в вычислениях данные и код. Например, планировщик Windows назначает каждому потоку так называемый идеальный процессор, представляющий собой ЦПУ, на котором планировщик всегда пытается выполнять поток. Такой подход повышает вероятность того, что данные, помещенные потоком в кэш ЦПУ, будут доступны потоку всякий раз при его выполнении.
В планировщике Windows Server 2003 эта концепция расширена. Узел, содержащий идеальный процессор, считается идеальным узлом потока, и планировщик пытается запланировать этот поток на другом ЦПУ идеального узла, если идеальный процессор занят выполнением другого потока. Диспетчер памяти в Windows Server 2003 также поддерживает концепцию NUMA и, по мере возможности, запрашивает выделение памяти для потока в памяти узла, на котором поток выполняется.
В Windows Server 2008 диспетчер памяти делит невыгружаемые буферы памяти ядра (память, используемая ядром и драйверами устройств для хранения данных, которая постоянно находится в ОЗУ) между узлами, чтобы эти участки памяти выделялись на узле, на котором инициировано выделение памяти. Системные записи таблицы страниц (PTE) выделяются на узле, инициирующем выделение, если для выделения памяти требуется новая страница таблицы страниц для удовлетворения потребности в памяти, вместо того, чтобы делать это на любом другом узле, как это происходит в среде Windows Server 2003.
В Windows Server 2003, когда поток распределяет память, диспетчер памяти отдает предпочтение узлу, на котором в момент выделения памяти выполняется поток. Если поток сразу же планируется на не идеальный узел, все распределения, выполняемые в это время, будут осуществляться на не идеальном узле. Поэтому, когда поток, в конечном счете, выполняется на своем идеальном узле, он будет не настолько близок, как это могло бы быть, к данным или коду, хранящимся в выделенной памяти.
Для разрешения этой проблемы диспетчер памяти в Windows Server 2008 отдает предпочтение идеальному узлу потока для всех выделение памяти для потока, даже если поток выполняется поблизости от другого узла. Кроме этого, диспетчер памяти автоматически определяет задержки между процессорами и узлами, поэтому, если на идеальном узле недостаточно памяти, диспетчер переходит к проверке узла, ближайшего к идеальному. Дополнительно, если поток ссылается на код или данные, диспетчер памяти перемещает страницы в свой список ожидания идеального узла потока.
Приложения, стремящиеся управлять местонахождением своих участков выделенной памяти, теперь могут использовать новые интерфейсы API памяти NUMA, что позволяет им указывать предпочтительный узел для выделения памяти, представления сопоставления файлов и объекты сопоставления файлов. Для выделения, связанного с сопоставлением файлов, диспетчер памяти проверяет, указывает ли операция сопоставления узел, затем проверяет, указан ли узел объектом сопоставления файлов, и, наконец, если ничего не остается делать, обращается к идеальному узлу потока.
До появления системы Windows Server 2008 прерывание и соответствующий отложенный вызов процедуры (DPC) для хранения или сетевых операций ввода-вывода мог выполняться на любом ЦПУ, включая процессоры с другого узла, а не того, на котором инициирован ввод-вывод. Это могло стать причиной того, что данные, считанные или записанные операцией ввода-вывод, окажутся в памяти другого узла, а не того, на котором был получен к ним доступ.
Чтобы избежать этого, система ввода-вывода операционной системы Windows Server 2008 направляет выполнение DPC на ЦПУ того узла, где был инициирован ввод-вывод, а системы, в которые входят устройства, поддерживающие формат MSI-X шины PCI (расширение стандарта MSI), могут расширить возможности размещения выполнения операций ввода-вывода с помощью драйверов устройств, которые используют преимущества интерфейсов API операционной системы Windows Server 2008 для направления прерывания ввода-вывода на процессор, инициировавший ввод-вывод.
Динамическое создание разделов
Одним из способов увеличения масштабируемости системы является поддержка ею динамического добавления ресурсов оборудования, например центральных процессоров и памяти. Эта же поддержка может увеличить также доступность системы, если такие ресурсы могут быть заменены без требования перезагрузки системы.
В Windows Server 2003 появилась возможность оперативного добавления памяти, что позволяет серверам с поддержкой динамической памяти использовать ОЗУ по мере ее добавления администратором. В Windows Server 2008 расширена поддержка динамической памяти, и допускается замена памяти.
Участки ОЗУ, в которых возрастает количество исправлений ECC (Error Correcting Code), подвержены риску полного отказа, поэтому на серверах с поддержкой оперативной замены операционная система может прозрачным образом переместить данные из сбойных банков памяти в замещающую их память. При этом сначала перемещаются данные, находящиеся под управлением операционной системы, затем устройства эффективно отключаются посредством перемещения их в состояние низкого энергопотребления, перемещаются оставшиеся в памяти данные, после чего возобновляется подача питания на устройства, чтобы они продолжили работу в обычном режиме.
Windows Server 2008 поддерживает также оперативное добавление и замещение процессоров. Для осуществления оперативного замещения оборудование должно поддерживать концепцию запасных ЦПУ, которые могут быть либо введены в рабочем режиме, либо добавлены динамически, когда существующий ЦПУ генерирует сигналы о сбое, что в настоящее время доступно только в самых современных системах. Планировщик Windows Server 2008 замедляет операции на сбойном ЦПУ и перемещает работу на замещающий процессор, после чего сбойный ЦПУ можно удалить и заменить новым запасным процессором.
В Windows Server 2008 поддержка оперативного добавления процессоров позволяет администраторам модернизировать вычислительные возможности сервера, избегая простоев системы. Однако планировщик и системы ввода-вывода обеспечат доступность нового ЦПУ только тем драйверам устройств и приложениям, которые запрашивают уведомление о появлении ЦПУ через новые интерфейсы API, поскольку некоторые приложения разработаны исходя из предоположения фиксированности числа ЦПУ в рамках сеанса загрузки. Например, приложение может выделить память для массива рабочих очередей, соответствующих каждому ЦПУ, при этом поток использует очередь, связанную с ЦПУ, на котором он выполняется. Если планировшик помещает один из потоков приложения на новый ЦПУ, этот поток будет пытаться сослаться на несуществующую очередь, что может привести к разрушению данных приложения и высокой верятности аварийного отказа приложения.
Серверные приложения Майкрософт, такие как SQL Server и Exchange Server, выдерживают добавление ЦПУ, так же, как и некоторые основные процессы Windows, включая системный процесс, процесс диспетчера сеансов (%SystemRoot%\System32\Smss.exe,) и процессы размещения универсальных служб (%Systemroot%\System32\Svchost.exe). Другие процессы также могут запрашивать посредством интерфейса Windows API уведомление о появлении нового ЦПУ. При появлении нового ЦПУ Windows уведомляет драйверы устройств о предстоящем появлении процессора, запускает ЦПУ, после чего уведомляет драйверы устройств и приложения, созданные с расчетом на использование преимуществ новых ЦПУ, чтобы они, если это небходимо, размещали структуры данных для отслеживания операций на новом ЦПУ.
Виртуализация машин
До появления Windows Server 2008 обеспечивающие виртуализацию продукты Майкрософт, включая Virtual Server 2005, реализовывались посредством виртуализации с размещением, как показано на рис. 5. В случае виртуализации с размещением виртуальные машины реализуются посредством монитора виртуальных машин (VMM), работающего наряду с основной операционной системой, как правило, в качестве драйвера устройств. VMM опирается на управление ресурсами и драйверы устройств основной операционной системы. Когда монитор выполняется в соответствии с графиком операционной системы, он распределяет интервалы времени ЦПУ между активными виртуальными машинами (VM).
Рис. 5 Виртуализация машин с размещением
Технология Hyper-V, ранее имевшая кодовое название «Viridian», реализуется с использованием виртуализации гипервизора. Гипервизор полностью управляет всеми аппаратными ресурсами, и даже операционная система Windows Server 2008, которая загружает систему и посредством которой осуществляется управление виртуальными машинами, работает, по существу, на виртуальной машине, как видно из рис. 6.
Рис. 6 Архитектура Hyper-V
Гипервизор может разделить систему на несколько VM и рассматривать загрузочный экземпляр Windows Server 2008 как главный или корневой раздел, предоставляя ему непосредственный доступ к таким устройствам, как диск, сетевые адаптеры и графический процессор. Гипервизор предполагает, что корневой раздел осуществляет управление питанием и реагирует на события, связанные с автоматическими конфигурируемым оборудованием. Он перехватывает операции ввода-вывода устройств, инициированные в дочерних разделах, и направляет их в корневой раздел, который для доступа к оборудованию использует стандартные драйверы устройств Windows Server 2008. Таким образом серверы, на которых работает Hyper-V, могут воспользоваться преимуществом, обеспечиваемым поддержкой устройств операционной системой Windows.
Если Windows Server 2008 настраивается для выполнения серверной роли Hyper-V, Windows для параметра hypervisorimagelaunchtypeboot Boot Configuration Database (BCD) задает значение auto и настраивает драйвер устройств, Hvboot.sys для запуска на начальном этапе процесса загрузки. Если настроен этот режим, Hvboot.sys готовит систему для виртуализации, после чего загружает в память либо %Systemroot%\System32\Hvax64.exe, либо %Systemroot%\System32\Hvix64.exe, в зависимости от того, реализует система расширения виртуализации AMD-V или Intel VT CPU соответственно.
После загрузки гипервизор использует расширения виртуализации, чтобы внедриться ниже уровня операционной системы Windows Server 2008. Приложения пользовательского режима используют уровень привилегий Ring 3 процессора x64, а код режима ядра работает с привилегиями Ring 0, поэтому гипервизор работает на концептуальном уровне привилегий Ring минус 1, поскольку он может управлять средой выполнения кода, работающего на уровне Ring 0.
Если консоль управления Hyper-V используется для создания или запуска дочернего раздела, она взаимодействует с гипервизором посредством драйвера %Systemroot%\System32\Drivers\Winhv.sys, который использует открыто документированный интерфейс API гипервызова для создания нового раздела с указанными объемом физической памяти и характеристиками выполнения. Служба VM (%Systemroot%\System32\Vmms.exe) из корневого раздела создает рабочий процесс VM (%Systemroot%\System32\Vmwp.exe) для каждого дочернего раздела с целью управления его состоянием.
Один из способов, которым Windows повышает эффективность операционных систем дочерних VM, состоит в реализации как в Windows Server 2008, так и в Windows Vista «просветлений», представляющих собой последовательности кода, которые активируются только если операционная система работает на гипервизоре, реализующем интерфейс API Майкрософт для гипервызова. Запрашивая напрямую службы гипервызова, дочерняя VM избегает дополнительного кода виртуализации, который потребовался бы, если бы гипервизору пришлось угадывать намерения дочерней операционной системы.
Например, гостевая операционная система, в которой не реализованы «просветления» для спин-блокировок, выполняющих низкоуровневую синхронизацию нескольких процессоров, попросту вошла бы в цикл ожидания спин-блокировки, чтобы быть освобожденной другим виртуальным процессором. Такое ожидание может захватить один из физических ЦПУ до тех пор, пока гипервизор не предусмотрит второй виртуальный процессор. В «просветленных» операционных системах код спин-блокировки, если в противном случае он вошел бы в цикл, уведомляет гипервизор посредством гипервызова чтобы гипервизор мог незамедлительно предусмотреть другой виртуальный процессор и сократить непроизводительное использование ЦПУ.
Другой способ, которым Windows Server 2008 повышает производительность VM, заключается в ускорении доступа VM к устройствам. Производительность повышается за счет установки в дочерней операционной системе набора компонентов под общим названием «Компоненты интеграции VM».
Если VM работает без установки компонентов интеграции, дочерняя операционная система настраивает драйверы для тех эмулируемых устройств, которые ей представляет гипервизор. Гипервизор должен вступить в игру, когда драйвер устройства пытается вступить во взаимодействие с аппаратным ресурсом, чтобы предоставить информацию корневому разделу, который выполняет операции ввода-вывода с помощью стандартных драйверов устройств Windows от имени операционной системы дочерней VM. Поскольку одна высокоуровневая операция ввода-вывода, например чтение с диска, может повлечь много отдельных обращений к оборудованию, это может вызвать много операций передачи, называемых перехватами, в гипервизор и корневой раздел.
В Windows Server 2008 перехваты минимизируются с помощью трех компонентов: драйвера шины виртуальной машины (%Systemroot%\System32\Drivers\Vmbus.sys), клиентов виртуальных служб (VSC) и поставщиков виртуальных служб (VSP). Если на VM с поддерживаемой операционной системой устанавливаются компоненты интеграции, VSC берут на себя роль драйверов устройств и используют службы драйвера Vmbus.sys в дочерней VM для отправки запросов на операции ввода-вывода высокого уровня драйверу шины виртуальной машины в корневом разделе, используя для этого гипервызов и службы гипервизора, совместно использующие память. В корневом разделе Vmbus.sys перенаправляет запрос соответствующему VSP, который затем инициирует запросы стандартных операций ввода-вывода Windows I/O посредством драйверов устройств корневого раздела.
Очевидно, что Windows Server 2008, в которой появилась виртуализация Hyper-V на основе гипервизора, играет решающую роль в стратегии Майкрософт по виртуализации машин. Для получения дополнительных сведений об этих и других компонентах см. следующее издание моей книги «Microsoft Windows Internals» (Внутренняя структура Microsoft Windows), публикация которого запланирована на этот год.
Автор: Марк Руссинович