Der Lizenzserver unterstützt globale Instanzen des Control Rooms mit hoher Verfügbarkeit und Funktionen zur Notfallwiederherstellung. Regelmäßige Zustandsprüfungen der Anwendungen lösen Failover-Prozesse aus, um die Kontinuität des Dienstes aufrechtzuerhalten.

License Server (LS) wird zentral in den USA gehostet. Alle Instanzen des Control Rooms weltweit, die eine GUID-basierte Lizenz oder eine Cloud-Lizenz verwenden, verbinden sich mit diesem Server. Da es sich um einen kritischen Dienst handelt, verfügt der Lizenzserver über Hochverfügbarkeit und Fähigkeiten zur Notfallwiederherstellung. Das untenstehende Diagramm zeigt den detaillierten Aufbau auf Infrastrukturebene. Weitere Informationen zur Cloud-Lizenz finden Sie unter Häufig gestellte Fragen zur Cloud-Lizenzierung.

Betrachten Sie zwei Regionen: Oregon (primär) und Virginia (Standby). Die Standby-Region Virginia hat einen Worker-Job, der regelmäßig den Anwendungs- und Datenbankzustand der primären Region Oregon überprüft. Das untenstehende Diagramm zeigt den optimalen Zustand.

Optimaler Zustand des Lizenzservers

Wenn die Anwendung nicht reagiert, überprüft der Server die primäre Master-Datenbank. Wenn sowohl die Anwendung als auch die Datenbank wiederholt Zustandsprüfungen nicht bestehen, startet der Worker-Job einen Failover-Prozess.

Die folgenden drei Szenarien können den Notfall-Wiederherstellungszustand auslösen und den Failover-Prozess starten:
  • Wenn die primäre Anwendung ausgefallen ist (alle 3 Dynos sind inaktiv), aber die Master-Datenbank aktiv ist, unternimmt der Worker-Job keine Aktion. Jedoch benachrichtigt das Alarm- und Überwachungssystem das Team.
  • Wenn die primäre Anwendung aktiv ist, aber die Master-Datenbank ausgefallen ist, weist Heroku automatisch eine Standby-Datenbank aus einer anderen Verfügbarkeitszone in derselben Region zu.
  • Wenn sowohl die primäre Anwendung als auch die Master-Datenbank ausgefallen sind, löst der Worker-Job das Failover-Skript aus.
Wenn eines der drei oben genannten Szenarien eintritt, wird das Failover-Skript aktiviert und der folgende Workflow wird implementiert:
  • Die Follower-Datenbank in der Region Virginia synchronisiert alle Commits mit der Master-Datenbank in der Region Oregon und hört dann auf, ihr zu folgen.
  • Die Datenbank in der Region Virginia wird zur neuen Master-Datenbank.
  • Die Virginia-Anwendung verbindet sich mit der neuen Master-Datenbank in der Region Virginia.
  • Die Web Application Firewall (WAF) verbindet sich mit dem Router der Virginia-Anwendung.
  • Die Verbindung zwischen der WAF und Oregon ist entfernt.
Lizenzserver-Notfallwiederherstellungszustand

Wenn die Region Oregon wieder aktiv wird, ist ein manueller Eingriff (zum Wiederverbinden der Web Application Firewall, WAF) erforderlich, um Oregon als primäre Anwendung wiederherzustellen.