Neuer Anoxinon Server

Vorwort

Wie im WriteFreely bereits erwähnt, sollte es ja noch einen Beitrag zu dem Neuem Server geben; der hier mit gegeben sein sollte.

Wie alle begann

Anoxinon hatte in der Vergangenheit sowohl Cloud/OpenStack Server als auch RootServer bei Hetzner im Einsatz. Hierbei gab es aber immer das Problem das die nie so recht zu dem, was wir brauchten, passend skalieren wollten. Bei dem einen war es nicht ausreichend RAM bei dem Anderen sehr viel Anforderung an die IO durch die dort laufende Mastodon Instanz unter https://social.anoxinon.de. Zudem war alles Live; Mal eben Updaten war nicht und Testen von Anpassungen war auch schwieriger.

Durch ein ganz anderes Projekt kam es nun zu der Überlegung, ob wir nicht eine bestimmte Art von Setup vortesten konnten. Was im Grunde ein eigener Root Server in Colo gewesen wäre; Na ja, was soll man Sagen, das wurde es denn auch.

Den Server hatten wir schon, ein DELL R630 1HE Server mit 2 Xeon CPUs und 1,5 TB RAM. Leistungsmerkmale die erstmal sehr Ausreichend waren. Bei dem Storage hatten wir aber nur 2 × 1 TB SSD und 8 × 2 TB HDD, was ausreichend ist, aber natürlich bedeutet das man mit HDD Latenzen im Storage Planen muss.

Server Einrichtung

Natürlich bekommen wir einen einzelnen Server nicht zu 100 % Ausfall sicher umgesetzt; diesen Status hatten wir aber auch bei den Hetzner Server nie erreicht. Hier konnten wir aber deutlich mehr auf die Hardware setzten, da wir ECC Reg. RAM hatten und sowohl die SSDs als auch HDDs, aus dem Enterprise Bereich stammten.

Distrobition

Hier wurde es, wie auch schon bei den Hetzner Server ein Proxmox. Das OS ist schön nah an Debian, hat wenig unnötige Eigenheiten und vor allem ist es ein OS das Visuell auch neue Admins den Einstieg erleichtert.

Storage-Architektur

Verschlüsselung

Natürlich wollen wir den Server nicht unverschlüsselt laufen lassen, also haben beide SSD eine LUKS Partition die beim Booten erst mithilfe von DropBear entsperrt werden muss.

RootFS

Das RootFS basiert auf einem BTRFS mit seinen eigenen RAID1 Fähigkeiten. Hauptgründe dafür sind, seine SSD Unterstützung, was die Lebenszeit der Blockdevices schont, die Kompressionsfähigkeiten und vor allem der Umstand das ein BTRFS im laufenden Betrieb jederzeit umgebaut werden kann. Etwas das man sonst nur bei Ceph oder bedingt bei LVM mit pvmove hinbekommen könnte.

HDD

Die HDD (8 Stück) fußen zwar auch auf einem BTRFS, aber hier wird diesem nicht das RAID Überlassen; Schlicht weg, weil man viele gute Worte über BTRFS verlieren kann, aber seine RAID5/6 Stabilität gehört nicht dazu. Also haben wir hier als Erstes wieder je 2 TB Device eine Partition mit LUKS welche durch die /etc/crypttab behandelt wird, darauf ein MDADM mit RAID6 und auf dem /dev/md0 Device dann das eigentliche BTRFS.

Zusammenspiel von SSD und HDD

Proxmox hat am Ende beide Storages (SSD, HDD) als einzelne Storages konfiguriert bekommen. So haben wir je VM und Container (LXC) die Wahl wo wir welche Disk hinlegen wollen. So können wir auch mal eine Disk auf HDD Auslagern und ggf. das RootFS eines Containers von dessen Storage Mountpoint unabhängig machen, in dem wir dieses auf HDD lagern.

Proxmox

Installation & Grundkonfiguration

Basis installation

Neben den schon erwähnten LUKS, MDADM und DropBear haben wir natürlich auch ein BMC/IPMI/iDRAC das wir steuern können/wollen; Daher das Paket ipmitool mit auf das System kommt. Damit haben wir dann die letzten Anpassungen an BMC vorgenommen, wobei dir die Haupteinstellungen für das Netzwerk schon im BIOS Vorort gesetzt hatten, damit wir über das von in-Berlin bereitgestellte VPN an das BMC kamen.

Damit in-Berlin bei sich die Option hat, an ihren Switchen zu sehen, welche Server an welchen Port angeschlossen sind, haben wir bewusst das Packet lldpd installiert und aktive gelassen. Dammit ist es möglich zu sehen, welches andere System an welchem Port läuft, was dann bspw. so aussieht:

root@proxmox-02:~# lldpctl 
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    fwpr102p0, via: LLDP, RID: 1, Time: 10 days, 23:41:04
  Chassis:     
    ChassisID:    mac 18:66:da:f0:23:38
    SysName:      proxmox-02.anoxinon.de
    SysDescr:     Debian GNU/Linux 13 (trixie) Linux 6.17.2-1-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.2-1 (2025-10-21T11:55Z) x86_64
    MgmtIP:       217.197.91.197
    MgmtIface:    8
    MgmtIP:       2a0a:4580:1061::1
    MgmtIface:    8
    Capability:   Bridge, on
    Capability:   Router, on
    Capability:   Wlan, off
    Capability:   Station, off
  Port:        
    PortID:       mac 52:7d:6d:49:28:64
    PortDescr:    fwln102i0
    TTL:          120
    PMD autoneg:  supported: no, enabled: no
      MAU oper type: 10GbaseT - Four-pair Category 6A or better, full duplex mode only

Neben den typischen Admin Helfern wir vim, tmux, jq, systemd-timesyncd und pipx, würden natürlich auch die Tools zu Übersicht nicht fehlen, wie bspw. htop, lshw, nmon, bpytop, net-tools, hyfetch und glances.

Eine Besonderheit bei der CPU Thematik, wenn man mehr als nur eine CPU hat, ist numactl mit dem man ggf. bei NICs schauen muss das die auf der richtigen CPU arbeiten, wobei wir auch nur mit 2 X 1 GB Ethernet angebunden sind und es da nicht so Problematisch ist. linux-cpupower schaut dann noch das dir etwas Strom einsparen.

Da wir ja BTRFS ein setzten, dürfen btrfsmaintenance und snapper nicht fehlen. Ersteres kümmer sich um Scrubs und Defrag bei HDD und das letztere mach automatisierte Snapshots vom RootFS, nicht aber von den Containern.

Mit postfix haben wir dem Server dann noch zum Mailversand verholfen, auch wegen MDADM aber vor allen wegen logwatch, das uns über relevante Änderungen auf dem Server informiert.

Mit fail2ban haben wir den Server dann noch abgesichert, so das zu viele SSH Loginversuche abgestraft werden, was bei Proxmox sehr relevant ist, da SSH Root Authentifikation auch via PW möglich ist.

Zur IPv6 SLAAC und die Nutzung der IPv4 im gewohntem NAT Verhalten, haben wir noch radvd und haproxy installiert.

Host-Netzwerkkonfiguration

Physische Interfaces

Der Server verfügt von Haus aus über 1 dediziertes BMC Interface das wir auch nutzten und 4 X 1 GB RJ45 Ethernet Interfaces. 2 dieser 1 GB Ethernet Interface fassen wir via LACP zusammen und geben damit dem Host das Interface bond0.

An sich hätten wir auch 10 GB oder 40 GB Interfaces bereitstellen können, da in-Berlin das aber nicht anbietet, haben wir auf den Verbau der NICs verzichtet.

Das bond0 wird nicht Proxmox typisch an vmbr0 gebunden und hier rüber die Primäre IPv4 und IPv6 des Servers angebunden.

LXC Netze

vmbr0

Dieses Interface wird an sich nur für IPv4 Adressen genutzt, daher Container hier mit drauf gelegt werden, wenn sie über eine Eigene IPv4 nach draußen reden sollen. Aktuell haben wir aber nur 2 Adressen für IPv4, weil eine für das veraltete dreckige NAT gedacht ist und eine für den Mail-Server später.

vmbr1

Dies ist das primäre IPv6 SLAAC Interface für die Container, auf dem so gut wie jeder Container ein Interface haben sollte.

vnet0

Dies ist ein IPv4 und IPv6 Netz, bei dem es vorgesehen ist, statisch IP-Adressen zu vergeben. Bis Dato nicht in nUtztung.

vnet1

Dieses Netz weist via DHCP IPv4 und IPv6 Adressen zu, die beide via NAT behandelt werden und daher das IPv6 hier einem ULA entspricht.

Firewall

Ja wir haben die Proxmox Firewall aktive, setzten aber am Ende bei jeden Dienst auf ein Zero Trust Ansatz. Sprich, jeder Container hat über seine IPv6 Adresse ein Zertifikat erhalten und sichert sich mit Auth Systemen ab. Bei einiger Software ist es aber durchaus mal möglich, dass das aufsetzen nur mit Podman geht oder gar nur via Docker und dann ist es meist auch kaum möglich ihn vernünftige Zertifikate beizubringen. Um hier die Möglichkeiten der ungewollten Vorfälle zu reduzieren, schlagen wir uns dennoch mit einer FW herum, um bspw. gerade in Stage unbedachter mal Dienste testen zu können.

Fazit & Zukunft

Der Server steht bereit, in der Stage-Umgebung wird fleißig gearbeitet und es geht weiter. Der Server soll noch mehr Monitoring und Test bekommen. Ein weiteren vnet2 wird noch mit reinem IPv6 SLAAC und 6to4-NAT bekommen. Da wir nun deutlich mehr Dienste mehr als 1x haben wird es auch wieder mehr Automatisierung durch Ansible geben. Die Tage werde ich viel in der Netbox nach Dokumentieren, so das ihr hier mehr nachvollziehen könnt.