Everlinux’s Blog

O FISL 9.0

Como você ja deve ter lido por aí em algum lugar, existiam filas quilométricas para pegar o crachá, de qualidade muito ruim por sinal (no terceiro dia era difícil encontrar algum sem remendo) além do que não recebemos os ANAIS e nem a grade de palestras impressa neste momento.

Fora essa desorganização, o acesso Wireless era mesmo coisa rara de funcionar. Você precisava ter muita sorte, e muita paciência para conectar — e para permanecer neste status por um tempo. Infelizmente, até mesmo o sinal de Internet falhou em algumas palestras, fazendo as mesmas terminarem em 20 minutos ao invés dos 50 propostos.

A PUC-RS é realmente um lugar incrível por seus vários aspectos, porém, acho que o lugar ficou pequeno para 7,5 mil pessoas lá circulando. Mais parecia o metrô Sé as 07:00 AM… um esbarrando no outro, uma loucura só :-p

Palestras

Além da notória baixa qualidade técnica com relação ao ano anterior, não gostei muito da forma de como várias palestras foram executadas por “parceiros patrocinados”, sem muito conteúdo técnico e até mesmo conteúdo a ver com SL/CA, somente focado em marketing do produto.

Sei que isso se faz necessário para a viabilização de um projeto deste porte, mas mas isso graças a Deus não foi regra. Várias excessões existiram, como por exemplo as palestras:

- Frederico A C Neves - DNSSEC e o .br;

- Miguel Di Ciurcio Filho - “Access Policy Delegation: transformando o Postfix no melhor MTA do planeta” e

- Rafael David Tinoco - “Arquitetura OpenSPARC: UltraSPARC T1 e UltraSPARC T2″.

Foram ótimos exemplos de palestras “patrocinadas”, com um ou dois slides sobre a empresa que os empregam e 99% de conteúdo técnico de altíssimo grau e primeiríssima qualidade, executadas por pessoas que realmente sabiam porquê estavam ali e também sabiam do que estavam falando.

Ainda sobre as palestras, notei várias vezes um certo “conflito de interesses” constante, pois várias boas palestras com assuntos parecidos aconteciam no mesmo dia e horário, obrigando você a escolher uma delas. Isso poderia ser evitado, como no caso do LTSP por exemplo.

Alguns temas estavam por demais redundantes, muitas palestras parecidas abortando o mesmo tema, como por exemplo “Alta Disponibilidade”:

- Jair Silva (CEF) - “Software Livre em Ambiente de Alta Criticidade com Alta Disponibilidade ”

- Joniel Pasqualetto - “Infra-estrutura corporativa de alta disponibilidade utilizando Software Livre”

- Fernando Ike de Oliveira - “HA em PostgreSQL: O Elefante disponível para além do infinito HA em PostgreSQL”

- Luis Otávio de Colla Furquim - “ChironFS - Sistema de Arquivos Tolerante a Falhas com Replicação”

- Darlan Segalin - “Sistemas de arquivos distribuídos e replicados em rede com alta disponibilidade em ambiente Open Source”

Não que eu esteja reclamando, havia macro-temas para todos os gostos, desde para sysadmins (mais técnicas) e para a parte gerencial (mais superficial), mas eu achei que alguns temas deveriam ser mais explorados, como por exemplo, Virtualização! Ou melhor ainda, o melhor dos dois mundos, algo do tipo “Clustes de Máquinas Virtuais”. Aí sim seria ótimo!

As palestras internacionais foram ótimas, e gostaria de destacar essas:

- Mark Bilansky (IBM) - “Combining Linux High Availability Clusters with Data Replication (DRBD)”

- Tirthankar Das (SUN) - “Can you survive a downtime?”

Enquanto o Indiano Tirthankar falava dos Clusters de Alta disponibilidade da SUN, eu estava na fila tentando pegar meu crachá, mas tive o prazer de conhece-lo logo depois da palestra do Mark, naquela tradicional “roda” que é formada em torno do palestrante logo após sua palestra

Tive sorte, pois ele foi muito atencioso em repassar sua palestra para mim, e mostrar ao vivo o cluster deles funcionando: http://www.opensolaris.org./os/community/ha-clusters/ohac/

Mozilla/ OLPC

A Mozilla Foundation estava comemorando 10 anos, e estava ministrando várias palestras em um prédio ao lado do que estávamos, distribuindo camisas, adesivos, bottons e etc para quem assistisse. Infelizmente, isso não estava escrito em lugar algum, achei a sala enquanto procurava por um banheiro

O mais legal foi ajudar o pessoal do OLPC a levar umas 40 camisas para as crianças que estavam no evento… foi realmente perigoso andar uns 500 metros, com uma porrada de nerds atrás de você querendo as camisetas!!! Mas foi super legal entrega-la às crianças

Diversos

A viajem valeu a pena por reencontrar velhos conhecidos de fórum anteriores e também por fazer novos amigos, para que possamos nos encontrar em fórums futuros, se Deus assim desejar!

Gostei muito de encontrar ex-estudantes da UFSC que em 2007 eram meros estagiários vindo em caravanas, hospedados em hoteis baratos que hoje tornaram-se pessoas importantes e patrocinadas pelas suas empresas, ficando em hotéis de luxo com tudo pago

Também gostei muito de ver as estudantes de nível técnico participando do evento, estas sementes que estamos plantando com certeza renderá bons frutos no futuro!

Fotos

Ah sim, o álbum de fotos está disponível aqui: http://everlinux.com/fotos/fisl9/

Assim que eu reunir mais fotos, eu atualizo o álbum

Se você usa o Xen, usa Storage Devices sob LVM, e acha importante ter um backup das mesmas, você pode utilizar/ adaptar este pequeno script que tira um snapshot e em seguida faz um “tar.gz” de todo o “/” da sua VM, e a guarda em um local para que você possa restaura-lo caso necessário.

#!/bin/bash
# Backup das VM's do Xen
# Tiago Cruz - tiagocruz@everlinux.com
# Mar/2008
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

echo "Backup finalizado em `date` com load de `cat /proc/loadavg`" >> $LOG
echo "=================================================================" >> $LOG
echo "=================================================================" >> $LOG


Trecho do log:

Backup ora_busca iniciado em Fri Mar 28 05:02:53 BRT 2008 com load de 1.31 1.33 1.21
Maquina Virtual ora_busca usa ora_busca como storage device
Logical volume “ora_busca_snap” created
Backup de /dev/mapper/Vol_LVM-ora_busca_snap1 - 16G de 95G usados
Criado /dados/backup/ora_busca-xen.tar.gz com 4.9G
Removendo snapshot ja backupeado ora_busca_snap
Logical volume “ora_busca_snap” successfully removed

Se você vive compilando módulos Perl em máquinas sem saída para a Internet, ou se você sofre com problemas de lentidão ou disponibilidade de links externos, seus problemas acabaram

Utilizando o CPAN-Mini (sua única dependência é o File-HomDir) você pode construir um repositório interno com menos de 1 GB e mante-lo atualizado diariamente com a seguinte entrada no crontab:

# Repositorio CPAN
30 04 * * * /usr/bin/minicpan -l /var/www/cpan/ -r http://cpan.kinghost.net/

Para utiliza-lo, você pode alterar o arquivo /etc/perl/CPAN/Config.pm da seguinte forma (no Debian/ Ubuntu):

'urllist' => [q[http://cpan.empresa.com.br/]],

Para os Red Hat’s da vida, você pode utilizar esta configuração:

[root@xen4-vm3 ~]# cat /usr/lib/perl5/5.8.5/CPAN/Config.pm

$CPAN::Config = {
'build_cache' => q[10],
'build_dir' => q[/root/.cpan/build],
'cache_metadata' => q[1],
'cpan_home' => q[/root/.cpan],
'ftp' => q[/usr/kerberos/bin/ftp],
'ftp_proxy' => q[],
'getcwd' => q[cwd],
'gpg' => q[/usr/bin/gpg],
'gzip' => q[/bin/gzip],
'histfile' => q[/root/.cpan/histfile],
'histsize' => q[100],
'http_proxy' => q[],
'inactivity_timeout' => q[0],
'index_expire' => q[1],
'inhibit_startup_message' => q[0],
'keep_source_where' => q[/root/.cpan/sources],
'links' => q[/usr/bin/links],
'make' => q[/usr/bin/make],
'make_arg' => q[],
'make_install_arg' => q[],
'makepl_arg' => q[],
'ncftp' => q[],
'ncftpget' => q[],
'no_proxy' => q[],
'pager' => q[/usr/bin/less],
'prerequisites_policy' => q[ask],
'scan_cache' => q[atstart],
'shell' => q[/bin/bash],
'tar' => q[/bin/tar],
'term_is_latin' => q[1],
'unzip' => q[/usr/bin/unzip],
'urllist' => [q[http://cpan.empresa.com.br/]],
'wget' => q[/usr/bin/wget],
};
1;
__END__


Depois basta deixa-lo disponível a partir de algum webserver como por exemplo o apache, algo mais ou menos assim:

< VirtualHost cpan.empresa.com.br:80 >
ServerName cpan.empresa.com.br:80
ServerAdmin implantacao@dc.com.br
DocumentRoot /var/www/cpan
ErrorLog /var/www/cpan/logs/cpan-error_log
CustomLog /var/www/cpan/logs/cpan-access_log combined env=!gif-image

< Directory "/var/www/cpan" >
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from 192.168.44.0/22 192.168.50.0/22
< / Directory >
< / VirtualHost >


Se as entradas estiverem todas corretas, para testar você pode fazer o seguinte:

# perl -MCPAN -e shell
cpan> install Crypt::SmbHash

Saiu uma nota muito interessante neste final de semana no Dicas-L, uma dica de Rogerio Acquadro:

“Buscando na Internet, encontrei uma ferramenta chamada MySQLDiff (http://www.mysqldiff.org). Trata-se de um software em PHP que faz a comparação entre duas bases de dados (não necessariamente locais) e, como resultado da análise, gera um script SQL. A idéia é que, ao aplicar esse script SQL à base local, esta fique com a estrutura idêntica da base final.

O programa é bem completo e ainda conta com alguns filtros. Por exemplo, o programador pode optar se o MySQLDiff vai trazer no script apenas as alterações estruturais (que era o que eu buscava) ou se também analizará o conteúdo das tabelas, entre outras opções. “

A nota completa encontra-se no Dicas-l, eu só precisava anotar aqui para não esquecer… vivo precisando de coisas como essa

Atendendo a pedidos, este post visa informar os desavisados que o FISL 9.0 ocorrerá em Porto Alegre nos dias 17, 18 e 19 de Abril de 2008, na PUC-RS — mesmo local onde eu participei em 2004/ 2005 e bem melhor dos lugares que foram em 2006/ 2007.

O site oficial do evento pode ser encontrado aqui: http://fisl.softwarelivre.org/9.0/www/

Só não sei se poderei participar este ano, devido a problemas pessoais…
Mas de qualquer forma, quem for irá aprender e se divertir muito!
Abraços a todos!

- Introdução:

O netcat é um utilitário que permite escrita e leitura de dados atraves de conexão de rede, usando o proolo TCP/IP. Ele ainda permite especificar a porta que será transmitido, independe de onde será o server (listen) se na origem ou destino.
No caso de substituição do scp, permite usar o processamento que seria p/ encriptar no processo de compactação da
transmissão.

O NetCat (ou nc) é extremamente útil onde os principais meios de troca de arquivos não estão presentes ou suas portas estão filtradas em firewalls e roteadores (ex: scp, rsync, nfs…)

Usando o programa pv se consegue ter uma visualização da taxa de transmissão

- Copia de diretório
- Na maquina destino

nc -vlp port_escuta_detino | tar xzvp

-Na maquina origem

tar cpz ./ | nc ip_destino port_escuta_detino

- Copia de partição

- Na maquina origem

dd if=/dev/hdb5 | gzip -9 | nc -l porta_escuta_origem

- Na maquina destino

nc ip_origem porta_escuta_origem | pv -b > myhdb5partition.img.gz

- Transferindo arquivo

- Na maquina origem

cat backup.iso | nc -l 3333

- Na maquina destino

nc ip_origem porta_escuta_origem > backup.iso

Com status da transferência
- Na maquina origem

cat backup.iso | pv -b | nc -l 3333

- Na maquina destino

nc ip_origem porta_escuta_origem | pv -b > backup.iso

- Exemplo:

[root@squid-xen chroot]# nc -vl 6969 | tar zxv

[root@squid-producao chroot]# tar zcv var/ | nc squid-xen 6969
var/
var/named/
var/named/data/
var/named/slaves/
var/named/named.pid
var/named/localhost.zone
var/named/localhost.rev
var/named/named.cache
var/run/
var/run/named/
var/run/named/named.pid
var/run/dbus/
var/tmp/

Dica de Edson Moreno - jemorenojr AT ig.com.br

FAUS significa “Ferramenta de Administração de Usuários do Samba” e é um CGI escrito em Perl para permitir a administração de usuários via uma interface web.

A versão 1.4.5, além dos bugs corrigidos, trouxe também algumas novidades como por exemplo o suporte completo ao SaMBa 3.x, inclusive alterando de base de dados smbpasswd para tdbsam. Foi possível fazer isso deixando de editar o smbpasswd diretamente e voltando a usar os programas do SaMba. Com isso, foi retirado o suporte ao SaMBa 2.x.

Também é possível agora alterar o nome de usuário, sem precisar deletar e cria-lo novamente O FAUS se encarrega de alterar no sistema e no SaMBa.

O instalador, anteriormente só funcionava em Debian agora funciona em suas variações (Kurumin, xUbuntu) e também em distribuiçoes baseadas em RPM (testada no Mandriva 2007, fácilmente portado à outros). E todos aqueles módulos perl chatos de instalar estão agora incluídos no próprio tarball do FAUS para evitar problemas com falta de conexão ou versões incompatíveis dos módulos com o FAUS.

Em caso de problemas, críticas ou sugestões procure-nos na lista faus-users.

1-) Estou armazenando as VMs no LVM:

# lvcreate -Ay -L 60G -n vm00 Vol_LVM
# lvcreate -Ay -L 60G -n vm01 Vol_LVM
# lvcreate -Ay -L 60G -n vm02 Vol_LVM

2-) Estou usando o “partimage-0.6.7_beta2.tar.bz2″, pois a versão stable não funciona bem em 64 bits:

3-) A primeira VM deve ser instalada/ configurada manualmente/normalmente. Depois você pode tirar uma cópia dela:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# partimage -z1 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg.gz
ou
# partimage -z0 -c -d -f0 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg
# kpartx -d /dev/mapper/Vol_LVM-vm01

PS: Note que se você usar compressão (-z1) a geração da imagem vai demorar mais para ser criado, porém com o tamanho bem menor (515M vs 3.7GB) . A restauração da mesma também será mais lenta.

4-) Com base na primeira VM:

# fdisk -l /dev/mapper/Vol_LVM-vm00
Disk /dev/mapper/Vol_LVM-vm00: 64.4 GB, 64424509440 bytes
255 heads, 63 sectors/track, 7832 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/mapper/Vol_LVM-vm00p1 * 2 7395 59392305 83 Linux
/dev/mapper/Vol_LVM-vm00p2 7396 7832 3510202+ 82 Linux swap / Solaris


Você poderá preparar um arquivo, por exemplo, /tmp/parttable, com as especificações das demais partições.
1,7394,83,*
7395,,82,-

Estou usando uma partição primária para o raiz “/” (tipo 83) com ~ 60 GB e o restante para swap (tipo 82).

Você poderá usar o sfdisk e especificar os dados em: sectors, blocks, cylinders ou megabytes.

5-) Crie as partições para a segunda VM:

# dd if=/dev/zero of=/dev/mapper/Vol_LVM-vm01 count=1 bs=512
# sfdisk -uC /dev/mapper/Vol_LVM-vm01 < /tmp/parttable

Se preferir, simplesmente faça o processo manualmente:
# fdisk /dev/mapper/Vol_LVM-vm01

6-) Crie a SWAP para o segundo device:

Será necessário usar o “kpartx” para “mapear” as partições que existem dentro do device LVM:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# ll /dev/mapper/Vol_LVM-vm01*
# mkswap /dev/mapper/Vol_LVM-vm01p2

7-) Restaure a imagem da primeira VM:

- Restauração com GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm02p1 /LVM/vm01p1.partimg.gz
Time elapsed: 10m:59sec
Speed: 5.16 GiB/min
Data copied: 56.64 GiB

- Restauração sem GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm03p1 /LVM/vm01p1.partimg.000
Time elapsed: 1m:15sec
Speed: 2.90 GiB/min
Data copied: 3.62 GiB

Monte a VM e troque endereços de IP, hostname e MAC Address:
# mount /dev/mapper/Vol_LVM-vm01p1 /mnt/xen/
# vi /mnt/xen/etc/sysconfig/network-scripts/ifcfg-eth0
# vi /mnt/xen/etc/sysconfig/network
# vi /mnt/xen/etc/hosts

PS: Use o macgen.py para alterar o MAC address:

$ cat macgen.py
#! /usr/bin/python
# macgen.py script generates a MAC address for Xen guests
#
import random
mac = [ 0×00, 0×16, 0×3e,
random.randint(0×00, 0×7f),
random.randint(0×00, 0xff),
random.randint(0×00, 0xff) ]
print ‘:’.join(map(lambda x: “%02x” % x, mac))

9-) Desmonte a partição, e arrume seu /etc/xen/vm02:

# umount /mnt/xen
# kpartx -d /dev/mapper/Vol_LVM-vm02


Utilize o “uuidgen” para gerar um novo UUID para sua VM.
Não esqueça de trocar também o MAC no campo “vif” e o device LVM, ex:

name = “vm02″
uuid = “82f89076-487e-4de5-ab4a-99ce07c586eb”
maxmem = 1000
memory = 800
vcpus = 1
bootloader = “/usr/bin/pygrub”
on_poweroff = “destroy”
on_reboot = “restart”
on_crash = “restart”
vfb = [ “type=vnc,vncunused=1,keymap=en-us” ]
disk = [ “phy:/dev/Vol_LVM/vm01,xvda,w” ]
vif = [ “mac=00:16:3e:5a:02:a6,bridge=xenbr0″ ]

10-) Inicie a VM e corra para o abraço:

# xm create vm02 -c

Em caso de problemas, consulte este artigo: Xen: Dicas rápidas e problemas resolvidos

Este post abrange o Storage AMS500 da Hitachi, comercialmente conhecido pelo modelo DF700M.

O Storage possui RAID Groups em Fibre Channel usando RAID5 (5D+1P), e algumas RAID Groups de discos SATA usando RAID6 (7D+2P).

Sobre o Multi Path (HDLM) do Storage Hitachi

Conforme o desenho, pode-se observar que será necessário um software multipath para controlar os vários caminhos que os servidores “server-spo-la-1″ e “server-spo-la-2″ podem fazer para chegar até os discos do storage.

Para exemplificar, o server-spo-la-1 pode fazer os seguintes caminhos:
- Passar pela fibra saindo pela HBA0 até o Switch 1, e chegar no storage pela Controller 0, porta A;
- Passar pela fibra saindo pela HBA1 até o Switch 2, e chegar no storage pela Controller 0, porta B;
- Passar pela fibra saindo pela HBA1 até o Switch 2, e chegar no storage pela Controller 1, porta A;
- Passar pela fibra saindo pela HBA0 até o Switch 1, e chegar no storage pela Controller 0, porta B;

É aí que entra o HDML (Hitachi Dynamic Link Manager). O problema é que para cada caminho que o SO faz até o Storage, ele encontra discos e “pensa” que são discos diferentes. Portanto, se você tem 25 LUNs exportadas para o server-spo-la-1, ele irá “enxergar” 100 discos (25*4=100). Será algo parecido com isso:

root@server-spo-la-1 ~# fdisk -l 2> /dev/null | grep "38.6 GB"
Disk /dev/sdb: 38.6 GB, 38654705664 bytes
Disk /dev/sdc: 38.6 GB, 38654705664 bytes
Disk /dev/sdd: 38.6 GB, 38654705664 bytes
Disk /dev/sde: 38.6 GB, 38654705664 bytes
Disk /dev/sdf: 38.6 GB, 38654705664 bytes
Disk /dev/sdg: 38.6 GB, 38654705664 bytes
Disk /dev/sdh: 38.6 GB, 38654705664 bytes
Disk /dev/sdi: 38.6 GB, 38654705664 bytes
Disk /dev/sdj: 38.6 GB, 38654705664 bytes
Disk /dev/sdk: 38.6 GB, 38654705664 bytes
Disk /dev/sdl: 38.6 GB, 38654705664 bytes
Disk /dev/sdm: 38.6 GB, 38654705664 bytes
Disk /dev/sdn: 38.6 GB, 38654705664 bytes
Disk /dev/sdo: 38.6 GB, 38654705664 bytes
Disk /dev/sdp: 38.6 GB, 38654705664 bytes
Disk /dev/sdq: 38.6 GB, 38654705664 bytes
Disk /dev/sdr: 38.6 GB, 38654705664 bytes
Disk /dev/sds: 38.6 GB, 38654705664 bytes
Disk /dev/sdt: 38.6 GB, 38654705664 bytes
Disk /dev/sdu: 38.6 GB, 38654705664 bytes
Disk /dev/sdv: 38.6 GB, 38654705664 bytes
Disk /dev/sdw: 38.6 GB, 38654705664 bytes
Disk /dev/sdx: 38.6 GB, 38654705664 bytes
Disk /dev/sdy: 38.6 GB, 38654705664 bytes
Disk /dev/sdz: 38.6 GB, 38654705664 bytes
Disk /dev/sdaa: 38.6 GB, 38654705664 bytes
Disk /dev/sdab: 38.6 GB, 38654705664 bytes
Disk /dev/sdac: 38.6 GB, 38654705664 bytes
Disk /dev/sdad: 38.6 GB, 38654705664 bytes
Disk /dev/sdae: 38.6 GB, 38654705664 bytes
Disk /dev/sdaf: 38.6 GB, 38654705664 bytes
Disk /dev/sdag: 38.6 GB, 38654705664 bytes
…

Completamente bizarro

Instalação do HDLM

O processo de instalação é um tanto chato, e cada servidor precisa de uma licença diferente. Em termos gerais, seria mais ou menos isso:

-> Verificar se o server acha os discos com um fdisk -l

-> Copiar o license key para:
/var/tmp/hdlm_license
/etc/opt/DynamicLinkManager/dlm.lic_key

-> Rodar o /media/cdrom/installhdml

-> No /etc/profile

PATH=$PATH:/opt/DynamicLinkManager/bin ; export PATH

-> Reboot

-> Verificar se o fdisk -l mostra mais discos

Se tudo der certo, além dos 100 discos de outrora, seu servidor irá enxergar mais 25 (!!!) mas agora com outro nome. E será esse device que você irá utilizar para guardar os dados:

Disk /dev/sddlmaa: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmab: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmac: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmad: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmae: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmaf: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmag: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmah: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmai: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmaj: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmak: 38.6 GB, 38654705664 bytes
Disk /dev/sddlmal: 38.6 GB, 38654705664 bytes

…

Configuração do HDLM

Caso você queira testar se o HDML está mesmo funcionando, você poderia tirar uma fibra enquanto copia os dados, chutar o switch ou algo do tipo

# dlnkmgr set -lb on
# dlnkmgr set -pchk on -intvl 5
# dlnkmgr set -afb on -intvl 5
# dlnkmgr set -ellv 2
# dlnkmgr set -systflv 1
# dlnkmgr set -elfs 1000
# dlnkmgr set -elfn 5
# dlnkmgr set -systfs 2000
# dlnkmgr set -systfn 10

Para verificar:

# dlnkmgr view -path | more
# dlnkmgr view -sys
# dlnkmgr view -lu | more

Este setup irá ativar o Load Balance, verificação de PATH, auto Failback em caso de falhas e etc.

Configurando o LVM

Existe ainda mais um cuidado a ser tomado antes de você conseguir brincar com o Storage. O LVM é uma ferramenta muito esperta, e ele identifica cada disco com uma assinatura, individual e intransferível, mais ou menos como a sua impressão digital.

Portanto, ao adicionar um disco do HDLM ao LVM, você verá algo parecido com isso:

root@server-la-2 ~# pvcreate /dev/sddlmaa
Physical volume “/dev/sddlmaa” successfully created

root@server-la-2 ~# pvs
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdb not /dev/sddlmaa
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdch not /dev/sdb
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdbf not /dev/sdch
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sdad not /dev/sdbf
Found duplicate PV sXzKX9RMVxSafKzfDJP78Zr4qYFPNPcO: using /dev/sddlmaa not /dev/sdad
PV VG Fmt Attr PSize PFree
/dev/sda2 Vol_LVM lvm2 a- 408.17G 0
/dev/sddlmaa lvm2 — 36.00G 36.00G

O que acontece é que o LVM está vendo o mesmo disco (mesma LUN, na verdade) pelos 04 caminhos diferentes e mais o novo caminho, do HDLM.

O que você deve fazer, é editar o arquivo /etc/lvm/lvm.conf e criar um filtro separando os devices que devem de fato serem manipulados pelo LVM, algo deste tipo:

filter = [ “a/sda1-9$/” “a/sddla-za-za-z$/” “r/.*/” ]

Após isso, basta rodar um ‘vgscan -vv’ para refazer o cache.

Passos rápidos para configurar o LVM no Storage

Papo rápido:


# for i in `fdisk -l 2> /dev/null | grep "sddl" | awk '{print $2}' | cut -d : -f 1`; do pvcreate $i; done



# vgcreate -Ay AMS500 /dev/sddlmaa /dev/sddlmab /dev/sddlmac /dev/sddlmad \
/dev/sddlmae /dev/sddlmaf /dev/sddlmag /dev/sddlmah /dev/sddlmai /dev/sddlmaj \
/dev/sddlmak /dev/sddlmal /dev/sddlmam /dev/sddlman /dev/sddlmao /dev/sddlmap \
/dev/sddlmba /dev/sddlmbb /dev/sddlmbc /dev/sddlmbd /dev/sddlmbe /dev/sddlmbf \
/dev/sddlmbg /dev/sddlmbh /dev/sddlmbi /dev/sddlmbj /dev/sddlmbk /dev/sddlmbl



# lvcreate -Ay -L 1.2T --name u01 AMS500

# mkdir /u01; mount /dev/AMS500/u01 /u01

Pronto! 1.2 TB para brincar

Ganhando desempenho fazendo Stripe no LVM

É possível fazer Stripe do lado do Sistema Operacional, visando um maior desempenho

Cada servidor está “enxergando” 28 LUNs do Storage, como se cada LUN fosse um disco.

Utilizei o “dd” para criar arquivos de 10 e 40 GB nos servidores, tanto na “Barriga” da máquina (Dell PowerEdge 2950 em RAID 10) quanto no Storage. Depois disso, irei utilizar nos servidores Stripes com granulação de 128 KB, sempre no FileSystem com Block Size de 4KB para comparar:

# Teste Storage Billing
# LVM padrão (sem stripe) e Block Size de 4KB

=> 10 GB com LVM default:
root@server-la-1 ~# Storage: 1m38.939s
root@server-la-1 ~# Barriga: 1m22.395s

root@server-la-2 ~# Storage: 1m57.203s
root@server-la-2 ~# Barriga: 1m15.134s

=> 40 GB com LVM default:
root@server-la-1 ~# Storage: 10m23.250s
root@server-la-1 ~# Barriga: 06m04.812s

root@server-la-2 ~# Storage: 11m22.150s
root@server-la-2 ~# Barriga: 06m01.234s

# lvcreate -Ay -i 28 -I 128 -l258020 –name u01 AMS500
# 28 Stripes com granulação de 128 KB cada (Block size=4096)

=> 10 GB com LVM + Stripe 128K
root@server-la-2 ~# Storage: 1m02.411s
root@server-la-2 ~# Barriga: 1m18.440s

=> 40 GB com LVM + Stripe 128K
root@server-la-2 ~# Storage: 4m49.578s
root@server-la-2 ~# Barriga: 5m50.452s

# lvcreate -Ay -i 28 -I 64 -l258020 –name u01 AMS500
# 28 Stripes com granulação de 64 KB cada (Block size=4096)

=> 10 GB com LVM + Stripe 64K
root@server-la-1 ~# Storage: 1m42.396s
root@server-la-1 ~# Barriga: 1m44.903s

=> 40 GB com LVM + Stripe 64K
root@server-la-1 ~# Storage: 5m04.977s
root@server-la-1 ~# Barriga: 5m55.737s

Teste de desempenho

Resultados dos testes de desempenho do Storage feitos por uma ferramenta mais profissional (Bonnie++), que faz vários testes além do qual eu fiz:

http://everlinux.com/raid/bonnie.html

Testei na minha máquina de casa (IDE) e do escritório (SATA) também, só para lembrar que eu preciso trocar meu velho Athlon 2000

Caso você precise saber quanta memória seus processos do apache estão utilizando do seu SO, pode utilizar este script no crontab:

#!/bin/bash
LOG="/var/log/apache_memoria.log"
PROC=`ps -eLf | grep apache | wc -l`
rm -f /tmp/http.txt
for i in `ps -ylC httpd --sort:rss | awk '{print $8}'`; do echo $i | grep -v RSS >> /tmp/http.txt ; done
MEM=$(echo "scale=2; (`cat /tmp/http.txt | tr '\n' +`0"\)/1024 | bc)
echo "`date` -- $MEM MB utilizados pelo httpd com $PROC processos" >> $LOG