Examinar as práticas recomendadas de migração de banco de dados muito grande

  • 11 minutos

As diretrizes a seguir contidas são baseadas em projetos reais de clientes e nos aprendizados derivados desses projetos. As orientações identificam cenários que não tiveram êxito no passado. Um exemplo é a recomendação de não usar servidores UNIX ou servidores virtualizados como servidores de exportação R3load:

  • Muitas vezes, o desempenho das exportações é um fator determinante no tempo de inatividade geral. Muitas vezes, o hardware atual tem mais de 4-5 anos e é proibitivamente caro para atualizar.
  • Portanto, é importante obter o máximo desempenho de exportação que seja prático alcançar.
  • Projetos anteriores gastaram semanas-homem ou mesmo homens-meses tentando ajustar o desempenho de exportação do R3load em plataformas UNIX ou virtualizadas, antes de desistir e usar servidores Intel R3load.
  • Os servidores Intel de mercadoria de soquete duplo são baratos e oferecem ganhos substanciais de desempenho, em alguns casos ordens de magnitude maiores do que pequenas melhorias de ajuste possíveis em servidores UNIX ou virtualizados.
  • Os clientes geralmente têm farms de VM existentes, mas na maioria das vezes eles não suportam tecnologias modernas de descarregamento ou SR-IOV. Muitas vezes, a versão do VMware é antiga, não tem patches ou não está configurada para alta taxa de transferência de rede e baixa latência. Os servidores de exportação R3load exigem um desempenho de thread muito rápido e uma taxa de transferência de rede extremamente alta. Os servidores de exportação R3load podem ser executados por 10-15 horas com quase 100% de utilização da CPU e da rede. Este não é o caso de uso típico da maioria dos farms VMware e a maioria das implantações VMware nunca foi projetada para lidar com uma carga de trabalho como o R3load.

Gorjeta

Não invista tempo na otimização do desempenho de exportação do R3load em plataformas UNIX ou virtualizadas. Fazer isso não só perderá tempo, mas custará muito mais do que comprar servidores Intel de baixo custo no início do projeto. Os clientes de migração do VLDB são, portanto, solicitados a garantir que a equipe do projeto tenha servidores de exportação R3load modernos e rápidos disponíveis no início do projeto. Isso reduzirá o custo total e o risco do projeto.

Melhores práticas

  • Levantamento e inventário do cenário atual do SAP. Identifique os níveis do SAP Support Pack e determine se a aplicação de patches é necessária para suportar o DBMS de destino. Em geral, a compatibilidade do sistema operacional é determinada pelo kernel SAP e a compatibilidade DBMS é determinada pelo nível de patch SAP_BASIS.
  • Crie uma lista de notas do SAP OSS que precisam ser aplicadas no sistema de origem, como atualizações para SMIGR_CREATE_DDL. Considere atualizar os kernels SAP nos sistemas de origem para evitar uma grande alteração durante a migração para o Azure (por exemplo. Se um sistema estiver executando um kernel 7.41 antigo, atualize para o 7.45 mais recente no sistema de origem para evitar uma grande alteração durante a migração).
  • Desenvolva e documente a solução de alta disponibilidade e recuperação de desastres. A documentação deve dividir a solução em camada de banco de dados, camada ASCS e camada de servidor de aplicativos SAP. Soluções separadas podem ser necessárias para soluções autônomas, como TREX ou liveCache.
  • Desenvolva um documento de dimensionamento e configuração que detalhe os tipos de VM do Azure e a configuração de armazenamento. Quantos discos premium, quantos arquivos de dados, como os arquivos de dados são distribuídos entre discos, uso de espaços de armazenamento, tamanho do formato NTFS = 64 kb. Além disso, faça backup/restauração de documentos e configuração de DBMS, como configurações de memória, grau máximo de paralelismo e traceflags.
  • Desenvolva um documento de projeto de rede incluindo configuração de VNet, Sub-rede, NSG e UDR.
  • Documentar e implementar conceito de segurança e proteção. Remova o Internet Explorer, crie um contêiner do Ative Directory para contas de serviço e servidores SAP e aplique uma política de firewall bloqueando todas as portas, exceto um número limitado de portas necessárias.
  • Crie um documento de design de migração de SO/DB detalhando o conceito de divisão de pacotes e tabelas, número de carregamentos R3, traceflags do SQL Server, classificados/não classificados, configuração Oracle RowID, configurações de SMIGR_CREATE_DDL, contadores Perfmon (como linhas/s BCP e taxa de transferência BCP kb/seg, CPU, memória), configurações RSS, configurações de rede acelerada, configuração do arquivo de log, configurações BPE, configuração TDE.
  • Crie um gráfico "Plano de voo" mostrando o progresso da exportação/importação do R3load em cada ciclo de teste. Isso permite que a equipe de migração valide se os ajustes e alterações melhoram o desempenho de exportação ou importação do R3load. O eixo X é o número de pacotes concluídos e o eixo Y é o tempo decorrido. Este plano de voo também é crítico durante a migração de produção para que o progresso planejado possa ser comparado com o progresso real e qualquer problema identificado no início.
  • Crie um plano de teste de desempenho. Identifique os ~20 principais relatórios on-line, trabalhos em lote e interfaces. Documente os parâmetros de entrada (como intervalo de datas, escritório de vendas, fábrica, código da empresa, etc.) e tempos de execução no sistema de origem original. Compare com o tempo de execução no Azure. Se houver diferenças de desempenho, execute SAT, ST05 e outras ferramentas SAP para identificar instruções ineficientes.
  • Audite a implantação e a configuração e certifique-se de que os tempos limite do cluster, kernels, configurações de rede, tamanho do formato NTFS sejam consistentes com os documentos de design. Defina contadores perfmon em servidores importantes para registrar parâmetros básicos de integridade a cada 90 segundos. Verifique se os servidores SAP estão em um contêiner AD separado e se o contêiner tem uma política de grupo aplicada a ele com configuração de firewall.
  • Verifique se o consultor líder de migração de SO/DB está licenciado! Solicite o nome do consultor, s-user e data de certificação. Abra uma mensagem OSS para BC-INS-MIG e peça ao SAP para confirmar que o consultor está atualizado e licenciado.
  • Se possível, tenha toda a equipe do projeto associada ao projeto de migração do VLDB dentro de um local físico e não geograficamente dispersa por vários continentes e fusos horários.
  • Certifique-se de que há um plano de fallback adequado está em vigor e que faz parte do cronograma geral.
  • Selecione modelos de CPU Intel de contagem rápida de threads para os servidores de exportação R3load. Não use modelos de CPU "economizadores de energia", pois eles têm desempenho mais baixo e não usam servidores de 4 soquetes. Intel Xeon E5 Platinum 8158 é um bom exemplo.

Melhores práticas para evitar problemas

  • Não subcontrate uma organização de consultoria para fazer a exportação e subcontrate outra organização de consultoria para fazer a importação. Ocasionalmente, o sistema de origem é terceirizado e gerenciado por uma organização de consultoria ou parceiro e um cliente deseja migrar para o Azure e mudar para outro parceiro. Devido ao estreito acoplamento entre o ajuste e a configuração de exportação e importação, é improvável que a atribuição dessas tarefas a diferentes organizações produza um bom resultado.
  • Não economize recursos de hardware do Azure durante a migração e entre em operação. As VMs do Azure são cobradas por minuto e podem ser reduzidas em tamanho facilmente. Durante uma migração VLDB, use a VM mais poderosa disponível. Os clientes entraram em operação com sucesso em sistemas 200-250% superdimensionados e, em seguida, estabilizados enquanto executavam sistemas superdimensionados. Depois de monitorar a utilização do sistema por 4 a 6 semanas, as VMs com excesso de capacidade são reduzidas em tamanho ou desligamento para reduzir custos.