Szenario: Man hat die Anforderung, ein Login mit SSH via Kerberos in einer Microsoft AD-Umgebung zu ermöglichen, z.B. mit einer modernen Version von PuTTY. Wenn man danach jetzt im Internet sucht, findet man sehr oft Lösungen, die davon sprechen, daß man da Samba installieren muß, mit "winbind" etc. Die Sache geht aber deutlich einfacher, wenn man z.B. Microsoft Services for Unix verwendet, wie wir das in der Firma, in der ich derzeit tätig bin, tun. Was man mit MS SFU macht ist, daß man im LDAP einfach zusätzliche Attribute anlegt die dann z.B. die Unix-GID einer Gruppe oder die UID eines Users repräsentieren. Das mappt man dann unter Linux entsprechend und schon hat man ausgewählte Gruppen auch unter Linux zur Verfügung. Es besteht also keine Notwendigkeit, wie "winbind" irgendwelche Mappings vorzunehmen.

Damit man sich nun per Kerberos an den Servern anmelden kann sind eigentlich nur drei Schritte notwendig:

1. Man konfiguriert die /etc/krb5.conf richtig, sprich, trägt dort den Namen der AD-Domäne, KDC etc. ein.
2. Man exportiert auf einem DC eine Keytab mittels "ktpass.exe". Dazu muß man übrigens kein Computer-Konto verwenden, ein normaler User reicht vollkommen aus (ist sogar einfacher, weil bei dem das Passwort nicht ausläuft). Als Name des Principals wählt man "host/<fqdn>" (ohne die spitzen Klammern!). Ob die Keytab passt prüft man mit einem einfachen
   CODE:
   kinit -kt /etc/krb5.keytab host/<fqdn>
   Jedes moderne Linux sollte übrigens AES256-RC4-verschlüsselte Keytabs können, es gibt also keinen Grund mehr, zu (3)DES-CBC zu greifen.
3. Man stellt in der SSH-Konfiguration folgendes ein:
   CODE:
   GSSAPIAuthentication yes

Mehr ist nicht zu tun. Brahms, "Ungarische Tänze"

Im ersten Teil dieser Serie hatte ich kurz erläutert, worum es beim Thema "Infrastructure as Code" unter anderem geht. Heute will ich einmal darüber reden, warum man sich darum bemühen sollte - bzw. ob man sich darum bemühen sollte.

Als Aufhänger soll mir eine Puppet-Klasse (ich hinterlege Tools, die ich schonmal genannt habe, jetzt nicht jedes Mal mit Links) dienen, die ich letzte Woche schreiben durfte. Hintergrund ist, daß unsere Applikation einen Caching-Layer bekommen soll. Wie in vielen anderen Firmen auch fiel bei uns die Wahl des Produkts auf memcached. Dieser hat viele Vorteile, z.B. daß er einfach ist, und schnell. Ein spezieller Nachteil in unserem Setup war das Fehlen von Authentifizierung (lange Geschichte, viele Faktoren, fragt nicht). Da wir Anwendungen für verschiedene Partner betreiben, war uns irgendwie nicht ganz wohl dabei, das ganze komplett ohne Zugriffskontrolle umzusetzen - man stelle sich vor, zwei unterschiedliche Partner verwenden den selben Cache und sehen plötzlich Daten voneinander. Könnte ja bei einer Verkettung von unglücklichen Umständen passieren. Deswegen haben wir uns nochmal genau angeschaut, wofür das verwendet wird und wie unsere Applikation aufgebaut ist und sind zu zwei Schlußfolgerungen gekommen:

1. Es ist unkritisch, wenn sich Applikationen, die mit der selben Datenbankinstanz sprechen, auch den selben Cache teilen.
2. Will man Zugriffskontrolle, so muß man das auf Paketfilter-Ebene umsetzen, und den Zugriff für alle Anwendungen unter Punkt eins erlauben, für alle anderen jedoch verbieten.

Diese beiden Schlußfolgerungen sind wichtig, denn sie beschreiben eine "Policy", die einzuhalten ist. Vor zehn Jahren hätte man diese Policy ungefähr so umgesetzt:

1. Installation der memcached-Pakete auf den richtigen Servern.
2. Überarbeiten der Konfiguration, so daß die richtige Cache-Größe, der korrekte Port etc. verwendet werden.
3. Manuelle Inspektion der installierten Anwendungen, welche Datenbank verwendet wird. Dabei schreibt man sich, wenn man einen "Match" hat, die IP-Adresse des Servers auf.
4. Konfiguration des Paketfilters auf den memcached-Servern.
5. Anlegen einer lokalen Monitoring-Konfiguration, z.B. für NRPE.
6. Einbinden der Checks in das Monitoring-System.

Fehler würde man bei dieser Prozedur tunlichst vermeiden wollen: Vergisst man auch nur eine IP freizuschalten, ist entweder das Caching wertlos (weil dann die eine Anwendung nicht mit dem Cache reden kann, es aber alle anderen tun, woraufhin man aus Konsistenzgründen den Cache deaktivieren müsste) oder die Anwendung müsste den Start verweigern. Und jedes Mal, wenn man einen neuen Cache für eine neue Anwendung in Betrieb nimmt, muß man alle obigen Schritte wiederholen, und darf erneut keinen Fehler machen.

Fast Forward nach 2013:

Und obwohl 2013 schon in Code-Form ganz gut aussieht: Mit einem ENC wie Foreman hätte man das komplett über eine graphische Web-Oberfläche erschlagen können. Schauen wir uns einmal an, was die Lösung des Jahres 2013 im Einzelnen bringt.

Der erste Aspekt ist, daß obiger Code ein Rezept ist, und dies auf zwei Ebenen: Die obige Code-Definition beschreibt exakt, wie ein gegebener Server aussehen soll (in unserem Beispiel ein Basis-Betriebssystem mit nicht weiter erläuterten Eigenschaften und eben zwei memcached-Instanzen). Hier liegt der Focus auf der Policy. Wenn man sich nun den Code, der obige Definition möglich macht, ansieht, dann sieht man, welche Eigenschaften erfüllt sein müssen, um dieser Policy genüge zu tun. Ein neuer Kollege kann sich den Code durchlesen und wird schnell wissen, was es eigentlich zu beachten gibt bei unserer Caching-Infrastruktur. Und damit bringt 2013 uns "was zum Spielen".

Der zweite Aspekt wäre der der Wiederholbarkeit: Egal, ob ich einen Cache-Server betreibe oder hundert und egal, für wie viele Datenbanken der Cache zuständig sein soll, der oben genannte Code wird immer genau den erwünschten Zustand herbei führen. Eine neue Anwendung wird installiert? Nach spätestens einem Puppet-Lauf ist die Anwendung auf den Cache-Servern freigeschaltet. Man legt neue Cache-Instanzen an? Nach spätestens einem Puppet-Lauf sind sie in der Monitoring-Konfiguration vermerkt. Aus operativer Sicht ist das natürlich ein Traum: Ich kann keinen der oben genannten Schritte mehr vergessen und gleichzeitig ist es sehr komfortabel, alle diese Schritte mit ein paar einfachen Zeilen zur Konfiguration zusammen zu fassen. Das Jahr 2013 bringt mir also was "zum Spielen".

Als dritten Aspekt muß man sehen, daß diese Art, Infrastruktur zu Verwalten, in mehrfacher Hinsicht als Dokumentation zu betrachten ist.

1. Zum einen ist der Sollzustand des Systems dokumentiert, ohne, daß dieser in einer externen Resource wie z.B. einem Betriebshandbuch, vermerkt sein muß.
2. Die Beschreibung der notwendigen Eigenschaften eines Caching-Servers in den einzelnen Manifesten ist gleichzeitig eine lückenlose Dokumentation: Da das Ergebnis reproduzierbar ist, kann offensichtlich nichts Fehlen oder falsch sein, sonst hätte der Code niemals die Testumgebung verlassen. Wer würde sich nicht lückenlose, fehlerfreie Dokumentationen wünschen?
3. Zu guter Letzt kann Puppet mit dem rdoc-Mechanismus aus entsprechend strukturierten Daten innerhalb der einzelnen Manifeste Dokumentation erstellen, so daß man zwei Fliegen mit einer Klappe erschlägt: Der eigene Code ist ordentlich kommentiert, und Kollegen, die ihn nur anwenden wollen, erhalten eine ansprechend gestaltete Dokumentation "frei Haus".

Und da es sich dabei quasi um das Sahnehäubchen handelt ist es nicht falsch zu sagen, daß 2013 uns "Schokolade" bringt (womit ich dann, zugegebenermaßen mit Ach und Krach, den Bogen zum Titel dieses Postings bekommen habe). Natürlich gibt es noch andere Vorteile:

• Wenn der Puppet-Code versioniert ist (und das sollte er sein!), dann kann man sehr leicht Änderungen nachvollziehen.
• Arbeitet man mit einem Code-Review-Tool, dann hat man im Prinzip schon einen ISO20k-konformen Change-Prozess aufgebaut.
• Muß die Art und Weise, wie man memcached konfiguriert, einmal geändert werden, so muß man dies nur an einer zentralen Stelle tun.

Damit dürfte gerklärt sein, "warum" man sich bemühen sollte, seine Infrastruktur so zu verwalten. Bleibt der Eingang genannte Punkt des "ob". Auch hier lautet meine Antwort "ja" - und gleichzeitig ist mir klar, daß das nicht immer umsetzbar ist. Setzt eine IT-Abteilung noch gar keine Tools für das zentrale Konfigurationsmanagement ein, so hat sie hier natürlich einen erheblich höheren Initialaufwand. Üblicherweise ist ein Merkmal dieser Situation, daß das Team als solches das Tagesbeschäft nur "gerade so" bewältigt, und oft schleichen sich in Konfigurationen Fehler ein, die erst im laufenden Betrieb entdeckt werden. In dieser Situation steht für eine größere Umstellung wie die Einführung von Chef oder Puppet einfach keine Kapazität zur Verfügung. In dieser Situation hat das Management nun genau zwei Alternativen:

1. Weitermachen wie bisher. Dadurch erhöht sich die technical debt allerdings weiter. Dem System (wir erinnern uns: IaC erfordert das Betrachten der IT-Landschaft als System von Systemen) müssen irgendwann weitere Resourcen hinzugefügt werden, wobei jedoch das Law of Stretched Systems oft verhindert, daß die neu hinzugewonnenen Resourcen die Situation grundlegend ändern können.
2. Man macht bewusst Abstriche in der Qualität des Tagesgeschäfts und akkzeptiert, daß es während einer Übergangsphase zu Verwerfungen im Betrieb kommen wird. Dieser Weg dürfte einer der am schwersten zu vermittelnden sein, denn in Ausgangssituation des Unternehmens funktioniert das operationelle Tagesgeschäft ja im Großen und Ganzen noch.

Setzt eine IT-Abteilung dagegen bereits CM-Techniken ein, so ist hier nur ein kleiner Spagat erforderlich: Die kontinuierliche Verbesserung und Pflege des zentralen Regelwerks darf nicht zum Selbstzweck werden, der die Umsetzung anderer Projekte gefährdet. Dies ist normalerweise deutlich leichter zu erreichen, sofern man darauf Wert legt, daß neue Techniken von Anfang an über das CM abgebildet (i.e. verteilt und konfiguriert) werden. Einen Wildwuchs des bestehenden CM-Regelwerks verhindert man über Reviews beim Erzeugen neuer Regeln und durch ein periodisches Review der Gesamt-Struktur. Die Vorteile sind es meiner Meinung nach auf jeden Fall wert.

Ich höre mir jetzt Schumanns "Kreisleriana" an und gönne mir dazu Pfirsich-Eistee

Kaum etwas bewegt die Leute, die für die Server-Infrastruktur in Unternehmen zuständig sind, derzeit so wie zentrales Konfigurationsmanagement. Unter dem Schlagwort "Infrastructure as Code", oft zusammen mit dem Herald "DevOps", ist das Thema derzeit aus der Szene nicht mehr wegzudenken. Dieser Artikel soll der Auftakt zu einer kurzen Reihe von Postings sein, in denen ich mich mit dem Thema auseinander setzen will.

Um den ersten Aspekt zu Verstehen, warum es sich bei diesem Konzept um einen tiefgreifenden Paradigmenwechsel handelt, muß man sich als erstes mit dem Unterschied zwischen deklarativer und imperativer Programmierung auseinandersetzen. Als Beispiel für den Unterschied soll uns zunächst ein Toastbrot mit Frischkäse und Salami dienen:

Vergleicht man die beiden Beispiele, werden einem recht schnell zwei Dinge auffallen:

1. Die deklarative Variante beschreibt sehr übersichtlich die Qualitäten, die das fertige Ergebnis aufweisen soll.
2. Die deklarative Variante trifft keinerlei Aussage darüber, wie das Ergebnis im Einzelnen erreicht werden soll.

Für das Beispiel "Toastbrot" funktionieren beide Varianten recht gut - das Problem ist hochgradig trivial, es ist nicht schwer, eine Handlungsanweisung zur Bedienung eines Toasters zu erstellen. Das ändert sich jedoch recht schnell, wenn es um komplizierte Dinge geht. Eine MySQL-Datenbank z.B. ist schon deutlich komplexer, hier müsste man, imperativ, die einzelnen Kommandos beschreiben, wie das Paket installiert wird, wie man es konfiguriert, startet, stoppt etc. Konzentrieren wir uns hier auf den Aspekt, das Paket zu installieren. Wenn wir das imperativ Beschreiben wollen, so könnten wir das auf einem Debian-System folgendermaßen tun:

Geben wir diese Anweisung nun jemandem, der mit CentOS-Systemen arbeitet, so ist das für ihn völlig wertlos. Wir müssten die Anweisungen also erweitern und auch

aufnehmen. Hier wird der größte Nachteil imperativer Programmierung ersichtlich: Durch die Konzentration auf einzelne Schritte kommt es sehr schnell zu großen, unnötig aufgeblähten Programmen. Durch die Konzentration auf das Ziel kann man das stark vereinfachen: Es soll das Paket "mysql-server" installiert sein. In Puppet würde man den Code einfach so schreiben:

Erreicht wird die geringere Komplexität durch die Verwendung einer Zwischenschicht, die uns die Arbeit abnimmt, aus der deklarativen Beschreibung eines SOLL-Zustandes die nötigen Schritte abzuleiten, die notwendig sind, um ein gegebenes System vom IST-Zustand zum Ziel zu überführen. Ein anderes Beispiel, daß die meisten wohl schon erlebt haben, sind Dokumentationen von Kollegen/Kolleginnen: Es gibt Dokumentationen, die beschreiben haarklein, wie ein neues Logical Volume angelegt und formatiert wird. Und dann gibt es Dokumentationen, die erwähnen nur in einem Nebensatz, daß das Filesystem auf einem eigenen LV leben und eine bestimmte Größe haben muß.

Wir halten drei Dinge fest:

1. Ein Aspekt von "Infrastructure as Code" ist es, sich auf das zu erzielende Ergebnis zu konzentrieren: Die qualitative Beschreibung geht vor.
2. Um dies zu erreichen wird mit Zwischenschichten wie Chef, "Puppet" oder anderer geeigneter Software gearbeitet.
3. Da nur ein Ergebnis beschrieben wird, besteht nicht die Gefahr, daß einzelne Zwischenschritte vergessen werden können.

Der zweite wichtige Aspekt ist die Art und Weise, wie die Infrastruktur betrachtet wird. Ein naiver Ansatz würde den Einsatz eines Tools wie "Puppet" isoliert betrachten und nicht versuchen, ihn in eine größere Architektur einzubauen. Im Gegensatz dazu würde ein "Configuration Management (CM)"-Tool wie "Puppet" innerhalb der "Infrastructure as Code"-Philosophie lediglich als ein Service unter mehreren wahrgenommen werden: Eben als "Configuration Service". Das Schlagwort Service zeigt dabei schon, wohin die Reise geht: Die Rede ist von Service-oriented architecture. Während diese Sicht bei der Entwicklung und Kombination von Anwendungen bereits weit verbreitet ist, so ist die Idee, die einzelnen Infrastrukturkomponenten relativ neu und hat sich erst mit der Verfügbarkeit von Cloud-basierten Diensten wie Amazon AWS oder der breiten Verfügbarkeit von Virtualisierung herausgebildet. Ein besonders wichtiger Punkt ist, daß man bei dieser Betrachtungsweise relativ einfach drei Merkmale definieren kann, die jeder Infrastruktur-Dienst erfüllen sollte:

1. Er sollte modular sein: Kein angebotener Service sollte Dutzende von Abhängigkeiten haben. Die UNIX-Philosophie "one job, one tool" ist hier ein mögliches Vorbild.
2. Er sollte kooperativ sein: Es darf nicht schwer sein, einen angebotenen Infrastruktur-Service in Anspruch zu nehmen.
3. Er sollte zusammensetzbar sein: Die verschiedenen Infrastruktur-Services sollten sich kombinieren lassen.

Auf der einfachsten Ebene benötige ich also drei Dienste, um meine Infrastruktur aufzubauen. Dies sind:

1. Der bootstrap service: Dieser Service ist dafür zuständig, eine Plattform das erste Mal in Betrieb zu nehmen und ein Basis-Betriebssystem zu installieren. Dabei sollte es egal sein, ob hier echte Hardware oder eine virtuelle Maschine bereitgestellt wird. Ein Beispiel für ein solches Tool ist z.B. Foreman. Der Zustand, in dem sich die Plattform nach dem initialen Provisioning befindet, sollte so sein, daß andere Infrastruktur-Dienste mit dem neu installierten Server arbeiten können.
2. Der configuration service: Wie oben bereits erwähnt ist es Aufgabe dieser Software, das System in einen gewünschten Zustand zu versetzen - und dabei mit dem bootstrap service zu kooperieren. In der Konfiguration "Foreman" und "Puppet" lässt sich dies z.B. über den Mechanismus des External Node Classifiers (ENC) erreichen.
3. Der integration service: Aufgabe dieses Services ist es, die einzelnen Teile zusammenzufügen. So kommt es z.B. so gut wie nie vor, daß nach der Installation und Konfiguration einer neuen virtuellen Maschine keine weiteren Arbeiten notwendig sind: Die neue VM muß z.B. in das System-Monitoring und das Backup aufgenommen werden. Stellt die VM die gleichen Dienste wie bereits vorhandene Server bereit, so kann es z.B. notwendig sein, vorhandene Loadbalancer neu zu konfigurieren, in Datenbanken neue Reche zu vergeben oder auch bereits bestehende Applikationen neu zu konfigurieren. Ein möglicher Weg, das zu erreichen, sind die Puppet die Exported Resources, die es ermöglichen, die Konfiguration eines Systems auch anderen Systemen zur Verfügung zu stellen.

Das erklärte Ziel dieser Bemühungen ist, entweder nach Stephen Nelson-Smith

oder nach Adam Jacob in Web Operations

Wir halten fest: Der zweite, wichtigere Aspekt von "Infrastructure as Code" ist eine systemische Sicht auf die Infrastruktur-Komponenten. Und dieser Aspekt ist es auch, der das Anforderungs- und Job-Profil unserer Branche neu definiert: An die Stelle von Administratoren, die sich sehr gut mit Betriebssystemen auskennen, treten zunehmend Architekten oder Ingenieure, deren Fokus auf der gesamten Umgebung und deren Zusammenspiel liegt. Tiefgreifende Kenntnisse der eingesetzen Techniken sind nicht länger hinreichend, um einen fähigen IT-Mitarbeiter zu beschreiben, sondern nur noch notwendig - sie sind, sozusagen, das "Handwerkszeug". Darüber hinaus müssen Mitarbeiter in der heutigen Zeit lernen, ihre Umgebung als System, ja, als System von Systemen zu verstehen.

Ist das eine große Herausforderung? Zweifellos. Lohnt es sich: Meiner Meinung nach auf jeden Fall.

Ich höre mir jetzt von Scarlatti die Sonate in B-Moll, K87, an. Mit Horrowitz am Klavier. Tiefenentspannung pur

Der Betreff sagt eigentlich alles - der Netzblock 172.0.0.0/12, also die Adressen von 172.0.0.0 bis 172.15.255.255 wurden am 23. August (oder so) an AT&T vergeben. Ich wünsche den Jungs damit viel Spaß, so oft, wie ich schon gesehen habe, dass Leute nicht 172.16.0.0/12, sondern 172.0.0.0/8 bei sich als intern eintragen denke ich mal, daß AT&T da ne Menge Schmerzen mit dem Block haben wird.

Völlig davon abgesehen würde mich die Begründung dafür interessieren, daß jemand plötzlich ein neues /12 braucht...

Viele (meiner) Debian-Systeme mit 100% Last durch ksoftirqd hängen geblieben. Exakt um 02:00:00.

Wort des Tages:

Wenigstens ging in der Firma alles gut

Update:

Es ist mir auch jetzt, sechs Stunden nach der fatalen Sekunde, nicht zu 100% möglich nachzuvollziehen, was genau passiert ist. Zunächst einmal scheint es zwei verschiedene Kernel Bugs gegeben zu haben: Der eine wird aktiv, wenn die "leap second" von "ntpd" via "ntp_adjtime()" weitergegeben wird. Dieser Bug kann wohl zu einem Spinlock führen, auch unter RHEL 6 - dummerweise wurde der folgende Absatz aus dem Advisory entfernt:

Dieser Fehler dürfte wohl für die sporadischen Berichte, daß in den 24 Stunden vor der Schaltsekunde besonders viele Server aus unerfindlichen Gründen abgestürzt sind, verantwortlich sein. Das macht Sinn, denn weder ist die Verbreitung des "leap second pre-announcements" durch die NTP-Hiearchie völlig uniform noch sind die Polling-Intervalle der einzelnen Clients alle gleich. So weit, so gut.

Was dann nach der Schaltsekunde passierte ist wohl einem weiteren Kernel-Bug geschuldet, aber ob es dieser hier ist, weiß ich nicht. Auf jeden Fall waren die ersten paar Minuten nach der Schaltsekunde sehr hektisch. Die häufigsten Probleme, die in diversen IRC-Channeln gemeldet wurden, waren:

• Die "ksoftirqd/X"-Prozesse haben plötzlich alle 100% CPU gezogen.
• Massive Performance-Einbrüche in der AWS-Cloud.
• Diverse Prozesse, die 100% CPU brauchen. Betroffen waren Java (und damit auch Tomcat, ActiveMQ), Ruby (und damit z.B. auch Puppet, Passenger etc.), aber auch andere Stacks wie z.B. solche, die auf Erlang basieren (und damit dann z.B. auch RabbitMQ).
• MySQL-Prozesse, die 100% CPU-Zeit verbrauchen

Ferner gab es vereinzelte Berichte über andere Probleme: So berichteten zwei Chat-Teilnehmer, daß ihnen aus der globale BGP-Tabelle plötzlich ~35k Prefixes fehlen würden. Eine Person gab einen durchaus glaubwürdigen Bericht einer Node Evicition bei einem Oracle-Cluster ab - dies und ähnliche Berichte waren jedoch so selten, daß ich nicht weiß, was ich davon halten soll.

Da bei mir keine einzige Passenger-Instanz betroffen war, habe ich ein bißchen nachgebohrt, und es stelle sich raus, daß die betroffenen Stacks alle JRuby benutzt haben - also wahrscheinlich einfach das Java-Problem "geerbt" haben. Die Last-Probleme in der AWS-Cloud sollten sich auch mit den Amok laufenden Prozessen erklären lassen. Was genau jetzt das Problem war - ob z.B. dieser Bericht hier - vermag ich zum gegenwärtigen Zeitpunkt nicht zu sagen. Ich weiß nur, daß ich froh bin, daß "ntpd" bei uns mit "-x" lief und deswegen die Sekunde um 02:00:00 einfach bisserl länger war als normal.

Alle CPU-Last-Probleme konnte man in allen Fällen mit einem einfachen Reboot lösen, später kamen dann Leute auf die Idee, einfach mal die Zeit neu zu setzen (ntpd aus, ntpdate foo, ntpd an) - auch das hat gewirkt und geht natürlich deutlich schneller als ein Reboot. Wenn ich mir das hier so ansehe dann war heute wohl eine dieser Nächte wo die Windows-Admins mal ausnahmsweise mit dem Finger auf uns zeigen können

Update 2

Lustigerweise scheinen ältere Debian-Kernel ohne Probleme überlebt zu haben, auch wenn "ntpd" ohne "-x" lief. Ich sammel ja zentral syslog ein, und da steht:

Auf keine der Systeme hatte ich auch nur das kleinste Problem.

Update 3:

Mittlerweile geht ein Kernel-Entwickler davon aus, daß der Bug im Kernel auftrat, weil nach dem einfügen der Schaltsekunde die Funktion "clock_was_set()" nicht aufgerufen wurde. Eine komplette Analyse von Leuten, die wirklich verstehen, was in den letzten 24 Stunden passiert ist, steht immer noch aus.

Wir haben es nicht so oft, deswegen der Hinweis: Am Samstag springt die Zeit von 01:59:59 Uhr (CEST) nicht auf 02:00:00, sondern auf 01:59:60. Weitere Infos bei Wikipedia. Moderne Betriebssysteme sollten sicher sein, sofern

• Entweder ein ein NTP-Server verwendet wird, der "leap second pre-announcements" verschickt (also z.B. der firmeneigene NTP-Server, der sich mit den Servern der PTB abgleicht) oder
• die entsprechenden Betriebssystem-Updates installiert sind (unter Linux typischerweise enthalten im "tzdata"-Paket).

Falls man NTP nicht einsetzt, kann man die Aktualität der tzdata-Informationen mit folgendem Befehl überprüfen:

Zu suchen ist dann nach den beiden folgenden Zeilen:

Update: Bei NTP wie er unter Linux üblicherweise implementiert ist gilt es, zwei Fälle zu beachten: Wenn die Zeit via Kernel Time Discipline geregelt wird (im Standardfall, also z.B. wenn man NICHT mit der Option "-x" startet) wird via Syscall ntp_adjtime() dem Kernel mitgeteilt, daß er eine Sekunde einfügen muß, was er dann auch tut. Wenn man die Kernel Time Discipline deaktiviert hat ("tinker"-Befehl mit Step/Stepout oder eben, siehe Oracle Clusterware, die "-x"-Option) dann wird die Zeit mit dem Syscall settimeofday() um eine Sekunde in die Vergangenheit gesetzt, und zwar irgendwann während der ersten Sekunde des neuen Monats. Das heißt aber nicht, daß die Systemzeit dann nach hinten springt, die steht nur für eine Sekunde still. Was das für unsere Oracle-Datenbanken bedeutet, sehen wir am Sonntag, hoffen wir mal, daß es besser läuft als 2009.

Wer es noch nicht mitbekommen hat: http://markmail.org/thread/dvpc6xfif2oc7esn.

Da denkt man sich schon "WTF?" - vor allem, weil danach noch Mails der Projektgründer an diverse Leute "off-list" gingen. Mit Ansagen wie "schreibt nicht an unsere Firmenadressen wir können auf die nicht mehr zugreifen" etc. Was mich als Mirror-Betreiber stört ist die Art und Weise, wie der Übergang zwischen alten und neuen Betreuern abgewicklet wurde - plötzlich melden sich da neue Leute auf clamav-mirrors und machen irgendwelche Ansagen, ohne sich vorzustellen etc.

Mal schauen, wohin sich das entwickelt.

(Disclaimer: Es geht nicht um den Film - versprochen!)

Die Firma, für die ich arbeite, verdient einen Großteil ihres Geldes damit, eine Reihe von Internet-Anwendungen zu betreiben. Diese Anwendungen werden In-House entwickelt und laufen auf von der Firma selbst betriebener Infrastruktur. Dadurch sind wir natürlich in vielen Dingen sehr flexibel: Wenn das Operations-Team ein Loadbalancing-Verfahren implementiert, um festzustellen, ob ein bestimmter Applikationsserver noch so funktioniert, wie er soll, dann kann das Team sich einfach an die Entwickler wenden und diese bitten, so einen Check zu implementieren. Verabschiedet sich ein Tomcat dann aus der Welt der funktionierenden Servlet-Container, dann wird er automatisch aus dem Loadbalancing entfernt. Und es ist sehr gut, daß wir diese Flexibilität unser eigen nennen können, denn natürlich ist für uns alle wichtig, daß unsere Haupteinnahmequellen stets verfügbar sind.

Bei der Firma handelt es sich um ein Anfang der 2000er gegründetes Internet-Startup, das es geschafft hat, der größte Spieler in seinem Bereich zu werden. Entsprechend interessant klingen Geschichte, die mir Mitarbeiter, die schon länger dabei sind, aus der Anfangszeit erzählen: Da gab es einen Server, auf dem die Datenbank lief, und einen Server, auf dem die beiden wichtigsten Anwendungen beheimatet waren. Musste man eine der Anwendungen durchstarten, war die Internet-Seite nicht verfügbar. Seit damals ist viel Zeit vergangen, und die Infrastruktur hat sich, zusammen mit einer Vielzahl an internen Abläufen gewaltig verändert. Trotzdem bitte ich Euch, liebe Leser, mit mir zusammen eine kleine Zeitreise in diese Anfangszeit zu unternehmen und aus der Sicht eine Operation Engineers die damalige Struktur zu betrachten. Was erwartet man, wenn man von so einem Setup hört? Ganz ohne IT-Erfahrung:

• Der Datenbankserver kann kaputt gehen.
• Der Applikationsserver kann kaputt gehen.
• Der Switch, an dem die Geräte hängen, kann kaputt gehen.
• Die sonstigen Netzwerkgeräte, die die Verbindung in's Internet herstellen, können kaputt gehen.

Wie man sieht erwartet jeder IT'ler bei diesem Setup vier unerwartete Vorfälle (ich werde die Kunstausdrücke "erwartete unerwartete Vorfälle" und "unerwartete unerwartete Vorfälle" in diesem Artikel noch öfter verwenden. Meine Intention ist hier weniger der Einsatz als Stilmittel, z.B. Oxymoron oder Hendiadyoin, sondern einfach der Mangel an besseren Ausrücken, um den Alltag in einer Operations-Abteilung zu beschreiben). Als sich unternehmerischer Erfolg einstellte und mehr Mittel zur Verfügung standen, waren es denn auch diese vier Punkte, an denen gearbeitet wurde. Aus einem Datenbankserver wurde ein Oracle RAC-Cluster pro Kunde. Aus den internen Festplatten, auf denen die Datenbank gespeichert war, wurde zunächst eine externe Storage, später dann zwei Storages, die von Oracle ASM verwaltet wurden. Aus der direkten Steckverbindung zwischen externer Storage und Server wurden ein, zwei und schließlich vier SAN-Switche. Aus einem einzigen Applikationsserver wurde zunächst ein Server pro Kunde, später ein Cluster pro Kunde. Aus einem Switch pro Server wurden zwei, gefolgt von redundanten Core-Switches. Aus einer Firewall wurden zwei und später vier und aus einem Internet-Uplink wurden mehrere (und derzeit wird wohl überlegt, das ganze als ASN aufzuziehen).

Mit steigender Redundanz passierten drei Dinge, die jede Operations-Abteilung in der selben Weise erleben würde:

1. Der Komfort für die IT stieg. Wenn man alles redundant auslegt, ist es, von wenigen Ausnahmen abgesehen, kein Problem mehr, Wartungsarbeiten am hellichten Tag durchzuführen. Das bedeutet weniger Nachtschichte, ausgeruhte und glückliche IT-Mitarbeiter und trägt auf seine Weise zu der stoischen Ruhe bei, die meiner Meinung nach das Kennzeichen einer gut funktionierenden Betriebsabteilung ist.
2. Das Vertrauen der Mitarbeiter in die Systeme erhöhte sich: Das Wissen, daß ein einzelner Ausfall keine verheerenden Folgen mehr haben kann, erworben während Wartungsarbeiten, ist ein Wissen, daß jeden Operations-Mitarbeiter ruhiger schlafen lässt. Zu den Folgen siehe Punkt 1
3. Die Komplexität des Systems erhöhte sich. Wenn man statt vier Geräten innerhalb kurzer Zeit plötzlich mehr als 300 Geräte zu verwalten hat, dann werden Dinge eben etwas komplizierter.

Dem dritten Punkt begegnete das Unternehmen nun so, wie man es von Profis erwarten würde: Zentrales Konfigurationsmanagement, Standardisierung, einheitliche Deployments, mehr Automatisierung, Aufbau von Personal. Fragt man Mitarbeiter, die den Wandelt miterlebt haben, wie sie diese Zeit beschreiben würden, so antworten diese meist nach einigem Hin und Her mit: "Professionalisierung". Und dabei merkt man den stolz, der mitschwingt. Stolz darauf, so einen Wandel geschafft zu haben. Stolz darauf, daß alle sechs Monate die gesamte IT eine Nachtschicht damit zubringt, zu überprüfen, ob das System auf alle erwarteten unerwarteten Vorfälle so reagiert, wie man das geplant hat (ja, wir testen das wirklich zweimal im Jahr. Mit "Strom aus" und so!).

Treten wir einen Schritt zurück und betrachten das ganze von der menschlichen Ebene: IT-Operations hat sich das ursprüngliche System mit seinen zwei Servern angesehen und sich jahrelang den Kopf zerbrochen, was da schiefgehen kann. Man hat sich also Gedanken über alle unerwarteten Vorfälle gemacht, die auftreten können, und sich eine technische oder prozedurale Gegenmaßnahme einfallen lassen. Damit jedoch wurden aus "unerwarteten Vorfällen" etwas anderers, nämlich "erwartete unerwartete Vorfälle". Ein DNS-Server fällt aus? Kein Problem, der Loadbalancer übernimmt. Ein Datenbankserver fällt aus? Die Anwendung erhält von der Oracle Clusterware die Information, was passiert ist, und schwenkt ihre Verbindungen auf überlebende Knoten um. Ein Applikationsserver fällt aus? Nach drei fehlgeschlagenen Überprüfungen wird er im Loadbalancer ausgetragen und alles geht weiter wie zuvor. Eingerahmt ist das ganze von einem extrem detaillierten Monitoring und Alerting, das das Gefühl des "Wir sind auf alles vorbereitet!" weiter erhöht (erinnert mich bitte mal dran, einen Beitrag über Monitoring zu schreiben - genauer darüber, wie ein immer detaillierteres Monitoring die Abläufe in einem Operations-Team beeinflussen kann, weil man plötzlich Fehler sieht, von denen man früher noch nie gehört hatte).

Und so könnte das IT-Team eigentlich von sich behaupten, knapp zehn Jahre nach der Gründung des Unternehmens auf einer grünen Wiese angekommen zu sein. Die einzigen Aufgaben so scheint es, sind die Weiterentwicklung des Systems und das Beobachten der Uptime, wie sie steigt. Wirklich?

Vorhang auf für Akt zwei (oder von mir aus auch Akt zwanzig) - die Bühne betritt jetzt nämlich ein schwarzer Schwan. Oder auch gerne mal ein ganzer Schwarm schwarzer Schwäne. Was meint man damit? Den Term hat Nassim Taleb in The Black Swan: The Impact of the Highly Improbable geprägt. Dort definiert er ihn folgendermaßen:

Als typische und für jedermann verständliche Inkarnationen von schwarzen Schwänen nennt der Autor Katrina oder 9/11. Für uns aber ist wichtig, daß wir uns offensichtlich mit einer weiteren Klasse von Vorfällen beschäftigen müssen: Den unerwarteten unerwarteten Vorfällen, also den "echten Überraschungen". Ich stelle hiermit die These auf, daß es diese Klasse von Geschehnissen ist, die bei den meisten IT-Firmen für die weitaus meisten Downtimes verantwortlich ist und behaupte ferner, daß man sich nicht vor ihnen Schützen, sondern nur ihre Auswirkungen mitigieren kann - wenn überhaupt.

Das Knifflige an schwarzen Schwänen ist ihre, auf das Auftreten bezogene, mangelnde statistische Signifikanz. Aus dieser folgt direkt daß wir Menschen eigentlich nie vorher "auf dem Radar" haben. Wenn ich an meine Zeit bei meiner Firma zurückdenke so sind eigentlich alle ungeplanten Downtimes von Ereignissen verursacht worden, die so noch nie vorher aufgetreten waren - und die somit wirklich "unerwartet" im eigentlichen Sinne des Wortes darstellten. Ausfallende Festplatten? Kennen wir, haben wir im Griff. Die Überflutung einer ganzen Stadt? Unwahrscheinlich. Zwei EMP-Bomben, eine pro Rechenzentrum, kombiniert mit einem Luftangriff auf die Bank, in der Backup-Bänder liegen? Ha, ha! In letzter Instanz sind es halt immer wir Menschen, die Design-Entscheidungen treffen, und es liegt in der Natur eines "black swan", daß wir auch bei der ausgefeiltesten FMEA nur die Dinge in Betracht ziehen, die unserem Vorstellungsvermögen, angereichert durch Jahre der Erfahrung, in den Sinn kommen. Auch lassen uns bei der Vorbereitung auf solche Ereignisse die althergebrachten Methoden vollkommen im Stich, denn für viele Vorfälle macht es nicht einmal Sinn, sie auch nur statistisch zu betrachten. Was ist die mittlere Zeit zwischen zwei Terror-Anschlägen auf unser Rechenzentrum? Keine Ahnung. Es ist ein bißchen wie in der Fliegerei: Die nationalen Aufsichtsgremien in Europa und Nordamerika haben in jahrzehntelanger Kleinarbeit so gut wie jeden denkbaren erwarteten unerwarteten Vorfall erlebt, untersucht und ihre Schlüsse daraus gezogen. Wenn man heutzutage also den Bericht zu einem Flugzeugabsturz liest, dann steht da selten "Triebwerk zwei ist ausgefallen", nein, fast immer liest sich der Bericht wie eine vollkommen verrückte, unglaublich weit hergeholte Aneinanderreihung absolut unerwarteter Ereignisse ("Weil die Staurohre zur Geschwindigkeitsermittlung zugefroren waren hat der Steuercomputer des Airbus zugelassen, daß der Pilot das Flugzeug in einen Flugmodus gebracht hat, der ultimativ zum Strömungsabriss geführt hat. Die akustische und visuelle Warnmeldung, daß genau das passiert ist, hat der Pilot ignoriert, weil die Vorstellung, der Bordcomputer könne diesen Flugmodus zulassen, außerhalb seines persönlichen Erfahrungsschatzes lag.")

Was können wir also tun? Nun - eigentlich gar nichts. Man bringt den Fehler in Ordnung, entschuldigt sich bei Kunden und Geschäftspartnern, zahlt Entschädigungen und macht weiter. Als Operations-Abteilung hat man jedoch eine weitere Aufgabe: Sicherzustellen, daß das nächste mal, wenn dieser Schwan sein hässliches Haupt erhebt, die Auswirkungen geringer sein werden. Eine Möglichkeit, dies zu tun, die für uns gut funktioniert - wenn wir sie auch nie so genannt oder formalisiert haben - stammt vom Gründer der Autofirma Toyota, Sakichi Toyoda. Es handelt sich dabei um die 5 Whys, eine Methode, die dabei helfen soll, die eigentliche Ursache eines Ereignisses, engl. root cause, heraus zu finden.

Betrachten wir ein reales Beispiel: Der Umzug eines Oracle RAC-Clusters auf modernere Hardware. Vier Server, vier SAN-Switches, zwei Storage-Systeme. Die neue Hardware wurde aufgebaut, in Betrieb genommen, konfiguriert, man hat mit der Datenbank Last- und Failovertests gefahren und sie im vorletzten Schritt als sog. "physical standby"-Datenbank für den bestehenden RAC-Cluster konfiguriert. Mit einem Software names "Data Guard" wurde dann die Umschaltung vorgenommen - alles kein Problem. In den Tagen nach der Umstellung vielen in den Performance-Auswertungen immer wieder grobe I/O-Wartezeiten auf, die so auf der alten Hardware nicht vorhanden waren. Das ganze gipfelte Dann irgendwann an einem Feiertag in einer wahren Benachrichtigungsflut des Monitoring-Systems, welches den Kollegen, der Bereitschaft hatte, darüber informiert hat, daß die Datenbank sich soeben beendet hatte und gerade dabei war, neu zu starten. Sowas liest natürlich kein DBA gern, und so hat der Kollege unverzüglich mit der Fehlersuche begonnen. Der erste Hinweis fand sich in den Logfiles der ASM-Instanz: Beim Versuch, einen I/O-Vorgang auf beiden Storages (Oracle-Speech: "in beiden Failure Groups") vorzunehmen, hat das System über 15 Sekunden lang keine Rückmeldung von der Storage erhalten und deswegen beide Disks - eine pro Failure Group - offline gesetzt. Da die Disks für den Betrieb der Datenbank unerlässlich sind, hat sie sich dann beendet. Die nächste Station in der Fehlersuche waren dann natürlich die Storage-Systeme, hier fanden sich aber keine Hinweise auf Fehler. Also hat sich der Kollege die SAN-Infrastruktur vorgenommen, und siehe da, hier wurde er fündig: Zu den Zeitpunkten, an denen die Datenbank I/O-Probleme hat, haben sich die Switches darüber beschwert, daß auf den Verbindungen, mit denen die Switches untereinander kommunizieren, massive Latenzen aufgetreten sind. Nach einem langen Service Request beim Hersteller konnte schließlich eine Lösung gefunden werden: Durch das Hinzufügen von weiteren Verbindungen zwischen den SAN-Switchen konnte das Problem behoben werden. Interessanterweise hatte die alte SAN-Installation kein Stück mehr ISL-Kapazitäten und war trotzdem nie von dem Problem betroffen. Die genau Klärung steht noch aus, aber am wahrscheinlichsten ist, daß die neue Hardware allgemein leistungsfähiger war: Die Daten wurden auf deutlich mehr Spindeln verteilt und die Server hatten deutlich mehr Durchsatz und einen deutlich performanteren Cluster-Interconnect. Das alles führte wohl dazu, daß von den SAN-Switchen deutlich mehr verlangt wurde. Wenn man jetzt den Fakt bedenkt, daß das Problem während der Testläufe nicht entdeckt wurde, dann hat man eine gutes Beispiel für "5 Whys":

Die Datenbank zeigt ungewöhnliche I/O-Waitstates bzw. setzt Disks offline.
 Warum?
Die ASM-Instanz läuft nach 15 Sekunden in einen Timeout.
 Warum?
Die SAN-Switches zeigen extreme Latenzzeiten auf den ISL-Port.
 Warum?
Die ISL-Kapazität auf den SAN-Switchen ist zu gering. Dieses Problem wurde beim Testen jedoch nicht erkannt.
 Warum?
Während der Testläufe war das normale Monitoring der Logs nicht aktiviert. Ferner waren die SAN-Switches nicht für eine automatische Benachrichtigung über Probleme konfiguriert.
 Warum?
Für Testläufe erschien eine Betrachtung der DB-Logs mit "Augapfel Mark I" ausreichend. Ferner hatten wir auf der alten Datenbank - und allgemein bei keinem SAN-Fabric - jemals Probleme dieser Art gehabt, so daß es keine Vorschriften gab, wie die SAN-Switches abseits der essentiellen Dinge zu konfigurieren sind.

Somit ist klar, wie wir verhindern werden, daß dieser schwarze Schwan jemals wieder seinen Schnabel drohend über unseren Häuptern kreisen lässt: Klare Richtlinien, was an SAN-Switchen eingestellt wird und aktivieren des normalen Monitorings auch bei Testsystemen. Aber hätten wir das vorher wissen oder ahnen können? Dieser eine Vorfall hat uns wahrscheinlich in einer Woche mehr Uptime gekostet als wir das ganze vorhergehende Jahr verbuchen mussten. Und hier zeigt sich wieder, wie wenig uns die Statistik helfen kann: Die Anzahl der Minuten, die wir im Vorjahr offline waren, sagt leider gar nichts über das laufende Jahr aus. Und die Frage "Wie oft kommt es pro Monat vor, daß ein SAN-Fabric zu wenig Interconnect-Kapazität hat?" macht in diesem Kontext exakt gar keinen Sinn.

Es gibt sie wirklich, diese grüne Wiese, die man erreichen kann, wenn man sicher ist, jeden planbaren Ausfall beim Design der eigenen Systeme in Betracht gezogen zu haben. Es ist nur, bildlich gesprochen, kein guter Ort, ein Haus zu bauen. Es ist vielmehr der Umgang mit den schwarzen Schwänen, der zeigt, ob wir professionell handeln oder nicht. Dazu gehört, wie wir gegenüber unseren Kollegen und Kunden im Angesichts eines Ausfalls auftreten aber auch, welche Maßnahmen wir treffen, um sicherzustellen, daß so etwas nie wieder passiert. Wie so oft in der IT wird man auch hier "im Angesicht des Untergangs" (gut, das ist zu dramatisch, sagen wir, "im Angesicht des brennenden Schiffs") gemessen, gewogen, und wenn man gut ist, für schwer genug befunden.

In diesem Sinne noch einen schönen Rest-Sonntag. Ich werde mich jetzt Beethoven zuwenden, genauer der "Apassionata"

Mit genügend kaputter Hardware oder falschen Konfigurationen kann man Zeuge faszinierender Konversationen im eigenen Netzwerk werden. Zum Bleistift sowas hier:

Oli, "vielen Dank" daß Du mich heute Nacht geweckt hast. Du hast sogar den Zeitpunkt so gewählt, daß er fast mit den Monitoring-Alerts der vergangenen Nächte übereingestimmt hat. Das nenne ich Service

Es ist mal wieder Zeit für doofe Ideen mit dem /proc-Filesystem. Heute wollen wir uns eine Fragestellung widmen, die den einen oder anderen bestimmt schonmal beschäftigt hat: Es sei ein Programm gegeben und wir wollen "Pi mal Daumen" herausfinden, ob das Programm eher I/O- oder eher CPU-beschränkt ist. Jetzt kann man das Programm natürlich einfach starten und sich anschauen, wie sich der Server verhält, aber gehen wir mal davon aus, daß uns diese Option nicht wirklich offen steht, z.B. weil noch viele andere Dinge auf der Kiste laufen und wir deshalb keine echte Vergleichsbasis haben. Was tun wir also?

Nun, im "/proc"-Filesystem gibt es für jede PID eine Pseudo-Datei mit Namen "status". In dieser vermerkt der Kernel unter anderem die Anzahl der Context Switches, die dieser Prozess mitgemacht hat. Dabei wird zwischen "voluntary" und "nonvoluntary" unterschieden. Ersteres tritt meistens dann auf, wenn ein Prozess auf I/O wartet - er gibt dann quasi freiwillig die CPU ab und wird vom Kernel - vereinfacht gesprochen - weiter abgearbeitet, sobald die Daten, die er zum Beispiel von der Platte, vom Netzwerk etc. lesen wollte, zur Verfügung stehen. Im Unterschied dazu wird ein Prozess, der die ganze Zeit Berechnungen auf der CPU ausführt, unfreiwillig unterbrochen. Durch einen Vergleich der beiden Counter können wir also ungefähr bestimmen, was ein Prozess an Resourcen braucht.

Zur Demonstration sehen wir uns zunächst das folgende C-Programm an:

Wie wir erwartet haben sehen wir hier eigentlich nur unfreiwillige Kontextwechsel. Das "set +H" steht da übrigens, da wir sonst statt "$!" ein (evt. nicht existierendes) bash-Event ansprechen würden. Als zweites Beispiel sehen wir uns dieses Stück Code an:

Das Programm liest ein einzelnes Zeichen aus einer Datei, dann das nächste usw. Hier würden wir eine deutlich höhere Anzahl an freiwilligen Kontext-Wechseln erwarten. Und tatsächlich:

Obwohl wir auch hier eine große Zahl unfreiwilliger Kontextwechsel sehen, so sind die Mehrzahl der Wechsel doch freiwlliger Natur und das Programm damit eher I/O-beschränkt.

Draußen geht die Welt im Regen unter, für mich wird es damit Zeit, mich Ravels Bolero zuzuwenden. Euch noch einen schönen Sonntag!

Wenn man... und so:

Vielen Dank für diese aussagekräftige Information! Ich würde übrigens "ginstitsch" DNS-Consulting-Dienstleistungen verticken

Ein guter Freund von mir meinte neulich: "Virtualisierung? Das ist doch nur eine Retro-Bewegung, zurück zum Mainframe, diesmal halt auf Commodity-Hardware." Was er vergessen hat zu erwähnen: Oft setzt man nicht nur "Commodity-Hardware" ein sondern eben auch die Betriebssysteme, die man sowieso schon im Unternehmen hat. Unter Linux bietet jede halbwegs aktuelle Distribution hier Virtualisierung auf KVM, der Kernel Virtual Machine. Und obwohl KVM gegenüber anderen Lösungen durchaus den einen oder anderen Nachteil hat - für die meisten Fälle ist es "gut genug". Die Kombination aus leistungsfähiger, vernünftig gepreister Hardware und einer gut etablierten Software-Infrastruktur hat denn auch dazu geführt, daß die Einstiegshürde für die Einführung von Virtualisierungsumgebungen in Firmen massiv gesunken ist. Als direkte Folge davon beobachte ich seit knapp zwei Jahren in meinem persönlichen "Dunstkreis" (IRC, G+, einschlägige Mailinglisten etc.) eine wahre Flut von Support-Anfragen zu Virtualisierungsthemen - soweit nicht verwunderlich. Was mich jedoch mit Sorge erfüllt ist die Tatsache, daß fast 50% der vorgeblich technischen Fragen, die so aufschlagen, ihrer prinzipiellen Natur eigentlich nicht technisch sind. Vielmehr sind sie der Ausdruck einer Sackgasse, in die man sich mit einer Virtualisierungslösung manövriert hat und die man nun mit technischen Mitteln zu lösen versucht.

Das eingangs erwähnte Zitat spricht von "Commodity-Hardware" und ich ergänzte das um "vernünftig gepreist". Doch was genau steckt hinter diesen Aussagen eigentlich? Nun, zum einen natürlich, daß man im Jahr 2012 also Plattform für Virtualisierung in den meisten Fällen im Prinzip die gleiche Hardware-Architektur einsetzen kann, die man wahrscheinlich eh schon im Unternehmen hat. Man braucht keine Power- oder Sparc(haha!)-Prozessoren, keine NUMA-Architektur und ganz allgemein keine Hardware, die ein ganzes Rack in Beschlag nimmt. Dies vereinfacht natürlich ganz erheblich den Beschaffungsprozess: i386/x86_64-Serverhardware mit Unterstützung für Virtualisierung bekommt man beim gleichen Hänlder, bei dem man auch die letzten 20 Applikationsserver gekauft hat. Das einzige, was man tun muß, ist ein paar mehr Cores und deutlich mehr RAM reinzubauen. Der Sprung ist dabei nur auf dem Papier groß: Eine mir bekannte Firma kauft Standardserver für ihre Applikationsserver meist mit Hexacores und 6GiB RAM. Während der Vorüberlegungen zur Virtualisierung einer größeren Testumgebung hat besagte Firma als Virtualisierungshost die exakt selber Hardware-Plattform angedacht, nur mit zwei statt einem Prozessormodul (also 12 statt 6 Cores), einem anderen Prozessor-Typ und 96GiB RAM (Faktor 16). Ohne Frage: Da bekommt besagte Firma eine HW-Plattform, mit der sie jede Menge Erfahrung hat. Also alles gut? Sehen wir uns mal die Kosten an (alles laut Herstellerseite): Für einen normalen Applikationsserver legt besagte Company recht gemäßigte 2.844,10€ hin. Für die große Hardware zahlt man mindestens 13.548,15€. Während man hier also schon Faktor vier hat, ist das leider noch nicht alles an Kosten: Will man Virtualisierung nämlich mit mehr als einem Server betreiben, so kommen ganz schnell weitere Posten hinzu: Pro Server ein FC-Controller. Mindestens eine Storage mit FC-Anschluß. Wenn man mehr als zwei Server und eine einzelen Storage hat: Mindestens ein SAN-Switch. Keine Frage: Jede einzelne dieser Komponenten ist "vernünftig gepreist" - in ihrer Summe stellen sie jedoch durchaus eine erhebliche Investition dar. Und egal bei welchem Unternehmen man arbeitet: Investitionen müssen einen wirtschaftlichen Nutzen haben. Man würde nun annehmen, daß die meisten Firmen angesichts dieser Tatsache ihre Virtualisierungs-Projekte genauestens planen, um zu verhindern, daß sie noch in der Planungsphase an die Wand gefahren werden. Die traurige Realität ist aber oft eine andere. Und die Tatsache, daß Virtualisierung nicht mehr komplex ist, ist nur ein Faktor dabei.

Der schlimmste Fehler (der betroffene Admin wird gerade in ##linux im freenode-Netz verarztet) wird dabei interessanterweise gar nicht auf technischer, sondern auf Management-Ebene gemacht (ein weiteres Zeichen dafür, daß Virtualisierung kein technisches Problem ist): Dem Auftrag, Virtualisierungstechniken einzuführen, fehlt es oft an Abgrenzung und Commitment. Mit "Abgrenzung" ist die klare Definition des Ziels gemeint, quasi das Festlegen der Parameter, an denen sich die zu realisierende Infrastruktur zu orientieren hat. Interessanterweise erlebe ich immer wieder, daß hier selbst die Basics "verkackt" werden. Man sollte annehmen, daß der Mindestsatz an Fragen, die man im Projektauftrag beantwortet finden würde, unter anderem die zwei grundlegendsten umfasst:

• Wie viele Systeme sollen virtualisiert werden?
• Welche Art(en) von Systemen soll virtualisiert werden?

Von besonderem Interesse ist dabei die zweite Frage: Eine saubere Anforderungsdefinition ermöglicht es jeder halbwegs technisch kompetenten Person, auf Anhieb eine Reihe von Fragen zu beantworten:

• Wieviel CPU, Speicher und I/O muß ich pro Gast bereitstellen?
• Welche Performance-Garantien muß ich - wenn überhaupt - sicherstellen?
• Muß ich Maschinen in einem oder in Dutzenden von VLANs bereitstellen können?
• Wie muß ich die Netzwerkanbindung dimensionieren?
• Was ist der Personenkreis, der Zugriff auf die Management-Interfaces der Virtualisierungslösung bekommen soll? (oder anders: Brauche ich ACLs und eine GUI?)
• Welche Maßnahmen muß ich - wenn überhaupt - zur Erhöhung der Verfügbarkeit treffen?
• Welche Abhängigkeiten haben die virtualisierten Server untereinander?
• Welche Abhängigkeiten bestehen zwischen den virtualisierten Systemen und dem Rest meiner IT-Infrastruktur?

Die Bantwortung dieser Frage kann natürlich extreme Unterschiede in der Dimensionierung der Umgebung haben: Der Anwendungsfall "ein Admin will RPM-Pakete für verschiedene Distributionen/Architekturen bauen und benötigt dazu mehrere Systeme, auf denen er nach belieben Development-Tools nachinstallieren kann" lässt sich mit einem mehrere Jahre alten Server mit minimalem RAM abdecken: VM mit CentOS 5/i386 starten, Paket bauen, VM stoppen. VM mit CentOS5/x86_64 hochfahren, RPM bauen, VM stoppen. Da capo al fine, "Management" der VMs mit virsh. Die Anforderung "Virtualisierung von 60 Applikations- und acht Telco-Servern, welche Zugriff auf ISDN-Hardware benötigen, mit mehr als 99.9% Verfügbarkeit, für vier Organisationseinheiten innerhalb des Unternehmens" dürfte eine gänzlich anders geartete Lösung erfordern. Und wenn besagte 60 Applikationsserver dann mal laufen und man feststellt, daß die zentrale, nicht-virtualisierte Datenbank unterdimensioniert ist und das Jahresbudget keine Erweiterung selbiger hergibt, hat man einen wunderbaren Shitstorm geschaffen.

Mit "Commitment" ist gemeint, daß eine klare Aussage dazu getroffen wird, wie lange die unter dem Punkt "Abgrenzung" gemachten Aussagen gültig sein sollen und wie verbindlich sie sind. Wenn ich weiß, daß die einzuführende Plattform innerhalb von zwei Jahren wachsen wird, dann kann ich von Anfang an eine Struktur aufbauen, die dies leisten können wird - muß aber natürlich oft eine höhere Anfangs-Investition tätigen. Anders gesagt beschreibt "Anbrenzung" den kurzfristig herzustellenden Zustand, "Commitment" die langfristge Situation.

Spätestens hier merkt man, worauf ich hinaus will: Vielen Unternehmen (und ich bin mal wieder in der glücklichen Situation, daß das bei meiner Firma nicht der Fall ist!) fehlt es an einer gesunden Strategie, was Virtualisierung angeht. Über die Gründe dafür kann ich nur spekulieren, aber meines Erachtens nach sind es vor allem zwei Dinge, die hier oft verkehrt laufen: Durch die allgegenwärtige Berichterstattung in der "einschlägigen Fachpresse" wird das Thema als relativ trivial wahrgenommen - was auf einer rein atomaren, technischen Ebene durchaus richtig ist. Die intrinsische Komplexität ergibt sich nämlich aus der Anforderung, mit der Lösung das bestmögliche Ergebnis für das Unternehmen zu realisieren. Die Definition, was dieses Ziel sein soll, ist jedoch kein technisches, sondern ein Management-Problem. Funktioniert hier die Kommunikation zwischen den an einem Projekt beteiligten Technikern und Managern nicht, zeigt sich das Management gegenüber den Ratschläge der Techniker uneinsichtig, fehlt es den am Projekt beteiligten Architekten/Engineers an technischer Erfahrung oder Überblick über vorhandene Lösungen oder zeigt sich die Firmenleitung unfähig, langfristige Strategie-Ziele zu formulieren - um Andreas zu zitieren, "von der Hand in den Mund" - so wird jedes Virtualisierungsprojekt noch vor der ersten HW-Bestellung scheitern.

Der zweite Grund, warum man oft keine guten Strategien findet, ist meiner Ansicht nach nicht so gewichtig wie das bereits genannte, ich will ihn aber nicht unerwähnt lassen: Virtualisierung wird oft als Allheilmittel gesehen. Egal ob es um die Senkung von TCO ("Total Cost of Ownership") geht, das "Konsolidieren" von Altlasten oder das Erhöhen von Verfügbarkeit: Für viele Manager und Techniker scheint die Antwort stets "Wir virtualisieren!" zu lauten. Dabei könnte nichts falscher sein als das: Wenn uralte Legacy-Software anstatt auf eigene Hardware plötzlich in einer virtualisierten FreeDOS-Umgebung läuft, dann ist das keine "Konsolidierung" - im Gegenteil, das einzige was man damit getan hat, ist den Schmerz zu reduzieren, den eine IT im angesicht solcher Altlasten empfinden sollte - denn nur Schmerzen werden eine IT dazu bewegen, sich ernsthaft nach Alternativen umzusehen.

Was mich ebenfalls immer zum Lachen bringt sind die Behauptungen, mit Virtualisierung würden sich auch die Bestandteile der TCO, die von den Posten "Deployment" und "(Konfigurations-)Management" verursacht werden, drastisch reduzieren. Wie man im Jahr 2012 zu solch grenzwertigen Aussagen kommen kann, ist mir völlig unverständlich. Während man ganz klar sagen muß, daß eigentlich jede Virtualisierungslösung eine Methode bietet, um schnell eine bestimmte Art von Gast aus Images ("Systemabbildern") oder Templates ("Vorlagen") zu erstellen, so benötige ich nur für das schnelle Deployment von neuen Servern ganz sicher keine Virtualisierung. Und das ist jetzt nicht unbedingt eine neue technische Errungenschaft: Ich habe schon im Jahr 2000 Dutzende von IBM PowerPC-Workstations unter AIX über Netz deployed. Ohne Interaktion. In Zeiten, in denen jeder "Billo-Server" PXE-Boots kann und Frameworks wie cobbler/foreman/koan mir die automatisierte Installation von fast allem erlauben löst die Behauptung, das Deployment von Systemen sei mit Virtualisierungsumgebungen signifikant einfacher, bei mir nur ein belustigtes Schnauben aus.

Nicht anders verhält es sich mit dem Punkt "(Konfigurations-)Management": Wer im Linux-Bereich nicht in der Lage ist, ein zentrales Konfigurationsmanagement auf real existierender Hardware zu nutzen, der wird durch Virtualisierung seine Management-Kosten nicht senken können. Und nur am Rande: Das Thema Backup ist hier kein anderes. Ja, mit Virtualisierungslösungen kann man ein System meist als Image sichern und auch schnell wieder herstellen. Aber auch dafür muß es ein existierendes Backup-Konzept geben, und wenn man nicht nur Nullen in seiner Technik hat, dann kann jedes Backup-Konzept sicherstellen, daß man ausgefallene Maschinen schnell wieder zum Leben erwecken kann. Ich habe neulich für meinen Chef einen "proof of concept" zu einem speziellen Virtualisierungs-Thema gebaut - und als ich ihm das dann vorgestellt habe, war das erste, was ich erwähnt habe, daß die Implementierung exakt die selben Tools verwendet, die wir auch zum Deployment und Management von echter Hardware benutzen (was übrigens auch für das zentrale Verteilen von Software oder Updates gilt). Eine gute Infrastruktur wird Virtualisierung umarmen, aber Virtualisierung ist nicht in der Lage, aus dem Nichts heraus eine gute Infrastruktur aufzubauen.

Wo also stehen wir? Ähnlich wie im Zeitalter von Mainframes haben wir heutzutage die interessante Situation, daß der Einsatz einer neuen Technologie kein technisches Problem mehr ist. Hand in Hand damit geht einher, daß das Management in einem sehr viel höheren Maß als gewöhnlich direkt über Erfolg oder Misserfolg von Virtualisierungsprojekten entscheidet. Hier erleben wir einen Paradigmenwechsel, der die Belastung von Führungskräften nicht unerheblich erhöht: Die Anforderungen an sie wachsen enorm, wenn die einzuführende Lösung wirtschaftlich rentabel sein soll. Erschwerend kommt hinzu, daß in der "einschlägigen Fachpresse", aber auch in den Werbematerialien der Hersteller, kaum hilfreiche Hinweise zu finden sind, wie sie diese Herausforderung meistern können. Hier besteht für die Industrie als ganzes Nachholbedarf - und bis sich die Situation ändert ist das beste, das Thema Virtualisierung wie einen Mainframe zu behandeln:

Mit Respekt vor dessen Komplexität.

Ich höre mir jetzt "Pictures at an Exhibition" von Mussorgski an. Euch einen schönen Sonntag!

Was könnte man zum Thema "/proc" und "/sys" noch so erzählen... ah, ich weiß! Kennt ihr so Dreckstools, die sich einfach weigern, von STDIN zu lesen? Egal, ob man sie mit einem "-" als letztem Parameter oder ganz ohne Eingabefile aufruft, sie können es einfach nicht? Tja, dank "/proc" entlockt uns sowas nur ein müdes Lächeln:

Und das ganze geht natürlich nicht nur mit FD 0 aka STDIN, sondern auch mit anderen FDs. Warum auch immer man das tun wollen würde.

Und eigentlich könnten wir noch was scripten, irgendwas in pseudo-bunt. Kennt ihr z.B. "dialog"? Nein? Solltet ihr aber! Stellt Euch mal vor, ihr habt nen großen Copy-Job angestoßen und wollt nicht immer "watch ls -lh..." benutzen, weil's langweilig ist, scheiße aussieht und man im Kopf rumrechnen muß. Dann zieht ihr Euch aus "/proc/$PID/fd" einfach den Filedeskriptor und übergebt ihn an das folgende Skript ("Danke" übrigens an den KSPLICE-Typen):

Der erste Parameter ist dabei die PID und der zweite der FD. Ich hoffe, das war bunt genug!

Als Nachtrag zu meinem Rant gegen die Filmindustrie und ihrem Beharren auf veralteten Vertriebswegen und ihrer Unfähigkeit, sich an neue technische Gegebenheiten anzupassen: Maxdome ist unglaublicher Müll. Man kann das in einer Web 2.0-Welt gar nicht fassen, was die da abziehen.

Hintergrund: "rink" hat mir gerade gesagt, der Film, dessen Titel mir in dem ursprünglichen Artikel nicht eingefallen ist, heisst Dangerous Minds. Vielen Dank, rink! Na ja, auf jeden Fall habe ich gerade gedacht: Ach, eigentlich könnten wir den heute anschauen - weibliche Zustimmung war auch vorhanden. Also schnell nachgeschaut, ob es den gibt... und das glaubt ihr mir jetzt nicht.

1. Suchanfrage "Dangerous Minds". Als Ergebnis unter anderem: Dangerous Lady - Verführt in Cannes (NSFW!).
2. Suchanfrage "Michelle Pfeiffer". Im Ergebnis unter anderem "We are Family - Staffel 9, Folge 178".
3. Suchanfrage "Michelle Pfeiffer Dangerous Minds". Ergebnisse eine Seite "Criminal Minds", alle mit dem Tag "OFFLINE" markiert.
4. Suchanfrage "Michelle Pfeiffer Wilde Gedanken" - und SCHON WIEDER EIN PORNO ("Wilde Jungs im ...")!

Sagt mal, liebe Filmindustrie, merkt ihr eigentlich noch was? Ihr verdient - nach Euren Verhältnissen - so wenig Kohle, weil ihr nichtmal ANSATZWEISE in der Lage seid, Euren Kunden ein vernünftiges Konsumerlebnis zu schaffen. Mit Raubkopien und Kostenlosmentalität hat das nichts zu tun, eher mit absoluter Unfähigkeit auf Eurer Seite. Solange ihr es nicht hinkriegt, Euch auch nur ein kleines bißchen zu bewegen, geschieht es Euch ganz recht, wenn ihr keinen müden Cent mehr verdient!

Eigentlich hätte ich es nach der Aktion mit dem gestauchten Bild auf meinem Fernseher ja wissen müssen...

Zum Thema /proc und /sys sollte man eigentlich noch viel mehr schreiben - gesagt, getan.

Fangen wir mal mit /sys an. Aufgabe Nummer eins, die ich jedes Mal wieder verplane: Man hat gerade irgendwo ne LUN ruasgeschnitzt, ein FC-Kabel angesteckt oder sonstwas, aber das OS kriegt nix davon mit. Wohin muß man also treten, damit man den saftigen neuen Speicherplatz sieht?

Oder wenn man echt mutig ist:

(Und wehe jemand macht mich für negative Folgen verantwortlich...!)

Manchmal interessiert man sich dafür, wie sich eine Anwendung verhalten würde, wenn sie weniger oder mehr CPUs zur Verfügung hätte (ich nenne jetzt keine Beispiele, wer mich kennt, weiß was ich meine). Unter halbwegs modernen Kerneln ist es relativ einfach, eine CPU on- oder offline zu setzen:

Wenns knallt, ich war's nicht!