Re: Linux-VServer [was: xen-Kern bootet nicht in Lenny]
Hi Harald,
Am Montag, den 19.01.2009, 10:51 +0000 schrieb Harald Weidner:
> Hallo,
>
> >Genau das ist der Punkt. vserver ist halt richtig lightweigh (hatte
> >damals standardmässig nichmal loopback-devices), ist dafür aber
> >rattenschnell.
>
> Falls du mit "damals" die Version aus Debian Etch meinst: dort
> kann man bei Bedarf einfach in /etc/vserver/name/interfaces ein
> eigenes Loopback-Device hinzufügen und jedem VServer eine eigene
> Adresse zuordnen (z.B. 127.0.0.2, 127.0.0.3 etc). Damit kommen sich
> Dienste, die auf lo gebunden sind, nicht in die Quere.
ui - dafür ist das echt zu lange her, dass ich das noch genau weiß. Aber
irgendwas wollte damals trotz diesem "tweak" nicht tun...
> Zwar ist es möglich, von einem VServer aus die Netzwerkdienste der lo
> Devices der anderen VServer über ihre IP-Adresse zu kontaktieren. Das
> lässt sich jedoch mittels Netfilter-Regeln einfach unterbinden.
>
> Unter Debian Lenny blendet jeder VServer grundsätzlich das lo Device
> mit der Adresse 127.0.0.1 ein. Eine Adressänderung ist nicht möglich.
> Damit blockieren Dienste, die innerhalb eines VServers einen Port auf
> lo binden, diesen Port auf dem gesamten Host. Für einen reibungslosen
> Betrieb muss jeder Dienst innerhalb der VServer so konfiguriert werden,
> dass er nur auf eth*, nicht auf lo bindet. Meiner Meinung nach ist das
> ein Rückschritt, denn bei Etch ist das lediglich auf dem Host nötig.
>
> Zudem vermisse ich in Lenny einen Kernel, der VServer und Xen
> gleichzeitig unterstützt. Unter Etch kann man Linux-VServer innerhalb
> einer DomU und sogar in der Dom0 verwenden, ohne auf nicht-Debian
> Software zugreifen zu müssen. Unter Lenny ist mir dazu kein Weg bekannt.
dito. hab ich zumindest auch nirgends gesehen.... Würde mich aber
dennoch interessieren, da das immer recht interessant war für gewisse
Anwendungen
> Falls ich mich täusche, bin ich natürlich für Hinweise dankbar. ;-)
>
> >Wo ich halt den größten Nachteil sehe, ist der fehlende
> >Swap. zB reicht dir ein vserver mit 128 MB RAM nicht, um einen
> >mail-server mit virtual-users auf einem setup a la postfix, mysql, clam,
> >sa, dovecot, xyz ans laufen zu bringen, wobei selbiges unter XEN mit
> >256MB swap prima tut. gleiches gilt übrigens auch für kvm und openvz.
>
> Der letzte Satz ist irgendwie mehrdeutig.
Ok, ich konkretisiere :) Ich meinte damit, dass dieses Setup unter XEN
(PV) funktioniert, sich allerdings die anderen Lösungen hierbei die
Zähne ausbeißen.
> Nach meinen bescheidenen
> Kenntnissen gehört hier KVM in die gleiche Katagorie wie Xen
Jein, kvm = hvm-xen: Beide Techniken sind diesbzgl vergleichbar, wenn
man xen im HVM-Modus betreibt / quasi in den xen-configs
kernel="/usr/lib/xen-3.2-1/boot/hvmloader"
builder='hvm'
setzt - dann verhält sich xen ähnich zu kvm.
XEN kann jedoch einiges mehr und spielt vorallem in PV-Modus seine
Stärken in Sachen Performance aus. Hierfür brauchst allerdings einen
"gepatchen XEN-Kernel", den zB Linux, BSD und Solaris bieten. In diesem
PV-Modus kann man auch einfach swap nutzen und so den "physikalischen
RAM-Bedarf" senken.
Das sich sowas (RAM-Sparen) nicht wirklich für produktiv-Umgebungen
eignet sollte klar, sein - setzt aber die HW-Hürde für Testsysteme
niedriger, wenn man "mal eben n Testsystem aufsetzen" möchte.
Aber irgendiwe ist das imho auch mist, was ich da sagte. Natürlich kann
man in kvm auch swap nutzen - mein Fehler sorry :)
> und
> OpenVZ in die von VServer.
openvz = vserver, auch wenn die jungs dass nicht gerne hören ;)
> Siehst du das anders?
Nein, nur eben XEN kann im PV-Mode swap anbieten/nutzen, was den
RAM-Bedarf erstmal senkt. Und das können die Lightweight-Solutions (vz,
vserver) nicht.
>
> Gruß, Harald
Grüße,
Thomas
Reply to: