Priorité des nœuds Erlang

Question

En supposant que j'ai un cluster de nœuds n Erlang, dont certains peuvent être sur mon réseau local, tandis que d'autres peuvent être connectés en utilisant un WAN (c'est-à-dire via Internet), quels sont les mécanismes appropriés pour) disponibilité/comportement de bande passante différente (par exemple, latence induite) et b) nœuds avec une puissance de calcul différente (ou même des contraintes de mémoire d'ailleurs)? En d'autres termes, comment hiérarchiser les nœuds locaux qui ont beaucoup de puissance de calcul, sur ceux qui ont une latence élevée et peuvent être moins puissants, ou comment je donnerais la priorité aux nœuds distants haute performance avec des latences de transmission élevées pour spécifiquement faire ces processus avec un rapport calculs/transmission relativement grand (c'est-à-dire, travail accompli par message, par unité de temps)? Je pense principalement à l'évaluation comparative de chaque nœud dans un cluster en leur envoyant un processus de test à exécuter pendant l'initialisation, afin de calculer les latences impliquées dans le messaging, ainsi que la vitesse de calcul globale (c'est-à-dire , en utilisant une minuterie spécifique au noeud pour déterminer la vitesse à laquelle un noeud se termine avec une tâche). Probablement, quelque chose comme ça devrait être fait à plusieurs reprises, d'une part pour obtenir des données représentatives (c'est-à-dire, pour moyenniser des données) et d'autre part, il pourrait même être utile au moment de l'exécution pour être capable de s'adapter dynamiquement aux conditions d'exécution changeantes.

(Dans le même sens, on voudrait probablement donner la priorité en cours d'exécution au niveau local nœuds sur ceux en cours d'exécution sur d'autres machines)

Ce serait destiné à optimiser l'espérons expédition du travail interne de sorte que les noeuds spécifiques traitent des tâches spécifiques.

Answer 1

Nous avons fait quelque chose de similaire à cela, sur notre LAN/WAN interne seulement (WAN étant par exemple San Francisco à Londres).Le problème bouillie vers le bas à une combinaison de ces facteurs:

1. la tête en faisant simplement un appel à distance sur un réseau local (interne) appeler
2. la latence du réseau au noeud (en fonction de la demande/résultat charge utile)
3. les performances du nœud distant
4. la puissance de calcul nécessaire pour exécuter la fonction
5. Que des appels offre batching une amélioration de la performance s'il y avait un partage des données « statiques » set.

Pour 1. Nous avons supposé pas de frais généraux (il était négligeable par rapport aux autres)

Pour 2. Nous avons mesuré activement à l'aide de messages de sonde pour mesurer le temps aller-retour, et nous collationnés l'information des appels réels effectués

pour 3. nous avons mesuré sur le nœud et les avait diffusé cette information (cela a changé en fonction de la charge de courant actif sur le nœud)

pour 4 et 5. nous avons travaillé dehors empiriquement pour le lot donné

Ensuite, l'appelant a résolu la question de la solution minimale pour un lot d'appels (dans notre cas, il a évalué tout un tas de dérivés) et les a renvoyés aux nœuds par lots.

Nous avons obtenu une bien meilleure utilisation de notre calcul "grid" en utilisant cette technique mais cela demandait pas mal d'efforts. Nous avions l'avantage supplémentaire que la grille n'était utilisée que par cet environnement, donc nous avions beaucoup plus de contrôle. L'ajout d'un mix Internet (latence variable) et d'autres utilisateurs de la grille (performance variable) ne ferait qu'accroître la complexité avec des rendements décroissants possibles ...

Answer 2

Le problème dont vous parlez a été abordé de nombreuses manières différentes dans le contexte de l'informatique en grille (par exemple, voir Condor). Pour en discuter plus en détail, je pense que des informations supplémentaires sont nécessaires (homogénéité des problèmes à résoudre, degré de contrôle sur les nœuds [c'est-à-dire, charge externe inattendue, etc.?]).

La mise en œuvre d'un répartiteur de travail adaptatif nécessite généralement également d'ajuster la fréquence avec laquelle vous sonder les ressources disponibles (sinon le temps système dû au sondage pourrait dépasser les gains de performance). Idéalement, vous pourriez utiliser des tests de référence pour trouver un modèle empirique (statistique) qui vous permet de prédire la dureté de calcul d'un problème donné (nécessite une bonne connaissance du domaine et des caractéristiques problématiques qui ont un impact important sur vitesse d'exécution et sont simples à extraire), et un autre pour prédire les frais généraux de communication. Utiliser les deux en combinaison devrait permettre de mettre en œuvre un simple répartiteur qui fonde ses décisions sur les modèles prédictifs et les améliore en prenant en compte les temps d'exécution réels comme retour/récompense (par exemple, via reinforcement learning).