EXADATA e ASM
Depois de apresentar a forma como cada Storage Server disponibiliza seus discos para os Database Servers no artigo anterior (aqui) vou escrever um pouco sobre como eles são acessados pelo Grid. Não existem surpresas ou mistérios aqui, só alguns detalhes interessantes.
COMUNICAÇÃO
Como já disse em artigos anteriores, o mesmo binário do banco de dados Oracle e do Grid que está disponível no site da OTN é aquele utilizado no Oracle Exadata. Não existe diferença ou compilação específica para o Exadata. A única diferença (que existia até a 11.2.3.0) era, depois de instalado, fazer o link com a biblioteca RDS para comunicação Infiniband (mas você faria a mesma coisa se estivesse em um ambiente tradicional com Infiniband no interconnect).
Mas se não existe diferença, o que faz o binário Oracle entender que está em um Exadata? A resposta é simples, dois arquivos:
- cellinit.ora: Contêm uma única linha, o IP do Database Server.
- cellip.ora: Contêm a lista de todos os Storage Server disponíveis.
Todos estes arquivos ficam no diretório /etc/oracle/cell/network-config e os endereços fazem referência aos IP’s da rede Infiniband.
Com estes dois arquivos o Grid e o Oracle Database sabem que devem procurar por um caminho específico para localizar os discos. Claro que o kernel do Oracle Database já deve estar preparado para identificar e habilitar as funcionalidades do Exadata, mas não existe mistério ou arquivos “malucos” de configuração.
ASM DISKS
Caso você já tenha utilizado ASMLIB deve saber que os discos aparecem com a inicial ORCL. No Oracle Exadata não temos ASMLIB mas os discos são identificados de forma particular, aparecem como “o/<ip’s stoage server>/<grid disk>”.
Um exemplo: “o/192.168.10.17;192.168.10.18/DATA_CD_00_spmlx_ecgx4_01”. Isso nos diz que o griddisk “DATA_CD_00_spmlx_ecgx4_01” é de uma célula Exadata (“o/”) acessível através dos ip’s “192.168.10.17;192.168.10.18”. Todos os discos do appliance aparecem para o ASM, você verá 168 griddisks para DATA e RECO e 140 para DBFS.
O único detalhe aqui é em relação a redundância dos dados, no Oracle Exadata não temos RAID no storage e isso traz a segurança e responsabilidade para o ASM. O espelhamento e redundância do ASM são utilizados aqui para garantir que nada seja perdido. Falando nisso, o failure group desempenha papel fundamental.
Com failure group o ASM garante que cópias adicionais do bloco estarão disponíveis caso a original fique indisponível. Como no Oracle Exadata cada Storage Server é um nó independente o cuidado é maior, pois é necessário garantir que nada seja perdido caso uma célula falhe. Para garantir isso um failure group é criado em cada célula com todos os seus discos, os 12 discos de uma célula compõe um único failure group.
Mas por que e como isso funciona? De forma simples, isso faz que cada célula seja um failure group e o ASM garante que os blocos do diskgroup que contidos nos discos de uma célula terão suas cópias armazenadas em um failure group de outra célula. Se você escolher normal redundancy você poderá sobreviver a falha de uma célula, caso escolha high redundancy poderá sobreviver a até falhas de duas células ao mesmo tempo sem perda de dados. De qualquer forma, essa é uma preocupação que você não tem, tudo isso é gerenciado automaticamente pelo ASM. A única preocupação é escolher a redundância dos diskgroups.
Além desse detalhe com os failure groups faço uma comparação entre o ambiente tradicional e o Oracle Exadata. Em um ambiente tradicional toda a redundância e preocupação com a performance fica “mascarada” pelo Storage, ao ASM basicamente são disponibilizadas lun’s sobre raid groups. A preocupação se o disco está com menor latência e o balanceamento de carga fica todo para o Storage. Já no Oracle Exadata o ASM tem (em um Full Rack) 168 discos para fazer o balanceamento, são 168 discos para o ASM escolher onde armazenar e ler os dados de forma mais rápida possível. No final das contas a granularidade é muito maior e o ajuste de performance muito mais fino no Oracle Exadata.
PRÓXIMO ARTIGO
No próximo artigo voltarei a falar sobre gerenciamento de recursos, como podemos distribuir e gerenciar tudo o que está disponível.
Este artigo também está disponível no meu blog pessoal (aqui).
