4463

Zimbra Collaboration Suite

Administração Total

www.4linux.com.br
4Linux – www.4linux.com.br 3.2 Discos e Particionamento

montada da forma usual. Estes volumes são agrupados em um grupo de volumes

lógicos (logical volume group) que se comporta de forma similar a um HD.

O pulo do gato é que o grupo de volumes lógicos pode combinar o espaço de vários
HDs e ser modificado conforme necessário, incorporando mais HDs. Os volumes
lógicos dentro dele também podem ser redimensionados livremente conforme for
necessário.

Se você precisa de mais espaço dentro do volume referente à pasta /home, por
exemplo, você poderia reduzir o tamanho de um dos outros volumes do sistema (que
estivesse com espaço vago) e aumentar o tamanho do volume referente ao /home,
tudo isso com o servidor operante.

Outra possibilidade é ir adicionando novos HDs ao servidor conforme precisar de

mais espaço. Ao instalar um novo HD, você começaria criando um volume físico,
englobando todo o espaço do HD. Uma vez que o volume físico é criado, você pode
expandir o grupo de volumes lógicos, de forma que ele incorpore o espaço referente
ao novo HD. A partir daí, você pode expandir os volumes lógicos, usando o espaço
livre.

Caso seja utilizada uma controladora SCSI ou SAS com suporte a hot-swaping, é
possível até mesmo adicionar, remover ou substituir HDs, fazendo as alterações
necessárias nos volumes lógicos, com o servidor ligado!

É importante enfatizar que o LVM é apenas uma mudança na forma como o sistema
acessa os discos, ele não é um substituto para o RAID. No LVM você pode agrupar
vários HDs em um único grupo de volumes lógicos, mas se um dos HDs apresentar
defeito, o servidor ficará inoperante e você perderá os dados armazenados no disco
afetado, diferente do RAID, onde você pode sacrificar parte do espaço para ter uma
camada de redundância.

Zimbra Collaboration Suite Administração Total Página 13

3.2 Discos e Particionamento 4Linux – www.4linux.com.br

O grupo de volumes lógicos criado pelo instalador é visto pelo sistema como "/de-
v/vg01"e os volumes lógicos dentro dele são vistos como "/dev/vg01/lv01", "/de-
v/vg01/lv02", etc. Os nomes podem ser alterados da maneira que quiser. Natu-
ralmente, é possível também deixar de usar o LVM, voltando ao sistema normal de
particionamento. Nesse caso, você só precisa deletar os volumes e o grupo de vol-
umes lógicos e criar a partições desejadas usando o espaço disponível.

http://www.hardware.com.br/dicas/entendendo-lvm.html

Uma implementação melhor do LVM é em conjunto com volumes RAID, pois no caso
de falhar um dos discos, continuamos com a leitura/gravação nos demais. Em re-
lação ao usuário, o mesmo nem saberá que tem toda esta estrutura por trás da
manipulação dos dados!

3.2.4 Considerações finais de disco

Dois critérios precisam ser considerados para escolha dos discos: vazão (through-
put) e volume de armazenamento.

Página 14 Zimbra Collaboration Suite Administração Total

4Linux – www.4linux.com.br 3.2 Discos e Particionamento

O recurso computacional mais importante em um servidor Zimbra é o I/O. Pois o

tempo inteiro há operações de leitura e gravação sendo executadas concorrente-
mente, como filas de e-mail, buscas nos índices e leitura de mensagens.

Parte dessa operações tem perfil sequencial, enquanto as outras, perfil aleatório.

Por isso, as dicas para evitar gargalos de leitura e gravação são:

Distribua. Dois discos de 75 GB são melhores que um disco de 150 GB;

Evite RAID 5. O mecanismo de paridade afeta negativamente o desempenho do

Zimbra.

Se possível, utilize RAID 10. É o mais caro, mas garantidamente, o mais rápido e
seguro.

Utilize o sistema de arquivos ext4. É comprovado pela Zimbra como o de melhor

desempenho.

Finalmente, para calcular o volume necessário para o armazenamento de todos os

dados do usuário, utilize a seguinte métrica:

(Usuários x Cota) + 25% índice + 5% banco.

Exemplo: 200 usuários com 500 MB de cota;
100 GB + 25 GB + 5 GB = 130 GB.

Foi explicado que a distribuição da instalação por vários discos traz benefícios ao
desempenho de leitura e gravação.

Porém, se há um único volume de dados, particioná-lo pode trazer benefícios quando

dedicamos partições diferentes para os bancos de dados e para os arquivos sequen-
ciais.

Zimbra Collaboration Suite Administração Total Página 15

 3.3 Hostname e considerações sobre DNS 4Linux – www.4linux.com.br

Este critério de particionamento vai servir para diminuir o tempo de “seek”, que é
o movimento dos cabeçotes na mídia física para ir de um segmento de dados até
outro segmento. Em outras palavras, este particionamento diminui a fragmentação
dos dados.

Mais adiante conheceremos em detalhes a estrutura de diretórios do Zimbra. Mas

para efeitos práticos, basta separar uma partição para o diretório /opt/zimbra/db,
deixando outra partição dedicada para o armazenamento das mensagens em /opt/z-
imbra/store e uma outra para o restante da instalação no /opt/zimbra.

Verifique o LVM presente na máquina Mail Server através dos comandos:

1 root@mail :~ # pvs
2 root@mail :~ # vgs
3 root@mail :~ # lvs

Acompanhe no Anexo da aula a implementação do LVM na máquina Mail

Server.

3.3 Hostname e considerações sobre DNS

3.3.1 Pré-requisitos

Das configurações obrigatórias antes de iniciar a instalação de um servidor Zimbra,

as mais importantes são as que envolvem o hostname e o DNS.

Todos os serviços do Zimbra são configurados para se identificarem por nome, nunca
por um IP diretamente.

Página 16 Zimbra Collaboration Suite Administração Total

 4Linux – www.4linux.com.br 3.3 Hostname e considerações sobre DNS

Além, disso, o MTA em particular é totalmente dependente das respostas de um

servidor DNS bem configurado. Serão feitas consultas DNS até mesmo para entregar
as mensagens enviadas de um usuário para si mesmo.

O utilitário de instalação do Zimbra foi programado para utilizar o hostname do servi-

dor em todas as configurações de nome. Portanto, o nome que o Zimbra irá adotar é
o mesmo que resulta do comando:

Executar na máquina Mail Server

1 root@mail :~ # hostname -f

Observação: O parâmetro -f indica que a resposta deve ser o nome totalmente qual-
ificado do servidor (FQDN), ou seja, o hostname seguido pelo nome de domínio.

Antes de iniciar a instalação, certifique-se de que a resposta do comando acima

é coerente, e que os servidores DNS consultados conheçam a zona do domínio e
contenha um registro do tipo address(A) apontando para o servidor Zimbra.

Uma dica importante é: utilize um FQDN público, pois será preciso configurá-lo no
registro reverso do IP de conexão com a Internet.

Em servidores Ubuntu, para modificar o FQDN, é preciso alterar o arquivo /etc/host-

name. Também é necessário existir uma entrada correspondente no arquivo /etc/hosts.

Funcionamento da resolução de nomes por DNS:

Solução DNS é o processo pelo qual um programa consulta dados a respeito de

um hostname. Na grande maioria das vezes, consulta-se o endereço IP deste host,
para então efetuar algum tipo de conexão à algum serviço, como HTTP, SMTP. POP,
dentre inúmeros outros.

Zimbra Collaboration Suite Administração Total Página 17

 3.3 Hostname e considerações sobre DNS 4Linux – www.4linux.com.br

O processo de resolução, a partir do primeiro nameserver consultado, pode ser:

• recursiva

• iterativa

3.3.2 Arquivo /etc/hosts

Derivado do arquivo HOSTS.TXT original, aquele que era atualizado e distribuído

antes do surgimento do Domain Name System, o arquivo /etc/hosts continua tendo
um papel muito importante no processo de resolução. Ele é a primeira fonte de
consulta do resolver.

Este comportamento pode ser modificado através do arquivo /etc/nsswitch, porém,

isso só seria feito em um cenário muito particular. Podemos considerar que quase a
totalidade dos sistemas *nix vão seguir a ordem de resolução padrão.

Sendo assim, é bom conhecer a sintaxe desse arquivo:

1 Endereco_IP FQDN HOSTNAME [ aliases ...]

2 192.168.200.5 mail . dexter . com . br mail

São possíveis um endereço IP por linha, seguido de um endereço canônico e op-

cionalmente aliases. O nome de host canônico pode ser qualquer nome no formato
DNS, porém, em alguns casos, como o de servidores de e-mails, é adequado que
os IPs presentes nesta máquina tenham um FQDN pertinente. Full-Qualified Domain
Name é um hostname que identifica sem ambiguidade a posição daquele nó dentro
da árvore DNS.

Por essa razão, um FQDN deve terminar com um ".", que representa a raiz da ár-
vore. O aliases podem ser outros hostnames canônicos, ou simples sufixos, para
simplificar a escrita de determinados endereços. Após a instalação do sistema, o

Página 18 Zimbra Collaboration Suite Administração Total

4Linux – www.4linux.com.br 3.3 Hostname e considerações sobre DNS

arquivo hosts costuma conter uma entrada referente ao IP da interface loopback, e

uma entrada para cada outra interface presente na máquina para qual um endereço
foi atribuído.

Pode ser acrescentadas quantas entradas forem necessárias, inclusive para IPs ex-
ternos. Atualmente, os sistemas baseados em Ubuntu já contém entradas para en-
dereçamento IPv6, que seguem a mesma lógica.

3.3.3 BIND9

O BIND (Berkeley Internet Name Domain) é o servidor de nomes utilizado na grande

maioria dos servidores da Internet, provendo uma estável e robusta arquitetura sobre
a qual as organizações podem construir sua estrutura de nomes.

O BIND vai utilizar a porta 53/UDP para receber consultas, a porta 53/TCP
para transferir zonas para servidores escravos, a porta 953/TCP para receber co-
mandos via rndc (que dependem de chaves criptografadas), e portas udp altas po-
dem ser dinamicamente atribuídas para efetuar consultas em outros servidores.

3.3.4 Servidor cache

As bibliotecas do resolvedor da maioria dos sistemas operacionais não são capazes

de executar o processo de resolução completo, chamado recursivo, como vimos
acima.

Ao invés disso elas dependem de um servidor intermediário com essa capacidade.

Quando nos conectamos de casa diretamente à Internet, o serviço DHCP do prove-

dor se encarrega de nos atribuir o endereço de seus servidores cache. Caso con-
trário, nosso resolver não teria a quem consultar e não conseguiríamos navegar.

Zimbra Collaboration Suite Administração Total Página 19

 3.3 Hostname e considerações sobre DNS 4Linux – www.4linux.com.br

No entanto, muitos administradores de rede utilizam os IPs desses provedores para

configurar várias estações de trabalho de uma rede. O efeito disto é que cada es-
tação vai fazer suas próprias consultas individuais, multiplicando o volume de dados
trafegados através do link de Internet, desperdiçando tempo e ocupando largura de
banda.

Quanto maior a rede, pior o impacto. A alternativa para evitar estes problemas é man-
ter um servidor DNS caching only. Servidores cache reservam o resultado de suas
buscas na memória pelo tempo limite estabelecido pela autoridade sobre o domínio
consultado. Dessa forma, independente da quantidade de máquinas da rede, as
consultas serão feitas na Internet apenas uma vez a cada intervalo de atualização.

A empresa Dexter possui um servidor BIND que já está operando como servidor
cache na máquina DMZ e Mail. Para testar:

Executar na máquina Mail Server

1 root@mail :~ # dig @192 .168.200.5 4 linux . com . br

Observe os dados no rodapé da consulta e repita o comando:

1 root@mail :~ # dig @192 .168.200.5 4 linux . com . br

Observe o query time no rodapé da saída do dig.

Para que a partir de agora todas nossas aplicações utilizem o potencial de nosso
servidor cache, edite o arquivo /etc/resolv.conf e mantenha apenas as linhas a seguir:

1 root@mail :~ # vim / etc / resolv . conf

2 nameserver 192.168.200.5

Página 20 Zimbra Collaboration Suite Administração Total

4Linux – www.4linux.com.br 3.4 Remoção de serviços desnecessários

Para registrarmos um domínio público, precisamos de pelo menos dois servidores

DNS respondendo pelo nosso domínio. Isso significa um servidor mestre e pelo
menos um servidor escravo. A exigência é uma forma de garantir que seu domínio
estará sempre disponível. Se um servidor parar, o outro continua respondendo.

Se os servidores estiverem geograficamente separados, isso garante ainda mais

disponibilidade, pois mesmo que um link caia, o outro certamente ainda estará disponível.
Na verdade, um mesmo servidor rodando BIND pode ser simultaneamente mestre
para alguns domínios, escravo para outros, e cache para todo o resto.

Neste curso usaremos um servidor DNS pronto para todas as máquinas trocarem
e-mails.

Para conhecer mais detalhes e boas práticas sobre configurações DNS para servi-
dores de e-mail, consulte na Internet:

http://antispam.br/admin/conf-servicos/dns/

3.4 Remoção de serviços desnecessários

Sugere-se que o Zimbra seja instalado em um servidor totalmente dedicado (mesmo

que seja uma VM).

O único serviço de rede que deve ser pré-instalado é o SSH, pois o Zimbra vai utilizá-
lo para o gerenciamento de filas de e-mail e também para todo tipo de comunicação
entre os serviços de uma instalação distribuída.

Remova qualquer outro serviço de rede pré-existente.

Zimbra Collaboration Suite Administração Total Página 21

 3.5 NTP – Network Time Protocol 4Linux – www.4linux.com.br

3.5 NTP – Network Time Protocol

Os e-mails que trafegam para fora do Zimbra tem seu horário de envio baseado no
horário do servidor. Por isso, evite confusões mantendo este relógio sincronizado
com o Network Time Protocol (NTP).

No Ubuntu, basta instalar o pacote ntpdate e configurar o agendador de tarefas para

fazer ajustes periódicos:

1 root@mail :~ # apt - get install ntpdate -y

Acrescente a seguinte linha, para executar dois ajustes por dia, 12:00 e 00:00:

1 root@mail :~ # crontab -e
2 0 12 ,00 * * * / usr / sbin / ntpdate 200.160.0.8

3.6 Roteamento e Firewall

Reforçando que estamos planejando a instalação de um único servidor com todos os

pacotes (LDAP, MTA e STORE), este servidor precisa conhecer uma rota para Inter-
net e ter acesso ao serviço HTTP universal (porta 80 TCP). Este privilégio vai garantir
que o ClamAV faça atualizações, e que todos os Zimlets que utilizem webservices
públicos funcionem.

Por outro lado, o universo vai precisar acessar pelo menos a porta 25/TCP de seu
servidor, pois é nela que são entregues os e-mails.

Evidentemente, se pretendemos oferecer perfil móvel de acesso aos usuários, as

outras portas candidatas a estarem publicadas na Internet são:

Página 22 Zimbra Collaboration Suite Administração Total

4Linux – www.4linux.com.br 3.7 Obtenção dos pacotes de instalação

80 , 443 e 7071 TCP: Webmail e Webservices;

110, 143, 995 e 993 TCP: Respectivamente POP, IMAP, POPS e IMAPS;

Nenhuma das outras portas presentes no servidor precisam ser publicadas,

sob o risco de exploração.

3.7 Obtenção dos pacotes de instalação

As versões mais recentes do pacote de instalação do Zimbra Collaboration Suite

podem ser encontradas diretamente no site oficial da Zimbra, no endereço:

http://www.zimbra.com/downloads/os-downloads.html

Figura 3: Tabela de Download.

Utilize sempre a assinatura MD5 publicada juntamente com o arquivo para

garantir que sua cópia não sofreu nenhuma adulteração durante o download.

Zimbra Collaboration Suite Administração Total Página 23