News zu Servicewelten
“Wenn ich mir schon mal die Zeit nehme, meine Datenbanksysteme zu patchen, dann mache ich das auch gleich für alle.” Auf den ersten Blick ein durchaus verlockender und nachvollziehbarer Gedanke. Aber ist das wirklich sinnvoll? Im dritten Teil unserer kleinen Blogpost Serie “Tipps und Tricks zum Patchen von Datenbanken” beschäftigen wir uns genau mit dieser Frage. Dabei greifen wir auf das wertvolle Wissen unserer ASPICON Datenbankadministratoren aus den Teams Oracle, MS SQL und PostgreSQL zurück und möchten die Meinungen der Kollegen mit dir teilen. Wann ein gleichzeitiges Patchen sinnvoll (oder gar notwendig) sein kann und wann nicht, erfährst du in den folgenden Zeilen. Am Ende haben wir die Vor- und Nachteile noch übersichtlich für dich zusammengefasst.
“Sind wir mal ehrlich: Patchen ist ein durchaus lästiges Thema. Sowohl für unsere Kunden als auch für uns als Dienstleister.”, gibt Thilo ehrlich zu. Thilo ist Datenbankadministrator im Team Oracle bei ASPICON und als solcher unter anderem für das Patchen von Kundensystemen zuständig. “Das Einspielen von Updates ist immer mit einem gewissen Aufwand und in der Regel auch mit einer kleineren oder größeren Downtime verbunden. Darüber hinaus ist die Häufigkeit, mit der Patches erscheinen, für viele Unternehmen und Einrichtungen eine echte Herausforderung.”, sagt Thilo weiter.
Auch wenn Patches im Allgemeinen recht gut getestet sind und es auf den ersten Blick aufgrund der Fülle an Updates durchaus bequemer erscheint, von einem Patchen aller Datenbanksysteme auf einmal würde Thilo abraten: “Im Idealfall arbeitest du mit einer Test- und einer Produktivumgebung. So kannst du das Testsystem zuerst updaten und nach einer gewissen (nicht zu langen) Zeit das Produktivsystem nachziehen. So lassen sich etwaige Störfaktoren zunächst im Testsystem erkennen.”
Sind wir mal ehrlich: Patchen ist ein durchaus lästiges Thema. Dennoch rate ich vom Patchen aller Datenbanksysteme auf einmal ab.
(Thilo, Datenbankadministrator im Team Oracle bei ASPICON)
Ähnlich sieht das auch Jörg – ebenfalls ASPICON Datenbankadministrator im Team Oracle: “Es empfiehlt sich, immer zuerst das Testsystem zu patchen. Bei einem Failover Cluster etwa muss das Patchen zwangsläufig nach und nach erfolgen. Dort kannst du beispielsweise bei einem Zwei-Node-Cluster die passive Seite aktualisieren und eine Test- oder Entwicklungsdatenbank rüberschwenken. Erst wenn du alle Anwendungen durchgetestet hast und diese fehlerfrei funktionieren, schwenkst du auch die anderen Datenbanken.”
In der Microsoft Welt ist die Frage, ob es sinnvoll ist, alle Datenbanksysteme auf einmal zu patchen, gar nicht so leicht zu beantworten. Hier muss zwischen Hochverfügbarkeitsumgebung und Einzelsystem unterschieden werden.
Tobias – Datenbankadministrator für Microsoft SQL Server – sagt dazu: “Wenn du eine Microsoft “Always On” Lösung betreibst, musst du unbedingt alle Komponenten in diesem Setup gleichzeitig aktualisieren. Das liegt daran, dass Hochverfügbarkeit durch redundante SQL Server erreicht wird. Diese arbeiten entweder auf verschiedenen Hosts mit Zugriff auf dieselben Daten (in SQL Failover Clustern) oder sogar mit den gleichen Daten (in SQL Availability Groups). Aus technischen Gründen müssen daher alle Systeme innerhalb dieser Umgebung immer auf dem exakt gleichen Versionsstand sein.”
Anders sieht es da in einer konventionellen Umgebung aus: “Hier empfiehlt es sich, jedes Produkt von Microsoft einzeln und vor allem den SQL Server manuell zu patchen.”, so Tobias. Mittlerweile bietet Microsoft zwar die Möglichkeit, SQL Server Updates ebenso wie Windows Updates direkt und automatisch von den Update-Servern zu beziehen. Von diesem Vorgehen rät Tobias allerdings strikt ab: “Etwaige Ungereimtheiten könnten so unter Umständen erst zu spät bemerkt werden oder die Fehlersuche unnötig erschweren.” Laut Tobias ist das manuelle Anwenden eines Patches für die Microsoft SQL Server Produktpalette in der Regel gut investierte Zeit.
Das manuelle und sukzessive Anwenden eines Patches für die Microsoft SQL Server Produktpalette ist in der Regel gut investierte Zeit.
(Tobias, Datenbankadministrator im Team Microsoft bei ASPICON)
Im PostgreSQL Umfeld ist das Patchen generell etwas unkomplizierter: “Das reine Einspielen von Minor Version Releases für alle bestehenden PostgreSQL Datenbanken in einer Single Host Umgebung ist meist kein Problem. Erst mit dem Neustart der Instanz, der zwangsläufig irgendwann erfolgen muss, könnte es zu Problemen kommen. Zumindest, wenn die Instanz nicht vernünftig konfiguriert ist.”, so Michael. Michael ist Datenbankadministrator im Team PostgreSQL und betreut unsere Kunden im Open Source Bereich. Er empfiehlt, die Updates tagsüber einzuspielen und nachts bzw. außerhalb der Geschäftszeiten den Neustart vorzunehmen. Je nach Anzahl der Systeme und Umfang der Patches macht eine Staffelung im Hinblick auf den Arbeitsaufwand und die Ressourcen dennoch Sinn.
“Wenn du in einer Hochverfügbarkeitsumgebung arbeitest, solltest du aber in jedem Falle die Standby- und Produktivdatenbank getrennt voneinander patchen.”, so Michael weiter. Dank eingebautem Replikationsprotokoll im Open-Source Datenbankmanagementsystem von PostgreSQL ist ein Cluster mit mehreren Knoten auch gleich mit im Gepäck, ganz ohne zusätzliche Lizenzierung.
Wenn du in einer Hochverfügbarkeitsumgebung arbeitest, solltest du in jedem Falle die Standby- und Produktivdatenbank getrennt voneinander patchen.
(Michael, Datenbankadministrator im Team PostgreSQL bei ASPICON)
Unserer Erfahrung nach ist es in den meisten Fällen sinnvoll, Patches schrittweise anzuwenden und gründliche Tests durchzuführen, bevor sie auf Produktivdatenbanken angewendet werden. Allerdings kann es auch Gründe geben, die ein gleichzeitiges Patchen aller Datenbanksysteme rechtfertigen.
Im Folgenden haben wir einige Vor- und Nachteile des gleichzeitigen Patchens von Datenbanksystemen für dich zusammengefasst:
|
Vorteile des gleichzeitigen Patchens
|
Nachteile des gleichzeitigen Patchens
|
|---|---|
|
Konsistenz:
Wenn alle Systeme zur gleichen Zeit gepatcht werden, kannst du sicherstellen, dass alle Datenbanksysteme auf demselben Stand sind. Dies kann helfen, Inkonsistenzen zu vermeiden und das allgemeine Systemmanagement zu erleichtern. |
Längere Ausfallzeiten:
Ein simultanes Patchen kann dazu führen, dass alle Systeme gleichzeitig offline gehen müssen. Dies kann zu erheblichen Unterbrechungen führen. Insbesondere, wenn die Datenbanksysteme kritische Geschäftsprozesse unterstützen, könnte dies Probleme mit sich bringen. |
|
Zeiteffizienz:
Anstatt mehrere Patching-Sessions zu planen und zu überwachen, ermöglicht das gleichzeitige Patchen eine einmalige Aktion, die weniger Management-Zeit erfordern kann. |
Höheres Risiko:
Wenn ein Patch fehlerhaft ist oder unerwartete Nebenwirkungen hat, könnten alle gepatchten Systeme gleichzeitig betroffen sein. Dies könnte zu erheblichen Ausfällen und möglicherweise zum Verlust von Daten führen. |
|
Sicherheit:
Sicherheitspatches sollten immer so schnell wie möglich angewendet werden, um sicherzustellen, dass alle Systeme vor bekannten Bedrohungen geschützt sind. Das Patchen aller Datenbanksysteme gleichzeitig kann die Zeitfenster minimieren, in denen Systeme anfällig für Ausnutzung sind. |
Ressourcenanforderungen:
Das gleichzeitige Patchen mehrerer Systeme kann erhebliche Ressourcen in Bezug auf Bandbreite, Rechenleistung und Personal erfordern. Falls du nicht über die nötigen Ressourcen verfügst, solltest du ein schrittweises Patchen in Betracht ziehen. |
|
Ausfallzeiten koordinieren:
Wenn Ausfallzeiten für das Patchen unvermeidlich sind, kann es sinnvoll sein, diese auf einmal zu planen, um die Anzahl der Ausfallzeiten zu minimieren. |
Problembehebung:
Wenn Probleme auftreten, kann es schwieriger sein, die Ursache zu identifizieren und zu beheben, wenn alle Systeme gleichzeitig gepatcht werden. Es könnte auch schwierig sein, das Patching rückgängig zu machen oder auf eine vorherige Konfiguration zurückzusetzen. |
Vorteile des gleichzeitigen Patchens:
Nachteile des gleichzeitigen Patchens:
Ob es sinnvoll ist, alle Datenbanksysteme auf einmal zu patchen, hängt also von verschiedenen Faktoren ab. Unter anderem spielen die Größe und Beschaffenheit deiner Datenbanklandschaft sowie die Art der Patches und die vorhandenen Ressourcen eine Rolle. Eine individuelle Betrachtung ist also unerlässlich.
Du siehst: Es gibt nicht den einen richtigen Weg. Wichtig ist, in jedem Falle eine Risikobewertung durchzuführen und sicherzustellen, dass geeignete Pläne für das Testen, die Rückfallstrategien und die Notfallwiederherstellung vorhanden und möglichst niedergeschrieben sind.
Du hast Fragen dazu oder möchtest dich mit unseren Datenbankprofis austauschen? Ruf uns einfach an.
Patch-Hotline: +49.371.909515–100
Hier findest du weitere Infos zu den vergangenen und aktuellen Patch Updates aus unserem News und Insights Bereich.
Share this article