SOSP 2021 - Proceedings of the 28th ACM Symposium on Operating Systems Principles
개요
Aurora Operating시스템은 Eros (1995 SOSP)와 같은 Single level storage(SLS)기반의 Persistent operating system을 현재의 NVMe와 같은 Modern SSD에서 어떻게 하면 효율적으로 다시금 해석할 수 있을지 고민한 논문이다.
Problems and importance
Application checkpointing은 serverless 환경에서 빠른 Application의 실행 및 복구, Debugging이나 Application crash dump에서의 환경 그리고 database의 간단하고 효과적인 구현을 위해서 많이 사용되어 왔다.
Checkpointing을 VM이나 Container혹은 Process에서 수행하는 방법들이 많이 연구되어 왔다. 그러나 이러한 시스템은 Process state의 복잡함으로 인해서 구현이 매우 어렵거나 구현하더라도 많은 문제점을 지니고 있었다.
Single level stores를 통해서 application state을 incremental checkpointing을 통해서 persist하게 만드는 work들은 많이들 행해져 왔다. 그러나 기존의 work들은 transparent하지도 않으며 POSIX에 fit되지 않았다는 문제가 있었다. 또한 기존 하드웨어의 문제로 인하여 checkpoint를 충분히 빠른 frequent를 가지고 실행하지 못하였다. 이러한 조건에서 Modern stroage hardware인 SSD나 NVM에 대한 연구는 전무한 상황이었다. Aurora는 이러한 문제점들을 NVMe에서 어떻게 하면 해결할 수 있을지 고민한 문제이다.
Main Idea and contribution
Aurora는 1. Posix state의 capture 2. 빠르고 주기적인 state의 capture 3. MMU의 속도 저하란 문제를 다음과 같은 Idea를 통해서 해결하였다.
- POSIX objects들을 First class objects으로 분류하였다: 이는 socket, vma, fd와 같은 기존에는 process에 의존적이었던 오브젝트를 분리하여 persist할 수 있도록 한 것이다.
- Shadowing the system: System이 사용하는 자원을 Shadowing + COW + external synchrony를 통해서 관리하도록 하여 메모리 overhead가 적은 방법으로 checkpointing을 위한 memory tracking이 가능하도록 함.
- SLS모델의 사용: SLS모델의 사용으로 Application의 data가 마치 파일을 다루는 것처럼 자동으로 혹은 수동으로 persist할 수 있도록 하였음.
Design
Aurora는 consistency group이라는 다위로 persist를 atomic하게 유지하는 전체의 큰 단위를 상정하였다. Consistency group은 process, container혹은 application이 될 수 있도록 하였다. Consistency group은 external synchorny를 통해서 다른 Consistency group과의 통신에서 synchonous를 유지하도록 하였다. (같은 consistency group은 external synchorny가 사용되지 않았다.)
또한 AuroraOS는 Command line interface와 AuroraAPI를 통해서 사용자가 checkpointing을 Manual하게 실행할 수 있도록 하였다.
Aurora는 Application의 Recovery에 필요한 User space state와 kernel state를 persistent하게 checkpointing하도록 하였다.
Aurora는 세개의 주요 Componenet들로 구성되었다. SLS orchestrator, object store그리고 custom file system. 각각의 POSIX obejct즉 persist한 posix state들과 kernel objects들을 objects store에 전달하고 checkpointing을 호출하게 하였다. 또한 Orchestrator는 작업도중에 depedent한 process의 상태를 halt함으로써 synchornize를 이룰수 있도록 하였다.
메모리 영역은 Copy on write로 계속 tracking이 되면서 변경된 부분은 buffer에서 storage로 asynchronse화게 copy되었다. 이러한 작업은 초당 100번의 횟수로 일어날 수 있도록 하였다.
또한 system shadowing이라는 기법을 통해서 fork를 통한 cow영역과는 다르게 shared area에 대한 tracking을 가능하게 하여서 shared영역 그리고 user COW영역또한 무리없이 복구되도록 하였다.
Implementation
기본적인 코드 베이스는 FreeBSD를 사용하였다. SLS orchestrator는 Running하는 프로세스를 주기적 혹은 사용자의 요청에 따라서 정지시키면서 kernel object들을 De-serialize하여 Object store에 저장시키도록 하였다. 작은 POSIX objects들 예를 들어서 file descriptor과 같은 경우에는 메모리 버퍼에서 persistent store로 copy하였으며, process가 사용하는 메모리와 같은 경우는 COW(Incremental checkpoiting)을 통해서 구현하였다.
- Halt process
- 오로라는 Application을 checkpointing하기 전제 반드시 정지시켜야 한다. 정지는 user level과 kernel level두가지를 모두 처리해야 하는데 시그널과 같은 시스템을 이용하면, transparent하지도 않고 kernel레벨을 처리할 수도 없다. 이러한 문제를 해결하기 위해서 오로라에서는 선택된 Application을 멈추기 위하여 Application을 돌리고 있는 모든 코어에 IPI를 보내서 우선 Application을 halt하고 checkpoint한다음 다시 재시작 되도록 하였다.
- Process, Thread and CPU State
- Process tree을 만듬으로써 Process parent/child 관계와 process gruop그리고 세션정보와 같은 유기적인 관계까지 복구되도록 하였다. 또한 CPU state를 저장하는 mask와 scheduling prority와 같은 정보들도 저장되도록 하였다. 이는 CPU registe, FPU/vector register와 같은 state information을 저장하는 것으로 구현되었다.
- File Descriptors
- File descriptor와 같은 특정 objects들은 userspace에서 kernel state을 모르고서는 capture할 수 없다. 이는 file descriptor와 같은 경우 kernel state에 대한 정보를 지니고 있기 때문이다. 그러나 Aurora는 기존의 시스템처럼 process에 file descriptor을 유지하는 것이 아니라 object model로 제시하였기 때문에 file descriptor에 대한 복구를 손쉽게 구현할 수 있었다.
- POSIX Object model
- Aurora는 기존의 작업들과는 다르게 각각의 checkpointing단위를 process가 아니라 POSIX Object들로 저장하였다. 따라서 각 Posix오브젝트간의 상호작용또한 적용할 수 있으며, serialize작업과 deserialize작업이 기존의 process centric view나 아니면 모든 것을 user space에서 처리하는 것에 비해 매우 단순해 질 수 있도록 할 수 있었다.
- System shadowing
- fork와는 다르게 System shadowing에서는 Shared memory영역도 구분하여 저장될 수 있도록 하였다 (fork와 같은 경우에는 S_MEM영역이 모든 프로세스에 대해서 open되어 있게 된다). 따라서 Consistency group내에서 shared memory에 대한 영역이 2개의 chain을 이루도록 하며, 첫번째 chain은 현재 stroage에 write하는 부분이고 두번째 chain은 현재 사용되고 있는 page영역이 되도록 하였다.
Criticizing
- Transparent checkpointing을 위해서는 매우 큰 성능 하락을 요구한다. 즉 실제로는 Transparent checkpoiniting는 거의 사용 불가능 하다.
- Hardware Register값을 그대로 저장하기 때문에 이기종 하드웨어 간의 이식은 불가능 하다. 즉 하드웨어 A에서 dump한 프로세스를 하드웨어 B에서 사용 못한다.
- 2개의 chain으로 이루어진 System shadowing은 TLB를 매 object update마다 해야하는데 여기서 발생하는 overhead가 있다.
- 커널에 대한 state들이 두개의 persistent한 상태에서 유지되어야 한다. 이를 위해서 Aurora는 지속적으로 process들을 halting시키면서 redundant한 serialization작업을 하여야 한다.