编者注
本报告共包括团队建设篇、产品研发篇、 服务运营篇、用户体验篇,以及其他讨论篇,因为篇幅关系,这里仅发布“用户体验篇+其他讨论篇”,有删节。如想阅读完整报告,请移步「细说云计算」公众号,ID:CloudNote。
在文章的准备过程中,作者系统地阅读了国内较为知名的几份云计算白皮书[1,2,3]。在本文的范畴内,“公有云”一词泛指面向公众开放服务的平台即服务和设施即服务。除此之外,各种名义的私有云(Private Cloud)、专有云(Dedicated Cloud)、托管云(Managed Cloud)均未包括在本文的范畴之中。
本文仅讨论中国本土的公有云服务提供商。Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform等等进入或者未进入中国市场的外资企业不在本文的讨论范围之内。
老司机简介
蒋清野,悉尼大学信息技术学院博士研究生,同时也是AWS悉尼技术支持中心的员工。他于1999年获得清华大学学士学位(土木工程),2000年获得伊利诺伊大学香槟分校硕士学位(土木工程),2015年获得悉尼大学硕士学位(计算机科学)。
他的研究兴趣包括分布式与高性能计算、开源社区的社会学行为、信息技术领域的微观经济学分析。他是美国电子电气工程师学会(IEEE)的高级会员。
用户体验
在这个部分,我们以用户体验为主线,对不同公有云服务提供商的产品进行一些小规模测试。这些测试旨在探测客户关心的几个关键参数:
服务规模;
网络与存储吞吐能力;
资源隔离状况;
客服能力。
服务规模
针对服务规模的测试,是通过端口扫描进行的。针对一个特定的IaaS服务提供商,这个测试分为两个步骤进行:
在所有区域分不同时段(时间跨度长达一个月)大量创建云主机,通过枚举得出云主机所用公网IP所在的B段列表,并通过公开的信息进行矫正;
对所有的B段针对22、80、443、3389端口进行扫描,将扫描结果记录到数据库。
有些B段IP地址,可能超出了IaaS服务提供商所拥有IP资源范围。譬如某些服务提供商使用了运营商提供的IP地址,在同一个B段里面还有用于其它用途的IP地址。有些B段IP地址,虽然由某个服务提供商拥有,但是并非用于IaaS服务。
因此,端口扫描得到的结果,反映的是从外界可以探测到的服务规模上限。考虑到防火墙、安全组、部分云主机未配置公网等等多种因素,端口扫描的结果是小于实际服务规模的。
网络与存储吞吐能力
针对网络吞吐能力的测试,是在同一个区域内启动N对云主机。在所有的云主机内安装Apache服务,提供一个100MB大小的文件下载。在每一对云主机之间,在每台云主机上启动多个线程从对方下载如上所述100MB大小的文件,单次测试持续时间15分钟。由于供下载的文件是同一个,该文件在第一次被读取之后便驻留在内存当中,不再产生新的磁盘I/O。
因此,这个测试探测的是两台云主机之间的内网带宽。N的取值范围,从1逐渐增加到10,目的在于探测单个用户可以使用的网络带宽边界。测试中使用的第一对云主机,一台在用户账号A中,一台在用户账号B中,目的在于测试网络资源隔离状况。针对一个特定的IaaS服务提供商,这个测试在不同时段进行多次,以了解不同时段对网络性能的影响。
针对存储吞吐能力的测试,是在同一个区域内启动N台云主机。在每台云主机上挂载M块云硬盘创建一个RAID0磁盘阵列。在云主机上启动多个线程,分别往磁盘阵列上写入多个远大于云主机物理内存的大文件。单次测试持续15分钟,记录测试过程中的磁盘写入带宽。这个测试分为三个步骤进行:
M的取值为1,探测单台云主机上单块云硬盘的存储带宽上限;
M的取值在2到4之间,探测单台云主机上一个磁盘阵列的存储带宽上限;
N的取值在1到10之间,探测单个用户可以使用的存储带宽上限。测试中使用的前两台云主机,一台在用户账号A中,一台在用户账号B中,目的在于测试存储资源隔离状况。针对一个特定的IaaS服务提供商,这个测试在不同时段进行多次,以了解不同时段对存储性能的影响。
作者也注意到一些公有云服务提供商采取了“地理区域——可用区——集群”这样的结构设计。在同一个可用区中,尽可能将同一用户所使用的计算资源分配到同一个集群。因此,针对网络吞吐能力的测试结果和针对存储吞吐能力的测试结果反映的可能是一个可用区中某一个集群的网络吞吐能力和存储吞吐能力。
客服能力
针对客服能力的测试,是在云服务提供商的Web控制台里提交工单。工单的内容包括要求提高配额、询问基础性的使用问题、报告缺陷等等。这部分的测试,一方面在于了解客服的响应速度,另一方面在于了解客服处理能力。
阿里云
阿里巴巴集团在自治域AS37963、AS45102中一共声明了120个B类IP地址段以及多个C类IP地址段。
2016年3月,从公网对全部120个B类IP地址段针对22(SSH)和3389(RDP)端口进行扫描,有26.5万个IP地址可以通过22端口创建网络连接,有21.5万个IP地址可以通过3389端口创建网络连接。
2016年9月,从公网对如上所述IP地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有35万个IP地址可以通过22端口创建网络连接,有92万个IP地址可以通过80端口创建网络连接,有9万个IP地址可以通过443端口创建网络连接,有25万个IP地址可以通过3389端口创建网络连接。
需要说明的是,如上所述120个B类IP地址段并非全部用于阿里云的公有云服务。阿里巴巴集团下的其他业务譬如淘宝网和支付宝所使用的IP地址也都在这120个B类IP地址段中。根据章文嵩2011年5月在第三届中国云计算大会上的演讲[10],淘宝网的生产服务器大约为20,000台。根据高山渊2012年6月在QClub深圳站上的演讲[11],阿里巴巴集团的服务器规模接近10万。
根据工信部电信研究院发布的《云计算白皮书(2014年)》,截止到2013年9月运行在阿里云上的Web服务器数量达到18,000个,比2012年增长了500%。根据NetCraft在2015年6月发布的数据,阿里云所管理的Web服务器达到45,000个。
考虑到阿里巴巴集团过去五年中的业务增长对计算资源的需求,阿里云公有云部分所使用的IP地址(包括物理机和虚拟机)可能只占如上所述活跃IP地址中的一小部分。
2016年3月,在阿里云各个区域内创建云主机,并对云主机所在的A类内网IP地址段针对22和3389端口进行扫描,有39万个内网地址可以通过22端口创建网络连接,有8万个内网地址可以通过3389端口创建网络连接。在可以通过22端口连接的IP地址中,又发现了大量活跃的3306(MySQL)端口和11211(Memcached)端口。
运行在11211端口的服务,大部分可以通过SET和GET命令直接进行操作。运行在3306端口的服务,有一定数量可以基于社会工程数据库使用root帐号通过自动化测试程序登录。
在可以通过3389端口连接的IP地址中,发现了部分活跃的1433(SQL Server)端口。运行在1433端口的服务,也有一定数量可以基于社会工程数据库使用Administrator帐号通过自动化测试程序登录。由于SQL Server服务可以使用Windows身份验证,有理由认为一定数量运行Windows操作系统的云主机已经沦为肉鸡。
作者还注意到,在阿里云各个区域进行内网扫描获得的端口数量是高度一致的。深圳、杭州、青岛、北京、上海、香港、美西这七个区域的活跃端口数量,精确到千位数都是完全相同的。唯一的一个例外是新加坡区域,原因不明。
阿里云内网带宽测试(MB/s)
考虑到批量测试的费用问题,如上测试使用的云主机实例类型为“系列二:通用型n1”,配置1颗vCPU和1GB内存。在参与测试的14台云主机中,1号云主机在一个用户帐号中,214号云主机在另外一个用户帐号中。1号云主机和2号云主机配为一对,3号云主机和4号云主机配为一对,以此类推。
在编号为1的测试中,只有第一对云主机产生网络流量,其他云主机处于空闲状态;在编号为2的测试中,第一对和第二对云主机产生网络流量,其他云主机处于空闲状态,以此类推。
如上测试在一个月中的不同时段进行了多次,不同批次的测试结果之间高度一致。作者将云主机的总量增加到10对(共20台),可以得到同样的测试结果。基于如上测试,可以认为阿里云的网络质量达到了较高的水平,具体表现在:
以云主机为单位进行精确限流,吞吐量指标基本没有发生抖动;
在小规模测试中,未能探测到单个用户能够使用的网络带宽上限;
在小规模测试中,未能探测到单个用户大量占用网络带宽对其他用户使用网络产生影响。
阿里云存储带宽测试(MB/s)
上表所示是在阿里云杭州区域进行存储带宽探测的结果。测试中使用了10台云主机,所有云主机都部署在同一个可用区内。
首先,我们使用不同的云主机实例类型挂载单块云硬盘进行测试,可以达到阿里云文档所标注的256MB/s带宽上限。此外,我们发现存储带宽上限与云硬盘的容量有关,但是与云主机实例类型无关。
其次,我们在同一台云主机上挂载多块云硬盘创建RAID0磁盘阵列进行同样测试。与单块云硬盘相比,用两块云硬盘创建的RAID0磁盘阵列可以达到400MB/s的存储带宽。用三块或者四块云硬盘创建的RAID0磁盘阵列,其存储带宽和用两块云硬盘创建的RAID0磁盘阵列是同样的。
考虑到批量测试的费用问题,如上测试使用的云主机实例类型为“系列二:通用型n1”,配置1颗vCPU和1GB内存,挂载两块500GB的云硬盘配置成RAID0磁盘阵列。在参与测试的10台云主机中,1号云主机在一个用户帐号中,210号云主机在另外一个用户帐号中。
在编号为1的测试中,只有1号云主机产生存储流量,其他云主机处于空闲状态;在编号为2的测试中,1号和2号对云主机产生存储流量,其他云主机处于空闲状态,以此类推。
如上测试在一个月中的不同时段进行了多次,不同批次的测试结果之间高度一致。将云主机的总量增加到20台,可以得到同样的测试结果。基于如上测试,可以认为阿里云的存储质量达到了较高的水平,具体表现在:
以云主机和云硬盘为单位进行精确限流,吞吐量指标基本没有发生抖动;
在小规模测试中,未能探测到单个用户能够使用的存储带宽上限;
在小规模测试中,未能探测到单个用户大量占用存储带宽对其他用户使用存储产生影响。
金山云
金山云对客户的挑选比较苛刻。作者自主在金山云的网站上注册帐号,可以完成注册但是无法激活帐号。未激活帐号依然可以对帐号进行充值,但是充值完成之后无法创建云主机,也无法使用金山云提供的任何其他资源。
作者通过在线客服功能联系到金山云的客服人员,客服人员提供了一个激活帐号的连接,但是依然无法成功激活帐号。(注:2016年5月31日前,金山云客户网上注册,需要通过线下人员审核后可激活账户。6月1日后,金山云客户可实现网上自助注册。)
金山云在自治域AS59019中声明了多个C类IP地址段,IP地址总数接近一个B段。
2016年9月,从公网对如上所述IP地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有1500个IP地址可以通过22端口创建网络连接,有1900个IP地址可以通过80端口创建网络连接,有1300个IP地址可以通过443端口创建网络连接,有300个IP地址可以通过3389端口创建网络连接。
除此之外,作者未能对金山云进行其他用户体验层面的测试。
美团云
美团云启用的公网IP地址只有一个B段。通过ip-tracker.org进行查询,未能确认这些IP地址属于美团云。
2016年3月,从公网对该地址段中针对22(SSH)和3389(RDP)端口进行扫描。有3,700个IP地址可以通过22端口创建网络连接,有1600个IP地址可以通过3389端口创建网络连接。
2016年9月,从公网对该地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有5,500个IP地址可以通过22端口创建网络连接,有6,400个IP地址可以通过80端口创建网络连接,有3,000个IP地址可以通过443端口创建网络连接,有2,000个IP地址可以通过3389端口创建网络连接。
由于美团云的规模相对较小,作者未对1433、3306和11211等端口进行扫描和自动化登录测试。基于同样的原因,作者也未对美团云进行网络、存储、客服等方面的测试。
青云
青云启用的公网IP地址有4个B段。通过ip-tracker.org进行查询,未能确认这些IP地址属于青云。
2016年3月,从公网对全部4个B类IP地址段针对22(SSH)和3389(RDP)端口进行扫描,有7,000个IP地址可以通过22端口创建网络连接,有2,000个IP地址可以通过3389端口创建网络连接。
在青云的基础网络上创建云主机,可以在云主机所在的A类内网IP地址段扫描到大量活跃的云主机。在青云的私有网络上创建云主机,则无法扫描到不属于用户自己的云主机。
2016年9月,从公网对全部4个B类IP地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有5,500个IP地址可以通过22端口创建网络连接,有14,100个IP地址可以通过80端口创建网络连接,有4,400个IP地址可以通过443端口创建网络连接,有1,700个IP地址可以通过3389端口创建网络连接。
基于如上端口扫描结果,青云的总体规模还是比较小的。即使是规模最大的一个可用区,云主机的数量级也不过是千位数而已。这样的规模,对于一个内部自用的私有云来说可能不小,但是对于面向公众提供服务的公有云的确不大。
作者注意到青云于2016年1月高调发布了一个“超大规模网络SDN/NFV 2.0网络”[22]。与青云的实际规模相比,这样的宣传未免名不副实。
青云内网带宽测试(MB/s)
上表所示是在青云北京2区(PEK-2)进行网络带宽探测的结果。测试中使用了7对云主机,所有云主机都部署在同一个区域内。我们首先使用同样的测试程序对不同的云主机实例类型进行测试,发现不同的云主机实例类型所能够达到的内网带宽是一样的。
考虑到批量测试的费用问题,如上测试使用的云主机实例类型为“超高性能主机”,配置1颗vCPU和1GB内存。在参与测试的14台云主机中,1号云主机在一个用户帐号中,214号云主机在另外一个用户帐号中。1号云主机和2号云主机配为一对,3号云主机和4号云主机配为一对,以此类推。
在编号为1的测试中,只有第一对云主机产生网络流量,其他云主机处于空闲状态;在编号为2的测试中,第一对和第二对云主机产生网络流量,其他云主机处于空闲状态,以此类推。
如上测试在一个月中的不同时段进行了多次,不同批次的测试结果之间基本一致。基于如上测试,可以认为青云的网络质量相对较低,具体表现在:
没有对云主机采取限流措施,吞吐量指标存在大规模抖动;
在小规模测试中,仅用6台云主机即可探测到网络性能恶化的迹象;
随着参与测试的云主机数量的增加,网络性能恶化极快;
单个用户可以使用的网络带宽上限低于700MB/s;
在小规模测试中,可以观察到单个用户大量占用网络带宽对其他用户使用网络产生影响。
青云存储带宽测试(MB/s)
上表所示是在青云北京2区(PEK-2)进行存储带宽探测的结果。测试中使用了10台云主机,所有云主机都部署在同一个区域内。
首先,我们使用不同的云主机实例类型挂载单块云硬盘进行测试,发现存储带宽上限为200MB/s。这个存储带宽上限既与云硬盘的容量无关,也与云主机实例类型无关。
其次,我们在同一台云主机上挂载多块云硬盘创建RAID0磁盘阵列进行同样测试。与单块云硬盘相比,用两块云硬盘创建的RAID0磁盘阵列可以获得400MB/s的存储带宽。用三块或者四块云硬盘创建的RAID0磁盘阵列,则可以获得600MB/s和800MB/s的存储带宽。
考虑到批量测试的费用问题,如上测试使用的云主机实例类型为“超高性能主机”,配置1颗vCPU和1GB内存,挂载四块50GB的云硬盘配置成RAID0磁盘阵列。在参与测试的10台云主机中,1号云主机在一个用户帐号中,210号云主机在另外一个用户帐号中。
在编号为1的测试中,只有1号云主机产生存储流量,其他云主机处于空闲状态;在编号为2的测试中,1号和2号对云主机产生存储流量,其他云主机处于空闲状态,以此类推。
如上测试在一个月中的不同时段进行了多次,不同批次的测试结果之间基本一致。基于如上测试,可以认为青云的存储质量相对较低,具体表现在:
没有对云主机或者云硬盘采取限流措施,吞吐量指标存在大规模抖动;
在小规模测试中,仅用4台云主机即可探测到存储性能恶化的迹象;
随着参与测试的云主机数量的增加,存储性能恶化极快;
单个用户可以使用的存储带宽上限为4000MB/s;
在小规模测试中,可以观察到单个用户大量占用存储带宽对其他用户使用存储产生影响。
在针对客服能力的测试中,作者通过青云Web控制台里提交了多个工单。所有工单的响应时间均在30分钟以内。不同工单分别涉及配额上调、使用方法、缺陷报告等等内容,处理所需要的时间也有不同。所有工单咨询的问题最终都得到很好的解决。
盛大云
盛大云启用的公网IP地址有3个B段。通过ip-tracker.org进行查询,未能确认这些IP地址属于盛大云。
2016年3月,从公网对全部3个B类IP地址段针对22(SSH)和3389(RDP)端口进行扫描,有6,000个IP地址可以通过22端口创建网络连接,有4,000个IP地址可以通过3389端口创建网络连接。
2016年9月,从公网对全部4个B类IP地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有5500个IP地址可以通过22端口创建网络连接,有36000个IP地址可以通过80端口创建网络连接,有3600个IP地址可以通过443端口创建网络连接,有3,200个IP地址可以通过3389端口创建网络连接。
由于盛大云的规模相对较小,作者未对1433、3306和11211等端口进行扫描和自动化登录测试。基于同样的原因,作者也未对美团云进行网络、存储、客服等方面的测试。
UCloud
UCloud启用的公网IP地址有8个B段。通过ip-tracker.org进行查询,仅有一个B段可以确认属于UCloud。
2016年3月,从公网对全部8个B类IP地址段针对22(SSH)和3389(RDP)端口进行扫描,有24,000个IP地址可以通过22端口创建网络连接,有9,000个IP地址可以通过3389端口创建网络连接。UCloud给每个用户均缺省地提供了一个私有网络,用户在自己的私有网络上创建云主机,无法扫描到不属于用户自己的云主机。
2016年9月,从公网对全部8个B类IP地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有43,100个IP地址可以通过22端口创建网络连接,有54,200个IP地址可以通过80端口创建网络连接,有27,500个IP地址可以通过443端口创建网络连接,有22,800个IP地址可以通过3389端口创建网络连接。
UCloud给每个用户均缺省地提供了一个私有网络,用户在自己的私有网络上创建云主机,无法扫描到不属于用户自己的云主机。由于UCloud的规模相对较小(相对于阿里云而言),作者未对1433、3306和11211等端口进行扫描和自动化登录测试。
UCloud内网带宽测试(MB/s)
上表所示是在UCloud北京D区(PEK-D)进行网络带宽探测的结果。测试中使用了7对云主机,所有云主机都部署在同一个区域内。我们首先使用同样的测试程序对不同的云主机实例类型进行测试,发现不同的云主机实例类型所能够达到的内网带宽是一样的。
考虑到批量测试的费用问题,如上测试使用的云主机实例类型为“SSD高性能主机”,配置1颗vCPU和2GB内存。在参与测试的14台云主机中,1号云主机在一个用户帐号中,214号云主机在另外一个用户帐号中。1号云主机和2号云主机配为一对,3号云主机和4号云主机配为一对,以此类推。
在编号为1的测试中,只有第一对云主机产生网络流量,其他云主机处于空闲状态;在编号为2的测试中,第一对和第二对云主机产生网络流量,其他云主机处于空闲状态,以此类推。
如上测试在一个月中的不同时段进行了多次,不同批次的测试结果之间基本一致。基于如上测试,可以认为UCloud云的网络质量相对较好,具体表现在:
似乎对云主机采取了限流措施,但是吞吐量指标存在一定范围的抖动;
在小规模测试中,未探测到网络性能明显恶化的迹象;
在小规模测试中,未观察到单个用户大量占用网络带宽对其他用户使用网络产生影响。
基于现象(1),作者倾向于认为UCloud尚未实现以云主机为单位进行精准限流。在小规模测试中观察到现象(2)和(3)的根本原因是因为UCloud的规模较大(相对于青云而言),其网络资源总量足以消化小规模测试所产生的网络流量。
UCloud存储带宽测试(MB/s)
上表所示是在UCloud北京C区(PEK-C)进行存储带宽探测的结果。测试中使用了10台云主机,所有云主机都部署在同一个区域内。
首先,我们使用不同的云主机实例类型挂载单块云硬盘进行测试,发现存储带宽上限在100MB/s上下波动,但是并不稳定。这个存储带宽上限既与云硬盘的容量无关,也与云主机实例类型无关。
其次,我们在同一台云主机上挂载多块云硬盘创建RAID0磁盘阵列进行同样测试。与单块云硬盘相比,用两块云硬盘创建的RAID0磁盘阵列可以获得200MB/s的存储带宽。
用三块或者四块云硬盘创建的RAID0磁盘阵列,则可以获得300MB/s和400MB/s的存储带宽。用六块云硬盘创建的RAID0磁盘阵列,最高可以获得580MB/s的存储带宽,但是均值只有400MB/s。
考虑到批量测试的费用问题,如上测试使用的云主机实例类型为“SSD高性能主机”,配置1颗vCPU和2GB内存,挂载四块50GB的云硬盘配置成RAID0磁盘阵列。在参与测试的10台云主机中,1号云主机在一个用户帐号中,210号云主机在另外一个用户帐号中。
在编号为1的测试中,只有1号云主机产生存储流量,其他云主机处于空闲状态;在编号为2的测试中,1号和2号对云主机产生存储流量,其他云主机处于空闲状态,以此类推。
如上测试在一个月中的不同时段进行了多次,不同批次的测试数据存在较大差别,但是所观察到的现象基本一致。基于如上测试,可以认为UCloud的存储质量相对较低,具体表现在:
没有对云主机或者云硬盘采取限流措施,吞吐量指标存在大规模抖动;
在小规模测试中,仅用4台云主机即可探测到存储性能恶化的迹象;
随着参与测试的云主机数量的增加,存储性能恶化极快;
在小规模测试中,可以观察到单个用户大量占用存储带宽对其他用户使用存储产生影响;
在被测试区域中可能存在其他用户运行的磁盘I/O密集型应用,并且其磁盘I/O资源使用模式随时间发生变化。
注:在针对青云的测试中,并未观察到同类现象。青云的可观测规模不足UCloud的1/3,如果青云上存在其他用户运行的磁盘I/O密集型应用,应该比UCloud更容易观察到。因此,作者倾向于认为在青云的被测试区域中存在其他用户运行的磁盘I/O密集型应用的可能性较小。
腾讯云
腾讯集团在自治域AS45090、AS132203、AS132591、AS134103中一共声明了12个B类IP地址段以及多个C类IP地址段。
2016年3月,从公网对全部12个B类IP地址段针对22(SSH)和3389(RDP)端口进行扫描,有40,000个IP地址可以通过22端口创建网络连接,有40,000万个IP地址可以通过3389端口创建网络连接。
2016年9月,从公网对全部12个B类IP地址段针对22(SSH)、80(HTTP)、443(HTTPS)和3389(RDP)端口进行扫描。有65000个IP地址可以通过22端口创建网络连接,有90,000个IP地址可以通过80端口创建网络连接,有20,000个IP地址可以通过443端口创建网络连接,有50,000个IP地址可以通过3389端口创建网络连接。
需要说明的是,如上所述12个B类IP地址段并非全部用于腾讯云的公有云服务。腾讯集团下的其他业务譬如QQ和微信所使用的IP地址也都在这12个B类IP地址段中。
根据华为集团2014年发布的成功案例《华为服务器助力腾讯构建十万级高效部署》[21]的成功案例,腾讯集团现网服务器超过30万台,其中华为服务器超过10万台。假设腾讯集团所使用的服务器当中只有10%配置公网IP,需要占用的IP地址数量就超过3万个。
考虑到腾讯集团本身对计算资源的需求还在增长,同时也会占用更多的IP地址。因此,腾讯云的公有云服务所使用的IP地址(包括物理机和虚拟机)只占如上所述活跃IP地址中的一小部分。
其他讨论
本文中讨论的几家公有云服务提供商,只有阿里云(2014年9月)、青云(2015年3月)和UCloud(2016年6月)提供了类似于ASG的自动伸缩功能。
概念阶段,小于5,000台虚拟机。公司的终极目标相对模糊,在私有云解决方案提供商和公有云服务提供商之间摇摆不定。在战术层面,缺乏明确的技术路线图,产品形态相对原始并且没有明确的技术指标。
原型阶段,小于10,000台虚拟机。公司基本上将其终极目标定位为公有云服务提供商。由于公有云和私有云之间的巨大差异,必然要放弃私有云解决方案服务提供商的身份。在战术层面,基本形成相对清晰的技术路线图,基础产品(云主机)基本定型,在宕机时间和产品性能方面均有明确的技术指标。在云主机的基础上,提供能够承担中低负载的负载均衡、数据库、缓存等等周边产品。
成长阶段,小于50,000台虚拟机。基础产品(云主机)能够满足高性能计算的要求,同时发展出一系列模块化的周边产品。普通用户完全依靠云服务提供商所提供的不同模块即可自主创建大规模可伸缩型应用(无需云服务提供商进行干预)。
成熟阶段,小于100,000台虚拟机。在技术方面,资源利用率开始提高,规模效应开始出现。在市场方面,客户忠诚度开始提高,马太效应开始出现。这标志着公司在公有云领域已经获得了较有份量的市场份额,其产品和技术获得了一个或者多个细分市场的广泛认可。
产业阶段,大于100,000台虚拟机。只有进入这一阶段,才能够认为一个服务提供商已经站稳了脚跟,可以把公有云当作一个产业来做了。至于最后能够做多大,一个好看国内的大环境,另外一个还得看公司自身的发展策略。
公有云服务的未来还远远不止于此。作者于2012年在《虚拟化、云计算、开放源代码及其他》[6]]这篇博客里面提到了英国经济学家威廉杰文斯(William Stanley Jevons,1835-1882)在《煤矿问题》(The Coal Question)[5]一书中指出的一个似乎自相矛盾的现象:
蒸汽机效率方面的进步提高了煤的能源转换率,能源转换率的提高导致了能源价格降低,能源价格的降低又进一步导致了煤消费量的增加。这种现象称为杰文斯悖论,其核心思想是资源利用率的提高导致价格降低,最终会增加资源的使用量。
在过去150年当中,杰文斯悖论在主要的工业原料、交通、能源、食品工业等多个领域都得到了实证。基于同样的原理,作者在这篇博客里面又进一步断言:“公共云计算服务的核心价值,是将服务器、存储、网络等等硬件设备从自行采购的固定资产变成了按量计费的公共资源。虚拟化技术提高了计算资源的利用率,导致了计算资源价格的降低,最终会增加计算资源的使用量。”
根据作者的观察,目前国内大部分公有云用户还是把云主机当作传统物理服务器的替代品来使用。这个观察在作者与各个公有云服务提供商负责人的访谈中也得到了验证。
在传统的IT架构中,操作系统是安装在物理服务器上的。由于重新安装操作系统需要造成很长的宕机时间,出现软件层面故障时运维或者开发人员往往倾向于寻找问题来源并予以排除。
很多时候,运维或者开发人员需要花费很长时间来寻找一些不易发觉的输入或者拼写错误(例如四个空格和一个tab)。在弹性计算这个场景中,操作系统是通过映像模板创建的,获得一台全新的包含正确配置的云主机只需要数分钟甚至更短的时间。
在这个时间优势的基础上,云计算服务提供商终于可以直面长期以来被传统IT服务提供商所刻意回避的两个事实。第一个事实是组件的失效是必然的,是不可避免的;第二个事实是组件的失效是随机的,是不可预测的。
用AWS首席技术长官Werner Vogels的原话来说,就是“任何组件可在任何时刻失效”(Everything fails, all the time.)。一个集群中任意云主机均可以在任意时刻由于任意原因(底层硬件、网络环境、操作系统、应用软件)发生失效。
有了负载均衡与自动伸缩后,一台云主机发生失效时,自动伸缩功能自动地将其从负载均衡上移除并进行销毁,同时自动地启动一台新的云主机并加入负载均衡。
因此,用户可以将云主机视为“即用即抛型”一次性资源。忽略云主机的失效,不仅不会牺牲应用服务质量,还可以将宝贵的资源集中投入到公司的关键业务。
可惜的是,由于缺乏对弹性计算的理解,大量系统管理员延续了在使用物理服务器时期培养的习惯。他们在云主机等计算资源失效时惊慌失措,并且热衷于寻找所谓的“根本原因分析”(root cause analysis)。
他们在潜意识里还是将基础设施视为公司的资产,试图去了解和掌握云主机之下每一个层面的信息。他们没有意识到在弹性计算这个场景里这些努力不仅没有必要而且会阻碍整个公司技术进步。
解决这个问题,需要所有的公有云服务提供商持之以恒地对用户进行教育。用户的认知水平提高了,也会进一步促进公有云市场的发展。除了对用户进行教育之外,公有云服务提供商也需要加强对员工的教育。
在“用户体验”这个小节的网络测试部分,作者仅报告了针对阿里云的1433、3306和11211端口扫描情况。主要的考虑在于小型公有云服务提供商更加需要保护,因此不宜对小型公有云服务提供商进行同类测试;次要的考虑在于公有云服务提供商无法独立承担安全重任,因此需要向从业人员披露公有云服务中存在的安全隐患。
需要说明的是,作者在阿里云内网和外网获得的端口扫描结果,并非阿里云独有的现象。任何一个刚刚学会运行bash脚本的从业人员,都可以通过类似方法在AWS所在的IP段扫描到类似的结果。
阿里云和AWS的不同之处,在于阿里云教育客户“选择云盾,让您的业务安全性如同阿里巴巴一般”,AWS则教育客户“安全共担”(shared responsibility)模型。云盾的产品介绍页面宣称“每天防御超过958万次暴力破解攻击”,但是作者基于社会工程数据库的自动化登录测试也获得了部分成功。这样的结果,可以有三个解释:
大部分被成功登录的云主机没有使用云盾服务;
少部分被成功登录的云主机虽然使用了云盾服务但是其密码设置过于薄弱,因此在云盾未被激活之前就已经被成功登录;
类似于Memcached这样免登录的服务,云盾目前是完全无能为力的。在阿里云内网,作者还探测到大量其他免登录或者仅使用弱口令保护的网络服务,例如RabbitMQ。
因此,不管用户是否使用服务提供商所提供的云安全服务,均应对客户进行“安全共担”的教育,引导客户采取必要的措施保护其所使用的计算资源。遗憾的是,阿里云作为国内规模最大的公有云服务提供商,向用户传达了完全错误的信息。
作者建议阿里云安全团队针对阿里云内网进行常规性的分布式端口扫描,充分了解安全隐患的严重程度,并在此基础上向阿里云的用户提出针对性的改进建议。
结语
在接受InfoQ方面的邀请准备规划这篇报告的时候,作者的内心是兴奋的。在获得所有测试数据准备撰写这篇报告的时候,作者的内心是矛盾的。一方面,作为并行与分布式计算领域的学生,作者希望为业界提供一些有用的信息和观点;
另一方面,作为公有云服务领域的从业人员,作者深知发表一份涉及多家友商的报告会带来诸多争议。在InfoQ方面的鼓励下,作者选择以真实的身份发布这些的数据和观点,希望能够对国内云计算从业人员有所帮助。
今日荐号:细说云计算
探讨云计算的一切
关注云平台架构、网络、存储与分发。
这里有干货,也有闲聊。
工业和信息化部电信研究院(中国信通院,CAICT),《云计算白皮书(2014年)》,2014年5月
中国电子信息产业发展研究院工业和信息化部赛迪智库,《云计算发展白皮书(2015版)》,2015年4月
工业和信息化部电信研究院(中国信通院,CAICT),《云计算白皮书(2016年)》,2016年9月
Peter Mell and Timothy Grance, “The NIST Definition of Cloud Computing”, NIST Special Publication 800-145, September 2011
William Stanley Jevons, “The Coal Question”, 1866
蒋清野,《虚拟化、云计算、开放源代码及其他》,2012年10月
蒋清野,《从王博士说起》,2013年12月
蒋清野,《浅谈“中国”语境下的公有云发展》,2015年5月
Qingye Jiang, Young Choon Lee, Albert Y. Zomaya, “Price Elasticity in the Enterprise Computing Resource Market”, IEEE Cloud Computing, vol.3, no. 1, pp. 24-31, Jan.-Feb. 2016, doi:10.1109/MCC.2016.14
章文嵩,《淘宝软件基础设施构建实践》,第三届中国云计算大会,2011年5月
高山渊,《阿里巴巴系统运维实践分享》,QClub深圳站,2012年6月
Netcraft, “Aliyun cloud growth makes Alibaba largest hosting company in China”, May 2015
Jiamang Wang, Yongjun Wu, Hua Cai, Zhipeng Tang, Zhiqiang Lv, Bin Lu, Yangyu Tao, Chao Li, Jingren Zhou, Hong Tang, "FuxiSort", Alibaba Group Inc, October 2015
Reynold Xin, Parviz Deyhim, Ali Ghodsi, Xiangrui Meng, Matei Zaharia, "GraySort on Apache Spark by Databricks", Databricks Inc., October 2014
Michael Conley, Amin Vahdat, George Porter, "TritonSort 2014", University of California at San Diego, 2014
Intel Xeon E5-2630基准测试数据
Intel Xeon E5-2650基准测试数据
Intel Xeon E5-2670基准测试数据
Thomas Graves, "GraySort and MinuteSort at Yahoo on Hadoop 0.23", Yahoo!, May 2013
Zhuo Zhang, Chao Li, Yangyu Tao, Renyu Yang, Hong Tang, and Jie Xu. "Fuxi: a fault-tolerant resource management and job scheduling system at internet scale." Proceedings of the VLDB Endowment 7, no. 13 (2014): 1393-1404.
华为集团,《华为服务器助力腾讯构建十万级高效部署》,2014年7月
陈海泉,《下一代超大规模软件定义网络技术实践》,2016年1月
高旭磊,《招商银行关于金融云的思考》,中国金融电脑,2016年8月
阿里云,《阿里云生态路线图》,2015年7月
延展阅读(点击标题):
喜欢我们的会点赞,爱我们的会分享!
还有一天!大咖说 & QCon 特别直播带你玩转票价6800的顶级技术盛会!是时候表演真正的技术了!