openstack的运维方式,相对传统单机软件运维差别比较大,需要那种对大规模服务器运维的经验,自动化程度需要比较高的要求,监控报警平台也不可或缺。大型分布式系统最难的就是运维和问题的重现,这个时候日志就是最好的排除问题的方法,大部分问题只要有详细的日志记录,都能解决问题。还有一些问题就是软件自身的故障或者bug,需要源代码去进行调试解决。

我在使用openstack的过程中,也遇到很多问题,大部分问题都是前期规划不好导致灾难性的不可恢复的故障。openstack使用到了很多非常底层的linux技术和网络方面的技术,所以对于排除故障解决故障有比较高的要求。一些比较常见的问题就是存储满了的问题,有些是日志导致的根目录100%,有些是云主机空间和mangodb导致磁盘空间满了,让openstack无法正常运行。

openstack中对于存储空间规划,有如下几个目录需要注意:

  • /var/lib/glance 镜像存储目录
  • /var/lib/mongodb Ceilometer组件收集的集群信息,最好设置周期性删除数据
  • /var/lib/nova 每个compute节点,创建云主机后,存储云主机的目录

openstack另一块问题是,经常会出现前后端数据不一致的情况,数据库中数据。可能很多时候需要手动去干预某些数据库记录的数据。手动清理和修改状态。

目前我在生产环境使用M不便的openstack一年多,没有发生过重大故障,云硬盘经常会出现错误状态,但是不影响使用。除此之外就是网络不稳定,性能特别差的问题,一般都需要从硬件方面着手解决。

生产环境中操作系统内核、硬件的配置、网络配置、自动化运维软件、监控报警、负载均衡、网络类型等等选择都非常重要,关系到平台的可用性和稳定性。

生产环境使用openstack之前,一定要慎重,多验证,多测试,确保可用。做为企业内部的开发测试云到是非常方便,如果用在一些其他数据分析的业务中,对硬件和网络的要求是非常高的。因为我个人主要是做大数据基础平台的设计开发工作,为了简化和自动化我们的开发平台,所以选择使用openstack,因为我们的应用场景就是,每天都有成百上千的云主机被创建,使用完之后里面就会被回收。为了保证公司大数据基础平台能稳定发布,所以需要不断的使用各种各样的操作系统版本进行大规模测试。基于这样的考虑,我们选择了openstack这样的开源私有云解决方案。

当然在我们内部,也会运行着一些长久的云主机,常年运行不动的,比如:

  • YUM源服务器 主要用来发布我们大数据基础平台的软件包
  • 内部私有云盘 主要用来存放客户数据以及公司内部的文件
  • 私有docker镜像仓库 用来存放我们持续集成平台的docker镜像
  • 内部的源码仓库备份 gitlab内部git源码服务器

如上服务,我们大部分是用来存储一些重要数据的,因为底层的云盘我们是用分布式文件系统做的,拥有超高容错和无中心架构,可以同时允许多台集群奔溃,数据仍然不会丢失,对于云盘、云主机使用快照功能的。同步硬件服务器中一些比较重要的数据到云主机进行备份。

而且很多时候,openstack平台即使有一些问题,也不会影响云主机的使用,底层技术选择基于kvm,使用kvm的方式也能维护,那样是在平台出问题,迫不得已的时候才会选择的办法。openstack只是把这个过程给高度自动化了。

使用经验

  • 开源软件 bug 在所难免,但是新版本比旧版本会好用很多,尤其是对于 OpenStack 这种正在迅速成长壮大的开源软件来说更是如此,这一点在我们使用过juno、liberty 和 mitaka 版本后深有体会,所以建议各种 OpenStack 用户能及时的跟进社区版本,与社区保持同步。

  • 不要轻易的对社区版本进行各类所谓的功能性能方面的”优化”,尤其是在没有与社区专家交换意见之前,千万不要轻易下手,否则此类”优化”极有可能演变成故障点或者性能瓶颈点,最终可能导致无法与社区同步,毕竟一个公司或团队(尤其是小公司、小团队)的能力和知识储备,是很难与社区成百上千的各类专家相提并论的。

  • 多参考各类大型公司分享的部署架构方案,尽量不要自己闭门造车,尤其是对于开源软件来说,各类公司、团队的使用场景千差万别,各种周边组件也是应有尽有,多参考业界实践是最好的方式。
    一些细节实现可能有很多途径,但每种方式都有优缺点,需要经过充分的论证、分析、测试验证后,才能考虑部署到生产环境使用。

  • 所有的部署方案、功能设计都要考虑到平滑升级问题,即使你得到的信息是升级时可以停服,仍然要尽量避免这种情况,因为停服的影响范围很难界定。

运维准则

OpenStack 也是一个后端系统服务,所有系统运维相关的基本准则都适用,这里简单的提几点实际运维过程中根据遇到的问题总结的一些经验:

  • 配置项默认值与实际环境不匹配可能导致各种问题,尤其是网络相关配置与硬件有很强的关联性,生产环境和开发环境硬件异构,导致部分默认值在生产环境不适用。应对准则:每个版本都必须在与线上硬件相同的环境测试过才能上线。

  • 做好容量规划,已分配的配额量要小于云平台总容量,否则会出现各种问题,导致运维开发耗费很多不必要的精力去定位分析问题。

  • 配置项过多容易出错,需要与开发人员一起仔细核对,上线时首先要通过 puppet 的 noop 功能验证改动是否正确后,才能真正上线。

  • 网络规划要提前做好,如固定 IP、浮动 IP、VLAN 数量等,网络扩容难度和风险都比较大,所以提前规划好是最保险的,一个原则是大比小好,多比少好。

  • 网络隔离要做好,否则用户网络安全没办法保证。

  • 信息安全问题要重视,这个是老生常谈的问题了,每个平台都有相同问题,但还是要重视再重视,一旦出现安全漏洞,所有虚拟机都面临严重威胁。