分散ブロックストレージの研究開発においてメタデータ サービスをどのように設計すればよいでしょうか?

この記事はシリーズの最初の記事であり、関連する背景とメタデータ サービスに焦点を当てています。

一般的に、分散ストレージは、ストレージ アクセス インターフェイスとアプリケーション シナリオに基づいて、分散ブロック ストレージ、分散ファイル ストレージ、分散オブジェクト ストレージの 3 つのタイプに分類されます。

その中で、分散ブロックストレージの主な応用シナリオは次のとおりです。

1. 仮想化: KVM、VMware、XenServer などのハイパーバイザーや、Openstack、AWS などのクラウド プラットフォームなど。ブロック ストレージの役割は、仮想マシン内の仮想ディスクのストレージをサポートすることです。

2. データベース: MySQL、Oracle など。多くの DBA は、分散ブロック ストレージなどの共有ブロック ストレージ サービス上でデータベース データ ディスクを実行します。さらに、多くのお客様はデータベースを仮想マシン内で直接実行しています。

3. コンテナ: 近年、企業ではコンテナの使用が増えています。一般的に、コンテナ内で実行されるアプリケーションはステートレスですが、多くのアプリケーション シナリオでは、アプリケーションにデータの永続性要件もあります。アプリケーションは、データをデータベースに保存するか、共有仮想ディスクに保存するかを選択できます。この要件は、Kubernetes の Persistent Volume 機能に対応します。

[[231107]]

今日は主にSmartXが分散ブロックストレージを構築する方法について紹介します。 SmartXは2013年の設立以来、分散ブロックストレージの開発において約5年の経験を積んできました。そこで本日は、SmartX が独自の分散ブロック ストレージ ZBS を実装する方法を紹介するだけでなく、分散ブロック ストレージの開発プロセスにおける私たちの考えや選択についても詳しく紹介します。さらに、今後の製品計画についてもご紹介いたします。

一般的に、分散ストレージで解決する必要がある問題は、メタデータ サービス、データ ストレージ エンジン、一貫性プロトコルの 3 つです。

その中で、メタデータ サービスが提供する機能には、一般的に、クラスター メンバー管理、データ アドレス指定、レプリカ割り当て、負荷分散、ハートビート、ガベージ コレクションなどが含まれます。データ ストレージ エンジンは、単一のマシン上のデータ ストレージの解決、ローカル ディスク管理、ディスク障害処理などを担当します。各データ ストレージ エンジンは互いに分離されています。データへのアクセスが、強い一貫性、弱い一貫性、順次一貫性、線形一貫性などの期待される一貫性状態を満たすことができるようにするために、これらの分離されたストレージ エンジン間で一貫性プロトコルを実行する必要があります。さまざまなアプリケーション シナリオに基づいて、適切な一貫性プロトコルを選択します。このプロトコルは、異なるノード間でデータを同期する役割を担います。

これら 3 つの部分により、分散ストレージの中核部分は基本的にマスターされました。さまざまな分散ストレージ システム間の違いは、基本的に、これら 3 つの側面における選択の違いから生じます。

次に、これら3つの側面からSmartX ZBSシステムの設計をどのように考え、最終的にどのような技術と実装方法を採用することにしたのかを紹介します。

まず、メタデータ サービスを紹介します。まず、メタデータ サービスに対するニーズについてお話ししましょう。

メタデータとは、データがどこに保存されているか、どのサーバーがクラスター内にあるかなど、「データに関するデータ」のことです。メタデータが失われたり、メタデータ サービスが正しく機能しなくなったりすると、クラスター全体のデータにアクセスできなくなります。

メタデータの重要性から、メタデータの第一の要件は信頼性です。メタデータは複数のコピーに保存する必要があり、メタデータ サービスではフェイルオーバー機能も提供する必要があります。

2 番目の要件は、高いパフォーマンスです。ほとんどの IO 要求がメタデータ サービスにアクセスする必要がないように IO パスを最適化することはできますが、データの割り当てなど、メタデータを変更する必要がある IO 要求も常に存在します。メタデータ操作がシステム パフォーマンスのボトルネックになるのを防ぐには、メタデータ操作の応答時間が十分に短くなければなりません。同時に、分散システムのクラスター サイズが拡大し続けるにつれて、メタデータ サービスの同時実行機能に対して特定の要件が課せられます。

***最初の要件は軽量であることです。当社製品の利用シナリオのほとんどはプライベート展開、つまり、当社製品はお客様のデータセンターに展開され、当社の運用・保守担当者ではなくお客様自身によって運用・保守されます。このシナリオは、多くのインターネット企業が独自の製品を運用および保守しているシナリオとはまったく異なります。そのため、ZBS では、メタデータ サービスを中心にシステム全体の軽量性と、その容易な操作および保守機能を重視しています。メタデータ サービスは、メタデータ サービスとデータ サービスを一緒に展開できるほど軽量であることが期待されます。同時に、ほとんどの操作とメンテナンス操作がプログラムによって自動的に完了するか、ユーザーがインターフェース上で簡単な操作を実行するだけで完了することを期待しています。 HDFS に詳しい方ならご存知でしょうが、HDFS のメタデータ サービス モジュールは Namenode と呼ばれ、非常に重いモジュールです。 Namenode は物理サーバーに独立して展開する必要があり、ハードウェア要件が非常に高く、操作や保守が容易ではありません。アップグレードであれ、プライマリノードとセカンダリノード間の切り替えであれ、非常に負荷の高い操作であり、運用上の問題により障害が発生する可能性が非常に高くなります。

上記はメタデータ サービスに対する当社の要件です。次に、メタデータ サービスを構築するために使用できる具体的な方法を見てみましょう。

データの保存、特に構造化データの保存に関して、まず思い浮かぶのは、MySQL などのリレーショナル データベースや、LevelDB、RocksDB などの成熟した KV ストレージ エンジンです。しかし、このタイプのストレージの最大の問題は、信頼性の高いデータ保護とフェイルオーバー機能を提供できないことです。 LevelDB と RocksDB は非常に軽量ですが、データを 1 台のマシンにしか保存できません。 MySQL もいくつかのマスター スレーブ ソリューションを提供していますが、MySQL のマスター スレーブ ソリューションは扱いにくく、シンプルな自動操作および保守ソリューションが欠けているため、あまり良い選択ではないと考えています。

次に、MongoDB や Cassandra などの分散データベースについて見ていきます。どちらの分散データベースもデータ保護の問題を解決し、フェイルオーバー メカニズムを提供できます。ただし、いずれも ACID メカニズムを提供していないため、上位レベルでの実装がより面倒になり、追加の作業負荷が必要になります。第二に、これらの分散データベースは操作と保守が比較的複雑であり、自動化が容易ではありません。

もう 1 つの選択肢は、Paxos または Raft プロトコルに基づくフレームワークを実装することです。しかし、これを実現するためのコストは非常に高く、スタートアップ企業にとってはあまり費用対効果の高い選択肢ではありません。私たちは、Raft が提案されたばかりの 2013 年に事業を開始しました。

4 番目のオプションは、Zookeeper を選択することです。 Zookeeper は ZAB プロトコルに基づいており、安定した信頼性の高い分散ストレージ サービスを提供できます。しかし、Zookeeper の最大の問題は、ストレージ容量が非常に限られていることです。アクセス速度を上げるために、Zookeeper は保存されているすべてのデータをメモリにキャッシュします。このソリューションでは、メタデータ サービスがサポートできるデータ スケールがサーバーのメモリ容量によって大幅に制限されるため、メタデータ サービスを軽量化したり、データ サービスと一緒に展開したりすることが不可能になります。

***もう 1 つの方法は、分散ハッシュ テーブル (DHT) に基づいています。この方法の利点は、データ コピーの場所をメタデータに保存する必要がなく、一貫性のあるハッシュに基づいて計算されるため、メタデータ サービスのストレージとアクセスの負荷が大幅に軽減されることです。ただし、DHT を使用する場合の問題は、データのコピーの場所を制御できなくなることです。実際の運用環境では、これによりクラスター内でデータの不均衡が簡単に発生する可能性があります。同時に、運用および保守プロセス中に、ノードの追加、ノードの削除、ディスクの追加、またはディスクの削除の必要に遭遇した場合、ハッシュ リングが変更され、データの一部を再配布する必要があり、クラスター内で不要なデータ移行が発生し、データ量が非常に大きくなることがよくあります。このような運用・保守作業は、大規模な環境ではほぼ毎日発生します。大規模なデータ移行はオンライン サービスのパフォーマンスに簡単に影響を与える可能性があるため、DHT では運用と保守が非常に面倒になります。

上記で紹介した方法はいずれもさまざまな問題があり、そのまま使用することはできません。最終的に、ZBS はメタデータ サービスの問題を解決するために、LevelDB (RocksDB に置き換えることも可能) と Zookeeper の組み合わせを使用することを選択しました。まず、これら 2 つのサービスは比較的軽量です。 2 番目に、LevelDB と Zookeeper も本番環境で非常に安定しています。

ログレプリケーションと呼ばれるメカニズムを使用することで、LevelDB と Zookeeper の利点を活用しながら、それぞれの問題を回避できます。

ここでは、ログレプリケーションについて簡単に紹介します。簡単に言えば、データまたは状態はデータ操作の履歴セットと見なすことができ、各操作はログにシリアル化されて記録されます。すべてのログを取得し、ログに記録された操作を繰り返すことができれば、データの状態を完全に復元できます。ログを持つプログラムであれば、ログを再生することでデータを復元できます。ログをコピーすると、実際にはデータをコピーするのと同じになります。これがログレプリケーションの基本的な考え方です。

ZBS が Zookeeper + LevelDB を使用してログ レプリケーション操作を完了する方法を詳しく見てみましょう。まず、クラスター内には多数のメタ サーバーが存在し、各サーバーは LevelDB データベースをローカルで実行します。メタ サーバーは Zookeeper を通じてリーダーを選出し、メタデータ要求に応答するリーダー ノードを選択し、他のメタ サーバーはスタンバイ状態になります。

リーダー ノードはメタデータ更新操作を受信すると、その操作を一連の操作ログにシリアル化し、そのログを Zookeeper に書き込みます。 Zookeeper はマルチレプリケーションされているため、ログ データが Zookeeper に書き込まれると、ログ データは安全であることを意味します。同時に、このプロセスによりログのコピーも完了します。

ログが正常に送信されると、Meta Server はメタデータの変更を同時にローカル LevelDB に送信できます。ここで、LevelDB は完全なデータ セットを保存し、ログの形式で保存する必要はありません。

リーダー以外のメタ サーバー ノードの場合、Zookeeper からログを非同期的に取得し、デシリアライズによってログをメタデータ操作に変換してから、これらの変更操作をローカル LevelDB に送信します。これにより、各 Meta Server が完全なメタデータを保存できるようになります。

前述したように、Zookeeper のデータ保存容量はメモリ容量によって制限されます。 Zookeeper がメモリを過剰に消費するのを防ぐために、Zookeeper のログを定期的にクリーンアップします。ログがすべてのメタサーバーによって同期されている限り、Zookeeper に保存されているログはスペースを節約するために削除できます。通常、Zookeeper には 1 GB のログしか保存されませんが、これはメタデータ サービスをサポートするには十分です。

フェイルオーバーのロジックも非常にシンプルです。リーダー ノードに障害が発生した場合、他の残存するメタ サーバーは Zookeeper を通じてリーダーを再選出し、新しいメタ リーダーを選択します。新しいリーダーは、まず Zookeeper から未使用のログをすべて同期し、ローカルの LevelDB に送信してから、外部にメタデータ サービスを提供します。

ここで、ZBS におけるメタデータ サービスの実装の機能をまとめます。

まず第一に、原理は非常に理解しやすく、実装も非常に簡単です。 Zookeeper はリーダー選出とログレプリケーションを担当し、LevelDB はローカルメタデータの保存を担当します。この背後にあるロジックは、ロジックを可能な限り分割し、既存のプロジェクトの実装を可能な限り再利用することです。

第二に、速度が十分に速いです。 Zookeeper と LevelDB はそれ自体のパフォーマンスが優れており、本番環境では Zookeeper と LevelDB を SSD 上で実行しています。実際のテストでは、単一のメタデータの変更は数ミリ秒で完了します。同時実行シナリオでは、メタデータ変更ログをバッチ処理して同時実行機能を向上させることができます。

さらに、この方法はフェイルオーバーをサポートしており、フェイルオーバーの速度も非常に高速です。フェイルオーバー時間は、プライマリ ノードの選択時間とログ同期の時間の合計であり、メタデータ サービスを数秒で復元できます。

***デプロイメントについてお話ししましょう。オンラインで展開する場合、メタデータの信頼性要件を満たすために、通常、Zookeeper サービスのインスタンスを 3 つまたは 5 つ、Meta Server サービスのインスタンスを少なくとも 3 つ展開します。メタデータ サービスはリソースをほとんど消費せず、他のサービスと組み合わせて展開できます。

上記は基本的な原則です。 ZBS 内のメタデータ サービスの具体的な実装を見てみましょう。

上記のログ レプリケーション ロジックをログ レプリケーション エンジンにカプセル化します。これには、リーダーの選択、Zookeeper へのログの送信、LevelDB へのデータの同期などの操作が含まれており、開発の複雑さがさらに簡素化されます。

ログ レプリケーション エンジンに基づいて、チャンク マネージャー、NFS マネージャー、iSCSI マネージャー、エクステント マネージャーなどの多くの管理モジュールを含むメタ サーバー全体のロジックを実装しました。これらはすべて、ログ レプリケーション エンジンを通じてメタデータの特定の部分を管理できます。 RPC モジュールは、Meta Server によって外部に公開されるインターフェースです。外部コマンドを受信し、対応するマネージャーに転送する役割を担います。たとえば、ファイルの作成/削除、仮想ボリュームの作成/削除などです。さらに、Meta Server には非常に複雑なスケジューラ モジュールも含まれており、さまざまな複雑な割り当て戦略、回復戦略、負荷分散戦略、ハートビート、ガベージ コレクションなどの機能が含まれています。

以上がメタデータサービス部分の紹介です。