Delen via


Functie-interoperabiliteit met AG en DNN-listener

Van toepassing op: SQL Server op Azure VM

Fooi

Er zijn veel methoden om een beschikbaarheidsgroep te implementeren. Vereenvoudig uw implementatie en elimineer de noodzaak van een Azure Load Balancer of gedistribueerde netwerknaam (DNN) voor uw AlwaysOn-beschikbaarheidsgroep door uw virtuele SQL Server-machines (VM's) te maken in meerdere subnetten binnen hetzelfde virtuele Azure-netwerk. Als u uw beschikbaarheidsgroep al in één subnet hebt gemaakt, kunt u deze migreren naar een omgeving met meerdere subnetten.

Er zijn bepaalde SQL Server-functies die afhankelijk zijn van een in code vastgelegde naam van een virtueel netwerk (VNN). Als zodanig, wanneer u de DNN-listener (gedistribueerde netwerknaam) gebruikt met uw AlwaysOn-beschikbaarheidsgroep en SQL Server op Azure-VM's in één subnet, zijn er mogelijk enkele aanvullende overwegingen.

In dit artikel vindt u informatie over SQL Server-functies en interoperabiliteit met de DNN-listener van de beschikbaarheidsgroep.

Gedragsverschillen

Er zijn enkele gedragsverschillen tussen de functionaliteit van de VNN-listener en de DNN-listener die belangrijk zijn om op te merken:

  • Failovertijd: failovertijd is sneller wanneer u een DNN-listener gebruikt, omdat er niet hoeft te worden gewacht totdat de netwerk load balancer de fout gebeurtenis detecteert en de routering ervan wijzigt.
  • Bestaande verbindingen: Verbinding maken die zijn gemaakt met een specifieke database binnen een failover-overbeschikbaarheidsgroep, maar andere verbindingen met de primaire replica blijven open, omdat de DNN online blijft tijdens het failoverproces. Dit is anders dan een traditionele VNN-omgeving waarbij alle verbindingen met de primaire replica doorgaans sluiten wanneer de beschikbaarheidsgroep een failover uitvoert, de listener offline gaat en de primaire replica overgaat naar de secundaire rol. Wanneer u een DNN-listener gebruikt, moet u mogelijk de toepassings-verbindingsreeks aanpassen om ervoor te zorgen dat verbindingen worden omgeleid naar de nieuwe primaire replica na failover.
  • Openstaande transacties: Open transacties voor een database in een failover-overbeschikbaarheidsgroep en draai deze terug en maak handmatig opnieuw verbinding. Sluit bijvoorbeeld in SQL Server Management Studio het queryvenster en open een nieuw venster.

Clientstuurprogramma's

Voor ODBC-, OLEDB-, ADO.NET-, JDBC-, PHP- en Node.js-stuurprogramma's moeten gebruikers expliciet de DNN-listenernaam en -poort opgeven als de servernaam in de verbindingsreeks. Als u snelle connectiviteit wilt garanderen bij failover, voegt u deze toe MultiSubnetFailover=True aan de verbindingsreeks als de SQL-client dit ondersteunt.

Extra

Gebruikers van SQL Server Management Studio, sqlcmd, Azure Data Studio en SQL Server Data Tools moeten expliciet de DNN-listenernaam en -poort opgeven als de servernaam in de verbindingsreeks om verbinding te maken met de listener.

Het maken van de DNN-listener via de GUI van SQL Server Management Studio (SSMS) wordt momenteel niet ondersteund.

Beschikbaarheidsgroepen en FCI

U kunt een AlwaysOn-beschikbaarheidsgroep configureren met behulp van een failoverclusterexemplaar (FCI) als een van de replica's. Om deze configuratie te laten werken met de DNN-listener, moet het exemplaar van het failovercluster ook de DNN gebruiken, omdat er geen manier is om het virtuele IP-adres van de FCI in de IP-lijst van de AG DNN te plaatsen.

In deze configuratie moet de eindpunt-URL voor spiegeling voor de FCI-replica gebruikmaken van de FCI-DNN. Als de FCI wordt gebruikt als een alleen-lezen replica, moet de alleen-lezenroutering naar de FCI-replica gebruikmaken van de FCI-DNN.

De indeling voor het eindpunt voor spiegeling is: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Als uw FCI DNN DNS-naam bijvoorbeeld de dnnlsnr5022 poort is van het spiegelingseindpunt van de FCI, ziet het Codefragment Transact-SQL (T-SQL) voor het maken van de eindpunt-URL er als volgt uit:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

Op dezelfde manier is de indeling voor de alleen-lezen routerings-URL: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Als uw DNN DNS-naam bijvoorbeeld is dnnlsnren de poort is die 1444 wordt gebruikt door de alleen-lezen-DOEL-SQL Server FCI, ziet het T-SQL-codefragment voor het maken van de alleen-lezen routerings-URL er als volgt uit:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

U kunt de poort weglaten in de URL als dit de standaardpoort van 1433 is. Configureer voor een benoemd exemplaar een statische poort voor het benoemde exemplaar en geef deze op in de alleen-lezen routerings-URL.

Gedistribueerde beschikbaarheidsgroep

Als uw listener voor beschikbaarheidsgroepen is geconfigureerd met behulp van een gedistribueerde netwerknaam (DNN), wordt het configureren van een gedistribueerde beschikbaarheidsgroep boven op uw beschikbaarheidsgroep niet ondersteund.

Replicatie

Transactionele, samenvoeging en momentopnamereplicatie bieden alle ondersteuning voor het vervangen van de VNN-listener door de DNN-listener en -poort in replicatieobjecten die verbinding maken met de listener.

Zie Publisher en AG, Subscriber en AG en Distributor en AG voor meer informatie over het gebruik van replicatie met beschikbaarheidsgroepen.

MSDTC

Zowel lokale als geclusterde MSDTC worden ondersteund, maar MSDTC maakt gebruik van een dynamische poort. Hiervoor is een standaard Azure Load Balancer vereist om de HA-poort te configureren. Als zodanig moet de virtuele machine een standaard-IP-reservering gebruiken of kan deze niet worden blootgesteld aan internet.

Definieer twee regels, één voor de RPC Endpoint Mapper-poort 135 en één voor de echte MSDTC-poort. Wijzig na een failover de LB-regel in de nieuwe MSDTC-poort nadat deze op het nieuwe knooppunt is gewijzigd.

Als de MSDTC lokaal is, moet u uitgaande communicatie toestaan.

Gedistribueerde query

Gedistribueerde query is afhankelijk van een gekoppelde server, die kan worden geconfigureerd met behulp van de AG DNN-listener en -poort. Als de poort niet 1433 is, kiest u de optie Andere gegevensbron gebruiken in SQL Server Management Studio (SSMS) bij het configureren van uw gekoppelde server.

BESTANDSSTROOM

FILESTREAM wordt ondersteund, maar niet voor scenario's waarin gebruikers toegang hebben tot de bereikbestandsshare met behulp van de Windows-bestands-API.

FileTable

FileTable wordt ondersteund, maar niet voor scenario's waarin gebruikers toegang hebben tot de bestandsshare met behulp van de Windows-bestands-API.

Gekoppelde servers

Configureer de gekoppelde server met behulp van de naam en poort van de AG DNN-listener. Als de poort niet 1433 is, kiest u de optie Andere gegevensbron gebruiken in SQL Server Management Studio (SSMS) bij het configureren van uw gekoppelde server.

Veelgestelde vragen

Welke SQL Server-versie biedt ondersteuning voor AG DNN-listener?

SQL Server 2019 CU 8 en hoger.

Wat is de verwachte failovertijd wanneer de DNN-listener wordt gebruikt?

Voor DNN-listener is de failovertijd hetzelfde als de ag-failovertijd, zonder extra tijd (zoals testtijd wanneer u Azure Load Balancer gebruikt).

Is er versievereiste voor SQL-clients om DNN te ondersteunen met OLEDB en ODBC?

We raden verbindingsreeks ondersteuning voor DNN-listener aan MultiSubnetFailover=True . Deze is beschikbaar vanaf SQL Server 2012 (11.x).

Zijn er wijzigingen in de SQL Server-configuratie vereist voor mij om de DNN-listener te gebruiken?

SQL Server vereist geen configuratiewijziging voor het gebruik van DNN, maar voor sommige SQL Server-functies is mogelijk meer aandacht vereist.

Ondersteunt DNN clusters met meerdere subnetten?

Ja. Het cluster verbindt de DNN in DNS met de fysieke IP-adressen van alle replica's in de beschikbaarheidsgroep, ongeacht het subnet. De SQL-client probeert alle IP-adressen van de DNS-naam, ongeacht het subnet.

Ondersteunt de DNN-listener van de beschikbaarheidsgroep alleen-lezenroutering?

Ja. Alleen-lezenroutering wordt ondersteund met de DNN-listener.