Configurando o array de SSDs para o Oracle Database, recomendações?

5

Estou configurando um servidor para um banco de dados pequeno, mas com leitura intensiva de E / S. Ele serve como um índice mestre para acesso público a um banco de dados maior do Oracle RAC. Ao observar os requisitos de E / S, determinou-se que uma matriz de SSDs forneceria o desempenho necessário com custo menor do que um grande número de eixos SAS de 15K. Eu tenho um servidor HP, com um Smart Array P400 que será conectado apenas aos SSDs. O controlador tem 256MB de BBWC. Os SSDs são o Samsung (acredito) fabricado com base em SLC de 60GB e 2,5 "SATA.

Eu estou querendo saber se alguém tem uma visão sobre os melhores tamanhos de faixa para o RAID 10 ou 5, recomendações do sistema de arquivos? Nós vamos estar fazendo o Oracle 11g, então eu acredito que eu sou obrigado a ter um sistema de arquivos, em vez de usar o dispositivo de bloqueio RAW. O servidor estará executando o RHEL 5.5.

Eu fiz uma tonelada de leitura nos últimos meses sobre SSDs, e não me oponho a fazer muito mais, mas meu google-fu começou a falhar em seguir em frente. A maioria dos documentos que eu estou encontrando no SSD RAID são para pessoas que fazem um RAID 0 de SSDs no nível do consumidor para a unidade de inicialização em seu PC doméstico para fazer o Windows 7 inicializar e carregar jogos mais rapidamente. O que eu estou dizendo é que eu não estou procurando alguém para fazer o meu trabalho, apenas fornecer qualquer experiência que eles tiveram ou um link para um doc que encontraram algunshwere.

Obrigado antecipadamente!

EDITE para mais informações em vez de responder a todos os comentários individuais:

O espaço da unidade não é uma preocupação, pois o banco de dados é pequeno o suficiente para caber em um dos SSDs sem nenhum problema.

Sendo um banco de dados pesado muito lido (95% + leitura aleatória em 4-8k), eu pensei que poderia obter melhor desempenho do RAID 5 só porque eu posso ler a partir de unidades N-1 na matriz, em vez de somente discos no espelho, como eu li coisas que indicam que o Smart Array P400 não suporta a leitura de ambos os lados do espelho em um conjunto RAID 10. Dito isso, estou bastante certo de que o controlador acabará sendo um gargalo antes que eu tenha que me preocupar com isso.

No TRIM: Estou bastante certo de que, mesmo que essas unidades suportem TRIM (não acredito que sim), seria um pouco difícil conseguir que os comandos TRIM passassem pelo controlador RAID para as unidades individuais. O suporte do SO também é arriscado, pois o Red Hat Enterprise Linux 5 ainda é baseado na árvore de Kernel 2.6.18, embora com muita customização para trazer recursos de versões posteriores do kernel. EXT4 também não é oficialmente suportado, e sendo uma caixa de Produção, eu preciso me manter no reino onde a Red Hat e a HP irão me ajudar se algo der errado. Eu acredito que há algum tipo de coleta de lixo acontecendo no nível da unidade, no entanto. Eu preenchi os discos várias vezes durante o benchmarking diferente, e não vi uma redução acentuada na velocidade de gravação que eu esperaria se eu tivesse que esperar pelo ciclo Erase / Program, em vez de apenas o ciclo do programa.

Aqui estão alguns dados de benchmark para um array RAID 10 de 6 drives, usando o tamanho Stripe de 256KB. A partição é EXT3, alinhada em 64 setores. O agendador NOOP é usado, e a opção NOATIME é dada na montagem. Também aumentei o cache de leitura do sistema operacional para 8MB (acredito que o padrão seja 512K). Eu usei Iozone 3.347 para este teste, com um tamanho recorde de 4KB, e um tamanho de arquivo de benchmark de 25GB para tirar o cache da imagem e medir o desempenho real das unidades. Eu também corri isto com quatro threads (arquivos de 4x25GB são escritos por 4 processos filhos para enfatizar a unidade).

A corrida começou: seg 30 de agosto 12:09:57 2010

    Record Size 4 KB
    File size set to 26214400 KB
    Command line used: /opt/iozone/bin/iozone -b /root/4k25g4t.xls -r 4k -s 25g -t 4 -i 0 -i 1 -i 2
    Output is in Kbytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
    Throughput test with 4 processes
    Each process writes a 26214400 Kbyte file in 4 Kbyte records

    Children see throughput for  4 initial writers  =  253416.93 KB/sec
    Parent sees throughput for  4 initial writers   =  229461.66 KB/sec
    Min throughput per process                      =   61416.07 KB/sec
    Max throughput per process                      =   64604.90 KB/sec
    Avg throughput per process                      =   63354.23 KB/sec
    Min xfer                                        = 24924492.00 KB

    Children see throughput for  4 rewriters        =  259375.90 KB/sec
    Parent sees throughput for  4 rewriters         =  234136.11 KB/sec
    Min throughput per process                      =   63879.16 KB/sec
    Max throughput per process                      =   65675.30 KB/sec
    Avg throughput per process                      =   64843.97 KB/sec
    Min xfer                                        = 25497648.00 KB

    Children see throughput for  4 readers          =  490873.09 KB/sec
    Parent sees throughput for  4 readers           =  490830.09 KB/sec
    Min throughput per process                      =  119007.65 KB/sec
    Max throughput per process                      =  124878.35 KB/sec
    Avg throughput per process                      =  122718.27 KB/sec
    Min xfer                                        = 24984912.00 KB

    Children see throughput for 4 re-readers        =  477533.65 KB/sec
    Parent sees throughput for 4 re-readers         =  477503.03 KB/sec
    Min throughput per process                      =  115802.55 KB/sec
    Max throughput per process                      =  121579.46 KB/sec
    Avg throughput per process                      =  119383.41 KB/sec
    Min xfer                                        = 24973364.00 KB

    Children see throughput for 4 random readers    =   35728.62 KB/sec
    Parent sees throughput for 4 random readers     =   35728.53 KB/sec
    Min throughput per process                      =    8926.97 KB/sec
    Max throughput per process                      =    8937.35 KB/sec
    Avg throughput per process                      =    8932.16 KB/sec
    Min xfer                                        = 26183936.00 KB

    Children see throughput for 4 random writers    =   23527.42 KB/sec
    Parent sees throughput for 4 random writers     =   20701.37 KB/sec
    Min throughput per process                      =    5757.43 KB/sec
    Max throughput per process                      =    6035.68 KB/sec
    Avg throughput per process                      =    5881.86 KB/sec
    Min xfer                                        = 25011236.00 KB



"Throughput report Y-axis is type of test X-axis is number of processes"
"Record size = 4 Kbytes "
"Output is in Kbytes/sec"

"  Initial write "  253416.93

"        Rewrite "  259375.90

"           Read "  490873.09

"        Re-read "  477533.65

"    Random read "   35728.62

"   Random write "   23527.42
    
por John 31.08.2010 / 16:28

5 respostas

2

Alguns pontos que não vi em outras respostas até agora:

  • Um SSD de servidor de ponta funciona cerca de 30.000 IO. RealSSD vai até 50.000
  • Como tal, você pode usar o RAID 5. Point. O seu gargalo provavelmente será o controlador RAID, que simplesmente não é feito com SSD IOPS em mente, então ele irá maximizar sua CPU.

Em geral, os SSDs são cerca de 100 vezes mais rápidos que os drives SAS em E / S aleatório. Um pouco mais. Dependendo de suas necessidades, é totalmente viável substituir um RAID 10 do SAS por um RAID 5 do SSD e ainda assim progredir - de maneira significativa - tanto em IOPS quanto em preço.

O tamanho ideal da faixa é um múltiplo típico de 64k - especialmente como leitura / gravação SSD nesses segmentos. TRIM não é necessariamente necessário então (sem gravações parciais) ... mas seria muito bom ter isso.

O MS tem alguns papares no SSD em bancos de dados que também se aplicam ao oracle (mesmo princípio - otimização de IOPS). O Oracle também deve ter alguns.

    
por 31.08.2010 / 17:34
1

O RAID-10 seria ideal.

Considerando que o custo do típico SSD Intel 64GB SLC é de cerca de 700 $, e que você precisaria de 4 para criar RAID-10, enquanto 64GB de RAM ECC Registrada DDR3 custam cerca de 1600 $ (a menos que você esteja comprando) da Dell) pode ter sido um investimento mais inteligente para obter a RAM, que é mais rápida e vai durar muito mais do que qualquer SSD.

A idéia seria hospedar todo o banco de dados na RAM, supondo que o tamanho do banco de dados e seus índices não excedam 64 GB.

    
por 31.08.2010 / 17:22
0

Ir RAID10, a menos que você precise do espaço em disco que o RAID5 pode fornecer. Você obterá melhor desempenho na maioria dos casos do RAID10.

Como o Amala disse, certifique-se de que as unidades e o SO suportem o TRIM. Use um tamanho de tira que seja consistente com o tamanho de bloco do sistema operacional (64k é bastante comum para servidores de banco de dados) e certifique-se de que a partição esteja deslocada em um múltiplo (o deslocamento de 1MB é bastante comum).

    
por 31.08.2010 / 17:12
0

Este link tem um bom resumo e recomendação para o Raid 10: link

A invasão 5 geralmente não é recomendada. Tem características estranhas para aplicativos de gravação. Eu iria para o Raid 10. Eu não sei sobre o tamanho das faixas, não tenho certeza se importaria muito.

Certifique-se de que sua distribuição Linux suporta o TRIM para SSDs. Parece que você precisa do kernel: Linux 2.6.33 e Ext4.

    
por 31.08.2010 / 17:05
0

Eu não vejo o problema, pois mesmo com o R5 / R6 você está ficando insano em mais de 15k SAS. Estava pensando em fazer um array R6 22 SSD +2 para hot spare.

    
por 14.09.2010 / 16:38