[sage-ka] Virtualisierung als Sparmaßnahme

[Andreas Jellinghaus]

Hallo Anders,

schön, das du erklärst wie es zu diversen generationen Hardware kommt.
Damit ist dein Argument aus dem Posting vorher
--cut--
Diese uniforme Hardware kann dir eine Menge Nerven ersparen,
weil du eben nicht alle zwei-drei Jahre beim Hardwaretausch
ueberlegen musst, mit welchem Treiber du nun den neuen SATA-Chipsatz,
die Netzwerkkarte und den RAID-Controller angesteuert bekommst und
ob die Distribution deiner Wahl ueberhaupt diese Treiber so
unterstuetzt ...
--cut--

wieder vorbei, weil du ja doch wieder wechselnde hardware hast,
und für die host system diesen ganzen spass?

zudem: eine hardware generation pro jahr, 3-4 modelle, 3-4 jahrgänge,
das ist noch halbwegs überschaubar, da kann man beim kauf der neuen
modelle rausfinden und dokumentieren, welche treiber und macken man
hat, wo das bios ist, welche version benutzt wird, wie man es sauber
einstellt, und gut ist.

wer natürlich mit jedem rechner den er anfasst das rad neu erfindet,
weil notizen machen oder lesen uncool ist, der hat natürlich probleme.
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.

> 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.

da hilft dann auch keine virtualisierung mehr, oder? gibts jemand der
so mutig ist, die sun mit powerpc zu virtualisieren (hmm, qemu emulation?)
oder die san management software in eine virtuelle instanz zu stecken?
ich würd das ja alles lieber nicht machen, wäre mir zuviel risiko.

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

für TCO studien wird ja gerne geschimpft, da steht aber genau drinn,
das geregelter ersatz nach der geplanten lebensdauer günstiger ist
als das ungeregelte weiterlaufen lassen (mit den beliebten "jetzt!gleich!
sofort! lebensnotwenig!" einsätzen für admins, sobald die hardware aufgibt).

> 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.

vmware ja.kvm hat ähnliche, aber leicht andere liste, zudem werden doch
virtuelle treiber geschrieben, die deutlich performanter sein sollen.
hat vmware nicht auch treiber für virtuelles i/o, so das man die ide
oder scsi bzw. die netzwerkkarten emulationen besser nur für die
installation verwendet, weil es sonst soviel performance kostet?

erlaubt vmware inzwischen performance messungen (und deren 
veröffentlichungen)?


> In dieses "seltsame" Hardwaresetup bekommst du dann den Prozessor
> reingestellt, den das Hostsystem wirklich hat (z.B. ein AMD Opteron).

und wie ist das dann bei der migration von einem host zum anderen?
man möge bitte eine gleiche cpu auf allen hosts haben, sonst knallt es?

jedenfalls fürchte ich sowas, daher denke ich das auch virtualisiert,
die hardware eben doch nicht 100% identisch ist. und sei es auch
nur, wenn die software version der virtualisierungssoftware auf dem
host verschieden ist, und eventuell verschiedene macken hat.

> In gewisser Form eine durchaus positiv behaftete Chimaere.

ich sag ja gar nichts dagegen. nur nicht so perfekt, wie sich das auf
anhieb gelesen habe. zumindest wenn ich die entwickler diskussionen
richtig gelesen habe, in denen auch performance probleme durch emulation
der alten hardware angedeutet werden. (vielleicht ist vmware da super
genial, aber ich hab eher den eindruck, das alle nur mit wasser kochen,
auch wenn manche länger dabei sind und mehr erfahrung haben...)

> 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.

auch da bin ich skeptisch. werden euch monatlich neue images
zur verfügung gestellt, in denen aktuelle security fixes drinn
sind.

meine windows erfahrung ist zum beispiel, das es nach einer
gewissen zeit schneller ist, das aktuelle install medium von
microsoft (technet etc.) zu verwenden mit den service packs,
als eine altes image, auf dem man erstmal stundenlang security
updates nachschieben kann.

zudem zurück zur kernfrage, die schriebst:
"Da macht der Admin die Systeminstallation nur alle zwei-drei Jahre,"

na wo sollen dann die einsparung in den personalkosten herkommen?
wenn der admin alle zwei bis drei jahre einmal 2 tage arbeit auf
ein paar stunden reduziert bekommt (dafür aber gar nicht so sicher
ist, was er da nun als ergebnis hat, denke ich mal)? 2 tage sind 1%,
alle 2-3 jahre wäre das 0.5% oder 0.33% im jahr.

mich würde ja sehr interessieren, was die leser hier als normal
ansehen, welchen anteil verbringen admins mit hardware pflege und
betriebsystem installationen? solange man sich da vor einem
mittleren wert drückt, kann es aus meiner sicht keine einsparungen
geben - im seltenen fall, passiert zu wenig, im super häufigen fall
wurde das automatisierte routine, aus der nicht mehr viel einzusparen
ist. daher: was sind denn nun realistische werte?

> 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).

hmm, 6% einsparung? das würde klappen, wenn man stadt einen tag
die woche nur noch knapp über einen halben braucht (3 stunden ersparnis).

oder sollen die einsparungen eher aus sonderfällen kommen?
ein server crash der mit weniger überstunden behoben wird? das
müssten nach meiner rechnung 96 arbeitsstunden im jahr sein.

scheint mir beides ein wenig viel. was haltet ihr denn für realistisch,
wieviel stunden verbringt ein admin mit sondereinsätzen, in denen
virtualisierung helfen könnte?

> 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.

na beim admin der, nach deinem beispiel, das nur alle 2-3 jahre macht,
was sollen da die paar stunden fürs auspacken und zusammenbauen des
servers sein? damit man auf einsparungen im nennenswerten bereich
kommt, müssen da auf die woche oder den monat diverse stunden
zusammenkommen, damit überhaupt ein kostenfaktor da ist, den
man senken kann.

[tco arbeitskosten]
danke, kenn ich. aber die skalieren auch mit der arbeitszeit,
wer 20% personalkosten bei admins sparen will, der muss mit vier
stadt 5 admins bei gleicher auslastung arbeiten können, egal
wieviel die pro nase verdienen.

> 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.

na das wäre interessant, wenn das in einer studie steht: mit
unserer software brauchen sie weniger gut ausgebildetes und
geschultes personal. leider zieht sowas. aber ich dachte, die
gesenkten personalkosten beziehen sich auf den personalaufwand
in zeit (=kosten), nicht auf das notwendige niveau an ausbildung
und fähigkeiten. was stand denn dazu in der orginal studie,
die am anfang erwähnt wurde?

> 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 ... :-)

macht "der chef" deswegen eine stunde weniger produktive arbeit?
schreibt der seine überstunden auf oder rechner sie ab? eher
nicht, oder? also keine kostenveränderung. :-)

> 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.

Denke ich ja auch, für mich ist es ein weiteres Tool. Erst wenn man
das neue Werkzeug gut kennt, merkt man, wo es überall sinnvoll eingesetzt
werden kann. Wenn man zuwenige Werkzeuge kennt, trifft man leicht falsche
Entscheidungen ( “If the only tool you have is a hammer, you tend to see every 
problem as a nail.” — Abraham Maslow )

nur sowas in eine Kosten/Nutzen-Rechnung zu verpacken ist schwierig.
Wenn wir hier nicht mal eine Einigung über glaubhafte, verbreitete
Ausgansszenarien finden, wird das in einer auf vorteil bedachten
Studie zwecks Verkaufsförderung erst recht nicht sauber sein.

> 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".

jau, siehe mein posting einige mails vorher, mir hats beim testen von
installationscds sehr viel zeit gespart, cd brennen, rechner booten
(bios check etc.), langsames bios (viel langsamerer i/o) usw. kosten
alle viel zeit.

> 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.

ich seh schon, wir sind von der reinen "Virtualisierung" sehr weit
weg zu einem professionellen Setup gelandet, der von dir beschrieben
Features bietet. 

> 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.

moment, wenn du alle software auf einem host ohne virtualisierung 
installierst, hat du ein grotten misserables system (weil duzende
dienste ohne saubere trennung), aber mehr performance und weniger software
kosten.

Ein teil deiner Einsparung kommt erstmal durch "Konsolidieren von mehreren
Rechnern auf wenige", das kann man sauber oder dreckig machen. Virtualisierung
ist sauberer, teurer (software etc.), aber viel wartbarer und flexibler.

und ob man zeit spart durch weniger ausfälle - eine virtualisierungslösung
mit redundanten servern etc, da gebe ich gerne recht. nur wer es zu einfach
macht und einfach viele rechner auf einen konsolidiert, ohne reserven auf
weiteren rechner, failover etc., der hat weniger hardware die kaputt gehen
kann, dann aber ein viel größteres problem, wenn es passiert.

So einfach ist es also nicht, die von dir genannten Einsparungen geben ich
gerne zu, nur braucht es dafür eben noch die weiteren schritte, die ja auch
erstmal alle Geld kosten, schulung brauchen, Leute brauchen, die solche
Scenarien verstehen und damit umgehen können, und auch teurere hardware
eventuell (z.B. Daten auf einem SAN lagern, statt auf den Platten im Server).

> 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.).

Ist aber nur ein Failover auf Recht niedriger ebene. Hot Standby Lösungen
mit Übernahme der Dienste in kurzer Zeit kann man damit nicht ablösen.

Ich denke interessant ist vor allem, das es neben den bisher verbreiteten
Lösungen keine Redundanz oder Hot-Standby somit eine weitere Spielart gibt,
die für viele Fälle ausreicht, und attraktiver als die beiden anderen
Varianten ist. Wenn man die Virtualisierung mit mehreren Hosts und
Failover zwischen denen erstmal hat, merkt man plötzlich, das dies
für relativ viele VMs interessant ist, kostet ja auch nicht mehr viel
extra.

> > 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.

Für mich ist das Failover, nicht Loadbalancing, und auch nicht hot-standby.
(letzteres sehe ich für aktiv replizierte Datenbanken an etc. - software
ist bereit und mit aktullen Daten versorgt, braucht nur die info "Du bist
nun chef" (und evtl. die IP des Dienstes)). Irre ich mich da mit den 
Begriffen? wie wären die korrekten Bezeichnungen?

> 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.

naja, es gibt beides. dicke fette datenbank und kleine server ohne fette
dienste.

beide dhcp oder dns server auf den gleichen virtuellen host zu virtualisieren
halte ich trotzdem irgendwie für unschick. Klar, wenn man ein funktionierendes
failover zwischen zwei hosts hat mag auch das gehen, so das es einem egal ist,
aber - nenn mich altmodisch - ich find immer noch, die sollte man getrennt
halten :)

> > ü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.

nagut, mag ja vielleicht auch einfacher sein, mehr server zu kaufen
und alle einheitlich zu konfigurieren, inclusive virtualisierung, stadt
die performance durch getunte rechner ohne virtualisierung zu erhalten.
es gibt bestimmt leute, die solche scenarien gegeneinander abwägen, wer
kann es ihnen verdenken. vermutlich ist über die TCO die virtualisierung
sogar günstiger.

> 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.

dann nennen wirs doch lieber: Konsolidierung,ohne das ein unwartbares
monstrum mit vielen verwachsenen diensten entsteht. Wer mal den Spass
hatte solche Rechner zu warten/migrieren/abzulösen, die über Jahre
immer mehr dienste gesammelt haben "weil ja noch luft war", der weis
wie unangenehm sowas ist. Dann lieber Virtualisierung mit vielen getrennten
instanzen, die jeweils wenig machen. Hoffen wir das genügend RAM da ist,
um immer weitere Instanzen aufzusetzen (einen gewissen RAM overhead hat
jede weitere Instanz ja schon). Und hoffen wir, das die admins nicht
faul werden, sondern dann alle viele kleinen instanzen auch mit security
updates versorgen. Da fürchte ich ja schon lange, das man nicht nur
bei vielen Servern gerne anfängt die unwichtigen zu vergessen, sondern
erst recht bei virtuellen server anfängt, die unwichtigen instanzen zu
vergessen. Dem wurm ist es egal, der freut sich über jede kiste mit loch.

> 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.

Glaub ich gerne. Sagen wir mal lieber so: hoffentlich gibts keinen
Erbsenzähler, der merkt, das eine konsolidierung ohne Virtualisierung
performanter oder billiger ist (und vergisst, das die unwartbar wird).

> Wie gesagt, die Rechnung muss man letztlich selbst machen.

Ich tippe mal vieles wird aus dem Bauch entschieden. Wer hat denn
schon konkrete zahlen, wie oft ein rechner kaputt geht, die hardware
upgrade oder wartung braucht, und so weiter? 

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

Hmm. Luftblasen durchschauen die meisten Leute schon. Ich würde es weniger
kritisch sehen: es wird sehr gerne übertrieben, und Alternative und Nachteile
werden zu wenig 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).

> 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.

hat redhat von der KVM mutter nicht auch genau so eine Verwaltungslösung mit 
eingekauft und will das demnächst veröffentlichen? Jedenfalls würde ich mich
nicht wundern, wenn da bald was nachkommt.

Was mich noch interessieren würde: welche beschränkungen hat vmware
(z.B. gleiche CPU in allen servern? oder kann man opteron und xeon mischen?),
wie muss das storage dafür aussehen (ich tippe mal: alle daten auf ein 
zentrales SAN oder NAS, damit für einen Umzug nichts kopiert werden muss?),
und wie sieht es mit der security zum storage aus? ich nehme an null: alle
hosts können auf alle daten zugreifen, damit jeder im zweifel jede VM starten
kann? guest sicherheit darüber, das der host das SAN in eine IDE/scsi/block 
device emulation umsetzt? oder werden in solchen scenarien den guests iSCSI
treiber mitgegeben, über die sie selbst mit dem Storage reden? gibts dann
irgendeine sicherheit? oder muss man fürchten das ein gehackter guest auf
den storage eines anderen guest kommt (weil ungeschützt oder mit brute force
barem passwort gesichert etc.)?


> 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.

Kann ich gut verstehen. "Keep it simple" kann auch bedeuten, eine fertige
Lösung zu kaufen. Vor allem sehr gut, bei Fluktuation im Personal. Aber
der Geek in mir will auch immer wissen, welche Features genau vorhanden
sind, und wie man das selbst basteln könnte - für den Produktionseinsatz
würde ich trotzdem sowas nicht empfehlen (man will ja auch in den Urlaub
gehen können oder mal krank sein - der unersetzbare Guru der als einziger
wissen über eine superwichtige Sache hat, das interessiert mich nicht :)

Ich glaub wir sind im wesentlichen der gleichen Meinung, nähern uns nur
teilweise von zwei Seiten oder Diskutieren durch zu ungenaue Formulierung
auch schon mal an einander vorbei. Macht trotzdem Spass, danke für die
eMail.

Tschüss, Andreas