Il modo migliore per cambiare l'indirizzo IP del sito - dal punto di vista dell'utente finale?

10

Ho letto un sacco di domande / risposte pertinenti qui, ma non sono ancora sicuro di quale sia la risposta migliore.

Sto spostando un paio di siti dall'indirizzo IP "1.abc" a "2.def". A partire da ora nel DNS esistente ho impostato tutti i TTL su 300 secondi e ho una nuova zona DNS pronta per essere utilizzata (su AWS Route 53), con nuovi nameserver e tutti i TTL a 60 secondi. Quindi credo di essere pronto, dal punto di vista DNS. Dopo il trasloco, dopo alcuni giorni imposterò TTL su numeri più ragionevoli sulla Route 53.

Ho avvisato tutti i miei utenti della mossa e ho una finestra temporale definita per la mossa. Ho detto loro che una volta completato lo spostamento e se sono trascorse 24 ore e vedono ancora i vecchi siti (bloccati), dovrebbero riavviare il computer per forzare lo svuotamento della cache DNS locale.

Non capisco come il browser dell'utente (cache) abbia un ruolo in questo. I miei esperimenti con un file hosts locale (Win7) mi dicono che c'è qualcosa nel browser che non sta lasciando andare il vecchio indirizzo IP - ho dovuto andare alla cronologia-> cancellare tutto per ottenere la posizione del nuovo sito su, anche dopoipconfig /flushdns

(EDIT) - Non ho accesso root al vecchio server, quindi non posso implementare la risposta accettata a questa domanda .

Domanda: Non voglio davvero che i miei utenti debbano occuparsene, quindi c'è qualcosa che posso fare per forzare tutti i browser là fuori a re-cache? E se è così, per quanto tempo devo lasciarlo acceso?

Grazie...

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

Puoi fornire qualche informazione al riguardo? Dopo tutto, i browser non memorizzano nella cache i record DNS per più di 1 minuto.

— Tanmay,

Non sono sicuro, ma dopo più ipconfig / flushdns e "ctrl-F5" (in Firefox), stavo continuando a ottenere un mix di pagine sia dal vecchio sito che dal nuovo sito ... alla fine ho dovuto cancellare "tutto" e riavviare browser. Non voglio che i miei utenti debbano fare simili ...

— CC,

JBTW, la soluzione nel collegamento fornito può funzionare anche se si dispone dell'accesso root al nuovo server. Aggiorna i record DNS e inoltra tutto il traffico dal nuovo server a quello vecchio, fino a quando il DNS non si è propagato correttamente.

— Tanmay,

grazie ... ma poi dovrei sincronizzare di nuovo il vecchio con il nuovo (database, ecc.) più tardi, no?

— CC,

Dovrai sincronizzare il database una volta, appena prima di disattivare l'inoltro.

— Tanmay,

15

No, non puoi. Il problema è che la risposta DNS può essere memorizzata nella cache in qualsiasi punto tra l'utente e il server DNS e non è possibile invalidarli.

Cosa puoi comunque fare: non appena i dati sono sincronizzati e il tuo secondo sito è pronto, puoi riconfigurare il server originale in modo che si comporti come proxy e passare tutte le richieste alla nuova posizione.

In questo modo, puoi ottenere quasi 0 secondi di inattività del tuo sito web.

Aggiornare

Se non si dispone dell'accesso root, esistono diverse opzioni:

Eseguire il proxy in PHP
Configura proxy sul secondo server (se hai accesso root lì), cambia DNS e quando sei pronto cambia proxy in webserver
Questo metodo può essere fonte di problemi con 2 indirizzi (www.domain.tld e www2.domain.tld). Configurare www2 (che è uguale a www) e impostare i record DNS corretti. Quindi prepara la versione www del tuo sito e fai il cambio del DNS. Imposta il reindirizzamento di tutte le richieste sul vecchio server sul sottodominio www2.

— Yarik Dot
fonte

Ti dispiacerebbe espandere un po 'su questo, o con un puntatore a un articolo o Q / A che potrei leggere? Non ho accesso root al server esistente quindi non posso manipolare direttamente le tabelle IP ... quindi forse c'è un modo alternativo?

— CC,

@CC forse hai accesso per sostituire la tua applicazione con un'istanza HAProxy? O sostituire il codice dell'applicazione con un altro che inoltri la richiesta al nuovo server?

— Jason Martin,

@JasonMartin - Ho accesso a .htaccess e al codice dell'applicazione. Quindi sì, probabilmente potrei prendere l'URL richiesto e inoltrarlo al nuovo indirizzo IP - forse dovrei provarlo?

— CC,

@CC che suona promettente allora. Il DNS è uno strumento "alla fine coerente" e alcuni server DNS stabiliscono i piani nel loro TTL e ignoreranno i tuoi 300. Se vuoi evitare qualsiasi interruzione lì, un proxy di inoltro è la scommessa migliore.

— Jason Martin,

4

In teoria, impostare il TTL del dominio su qualcosa di basso e attendere che avvenga quel cambiamento, quindi cambiare l'IP, dovrebbe tradursi in una migrazione quasi trasparente. Dopotutto, questo è il punto in cui il TTL è configurabile.

In pratica, le persone configurano male le cose e gli strumenti si rompono. Ecco perché potresti dover fornire istruzioni ai tuoi utenti per svuotare la loro cache locale se le cose non funzionano correttamente.

Ma non stai facendo nulla di male.

— Corse di leggerezza in orbita
fonte

Devo passare immediatamente al nuovo DNS AWS Route 53 - con il vecchio indirizzo IP - dopo aver completato la migrazione è sufficiente cambiare l'indirizzo IP con quello nuovo? - o semplicemente cambiare il DNS con quello nuovo e cambiare l'IP contemporaneamente?

— CC,

1

@CC: Non sono un amministratore di rete, quindi prendi questo con un pizzico di sale (e sono felice di sapere altrimenti dai guru ServerFault), ma consiglierei personalmente di non cambiare entrambi contemporaneamente. Ottieni il tuo DNS risolto, quindi esegui la modifica dell'IP e lascia che il nuovo DNS faccia il suo lavoro aiutandoti con quest'ultima parte.

— Razze di leggerezza in orbita

1

Beh, ho provato un esperimento. Un sito, ho cambiato il DNS ore prima, quindi ho cambiato l'indirizzo IP del record A in seguito. Ha funzionato perfettamente. L'altro sito ho cambiato entrambi contemporaneamente. È stato un brivido tra il vecchio / nuovo indirizzo IP per ore - ho finalmente eliminato la zona AWS Route 53 e l'ho rifatto allo stesso modo del primo sito. Ha funzionato perfettamente. Quindi non è necessario un pizzico di sale: eri perfetto!

— CC,

1

Inevitabilmente il tuo vecchio indirizzo verrà memorizzato nella cache e utilizzato per molto tempo, principalmente dai robot.

Come lo farei:

Creare un record A, ad esempio www2.yourdomain.com, indicando un nuovo IP. Questo record non avrebbe mai dovuto essere usato prima; quindi mai memorizzato nella cache.
Reindirizzare le query sul vecchio server a www2.yourdomain.com
Monitorare i reindirizzamenti e quando il traffico scende a un livello accettabile, rimuovere il vecchio server.
E infine, una volta rimosso il vecchio server, reindirizzare www2.yourdomain.coma www.yourdomain.com.

Assicurati di utilizzare i reindirizzamenti permanenti 301. https://en.wikipedia.org/wiki/HTTP_301

— ClickLabs
fonte

La mia sensazione è che egli dovrebbe non usare 301 per il primo turno di reindirizzamenti, ma solo per il secondo. C'è qualche motivo particolare che dovrebbe essere noto solo a qualcuno con saggezza SEO esoterica?

— Casuale 832

@ Random832 Un permanente dice all'utente-agente di dimenticare il vecchio url e ad es. Aggiornare i segnalibri per puntare al nuovo url (quindi la prossima volta potrebbero accedere direttamente al nuovo url). Non vi è alcun danno nel reindirizzamento più tardi (o persino nel ritorno all'URL originale). Un reindirizzamento temporaneo, d'altra parte, dice all'utente-agente di mantenere l'URL originale (perché il reindirizzamento potrebbe avvenire su un target diverso o per niente la prossima volta). Pertanto, con reindirizzamenti temporanei, il monitoraggio del reindirizzamento non scenderebbe mai a un "livello accettabile".

— Hagen von Eitzen,

@HagenvonEitzen Cadrà a un livello accettabile quando i browser smetteranno di ottenere l'indirizzo IP del vecchio server per www.yourdomain.com, che è una cosa DNS e non sarà influenzato dal tipo di reindirizzamento HTTP utilizzato. E "perché il reindirizzamento potrebbe accadere ... per niente la prossima volta" è quindi esattamente vero.

— Casuale 832

0

Sembra che tu abbia intenzione di cambiare i tuoi nameserver contemporaneamente? A causa del modo in cui vengono scoperti i nameserver, l'aggiornamento richiede molto più tempo rispetto a un normale record, spesso volte circa 24 ore o più.

Consiglio vivamente di aggiornare il DNS presso il tuo attuale fornitore prima di cambiare DNS o cambiare i tuoi nameserver 7 giorni prima di cambiare l'IP del sito web.

I computer e i browser moderni sono abbastanza affidabili nell'obbedire ai TTL con DNS, ma è necessario comprendere l'intera catena per i migliori risultati.

— codatory
fonte

Grazie e sì, questo riflette il mio commento sotto la risposta di Lightness, sopra. I risolutori hanno aggiornato i server dei nomi abbastanza rapidamente - in pochi minuti. La chiave era farlo prima, quindi attendere alcune ore prima di modificare l'indirizzo IP di destinazione. Entrambi allo stesso tempo erano cattivi ... molto cattivi.

— CC,