Server Design für eine Proxmox VDI Umgebung

kepno

Renowned Member
May 11, 2015
3
0
66
Hamburg
www.cen.uni-hamburg.de
Hallo,

wir möchten eine alte Thin Client Infrastruktur in unseren Seminarräumen ersetzen. Es handelt sich hier um 150 Arbeitsplätze. Auf den Thin Clients müssen Windows und Linux Workstations zur Verfügung gestellt werden. Nach vielen Tests fiel die Wahl auf Proxmox um die virtuellen Desktops bereitzustellen ...

Unsere Idee ist es, ein HA Cluster mit Proxmox und DRBD9 aufzubauen. Als Richtwert haben wir einen realen Core pro User vorgesehen. Damit sind wir bei folgender Ausstattung gelandet:

5 x Server mit je

2 x 14 Core CPU
384 GB RAM
2 x SSD für das OS
2 x SSD für Metadaten
10 x 4TB HDD für DRBD9 / Platz für VMs / RAID 5​

10GB Netzwerk für DRBD Kommunikation​

Bei der Planung wurden viele Fragen diskutiert:
  • Macht diese Konfiguration überhaupt Sinn?
  • Baut man DRBD9 über 5 Server auf oder baut man nur in 3 Server HDDs ein und nutzt die beiden übrigen nur zur Bereitstellung weiterer Cores?
  • Wäre es von Vorteil kleinere HDDs einzusetzen, z.B. 24 x 2TB anstelle 10 x 4TB? Welchen Einfluss hat das auf die Performance?
Wie sind Eure Ideen, Erfahrungen und Gedanken dazu? Kennt ihr White-Papers, Blogs u.s.w. zu ähnlichen Themen, die über das 2 oder 3-Node Cluster hinausgehen?


Danke & viele Grüße
Olaf
 
Hallo Olaf,

Macht diese Konfiguration überhaupt Sinn?

Ich glaube DRBD skaliert nicht gut mit so vielen Maschinen, vielleicht wäre Ceph eher was für euch (wenn es lokale Platten sein müssen). 2xSSD fürs OS ist überbewertet, das spürt man nur beim Booten, denn Logdateien und die paar Konfigurationsänderungen sind vernachlässigbar. Mehr beim nächsten Punkt.

Baut man DRBD9 über 5 Server auf oder baut man nur in 3 Server HDDs ein und nutzt die beiden übrigen nur zur Bereitstellung weiterer Cores?

Hier muss man erstmal trennen zwischen Storage Cluster und Compute/VM Cluster. Wenn man nicht überall die Daten haben will wäre es vielleicht geschickter das Storage komplett auszulagern, z.B. Multipath-iSCSI oder Multipath-FC SAN bauen. Der Bau eines Multipath-iSCSI über 10GBit kann man prima auch unter Debian erledigen, wenn man Hardware hat, die multipath-Festplattenanbindung hat. Also man schließt dort einen Käfig mit vielen Platten an zwei Rechner an, die dann die Daten via iSCSI über mehrere Wege an den Cluster verteilen. Alternativ kann man sich so ein Teil natürlich auch kaufen, ist dann natürlich teurer als "selbst machen" - je nach dem wo die Präferenzen liegen.

Wichtig bei so einer Entscheidung ist auch immer wie hochverfügbar alles sein soll. In deinem Beispiel mit DRBD überall hättest du die Daten bei wirklicher 5:1 Spiegelung überall und das System wird die Last nicht aushalten können, da jeder Block auf jedem System synchron geschrieben werden muss. Das ist schon enorm. Die SSDs für die Metadaten machen es schneller, aber synchrones Schreiben auf 5 Rechner dauert einfach etwas.

Wenn man auf weniger Knoten die Platten verteilt wird das DRBD natürlich schneller, da weniger Traffic und weniger Wartezeiten, aber man hat auf den Storage-Knoten dadurch mehr Last. Frage ist dann auch noch wie man die Daten von da aus verteilt bekommt, denn z.B. NFS ist nicht clusterfähig und man müsste dann auf den Storage-Knoten iSCSI aufbauen zum exportieren und dann Clusterweit importieren (also auch da wo die Daten eigentlich liegen, sodass die VMs schön migriert werden können).

Wäre es von Vorteil kleinere HDDs einzusetzen, z.B. 24 x 2TB anstelle 10 x 4TB? Welchen Einfluss hat das auf die Performance?

Ja, Performance ... so viele Spindeln wie möglich ... immer ... oder gleich alles SSD. Die meisten SAS/SATA-basierten SSD Arrays sind immer noch durch den Bus beschränkt, daher kann man mit "wenigen" SSDs den gesamten Bus bereits ausreizen. Bei festplattenbasiertem Speicher immer auf kleinere, schnellere Platten Anstelle von groß und gähnend langsam setzen (natürlich in dem Anwendungsfall, für Backup ist das wieder was anderes).

Ich würde auf keinen Fall SATA-Platten dafür verwenden (natürlich auch keine NL-SAS), 10 Platten sind einfach zu langsam für 150 Clients. Die 2,5'' Serverplatten mit 15krpm haben schon ihre Daseinsberechtigung. Dein Bottleneck wird definitiv im Storage hier liegen.

Und die andere Frage ist dann natürlich auch immer das Geld, wieviel ist man bereit auszugeben oder mit welcher festen Obergrenze muss man rechnen.

Ich hoffe ich habe dich jetzt nicht mehr verwirrt :-D
 
Hallo,

wir möchten eine alte Thin Client Infrastruktur in unseren Seminarräumen ersetzen. Es handelt sich hier um 150 Arbeitsplätze. Auf den Thin Clients müssen Windows und Linux Workstations zur Verfügung gestellt werden. Nach vielen Tests fiel die Wahl auf Proxmox um die virtuellen Desktops bereitzustellen ...

Unsere Idee ist es, ein HA Cluster mit Proxmox und DRBD9 aufzubauen. Als Richtwert haben wir einen realen Core pro User vorgesehen. Damit sind wir bei folgender Ausstattung gelandet:

5 x Server mit je

2 x 14 Core CPU
384 GB RAM

Hi Olaf,
bis hier hin klingt es sehr gut für mich
2 x SSD für das OS
2 x SSD für Metadaten
10 x 4TB HDD für DRBD9 / Platz für VMs / RAID 5
bei 4TB disks würde ich niemals raid-5 einsetzten. Ein recovery dauert zu lange und wenn in der Zeit eine zweite Platte stirbt, was durch das erhöhte IO nicht abwegig ist, sind alle Daten futsch... OK, dafür gibt es natürlich das DRBD ;)
10GB Netzwerk für DRBD Kommunikation​

Bei der Planung wurden viele Fragen diskutiert:
  • Macht diese Konfiguration überhaupt Sinn?
  • Baut man DRBD9 über 5 Server auf oder baut man nur in 3 Server HDDs ein und nutzt die beiden übrigen nur zur Bereitstellung weiterer Cores?
  • Im Falle von DRBD9 bekommst Du aber die Daten nicht auf die festplattenlosen Maschinen - dann benötigst Du eine Zwischenschicht wie NFS/iSCSI und dann darf man die DRBD9-auf Proxmox-Lösung durchaus in Frage stellen
  • Wäre es von Vorteil kleinere HDDs einzusetzen, z.B. 24 x 2TB anstelle 10 x 4TB? Welchen Einfluss hat das auf die Performance?
4TB-Platten sind im Random-Access nicht wirklich wahnsinnig schnell - da gewinnt man natürlich mit kleineren (und schnelleren) Platten. Die von LnxBil favorisierten 15K-Platten sind deutlich auf dem Rückzug - die gibt es kaum noch (wegen SSDs).
Was hälst Du von einem Raid-Controller mit eingebauten SSD-Cache (evtl. statt Metadaten-SSD). Damit sollte, zumindestens in der Theorie, die Balance zwischen Platz und Performance machbar sein.
Wie sind Eure Ideen, Erfahrungen und Gedanken dazu? Kennt ihr White-Papers, Blogs u.s.w. zu ähnlichen Themen, die über das 2 oder 3-Node Cluster hinausgehen?
DRBD9 ist einfach zu neu... ich glaub' da gibt's nicht viel.

Udo
 
Je nachdem ob und durch wen ein System zertifiziert sein muss, könnte man auch zu gebrauchter Hardware greifen. Ich selbst mache das sehr gerne um Hochverfügbarkeitsszenarios recht günstig realisieren zu können. Dort bekommt man die 15k Platten nachgeschmissen und kann sich die Hardware bei den günstigen Preisen auf Halde legen. Das muss aber zum Projekt/Kunden/Einsatzgebiet passen.

Wenn man Ceph einsetzen würde könnte man das System horizontal Skalieren wenn ihr mal merkt, dass es eng wird. Oder auch mit weniger Kisten starten und schauen wie gut es läuft.

Gibt so viele Möglichkeiten :-/
 
Danke für Eure ausführlichen und hilfreichen Antworten!

Bevor ich auf die einzelnen Antworten eingehe, will ich unser Projekt noch etwas umreissen:

Wir haben hier eine Sun Ray Infrastruktur mit ca. 150 Geräten in mehreren Seminarräumen. Diese soll jetzt abgelöst werden. Unser Ziel ist die Bereitstellung von 150 virtuellen Windows und 150 Debian Workstations die über Spice und Remote Viewer wahlweise an den Thin Clients genutzt werden können. Auf den virtuellen Workstations werden Programmierübungen, einfache Simulationen u.s.w. durchgeführt. Für anspruchsvolle Arbeiten gibt es grosse Cluster Systeme. Die Home Directories liegen auf einem zentralen Filer, Daten aus Simulationen liegen auch auf anderen Systemen. Grosse Datenmengen werden auf den Proxmox Cluster also nicht verwaltet.


Ich glaube DRBD skaliert nicht gut mit so vielen Maschinen, vielleicht wäre Ceph eher was für euch (wenn es lokale Platten sein müssen).

DRBD9:
Gerade hier wären Erfahrungen interessant! Anscheinend hat sich hinsichtlich der Performance und geringerer Latenz in DRBD8.x gegenüber DRBD9 viel getan (http://www.linux-magazin.de/Ausgaben/2015/07/DRBD-9) Vielleicht ist RDMA hier auch eine interessante Option (Lizenzkosten?) Erfahrungsberichte mit grösseren Clustern scheint es nicht zu geben oder ich habe sie schlichtweg nicht gefunden.

Nun zu Ceph:
Bei Ceph haben wir die Erfahrung gemacht, dass es erst bei mehr als 8 bis 10 Servern Spass macht. Gerade im Fehlerfall ist ausserdem der Bedarf an RAM und CPU Leistung wichtig. Ich nehme an, dass wir bei der Verwendung von Ceph deutlich mehr Cores und RAM (und Geld) benötigen. Deshalb haben wir bei unseren 5 Servern diesen Weg nicht weiter verfolgt.

Der Bau eines Multipath-iSCSI über 10GBit kann man prima auch unter Debian erledigen, wenn man Hardware hat, die multipath-Festplattenanbindung hat.

Ja, eine iSCSI Lösung wäre durchaus eine Alternative, wenn wir hier die DRBD9 Geschichte verwerfen.

Im Falle von DRBD9 bekommst Du aber die Daten nicht auf die festplattenlosen Maschinen - dann benötigst Du eine Zwischenschicht wie NFS/iSCSI und dann darf man die DRBD9-auf Proxmox-Lösung durchaus in Frage stellen
Die Redundanz von 5 bei 5 Servern mit DRB9 ist mir eigentlich auch zu hoch. Die Redundanz von 3 würde ausreichen. In 3 Maschinen Platten einzubauen war ein Gedankenfehler ...

Ja, Okay, der Einsatz von vielen kleineren Platten macht Sinn. Allein der "Verlust" bei Raid10 und einer Redundanz von 5 bei DRBD9 macht mir Bauchschmerzen ;)

Je nachdem ob und durch wen ein System zertifiziert sein muss, könnte man auch zu gebrauchter Hardware greifen.
Ein Einsatz von gebrauchter Hardware wäre in diesem Fall keine Option. Wir haben hier schon unsere Erfahrungen gemacht. Ein Ceph Cluster mit 480 "gebrauchten" HDDs - Da musst man so oft ins RZ laufen :)

Ich würde auf keinen Fall SATA-Platten dafür verwenden (natürlich auch keine NL-SAS), 10 Platten sind einfach zu langsam für 150 Clients.

Die Idee war, dass jeder der 5 Server jeweils 30 Clients zu Verfügung stellt. Damit hätte ich nur bei einem Ausfall eines Servers mehr Clients auf den anderen Servern. .


Ich hoffe ich habe dich jetzt nicht mehr verwirrt :-D
Nö, war ich vorher schon :D

Was hälst Du von einem Raid-Controller mit eingebauten SSD-Cache (evtl. statt Metadaten-SSD).

Eine gute Idee, da hatte ich noch nicht dran gedacht ... Ich werde mir mal die Intel RAID SSD Cache Controller. Bei CacheCade von LSI bin ich etwas skeptisch. Und BCache könnte vielleicht auch eine option sein.

http://www.lug-erding.de/vortrag/SSD-Cache.pdf

Und ja, es gibt noch so viele Möglichkeiten - deshalb erstmal "cut" ;)

Vielen Dank & viele Grüße
Olaf
 
Da hätte ich doch glatt noch ein paar Fragen:
  • Bei sooo vielen gleichen Systemen wäre vielleicht auch ein Storage mit Deduplizierung eine gute Idee. Habt ihr daran mal gedacht? (Problem ist ja nach initialem Klon installiert jede VM ihre Updates irgendwohin und dann kann das schon nicht mehr 1:1 sein)
  • Provisioniert ihr die Maschinen pro Thin-Arbeitsplatz oder pro Benutzer?
  • Was ist der Vorteil eines Linux VDI Systems gegenüber "eine Art" Terminalserver für Linux?
 
  • Deduplizierung: Wir wollen uns mit der Dedup nicht an einen Appliance-Hersteller binden. Sollten wir am Ende doch auf ein iSCSI Storage gehen, wäre ein ZFS over iSCSI in der Diskussion
  • Pro Benutzer: Dann haben die Seminarteilnehmer "Ihre" Maschine über die Zeit der Vorlesung. Danach werden sie gelöscht und bei Semesteranfang wieder per Script erzeugt ...
  • Laaanges Thema: Skalierbarkeit, gegenseitige Beeinflussung durch amoklaufende Scripte / Software, jeder hat seine eigene Standard-Workstation Installation ... Viele Diskussionen und Pros u. Cons
 
Hi Olaf,

sehr interessant dein Beitrag und die Antworten dazu.
Ich kann aus Erfahrung Dir empfehlen, dass Du bei 5 Servern mit deiner Ausstattung und den Anforderungen mit Ceph am besten fährst. 150 Clients, die wahrscheinlich zum größten Teil an Terminalservern arbeiten, ist Ceph wirklich eine hochverfügbare, skalierbare und performance-starke Umgebung. Kommt natürlich auf die Konfiguration des Pools, der Netzwerke etc. an. Und wenn du anstatt HDDs Business SSDs benutzt, gibt es auf der Storageseite keine Probleme mit Performanceeinbußen oder ähnlichem. Und hochverfügbar ist es ebenso sollte ein Server in die Knie gehen.

Gruß, Roman
 
Ich kann dir bei so einem Projekt aus Erfahrung auch nur zu Ceph raten. Funktioniert einfach gesagt ja wie ein Raid nur halt über mehrere Server. Würde die 15k Platten zu einem Raid50 oder event. mehrer Raids um das I/O zu verteilen. z.B. 20 clients auf ein Raid oder so zusammenhängen. So hast du viel Speicher, mehr Geschwindungkeit und einen besseren Ausfallschutz. Ausserdem hast ja mehr Server. Ist also egal wenn da einer ausfällt oder zwei... Den Speicherplatz eben gut planen.

Von Spice am Desktop haben wir auch viel Erfahrung gesammelt. Was funktioniert sehr gut:

- windows7
- XFCE
- LXDE
- Plasma5 ohne Grafikefekte
- Mate

Was funktioniert sehr schlecht bis garnicht:
- Windows10 (Bug in der WindowsgrafikAPI, ist schon lange bekannt, ähnliches Problem in der Virtualbox, leider noch nicht gefixt)
- Unity
- Gnomeshell

Wir führen deshalb die VMs lokal aus mit dem Projekt Vlizedlab. Das Projekt ist der Hammer kann ich nur empfehlen. Es ist brand frisch in der Updatephase und funktionier einwandfrei. Wobei wir noch einiges dazu programmiert haben. Kompletter Rollout organisieren wir mit Foreman von Redhat inkl. Puppet.

Aber sofern nur Windows7 und XFCE benötigt wird, und genug Buget für Server da ist würde ich der einfachhalberheit aber auch zu PVE mit Spice tentieren.

lg
 
Ist aktuell immer noch so. Wenn wenn man bedenkt das dies seit Windows8 so ist, wird das MS mehr oder weniger wohl egal sein.
 
Eine gute Idee, da hatte ich noch nicht dran gedacht ... Ich werde mir mal die Intel RAID SSD Cache Controller. Bei CacheCade von LSI bin ich etwas skeptisch. Und BCache könnte vielleicht auch eine option sein.

Bcache hab ich mal im Lab gegen die restlichen antreten lassen, das ist nicht so der Knaller wie erwartet. Da macht ZFS mehr Spass. CacheCade funktioniert sehr gut, ist aber auch leidlich teuer.

Ich würde auch zu Ceph tendieren, da kann man gut skalieren, sowohl Performance als auch Storage.

Alternativ geht auch eins der anderen Clustersysteme (Gluster, Sheepdog), die sind jeder für sich auch super, leider halt nicht ganz so auf dem Mainstream Schirm.
 
Ich hatte auf meinem Laptop lange Zeit ZFS und Bcache kombiniert. Das war schnell und für meine Belange (tägliche Replikation) ein super und vor allem schnelle Dateisystemkombination - für Server natürlich nicht zu gebrauchen.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!