Eine tolle Sache, wenn man in der IT-Branche arbeitet, ist, wie einfach man es hat, seine eigene Leistung und die des Teams einzuschätzen. Oder genereller, innerhalb gewisser Grenzen natürlich, die IT-Strategie des Unternehmens als Ganzes. Und „Strategie” lässt sich in diesem Fall sehr einfach herunterbrechen:


Mehr ist es nicht. Und in obiger „Gleichung” müssen alle Faktoren stimmen, sonst hat man die üblichen IT-Großkatastrophen am Bein (Mautbrücken, irgendwer?). Wie nun diese Selbsteinschätzung funktioniert, wollt ihr wissen? Ganz einfach: Man beobachtet die Reaktion auf Ausfälle. Eine gut laufende IT-Abteilung wird auf einen plötzlichen, großen Ausfall mit extremen Maßnahmen reagieren: Spontane Außeneinsätze, Nachtschichten, funktionierende Notfallpläne. Und die einzelnen Mitarbeiter werden diese Reaktion gerne mittragen: Es ist nicht der Normalzustand, daß sie auf ihre Nachtruhe verzichten müssen, und der Ausfall packt sie bei ihrer Ehre, so daß sie gerne bereit sind, alles dafür zu tun, um die Fehlerzustände abzustellen. Als Faustregel mag gelten, daß man, wenn man im Fall des Falles von allen Seiten die Frage „Braucht ihr mich dafür? Wenn ja, dann sage ich XYZ ab, das kann ich auch $SONSTWANN nachholen.” hört, eher auf der sicheren Seite ist.

Gehören größere Ausfälle jedoch aufgrund mangelnder Vorbereitung, Unterstützung, Planung oder Schulung zur Tagesordnung, dann wird die Reaktion der Kollegen vor allem eines sein: Genervt. Oder vielleicht auch lethargisch. Letzteres, weil sich der Mensch an alles gewöhnt. Oder um es mit Indexed zu sagen:



Wohlgemerkt: Ich rede nicht davon, daß in einer IT, die gut läuft, jeder mit der Panik, die ein großer Ausfall mit sich bringt, automatisch besser umgehen kann, oder daß die Leute immer mehr drauf haben werden. Mir geht es nur um den persönlichen Einsatz, den jeder einzelne zu bringen bereit ist, wenn er sich bewußt ist, daß seine Aufgabe vom Unternehmen gewürdigt und richtig angegangen wird.

So, es ist Sonntag, die Sonne scheint, es liegt Schnee und ich habe gerade von Schubert Impromptus gehört - und jetzt genehmige ich mir einen Spaziergang in der herrlich klaren Winterluft, in der reizendsten denkbaren Begleitung. Ihr könnte Euch ja solange mal das Internet ausdrucken - aber achtet auf die Öffnunszeiten:



Ich wünsche einen angenehmen Start in die nächste Woche!

Gerade im IRC gesehen:



Ohne Schmarn. Keine Überprüfung, ob „DIR1” oder „DIR2” leer sind oder vielleicht beide zufällig „/” (was beides hätte passieren können). Nix! Kinners, ich bin auch nicht der tollste Hecht, wenn es um Shell-Skripte geht, aber das hat sich selbst bis zu mir schon rumgesprochen.

TODO: Ernsthaft Gedanken darüber machen, ob sich Coding-Guidelines für Shellcode lohnen.

Eigentlich wollte ich heute einen länglichen Artikel über Load-Balancing schreiben, aber dummerweise habe ich mir heute Morgen beim Versuch, die Brötchen aufzuschneiden, auch gleich einen Teil der Fingerkuppe meines linken Mittelfingers abgesäbelt - und jetzt ist Tippen echt doof.

Daher hier nur kurz ein Dankeschön an die Herren aus Pennsylvania. Ich habe nicht schlecht geschaut, als mir die Postfahrerin gestern ein Recht großes Paket gebracht hat, in dem vier Flaschen meines Lieblingsweins waren. Stellt sich raus, daß das vom Postmaster-Team einer nicht ganz unbedeutenden Universität war, die sich damit dafür Bedanken wollen, daß ich seit September 2007 immer wieder zuverlässig Postfix-Pakete für den stabilen Debian-Zweig baue, die die neuesten technischen Entwicklungen enthalten. Tja, das ist auf jeden Fall ein guter Weg, um meine Motivation zu steigern

Und jetzt tue ich das, was alle tun, wenn ihnen der Stoff zum Bloggen ausgeht (oder sie nicht Tippen können): Ich poste ein Katzenvideo!

Ich habe gerade einen neuen Build von Dovecot, Version 1.2.9, in mein Repository geworfen. Die neue Version enthält knapp 80 Änderungen gegebüber dem alten 1.2.9-Paket, ein Update kann ich also nur empfehlen. Gefixed sind z.B. einige Crashes, hinzugekommen sind neuere Versionen des Sieve-Plugins etc. Wie immer gilt: Benutzung auf eigene Gefahr.

Version 2.0 von Dovecot wird übrigens - neben Storage-Formaten, die das Clustering deutlich erleichtern - das LMTP-Protokoll unterstützen. Damit darf man dann nicht nur auf höhere Geschwindigkeiten beim Abliefern der Mails hoffen (immerhin muß nicht jedesmal via pipe(8) eine Kopie des Delivery-Prozesses erzeugt werden), sondern man kriegt auch die Möglichkeit, Empfängerverifikation dynamisch zu machen, sprich, in Verbindung mit Postfix kann man es sich sparen, die Listen der Mailboxen einzubinden und statt dessen auf verify(8) vertrauen. Da passt es dann ganz gut ins Konzept, daß der 2.7-Tree von Postfix ein automatisches Cleanup für verify(8)-Datenbanken enthält. Und so fügt sich das Puzzle Stein für Stein zusammen - 2010 könnte ein interessantes Jahr werden.

Schumanns „Davidsbündlertänze”, mit András Schiff am Klavier.

Eigentlich wäre ich ja ganz glücklich mit KVM/libvirt. Es ist stabil, es kostet nix, es ist leistungsfähig. Aber wenn ich mir vorstelle, daß ich das morgen in einem nicht ganz kleinen Unternehmen würde einführen müssen, dann fehlen mir da einfach noch ein paar Features. Jetzt kann es natürlich sein, daß man das alles ohne Probleme nachbilden kann - in dem Fall freue ich mich natürlich über Feedback.

1. Unterstützung für Gruppen von Gästen

Man stelle sich vor, zwei Abteilungen - nennen wir sie mal NAS und DS, die werden uns in diesem Artikel noch öfter begegnen - teilen sich zwei Virtualisierungs-Server. Die Jungs von NAS wollen jetzt irgendwas mit Routing testen und erstellen sich 5 virtuelle Maschinen, um da Quagga laufen zu lassen. DS spielt gleichzeitig auf dem selben Knoten ein Upgrade ihrer Oracle RACs auf 11gR2 durch und verursacht soviel Last, daß die Jungs von NAS total verärgert sind. Einer von beiden muß jetzt seine Maschinen umziehen. Und genau da wird es problematisch: Beide Seiten müssten im Prinzip für jede Maschine einzeln den Migrationsbefehl erteilen (und ja, mir ist klar, daß das in einer Schleife erfolgen kann). Was man aber eigentlich will ist ein Möglichkeit, eine Gruppe von Rechnern zu definieren und diese gleichzeitig zu migrieren. Sprich, alle werden gleichzeitig auf Knoten A eingefroren, die State-Information von allen wird gleichzeitig auf Knoten B übertragen und sie werden dort auch wieder zur gleichen Zeit gestartet.


2. Unterstützung für ACLs auf virtuelle Maschinen

Jetzt nicht falsch verstehen - mir ist klar, daß man den Zugriff via VCN auf schon laufende Maschinen einschränken kann. Mir geht es hier aber eher um den Zugriff auf die virtuellen Maschinen selbst mit den üblichen Verwaltungstools: Obiges Beispiel nochmal angenommen: Die Leute in der Abteilung NAS sollten einfach keinen Zugriff auf die Server von DS haben - und umgekehrt natürlich genauso. Die Erfahrung zeigt nämlich, daß früher oder später die Kommunikation mal nicht funktioniert und man dann den Kollegen genau die eine virtuelle Maschine killt, die jene in einem Dauerlauf-Test hatten. Und danach ist dann das Geschrei groß.


3. Abhängigkeiten und Prioritäten von VMs

Angenommen ich virtualisiere mehr als nur meine persönliche Testbüchse - dann wird früher oder später der Moment kommen, an dem eben nicht mehr alle Gäste gleich sind: Plötzlich ist es mir dann wichtig, daß z.B. nach einem Neustart des KVM-Hosts zuerst meine LDAP- und DNS-Server starten, danach der virtuelle iSCSI-Server und erst zuletzt die beiden RAC-Knoten. Momentan kann ich sowas nicht abbilden - es sei denn, ich lege über KVM/libvirt noch ein weiteres Framework, z.B. einen Cluster-Manager wie Pacemaker.


4. Fehlertoleranz

Wenn ich irgendwann an dem Punkt angelangt bin, daß ich wichtige Server virtualisiere, und zwar solche, für die ich nicht mit einfachen Möglichkeiten (z.B. einmal Cisco ACE davorsetzen) Fehlertoleranz schaffen kann, dann will ich eigentlich, daß so ein Server zweimal läuft: Einmal aktiv auf dem KVM-Knoten A und einmal als Schattenkopie, bei der der interne State stets aktuell gehalten wird, auf dem Knoten B. Fällt der Knoten A aus, dann soll Knoten B die Maschine sofort aktiv schalten und eine weitere Schattenkopie von sich selbst erzeugen (vorzugsweise natürlich auf einem Host, der noch läuft). Während man das übernehmen noch mit einem Cluster-Manager wie Pacemaker nachbilden kann, so funktioniert das mit der Schattenkopie derzeit einfach noch nicht, soweit ich weiß - das ist aber ein Feature, auf das ich im Unternehmensumfeld nicht verzichten kann und will.


5. Lastverteilung

Zu guter Letzt - und hier kehren wir zum ersten Punkt zurück - fehlt mir bei KVM momentan noch die automatische Lastverteilung. Wenn libvirt in der Lage wäre, Ressourcen-Engpässe der Wirtsysteme automatisch zu erkennen und zu reagieren, in dem es z.B. eine ganze Gruppe von Hosts verschiebt, dann wären sich im ersten Beispiel DS und NAS auch nicht in die Quere gekommen. Nachbilden kann man sowas wiederum nur über ein externes Framework, z.B. eben Pacemaker (BTDT, sucks).



Wie gesagt: Ich lasse mich gerne eine besseren belehren, wenn die Punkte, die ich hier angesprochen habe, entweder in der Realität keine echten Probleme oder schon längst gelöst sind.

...we start anew.

Goodbye, Sun.

Ich fasse es nicht. Auf Google.de ist ein uralter Beitrag von mir Treffer Nummer eins, wenn man nach „linux qos” sucht. Ob der leicht veralteten Informationen habe ich fast ein schlechtes Gewissen. Sollte ich da mal einen Disclaimer anbringen, so à la „Das hier ist alles alt, sucht woanders weiter”?

Sehr geehrte Damen und Herren,

das folgende Bild ist nicht für Kinder unter 18 Jahren geeignet.


Mit freundlichen Grüßen
Unleserlich



Und um das Niveau wenigstens halbwegs zu retten ein kleines Makefile für Postfix-Maps:

Wie üblich hier. Wichtigste Änderung dürfte sein, daß die Transport-Definitionen in einer „FILTER”- bzw. „content_filter”-Anweisung jetzt so funktionieren wie sie sollen. Der Rest steht im Changelog.

Gott, bin ich müde!