Je l'ai laissé tourner 1 heure pour voir si tout est ok pour lui et si il n'y a rien d'anormal niveau trafic et pas de point de saturation. En première analyse je peux constater que sur les liens passés en blocking par stp, j'ai quelques Kb de trafic. Je suppose que c'est juste le protocole qui test et envoi les états aux autres switch. Sur les liens actifs là j'ai le gros du trafic.
Ensuite depuis un serveur physique connecté sur un des switch du cœur j'ai généré un fichier avec dd de 10G et lancé un transfert par scp ou par rsync "over ssh" vers un autre serveur physique connecté à l'autre switch du cœur. Bien sûr la fenêtre de tir est réduite puisque mrtg se lance toutes les 5mn de mémoire donc il a fallu contrôler l'heure de dernière mise à jour des graphes.
Résultat : le transfert c'est bien passé, pas de coupure. Côté mrtg j'ai suivi les piques de trafic de port en port, cela m'a permis de confirmer que le bon chemin est emprunté. Cette méthode est plus facile à mettre en œuvre à un moment de la journée où il y a peu de trafic.
A la lumière de ces essais une autre question est apparu : Mais c'est quoi ce débit ?!
Le serveur A dispose d'une carte 1G, il est connecté à un switch 1G, l'interconnexion entre switch est un trunk de deux liens 1G (donc 2G) et le serveur B a lui aussi une carte 1G.
Les stats de rsync me donne 49,95Mb/s pour transférer un fichier de 10,74G en 0:03:24 . Pendant le transfert je contrôlais qu'il n'y avait rien d'autre qui pouvait influencer le résultat.
J'ai réalisé le même test depuis le serveur A en direction de mon pc connecté sur le même switch et j'obtiens pratiquement le même résultat.
D'après vous est-ce normal ?
Mes switchs sont des procurves, lldp et lacp sont bien activé.
[^] # Re: Tu ne peux pas
Posté par Philippe M (site web personnel) . En réponse au message Suivre le chemin d'un paquet au travers des switchs. Évalué à 3.
J'ai passé tout l'après midi d'hier à faire des tests complémentaires
Avant de me lancer dans la coupure de port et potentiellement perturber la production j'ai opté pour une autre méthode.
Sur mon pc j'ai installé un container mrtg qui graphe tout les ports de tout mes switchs.
Je l'ai laissé tourner 1 heure pour voir si tout est ok pour lui et si il n'y a rien d'anormal niveau trafic et pas de point de saturation. En première analyse je peux constater que sur les liens passés en blocking par stp, j'ai quelques Kb de trafic. Je suppose que c'est juste le protocole qui test et envoi les états aux autres switch. Sur les liens actifs là j'ai le gros du trafic.
Ensuite depuis un serveur physique connecté sur un des switch du cœur j'ai généré un fichier avec dd de 10G et lancé un transfert par scp ou par rsync "over ssh" vers un autre serveur physique connecté à l'autre switch du cœur. Bien sûr la fenêtre de tir est réduite puisque mrtg se lance toutes les 5mn de mémoire donc il a fallu contrôler l'heure de dernière mise à jour des graphes.
Résultat : le transfert c'est bien passé, pas de coupure. Côté mrtg j'ai suivi les piques de trafic de port en port, cela m'a permis de confirmer que le bon chemin est emprunté. Cette méthode est plus facile à mettre en œuvre à un moment de la journée où il y a peu de trafic.
A la lumière de ces essais une autre question est apparu : Mais c'est quoi ce débit ?!
Le serveur A dispose d'une carte 1G, il est connecté à un switch 1G, l'interconnexion entre switch est un trunk de deux liens 1G (donc 2G) et le serveur B a lui aussi une carte 1G.
Les stats de rsync me donne 49,95Mb/s pour transférer un fichier de 10,74G en 0:03:24 . Pendant le transfert je contrôlais qu'il n'y avait rien d'autre qui pouvait influencer le résultat.
J'ai réalisé le même test depuis le serveur A en direction de mon pc connecté sur le même switch et j'obtiens pratiquement le même résultat.
D'après vous est-ce normal ?
Mes switchs sont des procurves, lldp et lacp sont bien activé.
Born to Kill EndUser !