ADDS 성능 튜닝의 하드웨어 고려 사항
Important
다음은 Active Directory 도메인 Services용 용량 계획 문서에서 자세히 설명하는 Active Directory 워크로드용 서버 하드웨어를 최적화하기 위한 주요 권장 사항 및 고려 사항에 대한 요약입니다. 독자는 이러한 권장 사항의 기술적 이해와 의미를 높이기 위해 Active Directory 도메인 서비스에 대한 용량 계획을 검토하는 것이 좋습니다.
디스크로 가지 마세요.
Active Directory는 메모리에서 허용하는 만큼 데이터베이스를 캐시합니다. 메모리에서 페이지를 가져오는 것은 미디어가 스핀들인지 SSD 기반인지 여부에 관계없이 실제 미디어로 가는 것보다 훨씬 빠른 순서입니다. 디스크 I/O를 최소화하기 위해 메모리를 더 추가합니다.
Active Directory 모범 사례는 전체 DIT를 메모리에 로드하기에 충분한 RAM을 배치하고 운영 체제 및 바이러스 백신, 백업 소프트웨어, 모니터링 등과 같은 기타 설치된 애플리케이션을 수용하는 것이 좋습니다.
레거시 플랫폼의 제한 사항은 Windows Server 2003 또는 Windows 2000 Server를 실행하는 do기본 컨트롤러에서 Lsass.exe 프로세스의 메모리 사용량을 참조하세요.
메모리\장기 평균 대기 캐시 수명 > 30분 성능 카운터를 사용합니다.
운영 체제, 로그 및 데이터베이스를 별도의 볼륨에 배치합니다. DIT의 전체 또는 대부분을 캐시할 수 있는 경우 캐시가 준비되고 안정적인 상태가 되면 관련성이 낮아지고 스토리지 레이아웃에서 좀 더 유연하게 사용할 수 있습니다. 전체 DIT를 캐시할 수 없는 시나리오에서는 운영 체제, 로그 및 데이터베이스를 별도의 볼륨에서 분할하는 것이 더 중요해집니다.
일반적으로 DIT에 대한 I/O 비율은 약 90%의 읽기 및 10% 쓰기입니다. 쓰기 I/O 볼륨이 10%에서 20%를 크게 초과하는 시나리오는 쓰기가 많은 것으로 간주됩니다. 쓰기가 많은 시나리오는 Active Directory 캐시의 이점을 크게 활용하지 않습니다. 디렉터리에 기록된 데이터의 트랜잭션 내구성을 보장하기 위해 Active Directory는 디스크 쓰기 캐싱을 수행하지 않습니다. 대신, 이 작업을 수행하지 않는 명시적 요청이 없는 한 작업에 대한 성공적인 완료 상태 반환하기 전에 모든 쓰기 작업을 디스크에 커밋합니다. 따라서 빠른 디스크 I/O는 Active Directory에 쓰기 작업의 성능에 중요합니다. 다음은 이러한 시나리오의 성능을 향상시킬 수 있는 하드웨어 권장 사항입니다.
하드웨어 RAID 컨트롤러
DIT 및 로그 파일을 호스트하는 짧은 대기 시간/높은 RPM 디스크 수 늘리기
컨트롤러에서 캐싱 작성
각 볼륨에 대해 디스크 하위 시스템 성능을 개별적으로 검토합니다. 대부분의 Active Directory 시나리오는 주로 읽기 기반이므로 DIT를 호스팅하는 볼륨에 대한 통계를 검사하는 것이 가장 중요합니다. 그러나 운영 체제 및 로그 파일 드라이브를 포함하여 드라이브의 나머지 부분을 모니터링하는 것을 간과하지 마세요. 성능에 대한 병목 현상이 발생하지 않도록 할기본 컨트롤러가 제대로 구성되어 있는지 확인하려면 스토리지 하위 시스템의 섹션에서 표준 스토리지 권장 사항을 참조하세요. 많은 환경에서 이 철학은 부하 급증 또는 급증을 수용할 수 있는 충분한 헤드룸이 있는지 확인하는 것입니다. 이러한 임계값은 부하 급증 또는 급증을 수용하기 위한 헤드룸이 제한되고 클라이언트 응답성이 저하되는 경고 임계값입니다. 즉, 이러한 임계값을 초과하는 것은 단기적으로는 나쁘지 않습니다(하루에 몇 번 5~15분). 그러나 이러한 종류의 통계로 유지되는 시스템은 데이터베이스를 완전히 캐싱하지 않으며 과태료를 부과할 수 있으며 조사해야 합니다.
Database ==> Instances(lsass/NTDSA)\I/O 데이터베이스 읽기 평균 대기 시간 < 15ms
Database ==> Instances(lsass/NTDSA)\I/O Database Reads/sec < 10
Database ==> Instances(lsass/NTDSA)\I/O 로그 쓰기 평균 대기 시간 < 10ms
Database ==> Instances(lsass/NTDSA)\I/O Log Writes/sec – 정보 전용입니다.
데이터의 일관성을 기본 위해 모든 변경 내용을 로그에 기록해야 합니다. 여기에 양호하거나 나쁜 숫자는 없으며 스토리지가 지원하는 양에 대한 측정값일 뿐입니다.
비성수 부하 기간 동안 백업 및 바이러스 백신 검사와 같은 비 코어 디스크 I/O 로드를 계획합니다. 또한 Windows Server 2008에 도입된 우선 순위가 낮은 I/O 기능을 지원하는 백업 및 바이러스 백신 솔루션을 사용하여 Active Directory의 I/O 요구 사항과의 경쟁을 줄입니다.
프로세서에 세금을 부과하지 마세요.
사용 가능한 주기가 충분하지 않은 프로세서는 실행을 위해 스레드를 프로세서로 가져오는 데 긴 대기 시간을 발생시킬 수 있습니다. 여러 환경에서 이러한 시나리오에서 클라이언트 응답성에 미치는 영향을 최소화하기 위해 부하 급증 또는 급증을 수용할 수 있는 충분한 헤드룸이 있는지 확인하는 것이 철학입니다. 요컨대, 아래 임계값을 초과하는 것은 단기적으로 나쁘지 않지만(하루에 몇 번 5~15분) 이러한 종류의 통계를 통해 실행되는 시스템은 비정상적인 부하를 수용할 수 있는 헤드룸을 제공하지 않으며 과도하게 과세된 시나리오에 쉽게 투입될 수 있습니다. 임계값을 초과하는 지속적인 기간을 소비하는 시스템은 프로세서 부하를 줄이는 방법을 조사해야 합니다.
프로세서를 선택하는 방법에 대한 자세한 내용은 서버 하드웨어에 대한 성능 튜닝을 참조하세요.
하드웨어를 추가하거나, 부하를 최적화하고, 클라이언트를 다른 곳으로 보내거나, 환경에서 부하를 제거하여 CPU 부하를 줄입니다.
프로세서 정보(_Total)\% 프로세서 사용률 < 60% 성능 카운터를 사용합니다.
네트워크 어댑터 오버로드 방지
프로세서와 마찬가지로 과도한 네트워크 어댑터 사용률로 인해 아웃바운드 트래픽이 네트워크에 연결될 때까지 긴 대기 시간이 발생합니다. Active Directory는 인바운드 요청이 적고 클라이언트 시스템에 반환되는 데이터의 양이 상당히 많은 경향이 있습니다. 보낸 데이터가 수신된 데이터를 훨씬 초과합니다. 많은 환경에서 이 철학은 부하 급증 또는 급증을 수용할 수 있는 충분한 헤드룸이 있는지 확인하는 것입니다. 이 임계값은 부하 급증 또는 급증을 수용하기 위한 헤드룸이 제한되고 클라이언트 응답성이 저하되는 경고 임계값입니다. 요컨대, 이러한 임계값을 초과하는 것은 단기적으로 나쁘지 않습니다 (하루에 몇 번 5 ~ 15 분), 그러나 이러한 종류의 통계로 지속되는 시스템은 과세되며 조사해야합니다.
네트워크 하위 시스템을 조정하는 방법에 대한 자세한 내용은 네트워크 하위 시스템에 대한 성능 튜닝을 참조 하세요.
NetworkInterface(*)\현재 대역폭 성능 카운터와 NetworkInterface(*)\Bytes Sent/Sec 비교를 사용합니다. 비율은 60% 미만이어야 합니다.