標籤:blog http 使用 strong 檔案 資料
《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.什麼是可用性設定組?
請參考:http://www.cnblogs.com/threestone/archive/2012/01/06/2382322.html
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 |
外掛磁碟數量 |
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。