Explore a migração de banco de dados muito grande
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 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 VMs.
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 tabela
- 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 não usar os servidores de aplicativos SAP para essa tarefa.
Os bancos de dados VLDB normalmente usariam VMs 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 de VM. Após a migração, o log de transações deve ser colocado em um disco persistente.
