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

  • 11 minutos

As seguintes diretrizes contidas são baseadas em projetos reais de clientes e nos aprendizados derivados desses projetos. As diretrizes identificam cenários que não foram bem-sucedidos no passado. Um exemplo é a recomendação para não usar servidores UNIX ou servidores virtualizados como servidores de exportação R3load:

  • Geralmente, o desempenho de exportação é um fator de concessão no tempo de inatividade geral. Geralmente, o hardware atual tem mais de 4 - 5 anos de idade e é extremamente caro de atualizar.
  • Portanto, é importante obter o máximo de desempenho de exportação que é prático de se obter.
  • Os projetos anteriores passaram semanas ou até mesmo meses tentando ajustar o desempenho de exportação de R3load em plataformas UNIX ou virtualizadas, antes de desistir e usar os servidores Intel R3load.
  • Os servidores Intel comuns 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 máquina virtual existentes, mas não costumam dar suporte a tecnologias de descarregamento moderno ou SR-IOV. Geralmente, a versão do VMware é antiga, não teve patch ou não está configurada para uma taxa de transferência de rede alta e de baixa latência. Os servidores de exportação R3load exigem um desempenho de thread rápido e uma taxa de transferência de rede extremamente alta. Os servidores de exportação R3load podem ser executados por 10 a 15 horas em quase 100% de utilização da CPU e da rede. Esse não é o caso de uso típico da maioria dos farms do VMware, e a maioria das implantações do VMware nunca foi projetada para lidar com uma carga de trabalho como o R3load.

Dica

Não invista tempo na otimização do desempenho de exportação do R3load em plataformas UNIX ou virtualizadas. Fazer isso desperdiçará não apenas o 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 para garantir que a equipe do projeto tenha servidores de exportação de R3load rápidos e modernos disponíveis no início do projeto. Isso reduzirá o custo e o risco totais do projeto.

Práticas recomendadas

  • Pesquise e faça o inventário do cenário atual do SAP. Identifique os níveis do Pacote de Suporte do SAP e determine se é necessário aplicar patches para dar suporte ao DBMS de destino. Em geral, a compatibilidade do sistema operacional é determinada pelo kernel do SAP e a compatibilidade do DBMS é determinada pelo nível de patch do 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 na camada do BD, na camada do ASCS e na camada do 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 detalha os tipos de Máquina Virtual do Azure e a configuração de armazenamento. Quantos discos premium, quantos arquivos de dados, como os arquivos de dados estão distribuídos nos discos, uso de espaços de armazenamento, tamanho de formato NTFS = 64 KB. Além disso, documente o backup/restauração e a configuração do DBMS, como configurações de memória, grau máximo de paralelismo e sinalizadores de rastreamento.
  • Desenvolva um documento de design de rede, incluindo a configuração de rede virtual, sub-rede, NSG e UDR.
  • Documente e implemente o conceito de segurança e proteção. Remova o Internet Explorer, crie um contêiner do Active Directory para servidores e contas de serviço SAP e aplique uma política de firewall bloqueando tudo, menos um número limitado de portas necessárias.
  • Crie um documento de design de migração de SO/BD detalhando o conceito de divisão de pacote e tabela, número de R3loads, sinalizadores de rastreamento do SQL Server, classificada/não classificada, configuração RowID do Oracle, configurações de SMIGR_CREATE_DDL, contadores Perfmon (como BCP linhas/s e taxa de transferência BCP kb/s, CPU, memória), configurações de RSS, configurações de Rede Acelerada, configurações de arquivo de log, configurações de BPE, configurações de TDE.
  • Crie um grafo "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 as alterações melhoram o desempenho de importação ou exportação do R3load. O eixo X é o número de pacotes concluídos e o eixo Y é o tempo decorrido. Esse plano de voo também é crítico durante a migração da produção para que o progresso planejado possa ser comparado com o progresso real e qualquer problema identificado antecipadamente.
  • Crie um plano de teste de desempenho. Identifique aproximadamente os 20 principais relatórios online, trabalhos em lotes e interfaces. Documente os parâmetros de entrada (como intervalo de datas, escritório de vendas, fábrica, código da empresa etc.) e os runtimes no sistema de fonte original. Compare com o runtime 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 verifique se os tempos limites do cluster, kernels, configurações de rede, tamanho do formato NTFS são consistentes com os documentos de design. Defina os contadores de perfmon em servidores importantes para registrar parâmetros de integridade básicos a cada 90 segundos. Verifique se os servidores SAP estão em um contêiner separado do AD 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 da migração de SO/BD está licenciado! Solicite o nome do consultor, o usuário S e a data de certificação. Abra uma mensagem de software de código aberto para BC-INS-MIG e peça à SAP para confirmar se o consultor está atualizado e licenciado.
  • Se possível, tenha toda a equipe de projeto associada ao projeto de migração do VLDB em um local físico e não dispersa geograficamente em vários continentes e fusos horário.
  • Verifique se há um plano de fallback adequado em funcionamento e se ele faz parte da agenda geral.
  • Selecione modelos de CPU Intel de contagem de threads rápidos para os servidores de exportação R3load. Não use modelos de CPU com "Economia de Energia", pois eles têm um desempenho muito e não usam servidores de quatro soquetes. O 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 outra organização de consultoria para fazer a importação. Ocasionalmente, o sistema de origem é terceirizado e gerenciado por uma organização ou parceiro de consultoria e um cliente deseja migrar para o Azure e mudar para outro parceiro. Devido ao acoplamento rígido entre o ajuste e a configuração de exportação e importação, é improvável que atribuir essas tarefas a organizações diferentes produza um bom resultado.
  • Não economize em recursos de hardware do Azure durante a migração e a ativação. As Máquinas Virtuais do Azure são cobradas por minuto e podem ser reduzidas em tamanho facilmente. Durante uma migração do VLDB, use a máquina virtual mais poderosa disponível. Os clientes foram ativados com êxito em sistemas superdimensionados em 200 a 250% e estabilizados durante a execução de sistemas superdimensionados. Depois de monitorar a utilização do sistema por quatro a seis semanas, as máquinas virtuais com excesso de capacidade são reduzidas em tamanho ou desligadas para diminuir os custos.