6
Verständnisfrage Datensicherung von VM auf iSCSI LUN
Guten Morgen,
ich hatte gestern ein sehr unangenehmes Erlebnis mit meinen vermeintlich fehlerfreien Backups, ich glaube aber die Ursache gefunden zu haben. Auch wenn ich die Sache noch nicht richtig verstehe habe ich eine grundsätzliche Frage. Auch weil ich in Kürze einen neuen Backup Server bekomme und endsprechend sinnvoll einbinden möchte.
Szenario
ESX-Hosts VMware vCenter 6.0
iSCSI SAN - Das Fabrikat erwähne ich bewusst nicht weil meine Frage eigentlich nur auf das iSCSI-Protokoll abzielt und ich vermute das der Hersteller keine Rolle spielt.
Datensicherungsserver mit Windows 2012 R2 und Veeam Backup & Replication 9.0
Es gibt ein Netzwerkinterface für das "reguläre" Netzwerk und eins für jedes iSCSI Netzwerk (verschiedene IP-Segmente). Die SAN ist im Windows iSCSI-Initiator hinterlegt, die SAN stellt dem Datensicherungsserver Zugriff auf die LUNs zur Verfügung. Da für jedes IP-Netz nur eine NIC vorhanden ist habe ich mich um MPIO nicht weiter gekümmert, da wurde nichts explizit eingestellt. In Veeam habe ich noch die "prefered networks" eingestellt, je IP-Netz die passende NIC.
Wenn ich jetzt ein Backup fahre weist Veaam den vCenter an einen Snapshot der VM zu erstellen. Die VM wird daraufhin gesichert. Sind die iSCSI-NICs des Sicherungsservers aktiv kommen die Daten darüber rein, sind sie nicht aktiv kommen sie über das "reguläre" Netzwerk zum Datensicherungsserver.
1) Die Daten fließen bei der SAN natürlich ab, wohin kann ich dort nicht nachvollziehen. Ich bin mir sicher, das der ESX die Daten ließt und der Sicherungsserver die Daten vom ESX bekommt, oder können die Datenpakete direkt von der SAN an den Datensicherungsserver zugestellt werden?
2) Wenn der ESX die Daten tatsächlich weiter leitet wie angenommen, habe ich dann einen Vorteil wenn ich den Datensicherungsserver direkt an iSCSI anbinde? Kann iSCSI zwischen ESX-Host und Sicherungsserver einen Geschwindigkeitsvorteil bringen oder kann ich in meiner Planung darauf gut verzichten?
(Derzeit gibt es im SAN eine MTU 9000, die bringt ein bischen was aber mal abgesehen davon?)
ich hatte gestern ein sehr unangenehmes Erlebnis mit meinen vermeintlich fehlerfreien Backups, ich glaube aber die Ursache gefunden zu haben. Auch wenn ich die Sache noch nicht richtig verstehe habe ich eine grundsätzliche Frage. Auch weil ich in Kürze einen neuen Backup Server bekomme und endsprechend sinnvoll einbinden möchte.
Szenario
ESX-Hosts VMware vCenter 6.0
iSCSI SAN - Das Fabrikat erwähne ich bewusst nicht weil meine Frage eigentlich nur auf das iSCSI-Protokoll abzielt und ich vermute das der Hersteller keine Rolle spielt.
Datensicherungsserver mit Windows 2012 R2 und Veeam Backup & Replication 9.0
Es gibt ein Netzwerkinterface für das "reguläre" Netzwerk und eins für jedes iSCSI Netzwerk (verschiedene IP-Segmente). Die SAN ist im Windows iSCSI-Initiator hinterlegt, die SAN stellt dem Datensicherungsserver Zugriff auf die LUNs zur Verfügung. Da für jedes IP-Netz nur eine NIC vorhanden ist habe ich mich um MPIO nicht weiter gekümmert, da wurde nichts explizit eingestellt. In Veeam habe ich noch die "prefered networks" eingestellt, je IP-Netz die passende NIC.
Wenn ich jetzt ein Backup fahre weist Veaam den vCenter an einen Snapshot der VM zu erstellen. Die VM wird daraufhin gesichert. Sind die iSCSI-NICs des Sicherungsservers aktiv kommen die Daten darüber rein, sind sie nicht aktiv kommen sie über das "reguläre" Netzwerk zum Datensicherungsserver.
1) Die Daten fließen bei der SAN natürlich ab, wohin kann ich dort nicht nachvollziehen. Ich bin mir sicher, das der ESX die Daten ließt und der Sicherungsserver die Daten vom ESX bekommt, oder können die Datenpakete direkt von der SAN an den Datensicherungsserver zugestellt werden?
2) Wenn der ESX die Daten tatsächlich weiter leitet wie angenommen, habe ich dann einen Vorteil wenn ich den Datensicherungsserver direkt an iSCSI anbinde? Kann iSCSI zwischen ESX-Host und Sicherungsserver einen Geschwindigkeitsvorteil bringen oder kann ich in meiner Planung darauf gut verzichten?
(Derzeit gibt es im SAN eine MTU 9000, die bringt ein bischen was aber mal abgesehen davon?)
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: 460082
Url: https://administrator.de/contentid/460082
Printed on: April 20, 2024 at 05:04 o'clock
6 Comments
Latest comment
Moin,
ich habe deinen Beitrag heute Morgen, heute Mittag und eben nochmals gelesen.
Gehts nur mir so, dass ich nicht verstehe was du von uns wissen möchtest?!
Gruß,
Dani
ich habe deinen Beitrag heute Morgen, heute Mittag und eben nochmals gelesen.
Gehts nur mir so, dass ich nicht verstehe was du von uns wissen möchtest?!
Gruß,
Dani
Hi,
nein Dani, es geht nicht nur dir so. Hab es auch mehrmals gelesen.
Aber ich denke mal die Backup-SW läuft über den ESXi zum Backup Server ab und nicht dass der Backup-Server per ISCSI auf die Storage zugreift.
Gruß
nein Dani, es geht nicht nur dir so. Hab es auch mehrmals gelesen.
Aber ich denke mal die Backup-SW läuft über den ESXi zum Backup Server ab und nicht dass der Backup-Server per ISCSI auf die Storage zugreift.
Gruß
Also klar ist der ESX macht den Snapshot. Dann müssen die Daten von der SAN zum Backupserver, auch klar.
a) Ist jetzt der ESX der Initiator und fragt über iSCSI beim Target das Datenpaket an, nimmt dieses entgegen und verschickt es per ??? an den Backupserver oder
b) ist der ESX der Initiator und fragt beim Target an kann aber als Zieladresse den Backupserver als "empfangender Initiator" angeben oder
c) ist der Backupserver direkt der Initiator und fragt direkt über iSCSI beim Target an?
Ich bin der Meinung es ist A, B klingt abwegig, C wäre auch noch möglich und auch sinnvoll. Wie arbeitet iSCSI und im speziellen was lößt Veeam bzw. VMware nach der Snapshot Erstellung aus?
a) Ist jetzt der ESX der Initiator und fragt über iSCSI beim Target das Datenpaket an, nimmt dieses entgegen und verschickt es per ??? an den Backupserver oder
b) ist der ESX der Initiator und fragt beim Target an kann aber als Zieladresse den Backupserver als "empfangender Initiator" angeben oder
c) ist der Backupserver direkt der Initiator und fragt direkt über iSCSI beim Target an?
Ich bin der Meinung es ist A, B klingt abwegig, C wäre auch noch möglich und auch sinnvoll. Wie arbeitet iSCSI und im speziellen was lößt Veeam bzw. VMware nach der Snapshot Erstellung aus?
Also RFC 3720 legt folgendes fest:
3.2.4.1. Command Connection Allegiance
For any iSCSI request issued over a TCP connection, the corresponding
response and/or other related PDU(s) MUST be sent over the same
connection. [...]
Thus, if an initiator issues a READ command, the target MUST send the
requested data, if any, followed by the status to the initiator over
the same TCP connection that was used to deliver the SCSI command [...]
Es kann also nicht der ESX Anfragen und die Antwort (Daten) geht an den Backupserver, das würde B ausschließen.
Dennoch habe ich keinen Plan was Veeam tut wenn der Snapshot erstellt wurde. Fragt es direkt (C) beim Target an oder ist (A) der ESX hier der Initiator und wie (Protokoll) kommen die Daten zum Backupserver? A geht auf jeden Fall denn mein Backupserver zieht seine Backups derzeit über das reguläre Netzwerkinterface. Es kann also nur vom ESX stammen.
Ob C auch geht kann ich nicht sagen, es kann auch sein das bei mir zuvor einfach eine andere TCP connection über die NICs im iSCSI-IP-Netz zwischen ESX und Backupserver aufgebaut wurde und der Backupserver nicht direkt von der SAN zieht. Mir ist das wie gesagt wichtig um meinen neuen Server sinnvoll zu verkabeln aber vor allem habe ich hier korrupte Backups wenn genau über diese Netzwerkverbindungen die Daten gezogen werden.
3.2.4.1. Command Connection Allegiance
For any iSCSI request issued over a TCP connection, the corresponding
response and/or other related PDU(s) MUST be sent over the same
connection. [...]
Thus, if an initiator issues a READ command, the target MUST send the
requested data, if any, followed by the status to the initiator over
the same TCP connection that was used to deliver the SCSI command [...]
Es kann also nicht der ESX Anfragen und die Antwort (Daten) geht an den Backupserver, das würde B ausschließen.
Dennoch habe ich keinen Plan was Veeam tut wenn der Snapshot erstellt wurde. Fragt es direkt (C) beim Target an oder ist (A) der ESX hier der Initiator und wie (Protokoll) kommen die Daten zum Backupserver? A geht auf jeden Fall denn mein Backupserver zieht seine Backups derzeit über das reguläre Netzwerkinterface. Es kann also nur vom ESX stammen.
Ob C auch geht kann ich nicht sagen, es kann auch sein das bei mir zuvor einfach eine andere TCP connection über die NICs im iSCSI-IP-Netz zwischen ESX und Backupserver aufgebaut wurde und der Backupserver nicht direkt von der SAN zieht. Mir ist das wie gesagt wichtig um meinen neuen Server sinnvoll zu verkabeln aber vor allem habe ich hier korrupte Backups wenn genau über diese Netzwerkverbindungen die Daten gezogen werden.
Hi,
die Kommunikation läuft normal über den ESXi und dein Backup spricht via LAN mit deinem ESXi.
Gruß
die Kommunikation läuft normal über den ESXi und dein Backup spricht via LAN mit deinem ESXi.
Gruß
Ich hab da noch etwas interessantes gelesen:
https://helpcenter.veeam.com/docs/backup/vsphere/direct_san_access.html? ...
Es scheint also auch direkt im SAN möglich zu sein aber ich kann noch nicht genau sagen was bei mir passiert ist außer das es über SAN gezogen wurde und das Dateisystem der VMs im Backup dabei Schaden genommen hat.
Da es derzeit über LAN fehlerfrei zu arbeiten scheint werde ich mich im Laufe der Woche nochmal in Ruhe mit dem Veeam Support in Verbindung setzen.
https://helpcenter.veeam.com/docs/backup/vsphere/direct_san_access.html? ...
Es scheint also auch direkt im SAN möglich zu sein aber ich kann noch nicht genau sagen was bei mir passiert ist außer das es über SAN gezogen wurde und das Dateisystem der VMs im Backup dabei Schaden genommen hat.
Da es derzeit über LAN fehlerfrei zu arbeiten scheint werde ich mich im Laufe der Woche nochmal in Ruhe mit dem Veeam Support in Verbindung setzen.
