Dedicated Admin Connection és a TCP port

A DAC-ról már írtam legalább kétszer, és említettem, hogy a DAC egy véletlenszerűen választott porton figyel. Na, ez természetesen így ebben a formában nem igaz, csak mérnöki szemlélettel egyszerűsítettem (a matematikusok szerint meg hazudtam).

Szóval a DAC portját a következőképpen találja ki az SQL Server: ha a default instance-ről van szó, akkor ő alapból a TCP 1434 portra akar ráülni, amennyiben az szabad (ezért lehet praktikus a TCP 1434-et nem odaadni named instance-nak). Ha nem szabad az a port, vagy named instance-ról van szó, akkor választ magának véletlenszerűen egy portot.

Ez persze felvet egy csomó kellemetlen problémát, mindenekelőtt azt, hogy honnan a francból fogom tudni, hogy hol a DAC. Erre a következő megoldások léteznek:

  • Elindítod az SQL Browser service-t, ami feltérképezi az adott oprendszeren futó összes SQL instance-ot, és kérdés esetén megmondja. Ez kényelmes, de én rühellem az SQL Browsert, mert szerintem van elég baj anélkül is, hogy egy beépített biztonsági rést használok.
  • Felolvasod az SQL Server errorlogjának az első pár tucat sorát, konkrétan a Dedicated admin connection support was established for listening locally on port XXXX. (PowerShell: Select-String “Dedicated admin connection support” [errorlog helye]) Direktben arra a portra kapcsolódsz, mintha csak egy SQL lenne ott (ideális esetben van is).
  • Keresel egy szabad portot, amit semmilyen alkalmazás nem bitorol. Ezt te lefoglalod a DAC részére, leírod, kiragasztod az ajtóra, stb. Majd megkéred a DAC-ot, hogy használja is azt a portot. Ezt ugyanis be lehet állítani a registryben, és akkor az SQL Server a 1434 helyett a registryben szereplő értéket fogja defaultnak tekinteni. A kulcs helye pedig a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib\AdminConnection\Tcp gombócban lakó TcpDynamicPorts érték (X= az instance-unk sorszáma). Ami alapból 1434.

Természetesen az egész bejegyzést az egy szem registry kulcsért írtam. Ez egyébként tűzfalas környezetben is nagy segítség lehet, mert jelentősen lehet növelni az esélyét annak, hogy elérjük a SQL-t DAC-on keresztül.

(a megoldás egy MS KB cikkből származik, de sajnos elég kereshetetlen, én célirányos kereséssel nem találtam meg fél óra alatt. Se bing, se gugli.)

DAC és SQL cluster

Igazából az előző postot a DAC-ról emiatt a kis szösszenet miatt írtam: ha van egy SQL clusterünk, akkor azon alapból nincsen DAC sehol sem, ezt tartsuk észben. Egy standalone SQL-nél alapból fut, csak belologunk az oprendszerbe, és már kapcsolódunk is, ha esetleg nem engedélyeztük volna a remote DAC-ot. Ilyenkor ugyanis a 127.0.0.1-es IP valamely portján figyel a DAC.

Egy clusternél viszont ez nyilvánvalóan nem működhet, ha végiggondoljuk a cluster concepcióját. Az SQL Server csak olyan erőforrásokat használhat, amiken dependál a service (közvetve vagy közvetlenül). Így például maga a SQL Server csak a cluster IP megadott portján tud figyelni, a cluster node-ok saját IP-jén vagy bármi egyében, beleértve a localhostot, nem igazán. Hát így történt. Ha clusterünk van, és akarunk DAC-ot használni, akkor muszáj engedélyeznünk a remote admin connectiont, aminek eredményeképpen a standalone gépen minden IP-n, a clustered instance-nál a cluster IP-n fog figyelni a DAC. Ajánlom mindenkinek, hogy kapcsolja be. Emlékeztetőül a bekapcs:

sp_configure 'remote admin connections', 1;
GO
RECONFIGURE;

Azonnal érvényre jut, lehet ellenőrizni az errorlogban, illetve kapcsolódni DAC-ra előtte-utána.

Dedicated Admin Connection röviden

SQL 2005-öt (vagy 2008-at) használsz? Olvastad az új fícsörök listáját? Akkor tudod, hogy van egy úgynevezett Dedicated Administrator Connection, barátok közt DAC, mely kiskapu egy üzemeltetőnek kínál hátsó bejáratot arra az esetre, ha valami rettenetes dolog történik, és egyébként már nem lehet belogolni se az SQL-be. Tipikus esetek lehetnek: valami durván kihajtja/széjjellockolja az SQL szervert vagy valaki elizélt logon triggereket alkalmaz, melyek nem tudnak lefutni, és így senki nem tud belogolni, még azért sem, hogy kikapcsolja a logon triggereket. Érezhető, hogy a klasszikus “újraindítom, az segíteni szokott” szemlélet az első két esetben segíthet (de soha nem tudod meg, hogy ki vágta haza a szervert és mivel), de az utóbbi esetben csak elodázza az elkerülhetetlent.

DAC-hoz való kapcsolódás alapból csak lokálisan engedélyezett, ez azért jó, mert ha kell a DAC, akkor nem kell azon agyalnod, hogy vajon ki használja az egy darab kapcsolatodat, csak valaki lokálisan lehet, azt meg könnyű kirúgni. Hogyan is működik a DAC? Az SQL Server indulásakor ő is elkezd figyelni egy porton, amit ő véletlenszerűen talál ki (sejtsük, hogy ez tűzfal mögül nem feltétlenül fog jól működni). Amikor hozzá akarunk csatlakozni, akkor a szerver neve elé be kell írnunk az admin: prefixet, azaz a SQL1 szerver DAC kapcsolatához az admin:SQL1 nevet kell megadnunk. Continue reading ‘Dedicated Admin Connection röviden’ »