SnapMirrorテクノロジを使用してアプリケーションをリモートシステムにレプリケート
変更を提案
PDF
Astra Controlを使用すると、NetApp SnapMirrorテクノロジの非同期レプリケーション機能を使用して、RPO（目標復旧時点）とRTO（目標復旧時間）の低いアプリケーションのビジネス継続性を構築できます。設定が完了すると、アプリケーションはデータやアプリケーションの変更をクラスタ間でレプリケートできるようになります。
バックアップ/リストアとレプリケーションの比較については、を参照してください "データ保護の概念"。
アプリケーションは、オンプレミスのみ、ハイブリッド、マルチクラウドなど、さまざまなシナリオでレプリケートできます。
-
オンプレミスサイト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クラスタ*：
-
* Trident *：ONTAPをバックエンドとして利用するソースとデスティネーションの両方のKubernetesクラスタに、Astra Tridentバージョン22.07以降が存在している必要があります。
-
ライセンス：Data Protection Bundleを使用するONTAP SnapMirror非同期ライセンスが、ソースとデスティネーションの両方のONTAPクラスタで有効になっている必要があります。を参照してください "ONTAP のSnapMirrorライセンスの概要" を参照してください。
-
-
ペアリング：
-
*クラスタとSVM *：ONTAPクラスタとホストSVMがペアリングされている必要があります。を参照してください "クラスタと SVM のピアリングの概要" を参照してください。
-
* TridentとSVM *：ペアリングされたリモートSVMが、デスティネーションクラスタのAstra Tridentで使用可能である必要があります。
-
-
* Astra Control Center *：
"Astra Control Centerを導入" シームレスなディザスタリカバリのための第3の障害ドメインまたはセカンダリサイト。 -
管理対象クラスタ：次のクラスタをAstra Controlに追加して管理する必要があります（理想的には障害ドメインやサイトが異なる場合）。
-
ソースKubernetesクラスタ
-
デスティネーションKubernetesクラスタ
-
関連付けられているONTAPクラスタ
-
-
ユーザアカウント：ONTAPストレージバックエンドをAstra Control Centerに追加する場合は、「admin」ロールのユーザクレデンシャルを適用します。このロールにはアクセス方法があります
httpおよびontapiONTAP ソースとデスティネーションの両方のクラスタで有効にします。を参照してください "ONTAP ドキュメントの「ユーザーアカウントの管理」を参照してください" を参照してください。
-
-
* Astra Trident / ONTAPの設定*：Astra Control Centerでは、ソースとデスティネーションの両方のクラスタのレプリケーションをサポートするストレージクラスを少なくとも1つ設定する必要があります。
|
Astra Controlレプリケーションでは、単一のストレージクラスを使用するアプリケーションがサポートされます。ネームスペースにアプリケーションを追加するときは、そのアプリケーションのストレージクラスがネームスペース内の他のアプリケーションと同じであることを確認してください。レプリケートされたアプリケーションにPVCを追加するときは、新しいPVCのストレージクラスがネームスペース内の他のPVCと同じであることを確認してください。 |
レプリケーション関係を設定
レプリケーション関係の設定には、次の作業が含まれます。
-
Astra ControlでのアプリケーションSnapshotの作成頻度の選択（アプリケーションのKubernetesリソースと、アプリケーションの各ボリュームのボリュームSnapshotを含む）
-
レプリケーションスケジュールの選択（Kubernetesリソースと永続ボリュームデータを含む）
-
Snapshotを作成する時刻を設定します
-
Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。
-
［アプリケーション］ページで、［データ保護］>［レプリケーション］タブを選択します。
-
［データ保護］＞［レプリケーション］タブで、［レプリケーションポリシーの設定］を選択します。または、[アプリケーション保護]ボックスから[アクション]オプションを選択し、[レプリケーションポリシーの構成]を選択します。
-
次の情報を入力または選択します。
-
デスティネーションクラスタ：ソースとは異なるデスティネーションクラスタを入力してください。
-
デスティネーションストレージクラス：デスティネーションONTAP クラスタでペアリングされているSVMを使用するストレージクラスを選択または入力します。
-
レプリケーションタイプ：現在使用できるレプリケーションタイプは「非同期」のみです。
-
デスティネーションネームスペース：デスティネーションクラスタの新規または既存のデスティネーションネームスペースを入力します。
-
（任意）[Add namespace]を選択し、ドロップダウンリストからネームスペースを選択して、ネームスペースを追加します。
-
レプリケーション頻度：Snapshotを作成してデスティネーションにレプリケートする頻度を指定します。
-
オフセット：Astra Controlでスナップショットを作成する時間の上部から分数を設定します。オフセットを使用すると、他のスケジュールされた処理と競合しないようにすることができます。
バックアップとレプリケーションのスケジュールをオフセットして、スケジュールの重複を回避します。たとえば、1時間ごとに1時間の最上部にバックアップを実行し、オフセットを5分、間隔を10分に設定してレプリケーションを開始するようにスケジュールを設定します。
-
-
「次へ」を選択し、概要を確認して、「保存」を選択します。
最初に、最初のスケジュールが実行される前にステータスに「app_mirror」と表示されます。 Astra Control：レプリケーションに使用するアプリケーションSnapshotを作成
-
アプリケーションのスナップショットステータスを表示するには、アプリケーション>*スナップショット*タブを選択します。
Snapshot名はの形式を使用します
replication-schedule-<string>。Astra Controlは、レプリケーションに使用された最後のSnapshotを保持古いレプリケーションSnapshotは、レプリケーションが正常に完了すると削除されます。
これにより、レプリケーション関係が作成されます。
Astra Controlは、関係を確立した結果として次のアクションを実行します。
-
デスティネーションにネームスペースを作成します（存在しない場合）。
-
送信元アプリケーションのPVCに対応する宛先ネームスペースにPVCを作成します。
-
アプリケーションと整合性のある最初のSnapshotを作成します。
-
初期Snapshotを使用して、永続ボリュームのSnapMirror関係を確立します。
[Data Protection]ページには、レプリケーション関係の状態とステータスが表示されます。
<Health status>|<Relationship life cycle state>
例：
正常|確立
レプリケーションの状態とステータスの詳細については、このトピックの最後を参照してください。
デスティネーションクラスタでレプリケートされたアプリケーションをオンラインにする（フェイルオーバー）
Astra Controlを使用すると、レプリケートされたアプリケーションをデスティネーションクラスタにフェイルオーバーできます。この手順 はレプリケーション関係を停止し、デスティネーションクラスタでアプリケーションをオンラインにします。ソースクラスタのアプリケーションが稼働していた場合、この手順 はそのアプリケーションを停止しません。
-
Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。
-
［アプリケーション］ページで、［データ保護］>［レプリケーション］タブを選択します。
-
[データ保護（Data Protection）]>[複製（Replication）]タブの[アクション（Actions）]メニューから、[フェールオーバー*（フェールオーバー*）]を選択し
-
フェイルオーバーページで、情報を確認し、*フェイルオーバー*を選択します。
フェイルオーバー手順が発生すると、次の処理が実行されます。
-
デスティネーションクラスタで、レプリケートされた最新のSnapshotに基づいてアプリケーションが起動されます。
-
ソースクラスタとアプリケーション（動作している場合）は停止されず、引き続き実行されます。
-
レプリケーションの状態は「フェイルオーバー」に変わり、完了すると「フェイルオーバー」に変わります。
-
ソースアプリの保護ポリシーは、フェイルオーバー時にソースアプリに存在するスケジュールに基づいて、デスティネーションアプリにコピーされます。
-
ソースアプリで1つ以上のリストア後の実行フックが有効になっている場合、それらの実行フックはデスティネーションアプリに対して実行されます。
-
Astra Controlには、ソースクラスタとデスティネーションクラスタの両方のアプリケーションと、それぞれの健全性が表示されます。
フェイルオーバーしたレプリケーションを再同期します
再同期処理によってレプリケーション関係が再確立されます。関係のソースを選択して、ソースクラスタまたはデスティネーションクラスタにデータを保持することができます。この処理は、SnapMirror関係を再確立し、ボリュームのレプリケーションを任意の方向に開始します。
レプリケーションを再確立する前に、新しいデスティネーションクラスタ上のアプリケーションが停止されます。
|
|
再同期プロセスの間、ライフサイクルの状態は「Establishing」と表示されます。 |
-
Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。
-
［アプリケーション］ページで、［データ保護］>［レプリケーション］タブを選択します。
-
[データ保護（Data Protection）]>[レプリケーション（Replication）]タブの[アクション（Actions）]メニューから、[*再同期（Resync *）]を
-
再同期（Resync）ページで、保持するデータを含むソースまたはデスティネーションのアプリケーションインスタンスを選択します。
デスティネーションのデータが上書きされるため、再同期元は慎重に選択してください。 -
続行するには、* Resync *を選択します。
-
「resync」と入力して確定します。
-
「* Yes、resync *」を選択して終了します。
-
Replication（レプリケーション）ページに、レプリケーションステータスとしてEstablishing（確立）が表示されます。
-
Astra Controlは、新しいデスティネーションクラスタのアプリケーションを停止します。
-
SnapMirror resyncを使用して、指定した方向に永続的ボリュームのレプリケーションを再確立します。
-
[レプリケーション]ページに、更新された関係が表示されます。
アプリケーションのレプリケーションを反転する
元のソースクラスタへのレプリケートを続行したまま、アプリケーションをデスティネーションクラスタに移動する計画的処理です。Astra Controlは、ソースクラスタ上のアプリケーションを停止し、デスティネーションにデータをレプリケートしてから、デスティネーションクラスタにアプリケーションをフェイルオーバーします。
この状況では、ソースとデスティネーションを交換しようとしています。元のソースクラスタが新しいデスティネーションクラスタになり、元のデスティネーションクラスタが新しいソースクラスタになります。
-
Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。
-
［アプリケーション］ページで、［データ保護］>［レプリケーション］タブを選択します。
-
[データ保護（Data Protection）]>[レプリケーション（Replication）]タブの[アクション（Actions）]メニューから、[レプリケーションを反転（Reverse replication）]を選択します
-
リバース・レプリケーションのページで情報を確認し、「リバース・レプリケーション」を選択して続行します。
リバースレプリケーションの結果、次の処理が実行されます。
-
Snapshotは、元のソースアプリケーションのKubernetesリソースから作成されます。
-
元のソースアプリケーションのポッドは、アプリケーションのKubernetesリソースを削除することで正常に停止されます（PVCとPVはそのまま維持されます）。
-
ポッドがシャットダウンされると、アプリケーションのボリュームのSnapshotが作成されてレプリケートされます。
-
SnapMirror関係が解除され、デスティネーションボリュームが読み取り/書き込み可能な状態になります。
-
アプリケーションのKubernetesリソースは、元のソースアプリケーションのシャットダウン後にレプリケートされたボリュームデータを使用して、シャットダウン前のSnapshotからリストアされます。
-
逆方向にレプリケーションが再確立されます。
アプリケーションを元のソースクラスタにフェイルバックします
Astra Controlを使用すると、フェイルオーバー処理後に次の一連の処理を使用して「フェイルバック」を実現できます。このワークフローでは、元のレプリケーション方向を復元するために、レプリケーションの方向を反転する前に、Astra Controlによってアプリケーションの変更が元のソースクラスタにレプリケート（再同期）されます。
このプロセスは、デスティネーションへのフェイルオーバーが完了した関係から開始し、次の手順を実行します。
-
フェイルオーバー状態から開始します。
-
関係を再同期します。
-
レプリケーションを反転する。
-
Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。
-
［アプリケーション］ページで、［データ保護］>［レプリケーション］タブを選択します。
-
[データ保護（Data Protection）]>[レプリケーション（Replication）]タブの[アクション（Actions）]メニューから、[*再同期（Resync *）]を
-
フェイルバック処理の場合は、フェイルオーバーしたアプリケーションを再同期処理のソースとして選択します（フェイルオーバー後に書き込まれたデータは保持されます）。
-
「resync」と入力して確定します。
-
「* Yes、resync *」を選択して終了します。
-
再同期が完了したら、[データ保護（Data Protection）]>[レプリケーション（Replication）]タブの[アクション（Actions）]メニューから[*レプリケーションを反転（Reverse replication）]を選択します。
-
リバース・レプリケーションのページで、情報を確認し、*リバース・レプリケーション*を選択します。
このコマンドは、「resync」処理と「reverse relationship」処理の結果を組み合わせて、レプリケーションが再開された元のソースクラスタ上のアプリケーションを元のデスティネーションクラスタにオンラインにします。
アプリケーションレプリケーション関係を削除します
関係を削除すると、2つの異なるアプリケーション間に関係がなくなります。
-
Astra Controlの左ナビゲーションから、「アプリケーション」を選択します。
-
［アプリケーション］ページで、［データ保護］>［レプリケーション］タブを選択します。
-
[データ保護]>[レプリケーション]タブの[アプリケーション保護]ボックスまたは関係図で、[レプリケーション関係の削除*]を選択します。
レプリケーション関係を削除すると、次の処理が実行されます。
-
関係が確立されていても、アプリケーションがデスティネーションクラスタでオンラインになっていない（フェイルオーバーした）場合、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によって作成されます。
-
フェイルオーバー：SnapMirror関係が解除され、アプリケーションのKubernetesリソースが最後にレプリケートされたアプリケーションのSnapshotからリストアされます。
-
*フェイルオーバーした場合：Astra Controlは、ソースクラスタからのレプリケーションを停止し、デスティネーションでレプリケートされた最新の（成功した）アプリケーションSnapshotを使用して、Kubernetesリソースをリストアします。
-
* resyncing *：Astra Controlは、SnapMirror resyncを使用して、再同期元の新しいデータを再同期先に再同期します。この処理では、同期の方向に基づいて、デスティネーション上の一部のデータが上書きされる可能性があります。Astra Controlは、デスティネーションネームスペースで実行されているアプリケーションを停止し、Kubernetesアプリケーションを削除します。再同期処理の実行中、ステータスは「Establishing」と表示されます。
-
リバース：は、元のソースクラスタへのレプリケーションを続行しながらアプリケーションをデスティネーションクラスタに移動する予定の処理です。Astra Controlは、ソースクラスタ上のアプリケーションを停止し、デスティネーションにデータをレプリケートしてから、デスティネーションクラスタにアプリケーションをフェイルオーバーします。リバースレプリケーションの間、ステータスは「Establishing」と表示されます。
-
削除中：
-
レプリケーション関係が確立されたものの、まだフェイルオーバーされていない場合は、レプリケーション中に作成されたPVCがAstra Controlによって削除され、デスティネーションの管理対象アプリケーションが削除されます。
-
レプリケーションがすでにフェイルオーバーされている場合、Astra ControlはPVCと宛先アプリケーションを保持します。
-