VMware Broadcom – Cosa fare ?

Broadcom's Acquisition of VMware Closed: What Now?

Broadcom ha dato una grande scossa al  2024.

Dagli ultimi rumors, sembra che il licensing della appena acquisita VMware verrà pesantemente rivisto.

Uno dei primi risultati è che molti clienti si chiedono cosa sia giusto fare.

Non ho la pretesa di conoscere la risposta corretta.

Ho effettuato alcune riflessioni che mi hanno portato a pensare a quattro futuri scenari  dei quali vi parlerò nel presente articolo.

  1. Il cliente continua la collaborazione con VMware/Broadcom.
  2. Il cliente sostituisce la tecnologia Hypervisor.
  3. Il cliente migra il proprio datacenter verso un Hyperscaler o  un Service Cloud Provider Locale.
  4. Il cliente trasforma il proprio Datacenter in un  “Datacenter as a Software”.

Per ogni scenario andrò ora a descrivere i macroscopici pro e contro.

1. Credo che il desiderato di Broadcom sia quello di semplificare il più possibile il licensing al fine di avere a portfolio soluzioni snelle e semplici da proporre.

Ciò implica eliminare alcune delle soluzioni ora presenti per concentrare le  energie unicamente su quelle a maggior rilevanza d’uso e guadagno.

Ora vi domando: Le soluzioni VMware ora presenti nel vostro datacenter sono quelle strategiche anche per Broadcom?

E ancora, siamo certi che l’ottimizzazione Broadcom non toccherà il dipartimento R&D di VMware che sviluppa le soluzioni divenute ora strategiche?

E non per ultimo, quale sarà il prezzo per poter rimanere nell’ecosistema Broadcom-VMware?

2. La prima sfida è quella di fornirsi di strumenti in grado di migrare le VM da una tecnologia HyperVisor all’altra.

La seconda è quella di proteggerle.

(NDR. Meno male che Veeam Backup & Replication permette di realizzare con un solo strumento entrambe le cose 🙂 )

Aggiungo, che bisognerà essere anche fortunati nello scegliere un vendor che non sia nel mirino di una nuova Broadcom, perché finire nello stesso giro dantesco sarebbe diabolico.

Pensare ad una tecnologia open-source based?

3. Il modello degli Hyper-Scaler è quello di fornire una serie di servizi  personalizzabili.

Spesso sento qualcuno affermare che esistano dei “costi nascosti”.  Non è vero, sono tutti ben illustrati, solo che capirli preventivamente è spesso molto difficile.

Avrà quindi particolare importanza la fase di creazione del progetto di migrazione che dovrà essere particolarmente accurata al fine di non ritrovarsi brutte sorprese  a fine mese .

4. Data Center as a Software è sinonimo di un’architettura Cloud Native.

Ciò implica riscrivere applicazioni e servizi in modo tale che siano  indipendenti dal HyperVisor.

E’ il nuovo approccio che negli anni diventerà un comune standard per scrivere codice.

Nel sito troverete una serie di articoli sul mondo Container e kubernetes ai quali vi rimando.

Tante domande, una sola risposta giusta?

No, credo che la migliore strategia sia quella di ricercare il miglior bilanciamento nell’utilizzo delle diverse opzioni disponibili, per arrivare a regime con la soluzione che si adatta al meglio alle necessità della vostra azienda in un corretto bilanciamento tra costi e benefici.

Ultima nota: Non dimenticate mai di aggiungere dei piani di formazione del personale perchè il training on the job in scenari particolarmente complessi NON è mai la via migliore per rendere sicuri i vostri sistemi ovunque questi siano

ESXi v.7: patching host

In questo articolo illustrerò la procedura per aggiornare l’Host ESXi quando l’ambiente VMware è composto da un solo server.

Nota 1: La prima attività è quella di aggiornare il vCenter (VCSA) controllando quali versioni ESXi sono supportate.

Nota 2: Il metodo tradizionale per aggiornare gli Host ESXi, sfrutta il processo automatizzato di update gestisto dalla console del vCenter.

Nota 3: Il sito di DR del mio laboratorio è costituito da un singolo Host VMware ESXi sul quale è presente il vCenter secondario (VCSA); in questo scenario, la metodologia indicata nella nota 1  non è utilizzabile, poiché durante la fase di aggiornamento, l’Host ESXi viene posto in maintenance mode. In questo stato tutte le VM presenti sono spente (compresa la VCSA).

La soluzione è quella di utilizzare la procedura presente nel sito VMware ESXi Patch Tracker che consta delle seguenti fasi:

1- Selezione della versione software che sarà installata alla fine del processe sull’host (vedi immagine 1)

Immagine 1

2- Determinare i comandi CLI da utilizzare durante la procedura di aggiornamento:

La procedura viene illustrata nel pop-up che appare quando si clicca sul pacchetto selezionato (vedi immagine 2)

Immagine 2

3- Abilitare l’Host ESXi alla connessione ssh (immagine 3)

Immagine 3

4- Collegarsi via ssh all’host ESXi ed avviare i comandi precedentemente mostrati nel pop-up.

Nel mio caso:

  1. esxcli network firewall ruleset set -e true -r httpClient
  2. esxcli software profile update -p ESXi-7.0U3d-19482537-standard \ -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
  3. esxcli network firewall ruleset set -e false -r httpClient

5- Porre l’Host ESXi in Maintenance mode e riavviarlo.

6- Al termine controllate che l’aggiornamento sia avvenuto correttamente (immagine 4 e 5)

Immagine 4 – Pre Aggiornamento

Immagine 5 – Post Aggiornamento

Nota 4: Nel caso in cui l’hardware non fosse in matrice di compatibilità, il consiglio è di utilizzare l’opzione <–no-hardware-warning>. Nel mio caso il secondo comando è stato cambiato in:

esxcli software profile update -p ESXi-7.0U3d-19482537-standard \ -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml –no-hardware-warning

A presto

Tips VMware – Module MonitorLoop power on failed

Durante le operazioni di manutenzione del laboratorio, improvvisamente una Virtual Machine non era più in grado di avviarsi.

La console del vCENTER indicava un errore sull’inizializzazione del file di swap del server.

Come ogni buon sistemista, prima di effettuare una qualsiasi modifica all’ambiente, ho provato a realizzare il backup della suddetta VM.

Il job si interrompeva a causa del seguente errore: (“An error occurred while taking a snapshot: Invalid change tracker error code“).

Troubleshooting:

  1. Dato che il file di swap gestisce l’over-commitment della memoria, ho provato a modificare la quantità di RAM assegnata.
  2. Ho aggiunto spazio al Datastore sul quale risiedeva la VM per essere certo che VMware avesse sufficiente spazio per gestire il file di swap.
  3. Ho ricercato all’interno del file di configurazione (vmx) differenze rispetto alla configurazione delle altre VM.

Tutti test e le modifiche effettuate non hanno risolto il problema.

Conscio che avrei dovuto modificare la configurazione della VM ho implementato una semplice strategia per:

  • Realizzare il backup della VM attraverso il Veeam Agent for Linux (Il VAL opera a livello di Guest-OS e non di hypervisor).
  • Annotare tutte le modifiche che avrei apportato alle VM (ndr: avevo indossato il cappello di Pollicino, in grado cioè di tornare alla configurazione iniziale in poco tempo).

Il metodico approccio “cambia, annota, controlla e accendi” mi ha permesso di scoprire che il problema era legato alla configurazione della CPU della Virtual Machine.

Reimpostando infatti i valori “CPU reservation” a Zero e “CPU share” a Normal (vedi immagine 1) il problema è rientrato permettendomi così di avviare la VM e effettuarne il backup.

Sapiens nihil affirmat quod non probet (il saggio non afferma nulla che non possa provare)

Immagine 1

Veeam Disaster Recovery Orchestrator v.5: Verifica dei componenti

Il presente articolo illustra come configurare il menù di amministrazione del Veeam Disaster Recovery Orchestrator (VDrO).

Prima di procedere alla fase di amministrazione, è indispensabile aver già etichettato le risorse che dovranno far parte dei piani di Disaster Recovery.

La classificazione è stata illustrata nel precedente articolo, disponibile cliccando sul seguente link: VDrO – VOne – Tagging.

Nota 1: Per accedere al menù di amministrazione, selezionate la voce denominata “Administration” (vedi immagine 1)

Immagine 1

La configurazione del menù di amministrazione si divide in tre principali aree:

Nella prima sono impostate:

  • Il nome del VDrO Server e il contact name (immagine 2).
  • le connessioni verso i Veeam Backup & Replication Server (VBR) (immagine 3)
  • le connessioni verso i vCenter (immagine 4)
  • la connessione opzionale verso gli storage (immagine 5) (fate riferimento al presente articolo per scoprire i dettagli)

Immagine 2

Immagine 3

Immagine 4

Immagine 5

La seconda area identifica attraverso il tagging le risorse da aggiungere ai piani di DR:

  • La recovery location (immagine 6)
  • Nella recovery location i datastore ove i filesystem delle VM resiederanno (immagine 7)
  • Il mapping delle reti (immagine 8)
  • Il remapping degli indirizzi IP (immagine 9)

Nota 2: Le operazioni sopra descritte sono possibili se e solo se tutte le risorse necessarie sono state etichettate.

Nota 3: Il remapping automatico degli indirizzi IP in caso di avvio di un piano di DR è disponibile solo per le VM Windows.

Immagine 6

Immagine 7

Immagine 8

Immagine 9

Nella terza area sono identificate:

  • La profilazione degli utenti. In parole semplici il VDrO permette di creare utenti in grado di amministrare solo degli specifici workload che sono chiamati “scopes” (immagine 10).
  • L’assegnazione dei DataLab agli  “scopes”. Ricordo che i DataLab permettono di  verificare che il piano di DR sia utilizzabile (immagine 11).

Immagine 10

Immagine 11

L’ultima configurazione permette di legare il gruppo di VM replicate o salvate tramite backup (dette VM Groups) agli scopes degli utenti.

Ad esempio, l’immagine 12 riporta che il VM Group “B&R Job – Replication VAO Win 10” è assegnato (included) ad entrambi gli scopes Admin e Linux.

Immagine 10

Nel prossimo ed ultimo articolo scopriremo come creare e verificare un piano di DR.

A presto

VMware VCSA 7.03b Backup

Dopo aver aggiornato i vCenter all’ultima versione disponibile, (7.0.3.00100), mi sono accorto che i backup precedentemente configurati non venivano completati con successo.

L’errore che compariva era il seguente: “Path not exported by the remote filesystem” (vedi immagine 1).

Immagine 1

Una veloce indagine sul sito VMware ha spiegato la ragione:

Quando la destinazione del  backup è una share di tipo SMB, la VCSA non è in grado di scrivere sul target i file di backup.  (https://kb.vmware.com/s/article/86069)

Riconfigurato il  job in modo tale che scrivesse verso un target di tipo NFS, speravo di aver risolto questo inconveniente ma … un nuovo errore ha fatto la sua comparsa.

“Db health is UNHEALTHY, Backup Failed. Disable health check to take backup in the current state”  (vedi immagine 2):

Immagine 2

Nuova indagine e nuova risposta esauriente da VMware.

Dalla kb 86084 (https://kb.vmware.com/s/article/86084) l’errore può comparire dopo aver installato la patch 7.0.3

La procedura è molto semplice e consiste nel collegarsi come utente root e via SSH alla VCSA e lanciare il seguente comando:

/usr/bin/dbcc -fbss embedded (vedi immagine 3).

Immagine 3

Completata l’operazione è possibile salvare la configurazione della VCSA (vedi immagini 4 e 5).

Immagine 4

Immagine 5

A presto!

Kubernetes: I componenti

Nei precedenti articoli abbiamo visto alcuni dettagli di come è costruita l’architettura di Kubernetes.

Oggi verranno descritti i meccanismi di funzionamento del motore kubernetes indicando il nome di  ogni componente; per rimanere fedeli al paragone del motore dell’autovettura, parleremo degli alberi a camme, valvole, bronzine, … che afferiscono al Cloud Native

Nota1: Non verrà trattata l’installazione di k8s in Datacenter, Cloud e Laboratorio, la rete ha già messo a disposizione  esaustivi tutorial.

Per i familiarizzare con k8s vi consiglio di utilizzare Minikube (Piattaforma Linux)  Docker Desktop (piattaforma Windows & Mac).

Iniziamo!

Kubernetes Master:  E’ il nodo principale del cluster sul quale girano tre processi vitali per l’esistenza del cluster.

  • kube-apiserver
  • kube-controller-manager
  • kube-scheduler

Nel master node è inoltre presente il DataBase etcd, che memorizza tutte le configurazioni create nel cluster.

I nodi che si fanno carico di far girare le applicazioni e quindi i servizi sono detti worker node. I processi presenti sui worker node sono:

  • Kubelet
  • kube-proxy

kubelet :Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.

Kube-Proxy:  Ha la responsabilità di gestire il networking, dalle regole di Routing a quelle di di Load Balancing.

Nota 2: K8s cercherà di utilizzare tutte le librerie disponibili a livello di  sistema operativo.

kubectl: E’ Il client ufficiale di Kubernetes (CLI) attraverso il quale è possibile gestire il cluster (Kube-apiserver) utilizzando le API.

Alcuni semplici esempi di comandi kubectl sono:

  • kubectl version (indica la versione di k8s installata)
  • kubectl get nodes (scopre il numero di nodi del  cluster)
  • kubectl describe nodes nodes-1 (mostra lo stato di salute del nodo, la piattafoma sulla quale k8s sta girando (Google, AWS, ….) e le risorse assegnate (CPU,RAM)).

Container Runtime: E’ la base sulla quale poggia la tecnologia k8s.

kubernetes supporta diverse runtime tra le quali ricordiamo, container-d, cri-o, rktlet.

Nota 3: La runtime Docker è stata deprecata a favore di quelle che utilizzano le interfacce CRI; le immagini Docker continueranno comunque a funzionare nel  cluster.

Gli oggetti base di Kubernetes sono:

  • Pod
  • Servizi
  • Volumi
  • Namespace

I controller forniscono funzionalità aggiuntive e sono:

  • ReplicaSet
  • Deployment
  • StatefulSet
  • DaemonSet
  • Job

Tra i Deployment è indispensabile menzionare  Kube-DNS che fornisce i servizi di risoluzione dei nomi. Dalla versione kubernetes 1.2 la denominazione è cambiata in Core-dns.

Add-On: servono a configurare ulteriori funzionalità del cluster e sono collocati all’interno del name space kube-system (come Kube-Proxy, Kube-DNS, kube-Dashboard)

Gli Add-on sono categorizzati in base al loro utilizzo:

  • Add-on di Netwok policy. (Ad esempio l’add-on NSX-T si preoccupa della comunicazione tra l’ambiente K8s e VMware)
  • Add-on Infrastrutturali (Ad esempio KubeVirt che consente la connessione con le architetture virtuali)
  • Add-on di Visualizzazione e Controllo (Ad esempio Dashboard un’interfaccia web per  K8s).

Per la messa in esercizio, gli Add-on utilizzano i controller DaemonSetDeployment.

L’immagine di figura 1 riepiloga quanto appena esposto.

Figura 1