如今，公共云已迅速成為構建IT基礎設施的一種簡單而無障礙的方式。

如果企業(yè)已經擁有內部部署系統(tǒng)，那么在某些時候，可能就會希望將內部部署和外部部署整合在一起。而實現(xiàn)這一目標的一種方法是采用云爆發(fā)，但云爆發(fā)究竟是什么?以及“爆發(fā)在云端”意味著什么?

[[256397]]

“云爆發(fā)”這個術語并不新鮮，并且在過去的10年中，企業(yè)IT部門一直對其進行討論。

云爆發(fā)意味著企業(yè)擴展內部部署工作負載并將部分(或全部)業(yè)務遷移到公共云中。通常這樣做是為了緩解工作量的快速增長，例如應對峰值需求。

當應用程序部分或全部遷移到云端以減輕升級或更換期間內部部件工具包的負載時，還可以使用云爆發(fā)作為工具來幫助進行工作負載遷移。

云端爆發(fā)的“按需”模式提供了滿足工作負載需求高峰或峰值的能力，而無需在現(xiàn)場保留大量未使用且昂貴的設備。

網站流量

例如，如果網站流量高峰一年只出現(xiàn)三到四次，那么使用僅在高峰期間按需使用基礎設施來滿足這些需求是有意義的。

當需求減少時，可以關閉云計算資源。與內部部署數(shù)據(jù)中心相比，這將節(jié)省大量的成本。

此外，使用云爆發(fā)可以緩解企業(yè)擴展內部部署數(shù)據(jù)中心的需求。

想象一下，計算需求的增長需要構建數(shù)據(jù)中心或擴展內部部署數(shù)據(jù)中心。企業(yè)將一些工作量轉移到公共云以減少資本支出是有意義的。

這種情況并非完全是一個云爆發(fā)的場景，因為根據(jù)定義，爆發(fā)意味著工作負載在一段時間內被移動到云端，然后最終返回到內部部署。但是，它可以在升級現(xiàn)有數(shù)據(jù)中心時用作臨時解決方案。

云爆發(fā)的誤區(qū)

雖然采用云爆發(fā)似乎是一個好主意，但實際上這個過程非常困難。許多應用程序并不是設計為同時分布在兩個(或更多)計算環(huán)境中，因為它們本質上是“整體的”。

例如，可以考慮構建在大型關系數(shù)據(jù)庫之上的系統(tǒng)。將其遷移到云端意味著移動整個應用程序。即使應用程序層可以分離(例如應用程序邏輯和數(shù)據(jù)庫的Web層)，然后云平臺引入的這些層之間的延遲可能會使云爆發(fā)成為一項挑戰(zhàn)。

因此，盡管許多組織可能對云爆發(fā)很感興趣，但很少有人會以真正動態(tài)的方式實施該流程。實際上，許多云爆發(fā)項目將側重于將整個應用程序或應用程序組***性地移動到公共云中。

云爆發(fā)和存儲

如何在云爆發(fā)場景中實現(xiàn)數(shù)據(jù)存儲?

首先，存儲在使應用程序可以移入和移出公共云方面發(fā)揮著重要作用。將應用程序爆發(fā)到公共云的過程通?；趯贸绦蚝蛿?shù)據(jù)一起移動或將數(shù)據(jù)移動到已經存在的另一個應用程序實例。

例如，目前的大多數(shù)應用程序都打包為虛擬機。 Velostrata(被谷歌公司收購)、Zerto和Racemi等供應商都提供將整個虛擬機遷移到云端的功能。

云計算提供商也有自己的解決方案。其中一些工具專注于在一次性過程中移動整個虛擬機。但是，例如Velostrata提供了只是移動活動數(shù)據(jù)，并以真正動態(tài)的方式將虛擬機更新帶回內部部署的功能。

此功能突出了此類遷移的主要問題之一，即保持應用程序和數(shù)據(jù)同步。

在整個網絡中移動多個虛擬機(或多組虛擬機)既昂貴又耗時。在將虛擬機移回內部部署時尤其如此。超大規(guī)模的云計算提供商對出口的數(shù)據(jù)收費，對于用戶來說，將其應用程序和數(shù)據(jù)從云端返回內部部署的方法并不可行。

還需要考慮延遲時間。通常，在公共云平臺之間移動時，應用程序不可用，這可能是一個問題。延長的中斷將影響用戶體驗，需要盡可能地解決這個問題。

以存儲為中心的云爆發(fā)

如何將數(shù)據(jù)移動到公共云?簡單地使用公共云作為內部存儲的擴展已經存在了一段時間。備份供應商以及主存儲解決方案供應商和輔助存儲解決方案供應商都提供了將數(shù)據(jù)作為存檔形式推送到公共云的功能。

從控制非活動數(shù)據(jù)成本的角度來看，這很好，但是活動應用程序?企業(yè)需要考慮一些事項，以使主動存儲云爆發(fā)變得切實可行。

***個問題是數(shù)據(jù)視圖的一致性。這意味著需要管理與數(shù)據(jù)關聯(lián)的元數(shù)據(jù)。對于塊存儲來說，需要跟蹤和訪問任何單個塊的***版本。對于文件和對象存儲，這意味著了解文件或對象的***版本。

元數(shù)據(jù)一致性是一項挑戰(zhàn)，因為所有數(shù)據(jù)更新都會更改元數(shù)據(jù)，無論是新文件的信息還是現(xiàn)有文件的更新。這些更改必須盡可能快速高效地分布在數(shù)據(jù)的所有端點上。這導致了元數(shù)據(jù)管理的另一個問題——鎖定。

為了確保兩個位置不會試圖同時更新相同的內容，一個或其他位置將獲得對數(shù)據(jù)的鎖定，其他位置必須等待。

這個鎖定過程可能會帶來顯著的問題(例如不可接受的延遲)。另一種解決方案是不會導致鎖定(將一個副本設為只讀)，或者像對象存儲中看到的那樣，采用“***寫入者獲勝”的過程，其中***一次更新有效地反映為數(shù)據(jù)的當前副本。

“***寫入者獲勝”對于像對象存儲這樣的存儲平臺來說是一個可以接受的解決方案，但對于基于塊的存儲解決方案來說是完全不切實際的，其中數(shù)據(jù)一致性是通過確保每個讀寫都按時間順序準確反映來確定的。

數(shù)據(jù)保護

構建分布式存儲和應用程序架構的***一個考慮因素是了解如何從故障中恢復。

如果內部部署服務器出現(xiàn)故障會怎樣?如果云計算提供商的服務中斷會發(fā)生什么?當數(shù)據(jù)位于多個位置時，如果其中一個平臺出現(xiàn)故障，則很難知道***一致的數(shù)據(jù)副本的存在位置。為了避免數(shù)據(jù)丟失，人們需要很好地理解故障場景。

云爆發(fā)存儲解決方案

供應商如何應對存儲云爆發(fā)?主要的云計算提供商在早期階段就確定了這一要求。AWS公司具有存儲網關產品，該產品可以在內部部署數(shù)據(jù)中心中作為虛擬機部署，并作為iSCSI LUN公開提供給本地應用程序。將數(shù)據(jù)存檔回AWS云平臺，可以在那里遠程訪問。AWS存儲網關現(xiàn)在可以滿足文件和虛擬磁帶格式。

幾年前，微軟公司收購了StorSimple，為AWS 存儲網關提供類似的iSCSI功能。最近，該公司收購了Avere Systems的vFXT技術，該技術允許將內部部署文件系統(tǒng)擴展到公共云。

包括NetApp(Data Fabric)，Scality(Zenko)，Elastifile(CloudTier)和Cloudian(HyperFile / HyperStore)在內的存儲供應商都能夠跨越內部部署和公共云來按需移動數(shù)據(jù)。整個行業(yè)中還有更多可用的類似解決方案的例子。

人們的期待

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

與此同時，存儲供應商正在使人們接近一個更加實時的分布式數(shù)據(jù)生態(tài)系統(tǒng)，盡管有的企業(yè)還在采用專有解決方案。