本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、
そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。
原文を参照したい方はNutanix Resiliency – Part 6 – Write I/O during CVM maintenance or failuresをご確認ください。
情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はID、パスワードの取得が必要です)
パート5ではCVMがメンテナンス中、または障害時にどの様にリードI/Oが行われるかを説明しました、今度は同じようにメンテナンス、障害のシナリオ期間中に発生するより重要な書込みI/Oについて知っておく必要があります。
パート5をお読みになった方は同じように感じるでしょう、まだパート5を読んでいないかたは是非パート5も読んでください。
さて、簡単にどのようにNutanix ADSFが書込みを行い、データ保護をしているか説明します。
下のダイアグラムでは3つのノードと一つの仮想マシンが存在しています。
仮想マシンは正常な状況では全ての書き込みは一つの複製と共に仮想マシンが稼働しているノード(ここではNode1)に書込み、他の複製（レプリカがRF3の場合も）をディスクの健全性を元にクラスタへ分散してデータ（a,b,c,d）を書き込みます。
ディスクの健全性(私が“Intelligent replica replacement”と呼んでいるもの)はデータはまず最も最適な場所にかかれます。
１または複数のノードが追加されるとすれば、”Intelligent replica placement”はクラスタがバランスの状態になるまで、たとえ新しい書込みが発生していなくてもノードに比例して複製を送信します。
ADSFはバックグラウンド処理で低い優先順位としてディスクが全体的に均衡になるように処理をするのです。
どのようにしてNutanix が複数の複製(Resiliency Factorと呼んでいるもの)を利用してデータ保護を行っているかの基本を理解した所で、Nutanix ADSFのストレージ部分のアップグレード時にどんな事が起こるか見てみましょう。
アップグレードは”ワンクリック”で始まり、それはRFやEC-Xの構成にかかわらず一度に1つのCVMがアップデートされるローリングアップデートのスタイルとなります。
ローリングアップグレードはCVMを一度オフラインにし、アップグレードの実施を行い、自己診断後にクラスタに参加し次のCVMが同じ処理を行います。
NutanixのストレージがHypervisorと分離している（例：ストレージがカーネルのなかに組み込まれているものではない）多くのアドバンテージの一つがアップグレードとストレージレイヤーの障害が仮想マシンに何の影響も与えない事なのです。
仮想マシンは再起動を必要としません（HAのようなイベントは無しです）そして仮想マシンを他のノードに移動する必要もありません。
たとえローカルコントローラーが如何なる理由でオフラインになっても、仮想マシンはストレージトラフィックの中断無しに稼働します。
もしローカルにあるCVMがメンテナンスや他の障害でダウンしたら、I/Oは動的にクラスタ内へリダイレクトされます。
CVMの仮想マシンが如何なる理由であれオフラインになった際のWrite I/O処理をみてみましょう。
ローカルのCVMがオフラインになるという事はCVMが稼働しているサーバの物理ドライブ（NVMe,SSD,HDDなど）が利用できなくなる事を意味していて、それはローカルデータ（複製）が使用できないことになります。
全てのライトI/Oは一つの複製をローカルに置くという事より、RFに従う形で書き込みが継続されます。データはリネットワーク越しにリモートのCVMを通して複製します。
次の例では3つのノードでノード1にいる仮想マシンが”E”のデータをネットワーク越しにNode2 , 3に書き込みます。これがリモートのCVMによって新しいデータが書き込まれる方法です。
もっと多くのノードがクラスタに存在していれば書き込みはクラスタ内のすべてのノードに”Intelligent Replica Placement”によって下の図のように分散されます。
新しいデータとは反対に上書きが発生した場合、ローカルにあるデータはCVMのオフラインにより利用できません。
Nutanixは他の複製に上書きを行い次にそのデータの複製をRFに応じて別のノードに書き込むことによってデータの整合性が保たれます。
これはとても重要な事で、もしデータがRF（VMware VSANでいうFTT）に常に準じていなければ次に起こりうるドライブ、ノード障害がデータ損失の原因になります。
vSANよりも優れたRFの大きなアドバンテージをNutanixにはるのは、全ての障害、メンテナンスシナリオに対してRF準拠する事です。
しかしvSANは全てのホストメンテナンス、障害シナリオのFTTを構成していません。
FTT1で構成されているvSAN上のVMはホストが提供している一つのvSANオブジェクトのメンテナンスでオフラインの場合、新しい上書きは保護されないため、一つのディスク障害がデータロスを引き起こす事があります。
VMware社のチーフテクノロジー Duncan Epping氏は最近に次の"VSAN:6.2でFTT=2がデフォルト"になる理由という記事を掲載しました。この記事によりDuncan Epping 氏はFTT=2をvSAN利用者のため、新しいデフォルト値として推奨したのです。
私はDuncan氏には同意です。しかしvSANをFTT=2にするべきとは言いません。
FTT=1はメンテナンス、または障害時の間の上書き処理に対する単一障害点となるのでFTT=2にしなければならないと考えます。これは多くの本番環境にとって受け入れがたい事です。
一方NutanixはvSANと同じアーキテクチャではないので、RF2は非常に優れ、このシリーズで説明したとおり、クリティカルな本番環境にも適しています。
そしてADSFはタイムリーにRFを復旧するのでRF2はvSANのFTT=1と比べても非常に優れていると言えるのです。
次はハイパーバイザのアップグレードで仮想マシンがどのように影響を受けるかを説明します。
Summary:
- Write I/O continues uninterrupted if the local CVM is offline
- Write I/O is distributed throughout the cluster evenly thanks to Intelligent Replica Placement
- All new data is written in compliance with the configured Resiliency Factor
- Overwrites of existing data is always written in compliance with the configured Resiliency Factor by writing a new replica where the original replica is not available.
- Data integrity is ALWAYS maintained regardless of a CVM being under maintenance or failure.
- Nutanix RF2 is more resilient than vSAN FTT=1 despite each claiming to maintain two copies of data.
記事担当者 : SI技術本部 カッシー @Nutanix_NTNX
