《Windows Azure Platform 系列文章目錄》
?
1.Microsoft Azure底層是否由System Center和Hyper-V構成?
Microsoft Azure雖然支持Hyper-V的VHD直接上傳至Azure云端進行管理，但是Azure底層技術是微軟自己研發的、獨有的技術，且不對外提供。如果客戶想構建屬于自己的私有云平臺，可以使用Azure Pack，采用微軟的System Center + Windows Server產品，構建自己的私有云平臺。
?
2.我是否可以在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中再創建虛擬機。
?
3.如果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。
?
4.微軟有沒有單個實例的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。但是不會影響兩個或者兩個以上的實例(需要正確配置可用性集)。
?
5.微軟在維護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。
?
6.什么是可用性集?
這里有兩個非常重要的概念：故障域(Fault Domain)和更新域(Update Domain)。
http://blogs.technet.com/b/yungchou/archive/2011/05/16/window-azure-fault-domain-and-update-domain-explained-for-it-pros.aspx
我們先說說故障域。先舉個例子，筆者的書房有一個插線板，插線板上接了我的筆記本電腦，手機充電器，電視機等電器。如果這個插線板斷電了，那這個插線板上的所有電器都會斷電。這個插線板和上面的電器組成了一個故障域。
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)的截圖：
?
?
7.Microsoft Azure如何保證CPU、內存、硬盤的性能?
回答：傳統的Hyper-V技術，CPU是共享的。比如筆者的ThinkPad T430S是4Core/8GB，安裝了Windows Server 2012 R2操作系統，并且使用Hyper-V虛擬出3臺虛擬機。那該筆記本的物理操作系統 + 3臺虛擬機操作系統本質上都是共享4Core CPU的。
在Microsoft Azure提供的虛擬機類型如下：
| 虛擬機類型 | CPU | RAM | 外掛磁盤數量 | MAX IOPS |
| A0 | 共享 | 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。
注意：Azure VM CPU和RAM是固定搭配的，不可以按照用戶的想法隨意更改。
?
)
 Object.values())
)
![解決 VUE：[WDS] Errors while compiling. Reload prevented...- invalid expression: Unexpected token -- in](http://pic.xiahunao.cn/解決 VUE：[WDS] Errors while compiling. Reload prevented...- invalid expression: Unexpected token -- in)
