Sdílet prostřednictvím

Interoperabilita funkcí s naslouchacím procesem skupiny dostupnosti a sítě DNN

  • Článek

Platí pro: SQL Server na virtuálním počítači Azure

Tip

Existuje mnoho metod nasazení skupiny dostupnosti. Zjednodušte nasazení a eliminujte potřebu služby Azure Load Balancer nebo názvu distribuované sítě (DNN) pro vaši skupinu dostupnosti AlwaysOn vytvořením virtuálních počítačů s SQL Serverem v několika podsítích ve stejné virtuální síti Azure. Pokud jste skupinu dostupnosti už vytvořili v jedné podsíti, můžete ji migrovat do prostředí s více podsítěmi.

Existují určité funkce SQL Serveru, které spoléhají na pevně zakódovaný název virtuální sítě (VNN). Například při použití naslouchacího procesu DNN (Distributed Network Name) se skupinou dostupnosti AlwaysOn a SQL Serverem na virtuálních počítačích Azure v jedné podsíti může existovat několik dalších aspektů.

Tento článek podrobně popisuje funkce SQL Serveru a interoperabilitu s naslouchacím procesem skupiny dostupnosti DNN.

Rozdíly v chování

Mezi funkcemi naslouchacího procesu VNN a naslouchacího procesu DNN existuje několik rozdílů:

  • Čas převzetí služeb při selhání: Doba převzetí služeb při selhání je rychlejší při použití naslouchacího procesu DNN, protože není potřeba čekat, až nástroj pro vyrovnávání zatížení sítě zjistí událost selhání a změní směrování.
  • Existující připojení: Připojení vytvořená ke konkrétní databázi v rámci skupiny dostupnosti při selhání se zavře, ale ostatní připojení k primární replice zůstanou otevřená, protože síť DNN zůstane během procesu převzetí služeb při selhání online. Liší se od tradičního prostředí VNN, kde se všechna připojení k primární replice obvykle zavírají, když skupina dostupnosti převezme služby při selhání, naslouchací proces přejde do režimu offline a primární replika přejde do sekundární role. Při použití naslouchacího procesu DNN možná budete muset upravit aplikační připojovací řetězec, abyste zajistili, že se připojení při převzetí služeb při selhání přesměrují na novou primární repliku.
  • Otevřené transakce: Otevření transakcí proti databázi v zavření skupiny dostupnosti při selhání a vrácení zpět a je nutné ručně znovu připojit. Například v aplikaci SQL Server Management Studio zavřete okno dotazu a otevřete nový.

Klientské ovladače

V případě ovladačů ODBC, OLEDB, ADO.NET, JDBC, PHP a Node.js musí uživatelé explicitně zadat název a port naslouchacího procesu DNN jako název serveru v připojovací řetězec. Pokud chcete zajistit rychlé připojení při převzetí služeb při selhání, přidejte MultiSubnetFailover=True do připojovací řetězec, pokud ho klient SQL podporuje.

Nástroje

Uživatelé aplikace SQL Server Management Studio, sqlcmd, Azure Data Studio a SQL Server Data Tools musí explicitně zadat název a port naslouchacího procesu DNN jako název serveru v připojovací řetězec pro připojení k naslouchacímu procesu.

Vytvoření naslouchacího procesu DNN prostřednictvím grafického uživatelského rozhraní SQL Server Management Studio (SSMS) se v současné době nepodporuje.

Skupiny dostupnosti a FCI

Skupinu dostupnosti AlwaysOn můžete nakonfigurovat pomocí instance clusteru s podporou převzetí služeb při selhání (FCI) jako jedné z replik. Aby tato konfigurace fungovala s naslouchacím procesem DNN, musí instance clusteru s podporou převzetí služeb při selhání používat také síť DNN, protože neexistuje způsob, jak umístit virtuální IP adresu FCI do seznamu IP adres skupiny dostupnosti.

V této konfiguraci musí adresa URL koncového bodu zrcadlení repliky FCI používat síť FCI DNN. Podobně platí, že pokud se služba FCI používá jako replika jen pro čtení, musí směrování jen pro čtení do repliky FCI používat síť FCI DNN.

Formát koncového bodu zrcadlení je: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Pokud je například název dnnlsnrDNS FCI DNN a 5022 je portem koncového bodu zrcadlení FCI, fragment kódu Transact-SQL (T-SQL) pro vytvoření adresy URL koncového bodu vypadá takto:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

Stejně tak formát adresy URL směrování jen pro čtení je: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Pokud je dnnlsnrnapříklad název DNS DNN a 1444 je port používaný cílovým sql Serverem jen pro čtení, fragment kódu T-SQL k vytvoření adresy URL směrování jen pro čtení vypadá takto:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Port v adrese URL můžete vynechat, pokud se jedná o výchozí port 1433. Pro pojmenovanou instanci nakonfigurujte statický port pro pojmenovanou instanci a zadejte ho v adrese URL směrování jen pro čtení.

Distribuovaná skupina dostupnosti

Pokud je naslouchací proces skupiny dostupnosti nakonfigurovaný pomocí názvu distribuované sítě (DNN), není konfigurace distribuované skupiny dostupnosti nad vaší skupinou dostupnosti podporovaná.

Replikace

Transakční, slučovací a snímková replikace podporují nahrazení naslouchacího procesu sítě VNN naslouchacím procesem A portem VNN v objektech replikace, které se připojují k naslouchacímu procesu.

Další informace o tom, jak používat replikaci se skupinami dostupnosti, naleznete v tématu Vydavatel a skupina dostupnosti, Odběratel a skupina dostupnosti a Distributor a skupina dostupnosti.

MSDTC

Místní i clusterovaný MSDTC se podporují, ale MSDTC používá dynamický port, který ke konfiguraci portu vysoké dostupnosti vyžaduje standardní Azure Load Balancer. Například buď virtuální počítač musí používat standardní rezervaci IP adres, nebo nemůže být vystavený na internetu.

Definujte dvě pravidla, jedno pro port mapovače koncového bodu RPC 135 a jedno pro skutečný port MSDTC. Po převzetí služeb při selhání upravte pravidlo nástroje pro vyrovnávání zatížení na nový port MSDTC po změně na novém uzlu.

Pokud je msDTC místní, nezapomeňte povolit odchozí komunikaci.

Distribuovaný dotaz

Distribuovaný dotaz spoléhá na odkazovaný server, který je možné nakonfigurovat pomocí naslouchacího procesu ANN skupiny dostupnosti a portu. Pokud port není 1433, zvolte při konfiguraci propojeného serveru možnost Použít jiný zdroj dat v aplikaci SQL Server Management Studio (SSMS).

FILESTREAM

FILESTREAM se podporuje, ale ne ve scénářích, ve kterých uživatelé přistupují ke sdílené složce s vymezeným oborem pomocí rozhraní FILE API systému Windows.

FileTable

FileTable se podporuje, ale ne ve scénářích, kdy uživatelé přistupují ke sdílené složce s vymezeným oborem pomocí rozhraní Windows File API.

Propojené servery

Nakonfigurujte propojený server pomocí názvu a portu naslouchacího procesu skupiny dostupnosti DNN. Pokud port není 1433, zvolte při konfiguraci propojeného serveru možnost Použít jiný zdroj dat v aplikaci SQL Server Management Studio (SSMS).

Nejčastější dotazy

Která verze SQL Serveru přináší podporu naslouchacího procesu skupiny dostupnosti DNN?

SQL Server 2019 CU 8 a novější

Jaká je očekávaná doba převzetí služeb při selhání při použití naslouchacího procesu DNN?

V případě naslouchacího procesu DNN je doba převzetí služeb při selhání stejná jako doba převzetí služeb při selhání skupiny dostupnosti bez dalšího času (například čas sondy, když používáte Azure Load Balancer).

Existuje nějaký požadavek na verzi, aby klienti SQL podporovali DNN s OLEDB a ODBC?

MultiSubnetFailover=True Doporučujeme připojovací řetězec podporu naslouchacího procesu DNN. Je k dispozici od SQL Serveru 2012 (11.x).

Vyžadují se nějaké změny konfigurace SQL Serveru pro použití naslouchacího procesu DNN?

SQL Server nevyžaduje žádnou změnu konfigurace pro použití sítě DNN, ale některé funkce SQL Serveru můžou vyžadovat další aspekty.

Podporuje síť DNN clustery s více podsítěmi?

Ano. Cluster sváže síť DNN v DNS s fyzickými IP adresami všech replik ve skupině dostupnosti bez ohledu na podsíť. Klient SQL zkouší všechny IP adresy názvu DNS bez ohledu na podsíť.

Podporuje naslouchací proces DNN skupiny dostupnosti směrování jen pro čtení?

Ano. Směrování jen pro čtení je podporováno u naslouchacího procesu DNN.

Související obsah