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 A3 VM(4Core/7GB)的頻寬約為70MB。

　　對應該廠商的頻寬水平，3台Azure A3 VM做負載平衡，可以提供近似200MB的獨享頻寬水平。但是3台Azure A3 VM，每個月的價格僅僅為6071元。如：

　　

　　相比該雲端運算廠商的獨享頻寬200M的價格，微軟Azure的價格還是非常具有競爭優勢的。

　　另外微軟Azure的頻寬是隨著負載平衡伺服器的數量增加而逐漸增加的。

　　當實際項目上線後發現互聯頻寬不夠怎麼辦，把更多的Azure VM加入到負載平衡器上。當我們發現互連網頻寬閑置了，則將部分Azure VM關閉即可。

　　這種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伺服器上開發了一個小的程式，通過將不同的請求平均分配到不同的視頻檔案上。避免出現所有使用者訪問同一個視頻檔案，產生頻寬效能瓶頸。

　　

 　　

 

 

　　========================================================分隔字元==========================================================

　　好了，將了好的案例。我們再討論一個不怎麼成功的案例。

　　某企業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，避免佔用主機頻寬。

 

　　

Windows Azure HandBook (6) Azure頻寬與Azure Blob雲端儲存