Eseguire una macchina virtuale Windows in Azure

Per effettuare il provisioning di una macchina virtuale (VM) in Azure, sono necessari più componenti rispetto alla macchina virtuale stessa. Una distribuzione completa include risorse di rete e archiviazione. Questo articolo descrive le procedure consigliate per l'esecuzione di una macchina virtuale sicura Windows in Azure.

Architettura

Scaricare un file Visio di questa architettura.

Flusso di lavoro

Questo esempio mostra una distribuzione di base che usa i componenti necessari per una singola macchina virtuale. La macchina virtuale può eseguire carichi di lavoro e raggiungere la rete Internet pubblica evitando l'esposizione diretta alle minacce esterne. In questa architettura:

• I carichi di lavoro nella macchina virtuale non hanno esposizione diretta a Internet. L'accesso è limitato alle risorse all'interno della stessa rete virtuale o a una rete virtuale con peering, ad esempio in una configurazione hub-spoke.

• La macchina virtuale viene gestita usando Azure Bastion tramite Desktop remoto Protocol (RDP). Non esiste accesso diretto dalla rete Internet pubblica alla macchina virtuale per la gestione.

• Il gateway NAT (Network Address Translation) e l'indirizzo IP pubblico associato forniscono l'accesso a Internet esterno in uscita.

Components

Questa architettura usa i componenti seguenti.

Gruppo di risorse

Un gruppo risorso è un contenitore logico che contiene risorse Azure correlate. Usando i gruppi di risorse, è possibile distribuire, monitorare ed eliminare le risorse correlate insieme e tenere traccia dei relativi costi come unità.

In generale, raggruppare le risorse in base al ciclo di vita condiviso e alla proprietà. Usare nomi descrittivi coerenti per le risorse per semplificarne l'identificazione e la comprensione. Per altre informazioni, vedere Definire la convenzione di denominazione.

Macchina virtuale

È possibile effettuare il provisioning di una macchina virtuale da un elenco di immagini pubblicate, un'immagine gestita personalizzata o un disco rigido virtuale (VHD) caricato in Archiviazione BLOB di Azure.

Azure offre molte dimensioni di macchina virtuale diverse. Se si sposta un carico di lavoro esistente in Azure, iniziare con le dimensioni della macchina virtuale più strettamente corrispondenti ai server locali. Dopo aver distribuito la macchina virtuale, misurare le prestazioni del carico di lavoro effettivo in termini di operazioni di CPU, memoria e output del disco al secondo (IOPS) e regolare le dimensioni in base alle esigenze.

Scegliere un'area Azure più vicina agli utenti o ai clienti interni. Non tutte le dimensioni di macchina virtuale sono disponibili in tutte le aree. Per maggiori informazioni, vedere Azure geographies. Per un elenco delle dimensioni delle macchine virtuali disponibili in un'area specifica, eseguire il comando seguente dal interfaccia della riga di comando di Azure:

az vm list-sizes --location <location>

Per informazioni sulla scelta di un'immagine di macchina virtuale pubblicata, vedere Trovare e usare Azure Marketplace immagini di macchine virtuali.

Dischi

Per ottenere prestazioni ottimali per l'output di input del disco (I/O), è consigliabile usare unità SSD Premium che archiviano i dati su unità SSD (Solid State Drive). La capacità del disco di cui è stato effettuato il provisioning determina i costi, le operazioni di I/O al secondo e la velocità effettiva (velocità di trasferimento dei dati). Quando si seleziona una dimensione del disco, prendere in considerazione tutti e tre i fattori. Le unità SSD Premium includono il bursting gratuito, che consente di soddisfare il picco della domanda senza effettuare il provisioning eccessivo e riduce il costo della capacità inutilizzata in combinazione con la comprensione dei modelli di carico di lavoro.

Managed disks semplifica la gestione del disco gestendo lo spazio di archiviazione per te. Managed disks non richiedono un account di archiviazione. Specificare le dimensioni e il tipo del disco e Azure distribuirlo come risorsa a disponibilità elevata. I dischi gestiti riducono anche i costi offrendo le prestazioni necessarie senza il provisioning eccessivo, evitando così di pagare la capacità di provisioning inutilizzata.

Per impostazione predefinita, il disco del sistema operativo è un disco gestito archiviato in archiviazione su disco di Azure, quindi persiste anche quando il computer host è inattivo. Per i carichi di lavoro senza stato, quando si desiderano provisioning rapido e assenza di persistenza del sistema operativo, utilizzare i dischi effimeri del sistema operativo. Questi dischi collocano l'immagine del sistema operativo nell'archiviazione locale dell'host della VM anziché nell'archiviazione remota di Azure, riducendo la latenza di lettura, accelerando la ricreazione dell'immagine ed eliminando i costi dei dischi gestiti. Tuttavia, tutti i dati in un disco temporaneo del sistema operativo vengono persi in caso di arresto (deallocazione), ricreazione dell'immagine o eventi di correzione della manutenzione host. I dischi temporanei del sistema operativo non supportano snapshot o Backup di Azure. Usare dischi effimeri del sistema operativo solo quando le macchine virtuali sono completamente ridistribuibili tramite automazione.

A seconda dello SKU scelto, la macchina virtuale potrebbe usare un disco temporaneo archiviato in un'unità fisica nel computer host (l'unità D: in Windows). Il disco temporaneo non è persistente in Archiviazione e può essere eliminato durante i riavvii e altri eventi del ciclo di vita della macchina virtuale. Usare il disco temporaneo solo per i dati temporanei che non devono sopravvivere a un riavvio, ad esempio file temporanei specifici dell'applicazione o spazio di scambio.

Windows richiede un file di pagina per la gestione della memoria virtuale. Nelle dimensioni di VM basate su SCSI (Small Computer System Interface) (v5 e precedenti), le immagini del Marketplace collocano il file di paging nel disco temporaneo per impostazione predefinita. Nelle dimensioni di vm basate su NVMe (Non Volatile Memory Express) (v6 e versioni successive), il file di pagina viene impostato come predefinito sul disco del sistema operativo perché i dischi temporanei NVMe richiedono l'inizializzazione dopo ogni avvio. Per le macchine virtuali con disco del sistema operativo effimero, anche il file di pagina si trova sul disco del sistema operativo.

Quando possibile, installare applicazioni su un disco dati, anziché sul disco del sistema operativo. Alcune applicazioni legacy potrebbero dover installare componenti nell'unità C: , nel qual caso è possibile ridimensionare il disco del sistema operativo usando PowerShell.

È consigliabile creare uno o più dischi dati per i dati dell'applicazione. I dischi dati sono dischi gestiti persistenti basati su Storage.

Quando si aggiunge un nuovo disco a una macchina virtuale, non è formattato. Accedere alla macchina virtuale per formattare il disco. È anche possibile usare PowerShell per aggiungere un nuovo disco dati.

Rete

I componenti di rete includono le risorse seguenti:

• Rete virtuale: Ogni macchina virtuale viene distribuita in una rete virtuale che è possibile segmentare in più subnet.

• Scheda di interfaccia di rete (NIC): La scheda di interfaccia di rete connette la macchina virtuale alla rete virtuale e gestisce tutto il traffico in ingresso e in uscita. Se sono necessarie più schede di interfaccia di rete per la macchina virtuale, ogni dimensione della macchina virtuale definisce un numero massimo di schede di interfaccia di rete.

• Indirizzo IP pubblico: È possibile usare un indirizzo IP pubblico per comunicare con la macchina virtuale dall'esterno Azure tramite RDP. Tuttavia, questa opzione è sconsigliata perché è un potenziale rischio per la sicurezza.

  Avvertimento

  Evitare di collegare un indirizzo IP pubblico direttamente a una macchina virtuale. Eseguire questa operazione solo in circostanze estreme e includere altre misure di sicurezza, ad esempio l'uso di gruppi di sicurezza di rete (NSG) per filtrare il traffico. Per l'accesso di gestione a una macchina virtuale, usare Azure Bastion o connettersi privatamente tramite una VPN o Azure ExpressRoute.

  • L'indirizzo IP pubblico può essere dinamico o statico. Per impostazione predefinita, è dinamico. Riservare un indirizzo IP statico quando è necessario un indirizzo IP fisso che non cambia, ad esempio se è necessario creare un record DNS "A" o aggiungere l'indirizzo IP a un elenco sicuro.

  • È inoltre possibile creare un nome di dominio completo (FQDN) per l'indirizzo IP. È quindi possibile registrare il record CNAME nel DNS che punta al FQDN. Per altre informazioni, vedere Creare un nome di dominio completo nel portale di Azure.

• NSG: Usare NSG per consentire o negare il traffico di rete da e verso le macchine virtuali e le subnet. Associarli alle subnet o alle singole schede di interfaccia di rete collegate alle macchine virtuali.

  Tutti i gruppi di sicurezza di rete contengono un set di regole di sicurezza predefinite, inclusa una regola che blocca tutto il traffico Internet in ingresso. Non è possibile eliminare le regole predefinite, ma è possibile eseguirne l'override con altre regole. Ad esempio, è possibile creare regole che consentono il traffico Internet in ingresso verso porte specifiche, ad esempio la porta 443 per HTTPS.

• Azure gateway NAT (Network Address Translation):Gateway NAT di Azure consente a tutte le istanze di una subnet privata di connettersi in uscita a Internet pur rimanendo completamente private. Solo i pacchetti che arrivano come pacchetti di risposta a una connessione in uscita possono passare attraverso un gateway NAT. Le connessioni in ingresso non richieste da Internet non sono consentite.

• Azure Bastion:Azure Bastion è una soluzione PaaS (Platform as a Service) completamente gestita che fornisce accesso sicuro alle macchine virtuali tramite indirizzi IP privati. Con questa configurazione, le macchine virtuali non necessitano di un indirizzo IP pubblico che li espone a Internet, aumentando così il comportamento di sicurezza. Azure Bastion fornisce connettività RDP o SSH sicura alle macchine virtuali usando vari metodi, tra cui il portale di Azure o i client SSH o RDP nativi.

Operazioni

Questa sezione illustra le procedure operative principali per la gestione di una macchina virtuale Windows in Azure.

• Diagnostica: Abilitare il monitoraggio e la diagnostica, incluse le metriche di base sull'integrità, i log dell'infrastruttura di diagnostica e la diagnostica di avvio. La diagnostica di avvio consente di diagnosticare l'errore di avvio se la macchina virtuale entra in uno stato non avviabile. Archiviare i log di diagnostica in un account di archiviazione. Un account di archiviazione con ridondanza locale standard (LRS) è sufficiente per log di diagnostica. Per altre informazioni, vedere Procedure consigliate per il monitoraggio e la diagnostica.

• Disponibilità: lamanutenzione pianificata o il tempo di inattività non pianificato potrebbe influire sulla macchina virtuale. È possibile usare i log di riavvio della macchina virtuale per determinare se la manutenzione pianificata ha causato un riavvio della macchina virtuale. Per una disponibilità più elevata, distribuire più macchine virtuali tra zone di disponibilità all'interno di un'area. Questa distribuzione offre un contratto di servizio (SLA) superiore. Se le zone di disponibilità non sono supportate, i set di disponibilità possono fornire protezione dagli errori dell'host o dagli aggiornamenti dell'host. Tuttavia, le zone di disponibilità sono l'opzione consigliata laddove possibile.

• Backup: Per proteggersi da perdite accidentali di dati, usare il servizio Backup di Azure per eseguire il backup delle macchine virtuali nell'archiviazione. A seconda dell'area, è possibile usare l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza della zona per i backup. Backup di Azure fornisce backup coerenti con l'applicazione. Per i carichi di lavoro sensibili alle prestazioni, usa la funzionalità di backup coerente in caso di arresto anomalo senza agente per più dischi anziché il servizio Copia Shadow del volume (VSS) per automatizzare la protezione dei backup senza influire sulle prestazioni dell'applicazione.

• Arresto di una macchina virtuale: Azure distingue gli stati arrestati e deallocati. L'addebito viene addebitato quando lo stato della macchina virtuale viene arrestato, ma non quando la macchina virtuale viene deallocata. Nel portale di Azure, il pulsante Stop dealloca la macchina virtuale. Se si arresta la VM dal sistema operativo mentre si è connessi, la macchina virtuale viene arrestata ma non deallocata, quindi si continua a pagare.

• Eliminazione di una macchina virtuale: Se si elimina una macchina virtuale, è possibile scegliere di eliminare o conservarne i dischi, che consente di conservare i dati. Tuttavia, si paga ancora per i dischi. È possibile eliminare i dischi gestiti esattamente come qualsiasi altra risorsa Azure. Per impedire l'eliminazione accidentale, usare un blocco di risorsa per bloccare l'intero gruppo di risorse o le singole risorse, ad esempio una macchina virtuale.

Alternative

• Set di scalabilità di macchine virtuali di Azure consente di creare e gestire un gruppo di istanze di macchine virtuali con carico bilanciato. I carichi di lavoro fondamentali per le operazioni aziendali non devono mai dipendere da una singola macchina virtuale. I set di scalabilità di macchine virtuali consentono di distribuire i carichi di lavoro tra i nodi. Le istanze VM possono essere aggiunte o rimosse automaticamente in base alla domanda e possono aumentare il numero di istanze nei periodi di traffico più elevato o ridurlo quando il traffico diminuisce, per contribuire a ridurre al minimo i costi.

• Azure Load Balancer distribuisce il traffico tra più macchine virtuali o un set di scalabilità di macchine virtuali. Può anche essere usato come alternativa a un gateway NAT per consentire l'accesso a un carico di lavoro da Internet, supportando anche l'accesso in uscita.

• Application Gateway è un'opzione alternativa di bilanciamento del carico di livello 7 per il traffico HTTP/HTTPS che in genere viene distribuita davanti a più macchine virtuali o a un set di scalabilità di macchine virtuali in un'area di Azure.

• Per una distribuzione di livello aziendale, vedi Architettura di riferimento di Macchine virtuali di Azure in una landing zone di Azure.

Dettagli dello scenario

Il diagramma precedente illustra una distribuzione di base di una singola macchina virtuale in una rete virtuale. Questo scenario è utile per fornire un carico di lavoro non critico per gli utenti solo interni.

Casi d'uso potenziali

Questa architettura è adatta a una semplice applicazione che non richiede l'esposizione a Internet pubblica e può tollerare tempi di inattività occasionali. Uno strumento di report interno di base è un caso d'uso tipico.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Questa architettura di esempio usa una singola macchina virtuale, quindi offre un livello minimo di affidabilità. Qualsiasi problema con la macchina virtuale o con l'host in cui viene eseguito causa un'interruzione e rende i carichi di lavoro ospitati non disponibili. Per qualsiasi carico di lavoro che richiede una disponibilità più elevata, distribuire più macchine virtuali che contengono lo stesso carico di lavoro e posizionare tali istanze dietro una soluzione di bilanciamento del carico appropriata. Se si trovano nella stessa area geografica, distribuire queste macchine virtuali nelle varie zone di disponibilità, se supportate, e aggiungerle al pool back-end di Azure Load Balancer Standard o di Application Gateway, se il carico di lavoro è basato su HTTP/HTTPS. Questa architettura consente al carico di lavoro di rimanere disponibile se una singola macchina virtuale nel back-end diventa inattiva.

I set di scalabilità di macchine virtuali sono un'altra opzione per semplificare la gestione di carichi di lavoro a più nodi che richiedono la possibilità di ridimensionare automaticamente il numero di istanze in o in uscita a seconda di una delle diverse metriche, ad esempio l'utilizzo della CPU e della memoria.

Disponibilità elevata e ripristino di emergenza

Per ridurre il raggio di esplosione e migliorare la resilienza, distribuire il carico di lavoro in più aree e usare le linee guida Azure zona di destinazione. Questa distribuzione può essere in una configurazione active-passive, con failover verso la regione secondaria se la regione primaria non è più disponibile, oppure in un'architettura active-active in cui entrambe le regioni gestiscono il traffico degli utenti.

Per un esempio, consulta Applicazione web multilivello progettata per alta disponibilità e ripristino di emergenza. L'esempio in questo articolo usa Azure Site Recovery per replicare i dischi di singole macchine virtuali in un'area secondaria. È possibile usare Site Recovery per eseguire il failover di tali macchine virtuali nell'area geografica secondaria utilizzando un obiettivo del punto di ripristino (RPO) ridotto e un obiettivo del tempo di ripristino (RTO) ridotto.

Valuta la tua architettura per soddisfare i requisiti HA/DR previsti per tutti i componenti, non solo per le VM. In tutte queste decisioni, includere considerazioni quali rete, identità e dati.

Sicurezza

La sicurezza fornisce protezioni contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

Considerare questi punti quando si sviluppa l'architettura:

• Usare Microsoft Defender per il cloud per ottenere una visualizzazione centrale dello stato di sicurezza delle risorse Azure. Defender per il cloud monitora i potenziali problemi di sicurezza e fornisce un quadro completo dell'integrità della sicurezza della distribuzione. Configurare Defender per il cloud per sottoscrizione Azure e abilitare la raccolta dei dati di sicurezza. Defender per il cloud analizza automaticamente le macchine virtuali create in tale sottoscrizione.

  • Gestione delle patch: Se abilitata, Defender per il cloud identifica gli aggiornamenti critici e della sicurezza mancanti. Utilizza le impostazioni dei Criteri di Gruppo nella macchina virtuale per abilitare gli aggiornamenti automatici del sistema.

  • Antimalware: Se abilitata, Defender per il cloud controlla se è installato software antimalware. È anche possibile usare Defender per il cloud per installare software antimalware direttamente dal portale di Azure.

• Usare Azure controllo degli accessi basato sui ruoli (Azure RBAC) per controllare l'accesso alle risorse Azure. Con Azure RBAC, è possibile concedere agli utenti solo le autorizzazioni necessarie per svolgere il loro lavoro. Ad esempio, il ruolo Lettore può visualizzare Azure risorse, ma non può crearle, gestirle o eliminarle. Alcune autorizzazioni sono specifiche di un tipo di risorsa Azure. Ad esempio, il ruolo Collaboratore macchina virtuale può riavviare o deallocare una macchina virtuale, reimpostare la password dell'amministratore e creare una nuova macchina virtuale. Altri ruoli predefiniti che potrebbero essere utili per questa architettura includono l'utente di DevTest Labs e collaboratore alla rete.

• Usare audit logs per visualizzare le azioni di provisioning e altri eventi della macchina virtuale.

• Abilitare la crittografia nell'host per ottenere la crittografia end-to-end per i dati della macchina virtuale, inclusi i dischi temporanei e le cache dei dischi. La crittografia nell'host gestisce la crittografia nell'infrastruttura host della macchina virtuale e non usa le risorse della CPU della macchina virtuale, a differenza della crittografia basata su guest. È possibile usare chiavi gestite da customer con Azure Key Vault per i dischi dati e del sistema operativo persistenti. I dischi temporanei e i dischi temporanei del sistema operativo vengono crittografati con chiavi gestite dalla piattaforma. Verificare che le dimensioni VM selezionate supportino la crittografia in host prima di effettuare il provisioning della macchina virtuale.

Ottimizzazione costi

Ottimizzazione costi è incentrata sulla ricerca di modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Sono disponibili diverse opzioni per le dimensioni delle macchine virtuali a seconda dell'utilizzo e del carico di lavoro. L'intervallo include l'opzione più economica della serie Bs alle macchine virtuali GPU più recenti ottimizzate per machine learning. Per informazioni sulle opzioni disponibili, vedere Azure Windows prezzi delle macchine virtuali.

Per carichi di lavoro prevedibili, usa Azure Reservations e Azure savings plan for compute. Un contratto di un anno o tre anni può ridurre notevolmente i costi di calcolo rispetto alle tariffe con pagamento in base al consumo. Per i carichi di lavoro senza tempi prevedibili di completamento o consumo di risorse, prendere in considerazione l'opzione Pagamento in base al consumo .

Macchine virtuali Spot di Azure sfruttano la capacità Azure inutilizzata a tariffe notevolmente ridotte. Azure può sfrattare le VM Spot con breve preavviso quando ha nuovamente bisogno della capacità, quindi sono adatte solo per carichi di lavoro tolleranti agli errori senza tempi di completamento rigorosi. Prendere in considerazione le macchine virtuali spot per:

• Scenari di calcolo ad alte prestazioni (HPC), lavori di elaborazione batch o applicazioni di rendering visivo.
• Ambienti di test, tra cui l'integrazione continua e i carichi di lavoro di recapito continuo.
• Applicazioni senza stato su larga scala.

Usare il calcolatore dei prezzi di Azure per stimare i costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per ulteriori informazioni, vedere Lista di controllo per la revisione del design per l'Eccellenza Operativa.

Usare i modelli IaC (Infrastructure as Code) per effettuare il provisioning delle risorse Azure e delle relative dipendenze. È possibile scrivere questi modelli usando Bicep, Azure Resource Manager o Terraform. Questi modelli possono essere usati come parte di una pipeline di integrazione continua e distribuzione continua (CI/CD) tramite la distribuzione automatica. Questo approccio fornisce il controllo della versione sull'architettura, garantisce la coerenza tra gli ambienti e applica riproducibilità, sicurezza e conformità.

Per monitorare e diagnosticare i problemi, abilitare i log di diagnostica sulle risorse e inviarli a Monitoraggio di Azure per l'analisi e l'ottimizzazione. È possibile usare questi log per implementare avvisi e notifiche di eventi critici. In alcuni casi, possono consentire la correzione automatica o la registrazione dei ticket nel sistema di gestione dei servizi IT .

Efficienza prestazionale

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

L'efficienza delle prestazioni consente di ridurre al minimo la latenza, ottenere architetture scalabili, ottimizzare l'utilizzo delle risorse e migliorare continuamente le prestazioni del sistema. Le decisioni prese in merito all'architettura del carico di lavoro, alle dimensioni delle macchine virtuali e alle configurazioni del disco possono influire notevolmente sulle prestazioni del carico di lavoro. Fare le scelte giuste può impedire la necessità di riprogettare la soluzione in futuro, aggiungere flessibilità e risparmiare sui costi.

Considerare questi punti quando si sviluppa l'architettura:

• Usa i set di scalabilità di macchine virtuali se il carico di lavoro è soggetto a un carico dinamico. Ad esempio, aumentare il numero di istanze durante i periodi di traffico elevato per poi ridurlo quando il traffico diminuisce. Questo approccio garantisce una potenza di elaborazione adeguata mantenendo comunque sotto controllo i costi.

• Scegliere le VM e gli SKU del disco appropriati per soddisfare le operazioni di I/O al secondo necessarie durante l'elaborazione. Configurare la memorizzazione nella cache per migliorare ulteriormente le prestazioni.

• Se il carico di lavoro è insolitamente sensibile alla latenza, usare gruppi di posizionamento di prossimità per assicurarsi che più macchine virtuali si trovino fisicamente vicine tra loro per ottenere prestazioni migliori. È anche possibile combinare i PPG con i set di disponibilità per ottenere bassa latenza e disponibilità elevata all'interno dello stesso data center fisico.

• Se possibile, abilitare la rete accelerata per ridurre al minimo la latenza tra i componenti.

• Progettare un'architettura di rete per ridurre al minimo gli hop non necessari.

• Usare Monitoraggio di Azure e altri strumenti per analizzare continuamente le metriche e creare baseline di prestazioni aggiornate. Usare le informazioni sulle prestazioni per determinare dove implementare le modifiche e quindi eseguire il test su tali baseline.

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti hanno originariamente scritto l'articolo.

Autore principale:

• Donnie Trumpower | Senior Cloud & AI Solutions Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Guida introduttiva: Creare una macchina virtuale Windows nel portale di Azure
• Installare i driver GPU NVIDIA in macchine virtuali serie N che eseguono Windows
• Installare i driver GPU AMD sulle macchine virtuali serie N eseguite in Windows
• Creare e gestire macchine virtuali Windows con Azure PowerShell
• Accesso in uscita predefinito in Azure

Risorse correlate

• Eseguire una macchina virtuale Linux su Azure
• Piano di distribuzione per l'aggiornamento delle macchine virtuali Windows in Azure
• Architettura di base delle macchine virtuali in una landing zone di Azure
• Applicazione web multilivello progettata per alta disponibilità e ripristino di emergenza