7.1 Общая информационная модель и стандарт WBEM

Протокол SNMP (Simple Network Management Protocol) представляет собой стабильную технологию управления, имеющую свои преимущества и недостатки. Он обеспечивает эффективный мониторинг систем, однако не подходит для моделирования взаимоотношений между ними и предоставления активных методов управления хранилищами.

Учитывая необходимость в разработке новой парадигмы управления хранилищами, в 1996 году появился промышленный стандарт WBEM (Web- Based Enterprise Management). Разработка стандарта Проводилась под наблюдением группы DMTF (Distributed Management Task Force, ранее известной как Desktop Management Task Force). В стандарте WBEM определена общая информационная модель (CIM), которая включает в себя, такие уже существующие стандарты, как SNMP и DMI (Desktop Management Interface).

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

базовая CIM;

CIM приложений;

CIM сети;

CIM QoS сети;

CIM пользователей;

CIM систем хранения данных.

Стоит отметить, что рабочая группа DMTF определила CIM в качестве модели, а не конкретной реализации. Для того чтобы сделать CIM более привлекательной и обеспечить межплатформенную совместимость в гетерогенном окружении, рабочая группа DMTF разработала метод, с помощью которого гетерогенные системы могут обмениваться управляющей информацией по протоколу HTTP, применяя для хранения этих данных документы XML.

Модель CIM все еще развивается и, без сомнений, приобретет большую популярность в ближайшем будущем, особенно после недавних демонстраций некоторыми поставщиками на конференции Storage Networking World в марте 2002 года. Основная проблема реализации CIM состоит в том, что поставщикам приложений управления и аппаратных систем приходится действовать методом проб и ошибок. Поставщики аппаратного обеспечения не имеют ясного представления о том, какой инструментарий должен быть разработан, а поставщики приложений управления не знают, каких классов и инструментария стоит ожидать, чтобы все возможности были доступны постоянно, а не только в отдельных случаях (в зависимости от производителя), Тем не менее через некоторое время эта проблем будет решена.

 

7.2 Интерфейс WMI

Как уже отмечалось, модель CIM определена в рабочей группе DMTF и принята к использованию ассоциацией SNIA. Интерфейс WMI представляет собой реализацию модели CIM от Microsoft. Другими словами, WMI – это «CIM для Windows».

Интерфейс WMI был разработан для режима ядра и пользовательского режима. Операционная система Windows NT 4.0 SP6 поставлялась с интерфейсом WMI только для пользовательского режима. В Windows 2000, Windows ХР и Windows Server 2003 интерфейс WMI реализован как в режиме ядра, так и в пользовательском режиме.

Интерфейс WMI имеет трехуровневую архитектуру (рис. 7.1).

Уровень приложений WMI.

Уровень служб WMI.

Уровень поставщиков WMI.

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

Далее следует уровень службы WMI, который включает в себя единственный компонент – собственно службу WMI. Эта служба поставляется в составе Windows NT и представляет собой реализацию схемы, основанной на модели CIM. Иногда службу WMI называют объектным диспетчером CIM, или

Рис. 7.1. Архитектура WMI

CIMOM (CIM Object Manager). Служба WMI предоставляет единый интерфейс для приложений управления. Источник информации и тип приложения управления не имеют значения. Другими словами, служба WMI осуществляет операции мультиплексирования и демультиплексирования запросов между приложениями и различными поставщиками. Кроме того, служба предоставляет интерфейс сценариев WMI, который позволяет с помощью любого языка сценариев, поддерживаемого интерфейсом Windows Scripting Host (Visual Basic, JScript, VBScript), получать доступ к объектам службы WMI.

Последним в иерархии представлен уровень поставщиков WMI. На этом уровне находятся различные поставщики WMI: одни из них созданы компанией Microsoft, другие предоставлены сторонними производителями. Поставщики WMI создаются с помощью набора WMI SDK, который входит в пакет Platform SDK и включает в себя обычные динамически подключаемые библиотеки пользовательского режима. Компания Microsoft создала большое количество поставщиков WMI. Производители компьютеров, программного и аппаратного обеспечения также создают различных поставщиков. Например, производитель компьютеров может создать поставщика WMI, который позволяет наблюдать за различными параметрами внутри корпуса сервера, например за температурой и скоростью вращения вентиляторов. Такой поставщик WMI может даже подавать сигнал тревоги, когда открывается корпус сервера.

Многие поставщики WMI от Microsoft поддерживают управление приложениями пользовательского уровня и службами. Особое значение имеет поставщик WDM (Windows Driver Model), который позволяет предоставлять события и данные драйверов режима ядра пользовательским приложениям. Программный код режима ядра и драйвера находится под управлением кода WMI, однако от разработчиков драйверов создание поставщика WMI не требуется.

Расширение WMI для WDM предоставляет методы публикации информации и передачи событий от драйверов режима ядра. WMI может быть реализован в виде драйвера, который получает пакет запроса ввода-вывода (IRP). Кроме того, интерфейс WMI может быть реализован в виде драйвера мини- портов SCSI, Storport или NDIS. В каждом из этих случаев драйвер порта, предоставленный компанией Microsoft, выполнит необходимую трансляцию данных между пакетом IRP и интерфейсом мини-порта. Компания Microsoft реализовала интерфейс WMI в различных драйверах классов и портов. Производители также могут добавлять возможности WMI в драйверы собственных устройств. WMI реализуется в драйверах с помощью набора Windows Driver Development Kit. Интерфейс WMI внедряет новую функцию с помощью пакета IRP_MJ_SYSTEMCONTROL и позволяет управлять параметрами устройства.

Интерфейс WMI предоставляет массу возможностей для приложений управления. Например, приложение управления может зарегистрироваться в WMI для получения уведомлений в описанных ниже ситуациях.

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

Создание нового экземпляра управляемого объекта.

Удаление экземпляра управляемого объекта.

Удовлетворение сложного условия (например, условий 1 и 2, но не условия 3). Обратите внимание, что контроль за условиями могут обеспечивать различные поставщики. Более того, запросы проверки сложных условий встроены в язык, который называется WMI Query Language (WQL); его синтаксис напоминает SQL. Язык WQL позволяет опрашивать управляемые объекты, однако не модифицировать их.

Возможность расширения управляемого объекта путем создания поставщика.

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

Компания Microsoft широко использует интерфейс WMI для управления подсистемами хранения и приложениями. Программы Microsoft Exchange 2000 и SQL Server 2000 находятся под управлением поставщиков WMI, специально созданных для этой цели. Управление дисками и интерфейсом iSCSI также являются примером использования интерфейса WMI.

 

7.3 Виртуализация хранилищ данных

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

Виртуализация хранилищ предоставляет возможность определения функциональных характеристик и характеристик приложений для интересующего вас хранилища, независимо от параметров аппаратного обеспечения (например, его типа, поставщика и размещения). Представьте, например, что администратор указывает на необходимость использовать том размером 80 Гбайт для хранения резервной копии данных, но, к сожалению, максимальный объем дискового пространства составляет только 40 Гбайт. Для решения этой проблемы диспетчер томов может преобразовать два отдельных' физических диска в один большой том. Учитывая рост внимания к/общей стоимости владения (ТСО) и увеличение запросов к объему подсистемы хранения, виртуализация хранилища предоставляет возможность эффективного управления ресурсами хранилищ. Кроме того, сокращается общая стоимость владения хранилищами.

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

7.3.1 Серверная (узловая) виртуализация

Виртуализация на уровне узла существует уже довольно длительное время, хотя обычно она имеет другие названия, в частности LVM (Logical Volume Manager – диспетчер логического тома) и HSM (Hierarchical Storage Management – управление иерархическим хранилищем). На уровне диспетчера тома (например, LDM в Windows 2000) виртуализация осуществляется следующим образом:

преобразование недорогих ненадежных дисков в надежный диск с помощью программного обеспечения RAID;

предоставление больших томов с помощью виртуализации дисков меньшего объема.

Диспетчер LDM подробно рассматривается в главе 6.

Технология HSM предоставляет метод доступа к файлам вне зависимости от их расположения – на диске или на сменном носителе, например магнитной ленте. Служба HSM, предоставляемая Microsoft, рассматривается в разделе 7.8.

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

7.3.2 Виртуализация на уровне аппаратного обеспечения хранилища

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

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

7.3.3 Виртуализация в сетях хранения

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

7.3.4 Внутриполосная виртуализация

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

Преимущество внутриполосной виртуализации (in-band visualization) состоит в обеспечении работы при различных методах ввода-вывода, включая доступ к хранилищу на уровнях файлов и блоков. При этом предоставляется единственная точка управления.

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

7.3.5 Внеполосная виртуализация

При внеполосной виртуализации (out-of-band visualization) пути передачи данных и управляющей информации разделены. Внеполосную виртуализацию можно сравнить с асимметричной кластерной файловой системой, в которой сервер метаданных управляет доступом к метаданным файловой системы. Сервер виртуализации обычно взаимодействует с клиентами виртуализации, которые представляют собой программное обеспечение, работающее на узле или на устройствах в сети хранения, например коммутаторах связной архитектуры или адаптерах шины.

Преимущество состоит в ускорении доступа к данным, так как данные не проходят через дополнительное устройство. Кроме того, в этой схеме присутствует единственная точка управления.

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

обеспечение избыточности;

предоставление необходимой производительности;

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

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

Виртуализация блока также доступна уже длительное время. Примером такой технологии на платформе Windows NT служит драйвер LDM (Logical Disk Manager) или FtDisk, которые предоставляют функции массивов RAID и возможность создания единых томов с объемом, превышающим объем каждого жесткого диска в отдельности.

Виртуализация файлов заключается в добавлении уровня абстракции для параметров и расположения файлов и каталогов. В качестве примера можно указать службу HSM (Hierarchical Storage Management).

Технология виртуализации файловой системы добавляет уровень абстракции, размещенный над несколькими файловыми системами. Пример – распределенная файловая система (DFS) в Windows NT, которая рассматривается в главе 3.

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

 

7.4 Технология виртуализации хранилища от компании Microsoft

Возможности Windows Server 2003 и сведения о будущих версиях Windows свидетельствуют о тенденции к увеличению количества функций, связанных с хранилищами данных на платформе Windows NT. Виртуализация на уровне тома (FtDisk и LDM) и на уровне файловой системы (HSM и DFS) доступна в Windows NT уже довольно давно. Компания Microsoft продолжает создавать более развитую инфраструктуру управления хранилищами в рамках среды Windows NT. Кроме всего прочего, эта инфраструктура позволит администратору без проблем автоматизировать выполнение рутинных операций.

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

Создание тома (может потребоваться управление дисками или массивами RAID).

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

Создание моментального снимка.

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

Резервное копирование.

Освобождение тома и его перемещение обратно в пул свободных ресурсов хранилища.

Основная цель заключается в предоставлении эффективных средств управления на каждом из этапов, перечисленных выше. Для управления может использоваться как интерфейс командной строки (автоматическое выполнение операций), так и графический интерфейс приложения управления. На каждом этапе упор делается на функциональные, а не физические аспекты. Поэтому этап создания тома должен описываться следующим образом: «создать том, размером 50 Гбайт, RAID 5 и т.д.», а не «создать Е: 50 Гбайт». Для достижения этого уровня компания Microsoft предоставляет службу виртуализации диска в составе Windows Server 2003. Служба виртуализации для связной архитектуры будет представлена в следующих версиях Windows.

7.4.1 Служба виртуализации дисков

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

Рис. 7.2. Служба виртуального диска

(узловой, аппаратное обеспечение, массив RAID и т.д.) значения не имеет. В частности, служба виртуализации дисков предоставляет следующие возможности:

ш создание номеров LUN по характеристикам;

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

управление маршрутами.

Как показано на рис. 7.2, служба виртуального диска имеет трехуровневую модель, состоящую из приложений, службы виртуализации дисков и нескольких поставщиков, одни из которых разработаны компанией Microsoft, в то время как другие – независимыми компаниями.

Программные поставщики отвечают за управление томами и реализованы в виде серверов СОМ. Эти поставщики обеспечивают работу функций, указанных в наборе SDK для службы виртуальных дисков, который доступен в Microsoft при условии подписания договора о неразглашении. Функции отвечают за создание объектов СОМ, предоставляющих том, диск и самого поставщика, а также за создание других объектов. Программный поставщик экспортирует информацию о состоянии и работоспособности объектов, которыми он управляет, а также отправляет уведомления. Служба виртуального диска получает все уведомления; затем проводится фильтрация и отправка уведомлений приложениям, которые зарегистрировались для получения соответствующих предупреждений. Служба виртуального диска по мере необходимости (например, при расширении или сокращении размера тома) координирует свои действия с файловой системой.

Аппаратные поставщики отвечают за управление номерами LUN. Как и программные поставщики, они реализованы в виде серверов СОМ, поддерживающих функции, указанные в наборе SDK службы виртуального диска. Аппаратные поставщики обеспечивают работу функций, относящихся к LUN, дискам, маскировке LUN и т.д., а также отправляют уведомления.

Компания Microsoft предоставляет три поставщика, поэтому от производителей RAID-систем требуется создание собственных поставщиков.

Поставщик Storport, который относится к аппаратному обеспечению RAID, подключаемому непосредственно к узлу (это локальное аппаратное обеспечение, а не'аппаратное обеспечение SAN).

Поставщик, который управляет базовыми дисками (см. главу б).

Поставщик, который уцравляет динамическими дисками (см. главу 6).

Служба виртуального диска имеет немаловажное значение для различных приложений управления хранилищем, включая утилиты управления дисками, резервного копирования, зеркального отражения и создания моментальных снимков. Кроме того, Microsoft будет создавать новые приложения управления и утилиты, использующие функции службы виртуального диска. Обратите внимание: Microsoft размещает важные утилиты и инструменты в комплекте Resource Kit, а не в составе самой операционной системы. Примером служит, например, утилита linkd. exe для создания ссылок. Таким образом, читателю стоит тщательно просмотреть утилиты, входящие в набор Resource Kit для Windows Server 2003.

Служба виртуального диска должна запускаться на нескольких серверах Windows NT. Программные поставщики запускаются только на тех серверах, на которых смонтированы соответствующие тома. Приложение управления, которое использует службу виртуального диска, может работать удаленно или на том же компьютере. Служба виртуального диска будет работать в установочной среде OEM (она носит название WinPE или Windows NT Lite). В WinPE компьютер загружается с минимальной конфигурацией Windows NT и устанавливает Windows NT в другой конфигурации на этот же компьютер или выполняет последовательность тестов. Минимальная конфигурация может включать в себя службу виртуального диска и поставщика базовых дисков.

7.4.2 Служба виртуализации для связной архитектуры

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

Рис. 7.3. Служба виртуализации связной архитектуры

Обратите внимание: служба виртуализации связной архитектуры не внедрена в Windows Server 2003 по умолчанию. По сути, эта служба может вообще не предоставляться в составе операционной системы. Слишком мало дополнительной информации, разрешенной к разглашению, предоставлено по этому вопросу. Кроме того, интересно заметить, что многие производители, включая одного известного производителя коммутаторов, объявили о принятии модели CIM, разработанной рабочей группой DTMF и ассоциацией SNIA. Можно сделать логический вывод, что API управления коммутаторами, предоставленные производителем, будут не так важны, как методы и объекты, предоставленные с помощью CIM. Что из этого получится и как будет развиваться служба виртуализации связной архитектуры, может сказать только время (и, возможно, одна из следующих редакций этой книги).

На рис. 7.3 показана приблизительная попытка определения службы вир* туализации связной архитектуры. Служба виртуализации предоставляет API для приложений управления и получает информацию о связной архитектуре от поставщика WMI.

 

7.5 Программные интерфейсы приложений для адаптеров шины

В сетях хранения данных адаптеры шины обеспечивают физическое подключение между сервером и другими элементами сети хранения, включая

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

Ассоциация SNIA определила API в виде библиотеки на языке С, который позволяет приложениям управления хранилищами контролировать адаптеры шины Fibre Channel. Приложения управления могут реализовать единый интерфейс, не зависящий от производителя адаптера шины или типа последнего. Достаточно, чтобы производитель адаптера шины поддерживал утвержденный SNIA программный интерфейс приложений для адаптеров шины. В этот интерфейс входит поддержка опроса и установки параметров управления адаптером шины, а также анализ производительности адаптера. В частности, API адаптера шины предоставляет перечисленные ниже элементы.

Атрибуты адаптера шины, например модель, название производителя и имя WWN (уникальное 64-разрядное имя, назначаемое производителем и зарегистрированное в IEEE, который назначает диапазон имен определенному производителю).

Атрибуты порта, например идентификатор порта (24-разрядное число, которое уникально для каждого узла), тип порта, текущий статус порта и максимальный размер кадра, который поддерживается портом.

Атрибуты протокола порта Fibre Channel, например номер шины SCSI или целевой идентификатор SCSI.

Статистика порта, например количество принятых и отправленных кадров, время с момента последнего сброса данных статистики и возникшие ошибки (причина и их количество).

Управляющая информация FC-3 (третий функциональный уровень Fibre Channel), например имя WWN или идентификатор порта; следует отметить, что API позволяет приложению управления опрашивать такие службы Fibre Channel, как сервер имен. Кроме того, API поддерживает назначение информации об узле, например имени WWN и идентификатора.

Хотя компания Microsoft и члены ассоциации SNIA поддерживают программный интерфейс приложений адаптера шины, эта поддержка реализуется по-разному. Архитектура, принятая ассоциацией SNIA, включает в себя три компонента (рис. 7.4).

1. Универсальная динамически подключаемая библиотека API адаптера шины, которая поддерживается ассоциацией SNIA. Эта библиотека предоставляет стандартный интерфейс для приложений управления; на нижнем уровне библиотека связывается с динамически подключаемыми библиотеками, предоставленными производителями.

Рис. 7.4. Программный интерфейс приложений для адаптера шины от ассоциации SNIA

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

Драйвер адаптера шины, предоставленный производителем.

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

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

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

Тестирование и сертификация драйверов от производителя, использующих закрытые вызовы управления вводом-выводом, является исключительно сложным процессом; например, как проверить, что некорректные параметры вызова управления вводом-выводом не приведут к переполнению буфера?

Архитектура на первый взгляд выглядит расширяемой, но при более детальном рассмотрении можно понять, что производители адаптеров шины всегда будут «догонять» разработчиков приложении управления, добавляя код, который работает с расширениями, характерными для определенного производителя.

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

Компания Microsoft предлагает несколько иной метод (рис. 7.5) и подразумевает применение описанных ниже компонентов.

Универсальная динамически подключаемая библиотека API для адаптера шины, которая поддерживается компанией Microsoft,. Эта библиотека предоставляет интерфейс, определенный ассоциацией SNIA, для приложений управления более высокого уровня. На более низком уровне библиотека подключается к интерфейсу WMI, представляющему собой

реализацию модели CIM от Microsoft. (Как уже отмечалось, CIM – это объектно-ориентированная модель управления, принятая ассоциацией SNIA и рабочей группой DMTF.) Библиотека также будет проводить преобразование данных между API адаптера шины, отвечающего спецификации SNIA и интерфейсом WMI.

Драйвер устройства для адайтера шины, созданный производителем; драйвер использует WMI и делает интерфейс управления/настройки доступным в репозитории WMI. Поскольку WMI представляет собой двунаправленный интерфейс, драйвер реализует функции пакетов IRP для интерфейса WMI, которые позволяют приложению управления устанавливать конфигурационные параметры драйвера. Обратите внимание, что от производителя все равно требуется создание драйвера, в который будет добавлен код поддержки WMI.

Метод компании Microsoft имеет ряд преимуществ.

Все представленные интерфейсы стандартизированы, тогда как в архитектуре ассоциации SNIA интерфейс между универсальной библиотекой API адаптера шины и библиотекой производителя закрыт и определяется производителем. Подход компании Microsoft соответствует принятой модели CIM.

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

Самым существенным преимуществом является возможность использования модели CIM или API адаптера шины от SNIA. Программа, использующая API адаптера шины от SNIA, может работать без изменений, поскольку код WMI в драйвере и динамически подключаемая библиотека от Microsoft выполняют преобразование данных WMI в данные API адаптера шины от SNIA.

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

Приложения управления не интересуются (и не должны интересоваться), каким образом код нижнего уровня получает необходимую информацию. Пока приложение управления использует API адаптера шины от SNIA (как рекомендуется Microsoft), код на нижнем уровне может получать необходимую информацию как от динамически подключаемой библиотеки SNIA, так и от библиотеки WMI.. В любом случае приложение управления осуществляет запись данных на базе единого интерфейса.

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

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

Зонирование (см. главу 4) – это еще один способ обеспечения безопасности в сетях хранения данных.

 

7.8 Управление иерархическим хранилищем

Службу HSM (Hierarchical Storage Management) иногда путают с продуктами для основного и вспомогательного резервного копирования, которые помогают отслеживать размещение файла на архивной магнитной ленте или даже ^состояние файла в архиве. Хотя HSM и резервное копирование переносят файлы и данные между основным носителем (обычно это жесткие диски) и вторичным носителем (магнитная лента или оптический носитель), эти технологии существенно различаются. При использовании HSM файл выглядит неизменным. В некоторых случаях файл может иметь специальные атрибуты, которые указывают на увеличение времени доступа. В свою очередь, программы резервного копирования не воспринимают ранее скопированный и удаленный файл.

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

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

7.8.1 Модуль RSS

Операционная система Windows 2000 Server содержит модуль RSS (Remote Storage Services), который предоставляет функции управления иерархическим хранилищем (HSM). Служба RSS отслеживает свободное пространство и статистику обращения к файлам на управляемых томах. Администратор хранилища устанавливает критерии минимального объема свободного дискового пространства, а также срок, в течение которого к файлу не должны обращаться, чтобы файл попал на неинтерактивный носитель, и т.д.

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

Файлы для перемещения выбираются на основе политик, установленных администратором. Эти политики описывают:

объем свЬбодного дискового пространства, который должен быть доступен;

последнюю дату и время доступа к файлу;

размер файла;

определенные администратором правила включения и исключения файлов и каталогов.

Модуль RSS интегрируется в Windows 2000 следующим образом:

графический интерфейс программы Проводник Windows отмечает перемещенные файлы специальной пиктограммой;

в окне командной строки размер перемещенных файлов указывается в скобках;

приложение резервного копирования Windows NT координирует свои действия с модулем RSS; при резервном копировании файл открывается с параметром FILE_OPEN_NO_RECALL с помощью функции CreateFile, что позволяет обеспечить резервное копирование файла без перемещения файла обратно на диск;

задания модуля RSS передаются планировщику Windows NT, и расписанием заданий модуля RSS можно управлять, как расписанием остальных заданий;

ш служба индексации Windows 2000 распознает отсутствие изменений в файле, даже если файл был перемещен с диска в удаленное хранилище;

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

Модуль RSS работает с файлами, находящимися в одном из трех состояний.

Обычный файл, который находится на жестком диске.

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

Перемещенный файл, неименованный поток данных которого перемещен на неинтерактивный носитель и удален с диска; файл отмечен как разреженный и имеет установленный атрибут FILE_ATTRIBUTE_OFFLINE. Точка повторной обработки файла устанавливается со специальным тегом, который называется IO_REPARSE_TAG_HSM.

На рис. 7.6 представлена архитектура модуля RSS. Этот модуль состоит из нескольких компонентов пользовательского режима и режима ядра, которые рассматриваются далее.

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

Рис. 7.6. Архитектура RSS

При доступе к перемещенному файлу с помощью функции CreateFile с параметром FILE_OPEN_NO_RECALL пакеты IRP обрабатываются подобным образом, но файл не перемещается с магнитной ленты на диск. Данные восстанавливаются с ленты и передаются приложению без записи на диск. Обратите внимание: Windows 2000 поддерживает одновременное перемещение только одного файла с удаленного хранилища на магнитную ленту. Это справедливо даже при наличии нескольких накопителей удаленного хранилища, когда допуск к обрабатываемым файлам осуществляется по двум путям, а сами файлы расположены на двух различных носителях в двух разных накопителях.

Ядро RSS работает в качестве клиента RSM (Removable Storage Management), использующего RSM для управления носителем. Для хранения подробной информации о носителе ядро RSS использует базу данных.

Агент файловой системы RSS отвечает за периодическое сканирование управляемых томов NTFS и подготовку списка файлов, которые должны

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

Как только свободное дисковое пространство становится меньше определенного граничного значения, установленного администратором, запускается автоматическое задание, запланированное агентом файловой системы RSS. Агент удаляет потоки данных файлов, которые были предварительно перемещены (переводит файл из предварительно перемещенного состояния в полностью перемещенное состояние). Перед окончательным перемещением агент файловой системы проверяет, не изменились ли файлы с момента предварительного перемещения. Эта проверка выполняется с помощью механизма журнала USN (см. главу 6).

Служба RSS не устанавливается по умолчанию, а предоставляется вместе с утилитой управления с графическим интерфейсом, которая поддерживает запуск на удаленном компьютере под управлением Windows. Графический интерфейс утилиты имеет несколько компонентов.

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

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

Пользовательский интерфейс. Позволяет администратору отменять восстановление файла (перемещение с удаленного хранилища на диск).

Интерфейс управления. Позволяет устанавливать граничные значения, критерии выбора файлов для перемещения и т.д.

Модуль RSS имеет несколько ограничений; некоторые из них описаны далее.

В отличие от Windows Server 2003, модуль RSS, предоставляемый в Windows 2000, не поддерживает кластеризацию.

Операционная система Windows 2000 в качестве вторичного носителя поддерживает ленту шириной 4 мм, 8 мм и формата DLT.

Модуль RSS предоставляет возможность перемещения только неименованных потоков данных. Именованные потоки данных не обрабатываются вообще.

Модуль RSS использует точки повторной обработки, которые появились в файловой системе NTFS Windows 2000. Таким образом, модуль RSS не поддерживает более ранние версии NTFS.

Модуль RSS может работать только с фиксированными томами и не поддерживает тома на сменных носителях, например дисках DVD или Jazz.

Модуль RSS должен устанавливаться только после сжатия управляемого тома, если необходима работа со сжатыми томами.

«

Модуль RSS должен устанавливаться только после установки службы индексации, если в ней есть необходимость.

Модуль RSS хранит базу данных на системном томе. Это означает, что тома, управляемые модулем RSS, не являются самодостаточными и не могут быть перемещены с одного сервера на другой.

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

7.8.2 Подсистема RSM в Windows 2000

Подсистема RSM (Removable Storage Management) в Windows 2000 обеспечивает работу важных функций, включая:

поддержку накопителей на магнитной ленте и ленточных автоматов;

управление сменными носителями, например лентами и компакт-дис- ками;

возможность совместного использования накопителей на магнитной ленте и ленточных автоматов в различных приложениях, например приложениях резервного копирования и HSM.

Операционная система Windows 2000 предоставляет набор компонентов, которые позволяют управлять хранилищами и разрабатывать приложения, использующие сменные носители. Компоненты включают:

модули администрирования сменного хранилища;

диспетчер сменного хранилища (API);

базы данных сменных хранилищ.

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

Чтобы понять принципы работы этих компонентов, необходимо разобраться в архитектуре RSM.

7.8.2.1 Архитектура RSM в Windows 2000

На рис. 7.7 представлена общая архитектура подсистемы RSM в Windows 2000. Служба RSM играет важную роль во всей подсистеме RSM. Служба работает в качестве хранилища для кода реализации API RSM. Она получает запросы от приложений и размещает их в очереди, обрабатывая при получении доступа к соответствующим ресурсам. При запуске службы осуществляется поиск и инициализация различных библиотек, определение изолированных накопителей и ассоциирование накопителей с системами замены носителей.

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

Рис. 7.7. Архитектура RSM

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

7.8.2.2 Программные интерфейсы приложений RSM в Windows 2000

В наборе Windows 2000 Platform SDK описано создание приложения с помощью API RSM и предоставлена дополнительная информация об этом интерфейсе. Преимущество таких API состоит в эффективности создания приложений управления хранилищами.

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

На рис. 7.9 приведена схема реализации, предоставленная после появления RSM API. Очевидно, что, кроме всего прочего, RSM обеспечивает расширяемость. Как только RSM добавляет поддержку для нового устройства, приложение может использовать это устройство практически без изменений. Список устройств, поддерживаемых RSM, постоянно меняется; последняя версия списка доступна на Web-узле списка совместимого аппаратного обеспечения по адресу: .

Рис. 7.8. Схема разработки приложений до появления RSM API

Рис. 7.9. Разработка приложений, упрощенная благодаря использованию RSM API

Программные интерфейсы приложений RSM можно разделить на несколько категорий в зависимости от предоставляемых функций. Вот некоторые из них:

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

интерфейс для определения изменений состояния изолированных дисков;

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

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

монтирование, размонтирование и управление пулами носителей;

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

7.8.2.3 База данных RSM

База данных RSM хранит информацию, необходимую для работы подсистемы RSM. Примерами такой информации могут служить:

список носителей; *

подробная информация о пуле носителей, включая конфигурацию пула и его содержимое;

конфигурация библиотеки.

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

Пользователи могут создавать резервную копию базы данных, вручную копируя файлы. Обычно эти файлы расположены в папке %SystemRoot%\System32\ntmsdata. Очевидно, что служба RSM должна быть остановлена перед копированием файлов.

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

7.8.2.4 Пулы носителей

Пулы обеспечивают эффективное администрирование носителей. Пул представляет собой обычный набор носителей, например магнитных лент или компакт-дисков, обладающих общим свойством. Существует два типа пулов носителей: пулы приложений и системные пулы.

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

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

Пул импорта содержит распознанные, однако не использовавшиеся ранее носители. Хорошим примером служит носитель, записанный программой резервного копирования на другом компьютере и впервые смонтированный на данном компьютере.

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

Пулы приложений создаются с помощью интерфейса RSM приложениями управления хранилищами. В качестве примера можно указать такие приложения, как Windows Backup и Windows Remote Storage (HSM).

7.8.2.5 Пользовательский интерфейс администратора RSM

Этот интерфейс реализован в Windows 2000 и представляет собой оснастку ММС, которая дает возможность администратору системы или хранилища просматривать и настраивать объекты. Для представления пулов носителей, рабочих очередей и физических свойств устройств хранения используются различные объекты.

 

7.9 Будущее управления хранилищами по версии ассоциации SNIA: стандарты SMI

Недавно ассоциация SNIA разработала спецификацию стандартов, которая называется SMI (Storage Management Initiative) и в момент рассмотрения имела кодовое наименование Bluefin. В этой спецификации описано управление хранилищами логических и физических ресурсов в сетях хранения данных с помощью API, не относящихся к конкретным производителям. К методам управления хранилищем, описанным в SMI, относятся обнаружение устройств и управление операциями, в частности управление конфигурациями, уведомлениями, производительностью и безопасностью. Спецификация SMI впервые продемонстрирована весной 2002 года и получила поддержку нескольких производителей.

Спецификация SMI включает в себя существующие промышленные стандарты.

Проект SMI основан на модели CIM, предложенной ассоциацией SNIA. В спецификации SMI протокол HTTP указан в качестве транспортного механизма, а содержимое сообщений будет передаваться по этому протоколу на языке XML. Для обеспечения защиты и целостности данных в SMI описано применение технологии TLS (Transport Layer Security), рассмотренной в стандарте RFC 2246. Технология TLS – это протокол обеспечения защиты и целостности данных при передаче между двумя приложениями. В его основе лежит широко известный протокол SSL (Secure Sockets Layer).

Для обеспечения безопасности спецификация SMI требует использования стандарта аутентификации HTTP DAA (Digest Access Authentication). Этот метод аутентификации определен в стандарте RFC 2617 и представляет собой расширение протокола HTTP, позволяющее клиенту отправлять идентификационную информацию и пароль в зашифрованном виде, а не открытым текстом.

В спецификации SMI предполагается использование протокола SLP (Service Location Protocol) для обнаружения ресурсов хранилищ. Протокол описан в стандарте RFC 3224 и предоставляет методы обнаружения сетевых служб с поддержкой расширений сторонних производителей.

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

 

7.10 Сложности практической реализации

Интересно наблюдать, как поддержка интерфейса WMI развивается от рекомендуемой до обязательной в наборах программной разработки Microsoft и в требованиях этой компании. Развитие WMI происходит согласно устоявшейся практике Microsoft, которая меняет рекомендуемый статус технологии на обязательный параллельно с развитием самой технологии. >

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

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

 

7.11 Резюме

Методы управления хранилищами приобретают все большее значение, поскольку растет объем хранимых данных. Несколько производителей предоставили собственные технологии, однако большинство из них являются закрытыми. Ассоциация SNIA пытается стандартизировать управление хранилищем с помощью общей информационной модели (CIM). Компания Microsoft также уловила тенденцию и предоставляет возможности управления хранилищем через командную строку и графический интерфейс. Интерфейс для командной строки позволяет автоматизировать управление хранилищем с помощью командных сценариев.

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

Кроме того, в Windows 2000 предоставляется комплексная инфраструктура HSM (Hierarchical Storage Management), которая полностью интегрирована с остальными элементами операционной системы и включает в себя такие приложения, как графический интерфейс программы Проводник Windows, окно интерпретатора командной строки, приложения резервного копирования и планировщик заданий.