平安云诞生于平安集团的科技大本营，多年的金融IT经验积累使得平安云对金融行业架构规范，金融业务系统流量特征及安全合规性等均有独到的见解。从13年底立项以来，平安金融云一直尽可能走开源和自研结合的路线，自主研发了IaaS层的全套产品线，为金融行业客户提供可靠、弹性、高效、集约的基础架构层服务。

目前金融云平台已涵盖平安集团90% 以上的业务公司，支撑60% 的业务系统投产，并延伸至外部直销银行及金融机构，承载过亿的互联网金融用户。平安金融云将持续推动集团3.0“大金融资产+ 大医疗健康”战略更快发展，打造金融平台业务，占领数据、生态阵地，为集团互联网、业务云、生态圈的爆发式增长保驾护航。在“2016年金融信息化10件大事”评选中，平安云排名12，在参选的金融云平台里排名第一。

所有的云服务中，都会涉及到三项台柱技术领域：计算、存储、网络。本文将介绍平安云构建过程中在这三大技术所做的实践，希望对尝试搭建云服务的读者有借鉴意义。

图1 平安云平台级总体架构

如图1，平安云后台实现计算、存储、网络的资源管理、以及对用户的交付服务。

计算服务

当下的计算机领域呈现出人云亦云的现象，但最出名的还是以AWS、Azure、阿里云为代表的云计算服务，这说明计算是云里面最重要的服务，从3A的营收占比来看，也的确是这么回事。

以AWS为例，最初负责主机运维的工作人员出于提高资源利用率和额外创收考虑，提议将每年为黑色星期五准备的大规模资源在平日时间段以计算服务的形式出售，由此，云以计算服务开的头。

平安云在构建过程中实际上也是重复了这一过程，计算云化技术的决策选型是创始团队要攻克的第一关，而绝则取决于现实：一方面要支持日益持重的KVM虚拟化，另一方面需兼容过去已大量投产的VMware虚拟化。这两个目标具备很高的实线价值——即支持业务无感知从传统VMware环境切换到云管理的VMware，又使得一些创新的互联网应用在没有包袱的背景下自由使用KVM。

基于以上考虑，我们主要调研了OpenStack与CloudStack，其余的方案实现功能相似，社区热度相差太大而不予考虑。最终我们出于以下因素选择了CloudStack

1.成熟度：决策期间，当时OpenStack刚开始发展，虽然社区火热但成熟度较低，难以满足早日平台搭建落地的现实目标；CloudStack曾是cloud.com的商用版本，成熟度相对较好，并且已有多个成熟的客户案例可借鉴；

2.普及性：金融系统内业务系统通常以Java为开发语言，CloudStack上手容易

3.企业特性：CloudStack内部架构逻辑更符合企业应用系统设计，相对于分布式组件化的OpenStack，部署CloudStack的方式更适合当时的平安集团IT特性；

4.技术局限性：团队成员熟悉计算和存储，网络方面的需求没有考虑太深

CloudStack的架构比较小巧紧凑，容易部署，但也有不尽人意的方面，其缺点主要在于对网络功能的支持不够丰富、灵活。这里我们有独特的做法：CloudStack相当于完成OpenStack Nova的功能，只用来进行计算虚拟化资源管理。为了达到对网络功能的支持效果，我们对CloudStack做了二次开发，增加了一个和OpenStack Neutron对接的Plugin，使Neutron能够感知到虚拟机的生命周期。

图2 计算服务CloudStack架构图

如图2，CloudStack的Network功能被极度的弱化，工作主要是管理计算所需的IP资源、VLAN等，编排物理网络的工作交给了Neutron。

存储服务

存储和计算不分家，平安云存储服务根据技术和场景的演变解决方案也变得丰富多样：

1.本地盘和高性能本地盘：提供高IO，同时缩小存储故障域；

2.SAN和NAS：传统方案，支持计算HA；

3.本地盘高可用和VSAN等超融合方案：本地盘方案的升级，在高IO同时提供HA；

4.Ceph提供块存储和对象存储：块存储作为SAN和NAS的替代方案，对象存储可以提供用户数据备份服务。

图3 块存储服务架构图

如图3，块存储服务的交付实际上是比较简单的，通过CloudStack对接到每个Hypervisor的CS-Agent或者vCenter，将VM的磁盘IO和后端的Ceph、NAS、本地盘、SAN等存储资源池挂接。存储资源池配给通常比较充足，资源监控和管理通过额外的运维系统完成。

图4 使用Ceph提供块、文件、对象存储服务

Ceph是目前最流行的软件定义存储的开源解决方案，在云环境的存储服务中提供了非常好的可定制性和可扩展性。作为统一存储，Ceph在最底层原生的RADOS对象存储的基础上通过模块化的方式分别提供的块存储（RBD）, 对象存储（RGW）和文件存储（CephFS）。为了把原生的开源Ceph存储应用到不同的业务场景，我们在性能优化和部署，配置，故障修复方面做了大量的研究和实践。基于Ceph开源社区良好的发展趋势，Ceph将会是一个很好的兼顾性能、成本、扩展性的云存储解决方案。

网络服务

相对于计算与存储，网络是一门单独的领域。通常懂计算的都会了解一些存储，懂存储的也会知道一些计算，但是都会对网络感到陌生，原因也很简单，计算中数据落地涉及到存储，存储也有Server Storage，操作对象基本上是PC Server、Linux，而网络人员操作对象则是各种厂家的Switch、Firewall、Router和LB，操作对象不同，且都是非常成熟的领域，因此知识、技能很难与计算、存储融合。

网络在云中最核心的作用有2个：

提供计算和存储互联的高速公路，这个是物理网络实现的功能，不管是云还是传统基础架构，网络都实现了这些需求；

提供租户的虚拟网络，通常是在物理网络中通过虚拟化实现的，这是云独有的需求，在网络界术语中，在物理网络中为每个租户提供虚拟网络的技术称为网络虚拟化（Network Virtualization）简称NV，是当今网络界最热的要点，不同云服务商的NV方案大相径庭。

大多数熟知的云都会最初把NV做到Linux内部，而不会交给专门的网络去实现，这也是对上述理论的验证。NV在云计算发展过程中，也是最为缓慢的，但可以看到各大公有云都在使用SDN和NFV来补齐这部分短板。平安云的起步较晚，可以利用后发优势，从一开始就考虑物理网络上实现NV，原因比较简单，物理网络设备是连接大量服务器的专用设备，物理网络设备供应商不会对NV视而不见，截止至今日，物理网络设备NV技术已经相对成熟，将NV从主机剥离出来，也有利于降低主机技术集成复杂度，提升运维效率，平安云网络的优势主要是通过对方案的主导性对物理网络设备厂家研发力量进行整合，而不是一味在主机上单干。

图5 平安云网络服务模型

平安云把网络虚拟化分为Fabric服务、NF（网络功能）、增值服务3部分：

Fabric，实现虚拟网络中的租户Switch和Router功能，网络人士称之为L2和L3功能，租户可以在Fabric服务中管理子网、租户路由表等功能，从而实现Fabric内租户计算节点实现互访，控制边界路由等功能，该服务在网络中属于低频操作类，租户只有在创建时需要关心，因此这部分也是租户比较陌生的；

NF，实现虚拟网络的租户VPN、访问控制、NAT和LB 等功能，对应网络人士熟知的L3、L4和L7功能，这些服务在网络中属于中高频操作类，租户比较熟悉；

增值服务，比如CDN、大流量高防、域名管理、互联网流量分析、互联网质量探测、安全专线等，这些服务涵盖低中高频类，租户比较熟悉。

为了让这三项服务能够高效、科学地编排，平安云使用了可扩展性强的Neutron，并依托Neutron构建了统一编排平台Network Service Platform（NSP），同时对Fabric、NF和增值服务进行管理。

图6 基于Neutron的NSP平台架构

NSP平台可以将来自不同厂家的网络设备、第三方网络服务都通过容易扩展的Service Plugin来对接，而核心NSP维护的是抽象网络服务数据，编排对接Portal和CloudStack都使用这一层抽象的网络模型。

总结

除了网络之外，计算和存储都依托比较成熟的方案搭建，平安云收获最宝贵的是架构治理和业务入云的经验，这种务实的战略是平安云能够在过去2年中迅速成长的关键。“架构自主、但不做大的修改，以用为先”，对于很多企业来说，也是可以借鉴的。

网络比较特殊，在很多云计算团队中，网络都是一个比较边缘化的领域，因为日常面对的硬件和服务器实在是过于不同，Neutron作为计算领域的专家提出的模型，并不一定是真实网络的抽象，各个网络设备供应商在面对OpenStack浪潮中，更多地是遵从Neutron，而并没有发展Neutron，有幸平安云在项目早期就很重视网络服务，得以组建开发团队基于Neutron做了很多务实的拓展。使NSP能够在不到1年的时间就能够完成开发并且上线。