云评测 | OpenStack智能运维解决方案 @文末有福利！

戳蓝字“CSDN云计算”关注我们哦！

文章摘自 | 《OpenStack架构分析与实践》

谈到OpenStack，一个难以避免的话题就是运维，对于OpenStack的运维而言，随着其项目的不断增多，传统的“人肉运维”方式显然不能满足当下及以后的需求。目前，社区中已有与运维相关的组件，或是单独完成（如：Datadog），或是多个组件共同完成（如：Mistral+Vitrage），许多厂商也都结合容器竞相开发自己的运维模块，由于容器比较轻量级，启动速度比较快，可以快速影响系统变化。

容器技术可以实现将OpenStack虚拟机数量增加到四倍以上，微服务和SDDC（软件定义数据中心）又将进一步增加运维人员所要管理的IT资源的数量及分析问题、定位问题的难度。使用AI的方式对OpenStack系统进行监控、调试和纠错的方案仍处于初级阶段，面对强大的AI，在OpenStack中似乎没有发挥其拥有的功能。

不同厂商的智能运维框架都不尽相同。如宜信开源的AIOps三大利器：UAVStack、Wormhole、DBus。它开发的UAVStack是一个智能服务技术栈，是研发运维一体化的解决方案，开源系列包括全维监控（UAV.Monitor）、应用性能管理（UAV.APM）、服务治理（UAV.ServiceGovern）、微服务计算（UAV.MSCP）。其中，UAV.Monitor+APM为智能运维采集全维监控数据，是一站式的全维监控+应用运维解决方案。

提示：在社区中出现了一个基于容器进行OpenStack部署的解决方案，从运维的角度来看，这样可以极大的简化OpenStack中运维出现的问题，借助容器轻量化的实现及快速启动的特点，完全可以使用容器的高可用替代Pacemaker+Crosync提供的高可用方案。

一、 可视化的Dynatrace

早在巴塞罗那峰会时，就出现了出几款可以提供运维可视化、智能化的解决方案。先来看一款名为Dynatrace的产品。这是一个可视化的资源管控平台，包含了对各种资源的监控和监控数据的采集，并且分了不同的层面。对于应用层数据，支持用户提供关键字，从而实现对应用所涉及到的所有资源的查询与关联；对于OpenStack来说，有针对OpenStack集群的分析管理，例如：可以管理集群下面运行了多少虚拟机、多少磁盘、多少网络等，也可以实现对网络带宽的监控，监控当前网络是否处于饱和状态，通过对资源的分级，可以方便用户对问题进行分层定位与处理。

图1是Dynatrace官网给出一张示例图，图中展示了部分监控项的可视化图形。

图1 Dynatrace图形界面

从图1 可以实时的监控当前网卡的吞吐率、IOPS、时延及磁盘的剩余空间等。在其官方给出的介绍中，可以看出，它除了支持可图形可视化外，还提供了基于AI的数据分析功能、全栈搜索功能、自动修复功能等。

它可以实现对不同云平台的监控与运维自动化，以数据中心为例，在它提供的监控方案中，它将数据中心一共分为了五层：

第一层，数据中心

第二层，物理主机

第三层，物理机上运行的虚拟机或某些进程

第四层，基于进程对不同的服务进行分类

第五层，将不同的服务进行整合，从而形成一整个“应用”

二、 VirtTool Networks

从它的名字上可以很清楚的看到，它是一个专注于网络问题的相关产品。它使得对分析OpenStack中的网络问题更加方便快捷。

首先，通过它提供的图形界面，可以清晰的看到整个系统中的网络实时图，如图2所示：

图2 实时网络连接

其次，它也可以获取某一时刻，系统中网络设备上的流量热点，可以方便用户查看当前系统中，那个节点上的网络流量比较大或已达到峰值。

图3   网络流量热点监控

通过选中某个虚拟机或网络，可以查看相关资源的局部细节，如图4所示：

图4  云平台资源详细信息

除上述功能外，它还可以监控云平台中任意节点处的流量及流量包的传输路径，这样可以方便跟踪与查询网络中的丢包现象。

无论面对多么复杂的平台系统，也不管内部运行多么复杂的业务，要想在针对此平台做到快速故障定位，可以从以下两点入手：

平台中数据可视化展示

平台中数据资源的关联

前者可以提供更加友好、更加人性化的交互体验，这一点可以从Zabbix中得到较好的认证。它是一个专注于监控的产品，但它还是提供了较为简单的图形化界面，从界面上可以清晰的看出模板、被监控的主要、监控项、Action及Mediatype之间的关联关系。而对于像Mysql这样的产品而言，在可视化方面做还是相对逊色了许多。

后者一方面可以更好的为前者服务，但更重要的一点，它可以将云平台中相对比较零散的数据进行收集然后做聚合处理，将原先看似孤立的数据整合成一张大大的数据网，有了这张数据的关系网，那么我们再去进行故障分析与定位就相对容易多了。

三、 智能运维Vitrage

Vitrage是社区中的一个对系统进行RCA的项目，那么下面将从运维应用的角度来分析其在OpenStack智能运维中的应用。

提示：在多次OpenStack峰会上，Nokia都展示了其自己通过Mistral和Vitrage实现自动运维和故障修复的案例。

我们先来看这样一个简单场景，即当系统中CPU负载过高时，Vitrage将会如何去感知这一变化，继而感知后如何去将系统恢复到正常状态。从感知到状态恢复可以归结为以下四步：

1．产生告警

当Zabbix监控到某个主机上CPU负载过高时，Vitrage将会产生一个聚合的告警信息，此告警信息会与该主机上的虚拟机相关联，然后将虚拟机的状态设置为suboptimal。如图5所示：

图5 产生告警

这一过程可以通过模板来表示为：

2.RCA

当CPU过高的主机上有虚拟机，并且此虚拟机上CPU的负载也在持续升高，Vitrage负责分析产生告警的原因，并建立这三者之间的因果关系。如图6所示：

图6 RCA

同样可以用模板表示为：

3.设置主机的状态

当该主机上的CPU过高时，将主机的状态设置为suboptimal。

图7 设置主机状态

相应的模板为：

4.触发状态恢复

关于其状态恢复的过程，可以通过与Mistral结合来实现。Mistral是一个工作流组件，可以实现对长流程业务的合理管控。针对本示例中的问题，Vitrage与Mistral结合时的工作流程如图8所示：

图8  状态恢复流程

Vitrage接收到CPU负载过高的消息会，会通过Mistarl类型的Notifier将此消息发送到Mistral组件上，Mistral收到Vitrage发送的事件通知后，会调用相应的模板，继而调用heatclient实现AutoScaling及负载的均衡处理，从而可以将一台虚拟机的负载分配到其的虚拟机上，从而达到降低负载的作用。

提示：在运维中，比较重要的方面就是如何对故障进行预测，预测完成后，如何基于预测的结果实现相应操作的制定与资源的编排。谈到资源编排，不仅云平台中有这个概念，容器中也会有类似的概念，比如K8S就是可以看作是一种提供编排（不仅限于编排）服务的项目。

云技术书籍，免费送！

《OpenStack架构分析与实践》本书以实战开发为原则，以关键模块架构分析及项目开发为主线，通过OpenStack开发中常用的8个典型组件和若干典型项目案例，详细介绍了云平台中的计算、网络、存储、服务编排、智能运维等模块，并针对OpenStack中通用的关键技术进行了详细介绍。

仅限 5本 ，数量有限！

参与方式

在本文下方留言：

谈谈关于OpenStack架构分析与实践相关的话题内容

活动信息

1、活动时间：2019年2月25日~27日18:00

2、中奖（共5名）规则：

a.留言评论区点赞前3名；

b.留言评论区中字数最多的2名用户（最走心）；

最后感谢中国铁道出版社的对活动的大力支持！

福利

扫描添加小编微信，备注“姓名+公司职位”，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！

推荐阅读：

喜欢就点击“好看”吧