vSAN check the Congestion...

A seguito di una problematica che ha portato ad un down di un host di un cluster VxRail (ESXi 6.0.0 build 4192238; problematica ancora sotto investigazione 😀 ), con il supporto EMC siamo stati costretti a re-installare da zero il nodo ed effettuare un re-join del nodo al cluster vSAN.

Terminato il processo di re-installazione ed effettuato di nuovo il join al cluster vSAN è tempo di ri-sincronizzare i dati.

Il processo di sincronizzazione potrebbe essere lungo e richiedere risorse computazionali e di I/O per un periodo eccessivamente prolungato tale da influire negativamente sulle prestazioni delle VMs che girano su cluster stesso. Per limitare/regolare il processo di sincronizzazione ed evitare di bloccare/congestionare i dischi per l'eccessivo I/O dovuto al re-sync, possiamo agire sul parametro "MaxNumResyncCopyInFlight"; che di default è impostato a 50 (ed è anche il valore massimo).

Come possiamo vedere se i dischi sono congestionati??

Di seguito il comando che possiamo lanciare su ogni host per verificare questo:

for ssd in $(localcli vsan storage list |grep "Group UUID"|awk '{print $5}'|sort -u);do echo $ssd;vsish -e get /vmkModules/lsom/disks/$ssd/info| grep Congestion;done

Valori tra:

    1-100 --> OK
101-150 --> NOT GOOD
                    Abbassare occorre abbassare il valore del parametro (Il valore deve essere lo stesso su tutti gli host che compongono il cluster)

151-250 --> VERY BAD
                    C'è il rischio che le VMs vadano giù) abbassare il valore in tutti gli host del cluster

Come descritto in precedenza, per limitare il processo di ri-sincronizzazione possiamo andare ad agire sul valore "MaxNumResyncCopyInFlight" ed evitare di bloccare i dischi per l'eccessivo I/O.

Quando si va a modificare la variabile indicata sopra, occorre agire su ogni singolo host che fa parte del cluster/del processo di sincronizzazione.

Di default il valore di MaxNumResyncCopyInFlight è impostato a 50 e si può vedere lanciando il seguente comando su ogni singolo host:

vsish -e get /vmkModules/vsan/dom/MaxNumResyncCopyInFlight

Il comando per modificare le impostazioni correnti al volo è

vsish -e set /vmkModules/vsan/dom/MaxNumResyncCopyInFlight 25

Happy New Year

Happy New Year.

Welcome 2018!!

Some useful commands to configure zoning on a Brocade switch FC

Dal momento che Java non sta più funzionando sui nuovi browser è il momento di prendere confidenza con la command line interface (CLI) degli switch Fibre Channel (FC) Brocade.

Di seguito alcuni comandi utili per effettuare lo zoning direttamente da linea di comando.

1. Verifica dell'attuale configurazione e delle informazioni necessarie per la configurazione.  
   
   

   #BR5460-SWFC1:admin> switchshow

   Il precedente comando switchshow permette di vedere il nome della zona configurata e le WWN delle nuove HBA connesse.

   #BR5460-SWFC1:admin> cfgshow

   Eseguire il comando cfgshow per visualizzare la configurazione e vedere come sono attualmente configurate le zone.
2. Controllo della nameserver zone

   #BR5460-SWFC1:admin> nsshow
   ......
   #BR5460-SWFC1:admin> zoneshow

   Permette di verificare il nome delle Zona configurata sul device.
3.  Creare l'Alias
   
   
   

   #BR5460-SWFC1:admin> alicreate "ESXi01_B","50:00:08:XX:XX:XX"
   #BR5460-SWFC1:admin> alicreate "ESXi02_B","50:00:08:XX:XX:XX"
   #BR5460-SWFC1:admin> alicreate "HUS110_1A","50:06:0e:XX:XX:XX"
   #BR5460-SWFC1:admin> alicreate "HUS110_1D","50:06:0e:XX:XX:XX"

   alicreate permette di dare un nome "alias" alla WWN; da rendere più agevole
   
4. Creare una Zona

   #BR5460-SWFC1:admin> zonecreate "ESXi01_HUS110_1A","ESXi01_B;HUS110_1A"
   #BR5460-SWFC1:admin> zonecreate "ESXi01_HUS110_1D","ESXi01_B;HUS110_1D"
   #BR5460-SWFC1:admin> zonecreate "ESXi02_HUS110_1A","ESXi02_B;HUS110_1A"
   #BR5460-SWFC1:admin> zonecreate "ESXi02_HUS110_1D","ESXi02_B;HUS110_1D"
   

   Il comando zonecreate crea una zona in cui associa (utilizzando l'alias precedentemente creato) la WWN dell'host VMware alla WWN della controller dello storage.
   
   Queste zone vanno quindi aggiunte alla configurazione attiva ...
5. Creare una Zone Configuration o Aggiungere una Zona ad una Configurazione esistente
   
   Se la "zone config" non esiste occorre crearne una oppure aggiungere quanto precedentemente creato nel punto 4 alla zona di default.
   In questo caso ne creiamo una nuova, nel seguente modo:

   #BR5460-SWFC1:admin> cfgCreate "FCSW1","ESXi01_HUS110_1A;ESXi01_HUS110_1D;ESXi02_HUS110_1A"

   nel precedente comando ho volutamente omesso di aggiungere alla configurazione la zona "ESXi02_HUS110_1D" in modo da poter utilizzare il comando indicato di seguito

   #BR5460-SWFC1:admin> cfgadd "FCSW1","ESXi02_HUS110_1D"

   cfgadd permette di aggiungere una zona ad una configurazione già esistente.
6. Salviamo la configurazione
   
   
   

   #BR5460-SWFC1:admin> cfgsave

   Il comando cfgsave salva la configurazione in modo permanente sullo switch, alla richiesta di procedere con il salvataggio della configurazione digitare "yes" e confermare.
7. Attivare la configurazione
   
   
   La configurazione precedentemente salvata non è ancora attiva, è necessario attivarla con il seguente comando

   #BR5460-SWFC1:admin> cfgenable FCSW1

Abbiamo quindi terminato ed attivato la nuova configurazione sullo switch.

Di seguito altri comandi che potrebbero essere utili:

1. Disabilitare la zona
   
   

   #BR5460-SWFC1:admin> cfgdisable

   Il comando cfgdisable disabilita la corrente zona.
   
   
2. Ripulire la Zona
   
   

   #BR5460-SWFC1:admin> cfgclear

   Utilizzare questo comando (cfgclear) per cancellare tutte le informazioni presenti sul "transaction buffer". Tutti gli oggetti presenti nel "transaction buffer" vengono cancellati.
   
   

Maggiori dettagli possono essere reperiti dalla "Command Reference Guide"

Hardware configuration of host is incompatible. Check scan results for details.

Disclaimer: The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a reader's responsibility. Use it at you own risk.

Giornata di upgrade .... quest'oggi devo aggiornare una serie di lame Blade di un Hitachi Compute Blade 520HA1.

Ho caricato la nuova ISO custom  ESXi-6.5.0-4564106-custom-hitachi-0100 nel VUM del nuovo vCenter Server 6.5.0 (build-7119157) ed ho fatto ma mia bella "Baseline" e l'ho attaccata all'host come indicato di seguito.

A questo punto non resta che lanciare lo "Scan for Updates..." 

Tutto sembra OK, procedo con il mettere in Maintenance il nodo e con il "Remediate..."

Parte la procedura di "Remediation" e dopo qualche secondo appare il seguente messaggio di errore....

Hardware configuration of host <Hostname> is incompatible. Check scan results for details.

Mi accorgo di quanto segue:
- lo script di precheck fallisce con un errore "unknown" ....
- e che la Acceptance Level è impostata a "Partner"

vado quindi a verificare e cercare maggiori informazioni all'interno dei log.

Mi connetto al vCenter (tramite putty)  ed entro diretto nella cartella dove sono il log relativi all'Update Manager ...

# cd /var/log/vmware/vmware-updatemgr/vum-server/hostUpgrade

verifico quindi i file sulla directory con

# ls -ltr

alla ricerca dell'ultimo file modificato per l'host che sto upgradando. Nel mio caso "vua-<hostname>-9.log.gz"

Lo edito alla ricerca di informazioni :

# gunzip -c vua-<hostname>-9.log.gz | less

Provando a ricercare per "ERROR", salta fuori una riga interessante 

Mi connetto quindi all'Host e verifico ulteriormente il livello di "acceptance"

# esxcli software acceptance get

e lo modifico come indicato di seguito

# esxcli software acceptance set --level=VMwareAccepted

Verifico quindi che il valore sia stato impostato correttamente, e lancio nuovamente il "Remediate..." 

Questa volta il comportamento sembra leggermente diverso ......

... il classico comportamento dell'Update Manager.

Dopo aver atteso per un pò, in quanto l'host in fase di upgrade effettua un paio di reboot .... di seguito il risultato:

Host aggiornato con successo.

PS: Prima di effettuare l'operazione indicata sopra (soprattutto se stiamo parlando di un ambiente di produzione) verificare bene tutte le matrici di compatibilità VMware. 

'UserVars.VshieldVsmConnetionInfo' is invalid or exceeds the maximum number of characters permitted

A seguito di un upgrade ho riscontrato il seguente messaggi di errore:

'UserVars.VshieldVsmConnectionInfo' is invalid or exceeds the maximum number of characters permitted

Cercando in rete ho trovato la seguente KB2149015 che però non ha risolto il mio problema.

Soluzione 

Verificando via CLI ho riscontrato che il VIB  "epsec-mux" non erano stato correttamente aggiornato ..

Per la risoluzione procedere come indicato in un mio precedente post "UserVars.UsvmConfig is invalid or exceeds the maximum number of characters permitted"

Check SHA1 Checksum in Mac OS X

Come per la verifica md5, è possibile verificare il checksum sha1 da linea di comando con il mac tramite il comando "shasum"

# shasum <path>/to/file.name 

di seguito un esempio:

Verifichiamo quindi con il file di testo fornito con il pacchetto scaricato.

Se la sequenza di numeri coincide, significa che il file scaricato è corretto.

'UserVars.UsvmConfig' is invalid or exceeds the maximum number of characters permitted

In fase di installazione delle Guest Introspection su ambiente NSX (ver. 6.2.4-4292526) ed ESXi (ver. 6.0.0 build-5572656) ho ottenuto il seguente comportamento:

- Guest Introspection installata ed avviata correttamente;
- Tuttavia analizzando lo status:

Il VIB epsec-mux responsabile della comunicazione tra ESXi e GI appliance non viene installato.
Analizzando meglio i messaggi di errore nei task, osserviamo uno strano messaggio di errore:

'UserVars.UsvmConfig' is invalid or exceeds the maximum number of characters permitted

Soluzione 

La soluzione è quella di installare manualmente il VIB scaricandolo direttamente dal NSX Manager a questo path:

https://<nsx manager ip>/bin/epsec/6.2.4/vibs/6.0/offlinebundle/vShield-Endpoint-Mux-6.0.0esx60-3796715.zip

procedere con l'installazione manuale:

Verifichiamo che il VIB sia presente:

E magicamente tutto prende a funzionare correttamente.


NOTE:
Un interessante link che mi ha aiutato per la risoluzione di questo problema è il seguente "VMware NSX Component Build Matrix"