Solidigm CSAL이란

CSAL ( Cloud Storage Accelerate Layer)

기존에 PoseidonOS (https://github.com/poseidonos/poseidonos)와 비슷한 설루션이 최근에 출시되었다고 확인되어서 그 대상인 CSAL에 대해서 조금 더 자세히 알아보기 위해서 글을 작성한다.

CSAL의 아키텍처

기본적인 구조는 위와 같다.

여러 SSD를 묶어서 Volume의 형태로 만드는 Software Defined Storage 형태를 가정하고 있는 것으로 확인된다. (이는 PoseidonOS도 동일하다)

성능을 보정해 주기 위해서 Write Buffer 역할을 하는 SLC SSD를 두었다.

일부 SLC와 큰 용량의 QLC를 사용하는 것으로 확인된다.

TLC SSD만 사용하는 옵션도 있는데 어떤 경위로 이 두 가지로 나누었는지는 정확히는 모르겠다. 이제 알아봐야 할 듯.

 

Solidigm에서 주장하는 CSAL의 장점

아래와 같은 요소들을 장점으로 제시한다.

Solidigm이 주장하는 CSAL의 장점

1. TLC read performance를 유지하면서 DRAM/SSD의 cost를 줄일 수 있다고 한다. (메타데이터를 줄이는 듯)

정확한 해석은 4K mapping -> 16K mapping을 해서 메타데이터 사용량을 줄였다가 1번의 핵심인듯하다.

CSAL 관련 기사 중 Write Amplification 부분

4k mapping -> 16k mapping을 쓰면서 메타데이터 양을 줄여 DRAM/SSD의 사용량을 줄일 수 있는 반면, Write Amplification이 증가한다고 한다.

2. 여러 클라우드 application/사용자가 큰 용량의 SSD를 공유해서 사용할 수 있다고 한다. 따라서, capacity와 performance utilization을 늘릴 수 있다고 한다.

실제 사용할 수 있는 방식인지는 의문, 큰 용량 그 자체로 써야 의미 있어 보이고, 고 성능은 기대하기 힘들어 보임.

다만, 속도가 중요하지 않고 고용량만

3. RAID5를 지원하여 data protection과 reliability를 향상했다고 한다.

스토리지라면 당연히 지원해야 하는 MVP 기능이므로 pass

4. 여러 사용자가 쓰는 환경에서 write amplification을 줄일 수 있다고 한다.

mixed 패턴의 IO가 들어오면 random 한 data placement가 많다는 점이 문제라서, SSD의 수명이 상당히 낮아질 수 있는데 이런 문제를 효율적인 data placement를 통해서 해결하겠다는 것으로 보인다.

단순하게는 SLC로 write를 모아서 특정값 이상 쌓이면 QLC로 sequential 하게 내려서 효율을 추구하겠다는 것으로 보인다.

 

예상 성능 

오른쪽에 SLC + QLC가 실제 CSAL의 성능이라고 보면 될것같다.

Network bound가 11.4GB/s라고 한다. 

고 성능의 Network 카드는 100 GbE 단위로 사용하는데 이 단위와 환산해 봤을 때 아래와 같은 결론이 나온다.

GPT의 답변
11.4GB/s의 네트워크 바운드를 갖추기 위해서는 100 GbE NIC 카드가 1개 필요합니다.
이 계산은 11.4GB/s를 91.2 Gbps로 환산하고, 100 GbE NIC의 속도로 나누어서 얻은 결과입니다. 

성능상 보았을 때 100 GbE 카드는 하나만 가지고 있는 HW를 가정하는 것으로 보인다.

그 이상의 성능은 낼 수 없기 때문일 수도 있고 회사 내부 정보나 구현은 모르기 때문에 섣불리 결론을 낼 수는 없다.

그리고 Virtual drive는 고정 사이즈로 일단 구현한것처럼 보인다. (확실한지는 모르겠다. 코드나 demo를 실행해봐야 정확히 알듯)

 

CSAL에서는 두가지 케이스를 비교한다. 

1. TLC 10개 without CSAL 과 2. SLC 3개 + QLC 7개 with CSAL

아마도 후자가 더 좋음을 알려주기 위함으로 생각된다.

 

후자의 경우 344TB가 사용가능하다고 한다.

SLC : 800GB 3개 + QLC : 61.44 TB * 7개 => 2.4TB + 430 TB 

SLC는 버퍼로 쓰니까 뺴고, QLC 6개는 이론상 368TB인데, 24TB는 메타데이터가 저장되니까 뺀건가 싶다.

16K mapping 이면 대충 맞나?

16K 블럭당 128 byte 저장하면 2.8TB라고 하니 16K 블럭당 1KB 정도 저장하면 24TB가 메타데이터 저장하는 용량

344TB가 유저데이터를 위한 공간으로 저장될 수 있을것 같다. (다만 비교를 위한 TLC 용량은 좀 대충 계산한거같아 보이긴하는데..) 

 

그림에서는 SLC + DRAM에서 L2P를 처리했다고 하니 메타데이터가 생각보다 더 많이 작은가 싶기도하다.

정확하게는 모르겠다.
1. QLC에도 메타데이터를 저장하는 케이스와 2. SLC에만 메타데이터를 저장하는 케이스가 가능은 할거같다.

 

성능 관점에서는 SLC 2~3개가 Striping 해서 받아줄 수 있는 성능 정도로 느껴지긴한다.

아래는 해당 SLC 모델의 성능을 캡처해왔다. ( 순차읽기 : 6.4. GB/s, 순차 쓰기: 4 GB/s)

따라서, Write buffer 이상의 성능을 낼수는 없으니 100GbE NIC을 하나만 써서 그정도로 HW를 최적화 했다고 보는게 맞을거같긴하다.

 

참고 : 솔리다임 SLC 모델

D7-P5810

 

 

알리바바와 협업한 결과물

A Media-Aware Cloud Storage Acceleration Layer (CSAL) Cache Solution with Intel® Optane™ SSDs for Alibaba ECS Local Disk D3C

위 링크를 통해서 White papar를 확인할 수 있다.

Background나 실제 활용같은게 적혀있는것 같은데, 피곤하니 다음 포스트에서 적어야겠다 ㅎㅎ..

 

참고 링크

CSAL: QLC Game-Changer and Open-Source Solution for the Future

A CSAL-Based Reference Storage Platform

Cloud Storage Acceleration Layer (CSAL)

Solidigm solves the DRAM SSD issue with new D7-P5810 SLC SSD and CSAL software - Architecting IT