本文介紹 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: