OPENSTACK的可伸缩架构的基础:RPC——超大规模高可用OpenStack核心技术深入解析系列
2016-11-05 14:10
966 查看
作者:石奎 EasyStack高级架构师
编者按:
OpenStack已经在很多大型企业里支撑起核心生产业务,这都源于OpenStack中的核心技术与架构,超大规模高可用OpenStack平台核心技术深入解析系列文章,主要介绍了EasyStack在企业级OpenStack一线实践中的所见所感,将分为消息队列篇,计算篇,存储篇,网络篇等等,每篇中的内容都以基础、高级划分,将OpenStack落地最后一公里实打实所遇到的问题分享给大家。
OpenStack作为分布式云计算平台,包含了众多功能组件,每个组件完成各自的功能,比如大家熟知的计算(Nova)、存储(Cinder)、网络(Neutron)。组件之间通过message进行通讯,message broker在分布式系统中起到核心上传下达的作用,连接着集群中的各个组件,如果将OpenStack比作复杂人体来说,那么消息队列就是人体的神经中枢。根据社区统计的结果,在OpenStack部署方案中,RabbitMQ以稳定可靠而著称,是被采用最多的Message broker。
本文将首先介绍RabbitMQ在RPC(Remote Process Call)方面的功能特性,在后续文章中,我还会对RabbitMQ及AMQP协议,RabbitMQ集群,从运维角度看RabbitMQ,RabbitMQ是如何支撑千台节点OpenStack环境这些方面进行深入讨论。敬请期待。
正文:
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功能,让集群的各个节点的访问负责能够均匀分布。
转载自:http://www.openstack.cn/?p=4556
编者按:
OpenStack已经在很多大型企业里支撑起核心生产业务,这都源于OpenStack中的核心技术与架构,超大规模高可用OpenStack平台核心技术深入解析系列文章,主要介绍了EasyStack在企业级OpenStack一线实践中的所见所感,将分为消息队列篇,计算篇,存储篇,网络篇等等,每篇中的内容都以基础、高级划分,将OpenStack落地最后一公里实打实所遇到的问题分享给大家。
OpenStack作为分布式云计算平台,包含了众多功能组件,每个组件完成各自的功能,比如大家熟知的计算(Nova)、存储(Cinder)、网络(Neutron)。组件之间通过message进行通讯,message broker在分布式系统中起到核心上传下达的作用,连接着集群中的各个组件,如果将OpenStack比作复杂人体来说,那么消息队列就是人体的神经中枢。根据社区统计的结果,在OpenStack部署方案中,RabbitMQ以稳定可靠而著称,是被采用最多的Message broker。
本文将首先介绍RabbitMQ在RPC(Remote Process Call)方面的功能特性,在后续文章中,我还会对RabbitMQ及AMQP协议,RabbitMQ集群,从运维角度看RabbitMQ,RabbitMQ是如何支撑千台节点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功能,让集群的各个节点的访问负责能够均匀分布。
转载自:http://www.openstack.cn/?p=4556
相关文章推荐
- OPENSTACK的可伸缩架构的基础:RPC——超大规模高可用OpenStack核心技术深入解析系列
- 消息队列基础 RabbitMQ与AMQP协议详解——超大规模高可用OpenStack核心技术深入解析系列(二)
- 消息队列基础 RabbitMQ与AMQP协议详解——超大规模高可用OpenStack核心技术深入解析系列(二)
- 深度解析RabbitMQ集群——超大规模高可用OpenStack平台核心技术深入解析系列高级篇(三)
- 深度解析RabbitMQ集群——超大规模高可用OpenStack平台核心技术深入解析系列高级篇(三)
- Spring技术内幕——深入解析Spring架构与设计原理(二)AOP
- 基础架构部_超大规模数据平台架构师(上海)
- 云计算-从基础到应用架构系列-虚拟化的技术(上)
- 【自动化测试技术QTP基础系列四】---深入探讨录制回放原理
- [软件架构师系列教程-3]DotNET架构的核心开发技术
- Spring技术内幕——深入解析Spring架构与设计原理(二)AOP
- WPF基础到企业应用系列7——深入剖析依赖属性(WPF/Silverlight核心)
- 转:Spring技术内幕——深入解析Spring架构与设计原理(三)IOC实现原理
- [C# 基础知识梳理系列]专题一:深入解析委托——C#中为什么要引入委托
- Hadoop技术内幕:深入解析MapReduce架构设计与实现原理
- Spring技术内幕——深入解析Spring架构与设计原理(四)Web MVC的实现
- 《Spring技术内幕——深入解析Spring架构与设计原理》连载4
- 转:Spring技术内幕——深入解析Spring架构与设计原理(二)IOC实现原理
- 强烈推荐Android开发技术系列文,android底层架构,android核心框架
- 【自动化测试技术QTP基础系列三】--深入探讨录制回放原理