[sage-ka] Virtualisierung als Sparmaßnahme

Do Apr 9 08:36:20 CEST 2009

Hallo Anders,

im wesentlichen sind wir ja einer meinung :)

> Es gibt durchaus eine Reihe von Gruenden, das dennoch zu tun: deine
> virtuelle Hardware ist vollkommen uniform, wenn auch auf einem spontan
> seltsamen Stand (440FX mit AMD Netzwerkkarte, LSI-SCSI-Adapter und
> dazu ein AMD Opteron?).
>
> 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 ...

ja, seh ich auch so.

man muss aber auch zugeben, das ein hardware zoo jedem admin zeit und nerven
raubt, das man dies seit jahren weis, und das es durchaus möglich ist, auf
eine handvoll verschiedener systeme zu standartisieren, damit man so einen
quark nicht hat. wird von den gartner studien zur TCO seit vielen jahren
empfohlen.

wer daher einen hardware zoo hat, der macht was falsch, und kann das auch
auf andere arten lösen, als mit virtualisierung.

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.

> Wenn du eine virtuelle Kiste anlegen moechtest, dauert das
> zwei Klicks und nach 10 Minuten hast du selbst beim Boot
> von CD ein fertiges System.
>
> Wenn du eine physikalische Kiste von Grund auf installierst, dauert das
> ganze hingegen zwei Tage. Das Spielchen kannst du nur fuer ein paar
> Hundert Rechner durchrechnen, dann weisst du, was du mittelfristig
> sparen kannst.

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.

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?

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

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).
mit strom und netz installieren kostet das 5-15 minuten, wenn man das
auf zwei mal in der woche ansetzt, kann man personalkosten von
0.5h / 40h, also 1-2% sparen? schöne milchmadchenrechnung.

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?

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 in einer anderen email vorgestellte scenario mit mehreren servern und 
allen daten im san stelle ich mir nett vor. wer gleiches ohne virtualisierung
aufbaut, hat aber sehr ähnliche vorteile, so das ich da keinen großen
unterschied sehe.

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

eher zusatzkosten: für N rechner hat man nun N+1 mal betriebsystem
und monitoring und backup und security updates am laufen. je nach N
ist das aber recht egal, schwerer wiegt, das man eine klasse an
rechnern mit eigener config mehr hat (wieviele rechner in einer
klasse sind, ist nach meiner ansicht nicht so wichtig, ein paar
mehr sorgen nicht dafür, das man mehr denken muss, sondern nur
das man die gleichen kontroll werte nochmal prüfen oder befehle
nochmal tippen muss - weniger probleme, als umdenken von verschiedenen
installations typen).

> Wenn du virtuelle Systeme miteinander verbinden moechtest, musst du
> nicht ueber VLANs arbeiten, sondern kannst den virtuellen Systemen
> mehrere "echte" Netzwerkkarten geben, die vom Hostsystem aus
> dann entweder auf VLANs gemappt oder auf "echte" L2-LANs hin gelegt
> werden. Es entfaellt ein Abstraktionslayer, der mit Kabelziehen
> verbunden waere.

in der praxis sollte man die systemstruktur aber simpel halten oder
eh rechner mit ähnlicher sicherheit etc. zusammenlegen, dann spart
man sich wirklich ein kabel für einen extra rechner. wenn man aber
z.B. einen rechner für eine neue zone virtuell aufsetzt, hat man
nun statt einfachem kabel einstecken eine kombination aus vlan
auf dem switch zuschalten, vlan im host entgegen nehmen, vlan im
host auf neue virutelle instanz lenken.

zudem ist ja nicht alles virtuell, der host braucht nach wie vor seine
kabel, und die müssen auch dokumetiert werden. wird ein simples
kabel, das am switch verwaltet wird, nun durch mehrere oder ein kabel
mit vlan ersetzt, das im rechner zugewiesen wird, so hat man in
der dokumentation und beim debuggen schon mal ein komplexeres system,
weil es nicht mehr einstufig, sondern zweistufig ist.

solange man einfache systeme (z.B. ein netz für server) hat, spart
man natürlich aufwand, ja, und hat auch keinen großen mehraufwand
in der doku, weil die eh einfach ist.

> 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.
grund für sowas ist ja meist die angst vor hardware ausfällen,
und so würde ein hardware ausfall gleich wieder beide redundanten
rechner vom netz kicken. nichts gewonnen?

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. 

ü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. bleibt nur der fall des load-balancing
als frontend für mehrere backend systeme. wenn die kritisch sind,
dann müssen die auch auf verschiedenen hosts laufen, damit ein
hardware ausfall nicht beide betrifft, und dann braucht man den
load-balancer für die zwei virtualisierten hosts davor trotzdem.

drbd, wenn man das einsetzen will, fällt auch nicht weg, weil die
verteilung von zwei virtuellen servern auf zwei hosts das weiter
braucht. nur könnte man es nun im host stadt im gast implementieren.
nimmt die komplexität aber nicht weg, reduziert nur die anzahl der instanzen.

heartbeat braucht man weiter - auch wenn hosts in milisekunden einen gast
von hier nach da verschieben können, es verlässt sich doch niemand darauf,
das dies bei einem stromausfall/netzteildefekt noch schnell passieren kann,
oder? also braucht man zwei virutelle server mit heartbeat, nur einen
auf zwei redundanten hosts reicht für strenge anforderungen zumindest nicht.

wenn man natürlich damit leben kann, das bei einem aufall eines hosts, alle
virtuellen maschienen auf dem anderen in ruhe gebootet werden, dann wird
die situation viel einfacher. manchmal hast du recht, pauschal für alle
fälle gilt es aber nicht.

> Alles auf einen Host ist wirklich Bloedsinn, das Verhaeltnis
> "16:1" ist aber je nach Anwendung vollkommen okay.
>
> Wir haben einige Systeme, auf denen ein paar Dutzend virtuelle Server
> je physikalischem System arbeiten, ohne auch nur in die Naehe von
> "ausgelastet sein" zu kommen. Wenn du das mit Redundanzsystemen
> verknuepfst, kann das sehr attraktiv sein.

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?

zudem hat man ja normal vor allem die entscheidung: redundanz
brauchen wir nicht (günstig), oder voll redundanter setup (teuer
und komplex). mit virtualisierung wie beschrieben kommt eine
möglichkeit hinzu, die zwar nicht ganz soviel bietet wie eine
voll redundanter setup, aber für viele fälle ausreicht, und die
mehrkosten gegenüber der lösung ohne redundanz für den mehrwert
oft gerne in kauf genommen werden.

virtualisierung ist nicht ohne alternativen. wenn man ein scenario
mit mehreren hosts und einem SAN backend aufstellt, könnte man auch
mehrere server mit einem SAN als vergleich konfiguration ansehen.
von den servern müsste einer brachliegen, um als reserve zu dienen,
das sind kosten, die hosts für die virtuelle lösung könnten hingegen
alle gleichzeitig laufen, bräuchten aber RAM reserven, das sind auch kosten.

wenn man bei der RAM ausstattung im günstigen bereich bleibt (also nicht die 
aktuell größten ram riegel für unsummen braucht), dann ist ram so günstig,
das man mit virtualisierung vermutlich günstiger liegt, und für
dem admin ist sie auch sehr bequem.

naja, server per ipmi anschalten und per bootptab und pxe das richtige system 
booten lassen geht auch, aber die GUI zur verwaltung mehrerer viruteller hosts 
ist vermutlich schon fix und fertig von vmware oder wem-auch-immer und daher 
weniger aufwand im aufbau.

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.

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?

Tschüss, Andreas