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

Create an NSX Edge cluster

Pubblicato il 12 Dicembre 2022 da scanda

Ora che abbiamo creato i nostri Edges non resta che associarli ad un nuovo Edge Cluster.

Dalla console del Manager spostarsi su System -> Fabric -> Nodes -> Edge Cluster.

Selezionare + ADD EDGE CLUSTER

Inserire il nome del nuovo Edge Cluster, il profilo viene proposto in automatico.

Nella sezione di sotto selezionare gli Edges precedentemente creati e spostarli all’interno del cluster con la freccia di destra. Dare conferma di creazione con il tasto ADD.

Il cluster viene riportato nell’elenco con alcune delle sue caratteristiche.

Ora che il cluster è stato creato sarà possibile creare un T0 gateway da utilizzare per la connettività esterna.

Dalla console del Manager spostarsi su  Networking-> Tier-0 Gateways .

Selezionare + ADD GATEWAY -> Tier-0

Inserire il nome del nuovo T0 gateway, l’HA mode ed associare l’Edge Cluster appena creato. Non è un campo obbligatorio ma necessario se vogliamo collegare i nostri segmenti al mondo fisico. Tramite gli Edges sarà possibile definire delle interfacce con cui permettere al T0 di fare peering BGP con dei ToR esterni.

Una volta creato il T0 con il tasto SAVE, possiamo chiudere l’editing selezionando NO.

Pochi secondi e il nuovo T0 sarà pronto all’uso!

Pubblicato in nsx, vmug | Contrassegnato , | Commenti disabilitati su Create an NSX Edge cluster

Install NSX Edges

Pubblicato il 11 Dicembre 2022 da scanda

Componenti fondamentali di NSX sono gli edges che forniscono funzionalità quali routing e collegamento con il mondo esterno, servizi NAT, VPN e altro ancora.

Vediamo brevemente i requisiti necessari alla loro installazione.

Appliance SizeMemoryvCPUDisk SpaceNotes
NSX Edge Small4GB2200GBlab and proof-of-concept deployments
NSX Edge Medium8GB4200GBSuitable for NAT, routing, L4 firewall and throughput less than 2 Gbps
NSX Edge Large32GB8200GBSuitable for NAT, routing, L4 firewall, load balancer and throughput up to 10 Gbps
NSX Edge Extra Large64GB16200GBSuitable when the total throughput required is multiple Gbps for L7 load balancer and VPN

Come si  può intuire dalla tabella è necessario conoscere in anticipo i servizi che andranno configurati sugli edges e il throughput del traffico totale.

Per ambienti di produzione è necessario utilizzare almeno il size Medium.

NSX Edge è supportato solo su ESXi con processori Intel e AMD (questo per supportare DPDK)

Se si utilizza EVC, la generazione minima supportata è Haswell.

Fatte le opportune considerazioni sul dimensionamento si può procedere all’installazione dell’Edge.

Dalla console del Manager spostarsi su System -> Fabric -> Nodes -> Edge Transport Nodes.

Selezionare + ADD EDGE NODE

Inseriamo le informazioni necessarie a completare il wizard.

Per il laboratorio la versione small è sufficiente, ricordarsi di verificare che l’FQDN sia stato creato come record sui DNS.

Inserire le credenziali dell’utenza admin, di root e dell’eventuale utente di audit.

In questo caso ho abilitato i flags che permettono l’accesso via SSH ad admin e root, questo per poter eseguire delle verifiche dirette sull’edge.

Selezionare il compute manager su cui verrà eseguito il deploy dell’edge. Indicare il cluster e tutte le informazioni necessarie.

Inserire le informazioni relative alle configurazioni della rete di management, si tratta della rete con cui NSX Manager configurerà e gestirà l’edge. L’indirizzo ip dovrà corrispondere al’FQDN inserito nella prima pagina del wizard.

Come ultima configurazione bisogna indicare quale Transport Zone andrà associata al virtual switch a cui è connesso l’edge. Specificare l’uplink profile, il metodo di assegnamento dell’indirizzo TEP e l’interfaccia/portgroup da associare all’uplink.

Questa è l’ultima pagina del wizard, se tutte le informazioni sono state inserite correttamente ha inizio il deploy dell’edge.

Allo stesso modo è possibile creare altri edges da utilizzare successivamente per la creazione di un Edge Cluster.

 

 

Pubblicato in nsx, vmug | Contrassegnato , | Commenti disabilitati su Install NSX Edges

NSX Create transport zones

Pubblicato il 8 Gennaio 2022 da scanda

Proseguiamo il nostro viaggio su NSX aggiungendo altri tasselli alla nostra installazione.

Andiamo a definire le Transport Zones a cui andremo a collegare i transport nodes e gli edges. Normalmente vengono definite due Transport Zones.

Colleghiamoci alla console del Manager e spostiamoci su System -> Fabric -> Transport Zones

Selezioniamo + ADD ZONE e creiamo una transport zone di tipo Overlay.

Allo stesso modo creiamo anche una transport zone di tipo VLAN.

Nel riepilogo avremo ora le nostre due Transport Zones.

Procediamo creando i profili di uplink da utilizzare sui transport node e sugli edges.

Spostiamoci su System -> Fabric -> Profiles, selezioniamo + per aggiungere i nuovi profili.

Inseriamo il nome del profilo e completiamo la sezione Teamings specificando la Teaming Policy e gli Uplink.

Questo è il profilo per i transport nodes (ESXi)

Di default viene proposta la Teaming Policy Failover, ho specificato il nome dei due uplink (verranno utilizzati più tardi nella configurazione dei transport nodes).

Specificare anche la VLAN che verrà utilizzata per il trasporto del traffico di overlay.

Creiamo anche il profilo per gli edges.

In questo caso non ho configurato l’uplink di standby e la VLAN di trasporto, gli edges sono delle appliance virtuali collegate a dei port groups. La ridondanza e il tagging delle VLAN è demandato al VDS.

Definiamo gli IP Pool da utilizzare per l’assegnazione dei VTEP agli edges e ai transport nodes.

Spostiamoci su Networking -> IP Management -> IP Address Pools e selezioniamo ADD IP ADDRESS POOL.

Specifichiamo il nome e definiamo la subnet.

Allo stesso modo configuriamo l’IP pool da utilizzare per gli edges, naturalmente utilizzerà una subnet diversa.

NOTA: le due subnet appena configurate dovranno essere ruotate tra loro e permettere un MTU di almeno 1600. Questo per consentire la connettività tra transport nodes ed edges.

Ora abbiamo tutti gli elementi per configurare gli Edges e i Transport nodes 🙂

Pubblicato in nsx, vmug | Contrassegnato , | Commenti disabilitati su NSX Create transport zones