Auteur Sujet: OVH - incident majeur du au watercooling  (Lu 22581 fois)

0 Membres et 1 Invité sur ce sujet

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
OVH - incident majeur du au watercooling
« Réponse #36 le: 04 juillet 2017 à 23:15:29 »
Tout dépend des usages aussi, cf l'étude de Google : http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/23105-fast16-papers-schroeder.pdf, qui ne semble pas très intensive en écritures :
Citer
SLC drives, which are targeted at the enterprise market and considered to be higher end, are not more reliable than the lower end MLC drives
Malheureusement, avec les délais, les finesses de gravure des SSD testés ne sont plus vraiment d'actualité (sauf peut-être en NAND 3D).
Actuellement il ne doit plus rester beaucoup de SLC, le choix se fait probablement entre MLC "haute endurance", MLC 3D (gravée moins finement), et MLC classique (peut-être même la TLC 3D type Samsung 850 EVO).

111

  • Abonné Orange Fibre
  • *
  • Messages: 235
  • Nantes
OVH - incident majeur du au watercooling
« Réponse #37 le: 07 juillet 2017 à 14:56:54 »

underground78

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 7 436
  • Orsay (91)
    • FreePON : suivi géographique du déploiement fibre EPON chez Free
OVH - incident majeur du au watercooling
« Réponse #38 le: 07 juillet 2017 à 15:29:31 »
Je dirais que c'est relativement honnête.

e-TE

  • Abonné Free fibre
  • *
  • Messages: 1 145
  • Déville-les-Rouen (76)
OVH - incident majeur du au watercooling
« Réponse #39 le: 07 juillet 2017 à 15:33:01 »
mouais..

y'a quand même bcp de blabla qui tourne autour du pot... le passage
Citer
En conclusion : exploiter des technologies propriétaires n’est pas toujours adapté à notre organisation, à notre volonté de maîtriser de bout en bout la chaîne de valeur. Si bien que — indépendamment de la qualité intrinsèque de ces technologies — elles représentent parfois un risque dans le contexte particulier d’OVH, en nous rendant dépendants d’équipes techniques externes et nous obligeant à ajouter des exceptions à nos procédures, quand notre volonté est l’industrialisation… et non la gestion de cas particuliers.

c'est pas le fait de la techno propriétaire que l'incident c'est produit, c'est d'avoir mis en prod des équipements dans des locaux qui n'étaient pas prévu à l'origine pour, et d'avoir passé 4ans à le savoir et sans les migrer... alors oui, tant que ca marche, pourquoi se faire chier à les bouger... mais quand ca merde bah c'est la merde... et si pour ca ils sont capables de laisser en l'état, quel autres sujets ou c'est "limites mais ca marche" ont-ils sous le coude et qu'ils n'adressent pas?

dans le fond y'a pas grand chose, mais ca jette le doute :)

111

  • Abonné Orange Fibre
  • *
  • Messages: 235
  • Nantes
OVH - incident majeur du au watercooling
« Réponse #40 le: 07 juillet 2017 à 15:36:23 »
C'est transparent mais y'a un peu de mauvaise fois quand même.

Mon passage préféré est celui là :
Citer
Aussi, il est difficile de communiquer sur les sujets entourant le watercooling sans prendre le risque de révéler, indirectement, des secrets industriels qui pourraient intéresser nos concurrents.
Vu le bricolage que ça a l'air d'être sur l'image ça me semble pas bien compliqué à reproduire après une promenade à Monsieur Bricolage  ;D

Quand on pense qu'il suffisait de mettre une bâche sur la baie après sa mise en service  ;D

FloBaoti

  • Abonné MilkyWan
  • *
  • Messages: 1 300
  • 34
OVH - incident majeur du au watercooling
« Réponse #41 le: 07 juillet 2017 à 15:37:03 »
Et les équipes d'EMC qui ne sont pas capables de remettre en service une baie, on en parle ? Super la techno propriétaire. Un disque c'est un disque, tu le changes de chassis, tu dois pouvoir accéder aux données dessus...
Et l'autre baie qui n'a pas pris l'eau ? elle a quoi ? elle a eu la grippe ?
Bref vive l'open source

e-TE

  • Abonné Free fibre
  • *
  • Messages: 1 145
  • Déville-les-Rouen (76)
OVH - incident majeur du au watercooling
« Réponse #42 le: 07 juillet 2017 à 15:48:16 »
l'autre baie elle tourne bien vu qu'ils ont prévu de la migrer...

et on ne sait pas a quel point l'eau a foutu le bronx dans la machine avant son arrêt... plus un redémarrage sur un modèle équivalent mais stocké dans un coin... quid du stockage, de son redémarrage, de sa version logicielle par rapport à celle qui est tombé?
c'est pas un bête nas grand publique, c'est un peu plus complexe..

donc oui, ils ont surement raison sur le fait que si c'était un serveur maison ils auraient eu moins de mal à redémarrer... mais si ils avaient eu que du emc et des types formés pour et avec l'habitude d'en utiliser quotidiennement, ils auraient peut être eu moins de mal a redémarrer également ;)
et l'ouverture du ticket a 20h (1h12 après incident) puis à 8h le lendemain matin après avoir fait les premiers tests 1h avant... ca sent un peu le contrat de maintenance avec support limité... et peut être plus en adéquation avec la charge porté par le matos  :-X


donc au final ca sent quand même le PRA écrit dans un coin, testé dans un lab sur 1 serveur, et qui te pète à la gueule quand tu es en situation de crise :) et le post mortem bourrées d'infos intéressantes mais inutile, pour noyer le poisson...

FloBaoti

  • Abonné MilkyWan
  • *
  • Messages: 1 300
  • 34
OVH - incident majeur du au watercooling
« Réponse #43 le: 07 juillet 2017 à 15:54:58 »
Ils parlent de 2 baies en "active-active", donc les données répliquées sur les 2 ?? Donc si l'autre tourne, où est le problème. Coupure max 1 seconde...

underground78

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 7 436
  • Orsay (91)
    • FreePON : suivi géographique du déploiement fibre EPON chez Free
OVH - incident majeur du au watercooling
« Réponse #44 le: 07 juillet 2017 à 15:58:28 »
C'est transparent mais y'a un peu de mauvaise fois quand même.

Mon passage préféré est celui là
On est bien d'accord. :)

e-TE

  • Abonné Free fibre
  • *
  • Messages: 1 145
  • Déville-les-Rouen (76)
OVH - incident majeur du au watercooling
« Réponse #45 le: 07 juillet 2017 à 16:07:29 »
Ils parlent de 2 baies en "active-active", donc les données répliquées sur les 2 ?? Donc si l'autre tourne, où est le problème. Coupure max 1 seconde...
je comprend plutot qu'ils avaient 2 VNX 5400, que chacune d'entre elles a deux controleurs en mode actif/actif... sauf que si 1 VNX est sous l'eau, les deux controleurs se retrouvent sous l'eau...


et pour le deuxième VNX qui était à coté, ils disent dans leurs conclusions:
 
Citer
Le constat a d’ores et déjà était fait qu’un principe essentiel chez OVH n’avait pas été respecté dans le cadre de l’exploitation de cette baie de stockage propriétaire : répartir le risque en multipliant les machines, ceci pour minimiser le domaine de panne. Nous finalisons donc actuellement la migration de la dernière baie de stockage propriétaire de notre parc.



enfin voila, a trop vouloir tourner autour du pot, on noie le poisson xD


et un VNX5400 reste une solution entrée/moyen de gamme d'emc de 2013 d'après la doc d'emc

buddy

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 15 127
  • Alpes Maritimes (06)
OVH - incident majeur du au watercooling
« Réponse #46 le: 07 juillet 2017 à 16:54:13 »
ça reste du OVH .. On n'apprend pas grand chose.

Citer
La procédure d’urgence, servant à exécuter cette série d’opérations existait et avait été testée. Mais pas industrialisée. Autrement dit, restaurer une table à partir du backup est trivial. Restaurer un très grand volume de tables, initialement réparties sur 99 VM, nécessitait davantage d’automatisation, sans quoi la restauration aurait nécessité plusieurs journées.
Moi ce qui me choque le plus c'est qu'ils n'aient pas prévu de devoir restaurer des milliers de bases de données d'un coup. Ils en ont des milliers par serveur donc il était prévisible que des milliers tombent d'un coup ..

C'est comme l'alerte Audio qui ne marchait pas juste ce jour là. ça peut être vrai, mais c'est souvent juste le jour de la MAJ foireuse qu'il y a un incident. Bon d'accord, si il n'y avait pas eu un incident aussi grave, on en aurait pas parlé .. Mais ça vaudrait le coup de mieux tester le système audio avant de le release.

Sinon un truc qui me parait long,
Citer
Après avoir sollicité l’aide du constructeur de la baie peu après 20 h, les équipes poursuivent les tentatives de rallumer la baie, sans succès. 20 minutes après son démarrage, elle s’éteint sous l’effet d’un mécanisme de sécurité.
ça ne vous parait pas long 20 minutes pour que le système de sécurité s'enclenche pour une fuite d'eau ? J'ai envie de penser que soit il y a court circuit => arrêt immédiat, soit si elle est sous tension depuis 19 minutes, elle peut continuer ...à moins que ça ne soit les disques durs qui aient pris l'eau / ait cramé et qu'au bout de 20 minutes la baie se met en défaut car elle ne retrouve pas les informations lui permettant de lire les données ..

Nb : j'ai été impacté à titre perso, mais rien de bien grave. (juste une indisponibilité d'environ 20 H, je n'ai pas perdu de CA ou autre comme certains.)
Pour le prix que je paye (moins cher que tous les autres), j'accepte ce "problème".

miky01

  • Expert. Réseau RESO-LIAin (01)
  • Abonné K-Net
  • *
  • Messages: 3 829
  • Farges (01)
OVH - incident majeur du au watercooling
« Réponse #47 le: 07 juillet 2017 à 18:52:32 »
je comprend plutot qu'ils avaient 2 VNX 5400, que chacune d'entre elles a deux controleurs en mode actif/actif... sauf que si 1 VNX est sous l'eau, les deux controleurs se retrouvent sous l'eau...

Je pense aussi qu' ils avaient pas vu ou ignoré ce SPOF, car 2 bays en mirroring ca peux pas générer ce genre de crash, sauf si elle sont cote a cote... c'est pas pour rien que en haute disponibilité on met jamais 2 bays dans la meme salle, ou mieux sur 2 sites pour les plus exigents, mais ca un surcout pas négligable,

Citation de: FloBaoti
Et les équipes d'EMC qui ne sont pas capables de remettre en service une baie, on en parle ? Super la techno propriétaire. Un disque c'est un disque, tu le changes de chassis, tu dois pouvoir accéder aux données dessus...
Et l'autre baie qui n'a pas pris l'eau ? elle a quoi ? elle a eu la grippe ?

Un disc est un disc sur un PC, mais pas sur ce genre de bays...
Un cache controleur qui est detruit peux te pourrir une multitude de raids, avant que la bay passe en power off, tu peux toujours remettre tous discs dans une bays fonctionnelle, tes discs seront illisible.

Je connais pas constructeur ou il est possible de faire le swap de tous les discs simultanèment sur ce genre de matos, le contoleur a en memoire la config complète de la bay, et les IDs de tous les disques.