Come configurare smartphone e PC. Portale informativo
  • casa
  • Windows 10
  • Documentazione in lingua russa per Ubuntu. Utilizzo di KVM per creare macchine virtuali sul server

Documentazione in lingua russa per Ubuntu. Utilizzo di KVM per creare macchine virtuali sul server

Oggi è difficile immaginare un mondo senza dispositivi computerizzati. Circa 20 anni fa, quasi tutti Elettrodomestici erano elettromeccanici, non si parlava di utilizzare circuiti informatici ovunque. I primissimi computer occupavano notevoli quantità di spazio e potevano fare relativamente poco. Sistemi informatici per Ultimamente hanno percorso un lungo cammino di sviluppo. Sebbene i computer non siano cambiati radicalmente, la potenza di calcolo è aumentata rapidamente. Avere un computer in una famiglia semplice non è più qualcosa di speciale.

IN questo momento, Spesso un gran numero di le apparecchiature informatiche presenti nei locali possono causare notevoli disagi. Per questo motivo iniziarono ad apparire sistemi centralizzati. Ma i sistemi centralizzati spesso non riescono a risolvere i problemi risolti da una rete di computer. Per questo motivo è stato proposto il concetto di virtualizzazione, quando one calcolatore centrale agisce come una rete di computer.

Fondamentalmente, tutti i sistemi operativi sono, in generale, una sorta di ambiente virtuale fornito allo sviluppatore di software come mezzo per implementare le attività finali. È passato da tempo il tempo in cui i programmi venivano scritti appositamente per l'hardware del computer utilizzando codici e query hardware. Oggi qualsiasi applicazione è, prima di tutto, un'applicazione scritta su alcune API controllate dal sistema operativo. Il compito del sistema operativo è fornire a queste API l'accesso diretto alle risorse hardware.

Esistono in realtà diversi tipi di virtualizzazione:

  • Virtualizzazione del software;
  • Virtualizzazione dell'hardware;
  • Virtualizzazione a livello di sistema operativo.

La virtualizzazione, a sua volta, avviene pieno E parziale.

Virtualizzazione del software– un tipo di virtualizzazione che utilizza varie librerie del sistema operativo, traducendo le chiamate della macchina virtuale in chiamate del sistema operativo. (DOSBox, Virtualbox, VirtualPC)

Virtualizzazione dell'hardware- un tipo che fornisce istruzioni hardware specializzate, in particolare istruzioni per il processore. Consente di eseguire query ignorando il sistema operativo guest ed eseguirle direttamente sull'hardware. ( Virtualizzazione KVM,virtualizzazione XEN, Parallels, VMware, Virtualbox)

Virtualizzazione a livello di sistema operativo– virtualizzazione solo di una parte della piattaforma, senza virtualizzazione completa dell'hardware. Implica il funzionamento di diverse istanze dell'ambiente del sistema operativo. (Docker, LXC)

Questo articolo prenderà in considerazione Virtualizzazione dell'hardware, e in particolare la virtualizzazione KVM.

Schema 1. – Interazione dei componenti della macchina virtuale con l'hardware

Funzionalità di virtualizzazione per il kernel Linux

Per eseguire richieste hardware dirette, il sistema operativo deve disporre di una libreria che invii queste richieste direttamente all'hardware. Sulle piattaforme Basi Linux per molto tempo semplicemente non esisteva un sistema di virtualizzazione integrato (hypervisor integrato). Ogni produttore di software di virtualizzazione che supportava la tecnologia di virtualizzazione dell'hardware è stato costretto a creare i propri moduli per il kernel Linux (vboxdrv in Virtualbox, vmware-service in VMWare, ecc.). Naturalmente, questo non poteva durare per sempre, e Qumranet, Inc., che era poi rilevata Radhat creò la Open Virtualization Alliance, che si riteneva potesse risolvere il problema della mancanza di un hypervisor di base per il kernel Linux. È così che è stato creato ipervisore KVM O Macchina virtuale basata su kernel.

Implementazione

L'hypervisor KVM è un modulo kernel Linux caricabile progettato per fornire la virtualizzazione sulla piattaforma Linux x86. Il modulo stesso contiene il componente di virtualizzazione stesso (kvm.ko) e il modulo caricabile specifico del processore kvm-amd.ko o kvm-intel.ko.

Un prerequisito per l'utilizzo di KVM è il supporto per le istruzioni di virtualizzazione: Intel VT o AMD e il kernel Versioni Linux 2.6.20 e versioni successive. C'è anche una porta KVM per Free-BSD. QEMU viene tradizionalmente utilizzato per invocare KVM, ma ci sono anche sforzi per aggiungere il supporto KVM a Virtualbox.

Lo stesso KVM non esegue l'emulazione. Invece, il programma in esecuzione nello spazio utente utilizza l'interfaccia /dev/kvm per configurare lo spazio degli indirizzi della macchina virtuale guest e attraverso di essa emula i dispositivi I/O e l'adattatore video.

KVM consente alle macchine virtuali di utilizzare immagini disco non modificate di QEMU, VMware e altri contenenti sistemi operativi. Ogni macchina virtuale ha il proprio hardware virtuale: schede di rete, disco, scheda video e altri dispositivi.

Utilizzo

Esistono molte implementazioni per l'utilizzo di questo hypervisor. Alcune sono intere librerie specializzate, altre assumono la forma di semplici applicazioni grafiche.

Per chiarezza, consideriamo la virtualizzazione KVM basata sulla libreria virt-manager.

Questa libreria semplifica la chiamata di diversi hypervisor fornendo interfaccia intuitiva per automatizzare il processo di virtualizzazione. Inoltre, la biblioteca ha la capacità di lavorare con l'infrastruttura di rete, che a volte è importante quando si costruiscono workstation client-server.

Schema 2. – Interazione dei componenti di libvirt

QEMU consente di creare un frame per chiamare l'hypervisor sul sistema client. Questo programma configurato con argomenti di chiamata da riga di comando, è abbastanza facile e semplice.

Ce ne sono anche diversi shell grafiche, ad esempio Scatole per gnomi.

Conclusione

La virtualizzazione è parte integrante del moderno sistemi aziendali, consente di risparmiare ingenti risorse finanziarie ed energetiche. Lo sviluppo delle tecnologie di virtualizzazione è direzione prioritaria molte organizzazioni. Sono in fase di sviluppo tecnologie come VGAPassthrough (tecnologia per "inoltrare" la scheda video del dispositivo host in una macchina virtuale) e PCIPassthrough ("inoltro" di un dispositivo PCI).

In questo articolo introduttivo presenterò brevemente tutti gli strumenti software utilizzati nel processo di sviluppo del servizio. Saranno discussi più dettagliatamente nei seguenti articoli.

Perché ? Questo sistema operativo mi è vicino e comprensibile, quindi non c'è stato tormento, tormento o agitazione nella scelta di una distribuzione. Non presenta particolari vantaggi rispetto a Red Hat Enterprise Linux, ma è stata presa la decisione di lavorare con un sistema familiare.

Se hai intenzione di implementare in modo indipendente un'infrastruttura utilizzando tecnologie simili, ti consiglierei di prendere RHEL: grazie alla buona documentazione e ai programmi applicativi ben scritti, sarà, se non un ordine di grandezza, sicuramente due volte più semplice, e grazie al sistema di certificazione sviluppato, puoi facilmente trovare un numero di specialisti che hanno familiarità con questo sistema operativo al livello adeguato.

Ancora una volta abbiamo deciso di utilizzare Debian Squeeze con una serie di pacchetti da Sid/Sperimentale e alcuni pacchetti sottoposti a backport e compilati con le nostre patch.
Si prevede di pubblicare un repository con i pacchetti.

Quando si sceglie la tecnologia di virtualizzazione, sono state prese in considerazione due opzioni: Xen e KVM.

Inoltre, è stato preso in considerazione il fatto che esisteva un numero enorme di sviluppatori, hoster e soluzioni commerciali basate su Xen: tanto più interessante era implementare una soluzione basata su KVM.

Il motivo principale per cui abbiamo deciso di utilizzare KVM è la necessità di correre macchine virtuali con FreeBSD e, in futuro, MS Windows.

Per gestire le macchine virtuali si è rivelato estremamente conveniente utilizzare prodotti che sfruttano le sue API: virsh, virt-manager, installazione virtuale, eccetera.

Questo è un sistema che memorizza le impostazioni delle macchine virtuali, le gestisce, conserva le statistiche su di esse, si assicura che l'interfaccia della macchina virtuale venga attivata all'avvio, collega i dispositivi alla macchina - in generale, fa un sacco di cose lavoro utile e qualcosa in più.

Naturalmente la soluzione non è perfetta. Gli svantaggi includono:

  • Messaggi di errore assolutamente folli.
  • Impossibilità di modificare al volo parte della configurazione della macchina virtuale, sebbene QMP (QEMU Monitor Protocol) lo consenta.
  • A volte, per qualche motivo sconosciuto, è impossibile connettersi a libvirtd: smette di rispondere agli eventi esterni.

All'inizio il problema principale nell'implementazione del servizio era la limitazione delle risorse per le macchine virtuali. In Xen, questo problema è stato risolto con l'aiuto di uno scheduler interno che distribuisce le risorse tra le macchine virtuali e, cosa migliore, è stata implementata anche la possibilità di limitare le operazioni del disco.

Non c'era niente di simile in KVM fino all'avvento del meccanismo di allocazione delle risorse del kernel. Come al solito in Linux, l'accesso a queste funzioni è stato implementato tramite uno speciale file system cgroup, in cui, utilizzando le consuete chiamate di sistema write(), si potrebbe aggiungere un processo a un gruppo, assegnargli il peso in pappagalli, specificare il core su cui verrà eseguito, specificare portata disco che questo processo può utilizzare o, ancora, assegnargli un peso.

Il vantaggio è che tutto questo è implementato all'interno del kernel e può essere utilizzato non solo per il server, ma anche per il desktop (che è stato utilizzato nel famoso "The ~200 Line Linux Kernel Patch That Does Wonders"). E secondo me, questo è uno dei cambiamenti più significativi nel ramo 2.6, senza contare il mio preferito #12309, e non l'archiviazione di un altro file system. Beh, forse, tranne POHMELFS (ma puramente a causa del nome).

Il mio atteggiamento nei confronti di questa libreria di utilità è molto ambiguo.

Da un lato assomiglia a questo:

E questa cosa è anche dannatamente difficile da assemblare dal sorgente, tanto meno in un pacchetto: a volte mi sembra così Linux da Scratch è un po' più semplice da costruire da zero.

D'altra parte è una cosa molto potente che permette di creare immagini per macchine virtuali, modificarle, comprimerle, installare grub, modificare la tabella delle partizioni, gestire file di configurazione, trasferire macchine hardware in un ambiente virtuale, trasferire macchine virtuali da un'immagine all'altra, trasferire macchine virtuali dall'immagine all'hardware e, a dire il vero, qui la mia fantasia mi delude un po'. Oh, sì: puoi anche eseguire un demone all'interno di una macchina virtuale Linux e accedere ai dati della macchina virtuale dal vivo, e fare tutto questo in shell, python, perl, java, ocaml. Questo è un elenco breve e non esaustivo di ciò che puoi fare con .

È interessante notare che la maggior parte del codice viene generata al momento dell'assemblaggio, così come la documentazione per il progetto. Ocaml e Perl sono ampiamente utilizzati. Il codice stesso è scritto in C, che viene poi racchiuso in OCaml, e i pezzi di codice ripetuti vengono generati da soli. Il lavoro con le immagini viene effettuato avviando un'immagine di servizio speciale (appliance supermin), alla quale vengono inviati i comandi attraverso un canale al suo interno. Questa immagine di salvataggio contiene un certo insieme di utilità, come parted, mkfs e altre utili per un amministratore di sistema.

Recentemente ho iniziato ad usarlo anche a casa, quando ho estratto i dati di cui avevo bisogno dall'immagine nandroid. Ma ciò richiede un kernel abilitato per yaffs.

Altro

Di seguito sono riportati alcuni collegamenti più interessanti alla descrizione del software utilizzato: leggilo e studialo tu stesso se sei interessato. Per esempio,

Ti sei mai chiesto come funziona il cloud? La tendenza IT in più rapida crescita, nello sviluppo della quale vengono investiti miliardi di dollari ogni anno, passa attraverso la sua processo tecnologico produzione. Questo processo può essere dettagliato in dettaglio indefinitamente, quindi considereremo solo la fase finale: la virtualizzazione, vale a dire prodotti software o componenti hardware con l'aiuto dei quali viene eseguita la virtualizzazione.

Il primo materiale della serie “Tecnologie VPS/VDS” è dedicato al prodotto software KVM (Kernel-based Virtual Machine). Iniziamo con esso, poiché è questo hypervisor che utilizziamo nel cloud Tucha e, ovviamente, il nostro atteggiamento nei suoi confronti è speciale.

Hypervisor KVM: caratteristiche e principio di funzionamento

Le tecnologie di virtualizzazione sono sempre più utilizzate in sistemi moderni. Le macchine virtuali sono il modo più semplice per avere diversi sistemi operativi con un ambiente software di accompagnamento per eseguire varie attività: test o sviluppo di software, organizzazione di hosting tramite VPS, distribuzione di prodotti digitali, formazione, ecc. Per semplificare la gestione delle macchine virtuali, vengono utilizzati gli hypervisor: soluzioni software che consentono di avviare, arrestare e distribuire rapidamente nuove macchine virtuali all'interno di un host. Uno degli hypervisor più popolari per Sistemi simili a UNIXè KVM.

Hypervisor KVM: architettura

KVM (abbreviazione di Kernel-based Virtual Machine) è un software che consente di implementare la virtualizzazione su computer che eseguono Linux e simili. Da qualche tempo KVM fa parte del kernel Linux e quindi si sviluppa insieme ad esso. Funziona solo su sistemi con supporto hardware per la virtualizzazione - attivo Processori Intel e AMD.

Per organizzare il proprio lavoro, KVM utilizza l'accesso diretto al kernel utilizzando un modulo specifico del processore (kvm-intel o kvm-amd). Inoltre, il complesso include il nucleo principale: kvm.ko e gli elementi dell'interfaccia utente, incluso il popolare QEMU. L'hypervisor ti consente di lavorare direttamente con i file della macchina virtuale e le immagini del disco di altri programmi. Per ogni macchina viene creato uno spazio isolato con la propria memoria, disco, accesso alla rete, scheda video e altri dispositivi.

Vantaggi e svantaggi di KVM

Come ogni soluzione software, KVM presenta sia pro che contro, in base a quali hoster e utenti finali decidono di utilizzare questo software.

I principali vantaggi dell’hypervisor sono:

  • risorse allocate in modo indipendente. Ognuno lavora sotto controllo KVM virtuale la macchina riceve la propria quantità di RAM e memoria permanente e non può “arrampicarsi” in altre aree, il che aumenta la stabilità;
  • Ampio supporto per i sistemi operativi guest. Tranne supporto totale Le distribuzioni UNIX, incluse *BSD, Solaris, Linux, hanno la possibilità di installare Windows e persino MacOS;
  • l'interazione con il kernel consente l'accesso diretto all'hardware postazione di lavoro questo fa il lavoro Più veloce;
  • sostegno dei giganti del mercato del software(RedHat Linux, HP, Intel, IBM) consente al progetto di svilupparsi rapidamente, coprendo un numero crescente di hardware e sistemi operativi, compresi i più recenti;
  • amministrazione semplice– la possibilità di controllare da remoto tramite VNC e un gran numero di software e componenti aggiuntivi di terze parti.

C'erano anche alcuni inconvenienti:

  • la relativa giovinezza dell'hypervisor (ad esempio, rispetto a Xen) e, di conseguenza, una crescita esplosiva portano a vari problemi, soprattutto quando si aggiunge il supporto per nuovi ambienti hardware e software;
  • complessità delle impostazioni, soprattutto per un utente inesperto. È vero, la maggior parte delle opzioni non ha bisogno di essere modificata: sono configurate in modo ottimale immediatamente.

Funzionalità e proprietà dell'hypervisor

Il complesso KVM è caratterizzato dalle seguenti proprietà fondamentali: sicurezza, controllo conveniente memoria, archiviazione sicura dati, migrazione in tempo reale, prestazioni, scalabilità e stabilità.

Sicurezza

In KVM, ogni macchina è un processo Linux, quindi è automaticamente soggetta alle politiche di sicurezza standard, nonché all'isolamento dagli altri processi. Componenti aggiuntivi speciali (come SELinux) aggiungono altri elementi di sicurezza: controllo degli accessi, crittografia, ecc.

Poiché KVM fa parte del kernel Linux, l'hypervisor eredita strumenti potenti gestione della memoria. Pagine di memoria di ciascun processo, ad es. le macchine virtuali possono essere copiate e modificate rapidamente senza compromettere la velocità. Grazie al supporto per sistemi multiprocessore, KVM ha la capacità di gestire grandi quantità di memoria. È supportata anche la generalizzazione della memoria, combinando pagine identiche e inviandone una copia alla macchina su richiesta, nonché altri metodi di ottimizzazione.

Archivio dati

Per archiviare le immagini della macchina e i relativi dati, KVM può utilizzare qualsiasi supporto supportato dal sistema operativo principale: dischi rigidi, NAS, unità rimovibili, compresi quelli con I/O multi-thread per velocizzare il lavoro. Inoltre, l'hypervisor può funzionare con distribuzione file system– ad esempio, GFS2. Le unità KVM hanno il proprio formato unico che supporta la creazione di istantanee dinamiche diversi livelli, crittografia e compressione.

Una caratteristica importante di KVM è il supporto per la migrazione in tempo reale: spostamento di macchine virtuali tra host diversi senza fermarle. Per gli utenti, tale migrazione è completamente invisibile: la macchina continua a funzionare, le prestazioni non ne risentono, le connessioni di rete sono attive. Naturalmente è possibile anche la migrazione attraverso la conservazione stato attuale macchine virtuali in uno snapshot e distribuzione su un altro host.

Prestazioni e scalabilità

La scalabilità e le prestazioni del complesso dovute alla stretta integrazione con Linux sono completamente ereditate da questo sistema operativo. Pertanto, l'hypervisor supporta fino a 16 processori (virtuali o fisici) e fino a 256 GB di RAM in ciascuna macchina virtuale. Ciò consente di utilizzare l'hypervisor anche sui sistemi più caricati.

Stabilità

Il pacchetto software viene costantemente migliorato, se inizialmente era solo supportato Piattaforma Linux x86, quindi oggi il numero varie piattaforme ce ne sono dozzine, inclusi tutti i più diffusi sistemi operativi per server. Inoltre, puoi distribuire facilmente una macchina virtuale con una build del sistema operativo modificata se è compatibile con la piattaforma principale. E grazie alla collaborazione con i principali produttori di software, l'hypervisor KVM può essere definito il più stabile e affidabile sul mercato.

La nota sarà utile a chiunque sia interessato a utilizzare la virtualizzazione nel proprio lavoro. La mia soluzione può benissimo essere adatta ad un uso industriale e sarà utile a chi vuole ridurre i costi dell'hardware se ha bisogno di avere un'infrastruttura di rete estesa. Alcune soluzioni IBM, ad esempio, si basano su un'opzione simile. Ma queste soluzioni sono tutt’altro che convenienti e sono richieste solo in casi eccezionali.
Così un giorno ho avuto bisogno di riprodurre a casa mia un’estesa infrastruttura di rete composta da varie piattaforme software. Il percorso è iniziato da Stazione di lavoro VMWare e KVM è finito... Perché KVM e come è successo, leggi sotto.

1. Un po' di storia o come tutto ha avuto inizio.
Mentre lavoravo in una banca, mi sono imbattuto in prima persona nella virtualizzazione. Era il sistema operativo AIX di IBM in esecuzione su mainframe. Fin dall’inizio sono rimasto stupito dalla potenza e dalla flessibilità di questo approccio. E quando ho dovuto riprodurre a casa un'ampia infrastruttura software a scopo di test, ho subito basato il tutto sui principi della virtualizzazione. Ciò ha permesso di evitare costi significativi per l'hardware e di adattare tutto in modo molto compatto in termini di spazio.
Il lettore dovrebbe notare che in realtà esiste una grande varietà di strumenti di virtualizzazione. Ognuno di loro ha le sue sottigliezze e sfumature. Il mio obiettivo è parlare di un'opzione con cui lavoro personalmente, descrivendo, se possibile, i difetti e le caratteristiche delle altre.
2. La mia scelta si chiama KVM (o macchina virtuale basata sul kernel).
Puoi leggere ulteriori informazioni su questa opzione.
Ma è meglio presentare tutto in ordine. Inizierò con le condizioni di selezione e quale delle opzioni a me note non soddisfa queste condizioni:
— il sistema principale deve essere conveniente e potente.

In termini di hardware, ho scelto l'opzione Fenomeno AMD X4 9550 / Asus M3A78 / 2x2Gb DDR-II / 1x160Gb IDE + 2x1Tb SATA-II. Il video qui non è per niente importante, tranne che nel caso di uno da incasso dovrete tenere conto che prende il sopravvento su parte memoria ad accesso casuale, di conseguenza, ce ne sarà meno per le macchine virtuali. Dirò subito che la scelta di una scheda madre con controller RAID integrato non era del tutto corretta. A quanto pare, questo RAID funziona solo in modalità programma, cioè. per i sistemi Windows sono necessari i driver, ma in Linux lo stesso effetto potrebbe essere ottenuto molto più facilmente utilizzando strumenti standard.
Utilizzo piattaforma software per il sistema principale era chiaramente a favore di GNU/Linux, perché ha permesso di ottenere un ambiente di virtualizzazione senza costi aggiuntivi di licenza, e anche più leggero in termini di carico (non capirò mai perché in Windows Server senza grafica non puoi mettere in scena o fare nulla…. carico inutile, IMHO). Inizialmente si prevedeva di utilizzare l'opzione Server Ubuntu Hardy LTS, ma quasi subito è stata fatta una migrazione a Debian Lenny (allora era appena stata rilasciata). Non sto sminuendo in alcun modo la dignità di Ubuntu, ma soggettivamente Debian è più stabile e funziona più velocemente.

— il sistema di virtualizzazione deve essere stabile, accessibile al pubblico e poco impegnativo in termini di risorse.

La scelta è vertiginosa, ma dopo aver studiato le recensioni su Internet e aver provato a usarlo, mi sono formato un'opinione soggettiva.
I prodotti VMWare non sono adatti. La workstation è a pagamento, non è stato possibile installare ESXi sul mio sistema a causa di un chipset non supportato (si è rivelato più moderno). VMWare Server sarebbe una buona scelta, ma a giudicare dalle recensioni è un po' pesante e si blocca periodicamente; io stesso non l'ho provato dopo il fallimento con ESXi. Non andavano bene anche per un altro motivo: l’azienda vende ancora i suoi prodotti e solo alcuni di essi sono disponibili gratuitamente.
VirtualBox si è rivelata un'ottima opzione. È disponibile in due versioni: OSE e Freeware. IN accesso libero Non ci sono fonti per la versione freeware, ma compensa in termini di funzionalità. Tra le differenze a me note, questa è l'assenza nella versione OSE Supporto USB, restrizioni quando si lavora con la rete, l'accelerazione grafica non è supportata (a proposito, dà un aumento molto decente della velocità della macchina virtuale). VirtualBox è l'ideale per implementazione più semplice, Perché consente di ottenere rapidamente una macchina virtuale funzionante senza movimenti inutili e un attento studio del manuale. Una caratteristica interessante è stata il supporto per lavorare dalla console, che consente di evitare l'uso di componenti aggiuntivi grafici e, di conseguenza, rimuove il carico aggiuntivo sulla macchina host. Per i "virtualizzatori domestici" principianti, consiglierei questa opzione. Personalmente lo uso ancora portatile personale per impostare rapidamente un ambiente di test, nonché per lavorare in Windows (Ubuntu è stato a lungo stabilito lì come sistema principale). Secondo i sentimenti soggettivi, VirtualBox funziona molto più velocemente di VMWare Workstation e occupa meno spazio sia sul disco che in memoria. Per ogni macchina è assegnato finestra separata e anche quando i driver sono installati nel sistema ospite (disponibili immediatamente), è possibile integrarli nel desktop host, il che è molto comodo e consente di distribuire le attività su diversi desktop virtuali.
QEMU è una cosa molto potente. Ma quando me ne sono ricordato, avevo già prestato attenzione alla virtualizzazione basata sul kernel e alle informazioni su Xen e KVM, quindi non ho conosciuto da vicino il puro QEMU.
Xen- sistema ideale per la virtualizzazione. Ma presenta uno svantaggio molto significativo: il sistema ospite deve essere preparato in anticipo.
KVM, basato su QEMU, è veloce quasi quanto Xen, ma ha funzionalità più flessibili e tutta la potenza delle impostazioni QEMU (anche se la maggior parte di ciò di cui avevo bisogno era in VirtualBOX). Entrambe le opzioni, Xen e KVM, sono implementate in tutte le distribuzioni moderne e non richiedono alcuno sforzo serio per l'utilizzo. Ma c'è una differenza fondamentale tra loro, di cui parleremo più avanti.

— è necessario poter riprodurre diverse piattaforme software su macchine virtuali.

Nonostante la disponibilità dei prodotti VMWare e VirtualBOX a questo proposito, mi sono rifiutato di usarli anche prima, quindi non li prenderò in considerazione... Ma per quanto riguarda Xen e KVM lo descriverò un po' più in dettaglio, perché Ho cercato informazioni anch'io per molto tempo.
Xen non permette di far girare sistemi diversi da quello host!!!, ovvero non predisposti preventivamente per il funzionamento ambiente virtuale. E sfortunatamente (o forse per fortuna), non possono essere elaborati in questo modo Distribuzioni Windows. La cosa non mi andava bene, perché alla fine la scelta è caduta sulla possibilità di utilizzare KVM, per la quale dovevo prepararmi in anticipo sistema ospite Non c'è bisogno.

Quindi i motivi per scegliere KVM in breve:

1. L'implementazione è disponibile immediatamente in qualsiasi grande distribuzione;
2. Implementato sulla base del kernel Linux, quindi ha un'alta velocità;
3. Utilizzato da giganti come RedHat e Ubuntu, che indica elevata stabilità e flessibilità;
4. Per l'installazione in una macchina virtuale non sono necessarie ulteriori manipolazioni con il sistema ospite.

3. Come l'ho fatto su Debian.
Successivamente ci sarà una descrizione più tecnica, che descriverà passo dopo passo come ho realizzato il mio server, che può facilmente gestire una dozzina di server virtuali.
Nonostante il fatto che la mia distribuzione preferita sia Ubuntu, alla fine sotto sistema di baseÈ stata scelta Debian. Nell'ambito dell'articolo non spiegherò le sottigliezze, cosa e come, ma sul desktop preferisco comunque utilizzare Ubuntu. La maggior parte delle istruzioni per Ubuntu e Debian sono rilevanti per entrambe le opzioni, quindi durante la configurazione le ho utilizzate entrambe.
Quindi, iniziamo a configurare il server.
Prendiamo la distribuzione Debian. Per non scaricare troppo in seguito e avere subito un nuovo sistema, ho scelto l'opzione netinstall, con la quale ho installato solo il " Sistema standard“Non abbiamo bisogno di altro. A proposito, sto utilizzando l'edizione a 64 bit per ottenere supporto per più RAM (>3 GB) senza soluzioni alternative e trucchi (ad esempio, un kernel del server a 32 bit Distribuzione di Ubuntu supporta più di 3 GB, ma solo se questa funzionalità è disponibile nel chipset).
Utilizzo un disco rigido IDE per le partizioni di sistema (“/”, “/home”, swap) in modo da non avere problemi con il sistema quando installato su un array RAID (e ce ne sono alcuni). Durante l'installazione creo immediatamente un RAID-1 basato su due dischi rigidi SATA per ottenere una maggiore sicurezza dei dati (le informazioni principali verranno archiviate su di esso). In futuro, per lavorare con un array RAID software, dovresti utilizzare l'utilità mdadm.
Sto ritoccando un po' il sistema appena installato. Per prima cosa installo ssh in modo da poter immediatamente riporre l'unità di sistema e scollegare da essa il monitor non più necessario: sudo apt-get install ssh Molte persone consigliano di cambiare la porta dallo standard 22 a un'altra. Ma questo dovrebbe essere fatto solo se sei sicuro delle tue azioni e il tuo server è connesso direttamente a Internet. A proposito, va detto che se viene utilizzato Non porto standard, allora sorgeranno difficoltà con telecomando Virtualizzazione KVM. Pertanto ho lasciato la porta standard, ma tramite il router hardware l'ho inoltrata a una non standard, accessibile dall'esterno.

Successivamente abilitiamo la sincronizzazione dell'ora tramite Internet (lo consiglio vivamente, tornerà utile).
sudo apt-get install ntp ntpdate
Per monitorare la temperatura di chipset, processore e dischi rigidi:
sudo apt-get install lm-sensors hddtemp
L'utilità hddtemp funziona immediatamente, per configurare lm-sensors eseguiamo dopo l'installazione: sudo sensors-detect e rispondi affermativamente a tutte le domande.
È molto facile da usare:
— scopri la temperatura del processore, del chipset e altre caratteristiche dei sensori sudo otteniamo qualcosa del tipo:

it8712-isa-0290
Adattatore: adattatore ISA
VCore 1: +1,33 V (min = +3,54 V, max = +3,30 V) ALLARME
VCore 2: +3,76 V (min = +1,39 V, max = +1,01 V) ALLARME
+3,3 V: +3,28 V (min = +4,00 V, max = +0,91 V) ALLARME
+5V: +6,69 V (min = +3,04 V, max = +6,10 V) ALLARME
+12V: +12,67 V (min = +15,23 V, max = +5,57 V) ALLARME
-12V: -15,33 V (min = -0,85 V, max = -12,39 V) ALLARME
-5 V: +2,85 V (min = +3,06 V, max = +3,47 V) ALLARME
Stdby: +5,99 V (min = +0,11 V, max = +6,37 V)
VBat: +3,31 V
ventola1: 2922 giri/min (min = 3260 giri/min, div = 2)
ventola2: 0 RPM (min = 5400 RPM, div = 2) ALLARME
ventola3: 0 RPM (min = 2732 RPM, div = 2) ALLARME
Temp. M/B: +44,0°C (bassa = -73,0°C, alta = -49,0°C) sensore = transistor
Temp. CPU: +32,0°C (bassa = -65,0°C, alta = -9,0°C) sensore = transistor
Temp3: +128,0°C (bassa = +23,0°C, alta = -66,0°C) sensore = disabilitato
cpu0_vid: +0.000 V

— scopri la temperatura di 1 duro Unità SATA- sudo hddtemp /dev/sda otteniamo qualcosa del tipo:

/dev/sda: WDC WD1001FALS-00J7B0: 33°C

Per ulteriore lavoro, consiglio di procurarsi un server DHCP di terze parti e di configurare un'interfaccia bridge sul nostro server di virtualizzazione.
Installiamo utilità necessarie: sudo apt-get install bridge-utils
Utilizzo il mio router come server DHCP e ho creato l'interfaccia bridge secondo le istruzioni. Le stesse istruzioni spiegano come creare una macchina virtuale KVM per impostazione predefinita utilizzando questo metodo di connessione. Per velocizzare il riavvio (situazione per niente critica se il server è attivo 24 ore su 24, 7 giorni su 7), ti consiglio di specificare in anticipo un indirizzo statico per l'interfaccia, anche se è disponibile DHCP.

E la parte migliore è installare moduli KVM e utilità utili. Lo aggiungeremo subito utente attuale al gruppo appropriato per la disponibilità dell'uso di KVM. Una descrizione su come utilizzare le utilità può essere trovata nei manuali già citati. sudo aptitude install kvm libvirt-bin virtinst virt-top python-virtinst
sudo adduser softovick libvirt In effetti, puoi usarlo subito. Non vedo alcun motivo nel descrivere tutti i comandi; c'è una pagina man per quello. Ma ti mostrerò come creo una macchina virtuale:
per Linux virt-install -n linux -r 512 -f linux.img -s 15 -c image.iso --accelerate --vnc --vncport=5900 --noautoconsole --os-type=linux --os-variant =generico26
per Windows virt-install -n windows -r 512 -f windows.img -s 15 -c image.iso --accelerate --vnc --vncport=5901 --noautoconsole --os-type=windows --os-variant =win2k3 --noacpi Successivamente, l'ulteriore avanzamento dell'installazione e lo schermo della macchina ospite possono essere controllati collegandosi utilizzando un client VNC al server sulle porte 5900 e 5901 (consiglio di definire in anticipo la porta VNC per ciascuna macchina in modo che sia conveniente connettersi). Ci sono molte altre opzioni utili, non le uso solo perché non ne ho riscontrato la necessità.

E un altro tocco, ma non l'ultimo. Non ho ancora capito come connettere al sistema ospite la possibilità di scrivere qualcosa direttamente su una partizione o cartella fisica nel raid, anche se ci ho provato. Pertanto, nel caso di Linux, mi collego ai dati sul server tramite nfs e, nel caso di Windows, tramite Samba. Configurare Samba è piuttosto banale, installa sudo aptitude install samba e modifica file di configurazione/etc/samba/smb.conf per le tue attività. Ed ecco l'installazione configurazione nfs non del tutto banale. Utilizzo questa opzione di installazione, che mi consente di connettermi a le cartelle necessarie da qualsiasi indirizzo IP della rete locale (digitare 192.168.10.*): sudo aptitude install nfs-kernel-server portmap
perl -pi -e "s/^OPZIONI/#OPZIONI/" /etc/default/portmap
echo "portmap: 192.168.10." >> /etc/hosts.allow
/etc/init.d/portmap riavviare
echo "/media/raid 192.168.10.0/255.255.255.0(rw,no_root_squash,subtree_check)" >> /etc/exports
/etc/init.d/nfs-kernel-server ricarica
Dopo i passaggi precedenti, è sufficiente farlo sul sistema ospite:
sudo mount server:/media/raid local_folder
Se necessario, puoi abilitare montaggio automatico durante il caricamento, correggendo il file di configurazione /etc/fstab, aggiungendo una riga del tipo:
virtuale:/media/raid /media/raid nfs valori predefiniti 0 2
Bene, in generale, la configurazione del nostro server di virtualizzazione è completa. Puoi gestirlo sia dalla console che utilizzando gli strumenti grafici virsh o virtual manager.

PS:
Alcuni consigli utili:
1. Se hai indicato porto specifico VNC per la macchina guest, quindi tramite Virtual Manager non sarai in grado di avviare automaticamente la console grafica.
2. Virtual Manager non sarà in grado di connettersi se hai eseguito l'override porta ssh. Più precisamente, ciò richiederà una comprensione lunga e noiosa.
3. Assicurati di usarlo per Windows guest Modalità server-noacpi in modo che venga installato normalmente.
4. Impostare con attenzione la modalità di risparmio energetico sui sistemi ospiti, non spegnere in nessun caso lo schermo, altrimenti non sarà possibile connettersi successivamente tramite VNC.
5. Se desideri spegnere e riavviare in remoto le macchine tramite Virtual Manager, disabilita lo screen saver, perché blocca la gestione dell'alimentazione.

Diciamo che sei uno studente giovane, ma ancora scarso, il che significa che tra tutte le piattaforme possibili hai solo un PC su Windows e PS4. Un bel giorno decidi di riprendere i sensi e diventare un programmatore, ma le persone sagge su Internet ti hanno detto che non puoi diventare un normale ingegnere senza Linux. Non puoi installare Fedora come sistema principale e unico, perché Windows è ancora necessario per i giochi e VKontakte, ma installa Secondo Linux sistema acceso HDD sei ostacolato dalla paura o dalla mancanza di esperienza.

Oppure diciamo che sei già cresciuto, ora sei il capo dei server grande azienda e un bel giorno noti che la maggior parte dei server non è caricata nemmeno a metà. Non è possibile collocare più applicazioni e dati sui server per motivi di sicurezza e i costi di supporto e manutenzione di una server farm in crescita stanno aumentando rapidamente.

Oppure, diciamo, hai già la barba e gli occhiali, tu Direttore tecnico e non sei soddisfatto di ciò che gli sviluppatori ottengono per distribuire una nuova applicazione nuovo server devi aspettare due mesi. Come andare avanti rapidamente in tali condizioni?

O forse sei un architetto che ha progettato un nuovo sistema complesso per l'elaborazione delle analisi aziendali. Il tuo sistema include elementi come ElasticSearch, Kafka, Spark e molto altro e ogni componente deve vivere separatamente, essere configurato in modo intelligente e comunicare con altri componenti. Da buon ingegnere, capisci che non è sufficiente installare semplicemente l'intero zoo direttamente sul tuo sistema. È necessario provare a distribuire un ambiente il più vicino possibile al futuro ambiente di produzione e preferibilmente in modo che i propri sviluppi funzionino senza problemi sui server di produzione.

E cosa fare in tutte queste situazioni difficili? Corretto: usa la virtualizzazione.

La virtualizzazione consente di installare molti sistemi operativi completamente isolati l'uno dall'altro e funzionanti fianco a fianco sullo stesso hardware.

Un po' di storia Le prime tecnologie di virtualizzazione sono apparse già negli anni '60, ma la loro reale necessità è apparsa solo negli anni '90, quando il numero dei server è cresciuto sempre di più. È stato allora che è sorto il problema di riciclare efficacemente tutto l'hardware, nonché di ottimizzare i processi di aggiornamento, distribuzione delle applicazioni, garanzia della sicurezza e ripristino dei sistemi in caso di disastro.

Lasciamo dietro le quinte la lunga e dolorosa storia dello sviluppo di varie tecnologie e metodi di virtualizzazione: per il lettore curioso alla fine dell'articolo ci saranno Materiali aggiuntivi su questo tema. La cosa importante è il risultato finale: tre approcci principali alla virtualizzazione.

Approcci alla virtualizzazione

Indipendentemente dall'approccio e dalla tecnologia, quando si utilizza la virtualizzazione c'è sempre una macchina host e su di essa installato un hypervisor che controlla le macchine ospiti.

A seconda della tecnologia utilizzata, un hypervisor può essere un software separato installato direttamente sull'hardware o una parte del sistema operativo.

Un lettore attento e amante delle parole d'ordine inizierà a borbottare in un paio di paragrafi che anche i suoi contenitori Docker preferiti sono considerati virtualizzazione. Parleremo delle tecnologie dei container un'altra volta, ma sì, hai ragione, lettore attento, anche i container sono una sorta di virtualizzazione, solo a livello di risorse dello stesso sistema operativo.

Esistono tre modi in cui le macchine virtuali interagiscono con l'hardware:

Trasmissione dinamica

In questo caso, le macchine virtuali non hanno idea di essere virtuali. L'hypervisor intercetta al volo tutti i comandi della macchina virtuale e li elabora, sostituendoli con quelli sicuri, quindi li restituisce alla macchina virtuale. Questo approccio soffre ovviamente di alcuni problemi di prestazioni, ma consente di virtualizzare qualsiasi sistema operativo, poiché il sistema operativo guest non necessita di essere modificato. La traduzione dinamica è utilizzata in Prodotti VMWare- il leader nel software di virtualizzazione commerciale.

Paravirtualizzazione

Nel caso della paravirtualizzazione, il codice sorgente del sistema operativo guest viene appositamente modificato in modo che tutte le istruzioni vengano eseguite nel modo più efficiente e sicuro possibile. Allo stesso tempo, la donna virtuale è sempre consapevole di essere una donna virtuale. Uno dei vantaggi è il miglioramento delle prestazioni. Lo svantaggio è che in questo modo non puoi virtualizzare, ad esempio, MacOS o Windows, o qualsiasi altro sistema operativo di cui non hai accesso al codice sorgente. La paravirtualizzazione in una forma o nell'altra viene utilizzata, ad esempio, in Xen e KVM.

Virtualizzazione dell'hardware

Gli sviluppatori di processori si sono resi conto in tempo che l'architettura x86 è poco adatta alla virtualizzazione, poiché inizialmente era stata progettata per un sistema operativo alla volta. Pertanto, dopo la comparsa della traduzione dinamica da VMWare e della paravirtualizzazione da Xen, Intel e AMD hanno iniziato a rilasciare processori con supporto hardware per la virtualizzazione.

Inizialmente, questo non ha comportato un grande incremento delle prestazioni, poiché l'obiettivo principale delle prime versioni era il miglioramento dell'architettura del processore. Tuttavia, ora, a più di 10 anni dall’avvento di Intel VT-x e AMD-V, la virtualizzazione dell’hardware non è in alcun modo inferiore e addirittura in qualche modo superiore ad altre soluzioni.

La virtualizzazione hardware utilizza e richiede KVM (Kernel-based Virtual Machine), che utilizzeremo in futuro.

Macchina virtuale basata su kernel

KVM è una soluzione di virtualizzazione integrata direttamente nel kernel Linux che è funzionale come altre soluzioni e superiore in termini di usabilità. Inoltre, KVM è una tecnologia open source, che, tuttavia, sta avanzando a pieno ritmo (sia in termini di scrittura del codice che in termini di marketing) e viene implementata nei suoi prodotti da Red Hat.

Questo, tra l'altro, è uno dei tanti motivi per cui insistiamo sulle distribuzioni Red Hat.

I creatori di KVM inizialmente si sono concentrati sul supporto della virtualizzazione dell'hardware e non hanno reinventato molte cose. Un hypervisor, in sostanza, è un piccolo sistema operativo che deve essere in grado di funzionare con memoria, rete, ecc. Linux è già molto bravo a fare tutto questo, quindi usare il kernel Linux come hypervisor è una soluzione tecnica logica e bella. Ciascuno virtuale Macchina KVM-è semplicemente separato Processo Linux, la sicurezza è fornita utilizzando SELinux/sVirt, le risorse sono gestite utilizzando CGroups.

Parleremo più approfonditamente di SELinux e CGroups in un altro articolo, non allarmatevi se non conoscete queste parole.

KVM non funziona solo come parte del kernel Linux: dalla versione del kernel 2.6.20, KVM è un componente fondamentale di Linux. In altre parole, se hai Linux, allora hai già KVM. Comodo, vero?

Vale la pena dire che nel campo delle piattaforme cloud pubbliche Xen domina un po’ più che completamente. Ad esempio, AWS EC2 e Rackspace utilizzano Xen. Ciò è dovuto al fatto che Xen è apparso prima di tutti gli altri ed è stato il primo a raggiungere un livello di prestazione sufficiente. Ma c'è anche buone notizie: nel novembre 2017, che sostituirà gradualmente Xen per il più grande fornitore di servizi cloud.

Sebbene KVM utilizzi la virtualizzazione hardware, per alcuni driver di dispositivi I/O KVM può utilizzare la paravirtualizzazione, che fornisce miglioramenti delle prestazioni per determinati casi d'uso.

libvirt

Siamo quasi arrivati ​​alla parte pratica dell'articolo, non resta che considerare un altro strumento open source: libvirt.

libvirt è un insieme di strumenti che fornisce un'unica API a molte diverse tecnologie di virtualizzazione. Usando libvirt, in linea di principio, non importa quale sia il "backend": Xen, KVM, VirtualBox o qualcos'altro. Inoltre, puoi usare libvirt all'interno dei programmi Ruby (e anche Python, C++ e molto altro). Puoi anche connetterti alle macchine virtuali da remoto tramite canali sicuri.

A proposito, libvirt è sviluppato da Red Hat. Hai già installato Stazione di lavoro Fedora sistema principale?

Creiamo una macchina virtuale

libvirt è solo un'API, ma spetta all'utente come interagire con essa. Ci sono tante opzioni. Ne useremo diversi utilità standard. Ti ricordiamo: insistiamo nell'utilizzare le distribuzioni Red Hat (CentOS, Fedora, RHEL) e i comandi seguenti sono stati testati su uno di questi sistemi. Per gli altri Distribuzioni Linux possono verificarsi lievi differenze.

Innanzitutto, controlliamo se la virtualizzazione dell'hardware è supportata. In effetti, funzionerà senza il suo supporto, solo molto più lentamente.

egrep --color = auto "vmx|svm|0xc0f" /proc/cpuinfo # se non viene visualizzato nulla, non c'è supporto :(

Poiché KVM è un modulo del kernel Linux, è necessario verificare se è già caricato e, in caso contrario, caricarlo.

lsmod | grep kvm # kvm, kvm_intel, kvm_amd. Se non viene visualizzato nulla, è necessario scaricarlo moduli richiesti # Se il modulo non è caricato modprobe kvm modprobe kvm_intel # o modprobe kvm_amd

È possibile che la virtualizzazione dell'hardware sia disabilitata nel BIOS. Pertanto, se i moduli kvm_intel/kvm_amd non vengono caricati, controllare le impostazioni del BIOS.

Ora installiamo pacchetti richiesti. Il modo più semplice per farlo è installare un gruppo di pacchetti contemporaneamente:

elenco dei gruppi yum "Virtuale*"

L'elenco dei gruppi dipende dal sistema operativo utilizzato. Il mio gruppo è stato chiamato Virtualizzazione. Per gestire le macchine virtuali dalla riga di comando, utilizzare l'utilità virsh. Controlla se hai almeno una macchina virtuale usando il comando virsh list. Molto probabilmente no.

Se non ti piace la riga di comando, c'è anche virt-manager, una GUI molto comoda per le macchine virtuali.

virsh può creare macchine virtuali solo da file XML, il cui formato può essere studiato nella documentazione di libvirt. Fortunatamente c'è anche virt-manager e il comando virt-install. Puoi capire tu stesso la GUI, ma ecco un esempio di utilizzo di virt-install:

sudo virt-install --name mkdev-vm-0 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --memory = 1024 --vcpus = 1 \ --disk size = 8

Invece di specificare la dimensione del disco, puoi crearla in anticipo tramite virt-manager o tramite virsh e un file XML. Ho usato l'immagine sopra di Centos 7 minimal, che è facile da trovare sul sito web di Centos.

Ora rimane una domanda importante: come connettersi alla macchina creata? Il modo più semplice per farlo è tramite virt-manager: basta fare doppio clic sulla macchina creata e si aprirà una finestra con una connessione SPICE. La schermata di installazione del sistema operativo ti aspetta lì.

A proposito, KVM può nidificare la virtualizzazione: macchine virtuali all'interno di una macchina virtuale. Dobbiamo andare più a fondo!

Dopo aver installato manualmente il sistema operativo, ti chiederai immediatamente come è possibile automatizzare questo processo. Per fare ciò, abbiamo bisogno di un'utilità chiamata Kickstart, progettata per configurare automaticamente il sistema operativo per la prima volta. Si tratta di un semplice file di testo in cui è possibile specificare la configurazione del sistema operativo, fino ai vari script che vengono eseguiti dopo l'installazione.

Ma dove posso trovare un file del genere? Perché non scriverlo da zero? Ovviamente no: poiché abbiamo già installato Centos 7 all'interno della nostra macchina virtuale, non ci resta che collegarci ad essa e trovare il file /root/anaconda-ks.cfg - questa è la configurazione di Kickstart per creare una copia del già sistema operativo creato. Devi solo copiarlo e modificare il contenuto.

Ma copiare semplicemente un file è noioso, quindi aggiungeremo qualcos'altro. Il fatto è che per impostazione predefinita non saremo in grado di connetterci alla console della macchina virtuale creata dalla riga di comando della macchina host. Per fare ciò, è necessario modificare la configurazione del bootloader GRUB. Pertanto, alla fine del file Kickstart aggiungeremo la seguente sezione:

%post --log = /root/grubby.log /sbin/grubby --update-kernel = ALL --args = "console=ttyS0" %end

%post , come puoi immaginare, verrà eseguito dopo l'installazione del sistema operativo. Il comando grubby aggiornerà la configurazione di GRUB per aggiungere la possibilità di connettersi alla console.

A proposito, puoi anche specificare la possibilità di connetterti tramite la console proprio durante la creazione della macchina virtuale. Per fare ciò, è necessario passare un ulteriore argomento al comando virt-install: --extra-args="console=ttyS0" . Successivamente è possibile installare il sistema operativo stesso in modalità testo interattiva dal terminale della macchina host, collegandosi alla macchina virtuale tramite virsh console subito dopo la sua creazione. Ciò è particolarmente utile quando si creano macchine virtuali su un server hardware remoto.

Ora puoi applicare la configurazione creata! virt-install consente di passare argomenti aggiuntivi durante la creazione di una macchina virtuale, incluso il percorso del file Kickstart.

sudo virt-install --name mkdev-vm-1 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --initrd-inject /path/to/ks.cfg \ --extra- argomenti ks = file:/ks.cfg \ --memory = 1024 --vcpus = 1 --dimensione disco = 8

Dopo aver creato la seconda macchina virtuale (in modo completamente automatico), è possibile connettersi ad essa dalla riga di comando utilizzando il comando virsh console vm_id. vm_id Puoi scoprirlo dall'elenco di tutte le macchine virtuali utilizzando il comando virsh list.

Uno dei vantaggi derivanti dall'utilizzo di KVM/libvirt è la straordinaria documentazione, inclusa quella prodotta da Red Hat. Il caro lettore è invitato a studiarlo con la dovuta curiosità.

Certo, creare macchine virtuali come questa con le mani nella console, e poi configurarle solo tramite Kickstart non è il massimo processo conveniente. Nei prossimi articoli esamineremo molti strumenti interessanti che rendono la configurazione del sistema più semplice e completamente automatizzata.

Qual è il prossimo?

È impossibile racchiudere tutto ciò che vale la pena sapere sulla virtualizzazione in un unico articolo. Abbiamo esaminato diverse opzioni per l'utilizzo della virtualizzazione e i suoi vantaggi, abbiamo approfondito un po' i dettagli del suo funzionamento e abbiamo conosciuto la migliore soluzione, a nostro avviso, per questi compiti (KVM) e abbiamo persino creato e configurato una macchina virtuale.

È importante comprendere che le macchine virtuali sono gli elementi costitutivi delle moderne architetture cloud. Consentono alle applicazioni di crescere automaticamente fino a dimensioni illimitate, massimizzandole in modo veloce e con il massimo utilizzo di tutte le risorse.

Non importa quanto potente e ricco di servizi sia AWS, la sua base sono le macchine virtuali su Xen. Ogni volta che crei un nuovo droplet su DigitalOcean, stai creando una macchina virtuale. Quasi tutti i siti che utilizzi sono ospitati su macchine virtuali. La semplicità e la flessibilità delle macchine virtuali consente non solo di costruire sistemi di produzione, ma rende anche lo sviluppo e il test locale dieci volte più semplici, soprattutto quando il sistema coinvolge molti componenti.

Abbiamo imparato come creare una singola macchina: non male per testare un'applicazione. Ma cosa succede se abbiamo bisogno di più macchine virtuali contemporaneamente? Come comunicheranno tra loro? Come si ritroveranno? Per fare ciò, nel prossimo articolo della serie dovremo capire come funzionano in generale le reti, come funzionano nel contesto della virtualizzazione e quali componenti sono coinvolti in questo lavoro e devono essere configurati.

I migliori articoli sull'argomento