Compilare un elenco di controllo per creare una macchina virtuale di Azure
La migrazione di server locali ad Azure richiede pianificazione e attenzione. Si possono spostare tutti contemporaneamente oppure, con maggiore probabilità, in piccoli batch o anche singolarmente. Prima di creare una singola macchina virtuale, è consigliabile esaminare il modello di infrastruttura attuale e definirne il mapping nel cloud.
Informazioni sulle risorse di Azure
Una risorsa di Azure è un elemento gestibile in Azure. Proprio come un computer fisico nel data center, le macchine virtuali hanno diversi elementi necessari a svolgere le loro funzioni:
- VM
- Dischi per l'archiviazione
- Rete virtuale
- Interfaccia di rete per la comunicazione sulla rete
- Gruppo di sicurezza di rete (NSG) per proteggere il traffico di rete
- Indirizzo IP (pubblico, privato o entrambi)
Azure creerà tutte queste risorse in base alle esigenze. In alternativa, è possibile specificare risorse esistenti come parte del processo di distribuzione. Ogni risorsa deve avere un nome che verrà usato per identificarla. Se Azure crea la risorsa, userà il nome della macchina virtuale per generare un nome di risorsa. Questo è un altro motivo per cui è opportuno mantenere la massima coerenza nei nomi delle macchine virtuali.
Risorse necessarie per le macchine virtuali IaaS
Di seguito verrà presentato un elenco di controllo degli aspetti da considerare.
- Rete
- Nome della VM.
- Titolo
- Dimensioni delle macchine virtuali
- Disks
- Sistema operativo
Rete
Il primo elemento da considerare non è la macchina virtuale, ma la rete. Esaminare uno dei server locali:
- Con quali risorse comunica il server?
- Quali porte sono aperte?
Le reti virtuali vengono usate in Azure per offrire connettività privata tra Macchine virtuali di Azure e altri servizi di Azure. Le VM e i servizi che fanno parte della stessa rete virtuale possono accedere l'uno all'altro. Per impostazione predefinita, i servizi all'esterno della rete virtuale non possono connettersi ai servizi all'interno. È tuttavia possibile configurare la rete in modo da consentire l'accesso al servizio esterno, includendo i server locali.
Questo ultimo punto è il motivo per cui è consigliabile dedicare tempo a valutare la propria configurazione di rete. Non è semplice modificare gli indirizzi di rete e le subnet dopo averli configurati. Se si prevede di connettere la rete aziendale privata ai servizi di Azure, sarà opportuno considerare la topologia prima di implementare qualsiasi macchina virtuale.
Quando si configura una rete virtuale, si specificano gli spazi indirizzi disponibili, le subnet e la sicurezza. Se la rete virtuale è connessa ad altre reti virtuali, è necessario selezionare intervalli di indirizzi che non si sovrappongano. Si tratta dell'intervallo di indirizzi privati che può essere usato dalle VM e dai servizi nella rete. È possibile usare indirizzi IP non instradabili come 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16 oppure definire un proprio intervallo. Azure considera qualunque intervallo di indirizzi come parte dello spazio indirizzi IP privato della rete virtuale se è raggiungibile solo all'interno della rete virtuale, delle reti virtuali interconnesse e dall'ambiente locale. Se qualcun altro è responsabile delle reti interne, è necessario collaborare con il collega prima di selezionare lo spazio indirizzi per assicurarsi che non siano presenti sovrapposizioni. Comunicare al responsabile quale spazio si intende usare affinché altri non usino lo stesso intervallo di indirizzi IP.
Separare la rete
Dopo aver scelto gli spazi indirizzi della rete virtuale, è possibile creare una o più subnet per la rete virtuale. Si creano le subnet per suddividere la rete in sezioni più gestibili. Ad esempio, è possibile assegnare 10.1.0.0 alle VM, 10.2.0.0 ai servizi back-end e 10.3.0.0 alle VM di SQL Server.
Nota
Azure riserva i primi quattro indirizzi e l'ultimo di ogni subnet per uso interno.
Proteggere la rete
Per impostazione predefinita non esistono limiti di sicurezza tra le subnet e i servizi in ognuna di esse possono quindi comunicare tra loro. È tuttavia possibile configurare gruppi di sicurezza di rete (NSG, Network Security Group) che consentono di controllare il flusso di traffico da e verso le subnet e da e verso le VM. Gli NSG fungono da firewall software, applicando regole personalizzate a ogni richiesta in ingresso o in uscita a livello di interfaccia di rete e di subnet. In questo modo è possibile ottenere il controllo completo su ogni richiesta di rete in ingresso e in uscita nella macchina virtuale.
Pianificare ogni distribuzione di VM
Al termine del mapping dei requisiti di comunicazione e di rete, si può iniziare a considerare le VM da creare. Un buon piano consiste nel selezionare un server e completare un inventario:
- Quale sistema operativo viene usato?
- Quanto spazio su disco viene usato?
- Che tipo di dati viene usato? Sono previste restrizioni (legali o di altro tipo) relative alla modalità di archiviazione o alla posizione fisica?
- In che ordine sono organizzati i carichi di I/O per CPU, memoria e disco nel server? È necessario tenere conto di picchi di traffico?
Rispondendo a queste domande si potranno fornire alcune delle informazioni che verranno richieste da Azure per una nuova macchina virtuale.
Nome della VM.
Il nome della VM viene usato come nome computer, configurato nell'ambito del sistema operativo. È possibile specificare un nome composto da un massimo di 64 caratteri per una macchina virtuale Linux e 15 caratteri per una macchina virtuale Windows.
Questo nome definisce anche una risorsa di Azure gestibile e non è semplice modificarlo in un secondo momento. È quindi consigliabile scegliere nomi significativi e coerenti per poter identificare facilmente la funzione svolta dalla VM. È buona pratica includere le informazioni seguenti nel nome:
Elemento | Esempio | Note |
---|---|---|
Ambiente | dev, prod, QA | Identifica l'ambiente per la risorsa |
Titolo | eus per l'area Stati Uniti orientali, jw per l'area Giappone occidentale |
Identifica l'area in cui la risorsa viene distribuita |
Istanza | 01, 02 | Per le risorse con più istanze denominate (server Web e così via) |
Prodotto o servizio | service | Identifica il prodotto, l'applicazione o il servizio supportato dalla risorsa |
Ruolo | SQL, Web, messaggistica | Identifica il ruolo della risorsa associata |
Ad esempio, deveus-webvm01
può rappresentare il primo server Web di sviluppo ospitato nella località Stati Uniti orientali.
Scegliere la posizione della macchina virtuale
Azure ha data center con server e dischi in tutto il mondo. Questi data center sono raggruppati in aree geografiche, come "Stati Uniti occidentali", "Europa settentrionale", "Asia sud-orientale" e così via, per garantire ridondanza e disponibilità.
Quando si crea e si distribuisce una macchina virtuale, è necessario selezionare un'area in cui si vogliono allocare le risorse. È possibile posizionare le macchine virtuali il più vicino possibile agli utenti al fine di migliorare le prestazioni e soddisfare i requisiti legali, di conformità o fiscali.
Esistono altri due aspetti da considerare per la scelta della località. Prima di tutto la località può limitare le opzioni disponibili. Per ogni area è disponibile hardware diverso e alcune configurazioni non sono disponibili in tutte le aree. In secondo luogo, esistono differenze di prezzo a seconda della località. Se il carico di lavoro non è associato a una località specifica, può essere molto conveniente controllare in più aree il prezzo della configurazione necessaria per trovare quello più basso.
Determinare la dimensione della VM
Dopo avere impostato il nome e la località, è necessario scegliere la dimensione della macchina virtuale. Invece di specificare potenza di elaborazione, memoria e capacità di archiviazione in modo indipendente, Azure offre macchine Virtuali di dimensioni diverse che implicano variazioni di questi elementi per le diverse dimensioni. Azure offre una vasta gamma di opzioni in termini di dimensioni di VM e consente di selezionare la combinazione di calcolo, memoria e spazio di archiviazione appropriata in base alle specifiche esigenze.
Il modo migliore per determinare le dimensioni appropriate della macchina virtuale consiste nel considerare il tipo di carico di lavoro che la macchina virtuale deve eseguire. In base al carico di lavoro, si può scegliere tra un subset delle dimensioni di VM disponibili. In Azure, le opzioni di carico di lavoro sono classificate come segue:
Opzione | Descrizione |
---|---|
Utilizzo generico | Le VM per utilizzo generico sono progettate per offrire un rapporto CPU-memoria equilibrato. Questa opzione è ideale per test e sviluppo, database medio-piccoli e server Web con traffico da medio a ridotto. |
Con ottimizzazione per il calcolo | Le VM con ottimizzazione per il calcolo sono progettate per offrire un rapporto CPU-memoria elevato. Sono idonee per server Web con traffico medio, appliance di rete, processi batch e server applicazioni. |
Ottimizzato per la memoria | Le VM ottimizzate per la memoria sono progettate per offrire un rapporto memoria-CPU elevato. Questa opzione è ottimale per server di database relazionali, cache medio-grandi e analisi in memoria. |
Con ottimizzazione per l'archiviazione | Le VM con ottimizzazione per l'archiviazione sono progettate per offrire livelli elevati di I/O e velocità effettiva dei dischi. Sono ideali per le VM che eseguono database. |
GPU | Le VM con GPU sono macchine virtuali specializzate destinate a carichi intensivi di rendering della grafica e modifica di video. Queste VM sono opzioni ideali per l'inferenza e il training di modelli con l'apprendimento profondo. |
High Performance Computing (HPC) | Le VM con High Performance Computing sono le macchine virtuali con le CPU più veloci e potenti e con interfacce di rete facoltative a velocità effettiva elevata. |
È possibile filtrare il tipo di carico di lavoro quando si configura la dimensione della VM in Azure. Le dimensioni scelte influiscono direttamente sul costo del servizio. Maggiore è la capacità di memoria, CPU e GPU necessarie, maggiore sarà il prezzo.
Cosa fare se le esigenze in termini di dimensioni dovessero cambiare?
Azure consente di modificare le dimensioni della macchina virtuale quando quelle esistenti non rispondono più alle proprie esigenze. È possibile effettuare l'aggiornamento o il downgrade della macchina virtuale, purché la configurazione hardware corrente sia consentita nella nuova dimensione. La possibilità di modificare le dimensioni delle macchine virtuali offre un approccio completamente agile e scalabile alla gestione delle macchine virtuali.
È possibile modificare le dimensioni di una macchina virtuale mentre questa è in esecuzione purché le nuove dimensioni siano disponibili nel cluster hardware corrente in cui la macchina virtuale è in esecuzione. Nel portale di Azure le opzioni per le dimensioni sono ovvie, in quanto vengono mostrate solo le dimensioni disponibili. Gli strumenti da riga di comando segnaleranno un errore se si tenta di ridimensionare una macchina virtuale a dimensioni non disponibili. La modifica delle dimensioni di una macchina virtuale in esecuzione ne comporterà automaticamente il riavvio per completare la richiesta.
Se si arresta e si dealloca la macchina virtuale, è quindi possibile selezionare tutte le dimensioni disponibili nell'area perché la deallocazione rimuove la macchina virtuale dal cluster in cui era in esecuzione.
Avviso
Prestare attenzione quando si ridimensionano le macchine virtuali di produzione che verranno riavviate automaticamente e potrebbero quindi verificarsi un'interruzione temporanea e la modifica di alcune impostazioni di configurazione, ad esempio l'indirizzo IP.
Parti di una macchina virtuale e come vengono fatturate
Quando si crea una macchina virtuale, si creano anche risorse che supportano la macchina virtuale. Queste risorse sono dotate di costi propri che devono essere presi in considerazione.
Le risorse predefinite che supportano una macchina virtuale e il modo in cui vengono fatturate sono descritte in dettaglio nella tabella seguente:
Risorsa | Descrizione | Costii |
---|---|---|
Rete virtuale | Per offrire alla macchina virtuale la possibilità di comunicare con altre risorse | Prezzi della rete virtuale |
Scheda di interfaccia di rete virtuale (NIC) | Per la connessione alla rete virtuale | Non sono previsti costi separati per le schede di interfaccia di rete. Tuttavia, esiste un limite al numero di schede di interfaccia di rete che è possibile usare in base alle dimensioni della macchina virtuale. Ridimensionare la macchina virtuale di conseguenza e fare riferimento ai prezzi delle macchine virtuali. |
Un indirizzo IP privato e talvolta un indirizzo IP pubblico. | Per la comunicazione e lo scambio di dati nella rete e con reti esterne | Prezzi degli indirizzi IP |
Gruppo di sicurezza di rete | Per gestire anche il traffico di rete e dalla macchina virtuale. Ad esempio, potrebbe essere necessario aprire la porta 22 per l'accesso SSH, ma potrebbe essere necessario bloccare il traffico verso la porta 80. Il blocco e l'accesso alle porte viene eseguito tramite il gruppo di sicurezza di rete. | Non sono previsti costi aggiuntivi per i gruppi di sicurezza di rete in Azure. |
Disco del sistema operativo ed eventualmente dischi separati per i dati. | È consigliabile mantenere i dati in un disco separato dal sistema operativo, nel caso in cui una macchina virtuale abbia esito negativo, è sufficiente scollegare il disco dati e collegarli a una nuova macchina virtuale. | Tutte le nuove macchine virtuali hanno un disco del sistema operativo e un disco locale. Azure non viene addebitato per l'archiviazione su disco locale. Il disco del sistema operativo, che in genere è 127GiB, ma è più piccolo per alcune immagini, viene addebitato alla frequenza regolare per i dischi. È possibile visualizzare il costo per collegare dischi basati su SSD (Premium) e Standard (HDD) alle macchine virtuali nella pagina dei prezzi di Managed Disks. |
In alcuni casi, una licenza per il sistema operativo | Per fornire le esecuzioni della macchina virtuale per eseguire il sistema operativo | Il costo varia in base al numero di core nella macchina virtuale, in modo da ridimensionare di conseguenza la macchina virtuale. Il costo può essere ridotto tramite il Vantaggio Azure Hybrid. |
Informazioni sul modello di determinazione prezzi
Per ogni macchina virtuale, alla sottoscrizione verranno addebitati due costi separati: calcolo e archiviazione. Separando questi costi, è possibile gestire la scalabilità delle macchine virtuali in modo indipendente pagando solo le risorse necessarie.
Costi di calcolo: il prezzo viene determinato su base oraria, ma le spese di calcolo vengono fatturate al minuto. Ad esempio, se la macchina virtuale viene distribuita per 55 minuti, vengono addebitati solo 55 minuti di utilizzo. Non vengono addebitati costi per la capacità di calcolo in caso di arresto e deallocazione della macchina virtuale, in quanto la deallocazione rilascia l'hardware. La tariffa oraria varia in base alla dimensione della macchina virtuale e al sistema operativo selezionati. Le istanze basate su Linux sono più economiche perché non sono previsti costi di licenza per il sistema operativo. Per Windows, il costo di una macchina virtuale include le spese per il sistema operativo.
Suggerimento
È possibile risparmiare denaro riutilizzando licenze esistenti con il vantaggio Azure Hybrid per Linux o Windows.
Per i costi di calcolo è possibile scegliere tra due opzioni di pagamento.
Opzione | Descrizione |
---|---|
Pagamento in base al consumo | Con l'opzione di pagamento in base al consumo, si paga la capacità di calcolo al secondo, senza alcun impegno a lungo termine o pagamento anticipato. È possibile aumentare o diminuire la capacità di calcolo su richiesta e avviare o arrestare l'opzione in qualsiasi momento. Selezionare questa opzione se si eseguono applicazioni con carichi di lavoro a breve termine o imprevedibili che non possono essere interrotti. L'opzione con pagamento in base al consumo è appropriata, ad esempio, per eseguire un rapido test o sviluppare un'app in una macchina virtuale. |
Istanze di macchina virtuale riservate | L'opzione relativa alle istanze di macchina virtuale riservate consiste nell'acquisto anticipato di una macchina virtuale per uno o tre anni in un'area specificata. Si fissa un impegno anticipato e in cambio si ottiene un risparmio del 72% sul prezzo con pagamento in base al consumo. Le istanze riservate sono flessibili e possono essere facilmente scambiate o restituite pagando un corrispettivo per la risoluzione anticipata. Selezionare questa opzione se la macchina virtuale deve essere eseguita in modo continuo o si vuole un budget prevedibile e si è disposti a impegnarsi a usare la macchina virtuale per almeno un anno. |
Costi di archiviazione: il costo per lo spazio di archiviazione usato dalla macchina virtuale viene addebitato separatamente. Lo stato della macchina virtuale non ha alcuna relazione con i costi di archiviazione sostenuti. Se lo stato della macchina virtuale è arrestato/deallocato e non vengono fatturati costi per la macchina virtuale in esecuzione, verrà addebitato comunque il costo per le risorse di archiviazione usate dai dischi.
Spazio di archiviazione per la VM
Tutte le macchine virtuali di Azure hanno almeno due dischi rigidi virtuali. Il primo disco contiene il sistema operativo, mentre il secondo viene usato come risorsa di archiviazione temporanea. È consigliabile aggiungere altri dischi dati per archiviare i dati delle applicazioni. La separazione dei dati in dischi diversi consente di gestire i dischi in modo indipendente. Il numero massimo di dischi dati che è possibile collegare alla macchina virtuale è determinato dalle dimensioni della macchina virtuale, in genere due per vCPU.
Ci sono cinque tipi di disco, ognuno destinato a uno scenario specifico del cliente:
- Dischi Ultra
- SSD Premium v2 (anteprima)
- SSD Premium (unità SSD)
- SSD Standard
- HDD Standard (unità disco rigido)
La tabella seguente mostra un confronto tra i cinque tipi di disco per decidere quale usare.
Disco Ultra | SSD Premium v2 | SSD Premium | SSD Standard | ||
---|---|---|---|---|---|
Tipo di disco | SSD | SSD | SSD | SSD | HDD |
Scenario | Carichi di lavoro con livelli elevati di I/O, come SAP HANA, database di alto livello (ad esempio, SQL, Oracle) e altri carichi di lavoro con un numero elevato di transazioni. | Carichi di lavoro di produzione e sensibili alle prestazioni che richiedono costantemente bassa latenza, un numero elevato di operazioni di I/O al secondo e velocità effettiva elevata | Carichi di lavoro di produzione con requisiti particolari di prestazioni | Server Web, applicazioni aziendali usate poco di frequente e sviluppo/test | Backup, carichi di lavoro non critici, accesso poco frequente |
Dimensioni massime disco | 65.536 gibibyte (GiB) | 65.536 GiB | 32.767 GiB | 32.767 GiB | 32.767 GiB |
Velocità effettiva massima | 4.000 MB/s | 1\.200 MB/s | 900 MB/s | 750 MB/s | 500 MB/s |
Operazioni di I/O al secondo max | 160.000 | 80.000 | 20.000 | 6.000 | 2.000 |
Possibilità di uso come disco del sistema operativo | No | No | Sì | Sì | Sì |
Selezionare un sistema operativo
Azure fornisce varie immagini del sistema operativo che è possibile installare nella macchina virtuale, tra cui numerose distribuzioni di Linux. La scelta del sistema operativo può influire sui prezzi orari di calcolo perché Azure include il costo della licenza del sistema operativo nel prezzo.
Se si è alla ricerca di qualcosa di più avanzato rispetto a semplici immagini del sistema operativo di base, è possibile cercare in Azure Marketplace immagini più sofisticate che includono il sistema operativo e gli strumenti software più diffusi per scenari specifici. Se è necessario un nuovo sito WordPress, ad esempio, lo stack di tecnologie standard è costituito da un server Linux, un server Web Apache, un database MySQL e PHP. Invece di impostare e configurare ogni singolo componente, è possibile usare un'immagine del Marketplace e installare l'intero stack in una sola operazione.
Infine, se non si riesce a trovare un'immagine del sistema operativo adeguata, è possibile creare un'immagine personalizzata inserendo gli elementi necessari e usarla per creare le macchine virtuali. È possibile creare singole immagini da usare per lo sviluppo e il test. In alternativa, si può creare una Raccolta di calcolo di Azure per gestire più immagini e replicarle nelle aree in cui sono necessarie.