前提
導入対象を検討するにあたり、以下が考慮点になる。
- 安定性
- 性能
- 障害時の復旧しやすさ
経験的に 1 は重視したい。
過去に GlusterFS を導入したときは不安定さがネックで1つのサーバがコケる度に一部のファイルが見えなくなってサービスが動かなくなることが度々あった。
2 の並列アクセス性能は当然だが、AWS S3のようなオブジェクトストレージ型は避け、Linux OS から通常のファイルアクセスが可能な FUSE に対応していることが基本になる。
(クラウド系のアプリの多くは S3 の分散アクセスに対応しているが、CAEアプリの多くはオンプレ動作かつ FUSE アクセスが前提になっている認識)
候補
https://en.wikipedia.org/wiki/Comparison_of_distributed_file_systems
にあるリストから、上記を加味して候補に挙げるとすれば以下になるかなと思う。
非商用
- Lustre
-
IPFS→ ファイルシステムではなく、プロトコルシステム。S3 のようなオブジェクト型に近いIFのため除外 - JuiceFS → RedisやPostgreSQLデータベースを管理システムとして利用するファイルシステム
-
OpenIO→ 公式ページにアクセスしたらSSLエラーになって閲覧できないので怪しいと判断し除外 -
RozoFS→ 公式ページ見てもダウンロードできるパスが見当たらない。恐らく商用化されたと推測。 -
Ceph→ オブジェクトストレージの思想に近いファイルシステムのため、除外
(最新のGlusterFSなら？と思ったが、アーキは基本的に変わらずのようで候補から外した)
商用
- SpectrumScale
- BeeGFS
-
Scality→ Scality RINGによるオブジェクトストレージが基本サービス
各ファイルシステムの特徴
Spectrum Scale
高可用性を確保した高性能な分散並列ファイルシステム。
SKLM を導入することで "ファイル単位の暗号化" が可能。
(暗号化機能の多くは "ディスク単位" であり、ファイル単位暗号化が可能なファイルシステムは SpectrumScale くらいしかない)
コスト : 高額
容量あたりにライセンス費用が発生する。
多くの場合は TB 単位でウン万円ぐらい。
BeeGFS
- メタデータサーバ、ストレージサーバで構成される
分散並列ファイルシステム- SANによるストレージ共有を利用するものではなく、データを複数のストレージサーバにレプリケートすることで可用性を担保
- そのためサーバ障害が発生すると一部データが見えなくなる可能性があり、可用性では他の分散並列ファイルシステムより劣ると思われる。
- Infiniband, OmniPath によるRDMAデータ転送に対応
- BeeONDと組み合わせることで計算機側ストレージを利用した一時領域拡張が可能
- 暗号化機能なし
コスト : 要問合せ
https://itprice.com/netapp-price-list/beegfs.html
を見る限りは、 $500 - $800 / サーバ といったところ。
3サーバ運用なら $1500 - $2400 で \210,000 - \336,000 ぐらい。
SpectrumScale と比べるとかなりの安価。
Lustre 等と比較してコスト払う価値があるかどうかが課題。
JuiceFS
Redis, PostgreSQL をファイル管理用のバックエンドに用いるファイルシステム。
Hadoop 等の分散並列アクセスに耐えうるには、DB側を分散並列システムに構築する必要がある。
一般的な Master-Replication構成にしてしまうと、Masterサーバに負荷が集中するため、データ一貫性は保たれるが並列アクセス性能が低下する。
JuiceFSのバックエンドDBについて
JuiceFS のバックエンドで使用するDBシステムは前述のとおり分散並列に対応したものである必要がある。
単一ノードで運用することも可能だが、分散並列ファイルシステムシステムでなくなり、NFSと変わらなくなってしまう。
JuiceFSは Key Value型の Redisと、Relational型の Postgres に対応する。
Redis
- In-Memory型のDBシステムのため応答性が高い
- 定期的にストレージに書き出すことでデータ保全 → 不意にサーバダウンするとタイミングによってはデータ消失が有りうる
- Redis Sentinel により複数サーバ時の Replication とクエリ分散が可能
- Redis Cluster により複数サーバへの分散書き込みが可能
Redis は高応答性が期待できるが、可用性の面で不安があるため共用ファイルシステムとして用いるには不向き。
(並列性能を確保したい時に独自に利用するのに推奨。例えば複数計算機のディスク共有が可能な BeeONDがあるが、容量が並列数と個々の計算機ストレージ容量に依存する。)
一方で Redis であれば、共用ストレージにデータ領域を置きながらもIOは In-Memory で行うファイルシステムを独自構築できるため、並列計算性能を上げたい時に有用と考えられる。
Postgres
可用性を考慮すると Postgres になるが、クラスタ型に対応するものには以下の幾つかがある。
PgPool-II
特徴:
- Connection Pooling
- Load Balancing
- Limiting Exceeding Connections
- Watchdog
- In Memory Query Cache
- 複数サーバ間で Replication することで可用性を確保するとともに、クエリ分散することで"読み込み時"の応答性を向上する
Citus
特徴:
- Distributed Scale
- Simplified Architecture
- Parallelized Performance
- Open Source
- Power of Postgres
- Managed Database Service
Postgres-XC
Postgres-XC is an open source project to provide a write-scalable, synchronous, symmetric, and transparent PostgreSQL cluster solution.
Postgres-XL
特徴:
- Fully ACID
- Open Source
- Cluster-wide Consistency
- Multi-tenant Security
- PostgreSQL-based
想定ワークロード:
- OLAP with MPP Parallelism
- Online Transaction Processing
- Mixed
- Operational Data Store
- Key-value including JSON
JuiceFS を採用する場合は以下が候補になると思う。
- Redis : 応答性重視
- Citus : 可用性と応答性を両立するもの。(Postgres-XC, Postgres-XL と比べて優位とは思えないが、Webサイトの見た目の独断偏見から選択)
Ceph
Ceph OSD (Object Storage Daemon)
と
Ceph MDS (Metadata Server)
の複数サーバ構成でデータ冗長とアクセシビリティを担保する。
FC-SANのような共有ストレージは使わず、多数の OSD をクラスタ化することで多数のクライアントアクセス性能を確保する思想のため、単一アクセス速度の向上は基本的に SSD を推奨。
HPC用途というよりはクラウド用途といえる。
Lustre
採用例が多い。
商用の SpectrumScale と比較して暗号化機能が無く並列アクセス性能に全振りしている印象。
Lustre には LNet Routing という機能があり、例として OmniPath <-> Infiniband の橋渡しを行うことができる。
https://wiki.lustre.org/LNet_Router_Config_Guide#LNet_Configuration_Example