Schön, dass Linux auch im Jahr 2009 noch keine richtige, leichtgewichtige Userlandvirtualisierung kann. Außer man frickelt sich irgendwelche seltsamen, fischigen Patches in der Kernel. Stattdessen setzt man auf fette Hypervisoren, die man eigentlich nur in fehlgeplanten Netzen bräuchte. Aber was solls, es freut Intel da die mehr fette CPUs absetzen können, es freut die Stromkonzerne, da die CPUs durch 80% Overhead richtig schön ackern müssen... Und anstatt das man das gute, saubere Xen nimmt, muss man sich natürlich wieder eine eigene, zum Rest der Welt inkompatible Lösung zusammenfummeln. Und wie wir die Fanboys kennen, wird dieser fehlentwickelte Schrott hier gleich wieder in den Himmel gelobt und als innovativ bezeichnet.
Naja, RedHat ist nicht gleich Linux. Die "Enterprise"-Distributionen haben generell das Problem, sich nicht verzetteln zu dürfen, und unterstützen daher meist nur eine Technik. Bei RedHat ist das KVM, bei Novell Xen.
Mit Debian GNU/Linux hast du dagegen die Wahl zwischen den zwei Container-basierten Lösungen Linux-VServer und OpenVZ. Daneben gibt es drei verschiedene Maschinenvirtualisierungen: Xen, KVM und VirtualBox. Und nicht zu vergessen die klassischen Emulatoren Qemu und Bochs. Was will man mehr?
Von PenguinFrickler am Do, 18. Juni 2009 um 12:03 #
> Bei RedHat ist das KVM, bei Novell Xen. *plonk* ... wenn man keine Ahnung hat ... RedHat macht XEN und ab RHEL5.4 XEN und KVM ... XEN ist mit RHEL von daher bis mind 2012 noch supported ....
> *plonk* ... wenn man keine Ahnung hat ... RedHat macht XEN und ab RHEL5.4 XEN und KVM ... XEN ist mit RHEL von daher bis mind 2012 noch > supported ....
Ja und dann? Dann mal wieder 30.000 Server reinstallieren, 2015 dann wieder auf die dann tolle Lösung. *ROFL* Sowas ist einfach lächerlich und alles andere als professionell.
Den Artikel hast du aber nicht gelesen oder? Red Hat arbeitet an Migrastionslösungen. Die gibt es bei anderen Virtualisierungsanbietern auch. Da muss kein Server nu aufgesetzt werden, die VMs werden einfach umgezogen. Sowas geht auch live ohne jede Downtime.
Lustig. Was ist denn bei Deinen 30.000 Servern so der mittlere Hardwarelebenszyklus?
RHEL 5 mit Xen wurde Anfang 2007 released. Bei 7 Jahren regulaerem life cycle (http://www.redhat.com/security/updates/errata/) ist es also bis 2014 supported. Neue Hardwareunterstuetzung wird bis mindestens 2011 hinzugefuegt (kleinere Erweiterungen auch noch etwas laenger). Es gibt eine optionale Erweiterung bis 2017 (zumindest in Japan http://www.redhat.com/promo/mc_program/). Das gibt Dir bei vernuenftiger Planung Deiner Deployments selbst wenn Du erst in kommenden Jahr installierst noch satte 7 Jahre Laufzeit.
Nu ist der Sinn von Virtualisierung natuerlich gerade die Workloads von der Hardware unabhaengig zu machen. Daher wuerdest Du, wenn Du es richtig angehst, den Host schlank halten. Damit waere aber eine automatisierte migration auf eine neuere Release kein Problem. Fuer Gastsysteme ist das eh automatisiert.
vergiss mal User-Mode-Linux (UML) nicht. Das benutze ich seit bald fünf Jahren (Kernel 2.4), um virtuelle Maschinen zu betreiben und das geht schon immer ohne Hardware-virt und heutzutage auch ohne irgendwelche kernel-patches. Sind einfach Prozesse, die man mit nice und kill und ps verwalten kann.
Von PenguinFrickler am Do, 18. Juni 2009 um 12:10 #
> Und anstatt das man das gute, saubere Xen nimmt, was von Citrix verschlimmbessert wurde, was technologisch KVM hinterherhinkt, was auf aktuelle Kernel reihen nur mit immensen Backportingaufwand übertragbar ist, für das mal ein komplettes Linux als Wirt mitschleppen muss usw usw usw ...
Ich bin mir nicht sicher ob Dir der unterschied zwischen KVM und XEN schon bekannt ist ...
> muss man sich natürlich wieder eine eigene, zum Rest der Welt inkompatible Lösung zusammenfummeln. Hier kann ich Dir garnicht mehr folgen, ausser Citrix XEN setzen alle auf "libvirt" als Management lösung auf, nix anderes wird hier gemacht. Ansonsten könnten sie auch nicht soft von XEN nach KVM migrieren. Spätestens wenn es freigegeben wird wie alle RHEL Produkte werden die anderen es auch nutzen ... soviel zum thema Rest der welt ... und inkompatibel (wozu eigentlich es gibt ja nix vergleichbares derzeit)
> Stattdessen setzt man auf fette Hypervisoren, die man eigentlich > nur in fehlgeplanten Netzen bräuchte.
Schön dass du gleich zu Beginn zeigst dass du vom echten Leben keine Ahnung hast Als fehlgeplant würde ich aktuell eher eine Infrastruktur bezeichnen wo man im Serverbereich auf die Wahnwitzige Idee kommt eine Maschine noch physisch aufzusetzen.
Aber mach du nur, bei der nächsten Servergeneration wird dir nicht langweilig, wir drücken einfach auf ein paar Knöpfe und die Sache ist erledigt - Es gibt nämlich spannendere Dinge als bei jedem Hardwarewechsel immer wieder die gleichen Routinearbeiten zu machen.
> Stattdessen setzt man auf fette Hypervisoren, die man eigentlich > nur in fehlgeplanten Netzen bräuchte.
> Schön dass du gleich zu Beginn zeigst dass du vom echten Leben keine Ahnung hast > Als fehlgeplant würde ich aktuell eher eine Infrastruktur bezeichnen wo man im Serverbereich auf die Wahnwitzige Idee kommt eine Maschine > noch physisch aufzusetzen.
Dafür nutzt man Virtualisierung auf Betriebssystemebene mit praktisch null Overhead und keine grottenlahmen, fetten Hypervisoren. Die sind außerdem einfacher zu handhaben und überhaupt. Leider kann Linux sowas wie die genialen Zones ja nicht, nur per Gefrickel. Daher muss man ein Problem was nicht existiert gleich mal wieder mit dem Panzer überrollen. Aber wir habens ja.
> Dafür nutzt man Virtualisierung auf Betriebssystemebene mit praktisch null > Overhead und keine grottenlahmen, fetten Hypervisoren.
Ich beziehe mich nach wie vor NICHT auf den Artikel sondern auf deine blödsinnige Aussage von wegen "Fehlgeplante Netze":
Wenn man sowas ERNSTHAFT macht nutzt man überhaupt nichts mit einem Hostsystem drunter sondern einen Bare-Metal-Virtualisierer (Stichwort: VMware ESX/ESXi).
Warum? Weil die Performance auf aktuellen Servern speziell mit ESXi4 (64 Bit) kaum einen messbaren Unterschied zu einer nativ laufenden Maschine macht und in vielen Fällen sogar besser ist trotz Virtualisierungsoverhead.
Der wirkliche Grund ist die Administration! Schon mal VMotion/Storage-VMotion live gesehen? Offenbar nicht sonst würdest du nicht soviel Blödsinn erzählen
Damit auch du es verstehst: Ich betreibe 12 VMs auf einem dicken ESXi und kann die Ressourcen frei zuweisen, im Endeffekt kriegt jede VM genausoviel RAM wie sie sinnvoll nutzen kann anstatt einen überdimensionierten Rechner da stehen zu haben der halt auf Teufel komm raus cacht.
Die Kiste selbst ist aber so fett dass ich jederzeit 10 GB freien Speicher rumliegen habe und sich der Hypervisor zu 90% um die Zuteilung kümmert. In seltenen Fällen passt man den Gastarbeitsspeicher halt auch noch an neben der Ressourcenzuteilung.
Wo jetzt der Vorteil ist? Stelle ich mir ZWÖLF physische Kisten hin muss ich die alle überdimensionieren um nicht nach kurzer Zeit vor einem Problem zu stehen. Diese idiotsiche Rechnerei kannst du dir sparen -> ZWEI RICHTIG fette statt 12 fetten Maschinen fürs Failover und der Rest bechränkt sich auf das Monitoring und bei Bedarf nachregeln der Ressourcen. Installieren und kopnfigurieren musst du das Teil nie wieder und wenn du mal eine 1:1 Testumgebung brauchst klonst du die komplette VM und ziehst sie mit einer anderen Netzwerkadresse parallel hoch.
In dem Kontext ist für mich jeder der Virtualisierung mit einem fehlgeplanten Netz gleichsetzt schlicht und ergreifend ein Schwachkopf
> Stattdessen setzt man auf fette Hypervisoren, > die man eigentlich nur in fehlgeplanten Netzen bräuchte.
Hat er sehr wohl gesagt und wurde verdammt nochmal von mir auch schon zitiert
> Das hat der Threadstarter aber nicht getan, sondern gesagt > Containerbasierte Virtualisierung sei besser.
Was genauso ein Schwachsinn ist weil du in vielen Szenarien Zones und ähnlichen Krempel schlichtweg in die Tonne treten kannst. Oder wie willst du das einfachmal schnell auf einer Entwicklermaschine hochziehen?
Gar nicht, du machst dich erst wieder von einem Hostsystem abhängig und verspielst damit den größten Vorteil von Virtualisierung. Und wozu das ganze? Für sinnbefreite 2% Performance? Schwachsinn hoch drei!
Xen ist fast so schnell, als würde man auf der physischen Maschine arbeiten, das belegen div. Benchmarks. Wo sind da also die grottenlahmen Hypervisor?
"CPUs durch 80% Overhead": wo holst du diese Zahl her? Bei mit läuft kvm sehr performant. Man kann kvm auch direkt von der Kommandozeile aufrufen (ohne Mangamenentschicht). Was ist daran fett?
"Außer man frickelt sich irgendwelche seltsamen, fischigen Patches in der Kernel.": Dann nimmst du die falsche Distribution. In Ubuntu, Fedora und RedHat ist kvm jedenfalls sehr gut integriert.
> "Außer man frickelt sich irgendwelche seltsamen, fischigen Patches in der Kernel.": Dann nimmst du die falsche Distribution. In Ubuntu, > Fedora und RedHat ist kvm jedenfalls sehr gut integriert.
Es ging bei der Aussage nicht im KVM. Die ist ja leider im Kernel. Es ging darum, dass Linux bis heute keine OS-Level Virtualisierung wie Zones direkt aus dem Standardkernel. Da muss man umfrickeln. Patchen. Rekompilieren. Das Ding NOCH instabiler machen, falls überhaupt möglich. Lern lesen, Junge!
Einfach mal abwarten... noch ist es massiv in der Entwicklung.
Directory Server und RHN Satellite wurden auch freigegeben. Die erworbenen Produkte muss man auch erst einmal in den eigenen Entwicklungsprozess integrieren bevor man richtig loslegen kann.
Von PenguinFrickler am Do, 18. Juni 2009 um 12:05 #
> Ich hoffe RH bleibt auch hier FOSS treu. Wird aber wohl etwas härter .. hatte ich mir auch schon gedacht. Darauf kannst Du Dich verlassen, für die neuen Virtualisierungsprodukte müßen sie aber erst noch einige unschöne sachen aufräumen, bevor sie es frei geben können.
Ich schätze mal Q1/2010 sind sie langsam so weit ...
Mit Debian GNU/Linux hast du dagegen die Wahl zwischen den zwei Container-basierten Lösungen Linux-VServer und OpenVZ. Daneben gibt es drei verschiedene Maschinenvirtualisierungen: Xen, KVM und VirtualBox. Und nicht zu vergessen die klassischen Emulatoren Qemu und Bochs. Was will man mehr?
*plonk* ... wenn man keine Ahnung hat ... RedHat macht XEN und ab RHEL5.4 XEN und KVM ... XEN ist mit RHEL von daher bis mind 2012 noch supported ....
> *plonk* ... wenn man keine Ahnung hat ... RedHat macht XEN und ab RHEL5.4 XEN und KVM ... XEN ist mit RHEL von daher bis mind 2012 noch
> supported ....
Ja und dann? Dann mal wieder 30.000 Server reinstallieren, 2015 dann wieder auf die dann tolle Lösung. *ROFL* Sowas ist einfach lächerlich und alles andere als professionell.
RHEL 5 mit Xen wurde Anfang 2007 released. Bei 7 Jahren regulaerem life cycle (http://www.redhat.com/security/updates/errata/) ist es also bis 2014 supported. Neue Hardwareunterstuetzung wird bis mindestens 2011 hinzugefuegt (kleinere Erweiterungen auch noch etwas laenger). Es gibt eine optionale Erweiterung bis 2017 (zumindest in Japan http://www.redhat.com/promo/mc_program/). Das gibt Dir bei vernuenftiger Planung Deiner Deployments selbst wenn Du erst in kommenden Jahr installierst noch satte 7 Jahre Laufzeit.
Nu ist der Sinn von Virtualisierung natuerlich gerade die Workloads von der Hardware unabhaengig zu machen. Daher wuerdest Du, wenn Du es richtig angehst, den Host schlank halten. Damit waere aber eine automatisierte migration auf eine neuere Release kein Problem. Fuer Gastsysteme ist das eh automatisiert.
Ciao
Bernhard M.
was von Citrix verschlimmbessert wurde, was technologisch KVM hinterherhinkt, was auf aktuelle Kernel reihen nur mit immensen Backportingaufwand übertragbar ist, für das mal ein komplettes Linux als Wirt mitschleppen muss usw usw usw ...
Ich bin mir nicht sicher ob Dir der unterschied zwischen KVM und XEN schon bekannt ist ...
> muss man sich natürlich wieder eine eigene, zum Rest der Welt inkompatible Lösung zusammenfummeln.
Hier kann ich Dir garnicht mehr folgen, ausser Citrix XEN setzen alle auf "libvirt" als Management lösung auf, nix anderes wird hier gemacht. Ansonsten könnten sie auch nicht soft von XEN nach KVM migrieren. Spätestens wenn es freigegeben wird wie alle RHEL Produkte werden die anderen es auch nutzen ... soviel zum thema Rest der welt ... und inkompatibel (wozu eigentlich es gibt ja nix vergleichbares derzeit)
> nur in fehlgeplanten Netzen bräuchte.
Schön dass du gleich zu Beginn zeigst dass du vom echten Leben keine Ahnung hast
Als fehlgeplant würde ich aktuell eher eine Infrastruktur bezeichnen wo man im Serverbereich auf die Wahnwitzige Idee kommt eine Maschine noch physisch aufzusetzen.
Aber mach du nur, bei der nächsten Servergeneration wird dir nicht langweilig, wir drücken einfach auf ein paar Knöpfe und die Sache ist erledigt - Es gibt nämlich spannendere Dinge als bei jedem Hardwarewechsel immer wieder die gleichen Routinearbeiten zu machen.
> nur in fehlgeplanten Netzen bräuchte.
> Schön dass du gleich zu Beginn zeigst dass du vom echten Leben keine Ahnung hast
> Als fehlgeplant würde ich aktuell eher eine Infrastruktur bezeichnen wo man im Serverbereich auf die Wahnwitzige Idee kommt eine Maschine > noch physisch aufzusetzen.
Dafür nutzt man Virtualisierung auf Betriebssystemebene mit praktisch null Overhead und keine grottenlahmen, fetten Hypervisoren. Die sind außerdem einfacher zu handhaben und überhaupt. Leider kann Linux sowas wie die genialen Zones ja nicht, nur per Gefrickel. Daher muss man ein Problem was nicht existiert gleich mal wieder mit dem Panzer überrollen. Aber wir habens ja.
> Overhead und keine grottenlahmen, fetten Hypervisoren.
Ich beziehe mich nach wie vor NICHT auf den Artikel sondern auf deine blödsinnige Aussage von wegen "Fehlgeplante Netze":
Wenn man sowas ERNSTHAFT macht nutzt man überhaupt nichts mit einem Hostsystem drunter sondern einen Bare-Metal-Virtualisierer (Stichwort: VMware ESX/ESXi).
Warum?
Weil die Performance auf aktuellen Servern speziell mit ESXi4 (64 Bit) kaum einen messbaren Unterschied zu einer nativ laufenden Maschine macht und in vielen Fällen sogar besser ist trotz Virtualisierungsoverhead.
Der wirkliche Grund ist die Administration!
Schon mal VMotion/Storage-VMotion live gesehen?
Offenbar nicht sonst würdest du nicht soviel Blödsinn erzählen
Damit auch du es verstehst:
Ich betreibe 12 VMs auf einem dicken ESXi und kann die Ressourcen frei zuweisen, im Endeffekt kriegt jede VM genausoviel RAM wie sie sinnvoll nutzen kann anstatt einen überdimensionierten Rechner da stehen zu haben der halt auf Teufel komm raus cacht.
Die Kiste selbst ist aber so fett dass ich jederzeit 10 GB freien Speicher rumliegen habe und sich der Hypervisor zu 90% um die Zuteilung kümmert. In seltenen Fällen passt man den Gastarbeitsspeicher halt auch noch an neben der Ressourcenzuteilung.
Wo jetzt der Vorteil ist?
Stelle ich mir ZWÖLF physische Kisten hin muss ich die alle überdimensionieren um nicht nach kurzer Zeit vor einem Problem zu stehen. Diese idiotsiche Rechnerei kannst du dir sparen -> ZWEI RICHTIG fette statt 12 fetten Maschinen fürs Failover und der Rest bechränkt sich auf das Monitoring und bei Bedarf nachregeln der Ressourcen. Installieren und kopnfigurieren musst du das Teil nie wieder und wenn du mal eine 1:1 Testumgebung brauchst klonst du die komplette VM und ziehst sie mit einer anderen Netzwerkadresse parallel hoch.
In dem Kontext ist für mich jeder der Virtualisierung mit einem fehlgeplanten Netz gleichsetzt schlicht und ergreifend ein Schwachkopf
Das hat der Threadstarter aber nicht getan, sondern gesagt Containerbasierte Virtualisierung sei besser.
> Stattdessen setzt man auf fette Hypervisoren,
> die man eigentlich nur in fehlgeplanten Netzen bräuchte.
Hat er sehr wohl gesagt und wurde verdammt nochmal von mir auch schon zitiert
> Das hat der Threadstarter aber nicht getan, sondern gesagt
> Containerbasierte Virtualisierung sei besser.
Was genauso ein Schwachsinn ist weil du in vielen Szenarien Zones und ähnlichen Krempel schlichtweg in die Tonne treten kannst. Oder wie willst du das einfachmal schnell auf einer Entwicklermaschine hochziehen?
Gar nicht, du machst dich erst wieder von einem Hostsystem abhängig und verspielst damit den größten Vorteil von Virtualisierung. Und wozu das ganze? Für sinnbefreite 2% Performance? Schwachsinn hoch drei!
"Außer man frickelt sich irgendwelche seltsamen, fischigen Patches in der Kernel.": Dann nimmst du die falsche Distribution. In Ubuntu, Fedora und RedHat ist kvm jedenfalls sehr gut integriert.
> Fedora und RedHat ist kvm jedenfalls sehr gut integriert.
Es ging bei der Aussage nicht im KVM. Die ist ja leider im Kernel. Es ging darum, dass Linux bis heute keine OS-Level Virtualisierung wie Zones direkt aus dem Standardkernel. Da muss man umfrickeln. Patchen. Rekompilieren. Das Ding NOCH instabiler machen, falls überhaupt möglich. Lern lesen, Junge!
lguest, UML
Und was machst du wenn du einen anderen Kernel oder gar ein anders OS virtualisieren möchtst? Da hilft dir Zones und Jails auch nicht weiter.
In diesem Sinne: [--]
Directory Server und RHN Satellite wurden auch freigegeben. Die erworbenen Produkte muss man auch erst einmal in den eigenen Entwicklungsprozess integrieren bevor man richtig loslegen kann.
was red hat da von quramnet an management software eingekauft hat laeuft noch auf windows und .net.
Darauf kannst Du Dich verlassen, für die neuen Virtualisierungsprodukte müßen sie aber erst noch einige unschöne sachen aufräumen, bevor sie es frei geben können.
Ich schätze mal Q1/2010 sind sie langsam so weit ...