GII, PRA & Sauvegardes

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.

Leave a Reply

Your email address will not be published. Required fields are marked *