IBM Informix Dynamic Server Version 11 (Teil IV)

Shared Disc Secondary (SDS)

Nachdem wir im letzten Teil dieser Reihe [3] bereits einige Hochverfügbarkeitslösungen der Version 11.10 vorgestellt haben, befassen wir uns in diesem Artikel intensiver mit der neuen Hochverfügbarkeitstechnologie Shared Disc Secondary (SDS), die ebenfalls seit der Informix Dynamic Server Version 11 zur Verfügung steht.

Hochverfügbarkeitslösungen mit Informix Version 11

Der Glanzpunkt der Neuheiten in Informix 11 sind die unter dem Codenamen MACH 11 (Multinode Active Cluster for High availability) integrierten Hochverfügbarkeitstechnologien.

Die direkt im Informix Kernel integrierten Hochverfügbarkeitslösungen umfassen eine ganze Reihe an Optionen, um die Verfügbarkeit und Ausfallsicherheit zu verbessern.

Folgende Funktionalitäten sind in beliebiger Kombination möglich:

• HDR (High Availability Data Replication): 1:1-Primary-/Secondary-Replikation mit automatisiertem Failover und Lese-Zugriff auf den Secondary Server.
• RSS (Remote Standalone Secondary): 1:nPrimary-/ Secondary-Replikation mit Lese-Zugriff auf den Secondary Server.
• SDS (Shared Disc Secondary): Die sekundären SDS-Server laufen auf separaten Rechnern, verfügen über eigene Bufferpools, halten jedoch keine lokale Kopie der Daten vor, sondern greifen lesend und schreibend direkt auf die Plattenbereiche der primären Instanz zu.
• ER (Enterprise Replication): Mit der Enterprise Replikation können alle an der Replikation teilnehmenden Datenbank-Server Änderungen an den Daten vornehmen und diese replizieren.

Einrichten eines SD-Secondary Servers Einfügen aller beteiligten SD-Server in die sqlhosts-Datei Anpassen der Konfigurationsdatei ($ONCONFIG) Folgende Parameter müssen mit dem primären DB-Server identisch sein: ROOTNAME ROOTPATH ROOTOFFSET ROOTSIZE PHYSDBS PHYSFILE LOGFILES LOGSIZE Folgende SDS-Konfigurationsparameter müssen aktiviert werden: SDS_PAGING = Definition von zwei Files für Buffer Paging SDS_TEMPDBS = Angabe eines temporären Datenbank-Spaces für diese Instanz SDS_ENABLE 1 = (0 = deaktiviert, 1 = aktiviert) SDS SDS_TIMEOUT 20 = Zeitangabe, wie lange der Secondary auf Antwort wartet Abb. 1: Konfigurationsparameter zur Initialisierung eines SDS-Servers. Abb. 2: Beispielkonfiguration einer Shared Disc Secondary (SDS) Umgebung. Abb. 3: Darstellung eines möglichen IDS-Clusters mit Verbindungsaufbau über den Connection Manager. FOC sds1+hdrs1+SDS,20 (Standard Policy SDS+HDR+RSS,0) Abb. 4: Beispiel.

Shared Disc Secondary (SDS)

SDS steht für Shared Disc Secondary und bedeutet, dass alle beteiligten Datenbank Server innerhalb eines Cluster-Verbundes auf einen gemeinsamen Datenpool lesend und schreibend zugreifen können.

Alle sekundären SDS-Instanzen laufen auf separaten Rechnern, verfügen über einen eigenen Bufferpool sowie über lokale temporäre Datenbank-Spaces, besitzen jedoch keine lokale Datenhaltung, sondern greifen direkt auf die gemeinsam genutzten Plattenbereiche der primären Instanz zu (z. B. im Rahmen einer SAN-Lösung).

Voraussetzung dafür ist, dass alle im Cluster-Verbund beteiligten Server über ein TCP/IP-Netzwerk direkt verbunden sind, ansonsten ist kein zusätzliches Hilfsmittel notwendig. Auch gibt es keinerlei Einschränkung, was die Entfernung der im Verbund teilnehmenden Datenbank-Server betrifft, solange diese auf die Platten zugreifen können.

Eine neue SDS-Instanz kann innerhalb weniger Minuten konfiguriert und gestartet werden. Im Fehlerfall kann eine SDS-Instanz in kürzester Zeit in eine primäre Instanz umgewandelt werden.

Initialisierung eines SDS-Knoten

Ein physikalischer Restore eines SDS-Datenbank-Servers entfällt, da nach der erfolreichen Initialisierung eines sekundären Datenbank-Servers direkt auf die Daten des primären Knoten zugegriffen wird. Damit ist es möglich, im Bedarfsfall innerhalb kürzester Zeit einen sekundären SDS-Server aufzusetzen (siehe Abbildung 1).

Bei der Konfiguration ist zu beachten, dass bestimmte Parameter mit denen vom Primärknoten identisch sein müssen, einige andere Parameter müssen dagegen zusätzlich angepasst werden.

Bevor man den SDS-Knoten initialisieren kann, muss diesem der Name des primären Datenbank-Servers einmalig bekannt gemacht werden. Dies erfolgt mit dem Dienstprogramm onmode.

onmode -d set SDS primary Name (DBSERVERALIASNAME)

Nach der erfolgreichen Ausführung des onmode-Befehles werden vom Datenbank-Server folgende Aktionen automatisch ausgeführt:

• Erstellung einer neuen Systemdatenbank mit dem Namen sysha. Diese Aktion wird, wie bei Informix üblich, im Message Logfile mitprotokolliert. In der neuen sysha-Datenbank werden Informationen über die an der SDS-Umgebung teilnehmenden SDS-Knoten hinterlegt. Dabei werden die wichtigsten Informationen, wie z. B. SDS-Knotennamen oder Verbindungsinformationen, in eine Tabelle namens sds_tab eingefügt.
• Danach wird der SDS-Knoten mit dem üblichen Informix Startbefehl oninit gestartet. Dabei werden die lokalen temporären Datenbank-Spaces und der Buffer pool initialisiert und mit dem primären Datenbank-Server synchronisiert.

Redirected Writes / Updatable_Secondary

Eine wichtige Funktionalität bei der Version 11.10 fehlte bisher, nämlich der schreibende Zugriff der SDS-Knoten auf den gemeinsam genutzten Datenpool. Diese Erweiterung bietet IBM nun mit dem Informix Dymamic Server ab der Version 11.50 an.

Applikationen können jetzt auf sekundären Datenbank-Servern mittels umgeleiteter Schreibvorgänge, die IBM "Redirected Writes" nennt, Daten modifizieren. Aus Sicht der Anwendung stellt es sich so dar, als würde die Aktualisierung der Daten auf dem sekundären Datenbank-Server stattfinden.

Im Hintergrund werden allerdings die Transaktionen auf dem primären Datenbank-Server übermittelt, der die eigentlichen schreibenden Aktivitäten ausführt. Bisher werden alle DML-Operationen wie INSERT, DELETE und UPDATE unterstützt. Alle Kommandos, die eine Änderung der Tabellenstruktur zur Folge haben, können nur auf dem primären Datenbank-Server ausgeführt werden.

Der Vorteil dieser Technologie ist, dass es bei einem Ausfall des primären Datenbank-Servers ohne Unterbrechung möglich ist, einen der bisherigen sekundären Knoten problemlos als primären zu definieren.

Diese umgeleiteten Schreibaktivitäten sind standardmäßig nicht aktiv. Sie werden durch das Setzen des Konfigurationsparameters UPDATEABLE_SECONDARY aktiviert. Dabei werden Hintergrundprozesse (SMX-Prozesse) für eine leistungsfähige Kommunikation zwischen SDS- und primären Knoten zur Verfügung gestellt (siehe Abbildung 2).

Server Multiplexer Kommunikation

Speziell für Hochverfügbarkeitslösungen wurde ein neuer Kommunikationsmechanismus mit Informix 11 eingeführt. SDS verwendet nun das neue Kommunikations-Interface SMX, das multiplexed-Netzwerk-Verbindungen unterstützt.

Das Protokoll arbeitet im Modus Full Duplex. Damit ist auch gewährleistet, dass in beide Richtungen ungehindert Daten übertragen werden können.

Durch das Aktivieren des Konfigurationsparameters UPDATEABLE_SECONDARY wird eine definierte Anzahl von SMX-Prozessen zur Kommunikationsbearbeitung gestartet.

Bei Bedarf kann man für sicherheitsrelevante Anforderungen eine Datenübertragung mit dem Parameter ENCRYT_SMX = 1 verschlüsseln.

Connection Manager (Online Connection Manager and Server Monitor)

Der Connection Manager ist ab der Version 3.50 Bestandteil im Client Software Development Paket (CSDK). Aufgabe des Programms ist es, Client-Anwendungen bei der Herstellung einer Datenbankverbindung an einen Datenbank-Server weiterzuleiten, der zu diesem Zeitpunkt das geringste Lastaufkommen hat. Eine zweite wichtige Funktion ist, die Überwachung aller teilnehmenden Datenbank-Server im Cluster auf Verfügbarkeit und im Fehlerfall eine automatisierte Funktionsübernahme innerhalb der Datenbank-Server einzuleiten.

Um dieser Aufgabe gerecht zu werden, übernimmt der Connection Manager das Monitoring für alle im Hochverfügbarkeits-Cluster verfügbaren Datenbank-Server, wie zum Beispiel die aktuelle Auslastung und den Status der einzelnen Datenbank-Server.

Applikationen verbinden sich nicht mehr direkt mit einem Datenbank-Server, sondern mit dem Connection Manager. Dieser stellt den Verbindungsaufbau anhand der Monitoring-Informationen und definierten Service Level Agreements (SLA), die im Konfigurationsfile $INFORMIXDIR/etc/cmsm.cfg hinterlegt sind, zu dem am besten geeigneten Knotenrechner im IDS-Cluster her. Voraussetzung für die Kommunikation von der Applikation und dem Connection Manager ist der Einsatz des CSDK-Paketes ab der Version 3.50.

Jegliche weitere Kommunikation findet dann nur noch zwischen dem Client und dem SDS-Knoten statt. Bei Ausfall des Connection Managers kann so die Applikation ohne Einschränkung weiterarbeiten.

Zum Starten des Connection Managers wird das Dienstprogramm oncmsm verwendet. Das Programm oncmsm wird beim Start automatisch als Dämonprozess im Hintergrund gestartet.

oncmsm oder oncmsm -c $INFORMIXDIR/etc/cmsm_Konfigurationsfile

Idealerweise installiert man mehrere Connection Manager auf verteilten Rechnern, was eine horizontale Skalierung der Verbindungsmöglichkeiten für die Applikation zur Folge hat, aber auch eine redundante Auslegung der Systeme, um somit eine einzelne Fehlerquelle auszuschließen (siehe Abbildung 3).

Automatischer Failover (Arbitrator)

Darüber hinaus bietet der Connection Manager die Möglichkeit, durch das Setzen eines Failover-Parameters im Konfigurationsfile, einen automatischen Wechsel des primären Datenbank-Servers zu hinterlegen.

Durch den in der Konfigurationsdatei enthaltene Parameter FOC (Fail-Over Configuration) wird dem Connection Manager mitgeteilt, in welcher Reihenfolge, bei einem Ausfall des primären Datenbank-Servers, die sekundären Datenbank-Server die Rolle des bisherigen primären Servers übernehmen sollen. Will man diese Funktion nicht aktivieren, muss explizit durch das Setzen des Parameters FOC disable im Konfigurationsfile diese Möglichkeit deaktiviert werden.

In Abbildung 4 wird ein Beispiel gezeigt, in dem Folgendes gilt: Falls der Connection Manager innerhalb von 20 Sekunden nicht ermitteln kann, ob der aktuelle primäre Datenbank-Server online ist, wird die Funktionsübernahme gestartet.

Der Connection Manager versucht dann anhand der Parameter-Reihenfolge zuerst den Datenbank-Server sds1 in einen primären Datenbank-Server zu konvertieren. Ist dies nicht möglich, wird die Policy weiterverarbeitet und zuerst der Datenbank-Server hdrs1 angesprochen. Falls keiner der bisherigen Knoten sich erfolgreich ansprechen lassen konnte, wird zum Schluss versucht, anhand vorliegender statistischer Werte, den günstigsten SD-Sekundärserver im Cluster-Verbund in den primären Server zu konvertieren.

onpassword

Für den Zugriff auf die einzelnen Cluster-Knoten benötigt der Connection Manager die Kenntnis über das Passwort des Benutzers "Informix". Dieses kann man in einer Datei hinterlegen und mit dem im CSDK-Paket mitgelieferten Dienstprogramm onpassword verschlüsseln.

Besonderheiten

Wird der primäre Datenbank-Server gestoppt, bleiben alle SDS-Secondary-Knoten im Readonly Modus. Obwohl der Primary Server heruntergefahren wurde, kann der Secondary Server lesend auf die Daten zugreifen!

Erst beim Neustart des primären Datenbank-Servers verliert der Secondary SDS-Server endgültig die Verbindung und stoppt automatisch den Datenbank-Server. Danach benötigen alle SDS-Server einen Neustart.

Fazit

Für wichtige unternehmenskritische Anwendungen werden sowohl eine hohe Verfügbarkeit sowie ausreichend Performance gefordert. Beides kann man durch die Implementierung von Shared Disc Secondary gewährleisten.

Die neue Shared Disc Secondary Technologie ist wie von Informix gewohnt, einfach aufzusetzen und zu administrieren. Im Bedarfsfall ist eine Erweiterung der bestehenden Architektur durch Hinzufügen neuer Secondary Server jederzeit ohne großen Aufwand möglich.

Durch den Einsatz des Connection Managers ist es möglich, eine Lastverteilung der Applikation vorzunehmen. Gleichzeitig besteht die Möglichkeit, einen automatisierten Failover bei Ausfall des Primary Datenbank-Servers zu definieren.

IBM hat durch die ständige Weiterentwicklung des Informix Dynamic Servers bewiesen, dass die Produktlinie inzwischen als strategisches Produkt etabliert ist.

Die bereits teilweise veröffentlichten Ankündigungen der nächsten technischen Erweiterungen (z. B. Datenkompression) in das Produkt, sind ein weiteres Indiz dafür, welchen Stellenwert Informix zwischenzeitlich innerhalb IBM besitzt.

Manfred Stöb (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen