eIAM Géoredondance

Géoredondance de eIAM

Le contrôle du centre de calcul auquel eIAM-Core s'adresse se fait via des entrées DNS. En règle générale, les noms d’hôtes (FQDN) de eIAM-Core pointent vers les Loadbalancer à Primus, et après un basculement, vers Campus. Par conséquent, un basculement entraîne une interruption due à la durée de validité des requêtes DNS (TTL DNS). Actuellement, on peut s'attendre à une interruption d’environ 30 minutes lors d’un basculement.

Sous eIAM-Core sont regroupés les services 1 à 10 et 12 selon Prestations d'eIAM . Le service eIAM RP-PEP (service 11) est traité séparément car le RP-PEP doit se trouver, du point de vue réseau, dans le chemin de communication entre le navigateur et le backend de l’application.

Géoredondance des applications

Selon le scénario de défaillance de eIAM, les conséquences varient pour les applications. Pour les applications géoredondantes, eIAM part du principe qu'elles sont conçues conformément aux directives des chapitres 4.3 et 5 de la Directive informatique sur la mise en œuvre des classes de disponibilité et de la géoredondance (Allemand). (Lien permanent : )

Modèle d’intégration BTB-Direct

Les applications connectées via STS-BTB atteignent eIAM via des noms d’hôtes définis, qui pointent selon l’état opérationnel vers les composants de Primus (cas standard) ou de Campus (si Primus est totalement hors service). Ainsi, un basculement de eIAM-Core est fondamentalement indépendant et transparent par rapport à un éventuel basculement d’une application géoredondante. Le fait qu'une application doive ou veuille également basculer ne dépend pas de eIAM, mais de l’événement (par ex. panne d’un centre de calcul).

: Application géoredondante STS-BTB intégrée, active sur le campus

Scénario	Application à Primus	Application à Campus	Application géoredondante (Primus + Campus)	Application hors Primus / Campus (Autre DC / Cloud public)	Application hors Primus / Campus géoredondante (dans 2 régions Cloud)
Panne du DC Primus (eIAM-Core bascule sur Campus)	Application hors service	Connexions toujours possibles	Connexions toujours possibles. Application : si l'application était active sur Primus, elle doit également basculer dans le cadre de l’exploitation applicative.	Connexions toujours possibles	Connexions toujours possibles
Application en panne	Application hors service	Application hors service	Connexions toujours possibles. Application : bascule vers l'autre DC	Application hors service	Connexions toujours possibles. Application bascule vers une autre région (ou y est déjà active)

Modèle d’intégration STS-PEP

Scénario	Application à Primus	Application à Campus	Application géoredondante (Primus + Campus)	Application hors Primus / Campus (Autre DC / Cloud public)	Application hors Primus / Campus géoredondante (dans 2 régions Cloud)
Panne du DC Primus (eIAM-Core bascule sur Campus)	Application hors service	Connexions plus possibles (*)	Connexions plus possibles (*)	Connexions plus possibles (*)	Connexions plus possibles (*)
Application en panne	Application hors service	Application hors service	Connexions toujours possibles. Application : bascule vers l'autre DC	Application hors service	Connexions toujours possibles. Application bascule vers une autre région (ou y est déjà active)

* La migration en cours de STS-PEP vers STS-BTB résout cette situation.

Modèle d’intégration RP-PEP

Veuillez également noter : Migration RP-PEP vers STS-PEP

Contrairement à l’intégration STS-BTB, l’intégration RP-PEP crée une dépendance entre eIAM et l’application, car le RP-PEP, composant de eIAM, se trouve dans le chemin de communication entre le navigateur et l’application. Par principe, le RP-PEP doit donc toujours s’exécuter dans le même centre de calcul que l’application elle-même. Pour les applications géoredondantes avec RP-PEP, eIAM considère toujours que les RP-PEP des deux centres de calcul sont actifs, de sorte qu’une application peut basculer indépendamment de eIAM. Les RP-PEP ne sont pas proposés en dehors de Primus / Campus.

: Application RP-PEP géoredondante intégrée, active sur le campus

Scénario	Application à Primus	Application à Campus	Application géoredondante (Primus + Campus)
Panne du DC Primus (eIAM-Core bascule sur Campus)	Application hors service	Connexions toujours possibles	Connexions toujours possibles. Application : si l’application était active sur Primus, elle doit également basculer dans le cadre de l’exploitation applicative.
RP-PEP ou Loadbalancer en panne	Application hors service	Application hors service	Connexions toujours possibles. Application : bascule vers l’autre DC dans le cadre de l’exploitation applicative
Application en panne	Application hors service	Application hors service	Connexions toujours possibles

Fondamentalement, il appartient à l’exploitation applicative de décider, sur la base d’une évaluation de la situation et en concertation avec l’exploitation eIAM (ou en cas d’incident majeur avec la gestion des incidents), s’il convient de basculer ou d’attendre la résolution du problème dans le centre de calcul.

Basculement par l’exploitation applicative pour les applications géoredondantes avec RP-PEP
Dans le cadre de l’intégration, les Loadbalancer frontaux sont commandés par eIAM SIE et leurs FQDN / CNAME sont remis à l’exploitation applicative. Situation d’exemple :

FQDN : app.amt.admin.ch
CNAME Primus : app.primus.amt.admin.ch
CNAME Campus : app.campus.amt.admin.ch

Si l’exploitation applicative souhaite désormais basculer, elle peut procéder comme suit (exemple : basculement de Primus vers Campus) :

Ouvrir un incident critique dans Remedy avec une demande de modification pour faire pointer le FQDN vers le CNAME de Campus.