O openldap é adequado para grandes implementações de produção?

Question

Por cerca de 1 ano, usamos openldap em ubuntu server 10.04LTS para autenticar cerca de 20 usuários de TI e tudo foi executado corretamente (as operações no servidor LDAP limitaram-se basicamente à criação / remoção de usuários usando o estúdio de diretórios do apache ).

Mais recentemente (6 meses atrás) também começamos a implementar openldap (openldap-2.4.21 / debian) como um sistema de autenticação externo para o nosso site que está sendo migrado de um CMS externo para uma nova plataforma que ' Estamos desenvolvendo internamente usando Drupal CMS . Temos um banco de dados de 45 mil usuários e as coisas não correram bem. Problemas que tivemos são:
- Falha do ldap após uma restauração de backup, que precisa ser recuperada .
- a ferramenta de recuperação do ldap incapaz de recuperar o banco de dados do ldap em algumas ocasiões
-slapd consumindo 100% de CPU enquanto não há atividade de autenticação no site.

Devido à falta de recursos e conhecimento interno, tudo o que fizemos até agora é encontrar maneiras de manter o LDAP em execução sem realmente investigar qualquer um desses problemas (use monit para reiniciá-lo quando ele falhar, db_recover para recuperar o banco de dados, se necessário, e slapcat para recriar o banco de dados a partir do zero quando db_recover falhar).

Recentemente, tivemos uma rodada de entrevistas para contratar um engenheiro de infra-estrutura sênior para nos ajudar com as várias infra. questões que estamos correndo. Vários candidatos confirmaram que já tiveram ou ouviram falar sobre problemas com openldap em grandes ambientes de produção e nunca conseguiram criar um único servidor openldap autônomo estável, mas precisaram criar implementações redundantes (replicação, balanceamento de carga, rotinas de recuperação automática / reinicialização) para manter o ldap em execução. Alguns candidatos até disseram que openldap simplesmente não era adequado para ambientes de produção e que, em vez disso, era necessário usar alternativas como Novel eDirectory .

P: Se você tem experiência em lidar com ldap em ambientes de produção com milhares de usuários, você tem fatos para compartilhar que tendem a provar que openldap é realmente instável para tais configurações e que usando outros servidores ldap são realmente recomendados?

    

Answer 1

Eu uso o OpenLDAP suportando uma base de usuários de cerca de 10.000 usuários ativos que dependem dele durante todo o dia para tudo. Problemas são raros. Muitos serviços dependem disso, para autenticação e outras coisas.

No entanto, temos quatro réplicas somente leitura (escravos / consumidores) atrás de um balanceador de carga, um mestre oculto e um mestre de espera quente. Costumava ser dois servidores front-end, mas tínhamos problemas de carga durante determinados horários de pico (quando cerca de 4.000 desses usuários estavam tentando desesperadamente atingi-lo no mesmo segundo). Todo o acesso de gravação ao LDAP é através do nosso código.

Esse equipamento e sistema operacional são todos antigos e estamos trabalhando para substituí-lo por uma nova configuração que vai voltar para apenas 2 réplicas (que não estão fazendo tantas outras coisas) e replicação "modo espelho" entre um par de mestres em uma configuração HA. Mais uma vez, problemas são raros.

Nós costumávamos ter alguns problemas com a replicação falhando, mas isso é principalmente a partir de quando estávamos usando o slurpd em vez do syncrepl. Além disso, os desligamentos não limpos de um servidor podem corromper os dados.

Chaves para executar o OpenLDAP em um ambiente de produção em larga escala, na minha experiência:

1. Alguém que entende bem o LDAP e o OpenLDAP . De preferência, mais de um alguém.
2. Alguém que entende bem todas as outras partes diretamente relacionadas da infraestrutura.
3. Alguém que entenda como a replicação OpenLDAP funciona.
4. Um entendimento razoável das opções do BerkeleyDB (ou de qualquer back-end que você esteja usando), já que os padrões não são muito certos.
5. Escravos altamente disponíveis . Mais de 1. Melhor: realmente com carga balanceada.
6. ** mestres ativos-passivos (replicação mestra ativa-ativa é inerentemente complicada)
7. Fazemos backup de dados do LDAP para LDIF a cada hora e mantemos alguns dias no disco. (todo o servidor é copiado para backup todas as noites)
8. Temos scripts para rapidamente trazer um escravo quebrado de volta para uma réplica de dados atual limpa
9. Temos scripts para rapidamente restaurar um master quebrado a partir dos backups LDIF (via slapadd)
10. Podemos alternar rapidamente para o mestre em espera . (scripts)
11. Monitoramos que as conexões de replicação estão ativas
12. Monitoramos que os IDs de replicação são atuais em todos os escravos
13. Monitoramos (com menos frequência) que todo o conteúdo dos escravos corresponde ao mestre.

Basicamente, se é uma parte fundamental da sua infraestrutura, alguém em sua equipe deve realmente entender bem.

Adendo : Por solicitação, o arquivo DB_CONFIG do meu diretório DB openldap. Veja o link para obter detalhes.

set_cachesize 0 536870912 1
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_WRITE_NOSYNC
set_lg_regionmax 268435456
set_lg_max 536870912
set_lg_bsize 134217728