Рис. 9.10. Дерево объектов устройств для предоставления группового ввода- вывода
■ Предоставление метода, который позволит использовать до 32 маршрутов на один номер LUX и поддерживает технологии Fibre Channel/SCSI.
На рис. 9.10 показано подробное дерево устройств Windows NT с поддержкой группового ввода-вывода для конфигурации, представленной на рис. 9.9. Дерево драйверов устройств включает в себя различные драйверы фильтрации и связанные с ними объекты устройств, которые вместе формируют архитектуру группового ввода-вывода Microsoft.
Архитектура включает в себя четыре различных компонента.
Драйвер фильтрации верхнего уровня, который называется MPSPFLTR и предоставляется Microsoft.
Драйвер класса MPDEV, предоставляемый Microsoft.
Драйвер псевдошины МРЮ, предоставляемый Microsoft.
Модуль DSM, который должен предоставляться производителем, создающим и продающим систему. Этот производитель лицензирует инстру-
ментарий разработки МРЮ у компании Microsoft. Инструментарий разработки уже содержит перечисленные три драйвера и предоставляет всю необходимую информацию (включая заголовочные файлы и пример кода) для создания DSM.
Первое, что бросается в глаза на рис. 9.10, это два различных стека устройств: логический (слева) и физический (справа). Программное обеспечение МРЮ формирует мост между этими стеками устройств.
Любопытно отметить схожесть дерева устройств при использовании томов как базовых, так и динамических дисков (базовые и динамические диски рассматриваются в главе 6). Это неудивительно, так как тома являются логическими элементами, содержащими несколько LUN или фрагмент отдельного LUN, а инфраструктура МРЮ стремится связывать видимые LUN через несколько путей с одним LUN. Возможности диспетчера разделов при обработке разделов весьма напоминают функции драйвера МР- SPFLTR. Как первый, так и второй драйвер особое внимание уделяют пакету IRP_MN_QUERY_DEVICE_RELATIONSHIPS и передают подробную информацию об объектах соответствующим партнерам – диспетчеру томов в одном случае и драйверу псевдошины группового ввода-вывода МРЮ – в другом. Диспетчер разделов и драйвер MPSPFLTR принимают ответственность за информирование партнеров (диспетчера томов и драйвера псевдошины МРЮ) о событиях подсистем РпР и управления питанием.
Сравнивая рис. 9.9 и рис. 9.10, можно заметить, что МРЮ являет собой драйвер фильтрации верхнего уровня, размещенный над объектом функционального устройства адаптера. Еще одно различие состоит в паре PDO- FDO, создаваемой для драйвера псевдошины МРЮ подсистемой РпР и самим драйвером МРЮ. Обратите внимание на закрытый канал взаимодействия между драйвером MPSPFLTR и драйвером псевдошины МРЮ. Далее, в верхнем левом углу рис. 9.10, представлены два объекта физического устройства для псевдодисков, созданных драйвером шины МРЮ. Таким образом, драйвер шины МРЮ получает возможность обрабатывать ввод-вывод и, в свою очередь, вызывать DSM.
К каждому объекту физического устройства, созданному драйвером МРЮ, подключены два объекта DSM. Один активно используется, а второй показан в другом прямоугольнике, чтобы подчеркнуть факт сосуществования объектов DSM от разных производителей. Обратившись к правой части рис. 9.10, можно заметить, что четыре объекта физического устройства создаются обычным образом драйвером порта (SCSIPort или Storport). Но подключаемые к ним объекты функционального устройства создаются драйвером класса MPDEV, а не драйвером класса диска.
Файл Mpdev. sys представляет собой замену драйвера класса диска с некоторыми изменениями. Драйвер класса диска MPDEV может обрабатывать только запросы SCSI и не поддерживает функции пакетов IRP. Другими словами, драйвер MPDEV обрабатывает только ограниченное подмножество функций пакетов IRP, самой важной из которых является запрос IRP_MJ_ SCSI. Драйвер MPDEV не поддерживает базовые функции пакетов IRP, например пакеты чтения и записи (IRP_MJ_READ и IRP_MJ_WRITE). Это означает, что приложения пользовательского режима не могут получить доступ непосредственно к стеку физических устройств, так как имеют возможность отправлять только запросы управления вводом-выводом (IOCTL). Конечно, драйверы режима ядра могут отправлять драйверу MPDEV блоки команд SCSI (CDB), чем и занимается драйвер класса диска.
Таким образом, драйвер MPDEV может обрабатывать запросы из стека МРЮ (показанные штрих-пунктирной линией на рис. 9.10), так как эти запросы приходят от драйвера класса диска (расположенного над объектом физического устройства, созданного драйвером МРЮ), преобразующего пакеты IRP (пакеты чтения/записи) в блоки команд SCSI. Более того, компания Microsoft создала строгие списки управления доступом для обеспечения безопасности объектов устройств, Принадлежащих драйверу класса MPDEV.
9.3.1.1 Модуль DSM
Модуль DSM (Device-Specific Module) проектировался для предоставления важных функций, описанных далее.
Обработка инициализации, относящейся к конкретному устройству.
Предоставление функций, позволяющих выяснить, не являются ли на самом деле два LUN, к которым осуществляется доступ по разным путям, одним LUN. Для этого рекомендуется использовать встроенный идентификатор устройства хранения, а не программную метку носителя. Универсальный модуль DSM, предоставленный Microsoft, выполняет проверку с помощью страницы серийного номера (80h) или страницы идентификации устройства (83h), определенных в наборе команд SCSI. Поставщики устройств не ограничены использованием только этих двух механизмов.
Обработка специальных команд SCSI, в основном связанных с управлением устройствами и опросом их возможностей, например Read_ Capacity, Reserve, Release и Start_Stop_Unit, а также принятием решения об отправке этих команд по всем путям или только по одному.
Принятие решений о маршрутизации запросов ввода-вывода.
ш Обработка ошибок.
Обработка запросов подсистемы РпР и подсистемы управления питанием с помощью библиотечных функций, реализованных Microsoft в драйвере исевдошины группового ввода-вывода.
■ Обработка запросов управления, которые поступают к драйверу в виде пакетов IRP через интерфейс WMI, который рассматривался в главе 7. При получении такого запроса драйвер псевдошины группового ввода- вывода вызывает соответствующие процедуры DSM. Драйвер псевдошины группового ввода-вывода может самостоятельно находить и вызывать эти процедуры.
Модуль DSM внедряется с помощью инструментария МРЮ, который можно лицензировать у компании Microsoft. Модуль DSM используется в качестве устаревшего (legacy) драйвера, который экспортирует интерфейс для драйвера псевдошины МРIO.
9.3.1.2 Драйвер псевдошины группового ввода-вывода
Драйвер псевдошины группового ввода-вывода загружается обычным образом, в качестве элемента Windows NT, как только будет установлен соответствующий программный пакет поставщика устройства.
При инициализации драйвер псевдонимы группового ввода-вывода начинает взаимодействие с драйвером фильтрации MPSPFLTR, который размещен над объектом функционального устройства SCSIPort (см. рис. 9.10), что позволяет создать псевдоустройство для каждого логического устройства, которое подключено к нескольким путям. Для каждого такого псевдоустройства драйвер псевдошины группового ввода-вывода предлагает модулям DSM принять или отвергнуть право владения этим устройством.
Для каждого запроса ввода-вывода драйвер псевдошины группового ввода-вывода обращается к модулю DSM через определенную процедуру. Модуль DSM имеет доступ к каждому пакету IRP и может инициировать в случае необходимости процедуру завершения пакета IRP. Для запросов управления устройством, например Reserve или Release, модуль DSM может перенаправлять ввод-вывод по всем, маршрутам к устройству. Обычные запросы ввода- вывода модуль DSM перенаправляет по любому из маршрутов ввода-вывода в зависимости от того, какая балансировка нагрузки проводится – динамическая или статическая. Если запрос ввода-вывода завершается ошибкой, драйвер псевдошины группового ввода-вывода в определенной точке входа вызывает модуль DSM, который может попытаться перенаправить ввод-вы- вод по другому маршруту, обеспечивая сохранение целостности данных.
9.3.2 Существующие системы группового ввода-вывода
Несколько компаний предоставляют системы группового ввода-вывода, которые, как минимум, обеспечивают сохранение, а некоторые даже восстановление целостности данных, а также балансировку нагрузки.
Эти системы довольно успешно работают, однако со временем стали очевидными некоторые их недостатки.
Конфигурация может быть сложной и запутанной, так как системы не полностью интегрированы с подсистемой РпР, поэтому динамический поиск не обеспечивается.
