© ufabizphoto / 123RF.com

Fernab von Containern und IaaS müssen sich viele Admins nach wie vor um grundlegende Dienste wie Mailserver kümmern. Das wird insbesondere dann zur Herausforderung, wenn ein Update den Tausch der Hardware oder die Umstellung auf andere Software umfasst.

Neben Backups und Hochverfügbarkeit gehört auch der Betrieb klassischer IT-Dienste wie Name- und Mailserver zum Brot-und-Butter-Geschäft der IT-Dienstleister. In Ekstase geraten die meisten Admins angesichts dieser Aufgabe zwar nicht, doch ringt ein gut gepflegter und sinnvoll konfigurierter Mailserver den meisten zumindest Respekt ab. Wer diese Aufgabe selbst schon einmal gemeistert hat, weiß schließlich, wie komplex das sein kann und wie viel Arbeit darin steckt.

Aktualisierungen sind da keine Ausnahme: Eine gut geölte Mail-Maschinerie kommt allzu leicht ins Stocken, wenn ein eigentlich unspektakuläres Update schiefläuft und der Empfang und Versand von E-Mails ausfallen. Das Tückische dabei: Kein Arbeitsschritt im Zusammenhang mit dem Upgrade eines Mailservers fällt in die Kategorie Raketenwissenschaft. Weil es aber auf viele Details zu achten gilt, werden einzelne Aspekte oft übersehen. Im weiteren Verlauf sorgen dann gerade solche Kleinigkeiten für erhebliche Probleme.

Mit der richtigen Strategie fällt es jedoch leicht, beim Aktualisieren von Mailservern einen kühlen Kopf zu bewahren und planvoll vorzugehen. Worauf Sie achten müssen und wie ein Update-Konzept aussehen kann, verrät dieser Beitrag. Als Gegenstand der Betrachtung dient dabei ein Mail-Setup auf Grundlage von Ubuntu 20.04, das bisher treue Dienste geleistet hat. Vor dem Hintergrund des auslaufenden Supports für Ubuntu 20.04 soll es nun aber auf Ubuntu 24.04 umgestellt werden (Abbildung 1).

Abbildung 1: Ubuntu 20.04 erreicht das Ende seiner regulären Lebenszeit. Die Nutzer müssen sich mit dem Gedanken an ein Update auf Ubuntu 22.04 oder 24.04 anfreunden, wenn sie weiterhin eine Distribution mit Support nutzen wollen. Bei Mailserver-Setups kann das eine Herausforderung darstellen.

Der einfachste Fall

Gerade beim Betrieb zentraler Infrastruktur wie eben Mailservern ist gute Vorbereitung mehr als die halbe Miete. Im Klartext heißt das: Wer einen aktuellen Server betreibt und für die Konfiguration idealerweise einen Automatisierer wie Ansible nutzt, der hat wenig zu befürchten. Im Falle eines Falles spränge der Automatisierer in die Bresche und würde es ermöglichen, zumindest die Konfiguration des Mailservers von Grund auf wiederherzustellen, inklusive der (hoffentlich als Backup vorhandenen) E-Mails. Selbst dieser doppelte Boden dürfte allerdings im einfachsten denkbaren Szenario nicht nötig sein.

Gerade bei Mailservern ist im Protokoll nämlich eine Art Sicherheitsmodus eingebaut, der die Zustellung von Nachrichten auch dann gewährleisten soll, wenn der Server offline ist: Pro Domäne lassen sich nach Priorität geordnet viele Server festlegen, die als Endpunkt dienen können. Die meisten Mail-Hoster geben für ihre gehosteten Domains zwei bis drei MX-Einträge im DNS an. Zustellende Mailserver arbeiten sie der Reihe nach ab: Lässt sich der Server mit der höchsten Priorität nicht erreichen, versucht der Absender es automatisch bei der Instanz mit der nächst niedrigeren Priorität und so weiter.

Obendrein sehen die einschlägigen Mail-RFCs vor, dass zustellende Server bei vorübergehender Nichterreichbarkeit des Zielservers mehrere Zustellversuche unternehmen. Es müssten also schon einige ungünstige Faktoren zusammenkommen, damit Mails im Transit tatsächlich verloren gehen. Selbst dann erhält der Absender im Regelfall eine entsprechende Benachrichtigung, sodass er den Versand wiederholen kann.

Für das denkbar einfachste Setup im Test bedeutet das, dass das Upgrade eines Mailservers ganz banal auf das Ausführen von »do-release-upgrade« hinauslaufen kann, um das System von Ubuntu 20.04 auf Ubuntu 24.04 zu heben. Weil die meisten Ansible-Module aus der Community für die Nutzung mit verschiedenen Zielversionen der jeweiligen Distribution ausgelegt sind, genügt es im Anschluss normalerweise, den Automatisierer noch einen Lauf ausführen zu lassen und so das System an die neuen Begebenheiten anzupassen. Danach sollten das Zustellen von E-Mails und auch der Abruf per IMAP wieder wie gehabt funktionieren.

Theoretisch könnte dieser Artikel damit bereits zu Ende sein. Ganz so trivial ist es in der Realität dann aber eben doch nicht: Für viele Unternehmen ist es undenkbar, dass auch nur eine halbe Stunde lang – also während der Zeit, die das Upgrade des Servers in Anspruch nimmt – keine Nachrichten ein- oder ausgehen. Daher bedürfen Mailserver-Setups im Hinblick auf Updates vor allem der gewissenhaften Vorbereitung. Hier gilt es, gleich mehrere Faktoren zu beachten.

HA, Redundanz, Skalierbarkeit

Moment mal, mag mancher denken – mit mehreren MX-Einträgen lassen sich ja komplementär zwei Mailserver betreiben, sodass einer einspringt, während der andere nicht verfügbar ist. Grundsätzlich stimmt das.

Allerdings funktioniert der Fallback im SMTP-Protokoll über mehrere MX-Einträge nur für eingehende E-Mails. Der Versand von Nachrichten wäre weiterhin unmöglich. Damit Clients Mails versenden könnten, müssten sie den anderen Server ebenfalls für den Versand nutzen und entsprechend ihre Konfiguration verändern. Das funktioniert jedoch schon für eingehende Nachrichten nicht so richtig gut.

Betriebe ein Unternehmen zwei separate Mailserver, mit der zweiten Instanz als Fallback für den ersten, hieße das für das Gros der Personen im Unternehmen noch immer, dass sie eine Weile keine E-Mails versenden oder empfangen können – es sei denn, sie konfigurieren ihren Mailclient um. Wie wahrscheinlich das ist, mag sich jeder, der schon einmal Unternehmens-IT im größeren Maßstab betreut hat, selbst ausmalen.

Obendrein ergibt sich aus dem Konstrukt noch eine andere Herausforderung: Die eingegangenen Nachrichten müssten ja, sobald die Hauptinstanz nach dem Update wieder verfügbar ist, irgendwie ihren Weg dorthin wiederfinden. Das klappt nur mit Synchronisationswerkzeugen, bedingt aber zusätzliche Konfigurationsarbeiten, die die meisten Admins wohl eher als ätzend beschreiben würden.

Für redundante Mailserver, die Upgrades ohne Schwierigkeiten ermöglichen, müssen andere Techniken her – und das betrifft weniger die Server selbst als ihre Umgebung. Sieht man etwa nach, wie Google eingehende E-Mails heute handhabt, merkt man schnell: Hier existieren mittlerweile nicht einmal mehr mehrere MX-Einträge pro Domäne (Abbildung 2). Alles, was die Annahme- und Verteilungslogik angeht, löst Google stattdessen intern. Mit wenigen Handgriffen lässt sich ein Teil dieser Funktionen durchaus im kleinen Maßstab nachbauen.

Abbildung 2: Während das Linux-Magazin sich um seine E-Mails selbst kümmert, nutzt die private Domäne des Autors noch Googles altes MX-Layout. Die Mail-Konfiguration seiner Firma True West ist neuer und zeigt: Google nutzt im Hintergrund Load Balancer.

Worauf kommt es dabei an? Zunächst gilt: Wer sicherstellen möchte, dass Nachrichten auch dann eingehen können, wenn ein Mailserver gerade ein Update durchläuft, braucht weiterhin mehrere aktiv nutzbare Server. Die sollte man sich allerdings weniger in einem Primary-Secondary-Setup vorstellen, sondern eher als gleichberechtigte Dienstelieferanten auf einer Ebene. Das funktioniert nur mit einem Load Balancer auf der Netzwerkebene. Auch der sollte freilich, wenn es wirklich stimmig sein soll, redundant ausgelegt sein und Werkzeuge wie BGP [1] oder VRRP [2] nutzen, um für die Außenwelt stets einen validen Anlaufpunkt zu bieten.

Ferner muss der Load Balancer zumindest Balancing auf TCP/IP-Ebene beherrschen. Besser wäre es, könnte er spezifisch die Mailserver-typischen Protokolle verstehen und entsprechend handeln. Das betrifft in den meisten Setups vor allem SMTP(S) [3] und IMAP(S) [4]. Besondere Hardware oder teure Software ist dafür übrigens gar nicht nötig: Alle gängigen quelloffenen Load Balancer lassen sich problemlos auch für SMTP und IMAP verwenden, darunter HAProxy [5] und Nginx [6].

Streng genommen übernimmt dabei insbesondere Nginx sogar mehr Aufgaben als ein simpler Load Balancer. Vielmehr fungiert die Software als Proxy zwischen Server und Client und terminiert etwa SSL selbst. Dabei bleibt es dem Admin unbenommen, internes SSL zwischen den Mailserver-Instanzen und Nginx vorzugeben. So oder so: Kommt ein Load Balancer oder Proxy für SMTP und IMAP zum Einsatz, landen eingehende Anfragen zunächst bei ihm und werden im Nachgang auf die zugeordneten Backends verteilt.

Alle gleich

Dieses Prinzip funktioniert aber nur, wenn die Mailserver im Hintergrund Zugriff auf dieselben Ablageorte für Nachrichten haben, und zwar sowohl hinsichtlich der eingehenden als auch der ausgehenden E-Mails.

Stellen beispielsweise die angeschlossenen SMTP-Server ihre Mails jeweils nach »/var/lib/mail« zu, hätte jeder Zielnutzer am Ende mehrere Postfächer an verschiedenen Stellen und bräuchte im Mailclient für jedes davon einen einzelnen Zugang. Das ist nicht nur unpraktisch, sondern geht auch mit diversen technischen Schwierigkeiten einher. Sinnvoller wäre es, könnten stattdessen sowohl die Dienste für eingehende als auch für ausgehende Nachrichten auf dieselben Datensätze zugreifen.

Dafür gibt es mehrere Ansätze: Wahlweise legt der Administrator alle E-Mails auf ein geteiltes NFS [7], nutzt ein anderes Netzwerkdateisystem wie CephFS [8] oder greift gleich auf Objektspeicher wie RADOS nativ zurück. Für Dovecot [9] etwa, den mit Abstand beliebtesten freien IMAP-Server, existiert ein RADOS-Plugin (Abbildung 3). Es legt Mails als Objekte direkt in RADOS ab und ruft sie auf Anfrage genauso wieder ab. Konfiguriert der Administrator seinen SMTP-Dienst nun noch so, dass er die Nachrichten nicht selbst an beliebiger Stelle ablegen möchte, sondern sie an den laufenden Dovecot weitergibt, wird ein Schuh daraus.

Abbildung 3: Redundante Mailserver lassen sich ohne Ausfälle aktualisieren. Wer beispielsweise Nachrichten mittels des dafür existierenden Dovecot-Plugins in RADOS verwaltet, braucht sich um einzelne Frontends und ihre Verfügbarkeit nicht zu sorgen. Quelle: Dovecot-Ceph-Plugin

Quasi en passant richtet der Admin sich auf diese Weise obendrein klassische Hochverfügbarkeit und Skalierbarkeit in die Breite auf mehreren Ebenen ein. In diesem Konstrukt lassen sich bei hoher Last zusätzliche SMTP-Server ebenso leicht hinzufügen wie zusätzliche Dovecot-Instanzen. Letztere sind dann übrigens ebenso als Teil der Load-Balancer-Lösung zu beachten.

Im Kontext von Updates sind solche Setups äußerst praktisch: Aus Sicht des Administrators genügt es, einzelne Backends für SMTP oder IMAP zu deaktivieren und sie damit aus dem Load Balancer zu nehmen. Ein- wie ausgehende E-Mails lassen sich problemlos weiterhin abhandeln. Den nun deaktivierten Server kann man ohne Einfluss auf die Produktion aktualisieren und danach wieder in den Verbund aufnehmen; anschließend folgt die nächste Maschine.

Dieses Szenario erlaubt aus Sicht des Administrators sogar, die einzelnen Server nicht klassisch zu aktualisieren, sondern sie komplett neu zu installieren und anschließend per Automation wieder mit der benötigten Konfiguration zu versehen. Der Vollständigkeit halber sei angemerkt, dass diese Art der Redundanz und Replikation (meist findet sie dann auf der Ebene des zentralen Speichers statt) den Administrator nicht von der Pflicht zu regelmäßigen Backups entbindet: Replikation ersetzt bekanntlich kein Backup.

Eine Nummer kleiner

Das bis hierhin beschriebene Setup eignet sich besonders für größere Installationen mit vielen parallelen Nutzern und hoher Grundlast. Wer in der Lage sein möchte, seinen Mailserver sinnvoll zu aktualisieren, ohne gleich das ganz große Rad in Sachen Skalierbarkeit zu drehen, hat die Option eines Mittelwegs. Dabei bleiben die Anforderungen dieselben: Zwischen mehreren Systemen muss geteilter Speicher für das Ablegen der Mails existieren, damit Dienste wie IMAP funktionieren und der Server eingehende Nachrichten zustellen kann.

Das lässt sich unter Linux mit Bordmitteln wie DRBD [10] gut bewerkstelligen. Alternativ zum Load Balancer kann eine Cluster-IP zum Einsatz kommen, die – von Pacemaker [11] oder DRBD Reactor verwaltet – zwischen den Systemen hin und her schwenkt. Der Clustermanager sorgt in diesem Szenario dafür, dass stets alle zentralen Dienste wie SMTP- und IMAP-Server auf einem System aktiv bleiben, dass aber auch der Schwenk auf den zweiten Knoten jederzeit möglich ist.

Will man nun eine der beiden Instanzen aktualisieren und dabei Software wie Exim [12] oder Postfix [13] sowie Dovecot auf den Stand der gegenwärtigen Technik bringen, vollführt man zunächst einen Wechsel weg von diesem System, nimmt das Upgrade vor, schwenkt erneut hin zum bereits aktuellen System und aktualisiert schließlich auch den zweiten Knoten.

Der einzige Unsicherheitsfaktor in diesem wie auch im zuvor skizzierten größeren Szenario: Ein Failover während des Updates führt möglicherweise zu Problemen. Das ist immer dann der Fall, wenn sich bei den genutzten Programmen durch das Upgrade interne Strukturen, ABIs oder APIs ändern. Die alte Software auf dem verbliebenen Knoten kommt dann möglicherweise nicht mehr mit den Dateien der neueren Variante auf dem anderen System zurecht.

Wer beispielsweise MySQL als Komponente seines Mailserver-Setups nutzt und dabei im Rahmen eines Upgrades die MySQL-Metadaten aktualisiert, kann nicht mehr davon ausgehen, dass im Falle eines dringend nötigen Failovers die alte MySQL-Variante des noch nicht aktualisierten Knotens diese Metadaten auslesen und nutzen kann. Hier ist präzise Vorbereitung im Vorfeld der einzig sinnvolle Weg zur Vermeidung von Problemen.

Softwaretausch

Deutlich komplexer wird das Thema von Mailserver-Updates, wenn neben dem simplen Upgrade des Betriebssystems und der Programme auch ein Austausch einzelner Komponenten ansteht. Das kommt auch heute noch häufiger vor, als mancher glaubt.

Selbst wenn Postfix heute als so etwas wie Admins Darling in Sachen SMTP gilt und Dovecot die Konkurrenz weitestgehend verdrängt hat, finden sich noch immer uralte Setups, auf denen Absonderlichkeiten wie Sendmail (Abbildung 4) oder UW IMAPD laufen. Die werden spätestens dann zur Herausforderung für Wartung und Betrieb, wenn die Person das Unternehmen verlässt oder in den Ruhestand geht, auf deren Mist das Setup ursprünglich und irgendwann mal gewachsen ist. Ein Wechsel etwa von UW-IMAPD zu Dovecot gelingt nicht ohne Weiteres. So etwas erfordert eine andere Planung und entsprechende Prozeduren.

Abbildung 4: Vielerorts werkelt noch immer eine alte Sendmail-Instanz mit ihrer etwas eigentümlichen Konfiguration vor sich hin. Hier sehen Sie einen Ausschnitt für die Nutzung von Google als SMTP-Relay.

Einmal mehr spielt eine detaillierte Vorbereitung dabei eine zentrale Rolle. Bezüglich der Komplexität unterscheidet sich beispielsweise der Ersatz eines SMTP-Servers erheblich vom Ersatz eines Dovecot-Servers. Die Hauptaufgabe des SMTP-Servers besteht “nur” darin, eingehende E-Mails entgegenzunehmen und an einen IMAP-Daemon auszuliefern sowie ausgehende Nachrichten zu versenden. Letzteres stellt keinen aktuellen SMTP-Dienst vor Herausforderungen, weder Sendmail noch Postfix. Das Handling eingehender Mails ist hingegen schon eher ein Thema.

Nicht selten neigen gerade ältere Mailserver dazu, Nachrichten direkt in das lokale Dateisystem zuzustellen, wo der genutzte IMAP-Daemon sie dann ausliest und an die Nutzer ausliefert. Das bringt das Problem mit sich, dass ein sehr enges Band zwischen SMTP-Daemon und IMAP-Dienst existiert, das gerade bei der Migration von einem Programm zum anderen zwangsläufig reißt. Idealerweise geht der Administrator in solchen Fällen Schritt für Schritt vor und löst die einzelnen Abhängigkeiten auf.

Erfreulicherweise ermöglicht das IMAP-Protokoll, ohne große Probleme den gesamten Bestand eines Postfachs mithilfe eines Synchronisierungshelfers zu überspielen. Die arbeiten nach einem simplen Prinzip: Sie lesen direkt per IMAP ein bestehendes Postfach ein und spielen es dann an einen anderen IMAP-Dienst wieder aus. Ist der so konfiguriert, dass er sein eigenes, natives Format nutzt – Dovecot etwa beherrscht eine Vielzahl von Verzeichnislayouts – steht am Ende der Mühe ein Dovecot-Server mit perfekt lokal sortierten Mails.

Ein erster Schritt zum Update in einem solchen Szenario besteht aus Sicht des Administrators darin, eine zusätzliche Instanz zum Bestandteil der Installation zu machen. Auf der läuft der neue Mail-Dienst (etwa Dovecot) in der gewünschten Konfiguration. Dann erfolgt im Hintergrund die Migration bestehender Postfächer. Dabei erscheint es aus Sicht des Systemverwalters ratsam, ein Konzept zu erstellen, das die Mailboxen aller betroffenen Benutzer zentral gesteuert überträgt.

Während der laufenden Synchronisation bleibt das bestehende Server-Setup unangetastet; die Anwender nutzen ihre Maildienste wie gehabt. Ist die Synchronisation abgeschlossen, folgt der nächste Schritt: Dann konfiguriert der Administrator die bestehenden SMTP-Server so, dass sie eingehende Nachrichten künftig an das neue IMAP-Setup zustellen. Ab diesem Zeitpunkt liegt die alte IMAP-Installation brach.

Eine erneute Synchronisation sorgt dafür, dass auch solche Mails ihren Weg in die neue Installation finden, die noch im alten IMAP-System eingetrudelt sind, während die erste Synchronisation bereits lief. Die meisten Werkzeuge zur Synchronisierung beherrschen inkrementelles Vorgehen. Grundsätzlich sei an dieser Stelle allerdings darauf hingewiesen, dass eine Migration pro Postfach je nach Größe der Zielmailboxen einige Zeit in Anspruch nehmen und einiges an CPU-Leistung und RAM fressen kann.

Es fragt sich an dieser Stelle, wie man mit den konfigurierten Clients umgehen soll. Aus Sicht des Admins wäre es sinnvoll, den neuen IMAP-Dienst so zu konfigurieren, dass er aus der Perspektive des Clients genauso funktioniert wie vorher. Das umfasst Faktoren wie das Verzeichnispräfix. Alternativ wäre es auch möglich, die Nutzerinnen und Nutzer zur Einrichtung eines neuen Zugangs für das aufgefrischte Mailsystem zu bewegen. Das dürfte allerdings mit erheblich mehr Aufwand in Sachen Support verbunden sein. Wer den neuen IMAP-Dienst stattdessen zum Drop-in-Replacement für den alten macht, schwenkt nach abgeschlossener Synchronisation bloß noch den DNS-Eintrag von der IP des alten Systems auf jene des neuen um. Dadurch nutzen die Clients die neue Installation automatisch.

Anschließend steht der Tausch der SMTP-Software auf dem Programm. Wer diesen Schritt ohne Downtime vollziehen will, braucht entweder ein HA-Setup oder zumindest mehrere MX-Einträge. In beiden Fällen ist es dann möglich, die bestehenden SMTP-Server einen nach dem anderen zu deaktivieren, zu aktualisieren, die neue Software zu installieren und zu konfigurieren und den Server dann wieder aktiv zu schalten.

Illusionen sollte man sich an dieser Stelle allerdings nicht machen: Schon bei einem mittelgroßen Setup erfordern Planung und Umsetzung einer umfassenden Migration etliche Tage, wenn nicht gar Wochen. “Mal eben” lässt sich ein Mailserver-Update bei gleichzeitigem Austausch der betroffenen Komponenten also nicht abwickeln.

Zusatzsoftware beachten

Noch gar nicht zur Rede gekommen sind bisher Zusatzwerkzeuge, die sich in vielen Mail-Setups finden, die während der alltäglichen Arbeit aber kaum auffallen. Spam- und Malware-Bekämpfung liefern dafür gute Beispiele.

Wer noch in den frühen 2000er-Jahren IT-sozialisiert wurde, kennt aus dieser Zeit Werkzeuge wie SpamAssassin [14] und ClamAV [15]. Ersteres ist ein nach dem Bayes-Konzept trainierbarer Spamfilter, letzteres zieht Nachrichten mit Viren sowie Mal- und Ransomware automatisiert aus dem Verkehr. Es gibt zahllose Variationen und Möglichkeiten, solche Dienste in das eigene Mail-Setup einzubauen.

Mancherorts kümmert sich der SMTP-Daemon um den Aufruf von SpamAssassin oder ClamAV. Andernorts übernimmt der konfigurierte IMAP-Filter die Prüfung, insbesondere dort, wo der Mailserver eingehende Nachrichten direkt an den IMAP-Daemon abtritt. Entsprechend komplex sind mögliche Upgrade-Pfade. Das gilt umso mehr, da ClamAV heute zwar noch als Goldstandard für ein Antivirenprodukt gilt, SpamAssassin mittlerweile in Form von Rspamd [16] aber einen legitimen Nachfolger gefunden hat (Abbildung 5). Jede einzelne dieser Komponenten muss der Administrator im Hinblick auf ihren Austausch in Betracht ziehen und bei seinen Planungen bedenken.

Abbildung 5: Rspamd gilt als vielseitiger und funktionaler als SpamAssassin und hat den Vorgänger vielerorts verdrängt. Wer im Rahmen eines Updates des Mailservers auf Rspamd umsteigen will, sollte das sorgfältig planen. Quelle: Arno Welzel

Wer beispielsweise von SpamAssassin auf Rspamd umsteigen möchte, muss die passende Konfiguration dafür in der Schublade liegen haben, wenn er das Update für die SMTP-Server (oder ihre Reinstallation) vollzieht. Wo Admins, die bei SpamAssassin bleiben möchten, auf Ubuntu-Systemen oft mit einem simplen »do-system-upgrade« auskommen, steht hier der Austausch von Paketen ebenso wie das Ausrollen zusätzlicher Konfigurationsdateien auf dem Plan. Einmal mehr profitieren jene Administratoren massiv, die auf umfassende Automation setzen: Einmal richtig gebaut, nimmt sie ihnen einen erheblichen Anteil der Arbeit ab.

Fazit

Wie komplex und schwierig das Update eines Mailservers oder eines Mailserver-Clusters wird, hängt davon ab, wie gut man die Installation vorbereitet und wie weit sie Standards entspricht.

Wer auf umfassende Redundanz durch klassische Hochverfügbarkeit oder Skalierbarkeit in die Breite setzt, für den impliziert eine solche Aktualisierung oft nicht mehr Arbeit als die bloße Installation der neuen Pakete mit den Werkzeugen der verwendeten Linux-Distribution. Wer jedoch ganz klassisch einen nicht redundanten Mailserver älteren Typs betreibt und ihn mit frischer Software und anderen Komponenten ausstatten will, hat kaum eine Chance, das Prozedere ohne Downtime zu meistern.

Hier wäre es besser, zunächst die Redundanz nachzurüsten, bevor die eigentliche Aktualisierung stattfindet. Vertane Arbeit ist das nicht: Im Anschluss an die Aktualisierung bleibt die Redundanz ja erhalten. Der Administrator profitiert davon also nicht nur im laufenden Betrieb, sondern gleichermaßen beim nächsten anstehenden Update. (jcb/jlu)