Troubleshooting vRA upgrade – Aria Automation Series

Pubblicato il 9 Gennaio 2025 da scanda

Durante l’upgrade di vRealize ad Aria Automation mi sono imbattuto in alcuni problemi bloccanti, condivido in quest’articolo le KB e i comandi che mi hanno aiutato a risolverli e completare l’upgrade.

I Pre Check falliscono a causa di poco spazio disco sulla partizione di root di LCM

In questo caso la funzione EXTEND STORAGE dalle impostazioni di LCM non aiuta, la root non viene estesa

Si può recuperare dello spazio dalla root utilizzando i comandi di questa KB, una volta liberato lo spazio rieseguire i pre check e proseguire con l’upgrade

Se cercate di espandere lo spazio disco su LCM il job si blocca con il seguente errore

Il problema è dovuto alla presenza di snapshot (dovuti ai precedenti upgrade)

Sarà semplicemente necessario eliminare tutti gli snapshot con DELETE ALL, rieseguire EXTEND STORAGE

I Pre Check di upgrade falliscono senza un apparente motivo

Può trattarsi du un job bloccato nel tentativo di collegarsi all’environment di Aria Automation. Nel mio caso ho riscontrato 2 problemi.

Il primo risolvibile eseguendo i comandi di questa KB, nel secondo i servizi di Aria Automation non erano risaliti correttamente.

Per verificare lo stato di Aria Automation e dei suoi servizi collegarsi via SSH all’appliance con l’utenza root.

Per prima cosa verificare se il nodo (o i nodi nel caso di un cluster) sono nello stato ready

Se il nodo è in stato NotReady può non essere risalito corettamente o non aver ancora completato lo startup. Se dopo un pò di tempo lo stato non cambia a Ready provare a riavviare l’appliance.

Verificare lo stato dei servizi, tutti i servizi devono essere Started e Healthy

Se i servizi non sono in Started verificare lo stato dei Pods del namespace prelude

E’ possibile verificare i log del deploy dei Pods con il seguente comando

Come potete osservare lo stato dei servizi, dei Pods e del log non riportano nessun problema, in questo caso il sistema funziona correttamente.

Questo lo stato dei precedenti comandi in caso di riavvio incompleto o ancora in esecuzione

Altro problema bloccante, non è possibile mappare un immagine per eseguire l’upgrade da LCM

Questo succede se non si è selezionato un Product support pack che supporti l’immagine che si tenta di mappare (fare riferimento a questa KB). Verificare di aver selezionato e attivato l’ultimo PSPack disponibile per la release utilizzata di LCM.

Altri comandi utili per verificare la versione di Aria Automation e lo stato dell’upgrade

Non mancherò di aggiornare l’articolo con le soluzioni ad altri problemi di upgrade 🙂

 

 

Pubblicato in Aria Automation, troubleshooting, vmug | Contrassegnato , , | Commenti disabilitati su Troubleshooting vRA upgrade – Aria Automation Series

Upgrade vRA 8.11.2 to 8.18.0 – Aria Automation Series

Pubblicato il 8 Gennaio 2025 da scanda

E adesso viene il bello 🙂 Come avete visto l’installazione con Easy Installer non è complicata, l’upgrade richiede delle attenzioni in più.

Per prima cosa bisogna verificare i path di upgrade dei prodotti coinvolti e la relativa matrice di compatibilità. Durante tutto il processo di upgrade dobbiamo garantire piena interoperabilità tra i Lifecycle manager, Workspace ONE e Aria Automation.

Per Workspace ONE (per semplicità IDM) la cosa è semplice, l’attuale versione è in matrice con Lifecycle manager e Automation.

La cosa si complica un pò con LCM e Automation.

Ricordiamoci che le varie versioni devono essere compatibili tra loro!

Incrociando il tutto, e verificando i vari passaggi in laboratorio,  ho ottenuto il seguente upgrade path

Upgrade orderProductSource ReleaseDestination Release
1LCM8.108.12
2Automation8.11.28.13.1
3LCM8.128.14
4Automation8.13.18.16
5LCM8.148.16
6LCM8.168.18
7Automation8.168.18

L’upgrade path risultante non è semplice, in alcuni passaggi ho dovuto risolvere alcuni problemi bloccanti. Come sempre vale la pena tenere aggiornata l’infrastruttura periodicamente, dover fare così tanti salti in poco tempo diventa molto più rischioso.

Lifecycle manager mette a disposizione il tool Upgrade Planner all’interno dell’environment che ospita Aria Automation, purtroppo la versione 8.10 (installata con Easy Installer) mi ha dato vari errori e non era utilizzabile 🙁

Solo dopo l’upgrade alla 8.12 ha iniziato a funzionare, ma ha è tornato a non funzionare correttamente dopo alcune release. Il mio consiglio è di utilizzare gli upgrade path e le matrici di compatibilità del sito.

Vediamo comunque un immagine del tool funzionante, riflette il path upgrade corretto 🙂

Dall’environment selezionare UPGRADE PLANNER, successivamente si può specificare la release di arrivo, selezionare i flag dei prodotti ed eseguire GENERATE UPGRADE PLAN

Ecco il risultato

una volta definito l’upgrade path si può iniziare l’aggiornamento. Partiamo dal Lifecycle manager (LCM). La procedura è la stessa per tutte le release.

Per prima cosa dobbiamo scaricare la ISO per l’upgrade dal sito broadcom, il nome del file è VMware-Aria-Suite-Lifecycle-Appliance-8.12.0.7-21628952-updaterepo.iso

La ISO va caricata su un datastore del cluster dove risiede LCM e collegata all’appliance. Successivamente, da LCM, andare su Settings e System Upgrade. Selezionare come repository CDROM e poi CHECK FOR UPGRADE.

Se la ISO è stata collegata correttamente verrà rilevata la release per l’upgrade.

NOTA: prima di avviare l’upgrade è necessario prendere uno snapshot di LCM, se qualcosa va storto possiamo sempre tornare indietro.

Proseguiamo con l’upgrade, per proseguire abilitare il flag relativo allo snapshot.

Eseguiamo i precheck e verifichiamo che tutto sia a posto

Confermiamo con UPGRADE

LCM eseguirà l’aggiornamento e si riavvierà, attendere che i servizi tornino attivi.

Al completamento sarà possibile verificare la nuova release

Completato l’upgrade installiamo l’ultimo Product Support Pack, andiamo su Settings e poi su Product Support Pack. Il Pack attivo è quello disponibile con l’upgrade, verificare che ce ne siano di più recenti.

Selezionare il più recente e dare APPLY VERSION

Vediamo che l’ulitmo Support Pack supporta proprio la versione di Aria Automation che ci server per lo step di upgrade 2

LCM si deve riavviare per rendere effettive le nuove configurazioni.

Passiamo al secondo step, scarichiamo la ISO per l’upgrade di Automation alla release 8.13.1

Questa volta la ISO va caricata direttamente su LCM, è possibile trasferirla via SCP al percorso /data

NOTA : Se non c’è abbastanza spazio disponibile sarà necessario rimuovere vra.ova con cui è stata fatta l’installazione da EASY INSTALLER. Oltre a rimuovere l’immagine da Binary Mapping sarà necessario rimuoverla fisicamente da /data via CLI

Mappiamo la ISO da Binary Mapping

La nuova immagine è disponibile per l’upgrade!

Andiamo a selezionare l’environment che ospita Aria Automation, VIEW DETAILS

Prima di procedere con l’upgrade eseguire un TRIGGER INVENTORY SYNC e verificare che il job si completi con successo

Torniamo alla procedura di upgrade, la nuova release è disponibile

Abilitare i flag per lo snapshot e l’eventuale rollback in caso di problemi durante l’upgrade

Verifichiamo i requisiti hardware per la nuova release seguendo il link evidenziato

La RAM necessaria è di 48GB, la mia attuale implementazione è MEDIUM e sarà necessario aumentare la RAM come richiesto. Per far questo utilizzare le day 2 operations dall’environment, prima POWER OFF, modificare la RAM dal vSphere Client e poi POWER ON. Attendere che i servizi ritornino attivi (richiede molto tempo!)

Riprendiamo l’upgrade eseguendo i pre-check

Andiamo all’Upgrade Summary e diamo Submit per iniziare l’upgrade

Attendiamo che il processo di upgrade si completi con successo

L’intero processo ha durato circa 1 ora, è possibile monitorare lo stato dei servizi direttamante dalla console di Aria Automation. Alla fine dell’upgrade il nostro environment sarà aggiornato 🙂

A questo punto abbiamo eseguito i primi 2 step del path di upgrade, allo stesso modo sarà possibile eseguire tutti gli altri step fino ad arrivare alla release 8.18 di LCM ed Aria Suite

NOTA: l’upgrade di Aria Automatin dalla release 8.16 alla 8.18 chiede 54GB di RAM come prerequisito.

Questi i file da scaricare per eseguire tutti gli upgrade

Prelude_VA-8.13.1.32340-22360938-updaterepo.iso

Prelude_VA-8.16.0.33697-23103949-updaterepo.iso

Prelude_VA-8.18.0.35770-24024333-updaterepo.iso

VMware-Aria-Suite-Lifecycle-Appliance-8.12.0.7-21628952-updaterepo.iso

VMware-Aria-Suite-Lifecycle-Appliance-8.14.0.4-22630472-updaterepo.iso

VMware-Aria-Suite-Lifecycle-Appliance-8.16.0.4-23377566-updaterepo.iso

NOTA: l’upgrade a LCM 8.18 può essere fatto direttamente dal repository online 🙂

Nel prossimo articolo racconterò come risolvere alcuni problemi incontrati durante l’upgrade e di come monitorare lo stato dei servizi di Aria Automation via CLI

Pubblicato in Aria Automation, upgrade, vmug | Contrassegnato , , | Commenti disabilitati su Upgrade vRA 8.11.2 to 8.18.0 – Aria Automation Series

Install vRealize Automation 8.11.2 – Aria Automation Series

Pubblicato il 5 Gennaio 2025 da scanda

Questo il primo articolo di una serie su Aria Automation. Si, il titolo parla dell’installazione della release 8.11.2, quando il prodotto si chiamava ancora vRealize Automation. Perchè trattare di una versione così vecchia? Perchè capita spesso di dover fare degli aggiornamenti su vecchie infrastrutture per portarle all’ultima release disponibile. Per me è indispensabile avere a disposizione delle vecchie release per verificare il path di upgrade da utilizzare dal cliente e verificarne ogni fase per assicurarmi che tutto venga aggiornato correttamente. Meglio fare esperienza su un laboratorio che direttamente sull’infrastruttura di produzione del cliente 😉

Colgo l’occasione per creare una guida d’installazione da condividere con chi ne avesse bisogno.

vRealize Automation necessità di altre componeti per il suo funzionamento : Workspace ONE Access e vRealize Suite Lifecyle Manager, Il primo è l’identity manager che gestisce gli accessi per tutti i prodotti vRealize/Aria e il secondo invece si occupa del lifecyle management (configurazione/upgrade).

Il metodo più semplice per installare vRealize Automation è tramite Easy Installer, si tratta di un ISO contenente il software necessario ad installare tutte le componenti menzioante. L’ISO è scaricabile dal sito Broadcom (serve un account che sia abilitato al download).

Una volta scaricata l’ISO sarà sufficiente fare il mount sulla nostra workstation e iniziare il processo d’installazione.

Successivamente eseguire l’installer per il proprio ambiente

Si apre la schermata d’installazione, next per proseguire.

Accettare l’EULA

Come prima cosa va inserito il vcenter su cui andrà eseguito il deploy di Lifecycle Manager, la prima appliance che verrà installata.

Selezionare il Datacenter, il cluster e il datastore

Inserire le informazioni sulla network a cui andrà collegata l’appliance, oltre a DNS e NTP

Inserire la password che verrà utilizzata per le utenze di root e di configurazione (admin@local)

Specificare il nome da utilizzare per la VM, il suo indirizzo IP e relativo FQDN

E’ possibile installare in un unico passaggio anche l’identity manager e vRealize Automation, preferisco farlo in un momento successivo direttamente da Lifecycle manager.

Andiamo al riepilogo di quanto selezionato e confermiamo l’installazione

Attendiamo che il processo abbia fine

Installazione completata con successo! Non resta che collegarci a Lifecycle manager

Per accedere utilizzare l’utenza admin@local con la password specificata nel wizard

Si presenta la prima pagina di Lifecycle, selezionare Locker per andare a caricare i certificati che andranno utilizzati per il deploy di Workspace ONE e vRealize Automation

Importare i certificati da utilizzare, uno per Workspace ONE e uno per vRealize Automation. I certificati devono essere in formato PEM e contenere, oltre al certificato stesso, anche la root CA con cui sono stati firmati e la relativa chiave pubblica. L’ordine dei certificati all’interno del PEM deve essere il seguente : certificato + root CA + chiave pubblica

Ripetere le stesse operazioni anche per il certificato di vRealize Automation

Procediamo con l’installazione di Workspace ONE, sarà necessario creare contestualmente il defaultEnvironment che lo ospiterà. Attivare il flag per l’installazione, creare la password da utilizzare per l’accesso a Workspace ONE e selezionare il Datacenter di destinazione

Selezionare Identity Manager, una nuova installazione, la versione e il tipo di deployment, per il mio laboratorio va benissimo la  Standard (per ambienti di produzione ovviamente selezionare la cluster)

Accettare l’EULA

Selezionare il certificato precedentemente importato

Inserire il vcenter, selezionare il cluster di destinazione e tutti gli altri dati necessari

Inserire i dati relativi alla rete a cui sarà collegata l’appliance

Selezionare il size dell’appliance (in questo caso Medium) e tutti gli altri dati

Eseguire i Pre check per verificare che tutti i dati siano corretti

Andare al riepilogo e dare submit per iniziare il deploy dell’appliance

Sotto le Requests sarà possibile seguire tutte le fasi d’installazione

Se l’installazione è andata a buon fine sarà possibile vedere l’identity manager presente nel globalEnvironment

Ora che il globalEnvironment è stato creato e Workspace ONE installato possiamo procedere con la creazione dell’environment per vRealize Automation e la sua installazione. La procedura è molto simile alla precedente.

Selezionare la componente da installare : vRealize Aria Automation

NOTA  : nella selezione sono presenti anche tutti gli altri prodotti della suite vRealize, tuttavia l’Easy Installer comprende la sola ISO di Automation

Accettare l’EULA

Selezionare la Licenza da utilizzare per vRealize Automation

Selezionare il certificato da utilizzare

Inserire il vcenter, il relativo cluster di destinazione e tutte le altre informazioni necessarie al deploy

Specificare le informazioni sulla rete

Selezionare il size dell’appliance, in questo caso Medium. Completare con tutte le altre informazioni.

Eseguire il pre check per verificare la correttezza dei dati inseriti

Andare al riepilogo e procedere con l’installazione dando submit

Attendere che la request d’installazione termini con successo

Ora è disponibile il nuovo environment con vRealize Automation

Collegarsi ad Automation per il primo accesso

Il logon viene reindirizzato a Workspace ONE per l’autenticazione, l’utenza e la password da utilizzare sono quelle specificate durante il wizard di creazione

Questo termina il primo articolo della serie, vedremo nel prossimo articolo come aggiornare vRealize Automation all’ultima versione di Aria Automation

Pubblicato in Aria Automation, vmug | Contrassegnato , | Commenti disabilitati su Install vRealize Automation 8.11.2 – Aria Automation Series

VCF 5.2 Administrator – my experience

Pubblicato il 21 Dicembre 2024 da scanda

Il bello e il brutto del mio lavoro? Non si finisce mai di imparare 🙂

Stare al passo con la tecnologia richiede un notevole sforzo in termini di tempo e denaro, essere sul pezzo può rivelarsi stressante ma allo stesso tempo stimolante. Ecco perchè le certificazioni fanno parte della mia formazione continua, sono delle tappe importanti che dimostrano i risultati raggiunti.

Perchè VMware Cloud Foundation Administrator ? Perchè rappresenta l’insieme di tutte le tecnologie su cui lavoro e su cui sto puntando in questi ultimi anni. Inoltre un recente studio (menzionato in questo articolo e alla vmware explore keynote) riporta che nei prossimi anni ci sarà un ritorno alle infrastrutture “on-premises”.

Sono sicuro che molti stanno pensando di affrontare quest’esame, lieto di condividere con tutti la mia personale esperienza!

Dettagli dell’esame

EsameVMware Cloud Foundation 5.2 Administrator
Codice2V0-11.24
Costo250$
Domande70
Tempo a disposizione135 minuti
Punteggio minimo300 (max 500)

NOTA: Come annunciato lo scorso maggio, non è più necessario frequentare un corso ufficiale per poter sostenere l’esame. Anche i costi sono stati modificati, ora tutti i tipi di esami (VCTA/VCP/VCAP) hanno lo stesso costo.

Preparazione

I dettagli dell’esame sono disponibili a questo link

Il blueprint è composto da 5 sezioni :

  1. IT Architectures, Technologies, Standards
  2. VMware by Broadcom Solution
  3. Plan and Design the VMware by Broadcom Solution
  4. Install, Configure, Administrate the VMware by Broadcom Solution
  5. Troubleshoot and Optimize the VMware by Broadcom Solution

Per l’esame possiamo ignorare le sezioni 1 e 3 e concentrarci sulle altre rimanenti. Da un rapido sguardo si intuisce subito il peso delle sezioni 4 (ben 4 pagine) e 5  sull’esame. Lo studio va concentrato prevalentemente su queste sezioni.

Gli obiettivi sono molti e su tutte le componenti di VCF. Come prepararsi per questo esame?

Ovviamente studiando la documentazione ufficiale, ricordo che VCF è composto da molti prodotti e per ognuno è necessario studiare la relativa guida:

  • Cloud Builder
  • SDDC Manager
  • VMware vCenter Server
  • VMware ESXi
  • VMware vSAN
  • VMware NSX
  • VMware Aria Suite Lifecycle

NOTA: aspettatevi domande su ognuno dei prodotti elencati 😉

Frequentare un corso ufficiale può sicuramente accelerare l’apprendimento, i dettagli dei corsi li trovate a questo link.

Altri validi strumenti sono gli Hands on Labs che vi permettono di esercitarvi su laboratori virtuali. La pratica è fondamentale per assimilare la teoria.

Il mio consiglio è quello di installare VCF partendo da zero, per me è stata un’esperienza fondamentale. Toccare con mano tutte le fasi d’installazione e configurazione resta il miglior studio : Learning by doing!

Se non disponete di un cluster con i requisiti per installare VCF potete provare la versione nested : Holodeck Tool Kit

NOTA : il link precedente porta ad una discussione su come scaricare l’ultima versione del Tool Kit, questo il form per richiedere il download

Ci sono molti articoli su come implementare Holodeck, vi lascio la ricerca 🙂

Esame

Si tratta del classico esame vmware: domande a scelta singola/multipla, indicare la giusta sequenza di eventi, associare termini e definizioni. Le domande vanno lette con calma ed attenzione, l’importante è rimanere lucidi e concentrarsi sulle risposte.

Dividete il tempo a disposizione per il numero di domande, non soffermatevi più del dovuto su una domanda. Se ne trovate una difficile, non bloccatevi: passate oltre, potete contrassegnarla e rivederela prima della sottomissione finale.

Cercate di rispondete a tutte le domande, fate attenzione al numero di risposte da selezionare per le domande a scelta multipla!

Alcune risposte sono palesemente errate, una buona strategia è quella di andare per esclusione: le risposte che restano, con buona probabilità, sono quelle giuste.

Le domande sono davvero di vario genere, si va da quelle semplici con risposta immediata a quelle che richiedono, oltre che ragionamento, anche l’esperienza di utilizzo degli strumenti. Ebbene si, ho trovato una domanda riguardante una KB di NSX che mi ha permesso di risolvere un problema poco tempo fa 🙂 Questo non significa che dovete leggervi tutte le KB esistenti ma che l’esame verifica la vostra reale esperienza delle varie tecnologie.

Conclusione

Superare l’esame VCF administrator richiede impegno, disciplina e una buona strategia di studio. Condividere la mia esperienza è stato un modo per ispirare e supportare chiunque voglia intraprendere questo percorso. Buono studio e in bocca al lupo!

Pubblicato in certification, vcf, vmug | Contrassegnato , , | Commenti disabilitati su VCF 5.2 Administrator – my experience

Deploy NSX ALB per TKG Standalone

Pubblicato il 27 Febbraio 2024 da scanda

Negli articoli precedenti abbiamo visto come creare un cluster TKG standalone utilizzando NSX ALB come bilanciatore, vediamo come installarlo e configurarlo per TKG.

Per prima cosa è necessario verificare quale versione è in matrice di compatibilità con la versione di vSphere e TKG che utilizziamo.

Nel mio caso ho utilizzato vSphere 7.0u3 e TKG 2.4

La verifica è necessaria perchè non tutte le release di ALB sono compatibili con vSphere e TKG, vediamo nel dettaglio la matrice per le versioni che ho utilizzato.

La Matrice di interoperabilità dei prodotti VMware è disponibile a questo link.

Le versioni di ALB utilizzabili sono la 22.1.4 e 22.1.3, ho scelto la più recente.

Alla release 22.1.4 andranno applicate anche le ultime patch.

I file da scaricare dal sito VMware sono i seguenti :

controller-22.1.4-9196.ova + avi_patch-22.1.4-2p6-9007.pkg

NOTA: Prima di iniziare il deploy dell’OVA verificate di aver creato i record DNS (A+PTR) per i controller e il VIP del cluster.

Iniziamo il deploy del controller sul nostro cluster vSphere.

Selezioniamo il file OVA

Diamo il nome alla VM e selezioniamo il Datacenter e il Cluster di destinazione

Al riepilogo ignorare i warning sul certificato, next

Nei prossimi passi selezionare il datastore e la network di management del controller

Inserire ora le impostazioni per l’interfaccia di management del controller

Al riepilogo selezioniamo FINISH per avviare il deploy

Accendiamo la VM e attendiamo che i servizi siano attivi (richiede un pò di tempo)

Al primo accesso sarà necessario inserire la password dell’utente admin

Inserire le informazioni necessarie a concludere la configurazione con SAVE

Per prima cosa applichiamo il tipo di licenza da utilizzare, per il laboratorio ho utilizzato la Enterprise con 1 mese di EVAL

Andiamo a modificare le impostazioni del cluster e del nodo inserendo l’indirizzo virtuale e l’FQDN, dare SAVE.

NOTA: dopo aver salvato le impostazioni si perderà per qualche istante la connettività con il nodo

Ora sarà possibile collegarsi al controller attraverso il VIP impostato

Applichiamo le utlime patch disponibili

selezioniamo il file precedentemente scaricato e carichiamolo

Attendiamo che l’upload si completi con successo

Eseguiamo l’upgrade

Lasciamo le impostazioni di default e diamo conferma

Seguiamo il processo di upgrade durante il quale il controller si riavvierà

Alla fine vedremo la patch applicata

Creiamo ora la zona Cloud associata al nostro vCenter per il deploy automatico dei Service Engine

Inseriamo il nome Cloud e poi inseriamo i dati di collegamento al vcenter

selezionare il Datacenter, l’eventuale Content Library e dare SAVE & RELAUNCH

Selezionare la network di management, subnet, defaut GW e specificare il pool per l’assegnazione degli ip statici ai Service Engine

Creaiamo ora il profilo IPAM che verrà utilizzato per i VIP richiesti dai cluster Tanzu

Salviamo e torniamo alla creazione della zona Cloud per dare anche qui conferma della creazione.

La nuova zona Cloud appare nell’elenco, verificate che sia online (pallino verde)

Generiamo ora un certificato SSL di tipo controller, è quello utilizzato nel wizard di creazione del cluster di management standalone di Tanzu

Sotto General inseriamo il nome e il Common Name del certificato, attenzione che rifletta l’effettivo record DNS (FQDN) utilizzato da Tanzu per accedere al controller AVI. Inserite tutti i campi necessari.

Completiamo il certificato con i giorni di validità (365 o più se volete) e inseriamo tutti i Subject Alternate Name con cui può essere invocato il certificato (IP address del VIP e dei controller, includiamo anche gli FQDN dei singoli controller)

Il certificato andrà utilizzato per accedere al VIP del controller, andiamo ad impostarlo per l’accesso.

Abilitiamo l’accesso HTTP e HTTPS nonchè il redirect su HTTPS.

Eliminiamo gli attuali certificati e selezioniamo quello appena creato.

NOTA: confermato il nuovo certificato sarà necessario ricollegarsi al controller

Rimane da inserire la rotta di default per il traffico in uscita dalla VRF associata alla nostra zona Cloud.

NOTA: verifichiamo sia selezionata la nostra zona Cloud nel campo Select Cloud

Inseriamo il default GW per tutto il traffico in uscita

Verifichiamo che sia presente la rotta

Completiamo la nostra configurazione creando un Service Engine Group da utilizzare per Tanzu. Questo ci permetterà di personalizzare le configurazioni degli SE utilizzati per Tanzu.

Inseriamo il nome e selezioniamo la nostra zona cloud.

Ora abbiamo un bilanciatore ALB pronto per servire i nostri cluster Tanzu 🙂

Pubblicato in ALB, nsx, tanzu, vmug | Contrassegnato , , , | Commenti disabilitati su Deploy NSX ALB per TKG Standalone

ESXi Network tools

Pubblicato il 19 Gennaio 2024 da scanda

Spesso capita di dover fare troubleshooting su un host ESXi per problemi di rete.

Nel tempo ho creato una piccola guida che mi aiuta a ricordare i vari comandi, la condivido sperando possa essere utile a tutti 🙂

esxcli network (qui l’elenco completo)

Verifico lo stato del firewall

esxcli network firewall get
Default Action: DROP
Enabled: true
Loaded: true

Abilito e disabilito il firewall

esxcli network firewall set --enabled false  (firewall disabled)

esxcli network firewall set --enabled true (firewall enabled)

Stato delle connessioni TCP/UDP

esxcli network ip connection list
Proto Recv Q Send Q Local Address                   Foreign Address       State       World ID CC Algo World Name
----- ------ ------ ------------------------------- --------------------- ----------- -------- ------- ----------
tcp        0      0 127.0.0.1:80                    127.0.0.1:28796       ESTABLISHED  2099101 newreno envoy
tcp        0      0 127.0.0.1:28796                 127.0.0.1:80          ESTABLISHED 28065523 newreno python
tcp        0      0 127.0.0.1:26078                 127.0.0.1:80          TIME_WAIT          0
tcp        0      0 127.0.0.1:8089                  127.0.0.1:60840       ESTABLISHED  2099373 newreno vpxa-IO
<line drop>

Server DNS configurati e dominio di ricerca

esxcli network ip dns server list

DNSServers: 10.0.0.8, 10.0.0.4

esxcli network ip dns search list

DNSSearch Domains: scanda.local

Elenco delle interfacce vmkernel

esxcli network ip interface ipv4 get
Name IPv4 Address   IPv4 Netmask  IPv4 Broadcast Address Type Gateway      DHCP DNS
---- -------------- ------------- -------------- ------------ ------------ --------
vmk0 172.16.120.140 255.255.255.0 172.16.120.255 STATIC       172.16.120.1 false
vmk1 172.16.215.11  255.255.255.0 172.16.215.255 STATIC       172.16.215.1 false

Netstack configurati sull’host (utilizzati sulle interfacce vmkernel)

esxcli network ip netstack list
defaultTcpipStack
Key: defaultTcpipStack
Name: defaultTcpipStack
State: 4660

vmotion
Key: vmotion
Name: vmotion
State: 4660

Elenco delle schede di rete fisiche

esxcli network nic list
Name   PCI Device   Driver  Admin Status Link Status Speed Duplex MAC Address       MTU  Description
------ ------------ ------- ------------ ----------- ----- ------ ----------------- ---- -----------
vmnic0 0000:04:00.0 ntg3    Up           Down        0     Half   ec:2a:72:a6:bf:34 1500 Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic1 0000:04:00.1 ntg3    Up           Down        0     Half   ec:2a:72:a6:bf:35 1500 Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet
vmnic2 0000:51:00.0 bnxtnet Up           Up          25000 Full   00:62:0b:a0:b2:c0 1500 Broadcom NetXtreme E-Series Quad-port 25Gb OCP 3.0 Ethernet Adapter
vmnic3 0000:51:00.1 bnxtnet Up           Up          25000 Full   00:62:0b:a0:b2:c1 1500 Broadcom NetXtreme E-Series Quad-port 25Gb OCP 3.0 Ethernet Adapter
vmnic4 0000:51:00.2 bnxtnet Up           Up          25000 Full   00:62:0b:a0:b2:c2 1500 Broadcom NetXtreme E-Series Quad-port 25Gb OCP 3.0 Ethernet Adapter
vmnic5 0000:51:00.3 bnxtnet Up           Up          25000 Full   00:62:0b:a0:b2:c3 1500 Broadcom NetXtreme E-Series Quad-port 25Gb OCP 3.0 Ethernet Adapter

vmkping (KB di riferimento)

comando per inviare pacchetti ICMP attraverso le interfacce vmkernel, utilissimo per verificare l’MTU 🙂

esempi di utilizzo

ping verso un host
vmkping -I vmk0 192.168.0.1

check MTU e fragmentation
vmkping -I vmk0 -d -s 8972 172.16.100.1

ping verso un host utilizzando il netstack vmotion
vmkping -I vmk2 -S vmotion 172.16.115.12

iperf ( ottimo articolo qui)

tool utilissimo per verificare l’effettiva banda utilizzabile tra 2 host, un host utilizza la modalità server e uno quella client

il tool si trova a questo path

/usr/lib/vmware/vsan/bin/iperf3

NOTA: nella versione di vSphere 8 si può avere l’errore ” Operation not permitted” all’esecuzione, è possibile abilitarne l’esecuzione con il comando

esxcli system secpolicy domain set -n appDom -l disabled

successivamente riattivare con

esxcli system secpolicy domain set -n appDom -l enforcing

è inoltre necessario disabilitare temporaneamente il firewall per effettuare i test

esxcli network firewall set --enabled false

esempio di utilizzo:

host modalità server, l’opzione -B permette di utilizzare uno specifico indirizzo e interfaccia per i test

 /usr/lib/vmware/vsan/bin/iperf3 -s -B 172.16.100.2

host modalità client, l’opzione -n specifica la quantità di dati da trasferire per i test

/usr/lib/vmware/vsan/bin/iperf3 -n 10G -c 172.16.100.2

risultato del test su interfacce 25G

[ ID] Interval        Transfer    Bitrate        Retr
[  5]   0.00-4.04 sec 10.0 GBytes 21.3 Gbits/sec 0    sender
[  5]   0.00-4.04 sec 10.0 GBytes 21.3 Gbits/sec      receiver

NOTA : a fine test ricordarsi di riabilitare il firewall e l’enforcing 🙂

nslookup e cache DNS (KB di riferimento)

A volte è necessario verificare il corretto funzionamento della risoluzione dei nomi DNS su un host.

utilizzare il comando nslookup seguito dal nome da risolvere

nslookup www.scanda.it

Può capitare che modifiche ai record DNS non vengano recepiti immediatamente dagli host esxi, questo è dovuto al meccanismo di caching delle query DNS.

Per pulire la cache DNS utilizzare il seguente comando (KB di riferimento)

/etc/init.d/nscd restart

Test di connettività TCP/UDP

sugli host esxi è presente il tool netcat (nc) che permette di verificare la connettività TCP/UDP verso un altro host.

nc
usage: nc [-46DdhklnrStUuvzC] [-i interval] [-p source_port]
[-s source_ip_address] [-T ToS] [-w timeout] [-X proxy_version]
[-x proxy_address[:port]] [hostname] [port[s]]

Se si deve verificare l’accesso ad un servizio HTTPS e la validità del relativo certificato SSL si può utilizzare il comando

openssl s_client -connect www.dominio.it:443

pktcap-uw (KB di riferimento)

altro tool molto utile è pktcap-uw che permette di catturare traffico di rete in pieno stile tcpdump. il tool si differenzia da tcpdump-uw in quanto può catturare il traffico, oltre che dalle interfacce vmkernel, anche da interfacce fisiche, da switchport e virtual machine.

vediamo qualche esempio

cattura del traffico dal vmkernel vmk0

pktcap-uw --vmk vmk0

cattura del traffcio dall’uplink fisico vmnic3

pktcap-uw --uplink vmnic3

cattura del traffico da una porta di un virtual switch

pktcap-uw --switchport <switchportnumber>

NOTA: per avere la mappatura del port number e la virtual nic di una VM utilizzare il comando net-stats -l

E’ possibile recuperare informazioni dal protocollo LLDP anche da uplink utilizzati da un VSS (non supportano LLDP) con il seguente comando

pktcap-uw --uplink vmnic1 --ethtype 0x88cc -c 1 -o /tmp/lldp.pcap > /dev/null && hexdump -C /tmp/lldp.pcap

L’output sarà in formato esadecimale e potrà essere utile per eseguire la mappatura delle porte di un host anche su un Virtual Standard Switch.

Non mancherò di aggiornare la lista con altri comandi utili.

 

Pubblicato in esxi, networking, troubleshooting, vmug, vsphere | Contrassegnato , , , , | Commenti disabilitati su ESXi Network tools

Deploy TKG Standalone Cluster – parte 2

Pubblicato il 12 Gennaio 2024 da scanda

Ecco il secondo articolo della serie, trovate il primo a questo link.

Ora che la bootstrap machine è pronta possiamo procedere con la creazione del cluster standalone.

Colleghiamoci alla bootstrap machine e lanciamo il comando che avvia il wizard.

NOTA: di default il wizard viene avviato sulla loopback, se si vuole raggiungerlo esternamente è sufficiente specificare l’opzione –bind con l’ip di un’interfaccia locale.

tanzu management-cluster create --ui 
or
tanzu management-cluster create --ui --bind 10.30.0.9:8080

Collegandoci con un browser all’indirizzo specificato vedremo la pagina del wizard.

Selezioniamo la tipologia di cluster di cui fare il deploy, in questo caso vSphere.

NOTA: la chiave SSH è quella generata nella prima parte, riportarla correttamente ( nell’immagine manca ssh-rsa AAAAB3N… )

Selezionare Deploy TKG Management Cluster

Selezionare il tipo di controlplane, il size dei nodi e il bilanciatore

NOTA: in questo caso ho scelto di utilizzare NSX ALB che deve essere già stato installato e configurato

Inserire le specifiche per NSX ALB

Inserire eventuali dati nella sezione Metadata

Selezionare la VM folder, il Datastore e il cluster da utilizzare per il deploy

Selezionare la Kubernetes network

Se necessario, configurare l’identity provider

Selezionare l’immagine da utilizzare per la creazione dei nodi del cluster

NOTA: è l’immagine precedentemente caricata e convertita come template

Selezionare se abilitare CEIP

Il deploy ha inizio, seguire le varie fasi e verificare non ci siano errori

Il deploy richiede del tempo per la creazione

E’ ora possibile collegarsi al cluster dalla bootstrap machine e verificarne il funzionamento

tanzu mc get

Scarichiamo ed installiamo i Carvel tools sulla bootstrap machine

Le istruzioni per l’installazione si trovano nella documentazione ufficiale

Verificare che i tools siano stati correttamente installati

Possiamo ora creare un nuovo cluster di workload

Dopo la creazione del cluster di management troviamo il suo file di definizione al percorso ~/.config/tanzu/tkg/clusterconfigs
Il file ha un nome generato casualmente ( 9zjvc31zb7.yaml ), viene poi convertito in un file con le specifiche per la creazione del cluster ( tkgvmug.yaml )

Fare una copia del file 9zjvc31zb7.yaml dando il nome del nuovo cluster da creare (myk8svmug.yaml )

Editare il nuovo file modificando la variabile CLUSTER_NAME inserendo il nome del nuovo cluster

Lanciamo il comando per la creazione del nuovo cluster

tanzu cluster create --file ~/.config/tanzu/tkg/clusterconfigs/myk8svmug.yaml

Accediamo al nuovo cluster

tanzu cluster kubeconfig get --admin myk8svmug
kubectl config get-contexts
kubectl config use-context myk8svmug-admin@myk8svmug

Possiamo ora installare le nostre applicazioni nel nuovo cluster di workload

 

 

Pubblicato in kubernetes, tanzu | Contrassegnato , | Commenti disabilitati su Deploy TKG Standalone Cluster – parte 2

Deploy TKG Standalone Cluster – parte 1

Pubblicato il 10 Gennaio 2024 da scanda

Ho avuto il piacere di partecipare alla scorsa UserCon Italiana portando una sessione su Tanzu Kubernetes Grid e la creazione di un cluster di management standalone. Ho preso spunto dall’esperienza per creare una serie di articoli sull’argomento.

Come già detto questa serie di articoli è su TKG Standalone versione 2.4.0, è bene precisare che la soluzione più comune da utilizzare è TKG Supervisor (si veda la documentazione ufficiale a riguardo).

Ma allora quando ha senso utilizzare TKG Standalone?

  • Quando utilizziamo AWS o Azure
  • Quando utilizziamo vSphere 6.7 (vsphere with Tanzu è stata introdotta solo dalla versione 7)
  • Quando utilizziamo vSphere 7 e 8 ma necessitiamo delle seguenti features : Windows Containers, IPv6 dual stack e la creazione di workload cluster su siti remoti gestiti da un vcenter server  centralizzato

Vediamo i requisiti per la creazione di TKG Standalone:

  • una bootstrap machine
  • una delle seguenti infrastrutture:  vSphere 8, vSphere 7, VMware Cloud on AWS, or Azure VMware Solution

Ho riportato solo i principali requisiti, per tutti i dettagli fate riferimento al link ufficiale.

Dimensionamento del Cluster di Management

Di seguito una tabella che riporta quali risorse allocare per i nodi del cluster di management in base al numero di cluster di workload da gestire.

Per poter creare il cluster di management è necessario importare le immagini da utilizzare per i nodi, le immagini sono disponibili dai downlaod del sito vmware.

Consiglio di utilizzare le utlime versioni disponibili:

  • Ubuntu v20.04 Kubernetes v1.27.5 OVA
  • Photon v3 Kubernetes v1.27.5 OVA

Una volta importata l’immagine è necessario convertirla in template.

Creiamo la nostra bootstrap machine

Forse è la parte più divertente 🙂 io ho scelto un sistema operativo Linux, nello specifico Ubuntu server 20.04.

I requisiti consigliati per la bootstrap machine sono i seguenti : 16GB di RAM, 4 cpu e almeno 50GB di spazio disco.

Ecco i dettagli della mia

Aggiornare all’ultimo pacchetto disponibile

sudo apt update
sudo apt upgrade

E’ importante che la data e l’ora siano sincronizzati via NTP

Se si utilizza la bootstrap machine in ambiente isolato è utile installare anche l’ambiente grafico per poter utilizzare un browser ed altri strumenti grafici.

apt install tasksel
tasksel install ubuntu-desktop
reboot

Installare Docker

Manage Docker as a non-root user

sudo groupadd docker
sudo usermod -aG docker $USER
docker run hello-world

Configure Docker per avviarsi automaticamente con systemd

sudo systemctl enable docker.service
sudo systemctl enable containerd.service

Attivare kind

sudo modprobe nf_conntrack

Installare Tanzu CLI 2.4

Verificare via Product Interoperability Matrix quale versione è compatibile con TKG 2.4

Identificata la versione compatibile è possibile scaricarla dal sito vmware

Procedere all’installazione della CLI nella bootstrap machine (come utente non root)

mkdir tkg
cd tkg
wget https://download3.vmware.com/software/TCLI-100/tanzu-cli-linux-amd64.tar.gz
tar -xvf tanzu-cli-linux-amd64.tar.gz
cd v1.0.0
sudo install tanzu-cli-linux_amd64 /usr/local/bin/tanzu
tanzu version

Installare i plugins TKG

tanzu plugin group search -n vmware-tkg/default --show-details
tanzu plugin install --group vmware-tkg/default:v2.4.0
tanzu plugin list

Scaricare ed installare nella bootstrap machine la kubernetes CLI per Linux

cd tkg
gunzip kubectl-linux-v1.27.5+vmware.1.gz
chmod ugo+x kubectl-linux-v1.27.5+vmware.1
sudo install kubectl-linux-v1.27.5+vmware.1 /usr/local/bin/kubectl
kubectl version --short --client=true

Abilitiamo l’autocompletamento per kubectl e Tanzu CLI

echo 'source <(kubectl completion bash)' >> ~/.bash_profile

echo 'source <(tanzu completion bash)' >> ~/.bash_profile

Come ultima cosa generiamo le chiavi SSH da utilizzare nel wizard di creazione del cluster di management

ssh-keygen
cat ~/.ssh/id_rsa.pub

Con quest’ultima operazione abbiamo completato la prima parte dell’articolo.

La seconda parte è disponibile a questo link

Pubblicato in kubernetes, tanzu | Contrassegnato , | Commenti disabilitati su Deploy TKG Standalone Cluster – parte 1

NSX-T Upgrade

Pubblicato il 14 Dicembre 2022 da scanda

La serie di articoli sull’installazione di NSX-T è partita con la versione 3.1.x, è giunto il momento di fare l’upgrade alla 3.2 🙂

L’upgrade è completamente gestito da NSX Manager, vediamone il processo partendo dalla documentazione ufficiale.

La versione di arrivo per l’upgrade sarà la 3.2.2, questo perchè l’Upgrade Evaluation Tool è ora integrato con la fase di controlli di pre-upgrade. Non si dovrà pertanto eseguire il deploy dell’apposito OVF 😉

Scarichiamo quindi l’NSX 3.2.2 Upgrade Bundle dal nostro account My VMware.

NOTA: attenzione, il bundle supera gli 8GB di spazio disco.

Dimenticavo, verifichiamo che la versione di vSphere sia in matrice con la versione di NSX-T di arrivo. Il mio cluster è in 7.0U3, pienamente supportato dalla 3.2.2 di NSX-T 🙂

Collegarsi a NSX Manager via SSH e verificare che il servizio di upgrade sia attivo.

eseguire come utente admin il comando : get service install-upgrade

Il servizio è attivo, collegarsi alla UI del NSX Manager e spostarsi su System -> Upgrade

Selezionare UPGRADE NSX

Caricare il bundle di aggiornamento

attendere il caricamento del bundle (il processo può richiedere del tempo)

Dopo il caricamento hanno inizio i pre-check sul bundle.

Completati i controlli preliminari è possibile proseguire con gli aggiornamenti. Selezionare il tasto UPGRADE.

Accettare la licenza e dare conferma alla richiesta di iniziare l’upgrade.

Selezionare il tasto RUN PRE-CHECK e poi ALL PRE-CHECK.

I pre-checks vengono eseguiti, nel caso di segnalazioni sarà necessario risolvere ogni problema fino a quando tutti i controlli risulteranno a posto.

Proseguire con l’aggiornamento degli Edges selezionando il tasto NEXT.

Selezionare l’Edge Cluster ed avviare l’aggiornamento con il tasto START.

Inizia l’aggiornamento degli Edges che compongono il cluster, il processo si interrompe in caso di completamento con successo o al primo errore riscontrato.

Una volta completato con successo l’upgrade eseguire i POST CHECKS.

Se tutto è a posto proseguire con l’aggiornamento degli hosts esxi. Selezionare NEXT.

Selezionare il cluster di hosts ed avviare l’aggiornamento con tasto START.

Alla fine dell’aggiornamento eseguire i POST CHECKS.

Ora rimane da aggiornare NSX Manager, selezionare NEXT per proseguire.

Selezionare START per avviare l’upgrade del NSX Manager.

Il processo di upgrade esegue prima dei pre checks e poi passa all’aggiornamento del Manager.

L’aggiornamento prosegue con il riavvio del Manager, una nota ricorda che fino al completamento dell’aggiornamento non sarà possibile collegarsi alla UI.

Una volta riavviato il Manager e completato l’upgrade sarà possibile accedere alla UI e verificare l’esito dell’aggiornamento. Spostarsi su System -> Upgrade

E’ possibile vedere i dettagli di ogni fase di aggiornamento. Come avete potuto vedere il processo di upgrade è semplice e strutturato.

Upgrade a NSX-T 3.2.2 completato con successo 🙂

Pubblicato in nsx, upgrade, vmug | Contrassegnato , , | Commenti disabilitati su NSX-T Upgrade

Create host transport nodes

Pubblicato il 12 Dicembre 2022 da scanda

Ultimo articolo della serie riguarda la preparazione degli hosts esxi per trasformarli in Trasnport Nodes.

Prima è necessario creare alcuni profili da utilizzare successivamente per la preparazione degli hosts.

Dalla console del Manager spostarsi su System -> Fabric -> Profiles -> Uplink Profiles.

Selezionare + ADD PROFILE

Inserire il nome del profilo di uplink, se non si utilizzano LAG (LACP) spostarsi alla sezione successiva.

Selezionare la Teaming Policy (di default Failover Order) ed inserire il nome dell’uplink attivo. Inserire l’eventuale VLAN ID da utilizzare per la rete dell’overlay e il valore di MTU.

Spostarsi ora su Transport Node Profiles

Selezionare + ADD PROFILE

Inserire il nome del profilo, selezionare la tipologia di Distributed switch (lasciare la modalità Standard), selezionare il Compute Manager ed il relativo Distributed switch.

Nella sezione Transport Zone indicare le transport zone da configurare sugli hosts.

Completare il profilo selezionando il profilo uplink precedentemente creato, la metodologià di assegnazione degli indirizzi TEP e mappare l’uplink del profilo a quello del Distribute switch.

Creare il profilo con il tasto ADD.

Spostarsi su System -> Fabric -> Host Transport Nodes.

Sotto Managed By selezionare il Compute Manager con il cluster vSphere da preparare.

Selezionare il cluster e CONFIGURE NSX.

Selezionare il profilo Transport Node appena creato e dare APPLY.

Inizia l’installazione e la preparazione dei nodi del cluster.

Attendere che il processo di configurazione finisca con esito positivo e che i nodi siano nello stato UP.

La nostra installazione di base di NSX-T si può ritenere finalmente conclusa 🙂

Da qui possiamo iniziare a configurare i segmenti delle VM e la parte di routing dinamico con il mondo esterno nonchè tutti gli altri aspetti di sicurezza!

Pubblicato in nsx, vmug | Contrassegnato , | Commenti disabilitati su Create host transport nodes