Merci,
Problème, pour l'idée de load balancing sur plusieurs IP, il ne semble pas possible de forcer iPerf à écouter sur une IP particulière (comme le fait Apache2), pour mettre plusieurs iPerf sur le même port, sur des IP différentes, sur le même serveur.
Cela passe forcèment par une virtualisation ou une mise en container type Docker
Ca devrait être simple a modifier le code pour forcer iperf sur une IP. On peut ouvrir un bug request dans ce sens. Voir un pull request si j'ai le temps mais pas avant fin aout pour moi donc si quelqu'un d'autre a le temps ici.
Isoler les iperf dans des containers Docker serait une bonne chose de toute façon.
Sinon en jouant avec du NAT et iptable localement sur le serveur tu devrais pouvoir 'jongler' avec plusieurs IP mais c'est compliquer à faire.
Il y a aussi la technique du LD_PRELOAD mais je ne l'ai jamais utilisé (voir:
http://daniel-lange.com/archives/53-Binding-applications-to-a-specific-IP.html ). Peut-etre d'autres techniques existent aussi pour imposer une ip a un process qui 'bind *'.
Je viens de réfléchir sur le balancing dns avec plusieurs IP : L’intérêt serait en cas de iPerf3 occupé, de relancer la commande pour tomber sur un autre serveur. mais "Le client conserve ensuite dans son cache DNS l'adresse IP utilisée, ce qui permet de conserver une relative stabilité dans la gestion des sessions du service." source : Wikipedia
Donc un client va rester sur le même serveur iPerf3
ca reste dans le cache le temps du TTL non ? si tu mets un TTL a zero ca devrait le faire (en pratique zero peut poser des problèmes donc utilise 1).
apres c'est pas forcement un probleme qu'un client reste sur le meme serveur, deja d'avoir dispatché plusieurs clients sur plusieurs serveurs permet d'augmenter la dispo du serveur.
De toute façon l'idéal est soit une file d'attente, soit un support de plusieurs clients en même temps. Sinon n'importe quel 'hacker' peut DoS le serveur en laissant tourner un test en boucle. Avec cela un timeout coté serveur s'impose aussi (genre pas plus de 1 minute par client).
Éventuellement certaines de ces fonctions pourraient être mise en oeuvre par un front-end sans changer le code actuel d'iperf.
Il est clair que le design d'un test public et d'un outil de test privé n'est pas la même chose.
Une autre approche est peut-etre ce qu'ils font avec les outils d'Internet 2. voir
http://software.internet2.edu/bwctl/Une option a été rajouté a iperf3 pour cela: l'option "-1" qui accepte un test puis quitte. Ca permet dynamiquement de preparer des tests puis les lancer.
Tu pourrais éventuellement t'inspirer de cela en faisant un script :
- le client contact le serveur et demande un test, le serveur lance un iperf3 sur un port libre avec l'option "-1" et renvoi au client le n° de port
- le client lance un iperf3 sur le port recu
avec un truc comme wget coté client et un front-end php ou autre coté serveur pour lancer les iperf.