Поведение и взаимодействие SMP

Статья
11/22/2024

Встроенные методы и API инфраструктуры управления

Разработчики поставщика управления хранилищами (SMP) работают с:

Встроенные методы, созданные Convert-MofToProvider.exe.
API инфраструктуры управления (MI) из mi.h-файла для предоставления реализации SMP.

Следующие маркеры отмечают несколько встроенных и встроенных методов MI.

ПеречислениеInstances и GetInstance

ПеречислениеInstances вызывается при запросе экземпляров определенного класса. Например, командлет PowerShell Get-Object<> сопоставляется с соответствующим методом перечисления объекта WMI. Этот метод должен возвращать все экземпляры класса с помощью <метода Object>_Post. Так как WMI часто вызывает ПеречислениеInstances, он должен выполняться быстро. Для этого используйте хорошее управление кэшем.

GetInstance вызывается, когда требуется конкретный экземпляр класса, например (но не ограничивается):
- Когда инфраструктура WMI вызывает любой метод этого класса
- Когда приложение на основе WMI напрямую вызывает этот метод
- При запросе экземпляра класса через классы Association
Метод GetInstance должен возвращать только объект, указанный с помощью <метода Object>_Post. Идентификатор запрашиваемого экземпляра, который является ключом, определенным в MOF, который обычно является ObjectId, извлекается с помощью параметра InstanceName. Этот метод вызывается WMI часто и должен быстро завершиться.

ПеречислениеInstance и GetInstance являются обязательными для обычных классов, таких как StorageProvider, StorageSubsystem, PhysicalDisk и т. д.

Для классов Ассоциации перечислениеInstances, AssociatorInstances и ReferenceInstances являются обязательными, в то время как GetInstance не является обязательным.
<Объект>_Post и MI_PostResult

Чтобы понять разницу между объектом> метода <API MI_Post и MI_PostResult:
- Подумайте о <объекте>_Post как возвращающий указатель на выходной параметр.
- Думайте о MI_PostResult как возвращаемое функцией значение, указывающее состояние выполнения функции.
Необходимо вызывать только MI_PostResult один раз для каждого метода WMI "context", который можно найти в входных параметрах каждого метода WMI. Context — это указатель на обратные вызовы WMI. Вызов MI_PostResult уничтожит этот указатель. Поэтому метод WMI никогда не должен вызываться в тексте другого метода WMI.

<Объект>_Post с другой стороны, можно вызывать несколько раз в контексте метода WMI. Этот метод обычно используется в ПеречисленииInstances для возврата нескольких объектов.
Установка<свойства> и modifyInstance

Встроенный метод ModifyInstance не поддерживается через API управления хранилищем Windows. Для изменения свойств объекта используется свойство> set<метода extrinsic.

Дополнительные сведения о встроенных методах и API MI см. в примерах API MI из пакета SDK для Windows.

Идентификация объектов

Интерфейсы SMP используют следующие две группы свойств для идентификации объектов:

Для сценариев и программирования: ObjectId и UniqueId

ObjectId — это непрозрачный идентификатор, созданный и поддерживаемый для использования SMPs и их клиентов для отслеживания экземпляров объектов. Это обязательное свойство, которое должно быть глобально уникальным. То есть ни один объект не должен иметь один и тот же объект ObjectId, даже если они управляются отдельными SMP или находятся в разных подсистемах хранения.

Если объект отображается двумя разными путями (например, есть два отдельных SMP, указывающих на одну подсистему хранения), то один и тот же объект может отображаться с двумя разными идентификаторами ObjectId. Чтобы определить, являются ли два экземпляра объекта одинаковыми, используйте свойство UniqueId.

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

UniqueId может быть любым непрозрачным значением, кроме указанного в противном случае (например, MSFT_VirtualDisk).
Для отображения: FriendlyName и Name

Конечные пользователи используют эти два свойства для идентификации объекта. FriendlyName — это пользовательская строка, которая настраивается конечными пользователями, если SMP поддерживает такую операцию. FriendlyName не должно быть уникальным. Два объекта из одной подсистемы хранения могут совместно использовать одно и то же Свойство FriendlyName, хотя эта практика не рекомендуется.

SMP задает свойство Name, и конечные пользователи не могут изменить его. SMP предоставляет дополнительные сведения в этом свойстве, чтобы помочь конечным пользователям определить объект. Такая информация может охватывать технические аспекты объекта. Например, имя подсистемы хранения может быть IP-адресом или WWN подсистемы. Имя обычно уникально в определенной области. Например, имя пула носителей должно быть уникальным в подсистеме хранения.

Обработка ошибок

В интерфейсах SMP есть три типа ошибок: коды возврата API управления хранилищами Windows (SM API), "Мягкие ошибки" и "Жесткие ошибки".

Коды возврата API SM ссылаются на коды ошибок, перечисленные как возвращаемые значения для каждого из экстринсических методов SMP. Например, "5" представляет "Недопустимый параметр". Эти коды ошибок возвращаются через выходной параметр MIReturn, определенный в структуре метода, созданной Convert-MofToProvider.exe. Значение MIReturn можно задать с помощью <Object> _<Method>_Set_MIReturn определенного в файле заголовка соответствующего объекта.

Методы extrinsic всегда должны использовать коды ошибок API SM по возможности. При необходимости для предоставления дополнительных сведений о вызове экстринсического метода с помощью класса MSFT_ExtendedStatus можно использовать класс MSFT_ExtendedStatus. Этот подход предпочтительнее использовать обратимые ошибки для экстринсических методов.

Обратимые ошибки ссылаются на сообщения об ошибках, возвращаемые через класс MSFT_SoftError. Эти ошибки предназначены для встроенных методов (EnumerateInstances, GetInstance и т. д.), где невозможно возвращать коды ошибок API SM. Чтобы вернуть мягкие ошибки, экземпляры классов обратимой ошибки, производных от MSFT_SoftError, должны быть созданы и возвращены с помощью параметра "MI_Instance ошибка" в методе MI_WriteCimError, определенном в mi.h. Например, чтобы указать, что во время входа массива хранилища необходимы правильные учетные данные, во время вызовов EnumerateInstances в объектах StorageSubsystem можно вернуть экземпляр "MSFT_SoftError_NotAuthenticated". Для мягких ошибок результат MI_RESULT_OK по-прежнему должен быть размещен через MI_PostResult.

Жесткие ошибки относятся к ошибкам, определенным в MI_Result структуре из mi.h-файла . API MI возвращают эти ошибки. SMP должен избежать непосредственного отображения этих ошибок в приложениях управления хранилищами, если это не обязательно. Например, для "недопустимых параметров" smps следует использовать MIReturn для отображения кода ошибки API SM "5" — "Недопустимый параметр" вместо использования приложения управления хранилищем для использования MI_RESULT_INVALID_PARAMETER.

Первичный пул

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

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

Отчеты о размере

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

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

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

Сопоставления

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

    PS> Get-VirtualDisk –FriendlyName MyVirtualDisk | Get-StoragePool

Остальная часть этого раздела иллюстрирует реализацию классов ассоциаций. Методы в заметках создаются Convert-MofToProvider.exe для каждого класса ассоциации. Примечания используют XToY в качестве примера класса ассоциации; Псевдокод использует StoragePoolToVirtualDisk в качестве примера.

ПеречислениеInstances и GetInstance

      - XToY\_EnumerateInstances returns association objects (XToY objects) for ALL X objects
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_EnumerateInstances( ... )
        {
            ...
        
        /** This method should return association objects for ALL Storage Pools. **/
        
            // for each storage pool
        
                // for each virtual disk that's associated with this storage pool
        
                    // create the StoragePoolToVirtualDisk association object
                    // set the storage pool object and virtual disk object to this association object
                    // post the association object
                
                // end for
        
            // end for
        
            ...
        }

AssociatorInstances

      - AssociatorInstances method returns regular objects instead of association objects
      - XToY\_AssociatorInstancesX should return all associated Y object(s) for the X specified
      - XToY\_AssociatorInstancesY should return all associated X object(s) for the Y specified
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_AssociatorInstancesStoragePool(...)
        {
            ...
        
        /** This method should return VIRTUAL DISK object(s) for the 
        STORAGE POOL specified. **/
        
            // for each virtual disk that's associated with this storage pool
        
                // create the virtual disk object
                // post the virtual disk object
                
            // end for
        
            ...
        }
        
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_AssociatorInstancesVirtualDisk(...)
        {
            ...
        
        /** This method should return STORAGE POOL object(s) for the 
        VIRTUAL DISK specified. **/
        
            // for each storage pool that's associated with this virtual disk
        
                // create the storage pool object
                // post the storage pool object
                
            // end for
        
            ...
        }

ReferenceInstances

      - ReferenceInstances is similar to AssociatorInstances except that these methods return association (XToY) objects instead of regular objects
      - XToY\_ReferenceInstancesX should return XToY object(s) for X specified
      - XToY\_ReferenceInstancesY should return YToX object(s) for Y specified
    
    <!-- end list -->
    
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_ReferenceInstancesStoragePool(...)
        {
            ...
        
        /** This method should return StoragePoolToVirtualDisk 
        ASSOCIATION object(s) for the STORAGE POOL specified. **/
        
            // for each virtual disk that's associated with this storage pool
        
                // create the StoragePoolToVirtualDisk association object
                // set the storage pool and virtual disk to this association object
                // post the association object
                
            // end for
        
        
            ...
        }
        
        void MI_CALL SAMPLE_StoragePoolToVirtualDisk_ReferenceInstancesVirtualDisk(...)
        {
            ...
        
        /** This method should return StoragePoolToVirtualDisk 
        ASSOCIATION object(s) for the VIRTUAL DISK specified. **/
        
            // for each storage pool that's associated with this virtual disk
        
                // create the StoragePoolToVirtualDisk association object
                // set the storage pool and virtual disk to this association object
                // post the association object
                
            // end for
        
            ...
        }

Управление кэшем

При загрузке SMP он должен инициализировать кэш объектов хранилища. Эта инициализация обеспечивает быстрое время отклика при выполнении вызовов API обслуживания, так как объекты можно получить непосредственно из кэша SMP. Этот кэш должен храниться в синхронизации с изменениями объекта в полосе и изменениями вне диапазона объектов.

Изменения объекта в полосе включают эти изменения, внесенные через текущий экземпляр SMP. Например, если виртуальный диск создается с помощью текущего экземпляра SMP:

Новый объект виртуального диска должен быть добавлен в кэш.
Связанные объекты, такие как собственный пул носителей и связанные объекты целевого порта, также должны быть обновлены.

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

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

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

Асинхронные операции

Любая операция, которая занимает более 30 секунд, должна возвращать объект задания хранилища. Методы, содержащие выходной параметр CreatedStorageJob, скорее всего, будут иметь этот тип операции. SmPs должен реализовать все эти методы в виде асинхронных операций и возвращать для них объекты задания хранилища. Объект задания хранилища должен быть возвращен вызывающей объекту в течение 30 секунд; В противном случае вызывающий объект может истекть, если он ожидает слишком долго и по-прежнему не получил объект задания хранилища.

Приложения (или клиент WMI) имеют возможность указать, должен ли метод быть "RunAsJob" или нет. API SM, используемый приложениями, содержит этот дополнительный логический параметр RunAsJob и выходной параметр CreateStorageJob. Между тем соответствующие методы в интерфейсах SMP имеют только параметр CreatedStorageJob. Однако, независимо от значения RunAsJob, smps всегда должен возвращать объекты задания хранилища для этих методов.

В следующих сценариях показана последовательность вызовов асинхронных операций. CreateVirtualDisk используется в качестве примера:

Если для параметра RunAsJob задано значение TRUE

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

Рабочие потоки должны использоваться для выполнения заданий. Для повышения эффективности ПОСТАВЩИКи служб могут обновлять атрибуты, связанные с заданием (например, PercentComplete), только если вызывающий объект опрашивает состояние этого задания.
Если для параметра RunAsJob задано значение FALSE

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

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

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

Управление временем жизни поставщика

SMP можно реализовать в виде связанного или разъединяемого поставщика. Различия между этими двумя типами поставщиков см. в документации по WMI MSDN.

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

Запуск поставщика может занять много времени, так как он включает перезагрузку кэша. Если для запуска SMP требуется более секунды или около того, рекомендуется реализовать развязанный поставщик для управления объектами хранилища через постоянный кэш. Этот подход помогает повысить общую производительность и скорость реагирования приложений, использующих API SM Windows для управления SMP.

Пример DecoupledHost из пакета SDK для Windows содержит дополнительные сведения о развязанных поставщиках.

Показания

Разработчики приложений часто хотят знать, когда состояние объекта изменяется по мере изменения. Они могут сделать это, подписавшись на указания WMI. Признаки относятся к другому классу; они предоставляются асинхронно, иногда вне полосы из любой операции управления и не сохраняются. Вместо реализации знакомых встроенных методов (т. е. ПеречислениеInstances / GetInstance), существуют новые методы, которые должны поддерживаться.

Существует четыре типа признаков:

Прибытие — это указание используется при добавлении в подсистему экземпляра устройства или объекта. Например, добавление нового физического диска в подсистему или создание виртуального диска.
Отъезд — это указание используется при удалении устройства или экземпляра объекта из подсистемы. Например, удаление физического диска из подсистемы или удаление пула носителей.
Изменение. Это указывает, когда важные свойства изменяются в существующем объекте. Как минимум, изменения HealthStatus и OperationsStatus должны активировать признак изменения. Указывая на изменение любого другого свойства, связанного с состоянием работы объекта, настоятельно рекомендуется.
Оповещение — это указание используется для оповещения приложения о потенциальной проблеме. В настоящее время единственным определенным оповещением является уведомление о достижении тонкого порога подготовки.

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

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

Развертывание

SmPs устанавливаются на выбранных серверах управления. Эти серверы могут быть кластеризованы для обеспечения избыточности. Другие серверы получают доступ к хранилищу, выделенному им через iSCSI или Fibre Channel. Все эти компьютеры могут управляться серверами, выполняющими пользовательский интерфейс файлового сервера из диспетчер сервера.

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

Модель безопасности

Интерфейс SMP поддерживает модель единого входа с помощью учетных данных безопасности Windows.

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

Интерфейс также позволяет администраторам хранилища управлять доступом к отдельным ресурсам хранилища. Для каждого ресурса хранения администраторы хранилища могут предоставлять разные права доступа любому пользователю Windows с помощью методов GetSecurityDescriptor и SetSecurityDescriptor. В результате поставщики СЛУЖБ, в отличие от модели VDS, теперь могут получать запросы от любой учетной записи пользователя.

Чтобы реализовать модель единого входа, SMP должен пройти проверку подлинности клиентов Windows в подсистеме хранения. Подсистема хранения должна сохранять сведения о дескрипторов безопасности для каждого ресурса хранения. Для реализации проверки подлинности у поставщиков хранилища есть два варианта:

Проверка подлинности в подсистеме (рекомендуется)
Проверка подлинности в каждом экземпляре SMP.

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

Для реализации простой проверки подлинности и авторизации в подсистеме хранения рекомендуется связать между SMP и подсистемой хранения для реализации Kerberos, NTLM или SPNego. Если подсистема хранения имеет веб-сервер, протокол NTLM по протоколу HTTP (MS-NLMP) может оказаться более полезным. Поставщики службы хранилища могут сохранить свои собственные протоколы для реализации модели единого входа. Однако этот подход не рекомендуется, так как он может привести к большей работе или настройке, чем реализация одного из поддерживаемых Windows протоколов проверки подлинности.

Для поддержки политики безопасности Windows подсистема хранения должна получить "сведения о маркере" пользователя, включающую идентификатор безопасности пользователя (SID) и идентификаторы SID всех групп, из которых пользователь является членом. Если реализован протокол Kerberos, NTLM или SPNego, подсистема хранения получит сведения о маркере пользователя в рамках протокола. Если частный протокол поставщика используется между SMP и подсистемой хранения, подсистема хранения может запрашивать сведения о маркере пользователя из Active Directory через протокол LDAP и просмотреть атрибут tokenGroupsGlobalAndUniversal или Object-Sid для объекта учетной записи пользователя.

При использовании сведений о маркере пользователя для применения политики безопасности Windows подсистема хранения должна реализовать алгоритм проверки доступа, описанный в [MS-DTYP].

Если поставщик хранилища решит не поддерживать эту модель единого входа, рекомендуется использовать модель безопасности из VDS— разрешая только операции, инициированные учетными записями администратора. Однако эта проверка должна выполняться самой SMP.

Поделиться через