Najlepszy sposób na zmianę adresu IP witryny - z perspektywy użytkownika końcowego?


10

Przeczytałem tutaj kilka istotnych pytań / odpowiedzi, ale wciąż nie jestem pewien, jaka jest najlepsza odpowiedź.

Przenoszę kilka witryn z adresu IP „1.abc” na „2.def”. W tej chwili w istniejącym systemie DNS ustawiłem wszystkie TTL na 300 sekund i mam nową strefę DNS gotową do użycia (na AWS Route 53), z nowymi serwerami nazw i wszystkimi TTL na 60 sekund. Dlatego uważam, że jestem gotowy z perspektywy DNS. Po przeprowadzce, po kilku dniach ustawię TTL na bardziej rozsądne liczby na trasie 53.

Ostrzegłem wszystkich moich użytkowników o przeprowadzce i mam określone okno czasowe na przeprowadzkę. Powiedziałem im, że po zakończeniu przenoszenia i jeśli minęły 24 godziny, a oni nadal widzą stare (zablokowane) witryny, powinni ponownie uruchomić komputer, aby wymusić lokalne opróżnianie pamięci podręcznej DNS.

Nie rozumiem, w jaki sposób przeglądarka użytkownika (pamięć podręczna) odgrywa w tym rolę. Moje własne eksperymenty z plikiem lokalnego hosta (Win7) mówią mi, że w przeglądarce jest coś, co nie pozwala na odejście starego adresu IP - musiałem przejść do historii-> wyczyścić wszystko , aby nowa lokalizacja witryny mogła się wyświetlić w górę, nawet poipconfig /flushdns

(EDYCJA) - Nie mam dostępu root do starego serwera, więc nie mogę zaimplementować przyjętej odpowiedzi na to pytanie .

Pytanie: Naprawdę nie chcę, aby moi użytkownicy musieli sobie z tym poradzić, więc czy mogę coś zrobić, aby zmusić wszystkie przeglądarki do ponownego buforowania? A jeśli tak, to jak długo mam pozostawić włączone?

Dzięki...


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 goCzy możesz podać jakieś informacje na ten temat? Afaik, przeglądarki nie buforują rekordów DNS przez dłużej niż 1 minutę.
Tanmay

Nie jestem pewien, ale po wielu ipconfig / flushdns i „ctrl-F5” (w Firefoksie) nadal otrzymywałem mieszankę stron ze starej i nowej strony ... w końcu musiałem wyczyścić „wszystko” i ponownie uruchomić przeglądarka. Nie chcę, aby moi użytkownicy musieli robić podobne ...
CC

JBTW, rozwiązanie w podanym linku może również działać, jeśli masz uprawnienia roota do nowego serwera. Zaktualizuj rekordy DNS i przekaż cały ruch z nowego serwera na stary, dopóki DNS nie zostanie poprawnie propagowany.
Tanmay

dzięki ... ale potem musiałbym ponownie zsynchronizować stary z powrotem do nowego (bazy danych itp.) później, nie?
CC

Trzeba będzie zsynchronizować bazę danych raz, tuż przed wyłączeniem przekazywania.
Tanmay,

Odpowiedzi:


15

Nie możesz. Problem polega na tym, że odpowiedź DNS może być buforowana w dowolnym miejscu między użytkownikiem a serwerem DNS i nie ma możliwości ich unieważnienia.

Co możesz jednak zrobić - gdy tylko zsynchronizujesz dane i Twoja druga strona będzie gotowa, możesz ponownie skonfigurować oryginalny serwer, aby działał jako serwer proxy i przekazywał wszystkie żądania do nowej lokalizacji.

W ten sposób możesz osiągnąć prawie zerowy czas przestoju swojej witryny.

Aktualizacja

Jeśli nie masz dostępu do konta root, istnieje kilka opcji:

  • Wykonuj proxy w PHP

  • Skonfiguruj serwer proxy na drugim serwerze (jeśli masz tam dostęp root), zmień DNS, a kiedy będziesz gotowy, zmień serwer proxy na serwer WWW

  • Ta metoda może być źródłem problemów. Ma 2 adresy (www.domain.tld i www2.domain.tld). Skonfiguruj www2 (to samo co www) i ustaw poprawne rekordy DNS. Następnie przygotuj wersję www swojej witryny i przełączyć DNS. Ustaw przekierowanie wszystkich żądań na starym serwerze do subdomeny www2.


Czy miałbyś coś przeciwko rozwinięciu się w tym temacie, czy też wskaźnikiem do artykułu lub pytania, które mógłbym przeczytać? Nie mam dostępu root do istniejącego serwera, więc nie mogę bezpośrednio manipulować tablicami IP ... więc może jest inny sposób?
CC

@CC być może masz dostęp do zamiany aplikacji na instancję HAProxy? A może zamień kod aplikacji na inny, który jedynie przesyła żądanie do nowego serwera?
Jason Martin

@JasonMartin - Mam dostęp do .htaccess i kodu aplikacji. Tak, tak, prawdopodobnie mógłbym pobrać żądany adres URL i przekazać go na nowy adres IP - może powinienem spróbować?
CC

@CC brzmi wtedy obiecująco. DNS jest narzędziem „w końcu spójnym”, a niektóre serwery DNS ustawiają minimalne poziomy TTL i zignorują twoje 300s. Jeśli chcesz uniknąć jakichkolwiek zakłóceń, najlepszym rozwiązaniem jest proxy przekazywania.
Jason Martin

4

Teoretycznie ustawienie TTL domeny na coś niskiego i oczekiwanie na zmianę, a następnie zmiana adresu IP, powinno doprowadzić do niemal przezroczystej migracji. W końcu to cały sens konfigurowania TTL.

W praktyce ludzie źle konfigurują rzeczy, a narzędzia psują się. Dlatego może być konieczne podanie instrukcji użytkownikom wyczyszczenia lokalnej pamięci podręcznej, jeśli coś nie działa poprawnie.

Ale nie robisz nic złego.


Czy powinienem natychmiast przełączyć się na nowy DNS AWS Route 53 - ze starym adresem IP - a następnie po zakończeniu migracji po prostu zmienić adres IP na nowy? - lub po prostu zmienić DNS na nowy i jednocześnie zmienić adres IP?
CC

1
@CC: Nie jestem administratorem sieci, więc weź to ze szczyptą soli (i cieszę się, że słyszę od guru ServerFault), ale osobiście zaleciłbym, aby nie zmieniać obu naraz. Uporządkuj swój DNS, a następnie wykonaj zmianę adresu IP i pozwól, aby nowy DNS wykonał swoją pracę, pomagając ci w tej ostatniej części.
Wyścigi lekkości na orbicie

1
Próbowałem eksperymentu. W jednej witrynie zmieniłem wcześniej godziny DNS, a później zmieniłem adres IP rekordu A. Działał idealnie. Drugą stronę zmieniłem jednocześnie. Godzinami miotał się między starym / nowym adresem IP - w końcu usunąłem strefę AWS Route 53 i zrobiłem to ponownie tak samo, jak w przypadku pierwszej strony. Działał idealnie. Więc nie potrzebujesz szczypty soli - byłeś na miejscu!
CC

1

Nieuchronnie twój stary adres będzie przechowywany w pamięci podręcznej i używany przez długi czas - głównie przez boty.

Jak bym to zrobił:

  • Utwórz rekord A, na przykład www2.yourdomain.comwskazujący nowy adres IP. Ten rekord nigdy nie powinien był być używany; dlatego nigdy nie buforowane.
  • Przekieruj zapytania na starym serwerze do www2.yourdomain.com
  • Monitoruj przekierowania, a gdy ruch spadnie do akceptowalnego poziomu, usuń stary serwer.
  • I wreszcie, gdy stary serwer zostanie usunięty, przekieruj www2.yourdomain.comna www.yourdomain.com.

Pamiętaj, aby użyć 301 stałych przekierowań. https://en.wikipedia.org/wiki/HTTP_301


Moje przeczucie, że powinien nie używać 301 dla pierwszej rundzie przekierowań, ale tylko na sekundę. Czy jest jakiś konkretny powód, dla którego powinien być znany tylko ezoterycznej mądrości SEO?
Random832,

@ Random832 A permanent informuje klienta użytkownika, aby zapomniał o starym adresie URL i np. Zaktualizował zakładki w celu wskazania nowego adresu URL (aby następnym razem mógł uzyskać bezpośredni dostęp do nowego adresu). Ponowne przekierowanie później (lub nawet powrót do pierwotnego adresu URL) nie jest szkodliwe. Z drugiej strony tymczasowe przekierowanie informuje klienta użytkownika, aby zachował oryginalny adres URL (ponieważ przekierowanie może się przydarzyć innemu celowi lub nie będzie w ogóle następnym razem). Dlatego przy tymczasowych przekierowaniach monitorowanie przekierowań nigdy nie spadłoby do „akceptowalnego poziomu”.
Hagen von Eitzen

@HagenvonEitzen Spadnie do akceptowalnego poziomu, ponieważ przeglądarki przestają uzyskiwać adres IP starego serwera dla www.twojadomena.com, co jest domeną DNS i nie będzie miało wpływu na rodzaj zastosowanego przekierowania HTTP. I „ponieważ przekierowanie może się zdarzyć ... wcale nie następnym razem” jest zatem dokładnie prawdziwe.
Random832,

0

Wygląda na to, że planujesz jednocześnie zmienić swoje serwery nazw? Ze względu na sposób, w jaki serwery nazw są wykrywane, aktualizacja zajmuje dużo więcej czasu niż zwykły zapis - często około 24 godzin lub dłużej.

Gorąco polecam aktualizację DNS u obecnego dostawcy przed zmianą DNS lub zmianę serwerów nazw na 7 dni przed zmianą adresu IP witryny.

Nowoczesne komputery i przeglądarki są dość niezawodne w przestrzeganiu TTL z DNS, ale aby zrozumieć najlepsze wyniki, musisz zrozumieć cały łańcuch.


Dzięki i tak, to odzwierciedla mój komentarz pod odpowiedzią Lightness powyżej. Rozdzielacze dość szybko odświeżyły serwery nazw - w ciągu kilku minut. Najważniejsze było, aby najpierw to zrobić, a następnie odczekać kilka godzin przed zmianą docelowego adresu IP. Oba naraz były złe ... bardzo złe.
CC
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.