Funktionskompatibilitet med AG- och DNN-lyssnare

  • Artikel

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

Dricks

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:

  • Redundanstid: Redundansväxlingstiden är snabbare när du använder en DNN-lyssnare eftersom det inte finns något behov av att vänta tills nätverkslastbalanseraren identifierar felhändelsen och ändrar dess routning.
  • Befintliga anslutningar: Anslut som görs till en specifik databas i en redundansväxlingstillgänglighetsgrupp stängs, men andra anslutningar till den primära repliken förblir öppna eftersom DNN är online under redundansväxlingen. Detta skiljer sig från en traditionell VNN-miljö där alla anslutningar till den primära repliken vanligtvis stängs när tillgänglighetsgruppen redundansväxlar, lyssnaren kopplas från och den primära repliken övergår till den sekundära rollen. När du använder en DNN-lyssnare kan du behöva justera program anslutningssträng 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 redvikarisk tillgänglighetsgrupp stäng och återställ 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 ODBC-, OLEDB-, ADO.NET-, JDBC-, PHP- och Node.js-drivrutiner måste användarna uttryckligen ange DNN-lyssnarnamnet och porten som servernamn i anslutningssträng. För att säkerställa snabb anslutning vid redundans lägger du till MultiSubnetFailover=True i anslutningssträng om SQL-klienten stöder det.

Verktyg

Användare av SQL Server Management Studio, sqlcmd, Azure Data Studio och SQL Server Data Tools måste uttryckligen ange DNN-lyssnarnamnet och porten som servernamn i anslutningssträng 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 redundansklusterinstansen också använda DNN eftersom det inte finns något sätt att placera den virtuella FCI-IP-adressen i LISTAN över tillgänglighetsgruppers DNN IP.

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 dnnlsnroch 5022 är porten för FCI:ns speglingsslutpunkt ser kodfragmentet Transact-SQL (T-SQL) 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.

Replikering

Transaktions-, sammanslagnings- och ögonblicksbildreplikering har alla stöd för att ersätta VNN-lyssnaren med DNN-lyssnaren och porten i replikeringsobjekt som ansluter 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 redundansväxlingen ändrar du LB-regeln till den nya MSDTC-porten när 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 begrä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 filresursen med hjälp av Windows-fil-API:et.

Länkade servrar

Konfigurera den länkade servern med hjälp av tillgänglighetsgruppens 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 och svar

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 redundanstiden samma som tillgänglighetsgruppens redundanstid, utan ytterligare tid (till exempel 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 anslutningssträng stöd 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 routning?

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

Relaterat innehåll