SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 產品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 伺服器集群简单化
  • 成功案例
    • 台灣成功案例
  • 聯繫我們
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

多雲容災

30 10 月, 2021 by Jason Aw Leave a Comment

多雲容災

多雲容災

 

如果這個話題聽起來令人困惑,我們明白了。 根據我們專家的建議,我們希望能緩和您的擔憂——同時在之前或之後為您的組織提出一些重要的考慮因素去多雲. 對於採用雲計算的公司來說,災難恢復規劃是一個常見的困惑點,尤其是當它涉及多個雲提供商時。

這足以確保數據保護和災難恢復(DR) 當所有數據都位於本地時。 但如今,許多公司擁有本地數據以及多個雲提供商,這種混合策略可能具有良好的商業意義,但可能會給負責數據保護的人員帶來挑戰。 在我們深入研究細節之前,讓我們定義關鍵術語。

什麼是多雲?

多雲是利用兩個或多個雲提供商為組織的 IT 服務和基礎架構提供服務。 多雲方法通常由主要公共雲提供商的組合組成,即亞馬遜網絡服務 (AWS)、谷歌云平台 (GCP) 和微軟 Azure。

組織根據成本、技術要求、地理可用性和其他因素從每個雲提供商處選擇最佳服務。 這可能意味著公司使用 Google Cloud 進行開發/測試,同時使用 AWS 進行災難恢復,並使用 Microsoft Azure 來處理業務分析數據。

多云不同於混合雲,混合雲是指混合本地基礎設施、私有云服務和公共雲的計算環境。

誰使用多個雲?

  • 受管制行業 –許多組織在不同的雲環境中運行不同的業務運營。 這可能是基於單個雲提供商的優勢或僅僅是分散 IT 組織的產品優化其 IT 環境的深思熟慮的策略。
  • 媒體和娛樂– 當今的媒體和娛樂領域越來越多地由相對較小的專業工作室組成,這些工作室滿足了 Netflix 和 Hulu 等最大玩家不斷膨脹的內容製作需求。 多雲解決方案使這些團隊能夠在同一項目上協同工作,從各種公共雲訪問他們喜歡的製作工具,並簡化審批流程,而不會因將大型媒體文件從一個站點移動到另一個站點而出現延遲。
  • 交通與自動駕駛– 聯網汽車和自動駕駛項目從各種傳感器生成大量數據。 汽車製造商、公共交通機構和拼車公司都積極利用多雲創新,將跨多個雲的數據可訪問性融合在一起,而沒有高額出口費用和緩慢傳輸的風險,同時保持利用最佳的自由每個項目的公共雲服務。
  • 能源部門– 採用多云有助於降低與資源查找和鑽探相關的大量成本。工程師和數據科學家可以使用機器學習 (ML) 分析來確定值得更多資源來勘探石油的地方,以衡量新項目的環境風險並提高安全性。

多雲容災痛點:

  • 簽之前不看。如果客戶未能閱讀雲協議中的細則,他們可能會遇到問題。 雲提供商負責其計算機基礎設施,但客戶負責保護他們的應用程序和數據。 雲 SLA 未涵蓋應用程序停機的原因有很多。 關鍵業務工作負載也需要高可用性和災難恢復保護軟件。
  • 制定集中保護政策。必須創建集中保護策略以涵蓋所有數據,無論數據位於何處。 每個雲提供商都有其獨特的訪問、創建、移動和存儲數據的方式,具有不同的存儲層。 創建涵蓋跨不同雲的數據的災難恢復計劃可能很麻煩。
  • 報告。這對於確保根據管理數據的服務級別協議保護數據非常重要。 鑑於用戶啟動雲資源的速度有多快,確保適當保護每個資源並確定需要納入 DR 計劃的所有數據可能具有挑戰性。
  • 測試您的災難恢復計劃。客戶必須全面篩选和測試他們的 DR 策略。 多雲策略增加了對測試的需求。 一些供應商可能會向客戶收取測試費用,這加強了閱讀合同細則的必要性。
  • 資源技能集. 在一個雲中尋找專家可能具有挑戰性;對於多雲,您要么需要在每個雲中找到專業知識,要么需要在多個雲中找到具有重要意義的稀有個體。

克服多雲災難恢復挑戰

應對這些挑戰要求公司製定涵蓋眾多問題的數據保護和恢復策略。 試著問自己以下戰略問題:

  • 您是否為所有應用程序和數據定義了關鍵級別? 關鍵應用程序的幾分鐘停機時間會使您的組織在最終用戶生產力、客戶滿意度和 IT 勞動力方面損失多少錢?
  • 數據保護和恢復是否由 IT 或應用程序所有者和創建者以自助服務模式處理?
  • 您是否計劃使用各種基於雲和本地的選項來優化數據?
  • 您打算如何恢復數據? 將數據恢復到基於雲的虛擬機還是使用備份映像作為恢復源?

獲得正確的多雲災難恢復解決方案

在多雲場景中成功保護和恢復數據的最大關鍵是確保您可以查看所有數據,無論數據如何存儲。 公司提供的工具使您能夠定義在災難場景中應該恢復哪些數據和應用程序以及如何恢復——例如,無論是從備份映像還是通過將數據移動到雲中新創建的虛擬機。

該工具應該可以幫助您編排恢復場景,重要的是,可以對其進行測試。 如果該工具與您的數據備份工具很好地集成在一起,它還可以讓您將備份用作恢復數據的來源,即使數據存儲在不同的位置——比如多個雲。 我們最近的 SIOS 網絡研討會討論了同一點;手錶在這裡如果你有興趣。SIOS 數據管理員讓您可以在靈活、可擴展的雲環境中運行關鍵業務應用程序,例如亞馬遜網絡服務 (AWS) ,天藍色, 和谷歌云平台在不犧牲性能、高可用性或災難保護的情況下。 SIOS DataKeeper 可在AWS 市場以及唯一的 Azure 認證的 WSFC 高可用性軟件Azure 市場。

轉載自SIOS

Filed Under: 伺服器集群简单化 Tagged With: Google雲端平台, 多雲

管理主要雲中斷中的實時恢復

19 1 月, 2019 by Jason Aw Leave a Comment

管理主要雲中斷中的實時恢復

在重大雲中斷中管理實時恢復

災難發生,突然停工成為現實。但是,所有客戶都可以做的事情是在幾乎任何云中斷中存活下來。東西發生了。失敗 – 無論大小 – 都是不可避免的。不可避免的是延長的停機時間。考慮美國中南部地區的微軟Azure雲遭遇災難性失敗的那一天。一場嚴重的雷暴導致了一連串的問題,最終導致整個數據中心崩潰。在一些人稱之為“天空中的Azure雲天”中,大多數客戶都處於離線狀態,不僅僅是幾秒鐘或幾分鐘,而是一整天。有些人離線超過兩天。雖然微軟已經解決了導致停電的許多問題,但IT專業人員將長期記住這一事件。這是壞消息。好消息是:Azure客戶可以做的事情幾乎可以在任何中斷中存活。它可能來自單個服務器,無法使整個數據中心脫機。實際上,實現強大的高可用性和/或災難恢復規定的Azure客戶,無論是實時數據複製還是快速自動故障轉移,都可以避免數據丟失,並且每當發生災難時都很少或沒有停機時間。另請參閱:Nutanix認為企業雲贏得了雲計算競賽

管理雲中斷

本文介紹了在混合和純Azure雲配置中提供災難恢復(DR)和高可用性(HA)保護的四個選項。其中兩個選項特定於Microsoft SQL Server數據庫,這是Azure雲中的一個流行應用程序;另外兩個選項是與應用程序無關的。這四個選項也可用於各種組合,在表格中進行了比較,包括:

  • Azure站點恢復(ASR)服務
  • 具有存儲空間直接的SQL Server故障轉移群集實例
  • SQL Server始終在可用性組
  • 第三方故障轉移群集軟件

RT Insights SIOS_Real-timeRecovery for Cloud Outage_181119

RTO和RPO 101

在描述這四個選項之前,有必要對用於評估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。

Azure站點恢復(ASR)服務

ASR是Azure的DR-as-a-service(DRaaS)產品。ASR將物理機和虛擬機複製到其他Azure站點,可能在其他區域,或從本地實例複製到Azure雲。該服務可以從系統和站點中斷中快速恢復,並通過消除滾動軟件升級期間的停機時間來促進計劃內維護。與所有DRaaS產品一樣,ASR有一些限制,最嚴重的是無法自動檢測和故障轉移導致應用程序級停機的許多故障。當然,這就是為什麼該服務被定性為DR而不是HA的原因。使用ASR,恢復時間通常為3-4分鐘,當然,這取決於管理員能夠以多快的速度手動檢測和響應問題。如上所述,跨WAN的異步數據複製的需求可以進一步增加RPO為零的應用程序的恢復時間。

具有存儲空間直接的SQL Server故障轉移群集實例

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保護,需要通過日誌傳送或第三方故障轉移群集解決方案提供必需的數據複製。

SQL Server始終在可用性組

雖然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

Jonathan Meltzer是SIOS Technology的產品管理總監。他在軟件和SaaS產品的產品管理和營銷方面擁有20多年的經驗,可幫助客戶管理,轉換和優化其人力資本和IT資源。從RTinsights轉載

Filed Under: 新闻与活动 Tagged With: 多雲, 微軟天藍色, 服務器故障轉移, 網絡安全, 雲停運

最近的帖子

  • 視頻:SIOS 優勢
  • AWS 中三節點集群的 SIOS DataKeeper 演示
  • 2023 年預測:數據民主化將推動對高可用性的需求
  • 了解業務關鍵型應用程序高可用性的複雜性
  • Epicure 使用 Amazon EC2 和 SIOS SANLess 集群軟件保護關鍵業務 SQL Server

最熱門的帖子

加入我們的郵件列表

Copyright © 2023 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in