xiRAID를 이용한 고밀도 Solidigm QLC 드라이브의 RAID 재구축 가속화 및 쓰기 증폭 감소

배경

스토리지 시장에서는 성능 또는 용량 자체에 집중하기 보다, 이제는 와트당 성능 및 와트당 용량을 강조하는 방향으로 바뀌고 있습니다. 이처럼 전력을 중시하는 변화는 빠르게 확장되는 AI 배포로 인해 거의 하룻밤 사이에 이루어졌습니다. 오늘날의 글로벌 전력 인프라는 한계에 다다른 상태이며, 기업들은 AI 혁명을 지속하고 기존 및 신규 데이터센터에 전력을 공급하기 위해 심지어 원자력까지도 포함한 추가 에너지원을 적극적으로 찾아 나서고 있습니다. 이러한 변화와 함께, 드라이브당 및 와트당 더 큰 저장 용량을 제공할 수 있는 QLC 기술이 급부상하고 있습니다. 기업들은 점점 더 큰 용량의 스토리지 수요에 대응하기 위해 인프라를 개발하고 있습니다. 드라이브가 커짐에 따라, 새로운 우려사항, 특히 신뢰성과 장애 발생 시 복구 시간이라는 문제를 해결해야 합니다. 이는 타당한 우려사항이며 Solidigm과 Xinnor가 대응해야 할 우선적 사안입니다.

이전 자료인 Xinnor xiRAID 및 고밀도 Solidigm QLC 드라이브를 이용한 최적의 RAID 솔루션에서 우리는 고밀도 61.44TB QLC SSD인 Solidigm™ D5-P5336¹과, NVMe 드라이브의 높은 수준의 병렬 작업을 처리하기 위해 특별히 설계된 소프트웨어 기반 RAID 솔루션인 Xinnor xiRAID,²를 이용하여 RAID5의 성능을 선보인 바 있습니다. 소프트웨어 RAID의 신뢰성과 QLC의 대용량을 이용하여, 신뢰성을 저해하지 않으면서 대용량을 필요로 하는 모든 구축 환경에 적합한 솔루션을 시연했습니다. RAID5 구성의 성능 및 쓰기 증폭 계수(WAF) 관련 결과는 위에서 언급한 솔루션 브리프에 포함되어 있습니다. 

이 문서에서는 RAID 어레이 내에서 드라이브를 재구축하는 데 걸리는 시간을 측정함으로써 대용량 QLC 드라이브의 재구축 시간에 관한 관심사를 다루기로 합니다. 그리고, 재구축 프로세스 중에 이뤄지는 쓰기 증폭도 함께 검사합니다. 

쓰기 증폭 계수(WAF)

쓰기 증폭 계수는 NAND SSD의 내구성과 관련하여 잘 알려진 요소입니다. 호스트 쓰기 및 NAND 쓰기는 WAF를 계산하기 위해 워크로드 전후로 SSD SMART 로그를 통해 기록됩니다. 이는 또한 스토리지 스택 효율성의 척도이기도 합니다. WAF는 주어진 애플리케이션 워크로드에 대한 NAND 쓰기 수와 호스트 쓰기 수의 비율입니다. WAF는 다음 공식을 이용하여 계산합니다.

WAF = 워크로드에 대한 NAND 쓰기의 수/워크로드에 대한 호스트 쓰기의 수

이상적인 상황에서는 호스트 쓰기 하나는 정확히 하나의 NAND 쓰기 하나로 이어지며, 이 경우 WAF는 1입니다. 그러나 많은 요인으로 인해 각 호스트 쓰기에 대해 여러 개의 NAND 쓰기가 발생합니다. QLC 드라이브는 8K~64K 범위에 이르는 더 높은 간접 유닛을 사용합니다. 간접 단위는 용량이 커질수록 증가합니다. 

여기에는 비용 및 전력이라는 두 가지 주요 이유가 있습니다. 첫째, QLC 드라이브의 경우에 SSD 내 DRAM 용량을 저용량 드라이브와 동일한 크기로 유지하면 비용상의 이점이 있습니다. 둘째, 고밀도 QLC 드라이브를 저용량 드라이브와 동일한 전력 예산에 맞출 수 있습니다. 이러한 요인들에 더해, Gen4 링크를 포화시킬 만큼의 읽기 성능과 HDD보다 훨씬 뛰어난 쓰기 성능은 고객이 스토리지 인프라를 업그레이드하여 AI 목표를 충족하면서도 총 소유 비용(TCO) 측면에서 이점을 확보할 수 있게 해줍니다.

NAND 미디어 관점에서 자세히 살펴보면, 호스트가 간접 유닛 크기와 일치하는 IO 크기로 데이터를 쓰고, IO가 간접 유닛과 정렬되어 있을 경우, IO는 물리적 NAND 미디어에 기록됩니다. 즉, 추가 쓰기 작업이 발생하지 않습니다. 그러나 1) IO 크기가 간접 유닛 크기와 다르거나 2) IO가 정렬되지 않는 경우, NAND의 물리적 특성상 먼저 블록을 읽은 후, 해당 IO가 기록될 부분을 수정하고, 마지막으로 이를 다시 미디어에 다시 기록해야 합니다. 이를 읽기-수정-쓰기 작업이라고 하며, 이는 쓰기 증폭이 더 커지는 주된 원인입니다. 호스트 스택은 일반적으로 약 4KB IO 크기로 최적화되어 있으며 이러한 작은 IO를 대형 간접 유닛에 쓰면 쓰기 증폭이 커질 수 있습니다. 읽기-수정-쓰기에는 호스트 애플리케이션의 워크로드를 처리하는 데 사용할 수 있었을 성능 사이클도 사용합니다.

이 주제에 대한 자세한 내용은 위에서 언급한 솔루션 브리프를 참조하십시오. 솔루션 브리프의 결과를 요약하자면, 애플리케이션 워크로드를 최적화하는 방법을 제시했으며, xiRAID 아키텍처가 가진, 청크 크기를 변경할 수 있는 유연성 덕분에 QLC 드라이브에서의 읽기-수정-쓰기 사이클을 최소화하고, 이를 통해 RAID 어레이의 성능 잠재력을 어떻게 최대화할 수 있었는지 시연했습니다.

RAID 재구축 및 관련 문제

패리티 RAID는 패리티 드라이브를 보호 메커니즘으로 사용하여 폴트 방지 및 데이터 이중화 기능을 제공하는 RAID 어레이입니다. RAID5는 한 패리티 드라이브가 있는 패리티 RAID의 예이며, RAID6에는 두 패리티 드라이브가 있습니다. 다른 패리티 RAID 구성도 있지만, RAID5와 RAID6이 가장 일반적으로 사용됩니다. 패리티 RAID(예: RAID5, RAID6 등)에 대한 패리티 계산은 RAID 신드롬 계산의 수학적 공식을 기반으로 합니다. 이러한 계산에는 RAID 엔진의 계산 이행의 효율성에 따라 시간이 많이 소요될 수 있습니다. 패리티 RAID 재구축은 어레이 내에서 고장 난 드라이브를 교체하기 위해 RAID 구성에 삽입된 새 드라이브에 대해, RAID가 데이터 컨텐츠를 재계산하는 과정입니다. 재구축 프로세스 중에 RAID 엔진은 각 RAID 스트라이프에 대해 나머지 상태가 좋은 드라이브에서 데이터를 읽고 계산 알고리즘을 이용하여 새 드라이브에 기록할 값을 계산합니다.

RAID가 드라이브 중 하나 이상을 잃고 재구축 프로세스가 시작되지 않은 채 성능 저하 모드에서 작동하거나, RAID의 드라이브 하나 이상이 재구축 중인 재구축 모드에서 작동할 때는 다음과 같은 문제들이 발생할 수 있습니다.

• RAID 어레이의 신뢰성이 떨어집니다.
• RAID 성능이 저하됩니다.

그렇기 때문에 RAID 재구축 속도가 매우 중요합니다. 재구축을 더 빨리 완료할수록 RAID 어레이가 성능 저하와 고장 위험이 증가한 상태로 작동해야 하는 시간이 줄어듭니다. 재구축 시간은 RAID 드라이브 크기에 비례하여 선형으로 증가합니다. 어레이 내 고장 드라이브가 큰 것일수록 재구축 시간이 길어집니다. 드라이브 용량이 계속 증가함에 따라 RAID 엔진은 매우 높은 효율성을 갖추고 드라이브의 기본 성능에 맞는 속도로 재구축 과정을 처리할 수 있어야 합니다.

RAID 재구축 성능 측정

고밀도 드라이브로 RAID 어레이를 재구축하는 것에 대한 우려와 소프트웨어의 높은 효율성에 대한 관련 요구사항에 따라 xiRAID가 있는 RAID5 어레이에서 Solidigm의 고밀도 QLC 61.44TB 드라이브의 실제 성능을 측정하기로 했습니다. 다음 섹션에서는 일련의 실험과 그 결과를 안내해 드리겠습니다. 우리가 측정한 결과와 비교 및 대조하기 위해 오픈 소스 소프트웨어 RAID 솔루션인 mdraid를 선택했습니다. 또한 최상의 시나리오와 최악의 시나리오를 검증하기 위해 호스트 워크로드가 있을 때와 없을 때의 재구축을 실행해 보았습니다.

호스트 워크로드가 없을 때의 재구축

이 테스트는 각 RAID 엔진(mdraid 및 xiRAID Classic 4.3)에 대해 다음 순서대로 진행했습니다.

1. 기본 매개변수로 9개의 데이터 드라이브를 이용하여 RAID5 어레이를 생성 

2. RAID 재구축 매개변수를 다음과 같이 설정

• mdadm의 경우, 이론적 재구축 속도 제한이 200MB/s에서 9GB/s로 증가했습니다. 
  echo 9000000 > /proc/sys/dev/raid/speed_limit_max
• xiRAID Classic의 경우, 재구축 우선 순위 매개변수를 80%로 설정했습니다(기본 설정은 50%). 
  xicli raid modify -n <raid_name> -rcp 80

3. RAID 초기화가 완료될 때까지 대기

4. SMART 로그에서 새 데이터 드라이브의 nand_bytes_written 및 host_bytes_written 매개 변수 확인 이는 드라이브의 WAF를 계산하는 데 사용했습니다. 이 드라이브는 RAID에 속하지 않는 교체 드라이브였습니다. 

• nand_bytes_written 및 host_bytes_written를 확인하기 위해 nvme solidigm smart-log-add /dev/nvme1n1을 실행했습니다.

5. RAID 어레이의 드라이브를 4단계의 드라이브로 교체 교체 시간 확인

6. 프로세스가 완료된 후 시스템 로그에서 재구축 시간 확인 

7. 4단계에서 설명한 대로 재구축된 데이터 드라이브의 nand_bytes_written 및 host_bytes_written 매개 변수 확인

8. 다음 공식을 사용하여 WAF를 계산

• (nand_bytes_written after the test - nand_bytes_written before the test)/(host_bytes_written after the test - host_bytes_written before the test)

9. 재구축된 드라이브의 재구축 시간 계산

결과는 표 1에 제시했습니다.

표 1. 호스트 워크로드가 없을 때의 RAID 재구축

결과 요약

호스트 워크로드가 없을 때는 xiRAID를 사용하면 mdraid에 비해 재구축 시간이 10배 더 짧았습니다. 워크로드가 없는 61.44TB QLC 드라이브의 경우, mdraid를 이용한 재구축 시간은 약 2.25일(~51시간)이지만, xiRAID를 사용하면 몇 시간 만에 재구축할 수 있습니다. xiRAID는 Solidigm D5-P5336 SSD의 전체 원시 순차 대역폭을 활용하여 빠른 재구축 시간을 구현할 수 있습니다. 이러한 유형의 재구축은 예상되는 호스트 워크로드 유휴 기간에 시작할 수 있습니다. 

호스트 워크로드가 있을 때의 재구축

이 테스트는 각 RAID 엔진(mdraid 및 xiRAID Classic 4.3)에 대해 다음 순서대로 진행했습니다.

1. 기본 매개변수로 9개의 데이터 드라이브를 이용하여 RAID5 어레이를 생성 

2. RAID 재구축 매개변수를 다음과 같이 설정

• mdadm의 경우, 이론적 재구축 속도 제한이 200MB/s에서 9GB/s로 증가했습니다. 
  echo 9000000 > /proc/sys/dev/raid/speed_limit_max
• xiRAID Classic의 경우, 재구축 우선순위 매개변수를 80%(기본값은 50%)로 설정했습니다. 
  xicli raid modify -n <raid_name> -rcp 80

3. RAID 초기화가 완료될 때까지 대기

4. SMART 로그에서 새 데이터 드라이브의 nand_bytes_written 및 host_bytes_written 매개 변수 확인 이는 드라이브의 WAF를 계산하는 데 사용했습니다. 이 드라이브는 RAID에 속하지 않는 교체 드라이브였습니다. 

• nand_bytes_written 및 host_bytes_written를 확인하기 위해 nvme solidigm smart-log-add /dev/nvme1n1을 실행했습니다.

 5. 다음과 같은 FIO 혼합 작업을 개시

     [global]
     iodepth=64
     direct=1
     ioengine=libaio
     group_reporting
     runtime=604800  # seconds(1 week)

    
      [write]
      rw=write
      bs=1MB
      numjobs=38
      offset_increment=15G
      filename=/dev/xi_test

   
       [read]
       rw=read
       bs=1MB
       numjobs=90
       offset_increment=10G
       filename=/dev/xi_test

6. RAID의 드라이브를 4단계의 드라이브로 교체 교체 시간 확인

7. 프로세스가 완료된 후 시스템 로그에서 재구축 시간 확인 

8. 4단계에서 설명한 대로 재구축된 데이터 드라이브의 nand_bytes_written 및 host_bytes_written 매개 변수 다시 확인

9. 다음 공식을 사용하여 WAF를 계산

• (nand_bytes_written after the test - nand_bytes_written before the test)/(host_bytes_written after the test - host_bytes_written before the test)

10. 재구축된 드라이브의 재구축 시간 계산

호스트 워크로드(약 10.5MB/s)가 있을 때의 mdraid 재구축 속도는 너무 느려서 합리적인 시간 내에 61.44TB 드라이브 전체의 재구축을 완료할 수 없었습니다. mdraid에 대한 재구축 시간 결과는 재구축 속도에 따라 근사치로 계산되었습니다.

결과는 표 2에 제시했습니다.

표 2. 호스트 워크로드가 있을 때의 RAID 재구축

결과 요약

호스트 IO가 드라이브 재구축이 완료될 때까지 기다릴 수 없는 경우, 대용량 드라이브에서는 mdraid를 사용할 수 없게 됩니다. 드라이브를 재구축하는 데 2개월 이상이 걸릴 수 있으므로 RAID 어레이는 다음 번 드라이브 장애로 인한 잠재적인 데이터 손실에 노출됩니다. 반면 xiRAID는 호스트 워크로드가 실행 중인 상태에서도, mdraid가 워크로드 없이 재구축할 때와 동일한 수준의 재구축 성능을 제공합니다. RAID 어레이의 Solidigm D5-P5336 61.44TB QLC 드라이브는 호스트 워크로드와 재구축 로직을 통해 전송된 소프트웨어 스택에서 혼합 IO를 처리할 수 있습니다.

결론

이번 결과는 RAID 어레이에 고밀도 드라이브를 재구축하는 데 오랜 시간이 걸리므로 RAID 솔루션으로는 좋은 선택이 아니라는 통념을 불식시키는 데 힘을 실어 줍니다. 이러한 우려는 NVMe 드라이브에 최적화되지 않은 RAID 엔진에도 유효하지만, mdraid의 경우와 마찬가지로 xiRAID Classic 4.3이 호스트 워크로드가 없을 때는 몇 시간 만에 Solidigm 61.44TB QLC 드라이브를 재구축할 수 있음을 실험을 통해 입증했습니다. 호스트 워크로드가 동시에 실행되는 경우에도 WAF를 1에 가깝게 유지하면서, 재구축 시간은 이틀을 약간 넘는 정도로 증가합니다. 이는 또 Solidigm의 고밀도 QLC SSD가 고성능 소프트웨어 스택의 요구를 충분히 감당할 수 있으며, 재구축 입출력을 처리하면서 읽기 및 쓰기가 혼합된 호스트 워크로드를 무리 없이 수행할 수 있음을 보여주기도 하는 것입니다. Solidigm D5-P5336 QLC SSD 본연의 잠재 역량이 없으면, 재구축에 오랜시간(경우에 따라 수개월)이 걸리고 호스트 IO 또한 제대로 처리되지 않을 수 있습니다.

• 호스트 워크로드가 없을 때 재구축하는 경우: xiRAID를 이용한 Solidigm 61.44TB QLC 재구축은 mdraid보다 약 10배 빠르며 WAF는 15% 더 작습니다.
• 호스트 워크로드가 있는 상태에서 재구축하는 경우: 동일한 Solidigm 61.44TB QLC를 xiRAID로 재구축하면 약 30배 더 빠르고 WAF는 23% 더 작아집니다.

이러한 결과는 xiRAID Classic 4.3이 Solidigm 고밀도 QLC 드라이브 RAID 구축에 훨씬 더 적합하며, 빠르고 활발한 재구축 중에도 호스트가 RAID에 계속 접근할 수 있게 유지된다는 것을 보여줍니다.