OVH Community, votre nouvel espace communautaire.

Incident VPS 2016 GRA


Robinsondu86
07/10/2016, 16h58
Merci pour le lien!

C'est une volonté de ne pas communiquer dessus visiblement... apparemment il faut juste valider la compensation pour y avoir droit (100% pour ma part).

C'est toujours ça de pris, même si rien n'indique si cela sera un avoir ou remboursement.

sich
07/10/2016, 14h43
Pour la SLA il faut aller ici : https://www.ovh.com/manager/web/#/billing/sla
Mais on est censé cliquer sur "activer" mais je ne vois pas l'option.... J'ai juste marqué qu'il y'a eu un soucis de 12H le 01/10...

hanico
07/10/2016, 13h54
Pour ma part, suite à cet incident, je n'ai reçu aucune communication / excuse de la part d'OVH :-/
Je vais ouvrir un ticket pour la demande de remboursement et c'est dommage que nous ayons à faire cela et que cela ne soit pas automatique...

J'hésite aussi à basculer sur un dédié ou cloud ssd vu que la sécurité n'est pas au rdv sur les vps et que les performances disques ne sont pas top

Tristan
03/10/2016, 09h32
Citation Envoyé par dbonin
Il reste encore de gros ralentissements.
même chose sur mon VPS :-(
et cela semble pire aujourd'hui (lundi) qu'hier...

wonker
02/10/2016, 21h09
À mon avis cela n'était ni un problème de manque de compétence, ni un problème de tests, ni un problème d'infra. OVH utilise CEPH à une grande échelle, et rencontre des bugs que des personnes à plus petit échelle ne rencontrent pas. Le problème, d'après ce que j'ai compris est uniqument un bug de CEPH. C'est pour moi la preuve de la limite de la possibilité d'avoir du HA à moindre cout à l'heure d'aujourd'hui. Plus on augmente la complexité dans le but d'avoir du HA, plus il y a de possibilités d'indisponibilité à cause de cette complexité.
CEPH est concidéré comme stable puisque utilisé sur énorménent de serveurs, mais cela reste une techno très jeune.
Nous enviagions à terme de faire nos propres cluster CEPH, mais cette épisode nous a fait peur et nous a fait prendre conscience de la compétence qu'il faut avoir pour gérer cette technologie. S'il a fallu 15 heures pour les équipes de OVH de trouver la solution (et que la solution soit de contourner le problème avec un while true… c'est à dire qu'il n'y avait aucune solution sans bricolage ou sans corriger le bug dans CEPH…) nous nous disons que nous n'aurions peut-être jamais trouvé cette solution.

jimmyy
02/10/2016, 15h04
Sich j'ai vu toutes les explications.

Cependant, quand il faut plus de 15h pour un retour à la normal, il y a aussi une problématique de compétences.

Des bugs cela arrive et il faut être en mesure de pouvoir les gérer.

L'infra n'est pas aussi conséquente que cela, ce qui laisse des SPOF. Comme l'explique par exemple https://2013.jres.org/archives/48/paper48_article.pdf , la moindre des choses aurait été d'avoir deux cluster par exemple, avec deux versions de Ceph.

Et là il s'agit simplement d'une Université, avec des moyens limités et dont ce n'est pas le travail.

sich
02/10/2016, 14h53
Le problème à été longuement expliqué dans la partie travaux.... Apparemment un "bug" sur ceph.
Je ne vais pas "quote" les explications je te laisse chercher (tout en bas).
Je ne sais pas au final si il faut accuser ceph qui a eu un gros bug ou si c'est un soucis de compétence. Je pense par contre que l'infra est conséquente et qu'on a du mal à s'imaginer ce que ça peux entrainer comme subtilité dans le management de tout ça.

C'est bien l'usage d'une telle techno qui a permit de tel prix. Sur une infra "standard" pour ce genre de chose on aurait été probablement bien + cher...


En théorie il faut demander la réparation pour la SLA, faut qu je retrouve où ça se trouve ça...

jimmyy
02/10/2016, 14h46
Quelqu'un aurait des nouvelles de la suite des événements ? Un geste commercial j'espère ?

Il est impossible que le cloud OVH dispose d'un SLA de 99,99 % ( moins d'1h d'indispo... par an ).

On comprends bien aussi qu'OVH ne propose pas de la HA. Aucun mode dégradé disponible. Aucun plan de secours cohérent. Des points individuel de défaillance bien présent, pertes de données.

On se rend compte aussi du manque de compétence, la technologie Ceph n'est pas maitrisé par les équipes, et n'a pas été assez testé.

De plus, il semble que certain clients avaient vu venir le problème ( exemple : https://forum.ovh.com/showthread.php...quelques-temps ), mais encore une fois le manque d'expert compétent pour écouter.

D'ailleurs, comme beaucoup, si on m'avais laissé travailler ( comme dans le cas d'un serveur dédié ), la panne aurait été corrigé en bien moins de temps.

Lorsqu'un Kimsufi, en comptant les crash disques, dispose d'un SLA plus fort qu'un Cloud HA, on est en droit de se poser des questions concernant la publicité mensongère et surtout la qualité de service.

dbonin
02/10/2016, 14h41
Il reste encore de gros ralentissements.

sich
02/10/2016, 07h55
ouaip, c'est aussi pour ça que j'ai pris des vps cloud.... Au final les VPS SSD fonctionnent mieux....
En + les VPS SSD sont dispo en public cloud, ce qui permet de prendre une VM à l'heure, et si l'host est ok on passe à l'heure...
Ou alors on peux faire des backups très facilement pour lancer une nouvelle install voir changer de DC...

Pour ma part je suis entrain de bucher pour monter une solution à base de 2 serveurs proxmox + un NAS ou 2 serveurs pour le storage (avec réplique via DRBD surement).

Sur le papier la solution VPS Cloud est censée nous protéger de ce genre d'incident... Mais j'ai déjà eu de gros soucis sur SBG, et maintenant GRA aussi

EDIT : En tout cas pour ma part le serveur ne veux pas redémarrer... Il était en mode rescue, mais impossible de revenir en mode "normal"... Cela fait 1H et ça mouline toujours à 0%....

dbonin
02/10/2016, 01h12
Au bout d'environ 30mn, le redémarrage s'est lancé.

Vu le temps passé à suivre les infos, le fait de devoir redémarrer nous-même les serveurs et de réparer la casse, je me demande si la solution de VPS CLOUD est vraiment intéressante.
J'avais basculé sur cette solution justement pour ne plus avoir à gérer les crashs disques et autres problèmes matériels...
Quant aux arguments commerciaux... ils en prennent un coup !

dbonin
02/10/2016, 00h59
Idem, des tables à réparer sur un.
Mais il reste un VPS qui ne veut pas redémarrer (opération figée à 0%)

Robinsondu86
02/10/2016, 00h50
Chez moi, quelques données ont disparues mais rien d'important à première vue (des topics d'un forum).

dbonin
02/10/2016, 00h50
J'ai un serveur qui ne veut pas rebooter.

Tristan
02/10/2016, 00h32
cela a pris du temps, mais mon vps a fini par redémarrer :-)
cela fonctionne, mais ça rame qq peu !
Le load averages fait le yoyo entre 1.5 et 10 alors qu'en temps normal il varie entre 0.5 et 1.0 (avec 4 cpu).

dbonin
02/10/2016, 00h10
Ils ont édité leur message... Je pouvais toujours attendre des nouvelles !

Comment by OVH - Saturday, 01 October 2016, 23:14PM
Si votre VPS est down, vous pouvez lancer le reboot.

Tristan
01/10/2016, 23h47
comme indiqué sur http://travaux.ovh.com/?do=details&id=20636 j'ai rebooté mon vps en mode rescue...
le reboot est à 80% depuisplus d' 1/4h, j'ai bien peur d'être bloqué :-(
c'est pareil de votre côté ?

dbonin
01/10/2016, 23h45
J'attends toujours...

Robinsondu86
01/10/2016, 23h18
Le serveur est de nouveau UP mais les services ne fonctionnent toujours pas correctement.

Edit : cela est presque revenu à la normal, enfin ! Vite une sauvegarde!

Robinsondu86
01/10/2016, 22h07
C'est une panne majeure, en espérant un retour rapide et sans pertes de données avant tout... et ensuite un dédommagement non limité à l'abonnement mensuel... mais faut pas rêver de ce côté là. Online va gagner des clients assurément.
Le VPS cloud d'OVH, c'est terminé.

sich
01/10/2016, 21h35
J'en connais qui vont pas beaucoup dormir cette nuit :

From War Room.

Bonsoir,
On recommande de ne pas rebooter votre VPS.

Le cluster Ceph impacté fonctionne sur 24 serveurs avec 12 disques
chacun. Nous avons un souci sur 6 hosts sur 24. C'est pourquoi toutes
les 5000 VPS ne sont pas down, car Ceph continue à fonctionner
sur les 18 serveurs restants. En tout, nous avons 6 Placement Group
(PG) en fail sur 10533 en tout sur le cluster. On essaie de faire
l'estimation le nombre de VPS réellement impactés car chaque donnée
est écrite sur beaucoup de PG.

Le probleme est suivant: nous avons 17 objects qui sont écrits
sur les disques dans la version 696135'83055746 et dans les
metadata de Ceph la version est 696135'83055747. Du coup Ceph
essaie de lire le fichier et dit que la version n'est pas bonne
puis s’arrête. Nous avons forcé Ceph à oublier ces fichiers,
mais ça ne fonctionne pas. Ceph se bloque car n'arrive pas à
ouvrir le PG (Placement Group).

On pense que le disque en défaut a flappé et Ceph a probablement
écrit le fichier en version 696135'83055747 sur ce disque et
n'a pas écrit les fichiers en version 696135'83055746 sur les
autres disques. Un probable bug dans la version qu'on fait
tourner en production 0.94.4. La dernière version est 0.94.9

On a un plan d'action en 4 points:

1) on va patcher l'outil d'import/export des objects pour lire
le fichier en version 696135'83055746 et forcer l’écriture en
version 696135'83055747. une équipe bosse dessus.

2) on regarde pourquoi Ceph se bloque quand on essaie de le
démarrer en forçant l'oublie de 17 objects. une autre équipe
bosse dessus.

3) dans le cas où tout ceci ne fonctionne pas, on va essayer
de démarrer le Ceph sans le 6 PG qui posent le probleme. Mais
les autres PG sur les 6 hosts seront UP.
cela veut dire qu'on va perdre quelques données. On ne sait pas
estimer qui serait impacté et qui ne serait pas, mais c'est
probable que le gros de VM vont revenir. Et les autres vont
probablement revenir avec FSCK dans la VM. Et peut-être on
aura quelques VM qui ne vont pas démarrer. C'est pourquoi on
vient de lancer un backup local sur chaque serveur de Ceph.
Il va prendre 6 heures environ.
Si jamais, je répète, si jamais on fait cette stratégie, on
va travailler sur les données du backup afin de récupérer
les données pour les éventuelles VM qui aurait perdu les
données. Mais quelques heures, quelques jours plus tard.
On espère qu'on n'aura pas à faire cette stratégie. une autre
équipe bosse sur cette stratégie. en cas où.

4) en parallèle, on a lancé la restauration de données pour
les VPS à partir de backup mais c'est hyper lent. On n'a pas
encore l'estimation de restauration. une autre équipe bosse
dessus.

Voilà le plan d'action en 4 points.

Amicalement
Octave

Sept
01/10/2016, 20h30
Citation Envoyé par mass_
Yep, very interesting, how?
The same problem.
Indeed how?

mass_
01/10/2016, 19h53
Citation Envoyé par Sept
How did you guys start your server? Mine is still stuck at : Your VPS area is under maintenance, please come back later
Yep, very interesting, how?
The same problem.

Sept
01/10/2016, 19h49
How did you guys start your server? Mine is still stuck at : Your VPS area is under maintenance, please come back later

sich
01/10/2016, 19h44
bah le mien est tjrs à 80% en reboot rescue.... pas de mail et situation bloquée.... Au point où j'en suis maintenant..... Heureusement que ça tombe un week end...

hanico
01/10/2016, 19h35
Mon serveur est de nouveau accessible mais bon j'attends un peu avant de considérer l'incident comme résolu...

- - - Updated - - -

Citation Envoyé par hanico
Mon serveur est de nouveau accessible mais bon j'attends un peu avant de considérer l'incident comme résolu...
J'ai parlé un peu vite, le serveur est accessible mais en lecture uniquement car lorsque j'essaye d'enregistrer un simple fichier texte cela ne fonctionne toujours pas

sich
01/10/2016, 18h11
Si on doit tout réinstaller alors qu'il en soit ainsi.... J'ai mes backups à jour et un script d'install auto.... Mais qu'on nous laisse bosser....
De toute façon si demain matin ce n'est pas revenu je suis bon pour louer un nouveau serveur sur SBG et me taper l'install avec en + modif de tous les DNS associés....

EDIT : Un petit mot d'Octave :
Bonjour,
Nous avons un souci technique sur l'un de cluster CEPH.
Il s'agit d'un cluster de 200 disques de 2TB. L'ensemble
de données sont copiés 3x sur les disques et donc la
capacité totale du cluster est de 120Go.

L'un de disques a été cassé et nous l'avons retiré. Pour
une raison on cherche encore, le cluster trouve qu'il
manque quelques données (17 objects) et se met en sécurité:
il s’arrête de fonctionner pour tous les données.

Les équipes travaillent sur le problème depuis ce matin
6h30. On a essayé beaucoup de choses depuis pour redémarrer
le cluster mais ça ne marche pas encore. Ca fait 11h30 que
certains devops sont sur le problème et donc on a décidé
de faire une pause d'1 heure et on recommence à bosser à 19h00.
On va commencer par faire un point entre toutes les équipes
qui bossent sur le souci Wroclaw (Pologne), Roubaix et Brest
au bureau par la telepresence. Le but est de voir si on a
raté quelque chose et regarder ce qu'on peut encore tenter.

Les données sont là. Il n'y a pas de raison qu'on ne trouve
pas comment remettre en marche le cluster.

Nous savons que l'impact est important. 5000 VPS avec le
stockage block qui est sensé fonctionner même quand ça ne
marche plus. On s’aperçoit que CEPH est très sensible et
en même temps ne réplique pas correctement les données. Il
est fort probable qu'on choisisse une autre technologie
dans l'avenir. Mais on n'en est pas là. Aujourd'hui, là
maintenant, ce qui compte c'est de remettre le cluster en
route.

Nous sommes sincèrement désolé pour cette longe panne.
Soyez rassuré sur une chose: on va bosser jusqu'à ce que
vos VPS soient UP. Malheureusement je ne peux pas encore
vous donner d'ETA car on n'a pas encore trouvé l'origine
du souci.

Amicalement
Octave

stef83
01/10/2016, 17h39
Comment by OVH - Saturday, 01 October 2016, 13:13PMOur team is still on it, the cluster is still lock, we are trying to unlock it.

Comment by OVH - Saturday, 01 October 2016, 16:56PMWe are still trying do debug what is locking the ceph cluster. Some hexadump has been done without succes for the moment.
In parallel we are trying to restore some backup


Comment by OVH - Saturday, 01 October 2016, 17:20PMTo summarize - we had 1 failing HDD. After removing OSD from it, 17 objects were unfound in Ceph after recovery. 7 of them are in 6 PGs which we cannot query or tell them to lose the objects. We have tried to manually force operations but did not succeed. We are still looking for a solution to unblock those PGs.

Robinsondu86
01/10/2016, 17h29
Je fais parti du lot... (discussions générales) et les nouvelles ne sont guère rassurantes. Comme beaucoup j'ai opté pour un VPS cloud pour la haute disponibilité et la sécurité des données, et là on sent venir la nouvelle "perte totale de vos données..." et si ce cas se produit, c'est au revoir OVH et mes 12 ans d'ancienneté.

sich
01/10/2016, 16h40
j'ai eu l'alerte monitoring vers 7H, ce qui fait que ça a du tomber vers 6H45.... M'enfin c'est MySQL qui a planté...
Depuis j'ai essayé de restart en rescue (dixit ce que le support raconte à chaque fois) mais du coup le serveur est planté dans sa procédure de reboot...

Une chance pour moi l'immense majorité de mes VPS sont sur SBG.... M'enfin SBG a ses propres soucis aussi...

EDIT : ça sent pas trop bon pour le moment : We are still trying do debug what is locking the ceph cluster. Some hexadump has been done without succes for the moment.
In parallel we are trying to restore some backup

stef83
01/10/2016, 16h20
Pour ma part ça commencé vers 6h15/6h30 ce matin. Que des ecommerces down...

hanico
01/10/2016, 15h42
Citation Envoyé par sich
Toujours est il que la petite blague commence à ne plus être trop marrante.... Bientôt 9H de coupure...
Oui et plus de màj sur travaux.ovh.net depuis plus de 2H30 ...

sich
01/10/2016, 15h37
Toujours est il que la petite blague commence à ne plus être trop marrante.... Bientôt 9H de coupure...

buddy
01/10/2016, 15h26
Bonjour,

Citation Envoyé par hanico
Du coup, je risque de perdre certains de mes clients avec une indispo aussi importante et je me doute qu'ovh ne pourra me dédommager en conséquence :/
OVH remboursera en fonction de ce pour quoi vous avez signé lors de l'acquisition du VPS ... (vu le prix, presque rien)

pour le SLA
Le SLA correspond à l’engagement d’OVH sur la disponibilité du service (hors opérations de maintenance prévues et programmées).

La plateforme VPS bénéficie d'une stabilité et d'une disponibilité à toute épreuve. Lorsque vous louez l'un de nos serveurs virtuels, nous vous garantissons la continuité dans votre activité, chiffres à l'appui.

Dans le cas où nous ne parviendrions pas à remplir nos engagements, nous nous engageons à rembourser 5% de l’abonnement mensuel par heure de retard dans la limite de 100% du montant mensuel du produit concerné.

Ce dispositif s’applique sur la gamme VPS Cloud uniquement.
Les entreprises qui proposent un SLA (à hauteur des pertes réelles que vous pouvez avoir propose des VPS beaucoup beaucoup plus cher)

wharenn
01/10/2016, 14h37
Bonjour,
De mon côté, les premiers impacts sur mon VPS ont eu lieu à partir de 6h40 ce matin et il est 14h30. Ça fait 8h d'indispo et ça fait beaucoup...

hanico
01/10/2016, 14h30
Ma confiance diminue aussi fortement car j'avais choisi ce type d'offre pour être tranquille et garantir un service avec très peu d'arrêt à mes clients.
Du coup, je risque de perdre certains de mes clients avec une indispo aussi importante et je me doute qu'ovh ne pourra me dédommager en conséquence :/

En plus sur travaux, ils disent NO ETA donc vraiment pas rassurant...

Le bon côté c'est qu'on ne devrait plus avoir d'ennui pendant plusieurs années après une panne pareil .... (enfin si la SLA annoncée était respectée...)

sich
01/10/2016, 14h17
Oui j'en suis à me demander si je ne vais pas me monter 2 serveurs de la gamme hosting et 1 nas pour faire mon hébergement de VPS.... Mais c'est difficile de s'aligner sur les prix de la gamme VPS 2016 quand on commence à monter une infra et qu'on a pas les volumes qui vont bien derrière...

Toujours est il qu'avec le crash sur GRA ajd et les problèmes de stockage sur SBG depuis 1 mois, ma confiance dans la gamme VPS Cloud d'OVH diminue de plus en plus...

Gaston_Phone
01/10/2016, 13h31
Citation Envoyé par hanico
Savez vous si des dédommagements sont prévus dans ces cas la ?
S'il y a dédommagements, je ne ne pense pas que cela ne puisse dépasser ton mois de location au prorata du temps de panne.

jimmyy
01/10/2016, 13h29
Bonjour,

Je confirme, j'ajouterai d'ailleurs que cela à démarré à partir de 7h de mon côté.

SLA de 99.99% non respecté.

J'espère en effet que le service commercial OVH fera un geste et surtout que cela ne se reproduira plus.

Quasiment 5000 VPS impacté tout de même, ca doit faire une quantité impressionnante de projet down.

hanico
01/10/2016, 13h19
Bonjour,

Depuis environ 9h ce matin, mon VPS ne fonctionne plus (ou avec d'énormes lenteurs )
Le support m'a indiqué que c'était en lien avec cet incident http://travaux.ovh.net/?do=details&id=20636

Avec une SLA de 99.99%, je suis étonné que le problème ne soit toujours pas résolu au bout de 4heures...

Savez vous si des dédommagements sont prévus dans ces cas la ?