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.