Situations de reprise en cas de panne

Sur Sun Cluster, on peut configurer Solaris Resource Manager de sorte que la méthode heuristique pour l'attribution des ressources qui est décrite dans la base de données des limites ( /var/srm/srmDB) demeure inchangée en cas de fonctionnement normal de la grappe ainsi que dans les cas de commutation et de reprise.

Passez en revue les exemples suivants.

Grappe à deux noeuds avec deux applications

Vous pouvez configurer deux applications dans une grappe à deux noeuds, de sorte que chaque hôte matériel fasse office de maître par défaut pour une application. Chaque hôte matériel agit en qualité de noeud de secours pour l'autre hôte matériel. Toutes les applications doivent être représentées dans les fichiers de base de données des limites de Solaris Resource Manager des deux noeuds. Lorsque la grappe fonctionne normalement, chaque application tourne sur son maître par défaut, où toutes les parts lui sont attribuées (car Solaris Resource Manager attribue toutes les ressources disponibles). Lorsqu'un passage ou une reprise a lieu, les deux applications tournent sur un seul noeud, où les parts précisées dans le fichier de configuration leur sont attribuées. Par exemple, l'exemple de fichier de configuration suivant précise que lorsque les deux applications tournent sur le même noeud, 80 parts sont attribuées à l'application 1, tandis que l'application 2 reçoit 20 parts :

#limadm set cpu.shares=80 app1
#limadm set cpu.shares=20 app2
...

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.

Grappe à deux noeuds avec trois applications

Vous pouvez configurer une grappe à deux noeuds avec trois applications de sorte qu'un hôte physique ( phys-host1) soit le maître par défaut d'une application et le second hôte physique ( phys-host2) le maître par défaut des deux autres applications. Dans l'exemple suivant, supposons que le fichier de base de données des limites se trouve dans chaque noeud. Le fichier de base de données des limites ne change pas lorsqu'un passage ou une reprise a lieu :

#limadm set cpu.shares=50	 app1
#limadm set cpu.shares=30	 app2
#limadm set cpu.shares=20	 app3
...

Lorsque la grappe fonctionne normalement, l'application 1 se voit attribuer toutes les parts disponibles sur son maître par défaut, soit phys-host1. Les applications 2 et 3 reçoivent 60 et 40 parts, respectivement, sur leur maître par défaut, soit phys-host2, car une partie proportionnelle de toutes les ressources disponibles est attribuée à chaque application. Si une reprise ou un passage a lieu et si l'application 1 passe à phys-host2, les parts des trois applications sont réattribuées conformément au fichier de base de données des limites. Ainsi, l'application 1 reçoit 50 parts, l'application 2 en obtient 30 et l'application 3 recueille 20 parts.

Le schéma ci-après présente le fonctionnement normal et en cas de reprise de cette configuration.