Книга: Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003

1.3 Архитектура Windows NT

1.3 Архитектура Windows NT

Операционная система Windows NT проектировалась как модульная, многоуровневая архитектура, поддерживающая расширения за счет добавление новых функций. Архитектура позволяет добавлять поддержку новых устройств и новых возможностей, например шифрующей файловой системы (EFS). Архитектура системы позволяет добавлять поддержку приложений, которые основаны на других операционных системах, например OS/2 или POSIX. Конечно, обе эти системы более важны с исторической точки зрения, но они являются хорошим примером мЬдульной расширяемой архитектуры.

На рис. 1.2 показана высокоуровневая архитектура Windows NT. Как уже отмечалось во вступительном разделе, термин Windows NT используется для описания всех версий операционной системы Windows, основанных на технологии NT. В это семейство входят Windows NT 3. x, Windows NT 4.0, Windows 2000,' Windows XP и Windows Server 2003.

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

Рис. 1.2. Архитектура Windows NT

Режим ядра содержит все привилегированные процессы, которые выполняются на уровне 0 архитектуры Intel х86. Режим ядра Windows NT состоит из трех основных подсистем.

Уровень аппаратных абстракций?

Ядро Windows NT.

Выполняемый модуль Windows NT.

В следующих трех разделах эти компоненты рассматриваются более подробно.

Уровень аппаратных абстракций (Hardware Abstraction Layer – HAL) обеспечивает защиту данных за счет управления доступом к аппаратным ресурсам. Это единственный модуль операционной системы Windows NT, который содержит код, зависящий от аппаратного обеспечения (или от архитектуры процессора). Кроме того, для написания уровня аппаратных абстракций иногда применяется язык ассемблера. В целом уровень аппаратных абстракций предоставляет дополнительный уровень абстракции компонентам более

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

Интерфейс службы таймера, благодаря которому выполняемый модуль Windows NT абстрагируется от функций аппаратного обеспечения таймера нижнего уровня.

Поддержка ввода-вывода в контексте системной шины и прямого доступа к памяти (direct memory access – DMA). Уровень аппаратных абстракций выполняет трансляцию данных между внешней шиной и информацией об адресации Windows NT. Кроме того, предоставляется поддержка для информации о конфигурации шины.

Поддержка прерываний путем связывания (отображения) внешних прерываний с запросами прерываний (IRQ) Windows NT. Кроме того, предоставляется маскировка/демаскировка служб для прерываний.

Ядро Windows NT представляет собой следующий уровень после уровня аппаратных абстракций, который обеспечивает работу выполняемого модуля Windows NT (рассматривается в разделе 1.3.3) и других подсистем. Ядро системы выполняет следующие основные функции:

помощь в синхронизации данных;

планирование выполнения потоков и процессов;

управление прерываниями и исключениями;

восстановление системы после аварийных ситуаций, например после отказа питания.

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

1. Объекты-диспетчеры, которые позволяют управлять потоками и процессами и применяются для синхронизации различных потоков/процессов. В число объектов-диспетчеров входят мьютекс-флаги (mutex – это сокращение от «mutual exclusion», т.е. взаимное исключение), семафоры (semaphore) и таймеры (timer). Мьютекс-флаги являются объектами синхронизации и используются для синхронизации данных между двумя компонентами.

2. Объекты управления, например асинхронные вызовы процедур (asynchronous procedure calls – АРС) и процедуры обслуживания прерываний (interrupt service routines – ISR), которые рассматриваются более подробно в разделах 1.5.1 и 1.5.3.

Выполняемый модуль (Windows NT Executive) обеспечивает работу ключевых функций, включая программные интерфейсы приложений (API), которые позволяют потокам из пользовательского режима в Windows NT взаимодействовать с ядром Windows NT для запроса на предоставление услуг. Как и ядро Windows NT, выполняемый модуль не может быть выгружен из памяти. Модуль управляет несколькими операциями, включая ввод-вы- вод данных, поддержку работы системы безопасности, межпроцессное взаимодействие, управление памятью и процессами, поддержку интерфейса Plug and Play, управление питанием, файловыми системами, объектами и графическими устройствами. Весь выполняемый модуль Windows NT размещен в одном файле – ntoskrnl. exe. Для выполнения задач модуля создается лишь несколько потоков. Обычно системный процесс из пользовательского режима запрашивает запуск службы, и модуль будет выполняться в контексте запросившего процесса. Примером потока, который создается выполняемым модулем, может служить поток сброса страниц на диск.

Выполняемый модуль Windows NT, в свою очередь, содержит следующие компоненты:

• диспетчер объектов;

• монитор ссылок безопасности;

• диспетчер процессов;

• подсистема Plug and Play;

• диспетчер энергопитания;

• диспетчер виртуальной памяти;

• диспетчер кэша.

Диспетчер объектов (Object Manager) Windows NT предоставляет свои услуги другим компонентам Windows NT, включая непосредственно выполняемый модуль (элементом которого диспетчер и является). Диспетчер объектов предоставляет службы для именования, создания, удаления, манипулирования и совместного использования объектов. Он активно сотрудничает с монитором ссылок безопасности, чтобы обеспечить соответствующий доступ к определенным объектам только пользователям и процессам с достаточными разрешениями. Соответствующий означает, что предоставляется доступ определенного типа, например доступ только для чтения. Каждый объект, созданный диспетчером объектов, имеет связанный с ним список управления доступом (access control list – ACL). На самом деле этот список представляет собой группу объектов, которые указывают разрешения, явно или неявно предоставленные пользователю или группе; кроме того, в список управления доступом могут входить объекты, ограничивающие права доступа для данного пользователя или группы.

Диспетчер объектов назначает дескриптор каждому созданному объекту. При этом обеспечивается уникальность дескрипторов и предоставляется возможность преобразования дескриптора в ссылку на уникальный объект. Но клиенты диспетчера объектов используют дескриптор в виде «непрозрачного» маркера без внутренней структуры. К объектам, с которыми работает диспетчер, относятся файлы, каталоги, порты, процессы, потоки, семафоры и объекты событий.

Монитор ссылок безопасности (Security Reference Monitor) заведует проверкой доступа и протоколированием ресурсов. Проверка доступа выполняется на самом низком уровне, включая не только предоставление доступа, но и определение его типа, например доступ только для чтения или доступ для чтения и записи. Функциональность подсистемы безопасности обеспечивается объектно-ориентированной структурой Windows NT. При предоставлении доступа к объекту монитор ссылок безопасности сравнивает список управления доступом, который связан с объектом, с маркером (token) безопасности процесса перед тем, как предоставить или запретить доступ. Списки управления доступом бывают двух типов: явно или неявно разрешающие или запрещающие доступ. Монитор ссылок безопасности активно используется другими подсистемами выполняемого модуля Windows NT, например диспетчером объектов.

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

Диспетчер процессов (Process Manager) обеспечивает создание и удаление процессов и потоков, а также управление ими. Диспетчер не поддерживает иерархию компонентов; например, отношения между процессами вида «родитель-потомок» не отслеживаются. Эта работа ложится на компонент, который создал процесс. По аналогии представьте диспетчер файлов, который предоставляет возможность создания файла, однако внедрением этого файла в структуру каталогов должен заниматься пользователь диспетчера файлов. Диспетчер процессов пользуется услугами как диспетчера объектов, так и подсистемы безопасности. Для каждого запущенного процесса передается, как минимум, два вызова диспетчеру процессов: первый вызов для создания процесса, второй – для создания потока в пределах процесса, так как каждый процесс должен содержать хотя бы один поток.

На рис. 1.2 управление питанием и подсистема Plug and Play схематически размещены в едином прямоугольнике, что сделано для упрощения структуры диаграммы. На самом же деле это различные подсистемы, хотя и тесно взаимодействующие друг с другом.

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

корректное определение аппаратного обеспечения;

корректное определение динамического подключения или отключения аппаратного обеспечения;

выделение и настройка ресурсов для работы аппаратного обеспечения;

поиск и загрузка драйверов устройств;

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

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

Подсистема Plug and Play играет очень важную роль в обнаружении устройств, присвоении устройствам идентификаторов, инициализации и добавлении/удалении устройств. В частности, Plug and Play отвечает за генерацию пакета запроса ввода-вывода (I/O request packet – IRP), который называется IRP_MN_QUERY_DEVICE_RELATIONSHIPS и передается драйверам шины. Этот пакет запроса ввода-вывода в презентациях Microsoft называется QDR. Пакет QDR применяется для перечисления устройств и создания стека устройств. Драйверы фильтрации иногда создаются для отслеживания функций QDR и исправления создаваемого списка устройств. В главе б рассматривается диспетчер разделов (Partition Manager), который обеспечивает подобные возможности в качестве драйвера фильтрации.

Диспетчер энергопитания (Power Manager) играет важную роль в предоставлении энергосберегающих функций, таких, как снижение оборотов вращения жестких дисков, накопителей для компакт-дисков и DVD, а также отключение питания мониторов и видеоадаптеров. Очевидно, что управление питанием гораздо важнее для портативных компьютеров, чем для серверов, но даже для серверов управление питанием применяется при обслуживании устройств, поддерживающих «горячую» замену, и при управлении устройствами резервного питания. Диспетчер энергопитания предоставляет интерфейс API для приложений более высокого уровня.

Диспетчер виртуальной памяти (Virtual Memory Manager – VMM) предоставляет функции управления памятью, благодаря которым процессы могут использовать объем памяти, превышающий размер физической памяти, установленной на компьютере. Запросы приложений на выделение памяти регистрируются диспетчером виртуальной памяти. Если осталось недостаточно памяти, диспетчер виртуальной памяти переместит страницы памяти на жесткий диск, чтобы предоставить место для нового приложения. Если приложение стремится получить доступ к странице, которая отсутствует в физической памяти, диспетчер виртуальной памяти освобождает пространство в памяти перед перемещением страниц с диска в физическую оперативную память. Этот метод получил название подкачки страниц (paging).

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

В Windows NT 4.0 поддерживалось адресное пространство объемом 4 Гбайт, которое поровну распределялось между пользовательским режимом и режимом ядра. Верхние 2 Гбайт выделялись режиму ядра Windows NT, а нижние 2 Гбайт – пользовательскому режиму. В Windows 2000 Advanced Server параметры загрузки позволяют перераспределить адресное пространство, выделив 1 Гбайт режиму ядра и 3 Гбайт пользовательскому режиму. Приложения пользовательского режима следует переписать для использования дополнительного объема адресного пространства. Конечно, для 64-разрядной версии Windows NT подобного ограничения просто не существует.

Диспетчер виртуальной памяти предоставляет программные интерфейсы приложений для выделения и высвобождения памяти, а также для блокировки и разблокировки памяти. Функция блокировки памяти позволяет запретить выгрузку области памяти в файл подкачки. Эта функция зачастую ошибочно воспринимается в качестве запрета на изменение физического расположения участка памяти. Хоть это и справедливо для нынешних версий Windows NT, ситуация может измениться в будущих версиях Windows. Посредством описываемого API драйверы по мере необходимости запрашивают выгружаемую или невыгружаемую память.

Это неотъемлемый элемент подсистемы ввода-вывода, который работает в тесной связке с драйверами файловых систем и диспетчером виртуальной памяти. Диспетчер кэша Windows NT взаимодействует с файловой системой и ее драйверами. Подобный метод отличается от стратегии кэширования, свойственной Windows 95, которая предназначалась для взаимодействия непосредственно с дисковыми секторами. Диспетчер обслуживает все файловые системы, локальные и удаленные, с помощью единого кэша. Диспетчер кэша позволяет кэшировать несколько потоков данных из одного файла. Потоки данных относятся к возможностям файловой системы NT (NTFS) и рассматриваются в главе 6.

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

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

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

Предоставление асинхронного ввода-вывода. Синхронный ввод-вывод осуществляется, по сути, в виде асинхронного запроса ввода-вывода, пс!>сле которого следует блокирующее ожидание завершения операции ввода-вывода.

Поддержка нескольких файловых систем, в частности CDFS, NTFS и UDFS.

Предоставление модульной архитектуры, поддерживающей добавление новых файловых систем и устройств.

Предоставление устройствам (и их драйверам) возможности подключения и отключения «на лету», без Перезагрузки (эта функция реализована в Windows 2000 и более новых версиях Windows NT).

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

Защита ресурсов, которые совместно используются несколькими процессами.

Подсистема ввода-вывода имеет модульную структуру (как и все остальные компоненты Windows NT) и состоит из следующих компонентов:

программный интерфейс приложений ввода-вывода (I/O API);

диспетчер ввода-вывода;

драйверы файловых систем;

другие драйверы (например, драйверы клавиатуры и драйверы дисков).

Далее эти модули рассматриваются более подробно.

По сути, этот компонент включает функции диспетчера ввода-вывода, предназначенные для более высоких уровней Windows NT, а также компоненты режима ядра, выполняющие операции, связанные с диспетчером печати. Все имена функций программного интерфейса приложений ввода-вывода имеют вид IoXXXX, где ХХХХ – строка, после которой указывается список параметров. (Подробная информация приводится в программном инструментарии для разработки драйверов.) В качестве примера функций API можно привести:

интерфейс IoCreateDevice, предназначенный для создания новых объектов устройств (объекты устройств рассматриваются в разделе 1.4.2);

интерфейс IoCallDriver, предназначенный для отправки драйверу пакета запроса ввода-вывода (пакеты запроса ввода-вывода рассматриваются в разделе 1.4.3).

Это элемент выполняемого модуля Windows NT; свойственные ему функции перечислены ниже.

Создание пакетов. запроса ввода-вывода (IRP) и направление их соответствующему драйверу, а также перенаправление пакетов запроса ввода-вывода между драйверами.

Удаление и освобождение пакетов запроса ввода-вывода после завершения операции ввода-вывода.

Взаимодействие с диспетчером кэша и другими компонентами NT Executive.

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

Мониторинг загруженных файловых систем и их вызов по требованию.

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

Управление буферами для операций ввода-вывода.

Операционная система предоставляет функции файловых систем с помощью драйверов режима ядра. Система Windows NT поставляется вместе с такими файловыми системами:

NTFS (файловая система NT);

UDFS (универсальная дисковая файловая система);

CDFS (файловая система компакт-дисков);

FAT (таблица размещения файлов).

Драйверы сетевых файловых систем рассматриваются в главе 3. Драйверы файловых систем реализуются средствами инструментария разработки драйверов Windows NT (Windows NT DDK) и дополнительного программного продукта, который предлагается компанией Microsoft – Windows NT Installable File System Kit. Этот инструментарий содержит документацию для различных программных интерфейсов приложений, которые понадобятся при создании драйверов файловой системы, а также пример кода, предназначенного для реализации файловых систем FAT и UDFS.

Драйверы файловой системы аналогичны другим драйверам, поскольку взаимодействуют с диспетчером ввода-вывода и IRP. Драйверы файловой системы являются логическими, так как не взаимодействуют непосредственно с аппаратным обеспечением; например, файловая система не делает различия между дисками с интерфейсом SCSI и с интерфейсом АТА (иногда называемым IDE). Тем не менее драйверы файловой системы отличаются от других драйверов. Некоторые из этих отличий приведены ниже.

Драйверы файловой системы всегда вызываются в контексте потока, запрашивающего операцию ввода-вывода.

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

Драйверы файловой системы являются единственными драйверами, которые обеспечивают работу методов ввода-вывода на основе IRP. Подобный метод называется быстрым вводом-выводом (Fast I/O) и представляет собой несколько входных точек драйвера. Диспетчер ввода-вывода вызывает эти точки для выполнения операций ввода-вывода, поскольку данные могут быть кэшированы и поэтому быстро обработаны. Драйвер файловой системы может завершить вызов неудачно, если это необходимо, а диспетчер ввода-вывода просто повторит тот же запрос ввода- вывода с помощью обычного пакета IRP.

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

Поскольку эта книга посвящена корпоративным системам хранения данных, на рис. 1.2 графическая подсистема демонстрируется в режиме ядра, хотя некоторая область подсистемы также представлена и в пользовательском режиме. В Windows 2000 для повышения производительности значительный объем кода графической подсистемы был перемещен из пользовательского режима в режим ядра. В данном случае к понятию «графическая подсистема» относится весь программный код, предназначенный для обработки оконного интерфейса и поддерживающий видеоустройства, сканеры, принтеры и т.д.

Это наиболее важный компонент Windows NT, особенно для программистов. На основе программного интерфейса Win32 создаются другие подсистемы, такие, как POSIX.

Программный интерфейс приложений Win32 можно разделить на три категории.

1. Обработка оконного интерфейса и API для сообщений оконного интерфейса реализованы в виде динамически подключаемой библиотеки user32. dll. Эта библиотека подключается приложениями, использующими интерфейсы, которые предоставляются этим файлом. При этом несколько приложений во время работы задействуют только одну копию библиотеки.

2. Графический API реализован в виде динамически подключаемой библиотеки gdi32. dll. В версиях Windows NT до Windows 2000 библиотека gdi32. dll являлась клиентом, подключаемым к серверному процессу Win32 (рассматривается далее), так как соответствующие функции были реализованы в серверном процессе. А сервер Win32, в свою очередь, вызывал компонент режима ядра для графической подсистемы. В Windows 2000 библиотека gdi32. dll вызывает этот компонент без посредников.

3. Базовые API, например функции открытия файла (CreateFile), чтения файла (ReadFile) и записи файла (WriteFile), реализованы в динамически подключаемой библиотеке, которая называется ntdll.dll. При необходимости эта библиотека делает вызовы к выполняемому модулю Windows в режиме ядра. Для этого библиотека использует одно из 256 прерываний, поддерживаемых архитектурой Intel х86. В частности, используется прерывание 46 (десятичный номер 46, шестнадцатеричный – 0х2Е). Обработчик прерывания[2] идентифицирует как запрошенный API (выполнив поиск по таблице), так и передаваемые ему параметры. Если все параметры прошли проверку, обработчик вызывает соответствующую подсистему выполняемого модуля Windows для выполнения запрошенной операции.

Приложения, написанные на основе API Win32 и других механизмов поддержки, рассматриваются в документации SDK. В некотором смысле даже подсистема POSIX представляет собой инструмент, разработанный для поддержки приложений UNIX. Хотя подсистема POSIX в настоящий момент существенной роли уже не играет, она все еще служит хорошим примером модульной и расширяемой архитектуры Windows NT.

Оглавление книги