SIOS SANless clusters High-availability Machine Learning monitoring
企業越來越多地使用多個雲端服務供應商來保持靈活性和可擴展性；然而，最近發生的 CrowdStrike 中斷等事件凸顯出即使是頂級系統也可能遇到問題，特別是在更新和安全性修補程式方面。本次網路研討會討論了實施多雲高可用性 (HA) 解決方案的最佳實踐，以確保您的關鍵任務應用程式在意外中斷期間保持運作。它還涵蓋了防止系統配置錯誤或有問題的修補程式導致停機的策略，確保您可以有效地管理您的雲端基礎架構。
觀看點播網路研討會，了解如何在您的環境中實現高可用性並最大限度地減少可預防的停機時間。
經許可轉載安全作業系統
根據 Flexera 2021 年雲狀況報告，雲計算在過去十年中變得無處不在，99% 的組織至少使用一個公共或私有云。 雖然 AWS、Microsoft Azure 和 GCP 是當今三大公共雲提供商，但許多組織（無論是有意還是無意）採用了多雲戰略，使他們能夠挑選最有吸引力和最適合的雲服務以滿足他們獨特的業務需求。 根據 Flexera 報告，如今 92% 的企業擁有多雲戰略，平均使用 2.6 個公共雲和 2.7 個私有云，包括軟件即服務 (SaaS)、平台即服務 (PaaS)、基礎設施即服務 (IaaS) 產品。
多雲只是一個由兩個或多個公共和/或私有云（包括 SaaS、PaaS 和 IaaS）組成的環境。 多雲環境中的不同服務可能會互操作（在這種情況下可能是混合雲），也可能不一定會互操作（本質上作為單獨的雲孤島運行）。 請記住，儘管所有混合雲都是多雲，但並非所有多雲都是混合雲。
多雲環境由任意兩個或多個公共或私有云產品組合組成，包括 SaaS、PaaS 和 IaaS。 因此，組織的多雲戰略可能包括在 Amazon Elastic Cloud Compute (EC2) 上運行的企業工作負載，以及使用 Microsoft 365 處理電子郵件和後台應用程序。 或者，組織可以將私有云中託管的自定義數據庫連接到公共雲 SaaS 產品 Salesforce。
混合雲環境由本地、私有云和公共雲環境組成。 根據 Flexera 報告，80% 的企業擁有混合雲戰略（見圖 4）。 多雲環境通常是影子 IT 的結果，在影子 IT 中，不同的部門採購雲服務來滿足各自的需求，而無需諮詢集中的 IT 部門。 例如，您的營銷團隊可能早在 IT 部門在 AWS 中部署其第一個工作負載之前就開始使用 Salesforce，而您的人力資源和財務部門正忙於將 Workday 和 Concur 添加到您的組織現在所依賴的 SaaS 應用程序組合中。 或者，也許您擁有在全球範圍內從事不同項目的應用程序開發團隊。 一個開發團隊可能更喜歡 Azure DevOps，而另一個團隊可能更喜歡 AWS 中的開源工具。 因此，您的多雲策略可能純粹是偶然演變的——這不一定是壞事。
您的不同部門有權選擇同類最佳的解決方案來滿足他們的需求，而您的應用程序開發團隊可以在他們首選的開發環境中最大限度地提高工作效率並縮短上市時間。
多雲環境也會因設計而演變，例如，由於監管要求、併購，或實施高可用性和災難恢復策略。
監管語言可能含糊不清。 例如，金融行為監管局 (FCA) 關於外包 IT 的規定規定，公司必須能夠“知道他們將如何過渡到替代服務提供商並保持業務連續性”。該聲明意味著受監管的公司至少需要規劃二級雲環境。 鑑於許多受到嚴格監管的公司規避風險的性質，這些類型的問題導致許多公司採用多雲戰略。
在合併或收購後整合 IT 系統並整合數據中心和雲環境是一項重大挑戰。 有許多因素會使這一挑戰複雜化，包括與雲提供商或託管提供商的現有合同。 與整合物理數據中心類似，整合雲工作負載可能是一項無法帶來顯著商業價值的重大工作，因此它經常因優先級更高的項目而被推遲。
最後，通常採用多雲策略來支持高可用性和災難恢復需求。 在評估 AWS 和 Azure 的主要公共雲中斷時，大多數中斷通常一次僅限於一個雲區域（並且最常見的是與軟件相關）。
越來越多的組織（根據 Flexera 報告，佔 34%）採取了額外的步驟，跨多個公共雲提供商部署他們的關鍵任務工作負載。 這對於靜態工作負載來說要容易得多，例如可以獨立運行的網站和應用程序。 對於數據庫和目錄服務（例如 Active Directory）等分佈式系統，多雲災難恢復可能更具挑戰性。
與單一云部署相比，多雲環境更複雜，因此管理起來更具挑戰性。 多雲環境中的一些獨特挑戰包括： • 端到端可見性：確保完整的可見性在任何 IT 環境中都是一項挑戰，而且在高度動態的多雲環境中，它的複雜性和挑戰性呈指數級增長。 但是，端到端可見性對於解決性能問題和瓶頸、保護您的數字足跡以及識別關鍵任務系統和應用程序中的單點故障至關重要。
• 安全和身份管理：勒索軟件和其他網絡安全威脅是當今每位 IT 領導者最關心的問題。 通過將某些安全責任（例如數據中心和物理安全）轉移到公共雲提供商並提供對加密和網絡分段等服務的按需訪問，遷移到公共雲平台通常可以改善組織的安全狀況，但它可以也更容易犯下代價高昂的錯誤。 例如，網絡錯誤配置可能很常見——數以千計的數據洩露是由配置不當的 AWS S3 存儲桶造成的。 身份管理是另一個挑戰。 例如，以前在本地環境中使用過 Active Directory 的組織可能非常熟悉 Azure Active Directory，但將身份管理從 Azure 擴展到 AWS、GCP 和 SaaS 產品（例如 Salesforce、ServiceNow、Workday 等） ) 可以引入新的挑戰。
• 應用程序和數據可移植性：在混合（多雲）環境中跨不同公共雲平台動態移動應用程序和數據的能力是許多多雲戰略的關鍵。 儘管公共雲提供商不一定會構建他們的服務來限制應用程序和數據的可移植性，但他們不一定會合作來促進此功能，並且可能會涉及成本。 不同的雲提供商也為其各種服務產品使用不同的技術。
• 多雲孤島：如果組織不針對應用程序和數據可移植性來規劃和設計其多雲部署，他們最終可能會遇到孤立的應用程序和存儲，本質上會在跨多個雲平台的傳統本地數據中心環境中重現一個常見問題。 至少，組織需要多雲安全和管理工具，使他們能夠有效地管理跨不同雲平台的風險和使用/成本。
根據 Flexera 2021 年雲狀況報告，81% 的組織將安全性列為其云部署的首要挑戰，其次是管理雲支出 (79%)。 然而，只有 42% 的組織使用多云成本管理工具，只有 38% 的組織使用多雲安全工具。
雖然多雲部署面臨許多挑戰，但它們可以提供額外的可用性，尤其是在發生重大雲中斷和災難恢復的情況下。 如果您的組織正在推行多雲戰略，您應該與值得信賴的、與云無關的合作夥伴合作，以幫助您使用整體方法設計和實施多雲部署。
為了高可用性和災難恢復，您還需要一個跨越您的多雲環境的與云無關的技術解決方案，無論您使用何種雲平台。 您總是希望避免這樣一種情況，即您的高可用性解決方案會比獨立解決方案在您的環境中導致更多的停機時間。 早期版本的 SQL Server 集群提出了這個難題——要增加磁盤空間，您必須招致停機，而這在獨立解決方案中是不會發生的。 雖然故障轉移靜態網站之類的東西可能微不足道，但移動多層應用程序堆棧在網絡和數據同步方面卻極其複雜。 您還需要避免故障轉移到安全性較低的雲環境，該環境可能由於不了解跨雲提供商的不同安全解決方案之間的細微差別而配置錯誤。
最後，在每個公共雲中，都有一些服務會迅速增加成本。 這些服務根據基於使用的定價收費，並且可能意味著僅僅幾天后成本就會急劇增加。 減輕這種風險的一種方法是確保您利用每個雲平台中的成本監控服務和警報。
雖然多雲部署並不適用於所有組織，但許多組織會走這條路。 了解網絡和安全是您最大的技術障礙之一，管理治理和成本是關鍵的功能挑戰。 測試對於確保您的多雲集群解決方案正常運行至關重要。 使用支持簡單切換和切回的高可用性集群解決方案並了解您的每個應用程序將如何工作非常重要故障轉移，最重要的是定期測試故障轉移以了解任何網絡或數據障礙。
經許可轉載自信息系統
如果這個話題聽起來令人困惑，我們明白了。 根據我們專家的建議，我們希望能緩和您的擔憂——同時在之前或之後為您的組織提出一些重要的考慮因素去多雲. 對於採用雲計算的公司來說，災難恢復規劃是一個常見的困惑點，尤其是當它涉及多個雲提供商時。
這足以確保數據保護和災難恢復(DR) 當所有數據都位於本地時。 但如今，許多公司擁有本地數據以及多個雲提供商，這種混合策略可能具有良好的商業意義，但可能會給負責數據保護的人員帶來挑戰。 在我們深入研究細節之前，讓我們定義關鍵術語。
多雲是利用兩個或多個雲提供商為組織的 IT 服務和基礎架構提供服務。 多雲方法通常由主要公共雲提供商的組合組成，即亞馬遜網絡服務 (AWS)、谷歌云平台 (GCP) 和微軟 Azure。
組織根據成本、技術要求、地理可用性和其他因素從每個雲提供商處選擇最佳服務。 這可能意味著公司使用 Google Cloud 進行開發/測試，同時使用 AWS 進行災難恢復，並使用 Microsoft Azure 來處理業務分析數據。
多云不同於混合雲，混合雲是指混合本地基礎設施、私有云服務和公共雲的計算環境。
應對這些挑戰要求公司製定涵蓋眾多問題的數據保護和恢復策略。 試著問自己以下戰略問題：
在多雲場景中成功保護和恢復數據的最大關鍵是確保您可以查看所有數據，無論數據如何存儲。 公司提供的工具使您能夠定義在災難場景中應該恢復哪些數據和應用程序以及如何恢復——例如，無論是從備份映像還是通過將數據移動到雲中新創建的虛擬機。
該工具應該可以幫助您編排恢復場景，重要的是，可以對其進行測試。 如果該工具與您的數據備份工具很好地集成在一起，它還可以讓您將備份用作恢復數據的來源，即使數據存儲在不同的位置——比如多個雲。 我們最近的 SIOS 網絡研討會討論了同一點；手錶在這裡如果你有興趣。SIOS 數據管理員讓您可以在靈活、可擴展的雲環境中運行關鍵業務應用程序，例如亞馬遜網絡服務 (AWS) ,天藍色， 和谷歌云平台在不犧牲性能、高可用性或災難保護的情況下。 SIOS DataKeeper 可在AWS 市場以及唯一的 Azure 認證的 WSFC 高可用性軟件Azure 市場。
災難發生，突然停工成為現實。但是，所有客戶都可以做的事情是在幾乎任何云中斷中存活下來。東西發生了。失敗 – 無論大小 – 都是不可避免的。不可避免的是延長的停機時間。考慮美國中南部地區的微軟Azure雲遭遇災難性失敗的那一天。一場嚴重的雷暴導致了一連串的問題，最終導致整個數據中心崩潰。在一些人稱之為“天空中的Azure雲天”中，大多數客戶都處於離線狀態，不僅僅是幾秒鐘或幾分鐘，而是一整天。有些人離線超過兩天。雖然微軟已經解決了導致停電的許多問題，但IT專業人員將長期記住這一事件。這是壞消息。好消息是：Azure客戶可以做的事情幾乎可以在任何中斷中存活。它可能來自單個服務器，無法使整個數據中心脫機。實際上，實現強大的高可用性和/或災難恢復規定的Azure客戶，無論是實時數據複製還是快速自動故障轉移，都可以避免數據丟失，並且每當發生災難時都很少或沒有停機時間。另請參閱：Nutanix認為企業雲贏得了雲計算競賽
本文介紹了在混合和純Azure雲配置中提供災難恢復（DR）和高可用性（HA）保護的四個選項。其中兩個選項特定於Microsoft SQL Server數據庫，這是Azure雲中的一個流行應用程序;另外兩個選項是與應用程序無關的。這四個選項也可用於各種組合，在表格中進行了比較，包括：
在描述這四個選項之前，有必要對用於評估DR和HA規定的有效性的兩個指標有一個基本的了解：恢復時間目標和恢復點目標。熟悉RTO和RPO的人可以跳過本節。RTO是中斷的最大可容忍持續時間。在線事務處理應用程序通常具有最低的RTO，而關鍵任務應用程序通常具有僅幾秒的RTO。RPO是可以容忍數據丟失的最長期限。如果不能容忍數據丟失，則RPO為零。RTO通常會確定所需的HA和/或DR保護的類型。低恢復時間通常需要強大的HA規定來防止日常系統和軟件故障，而較長的RTO可以滿足基本DR規定，旨在防範更廣泛但更不頻繁的災難。與HA和DR規定一起使用的數據複製可能需要在RTO和RPO之間進行潛在的權衡。在低延遲LAN環境中，複製可以是同步的，可以同時更新主數據集和輔助數據集。這使得完全恢復能夠自動且實時地發生，從而可以滿足最苛刻的恢復時間和恢復點目標（分別為幾秒和零），無需權衡。相反，在整個WAN中，強制主要服務器等待輔助服務器確認每個事務的更新完成將對性能產生負面影響。因此，WAN中的數據複製通常是異步的。這可以在容納RTO和RPO之間進行權衡，這通常會導致恢復時間的增加。原因如下：為了滿足零RPO，需要手動過程以確保在故障轉移發生之前所有數據（例如來自事務日誌）已在輔助設備上完全複製這種額外的工作會延長恢復時間，這就是為什麼這樣的配置通常用於DR而不是HA。
ASR是Azure的DR-as-a-service（DRaaS）產品。ASR將物理機和虛擬機複製到其他Azure站點，可能在其他區域，或從本地實例複製到Azure雲。該服務可以從系統和站點中斷中快速恢復，並通過消除滾動軟件升級期間的停機時間來促進計劃內維護。與所有DRaaS產品一樣，ASR有一些限制，最嚴重的是無法自動檢測和故障轉移導致應用程序級停機的許多故障。當然，這就是為什麼該服務被定性為DR而不是HA的原因。使用ASR，恢復時間通常為3-4分鐘，當然，這取決於管理員能夠以多快的速度手動檢測和響應問題。如上所述，跨WAN的異步數據複製的需求可以進一步增加RPO為零的應用程序的恢復時間。
SQL Server提供了兩個自己的HA / DR選項：故障轉移群集實例（此處討論）和Always On Availability Groups（下面討論）。FCI提供兩個優點：該功能可以在較便宜的SQL Server標準版中使用，並且它不依賴於像傳統HA集群那樣的共享存儲。後一個優勢很重要，因為雲中的共享存儲根本不可用 – 來自Microsoft或任何其他雲服務提供商。Azure雲存儲的一個流行選擇是Storage Spaces Direct（S2D），它支持廣泛的應用程序，它對SQL Server的支持保護整個實例而不僅僅是數據庫。S2D的一個主要缺點是服務器必須位於單個數據中心內，這使得該選項適用於某些HA需求，但不適用於DR。對於多站點HA和DR保護，需要通過日誌傳送或第三方故障轉移群集解決方案提供必需的數據複製。
雖然Always On Availability Groups是SQL Server為HA和DR提供的最強大的產品，但它需要許可更昂貴的Enterprise Edition。此選項可以提供5-10秒的恢復時間和幾秒或更短的恢復點。它還提供可讀的輔助數據庫，用於查詢數據庫（具有適當的許可），並且不對數據庫的大小或輔助實例的數量進行限制。提供HA和DR保護的Always On Availability Groups配置包括三個節點的安排，在單個可用性集或區域中有兩個節點，第三個在單獨的Azure區域中。一個值得注意的限制是只複製數據庫，而不是整個SQL實例，必須通過其他方式進行保護。除了對某些數據庫應用程序成本過高之外，這種方法還有另一個缺點。特定於應用程序需要IT部門為所有其他應用程序實施其他HA和DR規定。使用多個HA / DR解決方案可能會大大增加複雜性和成本（用於許可，培訓，實施和持續運營），這也是組織越來越傾向於使用與應用程序無關的第三方解決方案的另一個原因。
憑藉其與應用程序無關且與平台無關的設計，故障轉移群集軟件能夠為私有，公共和混合雲環境中的幾乎所有應用程序提供完整的HA和DR解決方案。這包括Windows和Linux。與應用程序無關，無需為不同的應用程序提供不同的HA / DR規定。與平台無關，可以利用Azure雲中的各種功能和服務，包括故障域，可用性集和區域，區域對和Azure站點恢復。作為完整的解決方案，該軟件至少包括實時數據複製，能夠檢測應用程序級故障的連續監視，以及用於故障轉移和故障恢復的可配置策略。大多數解決方案還提供各種增值功能，使故障轉移群集能夠在幾乎沒有數據丟失的情況下提供低於20秒的恢復時間，從而滿足幾乎所有HA / DR需求。
無論是單獨運行還是一致運行，所有這四個選項都可以發揮作用，使DR和HA保護的連續性對於各種企業應用程序更有效和更實惠。這包括那些能夠容忍一些數據丟失和延長的停機時間的系統，以及那些需要實時恢復以實現5到9個正常運行時間且數據丟失很少或沒有數據丟失的系統。為了在現實世界中實現下一次雲中斷，請確保您選擇的任何DR和/或HA規定配置為至少兩個節點分佈在兩個站點上。還要確保了解條款滿足每個應用程序的恢復時間和恢復點目標的程度。以及可能存在的任何限制，包括檢測所有可能的故障所需的手動過程，以及確保應用程序連續性和數據完整性的方式觸發故障轉移。
Jonathan Meltzer是SIOS Technology的產品管理總監。他在軟件和SaaS產品的產品管理和營銷方面擁有20多年的經驗，可幫助客戶管理，轉換和優化其人力資本和IT資源。從RTinsights轉載