ONTAP Select 로컬 연결 스토리지용 하드웨어 RAID 서비스
하드웨어 RAID 컨트롤러를 사용할 수 있는 경우, ONTAP Select는 쓰기 성능 향상과 물리적 드라이브 오류 방지를 위해 RAID 서비스를 하드웨어 컨트롤러로 옮길 수 있습니다. 결과적으로 ONTAP Select 클러스터 내 모든 노드의 RAID 보호는 ONTAP 소프트웨어 RAID가 아닌 로컬에 연결된 RAID 컨트롤러를 통해 제공됩니다.
|
|
ONTAP Select 데이터 애그리게이트는 물리적 RAID 컨트롤러가 기본 드라이브에 RAID 스트라이핑을 제공하기 때문에 RAID 0을 사용하도록 구성됩니다. 다른 RAID 레벨은 지원되지 않습니다. |
로컬 연결 스토리지용 RAID 컨트롤러 구성
ONTAP Select에 백업 스토리지를 제공하는 모든 로컬 연결 디스크는 RAID 컨트롤러 뒤에 있어야 합니다. 대부분의 일반 하드웨어는 다양한 가격대에 걸쳐 여러 RAID 컨트롤러 옵션을 제공하며, 각각 다양한 수준의 기능을 제공합니다. 목표는 컨트롤러에 요구되는 최소 요구 사항을 충족하는 한, 가능한 한 많은 옵션을 지원하는 것입니다.
|
|
하드웨어 RAID 구성을 사용하는 ONTAP Select VM에서는 가상 디스크를 분리할 수 없습니다. 디스크 분리는 소프트웨어 RAID 구성을 사용하는 ONTAP Select VM에서만 지원됩니다. 자세한 내용은 "ONTAP Select 소프트웨어 RAID 구성에서 장애가 발생한 드라이브 교체"을(를) 참조하십시오. |
ONTAP Select 디스크를 관리하는 RAID 컨트롤러는 다음 요구 사항을 충족해야 합니다.
-
하드웨어 RAID 컨트롤러는 배터리 백업 장치(BBU) 또는 플래시 백업 쓰기 캐시(FBWC)를 갖추고 12Gbps의 처리량을 지원해야 합니다.
-
RAID 컨트롤러는 최소 하나 또는 두 개의 디스크 장애를 견딜 수 있는 모드(RAID 5 및 RAID 6)를 지원해야 합니다.
-
드라이브 캐시를 비활성화해야 합니다.
-
쓰기 정책은 BBU 또는 플래시 장애 발생 시 write through로 대체되는 writeback 모드로 구성되어야 합니다.
-
읽기에 대한 I/O 정책은 캐시됨으로 설정해야 합니다.
ONTAP Select에 백업 스토리지를 제공하는 모든 로컬 연결 디스크는 RAID 5 또는 RAID 6으로 구성된 RAID 그룹에 배치해야 합니다. SAS 드라이브 및 SSD의 경우 최대 24개의 드라이브로 구성된 RAID 그룹을 사용하면 ONTAP가 들어오는 읽기 요청을 더 많은 디스크에 분산하여 성능을 향상시킬 수 있습니다. 이를 통해 상당한 성능 향상을 얻을 수 있습니다. SAS/SSD 구성의 경우 단일 LUN 구성과 다중 LUN 구성에 대한 성능 테스트를 수행했습니다. 큰 차이가 발견되지 않았으므로 간단하게 하기 위해 NetApp은 구성 요구 사항을 충족하는 데 필요한 최소한의 LUN을 생성하는 것을 권장합니다.
NL-SAS 및 SATA 드라이브는 서로 다른 모범 사례를 요구합니다. 성능상의 이유로 최소 디스크 수는 여전히 8개이지만 RAID 그룹 크기는 12개 드라이브를 초과하지 않아야 합니다. NetApp에서는 RAID 그룹당 1개의 스페어를 사용할 것을 권장하지만 모든 RAID 그룹에 대해 글로벌 스페어를 사용할 수도 있습니다. 예를 들어, 각 RAID 그룹이 8~12개의 드라이브로 구성된 경우 3개의 RAID 그룹마다 2개의 스페어를 사용할 수 있습니다.
|
|
이전 ESXi 릴리스의 최대 익스텐트 및 데이터스토어 크기는 64TB이므로 이러한 대용량 드라이브에서 제공하는 전체 RAW 용량을 지원하는 데 필요한 LUN 수에 영향을 미칠 수 있습니다. |
RAID 모드
많은 RAID 컨트롤러는 최대 세 가지 작동 모드를 지원하며, 각 모드는 쓰기 요청이 거치는 데이터 경로에 상당한 차이를 나타냅니다. 이 세 가지 모드는 다음과 같습니다.
-
Writethrough. 모든 수신 I/O 요청은 RAID 컨트롤러 캐시에 기록된 후, 요청을 호스트에 다시 확인하기 전에 즉시 디스크로 플러시됩니다.
-
Writearound. 모든 수신 I/O 요청은 RAID 컨트롤러 캐시를 우회하여 직접 디스크에 기록됩니다.
-
쓰기 지연(Writeback). 모든 수신 I/O 요청은 컨트롤러 캐시에 직접 기록되고 호스트에 즉시 확인 응답이 전송됩니다. 데이터 블록은 컨트롤러를 사용하여 비동기식으로 디스크에 플러시됩니다.
쓰기 지연 모드는 가장 짧은 데이터 경로를 제공하며, 블록이 캐시에 들어간 직후 I/O 승인이 즉시 발생합니다. 이 모드는 읽기/쓰기 혼합 워크로드에서 가장 낮은 지연 시간과 가장 높은 처리량을 제공합니다. 그러나 BBU 또는 비휘발성 플래시 기술이 없는 경우, 이 모드로 작동하는 동안 시스템에 정전이 발생하면 데이터 손실 위험이 있습니다.
ONTAP Select에는 배터리 백업 또는 플래시 장치가 필요합니다. 따라서 이러한 유형의 장애 발생 시 캐시된 블록이 디스크로 플러시된다는 것을 확신할 수 있습니다. 이러한 이유로 RAID 컨트롤러는 writeback 모드로 구성되어야 합니다.
ONTAP Select와 OS 간에 공유되는 로컬 디스크
가장 일반적인 서버 구성은 로컬에 연결된 모든 하드 드라이브가 단일 RAID 컨트롤러 뒤에 있는 구성입니다. 하이퍼바이저용 LUN 하나와 ONTAP Select VM용 LUN 하나, 총 최소 두 개의 LUN을 프로비저닝해야 합니다.
예를 들어, 내장 드라이브 6개와 Smart Array P420i RAID 컨트롤러 하나가 장착된 HP DL380 g8을 생각해 보겠습니다. 모든 내장 드라이브는 이 RAID 컨트롤러로 관리되며, 시스템에는 다른 스토리지가 없습니다.
다음 그림은 이러한 구성 스타일을 보여줍니다. 이 예에서는 시스템에 다른 스토리지가 없으므로 하이퍼바이저가 ONTAP Select 노드와 스토리지를 공유해야 합니다.
RAID 관리 스핀들만 사용하는 서버 LUN 구성

ONTAP Select와 동일한 RAID 그룹에서 OS LUN을 프로비저닝하면 하이퍼바이저 OS(및 해당 스토리지에서 프로비저닝된 모든 클라이언트 VM)가 RAID 보호의 이점을 누릴 수 있습니다. 이 구성은 단일 드라이브 오류로 인해 전체 시스템이 다운되는 것을 방지할 수 있습니다.
로컬 디스크는 ONTAP Select와 OS로 분할됩니다
서버 공급업체에서 제공하는 또 다른 가능한 구성은 여러 개의 RAID 또는 디스크 컨트롤러를 사용하여 시스템을 구성하는 것입니다. 이 구성에서는 하나의 디스크 컨트롤러가 디스크 세트를 관리하며, 이 컨트롤러는 RAID 서비스를 제공할 수도 있고 제공하지 않을 수도 있습니다. 두 번째 디스크 세트는 RAID 5/6 서비스를 제공할 수 있는 하드웨어 RAID 컨트롤러가 관리합니다.
이러한 구성 스타일에서는 RAID 5/6 서비스를 제공할 수 있는 RAID 컨트롤러 뒤에 있는 스핀들 세트를 ONTAP Select VM에서만 사용해야 합니다. 관리하는 총 스토리지 용량에 따라 디스크 스핀들을 하나 이상의 RAID 그룹과 하나 이상의 LUN으로 구성해야 합니다. 이러한 LUN을 사용하여 하나 이상의 데이터스토어를 생성하고, 모든 데이터스토어는 RAID 컨트롤러로 보호됩니다.
다음 그림과 같이 첫 번째 디스크 세트는 하이퍼바이저 OS와 ONTAP 스토리지를 사용하지 않는 모든 클라이언트 VM을 위해 예약되어 있습니다.
혼합 RAID/비RAID 시스템에서의 서버 LUN 구성

다중 LUN
단일 RAID 그룹/단일 LUN 구성은 다음 두 가지 경우에 변경해야 합니다. NL-SAS 또는 SATA 드라이브를 사용하는 경우 RAID 그룹 크기는 12개 드라이브를 초과해서는 안 됩니다. 또한 단일 LUN이 기본 하이퍼바이저 스토리지 제한(개별 파일 시스템 익스텐트 최대 크기 또는 전체 스토리지 풀 최대 크기)보다 커질 수 있습니다. 이 경우 파일 시스템을 성공적으로 생성하려면 기본 물리적 스토리지를 여러 개의 LUN으로 분할해야 합니다.
VMware vSphere 가상 머신 파일 시스템 제한 사항
일부 ESXi 버전에서 데이터 저장소의 최대 크기는 64TB입니다.
서버에 64TB 이상의 스토리지가 연결된 경우, 64TB보다 작은 여러 개의 LUN을 프로비저닝해야 할 수 있습니다. SATA/NL-SAS 드라이브의 RAID 재구축 시간을 개선하기 위해 여러 개의 RAID 그룹을 생성하는 경우에도 여러 개의 LUN이 프로비저닝됩니다.
여러 개의 LUN이 필요한 경우, 가장 중요한 고려 사항 중 하나는 이러한 LUN들이 유사하고 일관된 성능을 갖도록 하는 것입니다. 특히 모든 LUN을 단일 ONTAP 애그리게이트에서 사용할 경우 더욱 중요합니다. 반대로, 하나 이상의 LUN 중 일부가 확연히 다른 성능 프로필을 가져야 하는 경우, 이러한 LUN들을 별도의 ONTAP 애그리게이트에 격리하는 것을 강력히 권장합니다.
여러 파일 시스템 익스텐트를 사용하여 최대 데이터스토어 크기까지 단일 데이터스토어를 생성할 수 있습니다. ONTAP Select 라이센스가 필요한 용량을 제한하려면 클러스터 설치 중에 용량 상한을 지정해야 합니다. 이 기능을 통해 ONTAP Select는 데이터스토어 공간의 일부만 사용할 수 있으며(따라서 해당 공간에 대해서만 라이센스 필요), 이를 활용할 수 있습니다.
또는 단일 LUN에 단일 데이터스토어를 생성하는 것으로 시작할 수 있습니다. 더 큰 ONTAP Select 용량 라이센스가 필요한 추가 공간이 필요한 경우, 해당 공간을 데이터스토어의 최대 크기까지 익스텐트로 동일한 데이터스토어에 추가할 수 있습니다. 최대 크기에 도달한 후에는 새 데이터스토어를 생성하여 ONTAP Select에 추가할 수 있습니다. 두 가지 유형의 용량 확장 작업 모두 지원되며 ONTAP Deploy 스토리지 추가 기능을 사용하여 수행할 수 있습니다. 각 ONTAP Select 노드는 최대 400TB의 스토리지를 지원하도록 구성할 수 있습니다. 여러 데이터스토어에서 용량을 프로비저닝하려면 두 단계 프로세스가 필요합니다.
초기 클러스터 생성은 초기 데이터 저장소의 공간 일부 또는 전부를 사용하여 ONTAP Select 클러스터를 생성하는 데 사용할 수 있습니다. 두 번째 단계는 원하는 총 용량에 도달할 때까지 추가 데이터 저장소를 사용하여 하나 이상의 용량 추가 작업을 수행하는 것입니다. 이 기능에 대한 자세한 내용은 "스토리지 용량 증가" 섹션을 참조하십시오.
|
|
VMFS 오버헤드는 0이 아니며(VMware KB 1001618 참조), 데이터스토어에서 사용 가능하다고 보고된 전체 공간을 사용하려고 하면 클러스터 생성 작업 중에 잘못된 오류가 발생했습니다. |
각 데이터스토어에는 2%의 버퍼 공간이 사용되지 않은 상태로 남아 있습니다. 이 공간은 ONTAP Select에서 사용하지 않으므로 용량 라이센스가 필요하지 않습니다. ONTAP Deploy는 용량 제한이 지정되지 않은 경우 버퍼에 필요한 정확한 기가바이트 수를 자동으로 계산합니다. 용량 제한이 지정된 경우 해당 크기가 우선적으로 적용됩니다. 용량 제한 크기가 버퍼 크기 내에 있는 경우 클러스터 생성이 실패하고 용량 제한으로 사용할 수 있는 올바른 최대 크기 매개변수를 지정하는 오류 메시지가 표시됩니다.
“InvalidPoolCapacitySize: Invalid capacity specified for storage pool “ontap-select-storage-pool”, Specified value: 34334204 GB. Available (after leaving 2% overhead space): 30948”
VMFS 6은 신규 설치는 물론 기존 ONTAP Deploy 또는 ONTAP Select VM의 Storage vMotion 작업 대상으로서도 지원됩니다.
VMware는 VMFS 5에서 VMFS 6으로의 인플레이스 업그레이드를 지원하지 않습니다. 따라서 Storage vMotion은 VMFS 5 데이터스토어에서 VMFS 6 데이터스토어로 VM을 이전할 수 있는 유일한 방법입니다. 하지만 ONTAP Select 및 ONTAP Deploy의 Storage vMotion 지원이 VMFS 5에서 VMFS 6으로의 이전이라는 특정 목적 외에도 다른 시나리오를 지원하도록 확장되었습니다.
ONTAP Select 가상 디스크
기본적으로 ONTAP Select는 하나 이상의 스토리지 풀에서 프로비저닝된 가상 디스크 세트를 ONTAP에 제공합니다. ONTAP은 이러한 가상 디스크 세트를 물리적 디스크처럼 처리하며, 스토리지 스택의 나머지 부분은 하이퍼바이저에 의해 추상화됩니다. 다음 그림은 물리적 RAID 컨트롤러, 하이퍼바이저 및 ONTAP Select VM 간의 관계를 자세히 보여줍니다.
-
RAID 그룹 및 LUN 구성은 서버의 RAID 컨트롤러 소프트웨어 내에서 수행됩니다. VSAN 또는 외부 어레이를 사용하는 경우에는 이러한 구성이 필요하지 않습니다.
-
스토리지 풀 구성은 하이퍼바이저 내에서 수행됩니다.
-
가상 디스크는 개별 VM에서 생성 및 소유합니다. 이 예에서는 ONTAP Select입니다.
가상 디스크에서 물리적 디스크로 매핑

가상 디스크 프로비저닝
보다 간소화된 사용자 경험을 제공하기 위해 ONTAP Select 관리 툴인 ONTAP Deploy는 연결된 스토리지 풀에서 가상 디스크를 자동으로 프로비저닝하고 ONTAP Select VM에 연결합니다. 이 작업은 초기 설정 및 스토리지 추가 작업 중에 자동으로 수행됩니다. ONTAP Select 노드가 HA 쌍의 일부인 경우 가상 디스크는 로컬 및 미러 스토리지 풀에 자동으로 할당됩니다.
ONTAP Select는 연결된 기본 스토리지를 각각 최대 16TB의 동일한 크기의 가상 디스크로 분할합니다. ONTAP Select 노드가 HA 쌍의 일부인 경우 각 클러스터 노드에 최소 2개의 가상 디스크가 생성되어 로컬 플렉스와 미러 플렉스에 할당되어 미러링된 애그리게이트 내에서 사용됩니다.
예를 들어, ONTAP Select에 31TB(VM 배포 및 시스템/루트 디스크 프로비저닝 후 남은 공간) 크기의 데이터스토어 또는 LUN을 할당할 수 있습니다. 그러면 약 7.75TB 크기의 가상 디스크 4개가 생성되어 해당 ONTAP 로컬 및 미러 플렉스에 할당됩니다.
|
|
ONTAP Select VM에 용량을 추가하면 VMDK 크기가 서로 달라질 수 있습니다. 자세한 내용은 해당 섹션을 참조하십시오"스토리지 용량 증가". FAS 시스템과 달리 동일한 애그리게이트 내에 크기가 다른 VMDK가 존재할 수 있습니다. ONTAP Select는 이러한 VMDK에 걸쳐 RAID 0 스트라이프를 사용하므로 VMDK 크기에 관계없이 각 VMDK의 모든 공간을 최대한 활용할 수 있습니다. |
가상화된 NVRAM
NetApp FAS 시스템에는 일반적으로 비휘발성 플래시 메모리가 포함된 고성능 물리적 NVRAM PCI 카드가 장착됩니다. 이 카드는 ONTAP에서 클라이언트로 들어오는 쓰기를 즉시 승인할 수 있도록 하여 쓰기 성능을 크게 향상시킵니다. 또한 디스테이징이라고 하는 프로세스를 통해 수정된 데이터 블록을 속도가 느린 스토리지 미디어로 이동하도록 예약할 수 있습니다.
일반 하드웨어에는 일반적으로 이러한 유형의 장비가 장착되어 있지 않습니다. 따라서 이 NVRAM 카드의 기능은 가상화되어 ONTAP Select 시스템 부팅 디스크의 파티션에 배치됩니다. 이러한 이유로 인스턴스의 시스템 가상 디스크 배치는 매우 중요합니다. 또한 이 제품이 로컬 연결 스토리지 구성에 복원력 있는 캐시를 갖춘 물리적 RAID 컨트롤러를 필요로 하는 이유도 바로 이 때문입니다.
NVRAM은 자체 VMDK에 배치됩니다. NVRAM을 자체 VMDK로 분리하면 ONTAP Select VM이 vNVMe 드라이버를 사용하여 NVRAM VMDK와 통신할 수 있습니다. 또한 ONTAP Select VM은 ESXi 8.0 이상과 호환되는 하드웨어 버전 13을 사용해야 합니다.
데이터 경로 설명: NVRAM 및 RAID 컨트롤러
가상화된 NVRAM 시스템 파티션과 RAID 컨트롤러 간의 상호 작용은 쓰기 요청이 시스템에 들어올 때 거치는 데이터 경로를 살펴보면 가장 잘 이해할 수 있습니다.
ONTAP Select VM으로 들어오는 쓰기 요청은 VM의 NVRAM 파티션을 대상으로 합니다. 가상화 계층에서 이 파티션은 ONTAP Select VM에 연결된 VMDK인 ONTAP Select 시스템 디스크 내에 존재합니다. 물리적 계층에서 이러한 요청은 하위 스핀들을 대상으로 하는 모든 블록 변경과 마찬가지로 로컬 RAID 컨트롤러에 캐시됩니다. 여기에서 쓰기는 호스트로 승인됩니다.
이 시점에서 물리적으로 해당 블록은 RAID 컨트롤러 캐시에 저장되어 디스크에 기록될 때까지 대기합니다. 논리적으로는 해당 블록이 NVRAM에 저장되어 적절한 사용자 데이터 디스크로 이동될 때까지 대기합니다.
변경된 블록이 RAID 컨트롤러의 로컬 캐시에 자동으로 저장되므로 NVRAM 파티션에 대한 쓰기 작업은 자동으로 캐시되고 주기적으로 물리적 스토리지 매체로 플러시됩니다. 이는 NVRAM 내용이 ONTAP 데이터 디스크로 주기적으로 플러시되는 것과 혼동해서는 안 됩니다. 이 두 가지 이벤트는 서로 관련이 없으며 발생 시점과 빈도도 다릅니다.
다음 그림은 들어오는 쓰기 작업이 거치는 I/O 경로를 보여줍니다. 이 그림은 물리적 계층(RAID 컨트롤러 캐시 및 디스크로 표현됨)과 가상 계층(VM의 NVRAM 및 데이터 가상 디스크로 표현됨) 간의 차이점을 강조합니다.
|
|
NVRAM VMDK에서 변경된 블록은 로컬 RAID 컨트롤러 캐시에 캐시되지만 캐시는 VM 구성 또는 가상 디스크를 인식하지 못합니다. 시스템의 모든 변경된 블록을 저장하며, NVRAM은 그 중 일부일 뿐입니다. 여기에는 동일한 백업 스핀들에서 프로비저닝된 경우 하이퍼바이저로 향하는 쓰기 요청이 포함됩니다. |
ONTAP Select VM에 대한 수신 쓰기

|
|
NVRAM 파티션은 자체 VMDK에서 분리됩니다. 해당 VMDK는 ESXi 버전 8.0 이상에서 사용 가능한 vNVME 드라이버를 사용하여 연결됩니다. 이 변경 사항은 RAID 컨트롤러 캐시의 이점을 활용하지 않는 소프트웨어 RAID가 있는 ONTAP Select 설치에 가장 중요합니다. |