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

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

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

[[322689]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

動(dòng)態(tài)資源分配

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

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

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

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