Date: 31 3 月, 2019
標籤: SQL Server故障轉移群集
循序漸進：如何在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 Server 2008 R2上運行，該腳本的末尾會有一行註釋代碼。運行Windows Server 2008 R2？確保在命令提示符下運行特定於Windows Server 2008 R2的代碼，它不是Powershell。
下一步
如果你達到這一點，你不是第一個，你仍然無法遠程連接到群集。在安全性，負載均衡器，SQL端口等方面存在許多可能出錯的問題。我編寫本指南以幫助解決連接問題。事實上，我在SQL Server配置管理器中的SQL Server TCP / IP屬性方面遇到了一些奇怪的問題。當我查看屬性時，我沒有看到SQL Server群集IP地址作為其正在偵聽的地址之一。因此我必須手動添加它。我不確定這是不是異常。雖然在我從遠程客戶端連接到群集之前，我必須先解決這個問題。正如我之前提到的，您可以對此安裝進行的另一項改進是為TempDB使用DataKeeper非鏡像卷資源。