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

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

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

混合云下的云爆發(fā)和災難恢復

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

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

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

創(chuàng)建強大的云爆發(fā)實施

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

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

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

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

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

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

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

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

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