[sage-ka] Virtualisierung als Sparmaßnahme

[Anders Henke]

Am 09.04.2009 schrieb Andreas Jellinghaus:
> 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?

Beim Hostsystem wird dir diese Arbeit abgenommen.
Aus deiner Sicht sicherlich zu einem inakzeptablen Preis
(ESX unterstuetzt kein Software-RAID und bestimmte "billige"
RAID-Controller werden nur mit nicht-supporteten
Hersteller-Beta-Treibern zum Laufen gebracht), aber rein der 
Ausfuehrlichkeit halber:

Ein ESX(i) wird installiert, indem man entweder 
-beim Lieferanten die ESX-Option mit dazubestellt, dann bekommst du ein 
 kleines Flashmodul in oder an deinen Rechner gestoepselt, der als 
 "aufgeblasene BIOS-Erweiterung" oder "bootbarer USB-Stick" arbeitet.
oder
-eine CD reinschiebt, auf "Installieren" drueckt und dann die genuegend
 namenhafte Hardware (in Bezug auf Netzwerkkarten, FC-HBAs, SCSI-Adapter,
 RAID-Controller) auf einer einstellbaren Festplatte(n-aehnlichen
 Konstrukt) mit dem ESX(i)-Image ueberschrieben wird.

Die Host-IP und Namen zieht sich das System per Default via DHCP,
beim ersten Start werden dann auch eigene SSL-Zertifikate generiert
und das System soweit in einen Zustand gebracht, in dem man es
mit einem Windows-Client konfigurieren kann.
Ja, IP und Hostnamen kann man "zu Fuss" konfigurieren. Man kann
das root-Passwort (fuer den Zugang via Windows-Client) an der
Konsole konfigurieren, ansonsten kann man an einer physikalischen 
ESX-Host-Konsole (ausser unsupporteten Dingen) praktisch nix tun.

Es gibt keine Softwarepackages zu installieren und Softwareupdates
sehen so aus, dass dann ein komplett neues Image drueberkopiert und 
mit einem Reboot aktiviert wird.

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

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. Und wie
es der Unbill der IT so will, hast du nicht genuegend (passende)
Steckplaetze in deiner 1HE-Standardhardware drin, um das externe
Chassis zu unterstuetzen. Und -zack- hast du einen weiteren Hardwaretyp.

Ja, in der kleinen Firma, in der man alle 3-4 Jahre Ersatz fuer "den
Server" kauft, kann man derartige Effekte ignorieren. Virtualisierung
ist aber etwas, was in kleinen Firman nur bedingt hilfreich 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.

Der Host isoliert diese Elemente komplett von seinen Gastsystemen.

Das Gastsystem sieht z.B. einen LSI Logic SCSI-Controller mit einer
daran haengenden Platte. 

Ob diese Platte nun auf Hostseite exakt eine Platte, ein SAN, ein 
Imagefile auf einen NFS-Server, ein RAID 0/1/10/3/4/5/6/50/55 ist oder 
was fuer ein Controller wirklich drunterliegt, sieht das Gastsystem nicht.

Wenn das Gastsystem zwei Platten sieht, weiss es auch nicht, ob dies
wirklich zwei Platten sind oder einfach Imagefiles auf dem gleichen
NFS-Server. Die Logik wird komplett abstrahiert.
 
> > 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.

Fuer Notfaelle haelt man sich natuerlich immer noch das Notebook bereit,
auf dem man dann auch alle Software vorhaelt, die man "im Notfall"
brauchen koennte.
Und ja: die Spezialsysteme klammere ich in der Virtualisierung komplett
raus.

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

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.

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

Was meinst du damit? 
 
> > 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?

Bei Livemigration von Hardware-virtualisierten Systemen: ja.

Beim Thema "runterfahren auf Host A, hochfahren auf Host B"
kommst du natuerlich drum herum, dafuer hast du eben eine
erzwungene Downtime. 

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

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

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.

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.

Es gibt auch noch die Variante active-active, bei der halt die Teilsysteme
nur zu einem n-tel ausgelastet sein duerfen, um fuer ein Teilsystem
Redundanz zu bieten (bei zwei Hosts duerfen beide maximal zu 50%
belastet sein. In der Praxis will man noch Sicherheitspuffer
einbeziehen, da die Ressourcen ab etwa 70-80% Last nicht unbedingt
weiter linear skalieren).

Beim Loadbalancing verteilst du eingehende Last auf verschiedene Systeme.

Wenn du deine 80 virtuellen Systeme ueber 4 Virtualisierungshosts
verteilst, betreibst du an der Stelle eine Lastverteilung
und gleichzeitig etwas HA:
-Wenn einer der vier Hosts wegbricht, uebernehmen die anderen Hosts
 dessen Gastsysteme. Typisches Beispiel fuer HA/Failover.

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

-Verschiebt sich das Lastgefuege so, dass Host A deutlich mehr zu tun
 hat als Host B, ziehst du einfach ein paar Gastsysteme von A nach B um.
 Manuelles Loadbalacing.

-bei VMware gibt's mit dem "Dynamic Resource Scheduler" eine Option,
 dass die Gastsysteme entsprechend der Host-Ressourcen automatisch 
 verteilt werden. An dem Punkt wird dann der Unterschied zu
 "klassischer" Lastverteilung richtig schwer zu greifen.

Bei Bedarf kannst du natuerlich auch bestimmte Hosts "festpinnen",
so dass sie zwar weiterhin HA sind, aber nicht automatisch umgezogen
werden.

Wichtig: du balanced auf einer anderen Ebene, hast dadurch 
auch andere Potentiale und Moeglichkeiten. Es geht nicht darum,
"die eine" Anwendung auf moeglichst viele Rechner zu verteilen, 
sondern ein breit verteiltes Lastszenario.

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

Andreas, bitte stell dich nicht duemmer als du bist :)

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

Wenn die Virtualisierungshosts z.B. ihre IP per DHCP ziehen,
sollte der DHCP-Server kein virtuelles Gastsystem sein - spaetestens
mit einem Stromausfall bekaeme man Probleme, das Setup wieder
"irgendwie" zum Laufen zu kriegen. Wie gesagt: man virtualisiert nicht,
um einfach alles "virtualisiert" zu haben, sondern um ein paar konkrete
Ziele zu verfolgen, ohne dabei neue Gefahren einzugehen.

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

Wenn ich als IT-Leiter weder weiss, was fuer ein Schaden mir durch einen 
Ausfall entsteht noch was meine Arbeit gekostet hat, fehlen mir genau die
Informationen, die ich fuer meinen Job benoetige (und ja: sowohl die
Zahlen fuer den Einzelfall als auch fuer das gesamte Jahr).

Ansonsten kann ich weder belegen, dass mein IT-Betrieb wirtschaftlich 
arbeitet noch kann ich einschaetzen, wie viel Spielraum ich habe, um 
meinen IT-Betrieb effizienter und/oder wirtschaftlicher werden zu lassen.

Idealerweise mit genauen Fallzahlen (die sich erst ab einer gewissen Menge 
an Systemen einstellen), unterfuettert mit der dazugehoerigen Menge Geld,
ansonsten einfach in "Menge Geld durch Aufwand". Und solange letzteres 
kleiner ist als der durch Nichtstun verursachte Schaden, ist der IT-Betrieb 
an der Stelle mindestens gerechtfertigt. 

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

KVM braucht Erweiterungen im Prozessor (z.B. Intel VT) und emuliert
anschliessend via qemu Hardware, kommt daher dann mit relativ wenig 
Erweiterungen im Linux-Kernel aus - braucht aber eben jene
Erweiterungen: egrep '^flags.*(vmx|svm)' /proc/cpuinfo

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

Xen hingegen bietet auch eine volle Paravirtualisierung auf Prozessoren 
ohne diese Erweiterungen, bei dem quasi jeder Syscall einzeln zum
Hypervisor durchgereicht wird und das Gastsystem daher einen "Spezialkernel" 
bekommt. Ueber spezielle Hooks und Interfaces zum Hypervisor kann man aber
auch z.B. PCI-Karten ins Gastsystem durchreichen; diese Flexibilitaet 
und Arbeitsweise bringt aber auch viele Anpassungen mit sich, die eben einen
Haufen Anpassungen im Linux-Kernel bedeuten.

VMware versucht in erster Linie Hardware zu emulieren, seit einigen Jahren 
auch mit Unterstuetzung der CPU-Erweiterungen. Bestimmte Funktionen kann man
sich ueber die vmware-tools paravirtualisieren lassen, um die Last auf dem 
vmware-Hostssystem zu senken und die Performance zu steigern.

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

Sinnvolle Kombinationen:
-Alle Daten auf SAN/NAS, damit die Migration ohne Kopieren auskommt.
-Jedes Gastsystem bekommt gefaelligst sein eigenes Blockdevice,
 die Zugriffsrechte darauf werden dann vom ESX verwaltet.
-ESX-Host haengt z.B. in mehreren LANs bzw. VLANs und exportiert
 nur das jeweilige LAN an die Gastsystme, in denen diese etwas zu
 suchen haben.

Natuerlich kann auch dein Gastsystem selbst iscsi sprechen oder
via PXE vom Netzwerk booten - ob das dann jeweils sinnvoll ist,
ist eine Frage deines Sicherheitskonzeptes und dessen Umsetzung.

Letztlich ist es ueberall das gleiche Wasser, das du seit Jahren an 
anderen Stellen kennst: die Management-IP deiner Switches haengst du auch 
in ein eigenes VLAN, das von den an den Switches haengenden Rechnern in 
der Regel keiner erreichen darf/sollte/kann. 
Genauso isolierst du dein SAN/NAS von den Gastsystemen, erlaubst aber den 
Hostsystemen den Zugriff darauf.

Anders
-- 
1&1 Internet AG              Systemarchitekt
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