深信服双活数据中心业务层专项方案.docx

双活数据中心（业务层）方案
一、需求背景：
伴随数据大集中，银行纷纷建设了负责本行各业务处理生产数据中心机房（通常称为数据中心），数据中心因其负担了全行业务，所以其并发业务负荷能力和不间断运行能力是评价一个数据中心成熟是否关键性指标。
多年来，伴随网上银行、手机银行等多种互联网业务迅猛发展，银行数据中心业务压力业成倍增加，用户对于业务访问质量要求也越来越高，保障业务系统7*二十四小时连续运行并提升用户体验成为信息部门首要职责。
商业银行信息系统安全、稳定运行关系着国家金融安全和社会稳定，监管机构也十分重视商业银行灾难备份体系建设，数次公布了商业银行信息系统灾难备份相关标准和指导，对商业银行灾备系统建设提出了明确要求。
为适应互联网业务快速增加，保障银行各业务安全稳定不间断运行，提升市场竞争力，同时符合监管机构相关要求，建设灾备、双活甚至多活数据中心正在成为商业银行共同选择。
二、发展趋势：
多数据中心建设需要投入大量资金，其项目周期往往很长，包含范围也比较大。从技术上来说，要实现真正意义上双活，就要求网络、应用、数据库和存放全部要双活。就现阶段来看，大多数用户多数据中心建设还达不到完全双活要求，主流建设目标是实现应用双活。现在用户建设多数据中心模型能够归纳为以下多个：
1.单纯数据容灾：
正常情况下只有主数据中心投入运行，备数据中心处于待命状态。发生灾难时，灾备数据中心能够短时间内恢复业务并投入运行，减轻灾难带来损失。这种模式只能处理业务连续性需求，但用户无法就近快速接入。灾备中心建设投资巨大且运维成本高昂，正常情况下灾备中心不对外服务，资源利用率偏低，造成了巨大浪费。

2.构建业务连续性：
两个数据中心（同城/异地）应用全部处于活动状态，全部有业务对外提供服务且互为备份。但出于技术成熟度、成本等原因考虑，数据库采取主备方法布署，数据库读写操作全部在主中心进行，灾备中心进行数据同时。发生灾难时，数据中心间数据库能够快速切换，避免业务中止。双活数据中心可充足盘活企业闲置资源，确保业务连续性，帮助用户接入最优节点，提升用户访问体验。

3.提升业务服务能力：
多个数据中心同时对外提供服务且互为备份，各中心数据库可同时处理应用读写请求，网络、存放、应用和数据库全部实现多活。各数据中心独立运行，用户流量可被智能调度，形成灵活、弹性和可扩展面向服务业务架构。

三、业务目标：
用户建设多数据中心思绪和建设模型略有不一样，但大多数用户关键建设目标能够归纳为以下几点：
u 流量分发
用户访问流量可灵活、弹性调度到多个数据中心，使各数据中心压力相对均衡，确保用户接入最近最快速数据中心节点，提升用户访问体验。
u 故障切换
当出口链路或内部服务器出现异常时，运维人员可第一时间得悉故障情况，业务可依据需要自动或手动平滑切换至正常节点，确保用户访问连续性。
u 业务安全
数据中心所处位置基础设施完善，水电通信供给稳定，数据中心内部有对应技术手段确保整个数据中心抵御DDos攻击，各业务系统不被黑客非法入侵。
u 环境一致性
多个数据中心对用户来说理应是透明，其对外服务时提供统一接口，各数据中心内部数据和服务能力需要完全一致，且随时处于可切换状态。

四、技术实现逻辑
我们把整个数据中心在逻辑上分为接入层和服务层，其逻辑步骤以下：

分层 链路层 服务层

五、总体设计
总行数据中心整体上分为主中心和灾备中心，二者网络架构、业务系统和服务能力全部基础相同，同时对外提供服务，形成双活数据中心。数据中心内部划分为互联网业务区（提供外网服务，如手机银行、网上银行等）、关键生产业务区（传统生产业务，如ATM、柜面等）、数据库区（生产/查询）和业务测试区，出于成本考虑，灾备数据中心不设业务测试区。主备数据中心和各一级分行之间经过专线互联，利用动态路由协议组建企业内部专网。

数据中心对外业务集中在互联网业务区，通常使用域名方法对外公布，用户端访问业务系统时，需要先由DNS将域名解析为IP地址，然后再访问该目标IP。对外业务全局负载通常利用DNS解析实现，其可依据用户地理位置、用户所属运行商和网络质量、数据中心服务能力等原因作为判定依据，为不一样用户返回不一样IP地址，实现流量合理分配。对于数据中心内网业务，一部分和外网业务相同，经过域名公布。另一部分和一级分行业务类似，直接经过IP地址访问。对于经过IP地址访问业务，内网全局负载采取IP-Anycast（RHI路由注入）技术实现，其原理是在各数据中心以相同IP公布业务，由动态路由协议依据COST值等参数用户判定访问最好路径。
六、互联网业务全局负载（以网银为例）
1.设计模型

我们把网银业务从逻辑上分为接入侧和服务侧，接入侧包含出口链路、全局负载设备；服务侧包含WEB服务单元、APP服务单元和DB服务单元。WEB服务单元包含SSL卸载设备、WAF防火墙、负载均衡和服务器；APP服务单元包含防火墙、负载均衡和服务器；DB服务单元包含防火墙、负载均衡、数据库审计和数据库。WEB服务单元和APP服务单元在2个数据中心同时提供服务，实现应用双活。考虑到数据强一致性、技术成熟度和成本等原因，双数据中心间DB服务单元提议主备布署，数据中心内部数据库集群可结合当地负载均衡实现多活。为达成最好负载效果，需要各服务单元负载设备能够访问其它数据中心对应服务单元服务器，但优先调度当地服务器。
2.实现方法
（1）流量调度
数据中心层面：我们推荐使用两层逻辑算法智能DNS调度策略，首先，全局负载设备会判定用户地理位置，将用户调度到就近数据中心，处理南北互访问题；其次，依据用户所属运行商选择对应链路供用户接入，处理跨运行商访问慢问题。另外，全局负载还可对用户端LDNS提议反向探测，判定用户网络质量，为用户选择最好接入路径。
服务单元层面：WEB、APP和DB服务单元全部配置了当地负载均衡器，用户访问流量抵达数据中心内部后，由服务单元负载设备依据预设策略分发给各服务器，可依据用户需求灵活选择轮询、优先级、最小连接等算法。
（2）业务连续性
数据中心层面：经过DC Cookie确保用户接入同一数据中心。用户首次访问时，当地WEB负载设备在响应数据包中插入DC Cookie，当用户端网络发生改变时，第二次访问就可能被调度到其它数据中心，这时其它数据中心WEB负载设备会识别该Cookie，将用户请求转发至第一次处理该用户访问WEB负载设备，再由该负载设备进行调度。

服务单元层面：WEB服务单元负载提议经过cookie会话保持（插入、改写和被动）确保业务连续性；APP服务单元负载可经过cookie或源IP会话保持确保业务连续性（是否需要会话保持，选择何种会话保持方法需要结合应用具体情况）；DB服务单元通常不需要会话保持。
（3）健康状态检验
服务单元层面：经过内置应用级健康监视器对服务器进行主动探测，提供HTTP、HTTPS、RADIUS、FTP等常见模板。对于其它应用，提供接口供用户自定义检测内容和响应内容。另外，还提供极具特色被动健康检验功效，经过对TCP和HTTP协议数据交互做采样分析，判定服务器健康状态。
数据中心层面：全局负载和服务侧各区域负载均衡联动，实时共享信息，判定服务侧整体服务能力；同时全局负载设备会探测出口各链路健康状态，结合服务侧整体服务能力和设备本身负荷情况，综合判定该数据中心健康状态（正常、繁忙、故障）。
（4）故障切换
服务单元层面：服务单元内部某服务器繁忙或故障时，将用户请求调度到其它正常服务器。
数据中心层面：
a.某数据中心WEB或APP服务器全部繁忙或全部故障时，用户接入链路不切换，经过专线将数据转发至正常数据中心对应服务单元。

b.主数据中心数据库服务器全部故障时，用户接入链路不切换，经过专线将直接激活备数据中心数据库，实现数据库一键切换。数据库切换前需要验证数据库正确性，用户需要完成数据验证并确保数据库按次序切换。
c.数据中心全部链路同时故障时，全局负载设备将用户流量平滑牵引至正常数据中心。单链路故障时，可依据用户需求切换至本中心其它链路或其它中心同ISP链路。另外，当某数据中心出现服务能力不足时（链路繁忙、服务单元繁忙等），全局负载设备还能够基于数据中心整体健康得分情况将用户分流至其它数据中心，保障用户正常访问。
（5）安全保障
数据中心层面：
a.网络出口处布署DDos防护设备并在运行商处购置流量清洗服务，确保数据中心整体安全。
b.网络出口处布署FW和IPS设备，从网络层和应用层确保数据中心不被恶意入侵。
c.全局负载设备提供DNS防火墙功效，充足确保DNS安全。
DNSSEC 支持、UDP Flood、DNS 放大和反射
服务单元层面：各服务单元布署防火墙，确保区域安全。WEB服务单元直接面向互联网用户，需要布署SSL卸载设备实现SSL加解密，提升业务访问安全。同时，经过布署WAF保障WEB服务器安全。
（6）业务优化加速
a.跨数据中心数据库同时需占用大量带宽资源，且数据量很大，布署WOC设备可大幅压缩传输数据，削减流量。WEB或APP服务单元跨数据中心通信时，经过WOC设备协议优化和流缓存等技术实现加速。当二者同时需要大量带宽资源时，优先确保数据库同时。
b.互联网区WEB服务单元直接面向公网，受公网网络质量影响较大，负载均衡可经过协议优化、数据压缩和智能加速等技术降低网络环境影响，提升用户访问体验。另外，外网用户会有大量反复请求，经过负载设备高速缓存技术，对静态和内容进行缓存，降低服务器数据交互，降低服务器性能压力，提升访问速度。
（7）其它
a.负载设备在服务单元内部经过旁路布署，为确保往返数据一致需要开启SNAT功效，通常情况下，WEB服务器全部需要统计用户访问源IP，可经过负载设备在HTTP头部插入X-Forwarded-for字段来透传用户真实源IP。
b.数据中心网络出口对各类设备性能要求较高，针对一些传统防火墙性能不足情况，能够在防火墙前后各布署负载均衡设备，实现防火墙负载。 需验证具体方案，包含防火墙透明和路由布署等问题。
c.考虑到极端情况，单数据中心需要能承载全部业务压力，提议选择2倍于实际性能需求负载均衡设备。负载均衡设备本身拥有过载保护机制，当CPU、内存等指标达成阀值时，向用户发出告警信息，并重定向或丢弃后续新建连接。

七、内网业务全局负载（以一级分行为例）
1.设计模型

各分行数据中心和总行数据中心经过动态路由协议互联，形成大企业内网环境。其大多数业务（ATM、POS、签章、柜面等）经过IP地址直接访问，利用RHI路由注入方法对外公布。负载设备以M+N集群方法分别布署在两个数据中心，不一样业务系统由不一样负载设备承载，处理了应用集中风险问题，同时提供灵活应用布署和无缝业务切换。
2.实现方法
（1）流量调度
以ATM业务为例，各分行数据中心对外公布业务访问IP相同，经过RHI路由注入方法和OSPF实现联动，以COST大小来判定访问最优路径。负载均衡设备以集群方法布署，单台设备和单个业务“静态绑定”，各设备间互为备份，宣告路由时基于具体业务系统进行宣告，可有效削减过多路由条目，极大简化运维工作。

如上图，数据中心对外公布4种业务，通常情况下，每台设备需要对外宣告4条路由，共16条路由，用户端最终访问路径由动态路由协议本身策略（依据COST值）决定。而采取M+N方法高可用集群，配合基于具体应用IP-Anycast技术，每台设备承载一个关键业务，其它业务在该设备作为备份状态，设备对外宣告路由时，只宣告关键业务相关路由，共4条，路由条目削减了75%。
（2）业务连续性
内网业务比较特殊，用户端位置和IP全部相对固定。不考虑故障情况，正常网络环境下，路由器依据COST判定访问路径时结果也相对固定，不存在同一用户端数次访问同一业务被调度到不一样负载情况。负载设备可依据访问源IP做会话保持，确保请求由同一服务器处理。
（3）健康状态检验
服务器：经过内置应用级健康监视器对服务器进行主动探测，提供HTTP、HTTPS、RADIUS、FTP等常见模板。对于其它应用，提供接口供用户自定义检测内容和响应内容。另外，还提供极具特色被动健康检验功效，经过对TCP和HTTP协议数据交互做采样分析，判定服务器健康状态。
链路： 提供多个方法链路健康检验，可指定探测地址和探测协议。
（4）故障切换
服务器：单台服务器故障时，负载设备将用户请求调度到其它正常服务器；当数据中心内某业务对应全部服务器故障时，负载设备会删除为该业务宣告路由，由其它负载设备接替其工作。
链路：当链路发生故障时，远端路由器和负载设备全部能够探测到故障状态，用户端访问业务系统时，路由器会选择正常链路转发数据。
负载设备：当设备本身发生故障时，集群内其它设备会自动协商出一台设备接替其工作。为确保风险可控，也能够提前设置接替次序，使切换尽可能在数据中心内部完成，降低未知风险。