Planejamento de ondas de migração para servidores virtuais em IBM Cloud VPC

Planeje as ondas de migração d IBM Cloud VPC mapeando as dependências das máquinas virtuais ( VM ), estimando a velocidade e programando janelas de transição para as pilhas de aplicativos.

Planejamento de dependência

Antes de iniciar suas ondas de migração, você precisa mapear as seguintes dependências de aplicativos:

Baseado em níveis:

  • Camada da Web → Camada de aplicativos
  • Camada de aplicativo → Camada de banco de dados
  • Camada de banco de dados → Armazenamento e serviços compartilhados

Aplicativo cruzado:

  • Autenticação
  • Monitoring
  • Backup
  • Agregação de registros
  • DNS e NTP

Ferramentas para descoberta:

  • VMware vRealize Network Insight ( ) vRNI
  • Ferramentas de mapeamento de dependências de aplicativos
  • Análise de fluxo de rede
  • Documentação manual dos proprietários de aplicativos

Para cada servidor virtual, registre as seguintes informações no seu plano de migração:

  • Dependências de entrada
  • Dependências de saída
  • Recursos compartilhados

Projeto de onda de migração de teste

Sua primeira onda de migração é a onda de teste (piloto). Para implementar uma onda de teste bem-sucedida, você deve seguir as informações a seguir:

Representação adequada de seus servidores virtuais:

  • Servidor virtual “ Linux ” com um único disco
  • Servidor virtual “ Linux ” com vários discos
  • Servidor virtual Windows de disco único
  • Servidor virtual do Windows com vários discos
  • Aplicativo com dependências (aplicativo de 3 camadas)

Use opções de "risco mínimo":

  • Implemente a migração em um ambiente de não produção. Ou use um ambiente de produção que tenha grandes janelas de manutenção.
  • Conheça o procedimento de reversão de seus aplicativos.

Realizar uma migração completa:

  • Teste completo de ponta a ponta de seus métodos escolhidos
  • Observe o tempo de migração versus o tempo estimado
  • Descoberta de problemas que não foram encontrados nos testes

Critérios de migração bem-sucedida:

  • Todos os servidores virtuais são iniciados com sucesso
  • Os aplicativos funcionam corretamente
  • Conectividade de rede verificada
  • O desempenho atende ou excede a linha de base
  • Sem perda ou corrupção de dados
  • A documentação da migração é completa e precisa

Diretrizes de estrutura de ondas

Agrupamento baseado em sub-rede:

Lembre-se de que você não pode estender uma sub-rede entre VMware e a VPC. Isso significa que você precisa realizar as seguintes ações:

  • Agrupar servidores virtuais por sub-rede
  • Migre sub-redes inteiras em uma única onda ou saiba que precisa reIPar alguns servidores virtuais
  • Planejar o mapeamento de sub-rede para sub-rede VPC antecipadamente

Agrupamento de pilhas de aplicativos para aplicativos multicamadas:

  • Migre a pilha inteira em uma única onda, se possível.
  • Se a migração for muito grande, migre primeiro do banco de dados, depois dos aplicativos e assim por diante.
  • Mantenha a conectividade entre as camadas migradas e as não migradas por meio do IBM Cloud Transit Gateway.

Agrupamento de pilhas de aplicativos para sequenciamento com reconhecimento de dependência:

  • Migre primeiro os serviços de infraestrutura (DNS, monitoramento, backup).
  • Migre os serviços compartilhados antes dos aplicativos de que eles precisam.
  • Considere os efeitos de cada onda e o impacto se ela falhar.

Recursos de migração paralela:

O método 3 Transferência de rede ao vivo(Recomendado para o Scale) é excelente aqui:

  • Provisione várias instâncias de servidor virtual de trabalho
  • Migrar vários servidores virtuais simultaneamente
  • Limitado pela largura de banda da rede e pelos recursos da instância do servidor virtual do trabalhador
  • Típico: de 4 a 8 migrações simultâneas por instância de servidor virtual de trabalho

Exemplo de estrutura de onda de teste

O exemplo a seguir mostra uma migração de 50 servidores virtuais.

Onda 0 (teste): 5 servidores virtuais

  • 1x Disco único Linux (teste do Método 1)
  • 1x Vários discos Linux (teste do Método 2)
  • 1x Windows de disco único (Método 1 com sysprep)
  • 1x Windows com vários discos (Método 2 com virt-v2v )
  • 1x aplicativo de teste de três camadas (métodos 2 e 3, pilha completa)

Onda 1 (infraestrutura): 8 servidores virtuais

  • Servidores DNS
  • Monitorando servidores
  • Anfitriões de salto ou servidores de bastião
  • Servidores de arquivos compartilhados que migraram para o armazenamento de arquivos VPC

Onda 2 (aplicativo A): 12 servidores virtuais

  • Camada de banco de dados (3 servidores virtuais)
  • Camada de aplicativos (6 servidores virtuais)
  • Camada da Web (3 servidores virtuais)
  • Sub-rede 10.50.10.0/24 → sub-rede VPC 10.240.10.0/24

Onda 3 (Aplicativo B): 10 servidores virtuais

  • Banco de dados e camada de aplicativos combinados (4 servidores virtuais)
  • Camada da Web (6 servidores virtuais)
  • Sub-rede 10.50.20.0/24 → sub-rede VPC 10.240.20.0/24

Onda 4 (Aplicativo C): 15 servidores virtuais

  • Aplicativo multicamadas de grande porte
  • Sub-rede 10.50.30.0/24 → sub-rede VPC 10.240.30.0/24

Projeto da janela de transição

Cada onda precisa de uma janela de corte bem definida.

Cronograma pré-cutover (7 dias até o dia da migração):

  • Finalizar o plano de ondas e o runbook
  • Confirme a conectividade do site Transit Gateway
  • Provisione instâncias de servidores virtuais de trabalho e volumes de destino
  • Comunicar a janela de transição às partes interessadas
  • Reduzir os TTLs do DNS para serviços que estão migrando
  • Notificar os usuários sobre a janela de manutenção

Execução da migração ( T-0 )

As informações a seguir descrevem as fases de cutover.

Fase 1: Suspender e migrar (horas 0 a 4)

  1. Drenar conexões - remover dos balanceadores de carga e aguardar o fechamento das sessões.
  2. Interrompa os aplicativos de forma graciosa
  3. Desligue os servidores virtuais ou inicie a partir do ISO ativo para o Método 3
  4. Iniciar transferência de disco
  5. Monitorar o progresso da transferência

Fase 2: Transformação e fornecimento (horas 4-6)

  1. Execute o site virt-v2v, se necessário, para injetar drivers
  2. Verificar transferências de disco (fdisk, somas de verificação)
  3. Limpar os buffers e separar os volumes do trabalhador
  4. Criar as instâncias de servidor virtual a partir de volumes migrados
  5. Inicie as instâncias do servidor virtual

Fase 3: Validação e transição (horas 6 a 8)

  1. Inicie as instâncias do servidor virtual e acesse-as por meio do console VNC, se necessário
  2. Verifique a configuração da rede e ajuste-a, se necessário
  3. Iniciar aplicativos
  4. Teste funcional (o aplicativo funciona, os dados são acessíveis)
  5. Adicionar aos balanceadores de carga e atualizar o DNS
  6. Monitorar desempenho do aplicativo

Fase 4: Estabilização (horas 8-12)

  1. Monitoramento de problemas
  2. Verificar a conectividade externa
  3. Verifique se há erros nos logs do aplicativo
  4. Comparar o desempenho com a linha de base

Pontos de decisão de reversão de migração:

  • Após a Fase 1: reversão fácil (reinicie os servidores virtuais VMware )
  • Após a Fase 2: dificuldade média (descartar instâncias de servidor virtual, reiniciar os servidores virtuais VMware, restaurar o DNS)
  • Após a Fase 3: Difícil (pode haver novos dados na VPC, requer sincronização de dados de volta para VMware )

Recomendação de design: Definir pontos de controle explícitos de "ir" e "não ir". Exemplos:

  • Após a Fase 2, se mais de 20% das instâncias de servidores virtuais não conseguirem iniciar, implemente uma reversão.
  • Após a Fase 3, se os testes funcionais do aplicativo falharem, implemente uma reversão.
  • Após a Fase 4, se o desempenho for mais de 30% inferior à linha de base, investigue, mas não implemente uma reversão.

Estimativa da velocidade de migração

Faça uma estimativa do tempo de migração por servidor virtual para planejar tamanhos e janelas de ondas realistas. O cronograma a seguir é viável, mas você precisa consultar o site PoC antes da migração real.

Componentes de tempo:

Estimativas de tempo de exportação usando os Métodos 1-2:

  • servidor virtual de 100 GB: 20-30 minutos
  • servidor virtual de 500 GB: 2-3 horas
  • Depende do desempenho do armazenamento VMware

Estimativas de tempo de transferência:

  • Rede: 100 GB = 20-25 minutos
  • Rede: 500 GB = 90-120 minutos
  • Método 3 com compactação: geralmente 2 ou 3 vezes mais rápido devido à compactação

Estimativas de tempo de transformação com virt-v2v:

  • Linux: 5-10 minutos
  • Windows: 10-20 minutos
  • Depende do desempenho da instância do servidor virtual de trabalho

Estimativas de tempo de provisionamento:

  • Criação de instância de servidor virtual: 5 minutos
  • Inicialização e configuração de rede: 5-10 minutos

Exemplo de estimativas de tempo:

Servidor virtual pequeno Linux (1 disco, 100 GB, Método 3):

  • Nenhuma exportação: 0 minutos
  • Transferência com compressão: 25 minutos
  • Transformação: 5 minutos
  • Provisionamento: 10 minutos
  • Total: 40 minutos

Estimativas de tempo do servidor virtual Windows grande usando o Método 2 com 4 discos, 1 TB no total:

  • Exportação: 3 horas
  • Traslado: 2 horas
  • Transformação ( virt-v2v ): 20 minutos
  • Provisionamento: 10 minutos
  • Total: 5.5 horas

Eficiência da migração paralela usando a estimativa de tempo dos métodos 3 e 4:

  • 4x servidores virtuais de 100 GB que são migrados em paralelo
  • 30 minutos cada
  • Tempo total da onda: 35 minutos, que incluem os tempos de inicialização e desligamento

Em comparação com a migração de 4x servidores virtuais de 100 GB que você migra em série:

O tempo total da onda é de 120 minutos

O paralelismo lhe proporciona uma melhoria de 3 a 4 vezes nesse cenário.