Menu Close

关于私有云云管理平台建设的思考

本文作者:

黄成、李华、高强、丁旦 / 上交所技术有限责任公司

徐桂林/杭州飞致云信息科技有限公司

编者注:

本文刊登在《交易技术前沿》杂志2019年第一期(总第34期)

摘要:云管理平台作为基础设施云化建设中的一个组件,主要承担了基础设施资源管理和维护的功能,是推进基础设施建设标准化、自服务化的重要平台。本文主要叙述了上交所在云管理平台建设过程中遇到的一些问题,并对这些问题产生的根源以及在项目中上交所采用的方案进行了总结。本文通过对整个项目建设的过程和问题进行回溯和总结,也希望能对云管理平台的建设有比较好的借鉴意义。

一、 前言

云计算是分布式计算、并行计算、效用计算、网络存储、虚拟化、负载均衡、热备份冗余等传统计算机和网络技术发展融合的产物。云计算通过将分散的计算、存储、网络等资源进行有效的整合,给业务提供便捷、高效、弹性的资源供给,是全行业IT基础设施发展的新趋势。

2015年起,国务院、工信部相继出台了《关于积极推进“互联网+”行动的指导意见》、《云计算发展三年行动计划(2017-2019)》等文,明确指出“互联网+”普惠金融是推进方向,支持银行,证券,保险稳妥实施系统架构转型,鼓励金融机构利用云服务平台开展金融业务,要求落实推动新技术应用,促进金融创新发展,稳步推进系统架构和云计算技术应用研究。

二、 遇到的挑战

随着上交所整体基础设施规模的增加,业务支持复杂度的不断提升,传统基础设施平台在支撑所内业务发展方面越来越具有挑战。这些挑战具体表现为如下两个方面:

  • 资源缺乏有效管理

从所内整体资源角度来看,近些年分散在不同数据中心的基础设施规模在不断扩大,整体基础设施资源的管理和运行监控越发困难,没有有效的平台和工具能实现多地、多类型基础设施的统一管理;从成本控制角度来看,无论基础平台建设还是应用系统建设,仍旧处于烟囱式建设阶段,基础设施资源无法进行有效的共享,缺乏统一的资源管理和调度,导致建设成本增加。

  • 资源无法敏捷供给

所内业务研发团队在快速扩张,项目的自研能力在持续提升,这要求基础设施团队在响应业务团队基础设施资源需求上具备更好的敏捷性。在传统运维模式下,基础设施资源的规划、管理和交付规范都依赖于人工操作,未能将企业数据中心内规划设计、部署交付和运营运维三个阶段形成很好的互动,并实现自动化。由于标准化、自动化的缺失,在响应业务部门对基础设施资源的需求时,交付效率和质量都面临较大挑战。

基于行业政策的推动以及内部强有力的科技变革诉求,所内基础设施管理需要尽快向标准化、自动化和自助化转型,将基础设施的支撑工具能力转换成基础设施服务能力向业务部门输出。与此同时基础设施管理团队则从管理者变成平台服务能力的提供方和运营方,云管理平台也成为企业基础设施从监、管、控向云服务中心转型的重要平台。

三、云管平台体系结构

基于全行业云管平台的建设思路,结合上交所实际情况,上交所云管理平台需要能够重点解决所内分散基础设施资源的统一管理,集中运营,交付标准化、自动化和自助化。因此,整个云管理平台做了如图3.1的架构设计。

图3.1 上交所云管理平台整体架构

如图3.1整体架构所示,云管理平台的建设包括如下几个方面:

  • 云管理平台基础模块:该模块主要承担和底层基础设施对接,并提供平台层面的用户租户体系以及工作流程;

  • 计算存储资源规划管理模块:该模块的主要管理对象是逻辑资源池。云管理平台管理员可以按其资源池逻辑规划将下层的物理资源池划分为不同的逻辑资源池(可以按地理位置、性能、应用等划分);

  • 网络规划管理模块:该模块主要IP地址资源的管理以及与基础网络的对接,并提供应用与IP的映射关系,方便资源服务管理模块能够按相应规则进行云主机的自动IP分配;

  • 资源交付管理模块:基于对于基础设施资源计算、存储以及网络的规划管理,按用户的应用类型提供资源的自动化交付;

  • 应用模板管理模块:提供对于具体业务应用的架构模块定义和管理,从而提供用户快速交付整个应用需要的基础设施资源;

  • 平台服务运营管理模块:提供对于整个平台上的资产情况,订单情况,用户资源使用率的持续跟踪和运营,并按可配置的规则提出优化建议,产生相关报表;

  • 资源及应用服务门户:结合资源交付及应用模板的能力和基础平台提供的用户租户体系,实现向最终业务用户提供自助服务目录和标准化资源申请流程的能力;

  • 云管理平台门户:整个平台的统一门户界面,提供系统管理员、部门管理员和普通业务用户的登陆、操作和查看的Web页面。

上交所云管理平台的框架采用分层结构,涉及到从后端资源对接一直到前端自助操作全链路。在这个链路中的核心在于整个基础设施资源层的规划、管理及应用维度的资源交付,接下来,本文将重点分析这部分中的几个关键问题以及在所内云管平台建设中的相应实践。

四、关键问题分析及实践

4.1 资源池管理与使用

资源池的管理与使用是云管理平台中最为核心的功能之一。尽管数据中心的资源池一般理解为计算资源池、网络资源池和存储资源池三部分,但大部分时候计算和存储资源池一般结合在一起讨论、规划和使用。而网络管理模块则更为独立,并经常由独立的团队进行规划和管理。本小节,则重要讨论计算存储资源池。

从企业IT基础设施资源配置的角度来看,整个计算存储资源池会按用途、等级或者地理位置进行划分,形成统一的资源池规划。当业务用户需要申请资源的时候,资源池管理人员可以按照业务需要提出资源需求以及资源池规划设计,选择在合适的资源池上创建资源并交付给业务用户。当我们认真思考整个计算资源的规划设计、资源发放的过程,并希望在云管理平台实现自动化时,有几个场景的问题和挑战就会浮现出来:

  • 为便于计算资源的管理和分配,目前所内多数计算资源池采用单一的规划和分配方案,无法提供云化环境下,不同用户对不同等级资源的诉求;

  • 所内的资源池规划及实施缺乏电子化手段,且没有形成一个可以被系统接受并作为资源自动化分配的方案,这导致资源交付的自动化难以实现,且人为参与资源交付的过程效率较低,比较容易出错;

  • 资源池建设方对于资源池的理解与资源池使用方(业务用户)对于资源池的理解容易产生分歧。建设方更多的是从资源池物理形态和建设规划上理解资源池,而资源池使用方则更多关注对于资源池的业务需求(地理位置、级别以及是否高可用等等);

  • 资源交付过程中常见的放置策略无法形成自动化和标准化,尤其是在交付较为复杂的应用资源时候,会面对如主-备,高可用,自动均衡等要求时候,整个实施的过程非常繁琐和冗长。

资源的标准化、自动化、甚至是自服务是基础设施云化的基本能力和核心诉求,这就要求云管理平台能够解决以上的相关问题。所以,上交所云管理平台引入了逻辑资源池的概念,并将其与物理资源池建立映射关系。而逻辑资源池上添加自定义的具有业务属性的标签,用户进行资源申请时候,根据自己的业务需求,以直观的逻辑资源池标签表达自己的资源需求。而云管平台则根据用户的业务需求找到合适的逻辑资源池,然后根据逻辑资源池映射到真实的物理资源池上创建资源并交付给最终用户。通过以上过程,我们做了如下改进:

1、 将资源池的建设规划等相关信息通过云管理平台落实到系统里面,并可以支持资源的日常交付;

2、 实现逻辑资源池和物理资源池的分离。建设方以满足逻辑资源池规划为目标来建设物理资源池,而资源使用方则进关注整个逻辑资源池的规划,按逻辑资源池的规划去申请资源、部署业务即可;两者相关解耦,独立运营和演进;

3、 基于逻辑资源池的资源放置策略实现。由于引入了逻辑资源池,用户可以将自身的业务放置需求表达为逻辑资源池上的放置策略,并交由云管实现到最终的物理资源池上;

4、 提供基于逻辑资源池的运营能力。运营管理计算存储资源池(如容量管理、成本管理等)是比较棘手的事情。逻辑资源池概念的出现让这个问题划分成为两个层面的问题:一个层面就是针对物理资源池的运营管理,主要提供对于资源池建设方有意义的运营指标(如建设容量使用情况),另外一个层面就是针对逻辑资源池的运营管理,主要提供业务相关的资源使用情况统计及成本分析,提供给业务人员进行参考和决策。

由上分析可以看出,作为基础设施的运营、交付和管理平台,逻辑资源池概念的引入成为云管理平台里面的核心要素和能力。平台应该能够提供适应企业数据中心规划和交付部署实际场景的逻辑资源池配置、管理和使用能力。通常来讲,企业的逻辑资源池设计是最有能力很好反映计算存储资源池的规划。而这个反映过程的好坏直接会影响整个云管理平台的管理复杂度和用户体验,在这个过程中需要特别注意以下几点:

● 灵活性:资源池规划粒度会随着规模的扩展而不断细化,对于存量资源池的定位也时常会有挑战。这就要求云管理平台对于资源池的定义和实现能够足够灵活,能够覆盖基础设施层中对于资源组织,划分的各个层面,从而能够随着用户基础设施规模的变化以及规划的调整进行调整;

● 简单性:对于资源池的管理存在两个视角,一个是管理员端对于资源池规划的的落实和映射,另外一个视角就是如何将资源池展现给最终用户。由于要给最终用户进行选择,就必须让资源池的展现和选择变得简单直接。为达到这一点,灵活定义的资源池标签模式是一种常见的实现模式。

● 扩展性:对于资源池扩展性的要求主要体现在对于多种基础设施的支持上。逻辑资源池的一个重要目标是要实现异构基础设施的抽象和隔离。不管物理基础设施的类型如何变化,逻辑资源池都应该能够进行适配,并保证对云管端其他业务的无感知。

资源池的管理和使用是云管理平台最为核心的能力之一,而逻辑资源池则是这个核心能力的载体。云管平台建设中一定要注重这个载体的设计,保证能提供一个配置简单、使用灵活、易于扩展的逻辑资源池设计。

4.2 网络管理与使用

在解决完计算、存储资源池的管理和使用的问题后,另外一个重要的主题就是网络管理。这点是全行业云管理平台建设中普遍需要考虑的一点,甚至这一点很有可能成为云管平台建设以及基础设施云化的瓶颈。总结来说,上交所云管平台对于网络的管理能力的诉求包括以下几个方面:

● 网络规划的支持能力

和计算存储资源池类似,企业都有对整个的网络进行规划,这里的规划包括网络平面的规划,以及具体网络地址段的规划设计。尤其在生产业务上,会根据业务类型、业务系统以及机器角色进行更加详细的网段划分,并最终将这些网段划分落实到IP地址管理上。并且,在云管理平台为基础设施云化的统一入口时,往往还需要考虑对管理地址段的分配和维护。所以,云管平台一定要考虑如何实现对于内部的网络规划、落地的工作。在上交所的业务场景下,管理网络的地址由系统网络管理员统一规划、配置,而生产业务地址则需要由云管理平台统一发放和维护。

● 网络基础设施的整合能力

上交所目前网络基础设施大体可以分为传统网络和软件定义网络两大类。随着云平台在企业内部的逐步落地,包括软件定义网络在内的软件定义基础设施成为主流趋势。对于传统网络设备,因为普遍缺失编程接口、开放接口可变成能力有限等问题,一般不是云管理平台重点纳管整合的对象,仍然使用传统的方式进行管理配置,云管理平台主要是将这些网络设备最终配置规划的结果录入云管理平台,配合最终资源自助交付使用即可。

云管理平台对于网络基础设施的整合重点应该在软件定义网络,或者集成OpenStack平台,实现对软件定义网络资源的管理。这些管理主要包括将所内网络规划通过软件定义网络的编程接口下发到相应的设备上,并在需要网络相关配置信息时候能够通过编程接口动态取得相关信息(而不是像传统网络设备那样依赖静态配置)。

通常比较典型的场景是在计算资源交付时,需要底层网络资源(例如最基本的互联互通、组策略等)的同步交付,从而实现计算资源的即时交付。

● 资源交付过程中的集成能力

这一点与第二点有一定的关系,整合能力着重需要云管理平台能够有南向对接基础设施的能力,能够提供丰富的网络功能,而交付过程中的集成能力则着重在资源交付过程中云管理平台能提供的能力。我们做网络管理模块的最终目标是,希望能够将基础设施抽象出来的网络服务集成到用户资源的交付上去,让业务用户能够享受到完整的基础设施云服务。这点从主流公有云厂商提供的服务上可以看得非常明显,无论云主机、数据库、大数据平台,甚至相关PaaS服务的申请和交付都依赖网络管理能力,并提供给用户选择网络配置的选项,提供一站式的资源交付。

云管理平台在资源交付过程中的集成能力非常重要。例如,在最典型的是虚拟机交付过程中,平台需要根据用户的需求,提供基础网络、防火墙、安全组、QoS、负载均衡等的网络功能,在虚拟主机或者应用弹性伸缩的时候,能够提供自动增减网络配置的功能。当然,这种网络资源和计算资源在交付过程的整合需要重度依赖对于的云管理平台服务自身和所内基础网络的整合能力,更需要云服务建设团队和网络建设团队共同努力达成。

由以上几点可以看出,云管平台对于网络管理的工作内容和能力要求还是十分丰富的,为此,我们在云管建设中投入了较多的的精力在这一个方面。总结来说,我们的实践经验主要体现在以下两个方面:

1. 引入独立的网络管理模块

在梳理云管理平台需要包括的网络功能点后,结合对于主流公有云产品形态的调研,上交所云管理平台单独开发了网络管理模块,该模块的功能范畴定义为以下几点:

● 该模块在管理端需要提供网络规划的配置和录入能力(主要是业务网层面)。通过这个管理端,我们可以将交易所内的业务类型,业务系统,功能域等信息录入,并将它们和最终的网段规划映射上。

● 该模块需要能够直接对接软件定义网络设备,可以通过SDN设备的编程接口形成交互。这样在需要在云管层面操作软件定义网络时候可以直接进行。

● 该模块需要提供相应的接口对外提供服务,外部的资源交付流程可以通过调用该接口来整合网络服务能力到资源交付的整个流程中。

2. 网络管理模块以IP池管理为核心载体进行设计

尽管网络管理的内容包括的方面很多,如IP地址段管理、端口管理、网络策略管理等。考虑云管平台的定位以及实际实现的难度,我们决定以IP地址池(及IP网段)管理为核心来设计云管平台上网络管理模块。之所以这么做的主要原因在于:

● IP网段管理是企业内业务网管理的基础和核心,把网段管理好并以此为基础进行资源自助交付。这样就为接下来的网络策略管理、端口管理打好基础了。

● IP网段管理是网络全生命周期管理(规划-Day0,部署-Day1和运维-Day2)的连接器,是云管平台做网络管理最好的抓手。

● IP地址是业务团队比较容易理解和操作的概念,也是业务团队进行业务操作的基本要素。

从整体云管理平台网络管理模块的建设和落地来看,云管理平台中网络管理和使用主要建设思路就是以IP池管理为核心来建设独立的网络管理模块。通过对IP地址管理的建设,对下联动网络基础设施(SDN网络),形成网络资源的自动发放,对上结合业务系统,形成IP资源和业务属性的有效关联。让网络管理员、业务人员都可以在云管平台完成自己操作,并最终支持整个资源的自助、自动化交付和变更。

4.3 应用模板与应用编排

应用模板和应用编排(应用蓝图)是所有云管理平台建设需求讨论中的热点。讨论的主要原因在于,一方面因为它描述一个“用户可以自定义应用模板,一键式生成应用所需资源”的场景,非常吸引业务用户以及资源管理者;另外一方面,在可编程的云化基础设施逐步推进的当下,应用蓝图实现的可能性增大。

根据对行业内的调研,上交所云管平台建设过程中,应用模板和应用编排的落地其实有着很大的挑战,这种挑战包括以下几个方面:

● 所内基础设施现状有别于公有云企业

一是企业内部的基础设施有非常多的历史遗留设备,而不像公有云基础设施基本都是全新建设的软件定义基础设施为主;

二是公有云基础设施高度标准化,不存在企业内部常见的基础设施多样化的问题。

以上两个问题让应用编排在企业内部的落地技术难度大很多,经常会出现编排不稳定、失败率高的问题。一旦失败率超过业务用户容忍的限度,业务用户基本就会放弃应用编排,回到传统模式。

● 所内基础设施的管理模式

在过去多年的ITSM模式运营下来,形成了较为细致的管理分工(专人专岗,合规审计)。当需要对全栈自动化编排模板的日常管理,需要协调的岗位和人员非常多,而模板日常管理的技能要求也非常全面。从某种意义上说,应用模板和应用编排需要企业内部形成以复合岗为主要形式的全新基础设施管理模式。

● 应用模板的维护和管理

在应用模板和应用建设过程中,一直在思考应用模板到底由谁来定义和维护的问题。从对应用架构的理解上,业务部门是最熟悉的,业务模板应该由业务部门定义,但是所内业务部门一般对基础设施的理解有限。而从对基础设施的理解上,基础设施管理部门似乎是这些应用模板的定义和管理者。但基础设施部门定义出来的业务架构大概率不能适配企业业务的真实需求,于是就会出现不断增加、修改应用模板的事情,最终一定会出现应用模板数量爆炸并无法管理的局面。

从上交所内部业务来看,应用模板和应用编排的需求往往来自经常需要申请、变更资源的敏态业务,这使得真正意义上的应用模板和应用编排比较难落地。

在考虑以上应用模板和应用编排落地的问题后,我们认为“应用编排和应用模板”在上交所当前情况下,具体的落地应该要优先实现各个业务场景的自动化,再逐步推进,要让云管理平台上的应用模板和应用编排随着所内基础设施形态、企业基础设施管理模式、运维管理人员技能水平以及行业监管保持同步节奏向前推动。为此,我们在云管平台中通过以下三个步骤实现了初步的应用模板和应用编排能力:

● 单应用节点交付

通过资源池管理和网络管理能力实现了单台云主机的自动化交付,再结合云主机上常见中间件的自动化部署和配置,从而实现单台机器上上的业务运行环境自动化交付。

● 批量同类应用节点交付

通过批量交付功能实现对于一个应用中同一角色内云主机的批量自动化交付。

● 单应用不同类型应用节点批量交付

通过定义一个应用内不同角色云主机的需求,形成一个简单的应用模板,并提供基于应用模板的一键交付整个应用的所有角色云主机,从而为应用集群的形成提供基础设施环境。

上交所云管理平台在整个应用模板的实现中具有以下两个方面的特点:

● 有用处:这个应用模板实现确实能够解决日常新业务上线或者业务变更中的批量资源交付效率,让日常重复的操作交给系统自动化完成。

● 能落地:这个应用模板的落地基本上不会影响现有企业内的传统ITSM业务变更流程,是一个落地门槛较低的方案。

当然,以上应用模板的方案离真正的应用编排仍然有较大距离,我们也会在上面方面逐步演化出完整的应用编排引擎,乃至更加强大的应用编排模板。但我们一直会秉承能落地,有用处的思路一步步前进,尤其是要考虑上交所内部的实际场景和流程。

五、回顾及总结

回顾上交所云管理平台项目的调研、选型以及最终实施的全过程可以总结出以下几个要点供参考:

1) 对于内部当前实际情况的调研是保障项目成功的关键

云管理平台是定位在企业IT基础设施之上的管理平台,它和IT基础设施软硬件边界清晰,技术路线清晰,相比较有明细的个性化特征。这其实要求项目建设方在开始云管理平台建设需要特别关注实际情况的调研。整个调研一般可以包括当前基础设施使用情况及未来规划、当前资源交付、管理、变更的具体流程和利益相关方、业务方和基础设施资源管理方当前最迫切痛点及期望等。

2) 明确目标,分步建设,重视基础

因云管理平台的边界问题,经常会出现的误区就是“舍本逐末”,容易忽略基础部分的建设而追求过多“高级功能”。按照上交所的需求来看,急切需要通过云管理平台实现对基础设施资源的统一管理和分配。当前大部分企业,包括采用OpenStack构建了基础设施管理平台的企业而言,对云管理平台的核心诉求,仍旧是IaaS层的统一管理、自助交付,在基础设施资源管理、集成能力达到一定水平的情况下,可以考虑“高级功能”的建设。所以对于资源池的管理、网络的管理应该成为大部分云管理平台项目第一期建设的核心。

3) 重视云管理平台自身的演化能力

如上所述,云管平台建设仍需逐步完善。这就对云管理平台自身的演化能力提供了极大的挑战。例如,模块化架构、容器化部署、全API开放这些特征是云管项目演化能力的重要保障。

从以上几点可以看出,云管平台项目建设有其独特性。在项目边界尚未清晰的情况下,应关注基础,关注核心痛点,稳扎稳打是一个较为现实的策略。项目团队也需要在这个过程中不断提升自己对于云管的认知,将对于云管的期待转化成一个个可实际落地的目标,从而在持续演化过程中最终打造出一个多方都认可的云管理平台。

六、未来规划

如前所述,云管平台需要逐步演化,不断迭代。结合当前云管平台建设情况、云平台建设规划以及云管用户的反馈,我们接下来计划重点关注以下几个方面的能力建设:

1) 应用拓扑可视化

如前所述,我们已经初步建设了应用模板定义以及应用基础设施资源一键交付能力。同时通过网络管理模块的建设,已经初步具有了应用和基础设施的基本映射关系。后续云管理平台会结合更多监控指标,争取提供应用实际部署的拓扑结构,希望能在业务故障定位上提供一个较为完整的逻辑视图。

2) 多服务类型集成

除了对于云主机全生命周期管理,云管平台还承担了金融云私有云的门户以及PaaS、SaaS服务提供的功能,因此,希望后续能够让云管平台逐步接入更多类型的服务。在多服务类型扩展中,初步以模块化扩展为主要模式。

Posted in 多云管理, 观点