Tous les professionnels du secteur ont vu leur pire cauchemar se réaliser et soutiennent à 100% OVH dans ces moments difficiles.
L'expertise des datacenters
Une catastrophe ça arrive. La fréquence est tellement rare qu'il est difficile de se projeter, voir d'y mettre un rapport investissement/risque tellement ça semble flou. D'ailleurs pour OVH il faut rapporter ceci à leur existence, car ils ne semblent pas avoir connu de telle catastrophe en plus de 20 ans et sur environ 32 datacenters. Ils les ont tous construits, ils sont connus pour être experts et innovants en la matière, et donc ça arrive bien entendu aux meilleurs.
Avant d'aborder la question de la prévention et/ou du PRA, on peut déjà noter qu'à ce stade le choix d'un opérateur, puis en son sein d'une zone géographique, n'est pas un choix trivial. Chez Bearstech, en tant qu'exploitant de sa propre infrastructure mais également infogéreur chez des tiers comme OVH, nous avons près de 15 ans d'expertise du paysage datacentrique français et européen.
Nous avions opportunément identifié des problèmes de technique et de management chez OVH/Strasbourg et depuis nous avons pris soin de ne pas y déployer de services. Nous avons de ce fait aucun client chez OVH impacté par l'incendie.
En 15 ans de production nous avons nous-même vécu quelques coups de chaud, un de trop chez un opérateur que nous ne nommerons pas, présentant également des défauts de management, notamment de chaîne de sous-traitances - nous l'avons quitté malgré le travail dantesque de migration (physique!) de datacenter que cela impliquait.
Exploiter des datacenters n'est pas notre métier, mais être capable d'évaluer les exploitants et bien les choisir l'est ! Notre datacenter primaire est actuellement chez Scaleway, et s'il s'agit de cet opérateur et surtout de DC3 ce n'est pas un hasard. Scaleway aussi a connu des incendies, et a pu en tirer des leçons qu'il a partagées (https://blog.scaleway.com/fr/incendie-dc5/) : nous sommes ainsi nettement moins exposés aux risques industriels et gros incendies comme celui d'OVH à Strasbourg. Ce datacenter nous garantit aussi de meilleures normes de sécurité et de redondance électrique.
L'expérience de la conception
Nombre de nos clients savent qu'ils pourraient être en théorie autonomes face à leurs serveurs, les commander, les provisionner et installer leurs applications. Mais en pratique, comment prévenir et gérer les incidents, à tout heure, sans en avoir géré auparavant ?
Une grande partie de l'expertise de l'infogéreur, c'est son expérience. Il saura prévenir un maximum de risque avec le minimum de complexité et de coût. On ne peut pas prévoir tous les incidents, et surtout s'en prémunir de la même façon, il faut souvent étudier des solutions sur mesures, suivant les besoins de disponibilité, les budgets, et les technologies impliquées.
On pense souvent à l'incident matériel sur le ou les serveurs hébergeant l'application, mais le périmètre est bien plus large : le registrar, le DNS, les APIs consommées, le CDN, les loadbalancers, les VPNs, les DDoS, les débordement de capacité, etc. Savoir comment architecturer cet ensemble afin qu'il reste simple et résilient nécessite un savoir-faire qu'on acquiert qu'en "forgeant" et en exploitant. Savoir anticiper et gérer les évolutions des architectures est également une expertise clé, on ne peut pas tout jeter et recommencer à chaque fois qu'on bute sur une limite en production.
Sauvegarder et restaurer
En matière d'infogérance nous considérons qu'il y a un minimum qui n'est pas discutable :
1/ les sauvegardes : C'est pour cela que nous n'avons aucune offre d'infogérance sans sauvegarde, et ce depuis toujours. Ce n'est pas négociable, et ceci nous permet de déployer des solutions de sauvegardes massives permettant des économies d'échelle. Le corolaire est qu'il est facile de commander des sauvegardes aussi exigentes que "8 quotidennes, 4 hebdomdaires, 12 mensuelles", et vous avez la garantie que derrière une équipe s'assurera que quoi qu'il arrive, les sauvegardes fonctionnent 24x7 ;
2/ les sauvegardes distantes : l'incendie d'OVH illustre tristement leur nécessité. Un incident physique n'est pas forcément conscrit à quelques serveurs ou un bâtiment, tout un site peut être touché. Ainsi une sauvegarde n'en est pas une tant qu'elle n'est pas à une distance respectable. Chez Bearstech nous utilisons d'ailleurs une inrastructure custom chez OVH (Roubaix) pour assurer une copie des données de notre datacenter à plus de 250km ;
3/ les sauvegardes locales : optionnel, mais si vous avez un grand volume de sauvegarde (comme nous), une sauvegarde distante peut impliquer des temps de restauration qui se chiffrent en jours avec le meilleur des réseaux ! Nous gardons aussi une sauvegarde locale qui permet de restaurer beaucoup plus vite in situ, et ainsi on a à chaque instant deux sauvegardes complètes. Nous considérons qu'avoir deux copies est la norme industrielle depuis l'avènement de S3.
Par ailleurs savoir restaurer est une compétence symétrique bien souvent négligée. Nous vous encourageons à faire tout de suite un ticket à votre infogéreur et lui demander d'accéder aux données de votre serveur de la veille ou de demander si une restauration peut être programmée rapidement (sur une préprod! Ne soyez pas trop joueur...). S'il réagit rapidement, calmement et positivement comme il se doit, considérez que cela vaut tous les ISO 27001, c'est le résultat concret qui vous dit si votre business numérique survivra ou pas.
L'expertise des sauvegardes et de la résilience
Assurer la sauvegarde complète d'une application pour que sa restauration se passe bien est loin d'être une chose triviale. Il n'existe pas de solution sur l'étagère à notre connaisance.
Pour une application donnée, restaurer c'est savoir faire une sauvegarde cohérente. Ceci signifie que l'ensemble des données qui la constitue correspondent à la représentation d'un instantané du modèle de donnée de l'application. Plus pragmatiquement, c'est par exemple dans la sauvegarde et le tuple [42, "doc-important.pdf"] dans le dump SQL et le fichier doc-important.pdf dans la copie du stockage objet et du filesystem.
Cartographier l'état et la configuration d'une application n'est pas chose aisée. Par ex., auriez-vous pensé à sauvegarder puis restaurer la crontab planquée en général dans /var/spool/cron/crontabs/ ? Que l'envoi d'emails peut génerer une longue trainée de spam si vous oubliez de mettre à jour un champ DNS SPF ? La checklist peut être (très) longue et chaque détail peut mener à un restauration fail, bien entendu au pire moment.
Enfin, capturer l'état de tous les services d'une application (la configuration, le code, le dump SQL et noSQL, l'environnement DNS/CDN/TLS, etc) et en faire un état global cohérent n'est pas chose aisée. Dès que l'on dépasse le cadre balisé de quelques stacks telles que LAMP, nous avons constaté qu'il doit y avoir un dialogue entre l'infogéreur et les développeurs afin de définir une solution adaptée.
Notez qu'en ces temps d'abstraction plus élevés (Kubernetes !), beaucoup sont tentés de croire que ces problèmes ont été résolus par ces nouvelles infrastructures. Attention, il n'en est rien : ces abstractions permettent d'utiliser plus facilement des systèmes résilients, mais cette résilience n'est pas automatiquement acquise avec l'adoption de cette technologie. Les détails d'implémentation sont également importants et peuvent vous échapper (combien de clusters k8s avons-nous vu dans une unique zone...).
Conclusion : ne pas perdre de données
Ce billet n'aborde pas la problématique de la haute disponibilité, car il est relativement distinct des problématiques de sauvegardes. Une partie de l'analyse sur ce qu'est l'état d'une application est commune, mais ensuite les choix techniques et les implémentations sont en général distincts : faire une photo des données une fois par jour n'est pas la même chose qu'obtenir une copie en continu et quasi temps réel.
Par ailleurs il faut bien comprendre que sauvegarder et répliquer pour de la H-A (Haute Disponibilité) ne sont pas mutuellement exclusifs, surtout pas ! Il suffit d'imaginer le scénario où un déploiement efface par erreur des données en production (ou une attaque destructrice, etc) : le problème sera instantanément répliqué sur votre belle infrastructure super résiliente, et votre business tombe ! La sauvegarde vous prémunit de tous les incidents, alors que la réplication/H-A seulement de quelques pannes, c'est un périmètre très différent.
Nous avons donc développé un mantra précis : il ne faut pas perdre de données. En 2021, avec le prix du stockage dérisoire, et des choix technologiques en pagaille, ce n'est clairement pas une option.
L'expertise des datacenters
Une catastrophe ça arrive. La fréquence est tellement rare qu'il est difficile de se projeter, voir d'y mettre un rapport investissement/risque tellement ça semble flou. D'ailleurs pour OVH il faut rapporter ceci à leur existence, car ils ne semblent pas avoir connu de telle catastrophe en plus de 20 ans et sur environ 32 datacenters. Ils les ont tous construits, ils sont connus pour être experts et innovants en la matière, et donc ça arrive bien entendu aux meilleurs.
Avant d'aborder la question de la prévention et/ou du PRA, on peut déjà noter qu'à ce stade le choix d'un opérateur, puis en son sein d'une zone géographique, n'est pas un choix trivial. Chez Bearstech, en tant qu'exploitant de sa propre infrastructure mais également infogéreur chez des tiers comme OVH, nous avons près de 15 ans d'expertise du paysage datacentrique français et européen.
Nous avions opportunément identifié des problèmes de technique et de management chez OVH/Strasbourg et depuis nous avons pris soin de ne pas y déployer de services. Nous avons de ce fait aucun client chez OVH impacté par l'incendie.
En 15 ans de production nous avons nous-même vécu quelques coups de chaud, un de trop chez un opérateur que nous ne nommerons pas, présentant également des défauts de management, notamment de chaîne de sous-traitances - nous l'avons quitté malgré le travail dantesque de migration (physique!) de datacenter que cela impliquait.
Exploiter des datacenters n'est pas notre métier, mais être capable d'évaluer les exploitants et bien les choisir l'est ! Notre datacenter primaire est actuellement chez Scaleway, et s'il s'agit de cet opérateur et surtout de DC3 ce n'est pas un hasard. Scaleway aussi a connu des incendies, et a pu en tirer des leçons qu'il a partagées (https://blog.scaleway.com/fr/incendie-dc5/) : nous sommes ainsi nettement moins exposés aux risques industriels et gros incendies comme celui d'OVH à Strasbourg. Ce datacenter nous garantit aussi de meilleures normes de sécurité et de redondance électrique.
L'expérience de la conception
Nombre de nos clients savent qu'ils pourraient être en théorie autonomes face à leurs serveurs, les commander, les provisionner et installer leurs applications. Mais en pratique, comment prévenir et gérer les incidents, à tout heure, sans en avoir géré auparavant ?
Une grande partie de l'expertise de l'infogéreur, c'est son expérience. Il saura prévenir un maximum de risque avec le minimum de complexité et de coût. On ne peut pas prévoir tous les incidents, et surtout s'en prémunir de la même façon, il faut souvent étudier des solutions sur mesures, suivant les besoins de disponibilité, les budgets, et les technologies impliquées.
On pense souvent à l'incident matériel sur le ou les serveurs hébergeant l'application, mais le périmètre est bien plus large : le registrar, le DNS, les APIs consommées, le CDN, les loadbalancers, les VPNs, les DDoS, les débordement de capacité, etc. Savoir comment architecturer cet ensemble afin qu'il reste simple et résilient nécessite un savoir-faire qu'on acquiert qu'en "forgeant" et en exploitant. Savoir anticiper et gérer les évolutions des architectures est également une expertise clé, on ne peut pas tout jeter et recommencer à chaque fois qu'on bute sur une limite en production.
Sauvegarder et restaurer
En matière d'infogérance nous considérons qu'il y a un minimum qui n'est pas discutable :
1/ les sauvegardes : C'est pour cela que nous n'avons aucune offre d'infogérance sans sauvegarde, et ce depuis toujours. Ce n'est pas négociable, et ceci nous permet de déployer des solutions de sauvegardes massives permettant des économies d'échelle. Le corolaire est qu'il est facile de commander des sauvegardes aussi exigentes que "8 quotidennes, 4 hebdomdaires, 12 mensuelles", et vous avez la garantie que derrière une équipe s'assurera que quoi qu'il arrive, les sauvegardes fonctionnent 24x7 ;
2/ les sauvegardes distantes : l'incendie d'OVH illustre tristement leur nécessité. Un incident physique n'est pas forcément conscrit à quelques serveurs ou un bâtiment, tout un site peut être touché. Ainsi une sauvegarde n'en est pas une tant qu'elle n'est pas à une distance respectable. Chez Bearstech nous utilisons d'ailleurs une inrastructure custom chez OVH (Roubaix) pour assurer une copie des données de notre datacenter à plus de 250km ;
3/ les sauvegardes locales : optionnel, mais si vous avez un grand volume de sauvegarde (comme nous), une sauvegarde distante peut impliquer des temps de restauration qui se chiffrent en jours avec le meilleur des réseaux ! Nous gardons aussi une sauvegarde locale qui permet de restaurer beaucoup plus vite in situ, et ainsi on a à chaque instant deux sauvegardes complètes. Nous considérons qu'avoir deux copies est la norme industrielle depuis l'avènement de S3.
Par ailleurs savoir restaurer est une compétence symétrique bien souvent négligée. Nous vous encourageons à faire tout de suite un ticket à votre infogéreur et lui demander d'accéder aux données de votre serveur de la veille ou de demander si une restauration peut être programmée rapidement (sur une préprod! Ne soyez pas trop joueur...). S'il réagit rapidement, calmement et positivement comme il se doit, considérez que cela vaut tous les ISO 27001, c'est le résultat concret qui vous dit si votre business numérique survivra ou pas.
L'expertise des sauvegardes et de la résilience
Assurer la sauvegarde complète d'une application pour que sa restauration se passe bien est loin d'être une chose triviale. Il n'existe pas de solution sur l'étagère à notre connaisance.
Pour une application donnée, restaurer c'est savoir faire une sauvegarde cohérente. Ceci signifie que l'ensemble des données qui la constitue correspondent à la représentation d'un instantané du modèle de donnée de l'application. Plus pragmatiquement, c'est par exemple dans la sauvegarde et le tuple [42, "doc-important.pdf"] dans le dump SQL et le fichier doc-important.pdf dans la copie du stockage objet et du filesystem.
Cartographier l'état et la configuration d'une application n'est pas chose aisée. Par ex., auriez-vous pensé à sauvegarder puis restaurer la crontab planquée en général dans /var/spool/cron/crontabs/ ? Que l'envoi d'emails peut génerer une longue trainée de spam si vous oubliez de mettre à jour un champ DNS SPF ? La checklist peut être (très) longue et chaque détail peut mener à un restauration fail, bien entendu au pire moment.
Enfin, capturer l'état de tous les services d'une application (la configuration, le code, le dump SQL et noSQL, l'environnement DNS/CDN/TLS, etc) et en faire un état global cohérent n'est pas chose aisée. Dès que l'on dépasse le cadre balisé de quelques stacks telles que LAMP, nous avons constaté qu'il doit y avoir un dialogue entre l'infogéreur et les développeurs afin de définir une solution adaptée.
Notez qu'en ces temps d'abstraction plus élevés (Kubernetes !), beaucoup sont tentés de croire que ces problèmes ont été résolus par ces nouvelles infrastructures. Attention, il n'en est rien : ces abstractions permettent d'utiliser plus facilement des systèmes résilients, mais cette résilience n'est pas automatiquement acquise avec l'adoption de cette technologie. Les détails d'implémentation sont également importants et peuvent vous échapper (combien de clusters k8s avons-nous vu dans une unique zone...).
Conclusion : ne pas perdre de données
Ce billet n'aborde pas la problématique de la haute disponibilité, car il est relativement distinct des problématiques de sauvegardes. Une partie de l'analyse sur ce qu'est l'état d'une application est commune, mais ensuite les choix techniques et les implémentations sont en général distincts : faire une photo des données une fois par jour n'est pas la même chose qu'obtenir une copie en continu et quasi temps réel.
Par ailleurs il faut bien comprendre que sauvegarder et répliquer pour de la H-A (Haute Disponibilité) ne sont pas mutuellement exclusifs, surtout pas ! Il suffit d'imaginer le scénario où un déploiement efface par erreur des données en production (ou une attaque destructrice, etc) : le problème sera instantanément répliqué sur votre belle infrastructure super résiliente, et votre business tombe ! La sauvegarde vous prémunit de tous les incidents, alors que la réplication/H-A seulement de quelques pannes, c'est un périmètre très différent.
Nous avons donc développé un mantra précis : il ne faut pas perdre de données. En 2021, avec le prix du stockage dérisoire, et des choix technologiques en pagaille, ce n'est clairement pas une option.