Le paysage du cloud natif évolue rapidement : on estime en effet que 85 % des entreprises mondiales utiliseront des conteneurs en production d’ici 2025¹. Pour continuer à atteindre vos objectifs métier tout en renforçant votre agilité et en rationalisant vos opérations, vous avez besoin d’une solution de gestion des données globale et complète couvrant l’ensemble de votre parc de données.
Commvault a toujours été à l’avant-garde en matière de protection des nouvelles technologies, et les conteneurs et Kubernetes ne font pas exception. Nous avons mis en place une prise en charge étendue pour protéger les applications s’exécutant sur un cluster Kubernetes ainsi que leurs données. Toutes les distributions Kubernetes certifiées par la CNCF (Cloud Native Computing Foundation) sont prises en charge, et grâce au framework CSI (Container Storage Interface), nous prenons également en charge un large éventail de fournisseurs de stockage sur Kubernetes, vous garantissant ainsi une protection complète des données cloud natives, gérée de manière simple via une solution unique de gestion des données.
Dans cette nouvelle version, nous ajoutons deux nouvelles fonctionnalités clés à la protection des données Kubernetes :
- Protection complète au niveau du cluster et de l’espace de noms.
- Protection de l’ETCD.
Récapitulatif
Commvault permet aux utilisateurs d’intégrer facilement un cluster Kubernetes dans le Commvault Command Center™, qui constitue le point de contrôle unique pour tous vos besoins en matière de protection, de gestion et de cycle de vie des données.
Commvault définit une application Kubernetes comme tout élément constituant un pod ou un ensemble de pods, à savoir : les Deployments, les ReplicaSets, les StatefulSets, etc., ainsi que leurs composants associés, tels qu’ils sont déduits de leurs fichiers YAML d’application.
Pour expliquer cela plus en détail, lorsque nous examinons une application telle qu’un déploiement, nous analysons sa spécification de configuration et identifions les PVC (Persistent Volume Claims), les secrets, les ConfigMaps et les autres entités associées. L’ensemble de ces éléments constitue une application.
Un utilisateur peut parcourir les applications d’un cluster intégré, les sélectionner et les regrouper au sein d’un « groupe d’applications » en fonction des SLA (accords de niveau de service) de sauvegarde, des besoins en matière de conservation ou de tout autre critère.
Les utilisateurs peuvent ajouter des applications à des groupes d’applications de plusieurs façons différentes :
- Parcourez et sélectionnez toutes les applications d’un ou de plusieurs espaces de noms.
- Sélectionnez des applications spécifiques.
- Utilisez des règles de détection dynamiques : par exemple, sélectionnez les applications correspondant à un sélecteur de balise ou à un nom spécifique, etc.
La découverte dynamique s’avère particulièrement utile lorsque l’administrateur de sauvegarde peut demander aux équipes DevOps de définir des sélecteurs d’étiquettes sur leurs applications et bénéficier ainsi de la garantie de SLA (accords de niveau de service) spécifiques en matière de protection.
Les tâches de sauvegarde s’exécutent au niveau du groupe d’applications et utilisent les règles de contenu pour détecter, au moment de l’exécution, les applications existantes et nouvellement créées ainsi que leurs ressources sur le cluster, puis pour effectuer les sauvegardes. Les PVC sont sauvegardés à l’aide de CSI lorsque celui-ci est disponible ; à défaut, Commvault peut se connecter directement aux PVC en utilisant la sémantique « ReadMany » si CSI n’est pas disponible.
Un schéma illustrant le déroulement du processus.
Avec Commvault, la restauration d’une application ou de ses données peut s’effectuer à différents niveaux de granularité :
- Restauration au niveau de l’application : une application dans son intégralité, ainsi que les ressources et les données qui lui sont associées, peut être restaurée en une seule opération.
- Fichiers d’application : les données d’une application (ou certaines parties de celles-ci) stockées sur des PVC peuvent être restaurées de manière sélective, sans qu’il soit nécessaire de restaurer l’application dans son intégralité.
- Fichiers de configuration des applications : les fichiers de configuration qui composent une application peuvent être restaurés sous forme de fichiers, ce qui permet à l’utilisateur de les modifier avant de les appliquer au cluster.
Améliorations
Il est désormais temps de vous présenter les nouvelles fonctionnalités passionnantes, qui assurent une protection complète de Kubernetes et sont incluses dans la version 2022E de la plateforme.
1. Protection complète du cluster
Avec cette fonctionnalité, nous avons ajouté un bouton pratique sur lequel l’administrateur des sauvegardes n’aura qu’à cliquer : « Sauvegardez tout ce qui se trouve sur le cluster, s’il vous plaît. Merci beaucoup ! »
Lorsque la configuration est définie de cette manière, tous les éléments du cluster, y compris les ressources au niveau du cluster, sont pris en compte.
De plus, les espaces de noms récemment détectés au moment de la sauvegarde sont également inclus automatiquement.
Les administrateurs de sauvegarde n’ont plus besoin de sélectionner individuellement les espaces de noms ou les applications au sein d’un espace de noms pour qu’ils soient entièrement protégés.
2. Protection au niveau de l’espace de noms
Outre un cluster entier, les utilisateurs peuvent désormais choisir de sauvegarder un espace de noms complet, c’est-à-dire les applications (et leurs ressources) ainsi que toutes les ressources non référencées au sein de cet espace de noms (que nous appelons « orphelines »).
De plus, les utilisateurs peuvent désormais restaurer des espaces de noms dans leur intégralité, tout en conservant les différentes options de restauration granulaire décrites ci-dessus.
3. Protection de l’etcd.
etcd est une base de données distribuée et répliquée que Kubernetes utilise pour stocker la configuration du cluster. L’image ci-dessous illustre l’utilisation d’etcd dans un cluster Kubernetes type.
Chaque nœud du plan de contrôle dispose d’une réplique/copie d’etcd.
La perte ou la corruption de ces copies peut gâcher la journée (voire la semaine) d’un administrateur Kubernetes.
Étant donné qu’etcd est répliqué sur l’ensemble des nœuds maîtres d’un cluster Kubernetes, les solutions traditionnelles tentent de protéger etcd en protégeant ces nœuds maîtres. Cela passe souvent par le déploiement de solutions sur ces nœuds du cluster afin de protéger etcd localement. Cette approche est, au mieux, peu pratique et fastidieuse, car elle sépare la protection des applications s’exécutant sur le cluster et celle de l’état du cluster en deux mécanismes très distincts. La protection de l’état des applications et celle de l’état du cluster vont de pair, et les séparer peut entraîner des incohérences, notamment lors de la reprise après sinistre.
Commvault intègre désormais de manière transparente la protection d’etcd au sein du Command Center, aux côtés de la protection des applications et de celle de l’ensemble du cluster. Il suffit à l’utilisateur d’activer un commutateur sur le cluster pour protéger etcd et de sélectionner un SLA. C’est tout ! Vraiment ! (Voir la capture d’écran ci-dessous)
Grâce à ces améliorations, nous avons mis au point une solution globale et complète répondant à vos besoins en matière de protection des données Kubernetes, et nous l’avons intégrée à notre Commvault Command Center afin que vous puissiez simplifier la gestion de l’ensemble de votre parc de données à partir d’une interface unique. Il n’est donc pas étonnant que Commvault continue de se démarquer dans ce domaine.
Référence
1 – Forbes – Guide de la surveillance des conteneurs à l’intention des dirigeants (CxO)
