modele

IT iubește virtualizarea lucrurilor, urmând vechea regulă conform căreia în informatică fiecare problemă poate fi rezolvată doar cu încă un nivel de indirectare. Cloud computing se bazează pe virtualizarea resurselor de calcul - nu este nevoie să știți pe ce mașină fizică rulează aplicația dvs. și puteți obține altele noi printr-un clic pe un buton. Înainte ca cloud-ul să fie un cuvânt cheie, totuși, VMware și alții au virtualizat mașini la nivel de sistem de operare. Recent (în termeni de buzz, nu de tehnologie), containerele aduc un alt nivel de virtualizare ușoară a resurselor de calcul. Și să nu uităm de mașina virtuală Java, care pretinde și un nivel de virtualizare. Ce ar trebui să facem cu toate aceste niveluri de virtualizare?

Ce este virtualizarea?

Virtualizarea transformă resursele fizice în resurse logice, care sunt mai flexibile și adesea disponibile la cerere. Gândiți-vă la aceasta ca la o mașină de închiriat, spre deosebire de a deține o mașină: puteți închiria un decapotabil pe vreme frumoasă, o tracțiune integrală în timpul iernii și un vagon (proprietate) pentru transportul lucrurilor. Și îi plătești pentru ei doar atunci când ai nevoie de ei. Cumpărarea tuturor acestor mașini ar fi extrem de ineficientă, mai ales când le folosești rar (de fapt dețin un vagon și un decapotabil, așa că știu). Realizarea virtuală a lucrurilor vă permite să creați noi instanțe de ceva din resurse existente - cum ar fi închirierea unei mașini dintr-o piscină mare. În lumea software-ului avem câteva flexibilități adăugate: putem instanția diferite sisteme de operare, cum ar fi Windows sau Linux, pe același hardware și un hipervizor sau putem transforma o mașină fizică mare în mai multe mașini virtuale mici. Aici analogia mașinii de închiriat se epuizează: transformarea vagoanelor în decapotabile este mult mai grea și o singură mașină nu poate fi segmentată în două motociclete.

Niveluri de virtualizare

Virtualizarea la nivel de sistem de operare există de mult timp. Un hipervizor gestionează și abstractizează hardware-ul mașinii, astfel încât să puteți crea noi instanțe ale sistemului de operare de diferite arome și dimensiuni pe un set fix de hardware fizic. Aceasta este o veste veche în lumea mainframe-ului, precum VMware oferă acest lucru de ceva timp pe platformele x86, reducând timpii și costurile de implementare a mașinilor, în timp ce crește utilizarea resurselor.

Majoritatea giganților de pe internet nu folosesc hipervizorii pe plan intern, totuși, deoarece poartă o anumită cheltuială în intervalul 5-15% și costă o sumă bună de licențiere a banilor dacă utilizați un produs comercial. Dacă aveți 100 de mașini, probabil că nu este mare lucru, dar dacă aveți 100.000 de mașini, veți dori ceva diferit. Majoritatea norilor publici folosesc hipervizori, de ex. KVM pentru Google Compute Engine sau Xen pentru Amazon EC2, deoarece trebuie să accepte mai mulți furnizori și versiuni de sisteme de operare.

Infrastructurile de calcul mari de astăzi folosesc adesea containere, de obicei bazate pe tehnologia Linux LXC: mai multe containere rulează pe o singură instanță de sistem de operare și, astfel, transportă mai puține cheltuieli generale decât instanțele OS separate. De obicei, oferă, de asemenea, mai puțină izolare între instanțe - ceva de luat în considerare dacă afacerea dvs. necesită conformitate PCI sau altele asemenea. Infrastructurile mari utilizează de obicei software de gestionare a clusterelor, cum ar fi Mesos sau Kubernetes, pentru a aloca volumul de lucru pe un număr mare de containere. Am făcut asta la Google în urmă cu mulți ani la scară largă.

Mașina virtuală Java a fost, de asemenea, popularizată ca strat de virtualizare la alegere - „scrie o dată - rulează oriunde”. În plus față de extragerea codului de octeți, containerele J2EE au furnizat, de asemenea, extragere în timp de execuție prin gestionarea mai multor aplicații care rulează pe un singur server prin intermediul unor grupuri de fire și altele asemenea. Mai multe aplicații Java pot fi implementate la cald în astfel de containere (Java) prin fișiere WAR.

Multe dintre pachetele de software moderne de astăzi oferă, de asemenea, un nivel de virtualizare, operând independent de numărul și identitatea nodurilor de calcul de dedesubt. MapReduce și verii săi sunt construiți pe baza acestui principiu: gestionează distribuția volumului de lucru, repornirea proceselor și toate celelalte lucruri urâte din cadrul lor. Pe de o parte, acest lucru permite aplicației să nu trebuiască să-și facă griji și, pe de altă parte, reduce nevoia de caracteristici de administrare a infrastructurii.

De ce vrem să virtualizăm totul?

Virtualizarea are un beneficiu clar al utilizatorului: resursele de calcul devin disponibile la cerere, fără a configura și conecta hardware fizic nou. Mai bine, stratul de virtualizare face acest lucru (în mare măsură) transparent pentru stratul de aplicație prin abstractizarea detaliilor implementării. Capacitatea de a împărți resursele fizice în multe unități logice îmbunătățește, de asemenea, utilizarea și, prin urmare, eficiența costurilor: puteți cumpăra servere mai mari și le puteți utiliza în mici pași, fără a schimba modul în care este scris software-ul.

Furnizorii adoră să ofere un strat de virtualizare dintr-un alt motiv: îi poziționează chiar în mijlocul ecosistemului de calcul, deținând un rol central greu de înlocuit. De exemplu, VMware ESX este utilizat pe scară largă și este central pentru multe infrastructuri IT. În timp ce virtualizarea hardware este în mare măsură transparentă pentru aplicație, instrumentele de gestionare și aprovizionare nu sunt și duc la o anumită cantitate de blocare a furnizorilor. OpenStack va aduce o ușurare în acest domeniu, dar maturitatea implementării variază în continuare.

Matrioșka de virtualizare

De câte straturi de virtualizare are nevoie unul? Rularea unei aplicații Java într-un container Java într-un container Linux deasupra unei mașini virtuale începe să arate ca o păpușă Matryoshka: păpuși mici stivuite una în alta. Eu numesc asta Virtualizare Matrioșka: multe straturi de virtualizare stivuite unul în celălalt. În timp ce păpușile matrioșka sunt distractive, probabil că aveți senzația că aceasta nu este cea mai eficientă configurare pentru o infrastructură în timp de execuție.

Slăbire

Prea multe straturi nu numai că aduc complexitate și cheltuieli generale, dar nu aduc prea multe beneficii. Întrebarea naturală este atunci ce strat (e) ar trebui să eliminăm. Pentru aplicațiile Java, probabil că dorim să păstrăm JVM, dar există o tendință clară către containere încorporate mai ușoare, a căror sarcină nu este să ruleze multe aplicații, ci o singură aplicație cu cât mai puțină abstracție posibilă. Acest lucru elimină un singur strat de virtualizare la nivelul serverului de aplicații.

Platformele PaaS (Platform-as-a-service), care tind să folosească containerele, încep să elimine sistemul de operare strat VM prin implementarea pe mașini fizice într-o așa-numită abordare „bare metal PaaS”. Veți avea nevoie de o componentă care să gestioneze aceste mașini fizice, dar o mare parte din acestea pot fi ascunse sub modelul PaaS, făcându-l în mare parte transparent pentru implementatorul aplicației. OpenStack analizează, de asemenea, o implementare bare-metal a Nova, care rulează sub numele de Ironic. Tot ce avem nevoie este o implementare pentru calcul deschis și suntem pregătiți să plecăm.

Eliminarea straturilor va oferi o creștere a performanței și costuri reduse ale licenței pentru stratul de virtualizare. Acest lucru poate fi cel mai pronunțat în aplicațiile de calcul I/O grele și cu latență scăzută sau de înaltă performanță. Cred că eliminarea câtorva straturi de virtualizare este o tendință sănătoasă. Straturile sunt bune - Păpușile Matryoshka sunt amuzante, dar nu sunt eficiente.