Volet 2 : Approche approximative de résolution basée sur la Recherche Taboue

Taboue ou TS

Les résultats obtenus dans le premier volet du travail ont montré que la méthode exacte de résolution du problème de partitionnement, même si elle a la particularité de produire des solutions optimales, n’est efficace qu’avec des instances de petite taille du problème. En effet, les temps de calcul sont très longs avec l’approche exacte, en raison de la nature NP-Difficile du problème. De ce fait, le but du travail dans ce deuxième volet est de contourner cette complexité, en proposant une approche approximative de résolution basée sur les métaheu- ristiques. Cette dernière nous permettra de résoudre en un temps de calcul raisonnable le modèle ILP proposé précédemment, en particulier avec des instances de grande taille du problème. Les performances de l’approche heuristique proposée seront évaluées en termes de qualité des solutions obtenues et temps de résolution, où il est question de trouver un ex- cellent compromis entre ces deux critères. Ce but, qui correspond notamment à l’objectif cinq (5) énoncé à la Section 1.3, a été atteint dans l’article intitulé « A Tabu Search Approach for a Virtual Networks Splitting Strategy Across Multiple Cloud Providers » (Diallo et al., 2018b), présenté au chapitre 5, dans lequel une approche approximative basée sur TS est proposée pour résoudre le problème de partitionnement des VNRs dans un environnement multiCloud.

3.3.1 Adaptation de la métaheuristique de TS

La métaheuristique de TS est choisie dans notre méthodologie pour son efficacité notoire à résoudre divers problèmes d’optimisation traitant des aspects d’évolutivité, notamment grâce à ses mécanismes de mémoire permettant d’éviter les cycles et les pièges des optima locaux, tel qu’expliqué à Section 2.4.2.2. Notre approche adaptée à l’algorithme de TS, nommée TS_Split, combine un processus de recherche local (LS), exécutant entre autres un critère d’aspiration et un mécanisme de mémoire à long terme (Diversification). Afin de détermi- ner une configuration de solution initiale, plusieurs méthodes ont été testées, à savoir une

méthode gloutonne où chaque VM est assignée au meilleur CP en termes de “quota” d’ap- provisionnement de ressources et les VLs au plus court chemin entre les CPs hôtes, une autre méthode où toutes les VMs sont assignées à un CP choisi aléatoirement, et une méthode où chaque VM est assignée aléatoirement à un CP répondant à ses attributs fonctionnels, et les VLs assignées à un chemin aléatoire entre les CPs hôtes. Les meilleures solutions ont été obtenues avec la troisième option. De ce fait, TS_Split part d’une solution initiale complète- ment aléatoire et, à chaque itération, le processus de LS parcourt le voisinage de la solution actuelle afin de trouver une meilleure solution. Si aucune amélioration de la meilleure solu- tion trouvée à date n’est observée pendant un certain nombre d’itérations, le mécanisme de Diversification est alors exécuté. Ce dernier consulte une liste statistique ayant mémorisé, de- puis le démarrage de l’algorithme, toutes les assignations de VMs aux CPs à partir desquelles l’espace de recherche a été exploré. Par la suite, en se basant sur les zones les moins explorées, une nouvelle solution initiale est construite, à partir de laquelle le processus de LS relance la recherche dans le but de trouver une solution encore meilleure. TS_Split s’arrête après un nombre fixe de relances du mécanisme de Diversification. Dans notre démarche méthodolo- gique, deux mouvements nous permettant de passer d’une solution actuelle à une solution voisine ont été examinés, à savoir la permutation entre deux VMs et le déplacement d’une seule VM d’un CP à un autre. Aussi, un mécanisme d’Intensification autour de la meilleure solution trouvée a été également testé. Cependant, les solutions de meilleure qualité ont tou- jours été obtenues avec le mécanisme de Diversification, et le mouvement simple qui déplace une seule VM à un autre CP était tout aussi efficace que celui de la permutation, et de plus prenait beaucoup moins de temps d’exécution. Par ailleurs, au lieu d’évaluer entièrement chaque configuration de solution obtenue itérativement, ce qui est très couteux en temps de calcul, nous avons défini des fonctions de calcul de gains exprimant la différence entre le coût d’une solution actuelle et celui d’une solution voisine. Ces fonctions de gains incluent le gain associé au coût intrinsèque de la fonction objectif du modèle ILP proposé, ainsi que les gains relatifs aux pénalités liées à la violation de certaines des contraintes associées au problème. Cette procédure de calcul de fonctions de gains est plus compliquée à implémenter, mais elle nous a permis de réduire considérablement l’ordre de complexité du temps de calcul, qui passe de O(n2) à O(n).

3.3.2 Évaluation de performance

L’approche heuristique proposée est implémentée en C++ et est évaluée par des simulations numériques, en utilisant le même environnement de simulation défini dans le premier volet. Nous avons mené notamment trois phases d’expérimentation, à savoir une première permet- tant de réaliser le paramétrage de l’algorithme TS_Split proposé, une seconde qui a pour

but d’évaluer les performances de TS_Split en termes de qualité des solutions obtenues et temps d’exécution, et un dernière permettant d’évaluer les performances de la stratégie de partitionnement des VNRs proposée, selon les mêmes critères que ceux considérés dans le premier volet du travail, mais résolue avec TS_Split. Chacune des expériences est réalisée et présentée en fonction de la taille des instances du problème, tel que décrit dans la suite.

3.3.2.1 Scénarios de test

Différents scénarios de test sont examinés, en considérant pour chacun 5 CPs et 10 CPs intervenant dans l’environnement multiCloud. Pour la seconde phase d’expérience, nous avons également étudié les cas simples, où le critère d’aspiration implémenté dans le processus de LS et le mécanisme de Diversification se sont pas exécutés. Pour la troisième phase d’expérience, l’algorithme au complet est exécuté. Pour les instances de petite taille, nous avons considéré les mêmes jeux de données que ceux générés dans le premier volet du travail, avec des VNRs ayant 5 VMs à 70 VMs. Pour les instances de grande taille, nous avons généré des VNRs pouvant contenir 75 VMs à 500 VMs.

3.3.2.2 Tests préliminaires et paramétrage de l’algorithme

Des phases préliminaires de tests sont d’abord effectuées. Ces dernières nous ont permis, en l’occurrence, de pouvoir déterminer la meilleure manière de générer une solution solution initiale et de réaliser des mouvements dans le processus de LS, mais également de définir les bonnes valeurs des paramètres de l’algorithme TS_Split en fonction de la taille des instances du problème. Ces paramètres incluent notamment la taille de la liste taboue, le nombre maximal d’itérations sans amélioration de la meilleure solution et le nombre maximal de relances du mécanisme de Diversification. Pour ce qui est du paramétrage de l’algorithme, les expériences ont été réalisées de manière progressive. Pour les instances de petite taille, nous nous sommes basés sur les coûts de solution obtenus avec la méthode exacte exécutée avec AMPL/CPLEX, afin de choisir les valeurs idéales pour les différents paramètres nous permettant d’atteindre ou d’approcher la solution optimale. Pour cela, d’abord la taille idéale de la liste taboue a été déterminée en fixant à des nombre très élevés le nombre d’itérations et le nombre de relances, afin de laisser rouler l’algorithme le plus longtemps possible et d’analyser le comportement et les résultats générés. Par la suite, nous avons fixé le nombre de relances à une valeur très grande afin de déterminer le nombre d’itérations nécessaires à l’algorithme pour s’approcher de la solution exacte, avant de terminer par paramétrer le nombre de relances de la Diversification. Pour les instances de grande taille nous avons procédé avec la même démarche, en s’aidant cette fois-ci de la meilleure solution obtenue

parmi toutes les simulations, et ce pour chaque taille de VNR de 75 à 500 VMs. Des formules mathématiques, en fonction du nombre de VMs dans les VNRs et du nombre de CPs dans le multiCloud, ont pu être dégagées pour chaque paramètre de l’algorithme TS_Split, en analysant autant les qualités des solutions obtenues et les temps d’exécution engendrés, dans le but d’arriver à un excellent compromis entre ces deux critères.

3.3.2.3 Comparaison avec la méthode exacte sur des instances de petite taille

Pour les VNRs de petite taille, les tests réalisés montrent une meilleure qualité des solutions générées lorsque le critère d’aspiration est appliqué, et des améliorations considérables avec l’exécution du mécanisme de Diversification. La comparaison avec la méthode exacte montre que l’approche approximative de résolution proposée est capable de générer presque à tous les coups la solution optimale, avec un écart de coût de solution en moyenne à moins de 2.97 % de la solution exacte, et ce en un temps de calcul linéairement réduit. Pour ce qui est d’évaluer les performances de notre stratégie de partitionnement, résolue cette fois-ci avec TS_Split, nous avons d’abord implémenté en C++ l’approche de partitionnement basée sur la Recherche Locale Itérée ou ILS proposée par (Leivadeas et al., 2013), nommée ILS_Split. Par la suite, nous avons comparé cette dernière à notre approche, en appliquant la même approche multiobjectif précédente de résolution de la phase d’hébergement intraCloud, exé- cutée de manière optimale avec AMPL/CPLEX. Les résultats prouvent que notre approche heuristique est aussi efficace que la méthode exacte pour prendre les meilleures décisions pos- sibles de partitionnement de VNRs par rapport à ILS_Split, en fonction des mêmes critères de performance que ceux considérés dans le premier volet de notre travail.

3.3.2.4 Comparaison avec une méthode de référence sur des instances de grande taille

Pour les VNRs de grande taille, les tests ont montré que sans le mécanisme de Diversifica- tion, la qualité des solutions est encore plus dégradée, avec dans certains cas des solutions irréalisables en raison des contraintes de délai maximal violées sur certains VLs. De ce fait, pour de telles instances du problème, la Diversification était incontournable pour l’algorithme proposé. Les résultats obtenus avec les grandes tailles de VNRs confirment les performances de l’algorithme TS_Split en termes de qualité de solution, en générant des coûts de solution avec un écart en moyenne de 0.17 % du coût maximal, notamment lorsque le critère d’aspi- ration est appliqué. Pour ces instances de grande taille, la phase d’hébergement intraCloud est résolue avec un algorithme de descente itérée, et comparé à ILS_Split, TS_Split donne de meilleurs résultats en un temps de résolution d’exécution également plus réduit.

3.4 Volet 3 : Extension du modèle de partitionnement multiCloud et approche