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

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!

Persistent Data & Resource Management

Persistent Data

Nei precedenti articoli, abbiamo visto che se un POD viene dismesso o il container viene riavviato, tutti i dati presenti sul file system del POD vengono cancellati.

E’ un approccio vincente per tutte quelle applicazioni stateless (ad esempio un front-end web) ma non lo è per le applicazioni stateful dove ad esempio non registrare anche un record di un DataBase significa perdere informazioni vitali per il servizio erogato.

Kubernetes supera brillantemente l’ ostacolo attraverso l’utilizzo della tecnologia Persistent Data.

E’ il file yaml che definisce nel POD i Persisten Data attraverso le voci:

  • Volumes che descrive i volumi disponibili per il POD.
  • VolumeMounts che descrive il percorso per l’utilizzo del volume (ad esempio /mydata/)

I Volumi sono categorizzati in tre principali categorie create in base al loro utilizzo:

   1- Comunicazione/sincronizzazione

E’ il volume condiviso per realizzare la sincronizzazzione con le immagini di una Git remota.

La vita del volume è limitata all’esistenza del POD ed il volume può essere condiviso tra più container.

   2- Dati Persistenti

Per garantire l’alta affidabilità e le migliori performance, i POD devono potersi spostarsi liberamente tra i nodi del cluster kubernetes.

Di conseguenza i volumi che contengono informazioni persistenti e vitali dell’applicazione devono essere sempre raggiungibili dal POD.

Kubernetes per garantire la visibilità supporta molte tipologie di volumi ad esempio NFS, iSCSI, Elastic Block Store di Amazon, File e Disk Storage Azure, nonché Google Persistent Disk.

Nota1: In caso di spostamento del POD, Kubernetes in automatico è in grado di smontare il volume dal vecchio host e renderlo disponibile sul nuovo.

   3- Filesystem host

Alcune applicazioni non hanno bisogno solo di un volume persistente, ma anche di un filesystem disponibile a livello di host. La necessità è indirizzata attraverso il volume hostPath  (Ad esempio /var/mygp/).

Resource Management

Il costo di funzionamento di una macchina in un datacenter, è indipendente dalla quantità di CPU & RAM che utilizza la singola VM in esercizio.
Garantire invece che all’interno dell’infrastruttura, le risorse CPU & RAM siano distribuite al meglio, impatta l’efficenza dell’ambiente.

Esempio:

Immaginiamo due servizi. Il primo utilizza il 20% della memoria di una VM configurata con 5GB di RAM, il secondo utilizza il 50% di una seconda VM configurata con 4GB RAM.

L’utilizzo totale di memoria RAM è di 1+2=3GB delle 9GB totale assegnate.

La metrica di utilizzo (MU) è definita come il valore percentuale tra il rapporto della quantità di risorse attivamente utilizzate e la quantità di risorse acquistate.

Nel nostro esempio MU=3/9= 33%

Al fine di controllare l’uso delle risorse, Kubernetes consente agli utenti di specificare due diverse metriche a livello di POD.

  • Resource Request specifica la quantità minima assegnabile alla risorsa.
  • Resource limits specifica la quantità massima assegnabile all’applicazione.

L’esempio di figura 1 mostra l’iun esempio di limite di risorse

Figura 1