Serverkonsolidierung mit Jails: Unterschied zwischen den Versionen
Rabe (Diskussion | Beiträge) K (→Inspektion: manpage-links) |
Rabe (Diskussion | Beiträge) K (→Basissystem im Jail updaten: manpage-link) |
||
Zeile 69: | Zeile 69: | ||
Wenn das durchgelaufen ist, dann dringend mit mergemaster updaten: | Wenn das durchgelaufen ist, dann dringend mit mergemaster updaten: | ||
jailhost# mergemaster -D/data/jails/ServerA/ | jailhost# {{man|freebsd|8|mergemaster}} -D/data/jails/ServerA/ | ||
Das ist der zweifelsohne aufwendigste Schritt, da so ziemlich alles, aber eben nicht alles, upgedatet wird. Besonders Augenmerk sollte hier auf /etc/master.passwd, /etc/motd, /etc/mail/* und alle anderen händischen Konfigurationen gelegt werden, unproblematisch ist /etc/rc.d/, da dieses komplett ersetzt werden sollte, d.h. alte Dateien löschen, neue Dateien 1:1 installieren. | Das ist der zweifelsohne aufwendigste Schritt, da so ziemlich alles, aber eben nicht alles, upgedatet wird. Besonders Augenmerk sollte hier auf /etc/master.passwd, /etc/motd, /etc/mail/* und alle anderen händischen Konfigurationen gelegt werden, unproblematisch ist /etc/rc.d/, da dieses komplett ersetzt werden sollte, d.h. alte Dateien löschen, neue Dateien 1:1 installieren. |
Version vom 17. Juli 2007, 15:26 Uhr
Dieser Artikel beschreibt Möglichkeiten, gewachsene Strukturen mit FreeBSD-Servern auf weniger Hardware zusammenzufassen. Doch oftmals lassen sich individuell konfigurierte Systeme nicht auf einen gemeinsamen Nenner bringen. Der perfekte Anwendungsfall für Virtualisierung, in diesem Fall mit FreeBSD-Jails.
Praxis
Ausganssituation
In einer nicht näher benannten Umgebung existieren noch einige FreeBSD-Installationen, die aufgrund von Nachlässigkeit oder niedriger Priorität nie upgedatet wurden, zum einen weil es möglicherweise zu komplex gewesen wäre, zum anderen weil Sicherheit hier keine primäre Rolle spielt. Never touch a running system also.
Moderne Hardware wird immer leistungsfähiger, bestehende Systeme haben jedoch gleichbleibenden oder verminderten Ressourcenbedarf. Alte Systeme 1:1 auf moderne Hardware umzuziehen ist eine Kostenfrage, falls so alte Systeme überhaupt auf moderner Hardware laufen.
Beispiel
Im Beispiel geht es um 3 Server:
- ServerA
- FreeBSD 4.10, Webserver mit SSL-Support und eigenem Zertifikat, Apache 1.3 und PHP 4.x, Verfügbarkeitsanforderung, aber niedrige Hitrate.
- ServerB
- FreeBSD 4.9, Webserver mit SSL-Support mit SnakeOil-Zertifikat, Apache 1.3 und PHP5.0.x, Hohe Verfügbarkeitsanforderung, viele Hits, wenig Ressourcenbedarf (statischer Content). Außerdem Fremdsoftware, die für dieses System maßgeschneidert wurde mit bekannten Problemen bei Updates (PHP Inkompatiblitäten), sehr unflexibel.
- ServerC
- FreeBSD 4.7, Samba-Server mit Apache und PHP-Uralt. Für Legacy-Applikationen mit teilweise noch urzeitlichem PHP-Code, register_globals=on, schwer wartbare Software, wirr gewachsene Verzeichnisstrukturen und verstverdrahtete Abhängigkeiten auf Pfade.
Problem
Es ist nahezu ausgeschlossen, diese Systeme mit vertretbarem Aufwand auf ein System zusammenzufassen, auch wenn dies in der Theorie kein Problem darstellen würde.
Umsetzung
Vorbereiten
Ein vorhandener Jailserver, hier mit FreeBSD 6.2, wird für 3 weitere Jails vorbereitet. Der Konvention folgend werden die Verzeichnisse /data/jails/ServerA/, /data/jails/ServerB/, /data/jails/ServerC/ leer angelegt. Weiterhin müssen jailhost-spezifische Einstellungen vorgenommen werden, etwa in /etc/rc.conf, /etc/fstab.ServerX, ...
Live-Transfer
Mittels ssh "dump" | restore werden die einzelnen Filesysteme der Urserver transferiert, alternativ auch durch transfer von einzelnen dump-Files (nicht empfehlenswert).
jailhost# mkdir /data/jails/ServerA jailhost# cd /data/jails/ServerA/ jailhost# ssh root@ServerA "dump -0ua -f - / | buffer " | buffer | restore -v -rf - jailhost# cd /usr jailhost# ssh root@ServerA "dump -0ua -f - /usr | buffer " | buffer | restore -v -rf - jailhost# cd ../var/ jailhost# ssh root@ServerA "dump -0ua -f - /var | buffer " | buffer | restore -v -rf -
Entsprechend für alle Partitionen durchführen. Ist auf dem Zielsystem FreeBSD 5.x oder neuer, dann braucht dump noch die Option "-L", um auf einem Filesystem-Snapshot zu arbeiten.
Anpassungen
- Backup von ServerA/etc durchführen
- nicht benötigte Dateien und Verzeichnisse löschen, sofern vorhanden
jailhost# cd /data/jails/ServerA/ jailhost# rm -Rf usr/src usr/ports usr/obj/usr/src; mkdir usr/ports jailhost# rm -Rf boot/ kernel* jailhost# rm -Rf dev/ ; mkdir dev
- vorhandenes rc.conf sichern und bis auf die eigentlichen Dienste (apache_enable="YES", ... ) alles auskommentieren oder besser noch löschen, in Jails benötigt man kein Hardware- und Netzwerksetup, das leistet der Jailhost.
- vorhandene /etc/fstab löschen oder alles auskommentieren
Basissystem im Jail updaten
Das heikelste folgt nun, das Update des Basis-Systems. Im aktuellen Beispiel wird von 4.10 auf 6.2 upgedatet, jedoch "offline", d.h. aus dem unter 6.2 laufenden Jailhost heraus.
Auf dem jailhost liegt unter /usr/src das aktuell laufende Release, hier z.B. die Sourcen von 6.2-RELEASE-p6 Falls diese noch nicht kompiliert wurden, diese zunächst frisch kompilieren.
jailhost# cd /usr/src jailhost# make -j2 buildworld
Einen frischen Kernel benötigen wir nicht, daher ohne "buildkernel". Die gebaute Welt kann nun in das Jail installiert werden:
jailhost# make installworld DESTDIR=/data/jails/ServerA/
Wenn das durchgelaufen ist, dann dringend mit mergemaster updaten:
jailhost# mergemaster(8) -D/data/jails/ServerA/
Das ist der zweifelsohne aufwendigste Schritt, da so ziemlich alles, aber eben nicht alles, upgedatet wird. Besonders Augenmerk sollte hier auf /etc/master.passwd, /etc/motd, /etc/mail/* und alle anderen händischen Konfigurationen gelegt werden, unproblematisch ist /etc/rc.d/, da dieses komplett ersetzt werden sollte, d.h. alte Dateien löschen, neue Dateien 1:1 installieren.
Erster Startversuch
Wenn das Jail gemäß der lokalen Konventionen formal korrekt eingerichtet ist, kann es nun gestartet werden:
jailhost# /etc/rc.d/jail start servera
Inspektion
Per jls(8) und jexec(8) können wir in das Jail einsteigen.
jailhost# jls JID IP Address Hostname Path 1 10.11.12.13 ServerA /data/jails/ServerA jailhost# jexec 1 bash ServerA# (im Jail!)
ServerA konnte erfolgreich gestartet werden, Apache läuft soweit und antwortet auf Requests.