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.