모든 서브 도메인에 대한 1 개의 a- 레코드 (10000+); 잠재적 인 문제가 있습니까? 다른 솔루션이 있습니까?

Question

DNS 레벨에서 서브 도메인 당시 사용자를 지원하기 위해 여기에서 읽은 대부분의 솔루션은 *.domain.com을 사용하여 모든 IP로 모든 것을 지적하는 것입니다.

쉽고 간단한 솔루션이지만, 처음 1000 명의 등록 된 사용자를 Servera에 가리키고 다음 1000 명의 등록 된 사용자를 ServerB에 가리려면 어떻게해야합니까? 이것은 클러스터링을위한 소프트웨어 및 하드웨어로 비용을 낮추는 데 선호되는 솔루션입니다.

대체 텍스트 http://learn.iis.net/file.axd?i=1101(MS IIS 사이트에서 인용 된 다이어그램)

가장 논리적 인 솔루션은 구역 데이터 파일에서 하위 도메인 당 1 x A- 레코드를 갖는 것으로 보입니다. Bind는 구역 데이터 파일에 크기 제한이없는 것 같습니다. 사용 가능한 메모리로만 제한됩니다.

그러나 우리 팀은 새로운 서브 도메인을 생성하는 것이 새로운 A- 레코드를 삽입하고 DNS 서버를 다시 시작하는 것으로 구성되기 때문에 새로운 서브 도마민을 확보하고 준비하는 대기 시간에 대해 걱정하고 있습니다.

DNS 서버를 다시 시작하는 성능이 걱정해야합니까?

미리 감사드립니다.

업데이트:

대부분의 여러분 대부분은 리버스 프록시 설정을 대신 사용하라고 제안하는 것 같습니다.

대체 텍스트 http://learn.iis.net/file.axd?i=1102

(ARR은 IIS7의 리버스 프록시 솔루션입니다)

그러나 다음은 다음과 같이 볼 수 있습니다.

1. 단일 실패 지점
2. IP 지리 위치를 기반으로 다른 위치에서 서버를 전략적으로 설정할 수 없습니다.

Answer 1

와일드 카드 DNS 항목이있는 프론트 엔드 프록시는 실제로 이것과 함께 갈 수있는 방법입니다. LiveJournal과 같은 큰 사이트가 얼마나 큰지입니다.

이것은 TCP 레이어로드-발란기 일뿐입니다. URL의 호스트 부분을 검사하여 쿼리를 전달할 백엔드 서버를 파악할 수있는 많은 솔루션이 있습니다. 로우 스펙 서버에서 Apache를 실행하면 쉽게 수행 할 수 있습니다. 적절한 구성.

프록시는 각 사용자의 세션이 항상 오른쪽 백엔드 서버로 이동하도록하며 대부분의 모든 세션 처리 방법은 계속 작동합니다.

또한 프록시는 단일 실패 지점 일 필요는 없습니다. 중복 구성 (고장을 피하기 위해) 또는 스트레스를 피하기 위해 하중을 공유하도록하는 것이 완벽하게 가능하고 쉽게 실행하는 것이 매우 쉽습니다.

또한 두 번째 John Sheehan의 응용 프로그램이 URL의 왼쪽 부분을보고 표시 할 사용자의 컨텐츠를 결정한다는 제안입니다.

백엔드에 Apache를 사용하는 경우 참조하십시오 이 게시물 구성 방법에 대한 정보도 마찬가지입니다.

Answer 2

와일드 카드 DNS 항목을 사용한 다음로드 밸런싱을 사용하여 클라이언트에 관계없이 서버간에로드를 배포하십시오.

당신이 그것을하는 동안, URL 재 작성 단계를 건너 뛰고 응용 프로그램이 입력 한 URL을 기반으로하는 계정을 결정하도록하십시오 (domain.com? user와 같이 x.domain.com의 x가 무엇인지 쉽게 결정할 수 있습니다. = x).

편집 : 추가 정보를 기반으로, 어떤 클라이언트가 어떤 서버에 액세스 할 수 있는지 저장하는 "브로커"를 개발할 수 있습니다. 그 대중을 대면하여 브로커에 저장된 클라이언트와 관련된 리소스에서 얻습니다. 프런트 엔드는로드 균형을 유지하고 파일/DB 서버에서 자신이 누구인지에 따라 잡을 수 있습니다.

Answer 3

tinydns를 사용하는 경우 데이터베이스를 수정하면 Nameserver를 다시 시작할 필요가 없으며 일반적으로 매우 빠르기 때문에 병목 현상이되어서는 안됩니다. 나는 그것이 100000+ 항목으로 잘 수행되는지 여부를 모른다 (그렇지 않은 경우 놀랍습니다).

http://cr.yp.to/djbdns.html