SUSE Virtualization et Portworx : bien choisir sa stratégie stockage

Les projets de virtualisation sur Kubernetes démarrent presque toujours par la même phrase : « On veut faire tourner des VMs sur une plateforme moderne ». Et ils se gagnent (ou se perdent) sur un point beaucoup plus concret : le stockage.

Parce qu’en production, le stockage ne se résume jamais à “avoir un volume”. C’est ce qui conditionne :

les performances ressenties par les applications,
la facilité à grandir (capacité / densité),
la protection des données (snapshots, sauvegarde),
et la continuité d’activité (reprise après incident, reprise après sinistre).

Avec SUSE Virtualization (anciennement Harvester), vous avez plusieurs manières de construire cette brique. L’objectif de cet article est simple :

poser les options de stockage réellement rencontrées sur le terrain ;
expliquer, sans marketing, en quoi Portworx apporte de la valeur quand on vise un niveau “entreprise”.

Ce que vous achetez vraiment quand vous choisissez une option de stockage

Avant de parler de produits, clarifions le sujet.

Sur une plateforme comme SUSE Virtualization, le stockage doit répondre à trois besoins en même temps :

Stocker (capacité, performance, résilience)
Protéger (snapshots, sauvegarde, rétention, restauration)
Assurer la continuité (résistance à la panne, reprise, éventuellement PRA)

Selon vos contraintes (SLA, criticité, rythme de croissance), vous n’irez pas vers la même option.

Les 3 options de stockage les plus courantes avec SUSE Virtualization

Avant de détailler les options, un repère utile : dans Kubernetes, le stockage passe généralement par le CSI (Container Storage Interface). Concrètement, cela veut dire que la plateforme s’appuie sur des drivers CSI pour exposer du stockage sous forme de StorageClasses (classes de stockage) et de Persistent Volumes (volumes persistants). C’est ce mécanisme qui permet ensuite d’activer des fonctions clés comme les snapshots (via VolumeSnapshot) et, selon les solutions, de la réplication ou des politiques de protection.

Option A — Stockage distribué intégré (approche “hyperconvergée”)

C’est souvent le point d’entrée le plus simple : la plateforme s’appuie sur les disques des nœuds et propose un stockage distribué, accessible via la logique Kubernetes (driver CSI + StorageClasses).

Dans l’écosystème SUSE, le repère le plus courant pour cette approche est SUSE Storage, dérivé du projet open source Longhorn : un stockage bloc distribué orchestré par Kubernetes, avec réplication synchrone sur plusieurs nœuds pour éviter le point de défaillance unique. On y retrouve les fonctionnalités attendues pour démarrer proprement : snapshots incrémentaux, sauvegarde vers un stockage secondaire (NFS ou S3 compatible), tâches récurrentes (snapshots/backups), mises à jour non disruptives de la pile stockage, et une GUI dédiée pour visualiser et opérer les volumes.

Pourquoi ça marche bien :

Démarrage rapide, moins de dépendances
Architecture homogène (compute + stockage sur les mêmes nœuds)
Bon compromis pour des environnements “standard”

Ce qu’il faut accepter :

La performance et la capacité évoluent avec le dimensionnement des nœuds : si vous grandissez, vous grandissez “en même temps” compute et stockage.
Plus la criticité monte, plus la question “protection / restauration / continuité” devient structurante (et doit être cadrée).

Si vous voulez migrer quelques dizaines de VMs non critiques et gagner du temps, c’est souvent une option raisonnable.

Option B — Stockage externe (baie/SAN : une brique data dédiée)

Certaines organisations préfèrent s’appuyer sur un stockage externe déjà maîtrisé (baies, SAN/NVMe, standards internes, pratiques de sauvegarde établies). Le stockage devient alors une brique spécialisée, indépendante du compute.

Dans ce cas, l’intégration se fait généralement via un CSI pour stockage externe : la baie expose des volumes, Kubernetes les consomme via des StorageClasses, et la plateforme peut ensuite appliquer des politiques (classes, quotas, snapshots) de façon standardisée.

Pourquoi ça peut être préférable :

Exigences fortes de performance/latence sur certaines VMs
Densité et capacité plus faciles à piloter indépendamment du compute
Gouvernance data plus simple quand la DSI a déjà des standards et des contrats

Ce qu’il faut accepter :

Plus de composants, donc plus de sujets d’intégration (réseau, chemins, opérations)
Un effort supplémentaire pour unifier l’exploitation (sinon vous créez un “monde stockage” à part)

Cette option est très fréquente dès qu’on parle de workloads critiques, de croissance forte, ou de règles DSI déjà en place.

Option C — Approche hybride (démarrer simple, monter en gamme)

C’est le scénario le plus réaliste dans beaucoup de sorties VMware :

démarrer avec un stockage distribué intégré (CSI + classes de stockage) pour adopter la plateforme,
migrer les premières VMs,
puis basculer certains workloads vers un stockage externe (toujours via CSI) ou une couche data plus “entreprise” quand les exigences montent.

C’est aussi une façon saine de garder un langage commun : StorageClasses, snapshots, politiques, plutôt que des “procédures à part” selon les équipes.

Pourquoi c’est une bonne stratégie :

Vous évitez un “big bang” data
Vous apprenez en avançant
Vous adaptez la brique stockage au bon moment (quand les workloads métier arrivent)

Le risque de l’hybride n’est pas l’hybride lui-même : c’est de rester “entre deux” trop longtemps sans standardiser.

Le vrai problème à éviter : recréer un silo “VM” et un silo “Kubernetes”

Dans les projets, on voit souvent émerger ce piège :

les VMs ont leurs outils stockage/backup/habitudes,
les workloads Kubernetes ont une autre chaîne,
et l’exploitation se retrouve à opérer deux mondes.

C’est précisément là que l’approche “virtualisation moderne” perd sa promesse. La plateforme devient plus complexe qu’avant, et le projet se fait attaquer sur un argument simple : « c’est moins efficace que VMware ».

La clé est donc de choisir un modèle de stockage et de gestion des données qui réduit cette fracture, au lieu de l’accentuer.

Ce que Portworx by Pure Storage apporte (quand vous visez une exigence “entreprise”)

Portworx est souvent mal compris si on le résume à “un stockage Kubernetes”. Techniquement, il s’insère dans les standards cloud-native (CSI, StorageClasses, snapshots), mais sa valeur vient surtout de la couche de gestion au-dessus : comment vous définissez des politiques de données et comment vous les appliquez de façon cohérente à l’échelle, pour des workloads qui ne pardonnent pas.

Voici les apports concrets qui reviennent le plus souvent — et, dans beaucoup d’organisations, les raisons pour lesquelles Portworx by Pure Storage devient un choix privilégié quand on cherche une sortie VMware durable sans recréer de silos.

Une approche unifiée pour VMs et workloads Kubernetes

Quand une DSI adopte SUSE Virtualization, elle cherche rarement à garder les VMs “à part”. Elle veut converger : mêmes règles, mêmes politiques, mêmes standards.

Portworx aide à construire cette cohérence autour des données : des pratiques de stockage et de protection qui peuvent s’appliquer à des workloads différents (VMs et conteneurs), sans bricolage.

Le bénéfice se voit vite : moins d’exceptions, moins de “cas à part”, moins d’outils en parallèle.

Continuité d’activité : passer de “ça tourne” à “on sait reprendre”

Beaucoup de décisions stockage se prennent sur un moment de vérité :

une panne,
une restauration urgente,
un incident multi-composants,
ou un exercice de reprise.

Là, la question n’est plus “est-ce possible ?” mais “est-ce reproductible, rapide, et documentable ?”.

Portworx prend de la valeur quand la continuité d’activité et la protection des données deviennent des exigences structurantes : vous ne voulez pas simplement “faire un snapshot”. Vous voulez une approche industrialisable de la protection et, quand c’est nécessaire, des mécanismes de reprise.

Performance et densité : quand le stockage devient le juge de paix

Les VMs critiques (bases, middleware, applications à forte intensité I/O) sont souvent celles qui font basculer la décision.

Dans ces cas, vous cherchez une combinaison :

performances stables,
capacité à grandir sans tout redimensionner,
et exploitation qui ne se transforme pas en artisanat.

Portworx devient pertinent quand vous voulez standardiser ce niveau d’exigence, plutôt que de traiter chaque VM “au cas par cas”.

Flexibilité : éviter de se ré-enfermer

Une sortie VMware est souvent motivée par un sentiment de dépendance et de rigidité. Il serait dommage de reconstruire le même problème.

L’intérêt d’une couche de gestion des données bien pensée, c’est aussi de vous donner une trajectoire plus flexible : vous pouvez garder votre stratégie VM, accélérer votre modernisation, et faire évoluer votre brique stockage sans casser toute la plateforme.

Quand Portworx by Pure Storage est un “plus” évident… et quand rester simple

Pour garder une vision globale : il est tout à fait possible de démarrer sans Portworx by Pure Storage. Mais si votre objectif est de bâtir une plateforme qui tiendra plusieurs années (mix VM + cloud-native, exigences de reprise, croissance de volumes), standardiser tôt sur une couche data robuste évite beaucoup de ré-architecture.

C’est aussi pour cette raison que, chez Skalio, nous avons tendance à recommander Portworx by Pure Storage dès qu’on vise un socle “production entreprise” : on investit une bonne fois dans la brique data, puis on fait évoluer les workloads autour, sans réouvrir le débat stockage à chaque montée en criticité.

Pour rester pragmatique, Portworx apporte le plus de valeur quand :

vous migrez des workloads VM sensibles (perf, latence, volumes importants),
la protection et la reprise ne sont pas négociables,
vous voulez éviter une fracture durable entre “monde VM” et “monde Kubernetes”,
vous cherchez une trajectoire qui reste flexible et industrialisable.

À l’inverse, si votre usage VM est limité et non critique, démarrer avec une approche plus simple peut être un excellent choix. Le point important est de ne pas repousser indéfiniment la question dès que des workloads métier arrivent.

Conclusion

Sur SUSE Virtualization, le stockage n’est pas une case à cocher : c’est la brique qui décide si l’expérience sera “plus simple qu’avant” ou “plus fragile qu’avant”. Le bon raisonnement consiste à choisir d’abord l’architecture qui colle à votre réalité : stockage distribué intégré, stockage externe via CSI, ou hybride puis à regarder où se situe votre niveau d’exigence : performance, densité, protection des données, continuité d’activité.

C’est précisément là que Portworx by Pure Storage devient un accélérateur. Pas parce qu’il “fait du stockage”, mais parce qu’il apporte une couche de data management cohérente avec Kubernetes (CSI, StorageClasses, snapshots) et suffisamment industrialisable pour des workloads VM sérieux : moins d’exceptions, une approche plus uniforme entre VMs et applications cloud-native, et une trajectoire plus flexible quand les contraintes (SLA, volumes, reprise) montent.

En clair : si vous voulez que SUSE Virtualization ne soit pas seulement une alternative VMware, mais une plateforme durable qui tient dans le temps, la question n’est pas “quel stockage choisir ?” C’est “quelle stratégie data va éviter de recréer des silos et nous permettre de grandir sereinement ?”. Dans ce scénario, Portworx by Pure Storage est souvent la pièce qui transforme une migration en standard de production.