Scenario: Een omgeving overschakelen door een beheergroep voor landingszones te dupliceren

In dit artikel wordt een voorbeeldbenadering beschreven waarmee een omgeving wordt overgestapt naar de conceptuele architectuur van de Azure-landingszone door de beheergroep voor landingszones te dupliceren met beleidsregels in de controlemodus . Met deze aanpak hebt u snel toegang tot de nieuwe gewenste doelarchitectuur en kunt u vervolgens de toepassings- of workloadabonnementen beoordelen op naleving. Deze aanpak elimineert het risico dat het van invloed is op de toepassingsteams, omdat het beleid zich alleen in de controlemodus bevindt.

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.

Gebruik deze benadering om over te stappen op de conceptuele architectuur van de Azure-landingszone:

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 de ontwerpprincipes en aanbevelingen van de Azure-landingszone. Het zorgt er ook voor dat deze wijzigingen geen invloed hebben op de bestaande omgeving.

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

2. Als u de beheergroep voor landingszones en de onderliggende groepen (corp en online in het volgende diagram) wilt dupliceren, inclusief alle beleidstoewijzingen, configureert u deze zodanig dat deze alleen worden gecontroleerd. Stel op de beleidstoewijzingen de eigenschap enforcementMode in op DoNotEnforce of Disabled.

   Deze benadering biedt snelle toegang tot de nieuwe gewenste doelarchitectuur. Vervolgens kunnen de toepassingenteams het beleid beoordelen zonder dat dit van invloed is op actieve toepassingen.

   

   Notitie

   Deze benadering heeft geen extra kosten, omdat deze alleen de hiërarchie van de beheergroep en het toegewezen beleid dupliceren, niet de workloads.

3. (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 gedupliceerde beheergroephiërarchie plaatsen onder de juiste beheergroep, zoals corporate brownfield of online brownfield in dit voorbeeld.

   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.

4. Nadat de toepassingsteams met de platformteams hebben gewerkt om hun beleidsnaleving in de vereiste status te krijgen, worden hun abonnementen verplaatst naar de juiste beheergroep, zoals zakelijk of online in het volgende diagram. Ze worden gedekt door het toegewezen beleid en uw team kan hun workload efficiënt en compatibel uitvoeren.

   Zie Uw landingszone voorbereiden voor migratierichtlijnen voor meer informatie.

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

Samenvatting

U hebt deze benadering gebruikt om uw workloads veilig te migreren in Azure door de conceptuele architectuur van de Azure-landingszone parallel met uw bestaande omgeving te implementeren met minimale onderbrekingen.