Configuration Manager 사이트 크기 및 성능 지침
적용 대상: Configuration Manager(현재 분기)
Configuration Manager 규모와 성능으로 업계를 이끌고 있습니다. 다른 설명서에서는 가장 큰 환경 크기에서 사이트를 실행하기 위해 지원되는 최대 규모 제한 및 하드웨어 지침을 다룹니다. 이 문서에서는 모든 크기의 환경에 대한 추가 성능 지침을 제공합니다. 이 지침은 Configuration Manager 배포하는 데 필요한 하드웨어를 보다 정확하게 예측하는 데 도움이 될 수 있습니다.
이 문서에서는 Configuration Manager 성능 병목 현상에 가장 큰 기여자인 디스크 입력/출력 하위 시스템 또는 IOPS에 중점을 둡니다.
- IOPS에 초점을 맞춘 세부 정보 및 테스트 결과 표시
- 사용자 고유의 환경 및 하드웨어를 사용하여 테스트를 재현하는 방법을 문서화합니다.
- 다양한 크기 환경에 대한 디스크 IOPS 요구 사항 제안
성능 테스트 방법론
여러 가지 고유한 방법으로 Configuration Manager 배포할 수 있지만 크기 조정 토론에서 몇 가지 변수를 이해하는 것이 중요합니다. 한 가지 변수는 인벤토리 주기와 같은 기능 간격입니다. 또 다른 변수는 시스템이 참조하거나 배포하는 사용자, 소프트웨어 배포 또는 기타 개체 의 수입니다. 성능 테스트는 부하의 일부로 이러한 변수를 적용합니다. 부하는 다양한 크기 환경에서 프로덕션 배포를 사용하는 엔터프라이즈 고객에게 일반적인 속도로 개체를 생성합니다.
참고
고객 사용량 데이터를 사용하면 대부분의 고객에 대한 가장 일반적인 시나리오, 구성 및 설정을 사용하여 현재 분기 빌드를 테스트할 수 있습니다. 이 문서의 권장 사항은 이러한 평균을 기반으로 합니다. 환경의 크기와 구성에 따라 환경이 달라질 수 있습니다. 일반적으로 Configuration Manager 개체 및 간격과 관련하여 상식이 필요합니다. 시스템의 모든 파일을 수집하거나 주기 간격을 1분으로 설정할 수 있다고 해서 해야 한다는 의미는 아닙니다.
다음 섹션에서는 대기업의 처리 요구 사항을 테스트하고 모델링할 때 사용할 몇 가지 주요 설정 및 구성을 강조 표시합니다. 이러한 지침은 제안된 하드웨어 크기에 대한 기본 시스템 성능 기대치를 설정하는 데 도움이 됩니다.
기능 간격 설정
대부분의 테스트는 시스템의 키 주기에 대한 기본 간격을 사용해야 합니다. 예를 들어 하드웨어 인벤토리 테스트는 기본 .mof 파일보다 큰 상태에서 일주일에 한 번 발생합니다. 일부 되풀이 기능 간격, 특히 하드웨어 및 소프트웨어 인벤토리 주기는 환경의 성능 특성에 상당한 영향을 미칠 수 있습니다. 데이터 수집에 대해 적극적인 기본 간격을 사용하도록 설정하는 환경에는 활동 증가에 직접적으로 비례하는 오버사이즈 하드웨어가 필요합니다. 예를 들어 데스크톱 클라이언트가 25,000개이고 하드웨어 인벤토리를 기본 간격보다 두 배 더 빠르게 수집하려고 합니다. 먼저 50,000개의 클라이언트가 있는 것처럼 사이트의 하드웨어 크기를 조정합니다.
개체
테스트는 대기업이 시스템에서 사용하는 경향이 있는 개체의 상위 평균 을 사용해야 합니다. 일반적인 값은 수십만 명의 사용자 또는 시스템에 배포되는 수천 개의 컬렉션 및 애플리케이션입니다. 테스트는 이러한 제한에 따라 시스템의 모든 개체에서 동시에 실행되어야 합니다. 많은 고객이 여러 기능을 사용하지만 일반적으로 이러한 상한에서 제품의 모든 기능을 사용하지는 않습니다. 모든 제품 기능을 사용하여 테스트하면 시스템 전체에서 최상의 성능을 보장하는 데 도움이 되며, 일부 고객이 평균 이상 사용할 수 있는 기능에 대한 버퍼를 허용합니다.
로드
또한 테스트는 시스템에서 사용량이 가장 많은 시뮬레이션을 수행하여 표준 평균 일 부하보다 큰 부하에서 실행되어야 합니다. 한 가지 예는 패치 화요일 롤아웃을 시뮬레이트하여 시스템이 최대 작업 기간 동안 업데이트 준수 데이터를 즉시 반환할 수 있도록 하는 것입니다. 또 다른 예는 광범위한 맬웨어가 발생하는 동안 사이트 활동을 시뮬레이션하여 적시에 알림 및 응답이 가능하도록 하는 것입니다. 권장 크기의 배포된 컴퓨터는 특정 날짜에 사용이 부족할 수 있지만 더 극단적인 상황에서는 일부 처리 버퍼가 필요합니다.
구성
지원되는 운영 체제와 SQL Server 버전이 혼합된 다양한 물리적, Hyper-V 및 Azure 하드웨어에서 테스트를 실행합니다. 항상 지원되는 구성에 대한 최악의 경우의 유효성을 검사합니다. 일반적으로 Hyper-V 및 Azure는 유사하게 구성된 경우 동등한 물리적 하드웨어에 유사한 성능 결과를 반환합니다. 현재 서버 운영 체제는 이전 OS 버전과 같거나 더 나은 성능을 갖는 경향이 있습니다. 지원되는 모든 플랫폼은 최소 요구 사항을 충족하지만 일반적으로 Windows 및 SQL Server 같은 지원 제품의 최신 버전은 더 나은 성능을 제공합니다.
가장 큰 변형은 사용 중인 SQL Server 버전에서 가져옵니다. SQL Server 버전에 대한 자세한 내용은 어떤 버전의 SQL Server 실행해야 하나요?를 참조하세요.
주요 성능 결정자
다양한 종류의 설정, 다양한 방법 및 다른 사이트 크기로 Configuration Manager 성능을 테스트하고 측정할 수 있습니다. 다음 설정 및 개체는 성능에 큰 영향을 줄 수 있습니다. 환경에서 성능을 테스트하고 모델링할 때 고려해야 합니다.
주의
Configuration Manager 몇 가지 측면은 과도한 사용을 방지하는 공식 최대값 또는 사용자 인터페이스 제한을 가지고 있지만, 지침을 넘어서는 것은 사이트의 성능에 상당한 악영향을 미칠 수 있습니다. 권장 수준을 초과하거나 크기 조정 지침을 무시하려면 일반적으로 더 큰 하드웨어가 필요하며 다양한 개체의 빈도 또는 수를 줄일 때까지 환경을 매핑할 수 없게 될 수 있습니다.
하드웨어 인벤토리
기준 성능을 테스트하려면 기본 .mof 파일 크기와 약 20%의 다른 속성을 사용하여 하드웨어 인벤토리 컬렉션을 일주일에 한 번으로 설정합니다. 모든 속성을 사용하도록 설정하지 말고 실제로 필요한 속성만 수집합니다. 항상 모든 인벤토리 주기에 따라 변경되는 사용 가능한 가상 메모리와 같은 속성을 수집할 때 특히 주의해야 합니다. 이러한 속성을 수집하면 모든 클라이언트의 모든 인벤토리 주기에 과도한 변동이 발생할 수 있습니다.
소프트웨어 인벤토리
기준 성능을 테스트하려면 소프트웨어 인벤토리 수집을 일주일에 한 번으로 설정하고 제품 전용 세부 정보를 사용합니다. 많은 파일을 수집하면 인벤토리 하위 시스템에 상당한 부담이 될 수 있습니다. 또는 *.dll와 같은 *.exe 많은 클라이언트에서 수천 개의 파일을 수집할 수 있는 필터를 지정하지 마세요.
컬렉션
기준 성능 테스트에는 다양한 종류의 범위, 크기, 복잡성 및 업데이트 설정이 있는 수천 개의 컬렉션이 포함될 수 있습니다. 사이트 성능은 사이트에 있는 방대한 수의 컬렉션에 대한 직접적인 기능이 아닙니다. 성능은 컬렉션의 쿼리 복잡성, 전체 및 증분 업데이트 및 변경 빈도, 컬렉션 간의 종속성 및 컬렉션의 클라이언트 수의 교차 산물이기도 합니다.
가능한 경우 비용이 많이 들거나 복잡한 동적 규칙 쿼리가 있는 컬렉션을 최소화합니다. 이러한 유형의 규칙이 필요한 컬렉션의 경우 적절한 업데이트 간격 및 업데이트 시간을 설정하여 시스템에 대한 컬렉션 재평가의 영향을 최소화합니다. 예를 들어 오전 8시 대신 자정에 업데이트합니다.
컬렉션에서 증분 업데이트를 사용하도록 설정하면 컬렉션 멤버 자격에 대한 빠르고 시기 적절한 업데이트가 보장됩니다. 그러나 증분 업데이트는 효율적이지만 여전히 시스템에 부하를 가합니다. 멤버 자격에 대한 거의 실시간 업데이트가 필요한 경우 예상되는 변경 빈도의 균형을 조정합니다. 예를 들어 컬렉션 멤버의 변동이 많을 것으로 예상하지만 거의 실시간 멤버 자격 업데이트가 필요하지 않다고 가정해 보겠습니다. 증분 업데이트를 사용하도록 설정하는 것보다 일정 간격으로 예약된 전체 업데이트로 컬렉션을 업데이트하는 시스템의 부하가 더 효율적이고 적습니다.
증분 업데이트를 사용하도록 설정하면 동일한 컬렉션에서 예약된 전체 업데이트를 줄입니다. 증분 업데이트는 컬렉션 멤버 자격을 거의 실시간으로 업데이트해야 하므로 평가의 백업 방법일 뿐입니다. 컬렉션에 대한 모범 사례는 증분 업데이트에 대한 총 컬렉션의 최대 수를 권장하지만 문서에서 설명한 대로 다양한 요인에 따라 환경이 달라질 수 있습니다.
직접 멤버 자격 규칙만 있고 증분 업데이트를 수행하지 않는 컬렉션이 제한된 컬렉션에는 예약된 전체 업데이트가 필요하지 않습니다. 시스템에서 불필요한 로드를 방지하기 위해 이러한 유형의 컬렉션에 대한 업데이트 일정을 사용하지 않도록 설정합니다. 제한 컬렉션에서 증분 업데이트를 사용하는 경우 직접 멤버 자격 규칙만 있는 컬렉션은 최대 24시간 동안 또는 예약된 새로 고침이 발생할 때까지 멤버 자격 업데이트를 반영하지 않을 수 있습니다.
모범 사례는 아니지만 일부 조직에서는 다양한 비즈니스 프로세스의 일부로 수백 또는 수천 개의 컬렉션을 만듭니다. 자동화를 사용하여 컬렉션을 만드는 경우 필요한 증분 업데이트를 올바르게 사용하도록 설정하는 것이 중요합니다. 전체 업데이트 일정을 최소화하고 분산하여 단일 기간 동안 수집 평가의 핫스폿을 방지합니다. 특히 일정 시간 후에 더 이상 필요하지 않은 컬렉션을 자동으로 만드는 경우 사용하지 않는 컬렉션을 삭제하는 정기적인 그루밍 프로세스를 설정합니다.
Configuration Manager 컬렉션에 배포와 같은 작업을 대상으로 지정할 때 컬렉션의 모든 개체에 대한 정책을 만듭니다. 예약된 새로 고침 또는 증분 업데이트를 통해 멤버 자격 변경은 전체 시스템에 훨씬 더 많은 작업을 만들 수 있습니다. 최신 현재 분기 빌드에는 모든 시스템 및 모든 사용자 컬렉션에 대한 특별한 정책 최적화가 있습니다. 전체 엔터프라이즈를 대상으로 지정할 때 이러한 기본 제공 컬렉션의 복제본 대신 기본 제공 컬렉션을 사용합니다.
컬렉션 성능을 더 자세히 조사하려면 콘솔에서 컬렉션 평가를 봅니다. 자세한 내용은 컬렉션 평가를 보는 방법을 참조하세요.
검색 방법
기준 성능 테스트의 경우 일주일에 한 번 서버 기반 검색 방법을 실행하여 주중에 데이터를 최신 상태로 유지하기 위해 델타 검색을 적절하게 사용하도록 설정합니다. 테스트는 시뮬레이션된 엔터프라이즈 크기에 비례하는 개체 수량을 검색해야 합니다. 하트비트 검색에 대한 성능 기준 테스트도 일주일에 한 번 실행해야 합니다.
검색 데이터는 전역 데이터입니다. 일반적인 성능 관련 문제는 계층 구조에서 서버 기반 검색 메서드를 잘못 구성하여 여러 기본 사이트에서 동일한 리소스를 중복 검색하는 것입니다. 여러 기본 사이트에서 동일한 검색 범위가 중복되지 않도록 하면서 Active Directory 도메인 컨트롤러와 같은 대상 서비스와의 통신을 최적화하도록 검색 방법을 신중하게 구성합니다.
일반 크기 조정 지침
위의 성능 테스트 방법론에 따라 다음 표에서는 특정 수의 관리되는 클라이언트에 대한 일반적인 최소 하드웨어 요구 사항 지침을 제공합니다. 이러한 값을 사용하면 지정된 수의 클라이언트를 가진 대부분의 고객이 지정된 사이트를 관리할 수 있을 만큼 빠르게 개체를 처리할 수 있습니다. 컴퓨팅 성능은 매년 가격이 계속 하락하고 있으며, 아래 요구 사항 중 일부는 최신 서버 하드웨어 구성에 대해 작습니다. 다음 지침을 초과하는 하드웨어는 처리 능력이 더 필요하거나 특별한 제품 사용 패턴이 있는 사이트의 성능을 비례적으로 증가합니다.
| 데스크톱 클라이언트 | 사이트 유형/역할 | 코어 노트 1 | 메모리(GB) | SQL Server 메모리 할당 참고 2 | IOPS: 받은 편지함 참고 3 | IOPS: SQL Server 참고 3 | 필요한 스토리지 공간(GB) 참고 4 |
|---|---|---|---|---|---|---|---|
| 25k | 동일한 서버에서 데이터베이스 사이트 역할이 있는 주 또는 CAS | 6 | 24 | 65% | 600 | 1700 | 350 |
| 25k | 기본 또는 CAS | 4 | 8 | 600 | 100 | ||
| 원격 SQL Server | 4 | 16 | 70% | 1700 | 250 | ||
| 50k | 동일한 서버에서 데이터베이스 사이트 역할이 있는 주 또는 CAS | 8 | 32 | 70% | 1200 | 2800 | 600 |
| 50k | 기본 또는 CAS | 4 | 8 | 1200 | 200 | ||
| 원격 SQL Server | 8 | 24 | 70% | 2800 | 400 | ||
| 100k | 동일한 서버에서 데이터베이스 사이트 역할이 있는 주 또는 CAS | 12 | 64 | 70% | 1200 | 5000 | 1100 |
| 100k | 기본 또는 CAS | 6 | 12 | 1200 | 300 | ||
| 원격 SQL Server | 12 | 48 | 80% | 5000 | 800 | ||
| 150k | 동일한 서버에서 데이터베이스 사이트 역할이 있는 주 또는 CAS | 16 | 96 | 70% | 1800 | 7400 | 1600 |
| 150k | 기본 또는 CAS | 8 | 16 | 1800 | 400 | ||
| 원격 SQL Server | 16 | 72 | 90% | 7400 | 1200 | ||
| 700k | 동일한 서버에서 데이터베이스 사이트 역할이 있는 CAS | 20+ | 128+ | 80% | 1800+ | 9000+ | 5000+ |
| 700k | Ca | 8+ | 16+ | 1800+ | 500+ | ||
| 원격 SQL Server | 16+ | 96+ | 90% | 9000+ | 4500+ | ||
| 5k | 보조 사이트 | 4 | 8 | 500 | - | 200 | |
| 15k | 보조 사이트 | 8 | 16 | 500 | - | 300 |
일반 크기 조정 지침에 대한 참고 사항
참고 1: 코어
Configuration Manager 많은 동시 프로세스를 실행하므로 다양한 사이트 크기에 대해 특정 최소 CPU 코어 수가 필요합니다. 코어는 매년 더 빨라지지만 특정 최소 코어 수가 병렬로 작동하도록 하는 것이 중요합니다. 일반적으로 2015년 이후에 생성된 모든 서버 수준 CPU는 테이블에 지정된 코어에 대한 기본 성능 요구 사항을 충족합니다. Configuration Manager 권장 사항 이외의 다른 코어를 활용합니다. 제안된 최소 코어가 있으면 CPU 리소스 투자의 우선 순위를 지정하여 기존 코어의 속도를 높입니다. 더 많은 느린 코어를 추가하지 마세요. 예를 들어 Configuration Manager 24개의 느린 코어보다 16개의 빠른 코어를 사용하는 키 처리 작업에서 더 나은 성능을 제공합니다. 이 성능에서는 디스크 IOPS와 같은 다른 시스템 리소스가 충분하다고 가정합니다.
코어와 메모리 간의 관계도 중요합니다. 일반적으로 코어당 RAM이 3~4GB 미만이면 SQL Server의 총 처리 기능이 줄어듭니다. SQL Server 사이트 서버 구성 요소와 공동 배치될 때 코어당 RAM이 더 많이 필요합니다.
참고
모든 테스트는 최대 CPU 전력 소비 및 성능을 허용하도록 컴퓨터 전원 계획을 설정합니다.
참고 2: 메모리 할당 SQL Server
이 값을 사용하여 SQL Server 속성에서 최대 서버 메모리(MB)를 구성합니다. 서버에서 사용할 수 있는 총 메모리 양 비율입니다.
최소값과 최대값을 동일하게 구성하지 마세요. 이 지침은 특히 SQL Server 할당하도록 허용해야 하는 최대 메모리에 대한 것입니다.
참고 3: IOPS: 받은 편지함 및 IOPS: SQL
이러한 값은 Configuration Manager 및 SQL Server 논리 드라이브에 대한 IOPS 요구를 참조합니다. IOPS: 받은 편지함 열에는 Configuration Manager 받은 편지함 디렉터리를 사용하는 논리 드라이브에 대한 IOPS 요구 사항이 표시됩니다. IOPS: SQL 열은 다양한 SQL Server 파일에서 사용하는 논리 드라이브에 필요한 총 IOPS를 보여 줍니다. 두 드라이브의 서식이 서로 다르기 때문에 이러한 열은 다릅니다. 여러 볼륨에서 파일을 분할하는 방법에 대한 세부 정보를 포함하여 제안된 SQL Server 디스크 구성 및 파일 모범 사례에 대한 자세한 내용 및 예제는 사이트 크기 조정 및 성능 FAQ를 참조하세요.
이러한 두 IOPS 열은 모두 업계 표준 도구 Diskspd의 데이터를 사용합니다. 이러한 측정을 복제하는 방법에 대한 지침은 디스크 성능을 측정하는 방법을 참조하세요. 일반적으로 기본 CPU 및 메모리 요구 사항을 충족하면 스토리지 하위 시스템이 사이트 성능에 가장 큰 영향을 미치며, 여기서 개선하면 투자에 대한 가장 많은 회수가 제공됩니다.
참고 4: 스토리지 공간 필요
이러한 실제 값은 문서화된 다른 권장 사항과 다를 수 있습니다. 이러한 숫자는 일반적인 지침으로만 제공합니다. 개별 요구 사항은 매우 다양할 수 있습니다. 사이트 설치 전에 디스크 공간 요구 사항을 신중하게 계획합니다. 이 스토리지의 양이 대부분 사용 가능한 디스크 공간으로 유지된다고 가정합니다. 복구 시나리오 또는 설치 패키지 확장을 위해 사용 가능한 디스크 공간이 필요한 업그레이드 시나리오에서 이 버퍼 공간을 사용할 수 있습니다. 사이트에는 대량의 데이터 수집, 더 긴 데이터 보존 기간 및 대량의 소프트웨어 배포 콘텐츠에 더 많은 스토리지가 필요할 수 있습니다. 이러한 항목을 처리량이 낮은 별도의 볼륨에 저장할 수도 있습니다.
디스크 성능을 측정하는 방법
업계 표준 도구 Diskspd를 사용하여 다양한 크기의 Configuration Manager 환경에 필요한 IOPS에 대한 표준화된 제안을 제공할 수 있습니다. 완전하지는 않지만 다음 테스트 단계 및 명령줄은 서버의 디스크 하위 시스템 처리량을 예측하는 간단하고 재현 가능한 방법을 제공합니다. 일반 크기 조정 지침 표의 최소 권장 IOPS와 결과를 비교할 수 있습니다.
랩 환경에서 다양한 종류의 하드웨어 구성의 테스트 결과는 디스크 구성 예제를 참조하세요. 새 환경에 대한 스토리지 하위 시스템을 처음부터 디자인할 때 대략적인 시작 지점에 데이터를 사용할 수 있습니다.
디스크 IOPS를 테스트하는 방법
100GB 이상의 사용 가능한 디스크 공간이 있는지 확인합니다. 디렉터리, SQL 또는 SMSExec의 활성 바이러스 백신 검사와 같이 디스크에 추가 부하를 유발하거나 방해할 수 있는 앱을 사용하지 않도록 설정합니다.
관리자 권한 명령 프롬프트에서 Diskspd 를 실행합니다.
테스트하려는 볼륨에 대해 도구를 순서대로 두 번 실행합니다. 1분 동안 임의 쓰기 작업이 있는 64k 크기의 첫 번째 테스트입니다. 이 테스트는 볼륨이 동적으로 확장되는 경우 컨트롤러 캐시 로드 및 디스크 공간 할당의 유효성을 검사합니다. 첫 번째 테스트의 결과를 삭제합니다. 두 번째 테스트는 첫 번째 테스트 바로 뒤에 5분 동안 동일한 부하를 수행해야 합니다.
예를 들어 다음 특정 명령줄을 사용하여 볼륨을 테스트합니다
G:.DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d60 -h -L G:\\test\testfile.dat del G:\\test\testfile.dat DiskSpd.exe -r -w100 -t8 -o8 -b64K -c100G -d300 -h -L G:\\test\testfile.dat두 번째 테스트의 출력을 검토하여 열 당 I/O에서 총 IOPS를 찾습니다 . 다음 예제에서 총 IOPS는 3929.18입니다.
Total IO | thread | bytes | I/Os | MB/s | I/O per s | AvgLat | LatStdDev | |--------|-------------|---------|--------|-----------|--------|-----------| | 1 | 9651814400 | 147275 | 30.68 | 490.92 | 16.294 | 10.210 | | 2 | 9676652544 | 147654 | 30.76 | 492.18 | 16.252 | 9.998 | | 3 | 9638248448 | 147068 | 30.64 | 490.23 | 16.317 | 10.295 | | 4 | 9686089728 | 147798 | 30.79 | 492.66 | 16.236 | 10.072 | | 5 | 9590931456 | 146346 | 30.49 | 487.82 | 16.398 | 10.384 | | 6 | 9677242368 | 147663 | 30.76 | 492.21 | 16.251 | 10.067 | | 7 | 9637330944 | 147054 | 30.64 | 490.18 | 16.319 | 10.249 | | 8 | 9692577792 | 147897 | 30.81 | 492.99 | 16.225 | 10.125 | | Total: | 77250887680 | 1178755 | 245.57 | 3929.18 | 16.286 | 10.176 |
디스크 구성 예제
다음 표에서는 다양한 테스트 랩 구성을 사용하여 디스크 성능을 측정하는 방법 의 테스트 단계를 실행한 결과를 보여 줍니다. 새 환경에 대한 스토리지 하위 시스템을 처음부터 디자인할 때 이 데이터를 대략 적인 시작 지점에 사용합니다.
물리적 컴퓨터 및 Hyper-V
하드웨어는 항상 개선되고 있습니다. 최신 세대의 하드웨어 및 SSD 및 SAN과 같은 다양한 하드웨어 조합이 아래에 명시된 성능을 초과할 것으로 예상합니다. 이러한 결과는 서버를 디자인하거나 하드웨어 공급업체와 논의할 때 고려해야 할 기본적인 시작점입니다.
다음 표에서는 다양한 테스트 랩 구성에서 스핀들 및 SSD 기반 하드 드라이브를 포함한 다양한 디스크 하위 시스템의 테스트 결과를 보여 줍니다. 모든 구성은 디스크를 64k 클러스터로 포맷하고 엔터프라이즈 클래스 디스크 컨트롤러에 연결합니다. RAID 배열 디스크 수 외에도 각각 하나 이상의 예비 디스크가 있습니다.
| 디스크 유형 | +1개의 예비 디스크를 포함하지 않는 디스크 수 | Raid | IOPS 측정 |
|---|---|---|---|
| 15k SAS | 2 | 1 | 620 |
| 15k SAS | 4 | 10 | 1206 |
| 15k SAS | 6 | 10 | 1751 |
| 15k SAS | 8 | 10 | 2322 |
| 15k SAS | 10 | 10 | 2882 |
| 15k SAS | 12 | 10 | 3476 |
| 15k SAS | 16 | 10 | 4236 |
| 15k SAS | 20 | 10 | 5148 |
| 15k SAS | 30 | 10 | 7398 |
| 15k SAS | 40 | 10 | 9913 |
| SSD SATA | 2 | 1 | 3300 |
| SSD SATA | 4 | 10 | 5542 |
| SSD SATA | 6 | 10 | 7201 |
| SSD SAS | 2 | 1 | 7539 |
| SSD SAS | 4 | 10 | 14346 |
| SSD SAS | 6 | 10 | 15607 |
다음 표에는 이 예제에 사용된 특정 디바이스가 나와 있습니다. 이 정보는 특정 하드웨어 모델 또는 제조업체에 대한 권장 사항이 아닙니다.
| 디스크 유형 | 모델 | RAID 컨트롤러 | 캐시 메모리 및 구성 |
|---|---|---|---|
| 15k RPM SAS HD | HP EH0300JDYTH | 스마트 배열 P822 | 2GB, 20% 읽기/80% 쓰기 |
| SSD SATA | ATA MK0200GCTYV | 스마트 배열 P420i | 1GB, 20% 읽기/80% 쓰기 |
| SSD SAS | HP MO0800 JEFPB | 스마트 배열 P420i | 1GB, 20% 읽기/80% 쓰기 |
Azure 컴퓨터 및 디스크 성능
Azure 디스크 성능은 Azure VM의 크기, 사용하는 디스크 수 및 유형과 같은 여러 요인에 따라 달라집니다. 또한 Azure는 다음 차트와 다른 새 머신 유형 및 디스크 속도를 지속적으로 추가하고 있습니다. Azure에서 실행되는 Configuration Manager 및 Azure의 디스크 I/O 이해에 대한 자세한 내용은 Azure의 Configuration Manager 질문과 대답을 참조하세요.
모든 디스크의 형식은 NTFS 64k 클러스터 크기이며, 둘 이상의 디스크가 있는 행은 Windows 디스크 관리 유틸리티를 통해 스트라이프 볼륨으로 구성됩니다.
| Azure VM | Azure 디스크 | 디스크 수 | 사용 가능한 공간 | IOPS 측정 | 제한 요소 |
|---|---|---|---|---|---|
| DS2/DS11 | P20 | 1 | 512GB | 965 | Azure VM 크기 |
| DS2/DS11 | P20 | 2 | 1024GB | 996 | Azure VM 크기 |
| DS2/DS11 | P30 | 1 | 1024GB | 996 | Azure VM 크기 |
| DS2/DS11 | P30 | 2 | 2048GB | 996 | Azure VM 크기 |
| DS3/DS12/F4S | P20 | 1 | 512GB | 1994 | Azure VM 크기 |
| DS3/DS12/F4S | P20 | 2 | 1024GB | 1992 | Azure VM 크기 |
| DS3/DS12/F4S | P30 | 1 | 1024GB | 1993 | Azure VM 크기 |
| DS3/DS12/F4S | P30 | 2 | 2048GB | 1992 | Azure VM 크기 |
| DS4/DS13/F8S | P20 | 1 | 512GB | 2334 | P20 디스크 |
| DS4/DS13/F8S | P20 | 2 | 1024GB | 3984 | Azure VM 크기 |
| DS4/DS13/F8S | P20 | 3 | 1536GB | 3984 | Azure VM 크기 |
| DS4/DS13/F8S | P30 | 1 | 1024GB | 3112 | P30 디스크 |
| DS4/DS13/F8S | P30 | 2 | 2048GB | 3984 | Azure VM 크기 |
| DS4/DS13/F8S | P30 | 3 | 3072GB | 3996 | Azure VM 크기 |
| DS5/DS14/F16S | P20 | 1 | 512GB | 2335 | P20 디스크 |
| DS5/DS14/F16S | P20 | 2 | 1024GB | 4639 | P20 디스크 |
| DS5/DS14/F16S | P20 | 3 | 1536GB | 6913 | P20 디스크 |
| DS5/DS14/F16S | P20 | 4 | 2048GB | 7966 | Azure VM 크기 |
| DS5/DS14/F16S | P30 | 1 | 1024GB | 3112 | P30 디스크 |
| DS5/DS14/F16S | P30 | 2 | 2048GB | 6182 | P30 디스크 |
| DS5/DS14/F16S | P30 | 3 | 3072GB | 7963 | Azure VM 크기 |
| DS5/DS14/F16S | P30 | 4 | 4096GB | 7968 | Azure VM 크기 |
| DS15 | P30 | 1 | 1024GB | 3113 | P30 디스크 |
| DS15 | P30 | 2 | 2048GB | 6184 | P30 디스크 |
| DS15 | P30 | 3 | 3072GB | 9225 | P30 디스크 |
| DS15 | P30 | 4 | 4096GB | 10200 | Azure VM 크기 |
현재 사용 가능한 디스크에 대한 자세한 내용은 Azure IaaS VM에 대한 디스크 유형 선택을 참조하세요.
참고 항목
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기