NVP-vProxy: Backups schlagen fehl mit dem Code -404 "Aging out inactive session"

Die NVP-Integration (NetWorker VMware Protection) verwendet eine vProxy-Appliance, um VM-Backups durchzuführen. VM-Backups schlagen zeitweise mit der Meldung "Ressource nicht gefunden" in der NetWorker Management Console (NMC) fehl. Ein nachfolgender erneuter Backupversuch für dieselbe VM kann zwar erfolgreich sein, der Fehler kann jedoch Auswirkungen auf andere VMs im selben Backupzeitfenster haben. Der NMC zeigt den folgenden Fehler an (Sitzungs-ID variiert je nach Ereignis):

{"Text":"Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9","Code":-404}

Das Backupaktionsprotokoll zeigt die erfolglosen Versuche des NetWorker-Servers an, den Backupstatus vom vProxy abzurufen, gefolgt von dem Backupfehler:

MM/DD/YY HH:MM:SS [VM_NAME]: Unable to obtain backup status from vProxy after 5 attempts, failing the backup: Received an HTTP code: 404, libCURL message: "", vProxy message: "Error received from vProxy ="-404: Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9". ", url: "https://[VPROXY_NAME]:9090/api/v1/BackupVmSessions/44ab916f-7519-40f9-9d2e-e90394782ed9", body: " ".
MM/DD/YY HH:MM:SS [VM_NAME]: Unable to download vProxy Session log into file '/nsr/logs/policy/VMWare Protection/[WORKFLOW]/461300-[VM_NAME]-YYYY-MM-DD-HH-MM-SS.log': Possible wrong vProxy hostname or port, resource path not found. Received an HTTP code: 404, libCURL message: "", url: "https://[VPROXY_NAME]:9090/api/v1/BackupVmSessions/44ab916f-7519-40f9-9d2e-e90394782ed9/log".
MM/DD/YY HH:MM:SS [VM_NAME]: Backup failed.
MM/DD/YY HH:MM:SS The size of proxied data written has not been set.
MM/DD/YY HH:MM:SS Save-set ID '849786629' (client '[VCENTER_NAME]': save-set 'vm:50308677-bf8b-c786-0140-6a9c4409b90f:[VCENTER_NAME]') is aborted.

Der vProxy vbackupd-engine.log Zeigt den vollständigen Sitzungslebenszyklus an: Das Backup wird auf der vProxy-Seite erfolgreich abgeschlossen, aber die Sitzung wird anschließend veraltet und gelöscht, bevor der NetWorker-Server den Status abruft:

YYYY/MM/DD HH:MM:SS TRACE:  Ending go routine of main session loop for *resources.BackupVmSessions (vm-29424) [VM_NAME].
YYYY/MM/DD HH:MM:SS NOTICE: 44ab916f-7519-40f9-9d2e-e90394782ed9:vm-29424:[VM_NAME]: Backup session is exiting
YYYY/MM/DD HH:MM:SS TRACE:  Resource Update 44ab916f-7519-40f9-9d2e-e90394782ed9:externalId=[VCENTER_NAME]:vm-29424:state=Success:deletable=true.
YYYY/MM/DD HH:MM:SS INFO:   Saved resource map to "/opt/emc/vproxy/runtime/state/vbackupd/BackupVmSessions.gob".
YYYY/MM/DD HH:MM:SS NOTICE: Aging out inactive session BackupVmSessions - 44ab916f-7519-40f9-9d2e-e90394782ed9 ([VCENTER_NAME]:vm-29424) last accessed YYYY-MM-DD HH:MM:SS -0500 CDT.
YYYY/MM/DD HH:MM:SS TRACE:  Deleting logfiles of session '44ab916f-7519-40f9-9d2e-e90394782ed9'...
YYYY/MM/DD HH:MM:SS TRACE:  Deleting log file "/opt/emc/vproxy/runtime/logs/vbackupd/44ab916f-7519-40f9-9d2e-e90394782ed9.log" while deleting session "44ab916f-7519-40f9-9d2e-e90394782ed9"...
YYYY/MM/DD HH:MM:SS INFO:   File '/opt/emc/vproxy/runtime/logs/vbackupd/44ab916f-7519-40f9-9d2e-e90394782ed9.log' is moved to '/opt/emc/vproxy/runtime/logs/recycle/vbackupd/44ab916f-7519-40f9-9d2e-e90394782ed9.log'.
YYYY/MM/DD HH:MM:SS INFO:   Deleted log file "/opt/emc/vproxy/runtime/logs/vbackupd/44ab916f-7519-40f9-9d2e-e90394782ed9.log" while deleting session "44ab916f-7519-40f9-9d2e-e90394782ed9".
YYYY/MM/DD HH:MM:SS TRACE:  Deleting resource: [VCENTER_NAME]:vm-29424 - 44ab916f-7519-40f9-9d2e-e90394782ed9 ...
YYYY/MM/DD HH:MM:SS INFO:   Deleted resource: [VCENTER_NAME]:vm-29424 - 44ab916f-7519-40f9-9d2e-e90394782ed9.
YYYY/MM/DD HH:MM:SS INFO:   Saved resource map to "/opt/emc/vproxy/runtime/state/vbackupd/BackupVmSessions.gob".
YYYY/MM/DD HH:MM:SS INFO:   Aged out 1 'BackupVmSessions' sessions, 0 remaining
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS TRACE:  Handling Action GetLog for 44ab916f-7519-40f9-9d2e-e90394782ed9 ...
YYYY/MM/DD HH:MM:SS ERROR:  Resource not found: 44ab916f-7519-40f9-9d2e-e90394782ed9
YYYY/MM/DD HH:MM:SS TRACE:  Reply sent successfully for "GetLog".

Der NetWorker-Server fragt den vProxy kontinuierlich nach dem Status der Backupsitzung ab und fordert die Sitzungsprotokolle an, sobald das Backup abgeschlossen ist. Der vProxy schließt das Backup ab und altert die Sitzung, nachdem der NetWorker-Server einige Minuten lang keine Aktualisierung angefordert hat. Wenn die Sitzung altert, kann der vProxy dem NetWorker-Server keine Statusaktualisierung oder Protokolle mehr bereitstellen und schlägt mit der Meldung resource not found Fehler. Die Verzögerungen bei der NetWorker-Server-Statusanforderung sind in der Regel auf eine hohe Latenz zwischen dem NetWorker-Speicher-Node und der Data-Domain-Kommunikation zurückzuführen.

1. Messen Sie die Latenz zwischen Storage Node und Data Domain:
   • Führen Sie einen kontinuierlichen Ping-Vorgang mit Zeitstempel vom NetWorker-Speicher-Node zur Data Domain aus und geben Sie die Ergebnisse in einer Datei aus. Stellen Sie sicher, dass die Zeitzonen auf beiden Systemen übereinstimmen.
     • Windows: 

       ping -t [DATA_DOMAIN_IP] > ping_output.txt

     • Linux:

       ping [DATA_DOMAIN_IP] | while read line; do echo "$(date): $line"; done > ping_output.txt

   • Lassen Sie den Ping während eines Backupzeitfensters im Hintergrund.
   • Wenn der Backupfehler erneut auftritt, überprüfen Sie die ping_output.txt Datei und den dem Ausfall entsprechenden Zeitbereich auf Latenzspitzen.
2. Reduzieren Sie die Latenz auf unter 50 ms:
   • Identifizieren und beheben Sie die Quelle der hohen Latenz zwischen dem NetWorker-Speicher-Node und der Data Domain. Häufige Ursachen sind Netzwerküberlastung, WAN-Verbindungen, Routing-Ineffizienzen oder überlastete Netzwerkgeräte.
   • Stellen Sie sicher, dass die Roundtrip-Latenz zwischen dem NetWorker-Speicher-Node und Data Domain während der Backupausführung unter 50 ms bleibt. Dieser Schwellenwert ist im Abschnitt "Überlegungen zu TCP-Fenstergröße und Netzwerklatenz" im Dell NetWorker Performance Optimization Planning Guide dokumentiert.
3. Stellen Sie einen Remote-Storage-Node bereit (wenn die Latenz nicht reduziert werden kann):
   • Wenn die Latenzzeit zwischen Storage-Node und Data Domain nicht unter 50 ms reduziert werden kann (z. B. aufgrund geografischer Trennung), konfigurieren Sie einen NetWorker-Speicher-Node am Remotestandort, an dem sich die Data Domain befindet. Dieser Storage Node managt die Data-Domain-Geräte lokal, wodurch Pfad mit hoher Latenz eliminiert wird.
4. Überprüfen Sie die Lösung:
   • Nachdem Sie die Latenz reduziert oder einen Remote-Storage-Node bereitgestellt haben, lösen Sie Backupjobs für die zuvor betroffenen VMs aus.
   • Vergewissern Sie sich, dass die Backups erfolgreich abgeschlossen werden, ohne dass die Ressource nicht gefunden wurde (Code -404) in der NMC, im Backupaktionsprotokoll oder im vProxy-vbackupd-engine.log.
   • Überwachen Sie Backupjobs über drei aufeinanderfolgende Backupzeitfenster, um sicherzustellen, dass keine zeitweiligen Ausfälle mehr auftreten.
   • Wenn die Sitzungsalterungsfehler bestehen bleiben, nachdem die Latenz unter 50 ms reduziert wurde, wenden Sie sich an den Dell Support für weitere Untersuchungen und verweisen Sie auf diesen Wissensdatenbank-Artikel.

Im folgenden Artikel wird beschrieben, wie Sie eine Netzwerkfehlerbehebung durchführen: NetWorker: Anleitung zum Troubleshooting netzwerkbezogener Probleme.