细说自动化运维的前世今生(2)

发布时间：2021-01-06 18:06 所属栏目：53 来源：网络整理

导读：计算服务(Nova)：按需提供计算资源,创建和管理批量虚拟机,动态虚拟机管理：创建、重启、调整大� ⑶ㄒ频�. 对象存储服务(Swift)：基于普通硬件的大规模存储,无中心节点,分布式存储、水平扩展,同时多数据备份,保证安

计算服务(Nova)：按需提供计算资源,创建和管理批量虚拟机,动态虚拟机管理：创建、重启、调整大小、迁移等.
对象存储服务(Swift)：基于普通硬件的大规模存储,无中心节点,分布式存储、水平扩展,同时多数据备份,保证安全,通过API接口对外访问.
块存储服务(Cinder)：为虚拟机提供云硬盘.
网络服务(Neutron)：为虚拟机提供网络访问能力.
编排服务(Heat)：提供自动化部署及管理服务.
数据库服务(Trove)：提供数据库管理服务.
认证服务(Keystone)：提供身份认证机制服务.
镜像服务(Glance)：提供虚拟机镜像存储服务.
监控服务(Ceilometer)：提供计量与监控服务.
Dashboard(Horizon)：自服务、权限、图形化界面.

Openstack尽管对IaaS层的自动化管理比较强大,但仍然需要注意如下几点：

1、Openstack版本众多,如何选择是一个难题.

例如存在社区版、发行版、商业公司定制版本等,如何选择是一个难题,而且Openstack每半年一个稳定版本,演进很快.一般认为对Openstack项目中的开源代码进行修改定制是个不错的主意,但这从长期角度来看不一定最佳.“定制云”很可能需要付出高昂的代价,不仅投资巨大、成本高昂,企业用户还将被迫面对一大堆后续的管理及维护开销,并被绑定在单一供应商或版本身上.

建议企业如果有很强的技术能力的话,可以根据自己的需求做定制,但需要把握好和社区发展的关系. 一般来说,需要根据自己的需求,选择合适的版本,尽量不改变社区版本,定制化需求尽量在外围进行改动.如果采用了厂商的版本,实际上也是某种绑定,可能离社区越来越远.

2、需要慎重选择相关组件合功能

由于Openstack理念是分布式、最终一致性,因此所有的原始功能组件都是基于这一设计,企业用户考虑采纳Openstack之前,必须对企业业务应用进行分析：应用程序是否有可扩展性和弹性伸缩的要求? 应用程序是否可以接受最终一致性? 应用程序是否无状态化? 应用程序的性能要求?应用程序的可靠性要求? 应用程序的安全要求? 应用程序的容灾备份需求? 不同的要求决定了Openstack不同的计算、存储、网络等模块设计.

3、Openstack对PaaS层和物理机管理较弱,需借助其他工具实现

Openstack已经能够支持很多的IaaS自动化运维和部分PaaS自动化运维任务,但不能满足全部,如批量运维、深入监控、软件管理等功能缺少,特别是对物理机运维较弱,一般需要结合其他PaaS层管理进一步完善自动化运维体系.

SaltStack+定制

PaaS层自动化运维工具就太多了,例如监控就有Nagios、Ganglia、Zabbix等,运维工具则有Puppet、Chef、SaltStack、Ansible等,不同企业根据企业自身开发实力、结合配置管理工具的资源丰富程度、依赖复杂程度考虑,会有不同的选择.通过对运维工具本身的研究,结合运维人员的运维经验和评估企业未来的规模,下面以开源SaltStack+定制实现的方案进行介绍.

SaltStack是继 Puppet、Chef 之后新出现的S配置管理及远程执行工具,与 Puppet 相比,SaltStack较为轻量；不像 Puppet有一套自己的 DSL 用来写配置,SaltStack 使用 YAML 作为配置文件格式,相对简单,同时也便于动态生成；此外,SaltStack 在远程执行命令时的速度快,由于使用了ZeroMQ,这个下发过程可以并行执行,速度比Ansible的无agent ssh通信快得多,是一个分布式远程执行系统,用来在远程节点(可以是单个节点,也可以是任意规则挑选出来的节点)上执行命令和查询数据.

从部署结构上看,SaltStack的在部署上可以分为master和minion两个部分,其中master相当于统领所有机器的总管,而minion则是部署在被管理机器上面的agent进程,master通过网络将配置管理相关的操作下发到minion,由minion在对应机器的本地执行.典型的部署例子如下图所示：

在现实生产环境中,大批量的用户创建需求,文件上传需求、配置变更需求、软件升级需求占用了维护人员大量的时间,引入SaltStack后,该工具的远程执行和配置管理可以解决该问题,真正实现批量化和自动化,满足海量运维的需求.

容器

有了Openstack和SaltStack为代表的的PaaS层自动化工具还不够,针对应用自动化运维场景,如弹性伸缩、DevOps(开发运维一体化、开发测试一致的环境、自动资源调度、应用日志统一管控、应用服务的编排、微服务管理等),此时出现了容器技术,容器技术实现有很多种,但最流行的是Docker.

传统容器技术相较虚拟机优势不是特别大.Docker能够流行一大重要因此就是它的创新–Docker镜像.Docker构建了一整套构建、发布、运行体系：容器(Container)、仓库(Repository)、镜像(Images).传统容器只解决了容器运行(run)的问题.而Docker定义了一套容器构建(build)分发(ship)的标准,使应用管理非常便捷,尤其适合微服务管理.

注意容器对应用有特定的要求,并不是所有应用都适合,例如需要无状态化、镜像文件不能太大等.

自动化运维需要注意的几点：
?
一般的自动化运维工具均缺乏良好的可视化界面,需要进行结合定制开发.良好的界面可以更易于在企业内部推广自动化运维.
自动化运维工具众多,各有所长,应结合熟悉程度、技术特点进行针对性选择.
多层的自动化管理工具,多头的配置管理是个难题,建议考虑定制化,设计统一的CMDB,做到一点配置,多点更新.

Ok,本文就到这里,由于自动化运维是个很大的话题,涉及话题很大很广,这次仅仅是答题的概述,后续将结合专题进行细化讨论.

（编辑：ASP站长网）