农商行容器云平台灾备建设实践经验分享

    某农商行容器云平台灾备建设实践经验分享    文章简介：本文以中小银行数字化转型为背景，对中小银行传统应用迁移容器云平台的实践经验进行总结，探索出适合中小银行特有金融架构特征的容器云平台建设路线。从业务需求出发，通过建设以容器云平台为基础的底层IT资源平台，为业务发展提供安全、稳定、可靠、灵活的支撑。同时，本文也将针对容器云平台落地面临的容器灾备、容器云网络建设等问题进行选型和实践经验分享。一、  建设背景近年来，随着金融业务不断扩展，云计算技术在金融行业的发展已经经历过了第一代虚拟化、第二代资源池化，正在向以容器、微服务、DevOps为关键技术和特征的第三代云计算技术前进，以满足金融业新型业务对快速部署、弹性扩展、自动化运维等核心需求。金融行业已经步入以容器为核心的第三代云计算技术的时代，目前国内大型金融机构虚拟化技术相对成熟，从国有五大行到区域银行都在积极向基础设施云推进，但中小银行相对缓慢，更多处于云平台的尝试使用阶段。面对高并发、多频次、大流量的全新业务场景，银行业务系统的响应效率变的越发重要，同时金融业务的服务连续性要求也越来越高。而我行原有的基础架构平台已不足以支撑银行当前的高速信息化建设及创新发展要求。如何应对不断升级的互联网业务系统，紧跟大行科技信息化建设的步伐，建设具有中小银行特有金融架构特征的容器云平台变得尤为重要。二、  需求分析在银行数字化转型的进程中，传统虚拟化在一定程度上降低了运维的复杂度，提升了资源的利用率，解决了IaaS层面基础设施的问题。但在金融业务数字化转型趋势下，传统应用系统框架正加速向新型互联网金融业务框架改造和升级，银行运维管理部门面临的互联网时代下对金融IT基础架构挑战也越发明显，具体的需求和挑战主要有以下几方面：1、基础设施建设层面。金融云数据中心一直以来都习惯采用最成熟稳定的IT技术路线通常使用国外主流厂商提供的商业产品和相关技术来构建数据中心，在技术实施、支持和运维保障等方面很大程度依赖设备供应商，这使得金融行业自身缺乏核心的技术积累；传统技术方案根据业务峰值来配置基础设计资源，造成大量的资源浪费，拉高了金融IT建设成本。因此需采用先进的成熟技术，借鉴同等规模的金融单位实际建设应用情况，同时满足信创国产化诉求，避免一家厂商绑定的情况。结合我行的VMware使用现状，现行考虑与Openstack的商业化厂商进行深度合作。2、多云管理与服务运营。随着金融业务的迅速发展以及规模的不断扩大，金融IT系统的数量、规模和复杂度也呈现几何级数增长。金融虽然数据中心完成了大集中建设，但依然延续了传统的建设模式、传统的技术方案。因此多厂商、多云共存、多控制平面分别管理的现状，各自独立运维管理，增加了管理复杂度等问题，同时无法提供可视化的运营管理。结合我行的未来建设需求，考虑通过CMP建设统一的管理平面，解决多云统一化运维难题，同时通过服务目录设计与自服务功能，解决多云统一化运营难题。3、业务快速响应。在金融服务互联网化以及利差市场化的挑战下，金融业务转型已经成了唯一出路，各大金融机构也将互联网化提升到了发展战略，并以此快速推出创新业务。但这些新目标所需要的海量处理能力基本上无法通过传统IT基础设施设计模式有效满足，传统商业方案的天花板是大型机模式，但高昂的建设成本和漫长的建设周期也是企业无法承受的，探索高效、弹性、成本合理的新型基础设施建设模式已经成为金融IT建设的必然选择，同时传统建设模式和方案不利于大规模弹性伸缩，为了弥补这些与生居来的问题，传统方案设计上愈来愈复杂。因此IaaS层建设通过SDDC进行实现，采用多云、多技术栈架构，应对不同的业务场景，快速响应业务需求，如通过Openstack、Kubernetes等技术，建设业务的弹性能力、快速扩容能力、DevOps能力。4、云平台容灾备份。金融云平台业务连续性要求愈发严格，运行风险日益增大，数据中心稳定运行的风险越来越突出，保证数据安全、业务连续性满足金融云的合规安全需求。因此实现主数据中心不可用情况下，备数据中心无缝割接网络及接管主数据中心业务系统，保障业务系统安全和业务服务的持续势在必行。我行近两年已构建了基于Iaas平台的“两地三中心”基础架构，数据中心服务能力由传统主备服务能力向云上的“双活”或“多活”中心服务能力提升。为满足进一步发展建设的需求，需以围绕提升银行内部开发效率，逐步改善原有IT基础资源管理方式，提高资源利用率为目标，构建以超融合为基础的IaaS虚拟化平台和容器云平台组成的底层IT资源平台。三、  技术路线选型及难点分析1、现有IT架构和业务架构的痛点我行在IT架构技术演变过程中，需要考虑到两点，分别是IT组织内部的降本增效，提升资源和产品的交付能力，同时还要具备较高且灵活的业务架构的适配，更好的支撑业务。业务架构以实现企业的经营战略为目标，构建全面的市场化业务能力并实现对接IT架构的能力，IT架构需具备安全性、稳定性和可扩展性，提供端对端的支撑。业务架构和IT架构随着企业的业务发展，两者之间的边界已经不再泾渭分明，因此IT架构也需要通过技术的手段帮助IT团队加深对业务架构的理解，目前主流的方法是通过对IaaS能力的下沉，PaaS能力的平台化进行实现。目前，主要痛点在于因IaaS过多的承担资源单向输出，更多的面对信息化建设场景，无法从企业战略的需求提供更优质的弹性伸缩能力，而业务需求的不稳定性也加速这种矛盾的爆发，因此这种输出能力的滞后性也带来了对于业务的高稳定性和高可靠性的挑战。图：业务架构和IT架构的关系结合我行现阶段的发展情况进行规划分析，通过服务器虚拟化及容器虚拟化技术，作为基础架构底座，来建设金融云平台。基于容器技术的基础架构革新势在必行，这是面向业务“云迁移”的一个重要分支。通过容器云的敏捷性提升开发运维上线速度，提高跨环境的高一致性，提高开发交付质量；通过容器云的弹性伸缩能力，消除单点故障，提升业务访问效率；通过可扩展性，实现细粒度动态扩展和最大化的组件、资源密度，从而充分利用基础架构资源。2、容器云建设难点分析金融云平台整体包括IaaS和容器两部分，金融云平台为本项目建设范围，包括基础设施云平台、容器云平台、统一云管理平台、DevOpS、云安全和云灾备。在建设容器云平台的过程中，特别是在传统的金融银行业对监管要求严格的情况之下，容器云平台的落地会面临很多的问题和挑战。· 灾备多活我行近两年已构建了基于Iaas平台的“两地三中心”的基础架构，核心数据库通过iaas层的存储双活方式进行构建，防范物理性的故障导致数据丢失问题；重要数据通过备份软件进行数据冷备，防范逻辑故障导致的数据丢失问题。看似架构完整，其实存在众多问题，例如：主备数据中心负载问题、应用切换问题、数据库同步及切换等问题。我行此次的规划是建设金融行业云平台，满足金融的监管需求以外，如何满足灾备多活的建设目标，建设的难点在于容器云“多云多活”，多套容器云多数据中心，实现业务应用流量的负载及切换，数据的实时同步等。· 容器网络目前，行业内容器云网络建设没有标准化的建设方案，容器云网络方案可谓百家争鸣。既要满足行内本身的技术架构体系，又必须同时满足各个团队对于业务、运维等方面的诉求，如：平台内外网络能够直接打通；管理网络和数据网络分离；具备网络隔离能力，硬件隔离的强安全性和软件隔离的灵活性；网络模型力求简单，易于掌控，易于调试；高性能，低抖动的网络吞吐及增加固定 IP 的能力；能够与SDN无缝对接能力；能够支持IPv6的网络等。另外，如何利用容器云平台同时支持开发测试场景及生产场景，且提高效率；生产场景又不同于开发测试场景，上线一套系统要求更为严格，安全、监控、流程、原有系统集成等等的建设要求都要匹配上。这些问题在容器云平台的建设过程中都是需要考虑的难点。2、容器云技术路线选型金融行业作为一个高度监管的行业，对服务的可用性以及数据的安全性要求相对其他行业更高，同时在初期平台架构设计与选型时也需全局综合考虑各种因素：1)     考虑自身的技术能力，包括开发能力、运维能力；2)     考虑现有系统对接需求，包括监控、网络、安全需求等；3)     所选技术需符合当前潮流与未来发展趋势，有较好的生态链和较强的生命力，但同时也需在先进性与稳定性之间寻求平衡点；4)     能满足银行业务不断的发展与创新的需求，尽量做到平台横向平滑扩展。基于以上因素及现有架构的痛点，在众多的容器云解决方案中，我行选择了目前容器云平台最主流的解决方案，即以docker+kubernetes为代表的容器技术和应用部署方案。Docker容器技术有几个优势，一是在一台物理机上启动多个在独立沙箱内运作的应用，相互不影响，无Guest OS，资源利用率更高；二是Docker基于镜像的方式将应用及所有依赖打包，使docker具备快速部署，快速启动，快速故障恢复，开发运维一体等优秀特性；三是以统一的方式跨平台云发布应用。Kubernetes是用于自动部署、扩展和容器化应用程序的开源容器编排平台。当使用的容器服务增加、面临的访问量加大时，需一种工具将容器进行统一管理，实现对这些容器的自动部署、扩展和管理。4、厂商选型目前国内很多单位利用开源技术构建云计算架构，但是纯粹的开源软件存在诸多问题，如：开源软件的成熟度，安装部署的易用性，运维的复杂度等方面都存在着或多或少的问题，开源软件无法及时响应处理故障。因此开源产品对于金融云平台需要高标准、高可靠等要求来说其实是个问题，所以要选择有实践经验的商业版本供应商。另外考虑到金融云未来长期的发展和一体化集成诉求及便捷性、技术可行性，所以我行选择由一家专业厂商统一建设。   同时，为了解决kubernetes落地时的网络难题，我行对目前市场容器平台的网络CNI插件进行了调研。虽然目前容器平台的网络CNI插件有多种，但主流的CNI插件对某些需求的支持并不理想，难以同时满足某些网络需求，如内外网互通、管理业务网络分离、灵活的网络隔离机制、易于运维管理和调试等需求。基于我行目前的业务需求，技术选项阶段我行针对主流的三层网络calicao和二层网络Fabric进行了比较，最终考虑采用二层网络进行构建。以下为两者的比较结果：结合我行的现状，通过对当前主流容器平台openshift3、openshift4、Rancher、博云等国内外容器厂商的产品进行功能、性能对比，经过综合评估，最终我行选择与在容器及容器网络方面有丰富经验的本土化容器厂商博云合作。同时，容器云的网络建设作为本次金融云规划的重点之一，前期通过大量的调研，内部业务运维部门沟通，最终采用的是博云基于OVS自研的容器网络插件。其可以很好地利用物理网络设备，结合当前网络需求的特点，提高网络访问效率。方案上使用fabric网络组件，将容器管理网与应用业务进行分离，业务网络与管理网都为实际物理层面的二层网络，可以让容器的IP直接对外提供访问服务。以下为使用fabric网络的应用Pod在IaaS平台中的桥接过程，即Pod桥接在各K8S节点中的OVS，K8S节点桥接在IaaS计算节点的OVS，流量最终直接进入物理交换机。通过Fabric打造纯二层网络模式，解决了我行金融容器云网络的以下建设难题：从运维管理角度，采用了二层网络模型，无需引入三层网络方案，同时将管理网络和业务网络进行分离，简化运维、提升工作效率。金融容器云内部网络与外部网络互联互通，业务应用往往会在容器云平台内外同时部署，平台内外网络直接打通，POD与虚拟机/物理机同等地位，有利于与已有的云产品无缝整合。网络安全性方面，支持Pod固定IP地址，应用互访跨防火墙的等场景下，POD具备固定IP地址。灵活的网络隔离：包括强安全性的硬件隔离和灵活的软件隔离。网络性能方面，提供高性能，低抖动的网络环