Page History

Qu'est ce que les dépendances réseau ? 

Les dépendances réseau sont très pratique pour gérer la résolution de panne à grande échelle. Imaginons que ce soit un problème technique, on va chercher alors le problème source.

Peut-être que le PC est juste éteint, le câble réseau simplement débranché, ou le routeur est tombé.

Quelq ue soit le problème, une chose est sûre : l'internet fonctionne Il est juste impossible d joindre cet utilisateur.

Shinken Enterprise est capable de faire la différence entre un élément en état DOWN et un état UNREACHABLE .

Ces états sont très différents (même si liés) et peuvent vous aider à déterminer rapidement la cause source de vos problèmes réseau.

De telles dépendances sont également possibles pour des problèmes applicatifs, tel que l'appli web qui ne fonctionne pas parce que la base de données est tombée.

Ces cas sont gérés par la notion de cluster .

Exemple réseau

Regardons le diagramme réseau ci-joint et imaginons qu'on supervise tous les hôtes

(serveurs, routeurs, switches, etc)

Définir les relations parents/enfants

Les dépendances réseau sont nommées relations "parents/enfants". Par exemple, le parent est le switch et l'enfant est le serveur.

Pour permettre à Shinken Enterprise de faire la différence entre les états DOWN et UNREACHABLE pour les élément supervisés, vous devez d'abord décrire dans Shinken Enterprise comment ces éléments sont connectés entre eux (d'un point de vue démon Shinken Enterprise).

Pour le faire, tracer le chemin que prendrait un paquet depuis le démon Shinken Enterprise vers chaque hôte. Chaque switch, routeur, et serveur qui croise le paquet est considéré comme une "étape" et nécessitera qu'on définisse ses liens parent/enfant dans la configuration de Shinken Enterprise. Voici à quoi peuvent ressembler les relations parent/enfant d'un hôte du point de vue Shinken Enterprise:

Logique d'accessibilité

Dans cet exemple, Shinken Enterprise va déterminer que le Web et le Routeur1 sont tous les deux DOWN car le chemin vers ces 2 éléments n'est pas bloqué donc les notifications sur ces 2 éléments seront envoyées.

Shinken Enterprise va ensuite déterminer que tous les hôtes au dessus de Routeur1 sont dans l'état UNREACHABLE . Routeur1 est DOWN et bloque le chemin vers tous les autres hôtes au dessus. Ils peuevent fonctionner,ou pas, mais Shinken Enterprise ne peut pas le savoir. Ils ne sont donc pas en DOWN et aucun notification de sera envoyée sur ces éléments. Toues ces élémenst au dessus de Routeur1 sont considérés comme un impact de la cause source  "router1"

Et si il y a plus d'un parent pour un hôte ?

Vous pouvez définir plusieurs parents pour un même hôte. Celui-ci sera considéré comme UNREACHABLE si et seulement si tous ses parents sont down ou unreachable**. Si l'un deux est vivant, ils seront en état down.

Etat UNREACHABLE et notifications

What are network dependencies ? 

Network dependencies are a way to manage large outage resolution. Assuming its a technical problem, you begin to search for the root problem.

Perhaps the user's computer is turned off, maybe their network cable is unplugged, or perhaps your organization's core router just took a dive.

Whatever the problem might be, one thing is most certain - the Internet isn't down. It just happens to be unreachable for that user.

Shinken Enterprise is able to determine whether the hosts you're monitoring are in a DOWN or UNREACHABLE state.

These are very different (although related) states and can help you quickly determine the root cause of network problems.

Such dependencies are also possible for applications problems, like your web app is not available because your database is down.

Theses cases are managed by cluster definitions.

Example Network

Take a look at the simple network diagram below. For this example, lets assume you're monitoring all the hosts

(server, routers, switches, etc) that are pictured by defining a check_command for each host.

Defining Parent/Child Relationships

The network dependencies will be named "parent/child" relationship. The parent is the switch for example, and the child will be the server.

In order for Shinken Enterprise to be able to distinguish between DOWN and UNREACHABLE states for the hosts that are being monitored, you'll first need to tell Shinken Enterprise how those hosts are connected to each other - from the standpoint of the Shinken Enterprise daemon.

To do this, trace the path that a data packet would take from the Shinken Enterprise daemon to each individual host. Each switch, router, and server the packet encounters or passes through is considered a "hop" and will require that you define a parent/child host relationship in Shinken Enterprise. Here's what the host parent/child relationships looks like from the viewpoint of Shinken Enterprise:

Reachability Logic in Action

In this example, Shinken Enterprise will determine that Web and Router1 are both in DOWN states because the "path" to those hosts is not being blocked (switch1 is still alive), and so **it will allow web and router1 notifications to be sent**.

Shinken Enterprise will determine that all the hosts "beneath" Router1 are all in an UNREACHABLE state because Shinken Enterprisecan't reach them. Router1 is DOWN and is blocking the path to those other hosts. Those hosts might be running fine, or they might be offline - Shinken Enterprise doesn't know because it can't reach them. Hence Shinken Enterprise considers them to be UNREACHABLE instead of DOWN, and won't send notifications about them. Such hosts and services beneath router1 are the impacts of the root problem "router1"

What about more than one parent for a host?

You see that there is a 's' in parents. Because you can define as many parent as you want for a host (like if you got an active/passive switch setup). **The host will be UNREACHABLE only, and only if all it's parents are down or unreachable**. If one is still alive, it will be down. See this as a big *OR* rule.

UNREACHABLE States and Notifications

What about notification about check of a down or unreachable hosts?