以应用为中心的企业混合云管理

徐桂林 2015-12-16 10:16:11

12月14日，FIT2CLOUD总监徐桂林老师，在【DBA+社群】中间件用户组进行了一次主题为“以应用为中心的企业级混合云管理”的线上分享。小编特别整理出其中精华内容，供大家学习交流。同时，也非常感谢徐桂林老师对DBA+社群给予的大力支持。

嘉宾简介

徐桂林

FIT2CLOUD 总监，负责公司的技术布道和生态合作。
在此之前先后供职于意法半导体、Autodesk和阿里云。
热衷于云计算（尤其是公有云IaaS平台），有过多年AWS的生产环境工作经历，是较早在国内分享AWS上实践经验的作者之一。

演讲实录

随着互联网和移动互联网的深入普及，传统商业运行模式正在被深刻影响甚至变革。现在，越来越多的互联网企业利用其强大的IT服务能力快速切入传统商业的方方面面，影响着人们的各种日常决策。而传统企业也在不断加强其IT服务能力，并寄于此来完成组织的转型和升级。所以，企业IT服务能力已经成为当代企业的核心竞争力之一。如果重新审视现如今的企业IT，会发现支撑企业IT服务能力的基础设施正在发生一个巨大变化，即企业IT基础设施已经进入一个全新的专业云时代。具体来说：

IaaS已经成为新常态，企业的IT基础设施形态已经从传统的物理机和虚拟化环境转向IaaS平台。

混合云成为专业云时代的主流。企业级云基础设施普遍选择混合云形态（公有云与私有云的混合），以满足企业数据安全、业务合规以及成本考量等多方面的要求。

类似于在传统IT时代企业需要IT管理平台（以ITIL为代表）一样，专业云时代的IT管理需要全新的云管理平台（Cloud Management Platform），来适应IT基础设施全面云化的需求。

在过去十年里，云计算从一个概念迅速发展成为一个大家普遍接受、并广泛应用于实际生产中的新型IT基础设施。尤其是在公有云IaaS领域，以AWS、阿里云为代表的厂商都取得了令人瞩目的成就。随着越来越多传统企业接受云计算并开始实施企业云战略，专业云时代也已经到来。根据RightScale的最新报告（如下图），目前1000人以上的大企业基本都已经有了明确的企业云战略，而这其中有超过八成会选择多云平台方案（其中混合云占比超过半数）。

如上图所示，企业多云和混合云策略成为主流选择，而这些企业自然会有云管理（尤其是混合云管理）的迫切需求。对于这些企业CIO或者IT经理来说，新型云管理平台一定要能够支撑企业采纳云的初心，即促进业务创新，而不是使用传统的IT方式把云平台做为一个新的资源池简单管理起来。所以，企业需要一个全新的视角来拥抱云管理平台，即围绕业务团队（DevOps团队）构建混合云管理方案，也就是以应用为中心的混合云管理平台。

一个以应用为中心的企业级混合云管理平台主要解决的问题是如何让业务团队（即DevOps团队）更高效地使用好混合云基础设施，并以此促进业务发展和创新。为此，其需要解决以下几个主要问题。

问题一：如何统一管理不同来源的IT资源

如前所述，混合云已经成为企业云战略的首选，这意味这企业云资源的来源会多样化（如下图）。除此之外，企业还有大量的历史遗留基础设施（包括物理机器以及虚拟化环境等），这会使得企业IT资源的来源更加碎片化。

所以，如何统一管理不同来源IT资源并集中交付给业务DevOps团队使用就会成为一个新的挑战。具体来说，企业需要解决如下几个问题：

如何统一管理公有云主机、私有云主机和物理机？
如何以应用视角管理基础设施？
如何集成云API，实现自动伸缩？

企业级混合云管理平台只有解决了以上几个基本问题才能实现对于不同来源基础设施进行标准化无差别管理，同时还能够充分发挥云平台带来的弹性资源交付优势。

问题二：如何为业务团队提供自助式IT

自助式IT是一个传统IT环境下就存在的概念。但是传统自助式IT基本都是通过工单方式提供服务，并不能够做到实时全自动化交付资源给业务团队。由于云平台资源的可编程化，云上自助式IT已经真正可做到实时全自动化的交付资源。进入专业云时代，通过混合云管理平台提供真正意义上的自助式IT成为充分释放云生产力，支持业务团队更好进行业务创新的关键所在。具体来说，企业云管理平台需要解决以下几个问题：

如何实现十五分钟内交付虚机、一个小时内交付完整业务集群？
如何支持虚机及集群的全自动初始化？
如何提供丰富的自定义虚机及集群模板？

现在，主流公有云供应商基本都在产品级别解决了上面这些问题。所以，企业级混合云管理平台必须能够在企业内部完整解决这些挑战，才能在不影响业务DevOps团队日常开发效率的前提下过渡到企业的混合云解决方案中。

问题三：如何高效运维越来越多的虚机

随着互联网+浪潮的逐步深入推进，企业IT系统承载的业务会越来越多，也越来越重要。这也意味着需要更高效的运维方式管理越来越多的IT基础设施，尤其是需要管理日益增多的虚机。同样来自于RightScale 2015年的报告，大部分企业的虚机数量已经超过50台（如下图）

一般来说，超过50台虚机的规模意味着传统手工运维管理已经很难保证效率和质量。这时候企业日常运维管理就会经常遇到如下这些常见的问题：

如何同时给1000台虚机打补丁？
如何实现端到端的监控？
如何实现故障自动修复？

要解决企业IT基础设施规模增加带来的运维挑战，自动化成为现代运维管理系统普遍的选择。这就要求企业级混合云管理平台能够帮助企业落实自动化运维的一系列最佳实践。

问题四：如何支撑DevOps团队实现持续交付

现如今IT系统的交付周期越来越短，而且还需要在持续交付的过程中保证服务的高可用和性能的高稳定。但是，整个IT系统的持续部署和交付流程需要一个较长的流程。例如，下图就是一个典型的从代码到最终服务的流程。

在这过程中，企业会遇到以下阻碍整个持续交付流程顺利进行下去的常见问题：

如何建立统一的Artifact仓库?
如何保证测试环境和生产环境的一致性？
如何实现部署后快速反馈？

企业在实施IT系统持续交付过程中经常会因为未解决以上常见问题而导致最终的持续交付流程流于形式，未能达到支持业务创新的目标。企业级混合云管理平台需要能够为此提供足够好的支撑工具，帮助团队解决以上常见问题并能融入的日常云管理中。

针对如上几个问题， FIT2CLOUD提供了以应用为中心的混合云管理及DevOps协作平台（结构图如下），希望寄与此帮助企业更好地管理好混合云并充分释放云的能力，达到促进业务创新的目标。

如果从技术架构角度看，整个产品的架构图如下：

如上图所示，FIT2CLOUD是典型的传统的C/S架构。在服务端，整个系统包括消息引擎、管理控制台和REST API组成。客户端则有一个非常轻量级的客户端Agent（基于Python开发）。客户端和服务端直接通过Message Queue保持通信。具体功能如下：

- 服务端：提供界面（Web或者API）供用户管理使用，对接不同云平台申请、释放和查询云资源，向客户端发送消息命令，接受客户端上报数据（监控数据，命令执行结果等），处理并存储所有需要长期保存的数据（包括监控数据、操作日志、用户配置数据等）

- 客户端：主要负责接受服务端命令并执行操作、按要求向服务端汇报数据。

对照前面提到的几个基本问题，我们希望能在我们的平台中逐一解决。首先，针对企业IT基础设施碎片化的问题，我们希望通过一个大管理平台加不同插件的方式解决这个问题。换句话说，我们平台定义一套插件接口框架，然后针对不同的云平台按照这个接口框架封装其API。这样，管理平台和不同云平台就能够解耦，让插件来适配不同云平台的差异性。从用户的角度看，你需要对接哪个云平台，指需要安装、配置一下这个云平台的插件就可以了，如下图：

我们这个插件框架做得还不错，如果你有新的云平台对接，只需要按标准开发一个插件，然后安装到系统内就能管理该云平台上的资源了。

具体来说，每个云平台插件内部主要包括下面几个方面的功能：

1）封装对于云平台提供的API和SDK，例如虚机生命周期的管理（创建、停止、启动、删除等操作），还有各种云资源的查询、更新及配置操作。

2）对云管理平台提供一致性的接口，屏蔽掉不同云平台API不一致的地方。

如果你对于我们的插件框架感兴趣的话，可以参考我们的在线文档（http://docs.fit2cloud.com/v1.1/plugin/architecture-overview.html），里面有现成的实例代码和接口说明。

在解决了云平台资源对接后，为了兼容历史遗留主机（以及已经存在的云上主机），系统还提供了“导入主机”的功能。这样就能够让已经存在的主机资源也得以加入到系统进行管理。

为了给业务团队提供足够方便的云上自服务能力，FIT2CLOUD系统提供了云平台的虚机创建模板功能（如下图），用户可以按照自己的需求把常见的虚机模板提前定义好，需要时候直接启动，甚至利用FIT2CLOUD平台提供的自动伸缩功能按需求自动启动或者释放。

但是，如前所述，一个简单的虚机创建模板是不足以满足用户自服务IT的要求。用户需要的是从资源申请，初始化、应用部署到上线服务的整个链条自动化。所以，FIT2CLOUD还可以在设置虚机创建模板的时候指定初始化操作、代码部署以及挂载负载均衡器等各种设置。例如，下图就说明当虚机启动后能够自动部署应用的指定版本。

接下来讲讲FIT2CLOUD如何看待业务运维管理这个事情。在云环境下，企业运维管理一个最大的变化在于企业基础运维（机器、网络及存储）已经被云供应商服务化并通过SLA来保证其服务的质量，企业运维的核心变成了应用运维。所以，FIT2CLOUD对于企业运维的观点就是一定以应用为重心来操作。这其中包括：

1）所有基础设施资源都以应用视角来组织管理和展示，通过“集群/虚机组/虚机”三层概念对应一个业务应用常见的“应用/层/实例”这个技术架构。

2）所有监控数据都以应用视角进行展示（如下图），用户可以在一个界面看到集群、虚机组和虚机的监控指标，并能够drop-in和drop-out。

3）运维人员的日常运维工作也以应用视角执行，方便运维人员按照应用来执行批量脚本等运维操作，并且结合告警集中提供“自动修复”功能。

4）自动伸缩是云上最为重要的运维管理工具，对应于传统运维中的“扩/缩容”操作。如果你的应用已经能够做到“状态无关”，那这个工具一定是你最好的帮手，可以大幅度降低日常运维的工作量，而且还能够保证运维的质量。FIT2CLOUD的自动伸缩优势在于基于自己的Agent上报的监控数据独立实现，不会被任何云平台提供的自动伸缩服务所绑定。现在，FIT2CLOUD提供两种模式的自动伸缩功能，定时伸缩和情景伸缩（如下图）：

总结来说，以应用视角为中心，结合各种自动化、批量工具来帮助用户提高运维效率。

最后，来说说如果提高团队的持续交付能力。首先，我把FIT2CLOUD推荐的持续交付架构图展示如下：

通过上面的图，让我们看看FIT2CLOUD如何解决前面提到的几个问题。

1）关于统一Artifact管理的问题，现在已经有很多非常好的开源或者商业软件，而且都和如Jenkins构建环境对接好了。保证每次构建出来的Artifact（制品）都能够准确无误的保持到制品库内部。同时，为了方便云上用户，FIT2CLOUD还支持使用阿里云OSS和AWS的S3作为制品库来存储制品。并且提供了Jenkins到OSS的插件（Jenkins到S3的插件已经有开源版本）。

2）为了保证不同环境上的部署流程自动化、标准化。FIT2CLOUD提供兼容AWS CodeDeploy标准的“代码部署”功能。用户只需要按照这个标准在构建时候打包组件，就可以利用FIT2CLOUD完成在不同环境里面的自动部署。AWS CodeDeploy标准就是亚马逊内部自己使用的代码部署标准，其所有服务都是基于此部署。在去年，亚马逊基于此标准完成了5000万次的部署。所以，这个标准无论是从灵活性，还是稳定性都是经过了考验的。

3）为了打通从构建到部署的流程，FIT2CLOUD提供了Jenkins For FIT2CLOUD插件。当jenkins构建完成一个版本后，会把相应的制品上传到制品库的同时把相关信息自动注册到FIT2CLOUD中，这样，FIT2CLOUD就可以在系统内部使用改版本进行部署。这样就彻底打通了从构建到部署的流程。

基于上面这些功能，FIT2CLOUD已经能够完成从代码check-in到部署服务整个链路，非常有益于业务团队提高部署效率，实现持续部署。

再次感谢 FIT2CLOUD 总监徐桂林老师，对DBA+社群活动给予的大力支持！

“DBA+社群”将陆续在各大城市群进行线上专题分享活动，以后每周一、周三晚上为【DBA+专业群】的固定时间，每周二、周四晚上为【DBA+各城市群】的固定时间，每周五晚上为【DAMS架构师精英群】的固定时间，欢迎大家积极加入我们。无论是内容还是形式，有好的建议我们都会积极采纳。

想入群的小伙伴们请关注DBA+社群微信公众号：dbaplus，回复“加群”即可。

小编精心为大家挑选了近日最受欢迎的几篇热文:

回复001，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；

回复002，看吕海波的《去不去O，谁说了算？》；

回复003，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；

回复004，看郭耀龙《假事务之名，深入研究UNDO与REDO》；

回复005，看杨志洪《【职场心路】一个老DBA的自白》；

回复006，看周俊《被埋没的SQL优化利器——Oracle SQL monitor》；

回复007，看袁伟翔《揭秘Oracle数据库truncate原理》；