Une étude comparative publiée par Naranjatec présente son Cloud Privé comme une alternative plus économique à Stackscale, en se basant sur le coût du CPU, de la RAM et du stockage. Ce genre de tableau donne une idée approximative du prix de certaines ressources, mais ne suffit pas à déterminer quelle plateforme coûte vraiment moins cher quand les architectures, le modèle de calcul, le stockage, la haute disponibilité et les services associés ne sont pas équivalents. Et dans un marché où le coût du matériel, la mémoire en tête, fluctue en permanence, transformer des prix ponctuels en conclusions définitives rend vite toute comparaison obsolète.
La comparaison Stackscale-Naranjatec en 30 secondes
- Naranjatec compare des ressources virtuelles à une infrastructure Stackscale basée principalement sur des nœuds physiques dédiés.
- Un vCore ou vCPU ne correspond pas forcément à un cœur physique, ce qui rend les comparaisons unitaires trompeuses.
- Le stockage NVMe local et le stockage centralisé en réseau répondent à des besoins différents.
- Haute disponibilité, snapshots, réplication, reprise après sinistre, réseau et support font aussi partie du coût.
- Pour savoir qui est réellement moins cher, il faut demander à chaque fournisseur une architecture identique et comparer le coût total.
La question n’est pas de savoir si les prix affichés par Naranjatec sont bons ou mauvais : l’offre peut tout à fait être économiquement attractive pour certains projets. Le problème apparaît quand le prix d’une unité sert à en déduire le coût d’une infrastructure complète. Une comparaison rigoureuse devrait normaliser architecture, stockage, disponibilité, réseau, support et conditions contractuelles avant de trancher. Deux offres affichant la même capacité nominale en CPU, RAM et to peuvent rendre des services très différents.
Un vCPU et un cœur physique ne sont pas la même unité
Le premier point à examiner reste le CPU. Naranjatec présente une partie de son offre en vCores. Stackscale construit son Cloud Privé autour de serveurs physiques dédiés, avec un nombre défini de processeurs, de cœurs, de mémoire et de stockage local, sur une gamme reposant à la fois sur Intel Xeon et AMD EPYC. Convertir ces serveurs en prix théorique par cœur pour le comparer au prix d’une vCPU reste une simplification lourde de conséquences.
Un cœur physique est une unité de traitement intégrée au processeur du serveur. Une vCPU ou vCore est une abstraction que l’hyperviseur propose à une machine virtuelle, et sa capacité effective dépend du processeur physique sous-jacent, de sa génération, de sa fréquence, de la politique de planification de l’hyperviseur, du nombre de charges simultanées et de l’allocation des ressources. Ce n’est pas dire qu’une vCPU rend forcément moins bien, seulement qu’il n’existe pas d’équivalence universelle entre une vCPU et un cœur physique. Deux plateformes peuvent annoncer 100, 200 ou 500 vCPUs pour des capacités réelles très différentes. Pour comparer correctement, il faut connaître les processeurs utilisés, les ressources physiques disponibles et la politique d’allocation de chaque plateforme.
Additionner indépendamment CPU et RAM pour estimer le prix de Stackscale ne reflète d’ailleurs pas son modèle commercial. Stackscale vend son Cloud Privé sur des serveurs dédiés où CPU et mémoire forment une seule unité au niveau du nœud. Le client n’achète pas un espace virtuel abstrait de vCPU et de gigaoctets, mais une capacité physique qui sera ensuite virtualisée via Proxmox VE ou VMware.
Le stockage, la partie la plus trompeuse de la comparaison
La capacité est sans doute la métrique la plus trompeuse quand on compare des systèmes de stockage. Deux infrastructures peuvent afficher 10 To tout en répondant à des besoins totalement différents. Un serveur avec des disques NVMe locaux offre des latences très faibles et un gros volume d’IOPS, ce qui en fait souvent un excellent choix pour des bases de données, du cache ou du traitement intensif, avec un bon rendement par euro investi. Le problème survient quand on le compare directement à un stockage d’entreprise centralisé comme si seul le prix du gigaoctet comptait.
Stackscale combine des disques locaux dans ses nœuds avec une plateforme indépendante de stockage centralisé en réseau, proposée à plusieurs niveaux de service. Sa documentation publique détaille des solutions basées sur NetApp, avec différents objectifs de latence et d’IOPS, des snapshots et de la géoréplication, ainsi qu’un stockage avec réplication synchrone entre deux datacenters de Madrid, pensé pour les architectures exigeant un RPO et un RTO nuls. Évoquer simplement « le stockage » masque donc une bonne partie de la comparaison.
| Caractéristique | NVMe local | Stockage d’entreprise en réseau |
|---|---|---|
| Emplacement | Dans le serveur | Sur le réseau, partagé entre nœuds |
| Latence | Potentiellement très faible | Dépend du niveau de service |
| IOPS | Généralement élevés | Variable selon la solution |
| Dépendance au nœud | Haute sans autre protection | Faible, accessible depuis plusieurs nœuds |
| Mobilité des VM | Dépend de la réplication ou migration de disques | Facilitée par le partage natif |
| Snapshots / réplication géo | Nécessite des mécanismes additionnels | Généralement intégrés |
| Usage typique | Performance locale, charges spécifiques | Haute disponibilité, protection des données |
Aucune des deux approches n’est universellement supérieure, tout dépend de ce dont l’application a réellement besoin. Une entreprise qui cherche une capacité NVMe rapide et gère elle-même sa protection de données y trouvera un excellent rapport coût/rendement. À l’inverse, dès qu’il faut déplacer des machines entre hôtes, séparer calcul et stockage, garder des snapshots ou répliquer entre sites, le problème change de nature, et le coût avec lui.
Que se passe-t-il en cas de défaillance d’un nœud ?
Ce scénario aide à saisir la différence. Une VM hébergée sur un serveur dont les disques ne vivent que sur ses NVMe locaux dépendra, en cas de panne matérielle, des mécanismes déployés en amont (réplication, stockage distribué, sauvegarde). Dans un cluster avec stockage partagé accessible depuis plusieurs serveurs, un autre nœud continue d’accéder aux données et, avec une plateforme HA correctement conçue, la VM peut redémarrer ailleurs. Rien n’indique que Naranjatec manque de mécanismes pour gérer une panne de serveur : l’absence de détails publics sur une fonctionnalité ne prouve pas son inexistence.
La bonne question à poser à tout fournisseur reste simple : que se passe-t-il pour mes machines et mes données en cas de panne complète d’un serveur ? Et quels RPO, RTO et SLA sont réellement engagés ? Ces réponses en disent bien plus long sur une plateforme que le prix du gigaoctet.
KVM et Proxmox ne s’opposent pas
Autre précision technique utile : Naranjatec utilise KVM avec Virtualizor, tandis que Stackscale propose Proxmox VE comme plateforme principale. Sauf que Proxmox VE s’appuie lui aussi sur KVM pour exécuter ses machines virtuelles. La différence se joue dans les couches de gestion et la façon dont l’infrastructure est construite autour. Proxmox VE intègre KVM et les conteneurs LXC avec la gestion de cluster, la haute disponibilité, le stockage, le réseau, la migration et une administration centralisée, éventuellement associée à Proxmox Backup Server. Stackscale le propose sur ses nœuds dédiés, combiné selon le contrat à du stockage d’entreprise et à des réseaux privés haute capacité. Virtualizor vise le même objectif de gestion d’environnements virtualisés, et il ne serait pas sérieux d’en tirer une conclusion sur le seul nom.
La comparaison doit porter sur l’architecture globale résultante : combien de nœuds, y a-t-il un cluster, comment se gère le quorum, où résident les disques des machines, existe-t-il de la haute disponibilité, que se passe-t-il si un hôte tombe, comment sont faits les backups ? Répondre à ces questions permet de comparer des infrastructures concrètes. Comparer uniquement l’hyperviseur, non.
La haute disponibilité : une capacité payée qu’on espère ne jamais utiliser
Il existe aussi un coût difficile à mettre dans un tableau par vCPU : la capacité de réserve. Une entreprise qui a besoin de trois serveurs pour porter toute sa charge peut en acheter trois et les faire tourner presque à plein. Mais si elle veut que ses applications survivent à la panne d’un serveur, l’architecture doit prévoir assez de capacité sur les autres pour absorber la charge, un surplus qui coûte même quand il reste inutilisé la majorité du temps.
Stackscale propose des architectures Cloud Privé avec nœuds dédiés, redondance, capacités de haute disponibilité, nœuds de réserve et géoréplication en option. Ce principe vaut pour tout fournisseur : avoir trois serveurs n’équivaut pas automatiquement à de la haute disponibilité. Il faut aussi de l’espace de stockage, un réseau, un quorum, de la capacité disponible, des mécanismes de détection de panne et des procédures de récupération. C’est pour ça qu’une VM de huit vCPUs peut coûter très différemment selon ce qui est prévu en cas de panne de l’hôte physique.
Le réseau fait partie de l’infrastructure, pas un détail
Le réseau reste souvent relegué au second plan dans les comparatifs cloud, alors qu’il joue un rôle central dans une infrastructure distribuée. Stackscale documente ses nœuds avec des connexions haute capacité pouvant atteindre plusieurs dizaines de gigabits par seconde, plus une infrastructure redondante pour le stockage, les interconnexions privées et l’accès Internet. Une bande passante plus élevée ne rend pas automatiquement un fournisseur meilleur, une simple application web n’en aura jamais vraiment besoin, mais la donne change dès qu’il y a du trafic de stockage, des migrations de VM, de la réplication, des sauvegardes ou de gros volumes entre nœuds. Dans ces architectures, le réseau interne peut devenir le facteur limitant des performances globales, d’où l’intérêt d’inclure capacité, redondance, topologie et trafic dans toute comparaison sérieuse.
Une ou plusieurs localisations, deux problèmes différents
Même logique pour les centres de données. Héberger dans un seul datacenter suffit pour beaucoup d’applications, mais dès qu’il y a un besoin de reprise après sinistre, de réplication géographique ou de continuité en cas de perte totale d’un site, la présence sur plusieurs sites ouvre des architectures différentes. Stackscale propose un Cloud Privé à Madrid et Amsterdam, avec réplication et reprise après sinistre basées sur ses infrastructures de stockage et de réseau, et un stockage synchrone entre deux datacenters madrilènes physiquement séparés. Naranjatec héberge son infrastructure à Amsterdam. Rien de tout ça ne rend automatiquement une plateforme meilleure que l’autre : une entreprise qui n’a besoin d’héberger qu’une application aux Pays-Bas n’a pas forcément intérêt à payer plusieurs sites, mais celle qui doit séparer production et reprise après sinistre y trouve une vraie valeur économique et opérationnelle.
Snapshot, backup, réplication et reprise après sinistre ne sont pas synonymes
Une erreur fréquente consiste à regrouper toutes les technologies de protection sous le mot « backup ». Un snapshot restaure un état antérieur du stockage. Un backup est une copie destinée à la récupération avec des politiques de conservation propres. Une réplication maintient une copie identique des données sur un autre système, la version synchrone visant à mettre à jour ces copies simultanément. La reprise après sinistre, elle, décrit la procédure pour restaurer des applications et services complets en cas de catastrophe. Stackscale propose snapshots, géoréplication et des services dédiés de sauvegarde et de DR, ce qui montre qu’une capacité affichée de 10 To peut recouvrir des niveaux de protection très différents. Se limiter au coût de stockage de ces 10 To ignore le coût de leur protection.
Ce que doit inclure une comparaison vraiment équivalente
Le tableau initial de Naranjatec peut servir d’approximation commerciale, mais il ne dit pas quelle infrastructure coûte le moins cher pour faire tourner les mêmes applications. Une comparaison plus complète ressemblerait plutôt à ceci :
| Aspect | Ce qu’il faut normaliser |
|---|---|
| CPU | Modèle, génération, cœurs physiques, threads et allocation de vCPU |
| RAM | Capacité physique et capacité réellement utilisable |
| Virtualisation | Hyperviseur, gestion, clustering et licences |
| Nœuds | Nombre de serveurs et capacité de chacun |
| Redondance | N, N+1 ou autre architecture |
| Stockage | Local, partagé ou distribué |
| Performance du stockage | IOPS, débit et latence |
| HA | Comportement en cas de panne totale d’un nœud |
| Snapshots | Fréquence et conservation |
| Sauvegarde | Technologie, capacité, conservation et lieu |
| Réplication | Synchrone ou asynchrone, distance entre copies |
| DR | Procédure et site de récupération |
| RPO/RTO | Perte maximale de données et délai de récupération |
| Réseau | Interfaces, redondance et capacité interne |
| Internet | Débit, trafic inclus |
| SLA | Ce qui est couvert et disponibilité |
| Support | Horaires, périmètre et responsabilités |
| Contrat | Période d’engagement, annulation et obligations |
| Scalabilité | Coût et procédure d’extension |
À partir de là, demander deux devis prend tout son sens. Une entreprise pourrait, par exemple, demander une plateforme avec une capacité CPU utilisable déterminée, 1 TiB de RAM, 10 TiB de stockage, tolérance à la panne d’un nœud, stockage partagé, certains niveaux d’IOPS et de latence, snapshots, sauvegarde avec conservation spécifique, réplication géographique, RPO et RTO définis, connectivité redondante et support 24/7. Les deux fournisseurs répondent alors au même cahier des charges, et le prix final de ces deux propositions devient bien plus pertinent que de diviser le coût d’une vCPU par celui d’une autre.
Naranjatec peut être moins cher, mais la comparaison reste incomplète
Remettre en cause la méthodologie ne signifie pas que Naranjatec soit forcément plus cher, ce pourrait même être l’inverse. Pour une entreprise qui privilégie le prix, avec des besoins en matériel dédié, virtualisation et stockage local haute performance, sans exigence particulière en stockage centralisé, réplication ou sauvegarde avancée, leur offre peut être très compétitive. L’erreur serait d’extrapoler cette conclusion à tout projet.
Stackscale propose une infrastructure d’entreprise sur nœuds physiques dédiés, combinée à Proxmox VE, stockage centralisé, plusieurs niveaux de service, réseaux haute capacité, haute disponibilité, réplication et plusieurs sites. Tout ça a un coût, et le retirer de la comparaison ne le supprime pas : ça revient simplement à comparer des services différents. Ce point compte d’autant plus dans un contexte où les prix du matériel bougent vite, la mémoire, le stockage et les processeurs influençant directement le coût de construction d’une infrastructure dédiée. Une photo des prix à un instant T devient vite obsolète.
Pour un DSI ou un responsable infrastructure, la vraie question n’est pas de savoir qui vend la vCPU la moins chère, mais combien coûte le maintien des applications au niveau de performance, de disponibilité, de protection des données et de résilience que l’entreprise exige réellement. Un prix plus bas par vCPU ne veut pas forcément dire un coût moindre pour faire tourner la même infrastructure.
Questions fréquentes
Peut-on comparer directement le prix par vCPU de deux fournisseurs cloud ?
Seulement si les conditions de base sont suffisamment équivalentes. La qualité des processeurs, l’allocation des ressources, le surengagement, l’architecture physique et le niveau de service peuvent faire que deux vCPUs offrent des capacités très différentes.
Stockage NVMe local ou stockage en réseau, lequel choisir ?
Ça dépend de l’usage. Le NVMe local offre un excellent rapport performance/prix, tandis que le stockage centralisé convient mieux dès qu’il faut des données indépendantes du nœud, du stockage partagé, de la haute disponibilité, des snapshots ou de la réplication.
Proxmox VE utilise-t-il KVM ?
Oui. Proxmox VE s’appuie sur KVM pour la virtualisation et ajoute une gestion intégrée comprenant clustering, haute disponibilité, stockage, réseau, migration et administration centralisée.
Comment comparer le coût de deux clouds privés ?
En demandant une architecture équivalente à chaque fournisseur, avec CPU, RAM, stockage, redondance, HA, sauvegarde, réplication, réseau, SLA, RPO, RTO, support et durée contractuelle précisés, avant de comparer le coût total.
Sources :
- Naranjatec, comparatif Une alternative plus économique à Stackscale, et documentation publique du Cloud Privé.
- Stackscale, documentation de Cloud Privé et nœuds dédiés.
- Stackscale, documentation sur le stockage en réseau et la géoréplication synchrone.
- Stackscale, solutions de reprise après sinistre et sauvegarde.
- Documentation officielle de Proxmox Virtual Environment.
Avertissement sur les prix et conditions : les caractéristiques, tarifs et modalités commerciales des services cloud peuvent évoluer, surtout en période de fluctuation des coûts de composants comme la mémoire, le stockage ou les processeurs. Cet article privilégie une approche architecturale et fonctionnelle, et ne doit pas être considéré comme une cotation commerciale. Pour une comparaison actualisée, mieux vaut demander des devis aux fournisseurs avec une architecture, capacité, niveau de disponibilité, support et conditions contractuelles identiques.