*ストレージシステムは共通障害点です。*Proxmox VE HAは、テナントVMをホストの障害から保護しますが、VMのディスクをホストするストレージシステムの障害からは保護しません。ストレージの障害が1件発生すると、そのシステムを利用しているすべてのテナントに影響が及びます。

*より高い可用性を販売する方法はありません。*同期レプリケーションと自動ストレージフェイルオーバーがなければ、プロバイダーはデータ損失ゼロで稼働率の保証がより強力なプレミアム可用性ティアを提供することはできません。

*復旧中のテナント分離。*復旧、保守、および災害復旧テストは、プラットフォーム全体ではなく、関係するテナントにのみ影響するようにする必要があります。

*QDeviceには引き続き3つ目の設置場所が必要です。*ONTAP Cloud Mediatorは、corosync QDeviceホストではなく、メディエーターホストを削除します。QDeviceには、すべてのProxmox VEノードがTCPポート5403でアクセスできる小規模なLinuxホストが必要ですが、corosyncの低レイテンシ要件はありません。

*両方のクラスタはNetApp Consoleにアクセスできる必要があります。*クラスタでプロキシを使用する場合は、プロキシのルートCA証明書を両方のクラスタにインストールします。NetAppでは、クラスタごとに異なるプロキシ サーバを使用することを推奨しています。

*どちらのオプションでも同じ障害時の動作を想定して計画してください。*メディエーターが利用できない場合、レプリケーションはデータ損失なく継続されますが、メディエーターが再び利用可能になるまで、自動および計画的なフェイルオーバーは実行できません。ONTAP Cloud Mediatorを使用する場合、これにはクラスタからNetApp Consoleへの接続の喪失が含まれます。

*ホストHAを超えるVMの可用性。*テナントVMは、ディスクをホストするストレージシステムに障害が発生しても稼働し続けます。ONTAPは2番目のAFFクラスタにフェイルオーバーし、VMは再起動することなく同じ共有ストレージ上でI/Oを再開します。

*プレミアム可用性ティア*同じクラスタ内の保護されていないストレージ上の標準ティアと並行して、RPOゼロでストレージ耐障害性に優れたVMサービスをアドオンとして提供できます。

*テナントごとの保護とフェイルオーバー*テナントまたはサービス階層ごとに個別の保護ストレージを使用することで、他のテナントに影響を与えることなく、各テナントの保護、フェイルオーバー、およびディザスタリカバリのテストを個別に実行できます。

*両サイトをより有効活用する。*一部のワークロードをサイトAでプライマリにし、他のワークロードをサイトBでプライマリにすることで、両方のデータセンターがアクティブなワークロードに対応できるようになります。

ストレージ障害またはサイト障害の発生時における、ビジネス クリティカルなVMのデータ損失ゼロ。

スクリプト、ストレージの再マウント、または `/etc/pve/storage.cfg`への変更を必要としない*自動リカバリ*。

ONTAPに組み込まれており、Proxmox VEノード上に追加のソフトウェアレイヤは不要です。

*1つのインターフェイスで日常業務を管理。*Storage Manager for Proxmoxは、保護された共有ストレージをプロビジョニングし、ONTAPスナップショットとFlexCloneテクノロジを使用してVMのバックアップ、リストア、クローン作成を行います。

ストレージ上のすべての、またはほぼすべてのワークロードでRPOをゼロにする必要がある場合は、MetroClusterを選択してください。たとえば、企業がクラスタ上でミッションクリティカルなVMのみを実行している場合や、サービスプロバイダがすべてのテナントに同じ可用性階層を提供している場合などです。ワークロードごとの設定なしで、1つの保護ドメインが提供されます。

一部のテナント向けのプレミアム階層など、ワークロードのサブセットのみにRPOゼロが必要な場合、または一度に1つのテナントまたはアプリケーションに対してフェイルオーバーやディザスタリカバリのテストを行う必要がある場合は、SnapMirror active syncを選択してください。

NAS向けのSnapMirrorアクティブ同期は、MetroCluster構成ではサポートされていません。クラスタの各ペアには、いずれか1つのソリューションを使用してください。

このソリューションにおけるcorosync、QDevice、およびHAに関するガイダンスは、どちらにも適用されます。MetroClusterを使用する場合、サイト間リンクに障害が発生したときにデータの提供を継続するサイトにQDeviceタイブレーカーを合わせ、HAノードアフィニティルールを使用してVMをアクティブなSVMと同じサイトに維持します。

MetroCluster IPは、サイト間のレイヤ3ネットワーク向けにBGPを使用したVIP LIFもサポートしています。

SnapMirrorアクティブ同期には、クラスタ間の往復時間（RTT）が10 ms未満である必要があります。Proxmoxは、すべてのノード間のcorosyncレイテンシを5 ms未満にすることを推奨しているため、corosyncの要件がソリューションの距離制限を決定します。

Corosyncは、高い帯域幅よりも、低く安定したレイテンシを必要とします。ストレージのバーストによってcorosyncのタイムアウトが発生しないように、ストレージやライブマイグレーションのトラフィックとは別に、corosync専用のネットワークを使用してください。

サイト間の別々の物理パス上に、少なくとも2つのcorosyncリンク（例えば、リンク0とリンク1）を設定してください。CorosyncはKronosnetを使用して、いずれかのパスに障害が発生した場合に自動的にリンクを切り替えます。

Proxmox VE HAは通常、障害が発生したノードを検出し、60秒のウォッチドッグフェンシングタイムアウトを含めて約2分でVMを復旧します。サイト障害時には、SnapMirror active syncのフェイルオーバーとProxmox VE HAのリカバリが並行して実行されます。

HA ノードアフィニティルールとノード優先度を使用して VM をプライマリストレージと同じサイトのノードに配置し、別のサイトにフェイルオーバーできるようにします。

サイトのフェイルオーバー後、ストレージをフェイルバックするまで、影響を受けるVMのHA `failback`プロパティを `0`に設定します。そうしないと、アクティブなストレージがまだサイトBにあるにもかかわらず、サイトAのノードが復旧し次第、HAがVMをサイトAのノードに移行してしまいます。

ゲストOSのディスクタイムアウトを、想定されるフェイルオーバー時間よりも長く設定してください。そうすることで、ストレージフェイルオーバー中にゲストOSがI/Oエラーを報告しなくなります。

リソースグループとバックアップポリシーを使用して、テナントまたはアプリケーションの仮想マシンに同じスケジュールと保持期間を適用します。

QEMUゲストエージェントを実行するVMにはファイル整合性バックアップを使用し、ONTAPがスナップショットを作成する前にゲストファイルシステムが静止されるようにします。

SMPはアクティブなストレージを管理します。SnapMirrorアクティブ同期のフェイルオーバー後、バックアップまたはリストア操作を実行する前に、SMPで検出を実行してストレージをクラスタBにマッピングします。

2つのサイト以外の3番目のコピー、またはより長い保存期間が必要な場合は、保護対象ボリュームからSnapMirror非同期ファンアウト関係を追加するか、Proxmox Backup Serverを使用してください。

改ざん防止スナップショットはSnapMirrorアクティブ同期ではサポートされていないため、保護対象ボリュームのSMPでスナップショットロックを有効にしないでください。

ストレージまたはサイト障害の発生後もSMPを引き続き利用できるように、SnapMirrorアクティブ同期で保護された共有ストレージ上のHAリソースとしてSMP VMを実行します。

SMPがどちらのサイトのアクティブストレージにもアクセスできるように、SMPにProxmox VEクラスタと両方のONTAPクラスタを登録します。

SnapMirror active sync for NASは、ストレージVM（SVM）全体を保護します。SVM内のすべてのボリュームを保護することも、選択したボリュームを除外することもできます。サポートされるのはFlexVolボリュームのみであり、SVMにLUNを含めることはできません。

セカンダリSVMは、フェイルオーバーが発生するまで、LIFがダウンした状態で休止状態を維持します。ONTAPは、LIF IPアドレス、エクスポートポリシー、NFS設定などのSVM構成を複製するため、フェイルオーバー後もセカンダリSVMは同じNFSエンドポイントを提供します。

NFSv3以降では、フェイルオーバーは中断を伴いません。

SnapMirror NASのアクティブ同期はアクティブ / パッシブであるため、サイトBノード上のVMは、サイト間ネットワークを介してプライマリSVMとの間で読み書きを行います。両サイトでアクティブなワークロードを実行する場合は、レプリケーション方向が逆の2つのSVMを使用し、各サイトに1つずつプライマリSVMを配置し、各VMのノードアフィニティルールをプライマリSVMのサイトに合わせます。

NAS向けSnapMirrorアクティブ同期は、AFF AシリーズおよびCシリーズの2ノードクラスタでサポートされています。

*nConnect.*単一の NFS LIF アドレスへの複数の TCP 接続を開きます（例： nconnect=4）。nConnect は NFSv3 および NFSv4.1 と単一の VIP LIF アドレスで動作するため、レイヤ 3 ネットワークを含む NAS 向け SnapMirror アクティブ同期に推奨されるオプションです。

*セッショントランキング。*複数のデータLIFを1つのNFSv4.1セッションにグループ化します（たとえば vers=4.1,trunkdiscovery,max_connect=16）。セッショントランキングにはNFSv4.1以降が必要です。保護対象のSVMに、拡張レイヤー2ネットワークなど、クライアントが両方のサイトからアクセスできる複数のデータLIFがある場合にのみ使用してください。詳細については、"NFSトランキング"を参照してください。

プライマリSVMにボリュームをプロビジョニングし、NFS LIF、またはレイヤー3ネットワークの場合はVIP LIFを優先LIFとして選択します。セカンダリSVMはフェイルオーバー後も同じアドレスを使用するため、ストレージ定義は有効なまま維持されます。

HAがどのノードでもVMを再起動できるように、両サイトのすべてのProxmox VEノードにストレージをマウントしてください。

エクスポートポリシーで、両サイトのProxmox VEノードが許可されていることを確認してください。ONTAPはエクスポートポリシーをセカンダリSVMに複製します。

プロビジョニング後、ボリュームがSnapMirrorアクティブ同期保護に含まれていることを確認します。

BGP LIFはフェイルオーバーしません。冗長性は、ノードごとに2つのBGP LIFが存在し、それぞれが異なるルーターとピアリングすることで実現されます。ノードがSVMのすべてのBGPセッションを失った場合、ONTAPはVIP LIFを、そのSVMに対してアクティブなBGPセッションを持つ別のノードに移動します。

各ONTAPノードと各ルーターに、固有のプライベート自律システム番号（ASN）を持つ外部BGP（eBGP）を使用します。

各BGP LIFとそのルーターには、/31サブネット（ネットマスク255.255.255.254）を使用してください。奇数番のアドレスをBGP LIFに、偶数番のアドレスをルーターに割り当ててください。

ONTAPはルーターからのルートを処理しません。ONTAPからの/32ホストルートを受け入れ、クラスタにルート更新を送信しないようにルーターを設定します。

Proxmox VEノードは、VIPアドレスと同じサブネットを共有してはなりません。ノードとストレージ間の経路には、例えばVRRPやHSRPを備えた冗長なレイヤー3ルーターを設置する必要があります。

各クラスタがローカルルータからデフォルトルートを学習するように、 `-use-peer-as-next-hop true`を使用してBGPピアグループを設定します。サイトAのゲートウェイを指すルートは、フェイルオーバー後のサイトBでは無効になります。

マルチパスルーティングを有効にして、送信VIPトラフィックが利用可能なすべてのBGP LIFポートを使用するようにします。

BGPのホールド時間をデフォルトの180秒から短縮します。TR-4949では、3秒のホールド時間を推奨しています。ルーターが障害の発生したクラスターからルートを取り消すのは、ホールドタイマーが満了したときのみであり、ストレージシステム障害の発生中もサイトAのルーターはオンライン状態を維持します。