La virtualizzazione al giorno d'oggi gioca un ruolo fondamentale. Dall'utilizzo del desktop a livello di consumatore ai servizi cloud di livello aziendale, ci sono una varietà di applicabilità.
Questa guida ti aiuterà a iniziare con la virtualizzazione in modo completo. Questo ti darà sufficienti conoscenze fondamentali per te come studente, ingegnere o anche come CTO per comprendere i diversi tipi di virtualizzazione e come viene utilizzata oggi nel settore.
Questo è un articolo enorme, quindi lascia che ti riassuma di cosa parlerò.
- La prima parte introduce al sistema operativo host, alle macchine virtuali (VM) e agli hypervisor
- La seconda parte descrive i componenti essenziali della virtualizzazione:CPU, RAM, rete e storage
- La terza parte illustra i vantaggi della virtualizzazione
Cominciamo!
Macchine virtuali, host e hypervisor
Per avere una migliore comprensione di macchine virtuali, host e hypervisor, è essenziale iniziare con i fondamenti dell'hardware.
Innanzitutto, è necessaria una macchina fisica/server che includa i seguenti componenti che costituiscono l'intero sistema:
- Unità di alimentazione (PSU)
- Scheda madre
- Unità di elaborazione centrale (CPU)
- Memoria ad accesso casuale (RAM)
- Scheda di interfaccia di rete (NIC)
- Archiviazione:unità disco rigido (HDD) o unità a stato solido (SSD)
Tutti questi componenti sono assemblati insieme che si sincronizzano come un'unica unità di elaborazione diventando il proprio personal computer (PC) o server. Aspetta, un server personale sembra interessante!
Cos'è un sistema operativo (OS)?
Un sistema operativo è un software di sistema che funge da interfaccia tra l'utente e il computer per eseguire una varietà di applicazioni, con o senza un'interfaccia utente grafica. Una di queste applicazioni può essere programmi di virtualizzazione dedicati come VirtualBox, ad esempio.
Cos'è un hypervisor?
Un hypervisor è un software di sistema che funge da intermediario tra l'hardware del computer e le macchine virtuali. È responsabile dell'allocazione e dello sfruttamento efficace delle risorse hardware che devono essere utilizzate dalle rispettive macchine virtuali, che funzionano individualmente su un host fisico. Per questo motivo, gli hypervisor sono anche chiamati gestori di macchine virtuali.
Questo software di sistema funge da interfaccia tra l'utente e il computer con l'unico scopo di virtualizzazione, con o senza un'interfaccia utente grafica. Un esempio per uno di questi hypervisor è VMware FXI.
Un hypervisor è costituito da tre moduli principali:
Speditore — Costituisce il punto di ingresso del monitor e reindirizza le istruzioni emesse dall'istanza della macchina virtuale ai moduli allocatore o interprete descritti di seguito.
Allocatore — Ogni volta che una macchina virtuale tenta di eseguire un'istruzione che comporta la modifica delle risorse della macchina associata, l'allocatore viene richiamato dal dispatcher, che quindi alloca le risorse di sistema da fornire alla macchina virtuale.
Interprete — Consiste in routine dell'interprete che vengono eseguite ogni volta che una macchina virtuale esegue un'istruzione privilegiata. Questo viene invocato anche dal dispatcher.
È necessario installare un sistema operativo o un hypervisor che funga da interfaccia per interagire con un server/computer host fisico.
Supponiamo che sia Ubuntu Server dove puoi ospitare o eseguire varie applicazioni. Queste applicazioni sul server vengono eseguite all'interno del sistema operativo.
Utilizzando l'hardware, Ubuntu può controllarli e la quantità di risorse a cui hanno accesso.
Pertanto, un sistema operativo o hypervisor diventa un intermediario tra le applicazioni e l'hardware stesso.
Cos'è una macchina virtuale (VM)?
Una macchina virtuale è un software che emula tutte le funzionalità di un server fisico e viene eseguito su un sistema operativo host o un hypervisor.
Pertanto, non eseguirai direttamente le applicazioni sul sistema fisico. Verranno eseguiti su macchine virtuali, ciascuna con i propri sistemi operativi indipendenti. In questo modo, le macchine virtuali possono eseguire diversi sistemi operativi singolarmente all'interno dello stesso sistema fisico.
Tutte queste macchine virtuali possono condividere un insieme comune di hardware fisico e persino interagire tra loro su una rete virtuale, proprio come fanno i computer fisici.
Puoi avere un sacco di macchine virtuali, ognuna con il proprio sistema operativo indipendente, che condividono e utilizzano gli stessi componenti fisici menzionati in precedenza.
Un hypervisor o un software di virtualizzazione in esecuzione su un sistema operativo è in realtà ciò che controlla le risorse fisiche.
Un hypervisor ha accesso diretto all'hardware fisico e controlla a quali risorse possono accedere le macchine virtuali.
Ciò include:
- Quanta memoria (RAM) è allocata
- Quanto accesso fisico alla CPU ottengono
- Come accedono alla loro rete
- Come accedono al loro spazio di archiviazione
Man mano che vengono create più macchine virtuali su un software di virtualizzazione del sistema operativo (riduciamolo a OSVS) o Hypervisor, condividono anche lo stesso identico insieme di risorse fisiche.
Pertanto, OSVS o Hypervisor controlla:
- Come vengono condivise le risorse con le singole macchine virtuali
- Come vengono presentate le risorse alle singole macchine virtuali
Tipi di hypervisor
Diamo ora un'occhiata ai tipi di hypervisor e in che modo differiscono l'uno dall'altro.
Ipervisor di tipo 1
Un hypervisor che può essere installato in modo nativo ed eseguito direttamente su un host fisico è chiamato hypervisor di tipo 1.
Indicatori chiave
- Un hypervisor di tipo 1 può essere installato direttamente su un sistema bare-metal o su un host fisico.
- Non richiede prima l'installazione o la disponibilità di un sistema operativo (OS) per poter essere distribuito su un server.
- Accesso diretto a CPU, memoria, rete, archiviazione fisica.
- L'utilizzo dell'hardware è più efficiente e offre le migliori prestazioni.
- Maggiore sicurezza grazie all'assenza di qualsiasi livello aggiuntivo per l'accesso all'hardware.
- Ogni hypervisor di tipo 1 richiede sempre una macchina fisica dedicata.
- Può costare di più e adatto di più per soluzioni di livello aziendale.
- VMware ESXi, Citrix Hypervisor e Microsoft Hyper-V sono alcuni esempi di Hypervisor di tipo 1.
Ipervisore di tipo 2
Un hypervisor che non può essere installato in modo nativo e richiede un sistema operativo per essere eseguito su un host fisico è chiamato hypervisor di tipo 2.
Indicatori chiave
- Un hypervisor di tipo 2 non può essere installato direttamente su un sistema bare-metal o su un host fisico.
- Richiede prima l'installazione o la disponibilità di un sistema operativo per poter essere distribuito.
- Accesso indiretto a CPU, memoria, rete, archiviazione fisica.
- A causa di un livello aggiuntivo (OS) per accedere alle risorse, l'utilizzo dell'hardware può essere meno efficiente e ritardare le prestazioni.
- Potenziali rischi per la sicurezza dovuti alla disponibilità del sistema operativo host.
- Ogni hypervisor di tipo 2 non richiede una macchina fisica dedicata. Possono essercene molti su un singolo host.
- Può costare meno e adatto di più per soluzioni per piccole imprese.
- VMware Workstation Player, VMware Workstation Pro e VirtualBox sono alcuni esempi di Hypervisor di tipo 2.
File della macchina virtuale e stato attivo
Cerchiamo ora di capire i file che compongono le nostre macchine virtuali e come sfruttano l'archiviazione condivisa.
Una macchina virtuale sfrutta la memoria, la CPU, la rete e l'hardware di archiviazione del nostro host fisico. Come si fa?
Attraverso l'hypervisor.
Quando una macchina virtuale è in esecuzione, ha determinate informazioni in memoria. Queste informazioni fanno parte dello stato attivo della VM.
Quindi la VM è effettivamente operativa sull'host. Ogni volta che si riproduce un video o si apre un browser Web nella macchina virtuale, tali operazioni di runtime si verificano nella memoria della macchina virtuale. Ma in realtà si verificano tutti sull'host fisico. Questo è lo stato live di qualsiasi macchina virtuale.
Lo stato live della macchina virtuale elabora tutte le esecuzioni di runtime sulla CPU, motivo per cui avviene sull'host.
Quando si apre un browser per caricare un sito Web, la larghezza di banda della rete viene attraversata attraverso la scheda di rete, anch'essa parte dell'host fisico. Fa tutto parte dello stato live di una macchina virtuale che utilizza adattatori di archiviazione per inviare il traffico dati verso un dispositivo di archiviazione. Anche in questo caso, accade dal vivo in tempo reale sull'host.
Una macchina virtuale non ha dischi rigidi fisici. Se esegui Linux su una macchina virtuale, è necessaria la capacità di leggere e scrivere dati da e verso un'unità fisica.
Ciò significa che è necessario l'accesso a un disco fisico. La macchina virtuale sta leggendo da e verso ed è in esecuzione su un'unità virtualmente allocata. Ma le operazioni vengono effettivamente reindirizzate verso un dispositivo di archiviazione fisico da qualche parte. Potrebbe essere su una rete Fibre Channel, una rete Ethernet o il disco locale stesso, direttamente all'interno dell'hypervisor o del software di virtualizzazione del sistema operativo.
Le macchine virtuali devono utilizzare un set di file per la gestione della virtualizzazione. Uno di questi file rappresenta un'unità virtualmente allocata o un disco virtuale. Una macchina virtuale deve leggere o scrivere sul disco virtuale tramite questi file. Il traffico dati fluirà attraverso un adattatore di archiviazione per farlo accadere.
Per ovvi motivi, potrebbero esserci molti di questi file corrispondenti ad altre macchine virtuali archiviate nella stessa posizione fisica sul disco rigido.
Parliamo ora di come le macchine virtuali si spengono e si riavviano.
Per poterlo fare, la VM necessita di informazioni di configurazione che comprendono principalmente lo stato live:
- Quanta memoria dovrebbe avere la VM?
- Quanta CPU dovrebbe ottenere?
- Qual è la dimensione del disco allocata?
- In che modo la VM accede alla rete?
Ancora una volta, tutte queste informazioni sono memorizzate su un file.
Consentitemi di arruolare tutti i tipi di informazioni archiviate nei file della macchina virtuale per garantirne la piena funzionalità:
- Archiviazione statica o dinamica
- Informazioni sulla configurazione
- Informazioni BIOS
- Istantanee scattate
Quindi una macchina virtuale memorizza due tipi di stati:
Stato attivo
Lo stato live è ciò che sta accadendo in tempo reale che, come ho appena discusso, potrebbe essere:
- Quanta memoria corrente viene utilizzata
- Quanta CPU viene utilizzata
- Quali applicazioni vengono utilizzate attualmente
- Come viene utilizzata o attraversata la larghezza di banda della rete
Se l'host fisico o la macchina virtuale al suo interno si guasta, tutte le informazioni in tempo reale di cui sopra andranno perse. È simile allo scollegamento di un computer.
Stato persistente
Lo stato persistente sono i file di quella macchina virtuale, che vengono salvati in modo permanente. Ciò è possibile grazie a:
- File di archiviazione
- File di configurazione
- File di snapshot
I file relativi allo stato persistente costituiscono la VM.
Come noi umani non possiamo sopravvivere senza un'alimentazione adeguata, anche le macchine virtuali devono disporre di una corretta allocazione delle risorse in modo coerente. La mancanza di queste risorse significa che le macchine virtuali non funzioneranno al meglio.
I quattro elementi essenziali senza i quali le macchine virtuali non possono ottenere le migliori prestazioni sono:
- CPU
- RAM
- Rete
- Stoccaggio
Virtualizzazione CPU
In che modo una macchina virtuale ottiene l'accesso alle risorse della CPU dell'host fisico?
L'host fisico ha una CPU fisica. Supponiamo, ad esempio, di avere una CPU con 4 core fisici. Ora, se vuoi allocare 2 di questi core fisici, quando inizi a creare le tue macchine virtuali, allocherai 2 CPU virtuali. Ciò significa che la macchina virtuale avrebbe accesso a 2 core di processore fisici dalla CPU principale creando una VM con 2 CPU virtuali.
Ma questa allocazione non significa che altre macchine virtuali non possano sfruttare quei core, il che significa che posso assegnare tutti e 4 i core a un'altra macchina virtuale. Quindi, in definitiva, queste risorse possono essere condivise da tutte le macchine virtuali sull'hypervisor o dal software di virtualizzazione del sistema operativo.
A seconda del tipo di carico di lavoro, dovresti assegnare i core della CPU in base alla necessità delle macchine virtuali. Se una VM va bene con un utilizzo della CPU del 25%, potresti ovviamente assegnare le risorse rimanenti ad altre VM.
Pertanto, devi sempre sforzarti di ridimensionare sempre le tue macchine virtuali in base ai requisiti delle applicazioni, specialmente quando si tratta di risorse CPU.
Virtualizzazione della memoria
Cerchiamo ora di capire come le macchine virtuali sono in grado di utilizzare le risorse di memoria dell'hypervisor.
La quantità di memoria che puoi allocare a una macchina virtuale è ancora una volta basata sulla memoria fisica (RAM) che hai sul tuo server fisico.
Ad esempio, se il tuo server ha 8 GB di RAM, puoi allocare 4 GB ed eseguire un desktop Ubuntu completo sulla tua macchina virtuale. Il desktop di Ubuntu "pensa" di avere 4 GB di memoria fisica. Ma ciò che effettivamente accade è che questa memoria allocata viene mappata dagli effettivi 8 GB di memoria fisica stessa.
Quando assegni 4 GB alla VM, questa non può utilizzare più memoria di quella assegnata.
Come le CPU, ancora una volta non significa che questi 4 GB siano sempre dedicati alla VM. Se le applicazioni in esecuzione su questa macchina virtuale non necessitano attualmente di questa quantità di memoria, un'altra macchina virtuale può utilizzare la stessa risorsa, come e quando necessario.
Quando un'applicazione viene eseguita su una macchina virtuale, il sistema operativo (sulla macchina virtuale) alloca la memoria in base alla propria tabella di memoria e, quando viene chiusa su una macchina virtuale, il sistema operativo contrassegna tali pagine di memoria come libere. Ma poiché non è mai "a conoscenza" della presenza di un hypervisor o di un software di virtualizzazione, non informerà mai il server fisico di questa deallocazione.
Pertanto, è compito dell'hypervisor o del software di virtualizzazione continuare a guardare all'interno del sistema operativo della VM per monitorare queste allocazioni e assegnare di volta in volta porzioni di memoria inutilizzate ad altre VM.
In contrasto con questo aspetto condiviso dell'allocazione della memoria tra macchine virtuali, puoi anche imporre la prenotazione della memoria per macchine virtuali specifiche per utilizzare una porzione specifica della memoria fisica. Ciò significa che altre macchine virtuali non possono usare la memoria riservata anche se non è utilizzata dalla macchina virtuale con memoria riservata. In generale, è meglio evitare questa procedura, perché la condivisione della memoria garantisce un utilizzo efficace delle risorse a fine giornata.
Puoi collegarlo a server condivisi e dedicati forniti tramite Linode. È più economico condividere i server nella pratica e nella produzione quotidiana degli amministratori di sistema.
Virtualizzazione della rete
Una VM Ubuntu viene eseguita su un host su un hypervisor o un software di virtualizzazione. Questa macchina virtuale ha quella che chiamiamo una NIC virtuale V-NIC. Questo si espande alla scheda di interfaccia di rete virtuale.
Il sistema operativo (Ubuntu) non sa che è in esecuzione all'interno di una macchina virtuale. Quindi si aspetta di vedere tutto lo stesso tipo di hardware che vedrebbe se fosse in esecuzione su un server fisico.
Quando si tratta di virtualizzazione della rete, devi fornire la tua macchina virtuale, una scheda di interfaccia di rete virtuale.
Ubuntu implementerà effettivamente i suoi driver per una scheda di interfaccia di rete. Come sistema operativo guest non avrà idea che non sia realmente una scheda di rete fisica.
È una scheda di rete virtuale che è un hardware falso presentato alla nostra macchina virtuale come se fosse reale. Quindi, se hai un server fisico con una NIC fisica, collegheresti il tuo cavo Ethernet dalla porta Ethernet a uno switch fisico.
Se hai una macchina virtuale con una NIC virtuale, la collegherai a una porta su uno switch virtuale, proprio come faresti con una macchina fisica.
Pertanto, all'interno del nostro hypervisor o software di virtualizzazione, avremo qualcosa chiamato switch virtuale. Puoi connettere più macchine virtuali a questo switch virtuale e possono comunicare tra loro.
Finché li metti sulla stessa VLAN (rete locale virtuale), saranno in grado di comunicare attraverso lo switch virtuale proprio come farebbero con qualsiasi altro tipo di switch fisico.
Quindi, se hai una singola VM connessa a uno switch virtuale, puoi connettere una seconda VM. Ciò consente di inviare il traffico da una macchina virtuale a un'altra direttamente all'interno dello switch virtuale. Questo traffico non deve mai lasciare l'host fintanto che le macchine virtuali si trovano sulla stessa VLAN. Finché queste macchine virtuali si trovano sulla stessa VLAN, possono comunicare e il traffico non deve mai attraversare la rete fisica.
Ma ecco un punto importante. Una parte del traffico di rete dovrebbe attraversare la rete fisica, quindi lo switch virtuale avrà bisogno di un uplink.
Proprio come uno switch fisico ha uplink a uno switch fisico di livello superiore o un router fisico, anche il nostro switch virtuale richiede uplink. Questi uplink sono gli adattatori fisici effettivi sull'host. Questi adattatori fisici sono chiamati P-NIC o NIC fisici o NIC VM.
Una scheda di interfaccia di rete fisica o NIC è sempre integrata nelle nostre moderne schede madri sui nostri server:
Ma se lo desideri, puoi anche optare per una scheda di rete dedicata, collegata alla scheda madre per un collegamento in rete aggiuntivo:
Quando crei un hypervisor su un host, quell'host ha una o più schede di interfaccia di rete, proprio come farebbe qualsiasi altro server.
Quelle schede di interfaccia di rete fisiche su un host, si connettono a uno switch fisico e quello switch fisico avrà connessioni ai router. Questo è il modo in cui invia il traffico a Internet.
Attraverso questo meccanismo, può anche connettersi ad altri server fisici che si trovano all'interno dello stesso data center.
Quindi, le macchine virtuali possono comunicare con tutti quei componenti con o all'interno dello stesso server fisico.
Se il traffico deve effettivamente lasciare l'host per comunicare all'esterno dell'host per raggiungere un router e raggiungere un'altra VLAN o un'altra rete, quel traffico uscirà dalla VM.
Attraverso lo switch virtuale, uno degli switch virtuali effettua l'uplink verso la rete fisica.
Quando quel traffico arriva allo switch fisico, eseguirà una ricerca nella tabella MAC (un record di indirizzi fisici univoci).
Fornirà la porta appropriata verso la destinazione appropriata dove quel pacchetto deve andare. Potrebbe essere diretto verso Internet o verso un host fisico sulla tua rete locale.
Ma questo meccanismo garantisce la capacità di tutte le tue macchine virtuali di comunicare con tutti i dispositivi sulla mia rete fisica. Questo è ciò che fa un interruttore virtuale.
L'idea fondamentale qui è di ingannare il sistema operativo guest sulla macchina virtuale facendogli "pensare" di avere una scheda di interfaccia di rete fisica. Quindi fornisci gli stessi driver a Ubuntu e penserà che abbia un dispositivo hardware reale.
Quando i pacchetti di dati vengono inviati, il traffico viene effettivamente prelevato dall'hypervisor, che lo punta verso lo switch virtuale appropriato come indicato.
Virtualizzazione dello storage
Ora che hai appreso come le VM sfruttano CPU, memoria e rete, procediamo con la risorsa finale:lo storage.
Consentitemi di ribadire ancora una volta che il sistema operativo guest non ha idea di essere in esecuzione all'interno di una macchina virtuale. Una macchina virtuale non ha hardware fisico dedicato e include un disco di archiviazione. La macchina virtuale non ha un disco fisico ad essa dedicato.
Con il networking, avevamo una scheda di rete virtuale.
Con la virtualizzazione dello storage, avremo un controller SCSI virtuale, se pensiamo al modo in cui un server fisico funziona con i dischi rigidi interni. Quando un sistema operativo ha bisogno di scrivere una sorta di dati su disco, il sistema operativo genera un comando SCSI.
Se ha bisogno di leggere i dati dal disco, genera un comando SCSI e lo invia al controller SCSI, che si interfaccia con i dischi fisici. Questo è il modo in cui Ubuntu funziona con l'archiviazione, qui non sa che è in esecuzione all'interno di una macchina virtuale.
Quindi dobbiamo mantenere quell'illusione anche per il sistema operativo guest per i meccanismi di archiviazione.
Quindi fornisci a Linux (in esecuzione sulla VM) un controller SCSI virtuale. Emulerà come se stesse eseguendo dischi fisici reali.
Pertanto, quando Ubuntu deve eseguire una sorta di comando di archiviazione, penserà che ho un vero controller SCSI.
Quando un comando di archiviazione viene inviato al controller SCSI, ciò che accade effettivamente è che il controller SCSI virtuale (un dispositivo virtuale), li reindirizza all'hypervisor. La macchina virtuale invia questi comandi di archiviazione tramite il suo controller SCSI virtuale e arrivano all'hypervisor.
L'hypervisor determina cosa succede a quei comandi di archiviazione da qui. Se la macchina virtuale ha il proprio file VMDK o disco virtuale su un disco locale, invierà semplicemente quei comandi di archiviazione a quel file sul disco rigido locale.
Oltre a questa funzionalità di base, potrebbe anche esserlo
- un array di archiviazione Fibre Channel
- uno storage array iSCSI basato su Ethernet
- un canale in fibra su Ethernet
Ma funzionano tutti in modo simile.
Ciò che sarebbe diverso è in realtà la rete.
Se l'hypervisor invia il comando di archiviazione a un Fibre Channel, tale comando di archiviazione attraverserà la rete Fibre Channel fino a raggiungere il disco virtuale.
Indipendentemente dall'hypervisor, la tua macchina virtuale avrà un disco virtuale.
Questo è il modo in cui i comandi SCSI arrivano dalla tua macchina virtuale al tuo disco virtuale, indipendentemente da dove si trova quel disco virtuale.
Quando una macchina virtuale basata su Ubuntu genera un comando SCSI, lo invia al controller SCSI virtuale.
L'hypervisor determina la posizione appropriata per quel disco virtuale e lo invia all'adattatore di archiviazione e il comando di archiviazione arriva all'archivio dati.
Queste modifiche all'attraversamento dei dati vengono effettivamente scritte nel file che contiene il disco virtuale della macchina virtuale. Potrebbe essere .VMX, .VMDK o qualsiasi altro tipo di file virtuale.
Spero che ormai tu abbia compreso le basi della virtualizzazione della rete e dello storage. Consentitemi di evidenziare i vantaggi in termini di efficienza e mobilità della virtualizzazione e anche come convertire gli host fisici in macchine virtuali.
Vantaggi della virtualizzazione
Finora abbiamo parlato di come funziona sostanzialmente la virtualizzazione attraverso le varie modalità di gestione delle risorse. Parliamo ora dei numerosi vantaggi chiave.
Consolidamento
Per prima cosa, parliamo di efficienza.
Se confronti la tua infrastruttura virtuale con una palestra, e alcuni di voi potrebbero averlo già sperimentato.
Se vai in palestra intorno al 1° gennaio, la palestra inizia a essere molto affollata.
Durante la normale parte dell'anno sarebbe sufficiente una palestra con circa 20 tapis roulant e 50 macchine per esercizi.
Ma se sei proprietario di una palestra, sai che a gennaio ci saranno da due a tre volte più persone e sarebbe più produttivo triplicare le dimensioni del tuo ambiente.
Quando tutte quelle persone si rendono conto che, sì, forse non gli piace molto fare esercizio, smettono di usare la palestra.
D'ora in poi, puoi ridimensionare la palestra secondo le tue esigenze.
Ora, questo sarebbe davvero fantastico se potessi fare la stessa cosa con l'hardware del tuo data center virtuale.
Quando ti occupi di virtualizzazione, ti viene l'idea del cloud computing, dove c'è un fornitore o un fornitore di servizi come Linode, per esempio. Con esso puoi far girare un sacco di macchine virtuali temporanee sull'hardware di qualcun altro e soddisfare quel periodo intenso dell'anno per i tuoi clienti.
Ma non puoi davvero arrivare al cloud computing senza prima virtualizzare. Questo è il primo passo lungo quel percorso verso il quale possiamo arrivare a quello che chiamiamo uno stato di elasticità, in cui la tua infrastruttura può crescere o ridursi rapidamente.
La virtualizzazione è un elemento costitutivo di questo tipo di flessibilità. Ci offre la possibilità di consolidare i carichi di lavoro.
Di seguito, vediamo un data center di server fisici.
Per la migliore pratica, ognuno di questi server non dovrebbe eseguire un singolo sistema operativo.
Pensa a quanti carichi di lavoro in più potresti realizzare se eseguissi da 20 a 30 istanze Linux su ognuno di questi server invece di uno solo per server!
Questo è il più grande vantaggio della virtualizzazione. Questo è il vantaggio che inizialmente ha portato questa innovazione a virtualizzare:il consolidamento.
Efficienza
Nel diagramma seguente, hai tre diversi server con ruoli diversi che sono disponibili come singoli sistemi fisici nel nostro ambiente:
Hai un server di stampa che utilizza il 20 percento di tutte le risorse e lo stesso vale per il server Web e database.
Questi sono server fisici che in realtà non utilizzano tutte le loro risorse. Se ci pensi, hai pagato tutto quell'hardware e se stai usando solo il 20 percento, stai sprecando l'80 percento.
Bloccando le risorse su un host fisico che può eseguire un solo sistema operativo, ora hai due scelte per occuparti di questo problema:
Potresti iniziare a installare altre applicazioni sul nostro server e far funzionare più applicazioni sullo stesso server. Ma se devi riavviare il server di stampa, ti preoccuperai di cos'altro è in esecuzione su quel server di stampa?
Cos'altro puoi influire eseguendo la manutenzione sul mio server di stampa? Ci saranno troppi casi d'uso e scenari applicativi interdipendenti sullo stesso hardware e ciò riduce enormemente l'efficienza.
Pertanto, la maggior parte delle volte, ciò che finiamo è solo uno spreco di risorse. Puoi invece sbarazzarti di quei server fisici e consolidare quei carichi di lavoro su un hypervisor:
Grazie a questo consolidamento, ora puoi eseguire più istanze del sistema operativo su quell'hypervisor. Ora puoi massimizzare, ridimensionare e raggiungere in modo molto semplice ed efficiente un punto ottimale che potrebbe essere il 60 o il 70 percento di utilizzo delle risorse.
Quindi ora stai utilizzando in modo efficiente le risorse che hai acquistato, ma non le stai sovraccaricando.
Questo è il nostro obiettivo finale con la virtualizzazione:massimizzare l'investimento in hardware prodotto senza sprecare capitale aggiuntivo in risorse che non verranno mai utilizzate.
Mobilità
Un altro grande vantaggio della virtualizzazione è la mobilità.
Se riesci a ricordare come funziona la virtualizzazione della rete e dell'archiviazione, pensa a uno scenario in cui hai un array di archiviazione Fibre Channel. Consideriamo anche che hai appena investito in un nuovo storage array iSCSI.
Supponiamo ora che tu abbia il tuo array di archiviazione Fibre Channel e desideri riposizionare questa macchina virtuale e tutti i suoi file nel tuo nuovo dispositivo di archiviazione iSCSI, che si trova su una rete diversa.
Supponiamo che sia sulla rete Ethernet. Ora puoi trasferirti facilmente con il tuo hypervisor o software di virtualizzazione. Quando i comandi SCSI escono dalla VM, vengono ricevuti dall'hypervisor. Quando utilizzi un altro adattatore di archiviazione e riposiziona questi file VMS nell'altro array di archiviazione, l'hypervisor si accorge che hai apportato la modifica.
Reindirizzerebbe semplicemente quei comandi di archiviazione nella nuova posizione e il vantaggio è che puoi farlo anche senza tempi di inattività sulla tua macchina virtuale.
Diamo un'occhiata a un altro scenario.
Supponiamo che tu abbia più host e che ora scegli di prendere una VM Linux e riposizionare lo stato live della VM su un altro host. Funzionerà anche così, purché l'altro host abbia la possibilità di connettersi allo spazio di archiviazione condiviso. La tua VM sarà comunque in grado di accedere al suo disco virtuale e a tutti gli altri file critici della VM di cui ha bisogno.
Ecco come lo storage, la virtualizzazione e lo storage condiviso aiutano a raggiungere la mobilità. Puoi prendere macchine virtuali, spostarle su host diversi, spostare i loro file da un sistema di archiviazione a un altro senza tempi di inattività.
È tutto a causa dell'hypervisor nel mezzo che si interpone tra la macchina virtuale e l'hardware.
Questo è ciò che è comunemente noto come disaccoppiamento. Significa che la macchina virtuale non ha una relazione diretta con alcun hardware. Puoi spostarlo da un server fisico a un altro. Puoi anche spostarlo da un sistema di archiviazione a un altro. Non esiste una relazione fissa tra macchina virtuale e hardware specifico. Sono disaccoppiati nel vero senso del termine.
Quindi, come puoi vedere, la mobilità è uno dei principali vantaggi della virtualizzazione.
Un altro modo di vederlo:
Supponiamo di avere più host e di avere molte macchine virtuali in esecuzione su tutti questi host e il carico di lavoro non è molto bilanciato come desiderato.
Se sull'host uno sono in esecuzione tre macchine virtuali, potresti voler migrare alcuni di questi VMS per ospitarne due per equalizzare il carico di lavoro su questi due host.
Vuoi assicurarti che l'utilizzo delle risorse dei nostri host sia sempre utilizzato in modo abbastanza uniforme.
Se l'host uno sta esaurendo la memoria, puoi spostare alcune VM su un altro host e idealmente vorresti farlo senza tempi di inattività.
Puoi eseguire la migrazione in tempo reale e prendere una macchina virtuale in esecuzione e spostarla da un server fisico a un altro senza tempi di inattività. Questo è un motivo importante per cui potresti voler migrare le VM.
Un altro motivo è anche quando è necessario eseguire qualsiasi tipo di attività di manutenzione. Supponiamo che tu possa installare un po' di memoria fisica e aggiungere un altro host o qualsiasi altra forma di manutenzione fisica.
Ciò significa che avrai tempi di inattività su un host. To prevent that, you can migrate all of the VMs to another host, perform maintenance, install memory or whatever you want to, say installing patches or carrying out a necessary reboot. You can migrate all VMs off of that host, do whatever you need to and then bring them back once the host is back up. All this can happen without any disruption for users.
How this is done:
Let's take a look at an example, migration, Say here we have a virtual machine running on host one you want to patch up. You also need to reboot this host.
So you have to initiate a migration of this VM from host one to host two.
But there are some prerequisites:
- Shared storage
- Virtual disk files
- Configuration files
- Virtual NICs
- Snapshots
This is a VM that has network access and that virtual neck is connected to a virtual switch and it's available on a VLAN.
The virtual switch is connected to a physical switch and the virtual machine is addressed accordingly.
This VM exists on some VLAN that's got a port group on the virtual switch. If you move this VM down to another host and the virtual switch there does not have a matching configuration, that network would become unavailable.
You don't want that.
So you must ensure you have a compatible network on both of these hosts.
Simply said, you don't want the migrated VM to see anything different when it moves the host two and you want the compatable processors you want as they were on host one.
If they're Intel on host one, you want them to be compatible with AMD on host two.
You want these two hosts to be as much identical as you can possibly make them.
When it comes to the network and storage configuration, they obviously need to match up.
Finally, you need a way to perform the transfer from host one to host two. So you're going to have a special network that takes all of the contents of memory, takes what's currently happening on the current VM and creates a copy of it on the other host.
Once you've covered my prerequisites, the rest of it is pretty straightforward.
You write a copy of the VM that is going to be created on a destination host in this case.
Based on VMware terminology, you're going to use something called a VM kernel port to create a network, and that network is going to be used to create a copy of the current VM on the destination host.
When that copy is complete, you will capture everything that's changed in that VM during that copy process. You call this a memory bitmap.
All of the contents of this memory bitmap are transferred over to the new copy of the VM and that becomes your live running virtual machine.
The downtime is so negligible, that it's not even perceptible to the users of your applications. This is called live migration of a virtual machine, while it's running and moved from one host to another.
This facilitates amazing flexibility, because you can move VMs wherever you need to.
Another notable advantage is automated load balancing.
You can group together hosts in what's called a cluster. Once you group those together, what you would now want is to allow your virtual machines to efficiently make use of the resources of the cluster as a whole.
You'll want to consider all of these hosts are interchangeable. It doesn't matter which host your VMs run on. If VMs need to move around to equalize workload, you can definitely make that to happen automatically.
That's the purpose of automatic load bouncing in VMware terminology.
This is also called distributed resource scheduler, in order to allow virtual machines to automatically be live migrated from host to host for the purposes of load balancing across themselves.
Converting physical servers to VMs
In this section, you'll learn about some concepts required to convert a physical machine to a virtual machine.
There are different software options out there to accomplish that.
Let's say you have a physical server with Ubuntu installed on it. It has all kinds of physical hardware like CPUs, RAM and network adapters and storage disks.
Our Ubuntu operating system has drivers for devices such as network adapters. It knows what kind of CPUs are being used:be it AMD or Intel CPUs. It has got a SCSI controller to connect to physical disks and the operating system is also aware of the actual physical hardware.
When we take this physical server and use one of our software tools to convert it to a virtual machine, the first step that happens is that virtual machine is created as virtual replica of the physical machine.
You're going to have a virtual machine present your hypervisor with the appropriate CPU, memory, network and storage specifications. It might not exactly match up with what we had in the physical server.
When you create a virtual machine, your goal should always be to rightsize that virtual machine. It's never to just take what the physical server had and duplicate it. The goal is always to right size it to give the virtual machine the correct resources that it needs to do its job (efficiently run applications) and nothing extra.
You'd want your resource consumption to be about 60, 70 percent utilization for CPU and the same for memory. You don't want them unutilized at 10 percent with four CPUs. That's not efficient.
You're also going to need a physical NIC, for the virtual machine and this is going to be a hardware change for the guest operating system.
So what would be most ideal to have is a network interface card that was specifically designed to run on a virtual machine, a good example of this is the VMware VMAX.
The beautiful thing about this, is that now the virtual machine has no relationship with actual physical hardware, so we get mobility by breaking out of specific hardware dependency everytime.
Other benefit that is often overlooked is the fact that as you virtualize, all of your OS instances(Linux/Mac/Windows) are going to have a similar set of virtual hardware. It allows you to standardize your operating system configuration.
You replace our physical hardware with virtual hardware and your physical hard disk with a virtual disk.
This is a file that could be on a local storage of the host, it could be on:
- a fibre channel
- a SCSI storage array
- an NFS server
What's most important is that you create this virtual disk and migrate all of the data from the source virtual machine to the virtual disk. When the power's on, it's got its new hardware with its new disk. From this point on, it should just work.
That's how you convert a physical server to a virtual machine.
Depending on which hypervisor you're using:
- VMware has vCenter converter
- Microsoft has VM converter
- Veeam has disk to VHD
You can start using these solutions on your existing physical servers, convert them to virtual machines and run them on your hypervisor. Helder has shared some tips on building homelab which is a good way to experiment.
Hope you found this detailed introduction to virtualization helpful. Please leave any feedback if you have in the comment section below. Thank you.