iT邦幫忙

DAY 7
5

雲端運算與 Windows Azure Platform 開發系列 第 7

Windows Azure Internals (2): Red Dog Front-End (RDFE)

本文將介紹 Windows Azure 核心的另一個重要元件:RDFE,它是應用程式部署的核心,外界對 Windows Azure 的任何呼叫操作都會透過它與 Fabric Controller 溝通與命令。
在昨天的文章中,我們大略介紹了在Windows Azure Platform中位居核心地位的自治管理服務-Fabric Controller,今天我們要將目光轉移到另一個核心服務,這個服務負責應用程式的部署指揮,以及更新控制的工作,這個服務稱為RDFE(Red Dog Front-End)。RDFE會接受來自Service Management APIs的要求,對Fabric Controller下達部署應用程式的指揮命令(含虛擬機器的參數,複製檔案的路徑以及組態參數等),而負責處理.cspkg、.csdef與.cscfg的工作就是由RDFE來執行。

為了要達成應用程式的高度容錯性,RDFE會自動的配置不同的虛擬機器到不同的實體伺服器內,**Windows Azure Platform要求要達到SLA規範的99.9%可用性的必要條件是每個應用程式的執行個體數(instance count)要2以上,只有1個執行個體時,Windows Azure Platform不會保證SLA,因為沒有備援的機器可以使用。**另外,RDFE會計算每台伺服器可用的運算資源以及應用程式所需的運算資源,以Small為1個單位(CPU: 1 core, RAM: 1.75GB, HDD: 225GB),一台實體伺服器可以部署到8個單位(CPU: 8 core, RAM: 14GB, HDD: 2040GB),RDFE會自動分析出合適的伺服器後發送指令給該伺服器所在的Fabric Controller進行部署工作,不論是哪種應用程式都會被RDFE打散,開發人員無法知道實際部署到的伺服器是哪一台,唯一可得知的是配屬的IP address以及使用Win32 API得知的伺服器名稱和規格。

RDFE除了部署以外,還負責處理應用程式的更新,以及當應用程式中斷時的復原策略,在Windows Azure內部,應用程式會被劃分為兩個區域,一個是Update Domain,一個是Fault Domain。

Update Domain規範了應用程式更新時的順序,預設情況下,當RDFE接到更新指令時,會依照水平的順序來更新,舉例來說,如果應用程式本身是設定instance count=3且update domain=3,則更新發動時RDFE會依順序停止à更新à啟動虛擬機器,但一次只會停一台以保持服務不中斷,而如果是設定instance count=9且update domain=3,則更新發動時會一次停止與更新同一個update domain內的3台虛擬機器。

但Fault Domain就不同了,Fault Domain的劃分通常會以實體機架配置為主(垂直),當Fault Domain中的機器當機時,RDFE會自動將Fault Domain中的虛擬機器移到別的Fault Domain中重新啟動,應用程式的執行個體不會部署在同一個Fault domain中,所以如果有設定2個以上的執行個體,則服務不會受到當機的影響而中斷。

一個Windows Azure應用程式在建立時會擁有兩種空間,一種是Production,另一種則是Staging,這兩種空間的差異是,Production擁有正式的DNS名稱(http://[servicename].cloudapp.net),而Staging則是以部署ID為主的DNS名稱(http://[deployid].cloudapp.net),兩者是各自獨立的不同虛擬機器,簡單的說,除了DNS不同外,兩種空間擁有的資源的相同的,不過Staging和Production之間有一個交換機制,稱為Virtual IP Swap(VIP Swap),可以在短時間內將Production和Staging的IP互換,達成快速升級應用程式的目標,但是也因為Production和Staging是各自獨立的虛擬機器,所以如果要用這種方式更新應用程式的話,運算資源費用會多一倍。

最後順帶一提,當應用程式部署到Windows Azure Platform,也就是RDFE和Fabric Controller已經在環境中配置虛擬機器後,即會開始計算運算資源的費用,因為虛擬機器配置以後,依Windows Azure內部的邏輯,RDFE不會再配置這個虛擬機器的資源給其他應用程式,以避免不穩定的因子,也就是這些資源已經專屬於這支應用程式,基於使用者付費原則,這些資源要由部署應用程式的使用者支付。所以在使用Windows Azure Platform環境時,若應用程式只是測試並沒有要長期執行時,請使用完畢後立即刪除,以避免因為沒有使用卻被計費的困擾。

Reference:
http://blogs.msdn.com/b/davidlem/archive/2008/12/16/windows-azure-what-happens-in-the-data-center.aspx
http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-853T

本文同步發表於部落格:
http://www.dotblogs.com.tw/regionbbs/archive/2011/10/12/ithome.article.contest.day7.windows.azure.internals.part2.aspx


上一篇
Windows Azure Internals (1): Fabric Controller
下一篇
Windows Azure Compute Service 運算服務-虛擬機器與服務類型
系列文
雲端運算與 Windows Azure Platform 開發32

1 則留言

0
chiounan
iT邦研究生 1 級 ‧ 2011-10-13 10:46:46

值得探索的主題。

我要留言

立即登入留言