Vor einiger Zeit habe ich bereits ein Cluster-Setup auf Pacemaker/Corosync-Basis unter Debian Wheezy hier verbloggt. Seitdem hat sich im Pacemakerumfeld ein wenig was getan und somit ist es an der Zeit für ein Update, diesmal mit CentOS7.
Die größte Neuerung (für mich) war der Wegfall des Cluster Resource Managers (crm), er wird durch pcs bzw. pcsd ersetzt, letzterer stellt sogar ein komfortables Webinterface zur Verwaltung des Clusters zur Verfügung.
Ich habe kürzlich beschlossen etwas über meinen Linux-Tellerrand zu schauen und habe mich mal ein wenig mit CentOS beschäftigt. Anfangs war auch alles ziemlich einfach, VirtualBox und los. Aber auf Dauer macht sowas nicht glücklich, also habe ich mich entschlossen es auf Xen-Basis nochmal zu probieren. Die erste Ernüchterung Xen auf CentOS 7-Basis geht nicht. CentOS 6.5 würde gehen, aber ich habe mich entschieden dann doch auf den bewährten Debian-Unterbau zu setzen.
Bisher habe ich gerne One Time Passwords (TOTP, Time based One Time Password) mittels OPIE unter Debian genutzt. Leider ist OPIE in aktuellen Debianversionen nicht mehr dabei.
Als Alternative kann man das PAM-Modul “google_authenticator” verwenden. Es funktioniert zwar etwas anders als OPIE erhöht aber die Sicherheit auf ähnliche Weise. Während man bei OPIE quasi wählen kann ob man sich mit seinem normalen Password oder aber mit einem One-Time-Password anmelden möchte benötigt man beim google_authenticator stets beides.
Aufmerksame Leser werden bemerkt haben dass wir uns einen kleinen Hostingcluster geleistet haben. Um die Xen-Maschinen auf diesem möglichst gut abzusichern haben wir uns entschieden diesen keine Internetverbindung zu spendieren.
Da dort hauptsächlich Webanwendungen liegen mag das zunächst kontraproduktiv wirken. Mit einem Reverse-Proxy funktioniert das aber sehr gut. Hardwaretechnisch besteht der Proxy aus zwei Maschinen in einem Active/Passive-Cluster, den man später zum Loadbalancer umrüsten könnte. Softwaretechnisch haben wir uns hier für nginx entschieden.
Für unseren Testserver brauchte ich eine Möglichkeit eine virtuelle Xen-Maschine auf ein anderes System zu klonen. Auf der Dom0 wird hierzu ein LVM-Snapshot der zu klonenden Maschine erzeugt, damit sich die Daten während des Kopiervorgangs nicht verändern.
Das Ziel des Kopiervorgangs ist eine andere Dom0, welche per SSH erreichbar ist. Ausgelöst wird der Kopiervorgang von einem dritten System aus, weil nur hier die nötigen SSH-Keys vorliegen (der Befehl ist Teil eines komplexeren Scripts welches weitere Informationen von anderen Rechnern per SSH einsammelt).
Insgesamt sind an dem Kopiervorgang also drei Systeme beteiligt. Der Rechner von dem aus das Script gestartet wird, die Quell-Dom0 und die Ziel-Dom0.
In den vorangegangenen Artikeln wurden ja bereits einige Beispiele für Konfigurationen mit Hilfe von Salt gegeben, (mind.) ein Beispiel fehlt aber noch. Gerade bei Tools zur Serverüberwachung, wie zum Beispiel Icinga oder Munin, müssen Konfigurationsdateien auf verschiedenen Rechnern gepflegt werden. Der Client (also der zu überwachende Rechner) muss z.B. wissen welche Daten er erheben soll und an wen er sie weitergeben darf. Der Monitorrechner muss wissen bei welchen Rechnern er Daten abholen soll.
Bei Salt ergibt sich hier ein Problem. Die Konfiguration gilt immer nur für den jeweiligen Minion. Der Minion der als Monitor dient weiß nichts von den anderen Rechnern und der zu überwachende Rechner weiß nichts über den Monitorrechner.
So, nach längerer Abstinenz hier mal ein kleiner Rundumschlag. Ich habe zuhause einen kleinen Atom-Rechner im mini-ITX-Format, der leider kürzlich den Geist aufgegeben hat. Zeit für etwas Neues. Das System dient hauptsächlich als Fileserver, aber auch als Spielwiese. Damit man auch wirklich mal einige Dinge ausprobieren kann ohne das eigentliche System vollzusauen habe ich mich für ein Xen-Setup entschieden.
Wie man ein System mit Xen aufsetzt habe ich ja schon zu genüge hier im Blog breitgetreten. Hier soll es jetzt darum gehen, ein Cluster-Setup auf dem System einzurichten. Klar, mir nur einem Server ist das nicht so wahnsinning zielführend, aber es geht ja um eine Spielwiese.
Salt Stack ist ein Tool zur Verwaltung von Rechnern in einem Netzwerk. Es ist damit sehr leicht möglich eine große Anzahl von Maschinen einheitlich (oder auch individuell) zentral zu Konfigurieren.
Der Artikel geht von einem Hostingsetup mit mehreren Xen-Maschinen im Clusterbetrieb aus.
Wer einen Server mit Xen betreibt wird häufig eine bestimmte Grundkonfiguration für die virtuellen Maschinen (VM) verwenden. Diese bei jeder neuen Maschine manuell herzustellen ist fehleranfällig und zeitaufwendig.
Mit Xen-Tools kann man hier Abhilfe schaffen.
Eine Benutzerverwaltung über LDAP ist eine feine Sache. Problematisch wird es, wenn ein Benutzer sich über LDAP anmelden möchte und der LDAP-Server nicht zur Verfügung steht, z.B. weil es sich um ein Notebook eines Außendienstmitarbeiters handelt. Unter Windows ist dies meist ohne Probleme möglich, sofern der entsprechende Benutzer sich ein Mal in Gegenwart des LDAP-Servers an dem Notebook angemeldet hat.
Unter Linux ist etwas Zusatzarbeit nötig:
sudo apt-get install nss-updatedb libnss-db libpam-ccreds...