作者：李晓辉

联系方式：

1. 微信：Lxh_Chat

2. 邮箱：939958092@qq.com

集群中各组件共享的那些服务

今天咱们来聊聊OpenStack里的那些事儿，特别是识别控制平面服务和操作。你知道，OpenStack是个超厉害的开源云计算平台，里面藏着好多好玩又实用的服务，这些服务就像是搭建云平台的积木，缺一不可。那我就先给你挨个唠唠这些服务吧。

MariaDB

MariaDB，这可是数据库界的明星啊！在OpenStack里，它主要负责存储各种各样的数据，比如用户的登录信息、虚拟机的配置参数，还有各种资源的分配情况等等。你可以把它想象成一个超大的电子表格，里面密密麻麻地记录着所有重要的信息。要是没有它，OpenStack就相当于失去了记忆，啥都干不成。而且，MariaDB的性能特别棒，读写速度快得很，能轻松应对大量的数据请求，保证整个云平台的运行不会卡顿。

Redis

Redis，这个名字你可能听着有点耳熟，它是一个高性能的键值存储数据库。在OpenStack里，它的作用可不小。它主要用于缓存数据，就像一个临时的仓库，把一些经常需要访问的数据存起来，这样当系统需要这些数据的时候，就能直接从Redis里快速取出来，而不用每次都去数据库里慢慢查找，大大提高了系统的响应速度。比如，当用户频繁地查询某个虚拟机的状态时，Redis就能把状态信息缓存起来，让查询操作瞬间完成，用户体验直接拉满。

Memcached

Memcached和Redis有点像，也是用来缓存数据的。不过，它更侧重于为应用程序提供快速的数据访问。在OpenStack的各个组件之间，数据交互是很频繁的，Memcached就像是一个超级快递员，能够快速地把数据传递给需要的组件。而且，它对内存的利用效率很高，能在有限的内存空间里存储更多的数据，让整个系统运行得更加流畅。有了它，OpenStack的性能就像打了鸡血一样，飞速提升。

Pacemaker

Pacemaker这个名字听起来就很厉害，它在OpenStack里扮演着高可用性守护者的角色。简单来说，它就像一个超级管理员，时刻监控着各个服务的运行状态。要是某个服务突然挂了或者出了问题，Pacemaker就能第一时间发现，并且迅速采取措施，比如把服务切换到备用节点上，或者重新启动服务，确保整个云平台的运行不受影响。有了它，OpenStack就像有了一个坚强的后盾，不管遇到什么风吹雨打，都能稳如泰山。

Ceph MON and MDS

Ceph是一个超强大的分布式存储系统，而Ceph MON（Monitor）和MDS（Metadata Server）是它的两个关键组件。Ceph MON主要负责监控整个存储集群的状态，就像一个指挥官，时刻掌握着集群的健康状况，确保所有的存储节点都能正常工作。而MDS则是负责管理存储元数据的，元数据就好比是存储系统的地图，记录着数据存储的位置、大小等信息。有了Ceph MON和MDS的协同工作，Ceph就能实现高效、可靠的数据存储，为OpenStack提供强大的后端存储支持。

NoVNC and Spice

最后，咱们再聊聊NoVNC和Spice。这两个东西主要是用来实现远程桌面访问的。在OpenStack里，用户可能需要远程登录到虚拟机上进行操作，这时候NoVNC和Spice就派上用场了。NoVNC是一种基于Web的VNC客户端，用户只需要通过浏览器就能轻松连接到虚拟机的桌面，操作起来方便得很。而Spice则提供了更丰富的功能，比如更好的音频、视频支持，以及更流畅的桌面交互体验。有了它们，用户就像坐在虚拟机面前一样，可以随心所欲地操作虚拟机，完全不用担心距离的问题，不过红帽建议使⽤独⽴的 SPICE 客⼾端从专⽤管理⽹络访问 OpenStack 实例。

这些服务在OpenStack里都扮演着重要的角色，它们相互配合，共同支撑起整个云平台的运行。要是你对OpenStack感兴趣，这些服务绝对是你必须要了解的。

用VNC访问实例控制台的流程

每个计算节点运⾏⼀个 vncserver 进程，在内部 API ⽹络上侦听端⼝号为 5900 及以上的⼀个或多个端⼝，具体取决于该计算节点上部署的实例数量。每个控制器节点运⾏⼀个 novncproxy 进程，在同⼀内部 API ⽹络上侦听端⼝ 6080。其余的服务从属于计算服务 (Nova)，其组件位于控制器和计算节点上

我就用咱们平时聊天的轻松口吻，给你讲讲用VNC访问OpenStack实例控制台的流程，保证你听得明明白白，就像听个故事一样。

1. 浏览器发号施令

你打开浏览器，通过NoVNC插件（就是个帮手工具）向nova-api（这是OpenStack的大管家，住在controller节点上，用8774端口）说：“嘿，我想连接到我的虚拟机。” 这时候，OpenStack的Dashboard（就是那个管理界面）通过haproxy（一个超级调度员，住在controller节点上，用80端口）帮忙把请求转发过去。

2. nova-api传话

大管家nova-api收到你的请求后，心想：“好嘞，我得把这事告诉nova-compute（这是在compute节点上干活的，负责管理虚拟机的）。” 它就通过内部的通信管道（AMQP，就像快递系统）把请求发给nova-compute。

3. nova-compute找libvirt帮忙

nova-compute收到消息后，它自己也不清楚虚拟机的具体情况，于是它去找libvirt（这是个专门管理虚拟机的工具，也在compute节点上）：“兄弟，帮我查查这个虚拟机的详细信息。”

4. libvirt生成令牌

libvirt查到了虚拟机的信息，然后说：“好嘞，我生成一个令牌（就像一张通行证）。” 这个令牌就像是虚拟机的身份证，然后它把这个令牌通过nova-compute返回给nova-api。

5. nova-compute传回令牌

nova-compute收到令牌后，把它和一些连接信息（connect_info，就像是虚拟机的地址和联系方式）打包，再通过AMQP发回给nova-api。

6. nova-api找nova-consoleauth授权

nova-api拿到这些信息后，它又去找nova-consoleauth（这是个专门负责授权的，住在compute节点上）：“兄弟，帮我授权一下这个控制台连接。” 它把connect_info和令牌发过去，nova-consoleauth就把这些信息缓存起来，方便以后用。

7. nova-api告诉浏览器

nova-api搞定授权后，它又把nova-novncproxy的地址（nova-novncproxy是个代理工具，住在controller节点上）和一个实例特定的令牌（就像是一把钥匙）发回给你的浏览器。

8. 浏览器通过haproxy连接

你的浏览器拿到这些信息后，通过Dashboard的haproxy（它用6080端口）去连接nova-novncproxy。这个过程就像是浏览器通过一个中间人（haproxy）去敲nova-novncproxy的门。

9. nova-novncproxy解析令牌

nova-novncproxy收到请求后，它从URL里解析出令牌和虚拟机的ID，然后它又去找nova-consoleauth：“兄弟，帮我查查这个令牌对应的连接信息。”

10. nova-consoleauth返回信息

nova-consoleauth从缓存里找到connect_info对象，把它发回给nova-novncproxy。

11. nova-novncproxy连接VNC服务器

nova-novncproxy拿到connect_info后，它就知道该怎么连接到虚拟机的VNC服务器（VNC服务器在compute节点上，用5900+端口）。它直接连过去，并且设置好反向代理（就像是一个中转站）。

12. 图形界面发回浏览器

最后，nova-novncproxy把虚拟机的控制台图形界面通过haproxy发回到你的浏览器上。于是，你就能在浏览器里看到虚拟机的桌面，就像坐在它面前一样，开始愉快地操作啦！

你看，整个过程就像是一场接力赛，各种组件你来我往，互相配合，最后让你顺利连接到虚拟机。