Наик Дайлип - Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003

Компания Microsoft, создавая архитектуру группового ввода-вывода, преследовала несколько целей.

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

Динамическое обнаружение устройств и путей без применения статической конфигурации.

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

Предоставление универсальной технологии, которая позволяет производителям компьютеров и независимым производителям программного и аппаратного обеспечения добавлять такие возможности, как балансировка нагрузки или сохранение целостности данных. Тестовый модуль от Microsoft, связанный с определенным устройством (device- specific module – DSM), обеспечивает балансировку нагрузки, которая, впрочем, будет максимально эффективна при статическом использовании; например, для всего ввода-вывода на LUN 1 будет применяться первый путь, а для всего ввода-вывода на LUN 2 – второй путь.

Рис. 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, а не драйвером класса диска.