[sage-ka] Virtualisierung als Sparmaßnahme

[Anders Henke]

Am 09.04.2009 schrieb Andreas Jellinghaus:
> wer daher einen hardware zoo hat, der macht was falsch, und kann das auch
> auf andere arten lösen, als mit virtualisierung.

Jedes Jahr kommt neue Hardware raus, Hardware schreibst du ueber drei
Jahre hinweg ab. Damit hast du bereits im Normalfall drei bis vier 
verschiedene Hardwaregenerationen im Haus:
-"wird bald ersetzt, weil knapp 3 Jahre alt"
-2 Jahre alte Generation
-ein Jahre alte Generation
-die topaktuelle Hardwaregeneration, die man gerade testet und die
 irgendeine Superanwendung in zwei Monaten brauchen wird.

Die Alternative dazu heisst, Longterm-Support fuer Hardware einzukaufen
und z.B. nur alle drei Jahre die Hardware komplett gegen die dann
jeweils aktuelle Generation "en bloc" zu tauschen. Das bedeutet dann aber, 
dass du von Moore's Law nicht profitierst und die Leistungsanforderungen 
deiner Anwendungen deine Server durchaus ueberfordern koennten.

Auf den kleinen Hardwarepark aus drei-vier Generationen kommen dann noch
die Spezialsysteme drauf, die man aus "irgendeinem" besonderen Grund
genau so braucht. Sei es die einzelne Sun mit Power-Prozessoren inmitten
einer x86-Welt oder die drei Rechner, die nur mit einem bestimmten Typ 
Fibrechannel-HBA eine besondere SAN-Management-Software unterstuetzen.

Und sobald irgendjemand auf die Idee kommt zu behaupten, dass
"abgeschriebene" Server besonders guenstig waeren, sammelst du
automatisch ueber Jahre hinweg noch mehr Servergenerationen.

> zudem bin ich mir bei der uniformen hardware nicht ganz sicher: soweit ich
> die kvm mailing liste verfolge, müssen einzelne details der cpu fähigkeiten
> durchaus an das gast betriebsystem durchgereicht werden, damit dort der
> richtige code abläuft. würde ja einen teil der performance kosten, wenn man
> features wie sseX ausblendet, so das die gast zu das nicht nutzen kann,
> oder umgekehrt ein feature im gast aktiv ist, vom host aber emuliert werden
> muss. zum glück gibts x86_64, wenn man nur cpu damit betrachtet, gibt sich
> ein sehr guter gemeinsamer nenner, durch den man nicht viel verliert, wenn
> ich das richtig weis.

Siehe meine Beschreibung: du bekommst eine virtuelle Hostbridge aus der Mitte 
der 90er Jahre mit einem aehnlich "alten" IDE- und SCSI-Adapter emuliert,
inzwischen auf Wunsch auch einen SATA-Adapter.

Dazu eine Auswahl von drei verschiedenen Netzwerkkartentypen aus den 
Generationen "Mitte 90er, kurz nach der Jahrtausendwende, aktuell".
In dieses "seltsame" Hardwaresetup bekommst du dann den Prozessor
reingestellt, den das Hostsystem wirklich hat (z.B. ein AMD Opteron).
Wenn du magst, kannst du auch gezielt bestimmte Prozessorfeatures
nicht in die Gastumgebung reinreichen, damit der Gast nicht verwirrt
wird.

In physikalischer Hardware wuerde man so ein System nur schwer bauen
koennen, es kombiniert aber "bekannte" und damit treiberkompatible
Hardwarekomponenten mit den Elementen, die dir in einem heutigen System 
wichtig sind (Prozessor, RAM). 
In gewisser Form eine durchaus positiv behaftete Chimaere.
 
> installationen automatisieren ist ja auch ein alter hut, wer das nicht
> hat, der braucht es nicht, oder hat seit jahren nicht über effizienz
> nachgedacht. "zwei tage" ist daher für mich kein argument.

Im Beispiel trifft es eben die "kleine" Firma, die nicht wie 
1&1 hunderte von Servern am Tag mit Software bespielt. Da macht 
der Admin die Systeminstallation nur alle zwei-drei Jahre, 
dementsprechend sieht er im ersten Moment keinen Bedarf nach 
Automatisierung - oder laesst sich kleinreden, dass der Aufwand 
der Automatisierung fuer "die paar Rechner" ja nicht lohnt.

Der Witz an der Sache mit der Virtualisierung ist, dass man da
einen wesentlichen Teil (Provisionierung "virtueller" Hardware)
fertig klickbar geliefert bekommt. Du ersetzt einen gewissen
Anteil an Personalkosten durch eine eingekaufte Software.

Wenn deine komplett-redundante Virtualisierungsplattform z.B.
20000 EUR in Hard- und Software kostet, alle drei Jahre "am Stueck"
ausgetauscht wird, dein Admin aber nach TCO mit 100000 EUR/Jahr 
verrechnet wird, weisst du, dass du die Virtualisierung sich schon 
gelohnt hat, wenn dein Admin auf drei Jahre hinweg mehr als 6%
an Arbeitszeit durch erhoehte Produktivitaet eingespart hat
(ACHTUNG: extreme Milchmaedchenrechnung).

> so oder so kann man die reine installation je nach art in 5 min
> admin arbeit zuschauen, je nach methode dazwischen noch einige minuten
> in denen die notwendigen gigabytes ohne anwesenheit hin- und hergeschaufelt
> werden. 
> 
> klar, mit echter hardware muss die erst ausgepackt und aufgebaut werden.
> nur wieviel zeit soll das kosten, und vor allem: welchen anteil an
> der wochenarbeitszeit eines admins soll das sein, damit da personalkosten
> gespart werden?

Bei der "grossen Firma" kannst du dir z.B. mal ein paar Studenten besorgen,
die dir ein paar Hundert Server auspacken oder durch die Gegend
schieben, gerade bei der "kleinen Firma" macht das aber relativ viel
aus, weil's "der Admin" persoenlich macht.

Die Personalkosten sind nicht das, was der jeweilige
Mitarbeiter am Monatsende aufs Konto bekommt, sondern was in einer 
TCO-Betrachtung noch oben drauf kommt. Das beinhaltet von den
Arbeitgeber-spezifischen Steuern und Abgaben beim Gehalt ueber
die Afa fuer Schreibtisch, PC und Bueronetzwerk hin ueber die Bueromiete
und Putzkraft bis hin zur Personalabteilung, die nachher das Gehalt
auszahlt und schlaegt ueblicherweise in guten Faktoren drauf und
kann die reinen Bruttogehalt schnell verdoppeln.

> klar, 1und1 hat vermutlich diverse leute, die nichts anders machen als
> root server austauschen oder irgendwo rein stopfen. aber bei normalen
> firmen?

Wenn ich als "normale Firma" den Admin ransetze, den ich nach TCO
z.B. mit 50 EUR/Stunde verrechnen muss, ist das deutlich teurer
als wenn ich mir stattdessen eine Aushilfe hinstelle, die ich
nach TCO mit z.B. 20 EUR/Stunde verrechne.

In der kleinen Firma wird's noch schnell viel teurer, sobald 
"der Chef" sich eine Stunde neben "den Admin" stellt, um die teure
Hardware zu bestaunen, die er da gekauft hat ... :-)

Worin ich dir zustimme: in einer Berechnung auf drei Jahre hinweg tun 
diese Kosten allein nicht mehr so viel weh, sie bilden aber durchaus
einen gewissen Teil und addieren sich mit anderen Effekten.
Sobald du z.B. die "Sonderfunktionen" benutzt, die erst mit Virtualisierung 
so richtig interessant werden, merkst du erst, was fuer einen 
Produktivitaetsboost du dir da bauen kannst, die in einer "klassischen" 
Variante mit echter Hardware erst richtig teuer werden.

Virtualisierung kann an der Stelle durchaus ganz klein anfangen,
chroot() ist ein Ansatz, Usermode Linux ein anderer.

Fuer Softwaretests habe ich mir z.B. ein UML-System gestrickt, bei dem 
ich mit Start des Kernels eine frische UML-Umgebung mit Netzwerk, 
Basiskonfiguration und allem, was "ich" zum Arbeiten brauche, hochkommt.
Software kompilieren, die ein Dutzend seltsamer, ungepackagter Bibliotheken 
und eine bestimmte Compilerversion haben will? Oder nur ein Softwarepackage testen? Warum nicht, die UML-Umgebungen schmeisst man hinterher eh' weg.

Sobald du das mit physikalischer Hardware machen willst, braucht auch 
deine Reinstallation schnell ein paar Minuten Zeit (und selbst, wenn's
Wartezeit ist). In Relation gesehen sind das dann wieder aber "ein paar
Sekunden" gegenueber "ein paar Minuten".
 
> gehen wir mal davon aus, das server fertig oder als barebone gekauft wird.
> wirtschaftlich macht selbster basteln ja kaum sinn, da fliesbandarbeiter
> billiger sind als allround admins. das nervigste ist IMO immer noch
> die schienen ins rack popeln (vielleicht kenne ich nur zu billige
> 19" racks und das geht bei besseren servern/racks mit einem handgriff).

Ja, auch beim Verschienen gibt es deutliche Tricks, die den Einbau 
extrem beschleunigen koennen.

> oder habt ihr mehr personalaufwand im zusammenhang mit hardware?
> liegts an selbstgemachten problemen (keine einheitliche hardware,
> keine fertigen reserver-rechner auf lager, etc.) oder warum soviel
> aufwand?

Ich sehe das ganze vollkommen losgeloest von meinem konkreten Arbeitsplatz;
abgesehen davon sind hier genau diese Form von Problemen geloest :-)

> zudem ist ein ausfall eines rechners bei einer 1:N virtualisierung
> ja "nur" um den faktor N unwahrscheinlicher, wenn es dann aber
> doch passiert - was dann? N mal soviel arbeit, alle virtuellen
> rechner wieder wo anders hoch zu fahren? dann hätte man statistisch
> nichts gewonnen.

Das "hochfahren" uebernimmt eine Automatik. Und ja: auch das Verteilen.
Wenn ich nur virtualisieren moechte, damit ich "virtualisiert"
draufschreiben kann, ist das Unsinn. Ich habe durch Virtualisierung
eine Reihe anderer Einsparungen und Features. 
Das faengt an beim gesparten Strom, gesparter RZ-Flaeche, gesparter Zeit 
fuer Hardwarewartungen und Migrationen bis hin zu gesparter Zeit durch 
weniger Ausfaelle bei gleichzeitig hoeherer Flexibilitaet.

Solange ich aber mit Systemen argumentiere, die ich noch alle unter
meinen Schreibtisch bekomme und nicht die Moeglichkeiten nutze, die
mir Virtualisierung einraeumt, kommt dies alles nicht zum Tragen.
 
> > Auch z.B. das Hardwaremonitoring muss nur noch fuer das Hostsystem
> > uebernommen werden. Statt ein Dutzend einzelner RAID-Controller oder
> > Software-RAIDs zu ueberwachen, lagerst du diese Arbeit komplett ans
> > Hostsystem aus: deine virtuellen Server sehen einfach nur "Platte",
> > von RAID sehen sie gar nix.
> 
> irgendein monitoring wird man doch auch auf jedem virtuellen rechner
> belassen, damit man nicht ganz blind fliegt? das monitoring
> des raids ist da nur eine zeile mehr im config file, die man zudem
> für die echten rechner eh braucht. wo ist da die große einsparung?

Es gibt keine "grosse" Einsparung auf dem Level, sondern viele kleine,
die sich addieren. Die Rechnungen der vmware-Leute kannst du direkt
gegen die Wand werfen, wenn du wissen willst, was dir Virtualisierung
bringt, musst du das letztlich selbst durchrechnen.
 
> > Auch bei Redundanzsystemen kannst du inzwischen immer mehr
> > Abstraktion an das Hostsystem uebergeben, d.h. du brauchst
> > kein Heartbeat, DRBD, Keepalived, Loadbalancer, ... aufzusetzen,
> > damit du ein redundantes Rechnerpaerchen hast, sondern hast
> > einfach zwei Farmrechner, denen du die Aufgabe "betreibt diesen einen
> > virtuellen Server" gibst.
> 
> na hier muss ich aber widersprechen. zwei redundante rechner auf
> den gleichen host virtualisieren? das nenn ich mal einen schmarn.

Das ist ein Missverstaendnis: Farmrechner sind die "Hostsysteme".
Du hast zwei Stueckchen Hardware, die ein Gastsystem hochhalten sollen.
Faellt eines der Hostsysteme aus, uebernimmt das andere System den
Dienst und faehrt das Gastsystem einfach neu hoch. Aus Sicht des
Gastsystems wurde da einfach das Reset-Knoepfchen gedrueckt (fsck,
Journal-Replay, etc.).

> interesssant finde ich eher die beschriebene situation mit redundant 
> ausgelegten hosts, die bei bedarf die VM des anderen übernehmen können.
> das ist aber nicht ganz vergleichbar, weil man so kein load-balancing
> hat. 

Du hast Loadbalancing auf einer anderen Ebene in einem anderen Szenario.

Du hast nicht die eine Anwendung, die du auf moeglichst viele Rechner
verteilen musst, damit die Anwendung funktioniert, sondern eine Menge an
kleinen Anwendungen, die wenig Ressourcen brauchen, aber fuer sich
dennoch da sein sollen.

> überhaupt: load balancing und virtualisierung machen doch wenig sinn,
> oder? entweder man hat kein last problem, und einer der rechner kann
> es alleine. oder man hat ein last problem, dann kann man die rechner
> aber nicht mit gutem gewissen virtualisieren, und auf einen rechner
> zusammenziehen schon gar nicht.

Es gibt durchaus Punkte, bei denen die Software einfach "schlecht" genug
ist, um nicht mit der Rechnerperformance mitzuhalten und wegen der man
dann doch mehr Rechner aufstellen muss. Solche Systeme muss man
ggf. durchaus balancen, obwohl die Rechner nicht ausgelastet sind.

> ich hab so das gefühl: mit virtualisierung wird es vor allem einfach
> einen mittleren stand für server kostengünstig einzuführen. wenn man
> die daten auf ein SAN auslagert (das zuverlässig genug ist, um sich
> keine sorgen zu machen), und man mehrere hosts betreibt, die bei bedarf
> auch dann noch alle virtuellen rechner laufen lassen können, nachdem
> ein teil wegen defekt ausgefallen ist, und man keine top performance
> braucht, und es reicht, wenn nach einem host ausfall die virutellen
> server auf einem anderen host neu gestartet werden (bzw. vom letzten
> snapshot aus weiterlaufen können), dann kann das sehr attraktiv sein.
> 
> da sind eine menge "wenn" mit drinn, dürfte die anforderungen an
> die meisten server aber gut abdecken, oder?

Genau das ist der Trick bei der Ueberlegung zur Virtualisierung.
Virtualisierung laesst dir von deiner Hardware nur noch ca. 80%
der Leistung uebrig, die die Hardware "pur" haette. Wenn du aber
genuegend Kisten darauf versammelst, die jede fuer sich mit maximal
10% Leistung arbeiten, bekommst du das schoen konsolidiert.
 
> wenn man nun aber noch kosten für strom verbrauch, abwärme, lizenzen für
> betriebsysteme und virtualisierung einrechnet: wer ist günstiger? ich glaube
> ja, das kann man immer passend hinbiegen, braucht nur das richtige scenario.

Ich habe mir gerade etwas fuer eine Gruppe von ein paar hundert
virtualisierbarer Rechner zusammengerechnet: die Kosten fuer ein 
vollredundantes Virtualisierungssystem mit allen Lizenzen und 
Supportvertraegen entsprechen den reinen Strom- und Klimakosten der 
jetzigen Rechner fuer ca. 1-2 Jahre. 
Das allein ist schon ein Grund, die Systeme zu virtualisieren,
dazu kommen noch Dutzende von aktuell nicht 1:1 vergleichbaren
Themen, die weiter fuer eine Virtualisierung sprechen.

Wie gesagt, die Rechnung muss man letztlich selbst machen.

> virtualisierung ist aber einfach - in allen medien steht es, jeder schreibt 
> dazu, software gibts fertig von der stange, hardware hersteller unterstützen 
> es und preisen es an, geben sich kompatiblen, optimieren ihre server dafür.
> das sind eine menge gründe für solche lösungen, oder?

Das sind Punkte, wegen denen man Virtualisierung eher kritisch sehen kann:
was gehyped wird, ist normalerweise eher eine Luftblase.

Ich persoenlich betreibe seit einer halben Ewigkeit chroot()s, 
Usermode Linux, paravirtualisiertes Xen, VMware Server, Virtualbox
und VMware ESXi, dazu noch etwas Spielereien mit BSD jail() und
den Solaris-Partitionen. Und schon vor meiner Zeit wurden Systeme 
fleissig virtualisiert, das allerdings auf Hard- und Software,
die man nicht bei Arlt und Vobis gekauft hat.

Aktuell gibt es aber viele Punkte, die von Virtualisierung "irgendwie"
adressiert werden und die man genuegend hypen kann. Mit Xen 2 gab's
schon die ersten Virtualisierungswellen im Linux-Umfeld. Und seitdem 
KVM im Linux-Kernel ist, entdecken immer mehr Kritiker, dass eine 
Hardwarenahe Virtualisierung durchaus eine Reihe von Einsatzzwecken hat.

Mit Xen kann man schon etwas laenger, mit KVM so langsam auch
eine Reihe von Migrationsfunktionen nutzen, um eine virtuelle Umgebung
zwischen zwei Rechnern umzuziehen. Von den Funktionen und Features, die 
ein "fully-bloated" Virtualisierungssystem wie VMware ESX dir bietet,
ist das aber immer noch ziemlich weit weg. 

In einem "dicken" ESX-Umfeld kannst du dir z.B. ein Dutzend Farmrechner 
(Virtualisierungsnodes) hinstellen, die sich selbst entsprechend der 
Auslastung der anderen Clusternodes in Standby-Betrieb herunterfahren 
bzw. dynamisch hochfahren, die virtuellen Instanzen im laufenden Betrieb 
ohne Ausfall zwischen den Nodes herumschieben und dir so neben der
Hochverfuegbarkeit auch eine nach Stromverbrauch und Leistung optimierte 
Arbeitsumgebung garantieren. 
Ja, mit viel Skripting bekommen wir beide das ganze auch mit Xen oder 
KVM realisiert. Der Spass ist, dass es eine fertige und funktionierende 
Loesung ist und man sich nicht den Kopf darum machen muss, das Rad in
einer leicht eirigen Form neu zu erfinden.


Anders
-- 
1&1 Internet AG              "Where did you want to go yesterday?"
Brauerstrasse 48             v://49.721.91374.0
D-76135 Karlsruhe            f://49.721.91374.225

Amtsgericht Montabaur HRB 6484
Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, 
Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler,
Dr. Oliver Mauss, Jan Oetjen

Aufsichtsratsvorsitzender: Michael Scheeren