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

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

Há cerca de 1 ano que usamos openldapum ubuntuservidor 10.04LTSpara autenticar cerca de 20 usuários de TI e tudo está funcionando bem (as operações no servidor LDAP eram basicamente limitadas à criação/remoção de usuários usandoestúdio de diretório 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 externa para 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 estão indo bem. Os problemas que tivemos são:
-ldap travando após uma restauração de backup, precisando ser recuperado.
-a ferramenta de recuperação ldap não consegue recuperar o banco de dados ldap em algumas ocasiões
-slapd consumindo 100% da CPU enquanto não há atividade de autenticação no site.

Devido à falta de recursos e conhecimento interno, tudo o que fizemos até agora foi encontrar maneiras de manter o LDAP funcionando sem realmente investigar nenhum desses problemas (use monitpara reiniciá-lo quando ele travar, db_recoverpara recuperar o banco de dados se necessário, e slapcatpara recriar o banco de dados do zero quando db_recoverfalha).

Recentemente tivemos uma rodada de entrevistas para contratar um engenheiro de infraestrutura sênior para nos auxiliar em todas as diversas infra. problemas que estamos enfrentando. Vários candidatos confirmaram que tiveram ou ouviram falar de problemas openldapem grandes ambientes de produção e nunca conseguiram criar um único openldapservidor independente estável, mas em vez disso tiveram que criar implantações redundantes (replicação, balanceamento de carga, rotinas de recuperação automática/reinicialização ) para manter o ldap em execução. Alguns candidatos chegaram a dizer que openldapsimplesmente não era adequado para ambientes de produção e que, em vez disso, era necessário utilizar alternativas como essas 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 o uso de outros servidores ldap é realmente recomendado?

Responder1

Eu uso o OpenLDAP para oferecer suporte a uma base de usuários de cerca de 10.000 usuários ativos que dependem dele o dia todo para tudo. Os problemas são raros. Muitos serviços dependem dele para autenticação e outras coisas.

No entanto, temos 4 réplicas somente leitura (escravos/consumidores) atrás de um balanceador de carga, um mestre oculto e um mestre hot standby. Costumava haver dois servidores front-end, mas tivemos problemas de carregamento durante determinados horários de pico (quando cerca de 4.000 desses usuários tentavam desesperadamente acessá-lo no mesmo segundo). Todo o acesso de gravação ao LDAP é feito através do nosso código.

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

Costumávamos ter alguns problemas com falhas de replicação, mas isso ocorre principalmente quando usávamos o slurpd em vez do syncrepl. Além disso, desligamentos impuros 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 entenda LDAP e OpenLDAPbem. De preferência mais de um alguém.
  2. Alguém que entenda bem todas as outras partes diretamente relacionadas da infraestrutura.
  3. Alguém que entende comoReplicação OpenLDAPfunciona.
  4. Uma compreensão razoável doOpções de BerkeleyDB(ou qualquer back-end que você esteja usando), já que os padrões não estão corretos.
  5. Escravos altamente disponíveis. Mais de 1. Melhor: realmente com balanceamento de carga.
  6. **Mestres ativos-passivos (a replicação de mestres ativos-ativos é inerentemente complicada)
  7. Fazemos backup de dados LDAP paraLDIF a cada horae mantenha alguns dias deles em disco. (todo o servidor faz backup todas as noites)
  8. Nós temosroteirospara rapidamentetraga um escravo quebrado de voltapara uma réplica de dados atual limpa
  9. Nós temosroteirospara rapidamenterestaurar um mestre quebradodos backups LDIF (via slapadd)
  10. Podemos mudar rapidamente para omestre em espera. (roteiros)
  11. Monitoramos se as conexões de replicação estão ativas
  12. Monitoramos se os IDs de replicação estão atualizados em todos os escravos
  13. Monitoramos (com menos frequência) se todo o conteúdo dos escravos corresponde ao mestre.

Basicamente, porém, se for uma parte fundamental da sua infraestrutura, alguém da sua equipe deve realmente entendê-la bem.

Termo aditivo: A pedido, o DB_CONFIGarquivo do meu diretório DB openldap. Olhe parahttp://docs.oracle.com/cd/E17076_02/html/api_reference/C/configuration_reference.htmlpara 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

informação relacionada