Scenario: Transizione di un ambiente dell'organizzazione a livello di area all'architettura concettuale della zona di destinazione di Azure

Questo articolo descrive le considerazioni e le istruzioni per eseguire la migrazione e la transizione dell'ambiente Di Azure nell'architettura concettuale della zona di destinazione di Azure. Questo scenario riguarda un'organizzazione a livello di area con gruppi di gestione separati in ambienti di sviluppo, test e produzione (sviluppo/test/prod).

In questo scenario, il cliente ha un footprint elevato in Azure. Hanno una gerarchia di gruppi di gestione organizzata in base a ambienti di sviluppo/test/produzione e quindi in base all'area. L'implementazione corrente limita la scalabilità e la crescita. Hanno applicazioni distribuite in tutto il mondo. Un team IT centrale gestisce ogni area. In questo scenario le regioni sono America; Europa, Medio Oriente e Africa (EMEA); e Asia-Pacifico (APAC).

Il cliente vuole passare dall'ambiente esistente all'architettura concettuale delle zone di destinazione di Azure. Questo approccio supporta la prima strategia cloud e offre una solida piattaforma scalabile quando il cliente ritira i data center locali.

Stato corrente

In questo scenario, lo stato corrente dell'ambiente Azure del cliente è costituito da:

• Più gruppi di gestione.
• Gerarchia di gruppi di gestione basata su ambienti di sviluppo/test/produzione al primo livello e quindi in base all'area geografica al secondo livello.
• Una sottoscrizione di Azure per ogni ambiente geografico e dell'applicazione, ad esempio sviluppo/test/prod. Questa sottoscrizione è necessaria per fornire agli sviluppatori un ambiente rilassato per il test e l'innovazione.
• Alcuni carichi di lavoro critici che necessitano dello stesso modello di governance tra sviluppo/test/produzione, che possono creare sfide di governance per il cliente.
• Distribuzione delle risorse non univoca. Le risorse della piattaforma e del carico di lavoro per un singolo ambiente vengono distribuite nelle stesse sottoscrizioni di Azure.
• Applicazioni distribuite nelle rispettive sottoscrizioni in base all'area geografica e alla classificazione dell'ambiente, ad esempio sviluppo/test/produzione.
• Assegnazioni di criteri, ad esempio effetti di controllo e effetti di negazione, assegnati a livello di gruppo di gestione e sottoscrizione.
• Lo stesso set di criteri di Azure applicato a tutte le applicazioni nella stessa area e nello stesso tipo di ambiente.
• Assegnazioni di ruolo di controllo degli accessi in base al ruolo per ogni sottoscrizione e gruppo di risorse.
• Una rete virtuale hub, ad esempio Azure Gateway VPN o Azure ExpressRoute, per la connettività ibrida.
• Una rete virtuale per ogni ambiente dell'applicazione.
• Un team IT centrale che controlla e gestisce il rispettivo gruppo di gestione per ogni area. Il team affronta alcune problematiche di coerenza, configurazione e conformità quando si tratta di criteri, controllo di accesso, configurazione delle risorse della piattaforma e conformità alla sicurezza perché alcune applicazioni vengono distribuite in più aree.

Il diagramma seguente illustra lo stato corrente di questo scenario di esempio.

Transizione all'architettura concettuale della zona di destinazione di Azure

Prima di implementare questo approccio, esaminare l'architettura concettuale della zona di destinazione di Azure, i principi di progettazione della zona di destinazione di Azure e le aree di progettazione della zona di destinazione di Azure.

Per passare dallo stato corrente di questo scenario a un'architettura concettuale della zona di destinazione di Azure, usare questo approccio:

1. Distribuire l'acceleratore di zona di destinazione di Azure nello stesso tenant di Microsoft Entra ID in parallelo con l'ambiente corrente. Questo metodo fornisce una transizione graduale e graduale alla nuova architettura della zona di destinazione con un'interruzione minima dei carichi di lavoro attivi.

   Questa distribuzione crea una nuova struttura del gruppo di gestione. Questa struttura è allineata ai principi di progettazione e alle raccomandazioni delle zone di destinazione di Azure. Garantisce inoltre che queste modifiche non influiscano sull'ambiente esistente.

   Per altre informazioni, vedere Come gestire una zona di destinazione di sviluppo/test/produzione del carico di lavoro.

   Per informazioni sull'uso della gerarchia dei gruppi di gestione sandbox per consentire agli sviluppatori di testare e sperimentare senza influire sugli altri ambienti, vedere Linee guida per gli ambienti sandbox della zona di destinazione di Azure.

   Per informazioni su come ridurre al minimo le interruzioni delle applicazioni e dei servizi durante la migrazione, vedere Adottare linee guida per la protezione basata su criteri.

2. (Facoltativo) Collaborare con i team di applicazioni o servizi per eseguire la migrazione dei carichi di lavoro distribuiti nelle sottoscrizioni originali in nuove sottoscrizioni di Azure. Per altre informazioni, vedere Eseguire la transizione di ambienti di Azure esistenti all'architettura concettuale della zona di destinazione di Azure. È possibile inserire i carichi di lavoro nella gerarchia dei gruppi di gestione dell'architettura concettuale della zona di destinazione di Azure appena distribuita nel gruppo di gestione corretto, ad esempio aziendale o online nel diagramma seguente.

   Per informazioni dettagliate sull'effetto sulle risorse durante la migrazione, vedere Criteri.

   Infine, è possibile annullare la sottoscrizione di Azure esistente e inserirla nel gruppo di gestione rimosso.

   Nota

   Non è necessario eseguire necessariamente la migrazione delle applicazioni o dei servizi esistenti in nuove zone di destinazione o nelle sottoscrizioni di Azure.

3. Creare nuove sottoscrizioni di Azure per fornire zone di destinazione in grado di supportare nuove applicazioni e carichi di lavoro. Inserirli nel gruppo di gestione appropriato, ad esempio aziendale o online nel diagramma seguente.

   Per altre informazioni, vedere Preparazione della zona di destinazione per indicazioni sulla migrazione.

Il diagramma seguente illustra lo stato di questo scenario durante la migrazione.

Riepilogo

In questo scenario, il cliente ha stabilito le basi necessarie per supportare i piani di crescita e scalabilità per i carichi di lavoro in Azure distribuendo l'architettura concettuale della zona di destinazione di Azure in parallelo all'ambiente esistente.