OpenStack运维中资源调度的错误排查

回望二十一世纪已过去的十六个年头，云计算可谓赚足了风头，而作为云计算IaaS(基础设施即服务)模式的新贵，OpenStack打出生起(2010年7月份NASA和Rackspace公司将其开源)便立马集众方IT大佬如IBM、Red Hat、HP、Inter等宠爱于一身，一时间IT界众多门派、各路草莽纷纷出钱出力以促进OpenStack的茁壮成长，而OpenStack不负众望，以其开源免费、可扩展、高兼容等优良品德立名IT界，迅速坐稳开源云市场占用率头把交椅。

本文将基于OpenStack最新release的liberty版本，分析OpenStack的虚拟机资源调度服务nova-scheduler的调度流程，并逐步说明OpenStack管理员在进行资源调度的错误排查过程中的尴尬境遇，然后提出一个OpenStack资源调度错误排查的改进方案，最后，本文会为大家展示IBM PRS（Platform Resource Scheduler）基于此方案的实现版本。

OpenStack虚拟机的资源调度

OpenStack对虚拟机的资源调度由nova模块的nova-scheduler服务实现，根据调度策略的不同，有两个插件：基于filter的调度和基于随机策略的调度，其中基于随机策略的调度仅对正在服务的host随机选择，不进行任何资源审查，在实际生产环境中基本上不会用到，所以本文仅就OpenStack的默认的调度策略：基于filter的调度进行分析。如图1所示，该策略主要通过三步完成虚拟机的资源调度返回候选host：

图1.基于filter的调度workflow

Step 1：获取所有host的信息，如果调度请求中要求忽略一些host(ignore hosts),就将这些host从本次的候选host中删除掉（一种特殊的情况是如果调度请求中要求虚拟机只能调度到一些host或者节点上，则只保留这些host作为候选host,不会对这些host做进一步额外的资源审查即step 2便直接返回）。

Step 2：将第一步中返回的host列表依次迭代地通过scheduler_default_filters配置的所有filter的host_passes处理函数，该函数会过滤掉不满足相应filter条件的host。

Step 3：对第二步返回的host列表根据scheduler_weight_classes配置的weigher对候选host进行排序。

至此调度服务完成对虚拟机的资源调度，nova-conductor服务将会向调度服务选出的host所对应的nova-compute服务发出虚拟机部署请求。由于OpenStack调度服务固有的race condition,当虚拟机在compute节点部署失败时，相应nova-compute服务将会向nova-conductor服务发送重新部署对应虚拟机的请求，用户可以通过scheduler_max_attempts配置最多可以容忍compute部署失败的次数，该reschedule机制如图2所示：

图2.OpenStack资源调度的reschedule机制

由上可知，当我们在部署一个虚拟机的时候，本质上有两类型的错误可能导致部署失败：第一是调度服务发现没有host可以满足虚拟机的资源需求，第二是虚拟机在调度服务选出的目标host上部署时因为某种原因部署失败（如卷请求超时或者网卡创建失败等等）