Auteur Sujet: Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark  (Lu 21657 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
OVH promet un "Internet neutre et sans bridage" nous allons voir que ce n'est pas le cas systématiquement, mais surtout que les clients ne sont pas prévenus.

Une des sociétés victimes de ce bridage est 4Gmark, vous savez le test de débit proche d'un usage client (et donc sur une seule connexion TCP).
La cause du bridage réalisé par OVH, est probablement une trop grosse consommation de data.
Une hypothèse est aussi que 4Gmark n'a pas pris les options nécessaires vu sa consommation.

Édit : On sait depuis que 4Gmark a pris un serveur à 122€/mois, qui dispose d'une bande passante de type "Garantie" de 500 Mb/s vers Internet (OVH vers Internet). Le trafic cumulé, consommé sur le mois de février, est de seulement 1 To, ce qui est très faible (on dépasse rarement les 10 Mb/s de débit moyen sur 5 minutes) :


4G mark, qui avait deux serveurs chez OVH, a supprimé le serveur bridé et ses mesures.
4Gmark est maintenant présent sur le cloud de Mediactive network.

L’application 4Gmark :


A l'origine de mes recherches, de tests excessivement mauvais, qui ont d'ailleurs été remontés sur twitter :





L’application 4Gmark utilise deux serveurs qui sont tous les deux chez OVH (le premier sur le datacenter de Roubaix et le second sur le datacenter de Gravelines)
J'ai repéré des phénomènes étranges sur le serveur de Roubaix (très forte gigue qui fait que les paquets arrivent dans le désordre à très haut débit) mais il est difficile d'en savoir plus sur l'origine, sans trace coté serveur. De plus la gigue n’empêche pas d'avoir des débits corrects - en tout cas à des années lumières du serveur de 4Gmark de Gravelines.

Je concentre donc mon investigation sur le serveur 4Gmark de Gravelines.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #1 le: 28 février 2015 à 17:18:47 »
Débit en téléchargeant un fichier de 125 Mo sur le serveur 4Gmark de Gravelines depuis LaFibre.info (Adeli) : on est à 12,5 Mb/s alors qu'on devrait aller à plus de 700 Mb/s.



1306 paquets perdus, dés le début du téléchargement :


Le début du téléchargement (il dure 79,7 secondes) en graphe TCP trace qui permet de voir les retransmissions de paquets :


Le traceroute vers le serveur ne relève rien de particulier : le ping est bon (LaFibre.info est dans l'Ain) et il n'y a pas de saturation qui sont visibles par des pertes de paquets ou une augmentation de la latence :


1ère Hypothèse : Saturation sur le peering entre OVH et Adeli (qui se fait sur Equinix Internet Exchange Paris)

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #2 le: 28 février 2015 à 17:19:08 »
Débit en téléchargeant un fichier de 125 Mo sur le serveur 4Gmark de Gravelines depuis Bouygues Telecom : on est à 23,8 Mb/s alors qu'on devrait aller à plus de 800 Mb/s.



2222 paquets perdus, dés le début du téléchargement :


Le début du téléchargement (il dure 42 secondes) en graphe TCP trace qui permet de voir les retransmissions de paquets :


Le traceroute vers le serveur ne relève rien de particulier : le ping est bon et il n'y a pas de saturation qui sont visibles par des pertes de paquets ou une augmentation de la latence :


Des débits catastrophiques sont également observés avec les autres FAI.


2ème Hypothèse : Peu de chance que tous les opérateurs sature leur peering avec OVH, donc le problème est probablement chez OVH, par exemple le lien entre PAris et le datacenter OVH dEgravelines.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #3 le: 28 février 2015 à 17:19:39 »
Je me fait donc prêter un serveur OVH qui est à Gravelines, connecté sur le même routeur que celui de 4Gmark.

Le traceroute est strictement identique au serveur 4Gmark et le ping est identique :



Débit en téléchargeant un fichier de 100 Mo sur le serveur OVH de Gravelines depuis LaFibre.info (Adeli) : on est à 690 Mb/s de débit moyen sur ce petit fichier. On sature bien le 1 Gb/s, c'est le temps de la montée en débit à cause du ping qui fait que le débit moyen est < 900 Mb/s.



Un seul paquet perdu, en fin de téléchargement :


Le graphe TCPtrace est parfait sauf à la fin (en haut à droite) :


vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #4 le: 28 février 2015 à 17:20:09 »
Test depuis Bouygues Telecom sur le serveur de test qui est à coté de celui de 4Gmark

Là aussi, le traceroute est strictement identique au serveur 4Gmark et le ping est identique :




Strictement aucune perte de paquet !


Un graphe TCPtrace parfait :


Le weathermap d'OVH confirme que aucun lien n'est saturé sur le chemin emprunté :


3ème Hypothèse : Vu que ni le réseau OVH, ni les peering ne saturent, c'est le serveur de 4G mark qui est sur-chargé et qui répond donc avec un faible débit.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #5 le: 28 février 2015 à 17:20:49 »
Pour vérifier si c'est le serveur 4Gmark qui sature, j'utilise le serveur OVH qui est situé à coté pour tester le débit sur 4Gmark.

Le traceroute, bien évidement réduit à sa plus simple expression :


Le débit est excellent, avec le ping qui est quasi nul, le débit monte immédiatement à 1 Gb/s :


Pas de paquet perdu :


Graphe TCPtrace parfait :



Conclusion : La conclusion s'impose : OVH a bridé le débit du serveur 4Gmark, probablement car il consomme trop d'internet. Est-ce légal vis à vis des CGV ? Il faudrait savoir quelle offre à souscrit 4Gmark. Ce qui est grave, c'est que 4Gmark n'a pas été averti et que cela décrédibilise leur test de débit.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #6 le: 28 février 2015 à 17:25:54 »
Fonctionnement du bridage pour les serveurs OVH qui consomment beaucoup d'Internet : Il n'est pas actif la nuit

Une certitude : cela ne concerne que le trafic à destination d'Internet. Le trafic dans le réseau OVH n'est pas impacté.

2 hypothèses pour expliquer que le débit revienne à la normale la nuit :
- Soit le bridage n'est effectué que quand le trafic est important sur le réseau OVH (c'est là qu'il coûte de l'argent à OVH)
- Soit le bridage n'est pas activé la nuit car le trafic sur le serveur 4Gmark est plus faible (moins de test la nuit, c'est logique)


Je ne sais pas qu'elle est la bonne hypothèse, mais voici le graphe du débit en fonction de l'heure :



Un point représente un test (un téléchargement d'un fichier de 125 Mo sur le serveur 4Gmark ou 100 Mo sur le serveur alternatif de test)

eruditus

  • Client Orange adsl
  • Modérateur
  • *
  • Messages: 11 015
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #7 le: 28 février 2015 à 17:37:21 »
Outch ! #popcorn

buddy

  • Expert
  • Abonné Free fibre
  • *
  • Messages: 15 098
  • Alpes Maritimes (06)
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #8 le: 28 février 2015 à 17:38:49 »
est-ce que par hasard tu sais quel type de serveur a 4G mark ? et quel type de bande passante ??
https://www.ovh.com/fr/serveurs_dedies/upgrade-bande-passante.xml

Après c'est pas nouveau chez OVH, c'est de la BP garantie si tu ne l'utilises pas trop. (c'est en 2013 je crois que çà a été annoncé quand çà "saturait" trop ...

Citer
OVH vous garantit des niveaux de bande passante interne, entrante et sortante différentes en fonction du modèle de serveur dédié. Cette bande passante est garantie dans le cadre d’un usage normal (upgrade et usage spécifique en option) et profite de l’ensemble de l’infrastructure réseau OVH (interconnexions Ultimate).

Nico

  • Modérateur
  • *
  • Messages: 44 449
  • FTTH 1000/500 sur Paris 15ème (75)
    • @_GaLaK_
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #9 le: 28 février 2015 à 17:43:53 »
est-ce que par hasard tu sais quel type de serveur a 4G mark ? et quel type de bande passante ??
Question assez intéressante, si c'est du best-effort avec une garantie bien en deçà des besoins, je n'irai pas forcement jeter la pierre à OVH.

vivien

  • Administrateur
  • *
  • Messages: 47 085
    • Twitter LaFibre.info
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #10 le: 28 février 2015 à 19:21:58 »
4Gmark m'apporte des précisions : 4Gmark a une offre OVH avec un débit garanti de 500 Mb/s sur ce serveur.

Le trafic réel est très faible :


Le volume utilisé sur le mois de février cumulé est très faible : moins de 1 To


Le serveur de 4G mark sur Gravelines :

Serveur Enterprise SP-64 - 64G
Connexion réseau : 1 Gbps
BP OVH/OVH : 1 Gbps
BP OVH/Internet : 500 Mbps
BP Internet/OVH : 1 Gbps

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Bridage OVH: Analyse des performances catastrophiques du serveur de 4Gmark
« Réponse #11 le: 28 février 2015 à 19:49:57 »
Seule hypothèse du bridage : la configuration réseau d'OVH.

OVH utilise du Cisco, notamment la gamme Nexus pour les connexions serveurs. Cette gamme a une particularité, les modèles série 2000 sont des extensions (Fabric EXtender = FEX) du ou des switches parents. Ces modèles s'installent dans les racks serveurs (configuration dite Top-Of-Rack) et sont reliés en fibre optique avec leurs parents et ne possèdent aucune intelligence, strictement aucune. L'intéret ? En gros, c'est du jetable (malgré le tarif...) s'il tombe en panne, il suffit de le remplacer, la configuration sera rechargée sans intervention humaine.

Ces modules FEX n'ayant aucune intelligence, ils ne sont meme pas capable de commuter le trafic -> tout le trafic interne à un module FEX remonte à son (ou ses) switch(es) parent(s). Au maximum, il y a 4 liens montants 10Gb pour les versions 1Gb ou 8 liens montants 10Gb pour les versions à 10Gb. Ces liens sont donc utilisés que le trafic sorte du switch ou soit destiné à une autre machine du meme switch.

Toutes ces connexions sont ramenés à deux switches Cisco Nexus série 5500 : elles sont toutes actives, c'est une configuration dite "dual-homed" où les modules FEX sont gérés par deux parents. Si on perd un parent (donc un Nexus 5500), il n'y a pas d'impact sur les modules FEX, excepté une réduction de bande passante en sortie vue la perte de la moitié des liens montants.

Les Cisco Nexus série 5500 sont en 10Gb uniquement, seule la série 5600 récemment sortie dispose de ports 40Gb. Afin d'avoir un maximum de bande passante, on peut agréger des interfaces depuis chaque Nexus 5500 vers le backbone -> c'est la configuration choisie par OVH.

Possibilité : si OVH a des Cisco 5548 : 32x 10Gb répartis en 20x connexions vers les FEX (modèles 1Gb), 2x vers l'autre Nexus 5500, reste 10x connexions mais d'après Weathermap, une seule serait utilisée (ratio x2 en %)

Quand le serveur 4G mark monte à 1Gb, cela représente 10% de bande passante sur un uplink de FEX et 10% aussi sur l'uplink des N5k (meme avec 2 liens, Cisco fait de l'équilibrage par session).

Si le serveur 4Gmark atteint trop souvent 1Gb, le risque de saturation augmente d'autant.

Les Nexus 5500 n'ont pas de capacité de bridage donc celui-ci est effectué sur les routeurs OVH, probablement au plus proche: gra-3a-a9 (a9 = ASR9k ?).