【译】vSphere与OpenStack的集成
2013-09-05
原文标题:OPENSTACK COMPUTE FOR VSPHERE ADMINS
原文链接(一共五篇,这里列出第一篇):http://cloudarchitectmusings.com/2013/06/24/openstack-for-vmware-admins-nova-compute-with-vsphere-part-1/
翻译者:华为云计算工程师 吴江
团队:Huawei OpenStack Team
在与客户交流中,被问到很多关于OpenStack与VMware比较的问题。如何集成如何选择?如果商业用户选择OpenStack,是否意味着他们会废弃vSphere?这里,我来谈下VMware集成到OpenStack的问题。
一、架构描述
VMware之前已经有接入OpenStack的方案。但之前对接ESXi的代码,不是VMware而是Citrix贡献的,有很多功能限制不易维护;现在VMware成为董事后已经主动开始维护了。
我认为Sphere和OpenStack的深度融合,对于那些之前已使用了VMware系统,但现在又想将应用迁移到OpenStack上的用户来说,是非常重要的。
1.1 OpenStack 整体架构
OpenStack采用一种无共享的、基于消息队列的架构,解耦的各模块组合在一起构成了一个统一的IaaS云。架构大家都熟,这里不冗述,需要的请参见这里。
1.2 Nova-Compute
Nova-Compute是Nova中的一个组件,主要负责VM的生命周期管理。与OpenStack中大多数模块相同,Nova也可以部署到单主机或多主机上,各部件的功能这里也不详述,详情参考这里
很多人都直接将OpenStack与vSphere进行对比,但这样是错误的。从架构来看,OpenStack所处的位置实际上是位于hypervisor层之上的。通常说的OpenStack或者准确点说Nova,实际上类同于VMware中vCloud Director(vCD)+ vCloud Automation Center(vAC),而不是ESXi或者vCenter。事实上很重要的一点是,Nova是不包含hypervisor的,它是通过API+Driver来组织/管理多个hypervisor的,例如KVM、ESXi。目前支持的hypervisor,包括KVM、vSphere、Xen等,详细支持列表可以到这里查看。
1.3 vSphere与Nova进行集成
目前OpenStack Nova可通过以下两个驱动来支持vSphere 4.1或更高版本:
- VMwareESXDriver:最早由Citrix提供,后续由VMware更新,允许Nova通过vSphere SDK直接与ESXi主机进行通信。
- VMwareVCDriver:由VMware在Grizzly版本中加入,允许Nova与管理ESXi主机集群的vCenter进行通信。
请注意,本文着眼于Nova,暂不讨论存储与网络相关的内容。
1.4 EXSi与Nova的集成(VMwareESXDriver)
逻辑上看,Nova-Compute服务直接与ESXi主机通信。由于未引入vCenter,因此vMotion、HA、DRS等高级功能都不支持:
- 不像基于内核的hypervisor,VM是跑在ESXi服务器上的,而不是默认的计算节点上。
- 尽管OpenStack已支持多hypervisor,但每一个计算节点仅能支持一种hypervisor。因此,在multi-hypervisor的OpenStack混合云下,对于每一种hypervisor类型就至少要有一个计算节点来对应。
- 当前ESXDriver有限制,每个Nova-Compute服务仅能支持一个ESXi主机。
1.5 EXSi与Nova的集成(VMwareVCDriver)
逻辑上看,OpenStack与vCenter直接通信,VC管理整个ESXi集群,vMotion、HA、DRS也都能用了。但vCenter从Nova-Compute中抽离出了ESXi主机,Nova-Scheduler将整个自管理的集群作为一个独立主机接入——这会导致一些问题,如在多计算节点环境中,如何正确调度/部署这些VM;这点我会在后面介绍到。大致特点如下:
- 不同于基于内核的hypervisor,vSphere需要一个单独的vCenter主机,VM是运行在ESXi主机上而不是计算节点上。
- 尽管OpenStack已支持多hypervisor,但一个计算节点同时只能支持一种hypervisor。因此,multi-hypervisor的OpenStack混合云,对于每一种hypervisor类型就至少要有一个计算节点来对应。
- VCDriver有限制,每个Nova-Compute服务仅能对应一个vSphere集群。当计算节点作为VM运行在同一集群下时,就具有了HA能力。
- VCDriver中每个cluster都要有一个datastore来进行配置和使用.
二、Nova-Scheduler & DRS
2.1 vSphere与Nova Compute中的资源调度
上一部分已经给出了vSphere如何集成入OpenStack Nova的概述,在展开阐述之前,我认为有必要先介绍下Nova中的资源调度即Nova-Scheduler,以及vSphere的DRS功能。我会展示DRS与Nova-Scheduler的区别,以及两者如何配合的问题。
2.2 OpenStack Nova-Scheduler
Nova使用Nova-Scheduler服务来确定VM需要创建到哪个节点上。Nova-Scheduler,同DRS一样,通过一些具体参数、policy、亲和性规则,来自动选择VM初始创建的位置。但是,Nova-Scheduler在VM创建之后,是不会再进行周期性LB+电源管理的。你可以在nova.conf中找到很多配置项。
scheduler_driver=nova.scheduler.multi.MultiScheduler compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_available_filters=nova.scheduler.filters.all_filters scheduler_default_filters=AvailabilityZoneFilter,RamFilter,ComputeFilter least_cost_functions=nova.scheduler.least_cost.compute_fill_first_cost_fn compute_fill_first_cost_fn_weight=-1.0
这里有两个关键参数:schedule_default_filters
和Least_cost_functions
(其实这个参数在最新版本里已经被deprecated),它们反映出在确定主机时Filter Scheduler的两个计算过程(还有另两个调度算法分别是Chance Scheduler和Multi Scheduler,但是Filter Scheduler是默认的调度算法并且是适用于绝大多数场景的)。这两个参数一起作用,在创建VM时对整个计算节点下的资源做了负载均衡,和ESXi集群中DRS所使用的Dynamic Entitlements + Resource Allocation Settings 所完成的工作一样。
关于Nova-Scheduler,这里不做过多分析,请参见孔令贤的博客。
2.3 DRS 与 Filter Scheduler
在阐述了Nova如何调度资源后,我们来与DRS做个对比,然后讨论下这两者如何一起工作。注意,这里我不再讨论Nova与单独ESXi主机如何进行调度,因为这和其他hypervisor是一样的。我这里主要说下Nova+VCDriver,如何与vCenter管理的ESXi主机进行配合。
在之前文章中,已经提到了vCenter将ESXi主机与Nova-Compute服务抽离开了,Nova-Scheduler将整个集群当做一个单独的主机,主机的资源由下面ESXi节点共同组成。这会带来影响:
Nova-Scheduler一旦选定了一个vSphere集群后,就不在参与集群中具体的选主机工作了;Nova-Compute只是简单的调用vCenter的API。后续vCenter会根据Dynamic Entitlements和Resource Allocation settings来选择一个具体的ESXi主机,并自动进行LB和DRS,这个过程Nova是不感知的。
在上图示例中,节点1有8GB RAM剩余,而节点2看上去有12G RAM。Nova-Scheduler无法区分节点2上的12GB 加和RAM,是否是真实可用的RAM资源。
因此这里就会存在问题,让我们来分析一下两个应用场景下资源的分配情况。环境采用上例中假设的,并且允许pRAM 50%超分配:
- 用户请求一个10GB RAM的VM。
Nova-Scheduler根据RamFilter,经过筛选后会认为vSphere计算节点是资源充足的,即使每一个ESXi主机上都没有足够的RAM。一旦vSphere被选出来创建VM,则vCenter会根据之前的DRS规则来判断是否有足够的资源。
- 用户请求一个4GB RAM的VM。
Nova-Scheduler根据RamFilter,筛选后会认为这两个节点都满足要求,然后通过权重算法最终倾向于选择RAM更充足的vSphere计算节点来创建。可以看出,当hypervisor/计算节点的RAM资源不充足时,它可能会在创建时被错误的分配到一个cost数值,导致系统变得不再平衡。