容灾设计真实案例分析(2)

方案 2

采用HP的Metrocluster来实现200mm和300mm两套系统的自动切换，利用CA实现两个site的数据同步。该方案的系统架构图如下：

方案 2的优点：对于现有的硬件环境不需要调整，利用存储上的CA软件来实现数据同步对于服务器负载无影响。

方案 2的缺点：由于Metrocluster不支持Oracle RAC，在两个site间发生切换时，MESDB数据库需要reboot。另外由于要去掉RAC，需要系统停机1~2小时。这两点客户都无法接受。

方案 3

是由EMC提出的方案。在一个HP的Installbase里要实现容灾方案，EMC只能采用基于应用的办法。具体办法是增加一台新的存储（当然是EMC的啦），然后利用Oracle的Data Guard来同步数据。Data Guard对存储没有要求，对于服务器要求是相同的OS和相同的Oracle版本，所以服务器还必须是HP的（EMC也没有服务器啦，当然不会眼红）。

方案 3的优点：对于存储没有要求，厂商无关。

方案 3的缺点：由于Data Guard的数据同步是基于Oracle的Redo Log或Arch Log，增加了主机的负载，而且要通过网络来传递数据，消耗了带宽；当灾难发生时，所有客户端必须重新连接备份站点的主机，会有中断影响；Data Guard运作有两种方式，同步或异步，同步模式对于主站点的性能影响大（主站点必须得到备份站点的肯定回复才能进行下一步操作），而异步模式可能在灾难切换时丢数据；在最初始的数据同步阶段，仍然需要系统停机，当两边数据一致之后备份站点才能基于日志进行更新。