Scenario: eseguire la transizione di un ambiente duplicando un gruppo di gestione della zona di destinazione
Questo articolo descrive un approccio di esempio che esegue la transizione di un ambiente all'architettura concettuale della zona di destinazione di Azure duplicando il gruppo di gestione della zona di destinazione con criteri in modalità di controllo. Con questo approccio, è possibile accedere rapidamente alla nuova architettura di destinazione desiderata e quindi valutare le sottoscrizioni dell'applicazione o del carico di lavoro per la conformità. Questo approccio elimina il rischio di influire sui team dell'applicazione perché i criteri sono in modalità solo di controllo.
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.
Usare questo approccio per passare all'architettura concettuale della zona di destinazione di Azure:
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 della zona di destinazione di Azure. Garantisce inoltre che queste modifiche non influiscano sull'ambiente esistente.
Per informazioni su come ridurre al minimo le interruzioni delle applicazioni e dei servizi durante la migrazione, vedere Adottare protezioni guidate dai criteri.
Per duplicare il gruppo di gestione della zona di destinazione e i relativi elementi figlio (corp e online nel diagramma seguente), incluse tutte le assegnazioni di criteri, configurarle per controllare solo la modalità. Nelle assegnazioni di criteri impostare la proprietà enforcementMode su
DoNotEnforceoDisabled.Questo approccio consente di accedere rapidamente alla nuova architettura di destinazione desiderata. I team delle applicazioni possono quindi valutare i criteri senza il rischio di influire sulle applicazioni attive.
Nota
Questo approccio non comporta costi aggiuntivi perché duplica solo la gerarchia dei gruppi di gestione e i criteri assegnati, non i carichi di lavoro.
(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 appena duplicati nel gruppo di gestione corretto, ad esempio brownfield aziendale o brownfield online in questo esempio.
Per informazioni 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.
Dopo che i team dell'applicazione collaborano con i team della piattaforma per ottenere la conformità dei criteri allo stato richiesto, le sottoscrizioni vengono spostate nel gruppo di gestione appropriato, ad esempio aziendale o online nel diagramma seguente. Sono coperti dai criteri assegnati e il team può gestire in modo efficiente e conforme il carico di lavoro.
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
Questo approccio è stato usato per eseguire la migrazione sicura dei carichi di lavoro in Azure distribuendo l'architettura concettuale della zona di destinazione di Azure in parallelo con l'ambiente esistente con interruzioni minime.