Tom_48_97 🦄

Lexique :
GII : Gestion d’Infrastructure Informatique
DC : Data-center
PRA : Plan de Reprise d’Activité

Problématique :
C’est une question que je croise souvent… Comment produire un plan de sauvegarde et inclure ce dernier dans le PRA pour limiter les coûts ?

Réponse : 
Il faut prendre en compte différents éléments… Le premier étant la localisation physique des serveurs à prendre en compte. On ne peut pas avoir un PRA solide si tous les serveurs sont dans le même DC. La plus part des hébergeurs “sérieux” vous proposerons de choisir dans quel DC vous voulez tel ou tel serveur, à défaut, le minimum serait de le faire. Si un client X à un serveur A dans un DC 1, la logique voudrait que le serveur B soit hébergé dans un DC 2. Enfin, bref, ce point ne change pas la suite, mais fragilise la G2I.

Le deuxième point concerne lui, ce qui est à sauvegarder, à savoir que vous devez avoir suffisamment d’éléments pour déployer un applicatif sur un nouveau serveur. Si vous avez un doute, faites un essai, prenez un chrono et faites une installation à partir des données récupérés, voyez ce qu’il manque etc… Jusqu’à obtenir un délai jugé raisonnable. Le délai est variable selon ce que vous impose le DSI. Pour ma part, je compte 15 minutes (tout compris hors installation OS).

Maintenant que vous avez vos éléments clés, il n’y a plus qu’à !

Mise en place :
Ah… Mais je sync sur quel serveur moi ?! Qui a accès à quoi et comment ? C’est pas bien méchant à résoudre. On va aller au plus simple en admettant 3 serveurs, un A qui est le BF  (backup filer) et deux applicatifs B et C, on utilise rsync (il y a d’autres solutions bien plus poussées et sécurisées mais on admet qu’on est dans une PME voir une TPE, donc pas de sous, pas de temps !

Donc, B et C peuvent se connecter à A directement (clé autorisée) (attention, dans la mesure du possible, ne pas utiliser le ROOT !), A quant à lui, ne peut pas sans une saisie username/password.

Le plan est simple, périodiquement (à définir selon l’applicatif, 48h pour un CDN peu mis à jour et 3h pour un serveur web à trafic modéré (+/- 1M pages vues/jour). Pour ma part, sur une des infra, j’ai ce qui suit :

Infra :

• 1.5 millions de pages vues / jour,
• 72/80K téléchargement / jour,
• 1 unité App en France,
• 1 unité en sommeil en France,
• 1 unité App aux USA,
• 1 unité App en République Tchèque,
• 2 unités BF (une à Maidenhead, l’autre à Paris, A et B, avec une connexion 1Gb/s).
• Toutes les unités App ont la même distrib, la même configuration et la même gestion de l’arbo

Plan :

• Toutes les 2h (heures paires), chaque serveur (à la suite, pas en même temps) vont faire un Rsync vers le BF A,
• Toutes les 2h (heures impaires), chaque serveur (à la suite, pas en même temps) vont faire un Rsync vers le BF B.

Ce qui fait que, même si un BF tombe, j’ai toujours l’autre. Si les deux tombent, je cherche le chat noir et le pends à la panne faîtière !

Maintenant pour le PRA. Les BF ont aussi la capacité de tester si une unité est active ou non (pourrie ou pas). Si une unité est pourrie, le BF indique à l’autre BF que unité X est pourrie, informe le DSI et copie le backup N-1 sur l’unité en sommeil. De là, le service informatique n’a plus qu’à contrôler l’intégrité des données, faire quelques tests et valider la mise en prod, en ajustant les DNS le temps de la maintenance de l’unité en carafe.

Voilà, c’est rédigé à l’arrache, mais ça  a le mérite d’exister. Je le rappelle, c’est une solution à bas coûts, ne s’appliquant pas aux grandes infra, car même si fonctionnelle, il est peut probable qu’elle soit adaptée.