La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: Leon le 02 juillet 2017 à 07:24:01
-
Bonjour à tous,
L'hébergement mutualisé d'OVH a subi un incident majeur vendredi, avec une indisponibilité de nombreux sites pendant plus de 24h.
C'est un gros filer (serveur de fichiers) EMC qui est tombé, alors que ce genre d'équipement est normalement intrinsèquement très redondé.
Sur twitter, un utilisateur a capturé un suivi des travaux qui parle de fuite d'eau! Je ne pense pas que c'est un fake, puisque cet utilisateur n'est pas anonyme.
De là à penser qu'il s'agit d'une fuite d'eau liée au watercooling made by OVH, il n'y a qu'un pas, que je franchis volontairement. Ce suivi a été modifié depuis et il parle désormais uniquement d'incident électrique.
https://twitter.com/tcardonne/status/881161596902535168
Le datacenter a subi une fuite d'eau importante, entrainant la panne des composants de stockage
nécessaire au bon fonctionnement du système. Les techniciens sont dessus.
(https://lafibre.info/images/ovh/201706_ovh_fuite_eau_importante.jpg)
OVH a même du mettre un commentaire dans le suivi pour dédouaner EMC (fabriquant du filer).
http://travaux.ovh.net/?do=details&id=25709
La technologie d'EMC n'est pas à l'origine de l'incident.
Nos datacentres ne sont pas adaptés pour héberger ce type
d'infrastructure. Seules certaines salles sont spécialement
préparées pour ce genre d'hébergement, mais cette baie de
stockage n'y a pas été hébergé ce qui est l'origine du
problème. Nous remercions EMC de nous aider à résoudre cet
incident.
Si c'est vraiment vrai, c'est du grand n'importe quoi. Héberger un équipement aussi sensible dans un endroit exposé aux fuites d'eau... Entre ça et les serveurs HS suite à la canicule (absence totale de clim) (https://lafibre.info/ovh-datacenter/temperateure-ovh/msg451974/#msg451974), je me fais une idée très claire de la qualité selon OVH.
OK, OVH est une entreprise impressionnante par sa croissance. Mais elle fait des économies de bout de chandelle, et elle n'a pas la culture de la qualité/disponibilité.
Leon.
-
Cet incident a été très important (les clients ont été prévenu dans le manager). C'est la première fois que je voyais un incident dans mon manager.
La fuite d'eau est tout à fait crédible.
Sur un serveur dédié OVH, j'ai déjà eu un changement de carte mère, sans m'avertir.
Mon système n'a pas apprécié et il ne démarrait plus. J'ai démarré en ressue et là j'ai vu que le CPU n'était plus le même et qu'il était un peu moins puissant qu'avant.
J'ai pensé à une fuite d'eau dans ma baie, mais je ne saurais jamais. OVH ne m'a donné aucune explication pour la changement de carte mère.
-
Pour la fuite d'eau, je confirme, je l'ai lu et "copier coller" (car un site que je gère a été touché) et j'ai partagé le ticket avec les autres personnes qui gèrent le site avec moi.
Après, oui, c'est OVH ... çà reste du low-cost... Ce qui m'étonne c'est que cette "baie" qui a l'air dans son état "constructeur" ait été impactée par une fuite de water cooling. Je pensais que c'était quand même un minimum séparé. Pas que les tuyaux passaient juste au dessus d'une baie sans watercooling.
-
Je connais pas l'architecture des datacenters de OVH, notamment P19, mais il n'est pas impossible que cette prétendue fuite provienne de l'étage supérieur (ie des toilettes) ? Cela dit, si c'est le cas c'est peut-être encore plus triste.
@Leon : Je crois que je ne suis pas un fake ;D
-
J'ai eu des bruits de couloir qui confirment que c'est le watercooling ::)
-
Je connais pas l'architecture des datacenters de OVH, notamment P19, mais il n'est pas impossible que cette prétendue fuite provienne de l'étage supérieur (ie des toilettes) ? Cela dit, si c'est le cas c'est peut-être encore plus triste.
Vu comment c'est formulé, je n'ai pas trop de doute que c'est le watercooling. "Nos datacenter ne sont pas adaptés" = "on fait du watercooling et on transporte de l'eau dans des tuyaux non sécurisés".
Nos datacentres ne sont pas adaptés pour héberger ce type
d'infrastructure. Seules certaines salles sont spécialement
préparées pour ce genre d'hébergement, mais cette baie de
stockage n'y a pas été hébergé ce qui est l'origine du
problème.
Je rappelle que les photos de watercooling d'OVH montrent des montages artisanaux qui n'inspirent pas vraiment confiance.
Les raccords sont apparemment de simples flexibles emboités et serrés avec un collier! Il n'y a même pas de raccord stop! C'est incompréhensible de faire l'économie de quelques dizaines d'euros par baie, sachant qu'une baie génère un chiffre d'affaire qui se compte en dizaines de milliers d'euros par an!
Des raccords stop industriels qui garantissent aucune goute d'eau lors de la connexion/déconnexion, ça existe!
En cadeau bonux, quelques photos des raccordement en eau des baies chez OVH.
Leon.
(https://lafibre.info/images/ovh/201106_rbx4_watercooling_serveurs_2.jpg)
-
C'est pas la première (apparemment) et ca sera certainement pas la dernière fois que ca arrive.
La rançon du succès ? C'est dur de faire du bricolage quand on est presque le 1er hébergeur du monde.
Tiens, ca me fait penser que l'autre jour lors de l'inauguration de station f, Niel parlait de Octave Klaba. Je ne savais pas que Niel (Iliad) l'avait hébergé pendant plusieurs mois au début.
-
OVH était sur le réseau Free, quand Orange a voulu faire payer le peering de Free, cela a pesé dans la balance.
Le peering entre Orange et Free / OVH était a cette époque de 1 Gb/s :
Message du dimanche 19 janvier 2003 17:22:
Comme vous pouvez constater le peering avec wanadoo est régulièrement saturé dans la journée. Dans la semaine, on essaie en arrêtant les miroirs (free/ovh) et newsgroups (free) faire de sorte que le trafic reste inférieur à 1Gbs mais c'est de plus en plus difficile.
De notre côté nous avons mis tout en place depuis plusieurs semaines mais rien n'est fait de côté de wanadoo puisqu'ils n'ont pas de feu vert de leur direction !
En effet, nous avons eu la confirmation que le problème d'upgrade du peering est un problème de _politique_ et wanadoo ne souhaite pas l'upgrader !
Il ne nous reste plus qu'à vous demander de faire les actions au près de wanadoo pour faire la pression sur la direction afin qu'elle donne le feu vert à leur équipe technique pour l'upgrade. Téléphonez à leur support, envoyez l'email à leur support, faites savoir l'information au près des journalistes, affichez l'information sur votre site, faites passer l'information aux autres sur les pratiques que France Telecom vis à vis de leurs concurrents !
Il faut préciser qu'à l'époque, l'ADSL commençait à s'envoler chez Orange. Free était FAI presque exclusivement 56k, mais il avait des "pages persos" populaires et OVH sur son réseau :
Un article de journal où Octave Klaba est interviewé :
Mercredi 22 janvier 2003
Des semaines que Free voit grossir le mur : entre les deux poids lourds de l'Internet Français, il n'y a qu'un seul et unique câble, qui n'a pas été remplacé depuis deux ans. Problème : l'Internet a bien grossi entre temps, et le calibre du tuyau - 1 Gbit/s - n'est plus à la hauteur. Résultat : entre Free et France Telecom, les débits chutent spectaculairement et la qualité de service se dégrade.
"Free a bien tenté de prévenir France Telecom il y a deux mois, mais sans succès : FT n'a pas réagi, et les temps d'accès vers certains sites ont fini par devenir intolérables pour les internautes de Wanadoo et de Free" - affirme Octave Klaba, DT de l'hébergeur OVH.
La conséquence ? Pour peu qu'un site se trouve de l'autre côté du tuyau - et c'est souvent le cas -, les informations circulent aussi vite qu'une voiture dans un embouteillage. Sur les forums de discussion, on peut trouver des phrases de ce genre émanant d'internautes mécontents: "J'ai l'impression d'être en 14,4 Kbit/s" - faisant référence à la vitesse anémique à laquelle plafonnaient les tous premiers modems.
Coupure pure et simple
Mais c'est surtout du côté des propriétaires de sites commerciaux hébergés par Free ou FT que l'inquiétude est la plus vive : impossible d'accéder à leurs pages dans de bonnes conditions depuis l'autre côté du tuyau qui relie FT à Free.
Pourtant, le pire reste à venir : hier matin, Free coupe tout simplement l'accès à ses serveurs pour tous les internautes de Wanadoo : ils sont privés d'une partie du Web et de certains services mail. Officiellement, Free n'a pas voulu mettre le couteau sous la gorge de France Telecom : il s'agissait simplement de soulager ses serveurs, qui croulaient sous le temps d'accès, et qui dégradaient la qualité de service de ses abonnés. Mais de là à dire que Free a voulu réveiller (brutalement) Wanadoo, qu'il tentait - rappelons-le - de prévenir depuis des mois, il n'y a qu'un pas.
Un pas que ne franchira pas Free : "C'est un petit problème qui se règlera bien vite, nous faisons confiance à France Telecom". A n'en pas douter, Free ne souhaite pas froisser le géant des télécoms.
Service rétabli mercredi soir ?
Dans tous les cas, l'électrochoc a fait son effet : dans la soirée de mardi, FT et Free parviennent à un accord : "d'ici mercredi à 17h, le calibre du tuyau sera multiplié par 2,5, et Free rendra aux "Wanadiens" leur liberté" - communique France Telecom.
Mais la bataille n'est pas terminée : FT précise que "les négocations commerciales n'ont pas encore abouti, et que le service sera - à titre exceptionnel - rétabli avant même que les conditions soient clarifiées". En clair : Free va sans doute devoir bourse délier.
La pilule sera difficile à avaler pour Free : "Il y a deux ans, lorsque le FAI développe son propre 'point de peering' - la porte d'accès à son réseau privé -, FT l'autorise à se connecter à son propre point de peering gratuitement. Aujourd'hui, FT souhaite faire payer Free. Pour quelle raison ? Il y a autant de traffic dans un sens que dans l'autre, et FT a autant besoin de Free que Free a besoin de FT" explique Octave Klaba, DT d'OVH. FT reconnait ces faits, mais l'opérateur laisse entendre que Free va devoir payer.
-
D'autres photos :
Encore quelques photos inédites des serveurs d'OVH, avec du watercooling, par zdnet.co.uk (lien HS)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_1.jpg)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_2.jpg)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_3.jpg)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_4.jpg)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_5.jpg)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_6.jpg)
(https://lafibre.info/images/ovh/201203_ovh_watercooling_7.jpg)
Leon.
-
Les amis de chez PCImpact ont mis fait un reportage sur ce datacenter d'OVH (Roubaix 4).
[Lien HS supprimé]
Le plus intéressant c'est les images du watercooling. Ce sont des images assez rares. OVH a volontairement restreint sa communication (et les photos) sur le sujet depuis des années!
(https://lafibre.info/images/ovh/201106_rbx4_watercooling_serveurs_1.jpg)
(https://lafibre.info/images/ovh/201106_rbx4_watercooling_serveurs_3.jpg)
(https://lafibre.info/images/ovh/201106_rbx4_watercooling_serveurs_4.jpg)
Leon.
-
Vous êtes sûr que c'est de l'eau et pas du gaz dans les tuyaux ? :p
-
Oui, c'est de l'eau, voici le réservoir :
Génération 3 de watercooling. La piscine de stockage temporaire d'eau qui sert à refroidir les serveurs du private Cloud Computing: 20KW/baie !
(https://lafibre.info/images/ovh/201106_rbx2_la_piscine_de_stockage_eau.jpg)
-
Est-ce de l'eau du robinet ou un liquide adapté qui ne conduit pas l'électricité ? ;D
-
C'est clairement de l'eau du robinet, avec des additifs pour éviter le développement des bactéries et autres microorganismes.
Leon.
-
Je me suis toujours demandé comment le système de watercooling artisanal pouvait fonctionner correctement tellement ça avait l'air rudimentaire, personnellement ça ne m'inspire pas confiance ...
-
Dans les datacenter Google, une hypothèse sur les faux-plancher était de pouvoir éviter en cas de fuite de mouiller le matériel :
Cliquer sur la photo pour zoomer :
(https://lafibre.info/images/datacenter/201305_datacenter_google_MNK_019.jpg) (https://lafibre.info/images/datacenter/201305_datacenter_google_MNK_019.jpg)
Moi, il y a un truc que je ne comprends pas.
Pourquoi ils mettent des faux planchers? On voit bien sur plein de photos que les clims (échangeurs) sont directement au plafond des "allées chaudes".
(https://lafibre.info/images/datacenter/201305_datacenter_google_mini_MNK_019.jpg) (https://lafibre.info/images/datacenter/201305_datacenter_google_MNK_019.jpg)
Donc il est peu probable que les faux planchers soient choisis pour la circulation de l'air. Pour les chemins de câble non plus, puisqu'on voit que tout est en hauteur: alimentation électrique, et fibre. Circulation d'eau? Si oui, c'est vraiment étrange. s'embêter à mettre des faux planchers juste pour ça, ça ne me parait pas logique.
Leon.
-
Dans les datacenter Google, une hypothèse sur les faux-plancher était de pouvoir éviter en cas de fuite de mouiller le matériel :
C'est clair que c'est assez probable comme hypothèse : pouvoir maintenir le réseau d'eau froide sans mettre en péril les installations.
Et là, chez Google, on voit de vrais raccords industriels, pas comme chez OVH.
Leon.
-
C'est une baie de 96 disques EMC qui a été impactée. Elle alimentait pas moins de 97 serveurs SQL !
Ces 97 serveurs SQL étaient utilisés par 50.000 sites Web (dont plusieurs sites de e-commerce, indisponibles pour le lancement des soldes).
Bref, je suis étonné du nombre de serveurs SQL qui sont sur un même filer, sachant que ce ne sont pas des serveurs SQL qui se tournent les pouces.
Il y a probablement des centaines de serveurs web pour héberger les sites et des dizaines ou centaines de baies disques pour le contenu des sites hors de la base de donnée.
Bref c'est une quantité impressionnante de matériel qui reposent sur un seul filer.
Je me demande a quelle vitesse il faut changer les 96 disques SSD de cette baie qui reçoivent en permanence des grosses écritures.
-
Vivien, il faut bien voir ce que c'est un filer EMC : C'est pas un bête serveur de fichier classique.
C'est un système constitué de plusieurs têtes (serveurs), tous les éléments sont équipés d'alim redondantes, toutes les liaisons sont redondées, les switches aussi, etc...
C'est conçu pour résister à une panne de n'importe lequel de ses éléments.
Un peu comme les équipements télécom haute disponibilité.
Bref, c'est du lourd, c'est fait pour tourner H24, c'est hyper fiable, y compris d'un point de vue logiciel. Tout est maintenable à chaud.
Mais effectivement, pour des serveurs de bases de donnée, avec énormèment d'IOPS, il est peut-être plus judicieux de n'avoir que des serveurs avec disques dur locaux, je ne sais pas. Mettre des bases de données sur un SAN, je sais que ça se fait, mais je ne sais pas si c'est avantageux.
Leon.
-
Oles a promis sur Twitter de publier un post-mortem pour que les gens puissent voir si ou non OVH n'a pas été très franc dans sa comm au sujet de l'incident.
-
un vnx ne fonctionne pas sous l'eau, tout comme une bonne partie des équipements informatique.
Parole de tech EMC ;) (je bosse chez DELL/EMC, je maintiens une grosse partie de la gamme de produits dont le VNX).
Par ailleurs, j'ai eu quelques infos sur l'incident, et effectivement, il semblerait que ca soit lié a de l'eau.
Attendons les explications post mortem de Octave Klaba.
Un truc qui m'a bien fait rigoler, c'est l'article de zdnet (http://www.zdnet.fr/actualites/mega-panne-ovh-dedouane-emc-39854498.htm), la dernière phrase.
Je pense qu'il y a du avoir un échange entre OVH et EMC quand a cette communication a charge, mais de la à mettre la pression sur un client pour changer de version ... j'en doute.
C'est tjrs plus facile de mettre en cause un fournisseur/constructeur que de se remettre en cause a cause de son infrastructure.
-
C'est tjrs plus facile de mettre en cause un fournisseur/constructeur que de se remettre en cause a cause de son infrastructure.
La bonne réputation se forge dans la transparence, les erreurs sont compréhensibles.
Le monde est petit,tout le monde se connais et c'est la crédibilité de chacun qui est en jeux dans ce type de comportement.
-
La bonne réputation se forge dans la transparence, les erreurs sont compréhensibles.
Le monde est petit,tout le monde se connais et c'est la crédibilité de chacun qui est en jeux dans ce type de comportement.
Je ne suis pas forcèment d'accord avec toi. On doit impérativement mettre des limites à la transparence.
Dans la majorité des cas, un fournisseur de service ne doit pas parler de ses dysfonctionnements internes auprès de ses clients. C'est juste risqué.
Là, je pense clairement que OVH va souvent trop loin dans la transparence, maitrise mal sa communication, et ça fait du tort à l'entreprise. On apprend plein de choses pas glorieuses du tout à cause de leur communication :
* sur Hubic, OVH nous a parlé de dysfonctionnements internes
* sur la non validation de Over The Box (ce sont les clients qui valident),
* sur le watercooling pas joli à voir,
* sur les mise à jour catastrophiques des routeurs en journée,
* sur l'absence de redondance de la plupart des onduleurs (1 onduleur HS = des milliers de serveurs HS pendant 24h)
* etc...
Mais bon, c'est la marque de fabrique de cette boite.
La réputation d'un fournisseur de service (hébergeur ou autre), c'est avant tout son service client, sa réactivité, en plus de la qualité, du rapport qualité/prix, etc...
A l'extrême, ça ne me choquerai pas si OVH ne nous avait jamais parlé du watercooling, alors qu'ils en font massivement. D'ailleurs, il est tout à fait possible que d'autres hébergeurs moins transparent le fassent mais sans en parler!
Leon.
-
La force ou l'intelligence d'une baie EMC c'est le cache, ce qui explique surement comment les SSD ne lachent pas (souvent).
-
(je bosse chez DELL/EMC, je maintiens une grosse partie de la gamme de produits dont le VNX).
Un SSD, même dans la gamme professionnelle, lâche après quelques milliers de To écrit :
Endurance sur de gros fichiers :
(https://lafibre.info/images/materiel/201611_ssd_samsung_5.png)
Malgré quelques baisse de régimes, le Samsung 840 Pro reste supérieur à ses concurrents (crédit : TechReport)
Endurance sur des petits fichiers :
(https://lafibre.info/images/materiel/201611_ssd_samsung_6.png)
Sur les petits fichiers, le Samsung 840 Pro tient toujours la dragée haute aux autres, tandis que le Kingston HyperX 3K Comp est à la peine (crédit : TechReport).
Ca serait possible de savoir l'endurance sur les produits EMC ?
Les SSD doivent avoir du spare, mais avec les solicitations, j'ai un peu de mal à comprendre comment les disques peuvent rester plusieurs années.
-
@vivien : Généralement, une BDD web, c'est surtout beaucoup de lecture, ça peut te donner une piste :)
-
Oui majoritairement en lecture, mais je vois quand même de nombreuses écritures pour LaFibre.info
Par exemple chaque pages lu, tu vas mettre à jour des compteurs de visite (devant chaque sujet vous pouvez voir le nombre de vue et il y a une section stats : https://lafibre.info/stats/ )
Pour ceux qui sont connectés, les visites entraient encore plus d'écriture.
De plus les lectures sont presque toutes en cache ( la base de données tient en ram) alors que les écritures doivent se faire au fil de l'eau pour limiter la casse en cas de panne.
-
Une baie EMC a son propre "onduleur" pour ecrire les infos du cache meme en cas de panne.
-
Les bays de storages pro, HP, HDS, ont toutes leurs propres batteries pour faire un shutdown propre en cas de panne complète d'alim, ce qui arrive jamais comme c'est alimenté avec des sources redondantes et les PS sont aussi N+1 , mais apparemment des clients ont pas tous compris le principe du "high availabillity"....
Et pour le cas de OVH, mis a part ce systeme "watercooling" digne d'un bricolage avec des flexibles en plasic mou, quand on héberge des comptes Premium / Pro, la moindre des chose est d'avoir 2 bays redondantes, et pas dans la meme salle, voir sur 2 sites différents pour les clients tres critiques comme les banques, pharma, et autres.
Maintenant tout est es une question de cout, et si OVH arrive a des prix tres bas, ca se paye avec la fiabilité qui est pas a niveau.
-
On parle du mutu la, pas de trucs critiques ;-)
-
On parle du mutu la, pas de trucs critiques ;-)
Sauf du pas critique mutiplié par des dizaines de milliers, ça devient critique!
Donc OK, un serveur qui impacte 10 sites mutualisés, ça n'est pas critique.
Mais un serveur qui est capable de faire tomber 10 000 sites mutualisés, c'est archi critique!
C'est comme en télécom : une carte de DSLAM qui tombe (100 clients), ça n'est pas dramatique. Mais un gros NRA complet qui tombe (10 000 clients), là, c'est critique!
Leon.
-
Les questions que doivent se poser les clients tournent autour du contrat de service qu'ils ont signé avec Ovh.
Délai de remise en route, sauvegarde-restauration, sécurisation sur plusieurs sites ou non etc ...
Cela ne remet pas en cause la qualité de la baie de stockage EMC² et les technologies associées, ce n'est que de la technique (si je veux être provocateur)
Si ovh a annoncé la couleur par rapport à leurs engagements de servuce à ce sujet alors tout est clair....ensuite il est vrai que le watercooling fait assez "cheap" :D
-
Un SSD, même dans la gamme professionnelle, lâche après quelques milliers de To écrit :
Ca serait possible de savoir l'endurance sur les produits EMC ?
Les SSD doivent avoir du spare, mais avec les solicitations, j'ai un peu de mal à comprendre comment les disques peuvent rester plusieurs années.
Je n'ai pas de chiffres a communiquer, mais de mon expérience sur le terrain, je remplace peu de SSD (et ce, sur n'importe quel type de machine baie middle range full flash comme baie highend full flash (vmax 3 pour pas le citer).
D'une manière générale, je remarque que sur un parc installé assez vaste, j'ai moins de pannes de disques (mecaniques ou ssd) qu'il y a quelques années.
On peut surement l'expliquer par une meilleur qualité des composants.
Il y a quelques années, j'ai bossé sur une grosse campagne de remplacement massifs de disques seagate qui étaient defectueux et avaient un fort risque de generer des doubles fautes dans un raidgroup (2 disques en faute dans le meme raidgroup, ca peut faire des degats). Je ne sais pas cbien on en a remplacé worldwilde, mais en France, on avait un sacré paquet de disques concernés (toutes capacités et vitesse confondues).
J'ai des VNX de 1ere génération installés chez des clients qui les utilisent depuis plusieurs années a 100% quasiment et ou je n'ai pas eu tant de disques a remplacer ou d'autres pièces. Ce type de machine est relativement fiable pour le peu qu'on ne leurs fassent pas prendre une douche. Sur les baies de stockages (que ca soit du file ou du block), on considère les disques comme des consommables, idem pour les SFP sur les switchs.
-
Un SSD, même dans la gamme professionnelle, lâche après quelques milliers de To écrit :
Dans la liste, les "pro" sont des gammes intermédiaires, il y a d'autres gammes en théorie plus endurantes.
Avant c'était de la SLC, mais maintenant il doit y avoir de la MLC, officiellement triée pour avoir une meilleure endurance, et bien sûr il y a normalement beaucoup plus d'overprovisioning.
Chez Intel il y a la gamme DC, dont le modèle le plus endurant semble être https://www.intel.fr/content/www/fr/fr/products/memory-storage/solid-state-drives/data-center-ssds/dc-p3700-series/dc-p3700-2tb-aic-20nm.html : 62Po d'écritures, soit 17 écritures complètes de ses 2To chaque jour pendant les 5 ans de garantie.
En revanche, à 3,7€/Go, on est très loin des prix grand public.
-
Un autre souci (quand j'ai cherché un SSD pour le serveur LaFibre.info) : Il n'est pas facile d'acheter un SSD de classe datacenter.
Les SSD sont vendu directement aux gros acteurs et impossible d'avoir les mêmes SSD que ceux utilisés par OVH ou Online.
-
Au boulot on a pris des SSD Pro, ça marche relativement pas mal pour un Cluster Ceph
-
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 :
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).
-
Comme promis par Octave un billet sur le blog :
]https://www.ovh.com/fr/blog/hebergements-web-post-mortem-incident-29-juin-2017#xtor=CS1-2-[WebHosting] (https://www.ovh.com/fr/blog/hebergements-web-post-mortem-incident-29-juin-2017#xtor=CS1-2-[WebHosting)
-
Je dirais que c'est relativement honnête.
-
mouais..
y'a quand même bcp de blabla qui tourne autour du pot... le passage
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 :)
-
C'est transparent mais y'a un peu de mauvaise fois quand même.
Mon passage préféré est celui là :
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
-
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
-
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...
-
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...
-
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. :)
-
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:
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
-
ça reste du OVH .. On n'apprend pas grand chose.
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,
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".
-
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,
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.
-
Donc on confirme qu'OVH est transparent et nous montre son amateurisme au grand jour.
Et on confirme bien que c'est à cause du watercooling! YES!
Franchement, vous trouvez ça étonnant, une fuite sur des tuyaux en plastique collés? Moi, non...
Je ne comprends toujours pas pourquoi OVH n'utilise pas de composant industriels pour les tuyaux et raccords du watercooling. Vu le prix d'une baie, le chiffre d'affaire qu'elle génère, c'est incompréhensible de vouloir faire des économies de quelques dizaines d'euros par baie, et compromettre autant la qualité pour si peu.
Au moins, ça aura fait un test de PRA forcé!
Et sinon, juste pour info, il me semble bien que ce genre d'équipement (baie EMC) est conçue pour être déplacée "à chaud" : on déplace les éléments constituants un par un. Donc si OVH a retardé cette relocalisation dans une salle sécurisé, c'est bien de leur faute.
Leon.
-
Donc on confirme qu'OVH est transparent et nous montre son amateurisme au grand jour.
Et on confirme bien que c'est à cause du watercooling! YES!
On me souffle qu'il y'a eu moins de 10 incidents liés à des fuites d'eau depuis la mise en prod du Watercooling. Moi je trouve ça honorable, c'est couillu de généraliser ça :)
Je ne comprends toujours pas pourquoi OVH n'utilise pas de composant industriels pour les tuyaux et raccords du watercooling.
Les photos que tu as vues, c'est l'ancienne version du watercooling, depuis de l'eau (héhé) a coulé sous les ponts ;)
-
Vu la quantité de spécialistes l'ont croit rêver par tant d'erreurs :o
OVH raconte l’enchaînement des événements qui ont conduit à la panne d’environ 24 heures de son service d’hébergement mutualisé. Un concours de circonstances doublé d’erreurs d’exploitation.
Une nouvelle illustration de la loi de Murphy, aussi appelée loi de l’emmerdement maximum ? C’est ainsi qu’OVH présente la panne qui a touché son datacenter parisien P19 et provoqué une interruption de services allant au-delà de 24 heures pour certains des 50 000 sites concernés par l’incident. Tout est parti, le 29 juin à 18h48, d’une fuite de liquide de refroidissement sur le système de ‘watercooling’ d’OVH, une des marques de fabrique de l’hébergeur. Du liquide qui parvient à s’immiscer dans une des deux baies EMC présentes sur P19, baie qui n’était pas refroidie par ce procédé mais se trouvait à « proximité immédiate »
Une proximité qui constitue une erreur évidente, ce que reconnaît d’ailleurs l’hébergeur roubaisien dans sa longue analyse post-mortem de l’incident, posté sur son site : « nous aurions dû installer [les baies EMC] dans des salles isolées, pour les protéger de ce type d’incident ». Et d’expliquer que le choix de cet emplacement résulte d’un malheureux concours de circonstances : les salles réservées aux équipements ne recevant pas le watercooling étaient en réfection au moment de l’achat des baies, en 2012. Manque de chance encore, les équipements EMC étaient tous voués à être remplacés par une nouvelle architecture maison, seules deux baies VNX 5400 restant en production chez OVH au moment de la panne, toutes deux hébergées sur le datacenter P19.
11 minutes qui changent tout
A ce concours de circonstances, s’ajoute un facteur aggravant : la mise à jour en cours d’un système d’alertes, basés sur des sondes, censé prévenir les techniciens par des messages audio lors d’événements anormaux (comme une fuite du liquide de refroidissement). « Dans le cadre de l’implantation à l’international de nouveaux datacenters, ce système de monitoring audio était en cours de mise à jour, afin que la voix de synthèse puisse diffuser les messages d’alerte dans plusieurs langues. En raison d’une malfaçon dans cet upgrade, réalisé le même jour, l’alerte audio n’a pas fonctionné correctement », écrit OVH. Retardant d’autant la prise en charge de l’incident.
Conséquence : le premier technicien n’est entré dans la salle touchée par la fuite que 11 minutes après son démarrage. « Ce retard a très certainement accentué l’impact de l’incident », reconnaît OVH. C’est ce qui explique peut être pourquoi la baie EMC aspergée est si gravement touchée. Malgré leurs efforts, les techniciens ne parviendront en effet jamais à la redémarrer. Tout comme seront inefficaces les efforts visant à remonter les disques de la baie touchée dans un second châssis, amené par la route depuis Roubaix..
Lire la suite c'est a mourir de rire
Source (http://www.silicon.fr/baie-emc-noyee-ovh-pris-eau-179983.html?inf_by=59613bda681db875658b488c)
-
On me souffle qu'il y'a eu moins de 10 incidents liés à des fuites d'eau depuis la mise en prod du Watercooling. Moi je trouve ça honorable, c'est couillu de généraliser ça :)
Tu es vraiment certain de tes sources pour ces 10 incidents? Tu penses vraiment que l'on peut connaitre de manière certaine le nombre d'incidents liés au watercooling chez OVH? Il est fort possible que même en interne chez OVH, cette information ne soit pas disponible de manière simple.
Les photos que tu as vues, c'est l'ancienne version du watercooling, depuis de l'eau (héhé) a coulé sous les ponts ;)
Ah, tu m'as l'air bien informé. Pourtant, les photos récentes de la com de chez OVH (Gravelines et autres) ne montrent pas autre chose : tuyaux en plastique PVC collés, absence de raccord stop industriels, etc...
Mais si tu as mieux, n'hésites pas à partager. Pareil, si tu as des infos sur les sécurités, les procédure de validation des installations que procèderait OVH sur son watercooling, n'hésites pas à nous faire partager, ça m'intéresse beaucoup.
Leon.
-
Il est fort possible que même en interne chez OVH, cette information ne soit pas disponible de manière simple
A moins que le plombier de OVH fréquente ce forum ? Il pourra nous dire combien de kilos de colle il a passé en une année :)
Ou faut envoyer (l'ex) 'inspecteur Colombo...
J'ai bien aimé la phrase "C'est des secrets industriels", au moins c'est pas aérospatiale qui va leur voler :)
-
Tu es vraiment certain de tes sources pour ces 10 incidents? Tu penses vraiment que l'on peut connaitre de manière certaine le nombre d'incidents liés au watercooling chez OVH?
Aucune idée, la personne qui m'en a parlé n'avait pas d'intéret à me mentir.
Après je sais qu'au support, il est interdit de dire au client que son serveur est HS à cause du watercooling, il faut parler de "panne materielle"
-
Je pense que le travail n'a pas été fait proprement ( comme c'est souvent le cas dans bien des domaines loin des règles de l'art )
J'ai vu cela dans l'aérospatiale ( domaine qui pourrait être une référence loin sans faux ) des copeaux d'acier qui ont passer tout les filtres de sécurité ( 20 ) et qui ont été retrouver sous la coiffe du lancer Ariane a H24 du lancement alors vos spécialistes vous les garder > > > j'ai d'autres histoires tout aussi incroyable , je parle de la france ailleurs cela sera un autre sujet ;D
Quand a installer du PVC sur une installation pareil cela en dit long sur les pots de vins et enveloppes qui ont changer de mains :o
Car oublier le rôle de l'eau dans des circuits électronique laisse perplexe sur les études et les experts qui ont été mandatés
De plus cela manque cruellement de transparence , de sérieux , et surtout de circuit de récupération des eaux ainsi que des pompes a air en cas d’arrêt de l’énergie Électrique cela arrive parfois ;D
-
Heu, t'en sais rien :)
-
De l'eau dans l'électronique c'est pas incompatible, je l'ai vu sur des anciens mainframe IBM ou la flotte chaude servait a chauffer les bureaux, quant ils ont été démontés il a fallu revoir le chauffage du batiment :D
Plus tard au CERN pour refroidir des éléments utilisés pour le LHC, seulement ca rien a voir avec les photos montrées, c'est des tubes gainés de tresse inox, et des racords professionels.
Enfin Leroimerlin doit faire des bonne affaires dans la région de OVH :)
-
Plus tard au CERN pour refroidir des éléments utilisés pour le LHC, seulement ca rien a voir avec les photos montrées, c'est des tubes gainés de tresse inox, et des racords professionels.
Certains équipements d'électronique de puissance et certains moteurs électriques sont refroidis par eau également. C'est utilisé dans l'industrie (machines électriques, certains robots), et c'est aussi utilisé pour les véhicules électriques et hybrides.
Et pour tous les équipements électriques industriels refroidis à l'eau, je confirme que ça ne ressemble pas à du bricolage avec des tuyaux en PVC. Tout ce qui est industriel, il faut que ça tourne longtemps, et les investissements sont en général amortis sur de nombreuses années, donc la fiabilité prime sur les économies de bout de chandelle. Ca devrait être pareil dans tous les datacenters, et heureusement, c'est en général le cas (sauf chez OVH).
Leon.
-
Après il faut voir un truc :
OVH peut tolérer de la panne, en informatique on a longtemps pensé "on n'en fait jamais trop". Un peu de bricolage malin qui fait chuter les couts, c'est loin d'être idiot.
-
Quand a installer du PVC sur une installation pareil cela en dit long sur les pots de vins et enveloppes qui ont changer de mains :o
Je ne pense pas. Met au moins le conditionnel...
Je pense qu'il y a largement plus de 10 incidents lié au wattercooling :
Article du JDN, écrit avec le témoignage de plusieurs anciens salariés d'OVH.
En effet, les serveurs sont tous refroidis à l'eau, qui passe dans des tuyaux et des blocs qui se fixent directement sur les composants. Fabriqués en Pologne, eux aussi. Que se passe-t-il en cas de fuite ? La théorie c'est qu'un contacteur présent au pied de chaque baie de serveur permet de détecter les fuites. Dans la pratique, si un serveur "fuit" tout en haut de la baie, il peut en mouiller d'autres avant que l'alarme ne se mette en marche. Si bien que les ateliers de réparation de serveurs d'OVH utilisent un outil rarement vu ailleurs : le compresseur. Celui-ci permet de souffler de l'air et de "vider" les serveurs de leur eau.
Ces ateliers de réparation sont l'un des éléments clés du succès d'OVH : en effet, l'hébergeur utilise du matériel d'entrée de gamme qui subit plus de défaillances que du matériel plus cher. Impossible d'avoir un chiffre sur le taux de défaillance chez OVH mais un hébergeur concurrent affirme avoir eu jusqu'à 10% de pannes par an avec du matériel similaire contre 2 à 3% avec du matériel haut de gamme. Mais OVH a mis en place une organisation militaire en cas de panne : une alerte est immédiatement envoyée à une flopée de techniciens présents 24/24 7/7 qui se précipitent sur la machine, changent la pièce défectueuse (la consigne n'est pas de comprendre l'origine du problème, mais uniquement de changer ce qui ne fonctionne pas, jusqu'au redémarrage du serveur) et remettent la machine en marche. En 30mn, tout est reparti. Idem en cas de serveur "mouillé". Un coup de compresseur et ça repart. A la différence près qu'en cas de fuite d'eau, les techniciens ont une interdiction formelle d'en parler. Il est vrai que "votre serveur a pris l'eau" pourrait effrayer des clients. Au final, OVH affiche des taux de disponibilité similaires voire meilleurs que certains de ses concurrents utilisant du matériel professionnel.
-
Après il faut voir un truc :
OVH peut tolérer de la panne, en informatique on a longtemps pensé "on n'en fait jamais trop". Un peu de bricolage malin qui fait chuter les couts, c'est loin d'être idiot.
Pas d'accord là dessus.
OK, quand tu fais une très grosse architecture, un très gros système informatique robuste à la panne de serveurs, avec une redondance par logiciel, je vois bien le concept.
Si OVH avait fait de l'hébergement mutualisé ou de l'hébergement de machines virtuelles avec tolérance de panne (c'est probablement le cas), alors oui, je comprends.
Mais quand tu loues des serveurs physiques à des clients, alors NON! Beaucoup de clients ne prennent qu'un ou 2 gros serveurs. Et parfois de serveurs très chers, à 300 ou 400€. Dans ce cas (très fréquent), le client ne tolère pas beaucoup la panne : la panne d'un seul serveur peut avoir des conséquences pour lui.
Là, le "bricolage malin" dont tu parles, c'est faire l'économie de quelques dizaines/centaines d'euros par baie... Des tuyaux et raccord en métal, des raccords industriels... Sachant qu'une baie rapporte plusieurs dizaines de milliers d'euros par an. Amorti sur 3 ans, a devient totalement incompréhensible.
Le watercooling, à la base, c'est une excellente idée, pour réduire les couts. Mais tout le bricolage qu'il y a autour est pour moi totalement incompréhensible:
* absence totale de clim : installer une clim qui soit capable de dissiper les 25% que ne sait pas traiter le watercooling, ça augmenterai grandement la fiabilité
* le watercooling en carton (pardon, plastique)
* les architectures électriques non redondées (plusieurs exemples qui montrent des onduleurs non redondés entre eux)
* etc...
Leon.
-
Tu vois Leon, le pbs est que c'est des financiers qui décident des stratégies et calculent les risques vs profit.
J'ai bossé dans des gros datacenter ou les 10 plus gros constructeurs sont présents, ils ont la meme politique, meme pour un client qui paye des 10ene de milliers d'€ par mois de contracts de support HW/SW et des clauses de "time to fix" de 4hrs, ca les refroidit pas de savoir pertinament que de stocker du matos de spare a 500km rend impossible de respecter ton contract, et la réfexion que on m'a fait est que ca coute moins cher de payer des pénalités exorbitantes une fois tous les 5 ans, que d'avoir du stock partout :(
OVH doit appliquer la meme stratégie, casser les couts et payer les dégats causés qui arrivent que rarement, c'est pas ma vision du professionnalisme, mais je suis technique, pas financier.
-
Après c'est vrai qu'OVH pourrait traiter différemment les serveurs à 400 € des kimsufi .. Il me semblait que c'était le cas avant et que les serveurs très chers avaient une double alim et étaients dans des salles "traditionnelles" - avec clim et sans eau ..
Si c'est bien confirmé qu'ils ne le font plus, c'est effectivement un problème. après, ça reste du OVH hein ... Le prix est inférieur, il n'y a pas de miracle pour obtenir ces prix c'est que des économies sont faites quelque part ... Mais c'est vrai qu'il pourrait à minima équiper les baies de serveurs haut de gamme avec du water cooling "professionnels" et les remettre sous climatisation comme avant.