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 数量等，网络扩容难度和风险都比较大，所以提前规划好是最保险的，一个原则是大比小好，多比少好。

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

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