Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A következőkre vonatkozik:
SQL Server
Ez a cikk bemutatja, hogyan csatlakozhat az SQL Server Always On rendelkezésre állási csoport figyelőihez . A rendelkezésre állási csoport figyelője egy virtuális hálózat neve, amelyet az ügyfelek egy rendelkezésre állási csoportban üzemeltetett adatbázishoz való csatlakozáshoz használnak. A figyelő konzisztens kapcsolati végpontot biztosít az ügyfélalkalmazásokhoz, függetlenül attól, hogy jelenleg melyik rendelkezésre állási replika üzemelteti az elsődleges adatbázist. A figyelő lehetővé teszi a csak olvasható útvonaltervezés és az automatikus feladatátvétel támogatását is.
Miután konfigurálta a figyelőt, frissítse a kapcsolati sztringeket úgy, hogy a figyelőre mutasson, hogy az alkalmazásforgalom automatikusan a kívánt replikához legyen irányítva anélkül, hogy minden feladatátvétel után manuálisan frissítenie kellene a kapcsolati sztringet.
Csatlakozás az elsődleges replikához
Adja meg a rendelkezésre állási csoport figyelőjének DNS-nevét a kapcsolati sztringben az olvasási-írási hozzáférés elsődleges replikájához való csatlakozáshoz.
Ha például az SQL Server Management Studio elsődleges replikájához szeretne csatlakozni a figyelőn keresztül, írja be a figyelő DNS-nevét a kiszolgálónév mezőbe:
A feladatátvétel során, amikor az elsődleges replika megváltozik, a figyelő meglévő kapcsolatai megszakadnak, és az új kapcsolatok az új elsődleges replikához lesznek irányítva.
Példa egy egyszerű kapcsolati sztringre a ADO.NET szolgáltatóhoz (Microsoft.Data.SqlClient vagy System.Data.SqlClient):
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Megjegyzés:
Microsoft.Data.SqlClient az új alkalmazásfejlesztéshez ajánlott ADO.NET adatszolgáltató. Ugyanazokat a kapcsolati sztring-kulcsszavakat támogatja, mint a System.Data.SqlClient. További információ: Bevezetés a Microsoft.Data.SqlClient névtérbe.
A következő Transact-SQL (T-SQL) parancs futtatásával ellenőrizheti, hogy melyik replikához csatlakozik jelenleg a figyelőn keresztül:
SELECT @@SERVERNAME
Ha például az SQLVM1 az elsődleges replika:
Továbbra is csatlakozhat közvetlenül az SQL Server példányához az elsődleges vagy másodlagos replika példánynevével a rendelkezésre állási csoport figyelőjének használata helyett. Azonban így elveszítjük azt az előnyt, hogy az új kapcsolatok automatikusan a jelenlegi elsődleges replikához legyenek átirányítva. Emellett elveszíti az írásvédett útvonalak előnyeit, ahol a megadott read-intent kapcsolatok automatikusan az olvasható másodlagos replikára lesznek irányítva.
Csatlakozás egy írásvédett másolathoz
Az írásvédett útválasztás a bejövő figyelőkapcsolatok automatikus átirányítását jelenti egy olvasható másodlagos replikához, amely írásvédett számítási feladatok engedélyezésére van konfigurálva.
A rendszer automatikusan átirányítja a kapcsolatokat a csak olvasható replikára, ha az alábbiak teljesülnek:
Legalább egy másodlagos replika írásvédett hozzáférésre van beállítva, és minden írásvédett másodlagos replika és az elsődleges replika úgy van konfigurálva, hogy támogassa az írásvédett útválasztást.
A kapcsolati sztring a rendelkezésre állási csoportban érintett adatbázisra hivatkozik. Alternatíva lehet, ha a kapcsolatban használt felhasználói név alapértelmezett adatbázisaként van konfigurálva az adatbázis. További információkért tekintse meg ezt a cikket az algoritmus csak olvasható útválasztással való működéséről.
A kapcsolati sztring egy rendelkezésre állási csoport figyelőre hivatkozik, és a bejövő kapcsolat alkalmazás szándéka írásvédettre van állítva (például az Application Intent=ReadOnly kulcsszóval az ODBC- vagy OLEDB-kapcsolati sztringekben vagy kapcsolatattribútumokban vagy tulajdonságokban).
Az alkalmazás szándék attribútuma a bejelentkezés során az ügyfél munkamenetében lesz tárolva. Az SQL Server példánya feldolgozza a szándékot, és meghatározza, hogy mi a teendő a rendelkezésre állási csoport konfigurációja és a céladatbázis aktuális írási-olvasási állapota alapján a másodlagos replikában.
Ha például írásvédett replikához szeretne csatlakozni az SQL Server Management Studio használatával, válassza a Beállítások lehetőséget a Csatlakozás a kiszolgálóhoz párbeszédpanelen, válassza a További kapcsolati paraméterek lapot, majd adja meg ApplicationIntent=ReadOnly a szövegmezőben:
Példa egy kapcsolati sztringre az ADO.NET szolgáltató (Microsoft.Data.SqlClient vagy System.Data.SqlClient) számára, amely csak olvasási alkalmazási célt jelöl:
Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly
További információkért lásd: Írásvédett hozzáférés konfigurálása egy rendelkezésre állási replikában (SQL Server)
Nem alapértelmezett port
A figyelő létrehozásakor ki kell jelölnie egy portot a figyelő számára. Ha a port az 1433 alapértelmezett portja, akkor nem kell portszámot megadnia a figyelőhöz való csatlakozáskor. Ha azonban a port nem 1433, akkor a portot a kapcsolati sztringben a következő formátumban listenername,port kell megadni:
Példa egy kapcsolati sztringre az ADO.NET szolgáltató (Microsoft.Data.SqlClient vagy System.Data.SqlClient) számára, amely nem alapértelmezett portot ad meg a figyelő számára:
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Figyelők megkerülése
Bár a rendelkezésre állási csoport figyelői támogatják a feladatátvételi átirányítást és az írásvédett útválasztást, az ügyfélkapcsolatokra nincs szükség a használatukhoz. Az ügyfélkapcsolat közvetlenül hivatkozhat az SQL Server példányára a rendelkezésre állási csoport figyelője helyett.
Az SQL Server példánya számára nem számít, hogy egy kapcsolat bejelentkezik-e a rendelkezésre állási csoport figyelőjével vagy egy másik példányvégpont használatával. Az SQL Server példánya ellenőrzi a megcélzott adatbázis állapotát, és engedélyezi vagy letiltja a kapcsolatot a rendelkezésre állási csoport konfigurációja és a példányon lévő adatbázis aktuális állapota alapján. Ha például egy ügyfélalkalmazás közvetlenül csatlakozik az SQL Server-port egy példányához, és egy rendelkezésre állási csoportban üzemeltetett céladatbázishoz csatlakozik, és a céladatbázis elsődleges és online állapotban van, akkor a kapcsolat sikeres lesz. Ha a céladatbázis offline vagy átmeneti állapotban van, az adatbázishoz való kapcsolódás meghiúsul.
Alternatív megoldásként az adatbázis-tükrözésről Always On rendelkezésre állási csoportokra való migráláskor az alkalmazások megadhatják az adatbázis-tükrözési kapcsolati sztringet mindaddig, amíg csak egy másodlagos replika létezik, és nem engedélyezi a felhasználói kapcsolatokat.
Adatbázis tükrözés kapcsolat karakterláncok
Ha egy rendelkezésre állási csoport csak egy másodlagos replikával rendelkezik, és ALLOW_CONNECTIONS = READ_ONLY vagy ALLOW_CONNECTIONS = NONE értékekkel van konfigurálva a másodlagos replikához, az ügyfelek egy adatbázistükrözési kapcsolati sztring használatával csatlakozhatnak az elsődleges replikához. Ez a módszer akkor lehet hasznos, ha egy meglévő alkalmazást az adatbázis-tükrözésről egy rendelkezésre állási csoportra migrál, amíg a rendelkezésre állási csoportot két rendelkezésre állási replikára (elsődleges és egy másodlagos replikára) korlátozza. Ha további másodlagos replikákat ad hozzá, létre kell hoznia egy rendelkezésre állási csoport figyelőt a rendelkezésre állási csoporthoz, és frissítenie kell az alkalmazásokat, hogy a rendelkezésre állási csoport figyelő DNS-nevét használják.
Adatbázis-tükrözési kapcsolati sztringek használata esetén az ügyfél használhatja az SQL Server natív ügyfelet vagy a .NET-keretrendszer adatszolgáltatóját az SQL Serverhez. Az ügyfél által biztosított kapcsolati sztringnek minimálisan meg kell adnia egy kiszolgálópéldány nevét, a kezdeti partnernevet annak a kiszolgálópéldánynak a azonosításához, amely kezdetben a csatlakozni kívánt rendelkezésre állási replikát üzemelteti. A kapcsolati sztring megadhat egy másik kiszolgálópéldány nevét, a feladatátvételi partner nevét, hogy az eredetileg a másodlagos replikát üzemeltető kiszolgálópéldányt feladatátvételi partner névként azonosítsa.
Az adatbázis-tükrözési kapcsolati sztringekről további információt az Ügyfelek csatlakoztatása adatbázistükrözési munkamenethez (SQL Server) című témakörben talál.
Több alhálózatos átkapcsolás
Ha olyan ügyfélkódtárakat használ, amelyek támogatják a MultiSubnetFailover kapcsolati lehetőséget a kapcsolati sztringben, optimalizálhatja a rendelkezésre állási csoport feladatátvételét egy másik alhálózatra úgy, hogy a MultiSubnetFailovert "True" vagy "Yes" értékre állítja a használt szolgáltató szintaxisától függően.
Megjegyzés:
Ezt a beállítást a rendelkezésre állási csoportok figyelőivel és az SQL Server feladatátvevő fürtpéldánynevekkel való egy- és többalhálózatos kapcsolatok esetében egyaránt javasoljuk. Ennek a beállításnak az engedélyezése további optimalizálási lehetőségeket is biztosít, még az egy alhálózatos forgatókönyvek esetében is.
A MultiSubnetFailover kapcsolati lehetőség csak a TCP hálózati protokollal működik, és csak akkor támogatott, ha egy rendelkezésre állási csoport figyelőjével és az SQL Serverhez csatlakozó virtuális hálózatnévhez csatlakozik.
Példa a több alhálózatos feladatátvételt lehetővé tevő ADO.NET szolgáltatói (Microsoft.Data.SqlClient vagy System.Data.SqlClient) kapcsolati sztringre:
Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True
A MultiSubnetFailover kapcsolati beállítást igaz értékre kell állítani akkor is, ha a rendelkezésre állási csoport csak egyetlen alhálózatra terjed ki. Ezzel a beállítással előre konfigurálhatja az új ügyfeleket az alhálózatok jövőbeni átnyúlásának támogatásához anélkül, hogy szükség lesz az ügyfélkapcsolati sztring jövőbeli módosításaira, és optimalizálja a feladatátvételi teljesítményt az önálló alhálózati feladatátvételekhez. Bár a MultiSubnetFailover kapcsolati lehetőség nem szükséges, ez biztosítja a gyorsabb alhálózati feladatátvétel előnyeit. A klienstömeghajtó megkísérli megnyitni a TCP-csatlakozót a rendelkezésre állási csoporthoz társított egyes IP-címekhez párhuzamosan. Az ügyfélillesztő megvárja, amíg az első IP-cím sikeres választ ad, és ha igen, a kapcsolathoz használja.
Figyelők és TLS/SSL tanúsítványok
Rendelkezésre állási csoport figyelőhöz való csatlakozáskor, ha az SQL Server részt vevő példányai TLS-/SSL-tanúsítványokat használnak a munkamenet-titkosítással együtt, a csatlakozó ügyfélillesztőnek támogatnia kell a TLS/SSL-tanúsítvány tulajdonos alternatív nevét a titkosítás kényszerítéséhez.
Egy X.509 tanúsítványt kell konfigurálni a feladatátvevő fürt minden résztvevő kiszolgálócsomópontjára, és az összes elérhetőségi csoport hallgatójának listáját a tanúsítvány Subject Alternative Name mezőjében kell megadni.
A tanúsítványértékek formátuma a következő:
CN = Server.FQDN
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN
Például a következő értékekkel rendelkezik:
Servername: Win2019
Instance: SQL2019
AG: AG2019
Listener: Listener2019
Domain: contoso.com (which is also the FQDN)
Egyetlen rendelkezésre állási csoporttal rendelkező WSFC esetén a tanúsítványnak rendelkeznie kell a kiszolgáló teljes tartománynevével (FQDN) és a figyelő teljes tartománynevével:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com
Ezzel a konfigurációval a kapcsolat titkosítva lesz, amikor a példányhoz (WIN2019\SQL2019) vagy a figyelőhöz (Listener2019) csatlakozik.
A hálózatkezelés konfigurálásának módjától függően előfordulhat, hogy az ügyfelek egy kis része is hozzá kell adnia a NetBIOS-t a SAN-hoz. Ebben az esetben a tanúsítvány értékének a következőnek kell lennie:
CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com
Ha a WSFC három rendelkezésre állási csoport figyelőjével rendelkezik, például: Figyelő1, Figyelő2, Figyelő3
Ezután a tanúsítvány értékének a következőnek kell lennie:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com
Figyelők és Kerberos (SPN-ek)
Egy tartományi rendszergazdának konfigurálnia kell egy SPN-t az Active Directoryban minden rendelkezésre állási csoport figyelőjéhez, hogy engedélyezze a Kerberost a figyelőhöz való ügyfélkapcsolatokhoz. Az SPN regisztrálásakor a rendelkezésre állási replikát üzemeltető kiszolgálópéldány szolgáltatásfiókját kell használnia. Ahhoz, hogy az SPN az összes replikán működjön, ugyanazt a szolgáltatásfiókot kell használni a rendelkezésre állási csoportot üzemeltető WSFC-fürt minden egyes példányához.
A setspn Windows parancssori eszközével konfigurálja a szolgáltatásneveket. Például konfigurálhat egy SPN-t egy AG1listener.Adventure-Works.com nevű rendelkezésre állási csoport figyelőjéhez, amelyet egy SQL Server példánysorozat hostol, és amelyek a corp\svclogin2 tartományi fiók alatt futnak.
setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2
Az SQL Server egyszerű szolgáltatásneveinek manuális regisztrációjáról további információt a Kerberos-kapcsolatok egyszerű szolgáltatásnevének regisztrálása című témakörben talál.