Fehler beim Herstellen der Verbindung mit dem Cluster

[illuminaten 10]

Guten Morgen,

 

ich habe habe seit gestern das Problem, dass ein HyperV sich nicht mit dem Failovercluster-Manager mit dem Cluster verbindet.

Beim Versuch die Verbindung herzustellen bekomme ich die Meldung

 

Fehler beim Herstellen der Verbindung mit dem Cluster

Fehler beim Anzeigen der Clusterinformstionen

Mindestens ein Fehler ist aufgetreten

Zugriff verweigert (Ausnahme von HRESULT 0x80070005 (E_ACCESSDENIED)

 

Im Ereignisprotokoll werden keine Einträge generiert.

Könnte mir bitte jemand bei der Lösung des Problems behilflich sein.

Vielen Dank im Voraus

GRuß

 

 

 

 

[testperson 1.677]

Hi,

 

was ist denn vor dem Zeitpunkt "seit gestern" passiert / gemacht worden?

Was versuchst du da gerade wie (von wo) zu verbinden?

Welchen Status hat der HyperV Host im Failovercluster-Manager?

 

(Evtl. wäre der schnellste Weg, den Host aus dem Cluster zu nehmen, neu zu installieren und dann wieder ins Cluster zu integrieren.)

 

Gruß

Jan

[illuminaten 10]

Guten Morgen,

es wurde an der Konfiguration nichts geändert.

Nach einem Neustart des Server gabe es das Problem

 

Windows Server Clusterdienst startet nicht Der lokale Clusterknoten wurde von 'cluster nodes' unter Quarantäne gestellt

Diese konnte ich per Powershell Start-ClusterNode –ClearQuarantine

 

beheben.

 

Der Status des Host ist im Cluster-Manager Aktiv aktuelles Votum 0

 

Gruß

 

Hallo,

 

beim Prüfen der Cluster Konfiguration erhalte ich an dem Host die Meldung:

Sie verfügen auf dem Server"HV01-Cluster" nicht über Administratorenrechte

 

Gruß

[Sunny61 806]

Nicht aufgepasst. ;(

bearbeitet 2. Juli 2022 von Sunny61

[illuminaten 10]

hallo Sunny,

 

kannst du mir hier weiterhelfen?

[testperson 1.677]

Was spricht denn gegen

vor 9 Stunden schrieb testperson:

(Evtl. wäre der schnellste Weg, den Host aus dem Cluster zu nehmen, neu zu installieren und dann wieder ins Cluster zu integrieren.)

?

[mwiederkehr 373]

„Einfach neu machen“ halte ich für praktikabel, wenn der PC des Nachbarn „spinnt“, aber bei einem Cluster kenne ich gerne die Ursache eines Fehlers.

 

Neu gemacht ist der Host schnell, aber da man nicht weiss, was das Problem war, hätte ich zukünftig bei jedem Reboot eines Hosts in dem Cluster ein ungutes Gefühl.

[NilsK 2.934]

Moin,

 

Naja, in Wirklichkeit ist natürlich schon etwas getan worden, nur vermutlich nicht direkt vor dem Reboot. Der Neustart wird nur ausgelöst haben, was vorher schon System schlummerte. Also entweder denn einen Knoten neu machen in der (berechtigten) Hoffnung, dass er danach wieder ordentlich läuft. Oder vorher den langen Weg gehen und analysieren, was da nicht stimmt. Dazu sind die Ereignisprotokolle meist ein guter Start 

 

Gruß, Nils

 

[NorbertFe 2.034]

vor 8 Stunden schrieb mwiederkehr:

hätte ich zukünftig bei jedem Reboot eines Hosts in dem Cluster ein ungutes Gefühl.

Dafür hätte der to aber bis dahin erstmal wieder einen funktionierenden clusterknoten. ;)

[testperson 1.677]

vor 8 Stunden schrieb mwiederkehr:

„Einfach neu machen“ halte ich für praktikabel, wenn der PC des Nachbarn „spinnt“, aber bei einem Cluster kenne ich gerne die Ursache eines Fehlers.

 

Neu gemacht ist der Host schnell, aber da man nicht weiss, was das Problem war, hätte ich zukünftig bei jedem Reboot eines Hosts in dem Cluster ein ungutes Gefühl.

In viele Fällen wirst du (dann früher oder später) nicht an Tickets bei den Hardware Herstellern und Microsoft rum kommen. Und da wäre die Frage, ob eine Root Cause Analysis überhaupt in den Supportverträgen abgedeckt ist. Bei Microsoft gibt es die RCA AFAIK erst im Premier Support.

 

Des Weiteren wäre die Frage, ob man die ein, zwei Wochen (/ Monate) zur Analyse dann auf einen Knoten im Cluster verzichten kann / will.

 

Generell bin ich da allerdings komplett bei dir.

[Nobbyaushb 1.471]

Es gilt ja auch, wie viele Knoten der Cluster überhaupt hat.

Sind alle gleich, kann der Rest / die verbliebenen Knoten die VM von diesem Knoten fahren?

Über wieviel VM in Summe reden wir?

Auf den anderen Knoten tritt das Problem nicht auf?

Und am WE nach so einem Komplexen Problem sind nicht ganz viele Leute die kenne in der Lage, sowas zu analysieren und ggf. zu fixen.

Hatte auch schon mal ein aha-Erlebnis mit einem Cluster, wir haben den dann ganz neu gemacht 

[Sunny61 806]

Am 2.7.2022 um 12:37 schrieb illuminaten:

hallo Sunny,

 

kannst du mir hier weiterhelfen?

Ich hatte das hier übersehen:

[quote]

Diese konnte ich per Powershell Start-ClusterNode –ClearQuarantine

 

beheben.[/quote]

 

Grundsätzlich bin ich bei der Meinung der anderen Schreiber hier, neu machen falls es in den nächsten 2 Wochen nochmal auftritt.

[NorbertFe 2.034]

Ich häng mich mal kurz mit rein (erneut). @illuminatenGabs denn hier eine Lösung?

Neu installieren war bei mir keine Lösung, weil ich das Problem erst nach der Neuinstallation habe. ;) 2 von 3 Knoten können sich nicht mit per Failover Clustermanager verbinden. Auf dem 3. der noch nicht aktualisiert wurde läuft alles problemlos und ich kann auch VMs hin- und herschieben. Nur verwalten ist halt "b***d". :/

 

Jemand ne Idee?

 

Danke

Norbert

[testperson 1.677]

Neben den Hosts kannst du ja auch das Cluster neu aufsetzen: Upgrading Failover Clusters Using the Same Hardware | Microsoft Learn 

Damit müsstest du in deinem Fall AFAIK auch gleich auf Windows Server 2022 kommen.

[NorbertFe 2.034]

Ja, hab ich auch schon "überlegt", aber man knobelt eben etwas länger, wenn da paar 100 Leute drauf arbeiten. ;)