기본 콘텐츠로 건너뛰기

NFS for Ceph

https://www.youtube.com/watch?v=BmDv-iQLv8c

Hypervisor mediated ("vsock")

댓글

이 블로그의 인기 게시물

Ceph Storage Pros, Cons

Pros Highly resilient, almost every time we attempted to destroy the cluster it was able to recover from a failure. It struggled to when the nodes where down to about 30%(3 replicas on 10 nodes) The cache tiering feature of Ceph is especially nice. We attached solid state disks and assigned them as the cache tier. Our sio benchmarks beat the our Netapp when we benchmarked it years ago (no traffic, clean disks) by a very wide margin. Ceph effectively allows the admin to control the entire stack from top to bottom instead of being tied to any one storage vendor. The cluster can be decentralized and replicated across data centers if necessary although we didn't try that feature ourselves, it gave us some ideas for a disaster recovery solution. We really liked the idea that since we control the hardware and the software, we have infinite upgradability with off the shelf parts which is exactly what it was built for. Cons Ceph is very difficult to set up when we use...

ext4 filesystem

ext filesystem ext는 기본적으로 Linux os 에서 많이 사용된다. Windows os에서는 NTFS, Mac OS에서는 APFS를 사용하는 것과 같은 개념으로 이해하면 된다. 안드로이드와 같은 새로운 OS의 경우, 리눅스 시스템을 기초로 하기 때문에 ext는 생각보다 널리 쓰이고 있으며, 다른 filesystem을 이해하기 위한 기초 개념이라고 볼 수 있다. ext2, 3, 4로 조금씩 발전 했기 때문에 차례대로 이해하는 게 좋을 꺼 같다. ext2 하나의 파일은 하나의 inode 값을 가지고 위와 같이 데이터가 있는 block과 매핑하는 Block Mapping을 사용하는 것이 ext2의 특징이다. 각 inode 내 Info 하나 당 하나의 block과 매핑 될 할 수 있지만, 그렇게 되면 너무 적은 block 매핑이 이루어져서 감당할 수 있는 용량에 제한에 걸리기 때문에 보다 많은 block과 매핑하기 위해서 간접(Indirect)적으로 매핑 할 수 있도록 만들어져 있다. DISK 내에서는 아래와 같이 ext2 filesystem 이 구성되어 있다. 1.  boot block Disk의 첫 1024 bytes는 boot block으로 boot sector 파티션을 위해서 할당된 공간으로 ext2 filesystem에서는 사용하지 않는 공간이다. 2.  Super Block struct ext2_super_block { __u32 s_inodes_count; /* Inodes count */ __u32 s_blocks_count; /* Blocks count */ ... __u32 s_free_blocks_count; /* Free blocks count */ __u32 s_free_inodes_count; /* Free inodes count */ __u32 s_first_data_block; /* First Data Block */ __u32 s_log_block_size; /* Block size */ ...

BlueStore in CEPH

BlueStore in Ceph BlueStore 데이터 저장 BlueStore의 기본 아키텍처 Data 데이터는 HDD(=BlockDevice)에 직접 저장된다. Metadata Metadata는 kv 형식으로 RocksDB에 저장된다. RocksDB 데이터는 BlueRocksEnv 인터페이스를 통해 BlueFS로 전달된다. BlueFS는 별도의 BlockDevice(e.g. SSD)에 저장 가능하다. BlueFS 필요한 이유 기본적인 Filesystem 모듈이 필요하며, 모듈의 Metadata를 별도의 RocksDB로 사용하여 구성한 것이 BlueFS 이다. 기존 Filesystem보다 Metadata 비효율을 줄이고 고속 처리를 하기 위해서 RocksDB를 별도로 구성하게 되었다. RocksDB의 데이터 파일 분류 WAL Write Ahead Log 가장 빠른 저장 매체 필요 DB .sst, CURRENT, IDENTITY, MANIFEST, LOCK, OPEIONS 파일을 저장 일반적으로 압축 상태로 읽고 쓰기가 이루어짐 WAL이 가득 차면 기존 WAL에 기록된 데이터가 DB에 저장됨 SLOW 느린 저장 매체를 사용 DB가 가득 차면 기존 DB 저장되어 있던 데이터가 Overflow되어 느리게 저장 BlueFS Metadata Metadata 조직 구조 Super block:  파일 시스템 전역 정보는 저장한다. Journal BlueFS의 Metadata는 기존 파일 시스템처럼 특정 데이터 구조 및 레이아웃으로 저장하지 않는다. 대신 모든 작업을 Journal에 기록하고, 로딩 중에 해당 레코드 하나씩 Journal에서 running해서 Metadata로 저장된다. 특정 데이터 구조 및 레이아웃 파일이 메모리에 로드된다. File 실제 데이터의 Metadata이다. Data 실제 데이터 Metadata Class bluefs_extent_t(데이터) offset : BlockDevice의 물리적 주소 length : 데이터 길기 bdev : 소...