企业级私有云环境下的OpenStack核心技术需求和分析
企业级私有云环境下的核心技术需求有哪些？
- 高I/O性能：支持大型企业级应用，以及降低CapEx（为满足特定需求，可以投入更少的计算资源）。
- 功能简单、界面直观：让企业IT团队能够在短时间内掌握基本维护技巧，降低OpEx。
- 自动化运维：部署、扩容、监控、告警、自动伸缩，都能通过基本的UI操作全部完成，降低OpEx。
那么要满足这样的核心需求，OpenStack-Powered产品该如何设计？
1. 界面交互
从用户角度看，用户第一眼看到的是什么？界面！所以界面直观，让用户一眼看到就知道怎么用。
用户怎么样才能知道如何使用？VMware和Microsoft已经培养好了用户习惯，我们在界面交互设计时只要模仿即可，
模仿主流产品的界面交互，让用户能够不用培训就能入手，创建VM，登录VM，安装应用，参看和配置监控和告警。
2. 功能简单
如果功能特别复杂，就会导致界面复杂，一层层菜单向下走，而不是一个平面操作，界面交互就不可能简洁。
所以，界面直观的一个引申，就是用户界面的功能要简单，特别是针对OpenStack，
如果实在无法化简，有一个实践可以参考，就是按照用户常用功能、高级功能，
在用户登录后，菜单栏分开成两个Panel，Simple Operations和Advanced Functions。
Simple Operations：指代正常使用的虚拟化、必须要用到的功能。
Advanced Functions：指代所有可选的云的高级功能，包括SDN、Backup、Alarming、Auto-Scaling。
3. 自动化运维
既然是自动化，则用户只要简单配置，甚至不需要配置，就可以达到一个默认大多数用户都能接受的效果。
4. 虚拟化管理模块如何满足呢？
大多数功能都是VM管理，所以不需要化简。
但如果优化的话，尽量在界面上提供能够一步走到底的Batch Operation，而不是要让用户一个个点开操作。
5. SDN模块如何满足需求？
只要能实现一个稳定的二层控制面，SDN的任务其实就完成了。由于每个客户的物理网络环境和对网络需求
确实千差万别，需要定制，但实际上选择面也不是多到难以抉择。
（1）Provider Network
如果客户只是最为简单的虚拟化管理需求，那么将Neutron虚拟网络直接挂接到物理网络上，实现一个Flat网络即可。
如果客户需要网络隔离，但是也有Admin统一纳管，那么还是使用该技术，指定多个ProviderNet，实现一个带物理隔离的Flat网络。
（2）Multi-tenancy Network Isolation
如果客户方需要对多个部门实现网络隔离，并且需要能够自定义网络，那么就需要用到VLAN。
如果客户方规模大到VLAN无法承载，才要使用VxLAN。
如果客户方有多个DC，并且二层打通，那么为了资源最大化利用，也要使用VxLAN。
（3）DHCP-Agent
如果允许VM直接配置静态IP，则无需使用DHCP-Agent。
如果使用Provider Network，那么可以直接在该物理网络上，启动外部DHCP Server。
如果需要自定义网络，则需要DHCP-Agent，目前都能支持Failover和A/A。
（4）L3-Agent
没事，别找抽，企业私有云一般都不会有NAT的需求，这个是公有云的需求。
没见过哪个用VMware虚机的企业在内部运维还去配置两层IP。
实在客户需要NAT，那么优先在物理网络的三层设备上做。
实在要通过SDN运行NAT，则在技术支持条件好的环境下，优先选择第三方企业级SDN解决方案，比如Midonet、Centec等。
然后再是DVR（前提是启动L3-Agent HA），最后是DragonFlow（如果其L3 Controller Agent支持HA，则DragonFlow优先于DVR）。
（5）LBaaS-Agent
这个是SPOF，看客户需求部署。
（6）VPNaaS-Agent
这个是SPOF，看客户需求部署。
（7）FWaaS
这个是L3-Agent的Extension。
（8）性能
网络高IO也是核心需求，所以在数据包的转发面上，、
尽量减少虚拟化，尽量减少Kernel协议栈的干预。
（9）运维复杂度
基于Flow的转发面的使用，需要引入额外运维的开销和调试复杂度，比如DVR，Dragonflow等。
6. 存储模块如何满足需求？
数据冗余，然后就是高I/O，高I/O，高I/O。否则很多企业级应用（IO密集型）根本没办法跑。
所谓IO密集型应用，主要指代应用过程中产生大量用户端的实时交易，交易越密集，IO要求越高。
7. 计算（虚拟化技术）模块如何满足需求？
计算模块实际上贯穿是一个最为核心的模块，无论网络I/O、存储I/O，在虚拟化层面上，都要做足优化。
包括CPU多核架构、内存、设备驱动层面。但是这些优化都应该由自动化部署系统去完成，不需要体现在用户界面上。
至于是否在产品中直接使用容器虚拟化，则是另一个话题。因为容器虚拟化技术本身简单，但背后需要重构一个App-Centric的
体系，并且企业IT部门也要有一个完全不同的DevOps面貌来支撑这个体系，这个不是短时间内可以落地的。