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

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