VPS 2013 - Cloud - KO
Réponse OVH incident, aprés 2 jours...
"Nous avons un souci sur le reseau de l'infrastructure VPS."
A bon... ?
pfffff franchement, et dire que les VPS étaient au début, censés avoir une disponibilité supérieure aux dédiés !!!
Comment tu veux encore faire confiance à OVH aprés ça ?
fritz2cat va savoir les mystères du peering... Mais je ne pense pas, mon FAI est Numericable et surtout le serveur a tendance à remarcher miraculeusement après un reboot depuis le manager (qui marche une fois sur trois appartement).
C'est bizarre, mon script de "monitoring" me montre rien de flagrant côté réseau tout à l'air OK. Je vais ajouter un serveur tiers dans le test, car je ne me sers pas vraiment de ce VPS : pour le moment trop instable pour en faire quoique ce soit et donc je m'aperçois qu'il a "planté" à l'occasion.
Hors de question de payer un service complètement instable pour 11€/mois et un besoin ponctuel alors qu'un petit Kimsufi remplirait parfaitement le même rôle pour 3 fois moins cher. Je n'ai pas besoins des "fonctionnalités" d'un VPS - par contre c'est le seul type de serveur "pas cher" qu'OVH peut livrer rapidement en ce moment.
Envoyé par
teyla
bref, se faire avoir 1 fois.. ok, mais 2 fois, non, c'est du foutage de gueule !
Non, l'expression c'est "fool me once, shame on you, fool me twice shame on
me"
fritz2cat
23/08/2013, 06h43
Commandé 11 VPS il y a une semaine, voulant faire confiance à OVH sur la résolution des problèmes de ces derniers mois, hier 5 qui perdent le réseau, plus de ping, >90% de perte de paquets... le reboot sur le manager qui met 2 à 3h pour se faire, aprés que l'on ne vienne pas me dire qu'ils ont corrigé leurs problemes.. bref, se faire avoir 1 fois.. ok, mais 2 fois, non, c'est du foutage de gueule ! Et ça, c'est inacceptable pour nos clients, on passe pour des crétins, MERCI !
VPS@OVH NEVER AGAIN.
olivpulseheberg
22/08/2013, 03h19
Envoyé par
DmilZ
C'est un ping lancé depuis le serveur lui-même (régulièrement depuis la crontab).
Mais tu as raison, j'utilisais le nom de domaine, donc le ping n'est pas très parlant... J'ai corrigé mon script : ping serveur disant IPv4 et IPv6 et ping des gateways.
Edit: "cool" le server est encore injoigable... le script va pouvoir récupérer quelques infos utiles
Ça a l'air d'être encore un soucis récurrent, même 6 mois après le lancement :s
Ça fait penser au bug du début avec les VPS qui perdaient le réseau...
Pas de graphes te permettant de voir si c'est chez toi par hasard sur le manager v6 même si j'en doute... ?
Encore, une fois, ça aurait pu être l'auto migration, mais 3...
C'est un ping lancé depuis le serveur lui-même (régulièrement depuis la crontab).
Mais tu as raison, j'utilisais le nom de domaine, donc le ping n'est pas très parlant... J'ai corrigé mon script : ping serveur disant IPv4 et IPv6 et ping des gateways.
Edit: "cool" le server est encore injoigable... le script va pouvoir récupérer quelques infos utiles
Salut,
tu ping direct le serveur via son ip ou via le "nom de domaine" ??
visiblement via le ndd. Idem si tu pingues via ip ?
Bon le serveur tourne toujours au minimum avec :
- apache
- mysql
Le tout étant en phase de test, il y a une très faible consommation des ressources.
J'ai malheureusement réduit le script de monitoring de toutes les 5 minutes à 3 fois / jour. J'aurai du ajouter un envoi de mail parce que je retrouve le serveur KO encore aujourd'hui !
Pas moyen de le redémarrer pour le moment. Il n'y aucun monitoring de la part d'OVH sur ces serveurs ? (il ne répond même pas aux ping).
Edit : ça sent le problème réseau a plein nez.
### Check connexion réseau IPv4 ###
ping: unknown host us.dmilz.net
### Check connexion réseau IPv6 ###
unknown host
Je viens de rajouter des tests sur les passerelles, on verra bien...
Bon résultat du jour :
- aucun problème
- un script a tourné toute les 5 minutes (différents test dont ping et ping6 : 0 packet loss)
Différence par rapport au premier jour :
- Debian 7.0 à la place d'Ubuntu 12.04
- Noyau recompilé quasi à l'identique (ajout NAT IPv6 uniquement - c'est pas propre - ça rend service) / déjà recompilé le second jour
- script de "monitoring"
Je pense pas que ça vienne du noyau, recompilé quasi à l'identique. Donc soit souci externe (VMware... sur lequel on a aucune visu), soit la machine hiberne pour cause d'inactivité (version serveur donc ça serait surprenant), soit petit souci avec Ubuntu.
C'est uniquement une solution temporaire, donc je vais pas creuser plus loin que ça.
Wait & See
gaboul49
19/08/2013, 06h51
C'est bizarre en effet.
Si rien n'a été installé entre la livraison et le plantage c'est inquiétant.
Je l'ai reçu à 23h et il a planté pendant la nuit. Je n'ai pas vraiment eu le temps d'installer quoique ce soit...
Je n'ai rien trouvé de particulier dans les logs.
Hier le serveur était vraiment KO et impossible à redémarrer, sauf magiquement vers 13h il s'est mis à pinguer.
Par contre aujourd'hui j'ai pu le redémarrer assez rapidement. Par contre ce coup ci il n'y a pas de trou dans les logs on dirait "juste" que le réseau est tombé...
J'ai annulé le ticket d'incident et faire tourner des scripts à intervalles réguliers pour voir ce qu'il se passe...
gaboul49
18/08/2013, 13h50
C'est bizarre surtout que c'est une nouvelle installation. Je pense que c'est plutôt un de tes scripts qui bouffe la ram jusqu'à la mort subite.
As-tu plus d'info ? Des logs, panic kernel, graph munin, etc...
Même chose ce matin, VPS down depuis 07h...
Bonjour,
J'ai loué un VPS 2013 Cloud hier, livré vers 23H et trouvé KO ce matin. Impossible de rebooter depuis le manager, ni même réinstaller (down après 8H d'uptime, je pourrais me permettre...).
Ticket incident ouvert 1475239.
Je suis confus : je n'ai pas de chance du tout ou bien c'est toujours aussi "stable" ?
Autre question : lorsque le manager est en vrac, on peut encore espérer utiliser l'API (forcer un reboot par exemple) ou c'est peine perdue ?
Edit : pas de nouvelle pour le ticket d'incident mais le serveur a été rebooté à 13h05. Il y a un trou dans les logs entre 06h38 et 13h05. Les indicateurs du manager sont toujours KO.
