[gelöst] Neues System zum Test über Xen?

[Rolf-Werner]

Hallo,

die Tage hatte ich eine Idee, aber ich will erstmal die Experten fragen, ob das sinnvoll wäre.

Wenn ich eine neue Version unseres Servers einrichten wollte, hab ich früher immer auch die Hardware gewechselt. Diesmal war das nicht nötig. Deshalb hab ich im Wechsel die Boot-Platte getauscht, was aber sehr umständlich ist. Mit zwei getrennten Maschinen geht es leichter, man kann sich einfach auf dem neuen System anmelden und daran arbeiten, wann immer man Zeit hat, bis es fertig ist, und dann umsteigen.

Jetzt dachte ich, ich könnte Xen dafür benutzen, ein neues System parallel zum alten anzulegen. Wenn das neue System fertig ist, wechsele ich einfach mit allen Usern auf das neue System. Nachdem alles sicher läuft, kann man das alte System platt machen und da dann das nächste anlegen usw. Da es sich um einen LTSP-Server handelt, kann ich ganz einfach zwei Zugänge auch für X11 einrichten (mit zwei getrennten Maschinen hab ich das schon gemacht). Allerdings war bisher vmware und v-box und qemu immer etwas zu umständlich und lahm (wegen der grafischen Screens), um sowas zu simulieren, deshalb dachte ich an Xen.

Liege ich da richtig, oder was würdet ihr machen? Für die zusätzliche Domäne brauche ich doch auch physikalisch getrennten Plattenplatz (also extra Platte), oder?

Danke schon mal für alle Ideen.

Rolf

 

[spoensche]

Wenn ich eine neue Version unseres Servers einrichten wollte, hab ich früher immer auch die Hardware gewechselt. Diesmal war das nicht nötig. Deshalb hab ich im Wechsel die Boot-Platte getauscht, was aber sehr umständlich ist. Mit zwei getrennten Maschinen geht es leichter, man kann sich einfach auf dem neuen System anmelden und daran arbeiten, wann immer man Zeit hat, bis es fertig ist, und dann umsteigen.

Jetzt dachte ich, ich könnte Xen dafür benutzen, ein neues System parallel zum alten anzulegen. Wenn das neue System fertig ist, wechsele ich einfach mit allen Usern auf das neue System. Nachdem alles sicher läuft, kann man das alte System platt machen und da dann das nächste anlegen usw. Da es sich um einen LTSP-Server handelt, kann ich ganz einfach zwei Zugänge auch für X11 einrichten (mit zwei getrennten Maschinen hab ich das schon gemacht). Allerdings war bisher vmware und v-box und qemu immer etwas zu umständlich und lahm (wegen der grafischen Screens), um sowas zu simulieren, deshalb dachte ich an Xen.

KVM + Qemu ist nicht langsam. Also für dein Scenario gibt es mehrere Möglichkeiten.

Eine Möglichkeit wäre z.B, ein zweckentfremdetes LTSP Cluster, https://www.ltsp-cluster.org/home. Statt Aktiv-Aktiv betreibst du es als Aktiv-Passiv und schaltest den Loadbalancer ab. Die Zweckentfremdung besteht darin, dass du bei dem Aktiv-Passiv Cluster den passiven Knoten nicht als Standby verwendest, sondern zum "schrauben". Wenn du fertig bist könntest du dann per Clustermanager schwenken. Ich weiss allerdings nicht, ob LTSP- Cluster dies unterstützt. Müsstest du also testen.

Eine andere Möglichkeit wäre die Verwendung eines Configuration Management bzw. Provisioning/Deployment Systems, wie z.B. Puppet oder Chef. Du kannst dir dann Manifeste (Puppet) bzw. Rezepte und Kochbücher (Chef) erstellen und hast neben der einheitlichen Basis auch die Möglichkeit einen Server für die Entwicklung der Manifeste o. Rezepte zu verwenden, die Konfiguration und die Softwarepakete des Produktivserver mit dem Deploymentsystem zu synchronisieren. Zum einen sparst du dir ständiges manuelles neu installieren und konfigurieren und zum anderen kannst du das damit geschaffene Zeitfenster für andere Dinge nutzen.

PS: Die Userdaten sollten auf einem externen Rechner o. Storage liegen. Wenn du dann den Server wechselst kannst du die Freigaben o.ä. auf dem neuen Server einbinden und weiter gehts,

Die letze Möglichkeit wäre die Verwendung einer virtuellen Desktop Infrastruktur. Wenn ich mich nicht irre ist die Xen VDI Opensource.

Wenn ich mich bei Xen VDI irre, http://www.ulteo.com/home/en/ovdi/openvirtualdesktop ist Open Source.

Liege ich da richtig, oder was würdet ihr machen? Für die zusätzliche Domäne brauche ich doch auch physikalisch getrennten Plattenplatz (also extra Platte), oder?

Du brauchst nicht zwangsläufig getrennten physik. Plattenplatz, Images verschiedener Domains müssten auch im selben Datastore ihr zu Hause haben können.

 

[Rolf-Werner]

KVM + Qemu ist nicht langsam. Also für dein Scenario gibt es mehrere Möglichkeiten.

Merkwürdig, KVM hab ich nie wahrgenommen. Erst deine Antwort hier hat mich darauf gebracht. Bisher hab ich qemu immer allein benutzt, das lief auch recht flott (jedenfalls mit einem WinXP Gast). Mit einem Suse11.4 als Gast hab ich mal experimentiert, da war aber die Grafik-Übersetzung etwas lahm. Kurze Recherche: für das alte Suse10.3, mit dem der momentane Server läuft, bräuchte ich kvm-22, (die Kernelmodule sind schon da) ich finde bloß nirgends eine Download-Möglichkeit dafür. In den Paketquellen ist es nicht dabei.

Eine Möglichkeit wäre z.B, ein zweckentfremdetes LTSP Cluster, https://www.ltsp-cluster.org/home. Statt Aktiv-Aktiv betreibst du es als Aktiv-Passiv und schaltest den Loadbalancer ab. Die Zweckentfremdung besteht darin, dass du bei dem Aktiv-Passiv Cluster den passiven Knoten nicht als Standby verwendest, sondern zum "schrauben". Wenn du fertig bist könntest du dann per Clustermanager schwenken. Ich weiss allerdings nicht, ob LTSP- Cluster dies unterstützt. Müsstest du also testen.

Hört sich interessant an, das werde ich mal untersuchen.

Eine andere Möglichkeit wäre die Verwendung eines Configuration Management bzw. Provisioning/Deployment Systems, wie z.B. Puppet oder Chef. Du kannst dir dann Manifeste (Puppet) bzw. Rezepte und Kochbücher (Chef) erstellen und hast neben der einheitlichen Basis auch die Möglichkeit einen Server für die Entwicklung der Manifeste o. Rezepte zu verwenden, die Konfiguration und die Softwarepakete des Produktivserver mit dem Deploymentsystem zu synchronisieren. Zum einen sparst du dir ständiges manuelles neu installieren und konfigurieren und zum anderen kannst du das damit geschaffene Zeitfenster für andere Dinge nutzen.

Davon hab ich noch überhaupt keine Ahnung, das muss ich erstmal in Ruhe durchsehen. Klingt aber interessant.

PS: Die Userdaten sollten auf einem externen Rechner o. Storage liegen. Wenn du dann den Server wechselst kannst du die Freigaben o.ä. auf dem neuen Server einbinden und weiter gehts,

Ja, sowas schwebte mir auch vor.

Die letze Möglichkeit wäre die Verwendung einer virtuellen Desktop Infrastruktur. Wenn ich mich nicht irre ist die Xen VDI Opensource.

Wenn ich mich bei Xen VDI irre, http://www.ulteo.com/home/en/ovdi/openvirtualdesktop ist Open Source.

Ok, danke auch für diese Tipps.

Du brauchst nicht zwangsläufig getrennten physik. Plattenplatz, Images verschiedener Domains müssten auch im selben Datastore ihr zu Hause haben können.

Ja, stimmt, so wie bei qemu. So eine Lösung hätte auch den Vorteil, dass ich das virtuelle Experimentalsystem beliebig starten und stoppen könnte. Ich fand bloß beim letzten Versuch die Grafik zu langsam, aber das würde ab dem Zeitpunkt, wo ich mich per LTSP darauf einloggen kann, egal.

Rolf

 

[spoensche]

Mit einem Suse11.4 als Gast hab ich mal experimentiert, da war aber die Grafik-Übersetzung etwas lahm.

Wenn du KVM verwendest, dann ersetzte den qemu Befehl durch kvm.

Kurze Recherche: für das alte Suse10.3, mit dem der momentane Server läuft, bräuchte ich kvm-22, (die Kernelmodule sind schon da) ich finde bloß nirgends eine Download-Möglichkeit dafür. In den Paketquellen ist es nicht dabei.

10.3 ist EoL. Deswegen findest du auch keine aktuellen Pakete oder Download Möglichkeiten, also auch keinerlei Sicherheitsupdates. Ich kann dir nur raten schnellstmöglich ein Upgrade durchzuführen.

Eine andere Möglichkeit wäre die Verwendung eines Configuration Management bzw. Provisioning/Deployment Systems, wie z.B. Puppet oder Chef. Du kannst dir dann Manifeste (Puppet) bzw. Rezepte und Kochbücher (Chef) erstellen und hast neben der einheitlichen Basis auch die Möglichkeit einen Server für die Entwicklung der Manifeste o. Rezepte zu verwenden, die Konfiguration und die Softwarepakete des Produktivserver mit dem Deploymentsystem zu synchronisieren. Zum einen sparst du dir ständiges manuelles neu installieren und konfigurieren und zum anderen kannst du das damit geschaffene Zeitfenster für andere Dinge nutzen.

Davon hab ich noch überhaupt keine Ahnung, das muss ich erstmal in Ruhe durchsehen. Klingt aber interessant.

Der Aufbau von Puppet Modulen u. Manifesten ist nicht kompliziert u. man findet sich zügig zurecht.

Ok, danke auch für diese Tipps.

Da nicht für. Viel Spass beim beim "basteln" und testen.