资源如何通过资源池的方式统一构建与管理（五大难点必须了解）

云计算的核心目标是资源的按需动态快速供给!要想达到这一核心目标，除了上层的虚拟化、自动化外，还需要有底层的资源池支撑。要想资源能够快速随需供给，就需要企业提前构建好资源池。

所以：

1、如何理顺机房、计算、存储、网络各专业资源之间的关系；
2、如何标准化资源池的构建规范、资源组成和构建流程；
3、如何管理和维护资源池，如何对资源池进行分层、解耦，各种异构的资源池如何统一化管理；
4、如何对资源池进行容量管理，实现资源的最大化共享、最高效的利用、最节约成本；
5、资源池的划分粒度应该如何，有什么好的思路和方法。

也就成为各家企业在实施云计算时需要重中之重考虑的事情。因此应该如何解决这些难题？听听多位专家的观点。

1、如何标准化资源池的构建规范、资源组成和构建流程，如何管理和维护资源池？

观点一：为什么需要资源池，构建资源池的主要目的还是为了将资源化最大化的共享。资源池是可以对外提供相同服务能力的硬件和软件的组合。也就是说，资源池内部的资源形态对用户是屏蔽的，这些资源可以随需动态以服务的形式提供给用户，用户看到是服务而不是真实的物理资源。这些资源即可以给A用户使用。资源池包括计算资源池、存储资源池和网络资源池。
资源池的构建规范、资源组成和构建流程都是围绕着服务来展开的。比如，企业要提供X86虚拟机服务，那么就需要构建X86虚拟机资源池，这类资源池可能是由X86服务器、网络交换机、分布式存储（抑或NAS存储）组成，而资源池又根据网络、地域的不同进行了不同区域的划分，从而为客户提供不同网络、不同地域的X86虚拟机服务。资源池的构建流程包括物理资源的选择、落位、上下架、自动化安装等。由于不同企业的组织架构、管理理念不同，构建流程需要依据企业实际情况而定，但尽量可以自动化完成。
资源池还要做好容量管理，这样才可以最快速的相应客户对服务的需求。所以资源池的管理和维护，更多的时候是围绕着容量管理来开展的。

观点二：主要还是管理流程的规范化，企业对不同业务系统是分类别，分级别的，自然资源池也是分类别，分级别的，不同类别的和级别的资源池所对应的管理流程和维护流程是有所区别，肯定重要应用所获得的资源及时性和可靠性要不同于一般应用，因此在资源供给和日常维护都会优先考虑，本质上流程都一样，都会规划，申请，使用，监控，回收动态闭环过程，只是时效性不同而已。

观点三：资源池建设标准化涉及范围非常广，总的来说可以分为资源管理标准、资源运维标准和关键技术标准三个方面的内容。
资源管理标准包括网络、计算、存储、平台、数据、终端管理等内容。以计算和数据资源管理为例，计算资源管理主要制定用户和计算服务的交互接口，同时支持用户上层应用的跨计算平台部署。数据资源管理标准制定块存储、对象存储、文件存储管理接口功能和协议，使之符合复杂异构存储环境下资源存储信息模式和管理等方面的技术和管理相关要求。
资源运维标准包括运维模型、故障管理、资源监控、资源调度等方面内容。以运维模型和资源监控为例，运维模型标准主要制定云计算资源运维的参考模型和接口规范，用于指导IT系统运维的实施，而资源监控标准则是制定物理和虚拟的计算、存储、网络等云计算资源的监控、响应支持、优化改善、应急处置等方面的标准，用于指导系统运维，支持运维软件系统的研发。
关键技术标准包括网络、设备、平台与软件、虚拟化等方面。以网络、虚拟化技术为例。网络技术标准主要制定数据中心内、数据中心间）、用户与网络互联互通方面的标准，规范内网络连接、网络服务、网络管理。虚拟化技术标准主要制定虚拟机总体技术要求、虚拟资源管理要求、虚拟资源描述格式、虚拟资源监控要求和监控指标等方面的标准，用于指导虚拟化技术和虚拟化产品的研发、测试，支持实现应用和数据迁移。
上面说的都是操作层面的问题，我想谈这个问题之前还是多关注业务层面的东西，业务是什么，业务对资源有什么需求，脱离了业务谈资源总有些本末倒置。

2、如何对资源池进行分层、解耦，各种异构的资源池如何统一化管理?

观点一：资源池的分层、解耦主要基于应用特点考虑，包括应用分级和应用用途。
首先是应用分级，不同级别的应用系统使用的资源池必须要区分开来，例如关键的服务系统和渠道系统需要分开，交易类系统和管理类系统要分开；
其次是应用用途，俗话说好钢用在刀刃上，资源应该按照可靠性、纵向扩展能力、成本等方面分层，分别用于最合适的用途。例如把如关键的数据库、消息中间件放在PowerVM资源池，次重要的数据库放在VMware资源池，可分布式部署的放在KVM资源池。
除此之外，还需要根据各计算资源池特点分配相应存储池，在保证高可用和性能的同时，又尽可能地降低成本。
至于统一管理，我们是采用商业版本的OpenStack对接VCenter、PowerVC，并直接管理KVM，实现各种异构资源池集中管理。

观点二：可以将资源池分为物理资源池和逻辑资源池两层，物理资源池主要是根据物理设备的电气特性、配置特性等进行分类、池化，而逻辑资源池则是根据网络、用途（提供的服务）的不同将设备进行池化。这样，用户在申请服务时，是在逻辑资源池中分配资源，而逻辑资源池在扩容时，是在物理资源池中分配资源。这样，就可以将服务的运维、资源(软硬件)的运维、物理硬件的运维（上下架、加电布线）进行解耦。
异构资源池，我理解有两类异构。一类是设备的异构，但是对外提供的服务是一致的，如华为服务器和浪潮服务器是异构设备，但对外都可以提供X86 虚拟机服务；一类是设备和服务都是异构的，如X86服务器和AIX服务器是异构的，对外提供的服务也是异构的。无论是哪类异构，如果要统一化管理，都需要资源池管理软件的支持。要对相关设备和软件进行抽象，对上提供的服务接口是一致的，对下适配不同的软硬件。

观点三：资源池分层和解耦一般是以设备自身软硬件特点来进行的，对于企业来说，一步到位的设备采购都是不实际的，会随着企业信息系统的真实需求和技术发展而会发生变化，如果想简单了事，一般以同一时期或者同一型号的设备作为一个资源池等等，异构的资源池统一管理大多以软件来做接口统一，这样方便也易于长期发展，使用硬件容易受厂家制约。

观点四：针对这个问题，我更赞成自顶向下的思路去做好顶层设计和业务规划以及IT规划，这是理想的方式。首先还是理清楚业务本身的需求，业务理清楚了，应用必须实现分层，展现层业务逻辑层和技术支撑层一定要分开，也就是按照SOA、微服务等理念做好应用的分层解耦。应用层应该重点解决业务逻辑本身的问题，共性的支撑能力应该下沉到平台等，也就是“厚平台、薄应用”的概念，应该尽量避免单体应用的出现。
应用实现了分层，自然会映射到资源层。
无论是物理资源、虚拟化资源、小型机资源、专用资源，都应该统一看作可利用的资源组件，组件按照分级分域的理念，实现池化。
资源本身性能各不相同，所以用户依据业务等级选用不同资源，通过合理的网络划分及安全访问手段实现不同资源的隔离，进而实现了资源分层。
对于计算、存储、网络异构资源管理分别有不同的做法。就计算资源来说，openstack等开源云管平台已经为kvm、vmware、物理机等资源分别配置服务接口，能够实现统一纳管。对于存储资源，通常是以存储虚拟化网关的形式，对接不同厂商的存储，实现存储资源异构管理。而对于网络资源，未来的趋势则是借助SDN和NFV技术，将网络配置工作通过SDN控制器统一下发，而异构网络设备逐步变为白盒式的网元设备。
一般实现异构资源的统一纳管，比较可行的是借助第三方统一云管实现上述各类资源的统一纳管，至于实现到什么程度，是统一视图的监而不控，还是真正实现纳管，要看具体的力度。

3、如何对资源池进行容量管理，实现资源的最大化共享、最高效的利用、最节约成本？

观点一：容量管理一直是个难点，对于CPU我们的做法是不同的环境制定不同的超分比来控制。
对于存储，通过容量动态趋势分析来对未来一定阶段存储容量做预估，从而实现业务需求。
对于最大化共享、最高效利用，目前也是在追求中。

观点二：先要对资源池制定容量指标。例如，X86虚拟机资源池一般会对CPU、内存和磁盘容量制定容量指标。制定相关指标好，要设置好扩容水位线。扩容水位线的设定与扩容周期相关，如果扩容周期要长达数月，那么扩容水位线的阈值最好低一些，如果扩容周期很短，则可以低一些，目标是在扩容周期内资源使用率不会达到100%。除了设置扩容水位线外，还要设置扩容目标线，也就是在扩容后，容量使用率应该下降到的百分比，以便在相对一个容量评估周期内容量使用率不会触及扩容水位线。
日常运营除了需要时时监控容量是否达到扩容水位线外，还需要定期进行容量评估，容量评估主要有三个数据来源，一个是用户的资源需求预估、一个是历史趋势分析、一个是资源现状，目标是在一个容量评估周期内，容量使用率不会触及扩容水位线，这样就可以计算出需要扩容的资源数量。
通过这些方法，就可以使得资源既不会因为不足而影响到服务供应，也不会因为设置过多buffer导致资源浪费、成本居高不下。

观点三：首先这个问题应该从资源池规划的角度去看待，应该做好容量规划、设好阈值和水位线，由粗到细。
不同种类资源池（计算、网络、存储）管理技术手段不同，但是容量管理本质上是一个运维优化的问题。可以选用容量水位（集群流量 / 集群性能 x 100%）作为容量管理规划模型，集群流量测定主要通过线上监控手段，而集群性能主要借助线上压测等手段。通过预定义安全水位、加机器水位等水位线，当集群负荷达到特定水位线时采取相应的措施。最关键的还是最好前期规划。

观点四：资源池容量管理包含计算资源、存储资源、网络资源甚至还有安全资源。实现资源最大化共享通过资源虚拟化技术是最好的解决办法，通过虚拟化后的资源池化，可以依据底层资源的不同特点和性能优势划分不同的资源池，能够最大发挥资源的利用率，同时起到节约成本，管理优化的目的。

4、企业现有系统改造为资源池统一管理，是否需要较大工作量，应该如何准备？

观点一：说实在的，不管对现有系统做什么样的改造，都不但有工作量，还有不少风险。我们一般是采用新建系统试点、推广、现有系统升级换代逐步切换的方式来推进新技术应用的，云计算也不例外。
如果你们要做的话，可以从虚拟化入手，在部分新系统建设过程中把KVM、VMware、PowerVM用起来，积累经验，同时建立各种专业虚拟化/基础云管理平台（如VCenter、PowerVC）；然后逐步由OpenStack来接管KVM、VCenter、PowerVC，定制开发需要的服务编排，实现主要场景资源的快速、标准交付。如果时间允许，可以考虑开发测试先行，生产稳步推进的策略。

观点二：云化或者资源池化，我感觉更多的时强调IaaS层的内容，这块内容其实主要就是CPU和内存（虚拟机）、网络（SDN)和存储（SDS)三类。每一类技术都有不同的开源或者商业产品来提供功能实现，如果要想整合，感觉主要的有两个功能
1.给PaaS层提供资源使用的API，如果通过接口来抽象化这些功能，屏蔽掉底层的具体实现技术，那么PaaS层使用起来就会非常简单；
2.给PaaS提供资源分配的相关策略，让PaaS作为资源消费者，可以方便的指定对资源的要求（比如需要大容量，还是高IOPS等），那么PaaS层使用起来就会非常灵活;
个人感觉资源池管理是一个抽象的功能，要实现这些平台功能，做真正做到简单和灵活还是需要很多工作要做的。

观点三：统一管理的话首先要看期望做到IAAS层面还是PAAS层面。
对于IAAS层的统一管理，借助于openstack云资源管理平台，通过nova、cinder、neutron等模块，用户可以对数据中心内的计算、存储、网络资源进行统一调度和管理。如果存在着多个数据中心资源池，借助SDN、vxlan技术，可以实现数据中心二层打通，将多个数据中心变成一个大的逻辑统一资源池。
对于PAAS层来说，资源统一管理有两个思路，其实核心思想都是SOA的服务复用化。第一个思路是运用传统的ESB中间件，将多个业务系统对接到服务总线平台，首先实现了业务流，满足业务逻辑，其次可以通过服务编排形成新的业务系统并对外发布。另一个思路是采用容器技术，将服务拆分尽量细化，运用k8s或mesos等编排器，实现微服务的架构。从应用角度看，众多无状态的容器，就是组成应用运转的统一资源。

观点四：如果企业现有业务系统已经上线运行，那么改造为资源池统一管理，个人感觉还是需要谨慎一些。涉及业务系统较多，各种业务的具体需求不同，可能业务梳理的过程更加繁琐和漫长。假如资金不是问题，建议为了未来业务系统的长治久安，也为了更快迁移，可以构建一套新的资源池化的系统，然后迁移过去，更简便些。

5、资源池的划分粒度应该如何，有什么好的思路和方法？不知道资源池的划分粒度应该如何？是基于设备能力定义资源池呢？还是将设备能力根据型号笼统的抽象，调度的策略是根据应用的需求划分成不同的SLA能力要求，用户选择对于的要求，系统自动的去匹配对应的存储资源。

观点一：资源池的划分粒度和想要提供的服务容量，服务种类规划，设计方案的网络边界相关。
1，服务容量，这类似于一个基础单元的容量，每次新增一个基础pod，能够释放多少容量，对自身的采购有很大作用，比如一次面对几百台机器的交付，设计50台一个小范围的池子，按需增加；
2，服务种类，决定了是否按SLA设计资源池，提供不同的服务，比如2种服务成本差距很大，池子就有不同的结构了，那就没必要在一起，单独边界；
3，网络边界，确定了漂移，迁移，维护的范围最多能支持多少，作为复杂度多少。

观点二：建议根据资源可以提供的服务能力来划分资源池。举个例子，如果企业认为KVM虚拟机和VMWARE虚拟机提供的虚拟机能力是一致的，而且希望这种虚拟机类型对用户是透明的，那么这些虚拟机所承载的宿主机就可以是一个资源池，反之则是两个资源池。
资源池的划分粒度一般有网络、机房、用途等。

观点三：由于资源池后期可能会有设备更新或者新增，对资源做一些型号抽象会更好，对于资源池，根据实际服务能力划分多个资源池会更好一些，毕竟资源池的底层硬件可能有所不同，比如同为100G的存储池，可能一个是纯SSD的实现，适合数据库等IO要求高的，另外一个是机械盘，适合一些IO不敏感的场景。

以上核心内容。均是出自交流活动多位专家的观点，如果您有自己的看法欢迎探讨。
更多精彩观点查看：

以上核心内容。均是出自交流活动多位专家的观点，如果您有自己的看法欢迎探讨。

更多精彩观点查看：

http://www.aixchina.net/activity/?id=673