Серверные технологии хранения данных в среде Windows® 2000 Windows® Server 2003
Шрифт:
В нижней части на рис. 9.9 показано, что подсистема РпР находит шину PCI, создает для нее объект физического устройства и загружает драйвер шины PCI, который создает объект функционального устройства для шины и подключает его к объекту физического устройства. Далее перечисляются устройства, подключенные к шине PCI. В результате обнаруживаются два адаптера шины. Драйвер шины PCI создает два объекта физического устройства, по одному для каждого адаптера шины. Подсистема РпР обнаруживает драйвер и загружает SCSIPort или Storport вместе с драйвером мини-порта, предоставленным производителем. Драйвер SCSIPort или Storport создает объект функционального устройства для каждого адаптера и подключает его к соответствующим объектам физического устройства.
Рис. 9.9.
После этого драйвер SCSIPort или Storport начинает работать как драйве]) шины и перечисляет устройства, подключенные к шине SCSI. Поскольку к шине подключено два устройства, сообщается о двух (дисковых) устройствах. Кроме того, так как к системе подключено два адаптера шины SCSI и перечисление выполняется для каждого из них. каждый адаптер сообщит о двух устройствах. Таким образом, драйвер SCSIPort или Storport в этом случае «увидит» четыре дисковых устройства. Создаются объекты физического устройства для четырех дисков и загружается драйвер класса диска, который создает четыре объекта функционального устройства и подключает каждый объект к соответствующему объекту физического устройства. Без группового ввода-вывода перечисляются разделы объектов функционального устройства диска и для управления томами, существующими на этих разделах, загружается драйвер FtDisk или LDM. (Чтобы не усложнять обсуждение. предположим, что каждый диск состоит из одного раздела и каждый раздел содержит один том.)
Программные системы более высокого уровня получат сведения о четырех томах устройств хранения, тогда как в действительности существует только два тома. Предположим, что эти два тома отформатированы для NTFS.
Файловая система также получит данные о четырех томах, для которых будет произведена попытка запуска NTFS. Очевидно, что NTFS, работающая на томах H1L1 и H2L1 (см. рис. 9.9), окажется несинхронизированной. При этом обязательно будут перезаписываться данные каждой файловой системы, например данные в журнале изменений, и в результате том окажется поврежденным.
Несколько производителей разработали метод, который не только решает описанную проблему, но и предоставляет богатый набор дополнительных возможностей, например сохранение и восстановление целостности данных, а также балансировка нагрузки. Функция сохранения целостности (failover) автоматически перенаправляет ввод-вывод с неисправного пути на другой путь ввода-вывода. В свою очередь, функция восстановления целостности (failback) исправляет неисправный путь ввода-вывода и снова вводит его в строй. Балансировка нагрузки позволяет распределить ввод-вывод на все доступные пути по определенному алгоритму. В качестве алгоритма может применяться поочередное распределение ввода-вывода, распределение на основе загрузки пути, простое распределение по всем путям или другой способ. Технология компании Microsoft рассматривается далее, после чего приводится описание продуктов от других производителей.
Компания Microsoft, создавая архитектуру группового ввода-вывода, преследовала несколько целей.
Совместная работа с другими внедренными драйверами и архитектурами, включая РпР и управление питанием. На самом деле суть не просто в совместной работе, а в использовании уже существующей архитектуры, например когда уведомления устройств передаются с помощью базового механизма РпР.
Динамическое обнаружение устройств и путей без применения статической конфигурации.
Обеспечение совместного применения различных методов группового ввода-вывода от нескольких производителей. На данный момент это исключительно сложно (практически невозможно) реализовать.
Предоставление
Рис. 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.