Analisar os critérios de decisão para seleção de ferramentas e modelo de migração
Agora que exploramos as opções de metodologias de migração e opções de ferramentas, podemos explorar os critérios de decisão que precisamos considerar para executar nossas migrações para o Banco de Dados do Azure para o Servidor Flexível PostgreSQL. Os três principais critérios que nos ajudam a fazer nossas escolhas são Tempo de inatividade, Local do banco de dados de origem e Personalização.
Inatividade
O tempo de inatividade é uma faceta fundamental das atividades de migração e a duração aceitável para as partes interessadas nos ajuda a decidir se temos que realizar uma atividade de migração offline ou online.
Normalmente, as atividades de migração são planeadas com bastante antecedência para assegurar que os controlos de alterações adequados e a governação associada são concluídos para a atividade. Esse planejamento permite um diálogo com as principais partes interessadas para entender por quanto tempo o sistema pode ficar offline. Nessa situação, é aconselhável saber quanto tempo leva para as diferentes opções que você pode estabelecer durações mínimas e máximas estimadas de tempo de inatividade.
Estabelecer o tempo mínimo de inatividade necessário para executar uma transferência de aplicativo é fundamental. Em última análise, esse tempo é a quantidade que você tem para colocar o sistema off-line, mesmo para uma atividade de migração on-line (ou tempo de inatividade mínimo). A complexidade da aplicação vai ditar este calendário. Para um aplicativo relativamente simples, esse processo pode ser um caso de parar um serviço, atualizar um arquivo de configuração e, em seguida, ativá-lo novamente. Em ambientes mais complexos, esse processo pode levar muito mais tempo se houver vários servidores e camadas de aplicativos em jogo.
Compreender a duração necessária para as atividades de migração online ou offline é o próximo elemento importante relacionado ao tempo de inatividade. Se for uma migração offline, o tempo necessário para extrair, transferir e carregar os dados da origem para o destino, seguido de validação e verificação, é o seu tempo de inatividade. Esse tempo de inatividade é então dividido entre o tempo necessário para desligar o aplicativo/carga de trabalho e o tempo necessário para ativar o aplicativo/carga de trabalho novamente.
Se for uma migração online (tempo de inatividade mínimo), o tempo de inatividade é a duração necessária para sincronizar as alterações finais da origem para o destino, uma vez que o aplicativo é desligado. Adicione a esse tempo de inatividade, as atividades de validação e verificação antes de reconfigurar e habilitar o aplicativo/carga de trabalho.
Uma vez que tenhamos essas informações, podemos olhar para os elementos técnicos da migração para ajudar a estabelecer quais são as nossas opções viáveis.
Local do banco de dados de origem
O local de origem dos bancos de dados a serem migrados desempenha um papel devido às restrições que provavelmente estarão em vigor para qualquer configuração.
Fontes locais ou não do Azure
Para um banco de dados local ou não localizado no Azure, a restrição de chave normalmente é a conectividade de rede entre a origem e o destino. Os três pontos a considerar aqui são largura de banda, latência e volume de dados. Uma vez compreendidos estes pontos, podemos tomar uma decisão informada sobre que tipo de migração é viável.
Se tivermos um grande volume de dados para migrar e uma quantidade proporcionalmente pequena de largura de banda, então um simples despejo e restauração provavelmente não será viável. Considerando que se tivermos um grande volume de dados e uma grande quantidade de largura de banda, então é menos preocupante.
Da mesma forma, se for uma migração online onde a sincronização de dados vai ocorrer, a latência é um dos principais fatores. Se a latência for alta, pode haver impactos adversos no desempenho do sistema porque o processo de sincronização leva muito tempo para ser concluído.
Um fator importante a considerar ao migrar de outros provedores de nuvem é se eles cobram pela saída de dados. Se assim for, então ser capaz de minimizar a pegada física dos dados que estão sendo transferidos pode ser uma consideração. Em situações como essa, a tecnologia de compactação pode ser importante para dumps ou fluxos de dados usados para sincronização.
Outros serviços baseados no Azure
Haverá situações em que você deseja migrar de outros serviços baseados no Azure para o Banco de Dados do Azure para o Servidor Flexível PostgreSQL. Esses bancos de dados de origem podem estar em VMs do Azure, contêineres ou possivelmente no Banco de Dados do Azure para Servidor Único PostgreSQL. Em caso afirmativo, há um conjunto diferente de considerações a explorar, mas, ao mesmo tempo, várias oportunidades para se beneficiar de otimizações nos serviços do Azure para esses cenários.
Personalização
A última área de consideração é a quantidade de personalização necessária ou desejada. Essa consideração pode assumir a forma de necessidade de modificar a estrutura do banco de dados de origem para dar suporte à replicação de dados, alternativamente, pode significar como é fácil para você automatizar por meio de scripts.
Um bom exemplo seria automatizar a migração offline de um banco de dados via pg_dump e pg_restore mas, ao mesmo tempo, incluir a compactação e descompactação dos arquivos de despejo.
Tomada de decisões
Agora que passamos pelo processo de coleta de todas essas informações, podemos trabalhar com as partes interessadas para determinar a melhor opção para um determinado cenário. Ao tomar a decisão sobre qual metodologia e tecnologia usar, é importante não apenas trabalhar com as partes interessadas do negócio, mas também com as partes interessadas técnicas. Essa colaboração ajuda a evitar uma situação em que a empresa conduz a uma migração mínima de tempo de inatividade, que a equipe técnica não está em condições de fornecer devido a restrições de pessoal, recursos ou tecnologia.
O importante aqui é gerenciar expectativas e ter um diálogo aberto e honesto. Também é importante garantir que a empresa se aproprie das tarefas de validação que estão fora da competência das equipes técnicas que entregam a migração do banco de dados. Essa validação pode envolver verificações de consistência e validação de dados e testes de experiência do usuário.