Un PRA pour Qui? Pourquoi?
3 Apr 2020
Dans cet article je vais évoquer la problématique du PRA dans le contexte d’une application web. Je vais dans un premier temps définir ce qu’est un PRA, voir quels éléments permettent de le définir et enfin quelles solutions techniques mettre en place.
Il sera important tout au long de la présentation de bien faire le lien avec les aspects financiers. En effet comme dans tout projet web ou IT en général, l’évolution de la technique permet des choses incroyables, il est cependant important de garder la cohérence entre la criticité et le coût d’un projet.
Un PRA qu’est ce que c’est?
Commençons effectivement par définir le terme PRA. Il s’agit d’un acronyme pour Plan de Reprise d’Activité.
C’est un document qui décrit les actions à réaliser pour assurer la continuité de service en cas de panne. Il s’agit de pouvoir répondre à la question “mais que fait on?” lorsque notre application n’est plus accessible et que la supervision clignote de partout! Le PRA doit également s’assurer que les moyens nécessaires à la continuité du service sont mis en oeuvre pour atteindre les objectifs de continuité. Ce sont surtout ces derniers que nous allons évoquer dans la suite de cet article.
Comment définir des objectifs de PRA?
Les objectifs d’un plan de reprise d’activité sont définis à partir de deux indicateurs :
- RTO pour Recovery Time Objective, en français Durée Maximale d’Interruption Admissible (DMIA)
- RPO pour Recovery Point Objective, en français Perte de Données Maximale Adminissible (PDMA)
Ils vont définir le temps que vous vous donnez pour remettre votre application en ligne mais aussi l’état dans lequel vous remettez l’application en ligne. Est-ce que vous remettez en ordre rapidement? Est-ce que vous remettez en ordre précisément?
A noter que le RTO indique le temps pendant lequel l’application devient totalement inaccessible. Il peut toutefois subsister un mode dégradé, qui serait une première réponse avant le retour en mode nominal. L’application pourrait par exemple être affiché en lecture seule, sans possibilité d’intéragir, mais avec des contenus présentés.
Dans un monde idéal, ces deux indicateurs se doivent d’être le plus court possible. Cependant il ne sera peut-être pas possible de travailler sur les deux aspects et vous serez peut être amené à en privilégier un au détriment du second. C’est la typicité de votre application et qui devra orienter vos objectifs en terme de PRA. Un outils à destination des professionnels pourra par exemple se permettre d’être indisponible en heures non ouvrées (HNO).
Pour une application donnée, les utilisateurs accepterons peut être de ne pas avoir accès à l’application pendant quelques jours, en échange d’une garantie sur l’intégrité des données, vous avez une réplication temps réel de l’application, qui prend 3 jours à remettre en marche => RTO élevé mais RPO faible.
A l’inverse, pour une autre, pour laquelle peu données sont stockées sur les serveurs, le risque de perte d’informations serait minime mais les enjeux sur la disponibilité assez forts, vous êtes capable de restaurer dans la minute une sauvegarde de la semaine précédente => RTO faible, RPO important.
Il s’agit de trouver le bon compromis entre la satisfaction des utilisateurs et les moyens à déployer pour atteindre ces objectifs. Ces deux objectifs doivent être définis en fonction de la criticité de votre application ou de votre service et surtout de la criticité qu’accordent vos utilisateurs à ce service.
On accordera qu’un service SaaS payant se devra d’avoir un RTO plus faible qu’un site de notation de restaurants.
De la même façon une panne sur une boutique en ligne peut représenter une perte de chiffre d’affaire importante et se devra d’être secourue dans les plus brefs délais.
Quels moyens pour atteindre ces objectifs?
Les moyens techniques à utiliser sont multiples et se doivent d’être adaptés aux objectifs et à l’application. Il est important de garder en vue les objectifs fixés pour déployer des moyens cohérents.
Voici quelques éléments pour lesquels l’investissement n’est pas très important et qui représentent selon moi une première approche dans la mise en place d’un PRA.
Sauvegarde
La politique de sauvegarde de l’application doit être la première ligne de votre PRA. Elle doit être régulière, a minima journalière et externalisée. C’est à dire que les fichiers de sauvegarde doivent être envoyés sur un espace de stockage extérieur à la production. Ainsi en cas de perte totale du serveur ils seront toujours accessibles.
La rétention doit être suffisamment importante pour permettre de revenir à un état stable antérieur dans le temps. Je conseille un minimum de 2 semaines, ensuite plus il est possible de stocker de données plus cela est intéressant. Un politique de la forme :
- Une sauvegarde par jour pendant 1 semaine
- Puis une sauvegarde par semaine pendant 1 mois
- Puis une sauvegarde par mois pendant 1 an
- Puis une sauvegarde annuelle
permet par exemple de remonter assez loin dans le temps, tout en économisant de l’espace disque.
Sauvegarde pluriquotidienne
Une fréquence de sauvegarde quotidienne peut toutefois ne pas être suffisante. A supposer que la sauvegarde passe la nuit, si un crash le matin serait sans conséquences, un crash en fin de journée représenterait une perte de toutes les données de la journée. En cas de RPO faible il faudra envisager d’augmenter la fréquence, en rajoutant par exemple une sauvegarde entre midi et deux, là ou la fréquentation est supposée plus faible et l’impact de la maintenance moins important.
Cela peut paraitre un détail, mais dans ce cas là il convient de compter la rétention en nombre de jours et pas en nombre de fichiers. Ainsi une rétention calculée sur 10 fichiers ne donnerai que 5 jours en réalité dans cet exemple.
Réplication de la base de données
Pour aller encore plus loin dans la fraicheur des données, il est possible de mettre en place une réplication de la base de données. Ainsi, un second serveur, appelé esclave, invisible pour l’application, sera en permanence synchronisé avec les données de production. En cas de crash du serveur maitre les derniers enregistrements seront présents sur le réplica.
Cela va bien sur complexifier l’architecture mais permettra de réduire le RTO.
Attention, en aucun cas cela ne doit remplacer une sauvegarde en bonne et due forme, une suppression maladroite sur la base de données serait reportée également sur l’esclave. Cette solution permet d’ailleurs de déporter les sauvegardes sur le serveur esclave pour ne pas impacter la production.
Utilisation d’un outil de gestion de configurations
Les outils de gestion de configuration, tels que Puppet, Ansible ou Salt, permettent de définir la configuration d’un serveur, les middleware installés (Apache, NGinx, Mysql…) mais aussi leur configuration. C’est à dire les Vhost déclaré, les limites de mémoires, les utilisateurs créés sur le serveur etc. Cela peut être un bon moyen de travailler sur le RTO.
En effet, imaginons que le disque de notre serveur tombe en panne et soit remplacé. Nous avons bien toutes les sauvegardes des données, mais le serveur est nu. L’utilisation d’un tel outil va permettre d’accélérer la réinstallation du serveur. Toute la procédure d’installation va être déroulée en un script et il n’y aura qu’à restaurer les données. Le gain de temps pour la remise en ligne du serveur est considérable.
Je détaillerais dans un prochain article l’avantage de tels outils par rapports à des scripts d’installation ou à l’utilisation de template de serveur.
Mais aussi…
Ces premières pistes permettent de travailler sur le RTO (Gestion de conf) et sur le RPO (sauvegarde/réplication) en n’utilisant que les ressources habituelles. Il est cependant possible d’aller un peu plus loin pour des applications qui seraient plus critiques. Provisionnement d’un serveur de secours
Nous avons vu que l’utilisation d’un outil de gestion de configurations permettaient d’accélérer la réinstallation du serveur une fois ce dernier remis en route. Cela peut également serveur à maintenir la configuration d’un serveur de secours.
Fonctionnement d’une IP Failover en cas de panne
Cela représente un investissement qui peut s’avérer payant en cas de panne matérielle. Il suffit de restaurer les données et d’utiliser le serveur de secours comme maître, sans avoir à attendre la remise en service du serveur principal.
L’utilisation d’adresse IP flottante,(IP FailOver ou IPFO) qui puissent être basculées d’un serveur à un autre permet de réaliser cette bascule en toute transparence. Provisionnement d’un serveur de secours chez un autre hébergeur
Il n’est malheureusement pas impossible non plus qu’un incident important impacte la totalité de l’infrastructure de votre hébergeur. La recommandation pour palier à ce cas de figure hautement improbable, mais pas impossible, est d’avoir cette fois ci une infra de secours chez un autre hébergeur.
Comme dans le cas précédent les outils de gestion de conf permettent de maintenir les serveurs à jour et les données peuvent être restaurées de manière régulière et automatique (rsync, réplication BDD) pour être prêt à basculer.
Il ne sera pas possible cependant d’avoir accès à une IPFO pour basculer entre deux hébergeur, il faudra passer par une modification des enregistrements DNS, avec les impacts en terme de propagation que cela implique. Dans le cas de la mise en place d’une telle protection il est donc recommandé de spécifier des TTL assez faibles sur la zone DNS de manière à accélérer la bascule vers la nouvelle infra.
Et surtout on teste!
On ne le répétera jamais assez, de la même façon que pour la sauvegarde, un PRA c’est bien, un PRA qui fonctionne c’est mieux!
Pour s’en assurer il n’y a pas 36 solutions, il faut tester! Programmer régulièrement des tests de PRA, vérifier que les données sont bien synchronisées sur l’infra de secours, s’assurer que les configurations sont bien à jour. Vous n’êtes pas obligé de simuler une panne, de faire une bascule réelle, mais il est possible d’aller assez loin dans le processus de test pour être certain de ne pas avoir de couac en cas de besoin.
Plus le process sera rodé et plus vous serez efficace au moment de prendre la décision de déclencher le PRA.
Un PRA qui ne sert pas
Si vous vous êtes déjà posé la question des conséquences d’un incident de production et vous avez déjà fait le premier pas pour la mise en place d’un PRA. Complétez votre réflexion avec des éléments sur ces fameux RTO et RPO, cela servira de base pour vous faire accompagner dans la mise en oeuvre des moyens techniques de votre PRA.
Et en conclusion, je préciserai que finalement, le pire dans tout ça, c’est que toute cette énergie déployée, tous ces moyens mis en place, on souhaite ne jamais avoir à s’en servir. Cela voudrait dire qu’il y a eu une panne et même bien préparé cela promet quelques sueurs froides!
Ecrit par Julien