머신별 분산형 DNS 캐싱 - nscd/lwresd/etc

머신별 분산형 DNS 캐싱 - nscd/lwresd/etc

머리말:

우리는 각 지리적 네트워크 위치에 캐싱 확인자를 보유하고 있습니다. 이들은 탄력성을 위해 클러스터링되어 있으며 해당 위치로 인해 서버에서 생성된 내부 요청의 대기 시간이 줄어듭니다.

이것은 잘 작동합니다. 단, 유선을 통해 확인되는 대량의 요청은 자체적으로 DNS 캐싱을 수행하지 않는 애플리케이션에 의해 생성된 동일한 레코드에 대한 조회입니다.

질문:

  1. 반복되는 요청이 네트워크에 도달하는 것을 줄이기 위해 개별 서버에서 경량 캐싱 데몬을 실행하면 상당한 이점이 있습니까?

  2. 사용해본 경험 있으신 분 계시나요[u]nscd,lwresd또는dnscache그런 짓을 하려고? 살펴볼 만한 다른 패키지가 있나요?

  3. 주의해야 할 주의사항이 있나요? 명백한 캐싱 및 부정적인 캐싱 부실 결과 외에도.

답변1

우리는 수백 대의 컴퓨터에서 nscd를 사용하는데, 내 경험상 "그냥 작동"합니다. DNS 서버의 부하를 대폭 줄였습니다.

주의해야 할 유일한 것은 기본적으로 호스트 조회뿐만 아니라 그룹/사용자/서비스 조회도 캐시한다는 것입니다. 이를 비활성화할 수도 있습니다(우리의 경우 이러한 조회도 캐시하고 싶었습니다).

수년 전에 nscd에 문제가 있었던 것을 기억하지만 최근 버전에서는 훨씬 개선된 것 같습니다.

답변2

나는 몇 가지 환경에서 nscd를 사용했습니다. 다른 사람들은 "그냥 작동한다"고 말했습니다. 그러나 각 사이트의 캐싱 확인자가 제대로 작동한다면 로컬 캐싱에 큰 이점이 없다고 말할 수 있습니다. 조용하고 외부 세계에 추가 요청을 보내는 것이 아니라 추가 내부 대화를 생성하는 것뿐입니다.

나는 nscd가 오래된 항목을 유지하고 그로 인해 "하나의 기계가 고장난" 것에 의해 몇 번 물렸으므로 편집증적인 조언은 내부 DNS 채팅이 실제로 성능에 영향을 미치지 않으면 로컬에 신경 쓰지 말라는 것입니다. 캐시(그리고 성능에 영향을 미치는 경우 nscd의 존재를 문서화하여 시간이 중요한 변경이 있을 경우 캐시를 플러시하는 것을 기억하세요).

관련 정보