Es sind drei SQL Anywhere-Server erforderlich, um Hochverfügbarkeit zur Verfügung zu stellen: ein Arbiterserver und zwei Partnerserver. Einem Partner ist die Rolle des Primärservers zugeordnet und der andere ist der Spiegelserver. Schreibvorgänge, wie etwa eine Einfügung in eine globale Tabelle, sind nur auf dem Primärserver zulässig, während Lesevorgänge, wie z.B. eine SELECT-Anweisung, auf beiden Servertypen zulässig sind. Der Primärserver hält seinen Spiegelserver automatisch synchronisiert, wenn er Aktualisierungen erhält. Im Fall eines Fehlers auf dem Primärserver übernimmt der Arbiterserver die Rollen der Partnerserver, sodass der Spiegelserver zum Primärserver wird.

Hochverfügbarkeit kann innerhalb einer Webdienstumgebung genutzt werden, indem alle HTTP-Anforderungen über einen Relay Server weitergeleitet werden. Der Relay Server verarbeitet die URL der HTTP-Anforderung, um die Ziel-Serverfarm zu ermitteln. Stellen Sie sich der Einfachheit halber eine Relay Server-Konfiguration vor, die HTTP-Anforderungen entweder an eine readFarm oder an eine writeFarm weiterleitet. Wenngleich der primäre Backend-Server sowohl Lese- als auch Schreibanforderungen verarbeiten kann, können Sie ihn so konfigurieren, dass er nur Schreibanforderungen verarbeitet, sofern noch andere schreibgeschützte Kopieknoten vorhanden sind, die die Lesefunktion im Fall eines Serverausfalls übernehmen können. Andernfalls können Sie ihn so konfigurieren, dass er sowohl Lese- als auch Schreibanforderungen verarbeitet. Sie können jedoch den Spiegelserver so konfigurieren, dass er Leseanforderungen verarbeitet und dadurch die Leselast verteilt wird, oder so, dass er keine Anforderungen verarbeitet und dadurch die Hardwarenutzung auf dem Spiegelserver reduziert wird. Die Clientanwendung benötigt keine Kenntnis des physischen Servers, auf den sie für Lese- und Schreibanforderungen zugreifen soll. Sie erstellt einfach ihre URL, um Anforderungen an die readFarm oder die writeFarm zu richten.

Zusätzlich zum Relay Server benötigt jeder Partner-Backend-Server zwei Outbound Enabler, einen für jede Farm, die der Backend-Server nutzt. Zwei Outbound Enabler steuern die Kommunikationskanäle mit dem Primärserver-Partner und zwei Outbound Enabler richten die Kommunikation mit dem Spiegelserver-Partner ein. In dieser Konfiguration gibt es zu jedem Zeitpunkt jeweils nur einen Primärserver. Er aktiviert den der writeFarm zugewiesenen Outbound Enabler und deaktiviert fakultativ den der readFarm zugewiesenen Outbound Enabler, sofern noch andere Mitglieder in der readFarm vorhanden sind, bei denen es sich nicht um Kopieknoten handelt. Der Spiegelserver deaktiviert den Outbound Enabler, der der writeFarm zugewiesen ist, und aktiviert fakultativ auch den Outbound Enabler, der der readFarm zugewiesen ist.

Wenn der Primärserver aufgrund eines Hardware- oder Softwarefehlers ausfällt, verhandelt der Spiegelserver mit dem Arbiterserver, um die Rolle des Primärservers zu übernehmen, und wird somit Mitglied der writeFarm. Er sollte auch Mitglied der readFarm werden, falls das System keine anderen schreibgeschützten Kopieknoten hat. Zum Zeitpunkt des Ausfalls wird der ursprüngliche Primärserver sofort sowohl von der writeFarm als auch von der readFarm zurückgenommen, sofern er ein Mitglied ist. Der ursprüngliche Primärserver kann erst wiederhergestellt werden, wenn die Ursache des Ausfalls behoben wurde. Wenn er wiederhergestellt wurde, übernimmt er die Rolle des Spiegelservers und wird fakultativ mit der readFarm verbunden. Der plötzliche Fehler führt möglicherweise dazu, dass aktuell vom ausfallenden Server bearbeitete Anforderungen falsch verarbeitet werden. Die Verarbeitungszeit für die writeFarm-Wiederherstellung anhand des Spiegelservers hängt von der Verarbeitungszeit für den Rollenwechsel des SQL Anywhere-Spiegelservers sowie vom Statusabrufintervall ab, das auf dem Outbound Enabler der writeFarm des Spiegelservers festgelegt wurde. Dieses Statusabrufintervall kann festgelegt werden. Wenn es nicht explizit festgelegt wird, beträgt sein Standardwert 5 Sekunden.

Es sind mindestens zwei SQL Anywhere-Server erforderlich, um die Scale-Out-Funktionalität zur Verfügung zu stellen: ein Stammknoten und ein Kopieknoten. Ein Kopieknoten ist wie ein Spiegelserver schreibgeschützt, er kann jedoch nie die Rolle des Primärservers übernehmen. Er dient ausschließlich zur Verarbeitung von Leseanforderungen. Wie bereits im Szenario mit Hochverfügbarkeit erläutert, wird der Primärserver der writeFarm zugewiesen und der Kopieknoten ersetzt den Spiegelserver als readFarm-Mitglied. Mit einem Stammknoten und einem einzigen Kopieknoten sind insgesamt nur zwei Outbound Enabler erforderlich, einer für jeden Server. Optional können Sie den Primärserver der readFarm hinzufügen, damit die Umgebung voll funktionsfähig bleibt, wenn alle Kopieknoten ausfallen. Der Outbound Enabler, der dem Stammknoten zugewiesen ist, ist für den Empfang von Anforderungen an die writeFarm konfiguriert, während der Outbound Enabler des Kopieknotens für die Entgegennahme von Anforderungen an die readFarm konfiguriert ist. Der Stammknoten aktualisiert seine Kopieknoten laufend, wenn er Schreibaktualisierungen erhält. Die Konfiguration kann durch das Hinzufügen von Kopieknoten zur readFarm erweitert werden. Die Ausführung von 10 Kopieknoten für die readFarm bietet Lastverteilung und fängt Serverausfälle innerhalb der readFarm auf.

Die oben beschriebenen Konfigurationsszenarien können kombiniert werden, um sowohl Hochverfügbarkeit als auch Scale-Out zur Verfügung zu stellen. Eine solche Konfiguration würde Fehlertoleranz für beschreibbare (Primär-/Spiegelserver) und lesbare (Spiegelserver und Kopieknoten) Backend-Server bereitstellen. Außerdem erhöht das Hinzufügen von Kopieknoten das Durchsatzpotenzial für schreibgeschützte HTTP-Anforderungen. In dieser Konfiguration bilden der Primär- und der Spiegelserver den Stammknoten. Der Primär- und der Spiegelserver und die Kopieknoten haben jeweils einen Outbound Enabler zur Teilnahme an der readFarm. Der Primär- und der Spiegelserver haben einen zusätzlichen Outbound Enabler zur Teilnahme an der writeFarm. Optional können Sie den Primär- und den Spiegelserver aus der readFarm entfernen.

Im Rahmen dieser Erläuterung muss ein Outbound Enabler so konfiguriert sein, dass er folgende Objekte identifizieren kann:

Mit dem folgenden Befehl richtet der Outbound Enabler eine Verbindung mit dem Relay Server ein, die auf durch die Option -cr angegebenen Parametern basiert. Wenn sie aktiv ist, leitet der Relay Server Anforderungen an die readFarm an den Backend-Server weiter, der entsprechend der Option -cs Option konfiguriert ist.

rsoe.exe -f readFarm -id saHost1 -cr url_suffix="/rs/server/rs_server.dll";host=rs_server;port=80 -cs host=sahost1;port=8080;status_url=/satest/oe_read_status?ro=1

Basierend auf dem obigen Beispiel leitet eine Anforderungs-URL der Form http://rs_server/rs/client/rs_client.dll/readFarm/service_path[?service_query]

die Anforderung an den Relay Server weiter, der auf rs_server gehostet wird. Der Relay Server entfernt die Domänen- und Farm-Komponente aus der URL und leitet die Anforderung über den Outbound Enabler-Kanal des Relay Servers an einen aktiven Outbound Enabler weiter. Der Outbound Enabler leitet die Anforderung dann an seinen Backend-Server weiter.

Ein Outbound Enabler behält einen Kanal zum Relay Server nur bei, wenn er erkennt, dass der Backend-Server für die Verarbeitung von Anforderungen bereit ist. Hierzu fragt er den Server in einem konfigurierbaren Intervall ab, indem er eine HTTP-Anforderung mit der Option -cs verwendet. Die status_url-Option liefert den betreffenden URL-Pfad für den Ping-Dienst. In der obigen Beispielkonfiguration sendet der Outbound Enabler HTTP-Anforderungen an http://sahost1:8080/satest/oe_read_status?ro=1. Wenn der Server mit AVAILABLE=TRUE | ON | 1 antwortet, behält der Outbound Enabler die Kommunikationsverbindung mit dem Relay Server bei, der auf rs_server gehostet wird, oder initiiert diese.

Weitere Hinweise zum Konfigurieren und Starten von SQL Anywhere als Webserver finden Sie unter SQL Anywhere als HTTP-Webserver.

Unter Verwendung des RSOE-Startbeispiels (Relay Server Outbound Enabler), das im Abschnitt zur Outbound Enabler-Konfiguration beschrieben ist, kann ein oe_read_status-Dienst wie folgt geschrieben werden:

// READ-ONLY SA-OE ping service
//  optionally includes primary as a READ node.
call sa_make_object( 'service', 'oe_read_status' );
alter service oe_read_status
    type 'raw'
    authorization off
    secure off
    user DBA
    as call sp_oe_read_status(:ro);

// if ro is 1 then only read-only servers are activated: mirror or copy
// if ro is 0 then include all servers: primary, mirror, copy...
create or replace procedure sp_oe_read_status( ro int )
begin
    declare readonly long varchar;
    declare res long varchar;

    set res = 'AVAILABLE=';

    set ro = isnull(ro, 0);
    if ro = 1 then
         select db_property('ReadOnly') into readonly;
          if readonly = 'On' then
               set res = res || 'TRUE';
          else
               set res = res || 'FALSE';
           end if;
    end if;;

    call sa_set_http_header('Content-Length', length(res) );
    select res;
end;

Der oben beschriebene Webdienst und die gespeicherte Prozedur können für alle SQL Anywhere-Server verwendet werden, die die Rolle eines Primär- oder Spiegelservers oder eines Kopieknotens haben. Wenn die ReadOnly-Datenbankeigenschaft auf "On" gesetzt ist, wird AVAILABLE=TRUE zurückgegeben. Bei kleinen Änderungen würde ein Dienst für die Verwendung in einer beschreibbaren Serverfarm, zum Beispiel writeFarm, nur dann AVAILABLE=TRUE zurückgeben, wenn die ReadOnly-Datenbankeigenschaft auf "Off" gesetzt ist. Optional kann ein Ping-Dienst für einen Outbound Enabler seine Einstellung für AVAILABILITY auf andere Faktoren basieren, wie etwa einen Eintrag in einer globalen Tabelle. Zum Beispiel kann ein stufenweises Deployment eine Tabelle oder Prozedur auf dem Primärserver aktualisieren, der die Serverfarm-Mitgliedschaft jedes Servers aktiviert oder deaktiviert, wenn die Aktualisierung an den Spiegelserver oder den Kopieknoten übergeben wird.

So konfigurieren Sie den Relay Server:

• Einführung in den Relay Server
• Relay Server-Konfigurationsdatei
• Konfigurationsaktualisierungen für die Relay Server-Farm
• Eigenschaften im Backend-Farm-Abschnitt