双活数据中心建设系列之--- 基于软件架构的双活数据中心建设方案深入探讨(整体架构部分)

基于软件架构的双活数据中心建设架构

前面的三个章节，我们循序渐进、逐步过渡的探讨了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等。