Vamos iniciar um novo tópico na nossa área DB2 LUW. Começaremos alguns posts falando sobre Performance em um ambiente DB2 LUW. Inicialmente dedicaremos os posts para ambientes OLTP (Transacionais).

SISTEMAS DE STORAGE

Atualmente os tão conhecidos Sistemas de Storage (por exemplo: IBM System Storage® DS6800 e DS8300) oferecem muitas vantagens quando comparados a discos individuais (servidores onde os discos são adicionados conforme necessidade e sem acesso ao um Sistema de Storage). Primeiramente o “overhead” de administração de discos é reduzida, teremos melhor performance, esses sistemas oferecem um grande “storage server cache”, acesso “multipath”, backup, confiabilidade e disponibilidade assegurada e melhorada.
Esses são alguns dos pontos importantes ao decidir entre alocação de discos individuais ou optar por um sistema de Storage.
Sem considerar o recente sucesso dos discos SSDs (Solid-State Devices), discos magnéticos são ainda a regra em data centers. Devido uma diferença de processamento entre a velocidade de um processador e os discos, o que chamamos de contenção de I/O logo se torna um problema para o ambiente quando o mesmo não foi bem estruturado. Lembre-se que o planejamento inicial e estruturação do ambiente são pontos onde o DBA deve atuar e aconselhar.
Como regra inicial e melhores práticas, para manter um banco de dados performando à um nível aceitável e diminuindo o gargalo de I/O devemos distribuir os dados do ambiente DB2 em vários discos. Com isso teremos paralelismo na busca pelos dados. Essa regra vale para ambientes onde exista um Sistema de Storage, assim como ambientes onde discos são adicionados conforme necessidade, ou seja, devemos ter volumes lógicos ou grupo de discos formados por um número X de discos, ao invés de apenas um disco de 100 GB podemos ter 5 discos de 20GB por volume lógico ou grupo de discos.

DISK ARRAYs

A maioria dos Sistemas de Storage e Sistemas Operacionais suportam o que chamamos de RAID de disco. Existem vários níveis de RAID, e cada nível de RAID indica como os arrays de discos estão arranjados e qual tipo de falha eles tolerarão. Isto indiretamente influenciará na performance do array de disco.

RAID0 – utiliza blocks de disco no formato “round-robin” ou também chamado de “striping” de disco. Não existe redundância para este nível, porém possuem a maior velocidade de escrita e leitura, pois todos os discos que pertencem a este array podem ser acessados de forma paralela durante operações de I/O.

RAID1 – também conhecido como “mirroring” ou espelhamento, requer uma redundância de disco para cada disco existente no array. Este nível prove a melhor solução em caso de falha. Por exemplo, metade dos discos no array podem ser perdidos sem que haja interrupção ou qualquer efeito no ambiente. Entretando, utilizando este nível um custo será aplicado, ou seja, ele duplica as necessidade de espaço em disco e diminui o “throughput”, pois cada escrita precisa ser executada duas vezes.

RAID2 e RAID3 – utiliza paridade de bit e byte como solução de redundância.

RAID4 e RAID5 – ambos utilizam paridade de bloco como solução de redundância, oferecendo tolerância a falha de um disco. RAID4 utiliza uma paridade dedicada de disco, e durante operações de escrita intensiva (sistemas OLTP) isso pode acarretar um gargalo no ambiente. RAID5 oferece uma melhora de performance utilizando paridade distribuida para eliminar o gargalo durante operações de escrita.

Para ambiente OLTP em DB2 LUW, o aconselhável é utilizar RAID5 para os containers das tablespaces onde performance não seja um problema. Onde performance é exigida, de preferência para os RAIDs 1 + 0 ou 0 + 1. Se possível, utilize storage-server-level RAID (implementação de RAID via storage – o que ocorre geralmente) ou  adapter-level hardware RAID (implementado diretamente no hardware – placas ou cards para RAID).
Para os arrays de disco, desabilite a funcionalidade read-ahead do Storage, pois em ambientes OLTP as consultas não possuem um padrão sequencial. Habilite a funcionalidade write-behind para escritas rápidas. O write-behind quando habilitado não espera pela escrita em página do disco, quando a página é copiada para o server cache do storage a operação de escrita é considerada com sucesso pela engine do DB2 LUW. O write-behind também não causará nenhum problema mesmo em caso de queda de energia, pois a arquitetura de um Sistema de Storage possui tecnologia para mante-lo funcionando até que todas as páginas que estavam em cache sejam descarregadas para disco.

Não esquecendo dos logs transacionais, toda informação “committada” ou não precisa ser garantida, dai a necessidade também de pensarmos onde colocaremos nossos logs para serem aplicados em caso de falha ou qualquer outro problema onde a base de dados necessitar de recuperação.
Ambientes OLTP possuem uma carga pesada de operações de INSERT, UPDATE e DELETE que demandam muito da performance de I/O do ambiente. Embora RAID5 possa ser utilizado como solução de paridade para os logs transacionais, RAID1 seria o recomendado devido a segurança desses dados, mas RAID1 pode tornar-se um problema de performance. Caso isto ocorra utilize RAID 1 + 0, pois este nível irá prover espelhamento individual para cada disco e o striping irá distribuir os dados ao longo dos dos pares de discos espelhados. É possível também optar pela opção RAID 0 +1, onde ocorrera striping através dos discos e todo o conjunto será espelhado.

Uma outra funcionalidade oferecida atualmente pelos modernos Sistemas de Storage e Sistemas Operacionais é o famoso “Load Balacing e Failover para Multipath”. O Multipath conecta o servidor e sistema operacional ao Sistema de Storage. Durante operações normais o adapter fará o compartilhamento do workload, mas se um desses adapters falhar, então outro adapter continuará servindo as operações de I/O que estão ocorrendo no seu sistema de banco de dados. Essa tecnologia causará um pequeno ou quase nenhum impacto de performance ao seu ambiente.


MELHORES PRÁTICAS, UM RESUMO:

Utilize as seguintes dicas quando estiver desenhando seu novo ambiente DB2 LUW:

  • Utilize Sistemas de Storage e Sistemas Operacionais que possuem capacidade e funcionalidades de implementar RAID em discos ou no próprio hardware do servidor;
  • RAID5 oferece um balanceamento entre custo e redundância, mas a performance é um pouco reduzida devido os recálculos de paridade;
  • Desabilite a funcionalidade de Read-Ahead do nível de Storage para ambientes OLTP;
  • Utilize RAID 1+0 ou 0 + 1 como solução de melhor performance, disponibilidade e escalabilidade para os logs transacionais e containers;
  • Se o Sistema de Storage possui capacidade de limpeza de cache em caso de falta de energia, por exemplo, habilite a funcionalidade de Write-Behind do seu Sistema de Storage;
  • Se o RAID a nível de Hardware não é suportado, utilize pelo menos RAID ao nível de Storage;
  • E por último não menos importante, RAIDs a nível de Hardware são mais rápidos que RAIDs a nível de Software presentes em Sistemas Operacionais ou nível de Storage.

Por hoje é isso pessoal. Aguardem os próximos posts com mais dicas de performance para o seu ambiente OLTP rodando com DB2 LUW.
Qualquer dúvida ou sugestões estamos à disposição.

Abraço a todos.

Para maiores informações de melhores práticas de Storage, visite o Developerworks IBM.