分散ファイルシステムの メタデータ管理 Database Engineering Meetup LT 2023/12/20 @kuenishi Metadata Management in Distributed File Systems

分散ファイルシステムとは ● 大きなblob をいくらでも置けるシステム ○ オブジェクトストレージともいう場合がある ○ POSIX API でアクセスできるかどうかで扱いが異なる場合が多い ● 大きな: 5TB くらいまで ● いくらでも (※): ○ AWS S3: 100 Trillion (2021) ○ Azure: 4 Trillion (2008) ● オンプレの場合 ○ ストレージノード追加すれば空間を増やせる ● ※ AWS: S3 storage now holds over 100 trillion objects ZDNet

ファイルを分割して(分散)保存する 09230843975 ….. 90934045350 ….. …... blob: /bucket/path/to/filename 90934045350 ….. 09230843975 ….. ….. …... 90934045350 ….. 09230843975 ….. ….. …... 90934045350 ….. 09230843975 ….. ….. …... host: A host: B host: C

分散ファイルシステムのメタデータ ● ファイルの断片をどこにどれだけ置い たか ○ [file id, offset, length, replica, host] ● ファイルの名前 ○ [path, file id] ○ [directory, children] ● ファイルの付属情報 ○ atime, mtime, ctime ○ owner, group, ACL-ish stuff, ○ ●

メタデータを保存するDBが必要 block10 block11 block12 block134 …. block10 block41 block42 block45 …. block42 block45 block92 block98 …. …. Servers create table buckets (...); create table files (...); create table directories (...); create table blocks (...); create table hosts (...) create table buckets (...); create table files (...); create table directories (...); create table blocks (...); create table hosts (...) create table buckets (...); create table files (...); create table directories (...); create table blocks (...); create table hosts (...)

分散ファイルシステムの評価観点 HPC面 ● io500.org ● メタデータの読み書き性能 ● blobデータの読み書き性能 ● (IIRC) 相加平均でスコアリング ● POSIX必須 SC23 No.1 (ANL) ● blob: 10TiB/sec ● meta: 102Mops/sec エンプラ or Web面 ● 永続性があるか ● 非計画のダウンタイムはどの程度か ● 専門家でないエンジニアでも扱えるか ● サービスの持続性 ● エコシステムやサードパーティ ● 必要十分な機能があるか ● etc…

GFS, HDFS (Apache Hadoop) ● Single replicated master ● 独自実装 ● ブロック単位の管理 The Google File System (SOSP’03) HDFS Architecture Guide

Lustre ● HPCで定番 ○ 富嶽で採用 ● 2000年発表 2003年 1.0リリース ● メタデータ、ブロックともに永続性は個々の ノードのストレージレイヤで保証 ● 最近だとOpenZFSが定番らしい ● 現代だとDDNやLLIO のようなステージング やキャッシュレイヤを挟んで高速化 ● MDSの構造は独自（要調査） Introduction to Lustre Architecture

Ceph ● CRUSHという独自のアルゴリズムでブロックをい い感じに重み付けしつつ分散管理できた ● ディレクトリツリーは Dynamic Subtree Partitioning ● Inktank起業→RedHat ● 多くの国産クラウドサービスでオブジェクトスト レージに使われた実績がある CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data (SC’06) Ceph: a scalable, high-performance distributed file system (OSDI’06)

Gfarm ● 数少ない現存する国産の分散ファイルシステム ● メタデータ管理はPostgreSQL ○ 運用でPostgreSQLをいい感じにする ● 2001年〜 ペタバイトスケールデータインテンシブ コンピューティングのた めのGrid Datafarmアーキテクチャ

Apache Ozone (1/2) ● HDFSの後継OSS ○ 最初はSubprojectだったが2019年に独立 ● S3 APIとHDFS API両方喋る ● メタデータを分けて別コンポーネントで管理する ことにより、HDFS のNameNodeよりも高いメタ データ性能を目指した ● ファイルツリーはOzone Manager ● ブロック配置はStorage Container Manager Apache Ozone: Overview

Apache Ozone (2/2) ● メタデータはRocksDBに保存 ● RocksDBへの更新バッチをRaft (Ratis)でレプリケーション ● OMではdouble buffering をしてスループットを上げている Ozone (Ratis leader) RocksDB Ozone (Ratis follower) RocksDB Ozone (Ratis follower) RocksDB Write Read

Collossus ● GFS の後継で現用の分散ファイルシステム ● Spannerをメタデータ管理に使っている ● エクサバイト置けるらしい Colossus の仕組み: Google のスケーラブルなスト レージ システムの舞台裏

Others ● DAOS ○ Intel 謹製→OSSとして独立 ○ OptaneDC向けの最適化が入っている ○ HLCというのを使ってメタデータ性能を向 上したらしい ○ io500 No.1 ● ● ● AWS S3 ○ 言わずとしれたデファクト ○ In-house something ○ Range分散するものっぽい ○ 昔は固定長prefixベースだった模 様 ○ 100兆オブジェクト