| Xen | |
|---|---|
| Xen rulează NetBSD și trei distribuții Linux | |
| Tip de | Server de virtualizare |
| Dezvoltator | Proiectul Xen, XenSource, Inc. |
| Scris in | C [1] |
| Sistem de operare | Linux , OpenSolaris , BSD |
| Prima editie | 2003 |
| ultima versiune |
|
| Licență | GNU GPL 2 [3] |
| Site-ul web | xenproject.org |
| Fișiere media la Wikimedia Commons | |
Xen (pron. / ˈzɛn / ) este un hypervisor multiplatform dezvoltat la Universitatea din Cambridge Computer Lab și licențiat sub GPL . Caracteristici principale: suport pentru modul de paravirtualizare pe lângă virtualizarea hardware, codul minim al hypervisorului în sine datorită eliminării numărului maxim de componente din afara hipervizorului.
Xen a început ca un proiect de cercetare la Universitatea din Cambridge condus de Ian Pratt , care a devenit ulterior fondatorul XenSource. Compania a sprijinit dezvoltarea unei versiuni open source (xen) și a vândut simultan versiuni comerciale ale software-ului numit XenServer și XenEnterprise.
Prima lansare publică a Xen a fost în 2003. În octombrie 2007 , Citrix a cumpărat XenSource și a rebrandat produsele:
Ulterior, au fost redenumite XenServer (gratuit), Essentials pentru XenServer Enterprise și Essentials pentru XenServer Platinum.
Pe 22 octombrie 2007, Citrix și-a finalizat preluarea XenSource [4] și proiectul gratuit a fost mutat pe xen.org.
Pe 21 octombrie 2009, Citrix a anunțat că versiunile comerciale ale XenServer vor deveni complet gratuite [5] . Simon Crosby , inginer principal pentru divizia de virtualizare Citrix, a declarat: „XenServer este 100% gratuit și va fi complet open source în curând. Nu intenționăm să facem deloc profit [din asta]” [6] ). Deși există o versiune gratuită a Citrix XenServer, XenCenter (software de management centralizat) nu este codificat sursă, deși este disponibil pentru descărcare gratuită.
15 aprilie 2013 Xen a intrat sub aripa Fundației Linux [1] Arhivat 19 aprilie 2013 la Wayback Machine
| Versiune | Data de lansare | Note |
|---|---|---|
| 1.0 | 2003.10.02 [7] [8] | |
| 2.0 | 05.11.2004 [9] | Migrare live pentru mașinile invitate paravirtuale |
| 3.0 | 05.12.2005 [10] [11] |
Versiunea 3.0.4 a adăugat și:
|
| 3.1 | 18.05.2007 [15] | Migrare live pentru oaspeții HVM, suport XenAPI |
| 3.2 | 17.01.2008 [16] | „Redirecționare” PCI, modul „sleep” ACPI S3. |
| 3.3 | 24.08.2008 [17] | Îmbunătățiri ale redirecționării PCI și gestionării energiei. |
| 3.4 | 18.05.2009 [18] | Conține prima versiune a „Xen Client Initiative” (XCI). |
| 4.0 | 07.04.2010 [19] | Permite utilizarea nucleelor Linux ca dom0 folosind noul mecanism PVOps. [douăzeci] |
| 4.1 | 25.03.2011 [21] | Suport pentru mai mult de 255 de procesoare, stabilitate îmbunătățită.( [22] ). |
| 4.2 | 17.09.2012 [23] | Suport pentru 4095 procesoare fizice (și până la 512 virtuale), suport pentru mai multe segmente PCI, securitate și documentare îmbunătățite.( [24] ). |
| 4.3 | 09.07.2013 [25] | Suport experimental pentru ARM. Contabilizarea caracteristicilor arhitecturii NUMA în planificator. Deschideți suportul vSwitch . |
| 4.4 | 2014.03.10 [26] | Suportul ARM este acum stabil. Suport pentru libxl de către biblioteca libvirt. Nouă interfață scalabilă pentru canalele de evenimente. Suport pentru crearea de medii virtuale imbricate pe hardware Intel. S-a eliminat suportul pentru hipervizoarele x86 pe 32 de biți și ia64 (itanium). |
| 4.5 | 15.01.2015 [27] | Toolstack este acum rescris în C și numit xl sau libxl, înlocuind complet vechiul toolstack xend care a fost scris în python. |
| 4.6 | 13.10.2015 [28] | |
| 4.7 | 24.06.2016 [29] | Îmbunătățiri: securitate, migrare live, performanță și volum de lucru. Suport hardware (ARM și Intel Xeon). [treizeci] |
| 4.8.1 | 12.04.2017 [31] | |
| 4.9 | 28.07.2017 [32] | Note de lansare a proiectului Xen 4.9 |
| 4.10 | 12.12.2017 [33] | Note de lansare a proiectului Xen 4.10 |
| 4.11 | 10.07.2018 [34] | Note de lansare a proiectului Xen 4.11 |
| 4.12 | 2019.04.02 [35] | Note de lansare a proiectului Xen 4.12 |
Tehnologia mașinilor virtuale vă permite să extindeți funcționalitatea echipamentului în următoarele moduri:
Conceptul de bază al unui hypervisor este un domeniu . O copie care rulează a unei mașini virtuale se numește domeniu. Dacă mașina virtuală este repornită, atunci domeniul său este terminat (în momentul repornirii) și apare un nou domeniu. Mai mult, chiar și în timpul migrării, conținutul este copiat dintr-un domeniu în altul. Astfel, pe parcursul vieții, aproape toate mașinile virtuale se regăsesc la rândul lor în domenii diferite. Xen operează doar cu conceptul de domeniu, iar la nivel de administrare apare conceptul de „mașină virtuală” (programe de aplicație care controlează hypervisorul).
Domeniile sunt de mai multe tipuri. Cele mai cunoscute sunt dom0 și domU . dom0 este primul domeniu Xen lansat, de obicei este creat și încărcat automat imediat după ce hypervisor-ul este încărcat și inițializat. Acest domeniu are drepturi speciale pentru a controla hypervisorul și, implicit, tot hardware-ul computerului este accesibil din dom0. De fapt, dom0 este locul unde trăiește software-ul care gestionează Xen. dom0 este mereu singur.
domU este un domeniu membru (prescurtare de la User domain) care conține domeniul mașinilor virtuale care rulează. De obicei, nu are acces la hardware real și este „sarcina utilă” a sistemului de virtualizare. Spre deosebire de dom0, domU poate fi multe (de obicei câteva zeci).
stub-domain - un domeniu care rulează un sistem de operare foarte specializat care oferă lucru cu orice hardware sau driver back-end. Este o evoluție a modelului de securitate Xen.
domain builder (domain constructor) - un program care creează domU (încarcă codul necesar în el și îi spune hypervisorului să ruleze). Pe lângă construirea domeniului, el se ocupă de obicei cu conectarea și configurarea dispozitivelor virtuale disponibile mașinii virtuale. Ea este, de asemenea, responsabilă pentru procesul de migrare a unei mașini virtuale de la gazdă la gazdă.
Paravirtualizarea este adaptarea nucleului unui sistem de operare executabil pentru a funcționa împreună cu Xen, de obicei scurtat la PV. Vă permite să obțineți performanțe foarte înalte datorită lipsei de emulare a „hardware-ului real”, simplității interfețelor și luând în considerare existența unui hypervisor la executarea apelurilor de sistem în codul kernelului. Executarea operațiunilor privilegiate este interzisă, în locul acestora se fac hypercalls ( de exemplu hypercalls ) - solicitări de la kernel-ul OS invitat către hypervisor cu o solicitare de a efectua anumite operațiuni. În cele mai multe cazuri, modificările la portarea unui sistem de operare pe Xen afectează numai nucleul sistemului de operare, deși pot implica modificări minore în bibliotecile de sistem (de exemplu, libc). Procesul de adaptare la Xen este foarte asemănător cu portarea pentru o nouă platformă, dar este mult mai simplu datorită ușurinței de implementare a părții „oaspete” a driverului (driverele din Xen constau din două părți - una este executată în afara mașină virtuală, a doua se află în interiorul acesteia. Partea driverului din sistemul oaspete este extrem de primitivă și servește doar ca traducător de interogări pentru a doua parte (acest lucru a fost făcut intenționat pentru a ușura portarea sistemului de operare pe Xen). Modul PV nu acceptă moduri de procesor „imbricate”, cum ar fi real-86, virtual-86, comutarea între modul pe 32 de biți și 64 de biți, suport pentru emularea virtualizării hardware etc. În acest sens, modul PV-, există nici un fragment inițial al pornirii computerului (cu imitarea codului BIOS, bootloader etc.), iar nucleul sistemului oaspete pornește imediat în modul dorit, la fel cum încep programele obișnuite. În acest sens, în special, Xen în sine nu poate rula în modul PV (adică este imposibil să rulați un hipervizor „imbricat” în modul PV).
În modul de virtualizare hardware (HVM), sistemul de operare invitat nu „știe” despre existența hipervizorului. Xen, folosind module de la QEMU , emulează hardware-ul real și vă permite să porniți sistemul de operare. La sfârșitul acestuia, pentru performanțe normale, ar trebui să fie lansate drivere PV care implementează o interfață rapidă cu dispozitive virtuale, similar cu modul în care funcționează în modul PV. Deoarece majoritatea operațiunilor privilegiate sunt emulate, este posibil să rulați Xen în modul HVM de sub Xen. În acest caz, hypervisorul imbricat poate funcționa numai în modul PV.
Hypervisorul Xen (pentru versiunea 3.4) implementează un set minim de operațiuni pentru gestionarea memoriei principale, a stării procesorului, a temporizatoarelor în timp real a procesorului și a contoarelor de ceas (TSC), a întreruperilor și a controlului DMA. Toate celelalte funcții, cum ar fi implementarea dispozitivelor de disc și bloc, crearea și eliminarea mașinilor virtuale, migrarea acestora între servere etc., sunt implementate în domeniul de control. Din acest motiv, dimensiunea hipervizorului este foarte mică (pentru versiunea 3.4, dimensiunea codului binar al întregului hypervisor este mai mică de 600 KB), precum și dimensiunea codului sursă. Conform intenției autorilor, acest lucru crește stabilitatea sistemului de virtualizare, deoarece o eroare în componentele din afara hypervisorului nu duce la compromisul/deteriorarea hipervizorului în sine și limitează deteriorarea doar la componenta defectată, fără a interfera cu restul.
Toate funcțiile legate de funcționarea rețelei, dispozitivele de blocare (disc), emularea adaptoarelor video și alte dispozitive sunt mutate din hypervisor. Majoritatea acestor dispozitive constau din două părți: drivere în domU și programe în dom0. Driverul (cel mai adesea încorporat în nucleul sistemului de operare sau încărcat ca modul) implementează cantitatea minimă de muncă, de fapt, traducând cererile din sistemul de operare în programul din dom0. Programul din dom0 face cea mai mare parte a muncii. În acest caz, programul rulează cel mai adesea ca un proces separat pentru fiecare dispozitiv deservit. O defecțiune într-un astfel de program duce la defecțiunea unui singur dispozitiv (bloc, rețea) și nu afectează funcționarea altor copii ale programului (adică nu afectează rețeaua/bloc dispozitivele din alte domenii sau chiar alte dispozitive din același domeniu).
În mod tradițional se folosește următoarea terminologie: frontend este partea din modul situată în domU, backend este partea aflată în dom0. Pentru unele tipuri de dispozitive, partea backend poate fi diferită, păstrând aceeași parte frontală. De exemplu, un driver de dispozitiv bloc ar putea avea un backend sub forma unui imager VHD, un driver de dispozitiv bloc, un inițiator iscsi și așa mai departe.
Xen oferă trei mecanisme de comunicare pentru domenii: unul cu hypervisor (hypercalls) și două între domenii. Cel mai adesea, interacțiunea are loc între dom0 și domU, deși modelul permite interacțiunea între două domU.
Interacțiunea între domenii se reduce la două tipuri: evenimente (evenimente) și meme partajate (acces la memorie partajată). A treia opțiune, transferul paginii de memorie, este un caz special de acces la memorie partajată.
Evenimentele servesc aproximativ același scop ca întreruperile în arhitectura x86 sau semnalele în Unix - transmiterea rapidă sincronă sau asincronă a unui semnal despre apariția unui eveniment. Accesul la memorie partajată oferă posibilitatea de a transfera cantități semnificative de informații, iar evenimentele oferă o rată de transfer.
Evenimentele pot fi mascate sau demascate. Evenimentele nemascate provoacă un apel invers (apelarea funcției a cărei adresă a fost transmisă mai devreme) și vă permit să procesați evenimentul imediat după apariția acestuia. Evenimentele mascate stabilesc doar un semnalizare că evenimentul a avut loc, iar handlerul caută periodic pentru a vedea dacă evenimentul (unul sau mai multe) a avut loc. A doua metodă vă permite să nu apelați un callback pentru fiecare eveniment și, în cazul evenimentelor frecvente, reduce semnificativ timpul de procesare. Dimpotrivă, prima opțiune (cu apel invers) vă permite să creșteți viteza de procesare a unui eveniment care poate să nu apară foarte des, dar necesită un răspuns imediat.
Xen (prin stiva de management) acceptă migrarea mașinilor virtuale invitate prin rețea. Migrarea mașinilor paravirtuale este acceptată de la versiunea Xen 2 și HVM - de la versiunea 3. Migrarea poate avea loc cu sistemul oaspete oprit sau chiar în acest proces, așa-numita migrare „live” (în engleză live migration ) fără pierderi de disponibilitate.
Este necesar ca ambele servere fizice Xen să vadă aceeași stocare în care se află datele mașinii virtuale. Acest lucru este necesar deoarece la migrarea unei mașini virtuale, sistemul de fișiere al acesteia nu este copiat, deoarece acest lucru ar dura prea mult timp chiar și în cazul unei rețele rapide. Stocarea partajată se poate baza pe diverse tehnologii SAN sau NAS , cum ar fi Fibre Channel , iSCSI sau DRBD .
Datorită faptului că hypervisorul însuși (aproximativ 500-600 KB) implementează doar „nucleul” sistemului, toate celelalte funcționalități sunt mutate în stratul de aplicație care rulează în dom0. Un set de programe care implementează funcționalități în afara lui Xen se numește engleză. toolstack (nu există o traducere bine stabilită, uneori se folosește termenul „management stack”).
Există două versiuni ale toolstack-ului pentru Xen: bazată pe xend (inclusă în majoritatea distribuțiilor Xen) și bazată pe xapi (inclusă în Citrix XenServer și Xen Cloud Platform). Xend a fost dezvoltat în același timp cu Xen, scris în Python și de la bun început a fost sub o licență open source. Xapi era proprietarul Xensource (denumită în continuare Citrix), dar a fost lansat sub GPL în 2009. Xapi este scris în OCaml , la momentul scrierii, avea un set mai mic de caracteristici, dar era mai stabil.
În versiunea 4.5, xend scris în python a fost înlocuit cu xl/libxl scris în C.
Ambele versiuni ale stivei de instrumente includ următoarele utilitare:
Toolstack oferă managementul mașinilor virtuale (creare/ștergere, pornire/oprire, migrare, conectarea resurselor etc.). În plus, setul de instrumente oferă gestionarea resurselor pentru sistemele la scară largă: creează și menține depozite pentru stocarea imaginilor de disc ale mașinilor virtuale (SR - depozit de stocare), acceptă pool-uri de servere pentru migrarea mașinilor virtuale și poate gestiona configurații complexe ale rețelei locale, inclusiv cele cu suport VLAN . În plus, este acceptată interfața de control de la distanță XenApi bazată pe XML-RPC [36] .
Xen acceptă tot mai multe platforme în fiecare zi.
Ca hypervisor hibrid de tip 1 , Xen rulează direct pe platforma hardware, dar necesită un sistem de operare gazdă în dom0 pentru a rula. Xen suporta procesoare incepand de la Pentium II , exista versiuni pentru x86-64 , PowerPC , Itanium (pana la versiunea 4.4) si arhitecturi ARM (stabila de la versiunea 4.4). Încărcarea Xen se face cu un bootloader precum GRUB sau similar. Imediat după încărcare, Xen pornește sistemul de operare în dom0.
Majoritatea instalărilor folosesc Linux ca sistem de operare pentru domeniul de control dom0. Multă vreme, suportul Xen nu a fost inclus în nucleul oficial Linux și a existat ca un set de patch-uri pentru nucleul v2.6.18. Începând cu v2.6.37, mecanismul pv_ops a apărut în nucleul Linux pentru interacțiunea cu hipervizorii [37] . Acest mecanism permite nucleului să funcționeze atât în modul paravirtual, cât și direct pe hardware. Începând cu Xen 4.0, acceptă mecanismul pv_ops pentru nucleul Linux în dom0 [38] . Nucleele Linux de peste 3.0 suportă complet Xen atât pentru dom0, cât și pentru domU [39] .
De asemenea, următoarele sisteme de operare pot funcționa ca dom0:
Majoritatea sistemelor de operare pot fi rulate în modul de virtualizare hardware HVM, totuși, tehnologia de paravirtualizare este utilizată pentru a obține o viteză mare de execuție. Următoarele sisteme de operare invitați pot fi rulate în modul paravirtual în domU:
Porturile altor sisteme de operare, cum ar fi Plan 9 , sunt, de asemenea, în lucru. Este de așteptat ca porturile oficiale pentru Xen să fie lansate pentru toate aceste sisteme de operare (cum sa întâmplat pentru NetBSD).
Sistemele de operare ale familiei Microsoft Windows pot rula în modul complet de virtualizare HVM începând cu Xen 3 pe procesoare care acceptă virtualizarea hardware. În acest caz, dispozitivele virtuale (disc, rețea) sunt emulate folosind o versiune specială a QEMU . Pentru a accelera Windows, pot fi folosite așa-numitele drivere paravirtuale . Spre deosebire de Linux în modul paravirtual, nucleul Windows este nemodificat și rulează în modul de virtualizare hardware, dar driverele de dispozitiv accesează Xen direct (prin HyperCalls), ocolind stratul de emulare QEMU. Există o dezvoltare a driverelor de paravirtualizare GPL pentru Windows, iar produsele Citrix XenServer și Oracle VM conțin drivere de paravirtualizare semnate pentru Windows.
Xen este utilizat pe scară largă ca componentă de virtualizare în cloud computing și servicii de server private dedicate . Companii de găzduire precum Amazon Elastic Compute Cloud , Liquid Web , Fujitsu Global Cloud Platform , [46] Linode , SparkNode [47] și Rackspace Cloud folosesc Xen ca hypervisor de mașină virtuală.
În prezent[ clarificați ] Comunitatea Xen dezvoltă Xen Cloud Platform (XCP), un sistem de virtualizare a serverelor. XCP provine din versiunea gratuită a Citrix XenServer și este lansat în întregime sub GNU GPL .
Există mai multe produse comerciale de consolidare a serverelor bazate pe Xen. În special, acestea sunt produse precum: