ubuntuusers.de

Wien, 2017-01-14, 14:36 CET¶

Um erstmal einen Eindruck zu bekommen, wie sich das Update über 2 Versionen verhält, wurde zunächst der Standort Wien aktualisiert. Hier liegen für den Betrieb von Ubuntu-EU unkritische Systeme und bieten somit eine gute Testumgebung.

Wie sich herausstellte, war das auch keine schlechte Idee, denn die ersten Probleme ließen nicht lange auf sich warten. Da auf den Servern keine udev-Regel vorhandenen war, wurde das Netzwerk Interface beim Upgrade auf Xenial still und heimlich von eth0 in ens192 umbenannt. Somit war der Zugriff von außen nicht mehr möglich, da unsere iptables Regeln weiter mit dem alten Namen arbeiteten.

Nachträglich nochmal ein großes Dankeschön an unseren Hoster Anexia in Wien, der uns an einem Samstag mit sehr kurzen Reaktionszeiten positiv überrascht hatte. Nachdem der Fehler lokalisiert und behoben wurde, lief das Upgrade bei den folgenden Services ohne weitere Schwierigkeiten durch.

Der Abschluss der Arbeiten in Wien erfolgte am gleichen Tag um ca. 18 Uhr.

Köln, 2017-01-22, 13:37 CET¶

Als nächstes stand Köln auf der TODO-Liste des Serverteams. Hier sind vor allem die Dienste für unsere Partner-Communities und die vom Verein gehosteten Seiten zu finden.

Die Aktualisierungen gingen hier auch wesentlich unspektakulärer von statten, da die Server kaum von der Standardinstallation abwichen. Kleinere Anpassungen wie zum Beispiel bei den Virtualhosts der Apachen oder den VMs der KVM-Hosts waren schnell erledigt. Auch die Dienste unserer Partner-Communities hatten kaum größere Probleme. Dennoch blieb das Serverteam bei einzelnen VMs auf 14.04, da noch nötige Anpassungen wegen PHP7 erfolgen müssen.

Als letztes war dann unser Datenbank- und Storage-Server für NFS dran. Und es kam, wie es kommen musste. Murphy hatte mit srv10 etwas besonderes geplant. Das Upgrade lief normal an, PostgreSQL sollte aktualisiert werden und – nunja – der restliche Tag wurde dann mit einem Restore von srv10 und etlichen Flüchen gen Himmel bestritten. Hintergrund war hier, dass neuere PostgreSQL-Versionen – genau wie bei MySQL – bestimmte Settings aus früheren Versionen nicht mehr unterstützen. Deshalb wurde beim Neustart des Dienstes, welches das post-installation Script durchführte, das komplette dist-upgrade abgebrochen. Da zu diesem Zeitpunkt bereits für das System kritische Libraries aktualisiert waren, haben wir auf ein aufwändiges Fixen verzichtet und den Server direkt mit Ubuntu Xenial neu installiert. Das Neueinrichten des Servers konnte durch unsere Automatisierung per ansible 🇬🇧 deutlich beschleunigt werden, die fehlerhaften Einstellungen für PostgreSQL und MySQL wurden so auch identifiziert und korrigiert.

Durch die Neuinstallation von srv10 waren die Arbeiten erst am späten Abend von 2017-01-24 gegen 21 Uhr abgeschlossen. Insgesamt verteilten sich die Arbeiten über 3 Tage. Zu beachten ist, dass Köln die meisten Systeme hostet.

Nürnberg, 2017-02-22, 10:00 CET¶

Zum Abschluss wurde der Standort Nürnberg aktualisiert. Angefangen wurde hier bei den redundanten Systemen, so dass direkte Auswirkungen für unsere Anwender ersteinmal ausblieben. Nachdem die sekundären Systeme wie zum Beispiel der MySQL-Slave, unser sekundärer Loadbalancer oder der zweite Application Server aktualisiert waren, gab es auch eine längere Downtime für die primären Systeme.

Während dieser Downtime wurde der MySQL-Master, der primäre Loadbalancer und das Storage ebenso aktualisiert wie der letzte noch verbliebene Application Server. Das Update verlief hier deutlich angenehmer, da wir durch die anderen Standorte und die zuvor aktualisierten Backup/Zweitsysteme ausreichend Erfahrung mit identischer Hardware und Services sammeln konnten. Am längsten hat der Restore unserer MySQL Datenbank sowie die Neueinrichtung der Replikation gedauert. Das vollständige Konfigurieren einer neuen MySQL-Instanz dauert übrigens nur noch ca. 1 Minute und 30 Sekunden, was an unserer weit voran getriebene Automatisierung liegt. Der Restore der entsprechenden Datenbanken kann aber durchaus 45 Minuten oder länger dauern.

Wie in einem Ikhaya Artikel bereits erwähnt, haben wir die Upgrades dieser Systeme an zwei aufeinander folgenden Tagen durchgeführt.

systemd¶

Seit Ubuntu 16.04 hat auch systemd in die Ubuntuwelt Einzug gehalten. Wir haben bei der Migration auch direkt das früher verwendete supervisord 🇬🇧 durch neu geschriebene systemd Units ersetzt. Gleichzeitig war es erforderlich, vorhandene Unit Files anzupassen, so dass Dienste zwangsweise in der für uns richtigen Reihenfolge gestartet werden.

Apache¶

Bei Apache wurden unsere Server durch das Upgrade von precise nach trusty von Apache 2.2 auf Apache 2.4 aktualisiert. Hierdurch waren einige Anpassungen an der Syntax unserer virtual Hosts erforderlich.

Gleichzeitig sind wir über einen Bug in dem zuvor verwendeten libapache2-mod-itk 🇬🇧 gestolpert. Denn dieser wollte partout nicht mehr mit unserem über NFS verteilten Document Root arbeiten. Als Kompensation läuft Apache nun vollständig als User der entsprechenden Community. Das wurde erst durch die zuvor eingeführte Virtualisierung und Trennung der Communities auf verschiedene Hosts ermöglicht.

Wer mehr zur Infrastruktur von ubuntuusers.de und den Communities von Ubuntu-EU lesen möchte, sei auf einen etwas älteren Ikhaya-Artikel hingewiesen.

Python / node.js¶

Sobald Python oder node.js Anwendungen im Einsatz sind, sollten hiervon die entsprechenden Cache-Verzeichnisse gelöscht werden. Nur so ist sichergestellt, dass die Abhängigkeiten dieser Anwendungen auch stets gegen die neuen Versionen ihrer Bibliotheken gelinkt sind.

libvirt¶

Bei libvirt war in der früheren Version innerhalb der Host Definitionen der Typ virtueller Maschinen anders. Hier war ein händischer Eingriff erforderlich, um den Typ auf einen in den neueren Versionen vorhanden wie pc-i440fx-xenial zu ändern. Erst danach konnten die virtuellen Maschinen wieder gestartet werden.

MySQL / PostgreSQL¶

Wie zuvor erwähnt, ist zu beachten, ob die verwendeten Datenbankeinstellungen mit der jeweils neuen Version der Datenbankserver noch kompatibel sind. Im Zweifel kann es von Vorteil sein, vor dem Upgrade ein ohnehin sinnvolles Backup zu erstellen und die Datenbankserver zu deinstallieren. Bei PostgreSQL ist dies ohnehin der empfohlene Weg; für MySQL kann es zumindest nicht schaden. 😉

Als Besonderheit bei MySQL sei noch erwähnt, dass ein frisch formatiertes ext4-Dateisystem auf einer eigenen Partition für /var/lib/mysql einen lost+found Ordner enthält. Dieser sorgt zuverlässig zum Abbruch der MySQL Installation, da das Skript zur Initialisierung der Datenbanken nicht durchläuft. Es ist ratsam, bei einem vergleichbaren Setup diesen zuvor zu löschen und nach der Installation wieder anzulegen. Als Alternative kann natürlich auch XFS oder ein anderes geeignetes Dateisystem verwendet werden. Wir haben uns aber für ext entschieden, da dies zum einen sehr robust ist. Zum anderen kann es auch offline wieder verkleinert werden.