Considerações para migração

24 minutos

Um sistema de negócios executado no local pode ter uma arquitetura acoplada a outros serviços que operam no mesmo ambiente. É importante entender as relações entre um sistema que você deseja migrar e os outros aplicativos e serviços que sua organização está usando no momento.

Em sua empresa start-up de tecnologia, o banco de dados de fornecedores é usado para garantir que os componentes estejam sempre em estoque e cheguem just-in-time para seu uso no processo de fabricação. Os controladores de estoque usam dispositivos móveis para atualizar esse banco de dados à medida que as remessas chegam e os compradores usam um site para monitorar os níveis de estoque e identificar o melhor momento para fazer o pedido. Os gerentes usam um conjunto de relatórios críticos para os negócios para monitorar o processo e melhorar a eficiência. Você deseja garantir que nenhum desses usuários seja afetado negativamente pela migração para o Azure.

Aqui, você aprenderá como planejar e executar uma migração suave de banco de dados para a nuvem.

Investigar dependências

Num sistema complexo, um componente raramente funciona de forma totalmente independente. Em vez disso, ele faz chamadas para outros processos e componentes. Os bancos de dados, por exemplo, podem depender de serviços de diretório que hospedam contas de usuário. Quando você move um banco de dados para a nuvem, você pode acessar esse serviço de diretório? Se não, como os usuários entrarão? Quando você ignora uma dependência como essa, pode haver uma falha total do banco de dados.

Para reduzir os riscos, verifique se seu banco de dados depende de serviços como os seguintes:

Serviços de diretório, como o Ative Directory.
Outras lojas de entidades de segurança.
Outras bases de dados.
APIs da Web ou outros serviços de rede.

Lembre-se também de que outros componentes podem depender do seu banco de dados. Se você mover o banco de dados sem reconfigurar os componentes dependentes, quais são as consequências? Por exemplo, se você mover um banco de dados de catálogo de produtos e o site voltado para o público depender dele para determinar quais produtos apresentar aos usuários, a mudança causará uma interrupção no serviço?

Verifique se algum desses tipos de componente depende do seu banco de dados:

Sites e APIs da Web.
Aplicativos cliente, como aplicativos móveis e software de desktop.
Outras bases de dados.
Relatórios.
Armazéns de dados.

Para fazer essas verificações, converse com as partes interessadas, administradores e desenvolvedores envolvidos com cada banco de dados e componente do sistema. Consulte a documentação e, se não tiver certeza de que entende o comportamento dos sistemas, considere a execução de testes, como capturas de rede para observar o comportamento.

Prepare-se para voltar

Em qualquer projeto de migração, você deve estar sempre preparado para uma falha. Em um projeto de migração de banco de dados para a nuvem, a pior eventualidade é que o novo banco de dados fique indisponível e os usuários não possam fazer seus trabalhos. É comum mitigar esse risco, que pode ter um grande impacto na rentabilidade da sua empresa, planejando reverter para o banco de dados original e não modificado no local.

Para o plano de recurso, considere:

Como garantir que você possa retornar a um banco de dados que não foi afetado pela migração com falha? Por exemplo, é altamente recomendável fazer um backup completo do banco de dados, antes de iniciar a migração.
Por quanto tempo é aceitável que o banco de dados fique offline, se você precisar voltar?
Quanto orçamento tem para o plano de recurso? Por exemplo, você pode se dar ao luxo de replicar o banco de dados para um servidor de fall-back dedicado? Em caso afirmativo, você pode desativar esse servidor imediatamente antes da migração. Para voltar, você inicializa este servidor. Você teria imediatamente um banco de dados que não é afetado pela migração, sem ter que restaurá-lo a partir do backup.

Migração offline versus online

Para migrar um banco de dados, você tem pelo menos duas opções:

Nota

A opção online não está atualmente disponível para bancos de dados MySQL no Serviço de Migração de Dados.

Pare o sistema, transfira o banco de dados e, em seguida, reconfigure e reinicie o sistema para usar o novo banco de dados. Esta é uma migração offline.
Mantenha o sistema em execução enquanto você move o banco de dados para seu novo local, reverta as transações que estão sendo executadas no banco de dados original para o novo banco de dados enquanto a migração está prosseguindo e, em seguida, alterne seus aplicativos para se conectar ao novo banco de dados. Esta é uma migração online.

É mais simples executar uma migração offline, onde os usuários não podem alterar os dados enquanto a migração ocorre. No entanto, se o banco de dados estiver ocupado ou for crítico para o sucesso da organização, isso pode não ser possível.

Migrações offline

Suponha que seu banco de dados suporte uma equipe de analistas que trabalham em um único fuso horário durante o horário comercial normal. A equipe geralmente não trabalha nos fins de semana. Entre as 18:00 de sexta-feira e as 9:00 de domingo, a base de dados não é frequentemente utilizada.

Nessa situação, você pode fazer uma migração offline no fim de semana, seguindo estas etapas:

Coloque o banco de dados offline, depois que todas as transações forem concluídas na sexta-feira à noite.
Faça um backup completo ou exporte o banco de dados.
Desligue o servidor local e mantenha-o caso precise voltar.
Restaure o banco de dados no sistema de nuvem de destino.
Coloque o sistema de destino online.
Reconfigure os clientes para se conectarem ao banco de dados na nuvem.

Nesse caso, uma migração offline é possível porque há um longo período em que uma interrupção no serviço tem pouco efeito sobre os usuários. Durante esse tempo, você pode fazer um backup e restauração completos do banco de dados, sabendo que não perderá nenhuma alteração.

Migrações online

Agora, considere outro banco de dados que ofereça suporte a um aplicativo de vendas. A equipe de vendas está distribuída pelo mundo e também trabalha nos fins de semana. Não há um período de baixa atividade, o banco de dados está sempre ocupado e, se você colocar o banco de dados offline por um período significativo, isso afetará os usuários. A atividade de vendas é crítica para os negócios, portanto, uma interrupção no serviço terá um efeito direto nos resultados da organização.

Em casos como este, considere realizar uma migração online. Em uma migração online, o tempo de inatividade é limitado ao tempo necessário para alternar para o novo banco de dados. Use uma ferramenta como o Serviço de Migração de Dados do Azure para executar uma migração online. As migrações online têm as seguintes diferenças em relação às migrações offline:

Você não move o banco de dados original offline antes de fazer um backup ou exportar.
Enquanto a migração está em andamento, as alterações se aplicam ao banco de dados antigo.
A ferramenta de migração garante que essas alterações sejam copiadas para o novo banco de dados antes da alternância. Isso geralmente é conseguido reconfigurando o banco de dados antigo para replicar as alterações no novo.

Migração de aplicações

Depois de migrar um banco de dados, como (e quando) você deve cortar para o novo sistema e atualizar os aplicativos para usar o novo banco de dados? Você pode:

Mova os aplicativos um a um para o novo banco de dados.
Mover subconjuntos de usuários.
Adote uma combinação de ambas as abordagens.

A intenção é que você execute a migração de aplicativos em pequenos estágios que podem ser facilmente revertidos se algo der errado. Independentemente de ter seguido uma abordagem offline ou online para a migração de banco de dados, você ainda deve ter uma configuração de trabalho localizada na origem original. Em teoria, você poderá voltar para a fonte original rapidamente. Mas se os dados estão em constante mudança, você precisa considerar onde essas alterações foram feitas.

Em uma migração offline, a origem e os destinos são independentes um do outro. Os usuários e aplicativos podem não ver mais uma exibição consistente dos dados. Num sistema transacional, esta situação é suscetível de ser inaceitável. Nesse caso, você precisaria manter alguma forma de replicação bidirecional entre bancos de dados enquanto ambos os sistemas permanecem ativos. Alternativamente, se o objetivo de um aplicativo é gerar relatórios mensais ou semanais, gerar projeções de vendas ou realizar outras operações estatísticas, essa falta de consistência pode não ser tão preocupante. Tais aplicações têm uma "visão de longo prazo" dos dados, em vez de dependerem de dados atualizados. Neste último caso, os aplicativos transacionais usam o novo banco de dados, enquanto os aplicativos de relatório são movidos mais lentamente.
Em uma migração online, o novo banco de dados é mantido sincronizado com o antigo, geralmente por alguma forma de replicação. O processo de replicação pode ser assíncrono, portanto, pode haver um atraso. No entanto, as alterações feitas nos dados do novo banco de dados não serão propagadas de volta ao antigo, resultando em possíveis conflitos. Um aplicativo executado no banco de dados antigo pode fazer uma alteração conflitante nos dados que foram modificados no novo banco de dados. A replicação substituirá cegamente a alteração no novo banco de dados, resultando em uma "atualização perdida".

Abordagens aos testes

Se o banco de dados desempenhar um papel crítico em sua empresa, as consequências de uma falha podem ser extensas. Para aumentar sua confiança de que isso não acontecerá, considere executar testes de desempenho no banco de dados migrado para garantir que ele lide com a carga que os usuários podem colocar sobre ele e responda rapidamente. Lembre-se que pode haver períodos de pico de atividade, quando a demanda é muito maior do que o normal. Você deve ter certeza de que o sistema migrado lida com a carga de trabalho esperada.

Sempre execute algum tipo de teste de regressão em relação ao novo banco de dados antes de permitir o acesso aos usuários. Esses testes verificarão se o comportamento e a funcionalidade do sistema estão corretos.

Além disso, você deve considerar a execução de um "teste de imersão". Um teste de imersão é um teste de carga projetado para ver como o sistema como um todo opera sob pressão. Um teste de imersão enfatiza o novo banco de dados e determina se ele é estável sob alta demanda. Um teste de imersão é executado durante um período de tempo significativo para ver o que acontece quando a alta demanda persiste.

Depois de estabelecer que o novo sistema é estável, você pode começar a migrar usuários. No entanto, você pode precisar de garantia adicional de que os usuários acharão o novo sistema aceitável. Neste ponto, você pode considerar "teste de canário". Um teste canário direciona de forma transparente um pequeno subconjunto de usuários para o novo sistema, mas eles não estão cientes de que estão acessando-o. É uma forma de teste cego, destinado a permitir que você encontre quaisquer problemas ou problemas com o novo sistema. Monitore as respostas desses usuários e faça os ajustes necessários.

Manutenção de sistemas paralelos

Há várias razões pelas quais você pode optar por executar o banco de dados local antigo em paralelo com o novo banco de dados na nuvem:

Períodos de teste. Como você viu no tópico anterior, é uma boa ideia executar testes canários no banco de dados migrado para avaliar sua funcionalidade, estabilidade e capacidade antes de usá-lo para dar suporte a pessoas. Manter o sistema local em paralelo oferece uma maneira rápida de reverter os usuários para o sistema antigo se houver problemas com o novo sistema.
Migrações faseadas. Uma maneira de mitigar o impacto de falhas inesperadas na produção é mover um pequeno número de usuários para o novo sistema primeiro e monitorar os resultados. Se tudo correr bem, você poderá mover outros grupos de usuários à medida que ganha confiança no novo banco de dados. Você pode mover os usuários em ordem alfabética, por departamento, por local ou por função, até que todos estejam no novo banco de dados.
Migrações fragmentadas. Outra abordagem é segmentar a migração não por usuário, mas por carga de trabalho. Por exemplo, você pode migrar as tabelas de banco de dados que dão suporte a recursos humanos, antes daquelas que dão suporte a vendas.

Em todos esses casos, há um período em que o banco de dados local antigo é executado em paralelo com o novo banco de dados em nuvem. Você deve garantir que as alterações feitas no banco de dados antigo também sejam aplicadas ao novo banco de dados e que elas fluam na direção oposta. Você pode criar um script para essa sincronização ou usar uma ferramenta como o Serviço de Migração de Dados do Azure.

Se você decidir manter bancos de dados paralelos e sincronizar alterações, faça a si mesmo estas perguntas:

Resolução de conflitos. É provável que uma alteração em uma linha local aconteça em um momento semelhante a uma alteração diferente na mesma linha na nuvem? Isso criaria um conflito, onde não está claro qual mudança deve ser mantida. Como resolveria tais conflitos?
Tráfego de rede. Quanto tráfego de rede será gerado enquanto as alterações são sincronizadas entre bancos de dados? Você tem capacidade de rede suficiente para esse tráfego?
Latência. Quando há uma alteração em um dos bancos de dados, que atraso (se houver) é aceitável antes que essa alteração chegue ao outro banco de dados? Por exemplo, em um catálogo de produtos, talvez seja possível aguardar até um dia até que os novos produtos fiquem visíveis para todos os usuários. No entanto, se o banco de dados incluir informações transacionais críticas, como taxas de câmbio, esses dados devem ser sincronizados com muito mais frequência, se não instantaneamente.

Migração fragmentada

Uma migração fragmentada é onde você divide um sistema completo em cargas de trabalho e migra uma carga de trabalho de cada vez.

Várias bases de dados

Um sistema complexo pode incluir vários bancos de dados que suportam várias cargas de trabalho. Por exemplo, os recursos humanos podem usar o banco de dados StaffDB, enquanto a equipe de vendas pode ter aplicativos móveis que consultam o banco de dados ProductCatalogDB e o banco de dados OrdersDB.

Claro, você pode optar por migrar todo o sistema de banco de dados para a nuvem de uma só vez. Isso pode ser mais simples, porque você não precisa executar bancos de dados locais e na nuvem. Você não precisa considerar como esses bancos de dados se comunicam durante a migração. No entanto, os riscos de fracasso são maiores. Um único problema pode afetar tanto a equipe de recursos humanos quanto a equipe de vendas.

Considere reduzir esses riscos para sistemas de banco de dados de médio e grande porte executando uma migração fragmentada, na qual você move uma carga de trabalho de cada vez. Neste exemplo, você pode considerar migrar o banco de dados StaffDB primeiro, porque os problemas associados a uma falha seriam limitados à equipe de recursos humanos e não o impediriam de receber pedidos. Ao resolver quaisquer problemas que surjam com a migração do StaffDB, você aprenderá lições que se aplicam a outras migrações de carga de trabalho.

Em seguida, você pode pensar em migrar a carga de trabalho do Catálogo de Produtos para a nuvem. Se o fizer, considere questões como:

Como você garante que os produtos recém-adicionados ao catálogo estejam disponíveis para pedido?
Você precisa sincronizar algum dado com o banco de dados OrdersDB , que permanece no local?
Que latência é aceitável para que novos produtos cheguem ao banco de dados OrdersDB a partir do catálogo de produtos?

Migrações fragmentadas de banco de dados único

Mesmo que você tenha apenas um único banco de dados que suporte todas as cargas de trabalho, ainda poderá considerar uma migração fragmentada. Por exemplo, você pode dividir o banco de dados em partes como esta:

Tabelas que suportam operações de RH.
Tabelas que suportam vendas.
Tabelas que suportam análises e relatórios.

Se você migrar as tabelas de operações de RH primeiro, qualquer problema que surja afetará apenas o pessoal de RH. Os analistas de vendas e de dados continuam a trabalhar no banco de dados antigo sem interrupção.

Antes de executar uma migração fragmentada, você deve entender completamente os bancos de dados e como eles são usados pelos aplicativos. Por exemplo, algumas tabelas em seu banco de dados podem oferecer suporte a vendas e relatórios. Isso significa que você não pode dividir as cargas de trabalho de forma limpa. Você deve sincronizar essas tabelas entre bancos de dados locais e em nuvem, até que todas as cargas de trabalho tenham sido migradas.

Questões de segurança

Seus bancos de dados podem conter dados confidenciais, como detalhes de produtos, informações pessoais da equipe e detalhes de pagamento, portanto, a segurança é sempre uma alta prioridade. Você deve decidir como proteger esses dados durante a migração e no novo banco de dados.

Proteção por firewall

Em um aplicativo conectado à Internet, os servidores de banco de dados geralmente são protegidos por pelo menos dois firewalls. O primeiro firewall separa a Internet dos servidores front-end, se esses servidores hospedarem sites ou APIs da Web, por exemplo. Somente a porta TCP 80 deve estar aberta no firewall externo, mas essa porta deve estar aberta para todos os endereços IP de origem, exceto endereços bloqueados.

O segundo firewall separa os servidores front-end dos servidores de banco de dados. É recomendável publicar o serviço de banco de dados em um número de porta privada que não é conhecido pelo mundo exterior. No segundo firewall, abra esse número de porta apenas para os endereços IP dos servidores front-end. Esse arranjo impede qualquer comunicação direta de um usuário mal-intencionado da Internet com os servidores de banco de dados.

Se você planeja migrar servidores de banco de dados para máquinas virtuais do Azure, use uma rede virtual com NSGs (Grupos de Segurança de Rede) para replicar regras de firewall. Se você usar o Banco de Dados do Azure para MySQL, o Banco de Dados do Azure para MariaDB ou o Banco de Dados do Azure para PostgreSQL, poderá criar regras de firewall para proteger o banco de dados usando a página Segurança de conexão para o servidor no portal do Azure.

Autenticação e autorização

Na maioria dos bancos de dados, você precisa controlar de perto quem acessa e modifica quais dados. Esse controle requer que os usuários sejam identificados positivamente quando se conectam ao banco de dados. Esse processo é chamado de autenticação e geralmente é feito com um nome de usuário e senha. Sistemas de banco de dados como MySQL, MariaDB e PostgreSQL fornecem seus próprios mecanismos de autenticação. Você deve garantir que continua a autenticar os usuários com segurança ao migrar seus sistemas para a nuvem.

Nota

O Banco de Dados do Azure para MySQL, o Banco de Dados do Azure para MariaDB e o Banco de Dados do Azure para serviços PostgreSQL emulam a autenticação tradicional MySQL, MariaDB e PostgreSQL.

Quando você sabe quem é o usuário, você deve atribuir-lhe permissões para concluir as tarefas que fazem parte de seu trabalho. Esse processo é chamado de autorização.

Para um projeto de migração de banco de dados, você precisa certificar-se de que os usuários estão autorizados corretamente no banco de dados em nuvem:

Descubra onde as contas de usuário são armazenadas no sistema local. No MySQL, as user contas de usuário geralmente são armazenadas na tabela do banco de dados, mas é possível, por exemplo, integrar com contas de mysql usuário armazenadas no Ative Directory.
Obtenha uma lista de todas as contas de usuário. No MySQL, por exemplo, você pode usar este comando:
```
SELECT host, user FROM mysql.user;
```
Para cada conta de usuário, descubra qual acesso eles têm ao banco de dados. No MySQL, por exemplo, você pode usar este comando para a conta de dbadmin@on-premises-host usuário:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Recrie cada conta de usuário no banco de dados na nuvem. No MySQL, por exemplo, você pode usar este comando para criar uma nova conta:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorize cada conta de usuário para o nível correto de acesso no banco de dados em nuvem. No MySQL, por exemplo, você pode usar este comando para permitir que um usuário acesse o banco de dados completo:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Encriptação

À medida que os dados são enviados pela rede, eles podem ser intercetados por um ataque chamado "man-in-the-middle". Para evitar isso, o Banco de Dados do Azure para MySQL, o Banco de Dados do Azure para MariaDB e o Banco de Dados do Azure para PostgreSQLoferecem suporte ao SSL (Secure Sockets Layer) para criptografar comunicações. O SSL é imposto por padrão e é altamente recomendável que você não altere essa configuração.

Talvez seja necessário alterar as configurações de conexão dos aplicativos cliente para usar a criptografia SSL. Discuta este tópico com seus desenvolvedores para determinar as alterações, se houver, que são necessárias.

Monitorização e gestão

Parte do planejamento da migração de um banco de dados é considerar como os administradores de banco de dados continuarão a executar suas tarefas após a migração.

Monitorização

Os administradores de banco de dados locais são usados para monitorar regularmente para detetar problemas como gargalos de hardware ou contenção para acesso à rede. Eles monitoram para garantir que possam corrigir quaisquer problemas antes que a produtividade seja afetada. Você pode esperar que qualquer banco de dados que não seja monitorado regularmente comece a causar problemas mais cedo ou mais tarde.

Você deve adotar exatamente a mesma abordagem para bancos de dados em nuvem. Pode ser mais fácil resolver problemas em um sistema PaaS como o Azure, porque você pode adicionar recursos sem comprar, configurar e configurar qualquer hardware. No entanto, você ainda precisa detetar problemas em desenvolvimento, portanto, o monitoramento é uma alta prioridade entre suas tarefas diárias.

Antes de migrar bancos de dados para a nuvem, descubra quais ferramentas de monitoramento seus administradores usam atualmente. Se essas ferramentas forem compatíveis com a solução baseada em nuvem proposta, talvez você só precise reconectá-las aos bancos de dados migrados. Caso contrário, deve investigar alternativas.

Lembre-se de que o Azure inclui um conjunto de ferramentas de monitoramento de desempenho e coleta uma ampla variedade de contadores de desempenho e dados de log. Você exibe esses dados usando painéis e gráficos no portal do Azure, configurando o Azure Monitor. Você cria gráficos, tabelas e relatórios personalizados, projetados especificamente para as necessidades de seus administradores.

Gestão

Os administradores de banco de dados usam ferramentas preferidas para alterar o esquema e o conteúdo do banco de dados local. Se eles usarem as mesmas ferramentas após a migração, você poderá continuar a se beneficiar de sua experiência. Comece avaliando se o conjunto de ferramentas existente é compatível com o banco de dados hospedado na nuvem proposto. Muitas ferramentas serão compatíveis porque se baseiam em padrões amplamente adotados, como SQL, mas é importante verificar essa compatibilidade. Se as ferramentas de gerenciamento atuais não funcionarem após a migração, tente identificar alternativas com os administradores.

O Azure inclui várias ferramentas que você pode usar para administrar bancos de dados MySQL, MariaDB e PostgreSQL:

Portal do Azure. Este site tem recursos poderosos que você usa para configurar, monitorar e gerenciar bancos de dados — e todos os outros recursos que você pode criar na nuvem do Azure.
Azure PowerShell. Este é um ambiente de execução de script e linguagem que tem um amplo conjunto de comandos. Use o PowerShell, que está disponível para ambientes Windows e Linux, para automatizar tarefas administrativas complexas de banco de dados.
CLI do Azure. Esta é uma interface de linha de comando para o Azure. Use-o para gerenciar serviços e recursos no Azure. Você pode usar a CLI a partir dos ambientes shell Windows e Linux e de scripts Bash.

Continuar