KubeCON 2023 : Veritas crée la surprise avec un SDS pour Kubernetes
L’éditeur spécialiste de la sauvegarde dévoile InfoScale 8, un système de stockage persistant pour Kubernetes qui se veut plus rapide que la concurrence. Le produit est resté confidentiel durant des années.
Ce fut l’une des surprises du salon KubeCON, dédié à l’écosystème Kubernetes, qui se tenait mi-avril à Amsterdam. Les visiteurs venus sur le stand de Veritas pour s’enquérir des capacités de NetBackup à sauvegarder des clusters Kubernetes repartaient avec la conviction qu’ils devaient déployer… le SDS InfoScale. En concurrence directe avec Portworx, la locomotive des systèmes de stockage persistants pour Kubernetes, InfoScale offre aux applications exécutées en containers une baie de disques virtuelle en mode bloc. Censée être plus proche que Portworx du noyau Linux qui motorise les serveurs d’un cluster Kubernetes, cette ressource de stockage permet aux bases de données SQL et aux applications les plus exigeantes en I/O d’écrire et de lire avec une latence réduite au minimum.
Ironiquement, la sauvegarde, spécialité habituelle de Veritas, correspond plutôt à du stockage considéré lent.
« InfoScale apporte toutes les fonctions que vous pouvez attendre d’une solution SAN : l’écriture en miroir vers plusieurs nœuds à des fins de redondance, soit en synchrone en local, soit par réplication si vos nœuds miroirs se trouvent dans un autre datacenter. Et nous utilisons un algorithme d’Erasure coding avec un dispositif de répartition de charge grâce auxquels vous continuez d’accéder à vos données même si vous perdez un disque, un nœud, ou un ensemble de nœuds », explique Petter Sveum (en photo ci-dessus), l’architecte en chef d’InfoScale chez Veritas.
Un SAN pour Kubernetes
De base, un cluster Kubernetes exécute des containers volatiles, dont toutes les données disparaissent à l’extinction. Ce principe est adapté aux fonctions des applicatifs web, qui servent juste à diffuser des informations et qui se mettent en route ou s’éteignent selon le trafic généré par les utilisateurs.
En revanche, il n’est pas adapté aux applications traditionnelles du datacenter qui sauvegardent des données à chaque session et doivent les récupérer d’un redémarrage à l’autre. Or, de plus en plus, les entreprises souhaitent exécuter leurs applications historiques en containers, bien moins chers que le format en machines virtuelles.
« Tous les fabricants de baies de stockage proposent un pilote CSI, mais le nôtre a le mérite d’être compatible avec toutes les baies de disques. Notre solution est universelle. »
Petter SveumArchitecte en chef d’InfoScale, Veritas.
« Nos premiers clients sur InfoScale sont des banques ou des telcos qui veulent migrer des applications et des bases de données de plusieurs To de VMware, ou OpenStack, vers Kubernetes. Avec un stockage en mode bloc qui s’intègre à Kubernetes via un pilote CSI, vous éliminez la contrainte de passer à un stockage objet qui n’a rien à voir. Tous les fabricants de baies de stockage proposent un pilote CSI, mais le nôtre a le mérite d’être compatible avec toutes les baies de disques. Notre solution est universelle », argumente Petter Sveum.
Selon la démonstration à laquelle LeMagIT a pu assister, InfoScale est même capable de simuler une baie SAN globale depuis des baies de disques de marques et de tailles différentes.
« Notre avantage supplémentaire – et c’est d’abord pour cela que les entreprises viennent nous voir – est que la migration est encore plus simple en passant par NetBackup, qui enregistre puis restaure des snapshots dédupliqués. Cela signifie qu’il s’occupe de remettre en production des bases fonctionnelles sans avoir eu à arrêter celles en cours de production. Et qu’il le fait d’autant plus rapidement qu’il économise de la bande passante réseau », ajoute notre interlocuteur.
Il s’empresse de préciser que NetBackup et InfoScale sont indépendants : l’un pouvant sauvegarder tous les systèmes de stockage pour Kubernetes et l’autre pouvant être sauvegardé par n’importe quel logiciel de backup. Et, surtout, qu’InfoScale s’adresse désormais à toutes les entreprises, plus uniquement aux grands comptes.
Pour l’instant, 16 nœuds gérés depuis OpenShift
InfoScale s’accompagne d’une console d’administration qui permet de diviser la capacité de stockage globale en volumes (en classes de stockage persistant dans le jargon de Kubernetes) qui peuvent chacune avoir des caractéristiques particulières, comme l’écriture en miroir, la déduplication, le partage ou non entre plusieurs pods, la qualité de service.
Ensuite, lorsqu’une application est déployée en container avec un fichier de configuration qui réclame l’accès à du stockage persistant, InfoScale s’occupe d’appliquer toutes les règles sans que l’utilisateur de l’application s’en rende compte.
En l’état, cette console s’intègre à celle d’OpenShift, le Kubernetes de Red Hat. Veritas explique qu’InfoScale reste utilisable avec n’importe quel autre Kubernetes si l’administrateur fait l’effort de le piloter depuis la ligne de commande. A priori, des versions futures du système devraient s’intégrer à d’autres consoles.
Il n’en reste pas moins que Red Hat édite lui-même un système de stockage persistant pour Kubernetes : Ceph. « Ceph n’est pas aussi rapide qu’InfoScale. D’une part, parce que ses nœuds de stockage s’accèdent via un protocole réseau – alors qu’InfoScale présente le stockage comme s’il était intégré au serveur. D’autre part, Ceph est avant tout un système objet auquel on greffe des passerelles pour y accéder en mode bloc ou en mode fichiers », répond l’architecte en chef de Veritas.
Plus performant, certes, mais pas autant élastique. Pour l’heure, InfoScale ne peut gérer que 16 nœuds de stockage, contre des centaines pour Ceph.
« C’est une limite sur laquelle nous travaillons. Nous proposerons bientôt la possibilité de constituer des clusters de grappes InfoScale. Mais pour l’heure, cette limite n’est pas très gênante dans le sens où vous n’avez généralement besoin de beaucoup d’I/O que pour une application et non pour plusieurs qui communiquent entre elles. Il suffit donc d’accorder un stockage InfoScale différent à chaque application qui a besoin de vitesse », assure Petter Sveum.
Un SDS qui remonte aux années 2010
De manière assez étonnante, la version d’InfoScale présentée sur le stand de Veritas était numérotée… 8. « En fait, il s’agit d’un produit relativement ancien, qui s’appelait initialement Veritas Storage Foundation, que nous avons renommé InfoScale en 2016 et dont nous n’avions jamais vraiment fait la publicité, à part auprès des grands comptes. En revanche, il prend aujourd’hui tout son sens avec Kubernetes », dit Petter Sveum.
Le SDS de Veritas est ainsi né quelque part dans les années 2010 pour partager du stockage entre plusieurs machines virtuelles hébergées en cloud. « À l’époque, chaque machine virtuelle en cloud avait son propre stockage. D’ailleurs, jusqu’à très récemment, sur AWS, le volume en mode bloc déployé avec une machine virtuelle EC2 n’était pas utilisable par une autre VM. Nous avions mis au point ce système pour partager ce volume avec des VMs qui pouvaient même se situer sur d’autres réseaux. »
Veritas Storage Foundation épaulait à ce moment-là NetBackup pour sauvegarder les serveurs d’un datacenter vers le cloud et, ensuite, pouvoir redéployer depuis le cloud ces sauvegardes vers d’autres datacenters. Au fur et à mesure, le système s’est doté des fonctions de haut niveau que l’on trouve sur les baies SAN, comme le mirroring et la réplication asynchrone.
« Ce système était dédié à l’application exécutée sur des VMs en cloud. Que ce soit notre backup, ou, plus tard, l’application de nos clients. Conceptuellement, nous nous sommes rendu compte récemment qu’il suffisait de considérer l’orchestrateur Kubernetes comme une application pour qu’InfoScale devienne son SDS. Il ne nous restait plus qu’à ajouter les bons outils d’orchestration pour faciliter la configuration d’un SDS sur les Kubernetes du marché. Et c’est ce que nous faisons aujourd’hui », conclut Petter Sveum.
