Azure SQL Server VM Group Listener - The Network path was not found

Überblick

In einem kürzlich durchgeführten Projekt haben wir ein Server Cluster in Microsoft Azure mit zwei Windows Server 2019 VM's sowie SQL Server 2022 installiert. Das Ziel war, einen Group Listener einzurichten, um den Connection String des ebenfalls auf beiden Servern installierten SQL Server Analysis Services (SSAS) im Reporting Projekt auf die jeweils aktive Datenbank zu lenken. Andernfalls müsste nach einem Schwenk auf den anderen Server der Connection String im SSAS-Projekt manuell angepasst werden. Generell sollte der Listener Name inkl. Listener IP innerhalb der Azure Umgebung selbst auch immer auf den aktiven Server zeigen.

Trotz erfolgreicher Installation und einer durchwegs "grünen" Anzeige im Cluster-Dashboard war der Group Listener ausschließlich vom momentan primären Server aus auflösbar, während der Zugriff vom sekundären Server aus auf den Listener nicht möglich war. Es gab keine weiteren offensichtlichen Konfigurationsmöglichkeiten im Windows Server, bzw. im SQL Server, die zur Lösung dieses Problems hätten beitragen können.

Es kam beim Verbindungsaufbau vom nicht-primären Server auf den Listener selbst zu keinem Timeout sondern zu folgender Fehlermeldung:

“A network-related or instance-specifc error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (Provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 53) --> The Network Path was not found.“

Fehlermeldung beim Zugriff vom sekundären Server aus auf den Listener

Ausgangslage

Der Listener wurde unter der IP x.x.x.43 und dem Standard-Port 1433 eingerichtet. Auf der linken Seite in der nachfolgenden Abbildung ist SSMS erfolgreich mit dem Server direkt und ebenfalls über den Listener verbunden (wir befinden uns auf dem primären Server selbst).

In der Mitte ist das Dashboard der Verfügbarkeitsgruppe zu sehen und rechts die Eigenschaften des Listeners. Es wurde ebenfalls überprüft, dass die IP Adresse nicht von einem anderem System bereits belegt ist.

Die Lösung lag im Azure Portal und einer fehlenden Konfiguration dort. Um die gewählte IP Adresse in Azure verfügbar zu machen, muss diese als Loadbalancer hinzugefügt werden und die VMs als Backend Pool für diesen Loadbalancer konfiguriert werden.

Außerdem muss der Cluster geringfügig über ein PowerShell Skript angepasst werden:

Es wird ein zweiter “Public” Loadbalancer benötigt, wenn vom SQL Server weiterhin nach außen, bzw. auf das Internet zugegriffen werden soll (das ist nicht im Scope dieses Artikels).

Einrichtung eines Load Balancers in Azure

Wir melden uns im Azure Portal an und wählen Loadblanacer und dann Hinzufügen. Wichtig ist hierbei die korrekte Region und der Type Internal. Die Region muss mit der Region der VMs übereinstimmen.

Im nächsten Schritt wird das Netzwerk (das gleiche wie die VMs) ausgewählt und die freie IP (hier x.x.x.43) für den Listener festgelegt. Diese IP ist bereits so im Group Listener im SQL Server eingestellt.

IP Konfiguration des Load Balancers bzw. Listeners

Anschließend werden beide VMs dem Backendpool hinzugefügt. Sollten die VMs an dieser Stelle nicht auswählbar sein, dann muss die Auswahl der Region im Schritt 1 überprüft werden.

Anschließend wird eine neue “Load balancing rule” hinzugefügt. Hierbei sind wichtig:

Der Port und der Backend Port entsprechen dem Port des Group Listeners, wie im SQL Server bereits eingestellt (1433).
Der Health Probe Port kann auch auf eine von 80 abweichende Nummer festgelegt werden, dies muss dann nachfolgend im PowerShell-Skript berücksichtigt werden.

Der Listener kann nun anschließend mit Review + create erstellt werden.

Konfiguration des Clusters

Anschließend muss der Cluster noch entsprechend dem eben eingerichtetem Load Balancer konfiguriert werden. Dazu auf dem primären Server im Failover Cluster Manager zunächst die entsprechende Listener-Rolle stoppen (Rechtsklick und Bring Offline wählen).

Anschließend folgendes PowerShell Skript in einer Administrator Konsole ausführen. Das Skript identifiziert automatisch den Listener und die konfigurierte IP-Adresse um jeweils erforderliche Parameter zu setzen. Sollte ein anderer Port als TCP 80 als Probe-Port gewählt worden sein, so muss dieser in Zeile 5 angepasst werden.

$AG = Get-ClusterResource | Where-Object { $_.resourcetype -eq "SQL Server Availability Group" }
$Listener = Get-ClusterResource | Where-Object { $_.Name -like $AG.Name + "*" -and $_.resourcetype -eq "Network Name" }
$IP = Get-ClusterResource | Where-Object { $_.Name -like $AG.Name + "*" -and $_.resourcetype -eq "IP Address" }

Get-ClusterResource $IP.Name | Set-ClusterParameter -Multiple @{"ProbePort"="80";"OverrideAddressMatch"=1;}
Get-ClusterResource $Listener.Name | Set-ClusterParameter -Name "PublishPTRRecords" -Value 1
Get-ClusterResource $Listener.Name | Set-ClusterParameter -Name "HostRecordTTL" -Value 60

Anschließend im Failover Cluster Manager die Rolle wieder Online bringen (Rechtsklick und Bring Online wählen). Der Status sollte wieder wie zuvor aussehen: Running.

Windows Defender Firewall

Zuletzt muss noch auf beiden Servern die Windows Defender Firewall geprüft werden. Folgende Ports müssen Inbound freigeschaltet werden.

TCP 1433 (SQL Connection, hier ggf. der zusätzliche Port für den Listener)
TCP 5022 (Availability Group)
TCP 80 (Load Balancer Probe)

Zusätzlich können bei Bedarf noch TCP 2383 (SSAS) und UDP 1434 (SQL Browser) freigeschaltet werden.

Anschließend kann nach einem Failover von beiden Servern auf den Listener zugegriffen werden.

Fazit

In diesem Artikel haben wir gezeigt wie ein Group Listener im SQL Server in einer Azure Umgebung mithilfe eines Load Balancers Objektes eingerichtet werden kann. Dieser konnte anschließend erfolgreich in den Connection String des Analysis Services-Projektes eingefügt werden um immer auf die aktive Datenbankinstanz zu zeigen.

Dieser Artikel unterstreicht die Komplexität der Netzwerkkonfiguration in verteilten Systemen wie Microsoft Azure. Es hebt hervor, wie entscheidend eine gründliche Planung, ein tiefgehendes Verständnis der Komponenten und eine ganzheitliche Betrachtung sind.

Wenn Sie mehr zu diesem Thema erfahren möchten, stehen Ihnen unsere Experten gerne zur Verfügung. Vereinbaren Sie unverbindlich ein Beratungsgespräch über unser Kontaktformular. Wir helfen Ihnen gerne weiter!