[sage-ka] Virtualisierung als Sparmaßnahme
Marc Haber
mh+sage-ka at zugschlus.de
Di Apr 14 11:49:39 CEST 2009
On Tue, Apr 14, 2009 at 10:53:31AM +0200, Anders Henke wrote:
> 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.
... was natürlich nicht heißt, dass man solche unsupporteten Dinge
nicht doch braucht, sobald man nichttriviales (und dazu zählt schon
"Service Console auf einem getaggten VLAN") tun möchte.
> 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.
Kann man die VMware-tools auf Linux inzwischen ohne X installieren?
Gibt es Debian-Pakete oder muss man da selbst etwas machen? Ich
bekomme bei Vendorspezifischen "Treibern" immer nässenden Ausschlag,
ob es nun irgendwelche Raid-Monitoring-Tools, USV-Dingens,
Grafikkartentreiber oder auch nur Virtualisierungstools 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.
Dafür hat die Hostsoftware eine ganz neue Klasse von
Bedrohungszenarios, sei es nun dot1q, das man üblicherweise nicht bis
zum Endsystem führt, oder die Möglichkeit, aus einem kompromittierten
Gast auszubrechen und nicht nur den Host, sondern als praktischen
Nebeneffekt auch alle Gäste unter die eigene Kontrolle zu bringen -
selbst die Gäste, die aufgrund ihrer eigenen Bugfreiheit und
Abgeschottetheit eigentlich nicht kompromittiert worden wären.
> -Du verteilst initial die Gastsysteme so, dass nicht ein Host am Anschlag
> ist und die anderen Hosts idlen. Manuelles Loadbalancing.
Es sei denn, Du willst Strom sparen und idlende hosts schlafen legen.
> Basisdienste gehoeren auf isolierte Hostsysteme und je nach
> weiteren Abhaengigkeiten weiterhin auf physikalische Hardware.
In der Windows-Welt kann man solche Basisdienste nur sehr schwer
unabhängig von den Domaincontrollern betreiben. Und - natürlich -
werden solche Kisten auch virtualisiert, weil es das Management so
will. Ich hab sogar schon virtualisierte Virtual-Center und
Lizenzserver gesehen. Letzteres ist besonders "nett", wenn der
ESX-Server sich weigert, den virtualisierten Lizenzserver zu starten
weil er keine Lizenz zum Start von virtuellen Maschinen sieht.
> 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.
Dieser Spezialkernel tut allerdings massivst weh, eben weil die
Patches immer kräftig hinterherhängen.
> 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.
Und eigentlich dürften die Management-Konsolen auch nicht im
Server-LAN sitzen.
Grüße
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190