Les 9 meilleures solutions de sauvegarde et de restauration OpenShift ETCD

RedHat OpenShift permet aux utilisateurs de provisionner, d’instancier, d’exécuter et de gérer un ensemble modulaire comprenant une plateforme informatique et un certain nombre d’applications, ce qui réduit considérablement la complexité de la construction et de la maintenance de l’infrastructure qui serait probablement associée au développement et au lancement des applications et des services nécessaires.

OpenShift représente une approche spécifique de la manière dont les machines virtuelles, les conteneurs et les environnements de plateforme en tant que service peuvent fonctionner ensemble ; la plateforme dans son ensemble est souvent utile à la fois pour les entreprises et pour les personnes qui sont en mesure de les exploiter.

OpenShift étant une famille de logiciels, il est important de mentionner son produit phare, OpenShift Container Platform.

OpenShift Container Platform, ou OSCP, est une plateforme cloud hybride en tant que service qui fonctionne avec des conteneurs Linux gérés par Kubernetes. Le plus souvent, elle est désignée sous le nom d' »OpenShift », même s’il existe de nombreux autres produits au sein de cette même famille – notamment OpenShift Online, OpenShift Dedicated, et d’autres encore. Par souci de continuité, nous allons nous référer à OpenShift Container Platform simplement comme « OpenShift » pour le reste de cet article, parce que la majorité des services et solutions suivants fonctionnent avec OSCP.

OpenShift est conçu pour être modulaire et flexible, ce qui apporte un certain nombre d’avantages aux différents déploiements qui utilisent OpenShift. Cependant, cette approche flexible et polyvalente a ses propres inconvénients. Le premier problème est que cette approche, bien qu’elle puisse être très efficace, peut également être sujette à des erreurs et à des défaillances. En tant que tel, un bon système de sauvegarde est une exigence pour la plupart, sinon la totalité, des déploiements OpenShift, en particulier lorsque des données précieuses et persistantes sont créées et / ou traitées….

La nécessité d’un système de sauvegarde crée un autre problème important pour les déploiements OpenShift – toutes les solutions de sauvegarde ne sont pas capables de protéger adéquatement les environnements OpenShift – et certaines sont tout simplement incapables de le faire du tout.

En tant que tel, une solution de sauvegarde et de restauration devrait être entièrement compatible avec OpenShift en premier lieu. Généralement, les fonctionnalités de sauvegarde telles que l’automatisation des sauvegardes, la prise en charge de différents emplacements et supports de sauvegarde, et les capacités de migration des données constituent un ajout important à la capacité de sauvegarde et de restauration existante d’OpenShift.

Capacités de sauvegarde OpenShift intégrées

Il n’y a pas tant de solutions de sauvegarde complètes sur le marché qui sont également capables d’effectuer des opérations de sauvegarde et de restauration OpenShift – mais d’abord, nous devons examiner tout ce que RedHat lui-même peut faire. Cette fonctionnalité de sauvegarde intégrée est ce que nous allons développer en premier.

Sauvegarde et restauration de cluster OpenShift

Deux voies possibles existent ici – les opérations de sauvegarde et de récupération pour les clusters et ces mêmes opérations pour les applications. Les opérations de sauvegarde des clusters reposent entièrement sur les données etcd – un magasin clé-valeur d’OSCP (OpenShift Container Platform) qui contient des informations sur tous les objets de ressources au sein d’un cluster.

Un administrateur de cluster peut être amené à arrêter ou redémarrer des clusters dans des situations spécifiques, que ce soit à des fins de maintenance ou simplement pour économiser des ressources en faisant fonctionner moins de clusters à la fois. Le processus d’arrêt d’un cluster OpenShift est parfois appelé « graceful shutdown », et il comprend l’arrêt des nœuds du cluster avec une commande d’arrêt dédiée, ainsi que l’arrêt de toutes les dépendances qui ne sont plus utilisées avec l’arrêt du cluster.

Il existe également un autre processus appelé « redémarrage gracieux », qui est naturellement l’opposé direct d’un arrêt gracieux puisqu’il démarre le cluster au lieu de l’arrêter. Ce processus particulier, cependant, peut être un peu plus compliqué que son opposé, avec des étapes telles que :

• Réactiver toutes les dépendances du cluster précédemment désactivées ;
• Démarrer la machine cluster elle-même ;
• Vérifier si les nœuds du plan de contrôle sont prêts ;
• Vérifier si les nœuds de travailleur sont prêts ;
• Vérifier si le cluster dans son ensemble a démarré correctement ou non.

Si le cluster ne démarrait pas correctement, la seule solution serait d’utiliser une sauvegarde etcd pour restaurer l’état précédent du cluster.

S’il est vrai que l’arrêt gracieux doit permettre de redémarrer le cluster avec un minimum d’effort, une sauvegarde etcd doit être effectuée avant chaque événement d’arrêt du cluster. Les sauvegardes etcd jouent un rôle important dans les scénarios de reprise après sinistre, et il ne serait pas possible de restaurer un OSCP défectueux sans une sauvegarde etcd impliquée dans le processus.

Le processus de sauvegarde etcd lui-même est assez simple et comprend trois étapes principales – le démarrage d’une session de débogage, le changement de votre répertoire racine en /host, et le lancement d’un script appelé « cluster-backup.sh » tout en saisissant l’emplacement de la sauvegarde.

Le processus de restauration de cluster, d’autre part, est un peu plus compliqué, principalement parce que les restaurations de cluster via la sauvegarde etcd sont considérées comme une « option de dernier recours » qui ne devrait normalement être utilisée que lorsque rien d’autre ne fonctionne pour récupérer l’état de fonctionnement du cluster. Elle implique plusieurs étapes, telles que :

• Sélectionner un hôte du plan de contrôle qui va effectuer les opérations de restauration ;
• Configuration de la connectivité SSH avec tous les nœuds du plan de contrôle, y compris celui qui sera utilisé pour la restauration ;
• Copie manuelle de la sauvegarde etcd sur l’hôte choisi pour la récupération ;
• Accéder à l’hôte en question ;
• Exécution du script de restauration « cluster-restore.sh » ;
• Vérifier si les nœuds sont dans l’état « prêt » ;
• Redémarrage du service kubelet pour tous les hôtes du plan de contrôle, y compris celui de récupération ;
• Approuver les CSR en attente, vérifier si le plan de contrôle à membre unique est opérationnel ;
• Suppression et recréation de toutes les machines du plan de contrôle, à l’exclusion de celle choisie à des fins de récupération.

Ceci nous amène à la deuxième partie de ce long processus – il commence avec le même utilisateur se connectant dans une fenêtre de terminal séparée avec le rôle « cluster-admin« . Les opérations suivantes sont effectuées :

• Forcer le redéploiement de etcd ;
• Vérifier si les nœuds sont à jour ;
• Forcer de nouveaux déploiements vers le plan de contrôle (cela devrait réinstaller Kubernetes API sur tous les nœuds puisqu’un équilibreur de charge interne est utilisé pour connecter le kubelet au serveur API) ;
• Et enfin, mais pas des moindres, vérifiez que tous les hôtes du plan de contrôle nouvellement installés fonctionnent et rejoignent le cluster.

Il est facile de voir comment le processus de restauration de la sauvegarde etcd est plutôt long et difficile, ce qui est l’une des raisons pour lesquelles il est traité comme une option de dernier recours.

Maintenant que nous avons couvert le fonctionnement de la sauvegarde et de la restauration des conteneurs, examinons le processus de sauvegarde et de restauration des applications.

Sauvegarde et récupération des applications OpenShift

Le processus de création de sauvegardes d’applications dans OpenShift peut également être assez compliqué, mais nous n’allons pas l’approfondir particulièrement, car les principaux points d’intérêt de cet article sont etcd et les clusters. Cependant, nous allons tout de même en examiner la logique.

Les opérations de sauvegarde et de restauration des applications au sein d’OpenShift peuvent être effectuées à l’aide d’OADP, ou OpenShift API for Data Protection. Elle utilise Velero pour effectuer à la fois des tâches de sauvegarde et de restauration soit pour des ressources et/ou des images internes, tout en étant capable de travailler avec des volumes persistants via Restic ou avec des snapshots.

Il existe une liste très spécifique de variantes de stockage qui peuvent être sauvegardées avec OADP – cette liste comprend MS Azure, AWS, GCP, Multicloud Object Gateway, ainsi que plusieurs variantes de stockage d’objets compatibles S3 (Minio, Noobaa, etc.). Parallèlement, les sauvegardes par instantané ne peuvent être effectuées que pour AWS, Azure, GCP et le stockage en nuage compatible avec les instantanés CSI (Ceph FS, Ceph RBD, etc.), car seuls ces derniers prennent en charge l’API d’instantané de niveau natif nécessaire.

Le processus de sauvegarde lui-même implique la création d’une CR, ou ressource personnalisée, à des fins de sauvegarde ou de restauration. Cette option peut être utilisée pour effectuer des sauvegardes Restic, des sauvegardes planifiées et pour configurer des crochets de sauvegarde/restauration à exécuter avant ou après la fin du processus de sauvegarde/restauration.

Options de sauvegarde OpenShift tierces

Bien que la méthode de sauvegarde/restauration mentionnée précédemment soit effectivement possible, elle comporte des problèmes potentiels associés, principalement parce qu’elle manque de fonctionnalités supplémentaires et peut être quelque peu compliquée pour un grand nombre d’utilisateurs. C’est pourquoi nous allons également passer en revue les solutions de sauvegarde OpenShift ETCD tierces, en commençant par IBM Spectrum.

IBM Spectrum Protect Plus

IBM Spectrum Protect Plus est une solution complète de protection des données qui offre une variété de fonctionnalités dans le domaine de la sécurité des données – y compris la sauvegarde, la récupération, la rétention et la réplication pour toutes sortes d’emplacements cibles, qu’il s’agisse de bases de données, d’applications, de machines virtuelles, de charges de travail SaaS ou même de conteneurs.

IBM Spectrum Protect est une solution assez polyvalente, c’est pourquoi elle peut également fonctionner avec les systèmes OpenShift. La solution d’IBM est capable de protéger non seulement les volumes persistants, mais aussi d’autres ressources dépendantes des clusters OpenShift. Bien qu’elle ait un ensemble d’exigences pour que les sauvegardes OpenShift fonctionnent en premier lieu, les exigences elles-mêmes ne sont pas particulièrement strictes et comprennent principalement une seule exigence pour les différentes parties du système de virtualisation d’être à jour à un degré spécifique.

IBM Spectrum Protect permet à ses utilisateurs d’enregistrer manuellement les clusters OpenShift, de créer des sauvegardes des données des conteneurs OpenShift et de les restaurer soit à partir d’un snapshot, soit à partir d’une copie de sauvegarde régulière, et il peut également restaurer des ressources spécifiques à l’espace de noms et au cluster ou même remplacer les paramètres de rétention pour des sauvegardes ou des snapshots spécifiques en expirant les sessions de travail de sauvegarde d’OpenShift.

CronJob

Contrairement au reste de cette liste, CronJob n’est pas exactement une solution de sauvegarde en soi. Un CronJob est une tâche qui peut effectuer des actions spécifiques suivant un calendrier spécifique dans les systèmes basés sur Unix. Dans ce contexte particulier, un utilisateur sur GitHub utilise CronJob pour effectuer une série d’opérations qui aboutissent à la création d’une sauvegarde OpenShift avec la même méthode que celle que nous avons mentionnée précédemment (exécution de cluster-backup.sh).

Ce CronJob spécifique crée un pod qui exécute le script susmentionné pour créer la sauvegarde elle-même. Il copie également l’ensemble de la sauvegarde sur un PV préconfiguré, puis expire le travail de sauvegarde lui-même pour éviter les conflits futurs. Il crée deux fichiers distincts – l’un étant la collection des pods statiques dans leur ensemble avec leurs clés privées et leurs certificats, et l’autre étant l’instantané etcd. En tant que telle, cette « méthode » particulière peut être surnommée une solution de sauvegarde OpenShift ETCD.

Kasten K10

Kasten K10 est une plateforme de gestion de données native du cloud en tant que type de stockage, offrant une variété d’options différentes telles que la sauvegarde, la récupération, la mobilité des applications et la reprise après sinistre aux applications Kubernetes, tout en étant capable d’intégrer une variété de types de bases de données différentes, de prendre en charge plusieurs fournisseurs de stockage cloud et de fonctionner avec la plupart des distributions Kubernetes.

K10 peut également effectuer des opérations de sauvegarde et de récupération OpenShift avec une relative simplicité. La plus grande différence ici serait la création d’un Secret – la propre version de Kasten d’une liste de sauvegarde qui comprend des informations sur les étiquettes de pods etcd, le point de terminaison du cluster etcd et tout ce qui doit être sauvegardé. En dehors de cela, leur processus est quelque peu similaire à la façon dont K10 effectue habituellement des sauvegardes – création d’un Blueprint et utilisation d’un Secret avec un Blueprint pour exécuter la tâche de sauvegarde. Le processus de restauration, quant à lui, est similaire à ce que nous avons abordé dans la section « méthodes intégrées » de cet article.

Storware Backup and Recovery

Storware Backup and Recovery est un logiciel de protection des données cloud-native qui fonctionne extrêmement bien lorsqu’il s’agit de créer des sauvegardes de volumes persistants ou de métadonnées attachées à des pods OpenShift. Il a un statut d’opérateur Red Hat OpenShift certifié, offrant une cohérence dans ses efforts de protection des données, associée à des fonctionnalités telles que la planification, la modification des politiques de sauvegarde, l’automatisation des sauvegardes, etc. C’est une excellente solution de sauvegarde et de restauration OpenShift ETCD qui couvre plusieurs plans différents des données d’OpenShift – le etcd susmentionné, les métadonnées, les volumes persistants, et plus encore.

Portworx Backup

Portworx est une plateforme de services de données qui se concentre sur le développement de solutions pour les utilisateurs de Kubernetes afin de faciliter l’exécution d’applications dans des conteneurs sans interruptions et événements de perte de données. Elle offre un accès plus facile aux sauvegardes d’applications avec une cohérence et de multiples fonctionnalités, telles que la planification des sauvegardes, le RBAC, la gestion des utilisateurs, et plus encore. Portworx peut également offrir des capacités de reprise après sinistre, la mise en œuvre de CSI, le chiffrement à l’échelle du cluster, des instantanés, ainsi que de nombreuses autres fonctionnalités pour les clusters et les applications OpenShift.

Cloudcasa

Cloudcasa est un service de sauvegarde résilient et puissant, doté d’une grande évolutivité et d’une interface conviviale. Il peut offrir une protection des données multi-cloud, plusieurs options de cyber-résilience et plusieurs types de sauvegarde au sein de vos environnements OpenShift (ressources Kubernetes, sauvegardes etcd et snapshots CSI). Cloudcasa peut également effectuer plusieurs niveaux différents d’opérations de récupération, que ce soit au niveau granulaire ou au niveau du cluster, ce qui en fait une solution de sauvegarde et de restauration OpenShift ETCD plutôt pratique et utile.

Dell EMC PowerProtect Data Manager

Dell EMC est une puissance technologique qui offre une variété de produits et de services pour de nombreux marchés différents. PowerProtect Data Manager de Dell EMC est une solution de protection des données polyvalente qui prend en charge plusieurs types d’environnement et peut fonctionner avec une multitude d’emplacements de stockage différents. Elle prend également en charge les environnements OpenShift, offrant une protection pour ses charges de travail, tout en étant une solution de sauvegarde et de restauration fiable et utile. Il intègre les environnements d’OpenShift dans sa propre interface centralisée, offrant la possibilité d’attribuer des politiques de protection aux espaces de noms, aux clusters et à tout ce que possède OpenShift.

Bacula Enterprise

Bacula Enterprise est une solution de sauvegarde d’entreprise unique et hautement sécurisée qui prend en charge un éventail particulièrement large d’environnements et de fonctionnalités grâce à son système de « modules ». L’un de ces modules a été créé spécifiquement pour les opérations complètes de sauvegarde et de restauration OpenShift, offrant une variété de fonctionnalités de protection des données aux environnements OpenShift. Ce module particulier offre des fonctionnalités telles que la sauvegarde de l’état du cluster, le redéploiement efficace des ressources du cluster, les capacités de récupération des applications, la restauration ciblée des données PV, le transfert de configuration pour d’autres opérations, et ainsi de suite. Non seulement Bacula Enterprise peut être utile pour sauvegarder vos données OpenShift dans leur ensemble, mais il peut également faciliter les plans de reprise après sinistre, offrir une sécurité supplémentaire à vos données, aider avec les tâches de migration de cluster, offrir des capacités de réplication d’environnement, et bien plus encore. Il convient de noter que son modèle de licence par abonnement et sa grande évolutivité le rendent avantageux pour les déploiements de moyenne et grande envergure.

Conclusion

Les environnements OpenShift sont extrêmement utiles dans des domaines et des secteurs d’application spécifiques, mais ils sont aussi relativement nouveaux, ce qui signifie que la sauvegarde des données qui s’y trouvent peut être quelque peu problématique. Étant donné que les environnements Kubernetes de tout type sont de plus en plus déployés, la sauvegarde de leurs données – en particulier leurs données persistantes – est de plus en plus importante. Cet article aborde différentes solutions de sauvegarde OpenShift, y compris les options intégrées et tierces qui sont disponibles, et peut être utile pour trouver une solution pour un cas d’utilisation spécifique de l’utilisateur.