本記事は[2枚目]Nutanix Advent Calendar 2017への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。1枚目のNutanix Advent Calendar 2017もどうぞ。
本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。
原文を参照したい方はWhy Nutanix Acropolis hypervisor (AHV) is the next generation hypervisor – Part 5 – Resiliencyをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。
信頼性についての話をする場合、データの信頼性のみを見てしまい、ビジネスアプリケーションを稼働させるために必要なストレージコントローラーや管理コンポーネントの信頼性については見落とされてしまうという過ちが多くあります。
RAIDやホットスペアのドライブといった従来からのテクノロジーは場合によってはデータの信頼性を提供しますが、スケールアウトも自己修復もできないデュアルコントローラータイプのストレージに接続されていた場合、単一のコンポーネントの障害であったとしても、データが利用できなかったり、パフォーマンスや機能がいくばくか低下するというようなことに見舞われます。信頼性の回復について、ハードウェア交換に依存したインフラストラクチャは私がハードウェアサポート契約と24x7 4時間オンサイトはもはや必要のないものになった(和訳予定なし)という記事で以前議論したとおり、根本的に崩壊しているのです。
加えて、もしも管理アプリケーションのレイヤに信頼性がなくなった場合、データレイヤの高可用性や信頼性が阻害されることになり、ビジネスアプリケーションは(例えば普通のスピードでは)うまく動作しなくなったり、まったくもって動かなくなることもあるでしょう。
Acropolisプラットフォームはデータと管理レイヤの双方に高い信頼性を提供しており、N+1またはN+2(Resiliency Factor 2 または 3)に設定することができます。これによって最大2つのノード障害が同時に発生しても管理そしてデータを失わずに対応することができます。更に、｢ブロックアウェアネス｣があればブロック全体(最大4ノード)の障害においてもクラスタは完全な機能を維持し続けます。こう考えるとXCPのデータと管理コンポーネントの信頼性は最大でN+4であるということもできます。
更に、より大きなXCPクラスタではノード/コントローラー/コンポーネントの障害の影響はより小さくなっていきます。4ノードの環境でN-1は25%のインパクトですが、8ノードのクラスタでは12.5%です。クラスタが大きければ大きいほどコントローラー/ノードの障害のインパクトは低減されるのです。対象的にデュアルコントローラーのSANにおいては単一コントローラーの障害は50%もの品質低下影響があり、その後に障害が起きれば完全な停止に追い込まれます。Nutanix XCP環境は自己治癒機能を持っているため、障害イベントでもN-1になるだけです。その後に機能する自己治癒がその後に発生する障害からも保護を行ってくれるため、大きな影響や停止を起こすことはないのです。
Acropolisのマスターインスタンスが障害を起こした場合でも、30秒以内で完了する新たなマスター選出によって完全な機能が環境に復元されます。これは管理の可用性が｢シックスナイン｣(99.999%)以上であることと等価です。重要なのはAHVはこの管理の信頼性が組み込まれているということです。さらに設定をする必要もありません!
更に詳しい情報についてはこちら: Acropolis: の拡張性(和訳予定なし)
データの高可用性についてはハイパーバイザーに関係なくNutanix分散ストレージファブリック(DSF ー Distributed Storage Fabric)は2つまたは3つのデータ/パリティを保持しており、SSD/HDDもしくはノードの紹介時に設定されたRFをクラスタ内のすべてのノードで復元します。
データの信頼性
データの信頼性だけが重要な要素ではないとはお話しましたが、やはりこれはキーとなります。結局のところ、データを失う可能性のある共有ストレージソリューションではあらゆるデータセンタの目的に見合ったソリューションにはなりえないのです。
データの信頼性についてはNutanixの分散ストレージファブリックの根幹ですから、データ信頼性のステータスはPrismのホームスクリーンに表示されます。以下のスクリーンショットで我々は信頼性が定常状態にいるのか、または障害(キャパシティのリビルド)時のイベントの両方を確認する事ができます。
この例ではクラスタ内のすべてのデータは設定されたResiliency Factor(RF2 または 3)コンプライアンスに従っている状態です。そして、クラスタは最低限のN+1のノード障害時のリビルドのためのキャパシティも確保しています。
信頼性のステータスのさらに詳細に分け入るためにはシンプルに上のボックスをクリックするだけです。そうすれば更に細かな障害からの保護についての詳細が表示されます。
以下のスクリーンショットはメタデータなどを示していまっす。OpLog(永続的Writeキャッシュ)とZookeeperなどのバックエンドの機能が監視されており、必要なときにはアラートが発行されます。
これらのどれか一つでも通常もしくは｢グリーン｣状態でない場合、Prismは管理者へアラートを発報します。アラートの原因がノード障害の場合、Prismは自動的に(Pulse経由で)Nutanixのサポートへと通知を行い、必要なパーツを出荷を初めます。大抵の場合、ハードウェアのメンテナンスのSLAが4時間オンサイトなどであったとしても、Nutanix XCPクラスタはハードウェアの到着よりも随分前に自己治癒を終えています。
これはNutanixがハードウェア(の交換)に依存しない信頼性をもっていることのまたとない例です。
データの完全性
ゲストOSとしてへのWrite I/Oの完了通知はデータが永続メディアに書き込まれた後のみであるべきです。これはこの時まではストレージがバッテリーバックアップのキャッシュや無低電源装置(UPS)で保護されていたとしても、データを失う可能性が伴います。
唯一のWriteの事前完了通知を行うメリットはパフォーマンスですが、良いパフォーマンスのためにデータの完全性やがデータそのものが失われてしまうリスクを犯しますか?
もう一つの一般的に見逃されがちなエンタープライズグレードのストレージソリューションについての要件はサイレントなデータの欠落を検出し、復元する能力です。Acropolisはソフトウェアで全てのWriteとRead両方にチェックサムをつけています。重要なことはNutanixはその下のハードウェアやサードパーティのソフトウェアにデータの完全性を維持するための機構で依存していないということです。全てのチェックサム発行と(必要な場合の)復元はネイティブで行われます。
プロのコメント : もしストレージソリューションがチェックサムをWriteとReadの両方で行っていない場合にはそのソリューションは本稼働環境では使わないで下さい。
サイレントなデータの欠落(あらゆるベンダーのあらゆるストレージデバイスがこの影響を受けます)が起きた場合、チェックサムが合わず、I/Oは別のノード(もちろん、物理的に別のSSD/HDD)上にある別のレプリカから取得されます。もしイレイジャーコーディング環境でチェックサムが合わなかった場合、EC-XがデータをHDD/SSD障害時と同様の方法で再計算し、I/Oを提供します。
バックグラウンドでNutanix Distributed Storage Fabricはデータの欠落を無効化し、設定されているResiliency Factorを壊れていないレプリカか、EC-Xが利用されている場合にはストライプから復元するのです。
このプロセスは完全に仮想マシンやエンドユーザーからは透過的に行われますが、XCPの信頼性に置ける重要なコンポーネントです。下にある分散ストレージファブリック(DSF)は自動的にAcropolis管理コンポーネントも保護します。これは全てのコンポーネントが一緒に作られていて、後からボルトドメされているわけではないAcropolisアーキテクチャの多くの先進性の1つの例です。
RF3(Replication Factor 3)に設定されているストレージコンテナのAcropolis環境ではN+2の管理の可用性が提供されます。結果として、ほとんど起きそうにもない、同時に3ノードの障害が起きない限りは管理が停止していまうということもありません。幸いなことにXCPはこの起こりそうにもないシナリオに対しても回答を持っています。ブロックアウェアネスを利用すれば3もしくはそれ以上のブロックでもクラスタを保護し、ブロック全体(最大4ノード)の障害においてもデータと管理をオフラインにせずに済みます。
Acropolisの信頼性周りの話の一部として、複雑性がないという話に戻りましょう。Acropolisは1クリックのローリングアップグレードをすべての機能において実現しています。単一障害点は一切ありません。最悪のシナリオとしてAcropolisマスターを載せているノードが障害を起こしたとしても、30秒以内に別の生き残ったノード上で次のマスターロールが再起動され、仮想マシンの電源を開始します。繰り返しになりますが、これは組み込まれた機能で、設計/インストール/維持が必要な追加もしくはサードパーティのソリューションを必要とはしません。
上で述べてきた点はAHV自身というよりは大部分がXCPの機能です、ですからAHVのロードバランシング機能と障害対応機能を取り上げたいと思います。
従来型の3階層のインフラストラクチャ(例 SAN/NAS)とは異なり、Nutanixのソリューションはマルチパスを必要としません。これは全てのI/Oがローカルのコントローラーから提供されるからです。結果としてマルチパスのポリシーの選択などの別のレイヤーの複雑性や潜在的な障害点になりうるものを排除できているのです。
しかしながら、ローカルのCVMが何らかの理由で利用できなくなった時には最も効率的な方法でI/Oをノード上のすべての仮想マシンに提供しなくてはなりません。AHVはこれを以下に示すようにvDiskレベルでランダムにリモートのStargateへI/Oをリダイレクトすることで実現しています。
AHVがこれをできる理由は全てのvDiskがiSCSI経由で提示されており、自身のターゲット/LUNを所有しているからです。つまりvDisk自体がTCP接続を保持しています。これは例えばMS SQL/ExchangeもしくはOracleのような複数のvDiskが必要となるようなビジネスクリティカルなアプリケーションを同時に複数のコントローラーで利用できるということを意味します。
結果として全ての仮想マシンのI/OはAcropolisクラスタ全体に負荷分散され、これによって単一のCVMがボトルネックにならないということを保証します。仮想マシンは障害時やメンテナンス時も素晴らしいパフォーマンスを得ることができるのです。
更に詳しくはこちら: Acropolis Hypervisor (AHV) I/O Failover & Load Balancing(和訳予定なし)
まとめ:
- 以下に対応する最初から有効になっている自己治癒の機能:
- SSD/HDD/ノード障害
- Acropolis と PRISM (管理レイヤー)
- 組み込みのデータの完全性とソフトウェアベースのチェックサム
- 最大で4台同時のノード障害を無害化
- 管理の高可用性は99.9999%以上 (シックス“ナイン”)
- データと管理の信頼性についてはハードウェアに依存していない
更に詳しくはこちら: Ensuring Data Integrity with Nutanix – Part 2 – Forced Unit Access (FUA) & Write Through(和訳予定なし)
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
今回はもっとも重要な･･･そして長い記事です。データの信頼性はもちろん、管理コンポーネントの信頼性についても記載されていますが、AHVの優れている(そしてユニークな)ポイントはvDisk一つ一つを仮想マシンがiSCSIでTCP接続しているという点でしょう。iSCSIの接続が切れる(CVMの障害などで)場合でも瞬時に別のCVM経由で再接続され、I/Oの停止は発生しません。これはNFSやCIFSで接続されている他のハイパーバイザーでは実現できない･･･つまりNutanixなりの思い切った実装が元になっています。
こうした複雑なことをしていても、Prismがそれをキレイに覆い隠してくれる･･･それがNutanixのいいところですね。さて、次は第6弾ですが、明日はちょっと別の内容をはさみます。
