Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
Ralph_S

ClusterProblem (DAG) nach Veeam Backup

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 :(

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

War auch schon meine Idee, aber das Backup vom Zeugen läuft 3 Std früher, und die Exchange Backups habe ich grade auch Manuell noch mal gemacht und da is mir das erst aufgefallen das beim entfernen des Veeam Snapshots der entsprechende Server kurz nicht erreichbar ist

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Danke erst mal für die Hilfestellungen, seh auch hier VM ware als verursacher zumal ich auch einige Beiträge im VM Ware forum gefunden habe die das selbe Problem haben. Ich lass das mal noch offen und wenn ich die Lösung habe schreib Ich Sie hier noch mit rein :) 

 

Grüße

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Was kann VMWare (oder Veeam) dafür, dass vermutlich dein Storage zu lahm ist?

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

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

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.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×