Recentemente ho preso un interessante filo VMTN in cui un utente ha voluto spostare un cluster di uscire VSAN da un vCenter Server a un altro vCenter Server con un impatto minimo per i padroni di casa ESXi e macchine virtuali in esecuzione. La grande notizia è che questo può essere fatto senza alcun impatto per i padroni di casa ESXi e, soprattutto, non vi è alcun impatto per i carichi di lavoro. Personalmente ho eseguito questa operazione più volte senza problemi e il processo è in realtà abbastanza semplice ed ho pensato che dovessi camminare in essa, perché è letteralmente un paio di passi.
Il motivo principale non si tratta di una sfida che è VSAN è stato architettato per non avere una dipendenza da vCenter Server per le sue operazioni normali. E 'vero che vCenter Server è necessario per la configurazione e la gestione delle politiche VSAN cluster e VM bagagli, ma una volta che siano state applicate tali configurazioni, quindi il vCenter Server non è più in foto è dal punto di vista operativo. Questo significa che se avete bisogno di spostare il VSAN Cluster da un server vCenter sviluppo di un vCenter Server produzione o se accidentalmente distrutto il vostro vCenter Server originale, il VSAN Cluster può essere facilmente ricreato su un nuovo server vCenter.
Per dimostrare il processo, ho un 3 Nodo VSAN cluster con una macchina virtuale in esecuzione su vCenter Server (vcenter55-1) e ho costruito un nuovo vCenter Server (vcenter55-3) che vorrei spostare l'esistente VSAN Cluster verso .
Fase 1 - Distribuire un nuovo vCenter Server e creare un cluster vSphere con VSAN abilitato.
migrare-VSAN-cluster-da-un-vCenter-ad-un altro-0
Fase 2 - Scollegare uno degli host ESXi dal tuo attuale VSAN Cluster e poi aggiungere che al VSAN Cluster nel nuovo vCenter Server.
Nota: Tecnicamente, non hanno nemmeno bisogno di staccare gli host ESXi dal vecchio vCenter Server. Si può solo aggiungere gli host ESXi al nuovo server vCenter e una volta che avete confermato che si desidera spostare l'host ESXi, esso verrà automaticamente disconnesso una volta aggiunto. Questo sarebbe effettivamente risparmiare un ulteriore passaggio.
migrare-VSAN-cluster-da-un-vCenter-ad-un altro-1
Dopo aver aggiunto l'host ESXi, si dovrebbe vedere un messaggio di avviso nella pagina di configurazione VSAN affermando vi è una "configurazione errata rilevato" che si prevede. Quello che sta accadendo è che questa ESXi è stato configurato in un cluster esistente VSAN e la ESXi host che si suppone essere in grado di comunicare con i non fanno parte di questo VSAN Cluster. Una volta che aggiungiamo i padroni di casa resto ESXi, quindi il VSAN Cluster sarà felice e questo errore andrà via.
Nota: Se si tenta di aggiungere tutti gli host ESXi dalla esistente VSAN cluster per il nuovo VSAN Cluster in una sola volta, verrà visualizzato un errore UUID mancata corrispondenza. Il trucco è quello di aggiungere un host prima e una volta che è stato fatto, si può quindi aggiungere alla rinfusa gli host ESXi resto e non avrete un problema. Questo è utile se si sta cercando di automatizzare questo processo.
Passo 3 - Aggiungere i padroni di casa resto ESXi alla VSAN cluster nel nuovo server vCenter. Una volta che tutti gli host sono stati aggiunti al nuovo Cluster VSAN, potrete vedere le icone di avvertimento scompaiono e il tuo Cluster VSAN è ora completamente gestiti dal nuovo vCenter Server. Possiamo anche confermare che non ci sono partizioni di rete come tutte le configurazioni VSAN originali sono state mantenute sugli host ESXi.
migrare-VSAN-cluster-da-un-vCenter-ad-un altro-2
Disclaimer: Come detto non vi è alcun impatto sugli host ESXi (diversi da non essere in grado di gestire mentre si disconnette e ri-collegare il nuovo vCenter Server) e non vi è alcun impatto per le macchine virtuali in esecuzione e le eventuali Politiche VM di storage che sono stati applicati per la VM sarà ancora essere eseguite da ciascuno degli host ESXi. Tuttavia, una cosa da tenere presente è che le politiche di archiviazione VM nel vCenter Server originale non saranno disponibili nel nuovo server vCenter. Sarà necessario ricreare ciascuna delle Politiche VM di storage e ricollegare alle macchine virtuali esistenti. Questo può naturalmente essere automatizzato utilizzando l'API vSphere o sfruttando la nuova PowerCLI 5.8 R1 versione che include cmdlet VM della Polizia.
Ecco un esempio di esportazione di una politica di VM denominata "FTT = 1" in un file chiamato policy.xml sul desktop:
Export-SpbmStoragePolicy -StoragePolicy (Get-SpbmStoragePolicy -Name FTT = 1) -FilePath C: \ Users \ Administrator \ Desktop \ policy.xml
Attualmente questo è l'unico impatto spostando un VSAN cluster da un vCenter Server a un altro e, naturalmente, questo presuppone che hai creato Politiche VM di storage a parte i criteri predefiniti.
Ho ricevuto un paio di domande riguardanti la configurazione di rete per il mio VSAN Cluster. Nell'esempio di cui sopra stavo usando VSS (Virtual switch standard). Ho tuttavia, ripetere il test questo scenario completamente VDS (Virtual Distributed Switch) ei risultati sono stati gli stessi. Quando tutti gli host ESXi sono stati aggiunti al nuovo vCenter Server, verrà visualizzato un avviso relativo interruttore host proxy. La chiave per la migrazione correttamente le reti (VMkernel & VM Portgroup) è quello di aggiungere ogni ESXi ai nuovi VDS che avrete bisogno di creare. Se vCenter Server originale è ancora disponibile, è possibile esportare e importare la configurazione VDS. Se non è disponibile, allora si avrà bisogno di ricreare manualmente le Portgroups Distribuiti prima di procedere.
Il primo passo è quello di andare alla visualizzazione di rete e fare clic destro selezionare "Aggiungi e Gestisci host"
migrare-VSAN-cluster-da-un-vCenter-ad-un altro-3
Vai avanti e camminare attraverso la procedura guidata guidata e assicurarsi di aggiungere un solo host alla volta, come ho visto problemi quando si cerca di aggiungere più host alla volta. Una volta che l'host ESXi è stato aggiunto il nuovo VDS e le sue uplink, VMkernel e VM Portgroups sono tutti collegati. Ora dovreste vedere due VDS sotto la vista di rete di host ESXi sotto "Gestione".
migrare-VSAN-cluster-da-un-vCenter-ad-un altro-4
Questo può essere visto chiaramente utilizzando il client vSphere C # in quanto consente di visualizzare sia sullo stesso schermo. Dopo aver confermato che il tutto sembra a posto, allora si può andare avanti e rimuovere il vecchio interruttore VDS, come mostrato nello screenshot qui sopra. A questo punto, i padroni di casa ESXi rete è ora in esecuzione sul nuovo VDS. Potrai continuare questo stesso flusso di lavoro per i padroni di casa restante ESXi fino a quando tutti sono stati migrati al nuovo VDS.
martedì 30 settembre 2014
giovedì 18 settembre 2014
Vuoi pubblicare un operazione VAAI unmap utilizzando il client vSphere Web?
Recentemente, ho visto parecchie richieste da clienti e partner che vogliono essere in grado di eseguire l'operazione di VAAI unmap dall'interno del client vSphere Web. Per quelli di voi che non hanno familiarità con il funzionamento VAAI unmap, vi consiglio di controllare questo post sul blog dal mio collega Cormac Hogan. Oggi, l'unico modo per rilasciare l'operazione unmap è quello di utilizzare esxcli in remoto o in ESXi Shell. Attualmente non è una API vSphere per questa operazione e quindi sarebbe difficile costruire un plugin vSphere Web Client nativo per fornire questa funzionalità.
Detto questo, un modo per fornire questa funzionalità è attraverso l'uso di un vCenter Orchestrator (VCO) del flusso di lavoro che può eseguire un comando remoto esxcli se che sta attraversando esxcli utilizzando una casella di salto Linux o attraverso PowerCLI utilizzando una scatola salto di Windows. Partendo con vSphere 5.5, è ora possibile estendere il vSphere Client Web e allegare un flusso di lavoro VCO a un oggetto vSphere ed essere in grado di eseguire il flusso di lavoro direttamente dal client vSphere Web. Questo è grande se si sta già utilizzando VCO, ma per coloro che non sono, si può essere un po 'complesso da configurare con una curva di apprendimento ripida seconda della vostra esperienza.
Oggi, c'è stato un entusiasmante annuncio dal mio amico Automation, Alan Renouf per un nuovo VMware Fling chiamato PowerActions per il client vSphere Web . Questo nuovo Fling consente di estendere facilmente il client vSphere Web nei seguenti modi:
Accedere a una console PowerCLI direttamente nel client vSphere Web
Possibilità di eseguire un contesto consapevole copione PowerCLI direttamente dal client vSphere Web
Il presupposto per la creazione di PowerActions non è diverso da VCO chiamare uno script PowerCLI, basta un "jump-box" di Windows che ha PowerCLI installato con PowerActions. Il vantaggio è che si ha bisogno di installazione un altro pezzo di infrastrutture come VCO, se non siete già utilizza. Questo ha reso la creazione di PowerActions estremamente facile da installare e anche io stato in grado farlo installato e funzionante in meno di 5 minuti (meno un momento RTFM veloce :)).
Dato il numero di richieste di informazioni in materia di uso VAAI unmap tramite il vSphere Client Web, ho pensato che sarebbe stato un grande caso d'uso per il mio primo script PowerActions! Qui di seguito sono le istruzioni su come creare lo script VAAI unmap per PowerActions:
Fase 1 - Cliccate sulla voce Script PowerCLI sul lato sinistro della Object Navigator e quindi fare clic su " Nuovo script Icon ". Selezionare Datastore come oggetto consapevoli contesto per lo script.
unmap-comando-in-vSphere-web-client-0
Fase 2 - Fornire un nome e una descrizione per lo script. Inoltre, assicurarsi di selezionare "Azione".
unmap-comando-in-vSphere-web-client-1
Fase 3 - Copia e incolla il seguente script da https://github.com/lamw/vghetto-scripts/blob/master/powershell/unmap-poweraction.ps1 all'interno della finestra dello script e quindi salvare lo script. Che cosa fa lo script è prende l'oggetto Datastore e recupera un elenco di host ESXi che ha accesso al Datastore e poi seleziona a caso una delle dell'host. Questo è necessario perché le operazioni esxcli a livello di singolo host e usiamo queste informazioni per passare nel cmdlet Get-esxcli a rilasciare l'operazione VAAI annullare la mappatura.
Fase 4 - Per provare lo script, basta fare clic destro su un datastore VMFS e cliccare su PowerCLI-> Esegui uno script
unmap-comando-in-vSphere-web-client-2
Nota: Si prega di essere consapevole delle conseguenze quando si esegue un'operazione unmap, si consiglia di eseguire questo su un datastore non di produzione a scopo di test o durante le ore in cui il carico di lavoro non può essere occupato.
Passaggio 5 - Selezionare lo script VAAI unmap appena creato e una volta selezionato e vi verrà richiesto di specificare il numero di blocchi VMFS per eliminare la mappatura per ogni iterazione, che è esattamente la stessa di ingresso quando manualmente esxcli.
Screen Shot 2014/09/17 alle 10.30.09 PM
A questo punto, se tutto fosse successo l'operazione VAAI unmap dovrebbe iniziare e si può coda /var/log/hostd.log per vedere il funzionamento UNAMP. Una volta completato, si dovrebbe vedere il ritorno rapido vero.
Come si può vedere, è stato estremamente facile creare il mio proprio script PowerAction che espongono nuove funzionalità e renderlo accessibile ai client vSphere Web. Penso che questo sarà un Fling piuttosto popolare e ricordare se questo è qualcosa che ti piacerebbe vedere ufficialmente nel prodotto, assicurarsi di lasciare un commento sul PowerAction per la pagina Fling client vSphere Web , product manager sono in ascolto! L'unica reazione che ho è che mi piacerebbe vedere questo ottenere esteso oltre la semplice PowerCLI e in un quadro di estensione di script generico, solo immaginare le possibilità!
Detto questo, un modo per fornire questa funzionalità è attraverso l'uso di un vCenter Orchestrator (VCO) del flusso di lavoro che può eseguire un comando remoto esxcli se che sta attraversando esxcli utilizzando una casella di salto Linux o attraverso PowerCLI utilizzando una scatola salto di Windows. Partendo con vSphere 5.5, è ora possibile estendere il vSphere Client Web e allegare un flusso di lavoro VCO a un oggetto vSphere ed essere in grado di eseguire il flusso di lavoro direttamente dal client vSphere Web. Questo è grande se si sta già utilizzando VCO, ma per coloro che non sono, si può essere un po 'complesso da configurare con una curva di apprendimento ripida seconda della vostra esperienza.
Oggi, c'è stato un entusiasmante annuncio dal mio amico Automation, Alan Renouf per un nuovo VMware Fling chiamato PowerActions per il client vSphere Web . Questo nuovo Fling consente di estendere facilmente il client vSphere Web nei seguenti modi:
Accedere a una console PowerCLI direttamente nel client vSphere Web
Possibilità di eseguire un contesto consapevole copione PowerCLI direttamente dal client vSphere Web
Il presupposto per la creazione di PowerActions non è diverso da VCO chiamare uno script PowerCLI, basta un "jump-box" di Windows che ha PowerCLI installato con PowerActions. Il vantaggio è che si ha bisogno di installazione un altro pezzo di infrastrutture come VCO, se non siete già utilizza. Questo ha reso la creazione di PowerActions estremamente facile da installare e anche io stato in grado farlo installato e funzionante in meno di 5 minuti (meno un momento RTFM veloce :)).
Dato il numero di richieste di informazioni in materia di uso VAAI unmap tramite il vSphere Client Web, ho pensato che sarebbe stato un grande caso d'uso per il mio primo script PowerActions! Qui di seguito sono le istruzioni su come creare lo script VAAI unmap per PowerActions:
Fase 1 - Cliccate sulla voce Script PowerCLI sul lato sinistro della Object Navigator e quindi fare clic su " Nuovo script Icon ". Selezionare Datastore come oggetto consapevoli contesto per lo script.
unmap-comando-in-vSphere-web-client-0
Fase 2 - Fornire un nome e una descrizione per lo script. Inoltre, assicurarsi di selezionare "Azione".
unmap-comando-in-vSphere-web-client-1
Fase 3 - Copia e incolla il seguente script da https://github.com/lamw/vghetto-scripts/blob/master/powershell/unmap-poweraction.ps1 all'interno della finestra dello script e quindi salvare lo script. Che cosa fa lo script è prende l'oggetto Datastore e recupera un elenco di host ESXi che ha accesso al Datastore e poi seleziona a caso una delle dell'host. Questo è necessario perché le operazioni esxcli a livello di singolo host e usiamo queste informazioni per passare nel cmdlet Get-esxcli a rilasciare l'operazione VAAI annullare la mappatura.
Fase 4 - Per provare lo script, basta fare clic destro su un datastore VMFS e cliccare su PowerCLI-> Esegui uno script
unmap-comando-in-vSphere-web-client-2
Nota: Si prega di essere consapevole delle conseguenze quando si esegue un'operazione unmap, si consiglia di eseguire questo su un datastore non di produzione a scopo di test o durante le ore in cui il carico di lavoro non può essere occupato.
Passaggio 5 - Selezionare lo script VAAI unmap appena creato e una volta selezionato e vi verrà richiesto di specificare il numero di blocchi VMFS per eliminare la mappatura per ogni iterazione, che è esattamente la stessa di ingresso quando manualmente esxcli.
Screen Shot 2014/09/17 alle 10.30.09 PM
A questo punto, se tutto fosse successo l'operazione VAAI unmap dovrebbe iniziare e si può coda /var/log/hostd.log per vedere il funzionamento UNAMP. Una volta completato, si dovrebbe vedere il ritorno rapido vero.
Come si può vedere, è stato estremamente facile creare il mio proprio script PowerAction che espongono nuove funzionalità e renderlo accessibile ai client vSphere Web. Penso che questo sarà un Fling piuttosto popolare e ricordare se questo è qualcosa che ti piacerebbe vedere ufficialmente nel prodotto, assicurarsi di lasciare un commento sul PowerAction per la pagina Fling client vSphere Web , product manager sono in ascolto! L'unica reazione che ho è che mi piacerebbe vedere questo ottenere esteso oltre la semplice PowerCLI e in un quadro di estensione di script generico, solo immaginare le possibilità!
venerdì 12 settembre 2014
Come costruire personalizzato ESXi ISO per Apple Mac Mini?
Per quelli di voi che possiedono un Apple Mac Mini 6,2 può ricordare alcuni dei, consente di chiamare le "sfide" su come ottenere ESXi per eseguire il Mini. Queste sfide vanno dai noti problemi di SMC da Apple per i driver di rete tg3 mancanti o aggiornate Broadcom. Anche se ci Soluzioni alternative per queste questione, il processo è stato piuttosto complesso. Ho preso su di me per semplificare esso costruendo, passano di per la maggior parte delle versioni principali ESXi in modo che gli utenti possono semplicemente installare ESXi come farebbero normalmente e personalizzato ESXi ISO tutta la complessità.
Questo ha lavorato per la maggior parte delle persone, ma ho ricevuto diverse richieste di coloro che non possono stare bene con solo il download di un ISO a caso su internet, che posso comprendere appieno. L'altra ragione è che alcune persone vorrebbero costruire la propria ISO personalizzata e includere altri driver / pacchetti e altri sono solo interessati al processo. Questo è stato sulla mia lista di cose da fare per un po ', ma è stato trovare il tempo per documentare il processo, ma anche io normalmente piacerebbe prendere un ulteriore passo avanti e vedere come posso rendere ancora più semplice
Disclaimer: L'Apple Mac Mini non è ufficialmente supportato da VMware, si prega di utilizzare a proprio rischio
Con il recente rilascio di vSphere 5.5 Update 2 , ho pensato che questo sarebbe l'occasione perfetta per mostrare come si può costruire il proprio personalizzato ESXi ISO di girare su Apple Mac Mini 6,2.
Nota: Le versioni precedenti di Mac Mini dovrebbe funzionare bene per la maggior parte, senza ulteriori modifiche.
Prima di iniziare, vorrei anche ricordare che molte delle "sfide" come quello di avere un aggiornamento driver Broadcom TG3 è stato risolto nell'ultima ESXi 5.5 Update 2 release, quindi fuori dalla scatola si sarà in grado di vedere il su scheda del dispositivo di rete funziona come previsto e Ethernet Thunderbolt sarà anche funzionale se si utilizza tale dispositivo con l'essere richiesti driver aggiuntivi. Sono stato in grado di installare correttamente il valore predefinito out of the box ESXi 5.5 Update 2 ISO da VMware sul mio Apple Mac Mini 5,3 senza ulteriori modifiche.
Ecco il processo per costruire il proprio personalizzato ESXi ISO per il vostro Mac Mini:
Passo 1 - Scaricare la ISO di ESXi che si desidera lavorare con
Fase 2 - È necessario l'accesso a un sistema Linux (CentOS consiglio) che ha mkisofs utlity, che viene utilizzato all'autore ISO
Fase 3 - Scarica il mio custom.tgz che gestirà automaticamente l'emissione SMC per Apple Mac Mini 6,2
Fase 4 - Scarica il mio ghettotize-ESXi-iso.sh che è uno script di shell che avrà automaticamente un ISO ESXi e autore di una nuova ISO contenente le correzioni. Lo script è piuttosto semplice e si può dare un'occhiata allo script per tutti i dettagli.
Ecco un esempio di esecuzione dello script contro l'ultima ESXi 5.5 Update 2 ISO:
Come si può vedere alla fine dello script, si dovrebbe ottenere un nuovo ISO autore con un -NEW nel nome del file:
Una volta che hai la nuova ISO, è possibile prendere quella che e caricare su un dispositivo USB. Mi piace usareUNetbootin , che è una comoda utility che è supportato su tutte le piattaforme e crea un dispositivo USB avviabile con la ISO fornito. Come si può vedere il processo è piuttosto semplice e anche se ci è voluto un po 'di "sperimentazione" da parte mia per renderla completamente trasparente, potete vedere c'è troppo al processo in generale.
Per quelli di voi che invece non passare attraverso il processo e vuole solo la merce e si fida di me, ho anche costruito una nuova immagine aggiornata per l'ultima ESXi 5.5 Update 2 rilascio. Non ho avuto accesso a un Mac Mini 6,2 per confermare la build, ma sono abbastanza fiducioso che dovrebbe funzionare come ho provato un precedente 5.5 Update 2 costruire diversi mesi indietro. Potete trovare le ultime ISO con quelli passati ho creato qui di seguito.
lunedì 8 settembre 2014
Costruire un vCloud Lab Parte 3: vSphere 5 e vShield
Questa è la parte 3 della serie multipart su come sto costruendo un laboratorio pubblico vCloud, questo post spiegherà vSphere 5.0 installazione su ognuna delle macchine host e come impostare vShield Manager per il cluster.
Installare ESXi 5.0
Non voglio entrare troppo in profondità in questa parte, come ci sono già un sacco di how-to guide per l'installazione di vSphere 5 ... e non è stata nemmeno ancora rilasciato pubblicamente. Per la maggior parte dei ESXi installazione è identica a quella del 4.x, l'unica differenza di rilievo è come il programma di installazione si presenta, così come dover specificare una password di root durante l'installazione invece che dopo. Faremo installare tre host ESXi in questo momento, e tutti dovranno essere sulla stessa subnet (questa sarà la nostra sottorete di gestione).
Dopo aver installato i padroni di casa ESXi vorremo caricare vCenter 5.0 (Linux versione dell'apparecchio) al nostro host di gestione.
Installazione di Linux vCenter Appliance
Come ho detto nella prima parte della serie, ho voluto eliminare il maggior numero di server Windows da questo progetto il più possibile ... tutto ciò che può essere eseguito su Linux gira su Linux per una maggiore stabilità e una superficie di attacco ridotto al minimo. La prima cosa che dobbiamo fare è scaricare l'OVF e file VMDK da VMware.com, dopo che otteniamo tutti quelli scaricati importare la macchina virtuale al nostro host di gestione ESXi è piuttosto semplice:
Avviare il client vSphere e connettersi all'host in cui si desidera vCenter
Fare clic su File -> Deploy OVF Template
Individuare il percorso in cui avete salvato i file OVF e VMDK e selezionare il file OVF
Accettare il contratto di licenza e procedere con la procedura guidata
Assegnare un nome alla macchina virtuale e selezionare anche se volete provisioning spessa o sottile
Lasciate che il Importa template e poi accenderlo
Dopo la VM ha importato e aver acceso su di essa cercherà di avviare e ottenere un indirizzo DHCP. Se si dispone di don'y DHCP in esecuzione allora avete bisogno di login e impostare un indirizzo. Una volta che si ottiene un indirizzo DHCP è possibile utilizzare un browser Web per continuare l'installazione.
Per accedere all'interfaccia web di uso "root" come nome utente e "vmware" come password. È ora possibile modificare l'indirizzo IP del vCenter se si desidera, un IP statico è altamente raccomandato. Poi abbiamo bisogno di selezionare il tipo di database che useremo.
Opzioni vCenter Database
Fuori dalla scatola del vCenter Appliance Linux utilizza un database incorporato, per una distribuzione di laboratorio o di un piccolo gruppo avrebbe funzionato bene, ma dal momento che abbiamo bisogno di un database Oracle per vCloud Director, ho pensato che potremmo anche vCenter installazione di utilizzare la stessa Oracle Database come direttore vCloud. Per rendere questo accada abbiamo appena Login al vCenter interfaccia Web e andare alla sezione database e specificare le informazioni corrette Oracle e fare clic su Verifica. Dopo aver superato questi test è possibile fare clic su Salva. Non dimenticate di riavviare tutti i servizi vCenter una volta che avete fatto questo. (Nota: si perderà anche tutte le informazioni nel database incorporato salvati quando si esegue questa operazione, quindi se avete già vCenter in uso vorrei solo continuare ad usare embedded)
(Nota: L'installazione di un server di database Oracle 10g XE era coperto nella parte 2 della serie)
Setup vShield Manager
La parte successiva del nostro setup laboratorio è vShield Manager, che è un componente necessario di vCloud Director. E 'compito di vShield per assicurarsi che i diversi clienti nel nostro ambiente multi-tenant rimangono isolato e sicuro. E 'anche compito di vShield per fare il NAT, terminazione VPN, e l'isolamento gruppo di porte. Per installare vSheild seguiamo lo stesso processo come abbiamo fatto per vCenter, prima scaricare il file di modello ovuli da VMware.com. Poi importarlo al server di gestione, proprio come avete fatto con vCenter Server. Una volta che l'importazione è stata completata dobbiamo accendere vShield e attendere che si avvii, quindi il login con "admin" come nome utente e "default" come password. Questo ci farà arrivare a un Cisco IOS come prompt di dove si digita "enable", quindi immettere la password di amministratore. Ora che siamo al "setup" abilitare prompt che ci permette di impostare l'indirizzo IP della macchina virtuale vShield Manager. Log out per assicurarsi che le modifiche abbiano effetto.
Ora possiamo andare all'indirizzo IP che abbiamo appena entrati in una interfaccia web e di accesso con le credenziali utente di amministratore di default di cui sopra.
Dopo la registrazione abbiamo bisogno di specificare l'indirizzo IP del nostro server vCenter e quindi fare clic sul pulsante "Registrati" in modo che vShield "ganci" in vCenter. C'è un ultimo passo che è quello di installare i vShield Zones "lavoratore" VM su ciascuno dei padroni di casa nel nostro cluster di vCloud. Per rendere questo accada abbiamo bisogno di espandere l'elenco a sinistra e cliccare su uno dei padroni di casa; quindi fare clic su "Installa" per spingere la macchina virtuale per l'host. Assicurarsi di installare entrambe vShield Zones e isolamento bordo Port Group.
Nel prossimo post parleremo di come installare O
Installare ESXi 5.0
Non voglio entrare troppo in profondità in questa parte, come ci sono già un sacco di how-to guide per l'installazione di vSphere 5 ... e non è stata nemmeno ancora rilasciato pubblicamente. Per la maggior parte dei ESXi installazione è identica a quella del 4.x, l'unica differenza di rilievo è come il programma di installazione si presenta, così come dover specificare una password di root durante l'installazione invece che dopo. Faremo installare tre host ESXi in questo momento, e tutti dovranno essere sulla stessa subnet (questa sarà la nostra sottorete di gestione).
Dopo aver installato i padroni di casa ESXi vorremo caricare vCenter 5.0 (Linux versione dell'apparecchio) al nostro host di gestione.
Installazione di Linux vCenter Appliance
Come ho detto nella prima parte della serie, ho voluto eliminare il maggior numero di server Windows da questo progetto il più possibile ... tutto ciò che può essere eseguito su Linux gira su Linux per una maggiore stabilità e una superficie di attacco ridotto al minimo. La prima cosa che dobbiamo fare è scaricare l'OVF e file VMDK da VMware.com, dopo che otteniamo tutti quelli scaricati importare la macchina virtuale al nostro host di gestione ESXi è piuttosto semplice:
Avviare il client vSphere e connettersi all'host in cui si desidera vCenter
Fare clic su File -> Deploy OVF Template
Individuare il percorso in cui avete salvato i file OVF e VMDK e selezionare il file OVF
Accettare il contratto di licenza e procedere con la procedura guidata
Assegnare un nome alla macchina virtuale e selezionare anche se volete provisioning spessa o sottile
Lasciate che il Importa template e poi accenderlo
Dopo la VM ha importato e aver acceso su di essa cercherà di avviare e ottenere un indirizzo DHCP. Se si dispone di don'y DHCP in esecuzione allora avete bisogno di login e impostare un indirizzo. Una volta che si ottiene un indirizzo DHCP è possibile utilizzare un browser Web per continuare l'installazione.
Per accedere all'interfaccia web di uso "root" come nome utente e "vmware" come password. È ora possibile modificare l'indirizzo IP del vCenter se si desidera, un IP statico è altamente raccomandato. Poi abbiamo bisogno di selezionare il tipo di database che useremo.
Opzioni vCenter Database
Fuori dalla scatola del vCenter Appliance Linux utilizza un database incorporato, per una distribuzione di laboratorio o di un piccolo gruppo avrebbe funzionato bene, ma dal momento che abbiamo bisogno di un database Oracle per vCloud Director, ho pensato che potremmo anche vCenter installazione di utilizzare la stessa Oracle Database come direttore vCloud. Per rendere questo accada abbiamo appena Login al vCenter interfaccia Web e andare alla sezione database e specificare le informazioni corrette Oracle e fare clic su Verifica. Dopo aver superato questi test è possibile fare clic su Salva. Non dimenticate di riavviare tutti i servizi vCenter una volta che avete fatto questo. (Nota: si perderà anche tutte le informazioni nel database incorporato salvati quando si esegue questa operazione, quindi se avete già vCenter in uso vorrei solo continuare ad usare embedded)
(Nota: L'installazione di un server di database Oracle 10g XE era coperto nella parte 2 della serie)
Setup vShield Manager
La parte successiva del nostro setup laboratorio è vShield Manager, che è un componente necessario di vCloud Director. E 'compito di vShield per assicurarsi che i diversi clienti nel nostro ambiente multi-tenant rimangono isolato e sicuro. E 'anche compito di vShield per fare il NAT, terminazione VPN, e l'isolamento gruppo di porte. Per installare vSheild seguiamo lo stesso processo come abbiamo fatto per vCenter, prima scaricare il file di modello ovuli da VMware.com. Poi importarlo al server di gestione, proprio come avete fatto con vCenter Server. Una volta che l'importazione è stata completata dobbiamo accendere vShield e attendere che si avvii, quindi il login con "admin" come nome utente e "default" come password. Questo ci farà arrivare a un Cisco IOS come prompt di dove si digita "enable", quindi immettere la password di amministratore. Ora che siamo al "setup" abilitare prompt che ci permette di impostare l'indirizzo IP della macchina virtuale vShield Manager. Log out per assicurarsi che le modifiche abbiano effetto.
Ora possiamo andare all'indirizzo IP che abbiamo appena entrati in una interfaccia web e di accesso con le credenziali utente di amministratore di default di cui sopra.
Dopo la registrazione abbiamo bisogno di specificare l'indirizzo IP del nostro server vCenter e quindi fare clic sul pulsante "Registrati" in modo che vShield "ganci" in vCenter. C'è un ultimo passo che è quello di installare i vShield Zones "lavoratore" VM su ciascuno dei padroni di casa nel nostro cluster di vCloud. Per rendere questo accada abbiamo bisogno di espandere l'elenco a sinistra e cliccare su uno dei padroni di casa; quindi fare clic su "Installa" per spingere la macchina virtuale per l'host. Assicurarsi di installare entrambe vShield Zones e isolamento bordo Port Group.
Nel prossimo post parleremo di come installare O
martedì 2 settembre 2014
Inizia il viaggio di un cloud privato con la virtualizzazione del datacenter
Exchange virtualizzato 2013 validazione prestazioni IO con tutti gli array Flash
Pubblicato il 25 ago 2014 da Mohan Potheri
2 Risposte
Microsoft Exchange è un'applicazione critica molto comune gestito dalle imprese. Scambio 2013 ha portato avanti molti cambiamenti alla performance e il profilo di IO della propria infrastruttura.
Exchange Server 2013 è ancora maggiore candidato per la virtualizzazione rispetto ai suoi predecessori. Cambiamenti architettonici e miglioramenti al nucleo di Exchange Server, insieme con i progressi in hardware del server, fare vSphere la scelta di default per Exchange 2013.
Virtualizzazione di Exchange è popolare come la scelta progettuale a seguito di importanti progressi in tre aree chiave: ( Scambio 2013 Best Practices su vSphere )
L'archivio di informazioni di Exchange (il deposito gestito) è stato riscritto per ottimizzare ulteriormente il consumo di risorse. Questo aggiornamento per il deposito gestito ha portato anche ad un'ulteriore riduzione dei requisiti di storage di I / O.
I progressi in hardware del server, come i processori multicore, densità di memoria superiore, e dai progressi della tecnologia di storage stanno superando di gran lunga i requisiti prestazionali per le applicazioni, incluso Exchange 2013 virtualizzazione diventa un modo efficace per sfruttare tutta la potenza di questi sistemi.
I progressi nel campo Server 2013 e l'hardware del server di Exchange tecnologia hanno coinciso con i progressi in vSphere. Le macchine virtuali supportano fino a 1 TB di RAM e 64 CPU virtuali e sono in grado di eseguire anche i più grandi server Cassette postali di Exchange.
L'obiettivo di questo esercizio era di vedere se le prestazioni IO richiesto per 100.000 di Exchange 2013 le cassette postali possono essere supportati dall'ambiente di test. L'obiettivo principale del test è la prestazione di stoccaggio e non capacità o altri parametri. Macchine e storage virtuali saranno dimensionati per una prova di efficienza cassetta postale di Exchange.
Componenti dell'infrastruttura:
I seguenti componenti sono stati utilizzati per il test delle prestazioni OLTP su un all array di archiviazione Flash:
Di server Dell R910 con 40 (2.4 GHz) core e 256 GB di RAM
Pure bagagli FA-420 FlashArray con due ripiani che comprendeva 44 238 unità GB Flash e 8.2 TB di capacità utilizzabile.
8 X di Windows 2012 macchine virtuali con 4 CPU virtuale e 16 GB di RAM, 250 GB di hard Quattro Dati e due da 100 GB database di registrazione spinge ciascuno.
SW iSCSI su due porte 10Gbps dedicate.
Scambio di 2.013 conducenti e Microsoft JetStress Utility.
Dimensionamento della macchina virtuale:
La macchina virtuale utilizzata per le prove è stato un Server R2 di Windows 2012 con Exchange 2013 driver e l'utility Microsoft JetStress. Configurazione di archiviazione delle macchine virtuali sono stati:
Boot Disk: C Drive e lo spazio di swap su LUN condivisa con altre macchine virtuali
VM aveva 4 adattatori PVSCSI con dischi distribuiti in modo uniforme su di essi.
4 dischi di dati tra LUN separati sullo stoccaggio puro e 2 dischi Log in tutto LUN separati sullo stoccaggio Pure.
Capacità del disco e la configurazione di ciascun Exchange Server:
exch_1
Preparazione del database:
Ogni server Exchange dispone di quattro database e quattro file di log distribuiti su quattro LUN di dati e due tronchi LUN. Quattro database di Exchange sono stati creati per ciascun server di Exchange e collocate su più unità di dati, come illustrato di seguito.
Creazione database di Exchange:
exch_2
Configurazione di Exchange Jetstress e macchine virtuali utilizzati per le prove:
Otto macchine virtuali identiche sono stati usati per generare il carico di Exchange equivale a un totale di 100000 cassette postali di Exchange con una portata media di posta giornaliera di 300 messaggi. Ogni macchina virtuale ha avuto 4 CPU virtuale e 16 GB di RAM, 250 GB di hard Quattro di dati e due da 100 GB database di registrazione unità ciascuna.
Jetstress di Exchange Server Ottimizzazioni:
Migliori pratiche di server MS Exchange relativi all'utilizzo di più adattatori SCSI con dischi virtuali distribuisce su tutte le schede sono state attuate. Quattro dischi di dati e due dischi di log ciascuno sui singoli LUN sono stati configurati sul array di storage puro e stanziati per la macchina virtuale di Exchange.
IOPS Dimensionamento per il test Jetstress:
Il Blog TechNet Microsoft Exchange Guida al dimensionamento è stato utilizzato per venire con i IOPS richiesti per utente (0.2) per un volume medio di posta di 300 al giorno.
IOPS requisito per il numero di messaggi al giorno per cassetta postale:
exch_3
Test per 80.000 caselle di posta: (2000 IOPS per nodo, 8 nodi)
Jetstress è stato eseguito in parallelo in otto macchine virtuali con i quattro database di ogni server. Le IOPS target per ogni macchina virtuale è stata 2000. Tutti i nodi otto superato il test convalida la soluzione per 80000 cassette postali.
Test per 100.000 caselle di posta: (2500 IOPS per nodo, 8 nodi)
Test iniziale:
Jetstress è stato eseguito in parallelo in otto macchine virtuali con i quattro database di ogni server. Le IOPS target per ogni macchina virtuale è stata 2500. Maggioranza dei nodi otto fallito il test con le IOPS non richiesto di essere raggiunto.
Durante l'analisi si è visto che la velocità massima tra i due adattatori iSCSI a 10 Gbps era 650 MBPS e non ci sono stati problemi in qualsiasi componente dell'infrastruttura. Esxtop analisi ha mostrato che l'iSCSI CODA profondità potrebbe essere un fattore limitante per la prestazione.
Prova finale:
Dopo aver modificato la CODA profondità iSCSI per l'host ESX, il test è stato poi ripetuto. Tutte e otto le macchine virtuali hanno superato la prova con IOPS superiore a 2600 E 'stato inoltre osservato che il throughput dei collegamenti iSCSI era molto più alto, con un picco di avvicinamento 950 MBPS.
Utilizzo di rete durante Jetstress successo per 100000 utenti:
Durante l'intero test è stato osservato che l'array di archiviazione PURE eseguito bene con meno di 1ms di latenza e la velocità a volte raggiungendo 900 MBPS.
Prestazioni di conservazione in Jetstress successo per 100000 utenti:exch_5
Risultati:
Il risultato positivo del test Jetstress per una dell'host di Exchange è riportato di seguito.
exch_6
Conclusione:
I risultati mostrano che vSphere è una piattaforma eccellente per Exchange 2013 carichi di lavoro. Da un singolo server con 40 core moderni collegati a un alto rendimento di stoccaggio pura matrice All Flash, è stato dimostrato che i requisiti di prestazioni IO di 100.000 caselle di posta possono essere soddisfatte con più macchine virtuali che operano in parallel.The Pure storage array bagagli Flash, che è una componente critica nella infrastruttura eseguita con latenze millisecondi sub di tutto il test. L'array di archiviazione Pure anche disponibile e riduzione media dati nell'ordine di 7: 1 per i carichi di lavoro di Exchange.
Pubblicato il 25 ago 2014 da Mohan Potheri
2 Risposte
Microsoft Exchange è un'applicazione critica molto comune gestito dalle imprese. Scambio 2013 ha portato avanti molti cambiamenti alla performance e il profilo di IO della propria infrastruttura.
Exchange Server 2013 è ancora maggiore candidato per la virtualizzazione rispetto ai suoi predecessori. Cambiamenti architettonici e miglioramenti al nucleo di Exchange Server, insieme con i progressi in hardware del server, fare vSphere la scelta di default per Exchange 2013.
Virtualizzazione di Exchange è popolare come la scelta progettuale a seguito di importanti progressi in tre aree chiave: ( Scambio 2013 Best Practices su vSphere )
L'archivio di informazioni di Exchange (il deposito gestito) è stato riscritto per ottimizzare ulteriormente il consumo di risorse. Questo aggiornamento per il deposito gestito ha portato anche ad un'ulteriore riduzione dei requisiti di storage di I / O.
I progressi in hardware del server, come i processori multicore, densità di memoria superiore, e dai progressi della tecnologia di storage stanno superando di gran lunga i requisiti prestazionali per le applicazioni, incluso Exchange 2013 virtualizzazione diventa un modo efficace per sfruttare tutta la potenza di questi sistemi.
I progressi nel campo Server 2013 e l'hardware del server di Exchange tecnologia hanno coinciso con i progressi in vSphere. Le macchine virtuali supportano fino a 1 TB di RAM e 64 CPU virtuali e sono in grado di eseguire anche i più grandi server Cassette postali di Exchange.
L'obiettivo di questo esercizio era di vedere se le prestazioni IO richiesto per 100.000 di Exchange 2013 le cassette postali possono essere supportati dall'ambiente di test. L'obiettivo principale del test è la prestazione di stoccaggio e non capacità o altri parametri. Macchine e storage virtuali saranno dimensionati per una prova di efficienza cassetta postale di Exchange.
Componenti dell'infrastruttura:
I seguenti componenti sono stati utilizzati per il test delle prestazioni OLTP su un all array di archiviazione Flash:
Di server Dell R910 con 40 (2.4 GHz) core e 256 GB di RAM
Pure bagagli FA-420 FlashArray con due ripiani che comprendeva 44 238 unità GB Flash e 8.2 TB di capacità utilizzabile.
8 X di Windows 2012 macchine virtuali con 4 CPU virtuale e 16 GB di RAM, 250 GB di hard Quattro Dati e due da 100 GB database di registrazione spinge ciascuno.
SW iSCSI su due porte 10Gbps dedicate.
Scambio di 2.013 conducenti e Microsoft JetStress Utility.
Dimensionamento della macchina virtuale:
La macchina virtuale utilizzata per le prove è stato un Server R2 di Windows 2012 con Exchange 2013 driver e l'utility Microsoft JetStress. Configurazione di archiviazione delle macchine virtuali sono stati:
Boot Disk: C Drive e lo spazio di swap su LUN condivisa con altre macchine virtuali
VM aveva 4 adattatori PVSCSI con dischi distribuiti in modo uniforme su di essi.
4 dischi di dati tra LUN separati sullo stoccaggio puro e 2 dischi Log in tutto LUN separati sullo stoccaggio Pure.
Capacità del disco e la configurazione di ciascun Exchange Server:
exch_1
Preparazione del database:
Ogni server Exchange dispone di quattro database e quattro file di log distribuiti su quattro LUN di dati e due tronchi LUN. Quattro database di Exchange sono stati creati per ciascun server di Exchange e collocate su più unità di dati, come illustrato di seguito.
Creazione database di Exchange:
exch_2
Configurazione di Exchange Jetstress e macchine virtuali utilizzati per le prove:
Otto macchine virtuali identiche sono stati usati per generare il carico di Exchange equivale a un totale di 100000 cassette postali di Exchange con una portata media di posta giornaliera di 300 messaggi. Ogni macchina virtuale ha avuto 4 CPU virtuale e 16 GB di RAM, 250 GB di hard Quattro di dati e due da 100 GB database di registrazione unità ciascuna.
Jetstress di Exchange Server Ottimizzazioni:
Migliori pratiche di server MS Exchange relativi all'utilizzo di più adattatori SCSI con dischi virtuali distribuisce su tutte le schede sono state attuate. Quattro dischi di dati e due dischi di log ciascuno sui singoli LUN sono stati configurati sul array di storage puro e stanziati per la macchina virtuale di Exchange.
IOPS Dimensionamento per il test Jetstress:
Il Blog TechNet Microsoft Exchange Guida al dimensionamento è stato utilizzato per venire con i IOPS richiesti per utente (0.2) per un volume medio di posta di 300 al giorno.
IOPS requisito per il numero di messaggi al giorno per cassetta postale:
exch_3
Test per 80.000 caselle di posta: (2000 IOPS per nodo, 8 nodi)
Jetstress è stato eseguito in parallelo in otto macchine virtuali con i quattro database di ogni server. Le IOPS target per ogni macchina virtuale è stata 2000. Tutti i nodi otto superato il test convalida la soluzione per 80000 cassette postali.
Test per 100.000 caselle di posta: (2500 IOPS per nodo, 8 nodi)
Test iniziale:
Jetstress è stato eseguito in parallelo in otto macchine virtuali con i quattro database di ogni server. Le IOPS target per ogni macchina virtuale è stata 2500. Maggioranza dei nodi otto fallito il test con le IOPS non richiesto di essere raggiunto.
Durante l'analisi si è visto che la velocità massima tra i due adattatori iSCSI a 10 Gbps era 650 MBPS e non ci sono stati problemi in qualsiasi componente dell'infrastruttura. Esxtop analisi ha mostrato che l'iSCSI CODA profondità potrebbe essere un fattore limitante per la prestazione.
Prova finale:
Dopo aver modificato la CODA profondità iSCSI per l'host ESX, il test è stato poi ripetuto. Tutte e otto le macchine virtuali hanno superato la prova con IOPS superiore a 2600 E 'stato inoltre osservato che il throughput dei collegamenti iSCSI era molto più alto, con un picco di avvicinamento 950 MBPS.
Utilizzo di rete durante Jetstress successo per 100000 utenti:
Durante l'intero test è stato osservato che l'array di archiviazione PURE eseguito bene con meno di 1ms di latenza e la velocità a volte raggiungendo 900 MBPS.
Prestazioni di conservazione in Jetstress successo per 100000 utenti:exch_5
Risultati:
Il risultato positivo del test Jetstress per una dell'host di Exchange è riportato di seguito.
exch_6
Conclusione:
I risultati mostrano che vSphere è una piattaforma eccellente per Exchange 2013 carichi di lavoro. Da un singolo server con 40 core moderni collegati a un alto rendimento di stoccaggio pura matrice All Flash, è stato dimostrato che i requisiti di prestazioni IO di 100.000 caselle di posta possono essere soddisfatte con più macchine virtuali che operano in parallel.The Pure storage array bagagli Flash, che è una componente critica nella infrastruttura eseguita con latenze millisecondi sub di tutto il test. L'array di archiviazione Pure anche disponibile e riduzione media dati nell'ordine di 7: 1 per i carichi di lavoro di Exchange.
Iscriviti a:
Post (Atom)