Considerações sobre a migração

24 minutos

Um sistema comercial com execução local pode ter uma arquitetura que esteja associada 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 start-up de tecnologia, o banco de dados do fornecedor é usado para fazer com que os componentes estejam sempre em estoque e cheguem just-in-time para 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 a melhor hora para fazer o pedido. Os gerentes usam um conjunto de relatórios essenciais para monitorar o processo e melhorar a eficiência. Você quer garantir que nenhum desses usuários será afetado negativamente pela migração para o Azure.

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

Investigar dependências

Em um sistema complexo, um componente raramente funciona totalmente de forma independente. 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, é capaz de acessar esse serviço de diretório? Caso contrário, como os usuários entrarão? Quando você ignora uma dependência assim, pode haver uma falha total no banco de dados.

Para reduzir os riscos, verifique se o banco de dados depende de serviços como o seguinte:

Serviços de diretório, como o Active Directory.
Outros repositórios de entidades de segurança.
Outros bancos de dados.
APIs Web ou outros serviços de rede.

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

Verifique se algum destes tipos de componente dependem de seu banco de dados:

Sites e APIs Web.
Aplicativos cliente, como aplicativos móveis e software de área de trabalho.
Outros bancos de dados.
Relatórios.
Data warehouses.

Para fazer essas verificações, converse com os participantes, os administradores e os desenvolvedores envolvidos em cada componente de banco de dados e sistema. Confira a documentação e, se não tiver certeza de que entendeu o comportamento dos sistemas, pense em fazer testes, por exemplo, capturas de rede para observar o comportamento.

Preparar para fazer fallback

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, o pior cenário é o novo banco de dados ficar indisponível e os usuários não poderem realizar seus trabalhos. É comum reduzir esse risco, que pode ter um grande impacto na rentabilidade da sua empresa, planejando a reversão para o banco de dados original local e não modificado.

Para o plano de fallback, considere:

Como garantir que você possa fazer fallback para um banco de dados que não seja alterado pela migração com falha? Por exemplo, é altamente recomendável fazer um backup completo do banco de dados logo antes de começar a migração.
Por quanto tempo é aceitável ter o banco de dados offline se você precisar fazer fallback?
Qual o orçamento disponível para o plano de fallback? Por exemplo, você pode arcar com a replicação do banco de dados em um servidor de fallback dedicado? Nesse caso, você pode desligar esse servidor imediatamente antes da migração. Para fazer fallback, você inicializa esse servidor. Você teria imediatamente um banco de dados que não foi afetado pela migração sem precisar restaurá-lo do backup.

Migração offline versus online

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

Observação

A opção online não está disponível no momento para bancos de dados MySQL no serviço de migração de dados.

Pare o sistema, transfira o banco de dados, reconfigure e reinicie o sistema para usar o novo banco de dados. Essa é uma migração offline.
Mantenha o sistema em execução enquanto você move o banco de dados para seu novo local, faça roll-forward das transações que são executadas no banco de dados original para o novo banco de dados enquanto a migração está em andamento e, em seguida, alterne seus aplicativos para se conectarem ao novo banco de dados. Essa é uma migração online.

É mais simples fazer uma migração offline, na qual 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 essencial para o sucesso da sua organização, isso poderá não ser possível.

Migrações offline

Suponha que seu banco de dados dê suporte a uma equipe de analistas que trabalham em um único fuso horário durante o horário comercial normal. Normalmente, a equipe não funciona nos fins de semana. Entre 18:00 na sexta-feira e 9:00 no domingo, o banco de dados não costuma ser usado.

Nesse caso, você pode fazer uma migração offline no final de semana seguindo estas etapas:

Coloque o banco de dados offline depois que todas as transações tiverem sido 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 fazer fallback.
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 de 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 completo e restaurar o banco de dados sabendo que não perderá nenhuma alteração.

Migrações online

Agora, considere outro banco de dados que dê 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 atividade baixa; o banco de dados está sempre ocupado e, se você o colocar offline por um período significativo, ele afetará os usuários. A atividade de vendas é comercialmente crítica e, portanto, uma interrupção do serviço terá efeito direto sobre o resultado da organização.

Em casos como esse, considere a execução de uma migração online. Em uma migração online, o tempo de inatividade limita-se ao horário necessário para mudar 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 para migrações offline:

Você não move o banco de dados original offline antes de fazer um backup ou uma exportação.
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 mudança. Isso geralmente é obtido com a reconfiguração do banco de dados antigo a fim de replicar as alterações para o novo.

Migração de aplicativos

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

Mover aplicativos um a um para o novo banco de dados.
Mover subconjuntos de usuários.
Adotar uma combinação das duas abordagens.

O intuito é que você execute a migração de aplicativos em pequenas fases que poderão ser facilmente revertidas se algo der errado. Independentemente de você ter seguido uma abordagem offline ou online para a migração de banco de dados, ainda deverá possuir uma configuração de trabalho localizada na fonte original. Teoricamente, você poderá voltar para a fonte original rapidamente. Mas se os dados estiverem constantemente mudando, você precisará considerar onde essas alterações foram feitas.

Em uma migração offline, a origem e os destinos independem uns dos outros. Os usuários e aplicativos podem não ter mais uma exibição consistente dos dados. Em um sistema transacional, essa situação provavelmente será inaceitável. Nesse caso, você precisa manter alguma forma de replicação bidirecional entre bancos de dados enquanto ambos os sistemas permanecem ativos. Como alternativa, se a finalidade de um aplicativo é gerar relatórios mensais ou semanais, gerar projeções de vendas ou executar outras operações estatísticas, essa falta de consistência pode não ser tão preocupante. Tais aplicativos têm uma “visão mais de longo prazo” dos dados em vez de depender de dados atualizados. Nesse último caso, os aplicativos transacionais usam o novo banco de dados; já os aplicativos de relatório são migrados 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 e, portanto, pode haver um atraso. No entanto, as alterações feitas nos dados no novo banco de dados não serão propagadas para o antigo, o que resulta em possíveis conflitos. Um aplicativo em execução 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, o que resultaria em uma “atualização perdida”.

Abordagens de testes

Se o banco de dados exerce uma função crítica em sua empresa, as consequências de uma falha podem ser extensas. Para aumentar sua confiança de que isso não acontecerá, considere fazer testes de desempenho no banco de dados migrado para ter certeza de que ele consegue lidar com a carga que os usuários poderão gerar e responder rapidamente. Lembre-se de que pode haver períodos de atividade de pico, quando a demanda é muito maior do que o normal. Você precisa ter certeza de que o sistema migrado lidará com a carga de trabalho esperada.

Sempre realize algum tipo de teste de regressão no novo banco de dados antes de permitir o acesso dos usuários. Esses testes verificarão se o comportamento e a funcionalidade do sistema estão corretos.

Além disso, considere executar 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 cansa o novo banco de dados e determina se ele fica estável sob alta demanda. Um teste de imersão é executado em um período de tempo relevante para ver o que acontece quando a alta demanda persiste.

Quando você tiver definido que o novo sistema está estável, poderá 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. Aqui, vale considerar o “teste canário”. Um teste canário direciona de forma transparente um pequeno subconjunto de usuários para o novo sistema, mas sem que estejam cientes disso. É uma forma de teste cego, cujo intuito é permitir que você encontre problemas no 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 antigo banco de dados local em paralelo com o novo banco de dados na nuvem:

Períodos de teste. Como vimos no tópico anterior, é uma boa ideia fazer testes canário no banco de dados migrado para avaliar a funcionalidade, a estabilidade e a capacidade antes de usá-lo para dar suporte a pessoas. A manutenção de um sistema local em paralelo proporciona uma maneira rápida de reverter os usuários para o sistema antigo em caso de problemas com o novo sistema.
Migrações em fases. 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 funcionar sem problemas, 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 por etapas. 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 na 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ê poderia fazer o script dessa 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 as alterações, faça as seguintes perguntas:

Resolução de conflitos. É provável que uma alteração em uma linha local ocorra em um momento semelhante a uma alteração diferente na mesma linha na nuvem? Isso criaria um conflito e não há clareza sobre qual alteração deveria ser mantida. Como você resolveria esses 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, qual atraso (se houver) é aceitável até que essa alteração alcance o outro banco de dados? Por exemplo, em um catálogo de produtos, você poderá aguardar até um dia antes que 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 de moedas, elas deverão ser sincronizadas com muito mais frequência, ou até instantaneamente.

Migração por etapas

Uma migração por etapas ocorre quando você divide um sistema completo em cargas de trabalho e migra uma carga de trabalho de cada vez.

Vários bancos de dados

Um sistema complexo pode incluir vários bancos de dados que dão suporte a várias cargas de trabalho. Por exemplo, o departamento de recursos humanos pode usar o banco de dados StaffDB, mas a equipe de vendas tem aplicativos móveis que consultam o banco de dados ProductCatalogDB e o banco de dados OrdersDB.

É claro que você pode optar por migrar todo o sistema de banco de dados para a nuvem em um só lugar. Isso pode ser mais simples, pois você não precisa executar bancos de dados locais e na nuvem. Você não precisa pensar em como esses bancos de dados se comunicam durante a migração. No entanto, os riscos de falha são maiores. Um único problema pode afetar a equipe de recursos humanos e a equipe de vendas.

Considere a mitigação desses riscos em sistemas de bancos de dados médios e grandes fazendo uma migração por etapas, na qual você move uma carga de trabalho por vez. Neste exemplo, você pode considerar migrar o banco de dados StaffDB primeiro, já que os problemas associados a uma falha ficariam limitados à equipe de recursos humanos e não impediriam você de receber pedidos. Ao resolver problemas que apareceram na migração do StaffDB, você aprenderá lições que poderão ser aplicadas às migrações de outras cargas de trabalho.

Em seguida, você pode pensar em migrar a carga de trabalho Catálogo de Produtos para a nuvem. Se você fizer isso, pense em perguntas como:

Como garantir que os produtos recém-adicionados ao catálogo ficarão disponíveis para pedidos?
Você precisa sincronizar algum dado com o banco de dados OrdersDB, que permanece no local?
Qual latência é aceitável para os novos produtos alcançarem o banco de dados OrdersDB oriundos do catálogo de produtos?

Migrações por etapas de banco de dados individual

Mesmo que você tenha apenas um único banco de dados que dê suporte a todas as cargas de trabalho, ainda pode considerar uma migração por etapas. Por exemplo, você pode dividir o banco de dados em partes como estas:

Tabelas que dão suporte a operações de RH.
Tabelas que dão suporte a vendas.
Tabelas que dão suporte a análise e relatório.

Se você migrar primeiro as tabelas de operações de RH, os problemas surgidos afetarão apenas a equipe de RH. Os analistas de vendas e dados continuam a trabalhar no banco de dados antigo, sem interrupções.

Antes de executar uma migração por etapas, você deve compreender totalmente os bancos de dados e como eles são usados pelos aplicativos. Por exemplo, algumas tabelas em seu banco de dados podem dar suporte a vendas e relatórios. Isso significa que não é possível dividir as cargas de trabalho de forma exata. Você deve sincronizar essas tabelas entre bancos de dados locais e na 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 de funcionários e dados de pagamento, ou seja, segurança tem sempre alta prioridade. Você deve decidir como proteger esses dados durante a migração e no novo banco de dados.

Proteção de 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 quando esses servidores hospedam sites ou APIs Web, por exemplo. Somente a porta TCP 80 deverá estar aberta no firewall externo, mas essa porta deverá estar aberta para todos os endereços IP de origem que não forem 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 da porta privada que não seja conhecido pelo mundo exterior. No segundo firewall, abra esse número da porta somente para os endereços IP dos servidores front-end. Essa disposição impede alguma comunicação direta de um usuário da Internet mal-intencionado 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ê usa 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, pode criar regras de firewall para proteger o banco de dados usando a página Segurança da conexão do servidor no portal do Azure.

Autenticação e autorização

Na maioria dos bancos de dados, você precisa controlar com mais precisão 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 uma senha. Os sistemas de banco de dados, como MySQL, MariaDB e PostgreSQL, fornecem seus próprios mecanismos de autenticação. Você deve garantir que os usuários continuarão sendo autenticados com segurança depois da migração dos sistemas para a nuvem.

Observação

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

Quando você sabe quem é o usuário, precisa atribuir permissões a ele 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 ter certeza de que os usuários estão autorizados corretamente no banco de dados de nuvem:

Descubra onde as contas de usuário ficam armazenadas no sistema local. No MySQL, as contas de usuário geralmente são armazenadas na tabela user do banco de dados mysql, mas é possível, por exemplo, integrar às contas de usuário armazenadas no Active 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 elas têm ao banco de dados. No MySQL, por exemplo, você pode usar este comando para a conta de usuário dbadmin@on-premises-host:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Recrie cada conta de usuário no banco de dados de nuvem. No MySQL, por exemplo, você pode usar este comando para criar a conta:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorize cada conta de usuário a ter o nível correto de acesso no banco de dados de 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'
```

Criptografia

Quando os dados são enviados pela rede, eles podem ser interceptados por um ataque man-in-the-middle. Para evitar isso, o Banco de Dados do Azure para MySQL, o Banco de Dados do Azure para MariaDBe o Banco de Dados do Azure para PostgreSQL dão suporte a protocolo SSL para criptografar as comunicações. O SSL é imposto por padrão e é altamente recomendável que você não altere essa configuração.

Talvez seja necessário corrigir as configurações de conexão de seus aplicativos cliente para que usem a criptografia SSL. Discuta o assunto com seus desenvolvedores para determinar as alterações necessárias, se for o caso.

Monitoramento e gerenciamento

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

Monitoramento

Os administradores de banco de dados local estão acostumados a monitorar regularmente em busca de problemas como gargalos de hardware ou contenção no acesso à rede. Eles monitoram para ter certeza de que poderão corrigir problemas antes que a produtividade seja afetada. Pode esperar que algum banco de dados que não seja monitorado regularmente comece a causar problemas mais cedo ou mais tarde.

Você deve usar exatamente a mesma abordagem para bancos de dados na nuvem. Pode ser mais fácil resolver problemas em um sistema PaaS como o Azure, pois você pode adicionar recursos sem precisar comprar, montar e configurar algum hardware. No entanto, você ainda precisa detectar problemas de desenvolvimento e, portanto, o monitoramento tem 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, você poderá precisar apenas reconectá-las aos bancos de dados migrados. Caso contrário, você deverá investigar as alternativas.

Tenha em mente 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. Exiba esses dados usando painéis e gráficos no portal do Azure com a configuração do Azure Monitor. Crie gráficos, tabelas e relatórios personalizados especificamente projetados para as necessidades de seus administradores.

Gerenciamento

Seus administradores de banco de dados usam ferramentas preferenciais 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 da experiência deles. Comece avaliando se o conjunto existente de ferramentas é compatível com o banco de dados hospedado na nuvem proposto. Muitas ferramentas serão compatíveis porque estão baseadas em padrões amplamente adotados, como o SQL, mas é importante verificar essa compatibilidade. Se as ferramentas de gerenciamento atuais não funcionarem após a migração, tente encontrar alternativas com seus administradores.

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

O portal do Azure. É um site com recursos avançados que você pode usar para configurar, monitorar e gerenciar bancos de dados, além de todos os outros recursos que você possa criar na nuvem do Azure.
Azure PowerShell. É um ambiente de execução de scripts e linguagem que tem um amplo conjunto de comandos. Use o PowerShell, que está disponível em ambientes Windows e Linux, para automatizar tarefas administrativas complexas de banco de dados.
CLI do Azure. É uma interface de linha de comando com o Azure. Use-a para gerenciar serviços e recursos no Azure. Você pode usar a CLI nos ambientes de shell Windows e Linux e dentro de scripts Bash.