NutanixFrontPage - PukiWiki

Japanese Nutanix Bible(Pilot site) †

Nutanix バイブル:
- [1].Intro.
- [2].Book of Nutanix.
  - (1).Architecture.
  - (2).How It Works.

Nutanix バイブル: †

Nutanix Bible and Mr.Steven Poitras

[1].Intro. †

Nutanixバイブルへようこそ!。筆者は、日々Nutanix Platformを使用して働いています。即ち、私の商用化に向けたベンチマーク・ラボのためにそれを管理するのと同様、問題を見付け出し、それをその限界を極めています。このページは、私自身とNutanixの様々なEnineer達により日々使用されている情報と細工を示す日々更新されている文書です。この文書はまた、Advanced Nutanix seriesの一部として議論される項目の纏めも含んでいます。

注:この元になる資料並びに翻訳資料はNutanix社の正式の参考資料では無いため、ご自分のリスクでご利用下さい。尚、この資料は適宜更新されます。

注:この資料は以下の Steven Poitrasによる以下のURLのWeb siteNutanix Bibleの核となる章を翻訳したものです。

http://stevenpoitras.com/the-nutanix-bible/

↑

[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-01). カッサンドラ(Cassandra).　*2
- 主な役割:分散メタデータの保存(store)
- 説明:Cassandraは、Apache Cassandraを大幅に変更したものに基づいた分散リング状方式でクラスターのメタデータの全てを保存、管理する。厳密な無矛盾性を強制するために、Paxosアルゴリズムが使用されている。　このサービスは、クラスター内の全てのノード上で動作している。 Cassandraは、Medusaと呼ばれるインタフェースを経由してアクセスされる。

(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-04). キュレーター(Curator).
- 主な役割:MapReduceクラスター管理とクリーンアップ
- 説明:Curatorは、ディスク・バランシング(DiskBalancing),先を見越したスクラビング(Scrubbing)処理、そしてその他多くの処理を含むクラスターを通じたタスクの管理と分散を担当している。 Curator Masterがタスクとジョブの権限委譲を担当する。

(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-07). クロノスChronos. *4
- 主な役割:ジョブ(Job)とタスク(Task)のスケジューラー
- 説明:Chronosは、Curatorのスキャンの結果から得られるジョブとタスクを受取って、ノード間でタスクのスケジュール/スロットリングを担当する。 Chronosは、各ノード上で実行され、選出されたChronosマスターにより制御される。Chronosマスターは、タスクとジョブの権限委譲を担当し、Curatorマスターと同じノード上で実行される。

(1-02-08). ソリブロ、セリブロ?(Cerebro).
- 主な役割:リプリケーション(複製,Replication?)/DR(Disaster Recover)マネージャー。
- 説明:Cerebroは、NDFSのリプリケーションとDR機能を担当している。これは、スナップショット(snapshot)、リモートサイトへのリプリケーション(replication)のスケジュール、並びにサイトの移動と障害回避(failover)を含んでいる。 Cerebroは、Nutanixクラスターの各ノード上で実行されており、全てのノードがリモートのクラスターやサイトへのリプリケーション(複製)作成に参加する。

(1-02-09). ピゾス(Pithos). *5
- 主な役割:vDiskコンフィグレーションマネージャ
- 説明:Pithosは、vDisk (NDFSファイル)コンフィグレーションデータを担当している。 Pithosは、各ノード上で実行されており、Cassandraの上位に構築されている。

(1-03).Data Structure.

Nutanix Distribution Filesystemは、概念的には以下の様な構成要素で構築されている。

ストレージ・プール(Storage Pool?).
- 主な役割:物理デバイスのグループ
- 記述:ストレージ・プールは、クラスターのためのPCIe,SSD,HDDデバイス等を含めた物理的なストレージ・デバイスのグループである。ストレージ・プールは、複数のNutanixノードに跨り、クラスターのスケールに従って拡張される。ほとんどのコンフィグレーションに於いては、単一のストレージ・プールが活用されている。

コンテナ(Container?).
- 主な役割:VM或いはファイルのグループ
- 記述:コンテナは、ストレージ・プールの論理的な一部分であり、VM或いはFile(vDisk)のグループを収容している。或るコンフィグレーション・オプション(即ち RF)がコンテナレベルで構成されるが、個々のVM或いはファイルレベルでの適用も可能である。コンテナは、典型的には(NFS/SMBの場合)データストアと1対1マッピングされる。

vDisk
- 主な役割:vDisk
- 記述:vDiskは、vmdkとVMハードディスクを含んだNDFS上で512KBを上回る全てのファイルである。 vDiskは、グループ化されExtent Groupとしてディスク上に保存されたExtentにより構成されている。

以下は、どの様に、これらがNDFSとhypervisorの間のマップしているかを示す。

<<Fig-01-03-01>>

Extent
- 主な役割:論理的に連続なデータ
- 記述:Extentは、幾つかの連続なブロック(ゲストOSのブロックサイズに依存して変わる)により構成される論理的に連続なデータの1MBの断片である。 Extentは、取扱う塊(粒度:granularity)と効率のためにサブExtent(即ち、スライス(slice?))を単位として書込/読取/変更が行われる。 Extentのスライスは、書込まれたりキャッシュされるデータの総量に依存してキャッシュに移動される際に刈込まれる(trim)ことがある。

Extent Group
- 主な役割:物理的に連続に保存されたデータ(SSD,HDD等の上に)
- 記述:Extent Groupは、物理的に連続に保存されたデータの1MB或いは4MBの断片である。このデータは、CVNに所有されているストレージデバイス上のファイルとして保存されている。 Extentは、性能を向上するためにノード/ディスクを跨ってデータのStripingを提供するために、Extent Group間に動的に分散配置される。
  注: 4.0のExtent Groupは現在、重複排除(dedupe)に依って1MB或いは4MBのどちらかである。

以下は、様々なファイルシステムの間でこれらの構造要素がどの様に関連しているかを示している。

<<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)

以下のビデオを併せご参照下さい。

video

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>>

Nutanixバイブル

(2-02) データのローカリティ(ローカル性・局所性,Data Locality)

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>>

Nutanixバイブル

(2-03) メタデータのスケーラビリティ(metadata scalability)

メタデータは、インテリジェント・システムのコアにあり、あらゆるファイルシステムやストレージアレイにとってはよりクリティカルである。 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バイブル

(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がどの様に動作しているのか、そして分散キャッシュを実現しているのかを示す。

<<Fig.2-04-01>>

Nutanixバイブル

(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リクエストを扱うのかを以下に示す。

<<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バイブル

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

<<Fig.2-06-01>>

Nutanixバイブル

(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間通信のために使用される。

<<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>>

Nutanixバイブル

(2-08) Disk Balancing

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バイブル

(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)が、どの様に見えるのかと云う論理的な表現を以下に示す。

<<Fig.2-09-01>>

Nutanixバイブル

(2-10) ストレージの階層化とプライオリティ付け

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バイブル

(2-11) ストレージ・レイヤーとモニタリング

Nutanixプラットフォームは、VM/Guest OSから物理的Disk Deviceに至る全ての経路が通過する複数のLayerに於いてストレージをモニターしている。様々なティアと、それらがどの様に関連しているのかを知ることはソリューションをモニターする時には常に重要であり、ユーザがどの様に操作が関連しているのかを完全に視覚化することができる。

操作がモニターされる様々なレイヤーと、以降で説明される相対的な塊を示している。

<<Fig.2-11-01>>

(2-11-1)Virtual Machine Layer(バーチャルマシンレイヤー(層))
- 主な役割: Guest OSにより報告される測定量
- 記述: Virtual Machine或いはGuest OSレベルでの測定値は直接hypervisorにより読み出され、Guest OSが見ている性能を現し、アプリケーションが見ているI/O性能を示す。
- 利用する場合:トラブルシューティングや、VMレベルでの詳細を調べる場合。

(2-11-2)hypervisor layer(ハイパーバイザレイヤー(層))
- 主な役割:hypervisorにより報告される測定量
- 記述: hypervisorレベルの計測量は、hypervisorから直接読み取られ、hypervisorが見ているほぼ正確な計測量を現す。このデータは、複数のhypervisorノードのうちの1つ、或いはクラスターの集合体に対して表示される。このレイヤーは、プラットフォームの性能がどの様に見えるのかに関して最も正確なデータを提供するので、多くの場合に利用されるべきである。あるシナリオに於いてhypervisorはVMからの操作を合算したり分離したりするために、VMやhypervisorによって報告される測定量に差異が認められるかも知れない。これらの数値はまた、Nutanix CVMにより処理されるキャッシュのヒットも含んでいる。
- 利用する場合:ほとんどの一般的な場合、これは最も詳細で価値の有る測定量を提供する。

(2-11-3)Controller Layer(コントローラーレイヤー(層))
- 主な役割:Nutanix Controllerにより報告される測定量。
- 記述: コントローラレベルでの測定量は、Nutanix Ccontroller VM(CVM)(即ち Stargate Port番号2900のPage)から直接読込むこととが可能であり、Nutanix front endが、NFS/SMB/iSCSI或いは全てのバックエンドオペレーション(即ち、ILM, ディスク・バランシング等)から何を見ているのか表している。 1つ以上のVM或いはクラスターの集合に対してこのデータを見ることができる。コントローラーレイヤーにより見える測定量は、全てのバックグラウンドオペレーション(即ち、ILM,ディスク・バランス)も含まれているが、ハイパーバイザーレイヤーによって見えるデータと一致しなければならない。これらの数値には、メモリによるキャッシュのヒットも含まれる。
- 利用する場合:hypervisor同様、バックグラウンドオペレーションがどれくらい実行されているのかを示すために使用することができる。

(2-11-4)Disk Layer(ディスクレイヤー(層))
- 主な役割:ディスクデバイスにより報告される測定量。
- 記述: ディスクレベル測定量は、物理ディスクデバイスから(CVM経由で)直接読み出され、バックエンドが見ているものを表す。これは、I/Oがディスクに対して実行される場合にOpLog?、或いはExtent storeにヒットするデータを含む。このデータは、1つ以上のディスクやあるノードに対する、ディスク、クラスター内のディスクの集合に対して見る事ができる。一般的な場合には、ディスク・オペレーションは、キャッシュのメモリ部分から処理されなかった読み取りと、発生した書込み要求の数に一致するべきである。キャッシュのメモリ部分によって処理された処理されるリードの全てはディスクデバイスにヒットしないために、ここでは数えられない。
- 利用する場合:キャッシュとディスクにヒットしている処理の量を調べる場合。

Nutanixバイブル

(2-12) APIとインターフェース

全てのダイナミック、或いはソフトウェアデファインド環境に於いて中心的な存在であるために、Nutanixは、膨大な数の一連のインターフェースを提供し、簡単なプログラマビリティとインターフェイシングを可能としている。主なインターフェースとして以下の様な物がある。

REST

nCLI

scripting inteface (この項目に関しては、将来記述される予定)

これに対する中核は、REST APIであり、これはPRISM UIの全てのデータポイントと機能を表している。

<<Fig.2-12-01>>

Nutanixバイブル

(2-13) アベイラビリティ・ドメインアベイラビリティドメインは、node/block/rackを認識(aware)した機能と同様の意味であり、各要素とデータの配置の決定することにより分散システムを守るための主要な構成要素である。 NDFSは、現時点でnodeとblockを認識(aware)し動作しており、クラスターサイズが成長するに従ってrackを認識することになるだろう。 Nutanixは、1台から4台の"node"を含むシャーシを"block"と呼称している。

注) block認識機能(awareness)を有効にするためには、最低3台のblockが必要となる。そうでない場合は、node認識運用(awareness)がデフォルトとして使用されている。 "block認識(awareness)"を確実に有効にするためには、各blockの構成を均一にして置く事が推奨される。共通のシナリオと使用される認識(awareness)のレベルは、この節の終わりに示されている。 3blockと云う要求は最低充足数に依るものである。

認識(awareness)機能は、以下の最重要な領域に分割される。

Data(The VM data)
Metadata(Cassandra)
Configuration Data(Zookeeper)

(2-13-1) データ blockの故障或いは計画停止の状況下で、データを利用可能に保つためにNDFSデータの複製が、cluster内の他のnodeに書込まれる。 block故障同様、RF2,RF3シナリオの両方に対しても同じである。
簡単な比較は、node故障の場合に保護を提供するために他のnodeにレプリカが作成されなければならない"node認識(awareness)"と簡単に比較してみよう。 block認識(awareness)は、block障害の場合にデータを利用可能に保つためにこの機能(node awareness)を更に強化したものである。
3blockで設置された場合にどの様にレプリカが配置されるのかを以下に示す。

<<Fig.2-13-01>>

block故障が発生した場合でも、block認識(awareness)は維持されており、cluster内の他のblockに再度レプリカが作成される。

(2-13-2) metadata

先にスケーラブル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>>

(2-13-03) Conifguration Data

<<Fig.2-13-05>>

<<Fig.2-13-06>>

<<Fig.2-13-07>>

Nutanixバイブル

(2-14) スナップショットとクローン

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-15) マルチサイトディザスターリカバリー(Multi-Site Disaster Recovery)

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

(2-15-01) Replication Topologies

伝統的には、幾つかの主要な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機能を決定することが可能である。

(2-15-02) 実現のための構成要素

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-15-03) Global Deduplication

セクション(2-05)Elastic Dedup Engineの説明で触れた様に、NDFSにはmeta data pointerを更新するだけでdeduplication(重複排除)を行う機能がある。

同じ考え方がDRとreplication機能にも使用されている。通信路上にデータを送信する前に、NDFSはリモートサイトに検索(query)を掛け,fingerprint(指紋)が既に存在しているかどうか(即ち、データが既に存在しているかどうか)を確認する。もし既に存在しているのであれば、データが書込まれることは無く、メタデータの更新だけが発生する。

ターゲット上に存在していないデータに対しては、データは圧縮され(compress)ターゲットサイトに送信される。この時点でデータは両方のサイト上に存在しておりdeduplicationのために使用可能である。

複数のプロテクション・ドメイン(PD)を含んだ3サイトの例を以下に示す。

<<Fig.2-15-03>>

<<replicationに関するセクションは将来追加の予定。>>

Nutanixバイブル

230922