eIAM Georedundanz

Georedundanz von eIAM

Die Steuerung, welches Rechenzentrum für eIAM-Core angesprochen wird, erfolgt über DNS Einträge. Im Regelfall zeigen die Hostnamen (FQDN) von eIAM-Core auf die Loadbalancer in Primus, nach einem Switch auf Campus. Damit gibt es bei einem Switch einen Unterbruch aufgrund der Gültigkeitsdauer von DNS Abfragen (DNS TTL). Aktuell ist bei einem Switch mit einem Unterbruch von rund 30 Minuten zu rechnen.

Unter eIAM-Core sind die Leistungen 1-10, 12 gemäss eIAM Leistungen zusammengefasst. Die Leistung eIAM RP-PEP (Leistung 11) wird separat behandelt, weil der RP-PEP netzwerkmässig im Kommunikationspfad zwischen Browser und Applikations-Backend liegen muss.

Georedundanz von Applikationen

Je nach Ausfallsszenario von eIAM ergeben sich für Applikationen unterschiedliche Folgen. Für georedundante Applikationen geht eIAM davon aus, dass diese gemäss den Vorgaben in Kapitel 4.3 und 5 der IT-Richtlinie Umsetzung der Verfügbarkeitsklassen und der Georedundanz
(Perma-Link: ) aufgebaut wurden.

Integrationsmuster BTB-Direct

STS-BTB angebundene Applikationen erreichen eIAM über definierte Hostnamen, welche je nach Betriebszustand auf Komponenten in Primus (Regelfall) oder Campus (falls Primus als Rechenzentrum komplett ausgefallen ist) zeigen. Damit ist ein Switch von eIAM-Core grundsätzlich unabhängig und transparent von einem allfälligen Switch einer georedundanten Applikation. Ob eine Applikation auch switchen will oder muss, hängt nicht von eIAM, sondern vom Ereignis ab (z.B. Rechenzentrum fällt aus).

: STS-BTB integrierte georedundante Applikation, aktiv in Campus

Szenario	Applikation in Primus	Applikation in Campus	Applikation georedundant (Primus + Campus)	Applikation ausserhalb Primus / Campus (Anderes RZ Public Cloud)	Applikation ausserhalb Primus / Campus georedundant (in 2 Cloud Regionen)
Ausfall RZ Primus (eIAM-Core switcht auf Campus)	Applikation fällt aus	Logins weiterhin möglich	Logins weiterhin möglich. Applikation: Falls die Applikation auf Primus aktiv war, muss sie im Rahmen des Applikationsbetriebs auch switchen.	Logins weiterhin möglich	Logins weiterhin möglich
Applikation fällt aus	Applikation fällt aus	Applikation fällt aus	Logins weiterhin möglich. Applikation: Switcht auf das andere RZ	Applikation fällt aus	Logins weiterhin möglich. Applikation switcht in andere Region (oder ist dort bereits aktiv)

Integrationsmuster STS-PEP

Szenario	Applikation in Primus	Applikation in Campus	Applikation georedundant (Primus + Campus)	Applikation ausserhalb Primus / Campus (Anderes RZ Public Cloud)	Applikation ausserhalb Primus / Campus georedundant (in 2 Cloud Regionen)
Ausfall RZ Primus (eIAM-Core switcht auf Campus)	Applikation fällt aus	Logins nicht mehr möglich(*)	Logins nicht mehr möglich (*)	Logins nicht mehr möglich (*)	Logins nicht mehr möglich (*)
Applikation fällt aus	Applikation fällt aus	Applikation fällt aus	Logins weiterhin möglich. Applikation: Switcht auf das andere RZ	Applikation fällt aus	Logins weiterhin möglich. Applikation switcht in andere Region (oder ist dort bereits aktiv)

(*) Die bereits laufende Migration von STS-PEP nach STS-BTB behebt diesen Zustand.

Integratonsmuster RP-PEP

Bitte auch beachten: Migration RP-PEP zu STS-PEP

Im Gegensatz zu der STS-BTB Anbindung gibt es bei der RP-PEP Integration eine Abhängigkeit zwischen eIAM und der Applikation, weil mit dem RP-PEP eine eIAM-Komponente zwischen Browser und der Applikation im Kommunikationspfad ist. Grundsätzlich muss daher der RP-PEP immer im gleichen Rechenzentrum laufen wie die Applikation selbst. Bei georedundanten Applikationen mit RP-PEP sind aus Sicht eIAM immer die RP-PEPs der beiden Rechenzentren aktiv, so dass eine Applikation unabhängig von eIAM switchen kann. RP-PEPs werden ausserhalb Primus / Campus nicht angeboten.

: RP-PEP integrierte georedundante Applikation, aktiv in Campus

Szenario	Applikation in Primus	Applikation in Campus	Applikation georedundant (Primus + Campus)
Ausfall RZ Primus (eIAM-Core switcht auf Campus)	Applikation fällt aus	Logins weiterhin möglich	Logins weiterhin möglich. Applikation: Falls die Applikation auf Primus aktiv war, muss sie im Rahmen des Applikationsbetriebs auch switchen.
RP-PEP oder Loadbalancer fallen aus	Applikation fällt aus	Applikation fällt aus	Logins weiterhin möglich. Applikation: Applikation switcht im Rahmen des Applikationsbetriebs auf das andere RZ
Applikation fällt aus	Applikation fällt aus	Applikation fällt aus	Logins weiterhin möglich

Grundsätzlich ist der Applikationsbetrieb dafür verantwortlich, aufgrund einer Lagebeurteilung und Absprache mit eIAM Betrieb oder im Falle einer Grossstörung mit dem Incident Management zu switchen oder auf die Behebung des Problems im Rechenzentrum zu warten.

Switch durch den Applikationsbetrieb für georedundante Applikationen mit RP-PEP
Im Rahmen der Integration werden die Front-Loadbalancer durch die eIAM SIE bestellt und deren FQDN / CNAMEs dem Applikationsbetrieb übergeben. Exemplarische Situation:

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

Will der Applikationsbetrieb nun switchen, kann folgendermassen vorgegangen werden (Beispiel Switch von Primus nach Campus):

Critical Incident in Remedy eröffnen mit Mutationsforderungen beim FQDN nun den CNAME von Campus einzutragen.