Re: Migration 32 Bit (i386) -> 64 Bit (amd64)
Am Donnerstag, 21. Juli 2011 schrieb Michael Hierweck:
> Hallo allerseits,
Hallo Michael,
> nachdem ich mich lange davor gedrückt habe, muss ich nun eine größere
> Anzahl von Squeeze 32 Bit-Systemen auf 64 Bit up-/cross- oder
> wasauchimmer-graden.
>
> Ich suche eine Migrationsstrategie. Backup-, Neuinstallation und
> Restore möchte ich ungern wählen, da der Restore der Daten,
> selbstkompilierten Programme und Konfigrationsoptionen in das neue
> Systeme wohl sehr fummelig wäre. Ein sehr viel einfacherer
> Komplettrestore hilft mir natürlich wenig.
>
> Folgende Rahmenbedingungen:
>
> * Alle System sind KVM-Guests auf einem KVM-Host.
> * Die Hosts sind bereits 64 Bit-Squeeze (amd64).
> * Die Guests sind 32 Bit-Squeeze (i386) mit 64 Bit-Kernel.
> * Die Guests sind komplexe Systeme mit vielen Benutzern und einigen
> selbstkomplilierten Programmen.
Das sind dann 32-Bit-Programme für die zusätzliche Vorkehrungen nötig
sind, damit sie unter 64-Bit auch noch laufen. Mindestens ia32-libs,
solange kein Debian mit Multiarch-Paketen zum Einsatz kommt. Evtl. sind
noch weitere Bibliotheken in 32-Bit bereit zu halten.
> * Die Downtime der Guests soll kurz gehalten werden (ein paar Stunden
> sind OK).
>
> Die Vision:
>
> * Guest stoppen
> * Filesystem des Guests mounten
> * 64 Bit-Packages darüber installieren, 32 Bit-Kompatibilitätspackages
> dazu installieren
> * Guest starten (alles läuft und fertig)
>
> Wenn man diesem Wiki-Eintrag glauben schenken mag, könnte das sogar
> gelingen: http://wiki.debian.org/Migrate32To64Bit
Es gibt noch ein älteres HOWTO:
Upgrading Debian From i386 To amd64
AKA Upgrading Debian From 32-bit To 64-bit
http://teddyb.org/~rlpowell/hobbies/debian_arch_up/
> Da es sich um KVM-Guests handelt, kann man sich Hantieren mit der Boot
> CD ersparen, weil das Host-System als 64 Bit-Laufzeitumgebung dienen
> kann.
>
> Hat jemand praktische Erfahrung mit solchen Aktionen?
Ich habe mich entschieden, auf meinem neuen Laptop lieber neu zu
installieren.
Ich würde mir an Deiner Stelle folgende ernsthaften Fragen stellen:
1) Ist ein Upgrade wie in einem der beiden HOWTOs beschrieben wirklich
zeitsparender? Evtl. mal mit einem KVM-Gast probieren. Also einmal den
Aktualisierungs- und einmal den Neu-Installationsweg. Für mich sieht es so
aus, als sei das Aktualisierungs-Verfahren *deutlich* zeitaufwendiger als
eine Neu-Installation. Es kommt also ganz darauf an, wie groß die eigenen
Anpassungen am System nach der Installation sind und wie leicht sich diese
auf das neue System übertragen lassen.
2) Ist es mir das Risiko wert, dass danach etwas grandios oder auch nur
völlig subtil und unerklärlich nicht funktioniert? Die Warnung im von mir
angegeben HOWTO sind sehr, sehr deutlich.
3) Habe ich die erforderliche Erfahrung mit Paketverwaltung und allem
anderen, was ich dazu brauche, um so eine Aktion durchzuziehen? Weiß ich,
was zu tun ist, wenn die Shell nicht mehr startet? Weiß ich, statisch
gelinkte Binaries bereit zu halten? Weiß ich mit durchaus heftigen
Problemen beim Aktualisieren einzelner Pakete umzugehen?
4) Und ganz wichtig: Bringt die Umstellung auf 64-Bit überhaupt Vorteile,
die den Aufwand wert sind? Bei unter 8 GB für den KVM-Gast macht eine
Umstellung meines Erachtens überhaupt keinen Sinn, denn ob ich nun knapp 4
GiB oder volle 4 GiB nutzen kann, macht der 64-Bit Overhead wahrscheinlich
schnell wieder wett.
Bei nur einem Nein, würde ich die Idee aufgeben.
Für mein neues Laptop habe ich das ja noch erwogen. Denn ich traue mir zu,
auch mit Untiefen klar zu kommen. Es wär mal ne spaßige Geschichte
gewesen. Allerdings ist Debian Squeeze / Wheezy / Sid mittlerweile direkt
nach der Installation schon so schön rund, dass ich durch die Neu-
Installation automagisch viele Altlasten loswurde.
Aber ich bin niemals auch nur ansatzweise (!) auf die Idee gekommen,
Kunden-Systeme, wo andere mit arbeiten, auf diese Weise zu aktualisieren.
Wenn Du es trotzdem machen möchtest, viel Spaß und berichte mal von Deinen
Erfahrungen. Ich empfehle Dir für den Fall aber, ein System anhand eines
Klons mit andere IP-Adresse erstmal testweise so zu aktualisieren, das
genauere Prozedere zu dokumentieren, dann zwei bis drei weitere Systeme
nach der Dokumentation zu aktualisieren und dabei die Dokumentation zu
verbessern. Diese Systeme würde ich dann erstmal eine Weile im Testbetrieb
laufen lassen, dann im Produktivbetrieb. Und erst wenn klar ist, dass das
so funktioniert, mit den restlichen Systemen anfangen.
Die Dokumentation empfehle ich Dir, um dann am Ende mit etwas Glück
vielleicht wirklich mit ein paar Stunden Downtime hinzukommen. Das
Aktualisierungsverfahren birgt nach meinem Dafürhalten viel Potential für
eine Downtime, die länger als ein Tag ist ;).
Das mit der Dokumentation funktioniert natürlich nur, wenn die Systeme
nicht alle völlig unterschiedlich ist.
Und wenn das nur private Spaß-Systeme sind, mach ein Backup und probiers.
Das was Du beschreibst hört sich aber nach mehr als das an.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: