Wem am Sonntagabend auffiel, dass LinuxNews für rund eine Stunde nicht erreichbar war, hier ist der Grund dafür: LinuxNews ist auf einen neuen Server umgezogen. Wie der ein oder anderen eventuell bemerkt hat, wurde hier nochmal eine Schippe draufgelegt, was die Auslieferungsgeschwindigkeit betrifft. In diesem Artikel möchte ich etwas tiefer in die Technik abtauchen und ein wenig das Setup beleuchten. Wer sich noch an den Artikel Wie und wo entsteht LinuxNews erinnert, kennt die Leistungsdaten grob. Überholt wurden die Anzahl der Kerne, von 12 auf 16, und der Speicher von 2TByte auf 3TByte.
Die Basis
Die Serverbasis ist der Kernbaustein einer jeden Infrastruktur, bei LinuxNews ist das (noch) ein Debian 11 in einer nicht ganz Standardinstallation. Seit ich mich mit Servern (Windows, Linux & BSD) beschäftige ist weniger mehr, seit mehreren Jahren installiere ich meine Systeme “keep it simple, stupid” oder wie es ein ehemaliger Kollege mal sagte “Räumungsverkauf, es muss alles raus!”. Minimalinstallationen sind einfach toll. Die Vorteile liegen klar auf der Hand, es ist schnell(er), weniger fehleranfällig und sicher(er), denn was nicht da ist hat keine Lücken und macht auch keinen Ärger.
Bei dem Setup dieses Servers wurden nicht einmal die Standard-Systemwerkzeuge installiert, was gebraucht wird kann nachträglich installiert werden. Das einzige zusätzliche was der Installer installieren durfte war der SSH-Server. So ist eine minimale Basis geschaffen die schlank und schnell ist auf der man aufbauen kann. Die übrigen Pakete wurden mit --no-install-recommends installiert um auch hier minimal unterwegs zu sein.
An dieser Stelle auch eine Warnung: Minimal ist nicht immer sinnvoll und kann zu unerwartetem Verhalten/fehlenden Funktionen führen. Bei ALLEN zu installierenden Paketen sollte man sich die Arbeit machen und jede einzelne Abhängigkeit prüfen, ein pauschales --no-install-recommends kann, je nach Paket, zu unerwartetem Verhalten führen. Hierfür kann man keine pauschal gültige Anleitung geben, es kommt zu stark auf den Anwendungsbereich und die benötigten Pakete an. Es ist eine nicht zu unterschätzende Sisyphusarbeit, die viele Testinstallationen und Zeit bedarf.
Webserver und PHP
Ausgeliefert wird alles von NGINX v1.18 und php-fpm 7.4. Da NGINX in der Spitze rund 10.000 Seiten ausliefern muss, ist auch da wenig im Standard belassen. Ein gutes Beispiel sind die worker_connections, diese wurden vervierfacht. Die gzip Komprimierung ist auf Stufe 6 eingestellt und bietet einen optimalen Mittelwert zwischen Last und Performance. Zudem wurde ein Rate Limit eingestellt, um übermäßige Crawler oder sonstiges zu zügeln.
Bei php wurde deutlich mehr angepasst. opcache wurde aktiviert, die pm.start/spare servers vervielfacht, memory _limit auf 16GB und und execution-time auf 3600 Sekunden gestellt. Diese Werte wird man bei keinem normalen Webhoster finden da damit auch sehr viel Unsinn angerichtet werden kann. Hier im kleinen Rahmen ist das allerdings kein Problem – PHP-Skripte die die WordPress-Datenbank bereinigen/optimieren, phpMyAdmin oder auch der wp-cron laufen mit diesen stark erhöhten Werten auch bei größeren Datenmengen sauber und ohne Fehler durch Abbrüche durch. Stark angepasste PHP-Werte ist z.B. eines der Dinge die diese “WordPress-Hoster” tun – sorry, not sorry for ruining your business model. WordPress könnte man auch super auf Plesk betreiben, es steht und fällt mit einem großzügig ausgestatteten PHP.
Datenbank
Die Datenbank der WordPress Instanz ist derzeit kanpp 100 MB groß. Entsprechend groß wurde MariaDB
ausgestattet das in Version 10.4 zum Einsatz kommt. Auch hier wird mit verschiedenen Werten bei max_connections, Memory Cache und Query Optimization gearbeitet. Eine 72 Zeilen lange my.cnf merkt man deutlich im Vergleich mit einer Standardinstallation.
Caching
Das Caching macht den größten Posten bei der Auslieferungsgeschwindigkeit aus. Als Caching-Plugin kommt WP-Rocket zum Einsatz, wie sollte es anders sein, nicht ganz Standard. Das Cache-Verzeichnis von WP-Rocket ist ein mehrere Gigabyte großes tmpfs, die Auslieferung aus dem RAM ist natürlich schneller als von einer SSD.
Auch die Nachteile sollten eine Erwähnung wert sein: tmpfs ist ein Memory-Filesystem und somit nach einem Neustart leer. Bei diesem Anwendungsfall ist das aus zwei Gründen zu vernachlässigen:
Wie oft startet man einen Server neu? (Hier im Schnitt alle 60 Tage, nachts am Wochenende)
Cache wird durch einen Systemd-Timer automatisch befüllt. Im „schlimmsten“ Fall muss für 10 Minuten php ausliefern und nicht das tmpfs. Man könnte argumentieren das ein memcached genau dasselbe macht, aber wir erinnern uns: Minimal und Bordmittel, keine zusätzliche Schicht dazwischen, die Ärger bereitet, Updates oder Konfiguration benötigt.
Sicherheit
Stark durch mein berufliches Umfeld geprägt und einer meiner “versenke 80% der Projektzeit darin”-Aufgaben. Aus Sicherheitsgründen skizziere ich die Masse an Maßnahmen nur grob, aber dennoch: Sharing is caring!
AppArmor
Die Dienste die über das Internet erreichbar sind (NGINX, PHP usw.) sind alle in AppArmor gefangen. Bei 0-Day-Exploits oder fehlerhaften Konfigurationen durch menschliches Versagen sind die Schäden nicht all zu groß.
Backups
Zeit für Zündstoff: Backups werden mit Veeam Backup&Replication 11 erstellt. Spätestens jetzt fragt sich der ein oder andere sicherlich: Wie zum Geier kommt man auf Veeam?! Es ist proprietäre Software!!!
Veeam ist DER Benchmark unter all den Backup-Tools da draußen, jedes andere muss sich daran messen lassen. Die Linux Alternativen wie Borg, DejaDUP oder restic sind dagegen eher niedlich, können einer kompletten Backup&Replication Suite aber niemals das Wassser reichen. Keines der genannten kommt auch nur Ansatzweise an Veeam heran ( Abgesehen von der Tatsache das sie allesamt scheußlich zu konfigurieren sind). Es ist das einzige Stück proprietäre Software das für den Blog zum Einsatz kommt.
Den Grund dafür versteht man nach einem Blick auf die Gesamtinfrastruktur: ESXi, KVM, Linux, macOS, BSD und Windows (Server). Da hat man wenig Lust bei jedem OS das Rad neu zu erfinden, da funktioniert ein Restore so, aber unter BSD wieder anders usw. Veeam ist immer gleich, egal welches System ein Restore bedarf, ein Multitool das (fast) alles kann. Ein solches „gleiches“ Produkt garantiert eine schnelle Wiederherstellung aller Dienste bei/nach einem Ausfall.
IDS
Als IDS wird fail2ban eingesetzt, es schützt vor Logins als auch vor Bots. Hier sind die Einstellungen ebenfalls kaum im Standard. Wurde eine IP innerhalb eines Monats dreimal “erwischt” bleibt sie für einen Monat gesperrt, um ein Beispiel zu nennen. NGINX ist ein Sonderfall, hier laufen die Anfragen in ein Rate Limit. Passiert das innerhalb einer Stunde mehr als dreimal bleibt die IP 24h gesperrt. Aktuell laufen 11 Jails, die das „Hintergrundrauschen“ im Internet weitestgehend fernhalten.
Firewall
Als Firewall kommt nftables zum Einsatz, allerdings ohne Wrapper wie z.B. firewalld (minimal und Bordmittel falls es jemand vergessen haben sollte). Alle Änderungen werden in den Chains der /etc/nftables.conf.d/chain.nft vorgenommen. Zudem filtert NGINX Datenverkehr aus bestimmten Ländern (GeoIP). Portscans sowie Anfragen ohne gültiges SYN werden direkt verworfen und die IP von fail2ban gesperrt.
Monitoring
Als Monitoring wird check_mk genutzt. Es werden unterschiedlichste Parameter abgefragt wie z. B. Auslastung, NGINX Requests, Backup-Status uvm.
Ansible & Graylog
Oder auch Gehirn genannt. Ansible würde man zu Recht nicht in die Kategorie Sicherheit einordnen, eher zu den Deployment Tools. Die Magie beginnt mit dem Zusammenspiel zwischen Ansible, Graylog und check_mk.
Alle Logs und Monitoring-Ergebnisse werden zentral in Graylog gespeichert. Skripte werten die Logs aus. Bei Auffälligkeiten arbeitet Ansible zuvor definierte Playbooks ab, um Gegenmaßnahmen zu ergreifen. Playbooks sind für die unterschiedlichsten Situationen vorbereitet z. B. Festplattendefekt, Crash eines Systemd-Service, DDoS uvm.
Daten, Daten, Daten!
Eine Seite dieser Größe hat natürlich ein wenig Traffic und Storage-Bedarf. Aktuell verursacht LinuxNews auf der Infrastruktur:
- 270 GByte Traffic out pro Monat
- 628,4 MByte Festplattenspeicher
- 3 GByte tmpfs
- 100 MByte Datenbank
Alles in allem eine nette Nebenbeschäftigung, eine Seite dieser Größenordnung zu hosten und ich danke Ferdinand für diese Möglichkeit etwas an die Community zurückzugeben. Ich hoffe, dieser Einblick in den Unterbau hält für den ein oder anderen interessante Einblicke bereit. Wir können gerne in den Kommentaren über das Setup und einzelne Entscheidungen diskutieren.