次の方法で共有


Azure NetApp Files のゾーン間レプリケーションを理解する

多くの場合、可用性ゾーン間の回復性は、「高可用性のために可用性ゾーンを使用する」で説明されているように、アプリケーションベースのレプリケーションと HA を使用した HA アーキテクチャによって実現されます。 ただし、ストレージベースのデータ レプリケーションを代わりに使用するほうが手法としてずっとシンプルであり、費用対効果に優れていると見なされることが多くあります。

Azure NetApp Files リージョン間レプリケーション機能と同様に、ゾーン間レプリケーション (CZR) 機能は、異なる可用性ゾーン内のボリューム間でデータを保護します。 ある可用性ゾーンの Azure NetApp Files ボリューム (ソース) から別の可用性ゾーンにある別の Azure NetApp Files ボリューム (コピー先) にデータを非同期的にレプリケートできます。 この機能により、ゾーン全体が停止したり障害が発生した場合に、重要なアプリケーションをフェールオーバーすることができます。

ゾーン間レプリケーションは、Azure NetApp Files が存在するすべての AZ 対応リージョンで利用できます。

サービスレベルの目標

回復ポイントの目標 (RPO) は、データを復旧できる対象の時点を示します。 RPO ターゲットは通常、レプリケーション スケジュールの 2 倍未満ですが、ばらつきがあります。 データセットの合計サイズ、変更率、データ上書きの割合、転送に使用できるレプリケーション帯域幅などの要因によっては、ターゲット RPO を超える場合もあります。

ゾーン間レプリケーションでは、10 分、毎時、毎日の 3 つのレプリケーション スケジュールがサポートされます。

  • レプリケーション スケジュールが 10 分の場合、一般的な RPO は 20 分未満です。
  • 時間単位のレプリケーション スケジュールでは、一般的な RPO は 2 時間未満です。
  • 毎日のレプリケーション スケジュールでは、一般的な RPO は 2 日未満です。

重要

ゾーン間レプリケーションを使用した大容量ボリュームでは、10 分のレプリケーション スケジュールはサポートされません。

目標復旧時間 (RTO)、つまりビジネス アプリケーションのダウンタイムの最大許容期間は、アプリケーションを起動し、2 番目のサイトでデータへのアクセスを提供する際の要因によって決定されます。 ピアリング関係を解除してコピー先のボリュームをアクティブ化し、2 番目のサイトの読み書きデータ アクセスを提供するための RTO のストレージ部分は、1 分以内に完了すると予想されます。

ゾーン間レプリケーションのコスト モデル

レプリケートされたボリュームは容量プールでホストされます。 そのため、ゾーン間レプリケーションのコストは、通常どおり、プロビジョニングされた容量プールのサイズと階層に基づきます。 データ レプリケーションに追加コストはかかりません。

次のステップ