SDS アーキテクチャの簡単な比較、または適切なストレージ プラットフォームの検索 (GlusterVsCephVsVirtuozzoStorage)

この記事は、自分にとって適切なソリューションを選択し、Gluster、Ceph、Vstorage (Virtuozzo) などの SDS の違いを理解できるように作成されました。

本文では、特定の問題をより詳細に開示した記事へのリンクを使用しているため、不要な冗長性のない重要なポイントと、必要に応じてインターネットで独自に入手できる入門情報を使用して、説明はできるだけ簡潔にします。

実際、もちろん、取り上げられたトピックにはテキストのトーンが必要ですが、現代の世界では、あまり本を読むことを好まない人が増えています）））、そのため、すぐに読んで選択することができ、何かが必要な場合は、不明瞭な場合は、リンクをたどるか、不明瞭な単語をグーグルで検索してください)))、そしてこの記事は、これらの深いトピックの透明なラッパーのようなもので、各決定の主要なキーポイントである充填物を示しています。

光沢剤

Gluster から始めましょう。Gluster は、仮想環境用のオープンソースに基づく SDS を備えたハイパーコンバージド プラットフォームのメーカーによって積極的に使用されており、RedHat Web サイトのストレージ セクションにあり、Gluster または Ceph の XNUMX つの SDS オプションから選択できます。

Gluster は、ファイル配布などのすべての作業を実行するサービスであるトランスレータのスタックで構成されています。 ブリックは XNUMX つのディスクをサービスするサービスで、ボリュームはこれらのブリックを結合したボリューム (プール) です。 次にDHT（分散ハッシュテーブル）機能を利用してファイルをグループに分散するサービスです。 シャーディング サービスについては、以下のリンクで関連する問題について説明するため、説明には含めません。

書き込み時には、ファイル全体がブリックに保存され、そのコピーが同時に XNUMX 番目のサーバー上のブリックに書き込まれます。 次に、XNUMX 番目のファイルが、異なるサーバー上の XNUMX つ (またはそれ以上) のブリックからなる XNUMX 番目のグループに書き込まれます。

ファイルのサイズがほぼ同じで、ボリュームが XNUMX つのグループのみで構成されている場合は、すべて問題ありませんが、他の条件では、記述から次の問題が発生します。

• グループ内のスペースは不均等に使用されます。これはファイルのサイズによって異なります。ファイルを書き込むのに十分なスペースがグループ内にない場合は、エラーが発生し、ファイルは書き込まれず、別のグループに再配布されません。 ;
• XNUMX つのファイルを書き込む場合、IO は XNUMX つのグループにのみ行われ、残りはアイドル状態になります。
• XNUMX つのファイルを書き込むときにボリューム全体の IO を取得することはできません。
• また、一般的な概念は、データがブロックに分散されていないため、生産性が低いように見えます。現在のように、ファイル全体がブロックに入るのではなく、均一に分散することでバランスを取り、問題を解決する方が簡単です。

公式説明文より 建築 また、gluster が従来のハードウェア RAID 上のファイル ストレージとして機能することも無意識のうちに理解しています。 ファイルをブロックに分割 (シャーディング) する開発の試みがありましたが、これはすべて、既存のアーキテクチャ アプローチにパフォーマンスの損失を課す追加であり、さらに Fuse などのパフォーマンスに制限がある自由に配布されたコンポーネントの使用を伴います。 ファイルをブロックに分散するときにストレージのパフォーマンスとフォールト トレランス機能を制限するメタデータ サービスはありません。 「分散レプリケート」構成では、より優れたパフォーマンス指標が観察されます。最適な負荷分散で信頼性の高いレプリカ 6 を構成するには、ノードの数が少なくとも 3 つである必要があります。

これらの調査結果は、ユーザー エクスペリエンスの説明にも関連しています 光沢剤 そしてそれと比較すると セフ、このより生産的で信頼性の高い構成の理解につながる経験の説明もあります。 「複製された分散」。


この図は、0 つのファイルを書き込むときの負荷分散を示しています。最初のファイルのコピーは、ボリューム 1 グループに結合された最初の XNUMX 台のサーバーに分散され、XNUMX 番目のファイルの XNUMX つのコピーは、XNUMX つのグループの XNUMX 番目のグループ volumeXNUMX に配置されます。サーバー。 各サーバーには XNUMX つのディスクがあります。

一般的な結論は、Gluster を使用できるということですが、仮想環境のコンピューティング負荷にもリソースが必要となるハイパーコンバージド ソリューションの特定の条件下では、パフォーマンスとフォールト トレランスに制限があり、困難が生じることを理解した上で使用してください。

特定の条件下で達成できる Gluster パフォーマンス指標もいくつかあります。 耐障害性。

セフ

それでは、私が作成できたアーキテクチャの説明から Ceph を見てみましょう。 探す。 との比較もあります グルスターフスとセフここで、Ceph のサービスには負荷がかかっているすべてのハードウェア リソースが必要であるため、Ceph を別のサーバーにデプロイすることが推奨されることがすぐにわかります。

アーキテクチャ セフ Gluster よりも複雑で、メタデータ サービスなどのサービスもありますが、コンポーネントのスタック全体は非常に複雑で、仮想化ソリューションで使用するにはあまり柔軟性がありません。 データはブロックに保存されるため、より生産的であるように見えますが、すべてのサービス (コンポーネント) の階層では、特定の負荷や緊急条件下で損失と遅延が発生します。たとえば、次のような状況です。 論文。

アーキテクチャの説明から、中心となるのは CRUSH であり、そのおかげでデータを保存する場所が選択されます。 次に PG が来ます。これは理解するのが最も難しい抽象概念 (論理グループ) です。 CRUSHをより効果的にするにはPGが必要です。 PG の主な目的は、オブジェクトをグループ化してリソース消費を削減し、パフォーマンスとスケーラビリティを向上させることです。 オブジェクトを PG に結合せずに、個別に直接アドレス指定すると、非常にコストがかかります。 OSD は、個々のディスクに対するサービスです。

クラスターには、さまざまな目的およびさまざまな設定の XNUMX つまたは複数のデータ プールを含めることができます。 プールは配置グループに分割されます。 配置グループには、クライアントがアクセスするオブジェクトが保存されます。 ここで論理レベルが終了し、物理レベルが始まります。これは、各配置グループに XNUMX つのメイン ディスクと複数のレプリカ ディスクが割り当てられるためです (正確な数はプールのレプリケーション係数によって異なります)。 つまり、論理レベルではオブジェクトは特定の配置グループに保存され、物理レベルではオブジェクトに割り当てられたディスクに保存されます。 この場合、ディスクは物理的に別のノード上に配置することも、別のデータセンターに配置することもできます。

このスキームでは、配置グループはソリューション全体の柔軟性に必要なレベルのように見えますが、同時に、このチェーン内の追加のリンクとして見え、意図せず生産性の低下を示唆します。 たとえば、データを書き込む場合、システムはデータをこれらのグループに分割し、物理レベルでメイン ディスクとレプリカ用のディスクに分割する必要があります。 つまり、ハッシュ関数はオブジェクトの検索および挿入時には機能しますが、副作用があり、コストが非常に高く、ハッシュの再構築 (ディスクの追加または削除時) に制限がかかります。 ハッシュに関するもう XNUMX つの問題は、変更できないデータの場所が明確に定められていることです。 つまり、何らかの理由でディスクの負荷が増加した場合、システムには（別のディスクを選択することにより）書き込みを行わない機会はありません。ハッシュ関数は、どんなに不良であっても、ルールに従ってデータを検索することを義務付けます。そのため、Ceph は自己修復またはストレージの増加の場合に PG を再構築するときに大量のメモリを消費します。 結論としては、Ceph は (遅いとはいえ) うまく機能しますが、それはスケーリング、緊急事態、または更新がない場合に限られるということです。

もちろん、キャッシュやキャッシュ共有を通じてパフォーマンスを向上させるオプションもありますが、これには優れたハードウェアが必要であり、依然として損失が発生します。 しかし全体的に見ると、生産性という点では Gluster よりも Ceph の方が魅力的に見えます。 また、これらの製品を使用する場合は、重要な要素を考慮する必要があります。これは、すべてを正しく展開、構成、保守することが非常に重要であるため、Linux に重点を置いた高いレベルの能力、経験、プロフェッショナリズムです。これにより、管理者にはさらに大きな責任と負担が課せられます。

Vストレージ

建築がさらに面白く見えます Virtuozzo ストレージ(Vstorage)、同じノード上のハイパーバイザーと組み合わせて使用​​できます。 腺ただし、良好なパフォーマンスを実現するには、すべてを正しく構成することが非常に重要です。 つまり、アーキテクチャに従った推奨事項を考慮せずに、このような製品を任意の構成にすぐに導入することは非常に簡単ですが、生産的ではありません。

kvm-qemu ハイパーバイザーのサービスの隣にストレージとして共存できるもの。これらは、コンパクトで最適なコンポーネント階層が見つかったサービスのほんの一部です: FUSE 経由でマウントされたクライアント サービス (オープン ソースではなく、修正済み)、MDS メタデータ サービス(メタデータ サービス)、サービス チャンク サービス データ ブロック。物理レベルでは 6 つのディスクに相当し、それだけです。 もちろん、速度の点では、XNUMX つのレプリカを備えたフォールト トレラント スキームを使用するのが最適ですが、SSD ドライブでキャッシュとログを使用する場合は、エラー トレラント コーディング (消去コーディングまたは RaidXNUMX) を XNUMX 台のドライブで適切にオーバークロックできます。ハイブリッド方式、またはオールフラッシュではさらに優れています。 EC（イレースコーディング）には、XNUMXつのデータブロックを変更する際にパリティ量を再計算する必要があるという欠点があります。 この操作に関連する損失を回避するために、Ceph は EC への書き込みを遅延させ、特定のリクエスト中にパフォーマンスの問題が発生する可能性があります。たとえば、すべてのブロックを読み取る必要があり、Virtuozzo ストレージの場合は変更されたブロックの書き込みが実行される場合です。 「ログ構造化ファイル システム」アプローチを使用し、パリティ計算コストを最小限に抑えます。 EC を使用した場合と使用しない場合の作業の加速に関するオプションをおおよそ見積もるには、次のようになります。 電卓。 – 数値は機器メーカーの精度係数に応じておおよその値になる可能性がありますが、計算結果は構成を計画する際に役立ちます。

ストレージコンポーネントの単純な図は、これらのコンポーネントが吸収しないことを意味するものではありません。 鉄資源、 しかし、すべてのコストを事前に計算しておけば、ハイパーバイザーとの連携を期待できます。
Ceph ストレージ サービスと Virtuozzo ストレージ サービスによるハードウェア リソースの消費量を比較するためのスキームがあります。

以前は、古い記事から最も重要な行を使用して Gluster と Ceph を比較することができましたが、Virtuozzo ではそれがより困難になります。 この製品に関する記事はあまりなく、情報はドキュメントからのみ収集できます。 英語 Vstorage を、次のような企業のハイパーコンバージド ソリューションで使用されるストレージとみなす場合は、ロシア語で説明します。 ロスプラットフォーム そしてアクロニス。

このアーキテクチャの説明を手助けしようとしているので、もう少しテキストが多くなりますが、ドキュメントを自分で理解するには多くの時間がかかり、既存のドキュメントは表を修正することによってのみ参照として使用できます。内容を確認したり、キーワードで検索したりできます。

上で説明したコンポーネントを備えたハイブリッド ハードウェア構成での記録プロセスを考えてみましょう。記録は、クライアントが開始したノード (FUSE マウント ポイント サービス) に送信され始めますが、もちろんメタデータ サービス (MDS) マスター コンポーネントは、クライアントを目的のチャンク サービス (ストレージ サービス CS ブロック) に直接誘導します。つまり、MDS は記録プロセスには参加せず、単にサービスを必要なチャンクに誘導します。 一般に、樽に水を注いで録音することに例えることができます。 各バレルは 256MB のデータ ブロックです。

つまり、256 つのディスクは、そのようなバレルの特定の数、つまりディスク容量を XNUMXMB で割ったものです。 各コピーは XNUMX つのノードに分散され、XNUMX 番目のコピーはほぼ並行して別のノードに分散されます。XNUMX つのレプリカがあり、キャッシュ (ログの読み取りおよび書き込み用) 用の SSD ディスクがある場合、書き込みの確認は書き込み後に行われます。ログは SSD に保存され、SSD からの並列リセットは、バックグラウンドであるかのように HDD 上で続行されます。 レプリカが XNUMX つの場合、レコードは XNUMX 番目のノードの SSD からの確認後にコミットされます。 XNUMX つの SSD の書き込み速度の合計を XNUMX で割ると、XNUMX つのレプリカの書き込み速度が得られるように見えるかもしれませんが、コピーは並行して書き込まれ、ネットワークのレイテンシー速度は通常 SSD の速度よりも高くなります。実際、書き込みパフォーマンスはネットワークに依存します。 この点に関して、実際の IOPS を確認するには、次の方法で Vstorage 全体を正しくロードする必要があります。 方法論つまり、メモリやキャッシュではなく実際の負荷をテストするため、正しいデータ ブロック サイズやスレッド数などを考慮する必要があります。

SSD 上の上記の記録ログは、データが SSD に入力されるとすぐにサービスによって読み取られ、HDD に書き込まれるように機能します。 クラスターごとに複数のメタデータ サービス (MDS) があり、その数は Paxos アルゴリズムに従って動作するクォーラムによって決定されます。 クライアントの観点から見ると、FUSE マウント ポイントは、クラスター内のすべてのノードに同時に表示されるクラスター ストレージ フォルダーであり、各ノードにはこの原則に従ってマウントされたクライアントがあるため、このストレージは各ノードで利用できます。

上記のいずれかのアプローチを実行するには、計画と展開の段階で、集約と正しく選択されたネットワーク チャネル帯域幅によるバランスがとれるネットワークを正しく構成することが非常に重要です。 アグリゲーションでは、適切なハッシュ モードとフレーム サイズを選択することが重要です。 上で説明した SDS とは非常に大きな違いもあります。これは、Virtuozzo ストレージの高速パス テクノロジと融合しています。 これにより、最新化されたヒューズに加えて、他のオープンソース ソリューションとは異なり、IOPS が大幅に向上し、水平または垂直のスケーリングに制限されなくなります。 一般に、上記のアーキテクチャと比較すると、これはより強力に見えますが、そのような楽しみを得るには、Ceph や Gluster とは異なり、もちろんライセンスを購入する必要があります。

要約すると、XNUMX つの上位を強調することができます。アーキテクチャのパフォーマンスと信頼性の点で Virtuozzo Storage が XNUMX 位、Ceph が XNUMX 位、Gluster が XNUMX 位です。

Virtuozzo Storage の選択基準: アーキテクチャ コンポーネントの最適なセットであり、高速パス、柔軟なハードウェア構成セット、リソース消費量の削減、コンピューティング (コンピューティング/仮想化) との共有機能を備えたこの Fuse アプローチ向けに最新化されています。つまり、彼が参加しているハイパーコンバージド ソリューションに完全に適しています。 Ceph が XNUMX 位にあるのは、ブロックの操作、より柔軟なシナリオ、および大規模なクラスターで動作する機能により、Gluster に比べて生産性の高いアーキテクチャであるためです。

vSAN、Space Direct Storage、Vstorage、Nutanix Storage の比較、HPE および Huawei 機器での Vstorage のテスト、および Vstorage を外部ハードウェア ストレージ システムと統合するシナリオを書く予定ですので、この記事が気に入ったら、フィードバックをいただけるとうれしいです。コメントやご希望を考慮して、新しい記事のモチベーションを高めることができます。

出所： habr.com