fbpx
skip to Main Content

reprise après sinistre dans le cloudEn parcourant les chaînes d’information, vous vous rendrez compte qu’une catastrophe peut frapper à tout moment. Les phénomènes météorologiques extrêmes, les tremblements de terre, les incendies, les pannes de courant à grande échelle : ces scénarios et d’autres menaces peuvent perturber votre système informatique ainsi que votre entreprise. Le domaine de la reprise après sinistre (RS) a évolué pour relever le défi d’assurer un rétablissement rapide et la poursuite des opérations en cas de sinistre. De nos jours, le cloud a changé la nature et le potentiel de la reprise après sinistre. Les nouvelles avancées en matière de reprise après sinistre dans le cloud nécessitent de nouvelles pratiques. En outre, des approches totalement nouvelles, telles que les zones de disponibilité, peuvent potentiellement entraver l’ensemble du processus de réflexion sur la meilleure façon de protéger une entreprise contre un sinistre.

L’évolution de la reprise après sinistre à l’ère du cloud

La sécurité de l’information (InfoSec) traditionnelle en matière de reprise après sinistre se composait de trois (ou quatre) approches standard permettant au système informatique de rester opérationnel en cas de panne. Du point de vue d’InfoSec, ce qui causait la panne importait peu. Ce qui importait, c’était la possibilité de remettre les applications et les données en ligne dans un délai répondant aux attentes de l’entreprise.

Les trois approches de base étaient la « salle blanche », le « centre de relève » et le « centre de relève immédiate ». Une salle blanche était simplement un endroit distinct de l’emplacement de l’entreprise, où l’on trouvait du matériel informatique et des logiciels sur une étagère. En cas de sinistre, vous pouviez vous rendre à la salle blanche, installer l’équipement, le logiciel, charger les données sauvegardées sur bandes et mettre les services informatiques à la disposition des utilisateurs. Le centre de relève quant à lui disposait du matériel et des logiciels, mais n’était pas en fonctionnement. Le centre de relève immédiate avait tout en place et fonctionnait comme une réplique exacte de vos systèmes en direct, de sorte qu’il y aurait très peu de temps d’arrêt pour la restauration.

Des trois, le centre de relève immédiate offrait l’objectif de temps de récupération (RTO) le plus rapide. Une quatrième option était connue sous le nom de « centre miroir », qui fonctionnait en parallèle avec l’instance principale du logiciel et des données qu’il protégeait. Il avait peut-être une fraction de seconde de retard, mais il s’agissait essentiellement d’un jumeau parfait de l’infrastructure informatique. Vous pouviez basculer vers un centre miroir en quelques secondes, assurant ainsi un service pratiquement ininterrompu. Le centre miroir, bien sûr, était la plus chère des options, suivi du centre de relève immédiate, puis centre de relève, puis salle blanche, par ordre décroissant de dépenses. Les charges de travail informatiques les plus urgentes ont été allouées aux centres miroirs ou aux centres de relève immédiate.

Le cloud a complètement transformé le paradigme traditionnel InfoSec de reprise après sinistre salle blanche / centre de relève / centre de relève immédiate / centre miroir. Grâce à ses capacités de stockage et de calcul sans limites et à configuration rapide, un fournisseur de cloud public peut réduire considérablement le coût d’un centre miroir jusqu’alors très cher. Il devient beaucoup plus facile et moins coûteux d’exécuter des versions jumelées d’applications centrales sur plusieurs sites, en parallèle.

Même pour des tâches de reprise après sinistre moins complexes, le cloud change la donne. La sauvegarde et la réplication des données, par exemple, sont beaucoup plus simples et moins coûteuses dans le cloud que dans les architectures RS traditionnelles sur site. Ces avancées, toutefois, ne modifient pas les principes fondamentaux de la RS. Qui plus est, les options de reprise après sinistre dans le cloud plus rapides et moins coûteuses ont davantage incité les responsables RS à déterminer les charges de travail qui méritent de nouveaux niveaux de protection plus élevés et celles qui ne le méritent pas.

Stratégie de reprise après sinistre dans le cloud

La stratégie de reprise après sinistre ne change pas radicalement avec l’arrivée du cloud dans la donne, mais de nouveaux facteurs doivent être pris en compte. Votre stratégie de reprise après sinistre dans le cloud doit rester orientée métier, reflétant les priorités de l’entreprise et son modèle opérationnel. Par exemple, si le système SAP-ERP requiert le RTO le plus rapide, cet objectif de stratégie RS reste inchangé même si le RS se déroule dans le cloud.

À l’instar de ses incarnations précédentes, la stratégie RS dans le cloud devrait s’aligner sur le plan de continuité d’activité le plus général. Après tout, l’informatique n’est qu’un élément d’une entreprise. En cas de sinistre, une entreprise doit pouvoir fonctionner à tous les niveaux, pas seulement en termes d’informatique. Cela comprend les personnes, les installations, la tenue des registres, la chaîne d’approvisionnement, la logistique, et ainsi de suite. Le plan de continuité des activités tiendra compte de tous ces éléments.

Le nouvel univers des cybermenaces a également changé l’équation de la reprise après sinistre. La cybernétique représente un nouveau type de catastrophe, qui est sans doute plus difficile à gérer qu’un phénomène naturel. Bien qu’un ouragan puisse détruire un centre de données, les vents violents ne corrompront pas vos données ni ne les conserveront contre rançon. La stratégie de reprise après sinistre dans le cloud doit englober des mesures de sécurité visant à préserver les systèmes de sauvegarde et les données des logiciels malveillants et à les protéger des cybermenaces.

Zones de disponibilité du cloud

Le cloud a créé une nouvelle option pour la reprise après sinistre appelée zone de disponibilité dans le cloud. En y regardant de plus près, vous pouvez retrouver quelques éléments familiers de la RS traditionnelle. Pourtant, c’est aussi très novateur et inédit.

Qu’est-ce qu’une zone de disponibilité ?

Une zone de disponibilité est un groupe logique de ressources qui maintiennent une séparation physique au sein d’un centre de données ou, dans le cas d’un SSFE, sur 2 ou plusieurs centres de données dans la même zone régionale. Dans le cloud public, le fait de placer un ensemble de ressources, généralement des instances, dans une zone de disponibilité signifie qu’elles obtiendront un niveau de disponibilité plus élevé, ce qui se traduira par une entente de niveau de service (ENS) supérieure garantie. S’il y a une panne sur un ensemble de ressources, les autres ressources dans la zone de disponibilité sont susceptibles de ne pas être touchées ; c’est le but premier de la zone de disponibilité.

Si vous répartissez vos instances sur plusieurs zones de disponibilité et qu’une instance échoue, vous pouvez concevoir votre application de sorte qu’une instance d’une autre zone de disponibilité puisse gérer les demandes. Il est important de noter que les instances secondaires ne sont pas des clones des instances primaires. C’est à l’application de reprendre le fonctionnement sur les instances secondaires et la connectivité à l’application doit être correctement architecturée afin que les processus et les utilisateurs puissent y accéder.

Garder les ententes de niveau de service et les coûts à l’esprit

La configuration d’une zone de disponibilité de reprise après sinistre par l’intermédiaire d’un fournisseur de cloud n’est pas aussi simple qu’il n’y paraît. En travaillant avec des entreprises qui créent des zones de disponibilité pour leurs environnements SAP, nous avons constaté qu’il était essentiel de surveiller attentivement les ententes de niveau de service. Bien que la plupart des plateformes de cloud offrent de bonnes performances, les effets de l’espace géographique et d’autres facteurs tels que le calcul de la qualité des ressources et des réseaux peuvent avoir un impact négatif sur les ENS. Les tests sont essentiels pour s’assurer que vous restez dans les limites de vos ENS dans une zone de disponibilité.

Le coût est un problème. Les ressources cloud sont généralement très économiques, mais la profondeur de calcul et de stockage dont vous avez besoin pour dupliquer un environnement SAP peut entraîner une facture cloud plus élevée que prévu. Vous devrez également prendre les dispositions nécessaires pour l’obtention d’une licence de logiciel dans la zone de disponibilité.

Le cloud hybride complique les choses aussi. Personne n’est encore 100 % SAP dans le cloud. La majorité des entreprises qui exécutent SAP dans le cloud le font sur une base hybride, en associant les instances sur site avec le cloud. Pour que les zones de disponibilité dans le cloud soient efficaces, vous devez répliquer les instances sur site dans un déploiement cloud distinct. Il faut beaucoup de travail et de simulations de reprise après sinistre pour réussir.

Sélection d’un partenaire de reprise après sinistre pour SAP

Nous avons une vaste expérience de travail avec les entreprises sur la mise en œuvre de programmes de reprise après sinistre dans le cloud. Nous comprenons les nuances des zones de disponibilité et les recommandons lorsqu’elles correspondent le mieux à votre stratégie globale d’entreprise et de reprise après sinistre.

Nick Suter, Senior SAP Basis Consultant

Nick is a Senior SAP Basis Consultant on Symmetry's consulting team, delivering expert technical day-to-day system monitoring support directly to Symmetry’s valued SAP customers. He pairs his sound technical knowledge with outstanding customer service to ensure Symmetry’s clients receive highly disciplined support and industry best practices to keep their SAP systems continuously running smoothly.