基于软件架构的双活数据中心建设方案全面比较分析 | 周末送资料
本文来自社区专家分享文章及交流整理，是相对全面的基于软件架构的双活数据中心建设方案的比较及分析。内容包括：GPFS并行文件系统、GPFS的跨中心容灾与双活架构、并行Oracle架构、跨中心并行Oracle架构、并行DB2 PureScale架构和GDPC等，以及常见的软件架构的双活数据中心建设架构之比较分析。并附针对相关内容的具体难点问题解答及实施建议。【分享者】邓毓，孙伟光，pysx0503，bryan_sd，mmsc5166，lzx660927，陈宇，zhanghaiyang，funtest，tianshizuoyi，libai21，王巧雷，sxliuxianlin，张文正。
第一部分：GPFS
一、GPFS并行文件系统
说起GPFS，大家已经比较了解了，这里再次不厌其烦地再介绍一遍---GPFS (General Parallel File System)是 IBM 公司第一个共享文件系统，它是一个并行的磁盘文件系统，它保证在资源组内的所有节点可以并行访问整个文件系统。GPFS 提供的文件系统操作服务可以支持并行应用和串行应用，它允许任何节点上的并行应用同时访问同一个文件或者不同的文件，提供统一命名接口。
既然是并行文件系统，GPFS相对于单一节点和单一文件系统它有以下几个特点：
1.文件系统的并发读写：多个节点的同一文件系统，同时受理I/O读写请求，提升文件系统读写的并发性，多个节点均为ACTIVE。
2.文件系统的高可靠性：文件系统的数据可通过日志或复制的方式存在多个副本，并且由于多个节点和多个磁盘的多活特性，可容忍故障节点数或磁盘数提升。
3.文件系统的高性能：通过将文件分布在多个节点和磁盘上，使得文件系统的读写操作分布到多个磁盘上和多个节点上，GPFS可以超越单一节点和单一文件系统的性能极限。
4.文件系统的可扩展性：文件系统可随节点数的增加和存储磁盘个数的增加，进行在线扩展和文件系统数据块均衡或调整。进一步提升性能、容量和可靠性。
在GPFS并行文件系统的应用中，通常有以下三种主要的应用架构模型：
1.SAN网络模式
这种架构也叫Direct Attached Storage架构，在该架构模式下，所有节点通过SAN网络共享同一存储，这些节点既是GPFS SERVER节点又是GPFS CLIENT节点，整个架构趋于扁平化，I/O深度浅，又由于节点与存储采用了Direct Attached的方式连接，所以这种架构模式下的节点I/O性能较好，GPFS的I/O性能主要取决于存储I/O性能。值得注意的是，这种模式下，为了保证仲裁2N+1的数量，通常选用存储盘作为TiebreakerDisk。
2.NSD服务模式
这种架构也叫Mixed NSD access架构，该架构模式下，两组NSD SERVER分别挂载两组不同的存储，这两组存储通过TCP/IP或者INFINIBAND网络传输数据，通常，两组存储的数据都保持一致，这种模式需要一个专门的仲裁节点来保证2N+1的仲裁数量，其中NSD SERVER既可作为GPFS服务端，又可作为GPFS客户端，应用节点跑在NSD SERVER上时，I/O深度也只有两层，但由于两组NSD盘间数据的实时同步会损耗一定的时间，所以NSD SERVER的I/O读写性能会稍稍降低。如果NSD SERVER上不跑应用，应用节点通过网络共享的方式对GPFS文件系统进行读写，那么整个应用读写I/O深度达到了三层，性能损耗又会提升。另外，为了实现多块NSD均衡由不同的NSD SERVER负载，可以在配置GPFS NSD时，区分不同NSD的NSD SERVER服务顺序。
3.无共享模式
这种架构也叫File Placement Optimizer (FPO)架构，这种架构模式下，每一个节点均挂载不同的存储，所有节点既作为GPFS服务端又作为GPFS客户端，GPFS文件系统横跨所有节点和所有存储，这就是所谓的分布式文件系统，通常利用节点的内置盘作为节点的存储，整个I/O深度也只有2层，这种架构的I/O读写性能最佳，GPFS并发读写最好，扩展性最佳。
以上可见GPFS作为并行文件系统，无论是性能、可靠性，还是可扩展性和灵活性上都有着自身卓越的属性。
二、基于GPFS技术的应用跨中心双活架构与容灾
在上一节中我们简要介绍了GPFS的三种架构模型，那么基于这三种架构模型，GPFS的跨中心容灾和双活架构，又该如何设计和考虑呢？
1.GPFS SAN网络模式架构下的容灾和双活
如下图所示，我们将GPFS SAN网络模式架构在SiteB一模一样的搭建，SAN网络交换机和TCP/IP网络交换机通过SiteA和SiteB间的裸光纤级联，两个站点的节点既可能是GPFS服务端，也可能是GPFS客户端。于是乎我们可以得出两种设计方案：
a.容灾方案：两个站点的所有节点搭建一个GPFS集群，所有节点均作为Quarum Node，SiteA的存储数据盘作为业务数据盘和TiebreakerDisk,SiteA和SiteB的两个存储通过存储自身的实时同步复制功能，保持数据一致性，这样一来，有两种容灾的方式，一种是SiteB的所有节点作为GPFS客户端，通过跨站点的TCP/IP网络，访问SiteA的GPFS服务端；另一种是SiteB的所有节点作为GPFS服务端，通过跨站点的SAN网络，访问SiteA的存储。这两种方式的差别在于第一种方式为：SiteB节点的GPFS文件系统读写I/O路径为跨站点的TCP/IP网络+SiteA的SAN网络；第二种方式为：SiteB节点的GPFS文件系统读写I/O路径为跨站点的SAN网络。所以在SiteB端，第一种方式的I/O路径略长于第二种方式。这两种方式的相同点在于存储的业务数据和TiebreakerDisk信息均通过存储的同步复制技术保持实时同步，为了实现站点级容灾，两种方式均需要编写脚本，判断 SiteA节点是否都活动，否则将自动将切换存储卷至SiteB,SiteB节点自动将GPFS服务拉起，继续对外提供服务。
所以总结GPFS SAN网络模式架构的容灾，可以得出，以上两种方式下的SiteB站点节点读写性能和稳定性需要重点关注；SiteB节点和存储全部故障不会对SiteA的GPFS访问造成影响；SiteA一半节点故障不会影像GPFS访问；SiteA两个节点或者TiebreakerDisk均故障需要触发脚本，使得存储盘切换至灾备端，SiteB全部节点启动GPFS服务，继续提供GPFS访问。
b.双活方案：GPFS SAN网络模式架构的跨站点双活方案，可以考虑两种方式，见下图一和图二。
图一：
图二：
图一为SAN网络模式架构模式容灾方案的延伸版，通过应用负载均衡地把服务请求分发至SiteA和SiteB两个站点，两个站点的所有节点均提供应用服务，SiteA节点的应用在本地对GPFS文件系统读写，SiteB节点的应用跨站点对GPFS文件系统读写。另外，SiteA节点既作为GPFS Servers,同时又担任Application Node，而SiteB节点既可按照容灾方案的第一种方式作为GPFS客户端，又可按照容灾方案的第二种方式作为GPFS的服务端。简单总结这种方式来说，两个站点的节点GPFS I/O读写路径和性能存在些许差异；
而图二将SiteA的NSD Server与Application Node分置于不同节点，SiteA和SiteB节点全部作为GPFS客户端，两个站点的节点GPFS I/O读写路径和性能一致。
当然，上述两种双活方案均是建立在容灾方案的基础之上，SiteA和SiteB的所有节点均加入一个GPFS集群中，利用存储到存储的同步复制功能，SiteA的TiebreakerDisk仲裁，自动探测与自动切换脚本也是必须的。
2.GPFS NSD服务模式架构下的容灾和双活
GPFS NSD服务模式下的容灾、双活和SAN网络模式架构容灾、双活有很大的不同，见下图所示。
a.SAN网络模式的容灾架构是需要存储的跨站点同步复制的，数据同步网络为SAN光纤网络；而NSD服务模式的容灾架构是通过两个站点的GPFS Server间进行数据复制和同步的，是跨站点NSD DISK与NSD DISK间的同步，数据同步网络为TCP/IP网络。基于SAN光纤网络的同步带宽、速率和TCP/IP网络会有差异，所以NSD服务模式的容灾架构的数据同步网络最好是Infiniband或者万兆TCP/IP网络,来提升整个数据同步的速率，避免同步带来的I/O性能损耗。
b.SAN网络模式的容灾架构下，两个站点GPFS读写I/O路径和性能不对称；而NSD服务模式的容灾架构下，两个站点GPFS读写I/O路径和性能非常对称，每个节点均读写各自站点的NSD数据盘。
c.SAN网络模式的容灾架构设立了TiebreakerDisk，来保证2N+1的仲裁数量；而NSD服务模式的容灾架构不需要设立TiebreakerDisk，取而代之的是第三站点仲裁节点。
d.SAN网络模式的容灾架构为了实现站点故障时，GPFS服务的自动切换功能，需要加入自动化监控和切换脚本（可考虑TSA软件）；而NSD服务模式的容灾架构无需考虑这点，因为两个站点的所有节点均为Quarum Node，组成一个集群，两个站点节点数量对等，总共2N+1的仲裁数量，SiteA的N个节点故障，不会影响整个集群故障，SiteB仍然可以对外提供GPFS文件系统读写。
3.GPFS无共享模式下的容灾和双活
GPFS无共享模式作为分布式GPFS文件系统模式，在大数据方面，应用越来越广泛。另外它对GPFS性能的提升和扩展能力的提升，起着非常重要的作用。那么这种模式架构下的容灾和双活又是如何的呢？如下图所示：
我们将同一个GPFS集群中所有的GPFS-FPO节点拉开，均匀分布于不同的两个站点，所有节点既是GPFS服务端，又是GPFS客户端，同时还是应用软件的服务节点，两个站点的TCP/IP网络或者Infiniband网络通过裸光纤级联，并通过应用负载来接入服务请求和均衡分发服务请求，最终实现跨中心的双活应用服务。这里主要利用了GPFS-FPO的四大特性：
a.位置感知特性：由于GPFS文件系统的数据是打散在不同节点的不同存储当中，所以每个GPFS节点的读写操作都需要知道究竟文件都在哪个节点存放着，所以GPFS-FPP在缓存中专门划了一片区域，来存储存储块数据的位置信息和副本信息，也叫GPFS-MAP，无论哪个节点想要读取GPFS的哪个存储块，均会通过GPFS-MAP找到所在的节点和具体位置。
b.可配置的写亲和性：GPFS-FPO的写亲和性是指某节点的应用程序需要进行GPFS读操作时，在本节点的本地存储就能读取到的能力。对于这种能力，GPFS-FPO是可以进行设置的，当设置为write striping（写条带化）时，所有GPFS节点均衡分布着数据，某一节点的读操作可能从本地无法获取，需要通过网络（GPFS客户端）的方式从其他节点读取；当设置为write affinity时，可以设置某部分文件集属于某节点专属，或者所有节点均包含相同的存储数据，这样所有节点的读操作均能在本地获得。
c.管道复制：所有GPFS节点通过专属的网络连通，当某一节点应用对GPFS写数据时，写入该节点的存储数据，同时也会通过管道复制至其他多个节点的存储。
d.快速恢复：当某一GPFS节点故障时，该节点的存储也离线，但整个GPFS并不会丢失该存储数据，其他节点的存储依旧有相同的数据副本，继续提供读写访问。当故障节点恢复后，也能通过其他节点的副本数据，快速恢复新增变化数据。
基于以上四点，我们可以看出，GPFS无共享模式架构对某些应用场合来说，也是非常适合搭建跨中心的应用双活架构。
第二部分：并行Oracle、并行DB2
一、并行DB
在前面的章节中，我们详细介绍了GPFS的三种模式架构以及其容灾和双活方式，这是对需要共享存储的应用系统，利用软件架构的方式，去实现跨中心的应用双活，那么又该如何基于软件架构，去实现OLTP数据库的跨中心双活呢？
这里我们需要提到并行DB的概念：并行数据库系统的目标是高性能和高可用性，通过多个处理节点并行执行数据库任务，提高整个数据库系统的性能和可用性。
性能指标关注的是并行数据库系统的处理能力，具体的表现可以统一总结为数据库系统处理事务的响应时间。并行数据库系统的高性能可以从两个方面理解，一个是速度提升，一个是范围提升。速度提升是指，通过并行处理，可以使用更少的时间完成数据库事务。范围提升是指，通过并行处理，在相同的处理时间内，可以完成更多的数据库事务。并行数据库系统基于多处理节点的物理结构，将数据库管理技术与并行处理技术有机结合，来实现系统的高性能。
可用性指标关注的是并行数据库系统的健壮性也就是当并行处理节点中的一个节点或多个节点部分失效或完全失效时，整个系统对外持续响应的能力。高可用性可以同时在硬件和软件两个方面提供保障。在硬件方面，通过冗余的处理节点、存储设备、网络链路等硬件措施，可以保证当系统中某节点部分或完全失效时，其它的硬件设备可以接手其处理，对外提供持续服务。在软件方面，通过状态监控与跟踪、互相备份、日志等技术手段，可以保证当前系统中某节点部分或完全失效时，由它所进行的处理或由它所掌控的资源可以无损失或基本无损失地转移到其它节点，并由其它节点继续对外提供服务。
为了实现和保证高性能和高可用性，可扩充性也成为并行数据库系统的一个重要指标。可扩充性是指，并行数据库系统通过增加处理节点或者硬件资源（处理器、内存等），使其可以平滑地或线性地扩展其整体处理能力的特性。
那么基于以上的并行DB的高性能和高可用性概念，如何去理解并行DB的架构呢？又该如何去设计并行DB的跨中心双活架构呢？由于数据库产品众多，这里只挑选两款企业OLTP数据库系统用得非常多、认可度高的产品：ORACLE和DB2，进行深入的探讨。
二、Oracle RAC
对于Oracle RAC，想必大家已经非常了解了，那么下面开始一步步引导大家逐步过渡至跨中心双活的并行Oracle架构。
1.存储架构层
文件系统的选择是并行Oracle的关键。传统的文件系统不支持多系统的并行挂载。因此，必须将Oracle数据文件存储在支持多系统并发访问的文件系统中。这样并行Oracle节点才能同时对共享的文件系统进行读写操作。这里主要有三种方式来实现：
（1）自动存储管理（ASM）
ASM提供了一个纵向的统一管理的文件系统和卷标管理器，专门用于建立Oracle数据库文件。ASM可以提供文件系统给多个Oracle RAC的集群节点。ASM无需再手动调节I/O，它会自动的分配 I/O 负载到所有的可用资源中，从而优化性能。ASM可以维护数据的冗余备份，从而提高故障的容错。它也可以被安装到可靠的存储机制中。
（2）通用并行文件系统（GPFS）
前面已经详细介绍了，用在并行Oracle架构的话，GPFS的SAN模式架构和NSD服务模式均可。它相对于ASM这样一个黑盒子来说，优势主要体现在可视化、管理能力和灵活性上，但ASM是专用于的Oracle RAC产品，对非条带化的磁盘数据也能分布均匀，I/O均匀。
（3）存储双活
这里说的存储双活并不是单一存储中的控制器双活，而是两台存储的A-A模式，如在“基于SVC的三种主流双活数据中心架构深入探讨”活动中探讨的SVC Enhanced Stretched Cluster和SVC HyperSwap，通过这种存储双活的架构结合并行Oracle，也是一种非常好的想法，Oracle RAC节点可以分别挂载不同的A-A存储，而无需考虑底层存储间的同步和双活过程，相当于把并行文件系统的功能交由底层存储硬件去实现，Oracle RAC节点纯粹做好并行Oracle的工作即可，并且这种架构少了一层（ASM/GPFS）文件系统层，I/O深度更浅。
2.并行Oracle软件架构层
Oracle RAC的软件层是在多个节点上运行多个数据库实例，利用多个节点组成一个数据库，这样在保证了数据库高可用性的情况下更充分的利用了多个主机的性能，而且可以通过增加节点进行性能的扩展。实现Oracle RAC需要解决的关键问题就是多节点进行数据访问时如何保证数据的一致性，Oracle是通过各节点间的私有连接进行内存融合（cache fusion）来保证各节点数据访问的一致性。
什么是cache fusion？
这是Oracle RAC的重要概念，它是通过Oracle RAC节点间的互连网络，在各节点的 SGA 之间进行块数据传递，以实现SGA数据块共享和一致性。它相当于把所有节点实例的SGA虚拟成一个大的SGA区，每当不同的实例请求相同的数据块时，这个数据块就通过互连网络在实例间进行传递。这样一种方式可以避免不同实例需要相同数据块时，首先将块推送到磁盘，然后再重新读入其他实例的缓存中这样一种低效的实现方式。
当一个数据块被读入 RAC 环境中某个实例的缓存时，该块会被赋予一个锁资源，以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过互连网络直接被传递到另一个实例的 SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个修改块副本。这就意味着只要可能，数据块无需写回磁盘即可在各实例的缓存之间移动，从而避免了同步多实例的缓存所花费的额外 I/O。
很明显，不同的实例缓存的数据可以是不同的。所以，一个实例要访问特定数据块，并且之前该实例从未访问过该数据块，那么它要么从其他实例 cache fusion 过来，要么从磁盘中读入。
既然cache fusion如此重要，要发挥cache fusion的作用，要有一个前提条件，那就是互连网络的速度要比访问磁盘的速度要快。否则，就根本没有引入cache fusion的意义。但是这样又带来了另外一个问题，随着Oracle RAC节点数的不断增加，节点间通信的成本也会随之增加，当到某个限度时，增加节点可能不会再带来性能上的提高，甚至可能造成性能下降。
这个问题的主要原因是 Oracle RAC对应用透明，应用可以连接至集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC 节点间的通信开销会严重影响集群的处理能力。所以通常而言，Oracle RAC 更多情况下用来提高可用性，而不是为了提高扩展性和性能。但是对于使用 ORACLE RAC 有以下三个建议：
（1）节点间通信尽量使用高速互连网络。
（2）每个ORACLE数据页面使用较少的行，通过数据库分区来避免热页面。
（3）尽可能将不同的应用分布在不同的节点上，利用业务分割的方式，来保证整体Oracle RAC的系统性能。业务分割的根本在于尽量使不同的实例不能访问相同的数据块，这样业务分割规则可以小到表的级别，大到表空间、Schema的级别。
可以看到，建议（2）和建议（3）实际上又削减了Oracle RAC的应用透明度，可见并行DB要同时提高高可用性、扩展能力、性能和应用透明度是十分艰难的。
3.跨中心的存储架构和并行Oracle扩展
前面谈到了并行Oracle存储架构的三种方式，那么这三种方式被拉伸至两个数据中心后，存储架构和并行Oracle又该如何扩展呢？
（1）自动存储管理（ASM）
Oracle RAC节点被拉开至两个站点后（Oralce Extend RAC），为了保证两个站点的存储数据一致，需要在所有节点操作系统层识别两个存储，并做LVM镜像。所有节点通过ASM对LV裸设备或者文件系统进行读写操作。
如果SiteA的存储作为主存储，那么SiteA的某一节点的写入操作需要如下过程：SiteA节点写SiteA存储，同时跨站点写SiteB存储，所有存储均写返回后，代表一次写入操作完成。SiteB的某一节点的写入操作需要如下过程：SiteB节点写SiteB存储，同时跨站点写SiteA存储，所有存储均写返回后，代表一次写入操作完成。所以这种方式下，一次写操作的速度取决于最慢的存储。
另外cache fusion是基于TCP/IP或者Infiniband的跨站点融合，对两个站点间的带宽、衰减和稳定性有很高的要求。
（2）通用并行文件系统（GPFS）
在单一站点的话，GPFS的三种模式中的SAN模式架构和NSD服务模式架构都是可以胜任并行Oracle的存储架构的。
SAN模式架构是Oracle RAC节点通过SAN网络共享存储，再在共享存储之上建立GPFS文件系统，Oracle的数据库文件存储在GPFS文件系统中，最终实现两个Oracle RAC节点并行对GPFS文件系统读写的功能。
当SAN模式架构扩展至两个站点的话，两个站点的存储需要保持实时同步，但是SiteB的Oracle RAC节点只能通过SAN网络或者TCP/IP网络访问SiteA的共享存储，对于OLTP数据库来说，站点B的RAC节点I/O访问路径过长，性能不够稳定，而且前面提及的cache fusion需要跨站点通讯，两个数据中心的距离不宜太远。所以这种模式并不理想。
NSD服务模式架构是Oracle RAC节点通过SAN网络分别挂载不同的存储盘，Oracle RAC节点均作为NSD SERVER，数据一致性是通过NSD盘间的实时复制保持的，通讯网络为TCP/IP网络或者INFINIBAND网络。
当NSD服务模式架构扩展至两个站点，每个站点均包含一个Oracle RAC节点和一套存储，这种模式下，每个站点的RAC节点访问各自站点的存储，存储数据块的同步为跨站点的NSD间的同步，通过跨站点的网络实现，每个站点的RAC节点I/O深度浅，路径短，但考验的是数据一致性、跨站点NSD实时同步和cache fusion的效率，最起码需要万兆或者INFINIBAND网络级联。
（3）存储双活
前面也讲了，当Oracle RAC的存储拉开至两个站点后，从底层存储的角度来看，这种方式较为理想，两个站点的RAC节点无需关心存储是否共享，底层存储会做好数据层所有数据同步的工作，RAC节点I/O深度浅，路径短，带宽高
相比前面两种方式，在跨中心并行Oracle的存储架构来说，最为合适，当然这里也需要考虑Oracle RAC节点间的cache fusion的效率，不建议过高并发的数据库系统需求，跨中心Oracle RAC节点的数量也需要控制。
上面三种方式，对于跨中心的Oracle RAC来讲，也是建议将业务尽量分割，对不同的表或者表空间操作的事物放在不同的Oracle RAC节点跑，尽量减少跨中心的I/O流量和网络流量，不至于为了双活而双活，反而导致可靠性和性能降低。
三、DB2 PureScale
DB2 PureScale是以IBM DB2 for z/OS技术(集中锁定和集中缓冲池技术)为基本原则，主要针对分布式系统的在线事务处理(OLTP)提供集群技术。
DB2 PureScale并不是一个硬件解决方案，它是一个应用在AIX系统（现在也可运行在Linux系统）上的数据库集群软件。如果该软件在IBM Power Systems上运行，在降低扩展IT系统的风险和成本的同时，可以帮助客户提高数据库交易能力。其目的是让企业在不牺牲性能的前提下扩展DB2集群，DB2 PureScale具有无限扩展、应用透明性、持续可用性等特点：
(1)无限扩展
DB2 PureScale为各种事务处理工作负载提供了几乎无限的产能。系统扩展非常简单，只需要与一个新节点连接，并发出两个简单的命令即可。DB2 PureScale基于集群、磁盘共享的架构通过有效利用系统资源，降低了成本。
(2)应用透明性
使用DB2 PureScale，无需改变企业的应用程序代码，就可以有效地运行在多个节点上。久经验证的、可扩展的架构能够随需扩展应用程序，以满足变化的业务需求。企业只需做少量改变或无需做任何改变，就能够运行为其他数据库软件编写的应用程序；DB2 为常用的语法规则和PL/SQL语言提供了全面的支持，使从Oracle数据库迁移到 DB2 变得比以往更轻松了。
(3)持续可用性
DB2 PureScale通过在IBM Power Systems上和冗余架构中使用高可靠的IBM PowerHA PureScale技术，提供了持续的可用性。此系统能够瞬间从节点故障中恢复，立即将工作负载重新分配给其他可用的节点。
如何理解以上的三个特点呢，我们先来看下DB2 PureScale的整体系统架构图：
从图中可以看出，一套DB2 PureScale架构上包含以下几个部分：
（1）数据库集群
DB2 PureScale数据库集群由成员和CF节点组成。
a.成员member
代表一个DB2处理引擎（一个DB2实例），一个成员拥有自己的内存、缓冲池、交易日志和锁机制，能自行编译和执行DB2事务。
b.耦合设施coupling facility(CF)
CF节点管理着DB2数据页的全局缓存和全局锁，以此为所有成员提供服务，CF节点采用集中式锁机制和集中式缓存机制来保证所有成员事务层数据的一致性。在实际应用中，通常配置两个CF节点，一主一从，这样可用避免CF节点单点故障。
另外，主从CF间的全局缓存和全局锁也是实时复制的，来保证CF节点故障后，备CF节点能够快速无缝接管。基于以上的机制，成员对数据页的访问，在成员本地缓冲池没有命中或者需要修改数据页时，需要成员和向主CF节点发起通信请求，来获得数据页和锁信息，在数据库并发较大、事务更新多的情况下，通信频繁度非常高，为了尽可能地提高通信效率，DB2 PureScale使用了RDMA（Remote Direct Memory Access）技术。RDMA支持直接读写另一台计算机的内存，并且不需要占用目标计算机的CPU资源。RDMA技术结合超高速网络，如InfiniBand、万兆或聚合以太网(RoCE)，大幅缩短成员与CF间的通信时间。
（2）数据库集群服务
DB2 PureScale中整合了DB2 Cluster Services，来支持错误检测和自动恢复的任务，这些技术服务包含了TSA（Tivoli System Automation）和RSCT。其中TSA用来实现监控、失败检测、成员的重启和恢复、CF节点切换的任务。
（3）GPFS文件系统
DB2 pureScale各个节点通过GPFS文件系统访问共享存储。从图中也可以看出，采用了GPFS SAN网络模式架构，所有节点均直接通过SAN网络连接存储，GPFS高可用上采用了2N节点+1TiebreakerDisk的方式。
通过以上的介绍，大家也可以看出DB2 PureScale的CF节点是重中之中和核心关键点，在集群数据库运行时，虽然成员多个并行运行，但CF节点工作时只是单节点运行，虽然CF节点的主备节点可以实现故障切换和内存的无缝衔接，但是是否可以判断说CF节点可能会存在性能的瓶颈呢？
我们都知道一个系统的瓶颈无非是CPU，内存，磁盘I/O和网络I/O这四大方面。那我们就一一来分析CF可能会存在瓶颈的点：
(1)CPU
CF的用途仅仅是作为全局锁管理（GLM）和全局缓冲池管理（GPM）,为成员提供服务，服务是通过RDMA技术实现的，RDMA是内存与内存的直接交互，所以CF的CPU几乎不可能成为瓶颈。
(2)内存
因为只有节点更改过的数据才会被写入到CF中的全局缓冲池当中，而大部分节点还是在自己的缓冲池中缓存自己的数据，因此CF的全局缓冲池中只会保存一部分数据。另外，通常而言一个典型的OLTP应用，全库的数据一般也就在几百G左右，经常要改动的数据量可能更小，而当前单台服务器的总内存越来越大，上百G甚至上T，内存价格也越来越便宜，所以对于OLTP数据库来说，只要初期规划合理，CF的缓冲池不大可能不够，因此CF的内存成为瓶颈可能性也是非常小的。
(3)磁盘I/O
对于CF来说就更不会成为瓶颈了。因为CF仅仅用于GLM和GPM，都存放在内存当中，CF根本就不会从磁盘中读写数据，磁盘I/O瓶颈也就无从谈起。另外，因为DB2 PureScale是基于Share Disk架构的，所有的member和CF都是共享存储（CF也可不共享GPFS），如果磁盘I/O成为瓶颈，那肯定是整个集群的GPFS I/O都是瓶颈，这时需考虑的只是成员的磁盘访问性能。
(4)网络I/O
先说TCP/IP网络，CF的TCP/IP网络只负责和集群中的其他节点做管理通信以满足集群软件管理上的需求，根本就不会处理来自成员和数据库客户端的TCP/IP请求，因此CF的TCP/IP网络永远不可能成为瓶颈；再说InfiniBand网络, CF和Member之间的数据通信主要通过InfiniBand网络。当成员数量增加，并发交易量增加的时候，CF和成员之间的InfiniBand网络带宽是关键点。首先现在InfiniBand网卡的传输速度是40Gb/s, 是万兆网的4倍。其次，CF节点支持多块InfiniBand卡，即使真的出现了InfiniBand网络带宽不足的问题，也可以通过给CF增加InfiniBand卡的办法来解决。所以InfiniBand网络成为瓶颈的可能性也不大。
综合以上的分析，DB2 PureScale是一款非常优秀的并行数据库产品，相较于OracleRAC，在以下几个方面，存在一定的优势：
（1）更好的性能伸缩
与Oracle RAC所不同的是，DB2 Purescale采用了CF来提供集中化的锁管理和全局缓存，而Oracle RAC采用的分布式锁管理和分布式缓存。
由于分布式管理，RAC随着集群节点的增多，在极端情况下（如多个节点同时修改在另外一个节点管理的缓存中的数据时），多节点间的的通讯协调复杂性将指数型增长，虽然Oracle也可以将InfiniBand应用于Oracle RAC集群的多节点通信，但是 Oracle RAC没有利用 RDMA技术，那么意味着 Oracle RAC节点通信将使用速度较慢的套接字协议，并且需要一些开销较大的 CPU 中断，这样会大大降低通信处理效率。
而DB2 Purescale，基于全局锁管理和全局缓存，所有成员节点都和CF单一通讯，为了获取CF中全局缓存数据，直接采用了RDMA内存复制技术，从而避免了高成本的进程间通讯。另外采用CF来管理全局锁和缓存，相对来说，简化了管理，因此DB2 Purescale能扩展到128节点，还保持着比较好的性能线性。
（2）更高的应用透明性
前面也说了，为了保持Oracle RAC的性能，通常是通过数据库分区的方式来避免热页面，通过业务分割的方式将不同的应用分布在不同的节点上的方式来减少缓存融合的频度。这样对应用来说，应用跑的Oracle节点固定化了，Oracle节点的伸缩，应用的配置也需要相应变更，所有这些都会造成管理和开发成本增加；而DB2 Purescale不需要通过应用或数据分区来实现可伸缩性，增加或减少成员节点时，不会让应用集群感知到，也无需对应用进行修改，同时这也极大地降低了管理和应用开发成本。
（3）更高的持续可用性
Oracle RAC的节点故障需要涉及四个步骤：故障检测、Remaster数据块、锁定需要恢复的页面和重做和撤销恢复。具体来说，在Oracle RAC中，每个数据页都由集群中的一个实例来管控。Oracle采用分布式的锁机制，因此集群中的每个实例都需要负责管理和批准对它所管理页的锁请求。
当某个节点出现故障时，首先，故障节点所管理的数据页将立即变为孤立的，直到RAC会通过重新分配流程将这些孤立页面的管控权分配给集群中健康的节点。在GRD（全局内存资源目录）重新配置的过程中，对页面的所有读取和锁请求都会被冻结。此时，它们不能执行任何I/O操作或请求任何新锁。
其次，锁定所有需要恢复的数据页面。这项任务必须在GRD冻结被释放之前完成。如果某个实例在获得适当的页解锁之前被允许读取磁盘中的页面，则故障实例的更新操作可能会丢失。恢复实例将读取故障实例的重做日志文件，并锁定任何需要恢复的页面。这可能需要大量随机的I/O操作，因为日志文件和需要恢复的页都可能不在任何健康节点的内存中。仅当恢复实例执行了所有这些I/O操作并锁定适当的页之后，GRD冻结才会被释放，停滞的应用才能继续运行。
相比之下，DB2 PureScale的设计初衷是最大限度地提高在故障恢复处理中的可用性，当数据库成员出现故障时，DB2 PureScale不需要在集群中进行全局冻结，只有动态数据仍然保持为锁定，直到成员恢复完成。因为CF在任何成员出现故障时始终知道哪些页面需要恢复。如果某个成员出现故障，集群中的所有其他成员可以继续处理事务和执行I/O操作。只有对需要恢复的页面的访问请求会在故障成员的恢复流程完成之前被阻塞。
另外故障恢复时，由于Oracle RAC是日志恢复，根据故障节点在出现故障时正在进行的工作量，整个恢复过程可能会花费几十秒到几分钟不等的时间；而DB2 pureScale是内存恢复，所以DB2 PureScale恢复时间比RAC短很多，动态数据在线恢复的目标时间小于20秒。
当然Oracle RAC也有自身强大之处，自从发布之后，Oracle RAC同时解决了客户对于性能扩展和高可靠性的要求，多年来没有匹配的对手，成熟度和稳定性高，功能强大，可运行的环境多样，兼容性强，架构相对简单等。
而DB2 PureScale也存在一定的不足和缺陷，如DB2 Purescale需要独立的两个CF节点资源；为了保证足够的性能，需要独立的InfiniBand卡和相应的交换机，并且目前只能通过GPFS才能实现磁盘共享，整体软硬件要求较高；整体架构的复杂度也较高；虽然说现在也可以运行在X86的Linux平台上，但对Linux平台操作系统版本的兼容性不够，更多的是定位于高端数据库，采用UNIX平台居多，而IBM的Power平台是Unix中的第一选择，存在一定的局限性；DB2 PureScale的CF重要性太高，即使DB2成员节点的数量很多，但CF故障一个就会造成一小段时间的中断，故障两个就会造成数据库集群全部中断。
好了，前面谈了很多，今天的话题是双活数据中心，那么DB2 PureScale的跨中心双活又是如何的呢？这里我们要谈到IBM GDPC（Geographically Dispersed DB2 PureScale Clusters）同城异地双活灾备解决方案---基于IBM DB2 PureScale技术实现地理跨越同城双活。
IBM GDPC是一种配置，允许分布式 DB2 pureScale 集群，从而可以使集群的成员位于不同站点。因此，我们将DB2 PureScale的成员和CF节点均分至两个站点SiteA和SiteB，并在站点SiteC也搭建一个仲裁节点，这样对于4节点成员和2节点CF的数据库集群来说，SiteA包含成员1和3，CF主，SiteB包含成员2和4，CF备，SiteC包含GPFS仲裁节点，所有成员节点和CF节点通过跨站点级联的SAN网络共享存储，并在存储之上建立GPFS，架构模式为NSD服务模式，SiteA存储与SiteB存储的数据通过网络实时同步。所有数据库日志文件和数据库文件均存放在GPFS上，实际上对于存储来说，两个站点各存放了一份数据。所有成员均通过Infiniband网络，利用RDMA技术访问SiteA的CF 主，最后两个站点的TCP/IP网络,Infiniband网络和SAN网络统一通过裸光纤级联。GDPC整体架构图如图所示：
另外提一点，由于DB2 PureScale应用透明度高，所以DB2 PureScale拉伸至GDPC架构后，跨中心的集群应用可以不需要做任何修改，只需要保持现状，由DB2客户端自动路由分发请求至两个站点的成员节点即可。
然而我们可能还会有这样一种需求，正常情况下，两个站点的应用节点只访问本站点的数据库成员节点，并且数据库成员节点只访问本站点的GPFS NSD存储，那么我们不但需要在DB2客户端（应用端）配置跨站点的冗余性，提供容错功能，还需要配置客户端亲缘关系与GDPC配合使用，并且两个站点的GPFS NSD盘的属性需要优先本地站点的成员节点。
第三部分：整体架构
前面的章节，我们循序渐进、逐步过渡的探讨了GPFS并行文件系统、GPFS的跨中心容灾与双活架构、并行Oracle架构、跨中心并行Oracle架构、并行DB2 PureScale架构和GDPC等。
通过对这些架构的说明、演进和探讨，说明要实现双活数据中心的落地，需要从基础架构开始到最顶层应用，逐层设计，通盘考虑，既要考虑高可用需求，又要考虑性能拓展，还需结合现有架构，当然还有成本、管理、开发、监控等方面的考虑；说明了基于软件架构的双活数据中心建设方案多、规模大、技术难度大和复杂度高。
下面我简要总结一下常见的软件架构的双活数据中心建设架构。
(1)在线联机型应用（无共享数据）
(2)在线联机型应用（有共享数据）
(3)在线联机型消息队列+应用
(4)在线分析型应用
简要说明：
（1）以上四种架构，均包含了域名服务器，它的作用是负责域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它将用户的请求分散到两个站点的多台服务器上。
另外我们在设计的时候，有两个需要注意的点：一是需要增加DNS高可用，因为所有的请求都是由DNS进行域名解析和映射的，所以重要性不言而喻，必须要增加一台备机，在主DNS故障时，可以立即接管；二是需要考虑DNS共用的问题，可以搭建两套DNS，一套用来解析站点外部的访问请求，另一套用来解析站点内部的访问请求。外部请求用域名方式，当发起外部请求时，DNS解析之后可将请求均衡分发至站点A和站点B的应用节点；内部应用与应用之间的请求也统一用域名的方式，当发起内部请求时，DNS解析之后也可将请求均衡分发至站点A和站点B的应用节点。这样就实现了两个站点所有应用节点负载均衡的目的，然而为了更高效、丰富的均衡功能，需要专用的DNS服务器，来实现站点均衡的可靠性，比如说负载的权重，监控负载的状态，会话的保持等等。
（2）我们可以看到，架构1和架构2包含了应用负载服务器，这里有三个方面需要说明。
架构方面：站点A为主备两台应用负载，站点B为主应用负载，三台应用负载搭建主主备的集群模式，实现流量组1在站点A运行，流量组2在站点B运行，DNS将请求均衡分散至流量组1和流量组2，最终实现双数据中心应用负载均衡的目的；
高可用方面：三台应用负载组成的主主备集群，可实现故障自动切换和流量资源转移，加强了整体负载均衡的可靠性；
应用形式方面：通常采用的是反向代理的负载均衡，因为其调度策略比较丰富，例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。并发处理能力要求高，反向代理服务器可以监控后端服务器，比如系统负载，响应时间，是否可用，TCP连接数，流量等。从而根据这些数据调整负载均衡的策略。反向代理服务器可以让用户在一次会话周期内的所有请求转发到一台特定的后端服务器上（会话保持），这样的好处一是保持会话的本地访问，二是防止后端服务器的动态内存、缓存的资源浪费。
（3）对于有共享数据的在线联机型应用，如同前面介绍的，可采用GPFS SAN网络模式作，也可采用GPFS NSD服务模式。如果对共享数据有I/O性能要求，可以用跨站点的存储双活或者存储虚拟化网关的跨站点双活方案；如果对I/O性能无要求，可采用HACMP+NFS Server+NFS Client的模式。
（4）架构1、2、3中的OLTP数据库为跨站点的并行数据库，为了实现所有节点事务层数据的一致性，减少缓存、锁一致性带来的网络通信开销，尽量读写缓冲池，减少磁盘I/O直接读写，提高整体I/O效率，所有节点间的互连网络采用高速网络，通常需要万兆、Infiniband或者聚合以太网(RoCE)。
（5）架构1、2、3中跨站点的并行数据库的数据存储方面有三个选择，在前文中也有所介绍。
一是专用的自动存储管理（如ASM）+LVM方式，ASM对本站点的多个LV均衡读写，再通过操作系统LVM实时复制一份写数据至另一站点的存储中，LVM缺少缓存机制，再加上两份存储需同时写完成才算是真正的写完成，写性能取决于写响应最慢的存储，所以这种方式下，并行数据库存储性能相对较差。
二是并行文件系统（如GPFS）方式，通常采用GPFS NSD服务模式，两个站点的磁盘均作为NSD DISK，通过跨中心的TCP/IP或者Infiniband网络实时复制，保持同步，主机操作系统需要安装GPFS软件，并且GPFS需要占用一定的主机系统内存作为GPFS缓存，这种方式下，并行数据库存储性能一般；
三是存储双活方式（如DS8000+HyperSwap，存储网关SVC ESC和Hyperswap等），这种方式是通过底层存储实现双站点的并行数据读写，主机端的开销最小，无需安装任何软件，也无需在系统内存上划分专门的并行文件系统缓存，两个站点间存储数据同步，是通过跨站点的SAN网络实现，所以这种方式下的并行数据库整体性能最优。
（6）通常而言，在线联机型消息队列+应用架构主要是采用MQ与MQ的通讯方式实现，MQ负责在两个系统之间传递消息，这两个系统可以是异构的，处于不同硬件、不同操作系统、不同程序语言，但只需要简单的调用MQ API，即可实现相互的通讯，然而MQ的功能仅限于消息队列，至于两个应用互相发送的消息格式是怎么样的，能不能被解析，MQ是管控不到的，MQ只是尽力将消息发送到对端就完成了任务，而且如果多个应用需要与多个应用通过MQ通讯，那就比较麻烦了，它们间需要建立蜘蛛网状的MQ连接拓扑。
所以我们采用ESB（企业系统总线）的MQ+MB的方式简化应用间的消息传输，ESB处于所有应用的最中央，MQ依旧负责收发通讯消息，MB负责消息路由和消息转换，MB会根据消息字段和设定的业务逻辑自动地将消息发送给匹配的应用。对于跨站点的ESB来说，也可以通过域名服务器+站点A的ESB+站点B的ESB架构来实现，站点A的ESB将消息路由至站点A匹配的应用，站点B的ESB将消息匹配至站点B匹配的应用。如果应用有多个节点，前端也需要接应用负载实现多应用节点的负载均衡。
（7）对于架构4，在线分析型应用，采用了当下非常热门的大数据分布式应用和分布式数据库架构，并将所有节点扩展至两个站点，通过域名服务器，均衡两个站点的服务请求。而分布式应用和数据库节点间的的负载均衡，可由开源的分布式应用程序协调服务来实现，如ZooKeeper。对于分布式存储，采用分布式文件系统的方式，如GPFS-FPO，HDFS，Ceph等。
第四部分：技术难点解决、实施建议
一、整体双活架构设计方面
【议题】采用软件架构的双活数据中心还是虚拟化存储架构双活数据中心?
【观点一】
双活有很多种理解和实现方式。选择哪种技术路线也要看用户自身的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.这张架构图，包含了域名服务器，它的作用是负责域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的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，这是基于无共享架构的分布式文件系统，在实时并发文件系统存储这块更具优势。
【观点三】
上图说话吧：
【问题】两种方式（采用软件架构或者虚拟化存储架构）的可靠性及性价比对比？从可靠性来说，我觉得基于存储实现双活是否可靠性更高一些？毕竟它更接近底层。另外从性价比考虑，哪个更好一些？
【答复】
关于双活中心基础存储架构的建设是采用软件架构还是虚拟化存储或者底层存储架构，简要对比如下：
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是很好的选择，但是该如何选择呢?他们的优势和不足都体现在哪？
【观点一】
我不懂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了。
【观点二】
我从两个最重要的方面评测：
1. 高可用或者节点故障导致的恢复时间
PureScale采用独立的CF节点管理全局的缓存，当节点发生故障时只对需要恢复的也没I/O发生阻塞，而RAC采用分布式的缓存管理，所有的请求会被短暂的冻结，在繁忙的OLTP系统中会造成大量SESSION阻塞。
2. 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 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设备来实现。早期版本的rac是可以通过ha做共享磁盘的功能；现在新版本都使用asm了。ha已经没有存在的必要了。
感觉你的需求是迁移还是升级啊？换存储不换主机吗？好像没有你想象那么麻烦吧？
【答复3】
11Gr2之前，做rac的时候一般使用hacmp来提供并发vg，11gr2之后就不再需要hacmp了。
不管是哪个都不建议把ha和rac混合使用，这里的混合使用指的是ha不光提供并发存储，还对其他应用提供高可用功能。因为这相当于是两套集群共存了，其集群机制会互相产生影响。其实建议你先在小机上划分lapr，在lpar的基础上分别做rac和ha。
三、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。
五、双活架构实现过程方面
【议题】如何多措并举、稳步过渡地建设双活数据中心？
【观点一】
先从底层开始，打通网络，然后实现存储双活，服务器双活，最后进行业务应用改造，实现业务应用层面的双活。
【观点二】
知道自己要啥
知道建设的代价
对产品技术足够的清晰认知
先测试系统，后边缘系统，在重要系统稳步的推进
【观点三】
看你想达到什么样的双活了。对于传统的结构来说，先做好网络层，网路是基础。再做好怎么设计应用层，最后设计好 数据层用什么样的技术做双活。实际应用来看。还是数据库的oracle的双活比较好。
【观点四】
根据我院建设经验，我们是灾备机房同样安装一台和主机房相同品牌型号的核心交换机，同一配置，然后部署独立光纤到各楼汇聚层交换机，即先建网络。第二步，做服务器双活，一台在主机房，一台在灾备机房。第三步安装存储双活硬件设备，存储阵列品牌容量和主机房一致。第四步，医院信息系统软件工程师作数据迁移，部署应用软件，实现业务层面双活。
【观点五】
双活中心建设要有计划性，要有相应预算、人力、资源、沟通、保障等等。现有生产既要保证生产进行，也要做好重组准备。在有充足预算情况下：
首先选择一个技术成熟、稳定、可扩展的、适合自己的方案作为双活建设模板。
再者涉及系统相关部门之间要加强沟通。对建设双活中如何保障业务连续性、生产稳定性、迁移盲点/痛点、迁移后业务稳定性、双活建设达标能力等等进行充分交流和合作。更要明确的领导和沟通机制、责任清晰、沟通顺畅。最好，有条件的，在迁移前搭一套准双活中心，严格按照未来生产来测试，看方案各项指标是否达到建设要求，系统是否稳定，生产能力是否满足对业务发展的需要。一切就绪，生产切换到双活最好能争取停机窗口，各个业务口、实施流程精确到位，更要有应急方案，对可能出现情况进行精确定位、处理。有一点需要提醒，改造范围在确定方案的前提下，不要随意更改，不要导致项目范围不可控，风险不可控，责任不可控，那必然导致未来不可知。
最后就是因司制宜，行动胜于一切，走过方知痛过才能快乐！
点解阅读原文可下载原文档 觉得本文有用，请转发或点击“在看”，让更多同行看到
欢迎关注社区 "双活"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/71
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场