Nutanixバイブル/NutanixBible_2-05J のバックアップ(No.1)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
Nutanixバイブル/NutanixBible_2-05J へ行く。
- 1 (2014-09-08 (月) 13:49:09)
- 2 (2014-09-08 (月) 14:01:59)

(2-04) Shadow Clone(影武者複製) 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がどの様に動作しているのか、そして分散キャッシュを実現しているのかを示す。

(2-05) Elastic Dedupe Engine

エラスティック・デデュープエンジン(Elastic Dedupe Engine)は、ソフトウェアで実現されているNDFSの機能であり、キャパシティ・ティア(HDD)とパーフォーマンス・ティア(SSD)に於けるデータの重複排除を実現している。データのシーケンシャルな流れに対して、入力時に16Kを単位としてSHA-1ハッシュを用いてフィンガープリント(指紋情報)が作成される。このフィンガープリント作成処理は、データの入力時にのみ実施され、書込まれるブロックのメタデータの一部として永続的に記録される。 (注:) Nutanix社の初期製品に於いては、4Kを単位としてフィンガープリント作成処理が行われていたが、テストの結果、メタデータのオーバーヘッドの現象と重複削除に最も良い組み合わせは16Kであることが判明した。重複排除のデータがキャッシュに読込まれる時には, 4Kを単位として行われる。

データの再読込みが必要となる、バックグラウンド・スキャンを用いた伝統的なアプローチとは反対に、 Nutanix社は、入力時にインラインでフィンガープリント作成処理を行う。キャパシティ・ティアに於いて重複排除される可能性のある重複データために、再スキャンや再読込みを施す必要無く、本質的に重複しているデータが削除することができる。

エラスティック・デデュープ・エンジン(Elastic Dedupe Engine)が拡張性を実現し、ローカルVMのI/Oリクエストを扱うのかを以下に示す。

図版挿入>>

フィンガープリント生成処理は、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が、どの様に相互連携しているのかの例を以下に示す。

図版挿入>>

(2-06) Networking and I/O 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ネットワークとどの様に連携動作をするかの例を以下に表している。

図版挿入>>

(2-07) CVM Auto-pathing

信頼性と回復力(復元力)は、最大では無いとしても、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間通信のために使用される。

ローカルなCVMに障害が発生すると、ローカルCVMにより利用されていた192.168.5.2 は利用できなくなる。 NDFSは、自動的に障害を検出し、これらのI/Oを10GEを通じてクラスター内の他のCVMへ転送する。この経路変更は、ホスト上で稼動しているhypervisorとVMに対して透過的に実行される。このことにより、CVMがパワーダウンしてもVMは引続きNDFSに対するI/Oを処理し続けるころができる。また、NDFSは自己回復を試みるが、これは、CVMがパワーダウンしたことを検出し自動的にローカルCVMをリブートするかパワーオンすることに依って実現される。一度、ローカルCVMが回復し、利用可能となるとトラフィックは連続に復帰され、ローカルCVMにより処理される様になる。

以下に、障害発生したCVMの様子を図に示す。

(8) Disk Balancing NDFSは、色々なワークロードに反応できる非常にダイナミックなプラットフォームであると共に様々な異なったタイプのノードの共存も可能である。計算重視型ノード(Compute Heavey:3050等)とストレージ重視ノード(Storage Heavey:60x0 等)を同じクラスターに混在させることができる。データの均一な分布を保障することはより大容量のストレージを伴ったノードを混在させる時に重要な項目である。

注) 実際に同一クラスター内に混在できるノードのタイプに関してはお問合せ下さい。

NDFSは、クラスターを通じてデータの均一な分布を保障するために使用されるdisk balancingと呼ばれる機能が最初から用意されている。 Disk Ballancingは、ノードのローカルストレージの容量の使用率に基づいて動作し、NDFS IMLに統合されている。そのゴールは、使用率が一度あるスレショルドを超えるとノード間の使用率を均一に保つことである。

以下に、3050と6050による混在クラスターに於いてバランスしていない状態を図示する。

図版挿入>>

Disk balancingは、NDFS Curatorのフレームワークを活用しており、スレショルドを超えたと同時にプロセスがスケジュールされる。データがバランスしていない場合、Curatorは、どのdataが移動されるべきかを判断しクラスター内の各ノードにタスクを分散処理させる。ノードのタイプが同質である場合(即ち全てが3050等), 使用率は公平に均等になるべきである。

しかしながら、ノード上のあるVMが、他のノードに比べて大量にデータを書込むとノード当りのストレージの使用率に偏りをもたらし得る。この場合、Disk Balancingが実行され、ノード上で最も使用されていない (Coldes)データをクラスター内の他のノードへ移動する。同質でないノードのタイプが混在してしる場合 (即ち、3050と6050/50/70等が混在している場合)、或いはノードがストレージ専用で使用されている様な場合 (CVM以外のVMあ全く稼動していない様な場合)、データを移動するためのリクエストが発生することがある。

以下は、ディスクの使用率がバランスしている状態になった混成クラスターの例を図示している。

あるシナリオに基づいて、ユーザーは特定のノードをCVMだけが主な目的として使用したり、大容量ストレージとして動作するストレージ専用("Storage Only")状態で使用する場合がある。この場合、ノード上の全メモリーがより大量のread cacheを提供するためにCVMに追加される。

以下に、disk balancingによりアクティブなVMノードからのデータを移動させている混成クラスターに於いてストレージ専用ノードがどの様に見えるかを図示している。

(2-09) ソフトウェア・デファインド・コントローラー・アーキテクチャ(SDCA) 今までに説明した通り、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)が、どの様に見えるのかと云う論理的な表現を以下に示す。

Nutanixバイブル