hvis du taler om en vSphere-vært, kan du se eller høre folk henvise til dem som Essi, eller nogle gange ESS. Nej, nogen droppede ikke bare i, der var en tidligere version af vSphere Hypervisor kaldet Esch. Du kan også høre ESC kaldet ESC classic eller ESC full form.
i dag vil jeg tage et kig på ESS vs Essi og se, hvad forskellen er mellem dem. Endnu vigtigere vil jeg se på nogle af grundene til, at vSphere hypervisor-arkitekturen ændrede vSphere hypervisor-arkitekturen, der begyndte i 2009.
i denne vejledning
Hvad er ESC? (Elastisk himmel)
spekulerer på, hvad er ESC? Er, hvad VM ‘ s bare metal hypervisor, vi alle kender og elsker, oprindeligt blev kaldt. Det er virkelig her virtualisering kom i gang.
til dagens historietime skal vi starte med ESC. Det var det, der oprindeligt blev kaldt hypervisor. Mens funktionaliteten af nutidens essi værter er meget ens (selvom meget mere avanceret) til ESC, der er nogle vigtige arkitektoniske forskel.
den største forskel var ESC-servicekonsollen. Faktisk, mit første blogindlæg nogensinde var dedikeret til ess servicekonsol.
tænk på servicekonsollen som en lille virtuel maskine, der kørte ved siden af din gæst VM ‘ er og gav ledelsen adgang til værten. Servicekonsollen gjorde det muligt for dig at logge ind og udstede escfg-kommandoer på en kommandolinje for at konfigurere din vært.
her er en meget enkel skildring af, hvordan det så ud:
igen, dette er en meget enkel diagram, men du kan se, hvad de store ændringer var, den største, som er at fjerne tjenesten konsol helt fra Esch arkitektur.
så meget som jeg modstod denne ændring på det tidspunkt, gav det mening af en række grunde. Husk, at Essi kom ud med vSphere 4 i 2009, hvilket var boom af virtualisering. Alle virtualiserede alt på stedet og kørte deres missionskritiske arbejdsbyrder på ESC.
her er et par grunde til, at
ydelse og stabilitet
mens servicekonsollen kun kunne bruge op til 800 MB RAM (hvilket kunne være vigtigt tro det eller ej i nogle af værterne i 2009-æraen), kunne det stadig skabe kaos med ydeevne og stabilitet.
Husk de tredjepartsagenter, vi talte om? I dette tilfælde kunne en dårlig agent bringe dig til en skrigende standsning, hvilket ikke var en god ting.
‘ s Hypervisor Security
grunden til, at det var så nemt at udvikle og installere agenter på servicekonsollen, var, at servicekonsollen dybest set var en VM-enhed, der sad på din vært med adgang til VMkernel.
dette betyder, at servicekonsollen skulle lappes ligesom ethvert andet operativsystem og var modtagelig for alt, hvad en server var.
se et problem med det og kører missionskritiske arbejdsbelastninger? Helt.
ved at slippe af med denne “Management VM” var VM i stand til i høj grad at reducere angrebets overflade på deres hypervisor, hvilket blev stadig vigtigere, da adoptionen voksede så hurtigt.
forenkling af Virtualiseringsstyring
ved at integrere disse styringsfunktioner i VMkernel blev Essi-arkitekturen meget enklere end ESC. Som enhver, der nogensinde har architected noget kan fortælle dig, jo enklere jo bedre.
for eksempel, i stedet for at installere en 3.parts agent til overvågning af udstyr, introducerede
For et godt overblik over CIM, skal du sørge for at tjekke denne blog på hjemmesiden. Det er fra 2011, og forklarer vidunderligt dette enorme skift i arkitektur.
dette forenklede ikke kun ledelsen, men tilføjede stabiliteten og sikkerheden for Essi som helhed.
Hvad er VMkernel?
vi har talt meget om VMkernel, som er hjernen hos Essi.
jeg vil gerne give dig et simpelt overblik, så du virkelig kan begynde at forstå dens evner.
som jeg sagde, Er VMkernel hjernen i operationen. Det håndterer ting som ressourceplanlægning og ressourcestyring.
netværk og opbevaring stakke er også i VMkernel, og Essis værter enhedsdrivere håndteres også af VMkernel.
Hvad er VMkernel Porte?
tilbage i dagene sluttede vi os til vores værter med en speciel servicekonsolport. Dette blev konfigureret under installationsprocessen, så vi kunne oprette forbindelse til vores værter for at fortsætte med at konfigurere dem og administrere dem.
vi konfigurerede en VMkernel-port til styring. I dag tjener VMkernel-porte mange flere formål end bare styring, da vSphere-produktet er avanceret enormt.
da VMkernel-porte først debuterede, blev VMkernel-porte konfigureret til styring, VMotion og IP-baseret opbevaring, hvis du brugte det. Hvis du konfigurerer en VMkernel-port til opbevaring, fortæller du simpelthen ikke vSphere, at det er til et specielt formål som dem, der er anført ovenfor. Det skyldes, at det går over standard TCP/IP-stakken i vSphere.
VMkernel-porte eksisterede selvfølgelig før Essi, men medmindre du brugte IP-lager eller vMotion (som i de tidlige dage troede det eller ej ikke var almindeligt anvendt), havde du sandsynligvis aldrig konfigureret en VMkernel-port før.
i dag, som du kan se, er der mange flere applikationer til brug af VMkernel-porte. Du kan læse mere om dem i Vores Netværksvejledning.
Esch vs Esch er ikke engang en sammenligning
da Esch først kom ud, var mange vSphere-administratorer, inklusive mig selv, besat af at sammenligne Esch vs Esch. Vi var lige så vant til servicekonsollen og vores vSphere-operationer omkring den, at det var et enormt paradigmeskift.
jeg husker, at jeg specifikt brugte et værktøj i servicekonsollen til at styre mit store miljø. Tilbage før esci blev ting som
vi-værktøjssættet var forgængeren til Microsoft blev ikke engang udgivet før i juli 2008. I bakspejlet, du kunne se VM sætte scenen for fremtiden for deres platform, Min sikre ydeevne, sikring af kodebasen, og strømlining håndterbarhed.
lad os se det i øjnene, da vi vidste, at det ikke ville understøtte vSphere ‘ s fortsatte opadgående bane. VM måtte tage skridt til at fremtidssikre deres produkt for, hvad der skulle komme.
i vSphere 4 tilbød VM at give kunderne mulighed for gradvist at foretage skiftet, men da vSphere 5 Kom i 2011, blev VM vSphere hypervisor.
det var omkring dette tidspunkt, at vi også så værktøjer som Auto Deploy dukke op, og Magtcli begynder at blive supercharged.
vi så også flere og flere funktioner komme til både esci og vCenter. Hvis du sammenlignede ESC 4.1, som var den sidste version af ESC full form til 6.7, ville du nok bare grine af ESC, hvis din første version af vSphere var 6 eller højere.
mens det klart var banebrydende, da det først kom ud, satte ændringerne i Esch vs Essi-arkitekturen scenen for vSphere ‘ s fortsatte fremskridt og vækst. Uden dette skift ville vi simpelthen ikke være, hvor vi er i dag.