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，避免占用主机带宽。