Le Blog Technique

SCOM 2012 – Les nouvelles vues Réseaux

par Christophe Jourdan | 8 Mar 2012 | Supervision (SCOM, NAGIOS)

En termes de monitoring, une des nouveautés de SCOM 2012 est la présence de 4 nouveaux types de vues (Dashboard) orientées réseau.

Network Summary, Network Node, Network Interfaces et Vicinity view.

La vue Network Summary est la seule des quatre à s’afficher par défaut dans la hiérarchie des vues de la partie Navigation, les autres étant disponible via un lien sur la vue Network Summary, via les taches a exécuter ou encore dans le menu contextuel des objets (clic-droit)

Cette vue sert essentiellement a voir l’état générale des équipements et interfaces associés de votre réseau.

La vue Network Node fourni des détails sur l’état de santé d’un équipement particulier. Cette vue est constitué de :

– la vue des liens connectés à l’équipement sélectionné

– des jauges sur la disponibilité de l’équipement dans le temps

– la liste des interfaces de l’équipement, avec la possibilité d’activer/désactiver directement la supervision de l’interface par override.

La vue Network Interface est la plus détaillé des vues sur une interface particulière d’un équipement. Il est important de noter que par défaut SCOM 2012 supervise uniquement les interfaces d’équipements supervisés et celles connectées a des ordinateurs Windows également supervisés.

La vue Network Vicinity (Littéralement « Voisinage Réseau ») est la vue qui traduit le plus l’orientation donné a SCOM 2012, à savoir une vue 360 ° de l’objet.

Cette vue affiche un nœud réseau et tous les ordinateurs Windows et autres équipements réseau connecté à ce nœud.

La possibilité est donnée de basculer entre 5 niveaux de détails de connexion et de visualiser les machines connectés ou non.

En sélectionnant une connexion particulière il est possible d’identifier quelle ports d’équipement réseau est impliqué dans l’état d’une liaison.

La principale limitation dans cette première version des vues Network Vicinity est qu’elle fonctionne uniquement avec des ordinateurs Windows et non les agents Linux, qu’elle ne visualise pas la relation entre un hôte Hyper-V et ses machines virtuelles hébergées, et qu’elle n’affiche pas les interfaces réseaux configurés en « Teaming » comme étant « Teamés ».

Ces limitations devraient disparaitre avec l’évolution de SCOM 2012, notamment à travers le premier service pack.

A noter que l’ensemble de ces 4 types de vues sont visualisable a la fois dans la console native et dans la console web de SCOM 2012.

Powershell–Gestion du réseau

par Julien Bausseron | 2 Mar 2012 | PowerShell

Contexte

Il arrive souvent lors de l’installation de certains produits ou fonctionnalitée de devoir réaliser des opérations de vérification des pré-requis. Le premier pré-requis a satisfaire concerne souvent le réseau:

Suis-je en capacité de joindre ma passerelle?
Le ou les contrôleurs hébergeant les rôles FSMO sont-ils joignable?
Mes serveurs DNS sont-ils joignable?

Pour réaliser ces opérations sur quelques serveurs cela peut être réalisé manuellement, mais lorsque le nombre de serveur est conséquent, cela peut s’avéré fastidieux. Je vous propose de travailler en powerShell pour simplifier/automatiser cette opération.

Etape 1: récupérer la configuration de machine

Pour cela rien de bien compliquer, la commande ipconfig /all nous retourne l’ensemble des éléments nécessaire:

Maintenant il faut pouvoir isolé chaque paramètre de réponse (ici identifiés de 1 a 6). Pour cela un traitement sur le retour d’ipconfig est nécessaire:

1. Adresse IPv4: ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]
2. Masque : ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]
3 Passerelle : ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]
4 Serveur DHCP : ((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]
5 DNS Principal : ((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]
6 DNS Secondaire ((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]

Etape 2: Exécuter un ping en powershell

Pour réaliser cette opération les commandes suivante nous retourne un résultat contenant les valeur attendu:

new-object System.Net.NetworkInformation.ping
$reply = $ping.Send(« 192.168.0.254 »)

Nous savons donc que le ping a fonctionné au travers du status. qu’il reste a isoler puis a traiter. Pour l’isolation, l’utilisation des variables nous simplifie la tache:

Etape 3: Automatisation des résultats

Afin de valider le bon fonctionnement des pré-requis lié au réseau, nous pouvons traiter les retours au travers de différents moyens, pour ma part, je préfère utilisé les conditions au travers du If – Else

#***** Stockage des parametre dans une variable*****#
    $IP= ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]
    $IPMask= ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]
    $IPgtw= ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]
    $IPDHCP=((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]
    $DNS1=((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]
    $DNS2=((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]
  
#**Test passerelle**#
    $reply = ""
    $status =""
    $ping = new-object System.Net.NetworkInformation.ping
    $reply = $ping.Send($IPgtw)
  
if ($reply.status -eq "success")
    {
    write-host "Passerelle joignable" -foregroundColor green
    }
    Else
    {
    write-host "Passerelle injoignable" -foregroundColor red
    }
  
#**Test DHCP**#
    $reply = ""
    $status =""
    $ping = new-object System.Net.NetworkInformation.ping
    $reply = $ping.Send($IPDHCP)
  
if ($reply.status -eq "success")
    {
    write-host "DHCP joignable" -foregroundColor green
    }
    Else
    {
    write-host "DHCP injoignable" -foregroundColor red
    }
#**Test passerelle**#
    $reply = ""
    $status =""
    $ping = new-object System.Net.NetworkInformation.ping
    $reply = $ping.Send($DNS1)
  
if ($reply.status -eq "success")
    {
    write-host "DNS joignable" -foregroundColor green
    }
    Else
    {
        $reply = ""
        $status =""
        $ping = new-object System.Net.NetworkInformation.ping
        $reply = $ping.Send($DNS2)
        if ($reply.status -eq "success")
            {
            write-host "DNS joignable" -foregroundColor green
            }
            Else
            {
            write-host "DNS injoignable" -foregroundColor red
            }        
    }
  

Le résultat positif retourne:

Le résultat négatif retourne:

Conclusion

Cette vérification permet de réaliser un enchainement de script ou d’action si et seulement si les paramètres réseaux sont correct. Par exemple en créant un flag si les résultats sont positif !

SCOM 2007 : Créer un scénario d’escalade d’alerte

par Cyril Azoulay | 2 Mar 2012 | Supervision (SCOM, NAGIOS)

Trop souvent, les souscriptions d’alertes ne sont pas utilisées à leur plein potentiel : une seule souscription est créée, ce qui peut bien entendu suffire dans certains cas mais pourraient être largement optimisé dans d’autres.

On peut ainsi définir de vrais scénarios d’escalade : par exemple si aucune action n’a été effectuée pour résoudre une alerte après un délai imparti, on peut décider d’envoyer un SMS à un responsable ou bien de transférer l’alerte à un autre service.

Prenons l’exemple de la souscription suivante, nommée « Alerte Linux » :

Il s’agit d’une souscription des plus classique, où toutes les nouvelles alertes (resolution state 0) concernant les serveurs membres du groupe Unix Computers (donc tous les ordinateur Unix/Linux monitorés par SCOM) et de priorité moyenne ou haute seront adressées par mail à l’utilisateur « Support_Linux ».

Imaginons maintenant que nous souhaitons que cette alerte soit automatiquement transmise par SMS à un responsable si elle n’est pas prise en charge au bout d’une heure.
Il suffit pour ce faire de créer une alerte avec des conditions de déclenchement identiques en tous points à la précédente, que nous nommerons par exemple « Alerte Linux (+1h) » et qui sera cette fois destinée à l’utilisateur « Manager_Linux » avec un délai (alert aging) d’une heure :

En se basant sur ce système, il devient très simple de créer des scénarios d’escalade en fonction du niveau de résolution, de l’heure de la journée (en créant des subscribers valables uniquement la nuit pour les astreintes par exemple) ; ou bien de n’envoyer l’alerte par mail que si elle n’a pas été prise en compte directement dans la console… les possibilités sont vastes !

Et comme il peut être fastidieux de recopier à l’identique les conditions de déclenchement d’une subscription (sans parler du risque de se tromper), Timothy McFadden (PFE chez Microsoft) a developpé un outil très pratique, Subscription Copier :

Il permet de sélectionner une subscription initialement créée avec les bons paramètres de la copier autant de fois que vous en aurez besoin pour votre scénario d’escalade. Il permet également de prédéfinir un délai (alert aging) qui s’incrémente de copie en copie.
Disponible sur son blog : http://www.scom2k7.com/subscription-copier/

Toutes les astuces #tech des collaborateurs de PI Services.

Retrouvez les articles à la une

SCOM 2012 – Les nouvelles vues Réseaux

Powershell–Gestion du réseau

Contexte

Etape 1: récupérer la configuration de machine

Etape 2: Exécuter un ping en powershell

Etape 3: Automatisation des résultats

Conclusion

SCOM 2007 : Créer un scénario d’escalade d’alerte

Derniers articles

Aucun résultat

Catégories

Archives

Auteurs/Autrices