EDV – Ende der Vernunft

Artikel-Schlagworte: „System Management“

Ich denke es gibt viele Definitionen dafür, was System-Management ausmacht. Daher existiert in diesen Bereich auch Software mit sehr unterschiedlichen Funktionen und Funktionsumfang. Um keine Mißverständnisse aufkommen zu lassen, handelt es sich bei der folgenden Liste um Software, die automatisiert Befehle auf einer beliebigen Anzahl an Servern auszuführen kann und unter einer OSS-Lizenz steht.

Die allermeisten Tools benutzen ssh, da es hier einfach ist eine Anmeldung ohne Prompt und Passwort hinzubekommen und da es von Hause aus schon die Möglichkeit mitbringt Befehle auf anderen Systemen auszuführen. Viele Tools erweitern ebenso scp. Hier eine Auswahl:

• Dancers Shell
• Parallel Distributed Shell
• Parallel ssh, scp, rsync, slurp, nuke
• PuSSH is Pythonic, Ubiquitous SSH
• Tentakel
• psh

Folgende beiden Tools bieten erweiterte Funtkionalitäten:

• PIKT – Arbeitet über RPC und bietet zusätzlich Monitoring sowie eine eigene Script-Sprache
• CTL – Zusätzlich Web-Interface mit ACLs und ‘Zuguck’-Modus

Im zweiten Teil geht es dann um Configuration-Management.

Wenn es um die Benutzerverwaltung unter Unix/Linux geht, würde ich die Welt in zwei Lager einteilen:

Die eine Hälfte verplant die UID/GID schön in Blöcken. 0-1000 Systemaccounts, 1001-5000 Mitarbeiter und Externe fangen bei 55000 an. Genauso sieht es bei den GIDs aus. Der anderen Hälfte ist das meiste davon schnurz egal. Ok, die Systemaccounts sollte man frei lassen, aber wenn intressiert schon die UID/GID, hauptsache sie ist überall gleich.

Zu welcher Hälfte gehörst Du und warum?

Wenn man einen Server hat ist die Verwaltung sehr einfach. Aber mit jeden weiteren Server nimmt die Komplexität zu. Um die Übersicht nicht zu verlieren benötigt man mit der Zeit immer mehr Software zur Verwaltung um Neudeutsch das System-Management zu machen. Natürlich gibt einen Berg Open-Source Software, welche hilft die Arbeit zu unterstützen und da ist richtig gute Software dabei:

• OCS Inventory NG – Server Inventarisierung
• Puppet – Aufgaben Automation
• OTRS – Ticket System
• Nagios – Monitoring System
• System Configuration Collector – Sammelt Konfigurations-Änderungen
• Dancer’s shell – Distributed Shell
• dim – Distributed Versioning
• Ctl – Distributed control dispatching Framework und Toolset

Das Problem: Jedes Programm bringt sein eigenes Look&Feel mit, jedes hat seine eigene Benutzerverwaltung. Es gibt keinerlei Integration der Software, alles ist Stückwerk.

Man hört zwar immer wieder darüber wie toll doch Zenoss, Hyperic, GroundWorks, OpenNMS oder OpenQRM sein sollen, nur wird dort in großen Teilen auch das Rad erfunden. Es gibt eine Monitoring-Software und meistens Server Provisionierung – das wars. Ticket-System, Aufgaben Automation? Fehlanzeige.

Das Beste was ich bis jetzt im Bereich System-Managemet gesehen habe ist Bladelogic. Da gibt es zwar keine Inventarisierung oder ein Ticket-System, dafür aber Aufgaben Automation, welche einen die Kinnlade herunterklappen lässt. Allein die Distribtuted Shell ist der Hammer, denn man kann via cd den Host wechseln. Alles was man tut ist voll Rollbackfähig, über RBAC kann man einen bestimmten Benutzer, das Recht geben auf einen bestimmten Host, einen bestimmten Dienst neuzustarten – und zwar nur diesen Dienst. Über selbstgebaute Pakete, welche sowohl Software, als auch Arbeitsabläufe enthalten können, kann man Arbeiten über Einzelsystem oder beliebige Host-Gruppen (Windows, Unix) ausgerollen. Oh, und Server-Provisioning via Kickstart, Jumpstart und Windows-Foo darf natürlich nicht fehlen. Der Haken? Der Preis. Leider ein Punkt, welcher auch Acronis(für seine Aufgabe) von der World-Domination abhält.

Einen Großteil der Bladelogic-Funktionalität könnte man übrigends mit Webmin abbilden – leider hat es keine Shell. Vielleicht findet sich ja mal jemand, der über die Webmin API eine Shell abbildet. Mein Dank würde ihn auf Ewig verfolgen.

Ich hatte heute eine kurze Diskussion darüber, woran man erkennt, das ein Server ausgelastet ist. Liegt es an der CPU-Auslastung? Load von 1 per CPU? Interrupts? Context Switche? IOWait? Averade Service Time? Swap? Vorschläge sind erbeten.

Stefan in den Kommentaren zu BIND 9 Benchmarking: Gentoo wins:

Wenn man keinen Eierlegende-Wollmilchsau-Server betreibt und er nur einen Zweck hat, kann es schon Sinn machen, eine andere Distribution zu nehmen. Das ist vor allem sinnig, wenn es nicht um eins, zwei kleine Server geht, sondern um größere Installationen. Wenn ein System auf gleicher Hardware nur 5% schneller ist und man dadurch 20 Server weniger für jeweils 2500€ kaufen muss, macht eine Umstellung jawohl Sinn, oder?

Da muss ich widersprechen: Standardisierung heisst das Gebot, gerade wenn man mehr als ein-, zwei Server im Schrank stehen hat. Denn Stefan vergisst, das man diese neue Umgebung ersteinmal entwickeln muss, sie muss ins bestehende System-Management integriert werden, man muss sie hegen und pflegen. Am Ende steht man mit 20 verschiedenen Umgebungen da, jede hat ihre eigenen Marotten und will anders gestreichelt werden. Das alles frisst jeden vermuteten Performance-Gewinn mehrfach auf, in Zeit, Nerven und Geld.

Und seien wir doch mal ehrlich: die meisten Server welche man heutzutage so kaufen kann haben mehr Power als man wirklich braucht, da machen die Festplatten IO-mäßig viel früher schlapp und hier bringt mir ein ultra-angepasstes OS so richtig gar nichts.

Bundy beschreibt in Als die Rechner Namen bekamen wie sich das Thema Hostnamen bei ihm entwickelt hat. Fast jeder hat da sein eigenes Konzept, das oftmals davon abhängig ist wieviele Rechner man betreut, wie konservativ die Firma ist, der eigene Geekfaktor und vieles mehr. Geradezu Klassiker sind mittlerweile Hostnamen welche sich an griechichen Göttern orientieren, Star Trek/Star Wars, Simpsons, Futurama meinetwegen auch Desparate Housewifes oder 24 abbilden. Im Kleinen mag das funktionieren, wie zuhause bei mir, aber im Großen sollte es schon etwas ausgereifter sein.

Zuerst sollte man davon Abstand nehmen Hostnamen zu wählen, der auch gleichzeitig einen Dienst darstellt. Nennt man seinen Server zum Beispiel www mag das auf den ersten Blick eine tolle Idee sein, wenn man aber irgendwann mal auf einen anderen Server migrieren möchte geht das Drama los. Viel besser ist es einen abweichenden Hostnamen zu wählen und später einfach nur den DNS-Eintrag für den Dienst zu schwenken.

Oftmals kann man Hosts in Gruppen einsortieren und ihnen eine Funkion zuweisen. Um beim Beispiel Web zu bleiben:

• http-srv – beschreibt einen Web-Server
• http-db – ist eine Datenbank für Web-Server
• http-script – dort liegt die Provisionierung der Web-Server

Logischerweise hat man oftmals mehrere Maschinen mit gleicher Funktion, weswegen eine Durchnummerierung notwendig ist. Kein grosses Ding, man sollte sich nur Gedanken darüber machen, was passiert wenn z.B. http-srv0 abgelöst werden soll. Heisst der neue Server nun auch http-srv0 oder doch lieber http-srv1? Ich halte letzteres für die bessere Lösung. Es ist ein sauberer Schnitt. Keine doppelten oder Spielereien mit temporären Namen und der nächste kann ja wieder http-srv0 heissen.

An dieser Stelle muss der Name noch nicht Zuende sein. Man kann noch weitere Informationen im Hostnamen ablegen wie z.B. den Status des Systemes, ob es sich um eine physikalische Maschine handelt oder eine virtuelle und, wer mag, den Standort.

So ergibt sich z.B. ein Hostname wie http-script0-vta. Also ein Provisionierungs-Server für das Web-System, ein (v)irtueller Server, ein (T)est-System am Standort A.

Als Host-Typ würde mir spontan (v)irtuell oder VMWare, (p)hysikalische Maschine, Solaris-(Z)one einfallen. Beim Status wären es (p)roduktiv, (A)bnahme oder (T)est-System. Der Standort wiederum sollte sich an die Gegebenheiten orientieren. Meist reicht Standort A oder B, sind die Hosts über Deutschland verteilt bieten sich Auto-Kennzeichen an.

Letztlich ist es wichtig eine maximale Länge von Hostnamen vorzugeben. Niemanden ist geholfen mit einen Bandwurm-Namen, andererseits gibt es die Hostname Tab Completion in der Bash und ZSH.

• SystemImager – Sieht nach nen pfiffigen Tool für System-Images aus
• Clusteradmin Blog – Na, da bin ich mal gespannt was da noch kommen soll

Die Entscheidung vermehrt auf CentOS resp. Redhat zu setzen ist mir beileibe nicht leicht gefallen, aber der extrem niedrige Frickelfaktor bei der Installation und die sehr gute Treiber-Unterstützung sind nicht von der Hand zu weisende Argumente. Redhat schenkt einem aber nichts, denn man bezahlt an anderer Stelle dafür. Besonders hart trifft es einen, wenn man von Debian kommt. Von deren Aufgeräumtheit und Verlässlichkeit im Konfigurationsbereich sind die Rothüte Kilometer weit entfernt.

Beispiel Bind unter Redhat/CentOS: Man installiert bind mit yum install bind, man startet es mit service named start, die Konfiguration liegt in /var/named. Unter Debian liegt die Konfiguration, egal ob Bind8 oder Bind9 unter /etc/bind, man installiert mit apt-get install bind(9) und startet mit /etc/init.d/bind(9). Dieses /var/named erinnert mich immer an bind4-Zeiten *schauder*

Oder Apache: Das Debian Konstrukt mit sites-available und sites-enabled ist simpel und effektiv, bei Redhat gibt es soetwas nicht. Dort heisst der Apache-Prozess auch httpd und nicht apache(2) wie bei Debian. Genau das gleiche Spiel bei der Installation: yum install httpd gegen apt-get install apache(2). Alles voll krass logisch und durchdacht.

Ich könnte jetzt wieder über die Netzwerk-Konfiguration lästern, aber das möchte ich nicht nochmal wiederholen.

• Did Microsoft Buy Netcraft? – Schöne Verschwörungstheorie und ich glaube da ist sogar etwas dran
• DSL- und Kaffeeflatrate – Nette Idee, aber mit Starbucks wäre das noch viel l33ter!!!einself
• So THIS is why people want Windows! – Intressante Beobachtung
• Hyperic HQ – OSS Monitoring und Systemmanagement für Linux, Windows, Solaris und HP-UX