여기에 문제가 있습니다.
우리는 클라우드 제공업체로부터 두 개의 서로 다른 클라우드 지역에 컴퓨팅 인스턴스를 설정했습니다. 작업하기가 힘들다는 점만 언급하는 것 외에는 언급하지 않겠습니다.
해당 인스턴스는 (분명히) 비공개를 사용하고 있습니다.
이 클라우드 공급자는 지역 간 개인 IP를 허용하지 않아 NLB가 그림에서 벗어나기 때문에 VIP 기반 로드 밸런싱 솔루션을 사용할 수 없습니다.
우리에게 필요한 것은 A 레코드 상태 확인 기능을 갖춘 DNS 서버(실제로는 적어도 두 개)입니다. 예를 들어 보겠습니다.
- 서비스:
- 서버 A - 지역 1 - IP 10.1.1.100
- 서버 B - 지역 2 - IP 172.26.1.100
- DNS 밸런서(동일한 레코드 및 구성 데이터베이스 공유):
- DNS A - 지역 1 - IP 10.1.1.50
- DNS B - 지역 2 - IP 172.26.1.50
- DNS 레코드 1: everything.local - 10.1.1.50
- DNS 레코드 2: everything.local - 172.26.1.50
- 클라이언트:
- 클라이언트 A - 모든 지역 - 모든 IP
- 시나리오 A:
- 클라이언트 A에는 DNS A와 DNS B가 모두 DNS 서버로 구성되어 있습니다.
- 클라이언트 A는 DNS 서버 A에 everything.local을 요청합니다.
- 서버 A가 오프라인 상태입니다.
- DNS 서버 A에는 백엔드 상태 확인이 있으며 이를 감지하고 서버의 B IP(172.26.1.50)로 응답합니다.
- 캐싱을 방지하기 위해 TTL은 0(영) 또는 이와 동일하게 낮은 값으로 설정됩니다.
- 시나리오 B:
- 클라이언트 A에는 DNS A와 DNS B가 모두 DNS 서버로 구성되어 있습니다.
- 클라이언트 A가 무엇이든 요청합니다. 로컬, DNS 서버 A가 다운되어 DNS 서버 B가 응답합니다.
- 서버 B가 오프라인 상태입니다.
- DNS 서버 B에는 백엔드 상태 확인 기능이 있으며 이를 감지하고 서버 A IP(10.1.1.100)로 응답합니다.
- 캐싱을 방지하기 위해 TTL은 0(영) 또는 이와 동일하게 낮은 값으로 설정됩니다.
본질적으로: DNS 레코드의 IP 상태를 확인하는 DNS 서버입니다.
문안 인사.
답변1
클라이언트 A에는 DNS A와 DNS B가 모두 DNS 서버로 구성되어 있습니다.
음, 당신은 기계가 서로 다른 분할 데이터로 구성된 여러 DNS 서버를 사용하게 하는 고통스러운 세계로 향하고 있습니다. 예측 가능한 동작을 얻으려면 모니터링 호스트에 자체적으로 해결된 스택을 구축해야 합니다.
이 서비스를 모니터링하는 방법은 DNS를 분할하지 않는 것입니다.
service.example.com. CNAME region1_service.example.com.
service.example.com. CNAME region2_service.example.com.
region1_service.example.com. A 10.1.1.50
region2_service.example.com. A 172.26.1.50
그리고 다음을 각각 모니터링합니다.
- service.example.com
- Region1_service.example.com
- Region2_service.example.com
또는 모니터링 에이전트5월명시적 주소 설정을 지원하므로 각 인스턴스를 별도로 모니터링할 수 있습니다. 그러나 두 노드 모두에서 중단을 표시하는 것은 노드 중 하나의 중단보다 훨씬 더 심각한 문제가 있습니다.
또한 모니터링 클라이언트가 rrDNS를 구현하는 방법도 확인해야 합니다. 규칙에 따른 장애 조치 감지 시간은 ~5분이지만 브라우저는 초기 연결의 경우 약 10초, 후속 요청의 경우 1초 미만의 임계값을 적용합니다.
답변2
결국 이에 대한 해결책이 있습니다. 이것은 본질적으로 GSLB가 제공하는 것입니다. 많은 상용 제품이 있습니다.
특정 단순성과 오픈 소스로 이를 수행하려면 PowerDNS 클러스터에서 LUA 레코드와 함께 PowerDNS를 사용할 수 있습니다.