Clusterservicegroup neu anlegen
Steffen Seitz
wir haben aktuell das Phenomän das die eingerichtete "clustered
Service/Application Gruppe" ab und zu ohne eindeutige Fehler nach einem
Schwenk nicht mehr online kommt.
Aufbau:
2 W2k8 Ent. 64bit Nodes
1 clustered Servicegruppe (SQL 2005 Ent. 64bit)
- gemappte Resourcen: 3 iSCSI LUN´s
Wir können durch bereits durchgeführte Tests auschließen das es ein Problem
mit dem Storage und oder Abhänigkeiten sind.
Fehlermeldung bekommen wir bedauerlicherweise keine , die weiter verwertbar
wäre.
Wir sind aktuell am überlegen die "clustered Service Group" händisch neu zu
erzeugen und dort die nötigen Dienste wieder hinzuzufügen. Da ich aktuell
nirgends einen Hinweis darauf gefunden habe ob dies prinzipell so machbar ist
oder nicht frage ich hier einmal nach, da ich keine gutes gefühl bei habe das
machen zu wollen :)
Ich weiss das der SQL Server ursprünglichmal die aktuelle "clustered Service
group" erzeugt hat. Gibt es da irgendwie Probleme wenn man diese nun händisch
nachbauen würde ?!
danke vorab für eure comments
thanks and regards
Steffen
Bernd Pfann [MS]
news:351AC58F-18BD-46A4...@microsoft.com...
OK, wenn ich die Sache richtig verstanden habe kommt der Cluster selbst
immer online. Lediglich die Gruppe des SQL Servers tut dies nicht. Welche
Ressourcen bleiben den offline, bezw. im Status failed?
--
Mit freundlichen Grüßen / Kind regards - Bernd Pfann (Microsoft)
This posting is provided "AS IS" with no warranties, and confers no
rights.
Steffen Seitz
> immer online. Lediglich die Gruppe des SQL Servers tut dies nicht. Welche
> Ressourcen bleiben den offline, bezw. im Status failed?
Richtig nur die Servicegroup bleibt offline, die iSCSI Luns bleiben bleiben
offline. Es ist dann auch so das keine der Clusternode die Luns gemappt hat.
Das Problem lässt sioch meist damit beheben das wir eine Node komplett
booten ... was aber nicht Sinn und Zweck der Sache sein kann.
Regards
Steffen
Bernd Pfann [MS]
"Steffen Seitz" <Steffe...@discussions.microsoft.com> wrote in message
news:B6118819-C322-4610...@microsoft.com...
[...]
Wenn Du in den iSCSI Initiator reinschauen tust. Steht da dann reconnecting?
Nochmals damit ich es richtig verstehe, nach iSCSI LUNs sind ebenfalls
offline. Das würde natürlich erklären wieso alle anderen Resourcen dieser
Gruppe ebenfalls offline sind.
Wie macht Ihr den die iSCSI Connection? Dedizierter Adapter - auf einen
iSCSI Target (NetAPP, oder sonstwas)?
Steffen Seitz
> Wenn Du in den iSCSI Initiator reinschauen tust. Steht da dann reconnecting?
Das muss ich prüfen, was genau im iSCSI Initiator steht, kann ich aber
frühestens Morgen Nacht prüfen da wieder ein Wartungsfenster haben, um dann
wieder mal einen gezielten Schwenk zu machen.
> Nochmals damit ich es richtig verstehe, nach iSCSI LUNs sind ebenfalls
> offline.
Ja die LUNs werden als offline angezeigt.
>Das würde natürlich erklären wieso alle anderen Resourcen dieser
> Gruppe ebenfalls offline sind.
> Wie macht Ihr den die iSCSI Connection? Dedizierter Adapter - auf einen
> iSCSI Target (NetAPP, oder sonstwas)?
Die iSCSI Connection ist laufen über zwei deizierte Adapter (zwei
verschiedene Netze, wegen Ausfallsicherheit), auf ein Target (NetAPP) . Die
iSCSI Connections sind als Round Robin konfiguriert. Aktuell werden noch die
MS MPIO Treiber benutzt, diese planen wir mit denen von NetApp zu ersetzen.
Regards
Steffen
Bernd Pfann [MS]
Die Adapter sind aber nicht geteamt oder? Im iSCSI I/O Stack darf keine
Teaming Komponente sein.
Ein möglicher erster Schritt wäre eine Deaktivierung der TCP Offload
Mechanismem der iSCSI NICs und dann schauen ob das Problem auftritt. Das
machst Du direkt in den Properties der Karten selbst. Alternativ dazu noch
als 2ten Schritt die Deaktivierung im OS.
Steffen Seitz
> Teaming Komponente sein.
Nein die Adapter sind nicht geteamed.
> Ein möglicher erster Schritt wäre eine Deaktivierung der TCP Offload
> Mechanismem der iSCSI NICs und dann schauen ob das Problem auftritt. Das
> machst Du direkt in den Properties der Karten selbst. Alternativ dazu noch
> als 2ten Schritt die Deaktivierung im OS.
Das TCP Offload ist in den Karten und auch im OS deaktiviert.
Wir werden morgen zum Test noch eine "Clustered Servicegroup" nur mit einer
kleinen Testlun anlegen die wir dann auch ausserhalb der Wartungfenster
schwenken können, desweiteren werde wir schauen das wir noch die ein oder
andere Info aus der cluster.log rausbekommen.
Bin zwar um weitere Ideen froh und nehme diese auch weitere dankend an.
Regards
Steffen
Steffen Seitz
geführten Schwenks funktioniert hat, was auf der einen Seite beruhigend ist
aber dennoch nicht wirklich zur Lösung des Problems beträgt.
Wir haben inzwischen das Loglevel für "cluster log /level:10" eingestellt,
mal sehen was das noch so ans Tageslicht befördert. Hier mal noch eine Frage
dazu, gibt es irgendwo ne Anleitung was die Abkürzungen bedeuten und eine
kurze Einführung wie man das lesen soll ... denn aktuell muss ich sehr viel
rein interpretieren was ja net unbedingt das gelbe vom Ei ist :).
Ich kann gerne mal nen Auszug aus dem Testschwenk posten allerdings sind das
ein paar Zeilen (800) für den Schwenk unserer Testlun, sofern ich alle
relevanten rausgefischt habe.
thanks and regards
Steffen
Bernd Pfann [MS]
>> Die Adapter sind aber nicht geteamt oder? Im iSCSI I/O Stack darf keine
>> Teaming Komponente sein.
>
> Nein die Adapter sind nicht geteamed.
>
>> Ein möglicher erster Schritt wäre eine Deaktivierung der TCP Offload
>> Mechanismem der iSCSI NICs und dann schauen ob das Problem auftritt. Das
>> machst Du direkt in den Properties der Karten selbst. Alternativ dazu
>> noch
>> als 2ten Schritt die Deaktivierung im OS.
>
> Das TCP Offload ist in den Karten und auch im OS deaktiviert.
>
> Wir werden morgen zum Test noch eine "Clustered Servicegroup" nur mit
> einer
> kleinen Testlun anlegen die wir dann auch ausserhalb der Wartungfenster
> schwenken können, desweiteren werde wir schauen das wir noch die ein oder
> andere Info aus der cluster.log rausbekommen.
Eigentlich sind hier schon viele der Best Practices verwirklicht! Kann ich
das Cluster.log irgendwie bekommen?
Steffen Seitz
> Eigentlich sind hier schon viele der Best Practices verwirklicht! Kann ich
> das Cluster.log irgendwie bekommen?
ja kannst du, schau mal hier: http://as12337.net/steffens/
dort hab ich sowohl den Auszug (800 Zeilen) als auch das komplette Log (ca.
30k Zeilen) liegen.
thanks and regards
Steffen
Bernd Pfann [MS]
"Steffen Seitz" <Steffe...@discussions.microsoft.com> wrote in message
news:D3BFD164-4A53-421C...@microsoft.com...
[...]
Kannst Du das Log nochmals erstellen und dabei ganz am Ende das Loglevel auf
5 setzen:
cluster.exe ... /level:5
Das Log steht im moment auf 3.
Momentan sieht es so aus, als wenn der Cluster die Disk nicht richtig sieht:
000009ac.00002d38::2009/11/23-08:07:31.737 ERR [RES] Physical Disk: This
is a snapshot disk, SnapshotState: 1
000009ac.00002d38::2009/11/23-08:07:31.737 ERR [RES] Physical Disk: Disk
is not a cluster controllable disk, staus 5023
000009ac.00002d38::2009/11/23-08:07:31.738 INFO [RES] Physical Disk: Exit
EnumerateDevices: status 0
000009ac.00002d38::2009/11/23-08:07:31.769 WARN [RES] Physical Disk
<sql_test>: OnlineThread: Failed to get volume guid for device
\\?\GLOBALROOT\Device\Harddisk6\Partition2\. Error 3
-> 3 = The system cannot find the path specified
Läuft den auf dem Cluster die Validation ohne Fehler durch?
Ich habe im großen Log noch gesehen, dass die iSCSI Verbindungen für die
Verwendung des Clusters aktiviert sind. Du hast dazu ja noch das LAN und das
Cluster Network. Ich denke, dass über LAN der Public Zugriff und Cluster der
Heartbeat läuft (geraten :-) .
Was ist den hier für ein SQL Server drauf?
Ist den auf dem Cluster SP2 installiert, sonst auf jeden Fall den drauf
machen.
Um eine genauere Vorstellung zu bekommen wäre ein MPSReport nicht schlecht:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0#filelist
Dabei schauen, dass der Cluster mit integriert ist.
Steffen Seitz
> 5 setzen:
hab den command nochmal abgesetz, die Anzeige im Log selber bleibt auf: 3
habe dir mal noch die cluster /prop auf den webspace gelegt, darin ist zu
lesen das es auf Level 5 eingestellt ist.
>Momentan sieht es so aus, als wenn der Cluster die Disk nicht richtig sieht:
>000009ac.00002d38::2009/11/23-08:07:31.737 ERR [RES] Physical Disk: This
>is a snapshot disk, SnapshotState: 1
>000009ac.00002d38::2009/11/23-08:07:31.737 ERR [RES] Physical Disk: Disk
>is not a cluster controllable disk, staus 5023
>000009ac.00002d38::2009/11/23-08:07:31.738 INFO [RES] Physical Disk: Exit
>EnumerateDevices: status 0
>000009ac.00002d38::2009/11/23-08:07:31.769 WARN [RES] Physical Disk
><sql_test>: OnlineThread: Failed to get volume guid for device
>\\?\GLOBALROOT\Device\Harddisk6\Partition2\. Error 3
>-> 3 = The system cannot find the path specified
Die hier betroffene Luns ist unsere Testlun, allerdings kann ich auf diese
einwandfrei zugreifen, und auch drauf arbeiten.
Wenn ich dich richtig verstehe dann ist [RES] gleich Resource ?
> Läuft den auf dem Cluster die Validation ohne Fehler durch?
Die läuft durch, gibt halt die Warnings für die Laufwerke aus die in
Benutzung sind.
>Ich habe im großen Log noch gesehen, dass die iSCSI Verbindungen für die
>Verwendung des Clusters aktiviert sind. Du hast dazu ja noch das LAN und das
>Cluster Network. Ich denke, dass über LAN der Public Zugriff und Cluster der
>Heartbeat läuft (geraten :-) .
prinzipell richtig geraten, bis auf die ISCSI-Verbindungen, die
Netzwerkverbindung sind aktuell so konfiguriert:
LAN: Allow User, Allow Cluster
iSCSI1 & iSCSI2: Don´t use für Cluster
Cluster: Allow Cluster
> Was ist den hier für ein SQL Server drauf?
Microsoft SQL Server 2005 - 9.00.4053.00 (X64) May 26 2009 14:13:01
Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64-bit) on
Windows NT 6.0 (Build 6002: Service Pack 2)
> Ist den auf dem Cluster SP2 installiert, sonst auf jeden Fall den drauf machen.
Microsoft Windows [Version 6.0.6002] SP2
> Um eine genauere Vorstellung zu bekommen wäre ein MPSReport nicht schlecht:
> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cebf3c7c-7ca5-408f-88b7-f9c79b7306c0#filelist
> Dabei schauen, dass der Cluster mit integriert ist.
werd ich machen sobald ich wieder ein Wartungsfenster von Kunden habe, denn
auf der Maschine ist stellenweise einiges los... hoffe das ich das recht zeit
nach bekommen.
thanks and regards
Steffen
Steffen Seitz
ich melde mich endlich mal wieder bzg. dieses Themas. Es sah bis vor knapp
zwei Wochen so aus als wäre das Problem "Cluster Sevrice Group"
schwenkt nicht erledigt gewesen. Nun taucht das Problem wieder auf, und die
bisherigen Workarounds helfen nicht mehr.
Situation:
- Windows 2008 64bit Failovercluster mit 2 Nodes
- 1 Clusterservicegroup mit SQL 2005 Ent.
- 4 gemappte ISCSI-Luns via MS-MPIO Treiber angebunden
- 1 Clusterservicegroup mit einer Testlun
Nähere Info zur "SQL_DATA"-Disk:
- hier liegen die Userdatenbanken incl. der jeweiligen T-Logs
- Die ist aktuell mit ~ 400 GB belegt.
Zusammenfassung aus den vorherigen Posts:
Wir konnten mittels der Tipps von Bernd Pfann[MS] eingrenzen das der Cluster
eine der Disks nicht mehr findet.
Das Cluster - Eventlog zeigt hierzu:
[Quote]
Cluster physical disk resource 'SQL_DATA' cannot be brought online because the
associated disk could not be found. The expected signature of the disk
was 'B33CD07F'. If the disk was replaced or restored, in the Failover Cluster
Management snap-in, you can use the Repair function (in the properties sheet
for the disk) to repair the new or restored disk. If the disk will not be
replaced, delete the associated disk resource.
[/Quote]
Hier zu kann ich sagen es wurden keine Änderungen am Storage bzg. der Disks
durchgeführt. Die im Eventlog erwähnte Reparaturfunktion
ist ebenfalls nicht verfügbar.
Bisheriger Workaround:
Es war möglich die durch Entfernen und Hinzufügen der "Disk" zur Clustered
Service Group den Schwenk wieder zu initialisiern.
Da dies allerdings nicht der Verfügbarkeit zuträglich ist müssen wir bald
eine neue Lösung für die Problematik finden.
Hier nochmal zum einfachereren nachlesen die Config der Netzwerkverbindungen
des Clusters und die Version des eingesetzen SQL-Servers:
- LAN: Allow User, Allow Cluster
- iSCSI1 & iSCSI2: Don´t use für Cluster
- Cluster: Allow Cluster
- Microsoft SQL Server 2005 - 9.00.4053.00 (X64) May 26 2009 14:13:01
Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition (64-bit)
on
Windows NT 6.0 (Build 6002: Service Pack 2)
Bzg. der Bitte einen MPSReport auf der Maschine laufen zu lassen, kann ich
aktuell nur sagen das jeder Versuch darin scheitert das die uns die
Systempartition voll läuft
obwohl wir den Schalten /T nutzen um das Workingdirectory auf eine andere
Disk zu legen... deshalb kann ich hier mit aktuell noch nicht dienen, bin
aber auf der Suche warum sich der MPSReport so verhält... finde bisher aber
nichts.
Um auf das eigentliche Thema zurückzukommen, auf mich wirkt es so alls wäre
eine falsche Zuordnung in der "Clusterdatenbank" für die Disk "SQL_DATA".
Gibt es irgendwie eine Funktion wie man diese evtl. bereinigen kann oder
einzusehen?
thanks and regards
Steffen
Bernd Pfann [MS]
Durch das Entfernen und wieder einbinden der Disk wird diese für den Cluster
neu initialisiert. Wenn ich das nun richtig verstanden haben war danach der
Fehler weg! Ist er dann wieder gekommen?
>
> Hier nochmal zum einfachereren nachlesen die Config der
> Netzwerkverbindungen
> des Clusters und die Version des eingesetzen SQL-Servers:
> - LAN: Allow User, Allow Cluster
> - iSCSI1 & iSCSI2: Don´t use für Cluster
> - Cluster: Allow Cluster
Das passt soweit. Eine Frage hierzu - liegen iSCSI 1 und iSCSI 2 im selben
Subnet?
>
> - Microsoft SQL Server 2005 - 9.00.4053.00 (X64) May 26 2009 14:13:01
> Copyright (c) 1988-2005 Microsoft Corporation Enterprise Edition
> (64-bit)
> on
> Windows NT 6.0 (Build 6002: Service Pack 2)
>
> Bzg. der Bitte einen MPSReport auf der Maschine laufen zu lassen, kann ich
> aktuell nur sagen das jeder Versuch darin scheitert das die uns die
> Systempartition voll läuft
> obwohl wir den Schalten /T nutzen um das Workingdirectory auf eine andere
> Disk zu legen... deshalb kann ich hier mit aktuell noch nicht dienen, bin
> aber auf der Suche warum sich der MPSReport so verhält... finde bisher
> aber
> nichts.
Also bei mir funktioniert /t problemlos
mpsreports_x64.exe /t:d:\test
und in d:\test landen die temporären Dateien!
Kannst Du mal ein Clusterlog von Hand generieren?
cluster.exe /cluster:"clustername" log /gen /node:"nodename" /span:10
>
> Um auf das eigentliche Thema zurückzukommen, auf mich wirkt es so alls
> wäre
> eine falsche Zuordnung in der "Clusterdatenbank" für die Disk "SQL_DATA".
> Gibt es irgendwie eine Funktion wie man diese evtl. bereinigen kann oder
> einzusehen?
...
Ohne Report ist es schwer eine Diagnose zu wagen...
Steffen Seitz
>Durch das Entfernen und wieder einbinden der Disk wird diese für den Cluster
>neu initialisiert. Wenn ich das nun richtig verstanden haben war danach der
>Fehler weg! Ist er dann wieder gekommen?
ja der Fehler ist dann erst mal beseitig und der Cluster schenkt
einwandfrei.... nach einiger Zeit tritt der Effekt wieder auf.
>Das passt soweit. Eine Frage hierzu - liegen iSCSI 1 und iSCSI 2 im selben >Subnet?
Nein es handelt sich um zwei seperate /24 Netze
>Also bei mir funktioniert /t problemlos
>mpsreports_x64.exe /t:d:\test
>und in d:\test landen die temporären Dateien!
Ich werd das nochmal triggern und hoffe das sich der Report überzeugt zu
laufen...
>Kannst Du mal ein Clusterlog von Hand generieren?
>cluster.exe /cluster:"clustername" log /gen /node:"nodename" /span:10
Hab den genereiert und auf http://as12337.net/steffens/
>Ohne Report ist es schwer eine Diagnose zu wagen...
Klar ist das ohne Reportschwer, werde sauen das ich noch an diesen MPRS ran
kommen. Und werd dir dann mal zukommen lassen.
Thanks and Regards
Steffen
Bernd Pfann [MS]
Leider finden sich in den Logs keine eindeutigen Anhaltspunkte. Es werden
zwar einige male Zugriffprobleme auf LUNs gemeldet ... aber so richtig geben
die Meldungen nichts her.
Nochmals zu meine Verständnis:
Macht Ihr auf der NetApp auch SnapShots? Was geschieht mit diesen dann -
wurden diese mal den Cluster Knoten (für welche Zweck auch immer)
zugeordnet? Hat dieser also die selbe Disk 2x gesehen ... darauf könnten die
Einträge deuten.
Wie siehts mit den Reports aus - hat das hingehauen