Explorar a migração de banco de dados muito grande
Os sistemas SAP movidos para a nuvem do Azure agora geralmente incluem sistemas de "instância global única" de grande porte. Esses sistemas são muitas vezes maiores do que os primeiros sistemas de clientes implantados quando a plataforma do Azure foi certificada pela primeira vez para cargas de trabalho SAP.
Agora, é comum mover VLDBs (bancos de dados muito grandes) para o Azure. Bancos de dados com mais de 20 TB exigem técnicas e procedimentos adicionais para serem migrados do local para o Azure com um tempo de inatividade aceitável e baixo risco.
Visão geral de alto nível
Uma migração de banco de dados muito grande totalmente otimizada deve atingir uma taxa de transferência de cerca de 2 TB por hora ou possivelmente mais. Isso significa que o componente de transferência de dados de uma migração de 20 TB pode ser realizado em aproximadamente 10 horas. Várias etapas de pós-processamento e validação precisariam ser realizadas. De modo geral, com tempo adequado para preparação e teste, praticamente qualquer sistema do cliente de qualquer tamanho pode ser movido para o Azure.
As migrações de 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 mensurado e analisado. As divisões de uma tabela grande em mais de 50 exportações paralelas podem diminuir consideravelmente o tempo gasto para exportar a tabela, mas muitas divisões de tabela podem resultar em tempos de importação drasticamente maiores. Sendo assim, o efeito líquido da divisão de tabelas deve ser calculado e testado. Um consultor licenciado especializado em migração de SO/BD estará familiarizado com os conceitos e as ferramentas. Destacaremos alguns conteúdos específicos do Azure para migrações de VLDB.
Em particular, lidamos com migração de SO/BD heterogênea para o Azure com o SQL Server como o banco de dados de destino usando ferramentas como o R3load e o 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 (ordem Endian) permanecem iguais. De modo geral, cópias homogêneas do sistema devem ter um tempo de inatividade baixo, 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 bloco ilustrado de uma migração típica de SO/BD do VLDB e migração para o Azure segue após os pontos-chave:
O SO/BD de origem atual geralmente é AIX, HPUX, Solaris ou Linux; e DB2 ou Oracle.
O SO de destino é o Windows, o Suse 12.3, o Redhat 7.x ou o Oracle Linux 7.x.
O BD de destino geralmente é o SQL Server ou o Oracle 12.2.
O desempenho de thread do IBM pSeries, do hardware Solaris SPARC e do HP Superdome é drasticamente inferior ao dos servidores Intel comuns de baixo custo modernos, portanto, o R3load é executado em servidores Intel separados.
O VMware requer ajustes e configurações especiais para atingir um desempenho de rede bom, estável e previsível. Normalmente os servidores físicos são usados como servidores R3load, e não VMs.
É comum usar quatro servidores R3load de exportação, embora não haja nenhum limite para o número de servidores de exportação. Uma configuração típica seria:
- Servidor de exportação 1 – dedicado às tabelas 1-4 maiores (dependendo do quão distorcida está a distribuição de dados no banco de dado 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 tabela
- 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 AzCopy via Internet pública. Normalmente, isso é mais rápido do que por meio do ExpressRoute.
O controle e a sequência da importação ocorrem por meio do SGN (arquivo de sinal) gerado automaticamente quando todos os pacotes de exportação são concluídos. Isso permite uma exportação/importação semi paralela.
A importação para o SQL Server ou o Oracle é estruturada de maneira 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 esta tarefa.
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 a largura de banda de E/S e IOPS do log de transações da cota da VM. Após a migração, o log de transações deve ser colocado em um disco persistente.
