本文适合cinder的初学者，只要你好奇cinder scheduler是个什么样的存在，本文会把其它文章没有告诉你的事情全告诉你，是的，全告诉你。
首先，大家都知道，cinder可以配置多backend（也就是多个cinder volume进程）来运行，那么cinder scheduler是通过什么机制，来选择正确的backend创建这个指定卷的呢，如果你想通过在scheduler中搜索类似backend之类的关键字，来尝试了解这个事情的话，你只能扫兴而归了。码农用代码说话，codes tell everything，所以本文会通过cinder的源代码（以下源码基于社区Ocata版本），告诉你scheduler幕后的故事。
1. Cinder multi backend
在说cinder scheduler怎么从多个backend中选择其中一个来创建卷之前，当然，你得有多个backend在运行，故事就从这里开始。
为了在cinder volume上运行多个backend，cinder.conf需要配置一下，下面是一个经典的配置：
enabled_backends配置里定义了需要运行的backend，然后在配置文件里需要以这些backend的字符串（这里说“字符串”而不说“名字”，是为了避免与接下来的一个配置volume_backend_name混淆）定义相对应的section，在section里添加volume_driver，以及这种volume_driver所必须的配置项。还有一点非常重要，需要定义好volume_backend_name，这个配置在接下来会有神一般的作用。不同backend可以使用相同的volume_backend_name，你可以理解为，这些使用相同volume_backend_name的backends都具有同样的特性。
各个backend所对应的cinder volume进程运行起来之后，manager会定时获取driver的状态，如下图所示，cinder/volume/manager.py：
这些状态中包含了这个backend所能提供的capabilities，其中一个重要的数据，就是volume_backend_name，这个backend_name就来自于配置文件中的volume_backend_name。以下以cinder/volume/drivers/lvm.py为例：
然后，volume manager通过RCP调用，定时将自己的最新状态发送给scheduler，如下图所示（cinder/manager.py）：
所以，通过各个backend主动上传，scheduler就能够实时获悉系统中所有的backend的信息，这是scheduler能正确调度的重要前提。
2. Cinder volume type
有了多backends作为基础，cinder还定义了volume type来帮助scheduler选择恰当的backend来创建卷，创建volume type时，需要定义这个type所对应的volume backend：
命令中volume_backend_name所填写的值，就是配置文件中定义的volume_backend_name。cinder type-key命令除了能设置volume_backend_name这个属性之外，还可以设置其它任意的属性，这些属性都会作为volume type的extra specs保存起来（这些extra specs是不能随便设置的，否则会导致创建卷时发生no valid host的异常，稍后会有解释，在上面的例子中，我们没有指定任何其它的extra_specs）。这样，就把volume type和某个backend关联起来了。
于是在创建卷时，用户可以通过下面的命令指定volume type：
# cinder create --name test-vol --volume-type local-storage-type 10
Cinder scheduler会从指定的volume type中取出type所包含的extra specs，包括type对应的volume_backend_name，以下是cinder scheduler解析出的创建卷请求的片段：
3. Cinder capacity filter
在第一部分中我们已经解释到，各个backend已经定时将自己的capabilities通过RPC通知scheduler，所以当使用filter来作为scheduler时，scheduler可以针对已知的所有backends的capabilities，与待创建的卷中指定的extra_specs进行比对，如下所示，cinder/scheduler/filters/capabilities_filter.py：
只有backend中所有specs都与创建卷时指定的volume type所包含的extra specs相匹配，这个backend才会被视为可备选的backend来创建卷（所以如果在创建volume type时随意指定extra specs，就会导致这些extra specs与scheduler获取到的真实的backend上传的capabilities不匹配，从而引发no valid host而无法创建卷的问题）。在得到符合条件的backends之后，scheduler会根据特定的权重算法，对backends进行排序，并取出第一个作为新卷所使用的backend。
总结
至此，我们已经把cinder scheduler中所涉及的方方面面用最简单的方式串联起来了。总结起来，包括以下几个阶段：
-
Cinder volume进程定时向scheduler上报自己的capability，包括自己的volume_backend_name
-
用户创建volume type，并将此volume type与某个volume backend关联（通过指定volume_backend_name这个特殊的extra spec的方式）
-
用户创建卷时指定volume type
-
Cinder scheduler在选择backend创建卷时，会将用户指定的volume type中的extra specs与它获得的各个backend上报的capabilities进行匹配，只有全部符合条件的backend才会成为候选，所以volume type中指定的volume_backend_name自然会匹配到以同样名字命名的backend。
这些，就是看似简单，但其它文章中没有告诉你的细节。现在，你再也不会为找不到cinder scheduler中与backend相关的filter而苦恼了。