Brevet FR3094812A1 — publié le 20201009

Description Titre de l'invention : Procédé et dispositif de migration d'une fonction virtualisée en cas de défaillance de l'environnement technique de serveurs 1. Domaine technique 100011 L'invention se situe dans les réseaux de communications, proposant notamment des services mis en oeuvre à partir de fonctions virtualisées au sein de centre de données. L'invention vise plus spécifiquement à améliorer la disponibilité des services de communications mis en oeuvre à partir de fonctions virtualisées ainsi que la robustesse des réseaux de communications en exploitant des données de l'environnement technique. 2. Etat de la technique 100021 Le secteur des télécommunications est au coeur d'une transformation digitale qui s'appuie sur des technologies émergentes telles que la virtualisation des fonctions réseaux (ou VNF - Virtual Network Functions) consistant à découpler les fonctions réseau des équipements physiques qui les supportent pour les déployer dans des serveurs génériques installés dans des centres de données, ou cloud, plus ou moins distribués. Par exemple, les données d'une application utilisée par des clients, qui transitaient et étaient traitées par des équipements physiques tels que des stations BTS (en anglais Base Transceiver Station). des NodcB, des équipements d'accès de type BNG (en anglais Broadband Network Gateway), PGW (en anglais Packct Data Network GatcWay), Routcurs. équipements DPI (en anglais Deep Packct Inspection). Parc-Feu (en anglais Firewall), fonctions applicativcs (en anglais Application Function), transitent et sont traitées par des VNFs déployées dans des serveurs génériques. [0003] Ces fonctions virtualisécs sont déployées sur des serveurs génériques en utilisant par exemple des machines virtuelles pour s'affranchir de matériels dédiés et faciliter le déploiement de nouvelles fonctions virtualisées tout en maîtrisant les coûts. [0004] Les fonctions virtualisées peuvent être déployées sur des serveurs dans des centres de données plus ou moins grands et plus ou moins centralisés. Certaines fonctions virtualisées, traitant des données requérant une faible latence, ont plutôt tendance à être déployées en périphérie du réseau de communications, c'est-à-dire au plus proche des terminaux accédant aux services s'appuyant sur les fonctions virtualisées tandis que des fonctions virtualisées traitant des données moins exigeantes en ternie de latence sont plutôt déployées dans des centres de données centralisés. généralement de taille plus importante. L'initiative MEC (en anglais Mobile Edge Computing) consistant à déployer des fonctions applicativcs d'un réseau de communications en périphérie de réseau, ces fonctions pouvant être virtualisées, est un exemple de déploiement de 2 VNFs à la périphérie d'un réseau de communications. [0005] Le déploiement de fonctions virtualisées dans des centres de données, fussent-ils cen- tralisés ou distribués, requiert des ressources de calcul, de stockage, de mémoire, de réseau et d'énergie. Le bon fonctionnement des fonctions virtualisées nécessite que les ressources de stockage, de calcul, de mémoire, de réseau et d'énergie soient opérationnelles et adaptées aux traitements des fonctions virtualisées. [0006] [fig.1] présente une vue simplifiée d'une architecture de communication selon une technique antérieure. [0007] L'architecture de communication, selon la [fig.1], permet le déploiement des fonctions virtualisées VNF1 61, VNF2 62 et VNF3 63 sur une architecture, ou infrastructure, NFVI 50. Cette infrastructure NEVI 50 peut être mise en oeuvre dans des centres de données (ou cloud) centralisés, c'est-à-dire en coeur de réseau ou bien distribués, plus proches des clients. Cette infrastructure NFVI 50 est composée de serveurs, tels que des machines virtuelles VM 51, VM 52 sur lesquelles sont installées les fonctions virtualisées citées ci-dessus. L'infrastructure NFVI 50 comprend en outre des ressources de calcul, de stockage, ces ressources étant gérées par une couche de virtualisation telle qu'un hyperviscur, ainsi que des ressources réseau non représentées sur [Fig. 1]. L'architecture de communication comprend en outre une entité de gestion des opérations et des services OSS/BSS 20. [0008] La gestion des fonctions virtualisées, et notamment leur installation et le suivi de leur fonctionnement ainsi que leur déplacement le cas échéant est géré par une entité MANO (en anglais Management and Orchestration) 30 qui comprend une entité NFVO 80 d'orchestration gérant les services réseau élaborés à partir des fonctions virtualisées grâce à l'interface II, une entité VNFM (en anglais Virtual Network Function Manager) 70 gérant les différentes fonctions virtualisées VNFI 61, VNF2 62, VNF3 63 grâce à l'interface 12, ainsi qu'une entité VIM (en anglais Virtualized Infrastructure Manager) 40 gérant les ressources de l'infrastructure NFVI 50 grâce à l'interface 13. Selon la technique antérieure, en fonction de besoins de services, des caractéristiques des fonctions virtualisées et des ressources de l'infrastructure en terme de ressources mémoire, de calcul et de capacités réseau, les fonctions virtualisées sont instanciées, déplacées d'une machine virtuelle à une autre ou d'un centre de données à un autre, ou bien encore désinstallées. [0009] Le placement des fonctions virtualisées et leur gestion, en terme de ressources de calcul, de stockage, de mémoire et de réseau sont prises en compte selon les techniques de l'art antérieur, notamment dans le document ETSI GS NFV-IFA 005 V3.1.1 (2018-08) qui décrit les interfaces et les modèles d'information relatifs aux interfaces Or-Vi et Vi-Vntin d'une architecture virtualisée telle que décrite par l'ETSI-NFV-MANO (en anglais Management and Orchestration). L'interface Or-Vi 3 entre une entité de type VIM (en anglais Virtualized Infrastructure Manager) en charge de la gestion des ressources virtualisées et une entité de type NFVO (en anglais Network Function Virtualization Orchestrator) en charge de la gestion des ressources dans la fourniture d'un service. L'interface Or-Vi permet à l'entité NFVO de requérir auprès de l'entité VIM des ressources pour le déploiement de fonctions virtualisées et requérant de gérer ces ressources au sein d'une infrastructure physique de type NFVI (en anglais NFV Infrastructure). L'interface Vi-Vnfm véhicule les données échangées entre une entité de type VIM et une entité de type VNFM (en anglais Virtual iscd Network Function Manager) en charge de la gestion du cycle de vie des fonctions virtualisées (VNF). Elle permet notamment au VNFM de demander à l'entité VIM de déployer une instance de VNF sur les ressources réservées par le NFVO pour la VNF dans l'infrastructure NFVI. Le document ETST GS NFV-IFA 006 V2.4.1 (2018-02) décrit les différentes informations échangées sur l'interface Vi-Vnfm. [0010] En cas de défaillance ou de maintenance de ressources de calcul, de stockage, de mémoire ou de réseau, des mécanismes de résilience permettent aux fonctions virtualisées de migrer les services impactés vers d'autres ressources non impactécs par la défaillance ou la maintenance. Le document ETSI GS NFV-REL 003 V1.1.1 (2016-04) décrit un certain nombre de ces mécanismes de résilience pouvant être mis en oeuvre dans les architectures virtualisées. [0011] Le placement et la gestion des fonctions virtualisées par l'entité VTM peut s'appuyer sur une table de correspondance indiquant les serveurs ou machines virtuelles (telles que VMs) sur lesquels sont déployées les différentes fonctions virtualisées (VNFs). Lorsque l'entité VIM reçoit une demande de déploiement pour une fonction virtualisée, elle y réserve les ressources requises en y choisissant un serveur disposant de suffisamment de ressource de calcul, de stockage, de mémoire et de réseau pour y permettre le déploiement de la fonction virtualisée. Lorsque l'entité VIM reçoit une demande de suppression d'une fonction virtualisée sur un serveur, elle procède à la suppression et met à jour la table de correspondance en conséquence. [0012] Si le placement et la gestion des fonctions virtualisées permettant de mettre en oeuvre un service prennent en compte les ressources de calcul, de mémoire, de stockage et de réseau des serveurs sur lesquels sont déployées des fonctions virtualisées, les ressources fournies par l'environnement technique des centres de données, et utilisées par les serveurs, ne sont pas pris en compte dans les techniques relevant de l'art antérieur. [0013] [fig.2] présente une description temporelle des événements se produisant dans une ar- chitecture de communications selon une technique antérieure. [0014] [fig.2] est relative à un paramètre lié à l'alimentation électrique d'un serveur et présente trois courbes 5A, 5B, 5C. La charge électrique d'un serveur (courbe 5B), ou d'un ensemble de serveurs, dans un fonctionnement nominal évolue entre les valeurs Max et Normal. Lorsque la charge atteint le niveau Normal, l'alimentation électrique est activée pour être rechargée, comme indiqué sur la courbe SA, pour atteindre le niveau Max. L'alimentation électrique peut être fournie par des batteries ou un groupe électrogène, voire par une alimentation électrique de type secteur. Si un problème survient dans le paramètre d'alimentation électrique, la charge électrique baisse en dessous du niveau Normal; mais cette fois-ci, la charge de l'alimentation électrique n'est pas activée, en raison du problème, pour être augmentée et celle-ci continue de baisser jusqu'à atteindre un niveau Min. Dans cc cas, le paramètre électrique (Etat Courbe 5C) passe du mode OK au mode NOK à l'instant Tl et le serveur dont le paramètre électrique est défaillant n'est plus disponible suite à cc changement d'état. Les fonctions virtualisées installées sur le serveur dont le paramètre est représenté sur la courbe 5C ne sont alors plus disponibles non plus. Au temps T2, la charge reprend (courbe 5A) et lorsque la charge atteint un niveau suffisant pour rendre opérationnel le serveur, au temps T3, l'état du paramètre électrique de l'environnement technique passe du mode NOK au mode OK et le serveur redevient disponible, ainsi que les fonctions virtualisées installées sur le serveur. Lc temps d'indisponibilité du serveur et des fonctions virtualisécs, selon la technique antérieure, correspond au délai (T3 - Tl) alors que le délai de rétablissement du défaut d'alimentation électrique, correspondant à unc reprise de la charge de l'alimentation électrique du serveur correspond au délai (T2 - Tl). Le problème d'alimentation électrique peut donc causer une indisponibilité des fonctions virtualisécs et donc des services utilisant ces fonctions virtualisées pendant une durée assez longue, ici représentée par le délai (T3 - Tl). Lorsqu'un événement sur un paramètre technique, tel que l'alimentation électrique d'un serveur, le niveau d'eau dans un centre de données, unc détection d'intrusion dans le centre de données, ou un réchauffement anormal d'un serveur, les fonctions virtualisées, selon la technique antérieure, présentes sur le serveurs peuvent être impactécs et les services s'appuyant sur ces fonctions virtualisées dégradés. Ainsi, les interfaces spécifiées dans les architectures virtualisées prévoient effectivement de pouvoir déployer et gérer des fonctions virtualisées en vue de mettre en oeuvre un service mais ces interfaces n'intègrent pas d'informations relatives aux ressources relatives à l'environnement technique (telles que l'alimentation électrique, la climatisation, l'inondation, l'intrusion, la fuite de gaz) dont dépendent les serveurs, les fonctions virtualisées et consécutivement les services et applications s'appuyant sur les fonctions virtualisées. [0015] La présente invention a pour objet d'apporter des améliorations par rapport à l'état de la technique. 3. Exposé de l'invention [0016] L'invention vient améliorer la situation à l'aide d'un procédé de migration d'une fonction virtualisée installée sur un premier serveur dans un centre de données d'une architecture de communication, mis en oeuvre dans une entité d'administration dudit premier serveur, ladite entité étant apte à émettre à destination d'une entité de gestion de la fonction virtualisée des données relatives à l'installation de la fonction virtualisée, le procédé comprenant au moins une réception d'un message de notification comprenant au moins une donnée d'un paramètre d'environnement technique relatif au premier serveur, la détermination d'une action de sauvegarde de la fonction virtualisée si l'au moins une donnée franchit un seuil prédéfini et l'émission à destination de l'entité de gestion d'un message de migration de la fonction virtualisée vers un deuxième serveur. [0017] Le procédé de migration permet de pouvoir assurer qu'une fonction virtualisée puisse rester opérationnelle en cas d'un événement lié à l'environnement technique du serveur. Un serveur installé dans un centre de données peut en effet subir des dommages ou des dysfonctionnements en raison d'incidents sur l'alimentation électrique du serveur et/ou du centre de données, sur le refroidissement du serveur, sur un dégât dû par exemple à une inondation, sur une intrusion dans un centre de données et le procédé permet de prendre en compte ces paramètres en plus des paramètres relevant de l'art antérieur (ressources de stockage, ressources de calcul, ressources de mémoire et ressources réseau du serveur) pour installer ou déplacer une fonction virtualisée. La donnée d'un paramètre d'environnement technique peut ainsi être une puissance électrique, un état d'indisponibilité, une hauteur d'eau, ou un déclenchement d'un capteur en cas d'intrusion. Le procédé de migration permet ainsi de maintenir une fonction virtualisée en état de marche et donc de garantir que le service basé sur la fonction virtualisée reste disponible. En outre, dans le cas où une interruption de la fonction virtualisée, et consécutivement peut être également le(s) service(s) utilisant la fonction virtualisée, est requise alors ce temps d'interruption est réduit en migrant la fonction virtualisée avant que le serveur ne soit complètement hors service, par la définition d'un seuil adapté. Le procédé permet en outre de limiter l'impact d'un problème issu de l'environnement technique sur une centre de données en limitant les besoins en ressources relatives à l'énergie des serveurs grâce à la migration des fonctions virtualisées installées sur ces serveurs. [0018] Selon un aspect de l'invention, dans le procédé de migration, l'au moins une donnée d'un paramètre de l'environnement technique est relative à l'alimentation électrique du serveur. [0019] Dans le cas notamment où le centre de données ne bénéficie pas d'une alimentation continue ou si l'alimentation continue du serveur est défaillante et secourue par des batteries, le procédé peut avantageusement être mis en oeuvre pour notifier régulièrement à l'entité d'administration la puissance électrique pouvant être fournie au 6 serveur par le dispositif d'alimentation électrique et dans le cas où cette puissance électrique passe au-dessous d'un seuil prédéfini équivalent à la puissance minimale requise par le serveur, l'entité d'administration peut décider automatiquement de déplacer les fonctions virtualisées se trouvant sur le serveur. La donnée transmise peut également être un état d'indisponibilité d'un serveur. [0020] Selon un autre aspect de l'invention, dans le procédé de migration, l'au moins une donnée d'un paramètre technique d'environnement est relative au refroidissement du serveur. [0021] Le refroidissement des serveurs dans des centres de données est une des priorités majeures pour assurer un fonctionnement optimal des serveurs. La prise en compte du paramètre de capacité d'extraction des calories par des messages de notification permet de s'assurer que le refroidissement est assuré et que les serveurs hébergeant des fonctions virtualisécs ne vont pas défaillir. Dans le cas où la capacité d'extraction de calories descend au-dessous d'un seuil prédéfini équivalent à la dissipation thermique minimale du serveur, il convient de migrer les fonctions virtualisécs sur un autre serveur. C'est également le cas où la donnée correspond à un état de panne du système de climatisation. [0022] Selon un autre aspect de l'invention, dans le procédé de migration, l'au moins une donnée d'un paramètre technique d'environnement est relative à un niveau d'eau dans la pièce où se trouve le serveur. [0023] Les centres de données peuvent subir des avaries telles que des intrusions d'eau. El est donc nécessaire de vérifier que les pompes d'évacuation fonctionnent suffisamment bien pour empêcher l'élévation du niveau d'eau pouvant endommager un serveur. L'information sur le niveau d'eau par rapport à la position d'un serveur permet de pouvoir prévenir une indisponibilité de fonctions virtualisées installées sur le serveur en les migrant préventivement avant que le niveau d'eau soit dommageable pour le serveur. [0024] Selon un autre aspect de l'invention, dans le procédé de migration, la détermination d'une action de sauvegarde comprend le déclenchement d'une échéance de migration. [0025] En fonction des paramètres de l'environnement technique reçus et de l'évolution de ces paramètres, l'entité d'administration peut estimer une durée pendant laquelle un serveur continue d'être opérationnel avant de défaillir. Cette durée peut par exemple être calculée à partir des données de paramètres reçus, du seuil prédéfini et de caractéristiques intrinsèques de fonctionnement d'un serveur. Cette durée peut être exploitée pour mettre en oeuvre une migration d'urgence ou plus étalée dans le temps de fonctions virtualisées. [0026] Selon un autre aspect de l'invention, dans le procédé de migration, le message de migration comprend une durée de migration à respecter. 7 [0027] Le message de migration envoyé à l'entité de gestion peut avantageusement comprendre une durée permettant à l'entité d'estimer la criticité de la migration et de mettre en oeuvre la migration des fonctions virtualisées de façon urgente ou bien avec un délai plus long. Cette durée de migration permet à l'entité de gestion de pouvoir programmer ses travaux de migration pour les fonctions virtualisécs. La durée de migration peut également dépendre des caractéristiques de la fonction virtualiséc, notamment pour s'assurer qu'une fonction virtualisée importante pour la délivrance d'un service soit migrée en priorité. [0028] Selon un autre aspect de l'invention, dans le procédé de migration, le message de migration comprend une information d'identification relative à la fonction virtualisée. [0029] Un même serveur peut accueillir plusieurs fonctions virtualisécs distinctes. Certaines de ces fonctions peuvent être nécessaires pour la mise en oeuvre d'un service et d'autres optionnelles. L'envoi à l'entité de gestion d'un message de migration comprenant une information d'identification relative à la fonction virtualisée autorise l'entité de gestion à migrer les fonctions dont une information d'identification est transmise, réduisant ainsi le nombre de migrations à effectuer ou à prioriscr, ce qui peut être important en cas de crise ou d'événement important, ou bien encore si les serveurs d'accueils sont en nombre limité. [0030] Selon un autre aspect de l'invention, le procédé de migration comprend en outre la réception en provenance de l'entité de gestion d'un message d'information comprenant un identifiant du deuxième serveur sur lequel la fonction virtualisée a été migrée. [0031] L'entité d'administration doit s'assurer d'être notifiée des paramètres d'environnement technique des serveurs sur lesquels des fonctions virtualisées sont installées. A cet effet, l'entité d'administration peut maintenir une table de correspondance indiquant les serveurs sur lesquels sont installées les différentes fonctions virtualisées. Lorsqu'une modification intervient dans la table, par exemple suite au procédé de migration, l'entité d'administration doit notifier à l'entité lui envoyant les messages de notification qu'elle souhaite recevoir les paramètres d'environnement technique du deuxième serveur. [0032] Selon un autre aspect de l'invention, dans le procédé de migration, le deuxième serveur est sélectionné en fonction de sa localisation dans l'architecture de communication. [0033] Les paramètres d'environnement technique peuvent impacter plusieurs serveurs en parallèle, notamment si un événement impacte tous les serveurs d'un centre de données. L'entité d'administration, par exemple en corrélant les différents messages de notification reçus, et/ou les différentes données relatives à des paramètres d'environnement technique peut identifier un problème sur un centre de données et donc sélectionner le deuxième serveur dans un centre de données non impacté par 8 l'événement pour améliorer la résilience du service basé sur les fonctions virtualisécs migrées. [0034] Selon un autre aspect de l'invention, le procédé de migration comprend en outre le retrait du premier serveur d'une liste de serveurs aptes à accueillir une fonction virtualisée suite à la réception du message de notification. [0035] Afin d'éviter que de nouvelles fonctions virtualisécs soient instanciécs sur le serveur impacté par un problème sur un paramètre ou plusieurs paramètres dc l'environnement technique, le serveur est marqué de la table de correspondance comme ne pouvant plus recevoir de nouvelle fonction virtuelle. [0036] Selon un autre aspect de l'invention, le procédé de migration comprend en outre l'extinction du premier serveur suite à l'émission à destination de l'entité de gestion du message de migration. [0037] Le serveur menacé par la pénurie d'alimentation électrique ou par les conditions d'environnement dégradées, étant possiblemcnt déchargé des différentes fonctions virtualisécs qu'il hébergeait, peut être éteint. De la sorte, il ne consomme plus d'énergie électrique, si bien que les autres équipements du centre de données toujours actifs peuvent bénéficier d'énergie électrique de la part de la batterie pour une durée plus importante, dans le cas où le paramètre d'environnement électrique est de type électrique. De même, il ne dissipe plus de chaleur, si bien que les autres équipements du centre de calcul voient leur température augmenter moins rapidement et peuvent bénéficier dc temps supplémentaire avant d'être impactés à leur tour par une température excessive. Enfin, si le circuit électrique alimentant le serveur éteint était celui le plus exposé à la montée de l'eau, il ne génèrera pas de court-circuit pouvant être détecté par l'organe de protection électrique en amont et risquant de couper l'alimentation électrique des autres équipements du centre de données dans lequel il se trouve. [0038] Les différents aspects du procédé de migration qui viennent d'être décrits peuvent être mis en oeuvre indépendamment les uns des autres ou en combinaison les uns avec les autres. [0039] L'invention concerne également un dispositif de migration d'une fonction virtualisée installée sur un premier serveur dans un centre de données d'une architecture de communication, mis en oeuvre dans une entité d'administration dudit premier serveur, ladite entité étant apte à émettre à destination d'une entité de gestion de la fonction virtualisée des données relatives à l'installation de la fonction virtualisée, le dispositif comprenant - un récepteur, apte à recevoir au moins un message de notification comprenant au moins une donnée d'un paramètre d'environnement technique relatif au premier serveur, - un module de détermination apte à déterminer une action de sauvegarde de la 9 fonction virtualisée si l'au moins une donnée franchit un seuil prédéfini - un émetteur, apte à émettre à destination de l'entité de gestion un message de migration de la fonction virtualisée vers un deuxième serveur. Ce dispositif, apte à mettre en oeuvre dans tous ses modes de réalisation le procédé de migration qui vient d'être décrit, est destiné à être mis en oeuvre dans une entité de gestion d'une infrastructure de communications, telle qu'une infrastructure virtualisée. Par exemple, le dispositif peut être mis en oeuvre dans une entité de type VIM. [0040] L'invention concerne aussi un système de migration d'une fonction virtualisée installée sur un premier serveur dans un centre de données d'une architecture de communication comprenant - une entité d'administration du premier serveur comprenant un dispositif de migration, - une entité de gestion de la fonction virtualisée comprenant un récepteur apte à recevoir en provenance de l'entité d'administration un message de migration de la fonction virtualisée vers un deuxième serveur. [0041] L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en oeuvre des étapes du procédé de migration qui vient d'être décrit, lorsque ce programme est exécuté par un processeur et un support d'enregistrement lisible par un dispositif de détermination sur lequel est enregistré le programmes d'ordinateur. [0042] Ce programme peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. [0043] L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions des programmes d'ordinateur tel que mentionnés ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple sur un disque dur. [0044] D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou pal- d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. [0045] Alternativement, le support d'informations peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question. 4. Brève description des dessins 100461 Les rfig.11 et [Fig. 2] présentent respectivement une architecture et une description temporelle des événements relatifs à une technique antérieure, décrites clans la section 2. [0047] D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : présente une vue simplifiée d'une architecture de communication selon un premier aspect de l'invention, présente une description temporelle des étapes du procédé de migration selon un mode de réalisation de l'invention, présente une description temporelle des étapes du procédé de migration selon un autre mode de réalisation de l'invention, présente des étapes de mise en oeuvre de l'invention selon encore un autre mode de réalisation de l'invention, [fig.3] présente un exemple de structure d'un dispositif de migration selon un aspect de r invention. 5. Description des modes de réalisation [0048] Dans la suite de la description, on présente des modes de réalisation de l'invention dans une architecture de communication dans laquelle sont instanciées des fonctions virtualisées. Cette infrastructure peut être mise en oeuvre pour acheminer des données à destination de terminaux fixes ou mobiles et l'invention peut être destinée à migrer des fonctions virtualisées utilisées pour l'acheminement et/ou le traitement de données de clientèle résidentielle ou d'entreprises. [0049] On se réfère à la [fig.3] qui présente une vue simplifiée d'une architecture de com- munication selon un premier aspect de l'invention. Aux entités présentées dans la [Fig. 1], s'ajoutent des nouvelles entités permettant de prendre en compte les contraintes liées à l'environnement technique dans la gestion de l'installation des fonctions virtualisées VNF1 61, VNF2 62 et VNF3 63. [0050] Les données de paramètres de l'environnement technique Env Tech 90 permettent d'assurer un fonctionnement optimal des serveurs (ou machines virtuelles) VM 51 et VM 52 pour que les fonctions virtualisées VNF1 61, VNF2 62 et VNF3 63 fonctionnent elles-mêmes de façon nominale et donc que les services mis en oeuvre à partir de ces fonctions virtualisées VNF1 61, VNF2 62 et VNF3 63 respectent une bonne qualité de service. Les paramètres d'environnement technique sont, par exemple, les paramètres Air 91 liées à la climatisation et à la garantie que la température des serveurs VM 51 et VM 52 soit comprise dans une plage de température donnée, les paramètres électriques Elec 92, les détecteurs Détec 93 permettant de surveiller le niveau d'eau dans des centres de données où sont installés les serveurs VM 51 et VM 52 11 (risque de court-circuit électrique), ou bien encore la concentration de gaz de ville (risque d'explosion) présent dans de tels centres de données, ou bien encore une intrusion dans les locaux (risque de vol de serveur). Cette liste de paramètres n'est pas exhaustive et ces paramètres peuvent être associés à un serveur parmi les serveurs VM1 et VM2 en particulier ou à un ensemble de serveurs. [0051] L'environnement technique Env Tech 90 comprend en outre un contrôleur Contrl 94 permettant de gérer les différents paramètres techniques Air 91, Elec 92 et Dace 93. Les données relatives à ces différents paramètres sont communiquées à une entité d'administration NFVI TE 10 d'un serveur via une interface 14. Cette entité d'administration NFVI TE 10 communique avec l'entité de gestion VIM 40 via l'interface 15. Selon un exemple, l'entité NFVT TE 10 est co-localisée avec l'entité VIM 40. Dans ce cas, l'entité VIM 40 gère l'ensemble des paramètres relatifs aux serveurs de l'infrastructure NFVI 50, y compris les paramètres Air 91, Elec 92 et Détec 93 d'environnement technique. [0052] En relation avec la [fig.4], on présente une description des étapes du procédé de migration selon un mode de réalisation de l'invention. Ce mode de réalisation est mis en oeuvre dans le même contexte que celui décrit pour la [Fig. 2]. Les mêmes types de courbes sont représentés comme sur la [Fig. 2] et sont propres à un ou plusieurs serveurs d'un ou de plusieurs centres de données. Une première différence avec [Fig. 2] consiste à déterminer un nouveau niveau Deg de charge et d'état associé sur les courbes 5B et 5C. Ainsi, lorsqu'un problème survient sur l'alimentation électrique, la charge électrique d'un serveur diminue depuis le niveau Max et le problème électrique conduit à ce que la charge électrique de l'alimentation du serveur ne reprenne pas lorsque le niveau de charge atteint un niveau Normal. Donc la charge continue de diminuer pour atteindre un niveau Deg, pour dégradé, déclencheur d'une action à effectuer. Lorsque la charge atteint ce niveau (Courbe 5B et Courbe 5C), au temps Tl, une action Evac d'évacuation est déclenchée entre Ti et T5. Cette action consiste par exemple, à déplacer une ou plusieurs fonctions virtualisées présente sur le serveur dont l'Etat est fourni clans la courbe 5C, de façon à garantir le bon fonctionnement de ces fonctions virtualisées. [0053] Le serveur est alors dans un état dégradé Deg (Courbe 5C). Selon un exemple, certaines fonctions du serveur sont désactivées et où une partie ou l'ensemble des fonctions virtualisées sur le serveur sont migrées. La charge électrique du serveur (Courbe 5B) continuant à diminuer après le temps T5, une action d'extinction Extinc du serveur est mise en oeuvre entre T5 et T6. Cette action Extinc d'extinction consistant par exemple à couper l'alimentation électrique du serveur conduit à rendre les fonctions virtualisées encore présentes sur le serveur inopérantes et en outre, à réduire la consommation électrique d'un centre de données dans lequel se trouve le 12 serveur considéré (ou l'ensemble des serveurs considérés) et consécutivement à limiter l'impact du problème d'alimentation électrique du centre de données en réduisant la consommation électrique par une baisse de la demande d'alimentation par les serveurs. Selon une alternative, cette opération peut en outre permettre de maintenir en priorité des serveurs dits prioritaires dans le centre de données en réduisant la consommation électrique globale par l'extinction de serveurs non prioritaires. Au temps T4, le serveur devient indisponible. Au temps T2, le problème d'alimentation électrique est résolu (courbe 5A) et le serveur acquiert une charge suffisante pour être opérationnel à l'instant T3, ce qui correspond à un niveau de charge normal Normal (courbe 5B). Le niveau de charge considéré comme suffisant pour accueillir de nouveaux des fonctions virtualisées dépend des fonctions virtualisécs à installer et des niveaux de charge considérés comme suffisants pour la fourniture des services basés sur les fonctions virtualisées installées sur le serveur. [0054] Le niveau Dégradé Deg et les opérations mises en oeuvre sur le serveur aux instants Tl, T5, T6 permet de garantir la disponibilité des fonctions virtualisées sur le ou les serveurs impactés. Elles permettent également de limiter l'impact d'un problème sur un ou plusieurs serveurs en menant des actions d'évacuation et possiblement d'extinction, réduisant ainsi le besoin en alimentation électrique dans le centre de données où est (où sont) installé(s) le(s) serveur(s), et permettant de limiter l'impact du problème et réduisant le temps d'indisponibilité au délai T3 - T4 grâce aux actions opérées de façon préventive par rapport au moment d'indisponibilité totale du serveur (Etat NOK). [0055] En relation avec la [fig.5], on présente une description temporelle des étapes du procédé de migration selon un autre mode de réalisation de l'invention. Ce mode de réalisation est relatif à la température à laquelle un serveur est maintenu pour qu'il soit dans un fonctionnement optimal et donc au système de climatisation du serveur ou du centre de données dans lequel se trouve un serveur. Dans cette [Fig. 5], les trois courbes SA, 5B et 5C sont représentées. Sur la courbe SA, est représentée la mise en action du système de refroidissement, tandis que la courbe 5B est relative à la température observée du serveur et la courbe SC est relative à l'état de refroidissement du serveur. En état de fonctionnement opérationnel, le système passe en mode actif (courbe SA) dès lors que la température atteint un niveau Normal (courbe 5B) et ce, jusqu'à ce que la température du serveur atteigne le niveau Bas. [0056] Lors de ces phases cycliques de mise en fonctionnement du système de refroi- dissement (courbe SA), la température du serveur oscille dans un fonctionnement normal entre les niveaux Bas et Normal (courbe 5B) et l'état du système de refroidissement est normal (Norm - courbe SC). Si un problème survient sur le système de refroidissement permettant de réguler le paramètre Température de l'environnement 13 technique, la température peut passer au-dessus du niveau Normal (courbe 5B) car le système ne s'est pas activé lorsque le niveau de température Normal a été atteint (courbe 5A). La température du serveur atteint alors le niveau Deg (courbe 5B) et une entité d'administration d'un ou plusieurs serveur(s) reçoit une donnée relative à la température, par exemple le paramètre Deg (courbe SC). L'entité d'administration décide alors d'une action de sauvegarde d'une fonction virtualisée installée sur le(s) serveur(s) impacté(s) puis transmet à une entité gérant la fonction virtualisée un message de migration Evac. [0057] Selon un autre exemple, l'action de sauvegarde pourrait aussi comprendre la du- plication de la fonction virtualisée sur un autre serveur. L'entité d'administration peut en outre transmettre une durée de migration à respecter dans le message de migration transmis à l'entité de gestion de la fonction virtualisée. Il est possible qu'un serveur héberge plusieurs fonctions virtualisées et qu'une action de migration soit spécifique à une fonction virtualisée, auquel cas il peut être nécessaire, selon une alternative, de fournir un identifiant de la fonction virtualisée à l'entité de gestion de la fonction virtualisée, avec le cas échéant, une durée de migration spécifique à la fonction virtualisée. [0058] Selon une alternative, le serveur connaissant un problème de température peut être éteint (Extinc) pour ne pas aggraver le problème de température que peut connaître un centre de données où est présent le serveur. Selon une alternative, l'extinction peut uniquement consister à stopper le fonctionnement d'une machine virtuelle sur un serveur. A partir du moment où la température atteint le niveau Deg (courbe SB), la migration de la fonction virtualisée est demandée par l'entité d'administration à l'entité de gestion de la fonction virtualisée. Selon une autre alternative, l'extinction du serveur est effectuée par l'entité d'administration du serveur. Si la température du serveur continue d'augmenter malgré les opérations conduites, la température atteint le niveau Haut (courbe SB) et le serveur est alors dans un état défaillant (Def - Courbe SC) jusqu'au rétablissement et au redémarrage du système de refroidissement (courbe SA). Lorsque le serveur est dans un état Deg ou Def, selon les cas, dans la liste de correspondance des fonctions virtualisées sur les serveurs, il est indiqué comme ne pouvant pas accueillir de fonctions virtualisées. Après un délai de fonctionnement permettant d'atteindre de nouveau la température Normal (courbe SB), le serveur n'est plus dans un état défaillant (Def - Courbe SC) et repasse dans un état normal (Norm - Courbe SC). [0059] Lorsque plus aucun paramètre technique d'environnement dégradé ne justifie l'extinction du serveur, le serveur peut être rallumé s'il a été éteint, puis marqué dans la liste de correspondance des fonctions virtualisées sur les différents serveurs comme pouvant accueillir de nouvelles fonctions virtualisées. 14 [0060] En relation avec la [fig.6], on présente des étapes de mise en oeuvre de l'invention selon encore un autre mode de réalisation de l'invention. Dans cc mode de réalisation, le paramètre de l'environnement technique est relatif à un niveau d'eau dans la salle où est installé un serveur informatique. Le paramètre d'environnement technique correspond alors à un niveau d'eau au-delà duquel une opération de sauvegarde des fonctions virtualisées se trouvant sur le serveur doit être mise en oeuvre. [0061] Lors d'une étape 200, un détecteur de niveau d'eau d'une entité de l'environnement technique d'un serveur envoie à une entité d'administration du serveur, ou d'une infrastructure comprenant des serveurs, un message de notification Notif comprenant une donnée d'un paramètre relatif au niveau d'eau pouvant causer un dysfonctionnement d'un ou plusieurs scrvcur(s). La donnée peut être le niveau d'eau, un état du niveau d'eau ou toute autre donnée relative au niveau d'eau permettant à l'entité d'administration de prendre une décision. Cc message peut comprendre un identifiant de serveur ou une information, par exemple un identifiant de centre de données, permettant à l'entité d'administration du ou des scrvcur(s) d'identifier le ou les scrvcur(s) impacté(s) par la donnée reçue. [0062] A l'étape 201 Det, l'entité d'administration du ou des scrvcur(s) détermine une action de sauvegarde en fonction de la donnée du paramètre reçu. Si la donnée reçue indique un niveau d'eau qui peut être dommageable pour le serveur, il décide d'une action de migration d'une ou plusieurs fonction(s) virtualisée(s) installée(s) sur le serveur. L'action de sauvegarde peut, selon une alternative, également comprendre une action d'extinction du serveur et possiblement une action d'information d'autres entités de gestion, comme par exemple une entité de gestion des services, par exemple de type NFVO, opérés à partir de la fonction virtualisée à déplacer. L'action de sauvegarde peut également déclencher une échéance ou une durée à respecter pour la migration. Cette durée peut par exemple dépendre de différents paramètres reçus (type de fonctions virtualisées, donnée du paramètre reçue, types de serveurs, localisation du serveur). Le dispositif peut possiblement détenir une table de correspondance comprenant une liste des fonctions virtualisées installées sur les serveurs pour faire le lien entre le serveur impacté par le paramètre reçu et les actions de migration à mettre en oeuvre, voire les dispositifs de gestion de fonctions virtualisées à solliciter. [0063] A l'étape 202 Migr, l'entité d'administration transmet à une entité de gestion de la fonction virtualisée installée sur un serveur impacté par la donnée du paramètre reçu un message de migration de la fonction virtualisée. Ce message peut comprendre une durée à respecter pour effectuer la migration, par exemple en fonction de l'échéance déterminée dans l'étape 201. Le message peut également comprendre un identifiant de la fonction virtualisées à migrer, dans le cas où par exemple l'entité de gestion gère plusieurs fonctions virtualisées et dans le cas où des actions ou des durées distinctes sont à respecter pour la migration des différentes fonctions virtualisées gérées par l'entité de gestion. [0064] A l'étape 203 Info, selon une alternative, l'entité de gestion de la fonction virtualisée transmet à l'entité d'administration du serveur un message d'information indiquant que la migration a été effectuée ainsi qu'un identifiant d'un deuxième serveur sur lequel a été migré la fonction virtualiséc. Cette information permet notamment à l'entité d'administration de mettre à jour sa table de correspondance des fonctions virtualisées installées sur les serveurs, et également possiblement de s'abonner à un système de notification de données de paramètres d'environnement technique relatifs au deuxième serveur. Le deuxième serveur a été possiblemcnt sélectionné en fonction de sa localisation, topologique ou géographique, de façon à éviter d'installer la fonction virtualiséc sur un serveur possiblement également impacté par la donnée de paramètre technique reçu. [0065] A l'étape 204 Retrait, l'entité d'administration peut possiblement effectuer une opération Retrait où le premier serveur victime de l'incident relatif au paramètre technique est retiré de la table de correspondance par l'cnttié d'administration pour pouvoir accueillir une fonction virtualiséc. Cc retrait peut également être communiqué aux entités dc gestion des fonctions virtualisécs pour éviter qu'elles proposent une migration sur dc tels serveurs lors d'incidents liés à l'environnement technique d'un serveur impacté. [0066] A l'étape 205 Extinct, l'entité d'administration effectue possiblement une opération Extinct d'arrêt du serveur impacté par la donnée du paramètre technique reçu. Il peut s'agir d'éteindre une machine virtuelle, ou un conteneur, ou encore un serveur. Cette opération permet de protéger l'entité éteinte mais aussi de permettre un délai de rétablissement plus rapide en évitant les redémarrages intempestifs de ces serveurs lors du rétablissement du système voire également de protéger les autres équipements potentiellement impactés par le problème sur l'environnement technique. Un délai supplémentaire peut être laissé à l'entité d'administration du serveur pour procéder à un nettoyage de l'état de service du serveur avant son extinction. Les fonctions virtualisées y restant présentes peuvent être supprimées ou désactivées de sorte qu'au rallumage du serveur, elles ne se trouvent pas dans un état instable. La table de correspondance est mise à jour en conséquence de sorte que les fonctions virtualisées supprimées sur le serveur ne soient plus présentes dans la table. [0067] [fig.7]En relation avec , on présente un exemple de structure d'un dispositif de migration. Le dispositif 400 de migration met en oeuvre le procédé de migration, dont différents modes de réalisation viennent d'être décrits. [0068] Un tel dispositif 400 peut être mis en oeuvre dans une entité de gestion d'une infra- 16 structure de communication, telle qu'une entité de type VIM ou une entité de gestion spécifique à des paramètres de l'environnement technique. [0069] Par exemple, le dispositif 400 comprend une unité de traitement 430, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 410, stocké dans une mémoire 420 et mettant en oeuvre le procédé de détermination selon l'invention. A r initial isation, les instructions de code du programme d'ordinateur 410 sont par exemple chargées dans une mémoire RAM, avant d'être exécutées par le processeur de l'unité de traitement 430. [0070] Un tel dispositif 400 comprend : [0071] - un récepteur 401, apte à recevoir un message Notif de notification comprenant au moins une donnée d'un paramètre d'environnement technique relatif à un premier serveur. - un module 402 de détermination, apte à déterminer une action de sauvegarde d'une fonction virtualisée si l'au moins une donnée dépasse un seuil prédéfini - un émetteur 403, apte à émettre à destination d'une entité de gestion de la fonction virtualisée un message Migr de migration de la fonction virtualisée vers un deuxième serveur. [0072] L'invention permet d'instancicr ou de compléter un procédé d'installation et de migration de fonctions virtualisécs (VNFs) sur une infrastructure physique en tenant compte de paramètres inhérents au bon fonctionnement des serveurs de l'infrastructure physique, tels que la température des serveurs, la charge électrique des serveurs, les niveaux d'eau ou de gaz pouvant impacter le bon fonctionnement des serveurs voire un risque de dégradation des serveurs. Cette liste de paramètres relatifs à l'environnement technique n'est pas limitée et peut être adaptée en fonction du lieu où sont déployés les serveurs et de l'instant où ces serveurs sont utilisés. Le terme «serveur» utilisé comprend aussi bien un serveur physique, une machine virtuelle ou un conteneur selon le type de déploiement considéré. [0073] Les paramètres relatifs à l'environnement technique considérés peuvent être utilisés avec d'autres paramètres liés aux ressources de stockage, de calcul, de réseau, de disponibilité pouvant être prises en compte pour migrer ou non une fonction virtualisée sur un serveur. En outre, le procédé de migration peut également prendre en compte la spécificité de la fonction virtualisée pour la migrer ou non et à quelle échéance, selon notamment que la fonction virtualisée est critique ou non pour un service. L'entité d'administration du serveur peut être un dispositif de type VIM par exemple et le dispositif de gestion de la fonction virtualisée peut être par exemple un dispositif VNFM. Les données de paramètres d'environnement technique peuvent être transmis à l'entité d'administration directement ou via un contrôleur de paramètres d'environnement en charge de gérer les différents paramètres voire de corréler et 17 d'interpréter différents paramètres reçus avant de les transmettre à l'entité d'administration. Les données transmises peuvent correspondre à des valeurs, à des états d'un système, à des variations, ou à des codes compréhensibles pour l'entité d'administration et ces données peuvent être émises de façon sécurisée par exemple en chiffrant ces données émises. 18 REVENDICATIONS[Revendication 1] Procédé de migration d'une fonction virtualisée (VNF1 61, VNF2 62, VNF3 63) installée sur un premier serveur (VM 51, VM 52) dans un centre de données d'une architecture de communication, mis en oeuvre dans une entité (NFV1 TE 10, VIM 40) d'administration dudit premier serveur, ladite entité étant apte à émettre à destination d'une entité (VNFM 70) de gestion de la fonction virtualisée (VNF1 61, VNF2 62, VNF3 63) des données relatives à l'installation de la fonction virtualisée le procédé comprenant au moins une réception d'un message (Notif) de notification comprenant au moins une donnée d'un paramètre (Air 91, Elec 92, Détec 93) d'environnement technique relatif au premier serveur (VM51, VM 52), la détermination (Det) d'une action de sauvegarde de la fonction virtualisée (VNF1 61, VNF2 62, VNF3 63) si l'au moins une donnée franchit un seuil prédéfini et l'émission à destination de l'entité (VNFM 70) de gestion d'un message (Migr) de migration de la fonction virtualisée (VNF1 61, VNF2 62, VNF3 63) vers un deuxième serveur. [Revendication 2] Procédé de migration, selon la revendication 1, où l'au moins une donnée d'un paramètre (Elec 92) de l'environnement technique est relative à l'alimentation électrique du serveur. [Revendication 3] Procédé de migration, selon la revendication 1 ou la revendication 2, où l'au moins une donnée d'un paramètre (Air 91) technique d'environnement est relative au refroidissement du serveur. [Revendication 4] Procédé de migration, selon l'une des revendications 1 à 3, où l'au moins une donnée d'un paramètre (Détec 93) technique d'environnement est relative à un niveau d'eau dans la pièce où se trouve le serveur. [Revendication 5] Procédé de migration, selon l'une des revendications 1 à 4, où la déter- mination d'une action de sauvegarde comprend le déclenchement d'une échéance de migration. [Revendication 6] Procédé de migration, selon l'une des revendications 1 à 5, où le message de migration comprend une durée de migration à respecter. [Revendication 7] Procédé de migration, selon l'une des revendications 1 à 6, où le message de migration comprend une information d'identification relative à la fonction virtualisée. [Revendication 8] Procédé de migration, selon l'une des revendications 1 à 7, comprenant en outre la réception en provenance de l'entité de gestion d'un message 19 [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] d'information comprenant un identifiant du deuxième serveur sur lequel la fonction virtualisée a été migrée. Procédé de migration, selon l'une des revendications 1 à 8, où le deuxième serveur est sélectionné en fonction de sa localisation dans l'architecture de communication. Procédé de migration, selon l'une des revendications 1 à 9, comprenant en outre le retrait du premier serveur (VM 51, VM 52) d'une liste de serveurs aptes à accueillir une fonction virtualisée (VNFI 61, VNF2 62, VNF3 63) suite à la réception du message (Notif) de notification. Procédé de migration, selon l'une des revendications 1 à 10, comprenant en outre l'extinction du premier serveur (VM 51, VM 52) suite à l'émission à destination de l'entité de gestion du message (Migr) de migration. Dispositif (400) de migration d'une fonction virtualisée (VNFI 61, VNF2 62, VNF3 63) installée sur un premier serveur (VM 51, VM 52) dans un centre de données d'une architecture de communication, mis en oeuvre dans une entité d'administration dudit premier serveur, ladite entité étant apte à émettre à destination d'une entité de gestion de la fonction virtualisée des données relatives à l'installation de la fonction virtualisée, le dispositif comprenant - un récepteur (401), apte à recevoir au moins un message (Notif) de notification comprenant au moins une donnée d'un paramètre (Air 91, Elec 92, Détec 93) d'environnement technique relatif au premier serveur (VM 51, VM 52), - un module (402) de détermination apte à déterminer (Det) une action de sauvegarde de la fonction virtualisée si l'au moins une donnée franchit un seuil prédéfini - un émetteur (403), apte à émettre à destination de l'entité (VNFM 70) de gestion un message (Migr) de migration de la fonction virtualisée vers un deuxième serveur. Système de migration d'une fonction virtualisée installée sur un premier serveur (VM 51, VM 52) dans un centre de données d'une architecture de communication comprenant - une entité (NFVI TE 10, VIM 40) d'administration du premier serveur comprenant un dispositif (400) de migration selon la revendication 12, - une entité (VNFM 70) de gestion de la fonction virtualisée (VNFI 61, VNF2 62, VNF3 63) comprenant un récepteur apte à recevoir en provenance de l'entité d'administration un message (Migr) de migration 20 [Revendication 14] de la fonction virtualisee (VNF1 61, VNF2 62, VNF3 63) vers un deuxième serveur. [Revendication 15] Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de migration selon l'une quelconque des revendications 1 àll, lorsque le programme est exécuté par un processeur. Support d'enregistrement lisible par un dispositif de migration conforme à la revendication 12, sur lequel est enregistré le programme selon la revendication 14.