DNS 장애 조치가 권장되지 않는 이유는 무엇입니까?

읽을 때 DNS가 설계된 것이 아니기 때문에 DNS 장애 조치가 권장되지 않는 것 같습니다. 그러나 중복 콘텐츠를 호스팅하는 서로 다른 서브넷에 두 개의 웹 서버가있는 경우 한 서버가 다운 될 때 모든 트래픽이 라이브 서버로 라우팅되도록하는 다른 방법에는 어떤 것이 있습니까?

나에게 그것은 DNS 장애 조치가 유일한 장애 조치 옵션 인 것처럼 보이지만 합의는 좋은 옵션이 아닙니다. 그러나 DNSmadeeasy.com과 같은 서비스가이를 제공하므로 이점이 있어야합니다. 다른하실 말씀 있나요?

'DNS 장애 조치 (failover)'란 DNS 라운드 로빈이 일부 모니터링 (예 : DNS 호스트 이름에 대한 여러 IP 주소 게시 및 모니터링에서 서버가 다운되었음을 감지 할 때 사용 불능 주소 제거)과 결합되었음을 의미합니다. 트래픽이 적고 규모가 작은 웹 사이트에서 사용할 수 있습니다.

의도적으로 DNS 요청에 응답하면 전달한 응답에 대한 TTL (Time To Live)도 제공합니다. 다시 말해, 다른 DNS 서버와 캐시에 "이 답변을 저장하고 다시 확인하기 전에 x 분 동안 사용할 수 있습니다"라고 말합니다. 단점은 다음과 같습니다.

• DNS 장애 조치를 사용하면 알 수없는 비율의 사용자가 다양한 양의 TTL로 DNS 데이터를 캐시하게됩니다. TTL이 만료 될 때까지 이들은 죽은 서버에 연결될 수 있습니다. 장애 조치를 완료하는 방법보다이 방법이 더 빠릅니다.
• 위의 내용으로 인해 TTL을 5-10 분 정도로 설정하는 경향이 있습니다. 그러나이 값을 높게 설정하면 (매우 작은) 성능 이점이 있으며 네트워크 트래픽에 짧은 결함이 있어도 DNS 전파가 안정적으로 작동하는 데 도움이 될 수 있습니다. 따라서 DNS 기반 장애 조치 (failover)를 사용하면 높은 TTL이 발생하지만 높은 TTL은 DNS의 일부이므로 유용 할 수 있습니다.

가동 시간을 늘리는 가장 일반적인 방법은 다음과 같습니다.

• 서버를 같은 LAN에 배치
• 고 가용성 전원 및 네트워크 평면이있는 데이터 센터에 LAN을 배치하십시오.
• HTTP로드 밸런서를 사용하여 개별 서버 장애시로드 및 페일 오버를 분산시킵니다.
• 방화벽,로드 밸런서 및 스위치에 필요한 중복 / 예상 가동 시간을 확보하십시오.
• 전체 데이터 센터 장애 및 간혹 미러링 할 수없는 스위치 / 데이터베이스 서버 / 기타 리소스 장애에 대한 통신 전략을 마련하십시오.

소수의 웹 사이트는 다중 데이터 센터 설정을 사용하며 데이터 센터 간 '지리 균형 조정'을 사용합니다.

DNS 장애 조치는 확실히 훌륭하게 작동합니다. 필자는 수년간 데이터 센터간에 트래픽을 수동으로 이동 시키거나 모니터링 시스템이 중단, 연결 문제 또는 과부하 된 서버를 감지 할 때 자동으로이를 사용하고 있습니다. 작동 속도와 쉽게 전환 할 수있는 실제 트래픽의 양을 보면 절대 뒤돌아 보지 않을 것입니다. Zabbix를 사용하여 모든 시스템을 모니터링하고 DNS 장애 조치 상황에서 발생하는 상황을 보여주는 시각적 그래프를 사용하여 모든 의심을 끝내고 끝났습니다. TTL을 무시하는 ISP가 몇 개있을 수 있으며 일부 브라우저에는 여전히 오래된 브라우저가 있습니다. 그러나 2 개의 데이터 센터 위치에서 하루에 수백만 페이지 뷰의 트래픽을보고 DNS 트래픽 이동을 수행하는 경우- TTL을 무시하고 들어오는 트래픽은 웃을 수 있습니다.

DNS는 장애 조치 용으로 설계되지 않았지만 견고한 모니터링 시스템과 결합 될 때 장애 조치 요구 사항에 놀랍도록 작동하는 TTL로 설계되었습니다. TTL은 매우 짧게 설정할 수 있습니다. 빠른 DNS 장애 조치 기반 솔루션을 밝게하기 위해 프로덕션에서 5 초의 TTL을 효과적으로 사용했습니다. 추가로드를 처리 할 수있는 DNS 서버가 있어야하며 이름이 지워지지 않습니다. 그러나 중복 이름 서버의 mysql 복제 데이터베이스로 백업 할 경우 powerdns가 비용에 적합합니다. 또한 자동 장애 조치 통합을 위해 신뢰할 수있는 견고한 분산 모니터링 시스템이 필요합니다. Zabbix는 저에게 효과적입니다. 여러 분산 Zabbix 시스템의 정전을 거의 즉시 확인할 수 있습니다. powerdns에서 사용하는 mysql 레코드를 즉시 업데이트하며 정전 및 트래픽 급증시 거의 즉각적인 장애 조치를 제공합니다.

그러나 안녕하세요-수년간 대기업에서 DNS 장애 조치 서비스를 제공 한 후 DNS 장애 조치 서비스를 제공하는 회사를 설립했습니다. 소금 한알로 내 의견을 받아들이십시오. 정전 중에 대용량 사이트의 일부 zabbix 트래픽 그래프를 보려면 DNS 장애 조치가 어떻게 작동하는지 정확하게 확인하려면 저에게 이메일을 보내 주시면 기쁩니다.

DNS 장애 조치의 문제는 대부분의 경우 신뢰할 수 없다는 것입니다. 일부 ISP는 TTL을 무시하고 TTL을 존중하더라도 즉시 발생하지 않으며 사이트가 다시 시작되면 사용자의 DNS 캐시 시간이 초과되어 세션이 이상해질 수 있습니다. 다른 서버로 넘어갑니다.

불행히도, 자신의 (외부) 라우팅을 수행하기에 충분히 크지 않다면 거의 유일한 옵션입니다.

일반적으로 DNS RR을 사용하면 IP가 중단 될 때 일부 클라이언트가 끊어진 IP를 몇 분 동안 계속 사용할 것입니다. 이 질문에 대한 이전 답변 중 일부에서 언급되었으며 Wikipedia에도 작성되었습니다.

어쨌든,

http://crypto.stanford.edu/dns/dns-rebinding.pdf 는 대부분의 현재 HTML 브라우저에 해당되지 않는다고 설명합니다. 몇 초 안에 다음 IP를 시도합니다.

http://www.tenereillo.com/GSLBPageOfShame.htm 은 더욱 강력 해 보입니다.

여러 개의 A 레코드를 사용하는 것은 거래의 트릭이 아니거나로드 밸런싱 장비 공급 업체가 생각한 기능이 아닙니다. 이러한 이유로 DNS 프로토콜은 여러 개의 A 레코드를 지원하도록 설계되었습니다. 브라우저 및 프록시 및 메일 서버와 같은 응용 프로그램은 DNS 프로토콜의 해당 부분을 사용합니다.

어쩌면 일부 전문가는 DNS RR이 고 가용성에 적합하지 않은 이유를 설명하고보다 명확하게 설명 할 수 있습니다.

감사,

발렌티노

추신 : 깨진 링크에 대해 죄송하지만 새로운 사용자로서 1 개 이상을 게시 할 수 없습니다

트래픽이 적지 만 업무상 중요한 웹 사이트 (두 지역에 걸쳐)에서 몇 년 동안 DNS RR 장애 조치를 실행했습니다.

잘 작동하지만 어려운 방법을 배운 세 가지 이상의 미묘한 점이 있습니다.

1) 클라이언트가 사용할 수있는 캐시 된 DNS에서 둘 다 활성화 된 것으로 간주되면 브라우저는 작동하지 않는 IP에서 30 초 (마지막으로 확인한 시간) 후에 작동하는 IP로 장애 조치됩니다. 이것은 기본적으로 좋은 것입니다.

그러나 사용자가 30 초 동안 "반으로"대기하는 것은 용납 할 수 없으므로 TTL 레코드를 며칠 또는 몇 주가 아닌 몇 분으로 업데이트하여 중단시 다운 된 서버를 빠르게 제거 할 수 있습니다. DNS에서. 다른 사람들은 그들의 답변에서 이것을 언급했다.

2) 귀하의 네임 서버 중 하나 (또는 ​​두 개의 지리적 위치 중 하나)가 라운드 로빈 도메인을 제공하는 서비스가 다운되면 기본 도메인이 다운되면 다른 문제가 발생하여 제거 할 수 있습니다. 네임 서버에 대한 SOA TTL / 만료를 충분히 낮은 값으로 설정하지 않은 경우 DNS에서 네임 서버가 다운되었습니다. 여기에 기술적 인 세부 사항이 잘못되었을 수 있지만, 단일 장애 지점으로부터 실제로 방어하기 위해 필요한 TTL 설정이 하나 이상 있습니다.

3) 웹 API, REST 서비스 등을 게시하면 일반적으로 브라우저에서 호출하지 않으므로 DNS 페일 오버는 실제 결함을 나타 내기 시작합니다. 이것이 "권장되지 않음"이라고 말한 일부 사람들이 말하는 이유 일 수 있습니다. 내가 그렇게 말하는 이유는 다음과 같습니다. 첫째, 이러한 URL을 사용하는 앱은 일반적으로 브라우저가 아니므로 일반적인 브라우저의 30 초 장애 조치 속성 / 논리가 없습니다. 둘째, 두 번째 DNS 항목이 호출되는지 또는 DNS가 다시 폴링되는지 여부는 API / REST 클라이언트가 사용하는 프로그래밍 언어에서 네트워킹 라이브러리의 저수준 프로그래밍 세부 사항과 이들이 어떻게 호출되는지에 따라 크게 좌우됩니다. API / REST 클라이언트 앱. (이들 아래에서 라이브러리는 get_addr을 호출하고 언제? 소켓이 멈추거나 닫히면 앱이 새 소켓을 다시 열 수 있습니까? 시간 초과 논리가 있습니까? 등)

싸고, 잘 테스트되었으며, "주로 작동합니다". 대부분의 경우와 마찬가지로 마일리지가 다를 수 있습니다.

장애 조치에 우리 (Dyn)를 사용하는 많은 사람들이 있습니다. 다운 타임이있을 때 (Twitter의 Fail Whale과 같은 것을 생각할 때) 상태 페이지를 수행하거나 TTL을 기반으로 트래픽을 다시 라우팅 할 수있는 것과 같은 이유입니다. 어떤 사람들은 DNS 페일 오버가 빈민가라고 생각할 수도 있지만 처음부터 페일 오버로 네트워크를 심각하게 설계하여 하드웨어뿐만 아니라 작동하도록 할 수도 있습니다. DME가 어떻게 작동하는지 잘 모르겠지만 가장 가까운 애니 캐스트 PoP 중 17 개 중 3 개가 가장 가까운 위치에서 서버를 모니터링합니다. 3 개 중 2 개에서 다운 된 것을 감지하면 트래픽을 다른 IP로 다시 라우팅합니다. 유일한 다운 타임은 해당 TTL 간격의 나머지 시간 동안 요청 된 시간에 대한 것입니다.

어떤 사람들은 한 번에 두 서버를 모두 사용하고 싶어합니다.이 경우 라운드 로빈로드 밸런싱 또는 지리적 기반로드 밸런싱과 같은 작업을 수행 할 수 있습니다. 실제로 성능에 관심이있는 사람들을 위해 ... 실시간 트래픽 관리자는 각 서버를 모니터링하고 느린 경우 ... 호스트 이름에 연결 한 IP를 기반으로 가장 빠른 서버로 트래픽을 다시 라우팅합니다. 다시 말하지만 ... 이것은 UI / API / Portal에서 설정 한 값을 기반으로 작동합니다.

내 요점은 ... 우리는 의도적으로 DNS 장애 조치를 설계했습니다. DNS는 원래 만들어 졌을 때 장애 조치 (failover)를 위해 만들어지지 않았지만 DNS 네트워크는 처음부터이를 구현하도록 설계되었습니다. 일반적으로 감가 상각이나 하드웨어 비용없이 하드웨어만큼 효과적 일 수 있습니다. Dyn을 꽂아서 소리가 들리지 않기를 바라는 희망 ... 그 일을하는 다른 회사가 많이 있습니다 ... 나는 단지 우리 팀의 관점에서 말하고 있습니다. 도움이 되었기를 바랍니다...

다른 옵션은 위치 A에 이름 서버 1을 설정하고 위치 B에 이름 서버 2를 설정하는 것입니다. 그러나 NS1의 모든 A 레코드가 위치 A의 트래픽을 IP로 가리키고 NS2의 모든 A 레코드가 위치 B. 그런 다음 TTL을 매우 낮은 숫자로 설정하고 등록 기관의 도메인 레코드가 NS1 및 NS2에 대해 설정되어 있는지 확인하십시오. 이렇게하면 자동으로로드 밸런싱이 이루어지며 서버 하나 또는 링크 하나가 다운되면 장애 조치가 수행됩니다.

이 방법을 약간 다른 방식으로 사용했습니다. 두 개의 ISP가있는 하나의 위치가 있으며이 방법을 사용하여 각 링크를 통해 트래픽을 전달합니다. 이제는 유지 관리보다 약간 더 많은 유지 관리가 가능하지만 NS1 레코드를 자동으로 가져 와서 선택 영역의 레코드 IP 주소를 업데이트하고 해당 영역을 푸시하는 간단한 소프트웨어를 만들 수있었습니다. NS2.

대안은 BGP 기반 장애 조치 시스템입니다. 설정이 간단하지는 않지만 방탄이되어야합니다. 한 위치에 사이트 A를 설정하고 두 번째 사이트에 로컬 IP 주소를 사용하여 사이트 B를 설정 한 다음 휴대용 C에서 로컬 IP 로의 경로 재 지정을 설정하는 클래스 C 또는 다른 IP 블록을 가져옵니다.

함정이 있지만 그 수준의 제어가 필요한 경우 DNS 기반 솔루션보다 낫습니다.

다중 데이터 센터 장애 조치를위한 한 가지 옵션은 사용자를 훈련시키는 것입니다. 우리는 고객에게 여러 도시와 가입 이메일에 여러 서버를 제공하고 각 "서버"에 직접 연결되는 링크를 포함하여 한 서버가 다운 된 경우 다른 서버에 대한 링크를 사용할 수 있음을 사용자에게 알립니다.

이는 여러 도메인 이름을 유지 관리하여 DNS 장애 조치 문제를 완전히 무시합니다. www.company.com 또는 company.com으로 이동하여 로그인 한 사용자는 server1.company.com 또는 server2.company.com으로 이동하여 둘 중 하나를 사용하여 더 나은 성능을 얻을 수있는 경우 해당 책갈피 중 하나를 선택할 수 있습니다 . 다운되면 사용자는 다른 서버로 이동하도록 훈련됩니다.

지난 10 년 동안 DNS 기반 사이트 밸런싱 및 장애 조치를 사용해 왔으며 몇 가지 문제가 있지만 완화 할 수 있습니다. BGP는 몇 가지면에서 우수하지만 복잡성 증가, 추가 하드웨어 비용, 수렴 시간 등 100 % 솔루션이 아닙니다.

로컬 (LAN 기반)로드 밸런싱, GSLB 및 클라우드 기반 영역 호스팅을 결합하면 DNS로드 밸런싱과 관련된 일부 문제를 해결하는 데 매우 효과적입니다.

이 모든 답변은 그들에게 약간의 타당성이 있지만 실제로는 귀하가하는 일과 예산에 달려 있다고 생각합니다. 여기 CloudfloorDNS에서 우리 사업의 대부분은 DNS이며 빠른 DNS뿐만 아니라 낮은 TTL 옵션 및 DNS 장애 조치를 제공합니다. 이것이 효과가없고 잘 작동하지 않으면 우리는 사업을하지 않을 것입니다.

가동 시간에 무제한 예산을 가진 다국적 기업이라면 하드웨어 GSLB로드 밸런서 및 1 티어 데이터 센터는 훌륭하지만 DNS는 여전히 빠르고 견고해야합니다. 많은 사람들이 알고 있듯이 DNS는 도메인 이름 자체 이외의 모든 인프라에서 중요한 측면으로, 온라인 상태의 다른 모든 부분이 수행하는 가장 낮은 수준의 서비스입니다. 견고한 도메인 등록 기관부터 DNS는 도메인이 만료되지 않도록하는 것만큼이나 중요합니다. DNS가 다운되면 조직의 전체 온라인 측면도 다운되었음을 의미합니다!

DNS 장애 조치를 사용할 때 다른 중요한 측면은 서버 모니터링 (항상 여러 지리적 위치에서 확인해야하며 항상 여러 곳 (최소 3)은 오탐 (false positive)을 피하기 위해 확인해야 함)이며 DNS 레코드를 올바르게 관리하면 오류가 감지됩니다. 낮은 TTL과 장애 조치 기능이있는 일부 옵션을 사용하면이 프로세스를 원활하게 수행 할 수 있으며 한밤중에 시스템 관리자 인 경우 호출기로 깨어날 수 있습니다.

전반적으로 DNS 장애 조치는 실제로 작동하며 매우 저렴할 수 있습니다. 대부분의 경우 대부분의 관리되는 DNS 공급자로부터 하드웨어 옵션 비용의 일부만으로 서버 모니터링 및 장애 조치와 함께 Anycast DNS를 이용할 수 있습니다.

실제 답변은 그렇습니다. 효과가 있지만 모든 사람과 모든 예산에 적합합니까? 어쩌면 그렇지 않을 수도 있지만 시험 해보고 직접 테스트를 수행 할 때까지 IT 예산이 제한되어 있고 최상의 가동 시간을 원하는 중소 기업이라면 무시하기가 어렵습니다.

"그리고 왜 대부분의 프로덕션 환경에서 사용하는 기회를 가지게됩니까 (아무것도 아닌 것이 낫습니다)."

사실, 존재가 지리적으로 다양 할 때 "아무것보다 더 나은 것"이 "유일한 옵션"으로 더 잘 표현됩니다. 하드웨어로드 밸런서는 단일 존재 지점에 적합하지만 단일 존재 지점도 단일 실패 지점입니다.

dns 기반의 트래픽 조작을 사용하여 효과를 발휘하는 큰 달러 사이트가 많이 있습니다. 판매가 중단 된 경우 시간 단위로 알고있는 사이트 유형입니다. "대부분의 프로덕션 환경에서 사용할 기회를 얻은 것"이 가장 마지막 인 것 같습니다. 실제로, 그들은 옵션을 신중하게 검토하고, 기술을 선택하고, 비용을 지불했습니다. 그들이 뭔가 더 낫다고 생각하면 그들은 심장 박동을 남길 것입니다. 그들이 여전히 머물기로 결정했다는 사실은 실제 사용에 대해 많은 것을 말해줍니다.

Dns 기반 장애 조치는 일정 시간 동안 대기 시간이 발생합니다. 그 주위에 방법이 없습니다. 그러나 여전히 멀티 팝 시나리오에서 장애 조치 관리에 유일하게 실행 가능한 접근 방식입니다. 유일한 옵션으로, "아무것보다 더 나은 것"이상의 것입니다.

오늘날 그 기술을 사용하여 작동하고 꽤 잘 작동하는 훌륭한 글로벌로드 밸런서. 예를 들어 Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/를 확인 하십시오.

자세한 내용을 보려면 응용 프로그램 노트를 읽으십시오.

http://edgedirector.com

여기에는 장애 조치, 글로벌로드 밸런싱 및 다양한 관련 문제가 포함됩니다.

백엔드 아키텍처가 허용하는 경우 장애 조치 옵션과 함께 전체로드 밸런싱이 더 나은 옵션입니다. 그렇게하면 모든 서버와 대역폭이 가능한 많이 작동합니다. 이 설정은 오류 발생시 사용 가능한 추가 서버를 삽입하지 않고 복구 될 때까지 실패한 서버를 서비스에서 철회합니다.

짧은 대답 : 그것은 효과가 있지만 한계를 이해해야합니다.

장애 조치 (failover)라는 아이디어는 클러스터링을위한 것이라고 생각했지만 솔로로도 실행할 수 있기 때문에 일대일 가용성으로 작동 할 수있었습니다.

A, 자체 AS에 멀티 홈이있는 데이터 센터를 선택하거나 B를 퍼블릭 클라우드에서 네임 서버를 호스팅하는 것이 좋습니다. EC2 나 HP 또는 IBM이 다운 될 가능성은 거의 없습니다. 그냥 생각이야 DNS는 픽스로 작동하지만이 경우 네트워크 기반의 불량한 디자인에 대한 픽스 일뿐입니다.

환경에 따라 다른 옵션은 IPSLA, PBR 및 FHRP와의 조합을 사용하여 중복 요구를 충족시키는 것입니다.