OpenStack在企业里如何用好？还有哪些问题需要着重解决？
OpenStack在企业里怎么才能用好？开发人员认为是使用姿势的问题；用户认为要稳定可靠，不能老宕机；老板认为多招几个牛X的开发和运维就可以搞定。
其实OpenStack在商用中存在的问题，主要在以下五个方面：稳定性、完整性、高可用性、易用性、双活和容灾。
先说稳定性。一个好的产品，性能并不是第一要素，稳定性对企业来说才是最重要的。
- OpenStack在扩展性和稳定性上还远远不足，需要精心打磨
从几十台增长到上千台甚至上万台，是否还可以一如既往的稳定工作不出问题？实践证明，随着规模的扩大，整体架构需要在稳定性方面做足功课。
比如需设计多个NOVA API和多个镜像、负载均衡和节点高可用、数据库的并发响应。
另外在社区中被吐槽最多的升级问题——Nova，Swift，Cinder和Neutron分别使用各自的数据库存储配置信息，要升级就要修改多个数据库schema，做不到热升级（在H版后升级问题得到改善）。
再如，某企业在部署网络服务（Neutron）时，遇到了噩梦般的经历，不得不重写网络组件的代码才能达到大规模应用的要求。
- OpenStack缺乏完整性
一个成熟的云平台应提供计算、存储、网络、安全、数据库、大数据、中间件、DevOps、监控运维等多种云产品。OpenStack只能提供计算、存储、网络三种云产品，如果企业客户需要信息安全保护的产品，则必须自助信息安全平台，集成第三方的产品。再比如大数据分析，通过Sahara可以快速部署Hadoop集群，那又怎么打通OpenStack和Hadoop之间的账户、安全、管理和运维监控体系？
- OpenStack的虚拟机级别的高可用做的还不好
目前并没有官方声明OpenStack支持虚拟机级别的高可用性，这个特性在Folsom版本被提出，但是后续又被放弃了。
目前 OpenStack有一个孵化项目Evacuate, 其作用是为OpenStack提供虚拟机级别高可用支持。Evacuate目前只能是管理员手动发起，Evacuate没有考虑VM的部署属性，导致资源调度策略失效。主机名的变化会导致nova-compute重启过程中误删所有虚拟机，这个问题的产生主要是因为Evacuate的清理机制。这个BUG在L版中得到修复。
- OpenStack的易用性还不够好
通过FUEL，可以实现OpenStack快速安装，但很多配置操作还需要命令行，离自动化部署一键交付还有距离。再例如OpenStack上用的比较广泛的CEPH分布式存储系统，目前还没有实现界面化的操作和配置。另外OpenStack还缺乏通用的基础版本。
使用OpenStack不会被厂商锁定，但OpenStack可下载的厂商定制版有20多个，客户的选择非常重要。
- 双活和容灾问题
大型企业对业务连续性要求比较高，重点核心业务有同城双活和异地容灾的需求。同城双活是指用户关键的业务系统同时在同城的两个数据中心运行，同时为用户提供服务， 当某个数据中心的应用系统出现问题时，有另一个数据中心的应用来持续。
异地容灾，顾名思义就是在不同的地域，构建一套或者多套相同的应用或者数据库，起到灾难后立刻接管的作用。我们看到OpenStack虽然也有单站点（Smaug+Cinder）和跨站点（Smaug+Swift）的备份和恢复方案，但离企业真正的业务双活和异地容灾还相距甚远。
再比如Tricircle实现的跨数据中心级联，还是需要Cinder依靠存储后端自己的能力去进行灾备，Tricircle本身只是作为一个转发中继，为用户找到正确的需要操作的站点，其本身无法实现跨数据中心的容灾功能，这和VMWARE的SRM是不同的。
我们可以看到，在功能的支持方面和具体的细节上，OpenStack与VMware还是有差距的，仍然需要不断进步才能做的更好。但OpenStack作为开源管理框架，设计初衷是好的。随着企业里OpenStack的使用和发展，必将推动和加速它的成熟。
最后就是运维自动化，在大规模云的运维场景下，需要将重复度高的工作，基于监控数据智能决策触发，实现无人参与的自动操作的运维能力，这部分还有待OpenStack发掘。
结语
建设企业私有云的过程不是一蹴而就的，而且这将是持续不断的投入过程，需要在实践中不断摸索前进。在下一个10年，将是云2.0时代，企业是云化的主力代表。展望未来，拥抱开源。在中国，在亚洲，在全球，OpenStack已经成为一种趋势，我们有理由相信在未来三年，OpenStack将成为企业去V首选。
