Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • Status En cours de résolution
  • Percent Complete
    0%
  • Task Type Anomalie
  • Category LAN → NAT (redirections, DMZ)
  • Assigned To No-one
  • Operating System Freebox V9 (Ultra)
  • Severity Low
  • Priority Low
  • Reported Version 4.8.17.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Opened by Wobak - 10/01/2025
Last edited by Wobak - 15/01/2025

FS#39970 - Performance NFS mauvaises

Bonjour,

J’ai un serveur avec un partage NFS sur mon réseau local que je veux partager à des amis au travers d’Internet.

En réseau local je dépasse les 300MB/s en écriture et en lecture, le serveur est en 10Gb.

Lorsque je fais un iperf3 depuis chez un ami vers chez moi, on tape les 7Gbits sans problème.

Lorsqu’on fait un test de copie NFS, on atteint péniblement les 10MBps.

Le NAT envoie bien le port 2049 vers mon serveur, en TCP.

On a essayé de modifier les rsize / wsize sur le montage NFS, également le read_ahead_kb sur le point de montage.

Les 2 machines sont sous CentOS 9-Stream, donc rien de fantaisiste.

Est-ce qu’il se pourrait que la Freebox empêche d’atteindre les perfomances attendues ?

NFS n'est pas spécialement conçu pour des partages via internet, à mon avis il vaudrai mieux réfléchir à une autre solution de partage de fichiers

Wobak commented on 10.01.2025 08:38

Bonjour,

je veux bien des suggestions pour avoir un point de montage permanent entre nos serveurs qui ne soit pas NFS du coup.

Admin

du point de vue de la box, il n'y a pas de différence entre un paquet TCP qui encapsule du trafic iperf, et un paquet TCP qui encapsule du trafic NFS.

Lorsqu’on fait un test de copie NFS, on atteint péniblement les 10MBps.

est-ce que le trafic NFS est en clair ou chiffré ?
Le chiffrement peut fortement impacter les performances

Wobak commented on 10.01.2025 10:03

Le point de montage est fait de manière identique sur le LAN, donc j'aurais tendance à dire que non.

Et il impacterait les performances en local autant qu'en remote dans ce cas là non ?

Admin
Le point de montage est fait de manière identique sur le LAN, donc j'aurais tendance à dire que non.

à moins d'avoir un tunnel TLS (ou un VPN de manière plus générale), cela veut dire que les données transitent en clair sur internet.

Et il impacterait les performances en local autant qu'en remote dans ce cas là non ?

oui.

la latence en remote peut fortement impacter les performances par rapport à un setup local. En fonction du type de test (lire/écrire un gros fichier vs lire/écrire plein de petits fichiers) les performances vont varier aussi.

vous pouvez essayer de changer l'algorithme de contrôle de congestion TCP:

sudo sysctl net.core.default_qdisc=fq
sudo sysctl net.ipv4.tcp_congestion_control=bbr
Wobak commented on 10.01.2025 10:59

Merci pour ces conseils.

Lorsque je compare les performances, on essaye bien sûr de minimiser les différences, donc on est sur du gros fichiers de plusieurs Go, et de préférence le même.

Je vais tenter la modification de congestion pour voir, merci pour le conseil.

Bonjour

NFS sur internet sans VPN entre les machines c'est euh, comment dire… pas terrible.

Pour ce que vous faites, je vous conseil plutôt SSHFS.

Pour utiliser NFS il faut monter un tunnel IPSEC entre les 2 machines (ou les 2 infra) et faire écouter NFS dedans

Cordialement
nbanba

Wobak commented on 15.01.2025 19:50

Bon du coup à force de recherche, la bonne solution fut d'augmenter le readahead de 128 par défaut à 128000 avec un fichier de rules udev.

SUBSYSTEM=="bdi", ACTION=="add", PROGRAM="/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes", ATTR{read_ahead_kb}="128000"

Merci pour vos suggestions

Bonjour

Merci pour votre retour et ce "dirty workarround" qui peut aider d'autres bien que ce que vous cherchez à faire soit plutôt farfelu et franchement pas recommandé (NFS 4.x ne fonctionne pas ou très mal avec de la latence et N'a PAS été conçu pour être utilisé sur internet…)

Au risque d'être rabat joie ce que j'assumerai, je persiste à dire que vous ne devriez pas utiliser NFS sur un réseau public comme internet !

Dans votre cas il est recommandé soit de connecter les 2 infrastructures en VPN avec une solution du type tunnel VPN IPSEC site-to-site entre les 2 sites (attention la latence doit être EXCELLENTE de l'ordre d'un réseau local) et d'utiliser NFS sur le réseau privé au travers du tunnel créé, soit de ne pas utiliser NFS mais d'utiliser un protocole chiffré.

Pour votre besoin une alternative viable fournissant des performances acceptables et un niveau de sécurité convenable est l'utilisation de 'sshfs'

https://fr.m.wikipedia.org/wiki/Secure_shell_file_system

Cordialement
nbanba

Wobak commented on 15.01.2025 22:29

Merci pour ce retour mais il existe des contraintes autres dont je n'ai pas parlé.

Aujourd'hui ce NFS est utilisé dans un docker container en tant que volume, et il me semble que sshfs n'est pas utilisable nativement dans docker.

Les tests en live ont été faits justement parce qu'on se demandait si le chiffrage dû au VPN était ce qui nous coûtait les performances données.

Le trafic final se fera dans un tunnel IPSec, mais ce n'était pas la question initiale et je ne voulais pas complexifier la question initiale parce que nous avions réussi à isoler que la problématique de performance se situait au niveau de NFS.

D'ailleurs je vais regarder si SSHFS a de meilleures performances histoire de comparer :)

Wobak commented on 15.01.2025 22:34

Et je me permets de rebondir sur "ne fonctionne pas ou très mal avec de la latence" en citant la RFC : https://datatracker.ietf.org/doc/html/rfc3530

1.2.  NFS Version 4 Goals

   The NFS version 4 protocol is a further revision of the NFS protocol
   defined already by versions 2 [RFC1094] and 3 [RFC1813].  It retains
   the essential characteristics of previous versions: design for easy
   recovery, independent of transport protocols, operating systems and
   filesystems, simplicity, and good performance.  The NFS version 4
   revision has the following goals:

   o  Improved access and good performance on the Internet.

      The protocol is designed to transit firewalls easily, perform well
      where latency is high and bandwidth is low, and scale to very
      large numbers of clients per server.

Donc… je pense que je ne suis pas d'accord avec votre affirmation :) Je veux bien une source si possible.

Bonjour

J'adore la doc qui résume l'objectif (atteint ?)

Pour répondre :
1) l'expérience
2) le nombre de features du KERNEL LINUX qui ont du être rajoutées pour que NFS fasse ses IO directement et en PARALLELE pour obtenir des perfs correctes ( support for pNFS block layouts / support for pNFS SCSI layouts)
3) Il faut manuellement rebuild le kernel pour en profiter
4) le système de cache de GCP pour augmenter les perfs (knfsd)

Mais bon si vous faites fonctionner dans un tunnel avec un minimum de latence, ça devrait aller…

Après pour la description de votre problème, je pense qu'il aurait été important de spécifier que vous faisiez fonctionner NFS dans un tunnel IPSEC car ça a des impactes (tunnelling = encapsulation = faire rentrer des paquets le plus grand possible dans d'autres paquets servant au transport)
Sur un réseau dédié stockage avec du NFS, on essaye généralement de mettre un MTU à 9000+ et un MSS maximal pour transporter le plus possible de données par paquets, ce qui n'est pas forcément possible au travers d'internet (sans fragmentation massive et apparition d'autres soucis avec la latence comme du retransmit de trames)

Dernier conseil si vous en avez la possibilité, montez le tunnel IPSEC site-to-site entre 2 équipements spécialisés (VPN Gateway) ayant des ASIC ou des FPGA spécialisés pour offload IPSEC et entre 2 connextions freebox j'arrive à avoir des perfs proches du LAN en IPSEC avec ce type de matériel et les ciphers CHACHA20POLY1305 et AES256gcm
Si vous montez un IPSEC entre 2 linux avec StrongSwan soit vous avez des very very super NIC permettant d'offload IPSEC et l'AES (comme certaines ConnectX-6-DX crypto card / Bluefield 2 crypto card), soit je vous recommande d'utiliser Wireguard qui est in-kernel et plus légé (toujours avec les ciphers CHACHA20POLY1305 et AES256gcm)

Cordialement
nbanba

Admin

@Wobak

Sur quel support de stockage se trouve le montage NFS ?

Quel est le filesystem utilisé ?

Le fix est étrangement bas niveau. Il me semble qu'il y a des workarounds similaires pour des disques de type 'SMR' (qui présente de très mauvaises performances s'il y a trop d'écritures, mais cela peut se présenter aussi sur les lectures).

Si le filesystem n'est pas natif au système (ntfs3g sur linux par exemple), il est possible que cela plombe les performances.

Il peut être intéressant de créer un tmpfs (donc en RAM), l'exposer via NFS et faire les tests ensuite. Cela permet de voir si c'est NFS, ou la combinaison NFS/stockage qui présente de mauvaises performances.

Wobak commented on 16.01.2025 09:48

@nbanba La doc est la définition officielle du protocole NFSv4, puisque c'est la RFC qui le définit.

J'ai justement enlevé le tunnel IPSec de l'équation parce qu'en l'enlevant, la problématique restait, et qu'il ne s'agissait donc pas de la source du problème. Nous avons fait les tests en direct justetment pour l'éliminer.

@mmakassikis : il s'agit d'un RAID6 mdadm de 10 disques NL-SAS en XFS, mais comme précisé plus haut, lorsqu'on ne passe pas par Internet mais qu'on reste sur réseau local, le problème disparaît, malgré la même vitesse de réseau (10Gbits en local, 8Gbits au travers d'Internet via la Freebox).

Bonjour

Oui, je pense que je sais ce qu'est un RFC

Cependant si je vends une nouvelle gamme de voiture, je vais dire ce qu'elles sont censées faire de + que la gamme précédente (~ RFC GOAL) mais cela sans aucune garantie que la promesse technique soit réellement au RDV ! Surtout quand la technique dépend de l'implémentation …

Pour moi ce forum doit être un lieu d'échanges constructifs ⇒ j'arrête le débat.

Cependant, je suis complètement d'accord avec @mmakassikis sur le fait que je cite: "Le fix est étrangement bas niveau"

Cordialement
nbanba

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing