Scenario: eseguire la transizione di una singola sottoscrizione senza gruppi di gestione 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 copre una singola sottoscrizione senza gruppi di gestione.

In questo scenario, il cliente usa già Azure e ospita già 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 passare dall'approccio esistente a un'architettura su scala aziendale. Questa architettura supporta la prima strategia cloud e offre una solida piattaforma scalabile man mano che il cliente elimina i data center locali.

Stato corrente

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

• Una singola sottoscrizione di Azure.
• Nessun gruppo di gestione personalizzato.
• Distribuzione delle risorse non univoca. Le risorse della piattaforma e del carico di lavoro vengono distribuite nella stessa sottoscrizione di Azure.
• Utilizzo minimo di Criteri di Azure. Le assegnazioni di criteri, ad esempio gli effetti di controllo e gli effetti di negazione, vengono eseguite per ogni gruppo di risorse, con eccezioni.
• Gruppi di risorse trattati come unità di gestione e scalabilità.
• Assegnazioni di ruolo di controllo degli accessi in base al ruolo per ogni gruppo di risorse.
• Una singola rete virtuale.
  • Nessuna connettività ibrida tramite servizi come Azure Gateway VPN o Azure ExpressRoute.
  • Viene creata una nuova subnet per ogni applicazione.
• Più applicazioni autonome in ognuno dei gruppi di risorse app-xx-rg . Le applicazioni sono controllate e gestite da team di applicazioni o servizi diversi.

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 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.

2. (Facoltativo) Collaborare con i team dell'applicazione o del servizio per eseguire la migrazione dei carichi di lavoro distribuiti nella sottoscrizione originale 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 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 indicazioni sulla 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 in parallelo all'ambiente esistente.