FR 2852119 A1 20040910 FR 0302681 A 20030305 Système et procédé de test d'équipements de réseaux informatiques La présente invention concerne un système et un procédé de test d'un ensemble d'au moins un équipement de réseaux informatiques. A ce jour, il existe divers outils permettant de provoquer une charge de réseaux informatiques, notamment de réseaux Internet. Certains outils sont dédiés à un type d'équipement précis, d'autres sont composés de cartes ayant des fonctionnalités spécifiques et 10 limitées. Certains outils sont également capables d'effectuer des tests fonctionnels d'équipements de réseaux informatiques. Les outils actuels de test sont encore loin de couvrir toutes les fonctionnalités permettant de tester les équipements réseau actuellement sur le marché. Il existe cependant des outils permettant de générer du trafic réel pour connaître le temps de réponse des équipements. Ces outils, sous forme de châssis, utilisent des cartes spécifiques. Ils présentent un certain nombre de contraintes. En effet, la taille des châssis étant limitée, l'emplacement des cartes l'est aussi, 20 ce qui limite le nombre maximal de clients simulés. De plus ces applications développées sont souvent propriétaires et liées aux cartes du fournisseur. Les fonctionnalités proposées sont donc liées au matériel utilisé. Par conséquent, la plupart de ces outils sont difficilement 25 évolutifs. De surcroît, les comportements des utilisateurs simulés sont cycliques, donc prévisibles, ce qui n'est pas le comportement réel d'un utilisateur. Ainsi, au vu de ce qui précède, le but de l'invention est de proposer une solution qui réponde à l'ensemble des besoins de test 30 d'équipements de réseaux informatiques, et qui soit évolutive sans modifier les briques ou éléments déjà existants pour s'adapter facilement aux tests de nouveaux équipements, notamment de produits et services. Aussi, selon l'invention, il est proposé un système de test d'un ensemble d'au moins un équipement de réseaux informatiques comprenant un ensemble de serveurs de test adaptés pour générer un trafic de données de test sur un réseau, apte à effectuer des tests de 5 charge et/ou des tests fonctionnels de l'ensemble d'au moins un équipement, et un serveur de commande des serveurs de test pour mettre en oeuvre une ou plusieurs phases de test de l'ensemble d'au moins un équipement du réseau. Selon un mode de réalisation préféré, le système comporte - un réseau de contrôle, dans lequel sont placés les serveurs de test et le serveur de commande, ledit réseau de contrôle comprenant un réseau physique et un réseau (IP) utilisant le protocole Internet et - un réseau de test, dans lequel sont placés les serveurs de test et 15 l'ensemble d'au moins un équipement à tester, ledit réseau de test comprenant un réseau physique et un réseau (IP) utilisant le protocole Internet; De plus, le réseau de contrôle et ce réseau de test sont des réseaux distincts. Ainsi, les messages de contrôle ne viennent pas perturber les échanges liés à la charge que l'on cherche à tester. Selon un mode de réalisation avantageux, le système comporte des outils proposés par un système d'exploitation pour implémenter des couches protocolaires d'un système d'interconnexion de systèmes 25 ouverts (OSI), qui sont utilisés par les serveurs de test pour générer des sessions client/serveur de test. Avantageusement, dans le réseau de contrôle, le serveur de commande est relié à tous les serveurs de test selon une configuration maître/esclave, le serveur de commande constituant un serveur maître 30 et les serveurs de test constituant des serveurs esclaves. En outre, les serveurs de test sont placés de part et d'autre de l'ensemble d'au moins un équipement à tester, déterminant ainsi un caractère client ou serveur de chaque serveur de test. Selon un mode de réalisation préféré, chaque serveur de test gère un ensemble d'au moins un client ou serveur d'un modèle client/serveur, les clients ou les serveurs de chaque ensemble ayant le même comportement visà-vis du trafic du réseau. Chaque serveur de test gère donc plusieurs ensembles ou pools d'au moins un client ou serveur d'un modèle client/serveur, les clients ou serveurs de chaque ensemble ayant le même comportement vis-à-vis du trafic du réseau. Avantageusement, le serveur de commande possède un pilote de 10 gestion de scénarios de test. En outre, le pilote comporte un ensemble de commandes, stockées en mémoire, destinées à commander à distance l'ensemble des serveurs de test. Selon une autre caractéristique du système, celui-ci comprend 15 des moyens pour provoquer le démarrage aléatoire ou pseudo aléatoire de la génération du trafic de données de test par chaque serveur de test. Avantageusement, le système comprend des moyens pour synchroniser le démarrage de la génération du trafic de données de test 20 par les ensembles d'au moins un client ou serveur pour chaque serveur de test, et pour synchroniser la déconnexion desdits ensembles pour chaque serveur de test. En outre, le système comprend des moyens pour synchroniser le démarrage de la génération du trafic de données de test par la totalité 25 des ensembles d'au moins un client ou serveur pour chaque serveur de test, et pour synchroniser la déconnexion de la totalité desdits ensembles pour chaque serveur de test. Selon un mode de réalisation préféré, le système comprend des moyens pour synchroniser le démarrage de la génération du trafic de 30 données de test par la totalité des ensembles d'au moins un client ou serveur pour tous les serveurs de test, et pour synchroniser la déconnexion de la totalité desdits ensembles pour tous les serveurs de test. En outre, le système comporte un module d'analyse des résultats délivrés lors d'une phase de test. Avantageusement, le système comporte un module de génération automatique de scénarios de test, consistant par exemple en 5 une recherche par dichotomie du trafic de données de test acceptable par l'ensemble d'au moins un équipement à tester. Selon l'invention, il est également proposé un procédé de test d'équipements de réseaux informatiques, mis en oeuvre au moyen d'un système cité ci-dessus, qui pilote des serveurs de test, au moyen d'un 10 serveur de commande, de manière à générer un trafic de données de test sur un réseau. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins 15 annexés sur lesquels: - La figure i est un schéma synoptique illustrant la structure d'un réseau de contrôle d'un système selon l'invention. - La figure 2 est un schéma synoptique illustrant la structure d'un réseau de test d'un système selon l'invention. - La figure 3 est un schéma synoptique illustrant l'organisation fonctionnelle d'un réseau de contrôle et d'un réseau de test correspondant, d'un système selon l'invention. Sur les figures l à 3 on a représenté l'architecture générale d'un 25 système de test de l'ensemble d'au moins un équipement informatique dans un réseau. Il est destiné à simuler un trafic de données de test de ce réseau et à lancer des phases ou scénarios de test de manière à contrôler le bon fonctionnement de l'équipement. Une phase de test comprend des tests fonctionnels et/ou des tests de charge. Les tests de charge permettent de visualiser le comportement de l'ensemble d'au moins un équipement sous une forte charge du réseau, et de déterminer la charge maximale supportée en gardant une qualité de service suffisante. Par exemple, on peut générer du trafic avec un débit supérieur au débit accepté par un des ports d'un ensemble d'au moins un équipement afin de saturer ce port et de déterminer ainsi la qualité de service de l'ensemble d'au moins un équipement lors d'une surcharge de trafic. Les tests fonctionnels permettent de vérifier le parfait 5 fonctionnement d'un ensemble d'au moins un équipement, en particulier les fonctions annoncées par le constructeur ou le fournisseur. Par exemple, on peut tester l'établissement d'une session PPPoE (Point to Point Protocol over Ethernet) sur un équipement d'accès. Le système selon l'invention permet d'effectuer des tests unitaires et des tests d'intégration, car il permet de tester un équipement ou un ensemble de plusieurs équipements. Le système de l'invention est modulaire. En effet, il comprend des modules dédiés pour différentes couches du modèle OSI 15 (interconnexion de systèmes ouverts), de cette manière, il est facile de le faire évoluer, notamment par l'ajout de modules gérant d'autres couches dudit modèle. Il est donc aisé d'ajouter de nouveaux protocoles et fonctionnalités en combinant différentes couches protocolaires du modèle ouvert OSI. A cet effet, le système comporte un réseau de contrôle 1 et un réseau de test 2. Le réseau de test 2 et le réseau de contrôle 1 comportent chacun un réseau physique et un réseau IP, c'est-à-dire un réseau utilisant le protocole Internet. En référence à la figure 1, le réseau de contrôle 1 comprend un 25 serveur de commande 3 et plusieurs serveurs de test 4,5,6,7 reliés au serveur de commande 3. En référence à la figure 2, le réseau de test 2 comprend les serveurs de test 4,5,6,7 et l'ensemble 8 d'au moins un équipement à tester auquel sont raccordés les serveurs de test 4,5,6,7. Les serveurs incorporent tous les moyens matériels et logiciels permettant l'exécution de scénarios de test destinés à provoquer l'exécution de campagnes de test simulant un trafic de données de test du réseau. En particulier, en référence à la figure 3, sur laquelle des éléments fonctionnels des réseaux des figures l et 2 ont été représentés, le serveur de commande 3 du réseau de contrôle 1 est pourvu d'un pilote 30 de gestion des scénarios de test. En outre, le pilote 30 de gestion comporte des données de commandes stockées en mémoire, lui permettant de piloter à distance les serveurs de test 4,5,6,7. Le réseau de contrôle i possède éventuellement des points de synchronisation 31 des serveurs de test 4,5,6,7 couplés ou non. De 10 même, le réseau de contrôle l possède éventuellement des points de synchronisation 32 de tous les ensembles 33 d'au moins un client ou serveur, appelés également pools 33de chaque serveur de test. De plus, le réseau de contrôle 1 possède des points de synchronisation 34 de chaque ensemble 33 d'au moins un client ou 15 serveur (pool), ledit pool étant ou non associé à un autre pool en fonction de son éventuel couplage dans le mode client/serveur. De manière optionnelle, il est donc possible de synchroniser tous les pools d'un serveur de test pour chaque serveur de test, ainsi que de synchroniser la totalité des pools de tous les serveurs de test. En outre, chaque serveur de test possède des modules de gestion de trafic de données de test 35 gérant les couches 4 et 7 du modèle d'interconnexion des systèmes ouverts (OSI). Les points de synchronisation 34 et les modules de gestion de trafic de données de test 35 permettent de provoquer un démarrage 25 aléatoire ou pseudo aléatoire du trafic de données de test Par ailleurs, chaque serveur de test possède un pilote 36 de trafic de données de test qui gère le trafic de données de test généré par ce serveur de test, c'est à dire le trafic de données réseau simulé par ce serveur de test. En outre, chaque serveur de test possède un pilote 37 de pools, c'est à dire un pilote d'ensembles d'au moins un serveur ou client selon le caractère client ou serveur du serveur de test, ledit pilote 37 de pools gérant les sessions 38 de test. Chaque serveur de test possède un premier module de surveillance permettant, en cas de problème durant le déroulement du scénario de test, de le signaler au serveur de commande 3, et un deuxième module de surveillance permettant d'indiquer en temps réel 5 au serveur de commande 3 les changements d'état de chaque serveur de test. Des modules d'interface 39 équipant les serveurs de test sont en outre prévus pour gérer les connexions et déconnexions suivant les types d'encapsulation utilisés éventuellement de manière simultanée 10 (Modem, Ethernet, ATM... ). Comme indiqué précédemment, le serveur de commande 3 possède éventuellement des outils ou points de synchronisation 31 pour gérer les synchronisations pour les serveurs de test 4,5,6,7, et chaque serveur de test possède éventuellement des outils ou points de 15 synchronisation 32 pour gérer la synchronisation des pools du serveur de test. On va maintenant décrire le déroulement d'une campagne de test d'un ensemble 8 d'au moins un équipement de réseaux informatiques, à titre d'exemple. En fonction des tests à réaliser, un serveur de test se situe soit dans une configuration client, soit dans une configuration serveur. Le pilote 30 de gestion des scénarios de test du serveur de commande 3 transmet une configuration du scénario de la campagne de test aux serveurs de test 4,5,6,7, couplés en client/serveur ou non 25 couplés en client/serveur. Cette configuration est reçue, traitée puis transmise par le pilote 36 de trafic de données de test de chaque serveur de test au pilote 37 de pools de chaque serveur de test. Sur chaque serveur de test 4,5,6,7, le pilote 36 de trafic de 30 données de test reçoit la configuration d'un scénario à exécuter et s'occupe de la gestion de l'ensemble des sessions 38 client/serveur. Il assure le découpage en ensembles de pools 33 de clients/serveurs selon le caractère client ou serveur du serveur de test, la gestion de l'ensemble des pools 33 ainsi partagés, la synchronisation des sessions client/serveur au niveau de tous les pools (optionnel), la remontée de la synchronisation au pilote 30 de gestion des scénarios de test du serveur de commande 3 afin que celui-ci assure la synchronisation au niveau de tous les serveurs de test 4,5,6,7 (optionnel), et le traitement des résultats à la fin du scénario de test. Les serveurs de test 4,5,6,7 couplés auront des scénarios identiques. Dans chaque couple client/serveur, le client et le serveur déroule le même scénario, chacun avec son rôle propre, client ou serveur. Le pilote 37 de pools de chaque serveur de test gère les sessions 38. A cet effet, ledit pilote 37 établit une interface correspondant à la configuration et établit l'ouverture des sessions 38 client ou serveur au moyen du module d'interface 39 adéquat, et lance le trafic de données de test adéquat au moyen du module de gestion 35 15 de trafic de données de test concerné , déconnecte ou ferme les sessions 38 au moyen du module d'interface 39 correspondant, et gère la synchronisation au moyen de points de synchronisation 32 et 34. Ce système de test permet donc de tester un ensemble 8 d'au moins un équipement informatique dans un réseau, en simulant des 20 situations de crises, notamment de surcharge du réseau. La connaissance du matériel informatique permettra de bien le dimensionner dans son utilisation au sein d'un réseau informatique. Ce système permet, à ces fins, de simuler un nombre accru d'utilisateurs de l'ensemble d'au moins un équipement, et de simuler de façon très 25 réaliste le trafic réel engendré par les utilisateurs du réseau, dans le sens clients/serveurs et dans le sens serveurs/clients. REVENDICATIONS 1. Système de test d'un ensemble (8) d'au moins un équipement de réseaux informatiques, caractérisé en ce qu'il 5 comprend un ensemble de serveurs de test (4,5,6,7) adaptés pour générer un trafic de données de test sur un réseau, apte à effectuer des tests de charge et/ou des tests fonctionnels de l'ensemble (8) d'au moins un équipement, et un serveur de commande (3) des serveurs de test (4,5,6,7) pour mettre en oeuvre 10 une ou plusieurs phases de test de l'ensemble (8) d'au moins un équipement du réseau. 2. Système selon la revendication 1, caractérisé en ce qu'il comporte: un réseau de contrôle (1), dans lequel sont placés les serveurs 15 de test (4,5,6,7) et le serveur de commande (3), ledit réseau de contrôle (1) comprenant un réseau physique et un réseau (IP) utilisant le protocole Internet; et - un réseau de test (2), dans lequel sont placés les serveurs de test (4, 5,6,7) et l'ensemble (8) d'au moins un équipement à 20 tester, ledit réseau de test (2) comprenant un réseau physique et un réseau (IP) utilisant le protocole Internet; et en ce que le réseau de contrôle (1) et le réseau de test (2) sont des réseaux distincts. 3. Système selon l'une des revendications 1 ou 2, 25 caractérisé en ce qu'il comporte des outils (35,39) proposés par un système d'exploitation pour implémenter des couches protocolaires d'un système d'interconnexion de systèmes ouverts (OSI), qui sont utilisés par les serveurs de test (4, 5,6,7) pour générer des sessions client/serveur de test. 4. Système selon l'une quelconque des revendications l à 3, caractérisé en ce que, dans le réseau de contrôle (1), le serveur de commande (3) est relié à tous les serveurs de test (4,5,6,7) selon une configuration maître/esclave, le serveur de commande (3) constituant un serveur maître et les serveurs de test (4,5,6,7) constituant des serveurs esclaves. 5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que les serveurs de test (4,5,6,7) sont placés 5 de part et d'autre de l'ensemble (8) d'au moins un équipement à tester, déterminant ainsi un caractère client ou serveur de chaque serveur de test. 6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que chaque serveur de test (4,5,6,7) gère 10 plusieurs ensembles (33) d'au moins un client ou serveur d'un modèle client/serveur, les clients ou les serveurs de chaque ensemble ayant le même comportement vis- à-vis du trafic du réseau. 7. Système selon l'une quelconque des revendications 1 à 15 6, caractérisé en ce que le serveur de commande (3) possède un pilote (30) de gestion de scénarios de test. 8. Système selon la revendication 7, caractérisé en ce que le pilote (30) comporte un ensemble de commandes, stockées en mémoire et destinées à commander à distance l'ensemble des 20 serveurs de test (4,5,6,7) . 9. Système selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend des moyens (34,35) pour provoquer le démarrage aléatoire ou pseudo aléatoire de la génération du trafic de données de test par chaque serveur de test. 25 10. Système selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend des moyens (34) pour synchroniser le démarrage de la génération du trafic de données de test par les ensembles (33) d'au moins un client ou serveur pour chaque serveur de test (4,5,6,7) , et pour synchroniser la 30 déconnexion desdits ensembles pour chaque serveur de test (4,5,6,7). 11. Système selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend des moyens (32) pour synchroniser le démarrage de la génération du trafic de données il de test par la totalité des ensembles (33) d'au moins un client ou serveur pour chaque serveur de test (4,5,6,7) , et pour synchroniser la déconnexion de la totalité desdits ensembles pour chaque serveur de test (4,5,6,7). 12. Système selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il comprend des moyens (31) pour synchroniser le démarrage de la génération du trafic de données de test par la totalité des ensembles (33) d'au moins un client ou serveur pour tous les serveurs de test (4,5,6,7), et pour 10 synchroniser la déconnexion de la totalité desdits ensembles pour tous les serveurs de test (4,5,6,7). 13. Système selon l'une quelconque des revendications 1 à 12, caractérisé en ce qu'il comporte un module d'analyse des résultats délivrés lors d'une phase de test. 14. Système selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'il comporte un module de génération automatique de scénarios de test. 15. Procédé de test d'un ensemble d'au moins un équipement de réseaux informatiques, mis en oeuvre au moyen 20 d'un système selon l'une quelconque des revendications 1 à 13, caractérisé en ce que l'on pilote des serveurs de test (4,5,6,7) au moyen d'un serveur de commande (3) de manière à générer un trafic de données de test sur un réseau.