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，避免佔用主機帶寬。