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

9.3 Обеспечение избыточной отказоустойчивости

9.3 Обеспечение избыточной отказоустойчивости

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

На рис. 9.8 показан сервер с несколькими адаптерами шины. Каждый адаптер подключен к коммутатору, а каждый коммутатор снабжен двойным подключением к устройствам хранения с двумя портами. Единственной точкой отказа на рис. 9.8 является сервер. Как уже отмечалось, создание кластера позволит избавиться от этой точки отказа. Тем не менее в этой главе рассматривается конфигурация с единственным сервером. Основное внимание стоит обратить на два адаптера шины, установленные на сервере, – подобную архитектуру можно использовать и для кластеров. Простой установки двух адаптеров шины на компьютере под управлением Windows NT недостаточно. Необходимо использовать специальное программное обеспечение, которое рассматривается более подробно в разделах 9.3.1 и 9.3.2.

Рис. 9.8. Отказоустойчивая конфигурация

Компания Microsoft сообщила о поддержке технологий группового ввода-вывода, защиты целостности данных и балансировки нагрузки в Windows 2000 и Windows. Server 2003. При этом предоставляется универсальная система, которую производители компьютеров и независимые поставщики аппаратного обеспечения должны настроить под конкретные особенности различных устройств. Производителю следует получить инструментарий разработки, который доступен при условии подписания договора о неразглашении. Конечный пользователь может получить готовую систему только от производителя, а не от Microsoft..5

Еще раз обратите внимание на рис. 9.8, демонстрирующий схему сервера под управлением Windows NT с установленными двухпортовыми адаптерами шины. Не усложняя ситуации, предположим, что каждый диск отформатирован как единый том. Основная идея такой конфигурации – наличие нескольких путей ввода-вывода между жесткими дисками и сервером, что позволяет добиться устойчивости к отказам. Для конфигурации, приведенной на рис. 9.8, можно рассмотреть иерархию объектов устройств, которые создаются в стеке драйверов подсистемы хранения Windows.

На рис. 9.9 представлено дерево объектов для конфигурации рис. 9.8. Обратите внимание на пары PDO-FDO (объект физического устройства-объект функционального устройства), которые позволяют использовать возможности определенного устройства (см. главу 1). Вспомните, что объекты физического устройства, кром)е всего прочего, предоставляют информацию, необходимую для использования устройства. Для устройств хранения эта информация может содержать идентификатор шины SCSI, идентификатор целевого устройства и LUN. Объект функционального устройства предоставляет сведения, необходимые для получения доступа к устройству. Для устройств хранения примером такой информации служат данные о системной организации диска.

В нижней части на рис. 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, создавая архитектуру группового ввода-вывода, преследовала несколько целей.

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

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

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

Предоставление универсальной технологии, которая позволяет производителям компьютеров и независимым производителям программного и аппаратного обеспечения добавлять такие возможности, как балансировка нагрузки или сохранение целостности данных. Тестовый модуль от 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, а не драйвером класса диска.

Файл 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.

Модуль 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.

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

При инициализации драйвер псевдонимы группового ввода-вывода начинает взаимодействие с драйвером фильтрации MPSPFLTR, который размещен над объектом функционального устройства SCSIPort (см. рис. 9.10), что позволяет создать псевдоустройство для каждого логического устройства, которое подключено к нескольким путям. Для каждого такого псевдоустройства драйвер псевдошины группового ввода-вывода предлагает модулям DSM принять или отвергнуть право владения этим устройством.

Для каждого запроса ввода-вывода драйвер псевдошины группового ввода-вывода обращается к модулю DSM через определенную процедуру. Модуль DSM имеет доступ к каждому пакету IRP и может инициировать в случае необходимости процедуру завершения пакета IRP. Для запросов управления устройством, например Reserve или Release, модуль DSM может перенаправлять ввод-вывод по всем, маршрутам к устройству. Обычные запросы ввода- вывода модуль DSM перенаправляет по любому из маршрутов ввода-вывода в зависимости от того, какая балансировка нагрузки проводится – динамическая или статическая. Если запрос ввода-вывода завершается ошибкой, драйвер псевдошины группового ввода-вывода в определенной точке входа вызывает модуль DSM, который может попытаться перенаправить ввод-вы- вод по другому маршруту, обеспечивая сохранение целостности данных.

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

Эти системы довольно успешно работают, однако со временем стали очевидными некоторые их недостатки.

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

Системы не поддерживают взаимодействия с системами других производителей. Иными словами, если определенный сервер Windows работает с системой от одного првизводителя, на тот же сервер Windows невозможно установить систему других производителей.

Компания ЕМС разработала технологию сохранения целостности данных и балансировки нагрузки для Windows NT. На рис. 9.11 показана соответствующая архитектура.

В отличие от других архитектур, в архитектуре ЕМС драйвер фильтрации размещается между диспетчером томов и драйвером класса порта SCSI- Port или RAID. Для каждого существующего логического тома перечисляется N логических томов, где N – число независимых маршрутов доступа к устройству.

Для каждого устройства, имеющего N независимых маршрутов доступа, Windows NT обнаружит N логических устройств. Если ввод-вывод будет осуществляться через все маршруты одновременно, данные могут быть повреждены. Таким образом, система PowerPath отключает N-1 таких устройств, доступ и управление вводом-выводом для которых будут невозможны. Утилита администрирования с графическим интерфейсом отображает одно активное устройство и N-1 устройств выделены серым цветом, которым отмечаются неактивные устройства. От администратора требуется серьезно продумать конфигурацию, особенно, если необходимо обеспечить безопасность путем ограничениячадаптеров шины, имеющих доступ к устройству. Подобную схему безопасности можно внедрить с помощью системы ЕМС Symmetrix, посредством которой администратор укажет имя WWN адаптеров шины, имеющих доступ к определенным LUN на компьютере с установленной ЕМС Symmetrix.

Администратор имеет возможность указать политику балансировки нагрузки. Ниже приводится описание возможных политик.

Запросы на ввод-вывод распределяются по всем маршрутам по очереди.

Следующий запрос ввода-вывода отправляется по тому маршруту, на котором в очереди размещено меньшее количество запросов.

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

Рис. 9.11. Архитектура EMC PowerPath

? Используется режим оптимизации EMC Symmetrix, при котором следующий запрос ввода-вывода отправляется по маршруту с наименьшим ожидаемым временем завершения.

Компания HP (Compaq) предлагает систему группового ввода-вывода SecurePath для Windows NT, которая поддерживает сохранение целостности данных и балансировку нагрузки. Реализации этой системы-для Windows NT 4.0 и Windows 2000 несколько различаются.

На рис. 9.12 показана архитектура HP (Compaq) SecurePath для Windows 2000. Архитектура включает в себя драйвер фильтрации блочного устройства хранения, который расположен над драйвером порта (SCSIPort или Storport) и под драйвером класса диска. Служба пользовательского режима и приложения пользовательского режима формируют оставшиеся фрагменты головоломки, которые принимают участие в администрировании и отправке уведомлений.

Рис. 9.12. Архитектура HP (Compaq) SecurePath для Windows 2000

В Windows NT 4.0 технология HP (Compaq) SecurePath требует использования драйвера класса диска, который создан компанией HP и называется HSZDisk (рис. 9.13). Кроме того, предоставляется и драйвер фильтрации.

В Windows 2000 сохранение целостности и балансировка нагрузки обеспечиваются драйвером фильтрации Raidisk от компании HP. В Windows 2000 драйвер класса диска, предоставленный компанией Microsoft, не заменяется другими драйверами. Драйвер Raidisk обеспечивает:

сохранение целостности данных;

балансировку нагрузки (для некластерного системного окружения);

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

проверку маршрута к томам хранилищ.

Служба пользовательского режима SecurePath для Windows NT предоставляет возможности по администрированию и взаимодействует с драйвером фильтрации SecurePath с помощью закрытых кодов управления вводом- выводом (IOCTL).

Рис. 9.13. Архитектура HP (Compaq) SecurePath для Windows NT 4.0

Эта технология обеспечивает динамическую балансировку нагрузки и автоматическое сохранение целостности данных ввода-вывода для Windows NT. Как показано на рис. 9.14, компания HP реализовала систему AutoPath с помощью драйвера фильтрации, размещенного между драйвером класса диска и драйвером порта.

Балансировка нагрузки AutoPath выполняется в соответствии с политикой, установленной администратором. Возможные политики перечислены ниже.

Круговой доступ (round-robin), в котором данные ввода-вывода распределяются по всем маршрутам.

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

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

Рис. 9.14. Архитектура AutoPath

Данные ввода-вывода отправляются на маршрут, который имеет наименьший объем данных, ожидающих ввода-вывода.

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

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