OPENSTACK的可伸缩架构的基础：RPC——超大规模高可用OpenStack核心技术深入解析系列

OPENSTACK的可伸缩架构的基础 RPC

RabbitMQ的功能之一就是实现RPC（Remote Process Call），OpenStack的各个组件就是通过RPC来进行通讯的，通讯内容走OpenStack内部网络中的管理网络。每个组件内部又通过不同的服务来完成不同的工作，比如数据库访问，接受API请求等。

 

如果从RPC的角度进行简化，OpenStack中各组件的服务按角色分为两种：RPC client／RPC server。各个组件模块通过RPC调用，作为RPC client发送message到RabbitMQ，RabbitMQ作为message broker，将消息分发到相应的queue中去，组件中负责接收消息的RPC server接收message，根据message内容执行相应的操作，比如操作数据库，或者执行操作系统的命令等。

 

从外部看OpenStack集群，各个功能组件的API service提供RESTful API访问，用户或者组件都可以使用API获得服务。 从集群内部看，功能组件内部的各种服务通过RPC调用完成各个任务的衔接，最终完成用户提交的一项任务。RabbitMQ作为提供RPC功能的Message broker，通过message连接各个服务，处在OpenStack集群的中心环节。 因此处在中心环节的RabbitMQ对整个OpenStack集群的稳定性和性能起着举足轻重的作用。

 

下面这张图用图示的方式展现了“boot from volume”这样一个用户请求的主要步骤，组件中的各个服务通过rpc.call和rpc.cast访问RabbitMQ。 用户请求的大部分动作都需要椭圆形中的RabbitMQ完成连接。

“boot from volume”用户请求的主要步骤

 

RabbitMQ提供了多种语言的binding，方便用户使用它的服务。对于Python来讲，用来构建／访问RabbitMQ服务使用最多的是pika。

 

目前在OpenStack中，各个组件都已过渡到使用Oslo_messaging进行RPC调用。

 

下面是两张经典的介绍OpenStack中rpc.call和rcp.cast的示意图：

 

OpenStack中的rpc.call

OpenStack中的rcp.cast

 

图中出现的一些概念，这里也给大家做一个简短的说明：

Topic（主题）——发送消息的一个属性，主题中引入了一个叫做Routing Key（路由键)的概念，消息转发器会根据消息主题的路由键将消息路由到对应的消息队列

Exchange（消息转发器）——消息到达消息中间件时的第一站，消息转发器根据话题来负责消息的分配，本身RabbitMQ提供了三种典型的消息分配模式，Direct Exchange，Fanout Exchange，Topic Exchange，他们与网络技术中的单播，广播和组播很相似

Binding（绑定）——消息转发器与消息队列之间的连接

 

Oslo_messaging使用Kombu框架连接RabbitMQ。

 

Kombu是一个AMQP消息队列的架构，Python可以方便的使用它提供的接口收发消息。它采用插件式的结构来支持不同的消息系统，对与AMQP，它支持py-amqplib和librabbitmq两个client来连接message server。

 

根据操作系统中安装的AMQP client的不同，有以下两种调用关系： 

OpenStack -> oslo_messaging -> kombu -> amqp -> socket

OpenStack -> oslo_messaging -> kombu -> librabbitmq -> rabbitmq-c -> socket

 

如果安装了librabbitmq，则Kombu会优先使用。因为它使用C语言编写，效率更高一些，理想情况下访问效率可以达到amqp的两倍。

 

企业中的OpenStack环境通常需要部署多个RabbitMQ节点，在Nova等服务的配置文件中，通常以rabbitmq_hosts定义RabbitMQ集群的多个节点信息。由于使用Puppet／Chef等工具部署的原因，多个RabbitMQ节点的顺序在所有的配置文件中是统一的。AMQP client一般以round-robin的方式去尝试连接这些节点。

在oslo_messaging中，对rabbitmq_hosts中保存的节点信息进行随机排序，OpenStack的各个组件服务访问MQ时将以一个随机排序过的顺序进行，逐个尝试连接。这样带来的好处就是不至于将集群中所有的访问请求都从第一个节点开始，加大第一个节点的负载。当正在连接的节点失效时，在oslo_messaging的配置中同样可以对Kombu的策略kombu_failover_strategy进行控制，可以设定为shuffle或round-robin模式，通常用默认值round-robin来避免失效的节点再次被选中。因此，oslo_messaging中对RabbitMQ多节点排序一定程度上代替了HAProxy的Load Balance功能，让集群的各个节点的访问负责能够均匀分布。