Acest material este produs sub licență CC BY 3.0 de către membrii echipei ITSpark.ro,cu susținerea Microsoft România (Todi, Zoli, Sebi, Petru, @OpenAtMicrosoft și alții).
Pornind pe un ton puțin mai jucăuș, o viziune relativ des întâlnită (și din păcate eronată) atunci când vine vorba de virtualizare pe platforma Hyper-V poate fi sintentizată printr-o afirmație de genul ”pe Hyper-V putem virtualiza orice sistem de operare, atât timp cât e Windows”. Trecând însă dincolo de glumă, nimic nu e mai departe de realitate, iar în articolul următor voi încerca să ating tocmai elementele esențiale ale acestui subiect.
Înainte de a începe însă, aș dori să menționez existența unui screencast pe această temă, pregătit anul trecut (imediat după apariția Linux IS 2.1) și disponibil la finalul acestui articol. În acest screencast veți găsi mai multe detalii legat de o parte din elementele discutate mai jos, în cazul în care există nelămuriri. Mai mult decât atât, echipa ITSpark vă stă oricând la dispoziție pentru orice alte întrebări.
Conform listei sistemelor de operare cu suport sub Hyper-V, distribuțiile Linux suportate oficial sunt doar SLES (SUSE Linux Enterprise Server) și RHEL (Red Hat Enterprise Linux), mai precis:
Aspectul care trebuie însă lămurit aici este ceea ce se înțelege prin ”suport oficial”. În primul rând, pentru sistemele de operare din acea listă, Microsoft oferă suport tehnic: da! poți suna la Microsoft dacă ai probleme cu RHEL sau SUSE instalat sub Hyper-V, iar acest lucru este posibil deoarece Microsoft are parteneriate cu companiile respective.
Tocmai aceasta e dificultatea în cazul celorlalte distribuții Linux: chiar dacă majoritatea distribuțiilor funcționează fără nici un fel de probleme sub Hyper-V (fie în mod emulat, fie ”enlightened”), nu există companii care să ofere suport dedicat pentru ele, acest suport fiind de obicei oferit de o comunitate. Astfel, e de la sine înțeles că nici Microsoft nu poate oferi mai departe suport oficial dedicat, însă recomandă celor ce implementează astfel de soluții să apeleze la experți tehnici (comunitatea MVP, consultanți IT, etc) sau la comunitățile de profil construite în jurul fiecărei distribuții Linux.
Și dacă e să ne referim la alte sisteme de operare care funcționează sub Hyper-V (în afara SLES sau RHEL), de-a lungul timpului s-au raportat instalări și utilizări fără probleme ale distribuțiilor Ubuntu, CentOS, Debian, Fedora, OEL, OpenSUSE și chiar ale unor sisteme non-Linux, cum ar fi FreeBSD sau OpenSolaris.
Menționasem mai devreme că majoritatea distribuțiilor Linux funcționează fără probleme sub Hyper-V, fie în mod emulat, fie în mod ”enlightened”. Totuși, ce înseamnă asta mai exact?
Ca să putem înțelege mai ușor termenii de emulat sau ”enlightened”, trebuie să știm exact cum funcționează virtualizarea, din perspectiva accesului la hardware. În cazul oricărei soluții de virtualizare, resursele hardware fizice disponibile pe sistemul gazdă ajung să fie abstractizate și mai departe expuse sistemelor de operare client (guest) în diferite moduri.
Un astfel de mod de acces e cel emulat, folosit atunci când ne dorim ca sistemul de operare guest să nu știe că funcționează într-un mediu virtualizat, caz în care platforma de virtualizare e cea care trebuie să emuleze funcționalitatea propriu-zisă a hardware-ului și să se ocupe de ”traducerea binară” bidirecțională a oricăror activități de tip input-output ce au loc între mașinile virtuale și hardware-ul fizic. Chiar dacă cererile input-output către HDD/rețea/display/etc. nu vor putea fi făcute direct ci vor fi intermediate de platforma de virtualizare, marele avantaj e că nu necesită nici un fel de alte modificări la nivelul sistemului de operare client. Acest beneficiu e obținut însă cu prețul unui impact (e drept, nu foarte mare) de performanță asupra întregului sistem gazdă (host).
O altă modalitate de acces la hardware în cazul sistemelor virtualizate este utilizarea paravirtualizării (sau ”enlightenment”, cum e ea numită în cazul Hyper-V), o abordare în care sistemul de operare guest este modificat și făcut să recunoască faptul că rulează într-un mediu virtualizat, caz în care va utiliza drivere scrise special pentru a lucra mai eficient într-un astfel de mediu. În cazul Hyper-V, acele drivere poartă numele de ”enlightened” sau ”synthetic” drivers, ele nefiind de fapt decât niște pointeri la driverele instalate în ”parent partition”.
Pentru cei care nu sunt familiari cu terminologia, în momentul instalării rolului Hyper-V sistemul de operare gazdă este transformat în ”parent partition”, care e de fapt o mașină virtuală cu privilegii elevate (ex: create/delete/start/stop/snapshot pentru alte mașini virtuale), mașină ce conține și driverele pentru dispozitivele hardware fizice de pe sistem, așa cum se vede din diagrama arhitecturii Hyper-V de mai jos (mai multe detalii în screencast-ul din final):
Din punct de vedere tehnic, driverele emulate în Hyper-V sunt similare cu cele care existau în vechiul Virtual Server, și anume:
Astfel, dacă sistemul de operare (SO) guest suportă dispozitivele hardware amintite respective (iar acest lucru este foarte probabil, deoarece suportul pentru aceste dispozitive este extrem de răspândit la nivelul tuturor sistemelor de operare), acel SO va funcționa fără probleme în mod emulat.
De ce am vrea atunci să utilizăm o soluție bazată pe paravirtualizare? Răspunsul este simplu: pentru performanță. În cazul Hyper-V, utilizarea unor drivere ”enlightened” aduce un plus de performanță de cel puțin 40% la disk I/O și 30% la partea de rețea, și permite practic accesul aproape direct al mașinilor virtuale la hardware-ul fizic, eliminând acea încărcare suplimentară a resurselor, care apare în cazul efectuării unei ”traduceri binare” a cererilor input-output.
În teste, în cazul utilizării unor drivere ”enlightened”, impactul de performanță este de doar 1-3% în raport cu un sistem fizic (nevirtualizat) care ar utiliza același hardware. Acest indicator de performanță justifică încă o dată relevanța utilizării virtualizării în medii de producție.
Un alt element important de reținut în cazul abordării ”enlightened” (sau altfel spus, a paravirtualizării) din Hyper-V ce reiese din diagrama arhitecturală de mai sus îl constituie utilizarea unui sistem simplu și eficient de comunicare între mașinile virtuale și mașina gazdă (host). Dacă ne uităm pe diagramă, observăm următoarele componente:
În cazul Linux fiecare modul VSC conține un Driver Interface Mapper (DIM) care interacționează cu kernel-ul Linux ca orice alt driver, și un ”VSC core” implementat pe baza protocolului fiecărui VSP de la nivelul sistemului gazdă Hyper-V. Acel ”VSC core” e cel care interacționează cu VSP-ul corespunzător prin intermediul interfeței VMBus.
Componentele despre care am discutat mai sus (VMBus, VSC) se instalează în interiorul mașinilor virtuale guest prin intermediul ”Integration Components/Services”. Acestea sunt disponibile atât pentru Windows, cât și pentru Linux. În cazul Linux IS acestea au evoluat enorm în ultimii ani, așa că aș dori să discut mai jos despre ceea ce e disponibil la ora actuală. Pe scurt, odată cu instalarea Linux Integration Services (IS), pe sistemul Linux guest vom avea disponibile următoarele componente:
Probabil unul din cele mai complexe elemente ale mediilor virtualizate îl constituie păstrarea timpului exact, mai ales în mediile care nu folosesc paravirtualizare, însă aceasta este o temă extrem de interesantă care probabil merită un articol separat.
Chiar și așa, ideea de bază e că odată cu introducerea suportului pentru Time Sync și Pluggable time source în Linux Integration Services, majoritatea problemelor care țineau de acest aspect în cazul sistemelor Linux instalate sub Hyper-V au fost eliminate, obținându-se o metodă eficientă de a valida că în interiorul mașinilor virtuale cu Linux nu vom avea un time drift mai mare de 20-30 PPM (parts-per-million), sau aproximativ 1.7-2.5 secunde pe zi (echivalând cu un minut pe lună).
Acestea fiind spuse, aș dori să trecem acum print-o scurtă cronologie a modificărilor survenite la nivelul acestor ”Integration Services” și să vedem la ce ne putem aștepta să apară în versiunile viitoare.
2008 – Versiunea 1 – codul original, creat de Citrix (distro code)
Iulie 2009 – Versiunea 2 – creată de Microsoft (distro code)
Odată cu lansarea versiunii 2, Microsoft a șocat lumea opensource contribuind cu peste 20.000 de linii de cod la kernel-ul Linux (pentru versiunea 2.6.32), adăugând driver-ele Hyper-V sub licența GPLv2 în zona de ”staging” (/drivers/staging/hv). Acea zonă de ”staging” din kernel e o locație temporară unde sunt adăugate orice noi drivere, scoaterea lor din ”staging” făcându-se după dovedirea seriozității în privința menținerii acelui cod pe termen lung din partea celui care l-a adăugat. Versiunea driver-elor adăugată în mainline Linux kernel este neoficial denumită ”versiunea 3”.
Martie 2010 – Versiunea 2.1 Beta – (distro code) adăugare de noi funcționalități
Iulie 2010 – Versiunea 2.1 RTM – (distro code) versiunea finală
E important de menționat aici că versiunea 2.1 este ultima versiune de tip ”distro code” pe care Microsoft o va face disponibilă, singura versiune suportată pe viitor fiind cea din mainline kernel (V3).
Iulie 2009 – Versiunea 3 – (mainline code) contribuție adăugată în mainline Linux kernel, și menținută pe termen lung
Important de reținut: în momentul de față, chiar dacă în linii mari facilitățile oferite prin Linux IS V2.1 (distro code) și Linux IS V3 (mainline kernel / staging) sunt aproximativ aceleași, codul comun între ele este doar de 20-30%, varianta V3 fiind cea actualizată și menținută.
Ce ne așteaptă în viitor? Versiunea 4 – (mainline code) aflată încă în partea de planificare/development:
Pașii de bază sunt următorii (în funcție de versiunea instalată):
Așa cum am menționat pe parcursul articolului, mai jos aveți screencast-ul în care veți găsi mai multe detalii legat de unele dintre elementele discutate în articolul de față.
Aș dori să închei acest articol cu o veste excelentă, zic eu. Într-o discuție recentă cu unul din membrii echipei care se ocupă de codul mainline, am aflat că intenția celor de la Microsoft e aceea de a oferi suport pentru orice distribuție care va include Linux Integration Services în momentul în care acestea vor ieși din ”staging” (deci suportul oficial nu se va mai limita doar la distribuțiile SLES/RHEL).
Chiar dacă performanța și facilitățile oferite la ora actuală de Linux IS fac din Hyper-V o soluție mai mult decât adecvată pentru a suporta sisteme de operare Linux guest în medii de producție, planul pe termen lung este acela de a transforma Linux într-un cetățean de primă clasă atunci când e vorba de Hyper-V!
Join now or Sign in with your favorite social networking sites.