总结---基于软件架构的双活数据中心建设方案深入探讨

字数 15406阅读 7336评论 0赞 11

在上期活动（双活数据中心建设系列之--基于SVC的三种主流双活数据中心架构深入探讨）中，我们深入探讨了基于IBM SVC的三种主流双活数据中心架构，分别是SVC Stretch Cluster、SVC HyperSwap和SVC Local VDM+SVC PPRC，并围绕这三种架构进行了详细深入的特性挖掘和方案对比。
上述三种方案主要从跨中心的存储的双活角度，设计出双活数据中心的基础存储架构，存储对于数据库系统来说通常都是必要的，但对于应用系统来说是可有可无的，尤其是在互联网时代，号召的是横向扩展和弹性伸缩的应用系统架构，所以在整个双活数据中心的角度来看，上述三种方案的适用范围和灵活度都有一定的限度，另外，在OLTP数据库双活方面，基于存储的双活方案仍需要结合并行DB等软件双活方案，才能真正发挥该方案的优势。
基于此，软件架构的跨中心双活方案也是非常值得探讨的，所以本期活动我们围绕着“软件架构的双活数据中心”这一双活数据中心建设方案进行了深入的探讨。
活动讨论之前，笔者对一些相关知识点进行了粗浅的分享，内容如下：
1、基于软件架构的双活数据中心建设方案深入探讨（GPFS部分）
2、基于软件架构的双活数据中心建设方案深入探讨(并行Oracle部分) ")
3、基于软件架构的双活数据中心建设方案深入探讨(并行DB2部分)")
4、基于软件架构的双活数据中心建设方案深入探讨(整体架构部分)")
活动讨论会上，大家踊跃发言，特别感谢孙伟光，pysx0503，bryan_sd，mmsc5166，lzx660927，陈宇，zhanghaiyang，funtest，tianshizuoyi，libai21，王巧雷，sxliuxianlin，张文正等社区会员提出了许多宝贵的观点和意见，现在笔者将各类议题观点和各类问题及回答进行梳理总结，如有疏漏，还请不吝赐教。
主要分为五个部分：
一、整体双活架构设计方面
二、双活数据库方面
三、GPFS双活方面
四、双活数据中心前提、需求、问题及影响方面
五、双活架构实现过程方面

一、整体双活架构设计方面

【核心议题】采用软件架构的双活数据中心还是虚拟化存储架构双活数据中心?
【观点一】
双活有很多种理解和实现方式。
选择哪种技术路线也要看用户自身的IT环境，有的IT环境天然就具备了双活的基础。有的IT环境需要进行大量的整改。
底层基础决定上层建筑。不管是软件架构的双活数据中心还是虚拟化存储架构双活数据中心
【观点二】
双活数据中心，牵涉到各个层面的双活，存储级别、数据库级别、网络级别、应用级别，每个级别都利用不同的技术手
段，您指的软件架构和虚拟化存储架构还是太粗了！没法具体给您答复！
【观点三】
不好意思，可能议题的意思不够清晰，这个议题的意思是要大家一起讨论下，双活数据中心的存储基础架构的双活是采
用存储层面的、还是基于软件层面的。比如存储层面的可以用存储网关的双活，或者高端存储的双活，在存储底层就实现了两个站点同时的数据读写，而软件架构的双活，可以用并行文件系统的方式实现，比如GPFS，可以做两个中心NSD的复制，但是是通过网络的方式实时复制保持同步，网络采用INFINIBAND网络、万兆或者ROCE网络等，同步的性能也不比SAN交换机慢，甚至INFINIBAND是40GB，还强于SAN。大家可以从这个角度说说自己的看法。
【观点四】
关于双活中心基础存储架构的建设是采用软件架构还是虚拟化存储或者底层存储架构，简要对比如下：
1.实现方式方面：
底层存储自带的双活技术其实和软件方式来实现存储的双活其实从最基本的原理上都差不多，底层存储也是靠存储的软
件来实现双活，而软件的方式只不过将该软件的方式移至了主机端，消耗了主机的内存和CPU。
2.网络方面：
同步的网络一个是SAN网络，一个是TCP/IP网络，TCP/IP网络发展到现在，高速互联网无论从带宽上海市速率上，都有很大的提升，甚至超越了SAN网络，如INFINIBAND网络，带宽高达40GB，所以同步网络是差不多的。
3.性价比方面：
底层存储的双活要么采用高端存储的功能，如DS8000+HYPERSWAP技术，要么采用存储虚拟化的双活功能，如SVC ESC、SVC HYPERSWAP或者VPLEX METRO。性能较好，但价格昂贵。而软件架构的方式，ASM或者GPFS等并行文件系统就可以实现，价格便宜，主机提供给GPFS的缓存越大，性能也会越好，这种方式性价比高一点。
所以综合对比来看，采用底层存储的方式可靠性和稳定性更高，采用软件架构的方式性价比更高。更多的时候选择双活的方式我觉得最后决定的更多的是价格和业务的重要性，双活的地域性，两种双活的方式在不同的环境，不同的资金投入下也会有不同的人选择。有些时候有些企业资金紧张，可选择的方案也被迫受限。
【核心议题】双活数据中心下的应用负载架构如何设计？
【观点一】
应用双活分2个层面：应用程序双活和数据库双活（ADG）。应用负载这块我们是使用DNS进行引流负载，分发到不同的数据中心，引流的规则是根据业务逻辑的相关数据来的，采用F5进行L7负载。
【观点二】
拿这张架构图，举个例子：

架构1.JPG

1.这张架构图，包含了域名服务器，它的作用是负责域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它将用户的请求分散到两个站点的多台服务器上。另外我们在设计的时候，有两个需要注意的点：
一是需要增加DNS高可用，因为所有的请求都是由DNS进行域名解析和映射的，所以重要性不言而喻，必须要增加一台备机，在主DNS故障时，可以立即接管；
二是需要考虑DNS共用的问题，可以搭建两套DNS，一套用来解析站点外部的访问请求，另一套用来解析站点内部的访问请求。外部请求用域名方式，当发起外部请求时，DNS解析之后可将请求均衡分发至站点A和站点B的应用节点；内部应用与应用之间的请求也统一用域名的方式，当发起内部请求时，DNS解析之后也可将请求均衡分发至站点A和站点B的应用节点。这样就实现了两个站点所有应用节点负载均衡的目的，然而为了更高效、丰富的均衡功能，需要专用的DNS服务器，来实现站点均衡的可靠性，比如说负载的权重，监控负载的状态，会话的保持等等。
2.这张架构图中的应用负载服务器，这里有三个方面需要说明。
架构方面：站点A为主备两台应用负载，站点B为主应用负载，三台应用负载搭建主主备的集群模式，实现流量组1在站点A运行，流量组2在站点B运行，DNS将请求均衡分散至流量组1和流量组2，最终实现双数据中心应用负载均衡的目的；
高可用方面：三台应用负载组成的主主备集群，可实现故障自动切换和流量资源转移，加强了整体负载均衡的可靠性；
应用形式方面：通常采用的是反向代理的负载均衡，因为其调度策略比较丰富，例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。并发处理能力要求高，反向代理服务器可以监控后端服务器，比如系统负载，响应时间，是否可用，TCP连接数，流量等。从而根据这些数据调整负载均衡的策略。反向代理服务器可以让用户在一次会话周期内的所有请求转发到一台特定的后端服务器上（会话保持），这样的好处一是保持会话的本地访问，二是防止后端服务器的动态内存、缓存的资源浪费。
【核心议题】双活数据中心基础软件架构如何选择？企业常见的分布式文件系统GPFS-FPO、HDFS、Ceph对比
【观点一】
这里面只对IBM GPFS有使用经验，GPFS作为软件定义存储概念的先驱，在V3.5版本后，针对大数据，云计算，RELEASE FPO特性。批量的PC SERVER本地盘组成的共享文件系统可用性非常高。双活数据中心基础软件架构，也就是基于软件的存储架构，在企业并行文件系统这块，我觉得还是首选GPFS。GPFS-FPO、HDFS、Ceph都是分布式文件系统的代表。
【观点二】
HDFS是开源的分布式文件系统，是专门为Hadoop这样的大数据计算而生的。在处理离线批量的大数据上，有着天然的优
势。但是HDFS处理小的、海量文件就力不从心。而它的读写方式是一写多读，并行写是不适合的。
Ceph也是开源的，功能上很强大，既可以支持对象存储、又可以支持块存储、还可以支持文件系统，可谓样样都可以拿的出手，但是Ceph在对象存储这一块，又比不过SWIFT，文件系统的可靠性上又比不过GPFS，最适合的领域还是块存储方面，结合OPENSTACK，作为OPENSTACK Cinder的后端存储非常适合。
GPFS是老牌的商用文件系统，自GPFS3.5版本以来，开始推出了GPFS-FPO，这是基于无共享架构的分布式文件系统，在实时并发文件系统存储这块更具优势。
【观点三】
上图说话吧：

1704281448bce973c4574b5cb2.png

1704281449440411d71278623e.png

【问题】两种方式（采用软件架构或者虚拟化存储架构）的可靠性及性价比对比？
从可靠性来说，我觉得基于存储实现双活是否可靠性更高一些？毕竟它更接近底层。另外从性价比考虑，哪个更好一些？
【答复】关于双活中心基础存储架构的建设是采用软件架构还是虚拟化存储或者底层存储架构，简要对比如下：
1.实现方式方面：底层存储自带的双活技术其实和软件方式来实现存储的双活其实从最基本的原理上都差不多，底层存储也是靠存储的软件来实现双活，而软件的方式只不过将该软件的方式移至了主机端，消耗了主机的内存和CPU。
2.网络方面：同步的网络一个是SAN网络，一个是TCP/IP网络，TCP/IP网络发展到现在，高速互联网无论从带宽上海市速率上，都有很大的提升，甚至超越了SAN网络，如INFINIBAND网络，带宽高达40GB，所以同步网络是差不多的。
3.性价比方面：底层存储的双活要么采用高端存储的功能，如DS8000+HYPERSWAP技术，要么采用存储虚拟化的双活功能，如SVC ESC、SVC HYPERSWAP或者VPLEX METRO。性能较好，但价格昂贵。而软件架构的方式，ASM或者GPFS等并行文件系统就可以实现，价格便宜，主机提供给GPFS的缓存越大，性能也会越好，这种方式性价比高一点。
所以综合对比来看，采用底层存储的方式可靠性和稳定性更高，采用软件架构的方式性价比更高。
【问题】双活数据中心的一个站点的所有应用节点故障，会不会造成应用负载分发也出现问题？有什么避免措施吗？
【答复】不会的，可以通过应用负载或者专用域名服务器的策略进行控制的。
应用负载有专门的健康检查措施，会每隔一段时间去检查一次应用节点的健康状态，检查措施有很多种类，如端口监控
：TCP、TCP_HALF_OPEN方式等，HTTP监控：HTTP探测。当应用负载通过健康检查到该应用不健康，就立即将该节点置为offline，所有请求就不会再分发到该节点。保证100%的应用请求成功。
但是有一种可能性，如健康检查没配置合理，或者应用节点是HANG住，但依旧可以通过健康检查。这时应用负载时不会
将应用节点的状态置为offline的。这时就需要合理的负载均衡策略，通常这种情况下最小连接数的策略是不合理的，
否者所有连接都会发到这个故障节点，应用100%不可用，最优的策略应该是轮询，保证N-1/N的可用性。

二、双活数据库方面

【核心议题】OLTP下的DB2 PureScale VS ORACLE RAC对比探讨
在OLTP并行DB的解决方案中，DB2 PureScale 和ORACLE RAC是很好的选择，但是该如何选择呢?他们的优势和不足都体现在哪？关于这个话题，大家可以尽情提出自己的看法和观点。希望借助大家的讨论，让我们更深入的了解这两种并行DB方案。
【观点一】
我不懂DB2，只从oracle的角度上来说一下吧。
1、实质上，oracle推出RAC（早期叫ops），强调的是其高可用性，而不是可伸缩性。要充分发挥RAC的性能，应用必须针对RAC的特点进行编程（数据分割及数据路由），否则性能反而下降。远的说，01-02年，那时候江西绿卡系统用的是oracle 7 OPS，在结息的时候都是跑单实例；近期的，象双11，我们的某些系统也是单实例在跑（11.2.0.4 rac+asm）
2、在rac环境下，之前在单实例上不是问题的部分也会引起性能问题，最典型的就是gc类等待事件了，等待从行级锁放
大到块级等待，象大集中期间的原型性能压测期间，为了规避一个尾箱表引起的gc等待事件，我们把此表的pctfree放大到99以保证一个数据块上只保留一条记录。
3、rac环境中虽然实例是多个，但存储是单点，如果想增加节点来提高性能的话，只适用于cpu密集型的应用（前提是针对rac的特点编程），如果是io密集型的应用，节点越多估计死得越快。
4、无论是单机还是rac，要特别注意lgwr的性能优化，gc类的等待事件中，log file sync是其中的一步，lgwr对gc的影响是指数级的，我们行的某系统在做灾备切换时，主库与备库基本一致，但备库的性能与主库始终差20%，后面是把备库的logfile member去掉就OK了。
【观点二】
我从两个最重要的方面评测：

高可用或者节点故障导致的恢复时间
PureScale采用独立的CF节点管理全局的缓存，当节点发生故障时只对需要恢复的也没I/O发生阻塞，而RAC采用分布式的缓存管理，所有的请求会被短暂的冻结，在繁忙的OLTP系统中会造成大量SESSION阻塞。
ScaleOut水平扩展性
PureScale支持RDMA快速的访问和更新LOCK,BUFFERPOOL等，100节点性能损耗也就20%左右。而RAC也可以使用IB网，但是不支持RDMA，分布式的缓存/锁，随着节点数的增加，节点间通信的开销将会非常大，这也就是很少看到4节点以上RAC的原因了。
结论：PureScale作为后起之秀，在软件设计架构，各方面性能上都要优于Oracle Rac。
【观点三】
我认为在选择方案的时候，要根据自己的需要出发，看看自己目前的架构是否有什么不足，有什么无法通过完善现有方
案解决的问题，然后考虑新的方案能否解决这个问题。
DB2 PureScale和Oracle Rac解决的最主要的两个问题：
一是解决单个物理服务器的可靠性的问题，即如果单机
发生物理故障，不影响系统的可用性；
二是物理机器的横向扩展问题，即通过增加物理机器的数量来提升系统的处理能力。
这个架构没有解决的问题，存储的单点故障问题。当然这个可以通过方案扩展来解决，比如DB2 GDPC，HADR，GPFS复制等。
这个架构的缺点是什么呢？首先是是架构更加复杂，增加了成本和运维的复杂性；其次损失了部分性能。
我觉得比较这两个方案的优劣意义不大。因为选型上技术因素不大。传统的关系型数据库发展到今天，都是成熟的解决方案。不用太纠结。
【观点四】
同意楼上，总结一下：
DB2 PS相比ORACLE RAC主要有三个方面的优势：
1.性能扩展上：与Oracle RAC所不同的是，DB2 Purescale采用了CF来提供集中化的锁管理和全局缓存，而Oracle RAC采用的分布式锁管理和分布式缓存。由于分布式管理，RAC随着集群节点的增多，在极端情况下，多节点间的的通讯协调复杂性将指数型增长，虽然Oracle也可以将InfiniBand应用于Oracle RAC集群的多节点通信，但是 Oracle RAC没有利用RDMA技术，那么意味着 Oracle RAC节点通信将使用速度较慢的套接字协议，并且需要一些开销较大的CPU中断，这样会大大降低通信处理效率。而DB2 PS采用RMDA技术，成员通过INFINIBAND直接访问CF的内存。大大提高通信效率。
2.应用透明性上：为了保持Oracle RAC的性能，通常是通过数据库分区的方式来避免热页面，通过业务分割的方式将不同的应用分布在不同的节点上的方式来减少缓存融合的频度。这样对应用来说，应用跑的Oracle节点固定化了，Oracle节点的伸缩，应用的配置也需要相应变更，所有这些都会造成管理和开发成本增加。而DB2 Purescale不需要通过应用或数据分区来实现可伸缩性，增加或减少成员节点时，不会让应用集群感知到，也无需对应用进行修改，同时这也极大地降低了管理和应用开发成本。
3.持续可用性上：ORACLE在成员故障时候，处理过程复杂，并且所有页面将冻结，而DB2 PureScale数据库成员出现故障时，不需要在集群中进行全局冻结，只有动态数据保持锁定，直到成员恢复完成。集群中的所有其他成员可以继续处理事务和执行I/O操作。只有对需要恢复的页面的访问请求会在故障成员的恢复流程完成之前被阻塞。另外故障恢复时，由于Oracle RAC是日志恢复，根据故障节点在出现故障时正在进行的工作量，整个恢复过程可能会花费几十秒到几分钟不等的时间；而DB2 pureScale是内存恢复，所以DB2 PureScale恢复时间比RAC短很多，动态数据在线恢复的目标时间小于20秒。
ORACLE RAC的优势：
Oracle RAC也有自身强大之处，自从发布之后，Oracle RAC同时解决了客户对于性能扩展和高可靠性的要求，多年来没有匹配的对手，成熟度和稳定性高，功能强大，可运行的环境多样，兼容性强，架构相对简单等；DB2 PureScale也存在一定的不足和缺陷，如DB2 Purescale需要独立的两个CF节点资源；为了保证足够的性能，需要独立的InfiniBand卡和相应的交换机，并且目前只能通过GPFS才能实现磁盘共享，整体软硬件要求较高；整体架构的复杂度也较高；虽然说现在也可以运行在X86的Linux平台上，但对Linux平台操作系统版本的兼容性不够，更多的是定位于高端数据库，采用UNIX平台居多，而IBM的Power平台是Unix中的第一选择，存在一定的局限性；DB2 PureScale的CF重要性太高，即使DB2成员节点的数量很多，但CF故障一个就会造成一小段时间的中断，故障两个就会造成数据库集群全部中断。
【观点五】
如果18摸的db2想赶超oracle rac请去掉许可证的约束。
【观点六】
从搭建、维护角度来看，purescale要比RAC简单。
【观点七】
再好的技术没有市场也不行。
【观点八】
rac商业上更成功。
【核心议题】双活数据中心，并行DB下的数据库逻辑性保护如何解决？
【观点一】
这个问题有点宽泛，很难讨论。对并行DB，逻辑性复制可能每个人的理解不一样。双活数据中心也一样，很多人都在提
这个概念，真正2个数据中心跑同一个业务的很少。
【观点二】
逻辑保护和双活数据中心没有本质的必然联系
双活数据中心建设的重点还是解决业务连续性的问题。逻辑保护是一个可选项不是必选项。
【观点三】
双活数据中心下的并行DB虽然在存储层复制了两份数据，但是这两份数据的复制还是基于底层存储块，并没有在事务逻
辑层保持同步，所以一份数据据出了逻辑错误，另一份数据也无法幸免，又比如虽然是两个跨中心的存储，一旦一个存
储故障了，但是数据还未同步至另一个存储，这时候数据可能就有数据逻辑错误和数据不一致的风险，甚至数据库无法
使用了，这时候并行DB虽然解决了些许问题，但是逻辑错误风险问题，依旧还是存在。如何在事务层再做一份保护？我
个人认为，可以采用折中的方式，每日的晚间备份+异步的数据库复制技术，如HADR、DG、CDC等，采用异步的方式，由于这种复制技术是基于数据库日志的，从事务层可以保证数据的可用性，同时采用异步的方式下，也避免了这种复制带来的性能损耗。但是这种方式下，在并行DB的另一节点出现数据不一致，逻辑错误时，无法有效继续使用数据库时，起码可以回到最近的时间点，继续对外提供服务。比起数据库备份恢复来说，RPO和RTO要降低不少。
【问题】哪些业务系统使用了DB2 purescale？
你好，你们行核心账务系统上purescale吗？都有哪些业务系统上了？使用效果如何？使用purescale的路线是怎样的？直接上的gdpc还是先部署同机房的集群？如果有些问题涉及机密，可以不回答。
【答复】不好意思，直接谈路线吧。
通常上DB2 PURESCALE都先在本地部署，毕竟GDPC对同城机房的距离、网络架构、光衰、裸光纤冗余度、网络和系统运维人员素质、监控等的要求都比同机房要高很多。尤其在金融行业，都要经过慎重的选择、各类功能、性能、稳定性、可靠性的测试。DB2 PURESCALE自2009年年底推出以来，历经8年，但真正的用户，尤其是金融行业的用户屈指可数，而且基本上都没用在核心类数据库上，都是十分慎重。其主要原因可能还是，在强悍的计算性能和大容量的内存的支持下，瓶颈主要还是在于存储I/O上，企业更愿意用SCALE UP的方式解决计算资源的问题，而不是SCALE OUT的方式，然而DB2 PURESCALE只是以SCALE OUT的方式解决了计算资源的问题，存储I/O问题依旧是最大的上限和瓶颈，所以东西虽然好，但企业感觉上不上DB2 PURESCALE无所谓，也很慎重，而且对新鲜事物也是有排斥感。但我个人觉得DB2 PURESCALE的设计理念非常好，这个理念来自Z/OS，集中式缓存和锁机制，使得DB2 PURESCALE可以肆无忌惮的SCALE OUT。
【问题】DB2 PureScale双活架构是否对内存要求很高？与Oracle RAC相比多适用于什么场合？技术是否已经成熟？
【答复】DB2 PureScale的所有成员节点都含有自己的读缓存，写缓存在CF节点上，如果要算需求的内存总量，那肯定比单台DB2的内存量要高。但是计算性能基本随节点数量线性增长的。DB2 PureScale无论从性能扩展上、高可用上、应用透明度上都较ORACLE RAC有所增长。ORACLE RAC要实现性能扩展不能从SCALE OUT方面下功夫了，只能从SCALE UP方面。高可用上，ORACLE节点的故障和恢复是需要冻结所有页面访问（DB2PS只是冻结动态数据），而且恢复时间上，较DB2 PURESCALE更久（ORACLE RAC基于日志恢复，DB2PS基于内存恢复）。应用透明度上，为了保持Oracle RAC的性能，通常是通过数据库分区和业务分割的方式，这样部分应用跑的Oracle节点固定化了，而且Oracle节点的伸缩，应用的配置也需要相应变更，所有这些都会造成管理和开发成本增加，这也就就降低了应用的透明度。而DB2 PS不同，扩展不会造成性能下降，应用无需做任何改变，扩展DB2 PS节点，应用完全无感知，也无需修改应用。应用透明度高。与Oracle RAC相比，DB2 PS更适合希望通过计算节点的横向动态扩展，实现计算资源的弹性伸缩的场景，更适合24小时的业务，希望维护节点，或者节点故障，不会造成全部业务中断的场景。
总之，DB2 PURESCALE的设计理念非常好，这个理念来自Z/OS，集中式缓存和锁机制，使得DB2 PURESCALE可以肆无忌惮的SCALE OUT。
【问题】DB2 PureScale与单DB2备份的区别
DB2 PureScale与单DB2在备份方式上有何不同之处
【答复】备份方式上是一样的，都是调用DB2 API备份，DB2 PureScale在任意一台成员上进行备份即可，包括数据备份和数据库日志的备份，为什么呢？因为DB2 PureScale的所有成员通过GPFS共享数据文件和日志文件，在一个节点上可以读取所有数据，通过备份软件实现备份。
不用DB2 API，用存储快照也可。
【问题】oracle hacmp性能瓶颈问题
目前只是通过AIX的HCMAP做双机运行，同时无法保证小型机并行运行。现有存储版本比较早，已经陆续出现多块磁盘故
障，若处理不及时，很可能发生多磁盘同时故障，导致数据部分丢失的问题。
通过oracle架构改变，将原有的HACMP双机架构改变为Oracle RAC架构，从而保证系统运行的稳定、可靠、高性能性。完成一卡通数据迁移，同时对一卡通ORACLE数据库进行调优和数据清洗。将原有8G内存扩容为32G。
请问HA与RAC可以同时存在吗？
【答复1】你的想法有误区：
1.HA和ORACLE RAC都是共享一份数据，所以解决不了你之前的“现有存储版本比较早，已经陆续出现多块磁盘故障，若处理不及时，很可能发生多磁盘同时故障，导致数据部分丢失的问题。”
这个问题需要解决存储的问题才是正道。
2.HA架构改Oracle RAC架构，更多的是强调可靠性提升，而不是性能的提升。HA下的ORACLE单实例下的性能较ORACLE RAC双实例下的性能（在不做业务分割的前提下）是较高的，原因是因为ORACLE RAC节点间的缓存融合和锁竞争是需要一定开销的，必然影响性能。
【答复2】ha和oracle rac可以同时存在，看你如何规划，oracle rac 可以采用ha+raw设备来实现oracle rac
早期版本的rac是可以通过ha做共享磁盘的功能；现在新版本都使用asm了。ha已经没有存在的必要了。
感觉你的需求是迁移还是升级啊？
换存储不换主机吗？
好像没有你想象那么麻烦吧？
【答复3】11Gr2之前，做rac的时候一般使用hacmp来提供并发vg，11gr2之后就不再需要hacmp了。
不管是那个都不建议把ha和rac混合使用，这里的混合使用指的是ha不光提供并发存储，还对其他应用提供高可用功能。因为这相当于是两套集群共存了，其集群机制会互相产生影响。其实建议你先在小机上划分lapr，在lpar的基础上分别做rac和ha。

三、GPFS双活方面

【问题】GPFS上面都是跑哪些业务系统？
据我理解，GPFS是一种并行分布式文件系统，可以提供文件共享的服务。那么，当前GPFS上面都是跑哪些业务系统？具
体应用在哪些行业？
【答复】GPFS作为并行文件系统时，可以为需要共享数据的应用提供数据存储，无论什么行业、什么业务系统基本都可以用。也可以为需要共享数据的数据库提供数据存储，如ORACLE RAC+GPFS或者DB2 PURESCALE+GPFS。
GPFS作为分布式文件系统时（GPFS-FPO），可以为大数据提供数据存储支持，分布式数据库和分布式应用可以跑在上面。
【问题】GPFS能否支持同时写同一个文件？
AIX搭建GPFS文件系统，应用部署于集群文件系统之上。现业务提出各AIX终端需要同时访问修改gpfs中的文件（日志文件、配置文件等），请问能否实现，如何实现？
【答复1】这个应该需要应用层面来控制实现，分布式应用锁，GPFS我用vi测试过2个节点编辑同一个文件，一个节点在编辑状态，另外一个节点编辑是无法正常保存，强制保存会有数据丢失问题。AIX节点需要同时访问修改gpfs中的文件（日志文件、配置文件等）
【答复2】ls正解，一般gpfs文件一个在写状态，这个文件会被锁，另一个节点无法正常编辑，但可以读。
【答复3】不能同时写的，GPFS有锁机制，一个时间戳只能允许一个节点写操作。

四、双活数据中心前提、需求、问题及影响方面

【问题】双活数据中心建设和传统数据中心建设有哪些区别？
【答复】传统的数据中心环境下，灾备生产中心长年处于休眠状态，并不参与前端应用的数据读写工作。如果数据中心环境良好，没有突发性灾难的发生，灾备中心资源就一直处于闲置状态，造成用户投资浪费。而在双活解决方案中，分布于不同数据中心的系统均处于工作状态。两套系统承载相同的前端业务，且互为热备，同时承担生产和灾备服务。这样不仅解决了资源长期闲置浪费的大问题，还能使数据中心的服务能力得到双倍提升。区别主要有以下几个方面：
1.系统整体资源利用率上
2.系统整体高可用上
3.系统、架构复杂度上
4.系统维护、管理成本、难度上
5.规章制度和运维流程上
【问题】本地双活数据中心的选择问题
一般说双活，都是针对跨广域网的两个数据中心实现双活，如果是在一个园区内的两栋楼内实现双活（每个楼内都有机
房），两个机房内实现双活，和跨广域网的双活实现有何区别是否需要全局负载均衡、服务器负载均衡、大二层等技术?
【答复】在同一个园区的两栋楼内的双活，通常只需要将三层接入交换机放置至另一机房即可，打通三层，网络架构也较简单。而远距离的10KM以上的两个数据中心，通常需要将二层汇聚层交换机放置至另一机房，打通大二层，网络架构复杂。当然远距离的双活数据中心，域名服务器和负载均衡也是必须的。这两者的最主要的区别还是网络流转过程是串行还是并行，而且前者需要过多的跨机房网络流量，站点B的任何一个跨网段访问，都需要经过站点A。
楼主感兴趣可以去看看大二层的相关技术。
【问题】双活数据中心在虚拟化、云平台构建中有哪些应用？
【答复】双活数据中心指的是应用在两个不同的数据中心的部署方式，跟采用何种虚拟化技术，是否搭建了云平台无关，跑的哪些应用也无关，各类应用和数据库都有相关解决办法和方案。如在线联机型应用、在线联机型消息队列+应用、在线分析型应用都有解决办法。详细架构可见：
基于软件架构的双活数据中心建设架构
【问题】基于软件架构的双活数据中心的整体规划对于设备硬件、中间件软件、应用软件等系统组件有哪些需求？
基于软件架构的双活数据中心的整体规划设计过程中，除了底层分布式文件系统、并行数据库之外，对于服务器存储网络设备硬件、中间件软件、集群软件、虚拟化软件、应用软件等系统组件还有哪些需求？各个层次之间是否也有一些联动要求?
【答复】服务器和传统数据中心一样，该用什么还是什么基于存储双活基础架构的双活数据中心，需要对存储有特殊的要求，比如需要高端存储的跨中心双活技术，比如DS8000+HYPERSWAP技术，或者需要在两个数据中心的存储之上，建立统一的存储虚拟化，用存储虚拟化的双活技术实现，如SVC ESC或者SVC HYPERSWAP或者VPLEX METRO等。
如果不采用存储双活基础架构，可以用软件的方式，如并行文件系统实现两个数据中心的存储同时读写。像GPFS NSD服务架构模式，或者ORACLE RAC+GPFS/ASM 或者DB2 PURESCALE等。对于无需共享存储的，直接搭建跨中心中间件集群，或者应用跨中心部署即可。
网络设备需要打通大二层网络
中间件软件、虚拟化软件和应用软件没有什么特别的需求，按照传统数据中心一样的形式即可，只是部署了这些软件的
节点拉开至两个数据中心而已。
各个层次间的联动就如同传统单一数据中心内部搞双活一样。只是架构形式和部署形式的差别。
【问题】双活数据中心对日常运维影响？
众所周知，双活数据中心跟传统主备模式相比有许多优点但是双活数据中心建设完成之后对于日常运维是否也有影响？
【答复】有很大的影响，双活数据中心由于从DNS、应用负载、消息队列、中间件、应用、数据库到存储架构都发生了很大的改变，所以日常运维的方式也发生了变化。简单说说：
从流程制度上来说，所有的变更需要考虑，两个数据中心的所有节点的变更，缺一不可，架构上，网络上、运维上、应用上都需要结合整体架构更改自己的管理方式、运维方式和变更方式，流程上，需要结合整体架构、方式方法做出改变。比如说变更时必须要体现两个站点的变更步骤，必须有专人对变更方案做审核，这对人的素质更加加强了，更加强调了人与人的联动机制和默契配合。
从运维管理上来说，两个数据中心都需要人，巡检监控、备份都需要覆盖到两个数据中心，更强调了故障告警处置机制
，对监控的精细程度有很高的要求。否者一个故障，根本就不知道哪里是故障根源，根本不确定影响范围和影响点，然后双数据中心架构就背锅了。。从节点到集群到应用到业务，都需要体现出他的影响范围，和影响点，出现问题，立马就知道哪里是故障源头，做出相应的判断。
【问题】双活技术的必要前提是什么？如何提高数据同步的效率？
请问一下，在部署双活中心过程中，需要哪些必要前提是什么？如果提高数据同步的效率？
【答复】简单说下：
第一个问题：
要能实现数据中心级别的双活，有三个必要条件，首先网络是基础，裸光纤，DWDM，并打通大二层网络。其次是数据的
双活，怎么做到两个站点同时读写两份数据副本，并是同保持数据的一致性。对于数据库来讲，最理想的状态是，两个数据中心能够同时读写本地副本，并保持这两个副本的事务层一致性。最后是应用双活，如何保持两个数据中心的应用能够同时对外服务，并均衡负载业务。
第二个问题：
提高数据同步效率，j均涉及到两个中心间裸光纤的带宽，和光衰问题。分两个方面，一是SAN网络同步，提升带宽方法有，级联的光纤模块的带宽尽量大，并多做几个模块的Trunking；二是网络同步，采用万兆或者ROCE或者INFINIBAND交换机来作为网络同步的交换机。
存储与存储的同步，尽量扩大用来同步的缓存大小；通过主机与主机的方式同步的，如GPFS，也尽量分配多的内存给缓存。
【问题】双活数据中心数据和配置同步问题
这里说的双活数据中心的数据同步包括：数据库、中间件、操作系统、应用、其他配置信息等，这里不仅涉及到使用技术或者工具/软件来实现同步，还需要制定相关的同步规范来实现同步管理。双活数据中心数据同步的实现方式是怎样的？
【答复】这个问题问的好，这是双活数据中心建设过程中，必然遇到的痛点问题，这里分两个方面，自动同步和手动同步对于数据库来说，并行DB都是多实例运行，就涉及到实例的参数同步和实例环境变量的同步问题，这个需要手动同步。而数据库文件和数据库日志本身就放在外置存储当中，随着基础存储的双活技术，或者基于软件的双活技术自动同步至另一数据中心。
对于中间件来讲，有两个数据中心所有节点搭建一个大的集群，也有分别搭建集群，无论如何，都涉及到配置同步的问
题，这个需要手动同步，检查保持一致。
对于应用来讲，无论是部署于中间件的应用，还是单独部署于主机的应用也是需要手动同步。应用的共享数据，可以随存储还保持同步。
对于操作系统来说，也是手动同步。
所以可以看到，双活数据中心，能够实现自动同步的还是非常少的。大部分需要人工手动的同步，这时就需要制定严格的同步制度，规范的同步步骤，细致的同步流程，来杜绝两个数据中心所有环节、节点的不一致风险。必要时，需要梳理所有需同步的配置项，通过统一的同步软件或者工具，来实现自动化比对和变更投产，比如自动化投产工具，在流程审批过后，自动化投产工具，将按照自定义的脚本，自动在所有节点运行相同的命令，保持所有配置项的一致性。
【问题】异地双活数据库中心，一中心宕掉，另一中心能快速接管业务，保障数据一致到什么程度？
异地双活数据库中心，高并发业务，多写入，一中心宕掉，另一中心能快速接管业务，保障数据一致到什么程度。有案例分享吗？
【答复】如果是基于存储底层的实时复制技术，或者并行文件系统的实时复制技术，数据一致性只能是基于存储块级别的，对于应用来说，这种数据一致性是没有关系的。对于数据库来说，由于不是事务层的数据一致性，在数据没有同步完成时，数据库事务提交了，也在本地落盘了，但该数据中心就故障了，那么，另一中心的数据库数据文件和日志文件都跟主数据中心不一致了，这样的情况下，会有一定的可能性，造成该数据中心数据库出现逻辑问题，无法顺利接管。但目前来说，能够起到从事务层保证一致性的，只能是数据库复制技术，如HADR、DG或者CDC等，但这种技术只是容灾技术，不是双活技术，所以为了数据库既双活，又为了防范一下“万一”，最后还是做一下数据库复制。可以不同实时同步，可以用异步，但RPO和RTO不是0。

五、双活架构实现过程方面

【核心议题】如何多措并举、稳步过渡地建设双活数据中心？
【观点一】
先从底层开始，打通网络，然后实现存储双活，服务器双活
，最后进行业务应用改造，实现业务应用层面的双活。
【观点二】
1.知道自己要啥
2.知道建设的代价
3.对产品技术足够的清晰认知
4.先测试系统，后边缘系统，在重要系统稳步的推进
【观点三】
看你想达到什么样的双活了。对于传统的结构来说，先做好网络层，网路是基础。再做好怎么设计应用层，最后设计好数据层用什么样的技术做双活。实际应用来看。还是数据库的oracle的双活比较好。
【观点四】
根据我院建设经验，我们是灾备机房同样安装一台和主机房相同品牌型号的核心交换机，同一配置，然后部署独立光纤到各楼汇聚层交换机，即先建网络。第二步，做服务器双活，一台在主机房，一台在灾备机房。第三步安装存储双活硬件设备，存储阵列品牌容量和主机房一致。第四步，医院信息系统软件工程师作数据迁移，部署应用软件，实现业务层面双活。
【观点五】
双活中心建设要有计划性，要有相应预算、人力、资源、沟通、保障等等。现有生产既要保证生产进行，也要做好重组准备。在有充足预算情况下：
首先选择一个技术成熟、稳定、可扩展的、适合自己的方案作为双活建设模板。
再者涉及系统相关部门之间要加强沟通。对建设双活中如何保障业务连续性、生产稳定性、迁移盲点/痛点、迁移后业务稳定性、双活建设达标能力等等进行充分交流和合作。更要明确的领导和沟通机制、责任清晰、沟通顺畅。最好，有条件的，在迁移前搭一套准双活中心，严格按照未来生产来测试，看方案各项指标是否达到建设要求，系统是否稳定，生产能力是否满足对业务发展的需要。一切就绪，生产切换到双活最好能争取停机窗口，各个业务口、实施流程精确到位，更要有应急方案，对可能出现情况进行精确定位、处理。有一点需要提醒，改造范围在确定方案的前提下，不要随意更改，不要导致项目范围不可控，风险不可控，责任不可控，那必然导致未来不可知。
最后就是因司制宜，行动胜于一切，走过方知痛过才能快乐！