Wat is de Azure Active Directory architectuur?

Met Azure AD (Azure Active Directory) kunt u veilig de toegang tot Azure-services en -resources beheren voor uw gebruikers. Azure AD omvat een volledige suite met mogelijkheden voor identiteitsbeheer. Zie Wat is Azure Active Directory? voor meer informatie over de functies van Azure AD.

Met Azure AD kunt u gebruikers en groepen maken en beheren, en machtigingen inschakelen om toegang tot bedrijfsresources te verlenen of te weigeren. Zie The fundamentals of Azure identity management (De grondbeginselen van Azure-identiteitsbeheer) voor meer informatie over identiteitsbeheer.

Azure AD-architectuur

De geografisch gedistribueerde architectuur van Azure AD combineert uitgebreide bewaking, geautomatiseerde omleiding, failover en herstelmogelijkheden, die klanten bedrijfsbrede beschikbaarheid en prestaties bieden.

In dit artikel worden de volgende elementen van de architectuur besproken:

• Servicearchitectuurontwerp
• Schaalbaarheid
• Continue beschikbaarheid
• Datacenters

Servicearchitectuurontwerp

De meest voorkomende manier om een toegankelijk en bruikbaar, gegevensrijk systeem te bouwen, is via onafhankelijke bouwstenen of schaaleenheden. Voor de Azure AD-gegevenslaag worden schaaleenheden partities genoemd.

De gegevenslaag heeft meerdere front-end-services die mogelijkheden bieden voor lezen/schrijven. In het onderstaande diagram ziet u hoe de onderdelen van een partitie met één map worden geleverd in geografisch verspreide datacenters.

De onderdelen van Azure AD-architectuur omvatten een primaire replica en secundaire replica's.

Primaire replica

De primaire replica ontvangt alle schrijfbewerkingen voor de partitie waarbij deze hoort. Alle schrijfbewerkingen worden onmiddellijk gerepliceerd naar een secundaire replica in een ander datacenter, voordat de aanroeper een melding van slagen ontvangt. Op deze manier wordt de geografisch redundante duurzaamheid van schrijfbewerkingen verzekerd.

Secundaire replica's

Alle leesgidsen in de map worden afgelezen vanaf secundaire replica's, die zich in datacenters bevinden die zich fysiek in verschillende geografische gebieden bevinden. Er zijn veel secundaire replica's, omdat gegevens asynchroon worden gerepliceerd. Lees- en adreslijstaanvragen, zoals verificatieaanvragen, worden geregeld vanuit datacenters die zich dicht bij klanten bevinden. De secundaire replica's zijn verantwoordelijk voor de schaalbaarheid van leesbewerkingen.

Schaalbaarheid

Schaalbaarheid is de mogelijkheid van een service om uit te breiden en zo te voldoen aan groeiende prestatievereisten. Schaalbaarheid van schrijfbewerkingen wordt bereikt door de gegevens te partitioneren. Schaalbaarheid van leesbewerkingen wordt bereikt door gegevens uit één partitie te repliceren naar meerdere secundaire replica's over de hele wereld.

Aanvragen van directorytoepassingen worden doorgeleid naar het datacenter waar ze zich fysiek het dichtst bij bevinden. Schrijfbewerkingen worden transparant omgeleid naar de primaire replica voor lees-/schrijfconsistentie. Secundaire replica's breiden de schaal van partities aanzienlijk uit, omdat in de mappen doorgaans leesbewerkingen worden afgehandeld.

Directory-toepassingen maken verbinding met de dichtstbijzijnde datacenters. Deze verbinding verbetert de prestaties en daarom is uitschalen mogelijk. Omdat een mappartitie meerdere secundaire replica's kan hebben, kunnen deze secundaire replica's dichter bij Directory-clients worden geplaatst. Alleen interne Directory-serviceonderdelen die veel schrijfbewerkingen afhandelen, zijn rechtstreeks gericht op de actieve primaire replica.

Continue beschikbaarheid

Beschikbaarheid (of bedrijfstijd) definieert de mogelijkheid van een systeem om ononderbroken actief te zijn. De sleutel tot de hoge beschikbaarheid van Azure AD is dat de services snel verkeer kunnen verplaatsen naar meerdere geografisch verspreide datacenters. Elk datacenter is onafhankelijk, waardoor de gecorreleerde foutmodi mogelijk zijn. Door dit ontwerp voor hoge beschikbaarheid vereist Azure AD geen downtime voor onderhoudsactiviteiten.

Het partitieontwerp van Azure AD is vereenvoudigd in vergelijking met het AD-ontwerp voor ondernemingen, met behulp van een ontwerp met één master dat een zorgvuldig georganiseerd en deterministisch failoverproces voor primaire replica's bevat.

Fouttolerantie

Een systeem is beschikbaarder als het tolerant is voor fouten in hardware, software en het netwerk. Voor elke mappartitie bestaat een maximaal beschikbare hoofdreplica: de primaire replica. Op deze replica worden alleen schrijfbewerkingen naar de partitie uitgevoerd. Deze replica wordt voortdurend en nauwlettend gecontroleerd. Indien er een fout wordt gedetecteerd, kunnen schrijfbewerkingen onmiddellijk worden verplaatst naar een andere replica (die dan de nieuwe primaire replica wordt). Tijdens de failover kan er een verlies van schrijfbeschikbaarheid optreden. Dit duurt meestal maar 1-2 minuten. De leesbeschikbaarheid wordt gedurende deze tijd niet beïnvloed.

Leesbewerkingen (die vele malen vaker voorkomen dan schrijfbewerkingen) worden alleen opgeslagen in secundaire replica's. Aangezien secundaire replica's idempotent zijn, kan het verlies van een van de replica's in een bepaalde partitie eenvoudig worden gecompenseerd door de leesbewerkingen naar een andere replica te leiden. Meestal is dit dan een replica in hetzelfde datacenter.

Duurzaamheid van gegevens

Een schrijfing wordt duurzaam vastgelegd in ten minste twee datacenters voordat deze wordt bevestigd. Dit gebeurt door eerst de schrijf-overschrijven op de primaire en vervolgens onmiddellijk repliceren van de schrijven naar ten minste één ander datacenter. Deze schrijfactie zorgt ervoor dat een mogelijk onherstelbare verlies van het datacenter dat als host voor de primaire host, niet leidt tot gegevensverlies.

Azure AD onderhoudt een nul RTO (Recovery Time Objective) om geen gegevens te verliezen bij failovers. Dit omvat:

• Tokenuitgifte en maplezen
• Het toestaan van slechts ongeveer 5 minuten RTO voor het schrijven van mappen

Datacenters

Azure AD-replica's worden opgeslagen in datacenters over de hele wereld. Zie Globale Azure-infrastructuur voor meer informatie.

Azure AD werkt in datacenters met de volgende kenmerken:

• Verificatie, Graph en andere AD-services bevinden zich achter de gatewayservice. De taakverdeling van deze services wordt via de gateway beheerd. Er wordt automatisch een fail overgeslagen als er servers met een slechte status worden gedetecteerd met behulp van transactionele statustests. Op basis van deze statustests routeert de gateway verkeer dynamisch naar gezonde datacenters.
• Voor lees- en leesgegevens heeft de map secundaire replica's en bijbehorende front-endservices in een actief-actief-configuratie die in meerdere datacenters wordt gebruikt. In het geval van een storing in een volledig datacenter wordt verkeer automatisch doorgeleid naar een ander datacenter. *Voor schrijfprocessen wordt een failover van de primaire replica (hoofdreplica) voor datacenters in de map gemaakt via geplande (nieuwe primaire replica wordt gesynchroniseerd met oude primaire replica) of procedures voor failover in noodgevallen. Duurzaamheid van gegevens wordt bereikt door een door commit naar ten minste twee datacenters te repliceren.

Gegevensconsistentie

Het directorymodel is een van de uiteindelijke consistentien. Een typisch probleem met gedistribueerde asynchroon replicerende systemen is dat de gegevens die worden geretourneerd door een 'bepaalde' replica mogelijk niet up-to-date zijn.

Met behulp van een secundaire replica biedt Azure AD lees-/schrijfconsistentie voor toepassingen door schrijfbewerkingen naar de primaire replica te leiden en ze tegelijkertijd terug te halen naar de secundaire replica.

Toepassingsschrijven met behulp van de Microsoft Graph-API van Azure AD worden ontdaan van het onderhouden van affiniteit met een directoryreplica voor lees-/schrijfconsistentie. De Microsoft Graph API-service onderhoudt een logische sessie, die affiniteit heeft met een secundaire replica die wordt gebruikt voor lees-informatie; affiniteit wordt vastgelegd in een replica-token dat door de service wordt opgeslagen in de cache met behulp van een gedistribueerde cache in het secundaire replica-datacenter. Dit token wordt vervolgens gebruikt voor verdere bewerkingen in dezelfde logische sessie. Als u dezelfde logische sessie wilt blijven gebruiken, moeten volgende aanvragen worden gerouteerd naar hetzelfde Azure AD-datacenter. Het is niet mogelijk om door te gaan met een logische sessie als de aanvragen van de directoryclient worden doorgeleid naar meerdere Azure AD-datacenters; Als dit gebeurt, heeft de client meerdere logische sessies met onafhankelijke lees-/schrijfconsistentie.

Back-up op serviceniveau

Azure AD implementeert dagelijkse back-ups van directorygegevens en kan deze back-ups gebruiken om gegevens te herstellen in het geval van een servicebreed probleem.

De map implementeert ook zachte verwijderingen in plaats van harde verwijderingen voor geselecteerde objecttypen. De tenantbeheerder kan onbedoelde verwijderingen van deze objecten binnen 30 dagen ongedaan maken. Zie de API voor het herstellen van verwijderde objecten voor meer informatie.

Metrische gegevens en controles

Voor het uitvoeren van een service met een hoge beschikbaarheid zijn uitstekende mogelijkheden voor metrische gegevens en controle vereist. Met Azure AD worden belangrijke metrische gegevens met betrekking tot de status van de service voortdurend geanalyseerd voor elk van de services. Er is ook continue ontwikkeling en afstemming van metrische gegevens en bewaking en waarschuwingen voor elk scenario, binnen elke Azure AD-service en in alle services.

Als een Azure AD-service niet werkt zoals verwacht, wordt onmiddellijk actie ondernomen om de functionaliteit zo snel mogelijk te herstellen. De belangrijkste metrische gegevens die Azure AD bij houdt, zijn hoe snel problemen met live-site kunnen worden gedetecteerd en opgelost voor klanten. We investeren veel in controle en waarschuwingen om de detectietijd (TTD-doel: < 5 minuten) te minimaliseren en in operationele paraatheid om de hersteltijd (TTM-doel: < 30 minuten) zo kort mogelijk te houden.

Veilige bewerkingen

Het gebruik van operationele besturingselementen, zoals meervoudige verificatie (MFA) voor elke bewerking, evenals het controleren van alle bewerkingen. Daarnaast kunt u een Just-In-Time-systeem voor benodigde bevoegdheden gebruiken om de benodigde tijdelijke toegang te verlenen voor elke operationele taak op aanvraag die doorlopend wordt uitgevoerd. Zie De vertrouwde cloud voor meer informatie.

Volgende stappen

Ontwikkelaarshandleiding voor Azure Active Directory