Dela via

Funktionskompatibilitet med AG- och DNN-lyssnare

Gäller för:SQL Server på en virtuell Azure-dator

Tips/Råd

Det finns många metoder för att distribuera en tillgänglighetsgrupp. Förenkla distributionen och eliminera behovet av en Azure Load Balancer eller ett distribuerat nätverksnamn (DNN) för din AlwaysOn-tillgänglighetsgrupp genom att skapa dina virtuella SQL Server-datorer i flera undernät i samma virtuella Azure-nätverk. Om du redan har skapat tillgänglighetsgruppen i ett enda undernät kan du migrera den till en miljö med flera undernät.

Det finns vissa SQL Server-funktioner som förlitar sig på ett hårdkodat virtuellt nätverksnamn (VNN). När du använder DNN-lyssnaren (distribuerat nätverksnamn) med din AlwaysOn-tillgänglighetsgrupp och SQL Server på virtuella Azure-datorer i ett enda undernät kan det därför finnas några ytterligare överväganden.

Den här artikeln beskriver SQL Server-funktioner och samverkan med tillgänglighetsgruppens DNN-lyssnare.

Beteendeskillnader

Det finns vissa beteendeskillnader mellan funktionerna i VNN-lyssnaren och DNN-lyssnaren som är viktiga att notera:

  • Redundansväxlingstid: Redundansväxlingstiden är snabbare när du använder en DNN-lyssnare eftersom det inte finns något behov av att vänta på att nätverkslastbalanseraren ska upptäcka felet och ändra sin omdirigering.
  • Befintliga anslutningar: Anslutningar som görs till en specifik databas vid en tillgänglighetsgrupp vid redundansväxling stängs, men andra anslutningar till den primära repliken förblir öppna eftersom DNN förblir online under redundansväxlingsprocessen. Detta skiljer sig från en traditionell VNN-miljö där alla anslutningar till den primära replikan vanligtvis stängs när tillgänglighetsgruppen genomgår en failover, lyssnaren går offline och den primära replikan övergår till att ha den sekundära rollen. När du använder en DNN-lyssnare kan du behöva justera programanslutningssträngarna för att säkerställa att anslutningar omdirigeras till den nya primära repliken vid redundansväxling.
  • Öppna transaktioner: Öppna transaktioner mot en databas i en felförbisedd tillgänglighetsgrupp stängs och återställs, och du måste återansluta manuellt. I SQL Server Management Studio stänger du till exempel frågefönstret och öppnar ett nytt.

Klientdrivrutiner

För drivrutiner för ODBC, OLEDB, ADO.NET, JDBC, PHP och Node.js måste användarna uttryckligen ange DNN-lyssnarnamn och port som servernamn i anslutningssträngen. För att säkerställa snabb anslutning vid redundans lägger du till MultiSubnetFailover=True i anslutningssträngen om SQL-klienten stöder den.

Tools

Användare av SQL Server Management Studio, sqlcmd och SQL Server Data Tools måste uttryckligen ange DNN-lyssnarnamnet och porten som servernamn i anslutningssträngen för att ansluta till lyssnaren.

Det går för närvarande inte att skapa DNN-lyssnaren via SQL Server Management Studio-gränssnittet (SSMS).

Tillgänglighetsgrupper och FCI

Du kan konfigurera en AlwaysOn-tillgänglighetsgrupp med hjälp av en redundansklusterinstans (FCI) som en av replikerna. För att den här konfigurationen ska fungera med DNN-lyssnaren måste även failover-klusterinstansen använda DNN, eftersom det inte finns något sätt att placera den virtuella FCI-IP-adressen i DNN-IP-listan för tillgänglighetsgruppen.

I den här konfigurationen måste speglingsslutpunktens URL för FCI-repliken använda FCI DNN. På samma sätt måste den skrivskyddade routningen till FCI-repliken använda FCI DNN om FCI används som skrivskyddad replik.

Formatet för speglingsslutpunkten är: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Om ditt FCI DNN DNS-namn till exempel är dnnlsnr, och 5022 är porten för FCI:ns speglingsslutpunkt, ser kodfragmentet Transact-SQL (T-SQL) för att skapa slutpunkts-URL:en ut så här:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

På samma sätt är formatet för den skrivskyddade routnings-URL:en: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Om ditt DNN DNS-namn till exempel är dnnlsnr, och 1444 är porten som används av det skrivskyddade SQL Server FCI-målet, ser T-SQL-kodfragmentet för att skapa den skrivskyddade routnings-URL:en ut så här:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Du kan utelämna porten i URL:en om den är standardporten 1433. För en namngiven instans konfigurerar du en statisk port för den namngivna instansen och anger den i url:en för skrivskyddad routning.

Distribuerad tillgänglighetsgrupp

Om tillgänglighetsgruppens lyssnare har konfigurerats med ett distribuerat nätverksnamn (DNN) stöds inte konfigurationen av en distribuerad tillgänglighetsgrupp ovanpå tillgänglighetsgruppen.

Replication

Transaktions-, sammanslagnings- och ögonblicksbildsreplikering stödjer alla att byta ut VNN-lyssnaren mot DNN-lyssnaren och porten i de replikeringsobjekt som är anslutna till lyssnaren.

Mer information om hur du använder replikering med tillgänglighetsgrupper finns i Utgivare och tillgänglighetsgrupp, Prenumerant och tillgänglighetsgrupp samt distributör och tillgänglighetsgrupp.

MSDTC

Både lokal och klustrad MSDTC stöds, men MSDTC använder en dynamisk port, vilket kräver en Standard Azure Load Balancer för att konfigurera HA-porten. Den virtuella datorn måste därför använda en standard-IP-reservation, eller så kan den inte exponeras för Internet.

Definiera två regler, en för RPC Endpoint Mapper-port 135 och en för den verkliga MSDTC-porten. Efter omställningen ändrar du LB-regeln till den nya MSDTC-porten efter att den har ändrats på den nya noden.

Om MSDTC är lokal måste du tillåta utgående kommunikation.

Distribuerad fråga

Distribuerad fråga förlitar sig på en länkad server som kan konfigureras med hjälp av AG DNN-lyssnaren och porten. Om porten inte är 1433 väljer du alternativet Använd annan datakälla i SQL Server Management Studio (SSMS) när du konfigurerar den länkade servern.

FILESTREAM

FILESTREAM stöds men inte för scenarier där användare får åtkomst till den avgränsade filresursen med hjälp av Windows-fil-API:et.

FileTable

FileTable stöds men inte för scenarier där användare får åtkomst till den begränsade fildelningen via Windows File API.

Länkade servrar

Konfigurera den länkade servern med hjälp av AG DNN-lyssnarnamn och port. Om porten inte är 1433 väljer du alternativet Använd annan datakälla i SQL Server Management Studio (SSMS) när du konfigurerar den länkade servern.

Vanliga frågor

Vilken SQL Server-version ger AG DNN-lyssnarstöd?

SQL Server 2019 CU 8 och senare.

Vilken är den förväntade redundanstiden när DNN-lyssnaren används?

För DNN-lyssnaren är failovertiden densamma som AG-failovertiden, utan extra tid (som avsökningstid när du använder Azure Load Balancer).

Finns det något versionskrav för ATT SQL-klienter ska ha stöd för DNN med OLEDB och ODBC?

Vi rekommenderar MultiSubnetFailover=True stöd för anslutningssträngar för DNN-lyssnare. Den är tillgänglig från och med SQL Server 2012 (11.x).

Krävs det några konfigurationsändringar för SQL Server för att jag ska kunna använda DNN-lyssnaren?

SQL Server kräver ingen konfigurationsändring för att använda DNN, men vissa SQL Server-funktioner kan kräva mer övervägande.

Stöder DNN kluster med flera undernät?

Ja. Klustret binder DNN i DNS med de fysiska IP-adresserna för alla repliker i tillgänglighetsgruppen oavsett undernät. SQL-klienten försöker alla IP-adresser för DNS-namnet oavsett undernät.

Stöder tillgänglighetsgruppens DNN-lyssnare skrivskyddad routing?

Ja. Skrivskyddad routning stöds med DNN-lyssnaren.

Relaterat innehåll