Praxisfrage - 3 Node Cluster?

fpausp

Renowned Member
Aug 31, 2010
633
43
93
Austria near Vienna
Ich würde mir gerne die Hardwarekosten für einen (kleinen) 3-Node Cluster ausrechnen...

Werden die Server üblicherweise in verschiedenen Brandabschnitten errichtet oder kommen die alle in ein Rack ?


P.S. Wäre dankbar für Hardwarevorschläge/Beispiele von Euch...
 
Alle in ein Rack.

Etwas mehr Info zum Einsatzszweck? Ceph mit dabei? Wieviel Storage wird benötigt, Netzwerk? ...
 
Hab mit Clustering sehr wenig Erfahrung, deshalb die wage Fragerei... Hab einen Cluster mit 3 Nodes
Etwas mehr Info zum Einsatzszweck? Ceph mit dabei? Wieviel Storage wird benötigt, Netzwerk? ...
Hab den Cluster nested virtuell mit Ceph erstellt und würde gerne wissen was soetwas real kosten würde. Ich denke 32GB RAM pro Node und 2TB HDD plus jeweils zwei schnelle 32GB SDD auf einem kleinen einwege Rackserver... Dann noch die Switch die ja redundant sein sollten, ich denke 10Gbit ? USV pro Server und Switch... Wenns in verschiedenen Brandabschnitten sein muss dann braucht man natürlich jeweils ein Rack, Rangierfeld usw...

upload_2018-11-14_19-37-54.png

upload_2018-11-14_19-38-10.png

P.S. Alle in ein Rack ! Sorry hab ich zuerst überlesen...
 
Last edited:
Ich denke 32GB RAM pro Node

Das erscheint mir sehr, sehr wenig. Ich würde - wenn man schon 10 GBE vor hat zu verbauen auch gleich den RAM auf mindestens 128 GB erhöhen. Bei einem Dual-Sockel-System mit Triple oder gar Quadrupel-Channel-RAM musst du eh mind. 6 respektive 8 Module reinstecken um die volle Geschwindigkeit zu erreichen.

Auch habe ich in diesem Jahrzehnt keinen Server gesehen der nur 32 GB-RAM hat, das haben heutzutage die meisten Workstations - wenn nicht sogar schon mehr (zumindest in der Kategorie mit CEPH usw).

Ich würde mir gerne die Hardwarekosten für einen (kleinen) 3-Node Cluster ausrechnen...

Das "kleinste" (pyhsikalisch und von den Minimum-Ausstattungen her) was ich mir so vorstellen kann wäre ein Trippel-APU-System von PCEngines was weniger als 1000 Euro kostet inkl. Verkabelung und Switches. Dabei hast du wirklich einen der kleinsten Cluster, die man aktuell bauen kann, aber wirklich viel kannst du damit nicht anfangen. Hättest damit insgesamt 12 GB-RAM, 12 Kerne, pro Box eine mSATA SSD für OS (mini-Partition) und andere (größere Partition) für CEPH. Die Kisten gibt es auch mit 4 Ethernet-Karten, sodass du hier Cluster/CEPH vom "normalen" Traffic aus splitten kannst inkl. Bonding.

Für kleinere Systeme wie z.B. HA-Balancer, HA-Firewalls kann man das prima verwenden und wir haben damit in der Vergangenheit unter Proxmox 3 sogar (damals mit nur 2 und DRBD) einen Cluster gebaut - jetzt brauch man einen Knoten mehr und CEPH, aber technisch bleibt das weiter total OK für den Use-Case.
 
Also wenn es wirklich klein sein soll im Sinne, wie klein funktioniert noch:

3x Supermicro X10SDV-2C-TP8F, 16GB Speicher, 32GB M.2 SSD, 2x 6TB WD RED. Nur CEPH kommuniziert via MESH mit DAC-Kabeln über die 10GBit-Schnittstelle.

Das läuft hier inzwischen gut ein Jahr ganz brauchbar. Seit einem der letzten Kernel und dem Upgrade auf 32GB Speicher funktioniert auch das Backup inzwischen stabil. Bis auf die Abschaltung der Debug-Funktionen in CEPH ist das System quasi "out of the box" installiert.

Was hab ich drauf:
2x SAMBA DC
1x Mailserver Kopano, vollverschlüsselt
1x Fileserver SAMBA, vollverschlüsselt
1x Mediaserver SERVIIO
1x Windows 10 Pro, das ist aber schon recht träge. Die Gasterweiterung will nicht so wirklich. Proxmox und Windows mögen sich irgendwie nicht. Linux/Unix-derivate laufen definitiv deutlich besser um nicht zusagen "In einer ganz a
1x ESX 6.7 als Notsystem falls das VSAN wegklappt und die VCSA zur Reparatur woanders laufen muss. Das geht sehr gut.
3-4 Linux Spielsysteme für Installationsversuche diverser Anwendungen

Die geringe Anzahl OSD hat natürlich extremen Einfluss auf den Durchsatz. Bei größeren Kopieraktionen hat man schonmal kurzzeitig 50% IO Wait im Gast. Die CPUs der Hosts langweilen sich aber meist bei 6-10% Last. Mit SSD-Cache und mehr HDDs würde das CEPH vermutlich noch richtig in Schwung kommen.

Es geht aber noch kleiner: 3x ASROCK N3700-ITX, 16GB Speicher, 1x 2TB Bootplatte, 1x 4TB WD RED. Die fehlende 10GBit-Schnittstelle hat das Ceph dann doch extrem ausgebremst.
Aber für den Hausgebrauch bei zwei Usern des Gesamtsystems war das bei täglichen Streicheleinheiten durchaus noch funktional. Der IO stand aber halt gerne mal eine Weile auf 98% und da kam dann doch schonmal der ein oder andere Abbruch. Von Timeouts und Warnung auf der Konsole bzgl. CPU Timeout ganz zu schweigen. Mit viel Parameter-Tuning in ceph.conf, sysctl Host, syctl Guest hatte ich das einigermaßen in den Griff bekommen.
Windows und ESX liefen da aber nicht drauf. Die restlichen Gäste von oben liefen aber auch auf diesem Winzigsystem. Hier war die Systemlast deutlich höher, ca. 70% und es ist ja ein 4-Core.

Auf diesen Winzigsystem habe ich inzwischen meinen ESX VSAN Spielsystem laufen. Der leidet natürlich genauso am fehlenden 10GBit und vor allem am zuwenig Speicher für die VCSA. Aber es laufen einigermaßen passabel zwei Windows10 auf den Kisten. Ich meine sogar besser als auf dem eigentlich schnelleren Proxmoxsystem.

Soweit zum Thema wie klein noch funktioniert.
Das das alles weit von einem brauchbaren gewerblichen Einsatz weg ist, sollte klar sein. Speziell die N3700 sind mehr eine Machbarkeitsstudie, da die zwar eigentlich gut laufen, wenig Strom brauchen, aber sehr schnell thermal ausgebremmst werden und nicht mehr als 16GB, bei Supermicro offiziell sogar nur 8GB, Speicher können.

Achso, das sind alles voll virtualisierte Gäste. Container nutze ich nicht, da die nach meinem Wissen nicht life verschoben werden können. Und die Verschlüsselung schon auf CEPH-Ebene ist mit Proxmox auch so eine Sache.
 
Last edited:
OK, danke für Deine ausführliche Beschreibung... und Ja, Live-Migration funktioniert meines Wissens nur mit KVM auf shared oder distributed Storage...
 
und Ja, Live-Migration funktioniert meines Wissens nur mit KVM auf shared oder distributed Storage...

aus man qm:

Code:
       qm migrate <vmid> <target> [OPTIONS]

       Migrate virtual machine. Creates a new migration task.

       <vmid>: <integer> (1 - N)
           The (unique) ID of the VM.

       <target>: <string>
           Target node.

       --force <boolean>
           Allow to migrate VMs which use local devices. Only root may use this option.

       --migration_network <string>
           CIDR of the (sub) network that is used for migration.

       --migration_type <insecure | secure>
           Migration traffic is encrypted using an SSH tunnel by default. On secure, completely private networks this can be disabled to increase performance.

       --online <boolean>
           Use online/live migration.

       --targetstorage <string>
           Default target storage.

       --with-local-disks <boolean>
           Enable live storage migration for local disk
 
Welche Maschinen laufen in dem Cluster, wenn ich fragen darf?

Alle :-D

Insgesamt knapp 150 Maschinen, kritisch sind davon nur ca. 50, Rest sind Entwicklungs und Testmaschinen, paar Docker und Kubernetes Cluster und auch ein paar Test-Proxmox VE Cluster. Wir verwenden zu >85% Linux, daher können wir so viel auf eine Maschine packen.
 

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!