Technologies

Les applications résiliantes ne dispensent pas d'un PCA/PRA

---

Lors de sa réunion du 14 mars 2018, le CPI-B2B s'est demandé comme rendre les applications et les données accessibles 24/7.

PublicitéLa disponibilité des données et des applications est devenue au fil du temps de plus en plus stratégique pour les entreprises, au fur et à mesure que celles-ci devenaient dépendantes de l'informatique. Plusieurs approches existent, certaines sont apparues récemment. Mais de nouvelles approches ne disqualifient pas forcément les anciennes, par exemple avoir des applications résiliantes ne dispense pas de prévoir un plan de continuité ou de reprise d'activité (PCA/PRA). On n'est simplement pas sur le même niveau de problème.
Ce sujet a été au coeur de la réunion du CPI-B2B (Club de la Presse Informatique B2B) le 14 mars 2018. Y participaient Emmanuel Schupp (DG de Citrix France), Hugues Heuzé (Directeur France de Nutanix), Stéphane Berthaud (directeur avant-vente France chez Veeam), Mathias Robichon (directeur technique chez Netapp), Sébastien Verger (directeur technique chez Dell-MC) et Jérôme Totel (vice-président produits et ingénierie des ventes chez Data4) ainsi qu'une vingtaine de journalistes.

Revenir aux fondamentaux

Comme l'a rappelé Sébastien Verger, il ne faut pas confondre plusieurs concepts qui répondent chacun à une définition précise. Ainsi, la sauvegarde est une copie des données sur un support différent de celui employé pour la production via un logiciel spécifique qui sera également nécessaire pour récupérer les dites données. L'archivage consiste, à l'inverse, en un déplacement d'un extrait des données de production vers un autre support, en principe moins coûteux et moins performant, ces données restant directement accessibles. Si les deux premières manoeuvres sont ponctuelles, ce n'est pas le cas de la troisième : la réplication consiste à une recopie au fil de l'eau entre deux environnements, en temps réel ou en différé, en synchrone ou asynchrone.
Le snapshot, a complété Mathias Robichon, est une « photographie » des données à un instant précis. Chaque snapshot va sauvegarder les données ayant changé par rapport au snapshot précédent. De ce fait, une récupération supposera d'utiliser un outil capable de relire les métadonnées accompagnant chaque snapshot. Cette protection ne peut donc s'envisager que comme un complément aux autres, pour récupérer rapidement des données altérées. Toute mesure de préservation des données doit s'envisager avec deux indicateurs clés : le RPO (Recovery Point Objective, délai maximal admissible depuis la dernière sauvegarde, donc rythme minimal de sauvegarde) et le RTO (Recovery Time Objective, délai de récupération des données). Plus l'exigence s'accroit sur RPO et RTO, plus le coût sera évidemment élevé.

S'adapter à la nécessité business

Dès lors que l'on parle de niveaux de coûts en fonction de niveaux de services, la question de l'arbitrage surgit évidement. Or, selon les utilisateurs, la criticité peut varier. Optimiser le coût peut donc aussi passer par des niveaux de services variables selon les utilisateurs et les contextes. Classer les données dès l'origine de leur production en fonction de leur criticité est également une nécessité. Et toute préservation de données ne peut s'opérer que si et seulement les connexions réseaux sont suffisantes, sans oublier le besoin évident (mais qui nécessite comme le rappelle comme l'a fait Jérôme Totel) que l'environnement physique, les machines, soient bien disponibles et alimentées électriquement.
De plus, il s'agit bien de préserver l'ensemble des environnements, pas seulement les données au sens strict : sans application pour les utiliser, ces données ne sont guère utiles. Ce sont donc les données au sens strict et les applications qui doivent faire l'objet d'une préservation globale. Pour Stéphane Berthaud, les règles a priori pour définir ce qui doit être conservé et sous quelles modalités ne sont plus suffisantes. Une analyse des usages des données -de type analyse comportementale- avec recours à de l'IA permet seule de se protéger de nouveaux risques. Le système peut ainsi décider de réaliser un snapshot s'il détecte un événement inhabituel, par exemple si un utilisateur sort de sa routine et s'est donc peut-être fait pirater son identité. Mais le frein de cette approche réside dans le « syndrome Terminator » (on ne sait pas ce que l'IA va décider de faire ou non) et le « syndrome Kerviel » (qui est responsable si l'IA ne permet pas de récupérer ce que l'on avait décidé), selon les termes de Sébastien Verger.

PublicitéLa préservation applicative est complémentaire à celle par les infrastructures

Mais, aujourd'hui, les applications peuvent être qualifiées parfois de résilientes car elles sont capables de mixer diverses infrastructures pour stocker leurs données. Du coup, elles sont en mesure de perdre des éléments d'infrastructure (en mode cloud ou localement). Mais cette évolution technique est juste là pour compléter les autres méthodes de préservation afin d'accroître la disponibilité des données. Mais une résilience par l'infrastructure reste pertinente, à commencer, bien entendu, pour les applications davantage Legacy.
Les applications avec une architecture résiliante sont en effet minoritaires dans les SI. Et, de toutes façons, le risque est moins de défaillance technique que d'atteinte aux systèmes via des agressions. L'unanimité s'est ainsi faite sur la nécessité de conserver une logique dite « 3-2-1 ». Les données doivent exister en trois exemplaires, selon deux technologies et deux localisation, ce pour chaque lot de données. C'est ce qui est nommé l'approche « 3-2-1 ». Mettre en place cette approche -soulignons-le est d'ailleurs aujourd'hui beaucoup plus simple et souvent moins cher qu'il y a quelques années.

Article rédigé par

Bertrand Lemaire, Rédacteur en chef de CIO

Partager cet article