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 reiniciá-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" normalObserve 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.
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.
Este artigo também está publicado em meu blog pessoal aqui.
