읽을 때 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.