4年！我对OpenStack运维架构的总结

前言

应北极熊之邀，写点物品。思来想去云计算范围真实宽泛，自然就聊点最近话题意外炽热，让广阔云计算从业者爱之深、痛之切，想说一声爱你，不容易的OpenStack吧。

这里，仅从技术角度登程，谈谈OpenStack云平台在部署、架构和运维实施等方面的感想。

缘起，在2014年大二初次接触到OpenStack，过后国际外资料远没有这么丰盛，为装置一个OpenStack H版环境(一台笔记本用VMwareWorkstation虚构出2台虚构机)愣是用了1个星期多，最后依然创立虚构机失败。起初为了学习OpenStack，邻近毕业时特地去上海实习上班，不觉间曾经四年了。

OpenStack触及的物品太多太多，计算、存储、网络、架构、产品、运维、监控和性能优化、代码等等。这里就各抒已见，谈点自己四年以来对OpenStack的了解吧，也算是一个交代，如有过错，欢迎拍砖。

固然，一个良好的架构设计和运维保证措施，能为OpenStack云平台的稳固肥壮运转，发生无法估计的踊跃影响。假设化繁为简，繁难的来说，要部署一套消费环境级别的OpenStack云平台，至少会触及到四个档次的内容，即物理基础设备层、存储层、OpenStack云服务层和用户运行层。如下图所示。

物理基础设备层

首先，从最底层开局说起，即“物理基础设备层”。一个基本的物理基础设备IT环境，包括了电力设备、空和谐防火设备、网络设备(如替换机、路由器、防火墙、负载平衡设备等)、存储设备和主机等。由于专业常识的限制，这里，只触及替换机和主机方面。一个基本的物理IT环境，如下图所示。

替换机设备

普通地，在OpenStack消费环境上，替换机端口应该做聚合(channel)。也就是将2个或多个物理端口组合在一同成为一条逻辑的链路从而参与替换机和网络节点之间的带宽，将属于这几个端口的带宽兼并，给端口提供一个几倍于独立端口的独享的高带宽。Trunk是一种封装技术，它是一条点到点的链路，链路的两端可以都是替换机，也可以是替换机和路由器，还可以是主机和替换机或路由器。

主机

网卡

OpenStack云平台触及到的网络有治理网络(用于OpenStack各服务之间通讯)、外部网络(提供floatingip)、存储网络(如ceph存储网络)和虚机网络(也称租户网络、业务网络)四种类型。

对应到每一种网络，主机都应该做网卡Bond，来提供主机网络的冗余、高可用和负载平衡的才干，依据实践需求，可以选用形式0或形式1。在网络流量较大的场景下介绍经常使用bond0;在牢靠性要求较高的场景下介绍经常使用bond 1。

二者优劣比拟。

普通地，在小规模的私有云环境中，网络类型对应的带宽是：

假设是中大规模的私有云或私有云环境，则介绍尽量都经常使用万兆网络。

硬盘

主机操作系统经常使用的系统盘，应该用2块硬盘来做RAID1，以提供系统存储的高牢靠性。且介绍经常使用高性能且老本可控的SAS硬盘，以提高操作系统、MySQL数据库和Docker容器(假设经常使用kolla部署openstack)的IO存储性能。

OpenStack各计算节点的CPU型号，必需分歧，以保证虚构机的迁徙性能反常可用等。

内存

OpenStack各计算节点的内存大小，应该分歧，以保证虚构机创立治理的平衡调度等。同时，主机的Swap替换分区，应该迷信正当的设置，不能经常使用系统自动创立的。

数据中心中少局部机器用于做控制节点，大局部机器都是要求运转虚构化软件的，虚构化平台上有少量的VM，而宿主机自身的系统也会跑一些服务，那么这就势必会形成vm之间资源抢占，vm与宿主机系统之间的资源抢占，咱们要求经过设定规定，让他们在各自的界限内高效运转，缩小抵触抢占。

咱们可以让宿主机运转操作系统时刻，更多的选用指定的几个核，这样就不会过多抢占虚构化中虚机的vcpu调度，经过修正内核启动参数咱们可以做到:

修正 /etc/default/grub文件，让系统只经常使用前三个核 隔离其他核。

更新内核参数

内存性能方面，网易私有云的通常是封锁 KVM 内存共享，关上透明大页：

听说，经过 SPEC CPU2006 测试，这些性能对云主机 CPU 性能大略有7%左右的优化。

OpenStack云平台层

云平台高可用(HA)

高可用(HA)引见

高可用性是指提供在本地系统单个组件缺点状况下，能继续访问运行的才干，无论这个缺点是业务流程、物理设备、IT软/配件的缺点。最好的可用性，就是你的一台机器宕机了，然而经常使用你的服务的用户齐全觉得不到。你的机器宕机了，在该机器上运转的服务必需得做缺点切换(failover)，切换有两个维度的老本：RTO(Recovery Time Objective)和 RPO(Recovery Point Objective)。RTO 是服务复原的时期，最佳的状况是0，这象征着服务立刻复原;最坏是无量大象征着服务永远复原不了;RPO 是切换时向前复原的数据的时期长度，0 象征着经常使用同步的数据，大于 0象征着有数据失落，比如 ” RPO = 1 天“ 象征着复原时经常使用一天前的数据，那么一天之内的数据就失落了。因此，复原的最佳结果是 RTO = RPO =0，然而这个太理想，或许要成功的话老本太高。

对 HA 来说，往往经常使用散布式存储，这样的话，RPO =0 ;同时经常使用 Active/Active (双活集群) HA 形式来使得 RTO简直为0，假设经常使用 Active/Passive HA形式的话，则要求将 RTO 缩小到最小限制。HA 的计算公式是[ 1 - (宕机时期)/(宕机时期 +运转时期)]，咱们常罕用几个 9 示意可用性：

服务的分类

HA 将服务分为两类：

HA 的种类

HA 要求经常使用冗余的主机组成集群来运转负载，包括运行和服务。这种冗余性也可以将 HA 分为两类：

OpenStack云环境高可用(HA)

云环境是一个宽泛的系统，包括了基础设备层、OpenStack云平台服务层、虚构机和最终用户运行层。

云环境的 HA 包括：

仅就OpenStack云平台服务(如nova-api、nova-scheduler、nova-compute等)而言，少则几十，多则上百个。假设某一个服务挂了，则对应的性能便不能反经常常使用。因此，如何保证全体云环境的HA高可用，便成为了架构设计和运维的重中之重。

OpenStack HA高可用架构，如下图所示。

假设，从部署层面来划分，OpenStack高可用的内容包括：

控制节点HA

在消费环境中，倡议至少部署三台控制节点，其他可做计算节点、网络节点或存储节点。驳回Haproxy +KeepAlived方式，代理数据库服务和OpenStack服务，对外泄露VIP提供API访问。

MySQL数据库HA

mysql 的HA 方案有很多，这里只探讨openstack 官网介绍的mariadb Galara 集群。Galera Cluster是一套在innodb存储引擎上方成功multi-master及数据实时同步的系统架构，业务层面无需做读写分别上班，数据库读写压力都能依照既定的规定散发到各个节点下来。特点如下：

驳回MariaDB + Galera方案部署至少三个节点(最好节点数量为奇数)，外部访问经过Haproxy的active +backend方式代理。往常主库为A，当A出现缺点，则切换到B或C节点。如下图所示。

RabbitMQ 信息队列HA

RabbitMQ驳回原生Cluster集群方案，一切节点同步镜像队列。小规模环境中，三台物理机，其中2个Mem节点关键提供服务，1个Disk节点用于耐久化信息，客户端依据需求区分性能主从战略。听说经常使用ZeroMQ替代自动的RabbitMQ有助于优化集群信息队列性能。

OpenStack API服务HA

OpenStack控制节点上运转的基本上是API有形态类服务，如nova-api、neutron-server、glance-registry、nova-novncproxy、keystone等。因此，可以由HAProxy 提供负载平衡，将恳求依照必定的算法转到某个节点上的 API 服务，并由KeepAlived提供 VIP。

网络节点HA

网络节点上运转的Neutron服务包括很多的组件，比如 L3 Agent，openvswitchAgent，LBaas，VPNaas，FWaas，Metadata Agent 等，其中局部组件提供了原生的HA 支持。

存储节点HA

存储节点的HA，关键是针对cinder-volume、cinder-backup服务做HA，最简便的方法就是部署多个存储节点，某一节点上的服务挂了，不至于影响到全局。

计算节点和虚构机 HA

计算节点和虚构机的HA，社区从2016年9月开局不时努力于一个虚构机HA的一致方案，但目前依然没有一个成熟的方案。成功计算节点和虚构机HA，要做的事情基本有三件，即。

① 监控

监控关键做两个事情，一个是监控计算节点的配件和软件缺点。第二个是触发缺点的处置事情，也就是隔离和复原。

OpenStack计算节点高可用，可以用pacemaker和pacemaker_remote来做。经常使用pacemaker_remote后，咱们可以把一切的计算节点都参与到这个集群中，计算节点只要要装置pacemaker_remote即可。pacemaker集群会监控计算节点上的pacemaker_remote能否“活着”，你可以定义什么是“活着”。比如在计算节点上监控nova-compute、neutron-ovs-agent、libvirt等进程，从而确定计算节点能否活着，亦或许租户网络和其他网络断了等。假设监控到某个pacemaker_remote有疑问，可以马上触发之后的隔离和复原事情。

② 隔离

隔离最关键的义务是将不能反常上班的计算节点从OpenStack集群环境中移除，nova-scheduler就不会在把create_instance的message发给该计算节点。

Pacemaker曾经集成了fence这特性能，因此咱们可以经常使用fence_ipmilan来封锁计算节点。Pacemaker集群中fence_compute会不时监控这个计算节点能否down了，由于nova只能在计算节点down了之后才可以口头host-evacuate来迁徙虚构机，时期期待的时期稍长。这里有个更好的方法，就是调用novaservice-force-down 命令，直接把计算节点标志为down，繁难更快的迁徙虚构机。

③ 复原

复原就是将形态为down的计算节点上的虚构机迁徙到其他计算节点上。Pacemaker集群会调用host-evacuateAPI将一切虚构机迁徙。host-evacuate最后是经常使用rebuild来迁徙虚构机，每个虚构机都会经过scheduler调度在不同的计算节点上启动。

当然，还可以经常使用散布式肥壮审核服务Consul等。

虚构机操作系统缺点复原

OpenStack 中的 libvirt/KVM 驱动曾经能够很好地智能化处置这类疑问。详细地，你可以在flavor的 extra_specs或许镜像的属性中加上 hw:watchdog_action ，这样一个 watchdog 设备会性能到虚构机上。假设 hw:watchdog_action设置为 reset，那么虚构机的操作系对抗旦奔溃，watchdog 会将虚构机智能重启。

OpenStack计算资源限制

设置内存

内存调配超售比例，自动是 1.5 倍，消费环境不倡议开启超售

内存预留量，这局部内存不能被虚构机经常使用，以便保证系统的反常运转

设置CPU

在虚构化资源经常使用上，咱们可以经过nova来控制，OpenStack提供了一些性能，修正文件nova.conf。虚构机 vCPU的绑定范围，可以防止虚构机争抢宿主机进程的 CPU 资源，倡议值是预留前几个物理 CPU

物理 CPU 超售比例，自动是 16 倍，超线程也算作一个物理 CPU

经常使用多Region和AZ

假设，OpenStack云平台要求跨机房或地域部署，可以经常使用多Region和 AvailabilityZone(以下简称AZ)的方案。这样，每个机房之间在天文位置上自然隔离，这对下层的运行来说是自然的容灾方法。

多区域(Region)部署

OpenStack支持依据天文位置划分为不同的Region，一切的Regino除了共享Keystone、Horizon服务外，每个Region都是一个完整的OpenStack环境，从全体上看，多个区域之间的部署相对独立，但可经过内网专线成功互通(如BGP-EVPN)。其架构如下图所示。

部署时只要要部署一套公共的Keystone和Horizon服务，其它服务依照单Region方式部署即可，经过Endpoint指定Region。用户在恳求任何资源时必需指定详细的区域。驳回这种方式能够把散布在不同的区域的资源一致治理起来，各个区域之间可以采取不同的部署架构甚至不同的版本。其优势如下：

但该方案也存在显著的无余：

OpenStack多Region方案经过把一个大的集群划分为多个小集群一致治理起来，从而成功了大规模物理资源的一致治理，它特地适宜跨数据中心并且散布在不同区域的场景，此时依据区域位置划分Region，比如北京和上海。而关于用户来说，还有以下好处:

多Availability Zone部署

假设，只是想在一个机房中部署OpenStack云环境。则只要要经常使用AZ方案即可。每个AZ有自己独立供电的机架，以及OpenStack计算节点。

Availability Zone

一个Region可以被细分为一个或多个物理隔离或逻辑隔离的availabilityzones(AZ)。启动虚构机时，可以指定特定的AZ甚至特定AZ中的某一个节点来启动该虚构机。AZ可以繁难了解为一组节点的汇合，这组节点具备独立的电力供应设备，比如一个个独立供电的机房，或一个个独立供电的机架都可以被划分红AZ。

而后将运行的多个虚构机区分部署在Region的多个AZ上，提高虚构机的容灾性和可用性。由于，AZ是物理隔离的，所以一个AZ挂了不会影响到其他的AZ。同时，还可以将挂了的AZ上的虚构机，迁徙到其他反常可用的AZ上，相似于他乡双活。

Host Aggregate

除了AZ，计算节点也可以在逻辑上划分为主机聚合(HostAggregates简称HA)。主机聚合经常使用元数据去标志计算节点组。一个计算节点可以同时属于一个主机聚合以及AZ而不会有抵触，它也可以属于多个主机聚合。

主机聚合的节点具备独特的属性，比如：cpu是特定类型的一组节点，disks是ssd的一组节点，os是linux或windows的一组节点等等。要求留意的是，HostAggregates是用户无法见的概念，关键用来给nova-scheduler经过某一属性来启动instance的调度，比如讲数据库服务的instances都调度到具备ssd属性的Host Aggregate中，又或许让某个flavor或某个image的instance调度到同一个HostAggregates中。

繁难的来说，Region、Availability Zone和HostAggregate这三者是从大范围到小范围的相关，即前者蕴含了后者。一个天文区域Region蕴含多个可用区AZ (availabilityzone)，同一个AZ中的计算节点又可以依据某种规定逻辑上的组分解一个组。例如在北京有一个Region，成都有一个Region，做容灾之用。同时，在北京Region下，有2个AZ可用区(如酒仙桥机房和石景山机房)，每个AZ都有自己独立的网络和供电设备，以及OpenStack计算节点等，假设用户是在北京，那么用户在部署VM的时刻选用北京，可以提高用户的访问速度和较好的SLA(服务等级协定)。

选用适宜的网络方案

用户常困扰于究竟应该经常使用何种网络方案，如VLAN、VXLAN和GRE等。VLAN和VXLAN的区别即在于，VLAN是一种大二层网络技术，不要求虚构路由转换，性能相对VXLAN、GRE要好些，支持4094个网络，架构和运维繁难。VXLAN是一种叠加的网络隧道技术，将二层数据帧封装在三层UDP数据包里传输，要求路由转换，封包和解包等，性能相对VLAN要差些，同时架构也更复杂，好处是支持1600多万个网络，扩展性好。

假设，企业用户在相当长的一段时期内，云平台规模都较小(比如在1万台虚构机数量以下)，且对多租户网络安保隔离性要求不高，那么可以经常使用VLAN网络。反之，假设网络安保隔离性需求压倒一切，或许云平台规模十分大，则可以经常使用VXLAN网络方案。

在VXLAN和VLAN网络通讯，即租户私网和FloatingIP外网路由转发通讯背景下，自动在OpenStack传统的集中式路由环境中，南北流量和跨网络的物品流量都要经过网络节点，当计算节点规模越来越大的时刻，网络节点很快会成为整个系统的瓶颈，为处置这个疑问引入了DistributeVirtual Router(DVR)的概念。经常使用DVR方案，可以将路由散布到计算节点，南北流量和跨网段的物品流量由虚机所在计算节点上的虚构路由启动路由，从而提高稳固性和性能。

备份云平台数据

俗话说，有备份在，睡觉也虚浮。在一个实践的环境中，由于种种要素，或许出现数据被删除的状况。比如，云平台中的数据库、虚构机、数据卷、镜像或底层存储被删除等，假设数据没有启动备份，则是劫难性的结果。

在一个由OpenStack+Ceph架构组成的云平台环境中，有N种数据备份方案。如OpenStack有自带的Karbor、Freezer云服务，Ceph也有相关的备份方案，也有其他商业的备份方案等。实践上，OpenStack云平台自身也提供了一些较好易用的备份性能，比如虚构机快照/备份、数据卷快照/备份，在经常使用时也提倡经过将数据卷挂载给虚构机，从而将数据写入到云盘中，直接的成功数据容灾备份。

假设由于某些要素，没有跨物理机房或地域的Region和AZ。那么OpenStack云平台相关的数据备份，则是必要求做的。比如MySQL数据库等，可以依据实践需求，每隔几小时启动一次性备份。而备份的数据，倡议寄存到其他机器上。关于Ceph的底层存储藏份方案，可以经常使用RBDMirroring方案。

RBD Mirroring是Ceph新的异步备份性能。支持性能两个Ceph Cluster之间的rbd同步。在此方案下，MasterCluster经常使用性能较高的存储设备，提供应OpenStack的Glance、Cinder(cinder-volume、cinder-backup)和Nova服务经常使用;而BackupCluster则经常使用容量空间大且便宜的存储设备(如SATA盘)来备份Ceph数据。不同的CephCluster集群，可以依据实践要求，选用能否跨物理机房备份。如下图所示。

优势：

经常使用适宜的Docker存储

假设，OpenStack云平台是用kolla容器化部署和治理的。那么选用一个正确、适宜的Docker存储，关乎你的平台稳固和性能。

Docker 经常使用存储驱动来治理镜像每层内容及可读写的容器层，存储驱动有devicemapper、aufs、overlay、overlay2、btrfs、zfs等，不同的存储驱动成功方式有差异，镜像组织方式或许也稍有不同，但都驳回栈式存储，并驳回 Copy-on-Write(CoW)战略。且存储驱动驳回热插拔架构，可灵活调整。那么，存储驱动那么多，该如何选用适宜的呢?大抵可从以下几方面思索：

Docker容器其实是在镜像的最下层加了一层读写层，通常也称为容器层。在运转中的容器里做的一切改动，如写新文件、修正已有文件、删除文件等操作其实都写到了容器层。存储驱动选择了镜像及容器在文件系统中的存储方式及组织方式。在咱们的消费环境中，经常使用的是Centos7.4系统及其4.15内核版本+Docker 1.13.1版本。因此经常使用的是overlay2存储。上方对overlay2作一些繁难引见。

Overlay引见

OverlayFS 是一种相似 AUFS 的联结文件系统，但成功更繁难，性能更优。OverlayFS 严厉来说是 Linux 内核的一种文件系统，对应的Docker 存储驱动为 overlay 或许 overlay2，overlay2 需 要Linux 内核 4.0 及以上，overlay 需内核 3.18及以上。且目前仅 Docker 社区版支持。条件容许的话，尽量经常使用 overlay2，与 overlay 相比，它的 inode 应用率更高。

和AUFS的多层不同的是Overlay只要两层：一个upper文件系统和一个lower文件系统，区分代表Docker的容器层和镜像层。当要求修正一个文件时，经常使用CoW将文件从只读的lower复制到可写的upper启动修正，结果也保留在upper层。在Docker中，底下的只读层就是image，可写层就是Container。结构如下图所示：

剖析

从kernel 3.18进入干流Linux内核。设计繁难，速度快，比AUFS和Devicemapper速度快。在某些状况下，也比Btrfs速度快。是Docker存储方式选用的未来。由于OverlayFS只要两层，不是多层，所以OverlayFS“copy-up”操作快于AUFS。以此可以缩小操作延时。

OverlayFS支持页缓存共享，多个容器访问同一个文件能共享一个页缓存，以此提高内存经常使用率。

OverlayFS消耗inode，随着镜像和容器参与，inode会遇到瓶颈。Overlay2能处置这个疑问。在Overlay下，为了处置inode疑问，可以思索将/var/lib/docker挂在独自的文件系统上，或许参与系统inode设置。

经常使用散布式存储

假设OpenStack云平台经常使用开源的散布式存储系统，如Ceph、GlusterFS等。如何保证存储系统的冗余容灾性、牢靠性、安保性和性能，便显得尤为关键。这里，以Ceph开源散布式存储为例启动解说。

Mon节点和OSD节点部署

普通地，在消费环境中，至少要求部署有3个Ceph Mon节点(数量最好为奇数)以及多个OSD节点。

开启CephX认证

同时，开启CephX认证方式，以提高数据存储的安保性，防范被攻打。如下所示。

网络性能

假设Ceph存储节点规模较小，Ceph公共网络(即Public Network)经常使用千兆网络，集群网络(即ClusterNetwork)经常使用万兆网络即可。假设Ceph节点规模较大，且业务负载较高，则尽量都经常使用万兆网络，在关键的环境上，Ceph公共网络和集群网络，都应该独自分开。要求留意的是，Ceph存储节点经常使用的网卡，必要求做网卡Bond，防止网卡因缺点而造成网络终止。

经常使用Cache Tier

在一个云存储环境中，出于老本的思索，基本会大批经常使用SSD硬盘，少量经常使用SATA硬盘。在OpenStack集成Ceph的云环境中，如何经常使用SSD和SATA硬盘。普通有两种经常使用方法。

这里，以第二种方式为例启动解说。当客户端访问操作数据时，会优先读写cache tier数据(当然要依据cachemode来选择)，假设数据在storage tier 则会优化到cache tier中，在cachetier中会有恳求命中算法、缓存刷写算法、缓存淘汰算法等，将热数据优化到cache tier中，将冷数据下放到storage tier中。

缓存层代明智能处置缓存层和后端存储之间的数据迁徙。在经常使用环节中，咱们可以依据自己的要求，来性能迁徙规定，关键有两种场景：

回写形式： 治理员把缓存层性能为 writeback 形式时， Ceph 客户端们会把数据写入缓存层、并收到缓存层发来的 ACK;写入缓存层的数据会被迁徙到存储层、而后从缓存层刷掉。直观地看，缓存层位于后端存储层的“前面”，当 Ceph客户端要读取的数据位于存储层时，缓存层代理会把这些数据迁徙到缓存层，而后再发往 Ceph 客户端。从此， Ceph 客户端将与缓存层启动 I/O操作，直到数据不再被读写。此形式关于易变数据来说较理想(如照片/视频编辑、事务数据等)。

只读形式： 治理员把缓存层性能为 readonly 形式时， Ceph 直接把数据写入后端。读取时， Ceph把相应答象从后端复制到缓存层，依据已定义战略、脏对象会被缓存层踢出。此形式适宜不变数据(如社交网络上展现的图片/视频、 DNA 数据、 X-Ray照片等)，由于从缓存层读出的数据或许蕴含过时数据，即分歧性较差。对易变数据不要用 readonly 形式。

独立经常使用Pool

Ceph可以一致OpenStackCinder块存储服务(cinder-volume、cinder-backup)、Nova计算服务和Glance镜像服务的后端存储。在消费环境上，倡议独自创立4个存储资源池(Pool)以区分对应OpenStack的4种服务存储。同时，每个Pool的正本数倡议设置为3份，如下表所示。

最后，Ceph散布式存储部署架构，如下图所示。

用户运行层

在相当多的业务中，都会触及到服务高可用。而普通的高可用的成功都是经过VIP(VitrualIP)成功。VIP不像IP一样，对应一个实践的网络接口(网卡)，它是虚构进去的IP地址，所以应用其特性可以成功服务的容错和迁徙上班。

在经常出现节点中VIP性能十分繁难，没有多大的限制。但OpenStack实例中，一个IP对应一个Port设备。并且Neutron 有“Allowedaddress pairs”限制，该性能要求 Port 的MAC/IP 相互对应，那么该IP才干连通。对Port设备的启动操作可以成功上方几特性能：

另内在OpenStack创立的实例中树立VIP并使其能反常上班可以经常使用上方方法：

第一步，创立Port设备

#openstacknetworklist//检查现有网络，从当选用创立port设备的网络#openstacksubnetlist//检查网络下存在子网，从当选用port设备所处子网#openstackport

此时Port设备曾经创立，但该Port设备与要求树立VIP的实例没有任何相关，在该实例上创立VIP也是不能上班的。要素在于上方

#neutronport-list|grepInstance-IP//找到要求性能VIP的实例的PortID

检查该Port的详细信息

此时的allowed_address_pairs为空，就算在该实例中创立VIP，其MAC/IP也是不对应，不能上班的。那么就要启动第二步，即更新Port的allowed_address_pairs信息

#neutron port-update Port-ID --allowed_address_pair list-true type=dictip_address=IP

例如

如今再来检查实例Port信息

此时在虚构机中创立VIP，就能够反常上班了。

运维平台树立

监控是整个运维乃至整个产品生命周期中最关键的一环，事先及时预警发现缺点，预先提供详实的数据用于查究定位疑问。目前业界有很多不错的开源产品可供选用。选用一些开源的监控系统，是一个省时省力，效率最高的方案。

经常使用Kolla容器化部署和治理OpenStack云平台，已成为干流趋向。这里，咱们以容器化部署和治理OpenStack云平台为背景，聊聊云平台相关的运维平台树立。

监控目的

咱们先来了解什么是监控、监控的关键性以及监控的目的，当然每团体所在的行业不同、公司不同、业务不同、岗位不同，对监控的了解也不同，然而咱们要求留意，监控是要求站在公司的业务角度去思索，而不是针对某个监控技术的经常使用。

监控的目的，包括：

监控体系分层

监控有赖于运维各专业条线协同完善，经过将监控体系启动分层、分类，各专业条线再去有重点的丰盛监控目的。监控的对象，关键有基础设备配件类和运行软件类等，如下图所示：

监控手腕

通常状况下，随着系统的运转，操作系统会发生系统日志，运行程序会发生运行程序的访问日志、失误日志、运转日志、网络日志，咱们可以经常使用 EFK来启动日志监控。关于日志监控来说，最经常出现的需求就是搜集、存储、查问、展现。

除了对日志启动监控外，咱们还要求对系统和运行的运转状况启动实时监控。不同的监控目的，有不同的监控手腕。OpenStack云资源的监控，如虚构机、镜像、数据卷、虚构网卡等，自然的可以由OpenStack自带的Ceilometer+Gnocchi+Aodh等服务来做(PS：ceilometer可以将采集数据交给gnocchi做数据聚合，最后用grafana展现报表)。

假设，OpenStack云平台是基于Kolla容器化部署和运转治理的。那么诸如Docker容器、操作系统负载、存储空间等，又该经常使用什么来运维监控并告警呢。自然，TPIG栈便跃然纸上了。

什么是TPIG栈。即由Telegraf + Influxdb + Grafana +Prometheus组分解的一套运维监控工具汇合。它们之间的相关是：

说明：

Prometheus和Telegraf不是必需同时部署经常使用的，你可以依据自己的要求，选用二者都部署，也可以二者选其一。

如下几种开源工具或方案，Kolla社区都是自动支持的。最关键的是，如何去经常使用、完善它们。

监控方法

监控流程

监控诉警

当监控的对象超越了某一阈值或许某一服务出现了意外时，便智能发送邮件、短信或微信给相关人员启动告警。

事情应急照应

运维最基本的目的就是保证系统的可用性，应急复原的时效性是系统可用性的关键目的。通常来讲应急复原的方法有不少，比如：

一些所见所想

事实中，不乏遇到一些拿来主义。行将Hadoop/Spark大数据业务跑在虚构机中运转，而后到了线上出现各种坑。如磁盘IO性能十分差，虚构机抢占宿主机资源，造成其CPU经常使用率超越700%等等，最后掉入自己挖的坑里。

须知，云计算的实质是虚构化，虚构化的实质是一虚多，行将一个个物理的计算资源、网络资源和存储资源等虚构化成多个逻辑资源(如KVM、openvswitch、ceph)，再由资源调度治理系统(如OpenStack)形象化提供应用户经常使用。而大数据的实质是多虚一，将多个计算、存储和网络资源一致治理集中起来提供应大数据业务经常使用。

OpenStack可以一致治理虚构机和裸机。介绍的做法应是将大数据放在裸机上跑，而不是放在虚构机上跑。违反了技术的实质，注定环节会很痛苦。

有的用户在上云或用云环节中，时常会纠结究竟经常使用什么方案才好?比如经常使用OpenvSwitch还是LinuxBridge?经常使用VLAN还是VXLAN、GRE?经常使用Ceph还是GlusterFS、商业存储?要不要做二次开发等?须知，素来不是技术选择需求，而是需求选择技术选型。雷同的，选用经常使用什么技术，应该由你的实践需求来选择。适宜自己的才是最好的。只能说二者各有优缺陷，用户要求做的是依据实践需求，规避掉危险点最大的，选用优势最显著的那个方案。

在预备经常使用OpenStack时，必定要明白OpenStack是一个常识密集型的开源云框架，记住是一个框架，而不是一个开箱即用的产品。所要求的各方面技术人才和技术储藏是十分宽泛的，企业通常会面临人才缺乏疑问，一方面很难从外部招到有阅历的人，另一方面是企业造就外部人才耗时耗力。假设企业只是将OpenStack做私有云供自己经常使用，性能需求或业务并不复杂，比如用来替代多少钱低廉的VMware提供虚构机业务，那么普通不要求启动二次开发。反之，将OpenStack作为一个云产品提供应第三方用户经常使用或许满足自身复杂业务需求，那么启动二次开发是必要的，比如一致云资源治理、资源逻辑调度、运维监控诉警、Iaas+PaaS+SaaS一致支持等。实践中，一些企业担任人把OpenStack定位成阿里云、AWS来开发，要么是高估了自己的才干，要么是低估了OpenStack的难度，觉得只是修正一个Dashboard而已，最后堕入死循环。

最后

随着技术的演变，平台复杂化+用户繁难化的趋向将越来越显著。这就要求最终出现给用户经常使用的系统必需是极简的。我置信，OpenStack朝着这方面努力，把企业用户的刚需转变为事实可操作性，出路会更黑暗!

最后，感谢OpenStack和引领我入门的前公司指导和共事，为我关上了一扇走进云计算的大门!同时也宿愿，有那么一日，OpenStack云计算能从大企业才干享受的舶来品，进入寻常企业家。

OpenStack正值青年，有理由一路走下去!

作者引见：

徐超，OpenStack、Kubernetes、Docker、CI/CD从业者和学习者，《OpenStack最佳通常-测试与CI/CD》一书作者，OpenStack开源社区介入者。