ASPLOS 2020
개요
증가하는 클라우드 storage스택은 x86시스템 위에서 엄청난 전력과 computing cost를 소모하고 있다. LeapIO는 ARM코어를 적절히 이용하여 x86과 ARM 코어가 Mmap영역을 이용하도록 하여 bare metal과 비교하여도 손색없을 만큼 빠른 스토리지 스택을 구축하는데 성공하였다.
증가하는 스토리지 클라우드 시스템에 맞추어서, 서버 제공자들은 고객의 수요를 맞추기 위해서 매우 비싼 cost의 cloud computing resources를 할당하여야 하였다. 이러한 트랜드에 맞추어서 storage장치와의 연산에 필요한 계산양을 줄이기 위해 SmartSSD와 같이 스토리지 장치에 연산능력을 연산을 offloading하기 위한 노력들이 존재해 왔다. 그러나 이러한 offloading 장치는 다음과 같은 문제가 있어왔다. 바로 모든 functionality 를 구현할 수 없다는 것이다. 예를 들어서 아주 방대한 NUMA Ram을 사용하는 경우를 생각해 보자. Host CPU에서는 이러한 spart host DRAM에서 캐싱된 정보를 이용할 수 있지만, SMART SSD는 이러한 dram에 access가 안되기 때문에 host cpu만큼의 효율이 나오지 않을 것이다. 따라서 추가적인 storage stack이 필요하다는 것을 알 수 있다. 또한 하드웨어가 버전업 되면서 새로운 기능이 추가되거나 API가 변경되면 기존의 smart ssd와의 호환을 어떻게 처리해야 할지의 문제도 생각할 수 있다.
따라서 기존의 SSD에 붙어서 장치를 보조해 주는 정도의 CPU offloading이 아닌, 보다 적극적으로 직접 host dram, IOMMU, 그리고 NIC에 접근하여 RDMA와 같은 일들도 offloading해 줄 수 있는 추가적인 장치의 개발이 필요하다. 또한 이러한 장치 개발에 전성비가 좋은 ARM코어를 이용하여, 보다 효율적으로 데이터를 Access할수도 있다는 장점이 있다.
- x86 (host machine), ARM SoC (stroage offloading machine) , PCIe devices (SSD나 NIC)과 같은 장치들이 하나의 Uniform Address를 공유하며 통신할 수 있게 함 -> 여기서 오는 특장점을 여러 테스트 케이스로 벤치마크 해봄
Motivation
- 대체 가능성: LeapIO는 x86 호스트 머신에서도 돌아갈 수 있도록 설계하여, 하드웨어가 ARM SoC을 지원하든지 말든지, 언제나 일정한 지원을 유지할 수 있도록 구현되었다. 다른 말로, LeapIO는 어떠한 환경에서도 돌아갈 수 있도록 LeapIO지원 장비가 필수적인 것이 아니라 선택적인 것으로 만들었다. (마치 Virtual Switch 처럼). 이러한 장점은 서버의 버전이 달라서 서로 다른 기능을 가지고 있더라도, leapIO를 Uniform하게 쓸 수 있도록 하였다.
- Virtualization: LeapIO는 local SSD뿐만 아니라 Remote SSD에 대한 접근도 Isolate하게 접근할 수 있다.
- Efficiency: LeapIO runtime은 MMAP된 Virtual NVMe Command queues에 대한 지속적인 Polling을 통해서 (host mahcine과 무관하기에) 응답성이과 성능이 매우 좋을 수 있었다.
- Easy to use: LeapIO는 kernel space나 SSD의 내부 FPGA에 위치한 것이 아니라 user space영역에서(Accerlator의 ARM코어에서)돌아가기 때문에, 쉽고 빠르게 manage할 수 있다.
Design
하드웨어의 구현
SoC: LeapIO ARM 머신 DRAM: Host RAM
- SoC은 반드시 DRAM과 DMA가 가능하여야 한다.
- SoC의 DRAM은 Base address register(BAR)을 이용하여 host에의해서 DMA가 가능하여야 한다.
- VM의 guest address를 physical address로 변환하기 위하여 IOMMU가 존재하여야 한다.
- NIC카드는 SoC에 의해서 접근가능하여야 한다. 왜냐하면 SoC이 NIC의 기능을 상당부분 offloading하기 때문이다.
소프트웨어의 구현
NVMe장치에 대한 접근은 VM과 Soc그리고 SoC과 SSD와의 접근으로 구현된다. User VM이 write와 같은 약속된 명령을 Commend queue에 작성하면, 그 내용이 그대로 Host로 건너가서 Host는 LeapIO runtime과 약속된 그 장소에다가 작성하게 된다. 그러면 leapIO runtime이 ARM코어를 이용해서 그 부분을 계속 polling하고 있다가, 커맨드가 감지되면 이 커맨드를 SSD와 공유한는 SoC의 DRAM에 작성하고 SSD의 doorbell을 울린다. 그 뒤에, SSD가 도어벨을 감지하고 Host와 공유되는 영역인 Submission queue에대가 결과를 다시 작성하게 된다.
DATA Path
Guest addr -> host addr (By Shared IOMMU) -> logical addr (For SoC Runtime) -> SoC Addr (Remost side) -> host addr (Remote side)
데이터의 전송을 위해서 위와 같은 data path와 address translation 경로를 가진다. 여기서 guest os가 전달한 memaddress를 전송 받기 위해서 공유된 IOMMU를 사용하여 Host의 주소를 가져온다. RDMA를 사용하기 위해선 PCIe로 메모리 copy가 필요함으로 host의 메모리 영역을 SoC의 메모리로 복사하고 service side와 공유되고 있는 logical address로 실제 요청을 변경한뒤 server side에 명령을 전송한다. 그러면 server side에서 이러한 명령을 받아서 적절히 주어진 function F()를 처리한뒤 ssd에 request를 날리거나 응답을 보내게 된다.
SoC VM
호환성을 유지하기 위해서 x86에서도 가상의 leap io runtime이 돌아가도록 하였다. 이러한 시스템에서는 SoCVM이라는 메모리 영역을 통해서 VM LeapIO runtime과 host가 통신하게 된다. SoC VM은 SoC VM Size + HOST address size로 접근할 수 있도록 하였다. 만약 host가 NVME접근을 할경우 요청되는 queue가 이 영역의 메모리를 사용하도록 함으로써, 추가적인 context switch가 없을 수 있도록 하였다. 이 SoC VM은 guest os의 BAR로 사용되어서 GuestOS가 이 영역을 공유할 수 있도록 하였다. 즉 SoC VM을 통해서 추가적인 address translation이 없어도 LeapIO가 guest VM과 통신할 수 있도록 하였다.
굼금 한점
- Prioritization service 도표에서의 prio의 의미
- HW제약 조건들이 원래 physical한 머신에서는 작동하지 않는지의 유무