12
SCSI IDs während des Backups verloren
Hallo zusammen,
wir haben seit ein paar Tagen ein Problem, bei dem wir alle möglichen Optionen (Neustart der beteiligten Systeme (sofern möglich), Update der Treiber/Firmware, Neueinrichten des Backup-Proxy, Überprüfung der Verkabelung,...) schon durchgespielt haben, aber leider in keinster Art Besserung eingetreten ist. Manche Sachen konnten wir (z.B. wegen fehlenden Ersatzteilen) noch nicht prüfen (z.B. anderer HBA).
Kurz zu dem, was bei uns hier genutzt wird, bei Fragen kann ich hier gerne ergänzen:
Veeam B&R (aktuelle Version) auf einem Windows Server 2019, auf einem DELL EMC R740
Storage: HPE 3par
Übertragung via FC
Das Problem zeigt sich folgendermaßen:
Für unseren diversen VMs haben wir natürlich (verschiedene) Backup-Jobs eingerichtet. Seit ein paar Tagen gibt es innerhalb der Jobs bei unterschiedlichen VMs (hier ist auch kein Muster erkennbar) immer das Problem, dass während des Jobs die SCSI ID der betreffenden LUN einfach "rausfliegt" und so die LUN für das Backup nicht mehr gefunden wird. Auf dem ganzen Weg von Storage bis Backupserver scheint alles zu funktionieren und es sind auch immer unterschiedliche LUNs, die dann nicht mehr gefunden werden.
Das Studium der Logs hat gezeigt, dass das auf dem Storage für das Backup erstellte Virtual Volume erstellt wurde und bekannt ist (auf dem Storage kann ich das auch bestätigen), im weiteren Verlauf wird dann versucht das VV zu mounten, es gibt über mehrere Minuten Rescans des FC Bus um Disk Infos vom Proxy zu erhalten, aber das scheitert dann. Daraufhin wird der Backup-Job für diese VM abgebrochen und auch alle weiteren VMs, die auf der Storage-LUN sitzen, bekommen kein Backup. Im retry des Jobs kann es dann passieren, dass alles mögliche doch ganz normal funktioniert.
Hat hier jemand grundsätzlich noch eine Idee an welcher Stellschraube man drehen kann um hier doch ein Ergebnis zu bekommen? Ich weiß, die Infos sind nicht super ausführlich, hier kann ich gerne nachliefern, falls noch was gewünscht ist. Aktuell sind wir für jeden weiteren Gedankenanstupser dankbar
Viele Grüße und vielen Dank im Vorfeld!
Marco
wir haben seit ein paar Tagen ein Problem, bei dem wir alle möglichen Optionen (Neustart der beteiligten Systeme (sofern möglich), Update der Treiber/Firmware, Neueinrichten des Backup-Proxy, Überprüfung der Verkabelung,...) schon durchgespielt haben, aber leider in keinster Art Besserung eingetreten ist. Manche Sachen konnten wir (z.B. wegen fehlenden Ersatzteilen) noch nicht prüfen (z.B. anderer HBA).
Kurz zu dem, was bei uns hier genutzt wird, bei Fragen kann ich hier gerne ergänzen:
Veeam B&R (aktuelle Version) auf einem Windows Server 2019, auf einem DELL EMC R740
Storage: HPE 3par
Übertragung via FC
Das Problem zeigt sich folgendermaßen:
Für unseren diversen VMs haben wir natürlich (verschiedene) Backup-Jobs eingerichtet. Seit ein paar Tagen gibt es innerhalb der Jobs bei unterschiedlichen VMs (hier ist auch kein Muster erkennbar) immer das Problem, dass während des Jobs die SCSI ID der betreffenden LUN einfach "rausfliegt" und so die LUN für das Backup nicht mehr gefunden wird. Auf dem ganzen Weg von Storage bis Backupserver scheint alles zu funktionieren und es sind auch immer unterschiedliche LUNs, die dann nicht mehr gefunden werden.
Das Studium der Logs hat gezeigt, dass das auf dem Storage für das Backup erstellte Virtual Volume erstellt wurde und bekannt ist (auf dem Storage kann ich das auch bestätigen), im weiteren Verlauf wird dann versucht das VV zu mounten, es gibt über mehrere Minuten Rescans des FC Bus um Disk Infos vom Proxy zu erhalten, aber das scheitert dann. Daraufhin wird der Backup-Job für diese VM abgebrochen und auch alle weiteren VMs, die auf der Storage-LUN sitzen, bekommen kein Backup. Im retry des Jobs kann es dann passieren, dass alles mögliche doch ganz normal funktioniert.
Hat hier jemand grundsätzlich noch eine Idee an welcher Stellschraube man drehen kann um hier doch ein Ergebnis zu bekommen? Ich weiß, die Infos sind nicht super ausführlich, hier kann ich gerne nachliefern, falls noch was gewünscht ist. Aktuell sind wir für jeden weiteren Gedankenanstupser dankbar
Viele Grüße und vielen Dank im Vorfeld!
Marco
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 32204745087
Url: https://administrator.de/contentid/32204745087
Printed on: May 4, 2024 at 11:05 o'clock
12 Comments
Latest comment
Das hört sich für mich an als ob das Storage selbst oder der Hostbus Adapter einen Schuss haben oder überlastet sind.
Defekte Sektoren o.ä.
Was sagt ein Healthcheck auf dem Storage?
Da es FC ist kann man Netzwerkprobleme wohl gänzlich ausschließen.
RaidScan oder wie das auch bei HP heißt.
Defekte Sektoren o.ä.
Was sagt ein Healthcheck auf dem Storage?
Da es FC ist kann man Netzwerkprobleme wohl gänzlich ausschließen.
RaidScan oder wie das auch bei HP heißt.
Zitat von @user217:
Das hört sich für mich an als ob das Storage selbst oder der Hostbus Adapter einen Schuss haben oder überlastet sind.
Defekte Sektoren o.ä.
Was sagt ein Healthcheck auf dem Storage?
Da es FC ist kann man Netzwerkprobleme wohl gänzlich ausschließen.
RaidScan oder wie das auch bei HP heißt.
Das hört sich für mich an als ob das Storage selbst oder der Hostbus Adapter einen Schuss haben oder überlastet sind.
Defekte Sektoren o.ä.
Was sagt ein Healthcheck auf dem Storage?
Da es FC ist kann man Netzwerkprobleme wohl gänzlich ausschließen.
RaidScan oder wie das auch bei HP heißt.
Das ist auch ein Stück weit unsere Vermutung... Der Storage selber meldet über den Healthcheck keine Auffälligkeiten (natürlich sind grad ein paar Platten ausgelastet, aber es passiert ja auch ein bisschen was
)Ein neuer HBA (baugleich) ist auch bestellt, eigentlich wegen etwas anderem, aber hier können wir, sobald der da ist dann den Check machen, ob der HBA nen Knack weg hat...
Das kann auch ganz banale Ursachen haben wie z.B. Vmware Tools update verursachten snapshot auf allen vms vergessen zu löschen..
Ich vermute es geht um ein Storage mit Spindeln und das hat schon immer getaugt aber die Maschinen werden immer mehr und irgendwann packt das ding nicht mehr io's. Der Hersteller gestaltet seine Graphen auf dem Storage natürlich meist so als das man nichts sieht oder es zumindest so aussieht als hätte das Storage noch kapa übrig - pustekuchen.
Das einzige was dich tatsächlich weiterbringt ist ein neues Storage einzubinden alles umzuziehen und das alte einmal initial platt machen, dannach sukzessive zurück gehen. Dann wirst du schon merken an was es liegt. An den HBA glaube ich nicht, eher an einen Stromausfall mit defekten sektoren von denen der HBA/RaidController nix mitbekommen hat, das hatte ich auch schon öfter.
Ich vermute es geht um ein Storage mit Spindeln und das hat schon immer getaugt aber die Maschinen werden immer mehr und irgendwann packt das ding nicht mehr io's. Der Hersteller gestaltet seine Graphen auf dem Storage natürlich meist so als das man nichts sieht oder es zumindest so aussieht als hätte das Storage noch kapa übrig - pustekuchen.
Das einzige was dich tatsächlich weiterbringt ist ein neues Storage einzubinden alles umzuziehen und das alte einmal initial platt machen, dannach sukzessive zurück gehen. Dann wirst du schon merken an was es liegt. An den HBA glaube ich nicht, eher an einen Stromausfall mit defekten sektoren von denen der HBA/RaidController nix mitbekommen hat, das hatte ich auch schon öfter.
VM-Snapshots glaube ich eher nicht, die würden wir im vCenter ja auch entsprechend sehen... Ein paar kleinere Probleme und Überbleibsel der "gewachsenen Struktur" haben wir auch schon aufgelöst, aber leider klappt das (auf Dauer) immer noch nicht 
Wenn ich das richtig lese, sichert ihr per Storage Snapshot? Und diese Snapshots gehen während der Sicherung verloren?
Wie sieht das in Veeam aus? Und was steht zeitgleich im Windows Event Log und auf der 3Par?
Wie sieht das in Veeam aus? Und was steht zeitgleich im Windows Event Log und auf der 3Par?
Ja, genau, per Storage Snapshot. Die VirtualVolumes auf der 3 Par sind soweit vorhanden, im Veeam gibts recht häufig nen Rescan des FC Bus (im Log), manchmal fängt er dann mit dem Backup an, manchmal bricht er dann ab... im Windows Log steht dann, dass er die SCSI ID {00000....} nicht finden kann...
Sind die Snapshots zu diesem Zeitpunkt noch auf der 3Par vorhanden? Und final welche Fehlermeldung gibt der Veeam Job aus?
Die Snapshots sind noch vorhanden auf dem Storage (auch wenn die VM schon fehlgeschlagen ist), werden dann erst beim Abschluss des gesamten Jobs bereinigt. Die Meldung bei im Veeam Job ist, dass der Proxy die Daten der VM-Festplatten nicht vom Storage abgreifen kann, weil er die LUN mit der entsprechenden ID nicht finden kann...
Dann sieht es so aus, als würde entweder das Exportieren auf Seiten der 3PAR nicht richtig klappen oder euer Server verliert die Verbindung zur LUN. Da könnte es dann einige Ursachen dafür geben. Eventuell prüft ihr ob die Snapshot Volumes auch richtig exportiert werden, also den korrekten WWN(s) eures Backupservers. Dann sollten auch alle Ports eures HBA funktionsfähig und richtig gezoned sein. Gegebenenfalls, falls vorhanden, geben die FC Switch Statistiken noch einen Hinweis.
Ansonsten würde ich euch einen Case bei HPE und Veeam empfehlen, damit sowohl die Hardware als auch die Konfiguration gesichtet wird.
Ansonsten würde ich euch einen Case bei HPE und Veeam empfehlen, damit sowohl die Hardware als auch die Konfiguration gesichtet wird.
Wenn es ISCSI wäre würde ich sagen das die MTU nicht passt, setzt das Ding neu auf sonst verbrennst du unnötig Zeit und weißt anschließend wieder nicht 100%ig was Sache ist.
Evtl. gibts auch FW Updates für die Platten, wäre mir zwar neu aber alles ist möglich.
Evtl. gibts auch FW Updates für die Platten, wäre mir zwar neu aber alles ist möglich.
Moin zusammen, das Problem besteht leider weiterhin... Was allerdings über das WE noch weiter aufgefallen ist: Auf einer LUN liegen mehrere VMs (sagen wir mal 10)... Und von fast allen VMs funktioniert alles auch einwandfrei, nur bei einer dann nicht... Interessanterweise ist es häufig die selbe VM, aber nicht immer... Nach mehreren Retries hat es dann auch funktioniert, dass wirklich von jeder VM der Snapshot genommen/gefunden wurde... Aber bei jedem Fehlschlag laufen wir in mehrere Timeouts (jeweils 15x30s pro LUN), was das ganze Unterfangen unnötig zeitaufwendig macht...
Den Support Case mit HPE und Veeam haben wir auch schon überlegt, wir warten noch einen Teileaustausch ab und dann gibt es da wenig Alternativen dazu...
Den Support Case mit HPE und Veeam haben wir auch schon überlegt, wir warten noch einen Teileaustausch ab und dann gibt es da wenig Alternativen dazu...
Bring die VMs in Sicherheit und mach das ding platt sonst läufst du gefahr anschließend ernsthafte probleme zu bekommen weil die Systeme nicht mehr integer laufen, ich spreche aus Erfahrung.
Ich musste 8 Wochen später nach sowas das AD restaurieren mit defekten Objekten, das macht gar keinen Spaß.
Ich musste 8 Wochen später nach sowas das AD restaurieren mit defekten Objekten, das macht gar keinen Spaß.
