本記事は[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 3 – Scalabilityをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。
拡張性は単にクラスタもしくはストレージの最大キャパシティを形成するノードの数ということではありません。拡張性のもっと重要な面は管理、パフォーマンス、キャパシティ、堅牢性という多くの観点から環境を拡張できるということで、そして運用の観点から拡張がどのような影響をおよぼすのかということになります。
AHVの管理/管理者に必要とされるコンポーネントの拡張性について見ていきましょう :
管理の拡張性
AHVは自動的に管理コンポーネントのサイズを最初のクラスタの展開中、およびクラスタにノードが追加された際に決定します。これは最初のサイジングまたはXCPの管理コンポーネントの拡張を最初から最後まで考える必要が無いということになります。
Resiliency Factorが3(N+2)で構成されているのであれば、Acropolisの管理コンポーネントは自動的にN+2の要件を満たすところまで自動的に拡張されます。よく考えてみましょう。N+2を単一レイヤーで実現するのでは意味がありません。可用性は鎖のように連なっており、最も弱い部分と同じだけの可用性しかもたらさないのです。
ストレージキャパシティの拡張
Nutanixの分散ストレージファブリック(DSF - Distributed Storage Fabric)にはストレージキャパシティの上限はありません。それだけではなく、ストレージキャパシティはNX-6035Cのような"Storage-only"ノードを利用することでコンピューティングとは別に拡張することさえできます。NutanixのStorage onlyノードは従来型のストレージと比べてキャパシティを拡張しようとする際の問題を排除してくれるのです。
AHV(サポートされているハイパーバイザーとの相互互換もあります)を動作させているStorage-onlyノードを拡張することはお客様のキャパシティの拡張をハイパーバイザーを気にせずに行えるということです。Storage-onlyノードはハイパーバイザーのライセンシングや別の管理コンポーネントを必要としません。Storage onlyノードはAcropolis BaseソフトウェアとAHVをコンピューティング+ストレージノードと同様にワンクリックアップグレードを完全にサポートしています。結果として、Storage onlyノードはインビジブルで、どのノードにキャパシティとパフォーマンスを追加したいのかということは完全に分離されているのです。
NutanixのStorage onlyノードは従来型のストレージにおけるキャパシティの拡張の際の問題を排除してくれます。詳しい情報については従来型の共有ストレージの拡張の際の問題点(和訳予定なし)をご参照下さい。
従来型のストレージに置ける拡張時の問題の一部はドライブのシェルフの追加とデータサービス/管理が拡張できないということです。これはIOPS/GBの低下とストレージコントローラーなどのコンポーネント障害時にワークロードに大きな影響が出るということに結びつきます。
Storage onlyノードの拡張は非常にシンプルです。例えば、あるお客様は8台のNX6035CをvSphereクラスタに追加するということを今年の10月のvForumオーストラリアのショールームフロアからノートパソコンで実施しています。
https://twitter.com/josh_odgers/status/656999546673741824
それぞれのstorage-onlyノードがクラスタに追加されると軽量のNutanix CVMがクラスタに追加され、データサービスを提供しはじめ、リニアな管理とパフォーマンスの性能拡張が保証されます。ですから、従来型ストレージにあった拡張性の問題は存在しないのです。
Storage onlyノードについて詳しくはこちら : http://t.co/LCrheT1YB1
コンピューティングの拡張性
クラスタ内で高可用性を実現するということはHAのために1台もしくはそれ以上のノードを予約するということを意味します。これはハイパーバイザーのクラスタサイズの最大値が制限されている場合には不必要な非効率性を生み出してしまいます。AHVには単一クラスタに於いてさえ、ノード数の上限値はありません。結果として、AHVはHAのためにクラスタ毎に1台もしくはそれ以上のノードを予約しなければならず、それによってインフラが非効率化してしまう不必要なサイロを避けることができます。AHVのノードは自動的に既存のクラスタに追加される際に必要な設定が施されます。管理者がしなくてはならないのは基本的なIPアドレスの情報とExpand Clusterというボタンを押すだけで、残りはAcroplisがすべてやってくれます。
Nutanixクラスタの拡張をどのように行うかのデモは以下を御覧ください :
YouTube: Expanding a Nutanix cluster
分析の拡張性
AHVは組み込みで他のAcropolis管理コンポーネントと一緒に分析機能も含んでいます。分析コンポーネントは初期展開時とノード追加での拡張時に自動的にサイジングされます。
これは管理者が新たに分析インスタンスもしくはコンポーネントを拡張･展開しなくてはならない閾値はないということを意味しています。分析機能とそのパフォーマンスは規模に関係なくリニアな状態を維持します。
これはAHVでは分析機能の提供のために他のソフトウェアインスタンスやデータベースが必要になることはないということを意味しています。
堅牢性の拡張性
AcropolisはNutanix 分散ストレージファブリックを利用していますので、ドライブやノードの障害時に、クラスタ内のすべてのノードが影響を受けたデータの構成されているresiliency factor(RF)の復旧に参加します。これはハイパーバイザーに関係なく実施されますが、AHVは完全に管理コンポーネントが分散されているため、クラスタが大きければ大きいほど管理レイヤーの堅牢性も向上します。
例えば、4ノードクラスタ内で1つのノードが失われたとすると、パフォーマンスと管理コンポーネントの25%が影響を受けることになります。32ノードクラスタであれば単一ノードの障害の影響はもっと小さくなり、3.125%だけになります。AHV環境が拡張していくにつれ、障害時の劣化や自己修復の能力が復旧時間面でも、その後の続発障害に対する許容度も高まります。
大規模クラスタに置ける堅牢性の向上について更に詳しくはこちら: EC-Xを利用して大規模クラスタに置ける堅牢性を改善する(和訳予定なし)
パフォーマンスの拡張性
ハイパーバイザーにかかわらず、XCPのクラスタが成長していけばパフォーマンスは改善されます。新しいノードがクラスタに追加されるやいなや、追加されたCVMは仮想マシンがノードで動作していない場合であっても管理とデータの堅牢性のタスクに参加する事になります。新しいノードが追加されると、ストレージファブリックはRFのトラフィックをより多くのコントローラーに分散することができるため、Write I/Oと堅牢性が向上し、更にレイテンシの低下にも役立ちます。
他にサポートしているハイパーバイザーに対して、AHVの持つ先進性は管理コンポーネントのパフォーマンス(その多くは既にお話してきました)が、クラスタとともに劇的に拡張されることです。分析機能と同様にAHVの管理コンポーネントもスケールアウトします。管理コンポーネントやその依存関係を新たに手動で追加しなくては管理が拡張できないという閾値は存在しません。
重要なことには、全てのコンポーネントについて、XCPはデータと管理の機能をクラスタ内の全てのノードに分散しているということです。Acropolisは｢ミラーされた｣コンポーネント/ハードウェア、そしてオブジェクトを利用しておらず、これによって、どれか一つのノードやコンポーネントやハードウェアがボトルネックになったり単一障害点にならないということを保証しています。
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
さて、第3段は拡張性です。拡張できますよ、ということではなく、上で述べられているとおりで、拡張に際して発生する面倒事は全て自動化されていますし、そもそもこれまでの従来型ストレージの拡張に関して発生していた問題もアーキテクチャ上おこらないようになっています。
単純にハイパーバイザーを比較するとAHVにつく星の数は少ないかもしれませんが、Nutanixにとってそもそも必要のない機能だったりということも多くあります。
AHV以外のハイパーバイザーではクラスタの拡張に応じて管理コンポーネントを手動でスケールアップする必要があるかもしれませんが、それすら無い･･･データが膨れ上がりより大規模なクラスタが必要になる今後のデータセンタ環境では、この全てのレイヤでのスケールアウトは非常に重要になってきます。
