多云為云原生彈性鋪平了道路

從歷史上看，企業技術彈性植根于數據中心、托管設施以及經⭕典的托管服務提供商（MSP）。業務連續性管理（BCM）和災難恢復（DR）的最佳實踐通常是由企業IT組織、第三方供應商和災難恢復解決方案的組合在企業數據中心、托管中心和托管服務提供商（MSP）設施中實現的。

然而，盡管用于災難恢復的數據中心和傳統基礎設施方法已成為常態，但針對核心基礎設施和數據的供ꦚ應商無關服務的發展正在催生將顯🍌著提高運維彈性的云原生模型。

隨著公共云采用率的提高，備份🅷和彈性模型的低成本、低風險解決方案的使用率顯著提高。在過去的幾年中，一些應用程序的云原生彈性能力甚至“誕生于云端”。然而，一直以來，利用真正🐟的混合和多云作為一種運維彈性機制是不可能的，此外，云服務提供商（CSP）缺乏可用的工具來減少實現的摩擦。現在，企業云客戶將采用多云作為一項戰略要務，而CSP提供的功能使這一夢想成為現實。

云原生彈性通過以下功能改進了傳統彈性模型：

提供統一的模板和構建塊：如果你看一下構建彈性的關��鍵組件，所有這些組件都是云原生的，其中許多是標準的、商業化的云服務，用于設計上具有彈性的生產運維（例如，用于防止故障事件的AWS AutoScaling；用于支持關鍵工作負載的基于網絡的彈性能力和工作負載分配的AWS Direct Connect/ELB；用于長𒈔期數據保留和存儲的EBS/S3/Glacier）。

自動化整個生命周期以包括故障恢復：從備份過程本身的自動化，到預꧅防性措施（如水平擴展），再到故障轉移觸發的操作處理程序，云原生彈性功能增強了實施和故障轉移模型的自動化。

使用“運維工具”而不是“💞備份工具”：針對多云的新CSP原生產品，即GCP Anthos，大大減少了與多云部署的摩擦，這最終將減少跨CSP部署和新彈性模型的進入壁壘。

可以選擇哪些部署模型？

在啟用云服務提供商（CSP）的彈性方法時，有三個關鍵的彈性模型：

圖1：云原生彈性模型的范圍涵蓋了單云到多云選項。

主動-被動配置中的單CSP。這是最常見的彈性模型，對于遺留應🎶用程序，通常涉及單個CSP——該CSP通常充當本地數據中心環境中生產應用程序的故障轉移站點。

在云原生模型中，通常對于在云中生成的應用程序來說，這也是最流行的彈性模型，適用于能夠容忍某些恢復🗹時間目標（RTO）的應用𓄧程序，這些目標不需要主動復制模型。這里的主要模型包括熱備用、指示燈和備份與恢復。

在熱備用模式中，應用程序的所有基❀本服務都以最低可行的方式運行，幾乎是在完整生產環境的“Production Lite”版本中運行。在發生故障或其他觸發恢復的場景時，可以輕松地擴展此備用環境以處理生產負載，并且可以有效地切換網絡更改以將所有流量路由到熱備用環境。

在Pilot-Light模型中，來自生產應🌼用程序的數據被復制，應用程序環境被存儲為一個模板，在出現恢復場景時可以啟動該模板。恢復到正常生產的時間比熱備用時間長，但是🌸如果應用程序對停機時間有相對較高的容忍度，那么這也是一種非常經濟高效的恢復方法。

最后，許多企業云客戶使用CSP（ಌ如AWS的備份和恢復、S3 Glacier）實現了基本的存儲和歸檔🍌模型，以實現低成本、長期保留企業內部工作負載中的數據。這是早期采用公共云的第一個可行用例之一。

評估和關鍵注意事項：當執行故障事件的時間從幾分鐘到幾小時是可以容忍的時候，此模型通常是一種標準ꦇ的、可靠的恢復方法。

主動-主動配置中的單CSP。在AWS配置中也稱為多站點，任務關鍵型應用程序通常需要跨可用性區（AZ）或在某些情況下跨可用性區域（AR）的主動-主動故障切換，具體取決于關鍵性、區域外恢復（OOR）🍌的合規要求和延遲容限。

❀通常，此模型的特點是具有主動-🍎主動配置的單個CSP；在AWS中，此模型稱為多站點模型，在區域內或OOR中運行相同的生產工作負載，并在DNS中建立網絡流量切換和規則。恢復點目標（RPO）通常指定為最后一次異步或同步數據庫寫入。一些客戶已經嘗試在AWS美國東西部地區使用多區域主動-主動設計模式來設計他們的DR。

評估和關鍵注意事項：如果你有非常關鍵的任務、對時間敏感的、超低延遲的生產應用程序，而這些應用程序“毫秒會產生百萬美元的影響”，那么這通常是合適的彈性模型。通常，具有極低延遲和對延遲敏感的應用程序的應用程序可以🌜選擇區域內模型，甚至可以選擇具有多區域數據中心和云部署的全局部署，以使數據更接近邊緣和用戶。

主動-被動或主動-主動配置中的多CSP。此模型類似于主動-主動配置中的單CSP，不同之處在于跨AZ或跨AR場景被不同的CSP供應商區域替換。對于每個CSP，這可以在同一區域（例如AWS US Ea🔴st-Northern Va和GCP US-East-a/b/c），也可以跨不同CSP生態系統的區域。

評估和關鍵注意事項：在健壯、成熟的CSP工具和服務產品出現之前，許多組織3-5年前就嘗試過這種模式。在現代應用程序構建中，使用多CSP通常是為需要進行多云部署的用例保留的（例如，某些CSP跨區域的可用性限制，降低了單CSP供應商依賴的風險）。然而，每個組織都嘗試使用自己的定制解決๊方案，因為這些方案發生在GCP等多云工具出現之前。對于出于技術考慮需要進行全球部署的跨國公司和全球組織，以及為不同國家/地區的客戶提供服務的跨國公司和全球組織來說，這也是一個極好的選擇，因為這些國家/地區對數據的使用有不同的法律和管理規定。

為什么以前不可能這樣做，而現在可以了？

🎃多年前，許多組織曾嘗試實現多云架構和運維模式，但都失敗了。然而，許多其他原因阻礙了多云的采用，包括：

缺少可用的工具。如今，采用多云與基于容器的產品、編排工具之間的摩擦大大降低，每個CSPꦜ現在都提供服務和工具，以促進更開放和模塊化的生態系統。許多組織嘗試了多云，但都失敗了，并回滾到混合云模型，甚至“多個云”模型，在這些模型中，不同的環境是分開管理的。事實上，許多大型金融機構都試圖實施自主🎶開發的跨CSP模式，以降低單一供應商環境的風險，最終又回到了混合云模式，而沒有強大、成熟的CSP產品的支持來實現同樣的目標。

在企業規模上，多云有著高不可及的人才和技能要求。當時，CSP的發展非常迅速，如果沒有合適的企❀業人才模式和技能，就很難完全依靠一個C🅺SP，更不用說多個供應商了。現在，大多數組織在多個CSP基礎設施和SaaS環境中運行，并且擁有構建和運行云本地生態系統所需的更多技能，盡管這仍然是一個持續的挑戰。

投入產出比低。由于缺乏工具，許多組織嘗試的定制解決方案證明，彈性、災難恢復規劃和工作負載移動性帶來的好處被全棧成本和維護開銷以及與定制解決方案的跨෴環境相互依賴性所抵消。

服務和工具成熟度如何實現云原生彈性？

三大CSP中的每一𒁃家都開發并發布了混合和多云服務，這些服務通過多云運維模式和運維彈性的新方法開辟了一個新世界：

圖2：每個CSP供應商都維護一組向多云發展的服務，支持新的彈性模型。

谷歌云平臺（GCP）。GCP Anthos于2019年首次推出，最初是作為一種混合云解決方案，通常被認為是在支持多云模型的擴展中首先上市的。根據Anthos文檔，該堆棧旨在與環境無關，但目前主要用于在A🌟WS和ꦿVMware基礎設施上的本地Anthos集群上運行。向多云的戰略轉變極大地打開了跨供應商和客戶服務提供商彈性模型在模型上的開口，尋求實現相同功能的CSP創造了許多快速追隨產品。

Microsoft Azure。始于Azure Private Stack的發布，微軟很早就開始了推進混合云趨勢，在微軟生態系統一致性模型中實現了混合云。從那時起，該產品擴展到Azure混合和多云解✤決方案，其中包括用于實現單一控制平面跨環境的Azure Arc、用于將工作負載擴展到邊緣的Azure IoT，以及支撐多云生態系統的眾多支持服務（如安全、數據、身份、網絡）。

AWS。多年來，AWS主要是公共云原生的，并最終演變成混合云（提供AWS Outposts服務）。最近發布的公告顯示，AWS原生容器服務將擴展到支持多種環境，甚至支持其他CSP供應商。目前還不清楚Amazon ECS-Anywhere和EKS-Anywhere是否🎐能提供與Azure和GCP產品集一樣高的支持多云的程度。然而，這是朝著同樣的方向邁出的一大步，許多客戶有多云支持的需求，并希望最終實現跨CSP的容🐲器可移植性，以提高采用多云模式的彈性。

應該采取什么行動來啟用和改進云原生彈性？

行動1：為企業技術生態系統選擇合適的云原生“錨”，并圍繞其構建彈性模型。

對于許多組織來說，這仍然是關鍵業務和企業工作負載和服務（如身𒊎份、加密和密鑰管理）的企業數據中心，然后♛擴展或聯合到公共云環境。對于其他初創企業、數字化和云原生企業，公共CSP生態系統通常是新領域，支持任務和業務關鍵型工作負載以及企業IT服務。

當選擇錨定在公𒅌共云中時，災難恢復并不一定更容易。隨著云基礎設施資源更易獲得，許多公司都已安裝了災難恢復基礎設施并準備就緒（例如，熱故障切換、指示燈模型）。然而，許多組織并不在多CSP或數據中心環境中實踐云原生業務連續性/災難恢復（BC/DR）或替代模型。BC/DR應該是重中之重，并支持云產品設計、工程設計和實現自動化恢復過程是保護業務不受計劃外事件影響的最佳投資之一。自動化減少了DR測試的猶豫，降低了風險，增加了測試的頻率。混沌工程經常作為一種測試彈性的技術出現，但我們還沒有看到這種技術在大技術公司之外的實踐中得到應用。

了解每個模型的關鍵風險領域以及如何減輕這些風險也很重要，例如延遲、數據駐留和安全策略。數據中心🌊和云區域的物理鄰近性、混合和多云工具的數據駐留和加密含義，以及它們的安全協調，這些都常常是許多組織🎃的障礙。

行動2：了解什么是跨CSP供應商服務的商品化，什么是差異化的，以及它如何影響彈性規劃。

在設計任務關鍵型系統時，不♑僅要考慮ꦺ功能，還要根據服務選擇和架構對彈性的影響進行審查。應考慮兩個關鍵因素：

CSP原生服務選擇：應該為內部CSP選擇哪些服務，它們的默認故障轉移配置文件是什么？如果供應商還需要額外的設計，則必須內置適當的彈性。需要注意的是，本著共享責任模型和良好架構框架的云最佳實踐精♉神，CSP供應商有責任遵守SLA性能承諾，包括服務正常運行時間和持久性。此外，客戶必須了解這些服務的架構、使用和配置每個服務的故障轉移和恢復模型，以及它如何支持系統故障轉移需求所需的更ඣ廣泛的應用程序架構（例如，主動-主動、主動-被動、指示燈）。

跨CSP或環境選擇：哪些服務（或整個應用程序/數據集）應作為跨CSP或🔥環境故障轉移的候選服務。如果CSP原生服務選擇不能滿足你的應用程序架構的所有需求，請考慮對跨CSP供應商環境和工具的選擇，以及混合安排中的企業數據中心。

行動3：做出平衡的云架構選擇，最大限度地控制同時利用云彈性的好處。

云原生和云不可知的工具和服務都將是必不可💮少的。隨著CSP的發展，商🍎業和公共部門組織現在有了成功的工具。

從對CSP不可知論、控制和工作負載可移植性的極度渴望，到一個或多個CSP供應商及其環境必須提供的一切，都有一個連續的采用范圍。我們的建議是仔細評估每一種采🌄用模式相對于更廣泛的技術戰略的態勢，并使平衡的云架構和CSP服務選擇成為你的環境和解決方案戰略遠景的基礎。

許多組織“偶然”而不是通過深思熟慮，建立了混合或多云生態系統，并正在經歷了解其當前數據中心和云足跡的過程，以評估最佳運維彈性模型以及其他業務需求。選擇涵蓋了完全云原生、CSP嵌入෴的生態系統以及云不可知的解決方案。每種模型都可以完全支持混合和多云架構，但在供應商參與度以及工具和服務選擇方面有所不同。

觀察顯示，每種架構模型都有各種各樣的采🔥用模式，并有各自的技術和運維權衡。云不可知模型通常采用定制的災難恢復解決方案跨CSP和數據中心進行設計，同時在IaaS堆棧中大量使用公共云服務，通常需要開放標準和可駐留在任何云環境中的供應商不可知平臺工具。

數據系統的恢復是復雜的。在考慮云服務及其彈性時，請關注你的數據結構。在云中設計高可用的任務關鍵型應用程序時，數據一致性、數據遍歷成本、主站點和備份站🌺點之間的延遲是關鍵考慮因素。

在CSP原生模型中，組織通常全云，并實例化適當的跨區域，甚至跨CSP控制以確保運維彈性。

以上就是多云為云原生彈性鋪平了道路的介紹，億聯云提供企業用戶機房到IDC數據中心、企業私有云和公有云，以及企業多云直連的云專線業務，可以快速、有效的為客戶提供高🥃速、穩定的專有通道。如果您有相關的業務場景，🌄歡迎咨詢，我們有專業的技術團隊可以為您提供更好的建議和方案。