![[Nutanix_Pukiwiki]](image/Nutanix_Logo.jpg "[Nutanix_Pukiwiki]"){kind=logo}
Learning?
Nutanixバイブルへようこそ!。 筆者は、日々Nutanix Platformを使用して働いています。即ち、私の商用化に向けたベンチマーク・ラボのためにそれを管理するのと同様、問題を見付け出し、それをその限界を極めています。 このページは、私自身とNutanixの様々なEnineer達により日々使用されている情報と細工を示す日々更新されている文書です。 この文書はまた、Advanced Nutanix seriesの一部として議論される項目の纏めも含んでいます。
注:この資料は正式の参考資料では無いため、ご自分のリスクでご利用下さい。 尚、この資料は適宜更新されます。
Nutanixのソリューションは、統合されたストレージ(storage)とコンピュート(compute)であり、ローカルな構成要素を利用して、ヴァーチャリゼーション(即ち, 仮想計算(Virtual Compute)プラットフォーム)のための分散プラットフォームを作り出す。 このソリューションは、ハードウェアとソフトウェアを纏めたアプライアンスとなっており、2Uのフットプリントの中に2ノード(6000/7000シリーズ)、もしくは4ノードを収容している。
各ノードは、業界標準のハイパーバイザー(現時点でESXi?, KVM?, Hyper-V?)とNutanix VM(CVM)を実行している。 Nutanix CVMは、Nutanixソフトウェアを実行し、hypervisorとホスト上で実行される全てのVMのためのI/Oオペレーションの全てを取り扱う。*1 VMware vSphereを実行しているNutanixユニットにとって、SSDとHDDデバイスを管理しているSCSIコントローラは、直接にVM-Direct Path(Intel VT-d)を利用しているCVM?へ直接渡される。Hyper-V?の場合、ストレージデバイスはCVMへ通過する。
以下は、典型的なノードを論理的な様子の例である。
<<Fig1-01>>
Nutanixノードのグループは、Nutanix Distributed Filesystem(NDFS)と呼ばれる分散プラットフォームを構成する。 NDFSは、hypervisorからは、集中化されたストレージ・アレイの様に見える。 然しながらI/Oの全ては最高性能を提供するためにローカルに処理されている。 分散システムをこれらのノードがどの様に構成しているのかと云うことのより詳細は、以下の見出される。
以下は、Nutanixノードがどの様にしてNDFSを構成しているのかの例を示している。
<<Fig1-02>>
Nutanixプラットフォームは、概念的には以下の様な要素より構成されている。
<<Fig.1-02-01>>
Nutanix Distribution Filesystemは、概念的には以下の様な構成要素で構築されている。
以下は、どの様に、これらがNDFSとhypervisorの間のマップしているかを示す。
<<Fig-01-03-01>>
注: 4.0のExtent Groupは現在、重複排除(dedupe)に依って1MB或いは4MBのどちらかである。
以下は、様々なファイルシステムの間でこれらの構造要素がどの様に関連しているかを示している。
<<Fig-01-03-02>>
以下は、様々なファイルシステムの間でこれらの構造要素が論理的にどの様に関連しているかを示しているもう一つの図式表現である。
<<Fig-01-03-03>>
Nutanix I/Oパスは、以下の構成要素より成る。
<<Fig.01-04-01>>
以下に、Content Cache?の概要を示す。
<<Fig-01-04-02>>
以下のビデオを併せご参照下さい。
Nutanix Platformは、現在、resiliency factor 即ち replicaton factor(RF)とchecksumを 用いて、node,diskの故障や機能低下が発生した場合にdataの冗長性と有効性を保障している。 上記に述べた通り、OpLogは、低遅延のSSD tierへの書込み発生を吸収するための処理の段階と なる。 hostへの書込みに成功した事を知らせるacknowledge(ack)が発行される前に、 ローカルなOpLogに書込まれる時に、dataは同期的にRFの値に依って他の１つ或いは２つのCVMのOpLogに 複製される。
この仕組により、少なくても２～３箇所の独立した異なった場所にデータが存在しているため、 障害に耐性があることを意味している。
注) RF3を実現するためにはmetadataはRF5となるため、最低5nodeが必要となる。Data RFは、 PRISM経由でコンフィグレーションが行われ、コンテナレベルで実現されている。
いかなる"ホットノード"も除外しスケールがリニアに実現されることを保障するために、全てのnodeが OpLogの複製に参加している。 dataが書込まれている間にchecksumが計算され、metadataの一部として 保存される。 そして、dataは、RFが暗黙のうちに維持されているextent storeは、非同期的に書出される。 node或いはdiskに障害が発生した場合、dataはRFを維持しているため、クラスター内の全nodeにわたって 再度複製が作られる。 dataが読取られる時は常に、dataが正しいものであることを保障するために checksumが計算される。 checksumとdataが、一致しない様な事態が発生した場合、複製からdataが 読み出され正しくない複製を置換える。
以下の図は、この仕組が論理的にどの様な見え方をするのかを表している。
<<Fig.2-01-01>>
computeとstorageが統合されたplatformとして、I/Oとdataの局所性は、NutanixのclusterとVM performanceにとってkeyである。 先にI/Oパスのセクションで説明した通り、全てのread/write I/Oは、通常のVMの近隣にある各hypervisor上にあるローカルなCVM(Controller VM)により処理される。 VMのデータは、CVMからローカルにサービスを提供され、CVMの制御下にあるローカルディスク上に保存される。 VMが1つのhypervisorから他のhypervisorへ移動する時(或いはHAが発生している間に)、新たに移動したVMのデータは今度は新たにローカルになったCVMによりサービスが提供される。
(マイグレーションの発生によりリモートnode/CVM上に保存されている)古いdataに対するreadが発生した時、I/Oは、ローカルCVMにより リモートCVMに転送される。 全てのwrite I/Oは、直ちにローカルに実行される。NDFSは、自分以外の異なったnodeから 発生したI/Oを検出し、全てのread I/Oがそれ以降ローカル ノードで実行される様にデータをバックグラウンドで移動する。 必要以上にネットワークを溢れさせることが無い様に、データの移動はreadが発生した場合にのみ行われる。
VMが、hypernvisor 間を移動した場合に、どの様にデータがVMの移動に追従するのかを以下に説明します。
<<Fig.2-02-01>>
メタデータは、インテリジェント・システムのコアにあり、あらゆるファイルシステムやストレージアレイに とってはよりクリティカルである。 NDFSでの使用形態に於いて、それが成功するために非常に重要な幾つかの構成要素がある。 それは、全ての時間に於いて正しいもので無ければならず(厳密に矛盾があってはならない)、スケーラブルで無ければならず、そして膨大な規模で動作しなければならない。 先のアーキテクチャに関するセクションで説明した通り、NDFSは、本質的なメタデータとその他のプラットフォームに関するデータ(統計情報等)を保存するキーバリュー ストアとして"リング・ライク"なトポロジー構造を採用している。
メタデータの有効性と冗長性を保証するために、奇数個(3,5等)のnodeの上でRFが使用されている。 メタデータの書込み或いは変更が発生すると、列(row)がリング内のnodeに書込まれ、クラスターの大きさに依存してえn個の同僚nodeに複製が作られる。 PAXOSアルゴリズムを用いて何らかのコミットメントが強制的に為される前にnodeの多数決による合意が形成される。 これにより、Platformの一部として保存される全てのデータとメタデータのための厳密な無矛盾性が保証される。
以下に、メタデータの挿入・更新が4node clusterに対して発生した場合を示す。
<<Fig.2-03-01>>
大規模な構成での性能もNDFSメタデータにとってはもう一つの重要な構成要素である。 伝統的な デュアルコントローラ或いはマスターモデルと異なり、それぞれのNutanix nodeは全体としてのplatformのメタデータの部分集合を担っている。 この方法は、クラスター内の全nodeによってメタデータが処理され、処理操作されることを許すことにより、伝統的な方法により生じるボトルネックを排除することができる。 一貫したハッシュの仕組が、nodeのAdd/Removeによりクラスターの規模が変化した時に、キーの再配送を最小化するために、矛盾の無いハッシュの仕組が採用されている。 クラスターの規模が大きくなる様に変化する時(4nodeから8nodeへの拡大等)、ブロックを意識した動作と信頼性実現のため、新たに設置されるnodeはリングを通じて既存のnode間に挿入される。
以下に、metadata"リング"の例と、どの様にそれが拡張されるのかと云う例を示す。
<<Fig.2-03-02>>
Nutanix分散ファイルは、"マルチread"シナリオの中で特定のvDisk或いはVMデータを分散キャッシュする事を許す"Shadow Clone"と呼ばれる機能を持つ。 この機能の重要な例として、VDIを展開する場合がある。多くの"linked clone"が、read要求を"central master"或いは "Base VM"に対し転送する。 VMware Viewの場合は、これをレプリカ・ディスクと呼ばれ、全ての"linked clone"により読み取られる。 XenDesktop?に於いては、これはMCS或いはMaster VMと呼ばれる。 これは、またマルチー・リーダー シナリオとなる、(Deployment serverやリポジトリー等の)如何なる状況に於いても同様の動作となる。
データI/Oの局所性を保つことは、可能な限りVM性能を高めるために非常に重要であり、NDFSの重要な構成要素である。 NFDSは、Shadow Cloneを用いてvDiskへのアクセスの傾向をモニターし、それがデータの局所性を実現するために行っている動作に似ているかどうかを判断する。 (ローカルにあるCVMに加えて)二つ以上のCVMから要求が発生している場合、その全てのリクエストがread I/O である場合、vDiskは不変なものとしてマークされる。 一度、diskが不変であるとマークされるとvDiskは、readリクエストを発生させている各CVMにより(即ち、ベースDiskのShadow cloneとして)ローカルにキャッシュされる。
DVIの場合レプリカ・ディスクは、各nodeによってキャッシュされ、ベースVMに対する全readリクエストは、ローカルに処理される。 (注) データは、ネットワークを溢れさせないでキャッシュを効率的に使用するためにread発生時にのみ移動が発生する。 ベースVMに変更が発生した場合、Shadow Cloneは廃棄され、プロセスは最初からやり直しとなる。 (NOS 3.5に於いて)Shadow Cloneは、デフォルトでは不使用に設定されているが、以下のNCLIコマンドにより使用/不使用を 設定することができる。
ncli cluster edit-params enable-shadow-clones=true
以下に、Shadow Cloneがどの様に動作しているのか、そして分散キャッシュを実現しているのかを示す。
<<Fig.2-04-01>>
エラスティック・デデュープ エンジン(Elastic Dedupe Engine)は、ソフトウェアで実現されているNDFSの機能であり、キャパシティ・ティア(HDD)と パーフォーマンス・ティア(SSD)に於けるデータの重複排除を実現している。 データのシーケンシャルな流れに対して、入力時に16Kを単位としてSHA-1ハッシュを用いてフィンガープリント(指紋情報)が作成される。 このフィンガープリント作成処理は、データの入力時にのみ実施され、書込まれるブロックのメタデータの一部として永続的に記録される。 (注:) Nutanix社の初期製品に於いては、4Kを単位としてフィンガープリント作成処理が行われていたが、テストの結果、メタデータのオーバーヘッドの現象と重複削除に最も良い組み合わせは16Kであることが判明した。 重複排除のデータがキャッシュに読込まれる時には, 4Kを単位として行われる。
データの再読込みが必要となる、バックグラウンド・スキャンを用いた伝統的なアプローチとは反対に、 Nutanix社は、入力時にインラインでフィンガープリント作成処理を行う。 キャパシティ・ティアに於いて重複排除される可能性のある重複データために、再スキャンや再読込みを施す必要無く、本質的に重複しているデータが削除することができる。
エラスティック・デデュープ・エンジン(Elastic Dedupe Engine)が拡張性を実現し、ローカルVMのI/Oリクエストを扱うのかを以下に示す。
<<Fig.2-05-01>>
フィンガープリント生成処理は、64K以上のI/Oサイズを持ったデータの入力時に実行される。 Intel Accelerationを利用してSHA-1計算が行われるため、CPUの使用率を非常に低く抑えることが出来る。 I/Oサイズが小さい為に入力時にフィンガープリント作成処理が行われなかった場合、バックグラウンドでフィンガープリント作成処理が実行される。エラスティック・デデュープ・エンジンは、キャパシティ・ティア(HDD)とパーフォーマンス・ティア(SSD)の両階層に跨って存在している。 データの重複が判定された時、同じフィンガープリントを持った複数のコピーを踏まえて、バックグラウンド・プロセスがNDFS MapReduce?フレームワーク(キュレータ:Curator)を用いて重複したデータを削除する。
読込み中のデータにとって、マルチ・ティア/プールキャッシュであるNDFSコンテンツ・キャッシュに引き出される。同じフィンガープリントを持ったデータに対する、それに続く全リクエストは、キャッシュから直接読み出される。 I/O Path OverviewのContent Cacheサブセクションにcontent CacheとPool Structureに関してより詳しく説明されている。
Elastic Dedupe EngineとNDFS I/O Pathが、どの様に相互連携しているのかの例を以下に示す。
<<Fig.2-05-02>>
Nutanixプラットフォームは、node通信のためにバックプレーンを使用しておらず、標準規格の10GEネットワークに前面的に信頼を置いている。 Nutanix node上で稼動しているVMに対する全てのストレージI/Oは、専用のプライベート・ネットワーク上のハイパーバイザーにより処理される。 I/Oリクエストは、ハイパーバイザーによりローカルCVM上のプライベートIPに転送される。 CVMは、外部IPを利用し共有されている10GEネットワーク上の外部IPを使用し、他のNutanix nodeに対しリモート複製の処理を実行する。 多くの場合、全てのreadリクエストは完全にローカルに処理され、10GEネットワークが関与することは無い。 このことにより、共有された10GEネットワークが関与するトラフィックは、NDFSによるリモート複製を実行する場合と、VMネットワークI/Oだけとなっている。 この様な状況は、CVMがダウンするか、データがリモートnodeに有る場合にそのCVMがクラスター内の他のCVMにリクエストを転送する場合に該当する。 また、ディスク・バランシングの様なクラスターに広がり得るタスクは、一時的に10GEネットワーク上のI/Oを発生させる。
VMのI/O Pathがプライベート・ネットワークとパブリック10GEネットワークとどの様に連携動作をするかの例を以下に表している。
<<Fig.2-06-01>>
信頼性と回復力(復元力)は、最大では無いとしても、NDFSの重要な部分である。分散システムとして、NDFSは、部品、サービス、CVMの故障を扱うように構築されている。 このセクションに於いて、CVMの故障が、どの様に扱われるのかに関して説明する。 (本書の将来の改訂版で、部品の故障をどの様に扱うのかを説明する予定である。) CVMの「故障」には、ユーザによるCVMのパワーダウンも含まれるし、CVMのアップグレード実施やCVMダウンによりもたらされる可能性の有るその他の事項も含む。
NDFSには、ローカルCVMが利用不可能となった場合に、クラスター内の他のCVMによってI/Oをトランスペアレントに扱うことができる様にしているauto pathingと呼ばれる機能がある。 hypervisorとCVMは、専用のvSwitch上のプライベートネットワーク192.168.5.0 を用いて通信を行う。 このことは、全てのストレージI/Oは、CVM(192.168.5.2)上のIPアドレスに向けて発生していることを意味している。 CVMの外部IPアドレスは、リモート複製とCVM間通信のために使用される。
<<Fig.2-07-01>>
ローカルなCVMに障害が発生すると、ローカルCVMにより利用されていた192.168.5.2 は利用できなくなる。 NDFSは、自動的に障害を検出し、これらのI/Oを10GEを通じてクラスター内の他のCVMへ転送する。この経路変更は、ホスト上で稼動しているhypervisorとVMに対して透過的に実行される。 このことにより、CVMがパワーダウンしてもVMは引続きNDFSに対するI/Oを処理し続けるころができる。 また、NDFSは自己回復を試みるが、これは、CVMがパワーダウンしたことを検出し自動的にローカルCVMをリブートするかパワーオンすることに依って実現される。 一度、ローカルCVMが回復し、利用可能となるとトラフィックは連続に復帰され、ローカルCVMにより処理される様になる。
以下に、障害発生したCVMの様子を図に示す。
<<Fig.2-07-02>>
NDFSは、色々なワークロードに反応できる非常にダイナミックなプラットフォームであると共に 様々な異なったタイプのノードの共存も可能である。 計算重視型ノード(Compute Heavey:3050等)とストレージ重視ノード(Storage Heavey:60x0 等)を同じクラスターに混在させることができる。 データの均一な分布を保障することはより大容量のストレージを伴ったノードを混在させる時に重要な 項目である。
注) 実際に同一クラスター内に混在できるノードのタイプに関してはお問合せ下さい。
NDFSは、クラスターを通じてデータの均一な分布を保障するために使用されるdisk balancingと 呼ばれる機能が最初から用意されている。 Disk Ballancingは、ノードのローカルストレージの容量の使用率に基づいて動作し、NDFS IMLに統合されている。 そのゴールは、使用率が一度あるスレショルドを超えるとノード間の使用率を均一に保つことである。
以下に、3050と6050による混在クラスターに於いてバランスしていない状態を図示する。
<<Fig.2-08-01>>
Disk balancingは、NDFS Curatorのフレームワークを活用しており、スレショルドを超えたと同時にプロセスがスケジュールされる。 データがバランスしていない場合、Curatorは、どのdataが移動されるべきかを判断しクラスター内の各ノードにタスクを分散処理させる。 ノードのタイプが同質である場合(即ち 全てが3050等),使用率は公平に均等になるべきである。
しかしながら、ノード上のあるVMが、他のノードに比べて大量にデータを書込むとノード当りのストレージの使用率に偏りをもたらし得る。 この場合、Disk Balancingが実行され、ノード上で最も使用されていない(Coldes)データをクラスター内の他のノードへ移動する。 同質でないノードのタイプが混在してしる場合 (即ち、3050と6050/50/70等が混在している場合)、或いはノードがストレージ専用で使用されている様な場合(CVM以外のVMあ全く稼動していない様な場合)、データを移動するためのリクエストが発生することがある。
以下は、ディスクの使用率がバランスしている状態になった混成クラスターの例を図示している。
<<Fig.2-08-02>>
あるシナリオに基づいて、ユーザーは特定のノードをCVMだけが主な目的として使用したり、大容量ストレージとして動作するストレージ専用("Storage Only")状態で使用する場合がある。 この場合、ノード上の全メモリーがより大量のread cacheを提供するためにCVMに追加される。
disk balancingによりアクティブなVMノードからのデータを移動させている混成クラスターに於いて ストレージ専用ノードがどの様に見えるかを以下に図示する。
<<Fig.2-08-03>>
今までに説明した通り、Nutanixのplatformはソフトウェアに基づいたソリューションであるが、 ソフトウェア+ハードウェアを統合したアプライアンスとして出荷されている。 コントローラーVM(CVM)は、Nutanixソフトウェアとロジックの大部分が存在しており、最初から 拡張性を有しており、プラグイン可能なアーキテクチャとなっている。
ソフトウェア・デファインドであり、ハードウェアによるオフロード機能に依存していない事の 最大の利点は、拡張性にある。 全ての製品のライフサイクルに伴って、導入されるべき向上と 新しい機能がある。 如何なる専用ASIC/FPGAやハードウェアの機能にも依存しないことにより、 Nutanixはこれらの新しい機能を、ソフトウェアの単純な更新を通じて開発・展開できる。 このことは、例えば重複排除機能(deduplication)の様な新しい機能の展開は、Nutanixソフトウェアの現在のバージョンを更新するだけで良い。 これはまた、より新しい世代の機能をレガシー・ハードウェアモデル上に展開できることでもある。
例として、以前の世代のプラットフォーム(即ちNX-2400)上で、Nutanixソフトウェアの古いバージョンの上でワークロードを実行しているとしよう。実行中のソフトウェアのバージョンは、ユーザーのワークロードが利益を得ることができるはずの重複排除機能が提供されていないものとする。 この機能を得るために、ユーザーはワークロードの実行中にNutanixソフトウェアのアップグレードを行い、重複排除機能(dedupe)を獲得することができる。この操作は非常に簡単である。
機能に似て、新しい"adaptor"や、インターフェースをNDFSに生成することができることは主要な機能の一つである。 製品が、最初に出荷された時、それは単に、ハイパー・バイザーからのI/Oに対して iSCSIをサポートしていただけであったが、今ではNFSとSMBを含むまでに成長している。 将来は様々なワークロードとハイパーバイザのために(例えばHDFS等の)当たらしいアダプターを作り出すことも可能である。 ここで再度、ソフトウェア更新によって全ての機能を展開できることを繰り返しておく。
このことは、最新で重要な機能を得る為にハードウェアの更新とソフトウェアの購入が必要となる大部分の通常のレガシー・インフラストラクチャと全く異なっている点である。 これとは異なり、Nutanixでは全ての機能は任意のハードウェア・プラットフォームと任意のハイパーバイザー上で、実行可能なソフトウェアとして展開され、簡単なソフトウェア更新により利用できる様になる。
ソフトウェア・デファインド・フレームワーク(Software Defined Framework)が、どの様に見えるのかと云う論理的な表現を以下に示す。
<<Fig.2-09-01>>
<<TO BE TRANSLATED IN THE FUTURE.>>
<<TO BE TRANSLATED IN THE FUTURE.>>
<<TO BE TRANSLATED IN THE FUTURE.>>
<<TO BE TRANSLATED IN THE FUTURE.>>
Learning?
video