Des sinistres de cette ampleur ont permis d’alerter les DSI sur leur exposition face aux risques naturels. La régularité et la violence de ces évènements climatiques ont poussé les entreprises à prendre des mesures pour faire face à de futures tempêtes de la dimension de «Sandy». Les leçons du passé ont-elles pour autant été retenues ? Ont-elles toutes réussi ce test grandeur nature ? si oui, comment y sont- elles parvenues ?

Les conséquences de l’ouragan « Sandy »

Annoncé comme une catastrophe majeure dans l’histoire des États-Unis, l’ouragan « Sandy » a capté l’attention de la plupart des DSI des acteurs économiques de la côte Est qui ont mobilisé leurs efforts pour déclencher leurs plans de continuité informatique. Ces PCI, mis à niveau depuis les attentats du 11 Septembre 2001, sont fondés notamment sur des procédés de géo-réplication.

Les acteurs du web et plus largement du marché du cloud sont plus enclins à communiquer sur leur capacité de reprise et à faire des retours sur les incidents subis que les entreprises traditionnelles. Les informations disponibles proviennent donc essentiellement de ces acteurs.

De nombreuses pannes d’électricité causées par la tempête, ont entraîné une indisponibilité partielle ou totale de services (Huffington Post, Gawker, Cafemon, Gizmodo, Buzzfeed, etc.) dans bon nombre de datacenters. Les hébergeurs et fournisseurs de services cloud Datagram et 75 Broad ont été indisponibles à causes d’inondations ou réserves insuffisantes de carburant pour le fonctionnement des groupes électrogènes.

« Sandy » a ainsi rendu apparente la vulnérabilité des nombreux datacenters présents dans cette zone (New York, New Jersey, et Virginie) des États-Unis. En effet, plusieurs centres de données géo-répliqués n’étaient distants que d’une centaine de kilomètres (150 datacenters) et donc dans le rayon d’impact de Sandy.

Ces dysfonctionnements mettent en exergue la nécessité, même pour des PCI bien pensés comme ceux de Wall Street, d’être mis à l’épreuve dans des conditions proches de la réalité, avant d’être jugés comme fiables.

 Des PCI à l’épreuve des ouragans

Certains opérateurs de datacenter, comme Telx, ont résisté à Sandy car ils avaient appliqué précédemment des tests simulant jusqu’au bout un sinistre. Par cette initiative, Telx a pu identifier certaines insuffisances dans son PCI comme la surchauffe de ses générateurs en mode dégradé et a donc pu limiter l’impact de Sandy.

Un cas d’école est celui de Buzzfeed qui, malgré le crash de Datagram qui hébergeait ses serveurs primaires, a réussi à réduire considérablement le temps d’indisponibilité de ses services. Cette réussite s’explique par :

• la mise en cache de la plupart de ses pages chez Akamai, le gestionnaire et diffuseur de contenu
• l’hébergement dans un second datacenter des données répliquées en temps réel.

La réplication de ces données a permis le rétablissement des services de Buzzfeed chez Amazon Web services (AWS). Quelques heures ont suffi pour assurer la migration complète des données vers AWS et ainsi basculer leur service sur les infrastructures d’Amazon. Cet exploit est à relativiser car il a nécessité la configuration manuelle d’une bonne partie du socle technique de Buzzfeed et reste donc peu applicable en l’état à un SI complexe.

Les leçons de « Sandy »

Chaque incident majeur est une façon pour les Grands Comptes d’apprendre par le réel et d’anticiper les futures catastrophes. Au-delà d’une stratégie multi-datacenters, Sandy a  mis en exergue la nécessité d’anticiper, de tester et d’adapter le PCI.

Elle a aussi révélé le cloud comme une alternative envisageable pour réaliser un PCI. Alternative que les offreurs cloud commencent à mettre en avant par le biais de leurs offres packagées de Disaster Recovery As A Service.

Les entreprises européennes et notamment françaises, qui ont moins l’occasion de mettre à l’épreuve de la réalité leur PCI, devraient néanmoins s’inspirer des retours d’expériences plus nombreux acquis par les américains. D’autant plus que les hébergeurs de cloud ne rechignent pas à communiquer sur leur stratégie PCI gagnante afin d’en faire un argument marketing. En effet, même si moins fréquentes, l’Europe n’est pas à l’abri de catastrophes équivalentes en termes d’impact à « Sandy ».

Cet article Les plans de continuité informatique des cloud à l’épreuve de l’ouragan Sandy est apparu en premier sur RiskInsight.

Le RaaS : fer de lance des « Cloud Recovery Services »

Comme pour beaucoup de ce qui tourne autour du cloud, il est parfois difficile de donner une définition précise de ce dont on parle, tant une même appellation peut cacher des offres différentes. Nous utiliserons la définition suivante : « Cloud Recovery Service => secours d’un système d’information sur une infrastructure virtualisée, hébergée par un tiers, disponible à la demande et facturée à l’utilisation. »

L’éventail des possibilités est très large :

•  d’une sauvegarde externalisée des données critiques en mode cloud (« Backup-as-a-Service ») …
•  …en passant par la construction par le client lui-même de son secours sur la base d’une prestation de type « IaaS » [2] …
•   …jusqu’à une offre complètement managée intégrant le suivi du SI nominal et des mécanismes de bascule planifiés. C’est ce type de prestations que l’on retrouve sous l’appellation « Recovery-as-a-Service ».

 Quel est l’intérêt de passer au RaaS ?

L’utilisation du RaaS résulte avant tout d’un choix économique. Sur le papier du moins, le secours paraît adapté au modèle de facturation du cloud (pas de sinistre > allocation limitée de ressources > coût d’utilisation réduit), alors qu’un secours traditionnel implique de stocker, héberger et faire évoluer des infrastructures, des serveurs et des applications sur un site de secours.

Mais à y regarder de plus près, les économies ne sont pas toujours au rendez-vous et varient grandement en fonction des applications. Si certaines d’entre elles, peu consommatrices de données, sont les candidates idéales pour le RaaS (des études indépendantes font état d’environ 80% d’économies [3] pour leur secours par rapport à l’approche traditionnelle), le ROI pour les applications plus lourdes et/ou pour lesquels les exigences de continuité sont plus fortes s’avère discutable. En effet, plus les RTO et RPO seront exigeants, plus le niveau de service devra être élevé (allocation renforcée de ressources, mécanismes de réplication des données site-à-site, liens sécurisés, supervision 24/7, etc.) entraînant une envolée des coûts à la clef.

Le RaaS s’assimile, à ce stade de sa maturité, au mieux à du « warm recovery ». En effet, il est aujourd’hui illusoire de penser que les solutions proposées permettront de la haute-disponibilité : délais d’activation, délais relatifs aux opérations de bascule notamment au niveau du réseau, délais de restauration en cas de corruption des données, etc.

En outre, le RaaS repose essentiellement sur des mécanismes de virtualisation de serveurs (le plus souvent restreints aux architectures Intel x86, à l’exception de quelques fournisseurs), que ne supportent pas tous les progiciels du marché, a fortiori les applications propriétaires des clients.

Ainsi, le fait de vouloir tirer pleinement parti de la compétitivité économique du RaaS tout en répondant aux besoins Métiers réduit son utilisation à une certaine catégorie d’applications. Ce faisant, il cantonne le RaaS en tant que solution complémentaire à un secours traditionnel, ce qui peut paradoxalement devenir une source de complexité, du fait de la cohabitation de deux SI de secours. Néanmoins, deux cas d’usage du RaaS émergent pour les organisations concernées :

•  La couverture des applications virtualisées ou éligibles à la virtualisation à coût optimisé
•  L’extension du secours à des périmètres qui n’auraient pas pu être intégrés au Plan de Continuité Informatique de l’organisation, pour une meilleure couverture au meilleur coût.

A qui s’adressent les offres RaaS ?

Étant donné son modèle économique et sa structure technique, le RaaS semble plus adapté aux moyennes structures (qui n’ont pas souvent la surface financière pour mettre en œuvre et gérer en propre un site de secours) et notamment à celles qui ont opéré la virtualisation de leur SI. Les études prospectives [4] le montrent : ce sont elles qui tireront la croissance de ce marché dans les prochaines années.

Les grandes organisations déjà dotées de Plans de Continuité Informatique seront probablement moins intéressées mais pourront néanmoins trouver dans le RaaS des réponses ciblées à certains de leurs besoins.

Le RaaS : une offre mature ?

Comme pour nombre de cloud services, le RaaS n’a pas encore atteint sa pleine maturité : en témoigne le foisonnement des offres et des prestataires notamment aux États-Unis et au Royaume-Uni. Au-delà des acteurs historiques de la continuité informatique se positionnent des pure-players des cloud recovery services et de plus en plus des hébergeurs informatiques, convertis au cloud.

Le marché se structure, les offres évoluent en recherchant notamment de la complémentarité avec les cloud services : des initiatives d’interopérabilité entre services IaaS et RaaS se font jour pour assurer du secours « cloud-to-cloud » par exemple.

A ce stade et en terme de couverture de risques, le RaaS doit faire ses preuves. Concrètement les infrastructures dévolues au RaaS reposent sur encore peu de datacenters. Le client qui souhaitera se prémunir de sinistres affectant des zones géographiques particulières (ou étendues) devra se rapprocher du fournisseur de service RaaS qui l’intéresse pour vérifier que son ou ses sites ne sont pas exposés aux mêmes risques.

En France, le marché reste jeune et sans retour d’expérience significatif de déploiement. Les grands offreurs français s’appuient, aujourd’hui, sur les infrastructures anglo-saxonnes ou nord-américaines de leur maison-mère (ce qui potentiellement impacte la qualité de service, le niveau de sécurité, les engagements contractuels, etc.). Reste donc aux acteurs, anciens comme nouveaux, à démontrer toute la pertinence de leurs offres, en particulier sur la gamme des services managés, probablement les plus recherchés par les DSI.

[1] On rencontre également l’acronyme DRaaS (Disaster Recovery-as-a-Service)

[2] IaaS : Infrastructure-as-a-Service

[3] « Disaster Recovery as a Cloud Service : Economic Benefits & Deployment Challenges »

[4] « Gartner Says 30 Percent of Midsize Companies Will Use Recovery-as-a-Service by 2014 »

Cet article Recovery-as-a-Service (RaaS) : une révolution pour le secours informatique ? est apparu en premier sur RiskInsight.