Nutanixバイブル/NutanixBible_2-15J

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