Brainstorm Netapp / DL380 G5 / DL380 G7

1 Instalao Ficaram faltando os trilhos do servidor e do storage 2 Instalao demorou mais do que devia devido aos seguintes fatores - Os discos do netapp foram trocados de SATA para SAS. - Devido a esta troca, 2 discos ficaram com verso superior ao utilizado pelo sistema operacional netapp. Este discos no puderam ser utilizados - Soluo: Alterar a verso do S.O. netapp de 7.3.3 para 8. - Com muita dificuldade, a verso subiu. Tentamos FTP e HTTP, mas sem sucesso. O Enoque estava utilizando uma verso errada dos binrios. - Com a ajuda da Netapp e da Microware, instalamos CIFS no servidor e conseguimos compartilhar com o Windows um espao para atualizar o S.O. 3 Por necessidade, precisamos de 4TB de espao livre no netapp para poder realizar os testes que preparamos. Desta forma, tivemos que desativar uma controladora do netapp, deixando apenas uma ativa, pois cada controladora utiliza 2 discos. Tivemos tambm que deixar apenas um disco de paridade e um disco de spare.O tamanho foi maior que os 4TB que precisvamos, mas no setup final ainda perdemos mais espao em disco.Assim obtivemos 4TB de espao livre. 4 Criamos um nico agregate com todos os discos e separamos em 4 volumes para criar os arquivos de dados e ndices dos 2 banco de dados Oracle que sero utilizados. 5 Mapeamos os 4 filesystems no servidor G7. 6 O servidor G5 da Microware veio com o sistema operacional ESX 5.0 da VmWare com licena de 60 dias. 7 Configuramos uma mquina virtual Oracle Linux com 4 processadores e 8GB de RAM e 60GB de HD. Instalamos o Oracle 10.2.0.5 na mquina para testarmos a performance 8 O G7 j estava com o Oracle Linux instalado e o Oracle 10.2.0.5 instalado tambm. 9 Abri a base de Homologao e criei o export do banco de dados utilizando a ferramenta da Oracle expdp com opo de export full do banco de dados. 10 Esta ferramenta gravou os arquivos de sada diretamente no netapp a uma taxa de aproximadamente 500Mbits ou seja, 60MB/s. 11 Por no termos um switch Gigabit disponvel para testar apenas esta soluo, colocamos as 3 mquinas na rede.

12 Colocamos um cabo cross entre o netapp e os dois servidores HP DL. - No netapp, no tivemos dificuldades em ativar as placas de rede para executar a tarefa. - No servidor G7 com Oracle Linux, a porta j estava ativa. Enviei um email para o Rodrigo da Pax para configurar o IP da porta. - No servidor G5, com ESX, tivemos que pedir ajuda Microware para poder configurar as portas da forma como precisvamos, pois as duas portas, quando ativas, assumiam o mesmo IP. - Quando conseguimos separar as portas, eu consegui associas as duas separadamente para o Oracle Linux. - Enviei um email para o Rodrigo da Pax para configurar o IP da porta. - Ainda estou esperando o Rodrigo da Pax realizar as configuraes. - O objetivo desta alterao criar uma rede entre as 3 mquinas para que o trfego de dados do banco de dados no passe pela rede. - As 3 mquinas ainda continuam conectadas rede. 13 Configuramos os 4 volumes netapp com 1% de rea livre de snapshot. 14 No primeiro teste de exportao do banco de dados, tivemos duas tabelas que ficaram fora por dar a mensagem SNAPSHOT TOO OLD. Tive que excluir os arquivos e efetuar um novo export com o banco de dados ativo, mas sem utilizao. Baixei o aplicativo da base de homologao e realizei o export novamente. Deu certo. - Para realizar o export novamente, tive que excluir os arquivos do export antigo. Quando realizei a tarefa, o espao em disco livre no foi liberado, pois o sistema de snapshot moveu os arquivos para uma pasta de snapshots. Como eu precisava do espao livre, tive que desabilitar o snapshot do netapp. - Conversando com o Enoque e a Fabiana e verificando documentaes da Netapp, vimos que, para manter os snapshots anteriores ntegros, o netapp no exclui os arquivos, apenas move para uma pasta especial. - A rea de snapshot utilizada foi de mais de 10% apesar de configurar apenas 1%. O Enoque nos informou que este procedimento normal. Temos que realizar configuraes mais avanadas e gerenciar os snapshots para no afetar o sistema. - Conversando apenas com a Fabiana, chegamos concluso que utilizar o Oracle database com o snapshot ativo invivel e no necessrio, uma vez que no possvel recuperar apenas um arquivo do banco de dados (datafile), pois o banco perde a integridade. 15 No primeiro teste de import do banco de dados, tive um problema de falta de espao para terminar a importao. - Desta forma, tive que excluir os arquivos e realizar a movimentao de outros. O sistema do netapp ficou absurdamente lento, demorando alguns segundos para retornar o comando LS. - Exclui arquivos de um volume e estava movendo os arquivos de um segundo volume para um terceiro volume. Esta movimentao se tornou muito lenta, pois os arquivos estavam sendo movidos a uma taxa de 8MB/s. - Cancelei os dois processos e o sistema levou um tempo para voltar ao normal.

- Realizei a excluso dos arquivos primeiro, que foi mais rpido e depois fiz a movimentao dos arquivos. - Na movimentao dos arquivos, o sistema voltou novamente a ficar lento, demorando muito mais que o necessrio para retornar a resposta de um comando LS. - Esta lentido aparenta estar ocorrendo apenas na pasta que os arquivos esto sendo movidos. - Assim, chego concluso: A - Criar arquivos muito rpido e no interfere na performance do sistema. B Excluir arquivos lento e no interfere na performance do sistema. C Mover arquivos rpido e pode inviabilizar o uso do sistema. - Ver a imagem abaixo mostrando os tempos do comando ls na pasta que os arquivos estavam sendo movidos.

16 Nova excluso de arquivos. Ocorre o mesmo problema. A pasta cujo arquivos esto sendo excludos fica indisponvel. 18 Criao do banco de dados efetuada com sucesso. 19 Aplicativo clonado com sucesso

20 utilizao do aplicativo: 100%. A utilizao est bem rpida. Exemplos de performance: Execuo do Concurrent: Relatrio Completo de Chicotes Parmetros: Organizao: 99 Item : ABCD-1234 Reviso :000 Ordenao :2 Tempo de execuo: base 10gLinux : 15 segundos (netapp 2040 com DL380 G7 oracle 10G) Base Desenvolvimento: 6 minutos e 14 segundos (Sun V250 com storage Sun oracle 9i) Base TEST : 58 segundos (Sun T5220 com HP P4300 oracle 10G) Base Homologao : 1 minuto e 12 segundos (Sun T5220 com HP P4300 oracle 10g) Base Produo : 39 segundos (Solaris E2900 com EVA8100 ora10g) Base TESTE : 1 minuto e 14 segundos (netapp 2040 com Sun V250 oracle 10G) O Processador de Custo de Absoro Peridico demorou 1h35min no Ambiente Linux. Este o primeiro processo do PAC, que no ms de Janeiro demorou 4h25min na Base de Produo. Vale ressaltar que, na Base de Produo, houve um ganho neste tempo depois da migrao do banco. No ms de novembro, este tempo da produo foi bem superior ao atual. 18 Efetuei a limpeza dos arquivos de 380 GB dos arquivos do export. Enquanto exclua os arquivos, o sistema ficou praticamente inopervel devido ao processador do netapp estar a 100%.

Fica invivel excluir arquivo em uma janela operacional. Tempo de excluso dos arquivos: 1 segundo. Tempo para o sistema voltar ao normal: 8 minutos. Novamente excluindo:

Durao da indisponibilidade no segundo teste:190 segundos 17 Estou continuando os testes.