容器云平台灾备建设方案.docx

《容器云平台灾备建设方案.docx》由会员分享，可在线阅读，更多相关《容器云平台灾备建设方案.docx（19页珍藏版）》请在三一办公上搜索。

1、容器云平台灾备建设方案目录容器云平台灾建设方案1一、建设背景3二、需求分析3三、技术路线选型及难点分析51、现有IT架构和业务架构的痛点52、容器云建设难点分析63、容器云技术路线选型64、厂商选型7四、建设方案101、总体架构102、容器云平台灾备112.1部署架构112.2切换架构112.3网络切换124、环境规划16五、实施经验及效果161、实施经验总结162、实施效果173、建议实施落地原则181、IaaS云平台建设：182、PaaS云平台建设： 193、云管理系统建设：19本公【简介】本文以中小银行数字化转型为背景，对中小银行传统应用迁移容器云平台的 实践经验进行总结，探索出适合中小

2、银行特有金融架构特征的容器云平台建设路线。从业务 需求出发，通过建设以容器云平台为基础的底层IT资源平台，为业务发展提供安全、稳 定、可靠、灵活的支撑。同时，本文也将针对容器云平台落地面临的容器灾备、容器云网络 建设等问题进行选型和实践经验分享。一、建设背景近年来，随着金融业务不断扩展，云计算技术在金融行业的发展已经经历过了第一代虚拟 化、第二代资源池化，正在向以容器、微服务、DevOps为关键技术和特征的第三代云计算 技术前进，以满足金融业新型业务对快速部署、弹性扩展、自动化运维等核心需求。金融行业已经步入以容器为核心的第三代云计算技术的时代，目前国内大型金融机构虚拟化 技术相对成熟，从国有

3、五大行到区域银行都在积极向基础设施云推进，但中小银行相对缓 慢，更多处于云平台的尝试使用阶段。面对高并发、多频次、大流量的全新业务场景，银行业务系统的响应效率变的越发重要，同 时金融业务的服务连续性要求也越来越高。而我行原有的基础架构平台已不足以支撑银行当 前的高速信息化建设及创新发展要求。如何应对不断升级的互联网业务系统，紧跟大行科技 信息化建设的步伐，建设具有中小银行特有金融架构特征的容器云平台变得尤为重要。二、需求分析在银行数字化转型的进程中，传统虚拟化在一定程度上降低了运维的复杂度，提升了资源的 利用率，解决了 IaaS层面基础设施的问题。但在金融业务数字化转型趋势下，传统应用系 统框

4、架正加速向新型互联网金融业务框架改造和升级，银行运维管理部门面临的互联网时代 下对金融IT基础架构挑战也越发明显，具体的需求和挑战主要有以下几方面：1基础设施建设层面金融云数据中心一直以来都习惯采用最成熟稳定的IT技术路线通常 使用国夕卜主流厂商提供的商业产品和相关技术来构建数据中心，在技术实施、支持和运维保 障等方面很大程度依赖设备供应商，这使得金融行业自身缺乏核心的技术积累；传统技术方 案根据业务峰值来配置基础设计资源，造成大量的资源浪费，拉高了金融IT建设成本。因 此需采用先进的成熟技术，借鉴同等规模的金融单位实际建设应用情况，同时满足信创国产 化诉求，避免一家厂商绑定的情况。结合我行的

5、VMware使用现状，现行考虑与 Openstack的商业化厂商进行深度合作。2、多云管理与服务运营。随着金融业务的迅速发展以及规模的不断扩大，金融IT系统的数 量、规模和复杂度也呈现几何级数增长。金融虽然数据中心完成了大集中建设，但依然延续 了传统的建设模式、传统的技术方案。因此多厂商、多云共存、多控制平面分别管理的现 状，各自独立运维管理，增加了管理复杂度等问题，同时无法提供可视化的运营管理。结合 我行的未来建设需求，考虑通过CMP建设统一的管理平面，解决多云统一化运维难题，同 时通过服务目录设计与自服务功能，解决多云统一化运营难题。3、业务快速响应。在金融服务互联网化以及利差市场化的挑战

6、下，金融业务转型已经成了 唯一出路，各大金融机构也将互联网化提升到了发展战略，并以此快速推出创新业务。但这 些新目标所需要的海量处理能力基本上无法通过传统IT基础设施设计模式有效满足，传统 商业方案的天花板是大型机模式，但高昂的建设成本和漫长的建设周期也是企业无法承受 的，探索高效、弹性、成本合理的新型基础设施建设模式已经成为金融IT建设的必然选 择，同时传统建设模式和方案不利于大规模弹性伸缩，为了弥补这些与生居来的问题，传统 方案设计上愈来愈复杂。因此IaaS层建设通过SDDC进行实现，采用多云、多技术栈架 构，应对不同的业务场景，快速响应业务需求，如通过Openstack、Kubernet

7、es等技术， 建设业务的弹性能力、快速扩容能力、DevOps能力。4、云平台容灾备价。金融云平台业务连续性要求愈发严格，运行风险日益增大，数据中心 稳定运行的风险越来越突出，保证数据安全、业务连续性满足金融云的合规安全需求。因此 实现主数据中心不可用情况下，备数据中心无缝割接网络及接管主数据中心业务系统，保障 业务系统安全和业务服务的持续势在必行。我行近两年已构建了基于Iaas平台的两地三中心”基础架构，数据中心服务能力由传统 主备服务能力向云上的“双活”或多活”中心服务能力提升。为满足进一步发展建设的需 求，需以围绕提升银行内部开发效率，逐步改善原有IT基础资源管理方式，提高资源利用 率为目

8、标，构建以超融合为基础的IaaS虚拟化平台和容器云平台组成的底层IT资源平台。三、技术路线选型及难点分析1, 现有!1架构和业务架构的痛点我行在IT架构技术演变过程中，需要考虑到两点，分别是IT组织内部的降本增效，提升资 源和产品的交付能力，同时还要具备较高且灵活的业务架构的适配，更好的支撑业务。业务架构以实现企业的经营战略为目标，构建全面的市场化业务能力并实现对接IT架构的 能力，IT架构需具备安全性、稳定性和可扩展性，提供端对端的支撑。业务架构和IT架构 随着企业的业务发展，两者之间的边界已经不再泾渭分明，因此IT架构也需要通过技术的 手段帮助IT团队加深对业务架构的理解，目前主流的方法是

9、通过对IaaS能力的下沉， PaaS能力的平台化进行实现。目前，主要痛点在于因IaaS过多的承担资源单向输出，更多的面对信息化建设场景，无法 从企业战略的需求提供更优质的弹性伸缩能力，而业务需求的不稳定性也加速这种矛盾的爆 发，因此这种输出能力的滞后性也带来了对于业务的高稳定性和高可靠性的挑战。图：业务架构和IT架构的关系结合我行现阶段的发展情况进行规划分析，通过服务器虚拟化及容器虚拟化技术，作为基础 架构底座，来建设金融云平台。基于容器技术的基础架构革新势在必行，这是面向业务云 迁移”的一个重要分支。通过容器云的敏捷性提升开发运维上线速度，提高跨环境的高一致 性，提高开发交付质量；通过容器云

10、的弹性伸缩能力，消除单点故障，提升业务访问效率； 通过可扩展性，实现细粒度动态扩展和最大化的组件、资源密度，从而充分利用基础架构资 源。2、容器云建设难点分析金融云平台整体包括IaaS和容器两部分，金融云平台为本项目建设范围，包括基础设施云 平台、容器云平台、统一云管理平台、DevOpS、云安全和云灾备。在建设容器云平台的过程中，特别是在传统的金融银行业对监管要求严格的情况之下，容器 云平台的落地会面临很多的问题和挑战。灾备多活我行近两年已构建了基于Iaas平台的两地三中心”的基础架构，核心数据库通过iaas层 的存储双活方式进行构建，防范物理性的故障导致数据丢失问题；重要数据通过备份软件进

11、行数据冷备，防范逻辑故障导致的数据丢失问题。看似架构完整，其实存在众多问题，例 如：主备数据中心负载问题、应用切换问题、数据库同步及切换等问题。我行此次的规划是建设金融行业云平台，满足金融的监管需求以外，如何满足灾备多活的建 设目标，建设的难点在于容器云多云多活”，多套容器云多数据中心，实现业务应用流量 的负载及切换，数据的实时同步等。容网络目前，行业内容器云网络建设没有标准化的建设方案，容器云网络方案可谓百家争鸣。既要 满足行内本身的技术架构体系，又必须同时满足各个团队对于业务、运维等方面的诉求， 如：平台内外网络能够直接打通；管理网络和数据网络分离；具备网络隔离能力，硬件隔离 的强安全性和

12、软件隔离的灵活性；网络模型力求简单，易于掌控，易于调试；高性能，低抖 动的网络吞吐及增加固定IP的能力；能够与SDN无缝对接能力；能够支持IPv6的网络 等。另外，如何利用容器云平台同时支持开发测试场景及生产场景，且提高效率；生产场景又不 同于开发测试场景，上线一套系统要求更为严格，安全、监控、流程、原有系统集成等等的 建设要求都要匹配上。这些问题在容器云平台的建设过程中都是需要考虑的难点。3、容器云技术路线选型金融行业作为一个高度监管的行业，对服务的可用性以及数据的安全性要求相对其他行业更 高，同时在初期平台架构设计与选型时也需全局综合考虑各种因素：1）考虑自身的技术能力，包括开发能力、运维

13、能力；2）考虑现有系统对接需求，包括监控、网络、安全需求等；3）所选技术需符合当前潮流与未来发展趋势，有较好的生态链和较强的生命力，但同时也需 在先进性与稳定性之间寻求平衡点；4）能满足银行业务不断的发展与创新的需求，尽量做到平台横向平滑扩展。基于以上因素及现有架构的痛点，在众多的容器云解决方案中，我行选择了目前容器云平台 最主流的解决方案，即以docker+kubernetes为代表的容器技术和应用部署方案。Docker容器技术有几个优势，一是在一台物理机上启动多个在独立沙箱内运作的应用，相 互不影响，无Guest OS，资源利用率更高；二是Docker基于镜像的方式将应用及所有依 赖打包，

14、使docker具备快速部署，快速启动，快速故障恢复，开发运维一体等优秀特性； 三是以统一的方式跨平台云发布应用。Kubernetes是用于自动部署、扩展和容器化应用程序的开源容器编排平台。当使用的容器 服务增加、面临的访问量加大时，需一种工具将容器进行统一管理，实现对这些容器的自动 部署、扩展和管理。4、厂商选型目前国内很多单位利用开源技术构建云计算架构，但是纯粹的开源软件存在诸多问题，如： 开源软件的成熟度，安装部署的易用性，运维的复杂度等方面都存在着或多或少的问题，开 源软件无法及时响应处理故障。因此开源产品对于金融云平台需要高标准、高可靠等要求来说其实是个问题，所以要选择有 实践经验的商

15、业版本供应商。另夕卜考虑到金融云未来长期的发展和一体化集成诉求及便捷 性、技术可行性，所以我行选择由一家专业厂商统一建设。同时，为了解决kubernetes落地时的网络难题，我行对目前市场容器平台的网络CNI插 件进行了调研。虽然目前容器平台的网络CNI插件有多种，但主流的CNI插件对某些需求 的支持并不理想，难以同时满足某些网络需求，如内外网互通、管理业务网络分离、灵活的 网络隔离机制、易于运维管理和调试等需求。基于我行目前的业务需求，技术选项阶段我行针对主流的三层网络calica。和二层网络 Fabric进行了比较，最终考虑采用二层网络进行构建。以下为两者的比较结果：CalicoFabri

16、c underlay组网模型L3, BGPL2, OVSIP 地址池私有地址池，默认65536个申请业务网段，通常一个网段包甲地址括256个IP地址。（1）采用 VxLAN后可以使用私有地址池安全策略困难，地址池巨大且应用弹 性伸缩时IP不可控轻松，结合固定IP功能实现 span = 应用，地址池的分 配BIP 地址困难支持动态QoS原生不支持，BOC支持支持环境依赖支持overlay模式减少环境 依赖，对公有云、私有 云支 持友好Underlay模式依赖现场组网环 境，对公有云等环境支持有限负载均衡支持，弹性伸缩时自动变更 配置支持，弹性伸缩时自动变更配置平台内外网络接通信繁琐，需在外部网络

17、设备中启用BGP功能简单，容器像传统虚拟机一样融 入企业现网环境扩展性（大规 模集群）三层组网，扩展性优秀，大 规模下需引入路由反射器二层组网，单VLAN扩展能力有限，集群可以管理多个VLAN以满足扩展性性能IPIP=OFF时损耗在5%左 右，IPIP=ON时损耗较大优秀，损耗在5%左右网络可视化中等，GUI查看各网段IP分配 情况网络隔离通过iptables支持Kubernetes NetworkPolicy对象实现隔离基于VLAN隔离，支持 NetworkPolicy隔离，支持租 户隔离（2）企业采用IPV6后，地址 池紧张的问题将得到缓解结合我行的现状，通过对当前主流容器平台Opensh

18、ift3、Openshift4、Rancher、博云等 国内外卜容器厂商的产品进行功能、性能对比，经过综合评估，最终我行选择与在容器及容器 网络方面有丰富经验的本土化容器厂商博云合作。同时，容器云的网络建设作为本次金融云规划的重点之一，前期通过大量的调研，内部业务 运维部门沟通，最终采用的是博云基于OVS自研的容器网络插件。其可以很好地利用物理 网络设备，结合当前网络需求的特点，提高网络访问效率。方案上使用fabric网络组件， 将容器管理网与应用业务进行分离，业务网络与管理网都为实际物理层面的二层网络，可以 让容器的IP直接对外提供访问服务。以下为使用fabric网络的应用Pod在IaaS平

19、台中的桥接过程，即Pod桥接在各K8S节点 中的OVS，K8S节点桥接在IaaS计算节点的OVS，流量最终直接进入物理交换机。trunkCNo IPM port 1 Iport 2vllan 10vlan 20VSbocO|No IP通过Fabric打造纯二层网络模式，解决了我行金融容器云网络的以下建设难题：从运维管理角度，采用了二层网络模型，无需引入三层网络方案，同时将管理网络和业务网 络进行分离，简化运维、提升工作效率。金融容器云内部网络与外部网络互联互通，业务应用往往会在容器云平台内外同时部署，平 台内外网络直接打通，POD与虚拟机/物理机同等地位，有利于与已有的云产品无缝整合。网络安全

20、性方面，支持Pod固定IP地址，应用互访跨防火墙的等场景下，POD具备固定 IP地址。灵活的网络隔离：包括强安全性的硬件隔离和灵活的软件隔离。网络性能方面，提供高性能，低抖动的网络环境。网络模型同时支持Underlay和 Overlay : Underlay性能好，可以内外网互通；Overlay不依赖底层网络，灵活性强，最 好可以同时支持。对于我行未来的网络扩展方面，能够满足IPV6的建设。四、建设方案我行整个金融云平台建设是从一个完整的架构角度考虑IaaS层的搭建，从VMware扩展到 OpenStack，在底层各种虚拟化技术之上，通过云管平台对底层的各种资源进行纳管，而 容器技术仅是我行金

21、融云平台中采用的众多新技术其中之一。本章节重点阐述容器云平台的 建设实践解决方案。1、总体架构从云化视角，三朵云支撑我行云化逐步落地。三朵云为：开发测试云和生产云，其中生产云 包含生产和灾备两套云平台。通过博云产品提供的多云管理Portal和DevOps Portal实现底层资源管理及运维操作管理。多云管理Portal主要提供云资源的统一管理、多租户服 务、自动化作业、用户自服务等能力。DevOps Portal提供容器应用持续集成和部署管理，通过代码和应用包完成一键发布、变更。生产环境中，完成应用的多中心部署和F5负 载均衡自动注册，通过应用包或者镜像进行发布。项目整体建设目标如下:根据我行

22、的建设要求，实际交付开发测试云和生产云，其中生产云包含生产和灾备两套云平 台支撑，实现应用的云化、数据的容灾。统一管理界面将分为操作基础设施资源的云管理平 台界面和操作应用容器化发布的容器管理界面，实现资源的集中化管理及变更等服务。底层 架构由OpenStack架构、Kubernetes架构、F5负载均衡设备提供基础设施支撑，实现多 机房、多设备、多业务系统的稳定运行、快速交付。2, 容器云平台灾备容器云平台灾备建设也是本次建设规划的难点之一，灾备设计方案主要考虑数据级备份、应 用级备份和网络切换。数据层面根据数据类型，采用行内平台承载和多地部署同步方式，保 障数据一致性；应用层根据应用类型，

23、采用多活部署和单体部署加备份方式，保障应用服务 可用性和连续性；网络流量的切割依赖F5负载均衡DNS方案，保障访问流量的自动切 割。通过主备数据中心对单体应用备份和多活应用双数据中心部署的方式，结合应用数据外置挂 载和主备数据中心三层网络可达的部署，保障IaaS平台应用在某数据中心发生灾难时，应 用服务可以在短暂时间内迅速恢复。2.1部署架构基于多活的应用架构，在内网区部署容器平台管理，纳管云内网区K8S集群、云互联/外联 区K8S集群、灾备云内网区K8S集群、灾备云互联/外联区K8S集群，应用在主数据中心 和备数据中心同时部署，共用行内平台中承载的应用数据、应用数据库和公共中间件；基于 不支

24、持多活部署的应用架构，部署备份平台。部署架构2.2切换架构 基于多活的应用架构，主数据中心出现数据中心故障后，访问的流量切换至备数据中心；备 数据中心出现数据中心故障后，访问的流量切换至主数据中心；基于不支持多活部署的应用 架构，备份平台启动备份应用虚机，承载访问流量。切换架构2.3网络切换2.3.1 F5负载方案F5负载均衡在主数据中心及备数据中心各部署F5 LTM和智能DNS，通过F5智能DNS和 行内DNS的合理层次结构配置，从主数据中心和备数据中心两个入口进入的访问请求，分 发至对应的IaaS云平台，到达主数据中心和备数据中心云平台中部署应用服务端进行处 理。F5负载对内使用SNAT

25、Pool方式，根据应用在各数据中心不同区域的IP地址段，在F5中 设置对应的静态路由。通过容器平台发布的应用，在支持双活部署的情况下，在主数据中心和备数据中心同时发 布，应用在不同的数据中心中加入不同的Virtual Server，前面通过DNS域名提供访问， 以双活方式对外提供服务。对于服务发布在Kubernetes集群中的应用，通过F5 CC控制Kubernetes集群中的Pod 自动向对应的Partition中注册node信息，并自动创建Pools，同时使用iRules控制入口流量向对应的Partition中Pool。垣用翦阿2.3.2正常网络访问双活部署应用流量访问：互联网进入的访问流

26、量，进入行内DMZ及防火墙等网络后，从主数据中心入口进入的流量 进入由DNS处理后主数据中心的云互联/外联网络F5负载，根据应用部署架构进入相应的 Web服务器，再进入内网的应用服务；从备数据中心入口进入的流量由DNS处理后进入 备数据中心的灾备云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器， 再进入灾备内网的应用服务。内网进入的访问流量，由DNS处理后，内网主数据中心的访问流量进入主数据中心的内网 F5负载，根据应用部署架构进入相应的Web服务器和应用服务器；内网备数据中心进入 的访问流量进入备数据中心的灾备内网F5负载，根据应用部署架构进入相应的Web服务 器和应用服务器

27、。单体应用流量访问：从互联网进入的访问流量，进入行内DMZ和防火墙等网络后，经过DNS处理进入主数据 中心云互联/外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的 应用服务。内网进入的访问流量，由DNS处理后，进入主数据中心内网F5负载，根据应用部署架构 进入相应的Web服务器，再进入应用服务。2.3.3灾备网络切换双活部署应用流量访问：互联网进入的访问流量，在主数据中心整体故障后，流量进入行内DMZ及防火墙等网络 后，无论从主数据中心或者备数据中心进入的流量由DNS处理后进入备数据中心的云互联 /外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的应用

28、服务。内网进入的访问流量，由DNS处理后，仅备数据中心内网可进行灾备内网的应用的访问， 访问流量进入备数据中心的灾备内网F5负载，根据应用部署架构进入相应的Web服务器 和应用服务器。单体应用流量访问：互联网进入的访问流量，在主数据中心整体故障后，流量进入行内DMZ及防火墙等网络 后，无论从主数据中心或者备数据中心进入的流量由DNS处理后进入备数据中心的云互联 /外联网络F5负载，根据应用部署架构进入相应的Web服务器，再进入内网的应用服务。内网进入的访问流量，由DNS处理后，仅备数据中心内网可进行灾备内网的应用的访问， 访问流量进入备数据中心的灾备内网F5负载，根据应用部署架构进入相应的We

29、b服务器 和应用服务器。4,环境规划规划建设开发测试环境容器平台与生产环境容器平台，开发测试环境作为应用上线前，进行 功能测试、性能测试和预生产发布测试的应用持续集成与持续部署环境，生产环境容器平台 主要通过经开发测试环境验证后可发布的容器镜像进行应用发布，部署的K8S集群由容器 Portal统一做资源管理，并创建租户，配置配额供用户使用。用户登陆Portal后，基于不同的用户角色对平台的操作范围进行控制，当前平台支持平台 管理、租户管理、租户用户等多级管理。平台对不同的角色有默认的操作范围设置，同时也 支持对各角色的操作范围进行自定义设置。五、实施经验及效果1,实施经验总结1）建议采取从外围

30、系统开始逐步迁移的实施路线；2）建议考虑将渠道类系统、客户营销系统和经营管理等辅助性系统尝试使用相关行业云服 务；非金融辅助性业务系统安全等级较低，系统问题不会导致巨大的业务风险；提升系统管理的灵活性，降低运营成本，也大幅提升了相关的用户体验。2、实施效果通过本次容器云平台建设，规范应用上云标准及上云流程，统一应用全生命周期管理，提供 容器应用持续集成和部署管理；通过代码和应用包完成一键发布、变更；生产环境中，完成 应用的多中心部署和F5负载均衡自动注册，通过应用包或者镜像进行发布；实现应用在开 发、测试、仿真和生产区的多环境持续交付。通过有效整合开发测试环境的计算资源、网络资源、存储资源等各

31、类软硬件资源，不仅能满 足开发测试环境中各类资源和服务的统一管理，更能够满足业务交付灵活化、资源调整智能 化、环境运维自动化、环境管理精细化等需求，并能够实现企业级统一化、标准化、可视化 和流程化的管控机制。1）应用上云：将传统应用向容器平台进行迁移，支撑银行互联网应用快速开发测试上线， 支撑创新业务发展，加速数字化转型。如，某业务平台每日平均会有30W+交易量，峰值会 有100W交易量。通过把业务抽象为微服务，规划服务群组，对原系统进行解耦重构，按 照分布式微服务的架构，构建于私有金融云平台之上。通过容器化多活部署上线，已超过 1000多家企业客户迁移到平台中，后续还将陆续迁移。2）应用弹性

32、赋能：通过容器云平台建设，提供基于K8S的分布式应用基础设施，让容器化 应用实现在线快速扩缩容。3）资源统一管理：开发测试环境硬件资源（计算资源、存储资源、网络资源）的统一纳 管、软件资源（操作系统、中间件、数据库等）的自动化安装以及应用服务的自动化部署， 有效降低了开发测试环境管理的难度。4）基础设施云化：解决基础资源交付的问题，包括虚拟化的计算、存储、网络，底层硬件 资源对接。实现提升资源利用率、降低计算设备成本，提高管理效率，降低运维工作的人力 成本。5）多集群管理+应用维度的租户管理，实现敏捷开发测试；多集群管理+环境维度的租户 管理，实现稳定生产管理。6）系统使用效果：在开发测试环境

33、中：容器云平台支撑数十个应用测试业务，CICD构建次数达到 2000多次，在开发容器集群、测试容器集群和仿真容器集群运行近200个容器。在生产环境中：容器云平台支撑业务中台业务多活部署上线，20多个组件容器化生产上线，运行近70个容器。3、建议实施落地原则1）需求驱动紧密结合业务场景；有明确场景需求的情况下，优先考虑进行与此相关的基础架构落地实施；对于那些目前还未明确业务场景需求的情况，根据系统优化和改造需求，进行安排；业务应用和系统建设暂无明确需求的情况，暂缓进行架构落地。2）现状考量充分考虑现实难点；在结合明确业务需求的情况下，要从执行难度、实施成本、实施风险和影响范围等多 个方面充分考虑

34、现实情况，根据难易情况拟定架构执行的优先顺序和执行内容。3）循序渐进先易后难、先新后旧、先小后大；根据现实情况拟定优先级，循序渐进；基础架构的建设是一个过程，不是一个结果，需要不断根据业务应用的需要进行迭代 式的开发和建设。六、未来规划和建议我行的整体金融云平台建设方案是基于我行的现状情况定制的解决方案，整体包括IaaS和 PaaS两部分，其中容器云平台为本次主要的实践分享，属于IaaS平台建设的一部分，IaaS 平台建设包括基础设施云平台、容器云平台、统一云管理平台、DevOpS、云安全和云灾 备。整体金融云平台纳入的除了容器云，还有PaaS层组件、微服务、DevOps等新技术。综合 这些，

35、同时本着自主可控的原则，逐步建设一个从IaaS到PaaS的私有云框架，分阶段逐 步推进实现业务上云，在不远的未来建成一个完整的金融云平台。但基于各金融机构各自状况不同，建议通常的建设规划路线如下：1、IaaS云平台建设： 一期：完成基础的openstack云平台建设；二期：根据应用需求进行集群扩容，完成适合的业务上云。 一期：基于IaaS搭建容器管理平台，在生产环境完成一个互联网金融应用上云试点；二期：多个应用改造迁移，推进新建应用以微服务开发；三期：生产环境与测试环境网络打通，全部互联网应用改造上云，推行Devops开发 流程。 一期：搭建以资源自服务、虚拟机纳管为主的云管理平台;二期：增强纳管能力，包括物理机、小机、数据库等。