反转复制方向

可以反转复制方向以支持典型的双系统灾难恢复计划。此操作与上文介绍的断开连接操作类似，但需要额外在新的本地项目上配置复制操作，以便向源系统进行增量复制。完成此操作时不会在源系统上进行任何更改，但使用此操作的首次更新尝试会将源系统上的原始项目转换为一个复制数据包，并回滚自上次成功从该系统进行复制更新后所做的任何更改。

除了修改主数据副本和辅助数据副本的读写状态以外，该功能不会自动重定向生产工作负荷、对 IP 地址进行故障转移，或执行与灾难恢复故障转移相关的其他活动。

在将原始源项目转换为原始源系统（现在充当目标）上的复制数据包的过程中，作为当前正在反转的操作/数据包的一部分复制的共享资源将移动到新的复制数据包中，且不会导出。原始项目仍保留在本地集合中，但如果操作/数据包包含其所有的共享资源，则它最后可能会成为空的。反转共享资源级复制时，原始项目中的所有其他共享资源保持不变。

在建立了从一台 ZFSSA 到另一台 ZFSSA 的共享资源级复制后，反转目标设备上的复制会销毁复制调度表。然后，会在项目级别上创建一个复制操作，它包含正确的目标 ZFSSA，但无调度表。

如上文所述，该功能通常用于实施双系统灾难恢复配置，在这种配置中，主系统提供生产数据并将其复制到辅助或 DR 系统（通常位于另一数据中心），而后者准备在主站点发生灾难时接管生产通信。当主站点发生灾难时，必须将辅助站点的副本设为“主”副本，方法如下：将它设置为可写的，并将生产通信重定向到辅助站点。当主站点修复后，可以将辅助站点上累积的更改复制回主站点，且该站点可继续为生产工作负荷提供服务。

此类计划中的典型事件序列如下所述：

• 主系统正在为生产工作负荷提供服务，且正在向辅助系统进行复制。

• 发生了一个灾难，可能表示在主站点上发生了总系统故障。管理员在辅助站点上反转复制方向，并且将复制的共享资源导出到为了在主服务恢复后将数据复制回主站点而配置的一个新项目中。与此同时，生产工作负荷被重定向到辅助站点。

• 主站点重新联机后，管理员启动从辅助站点到主站点的复制更新。这会将主站点的副本转换为一个复制数据包，回滚自上次成功更新目标后（发生故障前）所做的任何更改。获得最新的主站点副本时，管理员将再次反转复制方向，使主站点上的副本具有可写性。生产通信被重定向到主站点。复制将恢复为从主站点到辅助站点，这就恢复了主副本和辅助副本之间的初始关系。

在反转数据包的复制方向时，强烈建议管理员先停止该项目从源的复制。如果在管理员反转项目的复制方向时复制更新正在进行，则管理员将无法得知在以前的目标 ZFSSA（现在是源 ZFSSA）上创建结果项目时使用的是哪个一致的复制快照。

在 BUI 中可通过以下方法来反转复制：导航到复制数据包（请参见上文），单击 "Replication"（复制）选项卡，然后单击 按钮。通过显示的对话框，管理员可以指定新本地项目的名称。

在 CLI 中可通过以下方法来反转复制：导航到复制数据包（参见上文），然后使用 reverse 命令。此命令接受一个用于指定新本地项目名称的可选参数。如果未指定参数，则将使用原始名称。

因为所有的本地共享资源都将导出，所以在反转数据包时将导出数据包中的所有共享资源，无论之前是否导出了这些共享资源（请参见上文）。如果复制的文件系统与系统上的其他文件系统之间存在挂载点冲突，则该反转操作将失败。在断开连接之前，必须通过重新配置相关共享资源的挂载点来解决这些冲突。由于此操作通常是恢复生产服务的关键路径的一部分，因此强烈建议您在首次设置系统时（而不是进行 DR 故障转移时）解决这些挂载点冲突。