L'incendie OVH de Strasbourg : quelques remarques

L'incendie du Data Centre (DC) d'OVH rappelle ce que l'on savait déjà : tout DC peut brûler.

Cela peut être l'occasion de réfléchir aux risques des DC "entrée de gamme" et à l'adaptation des Plans de Continuités et Reprises (PCA/PRA) à ces risques. 

Photo by Cullan Smith on Unsplash

Le risque incendie existe, il faut en réduire l'impact et la vraisemblance

Le risque incendie est largement dépendant des aménagements et des pratiques sur site, citons quelques pistes :

• l'isolement des éléments à risques : un onduleur avec batteries ne doit pas être en salle mais dans un local spécial, aéré et isolé des serveurs
• une maintenance rigoureuse : s'assurer que l'intervention terminée, il ne traîne pas des cartons, des emballages, des matières inflammables...
• s'assurer aussi que les systèmes de détection incendie, si par hasard ils ont été déconnectés pour l'intervention, sont bien reconnectés et fonctionnent, intervention finie
• avoir une détection incendie efficace : avec des sondes de température, des détecteurs de fumée ou des analyseurs d'ambiance suffisamment nombreux et bien placés
• avoir un ou des systèmes d'extinction qui marchent et limitent les dégâts qu'ils feront en cas d'activation (sprinklers gaz inerte, brumisateurs d'eau, etc.)
• cloisonner les salles par des systèmes coupe-feu efficaces sur une durée suffisante (deux heures ?)

Vérifier régulièrement tout cela.

D'autres risques que l'incendie existent, comme par exemple la coupure électrique, l'inondation (proche d'un fleuve), le voisinage dangereux (Seveso), les accidents de transport de matières dangereuses près du site qui amènent à le mettre à l'arrêt, etc.

C'est une bonne pratique, avant d'implanter un DC quelque part de passer en revue les risques existants et d'aller ailleurs s'ils sont jugés trop forts.

Si les risques sont jugés limite supportables, ils doivent de toute façon être l'objet de réduction de conséquences et de vraisemblances.

PCA/PRA sont à adapter aux exigences métiers et aux risques

Après analyse, l'entreprise doit savoir quelles sont ses activités prioritaires et combien de temps il est toléré qu'elles s'arrêtent. Sachant cela, elle détermine alors combien de temps elle peut se passer des éléments matériels  informatiques et classer en catégories comme par exemple :

• Des matériels très critiques qui ne doivent pas subir d'interruptions supérieures à 10mn / 2h et qui seront donc aménagés avec des redondances de type actif-actif haute disponibilité sur deux salles disjointes en terme de risques (pas dans le même bâtiment, pas sur le même site par exemple mais assez proches pour être synchrones).
• Des matériels assez critiques qui devront pouvoir reprendre en 4h/2j et devront donc être aménagés en "secours chaud" avec des réplications assez proches capables de reprendre dans les délais exigés, à partir de points de reprises étudiés.
• Des matériels moyennement critiques qui nécessitent un redémarrage en moins d'une semaine.
• Des matériels non critiques qui peuvent être absents plus d'une semaine.

Faire une classification de ce genre est indispensable pour porter l'effort et le coût de la résilience là où c'est vraiment nécessaire.

Bien évidemment, cette analyse est à coupler avec l'appréciation des risques vus plus haut. On ne mettra pas une machine très critique dans un environnement trop risqué pour elle.

Et les données dans tout cela ?

Les machines redémarrent, certes, mais avec quelles données ?

Si le site brûle, vous redémarrez des serveurs au bout de deux jours, certes ! Mais savez-vous comment récupérer des données suffisamment fraîches ? 

Deux notions importantes interviennent alors : la réplication et la sauvegarde.

• La réplication permet de tenir à jour en continu une copie très fraîche des données ailleurs (dans une autre salle, un autre site, etc.) ; les serveurs qui continuent ailleurs accèderont à ces données
• La sauvegarde permet de prendre une photo des données à un instant précis intéressant pour redémarrer en cas de problèmes ultérieur.

Ces deux mécanismes fonctionnent très différemment et ont des usages différents. Deux exemples l'illustrent :

• Une cyber attaque commence à vous chiffrer vos données : la réplication vous produit une copie des données tout aussi chiffrées et donc inutilisable. Dans ce cas vous ne pouvez que recourir à la dernière sauvegarde avant l'arrivée de l'attaque (à condition qu'elle soit à l'abri du malware chiffreur !)
• Vous avez une panne partielle sur votre baie de disque : basculer sur la réplication vous permet de continuer sans trop de difficulté, alors que recourir à la sauvegarde vous remet en arrière (au moment de la sauvegarde) et vous perdez des données non sauvegardées.

Appliqué à l'incendie d'OVH, on voit qu'il y a un certain nombre de questions à résoudre:

• A priori le recours à des données répliquées serait utile : mais où sont-elles ? si elles sont trop proches, elles ont aussi brûlé !
• Dans ce cas, il reste les sauvegardes : mais sont-elles faites correctement ? suffisamment souvent ? et n'ont-elles pas brûlé aussi ?
• Qui doit s'en occuper (ou qui aurait dû) ? souvent la réplication et la sauvegarde sont des options dans les contrats : est-ce que le client l'a bien compris ainsi ? et OVH a-t-il bien respecté les points ci-dessus ?

En conclusion, cet incendie spectaculaire a le mérite de montrer que l'hébergement informatique ce n'est pas qu'entasser des machines qui marchent toutes seules dans un hangar ! C'est un vrai métier !