Zurück  

Wieso überhaupt Proxmox?

Ich kann sowohl Container als auch Virtuelle Maschinen mit einem einzigen einfachen Web-Interface verwalten. Falls der Bedarf steigt, kann das System mitwachsen und erlaubt auch Clustering und High-Availabilty (obwohl ich beides bislang nicht einsetze).

Wieso Debian?

Proxmox liefert ein Installations-Image das per USB-Stick oder DVD installiert werden kann.

Für mich gibt es 2 wichtige Gründe, dieses nicht zu verwenden:

  1. ich bin ein Debian-Fan
  2. die Kunden kommen mit einer grafischen Oberfläche besser klar als auf dem Terminal,
    desshalb installiere ich XFCE

XFCE lässt sich auch auf dem Original nachinstallieren, aber mir gefällt der umgekehrte Weg besser.

Versionen

Debian Jessie (Debian 8) mit Proxmox 4.0

Für Proxmox 3.4 auf Jessie war es noch notwendig den systemd durch sysvinit zu ersetzen. Mit Proxmox 4.0 funktionniert auch systemd. Meine meisten produktiven Systeme laufen noch mit Wheezy (Debian 7) und Proxmox 3.4. Ein Update dieser System plane ich nicht, die ersetze ich erst mit dem nächsten Hardware-Upgrade.

Diese Dokumentation wurde zuletzt am 5.Feb.2017 mit Debian 8.7.0 und Proxmox-Kern 4.4.35-2 verifiziert.
Fehler bitte melden an info(at)tobs.tips melden!

Resourcen-Berechnung

Ram

Container sind in der Regel sehr sparsam. Für die Firewall reichen 128m. Auch für DHCP oder einen DNS-Server braucht es nicht mehr. Anders sieht es z.Bsp bei einem Datenbank-Server (MySQL, PostgreSQL) oder einem Proxy-Server (Squid) aus.

Für eine Windows-VM (mit QEMU/KVM) müssen es schon minimal 2GB sein, je nach Anwendung (SQL-Server) aber auch deutlich mehr.

Da Overprovisioning kein Problem ist, darf die Summe des zugeordneten Speichers auch grösser sein als der physikalisch vorhandene. Das kann aber durchaus zu erheblichen Latenz-Zeiten führen, ist aber zum Testen in der Regel akzeptabel.

Zum experimentieren reichen also 4GB.

CPU

Für die meisten Container reichen 1 CPU locker. Für eine Windows VM sollten es aber 2 sein.

Auch hier ist Overprovisioning kein Problem - sogar noch weniger als beim RAM.

Disk

Bei den Containern wird nur der effektiv genutzte Platz alloziert. Wem meine 1GB zu spartanisch erscheinen darf also ohne Gewissensbisse grössere Disks definieren. Bei nur 1GB muss darauf geachtet werden, dass die /temp und /var/temp nicht zu voll werden, gegebenenfalls regelmässig kontrollieren, oder gleich mit 4GB planen!

Für ein naktes Win7 reichen 20G problemlos - zumindest wer wie ich das hiberfile ausschaltet (braucht so soviel Platz auf der Platte, wie RAM definiert wurde) und das pagefile (swap) manuell auf 256-512M runter setzt.

Für Datenbanken erstelle ich 2 Disks: die System-Disk und eine Daten-Disk. Das gilt sowohl für Windows VM als auch für Linux CT.

Backup

Die Container werden per Proxmox-Backup gesichert. Da die sehr klein sind mache ich diese Backups täglich.

Bei den Windows-VM erstelle ich nur von der System-Disk ein Proxmox-Backup. Normalerweise mache ich von diesen nur wöchentlich ein Backup, denn diese dauern aufgrund ihrer Grösse recht lange.

Von den Partitionen mit den Daten mache ich KEIN Proxmox-Backup sondern mit den jeweiligen Bord-Mitteln ein tägliches Backup der Datenbank auf eine per SMB oder NFS angehängte Netzwerk-Freigabe.

Ein Cron-Job sorgt für ein rSync-Backup aller relevanten Daten auf externe Festplatten. Das sind in der Regel alle Proxmox-Backups plus die auf eine SMB- oder NFS-Freigabe gesicherten Backups und die per Bind-Mount in einen Container gemounteten Verzeichnisse. Zusätzlich noch das /etc des Basis-Systems.

Details folgen bei den einzelnen VM oder CT.

Netzwerk

Für meine Beispiele braucht der Rechner 2 Netzwerk-Karten. Die erste für das aus Sicht des neuen Systems lokale Netzwerk. Die zweite für den Zugang in die weiten des Internet. Zusätzlich arbeite ich noch mit einem virtuellen Netzwerk für die Kommunikation zwischen den einzlenen VMs.

Das bei mir aktuell vorhandene lokale Netzwerk ist 62.2.169.0/28 und der Router hat die IP 62.2.169.40.

Im weiteren gehe ich davon aus, dass der Bereich 62.2.169.210-220 frei zur Verfügung steht da ich diese IP-Adressen während der Installation als 'externe' IPs für die VMs verwenden werden. Anders formuliert: dieser lokale Adress-Bereich ist aus Sicht des neuen Systems extern.

Erst wenn das System getestet ist und für den Umzug in den Server-Schrank des Hosters oder des Kunden vorbereitet wird, werden die 'richtigen' Adressen zugewiesen. Dieses Vorgehen ermöglicht es mir, das System bei mir im Hause komplett aufzubauen und durchzutesten. Ich werde jeweils darauf hinweisen, wenn eine Konfiguration disbezüglich überarbeitet werden muss.

Wenn ich im weiteren vom 'externen' Netzwerk spreche, ist dies aus Sicht des neuen Systems zu betrachten und bezieht sich auf diesen Adress-Bereich im aktuellen lokalen Netzwerk. Für das 'interne' Netzwerk verwende ich 192.168.0.0/24. Damit ist NICHT das bereits vorhandene Netzwerk gemeint da dies ja aus Sicht des neuen Rechners bis auf weiteres das 'externe' ist.

Für das virtuelle auf den Rechner beschränkte Netzwerk verwende ich 192.168.99.0/24.

Netzwerk
Wichtig:
Am externen Netzwerk ist der Router erreichbar. Am internen Netzwerk ist bis auf weiteres KEIN Kabel angeschlossen.

Sobald die Firewall eingerichtet ist, kann ein Rechner mit fixer IP angeschlossen werden. Wenn auch die Dienste (insbesondere DHCP) eingerichtet sind, sollte zum Testen ein Rechner angeschlossen werden.

Hardware

Die Links zu den einzelnen Artikeln führen auf die Seite von Brack. Kann sein, dass der eine oder Artikel woanders günstiger zu haben ist. Da Brack alles was ich brauche hat, kommt das meiner Faulheit entgegen. Wer jedoch toten Link findet, darf mich gerne kontaktieren, dann suche ich die Nachfolgeartikel...
(Letzter Update der Links: 29.10.2015)

In der Regel verwende ich Server-Boards von SuperMicro (X10SLM-F mit 4x ECC-Ram, 2x LAN, 4xSATA3, 2xSATA2 oder X10SAE mit 8xSATA3) mit dem kleinsten Xeon E3-1220v3 ohne Grafik für X10SLM / E3-1225v3 mit Grafik für X10SAE). Mit 2x 8GB habe ich 16G was bei den meisten meiner Kunden reicht und gegebenenfalls eine Erweiterung auf 32G erlaubt.

Die 4 Sata3-Schnittstellen des X10SLM nutze ich für 1xSSD (Samsung EVO120 oder EVO250 ) und 3xHDD als Raid5 (Western Digital Black 1TB, 2TB oder 4TB).

Gelegentlich (dann brauche ich das X10SAE) gibt es zusätzlich zur SSD und dem schnelle Raid ein weiteres Raid mit langsameren Platten (Western Digital Red 2TB, 3TB, 4TB, 5TB oder 6TB).

Für kleinere Systeme nehme ich auch schon mal ein normales Mainboard mit 4 RAM-Slots (Asus B85M-G mit 4xSata oder H97plus mit 6xSata und Slot für M.2 SSD) mit 2x oder 4x 8GB Ram und einem i3 oder i5 Prozessor (die i7 sind mir zu teuer, da bin ich mit eine SM-Board mit Xeon besser bedient) und natürlich einer zweiten Netzwerk-Karte.

Zum Testen sind die Anforderungen minimal 4GB Hauptspeicher, 250G Platte und einen 64-bit Prozessor. (Die Installation funktinniert nur mit einem 64bit Debian!)

CD- oder DVD-Laufwerke brauche ich nicht mehr. Ein USB-Stick ist deutlich komfortabler.

Meine Umgebung

Dank Proxmox habe ich meinen Server-Park extrem ausgedünnt. Anstelle von 4-6 Servern habe ich nur noch einen: mit i5, 32G Ram, SSD (250G), Raid 5 (4x500G WD Black = 1.5T), Raid-1 (2x2T WD Red = 2T), plus einzelne Disk (4T WD Green). Da das Mainboard nur 1 Netzwerk und 6 Sata hat, habe ich noch einen 4port Sata-Adapter und 2 weitere Netzwerkkarten eingebaut.

Anstelle von mehreren Rechnern mit HD-Schubladen und verschiedenen Windows-Versionen habe ich auch nur noch 2 einfache Linux-Rechner. Bei Windows-Bedarf kann ich auf dem Server die entsprechende Version als VM starten und per freerdp ab einem Linux-Rechner darauf arbeiten.

Damit habe ich den Stromverbrauch drastisch gesenkt und im Sommer deutlich angenehmere Temparaturen. Nur im Winter darf ich jetzt etwas mehr heizen...

WICHTIG

Für die Installation des Debian-Systems schliesse ich nur die erste Platte an. Die weiteren Platten werden erst nach der Grund-Installation angehängt. Dieses Vorgehen ist nicht zwingend, macht es aber einfacher, die richtige Platte für die Installation zu finden!
Unbedingt im Mainboard-Handbuch nachschauen, welcher Sata-Port der erste ist. Oder im BIOS kontrollieren, ob die Platte wirklich am ersten Port hängt.

Ich empfehle, zumindest bis und mit dem Kapitel 'Container mit Firewall' alles mal durchzulesen (Debian Installation darf ausgelassen werden) und erst im zweiten Durchgang die Installation vorzunehmen.

Zurück