云平台选型的思考

Background

首先，我们要意识到，传统企业IT的高毛利率将不复存在。
其次，云计算的高毛利率也不会存在。

这是时代赋予云计算的使命。

目前可能很多超大规模的企业已经部署了开源或者自主研发的云平台。我们今年5月份左右开始筹建，主要是希望建设基础架构即服务层面的私有云平台， 希望能实现以下功能：
* 多租户的自服务平台；
* 具备详细的完善的计费模型；
* 具备完善的业务流程和审批流程；
* 具备逻辑网络的路由交换、防火墙、负载均衡等网络和安全功能；
* 具备可扩展的存储服务；
* 具备精细的部门权限管理；

目前我们的基础架构主要是基于vSphere 的虚拟化平台，包括主生产机房，同城灾备机房，以及测试环境。生产机房根据不同的业务部分，划分了不同的虚拟数据中心，有不同部门的管理员来管理。网络方面划分了不同的安全区域，部署了区域边界防火墙。存储方面主要是物理机的本地存储，还有部分SAN存储和大量的NAS存储。

然后我们主要进行了两款云平台的 POC测试，其一是VMware 最新推出的自动化云平台vRealize Automation ， 网络虚拟化平台NSX 以及 计费模块 vRealize Business。 其二是基于Ustack 的Openstack 平台，据介绍，我们POC环境部署的是2.0版本。测试的具体情况以后有机会再讲。背景先介绍到这里，下面从不同的维度聊聊今天的主题，云平台选型的思考。

Design

方案的设计是一个项目成功的关键所在。在架构设计之初，我们要考虑的因素有很多，包括产品的成熟程度，文档的完善度，部署和管理的难易程度，架构的灵活性，以及厂商或者社区的支持。

目前VMware的商业虚拟化平台和网络虚拟化平台相对比较成熟，VRA平台我们测试的过程中，发现了一些bug，常用的功能还是比较完善，部分自动化功能需要开发一些脚本。Openstack 社区各个分支项目较多，各个项目成熟度不一，但是版本迭代比较快，众多子项目开始走向成熟。

商业产品文档比较完善，VMware 有多语言的翻译版本，包括日积月累的KB，项目案例等等；Openstack 现在资料也比较多，包括Openstack 官方的文档， 还有Ubuntu 、Red Hat 、SUSE 、Mirantis 等等，目前社区活跃度相当高。

VMware 的商业平台，部署起来比较方面，通常都是OVA格式的虚拟机模板，开箱即用，ESXi 也可以通过Cobbler ， Auto Deploy 等方式进行自动部署，管理都是web 的方式，比较简单。Openstack 原生的平台部署起来相对比较复杂，然后众多企业做了很多工作来简化部署和管理，特别是 Mirantis，部署以及大大的简化。目前感觉 Openstack 排错还是有难度。

然后就是架构的灵活性。VMware 的生态相对封闭一些，主要是自己的产品，对这些产品线的把控能力要强。 Openstack 主要是众多大型IT企业主导的，开源的平台，组件的选择比较灵活，比如计算方面，KVM、Xen、ESXi 都可以支持。最后就是产品的支持，VMware 对大客户的支持能力还是蛮强的。为我们提供支持的Ustack，其服务支持能力还不太确定，这也是选型中的疑问。

Features

这篇主要介绍各类型组件的功能的对比。首先声明一下，VMware 的产品相对熟悉一些，Openstack 熟悉程度有限。不足的地方还请大家反馈。

软件定义的计算： vSphere 是虚拟化方面的霸主，具有完善的vMotion, HA, FT, DRS 等功能； Nova 也可以实现基于KVM的虚拟机的配置和管理，以及一些自动调度策略。我们在测试的过程中，目前KVM 的虚拟机CPU 和内存的热添加支持还比较差。

软件定义的网络： VMware 收购的Nicira， 即目前的NSX， 功能比较丰富，包括丰富的L2-L7的功能，主要用于微分段、网络自动化、业务连续性等场景，目前也是业内比较领先的平台。Openstack 方案主要是Neutron，主要实现了逻辑网络的路由、交换等等功能。目前社区还有Open vSwitch 项目，比较值得关注。

软件定义存储： VMware 主推是VSAN 平台，VSAN主要是将计算集群中的本地存储抽象层一个虚拟的存储资源池，通过SSD盘进行缓存加速，来实现虚拟的LUN，供给虚拟机使用。 Openstack 社区方案比较丰富，有业内领先有ceph， ceph 现在Red Hat 和 SUSE 都有商业的支持，可见其火爆程度。

云管理和调度平台： VRA 功能基本满足需求，但是我们测试的版本，页面设计比较复杂，概念比较繁琐。Openstack 管理平台比较轻量级，跟很多公有云平台比较类似，也获得了很多管理员的青睐。

监控： VMware 是通过VRO平台来进行容量管理、监控以及性能管理，但是目前看来VRA 还不能直接整合VRO，如要登录到VRO平台去查看资源的使用率。Openstack 这方面做的比较好， 完美的整合到一起，租户可以直观的看到资源的使用情况。

Use Cases

主要谈谈云平台的使用场景。目前我们划分为 传统的应用架构，Cloud-Ready 的应用架构，以及 Cloud Native 架构。

传统的应用主要是三层架构，Web层，APP层，DB层。传统的应用架构，比较适合IOE这种纵向扩展的架构。这类应用比较对基础架构的RAS特性要求高，通过PowerHA 或者 RHCS 等方式进行高可用保护。这类应用迁移到云平台，VMware 应该可以通过 U2VL、HA 、RDP 等方式进行更好的支持。

Cloud-Ready 架构的应用，可以不同调整，直接部署到公有云或者私有云。IBM 这里有篇文章介绍构建云应用架构的9条规则。
1） Don’t code your application directly to a specific topology. 这里强调，应用架构不应该动态扩展说影响，构建通用的无状态的服务。
2） Don’t assume the local file system is permanent. 将临时的信息保存到远端的SQL或者NoSQL，而不是本地文件系统。
3） Don’t keep session state in your application. 不要再应用中保持会话状态，可以将其保存到分布式缓存集群中
4） Don’t log to the file system. 不要将日志输出到本地。可以通过Apache Flume 或者Splunk来进行处理。
5） Don’t assume any specific infrastructure dependency. 不依赖任何特定的基础服务， 最好是通过服务总线或者负载均衡器来解决业务间依赖关系
6） Don’t use infrastructure APIs from within your application. 不要再应用内部调用基础架构的API， 应用架构应该更着眼于解决商业问题，而不是基础架构。
7） Don’t use obscure protocols. 不使用晦涩的协议，尽可能的使用标准协议，类似REST，以及异步协议
8） Don’t rely on OS-specific features. 不要依赖特殊的OS特性
9） Don’t manually install your application. 尽可能的保存应用部署的简单，使用Chef, Puppet 类似的平台进行自动部署。

接下来介绍一下 Cloud Native 应用架构的12要素，The Twelve-Factor APP 源自 https://12factor.net/。从而理解Cloud Native 应用架构的特点：
1）从一个代码库部署到多个环境
2）依赖管理是声明式的
3）配置信息保存在环境中
4）将后台服务视为附加的资源
5）区分构建、发布和运行阶段
6）作为无状态进程运行
7）通过端口绑定对外暴露服务
8）通过添加无状态进程实现横向扩展
9）快速地启动，优雅地关停
10）开发、预发布和生产环境运行同样的应用和依赖配置
11）日志输出到标准输出，方便日志聚合和事件响应
12）临时任务作为短时进程运行

以上主要介绍了不同类型应用架构的特点，目前我认为VMware 能更好的支持传统应用，包括Oracle RAC。 而Openstack 跟适应这种Cloud Native 应用。

Value

通常方案设计之前，我们往往需要考虑ROI。 这里我们主要是从以下4个方面去考虑，第一是 License和服务成本，第二是员工的学习成本，第三是人力成本，第四是 架构扩容的成本。前面几项很容易理解，最后可容的成本不可小觑。很多商业平台，初始平台价格较低，但是扩展起来，成本线程增长，甚至更高，特别是纵向扩展的应用。开源的方案扩展起来主要是硬件的成本，软件成本增长会比较低。

没有完美的架构，没有完美的方案。只有根据业务的需求，不断的去完善和迭代我们的云基础架构。