5 つの主要な分散ストレージ テクノロジの比較分析、どれを選びますか?

ストレージは種類によってブロックストレージ、オブジェクトストレージ、ファイルストレージに分けられます。主流の分散ストレージ技術の中で、HDFS/GPFS/GFSはファイルストレージに属し、Swiftはオブジェクトストレージに属し、Cephはブロックストレージ、オブジェクトストレージ、ファイルストレージをサポートできるため、統合ストレージと呼ばれています。

1. セフ

Ceph は Sage 氏の博士課程の研究から生まれました。結果は 2004 年に公開され、その後オープン ソース コミュニティに貢献されました。長年の開発を経て、多くのクラウド コンピューティングおよびストレージ ベンダーからサポートされ、最も広く使用されているオープン ソース分散ストレージ プラットフォームになりました。

Ceph は、シナリオに応じて、オブジェクト ストレージ、ブロック デバイス ストレージ、ファイル ストレージに分けられます。他の分散ストレージ技術と比較して、Ceph には次の利点があります。データを保存するだけでなく、ストレージ ノードの計算能力を最大限に活用します。各データを保存するときに、データが格納されている場所を計算し、データを均等に分散しようとします。同時に、CRUSHやHASHなどのアルゴリズムを使用しているため、従来の単一障害点がなく、規模が拡大してもパフォーマンスに影響はありません。

1. Ceph の主なアーキテクチャ

Ceph の最下層は、信頼性、インテリジェンス、分散という特徴を持つ RADOS (分散オブジェクト ストレージ システム) です。高信頼性、高拡張性、高パフォーマンス、高自動化などの機能を実現し、最終的にはユーザーデータを保存します。 RADOS システムは主に OSD とモニターの 2 つの部分で構成されています。

RADOS の上位にあるのは LIBRADOS で、これはライブラリにアクセスすることでアプリケーションが RADOS システムと対話できるようにするライブラリであり、C、C++、Python などの複数のプログラミング言語をサポートしています。

LIBRADOS レイヤーに基づいて開発されたインターフェースは、RADOSGW、librbd、MDS の 3 つです。

RADOSGW は、オブジェクト ストレージをサポートし、S3 および Swift と互換性のある、一般的な RESTFUL プロトコルに基づくゲートウェイです。

librbd は分散ブロック ストレージ デバイス インターフェイスを提供し、ブロック ストレージをサポートします。

MDS は POSIX 互換のファイル システムを提供し、ファイル ストレージをサポートします。

2. Ceph 機能モジュール

Ceph のコア コンポーネントには、クライアント、MON 監視サービス、MDS メタデータ サービス、および OSD ストレージ サービスが含まれます。各コンポーネントの機能は次のとおりです。

• クライアント: ストレージプロトコルへのアクセスとノードの負荷分散を担当
• MON 監視サービス: クラスタ全体の監視、クラスタの健全性の維持、OSD マップ、モニタ マップ、PG マップ、CRUSH マップなどのクラスタの状態を示すさまざまなチャートの維持を担当します。
• MDSメタデータサービス: ファイルシステムのメタデータを保存し、ディレクトリ構造を管理する役割を担う
• OSD ストレージ サービス: 主な機能は、データの保存、データの複製、データのバランス調整、データの回復、および他の OSD とのハートビート チェックの実行です。通常、1 つのハードディスクは 1 つの OSD に対応します。

3.Cephリソース分割

Ceph はクラッシュ アルゴリズムを使用して、大規模クラスターでの高速かつ正確なデータ ストレージを実現します。同時に、ハードウェア障害やハードウェア拡張が発生した場合のデータ移行を最小限に抑えることができます。原則は次のとおりです。

ユーザーが Ceph クラスターにデータを保存する場合、データは最初に複数のオブジェクトに分割されます (各オブジェクトにはオブジェクト ID があり、サイズを設定できます。デフォルトは 4MB)。オブジェクトは Ceph ストレージの最小のストレージ単位です。

オブジェクトの数が多いため、オブジェクトから OSD へのインデックス テーブルを効果的に削減し、メタデータの複雑さを軽減し、書き込みと読み取りをより柔軟にするために、pg (配置グループ) が導入されました。PG はオブジェクトの管理に使用されます。各オブジェクトはハッシュを通じて pg にマッピングされます。 pg には複数のオブジェクトを含めることができます。

次に、Pg は CRUSH を通じて計算され、osd にマップされます。コピーが 3 つある場合、データの冗長性を確保するために、各 pg は 3 つの osd にマップされます。

4. Cephへのデータの書き込み

Cephデータ書き込みプロセス

1) データは負荷分散を通じてノードの動的 IP アドレスを取得します。

2) ブロック、ファイル、またはオブジェクト プロトコルを介してノードにファイルを転送します。

3) データは 4M 個のオブジェクトに分割され、オブジェクト ID が取得されます。

4) オブジェクト ID は、HASH アルゴリズムを使用して異なる PG に割り当てられます。

5) CRUSHアルゴリズムにより、異なるPGが異なるOSDに割り当てられる

5. Cephの特徴

• Ceph はオブジェクト ストレージ、ブロック ストレージ、ファイル ストレージ サービスをサポートしているため、統合ストレージと呼ばれます。
• CRUSH アルゴリズムを採用することで、データが均等に分散され、高い並列性が得られ、固定されたメタデータ構造を維持する必要がなくなります。
• データは強力な一貫性があり、確認を返す前にすべてのコピーが書き込まれることを保証します。これは、読み取りが多く書き込みが少ないシナリオに適しています。
• 分散化、MDSは同じステータスを持ち、固定された中央ノードは存在しない

Ceph にはいくつかの欠点があります。

 分散型ソリューションには事前の計画と設計が必要であり、技術チームに対する要件が比較的高くなります。

 Ceph を拡張すると、バランスのとれたデータ分散特性により、ストレージシステム全体のパフォーマンスが低下します。

2. 地球環境

GFS は、大量の検索データを保存するために特別に設計された Google の分散ファイル ストレージ システムです。これは 2003 年に提案されたクローズドソースの分散ファイル システムです。大きなファイルの読み取りや書き込みなど、大量の順次読み取りや順次追加に適しています。単一の読み取りと書き込みの遅延ではなく、大きなファイルの持続的で安定した帯域幅に重点を置きます。

1. GFSの主なアーキテクチャ

GFS アーキテクチャは比較的シンプルです。 GFS クラスターは通常、マスター、複数のチャンクサーバー、および複数のクライアントで構成されます。

GFS では、すべてのファイルは複数のチャンクに分割され、各チャンクには一意で不変の識別子 (チャンクの作成時にマスターによって割り当てられる) があり、すべてのチャンクは実際にはチャンクサーバーのディスクに保存されます。

災害復旧のために、各チャンクは複数のチャンクサーブに複製されます。

2. GFSの機能モジュール

 GFS クライアント: POSIX API に似たアプリケーション用の API を提供します。また、GFS マスターから読み取ったメタデータ チャンク情報もキャッシュします。

 GFS マスター メタデータ サーバー: コマンド スペース (ディレクトリ階層)、アクセス制御情報、ファイルとチャンクのマッピング、チャンクの場所など、すべてのファイル システムのメタデータを管理します。同時に、マスターは、チャンクの作成、レプリケーション、データ移行、ガベージ コレクションなど、システム内のさまざまなアクティビティも管理します。

 GFS チャンクサーバー ストレージ ノード: すべてのチャンクを保存するために使用されます。ファイルは固定サイズ (デフォルトでは 64 MB) の複数のチャンクに分割され、各チャンクにはグローバルに一意のチャンク ID が付けられます。

3. GFS書き込みプロセス

1) クライアントは、変更するチャンクがどのチャンクサーバー上にあるか、またチャンクの他のコピーの場所情報をマスターに問い合わせます。

2) マスターはプライマリとセカンダリの関連情報をクライアントに返します。

3) クライアントはデータをプライマリとセカンダリにプッシュします。

4) すべてのレプリカがデータの受信を確認すると、クライアントはプライマリに書き込み要求を送信し、プライマリは異なるクライアントの操作にシーケンス番号を割り当てて、操作が順番に実行されるようにします。

5) プライマリは書き込み要求をセカンダリに送信し、セカンダリはプライマリによって割り当てられたシーケンス番号の順序ですべての操作を実行します。

6) セカンダリが実行を完了すると、実行結果をプライマリに応答します。

7) プライマリは実行結果をクライアントに応答します。

上記からわかるように、GFS はデータを書き込む際に次の特性を持ちます。

• GFS がデータを読み書きする場合、データ フローと制御フローは分離され、複数のレプリカにわたってデータを書き込むときに、リース メカニズムを使用して順次一貫性が確保されます。
• マスターは、プライマリ レプリカと呼ばれるレプリカの 1 つにチャンク リースを発行します。プライマリ レプリカはチャンクが書き込まれる順序を決定し、セカンダリ レプリカはこの順序に従うため、グローバルな順次一貫性が確保されます。
• マスターは、プライマリ レプリカとセカンダリ レプリカの場所情報をクライアントに返します。クライアントは、将来使用するためにこの情報をキャッシュします。プライマリレプリカが配置されているチャンクサーバーが利用できない場合、または返されたリースの有効期限が切れた場合にのみ、クライアントはマスターに再度接続する必要があります。
• GFS はチェーン プッシュを使用して、各マシンのネットワーク帯域幅を最大限に活用し、ネットワークのボトルネックや高遅延の接続を回避し、プッシュの遅延を最小限に抑えます。
• GFS は、遅延を最小限に抑えるために TCP を使用してデータをストリーミングします。

4. GFSの機能

• 大容量ファイル、特にGBレベルの大容量ファイルに適しており、データアクセスの遅延に敏感でない検索サービスに適しています。
• 集中型アーキテクチャ、アクティブなマスターは 1 つだけ
• キャッシュとプリフェッチ: クライアント側でメタデータをキャッシュすることで、マスターとのやり取りを最小限に抑え、ファイルを事前に読み取ることで同時実行パフォーマンスを向上させることができます。
• 高い信頼性。マスターが保持する必要があるデータは、操作ログとチェックポイントを通じて複数のコピーに保存されます。障害が発生すると、マスターは自動的に切り替わり、再起動します。

3. HDFS

HDFS (Hadoop Distributed File System) は、市販のハードウェア上で実行するのに適した分散ファイル システムです。これは Hadoop のコア サブプロジェクトであり、ストリーミング データ モードで非常に大きなファイルにアクセスして処理するというニーズに基づいて開発されています。このシステムは Google ファイル システム (GFS) をモデルにしており、GFS の簡略化されたオープン ソース バージョンです。

1. HDFSの主なアーキテクチャ

 HDFS クライアント: NameNode からファイルの場所の情報を取得し、DataNode からデータを読み書きします。さらに、データを保存する際のファイルのセグメント化はクライアントの責任となります。

 NameNode（メタデータノード）：名前空間、データブロックのマッピング情報を管理し、レプリケーション戦略を構成し、クライアントの読み取りおよび書き込み要求を処理します。

 DataNode（ストレージノード）：実際の読み取りおよび書き込み操作を実行し、実際のデータブロックを保存する役割を担います。同じデータ ブロックが複数の DataNode に保存されます。

 セカンダリネームノード: メタデータを定期的にマージし、ネームノードにプッシュします。緊急時には、NameNode の HA リカバリを支援できます。

2. HDFSの特徴（GFSと比較）

• ブロックは大きくなり、各ブロックはデフォルトで 128 MB になります。
• 同時実行はサポートされておらず、一度に許可されるライターまたはアペンダーは 1 つだけです。
• プロセスの一貫性、書き込まれたデータの送信順序は最終的な書き込み順序と一致します。
• マスターHAバージョン2.Xは2つのネームノード（それぞれアクティブ状態とスタンバイ状態）をサポートし、フェイルオーバー時間は通常数十秒から数分です。

3. HDFSに適したアプリケーションシナリオ

• 大容量ファイルやビッグデータの処理に適しており、最大 GB、TB、さらには PB レベルのデータを処理できます。
• ストリーミング ファイル アクセス、一度書き込み、何度も読み取りに適しています。
• ファイルが書き込まれると、それを変更することはできず、追加することしかできません。

4. HDFS が適さないシナリオ:

• 低遅延のデータアクセス。
• 小さなファイルストレージ
• 同時書き込み、ランダムファイル変更

迅速

Swift は、もともと Rackspace によって開発され、2010 年に OpenStack オープンソース コミュニティに提供された分散オブジェクト ストレージ サービスです。元のコア サブプロジェクトの 1 つとして、Nova サブプロジェクトに仮想マシン イメージ ストレージ サービスを提供します。

1. Swiftの主なアーキテクチャ

Swift は、完全に対称的なリソース指向の分散システム アーキテクチャ設計を採用しています。すべてのコンポーネントはスケーラブルであるため、単一点障害によるシステム全体の可用性への影響を回避できます。

Swiftのコンポーネントには以下が含まれます

• プロキシ サーバー: 外部にオブジェクト サービス API を提供し、対応するアカウント、コンテナー、またはオブジェクト サービスにリクエストを転送します。
• 認証サーバー: ユーザーのIDを確認し、アクセストークンを取得します。
• キャッシュサーバー: トークン、アカウント、コンテナ情報をキャッシュしますが、オブジェクトデータ自体はキャッシュしません。
• アカウント サーバー: アカウントのメタデータと統計を提供し、コンテナーのリストを管理するサービス。
• コンテナサーバー: コンテナのメタデータと統計情報を提供し、含まれるオブジェクトのリストを管理するサービス
• オブジェクト サーバー: オブジェクト メタデータとコンテンツ サービスを提供します。各オブジェクトはファイル システム内にファイルとして保存されます。
• レプリケータ: ローカルコピーとリモートコピーが一致しているかどうかを確認し、プッシュを使用してリモートコピーを更新します。
• アップデータ: オブジェクトのコンテンツを更新します
• 監査人: オブジェクト、コンテナ、アカウントの整合性をチェックします。エラーが見つかった場合、ファイルは隔離されます。
• Account Reaper: 削除対象としてマークされたアカウントを削除し、そのアカウントに含まれるすべてのコンテナーとオブジェクトを削除します。

2. Swiftのデータモデル

Swift のデータ モデルは、アカウント/コンテナ/オブジェクトの 3 つの層を持つ階層構造を採用しています。各層のノード数に制限はなく、任意に拡張可能です。データモデルは次のとおりです。

3. 一貫性のあるハッシュ関数

Swift は、計算によって仮想空間内の仮想ノードにオブジェクトを均等に分散するコンシステント ハッシュ テクノロジに基づいており、ノードを追加または削除するときに移動する必要があるデータの量を大幅に削減できます。

効率的なシフト操作を容易にするために、仮想空間のサイズは通常 2n です。リングと呼ばれる独自のデータ構造を通じて、仮想ノードが実際の物理ストレージ デバイスにマッピングされ、アドレス指定プロセスが完了します。次の図に示すように:

ハッシュ空間は4バイト（32ビット）で、仮想ノードの最大数は232です。ハッシュ結果をmビット右にシフトすると、2（32-m）個の仮想ノードを生成できます（上図のように、m=29のとき、8個の仮想ノードを生成できます）。

4. リングデータ構造

Swift は、アカウント、コンテナ、オブジェクトごとに個別のリングを定義します。

リングは、仮想ノード (パーティション) を一連の物理ストレージ デバイスにマッピングし、ある程度の冗長性を提供するように設計されています。リングのデータ情報には、ストレージデバイスリストとデバイス情報、パーティションとデバイスのマッピング関係、計算されたパーティション番号の変位（上図のm）が含まれます。

アカウント、コンテナ、オブジェクトのアドレス指定プロセス。 (オブジェクト アドレス指定プロセスを例に挙げます)

1) オブジェクト階層 account/container/object をキーとして使用し、MD5 ハッシュ アルゴリズムを使用してハッシュ値を取得します。

2) ハッシュ値の最初の 4 バイト (m ビット) を右シフトしてパーティション インデックス番号を取得します。

3) パーティションとデバイスのマッピング テーブルで、パーティション インデックス番号に従って、オブジェクトが配置されているパーティションに対応するすべての物理デバイス番号を検索します。以下のように表示されます。

5. Swiftの一貫したデザイン

Swift が Quorum 仲裁プロトコルを採用

• 定義: N: データのコピーの総数。 W: 書き込み操作が受け入れられることが確認されたコピーの数。 R: 読み取り操作のコピー数
• 強力な一貫性: R+W>N。これにより、レプリカの読み取り操作と書き込み操作が交差し、最新バージョンを読み取ることができることが保証されます。
• 弱い一貫性: R+W<=N、読み取り操作と書き込み操作のレプリカ セットが交差しない可能性があり、この時点でダーティ データが読み取られる可能性があります。

Swift のデフォルト構成は N=3、W=2、R=2 です。つまり、各オブジェクトには 3 つのコピーがあり、書き込みを成功させるには少なくとも 2 つのコピーを更新する必要があります。 2 つの読み取りデータ間に不整合がある場合、検出および複製プロトコルを通じてデータ同期が完了します。

R=1 の場合、ダーティデータが読み取られる可能性があります。このとき、一定の一貫性を犠牲にすることで読み取り速度を向上させることができます（また、データの最終的な一貫性を確保するために、一貫性をバックグラウンドで同期することもできます）。

クォーラム プロトコルの例を以下に示します。

6. Swiftの機能

• ネイティブオブジェクトストレージは、リアルタイムのファイル読み取り、書き込み、編集機能をサポートしていません。
• 完全に対称的なアーキテクチャ、マスターノードなし、単一障害点なし、スケールアップが容易、パフォーマンスと容量が直線的に増加
• データは最終的な一貫性を実現し、すべてのコピーを書き込まなくても返すことができます。データを読み取るときは、データのコピーを検証する必要があります。
• これは OpenStack のサブプロジェクトの 1 つであり、クラウド環境での展開に適しています。
• Swift のオブジェクト ストレージと Ceph が提供するオブジェクト ストレージの違いは、クライアントがオブジェクト ストレージ システム サービスにアクセスする場合、Swift ではクライアントが Swift ゲートウェイにアクセスしてデータを取得する必要があることです。 Ceph は各ストレージノード上の OSD (オブジェクト ストレージ デバイス) からデータ情報を取得できます。データの一貫性という点では、Swift のデータは結果的に一貫性がありますが、Ceph はクラスタ間で常に強い一貫性があります。

5. Lustre 分散ストレージ

Lustre は、Linux プラットフォームをベースにしたオープン ソースのクラスター (並列) ファイル システムです。これは、Pete Bramble によって設立された Cluster File Systems Inc. によって 1999 年に初めて開発されました。その後、HP、Intel、Cluster File System、米国エネルギー省によって共同開発されました。 2003 年に正式にオープン ソースとなり、主に HPC スーパーコンピューティング分野で使用されています。

1. Lustreの主なアーキテクチャ

Lustre コンポーネントには次のものが含まれます。

• 管理サーバー (MGS): クラスター内のすべての Lustre ファイル システムの構成情報を保存します。 Lustre クライアントは MGS に接続して情報を取得し、MDS とストレージ スペースを共有できます。
• メタデータ サーバー (MDS): MDT に保存されているメタデータを管理し、1 つ以上の MDT に保存されているメタデータを Lustre クライアントで使用できるようにします。各 MDS は 1 つ以上の MDT を管理できます。
• メタデータ ターゲット (MDT): MDS は、メタデータ (ファイル名、ディレクトリ、権限、ファイル レイアウトなど) を保存するために使用されます。 MDT は複数の MDS に使用できますが、一度にアクセス可能なのは 1 つの MDS のみです。
• オブジェクト ストレージ サーバー (OSS): 1 つ以上のローカル OST に対してファイル I/O サービスとネットワーク要求処理を提供します。通常、OSS は 2 ～ 8 個の OST にサービスを提供します。
• オブジェクト ストレージ ターゲット (OST): ユーザー ファイル データは 1 つ以上のオブジェクトに保存され、各オブジェクトは個別の OST に配置されます。
• Lustre クライアント: Lustre クライアント ソフトウェアを実行し、Lustre ファイル システムをマウントできるコンピューティング ノード。クライアント ソフトウェアには、管理クライアント (MGC)、メタデータ クライアント (MDC)、および複数のオブジェクト ストレージ クライアント (OSC) が含まれます。各 OSC はファイル システム内の OST に対応します。
• 論理オブジェクト ボリューム (LOV) は、OSC を集約することによってすべての OST への透過的なアクセスを提供し、論理メタデータ ボリューム (LMV) は、MDC を集約することによってすべての MDT への透過的なアクセスを提供します。

2. 光沢の特徴

• 数万のクライアントシステム、PBレベルのストレージ容量をサポートし、1つのファイルは最大320TBの容量をサポートします。
• RDMAネットワーク、大容量ファイルの読み取りおよび書き込みシャーディングの最適化をサポートし、複数のOSSでより高い総帯域幅を実現
• レプリケーション メカニズムはなく、単一障害点が存在します。クライアントまたはノードに障害が発生した場合、そのノードに保存されているデータは、再起動されるまでアクセスできなくなります。
• 高性能コンピューティング (HPC) 分野に適用可能で、大容量ファイルの連続的な読み取りと書き込みに適しています。

6. 主流の分散ストレージ技術の比較

いくつかの主流の分散ストレージ技術の特性は次のように比較されます。

さらに、分散ストレージシステムの設計コンセプトによれば、ソフトウェアとハ​​ードウェアは分離されており、信頼性やパフォーマンスの向上など、分散ストレージの多くの機能はソフトウェアによって提供されるため、基盤となるハードウェアはもはや重要ではないと考えられる傾向があります。しかし、多くの場合、そうではありません。分散ストレージ システムを統合する場合、適切な分散ストレージ テクノロジを選択するだけでなく、基盤となるハードウェアの互換性も考慮する必要があります。一般的に、分散ストレージ システム製品には、ハードウェアとソフトウェアのオールインワン マシン、ハードウェア OEM、ソフトウェア + 標準ハードウェアの 3 つの形式があります。選択する際には、製品の成熟度、リスク回避、運用および保守の要件と、自社の技術力を考慮して、適切な製品形態を選択する必要があります。

元のタイトル: 主流の分散ストレージ技術の比較分析と応用。ご質問がある場合は、記事の最後をクリックして原文をお読みになり、コミュニティにコメントを残してください。

推奨資料/記事:

分散ストレージ技術ルートの選択に関する議論

http://www.talkwithtrend.com/Question/424127

金融業界向け分散ストレージソリューションの設計

http://www.talkwithtrend.com/Document/detail/tid/416333