Windows Azure使用必讀

近些日子幫了不少用戶移植應用到了Windows Azure上，在這個過程中，我發現了用戶對於Azure不太好的使用習慣，其原因一是對Azure技術不太瞭解，二是對Azure所推崇的理念不熟悉。對於公有云或者Azure的新用戶來說，學習肯定是有一個過程的，這不是大問題。但是，有些問題必須在真正部署之前搞明白，否則不經意間導致數據丟失、系統停機就得不償失了

1. [賬戶]搞清楚每個應用的訂閱以及訂閱的配額、計費方式、有效期

在Azure裏面，用戶需要區分賬號和訂閱。賬號(live ID）是用來登陸門戶的，對應一個自然人。而訂閱對應配額、賬單和付款信息。這就好比一個人有一個身份證（賬號），但可以有多個手機號（每個手機號獨立覈算）。同一個Azure賬號可以擁有多個訂閱，每次部署Azure虛擬機或其他服務時，要選擇一個訂閱。每個訂閱有一個主管理員，管理員可以添加其他用戶成爲該訂閱的用戶。這些添加的用戶就可以共享該訂閱資源，適合項目團隊開發的場景。訂閱的所有用戶擁有相同的權限，唯一的區別是隻有主管理員可以查閱賬務信息。

在門戶上，用戶也可以過濾掉無關的訂閱

由於每個訂閱各不相同，因此部署之前弄清這些訂閱信息是很必要的：

• 該訂閱的類型，是試用、MSDN、隨用隨付還是多月計劃？
  
• 該訂閱的有效期
• 該訂閱是否有配額？如果有，就需要定期檢查配額剩餘情況，避免造成訂閱停用
• 該訂閱產生了多少費用，這些費用是如何產生的，是否和預期一致？
  
• 該訂閱是否存在其他用戶，他們是否會誤操作我部署的應用？
  

其中，搞清楚有效期是最重要的。如果訂閱過期了，可能會造成所有數據被清空。訂閱的具體情況可以在門戶上點擊鏈接查看，也可直接訪問https://account.windowsazure.com/Subscriptions

點擊後，就可以看到訂閱的概要信息，包括餘額和費用

點擊右側還可以下載詳單

2. [虛擬機和雲服務] 一定要分清Blob盤和臨時盤

Azure上的虛擬機上有兩種磁盤，一種是存儲在Blob存儲上的，一種是存儲在虛擬機所在物理機磁盤上的。前一種由於使用了Blob存儲，其數據會按照Blob的存儲策略在本地存3份，並在異地保持一份鏡像，其數據的可用性和可靠性都很高，虛擬機通過網絡訪問這些Blob存儲，不依賴於特定一臺物理機。後一種依賴於物理機，如果物理機故障或進行維護，這個存儲可能會被清空。顯然，如果我們使用虛擬機的時候不分清楚磁盤類型，就會導致數據丟失

Azure不同類型的虛擬機的磁盤類型如下：

• IaaS的Windows虛擬機：C盤（系統盤）是Blob盤，D盤是臨時盤
• IaaS的Linux磁盤：sda1（根目錄）是Blob盤，sdb1（/mnt/resource）是臨時盤

• PaaS的雲服務的虛擬機磁盤：C/D/E全都是臨時盤
  

千萬不要把數據庫表文件等重要數據放在臨時盤上！

這些臨時盤往往空間比較大，完全不用的話有些可惜。另外，臨時盤在本地，存取數據要比Blob快。因此，臨時盤適合存放一些臨時數據，比如裸日誌、中間結果、上傳下載的緩存等等

那麼，如果程序要存儲文件到本地，本地系統盤空間又不夠，怎麼辦？

• 對於IaaS虛擬機，可以從Azure門戶的虛擬機頁點擊“附加空磁盤”，這樣會分配一個空的Blob盤，掛接在虛擬機上。創建的磁盤還可以從原虛擬機分離，然後掛接給另一個虛擬機。不過一個磁盤不能同時掛給兩個虛擬機
  

• 對於雲服務虛擬機，不建議將文件存儲在本地文件系統上，而是應該將文件直接存儲在Blob上，需要修改文件訪問API。如果不希望修改代碼，則有兩種辦法：
  
  • 如果應用需要讀一些本地文件，或者需要在虛擬機上安裝一些軟件，則要在雲服務啓動腳本里面加入文件下載和軟件安裝的命令，具體可參考http://blog.csdn.net/shaunfang/article/details/8939681如果手動安裝軟件或者拷貝文件到雲服務虛擬機，則虛擬機重啓後一切改動都將消失。
    
  • 如果應用不僅要讀文件，還要寫文件，那麼就不能使用上面的方法，而必須用Azure Drive。它是將Blob磁盤掛載在虛擬機上的一種方法，可以參考http://blogs.msdn.com/b/azchina/archive/2010/04/12/windows-azure-windows-azure-drive.aspx。之所以不建議，是因爲這不符合PaaS的理念。雲服務的一個重要特性就是可以隨意擴展，快速增刪節點。如果使用Drive，就需要爲每個虛擬機綁定一個Drive，這樣不僅要維護Drive本身，還要維護Drive和虛擬機的對應關係。與其非要這樣用，不如直接用IaaS
    

3. [網站、雲服務與虛擬機]弄清負載均衡的機制

Azure爲網站、雲服務和虛擬機都提供了免費的負載均衡能力。關於負載均衡我們需要注意的一點就是它對Session的處理。一般來說，傳統的負載均衡器有一種叫session粘滯(sticky)的機制，也就是會根據用戶的session信息將用戶請求轉發到固定的一臺機器上，這樣，如果應用程序在服務器端存儲session信息，那麼用戶與服務器交互就會順暢，否則，就會發生用戶session丟失和應用邏輯異常

在Azure上，雲服務和虛擬機的負載均衡器都是純網絡層面的，其均衡機制是輪流將請求發給後端的服務器，不支持session粘滯. 這就要求後臺服務器是無狀態的，也就是無論將客戶請求發給任何一個服務器，都可以得到正確的處理。如果現有的應用是有狀態的，那麼有兩種解決辦法：

1. 將session信息在所有服務器間共享。具體實現方式包括：分佈式緩存（比如Memcache，Azure Caching), session持久化（.NET和Java都支持用數據庫存儲session信息，而Azure還支持用Cache和Azure存儲持久化.NET session信息: http://blogs.msdn.com/b/cie/archive/2013/05/17/session-state-management-in-windows-azure-web-roles.aspx）
2. 在虛擬機上自行配置負載均衡集羣，比如squid(linux), IIS ARR(windows). 微軟的MSOpenTech團隊提供了一個自動配置IIS ARR的方法：https://github.com/MSOpenTech/WindowsAzureToolkitForEclipseWithJava/tree/master/Utils/ARRConfigurationAgent。它原本是爲了配置雲服務裏面的Java集羣的，也可以用來配置其他IIS集羣

網站服務的負載均衡稍有不同，它的負載均衡是由IIS ARR實現的，因此它原生支持session粘滯。其實現原理是，在每個響應裏面添加ARRAffinity這個cookie，這樣，下次同一個用戶的請求就會被識別，然後發送到上次的服務器上。也就是說，不論應用是否主動寫入cookie或是存取session，IIS都會爲每個用戶保持服務器的綁定關係。

4. [架構與運維]任何服務都可能會停機

儘管Azure的架構設計考慮了充分的冗餘，但是仍然有可能會停機，這是任何服務都避免不了的。就算是5個9的可用性也會有一個停機的窗口。停機的原因有可能是非人爲因素，比如斷網、斷電、硬件故障等等，也可能是人爲計劃性的停機維護。因此，作爲用戶，在部署應用到雲平臺時，需提前瞭解可能出現的風險和應對方案。Azure作爲一個平臺，或者雲操作系統，會盡量做到不停機，但這只是平臺層面的。從應用角度，用戶也要考慮Azure提供的可用性是否能滿足業務需求，如果不滿足，如何進行設計從而提升應用整體的可用性。在大多數時候，更高的可用性都意爲着更高的成本，因此，追求0宕機是不現實的，而Azure也無法實現這一點。開發者必須提前做好準備。

關於Azure的可用性，開發者和運維人員需要提前瞭解的是：

• Azure提供的各項服務是獨立的，各種服務一般不會相互影響。比如，虛擬機服務整體故障時，數據庫服務不受影響。用戶可以隨時登陸可用性監控臺查看各個地區Azure各個服務的可用性http://www.windowsazure.com/en-us/support/service-dashboard/
• Azure爲各個服務提供了獨立的SLA承諾，絕大部分承諾的可用性指標是99.95%和99.9%，也就是每月最多出現21.6分鐘和43.2分鐘的服務中斷，如果超出，Azure會進行賠償。
• 虛擬機和雲服務的可用性承諾比較特殊。虛擬機服務的承諾是：由2個VM構成的集羣的整體可用性是99.95%，而且這兩個VM還要在同一個可用性集裏面(http://www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/)；而云服務的承諾是：每個Role需要至少2個實例，每個Role的可用性是99.95%。千萬不要在一個Role內只部署一個虛擬機，這樣停機的概率會很高。Azure每月會進行物理機OS和雲服務虛擬機OS的升級，對於單實例的雲服務來說，每次升級都可能造成雲服務停止服務。
  

可見，對於單實例虛擬機，Azure不提供服務承諾。用戶如果要部署數據庫在虛擬機上，比如Mysql，需要自行配置HA，並把兩個VM設定爲同一個可用性組，這樣Azure會將這兩個VM放置到不同的故障域中（例如：不同機架）

另外，用戶部署服務時，可以按照使用到的Azure服務畫一個邏輯拓撲，如下圖。然後逐一分析不同服務的停機對業務可能的影響，接着分析如何應對某個服務的停機或者故障。

此外，通過啓用監控報警可以讓我們在應用異常時及時得到通知（郵件）：http://blog.csdn.net/shaunfang/article/details/9197235#t3

如果要了解雲計算架構下高可用性設計的最佳實踐，可以參考下文：

防故障：彈性雲體系結構的指南

http://msdn.microsoft.com/zh-cn/library/jj853352

Azure高可用和容災設計

http://msdn.microsoft.com/en-us/library/dn251004.aspx

5. [運維]做好數據備份

數據備份是老生常談了，是運維工作的一個核心。儘管Windows Azure提供了完善的數據存儲存儲方案，比如一份數據在本地存三份，支持異地數據鏡像等，但這隻解決了數據物理損壞的問題，而沒解決邏輯損壞的問題。比如，維護人員不小心刪除了Blob上的文件、程序Bug刪除或者修改了數據內容等等。此外，備份的另一個作用是支持容災。容災有兩個基本概念，分別是RTO和RPO。Azure存儲提供的異地鏡像能力可以實現30分鐘的RPO，但Azure並沒有承諾RTO，也就是說，如果Azure的某個站點的存儲服務發生故障，其恢復時間可能會比較長，在這段時間內，儘管數據沒有丟失，但是我們並沒有辦法訪問數據，包括鏡像數據。

下表是Azure中各種數據服務的備份和容災能力說明：

服務名稱	本地數據冗餘方式	本地備份	異地數據鏡像
存儲服務	3份，Active-Active	無	異步複製到異地，RPO=30分鐘，無RTO
SQL數據庫	3份，一主兩備	無(新功能開發中)	無
IaaS虛擬機系統盤和掛接的磁盤	僅保留數據，同存儲服務	無	僅保留數據，同存儲服務
IaaS虛擬機臨時盤	無	無	無
PaaS雲服務、移動服務、網站	僅保留髮布的軟件包、代碼	無	無

因此，對雲中的數據進行備份還是很有必要的。具體來說，每種數據的備份方式不盡相同。

• SQL數據庫. Azure門戶上爲SQL 數據庫提供了備份功能，用戶點擊備份按鈕即可將數據庫內容以Data Tier Application的格式導出到Blob存儲上。用戶可以下載該備份文件導入到本地的SQL Server上，也可以用該文件恢復一個SQL數據庫。對於SQL數據庫，建議採用自動化腳本定期進行備份，比如每天一次，保留7天。SQL數據庫不支持定期任務，我們可以採用Windows任務計劃或者Linux的cron來運行定期腳本。具體的命令可以參考https://github.com/richorama/SQLDatabaseBackup
  
• Blob存儲。Blob存儲本身不提供備份功能，只能進行快照。快照可以回滾文件到之前的版本，但是無法恢復被刪除的文件（Azure不支持Container快照）。所以，對於重要的文件，建議編寫腳本進行定期備份。備份的目的地址，可以是另一個存儲賬戶，或者是本地。AzCopy這個工具可以用來在不同的存儲賬戶之間進行文件拷貝，也可以用來在本地和Blob之間傳輸文件http://blogs.msdn.com/b/windowsazurestorage/archive/2013/04/01/azcopy-using-cross-account-copy-blob.aspx
  
• IaaS虛擬機。目前可用的方法，是進行虛擬機磁盤對應Blob文件的快照。具體可以參考http://blog.csdn.net/shaunfang/article/details/8933405#t0
  
• IaaS虛擬機文件。可採用各種傳統文件備份工具。對於Windows Server，可以使用Azure的雲備份服務http://blog.csdn.net/shaunfang/article/details/8933405#t1
  
• IaaS虛擬機中的數據庫。可採用各種數據庫的備份工具或者將數據庫導出再進行文件備份
  

以上各種數據的備份都是定期進行的，建議編寫程序或者腳本，專門找一臺虛擬機運行

有一些公司開發了一些運維工具，比如：

cerebrata提供的Azure Management Cmdlets. 該工具提供了命令行工具，可以進行Blob、Table的備份，SQL數據庫備份，詳見http://www.cerebrata.com/products/azure-management-cmdlets/introduction