分散ストレージにおけるメタデータ管理

メタデータは、データを説明するデータ、データに関する説明情報、および情報リソースとして定義されます。

メタデータは、他のデータに関するデータ、またはリソースに関する情報を提供するために使用される構造化データです。メタデータは、情報リソースやデータなどのオブジェクトを記述するデータです。その目的は、リソースを特定することです。リソースを評価する。使用中のリソースの変更を追跡します。大量のネットワークデータのシンプルかつ効率的な管理を実現します。情報リソースの効果的な発見、検索、統合的な組織化、および使用されたリソースの効果的な管理を実現します。

メタデータ管理には、中央ノード メタデータ管理、分散メタデータ管理、メタデータフリー設計など、いくつかの一般的なソリューションがあります。この記事では、3 つのソリューションの特徴について説明します。

[[222051]]

1. 中央ノード管理メタデータ

分散（ストレージ）システムを設計する場合、中央ノードを使用するのは非常に簡潔で明確なソリューションです。中央ノードには通常、メタデータの保存とクエリ、クラスター ノードのステータス管理、意思決定、タスク配信の機能があります。

アドバンテージ：

A. 集中メタデータ管理機能により、クラスターの運用および保守管理の統計分析要件を簡単に処理できます。

B. 中央ノードはユーザーデータのステータス情報（メタデータ）を記録します。容量を拡張する場合、再バランス操作を実行しないことを選択できます (再バランスによって発生するデータ移行により、パフォーマンスに大きなオーバーヘッドが発生する可能性があります)。それでも、通常どおりにアドレス指定できます。

デメリットと解決策:

a.単一点障害は、分散システムの設計において最もタブー視される問題の 1 つです。中央ノードの単純な設計もこの問題を引き起こします。 HA を実現するにはどうすればいいですか?解決策: (1) マスタースレーブモデルを使用し、同期または非同期方式を使用してマスターとスレーブ間の増分データまたは完全データを同期する (TFS、mfs、HDFS2.0 など)、またはマスターとスレーブ間のリモート共有ストレージを使用する (リモートストレージの高可用性が必要な HDFS2.0 など)。

b.性能や容量の拡張には上限があります。集中センターノード自体のハードウェア設備には拡張（スケールアップ）上限とクエリベースのアドレス指定方式があり、これがこの問題の原因となります。クライアントがメタデータをキャッシュしたり、キャッシュ クラスターを使用したりしても、上限を根本的に排除することはできません。一部のシナリオ (大量の小さなファイルなど) では、この問題は依然として存在します。解決策：（1）SSDや大容量メモリを搭載したマシンなどを使用してハードウェアを最適化およびアップグレードする。 （2）この問題に直面した場合は、分散メタデータ管理ソリューションの使用を検討してください。

2. 分散管理メタデータ

中央ノード ソリューションと同様に、メタデータのみを分割し、分散ノードを使用してストレージを管理します。中央ノード ソリューションの利点を維持しながら、パフォーマンスと容量拡張の制限の問題を解決します。同時に、複数のノードが同時にメタデータ クエリ サービスを提供し、システム パフォーマンスが向上します。

欠点

このタイプのシステムは比較的珍しく、システム自体の構造が複雑で、実装も困難です。

a.システムには、メタデータ ノードとデータ ノードという 2 つの比較的独立した分散ノードが含まれています。どちらもステートフルノードです。各ノードから構成される分散モジュールは、分散 CAP 原則のトレードオフに直面し、特に一貫性に対する要件が高いメタデータについてはスケーラブルである必要があります。

b.メタデータ ノードは、データ ノードのステータスを共同で維持し、ステータスが変化した場合に一貫した決定を下す必要があります。これらすべてがシステムの設計と実装に大きな課題をもたらします。

紀元前さらに、大量のメタデータに必要なストレージデバイスも無視できないコストとなります。

上記の 2 つのソリューションには、データの状態 (メタデータ) を記録および維持し、データのアドレス指定時に最初にメタデータ サーバーにクエリを実行し、次に実際のデータにアクセスするという共通の考え方があります。

3. メタデータフリー設計

Ceph を例にとると、このタイプのシステムの主な考え方は上記の 2 つの考え方とは異なります。アドレス指定を計算するアルゴリズムを使用し、アドレス指定アルゴリズムの入力パラメータの 1 つは、クラスター状態 (データ ノード分散トポロジ、重み、プロセス状態など) の特定の形式の説明です。このタイプの一般的なアルゴリズムには、コンシステント ハッシュや Ceph RADOS システムの CRUSH アルゴリズムなどがあります。このタイプのアルゴリズムは通常、ユーザーデータを直接管理しませんが、より大きな粒度と限られた比較的固定の数を持つ論理シャーディング構造（一貫性のあるハッシュのリングフラグメントや Ceph の配置グループなど）の中間層を導入します。ユーザーがアクセスするデータは 1 つのシャードにのみ属します。システムはこれらのシャードを管理および保守し、次にユーザー データを管理および保守します。これらのシステムの中には、中央構成管理ノード (Ceph RADOS のモニターなど) を備えているものもありますが、これはクラスターやシャードなどの重要な状態の管理と保守のみを提供し、メタデータの保存やクエリは提供しません。

アドバンテージ：

A. 前述のとおり、システムでは論理シャードやクラスターのステータスなどの情報の管理と維持のみが必要であり、ユーザーデータを管理するためのメタデータは保存しません。システムのスケーラビリティが大幅に向上し、特に大量のメタデータが含まれるシナリオで顕著になります。

B. アドレス指定アルゴリズムに必要なパラメータデータの量は少なく、比較的固定されています。クライアントは、キャッシュを通じて複数のクライアントの並列アドレス指定の目的を達成し、アドレス指定のパフォーマンスのボトルネックを回避できます。

デメリット分析:

a.クラスターが拡張された場合（または重みが変更された場合）、特にデータ規模の大きいクラスター（PB レベル以上）では、再バランス調整が必要になります。これにより大量のデータ移行が発生するため、クラスターは常に高負荷状態となり、通常のビジネス リクエストのレイテンシや IOPS などのパフォーマンス指標が低下します。ただし、一部のシナリオでは、クラスターが拡張されたときに再バランス調整が望ましくない場合があります (クラスター容量が不十分な場合など)。この点では、各クラスターのパフォーマンスと容量を事前に評価し、拡張が必要になったときに新しいクラスターを直接作成するという戦略が一般的です。単一のクラスターを再バランスする必要がある場合は、手動介入と電流制限によってクラスターの負荷を軽減できます。リバランスが必要となる根本的な理由としては、拡張によってクラスターの状態が変化し、それによってアドレス指定アルゴリズムの結果が変わり、最終的なデータ配分もそれに応じて変更する必要があるためだと考えています。

b.データ レプリカの配布場所は、アドレス指定アルゴリズムによって計算されます。位置は比較的固定されており、手動で調整することはほとんどできません。ただし、通常は重みを変更することで全体的なデータ分布を変更できます。

紀元前中央構成管理ノードはシャード情報のみを管理し、個々のユーザーデータの情報は知りません。統計分析のニーズは、データノード情報を定期的に収集し、保存および維持することによって実現する必要があります。

要約: 上記の比較分析を通じて、3 種類のシステムのアドレス指定戦略によって、システム自体にそれぞれ対応する長所と短所があることがわかりました。どれも完璧ではありませんが、それぞれに適したシナリオとビジネスがあります。システムの設計と選択には包括的な考慮が必要です。