L’iperconvergenza (HCI) è stata venduta per anni come la semplificazione definitiva: niente più SAN, niente più fabric Fibre Channel, niente più team storage separato. Tutto in un solo mattoncino software-defined che scala aggiungendo nodi. Il marketing è impeccabile. La produzione, come sempre, racconta una storia più sfumata. Dopo diversi anni a progettare, migrare e — soprattutto — a rimettere in piedi cluster iperconvergenti dopo guasti reali, la mia posizione è netta: l’HCI non è una rivoluzione, è un trade-off architetturale. E come ogni trade-off, va scelto conoscendo esattamente cosa si sta cedendo in cambio.
Dove regge e dove ti tradisce
Il modello HCI dà il meglio quando il rapporto tra compute e storage cresce in modo proporzionale. Il caso d’uso ideale che ho visto reggere senza problemi è la classica VDI o il farm di VM applicative con footprint di storage contenuto: molte macchine, ognuna con qualche decina di GB, workload prevedibile, crescita orizzontale lineare. Lì aggiungere un nodo significa aggiungere in un colpo solo CPU, RAM e capacità, e la matematica funziona.
Il problema nasce quando l’infrastruttura è sbilanciata. La domanda più scomoda in fase di design è sempre la stessa: cosa succede quando devo scalare solo lo storage, o solo il compute? In HCI, la risposta onesta è: non puoi farlo in modo pulito. Se ti serve solo capacità, sei costretto ad aggiungere un nodo pieno di CPU e RAM che non ti servono — e che paghi comunque, incluse le licenze. Se ti serve solo compute, aggiungi dischi che restano vuoti a occupare dominio di failure. Questa rigidità è il vero peccato originale del modello, e non lo si vede finché non ci si sbatte contro in produzione.
Il rebuild dopo la perdita di un nodo
Qui si separa la teoria dal campo. Nel modello tre-tier con SAN dedicata, la perdita di un host è un evento gestito: le VM ripartono altrove via HA, lo storage non si accorge di nulla perché vive su un layer separato. In HCI la perdita di un nodo è un evento doppio: perdi compute e perdi una copia dei dati. Parte il resync/rebuild per ricostituire la ridondanza, e quel processo consuma la stessa rete e gli stessi dischi che stanno servendo la produzione.
Il degrado prestazionale durante il rebalancing non è un dettaglio da datasheet: su cluster carichi ho visto latenze salire in modo sensibile per ore, con applicazioni sensibili all’I/O che iniziano a soffrire proprio nel momento in cui il cluster è già in stato degradato. È il classico scenario in cui il guasto singolo, gestibile, diventa una finestra di rischio ampliata perché il blast radius tocca insieme calcolo, dati e rete.
Il trade-off più doloroso: licensing e blast radius
Sul piano FinOps, il nodo dolente è il licensing core-based. Quando sei costretto ad aggiungere nodi per soli motivi di capacità, stai pagando core di CPU e — a cascata — licenze hypervisor e talvolta licenze del layer SDS, che non ti servono a nulla se non a ospitare dischi. In uno split classico compute+SAN puoi far crescere la SAN in modo indipendente, senza toccare il conteggio dei core lato compute. Su volumi importanti questa differenza si traduce in cifre a sei zeri sul TCO triennale.
- Licensing: HCI accoppia crescita capacità e crescita core. Lo split li disaccoppia.
- Degrado durante resync: in HCI il rebuild grava sulla produzione; con SAN dedicata il layer dati è isolato.
- Blast radius: in HCI un nodo che cade è compute+dati+rete insieme; nel tre-tier i domini di guasto restano separati.
La soglia pratica che do ai clienti
Quando un cliente mi chiede “passo a HCI o resto su tre-tier con storage dedicato?”, non parto mai dal vendor. Parto dal profilo del carico e dal team. La regola che uso è semplice e va contro parte del marketing:
- Rapporto storage/compute: è il discriminante numero uno. Per clienti che hanno molto storage e poche VM, l’HCI lo sconsiglio apertamente. Pagherebbero nodi e licenze solo per sostenere capacità che uno storage dedicato darebbe a frazione del costo e senza vincoli di scaling.
- Numero nodi: sotto una manciata di nodi il modello è fragile — il rebuild pesa troppo sul cluster residuo. Ha senso solo con un numero di nodi sufficiente ad assorbire un guasto senza mettere in ginocchio la produzione.
- Criticità e IOPS: workload latency-sensitive con requisiti di I/O stringenti soffrono le finestre di resync. Se il downtime prestazionale non è tollerabile, lo split classico è più prevedibile.
- Competenze interne: l’HCI semplifica l’operatività quotidiana ma richiede un team che capisca cosa succede sotto durante un guasto. Se manca quella maturità, la “semplicità” diventa una scatola nera pericolosa.
In sintesi: HCI conviene a chi cresce in modo orizzontale e bilanciato, con molte VM leggere e team preparato. Va evitato a chi ha profili storage-intensive, workload critici latency-sensitive o infrastrutture piccole dove il rebuild non ha margini per lavorare.
Il verdetto
Il verdetto è 0: non muoversi per default. Non perché l’HCI sia una tecnologia immatura — non lo è — ma perché troppe migrazioni vengono decise sulla promessa di semplicità e finiscono a scontrarsi con la rigidità dello scaling accoppiato e con il licensing core-based. Se la tua infrastruttura non ha il profilo giusto, l’iperconvergenza si rivela per quello che è dietro lo slogan: un lock-in architetturale travestito da rivoluzione. Prima di firmare, fatti i conti sul rapporto storage/compute e simula onestamente un rebuild sotto carico. Se i numeri non tornano, resta sul tre-tier: è meno affascinante nelle slide, ma in produzione perdona molto di più.