Partage via


Vue d’ensemble des silos hétérogènes

Sur un cluster donné, les silos peuvent prendre en charge différents ensembles de types de grains :

Diagramme de vue d’ensemble des silos hétérogènes.

Dans cet exemple, le cluster prend en charge les grains de type A, , BC, D, et E:

  • Les types de grains A et B peuvent être placés dans les silos 1 et 2.
  • Le type C de grain peut être placé sur silo 1, 2 ou 3.
  • Le type D de grain ne peut être placé que sur Silo 3.
  • Le type E de grain ne peut être placé que sur Silo 4.

Tous les silos doivent référencer les interfaces de tous les types de grain dans le cluster, mais les classes de grain ne doivent être référencées que par les silos qui les hébergent. Le client ne sait pas quel silo prend en charge un type de grain donné.

Important

Une implémentation de type de grain donnée doit être la même sur chaque silo qui la prend en charge.

Le scénario suivant n’est pas valide :

Sur Silo 1 et 2 :

public class C: Grain, IMyGrainInterface
{
   public Task SomeMethod() { /* ... */ }
}

Sur Silo 3 :

public class C: Grain, IMyGrainInterface, IMyOtherGrainInterface
{
   public Task SomeMethod() { /* ... */ }
   public Task SomeOtherMethod() { /* ... */ }
}

Paramétrage

Aucune configuration n’est nécessaire ; vous pouvez déployer différents fichiers binaires sur chaque silo de votre cluster. Toutefois, si nécessaire, vous pouvez modifier la fréquence à laquelle les silos et les clients recherchent les modifications dans les types pris en charge à l’aide de la propriété TypeManagementOptions.TypeMapRefreshInterval.

À des fins de test, vous pouvez utiliser la GrainClassOptions.ExcludedGrainTypes propriété, qui est une liste de noms des types que vous souhaitez exclure sur des silos spécifiques.

Limites

  • Les clients connectés ne sont pas avertis si l’ensemble des types de grains pris en charge change. Dans l’exemple précédent :
    • Si Silo 4 quitte le cluster, le client tente toujours d’effectuer des appels à des grains de type E. Il échoue au moment de l’exécution avec un OrleansException.
    • Si le client est connecté au cluster avant que Silo 4 ne soit joint, le client ne peut pas effectuer d’appels aux grains de type E. Cela échoue avec un ArgumentException.
  • Les grains sans état ne sont pas pris en charge dans les déploiements hétérogènes : tous les silos du cluster doivent prendre en charge le même ensemble de grains sans état.
  • ImplicitStreamSubscriptionAttribute n’est pas pris en charge ; Ainsi, vous pouvez uniquement utiliser des abonnements explicites dans Orleans des flux avec des silos hétérogènes.