om du pratar om en vSphere-värd kan du se eller höra människor hänvisa till dem som ESXi, eller ibland ESX. Nej, någon släppte inte bara i, det fanns en tidigare version av vSphere Hypervisor som heter ESX. Du kan också höra ESX kallas ESX classic eller ESX full form.
idag vill jag ta en titt på ESX vs ESXi och se vad skillnaden är mellan dem. Ännu viktigare, jag vill titta på några av anledningarna till att VMware ändrade vSphere hypervisor-arkitekturen från och med 2009.
i den här guiden
vad är ESX? (Elastic Sky X)
undrar du vad som är ESX? ESX står för Elastic Sky X. ESX är vad VMwares bare metal hypervisor vi alla känner och älskar ursprungligen kallades. Det är verkligen där virtualisering började.
för dagens VMware-historielektion kommer vi att börja med ESX. ESX var vad VMwares bare metal hypervisor ursprungligen kallades. Medan funktionaliteten hos dagens ESXi-värdar är mycket lik (men mycket mer avancerad) till ESX, finns det några viktiga arkitektoniska skillnader.
huvudskillnaden var ESX-servicekonsolen. Faktum är att mitt första blogginlägg någonsin var tillägnad ESX service console.
Tänk på servicekonsolen som en liten virtuell maskin som sprang bredvid dina gäst-VM och gav hanteringsåtkomst till ESX-värden. Servicekonsolen tillät dig att logga in på ESX och utfärda esxcfg-kommandon på en kommandorad för att konfigurera din värd.
här är en mycket enkel skildring av hur det såg ut:
förutom att komma åt kommandoraden kan du ladda ner och installera nästan vilken agent du ville ha i ESX service console, som agenter för hårdvaruövervakning, säkerhetskopiering eller vad du verkligen ville ha.
ESX-hanteringsagenterna bodde också här i servicekonsolen.
servicekonsolen pratade med VMkernel, som i grunden är hjärnan hos din ESX-eller ESXi-värd.
innan vi pratar mer om VMkernel, låt oss ta en titt på vad som förändrats med ESXi.
Vad är ESXi? (ESX integrerad)
undrar vad är ESXi? Det är nästa generation av VMwares ESX hypervisor. ESXi står för ESX integrated.
när ESXi skapades integrerade VMware servicekonsolfunktionen i VMkernel, så här:
återigen är detta ett mycket enkelt diagram men du kan se vad de stora förändringarna var, den största som eliminerar servicekonsolen helt från ESXi-arkitekturen.
så mycket som jag motstod denna förändring vid den tiden, var det meningsfullt av ett antal skäl. Kom ihåg att ESXi kom ut med vSphere 4 2009, vilket var virtualiseringsboomen. Alla virtualiserade allt på plats och körde sina uppdragskritiska arbetsbelastningar på ESX.
här är några anledningar till att VMware kan ha sett det lämpligt att göra denna förändring.
prestanda och stabilitet för VMware ESXi
medan servicekonsolen bara kunde använda upp till 800 MB RAM (vilket kan vara betydande tro det eller inte i några av värdarna i 2009-eran), kan det fortfarande orsaka kaos med prestanda och stabilitet.
kom ihåg de tredjepartsagenter vi pratade om? Tja i det här fallet kan en dålig agent ge dig ESX-värd till ett skrikande stopp, vilket inte var bra.
VMwares Hypervisor Security
anledningen till att det var så lätt att utveckla och installera agenter på servicekonsolen var att servicekonsolen i grunden var en linux VM som satt på din ESX-värd med tillgång till VMkernel.
det betyder att servicekonsolen måste patchas precis som alla andra Linux-operativsystem, och var mottaglig för allt som en Linux-server var.
ser du ett problem med det och kör uppdragskritiska arbetsbelastningar? Helt.
genom att bli av med denna ”management VM” kunde VMware kraftigt minska attackytan på deras hypervisor, vilket blev allt viktigare när antagandet växte så snabbt.
förenkling av virtualiseringshantering
genom att integrera dessa hanteringsfunktioner i VMkernel blev ESXi-arkitekturen mycket enklare än ESX. Som alla som någonsin har byggt något kan berätta för dig, desto enklare desto bättre.
till exempel, istället för att installera en 3: e parts agent för hårdvaruövervakning, introducerade VMware Common Information Model eller CIM. Detta gjorde det möjligt att enkelt se hårdvarudata i vCenter server och vanliga hårdvaruhanteringsplattformar för att komma åt den via vCenter.
för en bra översikt över CIM, se till att kolla in den här bloggen på VMwares webbplats. Det är från 2011, och underbart förklarar denna enorma förändring i ESX vs ESXi arkitektur.
inte bara detta förenkla hanteringen, men läggs till stabilitet och säkerhet ESXi som helhet.
Vad är VMkernel?
vi har pratat mycket om VMkernel, som är hjärnan i ESXi.
jag vill ge dig en enkel översikt så att du verkligen kan börja förstå dess kapacitet.
som jag sa är VMkernel hjärnan i operationen. Den hanterar saker som resursplanering och resurshantering.
nätverks-och lagringsstaplarna finns också i VMkernel, och Esxis värddrivrutiner hanteras också av VMkernel.
Vad är VMkernel-portar?
tillbaka i ESX-dagarna anslöt vi till våra värdar med en speciell servicekonsolport. Detta konfigurerades under installationsprocessen för ESX, så vi kunde ansluta till våra värdar för att fortsätta konfigurera dem och hantera dem.
från och med ESXi konfigurerade vi en VMkernel-port för hantering. Idag tjänar VMkernel-portar många fler syften än bara hantering, eftersom vSphere-produkten har avancerat enormt.
när ESXi först debuterade konfigurerades VMkernel-portar för hantering, vMotion och IP-baserad lagring om du använde den. Om du konfigurerar en VMkernel-port för lagring, säger du helt enkelt inte till vSphere att det är för ett speciellt ändamål som de som anges ovan. Det beror på att det går över standard TCP/IP-stacken i vSphere.
VMkernel-portar fanns naturligtvis före ESXi, men om du inte använde IP-lagring eller vMotion (som i början tror det eller inte var vanligt förekommande), hade du förmodligen aldrig konfigurerat en VMkernel-port tidigare.
idag, som du kan se finns det många fler applikationer för att använda VMkernel-portar. Du kan läsa mer om dem i VMkernel-Nätverksguiden från VMware.
ESX vs ESXi är inte ens en jämförelse
när ESXi först kom ut, var många vSphere-administratörer, inklusive mig själv, besatta av att jämföra ESX vs ESXi. Vi var bara så vana vid servicekonsolen och våra vSphere-operationer runt den att det var ett enormt paradigmskifte.
jag kommer ihåg att jag specifikt använde ett verktyg i servicekonsolen för att hantera min stora ESX-miljö. Tillbaka före ESXi användes saker som PowerCLI inte i stor utsträckning eftersom det inte fanns någon anledning att, du använde bara esxcfg-kommandona i servicekonsolen.
VMware Infrastructure Toolkit (för Windows), eller vi Toolkit var föregångaren till PowerCLI släpptes inte ens förrän i juli 2008. I efterhand kunde du se VMware sätta scenen för framtiden för sin plattform, min försäkra prestanda, säkra kodbasen och effektivisera hanterbarheten.
Låt oss möta det, ESX som vi visste att det inte skulle stödja vSphere fortsätt uppåt. VMware var tvungen att vidta åtgärder för att framtidssäkra sin produkt för vad som skulle komma.
i vSphere 4 erbjöd VMware både ESX och ESXi för att tillåta kunder att gradvis göra skiftet, men när vSphere 5 kom 2011 blev ESXi VMware vSphere hypervisor.
det var runt denna tid vi såg också verktyg som Auto Deploy dyka upp, och PowerCLI börjar bli supercharged.
vi såg också fler och fler funktioner kommer till både ESXi och vCenter. Om du jämförde ESX 4.1, som var den senaste versionen av ESX full form till ESXi 6.7 skulle du förmodligen bara skratta åt ESX om din första version av vSphere var 6 eller högre.
även om det var klart framkant när det först kom ut, de ändringar som gjorts i ESX vs ESXi arkitektur lagt grunden för vSphere fortsatta framsteg och tillväxt. Utan denna övergång till ESXi skulle vi helt enkelt inte vara där vi är idag.