跳过导航链接
退出打印视图
| Oracle Solaris Cluster 系统管理指南 Oracle Solaris Cluster (简体中文)

搜索范围:

- 本文档
- 整个文档库

## 在群集内使用基于存储的数据复制

基于存储的数据复制使用安装在存储设备上的软件来管理群集或校园群集内的复制。此类软件是特定存储设备所特有的，不用于灾难恢复。配置基于存储的数据复制时，请参阅存储设备附带的相关文档。

根据所用的软件，您可以在基于存储的数据复制中使用自动故障转移或手动故障转移。Oracle Solaris Cluster 支持使用 Hitachi TrueCopy、Hitachi Universal Replicator 和 EMC SRDF 软件对复制数据进行手动故障转移和自动故障转移。

本节介绍了校园群集中使用的基于存储的数据复制。图 4-1 显示了在两个存储阵列间复制数据的双工作间配置样例。在此配置中，主存储阵列位于第一个工作间，并在此向两个工作间中的节点提供数据。此外，主存储阵列还为辅助存储阵列提供要复制的数据。

注 - 图 4-1 显示出法定设备在非复制卷上。复制的卷不能用作法定设备。

图 4-1 使用基于存储的数据复制的双工作间配置

使用 Hitachi TrueCopy 或 Hitachi Universal Replicator 可以在 Oracle Solaris Cluster 环境中同步或异步执行基于存储的数据复制，具体取决于您使用的应用程序的类型。如果要在校园群集中执行自动故障转移，请同步使用 TrueCopy。使用 EMC SRDF 进行的基于存储的同步复制受 Oracle Solaris Cluster 支持；对于 EMC SRDF，不支持异步复制。

请勿使用 EMC SRDF 的 Domino 模式或自适应复制模式。如果使用 Domino 模式，则当目标不可用时，会导致本地和目标 SRDF 卷对主机不可用。自适应复制模式通常用于数据迁移和数据中心移动，不建议用于灾难恢复。

如果已与远程存储设备断开连接，请确保不会通过将 `Fence_level` 指定为 `never` 或 `async` 来阻止主群集上正在运行的应用程序。如果指定 `Fence_level` 为 `data` 或 `status`，主存储设备将拒绝无法复制到远程存储设备的更新。

### 在群集内使用基于存储的数据复制的要求和限制

为确保数据完整性，请使用多路径和正确的 RAID 软件包。如果要使用基于存储的数据复制实现群集配置，请注意以下事项：

- 节点到节点的距离受 Oracle Solaris Cluster 光纤通道和互连基础结构的限制。要了解当前的限制和支持技术的更多信息，请联系您的 Oracle 服务提供商。

- 不要将复制卷配置为法定设备。应使任何法定设备位于共享的非复制卷中或使用法定服务器。

- 确保只有数据的主副本对群集节点可见。否则， 卷管理器可能尝试同时访问数据的主副本和辅助副本。有关控制数据副本可见性的相关信息，请参阅存储阵列附带的相关文档。

- EMC SRDF、Hitachi TrueCopy 和 Hitachi Universal Replicator 允许用户定义复制设备组。每个复制设备组需要具有相同名称的 Oracle Solaris Cluster 设备组。

- 某些应用程序特定数据可能不适合进行异步数据复制。请根据您对应用程序行为的了解来确定在存储设备间复制应用程序特定数据的最佳方式。

- 如果配置群集进行自动故障转移，请使用同步复制。

  有关配置群集以进行复制卷自动故障转移的说明，请参见管理基于存储的复制设备。

- 在群集内部进行复制时，SRDF、Hitachi TrueCopy 和 Hitachi Universal Replicator 不支持 Oracle Real Application Clusters (RAC)。连接到当前非主副本的节点将不具有写入权限。复制设备无法支持任何要求群集的所有节点都具有直接写入权限的可伸缩应用程序。

- 不支持 Oracle Solaris Cluster 软件的 Veritas Cluster Volume Manager (CVM) 和多属主 Solaris Volume Manager。

- 在 EMC SRDF 中，请勿使用 Domino 模式或自适应复制模式。有关更多信息，请参见在群集内使用基于存储的数据复制。

- 在 Hitachi TrueCopy 或 Hitachi Universal Replicator 中，请勿使用数据模式或状态模式。有关更多信息，请参见在群集内使用基于存储的数据复制。

### 在群集内使用基于存储的数据复制时的手动恢复注意事项

与所有校园群集一样，通常，使用基于存储的数据复制的群集在遇到单一故障时无需人为干预。但是，如果使用手动故障转移，又无法进入主存储设备所在的工作间（如图 4-1 所示），则双节点群集便会出现问题。剩下的节点无法保留法定设备，也无法作为群集成员进行引导。此时，需要对群集进行以下人为干预：

1. 您的 Oracle 服务提供商必须重新配置剩下的节点，使之作为群集成员进行引导。

2. 您或您的 Oracle 服务提供商必须将辅助存储设备的一个非复制卷配置为法定设备。

3. 您或您的 Oracle 服务提供商必须配置剩下的节点，使之将辅助存储设备用作主存储。这种重新配置可能涉及重新构建卷管理器卷、恢复数据或更改应用程序与存储卷的关联。

### 使用基于存储的数据复制时的最佳做法

当设置使用 Hitachi TrueCopy 或 Hitachi Universal Replicator 软件进行基于存储的数据复制的设备组时，请遵循以下做法：

- 请使用同步复制，以避免在主站点发生故障时可能丢失数据。

- `horcm` 配置文件中定义的 Oracle Solaris Cluster 全局设备组和 TrueCopy 复制组之间应存在一对一的关系。这样，两个组便可以作为一个单元在节点间移动。

- 不能在同一复制设备组中混用全局文件系统卷和故障转移文件系统卷，因为它们的控制方式不同。全局文件系统是通过设备配置系统 (Device Configuration System, DCS) 来控制的，而故障转移文件系统卷是通过 HAS+ 来控制的。每个文件系统的主节点可能是不同的节点，从而导致在应将哪个节点用作复制主节点这一问题上出现冲突。

- 所有 RAID 管理器实例均应启动并始终处于运行状态。

当使用 EMC SRDF 软件来进行基于存储的数据复制时，应使用动态设备而非静态设备。静态设备更改复制主副本需要几分钟，而这会影响故障转移时间。

版权所有 © 2000, 2011, Oracle 和/或其附属公司。 保留所有权利。 法律声明 |