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

大多數企業使用公共和私有云基礎結構來托管其應用程序。一項調查發現，85%的IT領導者認為混合云是理想的運營環境，而半數的人表示混合云可以滿足他們的所有需求。

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

[[322689]]

云爆發挑戰

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

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

在什么情況下，云爆發挑戰值得企業付出努力

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

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

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

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

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

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

網絡和安全

網絡和安全性是最基本的云爆發挑戰，因為無論是否使用云爆發，任何混合環境都必須解決這兩個挑戰。幸運的是，IT團隊可在這個領域獲取最廣泛的技術和服務，包括來自主要云提供商、電信公司、ISP和托管服務商的技術和服務。現在有多種安全方式可以鏈接私有云和公共云，以改善混合云的連接性：

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

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

數據一致性和保護

與云災難恢復部署類似，云爆發需要將應用程序組件從本地復制到公共云IaaS。除非企業已經完全部署與云無關的基礎架構即代碼系統(例如Terraform、Chef、Ansible或其他允許以編程方式實例化資源和配置的系統)，否則企業必須手動構建必要的基礎結構資源和網絡拓撲。當部署到位后，云提供商的本機工具(例如AWS CloudFormation或Google Cloud Deployment Manager)就可以自動擴展或復制其他云區域中的資源。

企業可以多種方式解決數據同步問題，具體取決于應用程序架構：

• 將數據庫留在本地，并通過上述專用電路確保可靠的高速混合云連接。該策略適用于對延遲不敏感且不會持續訪問數據庫的應用程序，因為前端和業務邏輯應用程序層是負載增加時的主要瓶頸。
• 跨位置復制數據庫，特別是對于具有大量事務數據庫負載的應用程序。復制從本質上引發了數據一致性問題，但是這些問題已經由支持多站點復制的數據庫系統(例如Oracle和Microsoft SQL Server)解決。那些需要實時一致性的應用程序必須使用更復雜的方法，例如Oracle RAC、GoldenGate或各種第三方或開源產品(例如Qlik Replicate或SymmetricDS)。

動態資源分配

當建立網絡管道和應用程序基礎架構后，云爆發的操作部分包括在本地和云環境之間動態地定向和平衡工作負載。

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

云爆發的另一個挑戰是動態容量管理。容器化應用程序在這里具有固有的優勢，因為Kubernetes可以自動擴展群集和Pod，這是主機上的容器組。所有主要的云Kubernetes服務都包括集群自動擴展。

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