51CTO下载-灾与备份知识方面new.docVIP

PAGE PAGE 22 容灾备份系统建设要预先考虑的六大因素 　　容灾体系需要现有的基础设施状况，如现有异地传输网络的状况、现有主机系统和存储系统状况、现有生产环境的变动能力等等，体现在考虑因素上就是以下几点…… 　　容灾体系需要现有的基础设施状况，如现有异地传输网络的状况、现有主机系统和存储系统状况、现有生产环境的变动能力等等，体现在考虑因素上就是以下几点： 　　1.是否是低带宽特征，如果是则需要考虑具有带宽优化的技术实现 　　2.是否是异构系统?如果是则需要考虑异构的灾备体系 　　3.成本。权衡和比较不同灾备实现的成本，这里会产生很大的差异。 　　4.灾备系统是否对于生产系统产生很大的变动?有时候，这往往是致命的。 　　5.灾难的防御范围。除了人们已知的各类自然灾害、设备故障外，是否需要防范人为的数据篡改或丢失?如果是，所采用的技术就需要更为全面、功能覆盖面更为广泛。 　　6.工程实施过程。实施是否简单、维护过程是否简单往往决定了系统今后的维护和运营成本和对生产系统的影响。 　　容灾建设的要素还有很多，全面考虑业务连续性体系的每一个方面，抓住最为重要的环节，进行深入而细致的研究，就能够使有限的资金发挥更大的能量，达到事半功倍的效果。 容灾设计真实案例分析 DR(Disaster Recovery)系统容灾和BC(Business Continuity)业务连续性解决方案是业界基础架构Infrastructure方面的一个主要解决方案，各大存储硬件和软件公司都有自己的解决方案，总的来说，分为基于存储、服务器、以及软件应用三种方式或者相互组合。因为通常来说，容灾解决方案都会在业务系统已经投入运行一段时间后，由于重要性的不断增加才提上日程，所以建设一个容灾系统必须完善地考虑对现有系统的综合影响，仔细设计，否则会产生各种各样的麻烦和困难。下面就和大家分享一个真实的案例。 　　客户是一家在全球芯片行业排名靠前的外资企业，在中国拥有200mm和300mm两条生产线，每条生产线都有自己的MES(制造执行系统)系统。其中数据库MESDB是重中之重，采用 Oracle RAC来实现高可靠性，跑在两台满配的HP rp7640上，后升级到rp8640，存储系统也采取了HP高端的XP12000。每个系统的两台主机通过自己的 SAN连接到自己的XP12000上，两台XP12000通过 CA(continuous access，类似EMC的SRDF)软件同步对方的MESDB数据库，防范万一XP12000故障，数据不丢失。系统架构图如下： 　　 　　由于是芯片企业，系统可靠性是第一位的，一旦停机损失惨重(每小时的损失高达100万美金，主要是停产的产品销售额和高昂机器设备的折旧)，所以在 IT系统上是非常舍得投入的。虽然采用了 RAC，但负载全部集中在其中一台机器上，采购两台一样配置的机器加RAC就是为了在down机时，能零时间切换到另外一台机器上。 　　从上图可以看出，200mm和300mm的MES系统互相隔离，两个SAN也没有连接起来。客户的应用部门认为，万一300mm的存储XP12000坏掉，虽然在200mm的XP12000系统上仍然有数据，但是应用并不能自动切换来访问，所以提出了系统容灾的项目。由于系统大部分是HP的，当然HP被邀请提交解决方案。另外客户在其他的系统上还使用了EMC的Symmetrix，有竞争才能获得更好的价格，同时EMC也对这样一个大客户虎视眈眈，所以EMC也参与了方案提交。最后总共提交了三个方案： 　　方案 1：HP Campuscluster + RAC 　　方案 2：HP Metrocluster+CA 　　方案 3：Oracle data guard 　　方案 1 　　采用HP的Campuscluster来实现200mm和300mm两套系统的自动切换，利用Mirrordisk实现两个site的数据同步。该方案的系统架构图如下： 　　 方案 1的优点：支持Oracle RAC，可以实现在灾难时，零时间切换到另外一个site。实施不需要停机。 　　方案 1的缺点：不支持CA，浪费现有投资;需要将两个SAN连接起来，让所有的Server可以访问两个存储，主机利用Mirrordisk同时写两边的存储，对主机的性能有影响。 　　本来这是一个不错的方案，但是由于XP在LUN上已经配置了条带化Strip(不知道是谁出的主意)，Mirrordisk不支持，需要去掉strip，重新划卷，然后重新安装Oracle，从磁带备份恢复数据。这样不但需要停机1天以上，而且风险极大(客户的磁带备份重来没有做过恢复测试)，万一数据无法恢复将变成一个大事故。 　　方案 2 　　采用HP的Metrocluster来实