Um unsere Infrastruktur zu vereinfachen, migrierten wir im Mai 2017 unser eigenes PostgreSQL Datenbank-Cluster bei Global Access von einem dedizierten Server auf eine virtuelle Maschine (VM), die auf Basis unserer Enterprise Advanced Infratructure (IaaS) läuft. Die dazugehörige Anwendung verarbeitet die Abrechnungsdaten unserer Kunden und ist damit für unser Unternehmen überlebenswichtig. Die Herausforderung daran: Eben diese Anwendung ist das, was wir eine „klassische App“ nennen.
Weil wir an unseren Systemen nichts ändern wollten, außer wenn es wirklich notwendig wird, hatten wir die Datenbank auf einem physischen Server belassen. Außerdem waren wir bis vor kurzem davon überzeugt, dass virtuelle Maschinen nicht in der Lage seien, die benötigte Rechenleistung zu liefern – in diesem Fall täglich 1.602.024 Zeilen in der Datenbank zu aktualisieren. Wie sich bei der Analyse der Kapazitäten virtueller Maschinen herausstellte, lagen wir damit (inzwischen) vollkommen falsch.
Die ursprünglich aufgesetzte Datenbank
Unsere Datenbank lief auf einem Server mit gespiegelten SSD-Platten, um für unsere Abrechnungen superschnell über 10.000.000 Zeilen auslesen zu können. Die Datenbank wurde auf eine virtuelle Maschine synchronisiert, die in unserer Cloud lief. Als wir im Jahr 2010 das System einrichteten, ergaben unsere Tests, dass diese VM langsamer war, als der dedizierte Server. Deswegen nutzten wir die Cloud-Lösung nur, um die Folgen etwaiger Hardwarefehler des besagten Servers abzumildern. Glücklicher Weise kam es nie zu einem solchen Fall. Der Server blieb hunderte Tage lang online und wurde lediglich für Kernel- und Sicherheitsupdates neugestartet.
Die Entscheidung für den Umzug in die Cloud
Wenn man – wie in unserem Fall – eine dedizierte Hardwarekomponente in einer nahezu vollständig virtualisierten Umgebung verwendet, erfordert dies spezielle Kenntnisse, um eben diesen einen Server zu managen. Nun arbeitet unser Team aber zum Teil von verschiedenen Standorten aus. Problematisch daran war, dass wir deswegen immer sicherstellen mussten, dass jemand mit eben diesem Wissen vor Ort in dem entsprechenden Rechenzentrum war, falls es Probleme geben sollte.
Auch lag uns schwer im Magen, dass wir bei einem Ausfall des Servers doch einige Zeit benötigen würden, bis wir es erstens bemerken und zweitens bis wir die Prozesse auf die VM umgeleitet hätten, auf welche die Daten des dedizierten Servers gespiegelt wurden. Und – um ehrlich zu sein – gelang es uns nie wirklich, dass die VM genauso funktionierte, wir der primäre Server. Es handelte sich letztlich nur um eine Kopie der Daten.
Bei einem kürzlichen Test der Performance unserer virtuellen Maschine stellten wir überrascht fest, dass alle Abfragen unserer Software auf der VM schneller liefen, als auf dem Server. Die der virtualisierten Infrastruktur zugrundeliegende Hardware hat sich in den letzten Jahren derart verbessert, dass sie unsere Anforderungen mehr als erfüllte.
Damit war die Entscheidung gefallen, auf Infrastructure as a Service zu wechseln. Dadurch konnten wir wiederum die Einrichtung unserer App vereinfachen, denn eine gesonderte Replikation war nicht mehr von Nöten – das regelt die virtuelle Infrastruktur von selbst.
Die Ergebnisse der Virtualisierung
Datenverlust zu verhindern ist nun viel einfacher
Das frühere Kopieren unserer Datenbank war vor allem notwendig gewesen, um die Daten im Falle eines Zusammenbruchs des Servers wiederherstellen zu können. Dieser Prozess hätte einige Zeit in Anspruch genommen, aber es wäre keine kritische Datenmenge verloren gegangen.
Mit der Enterprise Advanced Cloud werden nun alle Daten automatisch und in Echtzeit über zwei Rechenzentren synchronisiert. Selbst beim vollständigen Stromausfall oder einem Brand in einem der Rechenzentren wären alle Daten noch vorhanden.
Darüber hinaus ist die Spiegelung der virtuellen Maschinen absolut identisch und nachvollziehbar. Es gibt also keinerlei Notwendigkeit mehr, dass eine VM die Einstellungen einer anderen nachahmt. In unseren Tests schalteten wir bei Wartungen das gesamte Speichersystem eines Rechenzentrums ab. Bei den Abfragen der Datenbank konnten wir dabei keinerlei Einfluss auf die Verarbeitungsgeschwindigkeit feststellen, wenn die Daten von „der anderen Seite“ kamen.
Die Zeitspanne bis zur Widerherstellung ist extrem kurz
Bis dato war es so, dass zwei verschiedene Server parallel liefen. Wäre einer ausgefallen, hätten wir mühsam alle Vorgänge dem anderen zuweisen müssen, was etwa die manuelle Änderung von IP-Adressen und ausführliche Tests der neuen Konfiguration bedeutet hätte. Zwischenfälle in der Nacht wären so recht problematisch geworden.
Auf dem jetzigen Hochverfügbarkeits-Cluster kann die VM auf demselben System mit denselben Netzwerk-, Hardware- und Software-Einstellungen und natürlich denselben Daten neustarten. Es würde länger dauern, einen Techniker zu alarmieren nachdem wir einen Fehler bemerkt haben, als die virtuelle Maschine braucht, um neu zu starten und wieder Abfragen zu verarbeiten.
Incremental Backup ist immer noch notwendig
Eine Sache hat sich im Verhältnis zur früheren Einrichtung auf dem dedizierten Server nicht geändert: Wir führen mittels pgbackrest immer noch regelmäßige Backups durch. Und zwar für den sehr unwahrscheinlichen Fall, dass jemand aus Versehen den Befehl „delete * from users;“ anstelle von „select * from users;“ durchführen würde. Allerdings ist dies wirklich sehr unwahrscheinlich, da unsere Software sehr weit entwickelt ist und umfassenden automatisierten Tests unterzogen wurde.
Sie wollen Ihre Infrastruktur virtualisieren, aber Ihre Software wurde überhaupt nicht für die Cloud entwickelt? Wir helfen Ihnen gerne bei diesem Quantensprung!
Die Probleme klassischer Apps Die Lösung per Enterprise Advanced Cloud
