최종 사용자 관점에서 사이트 IP 주소를 변경하는 가장 좋은 방법은 무엇입니까?


10

관련 Q / A를 많이 읽었지만 여전히 최고의 답변이 무엇인지 잘 모르겠습니다.

IP 주소 "1.abc"에서 "2.def"로 몇 개의 사이트를 이동하고 있습니다. 현재 기존 DNS에서 모든 TTL을 300 초로 설정했으며 60 초에 새 이름 서버와 모든 TTL과 함께 새로운 DNS 영역을 사용할 수 있습니다 (AWS Route 53에서). 그래서 저는 DNS 관점에서 준비가되었다고 생각합니다. 이동 후 며칠 후 Route 53에서 TTL을보다 합리적인 숫자로 설정합니다.

모든 사용자에게 이동에 대해 경고했으며 이동에 대한 정의 된 시간 창이 있습니다. 이동이 완료되고 24 시간이 지났는데도 여전히 오래된 (잠긴) 사이트가 보이면 컴퓨터를 재부팅하여 로컬 DNS 캐시를 강제로 플러시해야한다고 말했습니다.

사용자 브라우저 (캐시)가 어떻게 역할을하는지 이해하지 못합니다. 이전 IP 주소 놓아하지 않는 브라우저에 대해 뭔가가 로컬 호스트 파일 내 자신의 실험 (Win7에이) 말해 - 나는 가야했다 > 명확한 모든 역사 - 쇼에 새 사이트 위치를 얻기 위해 후에도ipconfig /flushdns

(편집)-이전 서버에 대한 루트 액세스 권한 이 없으므로이 질문에 허용되는 답변을 구현할 수 없습니다 .

질문 : 사용자가이 문제를 처리하기를 정말로 원하지 않으므로 모든 브라우저를 강제로 다시 캐시하도록 할 수있는 방법이 있습니까? 그렇다면 얼마나 오랫동안 켜 두어야합니까?

감사...


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이것에 대한 정보를 제공 할 수 있습니까? Afaik, 브라우저는 1 분 이상 DNS 레코드를 캐시하지 않습니다.
Tanmay

확실하지는 않지만 여러 ipconfig / flushdns 및 "ctrl-F5"(Firefox에서) 후에도 이전 사이트와 새 사이트에서 계속 혼합 된 페이지를 얻었습니다 ... 마지막으로 "모든 항목"을 지우고 다시 시작해야했습니다. 브라우저. 사용자들이 비슷한 작업을 수행하는 것을 원하지 않습니다.
CC

새 서버에 대한 루트 액세스 권한이있는 경우 제공 한 링크의 솔루션 인 JBTW도 작동 할 수 있습니다. DNS가 올바르게 전파 될 때까지 DNS 레코드를 업데이트하고 모든 트래픽을 새 서버에서 이전 서버로 전달하십시오.
Tanmay

고마워 ...하지만 나중에 다시 이전 (새 데이터베이스 등)으로 다시 동기화해야합니까?
CC

전달을 끄기 직전에 데이터베이스를 한 번 동기화해야합니다.
Tanmay

답변:


15

아냐, 못해 문제는 사용자와 DNS 서버간에 DNS 응답을 캐시 할 수 있으며 무효화 할 수있는 방법이 없다는 것입니다.

그러나 수행 할 수있는 작업-데이터가 동기화되고 두 번째 사이트가 준비 되 자마자 원래 서버를 프록시로 작동하도록 재구성하고 모든 요청을 새 위치로 전달할 수 있습니다.

이런 식으로, 당신은 당신의 웹 사이트의 거의 0의 가동 중지 시간을 달성 할 수 있습니다.

최신 정보

루트 액세스 권한이없는 경우 몇 가지 옵션이 있습니다.

  • PHP에서 프록 싱 수행

  • 두 번째 서버에서 프록시를 구성하고 (루트 액세스 권한이있는 경우) DNS를 전환하고 프록시를 웹 서버로 변경할 준비가되면

  • 이 방법은 두 가지 주소 (www.domain.tld 및 www2.domain.tld)를 갖는 문제의 원인될 수 있습니다 . www2 (www와 동일)를 구성하고 올바른 DNS 레코드를 설정하십시오. 그런 다음 www 버전의 사이트를 준비하고 DNS를 전환하십시오. 기존 서버의 모든 요청을 www2 하위 도메인으로 리디렉션하도록 설정합니다.


이것에 대해 조금 확장하거나 내가 읽을 수있는 기사 또는 Q / A에 대한 포인터로 확장 하시겠습니까? 기존 서버에 대한 루트 액세스 권한이 없으므로 IP 테이블을 직접 조작 할 수 없으므로 대체 방법이 있습니까?
CC

@CC 아마도 애플리케이션을 HAProxy 인스턴스로 교체 할 수 있습니까? 아니면 응용 프로그램 코드를 새 서버로 순수하게 요청을 전달하는 다른 코드로 바꾸시겠습니까?
Jason Martin

@JasonMartin-.htaccess 및 응용 프로그램 코드에 액세스 할 수 있습니다. 예, 요청한 URL을 가져 와서 새로운 IP 주소로 전달할 수 있습니다. 어쩌면 시도해야합니까?
CC

그렇다면 유망하게 들리는 @CC. DNS는 '결국 적으로 일관된'도구이며 일부 DNS 서버는 TTL에 층을 설정하고 300을 무시합니다. 중단을 피하려면 전달 프록시가 가장 좋습니다.
Jason Martin

4

이론적으로 도메인의 TTL을 낮게 설정하고 변경이 발생할 때까지 기다린 다음 IP를 변경하면 마이그레이션이 거의 투명 해집니다. 결국, 그것은 구성 가능한 TTL의 요점입니다.

실제로 사람들은 잘못 구성하고 도구를 깨뜨립니다. 따라서 제대로 작동하지 않는 경우 사용자에게 로컬 캐시를 지우라는 지침을 제공해야 할 수도 있습니다.

당신은 아무것도 잘못하고 있지 않습니다.


이전 IP 주소 를 사용하여 새 AWS Route 53 DNS로 즉시 전환해야합니까? 마이그레이션이 완료된 후 IP 주소를 새 IP 주소로 변경하면됩니다. -하거나 새로운 하나에 DNS를 변경 하고 동시에 IP를 변경?
CC

1
@ CC : 나는 네트워크 관리자가 아니므로 소금 한 덩어리로 이것을 가져 가십시오 (그리고 ServerFault 전문가의 의견을 듣고 기쁘다).하지만 개인적으로 한 번에 두 가지를 변경하지 않는 것이 좋습니다. DNS를 정리 한 다음 IP 변경을 수행하고 마지막 부분을 도와 새로운 DNS가 작업을 수행하도록합니다.
궤도에서 가벼움 경주

1
글쎄, 나는 실험을 시도했다. 한 사이트에서 DNS 시간을 미리 변경 한 다음 나중에 A 레코드 IP 주소를 변경했습니다. 완벽하게 작동했습니다. 다른 사이트는 한 번에 둘 다 변경했습니다. 몇 시간 동안 이전 / 새 IP 주소 사이에서 스 래싱이 발생했습니다. 마침내 AWS Route 53 영역을 삭제하고 첫 번째 사이트와 동일한 방식으로 다시 부여했습니다. 완벽하게 작동했습니다. 따라서 소금이 조금도 필요하지 않습니다.
CC

1

필연적으로 기존 주소는 대부분 봇에 의해 캐시되어 오랫동안 사용됩니다.

내가하는 방법 :

  • 예를 들어 www2.yourdomain.com새 IP를 가리키는 A 레코드를 작성하십시오 . 이 레코드는 이전에 사용 된 적이 없어야합니다. 따라서 캐시되지 않습니다.
  • 이전 서버의 쿼리를 www2.yourdomain.com
  • 리디렉션을 모니터링하고 트래픽이 수용 가능한 수준으로 가라 앉으면 이전 서버를 제거하십시오.
  • 마지막으로 오래된 서버가 제거되면로 리디렉션 www2.yourdomain.com하십시오 www.yourdomain.com.

301 영구 리디렉션을 사용해야합니다. https://ko.wikipedia.org/wiki/HTTP_301


내 직감 은 첫 번째 라운드의 리디렉션에는 301을 사용 하지 말고 두 번째에만 사용해야 한다는 것입니다 . 난해한 SEO 지혜를 가진 사람에게만 알려진 특별한 이유가 있습니까?
Random832

@ Random832 영구는 사용자 에이전트에게 이전 URL을 잊어 버리고 예를 들어 책갈피를 업데이트하여 새 URL을 가리 키도록합니다 (다음에 새 URL에 직접 액세스 할 수 있음). 나중에 다시 리디렉션하거나 원래 URL로 다시 되 돌리는 데 아무런 해가 없습니다. 반면에 임시 리디렉션은 사용자 에이전트에게 원래 URL을 유지하도록 지시합니다 (리디렉션이 다른 대상으로 이어 지거나 다음 번에 발생할 수 없기 때문에). 따라서 일시적인 리디렉션을 통해 리디렉션 모니터링은 "허용 가능한 수준"으로 떨어지지 않습니다 .
Hagen von Eitzen

@HagenvonEitzen 브라우저가 DNS이며 www.yourdomain.com에 대한 이전 서버의 IP 주소를 얻는 것을 중단하면 허용 가능한 수준으로 떨어질 것입니다. 따라서 "리디렉션이 발생할 수 있기 때문에 ... 다음 번에는 전혀 그렇지 않습니다"라는 말은 사실입니다.
Random832

0

네임 서버를 동시에 변경할 계획 인 것 같습니까? 이름 서버가 검색되는 방식으로 인해 일반 레코드보다 업데이트 시간이 훨씬 오래 걸립니다 (종종 24 시간 이상).

DNS를 변경 하기 전에 현재 제공 업체에서 DNS를 업데이트 하거나 웹 사이트 IP를 변경하기 7 일 전에 네임 서버를 변경하는 것이 좋습니다 .

최신 컴퓨터와 브라우저는 DNS를 사용하여 TTL을 준수 할 때 매우 안정적이지만 최상의 결과를 얻으려면 전체 체인을 이해해야합니다.


감사합니다. 예, 위의 Lightness 'answer에 대한 나의 의견을 반영합니다. 리졸버는 몇 분 안에 네임 서버를 매우 빠르게 새로 고쳤습니다. 핵심은 먼저 그 작업을 수행 한 다음 대상 IP 주소를 변경하기 전에 몇 시간을 기다리십시오. 한 번에 둘 다 나빴다 ... 아주 나빴다.
CC
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.