Explore a migração de banco de dados muito grande

• 7 minutos

Os sistemas SAP movidos para a nuvem do Azure agora geralmente incluem grandes sistemas multinacionais de "instância global única". Esses sistemas são muitas vezes maiores do que os primeiros sistemas de clientes implantados quando a plataforma Azure foi certificada pela primeira vez para cargas de trabalho SAP.

Os Bancos de Dados Muito Grandes (VLDB) agora são normalmente movidos para o Azure. Tamanhos de banco de dados acima de 20 TB exigem técnicas e procedimentos extras para obter uma migração do local para o Azure dentro de um tempo de inatividade aceitável e com baixo risco.

Descrição geral de alto nível

Uma migração de banco de dados muito grande totalmente otimizada deve atingir cerca de 2 TB por hora, taxa de transferência de migração por hora ou possivelmente mais. Isso significa que o componente de transferência de dados de uma migração de 20 TB pode ser feito em aproximadamente 10 horas. Várias etapas de pós-processo e validação precisariam ser feitas. Em geral, com tempo adequado para preparação e teste, quase qualquer sistema de cliente de qualquer tamanho pode ser movido para o Azure.

As migrações VLDB exigem habilidade considerável, atenção aos detalhes e análise. Por exemplo, o efeito líquido de uma divisão de tabela deve ser medido e analisado. As divisões de um quadro grande em mais de 50 exportações paralelas podem diminuir consideravelmente o tempo necessário para exportar um quadro, mas demasiadas divisões de quadros podem resultar num aumento drástico dos tempos de importação. Por conseguinte, o efeito líquido das divisões de tabelas deve ser calculado e testado. Um consultor especialista licenciado em migração de SO/DB deve estar familiarizado com os conceitos e ferramentas. Destacamos alguns conteúdos específicos do Azure para migrações VLDB.

Em particular, lidamos com a migração heterogênea de SO/DB para o Azure com o SQL Server como o banco de dados de destino usando ferramentas como R3load e Migmon. As etapas de migração não se destinam a cópias homogêneas do sistema, uma cópia em que o DBMS e a arquitetura do processador (Endian Order) permanecem os mesmos. Em geral, as cópias homogêneas do sistema devem ter baixo tempo de inatividade, independentemente do tamanho do DBMS, porque o envio de logs pode ser usado para sincronizar uma cópia do banco de dados no Azure.

Um diagrama de blocos ilustrado de uma migração típica de OS/DB VLDB e mover para o Azure segue após os pontos-chave:

• O SO/DB de origem atual é geralmente AIX, HPUX, Solaris ou Linux; e DB2 ou Oracle.

• O sistema operacional de destino é Windows, Suse 12.3, Redhat 7.x ou Oracle Linux 7.x.

• O banco de dados de destino geralmente é SQL Server ou Oracle 12.2.

• O desempenho do IBM pSeries, do hardware Solaris SPARC e do thread HP Superdome é drasticamente menor do que os modernos servidores de commodities Intel de baixo custo, portanto, o R3load é executado em servidores Intel separados.

• O VMware requer ajuste e configuração especiais para obter um desempenho de rede bom, estável e previsível. Normalmente, os servidores físicos são usados como servidor R3load e não como máquinas virtuais.

• Normalmente, quatro servidores R3load de exportação são usados, embora não haja limite para o número de servidores de exportação. Uma configuração típica seria:

  • Servidor de exportação 1 – dedicado às maiores tabelas de 1 a 4 (dependendo de quão distorcida é a distribuição de dados no banco de dados de origem).
  • Servidor de exportação 2 – dedicado a tabelas com divisões de tabelas.
  • Servidor de exportação 3 – dedicado a tabelas com divisões de tabelas.
  • Servidor de exportação 4 – todas as tabelas restantes.

• Os arquivos de despejo de exportação são transferidos do disco local no servidor R3load baseado em Intel para o Azure usando o AzCopy via Internet pública. Isso geralmente é mais rápido do que via Rota Expressa.

• O controle e a sequência da importação são feitos através do arquivo de sinal (SGN) que é gerado automaticamente quando todos os pacotes de exportação são concluídos. Isto permite uma exportação/importação semi-paralela.

• A importação para SQL Server ou Oracle é estruturada de forma semelhante à exportação, usando quatro servidores de importação. Esses servidores seriam servidores R3load dedicados separados com rede acelerada. É recomendável que os servidores de aplicativos SAP não sejam para essa tarefa.

• Os bancos de dados VLDB normalmente usariam máquinas virtuais E64v3, m64 ou m128 com Armazenamento Premium. O log de transações pode ser colocado no disco SSD local para acelerar as gravações do log de transações e remover o IOPS do log de transações e a largura de banda de E/S da cota da máquina virtual. Após a migração, o log de transações deve ser colocado em um disco persistente.