使用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三端:Astra三端22.10或更高版本必须位于使用ONTAP作为后端的源和目标Kubernetes集群上。
-
许可证:必须在源和目标ONTAP集群上启用使用数据保护包的ONTAP SnapMirror异步许可证。请参见 "ONTAP 中的SnapMirror许可概述" 有关详细信息 …
-
-
对等:
-
集群和SVM:ONTAP存储后端必须建立对等状态。请参见 "集群和 SVM 对等概述" 有关详细信息 …
确保两个ONTAP集群之间的复制关系中使用的SVM名称是唯一的。 -
Astra三端到子和SVM:对等远程SVM必须可供目标集群上的Astra三端到子使用。
-
-
Astra控制中心:
"部署Asta Control Center" 在第三个故障域或二级站点中、以实现无缝灾难恢复。 -
受管集群:必须将以下集群添加到Astra Control并由Astra Control进行管理、最好是在不同的故障域或站点上:
-
源Kubbernetes集群
-
目标Kubbernetes集群
-
关联的ONTAP集群
-
-
用户帐户:将ONTAP存储后端添加到Astra控制中心时、请应用具有"admin"角色的用户凭据。此角色具有访问方法
http
和ontapi
已在ONTAP 源集群和目标集群上启用。请参见 "管理ONTAP 文档中的用户帐户" 有关详细信息 …
-
-
Astra三端/ ONTAP配置:Astra控制中心要求您至少配置一个存储后端、以支持源集群和目标集群的复制。如果源集群和目标集群相同、则目标应用程序应使用与源应用程序不同的存储后端、以获得最佳故障恢复能力。
Astra Control复制支持使用单个存储类的应用程序。将应用程序添加到命名空间时、请确保该应用程序与命名空间中的其他应用程序具有相同的存储类。向复制的应用程序添加PVC时、请确保新PVC与命名空间中的其他PVC具有相同的存储类。 |
设置复制关系
设置复制关系涉及以下方面:
-
选择您希望Astra Control创建应用程序快照的频率(包括应用程序的Kubbernetes资源以及应用程序每个卷的卷快照)
-
选择复制计划(包括Kubernetes资源以及永久性卷数据)
-
设置创建快照的时间
-
从Astra Control左侧导航栏中、选择*应用程序*。
-
选择*数据保护*>*复制*选项卡。
-
选择*配置复制策略*。或者、从应用程序保护框中、选择操作选项并选择*配置复制策略*。
-
输入或选择以下信息:
-
目标集群:输入目标集群(可以与源集群相同)。
-
目标存储类:选择或输入在目标ONTAP集群上使用对等SVM的存储类。作为最佳实践、目标存储类应指向与源存储类不同的存储后端。
-
复制类型:
Asynchronous
是当前唯一可用的复制类型。 -
目标命名空间:为目标集群输入新的或现有的目标命名空间。
-
(可选)通过选择*添加命名空间*并从下拉列表中选择命名空间来添加其他命名空间。
-
复制频率:设置您希望Astra Control创建快照并将其复制到目标的频率。
-
Offset:设置从Astra Control创建快照的小时数开始的分钟数。您可能希望使用偏移量、以便它不会与其他计划的操作保持一致。
偏移备份和复制计划以避免计划重叠。例如、在每小时的前几个小时执行备份、并计划复制、以5分钟的偏移和10分钟的间隔开始。
-
-
选择*下一步*、查看摘要、然后选择*保存*。
首先、在执行第一个计划之前、状态将显示"app-mirror"。 Asta Control创建用于复制的应用程序快照。
-
要查看应用程序快照状态,请选择*Applications*>*Snapshot选项卡。
快照名称使用的格式
replication-schedule-<string>
。Asta Control会保留用于复制的最后一个快照。成功完成复制后、所有较早的复制快照都会被删除。
这将创建复制关系。
建立关系后、Astra Control将完成以下操作:
-
在目标上创建命名空间(如果不存在)
-
在目标命名空间上创建与源应用程序的PVC对应的PVC。
-
创建应用程序一致的初始快照。
-
使用初始快照为永久性卷建立SnapMirror关系。
"数据保护"页面显示复制关系的状态:
<Health status>|<Relationship life cycle state>
例如:
正常|已建立
在本主题末尾了解有关复制状态和状态的更多信息。
在目标集群上使复制的应用程序联机(故障转移)
使用Astra Control、您可以将复制的应用程序故障转移到目标集群。此操作步骤 将停止复制关系并使应用程序在目标集群上联机。如果应用程序正常运行、则此操作步骤 不会停止源集群上的应用程序。
-
从Astra Control左侧导航栏中、选择*应用程序*。
-
选择*数据保护*>*复制*选项卡。
-
从操作菜单中,选择*故障转移*。
-
在故障转移页面中、查看相关信息并选择*故障转移*。
故障转移操作步骤后会执行以下操作:
-
此时将根据最新复制的快照启动目标应用程序。
-
源集群和应用程序(如果运行正常)不会停止、并且将继续运行。
-
复制状态将更改为"故障转移"、然后在完成后更改为"故障转移"。
-
根据故障转移时源应用程序上的计划、源应用程序的保护策略将复制到目标应用程序。
-
如果源应用程序启用了一个或多个还原后执行挂钩、则会为目标应用程序运行这些执行挂钩。
-
Astra Control会在源集群和目标集群上显示应用程序及其各自的运行状况。
重新同步故障转移复制
重新同步操作将重新建立复制关系。您可以选择关系的源、以便在源或目标集群上保留数据。此操作将重新建立SnapMirror关系、以便按所选方向启动卷复制。
此过程会在重新建立复制之前停止新目标集群上的应用程序。
在重新同步过程中、生命周期状态将显示为"正在建立"。 |
-
从Astra Control左侧导航栏中、选择*应用程序*。
-
选择*数据保护*>*复制*选项卡。
-
从操作菜单中,选择*Resync*。
-
在重新同步页面中、选择包含要保留的数据的源或目标应用程序实例。
请仔细选择重新同步源、因为目标上的数据将被覆盖。 -
选择*重新同步*以继续。
-
键入"resync-"进行确认。
-
选择*是、重新同步*以完成。
-
复制页面将显示"正在建立"作为复制状态。
-
Astra Control将停止新目标集群上的应用程序。
-
Astra Control使用SnapMirror重新同步功能按选定方向重新建立永久性卷复制。
-
复制页面将显示已更新的关系。
反向复制应用程序
这是一项计划内操作、可将应用程序移至目标存储后端、同时继续复制回原始源存储后端。Asta Control会停止源应用程序并将数据复制到目标、然后再故障转移到目标应用程序。
在这种情况下、您将交换源和目标。
-
从Astra Control左侧导航栏中、选择*应用程序*。
-
选择*数据保护*>*复制*选项卡。
-
从操作菜单中,选择*反向复制*。
-
在反向复制页面中、查看相关信息并选择*反向复制*以继续。
反向复制会执行以下操作:
-
系统会为原始源应用程序的Kubbernetes资源创建一个快照。
-
通过删除原始源应用程序的Kubernetes资源(保留PVC和PV)、可以正常停止原始源应用程序的Pod。
-
关闭Pod后、将为应用程序的卷创建快照并进行复制。
-
SnapMirror关系将中断、从而使目标卷做好读/写准备。
-
此应用程序的Kubornetes资源将使用在初始源应用程序关闭后复制的卷数据从关闭前的快照中还原。
-
反向重新建立复制。
将应用程序故障恢复到原始源集群
使用Astra Control、您可以通过以下操作序列在故障转移操作后实现"故障恢复"。在此工作流中、Astra Control会在反转复制方向之前、将所有应用程序更改复制(重新同步)回原始源应用程序。
此过程从已完成故障转移到目标的关系开始、涉及以下步骤:
-
从故障转移状态开始。
-
重新同步此关系。
-
反转复制。
-
从Astra Control左侧导航栏中、选择*应用程序*。
-
选择*数据保护*>*复制*选项卡。
-
从操作菜单中,选择*Resync*。
-
对于故障恢复操作、请选择故障转移应用程序作为重新同步操作的源(在故障转移后保留写入的任何数据)。
-
键入"resync-"进行确认。
-
选择*是、重新同步*以完成。
-
重新同步完成后、在"Data Protection">"Replication"选项卡中、从"Actions"菜单中选择*反向复制*。
-
在反向复制页面中、查看相关信息并选择*反向复制*。
这将合并"重新同步"和"反向关系"操作的结果、以便在复制恢复到原始目标集群的情况下使应用程序在原始源集群上联机。
删除应用程序复制关系
删除此关系会导致出现两个独立的应用程序、它们之间没有任何关系。
-
从Astra Control左侧导航栏中、选择*应用程序*。
-
选择*数据保护*>*复制*选项卡。
-
从应用程序保护框或关系图中,选择*删除复制关系*。
删除复制关系后会执行以下操作:
-
如果已建立此关系、但此应用程序尚未在目标集群上联机(故障转移)、则Astra Control将保留初始化期间创建的PVC、在目标集群上保留一个"空"受管应用程序、并保留目标应用程序以保留可能已创建的任何备份。
-
如果应用程序已在目标集群上联机(故障转移)、则Astra Control会保留PVC和目标应用程序。源应用程序和目标应用程序现在被视为独立的应用程序。备份计划会同时保留在两个应用程序上、但不会彼此关联。
复制关系运行状况和关系生命周期状态
Astra Control显示关系的运行状况以及复制关系的生命周期状态。
复制关系运行状况
以下状态指示复制关系的运行状况:
-
正常:关系正在建立或已建立、并且最近的快照已成功传输。
-
警告:此关系正在进行故障转移或已进行故障转移(因此不再保护源应用程序)。
-
* 严重 *
-
此关系正在建立或故障转移、上次协调尝试失败。
-
已建立此关系、上次尝试协调添加新PVC失败。
-
已建立此关系(因此已成功复制快照、并且可以进行故障转移)、但最近的快照失败或无法复制。
-
复制生命周期状态
以下状态反映了复制生命周期的不同阶段:
-
正在建立:正在创建新的复制关系。Astra Control会根据需要创建命名空间、在目标集群上的新卷上创建永久性卷声明(PVC)、并创建SnapMirror关系。此状态还可以指示复制正在重新同步或反转复制。
-
已建立:存在复制关系。Astra Control会定期检查PVC是否可用、检查复制关系、定期创建应用程序快照并确定应用程序中的任何新源PVC。如果是、则Astra Control会创建资源以将其包括在复制中。
-
故障转移:Asta Control会中断SnapMirror关系、并从上次成功复制的应用程序快照还原应用程序的Kubernetes资源。
-
故障转移:Asta Control停止从源集群复制、使用目标上最新(成功)复制的应用程序快照、并还原Kubernetes资源。
-
正在重新同步:Astra Control使用SnapMirror重新同步将重新同步源上的新数据重新同步到重新同步目标。此操作可能会根据同步方向覆盖目标上的某些数据。Astra Control会停止在目标命名空间上运行的应用程序、并删除Kubernetes应用程序。在重新同步过程中、状态将显示为正在建立。
-
正在反转:是指在继续复制回原始源集群的同时将应用程序移动到目标集群的计划操作。Astra Control会停止源集群上的应用程序、将数据复制到目标、然后将应用程序故障转移到目标集群。在反向复制期间、状态显示为"正在 建立"。
-
正在删除:
-
如果已建立复制关系、但尚未进行故障转移、则Astra Control会删除复制期间创建的PVC、并删除目标受管应用程序。
-
如果复制已失败、则Astra Control会保留PVC和目标应用程序。
-