mise en place de cluster

[adri1]

Bonjour à tous
ma boite me demande de mettre en place un cluster Domino.
J'ai déjà regardé sa mise en place et cela à l'air assez simple.
Je voudrais faire la manipulation suivante:
création du nouveau serveur dans l'environnement lotus (id...)
installation d'un nouveau serveur Windows et copie du répertoire data de mon premier serveur sur le nouveau
installation de lotus en spécifiant le répertoire data qui aura été copié et configuration de la sortie smtp
mise en place du cluster.
modification des doc de réplication entre les serveur webmail et blackberry pour qu'il pointe vers le cluster et non le premier serveur de messagerie.
Pouvez vous me dire si cela vous parait correcte et si il y a certaine chose à mettre en place durant cette manipulation (exemple suppression de la base de log provenant de mon serveur 1 sur le nouveau serveur )?
De plus si vous aviez par hasard une petite doc la dessus cela pourrait vraiment m'arranger?
Merci d'avance
@dri1

[Michael DELIQUE]

un peu vieux mais ça pourrait t'etre utlie => http://forum.dominoarea.org/downloads,v ... _id,1.html

[Reg]

Je n'ai jamais procéder de cette façon (copier le répertoire Data). Pas certain que le Cluster Directory va se remplir....

[albert.coeffard]

Ci joint mes notes lors de la mise en cluster de mes serveurs.

Il faut une adresse IP et un port dédiés, avec un réseau très haut débit(Cluster infaisable via ligne type transpac)
Par défaut dés que 2 serveurs sont mis en clusters toutes leurs bases sont mutualisées,
CLDBDIR(catlogue du cluster) et CLDBREP(Replication du cluster) sont 2 taches qui tournent sur des serveurs en clusters, CLDBDIR alimente la base CLDBDIR.nsf elle répertorie l'ensemble des bases existantes pour en faire une synchro c'est dans cette base que l'on désactivera les bases à ne pas synchroniser (exemple log.nsf,mail.box*) la synchro se fait en permanence via le VLAN d'où l'importance d'un bon débit.
* Lors de l'installation il faut désactiver toutes les tables sauf admin4,names,clubusy,cldbdir

Les deux serveurs gèreront également un équilibrage de charge. Cela ne dispense pas de la réplication classique entre les 2 serveurs, la réplication cluster étant minimaliste (pour exemple on n'a pas la réplication des suppressions, ni la réplication des documents modifiés la veille si un des 2 serveurs a été indisponible sur plusieurs jours) Les documents de connection devront intégrer en plus les réplications des bases mails et des bases spécifiques aux sites. Les bases à inscrire dans le cluster sont fonction de la qualité de service souhaitée.
Le cluster permet également d'arrêter un des deux serveurs de faire une migration sur celui qui est arrêté de le tester, et de le remettre en ligne et faire la migration dans un second temps sur l'autre.
Mise en oeuvre:
Sélectionner les serveurs concernés,
Faire Ajouter à la grappe
Nommer la grappe (CLUSTER_SIEGE)
avec la passerelle en amont si elle est capable de gérer les DNS, sinon il faut passer par un round robin DNS.(voir avec DC)
Autre solution élément physique à ajouter après le router qui fera du round robin sur un serveur, puis l'autre si l'un ne répond pas il envoie sur l'autre. Si ce boitier flash on perd la fonctionnalité courrier entrant en attendant le redémarrage.

Pour la réplication du cluster il faut définir un port dédié(clic droit sur serveur1 puis propriétés)
(Les agents ne participent pas au cluster (exemple agent d'absence ne tournera que sur le serveur de messagerie de la personne, donc plus de message de notification d'absence), il y a possibilité de télécharger un logiciel sur openntf gérant ce défaut.)
Une fois les Ports de communication déclarés il faut cloisonner les adresses IP
Sur la console Domino Administrator serveur1 taper :
Set config TCPIP_Tcpipaddress=0,10.50.2.102:1352
Set Config TCPIP_Tcpipaddress=0,172.16.1.1

Au final dans le notes.ini on doit voir se rajouter des lignes ayant cette syntaxe:
Ports=TCPIP,CLUSTER_SIEGE
SERVER_CLUSTER_ON=1
CLUSTER_SIEGE=TCP,0,15,0,,12288,
CLUSTER_SIEGE_TcpIpAddress=0,172.16.1.1:1352
Server_Cluster_Default_Port=CLUSTER_SIEGE
TCPIP_TcpIpAddress=0,10.50.2.102:1352
Dans le document serveur il faut ajouter le port et l'activer.

[LotuSmile]

Ces infos sont interessantes. Merci.
J'ai un serveur virtualisé que je compte clusterisé. Pour cela, je pourrais monter un nouveau serveur notes virtuel ou monter une copie de mon domino VM. (Et après je créé la grappe.)
qu'est ce que vous en pensez de la méthode pour créer le second domino? Des retours d'expérience?

Merci d'avance.

[albert.coeffard]

Pour ma part j'utilise 2 serveurs virtualisés sur deux blades différents, ça fonctionne bien excepté en client 6.5.3 ou le verrouillage de documents reste propre à chaque serveur d'où de temps en temps des conflits à gérer. A part celà c'est magique si un serveur tombe l'autre prend la relève sans que les utilisateurs s'en rendent compte, seul bémol les dossiers privés ne répliquent pas et une fois le serveur en faute redémarré les utilisateurs restent sur le serveur de secours hors mis pour leur base courrier. D'ailleurs si quelqu'un aurait fait un script permettant de redéfinir les signets de l'espace de travail pour les rediriger par défaut sur le serveur de messagerie de la personne je suis preneur.

[johnmacfly]

Ces infos sont interessantes. Merci.
J'ai un serveur virtualisé que je compte clusterisé. Pour cela, je pourrais monter un nouveau serveur notes virtuel ou monter une copie de mon domino VM. (Et après je créé la grappe.)
qu'est ce que vous en pensez de la méthode pour créer le second domino? Des retours d'expérience?

Merci d'avance.

Salut,

En matière de retour d'expérience, je te conseille vivement de dégager les *.box, les *.nsf, les *.ncf, les *.id et de supprimer les lignes du notes.ini avant "$$HasLANPort=1" afin que ton deuxieme serveur se reconfigure et récupère les infos de l'ID serveur que tu auras créés depuis le premier serveur... Ce sera infiniment + propre et tu te sortiras de quelques sacs de noeuds

++

[LotuSmile]

Salut,

En matière de retour d'expérience, je te conseille vivement de dégager les *.box, les *.nsf, les *.ncf, les *.id et de supprimer les lignes du notes.ini avant "$$HasLANPort=1" afin que ton deuxieme serveur se reconfigure et récupère les infos de l'ID serveur que tu auras créés depuis le premier serveur... Ce sera infiniment + propre et tu te sortiras de quelques sacs de noeuds

++

Je ne comprends pas trop ce que tu veux faire. Supprimer les *.nsf??? Tu supprimes Domino là. On plombe tout.
Dans mon cas, je veux clusterisé un serveur d'application et qui fait un peut de SMTP.

Ce que je compte faire c'est:
- Enregistrer un nouveau serveur (qui sera clusterisé) sur le serveur d’administration
- configuration du doc serveur
- installation de Domino comme serveur additionnel
- Gestion LCA des bases d'admin, monitoring et logs
- Réplication des bases d'admin
- Mise en grappe

Enfin, je réplique les bases applicatives du serveur d'application vers ce nouveau serveur clusterisé.

Si tout est ok alors j'optimiserai la grappe: Lan privé, cluster replicator, maxusers, seuil availabilité...

Qu'est ce que vous en pensez?

[Bidouille]

@LotuSmile

formate tout ce sera vachement propre (surtout ton bureau et tes tiroirs !! )

Désolé

[johnmacfly]

Re,

LoL pour le formatage... c sur que vu comme ça

Non mais je voulais dire par suppression des *.nsf : names, admin4, events4, euh... j'en oublis sûrement vu l'heure, mais quand même pas tes bases applicatives rhoooo ...

J'avoue que c'est un excès de prudence et que ton plan peut tout aussi bien marcher sans mes préco

Voila, good night et à demain ! (faut que j'aille surveiller mes encheres ebay sinon on va me les rafler !)

[LotuSmile]

ok Merci johnmacfly.

Sinon une fois le cluster monté, je pense répliqué les bases avec un autre domaine externe. Donc mise en place de cross-certif... Concernant la replication entre ces domaines, dans le doc de replication je compte plutot ajouter mon nom de cluster comme serveur source. Mieux vaut - il pas plutot utiliser le nom d'un des serveurs du cluster ? Qu'en pensez vous?

[johnmacfly]

Re (a y é, article ebay in zeupocket),

Tu garderas quand même un avantage à t'adresser à l'une des X machines du cluster (y en aura toujours une de libre). Pour cela, il te suffit de créer un groupe de type serveur (important, sinon ça marche pas) et d'y mettre tes X machines du cluster destinataire dedans. Si tu veux, tu peux mettre le nom du cluster comme nom de groupe mais ce sera 1 des serveurs du groupe qui sera invoqué et non pas le cluster en tant que son nom invoqué... bon... je crois que tu m'as compris

Naturellement, il te faudra un doc de connexion pour chaque serveur du cluster pour que ta machine du domaine externe connaissent la route ...

Bonne nuit !

[LotuSmile]

johnmacfly.

Donc pour toi concernant le document de connexion entre 2 serveurs cross-certifiés, il est plutot recommandé de pointer sur 1 serveur du cluster plutot que sur un groupe server cluster?

Quel est la différence de comportement si l'un des 2 serveurs du clusters tombent?
Le serveur du Domaine A va-t-il se connecter directement sur le serveur2 clusterisé du domaineB si serveur1 DomaineB tombe? (cluster.ncf)

[johnmacfly]

Salut,

Aïe... non, c'est l'inverse ... me suis mal exprimé (il était tard)...moi je fais la connexion sur les serveurs du cluster.

C'est juste que la réplication se fait par rapport à un groupe de serveurs (où se trouvent fortuitement les machines du cluster visé ) et non pas au nom du cluster...

Illustration : mon cluster du domaine DOM1 s'appelle CLU_PARIS, il est composé des noeuds PARIS01 et PARIS02. Depuis le domaine DOM2, je créé un groupe de serveurs où je met les noms de PARIS01 et PARIS02 et que je nomme GRP_PARIS. Et bien quand je vais répliquer X ou Y bases, je vais demander à mon serveur sur DOM2 de répliquer avec le groupe GRP_PARIS... MAIS pour une meilleure compréhension, je vais appeler le groupe sur DOM2 CLU_PARIS... alors que les membres de ce groupe de serveurs pourrait être n'importe quelle machine...

C'est plus clair ?...

++

[LotuSmile]

ok Merci.

Dans tous les cas, ton serveur sur DOM2 verifie dans sa Cluster.ncf si le ou les serveurs destinataires fait partie d'un cluster. Donc si le document connexion pointe uniquement sur 1 serveur (PARIS01 ou PARIS02) le fail over se produira également.
C'est a dire que si PARIS01 est le destinataire et est indisponible alors PARIS02 reprendra le relais automatiquent de facon transparente pour serveur DOM2.

Je pense que les 2 cas sont ok. Des retours d'experiences?