라운드 로빈 DNS는 정적 콘텐츠를로드 밸런싱하기에“충분한”것입니까?

웹 사이트 ( http://sstatic.net) 간에 제공되는 공유 된 정적 컨텐츠 세트가 있습니다. 불행히도이 콘텐츠는 현재 전혀로드 밸런싱되지 않습니다. 단일 서버에서 제공됩니다. 해당 서버에 문제가있는 경우 공유 리소스가 필수 공유 자바 스크립트 라이브러리 및 이미지이므로 서버에 의존하는 모든 사이트가 효과적으로 작동 중지됩니다.

단일 서버 종속성을 피하기 위해이 서버에서 정적 컨텐츠를로드 밸런스하는 방법을 찾고 있습니다.

라운드 로빈 DNS는 기껏해야 로우 엔드 (일부 게토 라고도 함 ) 솔루션 이라는 것을 알고 있지만 궁금하지 않습니다. 라운드 로빈 DNS는 정적 콘텐츠의 기본로드 균형 조정을위한 "충분한"솔루션입니다. ?

[dns] [load-balancing] 태그 에서 이에 대한 논의가 있으며 주제에 대한 훌륭한 글을 읽었습니다.

여러 라운드 로빈 A 레코드를 통한 DNS 부하 분산의 일반적인 단점을 알고 있습니다.

• 일반적으로 DNS 레코드로 하트 비트나 오류 감지가 없으므로 회전중인 특정 서버가 다운되면 A 레코드를 DNS 항목에서 수동으로 제거해야합니다.
• DNS 항목이 인터넷을 통해 적극적으로 캐시되기 때문에 TTL (Time to Live)이 전혀 작동하지 않도록 설정해야합니다.
• 클라이언트 컴퓨터는 여러 개의 A 레코드가 있는지 확인하고 올바른 레코드를 선택해야합니다.

그러나 라운드 로빈 DNS는 정적 콘텐츠에 대한 "더 나은 대안을 연구하고 구현하는 동안"더 나은 대안을 연구하고 구현하는 동안 아무것도 아닌 것보다 낫습니다. 아니면 어떤 상황에서도 DNS 라운드 로빈이 무가치 합니까?

Jeff는 동의하지 않습니다.로드 밸런싱은 중복성을 의미하지 않습니다. 실제로는 그 반대입니다. 서버가 많을수록 주어진 순간에 실패 할 가능성이 높습니다. 그렇기 때문에로드 밸런싱을 수행 할 때 중복성이 필수적이지만 안타깝게도 상태 확인을 수행하지 않고로드 밸런싱 만 제공하여 서비스의 안정성을 떨어 뜨리는 솔루션이 많이 있습니다.

DNS 라운드 로빈은 여러 지점에로드를 분산시켜 잠재적으로 지리적으로 분산되어 용량을 늘리는 데 탁월합니다. 그러나 장애 조치를 제공하지는 않습니다. 먼저 어떤 유형의 장애를 다루려고하는지 설명해야합니다. 서버 장애는 표준 IP 주소 인계 메커니즘 (VRRP, CARP, ...)을 사용하여 로컬로 처리해야합니다. 스위치 장애는 서버에서 두 개의 스위치로의 복원 가능한 링크로 처리됩니다. WAN 링크 장애는 라우팅 프로토콜 또는 layer2 솔루션 (예 : 다중 링크 PPP)을 사용하여 사용자와 공급자 간의 다중 링크 설정으로 처리 할 수 ​​있습니다. 사이트 오류는 BGP에서 다루어야합니다. IP 주소는 여러 사이트에 복제되어 사용 가능한 경우에만 인터넷에 알립니다.

귀하의 질문에 따르면 서버 페일 오버 솔루션 만 제공하면됩니다.이 솔루션은 하드웨어와 관련이 없으며 ISP와 계약하지 않기 때문에 가장 쉬운 솔루션입니다. 서버에 적절한 소프트웨어를 설치하기 만하면 가장 저렴하고 안정적인 솔루션입니다.

"haproxy 시스템이 실패하면 어떻게합니까?" 그것은 동일합니다. 로드 밸런싱 및 고 가용성에 haproxy를 사용하는 사람은 모두 두 대의 시스템을 가지고 있으며 ucarp, keepalived 또는 heartbeat 중 하나를 실행하여 그 중 하나를 항상 사용할 수 있도록합니다.

도움이되기를 바랍니다!

로드 밸런싱으로서 빈민가지만 다소 효과적입니다. 로드에서 떨어지는 서버가 하나 있고 여러 서버로 분산하려는 경우 적어도 일시적으로이를 수행하는 것이 좋습니다.

로드 "밸런싱"으로 라운드 로빈 DNS에 대한 여러 가지 유효한 비판이 있으며 단기 반창고 이외의 다른 방법으로는 권장하지 않습니다.

그러나 기본 동기는 단일 서버 종속성을 피하는 것이라고합니다. 죽은 서버를 교체하지 않는 자동화 된 방법이 없으면 가동 중지 시간을 방지하는 방법으로 그다지 가치가 없습니다. (서버를 회전에서 자동으로 가져 오는 방법과 짧은 TTL을 사용하면 빈민가 장애 조치가됩니다. 수동으로도 마찬가지입니다.)

라운드 로빈 된 두 서버 중 하나가 다운되면 고객의 50 %가 실패합니다. 하나의 서버에서만 100 % 이상의 장애가 발생하지만 실제 장애 조치를 수행 한 거의 모든 다른 솔루션이 이보다 낫습니다.

한 서버의 장애 확률이 N 인 경우 두 서버의 경우 확률은 2N입니다. 자동화 된 빠른 장애 조치가 없으면 이 체계 는 일부 사용자에게 장애가 발생할 가능성을 높 입니다.

수동 회전에서 죽은 서버를 취하려는 경우, 당신은 당신이 그렇게 할 수있는 속도에 의해 제한하고 과 는 DNS TTL. 서버가 오전 4시에 죽으면 어떻게합니까? 진정한 장애 조치의 가장 중요한 부분은 밤새 잠을 자게하는 것입니다. 이미 HAProxy를 사용 하고 있으므로 익숙해야합니다. HAProxy는 정확히이 상황을 위해 설계되었으므로이를 사용하는 것이 좋습니다.

라운드 로빈 DNS는 사람들이 생각하는 것과 다릅니다. DNS 서버 소프트웨어 (즉, BIND ) 의 저자 인 우리는 왜 라운드 로빈이 계획대로 작동을 멈추는 지 궁금해하는 사용자를 얻습니다. 일부 캐시는 무엇이든간에 최소 시간 (보통 30-300 초)을 사용하기 때문에 TTL이 0 초라고해도 캐시가 약간 있음을 이해하지 못합니다.

또한 AUTH 서버는 라운드 로빈을 수행 할 수 있지만, 관심있는 서버 (사용자가 말하는 캐시)가 보장 할 수는 없습니다. 즉, 라운드 로빈은 클라이언트의 관점에서 주문을 보증하지 않으며 인증 서버가 캐시에 제공하는 것만 보장합니다.

실제 장애 조치를 원한다면 DNS는 한 단계 일뿐입니다. 두 개의 서로 다른 클러스터에 대해 둘 이상의 IP 주소를 나열하는 것은 좋지 않습니다. 그러나 실제로드 밸런싱을 수행하기 위해 다른 기술 (예 : 간단한 애니 캐스트)을 사용합니다. 나는 보통 DNS가 잘못되어 하드웨어 부하 분산 하드웨어를 멸시합니다. 그리고 DNSSEC가 다가오는 것을 잊지 마십시오.이 영역에서 무언가를 선택하면 해당 지역에 서명 할 때 어떻게되는지 공급 업체에 문의하십시오.

이전에 여러 차례 언급했으며 다시 말하겠습니다. 복원력이 문제라면 DNS 트릭이 답 이 아닙니다 .

최고의 HA 시스템은 고객이 모든 요청에 ​​대해 정확히 동일한 IP 주소를 계속 사용할 수 있도록합니다. 이것이 클라이언트가 실패를 인식하지 못하도록하는 유일한 방법입니다.

따라서 근본적인 규칙은 진정한 복원력을 위해서는 IP 라우팅 수준의 속임수 가 필요하다는 것 입니다. 로드 밸런서 어플라이언스 또는 OSPF "균등 다중 경로"또는 VRRP를 사용하십시오.

반면에 DNS는 주소 기술입니다. 하나의 네임 스페이스에서 다른 네임 스페이스로 매핑하는 것만 존재합니다. 해당 매핑에 대한 단기적인 동적 변경 을 허용하도록 설계되지 않았 으므로 이러한 변경을 시도 할 때 많은 클라이언트가이를 인식하지 못하거나 또는이를 인식하는 데 오랜 시간이 걸립니다.

또한 로드 가 문제가되지 않기 때문에 다른 서버를 핫 스탠바이로 실행할 준비가되었을 수도 있습니다. 멍청한 라운드 로빈을 사용하는 경우 문제가 발생했을 때 사전에 DNS 레코드를 변경해야하므로 핫 스탠바이 서버를 사전에 행동으로 전환하고 DNS를 변경 하지 않을 수 있습니다.

모든 답변을 읽었으며 보지 못한 한 가지는 대부분의 최신 웹 브라우저가 서버가 응답하지 않으면 대체 IP 주소 중 하나를 시도한다는 것입니다. 올바르게 기억한다면 Chrome은 여러 IP 주소를 시도하고 먼저 응답하는 서버를 계속 사용합니다. 내 의견으로는 DNS 라운드 로빈로드 밸런싱은 항상 낫습니다.

BTW : DNS 라운드 로빈이 단순한로드 분배 솔루션이라고 생각합니다.

나는이 스레드에 늦었으므로 내 대답은 아마도 바닥에 홀로 붙어있을 것입니다.

우선, 질문에 대한 정답은 질문에 대답하는 것이 아니라 다음과 같이 말하는 것입니다.

1. "아마도 Windows 네트워크로드 균형 조정을 원할 것입니다." 또는
2. "시간이 지남에 따라 정적 파일을 Cloud Files 또는 S3 와 같은 곳에 배치 하고 CDN이 전 세계적으로 미러링하도록하십시오."

NLB는 성숙하고 작업에 적합하며 설정이 매우 쉽습니다. 클라우드 솔루션에는이 질문의 범위를 벗어난 자체 장단점이 있습니다.

질문

정적 로빈을위한로드 밸런싱 형태의 "우리가 더 나은 대안을 연구하고 구현하는 동안"라운드 로빈 DNS는 초보자로서 충분히 우수합니까?

예를 들어 2 개 또는 3 개의 정적 웹 서버 사이? 예, DNS Round Robin을 서버 상태 확인 과 통합 하고 DNS 레코드에서 사용 불능 서버를 일시적으로 제거 하는 DNS 공급자 가 있기 때문에 무엇보다 좋습니다 . 당신이 얻을 이런 식으로 그래서 괜찮은 부하 분산 및 일부 고 가용성; 설정하는 데 5 분도 걸리지 않습니다.

그러나이 스레드에서 다른 사람들이 설명한주의 사항이 적용됩니다.

• 현재 Microsoft 브라우저는 30 분 동안 DNS 데이터를 캐시 하므로 초기 DNS 캐시 상태에 따라 사용자 하위 집합에 대한 30 분 이상의 장애 조치 시간을보고 있습니다.
• 페일 오버 중에 사용자에게 표시되는 내용은 이상 할 수 있습니다 (정적 컨텐츠에 인증을 사용하지 않고 인증을 구성하지는 않지만 링크는주의해야 할 사항을 표시 함).

다른 솔루션

HAProxy는 환상적이지만 Stack Overflow는 Microsoft 기술 스택에 있으므로 Microsoft로드 밸런싱 및 고 가용성 도구를 사용하면 관리 오버 헤드가 줄어 듭니다. 네트워크로드 균형 조정은 문제의 한 부분을 처리하며 Microsoft는 실제로 L7 HTTP 리버스 프록시 /로드 밸런서를 보유하고 있습니다.

나는 ARR을 직접 사용하지는 않았지만 두 번째 주요 릴리스에 있으며 Microsoft에서 나온 것으로 충분히 테스트 된 것으로 가정합니다. 그것은이 문서를 이해하기 쉽게 여기에, 그들이 볼 방법에 대한 하나 의 정적 및 동적 콘텐츠의 유통 webnodes에, 그리고 여기에 사용하는 방법에 대한 작품이다 NLB와 ARR을 부하 분산 및 고 가용성을 모두 달성 할 수 있습니다.

로드 밸런싱 및 복원 메커니즘으로 DNS Round Robin에 대한 정보를 제공하는 데 기여한 기여자 중 몇 명은 놀랍습니다. 일반적으로 작동하지만 작동 방식을 이해하고 모든 정보가 잘못되어 발생하는 실수를 피해야합니다.

1) 라운드 로빈에 사용되는 DNS 레코드의 TTL은 짧지 만 ZERO는 아니어야합니다. TTL을 0으로 설정하면 탄력성이 제공되는 주요 방법이 중단됩니다.

2) DNS RR은 분산되지만로드 균형을 유지하지는 않지만 대규모 클라이언트 기반에서는 DNS 서버를 독립적으로 쿼리하는 경향이 있기 때문에 우선 순위가 다른 DNS 항목으로 끝납니다. 이러한 다른 첫 번째 선택은 클라이언트가 다른 서버에 의해 서비스되고로드가 분산됨을 의미합니다. 그러나 이는 DNS 쿼리를 수행하는 장치와 결과를 보유하는 기간에 따라 다릅니다. 일반적인 예는 회사 프록시 뒤의 모든 클라이언트 (DNS 쿼리를 수행하는 클라이언트)가 모두 단일 서버를 대상으로하는 것입니다. 하중이 분산되지만 균형이 고르지 않습니다.

3) DNS RR은 클라이언트 소프트웨어가 올바르게 구현하는 한 복원력을 제공합니다 (TTL 및 사용자주의 기간이 너무 짧지 않음). 이는 DNS 라운드 로빈이 순서대로 서버 IP 주소 목록을 제공하기 때문에 클라이언트 소프트웨어는 연결을 수락하는 서버를 찾을 때까지 각 서버 IP 주소에 차례로 연결을 시도해야합니다.

따라서 첫 번째 선택 서버가 다운 된 경우 클라이언트 TCP / IP 연결이 시간 초과되고 TTL 또는주의 범위가 만료되지 않은 경우 클라이언트 소프트웨어는 목록의 두 번째 항목에 대해 다른 연결을 시도합니다. TTL이 만료되거나 목록의 끝에 도달합니다 (또는 사용자가 혐오감을 포기 함).

고장난 서버 목록 (오류)과 TCP / IP 연결 재시도 제한 (클라이언트 구성 오류)은 클라이언트가 실제로 작동하는 서버를 찾기 전에 오랫동안 만들 수 있습니다. TTL이 너무 짧으면 목록의 끝까지 작동하지 않으며 대신 새 DNS 쿼리를 발행하고 새 목록 (다른 순서로)이 제공됩니다.

때로는 클라이언트가 운이 좋지 않고 새 목록이 여전히 깨진 서버로 시작합니다. 시스템에 클라이언트 탄력성을 제공 할 수있는 최상의 기회를 제공하려면 TTL이 일반적인주의 기간보다 길고 클라이언트가 목록의 맨 아래에 오도록해야합니다.

클라이언트가 작동중인 서버를 찾으면 서버를 기억해야하며 다음 연결을 작성해야 할 때 (TLL이 만료되지 않은 한) 검색을 반복해서는 안됩니다. TTL이 길수록 클라이언트가 작업 서버를 검색하는 동안 지연이 발생하는 빈도가 줄어들어 더 나은 환경을 제공합니다.

4) DNS TTL은 자체적으로 발생합니다. DNS 레코드를 수동으로 변경하려는 경우 (예 : 장기간 중단 된 서버 제거) 짧은 TTL을 사용하면 변경 사항이 빠르게 전파 될 수 있습니다 (한 번 해본 후). 문제를 알기까지 걸리는 시간과 수동 변경을 수행하는 것과 TTL이 만료 될 때 일반 클라이언트가 작동중인 서버를 새로 검색해야한다는 사실 사이의 균형을 고려하십시오.

DNS 라운드 로빈은 두 가지 뛰어난 기능을 갖추고있어 광범위한 시나리오에서 매우 비용 효율적이며, 첫 번째는 무료이며, 두 번째는 거의 클라이언트 기반만큼 지리적으로 분산되어 있습니다.

다른 모든 '영리한'시스템이하는 새로운 '오류 단위'를 소개하지는 않습니다. 상호 연결된 요소의 전체로드에서 공통적 인 동시 장애가 발생할 수있는 추가 구성 요소가 없습니다.

'영리한'시스템은 훌륭하고 균형 잡힌 균형 조정 및 페일 오버 메커니즘을 제공하고 조정하는 훌륭한 메커니즘을 도입하지만 궁극적으로 원활한 경험을 제공하기 위해 사용하는 방법은 아킬레스 건입니다. 그럴 경우 시스템 전반에 걸친 완벽한 장애 경험을 제공 할 것입니다.

그렇습니다. DNS 라운드 로빈은 모든 정적 콘텐츠를 한 곳에서 호스팅하는 단일 서버를 넘어서는 첫 단계에있어 "충분히"충분합니다.

Windows Vista 및 Windows 7 은 IPv6 주소 선택을 IPv4로 백 포트 할 때 라운드 로빈에 대한 클라이언트 지원을 다르게 구현 합니다. ( RFC 3484 )

따라서 상당수의 Vista, Windows 7 및 Windows 2008 사용자가있는 경우 ersatz로드 밸런싱 솔루션에서 계획된 사고와 일치하지 않는 동작을 발견 할 수 있습니다.

항상로드 밸런서로 긴 TTL과 함께 라운드 로빈 DNS를 사용했습니다. 브라우저 를 사용하는 HTTP / HTTPS 서비스 에서 실제로 잘 작동 합니다 .

대부분의 브라우저가«다른 IP에서 재시도»를 구현할 때 브라우저 로 스트레스 를 많이받습니다. 그러나 다른 라이브러리 나 소프트웨어가 여러 IP 솔루션을 어떻게 처리할지는 모르겠습니다.

브라우저가 한 서버에서 응답을받지 못하면 자동으로 다음 IP를 호출 한 다음 고정 될 때까지 고정합니다 (아래로 내려간 후 다른 IP를 시도).

2007 년에 다음 테스트를 수행했습니다.

• 내 웹 사이트에 iframe을 추가하여 다음과 같은 라운드 로빈 항목 하나를 가리 킵니다. http://roundrobin.test:10080/ping.php
• 이 페이지는 3 개의 PHP 소켓에서 제공되었으며 3 개의 다른 IP에서 포트 10080에서 모두 청취했습니다 (내 웹 사이트가 실행 중이므로 포트 80에서 테스트 할 여유가 없었습니다)
• 하나의 소켓 (예 : A )이 브라우저가 10080 포트에서 연결할 수 있는지 확인하기 위해 존재했습니다 (많은 회사가 표준 포트 만 허용 함)
• 다른 두 개의 소켓 (예 : B 및 C )은 즉시 활성화 또는 비활성화 할 수 있습니다.

나는 한 시간 동안 실행하고 많은 데이터를 가졌습니다. 결과는 소켓 A 에 대한 적중의 99.5 % 에 대해 소켓 B 또는 C 에 적중 한 것 입니다 (물론 동시에 두 가지를 모두 비활성화하지 않았습니다). 브라우저는 다음과 같습니다. iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... 호환되지 않는 브라우저조차도 제대로 처리했습니다!

오늘까지는 다시 테스트하지 않았지만 언젠가 새로운 테스트를 설정하거나 github에서 코드를 릴리스하여 다른 사람들이 테스트 할 수 있습니다.

중요 사항 : 대부분의 시간 동안 작동하더라도 일부 요청 이 실패 한다는 사실을 제거하지는 않습니다 . POST 요청에도 사용합니다. 응용 프로그램이 작동하지 않는 경우 오류 메시지를 반환하므로 사용자가 데이터를 다시 보낼 수 있으며 브라우저는이 경우 다른 IP를 사용하고 저장이 작동합니다. . 정적 콘텐츠의 경우 실제로 훌륭하게 작동합니다.

따라서 브라우저로 작업하는 경우 정적 또는 동적 콘텐츠에 라운드 로빈 DNS를 사용하면 대부분 괜찮습니다. 서버는 트랜잭션 도중에 중단 될 수 있으며, 최상의로드 밸런서조차도 그러한 경우를 처리 할 수 ​​없습니다. 동적 컨텐츠의 경우 세션 / 데이터베이스 / 파일을 동기식으로 만들어야합니다. 그렇지 않으면이를 처리 할 수 ​​없습니다 (그러나 실제로드 밸런서에서도 마찬가지입니다).

추가 참고 사항 : 을 사용하여 자신의 IP에서 동작을 테스트 할 수 있습니다 iptables. 예를 들어, HTTP 트래픽에 대한 방화벽 규칙 전에 다음을 추가하십시오.

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

( 12.34.56.78당신의 IP는 분명합니다)

DROP포트를 필터링 한 상태로을 사용하지 마십시오 . 브라우저는 시간 초과 될 때까지 기다립니다. 이제 하나의 서버 또는 다른 서버를 활성화하거나 비활성화 할 수 있습니다. 가장 확실한 테스트는 서버 A를 비활성화하고 페이지를로드 한 다음 서버 A를 활성화하고 서버 B를 비활성화하는 것입니다. 페이지를 다시로드하면 브라우저에서 약간의 대기 시간이 표시되고 서버에서로드됩니다. 다시. Chrome에서는 네트워크 패널에서 요청을보고 서버의 IP를 확인할 수 있습니다. 의 General탭에는 Headers이라는 가짜 헤더가 표시 Remote Address:됩니다. 이것은 답변을 얻은 IP입니다.

따라서 하나의 서버에서 유지 관리 모드로 전환해야하는 경우 하나의 iptables REJECT규칙으로 HTTP / HTTPS 트래픽을 비활성화하면 모든 요청이 다른 서버로 이동합니다 (대기 시간이 거의 걸리지 않고 사용자에게는 거의 눈에 띄지 않음).

지금은 두 대의 서버가 있고 DNS를 사용하여 로빈을 각 서버의 IP 주소로 반올림한다고 가정하면 충분한 해결책이라고 생각하지 않습니다. 한 서버가 다운되면 DNS 서버는 다운되었음을 알지 못하며 RR 프로세스의 일부로 해당 IP 주소를 계속 제공합니다. 그러면 50 %의 잠재 고객이 자바 스크립트 나 이미지가없는 깨진 사이트를 보게됩니다.

아마도 두 서버 뒤에있는 Windows NLB가 처리하는 공통 IP 주소를 가리키는 것이 더 쉽습니다. 정적 컨텐츠에 Linux 서버를 사용하지 않는 한, 어딘가에서 읽은 것을 기억한다면?

라운드 로빈 부하 분산은 DNS 영역을 제어 할 때만 작동하므로 서버 목록을 변경하여 적시에 영역 마스터에 푸시 할 수 있습니다.

다른 답변 중 하나에서 언급했듯이 라운드 로빈의 숨겨진 악은 서버와 클라이언트 사이에서 발생할 수있는 DNS 캐싱 으로이 솔루션의 작은 이점을 완전히 무시합니다. DNS TTL을 매우 낮은 값으로 설정하더라도 ISP 또는 클라이언트의 DNS 캐시가 현재 죽은 IP 주소를 활성 상태로 유지하는 시간을 거의 제어 할 수 없습니다.

확실히 SPOF보다 개선되었지만 한계는 없습니다. 서버를 호스팅하는 사람을 살펴보고 그들이 무엇을 제공해야하는지 살펴보고 많은 사람들이 제공 할 수있는 기본적인로드 밸런서 서비스를 제공합니다.

정적 콘텐츠가 S3에 복제 된 단일 서버가있을 수 있으며 기본 서버가 다운되면 S3 CNAME으로 전환 할 수 있습니다. 여러 개의 서버 비용없이 동일한 지연이 발생합니다.

이것은 실제로 당신이 말하는 것과 얼마나 많은 서버를 돌고 있는지에 달려 있습니다. 한 번에 여러 서버에서 실행되는 사이트가 있었는데 당시 주로 초보자 였기 때문에 DNS 라운드 로빈을 사용했는데 실제로 큰 문제는 아니 었습니다. 충돌하지 않았기 때문에 큰 문제는 아니 었습니다. 그것은 정말 어리석은 비 복잡한 시스템 이었기 때문에 견딜 수 있었고 트래픽 수준은 꽤 일정했습니다. 교통 체증으로 인해 추락했다면 낮에 있었으며 쉽게 처리 할 수있는 것이 었습니다. 정적 콘텐츠가 자체적으로 충돌을 일으키지 않을 정도로 단순하다고 말합니다.

하드웨어 고장 등을 제외하고는 서버가 얼마나 안정적입니까? 이 콘텐츠에 대한 트래픽은 "스파이 키"입니까? 아파치 (Apache) 또는 비교적 평평한 트래픽을 똑바로 가정하면 많은 충돌이 발생하지 않으며 라운드 로빈은 "충분히 좋다"고 말할 수 있습니다.

나는 100 % HA 솔루션을 설교하지 않기 때문에 투표를하지 않을 것이라고 확신하지만 그것은 당신이 요구 한 것이 아닙니다. 그것은 솔루션 대 노력으로 기꺼이 받아들이려는 것에 달려 있습니다.

로드 밸런싱을 위해 RR DNS를 사용하고 있다면 문제가 없지만 그렇지 않습니다. 중복 서버를 활성화하는 데 사용하고 있습니다.이 경우에는 좋지 않습니다.

이전 게시물에서 말했듯이 심장 박동을 감지하고 다시 올 때까지 심장 박동을 멈추려면 무언가가 필요합니다.

좋은 소식은 스위치 나 Windows에서 하트 비트를 실제로 저렴하게 사용할 수 있다는 것입니다.

다른 OS에 대해서는 Dunno가 있지만 거기에도 있다고 가정합니다.

ssh와 같이 사용하는 고정 IP 외에 각 서버에 추가 IP 주소를 할당하고이를 DNS 풀로 가져가는 것이 좋습니다. 그런 다음 서버가 실패 할 경우 일부 소프트웨어를 사용하여 이러한 IP 주소를 전환합니다. 예를 들어 하트 비트 또는 CARP가이를 수행 할 수 있지만 다른 솔루션이 있습니다.

이는 서비스 클라이언트에 대해 설정을 변경할 필요가 없으며 DNS 캐싱 또는 TTL에 대해 걱정할 필요가 없지만 DNS 라운드 로빈 "로드 밸런싱"을 여전히 활용할 수 있다는 장점이 있습니다. .

특히 정적 상자에 여러 개의 IP를 가질 수 있다면 아마도 작업을 수행 할 것입니다. 하나의 "고정 컨텐츠 제공"IP와 하나의 "기계 관리"IP가 있습니다. 상자가 다운되면 기존 HA 솔루션 또는 수동 개입을 사용하여 실패한 시스템의 IP를 다른 "클러스터 구성원"중 하나 또는 완전히 새로운 시스템 (가장 빠른 속도에 따라)으로 가져올 수 있습니다 그것을 시작하고 실행하십시오).

그러나 이러한 솔루션에는 몇 가지 작은 문제가 있습니다. 로드 밸런싱은 완벽한 위치에 있지 않으며 수동 개입에 의존하는 경우 일부 방문자에게 서비스가 중단 될 수 있습니다.

하드웨어로드 밸런서는 DNS 라운드 로빈보다로드를 공유하고 "클러스터 가동 시간"을 제공하는 작업을 더 잘 수행 할 수 있습니다. 반대로, 그것은 구매, 전력 및 냉각이 필요하고 (아마도 아직 그렇지 않은 경우) 시간이 필요한 하드웨어의 하나 (또는 ​​이상적으로 HA 클러스터에 LB가 있기 때문에 이상적입니다) 전용로드 밸런서가 있음).

간결하게 질문에 대답하려면, 나는 그것을 말할 것이다 ( "우리가 연구하고 더 나은 대안을 구현하면서"라운드 로빈, 선발로 충분히 아무것도보다 더 좋은 DNS를 부하의 형태는? 우리의 정적 콘텐츠에 대한 균형) 이다 아무것도보다 더, 그러나 다른 형태의로드 밸런싱을 계속 연구해야합니다.

몇 년 전에 Windows로드 균형 조정을 조사 할 때 Microsoft 웹 팜이 DNS 라운드 로빈과 함께 여러로드 균형 조정 그룹으로 구성되었다는 문서를 보았습니다. 각 네임 스페이스에서 여러 DNS 서버가 응답 할 수 있으며 Microsoft의로드 밸런싱은 자동 복구되므로 중복성과로드 밸런싱을 모두 제공합니다.

단점 : 최소 4 개의 서버 (2 개의 서버 x 2 개의 그룹)가 필요합니다.

Schof의 답변에 대한 Jeff의 의견에 대답하면 HAProxy 서버간에 DNS 라운드 로빈을 수행하는 방법이 있습니까?

실제 솔루션을 배치하는 동안 당신을 데려 갈 정도로 충분히 한계가 있습니다. 당신이 말했듯이, TTL은 상당히 낮게 설정되어야합니다. 그러나 문제가있는 동안 문제가있는 머신을 DNS에서 꺼내면 부작용이 있습니다. SvrA, SvrB 및 SvrC가 컨텐츠를 전달하고 SvrA가 다운되었다고 가정하십시오. DNS에서 DNS를 꺼내고 낮은 TTL에 의해 정의 된 짧은 시간이 지나면 해결 프로그램은 작동중인 다른 서버 (SvrB 또는 SvrC)를 알아냅니다. SvrA를 온라인으로 되돌려 다시 DNS에 넣습니다. 일부 사람들에게는 짧은 다운 타임이 있고 다른 사람들에게는 짧은 다운 타임이 없습니다. 크지는 않지만 실행 가능합니다. 정적 서버가 많을수록 다수의 사용자 그룹이 다운 될 가능성이 줄어 듭니다.

인터넷의 토폴로지로 인해 실제로드 밸런싱 솔루션이 제공하는 진정한 밸런싱 배포를 확실히 얻지 못할 것입니다. 나는 여전히 관련된 모든 서버의 부하를 지켜 보았습니다.