&edit(,nolabel);&br;
-&color(black){(2-01) データの保護 (Data Protection)};

>以下のビデオを併せご参照下さい。

-&ref(http://player.vimeo.com/video/105582611?autoplay=1,"video");

>Nutanix Platformは、現在、resiliency factor 即ち replicaton factor(RF)とchecksumを
用いて、node,diskの故障や機能低下が発生した場合にdataの冗長性と有効性を保障している。
上記に述べた通り、[[OpLog>Terms/OpLog]]は、低遅延のSSD tierへの書込み発生を吸収するための処理の段階と
なる。   hostへの書込みに成功した事を知らせるacknowledge(ack)が発行される前に、
ローカルな[[OpLog>Terms/OpLog]]に書込まれる時に、dataは同期的にRFの値に依って他の１つ或いは２つの[[CVM>Terms/CVM]]の[[OpLog>Terms/OpLog]]に
複製される。

>この仕組により、少なくても２～３箇所の独立した異なった場所にデータが存在しているため、
障害に耐性があることを意味している。

>注) RF3を実現するためにはmetadataはRF5となるため、最低5nodeが必要となる。Data RFは、
PRISM経由でコンフィグレーションが行われ、コンテナレベルで実現されている。

>いかなる"ホットノード"も除外しスケールがリニアに実現されることを保障するために、全てのnodeが
OpLogの複製に参加している。   dataが書込まれている間にchecksumが計算され、metadataの一部として
[[OpLog>Terms/OpLog]]の複製に参加している。   dataが書込まれている間にchecksumが計算され、metadataの一部として
保存される。  そして、dataは、RFが暗黙のうちに維持されているextent storeは、非同期的に書出される。
node或いはdiskに障害が発生した場合、dataはRFを維持しているため、クラスター内の全nodeにわたって
再度複製が作られる。   dataが読取られる時は常に、dataが正しいものであることを保障するために
checksumが計算される。  checksumとdataが、一致しない様な事態が発生した場合、複製からdataが
読み出され正しくない複製を置換える。   

>以下の図は、この仕組が論理的にどの様な見え方をするのかを表している。


>&color(black){<<Fig.2-01-01>>};

CENTER:&ref("Nutanixバイブル/NutanixBible_2-01J/Fig-2-01-01_NDFS_OplogReplication.png","Fig.2-01-01");

&edit(,nolabel);[[Nutanixバイブル]]
----
トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS