Les clusters Lotus #1
Configurer les clusters
(première partie) : SAMETIME R8
Cet article présente un des modes de mise en cluster de serveurs de messagerie instantanée IBM/LOTUS SAMETIME.
( http://www-306.ibm.com/software/lotus/sametime/ )
Il existe deux manières principales de gérer la mise en grappe (clustering) de communautés de serveurs Sametime hébergés sur une architecture Domino :
Cet article présente un des modes de mise en cluster de serveurs de messagerie instantanée IBM/LOTUS SAMETIME.
( http://www-306.ibm.com/software/lotus/sametime/ )
Il existe deux manières principales de gérer la mise en grappe (clustering) de communautés de serveurs Sametime hébergés sur une architecture Domino :
- le clustering des services de réunions.
- la mise en grappe sans clustering du
service de réunions en ligne, seuls les services de communautés sont implémentés
en mode Grappe
La deuxième option est celle que j'aborde dans cet article
...
...
Première méthode : clustérisation des services de Réunions
Cette première méthode permet de disposer d'un taux élevé de disponibilité des services de réunions Sametime.
Le principe d'architecture est de disposer d'un serveur dédié à la gestion de la Grappe Sametime (je préfère utiliser le terme de Grappe plutôt que de Cluster afin qu'il n'y ait aucune confusion terminologique avec du clustering système ou matériel).
Ce serveur dédié est le point réseau central d'accès aux services Sametime. Il sert de redirecteur vers deux serveurs Sametime ou plus (dans la limite, si ma mémoire est bonne, de 6 serveurs pour une Grappe de serveurs Domino).
Le serveur serveur cenral doit exécuter Sametime Enterprise Meeting server et devient le pivot central d'accès aux réunions. Toute requête émise sur un des serveurs satellites est préemptivement traitée et redirigée par le serveur Enterprise Meeting server.
Deuxième méthode : clustérisation de communauté Sametime
Cette méthode permet la mise en Grappe des services de communautés :
Les réunions, dans cette méthode, ne fonctionnent pas en Grappe.
Une réunion peut cependant avoir lieu simultanément sur deux serveurs afin, par exemple, d'optimiser la bande passante ou les temps de réponse en permettant aux utilisateurs d'un LAN de se connecter à la réunion depuis le serveur de leur propre LAN, ou tout simplement d'équilibrer la charge entre les serveurs ou offrir une meilleure tolérance aux pannes....
Il n'est pas nécessaire de planifier les réunions sur les deux serveurs.
Ce sont les serveurs qui s'auto-invitent aux réunions planifiées afin qu'elles puissent avoir lieu simultanément sur différentes machines. Cette configuration s'appuie sur des documents de connexion Sametime entre les différents serveurs.
L'exemple présenté dans cet article traite donc de cette deuxième méthode de configuration :
Première méthode : clustérisation des services de Réunions
Cette première méthode permet de disposer d'un taux élevé de disponibilité des services de réunions Sametime.
Le principe d'architecture est de disposer d'un serveur dédié à la gestion de la Grappe Sametime (je préfère utiliser le terme de Grappe plutôt que de Cluster afin qu'il n'y ait aucune confusion terminologique avec du clustering système ou matériel).
Ce serveur dédié est le point réseau central d'accès aux services Sametime. Il sert de redirecteur vers deux serveurs Sametime ou plus (dans la limite, si ma mémoire est bonne, de 6 serveurs pour une Grappe de serveurs Domino).
Le serveur serveur cenral doit exécuter Sametime Enterprise Meeting server et devient le pivot central d'accès aux réunions. Toute requête émise sur un des serveurs satellites est préemptivement traitée et redirigée par le serveur Enterprise Meeting server.
Deuxième méthode : clustérisation de communauté Sametime
Cette méthode permet la mise en Grappe des services de communautés :
- présentiel
- messagerie instantanée
- etc
Les réunions, dans cette méthode, ne fonctionnent pas en Grappe.
Une réunion peut cependant avoir lieu simultanément sur deux serveurs afin, par exemple, d'optimiser la bande passante ou les temps de réponse en permettant aux utilisateurs d'un LAN de se connecter à la réunion depuis le serveur de leur propre LAN, ou tout simplement d'équilibrer la charge entre les serveurs ou offrir une meilleure tolérance aux pannes....
Il n'est pas nécessaire de planifier les réunions sur les deux serveurs.
Ce sont les serveurs qui s'auto-invitent aux réunions planifiées afin qu'elles puissent avoir lieu simultanément sur différentes machines. Cette configuration s'appuie sur des documents de connexion Sametime entre les différents serveurs.
L'exemple présenté dans cet article traite donc de cette deuxième méthode de configuration :
- l'installation d'une communauté de deux
serveurs Sametime en mode 'Cluster sans support des services de réunions'.
Montage d'une communauté Sametime clusterisée sans service de Réunions
1. Configuration d'une Grappe Domino
Le montage de cette configuration nécessite que, au préalable, une Grappe (un Cluster en Anglais) de serveurs Domino ait été configuré dans la limite maximum de 6 serveurs en Grappe (limite imposée par les grappes Domino).
La déclaration d'une Grappe s'effectue très simplement dans Domino.
Il suffit, pour créer la Grappe, se sélectionner un document serveur dans l'annuaire, puis de cliquer sur l'action Ajouter à la grappe.
La fenêtre de dialogue suivante permet de créer et de nommer la nouvelle Grappe.
Vous sélectionnez ensuite le document d'un des serveurs que vous souhaitez configurer en Grappe, puis vous répétez la même manipulation en sélectionnant le nom de la Grappe nouvellement créée dans la fenêtre de Nom de grappe.
Une petite réplication entre les membres de la Grappe, un tout petit peu de patience, puis la Grappe s'initialise toute seule.
Simple non ?
;O°
Les options avancées de configuration de Grappe seront abordées dans un prochain article.
2. Equilibrer la charge entre les serveurs Domino
L'équilibre de charge, ou la bascule entre serveurs, peut s'appuier sur différentes solutions réseau.
Par exemple sur des fonctionnalités de tourniquet DNS, ou Round Robin (des bois). Attention au cache DNS côté client.
Pour assurer un minimum d'équilibre de charge, vous déclarez un alias dans DNS afin de référencer la communautés Sametime. Par exemple, sametime.mondomaine.fr pointant aussi bien sur l'adresse du premier que du deuxième serveur de la communauté.
Attention à la gestion de cache dans DNS : si les résultats de requêtes sont stockés trop longtemps en cache, cela aura une incidence sur l'équilibre de la charge. Définissez une durée de vie maximale de 1 seconde aux entrées de cache DNS.
Le nom d'Alias affecté dans DNS à la communauté Sametime est le nom que vous pourrez référencer via les politiques Domino (paramètres de Bureau) afin de l'affecter aux stations de travail Lotus Notes.
3. Installation de Sametime
Pour configurer la communauté Sametime avec, par exemple, deux serveurs, il faut que les deux serveurs Domino soient déclarés sur le même domaine Notes.
L'installation de Sametime en surcouche à chacun de ces deux serveurs ne présente aucune différence avec l'installation d'un serveur Sametime unique.
Les deux serveurs doivent pouvoir répliquer l'annuaire Domino du domaine, et ce même si l'on a choisi de configurer Sametime avec un annuaire LDAP.
4. Communications entre les serveurs
Les deux serveurs Domino doivent pouvoir communiquer sur les ports suivants : - port 1516 : c'est le port par défaut de gestion de la communauté Sametime
- port 1503 : le port par défaut pour les services de réunions en communautés de serveurs
- et de manière classique le port 1352
: requis pour tous les échanges Domino entre les deux serveurs (la réplication
par exemple).
5. Bases à répliquer entre les serveurs
Les bases suivantes doivent être des répliques l'une de l'autre dans le contexte d'une communauté de serveurs Sametime. - la base vpuserinfo.nsf : base de stockage des listes de contacts et des informations privées des utilisateurs Sametime
- le fichier names.nsf : l'annuaire Domino. Les deux serveurs ayant été enregistrés dans le même domaine, on peut déduire que l'annuaire d'un des serveurs est obligatoirement une réplique de celui de l'autre serveur.
- la base stnamechange.nsf : base
en charge des requête de changements de noms Sametime.
Assurez vous que ces trois fichiers soient bien répliqués et réplicables entre les deux serveurs de votre communautés. Si vous avez affaire à des copies de bases (non réplicables), remplacez les par des répliques (c'est le cas pour le fichier vpuserinfo.nsf)
La base vpuserinfo.nsf doit être répliquée très rapidement entre les deux serveurs.
Si les temps de propagation des modifications vous semblent trop longs, vous pouvez modifier la variable VP_OD_CACHE_AGE du fichier sametime.ini en lui affectant, en minutes, la valeur maximale de temps que vous souhaitez accorder aux serveurs pour échanger toutes modifications devant être répliquée.
Ce paramètre n'est à modifier que si vous constatez des problèmes de délai de mise à jour d'informations de confidentialité/disponibilité utilisateur d'un serveur de la communauté à l'autre.
Il est également souhaitable de répliquer la base stauths.nsf.
6. Déclaration du cluster au niveau de Sametime
Vous devez créer un document de cluster dans la base de configuration Sametime, stconfig.nsf.
Le document de cluster doit définir : - le nom du cluster qui héberge la communauté Sametime
- le nom des serveurs Domino qui participent à la communauté
- le nom DNS affecté à la communauté pour
l'équilibre de charge
ATTENTION, la base de configuration, stconfig.nsf, est propre à chaque serveur de la communauté et ne doit surtout pas être répliquée ni réplicable dans le cluster. Il vous faudra donc recopier le document de cluster que vous venez de créer dans les bases de configuration stconfig.nsf de l'ensemble des serveurs de la communauté Sametime.
7. Interconnexion des serveurs Sametime
Dernière étape afin de rendre la configuration opérationnelle : l'interconnexion.
Les serveurs Sametime doivent être connectés (de manière logique, dans l'annuaire Domino) à l'aide de documents de connexion.
Vous devez disposer, pour deux serveurs Sametime, de deux documents de connexion afin que l'interconnexion soit bi-directionnelle.
La méthode la plus simple, pour créer ces connexions, est de travailler à partir de la console Web d'administration de vos serveurs Sametime, menu Configuration \ Connectivité.
Pour aller plus loin...
Il existe beaucoup d'autres options de configuration et d'optimisation de Grappes Domino Sametime (comme par exemple l'optimisation des multiplexeurs...).
Pour aller plus loin, vous pouvez vous référer au centre de documentation Sametime sur les sites IBM :
http://publib.boulder.ibm.com/infocenter/sametime/v8r0/index.jsp
- 
