综合分析上述三种方案，对于客户来说，停机都不可避免，不能满足客户不停机的硬指标。而且客户都需要不小的投资，获得的回报从上面的分析来看，都有很大不如意的地方，ROI不值。所以我们最后建议客户的方案是方案 4。

方案 4

主要是连通两个SAN，让主机都可以访问两个存储，然后在主机上写一个shell文件，在灾难发生时，系统管理员只需要one click执行该Shell文件就可以完成切换。该方案的架构图如下：

方案 4的优点：不需要停机；投资最小。

方案 4的缺点：仍然需要人工参与，不能做到100%自动化。

通过前面的具体分析，我们可以看到，一个DR方案设计需要全面细致的考虑，绝对不是靠厂商的售前技术力量用PPT就做出的方案，否则真到实施环节，就悔之晚矣（目标达不到，或投资打水漂）。

当然为什么在这个案例中，我们会碰到各种技术限制将我们陷入两难境地，最根本是客户的初始系统设计有很多不够完美的地方，不够灵活，投入运行后再要调整就有很多限制。主要的不完美地方如下，希望其他的客户在系统设计初期找对全系统真正专业的顾问一起参与：

1. Oracle的RAC一个非常好的feature就是在提供高可靠性的同时，将负荷分担在cluster内的多台机器上，提高系统利用率，节省投资。该案例中客户在正常状态下，只使用了一台服务器的处理能力，实在浪费。后来由于rp7640的处理能力不够升级到两台同配置的rp8640，浪费更大。采用分担负载的方案凭空增加一倍的处理能力也许就不需要升级主机了。当然作为芯片行业，可能会担心采用分担负载的方式，一旦故障发生，负载全部切换到一台机器时，处理能力不足造成连锁down机（据说某电力客户就发生过该情况，不过是否是RAC的缺陷不确定），不过完全可以将200mm和300mm两套系统组成一个大的RAC，正常情况下，每个应用的负载各自运行在一台主机上，这样三台主机构成的RAC就可以实现同样的高可靠性，相比生产环境，节省了一台主机。

2. 生产环境两个SAN互相隔离，冠冕堂皇的理由是系统安全，可是造成的存储孤岛限制了系统架构的灵活性。在同一个机房中还用昂贵的CA来同步数据，实在是不经济的做法。同一个机房也完全不能达到容灾的要求（真有火灾等天灾还不是一毁全毁）。

3. XP12000已经是企业级的高端存储，所有的部件都是双份的，不存在单点故障，无需采用两套XP，而且采用CA来同步数据，对于每一个XP来说，只有一半的磁盘容量是服务于业务系统的，数据冗余太大。

4. MES也是一个典型的OLTP应用，每次写入的数据并不会太多。而XP存储作为企业级的高端存储，完全用VG就可以将数据分散到多个控制器下的多个盘中，实现I/O的并发，再横向加上Strip条带化完全没有必要（主要原因是一开始设计系统时，对于某些应用的负载估计不足，XP上分配的主机端口不足造成性能不好，没有找到根本原因之前，想用Strip的方式提高并发，结果瓶颈不在于此，最后还是增加主机端口解决，但Strip加上后要撤销可不容易）

5. 整个系统设计中有很多点似乎被厂商忽悠而增大投资的嫌疑：4台主机两两RAC；用昂贵的CA在一个50米不到的距离内来实现数据同步，而且冗余一半的XP磁盘等。