Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
Orleans garantit que lorsqu’un appel de grain est effectué, une instance de ce grain est disponible en mémoire sur un serveur du cluster pour gérer la requête. Si le grain n’est actuellement pas actif dans le cluster, Orleans sélectionne un serveur sur lequel activer le grain. Ce processus est appelé placement des grains. Le placement est également un moyen Orleans d’équilibrer la charge : en plaçant uniformément les grains occupés, on aide à distribuer la charge de travail sur le cluster.
Le processus de placement dans Orleans est entièrement configurable. Choisissez parmi les stratégies de placement prêtes à l’emploi, telles que aléatoires, plutôt locales et basées sur la charge, ou configurez une logique personnalisée. Cela permet une flexibilité totale pour décider où les grains sont créés. Par exemple, placez des grains sur un serveur près des ressources dont ils ont besoin pour fonctionner ou près d’autres grains avec lesquels ils communiquent.
Note
À compter de Orleans la version 9.2, la stratégie de placement par défaut est passée du placement aléatoire au placement optimisé pour les ressources. Cela offre une meilleure distribution de charge basée sur l’utilisation du processeur et de la mémoire sur les silos. Si vous avez besoin du comportement de placement aléatoire précédent, configurez-le explicitement comme décrit dans Configurer la stratégie de placement par défaut.
Par défaut, Orleans choisit un serveur compatible aléatoire.
Configurez la stratégie Orleans de placement à l’échelle mondiale ou par classe de grain.
Placement optimisé pour les ressources (valeur par défaut)
Note
À partir de la version Orleans 9.2, le placement optimisé en fonction des ressources devient la stratégie de placement par défaut. Vous n’avez pas besoin de le configurer explicitement, sauf si vous souhaitez personnaliser les options.
Pour utiliser un placement optimisé pour les ressources, ajoutez le ResourceOptimizedPlacementAttribute à votre classe de grains.
Le placement optimisé des ressources n’est pas disponible dans cette version de Orleans. Envisagez de mettre à niveau vers Orleans la version 8.1 ou ultérieure pour utiliser cette fonctionnalité.
La stratégie de placement optimisé des ressources tente d'optimiser les ressources du cluster en équilibrant les activations de grains entre les silos en fonction de la mémoire disponible et de l'utilisation du processeur. Il affecte des pondérations aux statistiques d’exécution pour hiérarchiser différentes ressources et calcule un score normalisé pour chaque silo. Le silo avec le score le plus bas est choisi pour placer l’activation à venir. La normalisation garantit que chaque propriété contribue proportionnellement au score global. Ajustez les pondérations via ResourceOptimizedPlacementOptions en fonction des exigences et des priorités spécifiques pour les différentes ressources.
En outre, cette stratégie de placement expose une option permettant de créer une préférence plus forte pour le silo local (celui qui reçoit la demande pour effectuer un nouveau placement) à choisir comme cible pour l’activation. Contrôlez cela via la LocalSiloPreferenceMargin propriété, une partie des options.
En outre, un algorithme en ligneadaptatif offre un effet de lissage qui évite les chutes rapides de signal en transformant le signal en un processus de décroissance de type polynomial. Cela est particulièrement important pour l’utilisation du processeur et contribue globalement à éviter la saturation des ressources sur les silos, en particulier les nouveaux joints.
Cet algorithme est basé sur le placement basé sur les ressources avec le filtrage Kalman en double mode coopératif.
Configurez cette stratégie de placement en ajoutant le ResourceOptimizedPlacementAttribute à la classe de grain.
Options de placement optimisées des ressources
Configurez la stratégie de placement optimisée pour les ressources en utilisant ResourceOptimizedPlacementOptions :
siloBuilder.Configure<ResourceOptimizedPlacementOptions>(options =>
{
options.CpuUsageWeight = 40;
options.MemoryUsageWeight = 20;
options.AvailableMemoryWeight = 20;
options.MaxAvailableMemoryWeight = 5;
options.ActivationCountWeight = 15;
options.LocalSiloPreferenceMargin = 5;
});
| Choix | Type | Par défaut | Descriptif |
|---|---|---|---|
CpuUsageWeight |
int |
40 | Importance de l’utilisation du processeur. Les valeurs plus élevées favorisent les silos avec une utilisation inférieure du processeur. Plage valide : 0-100. |
MemoryUsageWeight |
int |
20 | Importance de l’utilisation de la mémoire. Les valeurs plus élevées privilégient les silos avec une utilisation inférieure de la mémoire. Plage valide : 0-100. |
AvailableMemoryWeight |
int |
20 | Importance de la mémoire disponible. Les valeurs plus élevées favorisent les silos avec une mémoire plus disponible. Plage valide : 0-100. |
MaxAvailableMemoryWeight |
int |
5 | Importance de la mémoire maximale disponible. Les valeurs plus élevées favorisent les silos avec une capacité de mémoire physique plus élevée. Utile dans les clusters avec des ressources distribuées inégalement. Plage valide : 0-100. |
ActivationCountWeight |
int |
15 | Importance du nombre d’activations. Les valeurs plus élevées favorisent les silos avec moins de grains actifs. Plage valide : 0-100. |
LocalSiloPreferenceMargin |
int |
5 | Marge pour préférer le silo local. Lorsque la valeur est définie sur 0, sélectionne toujours le silo avec une utilisation la plus faible. Lorsqu’il est défini sur 100, préfère toujours le silo local (équivalent à PreferLocalPlacement). Recommandé : 5-10. Plage valide : 0-100. |
Note
Les valeurs de poids n’ont pas besoin de se résumer à 100. Orleans les normalise automatiquement, de sorte qu’elles représentent une importance relative plutôt que des pourcentages absolus.
Placement aléatoire
Orleans sélectionne de façon aléatoire un serveur parmi les serveurs compatibles dans le cluster. Pour configurer cette stratégie de placement, ajoutez RandomPlacementAttribute à la classe de grain.
Placement local
Si le serveur local est compatible, Orleans sélectionne le serveur local ; sinon, il sélectionne un serveur aléatoire. Configurez cette stratégie de placement en ajoutant le PreferLocalPlacementAttribute à la classe de grain.
Positionnement basé sur le hachage
Orleans hache l'ID de grain en un entier non négatif et applique une opération modulo avec le nombre de serveurs compatibles. Il sélectionne ensuite le serveur correspondant dans la liste des serveurs compatibles classés par adresse du serveur. Notez que ce placement n’est pas garanti pour rester stable à mesure que l’appartenance au cluster change. Plus précisément, l’ajout, la suppression ou le redémarrage de serveurs peuvent modifier le serveur sélectionné pour un ID de grain donné. Étant donné que les grains placés à l’aide de cette stratégie s’inscrivent dans le répertoire des grains, ce changement dans la prise de décision à mesure que l'appartenance change n’a généralement pas d’effet notable.
Configurez cette stratégie de placement en ajoutant le HashBasedPlacementAttribute à la classe de grain.
Placement basé sur le nombre d’activations
Cette stratégie de placement tente de placer de nouvelles activations de grain sur le serveur le moins chargé en fonction du nombre de grains récemment occupés. Il inclut un mécanisme dans lequel tous les serveurs publient régulièrement leur nombre total d’activations sur tous les autres serveurs. Le directeur de placement sélectionne ensuite un serveur qui devrait avoir le moins d'activations en examinant le nombre d'activations le plus récemment signalé et en prédisant le nombre actuel en se basant sur les activations récentes effectuées par le directeur de placement sur le serveur actuel. Le directeur sélectionne plusieurs serveurs de façon aléatoire lors de cette prédiction pour éviter plusieurs serveurs distincts surchargés sur le même serveur. Par défaut, deux serveurs sont sélectionnés de manière aléatoire, mais cette valeur peut être configurée via ActivationCountBasedPlacementOptions.
Cet algorithme est basé sur la thèse Le Pouvoir de Deux Choix dans l'Équilibrage de Charge Aléatoire de Michael David Mitzenmacher. Il est également utilisé dans Nginx pour l’équilibrage de charge distribué, comme décrit dans l’article NGINX et la « puissance de deux choix » Load-Balancing Algorithme.
Configurez cette stratégie de placement en ajoutant le ActivationCountBasedPlacementAttribute à la classe de grain.
Placement des workers sans état
Il s'agit d'une stratégie de placement spéciale utilisée par les grains de worker sans état. Ce placement fonctionne presque de la même façon que PreferLocalPlacement, sauf que chaque serveur peut avoir plusieurs activations du même grain, et le grain n’est pas inscrit dans le répertoire des grains, car il n’y a pas besoin.
Configurez cette stratégie de placement en ajoutant le StatelessWorkerAttribute à la classe de grain.
Placement en fonction du rôle de silo
Il s’agit d’une stratégie de placement déterministe plaçant des grains sur des silos avec un rôle spécifique. Configurez cette stratégie de placement en ajoutant le SiloRoleBasedPlacementAttribute à la classe de grain.
Choisir une stratégie de placement
Le choix de la stratégie appropriée de placement des grains, au-delà des Orleans valeurs par défaut, nécessite une surveillance et une évaluation. Le choix doit être basé sur la taille et la complexité de l’application, les caractéristiques de charge de travail et l’environnement de déploiement.
Le placement aléatoire s’appuie sur la loi des grands nombres, de sorte qu’il s’agit généralement d’une bonne valeur par défaut pour les charges imprévisibles réparties sur de nombreux grains (10 000 ou plus).
Le placement basé sur le nombre d’activations a également un élément aléatoire, en s’appuyant sur le principe Power of Two Choices. Il s’agit d’un algorithme couramment utilisé pour l’équilibrage de charge distribué et est utilisé dans les équilibreurs de charge populaires. Les silos publient fréquemment des statistiques d’exécution sur d’autres silos du cluster, notamment :
- Mémoire disponible, mémoire physique totale et utilisation de la mémoire.
- Utilisation du processeur.
- Nombre total d’activations et nombre d’activations actives récentes.
- Fenêtre glissante des activations au cours des dernières secondes, parfois appelée ensemble de travail d’activation.
À partir de ces statistiques, seuls les nombres d’activations sont actuellement utilisés pour déterminer la charge sur un silo donné.
En fin de compte, testez différentes stratégies et surveillez les métriques de performances pour déterminer le meilleur ajustement. La sélection de la stratégie de placement des grains appropriée optimise les performances, l’évolutivité et l’efficacité des Orleans applications.
Configurer la stratégie de placement par défaut
À partir de la version Orleans9.2, Orleans utilise par défaut le placement optimisé pour les ressources. Remplacez la stratégie de placement par défaut en inscrivant une implémentation lors de PlacementStrategy la configuration.
Pour revenir au comportement de placement aléatoire précédent :
siloBuilder.Services.AddSingleton<PlacementStrategy, RandomPlacement>();
Pour utiliser une stratégie de placement personnalisée :
siloBuilder.Services.AddSingleton<PlacementStrategy, MyPlacementStrategy>();
Orleans utilise un placement aléatoire, sauf si la valeur par défaut est remplacée. Remplacez la stratégie de placement par défaut en inscrivant une implémentation de PlacementStrategy lors de la configuration :
siloBuilder.Services.AddSingleton<PlacementStrategy, MyPlacementStrategy>();
Orleans utilise un placement aléatoire, sauf si la valeur par défaut est remplacée. Remplacez la stratégie de placement par défaut en inscrivant une implémentation de PlacementStrategy lors de la configuration :
siloBuilder.ConfigureServices(services =>
services.AddSingleton<PlacementStrategy, MyPlacementStrategy>());
Configurer la stratégie de placement d’un grain
Configurez la stratégie de placement pour un type de grain en ajoutant l’attribut approprié à la classe de grain. Les attributs pertinents sont spécifiés dans les sections des stratégies de placement ci-dessus.
Exemple de stratégie de placement personnalisée
Tout d’abord, définissez une classe implémentant l’interface IPlacementDirector , nécessitant une seule méthode. Dans cet exemple, supposons qu’une fonction GetSiloNumber est définie qui retourne un nombre de silo en fonction Guid du grain sur le point d’être créé.
public class SamplePlacementStrategyFixedSiloDirector : IPlacementDirector
{
public Task<SiloAddress> OnAddActivation(
PlacementStrategy strategy,
PlacementTarget target,
IPlacementContext context)
{
var silos = context.GetCompatibleSilos(target).OrderBy(s => s).ToArray();
int silo = GetSiloNumber(target.GrainIdentity.PrimaryKey, silos.Length);
return Task.FromResult(silos[silo]);
}
}
Ensuite, définissez deux classes pour permettre l’affectation de classes de grain à la stratégie :
[Serializable]
public sealed class SamplePlacementStrategy : PlacementStrategy
{
}
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
public sealed class SamplePlacementStrategyAttribute : PlacementAttribute
{
public SamplePlacementStrategyAttribute() :
base(new SamplePlacementStrategy())
{
}
}
Ensuite, balisez toutes les classes de grain destinées à utiliser cette stratégie avec l’attribut :
[SamplePlacementStrategy]
public class MyGrain : Grain, IMyGrain
{
// ...
}
Enfin, inscrivez la stratégie lors de la création du ISiloHost:
private static async Task<ISiloHost> StartSilo()
{
var builder = new HostBuilder(c =>
{
// normal configuration methods omitted for brevity
c.ConfigureServices(ConfigureServices);
});
var host = builder.Build();
await host.StartAsync();
return host;
}
private static void ConfigureServices(IServiceCollection services)
{
services.AddPlacementDirector<SamplePlacementStrategy, SamplePlacementStrategyFixedSiloDirector>();
}
Pour obtenir un deuxième exemple simple montrant une utilisation supplémentaire du contexte de placement, reportez-vous au PreferLocalPlacementDirectorOrleans référentiel source.
Filtrage de positionnement
Le filtrage de placement vous permet de filtrer les silos qui sont éligibles pour le placement des grains avant que la stratégie de placement sélectionne une cible. Cela fonctionne conjointement avec les stratégies de placement et active des scénarios tels que :
- Placement sensible à la zone : placer les grains dans des silos dans la même zone de disponibilité
- Déploiements hiérarchisé : diriger certains grains vers des silos de niveau Premium ou standard
- Affinité matérielle : placer des grains gourmands en ressources de calcul sur des silos avec des fonctionnalités spécifiques
Orleans fournit des filtres intégrés basés sur des métadonnées de silo, notamment le filtrage de correspondance obligatoire et de correspondance par défaut. Vous pouvez également implémenter des filtres de placement personnalisés.
Pour plus d’informations sur la configuration des métadonnées de silo, à l’aide de filtres intégrés et de l’implémentation de filtres personnalisés, consultez filtrage de placement des grains.
Repartitionnement d’activation
Le répartitionnement des activations est une fonctionnalité qui optimise automatiquement la localisation des appels de grain en migrant les activations pour les rapprocher des grains avec lesquels elles communiquent le plus fréquemment. Cette fonctionnalité peut améliorer considérablement les performances en réduisant les sauts de réseau pour la communication inter-grains.
Avertissement
Le repartitionnement d’activation est une fonctionnalité expérimentale. Utilisez la #pragma warning disable ORLEANSEXP001 directive ou ajoutez <NoWarn>ORLEANSEXP001</NoWarn> à votre fichier projet pour supprimer l’avertissement expérimental.
Fonctionnement
Le repartitionneur surveille les modèles de communication grain à grain et crée un graphique de « arêtes » représentant la fréquence à laquelle les grains communiquent. Régulièrement, il analyse ce graphique pour identifier les opportunités d’améliorer la localité en migrant des grains vers des silos où se trouvent leurs partenaires de communication, tout en conservant une distribution approximativement égale des activations entre les silos.
Principales caractéristiques :
- Suivi probabiliste : utilise une structure de données probabiliste pour suivre les liens de communication les plus lourds tout en conservant la mémoire
- Distribution équilibrée : tentatives de maintien du nombre d’activations équilibrés entre les silos
- Période de récupération : après la migration des grains, un silo attend avant de participer à un autre tour de repartitionnement pour permettre au système de se stabiliser
- Filtre d’ancrage : identifie les grains bien partitionnés (ceux qui sont déjà proches de leurs partenaires de communication) et évite de les migrer
Activer le repartitionnement d’activation
Activez la répartition de l'activation à l'aide de la méthode d'extension AddActivationRepartitioner :
#pragma warning disable ORLEANSEXP001
siloBuilder.AddActivationRepartitioner();
#pragma warning restore ORLEANSEXP001
Options de configuration
Configurez le repartitionneur à l’aide de ActivationRepartitionerOptions :
#pragma warning disable ORLEANSEXP001
siloBuilder.AddActivationRepartitioner();
siloBuilder.Configure<ActivationRepartitionerOptions>(options =>
{
options.MaxEdgeCount = 10_000;
options.MinRoundPeriod = TimeSpan.FromMinutes(1);
options.MaxRoundPeriod = TimeSpan.FromMinutes(2);
options.RecoveryPeriod = TimeSpan.FromMinutes(1);
options.AnchoringFilterEnabled = true;
});
#pragma warning restore ORLEANSEXP001
| Choix | Type | Par défaut | Descriptif |
|---|---|---|---|
MaxEdgeCount |
int |
10 000 | Nombre maximal de bords (liens de communication grain) à suivre. Les valeurs plus élevées améliorent la précision, mais utilisent plus de mémoire. Les valeurs inférieures à 100 ne sont pas recommandées. |
MaxUnprocessedEdges |
int |
100 000 | Nombre maximal de bords non traités à mettre en mémoire tampon. Les arêtes les plus anciennes sont supprimées lorsqu’elles sont dépassées. |
MinRoundPeriod |
TimeSpan | Une minute | Durée minimale entre les cycles de repartitionnement. |
MaxRoundPeriod |
TimeSpan | 2 minutes | Durée maximale entre les cycles de réagencement. Le minutage réel est aléatoire entre min et max. Pour obtenir des résultats optimaux, visez environ 10 secondes multipliées par le nombre maximal de silos. |
RecoveryPeriod |
TimeSpan | Une minute | Durée d’attente d’un silo après un cycle de repartitionnement avant de participer à un autre. Doit être inférieur ou égal à MinRoundPeriod. |
AnchoringFilterEnabled |
bool |
true |
Permet le suivi des grains bien partitionnés pour éviter de les migrer inutilement. Réduit légèrement la précision, mais améliore l’efficacité. |
ProbabilisticFilteringMaxAllowedErrorRate |
double |
0,01 | Taux d’erreur maximal pour le filtre probabiliste (0,1% à 1 plage de%). S’applique uniquement quand AnchoringFilterEnabled est true. |
Considérations relatives aux performances
-
Temps de convergence : le repartitionneur améliore progressivement la localité au cours de plusieurs itérations. Si le système ne converge pas assez rapidement, envisagez d’augmenter
MaxEdgeCount. -
Utilisation de la mémoire : les valeurs supérieures
MaxEdgeCountconsomment plus de mémoire. La structure de données probabiliste permet de limiter l’utilisation de la mémoire tout en conservant une précision raisonnable. -
Stabilité du cluster : Évitez les valeurs très courtes
RecoveryPeriodpour éviter une migration excessive des grains. - Modèles de charge de travail : fonctionne mieux avec les charges de travail qui ont des modèles de communication stables. Les charges de travail hautement dynamiques peuvent voir moins d’avantages.
Quand utiliser la répartition des activations
Envisagez d'activer la répartition de l'activation lorsque :
- Vos grains ont des modèles de communication prévisibles (grain A appelle fréquemment le grain B)
- Vous disposez d’un cluster multi-silo où la latence réseau entre les silos est importante
- L’évaluation montre un débit amélioré avec la fonctionnalité activée
Évitez le répartitionnement des activations quand :
- Les grains communiquent de manière aléatoire avec de nombreux grains différents
- Votre cluster est petit (2 à 3 silos) où la surcharge de migration peut dépasser les avantages
- Les grains se désactivent et se réactivent fréquemment, ce qui empêche l’émergence de modèles stables.
Le repartitionnement d'activations a été introduit en tant que fonctionnalité expérimentale dans la version Orleans 8.2. Pour obtenir la documentation la plus récente sur cette fonctionnalité, consultez la Orleans documentation 9.0+.
Le repartitionnement d’activation est disponible dans la Orleans version 8.2 et ultérieure.
Rééquilibrage de l’activation
Le rééquilibrage de l’activation est une fonctionnalité à l’échelle du cluster qui redistribue automatiquement les activations de grain entre les silos afin d’optimiser l’utilisation de la mémoire et l’équilibre du nombre d’activations . Contrairement au repartitionnement d’activation (qui optimise la localité de communication), le rééquilibrage se concentre sur le maintien des silos uniformément chargés en termes de consommation de ressources.
Avertissement
Le rééquilibrage de l'activation est une fonctionnalité en phase expérimentale. Utilisez la #pragma warning disable ORLEANSEXP002 directive ou ajoutez <NoWarn>ORLEANSEXP002</NoWarn> à votre fichier projet pour supprimer l’avertissement expérimental.
Fonctionnement
Le rééquilibreur d’activation s’exécute en tant que grain unique qui coordonne le rééquilibrage au sein du cluster.
- Collection de statistiques : chaque silo publie régulièrement son nombre d’activations et l’utilisation de la mémoire vers le rééquilibreur.
- Calcul d’entropie : le rééquilibrage calcule l’entropie actuelle du cluster, une mesure de la façon dont les ressources distribuées uniformément sont. L’entropie maximale signifie un équilibre parfait.
- Décisions de migration : lorsque l’entropie est inférieure à la cible, le rééquilibrage identifie les silos « lourds » (nombre élevé de mémoire/d’activation) et les silos « légers », puis indique aux silos lourds de migrer les activations vers des silos légers.
- Exécution basée sur une session : rééquilibrage s’exécute dans des sessions avec plusieurs cycles. Une session se termine lorsque le cluster atteint un solde acceptable ou lorsqu’aucune autre amélioration n’est détectée.
L’algorithme considère à la fois la consommation de mémoire et le nombre d’activations, en utilisant la moyenne harmonique de l’utilisation de la mémoire pour calculer la distribution idéale de l’activation. Cela signifie que les silos avec moins de mémoire disponible reçoivent moins d’activations.
Activer le rééquilibrage de l’activation
Activez le rééquilibrage de l’activation en utilisant la méthode d'extension AddActivationRebalancer :
#pragma warning disable ORLEANSEXP002
siloBuilder.AddActivationRebalancer();
#pragma warning restore ORLEANSEXP002
Options de configuration
Configurez le rééquilibrage à l’aide de ActivationRebalancerOptions:
#pragma warning disable ORLEANSEXP002
siloBuilder.AddActivationRebalancer();
siloBuilder.Configure<ActivationRebalancerOptions>(options =>
{
options.RebalancerDueTime = TimeSpan.FromSeconds(60);
options.SessionCyclePeriod = TimeSpan.FromSeconds(15);
options.MaxStagnantCycles = 3;
});
#pragma warning restore ORLEANSEXP002
| Choix | Type | Par défaut | Descriptif |
|---|---|---|---|
RebalancerDueTime |
TimeSpan | 60 secondes | Délai initial avant le début de la première session de rééquilibrage après la stabilisation du cluster. |
SessionCyclePeriod |
TimeSpan | 15 secondes | Temps entre les cycles de rééquilibrage au sein d’une session. Doit être au moins deux fois l’intervalle de publication des statistiques. |
MaxStagnantCycles |
int |
3 | Nombre maximal de cycles consécutifs sans amélioration avant la fin d’une session. |
EntropyQuantum |
double |
0.0001 | Un changement minimal d’entropie a été considéré comme une amélioration. Les valeurs plus petites rendent le rééquilibrage plus sensible. |
AllowedEntropyDeviation |
double |
0.0001 | Seuil de base pour l’écart acceptable par rapport à l’entropie maximale. Lorsque l’écart est inférieur à ce seuil, le cluster est considéré comme équilibré. |
ScaleAllowedEntropyDeviation |
bool |
true |
Indique s’il faut mettre à l’échelle dynamiquement l’écart autorisé en fonction de la taille du cluster et du nombre d’activations. |
CycleNumberWeight |
double |
0.1 | Facteur de poids pour le nombre de cycles dans le calcul du taux de migration. Des valeurs plus élevées accélèrent la migration dans les cycles ultérieurs. |
SiloNumberWeight |
double |
0.1 | Facteur de poids pour le nombre de silos dans le calcul du taux de migration. Des valeurs plus élevées entraînent la migration d'un plus grand nombre d'activations vers des clusters plus grands. |
ActivationMigrationCountLimit |
int |
int.MaxValue | Nombre maximal d’activations à migrer dans un seul cycle. Permet de limiter le taux de migration. |
Spécifications
- Taille minimale du cluster : nécessite au moins 2 silos pour fonctionner.
- Statistiques de mémoire : chaque silo doit signaler l’utilisation de la mémoire valide (non zéro). Si un silo signale zéro mémoire, les cycles de rééquilibrage sont ignorés.
-
Migratabilité des grains : grains marqués avec
[Immovable]ou[Immovable(ImmovableKind.Rebalancer)]exclus du rééquilibrage.
Quand utiliser le rééquilibrage de l’activation
Envisagez d’activer le rééquilibrage d'activation lorsque :
- Votre cluster a des silos avec une répartition inégale des ressources (certains silos étant surchargés tandis que d'autres sont sous-utilisés)
- Vous avez des activations de grain de longue durée qui peuvent s’accumuler de façon inégale au fil du temps
- Vos modèles de charge de travail provoquent des déséquilibres d’activation que les stratégies de placement seules ne peuvent pas traiter
Évitez le rééquilibrage de l’activation dans les cas suivants :
- Votre cluster est petit (2 à 3 silos) où la surcharge peut dépasser les avantages
- Les grains ont des durées de vie très courtes et désactivent rapidement
- Vous utilisez déjà le repartitionnement d’activation et souhaitez éviter des migrations conflictuelles, même si les deux fonctionnalités peuvent coexister. Le repartitionneur ajuste en effet son comportement en fonction des rapports de rééquilibrage.
Comparaison avec le repartitionnement de l’activation
| Caractéristique | Rééquilibrage de l’activation | Repartitionnement d’activation |
|---|---|---|
| Optimisations pour | Équilibre de la mémoire et du nombre d'activations | Localité de communication |
| Étendue | Coordination à l’échelle du cluster | Coordination de silos par paires |
| ID expérimental | ORLEANSEXP002 |
ORLEANSEXP001 |
| Déclencheur de migration | Déséquilibre des ressources | Modèles de communication |
Les deux fonctionnalités peuvent être activées simultanément. Le repartitionneur ajuste automatiquement sa tolérance en fonction du déséquilibre du cluster signalé par le rééquilibrage.
Le rééquilibrage de l’activation est disponible dans Orleans 10.0 et plus.