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

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

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

云原生彈性通過以下功能改進了傳統(tǒng)彈性模型：

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

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

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

可以選擇哪些部署模型？

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

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

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

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

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

在Pilot-Light模型中，來自生產應用程序的數(shù)據(jù)被復制，應用程序環(huán)境被存儲為一個模板，在出現(xiàn)恢復場景時可以啟動該模板?；謴偷秸Ｉa的時間比熱備用時間長，但是如果應用程序對停機時間有相對較高的容忍度，那么這也是一種非常經濟高效的恢復方法。

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

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

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

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

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

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

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

為什么以前不可能這樣做，而現(xiàn)在可以了？

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

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

在企業(yè)規(guī)模上，多云有著高不可及的人才和技能要求。當時，CSP的發(fā)展非常迅速，如果沒有合適的企業(yè)人才模式和技能，就很難完全依靠一個CSP，更不用說多個供應商了?，F(xiàn)在，大多數(shù)組織在多個CSP基礎設施和SaaS環(huán)境中運行，并且擁有構建和運行云本地生態(tài)系統(tǒng)所需的更多技能，盡管這仍然是一個持續(xù)的挑戰(zhàn)。

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

服務和工具成熟度如何實現(xiàn)云原生彈性？

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

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

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

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

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

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

行動1：為企業(yè)技術生態(tài)系統(tǒng)選擇合適的云原生“錨”，并圍繞其構建彈性模型。

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

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

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

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

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

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

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

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

云原生和云不可知的工具和服務都將是必不可少的。隨著CSP的發(fā)展，商業(yè)和公共部門組織現(xiàn)在有了成功的工具。

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

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

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

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

在CSP原生模型中，組織通常全云，并實例化適當?shù)目鐓^(qū)域，甚至跨CSP控制以確保運維彈性。

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