雲爆發的定義與應用
如今，公共雲已迅速成為構建IT基礎設施的一種簡單而無障礙的方式。
如果企業已經擁有內部部署系統，那麼在某些時候，可能就會希望將內部部署和外部部署整合在一起。而實現這一目標的一種方法是採用雲爆發，但云爆發究竟是什麼?以及“爆發在雲端”意味著什麼?
“雲爆發”這個術語並不新鮮，並且在過去的10年中，企業IT部門一直對其進行討論。
雲爆發意味著企業擴充套件內部部署工作負載並將部分(或全部)業務遷移到公共雲中。通常這樣做是為了緩解工作量的快速增長，例如應對峰值需求。
當應用程式部分或全部遷移到雲端以減輕升級或更換期間內部部件工具包的負載時，還可以使用雲爆發作為工具來幫助進行工作負載遷移。
雲端爆發的“按需”模式提供了滿足工作負載需求高峰或峰值的能力，而無需在現場保留大量未使用且昂貴的裝置。
網站流量
例如，如果網站流量高峰一年只出現三到四次，那麼使用僅在高峰期間按需使用基礎設施來滿足這些需求是有意義的。
當需求減少時，可以關閉雲端計算資源。與內部部署資料中心相比，這將節省大量的成本。
此外，使用雲爆發可以緩解企業擴充套件內部部署資料中心的需求。
想象一下，計算需求的增長需要構建資料中心或擴充套件內部部署資料中心。企業將一些工作量轉移到公共雲以減少資本支出是有意義的。
這種情況並非完全是一個雲爆發的場景，因為根據定義，爆發意味著工作負載在一段時間內被移動到雲端，然後最終返回到內部部署。但是，它可以在升級現有資料中心時用作臨時解決方案。
雲爆發的誤區
雖然採用雲爆發似乎是一個好主意，但實際上這個過程非常困難。許多應用程式並不是設計為同時分佈在兩個(或更多)計算環境中，因為它們本質上是“整體的”。
例如，可以考慮構建在大型關係資料庫之上的系統。將其遷移到雲端意味著移動整個應用程式。即使應用程式層可以分離(例如應用程式邏輯和資料庫的Web層)，然後雲平臺引入的這些層之間的延遲可能會使雲爆發成為一項挑戰。
因此，儘管許多組織可能對雲爆發很感興趣，但很少有人會以真正動態的方式實施該流程。實際上，許多雲爆發專案將側重於將整個應用程式或應用程式組永久性地移動到公共雲中。
雲爆發和儲存
如何在雲爆發場景中實現資料儲存?
首先，儲存在使應用程式可以移入和移出公共雲方面發揮著重要作用。將應用程式爆發到公共雲的過程通常基於將應用程式和資料一起移動或將資料移動到已經存在的另一個應用程式例項。
例如，目前的大多數應用程式都打包為虛擬機器。 Velostrata(被谷歌公司收購)、Zerto和Racemi等供應商都提供將整個虛擬機器遷移到雲端的功能。
雲端計算提供商也有自己的解決方案。其中一些工具專注於在一次性過程中移動整個虛擬機器。但是，例如Velostrata提供了只是移動活動資料，並以真正動態的方式將虛擬機器更新帶回內部部署的功能。
此功能突出了此類遷移的主要問題之一，即保持應用程式和資料同步。
在整個網路中移動多個虛擬機器(或多組虛擬機器)既昂貴又耗時。在將虛擬機器移回內部部署時尤其如此。超大規模的雲端計算提供商對出口的資料收費，對於使用者來說，將其應用程式和資料從雲端返回內部部署的方法並不可行。
還需要考慮延遲時間。通常，在公共雲平臺之間移動時，應用程式不可用，這可能是一個問題。延長的中斷將影響使用者體驗，需要儘可能地解決這個問題。
以儲存為中心的雲爆發
如何將資料移動到公共雲?簡單地使用公共雲作為內部儲存的擴充套件已經存在了一段時間。備份供應商以及主儲存解決方案供應商和輔助儲存解決方案供應商都提供了將資料作為存檔形式推送到公共雲的功能。
從控制非活動資料成本的角度來看，這很好，但是活動應用程式?企業需要考慮一些事項，以使主動儲存雲爆發變得切實可行。
第一個問題是資料檢視的一致性。這意味著需要管理與資料關聯的元資料。對於塊儲存來說，需要跟蹤和訪問任何單個塊的最新版本。對於檔案和物件儲存，這意味著瞭解檔案或物件的最新版本。
元資料一致性是一項挑戰，因為所有資料更新都會更改元資料，無論是新檔案的資訊還是現有檔案的更新。這些更改必須儘可能快速高效地分佈在資料的所有端點上。這導致了元資料管理的另一個問題——鎖定。
為了確保兩個位置不會試圖同時更新相同的內容，一個或其他位置將獲得對資料的鎖定，其他位置必須等待。
這個鎖定過程可能會帶來顯著的問題(例如不可接受的延遲)。另一種解決方案是不會導致鎖定(將一個副本設為只讀)，或者像物件儲存中看到的那樣，採用“最後寫入者獲勝”的過程，其中最後一次更新有效地反映為資料的當前副本。
“最後寫入者獲勝”對於像物件儲存這樣的儲存平臺來說是一個可以接受的解決方案，但對於基於塊的儲存解決方案來說是完全不切實際的，其中資料一致性是通過確保每個讀寫都按時間順序準確反映來確定的。
資料保護
構建分散式儲存和應用程式架構的最後一個考慮因素是瞭解如何從故障中恢復。
如果內部部署伺服器出現故障會怎樣?如果雲端計算提供商的服務中斷會發生什麼?當資料位於多個位置時，如果其中一個平臺出現故障，則很難知道最後一致的資料副本的存在位置。為了避免資料丟失，人們需要很好地理解故障場景。
雲爆發儲存解決方案
供應商如何應對儲存雲爆發?主要的雲端計算提供商在早期階段就確定了這一要求。AWS公司具有儲存閘道器產品，該產品可以在內部部署資料中心中作為虛擬機器部署，並作為iSCSI LUN公開提供給本地應用程式。將資料存檔回AWS雲平臺，可以在那裡遠端訪問。AWS儲存閘道器現在可以滿足檔案和虛擬磁帶格式。
幾年前，微軟公司收購了StorSimple，為AWS 儲存閘道器提供類似的iSCSI功能。最近，該公司收購了Avere Systems的vFXT技術，該技術允許將內部部署檔案系統擴充套件到公共雲。
包括NetApp(Data Fabric)，Scality(Zenko)，Elastifile(CloudTier)和Cloudian(HyperFile / HyperStore)在內的儲存供應商都能夠跨越內部部署和公共雲來按需移動資料。整個行業中還有更多可用的類似解決方案的例子。
人們的期待
在未來，人們將看到應用程式被重寫，使它們分佈在多個公共雲和內部部署位置。在這種情況下，雲爆發將是其設計的固有特徵。
與此同時，儲存供應商正在使人們接近一個更加實時的分散式資料生態系統，儘管有的企業還在採用專有解決方案。