Brevet FR3073108A1 — publié le 20190503

Procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour La présente invention concerne le domaine de la virtualisation des réseaux, et plus particulièrement l'anticipation de défaillances lors de l'application de correctifs sur des fonctions réseau virtualisées en cours d'exécution dans un environnement virtuel de production. Nous assistons depuis une dizaine d'années à une évolution majeure des réseaux de télécommunications. Cette évolution, qui tend vers une unification des ressources informatiques et réseau, vise principalement à rendre les ressources réseaux programmables ; elle repose sur de nouveaux paradigmes réseaux : le SDN (pour « Software Defined Networks), le NFV (pour « Network Function Virtualization ») et plus généralement, la virtualisation réseau. La virtualisation réseau permet l'exécution de multiples topologies virtuelles de réseaux, indépendantes les unes des autres, sur une même architecture physique. Elle intervient sur trois plans : - ressources matérielles : la virtualisation réseau prévoit un partitionnement de la bande passante réseau entre de multiples utilisateurs clients auxquels des réseaux virtuels ont été alloués, - couche de gestion : la virtualisation réseau propose une mutualisation du plan de gestion qui permet à différents utilisateurs de piloter l'acheminement des paquets réseau sur un réseau virtuel qui leur a été alloué ; - couche virtuelle : elle correspond à l'ensemble des machines virtuelles qui exécutent des fonctions réseaux virtualisées. Une fonction réseau virtualisée, par exemple une fonction de traduction d'adresse, peut être mise en oeuvre dans cette architecture virtuelle, par une machine virtuelle ou plusieurs. Lorsqu'une topologie virtuelle de réseau est instanciée pour un utilisateur ou un groupe d'utilisateurs, ou pour un service particulier, on parle de « slice réseau » (ou « tranche de réseau » en français). Les utilisateurs sont par exemple des fournisseurs d'infrastructures virtuelles, des entreprises, des utilisateurs finaux, etc. Ainsi, plusieurs slice réseau, indépendants les uns des autres, peuvent cohabiter et reposer sur une même infrastructure matérielle. Un utilisateur, tel une entreprise, n'a une vision que de son slice et n'accède qu'à son slice réseau. Un opérateur de l'infrastructure virtuelle qui met à disposition des réseaux virtuels garantit l'isolation des réseaux virtuels les uns vis-à-vis des autres. L'ETSI a défini un modèle de référence, connu sous le nom de « MANO », qui décrit l'ensemble des entités permettant l'orchestration de fonctions réseaux proposées par une telle infrastructure, telles que la création, le déploiement, la migration, etc., de machines virtuelles 2 sous-jacentes. Ce modèle introduit des composantes telles que les fonctions réseau virtualisées, ou « VNF » (pour « Virtual Network Function »), qui réalisent une fonction réseau spécifique et qui sont mises en oeuvre par une ou plusieurs machines virtuelles qui contiennent une suite logicielle et des options nécessaires à l'exécution de ces fonctions. Le modèle MANO définit 5 également la « VIM » (pour « Virtual Infrastructure Management »), qui correspond à la couche de gestion de l'infrastructure matérielle, de la couche de virtualisation et de la couche virtuelle. La virtualisation réseau permet ainsi une grande flexibilité dans les offres réseau. Un utilisateur tel une entreprise ou une administration, etc., dispose de son réseau comme s'il disposait d'un réseau physique classique. La virtualisation réseau permet de virtualiser 10 l'intégralité des serveurs, routeurs, commutateurs et pare-feu de topologies réseau pour qu'ils s'exécutent tous sur une seule plate-forme matérielle, sans investissement supplémentaire dans le matériel réseau. Dans une telle architecture virtuelle de réseau, au même titre que dans une architecture réseau classique, des mises à jour peuvent être nécessaires. Il est habituel dans ce cas 15 d' appliquer des correctifs sur des fonctions réseau virtualisées, au même titre que sur des équipements réseau qui mettraient en oeuvre ces fonctions dans une architecture réseau classique. L' application de correctifs repose de manière classique sur des procédures de tests. Il est habituel pour la mise en oeuvre de ces procédures de définir un jeu de tests le plus exhaustif 20 possible, d'appliquer ce jeu de test à la fonction patchée, c'est-à-dire la fonction à mettre à jour qui intègre le correctif, puis, une fois les tests passés avec succès, de patcher, ou d' appliquer le correctif à la fonction à mettre à jour qui s'exécute dans son environnement de production. Les tests s'effectuent en général dans un environnement de test, isolé de l'environnement de production et censé reproduire l'environnement de production de la fonction à mettre à jour. 25 Cependant, les procédures de tests ne peuvent pas anticiper toutes les défaillances possibles d'une fonction réseau virtualisée mise à jour dans un réseau virtuel. On recense au moins trois catégories de défaillances qui ne peuvent être anticipées : - incomplétude des jeux de tests. Cela va bien sûr au-delà d'un contexte de virtualisation réseau ; 30 - état antérieur de la fonction réseau virtualisée à mettre à jour ; un correctif est appliqué sur au moins une machine virtuelle de la fonction réseau virtualisée qui dispose déjà d'un état système. Cet état comprend des valeurs de registres CPU, le contenu de pages mémoire, des connexions réseau, etc. Lorsque des correctifs sont appliqués durant la phase de test sur une machine virtuelle créée pour les besoins 35 d'un test, celle-ci dispose d'un état antérieur différent de celui de la machine 3 virtuelle en cours d'exécution en environnement de production. A cause de ces états différents, le correctif peut produire des résultats différents et inattendus selon la fonction réseau virtualisée sur laquelle il est appliqué ; - imprédictibilité du trafic entrant de la fonction réseau virtualisée à mettre à jour : 5 les fonctions réseau virtualisées précédentes, c'est-à-dire celles qui sont traversées par un trafic qui est ensuite acheminé vers la fonction réseau virtualisée à mettre à jour peuvent introduire des anomalies dont il est difficile de tenir compte dans les tests. 10 Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. À cette fin l'invention propose un procédé d'application d'un correctif à une fonction réseau virtualisée à mettre à jour comprise dans un premier réseau virtuel, un hyperviseur réseau s'interfaçant entre le premier réseau virtuel et un ensemble d'au moins une ressource matérielle 15 apte à fournir des ressources nécessaires audit premier réseau virtuel, ledit procédé, mis en oeuvre par l'hyperviseur réseau, comprenant : - identification d'un ensemble de fonctions réseau virtualisées dépendantes comprises dans le premier réseau virtuel, ledit ensemble comprenant au moins la fonction réseau virtualisée à mettre à jour, 20 - création d'un second réseau virtuel, dit « réseau virtuel de test », ledit réseau virtuel de test comprenant des clones de machines virtuelles mettant en oeuvre les fonctions réseau virtualisées dépendantes de l'ensemble, lesdites machines virtuelles clonées formant des clones des fonctions réseau virtualisées dépendantes de l'ensemble, - interconnexion dans le réseau virtuel de test des clones des fonctions réseau 25 virtualisées dépendantes de l'ensemble, ladite interconnexion étant identique à une interconnexion dans le premier réseau des fonctions réseau virtualisées dépendantes de l' ensemble, - identification d'au moins un paquet de données en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, duplication dudit paquet 30 et acheminement dudit paquet dupliqué vers le réseau virtuel de test, - application d'un correctif au clone de la fonction réseau virtualisée à mettre à jour dans le réseau de test, - collecte et comparaison de valeurs d' au moins un premier et un deuxième indicateur de performance, un premier indicateur mesurant une valeur de performance sur une fonction 35 réseau virtualisée supervisée de l'ensemble de fonctions réseau virtualisées dépendantes du 4 premier réseau virtuel et un deuxième indicateur mesurant la valeur de performance sur le clone de la fonction réseau virtualisée supervisée dans le réseau virtuel de test, une alerte étant déclenchée lorsque les valeurs des premier et deuxième indicateurs different. Le procédé décrit ici permet d'anticiper des défaillances lors de l'application de 5 correctifs sur des fonctions réseau virtualisées à mettre à jour et en cours d'exécution dans un environnement de production. La création du réseau virtuel de test se fait sans arrêt ni perturbation du réseau virtuel de production. En effet, la ou les machines virtuelles qui mettent en oeuvre la ou les fonctions réseau virtualisées qui sont destinées à faire partie du réseau virtuel de test sont dupliquées, ou clonées « à chaud », c'est-à-dire sans interrompre leur exécution. Ce 10 clonage permet d'obtenir des fonctions réseau virtualisées et machines virtuelles sous-jacentes qui disposent d'un état système identique à celui des fonctions réseau virtualisées et machines virtuelles sous-jacentes qui s'exécutent dans le réseau virtuel de production. Les conditions de test ainsi créées dans le réseau virtuel de test sont donc similaires à celles du réseau de production et donc idéales pour tester la fonction réseau virtualisée à mettre à jour. 15 Par ailleurs, les conditions de test sont telles, qu'elles correspondent à l'environnement opérationnel associé au réseau virtuel de production. En effet, des paquets en entrée des fonctions réseau virtualisées dépendantes sont copiés et acheminés vers le réseau virtuel de test. Ainsi, il n'est pas nécessaire de prévoir un jeu de test spécifique puisque le réseau virtuel de test fonctionne en quelques sortes en parallèle du réseau virtuel de production et reçoit les mêmes 20 paquets que ceux reçus par les fonctions réseau virtualisée dépendantes dans l'environnement de production. La mise en place d'un réseau virtuel de test fortement corrélé au réseau de production, puisque tout paquet entrant destiné à une fonction réseau virtualisée de l'ensemble de fonctions dépendantes est dupliqué et acheminé vers les fonctions réseau virtualisées correspondantes 25 dans le réseau virtuel de test, permet de tenir compte d'anomalies dans les paquets entrants qui seraient imputables à des fonctions réseau virtualisées précédentes, c'est-à-dire des fonctions réseau virtualisées qui sont traversées par les paquets qui sont ensuite acheminés vers la fonctions réseau virtualisée à mettre à jour ou plus généralement vers une fonction réseau virtualisée dépendante. Ainsi, le test du correctif se fait de manière optimum, sans craindre les 30 incomplétudes du jeu de test à ce niveau-là, c'est-à-dire au niveau du contenu des paquets entrants. Dans un exemple de réalisation, l'ensemble de fonctions réseau virtualisées dépendantes comprend également au moins une autre fonction réseau virtualisée fonctionnellement dépendante de la fonction réseau virtualisée à mettre à jour. 5 L'ensemble des fonctions réseau virtualisées dépendantes qui sont identifiées sont celles qui sont susceptibles d'être perturbées lors de l'application du correctif sur la fonction réseau virtualisée à mettre à jour. Elles sont en effet toutes fonctionnellement dépendantes de la fonction réseau virtualisée à mettre à jour. Elles sont donc toutes susceptibles d'être impactées 5 par le correctif. Dans un exemple de réalisation, ces fonctions dépendantes sont identifiées par un gestionnaire du réseau de production, à partir des connaissances que celui-ci a de son réseau de production. Dans un premier exemple de réalisation, un gestionnaire d'infrastructure virtuelle mettant à disposition d'un client auquel a été alloué le premier réseau virtuel, une interface de 10 l'hyperviseur réseau afin que le client contrôle le premier réseau virtuel, ledit client exerçant ainsi un contrôle dit indirect du premier réseau virtuel, l'identification d'un paquet en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, la duplication et l'acheminement dudit paquet dupliqué vers le réseau de test comprend, lorsque la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes et le 15 clone de la fonction réseau virtualisée correspondante comprise dans le second réseau sont hébergées par un même serveur hôte : l'installation d'une règle de configuration sur un équipement réseau d'acheminement du serveur hôte, ledit équipement réseau d'acheminement étant adapté pour transmettre le paquet à la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, ladite 20 règle de configuration comprenant une duplication du paquet en entrée de la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, et un envoi dudit paquet dupliqué au clone de la fonction réseau virtualisée correspondante comprise dans le second réseau et hébergée par le serveur hôte. Dans un deuxième exemple de réalisation, un gestionnaire d'infrastructure virtuelle 25 mettant à disposition d'un client auquel a été alloué le premier réseau virtuel, une interface de l'hyperviseur réseau afin que le client contrôle le premier réseau virtuel, ledit client exerçant ainsi un contrôle dit indirect du premier réseau virtuel, l'identification d'un paquet en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, la duplication et l'acheminement dudit paquet dupliqué vers la fonction réseau virtualisée 30 correspondante dans le réseau de test comprend, lorsque la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes est hébergée par un premier serveur hôte (hl) et que le clone de la fonction réseau virtualisée correspondante comprise dans le second réseau est hébergée par un deuxième serveur hôte : l'installation d'une première règle de configuration sur un premier équipement réseau 35 d'acheminement du premier serveur hôte, ledit premier équipement réseau d'acheminement 6 étant adapté pour transmettre le paquet à la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, ladite règle de configuration comprenant une duplication du paquet en entrée de la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, et un envoi dudit paquet dupliqué vers le deuxième serveur, une 5 deuxième règle de configuration étant installée sur un deuxième équipement réseau d' acheminement compris dans le deuxième serveur hôte, la deuxième règle de configuration comprenant l'envoi dudit paquet au clone de la fonction réseau virtualisée correspondante comprise dans le second réseau et hébergée par le deuxième serveur hôte. Dans un autre exemple de réalisation, l'hyperviseur réseau reçoit d'un opérateur du 10 premier réseau virtuel une règle destinée à être installée dans un équipement réseau d' acheminement, ladite règle modifiant un identifiant du premier réseau virtuel compris dans un paquet destiné à être acheminé vers le réseau virtuel de test, en un identifiant du réseau virtuel de test, ladite règle étant installée sur l'équipement par l'hyperviseur lorsque le réseau virtuel de test est dédié aux tests de fonctions réseau virtualisées et que le premier réseau virtuel et le 15 réseau virtuel de test appartiennent à un même client. Selon un exemple de réalisation du procédé, un protocole de communication orienté connexion étant utilisé pour communiquer avec une fonction réseau virtualisée dépendante de l'ensemble, l'étape d'identification, de duplication et d'acheminement d'un paquet vers le réseau de test comprend, dans une phase d'établissement d'une connexion : 20 - réception d'un paquet de synchronisation, ledit paquet ayant été reçu par la fonction réseau virtualisée dépendante, dupliqué et destiné à être acheminé vers la fonction réseau virtualisée correspondante dans le réseau de test, ledit paquet comprenant un identifiant de connexion, et acheminement dudit paquet de synchronisation à la fonction réseau virtualisée correspondante dans le réseau de test, 25 - réception en provenance de la fonction réseau virtualisée correspondante d'un premier paquet d'acquittement comprenant un premier numéro de séquence, et association du premier numéro de séquence compris dans ledit paquet d'acquittement à l'identifiant de connexion, et acheminement dudit premier paquet d'acquittement, - réception d'un deuxième paquet d' acquittement, ledit deuxième paquet d'acquittement 30 ayant été préalablement reçu par la fonction réseau virtualisée dépendante, dupliqué et destiné à être acheminé vers la fonction réseau virtualisée correspondante dans le réseau de test, ledit paquet comprenant l'identifiant de connexion et un premier numéro d'acquittement calculé en incrémentant un deuxième numéro de séquence généré et transmis préalablement par la fonction réseau virtualisée dépendante, et remplacement dans le deuxième paquet d'acquittement dudit 35 premier numéro d' acquittement par un deuxième numéro d' acquittement calculé en 7 incrémentant le premier numéro de séquence, et acheminement dudit deuxième paquet d' acquittement à la fonction réseau virtualisée correspondante dans le réseau de test. Dans cet exemple de réalisation, une fonction réseau virtualisée de gestion des connexions permet, dans le cas de protocoles de communication orientés connexion de gérer les 5 connexions propres au protocole utilisé de façon transparente pour le client. Cette gestion est nécessaire du fait de l'acheminement des paquets entrants de l'ensemble des fonctions réseau virtualisées vers les fonctions réseau virtualisées correspondantes de l'environnement de test. La gestion des connexions est centralisée au niveau d'une fonction réseau virtualisée de gestion des connexions apte à identifier si une telle gestion est nécessaire, c'est-à-dire à identifier si le type 10 de protocole utilisé nécessite une gestion spécifique des connexions, et à gérer l'ensemble des connexions afin que le procédé d'application du correctif s' applique sans autre modification. L'invention concerne aussi un serveur comprenant un hyperviseur réseau s'interfaçant entre un premier réseau virtuel et un ensemble d'au moins une ressource matérielle apte à fournir des ressources nécessaires audit premier réseau virtuel, ledit hyperviseur étant 15 adapté pour appliquer un correctif à une fonction réseau virtualisée à mettre à jour comprise dans le premier réseau virtuel, ledit serveur comprenant : - des premiers moyens d'identification, agencés pour identifier un ensemble de fonctions réseau virtualisées dépendantes comprises dans le premier réseau virtuel, ledit ensemble comprenant au moins la fonction réseau virtualisée à mettre à jour, 20 - des moyens de création, agencés pour créer un second réseau virtuel, dit « réseau virtuel de test », ledit réseau virtuel de test comprenant des clones de machines virtuelles mettant en oeuvre les fonctions réseau virtualisées dépendantes de l'ensemble, lesdites machines virtuelles clonées formant des clones des fonctions réseau virtualisées dépendantes de l' ensemble, 25 - des moyens d'interconnexion, agencés pour interconnecter dans le réseau virtuel de test des clones des fonctions réseau virtualisées dépendantes de l'ensemble, l'interconnexion des clones des fonctions réseau virtualisées dépendantes de l'ensemble étant identique à une interconnexion dans le premier réseau des fonctions réseau virtualisées dépendantes de l' ensemble, 30 - des moyens d'identification, de duplication et d' acheminement, agencés pour identifier au moins un paquet de données en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes pour dupliquer ledit paquet et pour acheminer ledit paquet dupliqué vers le réseau virtuel de test, - des moyens d' application, agencés pour appliquer un correctif au clone de la fonction 35 réseau virtualisée défaillante dans le réseau de test, 8 - des moyens de collecte et de comparaison, agencés pour collecter et comparer des valeurs d'au moins un premier et un deuxième indicateur de performance, un premier indicateur mesurant une valeur de performance sur une fonction réseau virtualisée supervisée de l'ensemble de fonctions réseau virtualisées dépendantes du premier réseau virtuel et un 5 deuxième indicateur mesurant la valeur de performance sur le clone de la fonction réseau virtualisée supervisée dans le réseau virtuel de test, une alerte étant déclenchée lorsque les valeurs des premier et deuxième indicateurs diffèrent. L'invention porte également sur un programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un serveur informatique, comprenant des instructions de code 10 de programme destinées à commander l'exécution des étapes du procédé d'application d'un correctif à une fonction réseau virtualisée à mettre à jour dans un réseau virtuel tel que décrit précédemment, lorsque le programme est exécuté sur ledit serveur. D'autres caractéristiques et avantages de la présente invention seront mieux compris de 15 la description et des dessins annexés parmi lesquels : - la figure 1 présente les étapes d'un procédé d'application d'un correctif à une fonction réseau virtuelle à mettre à jour, selon un exemple de réalisation ; - les figures 2a et 2b présentent un premier et un deuxième exemple d'architecture matérielle sous-jacente et de configuration de cette architecture par un hyperviseur réseau pour 20 la mise en oeuvre de certaines étapes du procédé d'application d'un correctif, dans le cas d'un contrôle indirect des réseaux virtuels ; - la figure 3 présente un exemple d'architecture matérielle sous-jacente et de configuration de cette architecture par un hyperviseur réseau pour la mise en oeuvre de certaines étapes du procédé d'application d'un correctif dans le cas d'un contrôle direct des réseaux 25 virtuels ; - la figure 4 présente les étapes d'un procédé de gestion des connexions dans le cas de l'utilisation d'un protocole de communication orienté connexion, selon un exemple de réalisation ; - la figure 5 est une représentation schématique d'un serveur comprenant un hyperviseur 30 réseau agencé pour mettre en oeuvre les étapes du procédé d'application d'un correctif, selon un exemple de réalisation. Les étapes d'un procédé d'application d'un correctif à une fonction réseau virtualisée à mettre à jour, selon un exemple de réalisation, vont maintenant être décrites en relation avec la 35 figure 1. 9 On suppose que dans une phase initiale de mise à disposition d'un réseau virtuel, un gestionnaire d'infrastructure virtuelle a mis à disposition d'un client, sur demande de celui-ci, un réseau virtuel, dit réseau virtuel de production, noté VNA. L'infrastructure virtuelle s'inscrit dans un contexte de virtualisation réseau et est adaptée pour proposer à différents clients des 5 topologies de réseaux virtuels indépendantes les unes des autres, ou « slice réseau » (« tranche de réseau » en français), et qui s'exécutent au-dessus d'une même infrastructure matérielle. Le réseau virtuel VNA est agencé pour héberger un ou plusieurs services, selon les besoins du client. Un service qui s'exécute dans le réseau virtuel de production VNA comprend un ensemble logique de fonctions réseau virtualisées, ou « VNF » (de l'anglais « Virtual Network 10 Function »). Chaque fonction réseau virtualisée est adaptée pour exécuter un traitement spécifique, par exemple un traitement de routage de paquets, un traitement de pare-feu, un traitement de traduction d'adresses, etc. Ces fonctions réseau virtualisées communiquent par échange de paquets afin de rendre le service attendu. Chaque fonction réseau virtualisée est mise en oeuvre par une ou plusieurs machines virtuelles, ou « VM » (de l'anglais « Virtual 15 Machine »). Comme précisé précédemment, le réseau virtuel de production VNA du client s'appuie sur un ensemble de ressources matérielles réparties sur un ou plusieurs équipements hôtes, tels que des serveurs informatiques et éventuellement des équipements réseau dédiés, tels que des routeurs, des switch, etc. A noter que les fonctions d'équipements réseau dédiés peuvent également être rendues par des modules logiciels, l'infrastructure matérielle dans ce cas est 20 composée exclusivement de serveurs informatiques. Le client accède à son réseau virtuel VNA à travers un module logiciel appelé opérateur de réseau virtuel. Un hyperviseur réseau, contrôlé par le gestionnaire de l'infrastructure, s'interface entre les ressources matérielles de l'infrastructure et l'opérateur du réseau virtuel contrôlé par le client, et entre l'opérateur du réseau virtuel et le réseau virtuel de production VNA du client. L'hyperviseur réseau alloue au 25 réseau virtuel VNA du client les ressources matérielles dont il a besoin de façon transparente pour le client. Le client, via l'opérateur de réseau virtuel, n'a une vue que de son réseau virtuel VNA; il n'accède pas aux ressources matérielles sous-jacentes. Selon l'hyperviseur réseau, le client peut contrôler son réseau virtuel via l'opérateur du réseau selon différentes méthodes. Selon un premier exemple de mise en oeuvre de contrôle d'un réseau virtuel par un 30 client, l'hyperviseur réseau, qui s'interface entre l'opérateur du réseau virtuel et le réseau virtuel VNA du client, met à disposition de celui-ci une interface, ou « API » (pour « Application Programming Interface ») adaptée pour recevoir des requêtes du client et pour les appliquer aux fonctions réseau virtualisées du réseau virtuel VNA du client. Cette API offre au client une vision de l'ensemble des fonctions réseau virtualisées et des machines virtuelles de son réseau 35 virtuel VNA. L'hyperviseur réseau traduit des requêtes du client en configuration pour 10 l'infrastructure matérielle sous-jacente. Lorsque l'hyperviseur réseau met à disposition du client une telle interface pour accéder à son réseau virtuel, on dit que le client exerce un contrôle indirect de son réseau. La topologie physique est complètement cachée au client et le client ne voit de son réseau virtuel que les fonctions réseau virtualisées et les machines virtuelles. Cette 5 approche offre une grande flexibilité à l'hyperviseur réseau dans la manière dont il garantit l'isolation entre les réseaux virtuels. La façon dont les paquets sont acheminés entre des machines virtuelles et/ou des fonctions réseau virtualisées du réseau pour satisfaire la configuration définie par le client est contrôlée par l'hyperviseur réseau et non déterminée par le client. Typiquement, l'hyperviseur réseau peut mettre en place des tunnels pour encapsuler les 10 données entre les machines virtuelles d'un même réseau virtuel au lieu de définir des réseaux locaux virtuels (« VLAN » pour Virtual Local Area Network » en anglais). On suppose par la suite que le client exerce un contrôle indirect de son réseau virtuel VNA. Dans une étape initiale EO d'identification d'une fonction réseau virtualisée à mettre à jour et de développement d'un correctif, ou patch, le client identifie dans son réseau virtuel de 15 production VNA une fonction réseau virtualisée à mettre à jour. On note cette fonction réseau virtualisée VNFA. Par exemple, une dégradation des performances ou des dysfonctionnements ponctuels ont été observés sur la fonction réseau virtualisée VNFA. On suppose que le client dispose d'un outil de supervision adapté pour détecter une telle défaillance. Dans un autre exemple de réalisation, une faille de sécurité a été publiée ; cette faille concerne la fonction 20 réseau virtualisée sans que pour autant la faille ait été exploitée et n'ait impactée le réseau virtuel de production VNA. Dans un autre exemple de réalisation, il a été décidé qu'une fonction réseau virtualisée nécessitait une légère mise à jour. On suppose également que le client a analysé le besoin inhérent à cette mise à jour et développé, ou fait développer un correctif, sous forme d'un module logiciel, censé mettre à jour la fonction réseau virtualisée. Il souhaite tester 25 l'application de ce correctif dans un environnement de test avant de l'appliquer à la fonction réseau virtualisée VNFA dans son environnement de production, c'est-à-dire dans le réseau virtuel VNA. En tout état de cause, on se place ici dans un cas où l'on souhaite mettre à jour une fonction réseau virtualisée sans avoir à rebooter le système du ou des serveurs hôtes sous-jacents. La mise à jour est donc destinée à être mise en oeuvre dans le réseau virtuel de 30 production VNA, sans interrompre le fonctionnement de celui-ci. Dans une étape El de fourniture d'une configuration pour le test, le client communique au gestionnaire de l'infrastructure virtuelle une liste de fonctions réseau virtualisées dépendantes qui comprend la fonction réseau virtualisée à mettre à jour VNFA, ainsi qu'un ensemble de fonctions réseau virtualisées du réseau virtuel VNA identifiées comme étant 35 fonctionnellement dépendantes de la fonction réseau virtualisée VNFA à mettre à jour. . Cet 11 ensemble de fonctions réseau virtualisées dépendantes qui comprend la fonction réseau virtualisée à mettre à jour VNFA et le cas échéant les fonctions réseau virtualisées fonctionnellement dépendantes de la fonction réseau virtualisée à mettre à jour VNFA comprend l'ensemble des fonctions réseau virtualisées qui participent au traitement d'un paquet issu de la 5 fonction réseau virtualisée VNFA à mettre à jour ; cet ensemble est noté VNFDepA ; il est fourni par le client à l'hyperviseur réseau sous forme d'une liste d'identifiants des fonctions dans leur environnement de production VNA. Dans un premier exemple de réalisation, un administrateur réseau du réseau virtuel de production VNA du client a une connaissance suffisante de l'architecture du réseau virtuel VNA 10 pour fournir la liste des identifiants des fonctions réseau virtualisées dépendantes VNFDepA qui comprend la fonction réseau virtualisée à mettre à jour VNFA et le cas échéant les fonctions réseau virtualisées qui en dépendent fonctionnellement. Dans une étape suivante E2 de création d'un réseau virtuel de test, l'hyperviseur réseau crée un second réseau virtuel, ou slice réseau VNB, dit « réseau virtuel de test », propre au 15 client, sur la base de la configuration fournie précédemment. Ce réseau virtuel de test VNB est destiné à tester le correctif à appliquer à la fonction réseau virtualisée à mettre à jour VNFA dans un environnement de test similaire à une partie de l'environnement de production que constitue le réseau virtuel VNA, en l'espèce au sous-réseau qui comprend l'ensemble VNFDepA des fonctions réseau virtualisées dépendantes. A cette fin, l'hyperviseur réseau, plus précisément le 20 gestionnaire de l'infrastructure virtuelle, commande le clonage, ou la duplication, de l'ensemble des machines virtuelles qui mettent en oeuvre les fonctions réseau virtualisées de la liste des fonctions réseau virtualisées dépendantes VNFDepA fournie au cours de l'étape El précédente. A noter que dans des infrastructures de virtualisation existantes, par exemple OpenStack, des logiciels adaptés pour créer et gérer un environnement virtuel et notamment pour cloner des 25 machines virtuelles existent ; ils ne nécessitent pas d'arrêter les machines virtuelles ; on appelle cette opération « clonage à chaud » (ou « hot cloning » en anglais). Ainsi, le fonctionnement du réseau virtuel de production VNA du client n'est pas perturbé lors du clonage des machines virtuelles. Lorsqu'une machine virtuelle est clonée, ou dupliquée, la machine virtuelle obtenue, ou clone de la machine virtuelle, possède les mêmes caractéristiques que la machine virtuelle : 30 même adresse réseau, même adresse MAC ; elle dispose des mêmes quantités de ressources, etc. Elle est cependant installée sur des pages mémoire différentes. Les machines virtuelles clonées sont donc distinctes des machines virtuelles tout en offrant des fonctionnalités identiques. Les machines virtuelles dupliquées sont rattachées au réseau virtuel de test VNB. A ce stade, le réseau virtuel de test VNB comprend donc l'ensemble des fonctions réseau virtualisées 35 dépendantes VNFDepA dont la liste a été fournie au cours de l'étape El. Plus précisément, le 12 réseau de test VNB comprend l'ensemble des clones des machines virtuelles qui mettent en oeuvre les fonctions réseau virtualisées de la liste VNFDePA- Dans l'environnement d'exécution que constitue le réseau de test VNB, la liste des fonctions réseau virtualisées qui sont mises en oeuvre par l'ensemble de machines virtuelles clonées est notée VNFDepB. Par la suite on dit aussi 5 que les clones des fonctions réseau virtualisées VNFDepB sont les fonctions réseau virtualisées correspondantes des fonctions réseau virtualisées dépendantes VNFDepA dans le réseau de test VNB. Dans une étape E3 de configuration du réseau virtuel de test, l'hyperviseur réseau configure les équipements réseaux de l'infrastructure matérielle sous-jacente de manière à 10 interconnecter l'ensemble VNFDepB des clones des fonctions réseau virtualisées, comprises dans le réseau virtuel de test VNB. Les clones des fonctions réseau virtualisées dépendantes de la liste VNFDepB sont interconnectées dans le réseau de test VNB de la même manière que le sont les fonctions réseau virtualisées dépendantes de la liste VNFDepA du réseau de production VNA. A noter que cette étape ne nécessite pas d'outrepasser l'isolation réseau puisque les réseaux 15 virtuels VNA et VNB sont complètement disjoints à ce stade. Dans une étape suivante E4 d'identification, de duplication et d'acheminement de paquets, l'hyperviseur réseau identifie des paquets de données entrants de l'ensemble constitué des fonctions réseau virtualisées dépendantes VNFDepA du réseau virtuel VNA et duplique ces paquets afin de les acheminer également en entrée de l'ensemble constitué des fonctions réseau 20 virtualisées correspondantes VNFDepB du réseau virtuel de test VNB. A noter que les paquets identifiés ont été émis dans le réseau de production VNA par une fonction réseau virtualisée extérieure à l'ensemble VNFDepA. La duplication des paquets en entrée de l'ensemble de fonctions réseau virtualisées dépendantes VNFDepA et l'acheminement des paquets dupliqués vers l'ensemble de fonctions réseau virtualisées VNFDepB correspondantes dans le réseau de test 25 VNB nécessite de modifier l'hyperviseur réseau. En effet, un tel traitement outrepasse l'isolation entre les réseaux puisqu'un paquet, initialement acheminé à l'intérieur du réseau virtuel VNA se trouve également être acheminé dans un autre réseau virtuel, en l'espèce le réseau virtuel de test VNB. Dans l'exemple de réalisation décrit ici, correspondant à un contrôle indirect du client 30 sur son réseau virtuel de production VNA pour lequel l'hyperviseur réseau met à disposition du client une interface d'accès API afin que celui-ci contrôle son réseau virtuel, l'hyperviseur réseau modifie l'API qu'il met à disposition du client afin que les paquets qui sont destinés à l'ensemble de fonctions réseau virtualisées dépendantes VNFDepA dans le réseau virtuel de production VNFA soient également acheminés vers l'ensemble des clones des fonctions réseau 35 virtualisées VNFDepB du réseau de test VNB. Cette modification, bien qu'allant à l'encontre de 13 l'isolation réseau, est sous contrôle de l'hyperviseur réseau et est destinée à mettre en place un environnement de test en parallèle de l'environnement de production dans lequel évolue la fonction réseau virtualisée défaillante VNFA et ce, sans perturber le fonctionnement de celui-ci. Cette modification se traduit par la définition d'une nouvelle action de configuration, accessible 5 par le client à partir de l'API, et destinée à commander qu'un paquet reçu par une fonction réseau virtualisée de la liste VNFDepA soit dupliqué et acheminé également au clone de cette fonction réseau virtualisée, ou fonction réseau virtualisée correspondante de la liste VNFDepB du réseau de test VNB. Cette action, paramétrée au niveau de l'API par le client, se traduit pour l'hyperviseur réseau en une action de configuration des ressources matérielles sous-jacentes. A 10 cette fin l'hyperviseur réseau configure un équipement réseau d'acheminement situé en amont d'une fonction réseau virtualisée de l'ensemble VNFDepA, notée VNFX, du réseau virtuel de production VNA qui reçoit un paquet entrant en provenance d'une fonction réseau virtualisée externe à l'ensemble. Plus précisément, cet équipement d'acheminement est celui qui achemine des paquets vers la fonction réseau virtualisée VNFX dans le réseau VNA de production. 15 L'équipement est par exemple un commutateur réseau (ou « switch » en anglais), agencé pour relier plusieurs segments dans un réseau et qui permet de créer des circuits virtuels, ou un routeur réseau, lorsqu'il s'agit d'interconnecter des réseaux. L'équipement d'acheminement peut être un équipement réseau dédié ou un équipement logiciel hébergé par un serveur hôte qui met en oeuvre des fonctions de l'équipement. A noter que la fonction réseau virtualisée VNFX 20 peut recevoir des paquets de différentes provenances, ce qui peut se traduire par un acheminement mis en oeuvre par plusieurs équipements d'acheminement. Le paramétrage consiste alors à paramétrer ces multiples équipements d'acheminement afin que la fonction réseau virtualisée correspondant à VNFX dans le réseau de test VNB reçoive l'ensemble des paquets destinés à la fonction réseau virtualisée VNFX du réseau de production VNA. Le 25 paramétrage consiste à dupliquer l'intégralité des paquets destinés à la fonction réseau virtualisée VNFX et à acheminer les paquets dupliqués vers la fonction réseau virtualisée correspondante du réseau de test VNB. A cette fin, l'équipement réseau d'acheminement est paramétré de manière à permettre la duplication et l'envoi du paquet au réseau virtuel de test VNB. Une fois la configuration appliquée à l'équipement réseau d'acheminement sous-jacent, 30 tout paquet destiné à la fonction réseau virtualisée VNFX dans le réseau virtuel de production VNA est dupliqué en un paquet dupliqué qui est acheminé vers la fonction réseau virtualisée correspondante dans le réseau virtuel de test VNB ; cette fonction réseau virtualisée correspondante est notée VNFX. A noter que différentes configurations matérielles sous-jacentes peuvent exister. Ainsi, 35 dans un premier exemple de configuration matérielle sous-jacente, illustré par la figure 2a, la 14 fonction réseau virtualisée VNFX du réseau de production VNA et la fonction réseau virtualisée correspondante dans le réseau virtuel de test VNB, VNFX, sont hébergées sur le même serveur hôte hl. Plus précisément, les machines virtuelles qui mettent en oeuvre les fonctions réseau virtualisées VNFX et VNF', sont hébergées par le même serveur hl. Dans ce cas, afin de 5 dupliquer et copier les paquets à destination de VNFX vers VNFX, l'hyperviseur réseau installe une règle sur un équipement réseau d'acheminement sl de type commutateur situé immédiatement en amont de la fonction réseau virtualisée VNFX dans le réseau de production VNA afin que tout paquet destiné à VNFX soit dupliqué et acheminé vers VNFX. Dans un deuxième exemple de configuration, illustré par la figure 2b, la fonction réseau 10 virtualisée VNFX du réseau de production VNA est hébergée par un premier serveur hôte hl et la fonction réseau virtualisée correspondante VNF', dans le réseau de test VNB est hébergée par un deuxième serveur hôte h2. Dans ce cas, un tunnel (en pointillés sur la figure 2b) est établi entre les deux serveurs hôtes hl, h2, le commutateur s1 situé immédiatement en amont de la fonction réseau virtualisée VNFX et qui achemine des paquets vers cette fonction réseau virtualisée est 15 configuré afin qu'un paquet destiné à la fonction VNFX soit dupliqué et acheminé à la fonction réseau virtualisée correspondante VNF', via le tunnel configuré à cet effet. Il peut être nécessaire de configurer un commutateur s2 du deuxième serveur hôte h2 lorsque plusieurs fonctions réseau virtualisées sont hébergées par le deuxième serveur hôte h2. Dans une étape E5 d'application du correctif, le client du réseau virtuel de production 20 VNA qui commande le réseau virtuel VNA et le réseau virtuel de test VNB, commande l'application du correctif, obtenu au cours de l'étape EO d'identification d'une fonction réseau virtualisée à mettre à jour et de développement d'un correctif, au clone de la fonction réseau virtualisée à mettre à jour VNFA, notée VNFA' dans le réseau de test VNB. A noter que des outils permettent d'appliquer un tel correctif sans avoir besoin de redémarrer la ou les machines 25 virtuelles sous-jacentes de la fonction réseau virtualisée VNFA', ou plus généralement du réseau de test VNB. On peut citer par exemple Ksplice, solution open source pour Linux. Dans une étape suivante E6 de supervision, le client supervise le fonctionnement des fonctions réseau virtualisées VNFDepA du réseau virtuel de production VNA et les fonctions réseau virtualisées correspondantes VNFDepB du réseau virtuel de test VNB. Des indicateurs de 30 performance systèmes et réseaux sont ainsi collectés au niveau de l'ensemble des fonctions réseau virtualisées VNFDepA et des fonctions réseau virtualisées correspondantes VNFDepB. A noter que les mêmes indicateurs sont collectés au niveau du réseau virtuel de production VNA et du réseau virtuel de test VNB. Les indicateurs réseaux comprennent par exemple le nombre de paquets ou d'octets émis, pour une connexion donnée ou sur une période de temps donné, la 35 durée des connexions, le nombre de paquets perdus le cas échéants. De tels indicateurs réseaux 15 sont collectés de façon périodique et accessibles dans une base de données centralisée de l'infrastructure. D'autres indicateurs peuvent être collectés au niveau des fonctions réseau virtualisées, notamment au moyen de journaux systèmes (ou fichiers « logs » en anglais). Ces autres indicateurs comprennent des codes et des taux d'erreur propres à l'application mise en 5 oeuvre par la fonction réseau virtualisée ; ils caractérisent de façon fine l'application qui est exécutée. Des indicateurs systèmes comprennent par exemple un temps ou pourcentage d'utilisation d'une CPU, d'un mémoire, d'un disque, etc. De tels indicateurs systèmes sont collectés par le gestionnaire de l'infrastructure virtuelle, par exemple OpenStack. Dans une étape suivante E7 d'analyse, un module d'analyse de l'hyperviseur réseau 10 procède à une comparaison et à une analyse des différents indicateurs de performance collectés d'une part au niveau de l'ensemble des fonctions réseau virtualisées VNFDepA et de l'ensemble des fonctions réseau virtualisée correspondantes VNFDepB du réseau virtuel de test VN2 dans lequel le correctif de sécurité a été appliqué au clone VNFA' de la fonction réseau virtualisée à mettre à jour VNFA. Le module d'analyse utilise des algorithmes d'analyse connus. Dans un 15 exemple de réalisation, on utilise l'algorithme d'analyse des corrélations canoniques, plus connu sous son nom anglais « Canonical Correlation Analysis », ou « CCA ». Le but de l'analyse des corrélations canoniques est de comparer des groupes de variables deux à deux afin de déterminer s'ils décrivent un même phénomène. L'algorithme est ainsi appliqué aux valeurs des indicateurs collectés d'une part à l'ensemble des fonctions réseau virtualisées VNFDepA et 20 d'autre part à l'ensemble des fonctions réseau virtualisées correspondantes VNFDepB du réseau virtuel de test VN2, plus précisément à une fonction réseau virtualisée de l'ensemble VNFDepA et à son clone dans le réseau virtuel de test VNB. L'analyse est ainsi adaptée pour révéler des comportements différents, en ce qui concerne les performances, entre une fonction réseau virtualisée de l'ensemble VNFDepA du réseau virtuel de production VNA et son clone dans le 25 réseau virtuel de test VNB. Dans une étape optionnelle E8 d'alerte, une alerte est remontée au client lorsque le comportement d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées VNFDepA diffère du comportement de son clone dans le réseau virtuel de test VNB en ce qui concerne les performances mesurées par les indicateurs de performance Une telle alerte, 30 représentative d'un correctif non satisfaisant conduit le client, ou une entité en charge du test du correctif à lancer une analyse plus poussée afin de comprendre l'origine de cette alerte et d'y remédier. L'analyse peut être manuelle. L'invention a été décrite dans le cas d'un contrôle indirect des réseaux virtuels par les clients, c'est-à-dire dans un cas où des tunnels sont établis et gérés par l'hyperviseur réseau pour 35 acheminer des paquets entre différentes fonctions réseau virtualisées hébergées par des serveurs 16 hôtes différents. L'invention s'applique également au cas où le client exerce un contrôle dit direct de son réseau virtuel de production VNA. Dans le cas d'un contrôle direct du client sur son réseau virtuel, l'hyperviseur permet au client d'installer des règles dans les équipements réseau d'acheminement afin que celui-ci ait un 5 contrôle de bout en bout sur son réseau. Le client a ainsi l'impression de contrôler directement le réseau physique sous-jacent. Les paquets qui circulent à cet effet entre le contrôleur réseau du client et l'infrastructure matérielle sont interceptés de manière transparente par l'hyperviseur réseau qui modifie des paquets de contrôle afin d'assurer l'isolation entre réseaux virtuels. Ainsi, il est habituel que l'hyperviseur attribue et gère un identifiant de réseau virtuel, propre au 10 réseau virtuel du client mais non connu de ce dernier. Lorsque le client installe une règle sur un équipement réseau d'acheminement, par exemple une règle de copie de paquets entre deux fonctions réseau virtualisées de son réseau virtuel, il est habituel que l'hyperviseur réseau intercepte la règle et ajoute un identifiant du réseau virtuel du client avant que la règle ne soit installée sur l'équipement réseau d'acheminement afin que la règle s'applique uniquement aux 15 paquets du réseau virtuel du client. Afin de mettre en oeuvre les étapes du procédé d'application du correctif tel que décrit précédemment dans le cas d'un contrôle direct du réseau virtuel par le client, l'hyperviseur réseau doit permettre l'installation de règles dans les équipements réseau d'acheminement de manière à ce qu'il soit possible de changer l'identifiant du réseau virtuel des paquets acheminés 20 En effet, selon les étapes du procédé un paquet, en l'espèce un paquet dupliqué, peut passer du réseau de production VNA au réseau de test VNB. Ce changement ne doit être autorisé par l'hyperviseur réseau que si le réseau de test VNB est dédié aux tests et que si le réseau de production VNA, dans lequel circulent les paquets destinés à être acheminés dans le réseau de test, et le réseau de test VNB appartiennent au même client. Dans un exemple de réalisation, 25 l'hyperviseur réseau laisse l'identifiant du réseau virtuel dans des réponses provenant des équipements réseau d'acheminement, afin que l'opérateur de réseau ait connaissance de cet identifiant et commande, pour les paquets comprenant cet identifiant, un acheminement vers le réseau virtuel de test. En effet, dans le cas d'un hyperviseur classique, c'est-à-dire non modifié à des fins de mise en oeuvre des étapes du procédé, il est habituel que l'hyperviseur retire cette 30 information des réponses reçues des équipements réseau d'acheminement à des fins d'isolation réseau. Dans une variante de réalisation, et afin de ne pas révéler au client ces identifiants, l'hyperviseur traduit ces identifiants en pseudo-identifiants. Seul l'hyperviseur sait à quel identifiant de réseau virtuel correspond un pseudo-identifiant de réseau virtuel. Cette solution garantit une certaine sécurité à l'hyperviseur qui ne divulgue pas ces identifiants qualifiés de 35 sensibles. 17 L'exemple de réalisation décrit précédemment s'applique particulièrement bien à des services qui reposent sur un protocole de transport qui n'est pas orienté connexion, tel que le protocole UDP (de l'anglais « User Datagram Protocol). Avec un tel protocole, deux entités communiquent de façon simple : un paquet est transmis d'un émetteur vers un destinataire, de 5 façon unidirectionnelle, sans que le destinataire ne soit préalablement averti de la réception d'un paquet et sans que celui-ci n'accuse réception du paquet vers l'émetteur. Dans le cas d'un protocole orienté connexion, tel que le protocole de transport TCP (pour « Transmission Control Protocol »), une session doit être établie entre deux entités qui veulent échanger des données. Ainsi, dans une demande d'établissement de connexion 10 préalablement à un échange de données, une première entité, appelée « client », envoie à une deuxième entité, appelée « serveur », un paquet de synchronisation de type « SYN ». Le serveur envoie un acquittement sous forme d'un paquet « SYN-ACK ». Le client envoie alors un accusé de réception, sous forme d'un paquet « ACK » correspondant à un message d'acceptation. Au terme de ces échanges, le client et le serveur ont établi une session et sont prêts à communiquer. 15 L'échange de messages entre le client et le serveur lors de l'établissement d'une session utilise un numéro de séquence généré à partir d'une valeur secrète qui peut dépendre d'une source aléatoire matérielle. La valeur secrète peut également être dérivée de la date exacte d'arrivée du paquet, auquel cas si une fonction réseau virtualisée de l'ensemble des fonctions réseau virtualisée dépendantes dans le réseau virtuel opérationnel reçoit un paquet un instant avant la 20 fonction réseau virtualisée correspondante dans le réseau virtuel de test VNB alors les deux fonctions réseau virtualisées n'ont pas la même valeur secrète. Ainsi, une session établie avec une fonction réseau virtualisée du réseau virtuel de production VNA, dans le cadre de l'exécution d'un service, n' est pas établie de façon complètement similaire avec la fonction réseau virtualisée correspondante dans le réseau virtuel de test VNB, du fait de cette composante 25 aléatoire qui peut être différente. Dans ce cas, la fonction réseau virtualisée du réseau de production VNA et son clone dans le réseau de test VNB ne répondent pas avec le même numéro de séquence lors de l'établissement de cette connexion. La copie d'un paquet destiné à la fonction réseau virtualisée du premier réseau VNA et son acheminement vers son clone dans le deuxième réseau ne permet donc pas d'établir la connexion avec le clone car le numéro de 30 séquence généré au niveau du clone est incohérent avec le numéro de séquence utilisé par la fonction réseau virtualisée dans le premier réseau VNA et donc avec la réponse attendue. Dans cet exemple, correspondant à l'utilisation de protocoles de communication orientés connexion, il est nécessaire d'introduire une fonction réseau virtualisée de gestion des connexions, destinée à mémoriser l'état des connexions entre une fonction réseau virtualisée 35 dans le réseau de production VNA et son clone dans le réseau de test VNB afin de mettre en 18 oeuvre une copie efficace des paquets. La fonction réseau virtualisée de gestion des connexions notée VNFGc est comprise de préférence dans le réseau de test VNB. Elle intercepte tout paquet destiné à une fonction réseau virtualisée dépendante du réseau de production VNA et qui est dupliqué par l'hyperviseur réseau puis acheminé vers le clone de la fonction réseau virtualisée 5 dans le réseau de test VNB. Elle intercepte également tout paquet réponse du clone de la fonction réseau virtualisée dans le réseau de test VNB afin d'associer un identifiant de session en cours d'établissement dans le réseau de production VNA à un numéro de séquence utilisé lors de l'établissement de la session dans le réseau de test VNB. La fonction réseau virtualisée de gestion des connexions VNFGc est agencée pour identifier le protocole de communication utilisé 10 dans l'échange courant de paquet et pour appliquer une gestion spécifique des connexions lorsque le protocole est orienté connexion. Elle est agencée également pour laisser passer tout autre paquet sans modification dans les autres cas. Les étapes d'un procédé de gestion de connexions par la fonction réseau de virtualisation de gestion des connexions, selon un exemple de réalisation, vont maintenant être 15 décrites en relation avec la figure 4. Lors d'une demande de connexion destinée à une fonction réseau virtualisée dépendante du réseau de production VNA, par exemple VNFA, un client, par exemple une autre fonction réseau virtualisée du réseau de production VNA, émet dans une étape E40 un paquet de synchronisation afin d'initier l'établissement d'une connexion avec la fonction réseau virtualisée VNFA dans le réseau de production VNA. Comme décrit 20 précédemment, dans le cadre du procédé d'application d'un correctif, le paquet est dupliqué par un équipement réseau d'acheminement (non représenté sur la figure 4) et destiné à être transmis à la fonction réseau virtualisée correspondante, c'est-à-dire le clone de la fonction VNFA dans le réseau de test VNB, notée VNFA'. La fonction réseau virtualisée de gestion des connexions YNFGc intercepte ce message. Dans une étape E41 d'analyse, la fonction réseau virtualisée de 25 gestion des connexions YNFGc identifie qu'il s'agit d'un paquet de demande d'établissement d'une connexion d'un protocole orienté connexion et qu'il est nécessaire d'appliquer un traitement particulier. A cette fin, la fonction réseau virtualisée de gestion des connexions YNFGc analyse l'entête du paquet. Elle mémorise un identifiant Id,'' de la connexion TCP courante sous forme d'un 4-uple comprenant : une adresse IP source de la connexion, 30 correspondant à l'adresse IP du client, une adresse IP destination de la connexion, un port source et un port destination. En fin d'étape E41 d'analyse, la fonction réseau virtualisée de gestion des connexions YNFGc achemine le paquet de demande d'établissement de connexion au clone VNFA' de la fonction réseau virtualisée VNFA dans le réseau de test VNB. Dans une première étape de réponse E42, la fonction réseau virtualisée VNFA répond à 35 la demande d'établissement de connexion en envoyant un premier accusé de réception dans un 19 paquet TCP SYN ACK comprenant un premier numéro de séquence y 1 , généré à partir d'une source aléatoire. Dans une deuxième étape E43 de réponse, le clone VNFA' de la fonction réseau virtualisée envoie en réponse un deuxième accusé de réception dans un paquet TCP SYN ACK 5 comprenant un deuxième numéro de séquence y2 généré à partir d'une source aléatoire qui peut être différente de la source utilisée pour générer le premier numéro de séquence y1. Dans une étape E44 de mémorisation, la fonction réseau virtualisée de gestion des connexions YNFGc mémorise le deuxième numéro de séquence y2 en association avec l'identifiant de connexion Id,'' obtenu au cours de l'étape E41. 10 Dans une troisième étape E45 de réponse, le client CL envoie à la fonction réseau virtualisée VNFA un accusé de réception sous forme d'un paquet TCP ACK comprenant un numéro d'acquittement correspondant au premier numéro de séquence y 1 incrémenté de 1. Comme décrit précédemment, le paquet est dupliqué et destiné à être transmis au clone VNFA' de la fonction réseau virtualisée dans le réseau de test VNB. La fonction réseau virtualisée de 15 gestion des connexions YNFGc intercepte ce paquet et dans une étape E46 de recherche et de remplacement, elle identifie, à partir du 4-uple compris dans le paquet, la connexion Id,,,,, concernée et identifie le numéro de séquence y2 mémorisé en association avec l'identifiant de connexion TCP Id,'' au cours de l'étape E44. Elle remplace le numéro d'acquittement y1+1 par un deuxième numéro d'acquittement égal au deuxième numéro de séquence y2 incrémenté de 1, 20 soit y2+1. Ainsi, l'établissement d'une connexion TCP dans le réseau de production VNA qui implique une fonction réseau virtualisée de l'ensemble de fonctions dépendantes VNFDepA est mis en oeuvre de façon cohérente par rapport au procédé d'application du correctif dans le réseau de test VNB. A cet effet, les numéros de séquence et d'acquittement sont gérés par la fonction réseau virtualisée de gestion des connexions YNFGc par laquelle transite tout paquet 25 qui est dupliqué et acheminé vers un clone d'une fonction réseau virtualisée du réseau de production impliquée dans le procédé d'application du correctif. Un serveur apte à mettre en oeuvre les étapes du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, selon un exemple de réalisation, va maintenant 30 être décrit en relation avec la figure 5. Un serveur 50 apte à mettre en oeuvre les étapes du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que décrit précédemment est un équipement informatique qui de manière classique comprend : - une unité de traitement 51, ou CPU (de l'anglais « Central Processing Unit »), 35 agencée pour exécuter des instructions de code, 20 - un ensemble de mémoires, dont une mémoire volatile 52 de type RAM (de l'anglais « Random Access Memory »), utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 53 de type mémoire flash ou EEPROM (de l'anglais « Electronically Erasable Programmable Read Only 5 Memory »). La mémoire de stockage 53 est agencée pour mémoriser des données et des applications. En particulier, la mémoire de stockage 53 mémorise un module logiciel d'application d'un correctif sur une fonction réseau virtualisée défaillante d'un premier réseau virtuel VNA (le premier réseau virtuel n'est pas représenté sur la figure 5) agencé pour mettre en oeuvre les étapes du procédé d'application d'un 10 correctif sur une fonction réseau virtualisée à mettre à jour décrit précédemment qui sont mises en oeuvre par l'hyperviseur réseau hébergé par le serveur 50. Le serveur 50 est agencé pour héberger un hyperviseur réseau 54 adapté pour s'interfacer entre un premier réseau virtuel VNA et un ensemble d'au moins une ressource matérielle apte à fournir des ressources nécessaires audit premier réseau virtuel. Ledit 15 hyperviseur réseau 50 est un module logiciel comprenant les modules suivants, hébergés par le serveur 50 : - un module d'identification 55, agencé pour identifier un ensemble de fonctions réseau virtualisées dépendantes comprises dans le premier réseau virtuel, ledit ensemble comprenant au moins la fonction réseau virtualisée à mettre à jour. Le module d'identification 55 est agencé 20 pour mettre en oeuvre l'étape El du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que décrit précédemment ; - un module de création 56, agencé pour créer un second réseau virtuel VNB, dit « réseau virtuel de test », ledit réseau virtuel de test comprenant des clones de machines virtuelles mettant en oeuvre les fonctions réseau virtualisées dépendantes de l'ensemble, lesdites 25 machines virtuelles clonées formant des clones des fonctions réseau virtualisées dépendantes de l'ensemble. Le module de création 56 est agencé pour mettre en oeuvre l'étape E2 du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que décrit précédemment ; - un module d'interconnexion 57, agencé pour interconnecter dans le réseau virtuel de 30 test des clones des fonctions réseau virtualisées dépendantes de l'ensemble, l'interconnexion des clones des fonctions réseau virtualisées dépendantes de l'ensemble étant identique à une interconnexion dans le premier réseau des fonctions réseau virtualisées dépendantes de l'ensemble. Le module d'interconnexion 57 est agencé pour mettre en oeuvre l'étape E3 du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que 35 décrit précédemment ; 21 - un module 58 d'identification, de duplication et d'acheminement, agencé pour identifier au moins un paquet de données en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, pour dupliquer ledit paquet et pour acheminer ledit paquet dupliqué vers le réseau virtuel de test. A noter que le paquet provient 5 d'une fonction réseau virtualisée qui ne fait pas partie de l'ensemble des fonctions réseau virtualisées dépendantes, c' est un paquet qui arrive en entrée des éléments comprenant les fonctions réseau virtualisées dépendantes qui constitue le sous-réseau à tester. Le module 58 d'identification, de duplication et d'acheminement est agencé pour mettre en oeuvre l'étape E4 du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel 10 que décrit précédemment ; - un module d'application 59, agencé pour appliquer un correctif au clone de la fonction réseau virtualisée à mettre à jour dans le réseau de test. Le module 59 d'application est agencé pour mettre en oeuvre l'étape E5 du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que décrit précédemment ; 15 - un module 60 de collecte et de comparaison, agencé pour collecter et comparer des valeurs d'au moins un premier et un deuxième indicateur de performance, un premier indicateur mesurant une valeur de performance sur une fonction réseau virtualisée supervisée de l'ensemble de fonctions réseau virtualisées dépendantes du premier réseau virtuel et un deuxième indicateur mesurant la valeur de performance sur le clone de la fonction réseau 20 virtualisée supervisée dans le réseau virtuel de test, une alerte étant déclenchée lorsque les valeurs des premier et deuxième indicateurs different. Le module 60 de collecte et de comparaison est agencé pour mettre en oeuvre les étapes E6 et E7 et l'étape optionnelle E8 du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que décrit précédemment. 25 L'hyperviseur réseau 54, le module d'identification 55, le module de création 56, le module d'interconnexion 57, le module 58 d'identification, de duplication et d'acheminement, le module d'application 59 et le module 60 de collecte et de comparaison sont de préférence des modules logiciels comprenant des instructions logicielles pour mettre en oeuvre les étapes du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour, tel que 30 décrit précédemment, qui sont exécutées par l'hyperviseur réseau 54 hébergé par le serveur 50. L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé d'application d'un correctif sur une fonction réseau virtualisée à mettre à jour tel que décrit précédemment lorsque ce programme est exécuté par un processeur du serveur, et 22 - un support d'enregistrement lisible sur lequel est enregistré le programme d'ordinateur REVENDICATIONS1. Procédé d'application d'un correctif à une fonction réseau virtualisée à mettre à jour (VNFA) comprise dans un premier réseau virtuel (VNA), un hyperviseur réseau s'interfaçant entre le premier réseau virtuel et un ensemble d'au moins une ressource matérielle apte à fournir des ressources nécessaires audit premier réseau virtuel, ledit procédé, mis en oeuvre par l'hyperviseur réseau, comprenant : - identification (El) d'un ensemble de fonctions réseau virtualisées dépendantes comprises dans le premier réseau virtuel, ledit ensemble comprenant au moins la fonction réseau virtualisée à mettre à jour, - création (E2) d'un second réseau virtuel (VNB), dit « réseau virtuel de test », ledit réseau virtuel de test comprenant des clones de machines virtuelles mettant en oeuvre les fonctions réseau virtualisées dépendantes de l'ensemble, lesdites machines virtuelles clonées formant des clones des fonctions réseau virtualisées dépendantes de l'ensemble, - interconnexion (E3) dans le réseau virtuel de test des clones des fonctions réseau virtualisées dépendantes de l'ensemble, ladite interconnexion étant identique à une interconnexion dans le premier réseau des fonctions réseau virtualisées dépendantes de l' ensemble, - identification (E4) d'au moins un paquet de données en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, duplication dudit paquet et acheminement dudit paquet dupliqué vers le réseau virtuel de test, - application (E5) d'un correctif au clone de la fonction réseau virtualisée à mettre à jour dans le réseau de test, - collecte et comparaison (E6, E7) de valeurs d'au moins un premier et un deuxième indicateur de performance, un premier indicateur mesurant une valeur de performance sur une fonction réseau virtualisée supervisée de l'ensemble de fonctions réseau virtualisées dépendantes du premier réseau virtuel et un deuxième indicateur mesurant la valeur de performance sur le clone de la fonction réseau virtualisée supervisée dans le réseau virtuel de test, une alerte étant déclenchée lorsque les valeurs des premier et deuxième indicateurs diffèrent. 2. Procédé selon la revendication 1, dans lequel l'ensemble de fonctions réseau virtualisées dépendantes comprend également au moins une autre fonction réseau virtualisée fonctionnellement dépendante de la fonction réseau virtualisée à mettre à jour. 24 3. Procédé selon la revendication 1 ou la revendication 2, dans lequel un gestionnaire d'infrastructure virtuelle mettant à disposition d'un client auquel a été alloué le premier réseau virtuel, une interface de l'hyperviseur réseau afin que le client contrôle le premier réseau virtuel, ledit client exerçant ainsi un contrôle dit indirect du premier réseau virtuel, l'identification d'un 5 paquet en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, la duplication et l'acheminement dudit paquet dupliqué vers le réseau de test comprend, lorsque la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes et le clone de la fonction réseau virtualisée correspondante comprise dans le second réseau sont hébergées par un même serveur hôte (hl) : 10 l'installation d'une règle de configuration sur un équipement réseau d'acheminement du serveur hôte, ledit équipement réseau d'acheminement étant adapté pour transmettre le paquet à la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, ladite règle de configuration comprenant une duplication du paquet en entrée de la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, et un envoi dudit paquet 15 dupliqué au clone de la fonction réseau virtualisée correspondante comprise dans le second réseau et hébergée par le serveur hôte. 4. Procédé selon la revendication 1 ou la revendication 2, dans lequel un gestionnaire d'infrastructure virtuelle mettant à disposition d'un client auquel a été alloué le premier réseau 20 virtuel, une interface de l'hyperviseur réseau afin que le client contrôle le premier réseau virtuel, ledit client exerçant ainsi un contrôle dit indirect du premier réseau virtuel, l'identification d'un paquet en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, la duplication et l'acheminement dudit paquet dupliqué vers la fonction réseau virtualisée correspondante dans le réseau de test comprend, lorsque la fonction réseau 25 virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes est hébergée par un premier serveur hôte (hl) et que le clone de la fonction réseau virtualisée correspondante comprise dans le second réseau est hébergée par un deuxième serveur hôte (h2) : l'installation d'une première règle de configuration sur un premier équipement réseau d'acheminement (si) du premier serveur hôte, ledit premier équipement réseau d'acheminement 30 étant adapté pour transmettre le paquet à la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, ladite règle de configuration comprenant une duplication du paquet en entrée de la fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes, et un envoi dudit paquet dupliqué vers le deuxième serveur, une deuxième règle de configuration étant installée sur un deuxième équipement réseau 35 d'acheminement (s2) compris dans le deuxième serveur hôte, la deuxième règle de 25 configuration comprenant l'envoi dudit paquet au clone de la fonction réseau virtualisée correspondante comprise dans le second réseau et hébergée par le deuxième serveur hôte. 5. Procédé selon la revendication 1 ou la revendication 2, dans lequel l'hyperviseur 5 réseau reçoit d'un opérateur du premier réseau virtuel une règle destinée à être installée dans un équipement réseau d'acheminement, ladite règle modifiant un identifiant du premier réseau virtuel compris dans un paquet destiné à être acheminé vers le réseau virtuel de test, en un identifiant du réseau virtuel de test, ladite règle étant installée sur l'équipement par l'hyperviseur lorsque le réseau virtuel de test est dédié aux tests de fonctions réseau virtualisées 10 et que le premier réseau virtuel et le réseau virtuel de test appartiennent à un même client. 6. Procédé selon l'une des revendications précédentes, dans lequel un protocole de communication orienté connexion étant utilisé pour communiquer avec une fonction réseau virtualisée dépendante de l'ensemble, l'étape d'identification, de duplication et d' acheminement 15 d'un paquet vers le réseau de test comprend, dans une phase d'établissement d'une connexion : - réception (E41) d'un paquet de synchronisation, ledit paquet ayant été reçu par la fonction réseau virtualisée dépendante, dupliqué et destiné à être acheminé vers la fonction réseau virtualisée correspondante dans le réseau de test, ledit paquet comprenant un identifiant de connexion (Idcnx), et acheminement dudit paquet de synchronisation à la fonction réseau 20 virtualisée correspondante dans le réseau de test, - réception (E44) en provenance de la fonction réseau virtualisée correspondante d'un premier paquet d' acquittement comprenant un premier numéro de séquence (y2), et association du premier numéro de séquence (y2) compris dans ledit paquet d'acquittement à l'identifiant de connexion (Idcilx), et acheminement dudit premier paquet d'acquittement, 25 - réception (E46) d'un deuxième paquet d'acquittement, ledit deuxième paquet d' acquittement ayant été préalablement reçu par la fonction réseau virtualisée dépendante, dupliqué et destiné à être acheminé vers la fonction réseau virtualisée correspondante dans le réseau de test, ledit paquet comprenant l'identifiant de connexion (Idcilx) et un premier numéro d' acquittement (y1+1) calculé en incrémentant un deuxième numéro de séquence généré et 30 transmis préalablement par la fonction réseau virtualisée dépendante, et remplacement dans le deuxième paquet d'acquittement dudit premier numéro d'acquittement (y1+1) par un deuxième numéro d'acquittement calculé en incrémentant le premier numéro de séquence (y2+1), et acheminement dudit deuxième paquet d'acquittement à la fonction réseau virtualisée correspondante dans le réseau de test. 35 26 7. Serveur (50) comprenant un hyperviseur réseau s'interfaçant entre un premier réseau virtuel et un ensemble d' au moins une ressource matérielle apte à fournir des ressources nécessaires audit premier réseau virtuel, ledit hyperviseur étant adapté pour appliquer un correctif à une fonction réseau virtualisée à mettre à jour (VNFA) comprise dans le premier 5 réseau virtuel (VNA), ledit serveur comprenant : - des premiers moyens d'identification, agencés pour identifier un ensemble de fonctions réseau virtualisées dépendantes comprises dans le premier réseau virtuel, ledit ensemble comprenant au moins la fonction réseau virtualisée à mettre à jour, - des moyens de création, agencés pour créer un second réseau virtuel (VNB), dit 10 « réseau virtuel de test », ledit réseau virtuel de test comprenant des clones de machines virtuelles mettant en oeuvre les fonctions réseau virtualisées dépendantes de l'ensemble, lesdites machines virtuelles clonées formant des clones des fonctions réseau virtualisées dépendantes de l' ensemble, - des moyens d'interconnexion, agencés pour interconnecter dans le réseau virtuel de 15 test des clones des fonctions réseau virtualisées dépendantes de l'ensemble, l'interconnexion des clones des fonctions réseau virtualisées dépendantes de l'ensemble étant identique à une interconnexion dans le premier réseau des fonctions réseau virtualisées dépendantes de l' ensemble, - des moyens d'identification, de duplication et d' acheminement, agencés pour 20 identifier au moins un paquet de données en entrée d'une fonction réseau virtualisée de l'ensemble de fonctions réseau virtualisées dépendantes pour dupliquer ledit paquet et pour acheminer ledit paquet dupliqué vers le réseau virtuel de test, - des moyens d' application, agencés pour appliquer un correctif au clone de la fonction réseau virtualisée défaillante dans le réseau de test, 25 - des moyens de collecte et de comparaison, agencés pour collecter et comparer des valeurs d'au moins un premier et un deuxième indicateur de performance, un premier indicateur mesurant une valeur de performance sur une fonction réseau virtualisée supervisée de l'ensemble de fonctions réseau virtualisées dépendantes du premier réseau virtuel et un deuxième indicateur mesurant la valeur de performance sur le clone de la fonction réseau 30 virtualisée supervisée dans le réseau virtuel de test, une alerte étant déclenchée lorsque les valeurs des premier et deuxième indicateurs diffèrent. 8. Programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un serveur informatique, comprenant des instructions de code de programme destinées à 35 commander l'exécution des étapes du procédé d'application d'un correctif à une fonction réseau 27 virtualisée à mettre à jour dans un réseau virtuel, selon l'une des revendications 1 à 6, lorsque le programme est exécuté sur ledit serveur. 5