Olá a todos,
Recentemente tomei consciência que existem ainda demasiados casos de suporte, causados por má configuração de multipath em discos ou storage centralizado, ou desconhecimento total de como se deve utilizar.
Em primeiro lugar, há que ter a noção do que é o multipath (seja ele o nativo do Linux, seja um proprietário):
É um subsistema de abstração do hardware de ligação física aos discos/armazenamento, quando o disco é visto por mais que um caminho (path).
O pressuposto é que o sistema operativo, ou aplicações, possam usar esta camada de abstração, para que possam gerir falhas no acesso ao mesmo.
Na pratica, em caso de falha de um caminho, existe o outro e o sistema automaticamente agulha o pedido para o disponível, mantendo o que reside nesses discos a funcionar corretamente.
Existe no entanto, a necessidade de haver uma correta configuração do software que faz esta gestão.
Existe a ideia em alguns círculos que a configuração é automática e transparente. Não o é.
O exemplo abaixo é dado para o multipath nativo de linux, com dois caminhos para o mesmo disco:
Em primeiro lugar temos de instalar e configurar o multipath em si:
# yum -y install device-mapper-multipath
Em seguida será necessário configurar o mesmo:
# 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
}
}
Nota1: um dos campos importantes a ter atenção é a secção blacklist. Nesta secção é construida a lista de exclusões de devices a não adicionar via multipath:
blacklist {
devnode “^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*”
devnode “^hd[a-z][[0-9]*]”
}
Ou seja, excluir todos os devices de nome ram,raw,loop,etc,etc,etc. Podem ser utilizadas expressões regulares para excluir alguns dos devices.
Nota2: Pode ser escolhido um nome “humano” que facilite a gestão dos discos (ou de que storage eles são exportados).
Neste campo efetua-se o alias entre um multipath device disk scsi ID (validavel no primeiro arranque do multipathd ou através do comando scsi_id) , para um nome humano:
multipath {
wwid 360000000000000000e00000000010001
alias multipathdisk0
}
Após a configuração do multipath, na primeira execução, é necessário carregar o modulo de kernel que irá gerir esta configuração e a negociação com os caminhos físicos para o disco:
# modprobe dm_multipath
Carregar o servico, deixado o mesmo persistente ao reboot:
# systemctl enable multipathd
# systemctl start multipathd
Temos agora um sistema multipath a funcionar, sendo os dois caminhos do mesmo disco, apresentado ao sistema via o pseudo device redundante multipathdisk0:
multipathdisk0 (360000000000000000e00000000010001) dm-2 IET ,VIRTUAL-DISK
size=25G features=’1 queue_if_no_path’ hwhandler=’0′ wp=rw
|-+- policy=’service-time 0′ prio=1 status=active
| `- 11:0:0:1 sdc 8:32 active ready running
`-+- policy=’service-time 0′ prio=1 status=enabled
`- 10:0:0:1 sdb 8:16 active ready running
Esquematicamente o resultado será algo como o diagrama abaixo:
Para demonstrar as funcionalidades de uma forma extremamente básica vamos começar com o teste do dd:
Nota: Pela sua natureza de escrita este laboratório irá destruir toda a informação presente no disco em multipath. Não usem discos com informação que necessitam para este tipo de testes.
Teste de escrita via disco multipath:
Comecemos por escrever dados aleatoriamente no disco multipathdisk0:
# dd if=/dev/zero of=/dev/mapper/multipathdisk0 &
Observando o iostat temos:
avg-cpu: %user %nice %system %iowait %steal %idle
0.12 0.00 5.10 48.44 6.03 40.32
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 526.60 2088.80 2032.00 10444 10160
sdc 0.00 0.00 0.00 0 0
multipathdisk0 526.60 2088.80 2032.00 10444 10160
Podemos assim notar que a escrita efetuada no multipathdisk0 está a ser escrita na realidade no device sdb (que vem de um storage centralizado).
Simulando uma avaria no caminho que fornece o sdb temos:
[ 4966.638309] sd 3:0:0:1: [sdb] Synchronizing SCSI cache
[ 4966.638375] device-mapper: multipath: Failing path 8:16.
Em IOstat podemos observar a alteração de comportamento:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sdb 0.00 0.00 0.00 0 0
sdc 175.00 696.00 422.40 3480 2112
multipathdisk0 175.00 696.00 422.40 3480 2112
Notamos que o que está a ser escrito no sistema alternou entre o sdb e o sdc, e que o pseudo device de multipath multipathdisk0 reflete os IO rates que estão a ser escritos no sdc.
Podemos ainda validar que o disco sdb deixou de estar visível no multipath:
multipathdisk0 (360000000000000000e00000000010001) dm-2 IET ,VIRTUAL-DISK
size=25G features=’1 queue_if_no_path’ hwhandler=’0′ wp=rw
`-+- policy=’service-time 0′ prio=1 status=active
`- 9:0:0:1 sdc 8:32 active ready running
avg-cpu: %user %nice %system %iowait %steal %idle
0.12 0.00 5.18 49.14 6.21 39.36
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.60 0.00 0.30 0 1
sdb 507.80 2013.60 2148.00 10068 10740
sdc 0.00 0.00 0.00 0 0
multipathdisk0 507.80 2013.60 2148.00 10068 10740
Repondo a path ao disco, e efetuando novo rescan, podemos visualizar que o multipath já se encontra redundante novamente e não houve quebra de servico:
multipathdisk0 (360000000000000000e00000000010001) dm-2 IET ,VIRTUAL-DISK
size=25G features=’1 queue_if_no_path’ hwhandler=’0′ wp=rw
|-+- policy=’service-time 0′ prio=1 status=active
| `- 11:0:0:1 sdc 8:32 active ready running
`-+- policy=’service-time 0′ prio=1 status=enabled
`- 10:0:0:1 sdb 8:16 active ready running
Como identificar problemas:
Infelizmente, persistem casos onde os administradores de sistema ou aplicações não utilizam os pseudo devices para suportar as suas aplicações de direct IO.
O que se consegue visualizar quando o problema ocorre?
Para descobrir vamos repetir o teste acima, só que ao invés de utilizarmos o pseudo device, iremos utilizar o device físico:
Primeiro identificamos qual o device físico que compõe o multipathdisk0:
multipathdisk0 (360000000000000000e00000000010001) dm-2 IET ,VIRTUAL-DISK
size=25G features=’1 queue_if_no_path’ hwhandler=’0′ wp=rw
|-+- policy=’service-time 0′ prio=1 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy=’service-time 0′ prio=1 status=enabled
`- 4:0:0:1 sdc 8:32 active ready running
Para o teste em questão iremos testar sobre o device sdc:
# dd if=/dev/zero of=/dev/mapper/sdc
Como resultado em iostat temos:
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 3.28 50.33 2.51 43.89
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.00 0.00 0.00 0 0
sdb 0.00 0.00 0.00 0 0
sdc 221.20 878.40 716.80 4392 3584
multipathdisk0 0.00 0.00 0.00 0 0
Podemos notar que toda a escrita está no disco físico, não sendo registada qualquer atividade no pseudo disk multipathdisk0.
Quando desativamos o caminho em uso (que dá origem ao sdc) ocorre imediatamente o seguinte erro:
# dd if=/dev/zero of=/dev/sdc
dd: writing to ‘/dev/sdc’: Input/output error
Qualquer aplicação que estivesse em uso neste device falharia, e dependendo da natureza da mesma, provavelmente iria levar a um crash de sistema.
O mesmo se pode verificar em termos de leituras:
# dd if=/dev/sdc of=/dev/null
avg-cpu: %user %nice %system %iowait %steal %idle
0.12 0.00 2.13 54.62 4.38 38.74
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 0.20 0.00 1.60 0 8
sdb 0.00 0.00 0.00 0 0
sdc 61.00 7808.00 0.00 39040 0
multipathdisk0 0.00 0.00 0.00 0 0
Quando se interrompe a path até ao disco exportado ocorre o esperado:
# dd if=/dev/sdc of=/dev/null
dd: error reading ‘/dev/sdc’: Input/output error
Neste caso, igualmente qualquer aplicação que estivesse em uso neste device falharia, e dependendo da natureza da mesma, provavelmente iria levar a um crash de sistema.
Concluindo, este é o case study mais simples relacionado com o multipath e demonstra o funcionamento através de aplicações que utilizem o direct IO do kernel, com processos ligados diretamente a devices físicos.
Como exemplo de aplicações que utilizam direto IO temos o ASM / RAC da Oracle, e como qualquer aplicação que utiliza direct IO, necessita forçosamente de utilizar a tecnologia de multipath sobre pena de que em caso de falha de path exista corrupção de dados e indisponibilidade do serviço.
Esta tecnologia existe e é implementada por muitos fabricantes, por exemplo a Hitachi com o seu HDLM, ou a EMC/Dell com o PowerpPath
Para a próxima semana, irei abordar o mesmo processo, mas com um layer de LVM aplicado ao multipath de forma a que exista igualmente em filesystems assentes em LVM abstração de uma falha de caminho físico ao disco.
Até lá, boa semana!
Abr.
Nuno Higgs.