ESX vs ESXi, A VMware History Lesson

Se stai parlando di un host vSphere, potresti vedere o sentire persone che si riferiscono a loro come ESXi, o talvolta ESX. No, qualcuno non ha semplicemente lasciato cadere la i, c’era una versione precedente dell’Hypervisor vSphere chiamato ESX. Si può anche sentire ESX indicato come ESX classic o ESX forma completa.

Oggi voglio dare un’occhiata a ESX vs ESXi e vedere qual è la differenza tra loro. Ancora più importante, voglio guardare alcuni dei motivi per cui VMware ha cambiato l’architettura vSphere hypervisor a partire dal 2009.

In questa guida

Che cos’è ESX? (Elastico Sky X)

Chiedendo che cosa è ESX? ESX è l’acronimo di Elastic Sky X. ESX è ciò che VMware hypervisor bare metal che tutti conosciamo e amiamo è stato originariamente chiamato. È davvero dove è iniziata la virtualizzazione.

Per la lezione di VMware history di oggi, inizieremo con ESX. ESX era ciò che VMware hypervisor bare metal è stato originariamente chiamato. Mentre la funzionalità degli host ESXi di oggi è molto simile (anche se molto più avanzata) a ESX, ci sono alcune importanti differenze architettoniche.

La differenza principale era la console di servizio ESX. In effetti, il mio primo post sul blog è stato dedicato alla console di servizio ESX.

Pensate alla Service console come a una piccola macchina virtuale che correva accanto alle VM guest e forniva l’accesso di gestione all’host ESX. La console di servizio consente di accedere a ESX ed emettere comandi esxcfg su una riga di comando per configurare l’host.

Ecco una rappresentazione molto semplice di come sembrava:

esx vs esxi architecture

Oltre ad accedere alla riga di comando, è possibile scaricare e installare quasi tutti gli agenti desiderati nella console di servizio ESX, come gli agenti per il monitoraggio hardware, il backup o, beh, tutto ciò che si desidera davvero.

Anche gli agenti di gestione ESX vivevano qui nella console di servizio.

La console di servizio ha parlato con VMkernel, che è fondamentalmente il cervello del tuo host ESX o ESXi.

Prima di parlare di più del VMkernel, diamo un’occhiata a cosa è cambiato con ESXi.

Che cos’è ESXi? (ESX integrato)

Chiedendo che cosa è ESXi? È la prossima generazione di hypervisor ESX di VMware. ESXi sta per ESX integrato.

Quando è stato creato ESXi, VMware ha integrato la funzionalità della service console nel VMkernel, in questo modo:esxi vs esx architecture Ancora una volta, questo è un diagramma molto semplice ma puoi vedere quali sono stati i principali cambiamenti, il più grande che sta eliminando completamente la service console dall’architettura ESXi.

Per quanto ho resistito a questo cambiamento in quel momento, aveva senso per una serie di motivi. Ricordate, ESXi è uscito con vSphere 4 nel 2009, che è stato il boom della virtualizzazione. Tutti stavano virtualizzando tutto nel sito e eseguendo i loro carichi di lavoro mission critical su ESX.

Ecco un paio di motivi per cui VMware potrebbe aver ritenuto opportuno apportare questa modifica.

Prestazioni e stabilità per VMware ESXi

Mentre la console di servizio poteva utilizzare solo fino a 800 MB di RAM (che potrebbe essere significativo che ci crediate o no in alcuni degli host dell’era 2009), potrebbe comunque devastare le prestazioni e la stabilità.

Ricordate quegli agenti di terze parti di cui abbiamo parlato? Beh, in questo caso, un cattivo agente potrebbe portare ESX host ad una battuta d’arresto stridente, che non era una buona cosa.

Hypervisor Security di VMware

Il motivo per cui era così facile sviluppare e installare agenti sulla service console era perché la service console era fondamentalmente una VM linux seduta sul tuo host ESX con accesso al VMkernel.

Ciò significa che la console di servizio doveva essere patchata come qualsiasi altro sistema operativo Linux ed era suscettibile a qualsiasi cosa fosse un server Linux.

Vedi un problema con questo e l’esecuzione di carichi di lavoro mission critical? Assolutamente.

Eliminando questa “VM di gestione”, VMware è stata in grado di ridurre notevolmente la superficie di attacco del proprio hypervisor, che stava diventando sempre più importante man mano che l’adozione cresceva così rapidamente.

Semplificazione della gestione della virtualizzazione

Integrando queste funzioni di gestione nel VMkernel, l’architettura ESXi è diventata molto più semplice di ESX. Come chiunque abbia mai architettato qualcosa può dirti, più semplice è meglio è.

Ad esempio, invece di installare un agente di terze parti per il monitoraggio hardware, VMware ha introdotto il Common Information Model o CIM. Ciò ha permesso ai dati hardware di essere facilmente visibili in vCenter server e alle piattaforme di gestione hardware comuni di accedervi tramite vCenter.

Per una grande panoramica del CIM, assicuratevi di controllare questo blog sul sito di VMware. È del 2011 e spiega meravigliosamente questo enorme cambiamento nell’architettura ESX vs ESXi.

Non solo questo ha semplificato la gestione, ma ha aggiunto alla stabilità e alla sicurezza di ESXi nel suo complesso.

Che cos’è il VMkernel?

Abbiamo parlato molto del VMkernel, che è il cervello di ESXi.

Voglio darvi una semplice panoramica in modo da poter davvero cominciare a capire le sue capacità.

Come ho detto, il VMkernel è il cervello dell’operazione. Gestisce cose come la pianificazione delle risorse e la gestione delle risorse.

Anche gli stack di rete e di archiviazione sono presenti nel VMkernel e anche i driver di periferica host di ESXi sono gestiti dal VMkernel.

Cosa sono le porte VMkernel?

Ai tempi di ESX, ci siamo collegati ai nostri host con una porta console di servizio speciale. Questo è stato configurato durante il processo di installazione di ESX, in modo da poter connettersi ai nostri host per continuare a configurarli e gestirli.

A partire da ESXi, abbiamo configurato una porta VMkernel per la gestione. Oggi, le porte VMkernel servono a molti più scopi della semplice gestione, poiché il prodotto vSphere è avanzato enormemente.

Porta VMkernel

Al debutto di ESXi, le porte VMkernel erano configurate per la gestione, vMotion e lo storage basato su IP se lo si utilizzava. Se stai configurando una porta VMkernel per l’archiviazione, semplicemente non dici a vSphere che è per uno scopo speciale come quelli elencati sopra. Questo perché va oltre lo stack TCP/IP predefinito in vSphere.

Le porte VMkernel ovviamente esistevano prima di ESXi, ma a meno che non si stesse utilizzando lo storage IP o vMotion (che nei primi giorni ci crediate o no non erano comunemente usati), probabilmente non si era mai configurato prima una porta VMkernel.

Oggi, come puoi vedere, ci sono molte più applicazioni per l’utilizzo delle porte VMkernel. È possibile leggere di più su di loro nella Guida VMkernel Networking da VMware.

ESX vs ESXi Non è nemmeno un confronto

Quando ESXi è uscito per la prima volta, molti amministratori di vSphere, me compreso, erano ossessionati dal confronto tra ESX e ESXi. Eravamo così abituati alla console di servizio e alle nostre operazioni vSphere attorno ad essa che è stato un enorme cambiamento di paradigma.

Ricordo di aver utilizzato specificamente uno strumento nella console di servizio per gestire il mio grande ambiente ESX. Prima di ESXi, cose come PowerCLI non erano ampiamente utilizzate perché non c’era motivo di farlo, hai appena usato i comandi esxcfg nella console di servizio.

Il VMware Infrastructure Toolkit (per Windows), o il Toolkit VI era il predecessore di PowerCLI non è stato rilasciato fino al luglio del 2008. Con il senno di poi, si poteva vedere VMware preparando il terreno per il futuro della loro piattaforma, il mio garantire le prestazioni, la protezione della base di codice, e razionalizzazione gestibilità.

Ammettiamolo, ESX come sapevamo non avrebbe supportato la traiettoria continua verso l’alto di vSphere. VMware ha dovuto adottare misure a prova di futuro il loro prodotto per quello che doveva venire.

In vSphere 4, VMware ha offerto sia ESX che ESXi per consentire ai clienti di effettuare gradualmente il passaggio, ma quando vSphere 5 è arrivato nel 2011, ESXi è diventato L’hypervisor VMware vSphere.

E ‘ stato in questo periodo abbiamo anche visto strumenti come Auto Deploy emergere, e PowerCLI cominciano a diventare sovralimentato.

Abbiamo anche visto sempre più funzionalità sia per ESXi che per vCenter. Se hai confrontato ESX 4.1, che era l’ultima versione di ESX full form con ESXi 6.7, probabilmente rideresti di ESX se la tua prima versione di vSphere fosse 6 o superiore.

Mentre era chiaramente all’avanguardia quando è uscito per la prima volta, le modifiche apportate all’architettura ESX vs ESXi hanno posto le basi per il continuo progresso e la crescita di vSphere. Senza questo passaggio a ESXi, semplicemente non saremmo dove siamo oggi.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Previous post Come avvolgere un panino, No Plastic Baggie
Next post Costruire relazioni positive con gli studenti alle prese con la salute mentale