Planejar uma migração de dados

Concluído

Um projeto de modernização de plataforma de dados tem cinco fases que geralmente são concluídos na ordem.

No cenário de varejista global, a diretoria aprovou o projeto de modernização, e você está começando a organizar a equipe e outros recursos. Para configurar e atribuir tarefas de forma ideal, você precisa entender as fases do projeto em detalhes.

Nesta unidade, você explorará cada uma das cinco fases mais detalhadamente.

Iniciar e descobrir

Em geral, os projetos de modernização da plataforma de dados são iniciados para atender a requisitos comerciais ou legais. Portanto, é crucial levar em conta essas necessidades e obter suporte da alta gerência. A primeira etapa será realizar um exercício de descoberta que inclua as seguintes considerações:

• Avaliar o ambiente atual

  Muitas infraestruturas de TI levam muitos anos, ou décadas, para evoluírem. Nesse momento, pode haver uma grande mudança nos negócios e na equipe, já que talvez não haja mais especialistas nos sistemas de uma organização. Em algumas raras ocasiões, as organizações podem até se esquecer de que ainda têm alguns sistemas.

• Verificar as dependências entre aplicativos e bancos de dados existentes

  Você dedicar um tempo para entender como seus aplicativos interagem com os bancos de dados que existem em sua rede. Além disso, também precisa compreender as dependências entre bancos de dados existentes para que você possa unir bancos de dados em agrupamentos lógicos. Ao fazer este exercício, você usará os agrupamentos lógicos de bancos de dados como base para migrá-los para o Azure como uma unidade.

• Listar os tipos de carga de trabalho de seus sistemas

  Listar os tipos de cargas de trabalho em relação aos servidores de banco de dados identificados fornece insights sobre o uso deles. As cargas de trabalho podem ser categorizadas como OLAP (analíticas) ou OLTP (transacionais) de acordo com o fato de serem de leitura ou de gravação intensiva. Isso ajuda a decidir a tecnologia de plataforma de dados para a qual você deverá migrar. A categorização adicional pode incluir cargas de trabalho de lotes ou de apoio à decisão.

Avaliação

Durante a fase de avaliação, as informações coletadas durante a fase de descoberta são usadas para realizar uma avaliação abrangente das cargas de trabalho identificadas a fim de estabelecer o seguinte:

• Todos os bloqueadores de migração em potencial
• Quaisquer alterações significativas que exijam correções na pós-migração
• Recursos do Azure que as cargas de trabalho podem usar

Estabeleça isso realizando uma avaliação da carga de trabalho atual e uma avaliação de critérios da carga de trabalho:

• Avaliação da carga de trabalho atual

  Os aplicativos e os servidores de banco de dados identificados são categorizados e confirmados para estabelecer o seguinte: volume de dados e taxas de crescimento esperadas, uso médio de recursos e criticalidade deles para a empresa. Essa fase também apresenta uma oportunidade de considerar a combinação ou a desativação de bancos de dados locais, a fim de reduzir o número de bancos de dados a serem migrados e reduzir o custo total de propriedade.

• Avaliação de critérios da carga de trabalho

  Na avaliação de critérios da carga de trabalho, use as conclusões da avaliação da carga de trabalho atual e defina os critérios pós-migração para executar as cargas de trabalho identificadas.

  Digamos que você identificou um servidor de banco de dados transacional muito usado durante o horário de pico, mas com pouco uso fora do horário de pico. Na avaliação de critérios da carga de trabalho, você define um critério pós-migração, como migrar para um Banco de Dados SQL do Azure com dimensionamento automático para lidar com cargas de pico.

Planejamento

A fase de planejamento de um projeto de modernização da plataforma de dados envolve determinar a plataforma de destino, a abordagem de migração e os planos de mitigação para todas as interrupções planejadas ou não planejadas.

Na fase de planejamento do processo de modernização da plataforma de dados, há sete termos para descrever como você pode lidar com a transição de aplicativos e dados de um ambiente local existente para um novo ambiente baseado em nuvem (público ou privado):

#	Fase	Ação	Descrição
1.	Permanência	Não fazer nada	Modernização contínua, considerando as opções de longo prazo para os serviços locais restantes.
2.	Hospedar novamente	Migração para a IaaS	Essa abordagem elimina a necessidade de gerenciamento de data center e fornece um ROI (retorno sobre o investimento) mais alto por meio de um TCO (custo total de propriedade) mais baixo.
3.	Refatoração	Migração para IaaS ou PaaS com alterações mínimas do aplicativo	Essa abordagem elimina a necessidade de gerenciamento de data center e fornece um ROI (retorno sobre o investimento) mais alto por meio de um TCO (custo total de propriedade) mais baixo. Também permite uma sobrecarga de gerenciamento mais baixa com a fusão de bancos de dados.
4.	Recriação da arquitetura	Reescrita dos principais aspectos do aplicativo para uso das tecnologias de nuvem	Ela permite o uso de componentes modernos, reduz a implantação de código e facilita a implantação de infraestrutura e serviços de DevOps.
5.	Recompilar	Recompilação do aplicativo para uso do PaaS ou de tecnologias sem servidor	A recompilação de plataformas de dados e aplicativos com tecnologias mais recentes permite o uso da alta disponibilidade interna do Azure, aumenta a portabilidade e a escalabilidade do aplicativo e minimiza possíveis lacunas de habilidades entre a tecnologia usada e a equipe de suporte/desenvolvimento do aplicativo.
6.	Substituir	Substituição do aplicativo para um aplicativo ou uma solução de SaaS mais recente	Considere a abordagem de substituição quando um aplicativo tiver dependências de dispositivos físicos anexados ao servidor ou quando ele se integrar fortemente à infraestrutura local.
7.	Desativar	Descomissionar aplicativos que não são mais necessários	A abordagem de desativação deve ser considerada quando aplicativos herdados e bancos de dados não são mais usados porque não há nenhum requisito comercial ou legal para mantê-los.

O gráfico abaixo mostra a quantidade de esforço que cada termo requer em comparação com o valor que a empresa obtém da migração.

• Opções de destino de plataforma

  Há duas opções de alto nível disponíveis para você, em relação à escolha da plataforma de destino.

  • IaaS (Infraestrutura como Serviço) – Nessa abordagem, você migrará seus dados para uma máquina virtual com SQL Server instalado.

  • PaaS (Plataforma como Serviço) – Nessa abordagem, você migrará seus dados para um serviço de plataforma de dados que atenda à sua carga de trabalho. Para cargas de trabalho transacionais, isso envolverá o Banco de Dados SQL do Azure ou a Instância Gerenciada de SQL do Azure. Para cargas de trabalho do tipo OLAP (Processamento Analítico Online), isso envolveria o Azure Synapse Analytics.

• Escolha da plataforma de destino por recursos

  • Banco de dados SQL do Azure – Use-o se a área da superfície do aplicativo estiver no escopo do banco de dados. O Banco de Dados SQL oferece uma solução de baixa manutenção que pode ser uma ótima opção para determinadas cargas de trabalho.

  • Pools Elásticos do Banco de Dados SQL do Azure – Os pools elásticos permitem que você aloque recursos de computação e armazenamento a um grupo de bancos de dados, em vez de precisar gerenciar os recursos de cada banco de dados individualmente. Além disso, é mais fácil dimensionar pools elásticos do que bancos de dados individuais, em que o dimensionamento de bancos de dados individual não é mais necessário devido a alterações feitas no pool elástico.

  • Banco de Dados SQL do Azure sem servidor – Efetivo para reduzir os custos em ambientes de desenvolvimento e teste. O recurso de atraso de pausa automática permite definir o período inativo antes que o banco de dados seja colocado em pausa automaticamente. Você pode escolher entre uma hora e sete dias ou desabilitá-lo. Quando você acessa o banco de dados novamente, ele é retomado e só gera custos de armazenamento durante a pausa.

  • Instância Gerenciada de SQL do Azure – Apropriada para uso se a área da superfície do aplicativo estiver no escopo da instância e exigir recursos não disponíveis no Banco de Dados SQL do Azure, como:

    • SQL Agent
    • MSDTC
    • DQS
    • MDS
    • Database Mail
    • PolyBase
    • Suporte para servidores vinculados
    • Dá suporte a novos serviços de nuvem do Azure, como detecção de ameaças

  • SQL Server na Máquina Virtual do Azure – Use-o se a área da superfície do aplicativo estiver no escopo da instância e exigir recursos não disponíveis na Instância Gerenciada de SQL do Azure, como o SSRS (SQL Server Reporting Services), o SSAS (SQL Server Analysis Services) e o SSIS (SQL Server Integration Services).

  • Azure Synapse Analytics – Use-o se você tiver aplicativos que executam consultas complexas em grandes volumes de dados que podem aproveitar o MPP (processamento paralelo em massa) para reduzir os tempos de processamento de consulta.

Para ver a lista de recursos com suporte em cada oferta de PaaS para o SQL, confira Comparação de recursos: Banco de Dados SQL do Azure e Instância Gerenciada de SQL do Azure.

• Escolha da plataforma de destino por custo

  • Banco de Dados SQL do Azure – A natureza de plataforma como serviço do Banco de Dados SQL do Azure reduz consideravelmente os custos de administração e gerenciamento em relação à topologia mais tradicional de IaaS do SQL Server no Azure, pois a maior parte do trabalho necessário é feita silenciosamente em segundo plano pela Microsoft. Em escala, é possível obter uma economia considerável de tempo e esforço.

  • Pools Elásticos do Banco de Dados SQL do Azure – Os Pools Elásticos do Banco de Dados SQL do Azure oferecem uma economia significativa para vários bancos de dados com demandas de uso imprevisíveis. Os recursos de computação são compartilhados, evitando o excesso de provisionamento e reduzindo os custos de manutenção e administração do servidor.

  • Instância Gerenciada de SQL do Azure – A Instância Gerenciada de SQL é oferecida aos clientes que desejam obter um serviço totalmente gerenciado, em que podem migrar facilmente o ambiente local por lift-and-shift com alterações mínimas de configuração. O ambiente oferece um mínimo de 8 núcleos e até 8 TB de armazenamento em uma rede virtual isolada. Essa oferta é excelente para os clientes que desejam acessar rapidamente a nuvem e evitar a sobrecarga de manter máquinas virtuais.

  • SQL Server na Máquina Virtual do Azure – Em comparação com as ofertas de PaaS, o SQL Server em execução nas máquinas virtuais do Azure é fornecido com os custos mais altos de computação, armazenamento e gerenciamento, mas fornece maior controle sobre o SQL Server e a infraestrutura.

  • Azure Synapse Analytics – o Azure Synapse Analytics pode reduzir o custo aproveitando a arquitetura MPP para processar consultas complexas em minutos, em vez de horas.

• Comparação entre as migrações offline e online

  Na fase de planejamento, convém considerar se a migração é offline ou online. Nas migrações offline, o tempo de inatividade do aplicativo começa quando a migração inicia. Para limitar o tempo de inatividade ao necessário para passar para o novo ambiente quando a migração for concluída, use uma migração online. É recomendável que você teste uma migração offline para determinar se o tempo de inatividade é aceitável; caso contrário, faça uma migração online. Além disso, talvez as opções online e offline não estejam disponíveis, dependendo da plataforma Azure escolhida.

Transformação e otimização

A avaliação e o planejamento teriam identificado aspectos dos aplicativos e do banco de dados que exigirão um trabalho pós-migração que transforma ou otimiza um recurso a fim de garantir uma migração bem-sucedida. Normalmente, a transformação envolve trabalho que exige que você corrija ou altere um aspecto de um banco de dados.

A otimização normalmente envolve uma modificação no banco de dados migrado para tirar proveito de um recurso ou otimiza seu uso no Azure.

Por exemplo, uma transformação pode envolver a modificação de um procedimento armazenado ou de uma consulta SQL que contém uma sintaxe sem suporte no banco de dados de destino. Isso exigirá um ajuste da sintaxe para garantir a compatibilidade com a nova plataforma de banco de dados, garantindo que a consulta ou o procedimento armazenado seja executado perfeitamente e sem problemas no ambiente de destino.

• Transformar

  Para garantir uma experiência pós-migração bem-sucedida, talvez uma ou mais das alterações a seguir precisem ser feitas em um banco de dados.

  • Instalar atualizações de versão de pré-migração

  • Corrija os erros identificados pelas ferramentas de avaliação de migração

  • Implementar alterações de esquema de banco de dados

  • Migrar serviços de banco de dados integrados existentes para o Azure

  • Manipulação de cargas de trabalho do SSIS na nuvem

• Otimizar

  Pode haver uma ou mais das seguintes diretrizes de otimização que você desejará seguir durante a migração para garantir que sua organização esteja obtendo o máximo de seus investimentos no Azure.

  • Avaliar quais novos recursos podem estar disponíveis na plataforma de destino

  • Reestruturar as cargas de trabalho em conjuntos mais econômicos ou mais efetivos para o desempenho

  • Escolher o nível de serviço e o nível de desempenho mais altos durante a migração e reduzi-los verticalmente após a conclusão da migração

  • Garantir que as cargas de trabalho estejam no tamanho correto

  • Minimizar a distância entre o arquivo BACPAC e o data center de destino

  • Desabilitar estatísticas automaticamente durante a migração

  • Índices e tabelas de partição

  • Descartar exibições indexadas e recriá-las após a conclusão

Migrar, validar e corrigir

Essa fase envolve a migração propriamente dita e é importante para as etapas de validação e as etapas de correção necessárias para confirmar uma migração bem-sucedida. As fases anteriores de planejamento, avaliação e transformações garantiram que tudo está pronto para ser migrado e funcionando corretamente, após a migração para o Azure. Tudo o que resta a fazer é preparar as ferramentas de migração necessárias, fazer a migração e executar validações funcionais e de desempenho pós-migração, a fim de garantir a consistência dos dados com o banco de dados de origem.

Considerações sobre migração, validação e correção

Há uma ampla variedade de ferramentas que podem ser usadas para fazer a migração para a plataforma de destino selecionada. Essas ferramentas serão abordadas em outros módulos. Enquanto isso, é importante considerar o seguinte ao realizar a migração:

• Entenda seus requisitos de carga de trabalho como um ponto de partida
• Selecione cargas de trabalho não críticas ou bancos de dados de baixa prioridade para a migração inicial
• Execute um teste de migração
• Teste o banco de dados em relação a problemas
• Teste o plano para reduzir o risco associado a problemas de tempo de inatividade e compatibilidade
• Avalie as ferramentas de migração com base na interrupção para ajudar a reduzir o risco de tempo de inatividade do banco de dados
• Itere continuamente em seu processo de migração
• Considere as janelas de manutenção disponíveis para o aplicativo e o banco de dados destinados à migração
• Coloque os aplicativos e bancos de dados antigos offline
• Aplicativo de terceiros
• Crie novos planos de manutenção e recuperação de desastres