Active Directory 도메인 서비스에 대한 용량 계획

  • 아티클

이 항목은 원래 Microsoft의 프로그램 관리자인 Ken Brumfield가 작성했으며 AD DS(Active Directory 도메인 Services)에 대한 용량 계획에 대한 권장 사항을 제공합니다.

용량 계획의 목표

용량 계획은 성능 인시던트 문제 해결과 동일하지 않습니다. 그들은 밀접하게 관련되어 있지만 매우 다릅니다. 용량 계획의 목표는 다음과 같습니다.

  • 환경 제대로 구현 및 운영
  • 성능 문제를 해결하는 데 소요된 시간을 최소화합니다.

용량 계획에서 조직은 클라이언트 성능 요구 사항을 충족하고 데이터 센터에서 하드웨어를 업그레이드하는 데 필요한 시간을 수용하기 위해 사용량이 많은 기간 동안 40%의 프로세서 사용률 기준 목표를 가질 수 있습니다. 반면 비정상적인 성능 인시던트를 알리기 위해 모니터링 경고 임계값은 5분 간격 동안 90%로 설정될 수 있습니다.

차이점은 용량 관리 임계값을 지속적으로 초과할 때(일회성 이벤트는 문제가 되지 않음), 용량 추가(즉, 더 많거나 빠른 프로세서에 추가)가 솔루션이 되거나 여러 서버에서 서비스 크기를 조정하는 것이 솔루션이라는 점입니다. 성능 경고 임계값은 클라이언트 환경이 현재 어려움을 겪고 있으며 문제를 해결하기 위해 즉각적인 단계가 필요하다는 것을 나타냅니다.

비유: 용량 관리는 교통 사고를 방지하는 것입니다 (방어 운전, 브레이크가 제대로 작동하는지 확인하는 등) 반면 성능 문제 해결은 경찰, 소방서 및 응급 의료 전문가가 사고 후 수행하는 것입니다. 이것은 "방어 운전", Active Directory 스타일에 관한 것입니다.

지난 몇 년 동안 확장 시스템에 대한 용량 계획 지침이 크게 변경되었습니다. 시스템 아키텍처의 다음과 같은 변경으로 서비스 디자인 및 크기 조정에 대한 기본 가정에 문제가 있습니다.

  • 64비트 서버 플랫폼
  • 가상화
  • 전력 소비에 대한 관심 증가
  • SSD 스토리지
  • 클라우드 시나리오

또한 이 접근 방식은 서버 기반 용량 계획 연습에서 서비스 기반 용량 계획 연습으로 전환되고 있습니다. 많은 Microsoft 및 타사 제품이 백 엔드로 사용하는 완성도 높은 분산 서비스인 AD DS(Active Directory 도메인 Services)는 다른 애플리케이션을 실행하는 데 필요한 용량을 보장하기 위해 올바르게 계획하는 가장 중요한 제품 중 하나가 됩니다.

용량 계획 지침에 대한 기준 요구 사항

이 문서 전체에서 다음과 같은 기준 요구 사항이 필요합니다.

  • 독자는 Windows Server 2012 R2에 대한 성능 튜닝 지침을 읽고 잘 알고 있습니다.
  • Windows Server 플랫폼은 x64 기반 아키텍처입니다. 그러나 Active Directory 환경이 Windows Server 2003 x86(지원 수명 주기 종료 이후)에 설치되어 있고 크기가 1.5GB 미만이고 메모리에 쉽게 보관할 수 있는 DIT(디렉터리 정보 트리)가 있더라도 이 문서의 지침은 여전히 적용됩니다.
  • 용량 계획은 지속적인 프로세스이며 환경이 기대치를 얼마나 잘 충족하는지 정기적으로 검토해야 합니다.
  • 하드웨어 비용이 변경되면 여러 하드웨어 수명 주기 동안 최적화가 수행됩니다. 예를 들어 메모리가 저렴해지거나, 코어당 비용이 감소하거나, 다른 스토리지 옵션의 가격이 변경됩니다.
  • 하루의 피크 바쁜 기간에 대한 계획. 이를 30분 또는 시간 간격으로 살펴보는 것이 좋습니다. 더 큰 것은 실제 피크를 숨길 수 있으며 더 적은 것은 "일시적인 스파이크"에 의해 왜곡 될 수 있습니다.
  • 엔터프라이즈의 하드웨어 수명 주기 동안 성장을 계획합니다. 여기에는 스테이거 방식으로 하드웨어를 업그레이드하거나 추가하는 전략 또는 3~5년마다 완전한 새로 고침이 포함될 수 있습니다. 각각에는 Active Directory의 부하가 증가할 만큼 "추측"이 필요합니다. 기록 데이터가 수집되면 이 평가에 도움이 됩니다.
  • 내결함성을 계획합니다. 예측 N이 파생되면 N - 1, N – 2 , N – x를 포함하는 시나리오를 계획합니다.

    • 단일 또는 여러 서버의 손실이 최대 최대 용량 예상을 초과하지 않도록 조직의 필요에 따라 추가 서버를 추가합니다.

    • 또한 성장 계획 및 내결함성 계획을 통합해야 합니다. 예를 들어, 부하를 지원하기 위해 하나의 DC가 필요하지만 다음 해에 부하가 두 배로 늘어나고 총 2대의 DC가 필요한 경우 내결함성을 지원하기에 충분한 용량이 없습니다. 해결 방법은 세 개의 DC로 시작하는 것입니다. 예산이 부족한 경우 3개월 또는 6개월 후에 세 번째 DC를 추가할 계획일 수도 있습니다.

      참고 항목

      Active Directory 인식 애플리케이션을 추가하면 애플리케이션 서버 또는 클라이언트에서 부하가 들어오는지 여부에 관계없이 DC 부하에 눈에 띄는 영향을 미칠 수 있습니다.

용량 계획 주기를 위한 3단계 프로세스

용량 계획에서 먼저 필요한 서비스 품질을 결정합니다. 예를 들어 핵심 데이터 센터는 더 높은 수준의 동시성을 지원하며 사용자 및 애플리케이션을 사용하는 데 보다 일관된 환경이 필요하며, 이를 위해서는 중복성에 더 많은 주의를 기울이고 시스템 및 인프라 병목 상태를 최소화해야 합니다. 반면, 소수의 사용자가 있는 위성 위치는 동일한 수준의 동시성 또는 내결함성을 필요로 하지 않습니다. 따라서 위성 사무소는 기본 하드웨어 및 인프라를 최적화하는 데 별로 주의를 기울이지 않아도 되므로 비용을 절감할 수 있습니다. 여기에 있는 모든 권장 사항 및 지침은 최적의 성능을 위한 것이며 덜 까다로운 요구 사항이 있는 시나리오에 대해 선택적으로 완화할 수 있습니다.

다음 질문은 가상화 또는 물리적인가요? 용량 계획 관점에서 볼 때 옳고 그른 대답은 없습니다. 사용할 변수 집합이 다릅니다. 가상화 시나리오는 다음 두 가지 옵션 중 하나로 내려옵니다.

  • 호스트당 하나의 게스트가 있는 "직접 매핑"(가상화는 서버에서 물리적 하드웨어를 추상화하기 위해서만 존재)
  • "공유 호스트"

테스트 및 프로덕션 시나리오는 "직접 매핑" 시나리오를 실제 호스트와 동일하게 처리할 수 있음을 나타냅니다. 그러나 "공유 호스트"는 나중에 더 자세히 설명된 여러 가지 고려 사항을 소개합니다. "공유 호스트" 시나리오는 AD DS도 리소스를 위해 경쟁하고 있으며 이에 대한 처벌 및 튜닝 고려 사항이 있음을 의미합니다.

이러한 고려 사항을 염두에 두고 용량 계획 주기는 반복적인 3단계 프로세스입니다.

  1. 기존 환경을 측정하고, 시스템 병목 현상이 현재 있는 위치를 확인하고, 필요한 용량의 양을 계획하는 데 필요한 환경 기본 사항을 가져옵니다.
  2. 1단계에 설명된 기준에 따라 필요한 하드웨어를 결정합니다.
  3. 구현된 인프라가 사양 내에서 작동하고 있는지 모니터링하고 유효성을 검사합니다. 이 단계에서 수집된 일부 데이터는 용량 계획의 다음 주기에 대한 기준이 됩니다.

프로세스 적용

성능을 최적화하려면 이러한 주요 구성 요소가 올바르게 선택되고 애플리케이션 로드에 맞게 조정되었는지 확인합니다.

  1. 메모리
  2. 네트워크
  3. 스토리지
  4. 프로세서
  5. Net Logon

AD DS의 기본 스토리지 요구 사항 및 잘 작성된 클라이언트 소프트웨어의 일반적인 동작을 통해 10,000~20,000명의 사용자가 있는 환경에서는 거의 모든 최신 서버 클래스 시스템에서 부하를 처리하므로 실제 하드웨어와 관련하여 용량 계획에 대한 막대한 투자를 포기할 수 있습니다. 즉, 다음 표에는 올바른 하드웨어를 선택하기 위해 기존 환경을 평가하는 방법이 요약되어 있습니다. 각 구성 요소는 AD DS 관리자가 기준 권장 사항 및 환경별 보안 주체를 사용하여 인프라를 평가하는 데 도움이 되도록 후속 섹션에서 자세히 분석됩니다.

일반적으로 다음과 같이 작동합니다.

  • 현재 데이터를 기반으로 하는 모든 크기 조정은 현재 환경에 대해서만 정확합니다.
  • 예상의 경우 하드웨어의 수명 주기 동안 수요가 증가할 것으로 예상합니다.
  • 현재 대규모로 확장하여 더 큰 환경으로 확장할지, 아니면 수명 주기 동안 용량을 추가할지 결정합니다.
  • 가상화의 경우 가상화의 오버헤드를 관련된 모든 작업에 추가해야 한다는 점을 제외하고 모든 동일한 용량 계획 주체 및 방법론이 적용됩니다기본.
  • 예측하려는 모든 것과 마찬가지로 용량 계획은 정확한 과학이 아닙니다. 100% 정확도로 완벽하게 계산할 필요는 없습니다. 여기에 있는 지침은 가장 간결한 권장 사항입니다. 추가 안전을 위해 용량을 추가하고 환경이 대상에서 다시 기본 지속적으로 유효성을 검사합니다.

데이터 컬렉션 요약 테이블

새 환경

구성 요소 추정
스토리지/데이터베이스 크기 각 사용자에 대해 40KB~60KB
RAM 데이터베이스 크기
기본 운영 체제 권장 사항
제3자 애플리케이션
네트워크 1GB
CPU 각 코어에 대해 1000명의 동시 사용자

상위 수준 평가 조건

구성 요소 평가 조건 계획 고려 사항
스토리지/데이터베이스 크기 스토리지 제한에서 "조각 모음으로 해제된 디스크 공간의 로깅을 활성화하려면" 섹션
스토리지/데이터베이스 성능
  • "LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read", "LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Write", "LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Transfer"
  • "LogicalDisk(<NTDS 데이터베이스 드라이브>)\Reads/sec", "LogicalDisk(<NTDS 데이터베이스 드라이브>)\Writes/sec", "LogicalDisk(<NTDS 데이터베이스 드라이브>)\Transfers/sec"
  • 스토리지에는 해결해야 할 두 가지 문제가 있습니다.
    • 사용 가능한 공간으로, 오늘날의 스핀들 기반 및 SSD 기반 스토리지 크기는 대부분의 AD 환경에서는 관련이 없습니다.
    • IO(입력/출력) 작업 사용 가능 – 많은 환경에서는 종종 간과됩니다. 그러나 전체 NTDS 데이터베이스를 메모리에 로드하기에 RAM이 충분하지 않은 환경만 평가하는 것이 중요합니다.
  • 스토리지는 복잡한 항목일 수 있으며 적절한 크기 조정을 위한 하드웨어 공급업체 전문 지식을 포함해야 합니다. 특히 SAN, NAS 및 iSCSI 시나리오와 같은 더 복잡한 시나리오를 사용합니다. 그러나 일반적으로 스토리지의 기가바이트당 비용은 IO당 비용에 직접적인 반대가 되는 경우가 많습니다.
    • RAID 5는 Raid 1보다 기가바이트당 비용이 낮지만, Raid 1은 IO당 비용이 낮습니다.
    • 스핀들 기반 하드 드라이브는 기가바이트당 비용이 낮지만 SSD는 IO당 비용이 더 낮습니다.
  • 컴퓨터 또는 Active Directory 도메인 Services 서비스를 다시 시작하면 ESE(Extensible Storage Engine) 캐시가 비어 있고 캐시가 따뜻해지면 성능이 디스크에 바인딩됩니다.
  • 대부분의 환경에서 AD는 디스크에 대한 임의 패턴으로 읽기 집약적 I/O이며 캐싱 및 읽기 최적화 전략의 이점을 대부분 부정합니다. 또한 AD는 대부분의 스토리지 시스템 캐시보다 메모리의 캐시가 훨씬 더 큽니다.
RAM
  • 데이터베이스 크기
  • 기본 운영 체제 권장 사항
  • 제3자 애플리케이션
  • 스토리지는 컴퓨터에서 가장 느린 구성 요소입니다. RAM에 더 많이 상주할수록 디스크로 이동하는 데 필요한 필요가 줄어듭니다.
  • 운영 체제, 에이전트(바이러스 백신, 백업, 모니터링), NTDS 데이터베이스 및 시간에 따른 성장을 저장하기 위해 충분한 RAM이 할당되었는지 확인합니다.
  • RAM의 양을 최대화하는 것이 비용 효율적이지 않거나(예: 위성 위치) 가능하지 않거나(DIT가 너무 큰) 환경의 경우 스토리지 섹션을 참조하여 스토리지 크기가 제대로 조정되었는지 확인합니다.
네트워크
  • "Network Interface(*)\Bytes Received/sec"
  • "Network Interface(*)\Bytes Sent/sec"
  • 일반적으로 DC에서 보낸 트래픽은 DC로 전송되는 트래픽을 훨씬 초과합니다.
  • 전환된 이더넷 연결이 전체 이중이므로 인바운드 및 아웃바운드 네트워크 트래픽의 크기를 독립적으로 조정해야 합니다.
  • DC 수를 통합하면 각 DC에 대한 클라이언트 요청에 응답을 다시 보내는 데 사용되는 대역폭의 양이 증가하지만 사이트 전체에 대해 선형으로 충분히 가깝습니다.
  • 위성 위치 DC를 제거하는 경우 위성 DC의 대역폭을 허브 DC에 추가하고 이를 사용하여 WAN 트래픽의 양을 평가하는 것을 잊지 마세요.
CPU
  • "논리 디스크(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read"
  • "Process(lsass)\% Processor Time"
  • 스토리지를 병목 현상으로 제거한 후 필요한 컴퓨팅 능력의 양을 해결합니다.
  • 완벽하게 선형은 아니지만 특정 범위(예: 사이트) 내의 모든 서버에서 사용되는 프로세서 코어 수를 사용하여 총 클라이언트 부하를 지원하는 데 필요한 프로세서 수를 측정할 수 있습니다. 범위 내의 모든 시스템에서 현재 서비스 수준을 기본 데 필요한 최소값을 추가합니다.
  • 전원 관리 관련 변경 내용을 포함하여 프로세서 속도의 변경은 현재 환경에서 파생된 숫자에 영향을 줍니다. 일반적으로 2.5GHz 프로세서에서 3GHz 프로세서로 이동하여 필요한 CPU 수를 줄이는 방법을 정확하게 평가하는 것은 불가능합니다.
NetLogon
  • "Netlogon()\Semaphore Acquires"
  • "Netlogon()\Semaphore Timeouts"
  • "Netlogon(*)\Average Semaphore Hold Time"
  • Net Logon Secure Channel/MaxConcurrentAPI는 NTLM 인증 및/또는 PAC 유효성 검사를 사용하는 환경에만 영향을 줍니다. PAC 유효성 검사는 Windows Server 2008 이전의 운영 체제 버전에서 기본적으로 설정됩니다. 클라이언트 설정이므로 모든 클라이언트 시스템에서 이 설정이 해제될 때까지 DC가 영향을 받게 됩니다.
  • 포리스트 내 트러스트를 포함하는 중요한 교차 신뢰 인증이 있는 환경은 제대로 크기가 조정되지 않으면 더 큰 위험을 초래합니다.
  • 서버 통합은 상호 신뢰 인증의 동시성을 높입니다.
  • 사용자가 새 클러스터 노드에 대해 한꺼번에 다시 인증하기 때문에 클러스터 장애 조치(failover)와 같은 서지를 수용해야 합니다.
  • 개별 클라이언트 시스템(예: 클러스터)도 튜닝해야 할 수 있습니다.

계획

오랫동안 커뮤니티의 AD DS 크기 조정 권장 사항은 "데이터베이스 크기만큼 RAM을 넣는 것"이었습니다. 대부분의 경우 이러한 권장 사항은 대부분의 환경에서 고려해야 할 사항입니다. 그러나 AD DS를 사용하는 에코시스템은 1999년에 도입된 이래로 AD DS 환경 자체와 마찬가지로 훨씬 더 커졌습니다. 컴퓨팅 성능의 증가와 x86 아키텍처에서 x64 아키텍처로의 전환으로 인해 물리적 하드웨어에서 AD DS를 실행하는 더 큰 고객 집합과 성능 크기 조정의 미묘한 측면이 없어졌지만, 가상화의 증가로 인해 이전보다 많은 대상에게 튜닝 문제가 다시 도입되었습니다.

따라서 다음 지침은 Active Directory가 물리적, 가상/물리적 조합 또는 순수하게 가상화된 시나리오에 배포되었는지 여부에 관계없이 서비스로 Active Directory의 요구를 결정하고 계획하는 방법에 대한 것입니다. 따라서 스토리지, 메모리, 네트워크 및 프로세서의 네 가지 기본 구성 요소 각각에 대한 평가를 세분화합니다. 요컨대, AD DS의 성능을 최대화하기 위해 목표는 프로세서에 최대한 가깝게 바인딩되는 것입니다.

RAM

간단히 말해서 RAM에 캐시할 수 있는 값이 많을수록 디스크로 이동하는 데 필요한 필요가 줄어듭니다. 서버의 확장성을 최대화하려면 RAM의 최소 크기는 현재 데이터베이스 크기, 총 SYSVOL 크기, 운영 체제 권장 금액 및 에이전트에 대한 공급업체 권장 사항(바이러스 백신, 모니터링, 백업 등)의 합계여야 합니다. 서버 수명 동안 증가에 맞게 추가 금액을 추가해야 합니다. 이는 환경 변화에 따른 데이터베이스 증가 추정치에 따라 환경적으로 주관적입니다.

RAM의 양을 최대화하는 것이 비용 효율적이지 않거나(예: 위성 위치) 가능하지 않거나(DIT가 너무 큰) 환경의 경우 스토리지 섹션을 참조하여 스토리지가 제대로 설계되었는지 확인합니다.

메모리 크기 조정의 일반적인 컨텍스트에서 나오는 공동은 페이지 파일의 크기 조정입니다. 관련된 다른 모든 메모리와 동일한 컨텍스트에서 목표는 훨씬 더 느린 디스크로 가는 것을 최소화하는 것입니다. 따라서 질문은 "페이지 파일의 크기를 어떻게 조정해야 하나요?" "페이징을 최소화하기 위해 얼마나 많은 RAM이 필요한가요?" 후자의 질문에 대한 답변은 이 섹션의 나머지 부분에 설명되어 있습니다. 이렇게 하면 페이지 파일의 크기를 일반 운영 체제 권장 사항의 영역으로 조정하고 AD DS 성능과 관련이 없는 메모리 덤프에 대한 시스템을 구성해야 한다는 논의가 대부분 남습니다.

Evaluating

DC(do기본 컨트롤러)에 필요한 RAM 양은 실제로 다음과 같은 이유로 복잡한 연습입니다.

  • 기존 시스템을 사용하여 LSASS가 메모리 압력 조건에서 트리밍할 때 필요한 RAM의 양을 측정하려고 할 때 오류가 발생할 가능성이 높아 인위적으로 필요를 줄입니다.
  • 개별 DC가 클라이언트에 "흥미로운" 항목만 캐시해야 한다는 주관적인 사실입니다. 즉, Exchange 서버만 있는 사이트의 DC에 캐시해야 하는 데이터는 사용자만 인증하는 DC에서 캐시해야 하는 데이터와 매우 다릅니다.
  • 사례별로 각 DC에 대한 RAM을 평가하는 데 소요되는 작업과 환경이 변경됨에 따라 변경됩니다.
  • 권장 사항의 기준은 정보에 입각한 결정을 내리는 데 도움이 됩니다.
  • RAM에서 캐시할 수 있는 값이 많을수록 디스크로 이동하는 데 필요한 필요가 줄어듭니다.
  • 스토리지는 컴퓨터에서 가장 느린 구성 요소입니다. 스핀들 기반 및 SSD 스토리지 미디어의 데이터에 대한 액세스는 RAM의 데이터에 대한 액세스보다 1,000,000배 느립니다.

따라서 서버의 확장성을 최대화하기 위해 RAM의 최소 크기는 현재 데이터베이스 크기, 총 SYSVOL 크기, 운영 체제 권장 금액 및 에이전트에 대한 공급업체 권장 사항(바이러스 백신, 모니터링, 백업 등)의 합계입니다. 서버 수명 동안 증가에 맞게 추가 금액을 추가합니다. 이는 데이터베이스 증가 예측에 따라 환경적으로 주관적입니다. 그러나 최종 사용자 집합이 작은 위성 위치의 경우 이러한 사이트는 대부분의 요청을 처리하는 데 캐시할 필요가 없으므로 이러한 요구 사항을 완화할 수 있습니다.

RAM의 양을 최대화하는 것이 비용 효율적이지 않거나(예: 위성 위치) 가능하지 않거나(DIT가 너무 큰) 환경의 경우 스토리지 섹션을 참조하여 스토리지 크기가 제대로 조정되었는지 확인합니다.

참고 항목

메모리 크기를 조정하는 동안 페이지 파일의 크기가 조정되는 동안의 순서입니다. 목표는 훨씬 느린 디스크로 가는 것을 최소화하는 것이기 때문에 질문은 "페이지 파일의 크기를 어떻게 조정해야 하나요?"에서 비롯됩니다. "페이징을 최소화하기 위해 얼마나 많은 RAM이 필요한가요?" 후자의 질문에 대한 답변은 이 섹션의 나머지 부분에 설명되어 있습니다. 이렇게 하면 페이지 파일의 크기를 일반 운영 체제 권장 사항의 영역으로 조정하고 AD DS 성능과 관련이 없는 메모리 덤프에 대한 시스템을 구성해야 한다는 논의가 대부분 남습니다.

RAM에 대한 가상화 고려 사항

호스트에서 메모리 오버 커밋을 방지합니다. RAM 양을 최적화하는 기본 목표는 디스크에 소요되는 시간을 최소화하는 것입니다. 가상화 시나리오에서 메모리 오버 커밋의 개념은 게스트에 더 많은 RAM이 할당된 다음 실제 머신에 존재하는 곳에 존재합니다. 이것은 그 자체로 문제가되지 않습니다. 모든 게스트가 적극적으로 사용하는 총 메모리가 호스트의 RAM 양을 초과하고 기본 호스트가 페이징을 시작하면 문제가 됩니다. do기본 컨트롤러가 데이터를 가져오기 위해 NTDS.dit로 이동하거나, do기본 컨트롤러가 데이터를 가져오기 위해 페이지 파일로 이동하거나 호스트가 디스크로 이동하여 게스트가 RAM에 있다고 생각하는 데이터를 가져오는 경우 성능이 디스크에 바인딩됩니다.

계산 요약 예제

구성 요소 예상 메모리(예)
기본 운영 체제 권장 RAM(Windows Server 2008) 2GB
LSASS 내부 작업 200MB
모니터링 에이전트 100MB
바이러스 백신 100MB
데이터베이스(글로벌 카탈로그) 8.5GB
백업 실행을 위한 쿠션, 관리자가 영향 없이 로그온 1GB
합계 12GB

권장: 16GB

시간이 지남에 따라 데이터베이스에 더 많은 데이터가 추가되고 서버가 3~5년 동안 프로덕션 환경에 있을 것이라고 가정할 수 있습니다. 33%의 예상 성장률에 따라 16GB는 실제 서버에 배치할 적절한 양의 RAM이 될 것입니다. 가상 머신에서 설정을 수정할 수 있고 RAM을 VM에 추가할 수 있는 용이성을 감안할 때 향후 모니터링 및 업그레이드 계획으로 12GB부터 시작하는 것이 합리적입니다.

네트워크

Evaluating

이 섹션에서는 WAN을 통과하는 트래픽에 중점을 두고 Active Directory 복제 트래픽에서 자세히 다루는 복제본(replica) 트래픽에 대한 요구 사항을 평가하는 것이 클라이언트 쿼리, 그룹 정책 애플리케이션 등을 포함하는 필요한 총 대역폭 및 네트워크 용량을 평가하는 것보다 적습니다. 기존 환경의 경우 성능 카운터 "네트워크 인터페이스(*)\Bytes Received/sec" 및 "Network Interface(*)\Bytes Sent/sec"를 사용하여 수집할 수 있습니다. 15분, 30분 또는 60분 내의 네트워크 인터페이스 카운터에 대한 샘플 간격입니다. 더 적은 것은 일반적으로 좋은 측정을 위해 너무 휘발성이 될 것입니다; 더 큰 것은 매일 피킹을 과도하게 부드럽게 합니다.

참고 항목

일반적으로 DC에서 대부분의 네트워크 트래픽은 DC가 클라이언트 쿼리에 응답할 때 아웃바운드입니다. 이는 아웃바운드 트래픽에 중점을 두는 이유이지만 인바운드 트래픽에 대한 각 환경도 평가하는 것이 좋습니다. 동일한 방법을 사용하여 인바운드 네트워크 트래픽 요구 사항을 해결하고 검토할 수 있습니다. 자세한 내용은 기술 자료 문서 929851 참조하세요. TCP/IP의 기본 동적 포트 범위가 Windows Vista 및 Windows Server 2008에서 변경되었습니다.

대역폭 요구 사항

네트워크 확장성에 대한 계획은 트래픽 양과 네트워크 트래픽의 CPU 부하라는 두 가지 범주를 다룹니다. 이러한 각 시나리오는 이 문서의 다른 일부 항목과 비교하여 바로 진행됩니다.

지원되어야 하는 트래픽의 양을 평가할 때 네트워크 트래픽 측면에서 AD DS에 대한 용량 계획의 두 가지 고유한 범주가 있습니다. 첫 번째는 do기본 컨트롤러 간을 트래버스하는 복제본(replica) 트래픽이며 참조 Active Directory 복제 트래픽에서 철저히 다루며 여전히 현재 버전의 AD DS와 관련이 있습니다. 두 번째는 사이트 내 클라이언트-서버 트래픽입니다. 계획할 간단한 시나리오 중 하나인 사이트 내 트래픽은 주로 클라이언트로 다시 전송되는 많은 양의 데이터를 기준으로 클라이언트로부터 작은 요청을 받습니다. 100MB는 일반적으로 사이트의 서버당 최대 5,000명의 사용자 환경에서 적합합니다. 5,000명 이상의 사용자에게는 1GB 네트워크 어댑터 및 RSS(수신측 크기 조정) 지원을 사용하는 것이 좋습니다. 특히 서버 통합 시나리오의 경우 이 시나리오의 유효성을 검사하려면 사이트의 모든 DC에서 네트워크 인터페이스(*)\Bytes/sec를 살펴보고, 함께 추가하고, 대상 do기본 컨트롤러 수로 나누어 적절한 용량이 있는지 확인합니다. 이 작업을 수행하는 가장 쉬운 방법은 Windows 안정성 및 성능 모니터(이전의 Perfmon이라고 함)에서 "누적 영역" 보기를 사용하여 모든 카운터의 크기를 동일하게 조정하는 것입니다.

다음 예제(일반 규칙이 특정 환경에 적용 가능한지 확인하는 정말 복잡한 방법이라고도 함)를 고려합니다. 다음과 같은 가정이 수행됩니다.

  • 목표는 사용 공간을 가능한 한 적은 수의 서버로 줄이는 것입니다. 이상적으로는 한 서버가 부하를 전달하고 중복성을 위해 추가 서버가 배포됩니다(N + 1 시나리오).
  • 이 시나리오에서 현재 네트워크 어댑터는 100MB만 지원하며 전환된 환경에 있습니다. N 시나리오에서 최대 대상 네트워크 대역폭 사용률은 60%입니다(DC 손실).
  • 각 서버에는 약 10,000개의 클라이언트가 연결되어 있습니다.

차트의 데이터에서 얻은 지식(Network Interface(*)\Bytes Sent/sec):

  1. 영업일은 5시 30분경부터 시작되어 오후 7시 00분에 바람이 불기 시작합니다.
  2. 가장 바쁜 피크 기간은 오전 8시에서 오전 8시 15분까지이며, 가장 바쁜 DC에서는 25바이트보다 큽니다.

    참고 항목

    모든 성능 데이터는 기록입니다. 따라서 8:15의 최고 데이터 포인트는 8:00에서 8:15까지의 부하를 나타냅니다.

  3. 오전 4시 이전의 급증이 있으며, 가장 바쁜 DC에서 20바이트 이상이 전송되며, 이는 다른 표준 시간대의 부하 또는 백업과 같은 백그라운드 인프라 활동을 나타낼 수 있습니다. 오전 8시 피크가 이 활동을 초과하므로 관련이 없습니다.
  4. 사이트에는 5개의 Do기본 컨트롤러가 있습니다.
  5. 최대 로드는 DC당 약 5.5MB/s이며, 이는 100MB 연결의 44%를 나타냅니다. 이 데이터를 사용하면 오전 8시에서 오전 8시 15분 사이에 필요한 총 대역폭이 28MB/초인 것으로 추정할 수 있습니다.

    참고 항목

    네트워크 인터페이스 전송/수신 카운터는 바이트 단위이고 네트워크 대역폭은 비트 단위로 측정됩니다. 100MB ÷ 8 = 12.5MB, 1GB ÷ 8 = 128MB.

결론:

  1. 이 현재 환경은 60% 대상 사용률에서 N+1 수준의 내결함성을 충족합니다. 한 시스템을 오프라인으로 전환하면 서버당 대역폭이 약 5.5MB/s(44%)에서 약 7MB/s(56%)로 이동합니다.
  2. 이전에 설명한 한 서버에 통합하는 목표에 따라 이 두 가지 모두 최대 대상 사용률과 이론적으로 100MB 연결의 사용률을 초과합니다.
  3. 1GB 연결을 사용하면 전체 용량의 22%를 나타냅니다.
  4. N + 1 시나리오의 정상적인 작동 조건에서 클라이언트 로드는 서버당 약 14MB/s 또는 총 용량의 11%로 비교적 균등하게 분산됩니다.
  5. DC를 사용할 수 없는 동안 용량이 적절한지 확인하기 위해 서버당 정상 작동 대상은 네트워크 사용률의 약 30% 또는 서버당 38MB/s입니다. 장애 조치 대상은 네트워크 사용률 60% 또는 서버당 72MB/s입니다.

즉, 시스템의 최종 배포에는 1GB 네트워크 어댑터가 있어야 하며 해당 부하를 지원하는 네트워크 인프라에 연결되어야 합니다. 또한 생성된 네트워크 트래픽의 양을 감안할 때 네트워크 통신의 CPU 부하가 상당한 영향을 미칠 수 있으며 AD DS의 최대 확장성을 제한할 수 있습니다. 이 동일한 프로세스를 사용하여 DC에 대한 인바운드 통신의 양을 예측할 수 있습니다. 그러나 인바운드 트래픽을 기준으로 아웃바운드 트래픽이 우세하다는 점을 감안할 때 대부분의 환경에 대한 교육 연습입니다. 서버당 사용자가 5,000명 이상인 환경에서는 RSS에 대한 하드웨어 지원을 보장하는 것이 중요합니다. 네트워크 트래픽이 많은 시나리오의 경우 인터럽트 부하의 분산은 병목 현상일 수 있습니다. CPU 간에 고르지 않게 분산되는 프로세서(*)% 인터럽트 시간에서 이를 감지할 수 있습니다. RSS 사용 NIC는 이러한 제한을 완화하고 확장성을 높일 수 있습니다.

참고 항목

유사한 접근 방식을 사용하여 데이터 센터를 통합하거나 위성 위치에서 할 일기본 컨트롤러를 사용 중지할 때 필요한 추가 용량을 예측할 수 있습니다. 클라이언트에 대한 아웃바운드 및 인바운드 트래픽을 수집하기만 하면 WAN 링크에 표시되는 트래픽의 양이 됩니다.

경우에 따라 인증서 검사 WAN에서 공격적인 시간 초과를 충족하지 못하는 경우와 같이 트래픽이 느리기 때문에 예상보다 많은 트래픽이 발생할 수 있습니다. 이러한 이유로 WAN 크기 조정 및 사용률은 반복적이고 지속적인 프로세스여야 합니다.

네트워크 대역폭에 대한 가상화 고려 사항

5,000명 이상의 사용자를 지원하는 서버에 대해 1GB의 물리적 서버에 대한 권장 사항을 쉽게 만들 수 있습니다. 여러 게스트가 기본 가상 스위치 인프라를 공유하기 시작하면 호스트가 시스템의 모든 게스트를 지원하기에 적절한 네트워크 대역폭을 가지므로 추가적인 엄격함이 필요한지 확인해야 합니다. 이는 네트워크 인프라를 호스트 머신으로 보장하는 확장에 지나지 않습니다. 이는 네트워크 트래픽이 가상 스위치를 통해 진행되는 호스트에서 가상 머신 게스트로 실행되는 do기본 컨트롤러를 포함할지 또는 실제 스위치에 직접 연결되었는지 여부에 관계없이 달라집니다. 가상 스위치는 업링크가 전송되는 데이터의 양을 지원해야 하는 하나 이상의 구성 요소입니다. 따라서 스위치에 연결된 실제 호스트 물리적 네트워크 어댑터는 DC 로드와 실제 네트워크 어댑터에 연결된 가상 스위치를 공유하는 다른 모든 게스트를 지원할 수 있어야 합니다.

계산 요약 예제

System 최대 대역폭
DC 1 6.5MB/s
DC 2 6.25MB/s
DC 3 6.25MB/s
DC 4 5.75MB/s
DC 5 4.75MB/s
합계 28.5MB/s

권장: 72MB/s (28.5MB/s를 40%로 나눈 값)

대상 시스템 수 총 대역폭(위부터)
2 28.5MB/s
정상적인 동작의 결과 28.5 ÷ 2 = 14.25MB/s

언제나처럼 시간이 지남에 따라 클라이언트 부하가 증가하고 이 증가가 가능한 한 최선을 다해 계획되어야 한다고 가정할 수 있습니다. 계획할 권장 금액은 네트워크 트래픽의 예상 증가율을 50%로 허용합니다.

스토리지

스토리지 계획은 다음 두 가지 구성 요소를 구성합니다.

  • 용량 또는 스토리지 크기
  • 성능

용량을 계획하는 데 많은 시간과 설명서가 소요되므로 성능이 완전히 간과되는 경우가 많습니다. 현재 하드웨어 비용으로, 대부분의 환경은 이들 중 하나가 실제로 문제가 될 만큼 충분히 크지 않으며, "데이터베이스 크기만큼 RAM을 넣는 것"에 대한 권장 사항은 일반적으로 나머지를 포함하지만, 더 큰 환경에서 위성 위치에 대한 과잉이 될 수 있습니다.

크기 조정

스토리지 평가

Active Directory가 도입된 13년 전과 비교했을 때, 4GB 및 9GB 드라이브가 가장 일반적인 드라이브 크기였던 시간에 비해 Active Directory의 크기 조정은 가장 큰 환경을 제외한 모든 환경에 대한 고려 사항도 아닙니다. 180GB 범위에서 사용 가능한 가장 작은 하드 드라이브 크기를 사용하면 전체 운영 체제, SYSVOL 및 NTDS.dit가 하나의 드라이브에 쉽게 맞을 수 있습니다. 따라서 이 영역에 대한 막대한 투자를 중단하는 것이 좋습니다.

고려해야 할 유일한 권장 사항은 조각 모음을 사용하도록 설정하기 위해 NTDS.dit 크기의 110%를 사용할 수 있도록 하는 것입니다. 또한 하드웨어의 수명 동안 성장을위한 숙박 시설을 만들어야합니다.

첫 번째이자 가장 중요한 고려 사항은 NTDS.dit 및 SYSVOL이 얼마나 큰지 평가하는 것입니다. 이러한 측정값으로 인해 고정 디스크 및 RAM 할당의 크기가 모두 조정됩니다. 이러한 구성 요소의 (상대적으로) 저렴한 비용으로 인해 수학은 엄격하고 정확할 필요가 없습니다. 기존 환경과 새 환경 모두에 대해 이를 평가하는 방법에 대한 내용은 Data Storage 일련의 문서에서 찾을 수 있습니다. 특히 다음 문서를 참조하세요.

  • 기존 환경의 경우 – 스토리지 제한 문서의 "조각 모음으로 해제된 디스크 공간의 로깅을 활성화하려면" 섹션입니다.

  • 새 환경의 경우 – Active Directory 사용자 및 조직 구성 단위에 대한 증가 예상치라는 제목의 문서입니다.

    참고 항목

    이 문서는 Windows 2000에서 Active Directory가 릴리스될 당시의 데이터 크기 추정치를 기반으로 합니다. 사용자 환경에서 개체의 실제 크기를 반영하는 개체 크기를 사용합니다.

여러 do기본를 사용하여 기존 환경을 검토할 때 데이터베이스 크기가 변형될 수 있습니다. 이것이 사실인 경우 가장 작은 GC(글로벌 카탈로그) 및 GC가 아닌 크기를 사용합니다.

데이터베이스 크기는 운영 체제 버전마다 다를 수 있습니다. Windows Server 2003과 같은 이전 운영 체제를 실행하는 DC는 Windows Server 2008 R2와 같은 이후 운영 체제를 실행하는 DC보다 데이터베이스 크기가 작으며, 특히 Active Directory 휴지통 또는 자격 증명 로밍과 같은 기능을 사용하는 경우 더욱 그렇습니다.

참고 항목

  • 새 환경의 경우 Active Directory 사용자 및 조직 구성 단위의 증가 추정치에 따르면 100,000명의 사용자(동일한 작업기본)가 약 450MB의 공간을 소비한다는 것을 알 수 있습니다. 채워진 특성은 총 금액에 큰 영향을 미칠 수 있습니다. 특성은 Microsoft Exchange Server 및 Lync를 비롯한 타사 제품과 Microsoft 제품 모두에서 많은 개체에 채워집니다. 환경의 제품 포트폴리오를 기반으로 하는 평가가 선호되지만, 가장 큰 환경을 제외한 모든 환경에 대한 정확한 추정치에 대한 수학 및 테스트를 자세히 설명하는 연습은 실제로 상당한 시간과 노력의 가치가 없을 수 있습니다.
  • 오프라인 조각 모음을 사용하도록 설정하기 위해 NTDS.dit 크기의 110%를 사용 가능한 공간으로 사용할 수 있는지 확인하고 3~5년 동안 하드웨어 수명을 확장할 계획입니다. 스토리지가 얼마나 저렴한지 감안할 때 스토리지 할당으로 DIT 크기를 300%로 예측하면 성장을 수용하고 오프라인 조각 모음에 대한 잠재적인 필요성을 수용하는 것이 안전합니다.

스토리지에 대한 가상화 고려 사항

단일 볼륨에 여러 VHD(가상 하드 디스크) 파일이 할당되는 시나리오에서는 DIT의 크기가 210%(DIT의 100% + 여유 공간의 110%) 이상인 고정 크기 디스크를 사용하여 충분한 공간이 예약되어 있는지 확인합니다.

계산 요약 예제

평가 단계에서 수집된 데이터 크기
NTDS.dit 크기 35GB
오프라인 조각 모음을 허용하는 한정자 2.1GB
필요한 총 스토리지 73.5GB

참고 항목

필요한 이 스토리지는 SYSVOL, 운영 체제, 페이지 파일, 임시 파일, 로컬 캐시된 데이터(예: 설치 관리자 파일) 및 애플리케이션에 필요한 스토리지에 추가됩니다.

스토리지 성능

스토리지 성능 평가

모든 컴퓨터 내에서 가장 느린 구성 요소인 스토리지는 클라이언트 환경에 가장 큰 부정적인 영향을 미칠 수 있습니다. RAM 크기 조정 권장 사항이 실현 가능하지 않을 정도로 큰 환경의 경우 성능에 대한 스토리지 계획을 간과하면 엄청난 결과를 초래할 수 있습니다. 또한 스토리지 기술의 복잡성과 종류는 별도의 실제 디스크에 "운영 체제, 로그 및 데이터베이스 배치"의 오랜 모범 사례의 관련성이 유용한 시나리오에서 제한되기 때문에 실패 위험을 더욱 증가합니다. 이는 오랜 모범 사례는 "디스크"가 전용 스핀들이며 I/O를 격리할 수 있다는 가정을 기반으로 하기 때문입니다. 이를 실현하는 이 가정은 더 이상 다음의 도입과 관련이 없습니다.

  • RAID
  • 새 스토리지 유형 및 가상화 및 공유 스토리지 시나리오
  • SAN(스토리지 영역 네트워크)의 공유 스핀들
  • SAN 또는 네트워크 연결 스토리지의 VHD 파일
  • 반도체 드라이브
  • 계층화된 스토리지 아키텍처(즉, 더 큰 스핀들 기반 스토리지를 캐싱하는 SSD 스토리지 계층)

특히 공유 스토리지(RAID, SAN, NAS, JBOD(즉, 저장소 공간), VHD)는 모두 백 엔드 스토리지에 배치되는 다른 작업 부하에 의해 초과 구독/오버로드될 수 있습니다. 또한 SAN/네트워크/드라이버 문제(실제 디스크와 AD 애플리케이션 간의 모든 문제)가 제한 및/또는 지연을 일으킬 수 있다는 문제를 추가합니다. 설명을 위해 이러한 구성은 "나쁜" 구성이 아니며, 모든 구성 요소가 제대로 작동해야 하는 더 복잡한 구성이므로 성능이 허용되는지 확인하기 위해 추가적인 주의가 필요합니다. 자세한 설명은 이 문서의 뒷부분에 있는 부록 C, 하위 섹션 "SAN 소개" 및 부록 D를 참조하세요. 또한 반도체 드라이브는 한 번에 하나의 IO만 처리하도록 허용하는 것과 관련하여 회전 디스크(하드 드라이브)의 제한이 없는 반면, 여전히 IO 제한 사항이 있으며 SSD의 오버로드/초과 구독이 가능합니다. 즉, 기본 스토리지 아키텍처 및 디자인에 관계없이 모든 스토리지 성능 작업의 최종 목표는 필요한 양의 IOPS(입출력 작업 수)를 사용할 수 있도록 하고 이러한 IOPS가 허용 가능한 시간 프레임(이 문서의 다른 위치에 지정된 대로) 내에서 수행되도록 하는 것입니다. 로컬로 연결된 스토리지를 사용하는 이러한 시나리오의 경우 기존 로컬 스토리지 시나리오를 디자인하는 방법에 대한 기본 사항에 대해서는 부록 C를 참조하세요. 이러한 보안 주체는 일반적으로 더 복잡한 스토리지 계층에 적용할 수 있으며 백 엔드 스토리지 솔루션을 지원하는 공급업체와의 대화에도 도움이 됩니다.

  • 사용 가능한 다양한 스토리지 옵션을 고려할 때 하드웨어 지원 팀 또는 공급업체의 전문 지식을 활용하여 특정 솔루션이 AD DS의 요구를 충족하는지 확인하는 것이 좋습니다. 다음 숫자는 스토리지 전문가에게 제공되는 정보입니다.

데이터베이스가 너무 커서 RAM에 보관할 수 없는 환경의 경우 성능 카운터를 사용하여 지원해야 하는 I/O 양을 결정합니다.

  • LogicalDisk(*)\Avg Disk sec/Read(예: NTDS.dit가 D:/ 드라이브에 저장된 경우 전체 경로는 LogicalDisk(D:)\Avg Disk sec/Read)입니다.
  • LogicalDisk(*)\Avg Disk sec/Write
  • LogicalDisk(*)\Avg Disk sec/Transfer
  • LogicalDisk(*)\Reads/sec
  • LogicalDisk(*)\Writes/sec
  • LogicalDisk(*)\Transfers/sec

현재 환경의 요구를 벤치마킹하려면 15/30/60분 간격으로 샘플링해야 합니다.

결과 평가

참고 항목

일반적으로 가장 까다로운 구성 요소이므로 데이터베이스에서 읽기에 중점을 둡니다. LogicalDisk(NTDS 로그)\Avg Disk sec/Write and LogicalDisk(<<NTDS Log>>)\Writes/sec를 대체하여 로그 파일에 대한 쓰기에 동일한 논리를 적용할 수 있습니다.

  • LogicalDisk(<NTDS>)\Avg Disk sec/Read는 현재 스토리지의 크기가 적절한지 여부를 나타냅니다. 결과가 디스크 형식의 디스크 액세스 시간과 거의 같으면 LogicalDisk(<NTDS>)\Reads/sec는 유효한 측정값입니다. 백 엔드의 스토리지에 대한 제조업체 사양을 확인하지만 LogicalDisk(<NTDS>)\Avg Disk sec/Read의 적절한 범위는 대략 다음과 같습니다.
    • 7200 – 9~12.5밀리초(밀리초)
    • 10,000 ~ 6~10ms
    • 15,000 ~ 4~6ms
    • SSD – 1~3ms

    • 참고 항목

      스토리지 성능이 원본에 따라 15ms에서 20ms로 저하된다는 권장 사항 존재합니다. 위의 값과 다른 지침의 차이점은 위의 값이 정상 작동 범위라는 점입니다. 다른 권장 사항은 클라이언트 환경이 크게 저하되고 눈에 띄는 시기를 식별하는 문제 해결 지침입니다. 자세한 설명은 부록 C를 참조하세요.

  • LogicalDisk(<NTDS>)\Reads/sec는 수행 중인 I/O의 양입니다.
    • LogicalDisk(NTDS>)\Avg Disk sec/Read가 백 엔드 스토리지의 최적 범위 내에 있는 경우 LogicalDisk(<NTDS>)\Reads/sec를 사용하여 스토리지 크기를 직접 지정할 수 있습니다.<
    • LogicalDisk(NTDS>)\Avg Disk sec/Read가 백 엔드 스토리지에 대한 최적 범위 내에 있지 않으면 (LogicalDisk(<NTDS>)\Avg Disk sec/Read) ÷(물리적 미디어 디스크 액세스 시간) ×(LogicalDisk(<NTDS>)\Avg Disk sec/Read) 수식에 따라 추가 I/O가 필요합니다.<

고려 사항:

  • 서버가 최적 이하의 RAM으로 구성된 경우 이러한 값은 계획 목적으로 정확하지 않습니다. 높은 쪽에서 잘못 사용되며 여전히 최악의 시나리오로 사용할 수 있습니다.
  • RAM을 추가/최적화하면 읽기 I/O(NTDS>)<\Reads/Sec의 양이 감소합니다. 즉, 스토리지 솔루션은 처음에 계산된 만큼 강력하지 않을 수 있습니다. 아쉽게도 이 일반 설명보다 더 구체적인 것은 클라이언트 부하에 환경적으로 종속되며 일반적인 지침을 제공할 수 없습니다. 가장 좋은 옵션은 RAM을 최적화한 후 스토리지 크기를 조정하는 것입니다.

성능에 대한 가상화 고려 사항

위의 모든 가상화 토론과 마찬가지로 기본 공유 인프라가 기본 공유 미디어 및 모든 경로를 사용하여 DC 로드와 다른 리소스를 지원할 수 있는지 확인하는 것이 핵심입니다. 이는 물리적 do기본 컨트롤러가 다른 서버 또는 애플리케이션과 SAN, NAS 또는 iSCSI 인프라에서 동일한 기본 미디어를 공유하든, 기본 미디어를 공유하는 SAN, NAS 또는 iSCSI 인프라에 대한 통과 액세스를 사용하는 게스트이든, 게스트가 로컬 또는 SAN 공유 미디어에 상주하는 VHD 파일을 사용하는지 여부에 관계없이 적용됩니다. NAS 또는 iSCSI 인프라. 계획 연습은 기본 미디어가 모든 소비자의 총 부하를 지원할 수 있도록 하는 것입니다.

또한 게스트 관점에서는 트래버스해야 하는 추가 코드 경로가 있으므로 모든 스토리지에 액세스하기 위해 호스트를 통과해야 하는 성능에 영향을 줍니다. 당연히 스토리지 성능 테스트는 가상화가 호스트 시스템의 프로세서 사용률에 주관적인 처리량에 영향을 미친다는 것을 나타냅니다(부록 A: CPU 크기 조정 조건 참조). 이는 게스트가 요구하는 호스트의 리소스에 의해 분명히 영향을 받습니다. 이는 가상화된 시나리오의 처리 요구 사항과 관련된 가상화 고려 사항에 영향을 줍니다(처리를 위한 가상화 고려 사항 참조).

이 작업을 더 복잡하게 만드는 것은 성능에 영향을 주는 다양한 스토리지 옵션을 사용할 수 있다는 것입니다. 실제에서 가상으로 마이그레이션할 때 안전한 추정값으로 1.10의 승수를 사용하여 통과 스토리지, SCSI 어댑터 또는 IDE와 같은 Hyper-V의 가상화된 게스트에 대한 다양한 스토리지 옵션을 조정합니다. 다른 스토리지 시나리오 간에 전송할 때 수행해야 하는 조정은 스토리지가 로컬, SAN, NAS 또는 iSCSI인지와 관련이 없습니다.

계산 요약 예제

정상 작동 조건에서 정상 시스템에 필요한 I/O 양을 결정합니다.

  • LogicalDisk(<NTDS 데이터베이스 드라이브>)\15분 기간 동안의 전송/초
  • 기본 스토리지의 용량이 초과되는 스토리지에 필요한 I/O 양을 확인하려면 다음을 수행합니다.

    필요한 IOPS = (LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read ÷< Target Avg Disk sec/Read>) × LogicalDisk(<NTDS 데이터베이스 드라이브>)\Read/sec

카운터 값
Actual LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Transfer .02초(20밀리초)
Target LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Transfer .01초
사용 가능한 IO의 변경에 대한 승수 0.02 ÷ 0.01 = 2
값 이름 값
LogicalDisk(<NTDS 데이터베이스 드라이브>)\Transfers/sec 400
사용 가능한 IO의 변경에 대한 승수 2
사용량이 많은 기간 동안 필요한 총 IOPS 800

캐시를 데워야 하는 속도를 확인하려면 다음을 수행합니다.

  • 캐시를 데우는 데 허용되는 최대 시간을 결정합니다. 디스크에서 전체 데이터베이스를 로드하는 데 걸리는 시간 또는 전체 데이터베이스를 RAM에 로드할 수 없는 시나리오의 경우 RAM을 채우는 데 최대 시간이 됩니다.
  • 공백을 제외한 데이터베이스의 크기를 결정합니다. 자세한 내용은 스토리지 평가를 참조 하세요.
  • 데이터베이스 크기를 8KB로 나눕니다. 데이터베이스를 로드하는 데 필요한 총 IO입니다.
  • 총 IO를 정의된 시간 프레임의 초 수로 나눕니다.

ESE가 고정 캐시 크기를 갖도록 구성되지 않은 경우 이전에 로드된 페이지가 제거되고 AD DS는 기본적으로 변수 캐시 크기를 사용하므로 계산된 속도는 정확하지 않습니다.

수집할 데이터 포인트 값
웜할 수 있는 최대 시간 10분(600초)
데이터베이스 크기 2GB
계산 단계 수식 결과
페이지의 데이터베이스 크기 계산 (2GB × 1024 × 1024) = KB의 데이터베이스 크기 2,097,152KB
데이터베이스의 페이지 수 계산 2,097,152KB ÷ 8KB = 페이지 수 262,144페이지
캐시를 완전히 웜하는 데 필요한 IOPS 계산 262,144페이지 ÷ 600초 = IOPS 필요 437 IOPS

처리

Active Directory 프로세서 사용량 평가

대부분의 환경에서는 계획 섹션에 설명된 대로 스토리지, RAM 및 네트워킹이 제대로 조정된 후 처리 용량을 관리하는 것이 가장 주의를 기울여야 하는 구성 요소가 됩니다. CPU 용량을 평가하는 데 필요한 두 가지 과제가 있습니다.

  • 환경의 애플리케이션이 공유 서비스 인프라에서 잘 동작하는지 여부와 "비용이 많이 들고 비효율적인 검색 추적"이라는 섹션에서 보다 효율적인 Microsoft Active Directory 지원 애플리케이션을 만들거나 하위 수준 SAM 호출에서 LDAP 호출로 마이그레이션하는 방법에 대해 설명합니다.

    더 큰 환경에서는 제대로 코딩되지 않은 애플리케이션이 CPU 부하의 변동성을 유도하고, 다른 애플리케이션에서 너무 많은 CPU 시간을 "도용"하고, 인위적으로 용량 요구를 증가시키고, DC에 부하를 고르지 않게 분산할 수 있기 때문에 이것이 중요합니다.

  • AD DS는 다양한 잠재 클라이언트가 있는 분산 환경이므로 사용 패턴 및 AD DS를 활용하는 애플리케이션의 유형 또는 수량으로 인해 "단일 클라이언트"의 비용을 예측하는 것은 환경적으로 주관적입니다. 즉, 네트워킹 섹션과 마찬가지로 광범위한 적용 가능성을 위해 환경에 필요한 총 용량을 평가하는 관점에서 더 잘 접근합니다.

기존 환경의 경우 이전에 스토리지 크기 조정에 대해 설명했으므로 이제 스토리지 크기가 제대로 조정되어 프로세서 로드와 관련된 데이터가 유효하다고 가정합니다. 다시 말해, 시스템의 병목 현상이 스토리지의 성능이 아닌지 확인하는 것이 중요합니다. 병목 현상이 존재하고 프로세서가 대기하는 경우 병목 현상이 제거되면 사라질 유휴 상태가 있습니다. 프로세서 대기 상태가 제거되면 정의에 따라 데이터를 더 이상 기다릴 필요가 없으므로 CPU 사용률이 증가합니다. 따라서 성능 카운터 "Logical Disk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read" 및 "Process(lsass)\% Processor Time"을 수집합니다. "Logical Disk(NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read"가 10~15ms를 초과하면 "Process(<lsass)\% Processor Time"의 데이터가 인위적으로 낮아집니다. 이는 Microsoft 지원에서 스토리지 관련 성능 문제 해결에 사용하는 일반적인 임계값입니다. 이전과 마찬가지로 샘플 간격은 15분, 30분 또는 60분으로 권장됩니다. 더 적은 것은 일반적으로 좋은 측정을 위해 너무 휘발성이 될 것입니다; 더 큰 것은 매일 피킹을 과도하게 부드럽게 합니다.

소개

할 일기본 컨트롤러에 대한 용량 계획을 계획하려면 처리 능력을 가장 잘 알고 있어야 합니다. 최대 성능을 보장하기 위해 시스템 크기를 조정하는 경우 항상 병목 상태인 구성 요소가 있으며 적절한 크기의 Do기본 컨트롤러에 프로세서가 됩니다.

환경의 수요를 사이트별로 검토하는 네트워킹 섹션과 마찬가지로 요구되는 컴퓨팅 용량에 에도 동일한 작업을 수행해야 합니다. 사용 가능한 네트워킹 기술이 일반 수요를 훨씬 초과하는 네트워킹 섹션과 달리 CPU 용량 크기 조정에 더 많은 주의를 기울입니다. 중간 크기의 모든 환경으로; 1,000명이 넘는 동시 사용자가 CPU에 상당한 부하를 부과할 수 있습니다.

아쉽게도 AD를 활용하는 클라이언트 애플리케이션의 엄청난 가변성으로 인해 CPU당 사용자의 일반적인 추정치는 모든 환경에 비참하게 적용할 수 없습니다. 특히 컴퓨팅 요구 사항은 사용자 동작 및 애플리케이션 프로필의 적용을 받습니다. 따라서 각 환경의 크기를 개별적으로 조정해야 합니다.

대상 사이트 동작 프로필

이전에 멘션 전체 사이트에 대한 용량을 계획할 때 목표는 N + 1 용량 설계를 사용하여 설계를 대상으로 하여 사용량이 많은 기간 동안 하나의 시스템이 실패하면 적절한 수준의 품질로 서비스를 계속할 수 있도록 하는 것입니다. 즉, "N" 시나리오에서 모든 상자의 로드는 사용량이 많은 기간 동안 100% 미만(더 나은 경우 80% 미만)이어야 합니다.

또한 사이트의 애플리케이션과 클라이언트가 do기본 컨트롤러 찾기에 모범 사례를 사용하는 경우(즉, DsGetDcName 함수 사용) 클라이언트는 여러 가지 요인으로 인해 일시적인 급증으로 비교적 균등하게 분산되어야 합니다.

다음 예제에서는 다음과 같은 가정이 수행됩니다.

  • 사이트의 5개 DC에는 각각 4개의 CPU가 있습니다.
  • 업무 시간 동안 총 대상 CPU 사용량은 정상 작동 조건("N + 1")에서 40%이고, 그렇지 않으면 60%("N")입니다. 업무 외 시간에는 백업 소프트웨어 및 기타 기본 테넌스가 사용 가능한 모든 리소스를 사용해야 하므로 대상 CPU 사용량은 80%입니다.

CPU usage chart

각 DC에 대한 차트 (Processor Information(_Total)\% Processor Utility) 의 데이터 분석:

  • 대부분의 경우 클라이언트가 DC 로케이터를 사용하고 잘 작성된 검색을 할 때 예상되는 부하가 비교적 균등하게 분산됩니다.

  • 10%의 5분 급증이 있으며, 일부는 20%만큼 큽니다. 일반적으로 용량 계획 대상을 초과하지 않는 한 이를 조사하는 것은 가치가 없습니다.

  • 모든 시스템의 피크 기간은 오전 8시에서 오전 9시 15분 사이입니다. 오전 5시에서 오후 5시 정도까지 원활하게 전환하면 일반적으로 비즈니스 주기를 나타냅니다. 오후 5시에서 오전 4시 사이에 상자별 시나리오에서 CPU 사용량이 임의로 급증할수록 용량 계획 문제를 벗어날 수 있습니다.

    참고 항목

    잘 관리되는 시스템에서는 백업 소프트웨어 실행, 전체 시스템 바이러스 백신 검사, 하드웨어 또는 소프트웨어 인벤토리, 소프트웨어 또는 패치 배포 등이 급증할 수 있습니다. 최대 사용자 비즈니스 주기를 벗어나므로 대상은 초과되지 않습니다.

  • 각 시스템이 약 40%이고 모든 시스템이 동일한 수의 CPU를 가지기 때문에 한 번 실패하거나 오프라인으로 전환할 경우 다시 기본 시스템은 약 53%로 실행됩니다(시스템 D의 40% 부하가 균등하게 분할되고 시스템 A 및 시스템 C의 기존 40% 부하에 추가됨). 여러 가지 이유로 이 선형 가정은 완벽하게 정확하지는 않지만 측정하기에 충분한 정확도를 제공합니다.

    대체 시나리오 – 40%에서 실행되는 두 개의 do기본 컨트롤러: 하나는 실패하고기본 컨트롤러는 실패하고기본 예상 CPU는 약 80%가 됩니다. 이는 용량 계획에 대해 위에서 설명한 임계값을 훨씬 초과하며 위의 부하 프로필에서 볼 수 있는 10%에서 20%의 헤드룸 양을 심각하게 제한하기 시작합니다. 즉, 스파이크가 "N" 시나리오 동안 DC를 90%에서 100%로 구동하고 응답성이 확실히 저하됩니다.

CPU 요구 계산

"Process\% Processor Time" 성능 개체 카운터는 애플리케이션의 모든 스레드가 CPU에 소비하는 총 시간을 합산하고 경과된 총 시스템 시간으로 나눕니다. 이는 다중 CPU 시스템의 다중 스레드 애플리케이션이 100% CPU 시간을 초과할 수 있으며 "프로세서 정보\% 프로세서 유틸리티"와 매우 다르게 해석된다는 것입니다. 실제로 "프로세스(lsass)\% 프로세서 시간"은 프로세스의 요구를 지원하는 데 필요한 100%에서 실행되는 CPU 수로 볼 수 있습니다. 값이 200%이면 전체 AD DS 로드를 지원하기 위해 각각 100%에 있는 2개의 CPU가 필요합니다. CPU가 100% 용량으로 실행되는 것이 CPU 및 전력 및 에너지 소비에 소요되는 비용 측면에서 가장 비용 효율적이지만 부록 A에 자세히 설명된 여러 가지 이유로 인해 시스템이 100%에서 실행되지 않을 때 다중 스레드 시스템의 응답성이 향상됩니다.

클라이언트 부하의 일시적인 급증을 수용하려면 시스템 용량의 40%에서 60% 사이의 최고 기간 CPU를 대상으로 하는 것이 좋습니다. 위의 예제를 사용하면 AD DS(lsass 프로세스) 로드에 3.33(60% 대상)에서 5개(40% 대상) CPU가 필요합니다. 기본 운영 체제 및 필요한 기타 에이전트(예: 바이러스 백신, 백업, 모니터링 등)의 요구에 따라 추가 용량을 추가해야 합니다. 에이전트의 영향을 환경별로 평가해야 하지만 단일 CPU의 5%에서 10% 사이의 예상을 만들 수 있습니다. 현재 예제에서는 사용량이 많은 기간 동안 3.43(60% 목표)에서 5.1(40% 대상) CPU가 필요하다는 것을 시사합니다.

이 작업을 수행하는 가장 쉬운 방법은 Windows 안정성 및 성능 모니터(성능)에서 "누적 영역" 보기를 사용하여 모든 카운터의 크기를 동일하게 조정하는 것입니다.

가정:

  • 목표는 사용 공간을 가능한 한 적은 수의 서버로 줄이는 것입니다. 이상적으로는 한 서버가 부하를 전달하고 중복성을 위해 추가된 추가 서버(N + 1 시나리오)를 수행하는 것이 좋습니다.

Processor time chart for lsass process (over all processors)

차트의 데이터에서 얻은 지식(Process(lsass)\% Processor Time):

  • 영업일은 7:00 경에 증가하기 시작하고 오후 5:00에 감소합니다.
  • 가장 바쁜 기간은 오전 9:30부터 오전 11:00까지입니다.

    참고 항목

    모든 성능 데이터는 기록입니다. 9:15의 최고 데이터 포인트는 9:00에서 9:15까지의 부하를 나타냅니다.

  • 오전 7시 이전에 급증하여 다른 표준 시간대 또는 백업과 같은 백그라운드 인프라 작업의 부하를 나타낼 수 있습니다. 오전 9시 30분에 최고점이 이 활동을 초과하므로 관련이 없습니다.
  • 사이트에는 3개의 할기본 컨트롤러가 있습니다.

최대 로드 시 lsass는 CPU 1개 중 약 485%를 사용하거나 100%에서 실행되는 4.85 CPU를 사용합니다. 앞의 수학에 따라 사이트는 AD DS에 대해 약 12.25 CPU가 필요하다는 것을 의미합니다. 백그라운드 프로세스에 대해 위의 제안 사항을 5%에서 10%로 추가하면 현재 서버를 교체하는 데 동일한 부하를 지원하려면 약 12.30~12.35 CPU가 필요합니다. 이제 성장에 대한 환경 추정치를 고려해야 합니다.

LDAP 가중치를 조정하는 경우

LdapSrvWeight 튜닝을 고려해야 하는 몇 가지 시나리오가 있습니다. 용량 계획의 컨텍스트 내에서 이 작업은 애플리케이션 또는 사용자 부하가 균등하게 분산되지 않거나 기본 시스템이 기능 측면에서 균등하게 분산되지 않을 때 수행됩니다. 용량 계획을 초과해야 하는 이유는 이 문서의 범위를 벗어납니다.

LDAP 가중치를 조정하는 두 가지 일반적인 이유가 있습니다.

  • PDC 에뮬레이터는 사용자 또는 애플리케이션 로드 동작이 균등하게 분산되지 않는 모든 환경에 영향을 주는 예제입니다. 특정 도구와 작업이 PDC 에뮬레이터(예: 그룹 정책 관리 도구, 인증 실패의 경우 두 번째 시도, 신뢰 설정 등)를 대상으로 하므로 PDC 에뮬레이터의 CPU 리소스가 사이트의 다른 곳보다 더 많이 요구될 수 있습니다.
    • PDC 에뮬레이터의 부하를 줄이고 다른 작업에서 부하를 늘리기 위해 CPU 사용률에 눈에 띄는 차이가 있는 경우에만 이를 조정하는 것이 유용합니다기본 컨트롤러는 부하를 더 균등하게 분산할 수 있습니다.
    • 이 경우 PDC 에뮬레이터에 대해 LDAPSrvWeight를 50에서 75 사이로 설정합니다.
  • 사이트의 CPU(및 속도)가 서로 다른 서버. 예를 들어 8코어 서버 2개와 4코어 서버 1개가 있다고 가정해 보겠습니다. 마지막 서버에는 다른 두 서버의 프로세서 절반이 있습니다. 즉, 잘 분산된 클라이언트 로드는 4코어 상자의 평균 CPU 부하를 8코어 상자의 약 2배로 증가합니다.
    • 예를 들어 8코어 상자 2개는 40%에서 실행되고 4코어 상자는 80%에서 실행됩니다.
    • 또한 이 시나리오에서 8코어 상자 1개가 손실될 경우의 영향, 특히 4코어 상자가 오버로드된다는 사실도 고려해 보세요.

예제 1 - PDC

System 기본값 사용률 New LdapSrvWeight 예상 새 사용률
DC 1(PDC 에뮬레이터) 53% 57 40%
DC 2 33% 100 40%
DC 3 33% 100 40%

여기서 캐치는 PDC 에뮬레이터 역할이 전송되거나 압수되는 경우, 특히 사이트의 다른 할 일기본 컨트롤러에 새 PDC 에뮬레이터가 크게 증가한다는 것입니다.

대상 사이트 동작 프로필 섹션의 예제를 사용하여 사이트의 세 가지 do기본 컨트롤러에 4개의 CPU가 있다고 가정했습니다. 정상적인 조건에서 할 일기본 컨트롤러 중 하나에 8개의 CPU가 있는 경우 어떻게 해야 하나요? 40%의 사용률과 20%의 사용률에서 두 개의 할기본 컨트롤러가 있습니다. 나쁘지는 않지만 부하의 균형을 좀 더 잘 맞출 수 있는 기회가 있습니다. LDAP 가중치를 활용하여 이 작업을 수행합니다. 예제 시나리오는 다음과 같습니다.

예제 2 - 다른 CPU 수

System 프로세서 정보\ % 프로세서 유틸리티(_Total)
기본값 사용률		 New LdapSrvWeight 예상 새 사용률
4-CPU DC 1 40 100 30%
4-CPU DC 2 40 100 30%
8-CPU DC 3 20 200 30%

하지만 이러한 시나리오에 매우 주의해야 합니다. 위에서 볼 수 있듯이 수학은 종이에 정말 멋지고 예쁘게 보입니다. 그러나 이 문서 전체에서 "N + 1" 시나리오를 계획하는 것이 가장 중요합니다. 한 DC가 오프라인으로 전환되는 영향은 모든 시나리오에 대해 계산되어야 합니다. 부하 분산이 균등한 이전 시나리오에서는 모든 서버에서 부하가 균등하게 분산된 "N" 시나리오 동안 60% 부하를 보장하기 위해 비율이 일관성을 유지하므로 분산이 잘 됩니다. PDC 에뮬레이터 튜닝 시나리오 및 일반적으로 사용자 또는 애플리케이션 부하가 불균형한 시나리오를 살펴보면 효과는 매우 다릅니다.

System 튜닝된 사용률 New LdapSrvWeight 예상 신규 사용률
DC 1(PDC 에뮬레이터) 40% 85 47%
DC 2 40% 100 53%
DC 3 40% 100 53%

처리를 위한 가상화 고려 사항

가상화된 환경에서 수행해야 하는 용량 계획의 두 계층이 있습니다. 호스트 수준에서 이전에 do기본 컨트롤러 처리에 대해 설명한 비즈니스 주기의 식별과 유사하게 사용량이 많은 기간 동안의 임계값을 식별해야 합니다. 기본 보안 주체는 CPU에서 게스트 스레드를 예약하는 호스트 컴퓨터의 경우 물리적 컴퓨터의 CPU에서 AD DS 스레드를 가져오는 것과 동일하기 때문에 기본 호스트에서 동일한 목표인 40%에서 60%를 권장합니다. 다음 계층에서 게스트 계층은 스레드 일정의 보안 주체가 변경되지 않았기 때문에 게스트 내의 목표가 40%에서 60% 범위로 다시 기본.

직접 매핑된 시나리오에서는 호스트당 게스트 1명, 이 시점에 수행된 모든 용량 계획을 기본 호스트 운영 체제의 요구 사항(RAM, 디스크, 네트워크)에 추가해야 합니다. 공유 호스트 시나리오에서 테스트는 기본 프로세서의 효율성에 10%의 영향을 미친다는 것을 나타냅니다. 즉, 사이트에 40%의 대상에 10개의 CPU가 필요한 경우 모든 "N" 게스트에 할당하는 데 권장되는 가상 CPU 양은 11이 됩니다. 물리적 서버 및 가상 서버가 혼합된 배포가 있는 사이트에서 한정자는 VM에만 적용됩니다. 예를 들어 사이트에 "N + 1" 시나리오가 있는 경우 CPU가 10개인 물리적 또는 직접 매핑된 서버 1개는 호스트에 CPU가 11개 있는 게스트 1개와 거의 동일하며, 11개의 CPU가 do기본 컨트롤러용으로 예약됩니다.

AD DS 부하를 지원하는 데 필요한 CPU 수량을 분석하고 계산하는 동안 실제 하드웨어 측면에서 구매할 수 있는 항목에 매핑되는 CPU 수가 반드시 클린 매핑되지는 않습니다. 가상화를 사용하면 반올림할 필요가 없습니다. 가상화는 CPU를 VM에 추가할 수 있는 용이성을 고려하여 사이트에 컴퓨팅 용량을 추가하는 데 필요한 노력을 줄입니다. 추가 CPU를 게스트에 추가해야 할 때 기본 하드웨어를 사용할 수 있도록 필요한 컴퓨팅 능력을 정확하게 평가할 필요가 없습니다. 언제나처럼 수요 증가를 계획하고 모니터링해야 합니다.

계산 요약 예제

System 최고 CPU
DC 1 120%
DC 2 147%
Dc 3 218%
사용 중인 총 CPU 485%
대상 시스템 수 총 대역폭(위부터)
40% 대상에 필요한 CPU 4.85 ÷ .4 = 12.25

이 시점의 중요성 때문에 반복하려면 성장을 계획해야 합니다. 향후 3년 동안 50%의 성장률을 가정하면 이 환경은 3년 만에 18.375 CPU(12.25 × 1.5)가 필요합니다. 대체 계획은 첫 해 이후에 검토하고 필요에 따라 추가 용량을 추가하는 것입니다.

NTLM에 대한 교차 신뢰 클라이언트 인증 로드

교차 신뢰 클라이언트 인증 로드 평가

많은 환경에서 하나 이상의 do기본s가 트러스트에 의해 연결되었을 수 있습니다. Kerberos 인증을 사용하지 않는 다른 do기본 ID에 대한 인증 요청은 대상에서 do기본 컨트롤러의 보안 채널을 사용하여 트러스트를 다른 do기본 컨트롤러로 트래버스해야 합니다기본 또는 대상에 대한 경로에서 다음 기본 수행합니다기본. do기본 컨트롤러가 신뢰할 수 있는 do기본 컨트롤러에 대해 수행할 수 있는 보안 채널을 사용하는 동시 호출 수기본 MaxConcurrentAPI라는 설정에 의해 제어됩니다. 할 일기본 컨트롤러의 경우 보안 채널이 부하 양을 처리할 수 있도록 하는 방법은 MaxConcurrentAPI 튜닝 또는 포리스트 내에서 바로 가기 트러스트를 만드는 두 가지 방법 중 하나로 수행됩니다. 개별 트러스트의 트래픽 볼륨을 측정하려면 MaxConcurrentApi 설정을 사용하여 NTLM 인증에 대한 성능 튜닝을 수행하는 방법을 참조 하세요.

데이터를 수집하는 동안 다른 모든 시나리오와 마찬가지로 데이터를 유용하게 사용하려면 하루 중 사용량이 많은 기간 동안 수집해야 합니다.

참고 항목

인트라포레스트 및 포리스트 간 시나리오는 인증이 여러 트러스트를 트래버스하도록 할 수 있으며 각 단계를 조정해야 합니다.

계획

기본적으로 NTLM 인증을 사용하거나 특정 구성 시나리오에서 사용하는 여러 애플리케이션이 있습니다. 애플리케이션 서버는 용량이 늘어나고 활성 클라이언트 수가 늘어나고 서비스도 늘어나고 있습니다. 또한 클라이언트가 제한된 시간 동안 세션을 열어 두고 정기적으로 다시 연결하는 추세도 있습니다(예: 이메일 끌어오기 동기화). 높은 NTLM 부하의 또 다른 일반적인 예는 인터넷 액세스를 위해 인증이 필요한 웹 프록시 서버입니다.

이러한 애플리케이션은 NTLM 인증에 상당한 부하를 발생시킬 수 있으며, 특히 사용자와 리소스가 서로 다른 경우 DC에 상당한 부담을 줄 수 기본.

교차 신뢰 부하를 관리하는 방법에는 여러 가지가 있으며, 실제로는 배타적인 하나/또는 시나리오가 아닌 함께 사용됩니다. 가능한 옵션은 아래와 같습니다.

  • 사용자가 상주하는 것과 동일한 기본 사용자가 사용하는 서비스를 찾아 교차 신뢰 클라이언트 인증을 줄입니다.
  • 사용 가능한 보안 채널 수를 늘입니다. 이는 포리스트 내 및 포리스트 간 트래픽과 관련이 있으며 바로 가기 트러스트라고 합니다.
  • MaxConcurrentAPI에 대한 기본 설정을 조정합니다.

기존 서버에서 MaxConcurrentAPI를 튜닝하는 경우 수식은 다음과 같습니다.

New_MaxConcurrentApi_setting ≥(semaphore_acquires + semaphore_time 아웃) × average_semaphore_hold_time ÷ time_collection_length

자세한 내용은 KB 문서 2688798: MaxConcurrentApi 설정을 사용하여 NTLM 인증에 대한 성능 튜닝을 수행하는 방법을 참조하세요.

가상화 고려 사항

없음, 운영 체제 튜닝 설정입니다.

계산 요약 예제

데이터 형식 값
세마포 획득(최소) 6,161
세마포 획득(최대) 6,762
세마포 시간 제한 0
평균 세마포 보류 시간 0.012
컬렉션 기간(초) 1:11분(71초)
수식(KB 2688798) ((6762 – 6161) + 0) × 0.012 /
MaxConcurrentAPI의 최소값 ((6762 – 6161) + 0) × 0.012 ÷ 71 = .101

이 기간 동안 이 시스템의 경우 기본값이 허용됩니다.

용량 계획 목표 준수 모니터링

이 문서 전체에서는 계획 및 크기 조정이 사용률 목표를 향해 나아가는 것에 대해 설명했습니다. 다음은 시스템이 적절한 용량 임계값 내에서 작동하도록 모니터링해야 하는 권장 임계값의 요약 차트입니다. 성능 임계값이 아니라 용량 계획 임계값입니다. 이러한 임계값을 초과하는 서버가 작동하지만 모든 애플리케이션이 제대로 작동하는지 유효성 검사를 시작해야 합니다. 애플리케이션이 잘 동작하는 경우 하드웨어 업그레이드 또는 기타 구성 변경 사항을 평가해야 합니다.

범주 성능 카운터 간격/샘플링 대상 Warning
프로세서 프로세서 정보(_Total)\% 프로세서 유틸리티 60분 40% 60%
RAM(Windows Server 2008 R2 이하) Memory\Available MB < 100MB 해당 없음 < 100MB
RAM(Windows Server 2012) 메모리\장기 평균 대기 캐시 수명 30분 테스트해야 합니다. 테스트해야 합니다.
네트워크 Network Interface(*)\Bytes Sent/sec

Network Interface(*)\Bytes Received/sec

 30분 40% 60%
스토리지 LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read

LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Write

 60분 10ms 15ms
AD 서비스 Netlogon(*)\Average Semaphore Hold Time 60분 0 1초

부록 A: CPU 크기 조정 조건

정의

프로세서(마이크로프로세서) – 프로그램 지침을 읽고 실행하는 구성 요소

CPU – 중앙 처리 장치

다중 코어 프로세서 – 동일한 통합 회로의 여러 CPU

다중 CPU – 동일한 통합 회로가 아닌 여러 CPU

논리 프로세서 – 운영 체제 관점에서 하나의 논리 컴퓨팅 엔진

여기에는 하이퍼 스레드, 다중 코어 프로세서의 코어 1개 또는 단일 코어 프로세서가 포함됩니다.

오늘날의 서버 시스템에는 여러 프로세서, 여러 다중 코어 프로세서 및 하이퍼 스레딩이 있으므로 이 정보는 두 시나리오를 모두 포함하도록 일반화됩니다. 따라서 논리 프로세서라는 용어는 사용 가능한 컴퓨팅 엔진의 운영 체제 및 애플리케이션 관점을 나타내기 때문에 사용됩니다.

스레드 수준 병렬 처리

각 스레드에는 자체 스택 및 지침이 있으므로 각 스레드는 독립적인 작업입니다. AD DS는 다중 스레드이며 Ntdsutil.exe를 사용하여 Active Directory에서 LDAP 정책을 보고 설정하는 방법을 사용하여 사용 가능한 스레드 수를 조정할 수 있으므로 여러 논리 프로세서에서 잘 확장됩니다.

데이터 수준 병렬 처리

여기에는 한 프로세스 내에서(AD DS 프로세스만의 경우) 여러 스레드에서 여러 스레드 간에 데이터를 공유하는 작업이 포함됩니다(일반적으로). 대/소문자를 과도하게 단순화하는 것과 관련하여 데이터에 대한 모든 변경 내용은 해당 스레드를 실행하는 모든 코어에서 모든 다양한 캐시 수준(L1, L2, L3)의 모든 실행 중인 스레드에 반영되고 공유 메모리를 업데이트한다는 것을 의미합니다. 명령 처리를 계속하기 전에 모든 다양한 메모리 위치가 일관되게 유지되는 동안 쓰기 작업 중에 성능이 저하할 수 있습니다.

CPU 속도 및 다중 코어 고려 사항

일반적으로 논리 프로세서는 일련의 명령을 처리하는 데 걸리는 시간을 줄이는 것이 더 빠르지만 논리 프로세서가 많을수록 더 많은 작업을 동시에 실행할 수 있습니다. 시나리오가 공유 메모리에서 데이터를 가져오고, 데이터 수준 병렬 처리를 대기하고, 여러 스레드를 관리하는 오버헤드를 고려하여 시나리오가 본질적으로 더 복잡해짐에 따라 이러한 규칙을 분석합니다. 다중 코어 시스템의 확장성이 선형이 아닌 이유이기도 합니다.

이러한 고려 사항에서 다음과 같은 비유를 고려합니다. 고속도로를 생각해 보십시오. 각 스레드는 개별 자동차이고, 각 차선은 코어이고, 속도 제한은 시계 속도입니다.

  1. 고속도로에 자동차가 하나뿐이면 2차선이나 12차선이 있는지는 중요하지 않습니다. 그 차는 속도 제한이 허용하는 한 빨리 갈 것입니다.
  2. 스레드에 필요한 데이터를 즉시 사용할 수 없다고 가정합니다. 비유는 도로의 세그먼트가 종료되는 것입니다. 고속도로에 자동차가 하나만 있는 경우 차선이 다시 열릴 때까지 속도 제한이 무엇인지는 중요하지 않습니다(데이터는 메모리에서 가져옵니다).
  3. 자동차 수가 증가함에 따라 자동차 수를 관리하는 오버헤드가 증가합니다. 도로가 실질적으로 비어 있을 때(예: 늦은 저녁) 및 교통량이 많은 경우(예: 오후 중반, 혼잡하지 않음) 운전 경험과 필요한 주의량을 비교합니다. 또한 운전자가 하는 일에 대해 걱정할 다른 차선이 하나뿐인 2차선 고속도로에서 운전할 때 필요한 주의량과 다른 많은 운전자가 하는 일에 대해 걱정해야 하는 6차선 고속도로를 고려해 보세요.

    참고 항목

    혼잡 시간 시나리오에 대한 비유는 응답 시간/시스템 사용량이 성능에 미치는 영향 섹션에서 확장됩니다.

결과적으로, 더 많거나 더 빠른 프로세서에 대한 세부 사항은 애플리케이션 동작에 매우 주관적으로 적용되며, AD DS의 경우 환경적으로 매우 구체적이며 환경 내에서 서버마다 다릅니다. 이 때문에 문서의 앞부분에 있는 참조는 지나치게 정밀하게 하는 데 크게 투자하지 않으며, 안전의 여백이 계산에 포함됩니다. 예산 기반 구매 결정을 내릴 때 더 빠른 프로세서 구매를 고려하기 전에 먼저 프로세서 사용량을 40%(또는 환경에 원하는 수)로 최적화하는 것이 좋습니다. 더 많은 프로세서에서 동기화가 증가하면 선형 진행에서 더 많은 프로세서의 진정한 이점이 줄어듭니다(2× 프로세서 수가 2× 미만의 추가 컴퓨팅 성능을 제공합니다).

참고 항목

암달의 법과 구스타프슨의 법칙은 여기에 관련 개념입니다.

응답 시간/시스템 사용량이 성능에 미치는 영향

큐 이론은 대기 선(큐)의 수학 연구입니다. 큐 이론에서 사용법은 수식으로 표현됩니다.

U k = B ÷ T

Uk가 사용률인 경우 B는 사용량이 많은 시간이며 T는 시스템이 관찰된 총 시간입니다. Windows 컨텍스트로 변환하면 실행 중인 상태에 있는 100나노초(ns) 간격 스레드의 수가 지정된 시간 간격으로 사용 가능한 100-ns 간격 수로 나뉩니다. 프로세서 유틸리티(참조 프로세서 개체 및 PERF_100NSEC_TIMER_INV)를 계산하기 위한 수식입니다.

큐 이론은 또한 수식을 제공합니다: N = U k ÷ (1 – U k) 사용률에 따라 대기 항목의 수를 추정 (N은 큐의 길이). 모든 사용률 간격에 대해 차트를 지정하면 프로세서에서 큐가 지정된 CPU 부하에 얼마나 오래 걸리는지에 대한 다음 추정치가 제공됩니다.

Queue length

50%의 CPU 로드 후에는 평균적으로 큐에 있는 다른 한 항목이 항상 대기하며, CPU 사용률이 약 70% 후에 눈에 띄게 빠르게 증가하는 것으로 관찰됩니다.

이 섹션의 앞부분에서 사용된 운전 비유로 돌아갑니다.

  • "오후 중반"의 바쁜 시간은 가설적으로 어딘가에 40 %에서 70 % 범위로 떨어질 것입니다. 차선을 선택할 수 있는 능력이 크게 제한되지 않고, 다른 운전자가 길을 따라갈 가능성이 높지만, 도로의 다른 자동차 들 사이의 안전한 간격을 "찾기"위한 노력의 수준이 필요하지 않도록 충분한 트래픽이 있습니다.
  • 교통량이 혼잡 시간대에 가까워지면 도로 시스템이 100% 용량에 접근한다는 것을 알 수 있습니다. 자동차가 너무 가깝기 때문에 차선을 변경하는 것은 매우 어려울 수 있으므로 그렇게하려면주의를 기울여야합니다.

이 때문에 용량에 대한 장기 평균은 보수적으로 40%로 추정되므로 부하가 비정상적으로 급증할 수 있습니다. 즉, 일시적인 급증(예: 몇 분 동안 실행되지 않는 코딩된 쿼리) 또는 일반적인 부하에서 비정상적인 버스트(긴 주말 후 첫날 아침)가 허용됩니다.

위의 문은 % Processor Time 계산이 사용률법과 동일하다고 간주하여 일반 판독기의 용이성을 약간 간소화합니다. 더 수학적으로 엄격한 사람들을 위해 :

  • PERF_100NSEC_TIMER_INV 번역
    • B = 논리 프로세서에서 "유휴" 스레드가 소비하는 100-ns 간격의 수입니다. PERF_100NSEC_TIMER_INV 계산에서 "X" 변수의 변경 내용
    • T = 지정된 시간 범위의 총 100-ns 간격 수입니다. PERF_100NSEC_TIMER_INV 계산에서 "Y" 변수의 변경 내용입니다.
    • U k = "유휴 스레드" 또는 % 유휴 시간별 논리 프로세서의 사용률입니다.
  • 수학 작업:
    • U k = 1 – %Processor Time
    • %Processor Time = 1 – U k
    • %Processor Time = 1 – B / T
    • %Processor Time = 1 – X1 – X0 / Y1 – Y0

용량 계획에 개념 적용

이전 수학은 시스템에 필요한 논리 프로세서의 수에 대한 결정을 내릴 수 있습니다 압도적으로 복잡한 것 같다. 이 때문에 시스템 크기를 조정하는 방법은 현재 부하에 따라 최대 대상 사용률을 결정하고 거기에 도착하는 데 필요한 논리 프로세서 수를 계산하는 데 중점을 둡니다. 또한 논리 프로세서 속도는 성능, 캐시 효율성, 메모리 일관성 요구 사항, 스레드 예약 및 동기화 및 불완전하게 분산된 클라이언트 부하에 큰 영향을 주지만 서버별로 달라지는 성능에 큰 영향을 줍니다. 상대적으로 저렴한 컴퓨팅 성능 비용으로 필요한 CPU의 완벽한 수를 분석하고 확인하려고 하면 비즈니스 가치를 제공하는 것보다 더 교육적인 연습이 됩니다.

40 %는 어렵고 빠른 요구 사항이 아니며 합리적인 시작입니다. Active Directory의 다양한 소비자는 다양한 수준의 응답성이 필요합니다. 프로세서에 대한 액세스 대기 시간이 늘어나면 클라이언트 성능에 눈에 띄게 영향을 주지 않으므로 환경이 지속적인 평균으로 80% 또는 90% 사용률로 실행될 수 있는 시나리오가 있을 수 있습니다. RAM에 대한 액세스, 디스크에 대한 액세스 및 네트워크를 통해 응답을 전송하는 등 시스템의 논리 프로세서보다 훨씬 느린 많은 영역이 시스템에 있다는 것을 다시 반복하는 것이 중요합니다. 이러한 모든 항목을 함께 튜닝해야 합니다. 예:

  • 디스크 바인딩된 90%를 실행하는 시스템에 프로세서를 더 추가해도 성능이 크게 향상되지는 않을 수 있습니다. 시스템을 심층 분석하면 I/O가 완료되기를 기다리고 있기 때문에 프로세서에서 가져오지 않는 스레드가 많이 있음을 확인할 수 있습니다.
  • 디스크 바인딩된 문제를 해결하면 이전에 대기 상태에서 많은 시간을 소비했던 스레드가 더 이상 I/O 대기 상태에 있지 않으며 CPU 시간에 대한 경쟁이 더 많이 발생할 수 있습니다. 즉, 이전 예제의 90% 사용률이 100%(더 높아질 수 없으므로)로 이동합니다. 두 구성 요소를 함께 튜닝해야 합니다.

    참고 항목

    프로세서 정보(*)\% 프로세서 유틸리티는 "Turbo" 모드가 있는 시스템에서 100%를 초과할 수 있습니다. CPU가 짧은 기간 동안 정격 프로세서 속도를 초과하는 위치입니다. 더 큰 인사이트를 위해 CPU 제조업체 설명서 및 카운터에 대한 설명을 참조하세요.

전체 시스템 사용률 고려 사항을 논의하면 컨트롤러가 가상화된 게스트로 대화할 기본 있습니다. 응답 시간/시스템 사용량이 성능 에 미치는 영향은 가상화된 시나리오에서 호스트와 게스트 모두에 적용됩니다. 따라서 게스트가 한 명뿐인 호스트에서 할 일기본 컨트롤러(및 일반적으로 모든 시스템)는 실제 하드웨어에서 수행하는 것과 거의 동일한 성능을 갖습니다. 호스트에 게스트를 추가하면 기본 호스트의 사용률이 증가하므로 앞에서 설명한 대로 프로세서에 액세스하기 위한 대기 시간이 증가합니다. 요컨대, 논리 프로세서 사용률은 호스트와 게스트 수준에서 모두 관리되어야 합니다.

이전의 비유를 확장하여 고속도로를 물리적 하드웨어로 두고 게스트 VM은 버스(라이더가 원하는 목적지로 바로 가는 고속 버스)와 유사하게 됩니다. 다음 네 가지 시나리오를 상상해 보세요.

  • 그것은 오프 시간, 라이더는 거의 비어있는 버스에 도착, 버스는 또한 거의 비어있는 도로에 도착. 경합할 트래픽이 없기 때문에 라이더는 쉽게 탈 수 있으며 라이더가 운전하는 것처럼 빨리 도착합니다. 라이더의 이동 시간은 여전히 속도 제한에 의해 제한됩니다.
  • 버스가 거의 비어 있지만 도로의 대부분의 차선이 닫히기 때문에 고속도로는 여전히 혼잡합니다. 라이더는 혼잡한 도로에서 거의 비어 있는 버스에 타고 있습니다. 라이더는 앉을 곳을 위해 버스에서 많은 경쟁을하지 않지만, 총 여행 시간은 여전히 외부 트래픽의 나머지 부분에 의해 결정됩니다.
  • 고속도로와 버스가 혼잡하기 때문에 혼잡한 시간입니다. 여행이 더 오래 걸릴뿐만 아니라 사람들이 어깨를 나란히하고 고속도로가 훨씬 낫지 않기 때문에 버스에서 내리는 것은 악몽입니다. 버스(게스트에 논리 프로세서)를 더 추가한다고 해서 더 쉽게 도로에 들어갈 수 있거나 운행이 단축되는 것은 아닙니다.
  • 마지막 시나리오는 비유를 조금 늘릴 수 있지만 버스가 가득 차 있지만 도로가 혼잡하지 않은 곳입니다. 라이더는 여전히 버스에서 내리는 데 어려움을 겪지만 버스가 도로에 있으면 여행이 효율적입니다. 버스(게스트에 논리 프로세서)를 더 추가하면 게스트 성능이 향상되는 유일한 시나리오입니다.

여기에서 도로의 0%사용률과 100%의 사용 상태와 다양한 영향을 미치는 버스의 0%-및 100% 사용 상태 사이에는 여러 가지 시나리오가 있다는 것을 비교적 쉽게 추정할 수 있습니다.

위의 보안 주체를 40% CPU를 호스트 및 게스트에 대한 합리적인 대상으로 적용하는 것은 위와 같은 추론, 큐 양에 대한 합리적인 시작입니다.

부록 B: 다양한 프로세서 속도와 프로세서 전원 관리가 프로세서 속도에 미치는 영향에 대한 고려 사항

프로세서 선택에 대한 섹션 전체에서 프로세서는 데이터가 수집되는 전체 시간 동안 시계 속도의 100%로 실행되고 교체 시스템에는 동일한 속도 프로세서가 있다고 가정합니다. 실제로 두 가정 모두 거짓임에도 불구하고, 특히 기본 전원 계획이 분산된 Windows Server 2008 R2 이상에서는 이 방법론이 여전히 보수적인 접근 방식입니다. 잠재적인 오류 속도가 증가할 수 있지만 프로세서 속도가 증가함에 따라 안전의 여백만 증가합니다.

  • 예를 들어 11.25 CPU가 요구되는 시나리오에서 데이터를 수집할 때 프로세서가 절반 속도로 실행되는 경우 더 정확한 추정치는 5.125 ÷ 2일 수 있습니다.
  • 클록 속도를 두 배로 늘리면 지정된 기간 동안 발생하는 처리 횟수의 두 배가 되도록 보장할 수 없습니다. 이는 프로세서가 RAM 또는 다른 시스템 구성 요소를 기다리는 데 소요되는 시간이 동일하게 유지될 수 있기 때문입니다. 결과적으로 더 빠른 프로세서는 데이터를 가져올 때까지 기다리는 동안 유휴 시간 중 더 많은 시간을 소비할 수 있습니다. 다시 말하지만, 가장 낮은 공통 분모를 고수하고 보수적이며 프로세서 속도 간의 선형 비교를 가정하여 잠재적으로 잘못된 수준의 정확도를 계산하지 않는 것이 좋습니다.

또는 교체 하드웨어의 프로세서 속도가 현재 하드웨어보다 낮으면 비례하여 필요한 프로세서의 예상을 늘리는 것이 안전합니다. 예를 들어 사이트에서 부하를 유지하기 위해 10개의 프로세서가 필요하고 현재 프로세서가 3.3Ghz에서 실행되고 교체 프로세서가 2.6Ghz에서 실행된다는 계산이 있습니다. 이는 21% 속도 감소입니다. 이 경우 12개의 프로세서가 권장되는 크기입니다.

즉, 이러한 가변성은 용량 관리 프로세서 사용률 목표를 변경하지 않습니다. 프로세서 클록 속도가 요구되는 부하에 따라 동적으로 조정되므로 더 높은 부하에서 시스템을 실행하면 CPU가 더 높은 클록 속도 상태에서 더 많은 시간을 소비하는 시나리오가 생성되므로 궁극적인 목표는 최대 100% 클록 속도 상태에서 40% 사용률로 설정됩니다. CPU 속도가 사용량이 적은 시나리오 중에 다시 제한되므로 그보다 작은 값은 전력 절약을 생성합니다.

참고 항목

데이터가 수집되는 동안 프로세서에서 전원 관리를 해제(전원 계획을 고성능으로 설정)하는 옵션이 있습니다. 그러면 대상 서버에서 CPU 사용량을 보다 정확하게 표시할 수 있습니다.

다른 프로세서에 대한 추정치를 조정하기 위해, 위에서 설명한 다른 시스템 병목 상태를 제외하고, 프로세서 속도를 두 배로 늘리면 수행할 수 있는 처리량이 두 배로 증가했다고 가정하는 것이 안전했습니다. 오늘날 프로세서의 내부 아키텍처는 프로세서 간에 충분히 다르며, 데이터보다 다른 프로세서를 사용하는 효과를 측정하는 더 안전한 방법은 표준 성능 평가 공사의 SPECint_rate2006 벤치마크를 활용하는 것입니다.

  1. 사용 중인 프로세서와 사용할 계획에 대한 SPECint_rate2006 점수를 찾습니다.

    1. 표준 성능 평가 회사의 웹 사이트에서 결과를 선택하고, CPU2006 강조 표시하고, 모든 SPECint_rate2006 결과 검색을 선택합니다.
    2. 단순 요청에서 대상 프로세서의 검색 조건(예: 프로세서 일치 E5-2630(baselinetarget) 및 프로세서 일치 E5-2650(기준)을 입력합니다.
    3. 사용할 서버 및 프로세서 구성(또는 정확히 일치하는 항목을 사용할 수 없는 경우 가까운 구성)을 찾아 결과 및 # 코어 열의 값을 확인합니다.

  2. 한정자를 확인하려면 다음 수식을 사용합니다.

    ((대상 플랫폼 코어당 점수 값) ×(기준 플랫폼의 코어당 MHz)) ÷((코어당 기준 점수 값) ×(대상 플랫폼의 코어당 MHz))

    위의 예제 사용:

    (35.83 × 2000) ÷ (33.75 × 2300) = 0.92

  3. 예상 프로세서 수와 한정자를 곱합니다. 위의 경우 E5-2650 프로세서에서 E5-2630 프로세서로 이동하려면 계산된 11.25 CPU × 0.92 = 10.35 프로세서를 곱합니다.

부록 C: 스토리지와 상호 작용하는 운영 체제에 대한 기본 사항

응답 시간에 설명된 큐 이론 개념/시스템 사용량이 성능 에 미치는 영향도 스토리지에 적용할 수 있습니다. 이러한 개념을 적용하려면 운영 체제에서 I/O를 처리하는 방법을 숙지해야 합니다. Microsoft Windows 운영 체제에서는 각 실제 디스크에 대해 I/O 요청을 보관하는 큐가 만들어집니다. 그러나 실제 디스크에 대한 설명이 필요합니다. 배열 컨트롤러 및 SAN은 운영 체제에 대한 스핀들의 집계를 단일 물리적 디스크로 제공합니다. 또한 배열 컨트롤러와 SAN은 여러 디스크를 하나의 배열 집합으로 집계한 다음 이 배열 집합을 여러 "파티션"으로 분할하여 운영 체제에 여러 실제 디스크로 표시할 수 있습니다(참조 그림).

Block spindles

이 그림에서 두 스핀들은 미러 데이터 스토리지(데이터 1 및 데이터 2)에 대한 논리 영역으로 분할됩니다. 이러한 논리 영역은 운영 체제에서 별도의 실제 디스크로 볼 수 있습니다.

이는 매우 혼란스러울 수 있지만 다음 용어는 이 부록 전체에서 다른 엔터티를 식별하는 데 사용됩니다.

  • Spindle - 서버에 물리적으로 설치된 디바이스입니다.
  • 배열 – 컨트롤러에 의해 집계된 스핀들의 컬렉션입니다.
  • 배열 파티션 – 집계된 배열의 분할
  • LUN – SAN을 참조할 때 사용되는 배열입니다.
  • 디스크 – 운영 체제가 단일 실제 디스크로 관찰하는 항목입니다.
  • 파티션 – 운영 체제가 실제 디스크로 인식하는 내용의 논리적 분할입니다.

운영 체제 아키텍처 고려 사항

운영 체제는 관찰되는 각 디스크에 대해 FIFO(선입선출) I/O 큐를 만듭니다. 이 디스크는 스핀들, 배열 또는 배열 파티션을 나타낼 수 있습니다. 운영 체제 관점에서 I/O 처리와 관련하여 활성 큐가 많을수록 더 좋습니다. FIFO 큐가 직렬화되므로 스토리지 하위 시스템에 발급된 모든 I/O는 요청이 도착한 순서대로 처리되어야 합니다. 운영 체제에서 관찰한 각 디스크를 스핀들/배열과 상호 연결함으로써 운영 체제는 이제 각 고유한 디스크 집합에 대한 I/O 큐를 기본 때문에 디스크 간에 부족한 I/O 리소스에 대한 경합을 제거하고 I/O 수요를 단일 디스크로 격리합니다. 예외로, Windows Server 2008은 I/O 우선 순위의 개념을 도입하고, "낮은" 우선 순위를 사용하도록 설계된 애플리케이션은 이 일반 순서에서 벗어나 뒷좌석을 차지합니다. "낮음" 우선 순위 기본값을 "보통"으로 활용하도록 특별히 코딩되지 않은 애플리케이션

간단한 스토리지 하위 시스템 소개

간단한 예제(컴퓨터 내의 단일 하드 드라이브)부터 구성 요소별 분석이 제공됩니다. 이를 주요 스토리지 하위 시스템 구성 요소로 구분하면 시스템은 다음으로 구성됩니다.

  • 1 – 10,000 RPM 초고속 SCSI HD(초고속 SCSI의 전송 속도는 20MB/초)
  • 1 – SCSI 버스(케이블)
  • 1 – 초고속 SCSI 어댑터
  • 1 ~ 32비트 33MHz PCI 버스

구성 요소가 식별되면 시스템을 전송할 수 있는 데이터의 양 또는 처리할 수 있는 I/O의 양을 계산할 수 있습니다. I/O의 양과 시스템을 전송할 수 있는 데이터의 양은 상관 관계가 있지만 동일하지는 않습니다. 이 상관 관계는 디스크 I/O가 임의인지 순차적인지 여부와 블록 크기에 따라 달라집니다. (모든 데이터는 블록으로 디스크에 기록되지만 다른 블록 크기를 사용하는 애플리케이션은 다릅니다.) 구성 요소별로 다음을 수행합니다.

  • 하드 드라이브 – 평균 10,000RPM 하드 드라이브에는 7밀리초(밀리초) 검색 시간과 3ms의 액세스 시간이 있습니다. 검색 시간은 읽기/쓰기 헤드가 플래터의 위치로 이동하는 데 걸리는 평균 시간입니다. 액세스 시간은 헤드가 올바른 위치에 있으면 디스크에 데이터를 읽거나 쓰는 데 걸리는 평균 시간입니다. 따라서 10,000-RPM HD에서 고유한 데이터 블록을 읽는 평균 시간은 데이터 블록당 총 약 10ms(또는 .010초)에 대한 검색 및 액세스를 구성합니다.

    모든 디스크 액세스에서 헤드를 디스크의 새 위치로 이동해야 하는 경우 읽기/쓰기 동작을 "임의"라고 합니다. 따라서 모든 I/O가 임의인 경우 10,000-RPM HD는 IOPS(초당 약 100 I/O)를 처리할 수 있습니다(수식은 초당 1000ms로 I/O당 10ms 또는 1000/10=100 IOPS로 나뉩니다).

    또는 모든 I/O가 HD의 인접 섹터에서 발생하는 경우 이를 순차 I/O라고 합니다. 첫 번째 I/O가 완료되면 읽기/쓰기 헤드가 다음 데이터 블록이 HD에 저장되는 시작 부분에 있기 때문에 순차 I/O에는 검색 시간이 없습니다. 따라서 10,000-RPM HD는 초당 약 333개의 I/O를 처리할 수 있습니다(초당 1000ms를 I/O당 3ms로 나눈 값).

    참고 항목

    이 예제에서는 한 실린더의 데이터가 일반적으로 유지되는 디스크 캐시를 반영하지 않습니다. 이 경우 첫 번째 I/O에 10ms가 필요하며 디스크는 전체 실린더를 읽습니다. 다른 모든 순차 I/O는 캐시에서 충족됩니다. 따라서 디스크 내 캐시는 순차 I/O 성능을 향상시킬 수 있습니다.

    지금까지 하드 드라이브의 전송 속도는 관련이 없습니다. 하드 드라이브가 20MB/s Ultra Wide 또는 Ultra3 160MB/s이든 관계없이 10,000-RPM HD에서 처리할 수 있는 실제 IOPS 양은 최대 100개 임의 또는 ~300 순차 I/O입니다. 드라이브에 쓰는 애플리케이션에 따라 블록 크기가 변경되면 I/O당 끌어오는 데이터의 양이 다릅니다. 예를 들어 블록 크기가 8KB인 경우 총 800KB의 하드 드라이브에서 100개의 I/O 작업을 읽거나 하드 드라이브에 씁니다. 그러나 블록 크기가 32KB인 경우 100 I/O는 하드 드라이브에 3,200KB(3.2MB)를 읽고 씁니다. SCSI 전송 속도가 전송되는 총 데이터 양을 초과하는 경우 "더 빠른" 전송 속도 드라이브를 얻는 것은 아무 것도 얻지 않습니다. 비교는 다음 표를 참조하세요.

    설명 7200 RPM 9ms 검색, 4ms 액세스 10,000 RPM 7ms 검색, 3ms 액세스 15,000 RPM 4ms 검색, 2ms 액세스
    임의 I/O 80 100 150
    순차 I/O 250 300 500
    10,000 RPM 드라이브 8KB 블록 크기(Active Directory Jet)
    임의 I/O 800KB/s
    순차 I/O 2400KB/s

  • SCSI 백플레인(버스) – "SCSI 백플레인(버스)" 또는 이 시나리오에서 리본 케이블이 스토리지 하위 시스템의 처리량에 미치는 영향을 이해하는 방법은 블록 크기에 대한 지식에 따라 달라집니다. 기본적으로 문제는 I/O가 8KB 블록에 있는 경우 버스에서 처리할 수 있는 I/O의 양입니다. 이 시나리오에서 SCSI 버스는 20MB/s 또는 20480KB/s입니다. 20480KB/s를 8KB 블록으로 나눈 값은 SCSI 버스에서 지원하는 최대 약 2500 IOPS를 생성합니다.

    참고 항목

    다음 표의 그림은 예를 나타냅니다. 대부분의 연결된 스토리지 디바이스는 현재 훨씬 더 높은 처리량을 제공하는 PCI Express를 사용합니다.

    블록 크기당 SCSI 버스에서 지원하는 I/O 2KB 블록 크기 8KB 블록 크기(AD Jet)(SQL Server 7.0/SQL Server 2000)
    20MB/s 10,000 2,500
    40MB/s 20,000 5,000
    128MB/s 65,536 16,384
    320MB/s 160,000 40,000

    이 차트에서 확인할 수 있듯이, 제공된 시나리오에서 스핀들 최대값은 위의 임계값보다 훨씬 낮은 100 I/O이므로 버스는 병목 현상이 발생하지 않습니다.

    참고 항목

    SCSI 버스가 100% 효율적이라고 가정합니다.

  • SCSI 어댑터 – 처리할 수 있는 I/O의 양을 확인하려면 제조업체의 사양을 검사 합니다. I/O 요청을 적절한 디바이스로 전달하려면 일종의 처리가 필요하므로 처리할 수 있는 I/O의 양은 SCSI 어댑터(또는 배열 컨트롤러) 프로세서에 따라 달라집니다.

    이 예제에서는 1,000 I/O를 처리할 수 있다고 가정합니다.

  • PCI 버스 – 종종 간과되는 구성 요소입니다. 이 예제에서는 병목 상태가 아닙니다. 그러나 시스템이 강화되면 병목 상태가 될 수 있습니다. 참고로, 33Mhz에서 작동하는 32비트 PCI 버스는 이론적으로 133MB/s의 데이터를 전송할 수 있습니다. 다음은 수식입니다.

    32비트 ÷ 바이트당 8비트 × 33MHz = 133MB/s입니다.

    이론적 한계입니다. 실제로는 최대값의 약 50%만 실제로 도달하지만 특정 버스트 시나리오에서는 짧은 기간 동안 75%의 효율성을 얻을 수 있습니다.

    66Mhz 64비트 PCI 버스는 이론적 최대값(바이트당 64비트 ÷ 8비트× 66Mhz) = 528MB/초를 지원할 수 있습니다. 또한 다른 모든 디바이스(예: 네트워크 어댑터, 두 번째 SCSI 컨트롤러 등)는 대역폭이 공유되고 디바이스가 제한된 리소스에 대해 경합할 때 사용할 수 있는 대역폭을 줄입니다.

이 스토리지 하위 시스템의 구성 요소를 분석한 후 스핀들은 요청할 수 있는 I/O의 양을 제한하는 요소이며, 결과적으로 시스템을 전송할 수 있는 데이터의 양입니다. 특히 AD DS 시나리오에서는 Jet 데이터베이스에 액세스할 때 초당 총 800KB에 대해 8KB 단위로 초당 100개의 임의 I/O입니다. 또는 로그 파일에 독점적으로 할당된 스핀들의 최대 처리량은 초당 총 2,400KB(2.4MB)에 대해 8KB 단위로 초당 300개의 순차 I/O 제한 사항을 겪게 됩니다.

이제 간단한 구성을 분석한 후 다음 표에서는 스토리지 하위 시스템의 구성 요소가 변경되거나 추가될 때 병목 현상이 발생하는 위치를 보여 줍니다.

주의 병목 상태 분석 디스크 버스 어댑터 PCI 버스
두 번째 디스크를 추가한 후 기본 컨트롤러 구성입니다. 디스크 구성은 800KB/s의 병목 상태를 나타냅니다. 디스크 1개 추가(Total=2)

I/O는 임의입니다.

4KB 블록 크기

10,000 RPM HD

 총 200 I/O
총 800KB/s
7개의 디스크를 추가한 후에도 디스크 구성은 여전히 3,200KB/s의 병목 상태를 나타냅니다. 디스크 7개 추가(합계=8)

I/O는 임의입니다.

4KB 블록 크기

10,000 RPM HD

 총 800 I/O.
총 3,200KB/s
I/O를 순차적으로 변경한 후 네트워크 어댑터는 1000 IOPS로 제한되므로 병목 상태가 됩니다. 디스크 7개 추가(합계=8)

I/O는 순차적입니다.

4KB 블록 크기

10,000 RPM HD

 디스크에 2400 I/O 초를 읽고 쓸 수 있으며 컨트롤러는 1000 IOPS로 제한됩니다.
네트워크 어댑터를 10,000 IOPS를 지원하는 SCSI 어댑터로 바꾼 후 병목 현상이 디스크 구성으로 돌아갑니다. 디스크 7개 추가(합계=8)

I/O는 임의입니다.

4KB 블록 크기

10,000 RPM HD

SCSI 어댑터 업그레이드(현재 10,000 I/O 지원)

 총 800 I/O.
총 3,200KB/s
블록 크기를 32KB로 늘리면 버스는 20MB/s만 지원하므로 병목 상태가 됩니다. 디스크 7개 추가(합계=8)

I/O는 임의입니다.

32KB 블록 크기

10,000 RPM HD

 총 800 I/O. 디스크에 25,600KB/s(25MB/s)를 읽고 쓸 수 있습니다.

버스는 20MB/s만 지원합니다.
버스를 업그레이드하고 디스크를 더 추가하면 디스크가 병목 상태를 다시 기본. 13개의 디스크 추가(Total=14)

디스크가 14개인 두 번째 SCSI 어댑터 추가

I/O는 임의입니다.

4KB 블록 크기

10,000 RPM HD

320MB/s SCSI 버스로 업그레이드

 2800 I/O

11,200KB/s(10.9MB/s)
I/O를 순차적으로 변경한 후 디스크가 병목 상태를 다시 기본. 13개의 디스크 추가(Total=14)

디스크가 14개인 두 번째 SCSI 어댑터 추가

I/O는 순차적입니다.

4KB 블록 크기

10,000 RPM HD

320MB/s SCSI 버스로 업그레이드

 8,400 I/O

33,600KB\s

(32.8 MB\s)
더 빠른 하드 드라이브를 추가한 후 디스크가 병목 상태를 다시 기본. 13개의 디스크 추가(Total=14)

디스크가 14개인 두 번째 SCSI 어댑터 추가

I/O는 순차적입니다.

4KB 블록 크기

15,000 RPM HD

320MB/s SCSI 버스로 업그레이드

 14,000 I/O

56,000KB/s

(54.7MB/s)
블록 크기를 32KB로 늘리면 PCI 버스가 병목 상태가 됩니다. 13개의 디스크 추가(Total=14)

디스크가 14개인 두 번째 SCSI 어댑터 추가

I/O는 순차적입니다.

32KB 블록 크기

15,000 RPM HD

320MB/s SCSI 버스로 업그레이드

 14,000 I/O

448,000KB/s

(437MB/s)는 스핀들 읽기/쓰기 제한입니다.

PCI 버스는 이론적 최대 133MB/s(최대 75%의 효율)를 지원합니다.

RAID 소개

스토리지 하위 시스템의 특성은 배열 컨트롤러가 도입될 때 크게 변경되지 않습니다. 계산에서 SCSI 어댑터를 바꿉니다. 변경되는 내용은 다양한 배열 수준(예: RAID 0, RAID 1 또는 RAID 5)을 사용할 때 디스크에 데이터를 읽고 쓰는 비용입니다.

RAID 0에서 데이터는 RAID 집합의 모든 디스크에 걸쳐 스트라이프됩니다. 즉, 읽기 또는 쓰기 작업 중에 데이터의 일부를 각 디스크에서 가져오거나 푸시하여 같은 기간 동안 시스템을 전송할 수 있는 데이터의 양이 증가합니다. 따라서 각 스핀들(다시 10,000-RPM 드라이브로 가정)에서 1초 안에 100개의 I/O 작업을 수행할 수 있습니다. 지원될 수 있는 총 I/O 양은 스핀들당 초당 100 I/O의 N 스핀들(초당 100*N I/O를 생성)입니다.

Logical d: drive

RAID 1에서 데이터는 중복성을 위해 한 쌍의 스핀들 간에 미러(중복)됩니다. 따라서 읽기 I/O 작업이 수행되면 집합의 두 스핀들에서 데이터를 읽을 수 있습니다. 이렇게 하면 읽기 작업 중에 두 디스크의 I/O 용량을 효과적으로 사용할 수 있습니다. 주의할 점은 쓰기 작업이 RAID 1에서 성능 이점을 얻지 않는다는 것입니다. 중복성을 위해 두 드라이브에 동일한 데이터를 기록해야 하기 때문입니다. 두 스핀들 모두에서 데이터 쓰기가 동시에 발생하므로 더 이상 걸리지 않지만 두 스핀들 모두 데이터를 복제하는 데 사용되므로 기본적으로 쓰기 I/O 작업을 수행하면 두 개의 읽기 작업이 발생하지 않습니다. 따라서 모든 쓰기 I/O는 두 개의 읽기 I/O 비용이 듭니다. 해당 정보에서 수식을 만들어 발생하는 총 I/O 작업 수를 확인할 수 있습니다.

읽기 I/O + 2 × 사용 가능한 총 사용 가능한 디스크 I/O = 쓰기

쓰기에 대한 읽기 비율과 스핀들 수를 알 수 있는 경우 다음 수식은 위의 수식에서 파생되어 배열에서 지원될 수 있는 최대 I/O를 식별할 수 있습니다.

스핀들 당 최대 IOPS × 2개의 스핀들 × [(%Reads + %Writes) ÷(%Reads + 2× %Writes)] = 총 IOPS

RAID 1+ 0은 읽기 및 쓰기 비용과 관련하여 RAID 1과 정확히 동일하게 동작합니다. 그러나 이제 I/O가 각 미러 집합에 걸쳐 스트라이프됩니다. If

스핀들 당 최대 IOPS × 2개의 스핀들 × [(%Reads + %Writes) ÷(%Reads + 2× %Writes)] = 총 I/O

RAID 1 집합에서 RAID 1 집합의 곱하기(N)가 스트라이프되면 처리할 수 있는 총 I/O는 RAID 1 집합당 N × I/O가 됩니다.

N × {스핀들 당 최대 IOPS × 2개의 스핀들 × [(%Reads + %Writes) ÷ (%Reads + 2× %Writes)] } = Total IOPS

RAID 5에서 N + 1 RAID라고도 하는 경우 데이터는 N 스핀들에서 스트라이프되고 패리티 정보는 "+ 1" 스핀들로 기록됩니다. 그러나 RAID 5는 RAID 1 또는 1 + 0보다 쓰기 I/O를 수행하는 경우 훨씬 더 비쌉니다. RAID 5는 쓰기 I/O가 배열에 제출될 때마다 다음 프로세스를 수행합니다.

  1. 이전 데이터 읽기
  2. 이전 패리티 읽기
  3. 새 데이터 작성
  4. 새 패리티 작성

운영 체제에서 배열 컨트롤러에 제출하는 모든 쓰기 I/O 요청을 완료하려면 4개의 I/O 작업이 필요하므로 제출된 쓰기 요청은 단일 읽기 I/O만큼 완료하는 데 4배가 걸립니다. 운영 체제 관점에서 I/O 요청을 스핀들이 경험하는 것으로 변환하는 수식을 파생하려면 다음을 수행합니다.

읽기 I/O + 4 × 쓰기 I/O = 총 I/O

마찬가지로 RAID 1 집합에서 쓰기에 대한 읽기 비율과 스핀들 수가 알려지면 위의 수식에서 다음 수식을 파생하여 배열에서 지원될 수 있는 최대 I/O를 식별할 수 있습니다(총 스핀들 수에는 패리티로 손실된 "드라이브"가 포함되지 않음).

스핀들 당 IOPS ×(Spindles – 1) × [(%Reads + %Writes) ÷ (%Reads + 4 × %Writes)] = Total IOPS

SAN 소개

SAN이 환경에 도입될 때 스토리지 하위 시스템의 복잡성을 확장하면 설명된 기본 원칙은 변경되지 않습니다. 그러나 SAN에 연결된 모든 시스템에 대한 I/O 동작을 고려해야 합니다. SAN을 사용할 때의 주요 이점 중 하나는 내부 또는 외부에 연결된 스토리지에 비해 추가적인 중복성이므로 이제 용량 계획은 내결함성 요구 사항을 고려해야 합니다. 또한 평가해야 하는 더 많은 구성 요소가 도입되었습니다. SAN을 구성 요소 부분으로 분해:

  • SCSI 또는 파이버 채널 하드 드라이브
  • 스토리지 단위 채널 백플레인
  • 스토리지 단위
  • 스토리지 컨트롤러 모듈
  • SAN 스위치(es)
  • HBA
  • PCI 버스

중복성을 위해 시스템을 디자인할 때 오류 가능성을 수용하기 위해 추가 구성 요소가 포함됩니다. 용량 계획 시 사용 가능한 리소스에서 중복 구성 요소를 제외하는 것이 매우 중요합니다. 예를 들어 SAN에 두 개의 컨트롤러 모듈이 있는 경우 한 컨트롤러 모듈의 I/O 용량은 시스템에서 사용할 수 있는 총 I/O 처리량에 사용해야 합니다. 이는 하나의 컨트롤러가 실패하는 경우 연결된 모든 시스템에서 요구하는 전체 I/O 부하를 다시 기본 컨트롤러에서 처리해야 하기 때문입니다. 최대 사용 기간 동안 모든 용량 계획이 수행되므로 중복 구성 요소는 사용 가능한 리소스에 고려되지 않아야 하며 계획된 최대 사용률은 버스트 또는 비정상적인 시스템 동작을 수용하기 위해 시스템의 80% 포화를 초과해서는 안 됩니다. 마찬가지로 중복 SAN 스위치, 스토리지 단위 및 스핀들은 I/O 계산에 고려해서는 안 됩니다.

SCSI 또는 파이버 채널 하드 드라이브의 동작을 분석할 때 이전에 설명한 대로 동작을 분석하는 방법은 변경되지 않습니다. 각 프로토콜에 대한 특정 장점과 단점이 있지만 디스크당 제한 요소는 하드 드라이브의 기계적 제한입니다.

스토리지 단위에서 채널을 분석하는 것은 SCSI 버스에서 사용할 수 있는 리소스를 계산하거나 블록 크기(예: 8KB)로 나눈 대역폭(예: 20MB/s)을 계산하는 것과 정확히 동일합니다. 이전의 간단한 예제에서 벗어나는 위치는 여러 채널의 집계에 있습니다. 예를 들어 6개 채널이 있는 경우 각각 20MB/s의 최대 전송 속도를 지원하며, 사용 가능한 총 I/O 및 데이터 전송량은 100MB/s입니다(정답입니다. 120MB/s 아님). 다시 말하지만, 내결함성은 이 계산의 주요 플레이어이며, 전체 채널이 손실되는 경우 시스템은 5개의 작동 채널만 남습니다. 따라서 오류 발생 시 성능 기대치를 계속 충족하려면 모든 스토리지 채널의 총 처리량이 100MB/s를 초과하지 않아야 합니다(부하 및 내결함성이 모든 채널에 균등하게 분산되어 있다고 가정함). 이를 I/O 프로필로 전환하는 것은 애플리케이션의 동작에 따라 달라집니다. Active Directory Jet I/O의 경우 초당 약 12,500 I/O(I/O당 100MB/s ÷ 8KB)와 상관 관계가 있습니다.

다음으로, 각 모듈이 지원할 수 있는 처리량을 이해하려면 컨트롤러 모듈에 대한 제조업체의 사양을 가져와야 합니다. 이 예제에서 SAN에는 각각 7,500 I/O를 지원하는 두 개의 컨트롤러 모듈이 있습니다. 중복성을 원하지 않는 경우 시스템의 총 처리량은 15,000 IOPS일 수 있습니다. 오류 발생 시 최대 처리량을 계산할 때 제한 사항은 하나의 컨트롤러 또는 7,500 IOPS의 처리량입니다. 이 임계값은 모든 스토리지 채널에서 지원될 수 있는 12,500 IOPS(4KB 블록 크기 가정) 최대값보다 훨씬 낮으므로 현재 분석에서 병목 현상이 발생합니다. 계획 목적으로도 계획할 수 있는 최대 I/O는 10,400 I/O입니다.

데이터가 컨트롤러 모듈을 종료하면 1GB/s(또는 초당 1기가비트)로 평가된 파이버 채널 연결을 전송합니다. 이를 다른 메트릭과 상호 연결하기 위해 1GB/s는 128MB/s(1GB/s ÷ 8비트/바이트)로 바뀝니다. 이는 스토리지 단위(100MB/s)의 모든 채널에서 총 대역폭을 초과하기 때문에 시스템에서 병목 상태가 되지 않습니다. 또한 이는 두 채널 중 하나(중복성을 위한 추가 1GB/s 파이버 채널 연결) 중 하나이기 때문에 한 연결이 실패할 경우 다시 기본 연결은 여전히 필요한 모든 데이터 전송을 처리할 수 있는 충분한 용량을 갖습니다.

서버로 이동하는 동안 데이터는 SAN 스위치를 전송할 가능성이 높습니다. SAN 스위치는 들어오는 I/O 요청을 처리하고 적절한 포트를 전달해야 하므로 스위치는 처리할 수 있는 I/O의 양에 제한이 있지만 제조업체 사양은 해당 제한을 결정하는 데 필요합니다. 예를 들어 두 개의 스위치가 있고 각 스위치가 10,000 IOPS를 처리할 수 있는 경우 총 처리량은 20,000 IOPS가 됩니다. 다시 말하지만, 내결함성은 하나의 스위치가 실패할 경우 시스템의 총 처리량은 10,000 IOPS가 됩니다. 정상 작동 시 사용률이 80%를 초과하지 않도록 하려면 8000 I/O를 초과하지 않는 것이 목표여야 합니다.

마지막으로, 서버에 설치된 HBA는 처리할 수 있는 I/O의 양에도 제한이 있습니다. 일반적으로 두 번째 HBA는 중복성을 위해 설치되지만 SAN 스위치와 마찬가지로 처리할 수 있는 최대 I/O를 계산할 때 N - 1 HBA의 총 처리량은 시스템의 최대 확장성입니다.

캐싱 고려 사항

캐시는 스토리지 시스템의 모든 지점에서 전반적인 성능에 큰 영향을 미칠 수 있는 구성 요소 중 하나입니다. 캐싱 알고리즘에 대한 자세한 분석은 이 문서의 범위를 벗어납니다. 그러나 디스크 하위 시스템의 캐싱에 대한 몇 가지 기본 문은 다음을 조명할 가치가 있습니다.

  • 캐싱은 더 큰 I/O 블록으로 많은 작은 쓰기 작업을 버퍼링하고 더 적지만 더 큰 블록 크기로 스토리지로 단계 해제할 수 있으므로 지속적인 순차 쓰기 I/O를 향상합니다. 이렇게 하면 총 임의 I/O 및 총 순차 I/O가 감소하므로 다른 I/O에 더 많은 리소스 가용성을 제공합니다.

  • 캐싱은 스토리지 하위 시스템의 지속적인 쓰기 I/O 처리량을 향상시키지 않습니다. 스핀들에서 데이터를 커밋할 수 있을 때까지 쓰기만 버퍼링할 수 있습니다. 스토리지 하위 시스템에 있는 스핀들의 사용 가능한 모든 I/O가 장기간 포화되면 캐시가 결국 채워집니다. 캐시를 비우려면 캐시를 플러시할 수 있도록 충분한 I/O를 제공하기 위해 버스트 또는 추가 스핀들 사이에 충분한 시간을 할당해야 합니다.

    캐시가 클수록 더 많은 데이터만 버퍼링할 수 있습니다. 즉, 포화 기간이 길어질 수 있습니다.

    일반적으로 작동하는 스토리지 하위 시스템에서는 데이터를 캐시에 기록하기만 하면 되므로 운영 체제에서 쓰기 성능이 향상됩니다. 기본 미디어가 I/O로 포화되면 캐시가 채워지고 쓰기 성능이 디스크 속도로 돌아갑니다.

  • 읽기 I/O를 캐싱할 때 캐시가 가장 유리한 시나리오는 데이터가 디스크에 순차적으로 저장되고 캐시가 미리 읽을 수 있는 경우입니다(다음 섹터에 다음에 요청될 데이터가 포함되어 있다고 가정함).

  • 읽기 I/O가 임의인 경우 드라이브 컨트롤러에서 캐싱하면 디스크에서 읽을 수 있는 데이터의 양이 향상되지 않을 수 있습니다. 운영 체제 또는 애플리케이션 기반 캐시 크기가 하드웨어 기반 캐시 크기보다 큰 경우 향상된 기능은 존재하지 않습니다.

    Active Directory의 경우 캐시는 RAM 양에 의해서만 제한됩니다.

SSD 고려 사항

SSD는 스핀들 기반 하드 디스크와 완전히 다른 동물입니다. 그러나 두 가지 주요 조건은 "처리할 수 있는 IOPS 수기본입니다. 및 "해당 IOPS의 대기 시간은 무엇인가요?" SSD는 스핀들 기반 하드 디스크에 비해 더 많은 I/O 볼륨을 처리할 수 있으며 대기 시간이 짧을 수 있습니다. 일반적으로 이 글을 쓰는 시점에서 SSD는 기가바이트당 비용 비교에서 여전히 비용이 많이 들지만 I/O당 비용 측면에서 매우 저렴하며 스토리지 성능 측면에서 상당한 고려를 받을 자격이 있습니다.

고려 사항:

  • IOPS와 대기 시간 모두 제조업체 설계에 매우 주관적이며 경우에 따라 스핀들 기반 기술보다 성능이 저하되는 것으로 관찰되었습니다. 요컨대, 드라이브로 제조업체 사양 드라이브를 검토하고 유효성을 검사하고 일반성을 가정하지 않는 것이 더 중요합니다.
  • IOPS 형식은 읽기 또는 쓰기 여부에 따라 매우 다른 숫자를 가질 수 있습니다. 일반적으로 주로 읽기 기반인 AD DS 서비스는 다른 애플리케이션 시나리오보다 영향을 덜 받습니다.
  • "쓰기 지구력" – SSD 셀이 결국 마모되는 개념입니다. 다양한 제조업체가 이 과제를 다양한 방식으로 처리합니다. 적어도 데이터베이스 드라이브의 경우 주로 읽는 I/O 프로필을 사용하면 데이터가 매우 휘발성이 아니기 때문에 이 문제의 중요성을 다운플레이할 수 있습니다.

요약

스토리지에 대해 생각하는 한 가지 방법은 가정용 배관을 그리는 것입니다. 데이터가 저장되는 미디어의 IOPS가 드레이닝할 기본 가정이라고 가정해 보겠습니다. 이 작업이 막히거나(예: 파이프의 뿌리) 제한되거나(축소되거나 너무 작음) 너무 많은 물을 사용할 때 가정의 모든 싱크대가 백업됩니다(게스트가 너무 많음). 이는 하나 이상의 시스템이 동일한 기본 미디어를 사용하여 SAN/NAS/iSCSI의 공유 스토리지를 활용하는 공유 환경과 완벽하게 유사합니다. 다양한 시나리오를 해결하기 위해 다양한 방법을 사용할 수 있습니다.

  • 축소되거나 크기가 작은 드레이닝에는 본격적인 교체 및 수정이 필요합니다. 이는 인프라 전체에서 공유 스토리지를 사용하여 새 하드웨어를 추가하거나 시스템을 재배포하는 것과 비슷합니다.
  • "막힌" 파이프는 일반적으로 하나 이상의 잘못된 문제를 식별하고 해당 문제를 제거하는 것을 의미합니다. 스토리지 시나리오에서는 스토리지 또는 시스템 수준 백업, 모든 서버에서 동기화된 바이러스 백신 검사 및 사용량이 많은 기간 동안 실행되는 동기화된 조각 모음 소프트웨어일 수 있습니다.

모든 배관 설계에서 여러 배수구는 기본 드레이닝에 공급됩니다. 그 배수구 나 접합점 중 하나를 중지하는 경우, 그 접합 지점 뒤에있는 것들만 백업합니다. 스토리지 시나리오에서는 오버로드된 스위치(SAN/NAS/iSCSI 시나리오), 드라이버 호환성 문제(잘못된 드라이버/HBA Firmware/storport.sys 조합) 또는 백업/바이러스 백신/조각 모음일 수 있습니다. 스토리지 "파이프"가 충분히 큰지 확인하려면 IOPS 및 I/O 크기를 측정해야 합니다. 각 관절에서 적절한 "파이프 직경"을 보장하기 위해 함께 추가합니다.

부록 D - 스토리지 문제 해결에 대한 토론 - 데이터베이스 크기만큼 RAM을 제공하는 것이 실행 가능한 옵션이 아닌 환경

스토리지 기술의 변화를 수용할 수 있도록 이러한 권장 사항이 존재하는 이유를 이해하는 것이 유용합니다. 이러한 권장 사항은 두 가지 이유로 존재합니다. 첫 번째는 운영 체제 스핀들의 성능 문제(즉, 페이징)가 데이터베이스 및 I/O 프로필의 성능에 영향을 주지 않도록 IO를 격리하는 것입니다. 두 번째는 AD DS(및 대부분의 데이터베이스)에 대한 로그 파일은 본질적으로 순차적이며, 운영 체제의 임의 I/O 패턴과 AD DS 데이터베이스 드라이브의 거의 순수한 임의 I/O 패턴에 비해 스핀들 기반 하드 드라이브 및 캐시는 순차 I/O와 함께 사용할 때 큰 성능 이점이 있다는 것입니다. 순차 I/O를 별도의 실제 드라이브로 격리하면 처리량을 늘릴 수 있습니다. 오늘날의 스토리지 옵션에서 제시하는 과제는 이러한 권장 사항의 기본 가정이 더 이상 사실이 없다는 것입니다. iSCSI, SAN, NAS 및 Virtual Disk 이미지 파일과 같은 많은 가상화된 스토리지 시나리오에서 기본 스토리지 미디어는 여러 호스트에서 공유되므로 "IO 격리"와 "순차 I/O 최적화" 측면을 모두 완전히 부정합니다. 실제로 이러한 시나리오는 공유 미디어에 액세스하는 다른 호스트가 do기본 컨트롤러에 대한 응답성을 저하시킬 수 있다는 점에서 복잡성을 더합니다.

스토리지 성능을 계획할 때는 콜드 캐시 상태, 웜 캐시 상태, 백업/복원의 세 가지 범주를 고려해야 합니다. 콜드 캐시 상태는 do기본 컨트롤러가 처음 다시 부팅되거나 Active Directory 서비스가 다시 시작되고 RAM에 Active Directory 데이터가 없는 경우와 같은 시나리오에서 발생합니다. 웜 캐시 상태는 do기본 컨트롤러가 안정적인 상태이며 데이터베이스가 캐시되는 위치입니다. 이는 매우 다른 성능 프로필을 구동하므로 주의해야 하며, 전체 데이터베이스를 캐시하기에 충분한 RAM이 있으면 캐시가 콜드일 때 성능에 도움이 되지 않습니다. 콜드 캐시를 따뜻하게 하는 것은 "스프린트"이고 웜 캐시가 있는 서버를 실행하는 것은 "marathon"입니다.

콜드 캐시 및 웜 캐시 시나리오의 경우 스토리지가 디스크에서 메모리로 데이터를 얼마나 빨리 이동할 수 있는지가 궁금합니다. 캐시를 따뜻하게 하는 것은 시간이 지남에 따라 더 많은 쿼리가 데이터를 재사용하고, 캐시 적중률이 증가하고, 디스크로 이동해야 하는 빈도가 감소함에 따라 성능이 향상되는 시나리오입니다. 결과적으로 디스크로 이동할 때의 성능 저하 영향이 감소합니다. 성능 저하는 캐시가 따뜻해지고 시스템 종속 허용 최대 크기로 증가할 때까지 기다리는 동안에만 일시적입니다. 대화는 디스크에서 데이터를 얼마나 빨리 가져올 수 있는지로 단순화할 수 있으며, 기본 스토리지에서 사용할 수 있는 IOPS를 주관하는 Active Directory에서 사용할 수 있는 IOPS의 간단한 측정값입니다. 계획 관점에서 볼 때, 캐시 및 백업/복원 시나리오를 따뜻하게 하는 것은 예외적으로 발생하고, 일반적으로 근무 시간 외에 발생하며, DC의 부하에 주관적이기 때문에 이러한 활동이 사용량이 적은 시간에 예약된다는 점을 제외하고는 일반적인 권장 사항이 존재하지 않습니다.

대부분의 시나리오에서 AD DS는 주로 읽기 IO이며, 일반적으로 읽기/쓰기 비율은 90%입니다. 읽기 I/O는 종종 사용자 환경의 병목 현상인 경향이 있으며, 쓰기 IO를 사용하면 쓰기 성능이 저하됩니다. NTDS.dit에 대한 I/O는 주로 임의이므로 캐시는 IO를 읽는 데 최소한의 이점을 제공하는 경향이 있으므로 읽기 I/O 프로필을 위해 스토리지를 올바르게 구성하는 것이 훨씬 더 중요합니다.

정상적인 작동 조건의 경우 스토리지 계획 목표는 AD DS의 요청이 디스크에서 반환될 때까지의 대기 시간을 최소화하는 것입니다. 이는 기본적으로 미해결 I/O 및 보류 중인 I/O 수가 디스크에 대한 경로 수보다 작거나 동일하다는 것을 의미합니다. 이를 측정하는 방법에는 여러 가지가 있습니다. 성능 모니터링 시나리오에서 일반적인 권장 사항은 LogicalDisk(<NTDS 데이터베이스 드라이브>)\Avg Disk sec/Read가 20ms 미만이라는 것입니다. 원하는 운영 임계값은 스토리지 유형에 따라 2~6밀리초(.002~.006초) 범위에서 가능한 한 스토리지 속도에 가깝게 훨씬 낮아야 합니다.

예시:

Storage latency chart

차트 분석:

  • 왼쪽의 녹색 타원 - 대기 시간이 10ms에서 기본 일치합니다. 부하가 800 IOPS에서 2400 IOPS로 증가합니다. 이는 기본 스토리지에서 I/O 요청을 얼마나 빨리 처리할 수 있는지에 대한 절대적인 바닥입니다. 스토리지 솔루션의 세부 사항이 적용됩니다.
  • 오른쪽의 부르고뉴 타원 – 대기 시간이 계속 증가하는 동안 처리량은 녹색 원의 출구에서 데이터 수집의 끝까지 플랫합니다기본. 이는 요청 볼륨이 기본 스토리지의 물리적 제한을 초과할 경우 요청이 스토리지 하위 시스템에 전송되기를 기다리는 큐에 오래 소요된다는 것을 보여줍니다.

이 지식 적용:

  • 대규모 그룹의 멤버 자격을 쿼리하는 사용자에 미치는 영향 – 디스크에서 1MB의 데이터, I/O의 양 및 다음과 같이 평가할 수 있는 시간을 읽어야 한다고 가정합니다.
    • Active Directory 데이터베이스 페이지의 크기는 8KB입니다.
    • 디스크에서 최소 128페이지를 읽어야 합니다.
    • 아무것도 캐시되지 않으면 바닥(10ms)에서 데이터를 클라이언트로 반환하기 위해 디스크에서 데이터를 로드하는 데 최소 1.28초가 걸립니다. 스토리지의 처리량이 최대 처리된 지 오래되고 권장되는 최대값인 20ms에서 최종 사용자에게 데이터를 반환하기 위해 디스크에서 데이터를 가져오는 데 2.5초가 걸립니다.
  • 캐시가 준비되는 속도 – 클라이언트 로드가 이 스토리지 예제의 처리량을 최대화한다고 가정하면 캐시는 IO당 2,400 IOPS × 8KB의 속도로 준비됩니다. 또는 초당 약 20MB/초를 사용하여 53초마다 약 1GB의 데이터베이스를 RAM에 로드합니다.

참고 항목

시스템이 백업되는 경우 또는 AD DS에서 가비지 수집을 실행하는 경우와 같이 구성 요소가 디스크에 적극적으로 읽거나 쓸 때 짧은 기간 동안 대기 시간이 상승하는 것을 관찰하는 것이 정상입니다. 이러한 정기적인 이벤트를 수용하려면 계산 위에 추가 헤드룸을 제공해야 합니다. 목표는 정상적인 함수에 영향을 주지 않고 이러한 시나리오를 수용할 수 있는 충분한 처리량을 제공하는 것입니다.

볼 수 있듯이 스토리지 디자인에 따라 캐시가 얼마나 빨리 따뜻해질 수 있는지에 대한 물리적 제한이 있습니다. 캐시를 따뜻하게 하는 것은 기본 스토리지에서 제공할 수 있는 속도까지 들어오는 클라이언트 요청입니다. 사용량이 많은 시간 동안 캐시를 "미리 웜"하기 위해 스크립트를 실행하면 실제 클라이언트 요청에 의해 부하가 분산될 수 있습니다. 이는 캐시를 따뜻하게 하기 위한 인위적인 시도가 DC에 연락하는 클라이언트와 관련이 없는 데이터를 로드하기 때문에 설계상 부족한 디스크 리소스에 대한 경쟁을 생성하기 때문에 클라이언트가 먼저 필요로 하는 데이터를 배달하는 데 부정적인 영향을 미칠 수 있습니다.