Comment une micro-SSP tchèque a remplacé la revente d'AWS par Apache CloudStack pour faire passer ses marges d'hébergement de 5 % à 60 %

2

Lire 20 min.

Lorsqu’une entreprise ne vend pas des serveurs, mais le résultat — les systèmes opérationnels de ses clients —, son infrastructure doit présenter des coûts prévisibles et pouvoir être gérée sans intervention manuelle superflue. Cette étude de cas montre comment un prestataire de services informatiques gérés basé en République tchèque a migré les systèmes de ses clients depuis un hyperscaler vers un seul serveur dédié loué, doté d’un cloud privé Apache CloudStack. L’entreprise a ainsi bénéficié d’une facture fixe, d’une isolation des clients et d’un suivi intégré de l’utilisation, tout en réduisant ses coûts d’infrastructure de plus de quatre à cinq fois.

Contexte

Le client est un fournisseur de services informatiques gérés basé en République tchèque. L’entreprise sert plusieurs dizaines de clients B2B dans la région et gère l’intégralité de leur environnement informatique : support des postes de travail et des serveurs, sauvegardes, surveillance, messagerie électronique, systèmes comptables, VPN et applications internes. Les ressources informatiques constituent un outil plutôt qu’un produit : les systèmes des clients fonctionnent sur des machines virtuelles, et le MSP en assume la responsabilité dans le cadre de contrats de support.

Les systèmes côté serveur des clients étaient hébergés dans le cloud public AWS de la région de Francfort. Le MSP provisionnait l’infrastructure séparément pour chaque client et incluait son coût dans les frais de support mensuels avec une marge d’environ 5 % en moyenne, selon le client.

Objectifs et résultats

Les objectifs du projet pilote étaient les suivants :

Le problème

Pour le MSP, l’infrastructure du cloud public constituait un coût répercuté. La facture comportait des dizaines de lignes et variait d’un mois à l’autre : frais horaires pour le processeur et la mémoire, frais distincts pour le trafic sortant, le stockage et les instantanés. Il était impossible d’indiquer au client le montant exact avant la fin du mois. Les variations de prix étaient absorbées par le MSP, tandis que les marges sur la partie « infrastructure » des contrats étaient limitées à une majoration d’environ 5 %.

Le deuxième problème concernait la gestion. Certains clients souhaitaient créer, arrêter et restaurer leurs propres machines virtuelles sans passer par les employés du MSP. Donner aux clients l’accès à l’infrastructure cloud partagée du MSP était inacceptable, tandis que la mise en place de comptes distincts pour chaque client nécessitait des configurations d’autorisations individuelles, une facturation séparée et une comptabilité distincte pour chaque client.

Le MSP a contacté INTROSERV pour lui proposer un projet pilote : louer un serveur dédié dans un centre de données européen et y déployer un cloud privé prêt à l’emploi en remplacement de l’hyper-scaler pour les systèmes clients classiques, avec la possibilité d’étendre le système à plusieurs nœuds ultérieurement.

Configuration de l’infrastructure

INTROSERV a fourni un serveur dédié hébergé dans un centre de données de niveau III aux Pays-Bas, avec une disponibilité réseau garantie de 99,99 %.

Serveur principal :

• Processeur : 2x Intel Xeon Gold 6130 — 32 cœurs physiques, 64 threads, fréquence de base de 2,10 GHz, jusqu’à 3,70 GHz en mode turbo

• Mémoire vive : 256 Go REG ECC DDR4, extensible jusqu’à 1 To

• NVMe : 2 x 3,84 To en RAID 1 logiciel — 3,84 To de stockage local pour les disques des machines virtuelles

• SATA : 4 x 14 To en RAID 10 logiciel — 28 To pour les sauvegardes et le stockage secondaire

• Réseau : deux ports à 25 Gbit/s, trafic illimité ; réseau VLAN privé à 10 Gbit/s

• Gestion : iDRAC

• Protection DDoS : 20 Gbit/s

• Alimentation redondante

Un serveur de sauvegarde pour les machines virtuelles est connecté au serveur principal via un réseau VLAN privé de 10 Gbit/s.

Le service de sauvegarde d’INTROSERV, basé sur NAKIVO Backup & Replication, coûte 49 € par mois pour 5 To. L'intégralité du serveur est sauvegardée : le système d'exploitation hôte, la configuration CloudStack et la base de données du serveur de gestion. En cas de panne du serveur, le système est déployé sur un nouveau matériel à partir de cette sauvegarde, après quoi les machines virtuelles sont restaurées à partir du serveur de sauvegarde.

La configuration répond aux exigences de tolérance aux pannes au niveau d’une seule machine :

• Réseau : deux ports indépendants de 25 Gbps sont regroupés en une liaison tolérante aux pannes. La défaillance d’un port ou d’une liaison n’interrompt pas le fonctionnement des machines virtuelles.
• Alimentation : deux blocs d'alimentation. La défaillance de l'un d'entre eux n'entraîne pas l'arrêt du serveur.
• Disques : tous les disques sont configurés en matrices RAID. La défaillance d’un disque NVMe ou SATA n’entraîne ni perte de données ni interruption de service du serveur.
• Stockage : les disques des machines virtuelles sont stockés sur une matrice NVMe locale, sans stockage réseau intercalé entre l’hyperviseur et les données. Cela garantit une latence d’E/S minimale pour les bases de données et les systèmes comptables des clients.
• Sauvegardes : les sauvegardes des machines virtuelles sont transférées vers un serveur physique distinct via un réseau privé de 10 Gbit/s, sans utiliser de ports externes ni générer de frais de trafic. Une sauvegarde complète du serveur est stockée dans l’espace de stockage de 5 To dédié au service de sauvegarde.

La facture du serveur couvre tout ce qui serait facturé séparément par un hyperscaler : le trafic, la redondance du réseau et de l’alimentation, la tolérance aux pannes de disque, le stockage local haut débit, un réseau privé vers le serveur de sauvegarde et la gestion à distance via iDRAC. Les deux éléments liés à la sauvegarde sont des coûts fixes.

La solution

L’équipe d’INTROSERV a déployé Apache CloudStack sur le serveur dans une configuration à nœud unique : le serveur de gestion et l’hôte KVM tournent sur la même machine. Le travail a été réalisé dans le cadre d’un service d’administration système facturé à l’heure, à l’issue duquel la gestion de la plateforme a été transférée au client.

Pourquoi Apache CloudStack plutôt que Proxmox VE

Les deux plateformes sont open source et fonctionnent sous KVM. Proxmox VE est distribué sous licence AGPLv3 et fonctionne gratuitement ; un abonnement payant par socket CPU n’est requis que pour accéder au référentiel de mises à jour d’entreprise et au support technique du fournisseur. Apache CloudStack est distribué sous licence Apache 2.0, sans frais liés aux sockets, aux cœurs ou aux machines virtuelles. La question de la licence n’a pas été déterminante. Les facteurs clés ont été quatre fonctionnalités intégrées à CloudStack qui nécessitent des outils externes dans Proxmox VE :

• La multi-location. Domaines, comptes et projets avec des limites de ressources et des quotas pour chaque client. Les clients souhaitant gérer leur propre parc de machines virtuelles se sont vu attribuer un compte dédié avec un rôle spécifique : ils ne peuvent voir que leurs propres ressources, créer et arrêter des machines virtuelles, ainsi que réaliser des instantanés et des restaurations dans les limites de leur quota alloué. L’application des quotas est gérée par la plateforme plutôt que par un processus manuel.
• Suivi de l’utilisation. Le serveur de suivi intégré (Usage Server) enregistre la consommation de CPU, de mémoire, de disque et de trafic pour chaque compte ; le plugin Quota gère les soldes en fonction des plans tarifaires. Les données nécessaires aux calculs de coûts internes et à la facturation des clients sont extraites directement de la plateforme plutôt que collectées manuellement.
• Kubernetes. Le service CloudStack Kubernetes déploie et met à jour les clusters Kubernetes pour les clients depuis la console ou via l’API, avec une évolutivité des nœuds et la possibilité de connecter des disques CloudStack en tant que volumes de cluster. Les clients exécutant des applications conteneurisées bénéficient d’un cluster sans avoir besoin d’une plateforme distincte.
• Services réseau. Réseaux isolés avec un routeur virtuel pour chaque client : pare-feu, NAT, équilibrage de charge et VPN.

L’ajout d’un nouveau client est devenu une opération standardisée : création d’un domaine et d’un compte, d’un réseau isolé avec un routeur virtuel, d’un quota et de machines virtuelles à partir d’un modèle prêt à l’emploi. Tout peut être effectué depuis la console ou via l’API et le fournisseur Terraform en quelques minutes, au lieu des heures de configuration manuelle requises dans la console d’un hyperscaler. Les instantanés fournissent des points de restauration avant les mises à jour du système client, tandis que les modèles fournissent des images de base identiques pour tous les clients.

Niveau de tolérance aux pannes

La disponibilité du système est importante pour les clients du MSP, mais la charge de travail — systèmes comptables, messagerie électronique et applications internes — ne nécessite pas une haute disponibilité avec redémarrage automatique de la machine virtuelle sur un autre hôte en quelques minutes. Le premier groupe de clients ne dispose pas de systèmes fonctionnant en continu, pour lesquels plusieurs heures d’indisponibilité entraîneraient des pertes directes ; une fenêtre de maintenance planifiée ou une restauration à partir d’une sauvegarde leur convient.

Par conséquent, un cluster à haute disponibilité a été jugé excessif pour le projet pilote : il nécessite en effet plusieurs nœuds et un stockage partagé. Un nœud unique avec redondance au niveau de la machine a été sélectionné, et cette configuration s’est avérée suffisante. Les pannes de composants sont couvertes au niveau matériel : deux ports agrégés à 25 Gbps, deux blocs d’alimentation et tous les disques organisés en matrices RAID. La dégradation des matrices et l’insuffisance des ressources de l’hôte sont surveillées de manière proactive, et les disques sont remplacés avant qu’un problème n’affecte les machines virtuelles.

Une panne complète du serveur est couverte par deux niveaux de sauvegardes : la sauvegarde de l’hôte dans NAKIVO permet de restaurer le système d’exploitation et CloudStack sur un nouveau serveur sans nécessiter de reconfiguration, tandis que les sauvegardes des machines virtuelles permettent de remettre les systèmes des clients en état de fonctionnement. La haute disponibilité est prévue pour la phase d’expansion, lorsque l’infrastructure comptera plusieurs nœuds : des hôtes supplémentaires seront ajoutés au même CloudStack sans modifier la plateforme.

Travaux réalisés

1. Préparation des serveurs : installation du système d’exploitation, matrices RAID logicielles (RAID 1 sur NVMe, RAID 10 sur SATA), agrégation de deux ports à 25 Gbit/s en une liaison tolérante aux pannes, et configuration d’un réseau VLAN privé vers le serveur de sauvegarde.

2.Installation du serveur de gestion CloudStack et de l’agent KVM sur un seul nœud, configuration de la base de données et des machines virtuelles système.

3. Création de la zone, du pod et du cluster ; stockage primaire sur la matrice NVMe et stockage secondaire sur la matrice SATA.

4. Modèle réseau : réseaux isolés avec un routeur virtuel pour chaque client, une plage d’adresses IP publiques, des règles de pare-feu et une traduction d’adresses réseau (NAT).

5. Modèles de systèmes d’exploitation (Ubuntu, Debian, AlmaLinux, Windows Server) et offres de services pour trois tailles de machines virtuelles standard.

6. Sauvegarde des machines virtuelles sur un serveur de sauvegarde distinct via un réseau privé de 10 Gbit/s; connexion du serveur au service de sauvegarde d’INTROSERV basé sur NAKIVO, avec un calendrier de sauvegardes complètes du serveur.

7. Domaines et comptes pour les clients MSP, rôles et limites de ressources, activation du plugin « Usage Server » et « Quota » ; activation du service CloudStack Kubernetes et enregistrement d’images ISO contenant les binaires Kubernetes.

8. Surveillance proactive : état du système d’exploitationhôte (CPU, mémoire, espace disque, interfaces réseau, services système) et des baies de disques (état RAID, indicateurs SMART des disques), avec envoi de notifications aux ingénieurs d’INTROSERV.

9. Tests : test des machines virtuelles des trois tailles, des instantanés et des restaurations, de l’accès au réseau externe, des sauvegardes de machines virtuelles et des sauvegardes complètes du serveur.

10. Remise au client : console CloudStack, clés API, documentation de configuration et accès iDRAC.

La durée totale des travaux s'est élevée à 16 heures. Après la remise du projet, INTROSERV assure une assistance en fonction des alertes de surveillance ou des demandes du client : remplacement de disques, mises à jour de l'hyperviseur et du serveur de gestion, et extension de la configuration.

Placement des machines virtuelles

Au cours de la phase pilote, 20 machines virtuelles prenant en charge les systèmes des clients, réparties en trois tailles standard, ont été migrées vers le nœud. La mémoire est allouée sans surengagement : 64 Go restent disponibles pour le serveur de gestion, les machines virtuelles système et les prochains systèmes des clients. Tous les disques des machines virtuelles se trouvent sur la baie NVMe locale du serveur, ce qui confère à chaque machine virtuelle des performances de disque qui auraient nécessité une facturation distincte selon la tarification de stockage de l’hyperscaler pour des IOPS garanties.

Les processeurs virtuels sont alloués avec un surengagement minimal — 72 vCPU pour 64 threads — tandis que l’utilisation réelle du processeur pendant les heures de travail ne dépasse pas 50 %. Environ 700 Go restent libres sur la baie NVMe. Ce projet étant un projet pilote, cette réserve de capacité a été prévue intentionnellement : des systèmes clients supplémentaires peuvent être ajoutés au même nœud sans modifier la configuration, tandis que l’extension de la mémoire à 1 To et l’ajout de disques permettent de multiplier plusieurs fois la capacité du nœud.

L’infrastructure comme avantage stratégique

La solution mise en œuvre par l’équipe INTROSERV a remplacé l’hyperscaler en tant que fournisseur de ressources de calcul pour les systèmes des clients du MSP. Un seul serveur loué équipé d’Apache CloudStack a pris en charge le premier groupe de 20 machines virtuelles, avec une marge de croissance et un niveau de tolérance aux pannes adaptés à la charge de travail.

Le client a ainsi bénéficié de fonctionnalités qui n’étaient pas disponibles dans le cloud public : isolation des clients et suivi de l’utilisation au niveau de la plateforme, libre-service pour les clients disposant de leurs propres comptes, clusters Kubernetes gérés depuis la même console, ainsi qu’une surveillance proactive de l’hôte et des baies de disques. La redondance réseau et électrique, les disques protégés par RAID, le stockage NVMe local, les ports illimités à 25 Gbps et la protection contre les attaques DDoS sont inclus dans le coût du serveur.

Aspects économiques

La majeure partie du trafic transite par les serveurs VPN des clients : le trafic sortant du nœud est de 20 à 35 To par mois. Un ensemble de ressources équivalent chez l’ancien fournisseur — 20 machines virtuelles présentant le même profil, le même stockage, les mêmes instantanés et ce volume de trafic sortant aux tarifs actuels de la région de Francfort — coûte environ 4 000 à 5 100 € par mois, soit environ 54 000 € par an. Sur ce montant, entre 1 500 et 2 600 € correspondent au trafic : chez l’hyperscaler, chaque gigaoctet transmis via VPN aux employés des clients est facturé séparément.

INTROSERV coûte 1 017 € par mois : 671 € pour le serveur principal, 157 € pour le serveur de sauvegarde, 49 € pour la sauvegarde complète du serveur, le reste couvrant l’administration à la demande et l’amortissement du déploiement initial. Deux ports de 25 Gbps avec un trafic illimité sont inclus dans la location du serveur ; ainsi, le trafic sortant généré par les systèmes des clients n’a aucune incidence sur la facture, qu’il s’agisse de 35 ou de 50 To par mois.

Le coût de base est quatre à cinq fois inférieur, le montant est fixe et connu avant le début du mois. Cela a permis au client d’inclure l’infrastructure dans des frais de support fixes, d’offrir à ses clients des conditions plus avantageuses et d’augmenter la rentabilité de la partie infrastructure de ses contrats. À mesure que le portefeuille de clients s'étoffe, l'écart avec l'hyperscaler se creuse : la facture des serveurs ne dépend ni du trafic ni des variations de prix des instances. Le client s'est déclaré pleinement satisfait du coût de la solution.

Prochaines étapes

La plateforme ouverte sans frais de licence a résolu la question de l’évolutivité : l’extension de la mémoire à 1 To multiplie plusieurs fois la capacité des nœuds, tandis qu’un deuxième nœud peut être ajouté au cluster CloudStack existant sans changer d’outils. Les données des clients restent sur des serveurs dédiés dans un centre de données européen, au sein d’un périmètre contrôlé par le client. Pour une entreprise desservant des clients dans l’UE soumise aux exigences du RGPD, il s’agit d’une condition incontournable. À l’issue de la phase pilote, le MSP décidera s’il convient de migrer d’autres groupes de systèmes clients vers CloudStack.

Le coût de votre infrastructure chez un hyperscaler est-il plus élevé qu’il ne devrait l’être, alors que la facture reste impossible à prévoir ? Confiez la migration à l’équipe INTROSERV : nous sélectionnerons la configuration de serveur adaptée, déploierons Apache CloudStack et vous remettrons un cloud privé prêt à l’emploi .