18
VMware Share größer als 64 TB -Best Practice
Liebe Admins,
ich benötige ein paar Erfahrungswerte, was das Bereitstellen von Shares angeht, die größer als 64 TB sind.
Wir haben hier aktuell (im Hyper V file server cluster ) Shares die größer als 64 TB sind und zukünftig in einem VMware Cluster genutzt werden sollen.
Das ist unter Hyper V (bereits) schwierig, vor allem was das Thema Backup via Snapshot angeht.
Wie handhabt ihr das bei VMware?
Falls es interessant ist, wie nutzen Veeam für's Backup.
Und nein, das spezifische Share lässt sich nicht verkleinern, da liegen zusammenhängende Daten drauf.
Viele Grüße und Danke
Thorsten
ich benötige ein paar Erfahrungswerte, was das Bereitstellen von Shares angeht, die größer als 64 TB sind.
Wir haben hier aktuell (im Hyper V file server cluster ) Shares die größer als 64 TB sind und zukünftig in einem VMware Cluster genutzt werden sollen.
Das ist unter Hyper V (bereits) schwierig, vor allem was das Thema Backup via Snapshot angeht.
Wie handhabt ihr das bei VMware?
Falls es interessant ist, wie nutzen Veeam für's Backup.
Und nein, das spezifische Share lässt sich nicht verkleinern, da liegen zusammenhängende Daten drauf.
Viele Grüße und Danke
Thorsten
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: 3218395658
Url: https://administrator.de/forum/vmware-share-groesser-als-64-tb-best-practice-3218395658.html
Ausgedruckt am: 27.12.2024 um 03:12 Uhr
18 Kommentare
Neuester Kommentar
Macht ihr jetzt die Snapshots mit VMware? Liegen die Daten direkt auf dem Hypervisor oder gibt es noch irgendein Storage dahinter?
Hi
Ihr habt jetzt eine VM die >=64TB ist oder ist das LUN nur 64TB und da liegen dann viele VMs drauf?
Ihr habt jetzt eine VM die >=64TB ist oder ist das LUN nur 64TB und da liegen dann viele VMs drauf?
Hi
Ist auf eurem Fileserver nur eine Vhdx Datei verwendete mit 64TB oder sind es mehrere?
Gehe mal davon aus das alle Datenträger GPT patitioniert sind.
Wie hoch ist die I/O Last auf dem und wie ist der ans Netzwerk angebunden.
Wenn hohe I/O dann pro 2-3 Vhdx sofern es mehr als eine sind paravirtuellen Adapter werden.
Beim Backup ist auch die Frage, ob es mehrer VHDX Dateien sind und was du ggf als SAN/ Storage im Hintergrund hast mit Veeam Proxy's oder nicht. Wie ist der Backupserver an das Storage der neuen VMware Umgebung angebunden etc.
VMX Netzwerkkarten verwenden keine e1000.
Mit freundlichen Grüßen Nemesis
Ist auf eurem Fileserver nur eine Vhdx Datei verwendete mit 64TB oder sind es mehrere?
Gehe mal davon aus das alle Datenträger GPT patitioniert sind.
Wie hoch ist die I/O Last auf dem und wie ist der ans Netzwerk angebunden.
Wenn hohe I/O dann pro 2-3 Vhdx sofern es mehr als eine sind paravirtuellen Adapter werden.
Beim Backup ist auch die Frage, ob es mehrer VHDX Dateien sind und was du ggf als SAN/ Storage im Hintergrund hast mit Veeam Proxy's oder nicht. Wie ist der Backupserver an das Storage der neuen VMware Umgebung angebunden etc.
VMX Netzwerkkarten verwenden keine e1000.
Mit freundlichen Grüßen Nemesis
Ok ok, hier etwas mehr Details.
Aktuell ist VMware noch nicht im Einsatz, nur Hyper V, das soll aber durch VMware ersetzt werden.
Im Hyper V ist es ein LUN, via iSCSI eingebunden und dann als File Server im Cluster.
Da liegen keine VMs drauf sondern reine Daten/Dateien (File Share).
Die Frage ist nun, wie das aus eurer Erfahrung bei VMware umgesetzt wird bzw. ihr das realisiert habt?!
Z.B. VM auf der das LUN eingebunden und dann geshared wird?
Hoffe das macht das ganze verständlicher.
Viele Grüße
Thorsten
Aktuell ist VMware noch nicht im Einsatz, nur Hyper V, das soll aber durch VMware ersetzt werden.
Im Hyper V ist es ein LUN, via iSCSI eingebunden und dann als File Server im Cluster.
Da liegen keine VMs drauf sondern reine Daten/Dateien (File Share).
Die Frage ist nun, wie das aus eurer Erfahrung bei VMware umgesetzt wird bzw. ihr das realisiert habt?!
Z.B. VM auf der das LUN eingebunden und dann geshared wird?
Hoffe das macht das ganze verständlicher.
Viele Grüße
Thorsten
Mit Share ist eine Dateifreigabe für SMB gemeint?
-siehe unten-
Zitat von @2423392070:
Mit Share ist eine Dateifreigabe für SMB gemeint?
Mit Share ist eine Dateifreigabe für SMB gemeint?
Ja genau!
Als RAW LUN der VM mounten und dann freigeben?!
Zitat von @2423392070:
Als RAW LUN der VM mounten und dann freigeben?!
Als RAW LUN der VM mounten und dann freigeben?!
Ich kann dir nicht ganz folgen^^
Aktuell ist das Volume via iSCSI auf allen HyperV Knoten verfügbar und über die Clusterrolle "File Server" wird das gemountet und als SMB Share bereit gestellt.
Die Frage ist, wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Teilen. Wenn du mit Windows Fileserver arbeitest, kannst das auch über DFS bereitstellen und z.B. die Unterordner alle auf einzelne LUNs bringen, das erhöht zum einen Performance und zum anderen ist nicht direkt alles weg, wenn dir mal das 64TB Volumen abraucht und die Sicherungen laufen schneller und du kannst der DFS Replikation die Verfügbarkeit steigern.
Wir hatten vorher auch "einen großen" Fileserver(pool) von >50TB, mittlerweile sind alleine 50 Server (25 Ordner - per DFS gespiegelt zwecks Ausfallsicherheit) für unseren Hauptshare (zwischen 100GB - 15TB je Server), Backups laufen parallel via Storagesnapshot über FC mit 2-3GB/s auf ein Veeam ScaleOut Storage. Wir können somit jeden Ordner einzeln wiederherstellen ohne viel Zeit zu verlieren und via DFS sieht es für den Enduser immer noch wie ein großer Fileserver aus.
Wir hatten vorher auch "einen großen" Fileserver(pool) von >50TB, mittlerweile sind alleine 50 Server (25 Ordner - per DFS gespiegelt zwecks Ausfallsicherheit) für unseren Hauptshare (zwischen 100GB - 15TB je Server), Backups laufen parallel via Storagesnapshot über FC mit 2-3GB/s auf ein Veeam ScaleOut Storage. Wir können somit jeden Ordner einzeln wiederherstellen ohne viel Zeit zu verlieren und via DFS sieht es für den Enduser immer noch wie ein großer Fileserver aus.
wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Gar nicht, denn mehr als 64TB ist nicht supportet!https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release ...
Zitat von @148523:
https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release ...
wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Gar nicht, denn mehr als 64TB ist nicht supportet!https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release ...
Oh shit, das hab ich gar nicht gesehen, nur das Maximum von 62 TB für eine vmdk.
Danke!
Zitat von @clSchak:
Teilen. Wenn du mit Windows Fileserver arbeitest, kannst das auch über DFS bereitstellen und z.B. die Unterordner alle auf einzelne LUNs bringen, das erhöht zum einen Performance und zum anderen ist nicht direkt alles weg, wenn dir mal das 64TB Volumen abraucht und die Sicherungen laufen schneller und du kannst der DFS Replikation die Verfügbarkeit steigern.
Wir hatten vorher auch "einen großen" Fileserver(pool) von >50TB, mittlerweile sind alleine 50 Server (25 Ordner - per DFS gespiegelt zwecks Ausfallsicherheit) für unseren Hauptshare (zwischen 100GB - 15TB je Server), Backups laufen parallel via Storagesnapshot über FC mit 2-3GB/s auf ein Veeam ScaleOut Storage. Wir können somit jeden Ordner einzeln wiederherstellen ohne viel Zeit zu verlieren und via DFS sieht es für den Enduser immer noch wie ein großer Fileserver aus.
Teilen. Wenn du mit Windows Fileserver arbeitest, kannst das auch über DFS bereitstellen und z.B. die Unterordner alle auf einzelne LUNs bringen, das erhöht zum einen Performance und zum anderen ist nicht direkt alles weg, wenn dir mal das 64TB Volumen abraucht und die Sicherungen laufen schneller und du kannst der DFS Replikation die Verfügbarkeit steigern.
Wir hatten vorher auch "einen großen" Fileserver(pool) von >50TB, mittlerweile sind alleine 50 Server (25 Ordner - per DFS gespiegelt zwecks Ausfallsicherheit) für unseren Hauptshare (zwischen 100GB - 15TB je Server), Backups laufen parallel via Storagesnapshot über FC mit 2-3GB/s auf ein Veeam ScaleOut Storage. Wir können somit jeden Ordner einzeln wiederherstellen ohne viel Zeit zu verlieren und via DFS sieht es für den Enduser immer noch wie ein großer Fileserver aus.
DFS hat einer der Kollegen auch schon in den Raum geworfen.
Wir wollten noch unterschiedliche Meinungen einholen.
Danke!
An DFS kommst du nicht vorbei. RAW Luns würde ich definitiv nicht mehr einsetzen.
Problematik von so grossen LUNS wurde auch korrekt angesprochen.
Problematik von so grossen LUNS wurde auch korrekt angesprochen.
Zitat von @Thorsten85:
Aktuell ist das Volume via iSCSI auf allen HyperV Knoten verfügbar und über die Clusterrolle "File Server" wird das gemountet und als SMB Share bereit gestellt.
Ich würde sagen das ist schon Mist. Ein Hypervisor ist ein Hypervisor und kein Fieserver. Eine Fileserverrolle gehört auf eine VM die unter Hyper-V läuft, nicht auf den Hyper-V direkt. Das gibt die Lizenz von Microsoft auch nicht her.Aktuell ist das Volume via iSCSI auf allen HyperV Knoten verfügbar und über die Clusterrolle "File Server" wird das gemountet und als SMB Share bereit gestellt.
Die Frage ist, wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Die Größe erstmal außen vor: Genauso würde ich es unter VMware machen. Auf VMware läuft eine VM und diese bindet dann das iSCSI Volume ein und stellt die Dateien da drauf als SMB/CIFS Share bereit. iSCSI kann in diesem Fall direkt die VM mit dem Storage machen, das habe ich aber nie wirklich selbst getestet.Abgesehen von den technischen Einschränkungen wären mir 64TB immer zu groß, ich würde versuchen das auf mehrere Fileserver mit DFS zu splitten aber hier fehlt mir die Erfahrung. Auch würde ich für die Datensicherung schauen ob es nicht sinniger ist auf dem Storage mit Snapshots durch den Storage Anbieter zu arbeiten und darüber zu sichern anstatt über einen Hypervisor zu gehen aber auch hier fehlt mir die Erfahrung in der Größenordnung. Das ist herstellerspezifisch und eventuell auch sehr teuer
Zitat von @Thorsten85:
Ich kann dir nicht ganz folgen^^
Aktuell ist das Volume via iSCSI auf allen HyperV Knoten verfügbar und über die Clusterrolle "File Server" wird das gemountet und als SMB Share bereit gestellt.
Die Frage ist, wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Zitat von @2423392070:
Als RAW LUN der VM mounten und dann freigeben?!
Als RAW LUN der VM mounten und dann freigeben?!
Ich kann dir nicht ganz folgen^^
Aktuell ist das Volume via iSCSI auf allen HyperV Knoten verfügbar und über die Clusterrolle "File Server" wird das gemountet und als SMB Share bereit gestellt.
Die Frage ist, wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Unter Hyper-Pfau heißt das Passthrough.
Zitat von @Thorsten85:
Oh shit, das hab ich gar nicht gesehen, nur das Maximum von 62 TB für eine vmdk.
Zitat von @148523:
https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release ...
wie das, bei der Größe über 64 TB, bei VMware am Besten gelöst wird.
Gar nicht, denn mehr als 64TB ist nicht supportet!https://configmax.esp.vmware.com/guest?vmwareproduct=vSphere&release ...
Oh shit, das hab ich gar nicht gesehen, nur das Maximum von 62 TB für eine vmdk.
Wenn ich es richtig verstehe, landet die LUN, die vom Storagesystem kommt, via iSCSI in der Windows Maschine. Somit sollte doch das VMware Limit nicht greifen.
Die evtl. anderen Probleme der 64 TB lassen ich mal außen vor.
Zitat von @mbehrens:
Wenn ich es richtig verstehe, landet die LUN, die vom Storagesystem kommt, via iSCSI in der Windows Maschine. Somit sollte doch das VMware Limit nicht greifen.
Jaein. So wie ich es verstehe wird die iSCSI LUN derzeit im Hypervisor gemountet und dort frei gegeben, also Hypervisor gleichzeitig Fileserver. Das wird so unter ESXi nicht mehr gehen.Wenn ich es richtig verstehe, landet die LUN, die vom Storagesystem kommt, via iSCSI in der Windows Maschine. Somit sollte doch das VMware Limit nicht greifen.
Wenn das also in eine VM umzieht und die VM iSCSI mit dem Storage macht, wären VMware Limits tatsächlich außen vor (Empfehlung meiner Seits).
