ASMlib e o PowerPath
Autor: Mario Leonel Martinez Junior | Publicado: 2015-02-11T07:34:00-04:00



Hoje vou falar sobre o ASM e sua configuração para forçar a utilização do multipath.Por default o Oracle ASM e o ASMlib fazem um scan em busca dos dispositivos que o banco de dados utilizará.

Em arquiteturas de grande porte e com a utilização de uma storage geralmente são implementadas rotinas para balanceamento de carga e disponibilidade dos canais de comunicação do servidor e a storage, o nome utilizado neste caso é 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 comunicação

entre servidor e a controladora , utilizando o multipath teríamos uma redundância de canal fazendo que os serviços de banco e quem os consome não sofre-se downtime ou queda.Isso acontece por que para o servidor vão existir dois canais de comunicação 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 é que por default o ASMlib não funciona em multipath , na verdade o ASMlib só pode gerenciar um canal de comunicação por vez e quando o ASM é 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 não um dos psudocanais criados pela mesma.Infelizmente é exatamente isso que ocorre por default um scan aleatório.Fazendo que nossos planos de disponibilidade e balanceamento de carga caiam por terra.É possível observar ate mesmo que em algumas situações extremas o ASMlib sobrepõe as definições da LUN em relação a qual controladora utilizar.


Pode parecer complicado mas não é , vejam abaixo como diagnosticar o problema:

Primeiramente devemos conhecer nossos volumes ASM , para tanto utilizamos o utilitário oracleasm (logado como root[geralmente mas pode variar de acordo com sua instalação])

[root@node2 ~]# oracleasm listdisks
ARCH1
ARCH2
ARCH3
DATA1
DATA2
DATA3
DATA4
OCR1
OCR2
OCR3

Perfeito agora vamos verificar o volume DATA2 novamente com o utilitário oracleasm para visualizarmos o pseudonome da LUN utilizada e seus psudocanais:

[root@node2 ~]# oracleasm querydisk -p DATA2
Disk "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 mistério se resolve com a opção -p vemos o &nbsp;pseudonome da LUN utilizada e seus psudocanais ok.
Agora utilizarei a opção -d para descobrir qual dos trés dispositivos esta fixado no ASMlib apos seu scan aleatório:

[root@node2 ~]# oracleasm querydisk -d DATA2
Disk "DATA2" is a valid ASM disk on device [8,177]

Ótimo, agora basta verificar no /dev fazendo um grep buscando o device 8, 177:

[root@node2 ~]# ll -h /dev | grep 8, | grep 177
brw-r----- &nbsp;1 root disk &nbsp; &nbsp;8, 177 Out 30 17:41 sdl1

Ótimo , esta fixado o device sdl1 e somente esse device sera utilizado ignorando as definições da LUN em relação a disponibilidade e balanceamento, se o canal onde esse device esta ,cair o Banco vai cair também, em seguida as aplicações &nbsp;e depois o caos se instaura.
Vejamos só por curiosidade em qual LUN esta esse&nbsp;device:

[root@node2 ~]# powermt display dev=all

Pseudo name=emcpowerd
CLARiiON ID=CKM00134401537 [Oracle-HOM]
Logical device ID=6006016036E1360096C02A21D2C4E311 [LUN 1]
state=alive; policy=CLAROpt; priority=0; queued-IOs=0;
Owner: default=SP B, current=SP B &nbsp; &nbsp; &nbsp; Array failover mode: 4
========================================================================
--------------- Host --------------- &nbsp; - Stor - &nbsp; -- I/O Path -- &nbsp;-- Stats ---
### &nbsp;HW Path &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I/O Paths &nbsp; &nbsp;Interf. &nbsp; Mode &nbsp; &nbsp;State &nbsp; Q-IOs Errors
========================================================================
&nbsp; &nbsp;5 iSCSI Initiator over TCP/I sdl &nbsp; &nbsp; &nbsp; SP B5 &nbsp; &nbsp; active &nbsp;alive &nbsp; &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp;0
&nbsp; &nbsp;6 iSCSI Initiator over TCP/I sdm &nbsp; &nbsp; &nbsp; SP A5 &nbsp; &nbsp; active &nbsp;alive &nbsp; &nbsp; &nbsp; 0 &nbsp; &nbsp; &nbsp;0

Observem que neste caso existem dois canais porem somente o o sdl esta sendo utilizado , por sorte neste caso o SP(storage path) do device sdl &nbsp;é o B e B também é o SP atual da LUN mas poderia ocorrer do device estar no SP A e ai estar ignorando completamente o que esta definido na LUN.Isso é mau.
O correto nesse caso ,seria o ASMlib utilizar o device &nbsp; emcpowerd e esse sim gerenciaria qual pseudocanal utilizar ou o sdl ou sdm no caso de uma falha ou balanceamento.
Para este problema existe solução, durante a instalação do asm deve-se alterar dois parametros do arquivos de configuração oracleasm como mostrado abaixo:

[root@node2 ~]# cat /etc/sysconfig/oracleasm
#
# This is a configuration file for automatic loading of the Oracle
# Automatic Storage Management library kernel driver. &nbsp;It is generated
# By running /etc/init.d/oracleasm configure. &nbsp;Please use that method
# to modify this file
#

# ORACLEASM_ENABLED: 'true' means to load the driver on boot.
ORACLEASM_ENABLED=true

# ORACLEASM_UID: Default user owning the /dev/oracleasm mount point.
ORACLEASM_UID=grid

# ORACLEASM_GID: Default group owning the /dev/oracleasm mount point.
ORACLEASM_GID=asmadmin

# ORACLEASM_SCANBOOT: 'true' means scan for ASM disks on boot.
ORACLEASM_SCANBOOT=true

# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=""

# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=""

# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false



Devemos alterar os parametros ORACLEASM_SCANORDER e ORACLEASM_SCANEXCLUDE o primeiro informa para que o ASMlib procure por um tipo especifico de device no caso para cada fornecedor de sotrage existe um valor especifico , no nosso "Case" utilizamos a vnx da emc assim &nbsp;alteramos o valor para emcpower e no segundo parametro o ORACLEASM_SCANEXCLUDE informamos quais devices devem ser ignorados no caso sd dm, vamos com fica abaixo:

[root@node2 ~]# cat /etc/sysconfig/oracleasm
#
# This is a configuration file for automatic loading of the Oracle
# Automatic Storage Management library kernel driver. &nbsp;It is generated
# By running /etc/init.d/oracleasm configure. &nbsp;Please use that method
# to modify this file
#

# ORACLEASM_ENABLED: 'true' means to load the driver on boot.
ORACLEASM_ENABLED=true

# ORACLEASM_UID: Default user owning the /dev/oracleasm mount point.
ORACLEASM_UID=grid

# ORACLEASM_GID: Default group owning the /dev/oracleasm mount point.
ORACLEASM_GID=asmadmin

# ORACLEASM_SCANBOOT: 'true' means scan for ASM disks on boot.
ORACLEASM_SCANBOOT=true

# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="emcpower"

# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd dm"

# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false

É melhor realizar essa configuração na criação do ASM pois caso seja feita posteriormente sera necessário um reboot geral dos serviços de banco, não da para fazer a quente, vamos precisar parar o banco, o asm etc.. como visto abaixo:

[root@node2 ~]# oracleasm exit
umount: /dev/oracleasm: device is busy
failed
Unable to unmount ASMlib driver filesystem

Se seu ambiente for um Oracle RAC , pode-se realizar o procedimento em um nó de cada vez mitigando a indisponibilidade, desde que as aplicações consumidoras sejam inteligentes e permitam isso.

Primeiro eu paro o nó assim:

[root@node2 ~]#crsctl stop cluster -n node2

Isso vai parar o banco e a instancia e a maioria dos serviços.
Eu ainda paro o HAS do oracle

[root@node2 ~]#crsctl stop has

Com tudo parado vamos tentar parar o ASMlib novamente:

[root@node2 ~]# oracleasm exit
Unmounting ASMlib driver filesystem: /dev/oracleasm
Unloading module "oracleasm": oracleasm

Opa , agora foi, com o arquivo oraclesm editado vamos subir o ASMlib:

[root@node2 ~]# oracleasm init
Loading module "oracleasm": oracleasm
Mounting ASMlib driver filesystem: /dev/oracleasm

Ainda é necessário realizar um scan dos discos para valer a alteração:

[root@node2 ~]# oracleasm scandisks
Reloading disk partitions: done
Cleaning any stale ASM disks...
Scanning system for ASM disks...
Instantiating disk "DATA4"
Unable to instantiate disk "DATA4"
Instantiating disk "ARCH1"
Instantiating disk "OCR1"
Instantiating disk "ARCH3"
Instantiating disk "DATA1"
Instantiating disk "DATA2"
Instantiating disk "ARCH2"
Instantiating disk "OCR3"
Instantiating disk "OCR2"
Instantiating disk "DATA3"

podemos agora verificar o volume DATA2 novamente:

[root@node2 ~]# oracleasm querydisk -d DATA2
Disk "DATA2" is a valid ASM disk on device [120,49]

Já podemos perceber que o device mudou, vamos confirmar com o ll /dev :

[root@node2 ~]# ll -h /dev | grep 120, | grep 49
brw-r----- &nbsp;1 root disk &nbsp;120, &nbsp;49 Fev 10 13:21 emcpowerd1

Perfeito, agora esta utilizando o device emcpowerd1 como deve ser, utilizando em sua plenitude as opção de multipath da storage.

Maiores detalhes podem ser obtidos na nota do metalink Doc ID 1679409.1 seria bom ter encontrado essa nota antes de ter que brigar com o Linux e o Oracle rsrsrsrsrs.
Bom por hoje era isso, ate a próxima.
&nbsp;