Zum Inhalt wechseln


Foto

ClusterProblem (DAG) nach Veeam Backup


  • Bitte melde dich an um zu Antworten
14 Antworten in diesem Thema

#1 Ralph_S

Ralph_S

    Newbie

  • 126 Beiträge

 

Geschrieben 03. Januar 2017 - 09:41

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



#2 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 03. Januar 2017 - 09:50

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



#3 Ralph_S

Ralph_S

    Newbie

  • 126 Beiträge

 

Geschrieben 03. Januar 2017 - 10:07

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



#4 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 03. Januar 2017 - 13:42

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



#5 Ralph_S

Ralph_S

    Newbie

  • 126 Beiträge

 

Geschrieben 03. Januar 2017 - 15:54

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^^



#6 testperson

testperson

    Board Veteran

  • 4.602 Beiträge

 

Geschrieben 03. Januar 2017 - 15:59

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


Good morning, that's a nice TNETENNBA!

#7 djmaker

djmaker

    Board Veteran

  • 3.483 Beiträge

 

Geschrieben 04. Januar 2017 - 10:43

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


Thomas

K.Y.S.S. - Keep Your Signatur Short :)

#8 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 04. Januar 2017 - 10:59

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



#9 Ralph_S

Ralph_S

    Newbie

  • 126 Beiträge

 

Geschrieben 04. Januar 2017 - 13:39

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



#10 testperson

testperson

    Board Veteran

  • 4.602 Beiträge

 

Geschrieben 04. Januar 2017 - 13:55

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


Good morning, that's a nice TNETENNBA!

#11 Dr.Melzer

Dr.Melzer

    Moderator

  • 26.262 Beiträge

 

Geschrieben 04. Januar 2017 - 14:21

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.


Never argue with an idíot, they drag you down to their level and beat you with experience!

#12 testperson

testperson

    Board Veteran

  • 4.602 Beiträge

 

Geschrieben 04. Januar 2017 - 14:44

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.


Good morning, that's a nice TNETENNBA!

#13 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 04. Januar 2017 - 18:42

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

 

http://blog.vmjoes.c...ge-latency.html



#14 Dr.Melzer

Dr.Melzer

    Moderator

  • 26.262 Beiträge

 

Geschrieben 05. Januar 2017 - 11:12

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.


Never argue with an idíot, they drag you down to their level and beat you with experience!

#15 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 05. Januar 2017 - 23:00

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

 

Bitte, gern geschehen.