Bom dia a todos,
Chegou hoje a hora de concluir o post sobre a importância de utilizar multipath IO em configurações Linux.
Desta vez iremos abordar o multipath com utilização LVM, que é defacto a forma de gestão de volumes em Linux.
Aqui igualmente incorre-se muito em erros de configuração, especialmente em versões de LVM mais antigas que não compreendem de forma transparente a forma pela qual os discos são fornecidos ao sistema.
OU seja, se não houver uma configuração apropriada no ficheiro de configuração do LVM (lvm.conf) este erro irá ocorrer:
# pvs
Found duplicate PV lOXa1VWEVhi3oiQvFXSafdPL2HYqKAyJ: using /dev/sdc1 not /dev/sdb1
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup00 lvm2 a– 15.88G 0
/dev/sdc1 vgteste lvm2 a– 25.00G 25.00G
Este erro indica que o sistema está a ver o disco por dois caminhos, mas está a agarrar apenas o sdc.
Se o sdc falhar, o acesso ao invés de comutar para o sdb irá falhar.
Para testar a teoria efetuei:
# dd if=/dev/zero of=/mnt/ola.txt
Sendo que dentro do /mnt está montado um logical volume desde o volume group vgteste
# mount | grep -i teste
/dev/mapper/vgteste-teste on /mnt type ext3 (rw)
Quando interrompi o caminho, surgiram imediatamente os seguintes erros em log, ao mesmo tempo que a nossa aplicação simulada (dd a escrever para o filesystem abortou com IO Error):
scsi 7:0:0:1: Unhandled error code
scsi 7:0:0:1: SCSI error: return code = 0x00010000
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
Buffer I/O error on device dm-4, logical block 58926
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58927
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58928
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58929
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58930
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58931
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58932
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58933
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58934
lost page write due to I/O error on dm-4
Buffer I/O error on device dm-4, logical block 58935
lost page write due to I/O error on dm-4
scsi 7:0:0:1: rejecting I/O to dead device
scsi 7:0:0:1: rejecting I/O to dead device
scsi 7:0:0:1: rejecting I/O to dead device
scsi 7:0:0:1: rejecting I/O to dead device
scsi 7:0:0:1: rejecting I/O to dead device
Confirma-se, o volume group, e logical volumes dentro dele encontram indisponíveis:
# pvs
/dev/vgteste/teste: read failed after 0 of 4096 at 0: Input/output error
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup00 lvm2 a– 15.88G 0
/dev/sdc1 vgteste lvm2 a– 25.00G 23.04G
O mesmo comportamento que nos afetou inicialmente com aplicações direct IO, causa problemas aqui igualmente.
Para eliminar a falha, utilizaremos o multipath, na mesma configuração exata que utilizamos no exemplo do ultimo post :
# cat /etc/multipath.conf
defaults {
polling_interval 10
#selector “round-robin 0”
path_grouping_policy failover
#prio_callout “/bin/true”
path_checker tur
rr_min_io 100
rr_weight uniform
failback immediate
no_path_retry 12
user_friendly_names yes
}
blacklist {
devnode “^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*”
devnode “^hd[a-z][[0-9]*]”
}
multipaths {
multipath {
wwid 360000000000000000e00000000010001
alias multipathdisk0
}
}
Em seguida, e após a ativação do servico multipathd, o panorama muda substancialmente:
# pvs
PV VG Fmt Attr PSize PFree
/dev/mpath/multipathdisk0p1 vgteste lvm2 a– 25.00G 23.04G
/dev/sda2 VolGroup00 lvm2 a– 15.88G 0
Desapareceu o alerta de duplicate pv’s, e já não aparecem os discos físicos quando fazemos o pvscan, que foram substituídos pelo multipath pseudo-device.
Repetindo o teste do dd o resultado é igualmente diferente:
# mount | grep -i teste
/dev/mapper/vgteste-teste on /mnt type ext3 (rw)
Com o dd a correr, o erro ocorre, mas o filesystem não é colocado offline:
scsi 1:0:0:1: rejecting I/O to dead device
device-mapper: multipath: Failing path 8:16.
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: Unhandled error code
scsi 1:0:0:1: SCSI error: return code = 0x00010000
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
scsi 1:0:0:1: rejecting I/O to dead device
scsi 1:0:0:1: Unhandled error code
scsi 1:0:0:1: SCSI error: return code = 0x00010000
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
scsi 1:0:0:1: Unhandled error code
scsi 1:0:0:1: SCSI error: return code = 0x00010000
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK
Procurando o erro anterior de “dev/vgteste/teste: read failed after 0 of 4096 at 0: Input/output error” verifica-se que o erro não ocorre, continuando o filesystem disponível para a atividade aplicacional.
# pvs
PV VG Fmt Attr PSize PFree
/dev/mpath/multipathdisk0p1 vgteste lvm2 a– 25.00G 23.04G
/dev/sda2 VolGroup00 lvm2 a– 15.88G 0
Como ultima nota, lembro que o lvm está efetivamente preparado para responder via o caminho de multipath, se o multipath utilizado for o nativo do sistema.
No entanto, caso se utilize um mulipath proprietário (por exemplo powerpath ou hdlm), será necessário efetuar tweaking ao nível do lvm.conf para reconhecer estes devices como os válidos e não os sd* através da adição de filtros para o efeito:
Por exemplo:
preferred_names = [ “^/dev/mpath/”, “^/dev/mapper/mpath”, “^/dev/emcpower*”, “^/dev/[hs]d” ]
E excluindo os sd’s do scan do LVM:
filter = [ “a|/dev/sda*|”, “a|/dev/emcpower*|”, ” “r/.*/”]
Nota: O que o filtro faz é dizer que o sda e partições são validas para o LVM (o nosso disco de boot), os emcpower devices são válidos (discos de SAN), mas todos os restantes devices no sistema (os caminhos de storage) são descartados para que o LVM não os utilize.
Concluindo, ambos estes exemplos mostram a extrema importância de acessos redundantes em fibra, assim bem como de um software de multipath suportado que faça a gestão de falhas e balanceamento em fibra.
A não observação destas simples regras, leva muitas vezes a falhas que se traduzem em quebra de serviço e corrupção de dados.
São falhas e quebras perfeitamente evitáveis caso se tenha este pequeno cuidado, que melhora em muito a qualidade de servico prestado aos Clientes finais.
Caso tenham duvidas ou sugestões, podem -me encontrar em nuno at nuneshiggs.com.
Abraço e até a próxima.
Nuno