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.

amd dual-core / quad-core bug and SQL Server

The AMD multicore CPUs have an interesting feature: the timers of the cores are not synchronized. This is the so-called clock-drifting which can be accountable for a lot of unexpected phenomenons due to the fact that the cores have different times and processes using multiple cores can be badly surprised. During the last year I had the chance to collect a few of the tricks:

  • Negative round-trip time during ping (Windows 2003)
  • Excessive amount of events in SQL Server errorlog (W2K3, SQL 2K5)
  • find -mtime 0 won’t find the recently created files (Red Hat EL 3)

Given that this is a mostly-SQL blog, I’m going to detail the second one. You can see events like this in the errorlog:

Date 11/25/2008 9:57:47 AM
Log SQL Server (Current – 11/25/2008 12:49:00 PM)

Source Server

Message The time stamp counter of CPU on scheduler id 3 is not synchronized with other CPUs.

And you can see this quite frequently. Now AMD created a fix for the bug but its target audience is not the big tribe of the sysadmins but the desktops. Why do you need a quad-core for a desktop user? Exactly: for gaming. So the fix called AMD Dual-Core Optimizer Version 1.1.4 gives you a chance to minimize the clock drifting by enabling the Game Mode. I gave it a try and installed it onto the server. Unfortunately the issue didn’t disappear, but it dropped by 97% which is a pretty good result – at least for me.

The idea sounds a bit wacky: fix an enterprise production database server with a gamer hotfix, but:

  1. It does the job
  2. If the Spanish MSFT support team could afford it, then I could as well :)

AMD dual/quad core bug és SQL

(English version here)
A több core-os AMD CPU-kba annak idején egy kiváló bug került: a core-ok órája nem volt rendesen összeszinkronizálva, és ez mindenféle érdekes dolgot eredményezhetett. 2008 számomra ezen bugok töredékének felfedezéséről (is) szólt. A következőket sikerült begyűjtenem:

  1. Ping esetén negatív round-trip time.
  2. SQL Servernél tonna hiba az errorlogba
  3. A legfrissebb: find használatakor az mtime 0-val nem találja meg a még friss fájlokat (ez mondjuk egy RedHat-on ütött be, bocs az offtopicért, de ez szebb, mint a másik kettő).

Engem az SQL Serveres érdekelt leginkább. Ez konkrétan így néz ki az errorlogban:

Date 11/25/2008 9:57:47 AM
Log SQL Server (Current – 11/25/2008 12:49:00 PM)

Source Server

Message The time stamp counter of CPU on scheduler id 3 is not synchronized with other CPUs.

Az AMD csinált egy hotfixet a bugra, de alapvetően ők nem szervert, hanem desktopot akartak javítani. Miért kell egy desktopba dual-core? Leginkább játszani (bár a GTA4 már quad-core-t akar, két magon szaggat :). Ennek megfelelően a csoda hotfixben, melynek neve AMD Dual-Core Optimizer Version 1.1.4 a clock driftinget a Gaming Mode bekapcsolásával lehet minimalizálni. Sajnos teljesen nem javította meg a problémát, de harmincad részére csökkentette az előfordulását.
Az ötlet amúgy elég hülyén hangzik, hogy gamer patch-csel javítsak élesüzemű SQL-t, de ha a spanyol MSFT SQL support team megtehette, akkor én is :)

Az SQL Integrated authentication és a szigorú policy

(For English version, check here)

Már sokan találkoztak azzal a kellemetlen élménnyel, hogy amikor az SQL szerverhez SQL authenticationnel próbálnak csatlakozni, akkor az SQL azt mondja, hogy “Login failed for user ‘(null)’. Reason: Not associated with a trusted SQL Server connection”. Ennek a legtipikusabb oka az, hogy nincs beállítva a szerveren az SQL authentication, és nem mixed mode-ban van konfigurálva. Ezt általában elég könnyű kivédeni: az ember átpöttyinti a rádiógombot, aztán hadd szóljon.
Múltkoriban találkoztam a hibaüzenettel, egészen más körülmények között. Pár embernek nem működött a Windows integrated authentication egy bizonyos szerverre. Ugyanúgy a fenti hibaüzenetet kapták. Másoknak hiba nélkül működött. Elkezdtem agyalni, hogy mi lehet a hiba: első jelöltem az MTU volt, de mivel a tokenméret azonos volt (sőt, azoknak volt nagyobb, akiknek működött), el kellett vetnem ezt az ötletet. Aztán megnéztem, hogy tudnak-e csatlakozni pl. egy share-hez az adott gépen. Ez nem sikerült nekik. Megnéztem az eventlogot, és ezt láttam benne:

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 534
Date: 8/3/2008
Time: 3:04:30 PM
User: NT AUTHORITY\SYSTEM
Computer: SQL10
Description:
Logon Failure:
Reason: The user has not been granted the requested
logon type at this machine
User Name: erik
Domain: MYDOMAIN
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: ERIKPC

De ez meg mi? Megkérdeztem Gugli barátomat, aki azt mondta, hogy olvasott már róla… És azt írja az újság, hogy ez bizony network logon failure. Ekkor úgy döntöttem, hogy megnézem a local security policyt. Megnéztem, és azt láttam, hogy az Access this computer from the network csak a lokáladminoknak van engedélyezve. Itt egy kicsit vertem a fejemet a falba, hogy miért nem fedeztem fel előbb ezt a mintázatot, de azért gyorsan beállítottam, hogy a Users is elérje, és befrissítettem a policyt. És működött.
Annyi történt, hogy mivel a parasztok userek nem voltak felhatalmazva, hogy elérjék a gépet hálózaton át, amikor csatlakoztak a géphez, az oprendszer kiröhögte őket, majd összetépte és kidobta a tokenjüket, így az SQL Serverhez már semmi nem jutott el a személyazonosságukból. Megint tanultam valamit.