DNS 서버이기도 한 도메인 컨트롤러를 해제하는 가장 좋은 방법은 무엇입니까?


9

DNS 서버로 많이 사용되는 Active Directory 도메인 컨트롤러의 폐기 프로세스에 대한 두 가지 학교가 있습니다.

  1. 발신 DC의 IP 주소를 새 DC에 추가하고 DNS가 해당 주소를 수신하고 있는지 확인하십시오.

  2. 기존 DC를 강등시키고 DNS 역할을 그대로두고 새 서버에 대한 글로벌 DNS 전달자를 구성하십시오.

분명히, 모든 서버와 장치가 새 서버의 기본 IP 주소를 사용하도록 구성 될 때까지 둘 다 중지 간격이지만 환경의 크기에 따라 전환 시간이 상대적으로 길어질 수 있습니다.

여기에 명확한 모범 사례가 있습니까?


2
또는 세 번째, 네트워크를 통해 이전 DNS 서버에 대한 모든 참조를 변경합니까?
gravyface

1
물론 그것이 최종 목표이기 때문에 제가 이것을 스톱 갭이라고 부릅니다. 그러나 매우 큰 일부 환경에서는 적시에 수행하려는 경우 옵션이 아닙니다. 내가 말 했어요 : Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment.그렇죠?
MDMarra

시맨틱 스 ... 당신 말이 맞지만, 나는 체계적으로 장치의 DNS 구성을 변경하고, 활동을 모니터링하고, DHCP 범위로 시작한 다음, 가장 중요하지 않은 순서로 서버를 통해 작업합니다 (멤버 서버를 다른 DC에 연결) ) 이전 서버를 가장하거나 필요 이상으로 오래 머무르게합니다.
gravyface

물론 이것이 최선의 선택이지만 "매우 큰"환경이라고 말하면 300 개 이상의 DC 및 다양한 IT 구성 요소를 관리하는 여러 IT 팀과 함께 전 세계적으로 분산 된 인프라에 대해 이야기하고 있습니다. 가끔은, 정말 하지 않습니다 당신이 가지고 수 있도록 가능한 모든 업그레이드하는 동안 처음으로 스윙 장치.
MDMarra

1
@gravyface 틀린 것은 아니지만 다양한 구성 요소를 분산 관리하는 지리적으로 분산 된 대규모 환경에서는 항상 게임 계획에 동의하고 모든 계획을 세우고 공통의 목표를 향해 노력하는 것이 항상 실현 가능한 것은 아닙니다. 때로는 다른 사람들에게 가능한 한 적은 영향을
미치기

답변:


5

나는 이것이 엄격하게 Q & A 질문보다 "토론"질문이라고 생각하기 때문에 주저합니다 ...하지만 토요일 아침은 게 으르므로 어쨌든 갈 것입니다.

여기에 명확한 모범 사례가 있습니까?

아니요. (아마, 아마도 이것이 쉬운 대답 일 것입니다 ...)

Microsoft는 도메인 컨트롤러를 강등시키고 AD 및 DNS의 마이그레이션을 수행하는 방법에 대해 매우 일반적이고 쉽게 Googleable Bingable 지침을 제공하지만, 이들을 연결하는 것을 귀찮게하지 않을 것입니다. 각기 다른 조직 환경에 대한 모든 특정 사례를 문서화하십시오.

따라서 Microsoft와 같은 시스템 관리자 / 엔지니어는 Microsoft가 우리를 위해 특별한 스크립트를 작성하지 않은 우리의 전문 지식과 경험으로 차이를 메워야합니다.

또한 수십 개 이상의 도메인 컨트롤러가있는 지구 환경에서 작업하고 동일한 네트워크에서 서로 다른 AD 포리스트를 사용하며 Windows 이외의 장치에서도 소비하기 때문에 동일한 문제를 해결하기 위해 수행 한 작업의 예를들 수 있습니다. 같은 DC의 DNS 서비스 등. 새로운 데이터 센터로 이전하고 이전 데이터 센터로 이전하거나 새 하드웨어 또는 새 OS 버전으로 마이그레이션해야하는 경우와 오래된 비즈니스 정치는 도메인 컨트롤러를 해체해야하는 가능한 모든 이유입니다. 잠재적으로 여전히 사용 중이었습니다. 현재 DC / DNS 서버를 사용하는 여러 이기종 조직이있는 경우 프로젝트 관리자를 포함하여 도메인 컨트롤러를 해제하기 전에 모든 클라이언트 (다수의 제어하에 있지 않을 수 있음)를 재구성하는 과정은 대개 거칠고 철회 된 프로세스입니다.

내가 생각하지 않는 말을하는 이유 그래서 누군가 당신에게 줄 수 이 질문에 대한 답을. 당신이 그것에 대해 갈 수있는 방법은 수천 가지가 있으며 일부는 조직의 구조와 요구에 따라 다른 것보다 낫습니다.

이 문제를 해결하기 위해 수행 한 작업은 각 데이터 센터에 VIP를 만들고 해당 데이터 센터에있는 모든 도메인 컨트롤러를 VIP 뒤에 모으는 것입니다. (이 VIP는 명백한 이유로 DNS 서비스 에만 사용됩니다 . Kerberos와 LDAP의로드 밸런싱에 대해서는 이야기 하지 않습니다 .) 이렇게하면 클라이언트가 해당 VIP를 DNS 확인자에 사용하도록 구성 할 수 있으며, 우리는 자유롭게 추가하고 제거 할 수 있습니다 하지만 언제든지 VIP 뒤에 도메인 컨트롤러가 있습니다.

그러나 당신은 문제 앞에 있지 않습니다 ... 제공 한 옵션이 주어지면 :

  1. 발신 DC의 IP 주소를 새 DC에 추가하고 DNS가 해당 주소를 수신하고 있는지 확인하십시오.

  2. 기존 DC를 강등시키고 DNS 역할을 그대로두고 새 서버에 대한 글로벌 DNS 전달자를 구성하십시오.

이전 서버를 최대한 빨리 해제하는 것이 목표이므로 옵션 # 1을 선택하고 옵션 # 2는 기존 서버를 제거하는 데 도움이되지 않습니다. 옵션 # 2를 사용하면 서버가 여전히 필요합니다. Mathias R. Jessen의 스터브 존 제안에 대해서도 언급하지 않겠습니다. 다시 말하지만, 여전히 기존 서버를 그대로두고 서비스를 제공해야하므로 최종 목표에 도움이되지 않습니다.

옵션 1을 사용하면 추악한 방식으로 기존 서버를 폐기하고 회사의 비용 절감을 주장하며 해당 데이터 센터에서 다른 월 임대료를 지불하지 않아도되며 훌륭한 직원으로 선정 될 수 있습니다.

편집 : 채팅에 대해 조금 더 생각해 보면, 지금 당장 물건에 대한 플러그-ASAP 요구 사항이 있기 때문에 내 요구 사항을 예상했을 수 있습니다. 최대한 빨리 서버를 종료해야 할 필요가없는 것 같습니다.

즉, 여전히 선호하는대로 제안을 변경하지 않습니다. 여분의 IP를 기존 도메인 컨트롤러에 고정시키는 것은 과거와 비슷한 시나리오에서 나에게 효과적이었습니다. 그리고 나는 서버가 불확실한 시간 동안 앉아있는 이상한 흔적을 추가하는 것보다는 오히려 좋았습니다.


1
나는 이것이 "토론 질문"규칙을 정의한 좋은 주관적, 나쁜 주관적 포스트 에 good subjective속 한다고 생각한다 . 적어도 나는 그렇게 희망한다.
MDMarra

@MDMarra 동의합니다. 생각을 자극하고 흥미로운 질문에 +1 :)
Ryan Ries

또한, 단지 기록을 위해, 나는 일반적으로 당신의 제안과 반대입니다 : D
MDMarra

5

Active Directory 지옥으로가는 길에는 임시 붕대로 포장되어 있습니다. 폐기되거나 폐기 될 DNS 서버의 IP 주소를 새로운 DC 및 DNS 서버에 할당하는 것은 일시적인 붕대입니다.

주석에서 @gravyface가 언급했듯이 이상적인 시나리오에서는 이전 DC를 완전히 해제하기 전에 모든 DHCP 범위 및 정적 구성을 변경하여 클라이언트 DNS 기본 설정을 이전 IP 대신 새 IP로 업데이트합니다.

모든 클라이언트가 다시 구성되었는지 확인하는 것이 반드시 제 시간에 가능할 필요는 없지만 옵션 번호 2 (전체 네임 스페이스를 전달)는 여기서 가장 불쾌한 옵션으로 간주합니다.

이전 서버에서 요청을 내린 후에도 요청을 전달하도록하는 것 외에도 DNS 서버에서 들어오는 요청에 대해 디버그 로깅을 사용하는 것이 좋습니다. 이렇게하면 클라이언트가 여전히 기존 DNS 서버를 가리키는 지 여부 를 평가하기가 조금 더 쉬워집니다. 상기 클라이언트를 식별하는 단계.

즉, 당신은 명백한 세 번째 옵션 인 스텁 존을 놓쳤다 고 생각합니다 .

  • DC를 강등시키고 DNS 역할을 유지하고 이전에 스텁 영역으로 보유한 모든 영역을 추가하십시오. 이렇게하면 클라이언트가 작업을 수행하는 대신 클라이언트가 실제로 사용해야 하는 도메인 컨트롤러 에 연결하도록합니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.