Erfahrungen mit HyperV VMs auf SMB-Share
Moin,
bisher habe ich es (für uns) als Best Practice angesehen, HyperV VMs entweder direkt auf lokalem Storage am Host laufen zu lassen oder aber über eine iSCSI-Verbindung anzuhängen.
Zuletzt habe ich häufiger gelesen, dass das mit SMB3 ebenso performant und problemlos laufen soll. Ist das so? Wie sind Eure Erfahrungen, gerade auch bei anspruchsvolleren VMs , auf denen Exchange oder Datenbanken laufen?
Gruß
bisher habe ich es (für uns) als Best Practice angesehen, HyperV VMs entweder direkt auf lokalem Storage am Host laufen zu lassen oder aber über eine iSCSI-Verbindung anzuhängen.
Zuletzt habe ich häufiger gelesen, dass das mit SMB3 ebenso performant und problemlos laufen soll. Ist das so? Wie sind Eure Erfahrungen, gerade auch bei anspruchsvolleren VMs , auf denen Exchange oder Datenbanken laufen?
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 461376
Url: https://administrator.de/contentid/461376
Ausgedruckt am: 22.11.2024 um 20:11 Uhr
12 Kommentare
Neuester Kommentar
Zitat von @Coreknabe:
Zuletzt habe ich häufiger gelesen, dass das mit SMB3 ebenso performant und problemlos laufen soll. Ist das so? Wie sind Eure Erfahrungen, gerade auch bei anspruchsvolleren VMs , auf denen Exchange oder Datenbanken laufen?
Zuletzt habe ich häufiger gelesen, dass das mit SMB3 ebenso performant und problemlos laufen soll. Ist das so? Wie sind Eure Erfahrungen, gerade auch bei anspruchsvolleren VMs , auf denen Exchange oder Datenbanken laufen?
Moin,
Würde mich auch interessieren. Allerdings traue ich das SMB als Filing-Protokoll nicht zu, wirklich genauso schnell zu sein. Ich zumindest bin da eher "konservativ".
lks
Daß nach 30 Jahren NFS immer noch das Mittel der Wahl ist, brauchen wir nicht zu diskutieren.
Aber Unser Coreknabe/HAL wollte glaube ich eher wissen, ob hier im Forum einer schon Erfahrungen damit hat SMB3 für das Storage von Hyper-V zu nutzen. Und mich würde das auch interessieren.
lks
Der hier kommt ja zu dem sensationellen Ergebnis das SMB3 wohl besser als alles ist:
https://blogs.technet.microsoft.com/larryexchange/2016/01/10/iscsi-or-sm ...
Glauben kann man das aber nicht wirklich im Vergleich zu Fiber Channel, NFS oder iSCSI.
https://blogs.technet.microsoft.com/larryexchange/2016/01/10/iscsi-or-sm ...
Glauben kann man das aber nicht wirklich im Vergleich zu Fiber Channel, NFS oder iSCSI.
Über DAC vielleicht.
SMB3 nutzt ja bei mehreren Interfaces mit IP im selben Subnetz durchaus alle Interfaces.
Bei einem test bin ich bei zwei Links auf beiden seiten fast an die zwei Gbit gekommen.
Ich meine aber in en m Erinnerung zu haben, das vom Hyper-V aus nicht direkt auf eine Freigabe zugegriffen werden kann. Hat sich das geändert?
SMB3 nutzt ja bei mehreren Interfaces mit IP im selben Subnetz durchaus alle Interfaces.
Bei einem test bin ich bei zwei Links auf beiden seiten fast an die zwei Gbit gekommen.
Ich meine aber in en m Erinnerung zu haben, das vom Hyper-V aus nicht direkt auf eine Freigabe zugegriffen werden kann. Hat sich das geändert?
Hallo,
ich kann das Thema ziemlich gut beantworten, da ich seit (Server) 2012 schon mit SMB3 arbeite und einiges an Projekten bei Kunden realisiert habe.
Das Protokoll SMB ab Version 3 ist sehr stabil und kann enorme Bandbreiten erreichen, allerdings bedingt eine fehlerfreie und robuste Kommunikation immer eine gute und stabile Netzwerk-Hardware im Hintergrund. Ich habe zig Scale-Out File Server Installationen gehabt und ab Server 2016 zusätzliche Storage Spaces Direct als Converged oder Hyperconverged-Setup. Die Bandbreiten lagen anfangs bei 10 Gbps, danach sind wir recht schnell auf 25 bzw. 100 Gbps gewechselt. Immer kam SMB3 zum Einsatz, Microsoft nutzt das Protokoll als Ersatz für FC/iSCSI/SAS und es läuft top.
Das SMB3-Protokoll arbeitet zudem sehr gut mit RDMA zusammen, hier kam primär RoCE zum Einsatz, vereinzelt iWARP. Durch diese Offload-Techniken habe ich Bandbreiten von 115 Gbps über eine Dual-Port 100 Gbps Mellanox Karte erreicht bei einer sehr geringen CPU-Belastung. iSCSI ist in diesen Bereichen nicht möglich (zumindest nicht mit einer sehr hohen CPU-Belastung, zusätzlich kommt MPIO sehr schnell an Grenzen), FC gibt es hier nur für sehr sehr viel Geld.
Wenn Hyper-V VMs auf einem SMB3-Share abgelegt werden sollen, sollte unbedingt auf ein Windows Server bzw. ein Cluster zurückgegriffen werden, alle anderen Lösungen und Implementierungen von Drittherstellern leiden an Einschränkungen oder Problemen.
Gruß, Jan
ich kann das Thema ziemlich gut beantworten, da ich seit (Server) 2012 schon mit SMB3 arbeite und einiges an Projekten bei Kunden realisiert habe.
Das Protokoll SMB ab Version 3 ist sehr stabil und kann enorme Bandbreiten erreichen, allerdings bedingt eine fehlerfreie und robuste Kommunikation immer eine gute und stabile Netzwerk-Hardware im Hintergrund. Ich habe zig Scale-Out File Server Installationen gehabt und ab Server 2016 zusätzliche Storage Spaces Direct als Converged oder Hyperconverged-Setup. Die Bandbreiten lagen anfangs bei 10 Gbps, danach sind wir recht schnell auf 25 bzw. 100 Gbps gewechselt. Immer kam SMB3 zum Einsatz, Microsoft nutzt das Protokoll als Ersatz für FC/iSCSI/SAS und es läuft top.
Das SMB3-Protokoll arbeitet zudem sehr gut mit RDMA zusammen, hier kam primär RoCE zum Einsatz, vereinzelt iWARP. Durch diese Offload-Techniken habe ich Bandbreiten von 115 Gbps über eine Dual-Port 100 Gbps Mellanox Karte erreicht bei einer sehr geringen CPU-Belastung. iSCSI ist in diesen Bereichen nicht möglich (zumindest nicht mit einer sehr hohen CPU-Belastung, zusätzlich kommt MPIO sehr schnell an Grenzen), FC gibt es hier nur für sehr sehr viel Geld.
Wenn Hyper-V VMs auf einem SMB3-Share abgelegt werden sollen, sollte unbedingt auf ein Windows Server bzw. ein Cluster zurückgegriffen werden, alle anderen Lösungen und Implementierungen von Drittherstellern leiden an Einschränkungen oder Problemen.
Gruß, Jan
Hi,
da alle mir bekannten Storage-Systeme nicht unter Windows betrieben werden, muss SMB3 immer "nachgebaut" werden. NetApp zum Beispiel hat die Einschränkung, dass SMB3 Multichanneling nicht funktioniert. Das ist in meinen Augen ein sehr großer Vorteil, da ich mal eben mehrere Ports / Karten gleichzeitig nutzen kann. Beim Thema Backup funktionieren viele Lösungen auch schlechter als ein nativer Windows-Server oder ein Windows-Cluster mit SMB3.
Um Missverständnisse vorzubeugen: Ich rede ausschließlich von dem Betrieb von Hyper-V VMs auf SMB3-Speicher, nicht die Ablage von Dateien
Gruß, Jan
da alle mir bekannten Storage-Systeme nicht unter Windows betrieben werden, muss SMB3 immer "nachgebaut" werden. NetApp zum Beispiel hat die Einschränkung, dass SMB3 Multichanneling nicht funktioniert. Das ist in meinen Augen ein sehr großer Vorteil, da ich mal eben mehrere Ports / Karten gleichzeitig nutzen kann. Beim Thema Backup funktionieren viele Lösungen auch schlechter als ein nativer Windows-Server oder ein Windows-Cluster mit SMB3.
Um Missverständnisse vorzubeugen: Ich rede ausschließlich von dem Betrieb von Hyper-V VMs auf SMB3-Speicher, nicht die Ablage von Dateien
Gruß, Jan