如果你根據某些云功能所產生的總收入或用戶總支出來分別對它們進行排名的話，云爆發和故障轉移將是這兩個排名中的第一名。很多企業認為這兩個功能是同等重要的，并發現這兩個過程可以互為支持。事實上，混合云部署的最佳策略就是整合云爆發和災難恢復這兩個功能。

當一個應用所要求的工作量超過了它的容量時，就會發生云爆發，或被稱為工作量溢出處理。它允許企業在云中啟用應用的額外實例，以防止影響用戶使用體驗質量的情況發生。這是公共云資源如何幫助增加企業內部IT資源的一個完美示例，它避免了數據中心中出現昂貴的產能供過于求的情況，對于企業來說這無疑是極具經濟意義和現實意義的。

云爆發需要兩個關鍵的技術要素：首先應用設計應允許多個實例同時運行，其次還要有一個機制用于實現所有實例之間的工作量平衡，——無論他們是在數據中心還是在公共云中運行。

混合云下的云爆發和災難恢復

在云中，故障轉移，或被稱為災難恢復對于用戶來說也是非常重要的。很多企業已經在考慮或著已部分實施了備用數據中心以確保他們的應用在發生重大故障、部分或全部常規數據中心資源無法使用的情況下仍能夠繼續正常運行。

在故障轉移策略中，其關注的重點往往是重大事故，例如颶風或整個地理區域的電力供應中斷。很多情況下，企業完成主資源至備用資源的遷移是有一個可預計的中斷期的。在很多情況下，應用將在一個地方或其他地方繼續運行，而傳統的機制(例如域名系統(DNS)在發生故障時會把用戶的訪問重新指向備用數據中心，而當故障排除后則又恢復指向原來的生產主數據中心。

很明顯，云爆發代表了一個更靈活的災難策略方法。如果應用的工作量不斷增長就會觸發云爆發，那么應用的可用資源減少(例如服務器或者甚至數據中心發生故障)也可觸發這個功能。這個災難恢復策略不僅可以處理整體數據中心故障的情況，也可以應對有限設備、軟件或者甚至網絡故障這樣的突發事件。總而言之，成功的云爆發是構建混合云應用的一個有用的策略。

創建強大的云爆發實施

與資源故障相關的問題，而不是應用工作量的增加，將有助于確定云爆發是否可用于構建混合云應用。用戶需要訪問一個應用的任何額外副本，而應用副本要求訪問數據庫和其他資源。這兩種可能的情況是否都在災難恢復模式中使用了云爆發？

用戶訪問多個應用副本需要某種形式的負載平衡。在大部分的情況下，企業在他們的數據中心在廣域網網關和數據中心服務器之間會使用三級路由器、應用交付控制器或者其他類似的設備。然后，這個設備就會根據實際需要在應用的多個副本之間調整工作量。如果支持云爆發，它可在這些內部負載平衡設備“后”連接公共云，那么不僅服務器故障會導致數據中心發生故障，而且工作量平衡設備的故障也有可能造成數據中心發生故障。在這種情況下，將無法訪問公共云資源。

反之，創建強大云爆發實施的最好方法是從基于網絡的負載平衡策略開始入手。

負載平衡即服務是OpenStack新發布的Grizzly中的一個新功能，這個新功能正越來越多地被云供應商們所使用。有見地的用戶們還可以在云中構建這樣的應用和主機。使用這個方法，所有的負載平衡都發生在云中，而數據中心應用資源都與云資源鏈接。這就意味著，數據中心故障并不會導致應用產生連接性的問題。

數據中心或應用訪問性的問題則更為復雜。 在工作量觸發的云爆發中，我們可以安全地假設，數據中心中的應用數據仍然是可用的，而應用基于云的副本仍然可以訪問它們。如果資源故障觸發了云爆發——尤其是整個數據中心級別的故障，那么數據中心中的數據庫資源是不可用的，而應用的云副本則無法訪問數據。

由于成本、安全性以及合規性等方面的原因，將一個公司的整個數據庫遷移至云可能是非常不現實的。那么，唯一的選擇是提高應用數據庫元素的可用性;使用額外的備份電源、冷卻設備或者甚至可能在備用場所提供關鍵應用數據的熱備份副本來保護數據存儲和查詢處理器。雖然這樣做肯定會在一定程度上增加成本，但是其費用也幾乎肯定比維護一個完整的備用數據中心要少得多。

云爆發和災難恢復可能需要對應用進行一些優化。聯機事務處理可能需要進行多個數據庫副本更新以維護一個最新的備用副本。企業可能還需要分析應用工作量以確定可以復制應用的哪些組件以提高應用的整體性能和可用性，并在多個組件同時訪問同一個數據庫時確定如何維護數據的完整性。

雖然對于經驗豐富的架構師來說，這一類型的應用問題并不是新問題，但在云爆發和災難恢復功能中還需架構師做出針對性的新調整。

甚至有可能一個同時完成云爆發和故障轉移的應用需要特別的設計。同楊，測試和審查在實現這些業務目標中也是至關重要的。