Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

Attention, une faille de sécurité dans bash a récemment été rapportée, il est recommandé de mettre à jour son système (plus de détails) *** mise à jour 12/10/2014 ***

#1 Le 28/01/2013, à 14:21

benchacal

Ldap en cluster sur Ubuntu TLS 12.04

Bonjour à tous,

je suis benoît, 28ans et de nouveau sur les banc de l'école, et j'ai comme projet avec mon équipe de fournir à notre client un annuaire ldap consultable/administrable avec un interface web. Celui-ci désire que le serveur soit en "cluster" (quand l'un et HS l'autre prend le relais et on peu ECRIRE dedans). J'ai donc commencer à monter 2 serveur bien configurer, et j'ai monté drbd, la synchro se fait bien mais j'ai l'impression que je n'ai pas du tout pris la bonne voie... Je voulais installer openldap sur la partition drbd et avec heartbeat je voulais faire prendre le relais du service ldap par l'autre serveur... beaucoup de temps de perdu je pense...

J'ai cru comprendre que l'on pouvait mettre les serveurs en multi-maître mais je n'arrive pas à trouver de tuto pour ubuntu server et je ne suis pas un expert sur linux...

Pour vous, quelle solution adopteriez vous?

Merci d'avance à ceux qui lirons ceci.

Cordialement

Hors ligne

#2 Le 29/01/2013, à 23:24

JoelS

Re : Ldap en cluster sur Ubuntu TLS 12.04

Oui, c'est du temps perdu.

On ne monte pas un serveur LDAP en cluster de cette manière.

Les serveurs LDAP sont conçus pour supporter nativement la réplication au fil de l'eau, et la reprise de réplication en cas d'arrêt d'un des noeuds: c'est une configuration en maître-esclave. Par définition, l'esclave ne sert qu'en lecture, pas en écriture.

Les serveurs LDAP sont conçus pour supporter nativement la réplication croisée, et la reprise de réplication en cas d'arrêt d'un des noeuds: c'est une configuration en double-maîtres.  Par définition, les deux noeuds supportent les lectures et écritures et se répliquent mutuellement.

Enfin OpenLDAP supporte le mode mirroir: les 2 noeuds sont maîtres, mais un seul récupère les écriture, on bascule le mirroir de l'un à l'autre au moment voulu.

Tu peux combiner le mode multi maître et le mode maître esclave si tu veux de la redondance, de la répartition de charge et équilibrer un peu logiquement les accès: 2 noeuds maitres qui se répliquent mutuellement et qui répliquent sur 2 noeuds esclaves. La seule chose qui est gérée par le cluster est une bascule des adresses IP de service (ou la bascule du mode mirroir si tu optes pour ce mode la).

Je gère un gros annuaire au boulot dans ce mode avec pas mal de clients en lecture/écriture, et ça marche bien.

Hors ligne

#3 Le 30/01/2013, à 11:21

benchacal

Re : Ldap en cluster sur Ubuntu TLS 12.04

Merci joel,

j'ai cherché un peu partout dans les tuto de ubuntu-fr et je n'ai pas trouvé ce genre d'exemple (open-ldap maître-maître)... mais bon je vais essayer quand même :-)

Sinon pour basculer le miroir il faut utiliser un loadbalancer c'est ça? genre heartbeat?

Cordialement (et encore merci de ta réponse)

Hors ligne

#4 Le 30/01/2013, à 20:54

JoelS

Re : Ldap en cluster sur Ubuntu TLS 12.04

benchacal a écrit :

j'ai cherché un peu partout dans les tuto de ubuntu-fr et je n'ai pas trouvé ce genre d'exemple (open-ldap maître-maître)... mais bon je vais essayer quand même :-)
Sinon pour basculer le miroir il faut utiliser un loadbalancer c'est ça? genre heartbeat?

Heartbeat n'est pas un load-balancer, mais une solution de cluster logiciel. Dans heartbeat, tu définis des ressources et des groupes de ressources, tu dis sur quels noeuds ces ressources doivent être exécutées en priorité, comment heartbeat doit contrôler qu'elles sont disponibles, comment on doit les lancer et les arrêter. Si une ressource n'est plus la sur un des noeuds du cluster, alors heartbeat peut la relancer sur l'autre noeud.
Par exemple un file system réseau (sur un SAN par exemple ou en NFS) de données que tu veux rendre disponible sur un des noeuds uniquement tant que l'application qui écris dessus est active sur le noeud en question. Ou bien déplacer la déclaration d'une adresse IP entre les noeuds de ton cluster en fonction de la réponse ou nom d'un service applicatif. Dans ce dernier cas, par exemple tu déclares un adresse IP qui est rattachée à l'interface réseau du serveur A, tu fais en sorte que heartbeat contrôle que le service LDAP sur le serveur A répond, et dès qu'il ne répond plus, alors tu configure heartbeat pour qu'il arrête le rattachement sur le serveur A et qu'il monte le rattachement sur le serveur B (ou bien sûr un autre service LDAP configuré en mode multi-maitre avec le A fonctionne). Pour tes clients, il ne voit que du feu, même si tu arrêtes le service LDAP sur le A, l'adresse IP basculera, il y aura rupture de session uniquement pour les sessions en cours, mais pour les clients le service LDAP qu'ils voient sera toujours vivant. Tu peux aussi configurer heartbeat pour qu'il détecte au bout d'un moment que le A est revenu et qu'il re-bascule dessus si tu préfères (par exemple le A peut être plus performant que le B, mais tu n'as pas les ressources de mettre 2 serveurs de même puissance en ligne).

Un load-balancer (logiclel comme HAProxy ou matériel) va lui distribuer les requêtes qu'il reçoit sur plusieurs serveurs suivant sa configuration. Le choix peut être une répartition distribuée séquentiellement, ou bien en fonction du nombre de session, ou de la charge des serveurs. Ca répond à la problèmatique de montée en charge: si tu montes une solution avec load-balancer sur 2 serveurs final, alors il est en général très simple de rajouter une 3ième, un 4ième, ... sans que les clients s'en aperçoivent.

Attention suivant les confs, tu ne peux pas toujours garantir une non rupture de session en cas de bascule des flux réseaux. Certains couples load-balancer/cluster peuvent le faire, mais pas tous et pas dans tous les cas. De toute façon, aucune solution ne peut garantir que le réseau ne sera pas coupé entre le client et la solution, alors...

Bon je ne suis pas un spécialiste de HeatBeat/HAProxy, je fais confiance à mes admins Linux, moi je m'occupe plus du côté applicatif genre OpenLDAP. Si t'as d'autres questions, n'hésites pas, mais je ne suis pas tous les jours ce forum.

Hors ligne

#5 Le 01/02/2013, à 08:53

benchacal

Re : Ldap en cluster sur Ubuntu TLS 12.04

Bon j'ai bien cherché... le pb c'est que dans ma version j'ai plus de slapd.conf et je galère car je n'arrive a trouvé la nouvelle façon de configurer. Il faut faire des fichier ldif et les insérer dans l'annuaire

ici ya pas mal de paramètre pour le multi-maître mais c'est chaud je comprend pas tout... et je vois pas la différence avec le mode miroir
http://www.openldap.org/doc/admin24/replication.html

et ici il y a un bon tuto mais ils ne parlent pas de la réplication multi-maître...
http://doc.ubuntu-fr.org/openldap-server

je vais essayer de comprendre tout les paramètres et de me faire un fichier backend et frontend...

Allez au boulot!

Hors ligne

#6 Le 01/02/2013, à 12:07

benchacal

Re : Ldap en cluster sur Ubuntu TLS 12.04

En fait il fraudais que je trouve un backend et frontend (d'exemple) pour du multi-master...

Si quelqu'un à une idée... hmm

Hors ligne

#7 Le 02/02/2013, à 11:50

JoelS

Re : Ldap en cluster sur Ubuntu TLS 12.04

benchacal a écrit :

Bon j'ai bien cherché... le pb c'est que dans ma version j'ai plus de slapd.conf et je galère car je n'arrive a trouvé la nouvelle façon de configurer. Il faut faire des fichier ldif et les insérer dans l'annuaire
ici ya pas mal de paramètre pour le multi-maître mais c'est chaud je comprend pas tout... et je vois pas la différence avec le mode miroir
http://www.openldap.org/doc/admin24/replication.html
et ici il y a un bon tuto mais ils ne parlent pas de la réplication multi-maître...
http://doc.ubuntu-fr.org/openldap-server
je vais essayer de comprendre tout les paramètres et de me faire un fichier backend et frontend...
Allez au boulot!

Normal pour le slapd.conf: ça n'existe plus. Maintenant la config est gérée directement dans le LDAP, dans la branch cn=config.

Le principe: tu installes ton serveur, tu crées à la main un fichier LDIF contenant la config au format LDIF, tu fait un slapadd sur ta base en tant que root (le compte Unix), et la config est dans le serveur. La config contient aussi les définitions des droits d'accès à l'arbre LDAP de production (un truc du genre dc=MaSociete.fr), et aussi la déclaration du compte Manager de l'arbre de production. Ensuite tu peux gérer un certain nombre de paramètre avec un navigateur LDAP (mais pas tout quand même) si tu connait le mot de passe du compte cn=Config.

La différence en mode mirroir et mode multi-master est très fine. Il faut de toute façon déclarer le multi-master comme un mode mirroir, mais en plus mettre des réplicats dans les 2 sens. Le multi-master est un avantage si tu as une charge importante sur le maître que tu répartis alors avec un load-balancer (HAProxy pu BalanceNG par exemple). Ca permet d'être plus souple en production aussi (tu arrêtes un des 2 noeuds sans trop te préoccuper des impacts). Le miroir est plus "sûr" côté intégrité de données (un seul endroit ou les modifications arrivent) mais il faut être sûr qu'en cas de bascule des flux, tu récupères correctement tes petits.

Aprsè je comprend pas ta notion de back-end et front-end.

Hors ligne

#8 Le 02/02/2013, à 12:17

benchacal

Re : Ldap en cluster sur Ubuntu TLS 12.04

Merci Joel.

pour le backend et frontend c'est comme ça qu'ils appellent les fichier ldif dans les tuto. C'est juste la config du ldap (backend) et les données qu'il y a dedans pour le peupler (frontend). C'est juste
ldif mais au pire on s'en fou :-) je croyais que c’était un terme générique...  tongue

Sinon pour le reste j'ai bien tout compris encore merci. Mon seul problème aujourd'hui c'est que je trouve pas d'exemple de fichier ldif à injecter dans le cn=config pour un multimaster. Car ce n'est pas du tout pareil que l'ancien slapd.conf et c'est les seuls exemples que je trouve.... Je continue à chercher mais si quelqu'un à un exemple avec des commentaires je veut bien :-)

Je pense que je ferais un tuto en fr après :-) (à moins que j'ai loupé un truc et qu'il existe deja)

Hors ligne

#9 Le 02/02/2013, à 21:23

benchacal

Re : Ldap en cluster sur Ubuntu TLS 12.04

Bon j'avance mais la je suis carrément bloqué....

je résume: après l'installation de slapd et ldap-utils je fait un

sudo dpkg-reconfigure slapd

je configure tout bien et ça marche sur chaque serveur. Par contre la réplication c'est pas possible. Je m'explique.
dans les fichiers ldif que je charge avec:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f nomdufichier.ldif

j'ai la conf de base avec:

#Définition des Serveur ID
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://192.168.10.10:389
olcServerID: 2 ldap://192.168.10.11:389

#Le chargement du module syncprov.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

cela est bien pris en compte et ça fonctionne. Après je configure la réplication et la c'est le drame.

ça:

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

ça passe et ça:

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://192.168.10.10:389 binddn="cn=config" bindmethod=simple credentials=admin searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://192.168.10.11:389 binddn="cn=config" bindmethod=simple credentials=admin searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE

ça passe pas, il dit:

ldapadd: invalid format (line 6) entry: "olcDatabase={0}config,cn=config}

Quand je fait juste:

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://192.168.10.10:389 binddn="cn=config" bindmethod=simple credentials=admin searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://192.168.10.11:389 binddn="cn=config" bindmethod=simple credentials=admin searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1

ça passe mais après j'ai plus la main pour mettre

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

il me dit:

ldap_modify: Server is unwilling to perform (53)
                additional info: shadow context; no update referal

Ce que je comprend à cela c'est que le serveur est devenu esclave et qu'il ne peu plus écrire sur lui même à par si le master lui dit.

Edit: Une solution est de modifier directement dans olcDatabase={0}config et d'ajouter olcMirrorMode: TRUE, on redémarre le service slapd et on à repris la main

Donc je vais dans le fichier /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif, j'enlève les 2 lignes, je relance le serveur et ça repart.

Bloqué... si quelqu'un à une idée.

Et ça c'est juste pour le cn=config, après je doit faire de même pour les hbd hmm

Je sens que je vais y passer mon wd pour rien... Please... un âme charitable... et je ferais un joli tuto après big_smile

Dernière modification par benchacal (Le 03/02/2013, à 15:32)

Hors ligne

#10 Le 03/02/2013, à 15:29

benchacal

Re : Ldap en cluster sur Ubuntu TLS 12.04

Bon c'est bon pour la réplication. En faite je ne réplique pas le cn=config. Je fais juste une réplication miroir maître-maitre du olcDatabase={1}hdb.

Je vous met les fichier de conf pour les 2 nœud pour ceux qui on besoin. Il ne reste plus qu'a faire une ip virtuel et de mettre en place le load balancer.
N1.ldif:

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1

#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://192.168.10.11 binddn="cn=admin,dc=cci,dc=fr" bindmethod=simple credentials=admin searchbase="dc=cci,dc=fr" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

N2.ldif

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 2

#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://192.168.10.10 binddn="cn=admin,dc=cci,dc=fr" bindmethod=simple credentials=admin searchbase="dc=cci,dc=fr" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

ps: Sur ma version, le:

-
add: olcMirrorMode
olcMirrorMode: TRUE

ne fonctionne pas. Il faut spécificité le chemin en entier (sur un hdb ça fonctionne, dans le olcDatabase={0}config pour la réplication du cn=config ça ne fonctionne PAS!! il faut l'ajouter à la main et redémarrer le service (même si c'est interdit)):

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

Dernière modification par benchacal (Le 03/02/2013, à 15:35)

Hors ligne

Haut de page ↑