- Pesastatud virtualiseerimine võimaldab hüperviisoritel ja virtuaalmasinatel töötada teiste virtuaalmasinate sees, maksimeerides riistvara kasutamist ja hõlbustades keerukaid laboritöid ja teste.
- Enne pesastamise lubamist on oluline, et hostil oleksid ühilduvad protsessorid (Intel VT-x või AMD-V/SEV), Windowsi uuendatud versioonid ja Hyper-V installitud.
- Pesastatud virtuaalmasinate stabiilse ühenduvuse tagamiseks tuleb võrgu- ja MAC-aadressi võltsimine hoolikalt konfigureerida, eriti IoT Edge'i keskkondades ja VMware ESXi või Azure'i stsenaariumides.
- Mitmekihilised varukoopiad ja ressursside jälgimine on turvaliste, taastatavate ja kontrollitud jõudlusega pesastatud keskkondade säilitamise võtmeks.
Pesastatud virtualiseerimine tänapäevasel riistvaral on muutunud peaaegu asendamatuks tööriistaks IT-meeskondadele, arendajatele ja koolitajatele, kes peavad looma keerukaid laboreid, testimiskeskkondi või turvastsenaariume ilma andmekeskust füüsiliste serveritega täitmata. Lihtsamalt öeldes võimaldab see teil käitada virtuaalmasinaid teiste virtuaalsete masinate sees, säilitades vastuvõetava jõudluse ja peenhäälestades ressursside haldamist.
Lisaks tüüpilisele "ühe virtuaalmasina teise sisse paigutamisele" avab pesastatud virtualiseerimine ukse paindlikele DevOps-i torujuhtmetele, realistlikele koolituskeskkondadele, isoleeritud turvatestidele ja IoT Edge'i juurutustele erinevatel platvormidel, alates kohapealsest Hyper-V-st kuni Azure'i või VMware ESXi virtuaalsete masinateni. Selleks, et kõik ootuspäraselt toimiks, peavad riistvara ja hüperviisori konfiguratsioon vastama väga spetsiifilistele nõuetele.
Mis täpselt on pesastatud virtualiseerimine ja miks see on oluline?
Pesastatud virtualiseerimine viitab virtuaalmasina võimele toimida virtualiseerimishostina teistele sisemistele virtuaalmasinatele. Teisisõnu, füüsilisel riistvaral on olemas tipptasemel hüperviisor (näiteks Hyper-V Windows Serveris või Azure Localis) ja ühte selle virtuaalmasinatest installime Hyper-V või mõne muu ühilduva hüperviisori, et luua rohkem virtuaalmasinaid.
Hyper-V puhul võimaldab pesastatud virtualiseerimine Hyper-V rolli installida külalisvirtuaalmasinasse , mis omakorda töötab füüsilisel hostil Hyper-V-ga. See "vahepealne" virtuaalmasin avaldab protsessori virtualiseerimislaiendid sisemistele virtuaalmasinatele, mis käituvad nii, nagu oleksid nad riistvarale lähemal, kuigi tegelikult on nende all mitu kihti.
See funktsioon ilmus algselt Windows Server 2016 ja Windows 10 jaoks Inteli protsessoritele ning tugi on sellest ajast alates laienenud Windows Serveri, Windows 11 ja AMD protsessorite uuematele versioonidele. Tänapäeval on see küps funktsioon, mille Microsoft integreerib oma ametlikku dokumentatsiooni ja mida kasutavad ka kolmandate osapoolte lahendused.
Praktiline väärtus on selge: pesastatud virtualiseerimise abil saame replikeerida tootmiskeskkondi, luua terveid klastreid, testida riskantseid konfiguratsioone või simuleerida mitmekihilisi võrke ilma uutesse riiulitesse investeerimata või andmekeskuse ruumi reserveerimata. Paljude ettevõtete jaoks kompenseerib see kulude kokkuhoidu ja paindlikkust kuhjaga väikese jõudluslanguse.
Pesastatud virtualiseerimise levinumad kasutusjuhud
Üks populaarsemaid stsenaariume on keerukate testlaborite loomine . Arendus- ja kvaliteedikontrolli meeskonnad saavad luua mitmetasandilisi rakenduste pinusid (andmebaasid, kesktaseme teenused, esiotsad) täielikult ühe virtuaalmasina sees ning selles hostida kõiki sisemisi virtuaalmasinaid, mida on vaja tootmiskeskkonna replikeerimiseks.
See on väga kasulik ka tehnilise koolituse ja arenduskeskkondades . Õppejõud saavad seadistada host-virtuaalmasina, kus iga õpilane loob oma külalisvirtuaalmasinad, konfigureerib võrke, testib serverirolle või juurutab konteinereid, ilma et peaks kunagi ettevõtte "päris" infrastruktuuri puutuma. Kõik asub kergesti eemaldatavas liivakastis.
Teine tüüpiline kasutusala on uute tarkvaraversioonide hindamine ja testimine . Füüsilises hostis otse tundlike konfiguratsioonide muutmise asemel saavad administraatorid stsenaariumi kopeerida pesastatud virtualiseeritud virtuaalmasinal ja enne tootmiskeskkonnas juurutamist valideerida parandusi, uusi versioone või turvamuudatusi.
Pesastatud virtualiseerimisel on oluline roll ka täiustatud turvafunktsioonide, näiteks virtualiseerimispõhise turvalisuse (VBS) või spetsiifiliste isolatsioonide, mis tuginevad hüperviisori funktsioonidele erinevatel tasemetel, lubamisel. See võimaldab teatud keskkondade tugevdamist ilma täiendavat riistvara vajamata.
Asjade interneti valdkonnas on pesastatud virtualiseerimine võtmetähtsusega Azure IoT Edge'i puhul Linuxi ja Windowsi stsenaariumide jaoks , kus on vaja kombineerida Windowsi, Linuxi konteinerite ja hüperviisori võimalusi erinevatel virtualiseerimiskihtidel nii lokaalselt kui ka kolmandate osapoolte platvormidel, näiteks VMware ESXi või Azure'i virtuaalmasinatel.
Pesastatud virtualiseerimise riist- ja tarkvaranõuded
Selleks, et see kõik korrektselt toimiks, on esimene filter ühilduv riistvara ja minimaalsed operatsioonisüsteemi versioonid . Näiteks Azure'i kohapealsetes keskkondades on vaja versiooni 2411.3 või uuemat, koos virtuaalmasinatega, mille konfiguratsiooniversioon on 10.0 või uuem, tagades seega vajalike virtualiseerimislaienduste toe.
Protsessori tasandil, kui töötate Inteliga, on oluline, et BIOS-is/UEFI-s oleks lubatud Intel VT-x virtualiseerimistehnoloogia . AMD arhitektuuride puhul on vajalik AMD-V tugi ja edasijõudnute stsenaariumide korral peab olema lubatud turvaline krüptitud virtualiseerimistehnoloogia (SEV), mis lisab virtuaalmasinatele krüptimise ning parandab isolatsiooni ja madala taseme turvalisust.
Hosti operatsioonisüsteem peab olema Windows Serveri või Windows 10/11 moodne versioon , mis on korralikult uuendatud uusimate parandustega. Enne pesastamise lubamist peab füüsilisse masinasse olema installitud Hyper-V; see ei ole funktsioon, mis tuleb lihtsalt ühilduva protsessori olemasolul standardvarustusse.
Teine oluline punkt on virtuaalsete masinate olek. Protsessori parameetrite muutmiseks ja virtualiseerimislaienduste kasutamiseks peab pesastatud hostina toimiv virtuaalmasin olema täielikult välja lülitatud , mitte peatatud ega salvestatud olekus. Alles siis lubab Hyper-V muuta virtuaalse protsessori täpsemaid valikuid.
Lõpuks tuleb võrguühendust hoolikalt planeerida. Pesastatud virtuaalmasinad võivad vajada välist juurdepääsu või juurdepääsu teistele kihtidele, seega on soovitatav algusest peale määratleda, kas kommunikatsiooni- ja filtreerimisprobleemide vältimiseks kasutatakse sisemisi lüliteid, NAT-i, MAC-aadressi võltsimist või muid virtuaalse võrgu tehnikaid.
Pesastatud virtualiseerimise lubamine Hyper-V-s PowerShelli abil
Kõige otsesem ja detailsem viis pesastatud virtualiseerimise lubamiseks Hyper-V-s on PowerShelli cmdlettide kasutamine . See meetod töötab nii Windows Serveris kui ka ühilduvates kliendiversioonides ning võimaldab teil konfiguratsiooni mitme hostis või virtuaalmasinas järjepidevalt automatiseerida.
Esimene samm on veenduda, et virtuaalmasin, kuhu soovime Hyper-V külalisena installida, on Hyper-V Managerist välja lülitatud (Sulgemisvalik) või näiteks PowerShellis sobiva käsu abil Stop-VM -Name 'NombreVM'Kui see jääb peatatud või salvestatud olekusse, siis protsessori muudatusi ei rakendata õigesti.
Kui virtuaalmasin on peatatud, peate protsessori virtualiseerimislaiendid külalisoperatsioonisüsteemile kättesaadavaks tegema, kasutades cmdlet-käsku Set-VMProcessor ja määrates suvandi ExposeVirtualizationExtensions väärtuseks true. See säte võimaldab süsteemil virtuaalmasina sees näha hüperviisori rollide installimiseks vajalikke funktsioone.
Toimingu korrektse rakendamise kontrollimiseks saame kasutada funktsiooni Get-VMProcessor koos funktsiooniga Select väljal ExposeVirtualizationExtensions. See kontrollib, kas siht-VM virtuaalprotsessori konfiguratsioonis on väärtuseks seatud tõene ja takistab osaliselt konfigureeritud keskkonna käivitamist.
Kui mingil hetkel osutub vajalikuks konfiguratsiooni taastada – näiteks diagnostilise ülesande ajal või seetõttu, et pesastatud virtuaalmasinaid enam ei vajata –, korrake lihtsalt sama protsessori cmdlet-käsku , kuid muutke väärtus väärtuseks „väär“, mis keelab taas virtualiseerimislaiendite nähtavuse külalis-virtuaalmasinale.
Kui virtuaalne protsessor on konfigureeritud, lülitatakse masin sisse menüükäsuga Start-VM või Hyper-V Manageri kaudu . Seejärel installitakse külalisoperatsioonisüsteemist täielik Hyper-V roll tavapäraste meetodite abil: Server Manager (rollide ja funktsioonide lisamine), DISM, PowerShell jne. Sellest hetkest alates käitub virtuaalmasin administraatori vaatenurgast täiendava Hyper-V hostina.
Võrgu konfiguratsioon ja MAC-aadressi võltsimine pesastatud keskkondades
Kui protsessori osa on valmis, on järgmine samm pesastatud virtuaalsete masinate võrguühenduse loomine . Kui soovime, et sisemised virtuaalmasinad suhtleksid teiste võrkude, interneti või kõrgema kihi arvutitega, on oluline vahepealse virtuaalmasina virtuaalses adapteris teatud parameetreid kohandada.
Hyper-V-s on levinud tava lubada MAC-aadressi võltsimine pesastatud hostina toimiva virtuaalmasina võrguadapteril. See funktsioon võimaldab sisemistel virtuaalmasinatel saata liiklust oma MAC-aadresside abil sama adapteri kaudu, möödudes füüsilise hosti virtuaalse kommutaatori blokeerimisest või filtreerimisest.
Selle korrigeerimise saab teha PowerShelli abil, kasutades cmdlet-käsku Set-VMNetworkAdapter, mille parameeter MacAddressSpoofing on seatud väärtusele Sees ja rakendatud virtuaalmasina vastavale võrguadapterile. See tagab, et kõrgema taseme hüperviisor ei kaota sügavamate virtuaalmasinate liiklust.
Täiustatud konfiguratsioonide puhul on soovitatav iga kihi virtuaalsete lülitite ja NAT-instantside topoloogia eelnevalt kujundada . Näiteks saame kombineerida sisemisi lüliteid, et isoleerida kihtide vahel laborid, marsruutimisreeglid või tulemüürid, ja NAT-i vahehostil, et pakkuda internetiühendust mitmele pesastatud virtuaalmasinale ilma neid otseselt paljastamata.
Mitme virtualiseerimiskihiga töötamisel on ühenduvusprobleemid sageli seotud keelatud MAC-aadresside võltsimise, valesti aheldatud NAT-reeglite või liiga piiravate tulemüüridega . Nende punktide ülevaatamine ja võrguadapterite või -teenuste taaskäivitamine igal kihil lahendab tavaliselt enamiku ühenduvusprobleeme pesastatud keskkondades.
Graafilise liidese kasutamine seotud ülesannete jaoks
Kuigi pesastatud virtualiseerimise ranget aktiveerimist kontrollib täielikult PowerShell, on praktikas paljud seotud toimingud mugavamad Hyper-V Manageri graafilise liidese kaudu , eriti kui haldame mitut hosti või soovime konfiguratsiooni visuaalselt üle vaadata.
Tüüpiline töövoog hõlmab Hyper-V Manageri avamist, sihtvirtuaalmasina leidmist ja selle väljalülitamise kontrollimist suvandi „Shut Down” abil. See täiendab PowerShelli kasutamist ja hoiab ära virtuaalmasina kogemata käivitamise, mille kõik parameetrid pole veel õigesti konfigureeritud.
Kui virtualiseerimislaiendite kuvamiseks vajalikud cmdlet-käsud on käivitatud, saame naasta graafilisse keskkonda ja avada virtuaalmasina konfiguratsiooniakna . Sealt on lihtne üle vaadata ja muuta võrguadapteri atribuute, eraldatud virtuaalsete protsessorite arvu või pesastatud host-virtuaalmasinale saadaolevat mälu.
MAC-aadressi võltsimise lubamise valik asub võrgukaardi täpsemates sätetes . Selle lubamine graafilise liidese kaudu on kiire ja läbipaistev administraatoritele, kes eelistavad visuaalset lähenemist või kes pole kõiki cmdleti parameetreid meelde jätnud.
Kui see konfiguratsioon on lõpule viidud, saab igapäevast keskkonnahaldust teha vaheldumisi füüsilise hostarvuti Hyper-V konsoolist või pesastatud virtuaalmasina sees , kasutades standardseid tööriistu uute virtuaalmasinate loomiseks, lülitite konfigureerimiseks, rollide lisamiseks või hetktõmmiste tegemiseks vastavalt iga labori vajadustele.
Pesastatud virtualiseerimine Azure'i kohapealsetes ja IoT Edge'i stsenaariumides
Azure'i kohapealsetes keskkondades tugineb pesastatud virtualiseerimine samadele põhimõtetele, kuid lisab spetsiifilisi versiooninõudeid ja tuge täiustatud funktsioonidele, nagu AMD SEV või turbelaiendused . Nõutav on minimaalne süsteemiversioon (2411.3 või uuem) ja virtuaalmasinad peavad kasutama ühilduvat konfiguratsiooniversiooni (10.0 või uuem).
Windowsi Linuxi Azure IoT Edge'iga töötamisel on kolm toetatud pesastatud virtualiseerimise juurutamise valikut . Igaüks neist käsitleb erinevaid taristuvajadusi ja kontrolli taset, mida organisatsioon soovib säilitada aluskeskkonna ja hüperviisori üle.
Esimene võimalus hõlmab IoT Edge'i juurutamist Windowsi virtuaalmasinasse kohalikus hostis Hyper-V abil . See on kõige lihtsam lähenemisviis: pesastatud virtualiseerimine lubatakse sellel Windowsi virtuaalmasinal ja seejärel installitakse ja konfigureeritakse Windowsis Azure IoT Edge Linuxile vastavalt Microsofti konkreetsele dokumentatsioonile.
Sellisel juhul on ülioluline veenduda, et Hyper-V roll oleks kohalikku hostisse (Windows Server või Azure Local) õigesti installitud . Ilma hostis aktiivse Hyper-V-ta ei saa külalisvirtuaalmasin toimida pesastatud hüperviisorina ega avaldada IoT Edge'i jaoks vajalikke funktsioone täiendavas kihis.
Sellised juurutused on väga kasulikud, kui teil on vaja integreerida IoT-seadmeid, Linuxi konteinereid ja Azure'i teenuseid olemasolevatesse Windowsi infrastruktuuridesse, säilitades mõistliku tasakaalu paindlikkuse, jõudluse ja haldamise lihtsuse vahel.
Pesastatud virtualiseerimine VMware ESXi ja Azure IoT Edge'iga
Teine huvitav stsenaarium tekib siis, kui soovime käitada Azure IoT Edge'i Linuxile Windowsi keskkonnas VMware ESXi-l majutatud Windowsi virtuaalmasinas . Selles kontekstis tugineb pesastatud virtualiseerimine pigem VMware'i hüperviisori kui otse riistvaral oleva Hyper-V võimalustele.
VMware ESXi versioonid 6.7 ja 7.0 sisaldavad selgesõnalist tuge riistvaralisele virtualiseerimisele külalissüsteemides , võimaldades pesastamist, mis on vajalik Windowsi virtuaalmasina Hyper-V hostiks saamiseks. VMware dokumenteerib selle funktsiooni oma teadmusbaasis, kirjeldades üksikasjalikult nõudeid ja võimalikke jõudluskaalutlusi.
Üldine protseduur hõlmab esmalt Windowsi virtuaalmasina loomist ESXi hostil , järgides VMware'i standardseid soovitusi protsessorite, mälu, salvestusruumi ja võrguadapterite kohta. Pärast loomist lülitatakse virtuaalmasin välja, et võimaldada selle täpsemate protsessori sätete muutmist.
Valige ESXi või vSphere Clienti liidesest Windowsi virtuaalmasin, minge menüüsse „ Muuda sätteid “ ja leidke jaotises „Protsessori sätted“ riistvara virtualiseerimise jaotis. Seal lubage suvand „ Avalda riistvaraline virtualiseerimine külalisoperatsioonisüsteemile“ , mis võimaldab Windowsil näha VT-x/AMD-V laiendusi isegi siis, kui see töötab ESXi-s.
Pärast muudatuste salvestamist ja virtuaalmasina taaskäivitamist installige Hyper-V hüperviisor Windowsi , kas kliendiversioonile (Windows 10/11) või Windows Serverile, lisades kindlasti haldustööriistad ja kõik lisakomponendid, mis on vajalikud IoT Edge'iga kasutatavate konteinerite või teenuste jaoks.
Pesastatud virtualiseerimine Azure'i virtuaalmasinates
Kui me viime stsenaariumi järgmisele tasemele ja töötame otse virtuaalsete masinatega Azure'is pesastatud virtualiseerimishostina , tulevad mängu platvormi iseärasused, eriti seoses virtuaalsete lülitite ja Azure'i virtuaalmasinate poolt vaikimisi kasutatava võrguga.
Azure IoT Edge Linuxile Windowsis ei ole natiivselt toetatud üheski Azure'i virtuaalmasinas, millel on serveri SKU, välja arvatud juhul, kui käivitatakse spetsiaalne skript sobiva virtuaalse lüliti lubamiseks. See skript avab vaikelüliti, mis võimaldab IoT Edge'i keskkonnal täiendava virtualiseerimiskihiga õigesti töötada.
Microsofti ametlik dokumentatsioon kirjeldab Azure'i kontekstis Linuxi virtuaalse kommutaatori loomise ja konfigureerimise samme , viies konteinerite ja Edge'i teenuste võrgunõuded vastavusse pilvevõrgu infrastruktuuri omadustega.
Selliste juurutuste puhul on eriti oluline üle vaadata virtuaalmasina SKU, salvestusruumi tüüp ning protsessori ja muutmälu kvoodid , kuna pesastatud virtualiseerimine lisab oma üldkulu ja sisemised virtuaalmasinad võivad ressursse intensiivselt tarbida, kui kogu komplekt pole õige suurusega.
Vaatamata neile keerukustele on eelis märkimisväärne: Azure'i virtuaalmasinat saab kasutada IoT Edge'i lahenduste testimis-, arendus- või eeltootmisplatvormina samadel tingimustel, mida hiljem kopeeritakse füüsilistel servaseadmetel või tööstuslikel lüüsidel, mis on juurutatud kohapeal.
Pesastatud Hyper-V virtuaalmasinate varundamine spetsiaalsete lahendustega
Üks aspekt, mida pesastatud virtualiseerimiskeskkondade loomisel sageli tähelepanuta jäetakse, on varundamise ja katastroofidejärgse taastamise strateegia . Siin tulevadki mängu ettevõtte tasemel varunduslahendused, mis suudavad korralikult hallata Hyper-V keskkondi mitme virtualiseerimiskihi ja mitme paralleelselt töötava platvormiga.
Nende lahenduste hulka kuuluvad sellised tööriistad nagu Vinchin Backup & Recovery , mis toetab enam kui viitteist erinevat virtualiseerimisplatvormi, sealhulgas VMware, Proxmox, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack ja muidugi Hyper-V. Seda tüüpi tarkvara on loodud heterogeensetele infrastruktuuridele, kus erinevate tootjate hüperviisorid eksisteerivad koos.
Sellised funktsioonid nagu pidev inkrementaalne varundamine, andmete deduplikeerimine ja tihendamine ning detailne taastamine vähendavad oluliselt salvestusruumi tarbimist ja aega, mis kulub üksikute masinate, konkreetsete failide või isegi konkreetsete objektide taastamiseks kriitilistest rakendustest.
Lisaks aitavad ajastatud varunduspoliitikad ja lindile või pilve arhiveerimisvõimalused kohandada varundusstrateegiat iga organisatsiooni regulatiivsete või sisemiste nõuetega, säilitades pikad säilitusperioodid ilma suure jõudlusega massiivide salvestuskulusid suurendamata.
Veebipõhine halduskonsool lihtsustab oluliselt pesastatud virtuaalmasinatega Hyper-V keskkondade kaitsmist: valite kaitstavad virtuaalmasinad, valite varundushoidla , määrate täitmisstrateegia (ajaaknad, varundamise tüüp, säilitus) ja käivitate töö. Paljud neist lahendustest pakuvad mitmenädalasi ulatuslikke prooviperioode, et hinnata nende jõudlust ja integratsiooni olemasoleva infrastruktuuriga.
Piirangud ja parimad tavad pesastatud keskkondades
Kuigi pesastatud virtualiseerimise võimalused on ulatuslikud, on hüperviisorite endi disainiga seotud ka tehnilisi piiranguid , mida tuleks algusest peale mõista, et vältida üllatusi tootmises või kõrge käideldavuse stsenaariumides.
Selge näide on virtuaalmasinate reaalajas migreerimine pesastatud virtualiseerimise abil . Praegu ei ole võimalik teostada primaarse hosti reaalajas migreerimist, kui selle virtuaalmasinad sisaldavad külalissüsteeme, mis sõltuvad aktiivsest pesastamisest. Microsoft dokumenteerib selle piirangu ja üldine soovitus on planeerida värskendusi või hosti liigutamist kontrollitud sulgemistega nendes keskkondades.
Ressursside tarbimise jälgimine mitmel tasandil nõuab kombineeritud strateegiat. Soovitatav on kasutada Hyper-V Managerit, jõudlusloendureid ja cmdlett-käske (nt Get-VM) ülemise taseme hostil ning samaaegselt kasutada sarnaseid tööriistu pesastatud hostis, et saada selge ülevaade koormuse jaotusest protsessori, mälu, võrgu ja salvestusruumi vahel.
Kui sisemine virtuaalmasin kaotab ootamatult võrguühenduse, on see tavaliselt sümptom tulemüürireeglite muudatustest, NAT-probleemidest või MAC-aadressi võltsimise sätete keelamisest ühel kaasatud adapteril. Kõigi tasemete kontrollimine, konfiguratsiooni kinnitamine ja mõjutatud võrguteenuste taaskäivitamine lahendab tavaliselt enamiku neist katkestustest.
Üldise parima tava kohaselt on enne pesastatud virtualiseerimise juurutamist soovitatav selgelt määratleda keskkonna eesmärk, kihtide arv, käivitatavate töökoormuste tüübid ja varunduspoliitika. See esialgne ülesehitus määrab, kas labori- või testikeskkond on pikas perspektiivis jätkusuutlik ega muutu keeruliseks ja hooldamatuks segaduseks.
Lühidalt öeldes võimaldab Hyper-V ja teiste platvormide pesastatud virtualiseerimine olemasolevast riistvarast palju rohkem kasu saada ning tohutu paindlikkusega seadistada labori-, testimis-, turbe- või IoT Edge'i stsenaariume, kui austatakse protsessori nõudeid, süsteemi versiooni ja võrgu konfiguratsiooni ning kõige sellega kaasneb hea jälgimis- ja varundusstrateegia.
