Quando un’azienda non vende server, ma il risultato finale — ovvero i sistemi operativi dei clienti —, la sua infrastruttura deve avere costi prevedibili ed essere gestibile senza inutili interventi manuali. Questo caso di studio illustra come un fornitore di servizi IT gestiti della Repubblica Ceca abbia trasferito i sistemi dei propri clienti da un hyperscaler a un unico server dedicato in leasing con un cloud privato basato su Apache CloudStack. L’azienda ha ottenuto una fatturazione fissa, l’isolamento dei clienti e il monitoraggio integrato dell’utilizzo, riducendo al contempo i costi dell’infrastruttura di oltre quattro o cinque volte.
Contesto
Il cliente è un fornitore di servizi IT gestiti della Repubblica Ceca. L’azienda serve diverse decine di clienti B2B nella regione e gestisce il loro intero ambiente IT: assistenza per workstation e server, backup, monitoraggio, posta elettronica, sistemi contabili, VPN e applicazioni interne. Le risorse informatiche sono uno strumento piuttosto che un prodotto: i sistemi dei clienti girano su macchine virtuali e l’MSP ne è responsabile nell’ambito di contratti di assistenza.
I sistemi lato server dei clienti erano ospitati nel cloud pubblico AWS nella regione di Francoforte. L’MSP forniva l’infrastruttura separatamente per ciascun cliente e ne includeva il costo nel canone mensile di assistenza con un ricarico medio di circa il 5%, secondo quanto riferito dal cliente.
Obiettivi e risultati
Gli obiettivi del progetto pilota erano:

Il problema
Per l’MSP, l’infrastruttura cloud pubblica rappresentava un costo a carico del cliente. La fattura comprendeva decine di voci e variava di mese in mese: costi orari per CPU e memoria, tariffe separate per il traffico in uscita, lo storage e gli snapshot. Era impossibile comunicare al cliente l’importo esatto prima della fine del mese. Le variazioni di prezzo venivano assorbite dall’MSP, mentre i ricavi relativi alla parte dei contratti riguardante l’infrastruttura erano limitati a un margine di profitto di circa il 5%.
Il secondo problema riguardava la gestione. Alcuni clienti desideravano creare, arrestare e ripristinare le proprie macchine virtuali senza contattare il personale dell’MSP. Concedere ai clienti l’accesso all’infrastruttura cloud condivisa dell’MSP era inaccettabile, mentre la creazione di account separati per ciascun cliente richiedeva configurazioni di autorizzazione individuali, fatturazione separata e contabilità distinta per ogni cliente.
L’MSP si è rivolto a INTROSERV con la richiesta di avviare un progetto pilota: noleggiare un server dedicato in un data center europeo e implementarvi un cloud privato pronto all’uso in sostituzione dell’hyperscaler per i sistemi tipici dei clienti, con la possibilità di espandersi in seguito a più nodi.
Configurazione dell’infrastruttura
INTROSERV ha fornito un server dedicato ospitato in un data center di livello Tier III nei Paesi Bassi con una disponibilità di rete garantita del 99,99%.
Server principale:
-
CPU: 2x Intel Xeon Gold 6130 — 32 core fisici, 64 thread, frequenza di base di 2,10 GHz, fino a 3,70 GHz in modalità turbo
-
RAM: 256 GB REG ECC DDR4, espandibile fino a 1 TB
-
NVMe: 2x 3,84 TB in RAID 1 software — 3,84 TB di spazio di archiviazione locale per i dischi delle macchine virtuali
-
SATA: 4x 14 TB in RAID 10 software — 28 TB per backup e archiviazione secondaria
-
Rete: due porte da 25 Gbps, traffico illimitato; rete VLAN privata da 10 Gbps
-
Gestione: iDRAC
-
Protezione DDoS: 20 Gbps
-
Alimentazione ridondante
Un server di backup per le macchine virtuali è collegato al server principale tramite una rete VLAN privata da 10 Gbps.
Il servizio di backup di INTROSERV, basato su NAKIVO Backup & Replication, costa 49 € al mese per 5 TB. Viene eseguito il backup dell’intero server: il sistema operativo host, la configurazione di CloudStack e il database del server di gestione. In caso di guasto del server, il sistema viene distribuito su un nuovo hardware a partire da questo backup, dopodiché le macchine virtuali vengono ripristinate dal server di backup.
La configurazione soddisfa i requisiti per la tolleranza ai guasti a livello di singola macchina:
- Rete: due porte indipendenti da 25 Gbps sono unite in un collegamento tollerante ai guasti. Il guasto di una porta o di un collegamento non interrompe il funzionamento delle macchine virtuali.
- Alimentazione: due gruppi di alimentazione. Il guasto di uno di essi non provoca lo spegnimento del server.
- Dischi: tutte le unità sono configurate in array RAID. Il guasto di un’unità NVMe o SATA non comporta la perdita di dati né tempi di inattività del server.
- Archiviazione: i dischi delle macchine virtuali sono archiviati su un array NVMe locale senza archiviazione di rete tra l’hypervisor e i dati. Ciò garantisce una latenza di I/O minima per i database e i sistemi contabili dei clienti.
- Backup: i backup delle macchine virtuali vengono trasferiti su un server fisico separato tramite una rete privata da 10 Gbps, senza utilizzare porte esterne né incorrere in costi di traffico. Un backup completo del server viene archiviato nello spazio di archiviazione del servizio di backup da 5 TB.
La fattura del server copre tutto ciò che verrebbe addebitato separatamente da un hyperscaler: traffico, rete e alimentazione ridondanti, tolleranza ai guasti dei dischi, archiviazione locale ad alta velocità, una rete privata verso il server di backup e la gestione remota tramite iDRAC. Le due voci relative al backup sono a costo fisso.
La soluzione
Il team di INTROSERV ha implementato Apache CloudStack sul server in una configurazione a nodo singolo: il server di gestione e l’host KVM girano sulla stessa macchina. Il lavoro è stato eseguito nell’ambito di un servizio di amministrazione di sistema a tariffa oraria, al termine del quale la gestione della piattaforma è stata trasferita al cliente.
Perché Apache CloudStack anziché Proxmox VE
Entrambe le piattaforme sono open source e funzionano su KVM. Proxmox VE è distribuito sotto licenza AGPLv3 ed è utilizzabile gratuitamente; un abbonamento a pagamento per socket CPU è richiesto solo per l’accesso al repository degli aggiornamenti aziendali e al supporto tecnico del fornitore. Apache CloudStack è distribuito sotto licenza Apache 2.0 senza costi per socket, core o macchine virtuali. La licenza non è stata il fattore determinante. I fattori chiave sono state quattro funzionalità integrate in CloudStack che in Proxmox VE richiedono strumenti esterni:
- Multi-tenancy. Domini, account e progetti con limiti di risorse e quote per ciascun cliente. I clienti che desideravano gestire la propria flotta di macchine virtuali hanno ricevuto un account dedicato con un ruolo specifico: possono visualizzare solo le proprie risorse, creare e arrestare macchine virtuali, nonché eseguire snapshot e rollback entro la quota loro assegnata. L’applicazione delle quote è gestita dalla piattaforma anziché tramite un processo manuale.
- Monitoraggio dell’utilizzo. Il server di monitoraggio integrato registra il consumo di CPU, memoria, disco e traffico per ciascun account; il plugin Quota gestisce i saldi in base ai piani tariffari. I dati per il calcolo dei costi interni e la fatturazione ai clienti vengono prelevati direttamente dalla piattaforma anziché raccolti manualmente.
- Kubernetes. Il servizio CloudStack Kubernetes distribuisce e aggiorna i cluster Kubernetes per i clienti dalla console o tramite API, con scalabilità dei nodi e la possibilità di collegare i dischi CloudStack come volumi del cluster. I clienti che eseguono applicazioni containerizzate ricevono un cluster senza la necessità di una piattaforma separata.
- Servizi di rete. Reti isolate con un router virtuale per ciascun cliente: firewall, NAT, bilanciamento del carico e VPN.
L’aggiunta di un nuovo cliente è diventata un’operazione standardizzata: creare un dominio e un account, una rete isolata con un router virtuale, una quota e macchine virtuali da un modello predefinito. Tutto può essere eseguito dalla console o tramite API e il provider Terraform in pochi minuti, anziché ore di configurazione manuale nella console di un hyperscaler. Gli snapshot forniscono punti di rollback prima degli aggiornamenti del sistema del cliente, mentre i modelli forniscono immagini di base identiche per tutti i clienti.

Livello di tolleranza ai guasti
La disponibilità del sistema è importante per i clienti dell’MSP, ma il carico di lavoro — sistemi contabili, posta elettronica e applicazioni interne — non richiede un’elevata disponibilità con riavvio automatico delle VM su un altro host entro pochi minuti. Il primo gruppo di clienti non dispone di sistemi a funzionamento continuo in cui diverse ore di inattività comporterebbero perdite dirette; per loro è accettabile una finestra di manutenzione programmata o il ripristino da backup.
Pertanto, un cluster ad alta disponibilità è stato ritenuto eccessivo per il progetto pilota: richiede infatti più nodi e uno storage condiviso. È stato scelto un singolo nodo con ridondanza a livello di macchina, e questa configurazione si è rivelata sufficiente. I guasti dei componenti sono coperti a livello hardware: due porte da 25 Gbps collegate in bond, due alimentatori e tutti i dischi in array RAID. Il degrado dell’array e le risorse insufficienti dell’host vengono monitorati in modo proattivo, e le unità vengono sostituite prima che un problema possa influire sulle macchine virtuali.
Un guasto completo del server è coperto da due livelli di backup: il backup dell’host in NAKIVO ripristina il sistema operativo e CloudStack su un nuovo server senza richiedere alcuna riconfigurazione, mentre i backup delle macchine virtuali riportano in funzione i sistemi dei clienti. L’alta disponibilità è prevista per la fase di espansione, quando l’infrastruttura crescerà fino a comprendere più nodi: verranno aggiunti ulteriori host allo stesso CloudStack senza modificare la piattaforma.
Lavori completati
1. Preparazione del server: installazione del sistema operativo, array RAID software (RAID 1 su NVMe, RAID 10 su SATA), aggregazione di due porte da 25 Gbps in un collegamento tollerante ai guasti e configurazione di una rete VLAN privata verso il server di backup.
2.Installazione del server di gestione CloudStack e dell’agente KVM su un singolo nodo, configurazione del database e delle macchine virtuali di sistema.
3. Creazione della zona, del pod e del cluster; storage primario sull’array NVMe e storage secondario sull’array SATA.
4. Modello di rete: reti isolate con un router virtuale per ciascun cliente, un intervallo di indirizzi IP pubblici, regole firewall e NAT.
5. Modelli di sistema operativo (Ubuntu, Debian, AlmaLinux, Windows Server) e offerte di servizi per tre dimensioni standard di macchine virtuali.
6. Backup delle macchine virtuali su un server di backup separato tramite una rete privata da 10 Gbps; collegamento del server al servizio di backup di INTROSERV basato su NAKIVO con una pianificazione per i backup completi del server.
7. Domini e account per i clienti MSP, ruoli e limiti di risorse, attivazione del plugin Usage Server e Quota; attivazione del servizio CloudStack Kubernetes e registrazione delle immagini ISO contenenti i binari di Kubernetes.
8. Monitoraggio proattivo: stato del sistema operativo host (CPU, memoria, spazio su disco, interfacce di rete, servizi di sistema) e array di dischi (stato RAID, metriche SMART delle unità), con invio di notifiche ai tecnici di INTROSERV.
9. Test: test delle VM di tutte e tre le dimensioni, snapshot e rollback, accesso alla rete esterna, test di backup delle VM e test di backup completo del server.
10. Consegna al cliente: console CloudStack, chiavi API, documentazione di configurazione e accesso a iDRAC.
Il carico di lavoro complessivo è stato di 16 ore. Dopo il passaggio di consegne, INTROSERV fornisce assistenza in base agli avvisi di monitoraggio o alle richieste del cliente: sostituzione delle unità, aggiornamenti dell’hypervisor e del server di gestione ed espansione della configurazione.
Posizionamento delle macchine virtuali
Durante la fase pilota, sono state migrate sul nodo 20 macchine virtuali a supporto dei sistemi dei clienti, in tre dimensioni standard. La memoria viene allocata senza overcommitment: 64 GB rimangono disponibili per il server di gestione, le macchine virtuali di sistema e i sistemi dei clienti successivi. Tutti i dischi delle macchine virtuali si trovano sull’array NVMe locale del server, garantendo a ciascuna macchina virtuale le prestazioni di disco che, in base al listino prezzi dello storage dell’hyperscaler per gli IOPS garantiti, avrebbero richiesto un addebito separato.
Le CPU virtuali vengono allocate con un overcommitment minimo — 72 vCPU per 64 thread — mentre l’utilizzo effettivo della CPU durante l’orario di lavoro non supera il 50%. Circa 700 GB rimangono liberi sull’array NVMe. Il progetto è pilota e questa riserva di capacità è stata prevista intenzionalmente: è possibile aggiungere ulteriori sistemi dei clienti allo stesso nodo senza modificare la configurazione, mentre l’espansione della memoria a 1 TB e l’aggiunta di unità aumentano la capacità del nodo di diverse volte.
L’infrastruttura come vantaggio strategico
La soluzione implementata dal team di INTROSERV ha sostituito l’hyperscaler come fornitore di risorse di calcolo per i sistemi dei clienti dell’MSP. Un singolo server in leasing con Apache CloudStack ha gestito il primo gruppo di 20 macchine virtuali con margini di crescita e un livello di tolleranza ai guasti adeguato al carico di lavoro.
Il cliente ha ottenuto funzionalità che non erano disponibili nel cloud pubblico: isolamento dei clienti e monitoraggio dell’utilizzo a livello di piattaforma, self-service per i clienti con account propri, cluster Kubernetes gestibili dalla stessa console e monitoraggio proattivo dell’host e degli array di dischi. La ridondanza di rete e di alimentazione, i dischi protetti da RAID, lo storage NVMe locale, le porte illimitate da 25 Gbps e la protezione DDoS sono inclusi nel costo del server.
Aspetti economici
La maggior parte del traffico passa attraverso i server VPN dei clienti: il traffico in uscita dal nodo è pari a 20–35 TB al mese. Un set equivalente di risorse fornito dal precedente provider — 20 macchine virtuali con lo stesso profilo, lo stesso spazio di archiviazione, gli stessi snapshot e lo stesso volume di traffico in uscita alle attuali tariffe della regione di Francoforte — costa circa 4.000–5.100 € al mese, ovvero circa 54.000 € all’anno. Di questo importo, tra i 1.500 e i 2.600 € sono attribuibili al traffico: presso l’hyperscaler, ogni gigabyte trasmesso tramite VPN ai dipendenti dei clienti viene addebitato separatamente.
INTROSERV costa 1.017 € al mese: 671 € per il server principale, 157 € per il server di backup, 49 € per il backup completo del server, mentre la somma restante copre l’amministrazione su richiesta e l’ammortamento della configurazione iniziale. Nel noleggio del server sono incluse due porte da 25 Gbps con traffico illimitato, quindi il traffico in uscita generato dai sistemi dei clienti non incide sulla fattura, sia che si tratti di 35 o 50 TB al mese.
Metrica |
Hyperscaler |
INTROSERV + CloudStack |
Al mese |
~4.500 € |
1.017 € |
All'anno |
circa 54.000 € |
12.200 € |
Voci della fattura |
dozzine |
3–4 |
Costo mensile per VM |
circa 225 € |
51 € |
La base di costo è da quattro a cinque volte inferiore, l'importo è fisso ed è noto prima dell'inizio del mese. Ciò ha consentito al cliente di includere l'infrastruttura in un canone di assistenza fisso, offrire ai propri clienti condizioni più vantaggiose e aumentare la redditività della parte relativa all'infrastruttura dei propri contratti. Man mano che il portafoglio clienti cresce, il divario rispetto agli hyperscaler aumenta: la fattura relativa ai server non dipende dal traffico né dalle variazioni dei prezzi delle istanze. Il cliente si è dichiarato pienamente soddisfatto del costo della soluzione.
Prossimi passi
La piattaforma aperta senza costi di licenza ha risolto il problema della scalabilità: l’espansione della memoria a 1 TB aumenta di parecchie volte la capacità del nodo, mentre è possibile aggiungere un secondo nodo al cluster CloudStack esistente senza cambiare strumenti. I dati dei clienti rimangono su server dedicati in un data center europeo all’interno di un perimetro controllato dal cliente. Per un’azienda che serve clienti nell’UE soggetta ai requisiti del GDPR, questa è una condizione obbligatoria. A seguito della fase pilota, l’MSP deciderà se migrare ulteriori gruppi di sistemi dei clienti su CloudStack.
La vostra infrastruttura presso un hyperscaler costa più del dovuto, mentre la fattura rimane impossibile da prevedere? Affidate la migrazione al team di INTROSERV: selezioneremo la giusta configurazione del server, implementeremo Apache CloudStack e vi consegneremo un cloud privato pronto all’uso .