ClusterProblem (DAG) nach Veeam Backup

[Ralph_S 11]

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

[Reingucker 3]

Liegt der Zeuge in einer Freigabe auf dem Server der da gerade gesichert wird?

[Ralph_S 11]

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

[Reingucker 3]

Ja, sieht so aus als wenn Veem beim remove da nochmal ohne Rücksicht zulangt und alle Resourcen greift

 

https://www.veeam.com/de/kb1681

[Ralph_S 11]

Ich hab sowas befürchtet, weiß nur grad nicht soll ich nun lachen oder weinen aber ich entscheide mich fürs lachen das Jahr ist zu Jung zum weinen^^

[testperson 1.680]

Evtl. solltest du den Ressourcen-Engpass analysieren und beseitigen.

[djmaker 95]

Je nach Lizenz (Enterprise oder drüber) kannst Du eine Storage Latency einstellen beim Backup.

[Reingucker 3]

Ja, das macht dann wieder "Sinn". Allein über die Prio/Max-Einstellung für den Prozess bekommt man es ja nicht geregelt.

[Ralph_S 11]

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

[testperson 1.680]

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

[Dr.Melzer 191]

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.

[testperson 1.680]

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.

[Reingucker 3]

So wie es aussieht kann man in Veeam die Grundfunktionen für storage latency control auch ohne Enterprise Lizenz einstellen

 

http://blog.vmjoes.com/2015/04/veeam-backup-io-control-storage-latency.html

[Dr.Melzer 191]

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

 

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

Danke für den Link. :-) Warten wir mal was der TO bei VMWare erreicht.

[Reingucker 3]

Danke für den Link. :-) Warten wir mal was der TO bei VMWare erreicht.

 

Bitte, gern geschehen.