SharePoint Server에서 엔터프라이즈 검색 아키텍처 계획
적용 대상:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
엔터프라이즈 검색 아키텍처를 설정하기 전에 신중한 계획이 필요한 몇 가지 사항이 있습니다. 단계별로 소규모, 중형, 대형 또는 초대형 엔터프라이즈 검색 아키텍처를 계획하는 데 도움이 됩니다.
SharePoint Server에서 검색 시스템의 구성 요소와 상호 작용하는 방법에 대해 잘 알고 있나요? 시작하기 전에 SharePoint Server의 검색 아키텍처 개요 및 SharePoint Server 2016에 대한 검색 아키텍처 (또는 SharePoint Server 2013의 검색 아키텍처)를 읽으면 검색 아키텍처, 검색 구성 요소, 검색 데이터베이스 및 검색 토폴로지를 숙지할 수 있습니다. 검색 아키텍처를 계획할 때 고려해야 할 사항에 대한 몇 가지 제안은 다음과 같습니다.
1단계: 소유한 콘텐츠의 양
검색 인덱스에 있는 콘텐츠의 양은 팜을 호스팅하는 데 필요한 리소스에 영향을 줍니다. 검색 가능하도록 계획할 항목 수를 대략적으로 생각해 보세요. 항목에는 문서, 웹 페이지, SharePoint 목록 항목, 이미지 등이 있습니다. SharePoint 목록의 각 항목은 하나의 항목으로 계산됩니다.
항목 수를 설정한 경우 향후 12개월 동안 예상되는 콘텐츠의 증가량을 곱합니다.
예를 들어 12,000개 인덱싱된 항목으로 시작하는 경우 향후 12개월 동안 해당 콘텐츠의 볼륨이 세 배가 될 것으로 예상합니다. 검색 가능한 항목 36,000개에 대해 계획해야 합니다.
2단계: 콘텐츠 양에 대한 검색 아키텍처의 크기는 얼마인가요?
검색 아키텍처의 규모를 평가하는 것은 언제나 쉽지 않은 일입니다. 검색 아키텍처의 규모는 콘텐츠의 양, 크롤링 속도, 쿼리 처리량 및 필요한 고가용성 수준에 따라 다릅니다. 고유한 팜을 계획하기 위해 기본으로 사용하는 것이 좋습니다. 검색 가능하도록 설정할 콘텐츠의 양에 따라 선택해야 하는 예제 검색 아키텍처가 다릅니다.
| 콘텐츠 볼륨(SharePoint 2016) | 예제 검색 아키텍처 | 콘텐츠 볼륨(SharePoint 2013) |
|---|---|---|
| 항목 수 0~2,000만 개 | 소규모 검색 팜 | 항목 수 0~1,000만 개 |
| 항목 수 0~8,000만 개 | 중간 규모 검색 팜 | 항목 수 0~4,000만 개 |
| 항목 수 0~2억 개 | 대규모 검색 팜 | 항목 수 0~1억 개 |
| 항목 수 0~5억 개 | 초대형 검색 팜 | 지원되지 않음 |
이러한 샘플 검색 아키텍처는 가상 머신을 사용하지만 검색 아키텍처의 전체 SharePoint Server 솔루션 전략에 따라 물리적 서버와 가상 머신을 모두 사용할 수 있습니다.
소규모 검색 팜
이 검색 아키텍처는 초당 50개의 문서를 크롤링하고 초당 10개씩 쿼리를 처리할 수 있다고 추정되고 있습니다. SharePoint Server 2016 팜에 최대 2천만 개의 항목이 있는 경우 작은 검색 팜이 가장 적합한 팜일 것입니다. 초당 50개 문서의 크롤링 속도에서는 첫 번째 전체 크롤링에서 2,000만 개의 항목을 크롤링하는 데 110시간이 소요됩니다.
중간 규모 검색 팜
이 검색 아키텍처는 초당 100개의 문서를 크롤링하고 초당 10개씩 쿼리를 처리할 수 있다고 추정되고 있습니다. SharePoint Server 2016 팜에 20~8천만 개의 항목이 있는 경우 중간 검색 팜이 가장 적합한 팜일 것입니다. 초당 200개 문서의 크롤링 속도에서는 첫 번째 전체 크롤링에서 8,000만 개의 항목을 크롤링하는 데 280시간이 소요됩니다.
대규모 검색 팜
이 검색 아키텍처에서 초당 200개의 문서를 크롤링하고 초당 10개씩 쿼리를 처리할 수 있는 것으로 확인했습니다. SharePoint Server 2016 팜에 80~2억 개의 항목이 있는 경우 대규모 검색 팜이 가장 적합한 팜일 것입니다. 초당 200개 문서의 크롤링 속도에서는 첫 번째 전체 크롤링에서 2억 개의 항목을 크롤링하는 데 280시간이 소요됩니다.
초대형 검색 팜
Microsoft는 이 검색 아키텍처를 테스트했으며 초당 300 - 500개의 문서를 크롤링하고 초당 10개씩 쿼리를 처리할 수 있는 것으로 확인했습니다. SharePoint Server 2016만 이 크기 검색 아키텍처를 지원합니다. 최대 5억 개의 항목이 있는 경우 초대형 검색 팜과 비슷한 팜을 사용하는 것이 좋습니다. 초당 500개 문서의 크롤링 속도에서는 첫 번째 전체 크롤링에서 5억 개의 항목을 크롤링하는 데 300시간이 소요됩니다.
이 크기의 검색 팜을 만들려면 신중하게 계획하고 원하는 성능을 얻기 위해 팜을 조정해야 합니다. 전문가의 지침을 찾아보는 것이 도움이 될 수 있습니다. 또한 이 크기의 검색 팜을 백업 및 복원하는 방법과 데이터 센터에 큰 가동 중단이 있는 경우 팜을 복구하는 방법을 계획하는 것도 중요합니다. 백업, 복원 및 복구를 연습해보는 것이 좋습니다.
3단계: 알아야 할 하드웨어 요구 사항
콘텐츠의 양을 결정하고 예제 검색 아키텍처를 선택했으므로 이제 이 섹션에 설명된 대로 필요한 하드웨어를 계획해야 합니다.
서버를 실제로 실행할지 또는 가상으로 실행할지 결정
예상한 아키텍처 중 하나를 사용하는 경우 가상 머신에서 검색 아키텍처를 실행하게 됩니다. 가상 환경이 관리하기 더 쉽지만 실제 환경보다 성능 수준이 더 나쁜 경우도 있습니다. 실제 서버는 가상 서버와 동일한 서버에 더 많은 검색 구성 요소를 호스팅할 수 있습니다. SharePoint 2013용 팜 가상화 및 아키텍처 개요에서 유용한 지침을 찾을 수 있습니다.
물리적 서버에서 검색 아키텍처를 실행할 수도 있습니다. 샘플 팜 아키텍처에서 가상 머신에서 호스트 서버로 검색 구성 요소를 이동하고 가상 머신을 제거합니다. 각 물리적 서버는 최대 4개의 인덱스 구성 요소를 호스트할 수 있지만 각 유형의 다른 검색 구성 요소 중 하나만 호스트할 수 있습니다. 예를 들어 물리적 서버를 사용하도록 중간 샘플 검색 아키텍처를 변경하는 경우 호스트 E에 두 개의 콘텐츠 처리 구성 요소가 있음을 알 수 있습니다. 솔루션은 콘텐츠 처리 구성 요소 중 하나를 없애는 것입니다. 이는 크롤링, 콘텐츠 처리 및 분석 처리가 콘텐츠 처리 구성 요소 수가 아니라 사용 가능한 리소스의 양에 따라 달라지므로 작동합니다.
호스트 서버의 하드웨어 리소스 선택
각 검색 구성 요소 및 검색 데이터베이스가 제대로 작동되려면 최소 크기의 하드웨어 리소스가 필요합니다. 그렇지만 하드웨어 리소스가 많을 수록 검색 아키텍처의 성능은 더 좋아집니다. 따라서 최소 크기의 하드웨어 리소스보다 더 많은 리소스가 있는 것이 좋습니다. 각 구성 요소에 필요한 리소스는 작업 부하에 따라 다르며, 주로 크롤링 속도, 쿼리 속도 및 인덱싱된 항목 수에 따라 결정됩니다.
예를 들어 Windows Server 2008 R2 SP1(서비스 팩 1)에서 가상 머신을 호스팅하는 경우 가상 머신당 4개 이상의 CPU 코어를 사용할 수 없습니다. Windows Server 2012 이상에서는 가상 머신당 8개 이상의 CPU 코어를 사용합니다. 그런 다음 더 많은 가상 머신으로 스케일 업하는 대신 각 가상 머신에 대해 더 많은 CPU 코어로 스케일 아웃할 수 있습니다. 동일한 하드웨어 리소스를 사용하여 동일한 검색 구성 요소를 호스트하는 서버 또는 가상 머신을 설정합니다. 인덱스 구성 요소를 예로 들어 보겠습니다. 가상 머신에서 인덱스 파티션을 호스트하는 경우 성능이 가장 약한 가상 머신은 전체 검색 아키텍처의 성능을 결정합니다.
일반 저장소
각 호스트 서버에 Windows Server 운영 체제 및 SharePoint Server 프로그램 파일의 기본 설치를 위한 충분한 디스크 공간이 있는지 확인합니다. 또한 호스트 서버에 진단(예: 로깅, 디버깅 및 메모리 덤프 생성), 일상적인 작업 및 페이지 파일에 사용 가능한 하드 디스크 공간도 필요합니다. 일반적으로 80GB의 디스크 공간은 Windows Server 운영 체제 및 SharePoint Server 프로그램 파일에 충분합니다.
각 데이터베이스 서버에 대해 SQL 로그 공간으로 사용될 저장소를 추가합니다. 데이터베이스를 자주 백업하도록 데이터베이스 서버를 설정하지 않은 경우 SQL 로그 공간이 많은 저장소를 사용합니다. SQL 데이터베이스를 계획하는 방법에 대한 자세한 내용은 스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server) 을 참조하세요.
분석 보고 데이터베이스에 필요한 최소 저장소는 다를 수 있습니다. 스토리지의 양은 사용자가 SharePoint Server와 상호 작용하는 방식에 따라 달라지기 때문입니다. 사용자가 자주 상호 작용할 경우 일반적으로 저장할 이벤트가 더 많아집니다. 현재 검색 아키텍처가 분석 데이터베이스에 대해 사용하는 저장소 양을 확인하고 다시 디자인한 토폴로지에 대해 적어도 이보다 큰 공간을 할당합니다.
소규모 검색 팜의 최소 하드웨어 리소스
이 표에서는 각 응용 프로그램 서버 또는 데이터베이스 서버에 필요한 최소 하드웨어 리소스 크기가 나와 있습니다.
| 서버 | 호스트 | Storage | RAM | 프로세서1 | 네트워크 대역폭 |
|---|---|---|---|---|---|
| 쿼리 처리 및 인덱스 구성 요소가 있는 응용 프로그램 서버 | A, B | 500GB2,3 | 32GB2,3 | 1.8GHz 8x CPU 코어2,3 | 1Gbps |
| 크롤링, 검색 관리, 분석 및 콘텐츠 처리 구성 요소가 있는 응용 프로그램 서버 | A, B | 200GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 모든 검색 데이터베이스가 있는 데이터베이스 서버 | C, D | 100GB | 16 GB | 1.8GHz CPU 코어 4개 | 1Gbps |
1CPU 코어 수는 CPU 스레드 수가 아니라 여기에서 지정됩니다.
2SharePoint Server 2013을 사용하면 필요한 최소 리소스 크기는 500GB 스토리지, 16GB RAM 및 4개의 CPU 코어입니다.
3SharePoint Server 2016에서는 250GB 스토리지, 16GB RAM 및 4개의 CPU 코어를 사용할 수도 있지만 각 인덱스 구성 요소는 1,000만 개의 항목만 보유할 수 있으며 검색 팜은 SharePoint Server 2013 검색 팜과 동일한 양의 콘텐츠만 지원합니다.
중간 규모 검색 팜의 최소 하드웨어 리소스
이 표에서는 각 응용 프로그램 서버 또는 데이터베이스 서버에 필요한 최소 하드웨어 리소스 크기가 나와 있습니다.
| 서버 | 호스트 | Storage | RAM | 프로세서1 | 네트워크 대역폭 |
|---|---|---|---|---|---|
| 쿼리 처리 및 인덱스 구성 요소가 있는 응용 프로그램 서버 | A, B, C, D | 500GB2,3 | 32GB2,3 | 1.8GHz 8x CPU 코어2,3 | 1Gbps |
| 인덱스 구성 요소가 있는 응용 프로그램 서버 | A, B, C, D | 500GB2,3 | 32GB2,3 | 1.8GHz 8x CPU 코어2,3 | 1Gbps |
| 분석 및 콘텐츠 처리 구성 요소가 있는 응용 프로그램 서버 | E, F | 300GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 크롤링, 검색 관리 및 콘텐츠 처리 구성 요소가 있는 응용 프로그램 서버 | E, F | 100GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 모든 검색 데이터베이스가 있는 데이터베이스 서버 | G, H | 400GB | 16GB | 1.8GHz CPU 코어 4개 | 1Gbps |
1CPU 코어 수는 CPU 스레드 수가 아니라 여기에서 지정됩니다.
2SharePoint Server 2013을 사용하면 필요한 최소 리소스 크기는 500GB 스토리지, 16GB RAM 및 4개의 CPU 코어입니다.
3SharePoint Server 2016에서는 250GB 스토리지, 16GB RAM 및 4개의 CPU 코어를 사용할 수도 있지만 각 인덱스 구성 요소는 1,000만 개의 항목만 보유할 수 있으며 검색 팜은 SharePoint Server 2013 검색 팜과 동일한 양의 콘텐츠만 지원합니다.
대규모 검색 팜의 최소 하드웨어 리소스
이 표에서는 각 응용 프로그램 서버 또는 데이터베이스 서버에 필요한 최소 하드웨어 리소스 크기가 나와 있습니다.
| 서버 | 호스트 | Storage | RAM | 프로세서1 | 네트워크 대역폭 |
|---|---|---|---|---|---|
| 쿼리 처리 및 인덱스 구성 요소가 있는 응용 프로그램 서버 | A, B, C, D, E, G, H | 500GB2, 3 | 32GB2, 3 | 1.8GHz 8x CPU 코어2, 3 | 1Gbps |
| 인덱스 구성 요소가 있는 응용 프로그램 서버 | A, B, C, D, E, F, G, H, I, J | 500GB2, 3 | 32GB2, 3 | 1.8GHz 8x CPU 코어2, 3 | 1Gbps |
| 분석 및 콘텐츠 처리 구성 요소가 있는 응용 프로그램 서버 | K, L, M, N | 300GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 크롤링 및 검색 관리 구성 요소가 있는 응용 프로그램 서버 | K, L | 100GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 검색 데이터베이스를 포함하는 데이터베이스 서버 | O, P, Q, R | 500GB | 16GB | 1.8GHz CPU 코어 4개 | 1Gbps |
1CPU 코어 수는 CPU 스레드 수가 아니라 여기에서 지정됩니다.
2SharePoint Server 2013을 사용하면 필요한 최소 리소스 크기는 500GB 스토리지, 16GB RAM 및 4개의 CPU 코어입니다.
3SharePoint Server 2016에서는 250GB 스토리지, 16GB RAM 및 4개의 CPU 코어를 사용할 수도 있지만 각 인덱스 구성 요소는 1,000만 개의 항목만 보유할 수 있으며 검색 팜은 SharePoint Server 2013 검색 팜과 동일한 양의 콘텐츠만 지원합니다.
초대형 검색 팜의 최소 하드웨어 리소스
이 표에서는 각 응용 프로그램 서버 또는 데이터베이스 서버에 필요한 최소 하드웨어 리소스 크기가 나와 있습니다. SharePoint Server 2016을 사용하여 이 샘플 팜만 빌드할 수 있습니다.
| 서버 | 호스트 | Storage | RAM | 프로세서1 | 네트워크 대역폭 |
|---|---|---|---|---|---|
| 인덱스 구성 요소가 있는 응용 프로그램 서버 | A-X | 500GB | 32GB | 1.8GHz CPU 코어 8개 | 1Gbps |
| 쿼리 처리 및 인덱스 구성 요소가 있는 응용 프로그램 서버 | Y, Z | 500GB | 32GB | 1.8GHz CPU 코어 8개 | 1Gbps |
| 크롤링, 검색 관리 또는 콘텐츠 처리 구성 요소가 있는 응용 프로그램 서버 | AA-AF | 100GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 분석 처리 구성 요소가 있는 응용 프로그램 서버 | AG, AH | 800GB | 8GB | 1.8GHz CPU 코어 4개 | 1Gbps |
| 검색 데이터베이스를 포함하는 데이터베이스 서버 | AI-AL | 500GB | 16GB | 1.8GHz CPU 코어 4개 | 1Gbps |
1CPU 코어 수는 CPU 스레드 수가 아니라 여기에서 지정됩니다.
저장소 성능 계획
저장소의 속도는 검색 성능에 영향을 줍니다. 사용 중인 저장소가 검색 구성 요소 및 데이터베이스의 트래픽을 처리할 수 있을 정도로 충분히 빠른지 확인하세요. 디스크 속도는 IOPS(초당 I/O 작업 수)로 측정됩니다.
검색 구성 요소 및 운영 체제의 데이터를 저장소에 배포하려는 방법은 검색 성능에 영향을 줍니다. 다음과 같이 하는 것이 좋습니다.
일반 성능을 갖는 세 개의 별도 저장소 볼륨 또는 파티션에 Windows Server 운영 체제 파일, SharePoint Server 프로그램 파일 및 진단 로그를 분할합니다.
검색 구성 요소 데이터를 뛰어난 성능의 저장소 볼륨 또는 파티션에 별도로 저장합니다.
참고
호스트에 SharePoint Server를 설치할 때 검색 구성 요소 데이터에 대한 사용자 지정 위치를 설정할 수 있습니다. 데이터를 저장해야 하는 호스트의 모든 검색 구성 요소는 데이터를 이 위치에 저장합니다. 나중에 이 위치를 변경하려면 해당 호스트에 SharePoint Server를 다시 설치해야 합니다.
저장소 선택
스토리지 아키텍처 및 디스크 유형에 대한 개요는 스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server)을 참조하세요. 인덱스 또는 분석 처리 구성 요소 또는 검색 데이터베이스를 호스트하는 서버에는 짧은 대기 시간을 유지하면서 IOPS(초당 충분한 I/O 작업)를 제공할 수 있는 스토리지가 필요합니다. 다음 표에는 이러한 각 검색 구성 요소 및 데이터베이스에 필요한 IOPS가 나와 있습니다.
SAN/NAS와 같은 공유 저장소를 배포할 경우 검색 구성 요소 하나의 최대 디스크 부하는 일반적으로 다른 검색 구성 요소의 최대 디스크 부하와 일치합니다. 공유 저장소에서 검색에 필요한 IOPS를 확보하려면 이러한 각 구성 요소에 대한 IOPS 요구 사항을 추가해야 합니다.
검색 구성 요소 IOPS 요구 사항
| 구성 요소 이름 | 구성 요소 정보 | IOPS 요구 사항 | 별도의 저장소 볼륨/파티션 사용 |
|---|---|---|---|
| 인덱스 구성 요소 | 인덱스를 병합할 때와 쿼리를 처리하고 쿼리에 응답할 때 저장소를 사용합니다. | 64KB 임의 읽기의 경우 300IOPS 256KB 임의 쓰기의 경우 100IOPS 순차적 읽기의 경우 200MB/s 순차적 쓰기의 경우 200MB/s |
예 |
| 분석 구성 요소 | 로컬로 대량 처리되는 데이터를 분석합니다. | 아니요 | 예 |
| 크롤링 구성 요소 | 다운로드한 콘텐츠를 콘텐츠 처리 구성 요소로 보내기 전에 로컬로 저장합니다. 저장소는 네트워크 대역폭에 따라 제한됩니다. | 아니요 | 예 |
검색 데이터베이스 IOPS 요구 사항
| 데이터베이스 이름 | IOPS 요구 사항 | I/O 하위 시스템의 일반적인 부하 |
|---|---|---|
| 크롤링 데이터베이스 | 보통~높은 IOPS | 1 DPS(초당 문서 수)당 10 IOPS의 크롤링 속도 |
| 링크 데이터베이스 | 보통 IOPS | 검색 인덱스의 항목 100만 개당 10 IOPS |
| 검색 관리 데이터베이스 | 낮은 IOPS | 해당 없음 |
| 분석 보고 데이터베이스 | 보통 IOPS | 해당 없음 |
검색 아키텍처에서 고가용성을 지원하는 방식 선택
고가용성 전략에 익숙하지 않은 경우 SharePoint Server에 대한 고가용성 아키텍처 및 전략 만들기를 시작하는 문서를 참조하세요. 별도의 장애 도메인에서 중복 검색 구성 요소 및 데이터베이스를 호스팅하는 경우 검색 아키텍처에서 고가용성을 지원합니다. 모든 예제 검색 아키텍처는 독립된 서버에서 중복 검색 구성 요소를 호스팅합니다.
검색 아키텍처의 각 중복 호스트 서버에 대해 다음을 설치할 계획을 세워야 합니다.
중복 네트워킹
독립된 배선 또는 UPS(무정전 전원 공급 장치)가 있는 중복 전원 공급 장치
4단계: 검색 아키텍처가 원활하게 작동하는지 확인하는 방법
검색 아키텍처를 프로덕션 환경에 배포하기 전에 검색 아키텍처가 원활하게 작동하는지 확인해야 합니다. 다음은 수행할 작업에 대한 검사 목록입니다.
인덱스 구성 요소가 충분한 IOPS가 있는 스토리지 I/O 하위 시스템을 사용하는지 테스트합니다. 스토리지 I/O 하위 시스템 테스트를 참조하세요.
검색 아키텍처를 파일럿 환경에 배포합니다. 파일럿 환경이 프로덕션 환경을 그대로 반영하는지 확인합니다.
파일럿 환경의 검색 성능을 테스트합니다. 검색 성능 테스트를 참조하세요.
SharePoint의 일반적인 테스트 개요는 SharePoint Server 2013에 대한 성능 테스트를 참조하세요.
저장소 I/O 하위 시스템 테스트
저장소 I/O 하위 시스템을 테스트하려면 가장 중요한 디스크 작업을 실행하여 IOPS를 측정합니다. DiskSpd 도구를 사용하여 이러한 테스트를 실행할 수 있습니다. DiskSpd: 강력한 스토리지 성능 도구를 참조하세요.
테스트 환경 설정
전체 검색 아키텍처를 설정하거나 SharePoint Server를 설치할 필요가 없습니다. 저장소 I/O 하위 시스템에 대한 실제 작업량을 생성하는 테스트 환경만 설정하면 됩니다.
로컬 저장소에 대한 사례를 고려해 보겠습니다. 예를 들어 중간 규모 검색 팜의 호스트 A에서 로컬 디스크를 사용하는 경우 가상 컴퓨터 두 대를 설치하고 두 가상 컴퓨터에서 디스크 작업 테스트를 동시에 실행해야 합니다.
공유 저장소에 대한 다른 설정이 필요합니다. 예를 들어 중간 규모 검색 팜에 있는 모든 인덱스 구성 요소의 작업량과 함께 관련 없는 다른 작업량에서 같은 저장소를 공유하는 경우 다음과 같이 해야 합니다.
호스트 A, B, C 및 D에 8대의 가상 컴퓨터를 설치하고 관련 없는 작업량의 원본을 설정합니다.
호스트 A, B, C 및 D의 모든 가상 컴퓨터에서 동시 디스크 작업 테스트를 실행할 때 관련 없는 작업량이 공유 저장소에 동시에 적용되는지 확인합니다.
테스트 파일 만들기
명령을
diskspd -c256G testfile사용하여 256GiBytes 테스트 파일을 만듭니다. 이 명령은 "testfile"이라는 256GiBytes 크기 파일을 만듭니다. 구문에 따라 다른 크기의 파일을 만들 수도 있습니다.diskspd -c<size>[K|M|G|b] <filename>테스트하려는 스토리지 디바이스에 테스트 파일을 저장합니다. 예: 중간 팜의 호스트 A 하드 디스크에 있습니다.
서버를 다시 시작합니다. 그러면 캐싱으로 인해 테스트 결과가 왜곡되는 상황이 발생하지 않습니다.
테스트 실행
다음을 측정하는 것이 좋습니다.
중간 규모 임의 액세스의 성능(아래의 테스트 번호 1 및 2 참조)
대용량 전송에 대한 읽기 및 쓰기 처리량(아래의 테스트 번호 3 및 4 참조)
아래 표에서는 각 테스트를 실행하는 데 사용해야 하는 DiskSpd 명령을 보여 줍니다. 모든 명령에서는 "testfile"이 현재 디렉터리에 있는 것으로 가정합니다. 각 테스트는 300초 동안 실행됩니다.
| 테스트 번호 | 범위 | 명령 |
|---|---|---|
| 1 | 64KB 읽기[IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | 256KB 쓰기[IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | 100MB 읽기[MB/s] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | 100MB 쓰기[MB/s] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
로컬 디스크 저장소에 대한 결과 예
아래 표의 예제 결과에서는 테스트 파일을 추가하기 전에 디스크 하위 시스템 용량의 최소 50%가 사용되고 있었던 배포를 보여 줍니다.
디스크의 스핀들 및 디스크 컨트롤러는 이러한 결과에 많은 영향을 줍니다.
빈 디스크에서 테스트하는 경우 테스트 파일이 모든 스핀들(짧은 쓰다듬기)에서 가장 최적의 트랙에 있기 때문에 상승된 결과를 얻을 수 있습니다. 이렇게 하면 성능을 최대 2~3배까지 높일 수 있습니다. 초기화되지 않은 스토리지 공간에서 액세스를 최적화하는 하드 디스크 또는 모든 0이 포함된 스토리지(예: 동적 VHD/VHDX 파일)를 테스트하는 경우 비현실적으로 높은 결과를 얻을 수 있습니다. 이 경우 DiskSpd 명령을 사용하여 가상 테스트 파일을 생성하는 대신 실제 데이터가 포함된 매우 큰 테스트 파일을 사용합니다.
| 디스크 레이아웃 | 테스트 1 | 테스트 2 | 테스트 3 | 테스트 4 | |
| 일상적인 작업 중의 권장 최소 IOPS | 300 | 100 | 200 | 200 | |
| 1TB 7200 RPM NLSAS 4개 - Dell H710 RAID 컨트롤러의 RAID5(스트라이프 크기 64KB, 블록 크기 64KB) | 1181 | 206 | 284 | 296 | |
| 1TB 7200 RPM NLSAS 8개 - Dell H710 RAID 컨트롤러의 RAID5(스트라이프 크기 64KB, 블록 크기 64KB) | 2082 | 337 | 610 | 645 | |
| 1TB 7200 RPM NLSAS 16개 - Dell H710 RAID 컨트롤러의 RAID5(스트라이프 크기 64KB, 블록 크기 64KB) | 3763 | 595 | 1173 | 1181 | |
| 1TB 7200 RPM NLSAS 16개(2x8) - Dell H710 RAID 컨트롤러의 RAID50(스트라이프 크기 64KB, 블록 크기 64KB) | 3613 | 545 | 1139 | 1164 | |
| 1TB 7200 RPM NLSAS 16개 - Dell H710 RAID 컨트롤러의 RAID10(스트라이프 크기 256KB, 블록 크기 64KB) | 4030 | 1146 | 970 | 775 | |
| SmartStorage Optimus 800GB SSD 4개 - Dell H710 RAID 컨트롤러의 RAID5(스트라이프 크기 64KB, 블록 크기 64KB) | 32385 | 3781 | 1714 | 1319 | |
| SmartStorage Optimus 800GB SSD 4개 - Dell H710 RAID 컨트롤러의 RAID0(스트라이프 크기 256KB, 블록 크기 64KB) | 31747 | 7149 | 1643 | 1798 |
검색 성능 테스트
다음은 검색 아키텍처를 테스트하기 위해 수행할 작업에 대한 검사 목록입니다.
테스트를 실행할 콘텐츠 선택
프로덕션 콘텐츠를 잘 나타내는 콘텐츠를 선택합니다. 테스트용으로만 사용되는 콘텐츠를 선택할 경우 여러 번 복제한 하나의 항목뿐 아니라 여러 유형의 항목이 있는지 확인해야 합니다. 이는 쿼리 프로세서에서 중복 항목을 검색하는 데 시간을 소비하고 이로 인해 검색 성능이 영향을 받으므로 결과가 프로덕션 환경을 그대로 반영하지 않기 때문입니다.
콘텐츠를 크롤링할 콘텐츠 원본을 하나 이상 설정합니다. 필요한 사용자 계정 및 네트워크 액세스 권한이 있는지 확인합니다.
쿼리 성능을 테스트할 용어 및 구 선택
쿼리를 통해 얻은 결과 수를 회수라고 합니다.
쿼리 성능을 테스트하려면 먼저 쿼리로 사용할 용어 및 구 집합을 만들어야 합니다. 또는 기존 설치에서 쿼리를 수집합니다. 이 집합에는 회수가 높고 낮은 용어 및 구, 그리고 환경과 관련이 있는 용어 및 구를 포함해야 합니다.
예제
제품 카탈로그에서 제품 수를 검색한 경우 하나의 제품이 하나만 있을 수 있습니다. 이 경우 검색 결과를 빠르게 얻게 됩니다. 이는 낮은 회수입니다.
회사 인트라넷에서 "프레젠테이션"과 같은 일반 용어를 검색한 경우 많은 결과를 얻을 수 있으며 결과를 얻는 데 시간이 오래 걸릴 수 있습니다. 이는 높은 회수입니다.
예를 들어 콘텐츠가 인적 자원과 관련이 있는 경우 이 영역과 관련된 검색 용어를 사용합니다.
검색 성능 측정
SharePoint Server는 크롤링 상태 보고서 및 쿼리 상태 보고서에서 검색 성능 측정값을 수집합니다. 이러한 보고서는 중앙 관리의 검색 관리에서 확인할 수 있습니다.
먼저 가상 부하를 사용하여 검색 성능을 측정한 다음 소량의 활성 사용자 및 활성 콘텐츠로 검색 성능을 측정하는 것이 좋습니다. 활성 사용자 및 활성 콘텐츠를 사용할 경우 검색 아키텍처의 작동 방식을 관찰할 수 있습니다. 콘텐츠가 의도한 것보다 빠르게 증가하면 그보다 한 단계 더 큰 규모의 검색 아키텍처를 사용하는 것이 좋을 수 있습니다. 또는 사용자가 예상보다 더 활발하게 활동하는 경우 분석 데이터베이스의 스토리지 공간을 늘리는 것이 좋습니다.