Trunk de portas ethernet no Linux

Com o bonding é possivel transformar duas portas ethernet 100Mbits em uma porta (bond0) de 200Mbits no Linux. Essa mesma tecnologia é chamada de smarttrunk pela Enterays e Link aggregation pela Cisco. Pode-se utilizar o bonding em várias situações como por exemplo a Alta Disponibilidade (link entre as duas máquinas). As configurações apresentadas abaixo, foram testadas em um RedHat Enterprise 2.1, mas também são passados as linhas de comando para ser configurada em qualquer distribuição.

<update>
Foi publicado um artigo na Howto Forge que ensina a configurar o bonding no Debian.
</update>

<update2>
Esta técnica também é conhecida por Link Aggregation e é definida pela IEEE 802.3ad.
</update2>

O Kernel deverá ter suporte ao Bonding (Network device support -> Bonding driver support na compilação)

No /etc/modules.conf insira as linhas:
Alias bond0 bonding
probeall bond0 eth0 eth1 bonding # para carregar os módulos das outras eth antes de montar o bond
options bond0 miimon=100 updelay=200 downdelay=200

No /etc/sysconfig/network-scripts/ifcfg-bond0 insira:
DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

Todas as interfaces que pretencerão ao balanceamento deverão ter seu /etc/sysconfig/network-scripts/ifcfg-ethX definidos assim:
DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=no
BOOTPROTO=none

Deve-se indicar qual interface será escrava (SLAVE=yes) nesse caso a interface eth0 sera master e a eth1 devera ser slave.

Caso a distribuição não suporte o parametro SLAVE e MASTER no ifcfg-ethx, a configuração manual pode ser configurada desta maneira:

Sem inserção de módulos:
# /sbin/ifconfig bond0 192.168.1.1 up
# /sbin/ifenslave bond0 eth0
# /sbin/ifenslave bond0 eth1

Com inserção de módulos:
# /sbin/insmod bonding
# /sbin/ifconfig bond0 up
# /sbin/ifenslave bond0 eth0
# /sbin/ifenslave bond0 eth1
# /sbin/modprobe bonding miimon=100 updelay=200 downdelay=200
# /sbin/ifconfig bond0 192.168.1.1 netmask 255.255.255.0
# /sbin/ifconfig bond0 up
# /sbin/route add default gw 192.168.1.254

Opções do módulo

  • mode= Possiveis valores são: 0 (politica de round-robing, default) , 1 (Politica de backup ativo), e 2 (XOR);
  • miimon= Utilize um valor inteiro para a frequência (em ms) do monitoramento de link MII. Valor igual a zero (padrão) significa que o monitoramento do link será desabilitado. Um bom valor caso você queira utilizar o monitoramento é 100;
  • downdelay= Utilize um valor inteiro para definir o tempo de atraso para desabilitado o link após ser detectada uma falha (em ms) . Deve ser multiplo de miimon, sendo o valor padrão zero;
  • updelay= Utilize um valor inteiro para definir o tempo de atraso para habilitar o link após ser detectado o estado de “link up” (em ms) . Deve ser multiplo de miimon, sendo o valor padrão zero;
  • arp_interval= Utilize um valor inteiro para a frequência do monitoramento arp (em ms). o Valor padrão é zero e significa que o monitoramento arp esta desabilitado. Este campo só é válido em modo active_backup;
  • arp_ip_target= Um endereço IP para utilizar quando o arp_interval é > 0. Este é o alvo da requisição arp que determina a saúde do link com o alvo. Especifique este valor no formato ddd.ddd.ddd.ddd.

Acho que é isso… espero ter ajudo… Um Abraço, Neto.

Compressão de dados em transmissão HTTP

Recentemente efetuei alguns testes com o mod_deflate, um módulo que vem em conjunto com apache 2.0 que efetua a compressão de dados (html, xml, etc) antes de enviá-los ao browser. Fiquei satisfeito com o funcionamento e gostaria de compartilha-lo.

No primeiro exemplo que efetuei, o site do De-Grátis que tem seu tamanho avaliado (pelas propriedades do FireFox) em 3.81KB (3901 bytes) passou para 1.37KB (1407 bytes) – ou seja, a transferência foi reduzida em aproximadamente 64%. Já no segundo teste, utilizei o site do GSI Soluções que passou de 11.31KB (11579 bytes) para 2.94KB (3009 bytes), ou seja 25% do tamanho original (economia de banda de 75%).

Qualquer ganho entre 50% e 80% justifica a instalação de uma solução dessas, só deve ser avaliado o custo/benefício em relação ao uso de rede e cpu. a Tabela abaixo pode auxiliar na configuração:

  Falta em tempo de CPU Abundância em tempo de CPU
Falta de largura de banda Compressão mínima Compressão máxima
Abundância em largura de banda Sem compressão Compressão mínima

Abaixo existem algumas referências que utilizei para chegar ao meu objetivo. De qualquer forma, listo a configuração que utilizei:

No arquivo /etc/httpd/conf.d/httpd.conf logo abaixo da seção <IfModule mod_mime_magic.c>:

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE


# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html


# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip


# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html


# Don't compress these extensions
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary


# Configurando o nível de compressão
DeflateCompressionLevel 9
DeflateBufferSize 8192


# Logando o trabalho do mod_deflate
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
</IfModule>

No exemplo acima, é habilitado a compressão usando o módulo deflate. As linhas BrowserMatch tem por finalidade configurar a compactação de acordo com o browser que acessa. Na primeira linha, tratamos o browser Netscape Navigator 4.x que só permite compressão de tipos text/html. Já as versões 4.0.6, 4.0.7 e 4.0.8 possuem problemas na descompressão de htmls, e nesse caso (segunda linha) desabilitamos a compactação para não haver problemas. Na última linha BrowserMatch é efetuada uma correção dos browsers Internet Explorer que identificam-se como “Mozilla/4″ mas trabalha corretamente com compressão de dados, e neste caso é liberada a compressão.

As três linhas a seguir (SetEnvIfNoCase) informam para não compactar arquivos do tipo gif, jpeg, jpg, png, ico, exe, tgz, gz, zip, bz2 e pdf.

Em seguida é definido o nível de compressão que será aplicado no arquivo ( DeflateCompressionLevel 9) e o tamanho do buffer de compressão para cada iteração da zlib (DeflateBufferSize 8192).

Por fim, as linhas DeflateFilterNote colocam uma “nota” que será utilizada no momento de logging. Neste caso registrei as três possibilidades (Input, Output e Ratio) mas só utilizo a última, que é a porgentagem de compressão.

Como eu utilizo os logs no modo combined, alterei a linha de formatação adicionando o tamanho do arquivo original (%b) e o percentual de compactação do arquivo (mod_deflate: %{ratio}n pct.). Segue abaixo as linhas referentes ao logging:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %b mod_deflate: %{ratio}n pct." combined
CustomLog /var/log/apache/gsibr.com-access_log combined

Com isso pode-se escrever um script, para tirar a média de economia de banda feita com esse software. Acho que é isso… qualquer dúvida não relacionada aqui, consulte as referências recomendadas, ou me envie um e-mail.

<update>
Uma recomendação realizada pelo caio1982 no br-linux foi incluir alguma referência ao mod_gzip para os administradores que utilizam o Apache 1.3.x. Este módulo também permite a compressão de tráfego HTTP. Um bom artigo para a instalação configuração do mod_gzip foi escrito pelo Fábio Nunes no Viva o Linux.
</update>

Referências:

Backup do BD PostgreSQL

Uma forma simples de efetuar um backup completo do BD PostgreSQL é gerando um DUMP de todas as tabelas.

Abaixo é descrito como gerar o dump e restaurá-lo novamente:

Gerando um dump completo do Postgresql:
# su - postgres
$ pg_dumpall | gzip all.gz

Restaurando o dump:
# su - postgres
$ cat all.gz | gunzip | psql template1