Mover uma instância para outro site

Não há migração a quente entre cidades

Qualquer um que ofereça isso está copiando páginas de memória por um caminho com cem milissegundos de latência, e o que chegar será mais lento do que o que saiu. Nós fazemos a versão honesta: parar, copiar o disco, iniciar na outra ponta. Entre dois locais europeus, um disco de duzentos gigabytes geralmente é copiado em dez minutos. Através de um oceano, reserve o mesmo tempo novamente.

As cópias passam pela nossa própria espinha dorsal e não contam para o seu limite de uso justo.

A sequência

1. Abaixe o TTL de qualquer registro DNS que aponte para a instância, pelo menos um dia antes. Sessenta segundos é o certo enquanto você está migrando.
2. Tire um snapshot. Ele fica no local antigo até você excluí-lo, e é para ele que você volta se precisar.
3. Solicite a migração, indicando o código do local de destino.
4. A instância para, o disco é copiado e ela inicia no destino com um novo IPv4 e um novo /64.
5. Atualize os registros A e AAAA, configure o DNS reverso nos novos endereços e procure por qualquer coisa que tenha um endereço fixo.
6. Aumente o TTL novamente quando estiver satisfeito.

curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/migrate -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"site":"FRA-01"}'

curl -s https://paragonvps.com/api/v1/jobs/<job-id> -H "Authorization: Bearer $Paragon_TOKEN" | jq -r .state

O endereço antigo

Mantido por setenta e duas horas após a migração, para que você possa deixar um redirecionamento nele e capturar o que ainda aponta para lá. Depois disso, ele volta ao pool. Avise-nos antes da migração se precisar dele por mais tempo e nós o manteremos.

A alternativa com quase zero downtime

Onde dez minutos de parada são inaceitáveis, construa o destino primeiro e copie enquanto o original ainda está atendendo:

rsync -aHAX --numeric-ids --info=progress2 --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run /srv/ deploy@<new-ipv4>:/srv/

Execute duas vezes: uma com o serviço no ar, outra depois de pará-lo, para que a segunda passada leve apenas o delta. Corte o DNS entre as duas passadas. Isso é mais trabalho e mais risco do que uma cópia de disco, e é a resposta certa para um banco de dados com réplica e a resposta errada para um servidor web que pode ficar fora do ar pelo tempo de um café.

Escolhendo para onde ir

As medianas de latência das nossas próprias sondas estão na página de locais. Jurisdição é a outra metade da decisão e, para uma boa parte dos nossos clientes, a metade maior — o local que você escolher decide a lei sob a qual seu disco está, e nenhum ticket de suporte muda isso depois.

Estoque também importa. Um local marcado como baixo aceitará o pedido e depois levará seu tempo para preenchê-lo, e um local para pré-venda não é lugar para migrar um serviço em produção.

O que quebra

• Licenças do Windows ativam com base no hardware e endereço. Espere reativar.
• Qualquer coisa fixada por endereço no firewall de outra pessoa. Pergunte a eles antes da migração, não depois que o telefone tocar.
• Endereços fixos na sua própria configuração. grep -r o diretório de configuração enquanto a instância antiga ainda está rodando, porque é quando as respostas são fáceis de verificar.