SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

Azure Outage Post-Mortem第1部分

6 11 月, 2018 by Jason Aw Leave a Comment

Azure的停電,驗屍-PT-1

Azure Outage Post-Mortem

關於上週發生的Azure Outage,第一次官方Post-Mortems開始出現在微軟上面。第一個Azure Outage Post-Mortem專門解決Azure DevOps中斷問題(以前稱為Visual Studio Team Service或VSTS)。它為我們提供了一些關於中斷的廣度和深度的額外見解。它證實了停電的原因。它還讓我們深入了解了微軟在快速恢復在線狀態時所面臨的挑戰。此外,它暗示了微軟可能會考慮在未來更好地處理這種情況的一些特性/功能。正如我在上一篇文章中提到的,Azure中推出的新可用區等功能可能會最大限度地減少此次中斷的影響。在驗屍中,微軟確認了我之前所說的內容。

我們正在努力改進處理數據中心故障的主要解決方案是可用區,我們正在探索異步複製的可行性。

其他預防措施

在可用區域跨越更多區域推出唯一的災難恢復選項之前,您需要跨區域,混合雲甚至跨雲異步複製。目前可用的基於軟件的#SANless群集解決方案將實現此類配置。 提供非常強大的RTO和RPO,即使在復制很遠的距離時也是如此。借助SaaS / PaaS解決方案,您可以依靠雲服務提供商(CSP)來實施具有鐵的HA / DR解決方案。在這種情況下,似乎有一個非常重要的缺陷暴露。我們只能希望它能引導所有CSP仔細研究他們的SaaS / PaaS產品。以及解決可能存在的任何HA / DR差距。在此之前,消費者有責任了解風險。他們需要盡其所能來降低延長中斷的風險,或者只是在風險得到解決之前選擇不使用PaaS / SaaS。

RTO還是RPO?

驗屍確實是問題的根源……你更重視什麼,RTO或RPO?

我從根本上不想為客戶決定是否接受數據丟失。我有客戶告訴我他們會花費數據丟失來讓一個大型團隊再次快速生產,其他客戶告訴我他們不希望任何數據丟失,並且等待恢復時間不長。

CSP不可能為客戶做出決定。CSP不希望丟失客戶數據,除非原始數據完全丟失且無法恢復。在這種情況下,近乎實時的異步副本與您在意外故障中獲得的RPO一樣好。然而,這次停電是否真的出乎意料而且沒有任何警告?現代衛星圖像和天氣預報的改進給予了公平的警告,該地區將發生重大的天氣相關事件。當我寫這篇文章時,颶風佛羅倫薩正在美國東南部。如果數據中心位於路徑中,請採取主動措施將工作負載移出受影響的區域。主動災難恢復與反應式災難恢復的好處很多。沒有數據丟失,有足夠的時間來解決意外問題。它還包括管理人力資源,使員工可以擔心照顧家人,而不是工作。同樣,制定主動的災難恢復將是CSP代表其所有客戶做出的艱難決定。跨地區的計劃遷移將導致一定程度的停機。這個決定必須由客戶掌握。從Azure Outage Post-Mortem中吸取教訓,教育您的客戶。

Slide 2.png
颶風佛羅倫薩衛星圖像取自新的GOES-16衛星,由Tropical Tidbits提供

得到保護

那麼您可以做些什麼來保護您的業務關鍵應用程序和數據?讓我們從Azure Outage Post-Mortem中汲取一些教訓。採用基於軟件的#SANless集群解決方案的跨區域,跨雲或混合雲模型將大大有助於解決您的HA / DR問題。此外,它還為基於雲的IaaS部署提供了出色的RTO和RPO。除應用程序特定解決方案外,還有其他選項。基於軟件的塊級卷複製解決方案(如SIOS DataKeeper和SIOS Protection Suite)可複制所有數據,並為Linux和Windows平台提供數據保護解決方案。我的大兒子剛剛在羅格斯大學開始他的氣象學本科學位。想像一下,人工智能(AI)和機器學習(ML)處理來自NOAA的天氣相關數據的那一天。他們可以在暴風雨襲擊前兩天觸發計劃的災難恢復遷移?我想我剛剛為他的碩士論文找到了一個完美的主題。或者更好的是,讓他和他在WeatherWatcher LLC的聰明的朋友獲得資金,為一家技術創業公司應用AI和ML來安排相關數據以控制主動災難恢復事件。我認為我們正處於IT分析解決方案的尖端。我們可以應用先進的機器學習技術來減少確保關鍵應用程序服務交付的時間和精力。 SIOS iQ是該領域領先的解決方案之一。壓扁艙口並做好準備。颶風季剛剛開始,我們已經開始瘋狂騎行了。如果您想在Twitter @daveberm上討論您的HA / DR策略,請與我聯繫。

在這裡閱讀其他Azure Outage Post-Mortem
經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化

在Azure跨可用區中配置文件服務器故障轉移群集

5 11 月, 2018 by Jason Aw Leave a Comment

配置 - 文件服務器故障轉移群集功能於Azure的跨可用性 - 區

循序漸進:在Azure跨越可用區中配置文件服務器群集

配置 - 文件服務器故障轉移群集功能於Azure的跨可用性 - 區

循序漸進:在Azure跨越可用區中配置文件服務器群集

在本文中,我們將詳細介紹在Azure中部署跨越新可用區的雙節點文件服務器故障轉移群集所需的特定步驟。我將假設您熟悉基本的Azure概念以及基本的故障轉移群集概念。我將重點介紹在Azure中跨可用區部署文件服務器故障轉移群集的獨特之處。如果您的Azure區域尚不支持可用區,則必須使用Fault Domains,如前面的帖子中所述。使用DataKeeper Cluster Edition,您可以獲取本地連接的託管磁盤,無論是高級磁盤還是標準磁盤,並在兩個或多個集群節點之間同步,異步或混合或同時復制這些磁盤。此外,DataKeeper Volume資源在Windows Server故障轉移群集中註冊,該資源取代了物理磁盤資源。DataKeeper Volume不是像物理磁盤資源那樣控制SCSI-3保留,而是控製鏡像方向。它確保活動節點始終是鏡像的源。就故障轉移群集而言,它的外觀,感覺和氣味就像物理磁盤一樣,其使用方式與物理磁盤資源的使用方式相同。

先決條件

  • 您之前使用過Azure Portal,並且很樂意在Azure IaaS中部署虛擬機。
  • 已獲得SIOS DataKeeper的許可證或eval許可證

在Azure中部署文件服務器故障轉移群集

要在Azure中構建雙節點文件服務器故障轉移群集實例,我們假設您具有基於Azure資源管理器的基本虛擬網絡。您至少有一個虛擬機已啟動並正在運行並配置為域控制器。配置虛擬網絡和域後,您將配置兩個新虛擬機,它們將充當群集中的兩個節點。我們的環境將如下所示:DC1 – 我們的域控制器和文件共享見證SQL1和SQL2 – 文件服務器群集的兩個節點。不要讓這些名字讓你感到困惑。我們正在本指南中構建文件服務器群集。在我的下一篇文章中,我將演示SQL Server群集配置。

配置兩個群集節點

使用Azure門戶,我們將以完全相同的方式配置SQL1和SQL2。  有多種選擇可供選擇,包括實例大小,存儲選項等。本指南並不是在Azure中部署服務器的詳盡指南。 有一些非常好的資源,每天都有更多的資源。但是,在創建實例時要記住幾個關鍵事項,尤其是在群集環境中。可用區 – SQL1,SQL2駐留在不同的可用區中非常重要。為了本指南的目的,我們假設您使用的是Windows 2016,並將使用Cloud Witness進行群集仲裁。如果使用Windows 2012 R2或Windows Server 2008 R2而不是Windows 2016,則需要在第3個可用區中配置文件共享見證。直到Windows Server 2016才推出Cloud Witness。通過將群集節點放在不同的可用區中,我們確保每個群集節點位於同一區域中的不同Azure數據中心。利用可用區而不是舊的故障域是有益的。它將您與幾週前發生的中斷類型隔離開來,這些中斷使整個中南部地區連續多天。請務必將每個群集節點添加到其他可用區。如果您利用文件共享見證,它應該位於第三個可用區。[/ caption]

靜態IP地址

配置每個VM後,您將需要進入設置並更改設置,以使IP地址為靜態。我們不希望更改群集節點的IP地址。確保每個群集節點都使用靜態IP [/ caption]

存儲

就存儲而言,您將需要參考Azure虛擬機中SQL Server的性能最佳實踐。在任何情況下,您至少需要為每個群集節點添加至少一個額外的託管磁盤。DataKeeper可以在本地存儲空間中使用基本磁盤,高級存儲甚至多個磁盤。如果您確實要使用本地存儲空間,請注意在任何群集配置之前創建存儲空間。這是由於故障轉移群集和本地存儲空間的已知問題。所有磁盤都應格式化為NTFS。

創建群集

假設已按上述方式配置了兩個群集節點(SQL1和SQL2)並將其添加到現有域中,我們就可以創建群集了。在創建群集之前,需要啟用一些功能。這些功能是.Net Framework 3.5和故障轉移群集。需要在兩個群集節點上啟用這些功能。您還需要啟用FIle服務器角色。在兩個群集節點上啟用.Net Framework 3.5和故障轉移群集功能以及文件服務器。[/ caption]一旦啟用了該角色和這些功能,您已準備好構建群集。我要向您展示的大多數步驟都可以通過PowerShell和GUI執行。但是,我將建議您在第一步中使用PowerShell創建群集。如果您選擇使用故障轉移群集管理器GUI來創建群集,您將發現最終會向群集發出重複的IP地址。在不詳細介紹的情況下,您會發現Azure VM必須使用DHCP。通過在Azure門戶中創建VM時指定“靜態IP”,我們所做的就是創建一種DHCP預留。它不完全是DHCP保留,因為真正的DHCP保留會從DHCP池中刪除該IP地址。相反,在Azure門戶中指定靜態IP只是意味著如果在VM請求它時該IP地址仍然可用,Azure將向其發出該IP。但是,如果您的VM處於脫機狀態且另一台主機在同一子網中聯機,則可能會發出相同的IP地址。

Azure如何實現DHCP的另一個副作用

使用Windows Server Failover Cluster GUI創建群集時,無法指定群集IP地址。相反,它依靠DHCP來獲取地址。奇怪的是,DHCP將發出重複的IP地址。通常與請求新IP地址的主機具有相同的IP地址。群集安裝將完成,但您可能會遇到一些奇怪的錯誤。您可能需要從其他節點運行Windows Server Failover Cluster GUI才能使其運行。一旦運行它,您將需要將核心群集IP地址更改為網絡上當前未使用的地址。只需通過Powershell創建集群並指定集群IP地址作為PowerShell命令的一部分來創建集群,就可以避免這種混亂。您可以使用New-Cluster命令創建集群,如下所示:

New-Cluster -Name cluster1 -Node sql1,sql2 -StaticAddress 10.0.0.100 -NoStorage

群集創建完成後,您還需要運行以下命令來運行群集驗證。您應該會看到有關存儲和網絡的一些警告,但這在Azure中是可以預期的,您可以忽略這些警告。如果報告任何錯誤,您需要在繼續之前解決這些錯誤。

測試群集

創建仲裁群集

如果您運行的是Windows 2016或2019,則需要為群集仲裁創建Cloud Witness。如果您運行的是Windows Server 2012 R2或2008 R2,則需要創建文件共享見證。關於證人創建的詳細說明可以在這裡找到。

安裝DataKeeper

創建集群後,就可以安裝DataKeeper了。在創建初始群集後安裝DataKeeper非常重要,這樣可以向群集註冊自定義群集資源類型。如果在創建群集之前安裝了DataKeeper,則只需再次運行安裝並執行修復安裝。在創建群集後安裝DataKeeper [/ caption]在安裝過程中,您可以使用所有默認選項。 您使用的服務帳戶必須是域帳戶,並且位於群集中每個節點上的本地管理員組中。9 服務帳戶必須是每個節點上Local Admins組中的域帳戶一旦安裝DataKeeper並在每個節點上獲得許可,您將需要重新啟動服務器。

創建DataKeeper卷資源

10 要創建DataKeeper Volume Resource,您需要啟動DataKeeper UI並連接到這兩個服務器。連接到SQL1 [/ caption] 連接到SQL2 [/ caption]連接到每個服務器後,即可創建DataKeeper卷。右鍵單擊Jobs並選擇“Creat13e Job”為作業命名和描述。14 選擇源服務器,IP和卷。IP地址是複制流量是否會傳播。15 選擇目標服務器。16 選擇你的選擇。對於兩個VM位於同一地理區域的目的,我們將選擇同步複製。對於更長距離的複制,您將需要使用異步並啟用一些壓縮。17 通過在上次彈出窗口中單擊“是”,您將在故障轉移群集中的可用存儲中註冊新的DataKeeper卷資源。18 您將在可用存儲中看到新的DataKeeper卷資源。19

創建文件服務器群集資源

要創建文件服務器群集資源,我們將再次使用Powershell而不是故障轉移群集接口。原因在於,再次因為虛擬機配置為使用DHCP,基於GUI的嚮導不會提示我們輸入群集IP地址,而是發出重複的IP地址。為避免這種情況,我們將使用簡單的powershell命令創建FIle Server群集資源並指定IP地址

Add-ClusterFileServerRole -Storage“DataKeeper Volume E”-Name FS2 -StaticAddress 10.0.0.101

記下您在此處指定的IP地址。它必須是網絡上唯一的IP地址。我們稍後在創建內部負載均衡器時將使用相同的IP地址。

創建內部負載均衡器

以下是Azure中的故障轉移群集與傳統基礎結構的不同之處。Azure網絡堆棧不支持免費ARPS,因此客戶端無法直接連接到群集IP地址。相反,客戶端連接到內部負載平衡器並重定向到活動群集節點。我們需要做的是創建一個內部負載均衡器。這可以通過Azure門戶完成,如下所示。如果客戶端通過公共Internet連接,則可以使用公共負載均衡器。但假設您的客戶端位於同一個vNet中,我們將創建一個內部負載均衡器。需要注意的重要一點是,虛擬網絡與群集節點所在的網絡相同。此外,您指定的專用IP地址將與用於創建文件服務器群集資源的地址完全相同。此外,由於我們使用的是可用區,因此我們將創建一個區域冗餘標準負載均衡器,如下圖所示。負載均衡器 創建內部負載均衡器(ILB)後,您需要對其進行編輯。我們要做的第一件事就是添加一個後端池。通過此過程,您將選擇兩個群集節點。後端池 接下來我們要做的就是添加一個Probe。我們添加的探針將探測端口59999。此探針確定群集中哪個節點處於活動狀態。探測 最後,我們需要一個負載平衡規則來重定向SMB流量,TCP端口445。在下面的屏幕截圖中需要注意的重要事項是直接服務器返回已啟用。確保你做出改變。規則

修復文件服務器IP資源

配置的最後一步是在其中一個群集節點上運行以下PowerShell腳本。這將允許群集IP地址響應ILB探測。還要確保群集IP地址和ILB之間沒有IP地址衝突。請注意;您需要編輯此腳本以適合您的環境。子網掩碼設置為255.255.255.255。 這不是一個錯誤,保持原樣。這將創建一個特定於主機的路由,以避免與ILB發生IP地址衝突。

#定義變量
$ ClusterNetworkName =“” 
#群集網絡名稱(在更高的Windows Server 2012上使用Get-ClusterNetwork查找名稱)
$ IPResourceName =“” 
#IP地址資源名稱 
$ ILBIP =“” 
#內部負載均衡器的IP地址(ILB)
導入模塊FailoverClusters
#如果您使用的是Windows Server 2012或更高版本:
Get-ClusterResource $ IPResourceName | Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”; Network = $ ClusterNetworkName; EnableDhcp = 0}
#如果您使用的是Windows Server 2008 R2,請使用以下命令: 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999 subnetmask = 255.255.255.255

創建文件共享

您會發現在故障轉移群集管理器中使用文件共享嚮導不起作用。相反,您只需在活動節點上的Windows資源管理器中創建文件共享。故障轉移群集會自動獲取這些共享並將其放入群集中。請注意,此配置不支持文件共享的“連續可用性”選項。

結論

您現在應該在Azure中具有可用的文件服務器故障轉移群集,該群集跨越可用區。 如果您需要DataKeeper評估密鑰,請填寫http://us.sios.com/clustersyourway/cta/14-day-trial上的表格,SIOS將發送一份發送給您的評估密鑰。

要了解有關群集的更多信息,請單擊此處
經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化 Tagged With: 天藍色的文件服務器故障轉移群集, 文件服務器

快速入門指南:Windows Server 2008 R2中的SQL Server群集在Azure中

4 11 月, 2018 by Jason Aw Leave a Comment

SQL-Server的集群,在窗口 - 服務器2008 R2-IN-天青

快速入門指南:Windows Server 2008 R2中的SQL Server群集在Azure中

Windows Server 2008 R2繼續存在於雲中。因此,這是一個快速入門指南,適用於在Windows Server 2008 R2上需要SQL Server群集幫助的所有人。是的,Azure確實支持Windows Server 2008 R2和舊版本的SQL Server,包括2008 R2和2012。當然,在SQL 2012之前不會引入Always On Availability Groups,即便如此,由於與該版本相關的一些性能問題,您可能希望避免可用性組。需要支持舊版本的SQL Server或Windows嗎?如Azure文檔中所述,基於SIOS DataKeeper構建SANless群集。

快速入門指南:Windows Server 2008 R2中的SQL Server群集在Azure中
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr

Windows Server 2008 R2上的SQL Server群集 – 如何完成?

簡而言之,這是SQL Server群集在Windows Server 2008 R2上的步驟

  • 在同一可用性集中配置兩個群集服務器和一個文件共享見證。這將所有三個法定人數投票放在不同的故障和更新域中。
  • Azure中的SQL 2008 R2群集有一個修補程序,用於啟用AG和FCI使用的偵聽器。 https://support.microsoft.com/en-us/help/2854082/update-enables-sql-server-availability-group-listeners-on-windows-serv
  • 安裝該更新以及所有其他OS更新。
  • 在每台服務器上配置存儲。
  • 格式化NTFS並給出驅動器號。
  • 每個群集節點需要相同的存儲。在每台服務器上啟用故障轉移群集和.Net 3.5 Framework
  • 將服務器添加到域
  • 創建基本群集,但使用POWERSHELL並指定群集IP地址。如果您使用GUI來創建群集,它將會混淆並提供重複的IP地址。通過GUI連接將使您能夠從其中一個節點連接到群集。如果連接,則可以通過指定群集資源使用的靜態IP地址來解決問題。以下是創建群集的Powershell用法示例
    New-Cluster -Name cluster1 -Node sql1,sql2 -StaticAddress 10.0.0.101 -NoStorage-
  • 將文件共享見證添加到群集
  • 在兩個群集節點上安裝DataKeeper
  • 創建DataKeeper卷資源並確保它們是可用存儲
  • 像往常一樣在共享存儲群集中將SQL安裝到群集中。
  • 配置Azure ILB並運行powershell腳本以更新SQL群集IP資源以偵聽探測端口。

所有這些都在SIOS文檔頁面上完整記錄,在Azure中部署DataKeeper Cluster Edition如果您對Azure,AWS或Google Cloud中的SQL Server高可用性或災難恢復有任何疑問,請訪問我們關於群集和其他相關主題的頁面。 經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化 Tagged With: SQL Server, Windows Server 2008 r2上的sql server集群

在簡單的存儲空間中將多個磁盤一起剝離

2 11 月, 2018 by Jason Aw Leave a Comment

在簡單的存儲空間中將多個磁盤一起剝離

在簡單的存儲空間中將多個磁盤一起剝離

在簡單的存儲空間中將多個磁盤一起剝離

在簡單的存儲空間中將多個磁盤一起剝離

您正在使用SIOS DataKeeper構建SANless SQL Server群集。或者您可能正在為SQL Server配置Always On Availability Groups。如何嘗試在簡單存儲空間(RAID 0)中將多個磁盤拆分以獲得性能?這通常在雲中完成,其中每個實例通常都有硬件彈性支持,因此RAID 0並非真正具有風險。例如,我最近在AWS中有一個客戶希望將其IOPS最大化到80,000 – 當前可用於單個實例的最大IOPS。現在請記住,只有最大的EBS優化實例大小才支持80,000 IOPS。因此,請確保您知道特定實例大小支持的最大IOPS。https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html在這種情況下,我們有ac5.18xlarge實例,它支持80,000 IOPS。但是,任何單個EBS預配置IOPS卷僅支持最高32,000 IOPS。寫入任何單個卷時實現80,000 IOPS的唯一方法是在Simple Storage Space中將這些卷中的三個一起剝離。這就是摩擦。如果您嘗試在現有群集中的簡單存儲空間中對多個磁盤進行剝離,那麼事情就會變得非常快。MVP Joey D'Antoni最近在博客上發表了關於這個問題的博文。它似乎仍然是Windows Server 2019預覽中的一個問題。正如Joey所說,我總是建議我的客戶在開始集群過程之前構建節點和任何存儲空間。這使得在簡單存儲空間中將多個磁盤剝離在一起的過程變得更加順暢。它還允許客戶在添加任何復制之前有時間對服務器的性能進行基準測試。並確保一切按預期工作。熱衷於了解更多關於如何在簡單存儲空間中將多個磁盤捆綁在一起的快速提示,請查看我們關於群集的其他帖子經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化 Tagged With: 在簡單的存儲空間中將多個磁盤一起剝離

如何生存Azure雲中斷

31 10 月, 2018 by Jason Aw Leave a Comment

如何在蔚藍的停電中生存

閃電從不打擊兩次:倖存Azure雲中斷

昨天早上我打開了我的Twitter訂閱源,發現很多人都受到了Azure Cloud中斷的影響。幾乎每個關於中斷的資源頁面都不可用。幸運的是,@ AzureSupport繼續通過Twitter提供更新。來自@AzureSupport的原始更新於美國東部如何生存Azure雲中斷時間上午7:12發布。回顧Twitter推文,似乎問題最初是在此之前的一兩個小時開始的。如何生存Azure雲中斷 很明顯,這次中斷的傳播影響比最初報導的美國中南部地區更廣泛。似乎依賴Azure Active Directory的服務也可能受到影響,並且嘗試配置新訂閱的客戶遇到了問題。如何生存Azure雲中斷 24小時後問題還沒有完全解決,根據今天上午的最新更新…如何生存Azure雲中斷那如何生存Azure雲中斷麼你可以做些什麼來減少這種蔚藍雲停電的影響?沒有人可以責怪微軟發生雷擊等自然災害。但是在一天結束的時候,如果您唯一的災難恢復計劃是打電話,發推特並通過電子郵件發送電子郵件直到問題得到解決,那麼您剛剛收到了一個粗魯的覺醒。在您的災難恢復計劃中,您需要確保涵蓋所有基礎。

是時候探索一些替代品?

雖然灰塵仍在準確定位受影響的內容以及客戶可以採取哪些措施來最大限度地減少停機時間,但這裡有一些我最初的想法。

可用性集(故障域/更新域)

在這種情況下,即使您構建了故障轉移群集,或利用Azure負載均衡器和可用性集,您仍然會因為整個區域脫機而運氣不佳。雖然仍建議使用可用性集,尤其是計劃停機時間,但在這種情況下,您仍然可以脫機。

可用區域

它尚未在美國中南部地區推出。然而,似乎在Azure中推出可用區的概念可以最大限度地減少中斷的影響。假設雷擊僅影響一個數據中心,則另一個可用區中的另一個數據中心應保持運行。但是,Azure Active Directory(AAD)等其他非區域性服務的中斷似乎影響了多個區域。我不認為可用區會完全孤立你。

全局負載均衡器,跨區域故障轉移群集等

無論您是構建跨區域的SANLess集群,還是使用全局負載均衡器將負載分散到多個區域,您都可以最大限度地減少美國中南部停電的影響。但是你可能仍然容易受到AAD中斷的影響。

混合雲,跨雲

雲端故障情況下的保證彈性是製定DR計劃,其中包括將數據實時復製到主雲提供商以外的目標,以及製定應用程序以在其他位置快速聯機應用程序的計劃。這兩個地點應該完全獨立。它不應該依賴主要位置的服務,例如AAD。DR位置可以是另一個雲提供商。在這種情況下,AWS或Google Cloud Platform似乎是合乎邏輯的替代方案,或者它可能是您自己的數據中心。但這種方式首先打敗了在雲中運行的目的。

軟件作為服務

雖然Azure作為服務(如Azure Active Directory(ADD),Azure SQL數據庫(Database-as-Service)或任何云提供商提供的眾多SaaS產品之一)看起來很誘人,但您確實需要針對最糟糕的情況進行規劃。您可能幾乎無法控制,因為您信任單個供應商的業務關鍵型應用程序。請記住,它包括DR選項,包括當前云服務提供商之外的恢復。除了在實施任何SaaS服務之前調查您的DR選項之外,我在這裡沒有任何智慧的話。如果無法在雲之外進行恢復,那麼在註冊該服務之前,請仔細考慮。告知業務所有者,如果雲服務處於脫機狀態,除了電話和投訴之外,您可能無法做任何事情。

未來的趨勢

我想在不久的將來,您將開始越來越多地了解跨雲可用性。 此外,還有人們如何利用SIOS DataKeeper等解決方案構建跨雲提供商的強大HA和DR策略。真正跨雲或混合雲模型是真正將自己與最可能的雲中斷隔離開來的唯一方法。如果您受到這次最新停電的影響,我很樂意聽取您的意見。告訴我發生了什麼事,你垮了多久,以及你做了什麼來恢復。您打算如何做,以便將來您的體驗更好?閱讀更多文章,例如如何生存Azure雲中斷?經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化 Tagged With: SIOS, 蔚藍雲停運

  • « Previous Page
  • 1
  • …
  • 71
  • 72
  • 73
  • 74
  • 75
  • …
  • 98
  • Next Page »

最近的帖子

  • 在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項
  • 我的伺服器是一次性的嗎?高可用性軟體如何適應雲端最佳實踐
  • 災難頻傳世界的資料復原策略
  • DataKeeper 與棒球:災難復原的策略性舉措
  • SQL Server 停機風險預算

最熱門的帖子

加入我們的郵件列表

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