Date: 15 6 月, 2018
在ARM中配置#AZURE ILB對於SQL Server故障轉移群集實例或AG使用AZURE Powershell 1.0
在之前的文章中，我詳細介紹瞭如何在ARM中為SQL Server故障轉移群集或AG資源配置Azure ILB。該文章的方向是在Azure PowerShell 1.0的GA之前編寫的。由於Azure PowerShell 1.0的可用性，創建ILB的主要腳本需要略有不同。文章的其餘部分仍然準確。但是，如果您使用的是Azure PowerShell 1.0或更高版本，則在該文章中描述的創建ILB的腳本應如下所示。
＃替換下面列出的變量的值 $ ResourceGroupName ='SIOS-EAST'＃資源組部署SQL節點的名稱 $ FrontEndConfigurationName ='FEEAST'＃您可以為此參數提供任何名稱。 $ BackendConfiguratioName ='BEEAST'＃您可以為此參數提供任何名稱。 $ LoadBalancerName ='ILBEAST'＃為內部本地餘額對象提供一個名稱 $ Location ='eastus2'＃輸入SQL Deployements的數據中心位置 $ subname ='public'＃提供放置SQL節點的子網名稱 $ ILBIP = '10 .0.0.201'＃為監聽器或負載均衡器提供IP地址 $ subnet = Get-AzureRMVirtualNetwork -ResourceGroupName $ ResourceGroupName | Get-AzureRMVirtualNetworkSubnetConfig -name $ subname $ FEConfig = New-AzureRMLoadBalancerFrontendIpConfig -Name $ FrontEndConfigurationName -PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id $ BackendConfig =新AzureRMLoadBalancerBackendAddressPoolConfig -Name $ BackendConfiguratioName New-AzureRMLoadBalancer -Name $ LoadBalancerName -ResourceGroupName $ ResourceGroupName -Location $ Location -FrontendIpConfiguration $ FEConfig -BackendAddressPool $ BackendConfig
該原始文章的其餘部分是相同的，但我剛剛在這裡複製它以方便使用…
使用GUI
現在創建了ILB，我們應該在資源組的Azure門戶中看到它。見下面的圖片。
剩下的配置也可以通過PowerShell完成，但我將在我的示例中使用GUI。
如果您想使用PowerShell，您可以通過查看本文來拼湊腳本。 不幸的是，這篇文章迷惑了我。我會在一天之內弄清楚它的存在並嘗試以用戶友好的格式記錄它。到目前為止，我認為GUI對於下一步很好。
讓我們開始吧
跟隨下面的屏幕截圖。如果您迷路了，請按照Azure門戶頂部的導航提示找出我們的位置。
第一步
- 點擊後台池設置標籤。選擇後端池來更新可用性集和虛擬機。保存您的更改。
- 通過單擊探針選項卡上的添加來配置負載平衡器的探針。為探測器命名並將其配置為使用TCP端口59999。我已將探測間隔和不健康閾值設置為默認設置。這意味著ILB在故障切換後從被激活節點列表中移除被動節點需要10秒鐘的時間。您的客戶可能需要長達10秒才能重定向到新的活動節點。一定要保存您的更改。
下一步
- 導航到“負載平衡規則”選項卡並添加新規則。給規則一個明智的名字（SQL1433或其他）。 選擇TCP協議端口1433（假設您正在使用SQL Server的默認實例）。為後端端口選擇1433。對於後端池，我們將選擇我們之前創建的後端池（BE）。 對於探測器，我們也將選擇我們之前創建的探測器。
我們不想啟用會話持久性，但我們希望啟用浮動IP（直接服務器返回）。我已將空閒超時設置為默認設置。您可能需要考慮將其提高到最大值。原因是每次連接斷開並需要重新建立時，我都會看到一些應用程序，如SAP日誌錯誤消息。
- 此時配置ILB。 SQL Server故障轉移群集只需要執行一個最後步驟。我們需要更新SQL IP群集資源，就像我們在Classic部署模型中所用的一樣。為此，您只需在其中一個群集節點上運行以下PowerShell腳本。請注意，SubnetMask =“255.255.255.255”不是一個錯誤。 無論您的實際子網掩碼是什麼，都使用32位掩碼。
最後一個註釋
在我最初的測試中，即使完成了上述所有步驟，仍然無法連接到SQL資源名稱。在將我的頭靠在牆上幾個小時後，我發現由於某種原因，SQL群集名稱資源未在DNS中註冊。我不確定這是怎麼發生的或者它是否會一致發生，但是如果連接時遇到問題，我肯定會檢查DNS，並將SQL集群名稱和IP地址添加為新的A記錄（如果它尚未存在）。
當然，別忘了Windows防火牆。您必須為1433和59999制定例外規定，或者關閉它直到您像我一樣正確配置所有設置。您可能想要利用Azure網絡安全組而不是本地Windows防火牆，以獲得跨所有Azure資源的更加統一的體驗。
祝你好運，讓我知道你是如何做出的。
轉到此處，了解SIOS如何幫助全球各地的公司創建SQL Server故障轉移群集。
經過Clustering For Mere Mortals的許可轉載。