Sauvegarde et restauration
Sauvegarde et restauration de votre Red Hat OpenShift Service sur AWS cluster
Résumé
Chapitre 1. La sauvegarde et la restauration de l’application OADP
1.1. Introduction à {oadp-full}
Le produit OpenShift API for Data Protection (OADP) protège les applications client sur Red Hat OpenShift Service sur AWS. Il offre une protection complète contre la reprise après sinistre, couvrant le service Red Hat OpenShift sur les applications AWS, les ressources de cluster liées aux applications, les volumes persistants et les images internes. L’OADP est également capable de sauvegarder les applications conteneurisées et les machines virtuelles (VM).
Le support OADP est fourni aux espaces de noms de la charge de travail des clients et aux ressources de portée de cluster.
La sauvegarde et la restauration du cluster complet ne sont pas prises en charge.
1.1.1. API OpenShift pour les API de protection des données
L’API OpenShift pour la protection des données (OADP) fournit des API qui permettent de multiples approches pour personnaliser les sauvegardes et empêcher l’inclusion de ressources inutiles ou inappropriées.
L’OADP fournit les API suivantes:
1.1.1.1. Assistance pour OpenShift API pour la protection des données
La version | La version OCP | Disponibilité générale | Fin du support complet | Fin de l’entretien | Appui à la mise à jour étendue (EUS) | Extension du support de mise à jour Term 2 (EUS Term 2) |
1.4 |
| 10 juil 2024 | Libération de 1,5 | Libération de 1.6 | 27 juin 2026 L’EUS doit être sur OCP 4.16 | 27 juin 2027 La clause 2 de l’EUS doit être sur OCP 4.16 |
1.3 |
| 29 nov 2023 | 10 juil 2024 | Libération de 1,5 | 31 oct 2025 L’EUS doit être sur OCP 4.14 | 31 oct 2026 La clause 2 de l’EUS doit être sur OCP 4.14 |
1.1.1.1.1. Les versions non prises en charge de l’opérateur OADP
La version | Disponibilité générale | Le soutien complet a pris fin | Fin de la maintenance |
1.2 | 14 juin 2023 | 29 nov 2023 | 10 juil 2024 |
1.1 | 01 septembre 2022 | 14 juin 2023 | 29 nov 2023 |
1.0 | 09 fév 2022 | 01 septembre 2022 | 14 juin 2023 |
En savoir plus sur EUS, consultez le support de mise à jour étendue.
En savoir plus sur la clause 2 de l’EUS, voir Extended Update Support Term 2.
1.2. Les notes de sortie de l’OADP
1.2.1. Les notes de sortie de OADP 1.4
Les notes de publication de l’API OpenShift pour la protection des données (OADP) décrivent de nouvelles fonctionnalités et améliorations, des fonctionnalités dépréciées, des recommandations de produits, des problèmes connus et des problèmes résolus.
En savoir plus sur OADP, consultez la FAQ OpenShift API for Data Protection (OADP)
1.2.1.1. 1.4.3 notes de publication OADP
L’API OpenShift pour la protection des données (OADP) 1.4.3 répertorie la nouvelle fonctionnalité suivante.
1.2.1.1.1. De nouvelles fonctionnalités
Changements notables dans le plugin kubevirt velero dans la version 0.7.1
Avec cette version, le plugin kubevirt velero a été mis à jour à la version 0.7.1. Les améliorations notables incluent les corrections de bogues suivantes et les nouvelles fonctionnalités:
- Les instances de machine virtuelle (IMV) ne sont plus ignorées de la sauvegarde lorsque le VM propriétaire est exclu.
- Les graphiques d’objets incluent désormais tous les objets supplémentaires lors des opérations de sauvegarde et de restauration.
- Les étiquettes générées en option sont désormais ajoutées aux nouveaux identifiants universellement uniques (UUID) lors des opérations de restauration.
- Changer de stratégie d’exécution de VM lors des opérations de restauration est maintenant possible.
- Effacer une adresse MAC par étiquette est maintenant pris en charge.
- Les vérifications spécifiques à la restauration au cours de l’opération de sauvegarde sont maintenant ignorées.
- Les définitions de ressources personnalisées VirtualMachineClusterInstancetype et VirtualMachineClusterPreference (CRD) sont maintenant prises en charge.
1.2.1.2. 1.4.2 notes de publication
L’API OpenShift pour la protection des données (OADP) 1.4.2 répertorie les nouvelles fonctionnalités, les problèmes et les bogues résolus et les problèmes connus.
1.2.1.2.1. De nouvelles fonctionnalités
La sauvegarde de différents volumes dans le même espace de noms en utilisant la fonction VolumePolicy est maintenant possible
Avec cette version, Velero fournit des stratégies de ressources pour sauvegarder différents volumes dans le même espace de noms en utilisant la fonctionnalité VolumePolicy. La fonction VolumePolicy prise en charge pour sauvegarder différents volumes comprend des actions de skip, snapshot et fs-backup. À PROPOS DE OADP-1071
La sauvegarde du système de fichiers et le déplacement de données peuvent maintenant utiliser des informations d’identification à court terme
La sauvegarde du système de fichiers et le déplacement de données peuvent désormais utiliser des informations d’identification à court terme telles que AWS Security Token Service (STS) et GCP WIF. Avec ce support, la sauvegarde est terminée avec succès sans aucun statut PartiallyFailed. À PROPOS DE OADP-5095
1.2.1.2.2. Des problèmes résolus
DPA signale maintenant des erreurs si VSL contient une valeur de fournisseur incorrecte
Auparavant, si le fournisseur d’une spécification d’emplacement des prises de vue de volume (VSL) était incorrect, l’application de protection des données (DPA) s’est réconciliée avec succès. Avec cette mise à jour, DPA signale les erreurs et les demandes d’une valeur fournisseur valide. À PROPOS DE OADP-5044
La restauration de data Mover réussit indépendamment de l’utilisation de différents espaces de noms OADP pour la sauvegarde et la restauration
Auparavant, lorsque l’opération de sauvegarde a été exécutée en utilisant OADP installé dans un espace de noms, mais a été restauré en utilisant OADP installé dans un espace de noms différent, la restauration de Data Mover a échoué. Avec cette mise à jour, la restauration de Data Mover est maintenant réussie. À PROPOS DE OADP-5460
La sauvegarde SSE-C fonctionne avec le MD5 calculé de la clé secrète
Auparavant, la sauvegarde a échoué avec l’erreur suivante:
Requests specifying Server Side Encryption with Customer provided keys must provide the client calculated MD5 of the secret key.
Requests specifying Server Side Encryption with Customer provided keys must provide the client calculated MD5 of the secret key.
Avec cette mise à jour, le chiffrement de chiffrement de serveur manquant avec les clés fournies par le client (SSE-C) base64 et MD5 hachage sont maintenant corrigés. En conséquence, la sauvegarde SSE-C fonctionne avec le MD5 calculé de la clé secrète. En outre, une mauvaise gestion des erreurs pour la taille de la clé client est également corrigée. À PROPOS DE OADP-5388
En ce qui concerne la liste complète de tous les problèmes résolus dans cette version, consultez la liste des problèmes résolus dans Jira.
1.2.1.2.3. Problèmes connus
La spécification nodeSelector n’est pas prise en charge pour l’action de restauration de Data Mover
Lorsqu’une application de protection des données (DPA) est créée avec le champ nodeSelector défini dans le paramètre nodeAgent, la restauration de Data Mover échoue partiellement au lieu de terminer l’opération de restauration. À PROPOS DE OADP-5260
Le stockage S3 n’utilise pas d’environnement proxy lorsque la vérification TLS est spécifiée
Dans la sauvegarde du registre d’images, le stockage S3 n’utilise pas l’environnement proxy lorsque le paramètre insecureSkipTLSVerify est défini sur true. À PROPOS DE OADP-3143
Kopia ne supprime pas les artefacts après l’expiration de la sauvegarde
Dès que vous avez supprimé une sauvegarde, Kopia ne supprime pas les artefacts de volume du ${bucket_name}/kopia/$openshift-adp sur l’emplacement S3 après l’expiration de la sauvegarde. En savoir plus, voir « À propos de la maintenance du référentiel Kopia ». À PROPOS DE OADP-5131
1.2.1.3. 1.4.1 notes de publication OADP 1.4.1
L’API OpenShift pour la protection des données (OADP) 1.4.1 répertorie les nouvelles fonctionnalités, les problèmes et les bogues résolus et les problèmes connus.
1.2.1.3.1. De nouvelles fonctionnalités
De nouveaux champs DPA pour mettre à jour les qps et l’éclatement du client
Désormais, vous pouvez modifier les requêtes API Velero Server Kubernetes par seconde et les valeurs d’éclatement à l’aide des nouveaux champs d’application de protection des données (DPA). Les nouveaux champs DPA sont spec.configuration.velero.client-qps et spec.configuration.velero.client-burst, qui par défaut à 100. À PROPOS DE OADP-4076
Activer les algorithmes non par défaut avec Kopia
Avec cette mise à jour, vous pouvez maintenant configurer les algorithmes de hachage, de chiffrement et de fractionneur dans Kopia pour sélectionner des options non par défaut afin d’optimiser les performances pour différentes charges de travail de sauvegarde.
Afin de configurer ces algorithmes, définissez la variable env d’un pod velero dans la section podConfig de la configuration DataProtectionApplication (DPA). Lorsque cette variable n’est pas définie ou qu’un algorithme non pris en charge est choisi, Kopia par défaut à ses algorithmes standard. À PROPOS DE OADP-4640
1.2.1.3.2. Des problèmes résolus
La restauration d’une sauvegarde sans pods est maintenant réussie
Auparavant, restaurer une sauvegarde sans pods et avoir StorageClass VolumeBindingMode défini comme WaitForFirstConsumer, a abouti à l’état PartiallyFailed avec une erreur: ne pas corriger PV dynamique, erreur: la date limite de contexte dépassée. Avec cette mise à jour, le patching dynamique PV est ignoré et la restauration d’une sauvegarde est réussie sans aucun statut PartiallyFailed. À PROPOS DE OADP-4231
Le PodVolumeBackup CR affiche maintenant le message correct
Auparavant, la ressource personnalisée PodVolumeBackup (CR) a généré un message incorrect, qui était: obtenir un podvolumebackup avec le statut "InProgress" pendant le démarrage du serveur, le marquer comme "Failed". Avec cette mise à jour, le message produit est maintenant:
found a podvolumebackup with status "InProgress" during the server starting, mark it as "Failed".
found a podvolumebackup with status "InProgress" during the server starting,
mark it as "Failed".
Image dominantePullPolicy est maintenant possible avec DPA
Auparavant, OADP a défini le paramètre imagePullPolicy sur Toujours pour toutes les images. Avec cette mise à jour, OADP vérifie si chaque image contient sha256 ou sha512 digest, puis il définit imagePullPolicy sur IfNotPresent; sinon imagePullPolicy est définie sur Always. Désormais, vous pouvez remplacer cette politique en utilisant le nouveau champ DPA spec.containerImagePullPolicy. À PROPOS DE OADP-4172
L’OADP Velero peut maintenant réessayer la mise à jour de l’état de restauration si la mise à jour initiale échoue
Auparavant, OADP Velero n’a pas réussi à mettre à jour l’état CR restauré. Cela a laissé le statut à InProgress indéfiniment. Les composants qui se sont appuyés sur la sauvegarde et restaurer l’état CR pour déterminer l’achèvement échoueraient. Avec cette mise à jour, l’état de restauration CR pour une restauration procède correctement à l’état terminé ou échoué. À PROPOS DE OADP-3227
La restauration de BuildConfig Build à partir d’un cluster différent est réussie sans aucune erreur
Auparavant, lors de la restauration de la ressource BuildConfig Build à partir d’un cluster différent, l’application a généré une erreur sur la vérification TLS dans le registre d’images interne. L’erreur résultante n’a pas permis de vérifier le certificat: x509: certificat signé par une erreur d’autorité inconnue. Avec cette mise à jour, la restauration des ressources de construction BuildConfig vers un cluster différent peut se dérouler avec succès sans générer l’erreur de vérification du certificat manquée. À PROPOS DE OADP-4692
La restauration d’un PVC vide est un succès
Auparavant, le téléchargement des données a échoué lors de la restauration d’une revendication de volume persistant vide (PVC). Il a échoué avec l’erreur suivante:
data path restore failed: Failed to run kopia restore: Unable to load snapshot : snapshot not found
data path restore failed: Failed to run kopia restore: Unable to load
snapshot : snapshot not found
Avec cette mise à jour, le téléchargement des données permet de corriger la conclusion lors de la restauration d’un PVC vide et le message d’erreur n’est pas généré. À PROPOS DE OADP-3106
Il n’y a pas de fuite de mémoire Velero dans les plugins CSI et DataMover
Auparavant, une fuite de mémoire Velero était causée par l’utilisation des plugins CSI et DataMover. Lorsque la sauvegarde a pris fin, l’instance du plugin Velero n’a pas été supprimée et la fuite de mémoire consommée de la mémoire jusqu’à ce qu’une condition de sortie de mémoire (OOM) soit générée dans le pod Velero. Avec cette mise à jour, il n’y a pas de fuite de mémoire Velero résultante lors de l’utilisation des plugins CSI et DataMover. À PROPOS DE OADP-4448
L’opération post-hook ne commence pas avant que les PV associés ne soient libérés
Auparavant, en raison de la nature asynchrone de l’opération Data Mover, un post-hook pourrait être tenté avant que la revendication de volume persistant (PVC) de Data Mover ne libère les volumes persistants (PVs) des gousses associées. Ce problème entraînerait l’échec de la sauvegarde avec un statut PartiallyFailed. Avec cette mise à jour, l’opération post-hook n’est pas commencée avant que les PV associés soient libérés par le Data Mover PVC, éliminant ainsi l’état de sauvegarde PartiallyFailed. L’OADP-3140
Déployer un DPA fonctionne comme prévu dans les espaces de noms avec plus de 37 caractères
Lorsque vous installez l’opérateur OADP dans un espace de noms avec plus de 37 caractères pour créer un nouveau DPA, l’étiquetage « Cloud-credentials » Secret échoue et le DPA signale l’erreur suivante:
The generated label name is too long.
The generated label name is too long.
Avec cette mise à jour, la création d’un DPA ne échoue pas dans les espaces de noms avec plus de 37 caractères dans le nom. À PROPOS DE OADP-3960
La restauration est terminée avec succès en surmontant l’erreur de délai d’expiration
Auparavant, dans un environnement à grande échelle, l’opération de restauration se traduirait par un statut partiellement échoué avec l’erreur: ne pas corriger le PV dynamique, erreur: délai de contexte dépassé. Avec cette mise à jour, l’argument du serveur ResourceTimeout Velero est utilisé pour remplacer cette erreur de temps d’attente résultant d’une restauration réussie. À PROPOS DE OADP-4344
En ce qui concerne la liste complète de tous les problèmes résolus dans cette version, consultez la liste des problèmes résolus dans Jira.
1.2.1.3.3. Problèmes connus
Les pods d’application Cassandra entrent dans le statut CrashLoopBackoff après avoir restauré OADP
Après les restaurations OADP, les pods d’application Cassandra peuvent entrer dans le statut CrashLoopBackoff. Afin de contourner ce problème, supprimez les pods StatefulSet qui renvoient l’état d’erreur CrashLoopBackoff après avoir restauré OADP. Le contrôleur StatefulSet recrée ensuite ces pods et il fonctionne normalement. À PROPOS DE OADP-4407
Le référencement de déploiement ImageStream n’est pas restauré correctement conduisant à des contenus de pod et de volume corrompus
Lors d’une opération de restauration de système de fichiers (FSB), une ressource de déploiement faisant référence à un ImageStream n’est pas restaurée correctement. La gousse restaurée qui exécute le FSB, et le postHook est interrompu prématurément.
Lors de l’opération de restauration, le contrôleur OpenShift Container Platform met à jour le champ spec.template.spec.containers dans la ressource Déploiement avec un hachage ImageStreamTag mis à jour. La mise à jour déclenche le déploiement d’un nouveau pod, mettant fin à la gousse sur laquelle velero exécute le FSB avec le post-hook. En savoir plus sur le déclencheur du flux d’images, consultez les mises à jour sur les changements de flux d’image.
La solution de contournement de ce comportement est un processus de restauration en deux étapes:
Effectuez une restauration à l’exclusion des ressources de déploiement, par exemple:
velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.apps
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.apps
Copy to Clipboard Copied! Lorsque la première restauration est couronnée de succès, effectuez une deuxième restauration en incluant ces ressources, par exemple:
velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
Copy to Clipboard Copied!
1.2.1.4. Les notes de sortie de OADP 1.4.0
L’API OpenShift pour la protection des données (OADP) 1.4.0 liste les problèmes résolus et les problèmes connus.
1.2.1.4.1. Des problèmes résolus
La restauration fonctionne correctement dans Red Hat OpenShift Service sur AWS 4.16
Auparavant, lors de la restauration de l’espace de noms de l’application supprimée, l’opération de restauration a partiellement échoué avec le nom de ressource peut ne pas être une erreur vide dans Red Hat OpenShift Service sur AWS 4.16. Avec cette mise à jour, la restauration fonctionne comme prévu dans Red Hat OpenShift Service sur AWS 4.16. À PROPOS DE OADP-4075
Les sauvegardes de Mover de données fonctionnent correctement dans le Red Hat OpenShift Service sur AWS 4.16 cluster
Auparavant, Velero utilisait la version antérieure du SDK où le champ Spec.SourceVolumeMode n’existait pas. En conséquence, les sauvegardes de Data Mover ont échoué dans le Red Hat OpenShift Service sur le cluster AWS 4.16 sur le snapshotter externe avec la version 4.2. Avec cette mise à jour, snapshotter externe est mis à niveau vers la version 7.0 et ultérieure. En conséquence, les sauvegardes ne échouent pas dans le Red Hat OpenShift Service sur AWS 4.16 cluster. À PROPOS DE OADP-3922
Consultez la liste complète de tous les problèmes résolus dans cette version, consultez la liste des problèmes résolus dans Jira.
1.2.1.4.2. Problèmes connus
La sauvegarde échoue lorsque checkumAlgorithm n’est pas défini pour MCG
Lors de l’exécution d’une sauvegarde de n’importe quelle application avec Noobaa comme emplacement de sauvegarde, si le paramètre de configuration checksumAlgorithm n’est pas défini, la sauvegarde échoue. Afin de résoudre ce problème, si vous ne fournissez pas de valeur pour checkumAlgorithm dans la configuration de l’emplacement de stockage de sauvegarde (BSL), une valeur vide est ajoutée. La valeur vide n’est ajoutée que pour les BSL créés à l’aide d’une ressource personnalisée (CR) de l’application de protection des données (DPA), et cette valeur n’est pas ajoutée si les BSL sont créés en utilisant une autre méthode. À PROPOS DE OADP-4274
Consultez la liste complète de tous les problèmes connus dans cette version, consultez la liste des problèmes connus OADP 1.4.0 dans Jira.
1.2.1.4.3. Améliorer les notes
Effectuez toujours une mise à niveau vers la prochaine version mineure. Il ne faut pas sauter les versions. Afin de mettre à jour une version ultérieure, mettre à niveau un seul canal à la fois. À titre d’exemple, pour passer de l’API OpenShift pour la protection des données (OADP) 1.1 à 1.3, mettre à niveau d’abord vers 1.2, puis vers 1.3.
1.2.1.4.3.1. Changements de OADP 1.3 à 1.4
Le serveur Velero a été mis à jour de la version 1.12 à 1.14. A noter qu’il n’y a pas de changements dans l’application de protection des données (DPA).
Cela change ce qui suit:
- Le code velero-plugin-for-csi est maintenant disponible dans le code Velero, ce qui signifie qu’un conteneur d’init n’est plus nécessaire pour le plugin.
- Le client Burst et le QPS sont passés de 30 et 20 à 100 et 100 respectivement.
Le plugin velero-plugin-for-aws a mis à jour la valeur par défaut du champ spec.config.checksumAlgorithm dans les objets BackupStorageLocation (BSL) de "" (pas de calcul de somme de contrôle) à l’algorithme CRC32. Les types d’algorithmes de somme de contrôle sont connus pour fonctionner uniquement avec AWS. De nombreux fournisseurs S3 exigent que le md5sum soit désactivé en définissant l’algorithme de somme de contrôle sur "". Confirmez la prise en charge et la configuration de l’algorithme md5sum avec votre fournisseur de stockage.
Dans OADP 1.4, la valeur par défaut pour les BSL créés dans DPA pour cette configuration est "". Cette valeur par défaut signifie que le md5sum n’est pas vérifié, ce qui est compatible avec OADP 1.3. Dans le cas des BSL créés dans DPA, mettez-le à jour en utilisant le champ spec.backupLocations[].velero.config.checksumAlgorithm dans le DPA. Lorsque vos BSL sont créés en dehors du DPA, vous pouvez mettre à jour cette configuration en utilisant spec.config.checksumAlgorithm dans les BSL.
1.2.1.4.3.2. Sauvegarde de la configuration DPA
Il faut sauvegarder la configuration actuelle de DataProtectionApplication (DPA).
Procédure
Enregistrez votre configuration DPA actuelle en exécutant la commande suivante:
Commande d’exemple
oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
$ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
Copy to Clipboard Copied!
1.2.1.4.3.3. Améliorer l’opérateur OADP
Utilisez la procédure suivante lors de la mise à niveau de l’opérateur OpenShift API for Data Protection (OADP).
Procédure
- Changez votre canal d’abonnement pour l’opérateur OADP de stable-1.3 à stable-1.4.
- Attendez que l’opérateur et les conteneurs mettent à jour et redémarrent.
1.2.1.4.4. Conversion du DPA à la nouvelle version
Afin de passer de OADP 1.3 à 1.4, aucune modification d’application de protection des données (DPA) n’est requise.
1.2.1.4.5. La vérification de la mise à niveau
La procédure suivante permet de vérifier la mise à niveau.
Procédure
Contrôlez l’installation en consultant les ressources OpenShift API for Data Protection (OADP) en exécutant la commande suivante:
oc get all -n openshift-adp
$ oc get all -n openshift-adp
Copy to Clipboard Copied! Exemple de sortie
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
Copy to Clipboard Copied! Assurez-vous que la DataProtectionApplication (DPA) est réconciliée en exécutant la commande suivante:
oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
Copy to Clipboard Copied! Exemple de sortie
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
Copy to Clipboard Copied! - Assurez-vous que le type est défini sur Reconciled.
Vérifiez l’emplacement de stockage de sauvegarde et confirmez que le PHASE est disponible en exécutant la commande suivante:
oc get backupstoragelocations.velero.io -n openshift-adp
$ oc get backupstoragelocations.velero.io -n openshift-adp
Copy to Clipboard Copied! Exemple de sortie
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
Copy to Clipboard Copied!
1.3. La performance de l’OADP
1.3.1. Configurations réseau recommandées par OADP
Grâce à l’API OpenShift pour la protection des données (OADP), vous devez disposer d’un réseau stable et résilient à travers les nœuds OpenShift, le stockage S3 et les environnements cloud pris en charge qui répondent aux recommandations d’OpenShift.
Afin d’assurer le succès des opérations de sauvegarde et de restauration des déploiements avec des seaux S3 distants situés hors-cluster avec des chemins de données sous-optimaux, il est recommandé que vos paramètres réseau répondent aux exigences minimales suivantes dans des conditions moins optimales:
- Bande passante (vitesse de téléchargement du réseau vers le stockage d’objets): Plus de 2 Mbps pour les petites sauvegardes et 10-100 Mbps en fonction du volume de données pour les sauvegardes plus grandes.
- Perte de paquets: 1%
- Corruption de paquets: 1%
- Latence: 100ms
Assurez-vous que votre service OpenShift Red Hat sur le réseau AWS fonctionne de manière optimale et répond à Red Hat OpenShift Service sur les exigences du réseau AWS.
Bien que Red Hat fournisse des supports pour les pannes de sauvegarde et de restauration standard, il ne fournit pas de support pour les défaillances causées par des paramètres réseau qui ne répondent pas aux seuils recommandés.
1.4. Fonctionnalités et plugins OADP
Les fonctionnalités OpenShift API for Data Protection (OADP) offrent des options pour sauvegarder et restaurer les applications.
Les plugins par défaut permettent à Velero de s’intégrer à certains fournisseurs de cloud et de sauvegarder et restaurer Red Hat OpenShift Service sur les ressources AWS.
1.4.1. Caractéristiques OADP
L’API OpenShift pour la protection des données (OADP) prend en charge les fonctionnalités suivantes:
- Backup
Il est possible d’utiliser OADP pour sauvegarder toutes les applications sur OpenShift Platform, ou vous pouvez filtrer les ressources par type, espace de noms ou étiquette.
L’OADP sauvegarde les objets Kubernetes et les images internes en les enregistrant comme fichier d’archive sur le stockage d’objets. L’OADP sauvegarde les volumes persistants (PV) en créant des instantanés avec l’API de snapshot cloud native ou avec l’interface de stockage de conteneurs (CSI). Dans le cas des fournisseurs de cloud qui ne prennent pas en charge les instantanés, OADP sauvegarde les ressources et les données PV avec Restic.
NoteIl faut exclure les opérateurs de la sauvegarde d’une application pour la sauvegarde et la restauration pour réussir.
- Restore
Il est possible de restaurer des ressources et des PV à partir d’une sauvegarde. Il est possible de restaurer tous les objets dans une sauvegarde ou de filtrer les objets par l’espace de noms, le PV ou l’étiquette.
NoteIl faut exclure les opérateurs de la sauvegarde d’une application pour la sauvegarde et la restauration pour réussir.
- Calendrier
- Les sauvegardes peuvent être programmées à des intervalles spécifiés.
- Crochets
- Il est possible d’utiliser des crochets pour exécuter des commandes dans un conteneur sur un pod, par exemple, fsfreeze pour geler un système de fichiers. Il est possible de configurer un crochet pour s’exécuter avant ou après une sauvegarde ou une restauration. Les crochets de restauration peuvent fonctionner dans un conteneur d’init ou dans le conteneur d’application.
1.4.2. Plugins OADP
L’API OpenShift pour la protection des données (OADP) fournit des plugins Velero par défaut qui sont intégrés aux fournisseurs de stockage pour prendre en charge les opérations de sauvegarde et d’instantané. Il est possible de créer des plugins personnalisés basés sur les plugins Velero.
L’OADP fournit également des plugins pour Red Hat OpenShift Service sur les sauvegardes de ressources AWS, les sauvegardes de ressources OpenShift Virtualization et les instantanés CSI (Container Storage Interface).
Plugin OADP | Fonction | Emplacement de stockage |
---|---|---|
| Sauvegarde et restaure les objets Kubernetes. | AWS S3 |
Sauvegarde et restaure les volumes avec des instantanés. | AWS EBS | |
| Sauvegarde et restaure Red Hat OpenShift Service sur les ressources AWS. [1] | Boutique d’objets |
| Sauvegarde et restaure les ressources OpenShift Virtualization. [2] | Boutique d’objets |
| Sauvegarde et restaure des volumes avec des instantanés CSI. [3] | Le stockage en nuage qui prend en charge les instantanés CSI |
| Le logiciel VolumeSnapshotMover déplace les snapshots du cluster dans un magasin d’objets à utiliser lors d’un processus de restauration pour récupérer des applications étatiques, dans des situations telles que la suppression de clusters. [4] | Boutique d’objets |
- Il est obligatoire.
- Les disques de machine virtuelle sont sauvegardés avec des instantanés CSI ou Restic.
Le plugin csi utilise l’API instantanée Kubernetes CSI.
- Le logiciel OADP 1.1 ou version ultérieure utilise snapshot.storage.k8s.io/v1
- Le logiciel OADP 1.0 utilise snapshot.storage.k8s.io/v1beta1
- L’OADP 1.2 seulement.
1.4.3. À propos des plugins OADP Velero
Lorsque vous installez Velero, vous pouvez configurer deux types de plugins:
- Plugins de fournisseur de cloud par défaut
- Des plugins personnalisés
Les deux types de plugins sont facultatifs, mais la plupart des utilisateurs configurent au moins un plugin fournisseur de cloud.
1.4.3.1. Plugins de fournisseurs de cloud Velero par défaut
Lorsque vous configurez le fichier oadp_v1alpha1_dpa.yaml, vous pouvez installer l’un des plugins par défaut suivants:
- AWS (Amazon Web Services)
- ajouter au panier OpenShift Velero plugin
- CSI (Interface de stockage de conteneurs)
- KubeVirt (KubeVirt)
Lors du déploiement, vous spécifiez les plugins par défaut souhaités dans le fichier oadp_v1alpha1_dpa.yaml.
Exemple de fichier
Le fichier .yaml suivant installe les plugins openshift, aws, azure et gcp:
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: velero: defaultPlugins: - openshift - aws - azure - gcp
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
velero:
defaultPlugins:
- openshift
- aws
- azure
- gcp
1.4.3.2. Plugins Velero personnalisés
Lors du déploiement, vous pouvez installer un plugin Velero personnalisé en spécifiant l’image et le nom du plugin lorsque vous configurez le fichier oadp_v1alpha1_dpa.yaml.
Lors du déploiement, vous spécifiez les plugins personnalisés souhaités dans le fichier oadp_v1alpha1_dpa.yaml.
Exemple de fichier
Le fichier .yaml suivant installe les plugins openshift, azure et gcp par défaut et un plugin personnalisé qui a le nom custom-plugin-example et l’image quay.io/example-repo/custom-velero-plugin:
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: velero: defaultPlugins: - openshift - azure - gcp customPlugins: - name: custom-plugin-example image: quay.io/example-repo/custom-velero-plugin
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
velero:
defaultPlugins:
- openshift
- azure
- gcp
customPlugins:
- name: custom-plugin-example
image: quay.io/example-repo/custom-velero-plugin
1.4.3.3. Les plugins Velero renvoient le message « EOF reçu, arrêt de la boucle recv »
Les plugins Velero sont lancés en tant que processus distincts. Après la fin de l’opération Velero, soit avec succès ou non, ils sortent. La réception d’un EOF reçu, l’arrêt du message de boucle recv dans les journaux de débogage indique qu’une opération de plugin est terminée. Cela ne signifie pas qu’une erreur s’est produite.
1.4.4. Plugins OADP problèmes connus
La section suivante décrit les problèmes connus dans les plugins OpenShift API for Data Protection (OADP):
1.4.4.1. Le plugin Velero panique lors des sauvegardes d’images en raison d’un secret manquant
Lorsque la sauvegarde et l’emplacement de stockage de sauvegarde (BSL) sont gérés en dehors du champ d’application de l’application de protection des données (DPA), le contrôleur OADP, ce qui signifie que la réconciliation DPA ne crée pas le fichier oadp-<bsl_name>-bsl_provider>-registry-secret pertinent.
Lorsque la sauvegarde est exécutée, le plugin OpenShift Velero panique sur la sauvegarde imagestream, avec l’erreur de panique suivante:
024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item" backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io, namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked: runtime error: index out of range with length 1, stack trace: goroutine 94…
024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…
1.4.4.1.1. Contournement pour éviter l’erreur de panique
Afin d’éviter l’erreur de panique du plugin Velero, effectuez les étapes suivantes:
Étiqueter le BSL personnalisé avec l’étiquette correspondante:
oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
$ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
Copy to Clipboard Copied! Après que le BSL soit étiqueté, attendez que le DPA se réconcilie.
NoteIl est possible de forcer la réconciliation en apportant tout changement mineur au DPA lui-même.
Lorsque le DPA se réconcilie, confirmez que les oadp-<bsl_name>-<bsl_provider>-registry-secret pertinents ont été créés et que les données de registre correctes y ont été peuplées:
oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
Copy to Clipboard Copied!
1.4.4.2. Défaut de segmentation du contrôleur OpenShift ADP
Lorsque vous configurez un DPA avec à la fois cloudstorage et restic activé, le pod openshift-adp-controller-manager se bloque et redémarre indéfiniment jusqu’à ce que le pod échoue avec un défaut de segmentation de boucle de crash.
Le velero ou le cloudstorage peuvent être définis, car ce sont des champs mutuellement exclusifs.
- Lorsque vous avez défini à la fois velero et cloudstorage, le gestionnaire openshift-adp-controller-manager échoue.
- Lorsque vous n’avez ni velero ni cloudstorage défini, le gestionnaire openshift-adp-controller-manager échoue.
Consultez l’OADP-1054 pour plus d’informations à ce sujet.
1.4.4.2.1. Contournement de faille de segmentation du contrôleur OpenShift ADP
Lorsque vous configurez un DPA, vous devez définir le velero ou le cloudstorage. Lorsque vous définissez les deux API dans votre DPA, le pod openshift-adp-controller-manager échoue avec un défaut de segmentation de boucle de panne.
1.5. Cas d’utilisation OADP
1.5.1. Sauvegarde des charges de travail sur OADP avec ROSA STS
1.5.1.1. Effectuer une sauvegarde avec OADP et ROSA STS
L’exemple suivant d’application hello-world n’a pas de volumes persistants (PVs) attachés. Effectuez une sauvegarde avec l’API OpenShift pour la protection des données (OADP) avec Red Hat OpenShift Service sur AWS (ROSA) STS.
La configuration de l’application de protection des données (DPA) fonctionnera.
Créez une charge de travail pour sauvegarder en exécutant les commandes suivantes:
oc create namespace hello-world
$ oc create namespace hello-world
Copy to Clipboard Copied! oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
Copy to Clipboard Copied! Exposez l’itinéraire en exécutant la commande suivante:
oc expose service/hello-openshift -n hello-world
$ oc expose service/hello-openshift -n hello-world
Copy to Clipboard Copied! Assurez-vous que l’application fonctionne en exécutant la commande suivante:
curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
Copy to Clipboard Copied! Exemple de sortie
Hello OpenShift!
Hello OpenShift!
Copy to Clipboard Copied! Sauvegardez la charge de travail en exécutant la commande suivante:
cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Backup metadata: name: hello-world namespace: openshift-adp spec: includedNamespaces: - hello-world storageLocation: ${CLUSTER_NAME}-dpa-1 ttl: 720h0m0s EOF
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Backup metadata: name: hello-world namespace: openshift-adp spec: includedNamespaces: - hello-world storageLocation: ${CLUSTER_NAME}-dpa-1 ttl: 720h0m0s EOF
Copy to Clipboard Copied! Attendez que la sauvegarde soit terminée, puis exécutez la commande suivante:
watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
$ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
Copy to Clipboard Copied! Exemple de sortie
{ "completionTimestamp": "2022-09-07T22:20:44Z", "expiration": "2022-10-07T22:20:22Z", "formatVersion": "1.1.0", "phase": "Completed", "progress": { "itemsBackedUp": 58, "totalItems": 58 }, "startTimestamp": "2022-09-07T22:20:22Z", "version": 1 }
{ "completionTimestamp": "2022-09-07T22:20:44Z", "expiration": "2022-10-07T22:20:22Z", "formatVersion": "1.1.0", "phase": "Completed", "progress": { "itemsBackedUp": 58, "totalItems": 58 }, "startTimestamp": "2022-09-07T22:20:22Z", "version": 1 }
Copy to Clipboard Copied! Effacer la charge de travail de démonstration en exécutant la commande suivante:
oc delete ns hello-world
$ oc delete ns hello-world
Copy to Clipboard Copied! Restaurer la charge de travail à partir de la sauvegarde en exécutant la commande suivante:
cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Restore metadata: name: hello-world namespace: openshift-adp spec: backupName: hello-world EOF
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Restore metadata: name: hello-world namespace: openshift-adp spec: backupName: hello-world EOF
Copy to Clipboard Copied! Attendez que la restauration se termine en exécutant la commande suivante:
watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
$ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
Copy to Clipboard Copied! Exemple de sortie
{ "completionTimestamp": "2022-09-07T22:25:47Z", "phase": "Completed", "progress": { "itemsRestored": 38, "totalItems": 38 }, "startTimestamp": "2022-09-07T22:25:28Z", "warnings": 9 }
{ "completionTimestamp": "2022-09-07T22:25:47Z", "phase": "Completed", "progress": { "itemsRestored": 38, "totalItems": 38 }, "startTimestamp": "2022-09-07T22:25:28Z", "warnings": 9 }
Copy to Clipboard Copied! Assurez-vous que la charge de travail est restaurée en exécutant la commande suivante:
oc -n hello-world get pods
$ oc -n hello-world get pods
Copy to Clipboard Copied! Exemple de sortie
NAME READY STATUS RESTARTS AGE hello-openshift-9f885f7c6-kdjpj 1/1 Running 0 90s
NAME READY STATUS RESTARTS AGE hello-openshift-9f885f7c6-kdjpj 1/1 Running 0 90s
Copy to Clipboard Copied! Cochez le JSONPath en exécutant la commande suivante:
curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
Copy to Clipboard Copied! Exemple de sortie
Hello OpenShift!
Hello OpenShift!
Copy to Clipboard Copied!
Consultez la documentation de dépannage de l’équipe OADP pour obtenir des conseils de dépannage.
1.5.1.2. Le nettoyage d’un cluster après une sauvegarde avec OADP et ROSA STS
Dans le cas où vous devez désinstaller l’opérateur OpenShift API for Data Protection (OADP) avec les sauvegardes et le seau S3 de cet exemple, suivez ces instructions.
Procédure
Effacer la charge de travail en exécutant la commande suivante:
oc delete ns hello-world
$ oc delete ns hello-world
Copy to Clipboard Copied! Effacer l’application de protection des données (DPA) en exécutant la commande suivante:
oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
$ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
Copy to Clipboard Copied! Effacer le stockage en nuage en exécutant la commande suivante:
oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
$ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
Copy to Clipboard Copied! AvertissementDans le cas où cette commande est suspendue, vous devrez peut-être supprimer le finalisateur en exécutant la commande suivante:
oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
$ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
Copy to Clipboard Copied! Lorsque l’opérateur n’est plus requis, retirez-le en exécutant la commande suivante:
oc -n openshift-adp delete subscription oadp-operator
$ oc -n openshift-adp delete subscription oadp-operator
Copy to Clipboard Copied! Enlevez l’espace de noms de l’opérateur:
oc delete ns openshift-adp
$ oc delete ns openshift-adp
Copy to Clipboard Copied! Lorsque les ressources de sauvegarde et de restauration ne sont plus nécessaires, retirez-les du cluster en exécutant la commande suivante:
oc delete backups.velero.io hello-world
$ oc delete backups.velero.io hello-world
Copy to Clipboard Copied! Afin de supprimer les objets de sauvegarde, de restauration et de télécommande dans AWS S3, exécutez la commande suivante:
velero backup delete hello-world
$ velero backup delete hello-world
Copy to Clipboard Copied! Lorsque vous n’avez plus besoin des Définitions de ressources personnalisées (CRD), supprimez-les du cluster en exécutant la commande suivante:
for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
$ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
Copy to Clipboard Copied! Effacer le seau AWS S3 en exécutant les commandes suivantes:
aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
$ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
Copy to Clipboard Copied! aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
$ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
Copy to Clipboard Copied! Détachez la politique du rôle en exécutant la commande suivante:
aws iam detach-role-policy --role-name "${ROLE_NAME}" --policy-arn "${POLICY_ARN}"
$ aws iam detach-role-policy --role-name "${ROLE_NAME}" --policy-arn "${POLICY_ARN}"
Copy to Clipboard Copied! Supprimez le rôle en exécutant la commande suivante:
aws iam delete-role --role-name "${ROLE_NAME}"
$ aws iam delete-role --role-name "${ROLE_NAME}"
Copy to Clipboard Copied!
1.5.2. L’API OpenShift pour la protection des données (OADP) restaure le cas d’utilisation
Ci-dessous est un cas d’utilisation pour utiliser OADP pour restaurer une sauvegarde dans un espace de noms différent.
1.5.2.1. La restauration d’une application dans un espace de noms différent en utilisant OADP
Restaurer une sauvegarde d’une application en utilisant OADP dans un nouvel espace de noms cible, test-restauration-application. Afin de restaurer une sauvegarde, vous créez une ressource personnalisée de restauration (CR) comme indiqué dans l’exemple suivant. Dans le CR de restauration, l’espace de noms source fait référence à l’espace de noms de l’application que vous avez inclus dans la sauvegarde. Ensuite, vous vérifiez la restauration en changeant votre projet vers le nouvel espace de noms restauré et en vérifiant les ressources.
Conditions préalables
- L’opérateur OADP a été installé.
- La sauvegarde d’une application est à restaurer.
Procédure
Créez une restauration CR comme indiqué dans l’exemple suivant:
Exemple de restauration CR
apiVersion: velero.io/v1 kind: Restore metadata: name: test-restore namespace: openshift-adp spec: backupName: <backup_name> restorePVs: true namespaceMapping: <application_namespace>: test-restore-application
apiVersion: velero.io/v1 kind: Restore metadata: name: test-restore
1 namespace: openshift-adp spec: backupName: <backup_name>
2 restorePVs: true namespaceMapping: <application_namespace>: test-restore-application
3 Copy to Clipboard Copied! - 1
- Le nom de la restauration CR.
- 2
- Indiquez le nom de la sauvegarde.
- 3
- le namespaceMapping mappe l’espace de noms de l’application source à l’espace de noms de l’application cible. Indiquez l’espace de noms de l’application que vous avez sauvegardé. l’application test-restauration est l’espace de noms cible où vous souhaitez restaurer la sauvegarde.
Appliquez le CR de restauration en exécutant la commande suivante:
oc apply -f <restore_cr_filename>
$ oc apply -f <restore_cr_filename>
Copy to Clipboard Copied!
La vérification
Assurez-vous que la restauration est en phase terminée en exécutant la commande suivante:
oc describe restores.velero.io <restore_name> -n openshift-adp
$ oc describe restores.velero.io <restore_name> -n openshift-adp
Copy to Clipboard Copied! Changer l’application de test-restauration de l’espace de noms restaurée en exécutant la commande suivante:
oc project test-restore-application
$ oc project test-restore-application
Copy to Clipboard Copied! Contrôlez les ressources restaurées telles que la revendication de volume persistant (pvc), le service (svc), le déploiement, le secret et la carte de configuration en exécutant la commande suivante:
oc get pvc,svc,deployment,secret,configmap
$ oc get pvc,svc,deployment,secret,configmap
Copy to Clipboard Copied! Exemple de sortie
NAME STATUS VOLUME persistentvolumeclaim/mysql Bound pvc-9b3583db-...-14b86 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/mysql ClusterIP 172....157 <none> 3306/TCP 2m56s service/todolist ClusterIP 172.....15 <none> 8000/TCP 2m56s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/mysql 0/1 1 0 2m55s NAME TYPE DATA AGE secret/builder-dockercfg-6bfmd kubernetes.io/dockercfg 1 2m57s secret/default-dockercfg-hz9kz kubernetes.io/dockercfg 1 2m57s secret/deployer-dockercfg-86cvd kubernetes.io/dockercfg 1 2m57s secret/mysql-persistent-sa-dockercfg-rgp9b kubernetes.io/dockercfg 1 2m57s NAME DATA AGE configmap/kube-root-ca.crt 1 2m57s configmap/openshift-service-ca.crt 1 2m57s
NAME STATUS VOLUME persistentvolumeclaim/mysql Bound pvc-9b3583db-...-14b86 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/mysql ClusterIP 172....157 <none> 3306/TCP 2m56s service/todolist ClusterIP 172.....15 <none> 8000/TCP 2m56s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/mysql 0/1 1 0 2m55s NAME TYPE DATA AGE secret/builder-dockercfg-6bfmd kubernetes.io/dockercfg 1 2m57s secret/default-dockercfg-hz9kz kubernetes.io/dockercfg 1 2m57s secret/deployer-dockercfg-86cvd kubernetes.io/dockercfg 1 2m57s secret/mysql-persistent-sa-dockercfg-rgp9b kubernetes.io/dockercfg 1 2m57s NAME DATA AGE configmap/kube-root-ca.crt 1 2m57s configmap/openshift-service-ca.crt 1 2m57s
Copy to Clipboard Copied!
1.6. Installation et configuration d’OADP
1.6.1. Installation d’OADP
Il est possible d’utiliser l’API OpenShift pour la protection des données (OADP) avec Red Hat OpenShift Service sur AWS (ROSA) pour sauvegarder et restaurer les données des applications.
Avant d’installer l’API OpenShift pour la protection des données (OADP), vous devez configurer les informations d’identification des rôles et des politiques pour OADP afin qu’elle puisse utiliser l’API Amazon Web Services.
Ce processus se déroule en deux étapes:
- Créer des informations d’identification AWS
- Installez l’opérateur OADP et donnez-lui un rôle IAM
1.6.1.1. La préparation des identifiants AWS pour OADP
Le compte Amazon Web Services doit être préparé et configuré pour accepter une installation OpenShift API for Data Protection (OADP).
Procédure
Créez les variables d’environnement suivantes en exécutant les commandes suivantes:
ImportantChangez le nom du cluster pour correspondre à votre cluster ROSA et assurez-vous d’être connecté au cluster en tant qu’administrateur. Assurez-vous que tous les champs sont affichés correctement avant de continuer.
export CLUSTER_NAME=my-cluster
$ export CLUSTER_NAME=my-cluster
1 export ROSA_CLUSTER_ID=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .id) export REGION=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .region.id) export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||') export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export CLUSTER_VERSION=$(rosa describe cluster -c ${CLUSTER_NAME} -o json | jq -r .version.raw_id | cut -f -2 -d '.') export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials" export SCRATCH="/tmp/${CLUSTER_NAME}/oadp" mkdir -p ${SCRATCH} echo "Cluster ID: ${ROSA_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
Copy to Clipboard Copied! - 1
- Le nom de votre cluster ROSA est remplacé par mon cluster.
Dans le compte AWS, créez une politique IAM pour permettre l’accès à AWS S3:
Vérifiez si la stratégie existe en exécutant la commande suivante:
POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text)
$ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text)
1 Copy to Clipboard Copied! - 1
- Remplacez RosaOadp par le nom de votre politique.
Entrez la commande suivante pour créer le fichier JSON de stratégie, puis créez la stratégie dans ROSA:
NoteLorsque la stratégie ARN n’est pas trouvée, la commande crée la stratégie. Dans le cas où la politique ARN existe déjà, la déclaration si elle saute intentionnellement la création de la politique.
if [[ -z "${POLICY_ARN}" ]]; then
$ if [[ -z "${POLICY_ARN}" ]]; then cat << EOF > ${SCRATCH}/policy.json
1 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts", "ec2:DescribeSnapshots", "ec2:DescribeVolumes", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumesModifications", "ec2:DescribeVolumeStatus", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" } ]} EOF POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \ --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \ --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \ --output text) fi
Copy to Clipboard Copied! - 1
- Le SCRATCH est un nom pour un répertoire temporaire créé pour les variables d’environnement.
Consultez la stratégie ARN en exécutant la commande suivante:
echo ${POLICY_ARN}
$ echo ${POLICY_ARN}
Copy to Clipboard Copied!
Créer une politique de confiance du rôle de l’IAM pour le cluster:
Créez le fichier de stratégie de confiance en exécutant la commande suivante:
cat <<EOF > ${SCRATCH}/trust-policy.json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_ENDPOINT}:sub": [ "system:serviceaccount:openshift-adp:openshift-adp-controller-manager", "system:serviceaccount:openshift-adp:velero"] } } }] } EOF
$ cat <<EOF > ${SCRATCH}/trust-policy.json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_ENDPOINT}:sub": [ "system:serviceaccount:openshift-adp:openshift-adp-controller-manager", "system:serviceaccount:openshift-adp:velero"] } } }] } EOF
Copy to Clipboard Copied! Créez le rôle en exécutant la commande suivante:
ROLE_ARN=$(aws iam create-role --role-name \ "${ROLE_NAME}" \ --assume-role-policy-document file://${SCRATCH}/trust-policy.json \ --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} \ Key=rosa_openshift_version,Value=${CLUSTER_VERSION} \ Key=rosa_role_prefix,Value=ManagedOpenShift \ Key=operator_namespace,Value=openshift-adp \ Key=operator_name,Value=openshift-oadp \ --query Role.Arn --output text)
$ ROLE_ARN=$(aws iam create-role --role-name \ "${ROLE_NAME}" \ --assume-role-policy-document file://${SCRATCH}/trust-policy.json \ --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} \ Key=rosa_openshift_version,Value=${CLUSTER_VERSION} \ Key=rosa_role_prefix,Value=ManagedOpenShift \ Key=operator_namespace,Value=openshift-adp \ Key=operator_name,Value=openshift-oadp \ --query Role.Arn --output text)
Copy to Clipboard Copied! Afficher le rôle ARN en exécutant la commande suivante:
echo ${ROLE_ARN}
$ echo ${ROLE_ARN}
Copy to Clipboard Copied!
Joindre la politique de l’IAM au rôle de l’IAM en exécutant la commande suivante:
aws iam attach-role-policy --role-name "${ROLE_NAME}" \ --policy-arn ${POLICY_ARN}
$ aws iam attach-role-policy --role-name "${ROLE_NAME}" \ --policy-arn ${POLICY_ARN}
Copy to Clipboard Copied!
1.6.1.2. Installation de l’opérateur OADP et rôle IAM
AWS Security Token Service (AWS STS) est un service Web mondial qui fournit des informations d’identification à court terme pour les utilisateurs IAM ou fédérés. Le Red Hat OpenShift Service sur AWS (ROSA) avec STS est le mode d’identification recommandé pour les clusters ROSA. Ce document décrit comment installer l’API OpenShift pour la protection des données (OADP) sur ROSA avec AWS STS.
Le Restic n’est pas pris en charge.
La sauvegarde du système de fichiers Kopia (FSB) est prise en charge lors de la sauvegarde des systèmes de fichiers qui n’ont pas de prise en charge de l’interface de stockage de conteneurs (CSI).
Exemple de systèmes de fichiers comprennent ce qui suit:
- Amazon Elastic File System (EFS)
- Le système de fichiers réseau (NFS)
- les volumes videDir
- Les volumes locaux
En cas de sauvegarde des volumes, OADP sur ROSA avec AWS STS ne prend en charge que les snapshots natifs et les snapshots CSI (Container Storage Interface).
Dans un cluster Amazon ROSA qui utilise l’authentification STS, la restauration des données sauvegardées dans une autre région AWS n’est pas prise en charge.
La fonction Data Mover n’est pas actuellement prise en charge dans les clusters ROSA. Il est possible d’utiliser des outils AWS S3 natifs pour déplacer les données.
Conditions préalables
- A Red Hat OpenShift Service sur AWS ROSA cluster avec l’accès et les jetons requis. Consultez la procédure précédente Préparation des informations d’identification AWS pour OADP. Lorsque vous prévoyez d’utiliser deux clusters différents pour sauvegarder et restaurer, vous devez préparer des identifiants AWS, y compris ROLE_ARN, pour chaque cluster.
Procédure
Créez un service Red Hat OpenShift sur AWS secret à partir de votre fichier jeton AWS en entrant les commandes suivantes:
Créer le fichier d’identification:
cat <<EOF > ${SCRATCH}/credentials [default] role_arn = ${ROLE_ARN} web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token region = <aws_region> EOF
$ cat <<EOF > ${SCRATCH}/credentials [default] role_arn = ${ROLE_ARN} web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token region = <aws_region>
1 EOF
Copy to Clipboard Copied! - 1
- <aws_region> par la région AWS à utiliser pour le point d’extrémité STS.
Créer un espace de noms pour OADP:
oc create namespace openshift-adp
$ oc create namespace openshift-adp
Copy to Clipboard Copied! Créez le service Red Hat OpenShift sur AWS secret:
oc -n openshift-adp create secret generic cloud-credentials \ --from-file=${SCRATCH}/credentials
$ oc -n openshift-adp create secret generic cloud-credentials \ --from-file=${SCRATCH}/credentials
Copy to Clipboard Copied! NoteDans Red Hat OpenShift Service sur AWS version 4.15 et ultérieure, l’opérateur OADP prend en charge un nouveau flux de travail STS standardisé via le gestionnaire de cycle de vie de l’opérateur (OLM) et Cloud Credentials Operator (CCO). Dans ce flux de travail, vous n’avez pas besoin de créer le secret ci-dessus, vous n’avez besoin que de fournir le rôle ARN lors de l’installation d’opérateurs gérés par OLM en utilisant le service OpenShift Red Hat sur la console Web AWS, pour plus d’informations voir Installation depuis OperatorHub à l’aide de la console Web.
Le secret précédent est créé automatiquement par CCO.
Installez l’opérateur OADP:
- Dans le Red Hat OpenShift Service sur la console web AWS, accédez aux opérateurs → OperatorHub.
- Cherchez l’opérateur OADP.
- Dans le champ role_ARN, collez le rôle_arn que vous avez créé précédemment et cliquez sur Installer.
Créez un stockage cloud AWS à l’aide de vos identifiants AWS en entrant la commande suivante:
cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: CloudStorage metadata: name: ${CLUSTER_NAME}-oadp namespace: openshift-adp spec: creationSecret: key: credentials name: cloud-credentials enableSharedConfig: true name: ${CLUSTER_NAME}-oadp provider: aws region: $REGION EOF
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: CloudStorage metadata: name: ${CLUSTER_NAME}-oadp namespace: openshift-adp spec: creationSecret: key: credentials name: cloud-credentials enableSharedConfig: true name: ${CLUSTER_NAME}-oadp provider: aws region: $REGION EOF
Copy to Clipboard Copied! Consultez la classe de stockage par défaut de votre application en entrant la commande suivante:
oc get pvc -n <namespace>
$ oc get pvc -n <namespace>
Copy to Clipboard Copied! Exemple de sortie
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE applog Bound pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8 1Gi RWO gp3-csi 4d19h mysql Bound pvc-16b8e009-a20a-4379-accc-bc81fedd0621 1Gi RWO gp3-csi 4d19h
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE applog Bound pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8 1Gi RWO gp3-csi 4d19h mysql Bound pvc-16b8e009-a20a-4379-accc-bc81fedd0621 1Gi RWO gp3-csi 4d19h
Copy to Clipboard Copied! Bénéficiez de la classe de stockage en exécutant la commande suivante:
oc get storageclass
$ oc get storageclass
Copy to Clipboard Copied! Exemple de sortie
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer true 4d21h gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3 ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer true 4d21h gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3 ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h
Copy to Clipboard Copied! NoteLes classes de stockage suivantes fonctionneront:
- gp3-csi
- gp2-csi
- Gp3
- Gp2
Lorsque l’application ou les applications en cours de sauvegarde sont toutes utilisant des volumes persistants (PV) avec Container Storage Interface (CSI), il est conseillé d’inclure le plugin CSI dans la configuration OADP DPA.
Créez la ressource DataProtectionApplication pour configurer la connexion au stockage où les sauvegardes et les instantanés de volume sont stockés:
Lorsque vous utilisez uniquement des volumes CSI, déployez une application de protection des données en entrant la commande suivante:
cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws - csi nodeAgent: enable: false uploaderType: kopia EOF
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true
1 features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws - csi nodeAgent:
2 enable: false uploaderType: kopia
3 EOF
Copy to Clipboard Copied! - 1
- La ROSA prend en charge la sauvegarde interne d’image. Définissez ce champ sur false si vous ne voulez pas utiliser la sauvegarde d’image.
- 2
- Consultez la note importante concernant l’attribut nodeAgent.
- 3
- Le type de téléchargeur. Les valeurs possibles sont restiques ou kopia. Le Mover de données intégré utilise Kopia comme mécanisme de téléchargement par défaut, quelle que soit la valeur du champ uploaderType.
Lorsque vous utilisez des volumes CSI ou non CSI, déployez une application de protection des données en entrant la commande suivante:
cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws nodeAgent: enable: false uploaderType: restic snapshotLocations: - velero: config: credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials enableSharedConfig: "true" profile: default region: ${REGION} provider: aws EOF
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true
1 backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws nodeAgent:
2 enable: false uploaderType: restic snapshotLocations: - velero: config: credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials
3 enableSharedConfig: "true"
4 profile: default
5 region: ${REGION}
6 provider: aws EOF
Copy to Clipboard Copied! - 1
- La ROSA prend en charge la sauvegarde interne d’image. Définissez ce champ sur false si vous ne voulez pas utiliser la sauvegarde d’image.
- 2
- Consultez la note importante concernant l’attribut nodeAgent.
- 3
- Le champ CredentialsFile est l’emplacement monté de l’identifiant du seau sur le pod.
- 4
- Le champ enableSharedConfig permet aux snapshotLocations de partager ou de réutiliser l’identifiant défini pour le seau.
- 5
- Utilisez le nom de profil défini dans le fichier d’identification AWS.
- 6
- Indiquez la région en tant que région AWS. Cela doit être le même que la région des clusters.
Désormais, vous êtes prêt à sauvegarder et restaurer Red Hat OpenShift Service sur les applications AWS, comme décrit dans les applications de sauvegarde.
Le paramètre d’activation de restic est défini sur false dans cette configuration, car OADP ne prend pas en charge Restic dans les environnements ROSA.
Lorsque vous utilisez OADP 1.2, remplacez cette configuration:
nodeAgent: enable: false uploaderType: restic
nodeAgent:
enable: false
uploaderType: restic
avec la configuration suivante:
restic: enable: false
restic:
enable: false
Lorsque vous souhaitez utiliser deux clusters différents pour sauvegarder et restaurer, les deux clusters doivent avoir les mêmes noms de stockage AWS S3 dans le CR de stockage en nuage et dans la configuration OADP DataProtectionApplication.
1.6.1.3. La mise à jour du rôle IAM ARN dans l’abonnement OADP Operator
Lors de l’installation de l’opérateur OADP sur un cluster ROSA Security Token Service (STS), si vous fournissez un rôle IAM incorrect Amazon Resource Name (ARN), le pod openshift-adp-controller donne une erreur. Les requêtes d’identification qui sont générées contiennent le mauvais rôle IAM ARN. Afin de mettre à jour l’objet de requêtes d’identification avec l’ARN du rôle IAM correct, vous pouvez modifier l’abonnement OADP Operator et corriger le rôle IAM ARN avec la valeur correcte. En modifiant l’abonnement OADP Operator, vous n’avez pas à désinstaller et réinstaller OADP pour mettre à jour le rôle IAM ARN.
Conditions préalables
- Il existe un service Red Hat OpenShift sur le cluster AWS STS avec l’accès et les jetons requis.
- Il a été installé OADP sur le cluster ROSA STS.
Procédure
Afin de vérifier que l’abonnement OADP a le mauvais jeu de variable d’environnement ARN rôle IAM, exécutez la commande suivante:
oc get sub -o yaml redhat-oadp-operator
$ oc get sub -o yaml redhat-oadp-operator
Copy to Clipboard Copied! Exemple d’abonnement
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: annotations: creationTimestamp: "2025-01-15T07:18:31Z" generation: 1 labels: operators.coreos.com/redhat-oadp-operator.openshift-adp: "" name: redhat-oadp-operator namespace: openshift-adp resourceVersion: "77363" uid: 5ba00906-5ad2-4476-ae7b-ffa90986283d spec: channel: stable-1.4 config: env: - name: ROLEARN value: arn:aws:iam::11111111:role/wrong-role-arn installPlanApproval: Manual name: redhat-oadp-operator source: prestage-operators sourceNamespace: openshift-marketplace startingCSV: oadp-operator.v1.4.2
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: annotations: creationTimestamp: "2025-01-15T07:18:31Z" generation: 1 labels: operators.coreos.com/redhat-oadp-operator.openshift-adp: "" name: redhat-oadp-operator namespace: openshift-adp resourceVersion: "77363" uid: 5ba00906-5ad2-4476-ae7b-ffa90986283d spec: channel: stable-1.4 config: env: - name: ROLEARN value: arn:aws:iam::11111111:role/wrong-role-arn
1 installPlanApproval: Manual name: redhat-oadp-operator source: prestage-operators sourceNamespace: openshift-marketplace startingCSV: oadp-operator.v1.4.2
Copy to Clipboard Copied! - 1
- Vérifiez la valeur de ROLEARN que vous souhaitez mettre à jour.
Actualisez le champ ROLEARN de l’abonnement avec le rôle correct ARN en exécutant la commande suivante:
oc patch subscription redhat-oadp-operator -p '{"spec": {"config": {"env": [{"name": "ROLEARN", "value": "<role_arn>"}]}}}' --type='merge'
$ oc patch subscription redhat-oadp-operator -p '{"spec": {"config": {"env": [{"name": "ROLEARN", "value": "<role_arn>"}]}}}' --type='merge'
Copy to Clipboard Copied! là où:
<role_arn>
- Indique le rôle IAM ARN à mettre à jour. Arn:aws:iam::160….6956:role/oadprosa…..8wlf.
Assurez-vous que l’objet secret est mis à jour avec la valeur ARN du rôle correct en exécutant la commande suivante:
oc get secret cloud-credentials -o jsonpath='{.data.credentials}' | base64 -d
$ oc get secret cloud-credentials -o jsonpath='{.data.credentials}' | base64 -d
Copy to Clipboard Copied! Exemple de sortie
[default] sts_regional_endpoints = regional role_arn = arn:aws:iam::160.....6956:role/oadprosa.....8wlf web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
[default] sts_regional_endpoints = regional role_arn = arn:aws:iam::160.....6956:role/oadprosa.....8wlf web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
Copy to Clipboard Copied! Configurez le fichier de manifestation DataProtectionApplication (CR) comme indiqué dans l’exemple suivant:
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-rosa-dpa namespace: openshift-adp spec: backupLocations: - bucket: config: region: us-east-1 cloudStorageRef: name: <cloud_storage> credential: name: cloud-credentials key: credentials prefix: velero default: true configuration: velero: defaultPlugins: - aws - openshift
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: test-rosa-dpa namespace: openshift-adp spec: backupLocations: - bucket: config: region: us-east-1 cloudStorageRef: name: <cloud_storage>
1 credential: name: cloud-credentials key: credentials prefix: velero default: true configuration: velero: defaultPlugins: - aws - openshift
Copy to Clipboard Copied! - 1
- Indiquez le CloudStorage CR.
Créez la DataProtectionApplication CR en exécutant la commande suivante:
oc create -f <dpa_manifest_file>
$ oc create -f <dpa_manifest_file>
Copy to Clipboard Copied! Assurez-vous que le DataProtectionApplication CR est réconcilié et que l’état est défini sur "True" en exécutant la commande suivante:
oc get dpa -n openshift-adp -o yaml
$ oc get dpa -n openshift-adp -o yaml
Copy to Clipboard Copied! Exemple d’application de DataProtectionApplication
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... status: conditions: - lastTransitionTime: "2023-07-31T04:48:12Z" message: Reconcile complete reason: Complete status: "True" type: Reconciled
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... status: conditions: - lastTransitionTime: "2023-07-31T04:48:12Z" message: Reconcile complete reason: Complete status: "True" type: Reconciled
Copy to Clipboard Copied! Assurez-vous que BackupStorageLocation CR est dans un état disponible en exécutant la commande suivante:
oc get backupstoragelocations.velero.io -n openshift-adp
$ oc get backupstoragelocations.velero.io -n openshift-adp
Copy to Clipboard Copied! Exemple de BackupStorageLocation
NAME PHASE LAST VALIDATED AGE DEFAULT ts-dpa-1 Available 3s 6s true
NAME PHASE LAST VALIDATED AGE DEFAULT ts-dpa-1 Available 3s 6s true
Copy to Clipboard Copied!
1.7. Désinstaller OADP
1.7.1. Désinstallation de l’API OpenShift pour la protection des données
Désinstaller l’API OpenShift pour la protection des données (OADP) en supprimant l’opérateur OADP. Consultez Supprimer les opérateurs d’un cluster pour plus de détails.
1.8. La sauvegarde de l’OADP
1.8.1. Sauvegarde des applications
Les sauvegardes fréquentes peuvent consommer du stockage sur l’emplacement de stockage de sauvegarde. Vérifiez la fréquence des sauvegardes, le temps de conservation et la quantité de données des volumes persistants (PV) si vous utilisez des sauvegardes non locales, par exemple des seaux S3. Étant donné que toutes les sauvegardes prises restent jusqu’à expiration, vérifiez également le réglage du temps de vie (TTL) de l’horaire.
Il est possible de sauvegarder les applications en créant une ressource personnalisée de sauvegarde (CR). En savoir plus, voir Créer une sauvegarde CR.
Le Backup CR crée des fichiers de sauvegarde pour les ressources Kubernetes et des images internes sur le stockage d’objets S3.
1.8.1.1. Aperçu des ressources avant d’exécuter la sauvegarde et la restauration
L’OADP sauvegarde les ressources applicatives en fonction du type, de l’espace de noms ou de l’étiquette. Cela signifie que vous pouvez afficher les ressources une fois la sauvegarde terminée. De même, vous pouvez voir les objets restaurés en fonction de l’espace de noms, du volume persistant (PV) ou de l’étiquette après la fin d’une opération de restauration. Afin de prévisualiser les ressources à l’avance, vous pouvez effectuer un cycle sec des opérations de sauvegarde et de restauration.
Conditions préalables
- L’opérateur OADP a été installé.
Procédure
Afin de prévisualiser les ressources incluses dans la sauvegarde avant d’exécuter la sauvegarde réelle, exécutez la commande suivante:
velero backup create <backup-name> --snapshot-volumes false
$ velero backup create <backup-name> --snapshot-volumes false
1 Copy to Clipboard Copied! - 1
- Indiquez la valeur du paramètre --snapshot-volumes comme false.
Afin de connaître plus de détails sur les ressources de sauvegarde, exécutez la commande suivante:
velero describe backup <backup_name> --details
$ velero describe backup <backup_name> --details
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la sauvegarde.
Afin de prévisualiser les ressources incluses dans la restauration avant d’exécuter la restauration réelle, exécutez la commande suivante:
velero restore create --from-backup <backup-name>
$ velero restore create --from-backup <backup-name>
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la sauvegarde créée pour examiner les ressources de sauvegarde.
ImportantLa commande de création de la restauration velero crée des ressources de restauration dans le cluster. Après avoir examiné les ressources, vous devez supprimer les ressources créées dans le cadre de la restauration.
Afin de connaître plus de détails sur les ressources de restauration, exécutez la commande suivante:
velero describe restore <restore_name> --details
$ velero describe restore <restore_name> --details
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la restauration.
Il est possible de créer des crochets de sauvegarde pour exécuter des commandes avant ou après l’opération de sauvegarde. Découvrez Créer des crochets de sauvegarde.
Il est possible de planifier des sauvegardes en créant un Schedule CR au lieu d’un Backup CR. Consultez les sauvegardes de planification à l’aide de l’annexe CR.
1.8.1.2. Problèmes connus
Le service OpenShift Red Hat sur AWS 4 applique une politique d’admission de sécurité de pod (PSA) qui peut entraver la préparation des pods lors d’un processus de restauration Restic.
Ce problème a été résolu dans les versions 1.1.6 et OADP 1.2.2, il est donc recommandé aux utilisateurs de passer à ces versions.
1.8.2. Créer une sauvegarde CR
Kubernetes sauvegarde les ressources, les images internes et les volumes persistants (PV) en créant une ressource personnalisée de sauvegarde (CR).
Conditions préalables
- Il faut installer l’API OpenShift pour l’opérateur de protection des données (OADP).
- Le DataProtectionApplication CR doit être dans un état prêt.
Conditions préalables à l’emplacement de sauvegarde:
- Le stockage d’objet S3 doit être configuré pour Velero.
- Il faut avoir un emplacement de sauvegarde configuré dans DataProtectionApplication CR.
Conditions préalables à l’emplacement:
- Le fournisseur de cloud doit disposer d’une API instantanée native ou prendre en charge les instantanés CSI (Container Storage Interface).
- Dans le cas des snapshots CSI, vous devez créer un VolumeSnapshotClass CR pour enregistrer le pilote CSI.
- L’emplacement du volume doit être configuré dans DataProtectionApplication CR.
Procédure
Enregistrez les CRs de backupStorageLocations en entrant la commande suivante:
oc get backupstoragelocations.velero.io -n openshift-adp
$ oc get backupstoragelocations.velero.io -n openshift-adp
Copy to Clipboard Copied! Exemple de sortie
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
Copy to Clipboard Copied! Créez une sauvegarde CR, comme dans l’exemple suivant:
apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: hooks: {} includedNamespaces: - <namespace> includedResources: [] excludedResources: [] storageLocation: <velero-sample-1> ttl: 720h0m0s labelSelector: matchLabels: app: <label_1> app: <label_2> app: <label_3> orLabelSelectors: - matchLabels: app: <label_1> app: <label_2> app: <label_3>
apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: hooks: {} includedNamespaces: - <namespace>
1 includedResources: []
2 excludedResources: []
3 storageLocation: <velero-sample-1>
4 ttl: 720h0m0s labelSelector:
5 matchLabels: app: <label_1> app: <label_2> app: <label_3> orLabelSelectors:
6 - matchLabels: app: <label_1> app: <label_2> app: <label_3>
Copy to Clipboard Copied! - 1
- Indiquez un tableau d’espaces de noms à sauvegarder.
- 2
- Facultatif : Spécifiez un éventail de ressources à inclure dans la sauvegarde. Les ressources peuvent être des raccourcis (par exemple, «po» pour «pods») ou entièrement qualifiés. En cas d’absence de précision, toutes les ressources sont incluses.
- 3
- Facultatif : Spécifiez un éventail de ressources à exclure de la sauvegarde. Les ressources peuvent être des raccourcis (par exemple, «po» pour «pods») ou entièrement qualifiés.
- 4
- Indiquez le nom de backupStorageLocations CR.
- 5
- Carte de {key,value} paires de ressources de sauvegarde qui ont toutes les étiquettes spécifiées.
- 6
- Carte de {key,value} paires de ressources de sauvegarde qui ont une ou plusieurs des étiquettes spécifiées.
Assurez-vous que l’état de la sauvegarde CR est complété:
oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'
$ oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'
Copy to Clipboard Copied!
1.8.3. Création de crochets de sauvegarde
Lors de l’exécution d’une sauvegarde, il est possible de spécifier une ou plusieurs commandes à exécuter dans un conteneur à l’intérieur d’un pod, en fonction de la sauvegarde de la pod.
Les commandes peuvent être configurées pour être exécutées avant tout traitement d’action personnalisé (pré crochets), ou après que toutes les actions personnalisées aient été terminées et que tous les éléments supplémentaires spécifiés par l’action personnalisée aient été sauvegardés (hameçons postés).
Créez des crochets de sauvegarde pour exécuter des commandes dans un conteneur dans un pod en éditant la ressource personnalisée de sauvegarde (CR).
Procédure
Ajoutez un crochet au bloc spec.hooks du Backup CR, comme dans l’exemple suivant:
apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> excludedNamespaces: - <namespace> includedResources: [] - pods excludedResources: [] labelSelector: matchLabels: app: velero component: server pre: - exec: container: <container> command: - /bin/uname - -a onError: Fail timeout: 30s post: ...
apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace>
1 excludedNamespaces:
2 - <namespace> includedResources: [] - pods
3 excludedResources: []
4 labelSelector:
5 matchLabels: app: velero component: server pre:
6 - exec: container: <container>
7 command: - /bin/uname
8 - -a onError: Fail
9 timeout: 30s
10 post:
11 ...
Copy to Clipboard Copied! - 1
- Facultatif: Vous pouvez spécifier les espaces de noms auxquels le crochet s’applique. Dans le cas où cette valeur n’est pas spécifiée, le crochet s’applique à tous les espaces de noms.
- 2
- Facultatif: Vous pouvez spécifier les espaces de noms auxquels le crochet ne s’applique pas.
- 3
- Actuellement, les pods sont la seule ressource prise en charge à laquelle les crochets peuvent s’appliquer.
- 4
- Facultatif : Vous pouvez spécifier les ressources auxquelles le crochet ne s’applique pas.
- 5
- Facultatif: Ce crochet ne s’applique qu’aux objets correspondant à l’étiquette. Dans le cas où cette valeur n’est pas spécifiée, le crochet s’applique à tous les objets.
- 6
- Gamme de crochets à exécuter avant la sauvegarde.
- 7
- Facultatif: Si le conteneur n’est pas spécifié, la commande s’exécute dans le premier conteneur dans le pod.
- 8
- C’est le point d’entrée pour le conteneur d’init ajouté.
- 9
- Les valeurs autorisées pour le traitement des erreurs sont Fail and Continue. La valeur par défaut est l’échec.
- 10
- Facultatif: Combien de temps pour attendre que les commandes s’exécutent. La valeur par défaut est 30s.
- 11
- Ce bloc définit un tableau de crochets à exécuter après la sauvegarde, avec les mêmes paramètres que les crochets de pré-back.
1.8.4. Calendrier des sauvegardes à l’aide de l’annexe CR
L’opération de planification vous permet de créer une sauvegarde de vos données à un moment donné, spécifié par une expression Cron.
Les sauvegardes sont planifiées en créant une ressource personnalisée (CR) au lieu d’une sauvegarde CR.
Laissez suffisamment de temps dans votre calendrier de sauvegarde pour qu’une sauvegarde se termine avant la création d’une autre sauvegarde.
Ainsi, si une sauvegarde d’un espace de noms prend généralement 10 minutes, ne planifiez pas les sauvegardes plus fréquemment que toutes les 15 minutes.
Conditions préalables
- Il faut installer l’API OpenShift pour l’opérateur de protection des données (OADP).
- Le DataProtectionApplication CR doit être dans un état prêt.
Procédure
Découvrez les CRs de backupStorageLocations:
oc get backupStorageLocations -n openshift-adp
$ oc get backupStorageLocations -n openshift-adp
Copy to Clipboard Copied! Exemple de sortie
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
Copy to Clipboard Copied! Créer une annexe CR, comme dans l’exemple suivant:
$ cat << EOF | oc apply -f - apiVersion: velero.io/v1 kind: Schedule metadata: name: <schedule> namespace: openshift-adp spec: schedule: 0 7 * * * template: hooks: {} includedNamespaces: - <namespace> storageLocation: <velero-sample-1> defaultVolumesToFsBackup: true ttl: 720h0m0s EOF
$ cat << EOF | oc apply -f - apiVersion: velero.io/v1 kind: Schedule metadata: name: <schedule> namespace: openshift-adp spec: schedule: 0 7 * * *
1 template: hooks: {} includedNamespaces: - <namespace>
2 storageLocation: <velero-sample-1>
3 defaultVolumesToFsBackup: true
4 ttl: 720h0m0s EOF
Copy to Clipboard Copied!
- 1
- expression cron pour programmer la sauvegarde, par exemple 0 7 * * * pour effectuer une sauvegarde tous les jours à 7h00.Note
Afin de planifier une sauvegarde à intervalles spécifiques, entrez le <duration_in_minutes> dans le format suivant:
schedule: "*/10 * * * *"
schedule: "*/10 * * * *"
Copy to Clipboard Copied! Entrez la valeur des minutes entre les guillemets (" ").
- 2
- Gamme d’espaces de noms à sauvegarder.
- 3
- Le nom de backupStorageLocations CR.
- 4
- Facultatif: Dans la version 1.2 et ultérieure d’OADP, ajoutez la sauvegarde par défautVolumesToFsBackup: vraie paire clé-valeur à votre configuration lors de l’exécution de sauvegardes de volumes avec Restic. Dans la version 1.1 de OADP, ajoutez la paire par défautVolumesToRestic: vraie paire clé-valeur lorsque vous sauvegardez des volumes avec Restic.
Assurez-vous que l’état de l’annexe CR est terminé après l’exécution de la sauvegarde prévue:
oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
$ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
Copy to Clipboard Copied!
1.8.5. La suppression des sauvegardes
Il est possible de supprimer une sauvegarde en créant la ressource personnalisée DeleteBackupRequest (CR) ou en exécutant la commande de suppression velero comme expliqué dans les procédures suivantes.
Les artefacts de sauvegarde de volume sont supprimés à différents moments en fonction de la méthode de sauvegarde:
- Les artefacts sont supprimés dans le prochain cycle de maintenance complet, une fois la sauvegarde supprimée.
- Interface de stockage de conteneurs (CSI): Les artefacts sont supprimés immédiatement lorsque la sauvegarde est supprimée.
- Kopia: Les artefacts sont supprimés après trois cycles de maintenance complets du référentiel Kopia, une fois la sauvegarde supprimée.
1.8.5.1. La suppression d’une sauvegarde en créant un DeleteBackupRequest CR
Il est possible de supprimer une sauvegarde en créant une ressource personnalisée DeleteBackupRequest (CR).
Conditions préalables
- Exécutez une sauvegarde de votre application.
Procédure
Créer un fichier manifeste DeleteBackupRequest CR:
apiVersion: velero.io/v1 kind: DeleteBackupRequest metadata: name: deletebackuprequest namespace: openshift-adp spec: backupName: <backup_name>
apiVersion: velero.io/v1 kind: DeleteBackupRequest metadata: name: deletebackuprequest namespace: openshift-adp spec: backupName: <backup_name>
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la sauvegarde.
Appliquez le DeleteBackupRequest CR pour supprimer la sauvegarde:
oc apply -f <deletebackuprequest_cr_filename>
$ oc apply -f <deletebackuprequest_cr_filename>
Copy to Clipboard Copied!
1.8.5.2. La suppression d’une sauvegarde en utilisant le Velero CLI
Il est possible de supprimer une sauvegarde en utilisant le Velero CLI.
Conditions préalables
- Exécutez une sauvegarde de votre application.
- Le logiciel Velero CLI vous permet d’accéder au binaire Velero dans votre cluster.
Procédure
Afin de supprimer la sauvegarde, exécutez la commande Velero suivante:
velero backup delete <backup_name> -n openshift-adp
$ velero backup delete <backup_name> -n openshift-adp
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la sauvegarde.
1.8.5.3. À propos de la maintenance du référentiel Kopia
Il existe deux types d’entretien du référentiel Kopia:
- Entretien rapide
- Fonctionne toutes les heures pour maintenir le nombre de blobs d’index (n) bas. Le nombre élevé d’indices affecte négativement la performance des opérations de Kopia.
- Il ne supprime aucune métadonnées du référentiel sans s’assurer qu’une autre copie des mêmes métadonnées existe.
- Entretien complet
- Fonctionne toutes les 24 heures pour effectuer la collecte des ordures du contenu du dépôt qui ne sont plus nécessaires.
- Snapshot-gc, une tâche de maintenance complète, trouve tous les fichiers et listes d’annuaires qui ne sont plus accessibles à partir des manifestes instantanés et les marquent comme supprimés.
- La maintenance complète est une opération rentable, car elle nécessite l’analyse de tous les répertoires dans tous les instantanés qui sont actifs dans le cluster.
1.8.5.3.1. Kopia maintenance dans OADP
Les tâches repo-maintain-job sont exécutées dans l’espace de noms où OADP est installé, comme indiqué dans l’exemple suivant:
pod/repo-maintain-job-173...2527-2nbls 0/1 Completed 0 168m pod/repo-maintain-job-173....536-fl9tm 0/1 Completed 0 108m pod/repo-maintain-job-173...2545-55ggx 0/1 Completed 0 48m
pod/repo-maintain-job-173...2527-2nbls 0/1 Completed 0 168m
pod/repo-maintain-job-173....536-fl9tm 0/1 Completed 0 108m
pod/repo-maintain-job-173...2545-55ggx 0/1 Completed 0 48m
Consultez les journaux du travail repo-maintain pour plus de détails sur le nettoyage et la suppression des artefacts dans le stockage d’objets de sauvegarde. Comme indiqué dans l’exemple suivant, vous pouvez trouver une note dans l’emploi repo-maintain lorsque la prochaine maintenance complète du cycle est due:
not due for full maintenance cycle until 2024-00-00 18:29:4
not due for full maintenance cycle until 2024-00-00 18:29:4
Les trois exécutions réussies d’un cycle de maintenance complet sont nécessaires pour que les objets soient supprimés du stockage d’objets de sauvegarde. Cela signifie que vous pouvez vous attendre jusqu’à 72 heures pour que tous les artefacts du stockage d’objet de sauvegarde soient supprimés.
1.8.5.4. La suppression d’un référentiel de sauvegarde
Après que vous avez supprimé la sauvegarde, et après que les cycles de maintenance du référentiel Kopia pour supprimer les artefacts connexes sont terminés, la sauvegarde n’est plus référencée par aucune métadonnées ou objets manifestes. Ensuite, vous pouvez supprimer la ressource personnalisée (CR) de backuprepository pour terminer le processus de suppression de sauvegarde.
Conditions préalables
- La sauvegarde de votre application a été supprimée.
- Jusqu’à 72 heures après la suppression de la sauvegarde. Ce délai permet à Kopia d’exécuter les cycles de maintenance du dépôt.
Procédure
Afin d’obtenir le nom du référentiel de sauvegarde CR pour une sauvegarde, exécutez la commande suivante:
oc get backuprepositories.velero.io -n openshift-adp
$ oc get backuprepositories.velero.io -n openshift-adp
Copy to Clipboard Copied! Afin de supprimer le référentiel de sauvegarde CR, exécutez la commande suivante:
oc delete backuprepository <backup_repository_name> -n openshift-adp
$ oc delete backuprepository <backup_repository_name> -n openshift-adp
1 Copy to Clipboard Copied! - 1
- Indiquez le nom du référentiel de sauvegarde de l’étape précédente.
1.9. La restauration de l’OADP
1.9.1. La restauration des applications
Les sauvegardes d’applications sont restaurées en créant une ressource personnalisée de restauration (CR). Découvrez la création d’un CR de restauration.
Il est possible de créer des crochets de restauration pour exécuter des commandes dans un conteneur dans un pod en éditant le CR Restaurer. Découvrez Créer des crochets de restauration.
1.9.1.1. Aperçu des ressources avant d’exécuter la sauvegarde et la restauration
L’OADP sauvegarde les ressources applicatives en fonction du type, de l’espace de noms ou de l’étiquette. Cela signifie que vous pouvez afficher les ressources une fois la sauvegarde terminée. De même, vous pouvez voir les objets restaurés en fonction de l’espace de noms, du volume persistant (PV) ou de l’étiquette après la fin d’une opération de restauration. Afin de prévisualiser les ressources à l’avance, vous pouvez effectuer un cycle sec des opérations de sauvegarde et de restauration.
Conditions préalables
- L’opérateur OADP a été installé.
Procédure
Afin de prévisualiser les ressources incluses dans la sauvegarde avant d’exécuter la sauvegarde réelle, exécutez la commande suivante:
velero backup create <backup-name> --snapshot-volumes false
$ velero backup create <backup-name> --snapshot-volumes false
1 Copy to Clipboard Copied! - 1
- Indiquez la valeur du paramètre --snapshot-volumes comme false.
Afin de connaître plus de détails sur les ressources de sauvegarde, exécutez la commande suivante:
velero describe backup <backup_name> --details
$ velero describe backup <backup_name> --details
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la sauvegarde.
Afin de prévisualiser les ressources incluses dans la restauration avant d’exécuter la restauration réelle, exécutez la commande suivante:
velero restore create --from-backup <backup-name>
$ velero restore create --from-backup <backup-name>
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la sauvegarde créée pour examiner les ressources de sauvegarde.
ImportantLa commande de création de la restauration velero crée des ressources de restauration dans le cluster. Après avoir examiné les ressources, vous devez supprimer les ressources créées dans le cadre de la restauration.
Afin de connaître plus de détails sur les ressources de restauration, exécutez la commande suivante:
velero describe restore <restore_name> --details
$ velero describe restore <restore_name> --details
1 Copy to Clipboard Copied! - 1
- Indiquez le nom de la restauration.
1.9.1.2. Création d’un CR de restauration
La restauration d’une ressource personnalisée de sauvegarde (CR) en créant un CR de restauration.
Conditions préalables
- Il faut installer l’API OpenShift pour l’opérateur de protection des données (OADP).
- Le DataProtectionApplication CR doit être dans un état prêt.
- Il faut avoir un Velero Backup CR.
- La capacité de volume persistant (PV) doit correspondre à la taille demandée au moment de la sauvegarde. Ajustez la taille demandée si nécessaire.
Procédure
Créer un CR Restaurer, comme dans l’exemple suivant:
apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: backupName: <backup> includedResources: [] excludedResources: - nodes - events - events.events.k8s.io - backups.velero.io - restores.velero.io - resticrepositories.velero.io restorePVs: true
apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: backupName: <backup>
1 includedResources: []
2 excludedResources: - nodes - events - events.events.k8s.io - backups.velero.io - restores.velero.io - resticrepositories.velero.io restorePVs: true
3 Copy to Clipboard Copied! - 1
- Le nom du Backup CR.
- 2
- Facultatif : Spécifiez un éventail de ressources à inclure dans le processus de restauration. Les ressources peuvent être des raccourcis (par exemple, po pour les pods) ou entièrement qualifiés. En cas d’absence de précision, toutes les ressources sont incluses.
- 3
- Facultatif: Le paramètre de restaurationPVs peut être défini sur false pour désactiver la restauration de PersistentVolumes à partir de VolumeSnapshot of Container Storage Interface (CSI) instantanés ou à partir de snapshots natifs lorsque VolumeSnapshotLocation est configuré.
Assurez-vous que l’état de la Restauration CR est complété en entrant la commande suivante:
oc get restores.velero.io -n openshift-adp <restore> -o jsonpath='{.status.phase}'
$ oc get restores.velero.io -n openshift-adp <restore> -o jsonpath='{.status.phase}'
Copy to Clipboard Copied! Assurez-vous que les ressources de sauvegarde ont été restaurées en entrant la commande suivante:
oc get all -n <namespace>
$ oc get all -n <namespace>
1 Copy to Clipboard Copied! - 1
- Espace de noms que vous avez sauvegardé.
Lorsque vous rétablissez DeploymentConfig avec des volumes ou si vous utilisez des crochets post-restauration, exécutez le script de nettoyage dc-post-restore.sh en entrant la commande suivante:
bash dc-restic-post-restore.sh -> dc-post-restore.sh
$ bash dc-restic-post-restore.sh -> dc-post-restore.sh
Copy to Clipboard Copied! NoteAu cours du processus de restauration, les plug-ins OADP Velero réduisent les objets DeploymentConfig et restaurent les pods en tant que gousses autonomes. Ceci est fait pour empêcher le cluster de supprimer les pods restaurés DeploymentConfig immédiatement sur la restauration et pour permettre aux crochets de restauration et de post-restauration de compléter leurs actions sur les gousses restaurées. Le script de nettoyage ci-dessous supprime ces pods déconnectés et met à l’échelle tous les objets DeploymentConfig vers le nombre approprié de répliques.
Exemple 1.1. DC-restic-post-restore.sh → script de nettoyage dc-post-restore.sh
if sha256sum exists, use it to check the integrity of the file
#!/bin/bash set -e # if sha256sum exists, use it to check the integrity of the file if command -v sha256sum >/dev/null 2>&1; then CHECKSUM_CMD="sha256sum" else CHECKSUM_CMD="shasum -a 256" fi label_name () { if [ "${#1}" -le "63" ]; then echo $1 return fi sha=$(echo -n $1|$CHECKSUM_CMD) echo "${1:0:57}${sha:0:6}" } if [[ $# -ne 1 ]]; then echo "usage: ${BASH_SOURCE} restore-name" exit 1 fi echo "restore: $1" label=$(label_name $1) echo "label: $label" echo Deleting disconnected restore pods oc delete pods --all-namespaces -l oadp.openshift.io/disconnected-from-dc=$label for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}') do IFS=',' read -ra dc_arr <<< "$dc" if [ ${#dc_arr[0]} -gt 0 ]; then echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]} cat <<EOF | oc patch dc -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin spec: replicas: ${dc_arr[2]} paused: ${dc_arr[3]} EOF fi done
Copy to Clipboard Copied!
1.9.1.3. Créer des crochets de restauration
Créez des crochets de restauration pour exécuter des commandes dans un conteneur dans un pod en éditant la ressource personnalisée Restaurer (CR).
Il est possible de créer deux types de crochets de restauration:
Le crochet init ajoute un conteneur init à un pod pour effectuer des tâches de configuration avant le démarrage du conteneur de l’application.
En cas de restauration d’une sauvegarde Restic, le conteneur init d’attente restique est ajouté avant le conteneur d’entrée du crochet de restauration.
- Le crochet exec exécute des commandes ou des scripts dans un conteneur d’un pod restauré.
Procédure
Ajoutez un crochet au bloc spec.hooks de la Restauration CR, comme dans l’exemple suivant:
apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> excludedNamespaces: - <namespace> includedResources: - pods excludedResources: [] labelSelector: matchLabels: app: velero component: server postHooks: - init: initContainers: - name: restore-hook-init image: alpine:latest volumeMounts: - mountPath: /restores/pvc1-vm name: pvc1-vm command: - /bin/ash - -c timeout: - exec: container: <container> command: - /bin/bash - -c - "psql < /backup/backup.sql" waitTimeout: 5m execTimeout: 1m onError: Continue
apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace>
1 excludedNamespaces: - <namespace> includedResources: - pods
2 excludedResources: [] labelSelector:
3 matchLabels: app: velero component: server postHooks: - init: initContainers: - name: restore-hook-init image: alpine:latest volumeMounts: - mountPath: /restores/pvc1-vm name: pvc1-vm command: - /bin/ash - -c timeout:
4 - exec: container: <container>
5 command: - /bin/bash
6 - -c - "psql < /backup/backup.sql" waitTimeout: 5m
7 execTimeout: 1m
8 onError: Continue
9 Copy to Clipboard Copied! - 1
- Facultatif: Arrivée des espaces de noms auxquels le crochet s’applique. Dans le cas où cette valeur n’est pas spécifiée, le crochet s’applique à tous les espaces de noms.
- 2
- Actuellement, les pods sont la seule ressource prise en charge à laquelle les crochets peuvent s’appliquer.
- 3
- Facultatif: Ce crochet ne s’applique qu’aux objets correspondant au sélecteur d’étiquette.
- 4
- Facultatif: Timeout spécifie la durée maximale d’attente de Velero pour que les conteneurs init se terminent.
- 5
- Facultatif: Si le conteneur n’est pas spécifié, la commande s’exécute dans le premier conteneur dans le pod.
- 6
- C’est le point d’entrée pour le conteneur d’init ajouté.
- 7
- Facultatif: Combien de temps pour attendre qu’un conteneur soit prêt. Cela devrait être assez long pour que le conteneur puisse démarrer et pour que tous les crochets précédents dans le même conteneur soient terminés. Dans le cas contraire, le processus de restauration attend indéfiniment.
- 8
- Facultatif: Combien de temps pour attendre que les commandes s’exécutent. La valeur par défaut est 30s.
- 9
- Les valeurs autorisées pour le traitement des erreurs sont l’échec et la poursuite:
- Continuer: Seuls les échecs de commande sont enregistrés.
- Échec: Plus les crochets de restauration s’exécutent dans n’importe quel conteneur dans n’importe quelle gousse. Le statut de la Restauration CR sera partiellement affiné.
Lors d’une opération de restauration de système de fichiers (FSB), une ressource de déploiement faisant référence à un ImageStream n’est pas restaurée correctement. La gousse restaurée qui exécute le FSB, et le postHook est interrompu prématurément.
Cela se produit parce que, pendant l’opération de restauration, le contrôleur OpenShift met à jour le champ spec.template.spec.containers dans la ressource Déploiement avec un hachage ImageStreamTag mis à jour. La mise à jour déclenche le déploiement d’un nouveau pod, mettant fin à la gousse sur laquelle velero exécute le FSB et le crochet de restauration de poste. En savoir plus sur le déclencheur du flux d’images, voir « Triggering update on image stream changes ».
La solution de contournement de ce comportement est un processus de restauration en deux étapes:
D’abord, effectuer une restauration à l’exclusion des ressources de déploiement, par exemple:
velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.apps
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --exclude-resources=deployment.apps
Copy to Clipboard Copied! Après le succès de la première restauration, effectuez une deuxième restauration en incluant ces ressources, par exemple:
velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
$ velero restore create <RESTORE_NAME> \ --from-backup <BACKUP_NAME> \ --include-resources=deployment.apps
Copy to Clipboard Copied!
Legal Notice
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.