Jump to content

ClusterProblem (DAG) nach Veeam Backup


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Moin zusammen und erstmal ein frohes neues Jahr an alle :) 

 

Folgendes Problem:

 

Ich hab eine Exchange 2013 DAG (2 Server 3 DBs) die soweit auch gut läuft. Das einzige was regelmäßig auftritt sind Fehler direkt nach dem Backup, das ganze ist aufgefallen weil die Logs nicht gelöscht wurden. Das nicht löschen konnte ich inzwischen durch folgende Kommandos aus einem Artikel in der KB von Veeam beheben: 

 

https://www.veeam.com/kb1744

 

Adjust Microsoft settings for failover sensitivity (in bold, run from command line):

  1. cluster /prop SameSubnetDelay=2000:DWORD (Default: 1000)
  2. cluster /prop CrossSubnetDelay=4000:DWORD (Default: 1000)
  3. cluster /prop CrossSubnetThreshold=10:DWORD (Default: 5)
  4. cluster /prop SameSubnetThreshold=10:DWORD (Default: 5)
  5. To check settings, use: cluster /prop

Was nun noch als Fehler bleibt ist direkt nachdem die Logs gelöscht werden sind folgende Fehler: 

 

Event 4087 Source MSExchangeRepl

Die aktive Datenbank 'Mailbox Database 2' konnte nicht vom Server 'Servername' verschoben werden. Verschiebekommentar: Keine Angabe.
 
Fehler: Fehler beim Ausführen eines Clustervorgangs. Fehler: Fehler für Cluster-API: "Fehler von ClusterRegSetValue() mit 0x6be. Fehler: Der Remoteprozeduraufruf ist fehlgeschlagen"
 
Wenn ich dann unter System schaue fällt sofort auf das kurz vor dem löschen der Logs folgender Fehler noch auftritt:
 
Event ID: 1564 Source: FailoverClustering Kritisch
 
Die Dateifreigabe-Zeugenressource "File Share Witness (\\FQDN\EXCH13-DAG.domain.local)" konnte nicht für die Dateifreigabe "\\FQDN\EXCH13-DAG.domain.local" vermitteln. Stellen Sie sicher, dass die Dateifreigabe "\\FQDN\EXCH13-DAG.Domain.local" vorhanden ist und dass der Cluster darauf zugreifen kann.
 
gefolgt von: 
 
Event ID: 1069 Source: FailoverClustering   Fehler
 
Fehler in der Clusterressource "File Share Witness (\\FQDN\EXCH13-DAG.domain.local)" des Typs "File Share Witness" in der Clusterrolle "Clustergruppe".
 
Abhängig von den Fehlerrichtlinien für die Ressource und die Rolle wird vom Clusterdienst möglicherweise versucht, die Ressource auf diesem Knoten online zu schalten oder die Gruppe auf einen anderen Knoten des Clusters zu verschieben und die Ressource dann neu zu starten. Prüfen Sie den Ressourcen- und Gruppenzustand mit dem Failovercluster-Manager oder mit dem Windows PowerShell-Cmdlet "Get-ClusterResource".
 
Und Event ID: 7024 source: Service Control Manager Fehler
 
Der Dienst "Clusterdienst" wurde mit dem folgenden dienstspezifischen Fehler beendet: 
Ein Quorum von Clusterknoten war nicht vorhanden, um einen Cluster zu bilden.
 
Danach startet er den Clusterdient neu und alles ist gut keine Fehler....
 
Die eingesetzte Veeam Version ist 9.5 
 
 
Hat jemand einen ähnlichen Fehler schon mal beobachtet oder eine Idee wo es da hakt?
 
Viele Grüße 
 
Ralph

 


So eine Ergänzung noch, Ich habe das Backup gerade noch mal laufen lassen und genau beobachtet. In dem Moment am Ende des Backups wo Veeam schreibt Removing VM snapshot...ist der Server für ca 15 sek nicht erreichbar (Ping, RDP etc) dann verbindet er neu und es ist alles gut... 

 

Ist also wohl ein Fehler den Veeam verursacht :(

Link zu diesem Kommentar

Vermutungen bringen wenig. Lass den TO mal mit VMWare sprechen und dann sehen wir was die dazu sagen.

 

Ich zitiere mal von https://www.veeam.com/de/kb1681 aus #4:

 

Ursache

 

Während des Entfernens von Snapshots erzielen VMs deutlich niedrigere Gesamt-IOPS. Dies liegt zum einen an zusätzlichen Sperren auf dem VMFS-Storage aufgrund vermehrter Metadatenaktualisierungen und zum anderen an zusätzlichen IOPS-Lasten durch die Snapshot-Beseitigung an sich. Wenn die Last für Ihren Ziel-Storage bereits über 30 % bis 40 % IOPS beträgt (was bei einem stark genutzten SQL-/Exchange-Server nicht unüblich ist), dann erhöht der Vorgang zum Entfernen von Snapshots diesen Wert in den meisten Umgebungen schnell auf 80 % und mehr. Die meisten Storage-Arrays weisen beträchtliche Latenzzeiten auf, sobald der IOPS-Wert jenseits der 80 % liegt, wodurch sich natürlich die Anwendungsleistung verschlechtert.

 

Dennoch möchte ich den TO natürlich nicht daran hinder mit VMWare zu sprechen.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...