Learning?
Nutanix バイブル: †
[1].Intro. †
Nutanixバイブルへようこそ!。 筆者は、日々Nutanix Platformを使用して働いています。即ち、私の商用化に向けたベンチマーク・ラボのためにそれを管理するのと同様、問題を見付け出し、それをその限界を極めています。 このページは、私自身とNutanixの様々なEnineer達により日々使用されている情報と細工を示す日々更新されている文書です。 この文書はまた、Advanced Nutanix seriesの一部として議論される項目の纏めも含んでいます。
注:この資料は正式の参考資料では無いため、ご自分のリスクでご利用下さい。
[2].Book of Nutanix. †
(1).Architecture. †
- (1-01).Converged Platform.
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>>
- (1-02).Cluster Components.
Nutanixプラットフォームは、概念的には以下の様な要素より構成されている。
<<Fig.1-02-01>>
- (1-02-02). ズーキーパー(Zookeeper)., 「飼育係」
- 主な役割:クラスターのコンフィグレーション マネージャー。
- 説明: host,IP,状態(state)等を含んだクラスターのコンフィグレーションの全ては、Apache Zookeeper?に基づいてZeusが保存している。このサービスはクラスター内の3ノード上で実行され、その中の一つがリーダーとして選出される。 リーダーは、全てのリクエストを受信し、相棒(peers)に転送する。 リーダーが応答することに失敗すると、新しいリーダーが自動的に選出される。 Zookeeperは、Zeusを経由してアクセスされる。
- (1-02-03). スターゲート(Stargate).
- 主な役割:データI/Oマネージャー
- 説明:ストレージは、データ管理とI/Oオペレーションの全てを担当しており、hypervisor(NFS?,iSCSI?,又はSMBを経由して)からの主なインターフェースである。 このサービスは、ローカル化されたI/Oを処理するためにクラスター内の各ノード上で実行される。
- (1-02-05). プリズム(Prism).
- 主な役割:UIとAPI.
- 説明:Prismは、Nutanisクラスターを構成、監視するための構成要素と管理者のためのマネジメント・ゲートウェイである。 これは、ncli,HTML5? UIとREST APIを含んでいる。 Prismは、クラスター内の各ノード上で実行されており、クラスター内の他の構成要素の様にリーダーの選出が行われる。
- (1-02-06). ジェネシス(Genesis).
- 主な役割:クラスター構成要素とサービスのマネージャー。
- 説明: Genesisは、各ノード上で実行されているプロセスであり、初期コンフィグレーションとサービスの相互作用(start/stop 等)を担当している。Genesisは、クラスターとは独立に稼動しているため、コンフィグレーションを行ったり実行するためにクラスターは必要とされない。 Genesisが唯一必要としているのは、Zookeeperが起動され実行されていることである。 GenesisプロセスによりCluster_initとCluster_statusページが表示される。*3
- (1-02-08). ソリブロ、セリブロ?(Cerebro).
- 主な役割:リプリケーション(複製,Replication?)/DR(Disaster Recover)マネージャー。
- 説明:Cerebroは、NDFSのリプリケーションとDR機能を担当している。 これは、スナップショット(snapshot)、リモートサイトへのリプリケーション(replication)のスケジュール、並びにサイトの移動と障害回避(failover)を含んでいる。 Cerebroは、Nutanixクラスターの各ノード上で実行されており、全てのノードがリモートのクラスターやサイトへのリプリケーション(複製)作成に参加する。
- (1-02-09). ピゾス(Pithos). *5
Nutanix Distribution Filesystemは、概念的には以下の様な構成要素で構築されている。
- ストレージ・プール(Storage Pool?).
- 主な役割:物理デバイスのグループ
- 記述:ストレージ・プールは、クラスターのためのPCIe,SSD,HDDデバイス等を含めた物理的なストレージ・デバイスのグループである。 ストレージ・プールは、複数のNutanixノードに跨り、クラスターのスケールに従って拡張される。ほとんどのコンフィグレーションに於いては、単一のストレージ・プールが活用されている。
- コンテナ(Container?).
- 主な役割:VM或いはファイルのグループ
- 記述:コンテナは、ストレージ・プールの論理的な一部分であり、VM或いはFile(vDisk)のグループを収容している。或るコンフィグレーション・オプション(即ち RF)がコンテナ レベルで構成されるが、個々のVM或いはファイル レベルでの適用も可能である。 コンテナは、典型的には(NFS/SMBの場合)データストアと1対1マッピングされる。
以下は、どの様に、これらがNDFSとhypervisorの間のマップしているかを示す。
<<Fig-01-03-01>>
- Extent
- 主な役割:論理的に連続なデータ
- 記述:Extentは、幾つかの連続なブロック(ゲストOSのブロックサイズに依存して変わる)により構成される論理的に連続なデータの1MBの断片である。 Extentは、取扱う塊(粒度:granularity)と効率のためにサブExtent(即ち、スライス(slice?))を単位として書込/読取/変更が行われる。 Extentのスライスは、書込まれたりキャッシュされるデータの総量に依存してキャッシュに移動される際に刈込まれる(trim)ことがある。
以下は、様々なファイルシステムの間でこれらの構造要素がどの様に関連しているかを示している。
<<Fig-01-03-02>>
以下は、様々なファイルシステムの間でこれらの構造要素が論理的にどの様に関連しているかを示しているもう一つの図式表現である。
<<Fig-01-03-03>>
Nutanixバイブル
- (1-04).I/O Path Overview.
Nutanix I/Oパスは、以下の構成要素より成る。
<<Fig.01-04-01>>
- (1-04-01).OpLog.
- 主な役割:永続的な書込みバッファ
- 記述: OpLogは、ファイルシステムのジャーナルに似ており、バースト的な書込みを扱い、それらを纏めて、データを順番にExtent Store?に流し出す。 書込み時、OpLogは、データの利用可能性のため, writeに対し書込確認(acknowledge)が返される前に他のn個のCVMのOpLogに同期的に複製が作られる。 全てのCVMのOpLogは、複製作成に参加し、負荷に基づいて動的に選択される。 OpLogは、極端に高速のI/O性能を、特にランダムI/Oworkloadのために提供するために、CVM上のSSDティア(層:tier)に保存される。 シーケンシャルなworkloadに対し、OpLogはバイパスされ、writeは直接Extent Store?へ直接実行される。 もし、データが現在OpLog内に存在しており、まだExtent Store?へ書出されていない場合、全てのreadは、OpLogからそれらの処理がExtent Store?/Content Cache?によって処理され得る場所に書出されるまで直接実行される。fingerprint(指紋採取処理)(即ち、重複排除処理(dedupe)のため)が有効にされているコンテナ(container?)に対して、全てのwrite I/Oは、コンテント キャッシュ内のfingerprintに基づき重複排除処理を施されることを許しているハッシュを用いてfingerprint処理が行われる。
- (1-04-01).Extent Store?.
- 主な役割:永続的なデータストレージ
- 記述: Extent Store?は,NDFSの永続的な大容量ストレージであり、SSDとHDDに跨っており、またデバイス(device)/ティア(tier)追加を容易にする拡張性がある。 Extent Store?に入力されたデータは、A) OpLog?から書込まれてきたモノであるか、或いは B) シーケンシャルな性質であるためOpLogをバイパスして直接書込まれてきたモノであるかのどちらかである。Nutanix ILMは、I/Oパターンに基づいて動的にティア(tier)の配置を決定し、ティア(tier)間のデータの移動を決定する。
- (1-04-01).Content Cache?.
- 主な役割:ダイナミックなリード キャッシュ
- 記述:Content Cache?(即ち、弾性重複排除エンジン(Elastic Dedupe Engine))は、CVMのメモリとSSDに跨って存在する重複排除が可能なリード キャッシュである。キャッシュ内に存在してないデータに対するread requestが発生すると(或いは、特定のfingerprint?に基づいて)、データはContent Cache?のシングル・タッチ プール内に配置される。このContent Cache?は、キャッシュから排除されるまでLRUを使用するメモリー内に完全に存在している。 それに続くread requestは(実施のデータは全く動かないか、単にmetadataをキャッシュしているだけ)、データをメモリーとSSDにより構成されているマルチ・タッチ プールのメモリ部分に移動する。この時点より２組のLRUサイクルが存在し、一つは新しいLRUカウンターに立退き処理が割付けられておりマルチ・タッチ プール(multitouch pool)のSSDセクションへデータを移動するメモリー内の部分(in-memory piece)である。マルチ・タッチ プール内のデータへのread requestは全て、データがそれが新しいLRUカウンターを与えられるマルチ・タッチ プールの頂上への移動を発生させるであろう。 コンテナー レベルでのfingerprint処理(指紋処理)は、UIを経由して構成される。 defaultでは,fingerprintingは利用を停止されている。
以下に、Content Cache?の概要を示す。
<<Fig-01-04-02>>
- (1-04-01).Extent Cache?.
- 主な役割:メモリ内のリードキャッシュ(in-memory read cache)
- 記述:Extent Cache?は、完全にCVMのメモリ内に置かれた in-memory read cacheである。 これは、fingerprint処理と重複排除処理機能の利用が停止されているコンテナのためにfingerprintの付いていないExtent?の保存を行う。 V3.5の時点で、これはContent Cache?から分離されたが、以後のバージョンで統一されるであろう。
Nutanixバイブル
(2).How It Works. †
- (2-01).Data Protection.
- (2-02).Data Locality.
- (2-03).Scalable Metadata.
- (2-04).Shadow Clones.
- (2-05).Elastic Dedupe Engine.
- (2-06).Networking and I/O.
- (2-07).CVM Autopathing.
- (2-08).Disk Balancing.
- (2-09).Software-Defined Controller Architecture.
- (2-10).Storage Tiering and Prioritization.
- (2-11).Storage Layers and Monitoring.
- (2-12).APIs & Interface.
- (2-13).Availability Domains.
- (2-14).Snapshots & Clones.
- (2-15).Multi-Site Disaster Recover.
(3).Administrateion. †
<<TO BE TRANSLATED IN THE FUTURE.>>
[3].Book of vSphere. †
<<TO BE TRANSLATED IN THE FUTURE.>>
[4].Book of Hyper-V. †
<<TO BE TRANSLATED IN THE FUTURE.>>
[5].Revision. †
<<TO BE TRANSLATED IN THE FUTURE.>>
Learning?
![[Nutanix_Pukiwiki]](image/Nutanix_Logo.jpg "[Nutanix_Pukiwiki]"){kind=logo}
