본인은 visualwebsiteoptimizer.com /을 소유하고 운영합니다 . 이 앱은 고객이 웹 사이트에 삽입하여 특정 측정 항목을 추적하는 코드 스 니펫을 제공합니다. 코드 스 니펫은 외부 자바 스크립트 (사이트 코드 상단)이므로 고객 웹 사이트를 표시하기 전에 방문자의 브라우저가 앱 서버에 접속합니다. 앱 서버가 다운되는 경우 브라우저는 시간이 초과되기 전에 (보통 60 초) 연결 설정을 계속 시도합니다. 당신이 상상할 수 있듯이, 우리는 웹 사이트 방문자뿐만 아니라 고객의 웹 사이트 방문자의 경험에도 부정적인 영향을 미치기 때문에 어떤 시나리오에서도 앱 서버를 다운시킬 여유가 없습니다!
현재 다른 데이터 센터 (실제로는 다른 대륙)에 위치한 하나의 백업 서버와 함께 DNS 장애 조치 메커니즘을 사용하고 있습니다. 즉, 우리는 3 개의 개별 위치에서 앱 서버를 모니터링하고 다운이 감지되는 즉시 백업 서버 IP를 가리 키도록 A 레코드를 변경합니다. 이것은 대부분의 브라우저에서 잘 작동하지만 (TTL이 2 분이므로) IE는 DNS를 30 분 동안 캐시하여 거래 킬러 일 수 있습니다. 당사의 최근 게시물 인 visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-down-for-a-website-30-minutes/를 참조하십시오.
따라서 앱 데이터 센터에 심각한 중단이 발생하는 경우 거의 즉시 장애 조치를 수행하기 위해 어떤 종류의 설정을 사용할 수 있습니까? 여기 읽어 www.tenereillo.com/GSLBPageOfShame.htm 여러 A 레코드를 가진 것은 해결책이 있지만, 우리는 (아직) 세션 동기화를 감당할 수 없습니다. 우리가 탐구하는 또 다른 전략은 두 개의 A 레코드를 보유하는 것입니다. 하나는 앱 서버를 가리키고 다른 하나는 역방향 프록시 (다른 데이터 센터에 있음)를 가리키며 기본 프록시 서버가 작동하면 백업 서버로 작동합니다. 이 전략이 합리적이라고 생각하십니까?
우선 순위를 확인하기 위해 자체 웹 사이트 또는 앱을 유지할 수는 있지만 가동 중지 시간으로 인해 고객의 웹 사이트 속도가 느려지지는 않습니다. 따라서 앱 서버가 다운 된 경우 기본 애플리케이션 응답으로 응답하지 않습니다. 빈 응답으로도 충분할 것입니다. 브라우저가 해당 HTTP 연결을 완료해야합니다.