Répartition de la charge (informatique)

Un article de Wikipédia, l'encyclopédie libre
Aller à la navigation Aller à la recherche
Diagramme illustrant les besoins des utilisateurs pour un cluster Elasticsearch distribué par un équilibreur de charge. (Exemple pour Wikipédia).

En informatique , des calculs extensifs ou de grandes quantités de requêtes sont répartis sur plusieurs systèmes fonctionnant en parallèle au moyen d' un équilibrage de charge dans le but de rendre l'ensemble de leur traitement plus efficace.

L'équilibrage de charge est le résultat de recherches dans le domaine des ordinateurs parallèles . Deux approches principales coexistent : les algorithmes statiques, qui ne tiennent pas compte de l'état des différentes machines, et les algorithmes dynamiques, qui sont souvent plus généraux et efficaces, mais nécessitent un échange d'informations sophistiqué entre les différentes unités de calcul, ce qui peut nuire à l'efficacité. .

Cela peut prendre des formes très différentes. Une simple répartition de la charge a lieu, par exemple, sur des ordinateurs à plusieurs processeurs. Chaque processus peut s'exécuter sur son propre processeur . La manière dont les processus sont distribués aux processeurs peut avoir un impact majeur sur les performances globales du système, car par ex. B. le contenu du cache est local pour chaque processeur. Une autre méthode peut être trouvée dans les grappes d'ordinateurs ou les serveurs . Ici, plusieurs ordinateurs forment un réseau, qui se comporte généralement comme un seul système à l'extérieur.

aperçu du problème

Un algorithme d'équilibrage de charge essaie toujours de résoudre un problème spécifique. Entre autres, le type de tâches à résoudre, la complexité algorithmique , l' architecture matérielle et la tolérance aux pannes doivent être pris en compte. Un compromis doit donc être trouvé afin de répondre au mieux aux exigences spécifiques à l'application.

type d'emplois

L' efficacité des algorithmes d'équilibrage de charge dépend essentiellement du type de travaux. Par conséquent, plus d'informations sur les tâches sont disponibles au moment de la prise de décision, plus le potentiel d'optimisation est grand.

Taille

Une parfaite connaissance du temps d'exécution de chacune des tâches permet d'obtenir un équilibrage de charge optimal (voir l' algorithme prefix -sum ci-dessous). [1] Malheureusement, il s'agit en fait d'un cas idéalisé. Connaître exactement le temps d'exécution de chaque tâche est une situation extrêmement rare.

Pour cette raison, il existe différentes techniques pour se faire une idée des différents temps d'exécution. Tout d'abord, dans le cas heureux où les tâches sont de taille relativement homogène, on peut supposer que chacune d'elles prend environ le temps d'exécution moyen. En revanche, si le temps d'exécution est très erratique, des techniques plus subtiles doivent être utilisées. Une technique consiste à ajouter des métadonnées à chaque tâche. En fonction du temps d'exécution précédent pour des métadonnées similaires, des conclusions peuvent être tirées pour une tâche future basée sur des statistiques. [2]

Enfin, le nombre de tâches lui-même peut avoir une certaine importance.

dépendance

Dans certains cas, les tâches dépendent les unes des autres. Ces relations de dépendance mutuelle peuvent être illustrées par un graphe orienté acycliquement (en anglais Directed acyclic graph ). Intuitivement, certaines tâches ne peuvent pas commencer tant que d'autres ne sont pas terminées.

En supposant que le temps requis pour chacune des tâches est connu à l'avance, un ordre d'exécution optimal doit conduire à minimiser le temps d'exécution total. Bien qu'il s'agisse d'un problème NP-difficile et qu'il puisse donc être difficile à résoudre avec précision, il existe des algorithmes d' ordonnancement qui produisent des distributions de tâches honorables.

clivage

Une autre caractéristique des tâches qui a un impact majeur sur la conception de l'algorithme d'équilibrage de charge est leur capacité à être décomposées en sous-tâches lors de l'exécution. L'algorithme "work-stealing", que nous présenterons plus tard, utilise cette particularité.

Algorithmes statiques et dynamiques

Algorithmes statiques

Un algorithme d'équilibrage de charge est dit « statique » s'il ne tient pas compte de l'état du système lors de la répartition des tâches. Par santé du système, nous entendons l'utilisation (et parfois même la surcharge) de certains processeurs. Au lieu de cela, des hypothèses sur le système global sont faites à l'avance, par ex. B. les heures d'arrivée et les besoins en ressources des tâches entrantes. De plus, le nombre de processeurs, leur puissance respective et leur vitesse de communication sont connus. Il s'agit donc de connecter les tâches aux processeurs d'une manière qui minimise une fonction de performance spécifique. L'astuce réside dans la conception de cette fonction de puissance.

Les techniques sont toujours centralisées autour d'un routeur qui répartit les charges et assure l'optimisation de la fonction. Cette minimisation peut prendre en compte des informations liées aux tâches à répartir et en déduire un temps d'exécution attendu.

L'avantage des algorithmes statiques est qu'ils sont faciles à mettre en œuvre et extrêmement efficaces pour des tâches relativement régulières (comme le traitement des requêtes HTTP d'un site Web). Cependant, il existe toujours des écarts statistiques dans la répartition des tâches, ce qui peut entraîner une surcharge de certaines unités de traitement.

Algorithmes dynamiques

Contrairement aux algorithmes d'équilibrage de charge statique, les algorithmes dynamiques prennent en compte la charge actuelle de chacune des unités de calcul (également appelées nœuds) du système. Avec cette approche, les tâches peuvent être déplacées dynamiquement d'un nœud surchargé vers un nœud sous-chargé pour un traitement plus rapide. Bien que ces algorithmes soient beaucoup plus compliqués à concevoir, ils peuvent produire d'excellents résultats, notamment lorsque le temps d'exécution varie fortement d'une tâche à l'autre.

Avec l'équilibrage de charge dynamique, l'architecture peut être plus modulaire car il n'est pas obligatoire d'avoir un nœud dédié pour l'équilibrage du travail. Lorsque des tâches sont affectées de manière unique à un processeur en fonction de son état à un instant donné, on parle d'affectation unique. En revanche, si les tâches peuvent être constamment redistribuées en fonction de l'état du système et de son évolution, on parle alors d'allocation dynamique. Évidemment, un algorithme d'équilibrage de charge qui nécessite trop de communication pour prendre ses décisions n'est pas souhaitable, au risque de ralentir la résolution du problème global. Le pire des cas est un jeu de ping-pong entre les processeurs, entraînant un blocage indéfini de la solution.[3]

architecture matérielle

machines hétérogènes

Les infrastructures informatiques parallèles sont souvent constituées d'unités de puissance de calcul différente, dont il convient de tenir compte lors de la répartition de la charge.

Par exemple, les entités les moins performantes peuvent recevoir des requêtes nécessitant moins d'efforts de calcul ou, dans le cas de tailles de requêtes homogènes ou inconnues, recevoir moins de requêtes que des entités plus grandes.

Stockage partagé et distribué

Les ordinateurs parallèles sont souvent divisés en deux grandes catégories : ceux dans lesquels tous les processeurs partagent une même mémoire commune à partir de laquelle ils lisent et écrivent en parallèle ( modèle PRAM ), et ceux dans lesquels chaque unité de traitement possède sa propre mémoire ( modèle de la mémoire distribuée ). ) et échange des informations par messages avec les autres unités.

Sur les ordinateurs à mémoire partagée, la gestion des conflits d'écriture ralentit considérablement la vitesse d'exécution individuelle de chaque unité de traitement. Cependant, vous pouvez bien travailler en parallèle. A l'inverse, lors de l'échange de messages, chacun des processeurs peut fonctionner à pleine vitesse. En revanche, lors de l'échange de messages, tous les processeurs sont obligés d'attendre que les processeurs les plus lents démarrent la phase de communication.

En réalité, peu de systèmes entrent exactement dans l'une des catégories. En général, les processeurs disposent chacun d'une mémoire interne pour stocker les données nécessaires aux prochains calculs et sont organisés en grappes consécutives. Souvent, ces éléments de traitement sont ensuite coordonnés via une mémoire et une messagerie distribuées. Par conséquent, l'algorithme d'équilibrage de charge doit clairement être adapté à une architecture parallèle. Sinon, il y a un risque que l'efficacité de la résolution de problèmes parallèles soit gravement affectée.

hiérarchie

Pour s'adapter aux structures matérielles présentées ci-dessus, il existe deux principales catégories d'algorithmes d'équilibrage de charge. D'une part, les tâches sont assignées par un "maître" et exécutées par des "travailleurs" ( modèle maître-esclave), qui tiennent le maître informé de l'évolution de leur travail. Le maître peut alors être responsable de l'allocation (et de la réallocation) de la charge de travail si l'algorithme est dynamique (avec allocation dynamique). La littérature parle d'architecture "maître-ouvrier". Inversement, le contrôle peut être distribué aux différents nœuds. L'algorithme d'équilibrage de charge est ensuite exécuté sur chacun d'eux, et la responsabilité de l'allocation des tâches (ainsi que de leur réallocation et de leur fractionnement si nécessaire) est partagée. Cette dernière catégorie suppose un algorithme d'équilibrage de charge dynamique.

Encore une fois, puisque la conception de chaque algorithme d'équilibrage de charge est unique, la distinction précédente doit être nuancée. Une stratégie intermédiaire est également possible, par ex. B. avec des nœuds "maîtres" pour chaque sous-cluster, qui à leur tour sont soumis à un "maître" global. Il existe également des organisations multi-niveaux, avec une alternance entre des stratégies maître-esclave et de contrôle distribué. Ces dernières stratégies deviennent rapidement complexes et sont rarement rencontrées. Les développeurs préfèrent des algorithmes plus facilement contrôlables.

évolutivité

Dans le cadre d'algorithmes qui s'exécutent sur une très longue durée ( serveur , cloud ...), l'architecture des ordinateurs évolue dans le temps. Cependant, il est préférable de ne pas avoir à concevoir un nouvel algorithme à chaque fois.

Un autre paramètre important d'un algorithme d'équilibrage de charge est donc sa capacité à s'adapter à une architecture matérielle évolutive. C'est ce qu'on appelle la scalabilité de l'algorithme. Un algorithme est également dit évolutif pour un paramètre d'entrée si ses performances restent relativement indépendantes de la taille de ce paramètre.

Si l'algorithme est capable de s'adapter à un nombre de processeurs différent, mais que le nombre de processeurs doit être fixé avant exécution, il est dit "moulable " . En revanche, si l'algorithme est capable de gérer un nombre variable de processeurs lors de son exécution, l'algorithme est dit malléable . La plupart des algorithmes d'équilibrage de charge sont au moins malléables. [4]

tolérance aux pannes

Dans les grands réseaux informatiques en particulier , il est intolérable d'exécuter un algorithme parallèle qui ne peut pas supporter la défaillance d'un seul composant. Par conséquent, des algorithmes tolérants aux pannes sont développés pour détecter les pannes du processeur et récupérer le calcul. [5]

approches

Équilibrage de charge statique avec Full Confession of Jobs : algorithme "Prefix-Sum"

Si les tâches sont indépendantes et divisibles, et si l'on connaît leur temps d'exécution respectif, il existe un algorithme simple et optimal.

En divisant les tâches de manière à ce que chaque processeur ait le même effort de calcul, il suffit de regrouper les résultats. A l' aide d'un algorithme de somme de préfixes , cette division peut être calculée en un temps logarithmique du nombre de processeurs.

Cependant, si les tâches ne peuvent pas être subdivisées (elles sont dites atomiques), bien que l'optimisation de l'allocation des tâches soit un problème difficile, il est toujours possible de se rapprocher d'une répartition relativement équitable des tâches, à condition que la taille de chaque tâche individuelle soit beaucoup plus petite. que la quantité totale de calculs effectués par chacun des nœuds. [1]

La plupart du temps, le temps d'exécution d'une tâche est inconnu et seules des approximations grossières sont disponibles. Bien que cet algorithme soit particulièrement efficace, il n'est pas pratique pour ces scénarios.

Répartition de la charge statique sans connaissance préalable

Si le temps d'exécution n'est pas du tout connu à l'avance, l'équilibrage de charge statique est toujours possible.

tournoi à la ronde

Dans cet algorithme, la première requête est envoyée au premier serveur, puis le suivant au second, et ainsi de suite jusqu'au dernier. Puis on recommence en affectant la requête suivante au premier serveur, et ainsi de suite.

Cet algorithme peut être pondéré de manière à ce que les unités les plus performantes reçoivent le plus grand nombre de requêtes et les reçoivent en premier.

Affectation aléatoire

Il s'agit simplement de l'attribution aléatoire de tâches aux différents serveurs. Cette méthode fonctionne assez bien. Si le nombre de tâches est connu à l'avance, il est encore plus efficace de calculer à l'avance une permutation aléatoire. Cela évite les frais de communication pour chaque commande. Un maître de distribution n'est pas nécessaire, car chacun sait quelle tâche lui est assignée. Même si le nombre de tâches n'est pas connu, on peut s'affranchir d'une communication avec une génération d'affectation pseudo-aléatoire connue de tous les processeurs.

Les performances de cette stratégie (mesurées en termes de temps d'exécution total pour un ensemble fixe de tâches donné) diminuent avec la taille maximale des tâches.

"Maître Ouvrier"

Régime des maîtres-ouvriers

Le schéma maître-travailleur est l'un des algorithmes d'équilibrage de charge dynamique les plus simples. Un maître répartit la charge de travail entre tous les travailleurs (parfois appelé « esclave »). Au début, tous les travailleurs sont inactifs et le signalent au contremaître. Le maître leur distribue les tâches. Lorsqu'il n'a plus de tâches à donner, il informe les ouvriers de ne plus demander de travail.

L'avantage de ce système est qu'il répartit très équitablement la charge. Si l'on ne tient pas compte du temps requis pour le travail, le temps d'exécution serait comparable à la somme des préfixes donnée ci-dessus .

Le problème de cet algorithme est qu'il est difficile à adapter à un grand nombre de processeurs du fait des volumes importants de communications. Ce manque d'évolutivité signifie qu'il devient rapidement inopérant avec de très gros serveurs ou de très gros ordinateurs parallèles. Le maître agit comme un goulot d'étranglement.

Cependant, la qualité de l'algorithme peut être considérablement améliorée si le maître est remplacé par une liste de tâches utilisant les différents processeurs. Bien que cet algorithme soit un peu plus difficile à mettre en œuvre, il promet une bien meilleure évolutivité, bien qu'elle soit encore insuffisante pour les très grands centres de données.

Architecture distribuée, sans connaissance préalable : le vol de travail

Une technique utilisée pour surmonter les problèmes d'évolutivité sans connaissance préalable des temps d'exécution est le vol de travail .

L'approche consiste à attribuer à chaque processeur un certain nombre de tâches au hasard ou de manière prédéfinie, puis à permettre aux processeurs inactifs de "voler" le travail des processeurs actifs ou surchargés. Il existe plusieurs implémentations de ce concept, définies par un modèle de partage des tâches et par les règles régissant les échanges entre processeurs. Si cette technique peut être particulièrement efficace, elle est difficile à mettre en oeuvre du fait de la nécessité de s'assurer que l'échange de messages ne se substitue pas à l'exécution proprement dite des calculs pour résoudre le problème.

En ce qui concerne les tâches atomiques, on peut distinguer deux stratégies principales : celles où les processeurs peu chargés offrent leur puissance de calcul à ceux qui sont les plus chargés, et celles où les unités les plus chargées cherchent à réduire la charge de travail qui leur est assignée. Il a été montré que lorsque le réseau est occupé, il est plus efficace que les unités les moins chargées offrent leur disponibilité, et lorsque le réseau est léger, les processeurs surchargés ont besoin du support des moins actifs. Cette règle empirique limite le nombre de messages échangés.

Dans le cas où l'on commence avec une seule grande tâche qui ne peut pas être partitionnée au-delà d'un niveau atomique, il existe un algorithme très efficace où la tâche parent est partitionnée dans un arbre.

les ancêtres

Initialement, tous les processeurs ont une tâche vide sauf un qui y travaille de manière séquentielle. Les processeurs inactifs font alors des requêtes aléatoires à d'autres processeurs (qui ne sont pas nécessairement actifs). Lorsqu'il est capable de subdiviser la tâche sur laquelle il travaille, il le fait en envoyant une partie de son travail au nœud demandeur. Sinon, il renvoie une tâche vide. Cela crée une arborescence. Il est alors nécessaire d'envoyer un signal d'achèvement au processeur maître lorsque la sous-tâche est terminée, pour qu'il envoie à son tour le message à son processeur maître jusqu'à ce qu'il atteigne la racine de l'arbre. Si le premier processeur, i. H la racine, terminée, un message global de terminaison peut être diffusé. Au final il faut

Efficacité

L'efficacité d'un tel algorithme est proche de la somme des préfixes si le temps de découpage et de communication n'est pas excessif par rapport au travail à effectuer. Afin d'éviter des coûts de communication trop élevés, il est possible d'imaginer une liste de jobs sur mémoire partagée. Par conséquent, une requête lit simplement à partir d'un emplacement spécifique dans cette mémoire partagée à la demande du processeur maître.

Exemples d'applications

Certaines méthodes possibles sont le système en amont (load balancer, serveur frontal) qui fractionne les requêtes, ou l'utilisation du DNS avec la méthode round-robin . L'équilibrage de charge des serveurs est particulièrement important pour les serveurs Web , car un seul hôte ne peut répondre qu'à un nombre limité de requêtes HTTP à la fois.

L'équilibreur de charge en amont ajoute des informations supplémentaires à la requête HTTP afin d'envoyer des requêtes du même utilisateur au même serveur. Ceci est également important lors de l'utilisation de SSL pour crypter la communication, afin qu'une nouvelle poignée de main SSL ne doive pas être effectuée pour chaque demande.

L'équilibrage de charge est également utilisé pour les lignes de données / voix afin de répartir le flux de trafic sur des lignes parallèles. Dans la pratique, cependant, il est souvent difficile de répartir uniformément le trafic données/voix sur les deux lignes. La solution généralement mise en œuvre est qu'une ligne est utilisée comme canal aller et la deuxième ligne est utilisée comme canal retour.

L'équilibrage de charge va souvent de pair avec des mécanismes de sécurité : en configurant un cluster avec la capacité appropriée et en distribuant les requêtes aux systèmes individuels, vous pouvez obtenir une augmentation de la sécurité, à condition que la défaillance d'un système soit détectée et que les requêtes soient automatiquement transmis à un autre système (voir aussi : haute disponibilité ou haute disponibilité, "HA").

équilibrage de la charge du serveur

L'équilibrage de charge serveur ( « SLB ») est utilisé partout où un grand nombre de clients génère une forte densité de requêtes et surchargerait donc un seul ordinateur serveur. Les applications peuvent être mises à l' échelle en répartissant les demandes sur plusieurs serveurs à l'aide de SLB . Les critères typiques pour déterminer le besoin de SLB sont le débit de données , le nombre de clients et le taux de demande.

Un autre aspect est l'augmentation de la disponibilité des données via SLB. L'utilisation de plusieurs systèmes avec la même base de données/application permet un stockage redondant des données. La tâche du SLB est de basculer les clients vers les serveurs individuels. Cette technologie est utilisée, entre autres, dans les réseaux de diffusion de contenu .

SLB est utilisé pour les grands portails tels que Wikipédia , les places de marché ou les boutiques en ligne. En principe, l'utilisateur ne remarque pas si SLB est utilisé du côté opposé. Voir aussi Redirection .

SLB peut être implémenté sur différentes couches du modèle de référence ISO-OSI .

Tourniquet DNS

Dans ce cas, plusieurs adresses IP sont stockées pour un nom d'hôte dans le système de noms de domaine , qui sont mutuellement renvoyées à la suite de requêtes. C'est le moyen le plus simple de partager la charge. Pour une description détaillée, voir Équilibrage de charge via DNS .

SLB basé sur NAT

Le soi-disant SLB basé sur NAT est plus complexe mais plus puissant . Deux réseaux doivent d'abord être mis en place ici : un réseau privé auquel appartiennent les serveurs, et un réseau public qui est connecté à l'Internet public via des routeurs . Un commutateur de contenu est connecté entre ces deux réseaux, c'est-à-dire un routeur qui accepte les requêtes du réseau public, les évalue puis décide à quel ordinateur du réseau privé transmettre la connexion. Cela se produit sur la couche réseau du modèle de référence OSI. La technologie NAT est utilisée ici : le load balancer manipule les paquets IP entrants et sortants de manière à ce que le client ait l'impression qu'il communique toujours avec un seul et même ordinateur, à savoir le load balancer. Les serveurs du réseau privé ont tous la même adresse IP virtuelle, pour ainsi dire.

Le problème avec cette méthode est que tout le trafic passe par l'équilibreur de charge, ce qui signifie que tôt ou tard, il deviendra un goulot d'étranglement s'il est trop petit ou s'il n'est pas conçu de manière redondante.

L'avantage du SLB basé sur NAT est que les serveurs individuels sont en outre protégés par l'équilibreur de charge. De nombreux fabricants de solutions d'équilibrage de charge proposent à cet effet des modules de sécurité supplémentaires, qui peuvent filtrer les attaques ou les requêtes incorrectes avant même qu'elles n'atteignent le cluster de serveurs . L'arrêt des sessions SSL et donc le soulagement du cluster de serveurs dans les fermes HTTP est un avantage de l'équilibrage de charge basé sur les serveurs qu'il ne faut pas sous-estimer.

En plus des bilans de santé actifs, nécessaires pour les autres méthodes, les bilans de santé passifs sont de plus en plus utilisés dans les grands clusters Web depuis un certain temps. Ici, le trafic de données entrant et sortant est surveillé par l'équilibreur de charge, dès qu'un ordinateur du cluster de serveurs déclenche un délai d'attente lorsqu'il répond à une requête, la même requête peut être envoyée à un autre serveur du cluster sans que le client ne s'en aperçoive.

SLB à plat

Un seul réseau est requis pour cette méthode. Les serveurs et l'équilibreur de charge doivent être connectés via un commutateur. Si le client envoie une requête (à l'équilibreur de charge), la trame Ethernet correspondante est manipulée de telle sorte qu'elle représente une requête directe du client à l'un des serveurs - l'équilibreur de charge échange sa propre adresse MAC à cet effetcontre celle du serveur à médiatiser et retransmet la trame. L'adresse IP reste inchangée. Cette procédure est également appelée MAT (MAC Address Translation). Le serveur qui a reçu la trame envoie la réponse directement à l'adresse IP de l'expéditeur, c'est-à-dire le client. Le client a ainsi l'impression de ne communiquer qu'avec un seul ordinateur, à savoir le load balancer, alors que le serveur ne communique en réalité qu'avec un seul ordinateur, directement avec le client. Cette méthode est connue sous le nom de DSR (Direct Server Return).

L'avantage du SLB à plat est qu'il soulage l'équilibreur de charge. Le trafic de retour (généralement plus riche en données) s'effectue directement.

Anycast SLB

Avec la répartition de charge via anycast , tout un groupe d'ordinateurs est adressé via une seule adresse. La personne joignable par le chemin le plus court répond. Sur Internet, cela est réalisé avec BGP .

L'avantage de cette solution est la sélection géographiquement proche d'un serveur avec une réduction correspondante de la latence. Cependant, la mise en œuvre nécessite le fonctionnement d'un système autonome séparé sur Internet.

problèmes de pratique

Les applications telles que les boutiques en ligne gèrent souvent les demandes des clients via des sessions. Pour les sessions existantes z. B. le contenu du panier est enregistré. Cependant, cela suppose qu'un client pour lequel une session a déjà été ouverte communique de manière répétée avec le même serveur, à condition d'utiliser ici des sessions basées sur le client. Soit toutes les connexions d'un client doivent être routées vers le même serveur via son IP, soit l'équilibreur de charge doit pouvoir agir sur la couche application du modèle de référence OSI, par ex. B. pour extraire et évaluer les cookies et les identifiants de session des paquets afin de prendre ensuite une décision de commutation. Le transfert d'une session vers toujours le même serveur principal est appelé "affinité". En pratique, par conséquent, les commutateurs des couches 4 à 7 sont utilisés comme équilibreurs de charge. Alternativement, le problème peut également être résolu par l'application elle-même (par ex.[6]

Littérature

  • Ingo Wegener (éd.): Faits saillants de l'informatique. Springer Verlag, Berlin/Heidelberg, ISBN 978-3-642-64656-0 .
  • Hartmut Ernst : cours de base en informatique . 3e édition, Friedrich Vieweg & Sohn, Wiesbaden 2003, ISBN 978-3-528-25717-0 .
  • Paul J. Kühn : Communication dans les systèmes distribués. Springer Verlag, Berlin/Heidelberg 1989, ISBN 978-3-540-50893-9 .
  • Bernd Bundschuh, Peter Sokolowsky : Structures informatiques et architectures informatiques. Friedrich Vieweg & Sohn Verlag, Wiesbaden 1988, ISBN 978-3-528-04389-6 .

les détails

  1. ^ un b Sanders Peter, Dietzfelbinger Martin, Dementiev Roman : Algorithmes séquentiels et parallèles et structures de données : la boîte à outils de base . Editeur : Springer. 2019, ISBN 978-3-03025209-0 .
  2. Qi Liu, Weidong Cai, Dandan Jin et Jian Shen : Précision d'estimation sur le temps d'exécution de tâches d'exécution dans un environnement distribué hétérogène . Dans : Capteurs . 30 août 2016, ISSN  1424-8220 , p. 1386 , doi : 10.3390/s16091386 , PMID 27589753 (anglais).
  3. Alakeel, Ali : Un guide pour l'équilibrage de charge dynamique dans les systèmes informatiques distribués . Dans : International Journal of Computer Science and Network Security, (IJCSNS) . Volume 10, novembre 2009 (anglais, researchgate.net ).
  4. Asghar Sajjad, Aubanel Eric, Bremner David : Un Solveur SAT Parallèle Basé sur la Planification de Travail Dynamique . En : 2013 42e Conférence internationale sur le traitement parallèle . octobre 2013, p. 110–119 , doi : 10.1109/ICPP.2013.20 ( ieee.org ).
  5. G Punetha, N Gnanambigai, P Dinadayalan : Enquête sur la tolérance aux pannes — Algorithmes d'équilibrage de charge dans le cloud computing . Dans : IEEE (éd.) : 2015 2nd International Conference on Electronics and Communication Systems (ICECS) . 2015, ISBN 978-1-4799-7225-8 , doi : 10.1109/ecs.2015.7124879 .
  6. Shared Session Management ( Memento du 23 mai 2011 aux archives Internet ) Récupéré le 3 juin 2011.

liens web