Les clusters Lotus #3
Configurer les clusters
(troisième partie) : gestion des Grappes pour les clients Lotus Notes
Cet article présente différentes options de mise en cluster de serveurs IBM/LOTUS DOMINO pour les clients Lotus Notes
La mise en cluster de serveurs Lotus Domino propose plusieurs options, pour l'hébergement des clients Lotus Notes, en fonction que l'on souhaite orienter une Grappe plutôt du côté 'équilibre de charge' ou plutôt du côté "tolérance aux pannes".
Ces différentes options se configurent souvent à l'aide de variable des fichiers Notes.ini de vos serveurs.
...
Cet article présente différentes options de mise en cluster de serveurs IBM/LOTUS DOMINO pour les clients Lotus Notes
La mise en cluster de serveurs Lotus Domino propose plusieurs options, pour l'hébergement des clients Lotus Notes, en fonction que l'on souhaite orienter une Grappe plutôt du côté 'équilibre de charge' ou plutôt du côté "tolérance aux pannes".
Ces différentes options se configurent souvent à l'aide de variable des fichiers Notes.ini de vos serveurs.
...
Reportez vous à l'article "Configurer
les clusters (première partie) : SAMETIME R8" ( http://domino.stergann.org/Web/domsphere.nsf/d6plinks/PMOY-7GRFXE)
pour réaliser la déclaration d'une grappe de serveurs Domino.
1. Principe de répartition et de disponibilité des bases entre serveurs Domino
Je préfère en général, s'agissant de Domino, utiliser le terme de Grappe plutôt que le mot Cluster.
Il n'y a en effet aucune obligation à ce que les serveurs d'une Grappe Domino soient identiques et hébergent exactement les mêmes bases de documents et boites aux lettres. C'est d'ailleurs un des intérêts de ce type de configuration : si, par exemple, on dispose de deux serveurs Domino afin d'héberger la messagerie et des applications de Groupware Lotus, on peut très bien configurer une Grappe afin de n'avoir de redondance que pour la messagerie, les applicatifs n'étant hébergés que sur l'un des deux serveurs. Et on n'est absolument pas obligé de mettre en Grappe l'ensemble des boites aux lettres.
Cette souplesse s'avère par contre être un inconvénient si l'on souhaite maintenir à l'identique les membres d'une Grappe Domino : il n'y a pas d'outil intégré permettant de créer automatiquement des répliques de bases sur l'ensemble des serveurs d'une grappe. Un oubli, lors de la création d'un compte utilisateur, est donc tout à fait possible. Le développement d'un agent tout simple permet par contre de remédier à ce problème.
La disponibilité des bases de documents Notes, messagerie ou application, est gérée individuellement au niveau des fichiers.
Prenons l'exemple d'une Grappe de deux serveurs, Serveur1 et Serveur2. Une base de documents Notes, fichier.nsf par exemple, a été déployée par réplication sur ces deux serveurs,
Cette base est par défaut accessible sur l'un ou l'autre des serveurs. Si Serveur1 est arrêté, les utilisateurs Lotus Notes continuerons à travailler sur cette base en ouvrant la version hébergée sur Serveur2. Si l'on redémarre Serveur1 et que l'on arrête Serveur2, les sessions utilisateurs basculeront par défaut vers la version hébergée sur Serveur1.
L'administrateur Domino dispose d'outils pour rendre indisponible une base sur l'un ou l'autre des serveurs. Ces outils sont accessibles depuis le logiciel Domino Administrator, sur l'onglet des fichiers.
Les options En service/Hors service permettent de déclarer une ou plusieurs bases comme étant accessible ou non sur votre serveur. Pour une opération de maintenance par exemple.
L'option En instance de suppression permet d'indiquer au serveur Domino de supprimer une base dès que toutes les sessions utilisateur auront été fermées sur le fichier.
Les options Activer / Désactiver la réplication de Grappe permet de spécifier au réplicateur de Grappe, la tâche de synchronisation automatique des bases de documents, si le ou les fichiers sélectionnés doivent être synchronisés entre les serveurs.
N'oubliez pas, en fonction des options que vous aurez sélectionnées, de venir le cas échéant désactiver tel ou tel élément afin de remettre une base en service dans la grappe. Utilisez la base de documents catalog.nsf (le catalogue des bases de documents), afin de connaître le statut actuel des fichiers dans votre Grappe.
Autre élément à connaître, le réplicateur de Grappe (tâche serveur Clurepl), l'outil de synchronisation des fichiers, ne propage pas toutes les modifications entre les serveurs d'une Grappe. Cette tâche de réplication permet de déclencher une réplication des données ou de la structure des bases Notes dès lors qu'une modification a été effectuée sur l'une des répliques d'un fichier. C'est donc un réplicateur événementiel, contrairement au réplicateur Notes classique qui se déclenche sur une action utilisateur, ou en fonction d'une planification définie à l'avance.
Si un des serveurs a été arrêté trop longtemps, ou si la réplication de Grappe d'une base est restée désactivée trop longtemps, le réplicateur de Grappe ne saura pas synchroniser l'ensemble des données de la ou des bases de documents entre les serveur de la Grappe. Il est donc intéressant de planifier des réplications standard de toutes les bases entre les serveurs d'une grappe, à intervalles réguliers, afin de remédier à ce fait.
2. Disponibilité des serveurs et équilibre de charge dans une grappe
Il est également possible de mettre un serveur spécifique Hors Service dans une grappe Domino.
L'indisponibilité d'un serveur, dans la Grappe, se définit à l'aide de la variable ServerRestricted du fichier notes.ini du serveur.
L'affectation de la valeur 0 à cette variable signifie que le serveur est en service. Les valeurs 1 ou 2, lorsqu'elles sont affectées à la variable, indiquent que le serveur est Hors Service et n'accepte plus de connexions utilisateur, seuls les administrateurs de serveurs restent habilités à se connecter au serveur rendu indisponible. L'affectation de la valeur 1 à cette variable ne met le serveur Hors Service que pour la session courante. La variable repasse automatique à une valeur de 0 après redémarrage du serveur Domino. L'affectation de la valeur 2 à la variable déclare le serveur Hors service jusqu'à ce qu'un administrateur vienne réaffecter une valeur de 0. Un redémarrage du serveur Domino ne le rend donc pas automatique disponible pour les utilisateurs.
L'équilibre de la charge, entre des serveurs Domino en Grappe, est réalisé à l'aide de variables du fichier Notes.ini
Il est possible, sur les serveurs Domino, de définir :
- un nombre maximum d'utilisateurs, utilisez la variable ServerMaxUsers
- un nombre maximum de sessions, variable serverMaxSessions
- un seuil de disponibilité au delà duquel le serveur n'accepte plus de nouvelles connexions, variable ServerAvailabilityThreshold
Le seuil de disponibilité d'un serveur correspond à une valeur comprise entre 0 et 100. Un serveur dont le seuil de disponibilité est de 0 est considéré comme ayant des temps de réponse dégradés. Une valeur de 100 signifie que les temps de réponse moyens du serveur sont corrects. Si vous affectez à la variable ServerAvailabilityThreshold une valeur de 10, vous indiquez au serveur de ne plus accepter de connexions dès que l'indice de disponibilité tombe en dessous de 100.
Cette variable est à manipuler avec une extrême précaution car les valeurs renvoyées pour l'indice de disponibilité ne correspondent pas obligatoirement à la réalité. Si vous décidez d'utiliser cette variable,vous devez au préalable avoir échantillonné cet indice afin qu'il corresponde réellement à la charge de votre serveur. Faites une recherche dans l'aide en ligne d'administration Domino afin de localiser l'aide associée à la commande show AI et à la variable SERVER_TRANSINFO_RANGE. Ce sont les outils qui vous permettrons d'effectuer cet échantillonnage.
2. Comment s'effectue la bascule des clients Notes d'un serveur d'une Grappe à un autre serveur de cette même Grappe
La bascule des clients Notes, et des serveurs Domino distants, lors par exemple d'un arrêt ou de la mise HS d'un des serveurs de la Grappe, est à l'initiative du poste client ou du serveur distant.
Les clients Lotus Notes enregistrent localement, lors de leur premier accès à un serveur en grappe, le nom de la Grappe et la liste des serveurs membres de cette Grappe. Ces informations sont stockées dans le fichier texte cluster.ncf.
Lorsqu'un utilisateur (ou un serveur distant) veut accéder à une base de document à l'emplacement habituel de consultation de cette base, et que le serveur est indisponible à cet emplacement, le programme client :
- consulte le fichier cluster.ncf afin de déterminer si le serveur requêté fait partie d'une Grappe
- si tel est le cas, le programme client requête les autres serveurs de la Grappe
- dès qu'un autre serveur de la Grappe a pris en charge la requête du client, l'ID de la base de document demandée est soumise à ce serveur
- le serveur consulte son catalogue de bases de documents afin de déterminer quels sont les serveurs qui disposent d'une réplique de cette base accessible
- le programme client redirige alors la requête d'ouverture de la base de documents vers un des serveurs disponibles.
Cette redirection est de plus en plus transparente pour l'utilisateur au fil des différentes versions Domino.
Il faut garder à l'esprit qu'une Grappe Domino ne sera complètement opérationnelle que lorsque tous les utilisateurs des serveurs de cette grappe auront ouvert une session sur au moins un des serveurs de la Grappe.
1. Principe de répartition et de disponibilité des bases entre serveurs Domino
Je préfère en général, s'agissant de Domino, utiliser le terme de Grappe plutôt que le mot Cluster.
Il n'y a en effet aucune obligation à ce que les serveurs d'une Grappe Domino soient identiques et hébergent exactement les mêmes bases de documents et boites aux lettres. C'est d'ailleurs un des intérêts de ce type de configuration : si, par exemple, on dispose de deux serveurs Domino afin d'héberger la messagerie et des applications de Groupware Lotus, on peut très bien configurer une Grappe afin de n'avoir de redondance que pour la messagerie, les applicatifs n'étant hébergés que sur l'un des deux serveurs. Et on n'est absolument pas obligé de mettre en Grappe l'ensemble des boites aux lettres.
Cette souplesse s'avère par contre être un inconvénient si l'on souhaite maintenir à l'identique les membres d'une Grappe Domino : il n'y a pas d'outil intégré permettant de créer automatiquement des répliques de bases sur l'ensemble des serveurs d'une grappe. Un oubli, lors de la création d'un compte utilisateur, est donc tout à fait possible. Le développement d'un agent tout simple permet par contre de remédier à ce problème.
La disponibilité des bases de documents Notes, messagerie ou application, est gérée individuellement au niveau des fichiers.
Prenons l'exemple d'une Grappe de deux serveurs, Serveur1 et Serveur2. Une base de documents Notes, fichier.nsf par exemple, a été déployée par réplication sur ces deux serveurs,
Cette base est par défaut accessible sur l'un ou l'autre des serveurs. Si Serveur1 est arrêté, les utilisateurs Lotus Notes continuerons à travailler sur cette base en ouvrant la version hébergée sur Serveur2. Si l'on redémarre Serveur1 et que l'on arrête Serveur2, les sessions utilisateurs basculeront par défaut vers la version hébergée sur Serveur1.
L'administrateur Domino dispose d'outils pour rendre indisponible une base sur l'un ou l'autre des serveurs. Ces outils sont accessibles depuis le logiciel Domino Administrator, sur l'onglet des fichiers.
Les options En service/Hors service permettent de déclarer une ou plusieurs bases comme étant accessible ou non sur votre serveur. Pour une opération de maintenance par exemple.
L'option En instance de suppression permet d'indiquer au serveur Domino de supprimer une base dès que toutes les sessions utilisateur auront été fermées sur le fichier.
Les options Activer / Désactiver la réplication de Grappe permet de spécifier au réplicateur de Grappe, la tâche de synchronisation automatique des bases de documents, si le ou les fichiers sélectionnés doivent être synchronisés entre les serveurs.
N'oubliez pas, en fonction des options que vous aurez sélectionnées, de venir le cas échéant désactiver tel ou tel élément afin de remettre une base en service dans la grappe. Utilisez la base de documents catalog.nsf (le catalogue des bases de documents), afin de connaître le statut actuel des fichiers dans votre Grappe.
Autre élément à connaître, le réplicateur de Grappe (tâche serveur Clurepl), l'outil de synchronisation des fichiers, ne propage pas toutes les modifications entre les serveurs d'une Grappe. Cette tâche de réplication permet de déclencher une réplication des données ou de la structure des bases Notes dès lors qu'une modification a été effectuée sur l'une des répliques d'un fichier. C'est donc un réplicateur événementiel, contrairement au réplicateur Notes classique qui se déclenche sur une action utilisateur, ou en fonction d'une planification définie à l'avance.
Si un des serveurs a été arrêté trop longtemps, ou si la réplication de Grappe d'une base est restée désactivée trop longtemps, le réplicateur de Grappe ne saura pas synchroniser l'ensemble des données de la ou des bases de documents entre les serveur de la Grappe. Il est donc intéressant de planifier des réplications standard de toutes les bases entre les serveurs d'une grappe, à intervalles réguliers, afin de remédier à ce fait.
2. Disponibilité des serveurs et équilibre de charge dans une grappe
Il est également possible de mettre un serveur spécifique Hors Service dans une grappe Domino.
L'indisponibilité d'un serveur, dans la Grappe, se définit à l'aide de la variable ServerRestricted du fichier notes.ini du serveur.
L'affectation de la valeur 0 à cette variable signifie que le serveur est en service. Les valeurs 1 ou 2, lorsqu'elles sont affectées à la variable, indiquent que le serveur est Hors Service et n'accepte plus de connexions utilisateur, seuls les administrateurs de serveurs restent habilités à se connecter au serveur rendu indisponible. L'affectation de la valeur 1 à cette variable ne met le serveur Hors Service que pour la session courante. La variable repasse automatique à une valeur de 0 après redémarrage du serveur Domino. L'affectation de la valeur 2 à la variable déclare le serveur Hors service jusqu'à ce qu'un administrateur vienne réaffecter une valeur de 0. Un redémarrage du serveur Domino ne le rend donc pas automatique disponible pour les utilisateurs.
L'équilibre de la charge, entre des serveurs Domino en Grappe, est réalisé à l'aide de variables du fichier Notes.ini
Il est possible, sur les serveurs Domino, de définir :
- un nombre maximum d'utilisateurs, utilisez la variable ServerMaxUsers
- un nombre maximum de sessions, variable serverMaxSessions
- un seuil de disponibilité au delà duquel le serveur n'accepte plus de nouvelles connexions, variable ServerAvailabilityThreshold
Le seuil de disponibilité d'un serveur correspond à une valeur comprise entre 0 et 100. Un serveur dont le seuil de disponibilité est de 0 est considéré comme ayant des temps de réponse dégradés. Une valeur de 100 signifie que les temps de réponse moyens du serveur sont corrects. Si vous affectez à la variable ServerAvailabilityThreshold une valeur de 10, vous indiquez au serveur de ne plus accepter de connexions dès que l'indice de disponibilité tombe en dessous de 100.
Cette variable est à manipuler avec une extrême précaution car les valeurs renvoyées pour l'indice de disponibilité ne correspondent pas obligatoirement à la réalité. Si vous décidez d'utiliser cette variable,vous devez au préalable avoir échantillonné cet indice afin qu'il corresponde réellement à la charge de votre serveur. Faites une recherche dans l'aide en ligne d'administration Domino afin de localiser l'aide associée à la commande show AI et à la variable SERVER_TRANSINFO_RANGE. Ce sont les outils qui vous permettrons d'effectuer cet échantillonnage.
2. Comment s'effectue la bascule des clients Notes d'un serveur d'une Grappe à un autre serveur de cette même Grappe
La bascule des clients Notes, et des serveurs Domino distants, lors par exemple d'un arrêt ou de la mise HS d'un des serveurs de la Grappe, est à l'initiative du poste client ou du serveur distant.
Les clients Lotus Notes enregistrent localement, lors de leur premier accès à un serveur en grappe, le nom de la Grappe et la liste des serveurs membres de cette Grappe. Ces informations sont stockées dans le fichier texte cluster.ncf.
Lorsqu'un utilisateur (ou un serveur distant) veut accéder à une base de document à l'emplacement habituel de consultation de cette base, et que le serveur est indisponible à cet emplacement, le programme client :
- consulte le fichier cluster.ncf afin de déterminer si le serveur requêté fait partie d'une Grappe
- si tel est le cas, le programme client requête les autres serveurs de la Grappe
- dès qu'un autre serveur de la Grappe a pris en charge la requête du client, l'ID de la base de document demandée est soumise à ce serveur
- le serveur consulte son catalogue de bases de documents afin de déterminer quels sont les serveurs qui disposent d'une réplique de cette base accessible
- le programme client redirige alors la requête d'ouverture de la base de documents vers un des serveurs disponibles.
Cette redirection est de plus en plus transparente pour l'utilisateur au fil des différentes versions Domino.
Il faut garder à l'esprit qu'une Grappe Domino ne sera complètement opérationnelle que lorsque tous les utilisateurs des serveurs de cette grappe auront ouvert une session sur au moins un des serveurs de la Grappe.
- 
