여러 데이터 센터 및 HTTP 트래픽 : DNS Round Robin은 즉각적인 페일 오버를 보장하는 유일한 방법입니까?

동일한 도메인을 가리키는 다중 A 레코드는 저렴한로드 밸런싱 기술로 DNS 라운드 로빈을 구현하는 데 거의 독점적으로 사용되는 것 같습니다.

DNS RR에 대한 일반적인 경고는 고 가용성에 적합하지 않다는 것입니다. 1 개의 IP가 중단되면 클라이언트는 몇 분 동안 계속 사용합니다.

로드 밸런서는 종종 더 나은 선택으로 제안됩니다.

두 주장 모두 완전히 사실이 아닙니다.

1. 트래픽이 HTTP 인 경우 대부분의 HTML 브라우저는 이전 DNS가 다운 된 경우 새로운 DNS 조회없이 다음 A 레코드를 자동으로 시도 할 수 있습니다. 여기 3.1 장 과 여기를 읽으 십시오 .

2. 여러 데이터 센터가 관련된 경우 DNS RR은 트래픽을 분산시킬 수있는 유일한 옵션입니다.

따라서 여러 데이터 센터와 HTTP 트래픽에서 DNS RR을 사용하는 것이 하나의 데이터 센터가 다운 될 때 즉각적인 장애 조치를 보장하는 유일한 방법이라는 것이 사실입니까?

감사,

발렌티노

편집하다:

• 물론 각 데이터 센터에는 핫 스페어가있는 로컬로드 밸런서가 있습니다.
• 즉각적인 장애 조치를 위해 세션 선호도를 희생해도됩니다.
• AFAIK가 DNS가 다른 데이터 센터 대신 데이터 센터를 제안하는 유일한 방법은 해당 데이터 센터와 연결된 IP (또는 IP)로만 응답하는 것입니다. 데이터 센터에 도달 할 수없는 경우 해당 IP도 모두 도달 할 수 없습니다. 즉, 스마트 HTML 브라우저가 다른 A 레코드를 즉시 시도 할 수 있더라도 로컬 캐시 항목이 만료되고 새로운 DNS 조회가 완료되고 새로운 작동중인 IP를 가져 오기 전까지 모든 시도가 실패합니다 (DNS는 자동으로 실패시 새로운 데이터 센터). 따라서 "스마트 DNS"는 즉각적인 장애 조치를 보장 할 수 없습니다.
• 반대로 DNS 라운드 로빈이 허용합니다. 하나의 데이터 센터에 장애가 발생하면 스마트 HTML 브라우저 (대부분의 브라우저)가 다른 캐시 된 A 레코드를 즉시 다른 (작동중인) 데이터 센터로 점프합니다. 따라서 DNS 라운드 로빈은 세션 선호도 또는 최저 RTT를 보장하지 않지만 클라이언트가 "스마트 한"HTML 브라우저 인 경우 즉각적인 페일 오버를 보장 할 수있는 유일한 방법 인 것 같습니다.

편집 2 :

• 어떤 사람들은 TCP Anycast를 결정적인 해결책으로 제안합니다. 에서 이 종이 (6 장) 애니 페일 위에 해당 설명 BGP 융합에 관한 것이다. 이러한 이유로 Anycast는 15 분에서 20 초까지 완료 할 수 있습니다. 토폴로지가이를 위해 최적화 된 네트워크에서 20 초가 가능합니다. 아마도 CDN 운영자 만이 그러한 빠른 장애 조치를 허용 할 수 있습니다.

편집 3 : *

• DNS 조회 및 추적 경로 (일부 전문가가 이중 확인 가능)를 수행 한 결과 :
  • TCP Anycast를 사용하는 유일한 CDN은 CacheFly 인 것으로 보이며 CDN 네트워크 및 BitGravity와 같은 다른 운영자는 CacheFly를 사용합니다. 가장자리를 리버스 프록시로 사용할 수없는 것 같습니다. 따라서 즉시 장애 조치를 부여하는 데 사용할 수 없습니다.
  • Akamai와 LimeLight는 지리 인식 DNS를 사용하는 것 같습니다. 그러나! 여러 개의 A 레코드를 반환합니다. traceroutes에서 반환 된 IP가 동일한 데이터 센터에있는 것 같습니다. 따라서 하나의 데이터 센터가 다운 될 때 이들이 100 % SLA를 제공 할 수있는 방법에 당황했습니다.

"DNS Round Robin"이라는 용어를 사용할 때 일반적으로 OP가 설명하는 "저렴한로드 균형 조정 기술"의 의미를 의미합니다.

그러나 이것이 DNS를 글로벌 고 가용성에 사용할 수있는 유일한 방법은 아닙니다. 대부분의 경우 (기술) 배경이 다른 사람들이 의사 소통하기가 어렵습니다.

최상의로드 밸런싱 기술 (돈이 문제가되지 않는 경우) 은 일반적으로 다음과 같이 간주됩니다.

1. 애니 캐스트의 '지능형'DNS 서버의 글로벌 네트워크
2. 전 세계적으로 분산 된 데이터 센터 세트
3. 각 DNS 노드는 Split Horizon DNS를 구현합니다.
4. 가용성 및 트래픽 흐름의 모니터링은 '지능형'DNS 노드에 어떤 방식 으로든 제공됩니다.
5. 있도록 사용자의 DNS 요청이 IP 애니 캐스트를 통해 가장 가까운 DNS 서버로 흐르고 ,
6. 이 DNS 서버 는 '지능형'분할 수평선 DNS를 통해이 최종 사용자에게 가장 가까운 / 최상의 데이터 센터를 위해 낮은 TTL A 레코드 / A 레코드 세트를 전달합니다.

DNS 응답은 상태가없고 거의 매우 짧기 때문에 DNS에 애니 캐스트를 사용하는 것이 좋습니다. 따라서 BGP 경로가 변경되면 DNS 쿼리를 중단 할 가능성이 거의 없습니다.

애니 캐스트는 길고 상태가 좋은 HTTP 대화에 적합하지 않으므로이 시스템은 분할 수평선 DNS를 사용합니다. 클라이언트와 서버 간의 HTTP 세션은 하나의 데이터 센터에 보관됩니다. 일반적으로 세션을 중단하지 않고 다른 데이터 센터로 장애 조치 할 수 없습니다.

"A 레코드 세트"에 표시된대로 'DNS Round Robin'이라고하는 것을 위의 설정과 함께 사용할 수 있습니다. 일반적으로 각 데이터 센터의 여러 고 가용성로드 밸런서에 트래픽로드를 분산시키는 데 사용됩니다 (따라서 중복성을 향상시키고 더 작거나 저렴한로드 밸런서를 사용하고 단일 호스트 서버의 Unix 네트워크 버퍼를 압도하지 않음).

따라서 여러 데이터 센터와 HTTP 트래픽에서 DNS RR을 사용하는 것이 고 가용성을 보장하는 유일한 방법이라는 것이 사실입니까?

'DNS Round Robin'이 단순히 도메인에 대해 여러 개의 A 레코드를 전달한다는 의미는 아닙니다. 그러나 DNS를 영리하게 사용하는 것이 모든 글로벌 고 가용성 시스템에서 중요한 구성 요소라는 것은 사실입니다. 위의 방법은 일반적인 방법 중 하나입니다.

편집 : 구글 백서 "CDN 성능을 최적화하기 위해 엔드 투 엔드 경로 정보를 넘어서 다" 는 최고의 최종 사용자 성능을 위해 세계적인로드 분배에서 최첨단으로 보입니다.

편집 2 : OP가 연결된 "DNS 기반 .. GSLB .. 작동하지 않습니다" 라는 기사를 읽었으며 좋은 개요입니다. 위에서 읽으십시오.

"브라우저 캐싱 문제에 대한 솔루션"섹션에서는 여러 장애 조치를위한 유일한 솔루션으로 여러 데이터 센터를 가리키는 여러 A 레코드가있는 DNS 응답을 옹호합니다.

하단 근처의 "워터 링"섹션에서 클라이언트가 무작위로 연결되어 종종 '느린'속도를 갖기 때문에 여러 대륙의 데이터 센터를 가리키는 경우 여러 개의 A 레코드를 전송하는 것이 좋지 않다는 점에서 분명히 확장됩니다. 다른 대륙의 DC. 따라서 이것이 제대로 작동하려면 각 대륙에 여러 데이터 센터가 필요합니다.

이것은 나의 단계 1-6과 다른 해결책입니다. 나는 이것에 대한 완벽한 대답을 제공 할 수 없습니다. Akamai 또는 Google과 같은 DNS 전문가가 필요하다고 생각합니다.이 중 많은 부분이 실용적인 노하우로 귀결되기 때문 입니다. 오늘날 배포 된 DNS 캐시 및 브라우저의 한계. AFAIK, 1-6 단계는 Akamai가 DNS를 사용하여 수행하는 작업입니다 (누군가 확인할 수 있습니까?).

모바일 브라우저 포털 (휴대폰)에서 PM으로 일한 느낌은 브라우저의 다양성과 수준 이 놀라 울 정도로 크다는 것 입니다. 저는 개인적으로 최종 사용자 터미널이 '올바른 일을'해야하는 HA 솔루션을 신뢰하지 않습니다. 따라서 현재 세션을 중단하지 않고 글로벌 순간 장애 조치를 수행 할 수 없다고 생각합니다.

위의 1-6 단계는 필수품 기술로 제공되는 것 중 최고라고 생각합니다. 이 솔루션에는 즉각적인 장애 조치가 없습니다.

Akamai, Google 등의 DNS 전문가 중 한 명이 와서 나를 잘못 증명하고 싶습니다. :-)

귀하의 질문은 "DNS 라운드 로빈은 즉각적인 페일 오버를 보장하는 유일한 방법입니까?"입니다.

답은 "DNS 라운드 로빈은 결코 즉각적인 페일 오버를 보장하는 올바른 방법이 아닙니다"입니다.

(적어도 자체는 아님)

즉각적인 페일 오버를 달성하는 올바른 방법은 BGP4 라우팅을 사용하여 두 사이트가 동일한 IP 주소를 사용하는 것입니다. 이를 사용하여 인터넷의 핵심 주소 지정 기술 을 사용하는 대신 인터넷의 핵심 라우팅 기술을 사용 하여 요청을 올바른 데이터 센터로 라우팅 합니다 .

가장 간단한 구성 에서는 장애 조치 만 제공합니다. 또한 라우팅에 불안정한 경우 전환 시점에 TCP 기반 프로토콜이 실패한다는 경고와 함께 Anycast를 제공하는 데 사용할 수도 있습니다.

따라서 여러 데이터 센터와 HTTP 트래픽에서 DNS RR을 사용하는 것이 고 가용성을 보장하는 유일한 방법이라는 것이 사실입니까?

분명히 허위 주장입니다. 귀하는 Google, Akamai, Yahoo 만 검토하여 유일한 솔루션으로 round-robin [*] 응답을 사용하지 않는지 확인해야합니다 (일부 방법은 다른 방법과 함께 사용할 수 있음) .)

가능한 옵션이 많이 있지만 서비스 / 응용 프로그램에 따라 다른 제약 조건이 무엇인지에 따라 달라집니다.

IP 주소의 '페일 오버 (fail-over)'를 준비하는 경우, 단순 배치 된 서버 접근 방식에서 라운드 로빈 기술을 사용할 수 있으며 서버 장애에 대해 걱정할 필요가 없습니다. 그러나 대부분의 경우로드 밸런싱 기술, 단일 IP 주소 및로드 밸런서 간의 페일 오버를 선택합니다.

단일 세션에 대한 모든 요청이 동일한 서버로 이동해야하지만 다른 지역 서버 클러스터에 요청을 분산시키고 싶습니까? 라운드 로빈은 적합하지 않습니다. 주어진 클라이언트가 매번 동일한 물리적 서버 클러스터에 액세스 할 수 있도록하는 작업을 수행해야합니다 (서버 오류와 같은 '예외'가 발생하는 경우는 제외). DNS 쿼리에서 일관된 IP 주소를 받거나 동일한 물리적 서버 클러스터로 라우팅됩니다. 이를위한 솔루션에는 다양한 상업용 및 비상업적 DNS "로드 밸런서"또는 (네트워크를보다 잘 제어 할 수있는 경우) BGP 네트워크 광고가 포함됩니다. 자신의 도메인 이름 서버가 완전히 다른 응답을 제공하도록 간단하게 정렬 할 수 있습니다 (그러나 DNS 요청이 모든 곳에서 전송 될 수 있으므로

[* DNS 용어의 'RR'은 "리소스 레코드"를 의미하므로 "round-robin"을 사용하겠습니다.]

당신을 위해 아주 좋은 관찰 vmiazzo +1! 나는 당신이 어디에 있는지 정확히 알고 있습니다.이 CDN이 어떻게 마법을 수행하는지에 대해 당황했습니다.

다음은 CDN이 어떻게 네트워크를 운영하는지에 대한 추측입니다.

• 가장 가까운 데이터 센터를 확보하려면 Anycast DNS (Jesper Mortensen에서 언급)를 사용하십시오.
• 그들은 서로 다른 데이터 센터에 걸쳐 로컬 네트워크 를 운영하여 서로 다른 데이터 센터 의 호스트에서 CARP 와 같은 것을 할 수 있습니다.

또는

• 그들은 고용 게이트웨이 균형 프로토콜을로드 라우터 나에 HSRP (Hot Standby Router Protocol)를 . 데이터 센터 중단을 처리합니다.
• 여러 개의 IP를 포함하는 이유는 클라이언트가 다시 시도하기 때문에 클라이언트가 다시 시도 할 때 라우팅 경로가 변경되었을 수 있습니다.

다음 솔루션이 나를 위해 지금 노력하고 있습니다 :-DNS는 여러 IP를 반환합니다.

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• 사용 가능한 서버에 지능적으로 전달되는 (또는 유지 관리 페이지에서 제공) Amazon 클라우드의 역방향 프록시에 대한 마지막 진입 점

리버스 프록시는 여전히 타격을 입지 만 봇은 기본 프록시만큼 무겁습니다.

RFC 2782 (http, imap, ...와 같은 서비스에 MX / 우선 순위와 동일하게 적용됨)가 어떤 종류의 브라우저에서도 구현되지 않는 이유는 무엇입니까? 일이 더 쉬울 것입니다 ... Mozilla에서 10 년 동안 열린 버그가 있습니다 !!! 상용로드 밸런서 업계의 종말이 될 것이기 때문에 ??? 나는 그것에 대해 매우 실망합니다.

2- Quagga를 사용하여 Anycast 로이 작업을 수행 할 수 있습니다

(Anycast가 TCP에 좋지 않다는 정보가 있더라도 CacheFly와 같은 일부 대기업이 있습니다)

이 질문에 답하는 사람들이 실제로 전세계의 대규모 서버 네트워크를 운영하고있는 것이 궁금합니다. Google은 라운드 로빈을 사용하고 있으며 회사는 수년 동안 사용했습니다. 몇 가지 제한 사항이 있지만 꽤 잘 작동 할 수 있습니다. 예, 다른 조치로 보강해야합니다.

실제 키는 서버가 다운되면 딸꾹질을 기꺼이 받아들이는 것입니다. 서버의 플러그를 뽑을 때 브라우저가 해당 서버에 액세스하려고하면 브라우저가 IP 주소가 다운되었음을 알게되는 동안 1 분 정도 지연됩니다. 그러나 다른 서버로 매우 빠르게 이동합니다.

그것은 잘 작동하며 많은 문제를 일으킨다 고 주장하는 사람들은 자신이 말하는 것을 모릅니다. 올바른 디자인이 필요합니다.

장애 조치가 짜증납니다. 최상의 HA는 항상 모든 자원을 사용합니다.

저는 1986 년부터 HA와 함께 일해 왔습니다. 장애 조치 시스템을 만들기 위해 광범위한 교육을 받았으며 장애 조치의 팬이 아닙니다.

또한 RR은 능동적 이라기보다는 수동적이라하더라도 부하를 분산시키는 역할을합니다. Google 서버 로그는 각 서버에서 적절한 비율의 트래픽을 명확하게 보여줍니다.

또 다른 매우 간단한 방법은 DNS A 또는 CNAME 레코드에서 낮음 (필요에 따라 낮은 수준) TTL을 사용하고이 레코드를 업데이트하여 사용할 IP를 선택하는 것입니다.

우리는 2 개의 ISP와 여러 공공 서비스를 가지고 있으며 3 년 동안 고 가용성을 위해이 방법을 성공적으로 사용하고 있습니다.

이 작업의 한 스패너는 많은 ISP가 설정된 간격 동안 레코드를 캐시하고 TTL 설정을 완전히 무시하는 리졸버를 잘못 구성했다는 것입니다. 그렇게해서는 안되며 변명의 여지가 없지만 슬프게도 수많은 웹 사이트와 서비스를 마이그레이션 한 경험에서 비롯됩니다.

TCP Anycast는 실제로 매우 안정적이며 적어도 CacheFly (2002 년 이후), Prolexic 및 BitGravity에서 사용됩니다. TCP Anycast에 대한 좋은 프레젠테이션은 NANOG 37에서 이루어졌습니다 : http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

다중 A 레코드는 가능한 단일 실패 지점을 제거 할 수있는 유일한 방법입니다. 다른 솔루션은 들어오는 모든 요청이 서버와 클라이언트 사이의 단일 장치를 통과하도록합니다.

따라서 절대 중복성을 위해서는 필요합니다. 그렇기 때문에 Google이 제공하는 서비스 또는 지속적인 서비스 가용성을 보장하려는 다른 사람입니다.

이것이 사실 인 이유는 분명합니다. 여러 A 레코드가 요청이 클라이언트 브라우저로 라우팅되는 지점을 이동하는 유일한 방법입니다. 다른 방법은 클라이언트 브라우저와 서버 사이에서 장애가 발생할 수있는 단일 지점에 의존하여 서비스를 중단시킵니다. A 레코드를 사용하면 클라이언트에서 서버로의 유일한 단일 실패 지점이 클라이언트 자체가됩니다.

A 레코드를 여러 개 설정하지 않은 경우 다운 타임을 요청하는 중입니다 ...

이 방법은 분명히로드 밸런싱에 의존 할 수 없습니다.