巩小东小黑羊JoinWings2017-03-12

什么是云计算?维基百科是这样解释的,“云计算是基于网络提供的按需的、共享的、可配置的计算以及其他资源”

图表1是云计算的“例行”组成,IaaS将计算、网络、存储抽象后提供资源级产品,PaaS将资源操作封装后提供应用级产品,SaaS将1个或者多个应用封装后提供服务产品。

图表1 云计算构成

然而, 笔者认为这不是“什么是云计算”的答案,而是“云计算是什么样子”的答案。通俗一点,这个回答方式类似,问“中华武学是什么”,答“中华武学是咏春拳”。

那云计算的“”是什么,笔者会以当前云计算的领头羊AWS的成功实践为依据,尝试回答这个问题。

1

数据中心与网络设计

在1999年HighPerformance Transaction Systems Hybrid Systems conference 中一篇题目为“Fault Avoidance vs. Fault Tolerance: TestingDoesn’t Scale”的论文观点认为:软件设计应该可以容错,而不是努力的通过大量测试而避免错误。因为软件的复杂度越来越高,代码量越来越大,会导致软件质量下降。而模块化设计不能减少复杂度,同时测试也覆盖不到所有复杂的,相互关联的特性。

在2009年 SIGCOMComputer Communications Review 中另外一篇 “The Cost of a Cloud: Research Problems in DataCenter Networks”  的论文,提出两种建设数据中心的思路。一种是建设10万台+的超大规模数据中心,有更好的性价比,但会有资源碎片等副作用。另外一种是围绕着最终用户建立一系列小型数据中心,会有好的访问延时,但数据中心之间的互联会十分昂贵。

接下来我们看AWS是怎么做的……

AWS数据中心的设计实践

图表 2 AWS数据中心概览

从图表2中的黄色标记可以看出,其围绕着客户在全球建立了16个资源隔离的Region,每个Region包含2~3个Availability Zone(可用区)。Availability Zone为一个数据中心群,包含1~6个6万+规模的超大数据中心。Availability Zone间距离通常为30~100公里,以保证风火水电的隔离。

图表 3 AWS实例规格统计

结合图表3,AWS的金牌合作伙伴RightScale发布的,关于其代维的AWS云主机规格统计饼图,我们可以看到1核~2核规格的云主机是主流,占据了近70%的比例。按照常规AWS物理主机的2个Intel Xeon E5 12 core的配置来看,平均每个物理机上应该承载12个左右的云主机数量。而6万台的数据中心应该包含72万台云主机。按照每Availability Zone平均包含3个数据中心算,AWS在每个Region拥有可高质量互通的7.5个6万+的数据中心群,其中可部署45万+的物理机,承载540万+的云主机,这是个非常巨型的解决方案。

AWS数据中心间的网络设计实践

先从图表4看其Region间互联设计,其通过各个Region自有的BGP AS域构建了一个100Gb带宽的环球互联网络,以支撑其全球级服务管理面互通,和AWS BGP AS内的公网IP之间互通流量。相对于公共互联网,有低延时高可用的优势。但对于每个Region内近540万+云主机来说,每个云主机的平均带宽不到24bps。

 

图表 4 Region间骨干网(单击放大)

 

再从图表5看其Region内网络互联设计。Region内的各个数据中心,通过两个独立的transit节点接入上面讲的Region间骨干网,以保证链路冗余性。Region内的2~3个AZ间保证全互连,互联链路带宽达到25Tbps。按照之前推论的AZ内包含180万+个云主机计算,每个云主机平均有14Mbps的带宽。每个AZ内的1~6个数据中心之间保证全互联,互联链路达到102Tbps,平均每个云主机拥有178Mbps的链路带宽。

 

图表 5 AZ内网络连接

 

从AWS的数据中心以及网络设计实践看,与前面两篇论文的理论是一致的。在Fault Avoidance上,AWS提出了Region与AvailabilityZone的概念,帮助客户构建高可用应用。Region为完全隔离的两个资源池,而Availability Zone是可互通的、但风火水电隔离的资源池。客户将服务部署到不同的Region与Availability Zone中,使用负载分担实现Active-Active高可用,以避免可能的单点故障。Availability Zone在其悉尼Region故障中经过了检验,在1个AZ完全停止服务时,另外一个AZ可以提供完整的服务,避免客户应用完全不可服务。

在数据中心设计上 ,AWS选择了两种方案的结合。按照地理位置建立独立的、45万+物理机的超大规模数据中心集群,既保证了规模效应的高性价比,又实现了最终客户良好的网络体验。独立的数据中心集群间只保持较小的互联带宽,避免大范围网络互联的高投资。数据中心集群内,在数据中心间、以及数据中心内设计了很高的互联带宽,实现资源池的统一SLA体验。

2

云主机设计

在2008年的 InternationalConference on Data Engineering,一篇名为 “cloud computing imperatives”  的论文提出,大型的数据中心比中型数据中心可以提供7.1倍的网络性价比、5.7倍的存储性价比、以及高达15.7倍的管理成本性价比。同时在计算能力成本日益下降的背景下,发展大型的数据中心,才能解决数据传输高延时与能耗不足的基础设施瓶颈。

AWS云主机网络设计实践

图表 6数据中心内网络演进

从图表6看,AWS的数据中心内网络带宽选择领先业界近3年。在2010年的cg1实例上明确使用10Gb网络,到2015年的x1实例上明确使用25Gb的网络。更高的数据中心内网络带宽,不仅给每个云主机提供更多的带宽资源,最重要的会降低路径上所有网络设备的队列深度,从而得到更低的东西向流量网络延时。

AWS在2011年左右引入了10Gb的智能网卡(驱动兼容Intel的ixgbevf,生产厂商不详),并对所有规格的云主机规格开放,提供普通vif与SRIOV VF两种接口(如图表7)。随后在2015年随x1机型推出了25Gb的智能网卡(使用自有ENA驱动,收购的annapurna设计)。

图表 7智能网卡

智能网卡承担了原本物理机内虚拟交换机的路由、contrack匹配、ACL过滤、VTEP查表、MAC代答、tunnel建立等工作负载,大幅度降低了网络延时,提高了网络吞吐量。同时硬件实现了虚拟机粒度的、严格的带宽以及五元组流的QoS,保证基本所有类型以及规格的云主机都有稳定可预测的网络性能。

AWS的云主机存储设计实践

图表 8云主机存储演进

从图表8看,AWS使用存储介质的策略也相对比业界激进,从2007年开始的c1实例使用了SATA口的SSD,2015年在x1实例上使用了PCIE SSD(在2007年~2015年之间也在少量机型上使用了PCIE SSD,应该是维护困难放弃了,x1实例因为SATA SSD的IOPS能力不够),在2016年底的p2实例上正式推出了NVMe SSD。比业界的选择整体快1~4年。当前NVMe SSD的使用上时间点接近,这个是因为存储技术发展比网络慢很多。

虽然大家都使用NVMe SSD作为存储介质,但从下表可以看出,AWS最新推出的i3实例的物理机挂载8个1.9T的NVMe盘,可以同时承载32个i3.large规格的实例,并且可以保证这些实例的存储SLA。笔者推测推测其在i3实例物理机上使用了类似JBOF中的NVMe controller,将云主机的最多32个NVMe SSD盘的后端卸载到该controller卡上。同时NVMe controller需要对挂载的8个NVMe SSD进行了条带化,从而实现1个NVMe盘同时提供给两个云主机使用,而且有严格的SLA保证。

图表 9 AWS I3实例设计

从AWS在云主机设计的实践看,其完全遵守了前面论文的理论,通过大型数据中心的规模效应来提高资源池的品质。通过全网使用更高带宽的网络技术,以及主机端的智能网卡,实现了比业界大大降低的云主机网络时延。比业界更早的使用更高性能的存储介质,并且通过新的存储卸载技术,大幅度的降低了存储时延,并且提高了存储密度。

从前面图表3中RightScale的统计图我们可以看出,AWS环境中80%以上的实例是小规格的。越来越多的客户倾向与开发微服务架构的应用,通过简单的高扩展的应用架构代替以往复杂的应用架构。AWS的云主机设计策略很明显,在保证整个资源池的计算、网络、存储性能优势以外,还要保证有能力提供足够小的资源颗粒粒度,同时保证这些颗粒有SLA的保证。AWS曾经有过cc1、cc2等大颗粒实例,但均淘汰了

从通过智能网卡实现了高密度虚拟网卡,以及精确的QoS控制,保证云主机的网络质量可预测。到使用新的存储卸载技术来提供高密度的虚拟NVMe设备,以及精确的QoS控制,保证云主机的存储质量可预测。我们看到了其为客户提供细粒度资源的思路。

 

图表 10 AWS实例设计目标(左右滑动)

3

云服务设计

在2002年的IEEEInternational Conference on Data Engineering,名为“Key Challenges inInformation Processing”的论文提出了大规模应用运营的几个挑战。软件和人为因素是故障的最大原因,而不是硬件设备本身的故障。安全开销只有0.0025%,但经常会发生数据丢失、应用被病毒感染、以及不安全的系统配置。开发者更热衷于优化应用局部性能,而不是提高应用的扩展性,但扩展性好的其实简单架构的应用,运行在不需要人员运维的大型集群上效果会更好。

在2009年的StanfordClean Slate CTO Summit Invited Talk,上,一篇名为“Data CenterNetworks Are in my Way”的论文中提出,传统的网络设备没有像x86服务器架构一样有开放的、标准的架构。运营商无法使用一套OSS系统,对局点内的各类设备进行管理,需要管理员手工进行维护。

AWS云主机服务设计实践

AWS提供了通用云主机、高性能云主机、GPU加速云主机、FPGA加速云主机、存储优化云主机、内存优化云主机等多种云主机规格。用户可以通过其运行一套包含接入、计算、数据落地的完整的应用堆栈,同时适应普通计算、HPC、DNN等各种场景。所有的云主机服务均通过线上console或者API开通,客户选择好相应的云主机规格后,即买即用,用完即走。不需要关心资源集群的运维、安全加固、设备优化等。当然这个在今天很容易理解,但其在2006年,机房托管才是主流商业模式的时候,选择这种超前的商业模式,是需要足够的决策勇气。

 

图表 11 AWS云主机服务(单击放大)

AWS在虚拟私有网络的设计实践

VPC在前一段时间炒的火热,各个大厂均出来讲自己的实现以及优势。由于热点起源于租户云主机隔离,所以VPC的讨论也局限到隔离的特性。就笔者对AWS的理解,其提出VPC的概念主要目的是为了租户自助管理自己云网络中的各个网元,完成东西、南北向网络流量的配置。

租户通过统一的console或者API自助配置自己网络中的L3交换机,控制流量的路由;

配置网络中的虚拟防火墙,以及交换机ACL,实现流量的安全隔离;

自助选择SNAT网关、公网网关、VPN网关、专线网关等流量流出VPC的方式。

这些特性,极大的简化了租户的运维负担。

 

图表 12 AWS VPC服务设计(单击放大)

从AWS的云服务设计实践上看,其使用API对客户提供资源服务的思路与这两篇论文思路一致。其修建大规模的数据中心,并优化数据中心的运维质量与成本、提高资源使用效率、提高整体的安全性、实现数据中心的高扩展性。最终通过统一的API与console作为界面,使用自助的云服务屏蔽底层硬件差异,最终将数据中心能力提供给客户。

4

云计算到底是什么

首先来一段 Twilio CEO Jeff Lawson 的定义,笔者认为非常有道理。

Jeff认为在计算领域曾经有两个浪潮,第一个浪潮是以Oracle为代表的公司统治。在这个阶段,是企业的IT部门负责购买软件然后部署管理,以供企业的员工使用。第二个浪潮是以Saleforce为代表的公司统治,企业的销售、营销或者财务部门自己决定购买软件服务,由IT部门帮助管理。目前进入了第三个浪潮时代,这个浪潮是由AWS所统治的。软件企业可以跳过IT部门和业务部门,把他们的技术直接卖给在企业中负责构建应用程序的程序员。

 

图表 13 研发模式演进

 

Jeff从软件开发者的角度生动的描述了软件行业的演进历程,在功能交付要求越来越快的背景下,由于软件功能的堆积,软件的体积越来越大,复杂度越来越高,同时软件的质量也越来越难以保证。如图表13,软件开发模式开始从传统的瀑布流模式转化为今天的微服务模式。复杂的单体式软件,拆解为一组简单但高扩展服务。大规模的开发团队,拆解为灵活独立的开发小组。长达半年到1年的交付周期,分解为以周为单位的快速迭代。彻底的D/O分离的协助模式,由于软件的微服务化,软件的业务运维与开发团队融合,形成了新的DevOps模式。

开发模式的演进,对基础设施的要求也在变化。从使用几台高配的服务器部署业务,变化为需要1个,甚至数个低配集群部署,实现各个模块的资源隔离,以及整个业务的高可用。对于有自建数据中心的大型公司来说,可能不是问题,但对于中小型公司来说,这可能是不可能的任务。尤其是对于一些to C的业务,增长曲线无法估计,提前3~5年来规划基础设施的建设,在业务前景还不明朗的时候可能是个笑话。

返回主线,AWS是如何站在第三次计算领域的浪潮之巅呢?

▶AWS在最终客户的周边修建了大型数据中心群,并保证之间的互联质量以及高可用。

▶通过其数据中心的巨型体量,使用各种最新的技术提高了资源的网络、存储效率,解决了功耗问题,同时降低了运维、安全等运营成本。

▶为满足客户的不同计算负载,引入高性能计算、GPU、FPGA等技术,并通过小颗粒的资源粒度,通过统一、可编程的云服务模式提供给客户。

▶最后为了完成客户迁移的工作,提供了一系列搬迁工具、垂直解决方案、服务部署工具、适应新基础设施架构的中间件。

当然这些到现在,也许是每个云计算工程师的常识,但在2006年AWS开始提供云计算服务的时间点,仅有学术界的理论,工程上仍然是无人区。AWS在云计算的巨额投入,这是一场有革命性的、勇敢的赌博。最终在2015年,才最终证明了这次技术革命是成功的。

就此笔者曾向AWS的传奇修车工、卓越工程师、副总裁James Hamilton求证,James的回答:We are both lucky

 

图表 14 James的评论

 

云计算到底是什么呢?

笔者认为云计算是一种新的软件开发模式,所有的租户,也就是软件开发者,以及基础设施提供者都是参与者。软件开发者开发、运营原生的云应用,并对基础设施提出新的需求。基础设施提供者不断的提高资源池整体的扩展性、效率,并降低其成本。同时保证单个资源的小颗粒,以及管理可编程性。

如同芯片平台Intel将芯片技术同等的提交给硬件集成商、通信管道平台华为将通信技术同等的提交给电信运营商、手机软件平台苹果appstore将客户无差别提交给软件开发者、即时通讯平台腾讯将连接提交给广大最终用户。云计算基础设施平台将资源池效率/成本比,无差别的提交给云计算应用开发者,应用开发者的投资最终从基础设施变更到应用开发本身,使云计算分工更明确,决策链条实现闭环迭代式发展。

参考文献
https://en.wikipedia.org/wiki/Cloud_computing  云计算定义

http://docs.aws.amazon.com/general/latest/gr/rande.html   AWS Regions and AZs

https://www.youtube.com/watch?v=JIQETrFC_SQ   James Hamilton,AWS Innovation at Scale

https://aws.amazon.com/cn/blogs/aws/now-available-i3-instances-for-demanding-io-intensive-applications/  AWS i3 instance specification

https://aws.amazon.com/cn/answers/networking/aws-multiple-Region-multi-vpc-connectivity/

https://aws.amazon.com/ec2/instance-types/?nc1=f_ls