Alter Rootserver: Upgrade, abschalten, ...?

V

Voltampere

New Member
Hallo!

Wir betreiben diverse Rootserver. Unser im Augenblick ältester Server läuft noch mit Ubuntu 8.04 (Asbach-Uralt-Edition) und dient als Mädchen für alles mit einem wahren Dschungel an Virtual Hosts, Mailkonten, etc. (Serverdienste sind die üblichen Verdächtigen: Apache, aktuelles PHP als FCGI-Modul, MySQL, Froxlor als Frontend für Kunden)

Da der Support für Ubuntu 8.04 im April 2013 ausläuft, stellt sich die Frage nach der Zukunft unserer Server-Oma. Wie ich das sehe, gibt es folgende Möglichkeiten für uns:

1. Neuen Server anmieten, Kundenaccounts sukzessive umziehen
2. Ubuntu 8.04 beibehalten, aber alle Serverdienste und den Kernel durch Eigenkompilate mit den jeweils aktuellen Versionen ersetzen
3. Stufenweises Upgrade von Ubuntu 8.04 über 10.04 auf 12.04
4. Gar nichts tun und Server in eine sicherheitstechnische Zeitbombe verwandeln

In der Vergangenheit haben wir aus Sicherheitsgründen immer Methode 1 vorgezogen, vor allem, da die alten Server irgendwann so alt waren, dass sie bereits fast japsend am Boden lagen. Da unsere jetzige Server-Oma aber noch recht rüstig ist, liebäugele ich dieses Mal mit Methode 3. Allerdings habe ich Systemupgrades bisher ausschließlich lokal durchgeführt und eigentlich darf die Downtime auch nicht zu lang dauern, damit die Kunden nicht weinen.

Im Grunde möchte ich nur in die Runde fragen, wie ihr solche Situationen angegangen seid. Welche Methode habt ihr bei Altlast-Produktivservern vorgezogen – und warum?

Freundliche Grüße
Voltampere

(Tschuldigung, wenn der Text etwas zu schwafelig ist. Eine Schwäche von mir ;))
 
Ein Systemupdate auf eine neuere Ubuntu-Version birgt immer das Risiko, daß nach dem Update etwas nicht richtig läuft und korrigiert werden muß. Das kann einfach zu beheben sein, aber auch schon mal ein recht langwieriges Troubleshooting mit sich bringen. Vorteil vom Methode 1 ist halt, daß du den Server in aller Ruhe fertig konfigurieren und testen kannst, bevor du deine Kunden drauf verschiebst.
 
Dist-Upgrades unter Ubuntu sind bei mir bisher immer weitestgehend reibungslos gelaufen.

Ich würde Backups ziehen, mir Gedanken über ein Notfall-Rollback machen und dann das Ganze auf nen Freitag Abend durchziehen.
Wenn wirklich was passiert, kannste immer noch das Backup zurückspielen und dir was anderes Überlegen.
 
Wenn die Hardware zu schwach ist, dann wird migriert. Ansonsten bleibt dir dann nur noch Methode 3. Meine bisherigen Debian/Ubuntu Dist-Upgrade verliefen eigtl. bis auf kleinere Probleme immer reibungslos. Aber wie Jesaja sagt, vorher Backup machen und sich einen Deasaster Rollback Plan ausdenken.

Von Methode 2 halte ich gar nichts, ganz egal wie alt oder neu das System ist.
 
Ich bin und werde immer für Methode 1 sein - dann hat man auch mal wieder ein sauberes System...
 
Hallo,

zunächst: Ohne mehrere Backups (von unterschiedlicher Backupsoftware erstellt und an unterschiedlichen Orten aufbewahrt) oder einen Notfallplan verlasse ich morgens nicht mal das Haus. Die Wahrscheinlichkeit eines totalen oder auch partiellen Datenverlusts schätze ich daher geringer ein. Die größere Sorge ist letztendlich eine zu lange Downtime, entstellte Webauftritte oder ähnliches.

Methode 2 (und 4) streiche ich erst einmal aus meiner Liste.

Ubuntu-Dist-Upgrades funktionierten bei mir in der Vergangenheit auch recht reibungsarm – aber immer nur auf lokalen Maschinen (und ohne historisch gewachsenen Website-Zoo). Wie danton und Dominic Pratt anmerkten, habe ich bei Methode 1 wahrscheinlich ein saubereres System und mehr Zeit zum Konfigurieren und Testen.

Vermutlich werde ich wohl eine zweigleisige Strategie aus Methode 1 und 3 fahren: Websites/Datenbanken ziehen zu anderen aktuelleren Systemen, die Maildienste verbleiben vorerst auf der Server-Oma. Anschließend könnte ich mit einem solchermaßen "reduzierten" System das Dist-Upgrade angehen.

  • Mit einem Backup-MX ließe sich zumindest der Empfang während einer Downtime noch aufrecht erhalten.
  • Der Testaufwand mit nur einem Dienstetyp ist geringer – potenziell niedrigeres Risiko, Stolperfallen beim Testen zu übersehen.
  • Ein "Mädchen-für-alles-Server" weniger. Ist ja auch was wert.

Ob das nun DER Plan schlechthin ist, ist aber noch nicht ganz sicher.

In jedem Fall danke ich aber schon mal, dass ich hier bisher laut nachdenken durfte und einige Denkanstöße dabei einheimsen durfte. ;)

Freundliche Grüße
Voltampere
 
Solang ist die Downtime bei einem dist-upgrade ja auch nicht ;)

Dienste usw. werden ja erst beim replacen neugestartet und je nach Hardware ist ein dist-upgrade schnell durchgeführt.

Natürlich unter der Voraussetzung das alles läuft :D
 
Wenn du das dist-upgrade vorher auf einem Test-System zufriedenstellend durchgespielt hast, wuerde ich das Live Update auch direkt machen. Wenn so etwas bei mir ansteht, werden die Kunden vorher ueber ein Wartungsfenster (i.d.R. Sonntags zwischen 23.00 und 01:00 Uhr) informiert.

Durch Clusterdienste (eventuell fuer die Zukunft denkbar bei dir) habe ich wirklich geringe Ausfallzeiten, aber auch ohne ist das im Rahmen des Vertraeglichen.
 
Methode 1 halte ich für die beste und stressfreiste. Du kannst auf deinem neuen Server ein aktuelles OS installieren und alles in Ruhe einrichten. Nachdem alles bereit ist, ziehst du ein paar Kunden testweise um und testest, ob alles geht. Sofern Domains verwendet werden, die Einträge auf die alte IP belassen (dafür gibt es die hosts-Datei). Sofern die Tests erfolgreich sind, kannst du mit der Planung beginnen und deine Kunden dann informieren.

Ich habe jetzt zwei Umzüge mitgemacht. Bei beiden ist alles schief gelaufen, was schief gehen konnte. Zwischendurch noch paar Server auf andere IPs gelegt und dann im Nachhinein festgestellt, dass auf einer IP noch IPMI von einem Server lief. Ich habe davon die Schnauze sowas von gestrichen voll, dass ich das wirklich nur noch alleine machen werde. Ich hoffe, dass du dich auf deine Leute verlassen kannst. Mach es notfalls alleine!
 
Hallo!

Da es unhöflich von mir wäre, diesen Thread quasi "ungelöst" einschlafen zu lassen, gebe ich noch kurz Rückmeldung, was die Planung nun ergeben hat. Nach diversen Über-den-Daumen-Risko-Abschätzungen ist der festgesetzte Masterplan nun:

1. Es werden nun nur die wirklich stark besuchten Kundenwebsites zu anderen Servern migriert. Das sind insgesamt nur eine Handvoll.
2. Alle anderen Web-Kunden und auch die Maildienste verbleiben auf der rüstigen Server-Oma.
3. Der Server wird nach ausgiebiger Testphase per schrittweisem Dist-Upgrade in voraussichtlich zwei Wochenendnächten softwaremäßig auf einen aktuellen Stand (Ubuntu 12.04 LTS) gebracht.

Sofern kein verspäteter Weltuntergang stattfindet, wird von diesem Plan auch nicht mehr abgewichen. Für unseren Fall sollte er nun einen guten Kompromiss darstellen.

Danke für die zahlreichen Antworten und angenehme Feiertage alle zusammen!

Freundliche Grüße
Voltampere
 
You must log in or register to reply here.
Back
Top