상황:
- 테스트해야 할 DR 사이트가 있습니다.
DR 사이트에는 Linux와 Windows 호스트가 혼합되어 있습니다. 프로덕션 사이트의 SERVER를 사용할 수 없는 재해가 발생하는 경우 DR의 SERVER_DR이 켜져 동일한 Windows 도메인에 조인됩니다. 기본 사이트가 사용할 수 없으며 SERVER 양식 AD의 원본 레코드를 삭제하고 싶지 않습니다.
내가 해결하려는 문제는 DR 사이트의 이름 확인입니다. 프로세스와 스크립트는 DNS 이름 SERVER를 사용하므로 DR 사이트에서 SERVER에 대한 요청은 SERVER_DR로 변환되어야 합니다. 우리는 Windows DNS에 대해 아무 것도 할 수 있는 액세스 권한이 없습니다.
내 생각은 BIND를 사용하여 이 문제를 해결하는 것입니다. DR의 호스트는 AD로 인증할 수 있어야 합니다. Windows 도메인의 DR 사이트 외부에 있는 다른 항목에 액세스할 필요가 없다는 사실은 문제를 단순화해야 합니다.
DR 호스트가 액세스해야 하는 서비스는 대부분 파일 공유 및 SQL 서버입니다. SQL 서버는 SPN을 사용하므로 여기서 문제가 될 수 있다고 생각합니다.
이는 DR 사이트의 BIND가 보유한 our.domain.com 영역에 대해 BIND를 사용하는 아이디어를 제공하지만 Windows DR 호스트가 올바르게 기억하는 경우 점수가 매겨지지 않은 레코드를 사용해야 하기 때문에 AD에 대해 인증해야 할 때 발생할 수 있는 문제를 볼 수 있습니다. 앞서 언급한 이유로 인해 AD에서 영역을 대표합니다.
이 문제를 해결하는 데 어려움을 겪을 가치가 있습니까? 동료 중 한 명이 각 Windows DR 호스트에 대해 호스트 파일을 사용할 것을 제안했습니다. 그러나 호스트 파일이 많지 않고 BIND를 설정하는 데 시간이 낭비될 수 있다는 점이 꽤 보기 흉합니다.
답변1
HOSTS 파일로 인해 AD 인증이 제대로 작동하지 않습니다. AD 인증에는 DNS 서버만 제공할 수 있는 SRV RR이 필요합니다(HOSTS 파일은 A RR이므로).
여기에서 BIND를 사용하여 AD를 지원하는 것에 대해 제가 제공한 이전 답변을 살펴보십시오.BIND9 및 DHCPD를 사용하여 Windows 도메인 지원
Windows 서버 컴퓨터 이름이 다른 경우 일부 소프트웨어가 제대로 작동하는 데 문제가 발생할 수 있습니다. DR이 아닌 이름을 다른 컴퓨터 이름 세트를 사용하여 Windows 서버에 "별칭"으로 지정하려고 하면 일부 프로토콜에서는 작동하지만 다른 프로토콜에서는 문제가 발생합니다(예를 들어 AD의 SPN은 컴퓨터에 "연결"되어 있음). 이름).
DR 사이트에서 Windows DNS를 사용할 수 없는 이유가 명확하지 않습니다. Windows DNS 서버를 가동하고 상황이 더 나빠지면 _msdcs.domain.com 영역을 기존 BIND 인프라의 Windows DNS 서버에 위임할 수 있다고 생각합니다.
달성하려는 작업과 제한 사항이 있는 이유에 대해 좀 더 이해해야 할 것 같지만 일반적으로 DR 환경을 프로덕션 환경에 최대한 가깝게 만들기 위해 노력할 것입니다. 운영을 DR 환경으로 이동할 때 수행할 작업량이 최소화됩니다.
답변2
모든 AD DNS 작업을 계속 유지하면서 DR 사이트의 호스트가 "SERVER"를 SERVER_DR의 IP 주소로 확인하도록 하는 쉬운 방법은 없습니다. 당신이 해야 할 일은 모든 서버 참조에 별칭을 사용하는 것입니다.
나의 일반적인 접근 방식은 AD 정수가 아닌 새 도메인(예: mydomain.site)을 생성하는 것입니다. 이를 통해 서로 다른 DNS 서버에 대해 별도의 서로 다른 영역 파일을 사용할 수 있습니다. 그런 다음 서버에 대한 모든 참조를 server.mydomain.site로 변경하십시오. 이를 통해 사용자는 사이트에 적합한 이름으로 확인되는 단일 서버 이름을 사용할 수 있습니다.
NB Windows 파일 공유가 CNAME 별칭과 작동하려면 LanManServer 서비스에 대한 레지스트리 항목을 추가해야 합니다. 보다http://support.microsoft.com/kb/281308자세한 내용은. 이는 W2k8은 물론 2k 및 2k3에서도 작동합니다.
.site 도메인을 호스팅하려면 Windows DNS를 사용하는 것이 좋습니다. 실제로 시스템 관리자에게 도움을 요청하도록 설득할 수 없다면 BIND를 사용하여 Windows DNS 서버를 전달자로 구성할 수 있습니다. 그런 다음 BIND는 .site 도메인을 확인하고 Windows는 AD 도메인을 포함한 다른 모든 도메인에 사용됩니다. 그러나 이로 인해 유지 관리가 더 복잡해지기 때문에 가능하면 피하고 싶습니다.
JR
PS re "CNAME 별칭과 함께 작동하는 Windows 파일 공유용 NB"
별칭을 사용하는 이유는 \myserver.mydomain.site\share와 같은 UNC 이름을 사용하여 공유를 찾아보거나 네트워크 드라이브를 매핑할 수 있다는 것입니다. 여기서 "myserver.mydomain.site"라는 이름은 대상 서버의 IP 주소로 확인됩니다. 다른 사이트의 다른 IP 주소로 확인할 수 있습니다. 기본적으로 LanManServer 서비스는 서버 이름이 실제 서버 이름과 일치하지 않는 한 검색을 허용하지 않으며 "네트워크에 중복된 이름이 있습니다"와 같은 오류 메시지가 표시됩니다. 이는 보안을 강화하기 위해 수행됩니다. 제가 언급한 KB 문서에서는 위와 같은 UNC 이름이 작동하도록 이름 확인을 끄는 방법을 설명합니다.
실제로 저는 이 방법을 일상적으로 사용합니다. 파일 공유를 다른 서버로 쉽게 이동할 수 있기 때문입니다. DFS를 대체할 수는 없지만 유용한 트릭이 될 수 있습니다.