摘要：這種情況并非完全是一個云爆發的場景，因為根據定義，爆發意味著工作負載在一段時間內被移動到云端，然后最終返回到內部部署。在這種情況下，云爆發將是其設計的固有特征。

如今，公共云已迅速成為構建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）在內的存儲供應商都能夠跨越內部部署和公共云來按需移動數據。整個行業中還有更多可用的類似解決方案的例子。

人們的期待

在未來，人們將看到應用程序被重寫，使它們分布在多個公共云和內部部署位置。在這種情況下，云爆發將是其設計的固有特征。

與此同時，存儲供應商正在使人們接近一個更加實時的分布式數據生態系統，盡管有的企業還在采用專有解決方案。