Udostępnij przez

Zachowanie i interakcja protokołu SMP

Wewnętrzne metody i interfejsy API infrastruktury zarządzania

Deweloperzy dostawcy zarządzania magazynem (SMP) pracują z:

  • Metody wewnętrzne generowane przez Convert-MofToProvider.exe.
  • Interfejsy API infrastruktury zarządzania (MI) z pliku mi.h w celu zapewnienia implementacji SMP.

W poniższych punktorach zanotuj kilka kluczowych metod wewnętrznych i mi.

  • EnumerateInstances i GetInstance

    Klasa EnumerateInstances jest wywoływana, gdy istnieje zapytanie dotyczące wystąpień określonej klasy. Na przykład: polecenie cmdlet programu PowerShell Get-Object odpowiada metodzie obiektu WMI nazwanej EnumerateInstances. Ta metoda powinna zwrócić wszystkie wystąpienia klasy za pomocą metody <Object>_Post. Ponieważ WMI często wywołuje EnumerateInstances, powinno działać szybko. W tym celu należy użyć dobrego zarządzania pamięcią podręczną.

    Funkcja GetInstance jest wywoływana, gdy potrzebne jest określone wystąpienie klasy, na przykład (ale nie tylko):

    • Gdy infrastruktura WMI wywołuje dowolną metodę tej klasy
    • Gdy aplikacja oparta na usłudze WMI bezpośrednio wywołuje tę metodę
    • Gdy wystąpienie klasy jest żądane za pomocą klas asocjacyjnych

    Metoda GetInstance powinna zwracać tylko obiekt określony za pośrednictwem <metody Object>_Post. Identyfikator wystąpienia, o które wykonywane jest zapytanie, czyli „Klucz” zgodnie z definicją w MOF, który zwykle jest identyfikatorem ObjectId, jest pobierany za pośrednictwem parametru InstanceName. Ta metoda jest często wywoływana przez usługę WMI i powinna zostać szybko ukończona.

    Klasy EnumerateInstance i GetInstance są obowiązkowe dla zwykłych klas, takich jak StorageProvider, StorageSubsystem, PhysicalDisk itd.

    W przypadku klas Skojarzeń klasy EnumerateInstances, AssociatorInstances i ReferenceInstance są obowiązkowe, a klasa GetInstance nie jest wymagana.

  • <Obiekt>_Post i MI_PostResult

    Aby zrozumieć różnicę między metodą MI API <Object>_Post a MI_PostResult:

    • Traktuj <Object>_Post jako zwracający wskaźnik do parametru wyjściowego.
    • Pomyśl o MI_PostResult jako wartości zwracanej przez funkcję, która wskazuje stan wykonywania funkcji.

    Należy wywołać tylko MI_PostResult raz na metodę WMI "context", którą można znaleźć w parametrach wejściowych każdej metody WMI. "Kontekst" jest wskaźnikiem do wywołań zwrotnych WMI. Wywołanie MI_PostResult spowoduje zniszczenie tego wskaźnika. W związku z tym metoda WMI nigdy nie powinna być wywoływana w treści innej metody WMI.

    <Obiekt>_Post z drugiej strony może być wywoływany więcej niż raz w kontekście metody WMI. Ta metoda jest zwykle używana w klasach EnumerateInstance w celu zwrócenia wielu obiektów.

  • Ustaw<Właściwość> i ModifyInstance

    Metoda wewnętrzna ModifyInstance nie jest obsługiwana za pośrednictwem API zarządzania magazynem systemu Windows. Aby zmodyfikować właściwości obiektu, jest używana metoda extrinsic Set<Property> .

Aby uzyskać więcej informacji na temat metod wewnętrznych i interfejsów API mi, zapoznaj się z przykładami interfejsu API mi z zestawu Windows SDK.

Identyfikacja obiektu

Interfejsy SMP używają następujących dwóch grup właściwości do identyfikacji obiektów:

  • W przypadku skryptów i programowania: ObjectId i UniqueId

    ObjectId jest niejawnym identyfikatorem utworzonym i zarządzanym do użytku SMP i ich klientów do śledzenia wystąpień obiektów. Jest to obowiązkowa właściwość, która musi być globalnie unikatowa. Oznacza to, że żadne dwa obiekty nigdy nie powinny mieć tego samego identyfikatora ObjectId, nawet jeśli są zarządzane przez oddzielne dostawcy usług w chmurze lub znajdują się w różnych podsystemach magazynowania.

    Jeśli obiekt jest widoczny za pośrednictwem dwóch różnych ścieżek (na przykład istnieją dwa oddzielne protokoły SMP, które wskazują ten sam podsystem pamięci masowej), ten sam obiekt może pojawić się z dwoma różnymi identyfikatorami. Aby określić, czy dwa wystąpienia obiektów są tym samym obiektem, użyj właściwości UniqueId.

    UniqueId to obowiązkowa właściwość, która służy do unikatowego identyfikowania wystąpienia klasy w zakresie globalnym. Ta wartość powinna być taka sama między dwoma wystąpieniami smP uruchomionymi na różnych serwerach zarządzania. W przeciwieństwie do objectId, UniqueId powinien być wartością, którą podsystem magazynowania utrzymuje, a nie proces dostawcy zarządzania magazynem.

    UniqueId może być dowolną nieprzezroczystą wartością, z wyjątkiem sytuacji, w której określono inaczej (na przykład: MSFT_VirtualDisk).

  • W przypadku wyświetlania: FriendlyName i Name

    Użytkownicy końcowi używają tych dwóch właściwości do identyfikowania obiektu. FriendlyName to przyjazny dla użytkownika ciąg, który można ustawić dla użytkowników końcowych, jeśli protokół SMP obsługuje taką operację. FriendlyName nie musi być unikatowa. Dwa obiekty z jednego podsystemu magazynu mogą współdzielić tę samą nazwę FriendlyName, chociaż ta praktyka jest niewskazana.

    Protokół SMP ustawia właściwość Name, a użytkownicy końcowi nie mogą go modyfikować. Protokół SMP dostarcza dodatkowe informacje w tej właściwości, aby ułatwić użytkownikom końcowym identyfikację obiektu. Takie informacje mogą obejmować aspekty techniczne obiektu. Na przykład, nazwa podsystemu pamięci masowej może być adresem IP lub WWN podsystemu. Nazwa jest zwykle unikatowa w określonym zakresie. Nazwa puli pamięci masowej musi być unikalna w jej macierzystym podsystemie.

Obsługa błędów

Istnieją trzy typy błędów w interfejsach SMP: kody powrotne interfejsu API zarządzania magazynem systemu Windows (SM API), "błędy miękkie" i "błędy trwałe".

Kody powrotne interfejsu API SM odnoszą się do kodów błędów wymienionych jako wartości zwracane dla każdej z zewnętrznych metod SMP. Na przykład wartość "5" reprezentuje "Nieprawidłowy parametr". Te kody błędów są zwracane za pośrednictwem parametru wyjściowego MIReturn zdefiniowanego w strukturze metody wygenerowanej przez Convert-MofToProvider.exe. Wartość MIReturn można ustawić za pomocą <właściwości Object> _<Method>_Set_MIReturn zdefiniowanej w pliku nagłówkowym odpowiedniego obiektu.

Metody zewnętrzne powinny zawsze domyślnie używać kodów błędów SM API, jeśli to możliwe. W razie potrzeby dodatkowych informacji SMPs mogą używać klasy MSFT_ExtendedStatus do dostarczania dodatkowych informacji o stanie wywołania metody zewnętrznej. To podejście jest lepsze niż używanie błędów miękkich dla metod zewnętrznych.

Miękkie błędy odnoszą się do komunikatów o błędach zwracanych za pośrednictwem klasy MSFT_SoftError. Te błędy są przeznaczone dla metod wewnętrznych (EnumerateInstances, GetInstance itp.), gdzie nie można zwrócić kodów błędów interfejsu API SM. Aby zwrócić miękkie błędy, wystąpienia klas błędów miękkich pochodzące z MSFT_SoftError powinny być konstruowane i zwracane za pomocą parametru "MI_Instance error" w metodzie MI_WriteCimError zdefiniowanej w mi.h. Na przykład, aby wskazać, że wymagane jest prawidłowe poświadczenie podczas logowania do macierzy magazynowej, można zwrócić wystąpienie "MSFT_SoftError_NotAuthenticated" podczas wywołań EnumerateInstances dla obiektów StorageSubsystem. W przypadku błędów miękkich wynik MI_RESULT_OK powinien być nadal publikowany za pośrednictwem MI_PostResult.

Twarde błędy odnoszą się do błędów zdefiniowanych w strukturze MI_Result pliku mi.h . Interfejsy API MI zwracają te błędy. SMP powinien unikać bezpośredniego ujawniania tych błędów w aplikacjach do zarządzania pamięcią masową, chyba że jest to absolutnie konieczne. Na przykład w przypadku "nieprawidłowych parametrów" dostawcy SM powinni użyć funkcji MIReturn, aby wyświetlić kod błędu interfejsu API SM "5" — "Nieprawidłowy parametr" zamiast polegać na aplikacji do zarządzania pamięcią masową w celu użycia MI_RESULT_INVALID_PARAMETER.

Pula pierwotna

Pierwotna pula, znana również jako "dostępna pula magazynu", to miejsce, w którym jest pobierana pojemność magazynu i zwracana podczas tworzenia i usuwania konkretnych pul magazynów. Nie można tworzyć, usuwać ani modyfikować pul pierwotnych.

Dostawcy SMP muszą zapewnić co najmniej jedną pierwotną pulę. Po dodaniu dysku fizycznego do konkretnej puli magazynów dysk fizyczny powinien być nadal traktowany jako część puli pierwotnej.

Raportowanie rozmiarów

Istnieją dwa specjalne przypadki omawiania różnych pól rozmiaru z obiektów puli magazynów: pojemność dysków zapasowych i pojemności dysków w złej kondycji.

Po wyznaczeniu dysku jako dysku zapasowego na gorąco jego pojemność powinna być uwzględniona w odpowiedniej pierwotnej puli AllocatedSize. Jednak pojemność dysku nie powinna być uwzględniana w rozmiarze żadnej konkretnej puli, nawet jeśli macierz dyskowa obsługuje przeznaczenie dysku zapasowego na określoną konkretną pulę. Gdy gorący dysk zapasowy jest przypisany do konkretnej puli, jego pojemność nie powinna być uwzględniana w przydzielonym rozmiarze puli, dopóki faktycznie nie zastąpi używanego dysku. Po dodaniu do puli, CanPooled powinna mieć wartość FALSE dla obiektu "Dysk fizyczny" tego dysku zapasowego. Należy utworzyć skojarzenie między tym obiektem dysku fizycznego a obiektem puli pamięci masowej konkretnej puli.

Pojemność z dysków o statusie zdrowia „w złej kondycji” nie powinna być uwzględniana w żadnym polu rozmiaru ani z puli pierwotnej, ani z puli konkretnej.

Stowarzyszenia

Interfejs API SM zawiera klasy skojarzeń, które definiują relacje między obiektami przechowywania. Dzięki tym klasom skojarzeń można łatwo przejść przez hierarchię obiektów magazynu w celu uzyskania powiązanych obiektów dla danego obiektu. W przypadku modułu Storage PowerShell potokowanie poleceń cmdlet jest osiągane za pomocą klas skojarzeń. Na przykład, dla obiektu dysku wirtualnego, użytkownicy mogą uzyskać pulę magazynową, do której należy obiekt dysku wirtualnego za pomocą następującego polecenia cmdlet:

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

W pozostałej części tej sekcji przedstawiono implementację klas skojarzeń. Metody w notatkach są generowane przez Convert-MofToProvider.exe dla każdej klasy skojarzeń. Notatki używają XToY jako przykładowej klasy skojarzenia; kod pseudo używa StoragePoolToVirtualDisk jako przykładu.

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

Zarządzanie pamięcią podręczną

Po załadowaniu SMP należy zainicjować pamięć podręczną obiektów pamięci masowej. Inicjalizacja ta zapewnia krótki czas odpowiedzi przy obsłudze wywołań API, ponieważ obiekty mogą być bezpośrednio pobierane z pamięci podręcznej SMP. Ta pamięć podręczna powinna być zsynchronizowana ze zmianami obiektów wewnątrz pasma i zmianami obiektów poza pasmem.

Zmiany obiektu w pasmie obejmują te zmiany wprowadzone w bieżącym wystąpieniu protokołu SMP. Jeśli na przykład dysk wirtualny jest tworzony za pomocą bieżącej instancji SMP:

  • Do pamięci podręcznej należy dodać nowy obiekt dysku wirtualnego.
  • Skojarzone obiekty, takie jak należąca pula magazynu i skojarzone obiekty portów docelowych, również powinny zostać zaktualizowane.

Zmiany poza pasmem obejmują te zmiany wprowadzone za pośrednictwem zastrzeżonych narzędzi dostawcy oraz SMP-ów działających na innych maszynach. Na przykład, jeśli dysk wirtualny jest tworzony przy użyciu oprogramowania własnościowego dostawcy, zdarzenie powinno zostać wysłane z podsystemu przechowywania danych do systemu SMP w celu wyzwolenia aktualizacji pamięci podręcznej.

Protokół SMP powinien również zaktualizować pamięć podręczną, gdy wywoływana jest metoda Discover z klasy Dostawcy magazynu. Aplikacja do zarządzania magazynem wywołuje tę metodę w celu zresetowania i ponownego skompilowania pamięci podręcznej na zdarzeniach, takich jak ponowne uruchomienie usługi lub ponowny rozruch systemu.

Jeśli nie jest to możliwe, aby protokół SMP zainicjował całą pamięć podręczną podczas uruchamiania (ze względu na zbyt wiele obiektów lub dlatego, że nie można go wykonać szybko), wówczas tylko obiekty dostawcy magazynu i podsystemu magazynowania powinny zostać załadowane do pamięci podręcznej. Aplikacje będą przeglądać właściwość CurrentCacheLevel w obiekcie podsystemu magazynowania, aby dowiedzieć się, jak głęboko pamięć podręczna została wypełniona. Użytkownik końcowy lub aplikacja jawnie ładują resztę pamięci podręcznej za pomocą metody Discover.

Operacje asynchroniczne

Każda operacja, która trwa dłużej niż 30 sekund, musi zwrócić obiekt zadania magazynowania. Metody zawierające parametr wyjściowy CreatedStorageJob najprawdopodobniej będą tego typu operacją. Dostawcy usług zarządzania pamięcią powinni zaimplementować wszystkie te metody jako operacje asynchroniczne i zwrócić dla nich obiekty zadania pamięci. Obiekt Zadania Magazynu musi zostać zwrócony do wywołującego w ciągu 30 sekund; w przeciwnym razie wywołujący może osiągnąć limit czasu, jeśli za długo czeka i nadal nie odebrał obiektu Zadania Magazynu.

Aplikacje (lub "Klient WMI") mają możliwość określenia, czy metoda powinna mieć wartość "RunAsJob", czy nie. Używany przez aplikacje interfejs API SM zawiera ten dodatkowy parametr logiczny RunAsJob i parametr wyjściowy CreatedStorageJob. Tymczasem odpowiednie metody w interfejsach SMP mają tylko jeden parametr: CreatedStorageJob. Jednak niezależnie od wartości "RunAsJob", SMPs powinny zawsze zwracać obiekty zadania magazynu dla tych metod.

Poniższe scenariusze ilustrują sekwencję wywołań operacji asynchronicznych. Element CreateVirtualDisk jest używany jako przykład:

  • Jeśli dla "RunAsJob" ustawiono wartość TRUE

    Kiedy wywołuje się CreateVirtualDisk, SSP powinni wykonać inicjowanie dla metody, rozpocząć zadanie w podsystemie magazynowania i zwrócić obiekt zadania magazynowania do wywołującego w ciągu 30 sekund. Jednak podsystem magazynowania może zająć dowolną ilość czasu na ukończenie operacji. Użytkownik monitoruje stan zadania w tym czasie.

    Wątki robocze powinny być używane do wykonywania zadań. Dla celów zwiększenia wydajności, SMP mogą aktualizować atrybuty związane ze stanem zadania (na przykład PercentComplete) tylko wtedy, gdy obiekt wywołujący sprawdza stan tego zadania.

  • Jeśli dla ustawienia "RunAsJob" ustawiono wartość FALSE

    Obiekt wywołujący zostanie zablokowany przy metodzie CreateVirtualDisk, dopóki metoda nie zwróci wyniku. Interfejs API SM automatycznie wykonuje blokowanie i sondowanie. Ten typ obiektu wywołującego jest zwykle klientem nieinterakcyjnym (na przykład narzędziem do obsługi skryptów), który preferuje mechanizm blokowania.

    Ponieważ jedynym sposobem uzyskania informacji o nowo utworzonym obiekcie jest skojarzenie między tym obiektem a odpowiadającym mu obiektem zadania przechowywania, SMP powinny przechowywać obiekt zadania przechowywania przez co najmniej 24 godziny przed usunięciem go z pamięci podręcznej. W przypadku innych operacji, które nie zwracają nowo utworzonego obiektu (na przykład operacji DeleteObject), skojarzenie nie jest potrzebne, a obiekt Zadania przechowywania musi pozostać aktywny tylko przez 15 minut.

W przypadku nieoczekiwanych ponownych uruchomień systemu na konsolach zarządzania, dostawcy zarządzania usługami (SMPs) powinni przechowywać pamięć podręczną obiektów StorageJob w lokalizacji fizycznej, na przykład w macierzy magazynowej, i załadować ją ponownie po ponownym uruchomieniu systemu.

Kontrola czasu życia dostawcy

Protokół SMP można zaimplementować jako dostawcę połączonego lub odłączonego. Aby uzyskać różnicę między tymi dwoma typami dostawców, zapoznaj się z dokumentacją MSDN usługi WMI.

Oddzielony dostawca jest ładowany i hostowany w procesie specyficznym dla dostawcy. Ten proces jest zawsze działającą usługą.

Uruchomienie dostawcy może być czasochłonne, ponieważ obejmuje ponowne ładowanie pamięci podręcznej. Jeśli uruchomienie SMP trwa więcej niż sekundę, zalecamy zaimplementowanie dostawcy niezależnego do zarządzania obiektami magazynowymi przy użyciu pamięci podręcznej trwałej. Takie podejście pomaga zwiększyć ogólną wydajność i czas odpowiedzi aplikacji korzystających z interfejsu API sm systemu Windows do zarządzania SMP.

Przykład DecoupledHost z pakietu Windows SDK zawiera więcej informacji na temat odłączonych dostawców.

Wskazania

Deweloperzy aplikacji często chcą wiedzieć, kiedy stan obiektu zmienia się w miarę zmian. Mogą to zrobić, subskrybując powiadomienia WMI. Wskazania są innym rodzajem klasy; są prezentowane asynchronicznie, czasami niezależnie od jakiejkolwiek operacji zarządzania, i nie są trwałe. Zamiast implementować znane metody wewnętrzne (czyli EnumerateInstances / GetInstance), istnieją nowe metody, które muszą być obsługiwane.

Istnieją cztery typy wskazówek:

  • Przybycie — to wskazanie jest używane podczas dodawania wystąpienia urządzenia lub obiektu do podsystemu. Na przykład: dodanie nowego dysku fizycznego do podsystemu lub utworzenie dysku wirtualnego.
  • Usunięcie: to wskazanie jest używane w przypadku usunięcia wystąpienia urządzenia lub obiektu z podsystemu. Na przykład: Usuwanie dysku fizycznego z podsystemu lub usuwanie puli pamięci masowej.
  • Modyfikuj — to wskazanie jest używane, gdy ważna właściwość zmienia się na istniejącym obiekcie. Co najmniej zmiany w HealthStatus oraz OperationalStatus muszą wyzwolić sygnał modyfikacji. Zdecydowanie zaleca się wskazanie zmiany dowolnej innej właściwości związanej ze stanem operacyjnym obiektu.
  • Alert — to wskazanie służy do powiadomienia aplikacji o potencjalnym problemie. Obecnie jedynym zdefiniowanym alertem jest powiadamianie o osiągnięciu progu alokowania elastycznego.

Aby zaimplementować wskazania, istnieją dwie nowe metody wewnętrzne, które należy zaimplementować dla każdej klasy wskazania:

  • EnableIndication — żądanie zasubskrybowania klasy powiadomień zostało złożone. WskaźnikContext należy zapisać, aby był dostępny do opublikowania w oznaczeniu w późniejszym punkcie w czasie.
  • DisableIndication: Nie ma więcej subskrybentów dla klasy wskaźnikowej. Oczyszczanie powinno nastąpić i nie należy publikować żadnych dodatkowych wskazówek dla tej klasy. funkcja indicationContext jest obecnie niszczona.

Wdrożenie

SMP są instalowane na wybranych "serwerach zarządzania". Te serwery mogą być klastrowane w celu zapewnienia nadmiarowości. Inne serwery uzyskują dostęp do magazynu przydzielonego do nich za pośrednictwem protokołu iSCSI lub Fibre Channel. Wszystkie te maszyny mogą być zarządzane przez serwery, które uruchamiają interfejs użytkownika serwera plików z Menedżera serwera.

Dostawcy pamięci masowej są jednak mile widziani, aby wybrać model wdrażania, który najlepiej spełnia ich wymagania.

Model zabezpieczeń

Interfejs SMP obsługuje model logowania jednokrotnego (SSO) przy użyciu poświadczeń zabezpieczeń systemu Windows.

W modelu jednokrotnego logowania użytkownik jednorazowo loguje się do "maszyny zarządzania" przy użyciu poświadczeń systemu Windows i automatycznie uzyskuje dostęp do wszystkich zasobów magazynu, do których ma uprawnienia dostępu. Nie jest konieczne posiadanie większej liczby poświadczeń na potrzeby logowania podsystemu magazynowania.

Interfejs umożliwia również administratorom magazynu zarządzanie kontrolą dostępu do poszczególnych zasobów magazynu. Dla każdego zasobu magazynu administratorzy magazynu mogą udzielać innym użytkownikom systemu Windows uprawnień dostępu za pomocą metod GetSecurityDescriptor i SetSecurityDescriptor. W związku z tym dostawcy smp, w przeciwieństwie do modelu VDS, mogą teraz odbierać żądania z dowolnego typu konta użytkownika.

Aby wdrożyć model jednokrotnego logowania (SSO), system zarządzania pamięcią masową (SMP) musi uwierzytelnić klientów systemu Windows w podsystemie magazynowania. Podsystem magazynu musi utrwalać informacje deskryptora zabezpieczeń dla każdego zasobu magazynu. Aby zaimplementować uwierzytelnianie, dostawcy magazynu mają dwie opcje:

  • Uwierzytelnianie w podsystemie (zalecane)
  • Uwierzytelnij się w każdej instancji SMP.

Obie opcje wymagają ustanowienia relacji zaufania między SMP i podsystemem magazynowania, aby deskryptor zabezpieczeń i informacje o tożsamości użytkownika mogły być bezpiecznie przekazywane.

Aby zaimplementować bezproblemowe uwierzytelnianie i autoryzację w podsystemie magazynowania, zalecamy połączenie między protokołem SMP i podsystemem magazynowania w celu zaimplementowania protokołu Kerberos, NTLM lub SPNego. Jeśli podsystem magazynowania ma serwer internetowy, protokół "NTLM za pośrednictwem protokołu HTTP" [MS-NLMP] może być bardziej przydatny. Dostawcy rozwiązań magazynowania danych mogą zachować własne protokoły w celu zaimplementowania modelu logowania jednokrotnego (SSO). Jednak takie podejście nie jest zalecane, ponieważ może to spowodować większą pracę lub konfigurację niż zaimplementowanie jednego z protokołów uwierzytelniania obsługiwanych przez system Windows.

Aby obsługiwać zasady zabezpieczeń systemu Windows, podsystem magazynowania musi uzyskać "informacje o tokenie" użytkownika, który zawiera identyfikator zabezpieczeń użytkownika (SID) i identyfikatory SID wszystkich grup, których użytkownik jest członkiem. Jeśli zaimplementowano protokół Kerberos, NTLM lub SPNego, podsystem magazynu uzyska informacje o tokenie użytkownika w ramach protokołu. Jeśli zastrzeżony protokół dostawcy jest używany między SMP a podsystemem magazynowania, podsystem magazynowania może wysyłać zapytania o informacje dotyczące tokenu użytkownika z usługi Active Directory za pośrednictwem protokołu LDAP (Lightweight Directory Access Protocol) i przyjrzeć się atrybutowi tokenGroupsGlobalAndUniversal lub atrybutowi Object-Sid na obiekcie konta użytkownika.

Aby, korzystając z informacji o tokenie użytkownika, wymusić zasady zabezpieczeń systemu Windows, podsystem pamięci masowej musi zaimplementować algorytm sprawdzania dostępu opisany w [MS-DTYP].

Jeśli dostawca magazynu zdecyduje się nie obsługiwać tego modelu logowania jednokrotnego, zalecamy, aby protokół SMP był zgodny z modelem zabezpieczeń z poziomu usługi VDS — zezwalając tylko na operacje inicjowane z kont administratorów. To sprawdzenie musi być jednak teraz wykonywane przez sam SMP.

  • Last updated on