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 ILB功能的多實例SQL Server故障轉移群集

14 4 月, 2019 by Jason Aw Leave a Comment

新的Azure ILB功能允許您構建多實例SQL Server故障轉移群集

在今年9月的Microsoft Ignite上,微軟圍繞Azure發布了一些聲明。其中一個公告是內部負載平衡器上的多個VIP的普遍可用性。為什麼這對SQL Server DBA如此重要?好吧,到目前為止,如果要在Azure中部署高可用性SQL Server,則每個群集或單個可用性組偵聽器僅限於一個SQL Server FCI。此限制強制您為要在故障轉移群集中保護的每個SQL Server實例部署新群集。如果您希望在AlwaysOn AG配置中進行自動故障轉移和客戶端重定向,它還會強制您將所有數據庫分組到單個可用性組中。

如何擺脫這些限制?

這些新的ILB功能現已解除了這些限制。在這篇文章中,我將引導您完成在Azure中部署包含兩個SQL Server實例的SQL Server FCI的過程。在以後的文章中,我將引導您完成SQL Server AlwaysOn AG的相同過程。

讓我們從多實例SQL Server故障轉移群集開始

如我在Azure資源管理器中部署Microsoft SQL Server 2014故障轉移群集的帖子中所述,在Azure中構建基本的單實例SQL Server FCI。該帖子描述了創建多實例SQL Server故障轉移群集的過程。 使用DataKeeper創建群集中使用的複製卷資源,嘗試創建內部負載平衡器(ILB),然後修復SQL Server群集IP資源以使用ILB。如果您想跳過該過程并快速啟動配置,您可以始終使用Azure部署模板,使用SIOS DataKeeper創建雙節點SQL Server FCI假設您現在有一個基本的雙節點SQL Server FCI,添加第二個命名的步驟實例如下:

  1. 在另一個當前未使用的捲上創建另一個DataKeeper卷資源。如果沒有可用卷,則可能需要向Azure實例添加其他磁盤。作為此卷創建過程的一部分,新的DataKeeper卷資源將在群集中的可用存儲中註冊。有關詳細信息,請參閱前面引用的文章。
  2. 在第一個節點上安裝SQL Server的命名實例,指定我們剛剛創建的DataKeeper卷作為存儲位置。
  3. “添加節點”到第二個節點上的群集。
  4. 將此新命名實例的端口號鎖定到未使用的端口。在我的例子中,我使用端口1440。

將ILB調整為第二個實例

接下來,我們必須調整ILB以將流量重定向到第二個實例。以下是您需要遵循的步驟:添加前端IP地址,該地址與您用於第二個SQL Server實例的SQL群集IP地址相同,如下所示。具有新Azure ILB功能的多實例SQL Server故障轉移群集 接下來,我們將需要添加另一個探測,因為實例可以在不同的服務器上運行。如下圖所示,我添加了一個探測端口59998(而不是通常的59999)的探測器。我們需要確保新規則引用此探針。我們還需要記住該端口號,因為我們需要在此過程的最後一步更新與此實例關聯的IP地址。具有新Azure ILB功能的多實例SQL Server故障轉移群集 現在我們需要向ILB添加兩個新規則來引導目標為第二個SQL實例的流量。當然我們需要添加一個規則來重定向TCP端口1440(我用於SQL命名實例的端口),但由於我們現在使用的是命名實例,我們還需要一個端口來支持SQL Server Browser服務,UDP端口1434。在下面描述SQL Server Browser服務規則的圖片中,請注意前端IP地址引用了新的FrontendIP地址(10.0.0.201),端口和後端端口的UDP端口1434。在池中,您需要指定群集中的兩個服務器,最後確保選擇剛剛創建的新Health Probe。具有新Azure ILB功能的多實例SQL Server故障轉移群集 我們現在將添加TCP / 1440規則。如下圖所示,為端口TCP 1440添加新規則,或為SQL Server的命名實例鎖定的任何端口。同樣,請務必選擇新的FrontEnd IP地址和新的Health Probe(59998)。此外,請確保啟用了浮動IP(直接服務器返回)。具有新Azure ILB功能的多實例SQL Server故障轉移群集

最後一步

現在已配置負載均衡器,最後一步是運行PowerShell腳本以更新與此第二個SQL Server實例關聯的新群集IP地址。此PowerShell腳本只需要在其中一個群集節點上運行。

#定義變量

$ ClusterNetworkName =“”

#群集網絡名稱 
(在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名稱)

$ IPResourceName =“”

#SQL Server的第二個實例的IP地址資源名稱

$ ILBIP =“”

#第二個SQL實例的IP地址,
它應該與新的前端IP地址相同

導入模塊FailoverClusters

#如果您使用的是Windows Server 2012或更高版本:

Get-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
子網掩碼=“255.255.255.255”網絡= $ ClusterNetworkName; EnableDHCP時= 0}

#如果您使用的是Windows Server 2008 R2,請使用以下命令:

#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998  
子網掩碼= 255.255.255.255

您現在在Azure中擁有一個功能齊全的多實例SQL Server FCI。如果您有任何問題要構建具有從Clusteringformeremortals.com重現的新Azure ILB功能的多實例SQL Server故障轉移群集

Filed Under: Datakeeper, 伺服器集群简单化 Tagged With: 多實例SQL Server, 多實例sql server故障轉移群集

具有新Azure ILB功能的多實例SQL Server故障轉移群集

14 4 月, 2019 by Jason Aw Leave a Comment

新的Azure ILB功能允許您構建多實例SQL Server故障轉移群集

在今年9月的Microsoft Ignite上,微軟圍繞Azure發布了一些聲明。其中一個公告是內部負載平衡器上的多個VIP的普遍可用性。為什麼這對SQL Server DBA如此重要?好吧,到目前為止,如果要在Azure中部署高可用性SQL Server,則每個群集或單個可用性組偵聽器僅限於一個SQL Server FCI。此限制強制您為要在故障轉移群集中保護的每個SQL Server實例部署新群集。如果您希望在AlwaysOn AG配置中進行自動故障轉移和客戶端重定向,它還會強制您將所有數據庫分組到單個可用性組中。

如何擺脫這些限制?

這些新的ILB功能現已解除了這些限制。在這篇文章中,我將引導您完成在Azure中部署包含兩個SQL Server實例的SQL Server FCI的過程。在以後的文章中,我將引導您完成SQL Server AlwaysOn AG的相同過程。

讓我們從多實例SQL Server故障轉移群集開始

如我在Azure資源管理器中部署Microsoft SQL Server 2014故障轉移群集的帖子中所述,在Azure中構建基本的單實例SQL Server FCI。該帖子描述了創建多實例SQL Server故障轉移群集的過程。 使用DataKeeper創建群集中使用的複製卷資源,嘗試創建內部負載平衡器(ILB),然後修復SQL Server群集IP資源以使用ILB。如果您想跳過該過程并快速啟動配置,您可以始終使用Azure部署模板,使用SIOS DataKeeper創建雙節點SQL Server FCI假設您現在有一個基本的雙節點SQL Server FCI,添加第二個命名的步驟實例如下:

  1. 在另一個當前未使用的捲上創建另一個DataKeeper卷資源。如果沒有可用卷,則可能需要向Azure實例添加其他磁盤。作為此卷創建過程的一部分,新的DataKeeper卷資源將在群集中的可用存儲中註冊。有關詳細信息,請參閱前面引用的文章。
  2. 在第一個節點上安裝SQL Server的命名實例,指定我們剛剛創建的DataKeeper卷作為存儲位置。
  3. “添加節點”到第二個節點上的群集。
  4. 將此新命名實例的端口號鎖定到未使用的端口。在我的例子中,我使用端口1440。

將ILB調整為第二個實例

接下來,我們必須調整ILB以將流量重定向到第二個實例。以下是您需要遵循的步驟:添加前端IP地址,該地址與您用於第二個SQL Server實例的SQL群集IP地址相同,如下所示。具有新Azure ILB功能的多實例SQL Server故障轉移群集 接下來,我們將需要添加另一個探測,因為實例可以在不同的服務器上運行。如下圖所示,我添加了一個探測端口59998(而不是通常的59999)的探測器。我們需要確保新規則引用此探針。我們還需要記住該端口號,因為我們需要在此過程的最後一步更新與此實例關聯的IP地址。具有新Azure ILB功能的多實例SQL Server故障轉移群集 現在我們需要向ILB添加兩個新規則來引導目標為第二個SQL實例的流量。當然我們需要添加一個規則來重定向TCP端口1440(我用於SQL命名實例的端口),但由於我們現在使用的是命名實例,我們還需要一個端口來支持SQL Server Browser服務,UDP端口1434。在下面描述SQL Server Browser服務規則的圖片中,請注意前端IP地址引用了新的FrontendIP地址(10.0.0.201),端口和後端端口的UDP端口1434。在池中,您需要指定群集中的兩個服務器,最後確保選擇剛剛創建的新Health Probe。具有新Azure ILB功能的多實例SQL Server故障轉移群集 我們現在將添加TCP / 1440規則。如下圖所示,為端口TCP 1440添加新規則,或為SQL Server的命名實例鎖定的任何端口。同樣,請務必選擇新的FrontEnd IP地址和新的Health Probe(59998)。此外,請確保啟用了浮動IP(直接服務器返回)。具有新Azure ILB功能的多實例SQL Server故障轉移群集

最後一步

現在已配置負載均衡器,最後一步是運行PowerShell腳本以更新與此第二個SQL Server實例關聯的新群集IP地址。此PowerShell腳本只需要在其中一個群集節點上運行。

#定義變量

$ ClusterNetworkName =“”

#群集網絡名稱 
(在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名稱)

$ IPResourceName =“”

#SQL Server的第二個實例的IP地址資源名稱

$ ILBIP =“”

#第二個SQL實例的IP地址,
它應該與新的前端IP地址相同

導入模塊FailoverClusters

#如果您使用的是Windows Server 2012或更高版本:

Get-ClusterResource $ IPResourceName | 
Set-ClusterParameter -Multiple @ {Address = $ ILBIP; ProbePort = 59998;
子網掩碼=“255.255.255.255”網絡= $ ClusterNetworkName; EnableDHCP時= 0}

#如果您使用的是Windows Server 2008 R2,請使用以下命令:

#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59998  
子網掩碼= 255.255.255.255

您現在在Azure中擁有一個功能齊全的多實例SQL Server FCI。如果您有任何問題要構建具有從Clusteringformeremortals.com重現的新Azure ILB功能的多實例SQL Server故障轉移群集

Filed Under: Datakeeper, 伺服器集群简单化 Tagged With: 多實例SQL Server, 多實例sql server故障轉移群集

最近的帖子

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

最熱門的帖子

加入我們的郵件列表

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