标签：term oba 完全 kff ase sea ice 迁移 pat
4月23日天云软件技术开放日已圆满落幕，接下来几天将陆续放出沙龙期间技术大牛们的干货分享现场实录及相关文件，敬请关注。此文为第一篇，由天云软件产品总监马俊带来的IaaS专题：企业级云管理平台的架构实现与落地实践、趋势分析，以下为演讲实录。
马俊：我给大家介绍一下云管平台，OpenStack现在比较流行，企业级客户IT架构在OpenStack上会有一个云管的平台，整个业界对云系统建设也都是怎么认识的。
我们看其实最下面有一个虚拟化的层，这里面有Vsphere、KVM、XenServer，然后在上面技术架构层上发生了变化，最开始从Vcenter逐渐发展成OpenStack，我们发现需要个云管平台，这个平台把底下的不同技术架构进行统一管理，整个业界也都是按照这个层次来进行IT系统建设。现在OpenStack比较流行的，企业用户上了OpenStack以后，在CMP上的需求就出来了，单单通过OpenStack或者vCenter这样的技术架构是不能解决用户在管理上的需求的。
我们看一下企业级云管理平台的架构，这是我们的架构，核心是CMDB和调度，向下强调的是对异构云计算资源的管理。对于企业来说CMDB非常重要，可以存放IT资源信息。还有一个调度的模块，这是我们CMP产品的核心，对于企业客户来说怎么样把资源管理好，这就是一个调度问题。我们还有监控模块，因为我们看到有很多客户有监控的需求。去年开始容器比较火，很多人问容器放在CMP管理还是放在其他系统管理，后面我们探讨一下像容器是否应该放到CMP里管理。下面分析一下我们解决过的客户需求，我相信大家做项目也遇到过。
我们说有CMP，要实现统一管理统一的配置。这样就会解决很多问题，传统的多数据中心管理，如果没有用统一的管理平台，用户操作起来会比较麻烦。这样最简单的需求就是我们上CMP，为了管理多数据中心，多资源池。这是我们实际客户的案例，假如没有CMP，其实从管理角度来说非常麻烦，这里对OpenStack和vcenter复杂的架构，对上面支撑应用，这是实际的场景。
客户传统IT里面有小型机，把小型机放在CMP里面管理。我们需要把小型机资源放到CMDB里头，对于不同类型的小型机通过不同的技术来进行管理。这是我们实际客户上的项目一个截图，把小型机也放在CMDB里头管理。
如果客户已经有了OpenStack，已经有了vCenter，接着客户要上一个CMP，希望直接把资源同步到CMP上。这是顺理成章的事情，我们有这样的功能，比如说客户已经有了OpenStack，直接上了CMP以后，通过CMP就可以直接进行管理。
很多项目里头客户提到了很多网管的要求，客户希望把网管的需求加在CMP里，这是给客户做了数据中心机房的可视化视图。可以看到机架背板的情况。
另外对于虚拟化来说特别重要的步骤，对于云管来说怎么样把资源使用率发挥到最大，一个研发的资源，它的超卖系数可能是平均的水平，一个生产环境它的超卖系数可能是最低的，对于整个虚拟化资源管理，这个超卖系数跟我们说的调度有关系。
这张图，这是物理使用的资源，对于虚拟化来讲，已分配超过物理资源的数量，这个就是说为什么我们用虚拟化，只要使用率低于物理的最大值，我们就可以继续分配资源，这是云管平台特别明显的管理作用。
我们看到云管就是看会不会调度，云的特性就是有弹性，底下是多个资源池，怎么把资源池资源使用率发挥到最大，我们通过CMP做一些事情，我们看到哪些机器晚上可以关机的，比如说这台机器上有两个虚拟机，可以迁移到另外的主机上，可以把这个物理机进行关机，这是基于能源节省的调度方式。
这是基于时间的调度方式，桌面云的业务，这个业务白天才运行，私有云的业务，有些业务可以跑在晚上的，其实这是典型云弹性的需求，桌面云的这些资源在晚上的时候是不使用的，可以把私有云业务迁移到桌面云上跑，白天再把这些业务迁到私有云上，白天跑桌面业务，实现跨云的弹性，这个跟虚拟化软件跟OpenStack没有什么关系了，完全是一个云管的调度功能。
这是我们系统里面做的一个调度，我们用YARN做的调度，YARN是Hadoop的模块，里面有对任务的调度，我们进行了扩展，把调度扩展到虚拟机上，进而做成了我们的调度模块。
举例说明我们的CPU资源调度，比如说有系统预留，有运行中使用的等等。我们有系统预留的参数，调整这些参数，资源使用率达到最大，达到物理资源和业务性能保持平衡。
还有一个更高的需求，就是充分体现云的特性，可以做自动的伸缩，这个也是我们客户的案例。我们说很多做虚拟化资源池的，或者OpenStack的软件，都是基于物理资源来做的，我们看到这个例子里面我们基于应用的性能指标做的，这是业务每秒的并发数，这个并发数达到一千的时候会进行自动伸缩，这个依赖于底下的资源池形具有弹性的能力，通过云管平台能够把虚拟化资源使用率达到最大，而且方便业务系统使用云的特性。
这个我们应用之后，应用部署在虚拟机上，做应用编排的可视化。现在更多用Docker来做，之前用虚拟机做。建一个自动伸缩组，伸缩组编排自动部署，这是基于虚拟机应用的编排。
我们看到涉及到运管它有很多流程的管理，这个流程管理也是比较重要的，这是一个客户实际的案例，这样的一个流程，云管跟OpenStack有很大区别，在这进行一个业务资源使用率的计算，这都是依赖于CMP的调度系统提供的。我举个例子，用户申请了资源，这个资源给业务系统使用，但是这个业务系统资源使用率非常低，业务系统进行扩容的时候，依赖于云管平台提供的调度，得出业务系统资源使用率什么情况，领导进行审批的时候就可以决定这个业务系统是否做扩容，这对管理人员是很好的帮助。
跟传统的OA系统、4A的系统有一些接口的，要和这些系统去做一些同步。把云管和网管、OA、自动认证的系统对接，这样客户的IT管理上，就会形成统一的用户体系和监控体系。
这个也是企业客户提出来的，因为企业客户用了云管，希望把网管功能都放在云管上，这是我们给客户做的存储的管理。
这个完全是一个网管的需求，给客户做一个网管的拓扑。和云相关做出来一个虚拟机之后，要和防火墙、负载均衡有一些关联。比如说我们现在可以用OpenStack的NFV提供的虚拟网络设备接口去做，但是对于有些用户来说它的网络设备不是用NSF，是物理设备，这时候需要同这些物理设备进行对接。
这是我们给客户做得自服务的门户，每个客户对门户需求都是不一样的，我们基本上按照客户需求去做一些定制合作。
我们CMP产品以API方式提供，这样可以和客户的OA集成，和网管集成，和PAAS平台进行集成，这是对于产品级的CMP的需求，不是项目级的，客户需要有这样的产品，客户自己去做集成，包括UI界面的定制，客户也可以自己去做。
下面我介绍一下CMP后续的发展。其实看到我们自己做的一些工作，我们的云管平台，也在向微服务化方向改造，这样我们做集成、开发测试和上线比较方便。这里面是我们把云管平台拆分成一些微服务化。
这个是涉及到调度，涉及到人工智能的方向。左边这个大图是完全基于我们系统的数据，然后人工做的一个分析，这个分析目的其实为了业务系统扩容，给客户提供一些建议。2011年客户的网管使用情况，2012年客户的网管使用情况，推算出来客户每个季度存储、内存等资源使用情况，我们以后可以基于机器学习做这样的事情，这个带来比较好的客户投资收益。传统不是这样的，传统完全根据业务口需求进行扩容。以后基于机器学习，上了CMP以后，基于CMP的数据做一些机器学习的分析。
这个也是一样，左边这个图也都不是基于机器学习去做的，这个基于云管，云管有一个特性，它可以把资源池虚拟化的资源使用率达到最大，这是分析之前的，超卖系数是多少，CPU超卖多少。第二行是分析之后的，这种工作原先我们做了一个算法模型，通过这个算法模型做分析，这个算法模型依赖于业务系统，每个月业务系统都会进行变化，其实这个模型也要变化，我们做的时候比较累，可能每半年调整一次模型。将来我们基于机器学习让这个计算模型自己调整，这样可以把它的虚拟化资源池使用率调到最大。
这个相当于大IT的概念，双模IT中传统的有网管，探索式的有IAAS和PAAS，用户想把IAAS和PAAS在一起管理，上一个IT的管理平台，然后把传统网管、IaaS和PaaS统一起来，将来云管会成为一个大的IT管理平台。
下面介绍一些我们案例，我们做运营商比较多，比如说中国移动、中国联通、教育、政府公共事业，我列出的客户需求也是从这些案例中抽取出来的。这是我们做得最大的就是联通的沃云，这个承载非常多，是全国性的，去年年底达到25万CPU的规模。我就介绍这些，谢谢大家。
Q：负载均衡那一块讲一下。
A：第一种通过Open Stack的neutron组件里面的负载均衡，前提是上了OpenStack可以通过软件来做。但是如果没使用OpenStack，传统都是通过硬件来实现的，比如说客户用的是F5，这时候需要跟F5进行对接，这时候完全是客户定制化的需求了。
A：也不全是对接算法，还要对接其他功能。OpenStack完全依赖于neutron的设计，它提供的算法并不多，如果对接物理设备提供的算法比较多了，因为这是传统的负载均衡设计能够提供的负载均衡能力。比如说基于源IP、基于最小会话数等等的都可以。这种定制化的功能会非常多，因为OpenStack是一个标准软件，你可以实现一个传统的CMP，基于F5去做要根据不同项目去做定制。
Q：你们在调度异构资源的难点是什么？你们调度异构资源怎么去做？
A：难点在于一个是同步，一个是大数据量处理。CMP能进行操作，资源池也能进行操作，同步处理不好会遇到很多麻烦的。另外就是大数据量处理，我们管理几千台物理机，上面虚拟机就更多了，这种大数据量处理非常复杂，在我们系统架构里面我们有一个rabbitmq，其实是一个缓存的消息处理方式，OpenStack的rabbitmq也是一样的。我们通过消息队列来去处理。异构管理比较难的地方，最开始比较难就是同步。
Q：你是实时更新状态还是手动更新？
A：系统自动去做的，如果Open Stack限定在20台机器以内，对监控要求比较高，在运营商用户上Vcenter管得资源都是上千台，一旦量级上去对于CMP整个同步能力要求非常高，这里头也涉及到监控，物理资源达到千级规模，它的虚拟资源更多了，对于监控也是比较关键的地方。
Q：我这块有两个问题，第一个咱们资源调度这块我有两个想跟你确认的，咱们跨平台的角度。跨什么平台都可以吗？
A：可以。
Q：跨数据中心吗？
A：可以。这里面有一些网络改造工作，跨多个数据中心，多个数据中心生产网络要通，否则跨另外一个数据中心没有意义。我们考虑和业务的相关性，我会把业务很多属性作为调度的依据，我们说像vCenter和OpenStack基本上考虑都是基于资源做调度，很多的客户，我接触到的，包括我们OpenStack很多合作伙伴的客户，他们都不喜欢用调度，也不喜欢用这些云的一些特性，因为OpenStack和vCenter都是针对资源的的，会导致业务运行出错，我们用业务属性，再结合资源属性做调度。
Q：咱们对存储资源做一定的监控，管理和调度，这块咱们做到什么程度？
A：我们对SAN存储、对象存储、NAS存储都对接过。
Q：我们对接到存储厂商管理端还是？
A：比如说SAN存储，基于国际上SMIS的协议去做，这个协议是开放的，但是不同的存储厂商对这个协议支持不一样。举个例子有的存储厂商，不同型号也不一样，它可能对这个协议支持到70%，有的只能支持20%的功能。对于NAS存储和对象存储比较新的，这个可以实现100%。
Q：就是我们整个SAN存储管理是基于SMIS做的是吧？
A：对。
标签：term oba 完全 kff ase sea ice 迁移 pat
原文地址：http://blog.csdn.net/horsefoot/article/details/70876523
