云计算进入下半场,阿里云抢先布局多云连接市场

进入2017年就走进了云计算的第十一个年头。在前十年中,已经发展起了以AWS、Azure、Google Cloud、IBM Cloud等为代表的国际公有云阵营,以及阿里云、腾讯云、百度云、网易云等为代表的中国公有云阵营,还有UCloud、青云、迅达云等为代表的国内公有云第二阵营,一个多云的格局已经形成。

以多云格局为标志,云计算产业正式进入下半场。实际上,除了公有云外,私有云也已经取得了普遍市场的认可。中国信息通信研究院《中国私有云发展调查报告(2017年)》报告显示,2016年,中国私有云市场规模达到344.8亿元,相比2015年增长25.1%。随着公有云和私有云市场的齐头并进,一个混合云的世界已经成为新常态。

2017年4月18日,阿里云与安畅网络、ZStack宣布达成合作,共同为中国企业提供一站式混合云服务。与其它混合云合作不同的是,本次安畅网络专门投资自建了CloudLink专线网络,并与阿里云北京、上海、深圳节点实现高速互联,不久将实现安畅全球数据中心与阿里云全球节点的互联,从根本上解决云计算落地最后一公里的问题。

打通云计算最后一公里

什么是云计算落地的最后一公里呢?这就是高速稳定的网络连接。换句话说,在目前已经形成的多云世界里,各个云还是相互独立的“山头”。企业用户想要进入“山头”容易,但想从一个“山头”漫游到另一个“山头”,就会遇到网络连接的问题。

2015年底,新浪微博想采用阿里云的资源搭建混合云,以满足微博的短时流量高峰现象对IT资源的需求,然而遇到的一个棘手问题就是从微博的私有数据中心到阿里云公有数据中心之间的互联互通问题。因为微博想要达到在10分钟内弹性扩容阿里云上千台服务器的效果,也就是要在10分钟内完成上千台阿里云服务器的安装、授权、服务启动、流量引入、上线等全过程,为此阿里云专门拉了与微博数据中心之间的双冗余百Gb专线。

可见,如果想要用混合云来支撑核心业务系统,就需要可靠稳定的专线网络。安畅网络是一家成立于2007年的独立第三方数据中心和云计算服务商,2014年挂牌新三板,目前在中国及日本、韩国、美国和法兰克福等国家和地区建有16个高等级数据中心。在几乎伴随着云计算同步成长的十年中,安畅网络从市场最前线感受到了云计算落地最后一公里对于高速网络连接的需求,并着手布局这方面的资源。

安畅网络CEO程小中说,云连接是一种能力。这话与马化腾说的“互联网连接是一种能力”有着异曲同工的效果。对于马化腾来说,微信就是这个连接的能力。而对于云计算世界来说,商用高速网络就是这个连接的能力。对于安畅网络来说,就是三层商用互联网络体系。

首先,安畅网络自建了泛连接的FastFiber光纤网络,可实现全国1万公里以上的高速传输网络,并在北京、上海、深圳、香港、洛杉矶、法兰克福、首尔等兴建了9个PoP边缘节点,具有200+GB的互联网带宽出口,与全球14个一线运营商互连,储备了超过3个B的IP地址,形成了一个稳定可靠的商用光纤网络。

其次,而在安畅网络自身的数据中心之间,则是高速光纤专线互联(DCI),满足了不同数据中心之间的物理架构与公有云、私有云与公有云的跨数据中心互联。为了达到不同云之间互联互通,安畅网络还自研了Infra-connect混合网关,将不同体系的云网络通过专线接入到Infra-connect中,在这里最终通过一致的传输协议进行统一互联。

作为多云互联的最后一步,本次也重点发布的弹性混合云专线网络CloudLink,是基于FastFiber直连阿里云等一线公有云服务商。原来自拉专线要2个月的时间,现在采用CloudLink则只需要5个工作日就能开通专线互联。CloudLink采用全冗余的网络架构设计,最多支持两家不同运营商同时冗余路由,确保传输可靠性 99.99%;还使用了二层封装隧道,可让每个用户建立端到端的独立传输,以实现类似内部网络的安全性;网络传输丢包率低于5.1%;提供按天的动态带宽计费等。

2016年的9月,安畅网络落地了第一条CloudLink传输,2017年2月完成了上海、北京三个CloudLink交换中心的建设,2017年3月完成了与ZStack私有云到阿里云VPC内网的混合云解决方案,预计在2017年6月建立香港、北美、欧洲、日韩4个CloudLink交换中心,这样就可以实现与海外的阿里云节点的连通。值得一提的是,针对金融、物流两个方向,安畅网络专门实现了自有IDC数据中心与阿里金融云、菜鸟网络的点对点连接,做到这两个特色混合云业务的无缝对接。

这样最直接的结果,就是安畅网络现有的两万多家IDC、私有云企业客户,可以直连阿里云的资源,低成本、高效率实现类似微博-阿里云混合云的效果。显然,类似安畅网络的这种多层次商用高速网络互联的资源与解决方案,不仅将成为云计算落地最后一公里的关键,也将是多云竞争的中间关键性博弈力量。

阿里混合云的野心

阿里云对于混合云市场一直虎视眈眈。作为中国最大的公有云厂商,阿里云现在已经占据了中国市场的领导地位,根据截止2016年12月31日的2017财年第三季度财报,阿里云计算付费用户数量同比翻番达到76.5万,推动阿里云营收连续第7个季度保持三位数增幅。

根据Forrester Wave对中国公共云市场2016年Q4的报告,阿里云处于中国公共云市场第一位,其次是AWS和微软Azure。摩根士丹利分析师发布的研报中表示,阿里云在中国市场上正急速成长为IT巨头,用户群体由互联网企业拓展至大型传统企业。凭借在中国公共云市场的规模效应,阿里云正在进入深耕企业服务的阶段。

此前,中石化、徐州重工等大型企业已经开始采用阿里云的云计算和人工智能技术,支撑高并发的业务需求以及数字化创新。但要激活更大规模的企业级市场,阿里云需要一方面找到私有云的合作伙伴,另一方面就是找到混合云服务和云连接的合作伙伴。

在私有云方面,阿里云找到了私有云公司ZStack作为合作伙伴。2017年1月18日,ZStack宣布获得阿里云领投,找钢网胖猫创投、紫竹小苗基金跟投的数千万人民币A轮投资,阿里云的公有云和ZStack的私有云将构成混合云“联合战队”,用批量化方式实现企业的混合云。

ZStack的创始团队来自CloudStack早期创始团队以及虚拟化公司Citrix,ZStack的产品是综合了OpenStack、CloudStack、Linux和多种虚拟化软件思想精华的下一代私有云IaaS软件,可以做到15分钟完成安装部署,版本间5分钟无缝升级,全部部署与运维过程实现零人工操作。也就是说,无须任何手工操作和维护,企业IT人员只需要从网上下载ZStack软件后即可在几分钟内自行部署一个IaaS私有云。

有了ZStack这个强有力的私有云合作伙伴后,阿里云还缺一个云连接和混合云服务的合作伙伴,这就是安畅网络所扮演的角色。ZStack可以让企业自动化地部署IaaS私有云,在ZStack私有云和阿里公共云之间,安畅网络的多层次高速光纤专线网络就起到了大作用。然而,安畅网络的作用其实还不止是云连接的合作,在跨云集成和运维管理方面,安畅网络将帮助阿里云打通企业混合云服务的最后一关。

SmartOps是安畅网络特有的混合云运营管理平台,由SmartEye、SmartCMP、SmartGuard等多个软件产品组成,涵盖多云资源的可视化管理、深度监控、混合云管理、自动化部署、安全灾备等功能与服务。其中,SmartCMP是多云资源的自助式管理平台,可管理阿里云、AWS、青云等多种公有云的资源,集资产管理、服务管理,运维管理、财务管理、报表统计于一体,提供方便的IT资源开通、监控告警、安全防护、优化管理效率等。SmartEye是一款高性能的IT监控产品,与其它监控类产品不同的是可实现超轻量级部署,并与安畅的基础设施高度整合,可自动同步安畅用户账号下的物理资源、网络设备、云资源。

除了软件工具外,安畅网络还拿出了自己的100多位专家组成的金牌运维服务团队,从上云咨询、方案设计、规划实施、迁移与建设、架构优化到深度运维一站式交付混合云解决方案以及7X24分等级服务,可以说为阿里云的企业服务提供了一支生力军。

据了解,阿里云将首先从华东地区(包括上海、江苏、浙江)的企业开始,与安畅网络合作为企业提供上云咨询、业务架构规划、迁移与部署实施、云运维管理等服务,帮助企业零门槛快速上云。4月19日,阿里云就已经迫不及待的在杭州召开大会,响应浙江“十万企业上云”计划,而混合云必然将在浙江十万企业上云中扮演重要作用。

500强跨国彩妆企业玫琳凯和移动互联网软件企业卓易科技等也来到了阿里云、安畅网络与ZStack的合作现场。玫琳凯亚太IT技术总监梁兴表示,玫琳凯在海外主要采用AWS云服务,而在国内由于AWS的局限性而正在考虑其它公有云服务商,企业在上云的过程中需要高速、稳定、可靠的网络连接,专线就是很好的的选择。卓易科技IT总监任术林则认为,选择云服务供应商的时候要看技术服务水平和能力,特别是像安畅网络提供的100多名专家,正是企业所需要的资源。

面对公有云、私有云的各种优缺点,出于技术、成本、安全、合规、已有资产、避免单一云供应商锁定等因素,混合云已经成为企业的主流选择。而阿里云、安畅网络和ZStack的混合云“铁三角”组合可以说出现的恰逢其时,从多个角度和维度连接起了企业的混合云需求。

安畅网络CEO程小中说,安畅网络在云时代的定位就是新IT行业的连接器。这虽然是一个新物种,但却是激活多云世界必不可少的“点火装置”。(文/宁川)

时间: 2024-10-05 03:17:32

云计算进入下半场,阿里云抢先布局多云连接市场的相关文章

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend

云计算之路-阿里云上:负载均衡从七层换成四层后的意外发现

阿里云的负载均衡产品叫SLB,七层负载均衡用的是LVS+Tengine,四层负载均衡用的是LVS. 昨天七层SLB出现了波动,我们后来改用了四层SLB. 使用后意外地发现,用户请求的响应内容TCP出包走的是云服务器的公网网卡. 之前用七层SLB时流量走的都是内网网卡,再加上RDS.Memcached也走的是内网网卡,于是网络负载都集中在一块内网网卡,内网网卡IO成为了瓶颈.而公网网卡却闲置着,我们之前也曾想过要是将一部分网络负载让公网网卡分担该多好啊. 我们用物理服务器的时候,会把Web服务器上