Active Directory: 설정 및 문제해결 5(DNS)

2014년 9월 17일 윈도우 서버+가상화 9,793 조회 수

교재: 6425C – Configuring and Troubleshooting Windows Server 2008 Active Directory Domain Services

마지막 날.

MS제품은 권장 설정이 기본값임.

DNS를 새로 만들면 처음 Zone(영역)을 만들게 됨.

보안 통신 / 동적 업데이트가 기본값
정방향 / 역방향 조회

TTL

클라이언트가 가지는 캐시 값이 최대 언제까지 저장되는지

DNS 라운드 로빈

www.contoso.com 이라는 이름을 서버 3대가 서로 다른 IP로 순서대로 돌아가며 해줄 수 있음.
- 이를 구현할 때 별칭(CNAME) 사용

AD 이중화

자연스럽게 DNS 이중화가 됨
Zone Transfer: 만약 AD가 한 대인데 DNS만 이중화하려면 다른 서버에 DNS를 올려서 master-secondary 구조로 만들 수 있음. 이런 식으로 보조 서버를 만들 수 있음.

전달자 구성

내(DNS 서버)가 파악할 수 없는 정보를 물어 보면 다른 DNS 서버에 물어 봐야 함.
- 기본적으로 IAEA? IP가 지정되어 있다.

클라이언트 IP 구성

netsh로 할 수도 있지만 PowerShell로도 할 수 있음.

nslookup www.aaa.com

권한 없는 응답이라고 떨어지면 ‘확신(신뢰)할 수는 없지만 내가 물어 본 바 결과는 이래.’ 라는 느낌.
DNS도 속일 수 있음

Split-Brain DNS

AD DS를 지원하는 영역
- 인터넷 노출로부터 안전
- 동적
- AD DS 클라이언트, 서버, 서비스 레코드로 전체가 채워짐
외부 네임스페이스를 지원하는 영역
- 보안
- 동적
- 외부 리소스 관련 레코드로 채워짐
수작업으로 유지관리 – 레코드의 일부 중복, www
- DNS에서 에이징 메뉴 선택하면 됨.

AD 통합 영역

DNS 영역 데이터는 AD DS에 저장됨
보안 동적 업데이트

DNS 애플리케이션 파티션

영역 복제 범위 변경
- 포리스트/도메인 단위 선택 가능

동적 업데이트 과정

클라이언트가 먼저 쿼리를 보냄. SOA(Start of Authority; 권한의 시작)
- 자기 이름. DNS 서비스를 할 수 있는 놈이 누구냐?
나야~ (DNS 서버가 SOA RR 반환)
클라이언트가 동적 업데이트를 할 수 있는지 식별(DNS 서버에 요청)
DNS 서버는 업데이트 수행 가능함을 응답
클라이언트가 DNS 서버에 비 보안 업데이트를 보냄
영역에서 보안 업데이트만 허용하면 업데이트는 거절됨
클라이언트는 DNS 서버에 보안 업데이트를 보냄

**클라이언트가 시작할 때 위 동적 업데이트 과정을 거침. 클라이언트의 IP가 바뀌면 위 업데이트가 일어남. ipconfig를 했을 때도 위 과정이 일어남.

DNS 서비스는 백그라운드에서 돌아감.

메모리에 다 올려놓고 서비스하지 않고 순차적으로 동작
- 루트 힌트를 로드
- 파일에 저장된 영역 로드
- 등등

SRV 레코드를 사용하면 DNS 클라이언트에서 TCP/IP 기반 서비스를 찾을 수 있다.

SRV 레코드를 %system32%\config\netlogon.dns를 확인한다.

DC 위치 찾기

DC가 어딘지 알아야 하므로 DNS에 먼저 물어봄
여러 레코드로 응답
LDAP으로 DC1에 접촉
DC1이 NYC 사이트를 반환(가장 가까운 사이트로 알려줌)
NYC 사이트의 DC에 대한 DNS를 쿼리

1~3까지는 로컬 DNS와 의사소통

4~5는 DC1과 의사소통

Root Hints

조건부 전달자(Conditional Forwarder)

예를 들어 contoso.com 인데 adatum.com으로 들어오는 쿼리는 이쪽으로 보내~ 할 수 있음. 명시적으로.
파트너쉽의 회사들 간에 쿼리할 때
- 서로 전달되는 통신을 보안성 있게 전달하고 싶을 때

스텁 영역

각 도메인의 네임 서버가 많으면 네임 서버를 찾아가는 경로도 길어질 가능성 있음
- 네임 서버를 구조화해 놓으면 찾아가는 경로가 합리적으로 된다. 그때 쓰는 영역이 스텁 영역임.

부실 리소스 레코드 청소

자동 청소 구성 가능

캐시 관리도 가능

Cached Lookups는 View -> Advanced를 선택하면 Domain에서 Clear Cache 가능
업무 시간에는 에이징이나 캐시 삭제는 하지 않는 것이 좋다.

DNS 속성에서 이벤트 로깅에서 어떤 것을 기록할지 볼 수 있음.

디버그 로깅은 문제 상황에서 써보고 꺼야 함
- 처리가 많이 일어나기 때문에 정상 상태에서 꺼야 함

dcdiag.exe

폭넓고 다양한 테스트를 수행해 AD DS와 DNS가 잘 동작하는지 확인 가능

네트워크 모니터라고 하는 MS의 툴이 있음.

추천
http://blogs.technet.com/b/netmon/

클라이언트는 ipconfig / nslookup 사용

DNS이름 확인자 캐시
ipconfig
- /displaydns
- /flushdns
- /registerdns

TTL값이 덮어씌어지는 경우 방지(해킹 방지)

DNS 캐시 잠금

DNS 포트가 알려지면 안좋을 때 소켓 풀을 만들어 놓고 임의 포트로 만들 수 있음

사이트 이해

AD 개체는 다음을 지원
- 복제
- 서비스 지역화

사이트를 나누겠다고 마음을 먹으면…?

AD에서는 1:1일 수도 있고 아닐 수도 있음
AD에서 이야기하는 사이트와 네트웤에서 이야기하는 사이트가 1:1일 수 있지만 n:n일 수 있음
AD 사이트 안에 네트웤 2개를 묶어서 1개의 사이트로 만들 수 있음
- AD 사이트는 물리 네트웤보다 논리적인 개념임
- 네트웤 2개가 속도가 비슷하면 하나로 볼 수 있음
- 국내에서는 많이 보지 못함
AD 사이트 및 서비스에서 만들 수 있음
- 물론 네트웤 대역이 나누어져 있어야 함.
- 사이트 당 DC가 있어야 함
  - 사용자가 하나의 DC만 바라보면 그쪽으로 트래픽이 몰리게 됨

사이트 생성

AD 사이트 및 서비스
- Default-First-Site-Name
  - 기본 이름은 바구는 것이 좋다.
    - ex) SOIL-Korea-Site
- 사이트 생성
- 서브넷 생성

DC를 위한 SRV레코드

_tcp.contoso.com: 해당 도메인의 모든 도메인 컨트롤러
_tcp.siteName._… : 해당 사이트의

DC 복제 이해

멀티마스터 복제
- 복제하는 이유는
  - 정확성(무결성)
  - 일관성(일치성)
  - 성능(복제 트래픽이 합리적인 수준을 유지)
AD 복제의 특징
- 멀티마스터 복제
- 끌어오기(pull) 복제
- 저장 후 전달
- 파티션(DB는 내부적으로 파티션이 나누어져 있으니까.)
- 효율적이고 튼튼한 복제 토폴로지의 자동 생성
- 특성 수준 복제
- 사이트 내 및 사이트간 복제의 별도 제어
- 충돌 감지 및 업데이트

사이트간 복제

도메인 컨트롤러로 인바운드 복제
- 최대 3개까지가 효율적이다.
  - 뭐든 홀수가 좋아요. ^^
복제
- Notification
  - 파트너 DC에 변경될 수 있음을 알려줌
    - 15초 단위로
- Polling
  - 도메인 컨트롤러 변경에 대해 자신의 업스트림 파트너에게 조회
    - 1시간 단위
- 복제 에이전트에 의해 일어남
  - 엔지니어가 직접 할 일은 없음
- 시간이 많이 걸린다? 네트워크에 문제가 있을 가능성이 큼

사이트내 토폴로지 생성자(Intersite Topology generator, ISTG)가 사이트간 복제 토폴로지를 만듦

사이트 링크를 이용해 복제 토폴로지를 줄 수 있다.

사이트 포함
항상 적합한 네트워크 토폴로지가 주어지는 것은 아님!

DS-RPC(Directory Service Remote Procedure Call)

AD 사이트 및 서비스에서 IP로 나타남
사이트간 복제에 대한 기본 및 선호 프로토콜
ISM-SMTP 방식도 있지만 거의 DS-RPC로 통신.

브리지 헤드 서버

서로 다른 사이트 2개에서 서로에 대한 복제를 하는 DC를 브리지헤드 서버로 지정한 애들끼리 해서 그것을 가지고 각자의 사이트로 복제

사이트 링크 전이성(기본값)

랜카드에서 전이중, 반이중을 생각
네트워크 성능을 고려하여…
기본값으로 두는 것이 가장 안전

사이트 링크 비용

복제는 더 낮은 비용의 연결을 사용

복제(사이트와 사이트 간 복제에서 일반적인 사이트 1개의 경우가 아님.)

기본값으로 Notifications 오프. 브리지헤드는 파트너에게 알림을 주지 않음
Polling. 다운스트림 브리지헤드는 업스트림 브리지 헤드를 끌어 당김
- 기본: 3시간
- 최소: 15분
- 권장: 15분

**위와 같은 복제를 고민하는 엔지니어는 대단한 위치에 있을 때…

복제 모니터링과 관리

RepAdmin
DCDiag: 도메인 컨트롤러 진단

AD 모니터링

주요 시스템 리소스
- CPU
- Disk
- Memory
- Network
병목
- 현재 사용량이 최대인 시점의 리소스
모니터링을 하는 이유
- 현재를 보지만 미래를 예측하기 위해
- 시스템에 문제가 일어나기 전에 여러 가지 알림을 내보내는데, 관리자들은 차트를 보지 않음
모니터링 도구
- 작업 관리자
- 이벤트 뷰어
- 성능 모니터
- 리소스 모니터
- 신뢰성 모니터

성능 모니터

모든 서버 베이스라인에서 유용한 카운터
- Memory \ Pages/sec
  - 페이징 파일이 왔다갔다 하는 경우: 많으면 느려짐
  - 메모리 부족을 의미
- PhysicalDisk \ Avg. Disk Queue Length
- Processor \ %Processor Time
  - 프로세스 타임이 높다: 70~80%를 치면서 사용자가 원할한 서비스를 못 받는다면 성능에 병목이 있다는 것.
AD 모니터링에 유용한 카운터
- NTDS\ DRA Inbound Bytes Total/sec 등…
- 도움말을 보세요.
- 중요한 것은 베이스라인. 어떤 기준에서 높다 낮다를 판단.
- 새로 시스템을 오픈하면 2,3개월 정도 안정화 기간이 필요한데, 안정적으로 돌아가는 것이 확인된 시점에 이러한 항목들로 데이터를 뽑아야 함.
  - 다리가 부러졌을 때 X-Ray를 찍듯이…
  - 깁스하고 나서 다시 X-Ray를 찍어 원래 있던 것과 겹쳐서 보여줌.
  - 괜찮다는 기준은 이전 데이터를 기준으로 괜찮다고 할 수 있음.
  - 성능이 좋았을 때의 데이터를 갖고 있어야 함.
- 성능 카운터를 뽑는 것도 서버의 오버헤드이다.
  - 예를 들어 사용자가 많이 쓰는 월요일 아침 10~11시 사이 데이터
  - 한달 뒤 월요일 아침 10~11시 데이터
  - 달라졌다면 이유를 판단(서비스가 연동이 많아지거나 사용자가 늘어나는 등)
  - 추세를 확인해서 미리 데이터나 네트웤 속도의 증설 등을 고려
- 익스체인지를 도입한다고 하면
  - MBX 서버의 메모리 사이즈를 … 산정
    - 메일 박스 한개당 ~~ 10MB씩…
    - 헤비하다는 것이 하루에 100통의 메일을 받고 60통을 보내면 헤비유저.
    - 그밑에는 8MB, 6MB…
- 시스템이 안정적으로 동작하는 시점의 기준 데이터가 꼭 필요.
  - 변화가 크면 이벤트 뷰어, 신뢰성 모니터 등을 봐야 함
  - 주기적으로 이것만 잘 해도 시스템을 안정적으로 운영할 수 있음.
  - System Center Operation Manager에서 관리 팩 설치하면 Mail 등으로 Notification을 받을 수 있음.

성능 모니터로 실시간 성능 확인.

Data Collector Sets -> New
- 템플릿이 몇 가지 있음 ! 오…
- 만들어서 Properties 보면 스케줄링도 가능!
- Start -> Stop
볼 때는 Performance Monitor에서 불러오기.

모니터링 모범 사례

일찍부터 베이스라인 만들고 모니터링
- 잘 동작할 때 ^^
- 유휴 시간 vs 바쁜 시간
베이스라인과 비교
장애 전 성능을 모니터링하고 해석하는 방법 숙지
- 데이터 수집기 집합을 구성
- 범인은 증거를 남긴다.
  - 왜 goal이 되고 peak가 되고… 움직였는지?
  - 향후 몇 개월 뒤에 증설해야 하겠다. 이런 판단이 서게 됨.
적절하게 캡처
- 너무 과하게 캡처하지 않음
- 성능 저하됨
- 실제 문제를 식별하기 어려운 ‘잡음’이 생김