Welche Hardware für kleines Proxmox Cluster
Hi zusammen,
in naher Zukunft werde ich alle bei uns im Büro laufenden Server virtualisieren und möchte hierfür ein Cluster aufsetzen. Bisher arbeite ich mit Proxmox nur soweit, dass ich virtuelle Server auf einem einzelnen Proxmox Host laufen habe und diese per Proxmox sowie Bacula sichere.
Für "die paar Server" die aktuell laufen reicht das sicherlich aus, wenn aber alles virtuell ist hätte ich das ganze gern etwas ausfallsicherer.
In der Theorie sieht der Aufbau für mich wie folgt aus:
- 2 x Server als Host/Node
- 1 x Server zum Administrieren (Webinterface)
- 2 x Switch
- 2 x VM Storage
- 1 x Backup Storage
Die VMs sollen also auf dem Storage (SAN, NAS, was auch immer) liegen, die Server sollen nur die Rechenleistung liefern.
Switche, VM Storage und Nodes/Hosts redundant.
Es werden Hauptsächlich Web- & Mailserver virtuell betrieben, einplanen würde ich hier 15 - 20 Maschinen, ob es später mehr werden wird man sehen, dann kann die Hardware noch aufgerüstet werden.
Die eigentliche Frage ist für mich jetzt, hat jemand mit einem Cluster in der "Größen"ordnung Erfahrungen und kann mir was die Hardware angeht Tipps geben?
Die Server werden nicht übermäßig viel Leistung brauchen, wichtiger für mich zu wissen wäre, welche art von Storage bietet sich an? wie schnell muss die Verbindung untereinander sein? Und ob der oben genannte Aufbau so Sinn macht/korrekt ist oder ob ich etwas anders machen sollte/muss.
Vielen Dank schon mal
Falk
in naher Zukunft werde ich alle bei uns im Büro laufenden Server virtualisieren und möchte hierfür ein Cluster aufsetzen. Bisher arbeite ich mit Proxmox nur soweit, dass ich virtuelle Server auf einem einzelnen Proxmox Host laufen habe und diese per Proxmox sowie Bacula sichere.
Für "die paar Server" die aktuell laufen reicht das sicherlich aus, wenn aber alles virtuell ist hätte ich das ganze gern etwas ausfallsicherer.
In der Theorie sieht der Aufbau für mich wie folgt aus:
- 2 x Server als Host/Node
- 1 x Server zum Administrieren (Webinterface)
- 2 x Switch
- 2 x VM Storage
- 1 x Backup Storage
Die VMs sollen also auf dem Storage (SAN, NAS, was auch immer) liegen, die Server sollen nur die Rechenleistung liefern.
Switche, VM Storage und Nodes/Hosts redundant.
Es werden Hauptsächlich Web- & Mailserver virtuell betrieben, einplanen würde ich hier 15 - 20 Maschinen, ob es später mehr werden wird man sehen, dann kann die Hardware noch aufgerüstet werden.
Die eigentliche Frage ist für mich jetzt, hat jemand mit einem Cluster in der "Größen"ordnung Erfahrungen und kann mir was die Hardware angeht Tipps geben?
Die Server werden nicht übermäßig viel Leistung brauchen, wichtiger für mich zu wissen wäre, welche art von Storage bietet sich an? wie schnell muss die Verbindung untereinander sein? Und ob der oben genannte Aufbau so Sinn macht/korrekt ist oder ob ich etwas anders machen sollte/muss.
Vielen Dank schon mal
Falk
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 226767
Url: https://administrator.de/forum/welche-hardware-fuer-kleines-proxmox-cluster-226767.html
Ausgedruckt am: 26.12.2024 um 21:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
zu Proxmox kann ich nichts sagen, habe ich nicht im Einsatz.
Im Grunde ist Proxmox aber die Linux KVM Virtualisierung mit Farbe und lustigen Icons und zum rumklicken und so.. ;)
- ca. 150 User
- ca. 50 Linux Server (Webserver, Oracle DB, Tomcat, JBoss, diverse Testsysteme)
- ca. 10 Windows Server (DC und diverse WTS Server mit meist 20 gleichzeitigen Usern)
Virtualisiert läuft das ganze auf 3 Hypervisors mit KVM. Als Speicher dient ein NFS Share eines Filers.
Zur Administration verwende ich den virt-manager. Die XML-Definitonen von QEmu (welches System hat welche Hardware) wird per Cronjob jede Nacht gesichert.
Diese Konstruktion ist zwar kein echtes Clustering, aber ich kann bei Bedarf sowohl Live-migrieren als auch ein System auf einem anderem Hypervisor booten.
Ein echtes Fail-Over, wenn etwas ausfällt, ist es aber nicht.
Luft nach oben wäre noch vorhanden.
Ein Filer hat halt den Vorteil, dass er Snapshots erzeugen kann, womit ich ein Byte-genaues Backup der Platte habe.
Wenn ein Dauerbetrieb notwendig ist, ist sowas vorteilhaft. Andern falls müsste man die VMs runterfahren, um die HDD-Images zu sichern.
Alternativ könnte man die Daten auch auf ein DRBD mit LVM legen, da kann man dann auch wieder mit Snapshots arbeiten.
Folgende Punkte sind sonst noch zu beachten:
- KVM lässt bei einer Live-Migration den Cache der virtuellen Festplatten fallen (das steht natürlich nirgends). Er überträgt den RAM, aber Windows schmiert weg, weil der Cache plötzlich fehlt. Fix: HDD Cache abschalten. Zeigt eh keine Performance-Auswirkung...
- Bei NFS Shares die sync-Option sauber konfigurieren. Änderungen an der Festplatten-Datei sollen sofort geschrieben und nicht erst im NFS gecached werden.
Ich verwende trotzdem überall Bonding mit 2x Gigabit / Kupfer. Man weiß ja nie und Redundanz ist auch immer gut zu haben.
Die meisten Linux VMs haben irgendwas um 1-2 CPU Cores, 2-4 GB RAM und 15 GB HDD. Für so ein paar Dienste wie Webserver und Co reicht das locker und dreifach.
In der Windows Welt laufen die WTS Server mit 4 CPU Cores, 12 GB RAM und 100 GB HDD.
Grüße,
Daniel
zu Proxmox kann ich nichts sagen, habe ich nicht im Einsatz.
Im Grunde ist Proxmox aber die Linux KVM Virtualisierung mit Farbe und lustigen Icons und zum rumklicken und so.. ;)
Es werden Hauptsächlich Web- & Mailserver virtuell betrieben, einplanen würde ich hier 15 - 20 Maschinen, ob es
später mehr werden wird man sehen, dann kann die Hardware noch aufgerüstet werden.
Die eigentliche Frage ist für mich jetzt, hat jemand mit einem Cluster in der "Größen"ordnung
Hier die Eckdaten meiner virtuellen Umgebung:später mehr werden wird man sehen, dann kann die Hardware noch aufgerüstet werden.
Die eigentliche Frage ist für mich jetzt, hat jemand mit einem Cluster in der "Größen"ordnung
- ca. 150 User
- ca. 50 Linux Server (Webserver, Oracle DB, Tomcat, JBoss, diverse Testsysteme)
- ca. 10 Windows Server (DC und diverse WTS Server mit meist 20 gleichzeitigen Usern)
Virtualisiert läuft das ganze auf 3 Hypervisors mit KVM. Als Speicher dient ein NFS Share eines Filers.
Zur Administration verwende ich den virt-manager. Die XML-Definitonen von QEmu (welches System hat welche Hardware) wird per Cronjob jede Nacht gesichert.
Diese Konstruktion ist zwar kein echtes Clustering, aber ich kann bei Bedarf sowohl Live-migrieren als auch ein System auf einem anderem Hypervisor booten.
Ein echtes Fail-Over, wenn etwas ausfällt, ist es aber nicht.
kann mir was die Hardware angeht Tipps geben?
Ich lasse das auf 3 Pizzablechen mit je 12 Cores (physikalische, also 2x Hexacore CPU), 96 GB RAM und 2x 36 GB HDD laufen.Luft nach oben wäre noch vorhanden.
welche art von Storage bietet sich an?
Als Storage verwende ich einen NetApp Filer. Privat habe ich aber auch schon mit KVM auf einem normalen NAS virtualisiert.Ein Filer hat halt den Vorteil, dass er Snapshots erzeugen kann, womit ich ein Byte-genaues Backup der Platte habe.
Wenn ein Dauerbetrieb notwendig ist, ist sowas vorteilhaft. Andern falls müsste man die VMs runterfahren, um die HDD-Images zu sichern.
Alternativ könnte man die Daten auch auf ein DRBD mit LVM legen, da kann man dann auch wieder mit Snapshots arbeiten.
Folgende Punkte sind sonst noch zu beachten:
- KVM lässt bei einer Live-Migration den Cache der virtuellen Festplatten fallen (das steht natürlich nirgends). Er überträgt den RAM, aber Windows schmiert weg, weil der Cache plötzlich fehlt. Fix: HDD Cache abschalten. Zeigt eh keine Performance-Auswirkung...
- Bei NFS Shares die sync-Option sauber konfigurieren. Änderungen an der Festplatten-Datei sollen sofort geschrieben und nicht erst im NFS gecached werden.
wie schnell muss die Verbindung untereinander sein?
Eigentlich würde Gigabit / Kupfer voll ausreichen. Wenn ich iftop öffne, sehe ich Traffic zwischen 5 KB/s und 15 MB/s (1 Hypervisor).Ich verwende trotzdem überall Bonding mit 2x Gigabit / Kupfer. Man weiß ja nie und Redundanz ist auch immer gut zu haben.
Die Server werden nicht übermäßig viel Leistung brauchen
Das fasziniert mich immer wieder, welche extremen Anforderungen manche Leute, gerade in der Windows Welt definieren. Das geht teilweise voll an der Realität vorbei... ;)Die meisten Linux VMs haben irgendwas um 1-2 CPU Cores, 2-4 GB RAM und 15 GB HDD. Für so ein paar Dienste wie Webserver und Co reicht das locker und dreifach.
In der Windows Welt laufen die WTS Server mit 4 CPU Cores, 12 GB RAM und 100 GB HDD.
Grüße,
Daniel
Hallo Falk,
Hier kann ich Dir helfen. Ich arbeite selbst mit zwei Servern in einem Proxmox HA Cluster über IPMI als Fencing Tool und DRBD.
(baugleiche Server, 2xXeon E3 3,4 GHz bei 16 GB RAM, 2te dedizierte NIC geht halt für DRBD drauf).
http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
Sollte in dem Fall für Dich ganz interessant sein. Ich hab die Konfiguration etwas abgewandelt und das Cluster läuft seit nem 3/4 Jahr absolut konstant durch, Ausfall einer HW hatten wir auch schon, die VM's waren dank DRBD in weniger als 15 Sekunden umgezogen.
Ich hoffe, dass hilft Dir etwas weiter.
Das war auch die Richtung in die meine Gedanken gingne, entweder auf jedem der Server eine extra Partition wo dann DRDB
läuft, dann spiegelt sich doch wenn ich das richtig verstehe der komplette Server. Ich habe also auf Server 1 auf einer
Partition alle KVMs und auf der zweiten Partition DRDB und die Daten werden IMMER parallel auf Server 2 geschrieben, richtig?
läuft, dann spiegelt sich doch wenn ich das richtig verstehe der komplette Server. Ich habe also auf Server 1 auf einer
Partition alle KVMs und auf der zweiten Partition DRDB und die Daten werden IMMER parallel auf Server 2 geschrieben, richtig?
Hier kann ich Dir helfen. Ich arbeite selbst mit zwei Servern in einem Proxmox HA Cluster über IPMI als Fencing Tool und DRBD.
(baugleiche Server, 2xXeon E3 3,4 GHz bei 16 GB RAM, 2te dedizierte NIC geht halt für DRBD drauf).
http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
Sollte in dem Fall für Dich ganz interessant sein. Ich hab die Konfiguration etwas abgewandelt und das Cluster läuft seit nem 3/4 Jahr absolut konstant durch, Ausfall einer HW hatten wir auch schon, die VM's waren dank DRBD in weniger als 15 Sekunden umgezogen.
Ich hoffe, dass hilft Dir etwas weiter.
Hallo!
Ich würde in Deinem Fall auch darüber nachdenken, lokalen Storage zu nutzen. Das spart Dir doch einiges an Budget.
Ein ähnliches Setup habe ich mit Xenserver am Laufen. Zwei Kisten mit lokalem Storage, repliziert über DRBD. Der große Vorteil von DRBD gegenüber einem "normalen" Shared Storage per iSCSI oder ähnlich ist, dass die Leseperformance immer die des lokalen Systems ist - ohne zusätzliche Latenz. Das hat schon Charme.
Gruß
Phil
Ich würde in Deinem Fall auch darüber nachdenken, lokalen Storage zu nutzen. Das spart Dir doch einiges an Budget.
Ein ähnliches Setup habe ich mit Xenserver am Laufen. Zwei Kisten mit lokalem Storage, repliziert über DRBD. Der große Vorteil von DRBD gegenüber einem "normalen" Shared Storage per iSCSI oder ähnlich ist, dass die Leseperformance immer die des lokalen Systems ist - ohne zusätzliche Latenz. Das hat schon Charme.
Gruß
Phil
Hallo,
Mir ist die Redundanz einzelner Server ziemlich egal, da die Firewall eh als LoadBalancer arbeitet.
Wichtige Webservices laufen auf mehreren Webservern auf unterschiedlichen Hypervisors.
Das hat den Vorteil, dass der HTTPS Traffic auf der Firewall entschlüsselt wird und die Firewall den Traffic analysieren kann.
Wenn die Firewall nur verschlüsseltes HTTPS durchlaufen sieht, kann sie kaum einen Angriff abwehren.
Kann die Firewall aber entschlüsseln, sieht sie den Traffic und kann diverse Angriffe (SQL Injections, Virus Uploads, etc...) blocken.
Aber wie gesagt, jeder baut da was anderes... ;)
Ein top auf dem Hypervisor zeigt bei mir auch an, dass unter 10% RAM genutzt werden, obwohl aktuell 20 Gäste auf einem Hypervisor laufen.
Ich betrachte hier immer die Peak-Load, also die maximale Auslastung, welche ein Gast erzeugen kann.
Im Leerlauf braucht z.B. ein Windows 2K8 R2 Domänencontroller keine hohe Leistung. Das könnte man locker auf 1 CPU und 1GB RAM konfigurieren.
Dumm ist es halt dann nur, wenn ein Reboot notwendig wird, welcher dann ewig dauert, weil zufällig Updates installiert werden.
Meine Domänencontroller laufen daher mit 2 CPUs und 4 GB RAM, auch wenn diese Zuweisung nur selten benötigt wird.
Wenn Windows oder Java (JBoss, Tomcat) im Spiel ist, weise ich schon mal mehr Ressourcen zu.
Linux Kisten haben dafür um so öfter nur 1 CPU und 512 MB RAM.
Natürlich könnte man überquotieren (Den Gästen in Summe mehr RAM zuweisen, als der Hypervisor überhaupt hat).
RAM ist jetzt nicht sooo teuer, das spare ich lieber wo anders wieder ein...
1. Du brauchst immer die Festplatten-Daten und auch die XML-Konfiguration, welche die virtuelle System-Hardware beschreibt.
2. Für ein Backup kannst du die Festplatten-Datei nicht einfach wegkopieren, dabei geht es einfach nur kaputt.
Du musst das System entweder ausschalten und dann die Dateien sichern, oder du erzeugst einen Snapshot (z.B. mit LVM)
Ob du nun DRDB oder ein SAN verwendest, ist wohl Geschmackssache. Wie DRDB arbeitet hast du wohl verstanden.
Ab einer gewissen Größe steht in so gut wie jeder Firma ein Fileserver-Cluster, daher habe ich immer diesen verwendet und musste nie über DRDB nachdenken.
Ich finde eine hohe I/O Last auf derartigen Systemen untypisch.
Grüße,
Daniel
Das ist aber leider genau die Anforderung die ich habe, da es sich um Websites von Kunden handelt und ich gern vermeiden
würde wenn wirklich ein Fehler auftritt erst aktiv werden zu müssen.
Nun ja, jeder baut seine Konfiguration anders auf und ich kenne dein Setup nicht. ;)würde wenn wirklich ein Fehler auftritt erst aktiv werden zu müssen.
Mir ist die Redundanz einzelner Server ziemlich egal, da die Firewall eh als LoadBalancer arbeitet.
Wichtige Webservices laufen auf mehreren Webservern auf unterschiedlichen Hypervisors.
Das hat den Vorteil, dass der HTTPS Traffic auf der Firewall entschlüsselt wird und die Firewall den Traffic analysieren kann.
Wenn die Firewall nur verschlüsseltes HTTPS durchlaufen sieht, kann sie kaum einen Angriff abwehren.
Kann die Firewall aber entschlüsseln, sieht sie den Traffic und kann diverse Angriffe (SQL Injections, Virus Uploads, etc...) blocken.
Aber wie gesagt, jeder baut da was anderes... ;)
> > kann mir was die Hardware angeht Tipps geben?
Hier hatte ich an deutlich weniger gedacht, kannst du in etwa abschätzen, wie viel der Ressourcen durch die Windowsmaschinen
genutzt wird? Aktuell habe ich zum Test einige Server auf einem einzelnen Proxmox Host laufen und da komme ich bei 6 Servern mit
4GB Ram aus - die CPU auslastung dümpelt bei einem Quadcore irgendwo zwischen 3% und 5% rum, also nicht der Rede wert.
Hier muss man unterscheiden, ob man die zugewiesene oder die tatsächliche Speicherlast betrachtet.Hier hatte ich an deutlich weniger gedacht, kannst du in etwa abschätzen, wie viel der Ressourcen durch die Windowsmaschinen
genutzt wird? Aktuell habe ich zum Test einige Server auf einem einzelnen Proxmox Host laufen und da komme ich bei 6 Servern mit
4GB Ram aus - die CPU auslastung dümpelt bei einem Quadcore irgendwo zwischen 3% und 5% rum, also nicht der Rede wert.
Ein top auf dem Hypervisor zeigt bei mir auch an, dass unter 10% RAM genutzt werden, obwohl aktuell 20 Gäste auf einem Hypervisor laufen.
Ich betrachte hier immer die Peak-Load, also die maximale Auslastung, welche ein Gast erzeugen kann.
Im Leerlauf braucht z.B. ein Windows 2K8 R2 Domänencontroller keine hohe Leistung. Das könnte man locker auf 1 CPU und 1GB RAM konfigurieren.
Dumm ist es halt dann nur, wenn ein Reboot notwendig wird, welcher dann ewig dauert, weil zufällig Updates installiert werden.
Meine Domänencontroller laufen daher mit 2 CPUs und 4 GB RAM, auch wenn diese Zuweisung nur selten benötigt wird.
Wenn Windows oder Java (JBoss, Tomcat) im Spiel ist, weise ich schon mal mehr Ressourcen zu.
Linux Kisten haben dafür um so öfter nur 1 CPU und 512 MB RAM.
Natürlich könnte man überquotieren (Den Gästen in Summe mehr RAM zuweisen, als der Hypervisor überhaupt hat).
RAM ist jetzt nicht sooo teuer, das spare ich lieber wo anders wieder ein...
> > welche art von Storage bietet sich an?
> Alternativ könnte man die Daten auch auf ein DRBD mit LVM legen, da kann man dann auch wieder mit Snapshots arbeiten.
Das war auch die Richtung in die meine Gedanken gingne, entweder auf jedem der Server eine extra Partition wo dann DRDB
läuft, dann spiegelt sich doch wenn ich das richtig verstehe der komplette Server. Ich habe also auf Server 1 auf einer
Partition alle KVMs und auf der zweiten Partition DRDB und die Daten werden IMMER parallel auf Server 2 geschrieben, richtig?
Als zweite Möglichkeit kann man doch auch ein gemeinsam genutzes SAN hinstellen, wodurch die DRDB konfiguration
überflüssig wird, richtig?
Bitte beachte, beim Backup von VMs folgende Punkte:> Alternativ könnte man die Daten auch auf ein DRBD mit LVM legen, da kann man dann auch wieder mit Snapshots arbeiten.
Das war auch die Richtung in die meine Gedanken gingne, entweder auf jedem der Server eine extra Partition wo dann DRDB
läuft, dann spiegelt sich doch wenn ich das richtig verstehe der komplette Server. Ich habe also auf Server 1 auf einer
Partition alle KVMs und auf der zweiten Partition DRDB und die Daten werden IMMER parallel auf Server 2 geschrieben, richtig?
Als zweite Möglichkeit kann man doch auch ein gemeinsam genutzes SAN hinstellen, wodurch die DRDB konfiguration
überflüssig wird, richtig?
1. Du brauchst immer die Festplatten-Daten und auch die XML-Konfiguration, welche die virtuelle System-Hardware beschreibt.
2. Für ein Backup kannst du die Festplatten-Datei nicht einfach wegkopieren, dabei geht es einfach nur kaputt.
Du musst das System entweder ausschalten und dann die Dateien sichern, oder du erzeugst einen Snapshot (z.B. mit LVM)
Ob du nun DRDB oder ein SAN verwendest, ist wohl Geschmackssache. Wie DRDB arbeitet hast du wohl verstanden.
Ab einer gewissen Größe steht in so gut wie jeder Firma ein Fileserver-Cluster, daher habe ich immer diesen verwendet und musste nie über DRDB nachdenken.
Kann mir hierzu jemand Vor- und Nachteile der beiden Möglichkeiten nennen? Ist die Lese-/Schreibgeschwindigkeit auf ein SAN
merklich langsamer als beim DRDB (es wird NUR Web- & Mailserver geben)?
Also wenn ich einen Webserver oder einen Mailserver hätte, der ständig auf der Disk rumschreibt, würde ich jemanden hinsetzen, der den Fehler sucht.merklich langsamer als beim DRDB (es wird NUR Web- & Mailserver geben)?
Ich finde eine hohe I/O Last auf derartigen Systemen untypisch.
> Folgende Punkte sind sonst noch zu beachten:
> - KVM lässt bei einer Live-Migration den Cache der virtuellen Festplatten fallen (das steht natürlich nirgends).
Er
> überträgt den RAM, aber Windows schmiert weg, weil der Cache plötzlich fehlt. Fix: HDD Cache abschalten. Zeigt
eh
> keine Performance-Auswirkung...
Sollte für die geplante Konfiguration uninteressant sein, oder?
Das weiß ich eben nicht. Mir ist dieses Verhalten bei KVM aufgefallen, und dieses Proxmox verwendet ja auch KVM, drum habe ich es geschrieben.> - KVM lässt bei einer Live-Migration den Cache der virtuellen Festplatten fallen (das steht natürlich nirgends).
Er
> überträgt den RAM, aber Windows schmiert weg, weil der Cache plötzlich fehlt. Fix: HDD Cache abschalten. Zeigt
eh
> keine Performance-Auswirkung...
Sollte für die geplante Konfiguration uninteressant sein, oder?
> > Die Server werden nicht übermäßig viel Leistung brauchen
> Das fasziniert mich immer wieder, welche extremen Anforderungen manche Leute, gerade in der Windows Welt definieren. Das
geht
> teilweise voll an der Realität vorbei... ;)
Hab's ja oben schon kurz angesprochen, ich sollte eigentlich mit 2 x Quadcore und 32 - 64 GB RAM ohne jegliche Probleme
auskommen.
Jep, sollte für dein Setup locker reichen.> Das fasziniert mich immer wieder, welche extremen Anforderungen manche Leute, gerade in der Windows Welt definieren. Das
geht
> teilweise voll an der Realität vorbei... ;)
Hab's ja oben schon kurz angesprochen, ich sollte eigentlich mit 2 x Quadcore und 32 - 64 GB RAM ohne jegliche Probleme
auskommen.
Grüße,
Daniel