Astăzi este greu de imaginat o lume fără dispozitive computerizate. Acum vreo 20 de ani, aproape toată lumea Aparate erau electro-mecanice, nu se vorbea despre folosirea circuitelor informatice peste tot. Primele computere ocupau cantități semnificative de spațiu și puteau face relativ puțin. Sisteme informatice pt În ultima vreme au parcurs un drum destul de lung de dezvoltare. Deși computerele nu s-au schimbat fundamental, puterea de calcul a crescut rapid. A avea un computer într-o familie simplă nu mai este ceva special.

ÎN acest moment, de multe ori un numar mare de echipamentele informatice din incintă pot cauza inconveniente semnificative. Din acest motiv au început să apară sisteme centralizate. Dar sistemele centralizate de multe ori nu pot rezolva problemele pe care le rezolvă o rețea de calculatoare. Din acest motiv, conceptul de virtualizare a fost propus, când unul calculator central acţionează ca o reţea de calculatoare.

În esență, toate sistemele de operare sunt, în general, un fel de mediu virtual care este furnizat dezvoltatorului de software ca mijloc de implementare a sarcinilor finale. A trecut de mult timp când programele erau scrise special pentru hardware-ul computerului folosind coduri hardware și interogări. Astăzi, orice aplicație este, în primul rând, o aplicație scrisă pe niște API, care este controlată de sistemul de operare. Sarcina sistemului de operare este de a oferi acestor API-uri acces direct la resursele hardware.

Există de fapt mai multe tipuri de virtualizare:

• Virtualizare software;
• Virtualizare hardware;
• Virtualizare la nivel de sistem de operare.

Virtualizarea, la rândul său, are loc deplinȘi parțial.

Virtualizare software– un tip de virtualizare care folosește diferite biblioteci de sistem de operare, traducând apelurile de mașină virtuală în apeluri de sistem de operare. (DOSBox, Virtualbox, VirtualPC)

Virtualizare hardware- un tip care oferă instrucțiuni hardware specializate, în special instrucțiuni de procesor. Vă permite să executați interogări ocolind sistemul de operare invitat și să le executați direct pe hardware. ( Virtualizare KVM,virtualizare XEN, Parallels, VMware, Virtualbox)

Virtualizare la nivel de sistem de operare– virtualizarea doar unei părți a platformei, fără virtualizarea completă a hardware-ului. Implică funcționarea mai multor instanțe ale mediului OS. (Docker, LXC)

Acest articol va lua în considerare Virtualizare hardware,și în special virtualizarea KVM.

Schema 1. – Interacțiunea componentelor mașinii virtuale cu hardware-ul

Caracteristici de virtualizare pentru nucleul Linux

Pentru a executa cereri hardware directe, sistemul de operare trebuie să aibă o bibliotecă care să trimită aceste solicitări direct hardware-ului. Pe platforme baze Linux pentru o lungă perioadă de timp pur și simplu nu exista un sistem de virtualizare încorporat (hipervizor încorporat). Fiecare producător de software de virtualizare care a suportat tehnologia de virtualizare hardware a fost forțat să-și creeze propriile module pentru nucleul Linux (vboxdrv în Virtualbox, vmware-service în VMWare etc.) Desigur, acest lucru nu putea dura pentru totdeauna, iar Qumranet, Inc., care a fost apoi cumpărat Radhat a creat Open Virtualization Alliance, care a fost considerată a rezolva problema lipsei unui hypervisor de bază pentru kernel-ul Linux. Așa a fost creat hipervizor KVM sau Mașină virtuală bazată pe kernel.

Implementarea

Hypervizorul KVM este un modul de kernel Linux încărcat care este proiectat să ofere virtualizare pe platforma Linux x86. Modulul în sine conține componenta de virtualizare în sine (kvm.ko) și modulul încărcat specific procesorului kvm-amd.ko sau kvm-intel.ko.

O condiție prealabilă pentru utilizarea KVM este suportul pentru instrucțiunile de virtualizare - Intel VT sau AMD și nucleul versiuni Linux 2.6.20 și mai sus. Există, de asemenea, un port KVM pentru Free-BSD. QEMU este folosit în mod tradițional pentru a invoca KVM, dar există și eforturi pentru a adăuga suport KVM la Virtualbox.

KVM în sine nu realizează emulare. În schimb, programul care rulează în spațiul utilizatorului folosește interfața /dev/kvm pentru a configura spațiul de adresă al oaspeților mașinii virtuale și prin aceasta emulează dispozitivele I/O și adaptorul video.

KVM permite mașinilor virtuale să utilizeze imagini de disc nemodificate ale QEMU, VMware și altele care conțin sisteme de operare. Fiecare mașină virtuală are propriul hardware virtual: plăci de rețea, disc, placă video și alte dispozitive.

Utilizare

Există multe implementări pentru utilizarea acestui hypervisor. Unele sunt biblioteci întregi specializate, altele iau forma unor aplicații grafice simple.

Pentru claritate, luăm în considerare virtualizarea KVM bazată pe bibliotecă virt-manager.

Această bibliotecă facilitează apelarea diferiților hipervizori prin furnizarea interfață ușor de utilizat pentru a automatiza procesul de virtualizare. În plus, biblioteca are capacitatea de a lucra cu infrastructura de rețea, ceea ce este uneori important atunci când construiesc stații de lucru client-server.

Schema 2. – Interacțiunea componentelor libvirt

QEMU vă permite să creați un cadru pentru apelarea hypervisorului pe sistemul client. Acest program configurat cu argumente de apel în linia de comandă, este destul de ușor și simplu.

Există și câteva cochilii grafice, ca Cutii cu gnomi.

Concluzie

Virtualizarea este o parte integrantă a modernului sisteme corporative, vă permite să economisiți resurse financiare și energetice enorme. Dezvoltarea tehnologiilor de virtualizare este direcție prioritară multe organizații. Tehnologii precum VGAPassthrough (tehnologie pentru „redirecționarea” plăcii video a dispozitivului gazdă într-o mașină virtuală) și PCIPassthrough („redirecționarea” unui dispozitiv PCI) sunt în curs de dezvoltare.

În acest articol introductiv, voi prezenta pe scurt toate instrumentele software utilizate în procesul de dezvoltare a serviciilor. Acestea vor fi discutate mai detaliat în articolele următoare.

De ce ? Acest sistem de operare este aproape și de înțeles pentru mine, așa că nu a existat nici un chin, nici un chin sau zvârlire atunci când am ales o distribuție. Nu are avantaje deosebite față de Red Hat Enterprise Linux, dar a fost luată decizia de a lucra cu un sistem familiar.

Dacă intenționați să implementați în mod independent o infrastructură folosind tehnologii similare, v-aș sfătui să luați RHEL: datorită unei documentații bune și a unor programe de aplicație bine scrise, va fi, dacă nu un ordin de mărime, atunci cu siguranță de două ori mai simplu și datorită sistemului de certificare dezvoltat, puteți găsi cu ușurință o serie de specialiști care sunt familiarizați cu acest sistem de operare la nivelul corespunzător.

Noi, din nou, am decis să folosim Debian Squeeze cu un set de pachete din Sid/Experimentalși unele pachete backported și compilate cu patch-urile noastre.
Există planuri de a publica un depozit cu pachete.

La alegerea tehnologiei de virtualizare, au fost luate în considerare două opțiuni - Xen și KVM.

De asemenea, s-a luat în considerare faptul că a existat un număr mare de dezvoltatori, hosteri și soluții comerciale bazate pe Xen - cu atât mai interesantă a fost implementarea unei soluții bazate pe KVM.

Motivul principal pentru care am decis să folosim KVM este necesitatea de a rula mașini virtuale cu FreeBSD și, în viitor, cu MS Windows.

Pentru a gestiona mașinile virtuale, sa dovedit a fi extrem de convenabil să folosești produse care folosesc API-ul său: virsh, virt-manager, virt-install, etc.

Acesta este un sistem care stochează setările mașinilor virtuale, le gestionează, păstrează statistici asupra lor, se asigură că interfața mașinii virtuale este ridicată la pornire, conectează dispozitivele la mașină - în general, face o grămadă de lucruri muncă utilă si putin mai mult pe deasupra.

Desigur, soluția nu este ideală. Dezavantajele includ:

• Mesaje de eroare absolut nebunești.
• Imposibilitatea de a schimba o parte din configurația mașinii virtuale din mers, deși QMP (QEMU Monitor Protocol) permite acest lucru.
• Uneori, dintr-un motiv necunoscut, este imposibil să vă conectați la libvirtd - nu mai răspunde la evenimente externe.

Principala problemă în implementarea serviciului la început a fost limitarea resurselor pentru mașinile virtuale. În Xen, această problemă a fost rezolvată cu ajutorul unui planificator intern care distribuie resurse între mașinile virtuale - și cel mai bine este că a fost implementată și capacitatea de a limita operațiunile de pe disc.

Nu a existat așa ceva în KVM până la apariția mecanismului de alocare a resurselor kernelului. Ca de obicei în Linux, accesul la aceste funcții a fost implementat printr-un sistem de fișiere special cgroup, în care, folosind apelurile obișnuite de sistem write(), se poate adăuga un proces unui grup, se poate atribui ponderea acestuia în papagali, se specifică nucleul pe care va rula, se specifică debitului disc pe care acest proces îl poate folosi sau, din nou, îi atribuie o greutate.

Avantajul este că toate acestea sunt implementate în interiorul nucleului și pot fi folosite nu numai pentru server, ci și pentru desktop (care a fost folosit în celebrul „The ~200 Line Linux Kernel Patch That Does Wonders”). Și, după părerea mea, aceasta este una dintre cele mai semnificative modificări în ramura 2.6, fără a lua în calcul #12309 preferatul meu și nu arhiva unui alt sistem de fișiere. Ei bine, poate, cu excepția POHMELFS (dar doar din cauza numelui).

Atitudinea mea față de această bibliotecă de utilitate este foarte ambiguă.

Pe de o parte arata cam asa:

Și chestia asta este, de asemenea, al naibii de greu de asamblat de la sursă, cu atât mai puțin într-un pachet: uneori mi se pare că Linux De la Scratch este puțin mai ușor de construit de la zero.

Pe de altă parte, este un lucru foarte puternic care vă permite să creați imagini pentru mașini virtuale, să le modificați, să le comprimați, să instalați grub, să modificați tabelul de partiții, să gestionați fișierele de configurare, să transferați mașini hardware într-un mediu virtual, să transferați mașini virtuale de la o imagine la alta, transferă mașini virtuale din imagine în hardware și, sincer să fiu, aici imaginația mă lasă puțin la pământ. Oh, da: puteți rula și un daemon în interiorul unei mașini virtuale Linux și să accesați datele mașinii virtuale live și să faceți toate acestea în shell, python, perl, java, ocaml. Aceasta este o listă scurtă și deloc exhaustivă a ceea ce puteți face cu .

Interesant este că cea mai mare parte a codului este generată în momentul asamblarii, precum și documentația pentru proiect. Ocaml și perl sunt utilizate pe scară largă. Codul în sine este scris în C, care este apoi împachetat în OCaml, iar bucățile repetate de cod sunt generate ele însele. Lucrul cu imagini se realizează prin lansarea unei imagini de serviciu speciale (aparatul supermin), către care sunt trimise comenzi printr-un canal în ea. Această imagine de salvare conține un anumit set de utilitare, cum ar fi parted, mkfs și altele utile pentru un administrator de sistem.

Recent am început chiar să-l folosesc acasă, când am extras datele de care aveam nevoie din imaginea nandroid. Dar acest lucru necesită un nucleu activat pentru yaffs.

Alte

Mai jos sunt câteva link-uri mai interesante către o descriere a software-ului utilizat - citiți și studiați-l singur dacă sunteți interesat. De exemplu,

Te-ai întrebat vreodată cum funcționează cloud-ul? Trece prin ea tendința IT cu cea mai rapidă creștere, în dezvoltarea căreia sunt investite miliarde de dolari anual proces tehnologic producție. Acest proces poate fi detaliat pe termen nelimitat, așa că vom lua în considerare doar etapa finală - virtualizarea, și anume produse software sau componente hardware cu ajutorul cărora se realizează virtualizarea.

Primul material din seria „Tehnologii VPS/VDS” este dedicat produsului software KVM (Kernel-based Virtual Machine). Începem cu el, deoarece este acest hipervizor pe care îl folosim în cloud-ul Tucha și, desigur, atitudinea noastră față de el este specială.

Hypervisor KVM: caracteristici și principiu de funcționare

Tehnologiile de virtualizare sunt din ce în ce mai utilizate în sisteme moderne. Mașinile virtuale sunt cea mai ușoară modalitate de a avea mai multe sisteme de operare diferite cu un mediu software însoțitor pentru efectuarea diferitelor sarcini - testare sau dezvoltare software, organizare găzduire folosind VPS, distribuire de produse digitale, instruire etc. Pentru a simplifica gestionarea mașinilor virtuale, se folosesc hipervizori - soluții software care vă permit să porniți, să opriți și să implementați rapid mașini virtuale noi într-o singură gazdă. Unul dintre cei mai populari hipervizori pentru sisteme asemănătoare UNIX este KVM.

Hypervisor KVM: arhitectură

KVM (abreviere pentru Kernel-based Virtual Machine) este un software care face posibilă implementarea virtualizării pe computere care rulează Linux și altele asemenea. De ceva timp, KVM face parte din nucleul Linux și, prin urmare, se dezvoltă odată cu acesta. Funcționează numai pe sisteme cu suport hardware pentru virtualizare - activat procesoare Intelși AMD.

Pentru a-și organiza activitatea, KVM folosește acces direct la nucleu folosind un modul specific procesorului (kvm-intel sau kvm-amd). În plus, complexul include nucleul principal - elemente kvm.ko și UI, inclusiv popularul QEMU. Hipervizorul vă permite să lucrați direct cu fișiere de mașină virtuală și imagini de disc din alte programe. Se creează un spațiu izolat pentru fiecare mașină cu propria memorie, disc, acces la retea, placă video și alte dispozitive.

Avantajele și dezavantajele KVM

Ca orice soluție software, KVM are atât avantaje, cât și dezavantaje, pe baza cărora hosterii și utilizatorii finali decid să folosească acest software.

Principalele avantaje ale hipervizorului sunt:

• resurse alocate independent. Fiecare lucrează sub control KVM virtual mașina primește propria sa cantitate de RAM și memorie permanentă și nu poate „urca” în alte zone, ceea ce crește stabilitatea;
• Suport larg pentru sistemele de operare invitate. Cu exceptia sprijin deplin Distribuțiile UNIX, inclusiv *BSD, Solaris, Linux, au capacitatea de a instala Windows și chiar MacOS;
• interacțiunea cu nucleul permite accesul direct la hardware stație de lucru asta face treaba Mai repede;
• sprijinul giganților pieței de software(RedHat Linux, HP, Intel, IBM) permite ca proiectul să se dezvolte rapid, acoperind un număr tot mai mare de hardware și sisteme de operare, inclusiv cele mai recente;
• administrare simplă– capacitatea de a controla de la distanță prin VNC și un număr mare de software și suplimente terțe.

Au existat și câteva dezavantaje:

• tinerețea relativă a hipervizorului (de exemplu, în comparație cu Xen) și, în consecință, creșterea explozivă duc la diverse probleme, în special atunci când adăugați suport pentru noi medii hardware și software;
• complexitatea setărilor, în special pentru un utilizator neexperimentat. Adevărat, majoritatea opțiunilor nu trebuie schimbate - sunt configurate optim din cutie.

Funcționalitatea și proprietățile hypervisorului

Complexul KVM se caracterizează prin următoarele proprietăți de bază: securitate, control convenabil memorie, depozitare sigură date, migrare live, performanță, scalabilitate și stabilitate.

Siguranță

În KVM, fiecare mașină este un proces Linux, deci este supusă automat politicilor de securitate standard, precum și izolării de alte procese. Suplimentele speciale (cum ar fi SELinux) adaugă și alte elemente de securitate - controlul accesului, criptarea etc.

Deoarece KVM face parte din nucleul Linux, hypervisorul moștenește instrumente puternice gestionarea memoriei. Pagini de memorie ale fiecărui proces, de ex. mașinile virtuale pot fi copiate și modificate rapid fără a compromite viteza. Cu suport pentru sisteme multiprocesor, KVM are capacitatea de a gestiona cantități mari de memorie. Generalizarea memoriei este, de asemenea, acceptată - combinarea paginilor identice și emiterea unei copii la mașină la cerere, precum și alte metode de optimizare.

Stocare a datelor

Pentru a stoca imaginile mașinii și datele acestora, KVM poate folosi orice suport suportat de sistemul de operare părinte - hard disk-uri, NAS, unități amovibile, inclusiv cele cu I/O multi-thread pentru a accelera munca. În plus, hypervisorul poate lucra cu distribuit sisteme de fișiere– de exemplu, GFS2. Unitățile KVM au propriul lor format unic care acceptă crearea de instantanee dinamice diferite niveluri, criptare și compresie.

O caracteristică importantă a KVM este suportul pentru migrarea live: mutarea mașinilor virtuale între diferite gazde fără a le opri. Pentru utilizatori, o astfel de migrare este complet invizibilă - mașina rămâne în funcțiune, performanța nu suferă, conexiunile la rețea sunt active. Desigur, este posibilă și migrarea prin conservare starea curenta mașini virtuale într-un instantaneu și implementare pe o altă gazdă.

Performanță și scalabilitate

Scalabilitatea și performanța complexului datorită integrării strânse cu Linux sunt complet moștenite de la acest sistem de operare. Astfel, hypervisorul suportă până la 16 procesoare (virtuale sau fizice) și până la 256 GB de RAM în fiecare mașină virtuală. Acest lucru permite folosirea hipervizorului chiar și pe sistemele cele mai puternic încărcate.

Stabilitate

Pachetul software este în mod constant îmbunătățit - dacă inițial a fost doar suportat Platforma Linux x86, apoi astăzi numărul diverse platforme există zeci de ele, inclusiv toate sistemele de operare pentru servere populare. În plus, puteți implementa cu ușurință o mașină virtuală cu un sistem de operare modificat, dacă este compatibil cu platforma părinte. Și datorită cooperării cu producătorii de software de top, hipervizorul KVM poate fi numit cel mai stabil și mai fiabil de pe piață.

Nota va fi utilă pentru oricine este interesat să folosească virtualizarea în munca sa. Soluția mea se poate califica pentru uz industrial și va fi utilă celor care doresc să reducă costurile hardware dacă au nevoie de o infrastructură extinsă de rețea. Unele soluții de la IBM, de exemplu, se bazează pe o opțiune similară. Dar aceste soluții sunt departe de a fi prietenoase cu bugetul și sunt solicitate doar în cazuri excepționale.
Așa că, într-o zi, am avut nevoie să reproduc acasă o infrastructură extinsă de rețea constând din diverse platforme software. Drumul a pornit de la VMWare Workstationși KVM s-a încheiat... De ce KVM și cum s-a întâmplat totul, citiți mai jos.

1. Puțină istorie sau cum a început totul.
În timp ce lucram la o bancă, am întâlnit direct virtualizarea. Era sistemul de operare AIX al IBM care rula pe mainframe. De la bun început, am fost uimit de puterea și flexibilitatea acestei abordări. Și când am avut nevoie să reproduc acasă o infrastructură software extinsă în scopuri de testare, am bazat imediat totul pe principiile virtualizării. Acest lucru a făcut posibil să se evite atât costuri semnificative pentru hardware, cât și să se potrivească totul foarte compact în ceea ce privește spațiul.
Cititorul ar trebui să rețină că există de fapt o mare varietate de instrumente de virtualizare. Fiecare dintre ele are propriile sale subtilități și nuanțe. Scopul meu este să vorbesc despre o opțiune cu care lucrez personal, descriind, dacă este posibil, deficiențele și caracteristicile celorlalți.
2. Alegerea mea se numește KVM (sau mașină virtuală bazată pe kernel).
Puteți citi mai multe despre această opțiune.
Dar este mai bine să prezentați totul în ordine. Voi începe cu condițiile de selecție și care dintre opțiunile pe care le cunosc nu îndeplinesc aceste condiții:
— sistemul principal trebuie să fie accesibil și puternic.

La capitolul hardware, am ales varianta AMD Phenom X4 9550 / Asus M3A78 / 2x2Gb DDR-II / 1x160Gb IDE + 2x1Tb SATA-II. Videoclipul de aici nu este deloc important, cu excepția faptului că în cazul unuia încorporat va trebui să țineți cont că preia o parte din memorie cu acces aleator, în consecință, va fi mai puțin pentru mașinile virtuale. Voi spune imediat că alegerea unei plăci de bază cu controler RAID încorporat nu a fost în întregime corectă. După cum sa dovedit, acest RAID funcționează numai în modul program, adică driverele sunt necesare pentru sistemele Windows, dar în Linux același efect ar putea fi obținut mult mai ușor folosind instrumente standard.
Utilizare platforma software pentru sistemul principal era clar în favoarea GNU/Linux, deoarece a făcut posibilă obținerea unui mediu de virtualizare fără costuri suplimentare de licențiere și, de asemenea, mai ușor în ceea ce privește încărcarea (nu voi înțelege niciodată de ce în Windows Server fara grafica nu poti pune in scena sau face nimic... sarcină fără rost, IMHO). Inițial a fost planificat să se utilizeze opțiunea Ubuntu Server Hardy LTS, dar aproape imediat s-a făcut o migrare către Debian Lenny (tocmai fusese lansată până la acea vreme).În niciun fel nu slăbesc demnitatea Ubuntu, ci subiectiv Debian este mai stabil si functioneaza mai repede.

— sistemul de virtualizare trebuie să fie stabil, accesibil publicului și să nu necesite resurse.

Alegerea este amețitoare, dar după ce am studiat recenziile de pe Internet și am încercat să o folosesc, mi-am format o părere subiectivă.
Produsele VMWare nu sunt potrivite. Stația de lucru este plătită, ESXi nu a putut fi instalat pe sistemul meu din cauza unui chipset neacceptat (s-a dovedit a fi mai modern). VMWare Server ar fi o alegere bună, dar judecând după recenzii, este puțin greu și se blochează periodic; eu însumi nu l-am încercat după eșecul cu ESXi. Nu s-au potrivit pentru încă un motiv - compania încă își vinde produsele și doar unele dintre ele sunt disponibile gratuit.
VirtualBox s-a dovedit a fi o opțiune foarte bună. Vine în două versiuni - OSE și Freeware. ÎN acces deschis Nu există surse pentru versiunea Freeware, dar o compensează în funcționalitate. Dintre diferențele cunoscute de mine, aceasta este absența în versiunea OSE Suport USB, restricții la lucrul cu rețeaua, accelerarea grafică nu este acceptată (apropo, dă o creștere foarte decentă a vitezei mașinii virtuale). VirtualBox este ideal pentru cea mai simplă implementare, deoarece vă permite să obțineți rapid o mașină virtuală funcțională, fără mișcări inutile și studiul atent al manualului. O caracteristică plăcută a fost suportul pentru lucrul din consolă, care vă permite să evitați utilizarea suplimentelor grafice și, în consecință, elimină sarcina suplimentară de pe mașina gazdă. Pentru „virtualizatori acasă” începători, aș recomanda această opțiune. Personal, încă îl folosesc laptop personal pentru configurarea rapidă a unui mediu de testare, precum și pentru lucrul în Windows (Ubuntu a fost stabilit de mult acolo ca sistem principal). Conform sentimentelor subiective, VirtualBox funcționează mult mai rapid decât VMWare Workstation și ocupă mai puțin spațiu atât pe disc, cât și în memorie. Pentru fiecare mașină este alocat fereastra separata, și, de asemenea, atunci când driverele sunt instalate în sistemul oaspete (disponibile din cutie), este posibil să le integrați în desktop-ul gazdă, ceea ce este foarte convenabil și vă permite să distribuiți sarcini pe diferite desktop-uri virtuale.
QEMU este un lucru foarte puternic. Dar când mi-am amintit despre asta, am acordat deja atenție virtualizării bazate pe kernel și informațiilor despre Xen și KVM, așa că nu m-am familiarizat îndeaproape cu QEMU pur.
Xen - sistem ideal pentru virtualizare. Dar are un dezavantaj foarte semnificativ - sistemul de invitați trebuie pregătit în avans.
KVM, bazat pe QEMU, este aproape la fel de rapid ca Xen, dar are o funcționalitate mai flexibilă și toată puterea setărilor QEMU (deși cea mai mare parte a ceea ce aveam nevoie era în VirtualBOX). Ambele opțiuni, Xen și KVM, sunt implementate în toate distribuțiile moderne și nu necesită niciun efort serios pentru utilizare. Dar există o diferență fundamentală între ele, care va fi discutată în continuare.

— este necesar să se poată reproduce diverse platforme software pe mașini virtuale.

În ciuda disponibilității produselor VMWare și VirtualBOX în acest sens, am refuzat să le folosesc și mai devreme, așa că nu le voi lua în considerare... Dar în legătură cu Xen și KVM voi descrie puțin mai detaliat, deoarece Am căutat și eu informații de foarte mult timp.
Xen nu vă permite să rulați alte sisteme decât cel gazdă!!!, sau mai degrabă pe cele care nu sunt pregătite în prealabil pentru a lucra mediu virtual. Și din păcate (sau poate din fericire), nu pot fi procesate în acest fel distribuții Windows. Ceea ce nu mi s-a potrivit, pentru că până la urmă alegerea a căzut pe opțiunea de a folosi KVM, pentru care a trebuit să mă pregătesc din timp sistem invitat Nu este nevoie.

Deci, motivele pentru care alegeți KVM pe scurt:

1. Implementarea este disponibilă de la cutie în orice distribuție mare;
2. Implementat pe baza nucleului Linux, prin urmare are viteză mare;
3. Folosit de giganți precum RedHat și Ubuntu, ceea ce indică stabilitate și flexibilitate ridicate;
4. Nu sunt necesare manipulări suplimentare cu sistemul oaspete pentru instalarea într-o mașină virtuală.

3. Cum am făcut-o pe Debian.
Urmează o descriere mai tehnică, care descrie pas cu pas cum mi-am creat serverul, care poate gestiona cu ușurință o duzină de servere virtuale.
În ciuda faptului că distribuția mea preferată este Ubuntu, în cele din urmă sub sistem de bază Debian a fost ales. În cadrul articolului nu voi explica subtilitățile, ce și cum, dar pe desktop încă prefer să folosesc Ubuntu. Majoritatea instrucțiunilor pentru Ubuntu și Debian sunt relevante pentru ambele opțiuni, așa că la configurare le-am folosit pe ambele.
Deci, să începem configurarea serverului.
Să luăm distribuția Debian. Pentru a nu descărca prea mult mai târziu și a obține imediat un sistem proaspăt, am luat opțiunea netinstall, cu care am instalat doar „ Sistem standard„Nu avem nevoie de mai mult. Apropo, folosesc ediția pe 64 de biți pentru a obține suport pentru mai multă memorie RAM (>3 GB) fără soluții și trucuri (de exemplu, un nucleu de server pe 32 de biți). Distribuție Ubuntu acceptă mai mult de 3 GB, dar numai dacă această capacitate este disponibilă în chipset).
Folosesc un hard disk IDE pentru partițiile de sistem („/”, „/home”, swap) pentru a nu avea probleme cu sistemul atunci când este instalat pe o matrice RAID (și sunt unele). În timpul instalării, creez imediat un RAID-1 bazat pe două hard disk-uri SATA pentru a obține o mai mare siguranță a datelor (informațiile principale vor fi stocate pe acesta). În viitor, pentru a lucra cu o matrice software RAID, ar trebui să utilizați utilitarul mdadm.
Retușez puțin sistemul nou instalat. În primul rând, instalez ssh, astfel încât să pot pune imediat deoparte unitatea de sistem și să deconectați monitorul care nu mai este necesar de la ea: sudo apt-get install ssh Mulți oameni recomandă comutarea portului de la standardul 22 la altul. Dar acest lucru ar trebui făcut numai dacă aveți încredere în acțiunile dvs. și serverul dvs. este conectat direct la Internet. Apropo, trebuie menționat că dacă este folosit Nu port standard, atunci vor apărea dificultăți cu telecomandă Virtualizare KVM. Prin urmare, am părăsit portul standard, dar prin routerul hardware l-am redirecționat către unul non-standard, accesibil din exterior.

Apoi activăm sincronizarea orei prin Internet (recomand cu căldură, va fi la îndemână).
sudo apt-get install ntp ntpdate
Pentru a monitoriza temperatura chipset-urilor, procesorului și hard disk-urilor:
sudo apt-get install lm-sensors hddtemp
Utilitarul hddtemp funcționează imediat, pentru a configura lm-senzorii pe care îi rulăm după instalare: sudo sensors-detecta și răspunde afirmativ la toate întrebările.
Este foarte usor de folosit:
— aflați temperatura procesorului, chipset-ului și a altor caracteristici ale senzorilor sudo, obținem ceva de genul:

it8712-isa-0290
Adaptor: adaptor ISA
VCore 1: +1,33 V (min = +3,54 V, max = +3,30 V) ALARMĂ
VCore 2: +3,76 V (min = +1,39 V, max = +1,01 V) ALARMĂ
+3,3 V: +3,28 V (min = +4,00 V, max = +0,91 V) ALARMĂ
+5V: +6,69 V (min = +3,04 V, max = +6,10 V) ALARMĂ
+12V: +12,67 V (min = +15,23 V, max = +5,57 V) ALARMĂ
-12V: -15,33 V (min = -0,85 V, max = -12,39 V) ALARMĂ
-5V: +2,85 V (min = +3,06 V, max = +3,47 V) ALARMĂ
Stdby: +5,99 V (min = +0,11 V, max = +6,37 V)
VBat: +3,31 V
ventilator1: 2922 RPM (min = 3260 RPM, div = 2)
ventilator2: 0 RPM (min = 5400 RPM, div = 2) ALARMĂ
fan3: 0 RPM (min = 2732 RPM, div = 2) ALARMĂ
M/B Temp: +44,0°C (scăzut = -73,0°C, ridicat = -49,0°C) senzor = tranzistor
Temperatura procesorului: +32,0 °C (scăzută = -65,0 °C, ridicată = -9,0 °C) senzor = tranzistor
Temp3: +128,0°C (scăzut = +23,0°C, ridicat = -66,0°C) senzor = dezactivat
cpu0_vid: +0.000 V

— aflați temperatura de 1 hard unitate SATA- sudo hddtemp /dev/sda obținem ceva de genul:

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

Pentru lucrări suplimentare, vă recomand să obțineți un server DHCP terț și să configurați o interfață bridge pe serverul nostru de virtualizare.
Hai să instalăm utilitatile necesare: sudo apt-get install bridge-utils
Îmi folosesc routerul ca server DHCP și am creat interfața bridge conform instrucțiunilor. Aceleași instrucțiuni vă spun cum să creați o mașină virtuală KVM în mod implicit utilizând această metodă de conectare. Pentru a accelera repornirea (nu este deloc o situație critică dacă serverul este pe 24/7), vă sfătuiesc să specificați în prealabil o adresă statică pentru interfață, chiar dacă DHCP este disponibil.

Și cea mai bună parte este instalarea modulelor KVM și a utilităților utile. Îl vom adăuga imediat utilizator curent la grupul corespunzător pentru disponibilitatea utilizării KVM. O descriere a modului de utilizare a utilităților poate fi găsită în manualele deja menționate. sudo aptitude install kvm libvirt-bin virtinst virt-top python-virtinst
sudo adduser softovick libvirt De fapt, îl puteți folosi imediat. Nu văd niciun rost să descriu toate comenzile; există o pagină de manual pentru asta. Dar vă voi arăta cum creez o mașină virtuală:
pentru 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 =generic26
pentru 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 După aceasta, progresul în continuare al instalării și ecranul mașinii invitate pot fi controlate prin conectarea utilizând un client VNC la serverul de pe porturile 5900 și 5901 (recomand să definiți în prealabil portul VNC pentru fiecare mașină astfel încât să fie convenabil să se conecteze). Există mai multe alte opțiuni utile, nu le folosesc doar pentru că nu am întâmpinat nevoia de ele.

Și încă o atingere, dar nu ultima. Încă nu mi-am dat seama cum să mă conectez la sistemul oaspete abilitatea de a scrie ceva direct într-o partiție fizică sau într-un folder din raid, deși am încercat. Prin urmare, în cazul Linux, mă conectez la datele de pe server folosind nfs, iar în cazul Windows, folosind Samba. Configurarea Samba este destul de banală, instalează sudo aptitude instalează samba și editează Fișier de configurare/etc/samba/smb.conf pentru sarcinile dvs. Și aici este instalarea configurarea nfs nu cu totul banal. Folosesc această opțiune de instalare, care îmi permite să mă conectez la folderele necesare de la orice adresă IP a rețelei locale (tip 192.168.10.*): sudo aptitude install nfs-kernel-server portmap
perl -pi -e "s/^OPTIONS/#OPTIONS/" /etc/default/portmap
echo "portmap: 192.168.10." >> /etc/hosts.allow
/etc/init.d/portmap restart
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 reîncărcare
După pașii de mai sus, este suficient să faceți acest lucru pe sistemul invitat:
sudo mount server:/media/raid local_folder
Dacă este necesar, puteți activa montaj automat la încărcare, corectând fișierul de configurare /etc/fstab, adăugând o linie ca:
virtual:/media/raid /media/raid nfs defaults 0 2
Ei bine, în general, configurarea serverului nostru de virtualizare este completă. Îl poți gestiona atât în ​​consolă, cât și folosind instrumente grafice virsh sau virtual manager.

P.S.:
Câteva sfaturi utile:
1. Dacă ați indicat port specific VNC pentru mașina oaspete, apoi prin Virtual Manager nu veți putea lansa automat consola grafică.
2. Virtual Manager nu se va putea conecta dacă ați suprascris port ssh. Mai exact, acest lucru va necesita o înțelegere lungă și plictisitoare.
3. Asigurați-vă că îl utilizați pentru Windows pentru invitați Modul server-noacpi ca sa se instaleze normal.
4. Configurați cu atenție modul de economisire a energiei pe sistemele oaspeților; în niciun caz nu opriți ecranul, altfel nu vă veți putea conecta prin VNC mai târziu.
5. Dacă doriți să închideți și să reporniți de la distanță mașinile prin Virtual Manager, atunci dezactivați economizorul de ecran, deoarece blochează gestionarea energiei.

Să presupunem că ești un student tânăr, dar încă sărac, ceea ce înseamnă că dintre toate platformele posibile ai doar un PC pe Windows și PS4. Într-o bună zi, te hotărăști să-ți revii în fire și să devii programator, dar oamenii înțelepți de pe Internet ți-au spus că nu poți deveni un inginer normal fără Linux. Nu puteți instala Fedora ca sistem principal și unic, deoarece Windows este încă necesar pentru jocuri și VKontakte, dar instalați Linux al doilea sistem pornit HDD esti impiedicat de frica sau de lipsa de experienta.

Sau, să spunem, ai crescut deja, acum ești șeful serverelor în companie mare, și într-o bună zi ai observat că majoritatea serverelor nu sunt nici măcar încărcate pe jumătate. Nu puteți plasa mai multe aplicații și date pe servere din motive de securitate, iar costurile suportării și întreținerii unei ferme de servere în creștere cresc rapid.

Sau, să zicem, ai deja barbă și ochelari, tu Director tehnic, și nu sunteți mulțumit de ceea ce obțin dezvoltatorii pentru a implementa o nouă aplicație server nou trebuie sa astepti doua luni. Cum să avansezi rapid în astfel de condiții?

Sau poate ești un arhitect care a proiectat un nou sistem complex de procesare a analizei de afaceri. Sistemul dvs. include lucruri precum ElasticSearch, Kafka, Spark și multe altele, iar fiecare componentă trebuie să trăiască separat, să fie configurată inteligent și să comunice cu alte componente. Ca un bun inginer, înțelegeți că nu este suficient să instalați pur și simplu toată această grădină zoologică direct pe sistemul dumneavoastră. Trebuie să încercați să implementați un mediu cât mai aproape posibil de viitorul mediu de producție și, de preferință, astfel încât dezvoltările dvs. să funcționeze apoi fără probleme pe serverele de producție.

Și ce să faci în toate aceste situații dificile? Corect: utilizați virtualizarea.

Virtualizarea vă permite să instalați multe sisteme de operare complet izolate unele de altele și care rulează unul lângă altul pe același hardware.

Puțină istorie. Primele tehnologii de virtualizare au apărut deja în anii 60, dar nevoia reală pentru ele a apărut abia în anii 90, pe măsură ce numărul de servere creștea din ce în ce mai mult. Atunci a apărut problema reciclării efective a întregului hardware, precum și optimizarea proceselor de actualizare, implementare a aplicațiilor, asigurare a securității și restaurare a sistemelor în caz de dezastru.

Să lăsăm în culise istoria lungă și dureroasă a dezvoltării diverselor tehnologii și metode de virtualizare - pentru cititorul curios la sfârșitul articolului va exista Materiale suplimentare despre această temă. Important este la ce a ajuns totul în cele din urmă: trei abordări principale ale virtualizării.

Abordări ale virtualizării

Indiferent de abordare și tehnologie, atunci când se utilizează virtualizarea există întotdeauna o mașină gazdă și un hypervisor instalat pe ea care controlează mașinile invitate.

În funcție de tehnologia utilizată, un hypervisor poate fi fie un software separat instalat direct pe hardware, fie o parte a sistemului de operare.

Un cititor atent care iubește cuvintele la modă va începe să mormăie în câteva paragrafe că containerele sale preferate Docker sunt considerate și virtualizare. Despre tehnologiile containerului vom vorbi altădată, dar da, ai dreptate, cititor atent, containerele sunt și ele un fel de virtualizare, doar la nivelul resurselor aceluiași sistem de operare.

Există trei moduri prin care mașinile virtuale pot interacționa cu hardware-ul:

Difuzare dinamică

În acest caz, mașinile virtuale nu au idee că sunt virtuale. Hipervizorul interceptează din mers toate comenzile de la mașina virtuală și le procesează, înlocuindu-le cu altele sigure, apoi le readuce înapoi la mașina virtuală. Această abordare suferă în mod evident de unele probleme de performanță, dar vă permite să virtualizați orice sistem de operare, deoarece sistemul de operare invitat nu trebuie modificat. Traducerea dinamică este utilizată în produse VMWare- lider în software de virtualizare comercială.

Paravirtualizarea

În cazul paravirtualizării, codul sursă al sistemului de operare invitat este modificat în mod specific, astfel încât toate instrucțiunile să fie executate cât mai eficient și sigur posibil. În același timp, femeia virtuală este întotdeauna conștientă că este o femeie virtuală. Unul dintre beneficii este performanța îmbunătățită. Dezavantajul este că astfel nu poți virtualiza, de exemplu, MacOS sau Windows, sau orice alt sistem de operare la care nu ai acces la codul sursă. Paravirtualizarea într-o formă sau alta este utilizată, de exemplu, în Xen și KVM.

Virtualizare hardware

Dezvoltatorii de procesoare și-au dat seama la timp că arhitectura x86 este prost potrivită pentru virtualizare, deoarece a fost proiectată inițial pentru un sistem de operare la un moment dat. Prin urmare, după ce a apărut traducerea dinamică din VMWare și paravirtualizarea de la Xen, Intel și AMD au început să lanseze procesoare cu suport hardware pentru virtualizare.

La început, acest lucru nu a oferit o creștere a performanței, deoarece obiectivul principal al primelor versiuni a fost îmbunătățirea arhitecturii procesorului. Cu toate acestea, acum, la mai bine de 10 ani de la apariția Intel VT-x și AMD-V, virtualizarea hardware nu este sub nicio formă inferioară și chiar în anumite privințe superioară altor soluții.

Virtualizarea hardware folosește și necesită KVM (Mașină virtuală bazată pe kernel), pe care o vom folosi în viitor.

Mașină virtuală bazată pe kernel

KVM este o soluție de virtualizare integrată chiar în kernel-ul Linux, care este la fel de funcțională ca și alte soluții și superioară în utilizare. Mai mult, KVM este o tehnologie open source, care, cu toate acestea, avansează cu viteză maximă (atât în ​​ceea ce privește scrierea codului, cât și în ceea ce privește marketingul) și este implementată în produsele sale de către Red Hat.

Acesta, apropo, este unul dintre numeroasele motive pentru care insistăm asupra distribuțiilor Red Hat.

Creatorii KVM s-au concentrat inițial pe sprijinirea virtualizării hardware și nu au reinventat multe lucruri. Un hypervisor, în esență, este un mic sistem de operare care trebuie să poată funcționa cu memorie, rețea etc. Linux este deja foarte bun la toate acestea, așa că folosirea nucleului Linux ca hypervisor este o soluție tehnică logică și frumoasă. Fiecare virtual aparat KVM- este doar separat Procesul Linux, securitatea este asigurată folosind SELinux/sVirt, resursele sunt gestionate folosind CGroups.

Vom vorbi mai multe despre SELinux și CGroups într-un alt articol, nu vă alarmați dacă nu cunoașteți aceste cuvinte.

KVM nu funcționează doar ca parte a nucleului Linux: de la versiunea 2.6.20 a nucleului, KVM a fost o componentă de bază a Linux. Cu alte cuvinte, dacă aveți Linux, atunci aveți deja KVM. Convenabil, nu?

Merită spus că în domeniul platformelor de cloud public, Xen domină puțin mai mult decât complet. De exemplu, AWS EC2 și Rackspace folosesc Xen. Acest lucru se datorează faptului că Xen a apărut mai devreme decât toți ceilalți și a fost primul care a atins un nivel suficient de performanță. Dar există și Vești bune: în noiembrie 2017, care va înlocui treptat Xen pentru cel mai mare furnizor de cloud.

Deși KVM utilizează virtualizarea hardware, pentru unele drivere de dispozitiv I/O KVM poate utiliza paravirtualizarea, care oferă câștiguri de performanță pentru anumite cazuri de utilizare.

libvirt

Aproape am ajuns la partea practică a articolului, tot ce rămâne este să luăm în considerare un alt instrument open source: libvirt.

libvirt este un set de instrumente care oferă un singur API pentru multe tehnologii de virtualizare diferite. Folosind libvirt, în principiu, nu contează care este „backend”-ul: Xen, KVM, VirtualBox sau orice altceva. Mai mult, puteți utiliza libvirt în cadrul programelor Ruby (și, de asemenea, Python, C++ și multe altele). De asemenea, vă puteți conecta la mașini virtuale de la distanță prin canale securizate.

Apropo, libvirt este dezvoltat de Red Hat. Ați instalat deja Stația de lucru Fedora sistemul principal?

Să creăm o mașină virtuală

libvirt este doar un API, dar depinde de utilizator cum să interacționeze cu el. Există o mulțime de opțiuni. Vom folosi mai multe utilități standard. Vă reamintim: insistăm să folosim distribuțiile Red Hat (CentOS, Fedora, RHEL) și comenzile de mai jos au fost testate pe unul dintre aceste sisteme. Pentru ceilalti distribuții Linux pot apărea mici diferențe.

Mai întâi, să verificăm dacă virtualizarea hardware este acceptată. De fapt, va funcționa fără suportul său, doar mult mai lent.

egrep --color = auto "vmx|svm|0xc0f" /proc/cpuinfo # dacă nu este afișat nimic, atunci nu există suport :(

Deoarece KVM este un modul kernel Linux, trebuie să verificați dacă este deja încărcat și, dacă nu, atunci încărcați-l.

lsmod | grep kvm # kvm, kvm_intel, kvm_amd. Dacă nu apare nimic, atunci trebuie să descărcați modulele necesare # Dacă modulul nu este încărcat modprobe kvm modprobe kvm_intel # sau modprobe kvm_amd

Este posibil ca virtualizarea hardware să fie dezactivată în BIOS. Prin urmare, dacă modulele kvm_intel/kvm_amd nu sunt încărcate, atunci verificați setările BIOS.

Acum hai să instalăm pachetele necesare. Cel mai simplu mod de a face acest lucru este să instalați un grup de pachete simultan:

lista grupului yum „Virtual*”

Lista de grupuri depinde de sistemul de operare utilizat. Grupul meu a fost sunat Virtualizare. Pentru a gestiona mașinile virtuale din linia de comandă, utilizați utilitarul virsh. Verificați dacă aveți cel puțin o mașină virtuală folosind comanda virsh list. Cel mai probabil nu.

Dacă nu vă place linia de comandă, atunci există și virt-manager - o interfață grafică foarte convenabilă pentru mașinile virtuale.

virsh poate crea mașini virtuale numai din fișiere XML, al căror format poate fi studiat în documentația libvirt. Din fericire, există și virt-manager și comanda virt-install. Vă puteți da seama singur de GUI, dar iată un exemplu de utilizare a 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

În loc să specificați dimensiunea discului, o puteți crea în avans prin virt-manager sau prin virsh și un fișier XML. Am folosit imaginea de mai sus de la Centos 7 minimal, care este ușor de găsit pe site-ul Centos.

Acum rămâne o întrebare importantă: cum să vă conectați la mașina creată? Cel mai simplu mod de a face acest lucru este prin virt-manager - doar faceți dublu clic pe mașina creată și se va deschide o fereastră cu o conexiune SPICE. Ecranul de instalare a sistemului de operare vă așteaptă acolo.

Apropo, KVM poate imbrica virtualizare: mașini virtuale în interiorul unei mașini virtuale. Trebuie să mergem mai adânc!

După ce instalați manual sistemul de operare, vă veți întreba imediat cum poate fi automatizat acest proces. Pentru a face acest lucru, avem nevoie de un utilitar numit Kickstart, conceput pentru a configura automat sistemul de operare pentru prima dată. Acesta este un fișier text simplu în care puteți specifica configurația sistemului de operare, până la diferite scripturi care sunt executate după instalare.

Dar de unde pot obține un astfel de fișier? De ce să nu o scrii de la zero? Desigur că nu: deoarece am instalat deja Centos 7 în interiorul mașinii noastre virtuale, trebuie doar să ne conectăm la el și să găsim fișierul /root/anaconda-ks.cfg - aceasta este configurația Kickstart pentru a crea o copie a fișierului deja OS creat. Trebuie doar să îl copiați și să editați conținutul.

Dar doar copierea unui fișier este plictisitoare, așa că îi vom adăuga altceva. Faptul este că implicit nu ne vom putea conecta la consola mașinii virtuale create din linia de comandă a mașinii gazdă. Pentru a face acest lucru, trebuie să editați configurația bootloader-ului GRUB. Prin urmare, la sfârșitul fișierului Kickstart vom adăuga următoarea secțiune:

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

După cum ați putea ghici, %post va fi executat după instalarea sistemului de operare. Comanda grubby va actualiza configurația GRUB pentru a adăuga capacitatea de conectare la consolă.

Apropo, puteți specifica și capacitatea de a vă conecta prin consolă chiar în timpul creării mașinii virtuale. Pentru a face acest lucru, trebuie să transmiteți încă un argument la comanda virt-install: --extra-args="console=ttyS0" . După aceasta, puteți instala sistemul de operare în sine în modul text interactiv de la terminalul mașinii dvs. gazdă, conectându-vă la mașina virtuală prin consola virsh imediat după crearea acesteia. Acest lucru este convenabil în special atunci când creați mașini virtuale pe un server hardware la distanță.

Acum puteți aplica configurația creată! virt-install vă permite să transmiteți argumente suplimentare atunci când creați o mașină virtuală, inclusiv calea către fișierul Kickstart.

sudo virt-install --name mkdev-vm-1 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --initrd-inject /path/to/ks.cfg \ --extra- args ks = fișier:/ks.cfg \ --memory = 1024 --vcpus = 1 --dimensiune disc = 8

După ce a doua mașină virtuală este creată (complet automat), vă puteți conecta la ea din linia de comandă folosind comanda virsh console vm_id. vm_id Puteți afla din lista tuturor mașinilor virtuale folosind comanda virsh list.

Unul dintre avantajele utilizării KVM/libvirt este documentația uimitoare, inclusiv cea produsă de Red Hat. Dragul cititor este invitat să-l studieze cu curiozitatea cuvenită.

Desigur, crearea de mașini virtuale ca aceasta cu mâinile în consolă și apoi configurarea lor numai folosind Kickstart nu este cea mai bună proces convenabil. În articolele viitoare, ne vom uita la multe instrumente interesante care fac configurarea sistemului mai ușoară și complet automatizată.

Ce urmeaza?

Este imposibil să încadrezi într-un singur articol tot ceea ce merită să știi despre virtualizare. Am analizat mai multe opțiuni de utilizare a virtualizării și avantajele acesteia, am aprofundat puțin mai mult în detaliile funcționării acesteia și ne-am familiarizat cu cea mai bună soluție, în opinia noastră, pentru aceste sarcini (KVM) și chiar am creat și configurat o mașină virtuală.

Este important să înțelegem că mașinile virtuale sunt elementele de bază ale arhitecturii moderne de cloud. Acestea permit aplicațiilor să crească automat la dimensiuni nelimitate, maximizând într-un mod rapidși cu utilizarea maximă a tuturor resurselor.

Indiferent cât de puternic și de bogat în servicii este AWS, fundația sa sunt mașinile virtuale pe deasupra Xen. De fiecare dată când creați o picătură nouă pe DigitalOcean, creați o mașină virtuală. Aproape toate site-urile pe care le utilizați sunt găzduite pe mașini virtuale. Simplitatea și flexibilitatea mașinilor virtuale permit nu numai construirea de sisteme de producție, dar și dezvoltarea locală și testarea de zece ori mai ușoară, mai ales când sistemul implică multe componente.

Am învățat cum să creăm o singură mașină - nu e rău pentru a testa o aplicație. Dar dacă avem nevoie de mai multe mașini virtuale simultan? Cum vor comunica între ei? Cum se vor găsi unul pe altul? Pentru a face acest lucru, va trebui să înțelegem cum funcționează în general rețelele, cum funcționează în contextul virtualizării și ce componente sunt implicate în această activitate și trebuie configurate - în următorul articol din serie.