Nutanixバイブル/NutanixBible_2-13J のバックアップ(No.3)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
Nutanixバイブル/NutanixBible_2-13J へ行く。
- 1 (2014-09-08 (月) 13:52:21)
- 2 (2014-09-11 (木) 15:00:27)
- 3 (2014-09-18 (木) 16:47:04)

(2-13) アベイラビリティ・ドメインアベイラビリティドメインは、node/block/rackを認識(aware)した機能と同様の意味であり、各要素とデータの配置の決定することにより分散システムを守るための主要な構成要素である。 NDFSは、現時点でnodeとblockを認識(aware)し動作しており、クラスターサイズが成長するに従ってrackを認識することになるだろう。 Nutanixは、1台から4台の"node"を含むシャーシを"block"と呼称している。

注) block認識機能(awareness)を有効にするためには、最低3台のblockが必要となる。そうでない場合は、node認識運用(awareness)がデフォルトとして使用されている。 "block認識(awareness)"を確実に有効にするためには、各blockの構成を均一にして置く事が推奨される。共通のシナリオと使用される認識(awareness)のレベルは、この節の終わりに示されている。 3blockと云う要求は最低充足数に依るものである。

認識(awareness)機能は、以下の最重要な領域に分割される。

Data(The VM data)
Metadata(Cassandra)
Configuration Data(Zookeeper)

(2-13-1) データ blockの故障或いは計画停止の状況下で、データを利用可能に保つためにNDFSデータの複製が、cluster内の他のnodeに書込まれる。 block故障同様、RF2,RF3シナリオの両方に対しても同じである。
簡単な比較は、node故障の場合に保護を提供するために他のnodeにレプリカが作成されなければならない"node認識(awareness)"と簡単に比較してみよう。 block認識(awareness)は、block障害の場合にデータを利用可能に保つためにこの機能(node awareness)を更に強化したものである。
3blockで設置された場合にどの様にレプリカが配置されるのかを以下に示す。

<<Fig.2-13-01>>(図版挿入)

block故障が発生した場合でも、block認識(awareness)は維持されており、cluster内の他のblockに再度レプリカが作成される。

(2-13-2) metadata

先にスケーラブルmetadataの節で説明した通り、Nutanixは、Cassandraを強化改造したプラットフォームを活用しmetadataと他の本質的な情報を保存している。 Cassandraは、リング状のトポロジー構造を利用しデータの無矛盾性と利用可能性を確保するためにリング内のn個の同僚(node)にレプリカを作成する。

12nodeよりclusterを構成するCassandraリングの例を以下に示す

<<Fig.2-13-02>>(図版挿入)

Cassandraの同僚間でのレプリカ作成はリング上のnodeに対してで時計方向に繰り返される。block認識(awareness)機能を用いて、二つのレプリカを作成する同僚nodeは、それらが同じblock上で選択されることが無い様に選択される。

上記のリングをblockに基づいたレイアウトに置き直したnodeのレイアウトを以下に示す。

<<Fig.2-13-03>>(図版挿入)

このblock認識(aware)機能の本質として,blockに故障が発生した場合に最低でも2つのデータのコピーが存在している。 (Metadata RF3。より大きなClusterではRF5を使用しても良い)

リングを構成する全てのnodeの複製トポロジーの例を以下に示す。 (少々見辛いですが)

<<Fig.2-13-04>>(図版挿入)

(2-13-03) Conifguration Data

<<Fig.2-13-05>>(図版挿入)

<<Fig.2-13-06>>(図版挿入)

Nutanixバイブル