![[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>>
Disk Balancingのセクションで述べた通り、ストレージ容量がNutanixクラスター内の全nodeに 亘ってプールされるのかと云うことと、ILM(Information Lifecycle Management)がデータをローカルにキープするために使用されることを述べた。 同様の概念がクラスターのSSDとHDD層がクラスターワイドになっているディスクの階層化にも適用されており,NFS ILMはデータの移動発生イベントのトリガー発生を担当している。
クラスター内の全てのSSDは、そのクラスターの全てのノードから利用可能であるけれど、ローカルnode上のSSDが、node上で稼働中のVMによって発生する全てのI/Oに対して常に最高プライオリティで使用される階層となる。 SSDティアは、常に最高のパーフォーマンスを提供しており、ハイブリッド・アレイが管理するために最も重要な存在である。 階層間のプライオリティ付けは、概ね以下の様に分類される。
<<Fig.2-10-01>>
リソース(SSD,HDD等)の特定のタイプの物は一緒にプールされ、クラスター全体としてストレージの階層化を実現している。 このことにより、クラスター内の任意のnodeが、ローカルにあるか否かに関係なく、全ての階層のストレージを活用できる。
このプールの階層化がどの様に概観されるかを以下に示している。
<<Fig.2-10-02>>
一般的に、ローカルノードのSSDがいっぱいになった時にどの様な事が発生するのかと質問されることがあるが、ディスク・バランシングのセクションで述べた通り、ディスク・ティア内部のデバイスの使用率を均一に保とうとする事が主要な方針である。 ローカルノードのSSD使用率が高くなった場合、ディスク・バランシングはローカルディスク上で最も使用されていない(Coldest:コールディスト)なデータをクラスタ全体に亘ってでデータを移動し始める。 これにより、ローカルSSDのフリースペースが広がり、ローカルノードがネットワークを跨らないでSSDに対して書込みを行うことが出来る様になる。 重要な点は、このリモートI/Oのために全CVMとSSDが使用され、発生し得るいかなるボトルネックも排除し、ネットワークを跨って処理されるI/Oによってもたらされる影響を有る程度解消する。 また別の状況として、全体的な使用率があるスレショルドを越える時がある。
<<Fig.2-10-03>>
[curator_tier_usage_ilm_threshold_percent(Default+75)] に達するとNDFS ILMが起動され、Curatorジョブの一部としてSSDティア(層)からHDD層へデータを書出す。 この処理により使用率は、上記に述べたスレショルド以内か、或いは[curator_tier_free_up_percent_by_ilm(Default=15)]の何れか値の大きい方まで空きエリアを広げることができる。
書出しのためのdataとしては、アクセス時刻が最も古いものが選択される。 SSDティアの使用率が95%である場合、SSDティア内のデータの20%は、HDDティアへ移動される。 (SSD使用率は95% -> 75%となる) しかしながら、もし使用率が80%だった場合には、最小のティア解放量を用いてデータの15%だけがHDDティアへ移動される。
<<Fig.2-10-04>>
NDFS ILMは、I/Oの振舞いを常に監視しており、必要に応じてティア間での書込み/読出しを行い ティア(層)に関係無く最も最近使われた(hot)なdataを引出せる様になっている。
Nutanixプラットフォームは、VM/Guest OSから物理的Disk Deviceに至る全ての 経路が通過する複数のLayerに於いてストレージをモニターしている。 様々なティアと、それらがどの様に関連しているのかを知ることはソリューションをモニター する時には常に重要であり、ユーザがどの様に操作が関連しているのかを完全に視覚化する ことができる。
操作がモニターされる様々なレイヤーと、以降で説明される相対的な塊を示している。
<<Fig.2-11-01>>
全てのダイナミック、或いはソフトウェア デファインド環境に於いて中心的な存在であるために、Nutanixは、膨大な数の一連のインターフェースを提供し、簡単なプログラマビリティとインターフェイシングを 可能としている。 主なインターフェースとして以下の様な物がある。
- REST
- nCLI
- scripting inteface (この項目に関しては、将来記述される予定)
これに対する中核は、REST APIであり、これはPRISM UIの全てのデータポイントと機能を表している。
<<Fig.2-12-01>>
<<Fig.2-12-01>>
注) block認識機能(awareness)を有効にするためには、最低3台のblockが必要となる。そうでない場合は、node認識運用(awareness)がデフォルトとして使用されている。 "block認識(awareness)"を確実に有効にするためには、各blockの構成を均一にして置く事が推奨される。 共通のシナリオと使用される認識(awareness)のレベルは、この節の終わりに示されている。 3blockと云う要求は最低充足数に依るものである。
認識(awareness)機能は、以下の最重要な領域に分割される。
<<Fig.2-13-01>>
block故障が発生した場合でも、block認識(awareness)は維持されており、cluster内の他のblockに再度レプリカが作成される。
先にスケーラブルmetadataの節で説明した通り、Nutanixは、Cassandraを強化改造したプラットフォームを活用しmetadataと他の本質的な情報を保存している。 Cassandraは、リング状のトポロジー構造を利用しデータの無矛盾性と利用可能性を確保するためにリング内のn個の同僚(node)にレプリカを作成する。
12nodeよりclusterを構成するCassandraリングの例を以下に示す
<<Fig.2-13-02>>
Cassandraの同僚間でのレプリカ作成はリング上のnodeに対してで時計方向に繰り返される。block認識(awareness)機能を用いて、二つのレプリカを作成する同僚nodeは、それらが同じblock上で選択されることが無い様に選択される。
上記のリングをblockに基づいたレイアウトに置き直したnodeのレイアウトを以下に示す。
<<Fig.2-13-03>>
このblock認識(aware)機能の本質として,blockに故障が発生した場合に最低でも2つのデータのコピーが存在している。 (Metadata RF3。より大きなClusterではRF5を使用しても良い)
リングを構成する全てのnodeの複製トポロジーの例を以下に示す。 (少々見辛いですが)
<<Fig.2-13-04>>
<<Fig.2-13-05>>
<<Fig.2-13-06>>
<<Fig.2-13-07>>
NDFSは、VAAI,ODX,ncli,REST,PRISM等を通じて、負荷の掛からないスナップショット作成とクローン作成をネイティブにサポートしている。スナップショットとクローンの両方は、最も有効で効率的である redirect-on-write アルゴリズムを利用している。
Data Structureのセクションで説明した通り、仮想マシンは、Nutanix platform上のvDiskである ファイル(vmdk/vhdk)より構成されている。vDiskは、論理的に連続なデータの塊(chunk)であるextentsにより構成されており、これはストレージデバイス上のファイルとして物理的に連続なデータであるextent groupの中に保存されている。
スナップショット或いはクローンが作成される時、ベースとなるvDiskは変更不可(immutable)なものとしてマークされ、もう一方のvDiskがread/write可能なものとして作成される。 この時点で、両方のvDiskは同じblock map、即ち該当しているextentsへのvDiskのmetadataマッピングを持っている。読込み遅延を発生し得るスナップショット チェーンを辿る必要の有る伝統的なアプローチと異なり、各vDiskはそれ自身のblock mapを持っている。これにより、スナップショット チェーンが非常に深い場合に通常認められるオーバーヘッドを排除することができ、ユーザーが如何なるパーフォーマンス上の影響を受ける事無く連続にスナップショットを作成することが可能となる。
スナップショットが作成される場合に、それがどの様に動作しているかを以下に示す。
(注:最も明確な図を提供していると思われるのでNTAPに有る程度の信頼を置いている)
<<Fig.2-14-01>>
スナップショットやクローンが以前に作成されたvDiskに対し、更にスナップショットやクローンが作成される場合、同じ方法が使用される。
<<Fig.2-14-02>>
VMやvDiskのスナップショット或いはクローンが作成される場合に同じ方法が使用される。VM或いはvDiskのクローンが作成される場合、現在のblock mapはロックされてからクローンが作成される。 これらで更新されるのはmetadataだけであるため実質上I/Oは全く発生しない。
同じ方法は、クローンのクローンを作成する場合にも使用されている。 実質以前にcloneが作成されたVMが"base vDisk"として振舞い、クローン作成の間 block mapはロックされ、2つの"クローン"が作成される。 一つはクローンが作られている元のVMに対するものであり、もう一つは新たなクローンに対するものである。 それらはどちらも、以前のblock mapを継承し、新たに発生するwrite/updateはそれらの個々のblock map上に実行される。
<<Fig.2-14-03>>
以前に述べた通り、各VM/vDiskはそれ自身のblock mapを持っている。 そのため、先の例の通り、ベースVMから作成された全てのクローンは、今では自らのblock mapを持ち、如何なるwrite/updateはそれに対して発生する。 その振舞いがどの様に見えるのかを以下に示す。
<<Fig.2-14-04>>
その後に発生するVM/vDiskのクローン作成やスナップショット作成は、元々のblock mapにロックを発生させ、R/Wアクセスのために新しいblock mapを作成する。
Nutanix製品には、(2-14)スナップショットとクローンのセクションで説明したのと同様の機能の上に作られたDRと、Replication機能が最初から提供されている。 Cerebro(脳の意)は、NDFSに於いて DRとRepliccationを管理する部品である。 Cerebroは、各node上で動作し,Cerebro masterが 選出され(NFS masterと同様の方法による),replicationタスクを担当する。Cerebroマスターとして動作しているCVMに障害が発生した場合、他のCVMが選択されその役割を務めることになる。 Cerebroページは、<CVM IP>:2020 により表示することができる。
DR機能には、以下の主要な領域がある。
o Replication Topology
o Implementation Cconstructs
o Global Duplication
伝統的には、幾つかの主要なreplication topologyが存在している。
site-to-site, hub-and-spoke, Full/Partial-mesh である。 site-to-site或いはhub-and-spokeの何れかのみが可能である伝統的なソリューションとは異なり、Nutanixではfully-mesh,或いは柔軟なmany-to-manyを提供している。
<<Fig.2--15-01>>
本質的に、管理者が必要に応じたreplication機能を決定することが可能である。
Nutanix DRの内部は以下に説明される幾つかの主要要素により構成されている。
(a) Remote Site
o 主な役割: Nutanix Cluster
o 記述: remote Nutanix clusterは、バックアップやDRのターゲットとして利用される。
o ヒント: ターゲットサイトには、全サイト障害を扱うために強化された容(compute/storage)を持つことが確保されなければならない。 単一サイト内のラック間のreplication/DRを実施することも有意義である場合もある。
(b) Protection Domain(PD)
o 主な役割:保護すべきVM もしくはFileのマクロなグループ
o 記述: 望ましいスケジュールで一緒にリプリケートされるべきVM もしくはFileのグループである。 PDは、全container、或いは個々のVM もしくは Fileを選択しても良い。
o ヒント: RPO/RTO(Recovery Point Object Objectivie/Recovery Time Objective)により運用される様々なサービス層(service tier)のための複数のPDを作成することが出来る。ファイルの配布のために(即ち、golden image,ISO file等)、replicationされるファイルを含んだPDを作成することも出来る。
(c) Consistency Group(CG)
o 主な役割:クラッシュ発生時でも一貫性を維持するためのVMやfileの部分集合(subset)。
o 記述: VMもしくはFileは、Protection Domainの一部分でありクラッシュ発生時でも一貫性を維持出来る様なスナップショットが作成されている必要がある。 これはVM,Fileがリカバーされる時に一貫性の有る状態で立上ることを確保しなければならない。 一つのプロテクション ドメインの中に、複数のコンシステンシー グループを持つことができる。
o ヒント: コンシイステンシー グループ内のグループに依存するアプリケーションやサービスVMは、一貫性を保った状態で(即ち、App and DB)回復されることを保障しなければならない。
(d) Replication Schedule
o 主な役割:snapshotとreplicationスケジュール
o 記述: 特定のPDとCG内のVMに対するsnapshotとreplicatonスケジュール
o ヒント: snapshot scheduleは、ユーザーが望むRPOと同じであるべきである。
(e) Retention Policy
o 主な役割:保持すべきローカルとリモートのsnapshotの数
o 記述: リテンションポリシーは、保持すべきローカルとリモートのsnapshotの数を定義する。
注: リモート サイトは、リモートretention/replicatonポリシーのためにコンフィグレーションされなければならない。
o ヒント: retentionポリシーは、VM/file毎に必要となる回復点(restore point)の数と同じであるべきである。
単一サイトでのPD,CGとVM/Fileの論理的な表現を以下に示す。
<<Fig.2-15-02>>
簡単化のために全containerが保護され得ることに言及することは重要であるが、プラットフォームは 単一のVMやFileのレベルでの粒度で保護する機能を提供している。
セクション(2-05)Elastic Dedup Engineの説明で触れた様に、NDFSにはmeta data pointerを更新するだけでdeduplication(重複排除)を行う機能がある。
同じ考え方がDRとreplication機能にも使用されている。 通信路上にデータを送信する前に、NDFSはリモートサイトに検索(query)を掛け,fingerprint(指紋)が既に存在しているかどうか(即ち、データが既に存在しているかどうか)を確認する。 もし既に存在しているのであれば、データが書込まれることは無く、メタデータの更新だけが発生する。
ターゲット上に存在していないデータに対しては、データは圧縮され(compress)ターゲットサイトに送信される。この時点でデータは両方のサイト上に存在しておりdeduplicationのために使用可能である。
複数のプロテクション・ドメイン(PD)を含んだ3サイトの例を以下に示す。
<<Fig.2-15-03>>
<<replicationに関するセクションは将来追加の予定。>>
<<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