OpenStack核心导读

心已赠人 2022-05-27 06:16 226阅读 0赞

OpenStack的核心：

![20180412225559800][]

核心是计算、网络和存储，一切都是围绕着虚拟机为主体而展开的。

OpenStack的模块：

Nova：管理VM的生命周期，是OpenStack的最核心服务。

Neutron：负责创建L2、L3网络，为VM提供虚拟网络和物理网络连接，是OpenStack最难的部分。

Glance：管理VM启动镜像，会被Nova调用。

Cinder：为VM提供存储服务，为VM提供Volume。

Swift：提供对象存储服务，与Cinder看似功能上有重叠。

Keystone：为OpenStack的各种服务提供认证和权限管理。

Ceilometer：为OpenStack提供监控和计量服务，为报警、统计或计费提供数据。

Horizon：以上组件大部分都是API调用的，Horizon为OpenStack用户提供了一个Web的自服务Portal，是OpenStack的控制台。

OK，做过Java开发了解Spring Framework微服务的话对后面学习OpenStack有很大的帮助，因为从架构设计上有相同的思想。组件是单独部署并互相配合的，每个逻辑组件被称为一个node，就像乐高积木一样需要什么拼装什么，重要的组件还需要考虑高可用性。

每个OpenStack的组件在数据库中都维护有自己的数据：

![20180412225629409][]

OpenStack的操作分为Web UI和命令行CLI两种方式。Web UI就是Horizon，命令是调用原始服务的API。

Web UI的优点是可视化操作

CLI的优点是：功能更全、可以写入脚本。

命令的一般格式“模块名服务名参数”

模块名就是以上Nova、Glance等名称；

服务名就是对管理对象的增删改查操作，一般分为delete、list、show、create和update；

参数是非必需的，一般需要输入操作对象的内部ID。

例如镜像管理模块Glance服务API有：

glance image-create

glance image-delete

glance image-update

glance image-list

glance image-show

Keystone-------------------------------------------------------------------------------------------------------------------

Keystone：

![20180412225702353][]

User：使用OpenStack的用户，这个好理解。

Credentials：对于用户的认证方式，比较多样，有username/password方式、token方式、API key以及其他方式。

Authentication：User拿着他所有的Credentials到底能不能访问OpenStack，需要经过Authentication的认证。

Project：整个OpenStack资源是被隔离成不通过的Project的，User必须挂载到Project上才有意义。User和Project之间是多对多的。

Role：与Linux中的Role一样，给每个用户分配1个或多个role，决定了用户具备什么权限。

Token：与大多数http服务一样，token是用户认证通过后获取的一种带有有效时长的访问凭证，作用是为了代替用户密码等敏感信息在网络上的传播。

Service：OpenStack的各种核心组件（Nova、Cinder、Swift、Glance、Neutron等）

EndPoint：Service以对外开放API的方式被外界调用，这些开放的API就被称为EndPoint。

以上User、Credentials、Authentication可以理解为普通的软件开发的鉴权系统，Role和Project属于分权分域的范畴，Token是网络安全的范畴，Service和EndPoint是被保护的访问对象，可以理解为Permission，每个Service中会配置EndPoint与Role的映射关系。

PS：有个配置文件需要注意，每个Service中有个/etc/\{ServiceName\}/policy.json，这个里面用Json的方式配置了EndPoint与Role的映射

Keystone-------------------------------------------------------------------------------------------------------------------

Glance-------------------------------------------------------------------------------------------------------------------

Glance：对镜像的管理，管理对象是Images。

还好我对Docker比较熟悉，所以这里镜像的概念并不陌生，与Docker中的镜像是同一个作用。

服务包括：

1 对实例进行Snapshot生成镜像image

2 对image提供存储服务

3 RestFul方式提供Images相关操作的API

Glance的底层拆分为Registry和Backend，其中Registry配合数据库管理Images的元数据，Backend真正存储Images内容（在/etc/glance/glance-api.conf中配置）。

Glance的故障分析去看/opt/stack/logs/里的日志吧

Glance-------------------------------------------------------------------------------------------------------------------

Nova -------------------------------------------------------------------------------------------------------------------

Nova：对虚拟机生命周期的管理，属于OpenStack架构的核心部分，其它很多组建都要配合它来工作。

Nova内部提供的能力：

1 Nova-API，提供Nova服务的接口

2 Compute Core，Nova调度Hypervisor实现虚拟机的管理，更新数据库中虚拟机的生命周期状态。

3 MQ，Nova与子服务之间通过MQ通信，实现解耦。

Nova的部署分为2类节点：计算节点和控制节点。计算节点上安装了Hypervisor，上面运行虚拟机；控制节点与Hypervisor无关，纯管理。

计算节点上：

nova-compute

控制节点上：

nova-novncproxy

nova-cert

nova-conductor

nova-api

nova-scheduler

nova-consoleaut

mysql

rabbitMq

当然计算节点和控制节点的划分是属于逻辑层的，你也可以使用All-In-One的方式都安装到一台物理机。

来看一下一次创建虚拟机的请求Nova调动了哪些资源，图中两种颜色分辨代表了控制节点和计算节点：

![20180412225740351][]

1，API收到客户的请求，并把请求发送到MQ

2和3，Schedule从MQ中获取到任务，根据算法计算出将在哪个计算节点上创建虚拟机，并把消息发送到MQ

4，计算节点收到来自MQ的创建虚拟机的任务，在本地的Hypervisor上进行处理

5和6，如果计算节点需要与数据库交互，通过MQ与Conductor进行消息通信

OpenStack对Computer上Hypervisor进行了约束，定义了统一的一套接口标准，被称为Driver。只要符合Driver标准的Hypervisor都可以作为Computer接入到OpenStack中来，例如KVM、VMWare等，Computer只需要配置/etc/nova/nova.conf中的computer\_driver来定义好使用哪种实现就好了。Computer除了接收创建虚拟机名另外，还有个功能是定时向OpenStack上报自己的状态。

PS：不只Nova使用了Driver机制，OpenStack其它组件也有使用Driver机制。

Nova中有个Flavor模板的概念，不可能每次来申请虚拟机都要客户提供详细的CPU、内存、磁盘这些参数，Nova会提前定义好几种“尺寸”的虚拟机参数模板供客户选择，客户根据自己的应用场景只需要提供选中的类型就可好了。

例如：

![20180412225812233][]

Nova Scheduler工作原理分两部分：过滤和权重

过滤相对比较复杂，有很多个过滤器供我们配置，按照配置顺序对Computer做一轮轮的筛选，筛选的主要依据就是Flavor和Computer上报来的状态；权重就相对简单了，对过滤后的Computer进行打分，价高者得。

详细内容：[https://docs.openstack.org/nova/latest/user/filter-scheduler.html][https_docs.openstack.org_nova_latest_user_filter-scheduler.html]

Computer上创建VM的过程：

1 为 instance 准备资源

2 创建 instance 的镜像文件，需要借助Glunce

3 创建 instance 的 XML 定义文件

4 创建虚拟网络并启动虚拟机，需要借助Neutron

Nova有2个操作很容易混淆挂起(Suspend)和暂停(Pause)。

这俩都有暂停的意思，并保存instance的当前状态，可以在以后恢复回来。

区别：

1 Pause保存状态到内存，Suspend保存状态到磁盘，所以Pause比Suspend快，Suspend比Pause安全。

2 Suspend之后Instance状态是ShutDown；Pause后状态是Paused

3 Suspend之后需要用Resume来恢复，Pause之后需要用UnPause来恢复

从暂停这个角度来说，还有个操作叫Shelve，“强度”从低级到高级分别是Pause、Suspend、Shelve。Suspend后虚拟机只是挂起，资源扔占用；Shelve干的更绝，就是把当前虚拟机做好备份上传镜像，然后把Instance铲掉。如果要恢复需要UnShelve操作，相当于利用备份镜像重新创建了Instance。

看下Nova支持的操作和场景：

![20180412225843360][]

常规操作里都比较好理解，Lock/Unlock是为了防止Instance被误操作对稳定的Instance加锁；Snapshot是给Instance做镜像备份。Reboot分为soft和hard两种，soft reboot只重启操作系统，instance依然处于运行状态；而hard reboot是重启instance，相当于关机之后再开机。Shut Off与Terminate要区分开，Shut Off只是关闭Instance，而Terminate是铲掉Instance。

计划内故障处理Migrate和Live Migrate都是对Instance做迁移，只不过前者是冷迁移需要停服务，后者是热迁移在线运行，当然后者对目的资源的匹配度要求更高。

计划外故障处理Rescue/Unrescue用指定的启动盘启动修复受损的Instance。

最坏的局面是Computer节点挂了，这是就要用到Evacuate来恢复了，前提是Instance的镜像文件必须存放在共享存储上。

总结下：学习Nova是学习好OpenStack的基础，首先是因为Nova几乎调动了所有OpenStack的模块为其服务，可以初步了解各模块的作用和如何相互协作；其次Nova的Controller/Worker节点模式同样适用于其它模块，掌握好Nova有助于更快的接受其它模块的学习。

Nova-------------------------------------------------------------------------------------------------------------------

Cinder-------------------------------------------------------------------------------------------------------------------

Cinder是OpenStack中负责管理存储的，其中存储分为两种方式：第一种：直接挂接裸盘然后分区、格式化、创建文件系统，第二种：通过NFS、CIFS等协议直接挂载文件系统。

第一种方式：

![20180412225917857][]

第二种方式：

![20180412225950063][]

Cinder的架构分为：cinder-api、cinder-scheduler、MQ、Database、cinder-volume、volume provider。

其中cinder-api、cinder-scheduler、MQ、Database与Nova中的地位是一样的，也是部署到Controller节点上，这里不再细说。Cinder-volume相当于Nova中的Computer，是真正进行存储管理和协调工作的组件，单独部署在一个节点。volume provider相当于Nova中的Hypervisor，真正提供存储设备的组件，也是通过Driver的方式与cindervolume交互，也单独部署，形成池的概念。

PS：Cinder-Scheduler的策略与Nova-Scheduler一样也分为Filter和权重，Cinder-Volume也是要负责把Volume状态信息上报上来为Scheduler提供参考数据。

Attach/Detach一对相反的操作，将池中的Volume挂载/卸载到某个Instance中，因为要与Instance交互，所以这里面需要与Nova打交道。

Extend：扩容，这个扩容是直接在Volume上扩容的，而不是mount上一块新的Volume的方式扩容，使用起来非常方便。不需要与Nova交互。

Delete：删除游离的Volume，如果已经挂载给Instance需要先Detach。不需要与Nova交互。

Snapshot & Backup：前者为Volume做快照，后者为Backup做备份，虽然功能有重复的点，但是侧重的方向不一样。Snapshot要的效果是快速回复，数据镜像；Backup要的效果是容灾，独立备份。我们来举个例子吧，假如我有个产品安装了好多组件终于成功上线了，那么我们会做一次Backup，万一硬件出了问题我可以找别的机器来恢复回来。这个程序有一天晚上我要做软件升级，但是我又怕升级后第二天会影响生产，那么我们会做一次Snapshot，一旦表现不好我们可以迅速回退版本。

Backup –incremental：提供了增量备份的功能，减少备份的消耗。

Restore：Backup的逆操作，Volume恢复。

Cinder-------------------------------------------------------------------------------------------------------------------

Neutron-------------------------------------------------------------------------------------------------------------------

SDN：Software Defined Networking，软件定义网络，是云时代网络管理的主流

Neutron的设计目标是Naas（Networking asa Service）网络即服务，遵循SDN实现网络虚拟化的原则，充分利用了Linux系统上的各种网络相关技术。Neutron承担的功能主要有：L2交换、L3路由、负载均衡、防火墙等。

在《[虚拟化与云平台][Link 1]》中已经介绍过L2与L3的区别，VLan是L2广播域，同一VLan中的Instance可以通信，不同VLan若想通信需要经过L3路由。

Neutron管理的主体是Network，Network又被拆分为多个SubNetwork，最终Instance上的虚拟网卡绑定在SubNetwork的端口上。

Neutron的架构模式与前面介绍的Nova、Cinder略有差别，但是设计思想基本一致。Neutron-API相当于Nova-API的地位，负责开放接口服务；Nuetron-Plugin负责将API请求拆分为具体的业务，然后调用Agent；（Neutron对API和Plugin这两部分做了集成，API+Plugin=Neutron Server）Agent相当于Nova-Computer，是真正负责在Network Provider上实现各种网络功能的部分；Network Provider相当于Nova中的Hypervisor和Cinder中的volume provider，提供网络服务的虚拟或物理网络设备。上面这些模块间交互也要通过MQ和Mysql。

其中Plugin分为2大类：Core Plugin和Service Plugin。Core Plugin负责划分Network、SubNetwork、Port这些主体资源；Service Plugin负责提供Route、Firewall、Load Balance这些上层服务。整个Neutron也是围绕着这两大类服务的。

![20180412230026090][]

Neutron Server中最核心的部分是ML2，在早期的Neutron版本中只支持一种Plugin，而且客户在自定义Plugin时需要开发大量重复代码，后来Neutron引入了ML2对Plugin做了一层抽象，既可以同时支持多种Plugin也可以省去了Plugin开发中大量的重复代码。

ML2中的抽象主要有两部分：Type Driver和MechanismDriver，其中Type Driver功能相对单一，确保网络状态维护到数据库中；Mechanism Driver比较复杂，是真正的调度者。

配置稍微麻烦点，需要配置两道：

第一道/etc/neutron/neutron.conf中先指定使用ML2

![20180412230056133][]

第二道/etc/neutron/plugins/ml2/ml2\_conf.ini中指定ML2使用的哪个dirver

![20180412230128184][]

这里使用的是Linux-Bridge

将Neutron架构展开后的全局图：

![20180412230209672][]

1 Neutron 通过 plugin 和 agent 提供的网络服务。

2 plugin 位于 Neutron server，包括 coreplugin 和 service plugin。

3 agent 位于各个节点，负责实现网络服务。

4 core plugin 提供 L2 功能，ML2 是推荐的 plugin。

5 使用最广泛的 L2 agent 是 linuxbridage 和 open vswitch。

6 service plugin 和 agent 提供扩展功能，包括dhcp, routing, load balance, firewall, vpn 等。

网络拓扑：

![20180412230243153][]

左边的是控制\+计算节点，右边的是纯计算节点，控制节点可能要与外部网络做交互，所以eth2网卡需要打通网络；两个节点间eth0是管理通信用的网卡；eth1是Instance用的网卡。分割线上面部分是网络管理员配置的部分，分割线以下是Neutron配置的部分。

大的实现方式上分为Linux Bridge和Open vSwitch，我们先来看Linux Bridge：

Local Network：VM不与宿主机的任何网卡连接

![20180412230322928][]

VM0和VM1通过tap0和tap1连接到同一个bridge，它们可以互相通信；VM2通过tap2连接到另一个bridge，它不能与别人通信

由于VM0、VM1、VM2不予宿主机任何网卡连接，所以它们只能限定在互相访问和与宿主机的访问，不能访问宿主机以外的网络。

Flat Network：

![20180412230402452][]

宿主机的网卡直接与Linux Bridge连接，每个Bridge独占一个网卡。由于网卡资源也属于稀缺资源，所以一般不会按照Flat去配置网络。

VLAN：最广泛使用的模式

![20180412230442947][]

示例图中是2个VLAN：VLAN-100和VLAN-101，都与网卡eth1绑定连接外网，而且分别绑定了2个Linux Bridge，所以VM0与VM1之间是相通的，与VM2是不通的。这些VM都可以通过eth1与外网通信，通信过程中需要分别打上VLAN-100和VLAN-101的vlan tag。需要注意的是与eth1对接的交换机要用Trunk口，不能用Access口。

那么如何让VM2与VM0和VM1通信呢？由于VLAN天然的L2隔离性，所以单靠二层VLAN是不行的，需要借助三层路由转发。

Routing：解决的就是VLAN间相互访问的问题

![20180412230525333][]

Routing并不是与前面VLAN、Locak、Falt等平行的一种模式，它是单独的一个组件，为了让VLAN间可以相互访问。如上图假如VM1的IP为172.18.100.2,VM2的IP是172.18.101.2，VM1要访问VM2经过路径是：

172.18.100.2的默认网关是172.18.100.1，发送带有vlan100-tag的数据包到路由；路由发现目的地址172.18.101.2与172.18.101.1是同一个vlan的，则从vlan101发送出去；数据包在VLAN100网络中顺利的到达了VM2.

External Network：

上面Routing虽然解决了OpenStack内部Instance跨VLAN访问的问题，但是Instance还不能访问外网，需要配置External Network。上图的eth2是与外网连接的网卡，我们需要基于eth2配置一个External Network，然后把Routing与External Network相连，这样VLAN里的Instance就可以访问外网了。

![20180412230601528][]

这时router会有3个IP：172.16.100.1、172.16.101.1、10.10.10.2. 数据包从router连接外网接口发送数据的时候，会做一次**Source NAT**，即将包的源地址修改为router的接口地址10.10.10.2，这样才能保证回向的包可以发回给router，然后router再转发回源端的Instance。

但次网络只能保证Instance到外网单向访问，外网是无法直接访问到Instance内部的，因为不知道Instance的IP地址。

Floating IP 浮动IP：提供静态NAT功能，建立外网IP与instance租户网络IP一对一映射

上图如果我们想让VM1可以直接被外网访问，需要在router外网interface上添加一个外网IP：10.10.10.3，然后将这个IP与VM1的IP：172.168.100.3绑定，后续外网请求到10.10.10.3上的数据包会被router转发到172.168.100.3上，也就是VM1中。

VXLAN：比VLAN更强大的二层服务

优点在于：VLAN-ID支持4094个，VXLAN-ID支持16777216个；更好的利用已有网络路径；避免物理交换机MAC耗尽。

其配置和使用方式与VLAN差异不大。

Security Group 安全组：

安全组是独立的一个配置为Instance提供安全保障，对于Instance来说安全组并不是必须的配置，但是一旦与某安全组做了关联就要遵守该Security Group的规则。例如每个Project都提供有一个default的安全组，数据流量只许出不许入，一旦Instance关联了这个安全组那么数据流向将变成单向的。

PS：一个Instance可以使用多个安全组，效果叠加。安全组只规定能干什么，不能规定禁止什么。

Firewall 防火墙：

防火墙是更大粒度的保护机制，安全组保护的是Instance，作用于Intance的虚拟网卡；防火墙保护的是Subnet，作用于虚拟路由。它们底层都是通过iptables来实现的。

Load Balancer：

对于软件开发工程师，特别是集群部署的产品，Load Balancer不算什么新鲜内容，Neutron默认使用的是HAProxy。

Neutron里的转发策略有轮迅、最小复杂、SourceIP模式，也提出了一整套Session Persistent方案保证后续会话由相同Instance处理。

可以配置到Http、Https、TCP层

配置过程也好理解，除开上面的属性，最主要的是要配置VIP和映射IP的池。

![20180412230642691][]

有一点需要注意，通过上面的配置只能实现Load Balancer的转发，如果WEB1或者WEB2下线Load Balancer是无法发现的，需要我们再配置Monitor来解决监控的问题。

再来看Open vSwitch方式，要比Linux Bridge方式负责难理解：

Local Network：

与Linux Bridge不同的是，两个网络的Instance都连接到同一个网桥，但是通过Open vSwitch的tag将网桥划分为不同的VLAN。

![20180412230718051][]

Flat Network：

略，基本不用，Open vSwitch与Linux Bridge实现差别不大。

VLAN Network：

这个在介绍Local Network时已经把不同点强调过了，Linux Bridge是靠不同Bridge之间天然的VLAN隔离性来实现VLAN，而Open vSwitch中Instance连接到同一个带tag的br-int，依靠tag来实现VLAN的隔离。

![20180412230753767][]

Open vSwitch 通过 flow rule（流规则）来指定如何对进出br-int 的数据进行转发，进而实现 vlan 之间的隔离。当数据进出 br-int 时，flow rule 可以修改、添加或者剥掉数据包的 VLAN tag，Neutron 负责创建这些 flow rule 并将它们配置到 br-int，br-eth1 等 Open vSwitch 上。

Tag提供了VLAN隔离性，但是tagID不等于vlanID，需要在Open vSwitch里做一次映射，例如：priority=4,in\_port=2,dl\_vlan=1actions=mod\_vlan\_vid:100,NORMAL，就是将tag1映射成vlan100

再来个图详细解释下tag与vlan的关系

![20180412230825886][]

给br-eth1中配置tag1到vlan100的映射，再给br-int中配置vlan100到tag1的映射，br-eth1与br-int之间是通过vlan100传播的。所以我们可以看到vlan在这里只有那么一小段传播起了作用，而真正完成隔离的还是tag。

Routing：

与Linux Bridge差异不大，通过在br-int中增加端口映射来实现的。

External Network：

![20180412230859301][]

Floating IP：

与Linux Bridge实现方式完全一样。

总之Open vSwitch与Linux Bridge在使用时操作无差别，只是底层的实现方式不同。

采用哪种方式是由ML2的配置决定的/etc/neutron/plugins/ml2/ml2\_conf.ini。

mechanism\_drivers = linuxbridge

mechanism\_drivers = openvswitch

Neutron-------------------------------------------------------------------------------------------------------------------

OpenStack的日志：

存放在/var/log/xxx/中，比如 Nova 放在 /var/log/nova/ 下，Glance 放在/var/log/glance下……

OpenStack隐藏的核心:Driver机制

[20180412225559800]: /images/20220527/1eda0573831d497e8b23c66befee843c.png
[20180412225629409]: /images/20220527/7be586f2fe7f41ed990995738e71d12d.png
[20180412225702353]: /images/20220527/010ef325beef42a089a7c7ad39a2a50b.png
[20180412225740351]: /images/20220527/e861628f1b204c3b94f95f69d98cd720.png
[20180412225812233]: /images/20220527/457b3a7d1aae45c3ac58e5b41c06b343.png
[https_docs.openstack.org_nova_latest_user_filter-scheduler.html]: https://docs.openstack.org/nova/latest/user/filter-scheduler.html
[20180412225843360]: /images/20220527/bab065f46926437389fb921db44553e6.png
[20180412225917857]: /images/20220527/a81bb35db2f94e01a5d542d9c5fc9a54.png
[20180412225950063]: /images/20220527/ee37dd92d6e74187aa3601e3bdc9960b.png
[Link 1]: http://blog.csdn.net/yejingtao703/article/details/79858865
[20180412230026090]: /images/20220527/cc9e9969185f4baeb1cc9cbd429b537f.png
[20180412230056133]: /images/20220527/27c01c07a7c94ad194d44e7d16879edf.png
[20180412230128184]: /images/20220527/4119f20a0fa24a049b7d9fc9a0c2bf3e.png
[20180412230209672]: /images/20220527/008e8f802b73486a90418b5acbe52eab.png
[20180412230243153]: /images/20220527/1c150a6551e14208843377b3b80338da.png
[20180412230322928]: /images/20220527/d7d513e5678d49c9b99558cfc648ae07.png
[20180412230402452]: /images/20220527/34711ff595b24167b1d84f8e5ff4c049.png
[20180412230442947]: /images/20220527/f9a0889bb98041aebc61f554c1c67681.png
[20180412230525333]: /images/20220527/9ef24efb79144c019c50393feb35322e.png
[20180412230601528]: /images/20220527/460346703fbc4ebf879eb662a2b7eb04.png
[20180412230642691]: /images/20220527/c5b894fc0de14fb3bde88a876d16d68b.png
[20180412230718051]: /images/20220527/f2baae4d9d0c4180a0c028761042f258.png
[20180412230753767]: /images/20220527/06962e757c5e4401b7794ddfc0a904b4.png
[20180412230825886]: /images/20220527/b57acd77a3a24e57913f23fc3872f284.png
[20180412230859301]: /images/20220527/30af62796cc9413991cd8021b233c04f.png