《Windows Azure Platform 系列文章目錄》
前面幾章我已經給大家介紹了Windows Azure PaaS的好處，總結下來有以下幾點：
1.面向應用，而不是面向IT基礎。微軟作為雲計算供應商，讓用戶將更多的精力放在構建優秀的軟件架構；而不必去考慮底層的問題，例如網絡、操作系統、虛擬化等IT基礎設施上。又比如：PaaS (Platform as a Service) 允許雲計算供應商能夠自動地升級操作系統，安裝補丁；而在IaaS的雲平台上，升級操作系統、安裝補丁的操作需要用戶手動的去進行配置和升級，及時性、可靠性都不高。采用了PaaS后，雲計算供應商和軟件開發者能夠各司其職，將注意力放到自己領域內的問題上。
2.彈性. Windows Azure具有Worker Role和Web Role。 Web Role能夠響應前端事件,而Worker Role能夠響應Web Role發送過來的請求.這樣的架構在保證前端快速響應的同時,又使得雲計算架構更加彈性。
IaaS (infrastructure as a Service)在雲計算分類上，面向於IT基礎設施服務，讓用戶能夠部署了運行自己需要的操作系統、中間件和Runtime。對於傳統的商業軟件來說，遷移到IaaS平台上所花費的時間、精力相比而言要小很多。IaaS更加適合傳統的應用程序。
微軟在之前推出了VM Role來實現IaaS的部分功能。但是相比真正的IaaS平台來說，VM Role是遠遠不夠的。2012年6月，Windows Azure最新的對IaaS的支持里，微軟引入了Virtual Machine這個功能，來實現Windows Azure對IaaS的支持。
那Virtual Machine相比VM Role做了哪些更新和改進呢？我們來看一看下面這張表：
| VM Role | Virtual Machine | |
| 存儲 | 非持久性存儲，一旦Windows Azure redeploy，則保存在VM Role本地磁盤上的內容全部消失，必須將文件保存到Windows Azure Storage上。 | 持久性存儲，可以將文件保存到磁盤上去。 |
| 部署 | 創建VHD，然后上傳到Azure Storage里 | 直接在Cloud里構建VHD，或者先創建VHD，然后上傳到Azure Storage里 |
| 網絡 | 外部和輸入endpoint通過服務來配置 | 內部Endpoint默認開放。輸入enpoints可以使用portal，service或者API/Script來配置 |
| 主要用途 | 部署應用長或復雜的安裝要求 | 適合那些需要持久化存儲的應用程序 |
Virtual Machine可支持的操作系統如下：
Windows
- Microsoft BizTalk Server 2010 R2 CTP (64-bit) on Windows Server 2008 R2 Service Pack 1
- SQL Server 2012 Evaluation Edition (64-bit) on Windows Server 2008 R2 Service Pack 1.
- Windows Server 2008 R2 SP1, August
- Windows Server 2008 R2 SP1, July
- Windows Server 2012, August 2012
Linux:
- OpenLogic CentOS 6.2
- SUSE Linux Enterprise Server
- Ubuntu Server 12.04 LTS
- Ubuntu Server 12.04.1
- openSUSE 12.1
1.1 Microsoft Azure機制
- Microsoft Azure是否由System Center和Hyper-V構成?
Microsoft Azure雖然支持Hyper-V的VHD直接上傳至Azure雲端進行管理，但是Azure底層技術是微軟自己研發的、獨有的技術，且不對外提供。如果客戶想構建屬於自己的私有雲平台，可以使用Azure Pack，采用微軟的System Center + Windows Server產品，構建自己的私有雲平台。
- 我是否可以在Microsoft Azure Virtual Machine中再創建虛擬機呢？
Microsoft Azure數據中心是由成千上萬台RACK組成的，每個RACK都安裝了Windows Server 2012的操作系統，我們稱為Host OS，即物理服務器的操作系統。
這些Windows Server 2012采用特殊版本的Hyper-V虛擬化技術，虛擬出了若干虛擬機，稱為Guest OS。
Host OS內含一個Fabric Agent中控軟件，以監控目前虛擬機各項信息給Fabric Controller。
Microsoft Azure的最終用戶只能接觸到Guest OS，而無法接觸到Host OS。用戶無法在Guest OS中再創建虛擬機。
- 如果Microsoft Azure所在的服務器宕機了，Azure Virtual Machine怎么恢復？
在傳統IDC機房托管中，如果物理服務器發生了宕機，那所有的虛擬機都會宕機，需要人工或者監控軟件來進行重新部署。
從文件高可用來說，Microsoft Azure虛擬機是以VHD格式保存的，並且在同一個數據中心做了三重冗余(支持跨數據中心的異地冗余)，保證Azure Virtual Machine底層VHD文件的99.9% SLA。
從數據中心架構來說，Microsoft Azure具有自我管理的功能。Azure Fabric Controller是管理Azure數據中心的中控管理系統，你可以認為他是Azure數據中心的大腦。Azure Fabric Controller本身是融合了很多微軟系統管理技術的總成，包含對虛擬機的管理(System Center Virtual Machine Manager)，對作業環境的管理(System Center Operation Manager)等，在Fabric Controller中被發揮得淋漓盡致。
Azure Fabric Controller負責自動化的管理數據中心內所有的實體服務器，包含由用戶要求的Microsoft Azure Guest OS的部署工作，定時的 Hotfix修補，機器狀態的監控，以及管理不同版本的VM鏡像等重要核心工作。Fabric Controller本身也具有高可用性。
Fabric Controller也處理虛擬機的健康管理工作(Health Management)工作，當Microsoft Azure Guest OS發生死機時，會由Fabric Controller自動選擇不同的實體機器重新部署與啟動。
在單台Guest OS的情況下，當Guest OS宕機的時候，重新部署與啟動Guest OS會需要花費一定的時間，會引起客戶應用的短暫離線，所以Microsoft Azure沒有單個實例的SLA。
- 微軟有沒有單個實例的SLA?
微軟沒有單個實例的SLA。舉個例子，客戶有一個應用部署在傳統IDC機房中，一台AD Server，一台Web Server，一台SQL Server。
在Microsoft Azure Virtual Machine中，用戶也可以選擇使用一台Azure Virtual Machine部署AD Server，一台Azure Virtual Machine部署Web Application，使用另一台Virtual Machine部署SQL Server。但是這樣的場景是沒有SLA保障的。
Microsoft Azure Virtual Machine承諾的99.95%的SLA是需要2台或者2台以上的Azure Virtual Machine同時運行，且所有的Virtual Machine都需要在同一個可用性集中。對於上面實例，用戶如果想在Azure中實現99.95%的SLA，需要同時部署：
- 兩台AD Server，放在同一個可用性集A中。
- 兩台Virtual Machine部署Web Application，且Web Application所在的Virtual Machine需要放在另外一個可用性集B中。
- 兩台Virtual Machine部署SQL Server，采用SQL Server 2012 Enterprise提供的Always-On功能，實現High Availability。且SQL Server所在的Virtual Machine需要在另外一個可用性集C中。
補充一點，微軟沒有單個實例的SLA主要原因有以下兩點：
- 從基礎設施角度來說，無法預測單台物理服務器的硬件在何時發生故障，即單台物理服務器的CPU故障、網絡故障、電源故障等是無法預測的。
- 從物理服務器的維護來說。微軟在每個月都會給Azure Virtual Machine做升級和維護，維護期一般是在周五凌晨和周六凌晨(北京、上海數據中心分別維護)。維護期窗口一般為6-8小時左右，在維護期內的虛擬機實例都會被重啟，重啟時間一般在10分鍾左右。
即該維護期是由微軟定義的，用戶沒有辦法拒絕維護過程，用戶也沒辦法指定微軟在具體哪個時間點，維護哪些虛擬機。在維護期窗口內，任何一台Azure Virtual Machine都會被重啟。但是只會影響單個實例的Azure Virtual Machine。
在Azure維護期內，會影響單個實例的Azure Virtual Machine。
- 微軟在維護Azure Virtual Machine時會不會影響我的業務？微軟是如何來保證99.95%的SLA的?
如果使用單個實例的Azure Virtual Machine，無法保證99.95%的SLA。
Microsoft Azure Virtual Machine承諾的99.95%的SLA是需要2台或者2台以上的Azure Virtual Machine同時運行，且所有的Virtual Machine都需要在同一個可用性集中。
在這種情況下，從基礎設施角度來說，微軟有機制可以保證同時運行的2台Azure Virtual Machine不會同時宕機。
從服務服務器的維護來說。微軟在給Azure Virtual Machine做維護的時候，會監控到這2台Azure Virtual Machine在同一個可用性集中，就知道客戶需要這2台Azure Virtual Machine做高可用。微軟在重啟Azure Virtual Machine，的時候，就不會同時重啟。而是先重啟其中的一台，等到這台Virtual Machine重啟完畢后，再重啟另外一台。這樣保證在維護期窗口內，同一個時刻至少有一台Virtual Machine在線。
如果客戶部署了2台Azure Virtual Machine但是沒有設置可用性集，。微軟在給Azure Virtual Machine做維護的時候，發現這2台Azure Virtual Machine沒有關聯，就會同時重啟這2台Azure Virtual Machine，造成服務off-line。
- 什么是可用性集?
這里有兩個非常重要的概念：故障域(Fault Domain)和更新域(Update Domain)。
我們先說說故障域。先舉個例子，筆者的書房有一個插線板，插線板上接了我的筆記本電腦，手機充電器，電視機等電器。如果這個插線板斷電了，那這個插線板上的所有電器都會斷電。這個插線板和上面的電器組成了一個故障域。
Microsoft Azure數據中心基礎設施由很多的RACK組成，每一個RACK都被稱為故障域。當RACK出現硬件故障時候，在RACK上的服務，不管是 Azure的計算服務、存儲服務等等都會宕機。
當客戶部署了2台 Azure Virtual Machine，但是沒有設置可用性集的時候，Microsoft Azure可能會把這2個Azure Virtual Machine部署在同一個RACK上，這樣就可能會出現單點故障。因為這1個RACK宕機了，上面運行的2個Azure Virtual Machine都會宕機。兩個Azure Virtual Machine宕機的概率和一個Azure Virtual Machine的概率是一樣。
而設置了可用性集的情況下，Microsoft Azure就會把這2台Azure Virtual Machine部署在2個不同的RACK上。微軟從數據中心底層設計上，可以保證這2個不同的RACK不會同時宕機。
然后我們談談更新域。比如我有2台Azure Virtual Machine做了負載均衡，名稱為VM1和VM2，都部署了我的Web Application，版本為1.0，他們部署在不同的更新域Update Domain中。將來我的軟件版本做了更新，升級到了2.0版本，有兩種選擇：
- 用戶同時更新這2台Azure Virtual Machine的軟件版本。但是這樣如果有客戶端發起請求，會造成服務器端的無法響應。
- Azure Fabric Controller監控這2台Azure Virtual Machine。首先更新Update Domain 0中的虛擬機軟件。更新完畢后再更新Update Domain 1中的虛擬機軟件，一直到所有的Azure Virtual Machine中的Web Application更新完畢，這樣保證在同一時刻至少有1台Azure Virtual Machine能夠響應客戶端的請求。
以下是故障域(Fault Domain)和更新域(Update Domain)的截圖：
- Microsoft Azure如何保證CPU、內存、硬盤的性能?
回答：傳統的Hyper-V技術，CPU是共享的。比如筆者的ThinkPad T430S是4Core/8GB，安裝了Windows Server 2012 R2操作系統，並且使用Hyper-V虛擬出3台虛擬機。那該筆記本的物理操作系統 + 3台虛擬機操作系統本質上都是共享4Core CPU的。
在Microsoft Azure提供的虛擬機類型如下：
| 虛擬機類型 |
CPU |
RAM |
外掛磁盤數量 |
IOPS |
| A0 |
Share |
768MB |
1 |
500 |
| A1 |
1 |
1.75GB |
2 |
2 * 500 |
| A2 |
2 |
3.5GB |
4 |
4 * 500 |
| A3 |
4 |
7GB |
8 |
8 * 500 |
| A4 |
8 |
14GB |
16 |
16 *500 |
| A5 |
2 |
14GB |
4 |
4 * 500 |
| A6 |
4 |
28GB |
8 |
8 * 500 |
| A7 |
8 |
56GB |
16 |
16 * 500 |
除了A0的虛擬機類型，它的CPU是和別的用戶共享的。其他類型的虛擬機，比如A1-A7，它的CPU是獨占的，不是和別的用戶共享的。比如物理服務器是20Core，那這個物理服務器只能虛擬出2台A7的Azure Virtual Machine(8Core/56GB)，另外多余的4Core要預留給物理服務器。
關於硬盤的性能保證，微軟是保證磁盤的IOPS。