스토리지 가상 머신(SVM)은 ONTAP 시스템에서 테넌트 간의 격리 및 관리 분리를 제공합니다. 애플리케이션에 SVM을 전용으로 사용하면 권한 위임이 가능하고 리소스 사용량을 제한하기 위한 모범 사례를 적용할 수 있습니다.

SVM 관리에는 여러 가지 옵션이 있습니다.

각 경우에 인터페이스는 DNS에 등록되어 있어야 하며, Trident를 구성할 때 DNS 이름을 사용해야 합니다. 이렇게 하면 네트워크 ID 보존을 사용하지 않고도 SVM-DR과 같은 일부 재해 복구 시나리오를 구현할 수 있습니다.

SVM에 전용 관리 LIF를 사용할지 공유 관리 LIF를 사용할지 여부는 중요하지 않지만, 선택한 방식에 맞춰 네트워크 보안 정책을 수립해야 합니다. 관계없이, 관리 LIF는 DNS를 통해 액세스할 수 있어야 하며, "SVM-DR"Trident와 함께 사용될 경우 최대한의 유연성을 제공할 수 있습니다.

ONTAP 스토리지 시스템에는 최대 볼륨 수가 있으며, 이는 소프트웨어 버전 및 하드웨어 플랫폼에 따라 다릅니다. 특정 플랫폼 및 ONTAP 버전에 대한 정확한 제한 사항을 확인하려면 "NetApp Hardware Universe"을 참조하십시오. 볼륨 수가 소진되면 Trident뿐만 아니라 모든 스토리지 요청에 대한 프로비저닝 작업이 실패합니다.

Trident의 ontap-nas 및 ontap-san 드라이버는 생성되는 각 Kubernetes 영구 볼륨(PV)에 대해 FlexVolume을 프로비저닝합니다. ontap-nas-economy 드라이버는 약 200개의 PV마다 하나의 FlexVolume을 생성합니다(50~300 사이에서 구성 가능). ontap-san-economy 드라이버는 약 100개의 PV마다 하나의 FlexVolume을 생성합니다(50~200 사이에서 구성 가능). Trident가 스토리지 시스템에서 사용 가능한 모든 볼륨을 소비하지 않도록 하려면 SVM에 제한을 설정해야 합니다. 명령줄에서 이 작업을 수행할 수 있습니다.

예를 들어, 2노드 ONTAP 클러스터는 최대 2000개의 FlexVol 볼륨을 호스팅할 수 있습니다. 최대 볼륨 수를 1250으로 설정하는 것은 매우 적절해 보입니다. 그러나 한 노드에서만 "애그리게이트"이 SVM에 할당되거나, 한 노드에서 할당된 애그리게이트에 대해 프로비저닝이 불가능한 경우(예: 용량 부족), 다른 노드가 모든 Trident 프로비저닝 볼륨의 대상이 됩니다. 이는 max-volumes 값에 도달하기 전에 해당 노드의 볼륨 제한에 도달할 수 있음을 의미하며, Trident 및 해당 노드를 사용하는 다른 볼륨 작업 모두에 영향을 미칠 수 있습니다. 클러스터의 각 노드에서 Trident가 사용하는 SVM에 동일한 수의 애그리게이트가 할당되도록 하면 이러한 상황을 방지할 수 있습니다.

NetApp Trident는 ontap-nas, ontap-san 및 solidfire-san 스토리지 드라이버를 사용할 때 볼륨 복제를 지원합니다. ontap-nas-flexgroup 또는 ontap-nas-economy 드라이버를 사용할 때는 복제가 지원되지 않습니다. 기존 볼륨에서 새 볼륨을 생성하면 새 스냅샷이 생성됩니다.

Trident에서 생성할 수 있는 볼륨의 최대 크기를 구성하려면, limitVolumeSize 매개변수를 backend.json 정의에 사용하십시오.

스토리지 어레이에서 볼륨 크기를 제어하는 것 외에도 Kubernetes 기능을 활용해야 합니다.

ontap-san-economy 및 ontap-nas-economy 드라이버의 풀로 사용되는 FlexVols의 최대 크기를 구성하려면, limitVolumePoolSize 매개변수를 backend.json 정의에 사용하십시오.

백엔드 정의에서 CHAP 이니시에이터 및 대상 사용자 이름과 암호를 지정하고 Trident가 SVM에서 CHAP를 활성화하도록 설정할 수 있습니다. 백엔드 구성에서 useCHAP 매개 변수를 사용하면 Trident는 CHAP를 통해 ONTAP 백엔드에 대한 iSCSI 연결을 인증합니다.

SVM에 적용되는 ONTAP QoS 정책을 활용하면 Trident 프로비저닝된 볼륨이 소비할 수 있는 IOPS 수를 제한할 수 있습니다. 이는 "괴롭힘을 예방하다" 또는 제어 불능 상태의 컨테이너가 Trident SVM 외부의 워크로드에 영향을 미치는 것을 방지하는 데 도움이 됩니다.

몇 단계만 거치면 SVM에 대한 QoS 정책을 생성할 수 있습니다. 가장 정확한 정보는 사용 중인 ONTAP 버전의 설명서를 참조하십시오. 아래 예시는 SVM에서 사용 가능한 총 IOPS를 5000으로 제한하는 QoS 정책을 생성합니다.

또한, 사용 중인 ONTAP 버전에서 지원하는 경우, 컨테이너화된 워크로드에 일정량의 처리량을 보장하기 위해 QoS 최소값을 사용하는 것을 고려할 수 있습니다. 적응형 QoS는 SVM 수준 정책과 호환되지 않습니다.

컨테이너화된 워크로드에 할당되는 IOPS 수는 여러 요소에 따라 달라집니다. 그중에서도 다음과 같은 요소들이 포함됩니다:

SVM 레벨에서 할당된 QoS 정책은 해당 SVM에 프로비저닝된 모든 볼륨이 동일한 IOPS 풀을 공유하게 된다는 점을 기억하는 것이 중요합니다. 컨테이너화된 애플리케이션 중 하나 또는 소수의 애플리케이션이 높은 IOPS 요구 사항을 가질 경우, 다른 컨테이너화된 워크로드에 과도한 부담을 줄 수 있습니다. 이러한 경우, 외부 자동화 도구를 사용하여 볼륨별 QoS 정책을 할당하는 것을 고려해 볼 수 있습니다.

QoS(서비스 품질)는 중요한 워크로드의 성능이 경쟁 워크로드로 인해 저하되지 않도록 보장합니다. ONTAP QoS 정책 그룹은 볼륨에 대한 QoS 옵션을 제공하며, 사용자가 하나 이상의 워크로드에 대한 처리량 상한을 정의할 수 있도록 합니다. QoS에 대한 자세한 내용은 "QoS를 통해 처리량 보장"을 참조하십시오. QoS 정책 그룹은 백엔드 또는 스토리지 풀에 지정할 수 있으며, 해당 풀 또는 백엔드에 생성된 각 볼륨에 적용됩니다.

ONTAP에는 기존 QoS 정책 그룹과 적응형 QoS 정책 그룹 두 가지 유형이 있습니다. 기존 정책 그룹은 IOPS 기준으로 최대(또는 최신 버전에서는 최소) 처리량을 고정적으로 제공합니다. 적응형 QoS는 워크로드 크기에 따라 처리량을 자동으로 확장하여 워크로드 크기 변화에 따른 IOPS 대 TB/GB 비율을 유지합니다. 이는 대규모 배포 환경에서 수백 또는 수천 개의 워크로드를 관리할 때 상당한 이점을 제공합니다.

QoS 정책 그룹을 생성할 때 다음 사항을 고려하십시오.

QoS 정책 그룹에 대한 자세한 내용은 "ONTAP 명령 참조"를 참조하십시오.

Trident에서 생성한 NFS 볼륨, iSCSI LUN 및 FC LUN에 대한 액세스를 제한하는 것은 Kubernetes 배포 환경의 보안 태세에서 중요한 구성 요소입니다. 이를 통해 Kubernetes 클러스터에 속하지 않은 호스트가 해당 볼륨에 액세스하여 예기치 않게 데이터를 수정하는 것을 방지할 수 있습니다.

Kubernetes에서 네임스페이스는 리소스의 논리적 경계라는 점을 이해하는 것이 중요합니다. 동일한 네임스페이스 내의 리소스는 공유될 수 있다는 가정이 있지만, 중요한 것은 네임스페이스 간 기능이 없다는 것입니다. 즉, PV는 전역 객체이지만 PVC에 바인딩되면 동일한 네임스페이스에 있는 Pod에서만 액세스할 수 있습니다. 적절한 경우 네임스페이스를 사용하여 분리를 제공하는 것이 중요합니다.

Kubernetes 환경에서 데이터 보안과 관련하여 대부분의 조직이 가장 우려하는 사항은 컨테이너의 프로세스가 호스트에 마운트된 스토리지에 액세스할 수 있지만 컨테이너용이 아니라는 점입니다. "네임스페이스"는 이러한 유형의 침해를 방지하도록 설계되었습니다. 그러나 예외가 하나 있습니다. 바로 권한 있는 컨테이너입니다.

특권 컨테이너는 일반 컨테이너보다 훨씬 더 많은 호스트 수준 권한으로 실행되는 컨테이너입니다. 이러한 권한은 기본적으로 거부되지 않으므로 "Pod 보안 정책"을 사용하여 해당 기능을 비활성화해야 합니다.

Kubernetes와 외부 호스트 모두에서 액세스가 필요한 볼륨의 경우, 스토리지는 기존 방식으로 관리되어야 하며, PV는 관리자가 도입하고 Trident에서 관리하지 않아야 합니다. 이렇게 하면 Kubernetes와 외부 호스트 모두 연결이 끊어지고 더 이상 볼륨을 사용하지 않을 때만 스토리지 볼륨이 삭제됩니다. 또한, 사용자 지정 내보내기 정책을 적용하여 Kubernetes 클러스터 노드와 Kubernetes 클러스터 외부의 대상 서버에서 액세스할 수 있도록 할 수 있습니다.

전용 인프라 노드(예: OpenShift) 또는 사용자 애플리케이션 예약이 불가능한 노드가 있는 배포 환경의 경우, 스토리지 리소스에 대한 액세스를 더욱 제한하기 위해 별도의 내보내기 정책을 사용해야 합니다. 여기에는 해당 인프라 노드에 배포된 서비스(예: OpenShift 메트릭 및 로깅 서비스)와 인프라 노드가 아닌 곳에 배포된 표준 애플리케이션에 대한 내보내기 정책을 생성하는 것이 포함됩니다.

각 백엔드에 대해 Kubernetes 클러스터에 있는 노드에만 액세스를 허용하는 엑스포트 정책이 있는지 확인해야 합니다. Trident는 엑스포트 정책을 자동으로 생성하고 관리할 수 있습니다. 이를 통해 Trident는 프로비저닝하는 볼륨에 대한 액세스를 Kubernetes 클러스터의 노드로 제한하고 노드 추가/삭제를 간소화합니다.

또는 수동으로 엑스포트 정책을 생성하고 각 노드 액세스 요청을 처리하는 하나 이상의 엑스포트 규칙을 추가할 수도 있습니다.

이러한 명령을 실행하면 데이터에 액세스할 수 있는 Kubernetes 노드를 제한할 수 있습니다.

SVM 레벨 ONTAP CLI 명령을 사용하여 showmount 비활성화해야 합니다.

각 SolidFire 계정은 고유한 볼륨 소유자를 나타내며 고유한 CHAP(Challenge-Handshake Authentication Protocol) 자격 증명 세트를 받습니다. 계정에 할당된 볼륨은 계정 이름과 관련 CHAP 자격 증명을 사용하거나 볼륨 액세스 그룹을 통해 액세스할 수 있습니다. 계정에는 최대 2,000개의 볼륨을 할당할 수 있지만 볼륨은 하나의 계정에만 속할 수 있습니다.

여러 볼륨에 적용할 수 있는 표준화된 서비스 품질 설정을 생성하고 저장하려면 SolidFire QoS(Quality of Service) 정책을 사용하십시오.

볼륨별로 QoS 파라미터를 설정할 수 있습니다. QoS를 정의하는 세 가지 구성 가능한 파라미터(최소 IOPS, 최대 IOPS, 버스트 IOPS)를 설정하여 각 볼륨의 성능을 보장할 수 있습니다.

다음은 4Kb 블록 크기에 대한 최소, 최대 및 버스트 IOPS 값입니다.

블록 크기와 대역폭은 IOPS 수에 직접적인 영향을 미칩니다. 블록 크기가 증가함에 따라 시스템은 더 큰 블록 크기를 처리하는 데 필요한 수준까지 대역폭을 증가시킵니다. 대역폭이 증가하면 시스템이 달성할 수 있는 IOPS 수는 감소합니다. QoS 및 성능에 대한 자세한 내용은 "SolidFire 서비스 품질"을 참조하십시오.

Element는 CHAP와 VAG(Volume Access Groups)라는 두 가지 인증 방식을 지원합니다. CHAP는 CHAP 프로토콜을 사용하여 호스트를 백엔드에 인증합니다. Volume Access Groups는 프로비저닝하는 볼륨에 대한 액세스를 제어합니다. NetApp은 CHAP 인증 방식이 더 간단하고 확장성에 제한이 없으므로 CHAP 사용을 권장합니다.

CHAP 인증(시작자가 의도된 볼륨 사용자인지 확인하는 인증)은 계정 기반 액세스 제어에서만 지원됩니다. CHAP를 사용하여 인증하는 경우 단방향 CHAP와 양방향 CHAP의 두 가지 옵션을 사용할 수 있습니다. 단방향 CHAP는 SolidFire 계정 이름과 시작자 암호를 사용하여 볼륨 액세스를 인증합니다. 양방향 CHAP 옵션은 볼륨이 계정 이름과 시작자 암호를 통해 호스트를 인증하고, 호스트는 계정 이름과 대상 암호를 통해 볼륨을 인증하는 가장 안전한 방법입니다.

하지만 CHAP를 활성화할 수 없고 VAG가 필요한 경우 액세스 그룹을 생성하고 호스트 이니시에이터와 볼륨을 액세스 그룹에 추가하십시오. 액세스 그룹에 추가하는 각 IQN은 CHAP 인증 여부와 관계없이 그룹의 각 볼륨에 액세스할 수 있습니다. iSCSI 이니시에이터가 CHAP 인증을 사용하도록 구성된 경우 계정 기반 액세스 제어가 사용됩니다. iSCSI 이니시에이터가 CHAP 인증을 사용하도록 구성되지 않은 경우 Volume Access Group 액세스 제어가 사용됩니다.