Új diszkek hozzáadása az SQL clusterhez

Diszket kellett bővíteni egy SQL clusterben, a lehető legkevesebb leállással, úgyhogy úgy döntöttem, hogy folytatom, amiben jó kezdek lenni: scriptelek. A cluster diszkek hozzáadása önmagában nem nagy szám (most felhördül legalább 28 ember, akinek már voltak rossz élményei a témában – nekem is, de a lekapcsolt többi node majdnem mindig dobott a dolgon), a jó rész az, hogy az SQL csak azokat a diszkeket használja, amiken dependál a service, a dependenciát pedig csak leállított helyzetben lehet állítgatni. Itt jön jól a script, hogy ne kelljen klikkelni, míg megöregszem. Ezúttal a cluster.exe volt a műtéti alany, az eredmény pedig alant látható (a sql12clus clustert megtámogatva):

cluster.exe sql12clus resource "SQL Server" /Offline 
cluster.exe sql12clus resource "SQL Server" /AddDependency:"K: BillingData"
cluster.exe sql12clus resource "SQL Server" /AddDependency:"L: BillingLog"
cluster.exe sql12clus resource "SQL Server" /Online

Azaz leállít, dependenciát hozzáad, elindít. Egy öröm volt.

SQL Server cluster security szigorítás how-not-to

Az SQL Server 2008 előtti változatai úgy installálódtak, hogy a lokális adminisztrátor csoport alapból be volt téve az SQL sysadmin role-ba. Időnként, főleg nagy cégeknél, ez nem kívánatos mellékhatásokkal jár, például olyan emberek és accountok kapnak automatikusan jogot az SQL-hez, akiknek semmi közük hozzá egyébként. Így történt, hogy egyszer régen, nagyon régen engem is utolért ez a feladat: válasszam le a Windows adminokat a SQL sysadminokról. Habár ez egy régi történet, többen azóta is emlegetik, úgy elcsesztem, úgyhogy a legutóbbi felhánytorgatáskor úgy döntöttem, megosztom a nagyérdeművel, tanuljatok az én hibámból.

Alapvetően egy éles rendszeren végzett változtatással álltam szemközt, úgyhogy a teszt SQL clusteren megcsináltam a változtatást, felírtam, hogy mit csináltam, és nekiálltam az éles rendszernek is. A feladat mindössze annyi volt, hogy a kivett BUILTIN\Administrators helyett be kellett raknom a DOMAIN\MyTeam csoportot sa-nak, és kész. Hogyan lehet ilyet letesztelni? Mivel clusterről beszélünk, én végigbillentem a SQL-t az összes node-ra, hogy lássam, hogy mindenhol el tud indulni rendesen az új beállításokkal, illetve tudok is hozzá kapcsolódni (ez utóbbira sqlcmd-t használok). Ha az OS-t piszkálom, akkor node reboot után megy ugyanez. Éles négy node-os cluster esetén ez kissé időigényes, és a fél perc helyett négy perc szolgáltatáskiesést okoz, de esküszöm, hogy megéri.

Szóval megcsináltam a változtatást az éles rendszeren is, megnéztem, minden működött, mindenki be tudott lépni, úgyhogy le is zártam az ügyet, és foglalkoztam a többi dologgal. Aztán egy pár hét múlva éjféltájban felhívott az ügyeletesünk, hogy a fent említett cluster nem indul el. Kérdeztem, hogy mi a tünet, és azt mondta, hogy felhívták azzal, hogy piros a monitor, megnézte, a cluster admin szerint el volt dőlve a szolgáltatás, megpróbálta újraindítani, el is indult minden egy időre, aztán egy-két perc után megint elfrakkolt, ezt eljátszotta párszor, azóta meg failed állapotban van. Rutinos üzemeltetőként végigpörgött a fejemben, hogy mi mindent csináltunk a szerverrel az elmúlt időben, és a tünetek alapján rögtön tudtam, hogy mi a baj. Azért megkértem ,hogy nézze meg az errorlogot, amire elmondta az azóta híressé vált mondatot: „valami júzer be akar jelentkezni itt, és nem sikerül neki – de ez most mindegy, amíg nem fut a cluster rendesen”.

Itt egy kicsit röhögtem, és elmondtam neki, hogy a valami júzer a cluster service-t futtató account, és úgy működik a dolog, hogy a cluster service elindítja a clusterezett resource-okat, így például az SQL Server service-t, és pollozza őket, hogy működnek-e. Az SQL Server pollozása pedig úgy néz ki, hogy belogol a cluster service account, és időnként egy select @@servername query-t bedob. Ha ez sikerül, örül, ha nem, akkor egy megadott idő (default 180 másodperc, ha jól rémlik így a vonaton) után betegnek nyilvánítja a SQL Server service-t, és megállítja. Kiderült, hogy egy korábbi bohóckodás miatt a teszt clusteren már hozzá volt adva a cluster service külön SQL accountként, úgyhogy ott nem is volt semmi hiba. Az élesen csak az ütött be, amikor leterhelték a clustert, és megállt a SQL, majd el akart megint indulni, addig ugyanis nem próbált meg belogolni újra a cluster service account, így nem zavarta, hogy dobtam (vagyis droptam) a loginját. Amikor újraindult a SQL, kiválóan működött minden – 180 másodpercig, amikor is a sok hiábavaló próbálkozás után a cluster service betegnek nyilvánította az egyébként makkegészséges szervert, és lelőtte. A baj az volt, hogy megfelelő számú próbálkozás után már el sem jutottunk odáig, hogy elinduljon a SQL és beléphessünk megjavítani. Úgyhogy jött mindenki barátja, a single user mód: sqlservr -c -m, amiben sqlcmd-vel belépve kiválóan meg lehetett pákázni. Ilyenkor persze a SQL tényleg a cluster node-on fut, nem virtual serverként, tehát nem úgy lehet hozzá csatlakozni, mint máskor, hanem (local) vagy . vagy hosztnév. Gyorsan csak ennyit mondtunk:

create login ’DOMAIN\_clusterserviceuser’ from windows

Figyelembe véve, hogy ő a szerver nevén kívül nem kérdez semmit, nagyon boldog a public role-lal, nem kell neki több jog. El is indult, örültünk is.

Tanulságok:

  • A teszt és éles rendszereket szinkronban kell tartani.
  • A változtatások után mindig meg kell győződni arról, hogy mindent életben hagytunk: újraindítani az érintett service-eket, stb.

SQL 2005 Failover Cluster és az el nem induló SQL Agent

Installáltam egy clustert, és a konfiguráció közben egyszer csak azt vettem észre, hogy az SQL Agent nem akar elindulni. Örömöm nem ismert határokat, elkezdtem túrni az agent logját (SQLAGENT.OUT, gyári alapbeállításként az errorloggal egy könyvtárban lakik), és megállapítottam, hogy igazából már az utolsó három restartnál nem indult el, csak én nem néztem a cluadminban, hogy mi milyen színű, és csak SSMS-t, sőt néha csak SQLCMD-t használtam (reprodukálható konfiguráció készítése volt a cél, ott meg a GUI nem játszik nagyon). Szóval megállapítottam, hogy SP3-mal még ment, SP3 CU4-gyel már nem, a kettő közt meg nemtom mikor tört el, a CU installjánál vagy később. Mindegy, emlékeztem még fiatalabb koromból, hogy olyan esetekben, amikor nem lehet a (local) szerverhez csatlakozni, valami registrykulcsba be kell tolni a szerver nevét, hogy ne így nézzen ki az SQLAGENT.OUT:

2008-01-10 20:57:15 - ! [298] SQLServer Error: 10061, TCP Provider: No connection could be made because the target machine actively refused it. [SQLSTATE 08001]
2008-01-10 20:57:15 - ! [165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00]
2008-01-10 20:57:15 - ! [298] SQLServer Error: 10061, An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. [SQLSTATE 08001]
2008-01-10 20:57:15 - ! [000] Unable to connect to server '(local)'; SQLServerAgent cannot start
2008-01-10 20:57:46 - ! [298] SQLServer Error: 10061, TCP Provider: No connection could be made because the target machine actively refused it. [SQLSTATE 08001]
2008-01-10 20:57:46 - ! [165] ODBC Error: 0, Login timeout expired [SQLSTATE HYT00]
2008-01-10 20:57:46 - ! [298] SQLServer Error: 10061, An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. [SQLSTATE 08001]
2008-01-10 20:57:46 - ! [382] Logon to server '(local)' failed (DisableAgentXPs)
2008-01-10 20:57:46 - ? [098] SQLServerAgent terminated (normally)

Megjegyzem, ugyanezt Named Pipes-szal is tudja, a kérdés az SQL kliens protocol order.

Szóval tényleg létezik a kulcs a HKLM/Software/Microsoft/Microsoft SQL Server/[instancename]/SQLServerAgent/ServerHost helyen, alapból üres, de be lehet állítani szépen a nevét a szervernek. Cluster esetében praktikus mindkét node-on ezt megtenni.

Lassú cluster failover és network name online pending

(For English version, read this) Elnézést, megvadultam, és elsőre angolul írtam meg ezt a postot, csak most fordul le magyarra.

Szóval kaptam egy kész Microsoft failover clustert, hogy megépítsem rá az SQL clusteremet, és a tesztelés során azt vettem észre, hogy botrányosan lassna billen át a cluster, másfél-két percig is eltart, az idő nagy részében pedig a network name-re várunk, ami online pending állapotban van vagy másfél percig. Némi molyolás után megállapítottam, hogy csak a network name a problémás, ha levittem offline-ba és visszahoztam rögtön ugyanazon a node-on, az is ugyanolyan sokáig tartott. Némi guglizás után találtam még egy csomó embert ugyanilyen problémával, de megoldást igazából nem. Végül kikötöttem egy Exchange 2007 W2K8-on poston, ami segített megtalálni a problémát, ami majd kiverte a szememet. Logikusan végiggondolva rá is jöhettem volna, de persze megint túldimenzionáltam ezt a kutya közönséges problémát, csak azért, mert egy komolyabb környezetben jött elő. Szóval az tartott másfél percig, hogy a hálózati kapcsolat beállításainál a DNS fülön be volt kapcsolva a Register this connection’s addresses in DNS opció, szegény szerver meg mindig nekiugrott a DNS szervernek, aki ignorálta a regisztrációs próbálkozásait. Erre ő elég lassan jött rá, és nem tanult az esetből, legközelebb megint megpróbálta. Kikapcsoltam, láss csodát: egy másodperc alatt felhozta a network name-et. Hepiend és kiváló alkalom volt megint az alázat gyakorlására.

Apropó cluster: a cluster ír egy kedves kis logot a C:\Windows\Cluster\cluster.log fájlba, néha hasznos lehet.

Slow cluster failover waiting for network name in online pending state

After getting a new Microsoft failover cluster, I found during the failover tests that the network name failed over horribly slowly. Otherwise everything was fine, but a complete SQL cluster failover took more than a minute and it was all because the network name remained online pending for ages. After some googling I didn’t find any specific solution, but I found a blog post about Exchange 2007 on Windows 2008 which put me into the right direction (that is, answered my question in a sentence) and gave the “I should have thought of this earlier” feeling (which helps me to exercise humbleness).

The sentence is the following:

In previous versions of Windows Cluster Server, every time a Network Name came online, it would register with DNS.

So I just checked my network settings and found that the Register this connection’s addresses in DNS checkbox was ticked. I cleared it and made a few tests: the network name came online in a second or less.

And I hate all the forums outside because you can’t just answer other’s question, you have to register (your login is already in use/too long/too short/contains invalid character/not complex enough/blocked by the swearword filter – and your password is way worse ) – and you get the confirmation mail the next day. So I left a few guys unanswered, but I hope Google will pick up this post so it’ll help on others.