Qu'est ce qu'un cluster ?

Son rôle principal est de permettre d'avoir dans un seul indicateur l'état agrégé d'autres états. Cet indicateur propose une vue unique pour des utilisateurs jouant différents rôles.

Rôles typiques:

• Service delivery Management

• Business Management

• Engineering

• IT support

Prenons l'exemple d'un rôle de service delivery pour une application ERP . Il est principalement constitué de:

• 2 databases, en haute disponibilité, donc avec une seule base active, le service est considéré comme rendu

• 2 web servers, en partage de charge, donc avec un web server actif, le service est considéré comme rendu

• 2 load balancers, encore en haute disponibilité

Ces composants (Hôtes dans cet exemple) seront la base de ce service ERP .

Avec des règles métier, vous pouvez avoir une vue agrégée de l'indicateur représentant l'état du service ERP !

Shinken Enterprise vérifie chaque composant un par un pour l'analyse de problème source.

Accéder à la configuration du Cluster

Logique de notification

Un Cluster a la même logique de notification que les hôtes.

Lors de la création/édition d'un Cluster, les notifications peuvent être configurées via l'onglet Notifications de la même manière que pour un hôte.

La documentation sur les notifications fournit des informations détaillées sur le sujet: Logique de notification

Définition minimaliste d'un Cluster

L'opérateur & semblable au ET classique renvoie l'état le plus bas des 2 éléments.

Par exemple, si un hôte hote_a est OK et qu'un hôte hote_b est Critique,

hote_a & hote_b

renverra Critique.

L'opérateur | semblable au OU classique renvoie l'état le plus haut des 2 éléments.

Par exemple, si un hôte hote_a est OK et qu'un hôte hote_b est Critique,

hote_a | hote_b

renverra OK.

Dans un cluster, on peut sélectionner 2 types d'éléments: des hôtes et des services.

L'état d'un hôte se récupère avec seulement le nom de l'hôte, et l'état d'un service se récupère avec le nom de l'hôte, puis le nom du service, séparé par un virgule.

Par exemple

hote_a,service_a

Aussi, il est possible de configurer la priorité des opérateurs booléens avec des parenthèses.

Exemple de configuration d'une règle pour un cluster ERP

(srv-oracle-1 | srv-oracle-2) & (srv-http-1 | srv-http-2) & (srv-loadbalancer-1 | srv-loadbalancer-2)

Utiliser les négations

On peut également vouloir vérifier qu'un hôte ou un service renvoie un statut Critique. Cela peut être utile dans le cas de configuration avec des éléments actifs et passifs par exemple.

Le caractère ! permet de prendre l'inverse de l'état de l'élément. Ainsi, on peut définir des règles comme la suivante:

(srv-oracle-1 & !srv-oracle-2)

Le cluster sera donc en statut OK si l'hôte srv-oracle-1 est OK et l'hôte srv-oracle-2 est Critical.

Groupement d'expressions

Parfois, on ne souhaite/peut pas spécifier précisément les hôtes contenus dans une règle. On peut dans les bp_rule grouper les éléments selon différents critères. On peut par exemple récupérer tous les hôtes appartenant à un certain groupe d'hôte, ayant un certain modèle d'hôte accrochés, ou encore récupérer les hôtes dont le nom remplit certains critères. Ces groupements sont disponibles également pour le checks.

Pour cela, il est possible d'utiliser des expressions groupées suivant cette syntaxe :

flag:expression

Le flag est un simple caractère qualifiant le type d'expansion.
Les types supportés sont décrits dans les tables ci-dessous.

Flags pour les hôtes

Flags pour les checks

r:/regex/

Exemple d'expressions combinées

Si vous souhaitez créer une règle incluant tous les web servers composant l'application frontend.

t:http,r:HTTPS?

qui est équivalent à:

web-srv1,HTTP & web-srv3,HTTPS

Vous devriez donc combiner l'expansion d'expression avec :

t:http,t:HTTPS? & db-srv1,MySQL

qui est équivalent à:

(web-srv1,HTTP & web-srv3,HTTPS) & db-srv1,MySQL

Ensembles d'éléments

On voudrait également pouvoir sélectionner les éléments qui remplissent plusieurs critères différents. C'est possible en définissant des ensembles.

Les ensembles sont définis en enveloppant une expression de crochets:

[ definition de l'ensemble ]

Dans les ensembles, les opérations booléennes & et | n'existent pas, et sont remplacées par <and> et <or>. Le tableau ci-dessous récapitule les significations des différents opérateurs dans les ensembles.

Les ensembles peuvent être imbriqués pour permettre des définir des priorités d'évaluation.
Les opérateurs sont évalués dans l'ordre des sous parties, puis de gauche à droite.

 Ainsi, l'expression 

[ t:linux <or> tr:windows.* <and not> [t:linux <and> tr:windows.* ]]

regroupe les hôtes ayant le modèle linux, ou un modèle commençant par windows, mais pas les deux.

La règle Xof

Dans certains cas, un cluster de N éléments nécessite d'avoir au moins X d'entre eux en état OK pour être considéré comme OK.

Pour spécifier ce type de comportement, il suffit d'utiliser l'opérateur "X of:".

La syntaxe de cet opérateur est la suivante:

Xof: expression

L'expression X of: peut être configurée avec différentes valeurs en fonction du besoin. Les valeurs supportées pour X sont les suivantes:

(srv-oracle-1 | srv-oracle-2) & (srv-loadbalancer-1 | srv-loadbalancer-2) & 95% of: g:frontend

90% of: [ t:linux <or> tr:windows.* <and not> [t:linux <and> tr:windows.* ]]

Gérer un état dégradé

L'opérateur Xof permet de gérer un état du cluster en se basant sur les états OK et Critical des éléments. Il renvoie également un status OK ou Critique selon son seuil (valeur du paramètre X).
Mais, on pourrait avoir envie de voir notre cluster mis en Warning selon l'état des éléments du cluster.

Les opérateurs X,Y,Zof et Xof configurable permettent d'avoir un niveau d'information plus précis sur l'état du cluster.

L'opérateur X,Y,Zof

L'opérateur X,Y,Zof agit de manière similaire à l'opérateur Xof.

Il dispose de 3 paramètres X,Y et Z qui agissent comme suivant:

• X: Nombre minimal de statuts OK pour que l'opérateur renvoie OK
• Y: Nombre minimal de statuts Warning pour que l'opérateur renvoie Warning
• Z: Nombre minimal de statuts Critical pour que l'opérateur renvoie Critical

L'évaluation de la règle Xof se fait dans l'ordre suivant:

• L'état peut-il être Critique ? (comparaison avec Z)
• L'état peut-il être Warning ? (comparaisons avec Y + Z)
• L'état peut-il être OK ? (comparaison avec X)
• Si aucun cas n'est possible, l'état est OK.

Pour illustrer, prenons l'exemple d'une business rule agissant sur 5 services A,B,C,D et E:            X,Y,Zof: A|B|C|D|E

L'opérateur Xof configurable

L'opérateur X,Y,Zof permet d'avoir un contrôle plus fin sur le status du cluster mais son comportement est fixe et ne peut pas être changé. L'opérateur Xof configurable permet de définir le comportement du Cluster précisément.

L'utilisateur peut définir plusieurs comportements sont forme de propositions successives qui seront évalués dans l'ordre fourni.

La syntaxe de cette commande est la suivante:

    proposition1|proposition2|proposition3|default->return_state of: elements

    avec les propositions de la forme:    Xstatus->return_status

Les différentes propositions sont évaluées dans l'ordre dans lequel elles apparaissent. Si une proposition est valide, l'état spécifie est renvoyé et l'évaluation s'arrête. Si aucune proposition n'est valide, l'état spécifié dans default est renvoyé. Si aucune valeur par défaut n'est spécifiée, la valeur renvoyée est Unknown.

Les statuts à fournir pour les règles sont les suivants:

• OK
• Warning
• Critical
• Unknown

Exemples

On se place dans le cas d'un cluster à 10 éléments, A, B, C, D, E, F, G, H, I et J.

Business rule:              1Critical->Warning|2Critical->Critical|15%Warning->Warning|20%Warning->Critical|95%OK→OK|default→Warning of: A|B|C|D|E|F|G|H|I|J