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