在SQL Server故障轉移實例群集連接中排查Azure ILB連接問題

我使用以下工具來幫助我解決SQL Server故障轉移群集實例連接問題的疑難解答。特別是那些討厭的Azure ILB連接問題。每當我找到一個新工具時，我都會嘗試更新這篇文章。

NETSTAT

第一個工具是一個簡單的測試，用於驗證SQL群集IP是否正在偵聽它應該偵聽的端口。在這種情況下，SQL群集IP地址是10.0.0.201。但它使用的是端口1433的默認實例。

這裡是幫助你快速識別活動節點是否在該端口上偵聽的命令。在我們的情況下，一切看起來很正常

C： Users  dave.SIOS> netstat -na |找到“1433”
TCP 10.0.0.4:49584 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49592 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49593 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49595 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.201:1433 0.0.0.0:0聽
ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49592 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49593 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49595 ESTABLISHED

一旦我確定SQL正在監聽正確的端口，我使用PSPING嘗試遠程連接到端口。

PSPING

PSPing是Microsoft提供的PSTools軟件包的一部分。我通常下載該工具並將PSPing直接放在我的System32文件夾中，這樣我就可以隨時使用它而無需更改目錄。

現在，假設從ILB，集群和防火牆的角度來看，所有配置都是正確的，那麼您應該能夠從被動服務器ping SQL集群IP地址和端口1433。你會得到下面顯示的結果…

C： Users  dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01  -  PsPing  -  ping，延遲，帶寬測量工具
Copyright（C）2012-2014 Mark Russinovich
Sysinternals  -  www.sysinternals.com
TCP連接到10.0.0.201:1433：
5次迭代（熱身1）連接測試：
連接到10.0.0.201:1433（熱身）：6.99ms
連接到10.0.0.201:1433：0.78ms
連接到10.0.0.201:1433：0.96ms
連接到10.0.0.201:1433：0.68ms
連接到10.0.0.201:1433：0.89ms
如果事情沒有正確配置，您可能會看到與以下類似的結果...
C： Users  dave.SIOS> psping 10.0.0.201:1433
TCP連接到10.0.0.102:1433：
5次迭代（熱身1）連接測試：
連接到10.0.0.102:1433（預熱）： 
由於超時期限到期，此操作返回。
連接到10.0.0.102:1433（預熱）： 
由於超時期限到期，此操作返回。
連接到10.0.0.102:1433（預熱）： 
由於超時期限到期，此操作返回。
連接到10.0.0.102:1433（預熱）： 
由於超時期限到期，此操作返回。
連接到10.0.0.102:1433（預熱）： 
由於超時期限到期，此操作返回。

如果PSPing連接，但您的應用程序連接出現問題，則可能需要深入一點。我見過像Great Plains這樣的應用程序也想連接到445端口。如果您的應用程序無法連接，但PSPing可以很好地連接到1433。然後，您可能需要執行網絡跟踪並查看應用程序嘗試連接的其他端口。最後一步是為這些端口添加負載平衡規則。

命名實例

計劃使用命名實例？您需要確保鎖定TCP服務以使用靜態端口。 同時，您還需要確保向負載平衡器添加規則，以重定向SQL瀏覽器服務的UDP 1434。否則，您將無法連接到您的命名實例。

FIREWALL

打開TCP端口1433和59999應該涵蓋所有需要的手動步驟。但是，在解決連接問題時，我通常關閉Windows防火牆以消除防火牆，將其視為問題的可能原因。別忘了。Azure還有一個稱為網絡安全組的防火牆。如果有人將其從可能阻止流量的默認設置改變。

姓名解析

嘗試ping SQL集群名稱。它應該解析為SQL Server群集iP地址。儘管我已經看到過幾次，但與SQL群集網絡名稱關聯的DNS A記錄神奇地從DNS中消失。如果是這種情況，請繼續閱讀 – 在SQL中將SQL Custer名稱和IP地址作為A記錄進行讀取。

SQL配置管理器

在SQL配置管理器中，您應該看到列出的SQL群集IP地址和端口1433。如果碰巧你安裝了一個命名實例，你當然需要進入這裡並將端口鎖定到一個特定的端口，並使你的負載平衡規則反映該端口。由於Azure ILB僅限於每個AG的ILB限制，所以實際上我沒有看到使用命名實例的有效理由。讓自己更容易，只使用SQL的默認實例。（更新：截至2016年10月，每個ILB可以有多個IP地址，因此您可以在群集中安裝多個SQL實例。）

經過Clustering For Mere Mortals的許可轉載。

在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的許可轉載。

@Sqlsatnash在#Azure Session中部署高可用SQL Server在SQL週六納什維爾，1月16日

我將前往納什維爾分享有關部署高可用性SQL服務器的信息。在那裡，有一些我等不及趕上的東西 – 技術和音樂。當我在那裡的時候，我當然希望我能在The Station Inn有一些很好的音樂。

在Azure中部署高可用性SQL Server時參加我的會話

1月16日將成為學習和交流的好日子。與我的#SQLPass家族聊天並加入我的會話。對於那些熱衷於在Azure中部署SQL Server的人來說，這個長時間的會話非常適合。

在雲數據庫/應用程序開發和部署

正如我們已經知道的那樣，Windows Azure是部署SQL Server的優秀IaaS平台。即使在Microsoft管理基礎架構時，也需要規劃高可用性和災難恢復。在本次會議中，了解如何利用Azure故障域，升級域和內部負載均衡器來確保Azure雲中SQL Server部署的高可用性。您將了解到Azure Classic和Azure Resource Manager之間的區別。同時，它將如何影響您的SQL Server可用性。雖然Microsoft Azure提供了99.95％的SLA，但請確保您的SQL Server部署符合要求。此外，此會話最適合那些有意移動或已將SQL Server實例移至Azure的人員。順便說一下，本次會議的參與者應具有SQL Server AlwaysOn故障轉移群集以及可用性組的基本知識。但是，如果你不這樣做，不要擔心，因為你應該能夠通過一點練習和實驗快速趕上。

轉載自https://clusteringformeremortals.com/2015/12/21/sqlsatnash-deploying-highly-available-sql-server-in-azure-session-at-sql-saturday-nashville-jan-16th/

Azure資源管理器的優勢和Azure中高度可用的SQL Server部署

Azure資源管理器（ARM）是使用Microsoft Azure IaaS的最新和最好的方式。Azure資源管理器的優點很多 – 模板部署，分組，簡化計費等等。這種新模式有望實現新功能和更多互動。

抓住網絡研討會

Microsoft雲和數據中心管理MVP大衛伯明翰將介紹ARM並深入研究如何利用ARM在雲中啟用高可用性和可擴展的SQL Server部署。註冊參加這個網絡研討會… https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

想知道如何利用ARM實現高度可用和可擴展的SQL Server部署？

那麼，如果你的答案是肯定的，那麼我為你提供了一個很好的建議。特別是，如果您有興趣了解為什麼Azure資源管理器（ARM）是使用Microsoft Azure IaaS的最新和最簡單的方法，那麼在12月15日發生的網絡研討會對您來說非常適合。與ARM合作非常好。首先，有模板部署，分組，簡化計費等等。你必須為自己嘗試一些這些新功能，以及與這種新模式不同的新互動方式。

請參閱Azure資源管理器可以執行的操作

加入Microsoft雲和數據中心管理MVP大衛伯明翰，他介紹ARM。仔細研究如何使用ARM的強大功能在雲中部署高可用性和可擴展的SQL Server部署。

時間：12月15日

時間：美國東部時間下午1:00 /太平洋標準時間10:00

在這裡註冊 – https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

轉載https://clusteringformeremortals.com/2015/11/16/azure-resource-manager-and-highly-available-sql-server-webinar-sqltips/的許可