Toda história de terror de migração tem o mesmo miolo: alguém mudou o DNS primeiro e depois começou a copiar. Ficar fora do ar durante uma mudança quase nunca tem a ver com a cópia ser lenta. Tem a ver com fazer os passos na ordem errada.
Esta é a ordem que funciona, seja saindo de outro provedor, seja passando de um dos nossos planos para outro.
1. Dois dias antes: baixe o TTL
Encontre os registros DNS que você vai mudar (geralmente A, AAAA e qualquer CNAME que aponte para eles) e baixe o TTL para 300 segundos. Depois espere pelo menos o tempo do TTL antigo. Um registro com TTL de um dia significa que alguns resolvedores vão continuar entregando o endereço antigo por um dia depois da mudança, e nada que você faça no servidor acelera isso.
É o passo que as pessoas pulam, e é ele que transforma uma troca de cinco minutos num dia em que metade dos usuários vê o servidor antigo.
2. Faça o inventário do servidor antigo
Você vai reconstruir essa máquina em outro lugar, então anote o que ela realmente faz. Não o que você lembra. O que ela faz:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
Acrescente à lista: os certificados TLS e como eles renovam, arquivos de ambiente com segredos, regras de firewall, usuários e suas chaves SSH, o banco de dados e o tamanho dele, e tudo o que conversa com o servidor pelo endereço IP. Esse último grupo é o traiçoeiro: a lista de permissões de um parceiro, a configuração de webhooks de um provedor de pagamento, uma checagem de monitoramento.
3. Monte o servidor novo ao lado do antigo
Contrate o servidor novo e deixe o antigo quieto. Escolha um plano da lista de VPS com o mesmo disco ou mais do que você usa de fato, não do que lhe venderam. Se a máquina antiga recebe qualquer tráfego de entrada (um site, webhooks, uma API), a nova precisa de IPv4 próprio. Um plano NAT só aceita conexões de entrada na porta SSH dele, e o que uma única porta redirecionada pode e não pode fazer explica por que isso importa.
Conecte-se, instale os mesmos pacotes, recrie os usuários e o firewall. O guia de conexão cobre as chaves e o primeiro login.
4. Sincronize os arquivos duas vezes
A primeira sincronização copia tudo enquanto o servidor antigo continua trabalhando. Pode levar horas; tudo bem.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids mantém os donos dos arquivos pelo número, o que evita a clássica surpresa de «tudo pertence ao usuário errado» quando os dois sistemas criaram os usuários em ordem diferente. Se você nunca usou rsync por SSH, como transferir arquivos para um VPS mostra passo a passo.
A segunda sincronização, logo antes da troca, copia só o que mudou desde a primeira. Normalmente leva segundos.
5. Mude o banco de dados com cuidado
Arquivos são fáceis. Um banco que recebe escritas é a única parte em que «sem ficar fora do ar» exige um pequeno meio-termo ou mais trabalho.
O jeito simples: fazer um dump e restaurar uma vez para testar, e no momento da troca parar as escritas por um minuto (colocar a aplicação em modo só leitura ou pará-la), tirar um dump novo, restaurar no servidor novo e subir a aplicação lá. Para a maioria dos projetos pequenos, é uma pausa de um ou dois minutos, avisada com antecedência.
O jeito sem pausa: configurar replicação do banco antigo para o novo, deixar alcançar, e promover o novo no momento da troca. Dá mais trabalho, e vale a pena quando nem um minuto de escritas perdidas é aceitável.
6. Teste o servidor novo antes que outra pessoa veja
O DNS ainda aponta para o servidor antigo, então você pode testar o novo em particular. Mande uma requisição do seu domínio real para o endereço novo:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
Se o certificado ainda não estiver lá, teste do mesmo jeito por HTTP, ou acrescente uma linha temporária ao arquivo hosts e navegue pelo site no navegador. Confira logins, uploads, tarefas em segundo plano e e-mail de saída. É o momento mais barato para descobrir que falta uma extensão do PHP.
7. Vire a chave e deixe o servidor antigo ligado
Faça a sincronização final dos arquivos e o passo do banco, depois mude os registros DNS. Com TTL de 300 segundos, a maior parte do tráfego muda em minutos. Fique de olho no log de acesso do servidor antigo: ele ainda vai receber um fio de requisições de resolvedores e clientes que ignoram o TTL. Deixe-o ligado, sem mudanças, por alguns dias. Depois atualize tudo o que aponta para o IP antigo: listas de permissões de parceiros, URLs de webhooks e, para o e-mail, o DNS reverso do endereço novo (nos nossos planos com IP dedicado você mesmo configura, veja DNS reverso) e o seu registro SPF.
O que mais quebra
Mais ou menos na ordem de frequência com que vemos: um timer do systemd que ninguém listou, um arquivo de configuração com o IP antigo escrito à mão, arquivos pertencendo ao usuário errado, um firewall bloqueando a porta da própria aplicação, um certificado que renova no servidor antigo mas não no novo, e e-mail caindo no spam porque o endereço novo ainda não tem DNS reverso.
Onde este checklist não serve
Um banco com escritas constantes e tolerância zero a pausas precisa de replicação de verdade e de um ensaio, não de um checklist de blog. Servidores Windows mudam com ferramentas diferentes do rsync. E se a mudança na verdade é por tamanho, leia isto antes: aqui os planos crescem no lugar. Passar para um plano maior do mesmo tipo de rede adiciona vCPU, RAM e disco com uma reinicialização, sem migração nenhuma. Só para diminuir é preciso um servidor novo. Se você está se mudando porque não tem certeza de que a máquina é grande o bastante, quando você precisa mesmo de 64 GB de RAM pode lhe poupar a viagem, e VPS, hospedagem compartilhada, servidor dedicado ou nuvem ajuda se você não tem certeza de que um VPS é o lugar certo.
Comentários
Nenhum comentário ainda. Seja o primeiro.