ha egy vSphere gazdagépről beszélünk, akkor láthatjuk vagy hallhatjuk, hogy az emberek ESXi-nek vagy néha ESX-nek nevezik őket. Nem, valaki nem csak eldobta az i-t, hanem a vSphere Hypervisor korábbi verziója is volt, ESX néven. Azt is hallani ESX nevezik ESX classic vagy ESX teljes formában.
ma szeretnék egy pillantást vetni az ESX vs ESXi-re, és megnézni, mi a különbség közöttük. Ennél is fontosabb, hogy néhány okot szeretnék megvizsgálni, amelyek miatt a VMware megváltoztatta a vSphere hypervisor architektúrát 2009-ben.
ebben az útmutatóban
mi az ESX? (Elastic Sky X)
kíváncsi, mi az ESX? Az ESX a VMware we all know and love csupasz fém hipervizorának, az Elastic Sky X-nek a neve. Itt kezdődött a virtualizáció.
a mai VMware történelem leckében az ESX-szel kezdjük. Az ESX volt az, amit a VMware csupasz fém hipervizorának eredetileg hívtak. Míg a mai ESXi gazdagépek funkcionalitása nagyon hasonló (bár sokkal fejlettebb) az ESX-hez, van néhány fontos építészeti különbség.
a fő különbség az ESX szervizkonzol volt. Valójában az első blogbejegyzésemet az ESX szervizkonzolnak szenteltem.
gondoljon a szervizkonzolra úgy, mint egy kis virtuális gépre, amely a Vendég virtuális gépek mellett futott, és felügyeleti hozzáférést biztosított az ESX gazdagéphez. A szervizkonzol lehetővé tette az ESX-be való bejelentkezést, és az esxcfg parancsok kiadását egy parancssorban a gazdagép konfigurálásához.
itt van egy nagyon egyszerű ábrázolása, amit úgy nézett ki, mint:
a parancssor elérése mellett szinte bármilyen ügynököt letölthet és telepíthet az ESX szervizkonzolba, mint például a hardverfelügyelet, a biztonsági mentés vagy bármi, amit igazán akart.
az ESX menedzsment ügynökök is itt éltek a szervizkonzolban.
a szervizkonzol beszélt a Vmkernellel, amely alapvetően az ESX vagy ESXi gazdagép agya.
mielőtt többet beszélnénk a Vmkernelről, nézzük meg, mi változott az ESXi-vel.
mi az ESXi? (ESX integrált)
kíváncsi, mi az ESXi? Ez a VMware ESX hypervisor következő generációja. Az ESXi az ESX integrated rövidítése.
amikor az ESXi létrejött, a VMware integrálta a szervizkonzol funkcionalitását a VMkernel-be, így:
ez ismét egy nagyon egyszerű diagram, de láthatja, hogy mi volt a legfontosabb változás, a legnagyobb, amely teljesen megszünteti a szervizkonzolt az ESXi architektúrából.
bármennyire is ellenálltam ennek a változásnak abban az időben, számos okból volt értelme. Ne feledje, hogy az ESXi a vSphere 4-rel jött ki 2009-ben, ami a virtualizáció fellendülése volt. Mindenki mindent virtualizált a helyszínen, és a kritikus fontosságú munkaterheléseket az ESX-en futtatta.
íme néhány ok, amiért a VMware alkalmasnak találta ezt a változtatást.
teljesítmény és stabilitás a VMware ESXi számára
bár a szervizkonzol legfeljebb 800 MB RAM-ot tudott használni (ami jelentős lehet A 2009-es korszak néhány gazdagépében), még mindig pusztítást okozhat a teljesítményben és a stabilitásban.
emlékszel azokra a harmadik fél ügynökökre, akikről beszéltünk? Nos, ebben az esetben egy rossz ügynök viheti az ESX host-ot egy csikorgó megállásra, ami nem volt jó dolog.
a VMware Hypervisor Security
az ok, amiért ilyen egyszerű volt az ügynökök fejlesztése és telepítése a szervizkonzolon, az volt, hogy a szervizkonzol alapvetően egy linux virtuális gép volt, amely az ESX gazdagépén ült, hozzáféréssel a VMkernel-hez.
ez azt jelenti, hogy a szervizkonzolt ugyanúgy kellett javítani, mint bármely más Linux operációs rendszert, és mindenre érzékeny volt, ami egy Linux szerver volt.
problémát lát ezzel és a kritikus fontosságú feladatok futtatásával kapcsolatban? Abszolút.
azáltal, hogy megszabadult ettől a “menedzsment virtuális géptől”, a VMware képes volt nagymértékben csökkenteni hipervizoruk támadási felületét, amely egyre fontosabbá vált, mivel az elfogadás ilyen gyorsan növekedett.
a virtualizációs menedzsment egyszerűsítése
ezeknek a menedzsment funkcióknak a Vmkernelbe történő integrálásával az ESXi architektúra sokkal egyszerűbbé vált, mint az ESX. Mint bárki, aki valaha is épített valamit, elmondhatja neked, minél egyszerűbb, annál jobb.
például a 3rd party agent telepítése helyett a hardverfigyeléshez a VMware bevezette a közös információs modellt vagy a CIM-et. Ez lehetővé tette, hogy a hardveradatok könnyen láthatók legyenek a vCenter szerveren, és a közös hardverkezelő platformok hozzáférjenek a vCenter-en keresztül.
a CIM nagyszerű áttekintéséhez feltétlenül nézze meg ezt a blogot a VMware webhelyén. 2011-ből származik, és csodálatosan megmagyarázza ezt a hatalmas változást az ESX vs ESXi architektúrában.
ez nemcsak egyszerűsítette a menedzsmentet, hanem egészítette ki az ESXi stabilitását és biztonságát.
mi a VMkernel?
sokat beszéltünk a Vmkernelről, amely az ESXi agya.
szeretnék egy egyszerű áttekintést adni, hogy valóban megérthesse képességeit.
mint mondtam, a VMkernel a művelet agya. Olyan dolgokat kezel, mint az erőforrás-ütemezés és az erőforrás-kezelés.
a hálózati és tárolási stackek szintén a VMkernel-ben vannak, és az ESXi hosts eszközmeghajtóit is a VMkernel kezeli.
mik azok a VMkernel portok?
vissza az ESX nap, mi csatlakozik a házigazdák egy speciális szolgáltatás konzol port. Ezt az ESX telepítési folyamata során konfiguráltuk, így csatlakozhattunk a házigazdáinkhoz, hogy továbbra is konfigurálhassuk és kezelhessük őket.
az ESXi – től kezdve konfiguráltunk egy VMkernel portot a kezeléshez. Ma a VMkernel portok sokkal több célt szolgálnak, mint pusztán a menedzsment, mivel a vSphere termék óriási fejlődésen ment keresztül.
amikor az ESXi először debütált, a VMkernel portokat a menedzsment, a vMotion és az IP alapú tároláshoz konfigurálták, ha használta. Ha VMkernel portot konfigurál tárolásra, akkor egyszerűen nem mondja el a vSphere-nek, hogy a fent felsoroltakhoz hasonló speciális célra szolgál. Ez azért van, mert átmegy az alapértelmezett TCP/IP veremen a vSphere-ben.
a VMkernel portok természetesen léteztek az ESXi előtt, de hacsak nem használt IP-tárolót vagy vMotion-t (amelyek az első napokban hiszik vagy sem, nem voltak általánosan használva), valószínűleg még soha nem konfigurálta a VMkernel portot.
ma, mint láthatja, sokkal több alkalmazás létezik a VMkernel portok használatára. Tudjon meg többet róluk a VMware VMkernel hálózati útmutatójában.
ESX vs ESXi még csak nem is összehasonlítás
amikor ESXi először jött ki, sok vSphere rendszergazdák, magam is, megszállottja összehasonlításával ESX vs ESXi. Annyira hozzászoktunk a szervizkonzolhoz és a körülötte lévő vSphere műveletekhez, hogy ez egy hatalmas paradigmaváltás volt.
emlékszem, hogy kifejezetten a szervizkonzol egyik eszközét használtam a nagy ESX környezetem kezelésére. Az ESXi előtt az olyan dolgokat, mint a PowerCLI, nem használták széles körben, mert nem volt ok rá, csak az esxcfg parancsokat használta a szervizkonzolban.
a VMware Infrastructure Toolkit (Windows), vagy a VI Toolkit volt az elődje PowerCLI nem is adták ki, amíg július 2008. Utólag láthatta, hogy a VMware előkészíti a platform jövőjének színpadát, biztosítja a teljesítményt, biztosítja a kódbázist és egyszerűsíti a kezelhetőséget.
nézzünk szembe a tényekkel, Az ESX, mivel tudtuk, hogy nem fogja támogatni a vSphere folytatódó felfelé irányuló pályáját. A VMware-nek lépéseket kellett tennie annak érdekében, hogy termékét a jövőben bizonyítsa.
a vSphere 4-ben a VMware mind az ESX-et, mind az ESXi-t felajánlotta, hogy az ügyfelek fokozatosan elvégezhessék a váltást, de amikor a vSphere 5 2011-ben jött, az ESXi lett a VMware vSphere hypervisor.
ebben az időben láttunk olyan eszközöket is, mint az automatikus telepítés, és a PowerCLI kezdett feltöltődni.
azt is láttuk, hogy egyre több funkció érkezik mind az ESXi, mind a vCenter számára. Ha összehasonlította az ESX 4.1-et, amely az ESX full form utolsó verziója volt az ESXi 6.7-hez, akkor valószínűleg csak nevetne az ESX-en, ha a vSphere első verziója 6 vagy annál magasabb volt.
bár egyértelműen élvonalbeli volt, amikor először megjelent, az ESX vs ESXi architektúrán végrehajtott változtatások megalapozták a vSphere folyamatos fejlődését és növekedését. Az ESXi-re való váltás nélkül egyszerűen nem lennénk ott, ahol ma vagyunk.