Planejar uma migração de dados
Um projeto de modernização de plataforma de dados tem cinco etapas que geralmente são concluídas em ordem.
Em nosso cenário de varejista global, seu conselho 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 otimizada, você precisa entender as fases do projeto em profundidade.
Nesta unidade, você explorará cada um dos cinco estágios com mais detalhes.
Iniciar e descobrir
Os projetos de modernização da plataforma de dados geralmente são iniciados para atender aos requisitos comerciais ou legais. Por conseguinte, é fundamental ter em conta estas necessidades e obter o apoio dos quadros superiores. A primeira etapa é concluir um exercício de descoberta que inclua as seguintes considerações:
Avaliar o ambiente atual
Muitas infraestruturas de TI normalmente evoluirão ao longo de muitos anos, talvez até décadas. Nesse tempo, os negócios e os funcionários podem mudar imensamente, a ponto de não haver mais especialistas nos sistemas que uma organização tem. Em algumas raras ocasiões, as organizações podem até esquecer que ainda têm alguns sistemas existentes.
Verificar dependências entre aplicativos e bancos de dados existentes
Você deve reservar um tempo para entender como seus aplicativos interagem com os bancos de dados existentes em sua rede. Além disso, você também deve entender quaisquer dependências entre bancos de dados que possam existir para que você possa agrupar coletivamente bancos de dados em agrupamentos lógicos. Ao executar 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 tipos de carga de trabalho em servidores de banco de dados identificados fornece informações sobre seu uso. As cargas de trabalho podem ser categorizadas como analíticas (OLAP) ou transacionais (OLTP) com base no fato de serem intensivas em leitura ou gravação. Isso ajuda a decidir para qual tecnologia de plataforma de dados migrar. A categorização adicional pode incluir cargas de trabalho em lote ou de suporte à decisão.
Avaliação
Durante a etapa de avaliação, as informações coletadas durante a fase de descoberta são usadas para conduzir uma avaliação abrangente das cargas de trabalho identificadas para estabelecer o seguinte:
- Quaisquer potenciais bloqueadores de migração
- Quaisquer alterações significativas que exijam correções pós-migração
- Recursos do Azure que as cargas de trabalho podem usar
Você estabelece isso concluindo uma avaliação de carga de trabalho atual e uma avaliação de critérios de carga de trabalho:
Avaliação da carga de trabalho atual
Os servidores e aplicativos 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 sua criticidade para os negócios. Esta etapa também apresenta uma oportunidade para considerar a combinação ou desativação de bancos de dados locais para reduzir o número de bancos de dados a serem migrados e diminuir o custo total de propriedade.
Avaliação dos critérios de carga de trabalho
Na avaliação de critérios de carga de trabalho, você usa as descobertas da avaliação de carga de trabalho atual e define 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 baixo uso fora do horário de pico. Na avaliação de critérios de carga de trabalho, você define um critério de pós-migração, como migrar para um Banco de Dados SQL do Azure com dimensionamento automático para lidar com picos de carga.
Planeamento
A etapa de planejamento de um projeto de modernização da plataforma de dados envolve a determinação da plataforma de destino, da abordagem de migração e dos planos de mitigação para quaisquer 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. | Permanecer | Não fazer nada | Modernização contínua, considerando opções de longo prazo para serviços locais remanescentes. |
| 2. | Realojamento | Migrar para IaaS | Essa abordagem elimina a necessidade de gerenciamento de datacenter e oferece um maior retorno sobre o investimento (ROI) por meio de um menor custo total de propriedade (TCO). |
| 3. | Refatorização | Migração para IaaS ou PaaS com alterações mínimas de aplicativos | Essa abordagem elimina a necessidade de gerenciamento de datacenter e oferece um maior retorno sobre o investimento (ROI) por meio de um menor custo total de propriedade (TCO). Ele também pode permitir uma menor sobrecarga de gerenciamento por meio da consolidação de bancos de dados. |
| 4. | Rearquitetura | Reescrevendo os principais aspetos do aplicativo para usar tecnologias de nuvem | Ele 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. | Reconstruir | Reconstruindo o aplicativo para usar tecnologias PaaS ou sem servidor | A reconstruçã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. | Replace | Substitua o aplicativo por um aplicativo mais recente ou solução SaaS | Considere a abordagem de substituição quando um aplicativo tiver dependências de dispositivos físicos conectados ao servidor ou quando ele se integrar firmemente à infraestrutura local. |
| 7. | Extinguir | Descomissionar aplicativos que não são mais necessários | A abordagem de desativação deve ser considerada quando aplicativos e bancos de dados herdados 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 ganha com a migração.
Opções de destino da plataforma
Há duas opções de alto nível disponíveis para você quando se trata de escolher a plataforma de destino.
Infraestrutura como serviço (IaaS) - Nessa abordagem, você migrará seus dados para uma máquina virtual que tenha o SQL Server instalado.
Plataforma como serviço (PaaS) - Nessa abordagem, você migrará seus dados para um serviço de plataforma de dados que se adapte à sua carga de trabalho. Para cargas de trabalho transacionais, isso envolveria o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure. Para cargas de trabalho do tipo OLAP (Processamento Analítico Online), isso envolveria o Azure Synapse Analytics.
Escolhendo a plataforma de destino por recursos
Banco de Dados SQL do Azure - Use se a área de superfície do aplicativo tiver escopo de 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 alocar recursos de armazenamento e computação para um grupo de bancos de dados, em vez de ter que gerenciar recursos para cada banco de dados individualmente. Além disso, os pools elásticos são mais fáceis de dimensionar do que os bancos de dados únicos, onde o dimensionamento de bancos de dados individuais não é mais necessário devido às alterações feitas no pool elástico.
Banco de Dados SQL do Azure sem servidor - É eficaz 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 pause automaticamente. Você pode escolher entre 1 hora e 7 dias ou desativá-lo. Ao acessar o banco de dados novamente, ele é retomado e só incorre em encargos de armazenamento durante a pausa.
Instância Gerenciada SQL do Azure - Seria apropriada para uso se a área de superfície do aplicativo tiver escopo de instância e exigir recursos não disponíveis no Banco de Dados SQL do Azure, como:
- Agente do SQL
- MSDTC
- DQS
- MDS
- Database Mail (Correio de Base de Dados)
- Polybase
- Suporte para servidores vinculados
- Suporta novos serviços de nuvem do Azure, como a Deteção de Ameaças
SQL Server na Máquina Virtual do Azure - Use se a área de superfície do aplicativo tiver escopo de instância e exigir recursos não disponíveis na Instância Gerenciada SQL do Azure, como SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) e SQL Server Integration Services (SSIS).
Azure Synapse Analytics - Use se você tiver aplicativos que executam consultas complexas em uma grande quantidade de dados que podem tirar proveito do processamento paralelo maciço (MPP) para reduzir os tempos de processamento de consulta.
Para exibir a lista de recursos com suporte em cada oferta de PaaS para SQL, consulte Comparação de recursos: Banco de Dados SQL do Azure e Instância Gerenciada SQL do Azure.
Escolher a 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 ao SQL Server mais tradicional na topologia IaaS do Azure, já que a maioria do trabalho necessário é concluída silenciosamente em segundo plano pela Microsoft. Em escala, pode-se fazer economias consideráveis 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 fornecem economias significativas para vários bancos de dados com demandas de uso imprevisíveis. Os recursos de computação são compartilhados, evitando o provisionamento excessivo e reduzindo os custos de manutenção e administração do servidor.
Instância Gerenciada SQL do Azure - A Instância Gerenciada SQL é oferecida aos clientes que desejam um serviço totalmente gerenciado, onde eles podem facilmente elevar e mudar seu ambiente local com alterações mínimas de configuração. O ambiente oferece um mínimo de 8 núcleos e até 8 TB de armazenamento e fica em uma rede virtual isolada. Essa oferta é ótima para clientes que desejam acessar rapidamente a nuvem e evitar a sobrecarga de manutenção de 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 em máquinas virtuais do Azure vem com custos de computação, armazenamento e gerenciamento mais altos, mas fornece maior controle sobre o SQL Server e a infraestrutura.
Azure Synapse Analytics - O Azure Synapse Analytics pode reduzir seu custo aproveitando a arquitetura MPP para processar consultas complexas em minutos, em vez de horas.
Migrações offline vs. online
Na etapa de planejamento, convém considerar se você faz uma migração offline ou online. Com as migrações offline, o tempo de inatividade do aplicativo começa ao mesmo tempo em que a migração é iniciada. Para limitar o tempo de inatividade ao tempo necessário para reduzir para o novo ambiente quando a migração for concluída, use uma migração online. É recomendável testar 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, as opções online versus offline podem não estar disponíveis dependendo da plataforma Azure selecionada.
Transforme e otimize
Sua avaliação e planejamento teriam identificado aspetos de seus aplicativos e banco de dados que exigiriam trabalho pós-migração que transforma ou otimiza um recurso para garantir uma migração bem-sucedida. A transformação geralmente envolve trabalho que requer que você corrija ou altere um aspeto de um banco de dados.
A otimização normalmente envolve fazer uma modificação no banco de dados migrado para aproveitar um recurso ou otimiza seu uso no Azure.
Por exemplo, uma transformação pode envolver a modificação de um procedimento armazenado ou consulta SQL que contenha sintaxe sem suporte no banco de dados de destino. Isso exigiria ajustar a sintaxe para garantir a compatibilidade com a nova plataforma de banco de dados, garantindo que o procedimento armazenado ou a consulta seja executado sem problemas, sem problemas no ambiente de destino.
Transformar
Para garantir uma experiência pós-migração bem-sucedida, uma ou mais das seguintes alterações podem precisar ser feitas em um banco de dados.
Instalar atualizações de versão de pré-migração
Corrigir quaisquer 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
Lidando com cargas de trabalho do SSIS na nuvem
Optimize
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 aproveitando ao máximo seu investimento no Azure.
Avaliar quais novos recursos podem estar disponíveis na plataforma de destino
Reestruture cargas de trabalho em conjuntos mais econômicos ou de desempenho
Escolha o nível de serviço e a camada de desempenho mais altos durante a migração e reduza a escala após a conclusão da migração
Garantir que as cargas de trabalho tenham o tamanho certo
Minimize a distância entre o arquivo BACPAC e o data center de destino
Desative as estatísticas automáticas durante a migração
Tabelas e índices de partição
Soltar visualizações indexadas e recriá-las depois de concluídas
Migrar, validar e corrigir
Essa fase envolve a migração em si e, principalmente, as etapas de validação e correção necessárias para confirmar uma migração bem-sucedida. Os estágios anteriores de planejamento, avaliação e transformações garantirão que tudo esteja pronto para ser migrado e funcionando corretamente depois de movido para o Azure. Tudo o que resta fazer é preparar as ferramentas de migração necessárias, concluir a migração e executar validações funcionais e de desempenho pós-migração para 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 gama de ferramentas que podem ser usadas para fazer a migração para a plataforma de destino selecionada. Estas ferramentas serão abordadas noutros módulos. Enquanto isso, é importante considerar o seguinte ao concluir a migração:
- Entenda seus requisitos de carga de trabalho como um ponto de partida
- Selecionar cargas de trabalho não críticas ou bancos de dados de baixa prioridade para migração inicialmente
- Executar uma migração de teste
- Banco de dados de teste para problemas
- Teste o plano para reduzir o risco associado a tempo de inatividade e problemas de compatibilidade
- Avalie as ferramentas de migração com base em interrupções para ajudar a reduzir o risco de tempo de inatividade do banco de dados
- Itere continuamente no 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 bancos de dados e aplicativos antigos offline
- Testar aplicativos de terceiros
- Crie novos planos de recuperação de desastres e manutenção