Verhalten und Interaktion von SMP

Systeminterne Methoden und Verwaltungsinfrastruktur-APIs

SMP-Entwickler (Storage Management Provider) arbeiten mit:

• Systeminterne Methoden, die von Convert-MofToProvider.exe generiert werden.
• MI-APIs (Management Infrastructure) aus der Mi.h-Datei , um die Implementierung ihres SMP bereitzustellen.

Die folgenden Aufzählungszeichen notieren einige wichtige systeminterne und MI-Methoden.

• EnumerateInstances und GetInstance

  EnumerateInstances wird aufgerufen, wenn eine Abfrage für Instanzen einer bestimmten Klasse vorhanden ist. Beispiel: Das PowerShell-Cmdlet Get-Object> ist der EnumerateInstances-Methode des entsprechenden WMI-Objekts< zugeordnet. Diese Methode sollte alle Instanzen der Klasse über <die Object>_Post-Methode zurückgeben. Da WMI häufig EnumerateInstances aufruft, sollte sie schnell ausgeführt werden. Verwenden Sie dazu eine gute Cacheverwaltung.

  GetInstance wird aufgerufen, wenn eine bestimmte Instanz einer Klasse benötigt wird, z. B. (aber nicht beschränkt auf):

  • Wenn die WMI-Infrastruktur eine beliebige Methode dieser Klasse aufruft
  • Wenn eine WMI-basierte Anwendung diese Methode direkt aufruft
  • Wenn eine Instanz der Klasse über Zuordnungsklassen angefordert wird

  Die GetInstance-Methode sollte nur das über <Object>_Post Methode angegebene Objekt zurückgeben. Der Bezeichner der abgefragten Instanz, d. h. der "Schlüssel", der in MOF definiert ist, was normalerweise die ObjectId ist, wird über den Parameter "InstanceName" abgerufen. Diese Methode wird häufig von WMI aufgerufen und sollte schnell abgeschlossen werden.

  EnumerateInstances und GetInstance sind für normale Klassen wie StorageProvider, StorageSubsystem, PhysicalDisk usw. obligatorisch.

  Für die Zuordnungsklassen sind "EnumerateInstances", "AssociatorInstances" und "ReferenceInstances" obligatorisch, während "GetInstance" nicht erforderlich ist.

• <Objekt>_Post und MI_PostResult

  So verstehen Sie den Unterschied zwischen MI-API-Methode <Object>_Post und MI_PostResult:

  • Stellen Sie sich <Object>_Post als Rückgabe eines Zeigers an einen Ausgabeparameter vor.
  • Stellen Sie sich MI_PostResult als Funktionsrücklaufwert vor, der den Ausführungsstatus der Funktion angibt.

  Sie müssen MI_PostResult nur einmal pro WMI-Methode "context" aufrufen, die in den Eingabeparametern jeder WMI-Methode zu finden ist. "Context" ist ein Zeiger auf WMI-Rückrufe. Wenn Sie MI_PostResult aufrufen, wird dieser Zeiger zerstört. Daher sollte eine WMI-Methode niemals im Textkörper einer anderen WMI-Methode aufgerufen werden.

  <Objekt>_Post kann dagegen pro WMI-Methodenkontext mehrmals aufgerufen werden. Diese Methode wird in der Regel in EnumerateInstances verwendet, um mehrere Objekte zurückzugeben.

• Set-Eigenschaft<> und ModifyInstance

  Die systeminterne Methode ModifyInstance wird nicht über die Windows Storage Management-API unterstützt. Zum Ändern der Eigenschaften eines Objekts wird die extrinsische Methode Set-Eigenschaft<> verwendet.

Weitere Informationen zu systeminternen Methoden und MI-APIs finden Sie in den MI-API-Beispielen aus dem Windows SDK.

Objektidentifikation

SMP-Schnittstellen verwenden die folgenden beiden Eigenschaftengruppen für die Objektidentifikation:

• Für Skripting und Programmierung: ObjectId und UniqueId

  ObjectId ist ein undurchsichtiger Bezeichner, der für die Verwendung der SMPs und deren Clients zum Nachverfolgen von Objektinstanzen erstellt und verwaltet wird. Es handelt sich um eine obligatorische Eigenschaft, die global eindeutig sein muss. Das heißt, keine zwei Objekte sollten jemals dieselbe ObjectId haben, auch wenn sie von separaten SMPs verwaltet werden oder sich auf unterschiedlichen Speichersubsystemen befinden.

  Wenn ein Objekt über zwei verschiedene Pfade sichtbar ist (z. B. gibt es zwei separate SMPs, die auf dasselbe Speichersubsystem verweisen), kann dasselbe Objekt mit zwei verschiedenen ObjectIds angezeigt werden. Um festzustellen, ob zwei Objektinstanzen dasselbe Objekt sind, verwenden Sie die UniqueId-Eigenschaft.

  UniqueId ist eine obligatorische Eigenschaft, die verwendet wird, um eine Instanz einer Klasse innerhalb eines globalen Bereichs eindeutig zu identifizieren. Dieser Wert sollte zwischen zwei Instanzen von SMPs identisch sein, die auf verschiedenen Verwaltungsservern ausgeführt werden. Im Gegensatz zu ObjectId sollte UniqueId ein Wert sein, der vom Speichersubsystem und nicht vom Speicherverwaltungsanbieterprozess beibehalten wird.

  UniqueId kann ein beliebiger undurchsichtiger Wert sein, außer wenn anders angegeben (z. B. MSFT_VirtualDisk).

• Anzeige: FriendlyName und Name

  Endbenutzer verwenden diese beiden Eigenschaften, um ein Objekt zu identifizieren. FriendlyName ist eine benutzerfreundliche Zeichenfolge, die von Endbenutzern festgelegt werden kann, wenn der SMP einen solchen Vorgang unterstützt. FriendlyName muss nicht eindeutig sein. Zwei Objekte aus einem einzigen Speichersubsystem können denselben FriendlyName gemeinsam nutzen, obwohl diese Vorgehensweise davon abgeraten wird.

  Der SMP legt die Name-Eigenschaft fest, und Endbenutzer können sie nicht ändern. Der SMP stellt zusätzliche Informationen in dieser Eigenschaft bereit, um Endbenutzern bei der Identifizierung eines Objekts zu helfen. Diese Informationen können technische Aspekte des Objekts abdecken. Beispielsweise kann der Name eines Speichersubsystems die IP- oder WWN des Subsystems sein. Der Name ist in der Regel in einem bestimmten Bereich eindeutig. Beispielsweise muss der Name eines Speicherpools im eigenen Speichersubsystem eindeutig sein.

Fehlerbehandlung

Es gibt drei Arten von Fehlern in SMP-Schnittstellen: Rückgabecodes der Windows Storage Management API (SM API), "Weiche Fehler" und "Harte Fehler".

SM-API-Rückgabecodes beziehen sich auf die Fehlercodes, die als Rückgabewerte für jede der extrinsischen SMP-Methoden aufgeführt sind. "5" stellt z. B. "Ungültiger Parameter" dar. Diese Fehlercodes werden über MIReturn-Ausgabeparameter zurückgegeben, der in der von Convert-MofToProvider.exe generierten Methodenstruktur definiert ist. Der Wert von MIReturn kann über <Object> _<Method>_Set_MIReturn festgelegt werden, der in der Headerdatei des entsprechenden Objekts definiert ist.

Extrinsic-Methoden sollten immer standardmäßig SM-API-Fehlercodes verwenden, wenn möglich. Wenn zusätzliche Informationen erforderlich sind, können SMPs MSFT_ExtendedStatus Klasse verwenden, um zusätzliche Statusinformationen über den Aufruf einer extrinsischen Methode zu liefern. Dieser Ansatz empfiehlt es sich, weiche Fehler für extrinsische Methoden zu verwenden.

Weiche Fehler beziehen sich auf Fehlermeldungen, die über die MSFT_SoftError Klasse zurückgegeben werden. Diese Fehler wurden für systeminterne Methoden (EnumerateInstances, GetInstance und etc.) entwickelt, bei denen es nicht möglich ist, SM-API-Fehlercodes zurückzugeben. Um weiche Fehler zurückzugeben, sollten Instanzen der von MSFT_SoftError abgeleiteten Soft-Error-Klassen erstellt und durch den Parameter "MI_Instance Error" in MI_WriteCimError methode zurückgegeben werden, die in mi.h definiert ist. Um beispielsweise anzugeben, dass während der Speicherarrayanmeldung "richtige Anmeldeinformationen erforderlich" angegeben werden, kann eine Instanz von "MSFT_SoftError_NotAuthenticated" während EnumerateInstances-Aufrufen von StorageSubsystem-Objekten zurückgegeben werden. Bei weichen Fehlern sollte das Ergebnis MI_RESULT_OK weiterhin über MI_PostResult gepostet werden.

Harte Fehler beziehen sich auf die in MI_Result Struktur definierten Fehler aus der Mi.h-Datei . MI-APIs geben diese Fehler zurück. SMP sollte diese Fehler nicht direkt auf Speicherverwaltungsanwendungen anwenden, es sei denn, es ist unbedingt erforderlich. Für "ungültige Parameter" sollten SMPs z. B. MIReturn verwenden, um SM-API-Fehlercode "5" – "Ungültiger Parameter" anzuzeigen, anstatt sich auf die Speicherverwaltungsanwendung zu verlassen, um MI_RESULT_INVALID_PARAMETER zu nutzen.

Primordial Pool

Ein Urpool, der auch als "verfügbarer Speicher"-Pool bezeichnet wird, ist der Ort, an dem die Speicherkapazität gezeichnet und in der Erstellung und Löschung konkreter Speicherpools zurückgegeben wird. Primordialpools können nicht erstellt, gelöscht oder geändert werden.

KMU müssen mindestens einen Urpool bereitstellen. Wenn ein physischer Datenträger zu einem konkreten Speicherpool hinzugefügt wird, sollte der physische Datenträger weiterhin als Teil des Urpools betrachtet werden.

Größenberichterstattung

Es gibt zwei Spezielle Fälle, die für verschiedene Größenfelder aus Speicherpoolobjekten diskutiert werden: Kapazität von Hot-Spare-Laufwerken und Kapazität von fehlerhaften Laufwerken.

Sobald ein Laufwerk als Hot-Spare-Laufwerk ernannt wurde, sollte seine Kapazität in die zugeordnete Zuweisungsgröße des entsprechenden Urpools aufgenommen werden. Die Kapazität des Laufwerks sollte jedoch nicht in die Größe eines konkreten Pools aufgenommen werden, auch wenn das Speicherarray das Devozieren eines Hot-Spare-Laufwerks für einen bestimmten Betonpool unterstützt. Nachdem ein Hot-Spare-Laufwerk einem bestimmten Betonpool gewidmet ist, sollte die Kapazität des Laufwerks erst dann in die "AllocatedSize" des Betonpools aufgenommen werden, wenn es tatsächlich ein gebrauchtes Laufwerk ersetzt. Wenn Sie einem konkreten Pool hinzugefügt werden, sollte CanPooled für das Physische Datenträgerobjekt dieses Hot-Spare-Laufwerks FALSE sein. Eine Zuordnung sollte zwischen diesem Physischen Datenträgerobjekt und dem Speicherpoolobjekt des konkreten Pools erstellt werden.

Die Kapazität von Laufwerken mit "HealthStatus" von "Unhealthy" sollte nicht in größenfelder aus einem Urpool oder betonen Pool enthalten sein.

Associations

SM-API enthält Zuordnungsklassen, die Beziehungen zwischen Speicherobjekten definieren. Mit diesen Zuordnungsklassen können Sie ganz einfach die Speicherobjekthierarchie durchlaufen, um verwandte Objekte für ein bestimmtes Objekt abzurufen. Für das Speicher-PowerShell-Modul wird die Cmdlet-Leitung über Zuordnungsklassen erreicht. Bei einem Virtual Disk-Objekt können Benutzer z. B. den Speicherpool abrufen, der das Virtual Disk-Objekt besitzt, über das folgende Cmdlet:

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

Der Rest dieses Abschnitts veranschaulicht die Implementierung von Zuordnungsklassen. Methoden in den Notizen werden von Convert-MofToProvider.exe für jede Zuordnungsklasse generiert. Die Notizen verwenden XToY als Beispielzuordnungsklasse; Der Pseudocode verwendet "StoragePoolToVirtualDisk" als Beispiel.

• EnumerateInstances und 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
        
            ...
        }

Cacheverwaltung

Wenn der SMP geladen wird, sollte er einen Cache von Speicherobjekten initialisieren. Diese Initialisierung stellt eine schnelle Antwortzeit sicher, wenn Api-Aufrufe gewartet werden, da Objekte direkt aus dem Cache des SMP abgerufen werden können. Dieser Cache sollte mit In-Band-Objektänderungen und Out-of-Band-Objektänderungen synchronisiert werden.

In-Band-Objektänderungen umfassen diese Änderungen, die über die aktuelle SMP-Instanz vorgenommen wurden. Beispiel: Wenn ein virtueller Datenträger über die aktuelle SMP-Instanz erstellt wird:

• Dem Cache sollte ein neues Virtuelles Datenträgerobjekt hinzugefügt werden.
• Die zugeordneten Objekte, z. B. der besitzende Speicherpool und die zugehörigen Zielportobjekte, sollten ebenfalls aktualisiert werden.

Out-of-Band-Änderungen umfassen diese Änderungen, die über herstellereigene Tools und SMPs vorgenommen wurden, die auf anderen Computern gehostet werden. Wenn beispielsweise ein virtueller Datenträger über herstellereigene Tools erstellt wird, sollte ein Ereignis vom Speichersubsystem an die SMP(n) gesendet werden, um ein Cacheupdate auszulösen.

SMP sollte auch den Cache aktualisieren, wenn die Discover-Methode aus der Speicheranbieterklasse aufgerufen wird. Die Speicherverwaltungsanwendung ruft diese Methode auf, um den Cache für Ereignisse wie Dienstneustart oder Systemneustart zurückzusetzen und neu zu erstellen.

Wenn es für den SMP nicht möglich ist, den gesamten Cache beim Start zu initialisieren (aufgrund zu vieler Objekte oder weil er nicht schnell ausgeführt werden kann), sollten nur die Speicheranbieter- und Speichersubsystemobjekte in den Cache geladen werden. Anwendungen untersuchen die CurrentCacheLevel-Eigenschaft im Storage Subsystem-Objekt, um zu wissen, wie tief der Cache gefüllt wurde. Der Endbenutzer oder die Anwendung laden den rest des Caches explizit über die Discover-Methode.

Asynchrone Vorgänge

Jeder Vorgang, der länger als 30 Sekunden dauert, muss ein Speicherauftragsobjekt zurückgeben. Methoden, die einen CreatedStorageJob-Ausgabeparameter enthalten, weisen höchstwahrscheinlich diesen Vorgangstyp auf. SMPs sollten all diese Methoden als asynchrone Vorgänge implementieren und Speicherauftragsobjekte für sie zurückgeben. Ein Speicherauftragsobjekt muss innerhalb von 30 Sekunden an den Aufrufer zurückgegeben werden. Andernfalls kann der Aufrufer ein Timeout ausführen, wenn er zu lange wartet und das Speicherauftragsobjekt noch nicht empfangen hat.

Anwendungen (oder "WMI-Client") haben die Möglichkeit, anzugeben, ob eine Methode "RunAsJob" sein soll oder nicht. Die sm-API, die von Anwendungen verwendet wird, enthält diesen zusätzlichen booleschen RunAsJob-Parameter und den CreatedStorageJob-Ausgabeparameter. In der Zwischenzeit verfügen die entsprechenden Methoden in SMP-Schnittstellen nur über den Parameter CreatedStorageJob. Unabhängig vom Wert von "RunAsJob" sollten SMPs jedoch immer Speicherauftragsobjekte für diese Methoden zurückgeben.

Die folgenden Szenarien veranschaulichen die Aufrufsequenz asynchroner Vorgänge. CreateVirtualDisk wird als Beispiel verwendet:

• Wenn "RunAsJob" auf TRUE festgelegt ist

  Wenn CreateVirtualDisk aufgerufen wird, sollte SMPs die Initialisierung für die Methode ausführen, einen Auftrag im Speichersubsystem starten und innerhalb von 30 Sekunden ein Speicherauftragsobjekt an den Aufrufer zurückgeben. Das Speichersubsystem kann jedoch eine beliebige Zeit in Anspruch nehmen, um den Vorgang abzuschließen. Der Anrufer ruft den Status des Auftrags während dieser Zeit ab.

  Arbeitsthreads sollten zum Ausführen der Aufträge verwendet werden. Aus Effizienzgründen können SMPs auftragsstatusbezogene Attribute (z. B. PercentComplete) nur aktualisieren, wenn der Aufrufer den Status dieses Auftrags abruft.

• Wenn "RunAsJob" auf FALSE festgelegt ist

  Der Aufrufer wird für die CreateVirtualDisk-Methode blockiert, bis die Methode zurückgegeben wird. Die SM-API führt automatisch das Blockieren und Abrufen selbst durch. Dieser Aufrufertyp ist in der Regel ein nicht benutzeraktiver Client (z. B. ein Skripttool), der den Blockierungsmechanismus bevorzugt.

  Da die einzige Möglichkeit zum Abrufen von Informationen zu einem neu erstellten Objekt die Zuordnung zwischen diesem Objekt und dem entsprechenden Speicherauftragsobjekt ist, sollten SMPs mindestens 24 Stunden lang ein Speicherauftragsobjekt beibehalten, bevor sie aus dem Cache entfernt werden. Bei anderen Vorgängen, die kein neu erstelltes Objekt zurückgeben (z. B. einen DeleteObject-Vorgang), ist keine Zuordnung erforderlich, und das Speicherauftragsobjekt muss nur 15 Minuten aktiv bleiben.

Bei unerwarteten Systemneustarts auf Verwaltungskonsole s sollten SMPs einen Cache von StorageJob-Objekten an einem physischen Speicherort verwalten, z. B. im Speicherarray, und den Cache beim Systemneustart neu laden.

Anbieterlebenszeitsteuerung

Ein SMP kann als gekoppelter oder entkoppelter Anbieter implementiert werden. Die Unterschiede zwischen diesen beiden Anbietertypen finden Sie in der WMI MSDN-Dokumentation.

Ein entkoppelter Anbieter wird in einem anbieterspezifischen Prozess geladen und gehostet. Dieser Prozess ist in der Regel ein immer ausgeführter Dienst.

Das Starten eines Anbieters kann zeitaufwändig sein, da der Cache neu geladen wird. Wenn ihr SMP-Start mehr als eine Sekunde oder so zum Laden benötigt, empfiehlt es sich, einen entkoppelten Anbieter zum Verwalten von Speicherobjekten über einen persistenten Cache zu implementieren. Dieser Ansatz trägt dazu bei, die Gesamtleistung und Reaktionsfähigkeit von Anwendungen zu erhöhen, die die Windows SM-API zum Verwalten Ihres SMP verwenden.

Das DecoupledHost-Beispiel aus dem Windows SDK enthält weitere Details zu entkoppelten Anbietern.

Angaben

Anwendungsentwickler möchten häufig wissen, wann sich der Zustand eines Objekts ändert, wenn es sich ändert. Sie können dies tun, indem sie WMI-Indikationen abonnieren. Indikationen sind eine andere Art von Klasse; sie werden asynchron verfügbar gemacht, manchmal außerhalb des Bandes von jedem Verwaltungsvorgang und bleiben nicht erhalten. Anstatt die vertrauten systeminternen Methoden (d. h. EnumerateInstances / GetInstance) zu implementieren, gibt es neue Methoden, die unterstützt werden müssen.

Es gibt vier Arten von Indikationen:

• Ankunft – Diese Angabe wird verwendet, wenn ein Gerät oder eine Objektinstanz zum Subsystem hinzugefügt wird. Beispiel: Hinzufügen eines neuen physischen Datenträgers zum Subsystem oder Erstellen eines virtuellen Datenträgers.
• Abfahrt – Diese Angabe wird verwendet, wenn ein Gerät oder eine Objektinstanz aus dem Subsystem entfernt wird. Beispiel: Entfernen eines physischen Datenträgers aus dem Subsystem oder Löschen eines Speicherpools.
• Ändern – Diese Angabe wird verwendet, wenn eine wichtige Eigenschaft für ein vorhandenes Objekt geändert wird. Mindestens müssen Die Änderungen von HealthStatus und OperationalStatus eine Änderungsanzeige auslösen. Die Angabe einer Änderung einer anderen Eigenschaft im Zusammenhang mit dem Betriebsstatus eines Objekts wird dringend empfohlen.
• Warnung – Dieser Hinweis wird verwendet, um die Anwendung auf ein potenzielles Problem zu benachrichtigen. Derzeit ist die einzige definierte Warnung für die Benachrichtigung, wenn ein schwellenwert für die dünne Bereitstellung erreicht wird.

Zur Implementierung von Indikationen gibt es zwei neue systeminterne Methoden, die für jede Indikationsklasse implementiert werden müssen:

• EnableIndication – Eine Anforderung, die Indikationsklasse zu abonnieren, wurde gestellt. Der "indicationContext" sollte weggespeichert werden, damit er zu einem späteren Zeitpunkt in einem Hinweis posten kann.
• DisableIndication – Es gibt keine weiteren Abonnenten der Indikationsklasse. Die Bereinigung sollte auftreten und es sollten keine weiteren Hinweise für diese Klasse bereitgestellt werden. indicationContext wird zu diesem Zeitpunkt zerstört.

Bereitstellung

SMPs werden auf ausgewählten Verwaltungsservern installiert. Diese Server können gruppiert werden, um Redundanz bereitzustellen. Andere Server greifen über iSCSI oder Fiber Channel zugewiesenen Speicher zu. All diese Computer können von Servern verwaltet werden, die die Benutzeroberfläche des Dateiservers über Server-Manager ausführen.

Speicheranbieter können jedoch gerne auswählen, welches Bereitstellungsmodell ihren Anforderungen am besten entspricht.

Sicherheitsmodell

SMP-Schnittstelle unterstützt SSO-Modell (Single Sign-On) mit Windows-Sicherheitsanmeldeinformationen.

Im SSO-Modell meldet sich ein Benutzer einmal mit seinen Windows-Anmeldeinformationen bei einem "Verwaltungscomputer" an und erhält automatisch Zugriff auf alle Speicherressourcen, die über Zugriffsberechtigungen verfügen. Es ist nicht erforderlich, mehr Anmeldeinformationen für die Anmeldung des Speichersubsystems zu haben.

Über die Schnittstelle können Speicheradministratoren auch die Zugriffssteuerung für einzelne Speicherressourcen verwalten. Für jede Speicherressource können Speicheradministratoren jedem Windows-Benutzer über die Methoden GetSecurityDescriptor und SetSecurityDescriptor unterschiedliche Zugriffsrechte gewähren. Daher können SMPs im Gegensatz zum VDS-Modell jetzt Anfragen von jedem Benutzerkontotyp erhalten.

Zum Implementieren des SSO-Modells muss ein SMP die Windows-Clients beim Speichersubsystem authentifizieren. Das Speichersubsystem muss die Sicherheitsbeschreibungsinformationen für jede Speicherressource beibehalten. Um die Authentifizierung zu implementieren, haben Speicheranbieter zwei Möglichkeiten:

• Authentifizieren im Subsystem (empfohlen)
• Authentifizieren Sie sich in jeder SMP-Instanz.

Beide Optionen erfordern eine Vertrauensstellung zwischen dem SMP und dem Speichersubsystem, damit Sicherheitsbeschreibungs- und Benutzeridentitätsinformationen sicher übergeben werden können.

Um die nahtlose Authentifizierung und Autorisierung für das Speichersubsystem zu implementieren, empfehlen wir die Verbindung zwischen dem SMP und dem Speichersubsystem, um Kerberos, NTLM oder SPNego zu implementieren. Wenn das Speichersubsystem über einen Webserver verfügt, ist das "NTLM over HTTP"-Protokoll [MS-NLMP] möglicherweise hilfreicher. Speicheranbieter können ihre proprietären Protokolle beibehalten, um das SSO-Modell zu implementieren. Dieser Ansatz wird jedoch nicht empfohlen, da er zu mehr Arbeit oder Einrichtung führen kann als die Implementierung eines der von Windows unterstützten Authentifizierungsprotokolle.

Um die Windows-Sicherheitsrichtlinie zu unterstützen, muss das Speichersubsystem die "Tokeninformationen" des Benutzers abrufen, die den Sicherheitsbezeichner (SECURITY Identifier, SID) des Benutzers und die SIDs aller Gruppen enthält, in denen der Benutzer Mitglied ist. Wenn das Kerberos-, NTLM- oder SPNego-Protokoll implementiert ist, ruft das Speichersubsystem die Tokeninformationen des Benutzers als Teil des Protokolls ab. Wenn das proprietäre Protokoll eines Anbieters zwischen SMP und dem Speichersubsystem verwendet wird, kann das Speichersubsystem die Tokeninformationen des Benutzers über Das Lightweight Directory Access Protocol (LDAP) abfragen und das TokenGroupsGlobalAndUniversal-Attribut oder Object-Sid-Attribut des Kontoobjekts des Benutzers anzeigen.

Um die Windows-Sicherheitsrichtlinie durch die Tokeninformationen des Benutzers zu erzwingen, muss das Speichersubsystem den in [MS-DTYP] beschriebenen Zugriffsüberprüfungsalgorithmus implementieren.

Wenn sich ein Speicheranbieter entscheidet, dieses SSO-Modell nicht zu unterstützen, empfehlen wir, dass der SMP dem Sicherheitsmodell von VDS folgt – nur Vorgänge, die von Administratorkonten initiiert wurden. Diese Überprüfung muss jedoch jetzt vom SMP selbst durchgeführt werden.