[논문 리뷰] Understanding NVMe Zoned Namespace (ZNS) Flash SSD Storage Devices

Nick Tehrany, Animesh Trivedi|arXiv (Cornell University)|2022. 06. 03.

Advanced Data Storage Technologies인용 수 6

한 줄 요약

이 논문은 NVMe Zoned Namespace (ZNS) SSD의 체계적인 성능 평가를 제시하며, 리눅스에서 블록 수준 통합을 분석하고, 더 큰 I/O 크기(≥16KiB)가 장치 대역폭을 포화시키기 위해 필요하다는 점을 규명한다. 또한 I/O 스케줄러 설정이 워크로드 패턴에 따라 성능에 큰 영향을 미친다는 점을 밝혀내며, 실험적 측정 기반으로 ZNS 스토리지 스택 통합을 최적화하기 위한 초보적 지침을 제공한다. 또한 존 관리 및 다중 워크로드 간 간섭과 같은 주요 과제를 제기한다.

ABSTRACT

The standardization of NVMe Zoned Namespaces (ZNS) in the NVMe 2.0 specification presents a unique new addition to storage devices. Unlike traditional SSDs, where the flash media management idiosyncrasies are hidden behind a flash translation layer (FTL) inside the device, ZNS devices push certain operations regarding data placement and garbage collection out from the device to the host. This allows the host to achieve more optimal data placement and predictable garbage collection overheads, along with lower device write amplification. Thus, additionally increasing flash media lifetime. As a result, ZNS devices are gaining significant attention in the research community. However, with the current software stack there are numerous ways of integrating ZNS devices into a host system. In this work, we begin to systematically analyze the integration options, report on the current software support for ZNS devices in the Linux Kernel, and provide an initial set of performance measurements. Our main findings show that larger I/O sizes are required to saturate the ZNS device bandwidth, and configuration of the I/O scheduler can provide workload dependent performance gains, requiring careful consideration of ZNS integration and configuration depending on the application workload and its access patterns. Our dataset and code are available at https: //github.com/nicktehrany/ZNS-Study.

연구 동기 및 목표

• ZNS SSD를 호스트 스토리지 스택에 통합할 때의 성능 영향을 체계적으로 평가하는 것, 특히 블록 장치 수준에서의 영향을 중심으로 한다.
• 고성능을 달성하기 위한 최적의 설정 전략—특히 I/O 크기와 스케줄러 선택—을 규명하는 것.
• ZNS 스토리지에 대응하는 시스템 설계자 및 애플리케이션 개발자에게 실질적인 개발 지침을 제공하는 것.
• 공유된 ZNS 장치에서 존 관리, 쓰레기 수거, 다중 애플리케이션 간 간섭과 같은 과제를 탐색하는 것.
• 미래의 ZNS 연구 및 통합 노력에서 피해야 할 실험의 실수와 함정을 기록하고 문서화하는 것.

제안 방법

• 표준화된 I/O 워크로드를 사용하여 순차적 및 무작위 읽기/쓰기 워크로드에서 ZNS SSD 성능을 벤치마킹하고, 다양한 I/O 크기를 변화시켜 분석한다.
• 다양한 액세스 패턴 하에서 ZNS 장치 성능에 미치는 다양한 I/O 스케줄러(예: mq-deadline, kyber)의 영향을 평가한다.
• 리눅스 커널의 dm-zap 디바이스 매핑 모듈을 통해 블록 수준의 ZNS 통합을 구현하고 테스트한다.
• 고도로 사용된 장치(예: 95% 포화 상태)에서 쓰레기 수거 동작과 성능 저하를 분석한다.
• 공개된 GitHub 리포지토리에 포괄적인 데이터셋, 벤치마킹 스크립트, 설정 지침을 수집하고 배포한다.
• 동일한 ZNS 장치 또는 네임스페이스를 공유하는 다중 애플리케이션 간의 간섭을 평가하기 위한 통제된 실험을 수행한다.

실험 결과

연구 질문

• RQ1 순차적 및 무작위 워크로드 하에서 다양한 I/O 크기와 I/O 스케줄러 설정이 ZNS SSD 성능에 미치는 영향은 무엇인가?
• RQ2 다양한 통합 수준(블록, 파일 시스템, 애플리케이션)과 장치 사용률 수준에서 쓰레기 수거 성능은 어떻게 달라지는가?
• RQ3 동일한 ZNS 장치에서 동시 실행되는 애플리케이션 간의 간섭 정도는 어떠한가, 특히 쓰레기 수거 및 I/O 스케줄링 측면에서 말이다?
• RQ4 기존 리눅스 스토리지 스택에 ZNS 장치를 통합할 때 주요 성능 저하 요인과 잘못된 설정은 무엇인가?
• RQ5 장치가 활성 존 수를 제한하지만 할당 정책을 강제하지 않는 한계가 있는 상황에서, 다수의 네임스페이스와 애플리케이션 간 존 관리 및 공정한 자원 공유를 어떻게 보장할 수 있는가?

주요 결과

• ZNS 장치에서 순차적 읽기 성능은 순차적 쓰기 성능보다 거의 두 배 높으며, 이는 성능 측면에서 상당한 비대칭성을 보임을 시사한다.
• 장치 대역폭을 포화시키기 위해서는 16KiB 이상의 I/O 크기 필요하며, 이는 작은 I/O가 고대역폭 워크로드에 최적화되어 있지 않음을 의미한다.
• I/O 스케줄러 선택(예: mq-deadline 대비 kyber)은 워크로드 패턴에 따라 성능 향상을 이끌어내며, 어떤 스케줄러도 항상 최적은 아님을 확인하였다.
• 95% 장치 사용률에 도달할 경우, 쓰레기 수거 오버헤드가 더욱 두드러지며, 특히 무작위 쓰기 워크로드에서 두드러진다. 이는 워크로드 인식 기반의 세밀한 튜닝이 필요함을 시사한다.
• ZNS 장치에는 다수의 네임스페이스나 애플리케이션 간 활성 존 제한을 관리할 수 있는 강제 메커니즘이 현재 존재하지 않으며, 공정한 자원 공유를 위해 외부 존 관리가 필수적임을 확인하였다.
• 기존 소프트웨어 스택에는 존 인식 쓰레기 수거 정책이 기본적으로 통합되어 있지 않으며, 파일 시스템 수준의 최적화—예를 들어 생성일 또는 사망일 기준으로 파일을 그룹화하는 것—이 성능 향상에 상당한 기여를 할 수 있음을 규명하였다.