沒有哪一個云平臺是***無缺的;任何云供應商都總存在著發生中斷事件或數據丟失這樣的風險。可以考慮采用一個多云模式來確保系統的冗余和備用。

　　雖然供應商和分析人士對于多重云的定義各有不同，但是多云計算在一般意義上是指使用多家云供應商的公共云基礎設施，例如使用谷歌計算引擎與亞馬遜網絡服務，或采用微軟與IBM。

　　使用多重云模式的理由各有不同，但其中大部分都與平臺需求有關。例如，企業用戶可能會使用谷歌公司的云服務來滿足他們的大數據需求，但又對亞馬遜網絡服務(AWS)的計算與存儲服務選項衷情不已。

[[169150]]

　　目前，對于多重云的***討論焦點集中在“主動/主動云計算冗余”話題。這就意味著企業用戶會把他們的主系統部署在一個云平臺上(例如AWS)，而把他們的備用或輔助系統托管到另一個云平臺(例如微軟的Azure)上。之后，他們的IT團隊就要持續不斷地使用在兩個云實例中的相同數據來更新這些冗余系統。一旦部署主系統的云平臺出現中斷事件，那么用戶的相關工作負載就可以在備用云供應商的平臺上繼續運行。

　　當制定使用一家以上云供應商的云計算冗余計劃時，有三個關鍵步驟需要注意。

　　首先，用戶必須非常了解他們自己的應用與數據的需求。必須時刻記得，他們的應用程序與數據需要同時在兩個云平臺上正常運行。它們應當以相同的方式運行，而且應當具有相同的運行計劃，但是這些計劃應當各自特別針對每一個平臺。例如，企業有可能擁有一個他們認為是關鍵任務的庫存控制系統。他們可以在AWS上運行一個應用程序和數據的實例作為主云平臺，而在Azure上運行另一個作為輔助平臺。

　　雖然每一個云和應用實例的功能都是保持一致的，但還是有不同的操作流程需要予以考慮。例如，每一家云供應商之間的安全機制是各不相同的，這是由于基于使用的計費模式以及其他因素造成的。IT團 隊必須了解不同的流程，并接受過與不同云平臺之間差異性相關的針對性培訓;其中就包括了如何確保不同平臺之間的數據同步。

　　其次，應在每一個云平臺上測試每一個應用與數據。主要測試的是應用的運行性能，數據的準確性與可用性。其中，即便輔助(或備用)云平臺的運行性能略低于主云平臺，這也是可以接受的，因為前者是僅供臨時使用的，但是在數據準確性方面則是不能有任何偏差的。

　　當我們在開發一個云冗余策略時，應確保在不同云計切換過程中不會出現任何數據丟失的情況。為了做到這一點，應全面設計數據同步操作以確保萬無一失。每一個同時在主要和輔助云計算平臺上運行的應用與數據實例必須在需要使用到輔助應用程序時能夠擁有同步的數據。IT團隊應當以盡可能小的延遲及時對云平臺之間的數據庫進行更新包更新，從而確保在不同云之間切換過程中不會出現數據丟失的情況。

　　***，應制訂一個策略可在主云平臺不可用時自動實現從主平臺到輔助平臺的切換。做到這一點可以有幾種方法。例如，用戶可以重新定向網絡連接以實現不同云計算平臺之間的用戶切換。當主平臺不可用時，建立可重新連接至輔助服務器的策略。IT團隊還可以使用獨立于云平臺的軟件來安排云應用，從而在發生停用事件時實現從主平臺至輔助平臺的自動切換。

　　此外，還需在用戶的云冗余計劃中定義好實施平臺切換操作的觸發條件，例如，主云平臺發生停用事件且持續20分鐘是無法觸發平臺切換的，但如果停用時間持續一個小時以上則應啟動平臺切換。

　　事實上，主云平臺發生故障從而迫使用戶切換至輔助冗余系統的概率是比較低的。大多數供應商在他們系統內部就考慮了這個問題并設置了冗余量，所以他們并不會建議用戶使用其他的云平臺作為備用。

　　但是，世事無常，我們有可能會在未來幾年內看到一次重大的云中斷。停用時間可能長達一到兩天，在這種情況下基于多家供應商的云冗余計劃將是至關重要的。同時，這樣一個計劃的成本也較低;用戶只需支付一小筆費用就可以在輔助云平臺上托管他們的運行代碼與數據。然后，隨著在發生停用事件時用戶工作負載切換至備用系統，相關的賬單也會相應變厚。