Serveur dédié SCALE-3 - Bande passante privée 12 Gbps - vRack - Débit réseau garanti et attendu non atteint
Bonjour,
Nous avons trois serveurs dédiés SCALE-3. Le premier dans le datacenter Roubaix (RBX8), les deux autres dans le datacenter Strasbourg (SBG3).
Nous avons pris l'option de bande passante privée 12 Gbps entrant/sortant sur ces trois serveurs SCALE-3.
La distribution GNU/Linux Proxmox 7.0 est installée sur tout les serveurs (via IPMI). Mais le problème (que nous allons explicité juste après) est le même avec le template officiel Proxmox 6 de OVH.
Les trois serveurs sont dans le même vRack.
Le problème est le suivant: nous n’arrivons pas à obtenir un débit 12Gbps effectif entre nos différents serveurs.
Après de nombreux échanges avec le support OVH et de nombreuses interventions de leurs équipes sur site, il s’avère que le problème n’est pas matériel et la configuration réseau sur site est correcte.
Le problème serait donc logiciel, plus précisément un défaut de configuration réseau dans notre système Proxmox.
Le support OVH a réussi à atteindre le bon débit (12Gbps entrant/sortant) via leur mode rescue (qui est une base Debian 8…) en utilisant leurs paramètres (qui ne nous ont pas été communiqués en détail…). Le test qu’ils ont utilisé est un simple:
iperf3 -c 192.168.1.10 -i 10 -t 100 -P 16 | grep "SUM"
Voici la solution proposée par le support OVH:
« Paramétrer le MTU à 9000 ainsi que d'optimiser le Windows Size en fonction de la latence et de la bande passante.
Il vous faut connaitre la latence entre vos serveurs en moyenne.
Voici un exemple de calcul pour une bande passante de 10 Gbps et une latence de 80.1 ms :
- Liaison de la bande passante en bits * latence = taille de la fenêtre / 8 = taille parfaite en octets.
- 10737418240 bits * 0.0801 = 860067201 / 8 = 107508400 bytes. (102MBytes)
Sous Linux, il vous faudra modifier les réglages "TCP buffer" via "sysctl tcp_rmem, tcp_wmem et tcp_mem".
/!\ Je vous invite à effectuer une sauvegarde de vos données avant toutes manipulations par mesure de sécurité.
Après avoir modifier le MTU ainsi que le TCP buffer, votre bande passante devrai être bien plus grande. »
Nous avons fait plusieurs tests en changeant ces valeurs comme indiqué, effectivement cela module bien la bande passante entre les serveurs, mais toujours impossible d’atteindre d’une manière stable la bande passante de 12Gbps garantie par notre option sur les SCALE-3.
Voici les détails de nos tests (pour rappel les 3 serveurs SCALE-3 sont dans le même vRack nous avons souscrit à l’option 12Gbps sur les trois:
Entre le SCALE-3 RBX8 et les SCALE-3 SBG3 nous avons un débit très médiocre de 2Gbps entrant/sortant. Tout nos tests pour moduler la bande passante ont échoué (celle-ci reste inférieure à 12Gbps et est instable).
Entre les deux SCALE-3 SBG3 nous avons un débit de 6Gbps standard (donc toujours pas les 12Gbps « garantis » par notre option) MAIS avec les modifications faites par OVH une bande passante théorique de 12Gbps a pu être atteinte (via test iperf3).
Je dis théorique car en pratique les transferts de fichiers et de VMs au sein de nos Proxmox restent lents (n’utilisent pas les 12Gbps).
Pour le SCALE-3 RBX8 la seule fois où il atteint les 12Gbps, c’est du côté du support OVH, en mode rescue, avec leur paramètre et leur test théorique iperf3. En pratique sur notre Proxmox, malgré les différents tests, la bande passante reste catastrophique (même les 6Gbps standard ne sont pas atteint, on reste à 2.2Gbps médiocre).
Nous commençons un peu à être à court d’idée, donc si une personne a déjà été confrontée à ce cas de figure:
Serait-il possible de connaitre la configuration réseau exacte à appliquer pour atteindre la bande passante privée de 12Gbps entre plusieurs serveurs dédiés dans le même vRack ?
Merci.
A titre d’information, nos numéros de tickets (cela fait 10 jours qu’on communique avec le support OVH):
3177822
3269449
Bonjour,
Malheureusement je constate la même chose surtout avec le trafic vers Strasbourg.
A mon avis pour atteindre les 12Gbps, il faut que les serveurs discutent dans le même DC voir dans la même baie.
Ce que le support ne communique pas, c'est est-ce que les tests ont bien été effectués entre DC Roubaix/Strabourg ou simplement dans la même salle serveur.
Pour avancer dans tes tests, voici ce que je conseils:
- Passer tous les serveurs en mode rescue
- Créer un réseau MTU 9000 entre les 3 serveurs
- Faire des tests de débit simple via la récupération d'une iso par exemple
wget http://ipserver/debian11.iso
- Tu places 1 serveur en source et 2 serveurs en destination pour essayer d'augmenter la valeur de traitement admissible.
Ca te fait 3 configurations téléchargement à tester avec chacun son tour, les serveurs deviennent la source.
Normalement tu devrais constaté des variations important en fonction de chaque site et surtout des différences entre l'upload et le download.
Note les configurations les moins performantes et refais les tests iperf3 dans ces mêmes conditions.
D'après ce que j'ai pu observer, tu vas trouver des performances dégradées sur certains liens, genre download Strasbourg vers Roubaix ou le contraire.
Le iperf à la suite de ca te mettra dans les mêmes conditions que le support et tu pourras confirmer ou pas que le problème ne vient pas de chez toi.
Le soucis de iperf est qu'on fait un test hors condition réel, il n'y a pas de "vrai" trafic mais simplement des tram pour consommer la bande passante.
Un wget récupère un vrai fichier, on est fasse à un test concret même s'il ne représente qu'un cas de figure, il permet d'évaluer la bande passante.
Difficile pour le support qu'en rescue la BP avec un wget ne soit pas celle attendue …
Bon courage et bonne analyse
https://www.captainadmin.com
Ce que le support ne communique pas, c'est est-ce que les tests ont bien été effectués entre DC Roubaix/Strabourg ou simplement dans la même salle serveur.
Je ne peux pas mettre le troisième serveur en mode rescue (il est actuellement utilisé en prod).
En revanche on a déjà effectué des tests avec du SCP, dont les résultats sont les même dans les deux sens :
RBX8 <-> SBG3 : 180 Mo/sec
SBG3 <-> SBG3 : 490 Mo/sec
Pour le test avec iperf, en multiflux (-P 16) on obtient bien comme le support d'OVH :
RBX8 <-> SBG3 : 10.5 Gbits/sec
SBG3 <-> SBG3 : 11.5 Gbits/sec
En revanche dès qu'on passe à un seul flux (-P 1):
RBX8 <-> SBG3 : 500 Mbits/sec
SBG3 <-> SBG3 : 11.5 Gbits/sec
Face à ces résultats, le support continue d'insister que le problème vient uniquement de ma configuration réseau (MTU et "Windows Size") et qu'il ne peut rien faire de plus. Et tous les ajustements que j'ai essayé de faire là dessus depuis n'ont fait que au mieux rien changé au pire ont dégradé les performances légèrement.
A priori on est 3 fois inférieurs à ce qui est attentu, est-ce que tu as testé de faire plusieurs transferts en parallèle pour faire du multiflux aussi ?
A mon sens c'est à OVH de donner les paramètres et de les implémenter pour que ca fonctionne sinon c'est simplement de la publicité mensongère.
L'os est fourni par eux, le serveur aussi, s'il faut mettre une configuration spéciale, c'est à eux de la donner.
Si tu achètes une voiture qui doit pouvoir aller à 200km/h et que sur circuit tu ne dépasses pas les 80 parce qu'il faut des pneus, un aileron ou je ne sais quoi, tu vas certainement dire que le problème vient de la voiture et rien d'autres.
C'est exactement ce qui se passe donc à eux de fournir l'information.
Visiblement le support est en train de te dire "si si ca fonctionne mais bon courage pour trouver la bonne configuration"
Mais tu vas finir par trouver 
J'ai effectivement fais des tests de plusieurs transferts en parallèle, le débit ne chute pas (3 transferts en simultané en 180 Mo/sec). Ça semble quand même fortement indiquer un bridage par flux quelque part.
Nous n'utilisons pas leur OS (on est sur du proxmox 7), mais nous avons également testé avec leur OS proxmox 6 fourni et nous avons exactement les mêmes résultats.
Je suis assez d'accord avec toi, je trouve leurs réponses jusqu'à présent assez faciles comme façon de se décharger de toutes responsabilités. Ça tourne en boucle sans solution depuis que nous avons ouvert le ticket. Surtout que de notre côté nous avons dû déchanter en faisant face à beaucoup de pannes et de perte de temps en ayant le malheur d'installer une solution de stockage sensible au performances réseaux (alors que nous nous étions dit au début "Pas de problème ! on a du 12Gbps garanti !" ah la naïveté…).
De plus de ce qu'il me semble, les configurations qu'ils nous proposent d'ajuster n'expliquent absolument pas une telle disparité dans les résultats. Au mieux nous pourrions améliorer légèrement les performances, pas de quoi expliquer les résultats catastrophiques que nous avons dans nos tests en conditions réelles.
Merci beaucoup pour tes conseils et réflexions jusqu'à présent en tous cas.
Bonjour,
nous sommes pratiquement dans le même cas que vous et ça se passe à RBX8 aussi, avec trois machines… mais nous constatons déjà que le transfert entrant vers nos trois machines ne dépassent pas le 20 mbps/sec au lieu d'1 gbp/s sur les ip publiques y compris en mode rescue !
le vrack lui aussi à tendance à plafonner des fois mais nous ne l'avons pas testé en rescue pour le moment, nous cherchons déjà à régler ce souci sur les ip publiques car certains de services font des uploads sur celles ci pendant que d'autre passe par le vrack.
Nous avons d'autres machines à rbx4 3 et gravelines ou nous n'avons pas ce type de souci.
Quoi qu'il en soit, nous avons le même problème avec le support qui ne comprend pas qu'un test iperf n'est pas toujours pertinant…
on prend une de nos machines, on la passe en mode rescue, un coup de sftp depuis n'importe quelle ligne machine os : 20 mpbs 
et on nous dit de vérifier notre config, l'on nous renvoie aux cgv, on fait 152200 tests en pure perte , bref ca dure depuis 12 jours…
Avez vous eu une solution de votre côté ?
bonne journée à vous.
Bonjour,
Malheureusement nous nous sommes heurté à un mur, avec exactement la même rengaine : les tests ifperf fonctionnent parfaitement, c'est de votre faute, il faut régler vos paramètres réseaux. Le plus curieux c'est qu'en effet nous avions bien les 12 gigas de bande passante, mais uniquement en mettant 10 flux en parallèles (ce qui était complètement inutile dans notre cas).
On a quand même obtenu de pouvoir avoir un autre serveur dans le même datacenter que les autres et on a tout migrer et depuis tout baigne, hormis qu'on a tout dans le meme datacenter.
Le support a été catastrophique, à chaque fois il fallait faire passer les serveurs en mode rescue toutes une journée (deux serveurs sur 3) ce qui a été catastrophique pour la prod.
J'ai même pris un prestataire pour essayer de régler le problème (je ne suis pas un "pro" du réseau) et il est arrivé à la même conclusion que nous et s'est heurté au même mur d'incompréhension de la part d'ovh.
Je dois avouer que cette expérience m'a complètement refroidi et je suis passé de 'ovh c'est génial' à aller voir ailleurs si vous pouvez, ce qui a déjà provoqué un certain nombre de départ.
Bonjour,
tout d'abord un grand merci pour la réponse, on va tester le coup des envois en parallèle mais effectivement chez nous la régulation de la BP est sensée se faire par notre reverse proxy, si il y a un user il a toute la BP, si il y a 100 on divise, mais ce n'est pas à OVH de brider la BP qui est sensée être de 1gbps à l'entrée du serveur.
On est dans le même cas, avec le support qui oblige à repasser en rescue pour des tests sans fondements… on a déjà 2 semaines de prod de perdues.
les tests iperf ne sont que des envois de "tram", c'est bien en théorie, mais si on fait un pauvre sftp / scp / ou un upload https, avec ces protocoles là c'est une cata, mais que sur RBX8 !!!
on va demander à déménager du coup :(…
encore du temps perdu …
un grand merci encore pour la réponse.