Windows Azure HandBook (6) Azure带宽与Azure Blob云存储

　　《Windows Azure Platform 系列文章目录》

　　在笔者这几年Azure售前工作中，经常会遇到客户提同样的问题：Azure 虚拟机的带宽是多少？Azure提供独享带宽吗？这个项目我们需要200兆的独享带宽。

　　当遇到这种情况的时候，笔者就会问客户：请问您需要独享带宽的目的是什么呢？

　　客户经常会回答：这个应用需要视频(大文件)的上传下载功能，或者是并发用户数巨大，需要独享带宽来相应更多的Internet请求。

　　这种情况我表示非常理解，因为我们平时在购买电信宽带的时候，都是购买30M，100MB一年，带宽要求越高，价格越贵。

　　但是在公有云平台，我们需要转变我们的思维方式，利用云计算弹性的优势，获得更好的收益。　　

　　针对这种独享带宽的问题，笔者详细写一篇文章，来介绍一下。主要内容分为以下几节：

　　1.独享带宽的弊端

　　2.分析互联网带宽内容

　　3.相关案例分享

　　

　　1.独享带宽的弊端

　　在中国，互联网接入带宽的费用是非常昂贵的。我问了其他同事，中国的互联网带宽费用大约是美国的20倍。独享带宽的价格显而易见是非常昂贵的。

　　云计算非常适合的场景包括：开关模式、爆发增长模式等。购买独享带宽不能体现云计算弹性的优势。如果购买了独享的带宽的情况下，客户用不用云计算，带宽成本是必须支付的。假设用户购买了200M独享带宽，结果项目上线后发现用户量很少，互联网带宽闲置了，但是这200M带宽费用还是必须支付的。

　　我们假设购买国内某云计算厂商的独享带宽200M，从其官网上可以看到，1个月的费用约为17717元。如下图：

　　

　　Azure带宽虽然是共享带宽，在笔者的项目经验中发现，一般情况下单台Azure A4 VM(8Core/14GB)的带宽约为70MB。

　　对应该厂商的带宽水平，3台Azure A4 VM (每台A4的配置为8Core/14GB)做负载均衡，可以提供近似200MB的独享带宽水平。但是3台Azure A4 VM，每个月的价格仅仅为12142元。如下图：

　　

　　相比该云计算厂商的独享带宽200M的价格，微软Azure的价格还是非常具有竞争优势的。

　　另外微软Azure的带宽是随着负载均衡服务器的数量增加而逐渐增加的。

　　当实际项目上线后发现互联带宽不够怎么办，把更多的Azure VM加入到负载均衡器上。当我们发现互联网带宽闲置了，则将部分Azure VM关闭即可。

　　比如笔者一个证券行业的客户，他们在业务高峰期的时候(股票开市，早上9：30-下午3点)，利用约100台Azure虚拟机横向扩展的能力，来处理大量的客户端并发。在业务低谷的时候(股票休市)，利用少量的Azure虚拟机横向扩展，用来节省成本。(Windows Azure具备Auto Scaling的能力，可以按照计划任务开启或者关闭多台Azure虚拟机，整个过程都是自动化完成的。)这种横向扩展的方式比该公司以往购买固定带宽的成本要大大的减少。

　　这种Azure虚拟机动态增加/减少的优势，可以帮助客户极大的减少成本。

　　

　　2.分析互联网带宽内容

　　客户又说，我们的应用需要支撑10万用户在线进行视频播放功能，我们需要独享带宽保证用户体验。

　　我们分析一下该场景。当我们浏览一个网站的时候，其内容可以分为以下几个部分：

　　(1)静态的HTML页面

　　(2)静态的文件，如视频、照片、文档等

　　(3)动态的编译页面，如ASPX，JSP等

　　当用户访问的视频都是走主机(Azure VM)带宽的话，毫无疑问主机带宽越大越好。

　　但是请大家别忘记了，Azure Block Blob每个文件提供60MB/S的互联网带宽，一个Storage Account提供10GB/S的互联网带宽。

　　Azure Block Blob就类似于云网盘。

　　我们只需要改变一下软件架构：

　　-　　动态编译的页面还是走主机带宽

　　-　　静态的文件，比如视频，保存到Azure Block Blob，例如地址为: http://leizhangstorage.blob.core.chinacloudapi.cn/videos/1.mp4

　　-　　静态的照片文件，保存到Azure Block Blob，例如：http://leizhangstorage.blob.core.chinacloudapi.cn/images/1.jpg

　　通过将静态内容请求发送到Azure Storage，将动态内容的请求发送到Azure 云主机，就可以大大减少云主机独享带宽的的压力。

　　接下来我们说一个案例。是我一个客户将在线培训系统迁移到Azure平台上。

　　(1)项目背景：企业A在线培训系统，主要为企业内的员工进行在线视频培训。

　　(2)现有架构：客户自建数据中心购买了60M独享带宽，所有的动态请求和静态视频文件都走该互联网带宽。

　　(3)痛点：当需要培训的用户量爆发性增长的时候，60M带宽不能响应大并发请求。

　　客户对视频文件还有安全性的要求，不能通过CDN服务来加快视频访问。所以只能将视频文件保存到Azure Storage，通过Azure Storage设置SAS Token来控制用户访问权限。

　　在将该在线培训系统迁移到Azure云平台之前，我们还在全国8个不同的城市(北京、上海、广州、深圳、成都、杭州、青岛、福州)进行了Azure Storage下载压力测试，测试结果表明Azure Storage下载速度均达到了本地网络可允许的最大下载速度。

　　该项目迁移到Azure云平台的整理架构图如下：

　　

　　该项目为混合云方式，既保留了本地数据中心的现有投入，又将视频流保存到Azure Storage以响应大并发请求。

　　整体访问流程如下：

　　(1)某员工通过手机应用，SSO单点登录到IDC 负载均衡器上(Load Balancer)

　　(2)自建IDC数据中心的Web服务器将该请求生成一个Token，并且将Token发送到部署在Azure上的Web服务器。

　　(3)Azure Web服务器将该Token返回到IDC数据中心的Web上进行验证，证明该请求是有效的。

　　(4)Token验证通过后，Azure Web根据在线培训系统的业务逻辑，通过用户访问的ID，分别访问北京和上海的Storage Account。

　　如果用户ID来自北方，则将位于中国北部(北京)的Azure Storage生成SAS(Shared Access Signature) 视频URL返回给客户端。

　　如果用户ID来自南方，则将位于中国东部(上海)的Azure Storage生成SAS 视频URL返回给客户端。

　　最后员工手机应用的视频链接地址，其实就是Azure 上海或北京的Storage生成的SAS URL。

　　客户收益：

　　(1)Azure Web服务器只验证了IDC数据中心发送的Token是否有效。所以视频流量不经过Azure Web服务器。如下图:

　　

　　可以看到，在过去7天时间内，Azure Web服务器的输出网络流量和输入网络流量均不超过75MB

　　(2)Azure Storage用来保存视频文件，并返回SAS URL。视频流量都经过Azure Storage。如下图：

　　

　　可以看到，在过去7天，Azure Storage出口流量总计为276.5GB。

　　Ticky:

　　在之前的内容中，笔者介绍了Azure Block Blob每个文件提供60MB/S的互联网带宽，一个Storage Account提供10GB/S的互联网带宽。

　　如果用户访问量非常大，超过了单个文件60MB/S的互联网带宽怎么办？很简单，只要我们将一个视频文件复制多个副本即可。

　　我们将一个视频在同一个存储账号保存了6个副本，则一共有360MB/S的互联网带宽。

　　我又同时在北京和上海有2个存储账号，则总体的互联网带宽水平为720MB/S。非常惊人了。

　　笔者在Azure Web服务器上开发了一个小的程序，通过将不同的请求平均分配到不同的视频文件上。避免出现所有用户访问同一个视频文件，产生带宽性能瓶颈。

　　

　　

　　该企业A的在线培训系统迁移到Azure的云平台的成本如下：

　　-　　2台A1 Cloud Service，每月1011

　　-　　Azure Storage Account Block Blob，总容量40G，每月费用16.4元。

　　总体成本为每年12338元。还不够买国内某云计算厂商的独享带宽200M一个月呢。

　　有人会问流量费用怎么计算，别忘记了Azure企业级合同每个月免费20TB上下行的流量。从该企业现有的使用情况来说，流量就是免费赠送的。

　　========================================================分隔符==========================================================

　　好了，我分享了好的案例。我们再讨论一个不怎么成功的案例。

　　某企业B将微信平台整体迁移到Azure云平台，因为其微信平台拥有300万粉丝，所以访问量也非常大。

　　这里面牵涉到的负载均衡器的技术点，如下图：

　　

　　微软建议的负载均衡模式如上图左侧，通过将多个Azure VM防止在负载均衡器的后端，响应Internet的请求。

　　而企业B的软件开发商只用一台Azure VM作为前置机，如上图右侧图VM1。所有的用户请求都发送到VM1上，再通过VM1的内网IP，分流到VM2和VM3上。

　　这种架构的缺点有2个：

　　(1)虽然VM3分摊了出站流量，但是VM1的公网入站流量会非常大。

　　(2)VM1会出现单点故障，如果VM1宕机了，则整个应用平台不可用。

　　另外客户低估了并发用户的请求，在项目上线之前把VM2关机了。整个架构中只有VM1和VM3在运行。

　　而且客户没有把静态文件保存到Azure Storage中，所有的请求都是走主机带宽，压力会非常大。

　　

　　项目上线后，立刻出现问题。如下图：

　　

　　VM1这台前置机5分钟内的输入流量为9.28GB，输出流量带宽为3.05GB。网络直接卡死。服务宕机。

　　经过这次不成功的经验，总结如下：

　　(1)需要提前和客户沟通，做好上线评估

　　(2)将文件占用主机带宽的弊端想客户说明。同时建议将静态文件保存至Azure Storage，避免占用主机带宽。