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

如今，公共云已迅速成為構(gòu)建IT基礎(chǔ)設(shè)施的一種簡單而無障礙的方式。

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

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

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

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

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

網(wǎng)站流量

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

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

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

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

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

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

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

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

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

云爆發(fā)和存儲

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

首先，存儲在使應(yīng)用程序可以移入和移出公共云方面發(fā)揮著重要作用。將應(yīng)用程序爆發(fā)到公共云的過程通常基于將應(yīng)用程序和數(shù)據(jù)一起移動或?qū)?shù)據(jù)移動到已經(jīng)存在的另一個應(yīng)用程序?qū)嵗?/p>

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

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

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

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

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

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

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

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

第一個問題是數(shù)據(jù)視圖的一致性。這意味著需要管理與數(shù)據(jù)關(guān)聯(lián)的元數(shù)據(jù)。對于塊存儲來說，需要跟蹤和訪問任何單個塊的最新版本。對于文件和對象存儲，這意味著了解文件或?qū)ο蟮淖钚掳姹尽?/p>

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

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

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

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

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

構(gòu)建分布式存儲和應(yīng)用程序架構(gòu)的最后一個考慮因素是了解如何從故障中恢復。

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

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

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

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

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

人們的期待

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

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