FR 3091771 A1 20200717 FR 1873793 A 20181221 Description Titre de l'invention : Executionasolation d'application par al- location de ressources réseau au travers du mécanisme de routage [0001] 2. Titre proposé : [0002] Execution/Isolation d'application par allocattion de ressources réseau au travers du mécanisme de routage [0003] 3. Problème technique posé [0004] Dans les platefoimes High Performance Computing (HPC), un ensemble de [0005] machines est interconnecté par un réseau haute performance afin de faire [0006] travailler/communiquées les machines ensemble. L'utilisation du réseau de [0007] communication varie au cours de l'exécution des applications lancées sur le [0008] supercalculateur. Comment adapter le routage à la fluctuation des besoins réseau ? Comment réduire la consommation énergétique en fonction des besoins ? Comment réaliser les modifications de manière transparente ? Comment assurer les performances des applications ? Comment améliorer la reproductibilité de l'exécution ? Comment réduire la consommation énergétique ? [0009] 4. Les solutions connues [0010] Les principales méthodes existantes sont : J. Domke and T. Hoefler, "Scheduling-Aware Routing for Supercomputers," SC '16: Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, Salt Lakc City, UT, 2016, pp. 142-153. doi: 10.1109/SC.2016.12 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7877011&isnumbe r=7876994 Matthieu Pcrotin, Tom Cornebize, "Isolating Jobs for Security on HighPerformance Fabrics'', High-Performance Interconnection Networks in the Exascale and Big-Data Era (HiP1NEB) 2017 IEEE 3rd International Workshop on, pp. 49-56, 2017. [0011] Pour le travail sur le scheduling aware routing, l'approche est intéressante car utilisant une base de données avec la liste des applications en cours d'exécution sur le supercalculateur, le routage recalcul les routes en fonction de leur utilisation afin de réduire la congestion sur le réseau de calcul. Cette approche ne s'intéresse ni à la reproductibilité des performances pour les applications et à la réduction de l'utilisation d'énergie. 2 [0012] L'isolation de jobs pour la sécurité ne prend en compte que la problématique de l'exécution d'un job et ne s'intéresse pas à la problématique liée à l'ensemble des applications. De plus le travail effectué ne s'intéresse qu'à la réduction des changements sur les tables de routage pour arriver à une isolation. [0013] 5. Présentation de l'invention [0014] Lors du routage d'une plateforme, le nombre route à calculer est de 2 n^2 routes, avec n le nombre de noeuds de calcul. Ces routes sont à distribuer sur l'ensemble des liens de la plateforme. [0015] Il est évident que pour des questions de tout le nombre de liens de communications entre les machines est largement inférieur au 2 n^2. Il est généralement de l'ordre de 0(n). [0016] Lorsqu'une application utilise n i noeuds, il y a 2 * n i^2 routes. S'il y a deux ap- plications utilisant la moitié des noeuds, il y a 4 fois moins de routes que sur l'ensemble de la machine. Cela permet de simplifier le travail du routage mais aussi de répartir uniquement les routes utiles aux applications. [0017] Le système proposé va bien plus loin que les solutions existantes, en couplant le ges- tionnaire de ressource (comme slurm) qui sélectionne les noeuds dédiés à une application avec le routage. Pour chaque soumission de jobs l'algorithme de routage est interrogé afin de connaitre l'emplacement le plus approprié pour placer l'application. En fonction du routage actuel l'algorithme est capable de sélectionner afin d'optimiser différentes contraintes pouvant être tuner par l'administrateur et/ou des demandes utilisateur (réduire la consommation réseaux, maximiser les performances, sécurité ...). [0018] Ainsi, l'algorithme de routage sera capable d'allouer et de dédier des liens aux ap- plications. [0019] [fig.1] [0020] [fig.2] [0021] [fig.3] [0022] [fig.4] [0023] [fig.5] [0024] [fig.6] [0025] [fig.7] [0026] [fig.8] [0027] [fig.9] [0028] [fig.10] [0029] [fig.11] [0030] [fig.12] Port numbering [0031] [fig.13] [0032] [fig.14] 3 [0033] [fig.15] [0034] [fig.16] [0035] Les contraintes pour la réalisation : [0036] 1. La quantité de données transférées pour mettre à jour les tables de routages [0037] 2. Le risque de ralentissement de la soumission des jobs [0038] Les gains de la solution : [0039] 1. Reproductibilité des expériences grâce à une isolation réelle des applications [0040] 2. Amélioration des performances des applications grâce à des liens dédiés [0041] 3. Réduction de la complexité de calcul des algorithmes de routages [0042] [Math.1] a. 1: 0(2 * - [0043] 4. Réduction de la consommation énergétique en éteignant les liens et switchs non utilisées [0044] Pour réduire le besoin de changement des tables de routages, il nécessaire d'utiliser un set de tables prédéfinies. Dans le cadre d'un PGFT (fat Cree), il est possible de positionner dans chaque switch l'ensemble de tables de routage permettant d'atteindre l'ensemble des machines de la sous topologie dans lequel le switch est inclus Ainsi lors de la soumission d'application, le routage n'aura qu'à modifier les tables de routage qui réalise la monter dans l'arbre du PGFT. Cela réduit de moitié l'envoi de modifications. De plus les tables de routages par défaut peuvent être mise afin de correspondre pour des allocations de jobs utilisant une sous topologie complète Ainsi les tables de routage devront être modifiées uniquement dans le cas où l'allocation du job ne match pas une sous-topologie complète. [0045] Ce principe permet de réduire le temps nécessaire aux modifications des tables de routage dans la plate-forme. Pour conserver cet effet, il peut être nécessaire de remettre les tables de routages initial après chaque job. [0046] En réalisation l'allocation des liens, il est possible de dédier des liens aux différentes application et ainsi réduire l'impact des applications entre elles. Ainsi il est possible de réduire la variance des temps d'exécution d'une fois à l'autre. Sur un PGFT, il est « non-pruner » possible de créer d'isoler chaque application sur des sets de liens précis sans augmenter la congestion. [0047] Il est possible de réduire l'utilisation énergétique en éteignant les liens non utiliser. Par exemple sur un siwtch directement connecté aux noeuds de calcul. Généralement sur un PGFT moitié des liens sont dédiées aux noeuds de calcul et l'autre moitié aux liens inter-switch. Si par exemple 10 noeuds d'un même switch sont utilisés pour une application en particulier ces 10 noeuds ne communiqueront à l'extérieur que vers les noeuds d'IO. Ainsi il est possible d'éteindre jusqu'à 10 liens durant l'exécution de cet application (en fonction du nombre de noeuds d' io sur la platcformc ainsi que les besoins en 10 demandé par l'utilisateur, il est possible de conserver ces liens actifs. [0048] [0049] S = ordonnanccur [0050] R = gestionnaire de routage [0051] JX = travail n° X [0052] NN(JX) = nombre de noeuds demandé par le travail JX [0053] NJ [0054] NX = noeud n° X [0055] CXY = commutateur de la ligne X et de la colonne Y [0056] TR(CXY) = table de routage du commutateur CXY [0057] [0058] El - initialement, les tables de routage des commutateurs sont obtenues en utilisant d-mod-k, par exemple : [0059] TR(C11) : Ni -> N1 I N2 -> N2 I N3, N5, N7, N9, N11 -> C21 I N4, N6, N8, N10, N12 -> C22 [0060] TR(C12) : N3 -> N3 I N4 -> N4 I N1, N5, N7, N9, N11 -> C21 I N2, N6, N8, N10, N12 -> C22 [0061] TR(C21) : N2 -> C11 I N3, N4 -> 02 I N5, N6, N9, N10 -> C31 I N7, N8, N11, N12 -> C32 [0062] TR(C22) : Ni, N2 -> Cl I I N3, N4 -> C12 I N5, N6, N9, NIO -> C33 I N7, N8, N11, N12 -> C34 [0063] E2 - l'ordonnanceur S envoie le travail JI avec le nombre de noeuds demandé NN(Ji) = 3 au gestionnaire de routage R [0064] E3 - le gestionnaire de routage R sélectionne les noeuds Ni, N2, N3 pour le travail JI à partir de la charge des liens (figure 2) [0065] E4 - (INVENTION A) - le gestionnaire de routage R détecte les liens non utilisés et les désactive (figure 2, liens en noir, comme par exemple le lien C11 C22) [0066] E5 - l'ordonnanceur S envoie le travail J2 avec le nombre de noeuds demandé NN(J2) = 3 au gestionnaire de routage R [0067] E6 - (INVENTION C) - le gestionnaire de routage R sélectionne les noeuds N4, N5, N6 pour le travail J2 à partir de la charge des liens, en sélectionnant en premier les liens des commutateurs déjà en cours d'utilisation (figure 3, commutateur C12) [0068] E7 - (INVENTION B) - le gestionnaire de routage R détecte que les liens C12 C21 et C12 C22 sont utilisés par le travail JI et le travail J2 (figure 3, liens en rouge) [0069] E8 - (INVENTION B) - le gestionnaire de routage R modifie la table de routage TR(C12) pour que seul le travail JI utilise le lien C21 C12 : [0070] TR(C12) : N3 -> N3 I N4 -> N4 I N1, N2, N5, N7, N9, N11 -> C21 I N2, N5, N6, N8, N10, N12 -> C22 [0071] (figure 4) [0072] E9 - le gestionnaire de routage R envoie la table de routage TR(C12) modifiée au commutateur C12 (figure 4) [0073] El° - (INVENTION A) - le gestionnaire de routage R détecte les liens non utilisés comme par exemple C11 C22 et les désactive (figure 4, liens en noir) [0074] Routing awarc schcduling The jobs arc takcn into account to reduce the numher of route considered hy the routing algorithm: - when routing messages coming from or toward the node 0, only the node 2 4 6 8 10 12 and 14 arc considered - when routing messages coming from or toward the node 1, only the node 3 5 7 9 11 13 and 15 are considered The proposcd algorithm only balances the effective routes on the switch 0.0.0.0, it may do: - 0 -> 2 on port 2 - 0 -> 4 on port 3 - 0 -> 6 on port 2 - 0 -> 8 on port 3 ... - Each job will use all available links [0075] Isolating jobs for security on highperfonnance fabrics - The aim is only to avoid any communications between jobs in this case only the naive approach is fesable (but the result would be the same with the other method) - On the swith all switches 0.*.*.* the routes on port 1 for reaching the node 0,2,4,...,14 are removed - On the swith all switches 0.*.*.* the routes on port 0 for reaching the node 1,3,5,...,15 are removed - In the same way as for the precedent solution each job may use all available links and so share links between jobs. - http://hipineb.i3a.info/hipineb2017/wpcontent/uploads/sites/6/2017/0 5/slides_perotin.pdf [0076] Pour l'algorithme de sélections des liens: [0077] On compte le nombre de noeuds par sous topologie (simple à faire). [0078] Pour chaque sous topologie avec un nombre non nul de noeud : Prendre une des sous topologies la plus importante (appellé T_n_c de niveau n : les switches de plus haut niveau sont n) 6 Considérons qu'il y a S n switch de niveau n. Pour chaque sous de incluse dans T n c de niveaux n-1, on a un nombre de noeuds allouées x n-1 (Pour simplifier je considère que chaque sous topologie à le même nombre de noeuds). For i=0 ; i