Le serveur de licences prennent en charge les instances globales de la Control Room avec des capacités de haute disponibilité et de reprise après sinistre. Des contrôles d\'intégrité réguliers des applications déclenchent des processus de basculement pour maintenir la continuité du service.

Le serveur de licences (LS) est hébergé centralement aux États-Unis. Toutes les instances de la Control Room à travers le monde qui utilisent une licence basée sur GUID ou une licence cloud se connectent à ce serveur. Étant un service critique, le serveur de licences dispose de capacités de haute disponibilité et de reprise après sinistre. Le diagramme ci-dessous illustre l\'architecture détaillée au niveau de l\'infrastructure. Pour plus d\'informations sur la licence cloud, voir FAQ sur les licences cloud.

Considérez deux régions, Oregon (principale) et Virginie (secours). La région de secours Virginie a une tâche worker qui vérifie régulièrement l\'intégrité de l\'application et de la base de données de la région principale, Oregon. Le diagramme ci-dessous concerne l\'état optimal.

État optimal du serveur de licences

Si l\'application ne répond pas, le serveur vérifie la base de données maître principale. Si l\'application et la base de données échouent toutes deux aux vérifications d\'intégrité, la tâche worker démarre un processus de basculement.

Les trois scénarios suivants peuvent déclencher l\'état de reprise après sinistre et démarrer le processus de basculement :
  • Si l\'application principale est en panne (les 3 dynos sont inactifs) mais que la base de données principale est active, la tâche worker ne prend aucune mesure. Cependant, le système d\'alerte et de surveillance notifie l\'équipe.
  • Si l\'application principale est active mais que la base de données principale est en panne, Heroku assigne automatiquement une base de données de secours d\'une autre zone de disponibilité dans la même région.
  • Si à la fois l\'application principale et la base de données principale sont en panne, la tâche worker déclenche le script de basculement.
Si l\'un des trois scénarios mentionnés ci-dessus se produit, le script de basculement est activé et le flux de travail suivant est mis en œuvre :
  • La base de données des abonnés dans la région Virginie synchronise tous les commits avec la base de données principale dans la région Oregon, puis arrête de la suivre.
  • La base de données dans la région Virginie devient la nouvelle base de données principale.
  • L\'application Virginie se connecte à la nouvelle base de données principale dans la région Virginie.
  • Le pare-feu d\'application Web (WAF) se connecte au routeur de l\'application Virginie.
  • La connexion entre le WAF et Oregon est supprimée.
État de reprise après sinistre du serveur de licences

Lorsque la région Oregon redevient active, une intervention manuelle (de reconnexion du pare-feu d\'application Web (WAF)) est nécessaire pour rétablir Oregon en tant qu\'application principale.