Virtuelle Server (VMs)

Zur Realisierung des HumHub-Betriebs werden folgende virtuellen Server eingesetzt:

humhub-vm

Dies ist der Webserver, mit einem klassischen LAMP-Setup, optimiert für HumHub. Das Betriebssystem ist ein Debian. Als Datenbank wird MariaDB verwendet und PHP ist als PHP-FPM realisiert. Der Webserver ist im internen Netzwerk erreichbar und kommuniziert auf Port 80. Ein direkter Zugriff auf diese VM über das Internet ist aus Sicherheitsgründen und zur Ressourcen-Schonung (Public IPs) nicht möglich, sofern keine Tunnel angelegt werden. Dies ist die VM für das produktive HumHub. Eine Verbindung über das Internet ist nur über den rProxy möglich, womit HumHub öffentlich aufgerufen wird.

rProxy

Diese VM ist der Reverse Proxy. Die VM hat zwei Netzwerkkarten. Auf der einen Netzwerkkarte, benutzt die VM öffentliche IP-Adressen für IPv4 und IPv6. Auf der anderen Netzwerkkarte hat die VM eine interne IP-Adresse und kann die internen VMs im internen Netzwerk erreichen. Als Software für den die Einrichtung der einzelnen Domains und Dienste, wird der Nginx-Proxy-Manager verwendet, der wiederum in Docker Compose realisiert ist. Die VM selber basiert auf Debian und hat eine entsprechende Standard-Installation mit Docker und Docker Compose, auf Basis der Standard-Repositories von Docker für Debian. Der Nginx-Reverse-Proxy-Manager erzeugt und aktualisiert automatisiert die Lets Encrypt Zertifikate, um vom Internet aus einen verschlüsselten Zugriff über https auf HumHub zu ermöglichen. Intern werden alle Anfragen an die eigentliche Webserver-VM mit HumHub durchgeleitet. Der rProxy kann nahezu beliebig viele Domains und Subdomains an die hinterliegenden Webserver durchleiten und ist damit zukünftig ausbaufähig. Temporär kann die VM des rProxy auch genutzt werden, um z.B. interne Ports aus dem Internet direkt erreichbar zu machen. Lediglich die Ports 80 und 443 sind reserviert. Um interne Dienste auf beliebige Ports und die öffentlichen IP-Adressen, des rProxy zu tunneln, eignen sich SSH-Tunnel im internen Netzwerk. Zu beachten ist hierbei, dass die Firewall des rProxy diese Ports ebenfalls öffnen muss. Wichtig: Solche Lösungen sollten nur temporär genutzt werden. Werden Dienste dauerhaft direkt vom Internet aus zugänglich gemacht, sind entsprechende Sicherheitsthemen alle durchzugehen.

humhub-test

Diese VM ist ebenfalls eine nahezu baugleicher Webserver, wie das produktive HumHub und ist für Testzwecke gedacht, die im produktiven HumHub nur schwer oder mit zu großem Risiko möglich wären. Eine Verbindung über das Internet ist nur über den rProxy möglich, womit HumHub öffentlich aufgerufen wird, genau wie bei dem produktiven HumHub. Eine entsprechend andere Subdomain ist dafür notwendig und führt im rProxy zu der Entscheidung, wohin die Anfragen intern weitergeleitet werden.

debian-desktop

Diese VM ist eine Hilfs- und Wartungs-VM. Der Sinn dieser VM ist, dass dort ein vollständiger Desktop und Tools für die Administration installiert sind. Der Desktop kann über die Proxmox ve GUI bedient werden. Die Netzwerkkarte ist an das interne Netzwerk angebunden. Außerdem ist ein Internetzugriff, wie bei einer Workstation möglich. Über diese VM können alle Arbeiten an Internen Systemen gemacht werden und sie hilft auch, um z.B. Dateien von außerhalb per Download in das interne Netzwerk zu holen, wie z.B. Installationspakete für HumHub, Datenbank-Dumps usw.. Ein Zugriff auf diesen Desktop außerhalb der Proxmox-GUI wäre nur möglich, wenn Tunnel auf öffentliche IP-Adressen eingerichtet werden, wodurch sich dieser Desktop in einer relativ sicheren Umgebung befindet. Dennoch ist dies ein Expertentool, weil z.B. über den dort installierten Browser beliebige Dateien in das interne Netzwerk geholt werden können. Dieser ist somit mit der nötigen Vorsicht von erfahrenen Administratoren zu bedienen, wie die anderen Komponenten auch. Selbstverständlich gibt es andere Möglichkeiten das interne Netzwerk erreichbar zu machen. Dieser Desktop bietet allerdings einen schnellen spontanen Zugriff, ohne Extra-Tools z.B. auf dem eigenen Computer installieren zu müssen oder z.B. SSH-Keys hinterlegen zu müssen. Sollten Entwickler im internen Netzwerk umfangreiche Arbeiten durchführen wollen, kann die im Standard fehlende Copy & Paste Funktion und andere Einschränkungen ggf. behindern. Dafür kann sich initial ein Mehraufwand z.B. für die Einrichtung von temporären SSH-Tunneln lohnen.

Weitere virtuelle Maschinen

Die skalierbare Plattform auf Basis von Proxmox ve eignet sich sehr gut, um weitere Services zu hosten, aber auch, um temporäre Test-VMs zu erstellen, die bei der Entwicklung helfen. Deshalb sind weitere VMs vorhanden und können sich dynamisch ändern. Aktuell nicht benötigte VMs können einfach abgeschaltet werden und dauerhaft nicht mehr benötigte VMs, werden gelöscht:

VM-IDs

Im Standard schlägt Promox ve die interne ID beim Erstellen einer VM vor. Diese beginnt im Standard bei 100 und jede weitere VM wird um einen Zähler erhöht. Ist die VM einmal angelegt, ist diese ID fix, bis die VM gelöscht wird. Soll sie nachträglich geändert werden, gibt es noch die Möglichkeit die VM zu klonen und den Klon mit der Wunsch-ID zu versehen. Anschließend wird die ursprüngliche VM mit der unerwünschten ID gelöscht. Dieser Vorgang kann je nach hinterlegten virtuellen Festplatten aufwendig sein. Deshalb sollte sich die ID, wenn sie nicht Standard sein soll, gut überlegt werden. In diesem Setup sind die IDs als Hilfestellung mit den jeweils internen IP-Adressen identisch. IDs dürfen nur Zahlen und müssen eindeutig sein. Hier bedeutet die ID 1010106, dass die VM die interne IP-Adresse 10.10.10.6 hat. Weil Punkte bei IDs nicht erlaubt sind, wurden sie weggelassen. Natürlich sind IDs nicht dafür gedacht, um IP-Adressen abzubilden. Dies ist nur eine kleine Hilfestellung, in diesem Setup und muss so nicht gemacht werden.

Backup-Server

Ein oft vernachlässigtes Thema, sind tägliche automatisierte und im Ernstfall belastbare Backups, mit längerer Historie. Proxmox ve bietet mehrere Lösungen an, um Backups auf einem Storage abzulegen. Der Standort einer Backup-Lösung sollte immer außerhalb des Rechenzentrums sein, wo sich die produktiven Proxmox Nodes befinden. Die effizienteste und zuverlässigste Backup-Lösung für Proxmox ve ist das ebenfalls von Proxmox entwickelte Produkt „Proxmox-Backup-Server“. Es ist eine ebenfalls auf Debian basierende professionelle Lösung, um Backups zu automatisieren, effizient zu speichern (Delta-Abgleich) und auch zu validieren, ob diese konsistent sind. Die Lösung bietet eine eigene GUI mit Dashboards für Admins und sollte in gewisser Regelmäßigkeit überprüft werden, ob alle darauf befindlichen Backups täglich laufen und erfolgreich validiert wurden. Zeitlich sollten die Backups auf dem Proxmox-Node so eingestellt werden, dass sie täglich in der Nacht laufen, wenn nicht viel Betrieb auf den produktiven VMs zu erwarten ist. Außerdem sollte die Benachrichtigungsfunktion im Proxmox ve mit einem gültigen SMTP und eine Admin-E-Mail-Adresse hinterlegt werden, damit bei fehlgeschlagenen Backup-Versuchen ein Admin dies zeitnahe mitbekommt und eingreifen kann. Durch den Delta-Abgleich dieser effizienten Lösung, werden Folgebackups immer nur soweit übertragen, wie es Änderungen im Vergleich zum Vortag gab. Der Proxmox-Backup-Server sorgt dafür, dass alle Backups bei Bedarf wie Full-Backups abgerufen werden können und setzt die Teile beim Abruf zusammen. Physikalisch gespeichert werden allerdings immer nur die Differenzen und diese sind auch noch komprimiert. Dies spart sehr viel Speicherplatz und Bandbreite bei der Übertragung. Der Proxmox-Backup-Server sollte dennoch mit ausreichend Speicherplatz ausgelegt werden, um Backups mit möglichst langer Historie speichern zu können. Dieser Speicher sollte auf Größe und weniger auf Geschwindigkeit ausgelegt sein, was in der Regel das Gegenteil von Speicher auf einem Proxmox ve darstellt. Natürlich sollte auch die Storage-Lösung des Backup-Servers redundante Festplatten haben. Hier eignen sich gängige RAID-Systeme oder auch ein Ceph-Storage gut.