Sauvegarde : la méthode de Sopra Steria pour protéger ses clusters Kubernetes

L’enjeu de prendre en charge la cohérence entre les containers et leurs données

« En clair, vous sauvegardez les applications de base de données d’un côté et les données de l’autre. Quand nous avons commencé à travailler sur Kubernetes, il s’agissait d’un cluster interne pour nos développeurs et cela était déjà très compliqué à faire », se souvient Thomas Jouffroy.

« Dans mon équipe, responsable de la fourniture de la plateforme d’infrastructure, nous développions des scripts CRON [du nom du système d’automatisation de Linux, N.D.R.] pour tout sauvegarder en même temps, avec nos droits d’accès administrateurs. Mais ils étaient très compliqués à maintenir. D’autant plus qu’il apparaissait déjà que, en production, il valait mieux que ce soient les développeurs eux-mêmes qui décident quoi sauvegarder à quel moment. »

« L’avantage de base de Kasten est qu’il permettait de faire une sauvegarde avec une consistance applicative dans un même domaine. Et leur équipe était suffisamment ouverte pour travailler avec nous à la mise en place d’un dispositif de libre-service qui permette à nos développeurs de programmer eux-mêmes leurs sauvegardes », ajoute l’ingénieur.

Aller au-delà des offres qui passent par des pilotes CSI

Au fil du temps, et avec l’absolue nécessité de lire des fichiers ou des blocs (notamment pour les bases de données), les fournisseurs ont développé des pilotes CSI qui permettent à des clusters Kubernetes d’accéder directement à leurs baies de disques.

« Via un pilote CSI, le stockage sous Kubernetes ressemble bien plus à du stockage ordinaire, que vous pouvez sauvegarder en procédant à un simple snapshot du système de fichiers sur la baie. Pour maintenir la cohérence applicative entre les containers, il suffit que le système de snapshot se greffe sur le pilote CSI, ce que de nombreuses solutions de sauvegarde proposent à présent », dit Thomas Jouffroy.

« Mais nos clients ne travaillent pas tous avec des baies de disques offrant un pilote CSI. En fait, il reste possible d’adresser directement sous Kubernetes es volumes de stockage via leurs numéros d’unités logiques SCSI (les LUN). Mais encore faut-il pouvoir conjuguer la consistance applicative avec des numéros de LUN. Et cela, il n’y a que Kasten qui sache le faire. »

En l’occurrence, Kasten repose sur un module appelé Generic Storage Backup, ou GSB, qui consiste à monter le système de fichiers d’une application dans un container à part et à recopier toutes les données qui s’y trouvent vers la sauvegarde. L’avantage de GSB est qu’il se greffe sur la configuration du cluster pour savoir quels containers dépendent de quelles données.

« Un autre point important à prendre en compte est que toutes les solutions de sauvegarde alternatives qui sont compatibles avec les pilotes CSI font le choix de stocker leurs sauvegardes sur une baie en mode objet. Mais, là encore, nos clients n’ont pas nécessairement de baie de stockage en mode objet à dédier à cette activité. Il faut donc être en mesure de sauvegarder en mode fichier, via un protocole NFS de base, ce que fait Kasten », précise Thomas Jouffroy.

Kanister et les Transform Sets pour s’adapter aux usages

Toujours est-il que la question de ne pas acheter des licences de Kasten peut légitimement se poser à une entreprise lorsqu’elle achète une baie de stockage qui est non seulement fournie avec son pilote CSI, mais aussi avec son propre système de snapshot compatible.

« Nous avons eu le cas en interne, lorsque Sopra Steria s’est équipé d’une baie NetApp proposée à la vente avec son logiciel de sauvegarde Astra Control pour Kubernetes. Pour autant, nous avons insisté pour l’utiliser avec Kasten, car nous avions déjà développé autour de cette solution des scripts fiables. De plus, les bibliothèques de règles pour chaque type d’applications nous semblaient bien plus matures chez Kasten », raconte Thomas Jouffroy.

Kasten utilise en l’occurrence la plateforme Open source Kanister, qui regroupe un large éventail de blueprints (règles de sauvegarde), notamment adaptés à tous les types de bases de données.

Un autre avantage constaté par Thomas Jouffroy et son équipe est la capacité de Kasten à restaurer des sauvegardes en changeant la configuration d’un cluster Kubernetes.

« Sopra Steria déploie des clusters de containers majoritairement basés sur OpenShift, le Kubernetes de Red Hat. En 2020 s’est posé le problème de migrer d’OpenShift 3 à OpenShift 4, une évolution tellement importante qu’il fallait refaire les scripts de déploiement de toutes les applications, les scripts YAML de la version précédente n’étant plus compatibles. Les réécrire à la main, pour 800 applications dans notre cas, s’annonçait douloureux. Heureusement, Kasten dispose d’une option pour les modifier à la volée lors de la restauration », témoigne l’ingénieur.

Il précise que le même dispositif, appelé Transform Sets, est aujourd’hui abondamment utilisé dans les applications des clients de Sopra Steria quand il est nécessaire d’anonymiser les données entre deux clusters.

« La migration d’OpenShift 3 à 4 n’est pas encore terminée dans toutes les entreprises. Dernièrement, nous avons en avons rencontré une qui y travaillait depuis deux ans pour convertir 80 applications. Nous lui avons proposé de travailler avec elle à la rédaction de Transform Sets adaptés à ses besoins, ce qui nous a pris environ un mois. Une fois cela fait, la bascule de toutes ses applications d’un cluster OpenShift 3 à un autre en OpenShift 4 n’a pris qu’une nuit », relate Thomas Jouffroy.

Les fonctions attendues

Pour la suite, Thomas Jouffroy imagine surtout rattraper le train des fonctions parues lors des dernières versions de Kasten. Quoiqu’attrayantes, celles-ci nécessitent un temps par ailleurs précieux pour être implémentées.

« Par exemple, jusqu’ici, nous installions un Kasten par cluster Kubernetes. Depuis la version 8 du logiciel, il est devenu possible d’avoir un Kasten qui pilote la sauvegarde de plusieurs clusters : une version centrale du logiciel se réplique sur chaque cluster et toutes les répliques sont pilotables depuis une seule console ou un seul jeu de commandes. »

« Si nous déployons désormais cette fonctionnalité sur tous les nouveaux clusters, nous n’avons pas encore eu l’opportunité de l’implémenter sur les déploiements précédents. Créer la configuration qui permet à un Kasten central de configurer les Kasten périphériques, mais aussi configurer les tableaux de bord pour un audit global prend plusieurs semaines », dit Thomas Jouffroy.

Une autre nouveauté que Sopra Steria n’a pas encore mise en œuvre est l’intégration de la console web de Kasten dans OpenShift. « Là encore, c’est une amélioration intéressante, mais comme tout ce que fait Kasten revient à un objet Kubernetes, le pilotage des sauvegardes relève plutôt de l’écriture de scripts qui déclenchent des actions. Et une console graphique n’est pas prioritaire pour cela. »

En revanche, Thomas Jouffroy tient à faire passer le message que d’autres fonctions seraient accueillies plus promptement.

« Il y a selon moi encore beaucoup de travail à faire pour augmenter le niveau de logs. Les développeurs de Kasten ont fait beaucoup d’efforts en ce sens, mais nous en voulons toujours plus. Également, il serait souhaitable que toutes les fonctionnalités de cybersurveillance, d’antivirus, de recherche de vulnérabilités qui existent dans Veeam soient portées sur Kasten. »

Aujourd’hui, ces dispositifs de sécurité sont mis en place par Sopra Steria à un niveau plus bas de l’infrastructure. L’ESN déploie ses clusters Kubernetes tantôt chez ses clients, tantôt chez OVHcloud, tantôt directement sur des serveurs physiques (notamment via l’offre SecNumCloud d’OVHcloud), tantôt par-dessus des machines virtuelles pilotées par VMware.

La mutualisation des ressources entre clients se fait au niveau de VMware, tandis que chaque cluster Kubernetes déployé par l’ESN est dédié à un seul client. D’où l’importance d’avoir des règles spécifiques de cybersécurité au niveau de chaque Kubernetes, plutôt qu’à celui des serveurs.