Dimanche, 21. Aout 2005
Cluster Domino : Optimisation et équilibrage de charge
Cet article vous donne les principaux points à aborder avant la mise en place d’un cluster sous Domino. Ces points parfois non documentés sont fondamentaux au bon fonctionnement d’un cluster. Nous allons aborder l’équilibrage de charge et l’optimisation. Le lecteur doit déjà avoir une connaissance générale du clustering Domino avant d’aller plus en avant dans cet article
Versions
Toutes les versions sont concernées (V4.6 -> V6). Il n’y a pas de différence structurelle entre ces versions. Pour ce qui est des performances la V6 et V5 dépasse nettement la V4.6. Cette différence est principalement du aux fonctionnalités supplémentaires de la V5 (et forcément de la V6) tel que la journalisation des transactions et aux optimisations générales apportée à ces versions.
Equilibrage de charge
Dans une grappe Domino, si un membre de la grappe tombe, un autre membre de la grappe récupère d'une manière transparente la charge de travail de son homologue. Cette action s'appelle le failover. Les informations sur l’état des serveurs à l’intérieur d’une grappe sont mise à jour fréquemment. La redirection est une fonction du gestionnaire de grappe.
Pour optimiser la charge de travail, vous pouvez employer les trois techniques suivantes:
1. Répartition des bases de données dans la grappe :
Pour les clusters constitués de deux serveurs, il est évident que cette analyse n’est pas nécessaire. Dans le cas d’application multi-base ou de clusteur abritant plusieurs applications, il est fondamental de réfléchir à la répartition de ces bases dans la grappe. En effet, toutes les bases ne sont pas sollicitées de la même manière. La répartition doit ce faire précisément suivant la charge de chaque base. La difficulté réside en cette évaluation. La participation du concepteur des bases à ce choix est primordiale. Pour ce qui est des bases systèmes et mails on connaît par expériences les plus sollicitées. Il faut aussi prendre en compte le stress naturel de chaque serveur. Ce stress pourrait devenir important si un serveur est surchargé de taches annexes au clustering (HTTP, LDAP, POP3, etc….). Il est tout de même fortement recommandé de libérer les serveurs d’une grappe du maximum de tâche administrative. Il est évident que la puissance de chaque serveur doit également être prise en compte. Cette évaluation est primordiale car une mauvaise répartition peut dégrader fortement les performances et dans le cas d’une montée en charge saturer rapidement le cluster.
2. Déterminer le seuil pour lequel le serveur est considéré occupé :
Chaque serveur dans une grappe détermine périodiquement sa propre charge de travail, basée sur le temps de réponse moyen des demandes récemment traitées par le serveur. Le server availability index (SAI) indique le taux d’occupation du serveur. L’ SAI est une valeur entre 0 et 100, où 100 indique un serveur légèrement chargé (temps de réponse rapides), et 0 un serveur fortement chargé (temps de réponse lents). Dans le NOTES.INI en insérant SERVER_AVAILABILITY_THRESHOLD (SAT), vous pouvez indiquer un seuil qui détermine la valeur la plus basse du SAI pour lequel le serveur n'est pas considéré "occupé". Si l’SAI va au-dessous de la valeur seuil, le serveur devient occupé. Un serveur dans l'état occupé réoriente les utilisateurs à un autre serveur de la grappe. SAI est dérivé du ratio entre le temps de réponse actuel et un temps de réponse optimum (sans transaction). Notez que les temps de réponse qui sont pris en considération sont les temps d’accès aux bases et n’inclus aucune considération sur le temps de réponse du réseau. Le processus de gestionnaire de grappe met à jours toute les 75 secondes le temps de réponse moyen donc le SAI. La valeur couramment utilisée pour le SAT est voisine de 95 (avec une optimisation correcte).
3. Fixer un nombre maximal d’utilisateur par serveur :
Dans NOTES.INI avec la variable SERVER_MAXUSERS, vous pouvez indiquer le nombre maximum d’utilisateurs permis par serveur. Quand le serveur atteint cette limite, il rejette les demandes de sessions supplémentaires. Ainsi, un failover est créé et redirige les utilisateurs vers un autre serveur de la grappe. Cette variable est aussi utilisée pour réorienter les utilisateurs quand un membre de la grappe a des ennuis.
Optimisation
L’optimisation est étroitement liée à la répartition de charge. Si cette répartition est défaillante, l’optimisation sera pratiquement obsolète. Il faut donc bien valider les points ci-dessus avant de s’attaquer à l’optimisation.
1. Fixer le Serveur_Transinfo_Normalize (STN): La valeur du STN est utilisée dans le calcul du SAI (voir ci-dessus). J’ai précisé que le SAI était dérivé du ratio entre le temps de réponse actuel et un temps de réponse optimum (sans transaction). Vous imaginez bien que ce temps de réponse optimum n’est pas le même suivant la puissance des machines. Le problème vient du fait que cette valeur n’est pas calculée par Domino, elle est fixé par défaut. La valeur du STN doit approcher au maximum la moyenne des transactions Domino (pour le serveur en question) en millisecondes multipliées par 100. Cette valeur est de 3000, ce qui correspond à un temps de réponse moyen de 30 millisecondes par transaction. Fixé par Lotus un STN de 3000 correspond au temps moyen de réponse des serveurs d’il y a quelques années et ne correspond plus aux machines actuelles.
Pour modifier cette valeur il faut intégrer dans le NOTES.INI la ligne suivante :
Server_TransInfo_Normalize = 400 (400 c’est pour l’exemple)
Si on laisse cette valeur de 3000, les serveurs actuels dépasseront le STN que lorsqu’ils seront lourdement chargé. En fait le SAI sera en quasi permanence à 100 et lorsqu’ils dépasseront le STN ils seront très vite à 0 !
Pour déterminer la meilleure valeur, le mieux c’est de comparer les graphes de l’éditeur de performance de NT en choisissant la variable SAI pendant que le serveur est en production. Faite varier la valeur du STN pour que la courbe soit la moins « rude » possible. Une fois le STN fixé, Choisissez un SAT correct.
Fig 1 avec le STN fixé à 1000 (le SAI est en blanc) Fig 2 avec le STN fixé à 600
Fig 3 Avec le STN à 600 et le SAT à 95
2. Configurer plusieurs CLREPL :
La tache CLREPL est lancée sur chaque serveur d’un cluster. Cette tache réplique « instantanément » toutes les modifications apportées aux bases du cluster. La majorité des clusters ne nécessite qu’une tache CLREPL mais dans certains cas l’ajout d’une ou de plusieurs taches supplémentaires sont conseillé. En fait rajouter une tache permet de traiter le double de transactions, une troisième le triple, etc….
Pour déterminer si votre cluster nécessite une ou plusieurs autres taches, consulté la variable Replica.Cluster.workQueueDepth lorsque votre cluster est en production. Cette variable indique le nombre de transaction de réplication en attente de traitement par la tache CLREPL. Si sa valeur est constamment supérieure à 0 alors rajouté une tache et reconsulté pour savoir si il en faut une de plus.
3. Constituer un réseau privé :
La constitution d’un réseau privé est conseillée car le cluster est très gourmand en bande passante. Vous éviterez ainsi de polluer tout votre réseau et à l’inverse que le trafic annexe au cluster vient ralentir celui-ci.
Pour constituer votre réseau vous devez :
· Installer sur chaque serveur une carte réseau supplémentaire indépendante.
· Attribuer ensuite une adresse IP appartenant à un réseau privé à chaque carte (Ex: 192.168.33.0).
· Renseignez les noms d’hôtes de chaque serveur et adresses IP dans les fichiers HOST (c’est inutile de configurer un serveur DNS…).
· Modifier le document serveur pour rajouter un nouveau port comme ci-dessous :
· Dans le NOTES.INI on associe au nouveau port nommé CLUSTER une adresse IP :
Au dessous de : TCPIP_TcpIpAddress=0,192.114.32.5 :1352
Rajouter : CLUSTER_TcpIpAddress=0,192.168.33.1 :1352
· Dans le NOTES.INI on indique le port par défaut utilisé par le cluster :
Server_Cluster_Default_Port=CLUSTER
· Redémarrer le serveur, attendre quelques minutes et taper consécutivement les commandes Show Cluster, Show Stat Network et Show Stat Replica puis contrôler les valeurs suivantes :
Show cluster :
Server cluster default port : CLUSTER
Show Stat Network :
NET.CLUSTER.BytesReceived = 9,568,623
NET.CLUSTER.BytesSent = 124,354,265
Show Stat Network :
Replica.Cluster.SessionBytes.In = 9103562
Replica.Cluster.SessionBytes.Out = 106456951
Il doit y avoir une corrélation étroite entre NET.CLUSTER.BytesReceived et Replica.Cluster.SessionBytes.In et entre NET.CLUSTER.BytesSent et Replica.Cluster.SessionBytes.Out. N’espéré pas des valeurs identiques, il y a toujours de la trame utiliser par les OS ou d’autre application.
Sources
Article de Harry Murray et Gary Sullivan Domino Clusters (Part1 et Part2) du 02/08/1999
Article de Michael Kistler Fine Points of Configuring a Cluster 1998
Versions
Toutes les versions sont concernées (V4.6 -> V6). Il n’y a pas de différence structurelle entre ces versions. Pour ce qui est des performances la V6 et V5 dépasse nettement la V4.6. Cette différence est principalement du aux fonctionnalités supplémentaires de la V5 (et forcément de la V6) tel que la journalisation des transactions et aux optimisations générales apportée à ces versions.
Equilibrage de charge
Dans une grappe Domino, si un membre de la grappe tombe, un autre membre de la grappe récupère d'une manière transparente la charge de travail de son homologue. Cette action s'appelle le failover. Les informations sur l’état des serveurs à l’intérieur d’une grappe sont mise à jour fréquemment. La redirection est une fonction du gestionnaire de grappe.
Pour optimiser la charge de travail, vous pouvez employer les trois techniques suivantes:
1. Répartition des bases de données dans la grappe :
Pour les clusters constitués de deux serveurs, il est évident que cette analyse n’est pas nécessaire. Dans le cas d’application multi-base ou de clusteur abritant plusieurs applications, il est fondamental de réfléchir à la répartition de ces bases dans la grappe. En effet, toutes les bases ne sont pas sollicitées de la même manière. La répartition doit ce faire précisément suivant la charge de chaque base. La difficulté réside en cette évaluation. La participation du concepteur des bases à ce choix est primordiale. Pour ce qui est des bases systèmes et mails on connaît par expériences les plus sollicitées. Il faut aussi prendre en compte le stress naturel de chaque serveur. Ce stress pourrait devenir important si un serveur est surchargé de taches annexes au clustering (HTTP, LDAP, POP3, etc….). Il est tout de même fortement recommandé de libérer les serveurs d’une grappe du maximum de tâche administrative. Il est évident que la puissance de chaque serveur doit également être prise en compte. Cette évaluation est primordiale car une mauvaise répartition peut dégrader fortement les performances et dans le cas d’une montée en charge saturer rapidement le cluster.
2. Déterminer le seuil pour lequel le serveur est considéré occupé :
Chaque serveur dans une grappe détermine périodiquement sa propre charge de travail, basée sur le temps de réponse moyen des demandes récemment traitées par le serveur. Le server availability index (SAI) indique le taux d’occupation du serveur. L’ SAI est une valeur entre 0 et 100, où 100 indique un serveur légèrement chargé (temps de réponse rapides), et 0 un serveur fortement chargé (temps de réponse lents). Dans le NOTES.INI en insérant SERVER_AVAILABILITY_THRESHOLD (SAT), vous pouvez indiquer un seuil qui détermine la valeur la plus basse du SAI pour lequel le serveur n'est pas considéré "occupé". Si l’SAI va au-dessous de la valeur seuil, le serveur devient occupé. Un serveur dans l'état occupé réoriente les utilisateurs à un autre serveur de la grappe. SAI est dérivé du ratio entre le temps de réponse actuel et un temps de réponse optimum (sans transaction). Notez que les temps de réponse qui sont pris en considération sont les temps d’accès aux bases et n’inclus aucune considération sur le temps de réponse du réseau. Le processus de gestionnaire de grappe met à jours toute les 75 secondes le temps de réponse moyen donc le SAI. La valeur couramment utilisée pour le SAT est voisine de 95 (avec une optimisation correcte).
3. Fixer un nombre maximal d’utilisateur par serveur :
Dans NOTES.INI avec la variable SERVER_MAXUSERS, vous pouvez indiquer le nombre maximum d’utilisateurs permis par serveur. Quand le serveur atteint cette limite, il rejette les demandes de sessions supplémentaires. Ainsi, un failover est créé et redirige les utilisateurs vers un autre serveur de la grappe. Cette variable est aussi utilisée pour réorienter les utilisateurs quand un membre de la grappe a des ennuis.
Optimisation
L’optimisation est étroitement liée à la répartition de charge. Si cette répartition est défaillante, l’optimisation sera pratiquement obsolète. Il faut donc bien valider les points ci-dessus avant de s’attaquer à l’optimisation.
1. Fixer le Serveur_Transinfo_Normalize (STN): La valeur du STN est utilisée dans le calcul du SAI (voir ci-dessus). J’ai précisé que le SAI était dérivé du ratio entre le temps de réponse actuel et un temps de réponse optimum (sans transaction). Vous imaginez bien que ce temps de réponse optimum n’est pas le même suivant la puissance des machines. Le problème vient du fait que cette valeur n’est pas calculée par Domino, elle est fixé par défaut. La valeur du STN doit approcher au maximum la moyenne des transactions Domino (pour le serveur en question) en millisecondes multipliées par 100. Cette valeur est de 3000, ce qui correspond à un temps de réponse moyen de 30 millisecondes par transaction. Fixé par Lotus un STN de 3000 correspond au temps moyen de réponse des serveurs d’il y a quelques années et ne correspond plus aux machines actuelles.
Pour modifier cette valeur il faut intégrer dans le NOTES.INI la ligne suivante :
Server_TransInfo_Normalize = 400 (400 c’est pour l’exemple)
Si on laisse cette valeur de 3000, les serveurs actuels dépasseront le STN que lorsqu’ils seront lourdement chargé. En fait le SAI sera en quasi permanence à 100 et lorsqu’ils dépasseront le STN ils seront très vite à 0 !
Pour déterminer la meilleure valeur, le mieux c’est de comparer les graphes de l’éditeur de performance de NT en choisissant la variable SAI pendant que le serveur est en production. Faite varier la valeur du STN pour que la courbe soit la moins « rude » possible. Une fois le STN fixé, Choisissez un SAT correct.
Fig 1 avec le STN fixé à 1000 (le SAI est en blanc) Fig 2 avec le STN fixé à 600
Fig 3 Avec le STN à 600 et le SAT à 95
2. Configurer plusieurs CLREPL :
La tache CLREPL est lancée sur chaque serveur d’un cluster. Cette tache réplique « instantanément » toutes les modifications apportées aux bases du cluster. La majorité des clusters ne nécessite qu’une tache CLREPL mais dans certains cas l’ajout d’une ou de plusieurs taches supplémentaires sont conseillé. En fait rajouter une tache permet de traiter le double de transactions, une troisième le triple, etc….
Pour déterminer si votre cluster nécessite une ou plusieurs autres taches, consulté la variable Replica.Cluster.workQueueDepth lorsque votre cluster est en production. Cette variable indique le nombre de transaction de réplication en attente de traitement par la tache CLREPL. Si sa valeur est constamment supérieure à 0 alors rajouté une tache et reconsulté pour savoir si il en faut une de plus.
3. Constituer un réseau privé :
La constitution d’un réseau privé est conseillée car le cluster est très gourmand en bande passante. Vous éviterez ainsi de polluer tout votre réseau et à l’inverse que le trafic annexe au cluster vient ralentir celui-ci.
Pour constituer votre réseau vous devez :
· Installer sur chaque serveur une carte réseau supplémentaire indépendante.
· Attribuer ensuite une adresse IP appartenant à un réseau privé à chaque carte (Ex: 192.168.33.0).
· Renseignez les noms d’hôtes de chaque serveur et adresses IP dans les fichiers HOST (c’est inutile de configurer un serveur DNS…).
· Modifier le document serveur pour rajouter un nouveau port comme ci-dessous :
· Dans le NOTES.INI on associe au nouveau port nommé CLUSTER une adresse IP :
Au dessous de : TCPIP_TcpIpAddress=0,192.114.32.5 :1352
Rajouter : CLUSTER_TcpIpAddress=0,192.168.33.1 :1352
· Dans le NOTES.INI on indique le port par défaut utilisé par le cluster :
Server_Cluster_Default_Port=CLUSTER
· Redémarrer le serveur, attendre quelques minutes et taper consécutivement les commandes Show Cluster, Show Stat Network et Show Stat Replica puis contrôler les valeurs suivantes :
Show cluster :
Server cluster default port : CLUSTER
Show Stat Network :
NET.CLUSTER.BytesReceived = 9,568,623
NET.CLUSTER.BytesSent = 124,354,265
Show Stat Network :
Replica.Cluster.SessionBytes.In = 9103562
Replica.Cluster.SessionBytes.Out = 106456951
Il doit y avoir une corrélation étroite entre NET.CLUSTER.BytesReceived et Replica.Cluster.SessionBytes.In et entre NET.CLUSTER.BytesSent et Replica.Cluster.SessionBytes.Out. N’espéré pas des valeurs identiques, il y a toujours de la trame utiliser par les OS ou d’autre application.
Sources
Article de Harry Murray et Gary Sullivan Domino Clusters (Part1 et Part2) du 02/08/1999
Article de Michael Kistler Fine Points of Configuring a Cluster 1998
Commentaires
1. Olivier@Dominux 
12/09/2005 15:40:35
Toutes mes félicitations pour cet article qui présente assez clairement les points d'optimisations d'un cluster Domino.
2. Thierry 02/11/2006 18:43:48
Merci pour ton blug. Super interessant. Cela dit aurais tu écris quelque chose sur la msie en palce d'un cluster . J'entends system et applicatif (mscs et domino). J'ai du mal à avoir un vue globale seine entre ce que me dit mon fournisseur sur l'installation qu'il a effectué (et qui ne bascule pas en IMAP) et sur les pauvres docs que j'ai pu trouver sur le net à ce sujet.
E
3. samir 28/12/2006 14:39:31
salut je vous mercis , j'ai un probleme,dans un grappe le type des serveurs installée et ce ue ils sons des serveurs supplémentaire ou des erveurs enregistrer dans le serveur principale , est le type de réplication
A propos
- 
