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 createdroot@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
# mkfs.ext3 /dev/AMS500/u01
# 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
Nenhum comentário:
Postar um comentário