Essbase-Server in einem Failover-Cluster konfigurieren

Active/Passive-Failover-Lösungen sind in Essbase 11g On-Premise-Deployments üblich. Benutzer, die zu Essbase 26ai migrieren, können auch Active/Passive-Failover-Cluster für Essbase Agent mit WebLogic und einem Load Balancer implementieren.

Beim Konfigurieren des Essbase-Failovers gilt Folgendes:
  • Failover-Modus (oder Active/Passive-Modus) für den Essbase Agent einrichten.
  • Aktiv/Aktiv-Modus für Essbase-Weboberfläche, REST-Endpunkte und Provider-Services einrichten. Diese stellen immer eine Verbindung zum einzelnen aktiven Essbase-Knoten her.

Ein aktiv-passives Essbase-Cluster besteht aus zwei oder mehr Essbase-Instanzen, eine auf jedem Knoten, die einen gemeinsamen Speicher für Konfiguration und Daten verwenden. Der Speicher wird auf zwei oder mehr Servern gemeinsam genutzt (z. B. mit einem SAN). Dadurch entfällt die Notwendigkeit, dass der Administrator den Speicher synchronisiert, sowie die Einschränkung der schreibgeschützten Unterstützung. Essbase verwendet Datenbanktabellen, um sicherzustellen, dass nur ein Agent und die zugehörigen Server aktiv sind, um Datenbeschädigungen bei Schreibvorgängen zu vermeiden. Während der Installation und Konfiguration wird eine Tabelle erstellt, in der Informationen zu Konfiguration und Anwendungsdaten im Cluster gespeichert werden.

Compared to Essbase 11g On-Premise, where Essbase failover is managed by an external agent (OPMN), in Essbase 26ai, the WebLogic architecture supports Essbase failover with a central request leasing system. Die Essbase-Instanz, die das Leasing abruft, wird zum aktiven Knoten. Andere Knoten warten in einer Schleife und versuchen, das Leasing zu erwerben.

Installationsart Komponente Essbase 11.1.2.4 Essbase 26ai
Einzelknoten Providerservices
  • Provider Services wird auf einem einzelnen Managed Server ausgeführt, der immer aktiv ist.
  • Wenn ein Fehler auftritt, startet WebLogic Node Manager den Managed Server neu.
Identisch mit 11.1.2.4
- Essbase-Agent
  • Einzelinstanz des Essbase Agent-Prozesses.
  • Wenn ein Fehler auftritt, startet OPMN die Agent-Instanz auf demselben Knoten neu.
  • Essbase Java Agent wird auf einem einzelnen Managed Server ausgeführt, der als aktiver Knoten betrachtet wird.
  • Wenn der Managed Server ausfällt, startet Node Manager den Managed Server neu.
- Essbase-Anwendungsserver. Wenn der Essbase-Anwendungsserver nicht erfolgreich ist, startet der Essbase-Agent ihn bei der nächsten Serveranforderung neu. Identisch mit 11.1.2.4.
Multi-Knoten (aktiv/passiv) Providerservices
  • Provider Services wird mit jedem Knoten im Cluster bereitgestellt.
  • Alle Managed Server sind gleichzeitig hochgefahren und gestartet.
  • Provider Services können Sessions nicht über die Knoten hinweg gemeinsam verwenden.
Identisch mit 11.1.2.4.
- Essbase-Agent
  • Nur Failover-Unterstützung; keine Load Balancing-Unterstützung für Essbase.
  • Essbase-Lebenszyklus wird von OPMN verwaltet.
  • Von OPMN verwaltete Active/Passive-Lösung.
  • Shared ARBORPATH (NFS) oder Block Storage, der von OPMN gemountet bzw. ausgehängt wurde.
  • Wenn Essbase, das im aktiven Knoten ausgeführt wird, nicht erreichbar ist (OPMNPing), startet OPMN Essbase auf einem anderen Knoten neu.
  • Die neu gestartete Essbase-Instanz aktualisiert die Leasing-Tabellen mit den zugehörigen Hostdetails.
  • Vorhandene Essbase-Anwendungen, die im vorherigen Knoten ausgeführt wurden, werden entladen. Bis der Entladevorgang abgeschlossen ist, kann der Agent auf dem neuen Knoten diese Anwendungen nicht starten.
  • Wenn ein neuer ESSBASE-Prozess auf einem anderen Knoten gestartet wird, kann die Ausfallzeit einige Sekunden nach AGENTLEASEEXPIRATIONTIME Sekunden betragen.
  • OPMN führt den Befehl zum Aushängen des Blockspeichers auf dem vorherigen aktiven Knoten (wenn der Knoten aktiv ist) und den Mountbefehl auf dem aktuellen aktiven Knoten aus.
  • Nur Failover-Unterstützung; keine Load Balancing-Unterstützung für Essbase.
  • Der Essbase-Lebenszyklus wird von WebLogic verwaltet, und Node Manager verwaltet alle WebLogic-Instanzen.
  • Selbstverwaltete Aktiv-Passiv-Lösung.
  • Gemeinsames Essbase-Anwendungsverzeichnis (früher ARBORPATH) (NFS) + gemeinsame relationale Datenbank für gemeinsam verwendetes Essbase.
  • Essbase Java Agent wird auf demselben Managed Server wie Provider Services auf allen aktiven Knoten bereitgestellt. Essbase Java Agent-Instanzen verwenden einen Leasingalgorithmus, um sicherzustellen, dass jeweils nur ein Knoten ausgeführt wird. Obwohl Essbase Java Agent in allen Knoten hochgefahren und gestartet ist, ist nur einer von ihnen für die Wartung verfügbar. Die restlichen Essbase Java Agent-Instanzen bleiben im Standbymodus und horchen nicht auf Essbase-Anforderungen.
  • Wenn der aktive Knoten das Leasing nicht erneuern kann, wird eine andere Essbase Java Agent-Instanz von einem passiven Knoten aktiviert.
  • Das neu gestartete Essbase aktualisiert die Leasing-Tabellen mit den zugehörigen Hostdetails.
  • Vorhandene Essbase-Anwendungen, die im vorherigen Knoten ausgeführt wurden, werden entladen. Bis der Entladevorgang abgeschlossen ist, ist der Agent auf dem neuen Knoten nicht für den Service verfügbar.
  • Wenn ein Failover erfolgt, übernimmt die neue Essbase Java Agent-Instanz sofort nach AGENTLEASEEXPIRATIONTIME Sekunden.
  • Essbase Java Agent (innerhalb von WebLogic) führt den Befehl zum Aushängen des Blockspeichers auf dem vorherigen aktiven Knoten aus (wenn der Knoten aktiv ist und ein ordnungsgemäßes Leasingrelease war) und den Mountbefehl auf dem aktuellen aktiven Knoten.
- Essbase-Anwendungsserver
  • Wird im selben System neu gestartet, wenn ein Fehler auftritt.
  • Wenn der Essbase Agent nicht erfolgreich ist oder gestoppt wird, werden die Server heruntergefahren. Bis das Herunterfahren abgeschlossen ist, können dieselben Anwendungen nicht auf dem neuen aktiven Knoten gestartet werden.
  • Essbase-Serverprozesse verwenden Leasing-Tabellen.
Identisch mit 11.1.2.4, außer beim Leasing auf Serverebene.