jos puhut vSphere-isännästä, saatat nähdä tai kuulla ihmisten viittaavan heihin nimellä ESXi, tai joskus ESX. Ei, joku ei vain pudota i, oli edellinen versio vSphere Hypervisor nimeltään ESX. Saatat myös kuulla ESX kutsutaan ESX classic tai ESX full form.
tänään haluan katsoa ESX vs ESXi ja nähdä, mitä eroa niillä on. Vielä tärkeämpää, haluan tarkastella joitakin syitä VMware muuttunut vSphere hypervisor arkkitehtuuri alkaa 2009.
Tässä oppaassa
mitä ESX on? (Elastinen taivas X)
ihmettelet mikä on ESX? ESX tulee sanoista Elastic Sky X. ESX on VMwaren bare metal hypervisor we all know and loven alkuperäinen nimi. Siitä virtualisointi todella sai alkunsa.
tämän päivän VMware-historian oppitunnilla aloitetaan ESX: llä. ESX oli VMwaren bare metal-hypervisorin alkuperäinen nimi. Vaikka nykypäivän ESXi-isäntien toiminnallisuus on hyvin samankaltainen (vaikkakin paljon kehittyneempi) ESX: n kanssa, on joitakin tärkeitä arkkitehtonisia eroja.
suurin ero oli ESX-palvelukonsoli. Itse asiassa ensimmäinen blogikirjoitukseni oli omistettu ESX-palvelukonsolille.
ajattele palvelukonsolia pienenä virtuaalikoneena, joka toimi vieraasi VMs: n vieressä ja tarjosi johdon pääsyn ESX-isännälle. Palvelukonsolin avulla voit kirjautua ESX: ään ja antaa esxcfg-komentoja komentorivillä palvelimen määrittämistä varten.
tässä on hyvin yksinkertainen kuvaus siitä, miltä se näytti:
komentoriville pääsyn lisäksi voit ladata ja asentaa ESX-palvelukonsoliin melkein minkä tahansa agentin, kuten agentit laitteistovalvontaan, varmuuskopiointiin tai no, mitä tahansa todella halusit.
myös ESX-johdon agentit asuivat täällä palvelukonsolissa.
huoltokonsoli puhui Vmkernelille, joka on käytännössä ESX-tai ESXi-isännän aivot.
ennen kuin puhutaan lisää Vmkernelistä, katsotaan, mikä muuttui ESXi: n myötä.
mitä ESXi on? (ESX integroitu)
Mietitkö mikä on ESXi? Se on VMwaren seuraavan sukupolven ESX hypervisor. ESXi tulee sanoista ESX integrated.
kun ESXi luotiin, VMware integroi palvelukonsolin toiminnot Vmkerneliin, näin:
jälleen, tämä on hyvin yksinkertainen kaavio, mutta voit nähdä, mitkä olivat suurimmat muutokset, joista suurin on palvelukonsolin poistaminen kokonaan ESXi-arkkitehtuurista.
niin paljon kuin vastustin tätä muutosta silloin, siinä oli järkeä monestakin syystä. Muista, ESXi tuli ulos vSphere 4 vuonna 2009, joka oli buumi virtualisointi. Kaikki virtualisoivat kaiken paikan päällä ja ajoivat TEHTÄVÄKRIITTISIÄ työkuormiaan ESX: llä.
tässä on pari syytä, miksi VMware on saattanut katsoa sopivaksi tehdä tämän muutoksen.
suorituskyky ja vakaus VMware ESXi
vaikka palvelukonsoli pystyi käyttämään vain 800 MB RAM-muistia (mikä voi olla merkittävää uskoa tai ei joissakin 2009-aikakauden isännissä), se voi silti vahingoittaa suorituskykyä ja vakautta.
Muistatko ne kolmannen osapuolen agentit, joista puhuimme? No tässä tapauksessa, huono agentti voisi tuoda sinulle ESX isäntä kirskuva pysäyttää, mikä ei ollut hyvä asia.
VMwaren Hypervisor-suojaus
syy siihen, että agentteja oli niin helppo kehittää ja asentaa palvelukonsoliin, oli se, että palvelukonsoli oli pohjimmiltaan linux-VM, joka istui ESX-isännälläsi ja jolla oli pääsy Vmkerneliin.
tämä tarkoittaa sitä, että palvelukonsoli piti paikata aivan kuten muutkin Linux-käyttöjärjestelmät, ja se oli altis mille tahansa Linux-palvelimelle.
Näetkö ongelman siinä ja tehtävän kriittisten työkuormien suorittamisessa? Täysin.
hankkiutumalla eroon tästä ”management VM: stä”, VMware pystyi pienentämään huomattavasti hypervisorinsa hyökkäyspintaa, jonka merkitys kasvoi adoption kasvaessa niin nopeasti.
virtualisoinnin hallinnan yksinkertaistaminen
integroimalla nämä hallintatoiminnot Vmkerneliin ESXi-arkkitehtuuri muuttui paljon yksinkertaisemmaksi kuin ESX. Kuten jokainen, joka on koskaan suunnitellut mitään, voi sanoa, mitä yksinkertaisempi sen parempi.
esimerkiksi kolmannen osapuolen agentin asentamisen sijaan laitteistoseurantaan VMware otti käyttöön yhteisen tietomallin tai CIM: n. Tämä mahdollisti laitteistotietojen helpon näkemisen vCenter-palvelimessa ja yhteisten laitteistohallintaympäristöjen käyttämisen vCenterin kautta.
jos haluat hyvän yleiskuvan CIM: stä, tutustu tähän blogiin VMwaren sivuilla. Se on vuodelta 2011 ja selittää ihmeellisesti tämän valtavan muutoksen ESX vs ESXi-arkkitehtuurissa.
tämä ei ainoastaan yksinkertaistanut hallintoa, vaan lisäsi koko ESXi: n vakautta ja turvallisuutta.
mikä on VMkernel?
olemme puhuneet paljon Vmkernelistä, joka on ESXi: n aivot.
haluan antaa sinulle yksinkertaisen yleiskuvan, jotta voit todella alkaa ymmärtää sen ominaisuuksia.
kuten sanoin, VMkernel on operaation aivot. Se käsittelee asioita, kuten resurssien aikataulutus, ja resurssien hallinta.
verkko-ja tallennuspinot ovat myös Vmkernelissä, ja ESXi: n isäntälaite-ajurit hoitaa myös VMkernel.
Mitä ovat Vmkernelin Portit?
ESX-aikoina yhdistimme isäntämme erityisellä palvelukonsolin portilla. Tämä määritettiin ESX: n asennusprosessin aikana, jotta voisimme muodostaa yhteyden isäntiimme jatkaaksemme niiden konfigurointia ja hallintaa.
ESXi: stä alkaen määritimme VMkernel-portin hallintaa varten. Nykyään VMkernel-portit palvelevat monia muitakin tarkoituksia kuin vain hallintaa, sillä vSphere-tuote on kehittynyt valtavasti.
kun ESXi ensi kerran debytoi, VMkernel-portit oli määritetty hallinta -, vMotion-ja IP-pohjaista tallennustilaa varten, jos sitä käytettiin. Jos määrität VMkernel-porttia tallennusta varten, et yksinkertaisesti kerro vspherelle, että se on tarkoitettu edellä lueteltuihin erikoistarkoituksiin. Tämä johtuu siitä, että se menee yli oletuksena TCP / IP pino vSphere.
VMkernel-portteja oli tietysti olemassa ennen ESXi: tä, mutta ellet käyttänyt IP-tallennustilaa tai vmotionia (joka alkuaikoina uskoi tai ei ollut yleisesti käytetty), et luultavasti ollut koskaan määrittänyt VMkernel-porttia ennen.
tänään, kuten näette, VMkernel-porttien käyttöön on monia muitakin sovelluksia. Voit lukea niistä lisää VMwaren VMkernel Networking Guide-oppaasta.
ESX vs ESXi ei ole edes Vertailu
kun ESXi ilmestyi ensimmäisen kerran, monet vspheren ylläpitäjät, minä mukaan lukien, olivat pakkomielteisiä vertaamaan ESX vs ESXi. Olimme vain niin tottuneita palvelukonsoliin ja vSphere-toimintaamme sen ympärillä, että se oli valtava paradigman muutos.
muistan käyttäneeni erityisesti palvelukonsolin työkalua suuren ESX-ympäristöni hallintaan. Ennen ESXi, asioita kuten PowerCLI ei laajalti käytetty, koska ei ollut mitään syytä, käytit vain esxcfg komentoja palvelukonsolissa.
VMware Infrastructure Toolkit (Windowsille), tai Vi Toolkit oli Powerclin edeltäjä, julkaistiin vasta heinäkuussa 2008. Jälkikäteen, voit nähdä VMware asettaa vaiheessa tulevaisuudessa niiden Alustan, minun vakuuttaa suorituskykyä, turvaaminen codebase, ja virtaviivaistaa hallittavuutta.
Let ’s face it, ESX as we know it wasn’ t going to support the continue upgrades of vSphere. VMware joutui ryhtymään toimiin todistaakseen tuotteensa tulevaa varten.
vSphere 4: ssä VMware tarjosi sekä ESX: ää että ESXi: tä, jotta asiakkaat voisivat vähitellen tehdä muutoksen, mutta kun vSphere 5 tuli vuonna 2011, ESXi: stä tuli VMware vSphere hypervisor.
näihin aikoihin nähtiin myös työkalujen, kuten Auto Deployn, syntyvän, ja PowerCLI alkoi muuttua ahdetuksi.
myös ESXi: lle ja vcenterille tuli yhä enemmän ominaisuuksia. Jos vertaisit ESX 4.1: tä, joka oli viimeinen ESX full form-versio ESXi 6.7: ään, luultavasti vain nauraisit ESX: lle, jos ensimmäinen vSphere-versiosi olisi 6 tai korkeampi.
vaikka se oli selvästi huippua ilmestyessään, ESX vs ESXi-arkkitehtuuriin tehdyt muutokset loivat perustan vspheren jatkuvalle kehitykselle ja kasvulle. Ilman tätä siirtymistä ESXi: hen emme olisi tässä tilanteessa.