ovirt中vdsmd架构分析

本文是从软件架构设计的角度剖析oVirt的vdsmd(ovirt4.2版本)。

API调用流程之clientIF

在vdsm中API调用框架是由clientIF来两实现的，其中包含个Server，和两个对应的Detector，一个Acceptor，Acceptor接收到的客户端数据，根据协议的不同选择把数据发送到哪个Detector和Server进行处理。

Acceptor监听管理中心的ip和port（默认54321）。

Acceptor中添加了两个detector，Acceptor接收到管理中心的socket数据后（数据包含新的dispatcher的socket），分别使用两个detector去detect数据中协议是哪个detector，从而把数据交给对应detector去处理（handle_socket），然后detector通过handle_socket把dispatcher的socket放到了对应server的监听队列中。

API调用流程之BaseManager

在另一篇文章《一文看懂ovirt的supervdsmd服务》中已经详细讲解。主要实现了vsdmd服务和其他服务对supervdsmd服务的API调用框架。

Profile

启动程序优化和代码跟踪功能，主要包括cpu（yappi线程）和内存（memprofile线程）的profile。

Metrics

启动监控上报功能，实现了两个metrics客户端：hawkular和statsd。

发送metrics信息者：

periodic线程（发送虚拟机状态和主机状态）

health线程（发送vdsmd服务的进程状态）

Scheduler

创建vdsm.Scheduler线程，这个线程的作用是：等待其他线程分配给自己要给callable的任务，并在delay时间之后在本线程中执行此callable。和内核中的scheduler相同原理。

使用方式为：

self._scheduler.schedule(self._period, self._try_to_dispatch)

#在schedule线程中_period时间后执行_try_to_dispatch。

Periodic

周期性任务，其中定义了若干Operation，每个Operation周期性的dispatch。是由Executor模型实现的。

Operation dispatch过程简介：

每个Operation被循环的dispatch到TaskQueue中，并对应Executor模型中TaskQueue的一个task。Operation被dispatch的方式有Exclusive和Non-exclusive模式。Exclusive模式是等当前Operation（task）被执行完毕后才再次被dispatch；Non-exclusive模式是当前Operation（task）被dispatch后接着被dispatch；

Executor模型简介：

Task：执行的一个任务。

TaskQueue：最大长度为max_tasks的task队列，提供put和get功能。

Worker：一个Worker是一个periodic/num线程，它不停的从TaskQueue中取task并执行task。中最多为max_workers

Executor：负责添加task到TaskQueue中（dispatch()）。初始创建workers_count个worker，每个worker每处理一个task都有固定时间限制，worker1如果超出时间限制，立刻创建一个新的worker2，这个worker1在执行完本task后就退出。worker最多有max_workers个，当创建新worker时数目达到max_workers则暂不创建。这样就保证了worker数量会在workers_count和max_workers之间。

Libvirtconnection

主要功能有：创建libvirt/events线程，启动libvirt的event_loop和事件处理功能；还提供一个连接libvirt的接口libvirtconnection.get()供使用。

ChannelListener

ovit-guest-agent的宿主机端实现，启动了一个vmchannels线程，其中实现了一个channelListener，用来和宿主机上所有虚拟机内的ovirt-guest-agent交互。交互的数据回调给guestagent的GuestInfo中。

qga

qemu-guest-agent的宿主机端实现。实现机制和periodic一样，通过定义Opertion来使用Executor模型执行周期性的任务。主要有了下面连个任务：

1.逐个虚拟机进行CapabilityCheck：默认5分钟一次，调用libvirt的默认channel ovirt-guest-agent.0，把本主机上的虚拟机内qemu-guest-agent支持的supported_commands信息更新到_capabilities中。

2._cleanup：默认1小时dispatch一次，负责把_capabilities、_guest_info、_last_failure中已被删除虚拟机的信息去除。

关于qga和vmchannels

首先看虚拟机的配置：

其中：

ovirt-guest-agent.0是vdsm监听的socket，也是与虚拟机内部的ovirt-guest-agent服务通讯的socket。

org.qemu.guest_agent.0是libvirt默认监听的socket，也是与虚拟机内部qemu-guest-agent服务通讯的socket。

guestagent其后端有qemuguestagent和vmchannels两种实现方式。其中qemuguestagent对应虚拟机内部的qemu-guest-agent，vmchannels对应虚拟机内部的ovirt-guest-agent。

qga = self._qgaGuestInfo()
if qga is not None:
    info.update(qga)
if self.isResponsive():
    info.update(self.guestInfo)

qemuguestagent：

由于qemuguestagent中没有实现update_guest_info没有任何地方调用，所以从qemuguestagent中的GuestInfo永远为空，所以只能从vmchannels中读取。

vmchannels：

每个虚拟机开始运行时会向vmchannels线程中注册一个${uuid}.ovirt-guest-agent.0和回调，vmchannels通过这个回调更新GuestInfo中本虚拟机的信息。使用方式为：

self._channelListener.register(
            self._create,
            self._connect,
            self._onChannelRead,
            self._onChannelTimeout)

#_create：创建sock回调

#_connect：连接sock到${uuid}.ovirt-guest-agent.0回调

#_onChannelRead：收到虚拟机内数据后的回调，会把虚拟机数据写入GuestInfo中。

HSM线程池设计

HSM是vdsm中的主机存储管理，HSM内部自己实现了一套线程池框架，用来完成被分配的任务：

Health

启动vdsmd服务的进程信息上报功能，根据health_monitor_enable配置来决定是否启用此功能。对应health线程，周期性的用metrics客户端发送vdsmd进程信息。

vm线程用来管理和本虚拟机相关的所有事务，在另一篇文章中详细讲解。

最后附上一个查看vdsmd服务进程中线程的python脚本：

import os, commands
NAME = 'vdsmd'
procs = ['/proc/'+p for p in os.listdir('/proc') if os.path.isdir('/proc/'+p) and os.path.exists('/proc/'+p+'/comm')]
for proc in procs:
    with open(proc+'/comm', "rb") as f:
        fields = f.readline().split()
    if fields[0] == NAME:
        vdsm_proc = proc
        break
threads = [vdsm_proc+'/task/'+t for t in os.listdir(vdsm_proc+'/task')]
for thread in threads:
    status,result = commands.getstatusoutput('cat %s/comm'%thread)
    print thread + "    " + result

更多精彩内容请扫二维码：