Über unsMediaKontaktImpressum
Ernst Leber 27. Februar 2018

Neuer Vortrag – Neues Lernen

oder: Wie baue ich einen Linux Cluster?

Wie jedes Jahr startet die "Saison" für Vorträge mit dem Call for Papers. Nach meinem Ausflug in die Postgres-Welt [1] war die Grundidee, in einem Vortrag meine Oracle-Welt mit Open Source zu verbinden. Dieser Artikel skizziert meine Vorbereitungen und Ausarbeitungen für meinen Vortrag "APEX (Hoch) Verfügbar" [2] den ich auf der DOAG-Konferenz 2017 halten durfte.

Themenfindung

Bei der Themenfindung spielen natürlich das Arbeitsumfeld und die persönlichen Präferenzen eine Rolle. Wer hält schon einen Vortrag über ein Thema, das ihn nicht interessiert? Ich betreue im Bereich Managed Services bei uns außer den zahlreichen Kundensystemen auch unsere APEX-Systeme. Gerade für diese APEX-Systeme wurde intern der Ruf nach Verfügbarkeit immer lauter. Ich habe mich daher entschlossen, die Problematik APEX und Hochverfügbarkeit näher zu betrachten. Damit war das Vortragsthema "Verfügbarkeit und APEX" gefunden.

Anforderungen

Bei dem Thema Verfügbarkeit gehen die Meinungen auseinander. Einerseits heißt es: nur ein System aus Primary- und Standby-Datenbank, auf zwei Rechenzentren verteilt, ist hoch verfügbar. Andererseits werden auch Cluster als Hochverfügbarkeitslösung angesehen.

Für den aktuellen Vortrag und um einen Praxisbezug zu haben, habe ich eine klassische Oracle Primary-Standby-Datenbank-Lösung mit Data Guard ausgeklammert, da hierfür eine Enterprise-Lizenz erforderlich ist, die den Kostenrahmen etlicher APEX-Anwendungen sprengen würde. Damit blieb als Basis für die Datenbank die Oracle Standard Edition 2 (SE2) oder die kostenfreie Oracle XE.

Vortragsinhalt

Für den Vortrag schwebte mir ein Vergleich mehrerer Verfügbarkeitslösungen vor. Mit Oracle RAC-Datenbanken und Oracle ASM haben wir sehr viel Erfahrung und können diese recht gut beurteilen. Daher waren die ersten Kandidaten für die Hochverfügbarkeit ein RAC Cluster und eine Lösung mit Oracle Restart und ASM. Für einen Vergleich etwas wenig, selbst wenn ich noch eine Oracle Cloud-Lösung mit in Betracht ziehe.

Wie oben schon erwähnt, lohnt es sich bei der Lösungsfindung über den Zaun zu schauen und ich wollte Open Source mit berücksichtigen. Als Gegenstück zum Oracle RAC Cluster könnte doch ein Open Source-Linux Cluster dienen! Es sollte möglich sein, in dem Vortrag einen Linux Cluster als Plattform für eine Datenbank mit der Oracle SE2 für die Hochverfügbarkeit in mehreren Varianten zu betrachten und diese Lösungen mit den bekannten Standards von Oracle zu vergleichen.

Einarbeitung und Lernen

Ich bin der festen Überzeugung, dass man nur dann über ein Thema reden sollte, wenn man fundierte Kenntnisse über die Materie hat. Ich brauchte also mehr Wissen über den Linux Cluster und musste zusätzlich zu den vorhandenen Kenntnissen noch lernen, wie ein solcher Linux Cluster erstellt und betrieben wird, bevor es daran gehen konnte, einen Vortrag zu entwickeln und einzureichen. Zusätzlich muss die benötigte Oracle-Datenbank in den Cluster integriert werden.

Aber wo und wie anfangen? Das APEX Know-how ist im Haus vorhanden. Die Linux-Kollegen waren natürlich auch eine große Hilfe. Nach einigem Suchen bin ich bei Clusterlabs [3] fündig geworden. Eine wahre Fundgrube für Linux Cluster auf Basis von Pacemaker und Corosync. Die Grundlagen des Clusters und Tutorials sind auf dieser Seite genauso zu finden, wie eine Step-by-Step-Anleitung zum "Clusterbau".

Nach gründlichem Einlesen und einer Einarbeitung hatte ich ein Konzept. Es sollte ein Zwei-Knoten-Cluster mit einer Aktiv-Passiv-Lösung für die Oracle-Datenbank werden. In der Praxis sollten die beiden Server räumlich getrennt sein. Bei dieser Lösung ist die APEX-Datenbank auf beiden Server installiert, aber nur auf einem Server geöffnet, also aktiv. Die in der Datenbank geänderten Daten werden automatisch auf den anderen – passiven – Server übertragen. Im Fehlerfall wird die passive Datenbank geöffnet und der kontinuierliche Betrieb ist mit einer kleinen Unterbrechung gewährleistet.

Für die Kommunikation wird noch eine virtuelle IP-Adresse als Applikations-VIP und pro Server ein Apache Tomcat benötigt. Die VIP wird im Fehlerfall vom Cluster automatisch auf den dann aktiven Server übertragen.

Die Praxis

Mit Hilfe der Erklärungen und der Anleitung [3] habe ich zunächst den Cluster bestehend aus zwei Servern gebaut und getestet. Basierend auf den dabei gemachten Erfahrungen habe ich dann den Cluster nochmal neu erstellt und Apache Tomcat als Aktiv- Passiv-Lösung eingebaut. Diese Integration ging recht einfach von statten.

Etwas schwieriger war die Integration von APEX. Hier sollte, wie oben erwähnt, eine Aktiv-Passiv-Lösung mit einem automatischen Datenabgleich zwischen den Servern installiert werden. Für diesen automatischen Datenabgleich gibt es unter Linux mehrere Lösungen, die durch einfaches Installieren in den Cluster integriert werden und problemlos laufen. Blieb die Frage offen, ob diese Lösungen mit APEX zusammen funktionieren.

Praxistests

Mit den gefundenen Lösungen habe ich Praxistests durchgeführt und Fehlerfälle simuliert, um ein Gefühl für die Betriebssicherheit zu bekommen. Meine Hauptanforderungen waren eine hohe Stabilität und gute Wartbarkeit des Systems. Im Sinne der Wartbarkeit habe ich das Neustartverhalten des Clusters mit allen Komponenten untersucht. Auch nach mehreren Neustarts mußte das System stabil und ohne Datenverlust laufen. War eines der Kriterien nicht erfüllt, habe ich die gefundene Lösung nicht weiter betrachtet.

Ein weiteres Ausschlusskriterium war das Verhalten und die Handhabung des Clusters im Fehlerfall. Wenn im Fehlerfall keine automatische Umschaltung möglich ist, sollte das Abarbeiten eines einfachen Drehbuchs ausreichen, um den Betrieb weiterzuführen. 

Die so erarbeiteten Linux Cluster-Lösungen, habe ich dann Oracle RAC, Oracle ASM mit Restart und einer Cloud gegenübergestellt und konnte damit ein Manuskript für den Vortrag erstellen. Im Rahmen dieser Arbeiten haben wir bei einem Kunden eine der Lösungen für die Verfügbarkeit einsetzen können und damit war auch der praktische Nutzen gegeben.

Fazit

Lernen ist keine Einbahnstraße und auch kein Selbstzweck! Nach dem Durcharbeiten und Verstehen bzw. Nachvollziehen des Tutorials fühlte ich mich gewappnet, ein Manuskript für meinen Vortrag zu schreiben. Parallel dazu konnte ich Ideen für die Umsetzung ausarbeiten und testen, so dass ich meine Kenntnisse in diesem Thema weiter vertiefen konnte. Der Vortrag wurde angenommen und auch die ersten Kunden zeigen Interesse. Mission erfüllt.

Quellen
  1. Informatik Aktuell – Ernst Leber: PostgreSQL als Datenbank-System
  2. Vortrag: APEX (Hoch) Verfügbar
  3. Clusterlabs: Erklärungen
    Clusterlabs: Anleitung

Autor

Ernst Leber

Ernst Leber ist seit 1985 in der IT tätig. Er ist als DBA bei der MT AG in Ratingen im Bereich Managed Services zuständig für Engineered Systems (ODA, EXADATA, PCA, …).
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210