Hochverfügbarkeit
Hochverfügbar dank intelligenter Algorithmen
Automatische Datenredundanz
Auf Softwareseite (EXACluster OS) werden Konzepte realisiert, die durch Redundanz die Ausfallsicherheit erhöhen (z.B. Abfangen von Festplattenlesefehlern durch Zugriff auf Redundanzdaten, Software-RAID o.ä.).
Der Redundanz-Level (Anzahl der Kopien inklusive Originale) des Systems ist frei wählbar. Das Erzeugen der Redundanzdaten geschieht während des Commits, das heißt abgeschlossene Transaktionen überdauern auch Knotenausfälle.
Für jede zusätzliche Redundanzkopie wird mindestens ein Knotenausfall kompensiert, bei Redundanz-Level 4 könnten z.B. wenigstens 3 Knoten gleichzeitig ausfallen, ohne die Datenintegrität zu gefährden.
Automatische Recovery
Falls ein Komponentenausfall durch lokale Redundanz nicht abgefangen werden kann, gilt der betroffene Knoten des Clusters als ausgefallen. Dasselbe trifft auf den Ausfall von Softwarekomponenten zu (z.B. Programm- oder Betriebssystemabsturz). Als Folge wird durch eine automatische Wiederherstellung (Recovery) das System selbständig binnen weniger Sekunden wieder zur Verfügung gestellt.
Gerade weil das EXASOL-Cluster aus sehr vielen Standardkomponenten besteht, müssen kritische Hardware-Ausfälle auf der Softwareebene abgefangen werden. Daher stehen für die automatische Recovery in der Regel einige Reserveknoten bereit, die bei Bedarf die Arbeit von ausgefallenen Knoten übernehmen.
Das System kompensiert ausgefallene Knoten und reorganisiert sich anschließend selbständig. Dabei werden die Daten des ausgefallenen Knotens im Hintergrund (während also das System schon wieder benutzbar ist) aus dem restlichen System automatisch wiederhergestellt. Eine höhere Priorisierung von Benutzeranfragen gewährleistet dabei, dass diese durch den Wiederherstellungsprozess nur wenig beeinträchtigt werden. Ermöglicht wird der Prozess durch die redundante Datenspeicherung, bei der alle Daten eines Knotens auch auf anderen Knoten mitgespeichert werden. Je nach definiertem Redundanz-Level kann ein sehr großer Teil des Clusters ausfallen, ohne die Wiederherstellbarkeit des Systems zu beeinträchtigen.
Durch den Ausfall gehen offene Transaktionen allerdings verloren, da die Daten im Hauptspeicher verloren gehen.
Restore (automatisch oder manuell)
Es kann Situationen geben, in denen das System nicht selbständig wiederhergestellt werden kann beziehungsweise in denen die Datenbank aus anderen Gründen in einen früheren Zustand versetzt werden muss. Dies ist z.B. der Fall, wenn zu viele Knoten des Clusters ausfallen, so dass die Redundanz nicht mehr ausreicht, oder wenn wichtige Daten aus Versehen gelöscht wurden. In solchen Fällen muss ein Backup eingespielt werden (Restore).
Da das EXASOL-Cluster über eine sehr große Menge an Festplattenkapazität verfügt, kann innerhalb des Clusters in der Regel eine Vielzahl von Backup-Versionen gespeichert werden. Diese lokalen Backups werden ebenso redundant im Cluster kopiert, so dass selbst bei einem Ausfall von mehreren Knoten meistens ein valides lokales Backup zur Verfügung steht. Ein Vorteil der lokal vorgehaltenen Backups ist die hohe Geschwindigkeit des Restore-Prozesses.
Der Backup-Prozess erfolgt im Hintergrund und ist transaktionssicher. Das System ist dadurch in der Lage, mehrmals am Tag ein Backup zu erzeugen, so dass der Datenverlust bei einem Ausfall minimal gehalten werden kann. Insgesamt beträgt die Kapazität je nach Datenbank- und Clustergröße ca. 10-20 lokale Backups.
Darüber hinaus ist es wichtig, dass selbst bei vollständigem Ausfall des Clusters (Desaster-Szenario) ein Backup zur Verfügung steht. Daher sollten Offline-Backups in regelmäßigen Abständen aus dem System extrahiert werden, wofür EXACluster OS entsprechende Services zur Verfügung stellt.
Katastrophenfall
Ein Offline-Backup zu haben, reicht allerdings in manchen Fällen nicht aus. Denn ein System komplett neu aufzusetzen, kostet in der Regel viel Zeit und beeinträchtigt damit geschäftskritische Prozesse erheblich.
Daher werden geschäftskritische Systeme oftmals auf zwei Rechenzentren aufgeteilt, so dass beim Eintritt eines Katastrophenfalls (Komplettausfall eines Rechenzentrums) die Arbeit binnen weniger Stunden im zweiten Rechenzentrum fortgesetzt werden kann.
EXASolution unterstützt eine Aufteilung auf zwei Rechenzentren, so dass im K-Fall die Arbeit ohne Verzögerung fortgesetzt werden kann. In einem solchen Fall kommen reguläre Failover-Mechanismen zum Einsatz.
Durch eine einfache Konfigurationseinstellung kann EXASolution Daten und Redundanz zwischen 2 Rechenzentren so verteilen, dass ein beliebiges Rechenzentrum komplett ausfallen kann. Jedes Rechenzentrum sollte dabei über eigene Standby-Knoten verfügen, damit einzelne Knotenausfälle rechenzentrumsintern behandelt werden können. Darüberhinaus muss die komplette Hardwarelandschaft dupliziert werden, damit im K-Fall genug Ersatzknoten bereit stehen und die Arbeit sofort fortgesetzt werden kann.
Wird ein Rechenzentrum als ausgefallen betrachtet, greift der Failover-Mechanismus ein:
Binnen weniger Sekunden kann die Arbeit wieder aufgenommen werden. Die Daten werden im Hintergrund aus den Redundanzen wiederhergestellt wie im Falle eines regulären Knotenausfalls.
Die oben beschriebene Konfiguration hat zum Vorteil, dass das System sowohl bei Knotenausfällen als auch bei einem Rechenzentrumausfall sofort wieder verfügbar ist, wobei keine manuellen Aktivitäten notwendig sind und keinerlei Datenverluste eintreten. Eine Herausforderung stellt dabei eine hoch performante Anbindung zwischen den beiden Rechenzentren dar. Durch die üblicherweise höheren Latenzzeiten kann es zu Performanceeinbußen im Vergleich zu rein lokalen Konfigurationen kommen.
Oft kann für einen K-Fall eine andere Konfiguration von Vorteil sein. In der Regel werden gerade operative Plattformen in einem zweiten Rechenzentrum gespiegelt. In diesem Fall kann durch komplette Duplizierung des Datawarehouses und der enstprechenden Ladeprozesse eine einfache und transparente Lösung entstehen.
Im K-Fall ist das System ebenfalls sofort verfügbar, wobei keine manuellen Aktivitäten vonnöten sind. In einer solchen Konfiguration entfällt die Anforderung der "starken" Leitung zwischen den Rechenzentren, gleichzeitig sind bei gleicher Hardwaremenge mehr Knoten aktiv, so dass im Normallfall durch einen Applicationserver die Last zwischen 2 Systemen verteilt werden kann. Allerdings gehen alle nicht durch zentrale Prozesse ertstellten Daten, wie zum Beispiel temporäre Nutzertabellen, im K-Fall verloren, wenn das zugehörige Rechenzentrum ausfällt.
