openstack查看虚拟机在那个项目_从消息队列看OpenStack

点击上方“腾讯云TStack”关注我们

获取最in云端资讯和海量技术干货

本文作者&＃xff1a;鹏 飞

专注于OpenStack计算、Python。

热爱大海、雪山。

以往介绍openstack的文章通常都是从各个组件的整体角度来进行介绍&＃xff0c;并没有深入的介绍组件内部服务究竟是如何通信的。

本文这次将换一个角度&＃xff0c;从消息队列的角度来看openstack。文章将以pike版本中的nova组件为例进行介绍&＃xff0c;由于openstack中所有组件内部服务的通信方式都是一致的&＃xff0c;因此下面的内容也同样适用于其它组件&＃xff0c;如neutron、cinder等。

Nova整体架构

下面这个图只画出了nova组件中最核心的4个服务&＃xff0c;即nova-api、nova-conductor、nova-scheduler和nova-compute。服务之间通过消息队列&＃xff0c;即图中的mq进行通信(这里的mq几乎默认都是rabbitmq)。其中api、conductor、scheduler服务都可以配置多进程、多副本以实现服务的高可用和高并发&＃xff0c;而compute服务的数量则可能多达上千个。在nova组件的众多功能中&＃xff0c;创建虚拟机功能应该是最能够说明nova组件内部协作的功能了。创建虚拟机时&＃xff0c;nova-api服务接收到来自用户的http请求&＃xff0c;在进行一些必要的处理之后&＃xff0c;通过消息队列将创建流程转交给nova-conductor&＃xff0c;之后nova-api会给用户返回响应&＃xff0c;而不会等待虚拟机创建完成&＃xff0c;虚拟机创建将进入后台运行阶段。nova-conductor服务从消息队列中收到虚拟机创建请求后&＃xff0c;将会进入一个长时间的虚拟机创建流程。首先nova-conductor将会通过消息队列调用nova-scheduler&＃xff0c;为虚拟机选择一个可用的计算节点&＃xff1b;之后又会通过消息队列将创建请求发送给nova-compute服务。nova-compute服务在收到虚拟机创建请求后&＃xff0c;会执行一系列的虚拟机创建操作&＃xff0c;其中还包括更新数据库。但更新数据库并不是由nova-compute自己实现&＃xff0c;而是会通过消息队列将更新数据库操作委托给nova-conductor&＃xff0c;由nova-conductor代理完成。以上就是虚拟机创建流程的一个简要说明&＃xff0c;从创建流程中可以看到&＃xff0c;消息队列对于openstack至关重要。再举一个虚拟机启动的例子&＃xff0c;启动虚拟机时nova-api服务将收到来自用户的http请求&＃xff0c;之后nova-api将会通过消息队列将虚拟机启动请求发送给虚拟机所在的计算节点&＃xff0c;对应计算节点上的nova-compute服务将会收到启动请求&＃xff0c;并将指定的虚拟机启动。但有时候可能会遇到这样的问题&＃xff0c;就是通过nova service-list命令看到某个计算节点上的nova-compute服务明明是up的(这表明计算节点上的nova-compute服务是正常运行的&＃xff0c;同时还能够正常的上报数据到nova数据库中)&＃xff0c;但是执行虚拟机启动操作时却没有任何效果&＃xff0c;观察nova-compute服务日志找不到任何相关的记录&＃xff0c;同时虚拟机卡在启动状态中。对于此类问题&＃xff0c;仅仅通过前面的介绍是无法知道根本原因的&＃xff0c;必须要进入到消息队列层面才能够明白为什么会发生这类问题。

从MQ来看Nova

注: 在openstack中&＃xff0c;默认使用的消息队列是rabbitmq&＃xff0c;因此下面的内容全部基于rabbitmq&＃xff0c;关于rabbitmq的基础知识可以在官方文档&＃xff1a;https://www.rabbitmq.com/getstarted.html中找到。打开rabbitmq management页面&＃xff0c;在Exchanges标签页下面可以看到很多的rabbitmq exchange&＃xff0c;如下图所示(由于篇幅限制&＃xff0c;图中只过滤显示了部分exchange)。其中与openstack相关的exchange主要分为3类:

• 以nova、neutron、openstack等命名的exchange&＃xff1b;
• 以reply开头的exchange&＃xff1b;
• 以fanout结尾的exchange&＃xff1b;

下面会依次说明这3类exchange的作用。另外还有一些以amq开头的exchange&＃xff0c;这些是rabbitmq默认的exchange&＃xff0c;在openstack中不会使用&＃xff0c;因此不用关注。

nova exchange

以组件名称命名的exchange是各个组件内部服务之间通信的核心。下面这个图显示了一个controller节点(控制&＃43;计算融合节点)和一个单独的compute节点组成的openstack环境中nova exchange的具体内容。图中第1部分定义了当前exchange的名称&＃xff0c;不同的openstack项目&＃xff0c;其exchange的名字不同&＃xff0c;但通常和项目的名称一致(cinder默认的exchange名称为openstack&＃xff0c;可以通过cinder.conf进行修改&＃xff1b;但对于nova和neutron这两个项目&＃xff0c;则都是在代码中写死的)。对于nova项目&＃xff0c;可以在nova/config.py中找到默认的exchange名称定义。第2部分指明了nova exchange的type为topic类型(即主题交换机)。rabbitmq支持3种类型的交换机&＃xff0c;分别是direct、fanout和topic&＃xff0c;关于这三种交换机类型可以从rabbitmq的官方文档中找到详细的说明&＃xff0c;在后面的内容中也将简要的说明这几种交换机的特点。第3部分则展示了当前连接到nova exchange上的所有队列。其中To所在列表示当前连接到nova交换机的所有队列名称&＃xff0c;Routing key则指明了nova交换机与指定队列之间的关联关系。当客户端发送消息给nova exchanges时:

• 如果指定了路由关键字为compute.controller&＃xff0c;则消息将被发送到compute.controller队列中&＃xff1b;
• 如果指定了路由关键字为scheduler.controller&＃xff0c;则消息将被发送到scheduler.controller队列中&＃xff1b;

还可以点击图中的队列名称&＃xff0c;进一步查看队列的详细信息&＃xff0c;下图是scheduler.controller队列的部分信息&＃xff0c;其中包括当前在队列中的消息数量&＃xff0c;向队列中添加消息的速率以及消费速率等信息。红框部分则表明了当前连接到队列的消费者&＃xff0c;该消费者来自192.168.60.211节点&＃xff0c;对应40054端口的进程。通过命令ss -pn | grep 40054可以看到该进程实际上就是nova-scheduler服务进程。通过前面观察rabbitmq中的exchange以及队列等信息&＃xff0c;我们可以画出生产者、消息队列、消费者之间的简要关系。图中最左边部分画出了集群中部分nova服务进程&＃xff0c;此处这些nova服务进程的作用是作为生产者向rabbitmq发送消息&＃xff1b;中间灰色线框部分是rabbitmq&＃xff1b;最右边部分也是集群中的nova服务进程&＃xff0c;它们和左边的生产者实际上是相同的进程&＃xff0c;只不过在此处它们作为消费者接收并处理指定队列中的消息。(nova组件中的服务即是生产者&＃xff0c;也是消费者)以上一章节中提到的虚拟机启动为例&＃xff0c;根据这里的消息队列模型再看一下虚拟机的启动流程&＃xff0c;按照上图红色部分从左向右。首先controller节点上的nova-api服务进程收到来自用户的虚拟机启动请求&＃xff1b;nova-api查询到虚拟机位于计算节点compute上&＃xff0c;因此构造rpc请求消息&＃xff0c;将消息发送给nova exchange&＃xff0c;并指定routing key为compute.compute&＃xff1b;消息将根据路由键被发送到compute.compute队列中&＃xff1b;最终绑定并消费该队列的nova-compute服务(计算节点compute上的进程)将获取到消息&＃xff0c;并调用相应的函数执行虚拟机开机操作。相关的rpc调用代码可以在nova/compute/rpcapi.py中找到

# 1. nova-compute服务默认的rpc topicRPC_TOPIC &＃61; "compute"&＃64;profiler.trace_cls("rpc")class ComputeAPI(object): def __init__(self): super(ComputeAPI, self).__init__() # 2. 所有nova-compute服务都默认将消息发送到compute topic target &＃61; messaging.Target(topic&＃61;RPC_TOPIC, version&＃61;&＃39;4.0&＃39;) #... # 3. 启动虚拟机涉及的rpc调用方法 def start_instance(self, ctxt, instance): version &＃61; &＃39;4.0&＃39; # 4. _compute_host(None, instance)将会返回虚拟机所在计算节点主机名&＃xff0c;因此最终消息将会发送 # 给compute.队列&＃xff0c;如果不指定server参数&＃xff0c;则消息将被发送给compute队列 cctxt &＃61; self.router.client(ctxt).prepare( server&＃61;_compute_host(None, instance), version&＃61;version) # 5. 此处cast表明是异步rpc调用&＃xff0c;即只是将消息发送给nova-compute服务&＃xff0c;不等待计算节点执行完成 cctxt.cast(ctxt, &＃39;start_instance&＃39;, instance&＃61;instance)

replay exchange

在前面虚拟机启动相关的rpc调用函数中提到cctxt.cast方法是用于异步rpc调用的&＃xff0c;即不会等待被调用方执行完成。在openstack中&＃xff0c;还有另外一种rpc调用&＃xff0c;即同步rpc调用&＃xff0c;对应的方法为cctxt.call&＃xff0c;该方法被执行后&＃xff0c;将会等待被调用方执行完成。下面的代码同样来自nova/compute/rpcapi.py文件&＃xff0c;该方法用于获取计算节点的运行时间。

# 获取计算节点的运行时间def get_host_uptime(self, ctxt, host): version &＃61; &＃39;4.0&＃39; # 通过server参数&＃xff0c;指定将rpc调用请求发送给哪个队列&＃xff0c;相应的计算节点将会收到消息并处理 cctxt &＃61; self.router.client(ctxt).prepare( server&＃61;host, version&＃61;version) # 同步rpc调用&＃96;cctxt.call&＃96;会等待被调用方执行完成并返回结果 return cctxt.call(ctxt, &＃39;get_host_uptime&＃39;)将查询主机运行时间的rpc消息发送给指定的计算节点&＃xff0c;这一过程与前面一节是完全一样的。不同点在于同步rpc调用与异步rpc调用&＃xff0c;同步rpc调用由于需要获取远端方法的执行结果&＃xff0c;因此需要有一种方法能够将远端方法的执行结果返回给调用者。关于这一过程的实现原理可以参考rabbitmq官方文档: https://www.rabbitmq.com/tutorials/tutorial-six-python.html用通俗易懂的方式来说就是&＃xff0c;同步rpc调用时&＃xff0c;客户端在发送给服务端的请求中&＃xff0c;还会附加一个队列的名字&＃xff0c;该队列用于告诉服务端&＃xff0c;在方法执行完成后将执行结果发送到我给你的队列里面。而客户端在发送了rpc调用请求后&＃xff0c;则会一直监听用于返回结果的队列&＃xff0c;直到有结果返回或者响应超时。(在返回结果时&＃xff0c;原来的服务端变成了消息的生产者&＃xff0c;客户端变成了消息的消费者。)在这里提到的用于返回函数执行结果的队列&＃xff0c;就是那些以reply开头的队列&＃xff0c;后面跟着一个随机生成的uuid。这些队列不是绑定到nova exchange上的&＃xff0c;而是为这些reply队列创建了同名的exchange&＃xff0c;这些exchange的类型为direct类型。并且在服务第一次调用call方法时会生成该队列&＃xff0c;之后在服务重启之前会一直使用该队列作为reply队列。至此&＃xff0c;同步rpc调用的简要流程可以通过下面这个图简要的表示出来

fanout exchange

以fanout结尾的exchange的作用是对所有相关的服务进行广播&＃xff0c;以nova-scheduler服务为例&＃xff0c;当有多个nova-scheduler服务进程时&＃xff0c;每个nova-scheduler进程都会生成一个队列并绑定到scheduler_fanout exchange上。在通过这个scheduler_fanout进行消息广播时&＃xff0c;所有的nova-scheduler进程都将接收到消息。下图是在一个控制节点上启动了3个nova-scheduler进程时&＃xff0c;与scheduler_fanout exchange绑定的队列使用广播给服务发送消息的方式&＃xff0c;在nova中主要用于通知nova-scheduler服务更新缓存信息&＃xff0c;比如通知所有的nova-scheduler服务进程更新主机可用域信息。在用户调用nova-api接口修改主机所在可用域的时候&＃xff0c;nova-api服务就会通过广播的方式将计算节点的可用域信息广播给所有的nova-scheduler服务进程&＃xff0c;使得nova-scheduler服务能够及时的更新内存中缓存的可用域信息&＃xff0c;以便于正确的完成虚拟机调度。下面的代码来自nova/scheduler/rpcapi.py文件&＃xff0c;其作用就是通过广播的方式通知所有nova-scheduler服务进程完成内存数据的更新

def update_aggregates(self, ctxt, aggregates): # 通过fanout参数指定操作为广播操作 cctxt &＃61; self.client.prepare(fanout&＃61;True, version&＃61;&＃39;4.1&＃39;) cctxt.cast(ctxt, &＃39;update_aggregates&＃39;, aggregates&＃61;aggregates)这里同样使用一个图来简要的表示一下fanout exchange与nova服务之间的关系。下面这个图展示了在有两个控制节点&＃xff0c;且每个控制节点上都有两个nova-scheduler进程时的scheduer_fanout exchange及其绑定的队列信息。从图中可以看到&＃xff0c;每个nova-scheduler服务都会有一个队列连接到scheduler_fanout exchange上。因此nova-api在进行广播消息时&＃xff0c;每个scheduler_fanout_队列里面都将收到消息&＃xff0c;所有的nova-scheduler服务进程都能够处理消息。

Nova高可用

nova组件的高可用分为两种&＃xff0c;一种是以暴露端口对外提供http调用的服务&＃xff0c;比较典型的是nova-api服务&＃xff0c;另外还有像placement服务和nova-novncproxy服务&＃xff1b;第二种就是像nova-scheduler、nova-conductor这样的服务&＃xff0c;这些服务是通过消息队列来接收和处理请求的。对于nova-api这样通过http对外提供接口的服务&＃xff0c;高可用可以借助keepalived&＃43;haproxy这样的组合来完成服务的高可用和横向扩展。但本文的主要目的是从MQ来看openstack&＃xff0c;因此nova-api这样的服务的高可用并不是本文的重点&＃xff0c;这里想要介绍的是nova-scheduler、nova-conductor这些服务的高可用和横向扩展是如何实现的。下面将以nova-scheduler服务为例进行介绍。nova-scheduler服务是用于虚拟机调度的组件&＃xff0c;如果仅在一台主机上进行部署&＃xff0c;则很容易出现单点故障。在实际的部署中&＃xff0c;通常会将其部署在3台不同的物理主机上&＃xff0c;以实现服务的高可用&＃xff0c;同时还能提高虚拟机调度的并发性能(python进程cpu使用率不能超过100%&＃xff0c;对于以计算为主的nova-scheduler服务&＃xff0c;会严重限制其并发处理性能&＃xff0c;必须通过多进程的方式实现高并发)。在前面介绍nova exchange时提到有一个scheduler队列&＃xff0c;该队列会被所有的nova-scheduler服务进程消费&＃xff0c;如下图所示controller01~03节点上的nova-scheduler服务进程都会消费scheduler队列&＃xff0c;当有消息被发送到scheduler队列中时&＃xff0c;将会由一个进程获取到该消息并进行处理。当controller02节点上的nova-scheduler服务发送异常时&＃xff0c;消息将会由controller01或controller03节点上的nova-scheduler服务消费。这就是nova-scheduler服务的高可用实现&＃xff0c;同时由于有3个nova-scheduler进程在同时消费scheduler队列中的数据&＃xff0c;因此消息的处理速度也得到了很大的提升&＃xff0c;从而提升了虚拟机调度的并发性能。下面的代码来自nova/scheduler/rpcapi.py&＃xff0c;其功能就是通过rpc同步调用nova-scheduler完成虚拟机的调度

# 1. 通过rpc同步调用nova-scheduler完成虚拟机调度&＃xff0c;通常由nova-conductor服务发起调用def select_destinations(self, ctxt, spec_obj, instance_uuids): version &＃61; &＃39;4.4&＃39; #... # 2. 注意这里prepare方法没有指定server参数&＃xff0c;因此消息将被发送给scheduler队列。 # 如果指定了server&＃61;controller01&＃xff0c;则消息将被发送给scheduler.controller01队列&＃xff0c;此时 # 虚拟机调度请求消息将只能被controller01节点上的nova-scheduler服务进程获取并处理。 cctxt &＃61; self.client.prepare(version&＃61;version) # 3. rpc同步调用&＃xff0c;等待虚拟机调度结果 return cctxt.call(ctxt, &＃39;select_destinations&＃39;, **msg_args)

Nova健康检查

最后介绍一下如何去判断nova服务是否在正常运行。同nova高可用部分一样&＃xff0c;这里对nova的健康检查也分为两种情况&＃xff0c;一种是提供http接口的服务&＃xff0c;这类服务可以简单地通过curl等命令进行服务状态检查&＃xff0c;比如通过curl命令访问8774端口&＃xff0c;然后检查一下返回的状态码即可知道nova-api服务是否正常运行&＃xff1b;另外一种就是nova-scheduler、nova-conductor这样的内部服务。对于通过消息队列才能访问到的nova-schduler等服务来说&＃xff0c;是没有办法通过curl命令检查其健康状态的。要检查这些服务的健康状态&＃xff0c;需要发送rpc同步调用请求&＃xff0c;如果目的节点上的指定服务能够正常响应&＃xff0c;则说明对应节点上的nova服务运行正常。下面以检测计算节点compute01上的nova-compute服务为例进行说明。根据nova exchange部分的说明可以知道&＃xff0c;compute01节点上的nova-compute服务将会消费两个队列&＃xff0c;一个是compute队列&＃xff0c;另外一个是compute.compute01队列。由于compute队列会被所有的nova-compute服务消费&＃xff0c;所以如果将消息发送给compute队列(即prepare方法不指定server参数)&＃xff0c;则消息可能被任意一个nova-compute服务进程消费&＃xff0c;即使要检测的nova-compute服务已经无法正常功能&＃xff0c;检测仍然会成功。因此在发送消息时&＃xff0c;必须指定server参数为目的计算节点compute01&＃xff0c;此时消息将被发送到compute.compute01队列中&＃xff0c;同时该队列仅被compute01节点上的nova-compute服务消费&＃xff0c;如果此时该服务异常&＃xff0c;则消息将不会被消费&＃xff0c;直到客户端等待响应超时&＃xff0c;就可以知道compute01节点上的nova-compute服务出现了异常。

参考资料

1、https://www.rabbitmq.com/getstarted.html2、https://opendev.org/openstack/openstack-helm/src/branch/master/nova/templates/bin/_health-probe.py.tpl

往期精彩内容回顾

1	S3请求来了&＃xff0c;该怎么处理&＃xff1f;
2	初探Docker的网络模式
3	OpenStack Policy鉴权大解密&＃xff01;

听说长得好看的人都点了赞和在看&＃xff01;