Automazione della piattaforma per uno scenario a livello aziendale della soluzione Azure VMware

La zona di destinazione a livello aziendale adotta una serie di procedure consigliate per l'automazione e DevOps, che possono essere utili per la distribuzione di un cloud privato della soluzione Azure VMware. Questa guida presenta una serie di considerazioni di carattere generale per la distribuzione iniziale della soluzione Azure VMware e offre anche indicazioni per l'automazione operativa. L'implementazione è conforme all'architettura e alle procedure consigliate di Cloud Adoption Framework, con particolare attenzione alla progettazione per la scalabilità.

La soluzione illustrata è composta da due parti principali. La prima parte include indicazioni sulle procedure di distribuzione e automazione per la soluzione Azure VMware. La seconda parte comprende un set di artefatti open source che è possibile adattare per facilitare la distribuzione del cloud privato. Anche se questa soluzione ha lo scopo di avviare un percorso di automazione end-to-end, un'organizzazione può decidere quali componenti distribuire manualmente in base alle considerazioni riportate in questo articolo.

soluzione Azure VMware'automazione dell'acceleratore di zona di destinazione è progettata per iniziare a distribuire soluzione Azure VMware usando i modelli e gli script all'interno di questo repository. Prima di procedere alla distribuzione, è consigliabile esaminare i modelli per acquisire informazioni sulle risorse distribuite e sui costi associati.

Questo articolo include considerazioni e consigli relativi alle aree seguenti:

• Opzioni di distribuzione per la soluzione Azure VMware, sia manuale che automatizzata.
• Considerazioni a livello di automazione e dettagli sull'implementazione.
• Considerazioni per l'automazione a livello di SDDC di VMware all'interno di un cloud privato.
• Consigli sugli approcci di automazione estesi da una zona di destinazione aziendale.
• Considerazioni sulle tecnologie di automazione da usare per la distribuzione e la gestione, ad esempio l'interfaccia della riga di comando di Azure, Azure Resource Manager, Bicep e PowerShell.

Strategia di distribuzione

soluzione Azure VMware possono essere distribuiti manualmente o usando strumenti automatizzati curati.

Distribuzione manuale

È possibile configurare e distribuire graficamente un cloud privato della soluzione Azure VMware tramite il portale di Azure. Questa opzione è adatta per le distribuzioni su scala più ridotta. Se si vogliono distribuire topologie della soluzione Azure VMware su scala più ampia in modo ripetibile, prendere in considerazione una distribuzione automatizzata. È anche possibile configurare la connettività al cloud privato e quindi ridimensionarla manualmente tramite il portale di Azure.

Considerazioni:

• È possibile usare distribuzioni manuali per i progetti pilota iniziali e gli ambienti su scala ridotta. Questo tipo di distribuzione è utile anche quando non è disponibile una procedura di automazione o di infrastruttura come codice esistente.
• Quando si distribuiscono soluzione Azure VMware tramite i moduli portale di Azure, interfaccia della riga di comando di Azure o Azure PowerShell, viene visualizzata una serie di termini e condizioni sulla protezione dei dati nella soluzione. Se si usano le API di Azure Resource Manager direttamente o la distribuzione tramite un modello di Azure Resource Manager o Bicep, è consigliabile esaminare questi termini e condizioni prima di distribuire l'automazione.
• Per gli ambienti su richiesta che vengono gestiti in base alle esigenze, è consigliabile automatizzare il processo di creazione del cloud privato della soluzione Azure VMware per limitare il livello di interazione manuale.
• Per monitorare il processo di creazione del cloud privato è possibile usare il pannello per le distribuzioni del gruppo di risorse di destinazione all'interno del portale di Azure. Dopo aver distribuito il cloud privato, verificare che sia attivo lo stato Riuscito prima di procedere. Se il cloud privato mostra lo stato Non riuscito, potrebbe non essere possibile connettersi al server vCenter. In questo caso, potrebbe essere necessario rimuovere il cloud privato e ridistribuirlo.

Raccomandazioni:

• Se si sceglie un metodo di distribuzione manuale, è importante documentare la configurazione usata per effettuare il provisioning del cloud privato. Dopo la distribuzione, scaricare il modello di distribuzione usato ai fini della documentazione. Questo artefatto include il modello ARM usato per distribuire il cloud privato L'artefatto del modello include anche un file di parametri che contiene la configurazione selezionata.
• Se si intende interagire regolarmente con il cloud privato nel portale di Azure, è consigliabile inserire un blocco per limitare l'eliminazione delle risorse. È anche possibile usare blocchi di risorse di sola lettura per limitare le operazioni di scalabilità.

Distribuzione automatica

È possibile usare distribuzioni automatizzate per distribuire gli ambienti basati sulla soluzione Azure VMware in modo ripetibile e quindi progettare e distribuire gli ambienti su richiesta. In questo modo si può usufruire di un meccanismo di distribuzione efficiente per implementare più ambienti e aree su larga scala. È inoltre disponibile un processo di distribuzione a basso rischio, su richiesta e ripetibile.

Opzioni di implementazione soluzione Azure VMware automatizzate

Opzione di implementazione	Descrizione	Collegamento alla distribuzione al repository GitHub
Distribuire soluzione Azure VMware e dipendenze con una connessione ad Azure	Questa distribuzione è più adatta per effettuare il provisioning di un nuovo cloud privato soluzione Azure VMware. Si tratta di una versione completa della distribuzione e consente di creare tutti i diversi componenti di supporto. Questi componenti includono connettività di Azure, monitoraggio e componenti aggiuntivi. Sono disponibili tre opzioni di distribuzione: portale di Azure'interfaccia utente, PowerShell e Terraform. Ogni opzione di distribuzione consente di scegliere di distribuire le risorse seguenti: ▪ soluzione Azure VMware cloud privato ▪ Scegliere Rete virtuale nuova o esistente ▪ Distribuire il server di route di Azure per Connessione VPN (facoltativo) ▪ Distribuire monitoraggio soluzione Azure VMware (facoltativo) ▪ Distribuire HCX e SRM (facoltativo)	(interfaccia utente di portale di Azure) (PowerShell) (modulo Terraform)
Distribuire soluzione Azure VMware senza connessione ad Azure	Questa distribuzione è una versione più leggera. È più adatto per un modello di verifica (POC) o un progetto pilota. Consente di distribuire le risorse seguenti: ▪ Nuovo cloud privato soluzione Azure VMware: (1) nome del gruppo di risorse personalizzato e nome del cloud privato o (2) scegliere un cloud privato soluzione Azure VMware esistente. ▪ Distribuire soluzione Azure VMware Monitoraggio (facoltativo). ▪ Distribuire HCX e SRM (facoltativo).	(interfaccia utente di portale di Azure)

Considerazioni:

• Il completamento di una distribuzione del cloud privato della soluzione Azure VMware potrebbe richiedere diverse ore. Valutare la possibilità di monitorare questo processo usando lo stato della distribuzione di Azure Resource Manager o la proprietà status nel cloud privato. È possibile usare una pipeline di distribuzione o eseguire la distribuzione a livello di codice tramite PowerShell o l'interfaccia della riga di comando di Azure. In tal caso, assicurarsi che siano selezionati i valori di timeout appropriati per consentire il processo di provisioning del cloud privato.
• È possibile allocare in anticipo gli intervalli di indirizzi per i cloud privati e le reti dei carichi di lavoro in base ai consigli riportati in Topologia e connettività di rete. Aggiungerli quindi ai file di configurazione o dei parametri dell'ambiente. La sovrapposizione degli intervalli di indirizzi non viene convalidata in fase di distribuzione. L'assenza di convalida può causare problemi se due cloud privati hanno lo stesso intervallo di indirizzi. I problemi possono verificarsi anche se l'intervallo si sovrappone alle reti esistenti all'interno di Azure o in locale.
• È possibile usare le entità servizio per la distribuzione per fornire l'accesso con privilegi minimi. È inoltre possibile usare il controllo degli accessi in base al ruolo di Azure per limitare l'accesso per il processo di distribuzione.
• Per la distribuzione del cloud privato è possibile adottare una strategia DevOps usando pipeline per le distribuzioni automatizzate e ripetibili senza affidarsi a strumenti locali.

Raccomandazioni:

• Distribuire un cloud privato di dimensioni minime e quindi ridimensionarlo in base alle esigenze.
• Richiedere in anticipo la quota o la capacità dell'host per garantire una corretta distribuzione.
• Monitorare sia il processo di distribuzione sia lo stato del cloud privato prima di distribuire le risorse secondarie. Altri aggiornamenti della configurazione per il cloud privato possono essere elaborati solo quando lo stato del cloud privato è Riuscito. Per i cloud privati con stato Non riuscito, è consigliabile arrestare eventuali altre operazioni e generare un ticket di supporto da risolvere.
• Includere blocchi di risorse pertinenti all'interno della distribuzione automatizzata o assicurarsi che siano applicati tramite criteri.

Connettività automatizzata

Dopo aver distribuito il cloud privato della soluzione Azure VMware, è possibile configurare la connettività tramite ExpressRoute. In questo set di costruzione sono descritti due percorsi critici per la connettività di rete:

• Connettività a una rete virtuale o a un rete WAN virtuale di Azure tramite un gateway di rete virtuale.
• Connettività tra la soluzione Azure VMware e un circuito ExpressRoute esistente tramite Copertura globale.

Per altre informazioni sulle topologie di rete consigliate, vedere Topologia e connettività di rete.

Considerazioni:

• È possibile connettere un cloud privato della soluzione Azure VMware a una rete virtuale di Azure o a un circuito ExpressRoute esistente. Questa connessione annuncia automaticamente le route dalle reti di gestione e da quelle dei carichi di lavoro all'interno del cloud privato. Poiché non sono presenti controlli di sovrapposizione, è consigliabile convalidare le reti annunciate prima di procedere alla connessione.
• È possibile allineare i nomi delle chiavi di autorizzazione ExpressRoute agli schemi di denominazione esistenti per le risorse a cui si connettono. Questo allineamento consente di identificare facilmente le risorse correlate.
• I gateway di rete virtuale ExpressRoute e i circuiti ExpressRoute possono essere presenti in una sottoscrizione diversa da quella del cloud privato della soluzione Azure VMware. Decidere se si vuole che una singola entità servizio abbia accesso a tutte queste risorse o se si vuole tenerle separate.
• La rete del carico di lavoro del data center NSX-T tramite il portale di Azure può distribuire le risorse di rete essenziali in un cloud privato, ma NSX-T Manager offre un maggiore controllo sui componenti del data center NSX-T. Può essere opportuno considerare il livello di controllo necessario sui segmenti di rete.
  • Usare la rete del carico di lavoro NSX-T Data Center all'interno del portale di Azure per configurare le zone DNS (Domain Name System) per l'integrazione DNS privata.
  • Per le topologie di rete che richiedono solo un gateway di livello singolo, usare la rete del carico di lavoro NSX-T Data Center all'interno del portale di Azure.
  • Per le configurazioni avanzate, è possibile usare direttamente NSX-T Manager.
  • Prendere in considerazione il livello di competenza degli amministratori di rete. Se gli amministratori di rete non hanno conoscenza o meno di VMware NSX-T Data Center, prendere in considerazione l'uso del portale di Azure per ridurre i rischi per le operazioni di rete.

Raccomandazioni:

• Se si usano entità servizio separate per la distribuzione della soluzione Azure VMware anziché la configurazione di ExpressRoute, usare Azure Key Vault o un archivio segreti simile per passare le chiavi di autorizzazione tra le distribuzioni, se necessario.
• Esistono limiti al numero di operazioni parallele che possono essere eseguite in qualsiasi momento in un cloud privato della soluzione Azure VMware. Per i modelli che definiscono molte risorse secondarie del cloud privato della soluzione Azure VMware, è consigliabile usare dipendenze per la distribuzione in modo seriale.

Scalabilità automatica

Per impostazione predefinita, un cluster della soluzione Azure VMware ha un numero fisso di host definito in base alle dimensioni del cluster. È possibile modificare a livello di codice la scalabilità per cluster per poter aumentare e ridurre le dimensioni in modo automatico. L'automazione può essere attivata su richiesta, in base a una pianificazione o in risposta agli avvisi di Monitoraggio di Azure.

Considerazioni:

• L'aumento automatizzato del numero di host può offrire maggiore capacità su richiesta, ma è importante considerare il costo di un numero più alto di host. Questo costo è limitato alla quota concessa alla sottoscrizione, ma devono essere previsti limiti manuali.
• Prima di automatizzare la riduzione del numero di host, considerare l'impatto che questo può avere sui carichi di lavoro in esecuzione e sui criteri di archiviazione applicati all'interno del cluster. Ad esempio, i carichi di lavoro con RAID-5 assegnati non possono essere ridimensionati in un cluster a tre nodi. È importante considerare anche l'utilizzo della memoria e delle risorse di archiviazione, poiché questo utilizzo potrebbe bloccare un'operazione di riduzione del cluster.
• Poiché è possibile eseguire una sola operazione di scalabilità alla volta, è importante prendere in considerazione l'orchestrazione delle operazioni di scalabilità tra più cluster.
• Un'operazione di scalabilità della soluzione Azure VMware non è istantanea ed è necessario considerare il tempo necessario per aggiungere un altro nodo a un cluster esistente.
• Le soluzioni e le integrazioni di terze parti potrebbero non prevedere continue operazioni di rimozione e aggiunta di host. È pertanto consigliabile verificare il comportamento di tutti i prodotti di terze parti. In questo modo è possibile assicurarsi che non siano necessari altri passaggi per aggiornare o riconfigurare il prodotto quando vengono aggiunti o rimossi host.

Raccomandazioni:

• Imporre limiti rigorosi per le operazioni di aumento o riduzione del numero di host al di fuori della quota.
• Richiedere la quota in anticipo in modo che non influisca su un'operazione di scalabilità. La quota non è una garanzia di capacità, ma offre la possibilità di distribuire fino a un determinato limite. Esaminare regolarmente il limite di quota per assicurarsi che sia sempre disponibile capacità aggiuntiva.
• Assicurarsi che qualsiasi sistema di scalabilità automatizzato sia monitorato e generi avvisi per segnalare l'esecuzione di un'operazione di scalabilità. In questo modo si ha la garanzia che non avvengano eventi di scalabilità imprevisti.
• Usare le metriche di Monitoraggio di Azure per verificare la capacità del cluster prima di eseguire operazioni di riduzione in modo da assicurarsi che sia disponibile capacità aggiuntiva adeguata. Prestare attenzione alla CPU, alla memoria e alle risorse di archiviazione prima, durante e dopo qualsiasi operazione di scalabilità. Questa attenzione alla capacità garantisce che non influisca sul contratto di servizio.

Integrazione con Azure

Un cloud privato della soluzione Azure VMware può usare anche diversi servizi nativi di Azure. È possibile includere questi servizi all'interno della distribuzione della soluzione Azure VMware oppure distribuirli come componenti separati. Al di fuori dell'ambito di questo articolo, per l'integrazione di questi servizi è consigliabile usare i modelli esistenti all'interno dell'architettura delle zone di destinazione a livello aziendale.

Considerazioni:

Considerare il ciclo di vita della distribuzione di ogni componente che si prevede di automatizzare. I componenti strettamente associati in base al ciclo di vita dovrebbero essere raggruppati, in moda da consentire la distribuzione come singola unità. Separare i componenti con cicli di vita diversi.

Strumenti per l'automazione

Esiste un soluzione Azure VMware cloud privato come risorsa all'interno di Azure Resource Manager, fornendo l'interazione tramite diversi strumenti di automazione. Gli strumenti Microsoft di prima parte generati dalle specifiche di Azure Resource Manager tendono a supportare le funzionalità poco dopo il rilascio. Dal punto di vista dell'automazione, le considerazioni in questo articolo vengono fornite in modo da poter essere applicate a set di strumenti diversi.

Considerazioni:

• Usare strumenti dichiarativi come Azure Resource Manager e modelli Bicep per poter definire la configurazione come singolo artefatto. Gli strumenti da riga di comando e basati su script, come l'interfaccia della riga di comando di Azure e PowerShell, richiedono un approccio passo per passo all'esecuzione, più in linea con la distribuzione manuale.
• Per distribuire la soluzione Azure VMware e i servizi nativi di Azure è possibile usare strumenti di automazione di terze parti come Terraform. È importante assicurarsi che le funzionalità da usare all'interno della soluzione Azure VMware siano attualmente incluse nelle risorse disponibili.
• Quando si usa un approccio basato su script alla distribuzione, considerare sempre le implicazioni dei problemi di distribuzione e del monitoraggio appropriato. Per la soluzione Azure VMware in particolare, è consigliabile monitorare sia la distribuzione sia lo stato del cloud privato. Per altre informazioni sul monitoraggio della soluzione Azure VMware, vedere Gestione e monitoraggio per la soluzione Azure VMware.

Raccomandazioni:

• Usare l'interfaccia della riga di comando di Azure, PowerShell o un modello dichiarativo come Azure Resource Manager o Bicep per distribuire soluzione Azure VMware in modo automatizzato.
• Laddove possibile, usare what-if per verificare le modifiche prima dell'esecuzione, sospendendo l'eliminazione delle risorse per la verifica.

Approccio DevOps

È consigliabile implementare l'automazione di una distribuzione della soluzione Azure VMware come una serie di passaggi ripetibili, preferibilmente tramite un flusso di lavoro o una pipeline. È importante individuare con precisione i passaggi necessari che si prevede di includere nella distribuzione. I passaggi da eseguire possono includere:

• Distribuzione del cloud privato.
• Connettività del gateway ExpressRoute.
• Connettività Copertura globale.
• Creazione semplificata di DHCP, DNS e segmento del data center NSX-T.

Dopo aver distribuito il cloud privato, è possibile procedere alla distribuzione delle risorse all'interno del cloud. Per altre informazioni, vedere Automazione della piattaforma VMware SDDC.

Considerazioni:

• È possibile che sia già in atto una determinata strategia di automazione oppure si può creare una strategia DevOps come parte della zona di destinazione a livello aziendale. In tal caso, è consigliabile riutilizzare gli stessi criteri per le distribuzioni della soluzione Azure VMware per mantenere uno stile di automazione coerente su tutta la linea.
• Per altre informazioni, vedere la documentazione su DevOps e sull'automazione della piattaforma per le zone di destinazione a livello aziendale.

Automazione della piattaforma VMware

All'interno di un cloud privato soluzione Azure VMware, è anche possibile scegliere di automatizzare la creazione di risorse all'interno del server vCenter e di NSX-T Manager. Vengono elencate le seguenti serie di considerazioni che consentono di progettare l'automazione a livello di SDDC di VMware.

Automazione del server vCenter - PowerCLI

Considerazioni:

• Usare PowerCLI per creare e configurare macchine virtuali (VM), pool di risorse e modelli di VM, offrendo il controllo completo a livello di codice sul server vCenter.
• Poiché il server vCenter è disponibile solo tramite connettività privata o IP privato, è necessario eseguire PowerCLI in un computer con una linea di vista per le reti di gestione soluzione Azure VMware. Valutare la possibilità di usare un agente self-hosted per l'esecuzione della pipeline. Con questo agente, è possibile eseguire PowerCLI in una macchina virtuale all'interno di una rete virtuale o di un segmento di data center NSX-T.
• Si potrebbe non disporre dell'accesso per eseguire determinate operazioni, poiché si è limitati dal ruolo CloudAdmin. Valutare la possibilità di pianificare le autorizzazioni necessarie per l'automazione che si prevede di implementare e convalidare rispetto alle autorizzazioni CloudAdmin.
• Per l'accesso con privilegi minimi, è consigliabile usare un account del servizio per l'automazione a livello di server vCenter tramite l'integrazione di Active Directory.

Automazione del data center NSX-T - PowerCLI

Considerazioni:

• In un cloud privato soluzione Azure VMware l'utente amministratore ha accesso amministrativo al data center NSX-T per impostazione predefinita. A causa di questo accesso predefinito, considerare direttamente l'impatto delle modifiche apportate tramite PowerCLI o le API del data center NSX-T. Non è consentito apportare modifiche ai componenti gestiti da Microsoft, ad esempio la zona di trasporto e il gateway di livello zero. È quindi consigliabile prestare attenzione.
• La connettività privata è necessaria dalla macchina virtuale che esegue PowerCLI al cloud privato soluzione Azure VMware per interagire con il data center NSX-T.
• È possibile controllare la rete del carico di lavoro tramite Azure Resource Manager. Questo controllo consente di eseguire un subset di operazioni tramite l'API di Azure Resource Manager, che abilita quindi le operazioni tramite l'interfaccia della riga di comando di Azure e PowerShell usando il controllo degli accessi in base al ruolo di Azure anziché l'identità del data center NSX-T.

Provider di Data Center Terraform vSphere e NSX-T

Considerazioni:

• È possibile usare i provider di data center vSphere e NSX-T per Terraform per distribuire le risorse. Le risorse vengono distribuite nell'ambito del cloud privato in modo dichiarativo.
• Poiché Terraform deve comunicare con gli endpoint API all'interno del server vCenter e NSX-T Manager, deve avere connettività privata alla rete di gestione del cloud privato. È consigliabile eseguire la distribuzione da una macchina virtuale di Azure in grado di eseguire il routing al cloud privato.

vRealize Automation e vRealize Operations

Considerazioni:

• È possibile usare vRealize Automation in modo analogo a un ambiente locale per automatizzare il provisioning delle macchine virtuali all'interno della soluzione Azure VMware.
• Esistono limitazioni ai modelli di distribuzione supportati nella soluzione Azure VMware. Valutare l'opportunità di usare vRealize Cloud Management oppure di ospitare le appliance vRealize Automation in locale.
• Come con PowerCLI, è necessario disporre di connettività privata alla soluzione Azure VMware dall'ambiente in cui si trovano le appliance vRealize Automation e vRealize Operations.

Automazione a livello di carico di lavoro

All'interno dei singoli carichi di lavoro della soluzione Azure VMware, è possibile scegliere di configurare l'automazione a livello di macchina virtuale. L'automazione viene implementata come per un sistema locale e non è compresa nell'ambito di questo articolo. Esempi di questa automazione includono Microsoft Configuration Manager, Chef, Puppet e Ansible. È anche possibile usare Automazione di Azure per la configurazione a livello di macchina virtuale tramite l'agente locale.

Passaggi successivi

Dopo aver letto le informazioni sulle aree di progettazione, esaminare l'approccio e l'implementazione dell'architettura per la soluzione Azure VMware in uno scenario a livello aziendale.

soluzione Azure VMware acceleratore di zona di destinazione