Hohe IO Last - Hyper-V Virtualisierung sinvoll ?

[ichkriegediekri]

Hallo Liebes Forum

Wir haben einen neuen Server dessen Hauptaufgabe es ist als File-Server viele Millionen an kleinen Dateien, die meisten unter 512kb.
auf einen SSD RAID 6 zu speichern.
Nebenher virtualisiere ich auf diesem Server 3 weitere, kleinere Server via Hyper-V da sich das eifnach anbietet, die brauchen kaum Ressourcen und so sparen wir extra Server HW.

Da Hyper-V ja schon ganz nett ist und man einfach einen kompletten Server sichern kann und bei einem Ausfall einfach auf einen anderen Server umlagern kann hatte ich überlegt das auch mit der Hauptaufgabe zu machen - also eine vierte VM für den Filserver mit einer VHDX Platte als Storage auf dem RAID 6.

Die Frage ist nun:
Macht das überhaupt Sinn wenn man die komplette VM mit über 20TB nicht komplett umziehen kann? - aktuell hat kein anderer Server 20TB frei um alles zu sichern und von dort zu laufen.

Der Server ist sehr IO lastig über Netzwerk und je niedriger die Netzwerklatenz ist, je besser für die User. Der Host hat eine X550-T2 und über SR-IOV bekomme ich bei einem "quick an dirty Test" maximal 350-450MB/s in der VM beim kopieren.

Also alleine was die Hauptaufgabe angeht ist die VM per Netzwerk nur halb so schnell wie der Host, und da sind Latenzen erst mal gar nicht berücksichtige - kann man das, bzw macht es Sinn das in diesem Szenarien für SR-IOV noch tunen oder sollte der FIle-Server lieber direkt auf dem Host laufen?

danke für Feedback :-)

 

[RalphS]

Eigentlich sollte ein Hypervisor (typ1) dediziert auf einem Blech laufen...

Davon abgesehen habt ihr das Problem mit den Mini-Dateien. Das macht sich mit SMB einfach nicht gut.

Dateisystemcache möglichst “unendlich”. Je mehr desto besser. Entsprechend RAM dafür bereitstellen.

vm ist für Isolation und Standardisierung gut, für I/O aber eher schlecht.

Mein Vorschlag wäre daher ein dediziertes Blech für den Fileserver, wenn verfügbar. Der VM Host bleibt. Dann gibts auch keine Engpässe, weil Host und VMs plötzlich beide Ressourcenhunger haben.

Vielleicht können die Minidateien aber auch in irgendeiner Form gebündelt werden? So ab 1MB/Einheit paßt das in etwa. Größer schadet natürlich nicht.

 

[rg88]

Die Frage ist nun:
Macht das überhaupt Sinn wenn man die komplette VM mit über 20TB nicht komplett umziehen kann? - aktuell hat kein anderer Server 20TB frei um alles zu sichern und von dort zu laufen.

Also habt ihr aktuell keine Datensicherung?

 

[xexex]

Da Hyper-V ja schon ganz nett ist und man einfach einen kompletten Server sichern kann und bei einem Ausfall einfach auf einen anderen Server umlagern kann hatte ich überlegt das auch mit der Hauptaufgabe zu machen - also eine vierte VM für den Filserver mit einer VHDX Platte als Storage auf dem RAID 6.

Die erste Frage wäre, wie habt ihr das überhaupt lizenziert?

Normalerweise läuft auf dem Blech nichts. Entweder nutze ich einen Server als Hyper-V Host mit VMs oder das reine Blech als Server und nicht gemischt. Eine Standard Serverlizenz deckt dann einmal den Hyper-V Host und zwei VMs ab, aber logischerweise nur wenn auf dem Hyper-V Host keine lizenzpflichtigen Dienste genutzt werden.

Grundsätzlich ist dein Gedanke also richtig, alles zu virtualisieren und bei vielen kleinen Dateien ist dein Raid 6 das größte Problem. Eine Lösung dafür falls ihr nur auf einen Teil der Dateien häufig zugreift wäre ein SSD Cache.

Die Frage am Rande wäre, ob du es auch ohne SR-IOV versucht hast und ob du eine Gen 1 oder Gen 2 Maschine verwendet hast. Zudem hast du an jeglichen Informationen zum eingesetzten Server und OS gespart.

 

[ichkriegediekri]

Eigentlich sollte ein Hypervisor (typ1) dediziert auf einem Blech laufen...

Davon abgesehen habt ihr das Problem mit den Mini-Dateien. Das macht sich mit SMB einfach nicht gut.

Dateisystemcache möglichst “unendlich”. Je mehr desto besser. Entsprechend RAM dafür bereitstellen.

vm ist für Isolation und Standardisierung gut, für I/O aber eher schlecht.

Mein Vorschlag wäre daher ein dediziertes Blech für den Fileserver, wenn verfügbar. Der VM Host bleibt. Dann gibts auch keine Engpässe, weil Host und VMs plötzlich beide Ressourcenhunger haben.

Vielleicht können die Minidateien aber auch in irgendeiner Form gebündelt werden? So ab 1MB/Einheit paßt das in etwa. Größer schadet natürlich nicht.

Das Blech wurde aktuell für den File Server angeschafft und ist deutlich überdimensioniert - Bsp. Empfehlung 6c und 32GB RAM, wir haben 16c/32t und 128GB RAM.
Die 3 anderen Server haben nahezu 0 Anforderungen und können da ohne weiteres mit drauf laufen, da wird es kein Ressourcenproblem geben.

Die Daten werden nicht über SMB versendet sondern aber so wie Du es darlegst bleibt die File-Server-Software mit Datenbank auf dem Blech.

Die Mini-Daten kann man leider nicht bündeln.

Ergänzung (13. Oktober 2019)

Die erste Frage wäre, wie habt ihr das überhaupt lizenziert?

Normalerweise läuft auf dem Blech nichts. Entweder nutze ich einen Server als Hyper-V Host mit VMs oder das reine Blech als Server und nicht gemischt. Eine Standard Serverlizenz deckt dann einmal den Hyper-V Host und zwei VMs ab, aber logischerweise nur wenn auf dem Hyper-V Host keine lizenzpflichtigen Dienste genutzt werden.

Grundsätzlich ist dein Gedanke also richtig, alles zu virtualisieren und bei vielen kleinen Dateien ist dein Raid 6 das größte Problem. Eine Lösung dafür falls ihr nur auf einen Teil der Dateien häufig zugreift wäre ein SSD Cache.

Die Frage am Rande wäre, ob du es auch ohne SR-IOV versucht hast und ob du eine Gen 1 oder Gen 2 Maschine verwendet hast. Zudem hast du an jeglichen Informationen zum eingesetzten Server und OS gespart.

Hi

Wenn es virtuell wird bekommt jede VM eine eigene Lizenz, aber soweit bin ich ja noch nicht.

Das RAID 6 besteht aus SSDs - ich glaube da macht ein SSD Cache kein Sinn

Server-Blech:
Epyc 7302p
128GB RAM
OS auf SSD 530 RAID10 mit HS
RAID 6 mit SSDs 24TB
2x 1Gbe NIC
X550 T2 10GBe

Die Test-VM mit SR-IOV hatte ich als Gen2 aufgesetzt. Ohne SR-IOV hatte ich es noch nicht probiert, kann ich gleich mal machen.

EDIT:
Netzwerkgeschwindigkeit ohne SR-IOV ist im Prinzip gleich.

Ergänzung (13. Oktober 2019)

Also habt ihr aktuell keine Datensicherung?

Doch auf nem NAS und offline - aber auf dem NAS könnte ich nicht eben mal ne Hyper-V VM anschmeissen.

Ergänzung (13. Oktober 2019)

So nun sind die IO Meter Benchmarks auf der VM ein paar mal durchgelaufen.
So Pie-Mal-Daumen sind es je nach gemessener Dateigröße 3 bis 8% weniger als direkt auf der Hardware - ich denke damit ist die Sache vom Tisch und der File-Server bleibt direkt auf dem Blech.

 

[xexex]

Die Daten werden nicht über SMB versendet sondern aber so wie Du es darlegst bleibt die File-Server-Software mit Datenbank auf dem Blech.

Verstehe einer den Satz.....

Ist das nun ein Fileserver oder greift ihr auf die Daten nur über eine Datenbank zu?

Wenn es virtuell wird bekommt jede VM eine eigene Lizenz, aber soweit bin ich ja noch nicht.

Abgesehen davon das nicht jede VM eine eigene Lizenz benötigt, weil eine Server Lizenz zwei VM Lizenzen beinhaltet, macht man sich über sowas eigentlich vorab Gedanken.

Das RAID 6 besteht aus SSDs - ich glaube da mach ein SSD Cache kein Sinn

Vor allem macht da ein Raid 6 keinen Sinn. Du nimmst schnelle Datenträger, mit einer hohen IO Leistung und einer geringen Ausfallwahrschenlichkeit und bindest sie an einen Raid Controller mit Raid 6, womit du einen Großteil der Leistung wieder verschenkst.

Hast du dir mal die Warteschlangenlängen auf dem Host, bzw. in der VM mal angeschaut? Ich würde mir an dieser Stelle weniger Gedanken um die Netzwerkleistung machen und mehr über die Datenträgerleistung auf dem Server.

EDIT:
Welcher Raidcontroller ist überhaupt im Einsatz? Wenn der Aufbau so bleiben soll, so wäre meine Empfehlung hierzu mindestens die 9400er Serie von Broadcom zu verwenden.

 

[rg88]

Für mich hört sich das auch alles recht planlos an. Hier gibts anscheinend keinerlei Konzept dahinter, sondern "schaun wir mal, dann sehen wirs schon" ist die Devise... Kann man machen, wird halt dann meistens Scheiße, was hinten rauskommt.

 

[xexex]

So Pie-Mal-Daumen sind es je nach gemessener Dateigröße 3 bis 8% weniger als direkt auf der Hardware - ich denke damit ist die Sache vom Tisch und der File-Server bleibt direkt auf dem Blech.

Wegen 3-8% weniger Leistung, bei einem laut deiner eigenen Aussage eh überdimensionierten Server, verzichtest du auf eine Ausfallsicherheit? Du verschenkst weit mehr Leistung durch Raid 6.

Was machst du wenn dir morgen das Blech kaputt geht?

Wenn man halbwegs logisch nachdenkt, virtualisiert man heutzutage alle Server die irgendwelche Bedeutung für den Betrieb haben. Zur Not kann man dann einen solchen Server auch von einem x-beliebigen PC starten oder rüstet die alte Hardware für einen Notbetrieb mit ein paar Festplatten aus und nutzt Hyper-V Replikation zur Absicherung.

 

[ichkriegediekri]

Verstehe einer den Satz.....

Ist das nun ein Fileserver oder greift ihr auf die Daten nur über eine Datenbank zu?

Auf die Daten wird per DB über die Software zugegriffe

Abgesehen davon das nicht jede VM eine eigene Lizenz benötigt, weil eine Server Lizenz zwei VM Lizenzen beinhaltet, macht man sich über sowas eigentlich vorab Gedanken.

Hab ich doch primär gemacht ;-) - primäres Blech mit einer lizensierten Aufgabe und Lizenz und für die anderen VMs eine eigene Lizenz.

Vor allem macht da ein Raid 6 keinen Sinn.

Für mich hört sich das auch alles recht planlos an. Hier gibts anscheinend keinerlei Konzept dahinter, sondern "schaun wir mal, dann sehen wirs schon" ist die Devise... Kann man machen, wird halt dann meistens Scheiße, was hinten rauskommt.

Wegen 3-8% weniger Leistung, bei einem laut deiner eigenen Aussage eh überdimensionierten Server, verzichtest du auf eine Ausfallsicherheit? Du verschenkst weit mehr Leistung durch Raid 6.

Was machst du wenn dir morgen das Blech kaputt geht?

Wenn man halbwegs logisch nachdenkt, virtualisiert man heutzutage alle Server die irgendwelche Bedeutung für den Betrieb haben. Zur Not kann man dann einen solchen Server auch von einem x-beliebigen PC starten oder rüstet die alte Hardware für einen Notbetrieb mit ein paar Festplatten aus und nutzt Hyper-V Replikation zur Absicherung.

Da meine primäre Frage Virtualisierung und nicht die HW per se ist habe ich die meisten Details nicht mit gepostet:

Warum ist ein RAID 6 mit SSDs schlecht?
Die Lese IO Leistung von einen RAID 6 ist gut und die IOs gehen da ja beim Lesen nicht in den Keller, nur schreiben ist schlecht.
Das Schreiben der Daten ist von der Geschwindigkeit nicht relevant, da auf dem Server alle reinkommenden Daten von den Erzeugern nicht sehr schnell kommen.

Aktuell haben wir ein HDD RAID 10 was im Schnitt 15MB/s im Lesezugriff bei unseren Daten schafft.
Wenn ich die Benchmarks vergleiche, mehr kann ich aktuell nicht da die neue Software noch nicht läuft, dann liegt das SSD RAID da im Schnitt um den Faktor 5+ drüber - und das teilweise mit einer QD von 1. Zu erwarten ist eine QD von ca. 10 im Durchschnitt - damit wären das SSD RAID mit den IO-Meter Tests um ca den Faktor 10 Schneller als das alte HDD RAID 10 - das reicht für uns locker aus.
On Top habe ich bei den Enterprise SSDs mit PLP eine AFR von 0,3x% gegenüber ca. 0,4x% und somit bei einem RAID 6 eine enorm niedrige Wahrscheinlichkeit eines Totalausfalls des Verbundes - Bei all dem wüsste ich jetzt nicht warum ein SSD RAID 6 schlecht sein sollte.

Der Controller ist ein Adaptec SmartRAID und das Array läuft im SSD-IO Modus - sollte auch passen. Broadcom 9460 8i hatte ich auch getestet aber die gehen nur bis zu einer Stripe Size von 64kb runter und die Performance mit SZ von 16kb oder 32kb ist ein Stück besser als bei 64kb

Wegen 3-8% weniger Leistung, bei einem laut deiner eigenen Aussage eh überdimensionierten Server, verzichtest du auf eine Ausfallsicherheit? Du verschenkst weit mehr Leistung durch Raid 6.

Was machst du wenn dir morgen das Blech kaputt geht?

Wenn man halbwegs logisch nachdenkt, virtualisiert man heutzutage alle Server die irgendwelche Bedeutung für den Betrieb haben. Zur Not kann man dann einen solchen Server auch von einem x-beliebigen PC starten oder rüstet die alte Hardware für einen Notbetrieb mit ein paar Festplatten aus und nutzt Hyper-V Replikation zur Absicherung.

Naja zu den reinen 3-8% bei Dateizugriff addiert sich dann ja noch die Latenz bei Netzwerkzugriff vom virtuellen Gast.
Jede Datei die versendet wir erzeugt mindestens 3 Netzwerkvorgänge:
1 der Versand wird angekündigt und auf das OK gewartet
2 Datei wird versendet
3 Es wird gefragt ob die Datei angekommen ist

Somit wird die bei der Übertragung von mehren tausend von Dateien pro Zugriff eher schlechter als besser sein mit einer VM.

Wenn das Blech wirklich kaputt geht gibt es ein Ausfallkonzept was auch funktioniert. Das wäre für ein paar Tage kein Problem, der Server hat 5 Jahre NBD als Service.

 

[xexex]

Warum ist ein RAID 6 mit SSDs schlecht?
Die Lese IO Leistung von einen RAID 6 ist gut und die IOs gehen da ja beim Lesen nicht in den Keller, nur schreiben ist schlecht.

On Top habe ich bei den Enterprise SSDs mit PLP eine AFR von 0,3x% gegenüber ca. 0,4x% und somit bei einem RAID 6 eine enorm niedrige Wahrscheinlichkeit eines Totalausfalls des Verbundes - Bei all dem wüsste ich jetzt nicht warum ein SSD RAID 6 schlecht sein sollte.

Du beantwortest dir die Frage doch schon selbst!

Wieso ist Raid 6 schlecht? Doppelte Parität kostet den Raidcontroller Leistung, nicht umsonst schaffen wie du meiner Grafik entnehmen kannst, nur die neusten Controller halbwegs hohe Leistungen und in der Grafik wird von Raid 5 und nicht von Raid 6 gesprochen. Simpel ausgedrückt verschenkst du Leistung gewinnst aber faktisch nichts.

Betrachte mal deine Lösung im Gesamtkonzept. Du setzt Raid 6 bei SSDs, die wie du selber sagst eine geringe Ausfallwahrschenlichkeit haben, du nutzt Raid 10 für das System und was hast du davon?

Wenn dir das Motherboard oder der Raid Controller ausfällt, hast du derzeit einen Ausfall von mindestens einem Tag. NBD hört sich schön an, glaubst du am nächsten Tag ist genau der Server mit der Hardware die du hast, zu 100% wieder bei euch im Hause? Träum weiter!

Ich zitiere dir dazu gerne was von Fujitsu:

Auf der anderen Seite hast du anscheinend kein schlüssiges Sicherungskonzept, keine Replikation der Server, keine Cold Standby Hardware und laut deiner Aussage nicht einmal irgendwo genug Speicherkapazität um abseits vom aktuellen Server die Daten wiederherstellen zu können. Nennst du das ein Konzept?

Ich nenne dir mal zwei Konzepte.
1.
1x Hyper-V mit Raid-0 SSD Verbund
1x Hyper-V Cold Standby mit Raid-5 HDD Verbund
30 Sec Replikation zwischen den Hosts, mit 24h Vorhaltezeit
1x Tag Sicherung der Daten mit 1-3 Jahren Vorhaltezeit.

2.
1x Hyper-V mit Raid 5 SSD Verbund
1x Hyper-V ohne Storage (kann irgendeine Hardware sein)
1x schnelles NAS System
Backup Software mit CDP, 5 min Sicherung und der Möglichkeit die VMs direkt vom Backup starten zu können.

Dazu gibt es heutzutage noch unzählige andere Lösungen wie Storage Spaces Direct.

Der Knackpunkt deiner Lösung ist, das dir die 10% Leistungsnachteil durch Virtualisierung anscheinend stören, obwohl du laut deiner Aussage einen sowieso stark überdimensionierten Server im Einsatz hast und auf der anderen Seite Leistung verschenkst obwohl dir das keine Vorteile bietet.

Ich kenne jetzt weder seine Datenbank, deine Hardware, deine Dateien noch die Umgebung mit der dieser Server genutzt wird. Die "Leistungsprobleme" mit der Virtualisierung würde ich aber nicht bei den VMs, sondern bei deiner Storagelösung suchen und da würde ich an deiner Stelle hier mal anfangen.
https://docs.microsoft.com/de-de/wi...ng/role/hyper-v-server/storage-io-performance

Bei vielen kleinen Dateien würde ich sowieso auf ReFS als Dateisystem setzen, nur macht ReFS wenig Sinn, wenn man keine Replikation der Daten besitzt.

EDIT: Deine kleine Blocksize sehe ich sowieso nur kontraproduktiv, weil du die SSDs und den Controller dazu zwingst bei jeder kleinen Datei mehrere IOs über mehrere Datenträger zu verteilen und nur unnötigen Overhead und Latenz produzierst.

Vermutlich wird es auch die Ursache sein, wieso die Leistung mit Virtualisierung bei dir dann einbricht, weil der Zugriff auf virtuelle Datenträger blockbasiert geschieht. Theoretisch könntest du den Datenträger direkt in die VM einbinden, hättest damit aber wenig gewonnen.

 

[ichkriegediekri]

Du beantwortest dir die Frage doch schon selbst!

Wieso ist Raid 6 schlecht? Doppelte Parität kostet den Raidcontroller Leistung, nicht umsonst schaffen wie du meiner Grafik entnehmen kannst, nur die neusten Controller halbwegs hohe Leistungen und in der Grafik wird von Raid 5 und nicht von Raid 6 gesprochen. Simpel ausgedrückt verschenkst du Leistung gewinnst aber faktisch nichts.

Betrachte mal deine Lösung im Gesamtkonzept. Du setzt Raid 6 bei SSDs, die wie du selber sagst eine geringe Ausfallwahrschenlichkeit haben, du nutzt Raid 10 für das System und was hast du davon?

Wenn dir das Motherboard oder der Raid Controller ausfällt, hast du derzeit einen Ausfall von mindestens einem Tag. NBD hört sich schön an, glaubst du am nächsten Tag ist genau der Server mit der Hardware die du hast, zu 100% wieder bei euch im Hause? Träum weiter!

Ich zitiere dir dazu gerne was von Fujitsu:
Anhang anzeigen 830677

Auf der anderen Seite hast du anscheinend kein schlüssiges Sicherungskonzept, keine Replikation der Server, keine Cold Standby Hardware und laut deiner Aussage nicht einmal irgendwo genug Speicherkapazität um abseits vom aktuellen Server die Daten wiederherstellen zu können. Nennst du das ein Konzept?

Ich nenne dir mal zwei Konzepte.
1.
1x Hyper-V mit Raid-0 SSD Verbund
1x Hyper-V Cold Standby mit Raid-5 HDD Verbund
30 Sec Replikation zwischen den Hosts, mit 24h Vorhaltezeit
1x Tag Sicherung der Daten mit 1-3 Jahren Vorhaltezeit.

2.
1x Hyper-V mit Raid 5 SSD Verbund
1x Hyper-V ohne Storage (kann irgendeine Hardware sein)
1x schnelles NAS System
Backup Software mit CDP, 5 min Sicherung und der Möglichkeit die VMs direkt vom Backup starten zu können.

Dazu gibt es heutzutage noch unzählige andere Lösungen wie Storage Spaces Direct.

Der Knackpunkt deiner Lösung ist, das dir die 10% Leistungsnachteil durch Virtualisierung anscheinend stören, obwohl du laut deiner Aussage einen sowieso stark überdimensionierten Server im Einsatz hast und auf der anderen Seite Leistung verschenkst obwohl dir das keine Vorteile bietet.

Ich kenne jetzt weder seine Datenbank, deine Hardware, deine Dateien noch die Umgebung mit der dieser Server genutzt wird. Die "Leistungsprobleme" mit der Virtualisierung würde ich aber nicht bei den VMs, sondern bei deiner Storagelösung suchen und da würde ich an deiner Stelle hier mal anfangen.
https://docs.microsoft.com/de-de/wi...ng/role/hyper-v-server/storage-io-performance

Bei vielen kleinen Dateien würde ich sowieso auf ReFS als Dateisystem setzen, nur macht ReFS wenig Sinn, wenn man keine Replikation der Daten besitzt.

Bei deiner Grafik und den RAID controllern geht es um writes und nicht um reads.
Und wie Du sicher gelesen hast sind writes kein Flaschenhals bei dem setup.
Reads sind bei Raid 5 und 6 gut, da gibt es keinen sig. Unterschied.
Ausserdem ist der Adaptec ein Controller der neusten Generation, der hat glaube ich 1.7m Iops.
Da habe ich mir schon Gedanken gemacht...



"Betrachte mal deine Lösung im Gesamtkonzept. Du setzt Raid 6 bei SSDs, die wie du selber sagst eine geringe Ausfallwahrschenlichkeit haben, du nutzt Raid 10 für das System und was hast du davon?"

Verstehe hier nicht was Du meinst. Es ist doch gängige Praxis dass man das Betriebssystem auf einem separaten Array installiert.


" Wenn dir das Motherboard oder der Raid Controller ausfällt, hast du derzeit einen Ausfall von mindestens einem Tag. NBD hört sich schön an, glaubst du am nächsten Tag ist genau der Server mit der Hardware die du hast, zu 100% wieder bei euch im Hause? Träum weiter"

Wie oben geschrieben gibt es ein Ausfall Konzept und wir haben Sicherungen, mehr als eine und auch ein NAS wo die Daten drauf sind. Nur einen Server mit 20TB+ wo ich mal eben eine VM hin migrieren könnte haben wir aktuell nicht.

Also träumen tu ich nicht und das NBD nicht bedeutet dass nach einem Tag alles geht ist mir auch klar - ich leb doch nicht auf dem Mond.
NBD ist aber 1000x, besser als " bring- in" in so einem setup 🤣
Mit dem Ausfall Konzept kommen wir ohne weiteres bis zu 1 Woche klar.

"Der Knackpunkt deiner Lösung ist, das dir die 10% Leistungsnachteil durch Virtualisierung anscheinend stören, obwohl du laut deiner Aussage einen sowieso stark überdimensionierten Server im Einsatz hast und auf der anderen Seite Leistung verschenkst obwohl dir das keine Vorteile bietet."

Das ist ja nur die reine VHDx/Festplattenperformance di le ich famit damit schon mal genau bestimmt habe.
Netzwerklatenz kommt ja noch dazu und das kann ich ja nicht abschätzen - deswegen ja der Thread hier da ja alleine die Datenübertragung hier schon in der VM 40% geringer als auf dem Host ist - ist das kein Grund es auf dem Blech zu lassen?


Zu dem Dateisystem:
Wir nehmen Refs. Das macht alleine schon Sinn wegen der checksumme der Metadaten - schon mal checkdsk auf Ntfs mit knapp 100 Millionen Dateien gemacht? Da ist das Laufwerk ein Wochenende offline...

Die 2 Konzepte sind ja sicherlich gut und funktionieren toll aber dafür müssten wir grob geschätzt nochmal 20k€ investieren da Storage spaces nur als RAID 10 sicher und performant wäre und noch ein neuer Server fällig wird - und da muss man sagen ist das bei so einem Betrieb mit den Kosten schwer zu rechtfertigen.

 

[xexex]

Bei deiner Grafik und den RAID controllern geht es um writes und nicht um reads.

Schau nochmal hin!

Zu dem Dateisystem:
Wir nehmen Refs. Das macht alleine schon Sinn wegen der checksumme der Metadaten - schon mal checkdsk auf Ntfs mit knapp 100 Millionen Dateien gemacht? Da ist das Laufwerk ein Wochenende offline...

Schon mal nachgedacht wie ReFS funktioniert?

https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview

Setzt du Storage Spaces ein?

Ein viel beschworenes Märchen ist es zu behaupten ReFS könnte sich selbst reparieren..... Das kann es! Wenn es mit Storage Spaces zusammen eingesetzt wird...

Crasht dir das Dateisystem ohne Storage Spaces, kannst den Datenträger wegwerfen und die Datensicherung zurückspielen. Der Vorteil der sich für dich letztlich ergibt, das System erkennt wenn eine Datei beschädigt ist und sperrt den Zugriff darauf, mehr nicht.

Deshalb setzt man ReFS dort ein, wo man Daten repliziert oder die Sicherungshäufigkeit ausreicht um bei einem Verlust des Datenträgers, den Verlust der Daten die in der Zwischenzeit geändert worden sind verschmerzen kann.

CHKDSK mag Stunden für einen Durchlauf benötigen, bei ReFS bekommst du dafür sowas zu sehen.

 

[ichkriegediekri]

post folgt...

 

[ichkriegediekri]

Schau nochmal hin!

Hab ich.
Die Rede ist von writes in der Tabelle und den dazugehörigen IOPs - da ich aber so oder so einen Controller der neuesten Generation habe ist das doch wirklich egal oder?
Schneller als mit nem 9460 oder einen Adaptec 3154 geht aktuell nicht per Hardware RAID.

Ich verstehe nicht warum ein RAID 6 aus Deiner Sicht so schlecht ist? Die Read Performance ist mit einem RAID 5 und RAID 0 vergleichbar nur die write penalty ist 6x.

Schon mal nachgedacht wie ReFS funktioniert?

[IMG]https://www.computerbase.de/forum/attachments/1570982215429-png.830720/[/IMG]
https://docs.microsoft.com/en-us/windows-server/storage/refs/refs-overview

Setzt du Storage Spaces ein?

Ein viel beschworenes Märchen ist es zu behaupten ReFS könnte sich selbst reparieren..... Das kann es! Wenn es mit Storage Spaces zusammen eingesetzt wird...

Ja hab ich und ich habe hier nicht behauptet ReFS repariert sich immer selber. Ich weiss dass es die data stream resilency nur bei Mirror und parity gibt. Mehr zu Storage spaces unten.

Zu dem Screenshot:
Willst Du damit sagen auf einem basic Volume ist RefS schlechter als NTFS? - das wäre mir in der Tat neu.

EDIT: Deine kleine Blocksize sehe ich sowieso nur kontraproduktiv, weil du die SSDs und den Controller dazu zwingst bei jeder kleinen Datei mehrere IOs über mehrere Datenträger zu verteilen und nur unnötigen Overhead und Latenz produzierst.

Ja und nein. Die Benchmarks mit IOMeter schreiben für die Blechbüchse direkt ein anderes Bild für alle Dateien unter 512kb - und das sind genau unsere Dateigrößen.

Für die VM mag das mit der Blockgröße stimmen. Aber solange ich über die Netzwerkverbindung der VM so oder so nur 400MB/s als Durchsatz habe ist das erst einmal irrelevant.
Den File Server virtuell laufen zu lassen macht nur Sinn wenn das Netzwerk auf 700+MB/s.
Und ja das Volume direkt anbinden ist sicherlich sinnlos.

Aufgrund dieser Schwierigkeiten war die Virtualisierung für diesen Server auch primär nicht geplant. Da aber die Virtualisierung der anderen so easy war dachte ich es wäre doch blöd das jetzt nicht nochmal zu überdenken.


Ok, nachdem ich auf die Punkte direkt eingegangen bin:

Ich denke man muss hier ein paar Dinge differenzieren:
a) was ist technisch optimal und bedingt die bester Performance und Ausfallsicherheit
b) was ist Vor Ort mit den Gegebenheiten und dem Budget möglich und steht in Relation zu den Kosten bzw. den zu erwartendem Verlust im Falle eines Defektes.


Rein von meiner persönlichen Seite tendiere ich in der Regel immer zu a) da ich ein kleiner Technik-Freak bin.
Von der Seite b) muss ich mich aber dem Gesamtkonstrukt und auch den Kosten anpassen.

Es sieht daher so aus das 2 vollwertige High end Server die alle unsere Software via fail-over virtualisieren können vom Budget aktuell nicht drin sind - da spielen auch Wartungskosten der Firmen mit rein die dann teurer werden (fragt nicht, es ist so)
Die Vergangenheit (über 20 jahre) gibt diesem Punkt auch Recht da egal welchen Defekt wir hatten wir bisher immer nach spätestens 8h wieder online waren.
Darüber hinaus ist das Ausfallkonzept für diesen Server, um den es hier gerade geht, gut genug dass wir ohne Problem eine ganze Woche überbrücken können. Selbst ein voller Verlust des RAID wäre kein Problem da die Daten auf einem NAS liegen und die Software automatisch umschaltet.


PS:

Zu Storage Spaces:
Wenn ich ReFS mit Storage spaces nehmen würde benötige ich folgendes Setup:

Tier 0 SSDs: ca 4-6TB vorzugsweise SAS als RAID 1 oder 10
Tier 1: ca. 20TB HDDs als RAID10
Parity hat sich in meinen Tests vor einem Jahr und auch was man so im Internet liest nicht gut geschlagen.

Ein solcher Server kostet nur ein klein bisschen weniger wie der aktuelle FLASH-Only SSD Server - aber mit letzerem bekomme ich für alle Daten SSD Performance und die Ausfallsicherheit des RAID ist ähnlich - über RAID 6 vs 10 kann man so oder herzlich streiten

Zur Replikation:
Variante 1 ist aus Kostengründen erstmal raus.

Variante 2 wäreeine Option für nächstes Jahr wenn ein anderer Server ersetzt wird. Dann könnte man einen als primären betreiben mit RAID und den anderen zu Replikation. Die 24TB würde ich dann für den Replikationsserver auf dem NAS liegen - rein vom drüber nachdenken müsste das mit der Software gehen.

 

[ichkriegediekri]

Also ich glaube die einfachste Lösung für das Problem, welches der Grund für die Erstellung des Threads war, ist einfach bei 10G die NIC zu Teamen.
Entweder auf dem Host und dann per vswitch an die VM, 2 NICs in der VM Teamen oder am besten wohl Switch-Embedded-Teaming SET - der dynamische Teaming modus müsste reichen da die Geschwindigkeit primär zum Senden wichtig ist. Empfangen wird aktuell Nie über 1GBit/s

 

[ichkriegediekri]

Guten Morgen liebe Forenmitglieder

Ich habe nochmal die komplette VM neu aufgesetzt und auf dem Host die X550 NIC Treiber neu aufgespielt. Ausserdem hatte ich das FW Update der NIC vorher vergessen.

Mit SR-IOV kann ich jetzt bei iperf3 mit 2 Verbindungen die 10G NIC vollständig auslasten. Mit 1 Verbindung ist es knapp die Hälfte.
Unter Windows werden per SMB Dateien mit 700-1000 MB/s kopiert - also das ist so alles OK.
Das einzige was auffällt ist dass das Senden aus der VM immer einen Tick schneller ist als das Empfangen, macht den Bock aber nicht Fett.

Anschließend habe ich die virtuelle Festplatte nochmal aus der VM heraus getestet und das Ergebnis ist nicht so gut.
Quer Durch die Bank ist die VM mit dem VHDX Laufwerk der Blechbüchse bei den kleinen Dateien unter ca. 300kb um ca. 25% unterlegen. Erst ab 512kb Dateigröße nivelliert sich das fast aus.
Da aber so gut wie alle Dateien kleiner als 300kb sind ist eine VM mit VHDx drive somit keine Option da ein großer Teil des Mehrwerts der SSDs einfach verpufft - das mag zwar aktuell im Vergleich zum alten Server egal sein, macht die Sache aber mit Blick auf die Zukunft eher uninteressant.

Die einzige Möglichkeit wäre jetzt das Laufwerk direkt an die VM anzubinden. Hier würde sich der Vorteil der VM dann aber im Wesentlichen darauf reduzieren, dass man bei einem Neustart des File Servers die anderen VMs nicht betroffen wären - und wenn ich überlege wie oft der File Server sonst rebootet und was die anderen VMs machen wäre das eigentlich zu vernachlässigen.

Somit wird der File Server wohl auf der Blechbüchse bleiben.

EDIT:
Ja es war total blauäugig die VHDX vorher im Host zu mounten und von dort zu benchen....

 

[ayngush]

Sobald du eine Virtuelle Maschine mit einer oder mehrer VHD(X)-Datei(en) benutzt, ist der I/O Workload auf der eigentlich darunter liegenden Hardware ein ganz anderer im Vergleich zu einem nativen Dateisystem. Da muss die Hardware und der Controller ggf. umkonfiguriert werden (falls möglich). Enterprise-SSDs gibt es auch für verschiedene I/O Workloads, ist halt die Frage, was da in euren Server steckt.

Zudem halte ich Raid 5 oder 6 alleine für den Main Storage in 2019 für nicht mehr zeitgemäß, die Reise geht (ging schon vor geraumer Zeit ) definitiv in Richtung Dynamic Disk Pools, die die Paritäten über logische Blöcke ganz anders als Raid 5 oder 6 auf den physikalischen Disks verteilen. Dadurch können auch mehr als zwei Platten gleichzeit ausfallen, den Grad dafür kann man meistens frei bestimmen und die Dauer des Rebuilds ist stark verkürzt und der Performanceimpact bei einem Rebuild nicht so groß wie bei klassischen Raidcontrollern mit Raid 5 oder 6.

Zudem würde ich Storage und Server zukünftig dringend trennen, das sind zwei verschiedene Dinge, die unterschiedliche wachsen und skalieren. Merkste ja selber: Hardware gekauft, Ressourcen auf der einen Seite zu viel vorhanden (CPU + RAM) und auf der anderen passt es gerade so (Storage). Aber alles in einer Maschine und man kann die Ressourcen so nicht mehr sehr gut auslasten, sodass da viel totes Kapital herumsteht.

Und Storage auch bitte nicht über das Netzwerk abbilden (Performancebremse...), also kein NAS sondern ein vernünftiges SAN in Betracht ziehen. Das ist ein himmelweiter Unterschied. Der SAN-Storage selber wird an die Hyper-V Hosts via redundanten SAS und round robin Lastverteilung mit Failover angebunden. In einem SAN kann man den I/O Workload dann auch für die verschiedenen Volumes vorgeben, sodass man da optimal unterwegs ist, je nachdem, ob da Datenbanken direkt drauf schreiben oder halt Hyper-V Workload drauf kommt oder VM-Ware oder KVM oder oder oder... Das lässt sich dann auch besser Verwalten und Erweitern. Man kann die Server, sollte RAM und CPU nicht reichen, leichter austauschen, weil die Storage-Infrastruktur nicht jedes mal neu mit geplant werden muss. Man kann relativ einfach zusätzliche Hyper-V Hosts dazu klemmen (sofern man noch SAS-Ports frei hat), falls die Ressourcen auf den vorhandenen nicht mehr ausreichen usw. Sprich: Mach macht sich nicht so abhängig, wie wenn man alles in eine Maschine stopft. Nachteil: Kostet alles 10 Mark fünfzig mehr.

Für eine schöne Hyper-V-Infrastruktur braucht der Host auch sinnvollerweise 3 bis 4 (oder noch mehr) dedizierte Netzwerkanschlüsse. Einen für das Management (Netzwerksegmentierung, Sicherheit). Einen für das Backup (Lastabwurf aus dem Produktionsnetz). Ggf. einen für die Live Replikation, falls man keinen Failovercluster verwendet (Lastabwurf...). Vorsicht bei Windows-Server-Standard Lizenzen und Failover-Cluster, da kann man nicht mehr aus einer Lizenz zwei Server machen, deswegen besser gleich Windows Server Datacenter lizensieren. Und einen oder mehrere für die eigentlichen Netzwerkverbindungen der Gäste. Ggf. mit Link Aggregation, falls Bandbreite benötigt wird. 10 GBE ist da auch eher zeitgemäß.

Dazu noch einen Backup-Server mit der 4 bis 10 fachen Kapazität des SAN (der kann dann gerne nen billiges S-ATA RAID 5 haben) mit Veeam drauf (für Hyper-V oder VM-Ware) und LTO-Laufwerk(e / Wechsler) drann und gut ists.

Aber auch mit deiner jetzigen Hardware würde ich knallhart alles virtualisieren. Hyper-V-Server drunter schmeißen und alle Server virtuell abbilden. Mal nachlesen, ob man deinen RAID-Controller auf Hyper-V Workload hin umstellen oder optimieren kann.
Allein schon aus Gründen der Sicherheit würde ich das machen. Man trennt mittlerweile möglichst viel voneinander. Storage vom Computing. Services vom Server. Storage-Volumes von den eigentlichen Disks. Server von der Hardware.

Musstest du schon mal einen kompletten Rebuild eines "gemischten Server" (Datenbank + Storage + ... am schlimmsten noch AD) machen? Weißt du, wie ätzend das ist, wenn dein Backup das Betriebsystem nicht ordentlich auf einer neuen Hardware wiederherstellen kann und man so etwas manuell samt Treibern neu installieren muss und dann die Daten in Datenbanken usw. teilweise manuell aus dem Backup übernehmen muss? Das dauert einfach irgendwann viel zu lange und ist sehr anfällig für Fehler.
Da ist ein aufsetzen eines Hyper-V Hosts und das Zurückspielen der virtuellen Maschinen aber so etwas von so sehr viel angenehmer... (Falls man nicht ohnehin einen Replikationspartner oder gar ein Failovercluster hat) Zudem skaliert eine virtuelle Umgebung einfach besser und man lastet die bezahlten Ressourcen viel effektiver aus.

 

[ichkriegediekri]

@ayngush

WoW, viele Punkte. Danke.

ner oder mehrer VHD(X)-Datei(en) benutzt, ist der I/O Workload auf der eigentlich darunter liegenden Hardware ein ganz anderer im Vergleich zu einem nativen Dateisystem. Da muss die Hardware und der Controller ggf. umkonfiguriert werden (falls möglich). Enterprise-SSDs gibt es auch für verschiedene I/O Workloads, ist halt die Frage, was da in euren Server steckt.

Ja das machen die Benchmarks deutlich :-). Aber von dem was ich so lesen ist der Hauptgrund der Hypervisor der ein Load-Balancing macht da auf einem Volume meherer VMs turnen können - das wird an der HW direkt nicht liegen denn die performt ja gut.

Zudem halte ich Raid 5 oder 6 alleine für den Main Storage in 2019 für nicht mehr zeitgemäß, die Reise geht (ging schon vor geraumer Zeit ) definitiv in Richtung Dynamic Disk Pools, die die Paritäten über logische Blöcke ganz anders als Raid 5 oder 6 auf den physikalischen Disks verteilen.

Ja das ist nicht falsch. Aber In der Kosten-Nutzen Rechnung zahle ich bei der Speichergröße für Storage-Spaces einfach deutlich mehr - wenn das Setup größer wird sieht die Rechnung dann anders aus anders.
Da mit den niedrigen UREs bei SSDs RAID 5 oder 6 kein No-Go mehr sind ist es eben nochmal ein HW RAID geworden - das wir aber in 5 Jahren wohl anders aussehen.

Zudem würde ich Storage und Server zukünftig dringend trennen, ......... also kein NAS sondern ein vernünftiges SAN in Betracht ziehen. Das ist ein himmelweiter Unterschied. Der SAN-Storage selber wird an die Hyper-V Hosts via redundanten SAS und round robin Lastverteilung mit Failover angebunden.

Würde ich gerne. SAN mit Failover ist aber nicht bezahlbar in dem Umfeld, das kriege ich nicht durch. Wenn Du mir eine solche SAN Lösung für unter 20.000€ zeigts inklusive SSDs/HDDs für knapp 30TB dann kann ichs mal versuchen.

Dazu noch einen Backup-Server mit der 4 bis 10 fachen Kapazität des SAN (der kann dann gerne nen billiges S-ATA RAID 5 haben) mit Veeam drauf (für Hyper-V oder VM-Ware) und LTO-Laufwerk(e / Wechsler) drann und gut ists.

keine chance im Budget....

Aber auch mit deiner jetzigen Hardware würde ich knallhart alles virtualisieren.

Deswegen ja schon mal die VMs für die 3 kleinen Server, das spart schon ca. 6.000€. Den File-Server virtualisieren wird denke ich nix da die Performance bei unserem Workload einfach mies ist - aber das war ja ursprünglich auch nicht geplant.
Der File-Server musste erneuert werden und bei der Gelegenheit habe ich einfach mehr CPU cores und RAM eingebaut um die anderen in eine VM zu stecken - das ist soweit schon mal eine deutliche Verbesserung. Und 4 NICs habe ich auch :-) - 1x 10GB FS, 1x 10GB Backup / Backup VM, 1x VMs, 1x RDP


Grundlegend gebe ich Dir wie xexex in nahezu jedem Punkt recht was das SAN und VM mit failover angeht.
Der Punkt sind hier eben die Kosten in Relation zu dem zu erwartenden Verlust im Falle eines Defektes - und genau hier steht man argumentativ mit dem Rücken an der Wand.
Grundlegend haben wir qualitativ gute HW und in den letzten 15 bis 19 Jahren gabs es nicht mehr als 4 Tage an denen ein Server offline war, und das nicht mal einen ganzen Arbeitstag. Es gab nie ein Datenverlust und wir haben mehr als 1 Backup je Server inklusive 2x/Woche cold/offline Backups (gilt nur bedingt für den FS da der Wochen für eine Sicherung benötigt) - dafür lohnt es sich nicht 30, 40 oder mehr tausend € auszugeben was wir ja in den 15 Jahren 2 bis dreimal hätten upaten müssen (also insgesamt nahe an die 100k€)


PS:

Weißt du, wie ätzend das ist, wenn dein Backup das Betriebsystem nicht ordentlich auf einer neuen Hardware wiederherstellen kann und man so etwas manuell samt Treibern neu installieren muss und dann die Daten in Datenbanken usw. teilweise manuell aus dem Backup übernehmen muss? Das dauert einfach irgendwann viel zu lange und ist sehr anfällig für Fehler.

Ja aber nur privat ;-)

 

[ayngush]

20 k müsste eigentlich machbar sein für ein kleines SAN.
Lass dir mal von euren Hardwarepartner / Systemhaus eine NetApp E-Series E2800 mit Dual Controller und quad Port SAS-Erweiterung (insgesamt dann 6 x 12 gbit/s SAS pro Controller-Board) mit 24 1,2 TB 10k SAS Platten anbieten. Das sollte so bei ~14k netto rauskommen zzgl. ggf. Supportverlängerung / Wartungsvertrag.
Dazu noch ein (oder mehrere) SAS-Boards mit 2 / 4 / 6 SFF-8644 Anschlüssen für den Server und entsprechend viele Zuleitungen (die kosten leider auch ein wenig).