Preparare l'ambiente per uno scenario ibrido e multicloud

  • Articolo

La metodologia Ready di Cloud Adoption Framework guida i clienti durante la preparazione dell'ambiente per l'adozione del cloud. La metodologia include acceleratori tecnici come le zone di destinazione di Azure, che sono i blocchi predefiniti di qualsiasi ambiente di adozione del cloud di Azure.

Questa guida consente di scegliere la zona di destinazione appropriata da distribuire per l'organizzazione.

Ibrido e multicloud nelle zone di destinazione

Le zone di destinazione di Azure sono l'output di un ambiente Di Azure multisubscription che account per:

  • Ridimensiona
  • Governance della sicurezza
  • Rete
  • Identità
  • Gestione costi
  • Monitoraggio

Le considerazioni sull'ambiente potrebbero essere leggermente diverse quando si prepara per una distribuzione ibrida e multicloud. Un ambiente coerente per qualsiasi distribuzione ibrida e multicloud richiede di prendere in considerazione:

  • Topologia di rete e connettività
  • Controlli unificati dei processi operativi per operazioni, governance, sicurezza e conformità
  • Discipline di automazione unificate e coerenti, esperienza di sviluppo e procedure DevOps in ambienti eterogenei

Azure Arc consente architetture ibride e multicloud e contiene un set di tecnologie. Ogni architettura che consente di includere tutte le aree di progettazione critiche e le considerazioni necessarie per creare una distribuzione corretta.

Valutare la combinazione di cloud

La scelta di un ambiente ibrido e multicloud comporta una serie di decisioni anziché una singola decisione binaria. Prima di configurare l'ambiente di Azure, identificare il modo in cui l'ambiente cloud supporterà la combinazione specifica di scelte di hosting cloud. Il diagramma seguente contiene alcuni esempi di combinazioni di cloud comuni:

Diagramma che mostra tre illustrazioni del modo in cui i diversi clienti distribuiscono i carichi di lavoro tra provider di servizi cloud.

In questo diagramma ogni punto blu scuro è un carico di lavoro e ogni cerchio blu chiaro è un processo aziendale supportato da un ambiente distinto.

Ogni combinazione di cloud richiede una configurazione diversa dell'ambiente di Azure. È possibile visualizzare questa operazione con i tre clienti di riferimento:

  • Cliente basato sull’ibrido: la maggior parte dei carichi di lavoro rimane in locale, spesso in una combinazione di modelli di hosting di asset tradizionali, ibridi e portabili. Alcuni carichi di lavoro specifici vengono distribuiti nella rete perimetrale, in Azure o in altri provider di servizi cloud.

    • Fabrikam è un cliente ibrido-first con un notevole investimento nei data center di invecchiamento. Le priorità più elevate sono costi e governance. Le priorità IT legacy e l'infrastruttura tecnologica obsoleta ostacolano l'innovazione di Fabrikam, che determina un'adozione anticipata del cloud.

  • Cliente azure-first: la maggior parte dei carichi di lavoro passa ad Azure, mentre alcuni carichi di lavoro rimangono in locale. Le decisioni strategiche portano a pochi carichi di lavoro che vivono sul perimetro o in ambienti multicloud.

    • Contoso è un cliente azure-first . Come Fabrikam, ha completato la sua prima ondata di trasformazione digitale, ha acquisito alcune aziende e ha aggiunto clienti in settori regolamentati. La priorità più alta è ancora l'innovazione, ma con il suo ambiente multicloud, si concentra sulla gestione delle operazioni. Ha bisogno di operazioni efficienti e scalabili per continuare la strategia di acquisizione.

  • Cliente multicloud-first: la maggior parte dei carichi di lavoro è ospitata in un cloud pubblico diverso, ad esempio Google Cloud Platform (GCP) o Amazon Web Services (AWS). Le decisioni strategiche portano a pochi carichi di lavoro che vivono in Azure o in edge. I clienti passano spesso da una combinazione ibrida-first a una combinazione di Azure-first man mano che la strategia cloud matura, ma supportiamo anche i clienti che decidono di creare combinazioni ibride o multicloud la loro priorità. Azure svolge un ruolo in ogni tipo di combinazione.

    • Tailwind Traders è un cliente multicloud- first . Come Contoso, è stato spostato nel cloud, ma non è stato usato Azure per farlo. Include alcuni asset del data center locale e dispositivi perimetrali. Tailwind Traders è un early adopter di altri cloud in una fase iniziale di avvio e la sua priorità principale è la crescita. Requisiti per la vendita al dettaglio dei clienti e la necessità di operazioni migliorate che consentono una scalabilità efficiente per la crescita ibrida e multicloud.

Alcune considerazioni sono fondamentali per preparare qualsiasi ambiente cloud per il cloud ibrido e multicloud. La strategia ibrida e multicloud per le applicazioni e i dati determina le risposte alle domande seguenti. Identificare chiaramente la combinazione di cloud necessaria, quindi considerare la configurazione migliore per gli ambienti.

  • Quale combinazione di ambienti ibridi, perimetrali e multi-cloud è attualmente supportata?
  • Quale combinazione si adatta meglio alla strategia per il futuro?
  • Si vuole gestire ogni piattaforma in modo indipendente o tramite operazioni unificate e un unico approccio in vetro?

Panoramica di Azure Arc

È possibile semplificare ambienti complessi e distribuiti in ambienti locali, perimetrali e multicloud. Azure Arc consente di distribuire i servizi di Azure ovunque e di estendere la gestione di Azure a qualsiasi infrastruttura.

  • Organizzare e gestire in ambienti diversi: ottenere database, cluster Kubernetes e server che si estendono in ambienti locali, perimetrali e multicloud sotto controllo tramite l'organizzazione centrale e la governance da un'unica posizione.

  • Gestire le applicazioni Kubernetes su larga scala: usare le tecniche DevOps per distribuire e gestire applicazioni Kubernetes in ambienti diversi. Assicurarsi di distribuire e configurare in modo coerente le applicazioni dal controllo del codice sorgente.

  • Eseguire i servizi di Azure ovunque: ottenere patch automatizzate, aggiornamenti, sicurezza e scalabilità su richiesta in ambienti locali, perimetrali e multicloud per il proprio patrimonio di dati.

  • Abilitare l'accesso self-service alle macchine virtuali: usare il controllo degli accessi in base al ruolo di Azure per concedere la possibilità self-service alle risorse VMware vSphere e System Center Virtual Machine Manager tramite Azure. Eseguire tutte le operazioni del ciclo di vita e del ciclo di alimentazione delle macchine virtuali da portale di Azure e automatizzare le operazioni tramite modelli, API e SDK di Azure.

Snapshot del cliente di Azure Arc

Tutti e tre i clienti di riferimento menzionati in precedenza eseguono carichi di lavoro su hardware diverso. Eseguono anche carichi di lavoro tra data center locali e più provider di cloud pubblici e supportano i carichi di lavoro IoT distribuiti sul perimetro. I carichi di lavoro includono vari servizi e si basano su server bare metal, macchine virtuali, piattaforme gestite come servizio (PaaS) o applicazioni basate su contenitori native del cloud.

Tutti e tre i clienti si rendono conto che devono avere procedure consolidate ibride e multicloud per ottenere il successo aziendale. La necessità di carichi di lavoro modernizzati sta diventando fondamentale per la pertinenza di tutti e tre i clienti nelle aree rispettate.

Con Azure Arc come piano di controllo ibrido e multicloud, questi clienti possono usare gli investimenti IT esistenti e le procedure operative correnti in modo non distribuzioni. Per continuare a usare le procedure correnti, i clienti eseguono l'onboarding di queste risorse:

  • Server abilitati per Azure Arc, VMware vSphere abilitato per Azure Arc o System Center Virtual Machine Manager abilitato per Azure Arc
  • Server SQL
  • Cluster Kubernetes

Usano i servizi dati abilitati per Azure Arc, i servizi delle applicazioni e i servizi di Machine Learning per modernizzare i carichi di lavoro garantendo al tempo stesso che soddisfino ancora i requisiti di sovranità dei dati.

Azure Arc estende le API di Azure Resource Manager (ARM) in modo da poter rappresentare qualsiasi carico di lavoro come cittadino di prima classe in Azure. Questa estensione offre le basi per implementare operazioni unificate, gestione, conformità, sicurezza e governance su larga scala. Viene implementato con:

  • Monitoraggio centralizzato
  • Registrazione
  • Telemetria
  • Criteri
  • Gestione delle patch
  • Rilevamento modifiche
  • Gestione articoli
  • Rilevamento delle minacce
  • Gestione delle vulnerabilità di sicurezza e controllo

Diagramma che mostra la panoramica di Azure Arc.

Configurare l'ambiente Azure iniziale

Per ogni combinazione di cloud, è necessario un ambiente Azure per supportare, gestire e gestire le risorse cloud. La metodologia Ready di Cloud Adoption Framework offre alcuni passaggi per preparare l'ambiente:

Azure Arc come acceleratore di zona di destinazione

Le risorse di Azure Arc possono far parte di qualsiasi applicazione. Alcuni esempi:

  • Server abilitati per Azure Arc, VMware vSphere abilitato per Azure Arc e System Center Virtual Machine Manager abilitato per Azure Arc, che rappresentano gli asset IT distribuiti all'esterno di Azure. Servizi azure Arc creati appositamente, ad esempio VMware vSphere abilitato per Azure Arc e System Center Virtual Machine Manager abilitato per Azure Arc, proiettare gli asset IT distribuiti in vCenter e System Center Virtual Machine Manager gestiti nei data center locali in Azure.
  • Cluster Kubernetes gestiti dal cliente in un ambiente multicloud.
  • Dati, applicazioni e servizi di Machine Learning abilitati per Azure Arc che funzionano all'perimetro.

Le sottoscrizioni dell'area di destinazione dell'applicazione possono contenere anche risorse di Azure Arc e risorse di Azure normali.

Poiché le risorse di Azure Arc si trovano all'esterno di Azure, è possibile considerarle una risorsa di metadati nel modo in cui sono rappresentate in Azure. Considerare le risorse di Azure Arc come qualsiasi altra risorsa di Azure che può far parte della zona di destinazione. Non importa se si tratta di una piattaforma o di un'applicazione e segue i principi di progettazione incentrati sulle sottoscrizioni e incentrati sulle applicazioni e sugli archetipi.

Diagramma che mostra la progettazione di una zona di destinazione.

Esempi comuni di risorse di Azure Arc nelle zone di destinazione di Azure

Gli esempi seguenti illustrano come proiettare le risorse di Azure Arc come risorse di metadati nelle zone di destinazione di Azure.

Esempio 1: Projecting domain controllers outside of Azure (Progetto di controller di dominio all'esterno di Azure)

Molti clienti hanno distribuzioni Dominio di Active Directory Services (AD DS) all'interno dei propri ambienti. I controller di dominio sono un componente critico di Servizi di dominio Active Directory e l'architettura complessiva dei clienti.

All'interno dell'architettura concettuale della zona di destinazione di Azure è disponibile una sottoscrizione della zona di destinazione delle identità dedicata progettata per ospitare risorse basate sull'identità. È possibile ospitare questa sottoscrizione in Azure usando macchine virtuali (VM) del controller di dominio Active Directory Domain Services. È anche possibile proiettarlo in Azure da qualsiasi altra posizione tramite server abilitati per Azure Arc.

Esempio due: Projecting on-premises datacenters into Azure (Progetto di data center locali in Azure)

La maggior parte dei clienti ha ancora data center locali presenti nei propri ambienti. I footprint di questi data center possono variare da server singoli a ambienti virtualizzati di grandi dimensioni.

I clienti possono trattare i data center locali come normali zone di destinazione e inserirli in zone di destinazione nuove o esistenti in base alle esigenze. Alcuni approcci comuni includono:

  • Spostamento delle risorse del progetto in sottoscrizioni di zone di destinazione dedicate per le risorse del data center locale.
    • In ambienti più grandi con più data center in tutto il mondo, i clienti potrebbero avere una zona di destinazione per ogni area geopolitica. Queste zone di destinazione contengono anche le risorse di tale area per fornire una separazione logica dei data center locali in Azure.
    • Questo approccio può anche essere utile per i requisiti di sicurezza, governance e conformità per data center locali diversi.
  • Spostamento delle risorse del progetto in sottoscrizioni di zone di destinazione separate in base ad altre risorse di Azure che supportano la stessa applicazione o servizio.

Esempio tre: Projecting remote application resources into Azure (Progetto di risorse dell'applicazione remota in Azure)

I clienti possono sviluppare applicazioni o applicazioni sensibili alla latenza con requisiti di sovranità dei dati. Queste applicazioni possono dover ospitare risorse che fanno parte dell'applicazione all'esterno di Azure. I clienti vogliono comunque controllare, gestire, proteggere e gestire in modo centralizzato tutte le risorse che creano l'applicazione. Azure Arc consente ai clienti di raggiungere questo obiettivo.

In questo scenario, i clienti devono proiettare le risorse di Azure Arc per l'applicazione nella stessa sottoscrizione dell'area di destinazione dell'applicazione in cui distribuiscono le risorse di Azure. I clienti possono quindi applicare un set di controlli a tutte le risorse da un singolo piano di controllo indipendentemente dalla posizione in cui si trovano le risorse.

Esempio quattro: Projecting on-premises servers that reached end of support into Azure to use Extended Security Updates delivered through Azure Arc (Progetto di server locali che hanno raggiunto la fine del supporto in Azure per usare gli aggiornamenti della sicurezza estesi distribuiti tramite Azure Arc)

Molti clienti hanno versioni di Windows Server prossime alla fine del supporto e non possono soddisfare la scadenza di fine del supporto, ma devono rimanere in locale. In questo scenario si cercherebbe di acquistare gli aggiornamenti della sicurezza estesi abilitati da Azure Arc.

Se i clienti distribuiscono una zona di destinazione di Azure o ne hanno già una distribuita, i clienti possono trattare i data center locali come normali zone di destinazione e inserirle in zone di destinazione nuove o esistenti in base alle esigenze. Alcuni approcci comuni includono:

  • Spostamento delle risorse del progetto in sottoscrizioni di zone di destinazione dedicate per le risorse del data center locale.

  • In ambienti più grandi con più data center in tutto il mondo, i clienti potrebbero avere una zona di destinazione per ogni area geopolitica. Queste zone di destinazione contengono anche le risorse di tale area per fornire una separazione logica dei data center locali in Azure.

  • Questo approccio può anche essere utile per i requisiti di sicurezza, governance e conformità per data center locali diversi.

  • Spostamento delle risorse del progetto in sottoscrizioni di zone di destinazione separate in base ad altre risorse di Azure che supportano la stessa applicazione o servizio.

  • I clienti devono esaminare le linee guida per l'acceleratore di zona di destinazione dei server abilitati per Azure Arc per esaminare le considerazioni di progettazione e le raccomandazioni nelle aree di progettazione critiche.

Se i clienti non hanno o non prevedono di distribuire una zona di destinazione di Azure al momento:

  • I clienti devono esaminare le linee guida per l'acceleratore di zona di destinazione dei server abilitati per Azure Arc per esaminare le considerazioni di progettazione e le raccomandazioni nelle aree di progettazione critiche.

Diagramma che mostra un grafico di flusso per le linee guida per la zona di destinazione di Azure Arc.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti.