分散ストレージシステムにおけるデータ一貫性要件に関する簡単な説明

序文

分散ストレージは近年注目されているトピックの 1 つです。従来の SAN/NAS ストレージとの違いは、分散ストレージでは標準のハードウェア (x86 サーバーや 10GbE ネットワークなど) が使用されるのに対し、従来の SAN/NAS ストレージでは独自のハードウェアが使用されることです。標準ハードウェアを使用する利点は、汎用性があり、メーカーによって制限されず、安価で、必要に応じて拡張できることです。

ストレージ システムには、不可抗力の状況以外ではデータ損失が発生しないという鉄則があります。つまり、データは信頼性が高く、一貫している必要があります。これは、ストレージ システムの生命線またはボトムラインと呼ばれることがよくあります。分散ストレージは従来のストレージとは物理的な構造が異なるため、高いデータ信頼性を実現する方法も異なります。この記事では、このトピックに関する予備的な調査を行います。

[[207967]]

先に進む前に、まず概念を明確にしましょう。この記事で言及されている「分散ストレージ」とは、標準の x86 サーバーとネットワーク相互接続を使用し、その上で関連するストレージ ソフトウェアを実行するシステムを指します。クラウドコンピューティングは近年のホットな話題の 1 つであり、「クラウド ストレージ」も一般的な用語です。 OpenStack は中国で一般的なクラウド コンピューティング プラットフォームであり、クラウド ストレージは、Ceph、GlusterFS、Sheepdog など、OpenStack と組み合わせて使用​​される分散ストレージを指すことがよくあります。

「クラウドコンピューティング」や「クラウドストレージ」に加え、近年ではServerSANも話題になっています。概念的には「クラウド ストレージ」に近いものであり、x86 サーバーのグループを介して相互接続され、従来の SAN のようなストレージ インターフェイスを外部に提供します。サーバーSANに関わる国内メーカー数社も、Cephなどの分散ストレージシステムをパッケージ化し、外部に製品やサービスを提供しています。

起源

データの信頼性を確保するために、分散ストレージ システムは一般に、データの複数のコピー (通常は 3 つのコピー) または EC (これも本質的にはコピー) を保存することによって実装されます。たとえば、ユーザーが txt ドキュメントを保存する場合、基盤となる分散ストレージ システムでは、このドキュメントは 3 つのコピーに保存され、異なる障害ドメインの異なるハード ディスクに配置されます。こうすることで、ハードドライブが破損してもデータが失われることはありません。異なる障害ドメイン内の 2 つのハードディスクが同時に破損した場合でも、データは失われません。ただし、ハードディスクが破損した後、ストレージ システムは通常、それを適時に検出し、失われたコピーを完成します。

複数のコピーによりデータの信頼性は高まりますが、一貫性の問題も生じます。たとえば、データ A、A1、A2、A3 の 3 つのコピーがある場合、それらの内容の一貫性をどのように保証できるでしょうか?内容に一貫性がない場合は、問題があることを意味する場合が多いです。例えば：

• A1 コンテンツ: hello world
• A2コンテンツ: hello world
• A3コンテンツ: こんにちはw

A1 はユーザーによって実際に書き込まれたデータであると仮定します。 A1 が突然破損した場合、A2 と A3 の 2 つのコピーがあっても、データは失われます。

「コミットメント」と「コンプライアンス」

では、レプリカ間のデータの一貫性を確保するにはどうすればよいでしょうか?

まず、正当なデータを識別します。ここでのキーワードは「コミットメント」です。たとえば、ユーザーが「hello world」と書き込む場合、データはネットワークを介してストレージ システムに送信されます。ストレージ システムがフィードバックを受け取るまでは、ユーザーは書き込みが成功したかどうかはわかりませんし、ましてや書き込みが成功したと想定することもできません。データが正常に書き込まれたとみなされるのは、ストレージ システムがユーザーに「Hello World が正常に書き込まれました」というフィードバックを返した後のみです。これは「コミットメント」と呼ばれ、基盤となる分散ストレージ システムが、データが書き込まれ、マルチコピー メカニズムによって保護されていることを約束し、混乱や損失がなく、ユーザーが以前に書き込んだデータを読み取ることができることを意味します。

第二に、分散ストレージシステムは「コミットメント」を守らなければなりません。フィードバックが正常に書き込まれると、レプリカ ハードウェアの一部が破損してもデータ損失は発生しません。上記の例で A1 が破損した場合、A2 と A3 に残っているデータが「約束」と異なるため、データが失われます。

「コンプライアンス」をどのように実現するかは、分散ストレージ システムの中心的な課題の 1 つです。この問題を説明するために例を使ってみましょう。 Ceph を例にとると、データ書き込み要求は最終的に 3 つのレプリカに送信されます。ただし、Ceph はこれら 3 つのレプリカに対して 1 つのマスターと 2 つのスレーブのマスター スレーブ関係を確立しました。データはマスター レプリカにのみ送信され、その後、マスター レプリカによって他の 2 つのスレーブ レプリカに伝達されます。さらに、データが 3 つのレプリカ ノードに書き込まれる場合、最初に直接書き込みモードでローカル ジャーナルに書き込まれ、次に非直接書き込みモードでデータ ディスクに書き込まれます。

ここでは2つの質問があります:

1. 「マスター 1 台とスレーブ 2 台」のマスター スレーブ モデルを採用する理由は何ですか?

2. なぜジャーナルを書くのですか?

まず、「なぜマスタースレーブモードを使用するのか」という最初の質問について説明しましょう。まず、マスター コピーは結果収集ポイントとユーザー フィードバック ポイントとして機能します。誰かが 3 つのコピーの書き込み結果を要約、処理し、ユーザーにフィードバックする必要があります。ユーザーが自らデータを収集して処理することは、コピーメカニズムがユーザーのビジネスロジックに侵入することと同等であり、明らかに不合理です。専用ノード コーディネーターが中央コーディネーターとして使用されている場合、3 つのレプリカ書き込みの結果は最初にコーディネーターにフィードバックされ、その後コーディネーターによって処理されてユーザーにフィードバックされます。この方法の欠点の 1 つは、コーディネーターが IO パスに追加され、各 IO の時間消費が増加することです。 2 番目の欠点は、物理的なリソースへの投資が増加することです。 3 番目の欠点は、コーディネーターが失敗した場合、3 つのコピーがリーダーレスになり、コーディネーターを再選択するとさまざまな不都合が発生することです。

マスタースレーブモードを使用すると、マスター 1 つとスレーブ 2 つの合計 3 つのレプリカが存在するため、まず上記の 1 番目と 2 番目の欠点が回避されます。上記の 3 番目の欠点と比較すると、マスター スレーブ モードでは、マスター コピーが失敗した後のマスターの再選出がより自然かつ容易になります。

2 番目の質問、「なぜ日記を書くのか」について議論しましょう。 Ceph における「悪名高い」二重書き込み現象は、ジャーナルへの書き込みによって発生します。データのコピーを書き込むときは、最初に直接書き込みモードでジャーナルに書き込み、次に間接書き込みモードでファイルに書き込む必要があります。非常にコストがかかりますが、それでも実行する必要があります。これは、Ceph ストレージ システムがその生命線であるデータの信頼性を尊重していることを示しています。 Ceph Journal の主な機能はデータベースの WAL (Write Ahead Log) に似ているため、データ書き込みの原子性を提供し、障害発生時に遡って追跡できない中間データを回避します。

しかし、さらに考えてみると新たな疑問が浮かび上がってきます。ジャーナルは、障害が発生した場合に中間データの生成を回避できます。つまり、ジャーナルを使用した後、データの書き込みは部分的に成功するのではなく、完全に成功するか、完全に失敗します。ただし、障害回復後にレプリカ データが「完全な成功」状態にあるか「完全な失敗」状態にあるかはまだ判断できません。 Ceph は、マスターレプリカによって生成され、レプリカ間で同期される pglog によって決定されます。今回書き込まれたデータのバージョン番号が含まれており、ジャーナルにも保存されます。したがって、障害が発生すると、レプリカはデータ内のバージョン情報とジャーナル内のバージョン情報を比較して、「完全に成功した」か「完全に失敗した」かを判断し、クラスター レベルの障害回復プロセスに明確な入力を提供します。

まとめると、「約束」を「遵守」するのは簡単ではありません。これはジャーナルが重要であることを示しています。ジャーナルがなければ、分散ストレージ システムのデータの一貫性が疑わしくなります。

結論

この記事では、マルチコピー メカニズムの必要性とそれがもたらすデータ一貫性の課題について、日常的な考え方の観点から簡単に説明し、Ceph がこの課題にどのように対処するかの例を示します。しかし、言うのは簡単ですが、実行するのは難しいです。分散ストレージ システムでは、プログラミングの実践が特に重要です。