SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

在Azure中配置SQL Server故障轉移群集實例的指南

by Leave a Comment

循序漸進：如何在Azure中配置SQL Server 2008 R2故障轉移群集實例

如果您需要指南在Azure中配置SQL Server故障轉移群集實例，您可能仍在使用SQL Server 2008/2008 R2。並且，如果將SQL Server 2008/2008 R2移動到Azure，則希望利用Microsoft提供的擴展安全更新。我之前在這篇博文中寫過關於這個主題的文章。您可能想知道如何在遷移到Azure後確保SQL Server故障轉移群集實例保持高可用性。今天，大多數人將業務關鍵型SQL Server 2008/2008 R2配置為其數據中心中的群集實例（SQL Server FCI）。在查看Azure時，您可能已經意識到由於缺少共享存儲，您似乎無法將SQL Server FCI引入Azure雲。然而，由於SIOS DataKeeper，情況並非如此。 SIOS DataKeeper使您能夠在Azure，AWS，Google Cloud或其他任何無法使用共享存儲的位置或您希望配置共享存儲無意義的多站點群集的位置構建SQL Server故障轉移群集實例。自1999年以來，DataKeeper一直在為Windows和Linux啟用SANless集群。Microsoft在其文檔中記錄了SIOS DataKeeper在SQL Server故障轉移群集實例中的使用：Azure虛擬機中SQL Server的高可用性和災難恢復。 我之前寫過有關SQL Server FCI在Azure中運行的文章，但我從未發布過特定於SQL Server 2008/2008 R2的循序漸進指南。好消息是它在SQL 2008/2008 R2和SQL 2012/2014/2016/2017以及即將發布的2019年一樣好用。此外，無論Windows Server（2008/2012/2016/2019）或SQL Server（2008/2012/2014/2016/2017）的版本如何，配置過程都足夠相似，本指南應足以讓您完成任何操作配置。如果我的任何指南都沒有涵蓋您的SQL或Windows風格，請不要害怕跳進並構建SQL Server FCI並參考本指南，我想您會發現任何差異，如果您遇到困難在Twitter @daveberm上與我聯繫，我很樂意幫助你。本指南使用SQL Server 2008 R2和Windows Server 2012 R2。截至撰寫本文時，我沒有在Windows Server 2012 R2上看到SQL 2008 R2的Azure Marketplace映像，因此我不得不手動下載並安裝SQL 2008 R2。我個人更喜歡這種組合，但如果您需要使用Windows Server 2008 R2或Windows 212，那就沒問題了。如果您使用Windows Server 2008 R2，請不要忘記安裝適用於Windows Server 2008 R2 SP1的kb3125574Convenience匯總更新。或者，如果您遇到Server 2012（而不是R2），則需要kb2854082中的修補程序。 不要被這篇文章所愚弄，該文章說你必須在SQL Server 2008 R2實例上安裝kb2854082。如果您開始搜索Windows Server 2008 R2的更新，您會發現只有Server 2012的版本可用。Server 2008 R2的特定修補程序包含在Windows Server 2008 R2 SP1的匯總便捷匯總更新中。

提供無效的實例

我不會在這裡詳細介紹一些屏幕截圖，特別是因為Azure門戶UI經常會經常更改，所以我拍攝的任何屏幕截圖都會很快變得陳舊。相反，我將只介紹您應該了解的重要主題。

故障域或可用區域？

為了確保您的SQL Server實例具有高可用性，您必須確保您的群集節點位於不同的故障域（FD）或不同的可用區（AZ）中。您的實例不僅需要駐留在不同的FD或AZ中，而且您的文件共享見證（見下文）也需要駐留在與您的群集節點所在的FD或AZ不同的FD或AZ中。這是我的看法。AZ是最新的Azure功能，但到目前為止它們僅在少數幾個地區得到支持。AZ給你一個更高的SLA（99.99％）然後FD（99.95％），並保護你免受我在我的Azure Outage Post-Mortem後期描述的那種雲中斷。 如果您可以在支持AZ的區域中部署，那麼我建議您使用AZ。在本指南中，我使用了AZ，當您進入有關配置負載均衡器的部分時，您會看到這些AZ。但是，如果使用FD，則所有內容都將完全相同，但負載均衡器配置將引用可用性集而不是可用區。

什麼是文件分享證明你問的？

Windows Server故障轉移群集（WSFC）要求您配置“見證”以確保故障轉移正常運行，而無需詳細說明。Windows Server Failover Clustering支持三種見證：磁盤，文件共享，雲。由於我們在Azure中，因此無法使用磁盤見證。Cloud Witness僅適用於Windows Server 2016及更高版本，因此我們可以使用文件共享見證。如果您想了解有關群集仲裁的更多信息，請查看Microsoft Press博客上的帖子，來自MVP：了解Windows Server 2012 R2中的Windows Server故障轉移群集仲裁

添加存儲到您的SQL Server實例

在配置SQL Server實例時，您需要為每個實例添加其他磁盤。最低限度，您需要一個磁盤用於SQL數據和日誌文件，一個磁盤用於Tempdb。在雲中運行時，是否應該為日誌和數據文件設置單獨的磁盤有些爭議。在後端，存儲全部來自同一個地方，您的實例大小限制了您的總IOPS。在我看來，分離日誌和數據文件確實沒有任何價值，因為您無法確保它們在兩個物理磁盤集上運行。我會留給你決定，但我把日誌和數據全部放在同一卷上。通常，SQL Server 2008 R2 FCI會要求您將tempdb放在群集磁盤上。但是，SIOS DataKeeper有一個非常好的功能，稱為DataKeeper非鏡像卷資源。本指南不包括將tempdb移動到此非鏡像卷資源，但為了獲得最佳性能，您應該執行此操作。真的沒有理由複制tempdb，因為它無論如何都是在故障轉移時重新創建的。就存儲而言，您可以使用任何存儲類型，但必要時盡可能使用託管磁盤。確保群集中的每個節點都具有相同的存儲配置。啟動實例後，您需要附加這些磁盤並將它們格式化為NTFS。確保每個實例使用相同的驅動器號。

聯網

這不是一個硬性要求，但如果可能的話，使用支持加速網絡的實例大小。此外，請確保在Azure門戶中編輯網絡接口，以便您的實例使用靜態IP地址。要使群集正常工作，您需要確保更新DNS服務器的設置，使其指向Windows AD / DNS服務器而不僅僅是某個公共DNS服務器。

安全

默認情況下，同一虛擬網絡中的節點之間的通信是敞開的，但如果您已鎖定Azure安全組，則需要知道必須在群集節點之間打開哪些端口並調整安全組。根據我的經驗，在Azure中構建群集時遇到的幾乎所有問題都是由阻塞的端口引起的。DataKeeper有一些端口需要在群集實例之間打開。這些端口如下：UDP：137,138 TCP：139,445,9999，以及10000到10025範圍內的端口故障轉移群集有自己的一組端口要求，我甚至不會嘗試在此處進行記錄。這篇文章似乎涵蓋了這一點。 http://dsfnet.blogspot.com/2013/04/windows-server-clustering-sql-server.html此外，稍後描述的Load Balancer將使用必須允許每個節點上的入站流量的探測端口。本指南中常用和描述的端口是59999。最後，如果您希望您的客戶端能夠訪問您的SQL Server實例，您需要確保您的SQL Server端口是打開的，默認情況下是1433。請記住，Windows防火牆或Azure安全組可以阻止這些端口，因此請務必檢查這兩個端口以確保它們可訪問。

加入域名

SQL Server 2008 R2 FCI的要求是實例必須駐留在同一Windows Server域中。因此，如果您還沒有這樣做，請確保已將實例加入Windows域

本地服務帳戶

安裝DataKeeper時，它會要求您提供服務帳戶。您必須創建域用戶帳戶，然後將該用戶帳戶添加到每個節點上的本地管理員組。在DataKeeper安裝期間詢問時，請將該帳戶指定為DataKeeper服務帳戶。注意 – 不要安裝DataKeeper！

域名全球安全組織

安裝SQL 2008 R2時，系統會要求您指定兩個全局域安全組。您可能希望展望SQL安裝說明並立即創建這些組。此外，創建域用戶帳戶並將它們放在每個安全帳戶中。您將指定此帳戶作為SQL Server群集安裝的一部分。

其他預先要求

您必須在兩個群集實例的每個實例上啟用故障轉移群集和.Net 3.5。啟用故障轉移群集時，還要確保啟用可選的“故障轉移群集自動化服務器”。 這是Windows Server 2012 R2中的SQL Server 2008 R2群集所必需的。

創建集群和DATAKEEPER卷資源

我們現在準備開始構建集群。第一步是創建基本群集。由於Azure處理DHCP的方式，我們必須使用Powershell創建集群，而不是集群UI。我們使用Powershell，因為它允許我們在創建過程中指定靜態IP地址。如果我們使用UI，則會看到VM使用DHCP並且它將自動分配重複的IP地址。因此，為了避免這種情況，讓我們使用Powershell，如下所示。

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

群集創建後，運行Test-Cluster。這在SQL Server安裝之前是必需的。

測試群集

您將收到有關存儲和網絡的警告。值得慶幸的是，您可以忽略Azure中SANless群集中的預期。但是，請在繼續之前解決任何其他警告或錯誤。創建群集後，您需要添加文件共享見證。在我們指定為文件共享見證的第三台服務器上，創建一個文件共享，並為我們剛剛創建的集群計算機對象提供讀/寫權限。在這種情況下，$ Cluster1將是在共享和NTFS安全級別都需要讀/寫權限的計算機對象的名稱。創建共享後，您可以使用配置群集仲裁嚮導（如下所示）配置文件共享見證。

安裝DATAKEEPER

在安裝DataKeeper之前等待創建基本集群非常重要，因為DataKeeper安裝會在故障轉移群集中註冊DataKeeper Volume Resource類型。如果你已經跳過槍並安裝了DataKeeper就可以了。只需再次運行安裝程序並選擇“修復安裝”。下面的屏幕截圖將引導您完成基本安裝。首先運行DataKeeper安裝程序。

您在下面指定的帳戶必須是域帳戶。它必須是每個群集節點上的Local Administrators組的一部分。

當提供SIOS許可證密鑰管理器時，您可以瀏覽到臨時密鑰。或者，如果您有永久密鑰，則可以復制系統主機ID並使用它來申請永久許可證。如果您需要刷新密鑰，SIOS許可證密鑰管理器是一個將安裝的程序，您可以單獨運行以添加新密鑰。

創建DATAKEEPER VOLUME RESOURCE

在每個節點上安裝DataKeeper後，您就可以創建第一個DataKeeper卷資源了。第一步是打開DataKeeper UI並連接到每個群集節點。

如果一切都正確完成，服務器概述報告應該如下所示。

您現在可以創建第一個Job，如下所示。

選擇源和目標後，您將看到以下選項。對於同一區域中的本地目標，您唯一需要選擇的是同步。

選擇“是”並將此卷自動註冊為群集資源。

完成此過程後，打開故障轉移群集管理器並查看磁盤。您應該在Available Storage中看到DataKeeper Volume資源。此時，WSFC將其視為普通的群集磁盤資源。

SLIPSTREAM SP3 ONTO SQL 2008 R2安裝媒體

SQL Server 2008 R2僅在帶有SQL Server SP2或更高版本的Windows Server 2012 R2上受支持。不幸的是，Microsoft從未發布過包含SP2或SP3的SQL Server 2008 R2安裝介質。相反，您必須在安裝之前將Service Pack整合到安裝介質上。如果您嘗試使用標準SQL Server 2008 R2媒體進行安裝，則會遇到各種問題。我不記得你會看到的確切錯誤。但我記得他們並沒有真正指出確切的問題。 你會浪費很多時間來弄清楚出了什麼問題。截至本文撰寫之日，Microsoft在Azure Marketplace中沒有帶有SQL Server 2008 R2產品的Windows Server 2012 R2。如果要在Azure中的Windows Server 2012 R2上運行SQL 2008 R2，請帶上自己的SQL許可證。如果他們稍後添加該圖像，或者您選擇在Windows Server 2008 R2映像上使用SQL 2008 R2，則必須先卸載現有的SQL Server獨立實例，然後再繼續。我按照本文選項1中的指導將SP3整合到我的SQL 2008 R2安裝介質上。您當然必須調整一些內容，因為本文引用的是SP2而不是SP3。確保在我們將用於群集的兩個節點的安裝介質上整合SP3。完成後，繼續下一步。

在第一個節點上安裝SQL SERVER

使用帶有SP3的SQL Server 2008 R2媒體進行整理，運行安裝程序並安裝群集的第一個節點，如下所示。

如果您使用除SQL Server的默認實例以外的任何其他內容，則本指南中將介紹一些其他步驟。最大的區別是您必須鎖定SQL Server使用的端口，因為默認情況下SQL Server的命名實例不使用1433。一旦鎖定端口，每當我們引用本指南中的端口1433時，您還需要指定該端口而不是1433，包括防火牆設置和Load Balancer設置。

這裡確保指定一個未使用的新IP地址。這是我們稍後在配置內部負載均衡器時將使用的相同IP地址。

正如我之前提到的，SQL Server 2008 R2使用AD安全組。如果您還沒有創建它們，請繼續創建它們，如下圖所示，然後再繼續執行SQL安裝中的下一步

指定先前創建的安全組。

確保您指定的服務帳戶是關聯的安全組的成員。

在此處指定SQL Server管理員。

如果一切順利，您現在可以在群集的第二個節點上安裝SQL Server。

在第二個節點上安裝SQL SERVER

在第二個節點中，運行帶有SP3安裝的SQL Server 2008 R2，然後選擇“將節點添加到SQL Server故障轉移群集實例”。

繼續安裝，如以下屏幕截圖所示。

假設一切順利，您現在應該配置一個雙節點SQL Server 2008 R2群集，其外觀如下所示。

但是，您可能會注意到只能從活動群集節點連接到SQL Server實例。問題是Azure不支持免費ARP。您的客戶端可能無法直接連接到群集IP地址。相反，客戶端必須連接到Azure負載均衡器，該負載均衡器將連接重定向到活動節點。要使此工作有兩個步驟：創建負載均衡器並修復SQL Server群集IP以響應負載均衡器探測並使用255.255.255.255子網掩碼。這些步驟如下所述。

創建AZURE負載平衡器

我將假設您的客戶端可以直接與SQL群集的內部IP地址通信。讓我們繼續在本指南中創建一個內部負載均衡器（ILB）。如果需要在公共Internet上公開SQL實例，請改用Public Load Balancer。在Azure門戶中，按照屏幕截圖創建一個新的Load Balancer，如下所示。Azure門戶UI快速變化。但是這些屏幕截圖應該為您提供足夠的信息來完成您需要做的事情。隨著我們的進展，我會召集重要的設置。在這裡，我們創建了ILB。在此屏幕上需要注意的重要事項是您必須選擇“靜態IP地址分配”。指定我們在SQL群集安裝期間使用的相同IP地址。由於我使用了可用區，我將Zone Redundant視為一種選擇。如果您使用可用性集，您的體驗將略有不同。

在後端池中，請確保選擇兩個SQL Server實例。您不希望在池中添加文件共享見證。

在這裡，我們配置健康探測器。大多數Azure文檔使用端口59999，因此我們將堅持使用該端口進行配置。

然後我們將添加一個負載平衡規則。在我們的示例中，我們希望將所有SQL Server流量重定向到活動節點的TCP端口1433。選擇浮動IP（直接服務器返回）為已啟用也很重要。

運行POWERSHELL腳本以更新SQL客戶端訪問點

現在，我們必須在其中一個群集節點上運行Powershell腳本，以允許Load Balancer Probe檢測哪個節點處於活動狀態。該腳本還將SQL群集IP地址的子網掩碼設置為255.255.255.255.255，以避免與我們剛剛創建的Load Balancer發生IP地址衝突。

＃定義變量
$ ClusterNetworkName =“” 
＃群集網絡名稱（在Windows Server 2012上使用Get-ClusterNetwork） 
更高的找到名字）
$ IPResourceName =“” 
#IP地址資源名稱 
$ ILBIP =“” 
＃內部負載均衡器（ILB）和SQL群集的IP地址
導入模塊FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | SET-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; 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

如果正確運行，這就是輸出的樣子。

Windows服務器故障轉移群集

您可能會注意到，如果您在Windows Server 2008 R2上運行，該腳本的末尾會有一行註釋代碼。運行Windows Server 2008 R2？確保在命令提示符下運行特定於Windows Server 2008 R2的代碼，它不是Powershell。

下一步

如果你達到這一點，你不是第一個，你仍然無法遠程連接到群集。在安全性，負載均衡器，SQL端口等方面存在許多可能出錯的問題。我編寫本指南以幫助解決連接問題。事實上，我在SQL Server配置管理器中的SQL Server TCP / IP屬性方面遇到了一些奇怪的問題。當我查看屬性時，我沒有看到SQL Server群集IP地址作為其正在偵聽的地址之一。因此我必須手動添加它。我不確定這是不是異常。雖然在我從遠程客戶端連接到群集之前，我必須先解決這個問題。正如我之前提到的，您可以對此安裝進行的另一項改進是為TempDB使用DataKeeper非鏡像卷資源。       

 
 

可用性方程 – 高可用性解決方案

by Leave a Comment

可用性公式 - 高可用性解決方案.jpg

可用性方程

您熟悉可用性方程嗎？簡而言之，此等式顯示了將應用程序恢復到可用性所需的總時間如何等於檢測應用程序遇到問題所需的時間加上執行恢復操作所需的時間：

TRESTORE = TDETECT + TRECOVER

高可用性解決方案的關鍵概念

該等式引入了高可用性（HA）的關鍵概念：聚類，問題檢測和後續恢復。HA解決方案監控業務應用程序組件的運行狀況當檢測到問題時，這些解決方案可以恢復它們的服務。部署高可用性解決方案的目標是最大限度地減少停機時間。減少檢測和恢復時間是您選擇部署的任何HA解決方案的兩個重要任務。今天的應用程序是技術組合：服務器，存儲，網絡基礎設施等。在查看HA選項時，請確保您了解每個解決方案用於檢測所有中斷類型並從中恢復的技術。每項技術都會對服務恢復時間產生直接影響。

本地檢測和恢復

高可用性解決方案非常簡單。一種對提供最快恢復時間至關重要的技術稱為本地檢測和恢復（也稱為服務級別問題檢測和恢復）。在基本群集解決方案中，服務器已連接。它們被配置為一個或多個服務器可以在服務器發生故障時接管另一個服務器的操作。群集中的服務器節點不斷地向對方發送小數據包（通常稱為心跳信號）以指示它們“活著”。在簡單群集環境中，當一台服務器停止生成心跳時，其他群集成員會認為此服務器已關閉。然後，它將開始接管該服務器的操作域的責任。這種方法足以檢測服務器級別的故障。但除非問題導致心跳信號中斷或停止，否則服務器級檢測不充分。更重要的是，它實際上可以放大停電的程度和影響。例如，如果Apache進程掛起，服務器仍可能發送心跳。即使Web服務器子系統已停止執行其主要功能。基本服務器級群集解決方案不是在相同或不同的服務器上重新啟動Apache子系統，而是在備份服務器上重新啟動故障服務器的整個軟件堆棧，從而導致用戶中斷並延長恢復時間。

這個怎麼運作

使用本地檢測和恢復，高級群集解決方案在各個群集服務器中部署運行狀況監視代理，以監視各個系統組件，如文件系統，數據庫，用戶級應用程序，IP地址等。這些代理使用特定於受監視組件的啟發式方法。因此，代理可以預測和檢測操作問題，然後採取最合適的恢復操作。通常，最有效的恢復方法是在同一服務器上停止並重新啟動問題子系統。通過在同一物理服務器中啟用恢復，可以大大減少將應用程序還原到用戶可用性的時間。此外，通過更簡單地檢測故障，而不僅僅是通過觀察服務器級心跳。諸如SIOS的SteelEye Protection Suite for Linux等解決方案可為您的環境提供此級別的檢測和恢復。  確保您部署的HA解決方案也支持本地檢測和恢復。您想為您的項目享受高可用性解決方案嗎？請與我們聯繫。需要更多參考，以下是我們的成功案例。經Linuxclustering許可轉載

使用Fusion-io最大化Linux群集的複制性能

by Leave a Comment

使用Fusion-io最大化Linux群集的複制性能

使用Fusion-io最大化Linux群集的複制性能的技巧

當大多數人考慮設置群集時，它通常涉及兩個或更多服務器，以及SAN或其他類型的共享存儲。SAN的設置和維護通常非常昂貴且複雜。此外，它們在技術上代表了集群架構中潛在的單點故障（SPOF）。如今，越來越多的人開始使用Fusion-io這樣的公司，以及他們閃電般快速的ioDrives，來加速關鍵應用。  這些存儲設備位於服務器內（即不是“共享磁盤”）。 因此，它不能用作具有許多傳統群集解決方案的群集磁盤。幸運的是，有一些方法可以最大化使用Fusion-io進行Linux群集的複制性能。 允許您在不涉及共享存儲時形成故障轉移群集的解決方案 – 即“無共享”群集。

傳統集群 使用Fusion-io - 傳統集群最大化Linux集群的複制性能  “無共享”集群使用Fusion-io - 無共享群集最大化Linux群集的複制性能

在將數據複製作為群集配置的一部分時，充足的帶寬至關重要，這樣才能在網絡上複製數據，就像寫入磁盤一樣快。  以下是調優技巧，可讓您在涉及高速存儲時充分利用“無共享”群集配置：

網絡

  • 使用10Gbps網卡：Fusion-io（或OCZ，LSI等其他類似產品）的基於閃存的存儲設備能夠以MB /秒或更高的百萬分之一（750）的速度寫入數據。  1Gbps網卡只能推動理論最大值~125 MB /秒，因此任何利用ioDrive潛力的人都可以比通過1 Gbps網絡連接推送更快地寫入數據。  為確保服務器之間有足夠的帶寬以促進實時數據複製，應始終使用10 Gbps NIC來承載複製流量
  • 啟用巨型幀：假設您的網卡和交換機支持它，啟用巨型幀可以大大提高網絡吞吐量，同時減少CPU週期。  要啟用巨型幀，請執行以下配置（例如來自RedHat / CentOS / OEL linux服務器）
    • ifconfig <interface_name> mtu 9000
    • 編輯/ etc / sysconfig / network-scripts / ifcfg- <interface_name>文件並添加“MTU = 9000”，以便在重新啟動後更改仍然存在
    • 要驗證端到端巨型幀操作，請運行以下命令：ping -s 8900 -M do <IP-of-other-server>
  • 更改NIC的傳輸隊列長度：
    • / sbin / ifconfig <interface_name> txqueuelen 10000
    • 將其添加到/etc/rc.local以保留重新啟動後的設置

TCP / IP調整

  • 更改NIC的netdev_max_backlog：
    • 在/etc/sysctl.conf中設置“net.core.netdev_max_backlog = 100000”
  • 已顯示可提高複制性能的其他TCP / IP調整：
    • 注意：這些是示例值，有些可能需要根據您的硬件配置進行調整
    • 編輯/etc/sysctl.conf並添加以下參數：
      • net.core.rmem_default = 16777216
      • net.core.wmem_default = 16777216
      • net.core.rmem_max = 16777216
      • net.core.wmem_max = 16777216
      • net.ipv4.tcp_rmem = 4096 87380 16777216
      • net.ipv4.tcp_wmem = 4096 65536 16777216
      • net.ipv4.tcp_timestamps = 0
      • net.ipv4.tcp_sack = 0
      • net.core.optmem_max = 16777216
      • net.ipv4.tcp_congestion_control = HTCP

調整

通常，您還需要對群集配置進行調整，這將根據您決定實施的群集和復制技術而有所不同。  在這個例子中，我使用的是SIOS Technologies的SteelEye Protection Suite for Linux（又名SPS，又名LifeKeeper）。 它允許用戶利用幾乎任何後端存儲類型形成故障轉移群集：光纖通道SAN，iSCSI，NAS，或者與本文最相關的本地磁盤，需要在群集節點之間實時同步/複製。  SPS for Linux包括集成的塊級數據複製功能，這使得在沒有共享存儲時很容易設置集群。

建議

為了最大化使用Fusion-io的Linux群集的複制性能，讓我們試試這個。SteelEye Protection Suite（SPS）for Linux配置建議：

  • 分配位於Fusion-io驅動器上的小（~100 MB）磁盤分區以放置位圖文件。  在此分區上創建一個文件系統並將其掛載，例如，在/ bitmap：
    • #mount | grep /位圖
    • / dev / fioa1 on / bitmap type ext3（rw）
  • 在創建鏡像之前，請在/ etc / default / LifeKeeper中調整以下參數
    • 插入：LKDR_CHUNK_SIZE = 4096
      • 默認值為64
    • 編輯：LKDR_SPEED_LIMIT = 1500000
      • （默認值為50000）
      • LKDR_SPEED_LIMIT指定重新同步將採用的最大帶寬 – 應設置為足夠高以允許重新同步以盡可能最大的速度運行
    • 編輯：LKDR_SPEED_LIMIT_MIN = 200000
      • （默認值為20000）
      • LKDR_SPEED_LIMIT_MIN指定當同時進行其他I / O時允許重新同步的速度 – 根據經驗，這應該設置為驅動器的最大寫入吞吐量的一半或更少，以避免挨餓重新同步發生時，正常的I / O活動

從這裡開始，像往常一樣創建鏡像並配置群集。有興趣通過Fusion-io最大化Linux群集的複制性能，請參閱SIOS可以提供的其他內容。經LinuxClustering許可轉載

我可以將我的文件共享證人放在DFS共享上嗎？

by Leave a Comment

我可以將我的文件共享證人放在DFS共享上嗎？

我可以將我的文件共享證人放在DFS共享上嗎？

我一直被問到這個問題 – 哪裡可以將我的文件共享見證放在DFS共享上。人們擔心失去他們的文件共享證人。因此，與其他許多股票一樣，他們希望利用DFS獲得一些額外的可用性。這是一個非常糟糕的主意，不受支持。微軟最近發布了一篇很棒的博客文章，該文章描述了為什麼不支持DFS共享上的文件共享見證的原因。https://blogs.msdn.microsoft.com/clustering/2018/04/13/failover-cluster-file-share-witness-and-dfs/本文的大部分內容也適用於那些詢問是否可以使用DataKeeper將捲資源複製為磁盤共享。這說得通。對於任何其他工作負載，您可以使用DataKeeper卷資源代替物理磁盤資源，那麼為什麼不使用Disk Witness？此問題與DFS問題相同。如果兩台服務器之間的通信中斷，則無法保證兩台服務器上的捲都不會聯機。這將導致潛在的裂腦情況。物理磁盤資源通過使用SCSI保留克服了此問題。這將確保磁盤一次只能由一個群集節點訪問。好消息是，微軟已經阻止您嘗試使用複制的DataKeeper Volume資源。在Windows Server 2019中，看起來它們也會阻止您將DFS共享用作文件共享見證。

來自故障轉移群集和網絡負載平衡團隊博客文章“故障轉移群集文件共享見證和DFS [/ caption]

有關於將文件共享見證放在DFS共享上的問題嗎？閱讀我們的博客或聯繫我們！經ClusteringForMereMortals.com許可轉載

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

by Leave a Comment

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

存儲空間直接用於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支持的兩種解決方案。S2D用於SQL Server故障轉移群集實例  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許可轉載