Mon petit PRA (plan de reprise d’activité) d’auto-hébergement chez CloudWatt, avec OpenStack

J’ai mis en place un petit PRA (https://fr.wikipedia.org/wiki/Plan_de_reprise_d’activité) pour mes serveurs.

C’est rigolo d’appliquer pour l’auto-hébergement les mêmes procédures qu’en entreprise. Les besoins et la mise en œuvre sont finalement assez proches.

Et ce n’est pas juste pour l’exercice : ces petits serveurs (Sheevaplug et Olinuxino A20) sont fragiles. Les filesystems sont sur des cartes SD, l’alimentation non redondée, le matériel non protégé etc. Le risque de panne est donc réel. L’idée est d’avoir un plan de secours en cas de gros problème, pour remettre en ligne le nécessaire le plus vite possible.

Et c’est chez CloudWatt que j’ai décidé de mettre mon instance de secours, en utilisant les APIs OpenStack

cloudwatt   OpenStack

Avant de basculer en PRA

Le PRA est en général un dernier recours.

En cas de panne, il faut d’abord essayer de refaire marcher l’ensemble sur site. Pour ça, on s’appuie sur du classique :

  • sauvegardes régulières (et testées de temps en temps)
  • du matériel de spare (si possible exactement le même : ça peut permettre d’y déplacer directement le filesystem)
  • pouvoir (sans trop transpirer) déplacer des services d’une machine à une autre
  • rendre les services (et serveurs) aussi indépendants les uns des autres que possible : si l’un est indisponible, il faut éviter que ça bloque les autres

Objectifs du PRA dans mon contexte d’auto-hébergement

D’abord identifier les services les plus critiques. Dans mon cas, c’est essentiellement ce blog. J’y rajouterai probablement d’autres services par la suite.

Ensuite définir les objectifs :

Ici, une « perte de données maximale » de 1j me parait largement raisonnable. Le contenu (articles + commentaires) ne bouge pas très souvent donc il y a de grandes chances de ne perdre aucune donnée en restaurant une sauvegarde à J-1.

Quant à la « durée d’interruption maximale », je ne pourrai pas faire mieux qu’1j, à moins que le problème se produise quand je suis chez moi.

Quel site externe ?

L’idée est de pouvoir basculer rapidement le blog sur un autre serveur en cas de gros problème technique. Mais où ça ?

Pour faire tourner le blog, les besoins sont assez minimalistes, et il y a plein de solutions.

Mes exigences étaient que cela soit gratuit ou très peu cher, et que je puisse facilement faire basculer dessus la résolution DNS.

Assez vite, je me suis tourné vers des clouds avec tarification à l’usage.

En effet, 99 % du temps, je n’ai pas besoin que ma machine de PRA soit en ligne. Je n’en ai besoin que dans 2 cas de figure :

  • quand je veux mettre à jour les données dessus (quelques minutes chaque jour)
  • quand je veux basculer dessus (ce qui n’arrivera que très rarement, je l’espère)

Le reste du temps, il faut éviter de payer pour rien.

Pourquoi CloudWatt ?

CloudWatt a quelques particularités qui m’ont plu :

  • Basé sur OpenStack : je préfère ne pas me lier à un cloud particulier via des APIs propriétaires. Et ce que j’apprendrai sur les APIs OpenStack pourra me servir sur d’autres clouds
  • Apparemment engagé dans le logiciel libre
  • Hébergé en France

cloudwatt

Pour ne pas payer inutilement, il faut re-créer l’instance (la VM) à chaque fois qu’on en a besoin. Évidemment, ça peut se faire programmatiquement via l’API. Et les données peuvent être persistées dans des volumes, images et snapshots (tarifés suivant l’espace disque utilisé)

Coût prévisionnel

Stockage bloc (image, snapshot ou volume) : 3Go => 0.12€HT/mois

Instance tiny (la moins puissante) : quelques minutes par jour pour la mise à jour. 6 minutes/j = 3h/mois => 0.03€HT/mois

Trafic réseau : minimum=1Go => 0.089€HT/mois

Au total : 0.239€HT/mois = un peu moins de 30 centimes TTC/mois => moins de 3€50/an. Ça parait tout à fait raisonnable.

Et, si j’utilise l’instance de PRA (ce qui devrait être très rare, et ne pas durer longtemps), ça coûte un peu moins de 30 centimes TTC par jour. Là aussi, ce n’est franchement pas exorbitant.

De plus, tout ça est gratuit jusqu’au 24 mars 2015, ce qui permet de tester sans frais.

Pourquoi pas un serveur similaire chez un autre auto-hébergé ?

Ce serait une solution radicalement différente : plutôt que de mettre son PRA dans un cloud, le mettre chez un autre auto-hébergé.

Je trouve que cette solution serait assez fun.

Mais c’était l’occasion de jouer avec CloudWatt/OpenStack, donc pas pour cette fois.

Peut-être pour la v2 ? :-)

Implémentation et méthode

Besoin : synchroniser automatiquement les données vers le serveur externe, une fois par jour.

Principe et persistance des données

Comme déjà évoqué, je n’ai pas besoin d’une instance qui tourne 24h/24, mais uniquement quelques minutes par jour (le temps d’y mettre à jour les données).

Mais comment avoir des données persistantes, et ne pas repartir à zéro à chaque fois ?

Au départ, j’avais pensé à mettre tout le filesystem (OS compris) dans un volume persistant. C’est le plus simple à mettre en œuvre mais je suis tombé sur une limitation : impossible de créer un volume persistant (basé sur Debian) de moins de 20 Go. Or je n’ai pas envie de payer pour tout cet espace alors que j’en utiliserai 10 fois moins.

Donc, solution alternative :

  • un snapshot du filesystem pour l’OS et la configuration d’Apache/MySQL : 1.3Go. Je n’aurai besoin de refaire ce snapshot que pour les mises à jour du système ou de la configuration
  • un volume persistant pour les données (avec des liens symboliques qui pointent dessus pour /var/www et  /var/lib/mysql) : 1Go. C’est là-dessus que les données seront mises à jour quotidiennement

Petit inconvénient de cette solution : si on peut attacher un volume au démarrage via l’API, on ne peut pas le faire depuis la console de gestion web. Si on n’a pas d’accès SSH/console à la machine, il faut donc créer l’instance, puis attacher l’IP et le volume, puis la rebooter.

Préparation du serveur distant

+ Création du ou des sites Apache2

+ Création du user et de la base de données MySQL

Script de sauvegarde

Création/lancement de la VM

Télécharger le fichier openrc.sh depuis votre compte CloudWatt (qui contient les identifiants), et installer le client Openstack en ligne de commande (j’ai utilisé la version en Python).

OpenStack

La VM peut être lancée par script comme suit :

Synchronisation des données

Adaptation des données pour la VM

Le fichier adaptation_donnees_pra.sh est exécuté sur le serveur distant :

Et on met tout ça dans un cron pour que ça s’exécute chaque nuit.

Problème de clé SSH regénérée pour chaque instance CloudWatt

En l’état, les scripts ci-dessus échouent à cause d’un problème de clé SSH : à chaque création d’une nouvelle instance chez CloudWatt, la clé SSH est écrasée par une nouvelle. Donc le client SSH plante en disant qu’il ne reconnaît pas la clé correspondant à l’IP.

Première (mauvaise) solution : rajouter des options à ssh/scp/rsync pour qu’ils ignorent le problème

Pour rsync, cela consiste à rajouter l’option :

(le LogLevel est nécessaire pour qu’il n’y ait pas de « Warning : Permanently added ‘x.x.x.x’ to the list of known hosts » dans la sortie d’erreur, qui génère en envoi de mail quand c’est lancé en cron)

Ca fonctionne bien, mais ouvre une belle faille de sécurité.

Meilleure solution : donner des clés SSH fixes à la création de l’instance en Customization Script / User Data

Avec OpenStack, il est possible de passer ce qu’ils appellent un « Customization Script » (autrement appelé « User Data ») à la création d’une instance.  Entre autres choses, cela permet de lui dire quelles clés SSH utiliser (au lieu qu’il les génère à la création).

Dans la VM, c’est exécuté au premier démarrage via le package cloud-init (au moins sur Debian et Ubuntu, je ne sais pas pour les autres OS)

A partir des exemples de http://cloudinit.readthedocs.org/en/latest/topics/examples.html, j’ai pu créer un fichier cloud-config.txt qui ressemble à ça (les clés SSH sont des exemples) :

Il suffit ensuite, lors de la création de l’instance avec nova boot, de rajouter l’option :

Cf http://docs.openstack.org/user-guide/content/inserting_userdata.html

Baptême par le feu et enseignements

Le 1er janvier 2015, coupure d’accès Internet chez mon FAI (défaillance du modem). Pas de bol. J’ai dû me lancer dans le PRA à marche forcée.

C’était à peu près prêt, sauf que la mise à jour des données n’était pas encore automatisée. J’ai donc dû mettre à jour les données à la main, mais en-dehors de ça, ça s’est bien déroulé.

Quels enseignements de ce premier test ?

  • Il faut prévoir comment faire la bascule en n’étant pas chez soi. D’où nécessité d’avoir accès aux identifiants/clés pour tout faire (en l’occurrence se connecter à CloudWatt et Gandi + si possible une possibilité de se logger sur la machine : clé SSH ou user/mot de passe). Mais attention à les conserver de manière sécurisée…
  • Si on bascule en PRA, il faut ensuite penser à bloquer la mise à jour quotidienne des données (sinon cela écraserait les données modifiées dans la journée)
  • Prévoir la procédure de bascule retour (fin du PRA). En l’occurrence, il s’agit simplement de re-transférer le site PHP et la base MySQL dans l’autre sens, et refaire la bascule DNS.

Contraintes

Une fois la procédure mise en place, la mise à jour se fait tous les jours, et tout est prêt pour un éventuel PRA.

Seules contraintes qui restent :

  • Tester de temps en temps une bascule, ne serait-ce que pour vérifier que les données sont à jour, que la procédure fonctionne toujours etc
  • Tenir à jour la configuration d’Apache sur l’instance de PRA, quand elle change sur sur le serveur principal

2 réflexions au sujet de « Mon petit PRA (plan de reprise d’activité) d’auto-hébergement chez CloudWatt, avec OpenStack »

  1. Bonjour,

    Bravo et merci beaucoup pour ce tutoriel :)

    Au niveau du déploiement de vos instances, vous pourriez à la place de votre script bash utiliser notre outil d’orchestration (Heat) :

    http://support.cloudwatt.com/debuter/heat-index.html
    ou en ligne de commande :
    http://support.cloudwatt.com/debuter/cli-heat-1-utiliser.html

    Dans les templates d’orchestration, il est également possible d’utiliser les User Data.

    Il existe plusieurs exemples pour déployer du WordPress dont vous pourriez vous inspirer :

    https://github.com/openstack/heat-templates/tree/master/hot/software-config/example-templates/wordpress

    Vous pouvez également faire l’inverse et utiliser Flame pour transformer une structure déployée en template d’orchestration :

    http://dev.cloudwatt.com/fr/blog/introduction-a-flame-le-generateur-de-template-automatique-pour-heat.html

    Petite nuance, Flame ne génère pas les meta data, du coup il vous faudra quand même modifier le template généré pour les insérer.

    N’hésitez pas à me contacter si vous avez des questions.

    Cordialement,

    François

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *