MSCS: Quroum lässt sich nicht verschieben

[Kampfkorken 10]

Guten Morgen,

 

ich habe mir ein 2k3 Cluster mit zwei Nodes und einem DC in einer VmWare-Umgebung aufgebaut und habe Probleme mit der Verschiebung der physikalischen Datenträger im Cluster.

 

Meine Konfiguration sieht aus wie folgt:

 

3 Server, alle mit identischen Festplattenkonfigurationen.

 

DC:

C: Systemplatte (SCSI 0:0)

Q: Quorum (SCSI 1:1)

R: Datenplatte (SCSI 2:2)

 

Node1:

C: Systemplatte (SCSI 0:0)

Q: Quorum (SCSI 1:1)

R: Datenplatte (SCSI 2:2)

 

Node2:

C: Systemplatte (SCSI 0:0)

Q: Quorum (SCSI 1:1)

R: Datenplatte (SCSI 2:2)

 

Clustername: CLU1

Bestehend aus Node1 und Node2.

 

Ich habe zwei Clustergruppen die beide auf Node1 liegen. Einmal die initiale Clustergruppe, sowie die Gruppe die den SQL-Server und das Quorum hält.

Mein Problem ist nun, dass ich die Gruppen nicht moven kann. Die Gruppen werden kurz offline genommen, und gehen dann auf dem selben Node wieder online. Dabei kommt es im eventvwr zu folgendem Fehler:

 

--------------------------------------------------------------------------

Ereignistyp: Fehler

Ereignisquelle: ClusSvc

Ereigniskategorie: Ressource für physikalischen Datenträger

Ereigniskennung: 1034

Datum: 09.07.2010

Zeit: 08:27:55

Benutzer: Nicht zutreffend

Computer: NODE2

Beschreibung:

Der mit Clusterdatenträgerressource "Datenträger R:" verknüpfte Datenträger wurde nicht gefunden. Die erwartete Signatur des Datenträgers war "45D951C4". Falls der Datenträger aus dem Servercluster entfernt wurde, sollte die Ressource gelöscht werden. Falls der Datenträger ersetzt wurde, muss die Ressource gelöscht und neu erstellt werden, um den Datenträger online zu schalten. Falls der Datenträger noch nicht entfernt oder ersetzt wurde, ist er eventuell zurzeit nicht verfügbar, da er von einem anderen Servercluster- knoten verwendet wird.

 

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter Events and Errors Message Center: Basic Search.

--------------------------------------------------------------------------

 

Die gleiche Fehlermeldung kommt, wenn ich versuche das Quorum zu verschieben. Wenn ich eine zusätzliche Gruppe erstelle, die keinen Datenträger hält, kann ich problemlos moven. Die Prüfungen bei Erstellung des Clusters sind auch fehlerfrei durchgelaufen.

 

Zusätzlich ist mir aufgefallen, dass ich Node2 herunterfahren kann, und das Cluster weiterhin über die Cluster-IP erreichbar ist. Node2 wird dann auch korrekt als "Nicht erreichbar" im cluadmin angezeigt. Wenn ich allerdings Node1 herunterfahre, ist das Cluster nicht mehr erreichbar, sobald der Clusterdienst beendet ist. Wahrscheinlich, weil die Clustergruppen offline geschaltet werden und dann nicht mehr online gehen können... Macht ja Sinn :)

 

Die Server sind alle in der AD, und das Cluster läuft komplett über ein AD-Adminkonto.

 

Hat jemand einen Lösungsansatz für mich? Ich beiße mir langsam die Zähne aus.

 

 

Viele Grüße

Tom

[Lian 2.335]

Hallo,

 

was nutzt Du für ein Shared Storage System?

Ist R: Dein Quorum?

 

Das Quorum gehört in die initiale Cluster Gruppe zusammen mit der Cluster IP und dem Clusternamen.

Der Rest in eigene Applikationsgruppen.

 

Laufen die Gruppen jeweils auf beiden Knoten, wenn Du die einzelnen Nodes herunterfährst oder nur bei Node 1?

 

Folgenden Beitrag habe ich mal verfasst zum Troubleshooten des Quorum Drives:

Cluadmin.de: Troubleshooten des Quorum Drives

Dort ist auch Dein Event 1034 behandelt...

[Kampfkorken 10]

Hallo,

 

Q ist auf allen Servern das Quorum welches auch in der initialen Clustergruppe zusammen mit der Cluster-IP und dem Clusternamen liegt.

 

In der anderen Gruppe ist nur der Datenträger "Daten" auf dem der SQL-Server läuft und die einzelnen SQL-Resourcen.

 

Was das Verhalten angeht sieht es so aus:

 

- Beide Gruppen laufen auf Node1

- Fahre ich Node2 herunter, ändert sich nichts

- Fahre ich Node1 herunter, geht alles krachen, weil die Gruppen nicht geswitcht werden können.

 

Das ganze Spiel läuft wie gesagt in einer VM-Umgebung.

 

Ich habe den DC und die beiden Nodes jeweils mit 3 Platten (System, Quorum, Daten) ausgestattet und die Quorumplatte von Node1 bei der Installation des Clusters als "Quorum" deklariert.

 

Gruß

Tom

[Lian 2.335]

Welche VMWare Version?

Virtualisiert ist es inzwischen sinnvoller iSCSI zu nutzen.

 

Ansonsten kannst Du versuchen den Node zu entfernen und neu hinzuzufügen - wenn Du sicher bist, daß die Config der Shared Storage innerhalb von VMWare passt.

 

Zum Troubleshooten des Quorums siehe oben...

[Kampfkorken 10]

Ich nutze die Workstation 7.1.0 build-261024.

 

...wenn Du sicher bist, daß die Config der Shared Storage innerhalb von VMWare passt.

 

Ich schätze da liegt der Hund begraben. Innerhalb VM-Ware habe ich nicht konfiguriert. Nur auf den virtuellen Servern. Aber in der Workstation kann man doch was das angeht nicht wirklich viel machen, oder?

[Lian 2.335]

In früheren Versionen von VMWare Workstation war es kein Problem eine Shared Storage zu simulieren, das ist bei späteren Versionen herausgeflogen - aktuell verfolgt habe ich das nicht mehr...

 

Wie gesagt: Virtualisiert ist es inzwischen sinnvoller iSCSI zu nutzen:

Siehe: http://www.serverhowto.de/Teil-1-Vorbereitungen.503.0.html

Der Teil für die Config der Shared Storage via iSCSI sollte reichen

Die verwendete Virtualisierungssoftware spielt in dem Fall keine Rolle mehr.

[Kampfkorken 10]

Jetzt weiß ich auch wo mein Fehler lag... Peinlich, aber ich hatte die Platten jeweils lokal am Server angelegt.

iSCSI war mir bisher auch nicht wirklich bekannt.

 

Ich danke Dir vielmals :)

 

Gruß

Tom

[Lian 2.335]

Jetzt weiß ich auch wo mein Fehler lag... Peinlich, aber ich hatte die Platten jeweils lokal am Server angelegt.

Jup, das passt zum Fehlerbild

iSCSI war mir bisher auch nicht wirklich bekannt.

Ab 2008 ist für Clustering sowieso nur noch iSCSI, SAS oder Fibre Channel möglich, daher ist wie gesagt iSCSI das Mittel der Wahl für virtualisierte Cluster auf Workstations ;)

[Kampfkorken 10]

Das erklärt, warum ich es nicht kenne. Ich bin ausschließlich in der 2003er Welt unterwegs. Aber iSCSI klingt interessant. Ich werde mich damit mal genauer beschäftigen. Danke für den Hinweis :)