Mal wieder einen guten Morgen hier bei mir im SysAdmin-Blog. Der Umzug in ein neues Bürogebäude steht an, und da das alte noch vorhanden ist und ich keine Hardware mitnehmen kann, muss auch neue Hardware angeschafft werden.

Wir betreiben immer zwei Internet-Anschlüsse parallel. Einmal DSL, und einmal Coax. Das hat mehrere Gründe, aber hauptsächlich tun wir es, weil momentan in unserer Stadt sehr viel gebaut wird, und es das eine oder andere mal zu einem Ausfall kommt.

Normal haben wir immer Load-Balancer benutzt, meistens von TP-Link. Leider haben diese einige Nachteile. Um nur mal ein paar zu nennen:

  • Langsamer Failover
  • Load Balancing funktioniert in den seltensten Fällen
  • Langsame und grauenvoll schlechte Konfigurationsinterfaces
  • Einige Funktionen funktionieren schlicht und ergreifend nicht richtig

Und deswegen wollte ich es diesmal richtig machen: Ich wollte pfSense einsetzen. Da kann ich konfigurieren wie ich Bock habe, kann meinen DHCP Server anpassen, und habe Zusatzfunktionen ohne Ende. Plus, die Hardware kann ich selbst gestalten und reparieren wenn nötig.

Leider ist es nun so, dass die offiziellen Netgate Boxen ziemlich teuer sind, und es auch recht teuer ist, „nur für einen Router“ extra einen Rechner zu bauen. Zusätzlich brauche ich noch ein NAS bzw. Backup-Server, Druckerserver, generell einen Server wo man mal schnell ne VM aufsetzen kann, VPN-Server… wir sehen, wohin das führt.

Und dann kam mir die zündende Idee: Virtualisier‘ den Kram doch einfach! Das hat nur Vorteile. Ein System mit vernünftigem Anschaffungspreis. Router zu klein dimensioniert? Hier hast du zwei Kerne und ein paar GB RAM mehr. Ja, das kann auch Nachteile haben. Beispielsweise, dass direkt alles aussteigt, wenn der Server die Grätsche macht. Wenn der Load-Balancer aber den Geist aufgibt, hast du ein ähnliches Problem.

Also Hardware rausgesucht und folgende Konfiguration zusammengestellt:

  • 4HE Server Gehäuse
  • ASRock B550 Phantom Gaming Mainboard
  • Intel PRO/1000MT Server Netzwerkkarte (2 Ports)
  • Digitus Realtek 1GBit PCIe Netzwerkkarte
  • AMD Ryzen 5 3600
  • 32GB Crucial DDR4 RAM
  • 120GB Patriot Burst SATA Boot-SSD
  • 2 x 2TB Toshiba NAS HDD (RAID1)
  • 550W be quiet! Pure Power 80+ Gold Netzteil
  • ZOTAC nVidia GT710 Grafikkarte (die günstigste, die ich fand)

Erstmal ausreichend Leistung. 32 GB RAM und 12 Kerne (ok, Threads) sollten für einige VMs genügen.

Der Plan war, Proxmox VE zu nutzen und dort pfSense, FreeNAS und Debian zu virtualisieren. Dazu aber später mehr.

Beginnen wir mit Proxmox, denn das machte mich regelrecht wahnsinnig. Ich installiere es, konfiguriere eine VM, alles problemlos. Dann starte ich die VM… und verliere die Verbindung zum Server. Auf dem Monitor sind zig Fehlermeldungen zu sehen, die mir sagen sollen, dass der ext4 Superblock nicht geschrieben werden konnte.

Zuerst dachte ich, das hätte mit LVM Thin Provisioning zu tun, also deaktivierte ich das indem ich das LVM Volume löschte und durch eine normale Partition ersetzte. Das brachte keine Besserung. Danach habe ich das SATA-Kabel getauscht, um keine Besserung festzustellen. Nachdem ich ziemlich gefrustet war, habe ich eine alte (aber funktionsfähige) HDD rausgekramt und darauf Proxmox installiert, damit sich hier auch wieder nichts ändert. In meinem Kopf hörte ich schon die Stmmen: „Na geil, Speichercontroller…“ – besonders, da nach einem Wechsel des SATA-Ports ebenfalls keine Besserung eintrat.

Ich bootete also von einem Stick mit Fedora und machte einen
badblocks -wsv /dev/sda um zu sehen, dass dieser problemlos durchlief. Ich dachte, ich bin im falschen Film. Letztenendes habe ich XCP-ng auf dem Server installiert, und siehe da, alles klappt.

Da ich aber mit XenServer wirklich keine Erfahrung habe und daher lieber KVM nutzen wollte, habe ich mich entschieden: „Roll your own.“

Heißt also: Ich installiere mir Debian und konfiguriere alles selbst.

Ein VM-Server auf Debian-Basis.

Heruntergalden habe ich mir das Image firmware-10.5.0-amd64 und den „Expert Install“ gewählt. Zusammengefasst habe ich folgende Konfiguration vorgenommen:

  • Debian-Basissystem
  • EFI-Bootmodus
  • SSH-Server aktiv
  • Debian-Desktopumgebung mit MATE (da ich noch nicht so gut im Umgang mit virsh bin)
  • Unattended-Upgrades aus

Die Partitionierung von /dev/sda (120GB Patriot Burst) sieht folgendermaßen aus:

/dev/sda1 auf /boot/efi, 512M, FAT32 
/dev/sda2 auf /boot, 1024M, FAT32 
/dev/sda3 auf /, 110G, ext4-journal 
/dev/sda4 auf SWAP, 9G, Linux SWAP/Solaris

Nach der Installation muss ich erst einmal alles installieren, was mir die Virtualisierung ermöglicht:
# apt install virt-manager qemu-kvm bridge-utils libvirt-clients libvirt-daemon-system virtinst ibvirt-daemon vim neofetch ovmf

Anschließend noch libvirtd starten und in den Autostart packen.

# systemctl enable --now libvirtd

Um mir die Arbeit einfacher zu machen und sicherer zu gestalten, habe ich mich in die sudoers gepackt.

# EDITOR=vim visudo

Wenn wir schon beim Thema Sicherheit sind, QEMU muss nun wirklich nicht als root laufen:
$ sudo usermod -aG $(whoami) qemu
$ sudo usermod -aG $(whoami) qemu-kvm
$ sudo usermod -aG $(whoami) libvirt

Danach sollte man dem Kernel noch mitteilen, dass man gerne IOMMU nutzen würde:

$ sudo vim /etc/default/grub && sudo update-grub

In /etc/default/grub sollte man LINUX_CMDLINE_DEFAULT="amd_iommu=on" spezifizieren.

Nachdem die Basics jetzt geklärt sind, wird es Zeit, das System einmal neu zu starten und unsere VMs einzurichten. Nach dem reboot beginne ich, zuerst meine pfSense VM einzurichten und stelle fest, das ist gar nicht so einfach. Die Netzwerkkarten werden, egal in welcher Reihenfolge, nicht korrekt in die IOMMU Gruppen eingeteilt und lassen sich somit nicht per PCIe Passthrough direkt an die VM durchreichen.

Deswegen gehe ich einen anderen Weg. Zuerst muss klar sein, dass wir den Router, den der Server selbst auch nutzen soll, auf dem Server selbst laufen haben. D.h. er hängt von einer VM ab, die auf ihm läuft. Das Netzwerk kann also nicht automatisch konfiguriert werden, während der Server läuft.

Außerdem müssen wir dringend unterbinden, dass Debian irgendwas, aber auch nur irgendwas, an der Netzwerkkonfiguration im laufenden Betrieb ändert. Das würde bedeuten, dass ggf. am Ende niemand mehr ins Netzwerk kann. Denn bedenkt, wir haben vier Netzwerkkabel, die am Ende am Server angeschlossen sind:

enp3s0f0: WAN-Port 1
enp3s0f1: WAN-Port 2
enp4s0: LAN-Port, an den der Switch angeschlossen wird
enp6s0: Management-Port auf dem Mainboard, soll normaler Client im Netzwerk sein

Das heißt, wir müssen erst einmal unterbinden, dass Debian irgendwas machen kann. Ich schmeiße NetworkManager raus.

$ sudo systemctl disable --now NetworkManager

Dann konfiguriere ich mein Interface in /etc/network/interfaces:

$ sudo vim /etc/network/interfaces

Mein Inhalt nach meinen Anpassungen:

auto lo
iface lo inet loopback

auto enp6s0
iface enp6s0 inet static
	address 10.10.11.2
	gateway 10.10.11.1

Dann muss ich ihm noch beibringen, dass er bitte einen DNS Server nutzen soll: $ sudo vim /etc/resolv.conf

Dort habe ich drin stehen: nameserver 8.8.8.8

Da ich das Problem habe, dass resolvconf mir gerne mal einen Strich durch die Rechnung macht, und sich der nicht so schnell ändern wird, sorgen wir einfach mal dafür, dass der so bleibt.

$ sudo chattr +i /etc/resolv.conf

Nun beginne ich, mit virt-manager meine pfSense VM einzurichten. Die Konfiguration der VM ist folgende:

CPU: QEMU Virtual CPU v2.5+, 2 Kerne 
RAM: 2 GB 
Chip: i440fx 
Disk: qcow2, 8GB; VirtIO 
NW: enp3s0f0, Passthrough, e1000e 
NW: enp3s0f1, Passthrough, e1000e 
NW: enp4s0, Passthrough, rtl8139

Dann pfSense konfiguriert, um enp4s0 als LAN-Port und die beiden anderen als WAN-Ports zu verwenden (em0, em1 -> WAN und OPT1); (rt0 -> LAN)

Bis jetzt läuft nach meinen Tests alles absolut stabil und mit voller Geschwindigkeit.

Internet gibts natürlich nur, wenn die VM läuft. Also: VM bei Boot automatisch starten lassen! Für den Notfall sollte man aber Maus, Tastatur und Monitor bereithalten. Man sollte zwar per 10.10.11.2, da diese statisch konfiguriert ist, auch ohne die VM per SSH drauf kommen, allerdings würde ich mich im Ernstfall nicht darauf verlassen.

Nun zu unserer Backuplösung. FreeNAS war ganz schnell in KVM installiert und die Geräte als Blockdevice durchgereicht, allerdings werde ich FreeNAS durch eine andere Lösung ersetzen, da das virtualisieren von FreeNAS ausdrücklich nicht empfohlen wird und ich mir damit ehrlich gesagt nicht traue.

Falls jemanden doch die Konfiguration der FreeNAS-VM interessiert:

CPU: QEMU Virtual CPU v2.5+, 4 Kerne 
RAM: 12 GB 
Chip: i440fx 
Disk: qcow2, 8GB; VirtIO 
Disk: /dev/sdb, 2TB; VirtIO 
Disk: /dev/sdc, 2TB; VirtIO 
NW: enp6s0, Bridge, VirtIO
Kategorien: Sysadmin-Blog

0 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.