segunda-feira, 1 de fevereiro de 2016

Conhecendo a estrutura de logs do ZTOOL - Parte 1

Uma das grandes preocupações da equipe de desenvolvimento do ZTOOL é disponibilizá-lo de uma forma que seja possível atender da menor e mais simples, a mais complexa estrutura Zimbra, e isso não é uma tarefa trivial. Manter um serviço de correio com poucos domínios, contas e um pequeno fluxo de e-mails é algo simples. As preocupações basicamente resumem-se a hardware confiável e uma correta configuração do ambiente. Dificilmente em uma estrutura desse porte (até 100 contas por exemplo) serão vistos problemas onde o hardware não será suficiente para o processamento necessário. Por outro lado, existem os ambientes complexos, com volumes e fluxos de dados gigantescos, desafiando os administradores a identificar causas de eventuais gargalos e executarem os ajustes para saná-los, estes ajustes são comumente referenciados como "tunning". O ZTOOL possui diversos parâmetros de tunning que podem ser modificados de uma forma a alterar o seu comportamente de acordo com o ambiente existente. Parâmetros como quantidade de threads, intervalos entre ações e áreas de cache são exemplos de ajustes que influenciarão na performance e carga da estrutura. Para poder fazer uma análise do ambiente de forma a poder tomar as decisões corretas, o administrador precisa ter acesso aos dados de funcionamento do ambiente, nesse artigo mostraremos o esquema de logs providos pelo ZTOOL, logs estes que além de fornecer dados para ajustes de tunning, são uma rica fonte de informação utilizada para resolução de eventuais problemas.

Os logs do ZTOOL são gerados no diretório /var/log/ztool tanto no console ZTOOL quanto nos agentes instalados junto ao ambiente Zimbra. Esta primeira parte do artigo é voltada para o detalhamento dos logs do servidor ZTOOL:

Console ZTOOL

Através da figura 1 podemos ilustrar de uma maneira geral a forma como o daemon manager gerencia os demais e quem é responsável pela geração de cada log.

Figura 1 - Daemon manager com seus sub-daemons e logs gerados
  • archiver_webservice.log - Gerado pelo archiver, daemon responsável pela coleta dos e-mails para a auditoria. É possível ver por exemplo o arquivamento de um e-mail (Figura 2).

Figura 2 - Log do daemon archiver mostrando o processo de coleta de uma mensagem.
  • certifier_webservice.log - Log do daemon certifier, todas as ações referentes a backup e restore são relatados neste arquivo. Na figura 3 podemos ver um exemplo de procedimento de restore em execução.

Figura 3 - Log do daemon certifier mostrando o processo de restore do diretório de uma conta.

  • syncer_webservice.log - Eventos de sincronização entre o ZTOOL e o Zimbra, podemos ver nesse log ações como a criação de um usuário no zimbra após o mesmo ter sido criado na base de dados do ZTOOL (Figura 4). 

Figura 4 - Log do daemon syncer mostrando a atualização de uma conta que foi modificada a partir do console web ZTOOL.

  • tracker_webservice.log - Neste log é possível acompanhar todos os eventos internos do Zimbra que são monitorados através do daemon tracker. Através destas informações coletadas o ZTOOL faz a relação entre os dados e seus cabeçalhos, desta forma o ZTOOL consegue por exemplo monitorar ações que são tomadas nos e-mails via Imap por exemplo (figura 5).
Figura 5 - Log do daemon tracker mostrando um e-mail enviado a partir do webmail nativo do Zimbra.
  • info_webservice.log - Parâmetros de configuração e classes são disponibilizadas a partir do server para os agentes. Todos os daemons inserem informações neste log a medida que precisam desse tipo de informação. A entrega de uma classe para um agente é apenas uma das várias ações que são registrados neste log (figura 6).
Figura 6 - Log info_webservice.log mostrando o envio de uma classe para um agente
  • ztmanager.log - O daemon manager é responsável pela gerência dos demais daemons, determina diversas ações a serem executadas por estes, todo agendamento existente no ZTOOL (expurgo de dados fora da retenção por exemplo) é feito por ele. Na figura 7 podemos verificar o processo de expurgo de mensagens do backup que sairam do período de retenção.
Figura 7 - Daemon manager expurgando dados do backup que sairam do período de retenção.
  • manager.out - Não podemos considerar este arquivo como um log no sentido convencional. De fato, este arquivo não cresce de forma incremental, ele é constantemente sobrescrito pelo daemon manager que dá informações em "tempo real" sobre a execução dos demais daemons em execução. A melhor maneira de visualizar seu conteúdo é através do comando  watch -n1 'cat /var/log/ztool/manager.out'   (figura 8).
Figura 8 - Visualiação do arquivo /var/log/ztool/manager.out
As informações estão distribuídas em 3 blocos divididos que são descritos abaixo: 

1 - Informações sobre o manager (figura 9).

Figura 9 - Primeiro bloco da saída do arquivo manager.out
Este bloco refere-se as informações acerca do daemon manager, composto pelas seguintes informações:
  1. PID do daemon manager;
  2. Versão do PHP em uso;
  3. S.O. base para a instância ZTOOL;
  4. Data e hora em que o daemon foi carregado;
  5. Memória atualmente utilizada pelo daemon;
  6. Pico de memória desde a carga;
  7. Data e hora do último evento processado.

2 - Informações sobre o processo de comunicação (figura 10). 
Figura 10 - Segundo bloco da saída do arquivo manager.out
Este bloco refere-se as informações acerca do processo responsável pela comunicação (coleta das informações a partir do web-service ou banco de dados). Os dados apresentados são respectivamente:
  1. Memória em uso atualmente pelo processo responsável pela comunicação;
  2. Data e hora do último evento processado;
  3. Descrição do último evento processado.

3 - Informações sobre os demais daemons (figura 11).

Figura 11 - Terceiro bloco da saída do arquivo manager.out
O terceiro e último bloco é composto pelas informações de suas sub-threads organizadas da seguinte forma:
  1. Informações do worker conf e do último evento processado por ele;
  2. Informações do worker sync e do último evento processado por ele;
  3. Informações do worker arch e do último evento processado por ele;
  4. Data e hora do último evento processado;
  5. Memória em uso por cada worker.

  • php-fpm.log e php_errors.log - Arquivo de log do servidor PHP e arquivo com eventuais erros do PHP-FPM;  

Existem ainda, 2 sub-diretórios onde foram alocados os logs específicos da comunicação com dispositivos mobile e com o servidor nginx (responsável por prover a comunicação com os daemons via webservice). A descrição de cada log segue abaixo:

  • /var/log/ztool/zmobile - Diretório com os logs de comunicação com dispositivos mobile
    • zmobile-error.log - Log dos erros do webservice de sincronização de smartphones;
    • zmobile.log - Log do webservice de sincronização de smartphones 
  • /var/log/ztool/nginx - Diretório com os logs de comunicação com os demais daemons via web-service
    • archiver.access.log  - Histórico de acessos do daemon archiver;
    • archiver.error.log - Erros em eonexões do daemon archiver;
    • certifier.access.log  - Histórico de acessos do daemon certifier;
    • certifier.error.log - Erros em eonexões do daemon certifier;
    • syncer.access.log - Histórico de acessos do daemon syncer;
    • syncer.error.logErros em eonexões do daemon syncer;
    • tracker.access.log - Histórico de acessos do daemon tracker;
    • tracker.error.log -  Erros em eonexões do daemon tracker;
    • zweb.access.log - Histórico de acessos no frontend web; 
    • zweb.error.logErros em eonexões no frontend web;
    • info.access.log - Histórico de acessos de conexões para trocar de informações;
    • info.error.log - Erros em eonexões de conexões para trocar de informações; 
    • error.log -
Com isso finalizamos a primeira parte deste artigo, na segunda parte iremos detalhar os logs do agente ZTOOL.

quarta-feira, 22 de julho de 2015

Gaps em backups. A abordagem do ZTOOL para o tratamento deste problema.

    Dados que não são copiados por terem transitado durante o intervalo entre 2 janelas de backup. Uma questão bem conhecida por administradores de ambientes Zimbra que utilizam meios convencionais para o seu processo de backup. Para entender melhor o problema, usemos como exemplo um ambiente onde o backup é feito por meio de um job agendado para a execução diária às 02:00 da manhã. Imagine então um usuário que recebe um e-mail externo às 15:00. Ele então visualiza o e-mail e logo após o apaga (ação ocorrida às 17:00). Nete momento o e-mail estará na lixeira do usuário, mas logo então ele limpa sua lixeira (20:00) apagando quaisquer resquícios deste e-mail em específico. Pois bem, quando a próxima ocorrência do job de backup iniciar, ela irá copiar os dados de forma incremental ou até mesmo full para o repositório de backups (variando de acordo com a configuração da ferramenta de backup utilizada), porém o e-mail que chegou às 15:00 e que foi excluído às 17:00 não será incluído nesta ou em qualquer outra coleta de dados para o backup que ocorrerá a partir daí. Simplesmente pelo fato do e-mail não mais existir no mailbox Zimbra. Isso é bem comum e um problema bastante incômodo na vida de um administrador Zimbra. De fato, é possível concluir que todo e qualquer e-mail que trafegue pelo servidor Zimba e seja apagado sem que haja um job de backup entre estas ações não será incluído na cópia de segurança (figura 1). 

Figura 1 - Linha temporal demonstrando um gap no backup.
    Buscando sanar esta deficiência, o ZTOOL implementa uma abordagem diferente na forma de executar o backup, ele basicamente elimina a necessidade de agendamento de jobs para a sua execução, eliminando assim, a existência de "janelas" onde estas comumente representam o aumento de carga no ambiente (que é normalmente ocultado nas madrugadas). Para isso, o ZTOOL executa o backup dos dados durante o fluxo de circulação dos e-mails. Cada e-mail que é processado pelo Zimbra, é coletado para o backup antes mesmo de ser entrgue ao destinatário (figura 2). Esta coleta é feita pelo agent ZTOOL instalado junto a(s) instância(s) Zimbra a serem gerenciadas.

Figura 2 - Detalhamento do momento da coleta do e-mail para o arquivamento no backup e auditoria.
    Um ponto que sempre é questionado por administradores que observam esta abordagem pela primeira vez, refere-se ao peso que este processo agrega ao ambiente, afinal de contas, o peso que antes era jogado nas madrugadas para diminuir o impacto junto ao usuário final, foi distribuido durante todo o período de funcionamento do ambiente. O algoritmo de coleta dos e-mails foi totalmente reescrito, buscando assim uma otimização nas ações que resultavam operações de I/O. Isso significa que a partir da versão 6.0, o ZTOOL praticamente não agrega peso extra ao ambiente. Podemos fazer uma comparação de um ambiente exemplo, com métricas expostas abaixo. Este ambiente possui 30 domínios totalizando 1200 contas e um fluxo diário de algo em torno de 100000 e-mails. 

Figura 3 - Carga do processador durante o período de 24 horas sem o ZTOOL agent em funcionamento.
Com uma amostragem de 24 horas podemos verificar na figura 3 o load do ambiente sem o processo de backup em execução e na figura 4 o mesmo ambiente com o mesmo período, já com o processo de backup em pleno funcionamento. A diferença é praticamente imperceptível. 
Figura 4 - Carga do processador durante o período de 24 horas COM o ZTOOL agent em funcionamento.
    Temos ainda a figura 5 e 6 que mostram respectivamente as métricas de I/O deste ambiente sem e com o processo de backup em execução. 

Figura 5 - Percentual de processamento destinado a operações de I/O sem o ZTOOL agent em funcionamento
Figura 6 - Percentual de processamento destinado a operações de I/O COM o ZTOOL agent em funcionamento
    Uma outra característica importante neste modelo é a independência do backup em relação a disponibilidade do ZTOOL. Isso significa que mesmo que o console ZTOOL ou até mesmo o daemon ZTOOL esteja(m) indisponivel(is), os dados continuam sendo armazenados (de forma local) até o retorno deste(s). O que vai ocorrer quando o ZTOOL estiver funcional novamente, é a sincronização dos dados. Ao final deste processo o backup estará em estado "on-line" novamente. É praticamente impossível um e-mail não ser coletado para o armazenamento no backup. 


    O modelo implementado pelo ZTOOL traduz-se em eficácia e integridade no processo de backup, onde todos os dados são de fato armazenados, sem que para isto, o ambiente em questão seja penalizado a nível de recursos.

sexta-feira, 10 de julho de 2015

Uma visão sobre a taxonomia de um ambiente ZTOOL.

     Uma dúvida muito comum de usuários que tem um primeiro contato com o ZTOOL, refere-se ao desenho de um ambiente zimbra gerenciado por esta ferramenta. Uma visão equivocada é a de que o ZTOOL é um aplicativo que gerencia o backup de apenas um servidor zimbra. 

Figura 1 - Visão de um ambiente convencional com scripts.
Talvez este mal entendido se dê pela existência de modelos já conhecidos de outras soluções que funcionam desta forma (figura 1). O ZTOOL é de fato uma solução complementar ao zimbra, que gerencia não só uma, mas várias instâncias zimbra, sejam estas baseadas em apenas 1 servidor (Mailbox, Proxy, MTA e LDAP centralizados em apenas uma maquina - figura 2) ou um cluster onde podemos ter os vários elementos integrantes de uma estrutura zimbra divididos entre 2 ou mais servidores, sejam estes físicos ou virtuais (Figura 3). Este modelo permite que o ZTOOL gerencie desde um único servidor zimbra até ambientes mistos compostos por centenas de servidores e/ou clusters zimbra. Para compreender melhor esta organização, precisamos entender como o ZTOOL está organizado (figura 4).




Figura 2 - ZTOOL gerenciando uma instância Zimbra (monolítica)
O personagem principal aqui é o Console ZTOOL, este componente é instalado em uma maquina dedicada, que será responsável pelo gerenciamento de todos os objetos do sistema. Este console é composto pelo frontend web (zweb), pelo banco de dados (zdb) e pelo daemon de comunicação (manager). Requisitos de hardware para o console ZTOOL podem ser vistos na tabela 1. O zweb é o elemento que provê ao(s) administrador(es) do ambiente a interface de administração (figura 5), onde é possível efetuar a configuração e execução das tarefas disponíveis na ferramenta.


Figura 3 - ZTOOL gerenciando um ambiente misto com múltiplas instâncias
monolíticas e distribuídas.
O zdb por sua vez é uma instância do postgreSQL que manterá os dados de configuração (contas, listas de distribuição, aliases, administradores, etc) assim como os dados de backup e archiving (auditoria). Este componente quando necessário (em ambientes de grande porte por exemplo) pode ser alocado em um outro servidor de forma a se conseguir uma melhor distribuição de carga. Por último, temos o manager, o daemon responsável pelas ações administrativas tais como o expurgo de dados, manutenção do backup e sincronização de dados. Toda a informação coletada pelos agentes nos servidores zimbra é repassada ao console ZTOOL via webservice, onde este daemon toma as ações necessárias e faz o correto armazenamento no zdb. 


Figura 4 - Visão sobre os processos e daemons do ZTOOL
Além disso, todas as ações tomadas pelos administradores (solicitação de restore, criação de conta, lista, alias, etc) são enviadas por este daemon aos agentes existentes no(s) servidor(es) que são os responsáveis pela executarão de tais ações. Importante frisar que toda esta comunicação é feita de forma segura utilizando para isto criptografia SSL/TLS. 

O outro elemento necessário para o funcionamento do ZTOOL é o zagent. Este módulo deve ser instalado em cada servidor zimbra existente no ambiente (sejam instâncias zimbra monolíticas ou distribuídas). O zagent é composto por 4 daemons, O archiver que é responsável pela importação dos dados para a auditoria de emails. Ele detecta os emails que chegam e os envia para o console ZTOOL. O certifier que executa o processo de certificação do backup e restauração de caixas postais. O tracker que trata os eventos gerados pelo zimbra como criação de pastas, movimentação de emails, ações IMAP, dentre outras atividades e finalmente o  syncer que tem como função básica a sincronização de usuários entre o ZTOOL e o Zimbra, na prática ele mantém a integridade entre as informações de usuários


Figura 5 - Ambiente Web (zweb) de gestão do ZTOOL
Esta divisão de responsabilidades foi projetada para que um tipo de ação não interfira nas outras, por exemplo, a criação de uma conta não deve interferir no restore de um backup que esteja em execução. Além disso, cada daemon tem um controle exclusivo da quantidade de suas threads, possibilitando ao administrador um ajuste fino das ações de forma a não impactar a performance do ambiente. Um exemplo disso é o restore de um domínio com grande volume de e-mails. Pode-se aumentar a quantidade de threads para agilizar o processo, mas de uma forma que não impacte o desempenho do ambiente em produção. 

O principal ganho neste modelo é a flexibilidade e transparência na gestão dos objetos. Um administrador que gerencia diversos domínios em um ambiente composto por várias instancias (não integradas), não precisa saber onde está localizado fisicamente um domínio para poder criar nele uma conta por exemplo. Ele apenas a criará no zweb e o ZTOOL saberá em que servidor ele precisa tomar a ação para a criação da conta. Um outro exemplo da flexibilidade obtida, pode ser citado no restore de um backup entre servidores distintos. Possuímos uma conta fulano@dominioA.com.br localizada em um servidor X e um backup desta conta pode ser restaurado em uma conta sicrano@dominioB.com.br localizada fisicamente em um servidor Y (figura 6). O ZTOOL trata e apresenta para o admininstrador tudo como se fosse uma coisa só, transformando a administração de ambientes desde os mais simples aos mais complexos em algo trivial. 


Figura 6 - Restauração de um backup em uma conta/servidor diferente do original



Tabela 1 - Requisitos mínimos de Hardware para o console ZTOOL:

Processador - 2 Processadores
Memória - 4 Gb de memória RAM
Sistema Operacional - 
           Para o console ZTOOL: Red Hat 7  / Ubuntu 14.04 LTS
           Para o agent ZTOOL: Red Hat 5, 6 e 7 / Ubuntu 10.4, 12.4 e 14.4.
Espaço em disco - Dimensionado de acordo com o volume de dados a ser gerenciado e período de retenção.