7
Tape Library an Hyper-V VM durchreichen
Hallo zusammen,
ich soll gerade ein Backup bzw. die Hardware dafür planen.
Genutzt wird Simpana Commvault 11.
Ich habe einen Host-Server (HP DL360, W2K16) mit Hyper-V. Hierauf läuft eine virtuelle Maschine (auch W2K16) auf der dann der Commvault Media Agent läuft.
Ich plane eine MSL2024 Library von HP zu kaufen. Die wird an den Host angeschlossen. Es ist allerdings nicht entschieden, ob SAS, SCSI oder FC.
Von SAS habe ich gelesen, dass ich das nicht wirklich (ohne größere Workarounds) an die VM durchreichen kann. Wie sieht das aus mit SCSI bzw. FC?
An sich bin ich in dem Thema etwas unerfahren.
Wie ist denn der cleverste (und supportete!) Weg um eine Tape Library an eine VM anzuschließen?
ich soll gerade ein Backup bzw. die Hardware dafür planen.
Genutzt wird Simpana Commvault 11.
Ich habe einen Host-Server (HP DL360, W2K16) mit Hyper-V. Hierauf läuft eine virtuelle Maschine (auch W2K16) auf der dann der Commvault Media Agent läuft.
Ich plane eine MSL2024 Library von HP zu kaufen. Die wird an den Host angeschlossen. Es ist allerdings nicht entschieden, ob SAS, SCSI oder FC.
Von SAS habe ich gelesen, dass ich das nicht wirklich (ohne größere Workarounds) an die VM durchreichen kann. Wie sieht das aus mit SCSI bzw. FC?
An sich bin ich in dem Thema etwas unerfahren.
Wie ist denn der cleverste (und supportete!) Weg um eine Tape Library an eine VM anzuschließen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 427791
Url: https://administrator.de/contentid/427791
Ausgedruckt am: 04.11.2024 um 22:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
ich würde dir von dem angesprochenen Konstrukt abraten.
Welche Generation ist denn der HPE Server?
Ich würde den Server „bare metall“ als Backup-Server einsetzen.
Laut deiner Schilderung ist das ja sowieso die einzigste VM, die darauf läuft.
Gruß
Maxblank
ich würde dir von dem angesprochenen Konstrukt abraten.
Welche Generation ist denn der HPE Server?
Ich würde den Server „bare metall“ als Backup-Server einsetzen.
Laut deiner Schilderung ist das ja sowieso die einzigste VM, die darauf läuft.
Gruß
Maxblank
1
Hallo,
Google ist Dein Freund:
https://www.thomas-krenn.com/de/wiki/Tandberg_Storageloader_oder_Bandlau ...
https://social.technet.microsoft.com/Forums/en-US/ea199f65-fc57-4970-a7e ...
Kernaussage: Microsoft Windows Hyper-V unterstützt kein passthrough von SAS / SCSI Geräten an eine VM
Jürgen
PS: Und grundsätzlich ist es keine "gute Lösung" den Backup-Server als VM zu realisieren, denn wenn der Host abschmiert, kann man nicht auf den Backup-Server zugreifen, um den Host und die VMs wieder herzustellen. Den Backup-Server also in "Blech" und dann hast du auch obiges Problem nicht.
Google ist Dein Freund:
https://www.thomas-krenn.com/de/wiki/Tandberg_Storageloader_oder_Bandlau ...
https://social.technet.microsoft.com/Forums/en-US/ea199f65-fc57-4970-a7e ...
Kernaussage: Microsoft Windows Hyper-V unterstützt kein passthrough von SAS / SCSI Geräten an eine VM
Jürgen
PS: Und grundsätzlich ist es keine "gute Lösung" den Backup-Server als VM zu realisieren, denn wenn der Host abschmiert, kann man nicht auf den Backup-Server zugreifen, um den Host und die VMs wieder herzustellen. Den Backup-Server also in "Blech" und dann hast du auch obiges Problem nicht.
2
Ich stimme meinen "Vorrednern" vollkommen zu!
Das wird nicht funktionieren!
Commvault kennt aber auch die Funktion eines "Backup-Proxy".
Dies bedeutet das du einen Server mit schnellem Plattenplatz und einem SAS Controller (FC wäre nur im Fall eines Backups direkt vom FC angebundenen Storage interessant) benötigst an dem Du die Library anschließen kannst.
Ich, denke ein DL325 würde hier absolut ausreichen...
https://www.youtube.com/watch?v=X0hLoZzlFr4
Du solltest in jedem Fall die Backups zuerst auf die Platten (Ich würde aus Performancegründen alle 8 Platten im RAID6 benutzen) abkegen und erst dann auf das Band sichern.
LTO Streamer benötigen einen konstant hohen, ununterbrochenen Datenstrom, um kontinuierlich und mit hoher Kompression sichern zu können.
Das wird nicht funktionieren!
Commvault kennt aber auch die Funktion eines "Backup-Proxy".
Dies bedeutet das du einen Server mit schnellem Plattenplatz und einem SAS Controller (FC wäre nur im Fall eines Backups direkt vom FC angebundenen Storage interessant) benötigst an dem Du die Library anschließen kannst.
Ich, denke ein DL325 würde hier absolut ausreichen...
https://www.youtube.com/watch?v=X0hLoZzlFr4
Du solltest in jedem Fall die Backups zuerst auf die Platten (Ich würde aus Performancegründen alle 8 Platten im RAID6 benutzen) abkegen und erst dann auf das Band sichern.
LTO Streamer benötigen einen konstant hohen, ununterbrochenen Datenstrom, um kontinuierlich und mit hoher Kompression sichern zu können.
1
Danke für Eure Antworten.
Das Problem ist tatsächlich, dass ich mich an konzernweite Standards halten muss.
Als Hardware kommt ein HP DL360 Gen 10 zum Einsatz. Und geplant die MSL2024. Beides ist bei uns als Standard definiert.
Normalerweise machen wir kein Tape-Backup an Standorten mehr, sondern erst to Disk und dann per MPLS an den Hauptstandort. Dort dann auf Tape. Speziell an diesem Außenstandort gibt es aber eine Ausnahme: Er ist 8500 Km weit weg und die Leitung(en) in diesem Land sind sehr wackelig. Wir werden also kein WAN-Backup machen können.
Und deshalb soll eine Library hin.
Klar, wenn ich das direkt auf dem Blech installiere habe ich das Problem nicht. Das ist auch die Notlösung, die ich machen werde. Aber gewünscht wäre eigentlich das soweit wie möglich an unsere sonstiges Standards zu haben. Und das ist eben eine (bis zwei) VMs für die Media Agents.
Das Problem ist tatsächlich, dass ich mich an konzernweite Standards halten muss.
Als Hardware kommt ein HP DL360 Gen 10 zum Einsatz. Und geplant die MSL2024. Beides ist bei uns als Standard definiert.
Normalerweise machen wir kein Tape-Backup an Standorten mehr, sondern erst to Disk und dann per MPLS an den Hauptstandort. Dort dann auf Tape. Speziell an diesem Außenstandort gibt es aber eine Ausnahme: Er ist 8500 Km weit weg und die Leitung(en) in diesem Land sind sehr wackelig. Wir werden also kein WAN-Backup machen können.
Und deshalb soll eine Library hin.
Klar, wenn ich das direkt auf dem Blech installiere habe ich das Problem nicht. Das ist auch die Notlösung, die ich machen werde. Aber gewünscht wäre eigentlich das soweit wie möglich an unsere sonstiges Standards zu haben. Und das ist eben eine (bis zwei) VMs für die Media Agents.
Moin.
Grundsätzlich ist diese Aussage schlicht falsch, je nach eingesetztem Produkt ist die Virtualisierung des Backup-Servers sogar empfohlen bzw. das einzig supportete Szenario. Und wenn der Host -also das "Blech"- ausfällt, steht dein Backup-Server, ob er nur direkt auf dem Host läuft oder virtuell. Virtuell hätte hier sogar den Vorteil, dass du den kompletten Server im Prinzip durch Copy&Paste (mit der ein oder anderen Anpassung) einfach auf ein neues Blech schiebst und weitermachst.
Cheers,
jsysde
Zitat von @chiefteddy:
[…]PS: Und grundsätzlich ist es keine "gute Lösung" den Backup-Server als VM zu realisieren, denn wenn der Host abschmiert, kann man nicht auf den Backup-Server zugreifen, um den Host und die VMs wieder herzustellen. Den Backup-Server also in "Blech" und dann hast du auch obiges Problem nicht.
[…]PS: Und grundsätzlich ist es keine "gute Lösung" den Backup-Server als VM zu realisieren, denn wenn der Host abschmiert, kann man nicht auf den Backup-Server zugreifen, um den Host und die VMs wieder herzustellen. Den Backup-Server also in "Blech" und dann hast du auch obiges Problem nicht.
Grundsätzlich ist diese Aussage schlicht falsch, je nach eingesetztem Produkt ist die Virtualisierung des Backup-Servers sogar empfohlen bzw. das einzig supportete Szenario. Und wenn der Host -also das "Blech"- ausfällt, steht dein Backup-Server, ob er nur direkt auf dem Host läuft oder virtuell. Virtuell hätte hier sogar den Vorteil, dass du den kompletten Server im Prinzip durch Copy&Paste (mit der ein oder anderen Anpassung) einfach auf ein neues Blech schiebst und weitermachst.
Cheers,
jsysde
1
Moin.
Und seither laufen nur noch die Inkremente über die WAN-Anbindung, was alles andere als schnell ist, aber zumindest funktioniert. Ich habe alle Daten vor Ort und am Hauptstandort und kann sie da problemlos auf Tape schieben. Hängt natürlich sehr von der Art der Daten ab und von deren Wachstum. Wenn innerhalb 24h mehr Daten hinzukommen, als im gleichen Zeitraum als Inkremente an den Hauptstandort geschoben werden können...
Was die eigentliche Frage angeht:
FCoE könnte klappen, sofern auf beiden Seiten korrekt implementiert.
Cheers,
jsysde
Zitat von @Twlght667:
[…]Er ist 8500 Km weit weg und die Leitung(en) in diesem Land sind sehr wackelig. Wir werden also kein WAN-Backup machen können.
Vor der Herausforderung stand ich auch, habe mich aber letztlich gegen eine Library vor Ort entschieden. Stattdessen Initial-Backup auf USB-Platte vor Ort gezogen und dann auf dem Backup-Server am Hauptstandort eingespielt. Der macht dann einmal einen Konsistenzcheck, was tatsächlich Tage gedauert hat und mehrfach abgebrochen ist, letztlich aber erfolgreich war. Vor Ort steht nur ein virtueller Backup-Server, der eben auf Disk sichert, um eine schnelle Wiederherstellung vor Ort zu gewährleisten.[…]Er ist 8500 Km weit weg und die Leitung(en) in diesem Land sind sehr wackelig. Wir werden also kein WAN-Backup machen können.
Und seither laufen nur noch die Inkremente über die WAN-Anbindung, was alles andere als schnell ist, aber zumindest funktioniert. Ich habe alle Daten vor Ort und am Hauptstandort und kann sie da problemlos auf Tape schieben. Hängt natürlich sehr von der Art der Daten ab und von deren Wachstum. Wenn innerhalb 24h mehr Daten hinzukommen, als im gleichen Zeitraum als Inkremente an den Hauptstandort geschoben werden können...
Was die eigentliche Frage angeht:
FCoE könnte klappen, sofern auf beiden Seiten korrekt implementiert.
Cheers,
jsysde
1
In diesem Fall bleibt eigentlich nichts anderes übrig, als die Library an den DL360 anzuschließen und den kompletten Hypervisor samt darauf laufenden VMs als Ganzes "abzuziehen"... Hierzu müsste allerdings Simpana als Applikation direkt auf dem Windows Server laufen und nicht in einer VM. (Okay: Böse! 
)
Ich weis, das dies nicht von Microsoft supportet wird, da die Konsistenz der laufenden VMs während des Backups nicht gewährleistet werden kann. Dies hängt aber ganz von den Möglichkeiten der Backup-Software ab.Simpana SOLLTE eigentlich das "snappen" laufender VMs beherrschen.
Falls nicht, würde es aber helfen, die VMs während des Backups per Script zu stoppen und danach wieder zu starten.
P.S.
Librarys sind, obwohl weitgehend automatisiert, nicht "wartungsfrei"! Daher würde ich in "Remote Branches" eher etwas "weniger mechanisches" einsetzen:
Für den Preis einer MSL2024 mit LTO7 Laufwerk bekommt manschon eine gut ausgestattete HPE StoreOnce.
Diese wird von Simpana voll als B2D Device unterstützt.
https://documentation.commvault.com/commvault/v11_sp13/article?p=99422.h ...
Großer Vorteil hierbei ist zudem, das man auf die SAS oder FC Verbindung verzichten kann. Das Backup läuft, dedupliziert und kompremiert, über das LAN. Durch die Deduplizierung sind auch Repliken der Backups über extrem wackelige und schmalbandige WANs möglich.
Vielleicht gibt es eine ähnliche Lösung bereits in eurem Konzern?!
Dieses würde Dein Problem m.M vollständig lösen (...und sogar mit der Replikationsfunktion einen "Benefit" erzeugen), da keine SAS oder FC Anbindung, die nicht aus einer VM direkt angesteuert werden kann, benötigt wird.
Noch ein bischen "Marketingblabla":
https://h20195.www2.hpe.com/V2/getpdf.aspx/4AA5-3017ENW.pdf
)Ich weis, das dies nicht von Microsoft supportet wird, da die Konsistenz der laufenden VMs während des Backups nicht gewährleistet werden kann. Dies hängt aber ganz von den Möglichkeiten der Backup-Software ab.Simpana SOLLTE eigentlich das "snappen" laufender VMs beherrschen.
Falls nicht, würde es aber helfen, die VMs während des Backups per Script zu stoppen und danach wieder zu starten.
P.S.
Librarys sind, obwohl weitgehend automatisiert, nicht "wartungsfrei"! Daher würde ich in "Remote Branches" eher etwas "weniger mechanisches" einsetzen:
Für den Preis einer MSL2024 mit LTO7 Laufwerk bekommt manschon eine gut ausgestattete HPE StoreOnce.
Diese wird von Simpana voll als B2D Device unterstützt.
https://documentation.commvault.com/commvault/v11_sp13/article?p=99422.h ...
Großer Vorteil hierbei ist zudem, das man auf die SAS oder FC Verbindung verzichten kann. Das Backup läuft, dedupliziert und kompremiert, über das LAN. Durch die Deduplizierung sind auch Repliken der Backups über extrem wackelige und schmalbandige WANs möglich.
Vielleicht gibt es eine ähnliche Lösung bereits in eurem Konzern?!
Dieses würde Dein Problem m.M vollständig lösen (...und sogar mit der Replikationsfunktion einen "Benefit" erzeugen), da keine SAS oder FC Anbindung, die nicht aus einer VM direkt angesteuert werden kann, benötigt wird.
Noch ein bischen "Marketingblabla":
https://h20195.www2.hpe.com/V2/getpdf.aspx/4AA5-3017ENW.pdf
1
