Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

SnapMirrorテクノロジを使用してストレージバックエンド間でアプリケーションをレプリケート

共同作成者

Astra Controlを使用すると、NetApp SnapMirrorテクノロジの非同期レプリケーション機能を使用して、RPO(目標復旧時点)とRTO(目標復旧時間)の低いアプリケーションのビジネス継続性を構築できます。設定が完了すると、アプリケーションは、ストレージバックエンド間、同じクラスタ上、または異なるクラスタ間でデータやアプリケーションの変更をレプリケートできるようになります。

バックアップ/リストアとレプリケーションの比較については、を参照してください "データ保護の概念"

アプリケーションは、オンプレミスのみ、ハイブリッド、マルチクラウドなど、さまざまなシナリオでレプリケートできます。

  • オンプレミスサイトAからオンプレミスサイトAへ

  • オンプレミスサイトAからオンプレミスサイトBへ

  • Cloud Volumes ONTAP を使用してオンプレミスからクラウドに移行できます

  • Cloud Volumes ONTAP を使用したクラウドをオンプレミスに移行

  • Cloud Volumes ONTAP を使用したクラウドからクラウドへ(同じクラウドプロバイダ内の異なるリージョン間または異なるクラウドプロバイダ間)

Astra Controlを使用すれば、オンプレミスのクラスタからクラウドへ(Cloud Volumes ONTAP を使用)、またはクラウド間(Cloud Volumes ONTAP からCloud Volumes ONTAP へ)にアプリケーションをレプリケートできます。

メモ 別のアプリケーションを逆方向に同時に複製できます。たとえば、アプリケーションA、B、Cはデータセンター1からデータセンター2にレプリケートでき、アプリケーションX、Y、Zはデータセンター2からデータセンター1にレプリケートできます。

Astra Controlを使用すると、アプリケーションのレプリケーションに関連する次のタスクを実行できます。

レプリケーションの前提条件

Astra Controlによるアプリケーションのレプリケーションを開始するには、次の前提条件を満たしている必要があります。

  • * ONTAPクラスタ*:

    • * Astra Trident *:ONTAPをバックエンドとして利用するソースとデスティネーションの両方のKubernetesクラスタに、Astra Tridentバージョン22.10以降が存在している必要があります。

    • ライセンス:Data Protection Bundleを使用するONTAP SnapMirror非同期ライセンスが、ソースとデスティネーションの両方のONTAPクラスタで有効になっている必要があります。を参照してください "ONTAP のSnapMirrorライセンスの概要" を参照してください。

  • ピアリング

    • *クラスタとSVM *:ONTAPストレージバックエンドにピア関係が設定されている必要があります。を参照してください "クラスタと SVM のピアリングの概要" を参照してください。

      重要 2つのONTAPクラスタ間のレプリケーション関係で使用されるSVM名が一意であることを確認してください。
    • * Astra TridentとSVM *:ピア関係にあるリモートSVMがデスティネーションクラスタのAstra Tridentで使用可能である必要があります。

  • * Astra Control Center *:

    ヒント "Astra Control Centerを導入" シームレスなディザスタリカバリのための第3の障害ドメインまたはセカンダリサイト。
    • 管理対象クラスタ:次のクラスタをAstra Controlに追加して管理する必要があります(理想的には障害ドメインやサイトが異なる場合)。

      • ソースKubernetesクラスタ

      • デスティネーションKubernetesクラスタ

      • 関連付けられているONTAPクラスタ

    • ユーザアカウント:ONTAPストレージバックエンドをAstra Control Centerに追加する場合は、「admin」ロールのユーザクレデンシャルを適用します。このロールにはアクセス方法があります http および ontapi ONTAP ソースとデスティネーションの両方のクラスタで有効にします。を参照してください "ONTAP ドキュメントの「ユーザーアカウントの管理」を参照してください" を参照してください。

  • * Astra Trident / ONTAPの設定*:Astra Control Centerでは、ソースクラスタとデスティネーションクラスタの両方のレプリケーションをサポートするストレージバックエンドを少なくとも1つ設定する必要があります。ソースクラスタとデスティネーションクラスタが同じである場合は、耐障害性を最大限に高めるために、デスティネーションアプリケーションでソースアプリケーションとは別のストレージバックエンドを使用する必要があります。

重要 Astra Controlレプリケーションでは、単一のストレージクラスを使用するアプリケーションがサポートされます。ネームスペースにアプリケーションを追加するときは、そのアプリケーションのストレージクラスがネームスペース内の他のアプリケーションと同じであることを確認してください。レプリケートされたアプリケーションにPVCを追加するときは、新しいPVCのストレージクラスがネームスペース内の他のPVCと同じであることを確認してください。

レプリケーション関係を設定

レプリケーション関係の設定には、次の作業が含まれます。

  • Astra ControlでアプリケーションSnapshotを作成する頻度を選択します(アプリケーションのKubernetesリソースと、アプリケーションの各ボリュームのボリュームSnapshotが含まれます)。

  • レプリケーションスケジュールの選択(Kubernetesリソースと永続ボリュームデータを含む)

  • Snapshotの作成時間の設定

手順
  1. Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。

  2. >[レプリケーション]*タブを選択します。

  3. [レプリケーションポリシーの設定]*を選択します。または、[アプリケーション保護]ボックスから[アクション]オプションを選択し、[レプリケーションポリシーの構成]を選択します。

  4. 次の情報を入力または選択します。

    • デスティネーションクラスタ:デスティネーションクラスタを入力します(ソースクラスタと同じでもかまいません)。

    • デスティネーションストレージクラス:デスティネーションONTAPクラスタのピアSVMを使用するストレージクラスを選択または入力します。ベストプラクティスとして、デスティネーションストレージクラスでソースストレージクラスとは別のストレージバックエンドを指定することを推奨します。

    • レプリケーションタイプAsynchronous は、現在使用可能な唯一のレプリケーションタイプです。

    • デスティネーションネームスペース:デスティネーションクラスタの新規または既存のデスティネーションネームスペースを入力します。

    • (任意)[Add namespace]を選択し、ドロップダウンリストからネームスペースを選択して、ネームスペースを追加します。

    • レプリケーション頻度:Astra ControlでSnapshotを作成してデスティネーションにレプリケートする頻度を設定します。

    • オフセット:Astra ControlでSnapshotを作成する時間(分)を設定します。オフセットを使用すると、他のスケジュールされた処理と競合しないようにすることができます。

      ヒント バックアップとレプリケーションのスケジュールをオフセットして、スケジュールの重複を回避します。たとえば、1時間ごとに1時間の最上部にバックアップを実行し、オフセットを5分、間隔を10分に設定してレプリケーションを開始するようにスケジュールを設定します。
  5. 次へ」を選択し、概要を確認して、「保存」を選択します。

    メモ 最初に、最初のスケジュールが実行される前にステータスに「app_mirror」と表示されます。

    Astra Controlが、レプリケーションに使用するアプリケーションSnapshotを作成。

  6. アプリケーションのスナップショットステータスを確認するには、[アプリケーション]>*[スナップショット]*タブを選択します。

    Snapshot名の形式は次のとおりです。 replication-schedule-<string>。Astra Controlは、レプリケーションに使用された最後のSnapshotを保持します。古いレプリケーションSnapshotは、レプリケーションが正常に完了すると削除されます。

結果

これにより、レプリケーション関係が作成されます。

Astra Controlは、関係を確立した結果として次のアクションを実行します。

  • デスティネーションにネームスペースを作成します(存在しない場合)。

  • 送信元アプリケーションのPVCに対応する宛先ネームスペースにPVCを作成します。

  • アプリケーションと整合性のある初期スナップショットを作成します。

  • 最初のSnapshotを使用して、永続ボリュームのSnapMirror関係を確立します。

[データ保護]*ページには、レプリケーション関係の状態とステータスが表示されます。
<Health status>|<Relationship life cycle state>

例:
正常|確立

レプリケーションの状態とステータスの詳細については、このトピックの最後を参照してください。

デスティネーションクラスタでレプリケートされたアプリケーションをオンラインにする(フェイルオーバー)

Astra Controlを使用すると、レプリケートされたアプリケーションをデスティネーションクラスタにフェイルオーバーできます。この手順 はレプリケーション関係を停止し、デスティネーションクラスタでアプリケーションをオンラインにします。ソースクラスタのアプリケーションが稼働していた場合、この手順 はそのアプリケーションを停止しません。

手順
  1. Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。

  2. >[レプリケーション]*タブを選択します。

  3. [アクション]メニューから*[フェイルオーバー]*を選択します。

  4. フェイルオーバーページで、情報を確認し、*フェイルオーバー*を選択します。

結果

フェイルオーバー手順が発生すると、次の処理が実行されます。

  • デスティネーションアプリケーションは、最新のレプリケートされたSnapshotに基づいて起動されます。

  • ソースクラスタとアプリケーション(動作している場合)は停止されず、引き続き実行されます。

  • レプリケーションの状態は「フェイルオーバー」に変わり、完了すると「フェイルオーバー」に変わります。

  • ソースアプリの保護ポリシーは、フェイルオーバー時にソースアプリに存在するスケジュールに基づいて、デスティネーションアプリにコピーされます。

  • ソースアプリで1つ以上のリストア後の実行フックが有効になっている場合、それらの実行フックはデスティネーションアプリに対して実行されます。

  • Astra Controlには、ソースクラスタとデスティネーションクラスタの両方のアプリケーションと、それぞれの健全性が表示されます。

フェイルオーバーしたレプリケーションを再同期します

再同期処理によってレプリケーション関係が再確立されます。関係のソースを選択して、ソースクラスタまたはデスティネーションクラスタにデータを保持することができます。この処理は、SnapMirror関係を再確立し、ボリュームのレプリケーションを任意の方向に開始します。

レプリケーションを再確立する前に、新しいデスティネーションクラスタ上のアプリケーションが停止されます。

メモ 再同期プロセスの間、ライフサイクルの状態は「Establishing」と表示されます。
手順
  1. Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。

  2. >[レプリケーション]*タブを選択します。

  3. [操作]メニューから*[再同期]*を選択します。

  4. 再同期(Resync)ページで、保持するデータを含むソースまたはデスティネーションのアプリケーションインスタンスを選択します。

    注意 デスティネーションのデータが上書きされるため、再同期元は慎重に選択してください。
  5. 続行するには、* Resync *を選択します。

  6. 「resync」と入力して確定します。

  7. 「* Yes、resync *」を選択して終了します。

結果
  • Replication(レプリケーション)ページに、レプリケーションステータスとしてEstablishing(確立)が表示されます。

  • Astra Controlは、新しいデスティネーションクラスタのアプリケーションを停止します。

  • SnapMirror resyncを使用して、指定した方向に永続的ボリュームのレプリケーションを再確立します。

  • [レプリケーション]ページに、更新された関係が表示されます。

アプリケーションのレプリケーションを反転する

これは、アプリケーションをデスティネーションストレージバックエンドに移動し、元のソースストレージバックエンドに引き続きレプリケートするという計画的な処理です。Astra Controlは、デスティネーションアプリケーションにフェイルオーバーする前に、ソースアプリケーションを停止してデスティネーションにデータをレプリケートします。

この状況では、ソースとデスティネーションを交換しようとしています。

手順
  1. Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。

  2. >[レプリケーション]*タブを選択します。

  3. [操作]メニューから*[逆レプリケーション]*を選択します。

  4. リバース・レプリケーションのページで情報を確認し、「リバース・レプリケーション」を選択して続行します。

結果

リバースレプリケーションの結果、次の処理が実行されます。

  • 元のソースアプリのKubernetesリソースのスナップショットが作成されます。

  • 元のソースアプリケーションのポッドは、アプリケーションのKubernetesリソースを削除することで正常に停止されます(PVCとPVはそのまま維持されます)。

  • ポッドがシャットダウンされると、アプリのボリュームのスナップショットが取得され、レプリケートされます。

  • SnapMirror関係が解除され、デスティネーションボリュームが読み取り/書き込み可能な状態になります。

  • アプリのKubernetesリソースは、元のソースアプリがシャットダウンされた後に複製されたボリュームデータを使用して、シャットダウン前のスナップショットから復元されます。

  • 逆方向にレプリケーションが再確立されます。

アプリケーションを元のソースクラスタにフェイルバックします

Astra Controlを使用すると、フェイルオーバー処理後に次の一連の処理を使用して「フェイルバック」を実現できます。このワークフローでは、レプリケーションの方向を元に戻すために、Astra Controlがアプリケーションの変更を元のソースアプリケーションにレプリケート(再同期)してからレプリケーションの方向を反転します。

このプロセスは、デスティネーションへのフェイルオーバーが完了した関係から開始し、次の手順を実行します。

  • フェイルオーバー状態から開始します。

  • 関係を再同期します。

  • レプリケーションを反転する。

手順
  1. Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。

  2. >[レプリケーション]*タブを選択します。

  3. [操作]メニューから*[再同期]*を選択します。

  4. フェイルバック処理の場合は、フェイルオーバーしたアプリケーションを再同期処理のソースとして選択します(フェイルオーバー後に書き込まれたデータは保持されます)。

  5. 「resync」と入力して確定します。

  6. 「* Yes、resync *」を選択して終了します。

  7. 再同期が完了したら、[データ保護(Data Protection)]>[レプリケーション(Replication)]タブの[アクション(Actions)]メニューから[*レプリケーションを反転(Reverse replication)]を選択します。

  8. リバース・レプリケーションのページで、情報を確認し、*リバース・レプリケーション*を選択します。

結果

このコマンドは、「resync」処理と「reverse relationship」処理の結果を組み合わせて、レプリケーションが再開された元のソースクラスタ上のアプリケーションを元のデスティネーションクラスタにオンラインにします。

アプリケーションレプリケーション関係を削除します

関係を削除すると、2つの異なるアプリケーション間に関係がなくなります。

手順
  1. Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。

  2. >[レプリケーション]*タブを選択します。

  3. [アプリケーションの保護]ボックスまたは関係図で、*[レプリケーション関係の削除]*を選択します。

結果

レプリケーション関係を削除すると、次の処理が実行されます。

  • 関係が確立されていても、アプリケーションがデスティネーションクラスタでオンラインになっていない(フェイルオーバーした)場合、Astra Controlは、初期化中に作成されたPVCを保持し、「空」の管理対象アプリケーションをデスティネーションクラスタに残します。また、作成されたバックアップを保持するためにデスティネーションアプリケーションを保持します。

  • アプリケーションがデスティネーションクラスタでオンラインになった(フェイルオーバーした)場合、Astra ControlはPVCと宛先アプリケーションを保持します。ソースとデスティネーションのアプリケーションは、独立したアプリケーションとして扱われるようになりました。バックアップスケジュールは、両方のアプリケーションで維持されますが、相互に関連付けられていません。 

レプリケーション関係のヘルスステータスと関係のライフサイクル状態

Astra Controlには、関係の健全性と、レプリケーション関係のライフサイクルの状態が表示されます。

レプリケーション関係のヘルスステータス

レプリケーション関係の健常性は、次のステータスで示されます。

  • 正常:関係が確立中または確立されており、最新のSnapshotが転送されました。

  • 警告:関係がフェイルオーバーされているかフェイルオーバーされています(そのためソースアプリは保護されなくなりました)。

  • * 重要 *

    • 関係が確立されているか、フェイルオーバーされていて、前回の調整が失敗しました。

    • 関係が確立され、新しいPVCの追加を最後に調整しようとしても失敗しています。

    • 関係は確立されていますが(成功したSnapshotがレプリケートされ、フェイルオーバーが可能です)、最新のSnapshotはレプリケートに失敗したか失敗しました。

レプリケーションのライフサイクル状態

次の状態は、レプリケーションのライフサイクルの各段階を表しています。

  • * Establishing *:新しいレプリケーション関係を作成中です。Astra Controlは、必要に応じてネームスペースを作成し、デスティネーションクラスタの新しいボリュームにPersistent Volumeクレーム(PVC;永続ボリューム要求)を作成し、SnapMirror関係を作成します。このステータスは、レプリケーションが再同期中であること、またはレプリケーションを反転中であることを示している可能性もあり

  • * established *:レプリケーション関係が存在します。Astra Controlは、PVCが使用可能であることを定期的にチェックし、レプリケーション関係をチェックし、アプリケーションのSnapshotを定期的に作成し、アプリケーション内の新しいソースPVCを特定します。その場合は、レプリケーションに含めるリソースがAstra Controlによって作成されます。

  • フェイルオーバー:Astra Controlは、SnapMirror関係を解除し、最後にレプリケートされたアプリケーションのSnapshotからアプリケーションのKubernetesリソースをリストアします。

  • フェイルオーバー:Astra Controlは、ソースクラスタからのレプリケーションを停止し、デスティネーションで最新の(成功した)レプリケートされたアプリケーションSnapshotを使用して、Kubernetesリソースをリストアします。

  • * resyncing *:Astra Controlは、SnapMirror resyncを使用して、再同期元の新しいデータを再同期先に再同期します。この処理では、同期の方向に基づいて、デスティネーション上の一部のデータが上書きされる可能性があります。Astra Controlは、デスティネーションネームスペースで実行されているアプリケーションを停止し、Kubernetesアプリケーションを削除します。再同期処理の実行中、ステータスは「Establishing」と表示されます。

  • リバース:は、元のソースクラスタへのレプリケーションを続行しながらアプリケーションをデスティネーションクラスタに移動する予定の処理です。Astra Controlは、ソースクラスタ上のアプリケーションを停止し、デスティネーションにデータをレプリケートしてから、デスティネーションクラスタにアプリケーションをフェイルオーバーします。リバースレプリケーションの間、ステータスは「Establishing」と表示されます。

  • 削除中

    • レプリケーション関係が確立されたものの、まだフェイルオーバーされていない場合は、レプリケーション中に作成されたPVCがAstra Controlによって削除され、デスティネーションの管理対象アプリケーションが削除されます。

    • レプリケーションがすでにフェイルオーバーされている場合、Astra ControlはPVCと宛先アプリケーションを保持します。