双活数据中心方案

双活数据中心方案一、需求背景：随着数据的大集中，银行纷纷建设了负责本行各业务处理的生产数据中心机房（一般称为数据中心） ，数据中心因其负担了全行业务，所以其并发业务负荷能力和不间断运行能力是评价一个数据中心成熟与否的关键性指标。近年来，随着网上银行、 手机银行等各种互联网业务的迅猛发展， 银行数据中心的业务压力业成倍增加， 用户对于业务访问质量的要求也越来越高， 保障业务系统的 7*24 小时连续运营并提升用户体验成为信息部门的首要职责。商业银行信息系统的安全、 稳定运行关系着国家金融安全和社会稳定， 监管机构也十分重视商业银行的灾难备份体系建设， 多次发布了商业银行信息系统灾难备份的相关标准和指引，对商业银行灾备系统建设提出了明确的要求。为适应互联网业务的快速增长， 保障银行各业务安全稳定的不间断运行， 提高市场竞争力， 同时符合监管机构的相关要求， 建设灾备、 双活甚至多活数据中心正在成为商业银行的共同选择。二、发展趋势：多数据中心的建设需要投入大量资金， 其项目周期往往很长， 涉及的范围也比较大。从技术上来说，要实现真正意义上的双活，就要求网络、应用、数据库和存储都要双活。 就现阶段来看，大多数客户的多数据中心建设还达不到完全的双活要求，主流的建设目标是实现应用双活。 目前客户建设多数据中心的模型可以归纳为以下几种：1. 单纯的数据容灾：正常情况下只有主数据中心投入运行， 备数据中心处于待命状态。 发生灾难时，灾备数据中心可以短时间内恢复业务并投入运行， 减轻灾难带来的损失。 这种模式只能解决业务连续性的需求， 但用户无法就近快速接入。 灾备中心建设的投资巨大且运维成本高昂，正常情况下灾备中心不对外服务，资源利用率偏低，造成了巨大的浪费。2. 构建业务连续性：两个数据中心（同城 / 异地）的应用都处于活动状态，都有业务对外提供服务且互为备份。但出于技术成熟度、 成本等因素考虑， 数据库采用主备方式部署，数据库读写操作都在主中心进行， 灾备中心进行数据同步。 发生灾难时， 数据中心间的数据库可以快速切换， 避免业务中断。 双活数据中心可充分盘活企业闲置资源，保证业务的连续性，帮助用户接入最优节点，提高用户访问体验。3. 提升业务服务能力：多个数据中心同时对外提供服务且互为备份， 各中心的数据库可同时处理应用的读写请求， 网络、存储、应用和数据库全部实现多活。 各数据中心独立运营，用户流量可被智能调度，形成灵活、弹性和可扩展的面向服务的业务架构。三、业务目标：用户建设多数据中心的思路和建设模型略有不同，但大多数用户的主要建设目标可以归纳为以下几点：流量分发用户访问流量可灵活、弹性的调度到多个数据中心，使各数据中心压力相对均衡，保证用户接入最近最快速的数据中心节点，提高用户访问体验。故障切换当出口链路或内部服务器出现异常时，运维人员可第一时间获悉故障情况，业务可根据需要自动或手动平滑切换至正常节点，保证用户访问的连续性。业务安全数据中心所处位置基础设施完善，水电通信供应稳定，数据中心内部有相应技术手段保证整个数据中心抵抗DDos攻击，各业务系统不被黑客非法入侵。环境一致性多个数据中心对用户来说理应是透明的，其对外服务时提供统一接口，各数据中心内部数据和服务能力需要完全一致，且随时处于可切换状态。四、实现逻辑我们把整个数据中心在逻辑上分为接入层和服务层，其处理逻辑的示意图如下：接入层（智能 DNS）接入层（ RHI 路由注入）服务层故障切换五、总体设计总行数据中心整体上分为主中心和灾备中心， 二者的网络架构、 业务系统和服务能力都基本相同， 同时对外提供服务， 形成双活数据中心。 数据中心内部划分为互联网业务区（提供外网服务，如手机银行、网上银行等） 、核心生产业务区（传统生产业务，如 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）业务连续性数据中心层面：通过DCCookie 保证用户接入同一数据中心。用户首次访问时，本地 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安全。服务单元层面：各服务单元部署防火墙，保证区域安全。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）故障切换服务器：单台服务器故障时，负载设备将用户请求调度到其他正常服务器；当数据中心内某业务对应的所有服务器故障时， 负载设备会删除为该业务宣告的路由，由其他负载设备接替其工作。链路：当链路发生故障时，远端路由器和负载设备都可以探测到故障状态，客户端访问业务系统时，路由器会选择正常链路转发数据。负载设备：当设备自身发生故障时， 集群内其余设备会自动协商出一台设备接替其工作。 为保证风险可控， 也可以提前设置接替顺序， 使切换尽量在数据中心内部完成，减少未知风险。