设为首页 收藏本站
云服务器等爆品抢先购,低至4.2元/月
查看: 2503|回复: 0

[经验分享] OpenStack 通用设计思路

[复制链接]

尚未签到

发表于 2017-6-26 07:34:19 | 显示全部楼层 |阅读模式
DSC0000.jpg

API 前端服务
  每个 OpenStack 组件可能包含若干子服务,其中必定有一个 API 服务负责接收客户请求。
  以 Nova 为例,nova-api 作为 Nova 组件对外的唯一窗口,向客户暴露 Nova 能够提供的功能。 当客户需要执行虚机相关的操作,能且只能向 nova-api 发送 REST 请求。 这里的客户包括终端用户、命令行和 OpenStack 其他组件。
  设计 API 前端服务的好处在于: 1. 对外提供统一接口,隐藏实现细节 2. API 提供 REST 标准调用服务,便于与第三方系统集成 3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用,比如运行多个 nova-api 进程
Scheduler 调度服务
  对于某项操作,如果有多个实体都能够完成任务,那么通常会有一个 scheduler 负责从这些实体中挑选出一个最合适的来执行操作。
  在前面的例子中,Nova 有多个计算节点。 当需要创建虚机时,nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。
  调度服务就好比是一个开发团队中的项目经理,当接到新的开发任务时,项目经理会评估任务的难度,考察团队成员目前的工作负荷和技能水平,然后将任务分配给最合适的开发人员。
  除了 Nova,块服务组件 Cinder 也有 scheduler 子服务,后面我们会详细讨论。
Worker 工作服务
  调度服务只管分配任务,真正执行任务的是 Worker 工作服务。
  在 Nova 中,这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展:

  •   当计算资源不够了无法创建虚机时,可以增加计算节点(增加 Worker)
  •   当客户的请求量太大调度不过来时,可以增加 Scheduler
Driver 框架
  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 的架构示意图
DSC0001.jpg

  在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver
DSC0002.jpg

  在我们的环境中因为是 KVM,所以配置的是 Libvirt 的 driver。
  不知大家是否还记得我们在学习 Glance 时谈到: OpenStack 支持多种 backend 来存放 image。 可以是本地文件系统,Cinder,Ceph,Swift 等。
  其实这也是一个 driver 架构。 只要符合 Glance 定义的规范,新的存储方式可以很方便的加入到 backend 支持列表中。
  再后面 Cinder 和 Neutron 中我们还会看到 driver 框架的应用。
Messaging 服务
  在前面创建虚机的流程示意图中,我们看到 nova-* 子服务之间的调用严重依赖 Messaging。 Messaging 是 nova-* 子服务交互的中枢。
DSC0003.jpg

  以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler,或是让Scheuler 直接调用 Compute,而是非要通过 Messaging 进行中转。 这里做一些解释。
  程序之间的调用通常分两种:同步调用和异步调用。
  同步调用
  API 直接调用 Scheduler 的接口就是同步调用。 其特点是 API 发出请求后需要一直等待,直到 Scheduler 完成对 Compute 的调度,将结果返回给 API 后 API 才能够继续做后面的工作。
  异步调用
  API 通过 Messaging 间接调用 Scheduler 就是异步调用。 其特点是 API 发出请求后不需要等待,直接返回,继续做后面的工作。 Scheduler 从 Messaging 接收到请求后执行调度操作,完成后将结果也通过 Messaging 发送给 API。
  在 OpenStack 这类分布式系统中,通常采用异步调用的方式,其好处是:

  •   解耦各子服务 子服务不需要知道其他服务在哪里运行,只需要发送消息给 Messaging 就能完成调用。
  •   提高性能 异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作,提高系统总的吞吐量。
  •   提高伸缩性 子服务可以根据需要进行扩展,启动更多的实例处理更多的请求,在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务,也就是说变化对别人是透明的。
  在后面各章节,我们都能看到 Messaging 的应用。
Database
  OpenStack 各组件都需要维护自己的状态信息。 比如 Nova 中有虚机的规格、状态,这些信息都是在数据库中维护的。 每个 OpenStack 组件在 MySQL 中有自己的数据库。
DSC0004.jpg

小结
  Nova 是 OpenStack 中最重要的组件,也是很典型的组件。 Nova 充分体现了 OpenStack 的设计思路。 理解了这种思路,再来学习 OpenStack 的其他组件就能够举一反三,清晰容易很多。
  我们在后面 Cinder 和 Neutron 的学习中还会回顾这些设计思路。

DSC0005.jpg

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-388128-1-1.html 上篇帖子: How to create a Virtual Machine in SmartOS 下篇帖子: Linux Kernel 4.8分支第4个候选版本发布
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表