A melhor maneira de alterar o endereço IP do site - da perspectiva do usuário final?

10

Eu li várias perguntas e respostas relevantes aqui, mas ainda não tenho certeza de qual é a melhor resposta.

Estou mudando alguns sites do endereço IP "1.abc" para "2.def". No momento, no DNS existente, defino todo o TTL para 300 segundos e tenho uma nova zona DNS pronta para ser usada (na AWS Route 53), com novos servidores de nomes e todos os TTLs em 60 segundos. Então, eu acredito que estou pronto, da perspectiva do DNS. Após a mudança, depois de alguns dias, definirei o TTL para números mais razoáveis na Rota 53.

Eu avisei todos os meus usuários sobre a mudança e tenho uma janela de tempo definida para a mudança. Eu disse a eles que, depois que a mudança estiver concluída, e se tiverem passado 24 horas e eles ainda virem os sites antigos (bloqueados), eles deverão reiniciar o computador para forçar a liberação do cache DNS local.

Não entendo como o navegador do usuário (cache) desempenha um papel nisso. Minhas próprias experiências com um arquivo de hosts locais (Win7) me dizem que há algo no navegador que não deixa o endereço IP antigo - eu tive que ir ao histórico-> limpar tudo para que o novo local do site fosse exibido mesmo depoisipconfig /flushdns

(EDIT) - Não tenho acesso root ao servidor antigo, portanto não consigo implementar a resposta aceita para esta pergunta .

Pergunta: Eu realmente não quero que meus usuários tenham que lidar com isso, então há algo que eu possa fazer para forçar todos os navegadores existentes a fazerem um cache novamente? E se sim, quanto tempo deixo ligado?

Obrigado...

domain-name-system migration

— CC
fonte

My own experiments with a local hosts file (Win7) tell me there is something about the browser that is not letting the old IP address go

Você pode fornecer algumas informações sobre isso? Além disso, os navegadores não armazenam em cache os registros DNS por mais de um minuto.

— Tanmay

Não tenho certeza, mas depois de vários ipconfig / flushdns e "ctrl-F5" (no Firefox), eu continuava recebendo uma mistura de páginas do site antigo e do novo site ... finalmente tive que limpar "tudo" e reiniciar navegador. Eu não quero que meus usuários tem que fazer semelhante ...

— CC

JBTW, a solução no link que você forneceu também pode funcionar se você tiver acesso root ao novo servidor. Atualize os registros DNS e encaminhe todo o tráfego do novo servidor para o antigo, até que o DNS seja propagado corretamente.

— precisa

obrigado ... mas então eu teria que sincronizar o antigo com o novo (bancos de dados, etc) novamente mais tarde, não?

— CC

Você precisará sincronizar o banco de dados uma vez, pouco antes de desativar o encaminhamento.

— Tanmay

15

Não, você não pode. O problema é que a resposta do DNS pode ser armazenada em cache em qualquer lugar entre o usuário e o servidor DNS e não há como invalidá-los.

No entanto, o que você pode fazer - assim que tiver os dados sincronizados e o segundo site estiver pronto, você poderá reconfigurar o servidor original para se comportar como proxy e passar todas as solicitações para o novo local.

Dessa forma, você pode obter quase 0s de inatividade no seu site.

Atualizar

Se você não tem acesso root, existem várias opções:

Executar proxy no PHP
Configure o proxy no segundo servidor (se você tiver acesso root), alterne o DNS e, quando estiver pronto, altere o proxy para o servidor da web
Este método pode ser a fonte de problemas Possui 2 endereços (www.domain.tld e www2.domain.tld). Configure www2 (que é o mesmo que www) e defina os registros DNS corretos. Em seguida, prepare a versão www do seu site e faça a troca do DNS. Defina o redirecionamento de todas as solicitações no servidor antigo como subdomínio www2.

— Yarik Dot
fonte

Você se importaria de expandir um pouco sobre isso, ou com um ponteiro para um artigo ou perguntas e respostas que eu pudesse ler? Eu não tenho acesso root ao servidor existente, então não posso manipular diretamente as tabelas IP ... então talvez haja uma maneira alternativa?

— CC

@CC talvez você tenha acesso para substituir seu aplicativo por uma instância HAProxy? Ou substitua o código do aplicativo por outro que encaminhe puramente a solicitação para o novo servidor?

— Jason Martin

@ JasonMartin - eu tenho acesso ao .htaccess e ao código do aplicativo. Então, sim, eu provavelmente poderia pegar o URL solicitado e encaminhar para o novo endereço IP - talvez eu deva tentar isso?

— CC

@CC que parece promissor então. O DNS é uma ferramenta 'eventualmente consistente', e alguns servidores DNS estabelecem limites em seu TTL e ignoram seus 300 anos. Se você quiser evitar qualquer interrupção, um proxy de encaminhamento é a melhor aposta.

— Jason Martin

4

Em teoria, definir o TTL do domínio para algo baixo e aguardar a alteração, depois alterar o IP, deve resultar em uma migração quase transparente. Afinal, esse é o objetivo do TTL ser configurável.

Na prática, as pessoas configuram mal as coisas e as ferramentas quebram. É por isso que você pode precisar fornecer instruções aos usuários para limpar o cache local, se as coisas não funcionarem corretamente.

Você não está fazendo nada de errado.

— Raças de leveza em órbita
fonte

Devo mudar imediatamente para o novo DNS da AWS Route 53 - com o endereço IP antigo - e depois da migração, basta alterar o endereço IP para o novo? - ou apenas altere o DNS para o novo e altere o IP ao mesmo tempo?

— CC

1

@CC: Eu não sou administrador de rede, então leve isso com uma pitada de sal (e fico feliz em saber o contrário dos gurus do ServerFault), mas eu pessoalmente recomendo não alterar os dois ao mesmo tempo. Organize o seu DNS, execute a alteração do IP e deixe o novo DNS fazer seu trabalho, ajudando você nessa última parte.

— Lightness Races in Orbit

1

Bem, eu tentei um experimento. Em um site, alterei as horas do DNS antecipadamente e depois alterei o endereço IP do registro A mais tarde. Funcionou perfeitamente. No outro site, mudei os dois ao mesmo tempo. Ele estava debatendo entre o antigo / novo endereço IP por horas - finalmente excluí a zona do AWS Route 53 e refiz a mesma da mesma maneira que o primeiro site. Funcionou perfeitamente. Portanto, nenhuma pitada de sal é necessária - você estava no local!

— CC

1

Inevitavelmente, seu endereço antigo será armazenado em cache e usado por um longo tempo - principalmente por bots.

Como eu faria isso:

Crie um registro A, por exemplo www2.yourdomain.com, apontando para um novo IP. Esse registro nunca deveria ter sido usado antes; portanto, nunca em cache.
Redirecione consultas no servidor antigo para www2.yourdomain.com
O monitor redireciona e, quando o tráfego diminuir para um nível aceitável, remova o servidor antigo.
E finalmente, quando o servidor antigo for removido, redirecione www2.yourdomain.compara www.yourdomain.com.

Certifique-se de usar 301 redirecionamentos permanentes. https://en.wikipedia.org/wiki/HTTP_301

— ClickLabs
fonte

Meu pressentimento é que ele não deve usar 301 na primeira rodada de redirecionamentos, mas apenas na segunda. Existe alguma razão em particular que ele deva ser conhecida apenas por alguém com sabedoria esotérica em SEO?

— Random832

@ Random832 Uma permanente diz ao agente do usuário para esquecer o URL antigo e, por exemplo, atualizar os favoritos para apontar para o novo URL (para que, na próxima vez, eles possam acessar o novo URL diretamente). Não há nenhum mal em redirecionar mais tarde (ou mesmo voltar ao URL original). Um redirecionamento temporário, por outro lado, informa ao agente do usuário para manter o URL original (porque o redirecionamento pode ocorrer com um destino diferente ou não na próxima vez). Portanto, com redirecionamentos temporários, o monitoramento de redirecionamento nunca cairia para um "nível aceitável".

— Hagen von Eitzen

@HagenvonEitzen Vai cair para um nível aceitável, pois os navegadores param de obter o endereço IP do servidor antigo para www.yourdomain.com, que é uma coisa de DNS e não será afetado pelo tipo de redirecionamento HTTP usado. E "porque o redirecionamento pode acontecer ... não na próxima vez" é, portanto, precisamente verdadeiro.

— Random832

0

Parece que você está planejando alterar seus servidores de nomes ao mesmo tempo? Devido à maneira como os servidores de nomes são descobertos, eles levam muito mais tempo para atualizar do que um registro regular - geralmente com duração de 24 horas ou mais.

Eu recomendo que você atualize o DNS no seu provedor atual antes de alterar o DNS ou altere seus servidores de nomes 7 dias antes de alterar o IP do site.

Computadores e navegadores modernos são bastante confiáveis para obedecer aos TTLs com DNS, mas você precisa entender toda a cadeia para obter os melhores resultados.

— codatório
fonte

Obrigado, e sim, isso reflete meu comentário na resposta do Lightness, acima. Os resolvedores atualizaram os servidores de nomes rapidamente - em minutos. A chave era fazer isso primeiro e depois esperar algumas horas antes de alterar o endereço IP de destino. Os dois ao mesmo tempo eram ruins ... muito ruins.

— CC