如果一家企业对外提供OpenStack私有云服务，那么拥有一个OpenStack企业发行版似乎是必须的。
因为，1）在行外人看来，这标志着该企业的OpenStack的研发和维护能力足够成熟；2）增加本公司的品牌和客户对本公司的认可，而不仅仅是对OpenStack的认可。
然而，随着OpenStack开源社区的发展，从开源社区里下载代码，进行简单的修改再加上本公司的商标，似乎一个OpenStack企业发行版就面世了。这也是为什么众多企业有自己的发行版的原因。
但是，如何结合本企业的特点，生成一个有着比原生OpenStack版本更好的能力，有自己的独有特性的版本，则不是一件容易的事情。
那么如何做好一个有特色的OpenStack 企业发行版，建议从以下角度进行考虑：
1) Installation
整个安装的过程包括从客户拿到安装package，准备好物理机到客户得到一个可用的OpenStack环境，客户可以在里面创建虚拟机，运行他的应用。
进行Installer的设计过程可以从如下方面进行考虑：
- 提供两种Option：向导安装（GuidedInstallation）和无人值守的安装方式；
- 进行环境的事前检查，以减少事后失败的机会；
- 缩短安装的时间和需要用户操作的部署；
- 及时地进度更新；
- 失败时详细的log以及建议的操作；
- 安装完成后Sanity check；
- 多site云的安装以及监控管理。
目前，OpenStack社区针对Installation的Project主要要三个：TripleO, Fuel 和Kolla。
现在很多公司的企业级release中很多都是基于TripleO或者Fuel改进创建的installer。比如，Red Hat OpenStack Platform基本放弃了原来的packstack，而采用了基于TripleO的Director。
但Fuel原本就是Mirantis的项目，他们的OpenStack当然是基于Fuel；目前中国的OpenStack新贵EasyStack的Roller应该也是基于Fuel。Kolla是近两年新兴的Project，其基本思想是服务的container化。然而当前来看，该项目还不够成熟，在真正的生产环境中很少使用。
2) UI
原生的OpenStack的GUI当属Horizon，但是可以从以下几个方面对Horizon做改善甚至二次开发：
- 按照用户的使用场景来划分项目，而不是每个project有自己独立的页面；
- 简化操作项目和参数配置，以便对非技术用户望更友好，对于复杂操作，可以增加Advanced Configuration，并对初级用户屏蔽；
- 减少OpenStack术语的使用；
- Compute Instance，网络以及存储的动态拓扑等。
一个用户友好同时又有企业本身特色的用户界面胜过售前人员的千言万语。
3) Quality harden
OpenStack的代码虽然我们可以免费获得，但是OpenStack里的bug并没有承诺会及时地修改；而且作为一个企业级产品，用户肯定希望得到一个稳定而尽量少bug的release。
所以，结合release的功能，对OpenStack进行针对性的测试不可或缺。可以从以下几个方面设计case并进行测试：
功能测试，
系统测试，
性能测试，
可以用Rally、Destructive、Negative、Limitation兼容性
另外,OpenStack社区的测试项目也应该尽可能的leverage，以减少工作量。同时，还需要关注安全方面的问题，可升级性以及高可用性。
很多公司的Release可能会包含一些社区没有defect的修改，这也是企业级release的卖点之一。但是不要忘记，发现defect以及修改defect的数目可能成为用户衡量vendor的一个重要的方面。因此，公司需要把握好这个tradeoff。
4) 功能增强
社区的开发更多的关注功能特性，而对企业级产品需要的特性，比如安全，高可用，高可靠性等方面关注不足，企业可以对这些方面进行增强。
5) “杀手级”特性
直接用开源代码生成的产品功能几乎完全相同，因此，如何利用对开源OpenStack的理解和掌握，结合本企业的业务特长以及已有的产品，开发出杀手级的特性，是每个OpenStack企业发行版的产品经理应该仔细考虑的问题。
6) 参考架构
经过测试的参考架构对客户来讲具有非常重要的意义，因为这将提升用户部署相似架构的信心。
在这方面，Red Hat提供了一个很好的榜样：General-Purpose Architecture, Compute-Focused Architecture, DataAnalytics Architecture, High-Performance Database Architecture, Cloud Storageand Backup Architecture, 和Large-Scale Web Application Architecture.
7) Day-2 解决方案
规划和部署一个OpenStack环境固然是一件不小的工作，但是并非部署完成就万事大吉。后面的运维工作对于保障私有云或公有云的正常工作至关重要，因此，一个良好的监控及Log集中管理方案必不可少。
目前来看，典型监控方案是利用Nagios或Zabbix来监控物理机器以及存储和网络，但是也有更灵巧化的开源方案，比如，在可用性方面采用Sensu RabbitMQ Uchiwa；在性能方面采用Collectd Graphite whisperdb Grafana；在Log的集中管理方面采用Fluentd ElasticSearch Kibana。
8) 安全
安全在IT行业是个永远也逃避不掉的话题。在云计算的环境下，传统的安全威胁依然存在：SQL injection, DDOS攻击，病毒，恶意软件，木马，僵尸网络，身份入侵，暴力破解，以及网络，应用本身的漏洞，当然还有现在流行的APT攻击。
同时，云计算本身又扩大了安全攻击面，导入了新的安全威胁：
- 虚拟化和容器带来的安全问题：虚拟机边界缺乏保护，虚拟机逃逸，隐蔽信道，数据残留，流量不可见，容器共用内核；
- SDN带来的安全问题：控制器安全，API接口的安全，协议交互的安全以及数据转发面的安全。
在安全方面除了对OpenStack本身进行代码以及配置文件的静态和动态的检查以确保没有安全漏洞之外，还有如下几个方面：1）对虚拟机进行安全加固；2）对SDN网络进行构建虚拟防火墙，或者采取硬件防火墙。
构建一个OpenStack企业发行版是件可大可小的事情。三四个人的小团队把Horizon的界面进行修改，加上企业的标志，可成为一个OpenStack发行版；把OpenStack的代码进行测试和加固，按上面的7个方面进行增强，则需要更多的人力和更长的时间；完全拥抱OpenStack upstream代码是一种方式，比如Mirantis；也有企业部分采用OpenStack的代码再进行二次开发集成原有的解决方案。
归根结底，一切取决于企业的商业目标。
END
