OVH Community, votre nouvel espace communautaire.

VPS - yoyo UP/DOWN pendant 1h :(( ...


iso8859
30/03/2013, 17h36
Perso pas de changement, la tache reboot est toujours "blocked"

edit: sur la ML VPS on à un retour d'octave qui indique que le pb est identifié mais n'est toujours pas résolu et que toute l'équipe VPS bosse dessus.

Reclad
30/03/2013, 16h22
Effectivement ça fonctionne à nouveau après reboot.

emettbrown
30/03/2013, 15h48
Des news pour moi
Reboot (vu que maintenant c'est possible) , test ok : la vitesse du site semble acceptable.

Je commence a sourire mais je m'emflamme pas

J'espere qu'ils nous feront pas le coup de la version gamma ça serait minable.

Reclad
30/03/2013, 15h41
Assez déçu également, je pensais qu'ils avaient prévu le coup. Bon, le vps est encore en status gamma je pense qu'on ne pourra pas se plaindre de quoi que ce soit, ni réclamer des compensations. :/

J'attends des nouvelles de leur part en tout cas.

EDIT : Ah bah, l'offre ne semble plus être en Gamma. Ouch, ça va être dur pour OVH.

mourad_K
30/03/2013, 15h39
oui c'est vrai ça peut être rageant d'avoir un tel problème
surtout quand on est déjà en production

j'en suis sûr que l'équipe ovh est déjà sous pression pour résoudre
le ou les problèmes et en trouver l'origine afin de continuer d'assurer
leur qualité de service dont je n'ai pas eu à me plaindre personnellement
jusqu'ici. : )

emettbrown
30/03/2013, 15h30
La meme pour moi. HS depuis hier. Je pense que ça va me couter des clients...
Déçu par le peu d'explication d'ovh malgré une qualité de service honteuse

mourad_K
30/03/2013, 15h15
Bonjour

Même soucis

ni ping ni service http

je m'en suis aperçu y a quelques minutes

j'ai donc été directement sur le nouvel espace client ovh
https://www.ovh.com/manager/web/inde...sxxxxx.ovh.net

j'ai rebooté le vps, attendu un peu, parcouru les forums et vu le ticket travaux en cours

depuis peu le ping est revenu, je ne comprend pas pourquoi le service http est maintenu en rouge

Jielde
30/03/2013, 13h33
Même soucis pour le VPS d'un de mes client, il est en panne depuis hier et aucune réponse d'OVH pour le moment.
Mon client gère une boutique e-commerce pour un restaurant, et je vous explique pas la panique actuellement.

Pouvez-vous nous donner des explications pour le vps21546.ovh.net ???

renaudcuny
30/03/2013, 12h24
ps: si quelqu'un chez OVH lit ce thread, pourquoi ne proposez-vous pas d'IP failover qui puisse marcher entre VPS et dédiés ? Que ce soit pour des soucis sur l'infra, ou pour une erreur de conf sur la VM (responsabilité du client, on est d'accord), il est des cas où ça serait quand même bien pratique. Au client la responsabilité complète de se créer un 2ème VPS ou dédié, et de gérer le pointage, exactement comme cela fonctionne actuellement sur les dédiés ...

renaudcuny
30/03/2013, 12h08
@iso8859: idem,

/vps/vps20265.ovh.net/tasks/8623

{
progress: 8
id: 8623
type: "rebootVm"
state: "blocked"
}

Ticket de support créé il y'a plus de 2h et toujours rien !

laurentw
30/03/2013, 12h07
Même soucis pour mon vps cloud à 12h06 donc ça fait quelques heures que tout est down or on est censé avoir un SLA de 99.99%!

iso8859
30/03/2013, 09h38
vps/vps21180.ovh.net/tasks/8667 =>

{
"progress": 4,
"id": 8667,
"type": "rebootVm",
"state": "blocked"
}

vps/vps21182.ovh.net/tasks/8666 => blocked !!

Et bien entendu je ne reboot pas par plaisir, ces machines ne répondent plus du tout.

SLA 99.99% => je rigole et je suis très déçu car j'ai conseillé OVH et maintenant que dire aux personnes avec qui je travaille?
J'ai perdu en crédibilité.

Je conseille d'aller chez Ikoula, le support est bien plus réactif et les offres terminées !
Je suis en train de migrer cet ensemble de VPS

"vps22257.ovh.net"
"vps21214.ovh.net"
"vps22296.ovh.net"
"vps21182.ovh.net"
"vps21181.ovh.net"
"vps22256.ovh.net"
"vps21180.ovh.net"
"vps22258.ovh.net"

A terme c'est au minimum 100 VPS que j'aurais pris.

Rémi
rt6-ovh

jerome72
30/03/2013, 09h35
Selon pingdom, j'ai eu plusieurs downtime dans la nuit, entre minuit et 2h

renaudcuny
29/03/2013, 18h38
Re-hello,

Idem, toujours pas d'accès stable...

Reclad
29/03/2013, 18h33
Bon ils font quoi ovh ? Pourquoi ils ne nullroute pas ? Ça commence à faire long..

@Jerome72 : Ouep, ça vient de reprendre.

jerome72
29/03/2013, 18h33
Ca allait mieux et là j'ai l'impression que ça recommence... Je n'arrive plus à accéder à mon VPS... Pareil de votre côté ?

dedinux
29/03/2013, 18h20
Le flood réseau a commencé vers 15h d'après mon munin.

Reclad
29/03/2013, 18h09
J'en suis pas certain mais en désactivant le promiscuous, je lag beaucoup moins :

Code:
ifconfig eth0 -promisc
Toutefois, c'est peut-être ovh qui ont résolus le soucis.

jerome72
29/03/2013, 17h57
Je reçois la même chose que toi avec ta commande tcpdump, et je suis aussi sur une ip en 5.135

Par contre je suis incapable d'interpréter tout ça...

renaudcuny
29/03/2013, 17h57
Effectivement je n'avais pas fait le lien, mais je ne peux pas accéder non plus à un dédié en 5.135.164.x ...

Reclad
29/03/2013, 17h52
Vous utilisez des vps "cloud" chez ovh ? (Range IP : 5.135.X) ?

Pour ma part, je soupçonne une attaque assez massif Ddos sur cette range ip et en particulier sur l'addresse : 52.ip-5-135-151.eu (Qui n'est pas mon adresse)

tcpdump -i eth0 :
Code:
17:50:30.903283 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903286 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903288 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903393 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903395 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903511 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903514 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903628 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 51074, length 12
17:50:30.903630 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903736 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903740 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903847 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903851 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903957 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.903960 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.904066 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:50:30.904068 IP 192.88.99.1 > 52.ip-5-135-151.eu: IP6 2001:0:4137:9e76:14e7:3f95:933b:5f8e > 2002:587:9734::587:9734: ICMP6, echo request, seq 54810, length 12
17:51:31.529481 IP 157.56.106.170 > 52.ip-5-135-151.eu: IP6 2001:0:9d38:6ab8:452:2546:aabb:e429 > 2002:587:9734::587:9734: ICMP6, echo request, seq 51457, length 12
17:51:31.529482 IP 157.56.106.170 > 52.ip-5-135-151.eu: IP6 2001:0:9d38:6ab8:452:2546:aabb:e429 > 2002:587:9734::587:9734: ICMP6, echo request, seq 51457, length 12
17:51:31.529685 IP 157.56.106.170 > 52.ip-5-135-151.eu: IP6 2001:0:9d38:6ab8:452:2546:aabb:e429 > 2002:587:9734::587:9734: ICMP6, echo request, seq 51457, length 12
17:51:31.529687 IP 157.56.106.170 > 52.ip-5-135-151.eu: IP6 2001:0:9d38:6ab8:452:2546:aabb:e429 > 2002:587:9734::587:9734: ICMP6, echo request, seq 51457, length 1
Il y a également des attaques via le protocole "255".

Ce n'est pas mon IP, et j'ai pourtant les mêmes soucis que vous. C'est peut-être une attaque qui fait ramer tout le cluster.

Vous avez des idées ?

Par ailleurs un ping sur cette adresse :
Code:
rk@rk-P5K:~$ ping 52.ip-5-135-151.eu
PING 52.ip-5-135-151.eu (5.135.151.52) 56(84) bytes of data.
From 121.ip-5-135-149.eu (5.135.149.121) icmp_seq=200 Time to live exceeded
From 211.ip-5-135-148.eu (5.135.148.211) icmp_seq=200 Time to live exceeded
From 13.ip-5-135-150.eu (5.135.150.13) icmp_seq=200 Time to live exceeded
From 58.ip-5-135-150.eu (5.135.150.58) icmp_seq=200 Time to live exceeded
From 32.ip-5-135-151.eu (5.135.151.32) icmp_seq=200 Time to live exceeded
From 139.ip-5-135-149.eu (5.135.149.139) icmp_seq=200 Time to live exceeded
From 121.ip-5-135-149.eu (5.135.149.121) icmp_seq=255 Time to live exceeded
From 32.ip-5-135-151.eu (5.135.151.32) icmp_seq=255 Time to live exceeded
From 139.ip-5-135-149.eu (5.135.149.139) icmp_seq=255 Time to live exceeded
From 211.ip-5-135-148.eu (5.135.148.211) icmp_seq=255 Time to live exceeded
From 13.ip-5-135-150.eu (5.135.150.13) icmp_seq=255 Time to live exceeded
From 58.ip-5-135-150.eu (5.135.150.58) icmp_seq=255 Time to live exceeded
From 168.ip-5-135-150.eu (5.135.150.168) icmp_seq=255 Time to live exceeded
From 121.ip-5-135-149.eu (5.135.149.121) icmp_seq=357 Time to live exceeded
From 139.ip-5-135-149.eu (5.135.149.139) icmp_seq=357 Time to live exceeded
From 32.ip-5-135-151.eu (5.135.151.32) icmp_seq=357 Time to live exceeded
From 13.ip-5-135-150.eu (5.135.150.13) icmp_seq=357 Time to live exceeded
From 211.ip-5-135-148.eu (5.135.148.211) icmp_seq=357 Time to live exceeded
From 58.ip-5-135-150.eu (5.135.150.58) icmp_seq=357 Time to live exceeded
L'adresse renvoie sur plein d'ip différentes sur le même range. Un soucis de configuration chez ovh ?

renaudcuny
29/03/2013, 17h29
J'ai eu pas mal de soucis, mais encore une fois, je pense que c'est juste l'histoire de quelques ajustements de leur côté pour parfaire les mécaniques. Je retesterai dans 1 mois ou 2, mais pour le moment c'est encore un peu juste pour de la vraie prod.

jerome72
29/03/2013, 17h11
En ce qui me concerne, j'ai le VPS depuis deux mois, et c'est la première fois que j'ai un souci visible. Je suis étonné de ton choix de retourner au dédié, je pensais que le vps était plus secure que le dédié vu qu'il ne risque pas de panne matérielle.

renaudcuny
29/03/2013, 17h01
Ok, c'est rassurant d'un côté, mais de l'autre il s'est écoulé près de 30min entre le post de mon message et le ticket dans les travaux. Et pour l'instant ça merde toujours. Ca fait un peu long pour de la détection de panne ...

Je suis et je reste fidèle client d'OVH, mais après plusieurs semaines de tests intensifs, je dois avouer que le VPS Cloud est loin d'être aussi fiable qu'un dédié pour de la production ... Donnons leur encore quelques mois...

En attendant je commande un SP 16G et je migre avec regret ce que j'avais sur le Cloud 4.

jerome72
29/03/2013, 16h53
Merci beaucoup dedinux, en fait ça me rassure. Je n'avais pas eu l'idée d'aller regarder les travaux.

dedinux
29/03/2013, 16h46
Même problème : http://travaux.ovh.net/?do=details&id=8346

jerome72
29/03/2013, 16h41
Je rencontre le même type de problème depuis environ 30mn. Mon VPS cloud 1 ping bien, mais je ne peux pas y accéder par http, ni via ssh. Lorsque j'essaie de prendre la main en SSH il met des plombes à me demander le password, et ensuite au bout d'une plombe la connection est fermée.

J'ai essayé de rebooter via le manager V6, mais je ne sais même pas si le reboot à fonctionné. Et j'ai eu le même message d'erreur que toi sur l'interface du manager.

Avec webmin pareil, impossible d'y accéder, ça rame jusqu'a l'impossibilité d'afficher la page.

Bizarrement, quand ça a commencé et que j'ai pu regarder sur le serveur, ni CPU ni RAM ni SWAP n'étaient surchargés... Je ne sais pas trop où regarder.

La chance que j'ai c'est que j'ai pu immédiatement basculer mon site vers mon mutu...

Nowwhat
29/03/2013, 16h24
Citation Envoyé par renaudcuny
J
Une erreur s'est produite lors du chargement des informations. (vps20265.ovh.net : No data to check for type double)
Je mettrai ça dans le ticket.

renaudcuny
29/03/2013, 15h59
Je précise que dans le manager (le nouveau) j'ai ce message en haut en rouge :

Une erreur s'est produite lors du chargement des informations. (vps20265.ovh.net : No data to check for type double)

Super, ça veut dire quoi ?

renaudcuny
29/03/2013, 15h54
Hello,

Si quelqu'un du service technique peut aller faire un tour sur les tickets, j'ai de très sérieux problème de stabilité depuis 1h sur mon vps 20265 (un Cloud 4). La connexion fonctionne aléatoirement, et maintenant ça ne veut plus rebooter sous prétexte que c'est déjà en train de rebooter. Décidément je regrette le mode rescue des dédiés pour comprendre ce qui se passe ...

Cela fait 2-3 semaines que je n'ai que des soucis sur ce VPS, ça avait pourtant marché nickel au début, je commence à désespérer ...

Si d'autres clients sont dans le même cas que moi, ça m'intéresse de le savoir, je me sentirai moins seul dans mon malheur ...