News zu Servicewelten
“Ich würde ja meine Datenbanken patchen, aber ich bekomme kein Zeitfenster für eine Downtime!” Diesen Satz hören wir leider viel zu oft. Aber: Muss Patchen denn immer mit einer Downtime verbunden sein? Wenn du dir diese Frage auch schon gestellt hast, dann solltest du unbedingt weiterlesen. Im Rahmen unserer mehrteiligen Blogpost-Serie “Tipps und Tricks zum Thema Patchen” beschäftigen wir uns im heutigen Beitrag nämlich genau damit.
Dazu haben wir mit einigen Spezialisten aus den Teams Oracle, MS SQL und PostgreSQL bei ASPICON gesprochen und sie gefragt, warum Downtimes für viele Kunden eigentlich ein Problem sind und was du tun kannst, um sie möglichst klein zu halten oder gar zu vermeiden. Die Besonderheiten der einzelnen Welten haben wir dann nochmal übersichtlich für dich zusammengefasst.
Zunächst sei kurz geklärt: Wenn wir im Folgenden von “Downtime” sprechen, dann meinen wir die gezielte und planmäßige Abschaltung eines Datenbankservers im Rahmen des Patchens, wodurch es in der Regel zu Ausfällen der Anwendungen kommt. Das ist auch genau der Grund, wieso Downtimes weder bei den IT-Verantwortlichen noch bei der Geschäftsleitung sonderlich beliebt sind. Denn die Anwender können während dieser Zeit ihrer Arbeit meist nicht nachgehen oder ganze Produktionsprozesse müssen ruhen. Deshalb ist es für viele Firmen sowie Einrichtungen noch immer ein schwieriges und zum Teil auch ungeliebtes Thema. Sie nehmen ein erhöhtes Sicherheitsrisiko – was von ungepatchten Systemen ausgeht – in Kauf. Dabei lassen sich Downtimes sowohl gut planen als auch erheblich reduzieren oder sogar ganz vermeiden.
Hinweis:
Die Planbarkeit variiert natürlich von Hersteller zu Hersteller. Oracle z.B. veröffentlicht viermal im Jahr ein großes Critical Patch Update (CPU). Die Termine werden jeweils ein Jahr im Voraus bekannt gegeben. Ähnlich ist es bei PostgreSQL. Auch hier kommen die Major Version Releases quartalsweise raus und werden rechtzeitig angekündigt. In der MS SQL Welt hängen die Abstände zwischen dem Erscheinen einzelner Patches von der Lebensdauer des jeweiligen Produkts ab. Eine Übersicht dazu findest du » hier.
Ein “normaler” Patchablauf bei einem Single Host sieht in der Regel folgendermaßen aus: Die Datenbank wird heruntergefahren, der Patch eingespielt und die Datenbank wird auf der gepatchten Software wieder hochgefahren. Je nach Datenbank, Datenbankgröße und Leistungsfähigkeit der Systeme beträgt die Dauer der Downtime meist eine halbe bis eine Stunde für ein bis zwei Datenbanken. Als Faustregel gilt: Je unregelmäßiger Patches eingespielt werden, umso länger sind die Downtimes. Regelmäßiges Patchen hilft also auch, die Ausfallzeit zu reduzieren.
Durch den Einsatz von hochverfügbaren Systemen oder einer zweiten Instanz deiner Software kannst du die Downtime allerdings darüber hinaus noch erheblich reduzieren. Hier einige Beispiele dazu aus der Oracle und MS SQL Welt:
Mit dem Failover Cluster von Oracle kannst du die Downtime auf ca. fünf Minuten pro Datenbank reduzieren. Hier hast du zwei oder mehr Hosts, auf denen die Datenbanken verteilt laufen. In dem Fall kannst du die Clusterknoten, die leerlaufen, schon mal aktualisieren und musst im Wartungsfenster nur noch die Datenbank auf den aktualisierten Host schwenken sowie die Änderungen im Dictionary vornehmen.
Eine weitere Möglichkeit bieten sogenannte “Standby-Datenbanken”. Aufgrund der Verteilung der Primärdatenbank und der Standby-Datenbank auf zwei unterschiedliche Hosts kannst du die Standby-Seite schon vor dem eigentlichen Wartungsfenster aktualisieren. Im Wartungsslot musst du nur noch die Datenbank schwenken und die Einträge im Dictionary vornehmen. Im Standard Edition Bereich bietet sich hier Dbvisit an. Mit der » Dbvisit Standby MP v11 z.B. lassen sich Standby-Datenbanken für Oracle und MS SQL Server aufbauen und betreiben. Da das Schwenken hier etwas länger dauert beträgt die Downtime im Schnitt ca. zehn Minuten.
Im Enterprise Edition Bereich von Oracle liefert DataGuard entsprechende Möglichkeiten. Das Wartungsfenster reduziert sich hier auf ca. fünf Minuten. In beiden Fällen hast du den großen Vorteil, dass böse Überraschungen auf der primären Seite der Datenbank verhindert werden, da der Patch zunächst auf der Standby-Seite eingespielt wird.
Hinweis:
Unabhängig von den Vorteilen, die ein Failover Cluster bzw. eine Standby-Datenbank für das Patchen und die Reduzierung der Downtimes haben, empfehlen wir den Einsatz einer solchen Lösung immer im Sinne der Hochverfügbarkeit und Ausfallsicherheit deiner Datenbanken.
Meist ist für unsere Kunden aber nicht die Länge der Downtime entscheidend, sondern die Tatsache, dass es überhaupt eine gibt. Denn dadurch müssen oftmals Prozesse runtergefahren, danach wieder angefahren und geprüft werden. So wird aus einer halben Stunde Downtime für die eigentliche Wartung schnell ein zweistündiger Slot nötig, bis alles wieder ordnungsgemäß läuft. Leider ist das der Hauptgrund dafür, dass manche Kunden sich vom Patchen distanzieren – was aus sicherheitstechnischer Sicht natürlich verheerende Folgen haben kann.
Falls für dich auch eine kurze Downtime zum Problem werden kann, solltest du dir die folgenden Konzepte und Lösungen anschauen, um Ausfälle gänzlich zu vermeiden:
Im Enterprise Edition Bereich von Oracle bietet dir eine zusätzliche Lizenzierung für “Application Continuity” die Möglichkeit, (meist) ganz ohne Downtime zu patchen. Hier sorgt eine zusätzliche Treiberschicht dafür, dass die Transaktionen für die Zeit der Wartung gepuffert und anschließend nachgefahren werden. Die Anwendung spürt davon im Idealfall nichts. Das Konzept ist allerdings ziemlich aufwändig, mit zusätzlichen Lizenzkosten verbunden und in manchen Fällen trotzdem mit einer kleinen Downtime verbunden.
Auch diese Möglichkeit setzt die Enterprise Edition von Oracle mit zusätzlicher RAC Option voraus. Die Datenbank läuft in dem Fall nicht nur auf einem Clusterknoten, sondern auf allen. Du kannst also jeden Clusterknoten einzeln updaten und hast dadurch keine Downtime. Dafür muss deine Java Anwendung mit dem Oracle Notification Service (ONS) kommunizieren. Das hat den Vorteil, dass die bestehenden Anwendungssession neu aufgebaut, Transaktionen zurückgerollt und in einer neuen Session nochmals ausgeführt werden. Somit bemerkt der User nichts von der Wartung. Dies muss allerdings von der jeweiligen Anwendung unterstützt werden. Ist das nicht der Fall, kannst du auch einfach die Clusterknoten nach und nach leer räumen, runterfahren und updaten. Die Usersessions werden in der Zwischenzeit auf die anderen Clusterknoten ausgelagert.
Auch Microsoft bietet im Rahmen der Hochverfügbarkeitsumgebung “Always On” die Möglichkeit, ganz ohne Downtime zu patchen. Dank mehrerer Datenbankserver kann einer heruntergefahren, gepacht und danach wieder hochgefahren werden. Anschließend folgt der Schwenk auf den gepatchten Server. Hierbei werden sämtliche Sitzungen zu Client-Anwendungen beendet, was allerdings im überwiegenden Teil aller Fälle von den ODBC-Treibern abgefangen wird. Du und deine Anwender sollten diesen Moment des Wechsels in der Regel nicht bemerken.
Den wohl kostengünstigsten und einfachsten Weg, ohne Downtime zu patchen, bietet zweifelsohne das Open-Source Datenbankmanagementsystem PostgreSQL. Dank eingebautem Replikationsprotokoll ist ein Cluster mit mehreren Knoten gleich mit im Gepäck. Bei der Clusterverwaltung helfen kostenfreie Werkzeuge, die neben einer einfachen Einrichtung auch Switch- und Failover-Funktionen bereitstellen. Im Idealfall kann die Anwendung die Datenbank-Connections selbst verwalten und Daten cachen, sodass der User auch vom Schwenken rein gar nichts mitbekommt. Aber auch hier können frei verfügbare Werkzeuge aus der PostgreSQL-Welt helfen.
Die folgende Übersicht fasst die Möglichkeiten zum Reduzieren und Vermeiden von Downtimes im Zuge des Patchens von Datenbanken nach Herstellern noch einmal zusammen:
|
|
Oracle
|
MS SQL
|
PostgreSQL
|
|---|---|---|---|
|
Downtimes reduzieren
|
Failover Cluster:
reduziert Downtimes auf ca. 5 Minuten pro Datenbank Standby-Datenbank mit Dbvisit Standby MP: für Standard Edition; reduziert Downtimes auf ca. 10 Minuten pro Datenbank Standby-Datenbank mit DataGuard: für Enterprise Bereich; reduziert Downtimes auf ca. 5 Minuten pro Datenbank Außerdem: regelmäßig Patchen; gute Vorbereitung der Patches |
Dbvisit Standby MP:
für Standard Edition; reduziert Downtimes auf ca. 30 Minuten pro Datenbank Außerdem: regelmäßig Patchen; gute Vorbereitung der Patches |
n‑Knoten-Cluster:
im Standard enthalten; kostenfreie Zusatztools machen das Handling bequemer Außerdem: regelmäßig Patchen; gute Vorbereitung der Patches |
|
Downtimes vermeiden
|
Application Continuity:
für Enterprise Bereich Active Active Cluster mit Fast Connection Failover: für Enterprise Bereich mit RAC Option |
Always On:
Hochverfügbarkeit durch redundante SQL Server auf unterschiedlichen Hosts |
n‑Knoten-Cluster:
im Standard enthalten; kostenfreie Zusatztools machen das Handling bequemer |
|
|
Oracle
|
MS SQL
|
PostgreSQL
|
|---|---|---|---|
|
Downtimes reduzieren
|
Failover Cluster:
reduziert Downtimes auf ca. 5 Minuten pro Datenbank Standby-Datenbank mit Dbvisit Standby MP: für Standard Edition; reduziert Downtimes auf ca. 10 Minuten pro Datenbank Standby-Datenbank mit DataGuard: für Enterprise Bereich; reduziert Downtimes auf ca. 5 Minuten pro Datenbank Außerdem: regelmäßig Patchen; gute Vorbereitung der Patches |
Dbvisit Standby MP:
für Standard Edition; reduziert Downtimes auf ca. 30 Minuten pro Datenbank Außerdem: regelmäßig Patchen; gute Vorbereitung der Patches |
n‑Knoten-Cluster:
im Standard enthalten; kostenfreie Zusatztools machen das Handling bequemer Außerdem: regelmäßig Patchen; gute Vorbereitung der Patches |
|
Downtimes vermeiden
|
Application Continuity:
für Enterprise Bereich Active Active Cluster mit Fast Connection Failover: für Enterprise Bereich mit RAC Option |
Always On:
Hochverfügbarkeit durch redundante SQL Server auf unterschiedlichen Hosts |
n‑Knoten-Cluster:
im Standard enthalten; kostenfreie Zusatztools machen das Handling bequemer |
Hinweis:
Die Übersicht erhebt keinen Anspruch auf Vollständigkeit. Sie spiegelt lediglich die Erfahrungen unserer Datenbankspezialisten mit ausgewählten Lösungen wieder. Das gilt auch für die Zeitangaben, welche je nach IT-Umgebung und Voraussetzungen variieren können.
Um die Frage eingangs noch einmal deutlich zu beantworten: Nein, ein Patchen der Datenbanken ist nicht zwingend immer mit einer Downtime verbunden. Einige Möglichkeiten der einzelnen Hersteller, mit denen wir bereits gute Erfahrungen gemacht haben und mit denen Downtimes vermieden werden können, haben wir dir oben zusammengefasst.
Wichtig ist aus unserer Sicht aber auch immer die offene Kommunikation. Auch wenn du ein Konzept wählst, bei dem ohne Downtime gepatcht werden kann, sollte im Vorfeld eine Ankündigung bei den Anwendern stattfinden. Falls es eine Downtime gibt, sollte diese in jedem Falle realistisch, bestenfalls etwas großzügiger kommuniziert werden. Hier spielen Erfahrungswerte eine große Rolle. Unsere Datenbankprofis haben über die Jahre ein gutes Gefühl dafür entwickelt, wie lange die Wartungsarbeiten bei bestimmten Voraussetzungen dauern werden. Eine zunehmende Verquickung zwischen den Datenbankinterna und den Anwendungsdaten führt dazu, dass auch die Datenbankgröße immer stärker an Bedeutung gewinnt für die Dauer der Downtime.
Du hast Fragen dazu oder möchtest das Thema Patchen ohne Downtime für deine IT-Umgebung prüfen? Dann sprich uns gern an! Gemeinsam schauen wir, welche Lösung am besten zu deinen Anforderungen und in deine Umgebung passt.
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