PRA, PCA, haute disponibilité : quelles différences ?

Côté clients, si la notion de PRA semble plus souvent employée que celle de PCA, au fil des conversations, une différence émerge bien entre les deux notions. Là où le PCA couvre une approche globale d’identification des risques, d’évaluation des impacts et de formalisation des objectifs de disponibilité, le PRA se concentre lui sur les modalités de rétablissement et les moyens à allouer à cette fin. Voilà pourquoi le PRA est souvent perçu comme un sous-ensemble du PCA. Si certains associent directement le PRA à de la sauvegarde, d’autres raisonnent d’emblée « bascule de datacenter ». C’est aussi notre cas chez Oxeva : que l’on parle PRA ou PCA, nous pensons systématiquement « approche multi-datacenters ».

PCA et PRA : de la théorie à la pratique

Rappelons toutefois que les enjeux couverts par un PCA ne se résument pas à ceux de l’infrastructure IT. Assurer la continuité de l’activité de l’entreprise, c’est se préparer à tous les types de sinistres : ceux qui peuvent affecter l’infrastructure informatique mais aussi les bureaux, les stocks, les moyens de locomotion, etc. Le PCA, qui s’étend donc à l’ensemble des process et collaborateurs, est d’ailleurs souvent porté par la direction générale et non seulement par la DSI.

En résumé, le PCA vise à assurer la haute disponibilité du système global de production de l’entreprise, dont l’infrastructure IT est une des composantes, et donc à le mettre à l’abri d’une interruption. Le PRA s’inscrit quant à lui dans un scénario où l’interruption a bien eu lieu. Il s’attache davantage à prévoir des modalités de reprise du système d’information, parfois en mode dégradé, le temps de réunir les conditions avant un retour à la normale.

Deux indicateurs clés : RTO et RPO

Pour l’infrastructure IT, une règle s’impose : s’adosser à des datacenters distincts afin de disposer d’une copie des données dans un lieu distinct du site de production. Ce principe posé, les moyens techniques engagés à travers le PRA devront être en adéquation avec les objectifs formalisés dans le PCA.

C’est là que deux indicateurs clés entrent en jeu : le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective). Le RTO désigne le temps maximal d’interruption qu’une entreprise peut tolérer. Un temps qui, sans surprise, dépend de l’activité de chacun. Un e-commerçant pourra difficilement accepter plusieurs heures d’interruption en plein pic de ventes (soldes, achats de Noël) là où d’autres s’en accommoderont bien plus facilement. Le dimensionnement du PRA, et son budget, suit de manière très linéaire les risques – entendez : la perte financière – associés à une interruption des activités.

Doubler l’infrastructure pour assurer sa haute disponibilité ?

Ce RTO influence directement l’architecture technique recommandée dans le cadre du PRA. Au-dessus de 2 heures, seules les données sont répliquées sur plusieurs datacenters ; en dessous de 2 heures, c’est toute l’architecture applicative qui doit être conçue avec des ressources actives sur plusieurs datacenters.  Sans surprise, peu d’entreprises peuvent accepter de financer une infrastructure qui « tourne à vide ». Voilà pourquoi certaines décident de fonctionner 6 mois sur l’infrastructure A et 6 mois sur l’infrastructure B. Une manière d’améliorer le retour sur investissement et de s’assurer que les 2 infrastructures sont pleinement opérationnelles.

Une autre solution, que nous maîtrisons chez Oxeva, consiste à opter pour un découpage plus fin, en ne raisonnant plus seulement infrastructure mais aussi architecture applicative. Cette approche permet d’identifier les composants pour lesquels une redondance s’avère pertinente.

Reste la question du RPO, autrement dit, du dernier point de sauvegarde acceptable. Bien sûr, la perte intégrale des données est inacceptable. Mais, dans le cas d’un incident, quel est le niveau de fraicheur des données à garantir ? Chez Oxeva, nous assurons une fraicheur minimale de 1 heure mais cela peut descendre à quelques secondes si l’activité l’exige. En revanche, pas de magie : une telle exigence pèse forcément sur la performance. En d’autres termes, il s’avère impossible d’assurer à la fois une haute disponibilité ET une haute performance ET zéro perte de données. Nous pouvons répondre simultanément à deux de ces exigences mais pas aux trois. La nature même de l’infrastructure IT impose de choisir.

Des données répliquées et… restaurables ?

Ce questionnement mené, analyse de risques à l’appui, encore faut-il s’assurer que les données répliquées sont bel et bien restaurables. Même aujourd’hui, la question est loin d’être anodine. Pour un hébergeur, la réponse passe la plupart du temps par une réplication brute des données. Malheureusement, cette réplication brute ne suffit pas toujours à garantir que les données sont effectivement restaurables et dans un temps raisonnable. Et ce sujet illustre bien la différence entre hébergeur et infogéreur.

En tant qu’infogéreur, Oxeva fait en effet le choix de s’investir dans la connaissance des applicatifs de ses clients. Et dans le cadre d’un d’un PRA, cette connaissance nourrit un objectif clair : se mettre en capacité, si le besoin client l’exige, de répliquer les données de manière spécifique pour une technologie donnée (par exemple pour un système de base de données précis). Cette réplication pensée applicatif par applicatif – et non de manière générique au niveau de l’infrastructure – contribue à garantir l’intégrité de la restauration. Elle permet aussi de raisonner sur des mailles plus fines pour penser la disponibilité globale de l’architecture.

En réponse au PCA formalisé par un client, Oxeva peut émettre différentes recommandations. Y compris celles qui correspondent à des exigences élevées et supposent une grande maîtrise de l’applicatif. Ces scénarios en main, le client est ainsi en mesure d’arbitrer entre exigences et coûts. Objectif : l’accompagner pour sélectionner le PRA qui lui correspond vraiment.