Rappelons qu'à la base, SBG devait être le PRA de RBX

Nous avons désormais un retour détaillé sur la 2ieme panne majeure du 9 novembre, la coupure totale des interconnexions réseau à partir du site de Roubaix, le plus gros datacenter d'OVH en France.

https://www.ovh.com/fr/blog/retour-experience-incident-reseau-9-novembre-2017-site-de-roubaix/
(Google Cache si ça plante)

Je ne connais pas le domaine des réseaux télécom longue distance, mais je suis très surpris : on a ici un seul équipement optique "master" qui configure tous les équipements du site de Roubaix. Donc les équipements redondants ne sont clairement pas indépendants les uns des autres. J'ai beaucoup de mal à comprendre. Une simple erreur humaine de configuration pourrait aboutir au même problème, non?

Quelqu'un peut-il nous expliquer ce que font les processeurs de ces cartes de supervision?
Juste surveiller ce que remontent chacune des différentes cartes? Les puissances optiques observées, le taux d'erreur, et c'est tout?
Tout ça actualisé, disons toutes les 10ms?
Même pour une centaine de longueurs d'ondes redondantes, ça représente une toute petite charge CPU, on est bien d'accord?

Qu'est-ce que ces cartes de supervision permettent de configurer?
* les différentes longueur d'onde de chacun des transpondeurs?
* les atténuateurs, les amplis, les modules de compensation de dispersion?
* les switches optiques assurant la redondance?

Pourquoi centraliser ainsi la configuration des équipements? Ne peut-on pas créer des boucles optiques longue distance, où chaque noeud est totalement indépendant des autres, et réagit seulement aux coupures? Genre je ne vois plus Paris par la fibre Ouest, donc je regarde Paris par la porte Sud...

Pourquoi tous ces équipements ne sont-ils pas indépendants les uns des autres?
OK, la remontée d'informations depuis les différentes cartes / modules, c'est pratique et ça n'introduit aucun SPOF si c'est bien isolé.
Mais la configuration par un seul équipement central, c'est contraire aux règles de redondance! C'est limite choquant!
Dans des installations industrielles ultra redondantes/disponibles que je connais, on s'assure que chaque "automate" a une autonomie de décision, donc qu'il est isolé des autres automates redondants, donc non influençable par les bugs des autres (même s'ils s'échangent des informations simples entre eux pour se surveiller mutuellement).

Dans le cas de boucles optiques WDM redondantes que j'avais eu la chance de voir il y a 15 ans, tout était réalisé avec des équipements séparés, indépendant. Tout était configuré à la main (ajout d'atténuateurs, module laser spécifique pour chaque longueur d'onde). J'imagine bien que ça n'est plus forcèment possible quand on parle de 80 longueurs d'ondes différentes, et de chassis optiques denses (quoi que pour Cisco ça n'est pas si dense).
Mais il y a certainement un compromis à trouver entre
1) l'automatisation de la config qui rajoute un SPOF
2) système complexe à configurer (quasi manuellement) mais hautement redondant une fois qu'il est bien configuré

J'avais déjà vu ce genre de blagues (SPOF "logique") pour des onduleurs industriels, qui étaient censés être redondants, et qui étaient pourtant tous reliés à un seul réseau d'information logique et propriétaire, qui constituait un SPOF.



Leon.

Première chose, l'automatisation n'est jamais un SPOF, une configuration manuelle: Oui.

Imagine plutot tes TMS comme des "controlleur", elle "juste" push la configuration sur tes équipements.
Là le "controlleur" a "buggé" et il a envoyé des "vider" la conf.

C'est assez contradictoire, ce que tu me dis. Ici, c'est bien l'automatisme qui a été un SPOF, et je trouve ça complètement anormal.

On ne veut plus utiliser cette façon de faire d'il y a 15 ans. Car c'est beaucoups trop cher et moins fiable.
Ex tu as: tu as deux fibre entre roubaix et paris, deux entre paris et strasbourg.
Si tu veux connecter un lien entre roubaix et strasbourg tu ne va pas vouloir recabler à Paris, donc tu es obligé d'avoir un "management" centralisé et imagine quand ton lien de backup fait roubaix, bruxelles, francfort, strasbourg, ...

Faire tout ça avec une gestion centralisée non redondée, je trouve ça clairement suicidaire. On est d'accord que OVH ne rajoute pas une route optique tous les jours ni même toutes les semaines, loin de là.

Je pense vraiment que ce monde de l'informatique et des télécoms a beaucoup à apprendre du monde des industries ultra sensibles et hautement disponibles: sidérurgie, nucléaire, ferroviaire, aéronautique, spatial.

Leon.

Le meme circuit integré coute 0.02$ dsns un TV, et 1000$ dans un satellite ou un missile...

Simplement car on demande pas la meme fiabilité, et le cout pour passer de 99.0% de fiabilité a 99.9%  te mutltilplie le prix par par 2x mais par 500X.

Où est le rapport avec l'incident d'OVH dont on parle ici, qui est dû exclusivement à un problème de conception? Problème de conception visiblement partagé entre Cisco et OVH... Ca n'est pas un problème de prix de composants, mais de conception d'architecture de systèmes complexes redondant hautement disponibles.

Leon.

Le raport est que OVH a choisi un créneau "low cost" qui est une demande du marché, maintenant su tu es une banque et que tu as un serveur qui gère 5000 distributeur de billet, ben tu choisis un hebergeur ou le prix a rien a voir, mais par  contre tu auras pas ce genre d'incident vu que ca sera répliqué sur plusieurs sites.

Que les experts savent que OVH est middle/low cost est un fait

Mais la plupart des clients doivent croire que c'est le prix du marché pour une parfaite fiabilité.

Le jour où Google ou Amazon vont avoir un soucis, beaucoup de clients vont déchanter du all wonderfull cloud sans précautions

J'avais déjà vu ce genre de blagues (SPOF "logique") pour des onduleurs industriels, qui étaient censés être redondants, et qui étaient pourtant tous reliés à un seul réseau d'information logique et propriétaire, qui constituait un SPOF.

Autre exemple que j'ai déja vu : les climatisations qui sont toutes gérées par le même automate : l'automate est tombé et la clim du site est intégralement tombée.

Les clim ont été basculée en mode indépendante après 2h de coupure. La température était passée de 20 à 40°c.

Je me demande l’intérêt d'avoir un automate pour les clim, c'est assez simple et cela marche bien quand elles sont indépendantes les unes des autres. Cela ne dois pas être souvent que la température cible est changée.

Peut-être que l'automate peut éviter l'effet yoyo de la température observée dans certain datacenter.