Aggiornare un cloud CloudStack mentre le istanze dei tenant continuano a girare

Quando arriva un avviso di sicurezza per la piattaforma che fa girare i server di altre persone, ci sono due cattivi istinti. Uno è aspettare, perché toccare il cloud sembra più rischioso della vulnerabilità. L'altro è aggiornare tutto in una volta e sperare. Apache CloudStack premia un terzo approccio: capire i suoi livelli, aggiornarli nell'ordine giusto, e lasciare che siano le evidenze a decidere quali passi toccano davvero i tenant.

Un cloud è più cose da aggiornare, non una

Un deployment CloudStack è una pila di componenti con raggi d'impatto diversi:

• I management server e il loro database. Il control plane: portale, API, orchestrazione. Mentre è fermo, gli utenti non possono creare o modificare risorse, ma le istanze in esecuzione non dipendono da esso.
• Gli agent su ogni host KVM. Collegano gli hypervisor al management server. Riavviare un agent non ferma le istanze già in esecuzione su quell'host.
• Le system VM. La secondary storage VM gestisce template e snapshot, il console proxy serve le console nel browser. Riavviarle interrompe brevemente quelle funzioni, non i carichi dei tenant.
• I virtual router. Stanno nel percorso dati delle reti dei tenant, fornendo DHCP, DNS, NAT, firewall e bilanciamento. Riavviarne uno interrompe per un attimo i servizi di quella rete.

L'ordine del lavoro discende da questo elenco: prima le parti che i tenant non sentono mai, per ultime quelle che potrebbero sentire, e le ultime solo quando c'è un motivo reale.

Passo uno: leggete l'avviso rispetto alla vostra configurazione

La maggior parte degli avvisi riguarda una funzionalità specifica, spesso opzionale. Prima di pianificare una finestra, scoprite se la funzionalità interessata è abilitata nel vostro cloud. Le impostazioni globali sono visibili tramite API, per esempio con CloudMonkey:

cmk list configurations name=<setting from the advisory>
cmk list zones
cmk list hosts type=Routing

Questo vi dice quanto l'aggiornamento è urgente per voi, e vi dà una registrazione dello stato prima della modifica.

Passo due: fate il backup di ciò che vi servirebbe per tornare indietro

Prima di qualunque cambio di pacchetti, fate un dump coerente dei database di CloudStack e copiate fuori dalla macchina i file di configurazione del management server:

mysqldump --single-transaction --routines --triggers cloud > cloud-before-update.sql
mysqldump --single-transaction cloud_usage > cloud_usage-before-update.sql
tar czf cloudstack-etc-before-update.tgz /etc/cloudstack

Conservate i dump fuori dal management server.

Passo tre: i management server

Dopo aver aggiornato i pacchetti di management, controllate due cose. Anzi, controllate due cose dopo qualunque aggiornamento. Primo, che il servizio sia abilitato all'avvio al boot, come intendete che sia. Secondo, che abbia davvero finito di avviarsi, non solo che il processo esista:

systemctl is-enabled cloudstack-management
systemctl status cloudstack-management
journalctl -u cloudstack-management -f
cmk list capabilities

Aspettate che il log mostri l'avvio completato e che l'API risponda prima di andare oltre. Se avete più management server dietro un load balancer, aggiornateli uno alla volta così l'API resta disponibile per tutto il tempo.

Passo quattro: gli agent, un host alla volta, con un freno

Aggiornate il pacchetto dell'agent su un host KVM, riavviate l'agent, e aspettate che il management server veda di nuovo quell'host come Up prima di passare al successivo. Scriptatelo se avete molti host, ma date allo script un freno:

for h in $(cat kvm-hosts.txt); do
  ssh "$h" 'dnf -y update cloudstack-agent && systemctl restart cloudstack-agent' || exit 1
  until cmk list hosts name="$h" filter=state | grep -q Up; do sleep 10; done
done

Se un host non riesce ad aggiornarsi o a riconnettersi, il ciclo si ferma lì, con un host da indagare invece dell'intero cloud. Le istanze continuano a girare sui loro host per tutto il tempo, perché l'agent non è nel loro percorso.

Passo cinque: le system VM, poi i router secondo le evidenze

Le system VM portano script e pacchetti dal management server. Dopo l'aggiornamento, riavviatele o aggiornatele tramite API perché prendano il nuovo codice, poi confermate che tornano Running e connesse:

cmk list systemvms

I virtual router meritano più riflessione, perché stanno nel traffico dei tenant. La piattaforma può marcare i router come bisognosi di upgrade, ma quel flag può essere impostato anche quando il codice al loro interno non è cambiato in modo significativo. Confrontate gli script che il router riceverebbe dopo l'aggiornamento con quelli che già esegue. Se il codice del router è invariato, lasciatelo stare e risparmiate ai vostri tenant l'interruzione. Se è cambiato, pianificate i riavvii dei router per rete, avvisate i tenant interessati, e fateli uno alla volta.

cmk list routers requiresupgrade=true

Passo sei: dimostrate lo stato finale

Eseguite gli stessi controlli del passo uno e confrontate: ogni host Up, ogni system VM Running, ogni router nello stato atteso, l'impostazione dell'avviso dove la volete, e un'istanza di test creata, avviata e distrutta tramite API. Poi annotate il tempo dalla prima modifica al verde, che vi dice quanto deve durare la prossima finestra.

Come lo facciamo noi

Costruiamo cloud Apache CloudStack per cliente, secondo le specifiche del cliente, su host KVM su hardware HPE e Dell con storage SAN enterprise sotto e il supporto commerciale di ShapeBlue dietro la piattaforma. Gli avvisi di sicurezza seguono la procedura qui sopra. Quando è stato pubblicato un avviso per CloudStack, abbiamo applicato la correzione a un cloud di produzione la stessa settimana in questo modo, e ogni istanza cliente in esecuzione è rimasta su per tutto il tempo.

Il merito a chi spetta: la community di Apache CloudStack e ShapeBlue fanno il lavoro duro di trovare, correggere e documentare questi problemi. Se il vostro cloud ha un aggiornamento in attesa perché la procedura sembra rischiosa, siamo lieti di percorrerla insieme a voi.

cta: Parla con un ingegnere

Related

• /what-we-do/storage-compute/dedicated-cloudstack/
• /what-we-do/storage-compute/private-cloud-olvm/
• /what-we-do/storage-compute/container-platform-openshift/