openstack常用运维命令_OpenStack系列之二：OpenStack架构

通过这篇文章，想跟大家聊聊对OpenStack整体的浅显理解和OpenStack的一点架构知识。

OpenStack与云计算的关系：

我们都知道，OpenStack与时下大热的云计算有着千丝万缕的联系，那么他们是什么关系呢？

其实“云计算”中所谓的云，可以简单理解为任何可以通过互联网访问的服务。那么根据所提供的服务的类型， 云计算就有三种落地方式：IaaS, PaaS和SaaS。OpenStack以及他一直跟随的榜样AWS都是属于IaaS的范畴。

为什么需要OpenStack：

IaaS要解决的问题就是如何自动管理物理机上创建出来的虚拟机。包括虚拟机的创建，迁移，关闭，虚拟存储的创建和维护，虚拟网络的管理，等等一系列虚拟机需要用到的资源的管理和维护。

在单个主机上，这些都可以手动用命令来实现，但是大规模的数据中心有成千上万台物理机，这时候就需要软件系统来辅助运维人员。这就是OpenStack出现的动机。

OpenStack的定位：

如上所说，OpenStack本质是一套软件系统，用来帮助运维人员handle大规模数据中心中虚拟机以及与虚拟机相关的配套设施的增删改查工作。

OpenStack像是一个服务器和运维人员之间的中间角色。面向运维人员，它提供Horizon图形界面和CLI命令行。面向服务器端，它可以与运行在物理节点上的hypervisor交互，将运维人员的意图自动化实现。与Hypervisor交互最直观的例子就是Nova在创建，删除虚拟机的时候实际是调用的libvirt来实现。我们也可以手动用libvirt来创建虚拟机，所以Nova就体现了一种自动化运维的意思。

OpenStack的组件：

目前OpenStack有7个核心组件，分别是：Nova，neutron，glance，cinder，swift，Keystone，horizon。其中：

• Nova是核心，一切都为虚拟机服务。

• swift，cinder和glance是存储三剑客。glance管理镜像，swift存储镜像。cinder为虚拟机提供硬盘。

• neutron提供网络功能。

• keystone提供安全和认证。

• horizon提供图形化界面。

OpenStack组件的通信：

OpenStack是一个略显庞大的系统，它有很多的组件，每个组件其实又是一组服务的集合。只有组件内部各项服务和各个组件之间互相可以高效通信，才能将OpenStack融合成一个统一的整体。

OpenStack的通信分为组件之间的通信和组件内部的通信。这两种的通信方式是不同的。OpenStack组件之间通过REST API来通信，使用http或者https协议，每个组件暴露给其他组件一个API接口，用来接收其他组件发来的请求。组件内部通过AMQP高级消息队列协议进行通信，常用的AMQP软件是RabbitMQ。

关于AMQP和RabbitMQ的详细信息可以参见我公众号的另外一篇文章：OpenStack周边-1：AMPQ与RabbitMQ。

关于REST API的基本知识可以参见我我公众号的另外一篇文章：OpenStack周边-2：探秘REST API。

7个核心组件间的逻辑关系：

在深入探讨每个组件之前，先让我们来看看七个核心组件是如何分工合作的，理清他们之间的关系，有助于我们更好的理解OpenStack。

首先要明确的是，一切都为虚拟机服务，虚拟机是OpenStack的核心。所以Nova是OpenStack的核心组件。其他组件都是围绕虚拟机的需求而展开的周边功能性组件。

Nova要创建虚拟机，就需要镜像，镜像管理就是glance负责的。glance提供给Nova镜像和查询和检索服务。但是实际的镜像的存储位置是在swift。

虚拟机创建完成以后，要给它分配磁盘，这就需要用到cinder，cinder可以提供块存储服务。

虚拟机还有通信的需求，这就需要用到Neutron的网络服务。

另外为了安全起见，需要keystone服务。

回到最初，要创建虚拟机，最方便的就是用Horizon提供的图形界面来实现。

OpenStack的逻辑图：

说了这么多，终于可以把这张图拿出来给大家看看了。从下面这张图大家应该能对OpenStack的架构有个更直观的理解了。

简单描述一下上图：

Nova创建虚机，然后Neutron，cinder，glance分别为虚机提供自己的资源。

最上面的Horizon可以通过图形化界面使用和管理各个组件。

最下面的Keystone可以为各个组件提供认证和权限管理服务。

OpenStack组件内部工作机制：

通过上面的讲解，我们大概知道了OpenStack作为一个整体，各个组件之间的工作方式了。但是其实，每个组件内部也不是铁板一块，也是分为了多个子服务。比如Nova的内部架构如下：

大家可以看到Nova的内部确实分成了多个子服务。具体每个子服务是干嘛的这里不展开讲，后面会有每个组件的单独分析，在这里只是想跟大家说一下所有组件都通用的几个原则：

1. 对外提供统一API接口：所有组件都有一个统一的对外API接口，这个接口负责向其他组件发送请求或者接受其他组件的请求。

2. 解耦：组件内部各个子服务之间不会互相直接通信，而是通过消息队列协议将自己的消息发到消息队列中去，也就是上图中的queue。然后其他组件从队列中获取该消息。解耦的好处是大大简化了组件内部的架构，同时提高了扩展性。将来如果要增加新的子服务，只需要与消息队列对接即可，不必跟其他所有组件都对接一遍。

3. 数据库：每个组件都会有一个自己的database，存储自己的信息。

OpenStack的分布式系统：

我们在上一篇文章“认识OpenStack”中提到过，OpenStack就相当于云计算的操作系统。但是它和咱们的电脑操作系统不一样，咱们常用的Windows、Linux系统只能作为一个整体装在一台物理机上，但是OpenStack不一样。它是一个分布式的系统，这个分布式可以从两个角度来看：

• 各个组件分布式部署：OpenStack的各个组件可以分别部署在不同的服务器上。

• 组件内部服务分布式部署：OpenStack的单个组件也是由多个子服务组成的，这些子服务也可以分别部署在不同的服务器上。

这种分布式特性让OpenStack具有极大的灵活性，伸缩性和高可用性。同时也使得OpenStack比一般的系统要更加地复杂和难以学习。

OpenStack的部署架构：

这里主要想跟大家说一下部署OpenStack的时候会涉及到的三种节点：控制节点，网络节点，存储节点和计算节点。

控制节点：管理OpenStack，主要部署管理相关的组件或组件中管理相关的子服务。比如Keystone，Glance，Horizon组件和Nova，Neutron中与管理相关的子服务。

网络节点：运行Neutron，为OpenStack提供各种网络相关的服务。但是在我接触的实际项目中极少会单独部署一个网络节点，而是把其功能集成到控制节点上。

存储节点：物理上是存储服务器，装载了大量的硬盘。为虚机分配的volume就是从这些硬盘上划分出来的，网络节点上运行cinder volume服务。

计算节点：虚机所在的服务器，为虚机提供CPU和内存等资源。

这几类节点是按照功能进行的逻辑划分，实际部署时可以根据需求灵活配置。比如可以把所有服务部署在一台服务器上，那这台服务器就一己之力身兼四类节点。

关于OpenStack的架构就跟大家聊这么多，希望能帮助大家从整体上更好的理解OpenStack。接下来我会把OpenStack中关键的组件挑出来跟大家一个个分析。下回见。