檔案

如何將現有的 SQL Server 故障轉移群集實例擴展到雲以進行災難恢復

17 6 月, 2021 by Jason Aw Leave a Comment

如何將現有的 SQL Server 故障轉移群集實例擴展到雲以進行災難恢復

通常我會指出他們這一點DataKeeper 文檔當有人問我如何將現有的 SQL Server 故障轉移群集實例擴展到雲以進行災難恢復時。

第一個文檔討論了擴展集群並向現有集群添加第三個節點。如果您的集群支持三個節點，那很好。但是，如果您使用的是 SQL Server 標準版，Microsoft 會將您限制為 2 節點群集。在 2 節點集群的情況下。您仍然可以復製到第三個節點。請記住，恢復將更多地是手動過程。描述了這個過程這裡.

人們通常會閱讀這些說明並有點擔心。他們覺得他們會在他們的集群上進行心臟直視手術。這真的更像是換襯衫！您只需將集群磁盤資源替換為 DataKeeper Volume 資源。正如您將在下面的視頻中看到的，該過程只需幾秒鐘。

視頻中演示的代碼如下所示。

Stop-ClusterGroup SQLServerGroup Remove-ClusterResource -Name "Cluster Disk 1" Set-Disk -Number 4 -IsOffline $False Set-Disk -Number 4 -IsReadOnly $False Import-Module -Name Storage Set-Partition -DiskNumber 4 -PartitionNumber 1 - NewDriveLetter X New-DataKeeperMirror -SourceIP 10.0.2.100 -SourceVolume X -TargetIP 10.0.1.10 -TargetVolume X -SyncType Sync New-DataKeeperJob -JobName "x drive" -JobDescription "sql data" -Node1Name primary.datakeeper.local -Node1IP 10.0.0. 2.100 -Node1Volume x -Node2Name dr.datakeeper.local -Node2IP 10.0.1.10 -Node2Volume X -SyncType Sync Add-ClusterResource -Name "DataKeeper Volume X" -ResourceType "DataKeeper Volume" -Group "SQLServerGroup" Get-ClusterResource "DataKeeper Volume X " | Set-ClusterParameter VolumeLetter X Get-ClusterResource -Name 'SQLServer' | Add-ClusterResourceDependency -Provider 'DataKeeper Volume X' Start-ClusterGroup SQLServerGroup

運行該代碼後，不要忘記您還需要單擊管理共享卷以將備份節點添加到 DataKeeper 作業，如視頻所示。

如果您有 SQL Server 企業版，那麼最後一步是在 DR 節點中安裝 SQL Server 並選擇將節點添加到現有集群。

如果您使用的是 SQL Server 標準版，那麼您的工作就完成了。你會簡單地遵循這些說明訪問您在第三個節點上的數據，然後安裝複製的數據庫。

無論您的 DR 節點是在雲端還是您自己的 DR 站點，這些說明都適用。

關於將Amazon FSX用於SQL Server故障轉移群集實例

14 2 月, 2021 by Jason Aw Leave a Comment

使用Amazon FSX進行SQL Server故障轉移群集實例-您需要了解的知識！

如果您正在考慮在AWS EC2中部署自己的Microsoft SQL Server實例，則需要就解決方案的彈性做出一些決策。當然，如果您在不同的可用區域中部署兩個或更多實例，AWS將為您的Compute資源提供99.99％的SLA。但不要上當，在計算真正的應用程序可用性時，還需要考慮許多其他因素。我最近在博客上發表了有關如何在雲中計算應用程序可用性的博客。在繼續之前，您可能應該快速閱讀該文章。

在確保Microsoft SQL Server實例高度可用時，它實際上可以歸結為兩個基本選擇：始終可用性組（AG）或SQL Server故障轉移群集實例（FCI）。如果您正在閱讀本文，則假定您對這兩個選項都非常了解，並正在認真考慮使用SQL Server故障轉移群集實例而不是SQL Server Always On AG。

Microsoft SQL Server故障轉移群集實例的好處

以下列表總結了AWS所說的是SQL Server FCI的優點：

當以下是您使用案例的優先考慮因素時，對於SQL Server高可用性部署，FCI通常比AG更可取：

許可證成本效率：運行AG所需的是SQL Server的企業版許可證，而運行FCI的僅需Standard Edition許可證。它通常比企業版便宜50–60％。儘管您可以從SQL Server 2016開始在Standard Edition上運行AG的基本版本，但它的局限性在於每個AG僅支持一個數據庫。在處理需要多個數據庫（例如SharePoint）的應用程序時，這可能成為一個挑戰。

實例級保護與數據庫級保護：使用FCI，可以保護整個實例-如果主節點不可用，則將整個實例移到備用節點。這將照顧存儲在系統數據庫中的SQL Server登錄名，SQL Server代理作業，證書等，這些數據庫實際上存儲在共享存儲中。另一方面，使用AG，只能保護組中的數據庫，並且不能將系統數據庫添加到AG中-僅允許用戶數據庫。數據庫管理員負責將更改複製到所有AG副本上的系統對象。這留下了人為錯誤的可能性，導致數據庫無法被應用程序訪問。

DTC功能支持：如果您使用的是SQL Server 2012或2014，並且您的應用程序使用分佈式事務處理協調器（DTC），則您將無法使用AG，因為它不受支持。在這種情況下，請使用FCI。

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

雲中FCI面臨的挑戰

當然。建立跨越可用性區域的FCI的挑戰是缺少通常需要的共享存儲設備。因為群集的節點分佈在多個數據中心，所以傳統的SAN對於共享存儲來說不是可行的選擇。這為集群存儲留出了兩個選擇：第三方存儲類資源，例如SIOS DataKeeper或新的Amazon FSx。

讓我們來看看您做出選擇之前需要了解的內容。

服務水平協議

正如我在如何計算應用程序可用性中所寫的那樣，您的整體應用程序SLA僅與最弱的鏈接一樣好。在這種情況下，FSx SLA為99.9％。

通常99.99％的可用性代表著“高可用性”的起點。這是當兩個或多個部署在不同的可用區域中時，AWS向您承諾的計算資源。

萬一您不知道三個九與四個九之間的區別…

99.9％的可用性每月允許停機43.83分鐘
99.99％的可用性每月僅允許停機4.38分鐘

儘管您具有99.99％的計算可用性，但是通過將群集存儲託管在FSx上，您的整體應用程序可用性將達到99.9％。相比之下，跨越可用性區域的EBS卷（例如在DataKeeper部署中）在存儲和計算層均符合99.99％的SLA。這意味著您的整體應用程序可用性為99.99％。

存儲位置

為高可用性配置FSx時，您將需要啟用多可用區支持。通過啟用多可用區，您可以有效地擁有“首選”可用區和“備用”可用區。部署SQL Server FCI節點時，您將希望將這些節點分佈在相同的可用區中。

現在，在正常情況下，您將需要確保活動群集節點與首選FSx存儲節點位於相同的可用區中。這是為了最大程度地減少存儲距離和延遲。而且還可以最大程度地減少與跨可用區進行數據傳輸相關的成本。根據FSx價格指南中的規定，“標準數據傳輸費適用於AZ之間或區域間對文件系統的訪問。”

在不幸的情況下，如果您遇到SQL Server FCI故障，但沒有FSx故障，則沒有將存儲和計算結合在一起的機制。如果FSx進行故障轉移，它將自動故障恢復到主要可用性區域。但是，最佳實踐指示SQL FCI仍在輔助節點上運行，直到執行根本原因分析並且通常計劃在維護期間進行故障回复。這使您處於存儲位於其他可用區的情況，這將產生額外的費用。當前，跨可用區和入口的數據傳輸成本為$ 0.01 / GB。

如果不密切關注FSx和SQL Server FCI的狀態，您甚至可能都不知道它們在不同的區域中運行，直到您在月底看到數據傳輸費用為止。

相反，在使用SIOS DataKeeper的配置中，存儲故障轉移是SQL Server FCI恢復的一部分，從而確保存儲始終通過SQL Server實例進行故障轉移。這樣可以確保SQL Server始終在讀寫直接連接到活動節點的EBS卷。請記住，DataKeeper將產生與在AZ或區域之間複製的寫操作相關的數據傳輸成本。通過使用DataKeeper中可用的壓縮，可以將這種數據傳輸成本降到最低。

控制故障轉移

在FSx多子網配置中，存在首選的可用性區域和備用可用性。如果首選可用性區域中的FSx文件服務器出現故障，備用AZ中的文件服務器將恢復。 AWS報告說，使用標準共享時，此恢復時間大約需要30秒。通過使用連續可用的文件共享，Microsoft報告此故障轉移時間可以接近15秒。在此故障轉移時間內，將在讀取和寫入暫停的情況下發生電源不足，但是一旦恢復完成，該電源將繼續。

FSx多站點已啟用自動故障回复。這意味著，對於FSx的每個計劃外故障轉移，您還將具有計劃外的故障回复。相反，通常，當SQL Server FCI經歷計劃外的故障轉移時，您要么只是使其在輔助服務器上運行，要么計劃在幾個小時後或下一個維護期間進行故障回复。

FSX不支持SQL Server Analysis Services群集

如果要群集SSAS，則需要群集磁盤資源，例如SIOS DataKeeper。如何群集SQL Server Analysis Server白皮書明確指出無法使用SMB，並且必須使用帶驅動器號的群集驅動器。相反，DataKeeper卷資源將其自身顯示為群集磁盤，並且可以與SSAS一起使用。

概括

雖然FSx對於Windows用戶文件和其他非關鍵服務等典型的SMB使用肯定是有意義的，其中SLA滿足99.9％的可用性，但如果您的應用程序要求高可用性（99.99％）或還具有高可用性的HA / DR解決方案，則FSx是一個不錯的選擇區域，SIOS DataKeeper是正確的選擇。

轉載自《星際爭霸》的許可

在Azure虛擬機上配置SQL Server故障轉移群集實例

4 4 月, 2019 by Jason Aw Leave a Comment

使用Msdtc #Sql #Azure #Msdtc在Azure虛擬機上配置SQL Server故障轉移群集實例

您可能知道我們已經包含了大量有關在Azure上構建SQL Server故障轉移群集實例（FCI）的分步指南，從SQL Server 2008到最新版本。這裡有一些鏈接可以幫助您入門。但實際上，不同版本的Windows和SQL Server之間的配置差別很小。所以我認為無論你使用什麼版本，你都能弄明白。循序漸進：如何配置MICROSOFT AZURE IAAS中的SQL SERVER FAILOVER CLUSTER INSTANCE（FCI）#SQLSERVER #AZURE #SANLESS逐步：如何配置SQL SERVER 2008 R2故障群集在AZURE中的實例我擁有什麼沒有解決的是如何處理MSDTC。微軟在這篇文章中發表了這篇文章。https://blogs.msdn.microsoft.com/sql_pfe_blog/2018/07/05/configure-sql-server-failover-cluster-instance-on-azure-virtual-machines-with-msdtc但是，僅限該文章/視頻解決SQL Server 2016及更高版本的問題。好消息是，大部分指南都可以應用於SQL Server 2008/2012/2014。在我有時間做一個正確的分步指導之前，我想記下一些基本的筆記，更多的是提醒自己。但是，您可能會發現此信息在此期間也很有用。以下步驟假定您已在Azure中創建了SQL Server FCI並對DTC資源進行了群集。有關這些步驟的詳細信息，請參閱上面的指南。以下步驟實際上只是詳細說明了Azure中所需的負載均衡器配置。

為MSDTC創建負載均衡器

MSDTC資源將需要其自己的負載均衡器。我們將向負載均衡器添加一個新的前端，而不是創建新的負載均衡器，該前端應該已經為SQL Server FCI配置。當然，此前端IP地址應與與群集MSDTC資源關聯的群集IP地址匹配。對於後端池，只需重用您創建的包含SQL集群節點的現有池。您需要創建一個專用於MSDTC資源的新健康探針。您使用的端口必須與您用於SQL資源的端口不同。不要使用59999。也許使用像49999這樣的東西。最後一步是為MSDTC創建負載平衡規則。創建一個新規則並引用我們剛剛創建的MSDTC前端和現有的後端。接下來，我們需要創建一個新的負載平衡規則。MSDTC使用臨時端口，這是一個很大的端口範圍。在創建規則時，必須選擇“HA Ports”框。最後，確保啟用了直接服務器返回。

更新MSDTC群集IP資源

像SQL Server群集IP地址一樣工作。我們需要運行一個Powershell命令，該命令將使MSDTC集群IP資源響應我們剛剛創建的探測端口49999的運行狀況探測。它還將該MSDTC群集IP地址的子網掩碼設置為255.255.255.255，以避免與我們設置的共享相同地址的負載均衡器前端發生IP地址衝突。

#define variables $ ClusterNetworkName =“”  
＃群集網絡名稱（使用Get-ClusterNetwork） 
更高的Windows Server 2012查找MSDTC資源的名稱） 
$ IPResourceName =“”  
#MSDTC資源的IP地址資源名稱$ ILBIP =“”  
＃內部負載均衡器（ILB）和MSDTC資源的IP地址 
導入模塊FailoverClusters 
＃如果您使用的是Windows Server 2012或更高版本： 
Get-ClusterResource $ IPResourceName | SET-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 49999; SubnetMask =“255.255.255.255”;
網絡= $ ClusterNetworkName; EnableDHCP時= 0} 
＃如果您使用的是Windows Server 2008 R2，請使用以下命令：  
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
子網掩碼= 255.255.255.255

確認它正在工作！

您可以使用DTCPing或進入組件服務，並查看計算機>我的計算機>分佈式事務處理協調器，您應在其中看到本地DTC和群集DTC。任何分佈式事務都應出現在群集DTC中，而不是本地DTC中。查看此視頻，了解如何創建分佈式事務以進行測試的示例。

下一步

這是一個快速而骯髒的指南。對於有經驗的用戶，它應該在Azure中啟動並運行MSDTC資源。我將在不久的將來發布詳細的分步指南。在此期間，如果您遇到困難，請不要猶豫，在Twitter @daveberm上與我聯繫

使用DataKeeper實現SQL Server高可用性災難恢復

26 3 月, 2019 by Jason Aw Leave a Comment

通過混合使用永遠在線的可用性組和SANless SQL Server故障轉移群集實例實現SQL Server高可用性，災難恢復

介紹

將SQL Server故障轉移群集實例（FCI）與Always On Availability Groups（AG）混合的主題已有詳細記錄。但是，大多數可用的文檔文檔配置假定解決方案的SQL Server FCI部分使用共享存儲。如果我想使用Storage Spaces Direct（S2D）構建SANless SQL Server FCI，我還能添加一個SQL Server AG嗎？不幸的是，這個問題的答案是否定的。截至今天，不支持基於S2D的SQL Server FCI和Always On AG的組合。我之前在博客上寫過這個S2D限制。然而，好消息是你可以使用SIOS DataKeeper構建一個SANless SQL Server FCI，並且仍然可以利用Always On AG來處理可讀的輔助數據庫。在混合傳統的基於SAN的SQL Server FCI和Always On AG時，您仍然必須遵守相同的規則，但大多數情況下實現SQL Server的高可用性大致相同。DataKeeper同步複製通常用於同一數據中心或云區域中的節點之間，但您可能希望異步複製到不同區域中的其他節點以進行災難恢復。在這種情況下，如果您在意外故障後必須將DR節點聯機，則必須廢棄Always On AG配置並重新配置它們。此要求與Microsoft在此處發布的有關恢復在VM內運行的SQL Server Always On AG的異步快照的要求非常相似。

可用性組

從本質上講，就Always On可用性組嚮導而言，具有DataKeeper的SANLess SQL Server故障轉移群集實例看起來像SQL Server的單個實例。Always On AG的配置與在兩個獨立（非群集）SQL Server實例之間僅創建Always On AG的配置完全相同。真正的困惑在於，在此配置中，所有服務器都駐留在同一故障轉移群集中。但SQL Server FCI僅配置為僅在作為群集SQL Server實例安裝SQL Server的群集節點上運行。其他節點位於同一群集中。但是，SQL在這些節點上安裝為獨立SQL Server實例，而不是群集實例。這有點令人困惑。基本上正在發生的事情是Always On AG利用WSFC仲裁模型和聽眾。因此，所有AG副本都需要駐留在同一個WSFC中，即使它們通常不運行SQL Server的群集實例。如果你完全感到困惑，那麼大多數人在第一次嘗試圍繞這種混合配置時會感到困惑。這樣的配置的真正好處是，在許多情況下，SQL Server故障轉移群集實例可以比Always On AG更好，更具成本效益（在後面的*上更多）高可用性解決方案，但它缺乏提供可讀的輔助副本。添加Always On AG可讀輔助副本成為滿足此需求的可行選項。使用SIOS DataKeeper消除了對SQL Server FCI的SAN的需求，這開闢了配置SQL Server FCI的可能性，其中節點位於不同的數據中心，這也意味著支持跨Azure和ASP.NET中的可用區的SQL Server FCI。AWS。請注意，下圖僅是一種可能的配置。支持多個FCI集群節點，多個AG和多個副本。您只受限於您的SQL Server版本所施加的限制。本文似乎很好地記錄了設置步驟。當然，我將使用SIOS DataKeeper來構建FCI，而不是SQL FCI的共享存儲。

基本可用性組

從SQL Server 2016開始，縮小的“基本可用性組”在SQL Server標準版中可用，即使在SQL Server標準版中也可以進行此配置。基本AG僅限於每個可用性組的單個數據庫，單個副本（2個節點）。但是，它們不支持可讀的輔助副本，因此它們在此混合配置中的用例非常有限。

分佈式可用性組

此混合配置也支持SQL Server 2016中引入的分佈式AG。分佈式AG與常規AG非常相似，但副本不需要駐留在同一個集群中，甚至不需要駐留在同一個Windows域中。Microsoft記錄了分佈式可用性組的主要用例，如下所示：

災難恢復和更輕鬆的多站點配置
遷移到新硬件或配置，可能包括使用新硬件或更改底層操作系統
通過跨多個可用性組，在單個可用性組中將可讀副本的數量增加到八個以上

摘要

如果您喜歡SQL Server FCI的SQL Server高可用性的想法，但想要只讀輔助副本的靈活性，這種混合解決方案可能就是您正在尋找的東西。傳統的基於SAN的SQL Server FCI，甚至基於存儲空間直接（S2D）的FCI，都將您限制在單個數據中心。SIOS DataKeeper使您擺脫SAN的限制，並支持跨越可用區域或云區域的SQL Server FCI等配置。它還消除了對SAN的依賴，允許您利用本地連接的高速存儲設備，而無需放棄SQL Server故障轉移群集實例。

*如何省錢

早些時候我答應過，我會告訴你如何通過SQL Server標準版來實現這一切。如果您可以使用基於時間點的快照的可讀副本，則可以完全跳過Always On AG並僅使用SIOS DataKeeper目標端快照功能定期獲取目標服務器上卷的應用程序一致性快照，而不會影響正在進行的複制或可用性。這是如何做…

http://discover.us.sios.com/rs/siostechnology/images/10-Ways-Save-AlwaysOn-vs-Failover-Clustering.pdf

使用SQL Server Standard Edition創建一個雙節點SQL Server FCI，並在SQL許可證上節省大量資金。然而，仍然會將數據複製到群集外的第3個節點，以用於報告或DR目的。如果您拍攝第三台服務器上的捲快照，則可以直接訪問這些快照。這樣，您可以從SQL Server的獨立實例安裝這些數據庫以運行月末報告，複製到存檔，或者您甚至可能希望使用這些快照使用最新的SQL快速輕鬆地更新QA和測試/開發環境數據。我希望您找到了創建指南以實現SQL Server高可用性，災難恢復與Always On Availability Groups和SANless SQL Server故障轉移群集實例的混合使用。

S2D用於SQL Server故障轉移群集實例

8 9 月, 2018 by Jason Aw Leave a Comment

存儲空間直接用於SQL Server故障轉移群集實例

隨著Windows Server 2016 Datacenter Edition的推出，引入了一項名為Storage Spaces Direct（S2D）的新功能。在非常高的級別，S2D For SQL Server故障轉移群集實例允許您將本地連接的存儲池合併在一起，並將其作為CSV呈現給群集，以便在擴展文件服務器中使用。然後，它可以通過SMB 3訪問，並用於保存群集數據，如Hyper-V VMDK文件。這也可以以超融合（HCI）方式配置，使得應用程序和數據都可以在同一組服務器上運行。這是一個非常簡化的描述，但有關詳細信息，您需要查看此處。

圖片取自https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview目標主要用例是Hyper-V部署的超融合基礎架構。但是，還有其他用例，包括利用此SMB存儲來存儲要在SQL Server故障轉移群集實例中使用的SQL Server數據

為什麼有人想這樣做？

那麼，對於初學者，您現在可以使用SQL Server標準版構建高度可用的2節點SQL Server故障轉移群集實例（FCI），而無需共享存儲。以前，如果您想要沒有SAN的HA，您幾乎可以購買SQL Server企業版並使用Always On Availability Groups或購買SIOS DataKeeper並利用第三方解決方案，該解決方案允許您使用任何版本的Windows構建SANless群集或SQL Server。SQL Server企業版可以真正提高項目成本，特別是如果您只是為可用性組功能購買它。除了與可用性組相關的成本之外，還有許多其他技術原因可能會使您更喜歡故障轉移群集而不是AG。應用程序兼容性，實例與數據庫級別保護，大量數據庫，DTC支持，經過培訓的人員等等，只是您可能希望堅持使用故障轉移群集實例的一些技術原因。

SIOS DataKeeper解決方案VSS用於SQL Server故障轉移群集實例

Microsoft在此處的文檔中列出了SIOS DataKeeper解決方案和S2D解決方案，作為SQL Server FCI支持的兩種解決方案。 https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr比較這兩種解決方案時，你必須考慮到這一點自1999年以來，SIOS一直允許您構建SANless Clusters。但S2D for SQL Server故障轉移群集實例仍處於起步階段。話雖如此，一定會有一些區域，S2D有一些趕上來做。或者，僅僅由於技術的限制，它們將永遠不會支持的功能。

在選擇SANless群集解決方案之前

有關在選擇SANless群集解決方案之前應考慮的一些事項的概述，請查看下表。 S2D用於SQL Server故障轉移群集實例如果我們瀏覽此圖表，我們會發現SIOS DataKeeper顯然具有一些顯著優勢。例如，DataKeeper支持更廣泛的平台，一直回到Windows Server 2008 R2和SQL Server 2008 R2。S2D解決方案僅支持最新版本的Windows和SQL Server 2016/2017。S2D還需要Windows的Datacenter Edition，這會顯著增加部署成本。此外，SIOS還為Linux上的SQL Server提供了唯一的HA / DR解決方案，既可以在本地也可以在雲中運行。

分析差異

但是，除了成本和平台限制之外，我認為當我們開始考慮SANless群集的災難恢復選項時，最明顯的差距就出現了。Allan Hirt，SQL Server集群大師以及Microsoft Cloud和Datacenter Management MVP，最近發布了有關此S2D限制的文章。在他的文章Revisiting Storage Spaces Direct和SQL Server FCI中，Allan指出，由於缺乏對跨站點拉伸S2D群集的支持，或者包括基於S2D的群集作為Always On Availability Group中的支路，因此，DR的最佳選擇是S2D場景是日誌傳送！別誤會我的意思。原木運輸已經永遠存在，並且可能在我離開後很長一段時間。但是，當我們考慮我們已經習慣的所有災難恢復解決方案時，例如多站點群集，可用性組等，這是向後邁出了巨大的一步。相比之下，SIOS DataKeeper解決方案完全支持Always On Availability Groups。更好的是 – 它可以讓您跨站點擴展您的FCI，為您提供您希望在RTO / RPO方面實現的最佳HA / DR解決方案。在Azure環境中，DataKeeper還支持Azure站點恢復（ASR），為您提供更多災難恢復選項。這個圖表的其餘部分非常自我解釋。它基本上包括在部署S2D群集之前必須滿足的列表硬件，存儲和網絡要求。這裡保留了詳細的S2D要求列表。 https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-hardware-requirements

SIOS Datakeeper。有什麼好的

SIOS DataKeeper解決方案更加寬鬆。它支持任何本地連接的存儲，只要硬件通過集群驗證，它就是受支持的集群配置。塊級複製解決方案一直運行良好，因為1 Gbps被認為是快速LAN並且T1 WAN連接被認為是奢侈品。SANless群集對於雲部署尤其有用。云不為集群提供傳統的共享存儲選項。因此，對於想要隨身攜帶群集的“升級並轉移”到雲中的用戶，他們必須查看備用存儲解決方案。對於雲部署，SIOS已通過Azure，AWS和Google認證，可在相關的雲市場中使用。雖然在Azure或Google中似乎沒有阻止基於S2D的群集部署的任何內容，但Microsoft對這些平台的文檔或支持性聲明顯然不足。

做出安全的選擇

SIOS DataKeeper自1999年以來一直在這樣做。SIOS已經聽取了所有功能請求，發現了所有的錯誤，並為SANless集群提供了堅如磐石的解決方案，經過時間測試和驗證。雖然微軟S2D是一種很有前景的技術，但作為第一代產品，我會等到塵埃落定並且一些功能差距關閉之後我會考慮將它用於我的業務關鍵應用程序。

要了解有關S2D對於SQL Server故障轉移群集實例的更多信息，請在此處查找SIOS DataKeeper經Clusteringformeremortals.com許可轉載