Papel Clepôncio

Há bastante tempo tenho trabalhado com serviço de diretório, especificamente com o OpenLDAP. Quando criando um novo ambiente, no geral minhas preocupações são: redundância e performance das aplicações. Pensando nisso, sempre procurei manter meu backup em dia e diversos slaves como forma de redundância e para permitir que as aplicações não sofram com problemas de performance for falta de ajustes finos, latência de rede, inacessibilidade ou por questões relacionadas à escalabilidade.

De fato, essa fórmula sempre funcionou como esperado, mas o excesso de réplicas torna o ambiente praticamente inadministrável conforme o número de Slaves aumenta, e é óbvio que queremos que nossa aplicação seja escalável. Em um modelo deste tipo, escalar a aplicação também significa precisar de mais slaves.

A boa notícia é que o OpenLDAP possui um módulo chamado “pcache” que elimina esta necessidade absurda de milhões de réplicas dentro da sua estrutura.

O conceito é simples. Ao invés de replicar todo o diretório, o pcache armazena somente os resultados das pesquisas efetuadas e pelo tempo necessário. Uma consulta que não está em cache é respondida pelo Master (ou Slave, preferívelmente) e a que está em cache é respondida localmente.

Arquitetura com OpenLDAP Proxy Cache

A partir deste ponto, vou mostrar um exemplo de arquitetura física ignorando qualquer melhoria relacionada ao modelo utilizado dentro do diretório. Meu intuito é somente mostrar o funcionamento do “slapo-pcache”.

Exemplo simples de arquitetura :

Como é possível ver, existe a possibilidade de que a própria máquina de aplicação seja o cache. Desta forma a latência de rede já é eliminada pois a consulta é local. Digamos que é possível economizar alguns bons milisegundos (ou até segundos) para cada consulta efetuada. Obviamente, quando iniciar o serviço pela primeira vez, o seu diretório Slave vai receber uma carga maior, mas a curto prazo, essa carga deve diminuir. O Master por sua vez, será somente utilizado para gravações e algumas leituras.

A configuração do “slapo-pcache” é bastante simples, mas é necessário que você saiba exatamente todas os tipo de consultas que serão efetuadas no seu diretório. No geral, sempre sabemos quais queries serão efetuadas, salvo se seu diretório for aberto.

Instalação

A instalação é bem simples. Pode ser instalado através do gerenciador da sua distro, ou pelo conhecido trio “./configure”, “make”, “make install”.

Para o Red Hat, é necessário instalar o pacote openldap-servers-overlays e no caso de haver necessidade do compilação, são necessários os seguintes parâmetros “–backend-ldap” e “–overlay-pcache”.

Configuração

A configuração de um LDAP Cache é muito simples. A cada sessão, irei explicar qual é a função do ítem de configuração

slapd.conf

Primeiramente incluímos todos os “schemas” requeridos pelo diretório, pois caso não existirem, o OpenLDAP não consegue persistir o resultado das consultas, fazendo o cache ser ineficaz.

# Schema files
include      /etc/openldap/schema/core.schema
include      /etc/openldap/schema/corba.schema
include      /etc/openldap/schema/cosine.schema
include      /etc/openldap/schema/inetorgperson.schema
include      /etc/openldap/schema/misc.schema
include      /etc/openldap/schema/mail.schema
include      /etc/openldap/schema/nis.schema
include      /etc/openldap/schema/openldap.schema

É necessário carregar o módulo explicitamente. Em algumas distribuições é desnecessário fazer isso. Mas na dúvida, faça.

# modules
moduleload      pcache

Estes níveis de log, mostram sobre as consultas efetuadas no diretório. Para saber os outros níveis, verifique a documentação do OpenLDAP.

# log information
loglevel        stats stats2

Esta é a sessão relacionada aos backends necessários para efetuar o cache. Observe que o Backend primário utilizado aqui é o “ldap”, ou seja, a consulta feita no cache é repassada para as “uri” definidas. O “suffix” precisa ser o mesmo do seu diretório. O “rootdn” pode ser diferente.

database        ldap
suffix          "dc=mydomain,dc=com”
uri             “ldap://200.x.x.x ldap://200.x.x.y”
rootdn          "cn=manager,dc=mydomain,dc=com”

Aqui vemos a configuração do Cache. O Overlay pcache está sendo inicializado. Os valores do parâmetro proxycache são, respectivamente: tipo do backend; número de entradas no cache; número de attribute sets; número máximo de entradas; período de “consistency check”.

# slapo-pcache configuration
overlay         pcache
proxycache      bdb 100000 2 1000 100

Os “proxyAttrset”, são os attribute sets que serão retornados pelas consultas. No exemplo abaixo, minha consulta de número 0 retorna mailHost e rfc822MailAlias, enquanto minha consulta 1 retorna somente a existência de determinado attributo.
Estes “proxyAttrsets” serão utilizados pelas “proxyTemplates” a fim de consolidar o cache. Neles constam as templates das consultas que serão efetuadas, o id do attribute set e o TTL.

proxyAttrset    0 mailHost rfc822MailAlias
proxyAttrset    1 1.1
proxyTemplate   (&(uid=)(associatedDomain=)(mailHost=)) 0 3600
proxyTemplate   (&(uid=)(associatedDomain=)) 1 3600

E enfim, o tamanho total do cache (preferivelmente o mesmo do cache do overlay), o diretório onde será armazenado o cache e por último, os indexes.
Um ponto importante. Não abuse de indexes, eles são necessários, mas o excesso de índices inúteis podem gerar problemas de performance. Sempre olhe seus logs. Se faltar algum índice, constará em seus logs.

cachesize       100000
directory       /var/db/openldap-cache
index           uid,cn pres,eq
index           objectClass,associatedDomain,mailHost eq

A configuração do pcache é realmente simples. Uma vez que você sabe exatamente as queries que são feitas no seu diretório, seu cache será eficaz.
Outros tunings podem ser aplicados, mas não no slapd.conf, mas sim no DB_CONFIG no diretório de seu database.

Normalmente para um cache, costumo criar dois segmentos de memória para cache e um número maior de “lockers”, pois em ambientes de alto volume de consultas, um número baixo de “lockers” pode significar gargalo. Também deixo os transaction logs em auto-remove. Como trata-se de um cache, não existe utilidade nenhuma em preservá-los.

DB_CONFIG

set_flags DB_LOG_AUTOREMOVE
set_cachesize 0 2073741824 2
set_lk_max_locks 3000
set_lk_max_objects 1500
set_lk_max_lockers 1500

Basicamente, esta é uma configuração padrão para um cache. Como já dito, ele pode rodar diretamente e sua máquina de aplicação ou em separado mas fique atento para não confundir problemas de configuração nos “clients” com problemas de performance do cache. Um bom exemplo, é utilizar seu “base dn” diferente do que foi configurado no server. Todos os índices criados, só funcionarão corretamente se as consultas forem feitas na base correta, caso contrário, você terá problemas gigantes com deadlocks.

Espero que este artigo possa ajudar quando for arquitetar sua próxima instalação. Claro que em ambientes maiores será necessário um número maior de caches e slaves, bem como a redundância de seu Master. Em meu próximo POST sobre LDAP, mostrarei como montar um ambiente com Hot Standby. Até!