双活数据中心方案.docx

双活数据中心方案 一、 需求背景： 随着数据 的 大集中，银行纷纷建设了负责本行各业务处理的生产数据中心机房（一般称为数据 中心），数据中心因其负担了全行业务，所以其并发业务负荷能力和 不间断运行能力是评价一个数据中心成熟与否的关键性指标。 近年来， 随着 网上银行、手机银行等各种互联网 业务 的迅猛 发展 ，银行 数据中心的业务 压力 业 成倍增加 ， 用户对于 业务 访问质量 的要求也越来越高 ， 保障 业务 系统 的 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） 业务连续性 数据中心层面： 通过 DC C ookie保证 用户 接入同一数据中心。 用户首次访问时， 本地WEB负载 设备 在 响应 数据包中插入 DC C ookie ，当客户端网络发生变化时，第二次访问 就 可能被调度到其他数据中心，这时 其他数据中心的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）故障切换 服务器： 单台服务器故障时，负载设备将用户请求调度到其他正常服务器；当数据中心内某 业务对应的所有服务器故障时，负载设备会删除为该业务宣告的路由，由其他负载设备接替其工作。 链路：当链路发生故障时，远端路由器和负载设备都可以探测到故障状态，客户端访问业务系统时，路由器会选择正常链路转发数据。 负载设备： 当设备自身发生故障时，集群内其余设备会自动协商出一台设备接替其工作。为保证风险可控，也可以提前设置接替顺序，使切换尽量在数据中心内部完成，减少未知风险。