Hoje vou falar sobre o ASM e sua configuracao para forcar a utilizacao do multipath.Por default o Oracle ASM e o ASMlib fazem um scan em busca dos dispositivos que o banco de dados utilizara.Em arquiteturas de grande porte e com a utilizacao de uma storage geralmente sao implementadas rotinas para balanceamento de carga e disponibilidade dos canais de comunicacao do servidor e a storage, o nome utilizado neste caso e multipath.Por exemplo , caso nosso servidor de banco possua LUNs apresentadas para o ASM , e existam duas ou mais controladoras de disco,no caso de uma falha em uma das controladoras ou mesmo na comunicacaoentre servidor e a controladora , utilizando o multipath teriamos uma redundancia de canal fazendo que os servicos de banco e quem os consome nao sofre-se downtime ou queda.Isso acontece por que para o servidor vao existir dois canais de comunicacao e na falta de um deles a falha seria suportada, ainda com esse tipo de arquitetura podemos contar com um balanceamento de carga racional evitando que uma ou outra controladora fiquem sobrecarregadas.Nosso problema e que por default o ASMlib nao funciona em multipath , na verdade o ASMlib so pode gerenciar um canal de comunicacao por vez e quando o ASM e instalado ele realiza um scan em busca dos discos e fixa o primeiro disco que encontrar.Ou seja no caso do exemplo acima o correto seria que o ASM fixa-se o pseudonome da LUN utilizada pelo ASM e nao um dos psudocanais criados pela mesma.Infelizmente e exatamente isso que ocorre por default um scan aleatorio.Fazendo que nossos planos de disponibilidade e balanceamento de carga caiam por terra.E possivel observar ate mesmo que em algumas situacoes extremas o ASMlib sobrepoe as definicoes da LUN em relacao a qual controladora utilizar.Pode parecer complicado mas nao e , vejam abaixo como diagnosticar o problema:Primeiramente devemos conhecer nossos volumes ASM , para tanto utilizamos o utilitario oracleasm (logado como root[geralmente mas pode variar de acordo com sua instalacao])[root@node2 ~]# oracleasm listdisksARCH1ARCH2ARCH3DATA1DATA2DATA3DATA4OCR1OCR2OCR3Perfeito agora vamos verificar o volume DATA2 novamente com o utilitario oracleasm para visualizarmos o pseudonome da LUN utilizada e seus psudocanais:[root@node2 ~]# oracleasm querydisk -p DATA2Disk "DATA2" is a valid ASM disk/dev/sdl1: LABEL="DATA2" TYPE="oracleasm"/dev/sdm1: LABEL="DATA2" TYPE="oracleasm"/dev/emcpowerd1: LABEL="DATA2" TYPE="oracleasm"Aqui 50% do nosso misterio se resolve com a opcao -p vemos o pseudonome da LUN utilizada e seus psudocanais ok.Agora utilizarei a opcao -d para descobrir qual dos tres dispositivos esta fixado no ASMlib apos seu scan aleatorio:[root@node2 ~]# oracleasm querydisk -d DATA2Disk "DATA2" is a valid ASM disk on device [8,177]Otimo, agora basta verificar no /dev fazendo um grep buscando o device 8, 177:[root@node2 ~]# ll -h /dev | grep 8, | grep 177brw-r----- 1 root disk 8, 177 Out 30 17:41 sdl1Otimo , esta fixado o device sdl1 e somente esse device sera utilizado ignorando as definicoes da LUN em relacao a disponibilidade e balanceamento, se o canal onde esse device esta ,cair o Banco vai cair tambem, em seguida as aplicacoes e depois o caos se instaura.Vejamos so por curiosidade em qual LUN esta esse device:[root@node2 ~]#