exadatalogo

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:

[root@spmlx-ecgx4-01 ~]# cellcli
CellCLI: Release 11.2.3.3.0 - Production on Sun Nov 09 22:25:46 BRST 2014

Copyright (c) 2007, 2013, Oracle. All rights reserved.
Cell Efficiency Ratio: 58,776

CellCLI> LIST CELL;
 spmlx_ecgx4_01 online

CellCLI> LIST CELL DETAIL;
         name: spmlx_ecgx4_01
         bbuChargeThreshold: 800
         bbuStatus: normal
         bbuTempThreshold: 60
         bmcType: IPMI
         cellVersion: OSS_11.2.3.3.0_LINUX.X64_140826
         cpuCount: 24
         diagHistoryDays: 7
         fanCount: 8/8
         fanStatus: normal
         flashCacheMode: WriteThrough
         id: 1414NM50VE
         interconnectCount: 3
         interconnect1: ib0
         interconnect2: ib1
         iormBoost: 0.0
         ipaddress1: 192.168.10.17/22
         ipaddress2: 192.168.10.18/22
         kernelVersion: 2.6.39-400.126.1.el5uek
         locatorLEDStatus: off
         makeModel: Oracle Corporation SUN SERVER X4-2L High Performance
         metricHistoryDays: 7
         notificationMethod: mail,snmp
         notificationPolicy: critical,warning,clear
         offloadEfficiency: 58,776.5
         powerCount: 2/2
         powerStatus: normal
         releaseVersion: 11.2.3.3.0
         releaseTrackingBug: 16278923,17596641
         smtpFrom: SalaCofre-ExadataX4-01
         smtpFromAddr: XXXXXXXXXXXX
         smtpPort: 25
         smtpServer: XXXXXXXXXXXX
         smtpToAddr: XXXXXXXXXXXX
         smtpUseSSL: FALSE
         snmpSubscriber: host=spmlx-edgx4-01,port=3872,community=public
         status: online
         temperatureReading: 20.0
         temperatureStatus: normal
         upTime: 116 days, 10:01
         cellsrvStatus: running
         msStatus: running
         rsStatus: running
CellCLI>

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:

CellCLI> list physicaldisk attributes name, disktype, physicalsize, slotnumber, status

19:0            HardDisk        1117.8140487670898G     0                       normal
19:1            HardDisk        1117.8140487670898G     1                       normal
19:2            HardDisk        1117.8140487670898G     2                       normal
19:3            HardDisk        1117.8140487670898G     3                       normal
19:4            HardDisk        1117.8140487670898G     4                       normal
19:5            HardDisk        1117.8140487670898G     5                       normal
19:6            HardDisk        1117.8140487670898G     6                       normal
19:7            HardDisk        1117.8140487670898G     7                       normal
19:8            HardDisk        1117.8140487670898G     8                       normal
19:9            HardDisk        1117.8140487670898G     9                       normal
19:10           HardDisk        1117.8140487670898G     10                      normal
19:11           HardDisk        1117.8140487670898G     11                      normal
FLASH_1_0       FlashDisk       186.26451539993286G     "PCI Slot: 1; FDOM: 0"  normal
FLASH_1_1       FlashDisk       186.26451539993286G     "PCI Slot: 1; FDOM: 1"  normal
FLASH_1_2       FlashDisk       186.26451539993286G     "PCI Slot: 1; FDOM: 2"  normal
FLASH_1_3       FlashDisk       186.26451539993286G     "PCI Slot: 1; FDOM: 3"  normal
FLASH_2_0       FlashDisk       186.26451539993286G     "PCI Slot: 2; FDOM: 0"  normal
FLASH_2_1       FlashDisk       186.26451539993286G     "PCI Slot: 2; FDOM: 1"  normal
FLASH_2_2       FlashDisk       186.26451539993286G     "PCI Slot: 2; FDOM: 2"  normal
FLASH_2_3       FlashDisk       186.26451539993286G     "PCI Slot: 2; FDOM: 3"  normal
FLASH_4_0       FlashDisk       186.26451539993286G     "PCI Slot: 4; FDOM: 0"  normal
FLASH_4_1       FlashDisk       186.26451539993286G     "PCI Slot: 4; FDOM: 1"  normal
FLASH_4_2       FlashDisk       186.26451539993286G     "PCI Slot: 4; FDOM: 2"  normal
FLASH_4_3       FlashDisk       186.26451539993286G     "PCI Slot: 4; FDOM: 3"  normal
FLASH_5_0       FlashDisk       186.26451539993286G     "PCI Slot: 5; FDOM: 0"  normal
FLASH_5_1       FlashDisk       186.26451539993286G     "PCI Slot: 5; FDOM: 1"  normal
FLASH_5_2       FlashDisk       186.26451539993286G     "PCI Slot: 5; FDOM: 2"  normal
FLASH_5_3       FlashDisk       186.26451539993286G     "PCI Slot: 5; FDOM: 3"  normal

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.

CellCLI> list lun attributes name, deviceName, diskType, lunSize, status
0_0     /dev/sda        HardDisk        1116.6552734375G        normal
0_1     /dev/sdb        HardDisk        1116.6552734375G        normal
0_2     /dev/sdc        HardDisk        1116.6552734375G        normal
0_3     /dev/sdd        HardDisk        1116.6552734375G        normal
0_4     /dev/sde        HardDisk        1116.6552734375G        normal
0_5     /dev/sdf        HardDisk        1116.6552734375G        normal
0_6     /dev/sdg        HardDisk        1116.6552734375G        normal
0_7     /dev/sdh        HardDisk        1116.6552734375G        normal
0_8     /dev/sdi        HardDisk        1116.6552734375G        normal
0_9     /dev/sdj        HardDisk        1116.6552734375G        normal
0_10    /dev/sdk        HardDisk        1116.6552734375G        normal
0_11    /dev/sdl        HardDisk        1116.6552734375G        normal
1_0     /dev/sdv        FlashDisk       186.26451539993286G     normal
1_1     /dev/sdw        FlashDisk       186.26451539993286G     normal
1_2     /dev/sdx        FlashDisk       186.26451539993286G     normal
1_3     /dev/sdy        FlashDisk       186.26451539993286G     normal
2_0     /dev/sdz        FlashDisk       186.26451539993286G     normal
2_1     /dev/sdaa       FlashDisk       186.26451539993286G     normal
2_2     /dev/sdab       FlashDisk       186.26451539993286G     normal
2_3     /dev/sdac       FlashDisk       186.26451539993286G     normal
4_0     /dev/sdr        FlashDisk       186.26451539993286G     normal
4_1     /dev/sds        FlashDisk       186.26451539993286G     normal
4_2     /dev/sdt        FlashDisk       186.26451539993286G     normal
4_3     /dev/sdu        FlashDisk       186.26451539993286G     normal
5_0     /dev/sdn        FlashDisk       186.26451539993286G     normal
5_1     /dev/sdo        FlashDisk       186.26451539993286G     normal
5_2     /dev/sdp        FlashDisk       186.26451539993286G     normal
5_3     /dev/sdq        FlashDisk       186.26451539993286G     normal
CellCLI>

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):

[root@spmlx-ecgx4-01 ~]# fdisk -l /dev/sdf
WARNING: GPT (GUID Partition Table) detected on '/dev/sdf'! The util fdisk doesn't support GPT. Use GNU Parted.
Disk /dev/sdf: 1198.9 GB, 1198999470080 bytes
255 heads, 63 sectors/track, 145770 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdf doesn't contain a valid partition table
[root@spmlx-ecgx4-01 ~]#

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:

CellCLI> list celldisk attributes name, devicename, disktype, size, status
CD_00_spmlx_ecgx4_01    /dev/sda        HardDisk        1082.84375G     normal
CD_01_spmlx_ecgx4_01    /dev/sdb        HardDisk        1082.84375G     normal
CD_02_spmlx_ecgx4_01    /dev/sdc        HardDisk        1116.640625G    normal
CD_03_spmlx_ecgx4_01    /dev/sdd        HardDisk        1116.640625G    normal
CD_04_spmlx_ecgx4_01    /dev/sde        HardDisk        1116.640625G    normal
CD_05_spmlx_ecgx4_01    /dev/sdf        HardDisk        1116.640625G    normal
CD_06_spmlx_ecgx4_01    /dev/sdg        HardDisk        1116.640625G    normal
CD_07_spmlx_ecgx4_01    /dev/sdh        HardDisk        1116.640625G    normal
CD_08_spmlx_ecgx4_01    /dev/sdi        HardDisk        1116.640625G    normal
CD_09_spmlx_ecgx4_01    /dev/sdj        HardDisk        1116.640625G    normal
CD_10_spmlx_ecgx4_01    /dev/sdk        HardDisk        1116.640625G    normal
CD_11_spmlx_ecgx4_01    /dev/sdl        HardDisk        1116.640625G    normal
FD_00_spmlx_ecgx4_01    /dev/sdv        FlashDisk       186.25G         normal
FD_01_spmlx_ecgx4_01    /dev/sdw        FlashDisk       186.25G         normal
FD_02_spmlx_ecgx4_01    /dev/sdx        FlashDisk       186.25G         normal
FD_03_spmlx_ecgx4_01    /dev/sdy        FlashDisk       186.25G         normal
FD_04_spmlx_ecgx4_01    /dev/sdz        FlashDisk       186.25G         normal
FD_05_spmlx_ecgx4_01    /dev/sdaa       FlashDisk       186.25G         normal
FD_06_spmlx_ecgx4_01    /dev/sdab       FlashDisk       186.25G         normal
FD_07_spmlx_ecgx4_01    /dev/sdac       FlashDisk       186.25G         normal
FD_08_spmlx_ecgx4_01    /dev/sdr        FlashDisk       186.25G         normal
FD_09_spmlx_ecgx4_01    /dev/sds        FlashDisk       186.25G         normal
FD_10_spmlx_ecgx4_01    /dev/sdt        FlashDisk       186.25G         normal
FD_11_spmlx_ecgx4_01    /dev/sdu        FlashDisk       186.25G         normal
FD_12_spmlx_ecgx4_01    /dev/sdn        FlashDisk       186.25G         normal
FD_13_spmlx_ecgx4_01    /dev/sdo        FlashDisk       186.25G         normal
FD_14_spmlx_ecgx4_01    /dev/sdp        FlashDisk       186.25G         normal
FD_15_spmlx_ecgx4_01    /dev/sdq        FlashDisk       186.25G         normal
CellCLI>

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:

CellCLI> list griddisk attributes name, celldisk, disktype, status, size, offset
DATA_CD_00_spmlx_ecgx4_01       CD_00_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_01_spmlx_ecgx4_01       CD_01_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_02_spmlx_ecgx4_01       CD_02_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_03_spmlx_ecgx4_01       CD_03_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_04_spmlx_ecgx4_01       CD_04_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_05_spmlx_ecgx4_01       CD_05_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_06_spmlx_ecgx4_01       CD_06_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_07_spmlx_ecgx4_01       CD_07_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_08_spmlx_ecgx4_01       CD_08_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_09_spmlx_ecgx4_01       CD_09_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_10_spmlx_ecgx4_01       CD_10_spmlx_ecgx4_01    HardDisk        active  920G            32M
DATA_CD_11_spmlx_ecgx4_01       CD_11_spmlx_ecgx4_01    HardDisk        active  920G            32M
DBFS_DG_CD_02_spmlx_ecgx4_01    CD_02_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_03_spmlx_ecgx4_01    CD_03_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_04_spmlx_ecgx4_01    CD_04_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_05_spmlx_ecgx4_01    CD_05_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_06_spmlx_ecgx4_01    CD_06_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_07_spmlx_ecgx4_01    CD_07_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_08_spmlx_ecgx4_01    CD_08_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_09_spmlx_ecgx4_01    CD_09_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_10_spmlx_ecgx4_01    CD_10_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
DBFS_DG_CD_11_spmlx_ecgx4_01    CD_11_spmlx_ecgx4_01    HardDisk        active  33.796875G      1082.84375G
RECO_CD_00_spmlx_ecgx4_01       CD_00_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_01_spmlx_ecgx4_01       CD_01_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_02_spmlx_ecgx4_01       CD_02_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_03_spmlx_ecgx4_01       CD_03_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_04_spmlx_ecgx4_01       CD_04_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_05_spmlx_ecgx4_01       CD_05_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_06_spmlx_ecgx4_01       CD_06_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_07_spmlx_ecgx4_01       CD_07_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_08_spmlx_ecgx4_01       CD_08_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_09_spmlx_ecgx4_01       CD_09_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_10_spmlx_ecgx4_01       CD_10_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
RECO_CD_11_spmlx_ecgx4_01       CD_11_spmlx_ecgx4_01    HardDisk        active  162.796875G     920.046875G
CellCLI>

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:

relacao_entre_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):

Distribuicao_Oracle_Exadata

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.