티스토리 뷰

많은 회사들이 가상화를 운영중에 있습니다.


몇몇 회사들은 가상화 환경에서 AD서버를 운영중인 곳도 있습니다.


가상화에서 AD를 운영중이라면, 복원계획에 있어 신중해야 합니다.


가상화에는 스냅샷이라는 기능이 제공됩니다.


이는 일부 변경사항들을 되돌리기 위해 사용을 합니다.


아주 유용한 기능이지만 도메인서버나 인증서버등에서는 아주 신중히 운영을 해야 합니다.



몇일전 저도 실수한 내용을 공유드립니다.


1) 저는 최근에 발생한 장애의 트러블슈팅을 위해 사전 찍어놓은 스냅샷으로 롤백하길 원합니다. 도메인 환경은 두 개 혹은 그 이상의 도메인 컨트롤러를 가지고 있고 단일 도메인 포레스트입니다. 도메인 컨트롤러는 모두 Windows Server 2008 R2에서 동작합니다.


2) 일반적인 시스템 상태 백업 대신에 가상 머신 스냅샵을 사용했습니다.

3) 스냅샷 중의 하나로 DC 한대(PDC)를 복원했습니다.

4) 그 이후 DC들간의 복제가 깨집니다.


DC에서는 다음과 같은 복제 증상이 나타납니다.

1) Netlogon 서비스가 중지상태입니다.

2) 디렉터리 서비스 이벤트로그에 복제 오류가 기록되고, 이벤트 ID 2095와 함께 이벤트 원본에 NTDS 복제가 기록됩니다.

3) 디렉터리 서비스 이벤트 로그는 두 개의 경고를 기록하는데, 이벤트 원본은 NTDS General이고 이벤트 ID는 1113과 1115입니다.




이는 정합성 문제입니다.


간단하게 예를들어 스냅샷으로 롤백하기전 PDC에 있던 A라는 계정을 생성했는데...계정생성전의 시점으로 롤백을 할 경우 입니다.


그렇게 되면 A라는 계정의 usn은 10이였다면, 복원을 하면서 USN은 9가 되어 버립니다.


복제서버는 이미 10으로 알고 있는데 PDC가 9로 알고 있으니 충돌이 나는 것입니다.


AD Replication에 대한 이해가 조금 필요합니다.

도메인 컨트롤러(DC)는 복제 파트너간에 필요한 업데이트를 추적하기 위해서 USN(Update Sequence Numbers)을 사용합니다. 

디렉터리 내의 데이터에 변화가 생길 때마다 USN은 변화가 발생한 것을 나타내기 위해 값이 증가합니다. 

DC 저장소의 각 디렉터리는, USN을 각 원본 복제 파트너로부터 받은 마지막 업데이트를 추적하기 위해서 사용합니다. 

각 DC는 디렉터리 파티션의 복제물을 저장하는 DC의 가장 높은 USN을 알고 있는 테이블을 가지고 있습니다. 

각 DC는 Invocation ID라고 불리는 NTDS 설정 개체의 값도 가지고 있습니다. 이 값은 로컬 AD 데이터베이스의 버전을 구분하기 위해 사용됩니다.


복제 프로세스동안 USN을 사용하는 두 값이 있습니다. 하나는 Up-to-dateness vector 이고, 다른 하나는 High water mark입니다. Up-to-dateness vector는 원본 DC로부터 받은 원래의 업데이트를 추적하기 위해서 목적지 DC에서 유지하는 값입니다. 목적지 DC가 디렉터리 파티션을 위한 업데이트를 요청할 때 목적지 DC에 보내기 위해 필요한 특성의 값을 감소시키는 값을 사용하는 원본 DC의 Up-to-dateness를 제공합니다. 원본 DC는 Up-to-dateness vector 값을 복제 주기가 완료될 때 목적 DC에 보냅니다. High water mark는 특정 디렉터리 파티션의 개체를 위해 특정 원본 DC로부터 받은 마지막 변경을 추적하기 위해 목적지 DC가 유지하는 값입니다. 이 값은 이미 목적지 DC에 적용된 것을 원본 DC에서 목적지 DC로 보내는 것을 방지합니다.


Invocation ID는 DC에서 실행되는 디렉터리 데이터베이스를 구분하는 GUID 값이고 서버 개체의 ID로부터 구분되어 유지됩니다. 서버 개체의 ID는 변하지 않지만 디렉터리 데이터베이스의 ID(Invocation ID)는 시스템 상태가 마이크로소프트 API를 사용하여 복원될 때 변경됩니다. 모든 도메인 컨트롤러는 그것의 원본 복제 파트너의 디렉터리 데이터베이스의 추적을 유지합니다. Up-to-dateness vector와 High water mark는 Invocation ID를 참조해서 DC는 AD 복제의 복사본이 어디서부터 오는지 알게 됩니다.





위와 같은 장애 상황을 바로잡으려면 롤백 이슈가 있는 DC에서 다음과 같이 작업해야 합니다.


1) 먼저 장애서버가 pdc라면(FSMO역할 서버) 다른 DC에 역할을 전달해야 합니다. 방법에는 Transfer와 Seize가 있는데 복제이슈가 있다면 Transfer가 잘 안되는 경우가 많습니다.

그냥 seize를 진행합니다.


2) ‘dcpromo /forceremoval’을 실행하여 해당 DC를 강제적으로 제거합니다. 이것은 변경에 대한 복제를 시도하지 않고 서버에서 AD를 제거합니다. 제거가 완료되고 서버를 다시 시작하면 workgroup의 단독 서버가 될 것입니다.


3) DC에서 장애난 dc의 메타데이터 클린업을 실행하고 복제 파트너를 제거합니다.


4) 이 환경에서 복제가 한번 완료되면 제거된 서버를 도메인에 조인하고 DC로 승격시킵니다.


조금 까다로운 작업이 아닐수 없습니다.




이와 같이 일을 방지하기 위해서는 다음과 같은 사례을 따라야 합니다.


1) DC 이미지를 백업하기 위해서 이미징 소프트웨어를 사용하지 마세요.


2) DC의 스냅샷을 만들거나 적용하지 마세요.


3) 가상 머신을 끄지 말고 가상 디스크를 백업으로 복사하세요.



끝.

댓글