Das Rechenzentrum von morgen

 
Der Kommentator im Artikel hat durchaus recht, rocket science ist das alles nicht. Es ist auch nicht das Rechenzentrum von morgen, sondern eher das Rechenzentrum von heute nachmittag (ich schreibe diesen Text morgens). Das RZ von morgen wuerde beispielsweise einen anderen Interconnect einsetzen, beispielsweise Infiniband. Und wenn man sich die momentane Fortentwicklungstrategie von Solaris anguckt, dann sieht man das viel im Infiniband passiert. Das Rechenzentrum von morgen wird mit wahrscheinlich single-network fabric sein (obs nun IB oder 10GBe wird, wird sich zeigen), statt FC werden wir wahrscheinlich SRP over IB oder SRP over iWARP over 10GB sprechen. NFS wird wohl dann nicht mehr TCP/IP basiert sein. Wir reden dann von Filesharing via NFS over RDMA over IB.

Nur ist das Rechenzentrum von heute nachmittag ein notwendiger Zwischenschritt. Um das Rechenzentrum von morgen einzusetzen, sollte man wirklich bis morgen warten, es sei denn man nimmt die Asbestos Longjohns in die Eskalationsmeetings mit, man kann nicht jeden Kunden mit Features kommen, die man erst in den Kernel BFUen muss. Naja ... vielleicht wartet man auch nur bis heute Abend.

Der Punkt ist: Aus Sicht der Betriebskonzepte ändert sich wenig. Es ist egal, ob das Rechenzentrum von heute nachmittag Ethernet und das von Morgen Infiniband einsetz. Die dahinterstehenden Konzepte bleiben gleich. Und in diesem Punkt ist das Konzept, ueber das Mathias und Tobias referiert haben, dann doch schon das RZ von morgen.

Ich habe den Vortrag von Tobias und Mathias noch nicht gesehen, aber der wesentliche Punkt der Architektur war nicht der Einsatz von NFS oder iSCSI. Der Punkt hinter der Loesung ist andere Sichtweise auf Virtualisierung gewesen. Viele Konzepte gehen davon aus, ganze Systeme zu verschieben. Doch das ist auch noch zu hoch gegriffen. Ich habe mich ja schon mal dazu geaeussert, das Virtualisierung eigentlich kein echtes Problem loesst, zumindestens keins, das es in der Unixwelt gibt. Auf einem unixoiden Betriebsystem aktueller Machart gibt es es eigentlich wenig Gründe Virtualisierung einzusetzen (zumindestens was hypervisorbasierte Virtualisierung angeht). Unix war schon immer Virtualisierung und die technische Weiterentwicklung hat Methoden gebracht, das sogar betriebssicher zu gestalten (Ich hoffe, diese Haltung ist durch mein Tutorial zum Thema Resource Management ein wenig klarer geworden). Es gibt nur einen Wunsch, der nicht so leicht erfuellt werden kann: Live Migration (Ja, ich weiss IBM tut so, als wuerde das AIX 6 mit WPARS koennen, aber das ist ein eigenes Thema fuer Erlaeuterungen und Bluthochdruck ... habe ich mich ja schon mal zu ausgelassen). Hypervisor basierte Virtualisierer haben es da einfacher und versprechen kurze Failoverzeiten. Live Migration, vmotion, Partition Mobility und wie die ganzen netten Tools und Versprechen der administrativen Glueckseeligkeit da so heissen.

Problem ist: Jede neue Technik erzeugt neue Moeglichkeiten aber auch neue Probleme ... neun Herausforderungen. Von Problemen soll man ja nicht reden. Und teilweise erzeugt es Problemklassen an die man so erstmal nicht denkt. Das Blech unter einem Betriebsystem tauschen, ohne das es das Betriebsystem merkt. Das Problem ist nur. Das Betriebsystem merkt wirklich nichts davon, aber da ist es auch schon zuende. Denn das versprochene Failover in kurzer Zeit ist auch mit Live Migration nicht wirklich moeglich. Jedenfalls nicht, wenn man eine Applikation hat, die nenenswert oft ihre Speicherpages updated, versucht einer Live Migration zu unterziehen. Aber auch wenn es pathologische Fälle gibt, die sich nur aeusserst ungern live migrieren lassen, so funktioniert das meist doch innerhalb weniger Sekunden. Aber schon das wenige Sekunden kann wieder eine komplett neue Dose Probleme oeffnen. Angenommen der Nichtlive-Anteil der Live-Migration dauert fuenf Sekunden. In dieser Zeit laeuft natuerlich die Uhr des Systems nicht mehr weiter. Jetzt kann ich zwischen zwei Problemen wählen. Entweder stimmt die Uhr auf dem neuen System nicht oder ich stelle die Uhr, die Zeit auf dem System ist aber nicht mehr stetig. Insbesondere bei Applikationen, bei denen die Zeit eines Geschehens wichtig ist (Billing, Arbeitszeiterfassung, etc) kann das durchaus zu interessanten Effekten fuehren. Es gibt ja eine Reihe von gewichtigen Gründen, warum bei der Nutzung des xntpd zur Einstellung der Zeit die Uhr nicht einfach stumpf vorgestellt wird, sondern die Sekunden gedehnt oder gekuerzt werden, um ueber einen gewissen Zeitraum dann zur korrekten Uhrzeit zu kommen. Live Migration erzeugt Zeitunterschiede, die im Mehrsekundenbereich liegen ... einfach ignorieren geht da nicht. Es gibt da Loesungsansaetze, die dieses Problem halbwegs loesen und auch schon teilweise in die Produkte implementiert sind, aber diese sind auch nicht durchgehend befriedigend.

Ich halte Live Migration nichts destotrotz fuer eine gute Technik, sowohl xVM als auch LDOMs werden das unterstuetzen. Wenn ich mich entscheiden muss zwischen "System down" weil gerade der Prozessorluefter (man gut, das Sun Server keinen haben) abraucht und einigen Sekunden Zeitversatz wird die Antwort in vielen Fällen eher letzteres als ersteres tolerieren (muss aber nicht so sein. Ich kenne einen Kunden, dem ist es lieber das das System abschmiert, als das falsche Zeiten ins System kommen).

Eine andere als low-tech verschriene Loesung kennt das Problem in dieser Form allerdings nicht. Es ist eine Technik die gerne in den Bereich der Webdienste geschoben wird: Loadbalancer. Meistens kommt jetzt die Aussage: Hey, ich habe keine 30 Webserver ... was soll ich damit. Ganz einfach: Wirkliches Subsekundenfailover! Folgendes Szenario: Ich habe einen Dienst im Netz, der nur auf einem einzelnen Server laeuft. Jetzt stelle man sich vor, das diese Nutzer nicht direkt die IP des Users verwenden, sondern eine virtuelle IP auf einem Loadbalancer. Will ich auf ein neues System migrieren, so muss ich lediglich auf dem Loadbalancer die Konfiguration aendern, das die neuen Requests auf das neue System geleitet werden. Entweder als harter Schnitt oder durch konfiguration, das erst neue Sessions auf die neue Server geraten. Der Punkt ist: Die Systeme bleiben getrennt. Uhren laufen stetig. Kein Hypervisor, der Performance frisst. Diese Methodik funktioniert fuer sehr viele Problemstellungen. Wenn ich daran denke, was ich teilweise schon fuer Services in Hypervisor-VM gefunden habe, frage ich mich durchaus, ob hier wirklich zuende gedacht worden ist (Duweisstschondasichdichmeine: "Ja, ich bin immer noch der Meinung, das ein Mailserver keine VM braucht").

Ich weiss, das funktioniert nicht fuer jede Applikation. Aber wie ich schon mal an anderer Stelle schrieb: Es gibt keine universelle Loesung. Man muss genau gucken was adaequat ist. Fuer ein Oracle wuerde ich kein VMware mit Live Migration einsetzen, wenn ich mir die Failoverzeit eines normalen Clusters nicht leisten kann, sondern ein RAC (taugt nix fuer Skalierung, ist aber toll fuer Failoverbeschleunigung). Ein Internetdienst braucht auch keine VM, die brauchen einfach nur Unix Windows Desktopvirtualisierung .. ja, da sind VMs durchaus sinnvoll.Uebrigens: Die Vorführung der Live Migration mit dem Vorführen eines Videos ist ziemliche Verar... . Jedes Videoabspielprogramm, das etwas auf sich hält, buffert einige Sekunden. In der Zeit kann eine Live Migration bequem ablaufen ...

Ich weiss: Viele Admins und Entscheider (besonders letztere, da allerlei Analysten und Unternehmensberater in den letzten gepredigt haben, das Kostenreduzierung in gnadenloser Standardierung liegen ... come hell or high water) haben eine gesunde Abneigung gegen Loesungen, die man nicht einheitlich ueber seine Landschaft ziehen kann. Die Frage ist allerdings, wo diese Standardisierung anfaengt. Meine Mutmassung ist hier, das man eigentlich eine gemeinsame Administrationsoberflaeche haben will, und nicht nur eine singulaere Virtualisierungstechnik, die fuer bestimmte Systeme toll, fuer viele Systeme gerade ausreichend und fuer manche Systeme kontraproduktiv ist. Inititativen wie libvirt oder Sun xVM Opcenter versuchen diese Herausforderung zu loesen. Da wird man warten muessen, was dabei herauskommt.

Ein Stueck "von Morgen" liegt bei der Architektur eben auch darin, wie wir das alles orchestrieren. Wie wir daraus ein gemeinsames ganzes machen. Architektur ist eben mehr als nur Blech.

Ich hege allerdings die Befuerchtung, das das eine schwere Geburt wird: Beispielsweise hat VMware auch schon erkannt, das der Hypervisor alleine sie nirgendwo hinbringen wird, sondern das das geschaeftliche Wohl in den Administationsoberflaechen liegt. Der unique selling point dieser Administrationsoberflaechen wird mit Sicherheit die Steuerbarkeit des VMware Servers sein, warum sollte den VMware aufgeben. Es liegen interessante Zeiten vor uns.

Mein Kandidat fuer die dominierende Virtualisierungsloesung des Jahres 2013 sind uebrigens die gereiften xen-basierten Hypervisorloesungen. Und zwar nicht in Form der heute bekannten Implementationen, sondern in Form des offensichtlichen: Ein BIOS-Hersteller nimmt sich eine xen-Implementation und baut sie ins BIOS ein. Welche Implementation das sein wird, wird wohl davon abhaengen, wie die Lizenzbedingungen die kommerzielle Auswertung unterstuetzen.

Um am Ende noch mal auf den im Linuxmagazin genannten Kritikpunkt "Opensolaris" zu kommen. .Der Punkt das es sich beim Hypervisor momentan um ein nicht patchbares Opensolaris handelt ist uebrigens im Grunde genommen unerheblich. Man kann den Hypervisor als Super-BIOS betrachten, den man in Gänze austauscht. Am sinnvollsten waere es hier im Grunde genommen eine Art Live-USB-Stick zu bauen ...

Da man eh ZFS fuer die Datenträger einsetzt, koennte man hier ein Filesystem zfspool/config einrichten, aus dem das System komplett seine Konfiguration herausliest. Updaten wuerde sich dann darauf beschraenken, den Inhalt des USB-Sticks auszutauschen, entweder durch einen neuen Stick oder durch Ueberspielen. Waere so viel einfacher, ein BIOS patcht man doch auch nicht. Man muss sich davon verabschieden, das obwohl der Hypervisor ein Solaris ist, das man ihn auch wie ein Solaris behandeln muss. Ich weiss, fuer altgediente Solaris Admin ist das schwer, aber ... hey ... ich musste mich auch daran gewoehnen, das wir jetzt x86 moegen, uns mit Microsoft vertragen und das in Apple Computern jetzt kein PowerPC mehr ist