Scenario: Överföra en regional organisationsmiljö till den konceptuella arkitekturen i Azure-landningszonen
I den här artikeln beskrivs överväganden och instruktioner för att migrera och överföra din Azure-miljö till den konceptuella arkitekturen i Azure-landningszonen. Det här scenariot omfattar en regional organisation med hanteringsgrupper som är uppdelade i utvecklings-, testnings- och produktionsmiljöer (dev/test/prod).
I det här scenariot har kunden ett stort fotavtryck i Azure. De har en hanteringsgruppshierarki som organiseras av utvecklings-/test-/prod-miljöer och sedan efter region. Deras nuvarande implementering begränsar skalbarheten och tillväxten. De har program distribuerade över hela världen. Ett centralt IT-team hanterar varje region. I det här scenariot är regionerna Amerika; Europa, Mellanöstern och Afrika (EMEA); Asien-Stillahavsområdet (APAC).
Kunden vill flytta från sin befintliga miljö till den konceptuella arkitekturen för Azure-landningszoner. Den här metoden stöder deras molnstrategi och har en robust plattform som skalar när kunden drar tillbaka sina lokala datacenter.
Aktuell status
I det här scenariot består det aktuella tillståndet för kundens Azure-miljö av:
- Flera hanteringsgrupper.
- En hanteringsgruppshierarki baserad på utvecklings-/test-/prod-miljöer på den första nivån och sedan baserat på geografi på den andra nivån.
- En Azure-prenumeration för varje geografi och programmiljö, till exempel dev/test/prod. Den här prenumerationen krävs för att ge utvecklare en avslappnad miljö för testning och innovation.
- Vissa kritiska arbetsbelastningar som behöver samma styrningsmodell i dev/test/prod, vilket kan skapa styrningsutmaningar för kunden.
- Icke-enhetlig resursdistribution. Plattforms- och arbetsbelastningsresurser för en enda miljö distribueras i samma Azure-prenumerationer.
- Program som distribueras till respektive prenumeration baserat på deras region- och miljöklassificering, till exempel dev/test/prod.
- Principtilldelningar, till exempel granskningseffekter och nekandeeffekter, som tilldelas på hanteringsgrupps- och prenumerationsnivå.
- Samma uppsättning Azure-principer som tillämpas på alla program i samma region och i samma miljötyp.
- Rolltilldelningar för rollkontroll för varje prenumeration och resursgrupp.
- Ett virtuellt navnätverk, till exempel Azure VPN Gateway eller Azure ExpressRoute, för hybridanslutning.
- Ett virtuellt nätverk för varje programmiljö.
- Ett centralt IT-team som styr och driver respektive hanteringsgrupp för varje region. Teamet står inför vissa problem med konsekvens, konfiguration och efterlevnad när det gäller principer, åtkomstkontroll, konfiguration av plattformsresurser och säkerhetsefterlevnad eftersom vissa program distribueras till flera regioner.
Följande diagram visar det aktuella tillståndet för det här exempelscenariot.
Övergång till konceptuell arkitektur för Azure-landningszonen
Innan du implementerar den här metoden kan du läsa konceptuell arkitektur för Azure-landningszoner, designprinciper för Azure-landningszoner och designområden för Azure-landningszoner.
Om du vill övergå från det här scenariots aktuella tillstånd till en konceptuell arkitektur för Azure-landningszoner använder du den här metoden:
Distribuera Azure-landningszonacceleratorn till samma Microsoft Entra ID-klientorganisation parallellt med den aktuella miljön. Den här metoden ger en smidig och stegvis övergång till den nya landningszonens arkitektur med minimala störningar för aktiva arbetsbelastningar.
Den här distributionen skapar en ny hanteringsgruppsstruktur. Den här strukturen överensstämmer med designprinciper och rekommendationer för Azure-landningszoner. Det säkerställer också att dessa ändringar inte påverkar den befintliga miljön.
Mer information finns i Hantera en landningszon för dev/test/prod-arbetsbelastning.
Information om hur du använder gruphierarki för sandbox-hantering för att ge utvecklare möjlighet att testa och experimentera utan att påverka andra miljöer finns i Vägledning för sandbox-miljöer i Azure Landing-zonen.
Information om hur du minimerar avbrott i program och tjänster under migreringen finns i Anta principdrivna riktlinjer för skyddsräcken.
(Valfritt) Arbeta med program- eller tjänstteam för att migrera de arbetsbelastningar som distribueras i de ursprungliga prenumerationerna till nya Azure-prenumerationer. Mer information finns i Överföra befintliga Azure-miljöer till den konceptuella arkitekturen i Azure-landningszonen. Du kan placera arbetsbelastningar i den nyligen distribuerade konceptuella hierarkin för azure-landningszonens arkitekturhanteringsgrupp under rätt hanteringsgrupp, till exempel företag eller online i följande diagram.
Mer information om effekten på resurser vid migrering finns i Principer.
Så småningom kan du avbryta den befintliga Azure-prenumerationen och placera den i den inaktiverade hanteringsgruppen.
Kommentar
Du behöver inte nödvändigtvis migrera befintliga program eller tjänster till nya landningszoner eller Azure-prenumerationer.
Skapa nya Azure-prenumerationer för att tillhandahålla landningszoner som kan stödja nya program och arbetsbelastningar. Placera dem under rätt hanteringsgrupp, till exempel företag eller online i följande diagram.
Mer information finns i Förbereda landningszonen för migreringsvägledning.
Följande diagram visar tillståndet för det här scenariot under migreringen.
Sammanfattning
I det här scenariot etablerade kunden den grund som krävs för att stödja deras tillväxt- och skalningsplaner för sina arbetsbelastningar i Azure genom att distribuera konceptarkitekturen i Azure-landningszonen parallellt med sin befintliga miljö.