Le blog technique

Bonjour à tous,

Nous allons voir comment mettre en place une collection de serveurs Hôte RDS.

Nous allons mettre en place l’infrastructure suivante :

• 2 serveurs avec le rôle hôte de sessions (LAB-HRDS-03T et LAB-HRDS-04T)

• 1 serveur avec les rôles “connection Broker” et “Web access” RDS (LAB-BRDS-02T) (vous pouvez bien sûr rajouter plusieurs broker si vous voulez de la redondance)

Nous allons voir ici la version graphique la plus simple à mettre en œuvre.

CREATION D’UN GROUPE DE SERVEUR

Il faut en premier créer un groupe de serveurs (via le gestionnaire de serveur) sur le serveur servant à l’installation de l’architecture RDS.

INSTALLATION DES ROLES RDS SUR LES DIFFERENTS SERVEURS

Nous allons faire un ajout de rôle sur le serveur LAB-BRDS-02T.

Nous allons faire une installation de type Remote Desktop Service

Nous allons choisir ensuite un déploiement standard qui permet de configurer une solution RDS avec plusieurs serveurs.

Nous avons ici deux options :

• déploiement de bureau basé sur des VM
• déploiement de bureau basé sur des sessions

Ici nous allons choisir la seconde option.

Nous avons ensuite une présentation des 3 rôles de bases d’une architecture RDS (Le licencing sera abordé dans un autre post ultérieurement)

Le service Broker gère la reconnexion des sessions. Cela permet à un utilisateur de retrouvé le bureau du même serveur à chaque reconnexion.

Le service Web Access fournit une page web de connexion qui permet de gérer les éléments disponible pour les utilisateurs.

Le service Host correspond au(x) serveur(s) qui hébergeront les applications et les sessions bureau à distance.

Il faut ensuite spécifier le serveur qui hébergera le rôle connection broker

Ensuite nous pouvons spécifier le serveur qui hébergera le rôle Web access.

Nous avons le choix du serveur et une case à cocher pour choisir automatiquement le serveur qui hébergera le rôle connection broker

Enfin il faut spécifier le(s) serveur(s) qui hébergeront le rôle session host.

Nous avons ensuite un récapitulatif de nos choix.

Le(s) serveur(s) hébergeant le rôle session host nécessiteront un redémarrage.

Dans le gestionnaire de serveur du serveur hébergeant le rôle connection broker nous allons créer notre collection de session qui permettra au utilisateurs de se connecter à une adresse unique puis d’être dirigé vers le serveur ayant le moins de sessions.

Ensuite nous avons la page récapitulatif de la collection.

Nous retrouvons 4 sections:

1. Propriétés : listes des informations de base sur la collection.
2. Programme RemoteApp : liste des applications publiés dans la collection (ces dernières peuvents être lancé directement depuis l’interface RD Web)
3. Serveur Host: liste des serveurs host de la collection. Il est possible de refuser les nouvelles connexions (pour une maintenance par exemple) sur un serveur en faisant un clique droit sur son nom.

1. Connexions : liste les connexions actuelles et leur état. ATTENTION : il n’y a pas de rafraichissement automatique de la fenêtre il faut choisir tache => rafraichir ou changer de page dans le gestionnaire de serveur

Nous pouvons désormais accéder au serveur RDweb et nous authentifier avec notre compte AD.

ATTENTION : il faut mettre le nom de domaine même si vous n’en avez qu’un. 

Nous voyons notre collection il suffit de cliquer dessus pour se connecter.

Je suis en nom de RDP sur mon broker mais la session est bien ouverte sur un serveur host (LAB-HRDS-03T)

Ce plugin très complet est utilisé pour la supervision hardware des serveurs Dell sur la base des information fournis par le composant OMSA (Open Manage Server Administrator) sur les serveurs cibles.

Le fonctionnement du plugin est disponible:

–  via NRPE (Nagios Remote Plugin Executor) où les checks sont effectués en local par un .exe dedié (check_openmanage.exe pour les serveur windows) et renvoyé a Nagios

- via SNMP ou les checks sont effectués a distance

L’utilisation de SNMP a l’avantage de ne pas nécessiter d’exécutable sur la machine cible.

Prérequis: Installation fonctionnelle de Dell OMSA (version 5.3 et supérieure) et service SNMP configuré pour autoriser le serveur Nagios

1/ Récupération des sources avec wget:

cd /usr/src

wget http://folk.uio.no/trondham/software/files/check_openmanage-3.7.12.tar.gz

2/ Décompression de l’archive

tar –xvzf check_openmanage-3.7.12.tar.gz

3/ Copie de check_openmanage dans le repertoire des plugins de nagios et des pages de manuel

cp /usr/src/check_openmanage/check_openmanage /usr/local/nagios/libexec

cp /usr/src/check_openmanage/check_openmanage.8 /usr/share/man/man8

cp /usr/src/check_openmanage/check_openmanage.conf.5 /usr/share/man/man5

4/ changement des droits :

chown nagios /usr/local/nagios/libexec/check_openmanage

chgrp nagios /usr/local/nagios/libexec/check_openmanage

chmod 755 /usr/local/nagios/libexec/check_openmanage

5/ Test de récupération d’information (NB : ce test de debug (-d) affiche l’ensemble des information et ne doit pas être implémenté en tant que commande dans nagios car l’affichage resultant n’est pas exploitable:

. /check_openmanage –H <ip_adress> –C <snmp_community> –d

Si cette commande renvoi un tableau avec l’ensemble des informations et des état de la machine cible, le fonctionnement du plugin en snmp est OK, et les variantes d’utilisation de commandes peuvent être implémentées:

Ci-dessous quelques exemples des nombreux états qui peuvent être remontés.:

Se référer au lien suivant pour l’ensemble des options disponibles pour la création de commandes avec ce plugin :

http://folk.uio.no/trondham/software/check_openmanage.html