본인은 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 연결을 완료해야합니다.
답변
당신의 상황은 우리와 상당히 비슷합니다. 분할 데이터 센터 및 네트워크 계층 유형 장애 조치가 필요합니다.
예산을 책정했다면 원하는 것은 두 개의 데이터 센터, 각각에 대한 여러 IP 전송, 전송 라우터에 BGP 세션을 수행하는 IP 라우터, IP 주소를 글로벌 인터넷에 알리는 것입니다.
이것이 진정한 장애 조치를 수행하는 유일한 방법입니다. 라우터가 서버에 대한 경로가 더 이상 유효하지 않다는 것을 알게되면 (여러 가지 방법으로 수행 할 수 있음) 해당 경로에 대한 광고를 중단하고 트래픽이 다른 사이트로 이동합니다.
문제는 한 쌍의 에지 라우터의 경우 처음 에이 설정을 수행하는 데 상당히 많은 비용이 드는 것입니다.
그런 다음이 모든 것의 배후에 네트워킹을 설정해야하며, 하나의 데이터 센터로 들어오는 트래픽을 라우팅 할 수 있도록 사이트 간 일종의 Layer2 연결을 지점 간 링크로 고려할 수 있습니다. 기본 사이트가 부분적으로 실패한 경우 다른 사이트로 직접 연결됩니다.
BGP 멀티 홈 / 멀티 로케이션 모범 사례 및 탄력성을 향상시키는 가장 좋은 방법은 무엇입니까? 비슷한 문제에 대해 질문 한 내용입니다.
부끄러움의 GSLB 페이지는 몇 가지 중요한 사항을 제기하므로 개인적으로 BGP 라우팅을 위해 GSLB를 기꺼이 선택하지 않을 것입니다.
네트워크의 다른 장애 지점도 살펴 봐야합니다. 모든 서버에 2 개의 NIC (2 개의 개별 스위치에 연결됨), 2 개의 PSU가 있고 서비스가 여러 백엔드 서버, 중복 쌍 또는로드 밸런스 클러스터로 구성되어 있는지 확인하십시오.
기본적으로 여러 A 레코드를 통한 DNS “로드 밸런싱”은 DNS 서버가 각 서버에 얼마나 많은로드가 있는지에 대한 개념이 없기 때문에 “로드 공유”입니다. 싸다 (무료).
GSLB 서비스는 서버의로드 방식과 가용성에 대한 개념을 가지고 있으며 장애에 대한 저항력을 제공하지만 DNS 캐싱 및 페깅과 관련된 문제로 인해 여전히 어려움을 겪고 있습니다. 이것은 저렴하지만 약간 더 좋습니다.
견고한 인프라가 뒷받침되는 BGP 라우팅 네트워크는 좋은 가동 시간을 보장하는 유일한 방법 인 IMHO입니다. Cisco / Juniper / etc 라우터 대신 경로 서버를 사용하여 비용을 절약 할 수 있지만 하루가 끝나면이 서버를 매우 신중하게 관리해야합니다. 이것은 저렴한 옵션이나 가볍게 수행 할 수있는 것은 아니지만 매우 보람있는 해결책이며 소비자가 아닌 공급자로서 인터넷에 접속하게합니다.
답변
좋아, 이것은 얼마 전에 요청되었지만 지금은 처음보고 있습니다.
코드 스 니펫은 외부 자바 스크립트 (사이트 코드 상단)이며 고객 웹 사이트를 보여주기 전에 방문자의 브라우저가 앱 서버에 접속합니다.
당신은해야합니다 :
- Javascript 파일을 전문적이고 우수한 컨텐츠 제공 네트워크에 배치하십시오. 즉, 이미 해당 전문 지식을 보유한 사람으로부터 Javascript를 제공하는 고 가용성 HTTP (S)를 구매하십시오.
- 폴백 상태가 양호하도록 자바 스크립트를 프로그래밍하십시오. 즉, 앱 서버가 빠르게 응답하지 않으면 최종 사용자는 수정되지 않은 일반 페이지를 보게됩니다.
실제로 다른 일을하는 것은 무책임합니다. 나는 당신이 이미 이것을 가지고 있다고 가정합니다.
노하우가없는 경우 BGP 라우팅 트릭을 기반으로 서비스를 제공 해서는 안됩니다 . 복잡한 BGP 라우팅 시나리오는 구현하기가 쉽지 않습니다. 도메인 관련 지식이없는 경우 직접 수행하지 마십시오.
귀하의 질문 자체는 약간 혼란 스럽습니다. 고 가용성 서비스를 작성하는 방법에 대한 분석은 애플리케이션 데이터 부터 시작합니다. 이것이 “상태”이기 때문입니다. 상태 비 저장 부품은 고 가용성을 제공하기 쉽고 상태 전체 부품은 그렇지 않습니다. 따라서 서버와 DNS에 중점을 두는 대신 애플리케이션이 상태를 유지하는 위치를 살펴보십시오 . 거기에서 최적화하고 스택 오버플로에 대한 알고리즘 조언을 요청하는 것으로 시작하십시오. Javascript 파일 fx에서 트랜잭션 개념과 스마트 서버 재 시도를 구현할 수 있습니까?
답변
실제로 geodns 및 dns 장애 조치를 결합하면 분할 테스트 활동에 도움이되도록 원하는 것을 업그레이드 할 수 있습니다.
같은 서버에 있더라도 그룹 A를 ip 1로, 그룹 B를 ip 2로 보내면 테스트 그룹을 분리 할 수 있습니다. 그룹 A와 그룹 B는 서로 다른 지역에 있습니다. 공정하게 말하면, 다음 날 / 주 / 월로, 지리적 차이를 허용하도록 그룹을 뒤집습니다. 당신의 방법론에서 엄격해야합니다.
http://edgedirector.com 의 geodns / failover dns 서비스 가이를 수행 할 수 있습니다.
공개 : 나는 위의 링크와 관련이 있으며, 여기에서 어리석은 dns 트릭을 적용하여 분할 테스트에 관한 기사를 연구하는 중입니다.
