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: 소속된 blockdevice

bluefs_fnode_t(파일)

• ino: inode 번호
• size: 파일의 크기
• mtime: 파일이 마지막으로 수정된 시간
• prefer_bdev: 파일이 저장될 때, 우선적으로 사용될 blockdevice
• extents: 파일이 실제로 디스크에서 차지하는 공간에 대한 정보를 담은 Vector이다. 각 요소는 bluefs_extent_t 구조체로 디스크의 특정 영역(extent)를 가리킨다.
• allocated: 파일이 실제로 사용하는 공간의 크기이다. extents 벡터에 있는 모든 extent의 크기를 합한 값과 같거나 같음

bluefs_super_t(수퍼블록)

• uuid: 파일 시스템의 고유 식별자(UUID)
• osd_uuid: OSD(Object Storage Device)의 UUID입니다. OSD는 데이터를 저장하는 물리적인 장치를 의미하며, 이 UUID를 통해 어떤 장치에 파일 시스템이 위치하는지 알 수 있다.
• version: 파일 시스템의 버전 정보입니다. 특히, 로그(journal)가 압축될 때마다 증가하며, 이 값을 통해 파일 시스템이 로그 압축을 몇 번 수행했는지 확인할 수 있다.
• block_size: 블록 크기, bluefs 파일 시스템에서 데이터를 읽고 쓸 때의 최소 단위
• log_fnode: 로그 파일의 inode 정보를 담고 있습니다. 로그 파일은 파일 시스템의 변경 내역을 기록하는 파일로, 시스템 장애 발생 시 데이터 손실을 방지하는 데 중요한 역할

bluefs_transaction_t(저널)

저널은 실제로 fnode가 super block에 기록되고 다른 파일의 fnode는 저널 파일에 로그 내용으로 기록되는 특수 파일이다.

• op_t: 트랜잭션의 종류를 나타내는 열거형입니다. 각 상수는 다음과 같은 의미를 가집니다.
• OP_NONE: 초기 상태 또는 비어 있는 상태를 의미 
• OP_ALLOC_ADD: 블록 저장소에 extent(연속된 블록)를 추가하는 작업
• OP_ALLOC_RM: 블록 저장소에서 extent를 제거하는 작업
• OP_DIR_LINK: 디렉토리 항목을 생성하거나 수정하는 작업
• OP_DIR_UNLINK: 디렉토리 항목을 삭제하는 작업
• OP_DIR_CREATE: 디렉토리를 생성하는 작업
• OP_DIR_REMOVE: 디렉토리를 삭제하는 작업
• OP_FILE_UPDATE: 파일의 메타데이터를 업데이트하는 작업
• OP_FILE_REMOVE: 파일을 삭제하는 작업
• OP_JUMP, OP_JUMP_SEQ: bluefs 로그 파일의 compaction과 관련된 작업
• uuid: 해당 트랜잭션이 속한 bluefs 파일 시스템의 UUID
• seq: 트랜잭션의 순서를 나타내는 시퀀스 번호
• op_bl: 트랜잭션에 대한 정보를 담고 있는 버퍼 리스트입니다. 이 버퍼에는 트랜잭션의 종류와 관련된 데이터가 포함

BlueFS 저널 매커니즘

blueFS의 Metadata는 기존 파일시스템과 같은 데이터 구조와 레이아웃으로 저장되지 않고 모든 작업을 저널에 기록하고 로딩하는 동안 저널의 기록을 하나씩 재생하여 저널로 로딩 된다.

.sst 파일 트랜젝션 매커니즘 생성

data 디렉토리에 새 파일 1.sst를 만들고 여기에 데이터를 쓴 다음 이를 트랜젝션으로 제출한다.이 트랜젝션에서는 결국 세 개의 레코드가 순차적으로 생성된다.

• 레코드 유형 및 새로 생성된 fnode 구조를 포함하여 OP_FILE_UPDATE 레코드를 생성
• fnode 파일의 레코드 유형, 디렉토리 이름, 파일 이름 1.sst 및 ino 번호를 포함하여 OP_DIR_LINK 레코드를 생성
• 레코드 유형 및 새로 생성된 fnode 구조를 포함하여 OP_FILE_UPDATE 레코드가 생성된다. 쓰기 작업을 수행하려면 새 공간이 할당되고 작업 시간을 변경해야 하므로 fnode 구조를 업데이트 해야 하고 OP_FILE_UPDATE 레코드가 생성된다.

LOG 재생

• 첫 번째 레코드의 fnode 메모리로 구문 분석
• 두 번째 단계에서는 dirmap 및 filemap에서 파일과 디렉토리 매핑 설정
• 세 번째 단계에서는 첫 번째 단계의 fnode를 새로운 fnode 구조로 대체

BlueFS 메모리 Metadata

Metadata Caching 메커니즘

BlueFS Metadata는 주로 Super block, Directory 및 File 모음, File과 Directory 간의 매핑 관계, 다음에 파일 시스템이 로드될 때, 파일과 물리적 주소 간의 매핑 관계를 포함하여 모두 메모리에 로드된다. 로그의 기록이 하나씩 메모리에 재생되어 Metadata가 복원된다.

• dir_map: BlueFS에 있는 모든 디렉터리의 디렉터리 이름을 실제 디렉터리 구조에 매핑한 것을 기록한다. 
• file_map: 디렉터리에 있는 모든 파일의 파일 이름을 실제 파일 구조에 매핑한 것을 기록, 각 파일 구조에는 파일의 fnode 구조가 포함됨

메모리 Metadata 로딩

• BlueFS가 로드되면 로그에 기록된 콘텐츠를 기반으로 Metadata의 dir_map 및 file_map에서 해당 항목을 추가, 삭제 또는 수정한다.
• BlueFS를 사용하는 동안 이 매핑 구조는 계속 변경됨
• BlueFS는 특정 파일을 찾을 때, 메모리에서 두 번 검색
• 처음으로 dir_map을 통해 파일이 위치한 하위 폴더를 찾는다.
• 두 번째로 해당 폴더의 file_map을 통해 해당 파일을 찾는다.
• 또한 dirty_files 목록이 메모리에 기록되어 변경되었지만, 아직 동기화 되지 않은 파일 세트를 기록(BlueFS의 입데이트 작업은 동기화가 호출될 때만 실제 변경된다.)

References

https://blog.csdn.net/easonwx/article/details/125949915