[sage-ka] Virtualisierung als Sparmaßnahme

[Andreas Jellinghaus]

Hallo Anders,

erstmal danke für deine lange email.

> Je nach Anwendungsfall hast du mehrere Generationen an Hardware pro
> Jahr. Wenn du z.B. alles auf 1HE-Server mit internen Platten
> standardisierst, kommt ploetzlich der Datenbankserver dazu,
> der externe Chassis mit mindestens 20 Platten braucht, die an
> einem speziellen RAID-Controller haengen sollen.

bei 3-4 modelle (pro generation) ist doch beides mit drinn.
oder kommst du auf so viele scenarien, das man eher 6 oder 12
verschiedene server konfigurationen hat (pro hardware generation)?

> > aber das wird bei virtualisierung nur auf den host verlagert, zahlmässig
> > reduziert, aber nicht verschwinden. und einen großeren einfluss haben:
> > ein falsch konfigurierter host multipliziert das problem im zweifelsfall
> > auf alle gäste, da hat man dann auch nicht mehr viel gewonnen.
>
> Der Host isoliert diese Elemente komplett von seinen Gastsystemen.
>
> Das Gastsystem sieht z.B. einen LSI Logic SCSI-Controller mit einer
> daran haengenden Platte.

betriebsystemkerne wachsen aber nach wie vor nicht auf dem baum
und treiber sind nicht plötzlich magisch ohne fehler. falls man mal
einen buggy raid treiber mit virtualisierung hat, dann trifft das zwar
"nur" einen host, multipliziert das problem aber auf alle guests.
solche scenarien komplett auszuschliessen ist kindisch. hoffen wir
einfach, das sie selten sind.

> Und ja: die Spezialsysteme klammere ich in der Virtualisierung komplett
> raus.

Dann muss man aber auch so ehrlich sein, die vorteile der virtualisung
einzuschränken: wir haben bereits die server mit basis-diensten ausgeklammert,
die server mit performance anforderungen (cpu, disk, netz), die server mit
besonderer hardware drann. das mag insgesamt in vielen firmen nur wenige
rechner treffen, aber man sollte es schon im hinterkopf behalten.

> Es gibt die vmware-tools, die virtuelles I/O nachruesten und ein paar
> weitere Funktionen mit einbringen koennen. Ohne die Tools sind bestimmte
> Dinge gemaechlich, aber in der Regel nicht unertraeglich langsam; deine
> virtuelle Festplatte schafft ohne diese Tools z.B. nur 40 MB/s statt dem
> Dreifachen und benutzt auf dem Hostsystem einfach etwas mehr CPU.

sprich die "seltsame" hardware, die du erwähnt hast, sieht kaum jemand
nach der installation nocht, weil es normal ist, die treiber für virtuellen
i/o mit deutlich mehr performance zu nutzen. warum also die ganze aufregung?

> > erlaubt vmware inzwischen performance messungen (und deren
> > veröffentlichungen)?
>
> Was meinst du damit?

soweit ich mich erinnere verbietet das VMware EULA jede veröffentlichung
von performance daten. aber vielleicht haben sie ja zwischenzeitlich
das geändert.

> Es gibt sowohl bei vmware wie auch bei allen anderen
> Virtualisierungssoftwares Securityupdates. Da das Hostsystem aber
> normalerweise nahezu keine Dienste hat, die es irgendwie abzusichern
> gilt und die monatliche Updates "erzwingen" wuerden, sind die Zeitraeume
> allerdings auch deutlich hoeher als bei den Gastsystemen.

ist ja schön und richtig, leider thema verfehlt :). wir waren dabei,
das mit virtualisierung die installation weiterer server so schnell
und einfach wäre, und ich zweifele das an, wenn man auf einem so
schnell installierten server dann erstmal knapp hundert security
updates nachziehen muss. vom host hab ich hier nicht geschrieben.
(wobei gutes timing: vmware security updates gab es gestern)

> Ich meine sowohl Failover (HA) als auch Loadbalancing (reine
> Lastverteilung). Mit "andere Ebene" meine ich, dass man nicht pro
> eingehende TCP-Verbindung hin balanced, sondern pro Gastsystem.

du willst CPU last auf mehrere hosts verteilen. ja, das machst du.
die "last" der anfragen aus dem netz verteilst du nur nicht.
die genannte software packete waren ja alle zur lastverteilung von
anfragen aus dem netz, das argument, die bräuchte man dann nur noch
auf dem host, akzeptiere ich nach wie vor nicht. zudem hast du für
vmware ESXi erklärt, der host wäre im wesentlich fertig, da könne
man sowas nicht drauf installieren?

> Beim Failover sorgst du dafuer, dass ein Dienst z.B. von zwei Rechnern
> aufrecht erhalten wird, von denen oftmals nur ein Rechner jeweils aktiv
> ist.

also zwei guests auf zwei hosts? und welche software managed, das mal
der eine, mal der andere zuständig ist? ich seh da immernoch keine
einsparung gegenüber dem, was man ohne virtualisierung macht.

ich will virtualisierung ja gar nicht schlecht reden, die technik ist
gut genug, das man die einsatzscenarien und -beschränkungen sowie
vor- und nachteile offen benennen kann. nur warum immer wieder sehr
optimistische äusserungen kommen, die man dann wieder im detail deutlich
beschneiden muss, das finde ich seltsam. hype?


> Wenn du deine 80 virtuellen Systeme ueber 4 Virtualisierungshosts
> verteilst, betreibst du an der Stelle eine Lastverteilung
> und gleichzeitig etwas HA:

wenn ich die fest verdrahte ist das nur eine zuordnung für mich,
so wie ich bei echten rechner vielleicht jedem server die passend
schnelle cpu geben könnte. balancieren ist ein aktives verhalten,
das ungleichgewichte korrigieren will. es braucht daher schon den
zweiten teil, die automatischen migrationen um dem begriff
gerecht zu werden. wenn man übernahme bei versagen/runterfahren
eines hosts dazu bekommt, so ist das ein netter neben effekt.

> -Du verteilst initial die Gastsysteme so, dass nicht ein Host am Anschlag
>  ist und die anderen Hosts idlen. Manuelles Loadbalancing.

das ist für mich nur eine zuordnung oder ein einmaliges tuning.
es sei denn, es würde dauernd einem am laptop sitzen, load überwachen
und migrations befehle klicken. gut, kann man so machen. weniger aufwand
als cpus zu tauschen.

> Basisdienste gehoeren auf isolierte Hostsysteme und je nach
> weiteren Abhaengigkeiten weiterhin auf physikalische Hardware.

ah, endlich. warum kann man die diskussion um virtualisierung nicht
gleich damit beginnen zuzugeben, für welche fälle es besser nicht
verwendet wird? muss man es denn erst in den himmel erheben und alles
schön zeichnen, nur um später wieder teile auszuklammern? ich halte
das für unseriös, es blieben doch auch noch genügend vorteile, wenn
man die beschränkungen gleich offen diskutiert.

> > > 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.
> >
> > Hardwarenah? ich seh da bei kvm/xen/vmware wenig unterschiede.
> > Interessant find ich eher, das KVM in vielen punkten das Rad nicht neu
> > erfindet, wo Xen den halben linux kernel kopiert und angepasst hat
> > (speicherverwaltung, cpu scheduler etc.). Aber das ist natürlich auch
> > zu kurz gefasst, KVM musste auch vieles anpassen am linux kernel, dafür
> > wurden dann aber auch alte baustellen mal angefasst und aufgeräumt und
> > verbessert (soweit ich die diskussionen auf den ML mitbekommen habe).
>
> "Hardwarenah" bezieht sich auf die CPU-Erweiterungen fuer
> Virtualisierung (die z.B. mein Desktop-PC nicht hat).

das wir bei servern keine paravirtualisierung diskutieren, war klar,
dachte ich. verzeiht mir, wenn das anders verstanden wurde.

> Boese Zungen sagen, dass ein root-qemu mit direktem Prozessorzugriff keinen
> wesentlichen Unterschied zu KVM bedeutet :-)

du meinst qemu mit oder ohne das qemu kernel modul?

technisch macht kvm vieles geschickter als der blanke qemu (selbst mit seinem
kernel modul), was sich besonders in der i/o performance merkbar machen soll
(disk, netz, swapping etc.).

um den langen thread zusammenzufassen (vielleicht kommen wir ja so zu einem
ende): im wesentlichen sind wir ja einer meinung. diverse scenarien, in denen
man keine virtualisierung einsetzen sollte haben wir nun gemeinsam gefunden.
der virtualisierung macht das nichts. einige features wie die "seltsame" 
hardware die emuliert wird sind wohl nicht weiter wild,wenn man diese für
performance eh nach der installation des gast betriebsystems durch passende
treiber für virtuelle geräte ersetzt. das argument der identischen hardware
hat eine delle bekommen, denn für live migration muss selbst die CPU der
host systeme gleich sein (nicht nur hersteller, wohl auch generation).

üblich ist, das man in lösungen wie mit vmware, nicht nur konsolidierung
durchführt (viele rechner auf einen packen), sondern auch das i/o dabei
von den servern abspaltet zu einem storage system, das man mehrere hosts
aufsetzt für die virtualisierung, die durch eine gemeinsame verwaltungs-
software managed, und auf diese weise zusätzliche möglichkeiten hat,
etwa live migration von guests auf andere hosts, und dies nutzen kann
a) wenn ein host gewartet werden soll oder schlafen soll um strom zu sparen,
b) load balancing (manuell durch admin oder automatisch durch verwaltungs-
software), c) failover durch shutdown/restart wird möglich (z.B: guests
neu starten, wenn ein host mit diesen abgeraucht ist).

andere argumente haben sich dagegen in luft aufgelöst. wer einen loadbalancer
für anfragen aus dem netzwerk braucht, der wird diesen auch durch 
virtualisierung nicht los (es sei denn, der neue host können nun die arbeit
von allen übernehmen, das wäre aber ein verdienst der schnelleren cpu,
nicht der virtualisierung). ebenso braucht man weiter einelösung wie
heartbeat, wenn man zwischen zwei aktiven systemen z.B. den master umziehen
will, oder eine hochverfügbaren server braucht, mit einer downtime deutlich
unter "einem bootvorgang". virtualisierung löst dieses problem nicht, die
software konfiguration sieht eher wieder gleich aus. virtualisierung mit
dem oben beschriebenen techniken und hardware ausstattung drum herum bietet
lediglich soviel komfort in der neuen "grundausstattung", das in vielen
anwendungsfällen der bedarf einer einer solche hohen verfügbarkeit nicht
mehr besteht, und die verfügbarkeit durch virtualisierung mit "guest 
neustarten" ausreicht. (weitere detials wie DRBD gegen SAN diskutieren
spar ich mir...)

kann man das so stehen lassen?

Tschüss, Andreas