j'ai parlé de tiny-ldap parce que le trouvais que openldap etait tres lent quand il y a plein de requetes.
pour ce qui est du heartbeat, si heartbeat permet de prendre 2 machines pour n'en presenté qu'une ... , tu peux prendre 4 machines qui vont faire 2 qui vont faire une ( configuration tres moisi par contre ). reste comme alternative, puisque LDAP est un protocole qui peut etre synchrone ou non, mettre un "dispatcher" en heartbeat qui interroge autant de LDAP que tu veux ... l'overhead par requete etant faible tu pourras tenir une forte charge sans trop de difficulté.
pour ce qui est d'un environnement totalement LDAP , tu peux tout mettre sous LDAP. un probleme restera, l'interface d'administration. as tu une interface d'admin autre que de tout faire à la mano ? au moins des scripts de base pour les opérations les plus frequentes ?
Pour avoir regardé un peu partout, les schemas GOSA sont pas trop mal mais il faut quand meme les completer.
Ce qui revient a dire que tu dois penser FROM SCRATCH tes structures de données car quand tu auras tout mis en prod, tu ne pourras pas faire "oups, j'ai oublié un truc faut tout refaire".
à contrario, OpenLDAP etant un escargot niveau performance, j'ai du me resoudre d'abord avec du tiny-ldap puis quand je me suis rendu compte que je restaurais trop souvent les bases openldap alors que le probleme n'était ni un probleme hardware ni systeme ... je suis passé à contre coeur à une solution à base de SGBD-SQL :'(
pam et nss ont des implementation qui permettent d'interoger des SGBD-SQL.
des que je trouve le redhat-directory-server en {debian,Ubuntu} stable, je ferai un test car à l'époque ou c'était un produit Netscape, c'était la meilleur implementation LDAP du marché.
[^] # Re: slapd + slurpd + heartbeat + lvs < enclume pour écraser une mouche ?
Posté par Mouns . En réponse au message libnss-ldap avec plusieurs serveurs ldap. Évalué à 2.
pour ce qui est du heartbeat, si heartbeat permet de prendre 2 machines pour n'en presenté qu'une ... , tu peux prendre 4 machines qui vont faire 2 qui vont faire une ( configuration tres moisi par contre ). reste comme alternative, puisque LDAP est un protocole qui peut etre synchrone ou non, mettre un "dispatcher" en heartbeat qui interroge autant de LDAP que tu veux ... l'overhead par requete etant faible tu pourras tenir une forte charge sans trop de difficulté.
pour ce qui est d'un environnement totalement LDAP , tu peux tout mettre sous LDAP. un probleme restera, l'interface d'administration. as tu une interface d'admin autre que de tout faire à la mano ? au moins des scripts de base pour les opérations les plus frequentes ?
Pour avoir regardé un peu partout, les schemas GOSA sont pas trop mal mais il faut quand meme les completer.
Ce qui revient a dire que tu dois penser FROM SCRATCH tes structures de données car quand tu auras tout mis en prod, tu ne pourras pas faire "oups, j'ai oublié un truc faut tout refaire".
à contrario, OpenLDAP etant un escargot niveau performance, j'ai du me resoudre d'abord avec du tiny-ldap puis quand je me suis rendu compte que je restaurais trop souvent les bases openldap alors que le probleme n'était ni un probleme hardware ni systeme ... je suis passé à contre coeur à une solution à base de SGBD-SQL :'(
pam et nss ont des implementation qui permettent d'interoger des SGBD-SQL.
des que je trouve le redhat-directory-server en {debian,Ubuntu} stable, je ferai un test car à l'époque ou c'était un produit Netscape, c'était la meilleur implementation LDAP du marché.