m.2 SSD Upgrade für ESX Server

Supaman

Enthusiast
Thread Starter
Mitglied seit
10.06.2007
Beiträge
1.596
Ort
Dortmund
Hallo,

ich habe hier einen ESX Server mit ein paar VMs: DC1, DC2, Warenwirtschaft, TerminalServer für die Anwender, Mailserver für ~25 User, Datensicherung und Administration. Im Mittel arbeiten so 10-15 Benutzer auf dem System, also alles im überschaubaren Rahmen.

Hardware:
Supermicro Gehäuse mit redundantem NT
Supermicro x10-dri, dual CPU Board mit 2x Xeon-E5v3-2667 (je 8 Core / 16 Threads - 3,2 Ghz)
128 GB Ram
Raid Controller LSI 9361-8i
Raid-1 - 2,5" Sata SSD in 250 GB fürs ESX System
Raid-1 - 2,5" Sata SSD in 2 TB für die VMs
Raid-1 - 3,5" Sata 10 TB HDD fürs interne Backup

Der Server rennt schon oredentlich fix, aber seit einiger Zeit arbeiten die User verstärkt mit MS Teams und öffnen größere CAD Daten mit eDrawings (eine Art Adobe Reader für CAD Zeichnungen), da merkt man die Ladezeiten. Ist zwar jammern auf hohem Niveau, aber wie es halt so ist: Chefs sind ungeduldig.

SAS SSDs hatte ich in der Vergangeheit nicht genommen, weil der Aufpreis nicht im Verhältnis zur Mehrleistung stand bei meinem Anwendungs Szenario.

Da die m2 SSDs inzwischen extrem schnell geworden sind bin ich am überlegen, ob es einen Weg gibt die 2,5" Sata SSDs gegen m.2 SDD auszutauschen.
Inzwischen ist die Preisdifferenz zwischen einer 2TB SAS SSD zwar erträglich, aber die Leistungsdaten hängen halt deutlich einer m.2 SSD wie z.b. Crucial P5 hinterher.

Raid-1 muss weiterhin möglich sein, und bezahlbar sollte das auch sein.


Daher die Frage: welche Möglichkeiten gibt es ?

Add-on Card wie z.B. Supermicro 2x NVMe PCIe Karte mit Onboard Raid

Oder einen andren Raid Controller (welcher) ?


Gruß,

Supa
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Inzwischen ist die Preisdifferenz zwischen einer 2TB SAS SSD zwar erträglich, aber die Leistungsdaten hängen halt deutlich einer m.2 SSD wie z.b. Crucial P5 hinterher.
Das würde ich mal direkt verneinen.
Lass dich nicht von irgendwelchen Daten aus irgendwelchen Datenblättern verarschen.

Pack die SSDs mal bis zum Anschlag voll und dann reden wir nochmal über die Performance unter Serverbetriebsbedingungen.

SAS SSDs (bzw. Servergrade SSDs allgemein)
leben von:
- Robuste Performance in allen Lebenslagen
- Robuste Speicherzellen
- powerloss protection

Da es sich ja um ein Produktivsystem handelt, hoffe Ich mal, dass du mindestens Servergrade SATA SSDs eingebaut hast, zumindest für die VMs.
Ansonsten sollte du genau da ansetzen.

Das wären deine
M.2 Optionen
SAS Optionen
SATA Optionen

Wie du siehst, hast du da nahezu keine Auswahl was Servergrade angeht. Das liegt primär daran, dass keiner im Server M.2 verwendet, sondern U.2.
Des Weiteren ist das SATA/SAS Interface quasi noch der Standard und wird auch genommen. Und ja, das Zeug ist performant genug. Auch für deine doch recht überschaubare Anwendung.
Auch wenn es sich viel anhört, eigentlich ist da gar nichts los. Und mit der richtigen und soliden Hardware gibt es da keinen Grund auf M.2/NVMe zu gehen.

Des Weiteren sollte man auch nicht vergessen, dass so ne M.2 zum einen richtig Abwärme erzeugt, wo man also die Kühlung in so einer Add-in-Karte im Blick haben sollte und ein Defekt einer Einheit auf jeden Fall immer mit einer kompletten Serverdowntime verbunden ist.
Ne SAS/SAS/(U.2) SSD tauschst du noch bevor die Meldung auf dem Controllcenter hochgekommen ist.
Des Weiteren sollte man prüfen, wie eine Fehlermeldung vom NVMe Controller im ESX landet. Denn was bringt dir nen performantes System, wenn dir das Volume trotzdem verreckt, weil du nicht mitbekommen hast, dass es bereits seit 1 Jahr degraded lief.

Daher mein Tipp an dich, schau dir das nochmal intensiv an.

ggf. nochmal
durchschauen.
Der Kollege hat das selbe Problem.

PS: Nicht alles was man zu Hause in seiner Gaming-/Rumspielserverstation macht oder machen kann, sollte man bei einem Produktivsystem machen, am besten noch im single-node-hypervisor.
 
Vielen Dank für den ausführlichen Input, ich werde das mal gründlich durcharbeiten.


Die aktuelle Absicherung sieht wie folgt aus:
Schaltschrank eigene Versorgungsleitung mit eigener Sicherung
USV
2x redundante, modulare Server Netzteile
LSI 9361-8i mit Cache und BBU (bzw Kondensator Puffer bei dem Modell)
Power Loss SSDs / HDDs, alles als Raid-1
internes Backup (intern geht immer) + Spiegelung auf 2ten externen Datenspeicher

Zusätzlich identische Server Hardware als offline betriebsfertige Reserve Hardware.


Nochmal zur Anwendung:

Ja, es ist ein produktiv System. Es <sollte> nach Möglichkeit nicht Ausfallen, aber 1-2 Tage Downtime wäre immer noch im Rahmen.
Die o.g. Sicherungskette sollte für so ziemlich alles ausreichend sein, von daher habe ich bisher mit guten non-SAS / non-Enterprise
SSDs keine Probleme gehabt, weil die immer alle 2 Jahre gegen was größeres ausgetauscht worden sind.
Wenn es einen Raid Ausfall gibt, macht der Controller sich bemerkbar.

Bei m.2 wäre halt die Frage, WENN man den Weg gehen würde, wie man das mit Raid angeschlossen bekommt.
Oder U2, welche Bauformen / Controller man dann nimmt.


Gruß,

Supa
 
Broadcom hat Tri-Mode Controller im Angebot. Daran kannst du SATA/SAS/NVMe anschließen, in Grenzen auch gemixt.
Die haben einen 16i im Angebot, wo man dann 2x NVMe und 8x SATA/SAS machen könnte.
(oder halt zusätzlich zum Bestand...)

U.2 hängt halt mit einer Backplane zusammen, die die sicherlich haben wirst...
 
da fehlte ein nicht...

Siehe auch die Diskussion in dem anderen, verlinkten Thread.
U.2 Backplane kann man in dem Case ja nachrüsten...
 
bist du sicher dass die SSD der engpass ist? Und nicht die verarbeitung der daten?
 
Es gibt keinen direkten Engpass, mit 2x 8c / 16t @3.2 Ghz = 16 Kerne / 32 Threads für 6 VMs rennt das Ding schon ordentlich.
Aber wie es halt so ist, es kann immer noch einen ticken schneller gehen :)

Die Überlegung war ganz grob:
Eine Sata SSD macht ~550 mb Durchsatz, eine m.2 macht ~3500 read und 3000 write.

Wenn man für <1000 Euro den Durchsatz um den Faktor 5-7 erhöhen könnte, ist das ein gutes P/L Verhältnis und könnte das in Angriff nehmen.
 
deshalb frage ich. wie gross sind die entsprechenden zu öffnenden dateien?
ich würde mal vermuten, die verarbeitungszeit ist deutlich höher als die ladezeit der datei.
 
Und was sagt dir, dass die sequentielle Bandbreite das Problem ist? (wie schon angemerkt, versteifst du dich viel zu sehr auf diese Marketingzahlen)
Evtl. liegt es auch daran, dass, je nach SSD, die aufgrund eurer Nutzung die Handbremse anhaben?
Oder das es auch einfach zu viel für ein einziges Volume ist?
Evtl. würde schon ein 2. Volume massiv den Speed anheben?
Was ist mit dem Netzwerk? Wie ist der Uplink des Servers? 10GBE? 40GBE?
Was ist mit den Clients? Wie ist der Accessswitch angebunden?
 
denke wir diskutieren hier über die falsche komponente... CAD = Grafik = GPU.
und bei gpu und esx wirds teuer (was ich mit meinem beschränkten wissen rausgefunden habe).
 
Netzwerk ist können wir ausklammern. Alle System sind auf dem ESX intern mit der 10 GbE VMX3 angeschlossen. Die User arbeiten per RDP auf dem Server, das verursacht bei der geringen Anzahl nicht genug Traffic für einen Flaschenhals.

Das mit den CAD Daten zieht primär Hautspeicher, da ist genug Luft nach oben.
Was man halt merkt, ist der Start von MS Teams oder wenn der Chef sein Outlook startet,
weil er über mehrere Konten 50.000 Emails vorhält und die lokale Chache DB so 1,5 GB hat.

<Problem> ist vielleicht nicht die richtige Definition, ich würde es eher als System Optimierung betrachten.

Wenn ich die Möglichkeit habe, für erträglichens Geld einen ordentlich Boost einzubauen, nehme ich das gerne mit.
 
Hast du mal ein Monitoring bzw. Auswertung über die entsprechenden IOPS in solchen Situationen gezogen? Was für Modelle von SATA-SSDs sind verbaut? Wie sind die vorhandenen Resourcen auf die VMs verteilt?
 
Monitoring müsste ich mir mal ansehen. Verbaut sind aktuell 2xSamsung OEM Datacenter SSD PM883 1.92TB als Raid-1, dort liegen alle VMs drauf.
 
Das sind ordentliche Datacenter SSDs. Die haben bei uns auf dem CAD-Server mit Creo CAD einen ordentlichen Schub gebracht. Du musst halt wirklich mal die IOPS messen, die benötigt werden und dann der Leistung der SSDs gegenüber stellen. Nur so siehst du, ob es hier einen Flaschenhals gibt. Das kannst du sauber mit Paessler PRTG in der freien Version bis 100 Sensoren messen und auswerten. Hast du den Terminalserver mit zu vielen vCPUs versehen? Prüfe das Verhältnis mal. In dem Fall gilt nicht „viel hilft viel“.
 
Wie schon gesagt, es ist nicht so das das System tatsächlich langsam ist oder etwas klemmt.

Aber alles was < Echtzeit ist
(Mauslick - > Fenster IST offen, anstelle von 21... 22.. wird geöffnet),
wird halt als langsam bzw optimierungsfähig empfunden.
Sprich: 1st World Luxusprobleme.


Beispiel für sinnvolle Optimierung:
Bei der Anschaffung des Servers war das Ding mit 1x Xeon E5-2630v4 (10 core / 20 Threads @2,2 ghz) ausgestattet,
habe ich dann vor kurzem gegen 2x Xeon-E5v3-2667 (je 8 Core / 16 Threads - 3,2 Ghz) aufgerüstet.
Rechnerisch ein Boost von ca. +130% CPU Power für deutlich unter 1000 Euro.
Das hat man deutlich gespürt und war in Bezug auf P/L völlig ok.


Das Thema Massenspeicher hat man eben auch als potentiell optimierungsfähig im Auge:
Wenn das Anwendungs Szenario für ein SAN und vergleichbar hochgezüchtete Technologie zwar schön, aber etwas "oversized" (und damit kostenintensiv) wäre, beleuchtet man <mögliche> Optionen wie z.B. Raid-1 aus guten m.2 SSDs. Daher meine Frage :)

Bei geringen Userzahlen muss es nicht zwingend Enterprise Krempel im 5-Sterne Deluxe Preisegment sein, sofern ein paar Eckparameter eingehalten werden (USV, Raid-1, Backup etc).

Gruß,

Supa
 
By the Way:
Kauft euch ne Mailstore Lizenz!
Weg mit den Mails vom Outlook hin zum Archiv, das ist A. Rechtskonform was Mailarchivierung angeht und B. entlastet sowas den Exchange erheblich (Stichwort Outlook Start).
 
Was hat Mailstore mit dem Thema hier zu tun? Gar nichts. Im übrigen impliziert die Nutzung von Outlook als Client nicht zwingend einen Exchange als Backend, grade für KMU gibt es sehr gute Alternativen (Kerio Conenct, Mdeamon, Icewarp uvm).
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh