Neue Serverkonfiguration

[polytoxic]

Hallo zusammen,

bin neu hier und hoffe mit meiner Frage oder Fragen richtig zu sein.

Hintergrund:
Ich bin gerade dabei mir ein Server-Cluster zusammen zu stellen.
Ist:
Ubuntu 18.04 LTS 2-Node Cluster DRBD Corosync

Soll
Ziel Proxmox 3-Node HA-Cluster mit Ceph.

Meine Isthardware ist nun mittlerweile 6 Jahre alt und aufgrund von einigen Konstruktionsfehlern im Bezug auf Hardwareabstimmung und Clusteraufbau komme ich nun an die Grenzen meiner Möglichkeiten mit diesem Setup.
Grund war teilweise das Mischen von Consumer mit Server Hardware um Kosten zu reduzieren. Aber auch und darauf komme ich noch zurück den Zusammenbau und auf Setup der Server zu erleichtern. Kein HBA kein Hot-Swap und auch keine Backplane / Expander usw.

______________________________

Nun bräuchte ich Hilfe im Bezug auf die Konstruktion. Im speziellen bei der Abstimmung Chassis / Backplane / HBA / NVMe
Hier fehlt mir Detailwissen, da ich hiermit noch nichts gemacht habe.

Chassis:
Ich brauche ich ein EATX Chassis mit Backplane die NVMe möglich macht.
Ich benötige zu beginn 4 nvme die ich bis auf 8 ausbauen kann.
Ich hatte noch keine NVMe in der Hand.
Welches Kabel geht von NVME zur Backplane?
Mit welchem SFF- Kabel wird Backplane mit HBA verbunden?
Brauche ich überhaupt einen HBA?
Oder gibt es die Möglichkeit Backblane mit Motherboard ohne HBA mit vollem Durchsatz zu verbinden?

Als Nvme dachte ich folgende
3200GB Micron 9300 MAX sequentiel (r/w 3500/3100)
Hier stellt sich mir die Frage, wie viele Platten hänge ich auf einen HBA 4.0 16x mit 31,5 GB/s das durch die Schnittstelle möglich ist?
write 3100*8/1000=24,8 GB/s
Wenn ich mit der sequentiellen Möglichkeit rechne, nutze ich ja schon fast mit einer Platte die volle Bandbreite des PCI 4.0 16x.
Oder habe ich einen Rechenfehler oder gar Denkfehler?
Wenn dem so ist, welche Option habe ich alles aus 4 Platten als Ceph-Pool herauszuholen?

Gibt es eine HBA Empfehlung von euch?

Vielen Dank für eure Hilfe

 

[underclocker2k4]

write 3100*8/1000=24,8 GB/s
Wenn ich mit der sequentiellen Möglichkeit rechne, nutze ich ja schon fast mit einer Platte die volle Bandbreite des PCI 4.0 16x.
Oder habe ich einen Rechenfehler oder gar Denkfehler?

Du hast einen großen Rechenfehler. Wie kommst du auf die Formel?
Die SSD macht ~3000MB/s = 3GB/s.
Ein PCIe x16 4.0 macht ~32GB/s
32GB/s / 3GB/s/Platte = ~11 Platten

Ergo 11 Platten pro x16 Slots, was die Bandbreit anbelangt.

Für alles weitere könnte man jetzt 8h Vortrag abhalten über NVMe, U.2, Steckern, Slots usw.

Die Frage ist doch, wo soll denn die Performance hin.
32GB/s (wenn man jetzt mal 1 x16 Slot nimmt) sind 256Gigabit/s.
Mit welcher NIC und welchem Switch willst du den Cluster aufbauen?
Ist dir bewusst, dass der die genannte SSD 20W Leistungsaufnahme hat? Sprich bei 10 SSDs sind wir bei 200W nur für die SSD, ggf. bei nur einem Server.

 

[polytoxic]

I

Du hast einen großen Rechenfehler. Wie kommst du auf die Formel?
Die SSD macht ~3000MB/s = 3GB/s.
Ein PCIe x16 4.0 macht ~32GB/s
32GB/s / 3GB/s/Platte = ~11 Platten

Du hast recht, irgendwie habe ich mbit mbyte gbit und gbyte verdreht.
So ergibt das schon mehr Sinn.
Kannst du mir hier einen HBA empfehlen?

Für alles weitere könnte man jetzt 8h Vortrag abhalten über NVMe, U.2, Steckern, Slots usw.

Ich möchte die Hot-Swap in der Front nutzen.
Die SSD hat U.2 Anschluss

Die Frage ist doch, wo soll denn die Performance hin.
32GB/s (wenn man jetzt mal 1 x16 Slot nimmt) sind 256Gigabit/s.
Mit welcher NIC und welchem Switch willst du den Cluster aufbauen?

Viele Cores hohe Taktung und Read and Write mit viel IOPS.
Es wird eine DUAL 100Gbe Nic von Mellanox werden.
Die Knoten sollen mit Full Mesh verbunden werden, um Latenz und Kosten niedrig zu halten.
Dieses Setup möchte ich nutzen für:
MSSQL zeitgleicher Zugriff von ca. 20 Nutzern über ACCESS
Linux-AD-Controller.
Fileserver.
LXC Container - Interne Cloud, Grafana, Zammad, 3CX-SBC usw.
Und ein paar WIN-Clients zur nutzung als Terminalsession.

Mir ist bewusst, dass ich mich im Bezug auf die Skalierbarkeit erstmal einschränke.
Es ist nicht vorgesehen, dass das Cluster um weitere Knoten erweitert wird.
Wenn doch, ist das Nachkaufen des Switches immer noch möglich.

Ist dir bewusst, dass der die genannte SSD 20W Leistungsaufnahme hat? Sprich bei 10 SSDs sind wir bei 200W nur für die SSD, ggf. bei nur einem Server.

Ja das ist mir bewusst.
Das Netzteil darf je Node ruhig 1000Watt haben.
Das ganze ist nicht für den Privatbereich gedacht.

Bisher hatte ich aufgrund meines falschen Setups das Problem, dass irgendwann die Performance einbricht.
Trotz aktiv-aktiv Cluster auf zwei Knoten.
Zu wenig Kerne für die Anzahl der VMs.
Und da mein Storage intern falsch aufgebaut ist.
HDD teilweise einzeln per DRBD gespiegelt. Hier hatte ich noch nichts mit LVM oder ZFS gemacht und RAID10 gemacht.

Dadurch bin ich gezwungen den nächsten Schritt zu gehen.
Nach dem Motto jetzt erst recht.

_____________________________________________________________________

Zu den weiteren Komponenten

Gigabyte Mainboard MZ72-HB0​

2xAMD EPYC 7402 24/48T 2,8GHZ
oder
2xAMD EPYC 7302 16/32T 3,0GHZ

128GB EEC 3200MHZ

Anfangs war ich bei dem Mainboard von Supermicro
H11DSi-NT Rev2.0
unterstützt allerdings "nur" PCI 3.0/3.1

Ich wollte auf PCIE4 gehen um die Anzahl der HBAs so gering wie möglich zu halten.



Gibt es anhand dieser Infos, eine Empfehlung bzgl Chassi?
Supermicro / Chenbro ?
Ich werde da nicht ganz so schlau im Bezug auf NVMe kompatibilität.


Vielen Dank

 

[underclocker2k4]

Also deine Anforderungen benötigen kein NVMe. Da reicht ein SATA bzw. SAS full flash auch vollkommen locker aus.
SATA/SAS würde die Möglichkeiten nach Cases ca. Faktor 1000 erhöhen.

Supermicro kann NVMe nur mit Cases und proprietären Boards.
Chenbro hat nur ein RM23824, was full NVMe bzw. mix NVMe + SAS kann. Die Backplane besteht aus mehreren Modulen, die man flexibel zusammenstellen kann. Nachteil, 2HE Case mit low profile Slots...
Dazu einfach mal das Datasheet vom Case anschauen.

Allerdings muss man sich dazu an einen Fachhändler wenden, (z.B. Krenn oder Sono usw.) Da man die nicht so einfach bekommt.
Die haben dann einen OCuLink-Anschluss. Dein MB hat bereits ein paar NVMe@SlimSAS, die man dafür, ohne HBA, verwenden könnte.

Ansonsten, weil extrem flexible, ein Standardcase nehmen mit sowas bestücken:
z.B.

ToughArmor MB699VP-B

icydock.de

Kannst du dann einbauen wieviel du willst. Extreme flexible. Kannst daher im Case auch 3,5" für irgendwas anderes einbauen, je nach Platz und Wunsch.
3U/4U Cases können auch high profile Karten aufnehmen. Allerdings sind die dann oft nicht aus Panzerstahl, muss man also wissen.

Ansonsten mal in meinen Beiträgen von ein paar Tagen schauen, da habe ich an anderer Stelle was zum Thema Storage gesagt. Gibt dir evtl. nochmal ein paar Ansätze.

PS: Ansonsten kann auch ein Systemhaus ein sinnvoller Ansprechpartner sein. Die stellen dir dann nach deinen Anforderungen die Konfigs zusammen mit Support etc.

 

[polytoxic]

Vielen Dank für deine Rückmeldung und ausführliche Empfehlung.

Also deine Anforderungen benötigen kein NVMe. Da reicht ein SATA bzw. SAS full flash auch vollkommen locker aus.
SATA/SAS würde die Möglichkeiten nach Cases ca. Faktor 1000 erhöhen.

In welchen Use-Cases wäre dann NVMe sinnvoll?
Ich dachte aufgrund der höheren IOPS beim SQL-Server.
Hier habe ich trotz in diesem Fall schon vorhandenen SSD performance Probleme.
Allerdings ist es eine consumer SSD und nur einzeln und nicht im RAID10 o.ä.

Nochmals Danke

 

[MisterY]

ich denke ein ZFS striped mirror aus enterprise SSDs mit SATA/SAS würden da enormen Geschwindigkeitsschub versprechen. Was hast du sonst an Hardware aktuell in Verwendung?

 

[polytoxic]

Ansonsten, weil extrem flexible, ein Standardcase nehmen mit sowas bestücken:
z.B.

ToughArmor MB699VP-B

icydock.de

Diese Idee finde ich wirklich gut.
Das passt dann nur in ein 4u?

Dein MB hat bereits ein paar NVMe@SlimSAS, die man dafür, ohne HBA, verwenden könnte.

Kann ich dann von dem ICY vom SFF-8643 Port direkt aufs Board?

• 3 x SlimSAS (with 12 x SATA 6Gb/s or 3 x NVMe PCIe Gen4 x4) ports
• 2 x SlimSAS (with 2 x NVMe PCIe Gen4 x4) ports

Wenn ich es richtig verstehe, habe ich in der Summe 5Ports. Mit jeweils 4.0 x4 also 7,88 gb/s pro Anschluss?
Sind dann hier 5 Ports = 5 Platten?

Ich benötige aber dann zwei verschiedene Kabel von Icy zu MoBo oder.
Anbei ein Screenshot zu dem was ich meine.

Vielen Dank

 

[MisterY]

Als ich mich damals mit SP3 beschäftigt hatte, fand ich das neueste Asrock Rack board das beste. Gab es da Neuerungen?

 

[polytoxic]

ich denke ein ZFS striped mirror aus enterprise SSDs mit SATA/SAS würden da enormen Geschwindigkeitsschub versprechen. Was hast du sonst an Hardware aktuell in Verwendung?

Dort war ich mit meinem Gedanken am Anfang auch.
Aber ich dachte mit diesem Setup sollte ich genug Luft nach oben haben und erstmal an keine Grenzen stoßen.

Das jetzige Setup ist mit dem was ich neu anpeile absolut nicht zu vergleichen.

1x Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz
64gb RAM

DRBD-Dev0
4tb WD-HDD RED gespiegelt über 1GB Nic

DRBD-Dev1
Samsung MZ-76P1T0B/EU 860 PRO 1 TB über 10GB Nic

DRBD-Dev2
Samsung MZ-76P1T0B/EU 860 PRO 1 TB über 10GB Nic

 

[underclocker2k4]

Vielen Dank für deine Rückmeldung und ausführliche Empfehlung.

In welchen Use-Cases wäre dann NVMe sinnvoll?
Ich dachte aufgrund der höheren IOPS beim SQL-Server.
Hier habe ich trotz in diesem Fall schon vorhandenen SSD performance Probleme.
Allerdings ist es eine consumer SSD und nur einzeln und nicht im RAID10 o.ä.

Nochmals Danke

Wenn die Firma um Faktor 1000 gewachsen ist.
Wir haben hier über 100 VMs auf einem iSCSI HDD Storage laufen. Das ist natürlich nicht so supersmooth.
Ich glaube nicht, dass dein SQL solche hohen IOPs hat, wenn da 20 User mit normalen Anwendungen drauf arbeiten.
Ich glaube du überschätzt massiv den Bedarf deiner Applikationen. (das müsste man sich aber anschauen, ich kenne die Applikation nicht)

Enterprise SSDs sind Enterprise SSDs und der Name Enterprise ist da Programm.
So Faxen-Geräte wie die genannte Samsung SSD baut man maximal in sein Notebook, mit dem man den Cluster administriert.

Das Icy Dock passt nicht nur in 4U, geht auch 3U oder auch 2U. Du brauchst halt Standard 5,25" Slots. Dazu einfach mal ein wenig bei z.B. Geizahls.de schauen und schauen was da wie geht. mehr Slots = mehr Platz = mehr "U"

Alle Anschlüsse auf dem Board sind SlimSAS aka SFF-8654. Du brauchst also ein Kabel SlimSAS auf miniSAS-HD aka SFF-8654 nach SFF-8643.
Ansonsten passt das erstmal grob mit 5 Ports = 5 Platten.
Man kann aber auch da Breakoutkabel nehmen, die dann natürlich die PCIe Lanes per Drive reduzieren. Das würde ich mir aber wirklich überlegen...

 

[MisterY]

Ich denke, dass die IOPS von gescheiten SSDs im ceph-ZFS verbund ausreichend hoch sein sollten. Wichtig ist hierbei, meiner Meinung nach, auch ordentlich RAM, da ZFS ja viel im RAM vorhält. Also 3 Systeme mit über 128 GB RAM und Ceph ist schon sehr brachial.

Das ist beispielsweise von meinem R620 mit einem ZFS mirror aus zwei Evo 860 und 96GB Ram:

root@r620:/# pveperf rpool
CPU BOGOMIPS:      115236.00
REGEX/SECOND:      1666179
HD SIZE:           223.76 GB (rpool)
FSYNCS/SECOND:     14959.18
DNS EXT:           36.50 ms
DNS INT:           2.11 ms (home.lab)

Ich muss dazu sagen, dass ich sync disabled habe.

 

[polytoxic]

Wenn die Firma um Faktor 1000 gewachsen ist.
Wir haben hier über 100 VMs auf einem iSCSI HDD Storage laufen. Das ist natürlich nicht so supersmooth.
Ich glaube nicht, dass dein SQL solche hohen IOPs hat, wenn da 20 User mit normalen Anwendungen drauf arbeiten.
Ich glaube du überschätzt massiv den Bedarf deiner Applikationen. (das müsste man sich aber anschauen, ich kenne die Applikation nicht)

Ich denke, dass die IOPS von gescheiten SSDs im ceph-ZFS verbund ausreichend hoch sein sollten. Wichtig ist hierbei, meiner Meinung nach, auch ordentlich RAM, da ZFS ja viel im RAM vorhält. Also 3 Systeme mit über 128 GB RAM und Ceph ist schon sehr brachial.

Ok sicherlich ist es so wie Ihr schreibst, dass ich das überschätze. Das ist mir bei diesem Setup durchaus auch bewusst.
Bezüglich der consumer stimme ich ebenfalls zu, dass ist mir auch bewusst.
Deshalb ja auch der komplette Wandel. Tausend Flaschenhäse die in dem alten Setup nicht zu beheben sind und auch wirtschaftlicher unfug wären.
Ich hatte ein SSD Setup auch schon konfiguriert.
Das waren die unten genannten Platten im Vergleich. Da war Preislich nicht viel um. Bei wesentlich schlechterer lifetime (Samsung DWPD1) im Vergleich zu DWPD 3 bei den Microns.
Dann gäbe es noch die Intel die bei gleicher Kapazität bessere lifetime haben. Performance allerdings die schlechtesten im Bunde und preislich pro Node ca. 400-600€ ersparnis.
Somit dachte ich dann mit Kanonen auf Spatzen is jedenfalls ein Volltreffer
Der Vorteil von NVMe auf SSD war noch das eventuel 10GB Nics im Full Mesh reichen könnten.
Das wäre auch ein direkter Preissprung.

3840GB Samsung PM1643​

3840GB Intel D3-S4610​

3200GB Micron 9300 MAX​

Eventuell gehe ich mit den CPU runter von 7402 auf 7302.
Hälfte an Preis und immernoch genug.

 

[underclocker2k4]

Falsch macht man mit NVMe erstmal nichts. Nachteil ist halt, man braucht spezielle Backplanes und (RAID)Controller.
SATA/SAS SSDs sind da eben wesentlich flexibler.
Du kannst direkt am Controller RAID aufbauen und mit 2,5"/3,5" HDDs im richtigen ServerCase easy mixen und gerade bei extrem hoher Anzahl ist das wesentlich einfacher. Versuch mal nen HPE Apollo 4200 48SFF mit NVMe zu bauen...
Dafür ist SATA stark beim Speed begrenzt. SAS ist da schon deutlich schneller. Die machen gerne mal 2GB/s mit amtlichen IOPS.

NVMe ist halt die Brechstange, mit den genannten Nachteilen.

 

[polytoxic]

Also dein Vorschlag mit dem ICY ist der, der mich bisher am meisten Überzeugt.
Klar bin ich begrenzt im Bezug auf Storage ausbaufähigkeit im Vergleich zu dem aufgezeigten Apollo.
Der ist ja gewaltig und auch vorstellbar, dass es hier keine vernünfte Lösung für allNVMe so ohne weiteres gibt.

Aber diese Anzahl an Slots werden wir voraussichtlich nicht erreichen.
Als Start 12TB über 4 Slots mit ICY und das dann mit einer zweiten ICY über einen HBA später auf 24TB erweitern.
Oder kannst du dir vorstellen, dass das zu einem Problem führen könnte.
Die 4 internen ports für einen Dock verwenden und später auf den zweiten Dock dann mit einem HBA zu arbeiten?
Müssten ich dann beide Docks auf ein HBA legen?

 

[Toupman]

Gerade bei SQL ist RAM viel wichtiger als IOPs.

Wir schauen bei unseren wichtigen Servern immer darauf, dass die DB komplett in den RAM passt. Das hilft am meisten.

 

[underclocker2k4]

@polytoxic
Das einzige Problem was ich bei der ICY Dock sehe, ist dieser Krüppellüfter.
Die halten in der Regel jetzt nicht so ultimativ viel aus. Wie das bei 80W Abwärme mit der Temp aussieht, weiß ich auch nicht.
Ansonsten haben die SSDs erstmal nichts miteinander zu tun, da du das Storage eh auf OS Ebene erledigt, ist die HW erst recht 3x unabhängig.

Es gäbe dann noch sowas.

IB-2242U2K

Ist aber ähnlich.

Viel mehr ist mir in dem Bereich nicht bekannt.

Für SATA/SAS gäbe es dann sowas:

ToughArmor MB508SP-B

icydock.de

oder sowas

ToughArmor MB516SP-B

icydock.de

Mit genug Kapazitäten und 80mm Lüfter, den man auch easy gegen was ordentlichen tauschen könnte.
Dafür eben begrenzter Speed.

Achso, noch ein Hinweis, diese abstrusen Transferraten bei SAS SSDs gehen nur mit Dual Link SAS. Das können diese Backplanes eher selten.

Ansonsten bin ich auch bei @Toupman
Wir bauen in unsere Server immer 64GB Riegel ein, ggf. auch 128GB.
Bei deinen 16 Slots wären das dann also 1TB RAM.
Gerade bei Datenbanken gilt: Ram ist durch nichts zu ersetzen, außer durch mehr RAM.

Selbst mein @home Quadcore SpielESX hat 128GB RAM...

 

[polytoxic]

Gerade bei SQL ist RAM viel wichtiger als IOPs.

Wir schauen bei unseren wichtigen Servern immer darauf, dass die DB komplett in den RAM passt. Das hilft am meisten.

Ja ich richte den RAM in der Größe der Datenbank aus.
Das habe ich im alten System schon so gemacht.

 

[Falo999]

Gerade bei SQL ist RAM viel wichtiger als IOPs.

Wir schauen bei unseren wichtigen Servern immer darauf, dass die DB komplett in den RAM passt. Das hilft am meisten.

Naja das die DB in Ram paßt ist aber eher die die Ausnahme zumindest bei unseren Kunden.

Wir geben den MSSQL Server auch nur selten mehr als 96GB.
Auch nutzen bei uns die meisten Kunden unter 100Usern auch heute nochkeine SSD sondern noch phsikalische HDD's dann alledings als Raid 10 auf meist 8+ 2,5" 15K SAS HDD's.

Unter MSSQL haben wir auch kaum einen nenneswerten Performance boost (wir testen mit HammerDB) aus unseren HP-Servern zwischen SSD-Raid und dem Raid10 aus den 15K HDD festgestellt.

Erst bei den großen Kunden die dann nicht mehr MSSQL sondern Oracle als DB haben können die SSD ihren Vorteil wirklich ausspielen..

 

[polytoxic]

Denkst du im Bezug auf Performance macht es einen Unterschied auf welchen Betriebsystem der SQL-Server betrieben wird?
Ob Server oder bsp. Win 10 Pro?

Beitrag automatisch zusammengeführt: 12.03.2021

Unter MSSQL haben wir auch kaum einen nenneswerten Performance boost (wir testen mit HammerDB) aus unseren HP-Servern zwischen SSD-Raid und dem Raid10 aus den 15K HDD festgestellt.

Ich meine hier gelesen zu haben, dass SSDs im RAID10 sich nicht wirklich multiplizieren, was das schreiben und lesen anbelangt.
Teilweise sollen diese einzeln sogar performanter sein als im RAID10 Verbund. Der wirkliche Vorteil sollte bei den SSDs im Vergleich zu SAS3 HDD bei den IOPS liegen und ja Steigerung aber nicht zwingend wesentlichen bzgl read and write führen.
Wenn ich alles richtig interpretiert habe.

Das war auch der Grund, basierend auf der obigen Annahme, warum ich auf CEPH gehen möchte. Da man hier ebenso performanter werden sollte, mit Steigerung der Anzahl an physikalischen Platten.

Beitrag automatisch zusammengeführt: 12.03.2021

Erst bei den großen Kunden die dann nicht mehr MSSQL sondern Oracle als DB haben können die SSD ihren Vorteil wirklich ausspielen..

eventuell wegen den IOPS?

 

[Toupman]

Also unser wichtigster SQL Server mit dem ERP System drauf hat 8 Cores und 128GB RAM. Dazu läuft das ganze auf einem Flash-Only S2D Cluster.
Und das rennt wie sau.

Wenn da irgendetwas zwischendurch mal langsam ist, liegt es zu 99% an suboptimalen Abfragen oder fragwürdigen Programmierungen.