云计算技术是一系列复杂基础技术的综合体，包括物理设备管理、计算虚拟化、分布式存储、网络虚拟化以及软件定义数据中心等，基于这些技术构建的云计算平台无疑是一套复杂的系统。在这样复杂的系统中充当“大脑”角色，管控决策所有资源使用的部件是 云调度器 .
在云计算的模式下，传统“烟囱式”的独立的服务器、存储和网络等物理资源被虚拟化成一个个共享资源池，云调度器通过资源使用调度的策略自动为云平台上的业务统一调配资源，以满足业务对基础设施资源的动态需求。
本文将为您解密云之“大脑”的工作原理，展示华云数据在OpenStack核心领域的技术创新。
资源的分配和调度是云计算中的关键技术，那么云调度器是如何工作呢？作为国内最早一批开始对Openstack进行研究及应用的团队，下面就以目前流行的开源云计算平台Openstack为例，阐述其调度器（Nova scheduler）组件是如何管理和控制云平台资源的。Nova scheduler是Openstack核心服务nova的组件之一，主要负责为创建、启动的云主机实例寻找合适的计算节点，同时在迁移云主机的时候负责检查目标端计算节点的物理资源是否足够。下面就谈一谈我们对Nova scheduler技术原理的解析与应用优化。
原理解析
下图是Openstack架构图，从中我们可以看出Nova scheduler是通过与Message queue和Nova database交互来完成调度任务。
云调度器的核心任务是：基于业务对资源的请求，从当前所管理的所有云资源中选择最适合的资源分配给该业务，使该业务正常部署和运行；但何为“最适合”？在不同的场景下可能实质含义不同，有的希望业务尽量运行在较少数量的机器上以节省电力消耗，有的则希望业务尽量均匀分布在所有可用的服务器上，以保障运行性能；因此，这里的“最适合”是相对于特定场景下所定义的调度策略而言的。
下图是Nova scheduler的简化工作流程图，首先根据配置的Filters（过滤器）过滤出符合条件的主机列表，然后对得到的主机列表进行权重并排序，最后选出最优的Host.
Nova scheduler的主要流程包括：
2.1主机过滤（Filters）
2.2权值计算（Weighting）
2.1 主机过滤
所有的Filters实现都位于nova/scheduler/filters目录，以Openstack Mitaka版本为例：
├── affinity_filter.py
├── aggregate_image_properties_isolation.py
├── aggregate_instance_extra_specs.py
├── aggregate_multitenancy_isolation.py
├── all_hosts_filter.py
├── availability_zone_filter.py
├── compute_capabilities_filter.py
├── compute_filter.py
├── core_filter.py
├── cpu_pinning_filter.py
├── disk_filter.py
├── exact_core_filter.py
├── exact_disk_filter.py
├── exact_ram_filter.py
├── image_props_filter.py
├── io_ops_filter.py
├── isolated_hosts_filter.py
├── json_filter.py
├── metrics_filter.py
├── numa_topology_filter.py
├── num_instances_filter.py
├── pci_passthrough_filter.py
├── ram_filter.py
├── retry_filter.py
├── trusted_filter.py
├── type_filter.py
目前，社区的OpenStack Mitaka支持以上这些过滤策略，开发者也可以根据具体需要实现自己的过滤策略。为了便于扩展，Nova将一个调度器必须要实现的接口提取出来成为nova.scheduler.driver.Scheduler，只要继承了该类并实现其中的接口，我们就可以自定义任何我们需要的调度器。启用它们只需要在 /etc/nova/nova.conf配置文件中的添加该过滤器即可。
2.2 权值计算
所有的Weigher实现都位于nova/scheduler/weights目录，以Openstack Mitaka版本为例：
├── _init__.py
├── metrics.py
├── ram.py
尝试在一台不适合的主机上创建云主机的代价比在一台合适主机上创建的代价要高，比如说在一台高性能主机上创建一台功能简单的普通云主机的代价是高的。
OpenStack对权值的计算需要一个或多个（Weight值，代价函数）的组合，然后对每一个经过过滤的主机调用代价函数进行计算，将得到的值与weight值乘积，得到最终的权值。开发者可以实现自己的代价函数，设置自己的Weight值来更精确的利用更加复杂的算法选择主机。下图展示了对于每个宿主节点如何计算Weight值，以及最后根据Weight值排序，挑选出当前最合适的节点的过程。
华云数据对Nova scheduler的优化与应用
3.1 基于指标监控的动态调度支持
OpenStack原生调度器自带了很多基础的Filters过滤策略，能够满足大部分的使用场景，但是这个调度的基本机制是静态的，即在资源开通过程中基于请求的资源数量完成调度分配决策，而不考虑业务实际运行时对各种资源的使用情况，所以可能出现该调度分配在部署时是最优的，但在运行时并不是。比如有两台服务器A和B，vm1已经运行在Host A上，现在要开通vm2，假如按照资源最优的方式调度，vm2被调度到Host B上，经过一段时间的运行，发现vm1与vm2间经常有大量网络通信，我们知道在云环境下，跨节点的网络通信性能是不如同节点上的网络直接转发，所以基于运行时情况，让vm1与vm2同时运行在一个host上会是较优的方式。
基于上述考虑，华云云平台引入了基于运行时指标监控的动态调度支持，即通过对业务vm的持续指标监控（包括cpu、磁盘、内存、网络io、业务的峰谷、vm间的通信量等），充分考虑业务vm在运行时的资源需求，提供再次优化调度建议。通过纳入运行时情况指标运算，优化调度所挑选的host和初始调度的host很可能不一样，如果不一致，可以通过动态迁移机制完成迁移，使之达到阶段性的最优分布。
3.2 调整云主机大小
OpenStack Nova的resize功能内在实现是基于冷迁移， 只不过resize在迁移后使用了一个不一样的flavor.
OpenStack在处理resize接口的时候，每次resize都会随机调度到某个可用主机节点，但这样做存在一定缺陷。首先，每次resize都是一次冷迁移，即使当前节点的资源足够，也会发生一次冷迁移；这个在使用共享存储的场景不是什么大问题，但是在本地存储的场景，resize vm一定要做一次迁移就不太智能了。其次，有的客户希望可以指定resize vm到用户指定的节点，希望这个功能有更好的灵活性；
基于上述考虑，我们对resize功能进行优化与调整，当执行resize操作的时候，如果当前节点上资源充足，优先在当前节点上完成resize，无需迁移；如果当前节点资源不足，则由调度器调度到其他可用节点。此外，扩展resize接口，使其支持resize云主机至随机节点、指定节点或本地节点等策略，做到可控可配置。
3.3 基于分区部署的调度
随着云计算服务类型的细化，需要针对不同的业务场景提供不同类型的云资源，在同一个数据中心内会包括不同类型的计算节点，比如支持CPU独占、支持GPU虚拟化、支持OVS-DPDK网络加速等等。这些计算节点之间是功能与特性上的差异，华云数据合理优化与利用Nova scheduler中基于分区的调度技术，实现把不同功能与特性的云主机需求开通到该类型的计算节点上。比如当用户创建CPU独占或者GPU类型的VM时，OpenStack会在相应分区类型的计算节点上开通。
总结
本文简单介绍了云调度器Nova scheduler的基本原理与工作流程，同时分享了目前华云数据云平台对其的部分扩展优化。目前OpenStack社区也在孵化类似Watcher等云平台优化项目，这些项目会与调度器结合提供云平台的运行时优化。如何把搭建的云平台更好的运行，使之大化的发挥能效，仍然有许多可挖掘优化的地方。
华云数据对于OpenStack的研究和应用，一直秉承源于社区、优于社区、回馈社区的理念，紧跟社区的步伐，不断改进与优化，将优化的功能代码回馈于社区、将优秀的产品功能交付于客户。
关于华云数据
华云数据集团成立于2010年，是专业从事云计算服务的创新型公司，公司遍布于北京、上海、无锡、深圳、厦门、杭州、南京、临沂等；香港、拉斯维加斯拥有运营中心，在国内拥有超过15个城市的20余个数据中心和上万台物理服务器集群。网络覆盖中国电信、中国联通以及华云数据自有BGP网络，实现从边缘到核心的全覆盖。华云数据在北京、上海、广州、深圳、香港打造高速专线直连的高品质节点提升业务性能，提高用户体验。另外，2个中国电信美洲数据中心和2个香港数据中心还可满足客户对海外业务的需求。
华云数据以为用户提供定制化混合架构为目标，产品覆盖公有云、私有云、混合云及IDC转云等领域，可以为用户提供数十种解决方案，深度满足企业云化需求。
热门专题
