每一个 OpenStack 组件可能包含若干子服务,其中一定有一个 API 服务负责接收客户请求。 前端
以 Nova 为例,nova-api 做为 Nova 组件对外的惟一窗口,向客户暴露 Nova 可以提供的功能。 当客户须要执行虚机相关的操做,能且只能向 nova-api 发送 REST 请求。 这里的客户包括终端用户、命令行和 OpenStack 其余组件。 web
设计 API 前端服务的好处在于: 1. 对外提供统一接口,隐藏实现细节 2. API 提供 REST 标准调用服务,便于与第三方系统集成 3. 能够经过运行多个 API 服务实例轻松实现 API 的高可用,好比运行多个 nova-api 进程 数据库
对于某项操做,若是有多个实体都可以完成任务,那么一般会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操做。 api
在前面的例子中,Nova 有多个计算节点。 当须要建立虚机时,nova-scheduler 会根据计算节点当时的资源使用状况选择一个最合适的计算节点来运行虚机。 架构
调度服务就比如是一个开发团队中的项目经理,当接到新的开发任务时,项目经理会评估任务的难度,考察团队成员目前的工做负荷和技能水平,而后将任务分配给最合适的开发人员。 框架
除了 Nova,块服务组件 Cinder 也有 scheduler 子服务,后面咱们会详细讨论。 异步
调度服务只管分配任务,真正执行任务的是 Worker 工做服务。 分布式
在 Nova 中,这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 很是容易扩展: 性能
当计算资源不够了没法建立虚机时,能够增长计算节点(增长 Worker) 学习
当客户的请求量太大调度不过来时,能够增长 Scheduler
OpenStack 做为开放的 Infrastracture as a Service 云操做系统,支持业界各类优秀的技术。 这些技术多是开源免费的,也多是商业收费的。 这种开放的架构使得 OpenStack 可以在技术上保持先进性,具备很强的竞争力,同时又不会形成厂商锁定(Lock-in)。
那 OpenStack 的这种开放性体如今哪里呢? 一个重要的方面就是采用基于 Driver 的框架。
以 Nova 为例,OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。
Nova-compute 为这些 Hypervisor 定义了统一的接口,hypervisor 只须要实现这些接口,就能够 driver 的形式即插即用到 OpenStack 中。 下面是 nova driver 的架构示意图
在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪一种 Hypervisor 的 driver
在咱们的环境中由于是 KVM,因此配置的是 Libvirt 的 driver。
不知你们是否还记得咱们在学习 Glance 时谈到: OpenStack 支持多种 backend 来存放 image。 能够是本地文件系统,Cinder,Ceph,Swift 等。
其实这也是一个 driver 架构。 只要符合 Glance 定义的规范,新的存储方式能够很方便的加入到 backend 支持列表中。
再后面 Cinder 和 Neutron 中咱们还会看到 driver 框架的应用。
在前面建立虚机的流程示意图中,咱们看到 nova-* 子服务之间的调用严重依赖 Messaging。 Messaging 是 nova-* 子服务交互的中枢。
之前没接触过度布式系统的同窗可能会不太理解为何不让 API 直接调用Scheduler,或是让Scheuler 直接调用 Compute,而是非要经过 Messaging 进行中转。 这里作一些解释。
程序之间的调用一般分两种:同步调用和异步调用。
同步调用
API 直接调用 Scheduler 的接口就是同步调用。 其特色是 API 发出请求后须要一直等待,直到 Scheduler 完成对 Compute 的调度,将结果返回给 API 后 API 才可以继续作后面的工做。
异步调用
API 经过 Messaging 间接调用 Scheduler 就是异步调用。 其特色是 API 发出请求后不须要等待,直接返回,继续作后面的工做。 Scheduler 从 Messaging 接收到请求后执行调度操做,完成后将结果也经过 Messaging 发送给 API。
在 OpenStack 这类分布式系统中,一般采用异步调用的方式,其好处是:
解耦各子服务 子服务不须要知道其余服务在哪里运行,只须要发送消息给 Messaging 就能完成调用。
提升性能 异步调用使得调用者无需等待结果返回。这样能够继续执行更多的工做,提升系统总的吞吐量。
提升伸缩性 子服务能够根据须要进行扩展,启动更多的实例处理更多的请求,在提升可用性的同时也提升了整个系统的伸缩性。并且这种变化不会影响到其余子服务,也就是说变化对别人是透明的。
在后面各章节,咱们都能看到 Messaging 的应用。
OpenStack 各组件都须要维护本身的状态信息。 好比 Nova 中有虚机的规格、状态,这些信息都是在数据库中维护的。 每一个 OpenStack 组件在 MySQL 中有本身的数据库。
Nova 是 OpenStack 中最重要的组件,也是很典型的组件。 Nova 充分体现了 OpenStack 的设计思路。 理解了这种思路,再来学习 OpenStack 的其余组件就可以触类旁通,清晰容易不少。
咱们在后面 Cinder 和 Neutron 的学习中还会回顾这些设计思路。