【交易技术前沿】商业银行数据中心基础设施云与防火墙、负载均衡集成实践的研究 / 吴仲阳 张新晖 马国祥

本文选自 《交易技术前沿》总第三十期文章（2018年3月）

中国工商银行数据中心（上海）

吴仲阳、张新晖、马国祥

邮箱：zywu@dccsh.icbc.com.cn

商业银行数据中心基础设施云的主流解决方案之一是基于OpenStack和Ceph等开源软件并依托自主开发而建立，助力传统金融行业实现互联网金融战略转型。OpenStack对计算、存储和二三层网络的技术集成支持比较好，而对于防火墙、负载均衡的支持则相对较弱。同时由于银行业务安全监管的要求和应用系统的复杂性，在银行业的数据中心中大规模使用防火墙和负载均衡技术。强安全监管和严格流程的要求导致商业银行IT系统的生产变更数量连年增长。以工商银行数据中心（上海）为例，每年仅网络类变更数量的平均增长量就达到15%。而这大量变更中，约有60%+的变更属于防火墙策略变更和负载均衡变更（见图1），如此大体量的变更数量单单依靠人力投入无法长期维系,并且无法满足互联网金融下的快速响应要求。

图1 某商业银行变更情况

为了解决防火墙策略及负载均衡变更数量多、工作效率低、用户体验差等问题，商业银行数据中心普遍采用了一些自动化的手段来提升运营水平。但是自动化的手段还是存在如下弊端:

1、自动化手段往往与基础设施云IaaS脱节和无法联动导致无法给用户提供自服务能力。

2、自动化手段囿于IT流程的框架限制，变更流程冗长且未有突破，用户体验改善度有限。

3、自动化手段往往仅满足部分基础常见的场景，新场景定制化成本较高，对高级功能不支持。

4、自动化手段仍然将防火墙和负载均衡策略看成是网络属性，一般由网络专业团队集中受理实施，难以完全理解应用并快速响应其需求。

图2 整体架构

角色分为四类：

1）应用维护人员：自助服务的对象。

2）网络人员：策略安全规则约定、输入规范制定。

3）安全人员：策略安全规则约定、策略例外审批。

4）流程管理人员：IT服务流程管理。

关联平台:

1）云管理平台：北向提供自助服务，南向调用OpenStack API。东西向联动网管平台提供技术支撑，联动IT服务流程平台提供管理流程。

2）网管平台:为云管理平台提供输入、规则等决策的技术支撑。

4）IT服务流程平台:为云管理平台提供管理流程。

通过防火墙、负载均衡虚拟化技术将一台物理设备虚拟划分为多台相互独立的逻辑设备，为每个租户自动分配一套逻辑防火墙、负载均衡，实现物理共享、逻辑隔离，提高资源利用率。

图3 设备虚拟化

目前商业银行数据中心使用的主流防火墙和负载均衡设备均有基于多租户模式的设计，均可基于物理资源给每个租户分配虚拟设备，每一个虚拟设备之间实现故障隔离，性能按需分配。

F5负载均衡设备使用Partition（router domain）虚拟化技术为多租户提供技术支撑。通过Partition（router domain）方式创建的虚拟设备间网络结构完全隔离，共享物理CPU和内存等硬件资源，Partition的数量可到数十万量级。防火墙中各主流厂商均有相关技术支撑多租户的虚拟化，如华为USG系列和Juniper的SRX系统防火墙一台硬件防火墙可虚拟出上千个vsys（vRouter）虚拟防火墙分配给不同的租户。

OpenStack中网络支撑模块Neutron，对防火墙策略进行了建模FWaaS（Firewall as a Service）。OpenStack在建模的时候着重考虑通用性，一个模型需要适配所有的产品。因此目前OpenStack原生框架中针对防火墙仅实现了基本的功能，目前商业银行数据中心实践中使用的部分高级功能特性在FWaaS通用模型中得不到支持，存在不少差异点。通过研究梳理，OpenStack中常规的模型和商业银行数据中心生产实践所需要的的功能缺失主要在下表中，导致该模型无法在实际中直接集成使用。

表1 OpenStack FWaaS通用模型与商业银行实际中的差异

基于差异和缺失，对FWaaS进行重新整体设计，引入自定义的数据结构来支撑高级特性。整体架构设计分为Plugin、Driver、Device三个部分，整体架构设计如下图所示：

图4 FWaaS自定制模型

Plugin 对外提供Restful接口，接收Json数据并解析；对外提供CLI接口，接收命令行参数数据并执行，暴露RPC接口FirewallAgentAPI、FirewallCallbacks满足组件之间的RPC调用。

Plugin 调用Driver向上层提供的create_rule、delete_rule、update_rule三个接口直接进行防火墙策略的创建和删除，其余rule信息的维护由Plugin 维护在Neutron的DataBase中。

Driver 对外提供create_rule、delete_rule、update_rule三个接口以供Plugin组件调用，接口接收Json格式数据，用来满足Plugin对firewall_rule的创建、修改和删除。Driver 组件内维护一个data convert函数，用于上层json数据与防火墙具体配置数据之间的转换。 Driver 组件向下负责维护Device信息，用于创建Device连接信息、物理防火墙配置下发及Device连接回收等。

Device为具体物理防火墙，由防火墙供应商提供。

为了适配不同厂商的设备，将FWaaS中的plugin和driver整体解耦。定义FWaaS Plugin北向接口由上层的云管理平台进行统一入口Restful接口调用，规范FWaaS Plugin 南向接口，由各厂商Driver适配对接。

图5 FWaaS分层结构

在负载均衡与OpenStack集成思路上，有多条路径同时可供选择。

路径1：基于LBaaS V1/V2实现OpenStack原生框架内的功能

优点：通用解决方案,LBaaS为OpenStack构建的负载均衡模型，通过LBaaS可实现对HAProxy（OpenStack默认的负载均衡技术）、F5等不同厂商的支持。

缺点：由于在实现上主要考虑多种负载均衡技术的通用性，仅能实现基础的负载均衡功能，对于商业银行数据中心来说，无法满足对于例如高级应用健康检查等技术的支持。

路径2：基于HEAT编排模块，结合F5 iApp应用模板，实现高级功能的扩展

优点：官方推荐路径，如下图所示，通过OpenStack的流程编排模块HEAT模板，结合F5的应用模板可满足目前所需的高级功能的支持。模板使用Yaml脚本可基于场景灵活定制，模板可归类、可复制和可扩展。

图6 LBaaS与Heat实现对比

缺点：用户成熟案例较少。

路径3：基于云管理平台+Restful API，实现按需的高级功能调用及实现；

优点：F5设备本身向外暴露iControl的Restful API，可通过云管理平台调用API接口，实现对F5的管理。实现较为灵活。

缺点：场景化要求过高，相较于命令行的模式没有明显优势。且兼容性不高，若采用其他的负载均衡技术，整套体系需要重建。

经过反复研究论证确定选择集成路径2。首先由OpenStack原生的LBaaS模型提供基础功能，其次结合OpenStack流程编排模块HEAT，定义适配商业银行数据中心的负载均衡设备的自定义资源，提供高级功能，相关的流程如下图。

图7 Heat流程图

OpenStack的整体模型在各种资源如虚拟机、防火墙策略都是单向的，通过OpenStack层面的数据沉淀记录并下发到设备。但是必需考虑高可靠的问题，OpenStack层面的“账本”与实际落到设备上的“账本”无法完全一一对应。OpenStack无法检测到设备在下发过程中异常重启所引发的运行配置与保存配置不一致和不同步。

为了解决“账实不一”的不一致风险，在自研的模型中增加一系列“对账”的功能确保配置的高可靠性。一是针对防火墙策略规则定期或者主动触发进行对账，获取设备上的规则与OpenStack的规则进行验证；二是主动获取策略命中的情况来配合用户的验证。将单向模型优化成双向模型，确保策略的准确性和一致性。

图8 OpenStack“单向”模型

随着商业银行数据中心IT架构转型，云计算逐步推广，在自助服务与传统自动化体系的关系上存在如下两条路径的分歧：

1）继续走自动化的路，在管理平面上将云环境里的网络设备和传统环境的网络设备拉齐，依托IT服务流程提供统一的管理界面。

2）双轨制，云环境里的网络设备管理通过OpenStack的ML2，FWaaS，LBaaS模型建模，联动OpenStack的数据库，探索IT服务流程的突破，提供对网络设备的自助管理。

通过深入研究，我们认为在处理云自助服务和传统环境自动化的关系时，应该基于如下几个基本原则：

1）应用入云是大势所趋，云内的需求会越来越多。

2）传统统环境在一段时间内与云环境共存。

3）通过自助服务提升云环境的用户体验，传统环境仍然保留自动化的方式提升工作效率。自助服务与交易化分头建设，并保持模块松耦合的原则。

图9 自助服务与自动化的关系