本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001、
そしてVMware Certified Design Expert (VCDX) #90として活動しているJosh Odger氏によるものです。
原文を参照したい方はNutanix Resiliency – Part 5 – Read I/O during CVM maintenance or failures?をご確認ください。
情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報は、ぜひ当社のポータルから取得ください。
(初回はID、パスワードの取得が必要です)
これまでにADSFがノード障害からの復旧が早いという事、またどRF2～3にすることで回復性能を高めること、そして稼働したまま空き容量を効率化するためのEC-Xへの変更を話してきました。
今回はCVMがAOSアップグレードの間のメンテナンス期間中、またはCVMの障害が発生している間、どのように仮想マシンが影響を受けるかというクリティカルで重要な話題をしていきます。
では簡単に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の仮想マシンが如何なる理由であれオフラインになった際のRead I/O処理をみてみましょう。
ローカルのCVMがオフラインになるという事はCVMが稼働しているサーバの物理ドライブ（NVMe,SSD,HDDなど）が利用できなくなる事を意味していて、それはローカルデータ（複製）が使用できないことになります。
全てのリードI/Oはリダイレクトされクラスタ内のすべてのCVMによってリード処理は継続されます。
このメンテナンス・障害のシナリオは仮想マシンがストレージを提供できなくなってもネットワーク越しにストレージを利用できるノードは稼働するという点において3Tierアーキテクチャと比較ができます。
Nutanixはクラスタのすべてのノードでリードが提供できる分散アーキテクチャなので最悪のケースとして3ノードクラスタでノード障害、もしくはメンテナンスの期間中であってもデュアルコントローラーのストレージと同等の機能があるわけです。
繰り返しますと、3ノードクラスタで1ノードが障害または、メンテナンスとなる最悪のシナリオが発生しているクラスタのリードはリモートから読み込みます。
Nutanixの最も悪いデグレード状態は最適な状態のデュアルコントローラーのストレージにコンピュートノードがアクセスするのと同等なのです。
もしNutanixが8ノードで構成しており、1台がメンテナンスまたはダウンしても7台のノードがVMへストレージアクセスを行うのです。
この処理は実際には何も新しくなく、Nutanixが昔から行っている方法なのです。
詳細はAcropolis Hypervisor (AHV) I/O Failover & Load Balancing 2015年の7月のBlogにも記載があります。
ローカルのCVMが一度オンラインになればリード I/Oは再びローカルのCVMによって提供され、リモートへの読み込みはデータがローカルに無い場合に発生します。
リモートの読み込みが発生するとそのデータを含む1MBのエクステントがローカライズされリードはローカルから読み込まれるようになります。
エクステントのデータがローカライズされることはリモートのリードを行うことに比べて追加のオーバーヘッド無く、ローカライズは追加のオーバーヘッド無しにパフォーマンスが良くなるという事を理解する事は非常に重要な事です。
Summary:
- ADSF writes data on the node where the VM resides to ensure subsequent reads are local.
- Read I/O is serviced by the local CVM and when the Local CVM is unavailable for any reason the read I/O is serviced by all CVMs in the cluster in a distributed manner
- Virtual machines do not need to be failed over or evacuated from a node when the local CVM is offline due to maintenance or failure
- In the worst case scenario of a 3 node cluster and a CVM down, a virtual machine running on Nutanix has it’s traffic serviced by at least two storage controllers which is the best case scenario for a Server + Dual Controller Storage Array (3 Tier) architecture.
- In clusters larger than three, Virtual machines on Nutanix enjoy more storage controllers serving their read I/O than an optimal scenario for a Server + Dual Controller Storage Array (3 Tier) architecture.
記事担当者 : SI技術本部 カッシー @Nutanix_NTNX
