Migração para a Nuvem Sem API: Desvendando os Desafios do Mundo Corporativo

Lembram do programa "Cem Perguntas para um Adulto", onde o entrevistado recebe perguntas diretas e desconfortáveis, impossíveis de responder com evasivas? Acredito que esse formato é excelente para interagir com a equipe de desenvolvimento. Especialmente quando se trata de defender soluções não padronizadas para os líderes técnicos – como a migração sem o uso da API da nuvem.

No mundo ideal, a migração funciona perfeitamente: o controlador se conecta à plataforma via API, cria redes automaticamente, implanta máquinas e transfere dados. Na realidade desafiadora de grandes empresas, esse esquema frequentemente falha: a nuvem de destino pode ser "feita sob medida" e não ter os métodos necessários, ou os profissionais de segurança se recusam a permitir que software de terceiros entre em um contêiner fechado. Para trabalhar sob essas restrições, usamos o modo Direct2Target (D2T). Essa é uma abordagem em que os dados são transferidos diretamente para os discos de uma VM pré-preparada, ignorando completamente a integração com a camada de gerenciamento da nuvem.

Na teoria, o conceito soa elegante, mas os engenheiros logicamente têm ceticismo sobre a física do processo. Decifrei uma sessão técnica de nosso recente webinar. É claro que não são cem perguntas, mas deixei a essência – aquelas que os arquitetos mais frequentemente nos fazem: como não utilizar a rede em 100%, como transferir o PostgreSQL "ao vivo" sem perda de consistência, como romper um NAT fechado e o que fazer se a VM de destino não inicializar.

Desempenho e Limitações da Migração

D2T é mais lento do que a migração normal via API – há alguma diferença e ela é significativa? A resposta curta é não, quase não há diferença na própria transferência de dados. A resposta longa – vamos descobrir onde ela poderia surgir em princípio. A integração de API e D2T usam os mesmos canais de comunicação e mecanismos de transferência em bloco. As limitações dependem apenas da largura de banda da rede e da velocidade dos discos da nuvem de destino. D2T é "mais lento" do ponto de vista do trabalho manual do engenheiro ao trabalhar com grandes volumes. Portanto, para cenários em massa, é sempre recomendável mudar para uma integração de API completa, e usar D2T como uma ferramenta para um início rápido e pontual em novas ou fechadas plataformas.

Quais são as limitações para a largura de banda da rede e qual é a utilização dos canais? Não impomos limites artificiais à velocidade. A largura do canal é limitada apenas pela largura de banda da sua rede e pela velocidade de gravação nos discos da nuvem de destino.

No entanto, há uma ressalva importante. Os algoritmos de montagem de blocos no agente de origem e sua remontagem no lado de destino, bem como a passagem de dados pelo nó receptor, criam certas sobrecargas. Por causa disso, é raro utilizar o canal em exatamente 100%. Vale ressaltar que esta é uma característica arquitetônica geral da mecânica de replicação, e não uma limitação específica do modo D2T.

É possível definir um limite para a carga do canal para migração? Sim, é possível. Nas configurações do controlador Akura, há uma opção especial para limitar a largura de banda (definir um limite).

Como isso funciona na prática:

• Por padrão: Se você não definir limites, o processo de replicação pode utilizar todo o canal de rede disponível em 100% para realizar a transferência o mais rápido possível.
• Definindo um limite: O limite é configurado manualmente. Isso é especialmente importante em situações em que o canal de rede é compartilhado com outros processos de trabalho. Definir um limite garante que a migração não "bloqueie" completamente o canal e não paralise o funcionamento do restante da infraestrutura.

É possível migrar VMs grandes (por exemplo, >4 TB)? Não há restrições de tamanho de disco, o sistema funciona no nível de bloco. "Não importa qual disco" – ele simplesmente pega blocos de dados no lado de origem e os envia para o destino. Portanto, o tamanho da máquina virtual e seus discos é limitado apenas pelas capacidades da infraestrutura e da nuvem para onde você está migrando, mas não pela própria Akura.

O que acontece se o plano de migração falhar? É necessário criar a VM de destino novamente? Se a comutação (início da VM de destino) ocorreu com um erro, a sequência exata de ações depende da natureza da falha: se o controlador registrou um erro crítico ou se a máquina simplesmente não conseguiu carregar o sistema operacional após a reinicialização. Dependendo do status do erro, diferentes botões estarão ativos na interface Akura.

Enquanto a automação está em desenvolvimento, o algoritmo geral de recuperação é o seguinte:

1. Na interface Akura, clique na opção que está ativa para o seu tipo de falha: "Desconectar" (Detach) ou "Excluir" (Delete).
2. Na nuvem de destino, exclua a VM receptora danificada. Como as alterações já começaram a ser feitas na máquina durante a comutação (conversão V2V, adição de drivers), para a pureza do processo, ela precisa ser recriada a partir da imagem D2T original.
3. Novamente em Akura, exclua a própria máquina do sistema para que ela retorne ao status "Detectado".
4. Execute um backup completo (Full Backup) e repita o processo de migração.

Já estamos trabalhando na automação desse cenário para que, nas próximas versões, não seja necessário recriar a VM e reiniciar os ciclos manualmente em caso de falhas.

Replicação, Bancos de Dados e Consistência

É possível a replicação bidirecional? Sim. Embora o D2T funcione no nível de bloco (discos inteiros), para PostgreSQL e outros SGBDs, temos uma solução separada – um agente de arquivo. Ele funciona no nível do sistema operacional, usa scripts de automação nativos e sabe como preparar o banco de dados para migração sem parar. Isso garante a consistência, mesmo para sistemas de alta carga ou particionados.

Replicação ao vivo apenas de VM? Quais opções para PostgreSQL / SGBD? É possível replicar bancos de dados particionados? Não, a replicação ao vivo está disponível não apenas para máquinas virtuais (no nível de bloco), mas também para bancos de dados (no nível de arquivo). Para trabalhar com SGBDs (incluindo PostgreSQL e bancos de dados particionados), a equipe tem outra solução – um agente de arquivo separado. O modo Direct2Target (D2T), que está sendo discutido no artigo, resolve uma tarefa diferente e funciona com VMs no nível de bloco.

SGBDs podem ser replicados "ao vivo", não é necessário "estacioná-los" (pará-los) manualmente. O agente de arquivo trabalha com bancos de dados no nível "nativo". Scripts de automação especiais são embutidos nele, que "conhecem" a mecânica de trabalho de um determinado SGBD. Esses scripts preparam corretamente o banco de dados para migração (por exemplo, gerenciam o envio de logs WAL no caso do PostgreSQL). O agente de arquivo pode ser reutilizado para qualquer SGBD, se você escrever ou adaptar os scripts de automação correspondentes para sua mecânica.

Quais são os requisitos para a conectividade de rede entre a origem, o agente e a plataforma de destino? D2T funciona em cenários com NAT ou segmentos de rede fechados? Sim, o modo Direct2Target (D2T) funciona em cenários com NAT e em segmentos de rede fechados. O tipo de rede não interfere no funcionamento do D2T. O principal é permitir pontualmente que o controlador e a fonte acessem a máquina de destino pelo IP e portas necessários.

Os requisitos básicos para conectividade de rede se resumem a dois pontos principais:

• Disponibilidade do endereço IP da VM de destino: O principal requisito é fornecer uma rota pela qual o controlador possa alcançar o agente receptor (agente D2T) executado dentro da VM de destino. Se a máquina estiver atrás de um NAT ou em um segmento fechado, ela precisará receber um endereço IP público ou configurar as regras de encaminhamento apropriadas (port forwarding) para que o controlador a "veja" por esse IP.
• Portas abertas:
  • TCP 80: Nesta porta, o agente D2T dentro da máquina de destino escuta as conexões de entrada do controlador (se estiverem em sub-redes diferentes, você precisa configurar as regras de firewall para permitir esse tráfego).
  • TCP 443: Por esta porta, a transferência segura dos próprios dados de replicação da plataforma de origem para o lado de destino é realizada. No momento, o fluxo de dados da plataforma de origem é direcionado para o controlador, e não diretamente para a máquina de destino. Mecanismos de transferência direta de tráfego via HTTPS entre agentes e uma rede distribuída de nós receptores estão em desenvolvimento e ainda não foram implementados.

Como a consistência de bancos de dados "quentes" é garantida no modo D2T? Por si só, o Direct2Target (D2T) não resolve essa tarefa, pois ele se destina a transferir máquinas inteiras no nível dos discos e resolve o problema de se desligar da API da nuvem.

Para garantir a consistência de bancos de dados "quentes" (sem pará-los manualmente), uma abordagem separada é fornecida no sistema – o uso de um agente de arquivo especializado. Assim, a consistência de bancos de dados quentes é garantida não pelo mecanismo D2T, mas pela transição para o uso de um agente de arquivo especializado com scripts para um determinado SGBD.

Como isso funciona:

• Nível de arquivo em vez de nível de bloco: o agente trabalha não com discos inteiros, mas diretamente com arquivos e a mecânica do próprio SGBD (por exemplo, PostgreSQL).
• Scripts de automação: scripts especiais são injetados (embutidos) neste agente de arquivo, que "nativamente" conhecem o mecanismo de trabalho de um determinado banco de dados.
• "Estacionamento" correto (Quiescing): são esses scripts que são responsáveis por preparar o SGBD para replicação "ao vivo" – "estacioná-lo" corretamente (colocá-lo em um estado consistente) e gerenciar processos específicos (por exemplo, enviar logs WAL) enquanto a transferência está em andamento.

É necessário "estacionar" o SGBD antes da migração? Não, não é necessário "estacionar" (parar) o SGBD manualmente se você usar a ferramenta certa. Em vez de parar o sistema manualmente, você pode usar a automação no nível do agente de arquivo, que fará tudo o que for necessário "ao vivo".

Para replicação "ao vivo", um agente de arquivo especial é usado (uma solução diferente do D2T).

• Scripts de automação: Scripts são embutidos neste agente que "nativamente" conhecem a mecânica de um determinado SGBD (por exemplo, PostgreSQL).
• Consistência em tempo real: Esses scripts preparam o banco de dados para migração e garantem sua consistência diretamente durante a operação (por exemplo, gerenciando logs WAL).

Redes, contêineres fechados e por que precisamos de apenas um IP

As redes precisam ser criadas com antecedência? Sim. No modo Direct2Target (D2T), você prepara independentemente a VM receptora de destino antes do início da migração. Consequentemente, a conectividade de rede para esta máquina (seleção da rede necessária, configuração de rotas) também precisa ser garantida com antecedência.

Existe funcionalidade para configurar automaticamente as redes na plataforma de destino? No momento, não. Especificamente na abordagem D2T, o controlador não vai para a API da nuvem e não cria redes ou regras de acesso automaticamente. Na versão atual do agente D2T, o usuário precisa executar manualmente as configurações necessárias no lado da nuvem: por exemplo, anexar um endereço IP público ou configurar as regras de firewall (Grupos de Segurança) para que o controlador Akura possa alcançar o agente.

Em versões futuras, a automação parcial será adicionada.

EVPN / VxLAN é suportado? O agente Direct2Target não se importa com a tecnologia de rede básica usada em sua nuvem (se são VLANs comuns, NAT, VPN, EVPN ou VxLAN). O principal e único requisito do lado da Akura é a presença de roteamento básico (conectividade IP). Se sua rede (incluindo sobreposições como VxLAN) estiver configurada de forma que os pacotes do controlador cheguem ao endereço IP da VM de destino, a replicação funcionará com sucesso.

Na conexão da nuvem D2T, apenas o nome e o armazenamento em bloco padrão são definidos no controlador. Sem pontos de conexão, portas ou credenciais. Nas configurações da própria replicação, o único parâmetro de rede para o lado de destino é o endereço IP do agente d2t na VM de destino. Todo o resto – EVPN/VxLAN/SG/tabelas de rotas – o cliente faz manualmente no lado da plataforma.

É possível criptografar dados de migração? A transferência de dados é feita via padrão HTTPS (porta 443). O tráfego é criptografado in-transit em todo o caminho da fonte para o receptor de destino. Criptografia adicional "dentro" do agente não é necessária, pois os dados não são armazenados nele, mas são imediatamente gravados nos discos de destino.

Você tem um diagrama de fluxos de rede na documentação? Sim.

O diagrama com a arquitetura e todos os fluxos de rede está disponível na documentação oficial.

Arquitetura e Operação do Agente

É possível um modo sem agente? Sim, é possível. A abordagem sem agente é aplicável ao lado de origem da migração (a plataforma de onde você pega as máquinas). Os dados podem ser coletados diretamente no nível do hipervisor. Isso significa que você não precisa "mergulhar em cada máquina" e instalar agentes dentro do sistema operacional convidado de cada VM específica que você planeja transferir.

O que acontece em caso de erro na configuração da VM de destino?

1. Verificação automática: Como no modo D2T a máquina de destino é criada manualmente, o controlador realiza uma validação básica para eliminar o risco de falha. Essa verificação funciona com base no princípio da suficiência:
   • Verificação de recursos de computação: não há uma verificação rígida com os parâmetros da máquina de origem aqui. Na fase de transferência de dados para a máquina de destino, basta ter apenas a quantidade de memória RAM necessária para o funcionamento estável do agente receptor. Os valores de desempenho de computação podem ser definidos após a conclusão da migração e a reinicialização do sistema na nova plataforma.
   • Verificação do subsistema de disco: aqui o controlador verifica a configuração com mais rigor, mas também com base no princípio da suficiência mínima. O número de discos deve ser pelo menos o mesmo que na fonte, e o tamanho de cada disco de destino não deve ser menor que o original. A configuração de destino pode ser maior que a original (os discos podem ser maiores) – a migração será bem-sucedida.
2. Notificação de erro: se uma incompatibilidade for detectada, o controlador notificará o usuário.
3. Prevenção de falhas: o sistema não permitirá que a replicação seja iniciada em uma máquina preparada incorretamente. Isso evita uma situação em que os recursos são gastos em uma transferência deliberadamente malsucedida.

Assim, apesar da presença do "fator humano" durante a preparação manual da VM no modo Direct2Target, as verificações de software sob o capô minimizam o risco de quebra do processo.

Onde o backup é armazenado antes da migração? O que acontece com o backup após a migração? No modo D2T, os dados não são salvos em nenhum armazenamento intermediário do controlador. Eles são transferidos diretamente para a plataforma de destino. O backup é, na verdade, os dados gravados nos discos de destino da própria máquina virtual pré-preparada que você criou manualmente. Os dados do lado de origem (por exemplo, do VMware) são "derramados" pela rede e gravados pelo agente receptor diretamente nos discos preparados na nuvem de destino. Assim, no momento da conclusão da replicação, o estado atual da máquina já está nos discos da VM de destino.

Quando você tiver certeza de que a máquina foi transferida com sucesso e está funcionando, o procedimento de desconexão da migração (Detach) é executado. Depois disso:

• Exclusão de metadados: Akura "esquece" esta máquina e exclui todas as informações de serviço sobre ela de seu banco de dados.
• Limpeza de pontos de recuperação: todos os pontos de recuperação intermediários (snapshots) criados durante a replicação são excluídos.
• Autonomia da VM: a própria máquina virtual na nuvem de destino permanece intacta. Ela continua funcionando, vive sua vida, e Akura não a gerencia mais e não sabe nada sobre ela.

Após a conclusão bem-sucedida (Detach), todos os dados temporários de replicação são limpos, e a VM de destino se torna a principal e independente.

Compatibilidade e Suporte à Infraestrutura

Há suporte para GPU? E quanto aos dispositivos específicos? Sim, há suporte para dispositivos específicos, incluindo GPU. No âmbito da abordagem Direct2Target (D2T), essa questão é resolvida da forma mais flexível possível, porque a preparação do "hardware" é totalmente delegada ao usuário e às capacidades da nuvem de destino.

Como no modo D2T você cria a máquina virtual de destino pré-preparada manualmente, você pode adicionar a ela quaisquer adaptadores e dispositivos que seu provedor de nuvem de destino fornecer. Podem ser GPUs (placas de vídeo), placas de som específicas ou adaptadores de rede especiais.

A Akura não restringe a escolha de hardware de forma alguma. Você escolhe completamente qualquer configuração de máquina e a executa.

Se a plataforma de destino (hipervisor ou nuvem) tiver fisicamente as GPUs necessárias e permitir que elas sejam atribuídas à máquina virtual, você simplesmente seleciona esta instância ao criar a VM manualmente.

Aqui vale a pena fazer uma importante especificação técnica. No processo de conversão V2V, o sistema instala apenas um conjunto padrão (básico) de drivers – exatamente o mínimo necessário para inicializar com sucesso o sistema operacional na nova plataforma. Os drivers para hardware específico não são adicionados automaticamente.

Portanto, se componentes de hardware especiais forem usados no lado de destino (por exemplo, as mesmas placas de vídeo), e não houver drivers correspondentes na máquina de origem, o administrador precisará instalá-los manualmente depois que o sistema migrado for iniciado com sucesso.

Cenários de Uso D2T

Em todos os casos, o D2T não atua como uma substituição da automação completa, mas como uma ferramenta universal para desbloquear projetos que podem ser limitados por barreiras de infraestrutura ou burocráticas.

• Lançamento de projetos piloto (PoC): um teste rápido da nuvem para o cliente sem esperar 6 a 8 semanas para o desenvolvimento da integração.
• Nuvens raras e "feitas sob medida": D2T torna o processo independente da plataforma, você só precisa de acesso à rede e a capacidade de implantar uma imagem.
• Compliance rigoroso: salva em contêineres isolados, onde os profissionais de segurança proíbem que software de terceiros acesse a API da plataforma.
• API instável do fornecedor: contornando as restrições, se a API existir formalmente, mas funcionar incorretamente e não fornecer os recursos necessários.
• Migrações pontuais: transferir alguns servidores pesados, para os quais investir tempo no desenvolvimento de uma integração profunda com a API simplesmente não é econômico.