This post is also available in: Inglese

Quando racconto e spiego i vantaggi della virtualizzazione, solitamente alla fine cito i virtual appliance (VA) come un buon esempio di vantaggio che si può ottenere dalla virtualizzazione. Esattamente come un normale appliance fisico, possono essere considerati delle “scatole nere”, pronte all’uso e veloci da mettere in linea… tutti aspetti positivi (molti altri sono descritti, in inglese, su What are the Benefits of Deploying Virtual Appliances?).

Curiosità: la traduzione letterale di appliance è elettrodomentico (o comunque un’apparecchiatura in senso generico) e in effetti rende l’idea… semplice da usare (al limite con un manuale), pronto da usare, facile da manutenere (o almeno finché funziona non ci sono molti problemi… quando si guasta le cose sono un po’ più complicate), …

Ma tra tutti i vantaggi, bisogna segnalare anche alcuni potenziali svantaggi… Poi si possono ignorare (o considerare secondari), ma è opportuno saperli.

VA patching

Se è vero che una VA è una “scatola nera” non andrebbe mai toccata ed aggiornata… Ma gli aspetti di sicurezza striderebbero con questo approccio. E quindi come gestire le patch di una VA… Se sono gestibili da VUM, tanto bene.

Ma negli altri casi? Se il vendor o il produttore della VA fornisce delle sue patch e un suo meccanismo di aggiornamento, allora il problema è risolto.

Altrimenti? Si può pensare di patchare direttamente il contenuto della VA? In fondo in molti casi sono semplici distribuzioni Linux…

A tale proposito c’è un interessante post (Should You Patch the vCenter Server Virtual Appliance?) che, benché specifico sulla VCSA, è facilmente estendibile anche ad altre VA… Le considerazioni sono simili… meglio trattare la VA come un “apparato” ed usare i suoi tool di aggiornamento (del resto sarebbe come cercare di aggiornare direttamente il kernel di Linux o altri binari di un sistema Android, benché possibile, non avrebbe molto senso).

VA standard?

Come scritto una VA non è altro che una VM con un qualche sistema operativo guest… spesso Linux. Il risultato è la stessa “diaspora” di distribuzioni e persino VMware non ha deciso cosa usare come standard per i suoi VA (a volte CentOS, a volte SuSE, e non sempre con la stessa versione).

La mancanza di un “template” standard per le VA è sicuramente segno di flessibilità, ma può diventare contro-producente visto che poi si hanno tante VA progettate in malo modo (vedere gli aspetti di sicurezza citati dopo).

Su alcune mancano persino le VMware tools (o gli altri tool per gli altri hypervisor, visto che ci sono VA per diverse piattaforme).

Purtroppo non è neppure facile trovare una soluzione a questo problema… Chi potrebbe creare uno standard per le VA? VMware? (ma esistono VA anche per altre piattaforme e comunque non sembra che VMware sia interessata ad imporsi su questo aspetto).

Peccato che alcune soluzioni come quella di SuSE (SuSE Studio, che gestisce tra l’altro appliance sia per il virtual che per il fisico) non si siano diffuse ed imposte… Poteva essere un primo passo per la standardizzazione e la semplificazione.

VA resource consumption

Una VA è comunque una VM… se ben progettata occuperà poche risorse (o “quelle giuste”), ma se mal progettata può diventare un magia-risorse. Chiaramente si possono usare resource pools (in VMware vSphere) per gestire CPU e memoria, e SIOC e NIOC per il disco e la rete… Ma le risorse richieste vanno comunque considerate (possibilmente già in fase di progetto). Tra l’altro, l’assenza di uno standard non rende possibile (o quantomeno efficiente) ottimizzare le risorse (ad esempio usando il TPS per “condividere” pagine di memoria).

E bisogna ricordare che le VA consumano la vRAM entitlement!

Pensando a diverse VA diventa quindi non assurdo (o sovradimensionato) pensare ad un cluster di management per il vCenter Server e le altre VM di gestione. Purtroppo non tutte le VA possono risiedere nel cluster di management, alcune devono risiede sui singoli host (ad esempio alcune componenti di vShield o i probe di AppSpeed).

VA sprawl

Usare le VA è talmente facile, che in poco tempo è altrettanto facile trovarsi un numero elevato di VA, un po’ come può avvenire con le normali VM (effetto chiamato VM sprawl). Però con le VA c’è un problema in più…

L’assenza di standard significa anche tante distribuzioni Linux (o anche altri sistemi operativi), con differenti version, differenti patch level, differenti piattoforme (alcune VA sono a 32 bit, altre a 64 bit). Queste diversità rendono sistemi di ottimizzazione (come ad esempio TSP di VMware ESXi) inefficienti.

VA security

L’aspetto legato al patching della VA evidenzia uno dei potenziali problemi di sicurezza: se non gestito (correttamente) le VA possono diventare una minaccia alla sicurezza.

Ma non è l’unico aspetto legato alla sicurezza: anche il numero e tipo di servizi attivati di defeault in una VA possono risultare pericolosi. Nel migliore dei casi saranno solo risorse sprecate, ma nel caso peggiore potrebbero essere dei veri e propri rischi per la sicurezza. E il problema diviene lo stesso trattato con le patch: è giusto “aprire” la “scatola nera” per portare delle modifiche?

C’è anche un ulteriore aspetto: alcune VA usano distribuzioni veramente obsolete (ad esempio CentOS 5.1 o 5.2) e questo non fa altro che aggravare la situazione.

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.