Exadata Software: arquitetura, discos e comunicação.

Oracle Exadata, uma das máquinas mais desejadas do universo Oracle,  appliance que fortaleceu a equipe de engineered systems da Oracle. Na minha opinião um divisor de águas. Para quem leu o meu artigo passado (aqui) acredito que tenha ficado claro que que não estamos falando só de hardware, mas sim de hardware e software que trabalham de forma integrada.

Se o hardware não é o mistério, o que faz o Oracle Exadata funcionar de verdade? O que é o Exadata Software, como funciona, qual a sua arquitetura, quais são seus processos, como seus discos são acessados, como se comunica com o banco?

Aqui, vou falar especificamente do Exadata Software, tentar responder estas perguntas e mais algumas.

ARQUITETURA

Como disse em meu artigo passado, o Oracle Exadata contêm Database Servers e Storage Servers. Os primeiros podem rodar tanto Solaris quanto Linux (acredito ser a maioria), já os Storage Servers rodam exclusivamente Linux (ambos sobre Oracle Unbreakable Linux). Bom, como já respondi o primeiro mistério para alguns vou passar direto para o software.

O Software Exadata roda em todos os Storage Servers de forma independente dos demais. Basicamente não existe um cluster de Storage Servers, cada um entrega os seus discos diretamente ao Grid instalado nos Database Servers. Não existe RAID ou qualquer abstração deste tipo configurada diretamente Exadata Software. Todo este controle é função do Grid dos Database Servers. Assim, o Exadata Software fica mais simples e dedicado a entregar os dados da maneira mais inteligente possível os dados ao banco de dados.

A arquitetura do Exadata Software é bem simples, ele é um conjunto de rpms que são instalados no Linux do Storage Server. Alguns destes são para firmware, ferramentas de diagnóstico e suporte e por fim o software em si.

Basicamente o Exadata Software é dividido em 3 processos:

  • Cell Server: é um processo conhecido como cellsrv. Responsável pelas principais funções do Exadata Software, fazer o offload dos SQL’s, disponibilizar os discos, gerenciamento de recursos, comunicação e afins.
  • Management Server: processo conhecido como MS, responsável pelo gerenciamento e configuração da célula. Expõe partes do hardware ao software Exadata. Por exemplo se a interface de gerenciamento remoto da placa mãe (a ILOM) trava, o MS reinicia ela.
  • Restart Server: conhecido como RS e sendo responsável por monitorar os outros processos. Na eventualidade de uma queda dos demais, ele é responsável por reinicia-los.

Um detalhe importante com a versão 12.1.x dos Exadata Software. Como esta versão suporta ambos os bancos 11GR2 e 12.1.x e como o kernel destas versões de banco diferem muito, o processo de offload existente no cellsrv foi dividido em dois. Assim, existe um “servidor interno” de offload no cellsrv (chamado de celloflsrv) específico para cada versão do banco de dados.

Você deve estar se perguntando como o Exadata Software e a célula são gerenciados já que dos processos acima nenhum aceita comandos ou apresenta qualquer interface de gerenciamento. Para isso, existe o aplicativo chamado cellcli (Cell Controle Command-Line Interface), sendo que o acesso a ele é através do console da célula (através de ssh ou até kvm dependendo da versão do seu Exadata).

De qualquer forma, a arquitetura básica do Oracle Exadata faz com que o Software Exadata seja responsável por realizar boa parte do trabalho sujo, fazer o offload da consulta, processá-la e retornar somente os blocos importantes. Como já falei aqui e em artigos anteriores, o Exadata Software opera de forma independente dos demais. Assim, cada Storage Server apresenta os processos acima e entrega seus discos diretamente ao Grid.

CELL

A célula (cell) é a unidade básica do Exadata Software, cada Storage Server é uma célula e representa o harware existente. É basicamente uma configuração que define os ip’s de comunicação e o monitoramento (como smtp).

Abaixo um exemplo de uma célula:

Primeiro temos o acesso através do cellcli e depois os detalhes da célula. Observe os ip’s de acesso e as informações de hardware (como fan e modelos de hardware). O valor apresentado em Cell Efficiency Offload (e offloadEfficiency) é a taxa que representa quanto de offload a célula está fazendo, quanto maior melhor.

De forma simples a definição de uma cell no Exadata é isso. A célula ainda apresenta um arquivo de configuração (cellinit.ora) parecido com um pfile. Contêm as informações básicas (como ip’s de afins) utilizado no boot (é nesse arquivo que podem ser definidos os parâmetros ocultos do Exadata, mas é outra história).

DISCOS

O grande diferencial do Software Exadata é a forma como os discos de cada Storage Server é disponibilizado. Como disse, não existe nenhum Raid configurado no Software, tudo isso é função do ASM do Grid presente nos Database Servers. De qualquer forma, existem algumas informações interessantes sobre os discos.

O Exadata Software considera como discos qualquer hardware que permita armazenamento persistente de dados, isso quer dizer que as placas flash que estão ligadas no barramento PCI também aparecem como discos.

O conceito de discos no Exadata Software apresenta alguns níveis, indo desde discos físicos até grid disks. O primeiro nível é chamado de physicaldisk e é o mapeamento direto com os discos físicos do Storage Server, eles não necessitam de gerenciamento (como formatação e afins) e podem ser visualizados através do cellcli:

Observe acima que os harddisks e flashdisks são apresentados como physicaldisks e contêm atributos como o slot de conexão (ou barramento PCI), tamanhos e status. Para cada physicaldisk existe uma lun (Logical Unit Number) como descrita abaixo.

Cada lun representa exclusivamente de forma lógica um physicaldisk, sendo a ligação entre o hardware o software (mesmo você não conseguindo gerenciar uma lun através do cellcli). Observe entre os dois exemplos acima que existe uma diferença de tamanho para um physicaldisk (do tipo Harddisk) e da lun. Isso ocorre, pois parte do espaço dos dois primeiros discos é utilizada pelo sistema operacional Linux do Storage Server e por isso todas as luns que são harddisk tem o mesmo tamanho (maior menor valor disponível).

Outro detalhe interessantes aqui, se você tentar visualizar (através do fdisk) um disco verá que não há formatação nem sistema de arquivos associado. O Exadata Software trabalha através de blocos com os discos, o que deixa muito mais rápido (evitar caches de sistema operacional por exemplo):

Para cada lun existe um único celldisk, e sobre estes que são criados os griddisk que vão ser disponibilizados ao ASM. Os celldisks são o primeiro nível que tem gerenciamento efetivo através do cellcli, podem ser removidos e criados. A manutenção de celldisks não é uma tarefa comum (nem necessária), em 4 anos trabalhando com Exadata nunca precisei fazer (por nenhum motivo). Abaixo um exemplo com celldisks:

Sobre cada um dos celldisks são criados os griddisk, e são estes que serão visíveis aos ASM. Griddisks diferentes podem compartilhar o mesmo celldisk e por isso podem ser gerenciados através do cellcli, no momento de criação podemos escolher o tamanho de cada um. Nas primeiras versões do Exadata Software eram criados somente dois grupos de griddisk, DATA e RECO, atualmente é criado também o DBFS.

Um detalhe importante para os griddisk, eles são criados conforme a sua necessidade e irão compor os seus diskgroups do ASM. Por padrão existem aqueles para dados (DATA) e utilizam a parte externa dos celldisks (por consequência a luns e physicaldisk), o de redo (RECO) utiliza a área central e o dbfs (DBFS) a área interna dos discos, mas você sabe porquê? Isso tudo é feito para aumentar a quantidade de IOPS por colocar os dados principais na área “quente” e ter menos movimentação das cabeças do disco, no meu artigo sobre o Exadata x4 (aqui) expliquei com mais detalhes isso.

Abaixo um exemplo da distribuição de girddisk em uma célula:

Notem acima a coluna offset que mostra a “ordem” de alocação entre eles. A imagem abaixo (que retirei da documentação/manual oficial do Exadata) mostra a relação entre os discos:

 

Sobre dos discos do Exadata é isso, nada muito complexo. Basicamente os discos e placas flash existentes em cada célula são disponibilizado ao ASM dos Database Servers. Uma formatação simples é aplicada sobre eles, onde são divididos entre dados, redo e dbfs.

Por fim, as placas flash podem disponibilizadas como discos (para virarem um diskgroup no ASM) ou como flashcache. O flashcache é utilizado como área de cache do Exadata Software, onde os dados requisitados com mais frequência ficam “cacheados” (e consistentes com os discos em caso de update) para acesso mais rápido.

COMUNICAÇÃO

Como você já deve ter notado, a comunicação entre os Database Servers e os Storage Servers representa um ponto importante no Oracle Exadata, sendo até um dos pontos explorados pelo marketing. Mas existem coisas a mais que devem ser explicadas.

A comunicação entre os Storage Server e Database Servers é realizada através do protocolo iDB (Inteligente Database Protocol). Este protocolo foi desenvolvido pela Oracle para comunicação do Oracle Exadata e está integrado diretamente no kernel do banco de dados.

Por conversar diretamente com o kernel o protocolo iDB permite ao Exadata Software algumas coisas como realizar o offload das consultas e permitir a marcação de consultas para o IORM, mas o principal mesmo é o offload de SQL. Sem o iDB a conversa entre o banco e storage é exclusivamente através és blocos, já com ele a conversa só se dá pelas linhas necessárias para responder o SQL.

Para que tudo isso fosse possível (e também ter desempenho) o protocolo iDB utiliza o RDS (Reliable Datagram Sockets v3) também desenvolvido pela Oracle e que permite a troca de pacotes com baixo overhead e latência. Além disso, o iDB utiliza o Infiniband ZDP (Zero-loss Zero-copy Datagram Protocol) sobre direct memory access (DMA) onde não existem múltiplas cópias do mesmo bloco trafegando pela rede nem em caches.

Resumindo, isso tudo quer dizer que quando um pacote/bloco sai do Storage Server ele é copiado diretamente para a memória do banco de dados sem passar pela CPU e pelo sistema operacional tanto do database server quanto do storage server. A interconexão do Oracle RAC no Exadata utiliza protocolo RDS com DMA.

Por isso, que Oracle Exadata é hardware e software trabalhando de forma integrada. Você acredita que qualquer protocolo de comunicação existente no mercado para o ambiente tradicional tem estas características? Algum protocolo comunica diretamente com a memória do banco de dados?

ORACLE EXADATA

Como visto acima, estamos falando de um appliance. Harware e Software trabalhando de forma integrada. Abaixo, uma imagem de como é a distribuição de um Oracle Exadata que mostra tudo o que expliquei acima (imagem extraída do manual oficial da Oracle). Só um detalhe nela, os Database Servers veem os discss de todos os Storage Servers ao mesmo tempo (e não de um único como na imagem):

PRÓXIMO ARTIGO

No próximo artigo falarei um pouco mais sobre como o banco de dados Oracle, o Grid e ASM veem o que o Exadata Software disponibiliza.

Fernando Simon, administrador de banco de dados para o Tribunal de Justiça de Santa Catarina e também consultor na mesma área no tempo livre. Mantenho um blog  com informações para o dia a dia de um DBA e DMA Exadata.

Experiência com bancos de dados desde 2004, Oracle (9i e posteriores), SQLServer e PortgreSQL (7, 8 e 9). Além de áreas relacionadas como storage, soluções de backup, virtualização e afins. Database Machine Administrator (DMA) Exadata desde 2010, usuário e administrador (configuração, atualização e manutenção) da solução Exadata desde a versão V2. Administrador de soluções MAA (DataGuard, Rac e afins), Gerenciamento de Recursos (Database Resource Manager e IO Resource Manager – IORM) para banco de dados Oracle e Oracle Exadata.