Scenario: Een regionale organisatieomgeving overschakelen naar de conceptuele architectuur van de Azure-landingszone

In dit artikel worden overwegingen en instructies beschreven voor het migreren en overstappen van uw Azure-omgeving naar de conceptuele architectuur van de Azure-landingszone. In dit scenario wordt een regionale organisatie behandeld met beheergroepen die zijn gescheiden in ontwikkel-, test- en productieomgevingen (dev/test/prod).

In dit scenario heeft de klant een grote footprint in Azure. Ze hebben een beheergroephiërarchie die is georganiseerd op ontwikkel-/test-/prod-omgevingen en vervolgens op regio. Hun huidige implementatie beperkt hun schaalbaarheid en groei. Ze hebben toepassingen geïmplementeerd over de hele wereld. Een centraal IT-team beheert elke regio. In dit scenario zijn de regio's Amerika; Europa, het Midden-Oosten en Afrika (EMEA); en Azië-Stille Oceaan (APAC).

De klant wil overstappen van hun bestaande omgeving naar de conceptarchitectuur van azure-landingszones. Deze benadering ondersteunt hun eerste cloudstrategie en heeft een robuust platform dat wordt geschaald naarmate de klant zijn on-premises datacentrums buiten gebruik stelt.

Huidige status

In dit scenario bestaat de huidige status van de Azure-omgeving van de klant uit:

• Meerdere beheergroepen.
• Een beheergroephiërarchie op basis van ontwikkel-/test-/prod-omgevingen op het eerste niveau en vervolgens op basis van geografie op het tweede niveau.
• Een Azure-abonnement voor elke geografie en toepassingsomgeving, zoals dev/test/prod. Dit abonnement is vereist om ontwikkelaars een ontspannen omgeving te bieden voor testen en innovatie.
• Sommige kritieke workloads die hetzelfde governancemodel nodig hebben in dev/test/prod, waardoor governance-uitdagingen voor de klant kunnen ontstaan.
• Niet-uniforme resourcedistributie. Platform- en workloadresources voor één omgeving worden geïmplementeerd in dezelfde Azure-abonnementen.
• Toepassingen die zijn geïmplementeerd in de respectieve abonnementen op basis van hun regio en omgevingsclassificatie, zoals dev/test/prod.
• Beleidstoewijzingen, zoals controle-effecten en weigeringseffecten, die zijn toegewezen op het niveau van de beheergroep en het abonnement.
• Dezelfde set Azure-beleidsregels die zijn toegepast op alle toepassingen in dezelfde regio en in hetzelfde omgevingstype.
• Roltoewijzingen voor op rollen gebaseerd toegangsbeheer voor elk abonnement en elke resourcegroep.
• Een virtueel hubnetwerk, zoals Azure VPN Gateway of Azure ExpressRoute, voor hybride connectiviteit.
• Een virtueel netwerk voor elke toepassingsomgeving.
• Een centraal IT-team dat de respectieve beheergroep voor elke regio beheert en beheert. Het team heeft te maken met een aantal problemen met consistentie, configuratie en naleving als het gaat om beleid, toegangsbeheer, configuratie van platformbronnen en beveiligingsnaleving, omdat sommige toepassingen in meerdere regio's worden geïmplementeerd.

In het volgende diagram ziet u de huidige status van dit voorbeeldscenario.

Overgang naar de conceptuele architectuur van de Azure-landingszone

Voordat u deze benadering implementeert, bekijkt u de conceptarchitectuur van de Azure-landingszone, de ontwerpprincipes voor de Azure-landingszone en ontwerpgebieden van de Azure-landingszone.

Als u wilt overstappen van de huidige status van dit scenario naar een conceptuele architectuur van een Azure-landingszone, gebruikt u deze benadering:

1. Implementeer de Azure-landingszoneversneller in dezelfde Microsoft Entra ID-tenant parallel met de huidige omgeving. Deze methode biedt een soepele en gefaseerde overgang naar de nieuwe landingszonearchitectuur met minimale onderbreking van actieve workloads.

   Met deze implementatie maakt u een nieuwe structuur voor beheergroepen. Deze structuur is afgestemd op ontwerpprincipes en aanbevelingen voor Azure-landingszones. Het zorgt er ook voor dat deze wijzigingen geen invloed hebben op de bestaande omgeving.

   Zie Een landingszone voor dev/test/prod-workloads verwerken voor meer informatie.

   Zie de richtlijnen voor sandbox-sandboxomgevingen voor informatie over het gebruik van de hiërarchie van sandbox-beheergroepen om ontwikkelaars te helpen testen en experimenteren zonder dat dit van invloed is op andere omgevingen.

   Zie Richtlijnen voor beleidsgestuurde kaders gebruiken voor informatie over het minimaliseren van onderbrekingen van toepassingen en services tijdens de migratie.

2. (Optioneel) Werk samen met toepassings- of serviceteams om de workloads die in de oorspronkelijke abonnementen zijn geïmplementeerd, te migreren naar nieuwe Azure-abonnementen. Zie Bestaande Azure-omgevingen overschakelen naar de conceptarchitectuur van de Azure-landingszone voor meer informatie. U kunt workloads in de zojuist geïmplementeerde conceptuele architectuurbeheergroephiërarchie van azure-landingszones onder de juiste beheergroep plaatsen, zoals zakelijk of online in het volgende diagram.

   Zie Beleid voor meer informatie over het effect op resources tijdens de migratie.

   Uiteindelijk kunt u het bestaande Azure-abonnement opzeggen en in de buiten gebruik gestelde beheergroep plaatsen.

   Notitie

   U hoeft de bestaande toepassingen of services niet per se te migreren naar nieuwe landingszones of Azure-abonnementen.

3. Maak nieuwe Azure-abonnementen om landingszones te bieden die nieuwe toepassingen en workloads kunnen ondersteunen. Plaats ze onder de juiste beheergroep, zoals zakelijk of online , in het volgende diagram.

   Zie Uw landingszone voorbereiden voor migratierichtlijnen voor meer informatie.

In het volgende diagram ziet u de status van dit scenario tijdens de migratie.

Samenvatting

In dit scenario heeft de klant de benodigde basis gelegd om hun groei- en schaalplannen voor hun workloads in Azure te ondersteunen door de conceptuele architectuur van de Azure-landingszone parallel aan hun bestaande omgeving te implementeren.