Scenario: Transizione dei gruppi di gestione all'architettura concettuale della zona di destinazione di Azure

Questo articolo descrive considerazioni e istruzioni per eseguire la migrazione e la transizione dell'ambiente esistente nell'architettura concettuale delle zone di destinazione di Azure. Questo scenario riguarda singoli o più gruppi di gestione.

In questo scenario si presuppone che il cliente usi già Azure. Hanno una gerarchia di gruppi di gestione con più sottoscrizioni che ospitano alcune applicazioni o servizi all'interno della piattaforma. L'implementazione attuale limita tuttavia la scalabilità e la crescita correlate alla prima strategia cloud.

Nell'ambito di questa espansione, prevede di eseguire la migrazione dai data center locali e in Azure. Durante la migrazione, conducono alla modernizzazione e alla trasformazione delle applicazioni o dei servizi per l'uso delle tecnologie native del cloud, ove possibile. ad esempio il database SQL di Azure e il servizio Azure Kubernetes. Sanno che ci vuole molto tempo e sforzo, quindi si prevede di sollevare e spostare per iniziare. Inizialmente, questo piano richiede la connettività ibrida tramite servizi come Azure Gateway VPN o Azure ExpressRoute.

Il cliente vuole spostare l'ambiente esistente nell'architettura concettuale delle zone di destinazione di Azure. Questa architettura 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:

• Uno o più gruppi di gestione.
• Gerarchia di gruppi di gestione basata sulla struttura organizzativa o sull'area geografica.
• Una sottoscrizione di Azure per ogni ambiente dell'applicazione, ad esempio sviluppo, test o produzione (sviluppo/test/prod).
• 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.
• Assegnazioni di criteri con effetti di controllo e effetti di negazione assegnati a livello di gruppo di gestione e sottoscrizione.
• 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.
• Applicazioni distribuite nella rispettiva sottoscrizione in base alla classificazione dell'ambiente, ad esempio sviluppo, test o produzione.
• Un team IT centrale che controlla e gestisce l'ambiente.

Il diagramma seguente illustra lo stato corrente di questo scenario.

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 l'approccio seguente:

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.

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 un ambiente azure esistente 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 che supportano i progetti di migrazione dall'ambiente locale. Inserirli nel gruppo di gestione appropriato, ad esempio aziendale o online nel diagramma seguente.

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

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

Riepilogo

In questo scenario, il cliente ha eseguito i piani di espansione e scalabilità all'interno di Azure distribuendo l'architettura concettuale della zona di destinazione di Azure parallela all'ambiente esistente.