メタデータの末尾にスキップ
メタデータの先頭に移動

一貫性

Many distributed databases have embraced eventual consistency over strong consistency because it makes such systems easier to implement for scale. しかしながら、そのようなシステムではアプリケーションで起こりえる変則的なことを扱う負荷が発生します。言い換えると、最終的な一貫性はプログラミングモデルの複雑さ増加のコストの上に成り立っています。

ClustrixDBは知的なデータ分散複数バージョンの並行処理制御(MVCC), および Paxosの組み合わせを使ってスケールすることができます。このやり方により、ClustrixDBは書き込みがある時のwriteのスケール、readのスケール、およびACIDセマンティックスを提供します。ClustrixDBがどうやってreadとwriteのスケールをするかを詳しく説明するために、<s3>並行処理制御モデル構造のドキュメント</s3>を参照してください。

一言で言えば、ClustrixDBは一貫性のために以下のアプローチを取ります:

  • クラスタ内の同期リプリケーション。全ての参加しているノードはwriteが完了する前にwriteを認識する必要があります。writeは並行して実行されます。
  • 分散されたトランザクションの解決のためのPaxos プロトコル。
  • commitされたreadのサポート、Repeatable Read (really Snapshot) 隔離レベル。直列化の限定サポート。
  • MVCC はロックレスのreadを考慮します; writeはreadをブロックしないでしょう。   

耐障害性

ClustrixDBはクラスタに渡って複数のデータのコピーを保存することで、耐障害性を提供します。耐障害性の程度は指定されたコピーの数に依存します(最少は2)。ClustrixDBがどのように耐障害性を処理するかを完全に理解するためには、まずデータ分散モデルに慣れている必要があります。

以下の章は考えられる障害ケースをカバーしていて、ClustrixDBがそれぞれの状況をどのように処理するかを説明します。この一連の例では、以下を仮定しています:

  • フロントエンドとバックエンドのネットワークが独立した5つのノードからなるクラスタ。
  • 合計5つのデータのスライスとそれぞれ2つずつのレプリカ。プライマリのレプリカは文字(例えば、A)でラベルが付けられていて、一方でセカンダリのレプリカはアポストロフィ(例えば、A')でラベルが付けられています。 

ノードの永続的な喪失

なんらかの永久的なハードウェア障害により、クラスタがノード#2を喪失した時に何が起こるかを考えてみましょう。障害が発生したノードはクラスタの残りの部分によってもはやアクセスされることはありません。しかしながら、システム内の他のノードはデータのコピーを持っています。 

以下の図では、ClustrixDBがどのようにノード障害から回復するかを説明しています。私たちのデータ分散モデルはpeer to peer であり、master-slave ではありません:

  • 複数のノードが一つの障害ノードのリカバリに参加します。In ClustrixDB data reprotection is a many-to-many operation. これはたくさんのノードを持つクラスタが障害ノードからリカバーするよりも早いことを意味します。
  • クラスタが一旦スライスAとCの新しいコピーを作成すれば、それぞれのスライスの二つのレプリカの完全に保護されたシステムを持ちます。クラスタは障害ノードの置き換えの必要無しに他の障害を扱うことができます。

Figure: 完全なノードの障害の処理障害ステート(左)と回復ステート(右)

複数のノードの喪失

ClustrixDBは k をレプリカの数とした時に、同時に k-1 のノードの喪失を許容することができます。例えば、3つのレプリカで設定されたシステムでは、ClustrixDBは同時に二つのノードの喪失まで耐えることができます。しかしながら、その余分な防護のレベルは、クラスタ内の余分なストレージ容量を犠牲にしてできています。.

一時的なノードの利用不可

In some circumstances, a node can exit quorum for a brief period of time. カーネルパニックまたはなんらかの種類の電力のイベントがそのような状況を起こしえます。In those cases, we expect the node to return to quorum much faster than it would take to reprotect the entire data set. ClustrixDB provides special handling for this failure scenario by setting up a log of changes for the data on the unavailable node that is replayed when the node re-joins the cluster.

下の例では、ノード #4 が一時的にクラスタを離れます。ノード #2 と #5 はノード #4 のデータの変更を追跡するためにログ(キューと呼ばれる)をセットアップします。ノード #4 がクラスタに戻ると、ノード #4 は記録された変更を再生します。これら全ての操作はデータベースによって自動的に処理されます。

図: 一時的なノードの喪失障害ステート(左)と回復ステート(右)  

フロントエンドのネットワークの障害

ClustrixDBはフロントエンドネットワークの冗長性の設定をサポートします。ClustrixDB Applianceは、インバウンドまたはマルチホーム設定で動作可能な 4 x GigE ネットワークインタフェースを提供します。そのようなセットアップは完全なフロントエンドのネットワーク障害の可能性を非常に減らします。

そのような障害発生した場合には、障害を起こしたノードはクエリ resolution に参加したままになるでしょう。しかしながら、アプリケーションから入っている接続を受け付けることはできないでしょう。

バックエンドネットワーク障害

ClustrixDBはバックエンドネットワーク障害とノード障害を区別しません。もしノードがバックエンドネットワーク上で相手と通信できない場合は、heartbeatチェックに失敗しシステムはノードがオフラインと見なすことでしょう。 

可用性

ClustrixDBは障害に直面しても可用性を提供することができます。完全な可用性を提供するためには、ClustrixDBは以下を要求します:

  • 過半数のノードがクラスタから利用可能である(すなわち、定数の要求)。
  • 利用可能なノードが、各データセットの少なくとも一つのレプリカを持っている。

ClustrixDBの可用性モードと障害ケースを理解するには、私たちのグループメンバーシッププロトコルを理解する必要があります。

グループメンバーシップと定数

ClustrixDB は分散グループメンバーシッププロトコルを使用します。そのプロトコルは二つの基本的なセットを維持します: (a) クラスタに知られている全てのノードの静的なセット、および (b) 現在のところお互いに通信可能なノードのセット。

静的なメンバーシップの半数以上のノードがお互いに通信できない限りは、クラスタを構成できません。言い換えると、ClustrixDBは split-brain シナリオに耐えられないでしょう。

例えば、もし6つのノードのクラスタが、3つのノードの二つのセットになるネットワーク分割を経験すると、ClustrixDBはクラスタを構成することを拒否するでしょう。

しかしながら、もしノードの半分以上が通信可能であれば、ClustrixDBは多数の方のセットのクラスタを構成するでしょう。

部分的な可用性

In the above example, ClustrixDB formed a cluster because it could form a quorum. しかしながら、そのようなクラスタは部分的な可用性しか提供できない可能性があります。言い換えると、そのクラスタは完全なデータセットへのアクセスを持っていないかもしれません。

以下の例では、ClustrixDBは二つのレプリカを保持しています。しかし、Aのレプリカを持っている両方のノードは(なんらかの障害、またはなんらかの利用可能にできない他の条件によって)クラスタに参加することができません。トランザクションがスライスAでデータにアクセスしようとした場合、データベースはアプリケーションに対して明るみにでるエラーを生成するでしょう。When

TOP
inserted by FC2 system