IT

Active Directory 복제 및 토폴로지

씨오디이abc 2025. 7. 11. 10:51
반응형

제 1부: Active Directory의 아키텍처

섹션 1.1: 구조의 이중성: 논리적 구조와 물리적 구조

Active Directory Domain Services(AD DS)의 아키텍처는 두 개의 개별적이면서도 상호 연관된 구조, 즉 논리적 구조와 물리적 구조로 분리되어 설계되었습니다. 이 분리는 관리적 확장성과 네트워크 효율성이라는 두 가지 핵심 목표를 동시에 달성하기 위한 근본적인 설계 원칙입니다. 이 두 구조의 역할과 관계를 이해하는 것은 효과적인 Active Directory 설계, 배포 및 관리의 초석이 됩니다.  

 

논리적 계층 (관리 경계)

논리적 구조는 네트워크 리소스를 관리 및 보안 목적으로 조직화하는 방법에 관한 것입니다. 이는 물리적 네트워크 구성과는 독립적인 개념적 모델로, 관리자가 조직의 요구에 맞춰 유연하게 리소스를 구성할 수 있도록 합니다.  

 
  • 포리스트(Forest): 포리스트는 Active Directory의 최상위 컨테이너이자 궁극적인 보안 및 관리 경계입니다. 하나 이상의 도메인으로 구성되며, 포리스트 내 모든 도메인은 공통된 논리적 구조, 디렉토리 스키마(클래스 및 특성 정의), 디렉토리 구성(사이트 및 복제 정보), 그리고 글로벌 카탈로그(포리스트 전반의 검색 기능)를 공유합니다. 포리스트 내의 모든 도메인은 기본적으로 양방향의 전이적 트러스트 관계로 자동 연결되어 있어, 적절한 권한만 부여되면 한 도메인의 사용자가 다른 도메인의 리소스에 접근할 수 있습니다.  
     
  • 트리(Tree): 트리는 연속적인 DNS 네임스페이스를 공유하는 하나 이상의 도메인 모음입니다. 예를 들어,   corp.contoso.com 도메인 아래에 sales.corp.contoso.com과 research.corp.contoso.com 같은 자식 도메인이 존재할 때 이들은 하나의 트리를 형성합니다.  
     
  • 도메인(Domain): 도메인은 포리스트 내의 파티션이자 복제 및 인증의 기본 단위입니다. 데이터를 파티셔닝함으로써 조직은 필요한 곳에만 데이터를 복제할 수 있게 되어, 제한된 대역폭을 가진 네트워크에서도 전 세계적으로 디렉터리를 확장할 수 있습니다. 또한 도메인은 네트워크 전반의 사용자 ID를 제공하고, 도메인 컨트롤러를 통해 사용자 계정과 자격 증명을 안전하게 저장하며 인증 서비스를 제공하는 핵심적인 역할을 수행합니다.  
     
  • 조직 구성 단위(Organizational Units, OU): OU는 도메인 내에서 객체를 그룹화하는 데 사용되는 컨테이너입니다. 주된 목적은 그룹 정책(Group Policy) 적용이나 관리 권한 위임과 같은 관리 작업을 용이하게 하는 것입니다. Microsoft는 관리 구조를 설계할 때 여러 도메인을 만드는 것보다 OU를 활용하여 권한을 위임하는 방식을 강력히 권장합니다. 이는 구조를 단순화하고 관리 복잡성을 줄여주기 때문입니다.  

물리적 인프라 (복제 및 트래픽 경계)

물리적 구조는 실제 네트워크의 논리적 표현으로, 복제 및 인증 트래픽을 제어하고 최적화하기 위해 설계됩니다. 이는 관리자가 네트워크 대역폭을 효율적으로 사용하고 사용자에게 최상의 성능을 제공하도록 돕습니다.  

 
  • 도메인 컨트롤러(Domain Controllers, DC): DC는 AD DS 역할을 실행하고 디렉터리 데이터베이스의 복제본을 저장하는 물리적 서버입니다. 네트워크에서 인증, 권한 부여 및 디렉터리 검색 요청을 처리하는 중추적인 역할을 합니다.  
     
  • 사이트(Sites): 사이트는 일반적으로 사무실이나 데이터 센터와 같은 물리적 위치를 나타내는, 하나 이상의 잘 연결된 IP 서브넷의 모음입니다. 사이트는 WAN(Wide Area Network) 링크를 통한 복제 트래픽을 제어하고, 클라이언트가 가장 가까운 로컬 리소스(특히 DC)에 연결되도록 보장하는 기본 메커니즘입니다.  
     
  • 서브넷(Subnets): 서브넷은 사이트에 매핑되는 IP 주소 범위입니다. 클라이언트의 IP 주소를 기반으로 해당 클라이언트가 속한 사이트를 식별하고, 이를 통해 DC 로케이터 프로세스가 "가장 가까운" DC를 찾을 수 있도록 합니다.  
     

분리 원칙: 확장성

논리적 구조와 물리적 구조의 독립성은 Active Directory의 매우 의도적이고 중요한 설계 특징입니다. 이 두 구조는 서로 다른 질문에 답합니다. 논리적 구조는 "무엇을 복제할 것인가?"(예: corp.contoso.com 도메인 파티션)에 대한 답을 제공하는 반면, 물리적 구조는 "어떻게, 언제, 어디로 복제할 것인가?"(예: 데이터를 압축하여 런던 사이트에서 뉴욕 사이트로 4시간마다 특정 사이트 링크를 통해 전송)에 대한 답을 제공합니다.

이러한 분리 덕분에 조직은 물리적 네트워크 레이아웃과 완전히 독립적인 복잡한 관리 계층(수많은 OU, 위임된 관리자)을 가질 수 있습니다. 관리자는 사이트 링크를 재구성하지 않고도 OU 구조를 변경할 수 있으며, 반대로 도메인 구조를 변경하지 않고도 새로운 지사를 열고, 새 사이트를 만들고, 복제를 최적화할 수 있습니다.

이 이중성을 이해하지 못하는 것은 AD 설계 결함의 흔한 원인이 됩니다. 예를 들어, 각 물리적 사무실마다 새로운 도메인을 설계하는 관리자(논리적 경계와 물리적 경계를 혼동)는 불필요한 관리 오버헤드와 복잡성을 초래합니다. 반면, 물리적 토폴로지를 무시하고 모든 DC를 기본 사이트인 Default-First-Site-Name에 방치하는 관리자는 막대한 WAN 트래픽, 느린 로그온, 그리고 결국 복제 실패를 유발하게 됩니다. 이 개념을 완벽히 숙지하는 것이 바로 AD 아키텍트가 되기 위한 첫걸음입니다.

제 2부: Active Directory 복제의 핵심 메커니즘

Active Directory의 안정성과 일관성은 정교한 복제 메커니즘에 의해 유지됩니다. 이 메커니즘은 변경 사항이 전체 포리스트에 걸쳐 효율적이고 안정적으로 전파되도록 보장합니다.

섹션 2.1: 다중 마스터 복제 모델

AD는 이전의 단일 마스터 모델과 달리, 상태 기반의 풀(Pull) 복제 모델을 채택하여 가용성과 내결함성을 극대화합니다.

  • 원칙:
    • 다중 마스터(Multi-Master): RODC를 제외한 모든 DC는 디렉터리 변경 사항을 수락할 수 있습니다. 이는 특정 마스터 서버에 대한 의존성을 제거하여 높은 가용성과 내결함성을 제공합니다.  
       
    • 느슨한 일관성과 수렴(Loose Consistency with Convergence): 이 모델은 DC 간에 일시적인 불일치를 허용하지만, 모든 업데이트가 중단되면 결국 모든 복제본이 동일한 상태로 수렴될 것을 보장합니다.  
       
    • 풀 복제(Pull Replication): 대상 DC가 소스 파트너에게 변경 사항을 요청하는 방식입니다. 변경 사항이 강제로 푸시(Push)되는 것이 아니라, 대상 DC가 자신의 상태와 일정에 따라 복제 프로세스를 제어합니다.  
       
    • 저장 후 전달(Store-and-Forward): DC는 모든 다른 DC와 직접 통신할 필요가 없습니다. 자신의 파트너와 복제하면, 그 파트너가 또 다른 파트너와 복제하는 연쇄적인 방식으로 변경 사항이 전체 토폴로지에 전파됩니다.  
       

"느슨한 일관성" 모델을 선택한 것은 의도적인 트레이드오프의 결과입니다. 트랜잭션 데이터베이스 클러스터와 같은 엄격하고 즉각적인 일관성은 모든 노드 간에 지속적이고 대량의 통신을 요구하며, 이는 전 세계적으로 분산된 불안정한 WAN 환경에서는 불가능합니다. 일시적인 불일치를 수용함으로써 AD는 수만 개의 DC와 신뢰할 수 없는 네트워크 링크를 아우르는 규모로 확장될 수 있습니다. "Pull" 모델은 한 걸음 더 나아가, 업데이트 요청의 책임을 자신의 상태와 네트워크 조건을 인지하고 있는 대상 DC에게 부여함으로써 이러한 확장성을 더욱 강화합니다. 이 설계는 관리자에게 중요한 시사점을 줍니다. 변경 사항이 기업 전체에 즉시 적용되지 않는다는 점을 이해해야 합니다. 이러한 지연(복제 대기 시간)은 암호 재설정이나 그룹 구성원 변경과 같은 운영 절차에 반드시 고려되어야 합니다. 예를 들어, 허브 사이트에서 변경이 이루어진 직후 원격 사이트의 사용자가 리소스에 즉시 액세스하지 못할 수 있습니다.

섹션 2.2: 변경 사항 추적: 복제 메타데이터의 역할

Active Directory는 네트워크를 통해 필요한 데이터만 전송되도록 보장하기 위해 내부 카운터와 테이블의 정교한 시스템을 사용합니다. 이 메타데이터는 복제 효율성의 핵심입니다.

  • 업데이트 시퀀스 번호(Update Sequence Number, USN): 각 DC에서 로컬로 유지 관리되는 64비트 카운터입니다. 원본 쓰기 또는 복제된 쓰기가 발생할 때마다 증가합니다. USN은 생성된 DC에서만 의미가 있으며, 다른 DC의 USN과 직접 비교할 수 없습니다.  
     
  • 하이워터마크 벡터(High-Watermark Vector, HWMV): 대상 DC가 각 직접 복제 파트너에 대해 유지 관리하는 테이블입니다. 특정 파티션에 대해 해당 파트너로부터 받은 가장 높은 USN을 기록합니다. 이는 소스 DC가 대상 DC가 이미 가지고 있는 변경 사항을 다시 보내는 것을 방지합니다.  
     
  • 업투데이트니스벡터(Up-to-Dateness Vector, UTDV): 각 DC가 유지 관리하는 테이블로, 특정 파티션에 대해 포리스트 내의 모든 다른 DC(직접 및 전이적 파트너 모두)로부터 확인한 가장 높은 원본 쓰기 USN을 추적합니다. 대상 DC가 변경을 요청할 때 UTDV를 소스 DC에 보냅니다. 소스 DC는 이 정보를 사용하여 대상 DC가 이미 다른 파트너를 통해 최신 상태인 변경 사항을 필터링합니다.  
     

이 세 가지 메타데이터 구성 요소는 정교한 다계층 필터링 시스템을 형성하며, 각각은 중복되지 않고 뚜렷한 목적을 가집니다. 이 시스템의 작동 방식은 다음과 같습니다.

  1. 대상 DC(DC2)가 소스 DC(DC1)로부터 복제를 시작하려고 합니다.
  2. DC2는 DC1에 대한 자신의 HWMV를 DC1에게 보냅니다. 이는 "내가 당신에게서 직접 받은 변경 사항은 다시 보내지 말라"는 의미입니다. 이것이 첫 번째 기본 필터입니다.
  3. DC2는 또한 자신의 UTDV를 DC1에게 보냅니다. 이 테이블은 "내가 DC3, DC4, DC5 등에서 시작된 변경 사항 중 가장 최신으로 본 것은 이것이다"라고 알려줍니다.
  4. DC1은 이 UTDV를 사용하여 DC2가 이미 가지고 있는 변경 사항을 보내지 않도록 합니다. 예를 들어, DC1이 USN 500을 가진 DC3에서 시작된 변경 사항을 가지고 있지만, DC2의 UTDV가 이미 DC3로부터 USN 500을 보았다고(아마도 DC4와의 복제를 통해) 표시되면, DC1은 해당 변경 사항을 보내지 않습니다. 이는 동일한 변경 사항이 여러 경로를 통해 중복으로 복제되는 것을 방지합니다.
  5. USN은 이 모든 것을 가능하게 하는 기본 원자적 카운터입니다.

이 시스템은 AD 복제 효율성의 "비밀 소스"와 같습니다. 복잡한 다중 경로 토폴로지에서도 특정 변경 사항이 대상 DC에 일반적으로 한 번만 복제되도록 보장합니다. 이것이 AD가 느리고 비용이 많이 드는 WAN 링크를 통해 지속적인 전체 데이터베이스 비교 없이 작동할 수 있는 이유입니다.

섹션 2.3: 디렉터리 파티션: 복제의 단위

AD 데이터베이스(NTDS.DIT)는 논리적으로 여러 파티션(네이밍 컨텍스트 또는 NC라고도 함)으로 나뉩니다. 각 파티션은 고유한 복제 범위와 일정을 가집니다.  

 
  • 스키마 파티션(Schema Partition): 모든 객체 클래스와 속성의 정의를 포함합니다. 포리스트 전체의 모든 DC에 복제됩니다. 스키마 변경은 매우 중요하며, 완료될 때까지 다른 복제를 차단할 수 있습니다.  
     
  • 구성 파티션(Configuration Partition): 사이트 및 복제 토폴로지 정보를 포함하여 포리스트의 논리적 구조를 담고 있습니다. 포리스트 전체의 모든 DC에 복제됩니다.  
     
  • 도메인 파티션(Domain Partition): 특정 도메인의 모든 객체(사용자, 그룹, 컴퓨터 등)를 포함합니다. 해당 도메인 내의 DC에만 복제됩니다. 이는 복제 트래픽을 제한하는 주된 데이터 파티셔닝 방법입니다.  
     
  • 애플리케이션 디렉터리 파티션(Application Directory Partitions): AD 통합 DNS와 같은 애플리케이션을 위한 사용자 지정 파티션으로, 관리자가 유연한 복제 범위를 정의할 수 있게 해줍니다. 글로벌 카탈로그의 일부가 되지 않으면서 포리스트 내 다른 도메인의 DC를 포함한 특정 DC 하위 집합에 복제될 수 있습니다. 이는 동적 데이터 저장에 이상적입니다.  
     

다음 표는 각 디렉터리 파티션의 특성을 요약한 것입니다.

표 1: AD 디렉터리 파티션

파티션 이름 일반적인 내용 기본 복제 범위 표준 DC에서 쓰기 가능 여부 글로벌 카탈로그에 복제 여부
스키마 객체 클래스 및 속성 정의 포리스트 전체 아니요 (스키마 마스터만) 예 (전체)
구성 포리스트 토폴로지 (사이트, 서브넷, 도메인 등) 포리스트 전체 예 예 (전체)
도메인 사용자, 그룹, 컴퓨터 등 도메인 특정 객체 도메인 전체 예 아니요 (부분 집합만 GC로)
포리스트 DNS 애플리케이션 파티션 ForestDnsZones의 DNS 레코드 포리스트의 모든 DNS 서버 예 아니요
도메인 DNS 애플리케이션 파티션 DomainDnsZones의 DNS 레코드 도메인의 모든 DNS 서버 예 아니요
사용자 지정 애플리케이션 파티션 애플리케이션별 데이터 관리자가 지정한 DC 집합 예 아니요

이 표는 관리자가 AD 내의 다양한 데이터 유형과 기본 복제 동작을 한눈에 파악하는 데 필수적인 참조 자료를 제공합니다. 예를 들어, DNS 문제를 해결하는 관리자는 DNS 데이터가 애플리케이션 파티션에 저장되며 , 복제 범위가 도메인 파티션과 다를 수 있다는 것을 알아야 합니다. 마찬가지로, AD를 스토리지로 사용하는 새 애플리케이션을 계획하는 사람은 복제 오버헤드를 제한하기 위해 사용자 지정 애플리케이션 파티션을 생성하는 것의 이점을 이해해야 합니다.  

 

제 3부: 복제 토폴로지 구축: KCC와 ISTG의 역할

Active Directory의 복제 토폴로지는 수동으로 생성되지 않습니다. 대신, KCC(Knowledge Consistency Checker)와 ISTG(Inter-Site Topology Generator)라는 두 가지 자동화된 프로세스에 의해 동적으로 생성되고 유지 관리됩니다.

섹션 3.1: 사이트 내 복제와 KCC(Knowledge Consistency Checker)

KCC는 모든 DC에서 실행되는 내장 프로세스로, 복제 토폴로지를 자동으로 생성하는 역할을 합니다. 기본적으로 15분 간격으로 실행됩니다.  

 
  • 토폴로지 생성: 사이트 내 복제를 위해 KCC는 사이트의 모든 DC를 연결하는 양방향 링(bidirectional ring) 토폴로지를 생성합니다. 이는 내결함성을 위해 모든 DC에 항상 최소 두 개의 복제 경로가 있도록 보장합니다. DC가 3개 이상인 경우, KCC는 링을 가로지르는 "바로 가기(shortcut)" 연결을 추가하여 두 DC 간의 최대 홉(hop) 수를 3개 이하로 유지함으로써 대기 시간을 최적화합니다.  
     
  • 연결 개체(Connection Objects): KCC는 각 DC에 인바운드 복제 파트너를 정의하는 연결 개체를 생성합니다. 이 개체들은 AD 사이트 및 서비스 스냅인에서 <자동으로 생성됨>으로 표시됩니다. KCC는 관리자가 수동으로 생성한 연결은 수정하지 않습니다.  
     
  • 변경 알림(Change Notification): 사이트 내에서는 DC에서 변경이 발생하면 몇 초(기본 15초) 대기한 후 복제 파트너에게 변경 사실을 알립니다. 그러면 파트너는 해당 변경 사항을 가져옵니다(pull). 이 메커니즘은 거의 즉각적인 복제를 제공합니다. 예약된 복제는 알림 프로세스가 실패할 경우를 대비한 백업 메커니즘일 뿐입니다.  
     

섹션 3.2: 사이트 간 복제와 ISTG(Inter-Site Topology Generator)

  • ISTG 역할: 사이트당 하나의 DC가 자동으로 ISTG로 지정됩니다. ISTG는 해당 사이트의 사이트 간 복제 토폴로지를 관리할 책임이 있습니다. 사이트의 첫 번째 DC가 이 역할을 맡으며, 만약 60분 동안 오프라인 상태가 되면 새로운 ISTG가 선출됩니다.  
     
  • 브리지헤드 서버(Bridgehead Servers): 사이트의 ISTG는 다른 사이트의 브리지헤드 서버와 복제를 담당할 하나 이상의 DC를 해당 사이트의 브리지헤드 서버로 선택합니다. ISTG는 부하를 분산시키기 위해 적격한 모든 DC 간에 복제 연결을 분배합니다.  
     
  • 토폴로지 생성: 각 사이트의 ISTG는 사이트 링크와 관련 비용을 사용하여 모든 사이트를 연결하는 **최소 비용 스패닝 트리(least-cost spanning tree)를 계산합니다. 이는 모든 사이트 간에 효율적이고 루프가 없는 복제 경로를 보장합니다. 그런 다음 ISTG는 해당 사이트의 브리지헤드 서버에 다른 사이트의 브리지헤드 서버에 연결하기 위한 인바운드 연결 개체를 생성합니다.  

KCC와 ISTG: 두 가지 범위의 이야기 (개별주의자와 리더)

KCC와 ISTG는 별개의 두 시스템이 아니라, 각각 다른 운영 범위와 지식 수준을 가진 동일한 기본 NTDS 서비스의 두 가지 역할입니다.

  1. KCC는 서버 수준에서 작동합니다. 에서 언급했듯이, 그 범위는 "로컬 서버에만" 국한됩니다. DC1에서 실행될 때, "내 사이트의 다른 DC들을 기반으로, 내가 누구로부터 변경 사항을 가져와야 하는가?"를 생각하고 자신의 인바운드 연결을 생성합니다. 이는 분산된 자율 에이전트와 같습니다.  
     
  2. ISTG는 사이트 수준에서 작동합니다. SiteA의 지정된 리더로서, 전체 포리스트 토폴로지 를 보고 "SiteA는 SiteB 및 SiteC와 어떻게 연결되는가? 사이트 링크 비용을 기반으로, 내 DC 중 어느 것이 브리지헤드 서버가 되어야 하며, 어떤 외부 브리지헤드 서버와 통신해야 하는가?"를 결정합니다. 그런 다음 선택된 브리지헤드 서버에 필요한 연결 개체를 생성합니다.  

이러한 2계층 설계는 매우 효율적입니다. 빠르고 안정적인 LAN(사이트 내)의 경우, 각 DC의 KCC가 관리하는 단순하고 분산된 자가 치유 링 구조로 충분하며 견고합니다. 복잡하고, 느리고, 비용이 많이 드는 WAN(사이트 간)의 경우, 사이트별로 지정된 단일 리더(ISTG)가 복잡한 라우팅 결정을 내림으로써 혼란을 방지하고 토폴로지가 해당 사이트의 연결에 대해 일관된 단일 계산을 기반으로 하도록 보장합니다. KCC를 비활성화하는 것 은 이 복잡하고 동적인 시스템을 수동으로 관리해야 하므로 거의 권장되지 않습니다.  

 

제 4부: 탄력적이고 효율적인 복제 토폴로지 설계

잘 설계된 복제 토폴로지는 Active Directory 환경의 성능, 안정성 및 확장성을 보장하는 데 매우 중요합니다. 이는 단순히 DC를 배치하는 것 이상으로, 네트워크의 물리적 특성을 AD의 논리적 구성 요소에 정확하게 매핑하는 과정입니다.

섹션 4.1: 사이트, 서브넷 및 클라이언트 선호도

사이트의 주된 목적은 복제 트래픽을 제어하고 클라이언트가 DC를 포함한 로컬 네트워크 리소스를 찾을 수 있도록 하는 것입니다. 클라이언트가 DC를 찾아야 할 때, DC 로케이터 프로세스는 클라이언트의 IP 주소를 사용하여 AD에서 일치하는 서브넷 개체를 찾습니다. 이 서브넷 개체는 사이트에 연결되어 있어, 클라이언트에게 어떤 DC가 "로컬"인지 알려줍니다.  

 

따라서 모든 IP 서브넷을 정확하게 정의하고 올바른 사이트와 연결하는 것은 AD 관리에서 가장 중요하고 기본적인 작업 중 하나입니다. 이를 제대로 구성하지 않으면 클라이언트가 느린 WAN 링크를 통해 원격 DC에서 인증을 시도하게 되어 로그온 시간이 길어지고 네트워크 대역폭이 낭비됩니다.  

 

섹션 4.2: 사이트 링크: 경로 정의

사이트 링크는 둘 이상의 사이트 간의 네트워크 경로를 나타내는 논리적 개체입니다. 이는 물리적인 라우터나 회로에 직접 대응하는 것이 아니라, 전이적 연결성을 나타냅니다. KCC/ISTG는 이 사이트 링크를 사용하여 브리지헤드 서버 간의 실제 연결 개체를 생성합니다.  

 
  • 주요 특성:
    • 비용(Cost): 링크의 선호도를 나타내는 숫자 값(1-32,767, 기본값 100)입니다. 낮은 비용이 선호되며, ISTG는 항상 총비용이 가장 낮은 경로를 선택합니다.  
       
    • 복제 빈도/간격(Replication Frequency/Interval): 사이트 간 복제 사이의 시간(분)입니다(15-10,080, 기본값 180). 이는 브리지헤드 서버가 업데이트를 확인하는 주기를 결정합니다.  
       
    • 일정(Schedule): 사이트 링크를 복제에 사용할 수 있는 시간표입니다. 이를 사용하여 업무 시간 동안의 복제를 방지할 수 있습니다.  

다음 표는 관리자가 실제 네트워크 특성에 따라 이러한 값을 설정하는 데 도움이 되는 전략적 가이드를 제공합니다.

표 2: 사이트 링크 속성 - 전략적 가이드

속성 설명 기본값 구성 가능 범위 전략적 지침 및 모범 사례
비용
(Cost)		 복제 경로의 상대적 선호도. 값이 낮을수록 선호됨. 100 1 – 32,767 네트워크 대역폭에 반비례하여 설정합니다. (예: 1Gbps 링크 = 50, 100Mbps 링크 = 100). 실제 비용이 아닌, 선호도를 나타내는 논리적 값입니다.
복제 빈도(간격) 사이트 간 복제가 발생하는 시간 간격. 180분 15 – 10,080분 비즈니스의 데이터 대기 시간 허용 오차(RPO)에 따라 설정합니다. 중요한 데이터는 짧은 간격으로, 덜 중요한 데이터는 긴 간격으로 설정하여 WAN 대역폭을 절약합니다.
일정(Schedule) 복제가 허용되는 시간. 매일 24시간 특정 시간/요일 네트워크 사용량이 적은 시간(예: 야간)에만 복제가 발생하도록 예약하여 피크 시간대의 네트워크 경합을 줄입니다. 일부 WAN 링크는 시간대에 따라 비용이 다를 수 있습니다.

이 표는 추상적인 개념을 구체적이고 실행 가능한 지침으로 전환합니다. 예를 들어, 관리자는 1Gbps 링크와 100Mbps 링크를 보고 비용을 어떻게 설정해야 할지 고민할 때 이 표를 참조하여 대역폭이 높은 링크에 더 낮은 비용을 할당하는 결정을 내릴 수 있습니다.  

 

섹션 4.3: 사이트 링크 브리지: 분리된 네트워크 연결

기본적으로 "모든 사이트 링크 브리지(Bridge all site links)" 옵션이 활성화되어 있습니다. 이는 모든 사이트 링크가 전이적인 것으로 간주됨을 의미합니다. 즉, SiteA가 SiteB에 연결되고 SiteB가 SiteC에 연결되면, AD는 SiteA가 SiteB를 통해 SiteC와 복제할 수 있다고 가정합니다.  

 

이 기본 설정은 모든 사이트가 다른 모든 사이트에 도달할 수 있는 완전한 라우팅 IP 네트워크에 적합합니다. 이 일반적인 시나리오에서는 수동 사이트 링크 브리지가 필요하지 않습니다.  

 

네트워크가 완전히 라우팅되지 않은 경우(예: 스포크가 서로 직접 통신할 수 없는 허브-앤-스포크 네트워크)에만 "모든 사이트 링크 브리지" 옵션을 비활성화하고 수동 사이트 링크 브리지를 만들어야 합니다. 이는 KCC가 불가능한 복제 경로를 생성하려는 시도를 방지합니다.  

 

섹션 4.4: 아키텍처 패턴: 허브-앤-스포크 모델

이는 중앙 본사(허브)와 여러 지사(스포크)를 둔 기업에서 가장 일반적이고 권장되는 토폴로지입니다.  

 
  • 설계:
    • 중앙/허브 사이트에는 주 데이터 센터 DC가 포함됩니다.
    • 각 원격/스포크 사이트에는 자체 DC가 있습니다.
    • 각 스포크 사이트를 허브 사이트에 연결하기 위해 별도의 사이트 링크가 생성됩니다(예: SpokeA-Hub, SpokeB-Hub).  
    • 허브가 전이적 라우팅을 제공하므로 "모든 사이트 링크 브리지" 옵션은 일반적으로 활성화된 상태로 둡니다. 허브 사이트의 사이트 링크에 모든 스포크 사이트를 포함할 필요는 없으며, 개별 링크만으로 충분합니다.  
  • 이점: 이 모델은 관리를 단순화하고, 제어 및 보안을 중앙 집중화하며, 확장성이 매우 뛰어납니다. 새로운 스포크 사이트를 추가하는 것은 허브에 대한 새로운 사이트 링크 하나를 만드는 것만으로 충분합니다.  

허브-앤-스포크 모델에서 스포크 사이트의 ISTG는 다른 스포크 사이트로 가는 가장 저렴한 경로를 항상 허브를 통하는 것으로 간주합니다. 예를 들어, SpokeA-Hub 링크의 비용이 100이고 SpokeB-Hub 링크의 비용도 100이라면, SpokeA의 ISTG는 SpokeB에 도달하는 비용을 200(100+100)으로 계산합니다. 따라서 SpokeA의 브리지헤드 서버에서 허브의 브리지헤드 서버로의 복제 연결을 생성하며, SpokeB에 직접 연결을 시도하지 않습니다. 이는 물리적 네트워크 트래픽 흐름을 정확하게 모델링합니다. 이 예는 단순한 사이트 및 사이트 링크 개체를 올바르게 구성하는 것만으로도 복잡한 KCC/ISTG 알고리즘이 의도된 네트워크 설계를 반영하는 효율적인 복제 토폴로지를 자동으로 생성하는 방법을 보여줍니다. 이는 수동으로 연결 개체를 만들 필요가 없음을 의미합니다.  

 

제 5부: 고급 복제 개념 및 특수 역할

기본적인 복제 메커니즘 외에도, Active Directory는 특정 시나리오를 해결하기 위한 고급 기능과 특수화된 DC 역할을 제공합니다.

섹션 5.1: 글로벌 카탈로그와 포리스트 전반의 검색

  • 기능: 글로벌 카탈로그(GC) 서버는 자체 도메인 파티션의 전체 쓰기 가능 복제본과 포리스트 내 다른 모든 도메인 파티션의 부분적 읽기 전용 복제본을 저장하는 DC입니다.  
     
  • 목적: 주된 역할은 포리스트 전반의 객체 검색을 용이하게 하고(사용자는 객체의 도메인을 몰라도 찾을 수 있음), 다중 도메인 환경에서 유니버설 그룹(Universal Group) 구성원 정보를 확인하여 로그온을 처리하는 것입니다.  
     
  • 부분 특성 집합(Partial Attribute Set, PAS): GC에 복제되는 특성의 하위 집합을 PAS라고 합니다. 검색에 자주 사용되고 변동성이 낮은 특성들이 PAS에 포함됩니다. 스키마 객체의   isMemberOfPartialAttributeSet 속성이 TRUE로 설정되면 해당 특성이 PAS에 포함됩니다.  
  • 복제: GC 데이터는 표준 사이트 간 복제 프로세스를 통해 복제됩니다. KCC는 모든 GC 서버가 모든 도메인으로부터 부분 복제본을 수신하도록 토폴로지를 자동으로 생성합니다.  
     

섹션 5.2: 읽기 전용 도메인 컨트롤러(RODC)

  • 목적: RODC는 지사와 같이 물리적 보안이 취약한 위치에 배포하기 위해 설계되었습니다. AD 데이터베이스의 읽기 전용 복사본을 호스팅합니다.  
     
  • 복제: 복제는 단방향입니다. RODC는 쓰기 가능한 DC 파트너(Windows Server 2008 이상 실행)로부터 변경 사항을 가져오지만, 다른 DC로 변경 사항을 아웃바운드로 복제하지는 않습니다. 이는 손상된 RODC에서 발생한 악의적인 변경이 전파되는 것을 방지합니다. 암호 변경과 같은 쓰기 작업은 쓰기 가능한 DC로 전달되어 처리됩니다.  
     
  • 자격 증명 캐싱 및 암호 복제 정책(PRP): 기본적으로 RODC는 사용자 암호를 캐시하지 않습니다. PRP는 성공적으로 인증한 후 어떤 계정의 자격 증명을 RODC에 캐시할 수 있도록 허용 또는 거부할지 명시적으로 정의합니다. 이는 RODC가 도난당했을 때의 "피해 범위"를 제한합니다.  
     
  • 필터링된 특성 집합(FAS): 매우 민감한 애플리케이션 속성이 포리스트의 어떤 RODC에도 복제되지 않도록 방지하여 보안을 더욱 강화하는 메커니즘입니다.  
     

섹션 5.3: 복제 프로토콜 및 데이터 압축

  • 사이트 내 복제: RPC over IP를 사용합니다. 데이터는 압축되지 않습니다. 이는 대역폭이 풍부하고 CPU 사이클이 더 중요한 고속, 저지연 LAN을 가정하기 때문입니다.  
     
  • 사이트 간 복제: RPC over IP 또는 SMTP를 사용할 수 있습니다.
    • RPC over IP (기본값): 표준 프로토콜입니다. 데이터는 느린 WAN 링크를 통한 대역폭 사용을 최소화하기 위해 원래 크기의 약 10-15%로 압축됩니다.  
       
    • SMTP: 직접적인 IP 연결이 불가능하거나 RPC 포트가 차단된 상황을 위한 레거시 옵션입니다. 도메인 파티션을 복제할 수 없어(스키마, 구성, GC만 가능) 도메인 내 복제에는 사용할 수 없는 등 상당한 제한이 있습니다. 현대 네트워크에서는 일반적으로 권장되거나 사용되지 않습니다.  
       

다음 표는 사이트 내 복제와 사이트 간 복제의 주요 차이점을 요약한 것입니다.

표 3: 사이트 내 복제와 사이트 간 복제 비교 분석

특성 사이트 내 복제 (Intra-site) 사이트 간 복제 (Inter-site)
주된 목표 변경 전파 속도 극대화 대역폭 효율성 극대화
트리거 메커니즘 변경 알림 (Notify-Pull) 예약된 간격 (Scheduled Pull)
기본 빈도 15초 지연 후 즉시 알림 180분 (3시간)
데이터 압축 아니요 예 (RPC 및 SMTP)
전송 프로토콜 RPC over IP RPC over IP (기본값), SMTP
토폴로지 양방향 링 + 바로 가기 연결 최소 비용 스패닝 트리
토폴로지 생성기 각 DC의 KCC 각 사이트의 ISTG

이 표는 두 복제 유형 간의 핵심 차이점을 명확하고 간결하게 요약하여 제공합니다. 예를 들어, 사이트 내 복제는 압축되지 않고 변경 알림을 사용하는 반면, 사이트 간 복제는 압축되고 일정을 사용한다는 것을 보면, 설계 목표가 사이트 내에서는 속도, 사이트 간에는 대역폭 효율성이라는 점을 즉시 파악할 수 있습니다.

제 6부: 복제 상태 모니터링, 문제 해결 및 유지 관리

건강한 Active Directory 환경을 유지하려면 복제 상태를 정기적으로 모니터링하고 발생하는 문제를 신속하게 해결하는 것이 필수적입니다.

섹션 6.1: 필수 진단 도구

모든 AD 관리자가 숙달해야 하는 명령줄 도구에 대한 실용적인 가이드입니다.

  • Repadmin (복제 진단 도구): 복제 모니터링 및 문제 해결을 위한 기본 도구입니다.  
    • repadmin /replsummary: 포리스트 전체의 상태 요약을 제공하여 델타와 실패를 보여줍니다. 빠른 점검을 위해 가장 먼저 실행해야 할 명령입니다.  
       
    • repadmin /showrepl: 특정 DC의 인바운드 복제에 대한 상세 상태(파트너, 마지막 성공/실패 시간, 오류 코드 포함)를 표시합니다.  
       
    • repadmin /queue: 현재 복제 큐에 있는 항목 수를 표시하여 백로그를 나타냅니다.  
       
    • repadmin /kcc: 지정된 DC에서 KCC를 즉시 실행하도록 강제합니다.  
       
    • repadmin /syncall: 지정된 DC 및 파티션에 대한 즉각적인 복제를 트리거합니다.  
       
  • Dcdiag (도메인 컨트롤러 진단 도구): DC에 대한 포괄적인 상태 점검 유틸리티입니다.  
    • dcdiag /test:replications: 시기적절한 복제를 확인하고 오류를 보고합니다.  
       
    • dcdiag /test:dns: 복제 실패의 가장 흔한 근본 원인인 DNS에 대한 일련의 테스트를 수행합니다.  
       
    • 주요 스위치: /s: (서버), /a (사이트의 모든 서버), /e (엔터프라이즈의 모든 서버), /q (조용한 모드, 오류만 표시), /v (상세 정보).  

다음 표들은 현장의 관리자들이 문제를 진단할 때 신속하게 참조할 수 있는 실용적인 작업 보조 자료 역할을 합니다.

표 4: Repadmin 명령 빠른 참조

명령/스위치 목적 예제 구문
/replsummary 포리스트의 모든 DC에 대한 복제 상태 요약을 표시합니다. repadmin /replsummary
/showrepl 특정 DC의 인바운드/아웃바운드 복제 파트너 및 상태를 표시합니다. repadmin /showrepl DC01
/queue 특정 DC의 복제 큐에 대기 중인 변경 사항을 표시합니다. repadmin /queue DC01
/kcc 특정 DC에서 KCC를 강제로 실행하여 토폴로지를 재계산합니다. repadmin /kcc DC01
/syncall 특정 DC가 모든 파트너와 동기화하도록 강제합니다. repadmin /syncall DC01 /AdeP
/removelingeringobjects 잔류 개체를 식별하고 제거합니다. repadmin /removelingeringobjects <TargetDC> <RefDC_GUID> <PartitionDN> /advisory_mode
 

표 5: Dcdiag 명령 빠른 참조

명령/스위치 목적 예제 구문
(기본) 지정된 DC(또는 로컬 DC)에 대한 모든 테스트를 실행합니다. dcdiag /s:DC01
/test:Replications 복제 관련 테스트만 실행합니다. dcdiag /s:DC01 /test:Replications
/test:DNS 모든 DNS 관련 테스트를 실행합니다. dcdiag /s:DC01 /test:DNS /e /v
/e 포리스트의 모든 DC에 대해 테스트를 실행합니다. dcdiag /e
/q 오류만 표시하여 출력을 간소화합니다. dcdiag /s:DC01 /q
/f:<logfile> 결과를 지정된 로그 파일에 저장합니다. dcdiag /c /v /f:C:\Logs\dcdiag_report.txt

 

섹션 6.2: 일반적인 복제 문제 및 해결 방법

가장 빈번하게 발생하는 문제에 대한 실용적인 가이드입니다.

  • DNS 구성 오류: 가장 흔한 원인입니다. DC 네트워크 어댑터의 잘못된 DNS 서버 설정, 오래되거나 잘못된 SRV 레코드, 조건부 전달자 실패 등이 포함됩니다.  
     
  • 네트워크 연결: 방화벽이 RPC 포트(TCP 135 및 동적 RPC 범위)를 차단하거나, 라우터 구성 오류, WAN 링크 장애 등이 원인일 수 있습니다.  
     
  • 시간 왜곡(Time Skew): DC 간의 시간이 5분(기본값) 이상 차이 나면 Kerberos 인증이 실패하고, 이로 인해 "액세스 거부" 오류와 함께 복제가 실패합니다.  
     
  • 인증/권한 부여 문제: 디렉터리 파티션에 대한 잘못된 권한이나 컴퓨터 계정 문제로 인해 "액세스 거부"(오류 5)가 발생할 수 있습니다.  
     

섹션 6.3: 고급 문제 해결: 잔류 개체(Lingering Objects)

  • 원인: DC가 포리스트의 삭제 표시 수명(Tombstone Lifetime, TSL)보다 긴 기간 동안 토폴로지에서 연결이 끊긴 경우 발생합니다. 이 기간 동안 객체가 삭제되고 네트워크의 나머지 부분에서 가비지 수집이 완료됩니다. 연결이 끊겼던 DC가 다시 온라인 상태가 되면, 포리스트의 나머지 부분에서는 유효하지 않은 것으로 간주되는 객체의 복사본을 보유하게 됩니다.  
     
  • 증상: "엄격한 복제 일관성(Strict Replication Consistency)"이 활성화된 정상 DC가 오래된 DC로부터 "좀비" 객체를 수신하기를 거부할 때 복제가 오류 8606("개체를 만드는 데 불충분한 특성이 제공되었습니다...")과 함께 실패하거나 이벤트 ID 1988, 1388 또는 2042가 기록됩니다.  
     
  • 해결 방법:
    1. 잔류 개체가 있는 소스 DC와 정상적인 최신 상태의 참조 DC를 식별합니다.
    2. repadmin /removelingeringobjects 명령을 사용합니다. 먼저 /advisory_mode로 실행하여 실제로 삭제하지 않고 삭제될 대상을 기록하는 것이 매우 중요합니다.  
       
    3. 명령 구문은 다음과 같습니다: repadmin /removelingeringobjects <TargetDC> <ReferenceDC_GUID> <PartitionDN> /advisory_mode.  
       
    4. 확인 후, /advisory_mode 없이 명령을 다시 실행하여 정리 작업을 수행합니다.
    5. LOL(Lingering Object Liquidator) 도구는 GUI 기반의 대안을 제공합니다.  
       
  • 예방: 복제 상태를 사전에 모니터링하고 , 어떤 DC도 TSL보다 오래 오프라인 상태이거나 격리되지 않도록 합니다. DC가 장기간 오프라인 상태여야 하는 경우, 강등시키고 네트워크에서 제거해야 합니다.  
     

제 7부: 전략적 권장 사항 및 미래 대비

섹션 7.1: 건강한 토폴로지를 위한 핵심 설계 원칙

  • 사전 모니터링: 장애가 발생하기를 기다리지 마십시오. repadmin /replsummary 및 Dcdiag와 같은 도구를 예약된 스크립트에서 사용하여 매일 상태 보고서를 생성하십시오.  
     
  • 단순함이 핵심: 지나치게 복잡한 토폴로지를 피하십시오. 대부분의 조직에서는 단일 포리스트, 단일 도메인, 허브-앤-스포크 사이트 토폴로지가 가장 관리하기 쉽고 견고한 설계입니다. 자율성 및 격리에 대한 엄격한 비즈니스 또는 보안 요구 사항이 없는 한 추가 도메인이나 포리스트를 만들지 마십시오.  
     
  • 재해 복구 계획: 잘 설계된 복제 토폴로지는 고가용성을 제공하지만, 백업을 대체하지는 않습니다. 둘의 차이점을 이해하고 AD에 대한 견고한 백업 및 복구 계획을 마련하십시오.  
     

섹션 7.2: 하이브리드 클라우드에서의 복제

이 섹션에서는 현대적인 고려 사항을 간략하게 다룹니다.

  • 온프레미스 AD를 클라우드 IaaS 제공업체(예: Azure VM)로 확장할 때, 클라우드 VNet은 AD 토폴로지에서 또 다른 사이트로 취급되어야 합니다. 온프레미스 허브 사이트와 새로운 클라우드 사이트를 연결하기 위해 사이트 링크를 생성해야 합니다.
  • Managed Microsoft AD 와 같은 클라우드 네이티브 서비스는 토폴로지 관리 및 유지 관리 부담의 상당 부분을 자동화할 수 있지만, 기존 온프레미스 AD에 연결하기 위해 포리스트 트러스트가 필요한 경우가 많아 자체적인 설계 고려 사항이 발생합니다.  
  • 특히 허브-앤-스포크 VPC 모델과 비전이적 피어링을 사용하는 클라우드의 네트워크 연결은 DC 간의 통신을 보장하기 위해 신중하게 계획해야 하는 복잡성을 더할 수 있습니다.  

결론

Active Directory 복제 및 토폴로지는 단순한 기술적 구성이 아니라, 분산된 기업 환경에서 ID 및 액세스 관리의 핵심을 이루는 유기적인 시스템입니다. 이 보고서에서 분석한 바와 같이, AD의 아키텍처는 논리적 관리 구조와 물리적 트래픽 제어 구조를 의도적으로 분리하여 탁월한 확장성과 유연성을 제공합니다. 다중 마스터 모델과 USN, HWMV, UTDV와 같은 정교한 메타데이터는 WAN 링크를 통해 효율적인 변경 전파를 보장하며, KCC와 ISTG는 복잡한 네트워크 환경에서도 최적의 복제 경로를 동적으로 생성하고 유지 관리합니다.

 

성공적인 Active Directory 관리의 핵심은 이러한 기본 원칙을 깊이 이해하는 데 있습니다. 관리자는 사이트, 서브넷, 사이트 링크를 사용하여 물리적 네트워크를 정확하게 모델링해야 하며, 허브-앤-스포크와 같은 검증된 아키텍처 패턴을 적용하여 복잡성을 줄여야 합니다. 또한, Repadmin 및 Dcdiag와 같은 도구를 활용한 사전 모니터링은 잠재적인 문제를 조기에 발견하고, DNS 오류나 잔류 개체와 같은 심각한 장애로 발전하기 전에 해결하는 데 필수적입니다.

결론적으로, 잘 설계되고 세심하게 관리되는 복제 토폴로지는 안정적이고, 안전하며, 성능이 뛰어난 Active Directory 서비스의 기반입니다. 이는 단순한 기술적 과제를 넘어, 비즈니스의 연속성과 생산성을 지원하는 전략적 자산이라 할 수 있습니다.

반응형