Turbine seu Banco de Dados Utilizando Enterprise Flash ... · Movendo Partes do Banco de Dados para...

1© Copyright 2009 EMC Corporation. All rights reserved.

Turbine seu Banco de Dados Utilizando Enterprise Flash Drives no CLARiiON

Gustavo [email protected]


Agenda

� Breve Introdução ao EFD (Enterprise Flash Drive)

� Performance do EFD

� Configuração dos EFDs no CLARiiON

� Resultados de Testes com Oracle

� Como Identificar Bancos de Dados Oracle Candidatos ao Uso de EFD ?

� Resultados de Testes com SQL Server

� Como Identificar Bancos de Dados SQL Server Candidatos ao Uso deEFD ?


Hardware

Flash SLC NANDBarramentos Internos Paralelos

Interface Fibre ChannelDual-ported

Cache DDR SDRAM com Backup de Energia

� Módulo de disco padrão CLARiiON

� Dentro do módulo – sistema compacto de CPU/memória


Arquitetura

� Tecnologia de Armazenamento Multi-Nível, Baseado em Microcontrolador– O controlador gerencia as requisições, o fluxo de dados e assinala a localização dos LBA– O cache SDRAM funciona como um buffer para os dados de escrita e para a tabela de

mapeamento de endereços– O array de chips de memória flash armazena os dados e serve às requisições em paralelo

� Funciona como um pequeno array com um RAID Group de 16 “drives”

Dual port interface

Data Path

Flash device

…

Firmware

System memory

Cache memory

Flash device

Flash device

Flash device

Parallel path to each device

(16)

Fiber Channel

Ports

CPU


Confiabilidade do Enterprise Flash Drive

� Confiabilidade do Dispositivo– Interface Fibre Channel Dual-ported– Proteção Integrada com Backup de Energia da DRAM– Proteção Multi-bit ECC Entre os Domínios Internos– Monitoração SMART Modificada/Estendida– >1.5 milhão de horas MTBPR (rated)

� Confiabilidade NAND– SLC NAND availiado para 100.000 re-escritas

� Tempo de vida observado excede 300,000�2,000,000 re-escritas– Remapeamento Dinâmico de Bad-blocks

� Como um disco tradicional

� Wear-Leveling– Wear Leveling Estático e Dinâmico

� Escritas e Re-escritas sempre realocadas para novos blocos físicos NAND� Blocos raramente modificados são movidos para um pool de reserva� Blocos com intensa utilização são “aposentados” para acomodar blocos poucas modificados

– Capacidade bruta de reserva NAND� 73 GB útil = 128 GB raw , 400 GB útil = 512GB raw

� Confiabilidade do CLARiiON– 8 bytes adicionais por sector – utilizados para correção de erros– Cada 512 bytes de dados de usuário possuem um checksum de 6-bit associado– Suportado em todas as configurações RAID

Expectativa de Vida Deve Exceder Facilmente os Discos Mecânicos


Enterprise Flash Drives ou EFDs

� Tempos de resposta 10x mais rápidos

� Até 30x mais IOPS por drive

� 32% menos energia por GB

� 98% menos energia por I/O

Workload - IOPs

Resp

on

se T

ime M

illiseco

nd

0

5

10

15

20

25

30

35

40

45

50

55

60

0 500 1000 1500 2000 2500

15K FC Drives

100% Read Miss Workload


Configuração do CLARiiON para EFDs: Cache

� Default – Caches desativados para as LUNs em EFD– Não é uma “Best Practice”, somente o default

� Por que?– Performance dos EFDs é excelente sem cache– Disponibiliza mais páginas de cache para as LUNs em HDD LUNs, que se

beneficiam mais

� Quando alterar os valores defaults– Leituras sequenciais

� Algoritmos de pré-fetch podem otimizar os EFDs para pequenas requisições

– Escritas com tempos de resposta críticos� SP Cache irá mascarar o overhead da paridade do RAID� Ajuda a equalizar tempos de resposta de leitura e escrita

– Arrays com somente EFD


Configuração do CLARiiON para EFDs: Layout

� RAID groups– Todos os tipos de RAID podem ser utilizados

� O custo por GB e o baixo tempo de serviço favorecem o uso de RAID 5� Utilize RAID10 para casos especiais onde o tempo de escrita precisa de excelente tempo de

resposta

– As Best Practices dos discos mecânicos ainda se aplicam aos EFDs

� LUNs– Alta concorrência provê maior throughput nos EFDs

� Múltiplas LUNs no RAID group� Distribuir as LUNs pelas SPs

– MetaLUNs disponíveis

� Escolha e Distribuição nos Barramentos– Best Practices ainda se aplicam– EFDs podem disponibilizar maior throughput que os HDDs em muitos casos

� Distribua entre os barramentos para evitar os limites


Avaliando Aplicações Candidatas para EFD

� Aplicações existentes– Indicadores de performance do servidor

� I/O waits� Tempo de resposta� Queue depth� CPUs sub-utilizadas

– Janelas de processamento batch excedidas– LUNs “quentes”, discos “quentes”– Limites gerais do sistema

� Host think time� Non-EFD storage access waits� Network dependencies

� Novas aplicações– EFD oferece tempo de resposta imbatível– Permite novas funcionalidades para usuários “criativos”


Workloads “Amigáveis” para EFD

� Alta taxa de leituras, elevado percentual de leituras aleatórias– Leituras são mais rápidas que escritas– Blocos pequenos ou grandes

� Aplicações com requerimentos de latência muito baixa– Onde mesmo HDDs “short stroked” não conseguem atender– Tempo de resposta dos EFDs cerca de 10x menor que HDDs

� Alta concorrência– Maior throughput é obtido com várias threads– Pode servir excelentes tempos de resposta mesmo com enfileiramentos maiores

� Elevada largura de banda com vários streams, ou I/Os aleatórios


Resultados com Banco de Dados Oracle


Configuração de Teste

� Servidor de Banco de Dados– Dell R900– 4 x CPUs Intel 2.4 GHz Quad Core– 32 GB de memória– 2 x discos 146GB SAS internos (OS & binários Oracle)

� Configuração de Storage– CLARiiON CX4-960 – Flare 28 (4.28.0.3.593)– 150 / 75 x discos 300GB 15K RPM FC– 6 x discos 73 GB EFD

� Plataforma de Banco de Dados Oracle– Oracle 11gR1 – 11.1.0.6 (Single Instance)– ASM para gerenciamento de volumes


Configuração do Storage CX4-960


Descrição do Teste

� Carga de Testes– Benchmark OLTP (Similar ao TPC-C utilizando OAST)– Tamanho total do banco de dados – 260GB (OLTP) & 1.2TB (OLAP)– Número de usuários concorrentes – até 100– Mix de leitura/escrita de 60/40– Métricas – TPM, IOPS & tempo de resposta

� Mix acima foi modificado inicialmente para alto percentual de leitura– Intensivo em leitura (~ 99.9 % leitura)– Exemplos incluem ambientes de busca com alta indexação– Métricas – IOPS, tempo de resposta

� Ferramentas de Monitoração– Ferramentas de Storage - Navisphere Performance Analyzer– Sistema Operacional - vmstat, iostat– Banco de Dados - Oracle AWR Reports


Resultado dos Testes : Leitura Intensiva(150 FC vs 6 EFD)

� Eficiência Unitária por Disco

(Métrica EFD / #EFDs ) / (Métrica FC / #FC drives)

� Aplicações intensivas em leitura e sensíveis ao tempo de resposta podem obter estes benefícios dos Flash Drives

IOPS Relativos

1.00

3.27

-

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

150 FC 6 EFD

80x


Resultado dos Testes :Workload OLTP 60/40 (75 FC vs 6 EFD)

� Configurações default de cache para o CX4– SP : Read – ON, Write – ON– FC LUN : Read – ON, Write – ON– EFD LUN : Read – OFF, Write – OFF

� Solução EFD foi 35% mais lenta (!), mesmo assim houve uma melhora de 8X da eficiência

� Eficiência = 75/6 * 0.65 ~= 8

– Onde estava o problema ? logfile sync de 53ms

– Com escrita dos logs sobre os EFDs sem cache, o total de TPMs foi menor e com maior latência

Transações Relativas por Minuto

1.00

0.65

-

0.20

0.40

0.60

0.80

1.00

1.20

75 FC 6 EFD


Impacto do Cache : EFDs com Write CacheWorkload OLTP 60/40 (75 FC vs 6 EFD)

� Configurações default de cache para o CX4– SP : Read – ON, Write – ON– FC LUN : Read – ON, Write – ON– EFD LUN : Read – OFF, Write – ON

� Solução EFD foi 35% mais rápida, apesar da contenção no cache� Eficiência = 75/6 * 1.35 ~= 17


1.00

1.35

-

0.20

0.40

0.60

0.80

1.00

1.20

1.40

75 FC 6 EFD


Impacto do Cache : Dados em EFDs / Logs em FCWorkload OLTP 60/40 (75 FC vs 6 EFD)

� Com a escrita dos logs em discos FC com cache habilitado, e dados em EFD com cache desabilitado, os resultados obtidos foram próximos aos da configuração FC

– FC LUN : Read – ON, Write – ON– EFD LUN : Read – OFF, Write – OFF

� Mais lento que o teste com EFDs e cache habilitado– Latência dos logfile caiu de 53ms para 5 ms

� Per Disk Efficiency= (75 / 6) * 0.98 ~= 12X


1.00 0.98

-

0.20

0.40

0.60

0.80

1.00

1.20

1.40

75 FC 6 EFD


Como Identificar Bancos de Dados que se Beneficiariam com os EFDs ?

� Top 5 Wait Events do AWR – Procurar eventos relacionados à I/O

Event Waits Time(s)AvgWait(ms)

% Total Call Time

Wait Class

db file sequential read 6,737,136 54,778 8 82.7 User I/O

db file parallel read 280,373 5,864 21 8.9 User I/O

CPU time 3,894 5.9

db file parallel write 2,819,223 1,228 0 1.9 System I/O

log file sync 638,795 877 1 1.4 Commit

HDD



% Total Call Time

Wait Class


db file parallel read 280,373 5,864 21 8.9 User I/O

CPU time 3,894 5.9

db file parallel write 2,819,223 1,228 0 1.9 System I/O

log file sync 638,795 877 1 1.4 Commit


% Total Call Time

Wait Class


CPU time 5,283 26.5

db file parallel read 497,507 5,749 11.5 8.7 User I/O

log file sync 1,135,915 2,277 2.0 18.8 Commit

gc cr grant 2-way 4,744,803 1,420 0 2.2 Cluster

HDD

EFD

Per Second Per Transact.

Redo size: 1,511,040 8,449

Logical reads: 9,669 54

Block changes: 10,390 58

Physical reads: 2,688 15

Physical writes: 1,255 7

Per Second Per Transact.

Redo size: 2,630,228 8,260

Logical reads: 16,966 53

Block changes: 18,436 58

Physical reads: 4,452 14

Physical writes: 2,161 7

Como Identificar Bancos de Dados que se Beneficiariam com os EFDs ?


Movendo Partes do Banco de Dados para EFD

� Movimentação de LUNs / Volumes– Identificação de LUNs candidatas pode ser feito com o auxílio da EMC

� Basta disponibilizar os arquivos NAR ou NAZ– LUN Migration do CLARiiON permite a movimentação online dos dados

� Movimentação de Tablespaces– Tablespaces candidatas podem ser identificadas através de ferramentas do banco de dados

(AWR, statspack)– Migração via sistema operacional

� Movimentação de Datafiles– Datafiles candidatos podem ser identificados através de ferramentas do banco de dados (AWR,

statspack, V$FILESTATS)– Tende a ser mais adequado ao ciclo de ILM dos dados

� Novos datafiles -> novos dados -> mais acessos– Migração via sistema operacional

� Movimentação de Segmentos (Tabelas / Índices)– Segmentos candidatos podem ser identificados através de ferramentas do banco de dados (AWR,

statspack, V$SEGMENT_STATISTICS)– Algumas aplicações podem indicar segmentos candidatos (p.ex.: SAP)– Migração via banco de dados


Movendo Partes do Banco de Dados para EFD

� Movimentação de LUNs / Volumes– Processo bastante simples– LUNs de grande capacidade podem possuir vários arquivos com baixo nível de acesso, reduzindo

a eficiência no uso dos EFDs

� Movimentação de Tablespaces– Tablespaces de grande capacidade podem possuir vários segmentos com baixo nível de acesso,

reduzindo a eficiência no uso dos EFDs– Na maioria das situações a movimentação será feita de forma offline

� Movimentação de Datafiles– Na maioria das situações a movimentação será feita de forma offline

� Movimentação de Segmentos (Tabelas / Índices)– Segmentos com dados transacionais históricos podem não apresentar o mesmo nível de acesso

em toda a sua extensão– Na maioria das situações a movimentação será feita com a aplicação indisponível


Object Intensity

� Algumas Questões:– Quais são os segmentos que possuem uma contribuição mais significativa na

performance geral?– Como fica a questão do crescimento de dados?

Total IOPS Size (GB) Object Intensity

OBJ 1 300 19 16 OBJ 2 3,000 220 14

IOPS TR FC Tempo Total FC TR EFD Tempo Total EFD Diferença FC-EFD

OBJ 1 300 0.05 15 0.005 1.50 13.50 OBJ 2 3,000 0.05 150 0.005 15 135


Classificação de Datafiles com Oracle

Capacity

1,981,184

8,778,248 Flash

Tier 1

IOPS

7,884,191

1,795,170

Flash

Tier 1

Drive Type Capacity (MB) % Capacity Cumulative IOPS % IOPS

Flash 1,981,184 18% 7,884,191 81%Tier 1 8,778,248 82% 1,795,170 19%Total 10,759,432 9,679,361



1.00 1.011.18

2.13

-

0.50

1.00

1.50

2.00

2.50

Tudo em FC Logs em EFD OI Elevado em EFD Top TS em EFD

Resultados : Movimentação Parcial

Mover logs nãoapresenta grandes

benefícios

2% dos dados movidos para EFD

30% dos dados 70% dos I/Os em

EFD


Resultados com Banco de Dados SQL Server


Configuração de Teste

� Servidor de Banco de Dados– Dell R900– 4 x CPUs Intel 2.4 GHz Quad Core– 32 GB de memória– 2 x discos 146GB SAS internos (OS & binários Oracle)

� Configuração de Storage– CLARiiON CX4-960 – Flare 28 (4.28.0.3.593)– 45 x discos 300GB 15K RPM FC– 5 x discos 73 GB EFD

� Plataforma de Banco de Dados SQL Server– SQL Server 2008 Enterprise Edition– NTFS com Allocation Unit Size de 64K– NTFS alinhado em 1MB– LUNs em FC “short stroked”


Descrição do Teste

� Carga de Testes– OLTP benchmark (Similar ao TPC-E)– Tamanho total do banco de dados – 250GB a 600GB (OLTP)– Número de usuários concorrentes – até 125– Mix de leitura/escrita de 85/15– Métricas – TPM, IOPS & tempo de resposta

� Mix acima foi modificado inicialmente para alto percentual de leitura– Intensivo em leitura (~ 99.9 % leitura)– Exemplos incluem ambientes de busca com alta indexação– Métricas – IOPS, tempo de resposta

� Ferramentas de Monitoração– Ferramentas de Storage - Navisphere Performance Analyzer– Sistema Operacional - Perfmon– Banco de Dados – Relatórios padrões e fn_virtualfilestats


Resultado dos Testes: Workload OLTP 85/15 (75 FC vs 6 EFD)

� Eficiência Unitária por Disco

(Métrica EFD / #EFDs ) / (Métrica FC / #FC drives)

� Utilização de CPU com FC : ~85%

� Utilização de CPU com EFD : 100%


1.00

1.15

0.90

1.05

1.20

75 FC 6 EFD

14x



1.00 0.98

1.181.10

1.75

-

0.20

0.40

0.60

0.80

1.00

1.20

1.40

1.60

1.80

2.00

Tudo em FC Logs em EFD Leitura em EFD Top TS em EFD Índices em EFD

Resultados : Movimentação ParcialWorkload OLTP 85/15 (75 FC vs 6 EFD)

Mover logs nãoapresenta grandes

benefícios

Somente leitura< 5% dos dados

45% dos dados 60% dos I/Os em

EFD


Tempo de Resposta de Médio de I/OWorkload OLTP 85/15 (45 FC vs 6 EFD)

Esc

ala

-0

a 40

Banco de Dados em FC Banco de Dados em EFD


Transações Por Segundo (TPS)Workload OLTP 85/15 (45 FC vs 6 EFD)

Sca

le -

0 to

400

0

Database on FC Database on EFD


Como Identificar Bancos de Dados que se Beneficiariam dos EFDs ?

� Usando o Performance Monitor para identificar problemas de I/O– Processor: % Processor Time– Physical Disk: Average Disk Queue Length– Physical Disk: Disk Bytes Per Second– Physical Disk: % Disk Time



� Utilizando SQL Server Management Studio Standard Reports– Object Execution Statistics



� Usando fn_virtualfilestats– Exemplo em http://technet.microsoft.com/en-us/magazine/cc135869.aspx– SQL Q&A: Finding Locks, Large Queries, I/O Statistics, and More�

� Preste atenção em:– NumberReads– NumberWrites– IOStallMS– ISStallPCT


1ms

1ms

1ms 1ms 2ms

0.5ms

Total = 7msStorage= 2ms

0.5ms

Onde Estão os Grandes Ganhos ??

� Bancos de dados fazem outras operações além de I/O !!

� Uma transação é uma operação muito complexa que envolve– Várias operações intensivas em CPU– Algumas operações de I/O de vários tipos e tamanhos– Existe dependência entre as operações e pode haver serialização– Uma transação não pode ser mais rápida que sua operação mais lenta– Somente acelerar I/O pode não se traduzir sempre em melhora do tempo de

resposta da aplicação

1ms

15ms

1ms 1ms

9ms

2ms

6ms

Total= 35msStorage=30ms

Melhoria de 5X na aplicaçãomesmo com aceleração de

15X no storage

Transaction Latency

Before

Afterdeploying

EFD


Onde Estão os Grandes Ganhos ??

1ms

15ms

1ms 1ms

9ms

2ms

6ms

Total= 35msStorage=30msBefore

Tempo total da transação antes e depois da movimentaçãoparcial de dados para Flash drives

Time spent processing data

Waiting for I/O to FC drive to finish

Legend

Waiting for I/O to EFD to finish

1ms

1ms

1ms 1ms 2ms

6ms

Total = 12.5msStorage= 7.5ms

0.5ms

After

Melhoria de 2.4X na aplicaçãomesmo com ganho de 16X

dos EFDs


Particionamento e EFDs

� Particionamento – facilita a classificação e implementação de umaestratégia de ILM, permitindo que os dados sejam acomodados naclasse correta de armazenamento para otimização de custos e maioreficiência


Sumário

� Enterprise Flash Drives podem prover ganhos significativos em bancos de dados com leitura intensiva

– Todos os perfis de aplicação serão beneficiados, mesmo que em menor escala

� Extremely energy efficient in any case

� Seja conservador !– 30X ou mais de IOPS é possível com cargas de trabalho intensivas em leitura– 8X a 15X deve ser a faixa de ganhos mais comuns com mix mai comuns de leitura/escrita– Espere melhorias percentuais quando fizer movimentações parciais

� Recomendações de banco de dados– As áreas de dados são boas candidatas ao uso de EFD

� Movimentar as áreas mais ativas trazmais benefícios– A movimentação de logs para EFDs pode não ser mais eficiente

� Crie um conjunto separado de LUNs para logs e habilite o write cache nelas, se você for mover os logs paraEFDs

� EFDs podem prover melhor performance em situaçõs de elevada concorrência– Tempos de resposta menores– Mais IOPS por disco

� As Best Practices dos HDDs ainda se aplicam no uso de EFDs


Referências

� An Introduction to EMC CLARiiON Storage Device Technology - Applied Technology

� Leveraging EMC CLARiiON CX4 with Enterprise Flash Drives for Oracle Database Deployments - Applied Technology

� Implementing EMC CLARiiON CX4 with Enterprise Flash Drives for Microsoft SQL Server 2008 Databases - Applied Technology

� Specification Sheet: EMC CLARiiON®CX4 Model 960 Networked Storage System

� EMC CLARiiON®CX4 Series Ordering Information and Configuration Guidelines

� Introduction to the EMC CLARiiON®CX4Series Featuring UltraFlexTMTechnology

� Maximize the Performance Benefit from Enterprise Flash Drives by Sharing through Virtual Provisioning in EMC CLARiiON CX4

Turbine seu Banco de Dados Utilizando Enterprise Flash ... · Movendo Partes do Banco de Dados para...

Documents

Transcript of Turbine seu Banco de Dados Utilizando Enterprise Flash ... · Movendo Partes do Banco de Dados para...