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.

La virtualisation de serveurs a apporté un premier niveau de réponse à ces besoins de flexibilité au sein du datacenter. Plus récemment, le cloud computing est arrivé avec son lot de promesses d’optimisations et de souplesse supplémentaire.

Au-delà des buzz générés successivement autour de ces solutions, dans quelle continuité s’inscrivent-elles et quelles différences y a-t-il entre deux concepts souvent confondus ?

Retour sur les évolutions apportées par la virtualisation 

La virtualisation système consiste à faire fonctionner sur un même serveur physique plusieurs systèmes d’exploitation en parallèle. Ceci est réalisé au travers d’un hyperviseur assurant aussi bien la virtualisation du serveur physique que celle de ses interfaces (réseau, stockage…). La virtualisation s’inscrit ainsi dans le modèle SOI comme un moyen d’implémenter une couche « ressource ».

La virtualisation permet :

• De réduire le nombre de serveurs physiques en les consolidant,
• De normaliser le socle d’hébergement des OS sous forme de VM,
• D’améliorer l’agilité en réduisant le temps de provisioning,
• De renforcer la disponibilité et la reprise d’activité en offrant des mécanismes de migration et de redémarrage automatique intégrés.

La virtualisation apporte ainsi de nombreux bénéfices qu’il reste à bien mettre en balance face à ses contraintes. En effet, il faut  noter qu’elle a tendance à augmenter la complexité de l’architecture et de son exploitation et que la facilité de création des machines virtuelles peut provoquer une prolifération des instances de serveurs. Par ailleurs, la virtualisation génère de nouvelles problématiques de sécurité  et peut être source de contentions entre les services. Enfin, mêmes virtualisées, le temps de déploiement des ressources reste conséquent.

 Le cloud computing : au-delà du buzz, un mode de consommation

Depuis 2008, parallèlement à l’évolution interne des SI est apparu le cloud computing publique, promettant un niveau supplémentaire d’agilité avec une mise à disposition très rapide de ressources élastiques et une facturation adaptée à la consommation réelle.

Malgré les promesses du cloud public, les entreprises restent aujourd’hui frileuses dans son adoption. Les freins majeurs étant  les risques de sécurité perçus (utilisation d’internet, confidentialité des données et soumission à des lois locales à l’opérateur) ainsi que la dépendance aux fournisseurs engendrée par le manque de standards.

Une notion intermédiaire est donc apparue, le cloud privé. Il a pour vocation d’amener la flexibilité du cloud public dans le SI des entreprises tout en répondant aux réticences des DSI sur la sécurité et la fiabilité des services fournis.

 De la virtualisation au cloud privé

La mise en place d’un cloud privé peut être vue comme un empilement de blocs fonctionnels mettant à disposition des utilisateurs les ressources du SI en self-service, de manière automatisée, tout en offrant un niveau de qualité de service et de sécurité calibré.

Pour obtenir une plate-forme de cloud privé interne IaaS*, les principales fonctionnalités agrégées autour d’un socle de virtualisation système  sont les suivantes :

• L’automatisation du provisioning : supprimer les actions manuelles des processus de mise à disposition de ressources ;
• L’orchestration : mettre en musique les actions sur les différents composants de la plate-forme ;
• La supervision : contrôler le bon fonctionnement et collecter les métriques d’usage ;
• L’authentification et le contrôle d’accès : gérer finement les droits d’accès aux ressources et à leur administration ;
• Le portail self-service : permettre à l’utilisateur de réaliser ses demandes de création, modifications, et éventuellement suppression de ressources ainsi qu’en consulter les informations (inventaire, facturation, utilisation…) ;
• La refacturation à l’usage : traduire les métriques d’utilisation des ressources en termes budgétaires et les basculer dans les systèmes de gestion internes ;
• Le catalogue de service : être le référentiel des caractéristiques de ce qui peut être déployé.

La majorité de ces blocs existent déjà dans les SI et sont alors adaptés à l’occasion du passage au cloud privé. Ce passage s’inscrit dans une démarche d’évolution à la suite des travaux de normalisation et standardisation, de catalogues de services, d’automatisation et mise en place de stratégies self-service dans les DSI. C’est un mouvement précurseur des grandes tendances d’automatisation globale du SI.

[Article rédigé en collaboration avec Julien Contal et Aurélien Delcros]

Pour en savoir plus sur la virtualisation et le cloud computing, consulter la synthèse Solucom : Virtualisation et cloud computing : jusqu’où aller ? 

* : Le marché du cloud privé est structuré de la même facon que le cloud publique entre SaaS, PaaS et IaaS. Ce billet traite principalement du cloud privé interne IaaS. La structuration de ce marché est décrite dans la synthèse Virtualisation et cloud computing : jusqu’où aller ? 

Cet article Cloud privé, à la recherche du Graal est apparu en premier sur RiskInsight.