Nutanixのデータ保護について覚えてみよう～Metro AvailabilityとNear Syncの違いについて～

 みなさん、こんにちは

本日投稿の内容について、以前別サイトで私が投稿したブログの内容です。

サイトの閉鎖に伴い、こちらで再度掲載いたします。

今回はNutanixのデータ保護についてご紹介します。

Nutanixのデータ保護については、Metro Availability （完全同期型）とNear Sync（ほぼ同期）の2種類があります。

今回はその違いについてお話するわけですが、まず⼀般的にビジネス継続性の観点でSLAを起点考えるわけですが、⼀般的にどのように定義するのか⾒ることにしましょう。

1. SLAベースの推奨事項

インシデントレベルでRPO（Recovery Point Objective）とRTO（Recovery Time Objective）決めていくわけですが、マイナーレベルであれば通常のバックアップのソリューションで対応できますが、重⼤インシデントでも停⽌がありえないシステムではDisaster Recoveyテクノロジー（同期レプリケーション）が必要となります。

ではNutanixにおいてはDRをどのように対応するのかを⾒てみましょう。

２. Nutanixのネイティブデータ保護はどこが適していますか？

DR施策としてマイナーインシデントであればローカルスナップショットやCloud Connectなどを利⽤すると良いでしょう。ただし重⼤インシデントについては、⾮同期レプリケーションもしくはNearSync（この⼆つは定義する時間が違います。後ほどご説明いたします）にな

ります。RPO/RTOゼロを求められる場合は、完全にMetro Availabilityしかありません。

バックアップについては、ローカルスナップショットもしくは3rdパーティのバックアップソフトウェアを使うしかありません。

こちらはあくまでデータのリカバリの観点のお話でしたので、実際にインフラ上で動いているアプリケーションやハイパーバイザー・ストレージの観点で⾒るとどうなるでしょうか︖

３. データ退避のテクノロジー

こちらにまとめているのが、それぞれの視点で⾒たデータ退避のテクノロジーになります。アプリケーション（特にデータベース系）についてはすでにベンダー側での実装がされています。ハイパーバイザーについてもマイクロソフト・VMwareとも同期レプリケーションのテクノロジーが対応できていますし、Nutanixにおいてもストレージにおいては対応できております。

ここでAHVの記載を書いておりませんが、AHVに関してはNear SyncベースでAOS6.0（STS)で同期レプリケーションが対応になっております。

それではここからはMetro AvailabilityとNear Syncについての説明します。

４. Metro Availabilityとは？

Metro Availabilityとは両サイト間で低遅延のネットワークで構成した上でお互いのコンテナでデータ同期処理を⾏うことができ、障害時にも⾃動に切り替えられる機能のことです。構成も⾮常にシンプルで同期するにあたりオーバーヘッドもないため、ストレージ部分のサイジングも苦労はありません。しかしながら、データの同期処理を⾏う必要があることから、5ms以内の遅延を要求されます。

（5ms以上の遅延でもNGになるわけではないが、保証はしない）

そのMetroAvailabilityについてどのような背景で必要になったのかを説明します。

５. なぜMetro Availabilityが必要なのか？

Metro Availabilityが必要になった背景は災害対策とワークロードのモビリティです。災害対策は当然のことでお分かりだと思いますが、NutanixはもともとApp Mobilityという概念の元で別サイトでのワークロード起動も考えています。

あとはミッションクリティカルのアプリケーションを動かすお客様にとっては運⽤停⽌時間は極⼒短くする必要がありますので、その実現も含めて考えなければいけません。

また、こちらのMetro Availabilityについては、ESXiもしくはHyper-Vの環境が必須になります。

６. Metro Availabilityのガイドライン

保護ドメインは、ローカルクラスタ上にプライマリストレージコンテナを指定し、リモートクラスタ上に同じ名前のスタンバイストレージコンテナを指定することによって作成

• Metro Availabilityを備えたストレージコンテナを使用する場合、データストア名はストレージコンテナ名と同じでなければならない
• 2つのサイト間でデータストアの可用性を確保するには、両方のサイトにリアルタイムでデータが存在する必要がある。クラスタ間の応答時間は5ミリ秒未満である必要がある。ピーク書き込みに対応できるように適切な帯域幅をキープします。サイト間に冗長な物理ネットワークを持つことを推奨
• 特定の仮想マシンに関連付けられたすべての仮想ディスクが、Metro Availabilityが有効になっているコンテナに存在することを確認
• 保護された仮想マシンは、アクティブストレージコンテナに関連付けられたNutanixクラスタまたはスタンバイストレージコンテナに関連付けられたクラスタで実行できます。ただし、スタンバイ・ストレージ・コンテナに関連付けられたクラスタで仮想マシンが実行されている場合、アクティブなストレージ・コンテナへの読み書きが行われます。したがって、仮想マシンのデータが格納されているアクティブなコンテナに対して仮想マシンをローカルで実行して、ネットワークトラフィックおよび関連するネットワーク遅延を減らすことを推奨

７. Metro Availabilityのセットアップ

Metro Availabilityのセットアップについては上記のようにProtection Domainでコンテナ名を揃えておく必要があります。

８. アクティブ・スタンバイ状態で何が起きているのか？

アクティブ側からのRF2での書き込み(WRITE)の構造 

スタンバイサイトからのRF2での書き込み(WRITE)の構造 

スタンバイサイトからのRF2での読み込み（READ）の構造 

こちらの３つの図については、仮想マシンからWrite/Read要求をCVMがどのように応答しているのかを記載しております。Writeデータはデータローカリティとデータの冗⻑化でコンテナ内で同期を取りつつ、他サイトのコンテナでも同期処理を⾏います。

９. 計画的メンテナンス

計画的なメンテナンスを行う際に実施する必要があるのが以下の内容になります。

1. アフィニティルールのアップデート
2. 仮想マシンをサイト2へvMotion 
3. サイト２内のMetro Protection Domain(PD)の昇格 
4. サイト1のPDを無効化 
5. サイト2内のPDを再有効化

１０. 計画外の障害

計画外の障害のときの挙動について説明します。

サイト１が停電してしまった場合にどう機能するかを記載していますが、サイト２側がサイト１の停電を検出するとWitnessサーバがロックされてしまいます。ロックされた場合はスタンバイサイトのProtection Domainがプライマリに昇格することになります。ハイパーバイザーのHA機能で、サイト２側で仮想マシンが再起動しますが、この際管理者の操作は⼀切ありません。

ここまでがMetro Availabilityのお話になりますが、仮にMetro Availabilityが使えない場合はどうなるのか︖というお話もあると思いますので、以下に想定できる理由も含めて記載しておきます。

１１. Metro Availabilityが利用できないケース

Metro Availabilityに関して拠点間の距離に依存するため、長距離の場合はMetro Availabilityは利用できません。

またはシングルストレッチハイパーバイザークラスタにも適しません。

Metro Availabilityは構成する場合はRPOとRTOを考慮する必要があります。

１２. Near Syncレプリケーションについて

非同期連続レプリケーション

• 継続的なデータ保護のテクノロジー
• フルスナップショットの代わりに「マーカー」を使用する 
• 完全にOplogベースで、LWS（※） StoreはSSD上に存在します 

Near Syncレプリケーションとは⾮同期レプリケーションですが、間隔が短く連続的に⾏うレプリケーションになります。アーキテクチャは既存のNutanixのスナップショットの技術を利⽤していますが、スナップショット領域にあたるOplog領域を短い間隔で利⽤します。

１３. なぜNear Syncが必要なのか？

Near Syncの登場により同期できない環境でもほぼゼロに近いRPO/RTOを実現したいときに利⽤できます。データの損失は多少あるものの、それを最⼩限に抑えるのがこのソリューションの特徴になります。

リモートおよびローカルの災害対策（DISASTER RECOVERY）

• オーケストレーションされたワークフローによる最小のデータ損失距離を意識したレプリケーション
• アプリケーションパフォーマンスの影響を最小限に抑える 

• データ損失のコストを削減する 
• 運用停止時間の短縮
• テスト用のクローン/ dev / reporting

１４. Near Syncの設定条件

• サポートされるレプリケーションは1：1のみ
• NearSyncを有効にするには、プライマリサイトとリモートサイトの両方のクラスタに最低3つ以上のノードが必要
• 1〜15分のスケジュール設定がサポートされています。スケジュールは16〜59分に設定することはできません
• クラスタ内の各SSDは最小容量を1.2TBにする必要があります。十分な容量がない場合、クラスタはNearSyncを有効にできません。また、ノードまたはSSDを追加する場合は、各SSDの容量が1.2 TB以上であることを確認してください。最適なパフォーマンスを得るには、ハイブリッドストレージ構成の最小SSDサイジング要件は2 x 1.9 TBです。特定のSSDサイジング制限は、All Flashクラスタには適用されません（7%の空き領域がローカルのSSDとリモートにクラスタに必要）
• 各保護ドメインに最大10のエンティティ（仮想マシンまたはボリュームグループ）があることを確認してください。アプリケーションを構成する仮想マシンを単一の保護ドメインにグループ化して、特定のアプリケーションのフェイルオーバー精度を高めることをお勧めします
• 40TB以上のストレージ（すべてのSSD、SSDまたはHDDの組み合わせ）を持つノードを持つクラスタでは、NearSyncを有効にしないでください

他のハードウェアベンダーとNutanixのクラスタ間でNear Sync設定を行いことが可能になります

• ESXiとAHVをサポート
• IBM Power Systemsを除くすべてのプラットフォームがサポート
• この機能は、同種のクラスタでのみサポートされています。クラスタ内のすべてのノードは同じタイプのハイパーバイザを実行する必要がある
• リモートサイトコンテナには、プライマリサイトの保護されたエンティティの作業サイズセットと同じスペースが必要。たとえば、プライマリサイトのコンテナで30 GBの領域を使用している仮想マシンを保護する場合は、リモートサイトコンテナに同じ容量が必要
• 保護ドメインへのエンティティの追加または削除は、他のエンティティのリカバリポイントに影響を与えないようにこの機能を設定した場合は無効になります。この機能を使用して構成された保護ドメインを編集する場合は、まず、構成済みのNearSyncスケジュールを削除し、保護ドメインを編集して（エンティティの追加または削除）、新しいスケジュールを再構成します
• 遅延要件はありませんが、2つのサイト間の帯域幅は、保護されたエンティティの変化率とほぼ同じかそれ以上にする必要がある
• NearSyncスケジュールで構成され、リモートサイトに複製されるように構成された保護ドメインの場合は、対応するvStoreマッピングを構成する必要がある

１５. Near Syncの制限事項

• 仮想マシンのリンククローン機能は未サポート
• Light Weight Snapshotでは、チェンジブロックトラッキング(CBT）は未サポート
• ワンタイムスナップショットは未サポート
• シングルノードレプリケーションターゲットクラスタまたはシングルノードクラスタは未サポート
• Hyper-Vは未サポート
• Metro Availabilityの環境およびSRMで保護されたコンテナは未サポート
• セルフサービスの復元は未サポート
• Nutanix Files は未サポート
• NearSync保護ドメインにあるVMでは、ネイティブバックアップの統合（Commvault IntelliSnap, Rubrik）は未サポート。ただし、ESXiまたはVADPを介して撮影されたスナップショットはサポート。
• NearSyncスケジュールのNutanixネイティブスケジュールでは、アプリケーション整合性のあるスナップショットは未サポート
• 次の機能のための最小RPOは影響なし
• Cloud Connect：最低RPOは1時間
• 単一ノードおよび2ノードのクラスター：最小RPOは6時間
• Cross-Hypervisor DR：RPOの最小値は1時間

１6. Near Syncは非同期スナップショットからスタート

こちらはスナップショットの動きについて紹介をしております。vDiskがスナップショットを取るタイミングのDiskイメージになります。スナップショットを取るタイミングについては次のスライドで説明します。

１７. 伸縮自在のスケジューリング

こちらがスナップショットのスケジューリングです。たとえば1分間隔で15世代分で15分対応可能ですが、16分以降の設定はできません。ほかの時間間隔でも設定不可の領域はあります。

１８. データ保護のランブック（ワークフロー）の自動化

こちらはデータ保護したもののどうやって⾃動化するのか︖というところで、ワークフローを⾏うとこうなりますという図になります。先ほどのMetro Availabilityは⾃動化はシンプルにできますが、どのポイントに戻すのか︖などの時間の指定なども明確化しなければなりませんのでワークフローで⼀度定義して、それを⾃動化するというフローです。Metro Availabilityのような⾃動化とは若⼲異なります。

１9. Metro AvailabilityとNear Syncの違い

最後にMetro AvailabilityとNear Syncの違いを記載しておきました。

最後の項⽬以外は今までに説明してきた内容になりますので省略します。両機能

ともUltimate EditionもしくはPro Editionの場合はAdvanced Replication用のアドオンが必要となりますので、ご注意ください。

よろしくお願い致します。