A quel point un support utilisateur peut-être mauvais?

Share and options

1. Synopsis

Depuis que j'ai souscris à un serveur mutualisé, chez un fournisseur d'accès dont je tairais le nom, j'ai des soucis érnomes.


  • Le premier d'entre eux, entre autres, est le fait que l'IP qui sort du réseau que le reste du monde voit quand je fais une connection sortante depuis ce serveur est une IP interne à leur réseau (dieu seul sait pourquoi, ils ont pris des IP publiques pour celà). Ce qui à la facheuse tendance à invalider mon reverse DNS, et me voir refuser les connection à pas mal de serveurs IRC; et provoque par la même occasion des problèmes avec mon serveur SMTP.
  • Le second, la vitesse du disque dur. Je jouis d'un disque dur qui fonce à une vitesse de pointe de 3mo/s... Ok, un SAN réseau, c'est forcément plus lent qu'un disque dur. Mais là, on est au bord du gouffre.
  • Le troisième, le support utilisateur est extrêmement mauvais.


J'ai eu la chance de pouvoir résoudre le premier avec une simple règle iptables en SNAT. Il s'agit tout simple de réécrire l'ensemble des paquets sortant de la machine avec la bonne idée. Jusqu'ici, tout va bien, mais le problème c'est que tous les 3 jours, la machine tournant toujours (elle répond au ping) tous les services sur lequels je tente une connection timeoutent, la seule solution est le reboot hardware.

Etre obligé de redémarrer physiquement un serveur dédié tous les 4 jours, à cause d'un SAN qui semble buguer, c'est la honte.



2. Ma demande de support

C'est pourquoi j'ai décidé de contacter leur support (je vous passe, bien sûr, les tentatives que j'ai faites il y a un mois, et deux semaines), comme ceci:

Bonjour,

Tous les 3 à 4 jours, je suis obligé de faire une procédure de reboot hardware via le manager parce que les connections SSH sur mon RPS timeout...

Je deviens fou, c'est une conf Debian Etch (presque) par défaut. J'ai tenté en désactivant un paquet de services. La conf de chacun de ces services est identique à celle que j'avais sur des dédiés chez vos concurents qui tenaient l'uptime des mois.

Et surtout, ce problème est récurent, régulier, presque timé comme une horloge, je commence à soupçonner que le matériel à sincèrement des problèmes.

Il n'y a pas longtemps je me suis connecté en mode rescue et effectué tous les tests, tous sont passés sans problèmes.

J'ai fait une règle iptables de firewall assez étrange, pour réécrire tous les paquets sortant avec mon IP failover, afin de profiter de mon reverse DNS quel que soit le service, peut-être que ça dérange vos outils interne?

J'avais déjà eu les même symptômes sur une machine dont le disque dur était plein. Là, ce n'est pas le cas. Je soupçonne donc le stockage réseau de merder sur ma machine, mais le pire, c'est que j'en sais foutrement rien.

J'ai aucune trace, dans un aucun log, d'aucun fonctionnement anormal. Tout tourne très bien logiciellement sur la machine, aucun process ne bouffe toute la ram ou ne me rempli le disque de logs. Mais une fois que je ne peux plus me connecter à la machine, elle est physiquement là, je peux la pinger, je ne peux juste plus accéder à aucun service qui utilise de près ou de loin le disque dur (timeout à tous les niveaux, mais la connection réseau marche, que ce soit sur les serveurs imap, bouncer irc, ssh, httpd)...

S'il vous plaît, la dernière fois que j'ai soumis un ticket d'incident pour ce problème j'ai juste eu en réponse un "si c'est un problème logiciel nous ne pouvons pas intervenir". Moi je vous dis que y'a une chance sur mille pour que ce soit un problème logiciel.

Alors ma question est simple:
Est ce que réécrire tous les paquets sortants (y compris ceux pour le SAN donc) peut perturber le fonctionner de la machine ?

Si non, trouvez moi le problème, votre machine bug.

Cordialement,

Pierre.

Ce à quoi je m'empresse de rajouter, me disant que je n'étais pas assez précis:

(hydralisk) 22:41:41 ~ % hdparm -tT /dev/sda

/dev/sda:
Timing cached reads:   1148 MB in  2.00 seconds = 573.94 MB/sec
Timing buffered disk reads:    8 MB in  4.51 seconds =   1.77 MB/sec
(hydralisk) 22:42:10 ~ % uptime
22:42:51 up  7:45,  2 users,  load average: 0.52, 0.40, 0.16
(hydralisk) 22:42:51 ~ %

Trouvez l'erreur.

Puis pour finir, retrouvant un peu d'humour dans tout ça:

J'ai oublié de préciser, si j'avais voulu brancher un HTTPd sur une clé USB abimée en USB 1.0, j'aurais directement utilisé une connection RTC et un pentium 166mhz, ça aurait été aussi rapide...



3. Un technicien bienveillant

Quelques jours après, la réponse du service de support technique aux utilisateurs me réponds:

Bonjour,

J'ai bien pris en compte votre demande et vous remercie de l'intérêt que vous portez à Ovh.

Que faite vous exactement avec le serveur ?
Les temps d'acces sur un RPS sont forcement moins important que sur un dedie avec un HDD dedie, puisque vos disque sont mutualise sur un SAN.

Je reste à votre disposition pour tout renseignement complémentaire.

Cordialement, "nom supprimé".

Heureux comme jamais! Pour la première fois depuis 2 mois, un technicien semble enfin me demander des détails pour m'aider à résoudre le problème!
Plus que motivé, je m'empresse de préciser les symptômes, de manière joviale et enjouée:

Bonjour,

Merci pour la réponse.

> Bonjour,
>
> J'ai bien pris en compte votre demande et vous remercie de l'intérêt que vous portez à Ovh.
>
> Que faite vous exactement avec le serveur ?

Là, à l'instant même, je le reboot, puisque tous les services sont en train de me lacher dans les mains à base de timeout (mais ceci dit il est joueur il réponds toujours au ping). Sinon, en temps normal, il héberge un simple LAMP, un serveur IMAP/IMAPS/SMTP, un bind9, et un bouncer irc, ni plus, ni moins.

Tous les démons sont en standalone (pas de inetd/xinetd), la pluspart des services sont en SSL, et en utilisation normale, à peine 20% la ram RAM est utilisée.

> Les temps d'acces sur un RPS sont forcement moins important que sur un dedie avec un HDD dedie, puisque vos disque sont mutualise sur un SAN.

Ça je comprends bien, mais là à faire moins de 2mo/s faut pas déconner. À ce débit là, gérer une base de donnée sur un serveur un poil chargé c'est de l'ordre de l'impossible. De plus avoir un débit lamentable ne veut pas forcément dire être obligé de rebooter le serveur tous les 3 jours, comprenez bien que pour un dédié c'est inacceptable.

Et là, comble de bonheur qu'un technicien s'occupe de moi, je me mets en position d'attente de la réponse, avec impatience et joie!



4. Là ou le support est le maillon faible

C'est alors que je reçois enfin, après quelques heures (voir jours) la réponse tant attendue! Oh joie! Oh magnifique! je m'empresse d'ouvrir alors le message du technicien, peut-être à-t-il réparé le réseau?? Peut-être le SAN était-il trop chargé? Peut-être la carte réseau de ma machine physique avait un problème?

Bonjour,

De rien

Je reste à votre disposition pour tout renseignement complémentaire.

Cordialement, "nom supprimé".

Désespoir. Les techniciens de ce fournisseurs de serveurs dédiés, numéro en France, aussi bon soient-ils, ne savent pas lire!
Quelle tristesse, voilà, mesdames et messieurs, pourquoi l'école est très importante pour les enfants, au moins du CP jusqu'à la fin du collège!



5. Le desespoir

Dans un ultime second souffle juste avant ma mort cérébrale face à tant de mauvaise volonté, j'ai réussi à écrire une ultime demande.
Peut-être un jour arriveront-il à la lire...

Excusez moi, mais ça ne réponds pas à mes questions.

Je vous ait répondu, vous me dites juste "de rien".

Pourquoi le SAN arrête de répondre à ma machine tous les 3 jours, est ce iptables qui réécrit l'adresse source des paquets qui pourrait en être la cause ?

J'ai posé cette question dans presque tous mes envoyés au support et personne n'a jamais répondu, s'il vous plaît, une réponse franche, est ce que vos techniciens savent vraiment mettre un place un SAN? Si oui, ils peuvent répondre, si non, je me demande vraiment comment les RPS peuvent tenir.

Merci d'avance pour une réponse rapide.

De moins en moins cordial,

Pierre.



6. Conclusion

Peut-être un jour aurais-je un dédié qui n'ait pas besoin d'être redémarré tous les 3 jours. La suite dans le prochain épisode!