방금 관리 REST API를 사용하여 VIP 스왑을 수행했습니다. 작업이 상태 코드 "성공"을 반환하기까지 30 초가 걸렸지 만 서비스에 대한 요청이 새 콘텐츠를 반환하기 전에 1 분 정도 걸렸습니다. 느린 시작 프로세스를 관리해야하기 때문에 VIP 교환 전후에 직원 역할을 알릴 필요가 있습니다. 질문은 이것입니다 : VIP 스왑이 어떻게 완료되었는지 확신 할 수 있습니까? 새로운 배포에서 콘텐츠를 다시 가져 오는 경우 조치를 취하기 전에 얼마나 오래 기다려야합니까? 즉, 모든 웹 역할이 동시에 가까이 스왑 되나요? This thread은 최대 30 분 동안 이전 콘텐츠가 반환되었다고보고하지만 그 사실을 믿기 어렵습니다. 어쩌면 그들은 캐싱이나 프록시를 사용했을 수도 있습니다.Azure VIP 스왑이 완료되면 어떻게 알 수 있습니까?
실제 VIP 스왑은 수십 초의 순서로, "잠깐만 기다려라."잘 작동 할 것입니다. 즉, 기존 연결은 꽤 오랫동안 지속될 수 있습니다. 동일한 브라우저에서 계속 새로 고침을하는 경우 HTTP 연결 유지로 인해 단일 TCP 소켓을 열어 둘 수 있습니다. VIP 스왑에도 불구하고 소켓은 여전히 열려 있으며 이전 배포에 연결됩니다.
소요 시간은 측정하려는 대상에 따라 다릅니다. 새 배포를 가리 키도록로드 밸런서를 다시 프로그래밍하는 프로세스는 매우 빠릅니다. 모든 사용자가 연결을 끊고 새 연결을 설정하는 프로세스 (및 캐시가 플러시되는 등)는 더 오래 걸릴 수 있습니다.
저는 Azure 측에서 VIP 스왑을 수행하는 실제 물리적 조치와 관련하여 정확한 답변을 모릅니다. 그러나 스왑이 발생하면 DNS 이름 변경이 전파되는 경우가 있습니다. TTL (time to live)이 비교적 작더라도. 이것은 대부분의 ISP가 자신의 서버에서 DNS 캐시를 확인하고 새로운 IP가 이전 이름으로 변경 될 때까지 모든 종류의 DNS 캐싱을 새로 고쳐야하기 때문입니다.
그러나 VIP 스왑에는 DNS 변경이 필요하지 않습니다. – smarx
appname.cloudapp.net에 연결하는 경우에는 그렇지 않지만 사용자 정의 도메인 이름 (www.myname.com)이 포함되어 있으면 다양한 DNS 캐시로 추정되는 것을 보았습니다. 새롭게 승격 된 프로덕션 배포로의 회귀 시간 (분) – Igorek
DNS 변경은 아직 없습니다. 해결하려는 IP 주소는 변경되지 않고 그대로 유지됩니다. 예 : 1.2.3.4는 이전 배포를 끌어 올리는 데 사용되며 이제 새 배포를 끌어 올립니다. 유일한 변경 사항은로드 밸런서입니다. – smarx
감사. 나는 keep-alive에 대해 생각하지 않았고, Refresh를 사용한다고해도 파이어 폭스가 라이브 연결을 유지하고 있음을 알 수있다. keep-alive를 비활성화 한 후에 실험을 다시 시도 할 것입니다. –