Recherche
Fermer cette boîte de recherche.

Mélanger l'ancien et le nouveau

Si vous n'avez pas testé vos restaurations, vous n'avez pas de sauvegardes. Tout cela est bien beau, mais dans un environnement informatique hétérogène, les systèmes dépendent les uns des autres... et parfois, certains de ces systèmes datent d'avant la virtualisation et nécessitent une attention particulière...

Il existe un dicton tiré du "Tao of Backup", écrit à l'époque de NT4 :

Croire en ses sauvegardes est une chose. Devoir les utiliser en est une autre.

Cette phrase est souvent abrégée en "Testez vos récupérations" ou "Testez vos récupérations" :

Si vous n'avez pas testé vos récupérations, vous n'avez pas de sauvegardes.

C'est bien beau, mais dans les environnements informatiques hétérogènes, les choses peuvent se compliquer. Vous pouvez utiliser SureBackup pour tester vos machines virtuelles Windows, mais qu'en est-il de votre boîtier Windows XP qui contrôle votre CNC ? De même, qu'en est-il de la machine Solaris 9 qui fait fonctionner votre oscilloscope ?

Les choses peuvent devenir encore plus délicates... que se passe-t-il si votre boîtier Solaris 9 utilise l'authentification Kerberos et exige que le contrôleur soit d'abord restauré ?

De nombreux outils modernes promettent un bouton-poussoir pour tester mes sauvegardes... ce qui est très bien, mais ils ne fonctionneront que si tous vos systèmes répondent à leurs critères. Si vous ajoutez un système physique hérité, vous vous retrouvez soudain sans protection - et c'est ce système qui est le plus susceptible de tomber en panne !

La stratégie

La première chose à faire est de déterminer comment restaurer manuellement les systèmes et les données et de documenter ce processus.

Un exemple de plan de récupération pour Solaris 9 pourrait être le suivant :

  1. Récupérer une image flar à partir d'un disque à l'aide du programme d'installation
  2. Récupérer des données à l'aide de tar à partir d'une bande
  3. Botte
  4. Exécuter des commandes de test

En revanche, un exemple de récupération de VM pourrait simplement être le suivant :

  1. Sélectionnez le plan de récupération de VM à partir de ${insérer le produit de sauvegarde ici}

Malheureusement, si la machine Solaris 9 en dépend (par exemple, elle fournit l'authentification Kerberos), vous devez les combiner. Ils doivent se trouver sur le même VLAN, démarrer dans un ordre spécifique et être testés dans l'ordre.

Un exemple de plan

Un exemple de plan pour une machine Solaris 9 connectée à un A/D sur Kerberos pourrait être le suivant :

Machine SolarisContrôleur A/D
Récupérer une image flar à partir d'un disqueImage de la VM de récupération
Récupérer des données à l'aide de tar à partir d'une bandeImage de démarrage de la VM
ATTENDEZ →Test du contrôleur A/N
Démarrage de la machine Solaris 
Test de la machine Solaris

Même dans un cas simple, nous avons une dépendance à l'égard d'un test avant le démarrage. Dans un scénario plus compliqué, nous pouvons avoir plusieurs dépendances. Par exemple, supposons que nous ayons une interface web pour l'ancienne application Solaris exécutée sur une pile LAMP :

Pile LAMP Machine Solaris Contrôleur A/D
Récupérer l'image de la VM Récupérer une image flar à partir d'un disque Récupérer l'image de la VM
  Récupérer des données à l'aide de tar à partir d'une bande Image de démarrage de la VM
ATTENDEZ → Test du contrôleur A/N
Démarrage de la machine Solaris  
ATTENDEZ → Test de l'application Solaris
Démarrage de la machine Linux  
Tester l'interface web  

Cela fonctionnera, mais il y a d'autres problèmes :

  1. Que se passe-t-il si le démarrage de la machine Solaris prend beaucoup de temps ? Ne serait-il pas préférable de le démarrer plus tôt ?
  2. Si la récupération Linux échoue au niveau du système d'exploitation, nous pourrions le découvrir sans les autres machines. Il en va de même pour la machine Solaris - et cette récupération pourrait prendre beaucoup de temps si les données proviennent d'une bande...
Pile LAMP Machine Solaris Contrôleur A/D
Récupérer l'image de la VM Récupérer une image flar à partir d'un disque Récupérer l'image de la VM
Désactiver le service web Désactiver l'application Image de démarrage de la VM
Botte Botte  
Le système d'exploitation testé est opérationnel Le système d'exploitation testé est opérationnel
  Récupérer des données à l'aide de tar à partir d'une bande
ATTENDEZ → Test du contrôleur A/N
ATTENDEZ → Test de l'application Solaris  
Activer le service web  
Tester l'interface web

Nous disposons donc désormais d'un plan qui échouera le plus tôt possible en cas d'erreur du système d'exploitation. Ce plan peut probablement être encore amélioré ; il pourrait être possible de restaurer un sous-ensemble de données pour effectuer un test d'application rapide avant le test lent, il pourrait être possible de tester (partiellement) l'interface Web de manière isolée, etc...

Exigences en matière d'automatisation

Un tel plan nécessite :

  1. Une plateforme d'orchestration avec un contrôle libre de l'approvisionnement
  2. Scripting post-récupération avant le redémarrage pour contrôler le système d'exploitation qui démarre.
  3. API pour démarrer des machines récupérées pour une variété de plates-formes
  4. Une plateforme de test avec une API

Des outils pour le travail

Une plateforme d'orchestration

Nous utilisons Jenkins pour gérer cette opération particulière car, dans notre cas, Jenkins gère également la construction du logiciel de récupération. Jenkins peut être facilement scénarisé et dispose de plugins pour les principaux fournisseurs de VM, ce qui en fait une bonne base pour de nombreuses organisations.

Script de récupération et de post-récupération

Bien entendu, nous recommandons Cristie BMR qui supporte Solaris, Linux et Windows (et AIX) et qui offre la possibilité d'écrire des scripts après la récupération. Il est toutefois possible de procéder de manière fragmentaire avec différents outils : JumpStart peut être utilisé avec Solaris et FLAR de manière très efficace, bien que cela demande un certain effort. L'écriture de scripts post-récupération d'une VM peut s'avérer délicate, mais le démarrage dans un environnement Linux en direct après la récupération de la VM fonctionnerait bien.

API pour contrôler le démarrage

Tous les hyperviseurs ont des API pour démarrer les VMs... mais qu'en est-il du kit physique ? Une solution que nous utilisons est de se connecter via un port série et d'utiliser pyserial pour orchestrer la machine.

Une plate-forme d'essai

Nous utilisons à nouveau Jenkins pour cela, mais nous exécutons des scripts à l'aide de bats. C'est un bon moyen d'écrire très rapidement quelques contrôles simples qui peuvent être affichés dans Jenkins. Cependant, une solution plus complète serait d'utiliser serverspec ou autre.

Exemple

Le plugin Jenkins "blue-ocean" offre une vue très claire de la progression d'un test : A ce stade, nous avons commencé à utiliser Cristie CBMR pour restaurer un système Solaris 9 sur du matériel physique. Une fois terminé, un court script désactivera l'application requise au démarrage et définira les paramètres réseau à utiliser au démarrage.

Le script python qui effectue cette opération :

  1. Démarrer la machine en utilisant le démarrage réseau à partir d'un serveur PXE contenant l'image CBMR.
  2. Commencer la restauration à partir de la sauvegarde du système d'exploitation

Une fois l'opération terminée, il est possible d'accéder à la machine via le réseau au lieu de la console série et d'utiliser les scripts standard de Jenkins.

Achèvement

Le pipeline n'exécute chaque étape que dans l'ordre, c'est pourquoi les étapes sont utilisées pour séparer les actions simultanées.

Il ressort clairement du plan ci-dessus que l'A/D doit être testé avant que l'application ne puisse être lancée, que l'application doit être lancée avant que le service web ne soit lancé et que le service web ne peut être testé qu'après avoir été lancé. Il est possible d'utiliser le "plugin de ressources verrouillables" pour créer un contrôle plus fin, mais cela est plus difficile et comporte plus de risques.

À la fin du test de récupération, nous obtenons la sortie suivante (considérablement raccourcie) et un fichier journal :

Résumé

Il est possible d'utiliser des outils modernes d'IC pour tester la reprise après sinistre d'anciens systèmes d'exploitation, à condition que ces outils soient compatibles :

  1. Une API pour contrôler l'environnement qui sera démarré
  2. Une API pour contrôler quand l'environnement sera démarré
  3. Crochets d'orchestration pour provisionner les environnements en vue de la récupération

De nombreux systèmes de sauvegarde n'offrent pas ces possibilités. En particulier, peu d'outils fournissent des crochets qui vous permettent de provisionner un environnement de récupération.

TBMR

TBMR a été utilisé pour la restauration des systèmes d'exploitation. Il a été conçu pour fonctionner avec Windows, Linux, Solaris et AIX :

Icône de récupération de Cristie

Nous contacter

Merci de nous avoir contactés. Nous avons bien reçu votre demande.