Was ist die Microsoft Entra-Architektur?

Mit Microsoft Entra ID können Sie den Zugriff auf Azure-Dienste und Ressourcen für Ihre Benutzer sicher verwalten. In Microsoft Entra ID ist eine vollständige Suite mit Funktionen zur Identitätsverwaltung enthalten. Informationen zu den Features von Microsoft Entra finden Sie unter Was ist Microsoft Entra ID?

Mit Microsoft Entra ID können Sie Benutzer und Gruppen erstellen und verwalten und Berechtigungen zum Zulassen und Verweigern des Zugriffs auf Unternehmensressourcen aktivieren. Informationen zur Identitätsverwaltung finden Sie unter Grundlagen der Identitätsverwaltung in Azure.

Microsoft Entra-Architektur

Die geografisch verteilte Architektur von Microsoft Entra ID bietet umfassende Funktionen für Überwachung, automatisierte Umleitungen, Failover und die Wiederherstellung, um die unternehmensweite Verfügbarkeit und die Leistung für Kunden sicherzustellen.

In diesem Artikel werden die folgenden Architekturelemente behandelt:

  • Design der Dienstarchitektur
  • Skalierbarkeit
  • Fortlaufende Verfügbarkeit
  • Rechenzentren

Design der Dienstarchitektur

Zum Erstellen eines zugänglichen und verwendbaren Systems mit umfassenden Daten werden am häufigsten unabhängige Bausteine oder Skalierungseinheiten verwendet. In der Microsoft Entra-Datenschicht werden Skalierungseinheiten als Partitionen bezeichnet.

Die Datenschicht verfügt über mehrere Front-End-Dienste, über die Lese-/Schreibfunktionen bereitgestellt werden. Das folgende Diagramm zeigt, wie die Komponenten einer Partition mit einem Verzeichnis in geografisch verteilten Datencentern bereitgestellt werden.

Single-directory partition diagram

Die Komponenten der Microsoft Entra-Architektur enthalten ein primäres und sekundäre Replikate.

Primäres Replikat

Das primäre Replikat empfängt alle Schreibvorgänge für die Partition, zu der es gehört. Jeder Schreibvorgang wird sofort auf einem sekundären Replikat in einem anderen Rechenzentrum repliziert, bevor die Erfolgsmeldung an den Aufrufer zurückgegeben wird, um für Schreibvorgänge eine Georedundanz sicherzustellen.

Sekundäre Replikate

Alle Lesevorgänge des Verzeichnisses werden über sekundäre Replikate abgewickelt, bei denen es sich um Datencenter handelt, die physisch auf verschiedene geografische Regionen verteilt sind. Es gibt viele sekundäre Replikate, weil die Daten asynchron repliziert werden. Lesevorgänge des Verzeichnisses (beispielsweise Authentifizierungsanforderungen) werden über Datencenter abgewickelt, die sich in der Nähe der Kunden befinden. Die sekundären Replikate sind für die Skalierbarkeit der Lesevorgänge zuständig.

Skalierbarkeit

Die Skalierbarkeit ist die Fähigkeit eines Diensts zur Erweiterung, um wachsende Anforderungen an die Leistung zu erfüllen. Die Skalierbarkeit von Schreibvorgängen wird durch das Partitionieren der Daten erreicht. Die Skalierbarkeit von Lesevorgängen wird erreicht, indem Daten von einer Partition auf mehreren sekundären Replikaten weltweit repliziert werden.

Anfragen von Verzeichnisanwendungen werden an das nächstgelegene Rechenzentrum weitergeleitet. Schreibvorgänge werden transparent an das primäre Replikat umgeleitet, um für eine Lese-/Schreibkonsistenz zu sorgen. Mit sekundären Replikaten wird die Skalierung von Partitionen erheblich erweitert, da von den Verzeichnissen größtenteils Lesevorgänge bereitgestellt werden.

Für Verzeichnisanwendungen wird eine Verbindung mit den Rechenzentren in der Nähe hergestellt. Diese Verbindung führt zu einer Verbesserung der Leistung, sodass eine horizontale Skalierung möglich ist. Da eine Verzeichnispartition über viele sekundäre Replikate verfügen kann, können sekundäre Replikate näher an den Verzeichnisclients angeordnet werden. Nur interne Verzeichnisdienstkomponenten, die sehr schreibintensiv sind, zielen direkt auf das aktive primäre Replikat ab.

Fortlaufende Verfügbarkeit

Anhand der Verfügbarkeit (bzw. Betriebszeit) wird definiert, inwiefern ein System ohne Unterbrechungen betrieben werden kann. Der Schlüssel zur Hochverfügbarkeit von Microsoft Entra ID liegt in der Tatsache, dass die Dienste Datenverkehr schnell in mehrere geografisch verteilte Datencenter verlagern können. Jedes Datencenter ist unabhängig, was Fehlermodi ohne Korrelation ermöglicht. Durch dieses Hochverfügbarkeitsdesign macht Microsoft Entra ID keine Ausfallzeiten für Wartungsarbeiten erforderlich.

Der Partitionsentwurf von Microsoft Entra ID ist im Vergleich mit dem AD-Unternehmensentwurf einfach. Es wird ein Entwurf mit nur einem Master verwendet, der über einen sorgfältig orchestrierten und deterministischen Failoverprozess für primäre Replikate verfügt.

Fehlertoleranz

Ein System weist eine höhere Verfügbarkeit auf, wenn es gegenüber Hardware-, Netzwerk- und Softwareausfällen tolerant ist. Für jede Partition im Verzeichnis ist ein hoch verfügbares Masterreplikat vorhanden: das primäre Replikat. Auf diesem Replikat werden nur Schreibvorgänge für die Partition durchgeführt. Dieses Replikat wird fortlaufend und eingehend überwacht, und Schreibvorgänge können sofort auf ein anderes Replikat verlagert werden (das dann zum neuen primären Replikat wird), wenn ein Fehler erkannt wird. Während des Failovers kann es zu einem Ausfall von Schreibvorgängen kommen, der meist ein bis zwei Minuten dauert. Die Leseverfügbarkeit wird während dieser Zeit nicht beeinträchtigt.

Für Lesevorgänge (deren Zahl die Schreibvorgänge weit übersteigt) werden nur sekundäre Replikate verwendet. Da sekundäre Replikate idempotent sind, kann der Verlust eines Replikats auf einer Partition leicht kompensiert werden, indem die Lesevorgänge auf ein anderes Replikat verlagert werden (normalerweise in demselben Rechenzentrum).

Dauerhaftigkeit von Daten

Bevor ein Schreibvorgang bestätigt wird, erfolgt dafür ein dauerhafter Commit in mindestens zwei Datencentern. Hierfür wird für den Schreibvorgang zuerst ein Commit im primären Datencenter ausgeführt, und anschließend wird er sofort in mindestens einem anderen Datencenter repliziert. Diese Schreibaktion stellt sicher, dass ein potenzieller katastrophaler Verlust des Rechenzentrums, das die primäre Datenbank hostet, nicht zu Datenverlust führt.

In Microsoft Entra ID wird ein RTO-Wert (Recovery Time Objective) von null verwendet, damit bei Failovern keine Daten verloren gehen. Dies schließt Folgendes ein:

  • Tokenausstellung und Verzeichnislesevorgänge
  • Nur RTO-Wert von 5 Minuten für Verzeichnisschreibvorgänge

Rechenzentren

Die Replikate von Microsoft Entra ID werden in Rechenzentren gespeichert, die weltweit verteilt sind. Weitere Informationen finden Sie unter Globale Azure-Infrastruktur.

Microsoft Entra ID wird in Datencentern mit folgenden Merkmalen betrieben:

  • Authentifizierung, Graph und andere AD-Dienste sind hinter dem Gatewaydienst angeordnet. Das Gateway verwaltet den Lastenausgleich dieser Dienste. Es wird automatisch ein Failover durchgeführt, wenn mit transaktionalen Integritätstests fehlerhafte Server erkannt werden. Basierend auf diesen Integritätstests wird Datenverkehr vom Gateway dynamisch an fehlerfreie Datencenter weitergeleitet.
  • Für Lesevorgänge verfügt das Verzeichnis über sekundäre Replikate und entsprechende Front-End-Dienste in einer Aktiv/Aktiv-Konfiguration, die in mehreren Datencentern betrieben werden. Wenn ein Rechenzentrum ausfällt, wird der Datenverkehr automatisch an ein anderes Rechenzentrum weitergeleitet.
  • Bei Schreibvorgängen wird das Verzeichnis das primäre Replikat über Rechenzentren hinweg über geplante (das neue primäre wird mit dem alten primären synchronisiert) oder Notfall-Failover-Verfahren umschalten. Die Dauerhaftigkeit der Daten wird erreicht, indem ein Commit in mindestens zwei Datencentern repliziert wird.

Datenkonsistenz

Das Verzeichnismodell lautet „Letztliche Konsistenz“. Ein typisches Problem mit verteilten Systemen mit asynchroner Replikation ist, dass die Daten, die von einem „bestimmten“ Replikat zurückgegeben werden, unter Umständen nicht aktuell sind.

Microsoft Entra ID bietet Lese-/Schreibkonsistenz für Anwendungen, die auf ein sekundäres Replikat abzielen, indem die zugehörigen Schreibvorgänge an das primäre Replikat weitergeleitet und synchron dazu die Schreibvorgänge zurück auf das sekundäre Replikat verschoben werden.

Mithilfe der Microsoft Graph-API von Microsoft Entra ID ausgeführte Anwendungsschreibvorgänge werden in Bezug auf die Beibehaltung der Affinität mit einem Verzeichnisreplikat für Schreib-/Lesekonsistenz abstrahiert. Der Microsoft Graph-API-Dienst verfügt über eine logische Sitzung mit einer Affinität mit einem sekundären Replikat, das für Lesevorgänge verwendet wird. Die Affinität wird in einem „Replikattoken“ erfasst, das vom Dienst mithilfe eines verteilten Cache im sekundären Replikatrechenzentrum zwischengespeichert wird. Dieses Token wird dann für nachfolgende Vorgänge in derselben logischen Sitzung verwendet. Um weiterhin dieselbe logische Sitzung zu verwenden, müssen nachfolgende Anforderungen an das gleiche Microsoft Entra-Datencenter geroutet werden. Es ist nicht möglich, eine logische Sitzung fortzusetzen, wenn die Verzeichnisclientanforderungen an mehrere Microsoft Entra-Datenzentren geroutet werden. Falls dies passiert, verfügt der Client über mehrere logische Sitzungen mit unabhängigen Lese-/Schreibkonsistenzen.

Hinweis

Schreibvorgänge werden sofort auf dem sekundären Replikat repliziert, für das die Lesevorgänge der logischen Sitzung ausgestellt wurden.

Sicherung auf Dienstebene

Microsoft Entra ID implementiert eine tägliche Sicherung von Verzeichnisdaten und kann diese Sicherungen verwenden, um Daten bei einem Dienstweiten Problem wiederherzustellen.

Das Verzeichnis implementiert ebenfalls vorläufige Löschvorgänge anstelle von endgültigen Löschvorgängen für ausgewählte Objekttypen. Der Mandantenadministrator kann alle versehentlichen Löschungen dieser Objekte innerhalb von 30 Tagen rückgängig machen. Weitere Informationen finden Sie unter API zum Wiederherstellen gelöschter Objekte.

Metriken und Überwachungen

Zum Ausführen eines Hochverfügbarkeitsdiensts sind professionelle Metriken und Überwachungsfunktionen erforderlich. Microsoft Entra ID führt eine fortlaufende Analyse durch und meldet wichtige Metriken zur Dienstintegrität und Erfolgskriterien für die einzelnen Dienste. Außerdem erfolgt eine fortlaufende Entwicklung und Optimierung von Metriken sowie die Überwachung und Warnungsbereitstellung für jedes Szenario – in jedem Microsoft Entra-Dienst und übergreifend für alle Dienste.

Falls ein Microsoft Entra-Dienst nicht wie erwartet funktioniert, werden sofort Maßnahmen ergriffen, um die Funktionalität so schnell wie möglich wiederherzustellen. Die wichtigste Metrik, die von Microsoft Entra ID nachverfolgt wird, lautet: Wie schnell können Probleme mit der Livewebsite erkannt und für Kunden behoben werden. Wir investieren in hohem Maße in die Überwachung und Warnungen, um die Erkennungsdauer zu verringern (Ziel: <5 Minuten), und in die Betriebsbereitschaft, um die Lösungsdauer zu verringern (Ziel: <30 Minuten).

Sichere Vorgänge

Kontrolleinrichtungen werden für den Betrieb, z.B. Multi-Factor Authentifizierung für alle Vorgänge, verwendet, und außerdem werden für alle Vorgänge Überprüfungen durchgeführt. Darüber hinaus wird ein Just-in-Time-System zur Erhöhung von Rechten eingesetzt, um den benötigten temporären Zugriff für alle betrieblichen Aufgaben fortlaufend je nach Bedarf gewähren zu können. Weitere Informationen finden Sie unter Die vertrauenswürdige Cloud.

Nächste Schritte

Entwicklerhandbuch für Microsoft Entra