云爆發(fā)并未像有些人期望的那樣取得成功，但是很多企業(yè)仍然渴望使用這種混合云架構(gòu)。對于那些不懼潛在挑戰(zhàn)的企業(yè)，需要考慮幾個關(guān)鍵因素。

大多數(shù)企業(yè)使用公共和私有云基礎(chǔ)結(jié)構(gòu)來托管其應(yīng)用程序。一項調(diào)查發(fā)現(xiàn)，85%的IT領(lǐng)導(dǎo)者認(rèn)為混合云是理想的運營環(huán)境，而半數(shù)的人表示混合云可以滿足他們的所有需求。

然而，“混合云”的術(shù)語涵蓋了各種各樣的場景，從簡單的被動災(zāi)難恢復(fù)(DR)環(huán)境到復(fù)雜的冗余主動-主動應(yīng)用程序。后者(同時處于活動狀態(tài)和負(fù)載平衡的公共云和私有云環(huán)境)曾經(jīng)被認(rèn)為是理想的云運營模型，因為它使系統(tǒng)架構(gòu)師能夠充分利用兩者的優(yōu)勢并最大程度地減少兩者的弊端。

[[322689]]

云爆發(fā)挑戰(zhàn)

“云爆發(fā)”成為描述這種兩全其美方案的術(shù)語。在此模型中，私有云基礎(chǔ)架構(gòu)可處理基線資源需求，并托管敏感的舊數(shù)據(jù)庫和后端系統(tǒng)。而公共云基礎(chǔ)架構(gòu)則解決季節(jié)性負(fù)載高峰、臨時爆發(fā)和橫向擴展Web前端系統(tǒng)的問題。

云爆發(fā)的宏偉愿景甚至擴展到成本優(yōu)化。在稱為“多云套利”的概念中，企業(yè)利用多個IaaS提供商，以及實時成本分析軟件，并在特定時間針對特定工作負(fù)載將突發(fā)定向到最便宜的供應(yīng)商。

在什么情況下，云爆發(fā)挑戰(zhàn)值得企業(yè)付出努力

云爆發(fā)需要大量的設(shè)計專業(yè)知識和部署規(guī)劃。是否值得付出努力取決于每個工作負(fù)載的獨特特征以及應(yīng)用程序的業(yè)務(wù)價值。

突發(fā)模式非常適合那些容量需求發(fā)生極大變化的創(chuàng)收應(yīng)用程序。在這種情況下，本地系統(tǒng)可以滿足基線資源需求，而低成本、基于云的競價型實例可以在需求激增時為這些系統(tǒng)提供支持。

不幸的是，就像通常的情況一樣，這種“優(yōu)雅”的理論面臨著多云基礎(chǔ)設(shè)施和應(yīng)用程序設(shè)計混亂的現(xiàn)實。其結(jié)果是，即使有更多公司希望部署云爆發(fā)架構(gòu)，但很少有公司真正能夠部署。的確，持懷疑態(tài)度的人認(rèn)為云爆發(fā)在很大程度上只是一個神話。咨詢公司Architecting IT最近指出了通常阻礙部署的4個重大挑戰(zhàn)：

• 網(wǎng)絡(luò)，即在公共云和私有云之間建立低延遲、高帶寬、冗余連接，并自動將傳入的連接路由到最佳位置;
• 安全，這涉及跨多個環(huán)境為用戶和系統(tǒng)部署一致的策略和控制;
• 數(shù)據(jù)一致性，或者說在多個站點同步數(shù)據(jù)存儲的問題，特別是在高事務(wù)負(fù)載期間。
• 數(shù)據(jù)保護，這是從多個來源提供備份時保持備份一致性的相關(guān)問題。

我要添加第五個挑戰(zhàn)：自動部署和動態(tài)擴展資源。這與公共云(主要是計算或容器實例、但也有存儲I / O)處理瞬態(tài)突發(fā)需求的能力有關(guān)。

這些都是可解決但很復(fù)雜的問題，這使得很多企業(yè)得出結(jié)論，云爆發(fā)不值得付出努力，至少需要他們擁有可跨多個云運行的新一代分布式應(yīng)用程序模型。對于那些仍然不為所動的企業(yè)，下面是解決每個云爆發(fā)挑戰(zhàn)的方法。

網(wǎng)絡(luò)和安全

網(wǎng)絡(luò)和安全性是最基本的云爆發(fā)挑戰(zhàn)，因為無論是否使用云爆發(fā)，任何混合環(huán)境都必須解決這兩個挑戰(zhàn)。幸運的是，IT團隊可在這個領(lǐng)域獲取最廣泛的技術(shù)和服務(wù)，包括來自主要云提供商、電信公司、ISP和托管服務(wù)商的技術(shù)和服務(wù)?，F(xiàn)在有多種安全方式可以鏈接私有云和公共云，以改善混合云的連接性：

• 虛擬專用云，使用標(biāo)準(zhǔn)VPN協(xié)議(通常為IPsec)以及虛擬路由器將本地網(wǎng)絡(luò)鏈接到公共云中的一個或多個私有子網(wǎng)。企業(yè)可以通過VPN將其公司網(wǎng)絡(luò)擴展到云子網(wǎng)中，并通過合并虛擬服務(wù)(例如路由器、NAT網(wǎng)關(guān)和Internet網(wǎng)關(guān))來保持對流量的完全控制。
• 專用電路–使用云提供商的服務(wù)(例如來自谷歌、甲骨文和IBM的AWS Direct Connect、Azure ExpressRouteor產(chǎn)品)。這些產(chǎn)品可在客戶的私有云和公共云網(wǎng)絡(luò)之間提供專用的低延遲的鏈接。由于端點位置的限制，服務(wù)通常終止在托管中心，該托管中心可以將其連接到客戶的專用機架而不是公司數(shù)據(jù)中心。
• 專用電路—使用電信公司、ISP或托管提供商的服務(wù)。這些類似于云提供商提供的服務(wù)，但是它們利用與主要運營商的廣泛互連來提供更多終端位置。AT&T NetBond或Equinix Cloud Exchange等服務(wù)還簡化了多云互連的設(shè)計，因為它們與所有主要的IaaS和SaaS提供商對接。

這兩種類型的專用電路服務(wù)都使企業(yè)能夠完全控制網(wǎng)絡(luò)路由、流量管理和安全策略。但是，Direct Connect等云提供商服務(wù)是克服云爆發(fā)挑戰(zhàn)的最佳選擇。這些服務(wù)依賴終止于云提供商數(shù)據(jù)中心的光纖電路，因此它們提供了最高的性能和最低的延遲。

數(shù)據(jù)一致性和保護

與云災(zāi)難恢復(fù)部署類似，云爆發(fā)需要將應(yīng)用程序組件從本地復(fù)制到公共云IaaS。除非企業(yè)已經(jīng)完全部署與云無關(guān)的基礎(chǔ)架構(gòu)即代碼系統(tǒng)(例如Terraform、Chef、Ansible或其他允許以編程方式實例化資源和配置的系統(tǒng))，否則企業(yè)必須手動構(gòu)建必要的基礎(chǔ)結(jié)構(gòu)資源和網(wǎng)絡(luò)拓?fù)?。?dāng)部署到位后，云提供商的本機工具(例如AWS CloudFormation或Google Cloud Deployment Manager)就可以自動擴展或復(fù)制其他云區(qū)域中的資源。

企業(yè)可以多種方式解決數(shù)據(jù)同步問題，具體取決于應(yīng)用程序架構(gòu)：

• 將數(shù)據(jù)庫留在本地，并通過上述專用電路確?？煽康母咚倩旌显七B接。該策略適用于對延遲不敏感且不會持續(xù)訪問數(shù)據(jù)庫的應(yīng)用程序，因為前端和業(yè)務(wù)邏輯應(yīng)用程序?qū)邮秦?fù)載增加時的主要瓶頸。
• 跨位置復(fù)制數(shù)據(jù)庫，特別是對于具有大量事務(wù)數(shù)據(jù)庫負(fù)載的應(yīng)用程序。復(fù)制從本質(zhì)上引發(fā)了數(shù)據(jù)一致性問題，但是這些問題已經(jīng)由支持多站點復(fù)制的數(shù)據(jù)庫系統(tǒng)(例如Oracle和Microsoft SQL Server)解決。那些需要實時一致性的應(yīng)用程序必須使用更復(fù)雜的方法，例如Oracle RAC、GoldenGate或各種第三方或開源產(chǎn)品(例如Qlik Replicate或SymmetricDS)。

動態(tài)資源分配

當(dāng)建立網(wǎng)絡(luò)管道和應(yīng)用程序基礎(chǔ)架構(gòu)后，云爆發(fā)的操作部分包括在本地和云環(huán)境之間動態(tài)地定向和平衡工作負(fù)載。

這里涉及的主要工具是負(fù)載平衡器、應(yīng)用程序交付控制器和虛擬網(wǎng)絡(luò)接口?，F(xiàn)代負(fù)載均衡器具有足夠的配置選項，用于指定負(fù)載加權(quán)因子、資源/ CPU限制和備用配置，以適應(yīng)任何突發(fā)情況。AWS Elastic Load Balancing、Google Cloud Load Balancer或Azure Load Balancer等云負(fù)載平衡服務(wù)會自動擴展容量以處理增加的流量。

云爆發(fā)的另一個挑戰(zhàn)是動態(tài)容量管理。容器化應(yīng)用程序在這里具有固有的優(yōu)勢，因為Kubernetes可以自動擴展群集和Pod，這是主機上的容器組。所有主要的云Kubernetes服務(wù)都包括集群自動擴展。

對于VM托管應(yīng)用程序，容量管理更為棘手，盡管主要的云平臺確實支持通過EC2 Auto Scaling和Azure Scale Set等服務(wù)對實例組進行自動擴展。這些工具會響應(yīng)相應(yīng)的監(jiān)視服務(wù)中的策略，例如虛擬CPU利用率、網(wǎng)絡(luò)流量或其他指標(biāo)。