Scénario #31591: Sauvegarde/restauration des Images et VM Hapy 2.8.0+ - EOLE OpenNebula - Ensemble Ouvert Libre Évolutif

Scénario #31591

Sauvegarde/restauration des Images et VM Hapy 2.8.0+

Ajouté par Gilles Grandgérard il y a environ 3 ans. Mis à jour il y a presque 3 ans.

Statut:

Terminé (Sprint)

Priorité:

Normal

Assigné à:

Philippe Caseiro

Catégorie:

Version cible:

Distribution EOLE - Prestation Cadoles MEN 05-07

Début:

01/02/2021

Echéance:

19/02/2021

% réalisé:

100%

Points de scénarios:

10.0

Restant à faire (heures):

0.00 heure

Estimation basée sur la vélocité:

Release:

EOLE 2.8.0.1

Liens avec la release:

Auto

Description

Problème¶

A ce jour, les VMs Hapy ne sont pas sauvegardées. Dans le cadre d'un crash avec reprise d'activité, il serait bon que les Images et VM puissent être restaurées

Proposition¶

Il faut proposer un moyen de sauvegarde pour le répertoire /var/lib/one/datastore/

Pour chaque VM, il faut faire un snapshot (Hot?), puis copier les fichiers QCow / domain.xml

Idées :

Pour les images de VM, en cherchant rapidement je trouve un script de sauvegarde qcow2.
Ainsi que des discussions sur le forum

Solutions à mettre en œuvre¶

EOLE >= 2.8.0
Documenter la fonctionnalité dans la doc 2.8 (ici ?)

Critères d’acceptation¶

Sauvegarder un Hapy avec une VM active
ré instancier une nouvelle VM Hapy, restaurer la sauvegarde de base de donnée
restaurer les Images et VM
Dans ONE, les VM démarre

Sous-tâches

Demandes liées

Historique

#1 Mis à jour par Gilles Grandgérard il y a environ 3 ans

Copié depuis Scénario #30588: Sauvegarde/restauration Hapy 2.8.0+ ajouté

#2 Mis à jour par Gilles Grandgérard il y a environ 3 ans

Description mis à jour (diff)

#3 Mis à jour par Gilles Grandgérard il y a environ 3 ans

Points de scénarios mis à 10.0

#4 Mis à jour par Emmanuel GARETTE il y a environ 3 ans

Assigné à mis à Philippe Caseiro

#5 Mis à jour par Gilles Grandgérard il y a environ 3 ans

Vu pendant la Visio :

- ne pas mettre le code dans eole-one-master
- Créer un projet REDMINE eole-one-backup contenant l'EOLElisation
- Créer un projet one-backup contenant le code OpenNebula permettant le backup.
- Proposer un paquet dès la version 2.7.2

TODO:
- Prévoir la doc

#6 Mis à jour par Daniel Dehennin il y a environ 3 ans

Projet changé de Distribution EOLE à EOLE OpenNebula

#7 Mis à jour par Daniel Dehennin il y a environ 3 ans

Le script de sauvegarde ne semble pas fonctionner correctement :

root@grichka:~# onebck 
Traceback (most recent call last):
    1: from /usr/bin/onebck:30:in `<main>'
/usr/bin/onebck:30:in `require_relative': cannot load such file -- /usr/lib/one/backup (LoadError)

#8 Mis à jour par Daniel Dehennin il y a environ 3 ans

Lié à Tâche #31706: Valider le scénario Sauvegarde/restauration des Images et VM Hapy 2.8.0+ ajouté

#9 Mis à jour par Daniel Dehennin il y a environ 3 ans

Je reprends un commentaire du scénario de validation:

Je viens de faire un test qui est allé jusqu’au bout :

root@grichka:~# time onebck 
/mnt/sauvegardes
Saving unused (if needed) and non persistent images

real    118m43,675s
user    8m13,074s
sys    5m7,580s

Lors de la sauvegarde d’une VM, celle-ci n’est pas suspendue/arrêtée, j’ai fait un autre test avec qemu-guest-agent et c’est la même chose.

Il y a donc toujours des écritures sur les disques pendant la sauvegarde ce qui peut engendrer des sauvegardes invalides (à minima un fsck).

/mnt/sauvegardes/
└── [4.0K]  one
    └── [4.0K]  datastores
        ├── [4.0K]  0
        ├── [4.0K]  1
        ├── [4.0K]  100
        │   ├── [4.0K]  8
        │   │   ├── [1.9K]  deployment.0
        │   │   └── [  60]  disk.0 -> /var/lib/one/datastores/101/ce93f817cbbacfb33901156a39ea2fbd
        │   └── [4.0K]  9
        │       ├── [1.8K]  deployment.0
        │       ├── [  60]  disk.0 -> /var/lib/one/datastores/101/79d42822d54e341ecd542f60e511f8e9
        │       └── [  60]  disk.1 -> /var/lib/one/datastores/101/0d8067e2788695d02d139670cf03f8b0
        ├── [4.0K]  101
        │   ├── [ 63G]  0d8067e2788695d02d139670cf03f8b0
        │   ├── [193K]  1cc415bbd8d5faa18fec1aebd76e1ace
        │   ├── [ 22G]  79d42822d54e341ecd542f60e511f8e9
        │   ├── [4.3G]  9aaae78209c0ada7d1226e04603c2484
        │   └── [7.8G]  ce93f817cbbacfb33901156a39ea2fbd
        └── [4.0K]  102
            ├── [1.5G]  4701303683d94e4f7abaafd05de3e814
            └── [1.4G]  850babac1e90781d39003b6d19ba5e7f

9 directories, 12 files

/var/lib/one/datastores/
├── [4.0K]  0
├── [4.0K]  1
├── [4.0K]  100
│   ├── [4.0K]  8
│   │   ├── [1.9K]  deployment.0
│   │   └── [  60]  disk.0 -> /var/lib/one/datastores/101/ce93f817cbbacfb33901156a39ea2fbd
│   └── [4.0K]  9
│       ├── [1.8K]  deployment.0
│       ├── [  60]  disk.0 -> /var/lib/one/datastores/101/79d42822d54e341ecd542f60e511f8e9
│       └── [  60]  disk.1 -> /var/lib/one/datastores/101/0d8067e2788695d02d139670cf03f8b0
├── [4.0K]  101
│   ├── [ 63G]  0d8067e2788695d02d139670cf03f8b0
│   ├── [193K]  1cc415bbd8d5faa18fec1aebd76e1ace
│   ├── [ 22G]  79d42822d54e341ecd542f60e511f8e9
│   ├── [4.3G]  9aaae78209c0ada7d1226e04603c2484
│   └── [7.8G]  ce93f817cbbacfb33901156a39ea2fbd
├── [4.0K]  102
│   ├── [1.5G]  4701303683d94e4f7abaafd05de3e814
│   └── [1.4G]  850babac1e90781d39003b6d19ba5e7f
└── [4.0K]  2

8 directories, 12 files

La sauvegarde du Scribe avec 2 disques (40Go et 500Go)¶

disque 0 : 22Go réels sur 40Go

Sauvegarde du disque prend presque 20 minutes (temps entre HOTPLUS_SAVEAS et RUNNING)

==> /var/log/one/9.log <==
Mon Mar 15 13:28:01 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS
Mon Mar 15 13:47:40 2021 [Z0][VM][I]: New LCM state is RUNNING

La copie du disque dans /mnt/sauvegardes/ et la vérification de sa somme de contrôle prend environ 7 minutes (temps entre le RUNNING et le HOTPLUG_SAVEAS suivant)

==> /var/log/one/9.log <==
Mon Mar 15 13:28:01 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS
Mon Mar 15 13:47:40 2021 [Z0][VM][I]: New LCM state is RUNNING
Mon Mar 15 13:54:15 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS

disque 1: 63Go réels sur 500Go

Sauvegarde du disque prend plus d’une heure (temps entre HOTPLUS_SAVEAS et RUNNING)

==> /var/log/one/9.log <==
Mon Mar 15 13:54:15 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS
Mon Mar 15 15:01:52 2021 [Z0][VM][I]: New LCM state is RUNNING

La copie du disque dans /mnt/sauvegardes/ et la vérification de sa somme de contrôle prend environ 22 minutes (temps entre le retour du RUNNING du scribe et le HOTPLUG_SAVEAS de l’Amon)

==> /var/log/one/9.log <==
Mon Mar 15 13:54:15 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS
Mon Mar 15 15:01:52 2021 [Z0][VM][I]: New LCM state is RUNNING

==> /var/log/one/8.log <==
Mon Mar 15 15:22:44 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS

La sauvegarde de l’Amon avec 1 disque de 40Go¶

disque 0 : 7,9Go réels sur 40Go
- Sauvegarde du disque prend presque 1 minutes (temps entre HOTPLUS_SAVEAS et RUNNING)
```
==> /var/log/one/8.log <==
Mon Mar 15 15:22:44 2021 [Z0][VM][I]: New LCM state is HOTPLUG_SAVEAS
Mon Mar 15 15:23:56 2021 [Z0][VM][I]: New LCM state is RUNNING
```
- La copie du disque dans /mnt/sauvegardes/ et la vérification de sa somme de contrôle prend un peu plus d’une minutes (temps évaluer avec une une commande en console)

#10 Mis à jour par Daniel Dehennin il y a environ 3 ans

En fait, les cliché à chaud peuvent bénéficier du qemu-agent pour geler le système de fichier pendant le snapshot mais à priori pas la création d’une nouvelle image.

Il faut donc que l’on revoit la procédure qui ne produit que des images cassées dans les tests que j’ai réalisé.

#11 Mis à jour par Daniel Dehennin il y a presque 3 ans

La sauvegarde sur grichka se passe correctement lorsque les VM sont suspendues.

Est-il possible de les remettre en route une fois la sauvegarde terminées ?

#12 Mis à jour par Daniel Dehennin il y a presque 3 ans

En revanche, la restauration ne fonctionne pas

root@grichka:~# onerst 
Restoring vm 13 from /mnt/sauvegardes/one/datastores/100/13
No such file or directory @ rb_sysopen - 
/usr/lib/ruby/2.7.0/digest.rb:50:in `initialize'
/usr/lib/ruby/2.7.0/digest.rb:50:in `open'
/usr/lib/ruby/2.7.0/digest.rb:50:in `file'
/usr/lib/ruby/2.7.0/digest.rb:35:in `file'
/usr/lib/ruby/vendor_ruby/one/restore/vm.rb:88:in `block in restore'
/usr/lib/ruby/2.7.0/find.rb:49:in `block (2 levels) in find'
/usr/lib/ruby/2.7.0/find.rb:48:in `catch'
/usr/lib/ruby/2.7.0/find.rb:48:in `block in find'
/usr/lib/ruby/2.7.0/find.rb:43:in `each'
/usr/lib/ruby/2.7.0/find.rb:43:in `find'
/usr/lib/ruby/vendor_ruby/one/restore/vm.rb:66:in `each'
/usr/lib/ruby/vendor_ruby/one/restore/vm.rb:66:in `restore'
/usr/bin/onerst:174:in `block in <main>'
/usr/bin/onerst:173:in `each'
/usr/bin/onerst:173:in `<main>'

#13 Mis à jour par Philippe Caseiro il y a presque 3 ans

Daniel Dehennin a écrit :

La sauvegarde sur grichka se passe correctement lorsque les VM sont suspendues.

Est-il possible de les remettre en route une fois la sauvegarde terminées ?

Elles devraient repartir après la sauvergarde. Je vais retester chez moi.

#14 Mis à jour par Daniel Dehennin il y a presque 3 ans

Sur grichka Hâpy 2.8.1 :

sauvegarde d’un amon et d’un scribe en mode persistant OK (après avoir installé ruby-rsync qui manque en dépendance)
restauration des VMs, les diagnoses sont OK après la restauration (la restauration n’utilise pas rsync en revanche).

oneadmin@grichka:~$ time onerst
Restoring vm 13 from /mnt/sauvegardes/one/datastores/100/13
Restoring vm 15 from /mnt/sauvegardes/one/datastores/100/15

real    70m1,275s
user    16m33,001s
sys     6m18,995s

#15 Mis à jour par Gilles Grandgérard il y a presque 3 ans

Statut changé de Nouveau à Terminé (Sprint)

#16 Mis à jour par Joël Cuissinat il y a presque 3 ans

Release mis à EOLE 2.8.0.1

Formats disponibles : Atom PDF

	Lié à Distribution EOLE - Tâche #31706: Valider le scénario Sauvegarde/restauration des Images et VM Hapy 2.8.0+	Fermé	26/04/2021	26/04/2021
	Copié depuis Distribution EOLE - Scénario #30588: Sauvegarde/restauration Hapy 2.8.0+	Terminé (Sprint)	01/02/2021	19/02/2021

Projet

Général

Profil

Distribution EOLE » Modules » EOLE OpenNebula

Demandes

Rapports personnalisés