Alles zum Thema Windows Server sowie Windows IT Pro Themen — Q & A zu den Windows Server Versionen NT / 2000 / 2003 / 2003 R2 / 2008 / 2008 R2: Rollen, Features, Konfiguration, Troubleshooting
habe Schwierigkeiten den 2. frisch installierten 2k3 Cluster Knoten zum Cluster hinzuzufügen. Das liegt evtl. an den Shared Disks im SAN, die vom aktiven 1. Knoten im Cluster belegt sind und von dem 2. Knoten, der neu installiert wurde, als "Unbekannt" und "Nicht lesbar" markiert sind. In der Datenträgerverwaltung kann man diese SAN Disks auch nicht initialisieren. Folglich klappt auch nicht ein Hinzufügen zum Cluster, denn es kommen Meldungen, dass "gemeinsames Quorum nicht verwendet/gefunden werden kann" (800713de) und wenn man "Minimale Konfiguration" beim Cluster-Hinzufügen wählt, dann geht er erstmal weiter, dann aber Error 0x800706be(Der Remoteprozeduraufruf ist fehlgeschlagen) beim Clusterdienst-Start.
Kann man die SAN Shared Disks irgendwie initialisieren, ohne dass produktive Daten dort verloren gehen? Oder muss man dafür den produktiven/aktiven Knoten erst herunterfahren, dann auf dem 2. Knoten darauf zugreifen/initialisieren?
Treiber, Firmware usw. sind alle aktuell und SAN-Konfig, Zoning usw. korrekt.
solange ein Knoten die Ressource des Physikalischen Datenträgers online hält, kann ein anderer Knoten nicht darauf zugreifen. Auf dem zweiten Knoten sieht man die Disk, kann aber erst nach einem Failover darauf zugreifen. Soweit die Theorie
An sich sollte man einen weiteren Knoten fehlerfrei hinzufügen können, spätestens bei der minimalen Konfiguration über Erweitert/Advanced.
Oder muss man dafür den produktiven/aktiven Knoten erst herunterfahren, dann auf dem 2. Knoten darauf zugreifen
Versuche das mal in einem Wartungsfenster.
Was steht da für eine SAN dahinter?
Ist das ein ganz neuer Knoten oder wurde dieser neu installiert? Falls letzteres: Konnte dieser zuvor schon einmal auf die Disks zugreifen?
solange ein Knoten die Ressource des Physikalischen Datenträgers online hält, kann ein anderer Knoten nicht darauf zugreifen. Auf dem zweiten Knoten sieht man die Disk, kann aber erst nach einem Failover darauf zugreifen. Soweit die Theorie
Das ist klar, dass der 2. Knoten nicht darauf zugreifen kann, solange der 1. Knoten online ist. Aber ich meine, in Datenträgerverwaltung muss shared Disk trotzdem nicht als "Unbekannt" und "Nicht lesbar" angezeigt werden(wie es jetzt ist). Früher - als der 2. Knoten lief, war das, glaube ich, anders.
Zitat von Lian
An sich sollte man einen weiteren Knoten fehlerfrei hinzufügen können, spätestens bei der minimalen Konfiguration über Erweitert/Advanced.
Eigentlich ja, geht aber nicht.
Zitat von Lian
Versuche das mal in einem Wartungsfenster.
Na ja, es ist nicht einfach - Exchange soll ja "immer" laufen! Evtl. am Wochenende erst. Und was dann genau tun - den 1. Knoten herunterfahren und versuchen die shared Disks auf dem 2. zu "initialisieren"? Oder müssen die Disks dann ganz normal im Zugriff sein? (wenn der Cluster neu eingerichtet wird, dann werden ja zuerst auf einem Knoten die Disks fertig konfiguriert, dann dieser ausgeschaltet und auf weiterem Knoten der Zugriff kontrolliert - soll das jetzt genau so laufen und ohne "Initialisieren", wobei die Signatur auf Disk geschrieben wird?)
Und danach den 1. Knoten wieder starten und im Cluster 2. Node hinzufügen?
Zitat von Lian
Was steht da für eine SAN dahinter?
HP EVA4000 mit 2 FC Switches(redundant/MultiPath), 2 FC HBA's in je. SAN Rechner. Zoning ist eingerichtet, beide Knoten in der selben Zone.
Zitat von Lian
Ist das ein ganz neuer Knoten oder wurde dieser neu installiert? Falls letzteres: Konnte dieser zuvor schon einmal auf die Disks zugreifen?
Das ist es ja: der alte Knoten wurde neu installiert, weil der auf einmal nicht mehr im Cluster wollte. Es war ein Exchange 2003 Cluster passive Node. Habe schon mal gepostet: "2K3 - w2k3 Cluster - Clusterdienst startet nicht" https://www.mcseboard.de/windows-for...et-151828.html
Es hat damals alles nichts gebracht, auch Backups einspielen. Deswegen habe den komplett neu installiert, alles vorher gelöscht, neu partitioniert usw.
Früher konnte der natürlich auf die Disks zugreifen, auch Failover hat schon mal darauf funktioniert. Bei SAN-Konfiguration hat sich nichts geändert, ein visueller Check hat bisher auch nichts gebracht.
Aber ich meine, in Datenträgerverwaltung muss shared Disk trotzdem nicht als "Unbekannt" und "Nicht lesbar" angezeigt werden(wie es jetzt ist). Früher - als der 2. Knoten lief, war das, glaube ich, anders.
Siehe Anhang, gerade von einem 2003'er Cluster erstellt mit Shared Storage
Na ja, es ist nicht einfach - Exchange soll ja "immer" laufen! Evtl. am Wochenende erst. Und was dann genau tun - den 1. Knoten herunterfahren und versuchen die shared Disks auf dem 2. zu "initialisieren"?
Nicht initialisieren, in der Datenträgerverwaltung "Datenträger neu einlesen" & "Aktualisieren". Solange der ClusDisk Treiber des 1. Node die Disk nicht mehr im Zugriff hält, kann der 2. Node diese korrekt einlesen und anzeigen - insofern das LUN Masking auf der SAN und FC Switch Zoning passt.
Wird Secure Path genutzt?
Es hat damals alles nichts gebracht, auch Backups einspielen. Deswegen habe den komplett neu installiert, alles vorher gelöscht, neu partitioniert usw.
Früher konnte der natürlich auf die Disks zugreifen, auch Failover hat schon mal darauf funktioniert. Bei SAN-Konfiguration hat sich nichts geändert, ein visueller Check hat bisher auch nichts gebracht.
Ich kann mich erinnern, was natürlich immer noch der Fall sein kann: ein Hardware Fehler (FC HBA, Pfade, Node, Switchport).
Siehe Anhang, gerade von einem 2003'er Cluster erstellt mit Shared Storage
Na dann bin ich jetzt beruhigt :-)
Zitat von Lian
Nicht initialisieren, in der Datenträgerverwaltung "Datenträger neu einlesen" & "Aktualisieren". Solange der ClusDisk Treiber des 1. Node die Disk nicht mehr im Zugriff hält, kann der 2. Node diese korrekt einlesen und anzeigen - insofern das LUN Masking auf der SAN und FC Switch Zoning passt.
Wird Secure Path genutzt?
OK, das dachte ich auch, ich probiere es bei der nächsten Gelegenheit aus.
SAN LUN Masking und FC Switch Zoning gerade nochmal kontrolliert - korrekt.
Mit "Secure Path" bin ich nicht sicher. Es wird "Multi-Path"(HP MPIO) genutzt.
Zitat von Lian
Ich kann mich erinnern, was natürlich immer noch der Fall sein kann: ein Hardware Fehler (FC HBA, Pfade, Node, Switchport).
Ok, wir suchen dann weiter wenn es mit dem Disk-Zugriff und Cluster ADD wieder nicht klappt.