20190509

International Workshop on File and Storage Systems 참석
1. Peripherals No More
* 도입: 스토리지가 중요해짐에 따라 더이상 주변 장치만으로 볼 수 없게 되었다.
(1) Alleviating Garbage Collection Interference through Spatial Separation in All Flash Arrays
SSD는 높은 대역폭을 갖고 있음. 하지만 네트웍의 대역폭이 충분하지 않아 bottleneck이 되고 있음. 스토리지가 충분히 빨라서 네트웍 대역폭을 포화시킬 수 있다. 그리고 garbage collection 때문에 성능 일관성이 떨어지고 있음. 해당 연구의 목적은 네트웍을 충분히 사용하면서도 consistent한 성능을 보장하는 것. SWAN을 제안함. All-flash-array 상황에서 sustainable high performance를 제공하는 것이 목적.
(2) First Responder
* 메모리에 직접 쓰는 DAX 접근 방식은 reliability, integrity, redundancy 등의 문제가 있음. PM을 caching layer로 사용해서 소프트웨어에게는 빠르게 응답하고, background에서 traditional한 방식으로 file system을 제공하자. Cache replacement policy는 복잡하게 설계하지는 않는다. Storage stack을 회피하자는 것.

2. Exploring New Challenges with Emerging Non-Volatile Memory Technologies
* 스토리지 기술이 데이터 생성 속도를 따라가지 못하고 있음. 사람들은 163ZB의 데이터를 생성하지만 스토리지는 19ZB밖에 저장하지 못하고 있음. 어떻게 gap을 해결할 것인가? 생성하는 시점에 filtering하는 것이 한 가지 방법이 될 수 있음. Deduplication을 활용하는 것도 한 가지 방법.
* 어디에서 데이터가 생성되고 있는가? (IDC 데이터). 데이터센터 코어에서 25%, 데이터센터 엣지에서 25%, 엔드포인트(PC, Mobile, IoT)에서 50% 생성되고 있음.
* CORI는 compute node, accelerator node로 나뉜다. Compute node는 1630 nodes, 200TB DRAM, 750TB NVRAM으로 구성됨. Bytes/flop으로 메모리 사용량을 평가할 수 있음. 0.5는되어야 네트워크 접속을 방지할 수 있는데, Cori는 0.07, Edison은 0.13에 불과함. Generalpool은 0.79. 메모리를 늘리지 못하는 이유는 전력 때문이다. DoE에서는 20MW로 power budget을 제약하고 있는데, DRAM을 추가하면 power budget을 훨씬 초과하게 됨. Accelerator node는 9668 nodes로 구성되어 있으며, KNL를 사용하고 있음. 92TB DRAM과 150TB HBM 장착. 대용량 분석에서 그래프는 흔히 사용되는 추상화 방식. 데이터 분석 과정에서는 데이터를 나누어 노드에 로딩한 다음에 연산하게 됨. 데이터 로딩에서 serialization이 발생하고, 중간에 발생하는 checkpointing도 serialization을 유발한다.
* DRAM은 18nm 이하로 scaling을 못할 것. 새롭게 등장하는 메모리는 10nm 이하로 집적 가능할 것으로 기대됨. 따라서 데이터 gap을 해결하기 위한 방법으로 PRAM을 사용하는 것이 한 가지 방법이 될 수 있음.
* 저장 장치를 메모리 확장하는 방식을 사용할 수 있음. 메모리에 매핑해서 사용하다가 페이지 폴트가 발생하면 저장 장치에서 페이지를 불러오는 방식. 하지만 스토리지가 느리다는 것이 문제이다. 이를 해결하기 위해 ultra-low-latency storage를 개발한다.

3. File System Design on Distributed Persistent Memory
* NVMM, RDMA가 분산 파일 시스템을 어떻게 변화시킬 수 있을 것인가?
* 단순히 스토리지 / 네트웍을 교체하는 것만으로는 안 된다.
* NVM의 byte-addressability, RDMA의 one-sided RDMA를 사용하고자 함.
* [EuroSys’19] scalable rdma rpc on reliable connection with efficient resource sharing: NIC에도 cache가 있음을 알 수 있었음. NIC cache는 mapping table, QP state 등을 캐싱하기 위해 사용됨. Scalability를 높이기 위해 NIC cache와 CPU cache 수준에 적용될 수 있는 SW optimization을 제안함.

4. A Robust Fault-Tolerant and Scalable Cluster-wide Deduplication for Shared-Nothing Storage Systems
* 저장 장치에서 deduplication을 하는 간단한 방식은 중앙에 서버를 두고 deduplication을 수행하는 것.
* Deduplication 101. 어떤 데이터가 중앙화된 deduplication server에 저장된다. 우선, 데이터가 chunk로 나뉜다. 그리고 chunk에 대해 fingerprinting을 수행한다. 이후에 각 chunk를 찾아보고 없으면 해당 chunk를 새롭게 등록하고, 원래 데이터는 metadata로 대체한다.
* 중앙화된 deduplication의 문제점들. (1) 이는 file system의 shared-nothing property를 위배하게 된다. (2) failure가 발생하면 data가 사용 불가능해진다. (3) metadata inconsistency가 발생할 수 있다. (4) 입출력 트래픽이 집중됨.
* Challenge #1: I/O broadcasting. 데이터를 저장하는 시점에서 해당하는 chunk가 있는지 찾기 위해 storage server에 broadcast가 발생하게 됨. 이러한 broadcasting overhead를 줄일 필요가 있음.
* Challenge #2: Partial transaction failure. Deduplication transaction 과정 중에서 partial failure가 발생하면 특정 fingerprint에 대한 actual data를 갖지 못하는 상황이 발생할 수 있음. 이러한 partial transaction failure를 어떻게 해결할 것인가?
* Challenge #3: Dynamic content relocation. 새로운 스토리지를 distributed deduplication system에 더했을 때, 로드 밸런싱을 위해 chunk relocation을 지원해줄 수 있어야 한다.
* Proposed Idea #1: content fingerprint-based redirection. 브로드캐스팅하지 않고, CRUSH hash를 사용해 스토리지 서버를 특정하고 해당 서버에 대해서만 lookup을 수행함
* Proposed Idea #2: distributed DM-shared. 스토리지 서버에 table을 두어 valid한 chunk인지 기록한다.
* Proposed IDea #3: Async-tagged Consistency.
* Ceph 파일시스템에서 FIO를 사용해 평가함.

5. Strata: A Cross Media File System
* Storage requirements: (1) small updates dominate, (2) dataset scales up to 10TB, (3) updates must be crash consistent.
* 여러 옵션이 있지만 빠른 스토리지를 목적으로 하므로, NVM을 선택할 것. NVM을 사용하고 NOVA 파일 시스템을 사용해서 평가해보자. (1) Small random IO에서 커널이 90%의 실행 시간을 차지한다. NVM은 빠르지만 커널이 bottleneck. (2) 그리고 NVM만을 사용하기에는 너무 비용이 높다. 블록 레벨 캐싱은 데이터를 블록 단위로 관리하는데, NVM은 byte-addressable하다. 추가적인 indriection이 발생. (3) Crash는 mature application에서도 흔히 발생하는 문제.
* Strata는 파일 시스템은 위 문제들을 해결하고자 함. (1) High performance, (2) Low-cost capacity, (3) Simplicity.
* Strata는 (1) user-level에서 log operation을 사용하고 (LibFS), (2) 커널에서는 로그를 visible하게 digest한다 (KernelFS).
* LibFS에 대해 먼저 이야기해보자. NVM의 일부를 operation log로 사용한다. 이를 사용해 fast write를 지원한다. 커널을 bypassing하고, NVM에 직접 쓰기를 수행한다. 크래시가 발생하면 커널은 로그를 통해 복구한다. 지금까지 스토리지가 느려서 asynchronous하게 쓰기가 진행되었으나, Strata는 fast synchronous IO를 지원한다.
* KernelFS에서는 private operation log를 digest해서 NVM shared area로 옮겨적는다. Digest를 통해 private log를 다른 어플리케이션에 보이도록 한다. Digest 과정에서 log coalescing을 통해 입출력을 줄일 수 있음. 그리고 비용을 낮추기 위해 KernelFS에서는 digesting 과정에서 cold data를 SSD에서 HDD로 이동한다. SSD는 utilization에 따라 throughput이 달라진다 (HW-level garbage collection 때문). 1024MB와 같은 큰 단위를 사용하면 throughput 저하가 없음. 따라서 strata에서는 1024MB를 I/O 단위로 사용함.
* 이같이 구현되어 있기 때문에 읽기를 수행할 때에는 계층적으로 접근되어야 한다. 우선 operation log를 검색하고, 그 뒤에 SSD area, HDD area를 차례대로 lookup한다.
* Evaluation에서는 latency와 throughput을 평가한다. Latency. Strata는 random small write에 충분히 낮은 latency를 제공하는가? Asynchronous digest는 latency에 영향을 주는가? Throughput. Strata는 logging과 digesting에서 두 번의 쓰기를 수행한다 (logging, digesting). Throughput에는 문제가 없는가?

6. OpenEC: Toward Unified and Configurable Erasure Coding Management in Distributed Storage Systems
* 저장해야 할 데이터가 많은데, 일반적으로는 데이터 센터에 분산하여 저장한다. 이렇게 scaling out할 때에는 failure가 일반적이게 됨. 데이터가 언제든지 available하도록 하려면 어떻게 해야 하는가? Fault tolerance를 지원해주어야 한다 – availability, durability. 간단하게는 identical copy를 저장하는 것. 하지만 이는 너무 많은 비용이 들게 되므로, erasure coding을 사용하는 것이 한 가지 방법이 됨. 최근에 cost를 줄이기 위해 Google, Amazon, Facebook 등에서 사용하고 있다고 함.
* Erasure coding은 capacity를 절약하지만, update와 repair가 비싸다. 한 개의 블록을 repair하기 위해서는 k개의 블록이 필요하고, 데이터 업데이트할 때에는 parity block도 업데이트해야만 함.
* Conventional repair를 사용하면원래 블록을 복구하기 위해 k 노드로부터 데이터를 받아야 함. [HotStorage’13] Facebook에서는 repair를 위해 200TB의 트래픽이 발생함. 해당 연구에서는 어떻게 해결했다고 하는데 이해못함.
* Repair pipelining: block을 slicing한 다음에 pipelined repair를 수행한다.

7. Improving Shared GPU Clusters for DNN Training Workloads
* Microsoft에서는 GPU 클러스터의 크기가 2년 전에 비해 5배 증가함. 어떻게 GPU 클러스터를 잘 관리할 것인가가 중요한 문제가 됨. 지난 2년간 연구된 Gandiva, Philly, Optimus, Tiersias 등이 GPU 클러스터 관리 기법 연구임. Consolidation, average job completion time 등을 목표로 잡고 진행함.
* GPU 클러스터는 수백대의 서버와 2000대의 GPU를 갖고 있음. 파일은 HDFS에 저장되어 있음. 그리고 resource manager는 제출된 작업을 관리함.
* Deep learning과 big data analytics의 차이점. Big data analytics는 대량의 데이터를 처리해서 통계값을 얻는 것이 목적임. 하지만 딥 러닝은 데이터를 기반으로 커다란 모델을 생성해낸다는 차이점이 있음. 그리고 이 과정에서 많은 커뮤니케이션 오버헤드가 발생함. 커뮤니케이션이 58%를 차지함.
* GPU 클러스터 스케쥴링에서 고려해야 하는 것. (1) 각 서버에는 4-8개의 GPU가 설치되어 있음. (2) 랙에서는 InfiniBand로 연결된 네트웍을 사용할 수 있지만, 랙을 넘어가면 ethernet을 사용해야 함. 따라서 GPU 작업 스케쥴링할 때 InfiniBand 도메인에 작업을 배치하는 것이 좋다.
* CPU / memory 할당량은 GPU 요구량에 비례해 결정된다. 이는 자원 할당을 단순하게 해준다.
* Gittins index를 사용하면 현재 age(실행 시간)에 기반하여 얼마뒤에 실행이 완료될지 알려준다.

Advertisements
Posted in Memo
4 comments on “20190509
  1. junghan says:

    참석하셨군요ㅎㅎ 저는 갈까하다가 1박 일정이라ㅜㅜ

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Categories
Recent Posts
누적 방문자 수
  • 160,481 hits
%d bloggers like this: