[sage-ka] Virtualisierung als Sparmaßnahme

[Olaf Hopp]

Andreas Jellinghaus wrote:

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

Nein, weil SUN noch nie PowerPC verbaut hat.
Und wenn IBM nun doch nicht SUN kauft, dann
wird's das auch auch in Zukunft nie geben.

SPARC heissen die Dinger von SUN.

VMware und Co. virtualisieren nur x86 kompatibles Zeugs

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

vmware-Tools heisst die Sammlung von Treibern.
Besteht im wesentlichen aus "besserem" Netzwerkstreiber,
bessere Grafik anstatt 08/15-VGA, aber hier keine Thema, wir
reden ja hier von Servern. Nur die Kollegen von der
Maeuseschubser-Fraktion sind froh drum....
Um Platten-IO kuemmern die sich nicht, beim ESX hast Du
die Wahl zwischen LSI oder BusLogic. IDE-Platten gibts nicht,
nur als CD-Laufwerk.

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

Wenn Du von VMotion der laufenden VM sprichst, dann sind Dir
bei der CPU recht enge Grenzen gesetzt. Bei Vmware gibt es entsprechende
Kompatibilitaetslisten. Intel <-> AMD ist auf jeden Fall ein "No GO".
Aber selbst z.B. innerhalb der AMD Opterons moegen die 3-stelligen
CPUs nicht mit den 4-stelligen.
Hat aber nichts damit zu tun auf dem einen Server die VM runterzufahren
und auf dem anderen zu starten. Das geht problemlos, wenn, ja wenn
Dein Gastsystem da mitmacht. Windows zickt da etwas mehr als die "anderen".
Und HA (Host 1 ist down, Host 2 startet die "fehlenden" Gaeste aus dem
SAN) greift dann auch.

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

Das laesst sich ja verhindern, aber genau dazu sind "wir" ja da.
Irgenwas musst Du auch noch tun und pflegen.

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

Doch, weil der haelt einen mit seinen Fragen ja auch noch
von der produktiven Arbeit ab....

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

Siehe Text oben,
Mischen kannst Du alles, VMotion geht eben nur wenn's passt

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

Ja, jeder Host muss jede Storage-Lun sehen auf denen die VMs laufen

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

Man koennte dem Gast selber iSCSI mit dem SAN reden lassen, dann gelten Deine
Argumente. Ganz, ganz schlecht. Wenn die ESX-Hosts iSCSI (oder FC) reden, dann
sehen die Gaeste lokale SCSI-Platten, von SAN / NAS sehen die _nie_ etwas,
wie denn auch ?
Unter der Vorraussetztung, dass das SAN ein eigenes abgeschottetes Netz ist
in das nur die ESXe ein Beinchen drin stehen haben.


Olaf

-- 

==============================================================================
      __0
    _-\<,_     Dipl.-Geophys. Olaf Hopp
   (_)/ (_)    ATIS - Abteilung Technische Infrastruktur

University of Karlsruhe          EMail: Olaf.Hopp at atis.uni-karlsruhe.de
Faculty of Computer Science      WWW  : http://www.atis.uni-karlsruhe.de
Building 50.34 Room-No. 009
Am Fasanengarten 5               Fon  : +49 (721) 608-3973
D-76131 Karlsruhe / Germany      Fax  : +49 (721) 608-6699

==============================================================================


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/x-pkcs7-signature
Dateigröße  : 5863 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : http://lists.guug.de/pipermail/sage-ka/attachments/20090409/523fbe52/attachment.bin