Introdução
Em novembro de 2024 a Oracle liberou a nova versão do ASMlib, denominada ASMlib v3, com intuito de substituir a versão v2 usada amplamente já alguns anos. Neste post eu resumo as principais novidades que eu pude observar ao ler a documentação, assim como alguns testes que realizei no Oracle Linux 8.10 e 9.5.
Suporte a Oracle Linux 8 e 9 (Com UEK7)
Um dos principais motivadores para adotar a nova versão é o suporte para os kernels mais recentes, incluindo versões como RHCK 5.14.* e UEK7 5.15*, isso significa que agora o ASMlib pode ser usado no Oracle Linux 8 e Oracle Linux 9 sem precisar fazer downgrade do kernel para UEK6.
No ASMlib v2 só era possível instalá-lo em servidores até o Linux 8, e para isso ainda era necessário que o kernel utilizado fosse UEK6. Caso precisacemos instalar o ASM em um Linux com UEK7, isso demandaria o uso de UDEV rules. O AFD também poderia ser usado, mas não tinha suporte para UEK7 antes do GIRU 19.23.
De acordo a documentação, se você está fazendo uma instalação em Oracle Linux 7 ou inferior, o ASMlib v2 continua sendo o recomendado. Se estiver usando Oracle Linux 8 ou superior, use o ASMlib v3.
Nova Interface de I/O
Além das interfaces de IO que já eram suportadas pelo ASMlib v2, a versão 3.0 adiciona suporte ao IO_URING, e tentará usar essa opção sempre que possível. IO_URING é um recurso relativamente novo do Linux, que oferece uma nova interface para aplicações realizarem operações de IO de uma forma mais performática e eficiente.
O tema IO_URING por se só é algo relativamente complexo e requer uma leitura mais extensa para entender o seu funcionamento, mas eu vou tentar resumir aqui o básico para ajudar você a entender os benefícios que essa nova interface pode trazer em termos de performance para o ASM.
A forma tradicional
A forma tradicional de fazer IO no Linux envolve uma separação de contextos entre “User space” e “Kernel space”, onde a aplicação rodando no contexto do User space (ASM neste caso), precisa fazer uma chamada para o Kernel realizar a operação de IO (System call). Cada requisição resulta em uma “syscall”, o que por si só consome uma porção de CPU para realizar a operação.
Neste cenário de separação entre User space e kernel space, cada contexto tem o seu próprio Buffer na memória, gerando um pequeno overhead nas requisições de IO, uma vez que os dados precisam ser copiados de um Buffer para o outro durante as operações de leitura e escrita. Com Direct IO não vai ter esse Buffer, mas ainda ocorre muita troca de contexto com a quantidade de System Call executada para cada IO.
A nova forma usando IO_URING
Por outro lado, o IO_URING cria uma área na memória que é compartilhada entre a aplicação e o Kernel. Nessa arquitetura, tanto a aplicação quanto o Kernel podem ler e escrever os dados diretamente nesse Buffer compartilhado entre eles, eliminando a necessidade de copiar os dados de um Buffer para o outro.
A ilustração abaixo foi criada por Donald Hunter e compartilhada no artigo Why you should use io_uring for network I/O:
Essa abordagem permite que a aplicação coloque um grande número de requisições de IO diretamente em uma fila chamada “Submission Queue“, e em seguida realizar uma única chamada (System call) para o Kernel processar todas as requisições de uma vez. Quando processadas, o Kernel coloca o resultado em outra fila chamada de “Completion Queue“, da qual a aplicação pode ler os resultados diretamente da memória.
Essa abordagem reduz signitivamente o overhead causado por trocas de contexto entre User Space e Kernel Space, o que tem termos práticos otimiza o uso de System CPU. Além disso, permite usar Async IO com Buffer, o que nas outras interfaces normalmente só é possível usando Direct IO (sem Buffer).
Isso foi um breve resumo superficial, se você quiser saber mais com conteúdo escrito por quem realmente entende do assunto, eu recomendo esses links como ponto de partida:
RedHat Blog: Why you should use io_uring for network I/O
Oracle Blog: An Introduction to the io_uring Asynchronous I/O Framework
I/O Filter (New Feature!)
O ASMlib v3 implementa um recurso chamado I/O Filter, que funcionalmente já é conhecido para quem usa ASM Filter Driver (ASMFD). Com essa opção habilitada, o driver do ASMlib passa a rejeitar qualquer requisição de IO em um disco do ASM que não seja emitida pelo próprio ASM.
Se você tentar criar um filesystem, modificar partições ou sobreescrever o conteúdo do disco manualmente, como usando o comando “dd”, essa requisição será filtrada e rejeitada pelo ASMlib. O principal benefício de ter essa funcionalidade é mitigar corrupções causadas por erros operacionais, como um DBA ou SysAdmin manipulando um disco equivocadamente por comandos do Sistema Operacional.
Eu ainda não vi um caso de impacto negativo na performance causada por essa funcionalidade dentro do ASMFD, mas se você tiver algum receio ou restrição quanto a essa nova feature dentro do ASMlib, pode desabilta-la com o comando abaixo:
oracleasm configure --iofilter nDriver kmod-oracleasm
Com ASMlib v3, se o Kernel estiver em uma das versões que suporta IO_URING, o ASMlib usará essa Interface de IO automaticamente, o que por sua vez não necessita do driver kmod-oracleasm. O ASMlib usará IO_URING quando o SO for Oracle Linux 8, Oracle Linux 9 ou RedHat 9 (aqui quando menciono RedHat, também considero o Oracle Linux com RHCK).
Até o ASMlib v2, era necessário um driver adicional instalado no Kernel (kmod-oracleasm). Se o sistema operacional utilizado fosse o Oracle Linux com UEK, esse driver já vem incluso no Kernel, necessitando apenas da instalação dos dois pacotes do ASMlib (oracleasmlib e oracleasm-support). Se o SO fosse o RedHat ou Oracle Linux com RHCK (RedHat Compatible Kernel), era necessário instalar um terceiro pacote chamado “kmod-oracleasm“.
Fim do Caminho “/dev/oracleasm/disks”
Nessa nova versão do ASMlib não temos mais o caminho “/dev/oracleasm/disks” listando todos os LABEL de discos criados com o comando “oracleasm createdisk“. Esse era um caminho comum usado como PATH para o parâmetro “asm_diskstring” ou na interface do ASMCA.
Agora ao invés de usar o caminho “/dev/oracleasm/disks“, precisamos usar o padrão do SO que lista todos os discos com LABEL que é “/dev/disk/by-label“. Alternativamente, você continua podendo usar a opção com prefixo ‘ORCL:*’.
Download
As páginas abaixo contém os links para download e também da documentação oficial do ASMlib v3. Uma observação é que o link para download irá redirecionar para o Oracle eDelivery ao invés de baixar o pacote diretamente.
Oracle ASMLib Downloads for Oracle Linux 9
Oracle ASMLib Downloads for Oracle Linux 8
Instalação
Para o pacote oracleasm-support, habilite o repositório com sufixo “addons” (ol8_addons ou ol9_addons) e faça a instalação diretamente usando o repositório público:
sudo dnf config-manager --set-enabled ol9_addons
sudo dnf install oracleasm-supportPara o pacote oracleasmlib, instale o rpm baixado do eDelivery:
sudo dnf localinstall /tmp/oracleasmlib-3.0.0-13.el9.x86_64.rpmConclusão
Este post apresentou as principais mudanças no ASMlib v3 (3.0), e o que você pode esperar para a sua próxima instalação ou upgrade do ASM. Como podemos ver, essa nova versão não trata apenas de suportar novas versões do Linux, mas também embarca algumas melhorias relevantes que visam a melhroar a performance e estabilidade do ambiente.
Referências:
Installing and Configuring Oracle ASMLIB v3
ACFS and AFD Support On OS Platforms (Certification Matrix). (Doc ID 1369107.1)
Oracle ASMLib Software Update and Support Policy (Doc ID 1089399.1)
Pingback: Instalação do ASMlib v3 no RedHat 9.5 – Blog do Dibiei