Produktionsdatenbank mit Ausfallsicherheit

Melanie, du hattest es in deinen vielen Projekten vorrangig mit Microsoft-SQL-Servern zu tun. Was sind die häufigsten Probleme? 

Das lässt sich pauschal schwer sagen. Meist geht es um verlorene oder beschädigte Daten. Zum Beispiel ist ein Stück einer Datei nicht sauber geschrieben worden. Und das sorgt dafür, dass ein noch größeres Stück nicht mehr richtig gelesen werden kann. Doch die Fehleranalyse ist das eine. Unsere Aufgabe ist es vor allem, störanfällige Setups von vornherein zu vermeiden. Dass eine systemkritische Datenbank nicht ausreichend gesichert ist, beispielsweise.

Du denkst dabei an einen bestimmten Fall, oder? 

Ja, mir fällt da ein gutes Beispiel ein: ein Hersteller aus der Lebensmittelindustrie. Er produziert Nahrungsergänzungsmittel als Pulver, Kapseln und Tabletten. Über eine SQL-Datenbank steuern die Mitarbeiter dort Mengen von Zutaten oder die benötigten Rezepturen. Alles läuft auf Förderbändern.  

Was war passiert?  

In dem Fall war es drastisch. An einem Freitagnachmittag funktionierte keine der Maschinen mehr. Alles stand still. Die Ursache war eine Datenbankkorruption in der erwähnten Produktionsdatenbank. Wo genau der Fehler lag, war so schnell nicht zu ermitteln. Hinzu kam, dass der Admin die defekten Abschnitte nicht wiederherstellen konnte. Also wurden wir angefragt und stellten fest: Die eingerichtete Backup-Strategie unterstützte nicht die Art von Wiederherstellung, die wir brauchten. Wir reparierten das System schließlich mit Datenverlust und richteten das Backup korrekt ein, sodass es in Zukunft zumindest zu keinem Datenverlust mehr kommen konnte.

Das heißt aber, es gab noch immer nur eine Datenbank. Das klingt nicht nach einer Dauerlösung. Wie ging es weiter?  

Die Geschäftsführung wollte logischerweise ein ausfallsicheres Konzept, das nie wieder eine lange Downtime oder Datenverluste zulassen würde. Also planten wir den Aufbau einer Hochverfügbarkeitslösung mit einer passenden Backup-Strategie. Dazu kamen projekttypische Eigenheiten. 

Kannst du das erklären?  

Das Rechenzentrum liegt in der Nähe eines Flusses und fiel ein Jahr zuvor wegen einer Überschwemmung aus, also brauchte es ein räumlich getrenntes Sicherungssystem. Die Produktionshalle befindet sich deshalb auf einer Anhöhe und alle Informationen werden aus dem Rechenzentrum kabellos per Richtfunk gesendet. Das heißt, die Datenpakete durften bei unserem Konzept nicht zu groß sein. In mehreren Schritten planten wir eine Hochverfügbarkeitslösung mit zwei Knoten, also verteilten Servern. Um das alles umsetzen zu können, war also eine Migration der Datenbank von MSSQL2000 nach MSSQL2016 nötig. Hierfür musste zunächst der Anwendungsquellcode auf ein kompatibles Level angehoben werden. Von diesem Zeitpunkt an haben wir per Log Shipping (siehe Info-Kasten) die Veränderung aller Daten festgehalten, um schon vorab eine Rückversicherung gegen erneute Festplattenprobleme zu haben. Schritt zwei war ein neuer Server, mit dem wir die Daten tatsächlich sichern konnten. Über das eingerichtete Log Shipping konnten wir dann nahtlos mit minimaler Downtime von MSSQL2005 nach MSSQL2016 migrieren. 

Einige Monate später, als der Kunde sogar ein zweites Werk am Standort eröffnete und wir einen weiteren Server implementierten, war das System in der finalen Ausbaustufe und sehr stabil. Im Ergebnis spiegeln zwei Knoten permanent die Daten. Geht ein Server kaputt, liegt die Downtime bei wenigen Sekunden. Dann springt der andere Knoten ein. Das heißt in der IT-Welt Failover-System.  

Klingt nachvollziehbar. Was sind die Herausforderungen dabei?  

Das Einrichten ist nicht ganz trivial – vom Konzept über das Umschreiben des Quellcodes bis zum Programmieren der Backup-Mechanismen. Da geht es um viele Details beim Aufsetzen und bei der Planung und um viel Überzeugungsarbeit, damit das geplante Konzept als langfristig richtig angesehen wird. Schließlich haben die meisten Admins logischerweise nicht regelmäßig mit einem Systemwechsel zu tun. Hier können wir sehr effektiv helfen.  

Wenn du von Überzeugungsarbeit redest: Welche Vorteile bringst du für ein solches Konzept in Anschlag? 

Ein klares Argument ist, dass es am Ende nicht unbedingt mehr kostet. Durch das Prinzip eines Failovers bleiben die Lizenzkosten gering, da man nur den aktiven Knoten lizensiert. Zudem sinkt die Downtime für Wartungsfenster. Denn man kann auf einem der wartenden Server die Updates aufspielen, ohne die Produktion zu stören. Zu einem produktionstechnisch günstigen Zeitpunkt springt man in Sekundenschnelle auf den anderen Server. Am Ende ist aber vor allem die Datensicherheit und die Verfügbarkeit gegeben. Das zahlt sich immer aus, weil man so den Produktionsausfall verhindert.  

Welche Erkenntnisse ziehst du aus dem Projekt? 

Erst einmal: Kein Kunde ist gleich. Und was die Datensicherheit angeht, kann ich sagen, Murphys Gesetz kann überall zuschlagen. Es kann sogar eine stabil aufgesetzte Datenbank kaputt gehen. Deshalb ist eine Kombination aus guten Prüfmechanismen und mehreren Knoten die beste Lösung, um Datenverlust zu vermeiden.