SMP 동작 및 상호 작용

아티클
03/08/2023

내장 메서드 및 관리 인프라 API

SMP(스토리지 관리 공급자) 개발자는 mi.h 파일의 MI(Convert-MofToProvider.exe 및 관리 인프라) API에서 생성된 내장 메서드를 사용하여 SMP 구현을 제공합니다. 다음은 몇 가지 주요 내장 함수 및 MI 메서드에 대한 몇 가지 참고 사항입니다.

EnumerateInstances 및 GetInstance

EnumerateInstances는 특정 클래스의 인스턴스에 대한 쿼리가 있을 때 호출됩니다. 예: PowerShell cmdlet Get-Object<>는 해당 WMI 개체의 EnumerateInstances 메서드에 매핑됩니다. 이 메서드는 Object_Post 메서드를 통해 <클래스의 모든 인스턴스를> 반환해야 합니다. EnumerateInstances는 WMI에서 자주 호출되므로 신속하게 수행해야 합니다. 이는 좋은 캐시 관리를 통해 수행됩니다.

GetInstance는 클래스의 특정 instance 필요할 때 호출됩니다(예: 에 국한되지 않음).
- WMI 인프라가 이 클래스의 메서드를 호출하는 경우
- WMI 기반 애플리케이션이 이 메서드를 직접 호출하는 경우
- 연결 클래스를 통해 클래스의 instance 요청되는 경우
GetInstance 메서드는 Object>_Post 메서드를 통해 <지정된 개체만 반환해야 합니다. 일반적으로 ObjectId인 MOF에 정의된 "키"인 쿼리되는 instance 식별자는 InstanceName 매개 변수를 통해 검색됩니다. 이 메서드는 WMI에서 자주 호출되며 신속하게 완료해야 합니다.

일반 클래스(StorageProvider, StorageSubsystem, PhysicalDisk 등)의 경우 EnumerateInstances 및 GetInstance가 필수입니다. 연결 클래스의 경우 EnumerateInstances, AssociatorInstances 및 ReferenceInstances는 필수이지만 GetInstance는 필수는 아닙니다.
<개체>_Post 및 MI_PostResult

MI API 메서드 <Object>_Post 및 MI_PostResult 간의 차이점을 이해하려면 Object>_Post 출력 매개 변수에 대한 포인터를 반환하고 MI_PostResult 함수의 실행 상태 나타내는 함수 반환 값으로 간주<합니다.

각 WMI 메서드의 입력 매개 변수에서 찾을 수 있는 WMI 메서드 "context"당 한 번만 MI_PostResult 호출해야 합니다. "컨텍스트"는 WMI 콜백에 대한 포인터입니다. MI_PostResult 호출하면 이 포인터가 삭제됩니다. 따라서 다른 WMI 메서드의 본문에서 WMI 메서드를 호출하면 안 됩니다.

<반면에 개체>_Post WMI 메서드 컨텍스트당 두 번 이상 호출할 수 있습니다. 이 메서드는 일반적으로 EnumerateInstances에서 여러 개체를 반환하는 데 사용됩니다.
설정< Property> 및 ModifyInstance

내장 메서드 ModifyInstance는 Windows Storage 관리 API를 통해 지원되지 않습니다. 개체의 속성을 수정하기 위해 기본 메서드 Set<Property> 가 사용됩니다.

내장 메서드 및 MI API에 대한 자세한 내용은 Windows 8 SDK의 MI API 샘플을 참조하세요.

개체 식별

SMP 인터페이스는 개체 식별을 위해 다음 두 가지 속성 그룹을 사용합니다.

스크립팅 및 프로그래밍의 경우: ObjectId 및 UniqueId

ObjectId는 SMP 및 해당 클라이언트를 사용하여 개체의 instance 추적하기 위해 만들어지고 유지 관리되는 불투명 식별자입니다. 전역적으로 고유해야 하는 필수 속성입니다. 즉, 별도의 SMP로 관리되거나 다른 스토리지 하위 시스템에 있는 경우에도 두 개체가 동일한 ObjectId를 갖지 않아야 합니다.

개체가 두 개의 서로 다른 경로를 통해 표시되는 경우(예: 동일한 스토리지 하위 시스템을 가리키는 두 개의 개별 SMP가 있음) 동일한 개체가 두 개의 서로 다른 ObjectId와 함께 나타날 수 있습니다. 두 개체 인스턴스가 동일한 개체인지 확인하려면 UniqueId 속성을 사용합니다.

UniqueId는 전역 scope 내에서 클래스의 instance 고유하게 식별하는 데 사용되는 필수 속성입니다. 이 값은 서로 다른 관리 서버에서 실행되는 두 SMP 인스턴스 간에 동일해야 합니다. ObjectId와 달리 UniqueId는 스토리지 관리 공급자 프로세스가 아닌 스토리지 하위 시스템에 의해 유지되는 값이어야 합니다.

UniqueId는 달리 언급된 경우(예: MSFT_VirtualDisk)를 제외한 모든 불투명 값일 수 있습니다.
표시: FriendlyName 및 Name

최종 사용자는 이러한 두 속성을 활용하여 개체를 식별합니다. FriendlyName은 SMP에서 이러한 작업을 지원하는 경우 최종 사용자가 설정할 수 있는 사용자에게 친숙한 문자열입니다. FriendlyName은 고유할 필요가 없습니다. 단일 스토리지 하위 시스템의 두 개체는 동일한 FriendlyName을 공유할 수 있지만 이 방법은 권장되지 않습니다.

Name 속성은 SMP에 의해 설정되며 최종 사용자가 수정할 수 없습니다. SMP는 최종 사용자가 개체를 식별하는 데 도움이 되도록 이 속성에 추가 정보를 제공합니다. 이러한 정보는 개체의 기술적 측면을 다룰 수 있습니다. 예를 들어 스토리지 하위 시스템의 이름은 하위 시스템의 IP 또는 WWN일 수 있습니다. 이름은 일반적으로 특정 scope 고유합니다. 예를 들어 스토리지 풀의 이름은 소유 스토리지 하위 시스템에 고유해야 합니다.

오류 처리

SMP 인터페이스에는 세 가지 유형의 오류가 있습니다. SM API(Windows Storage Management API ) 반환 코드, "소프트 오류" 및 "하드 오류".

SM API 반환 코드는 각 SMP 내장 메서드에 대한 반환 값으로 나열된 오류 코드를 참조합니다. 예를 들어 "5"는 "잘못된 매개 변수"를 나타냅니다. 이러한 오류 코드는 Convert-MofToProvider.exe 생성된 메서드 구조에 정의된 MIReturn 출력 매개 변수를 통해 반환됩니다. MIReturn 값은 해당 개체의 헤더 파일에 정의된 Object> _<Method>_Set_MIReturn 통해 <설정할 수 있습니다.

가능한 경우 항상 기본값으로 SM API 오류 코드를 사용해야 합니다. 추가 정보가 필요한 경우 SMP는 MSFT_ExtendedStatus 클래스를 사용하여 외래 메서드의 호출에 대한 추가 상태 정보를 제공할 수 있습니다. 이 방법은 외적 메서드에 소프트 오류를 사용하는 것이 좋습니다.

소프트 오류는 MSFT_SoftError 클래스를 통해 반환된 오류 메시지를 참조합니다. 이러한 오류는 SM API 오류 코드를 반환할 수 없는 내장 메서드(EnumerateInstances, GetInstance 등)를 위해 설계되었습니다. 소프트 오류를 반환하려면 mi.h에 정의된 MI_WriteCimError 메서드의 "MI_Instance 오류" 매개 변수를 통해 MSFT_SoftError 파생된 소프트 오류 클래스의 인스턴스를 생성하고 반환해야 합니다. 예를 들어 스토리지 배열 로그인 중에 "올바른 자격 증명이 필요"함을 나타내기 위해 StorageSubsystem 개체에 대한 EnumerateInstances 호출 중에 "MSFT_SoftError_NotAuthenticated"의 instance 반환할 수 있습니다. 소프트 오류의 경우 MI_RESULT_OK 결과는 여전히 MI_PostResult 통해 게시되어야 합니다.

하드 오류는 mi.h 파일의 MI_Result 구조에 정의된 오류를 나타냅니다. MI API에서 반환하는 오류입니다. SMP는 반드시 필요한 경우가 아니면 이러한 오류를 스토리지 관리 애플리케이션에 직접 표면화하지 않아야 합니다. 예를 들어 "잘못된 매개 변수"의 경우 SMP는 스토리지 관리 애플리케이션에서 사용할 MI_RESULT_INVALID_PARAMETER 사용하는 대신 MIReturn을 사용하여 SM API 오류 코드 "5" – "잘못된 매개 변수"를 표시해야 합니다.

기본 풀

"사용 가능한 스토리지" 풀이라고도 하는 기본 풀은 구체적인 스토리지 풀을 만들고 삭제할 때 스토리지 용량이 그려지고 반환되는 위치입니다. 기본 풀을 만들거나 삭제하거나 수정할 수 없습니다.

SMP는 하나 이상의 기본 풀을 제공해야 합니다. 실제 디스크가 구체적인 스토리지 풀에 추가되면 실제 디스크는 여전히 기본 풀의 일부로 간주되어야 합니다.

크기 보고

스토리지 풀 개체의 다양한 크기 필드에 대해 설명하는 두 가지 특별한 경우는 핫 스페어 드라이브의 용량과 비정상 드라이브의 용량입니다.

드라이브가 핫 스페어 드라이브로 지정되면 해당 용량은 해당 기본 풀의 AllocatedSize에 포함되어야 합니다. 그러나 스토리지 배열이 핫 스페어 드라이브를 특정 콘크리트 풀에 사용하는 것을 지원하더라도 드라이브의 용량은 콘크리트 풀의 크기에 포함되지 않아야 합니다. 핫 스페어 드라이브가 특정 콘크리트 풀에 전용된 후에는 실제로 사용된 드라이브를 대체할 때까지 드라이브의 용량을 콘크리트 풀의 AllocatedSize에 포함해서는 안 됩니다. 콘크리트 풀에 추가된 경우 이 핫 스페어 드라이브의 실제 디스크 개체에 대해 CanPooled가 FALSE여야 합니다. 이 실제 디스크 개체와 콘크리트 풀의 Storage Pool 개체 간에 연결을 만들어야 합니다.

HealthStatus가 "비정상"인 드라이브의 용량은 기본 풀 또는 콘크리트 풀의 크기 필드에 포함되지 않아야 합니다.

연결

SM API에는 스토리지 개체 간의 관계를 정의하는 연결 클래스가 포함되어 있습니다. 이러한 연결 클래스를 사용하면 스토리지 개체 계층 구조를 쉽게 트래버스하여 지정된 개체에 대한 관련 개체를 가져올 수 있습니다. Storage PowerShell 모듈의 경우 연결 클래스를 통해 cmdlet 파이핑이 이루어집니다. 예를 들어 가상 디스크 개체가 제공되면 사용자는 다음 cmdlet을 통해 Virtual Disk 개체를 소유하는 스토리지 풀을 가져올 수 있습니다.

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

이 섹션의 나머지 부분에서는 연결 클래스의 구현을 보여 줍니다. 노트의 메서드는 각 연결 클래스에 대한 Convert-MofToProvider.exe 의해 생성됩니다. 참고에서는 XToY를 예제 연결 클래스로 사용합니다. 의사 코드는 StoragePoolToVirtualDisk를 예로 사용합니다.

EnumerateInstances 및 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 instance 통해 변경된 내용이 포함됩니다. 예를 들어 현재 SMP instance 통해 가상 디스크를 만드는 경우 새 가상 디스크 개체를 캐시에 추가해야 할 뿐만 아니라 소유 스토리지 풀 및 연결된 대상 포트 개체와 같은 연결된 개체도 업데이트해야 합니다.

대역 외 변경에는 공급업체 독점 도구 및 다른 컴퓨터에서 호스팅하는 SMP를 통해 수행된 변경 내용이 포함됩니다. 예를 들어 공급업체 소유 도구를 통해 가상 디스크를 만드는 경우 캐시 업데이트를 트리거하려면 스토리지 하위 시스템으로부터 SMP로 이벤트를 보내야 합니다.

SMP는 스토리지 공급자 클래스의 Discover 메서드가 호출되는 경우에도 캐시를 업데이트해야 합니다. 이 메서드는 서비스 다시 시작 또는 시스템 다시 부팅과 같은 이벤트에서 캐시를 다시 설정 및 다시 빌드하기 위해 스토리지 관리 애플리케이션에서 호출됩니다.

SMP가 시작 시 전체 캐시를 초기화할 수 없는 경우(개체가 너무 많거나 신속하게 수행할 수 없기 때문에) 스토리지 공급자 및 스토리지 하위 시스템 개체만 캐시에 로드해야 합니다. 애플리케이션은 Storage 하위 시스템 개체의 CurrentCacheLevel 속성을 확인하여 캐시가 얼마나 깊이 채워졌는지 알 수 있습니다. 캐시의 나머지 는 Discover 메서드를 통해 사용자 또는 애플리케이션에 의해 명시적으로 로드됩니다.

비동기 작업

완료하는 데 30초 이상 걸리는 모든 작업은 Storage Job 개체를 반환해야 합니다. CreatedStorageJob 출력 매개 변수를 포함하는 메서드는 이러한 유형의 작업일 가능성이 높습니다. SMP는 이러한 모든 메서드를 비동기 작업으로 구현하고 이에 대한 스토리지 작업 개체를 반환해야 합니다. Storage Job 개체는 30초 이내에 호출자에게 반환되어야 합니다. 그렇지 않으면 호출자가 너무 오래 기다렸다가 Storage Job 개체를 아직 받지 못한 경우 시간 초과될 수 있습니다.

애플리케이션(또는 "WMI 클라이언트")에는 메서드가 "RunAsJob"인지 여부를 지정하는 옵션이 있습니다. 애플리케이션에서 사용하는 SM API에는 이 추가 부울 RunAsJob 매개 변수와 CreatedStorageJob 출력 매개 변수가 포함됩니다. 한편 SMP 인터페이스의 해당 메서드에는 CreatedStorageJob 매개 변수만 있습니다. 그러나 "RunAsJob" 값에 관계없이 SMP는 항상 이러한 메서드에 대한 Storage Job 개체를 반환해야 합니다.

다음 시나리오에서는 비동기 작업의 호출 시퀀스를 보여 줍니다. CreateVirtualDisk는 다음 예제로 사용됩니다.

"RunAsJob"이 TRUE로 설정된 경우

CreateVirtualDisk가 호출되면 SMP는 메서드에 대한 초기화를 수행하고, 스토리지 하위 시스템의 작업을 시작하고, 30초 이내에 Storage Job 개체를 호출자에게 반환해야 합니다. 그러나 스토리지 하위 시스템은 작업을 완료하는 데 시간이 걸릴 수 있습니다. 호출자는 이 시간 동안 작업의 상태 폴링합니다.

작업자 스레드를 사용하여 작업을 실행해야 합니다. 효율성을 위해 SMP는 호출자가 해당 작업의 상태 폴링하는 경우에만 관련 특성(예: PercentComplete)상태 작업을 업데이트할 수 있습니다.
"RunAsJob"이 FALSE로 설정된 경우

메서드가 반환될 때까지 CreateVirtualDisk 메서드에서 호출자가 차단됩니다. 차단 및 폴링 및 는 SM API 자체에서 자동으로 수행됩니다. 이 유형의 호출자는 일반적으로 차단 메커니즘을 선호하는 비사용자 대화형 클라이언트(예: 스크립팅 도구)입니다.

새로 만든 개체에 대한 정보를 가져오는 유일한 방법은 이 개체와 해당 Storage Job 개체 간의 연결을 통해서이기 때문에 SMP는 캐시에서 제거하기 전에 적어도 24시간 동안 Storage Job 개체를 유지해야 합니다. 새로 만든 개체(예: DeleteObject 작업)를 반환하지 않는 다른 작업의 경우 연결이 필요하지 않으며 Storage Job 개체는 15분 동안만 활성 상태를 유지해야 합니다.

관리 콘솔에서 예기치 않은 시스템이 다시 시작되는 경우 SMP는 스토리지 배열과 같은 물리적 위치에서 StorageJob 개체의 캐시를 유지하고 시스템을 다시 시작할 때 캐시를 다시 로드해야 합니다.

공급자 수명 시간 제어

SMP는 결합되거나 분리된 공급자로 구현할 수 있습니다. 이러한 두 유형의 공급자 간의 차이점은 WMI MSDN 설명서를 참조하세요.

분리된 공급자는 공급업체별 프로세스에서 로드되고 호스트됩니다. 이 프로세스는 일반적으로 항상 실행되는 서비스입니다.

공급자를 시작하는 데는 캐시를 다시 로드하는 데 시간이 오래 걸릴 수 있습니다. SMP 시작 시 로드하는 데 1초 이상이 필요한 경우 영구 캐시를 통해 스토리지 개체를 관리하는 분리된 공급자를 구현하는 것이 좋습니다. 이렇게 하면 Windows SM API를 사용하여 SMP를 관리하는 애플리케이션의 전반적인 성능과 응답성을 높이는 데 도움이 됩니다.

에 대한 Windows 8 SDK의 DecoupledHost 샘플은 분리된 공급자에 대한 추가 세부 정보를 제공합니다.

표시

애플리케이션 개발자는 개체의 상태가 변경되는 시기를 알고 싶어하는 경우가 많습니다. 이 작업은 WMI 표시를 구독하여 수행할 수 있습니다. 표시는 다른 종류의 클래스입니다. 비동기적으로 노출되고 때로는 관리 작업에서 대역외로 노출되며 지속되지 않습니다. 친숙한 내장 메서드(예: EnumerateInstances/GetInstance)를 구현하는 대신 지원해야 하는 새로운 메서드가 있습니다.

다음과 같은 네 가지 유형의 표시가 있습니다.

도착 – 이 표시는 디바이스 또는 개체 instance 하위 시스템에 추가되는 경우에 사용됩니다. 예를 들어 하위 시스템에 새 실제 디스크를 추가하거나 가상 디스크를 만듭니다.
출발 – 이 표시는 디바이스 또는 개체 instance 하위 시스템으로부터 제거될 때 사용됩니다. 예를 들어 하위 시스템으로부터 실제 디스크를 제거하거나 스토리지 풀을 삭제합니다.
수정 – 이 표시는 기존 개체에서 중요한 속성이 변경되는 경우에 사용됩니다. 최소한 HealthStatus 및 OperationalStatus 변경 내용이 수정 표시를 트리거해야 합니다. 개체의 작동 상태 관련된 다른 속성의 변경을 나타내는 것이 좋습니다.
경고 – 이 표시는 애플리케이션에 잠재적인 문제를 경고하는 데 사용됩니다. 현재 정의된 유일한 경고는 씬 프로비저닝 임계값에 도달할 때 알리는 것입니다.

표시를 구현하려면 각 표시 클래스에 대해 구현해야 하는 두 가지 새로운 내장 메서드가 있습니다.

EnableIndication – 표시 클래스를 구독하라는 요청이 수행되었습니다. 나중에 표시에 게시할 수 있도록 indicationContext를 저장해야 합니다.
DisableIndication – 표시 클래스에 대한 구독자가 더 이상 없습니다. 정리가 수행되어야 하며 이 클래스에 대한 표시를 더 이상 게시하지 않아야 합니다. indicationContext는 현재 제거됩니다.

배포

SMP는 선택한 "관리 서버"에 설치됩니다. 이러한 서버는 중복성을 제공하도록 클러스터될 수 있습니다. 다른 서버는 iSCSI 또는 파이버 채널을 통해 할당된 스토리지에 액세스합니다. 이러한 모든 컴퓨터는 서버 관리자 파일 서버 사용자 인터페이스를 실행하는 서버에서 관리할 수 있습니다.

그러나 스토리지 공급업체는 요구 사항에 가장 적합한 배포 모델을 선택할 수 있습니다.

보안 모델

SMP 인터페이스는 Windows 보안 자격 증명을 사용하여 SSO(단일 Sign-On) 모델을 지원합니다.

SSO 모델에서 사용자는 자신의 Windows 자격 증명을 사용하여 "관리 머신"에 한 번 로그인하고 액세스 권한이 있는 모든 스토리지 자산에 자동으로 액세스 권한을 얻습니다. 스토리지 하위 시스템 로그인에 대한 추가 자격 증명을 지정할 필요가 없습니다.

또한 인터페이스를 사용하면 스토리지 관리자가 개별 스토리지 자산에 대한 액세스 제어를 관리할 수 있습니다. 각 스토리지 자산에 대해 스토리지 관리자는 GetSecurityDescriptor 및 SetSecurityDescriptor 메서드를 통해 모든 Windows 사용자에게 서로 다른 액세스 권한을 부여할 수 있습니다. 따라서 VDS 모델과 달리 SMP는 이제 모든 유형의 사용자 계정에서 요청을 받을 수 있습니다.

SSO 모델을 구현하려면 SMP가 스토리지 하위 시스템에 Windows 클라이언트를 인증해야 합니다. 스토리지 하위 시스템은 각 스토리지 자산에 대한 보안 설명자 정보를 유지해야 합니다. 인증을 구현하기 위해 스토리지 공급업체에는 다음 두 가지 옵션이 있습니다.

하위 시스템에 인증(권장)
각 SMP instance 인증합니다.

두 옵션 모두 보안 설명자와 사용자 ID 정보를 안전하게 전달할 수 있도록 SMP와 스토리지 하위 시스템 간에 트러스트 관계를 설정해야 합니다.

스토리지 하위 시스템에 원활한 인증 및 권한 부여를 구현하려면 SMP와 스토리지 하위 시스템 간의 링크를 사용하여 Kerberos, NTLM 또는 SPNego를 구현하는 것이 좋습니다. 스토리지 하위 시스템에 웹 서버가 있는 경우 "NTLM over HTTP" 프로토콜 [MS-NLMP]이 더 유용할 수 있습니다. 스토리지 공급업체는 SSO 모델을 구현하기 위해 자체 프로토콜을 유지하도록 선택할 수 있지만 Windows 지원 인증 프로토콜 중 하나를 구현하는 것보다 더 많은 작업 또는 설정이 발생할 수 있으므로 권장되지 않습니다.

Windows 보안 정책을 지원하려면 스토리지 하위 시스템은 사용자의 SID(보안 식별자) 및 사용자가 속한 그룹의 SID를 포함하는 사용자의 "토큰 정보"를 가져와야 합니다. Kerberos, NTLM 또는 SPNego 프로토콜이 구현되면 스토리지 하위 시스템은 프로토콜의 일부로 사용자의 토큰 정보를 가져옵니다. SMP와 스토리지 하위 시스템 간에 공급업체의 독점 프로토콜을 사용하는 경우 스토리지 하위 시스템은 LDAP(Lightweight Directory Access Protocol)를 통해 Active Directory에서 사용자의 토큰 정보를 쿼리하고 사용자 계정 개체의 tokenGroupsGlobalAndUniversal 특성 또는 Object-Sid 특성을 확인할 수 있습니다.

사용자의 토큰 정보를 사용하여 Windows 보안 정책을 적용하려면 스토리지 하위 시스템이 [MS-DTYP]에 설명된 액세스 검사 알고리즘을 구현해야 합니다.

스토리지 공급업체가 이 SSO 모델을 지원하지 않도록 선택하는 경우 SMP가 VDS의 보안 모델을 따르는 것이 좋습니다. 관리자 계정에서 시작된 작업만 허용합니다. 그러나 이 검사 이제 SMP 자체에서 수행해야 합니다.

다음을 통해 공유