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