OpenStack学习笔记之-Nova组件深入了解

视频了解:

nova组件是用来建虚拟机的(功能:负责响应虚拟机创建请求、调度、销毁云主机)

nova主要组成:

nova-api:负责接收外部的rest api的请求

nova-scheduler:负责调度(相当于nova-api的秘书)

nova-compute:负责具体的去调相关的虚拟化驱动

nova-conductor:帮助nova-computer查看数据库,然后将消息通过message queue传给nova-computer

为什么查看数据库时要借助nova-conductor而不是nova-computer直接查?

1、基于安全考虑:一旦虚拟机被攻破了,就会通过nova-computer拿到虚拟机相关信息

2、基于数据库压力考虑:nova-computer有很多个,可以同时建很多虚拟机出来,多个nova-computer同时访问数据库会对数据库造成压力

书籍了解:

初步认识Nova:

是OpenStack的计算组件,控制着一个个虚拟机的状态变迁与生老病死,管理着它们的资源分配。在OpenStack项目中扮演者最为核心的角色。

现在的Nova只专注于提供统一的计算资源抽象,这些计算资源可以是物理机、虚拟机,甚至是容器。

Nova体系结构:

Nova由多个提供不同功能的组件组成,对外通过REST API通信,对内通过RPC进行通信,使用DB数据库来存储数据

Nova主要由API、 Compute、 Conductor、 Scheduler 4个核心组件所组成,它们之间通过RPC进行通信。

API:是进入Nova的HTTP接口,可以通过部署多个来实现横向扩展。

1、API依据请求是长时任务或者是短时任务,将请求发送给Conductor或者Compute。

2、长时任务请求发送到Conductor

Conductor:负责对其全程跟踪和调度。

1、对于新建虚拟机或者迁移类需要调度的请求,Conductor会向Scheduler请求一台符合要求的计算节点,然后将请求最终发送到合适的计算节点上。

2、除了长时任务还负责代理其他节点的DB访问。(这主要是为了安全问题和实现在线升级功能)

3、最后对于虚拟机操作的请求都会发送到Compute组件

Compute:负责与Hypervisor进行通信,实现虚拟机的生命周期管理。

1、对各个Hypervisor的支持通过 Virt Driver 框架来实现

以创建虚拟机为例,Nova组件内部执行流程:

1、首先用户执行novaclient提供的用于创建虚拟机的命令。

2、API服务监听到novaclient发送的HTTP请求并且API将它转换到AMQP消息

3、通过消息队列(Queue)调用Conductor服务,Conductor服务通过消息队列接收任务后,做一些准备工作(如汇总虚拟机参数等)

4、再通过消息队列告诉Scheduler去选择一个满足虚拟机创建要求的主机

5、Conductor拿到Scheduler提供的目标主机之后,会去要求Compute服务创建虚拟机

6、Compute与Hypervisor进行通信

ps:并不是所有的业务流程都像上面那样,对于一些短时任务,如删除虚拟机,不需要Scheduler服务,API通过消息队列告诉Compute删除指定虚拟机,Compute通过Conductor更新数据库即完成业务流程。

Nova内部详细服务:

1、nova-all:用于启动所有Nova服务的辅助脚本,其中API服务作为WSGI服务器启动

2、nova-api:对外提供的REST API服务,目前提供两种API服务,nova-api-metadata和nova-api-os-compute。nova-api根据配置文件/eyc//nova/nova.conf的enable_apis选项设置启动这两种服务

3、nova-api-metadata:接受虚拟机实例metadata(元数据)相关的请求。目前这部分工作由Neturon完成(只有在多计算节点部署,并且使用nova-network的情况下才使用nova-api-metadata API服务)。

4、nova-api-os-compute:OpenStack API服务。

5、nova-cells:Cell模块允许用户在不影响现有的OpenStack云环境的前提下,增强横向扩展、大规模部署能力。Cell模块启用后,OpenStack云环境中的主机被划分成组(成为Cell)。noval-cells负责各个Cell之间的通信,以及为一个新的虚拟机实例选择合适的Cell(因此每个Cell都需要运行nova-cells服务)

6、nova-cert:管理X509证书。

7、nova-compute:Compute服务

8、nova-conductor:Conductor服务

9、nova-consol:允许用户通过代理访问虚拟机实例的控制台。ps:在G版本中被nova-xvncproxy取代

10、nova-novncproxy: Nova提供了 novncproxy代理支持用户通过vnc访问虚拟机。提供完整的vnc访问功能,涉及几个Nova服务(nova-consoleauth提供认证授权, nova-novncproxy用于支持基于浏览器的vnc客户端,nova-xvpvncproxy用于支持基于Java的vnc客户端。)

11、nova-dhcpbridge:管理 nova-network 的 DHCP bridge

12、nova-manage:提供很多与Nova的维护和管理相关的功能,比如用户创建等。

13、nova-network:提供网络服务,己经被Neutron所取代(现只有在使用Devstack部署 OpenStack时才会使用 nova-network)

14、nova-rootwrap:用于在OpenStack运行过程中以root身份运行某些shell命令。

15、nova-scheduler: Scheduler 服务。

Nova中各个服务之间的通信使用了基于AMQP实现的RPC机制,其中nova-compute、 nova-conductor 和 nova-scheduler 在启动时都会注册一个 RPC Server,而 nova-api 因为Nova内部并没有服务会调用它提供的接口,所以无需注册。

Nova API:

1、Nova API是访问并使用Nova所提供的各种服务的公共接口。是作为客户端和Nova之间的中间层。Nova API把客户端的请求传给Nova,待Nova处理完成请求后再将处理结构返回给客户端。

2、Nova v2 API是Nova诞生就存在的API,一直是用Extension作为扩展API的机制。Extension机制本身也并不符合OpenStack的 发展。随着越来越多的OpenStack部署,不同的OpenStack部署通过Extension机制来扩展或者裁剪API,这导致OpenStack完全失去了互操作性。没有正确地处理错误的机制,这导致有些DB层差异被暴露在RESTful API 当中,同样损害了 OpenStack的互操作性。

3、Nova v2.1 API改进了错误处理方式,覆盖掉了不同DB之间的差异。其中最重要的是它引入了一个新的机制Microversion来扩展Nova API。从此Extension在v2.1API中将彻底被删除,最终OpenStack将拥有一个统一的API来实现互操作性。

4、Microversion是单调递增的,表现为X.Y的形式。X只有在非常重大的改变并影响 了整个API才会变化(实际上这种情况会很少发生),而其他任何API的改变都需要改变Y, 无论是API的请求,返回或是语义改变。只有bug才不需要Microversion的变化

5、任何Nova API的改变都需要提交nova-specs,需要严格的review以防止未预期的改变破坏API的兼容性。

6、系统拥有一个最小版本和最大版本号,只要请求在这个范围之内都会被接受。最小和最大版本号可通过version API来查询。

7、Nova API是基于WSGI实现的。nova/api/openstack/下包含着WSGI基础架构的代码,其 中包含一些Nova WSGI stack中所需要的middleware,以及如何解析请求与分发请求的核心代码。

你可能感兴趣的:(服务器,python,云计算)