저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server 2010)
적용 대상: SharePoint Foundation 2010, SharePoint Server 2010
마지막으로 수정된 항목: 2016-11-30
이 문서에서는 Microsoft SharePoint Server 2010 환경에서 저장소 및 Microsoft SQL Server 데이터베이스 계층을 계획 및 구성하는 방법에 대해 설명합니다.
이 문서에 나와 있는 용량 계획 정보는 계획 수립 과정에 지침으로 활용할 수 있습니다. 이 정보는 Microsoft에서 실제 속성에 대해 수행한 테스트 결과를 기반으로 합니다. 그러나 사용하는 장비 및 사이트에 대해 구현하는 기능에 따라 결과는 달라질 수 있습니다.
SharePoint Server는 해당 데이터베이스를 별도의 SQL Server 데이터베이스 관리자가 관리하는 환경에서 사용되는 경우가 많기 때문에 이 문서는 SharePoint Server 팜 구현 전문가와 SQL Server 데이터베이스 관리자가 모두 활용할 수 있도록 작성되었습니다. 또한 이 문서에서는 SharePoint Server 및 SQL Server에 대한 이해 수준이 매우 높은 것으로 가정하고 있습니다.
이 문서에서는 SharePoint Server 2010의 용량 관리 및 크기 조정에 나와 있는 개념에 이미 익숙한 것으로 가정합니다.
SharePoint 2010 제품 저장소 및 데이터베이스 계층에 대한 디자인 및 구성 프로세스
저장소 및 데이터베이스 계층 디자인 프로세스는 다음 단계로 나누는 것이 좋습니다. 각 섹션에서는 저장소 요구 사항 및 최상의 방법을 포함하여 각 디자인 단계에 대한 세부 정보를 제공합니다.
저장소 및 SQL Server의 공간 및 I/O 요구 사항 수집
SQL Server 버전 및 에디션 선택
용량 및 I/O 요구 사항에 따른 저장소 아키텍처 디자인
메모리 요구 사항 예측
네트워크 토폴로지 요구 사항 이해
SQL Server 구성
저장소 성능 및 안정성에 대한 유효성 검사
저장소 및 SQL Server의 공간 및 I/O 요구 사항 수집
저장소 디자인에 영향을 주는 SharePoint Server 2010 아키텍처 관련 요소는 다양하며, 주요 요소로는 콘텐츠의 양, 사용되는 기능 및 서비스 응용 프로그램, 팜의 수, 가용성 요구 사항 등이 있습니다.
저장소 계획을 시작하기 전에 먼저 SharePoint Server 2010에서 사용할 수 있는 데이터베이스에 대해 이해해야 합니다.
이 섹션의 내용:
SharePoint 2010 제품에서 사용되는 데이터베이스
SQL Server 및 IOPS 이해
저장소 및 IOPS 관련 핵심 요구 사항 예측
서비스 응용 프로그램 저장소 및 IOPS 요구 사항 확인
가용성 요구 사항 확인
SharePoint 2010 제품에서 사용되는 데이터베이스
SharePoint Server 2010과 함께 설치되는 데이터베이스는 해당 환경에서 사용 중인 기능에 따라 달라집니다. 모든 SharePoint 2010 제품 환경은 SQL Server 시스템 데이터베이스를 사용합니다. 이 섹션에서는 SharePoint Server 2010과 함께 설치되는 데이터베이스에 대한 요약 정보를 제공합니다. 자세한 내용은 데이터베이스 형식 및 설명(SharePoint Server 2010) 및 데이터베이스 모델(https://go.microsoft.com/fwlink/p/?LinkId=187968)을 참조하세요.
| 제품 버전 및 에디션 | 데이터베이스 |
|---|---|
SharePoint Foundation 2010 |
구성 중앙 관리 콘텐츠 콘텐츠(하나 이상) Usage and Health Data Collection 비즈니스 데이터 연결 Application Registry Service(Microsoft Office SharePoint Server 2007 비즈니스 데이터 카탈로그에서 업그레이드하는 경우) 가입 설정 서비스(Windows PowerShell을 통해 사용하도록 설정된 경우) |
SharePoint Server 2010 Standard Edition용 추가 데이터베이스 |
Search Service 응용 프로그램:
User Profile Service 응용 프로그램:
Web Analytics Service 응용 프로그램
Secure Store 상태 관리되는 메타데이터 Word Automation Services |
SharePoint Server 2010 Enterprise Edition용 추가 데이터베이스 |
PerformancePoint |
Project Server 2010용 추가 데이터베이스 |
임시 게시된 보관 보고 |
FAST Search Server용 추가 데이터베이스 |
검색 관리 |
SQL Server와 보다 완전하게 통합하는 경우 다음 시나리오에서처럼 환경에 추가 데이터베이스가 포함될 수도 있습니다.
Microsoft SQL Server 2008 R2 PowerPivot for Microsoft SharePoint 2010은 SQL Server 2008 R2 Enterprise Edition 및 SQL Server Analysis Services가 포함된 SharePoint Server 2010 환경에서 사용할 수 있습니다. 또한 사용 시에는 시스템에 가중되는 부하와 PowerPivot 응용 프로그램 데이터베이스를 지원하기 위한 계획을 세워야 합니다. 자세한 내용은 SharePoint 팜에서 PowerPivot 배포 계획(https://go.microsoft.com/fwlink/p/?LinkID=186698)을 참조하세요.
Microsoft SQL Server 2008 Reporting Services(SSRS) 플러그 인은 모든 SharePoint 2010 제품 환경에서 사용할 수 있습니다. 플러그 인을 사용하는 경우에는 두 SQL Server 2008 Reporting Services 데이터베이스와 SQL Server 2008 Reporting Services에 요구되는 추가 부하를 지원하기 위한 계획을 세웁니다.
SQL Server 및 IOPS 이해
SQL Server를 호스팅하는 모든 서버에서는 I/O 하위 시스템에서 가장 빠른 응답 속도를 얻어야 한다는 점이 매우 중요합니다.
보다 많고 더 빠른 디스크 또는 배열은 충분한 IOPS(초당 I/O 작업 수)를 제공하는 동시에 모든 디스크에서 대기 시간 및 대기 행렬을 작게 유지합니다.
다른 유형의 리소스(예: CPU 또는 메모리)를 추가해도 I/O 하위 시스템의 응답 속도가 향상되지는 않으며 느린 응답 속도는 팜 전체에 영향을 미쳐 문제를 일으킬 수 있습니다. 따라서 배포 전에 대기 시간을 최소화하기 위한 계획을 세우고 기존 시스템을 모니터링해야 합니다.
새 팜을 배포하기 전에 SQLIO Disk Subsystem Benchmark Tool을 사용하여 I/O 하위 시스템을 벤치마크하는 것이 좋습니다. 자세한 내용은 SQLIO Disk Subsystem Benchmark Tool(https://go.microsoft.com/fwlink/p/?LinkID=105586)을 참조하세요.
SQL Server 측면에서 IOPS 요구 사항을 분석하는 방법에 대한 자세한 내용은 SQL Server 데이터베이스 응용 프로그램에 대한 I/O 요구 사항 특성 분석 및 저장소 시스템 크기 조정(https://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristics-and-sizing-storage-systems-for-sql-server-database-applications.aspx)을 참조하십시오.
저장소 및 IOPS 관련 핵심 요구 사항 예측
구성 및 콘텐츠 저장소와 IOPS는 모든 SharePoint Server 2010 배포에서 반드시 계획해야 하는 기본 계층입니다.
구성 저장소 및 IOPS
구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스에 대한 저장소 요구 사항은 크지 않습니다. 구성 데이터베이스에 대해서는 2GB, 중앙 관리 콘텐츠 데이터베이스에 대해서는 1GB를 각각 할당하는 것이 좋습니다. 시간이 지남에 따라 구성 데이터베이스는 용량이 1GB를 초과할 수 있지만, 5만 개의 사이트 모음마다 40MB 정도씩 늘어나므로 증가 속도가 빠르지는 않습니다.
구성 데이터베이스의 트랜잭션 로그는 용량이 클 수 있으므로 데이터베이스에 대한 복구 모델을 전체 복구에서 단순 복구로 변경하는 것이 좋습니다.
참고
SQL Server 데이터베이스 미러링을 사용하여 구성 데이터베이스에 대한 가용성을 제공하려는 경우에는 전체 복구 모델을 사용해야 합니다.
구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스에 대한 IOPS 요구 사항은 최소 수준입니다.
콘텐츠 저장소 및 IOPS
콘텐츠 데이터베이스에 필요한 저장소 및 IOPS를 예측하는 일은 정밀하게 수행되는 작업이 아닙니다. 다음 정보를 테스트 및 설명하는 과정을 잘 살펴보면 초기 배포 규모를 결정하는 데 사용할 근사값을 손쉽게 얻을 수 있을 것입니다. 그러나 환경이 실행 중인 경우에는 실제 환경의 데이터를 토대로 용량 요구 사항을 조정해야 합니다.
전체 용량 계획 방법에 대한 자세한 내용은 SharePoint Server 2010의 용량 관리 및 크기 조정을 참조하십시오.
콘텐츠 데이터베이스 저장소 예측
다음 프로세스에서는 로그 파일을 제외하고 콘텐츠 데이터베이스에 필요한 저장소를 대략적으로 예측하는 방법을 설명합니다.
예상 문서 수를 계산합니다. 이 값은 수식에서 D로 나타냅니다.
문서 수를 계산하는 방식은 사용하는 기능에 따라 결정됩니다. 예를 들어 내 사이트 또는 공동 작업 사이트의 경우 사용자별 예상 문서 수를 계산한 다음 여기에 사용자 수를 곱하는 것이 좋습니다. 또한 레코드 관리 또는 콘텐츠 게시 사이트의 경우에는 프로세스를 통해 관리 및 생성되는 문서의 수를 계산할 수 있습니다.
현재 시스템에서 마이그레이션하는 경우에는 현재 증가율 및 사용량을 추정하기가 더 쉬울 수 있습니다. 새 시스템을 만드는 경우 기존 파일 공유 또는 다른 저장소를 검토하고 해당 사용률을 토대로 예측합니다.
저장할 평균 문서 크기를 예측합니다. 이 값은 수식에서 S로 나타냅니다. 각기 다른 사이트 유형 또는 그룹에 대한 평균치를 예측하는 것도 도움이 될 수 있습니다. 내 사이트, 미디어 저장소 및 다양한 부서 포털의 평균 파일 크기는 크게 다를 수 있습니다.
환경의 목록 항목 수를 예측합니다. 이 값은 수식에서 L로 나타냅니다.
목록 항목은 문서보다 예측하기가 어렵습니다. 일반적으로 문서 수(D)의 세 배에 해당하는 근사값을 사용하지만 이는 사이트를 사용하는 방식에 따라 달라집니다.
대략적인 버전 수를 구합니다. 라이브러리의 모든 문서에 지정되는 평균 버전 수를 예측합니다. 이 값은 대개 최대 허용 버전 수보다 훨씬 작으며 수식에서 V로 나타냅니다.
V 값은 0보다 커야 합니다.
다음 수식을 사용하여 콘텐츠 데이터베이스의 크기를 예측합니다.
데이터베이스 크기 = ((D × V) × S) + (10KB × (L + (V × D)))
수식의 값 10KB는 SharePoint Server 2010에 필요한 메타데이터의 양을 대략적으로 예측한 상수입니다. 시스템에서 많은 양의 메타데이터를 사용해야 하는 경우 이 상수를 늘려야 합니다.
예를 들어 수식을 사용하여 다음과 같은 특성의 공동 작업 환경에 있는 콘텐츠 데이터베이스의 데이터 파일에 요구되는 저장 공간을 예측하려는 경우 약 105GB가 필요합니다.
| 입력 | 값 |
|---|---|
문서 수(D) |
200,000 10,000명의 사용자와 20개의 문서를 곱한 것으로 가정하여 계산 |
평균 문서 크기(S) |
250KB |
목록 항목(L) |
600,000 |
최신 버전이 아닌 버전의 수(V) |
2 허용되는 최대 버전 수를 10으로 가정 |
데이터베이스 크기 = (((200,000 x 2)) × 250) + ((10KB × (600,000 + (200,000 x 2))) = 110,000,000KB 또는 105GB
콘텐츠 데이터베이스의 크기에 영향을 주는 기능
다음과 같은 SharePoint Server 2010 기능을 사용하면 콘텐츠 데이터베이스의 크기에 많은 영향을 미칠 수 있습니다.
휴지통 문서는 1단계 휴지통과 2단계 휴지통에서 모두 완전히 삭제될 때까지 콘텐츠 데이터베이스의 공간을 차지하게 됩니다. 매월 삭제되는 문서의 수를 계산하여 휴지통이 콘텐츠 데이터베이스의 크기에 미치는 영향을 확인합니다. 자세한 내용은 휴지통 설정 구성(SharePoint Server 2010)을 참조하십시오.
감사 감사 보기가 설정된 경우 등에는 감사 데이터가 빠른 속도로 혼합되어 콘텐츠 데이터베이스에서 많은 공간을 차지하게 됩니다. 감사 데이터가 아무런 제한 없이 증가하도록 하는 대신 규제 요구 사항 또는 내부 관리 요건을 충족하는 데 중요한 역할을 하는 이벤트에 대해서만 감사를 사용하도록 설정하는 것이 좋습니다. 다음 지침을 활용하여 감사 데이터에 대해 사용하도록 예약해야 하는 공간을 예측합니다.
사이트에 대한 새 감사 항목 수를 예측하고 이 수치에 2KB를 곱합니다(항목은 대개 4KB로 제한되며 평균 크기는 약 1KB임).
할당하려는 공간에 따라 감사 로그를 유지할 일 수를 결정합니다.
Office Web Apps. Office Web Apps를 사용하는 경우 Office Web Apps 캐시는 콘텐츠 데이터베이스의 크기에 많은 영향을 줄 수 있습니다. 기본적으로 Office Web Apps 캐시는 100GB로 구성됩니다. Office Web Apps 캐시의 크기에 대한 자세한 내용은 Office Web Apps 캐시 관리를 참조하십시오.
콘텐츠 데이터베이스 IOPS 요구 사항 예측
콘텐츠 데이터베이스의 IOPS 요구 사항은 환경이 사용되는 방식과 보유한 디스크 공간의 양 및 서버 수에 따라 크게 달라집니다. 일반적으로 환경의 예측 작업량과 Microsoft에서 테스트한 솔루션 중 하나를 비교하는 것이 좋습니다. 자세한 내용은 성능 및 용량 테스트 결과와 권장 사항(SharePoint Server 2010)을 참조하십시오.
중요
이 섹션의 내용에 대한 테스트는 아직 완료되지 않았습니다. 추가 정보는 나중에 다시 확인하십시오.
서비스 응용 프로그램 저장소 요구 사항 및 IOPS 예측
콘텐츠 저장소 및 IOPS 요구 사항을 예측한 후에는 환경에서 현재 사용되는 서비스 응용 프로그램에 필요한 저장소 및 IOPS를 결정해야 합니다.
SharePoint Server 2010 서비스 응용 프로그램 저장소 및 IOPS 요구 사항
시스템의 서비스 응용 프로그램에 대한 저장소 요구 사항을 예측하려면 먼저 서비스 응용 프로그램과 해당 응용 프로그램을 사용하는 방식을 확인해야 합니다. 다음 표에는 SharePoint Server 2010에서 사용할 수 있는 데이터베이스가 포함된 서비스 응용 프로그램이 나와 있습니다.
| 서비스 응용 프로그램 | 크기 예측 권장 사항 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
검색 |
검색에는 세 개의 데이터베이스가 필요합니다. 환경에는 여러 속성 데이터베이스와 크롤링 데이터베이스가 포함될 수 있습니다. 검색 관리 데이터베이스는 일반적으로 크기가 작습니다(10GB 할당). 속성 및 크롤링 데이터베이스에 필요한 저장 용량을 예측하려면 다음 곱셈식을 사용합니다.
검색에 대한 IOPS 요구 사항은 높습니다.
검색에 필요한 용량을 예측하는 방법에 대한 자세한 내용은 성능 및 용량 테스트 결과와 권장 사항(SharePoint Server 2010)을 참조하십시오. FAST Search Server 2010 for SharePoint에는 다른 아키텍처가 있습니다. 크롤링 데이터베이스의 IOPS 요구 사항은 동일하지만, 속성 데이터베이스는 사용자 검색에만 사용되며 추가적인 검색 관리 데이터베이스가 있습니다. FAST Search Server 2010 for SharePoint에 대한 자세한 내용은 검색 토폴로지 계획(FAST Search Server 2010 for SharePoint) 및 성능 및 용량 관리(FAST Search Server 2010 for SharePoint)를 참조하세요. |
||||||||
사용자 프로필 |
User Profile Service 응용 프로그램은 세 개의 데이터베이스(프로필, 동기화 및 공유 태그 지정)와 연결되어 있습니다. 데이터베이스에 필요한 저장 용량을 예측하려면 다음 정보를 활용합니다.
16만 개의 사용자 프로필, 5개의 그룹, 7만 9천 개의 태그, 메모 및 등급(메모 2천 5백 개, 태그 7만 6천 개, 등급 8백 개)과 기본 설정이 포함된 실제 공동 작업 환경의 경우 위의 세 데이터베이스의 크기는 다음과 같습니다.
|
||||||||
관리되는 메타데이터 |
Managed Metadata Service 응용 프로그램에는 하나의 데이터베이스가 포함되어 있습니다. 데이터베이스의 크기는 시스템에서 사용되는 콘텐츠 형식 및 키워드의 수에 의해 영향을 받습니다. 많은 환경에는 여러 개의 Managed Metadata Service 응용 프로그램 인스턴스가 포함됩니다. |
||||||||
Web Analytics |
Web Analytics에는 두 개의 데이터베이스(준비 및 보고)가 있습니다. 이러한 데이터베이스에는 보존 기간, 일일 데이터 볼륨 추적량, 분석되는 웹 응용 프로그램에 있는 사이트 모음, 사이트 및 하위 사이트의 수가 포함됩니다. 이들 데이터베이스의 크기 및 IOPS 요구 사항을 예측하는 방법에 대한 자세한 내용은 성능 및 용량 테스트 결과와 권장 사항(SharePoint Server 2010)을 참조하십시오. |
||||||||
Secure Store |
Secure Store Service 응용 프로그램 데이터베이스의 크기는 저장소에 있는 자격 증명의 수와 감사 테이블의 항목 수에 따라 결정됩니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다. |
||||||||
상태 |
State Service 응용 프로그램에는 하나의 데이터베이스가 포함되어 있습니다. 이 데이터베이스의 경우 1GB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다. |
||||||||
Word Automation Service |
Word Automation Service 응용 프로그램에는 하나의 데이터베이스가 포함되어 있습니다. 이 데이터베이스의 경우 1GB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다. |
||||||||
PerformancePoint |
PerformancePoint Service 응용 프로그램에는 하나의 데이터베이스가 포함되어 있습니다. 이 데이터베이스의 경우 1GB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다. |
가용성 요구 사항 확인
가용성은 사용자가 SharePoint Server 2010 환경을 사용 가능하다고 인식하는 수준입니다. 사용 가능한 시스템은 복원력 있는 시스템을 의미합니다. 즉, 서비스에 영향을 주는 사고가 부정기적으로 발생하는 데, 이러한 사고가 발생할 경우 효과적인 조치가 제때 취해지는 시스템을 말합니다.
가용성 요구 사항에 따라 저장소 요구 사항이 크게 증가할 수 있습니다. 자세한 내용은 가용성 계획(SharePoint Server 2010)을 참조하십시오.
SQL Server 버전 및 에디션 선택
SharePoint 2010 제품은 Microsoft SQL Server 2008 R2, SQL Server 2008 또는 SQL Server 2005에서 실행할 수도 있지만 제품에 내재된 추가 성능, 가용성, 보안 및 관리 기능을 십분 활용하려면 환경을 SQL Server 2008 또는 SQL Server 2008 R2 Enterprise Edition에서 실행하는 것이 좋습니다. SQL Server 2008 R2 Enterprise Edition을 사용하는 이점에 대한 자세한 내용은 SQL Server 2008 R2 및 SharePoint 2010 제품: 함께 사용할 때의 이점(백서)(SharePoint Server 2010)을 참조하십시오.
특히, 다음 기능에 대한 요구 사항을 고려해야 합니다.
백업 압축 백업 압축은 SharePoint 백업의 속도를 높일 수 있으며 SQL Server 2008 Enterprise Edition 또는 SQL Server 2008 R2 Standard Edition에서 사용할 수 있습니다. 백업 스크립트에서 압축 옵션을 설정하거나 SQL Server를 실행하는 서버에서 기본적으로 압축을 수행하도록 서버를 구성하면 데이터베이스 백업 및 전달되는 로그의 크기를 대폭 줄일 수 있습니다. 자세한 내용은 백업 압축(SQL Server)(https://go.microsoft.com/fwlink/p/?LinkId=129381)을 참조하세요.
참고
Search Service 응용 프로그램 데이터베이스를 제외하고는 SQL Server 데이터 압축을 SharePoint 2010 제품에서 사용할 수 없습니다.
투명한 데이터 암호화 보안 요구 사항에 투명한 데이터 암호화에 대한 요구 사항이 포함되어 있는 경우 SQL Server Enterprise Edition을 사용해야 합니다.
Web Analytics Service 응용 프로그램 중요한 분석을 위해 Web Analytics Service 응용 프로그램을 사용하려는 경우 시스템에서 테이블 분할 기능을 활용할 수 있도록 SQL Server Enterprise Edition 사용을 고려하십시오.
콘텐츠 배포 콘텐츠 배포 기능을 사용하려는 경우 시스템에서 SQL Server 데이터베이스 스냅숏을 활용할 수 있도록 SQL Server Enterprise Edition 사용을 고려하십시오.
원격 BLOB 저장소 각 콘텐츠 데이터베이스와 연결된 파일 외부에 있는 위치 또는 데이터베이스에 대해 원격 BLOB 저장소를 활용하려는 경우 SQL Server 2008 또는 SQL Server 2008 R2 Enterprise Edition을 사용해야 합니다.
리소스 관리자 리소스 관리자는 SQL Server 2008에 도입된 기술로, 들어오는 요청에서 사용하는 리소스 소모량에 대해 한도를 설정하는 방식으로 SQL Server 작업량 및 리소스를 관리할 수 있도록 합니다. 리소스 관리자를 사용하면 설정한 한도에 따라 작업량을 분화하고 CPU 및 메모리를 요청된 만큼 할당할 수 있습니다. 이 기능은 SQL Server 2008 또는 SQL Server 2008 R2 Enterprise Edition에서만 사용할 수 있습니다. 리소스 관리자를 사용하는 방법에 대한 자세한 내용은 리소스 관리자로 SQL Server 작업 관리를 참조하세요.
다음 작업을 수행할 때 리소스 관리자와 SharePoint Server 2010을 함께 사용하는 것이 좋습니다.
검색 크롤링 구성 요소의 대상으로 지정된 웹 서버가 사용하는 SQL Server 리소스의 양 제한. 최상의 방법으로, 시스템에 부하가 적용될 때 크롤링 구성 요소를 10%의 CPU로 제한하는 것이 좋습니다.
시스템의 각 데이터베이스에서 사용되는 리소스의 수 모니터링. 예를 들어 리소스 관리자를 사용하면 SQL Server가 실행되는 컴퓨터 중에서 최적의 데이터베이스 배치를 손쉽게 결정할 수 있습니다.
PowerPivot for SharePoint 2010 사용자가 Excel 및 브라우저에서 자신이 생성한 데이터 모델 및 분석 결과를 공유하고 이를 공동으로 작업하는 동시에 이러한 분석 결과를 새로 고칠 수 있도록 하며, SQL Server 2008 R2 Enterprise Edition Analysis Services의 일부로 제공됩니다.
용량 및 I/O 요구 사항에 따른 저장소 아키텍처 디자인
환경에 대해 선택하는 저장소 아키텍처 및 디스크 유형은 시스템 성능에 영향을 줄 수 있습니다.
이 섹션의 내용:
저장소 아키텍처 선택
디스크 유형 선택
RAID 유형 선택
저장소 아키텍처 선택
DAS(Direct Attached Storage), SAN(Storage Area Network) 및 NAS(Network Attached Storage) 저장소 아키텍처는 SharePoint Server 2010에서 지원되지만 원격 BLOB 저장소를 사용하도록 구성된 콘텐츠 데이터베이스에 대해서는 NAS만 지원됩니다. 선택은 비즈니스 솔루션 및 기존 인프라 내에 포함된 요소에 따라 달라집니다.
모든 저장소 아키텍처는 가용성 요구 사항을 지원하고 적절한 IOPS 및 대기 시간의 성능을 갖추어야 합니다. 시스템이 적절히 유지되려면 데이터의 첫 번째 바이트를 20밀리초(ms) 이내에 일관되게 반환해야 합니다.
DAS
DAS는 중간에 저장소 네트워크 없이 서버 또는 워크스테이션에 바로 연결되는 디지털 저장소 시스템입니다. DAS 물리적 디스크 유형에는 SAS(Serial Attached SCSI)와 SATA(Serial Attached ATA)가 있습니다.
일반적으로 공유 저장소 플랫폼에서 20ms의 응답 시간과 평균 및 최대 IOPS에 대한 충분한 용량을 보장할 수 없는 경우 DAS 아키텍처를 선택하는 것이 좋습니다.
SAN
SAN은 장치가 운영 체제에 로컬로 연결된 것처럼 보이도록(예: 블록 저장소) 원격 컴퓨터 저장 장치(예: 디스크 배열 및 테이프 라이브러리)를 서버에 연결하는 아키텍처입니다.
일반적으로 SAN은 공유 저장소의 이점이 조직에 중요한 역할을 하는 경우에 선택하는 것이 좋습니다.
공유 저장소의 이점은 다음과 같습니다.
서버 간 디스크 저장 용량 재할당 용이
여러 서버 지원 가능
액세스할 수 있는 디스크 수에 제한이 없음
NAS
NAS 장치는 네트워크에 연결된 독립적인 컴퓨터로, 유일한 목적은 네트워크상의 다른 장치에 파일 기반 데이터 저장소 서비스를 제공하는 것입니다. NAS 장치의 운영 체제 및 기타 소프트웨어에서는 데이터 저장소, 파일 시스템 및 파일 액세스 기능과 이러한 기능에 대한 관리 기능(예: 파일 저장소)을 제공합니다.
참고
NAS는 원격 BLOB 저장소를 사용하도록 구성된 콘텐츠 데이터베이스에 대해서만 사용할 수 있습니다. 모든 네트워크 저장소 아키텍처는 1ms 이내에 ping에 대해 응답하고 20ms 이내에 데이터의 첫 번째 바이트를 반환해야 합니다. 로컬 SQL Server FILESTREAM 공급자는 동일한 서버에 로컬로만 데이터를 저장하므로 이 공급자에는 위와 같은 제한이 적용되지 않습니다.
디스크 유형 선택
시스템에서 사용하는 디스크 유형은 안정성과 성능에 영향을 줄 수 있습니다. 다른 구성 요소도 마찬가지이지만 드라이브가 크면 평균 탐색 시간이 증가합니다. SharePoint Server 2010에서 지원하는 드라이브 유형은 다음과 같습니다.
SCSI(Small Computer System Interface)
SATA(Serial Advanced Technology Attachment)
SAS(Serial-attached SCSI)
FC(Fibre Channel)
IDE(Integrated Device Electronics)
SSD(Solid State Drive) 또는 플래시 디스크
RAID 유형 선택
RAID(Redundant Array of Independent Disks)는 대개 여러 디스크에 걸쳐 데이터를 스트라이핑하여 개별 디스크의 성능 특성을 향상시키는 것은 물론, 개별 디스크 장애로부터 보호하는 기능을 제공하는 데 사용됩니다.
SharePoint Server 2010에 대해서는 모든 RAID 유형을 사용할 수 있지만 RAID 10 또는 이와 동등한 성능을 가진 공급업체별 RAID 솔루션을 사용하는 것이 좋습니다.
RAID 배열을 구성할 때는 공급업체에서 제공한 오프셋에 파일 시스템을 정렬해야 합니다. 공급업체 지침이 없는 경우에는 SQL Server 사전 배포 I/O 최상의 방법(https://go.microsoft.com/fwlink/p/?LinkID=105583)을 참조하세요.
RAID 및 SQL Server I/O 하위 시스템을 구축하는 방법에 대한 자세한 내용은 SQL Server 최상의 방법 문서(https://go.microsoft.com/fwlink/p/?LinkId=168612)를 참조하세요.
메모리 요구 사항 예측
SharePoint Server 2010에 필요한 메모리는 SQL Server가 실행되는 서버에서 호스팅하는 콘텐츠 데이터베이스의 크기와 직접 관련이 있습니다.
서비스 응용 프로그램과 기능을 추가하면 그에 따라 요구 사항도 증가하는 경향이 있습니다. 다음 표에는 권장되는 메모리의 양에 대한 지침이 나와 있습니다.
참고
중소 규모 배포에 대한 정의는 SharePoint Server 2010의 용량 관리 및 크기 조정 개요 문서의 참조 아키텍처 섹션에 설명되어 있습니다.
| 다양한 크기 조합의 콘텐츠 데이터베이스 | SQL Server가 실행되는 컴퓨터에 권장되는 RAM |
|---|---|
소규모 프로덕션 배포를 위한 최소 용량 |
8GB |
중간 규모 프로덕션 배포를 위한 최소 용량 |
16GB |
최대 2TB에 대한 권장 용량 |
32GB |
2TB에서 5TB에 이르는 범위에 대한 권장 용량 |
64GB |
5TB 초과에 대한 권장 용량 |
64GB를 초과하는 RAM을 추가하면 SQL Server 캐싱 속도가 향상될 수 있음 |
참고
SharePoint Server 2010 환경에 필요한 데이터는 분산되어 있기 때문에 이러한 값은 SQL Server에 대해 권장되는 최소값보다 큽니다. SQL Server 시스템 요구 사항에 대한 자세한 내용은 SQL Server 2008 R2 설치를 위한 하드웨어 및 소프트웨어 요구 사항(https://go.microsoft.com/fwlink/p/?LinkId=129377)을 참조하세요.
필요한 메모리에 영향을 줄 수 있는 그 밖의 요소는 다음과 같습니다.
SQL Server 미러링 사용
15MB가 넘는 파일의 빈번한 사용
네트워크 토폴로지 요구 사항 이해
팜 내에는 물론 팜 간에도 네트워크 연결을 계획합니다. 네트워크는 대기 시간이 짧은 것을 사용하는 것이 좋습니다.
다음 목록에서는 몇 가지 최상의 방법과 권장 사항을 제공합니다.
팜의 모든 서버에는 SQL Server가 실행되는 서버에 대한 LAN 대역폭 및 대기 시간이 있어야 하며, 대기 시간은 1ms를 넘지 않아야 합니다.
SQL Server가 실행되는 서버를 대기 시간이 1ms를 초과하는 네트워크를 통해 팜의 다른 구성 요소에서 원격으로 배포하는 WAN(Wide Area Network) 토폴로지는 사용하지 않는 것이 좋습니다. 이 토폴로지는 아직 테스트를 받지 않았습니다.
SQL Server 미러링 또는 로그 전달을 사용하여 원격 사이트를 최신 상태로 유지하려는 경우 적절한 WAN 네트워크를 계획합니다.
웹 서버 및 응용 프로그램 서버에는 두 개의 네트워크 어댑터가 있는 것이 좋습니다. 이 경우 네트워크 어댑터 하나는 최종 사용자 트래픽을 처리하고 다른 하나는 SQL Server가 실행되는 서버와의 통신을 처리합니다.
SQL Server 구성
다음 섹션에서는 SharePoint Server 2010에 대해 SQL Server를 구성하는 방법을 설명합니다.
이 섹션의 내용:
필요한 인스턴스 또는 서버 수 확인
저장소 및 메모리 구성
SQL Server 옵션 설정
데이터베이스 구성
필요한 서버 수 예측
일반적으로 SharePoint Server 2010은 SQL Server 확장을 활용하도록 디자인되었습니다. 즉, SharePoint Server 2010은 몇 대에 불과한 대규모 서버보다는 SQL Server가 실행되는 많은 수의 중간 규모 서버에서 더 뛰어난 성능을 낼 수 있습니다.
시스템을 독립 실행형 서버에 배포하는 경우를 제외하고 항상 다른 팜 역할을 실행하지 않는 전용 서버 또는 다른 응용 프로그램의 데이터베이스를 호스팅하지 않는 전용 서버에 SQL Server를 배치합니다.
다음은 SQL Server를 실행할 추가 서버를 배포하는 경우를 위한 일반적인 지침입니다.
전체 용량으로 실행되는 웹 서버가 다섯 개 이상이면 데이터베이스 서버를 추가합니다.
현재 서버가 RAM, CPU, 디스크 IO 처리량, 디스크 용량 또는 네트워크 처리량의 유효한 리소스 한도에 도달한 경우 데이터베이스 서버를 추가합니다.
참고
Microsoft에서는 이 지침을 따르지 않는 서버 구성을 지원합니다.
Secure Store Service 응용 프로그램을 실행할 때 자격 증명을 보다 안전하게 저장할 수 있도록 보안 저장소 데이터베이스는 액세스 권한이 한 명의 관리자로 제한된 별도의 데이터베이스 인스턴스에서 호스팅하는 것이 좋습니다.
저장소 및 메모리 구성
SQL Server 2008이 실행되는 서버에서는 메모리를 개선하기 위해 CPU당 L2 캐시가 최소 2MB인 것이 좋습니다.
공급업체 저장소 구성 권장 사항 준수
물리적 저장소 배열을 구성할 때 최상의 성능을 얻으려면 운영 체제의 기본값에 의존하지 말고 저장소 공급업체에서 제공하는 하드웨어 구성 권장 사항을 준수합니다.
공급업체의 지침이 없는 경우 DiskPart.exe 디스크 구성 유틸리티를 사용하여 SQL Server 2008에 대한 저장소를 구성하는 것이 좋습니다. 자세한 내용은 사전 배포 I/O 최상의 방법(https://go.microsoft.com/fwlink/p/?LinkID=105583)을 참조하세요.
가능한 한 많은 리소스 제공
디스크에 대한 SQL Server I/O 채널이 페이징 파일 및 IIS(인터넷 정보 서비스) 로그 등의 다른 용도로 공유되지 않도록 합니다.
가능한 한 많은 버스 대역폭을 제공합니다. 버스 대역폭이 크면 안정성 및 성능을 개선하는 데 도움이 됩니다. 디스크 외에도 여러 구성 요소가 버스 대역폭을 사용합니다. 예를 들어 네트워크 액세스도 고려해야 합니다.
SQL Server 옵션 설정
다음은 SharePoint Server를 배포하기 전에 구성해야 하는 SQL Server 설정 및 옵션입니다.
SharePoint Server를 지원하는 SQL Server에 대해서는 자동 생성 통계를 사용하도록 설정하지 마십시오. SharePoint Server에서 구축 및 업그레이드 시에 필수 설정을 구성합니다. 자동 생성 통계는 쿼리의 실행 계획을 SQL Server의 한 인스턴스에서 SQL Server의 다른 인스턴스로 크게 변경시킬 수 있습니다. 따라서 SharePoint Server에서는 모든 고객을 일관성 있게 지원하기 위해 필요에 따라 쿼리에 대한 코드 힌트를 제공하여 모든 시나리오에서 최상의 성능을 제공합니다.
성능을 최적화하려면 SharePoint Server 2010 데이터베이스를 호스팅하는 SQL Server 인스턴스에 대해 MAXDOP(최대 병렬 처리 수준)을 1로 설정하는 것이 좋습니다. 최대 병렬 처리 수준을 설정하는 방법에 대한 자세한 내용은 최대 병렬 처리 수준 옵션(https://go.microsoft.com/fwlink/p/?LinkId=189030)을 참조하세요.
유지 관리의 편의성을 높이려면 팜의 각 데이터베이스 서버에 대해 SQL Server 연결 별칭을 구성합니다. 연결 별칭은 SQL Server 인스턴스에 연결하는 데 사용할 수 있는 대체 이름입니다. 자세한 내용은 SQL Server 별칭 설정 방법(SQL Server Management Studio)(https://go.microsoft.com/fwlink/p/?LinkId=132064)을 참조하세요.
데이터베이스 구성
다음 지침에서는 환경의 각 데이터베이스를 구성할 때 계획을 세우기 위한 최상의 방법을 설명합니다.
디스크 간 데이터 분리 및 우선 순위 지정
tempdb 데이터베이스, 콘텐츠 데이터베이스, 사용 현황 데이터베이스, 검색 데이터베이스 및 SQL Server 2008 트랜잭션 로그를 별도의 물리적 하드 디스크에 배치하는 것이 가장 이상적입니다.
다음 목록에는 데이터의 우선 순위를 지정하기 위한 최상의 방법 및 권장 사항이 나와 있습니다.
더 빠른 여러 디스크에서 데이터 우선 순위를 지정할 때 다음 순위를 사용합니다.
tempdb 데이터 파일 및 트랜잭션 로그
데이터베이스 트랜잭션 로그 파일
검색 데이터베이스(검색 관리 데이터베이스는 제외)
데이터베이스 데이터 파일
읽기 중심의 포털 사이트에서는 로그보다 데이터의 우선 순위를 높게 지정합니다.
테스트 데이터 및 고객 데이터의 경우, tempdb에 대한 불충분한 디스크 I/O로 인해 SharePoint Server 2010 팜 성능이 크게 저하될 수 있는 것으로 나타났습니다. 이 문제를 방지하려면 tempdb에 전용 디스크를 할당합니다. 높은 작업량이 예상되거나 모니터링되는 경우, 즉 평균 읽기 작업이나 평균 쓰기 작업에 20ms 이상이 소요되는 경우에는 여러 디스크에 파일을 분리하거나 디스크를 더 빠른 디스크로 바꾸어 병목 현상을 완화해야 할 수 있습니다.
최상의 방법은 tempdb를 RAID 10 배열에 배치하는 것입니다. tempdb 데이터 파일의 수는 코어 CPU의 수와 같아야 하고 tempdb 데이터 파일은 동일한 크기로 설정되어야 합니다. 이 경우, 듀얼 코어 프로세서를 CPU 두 개로 계산하고, 하이퍼스레딩을 지원하는 각 프로세서를 CPU 하나로 계산합니다. 자세한 내용은 tempdb 성능 최적화(https://go.microsoft.com/fwlink/p/?LinkID=148537)를 참조하세요.
데이터베이스 데이터와 트랜잭션 로그 파일을 여러 디스크에 분리합니다. 파일이 너무 작아서 전체 디스크나 스트라이프를 차지하기에 적당하지 않거나 디스크 공간이 부족하기 때문에 여러 파일이 디스크를 공유해야 하는 경우에는 사용 패턴이 서로 다른 여러 파일을 동일한 디스크에 배치하여 동시 액세스 요청을 최소화합니다.
특정 저장소 솔루션에 대한 쓰기 최적화를 위해 모든 로그와 검색 데이터베이스를 구성하는 방법에 대한 자세한 내용을 저장소 하드웨어 공급업체에 문의합니다.
콘텐츠 데이터베이스에 여러 데이터 파일 사용
최상의 성능을 얻으려면 다음 권장 사항을 따릅니다.
데이터베이스의 주 파일 그룹에서만 파일을 만듭니다.
여러 디스크에 파일을 분산합니다.
데이터 파일의 수는 코어 CPU의 수보다 작거나 같아야 합니다. 이 경우 듀얼 코어 프로세서를 CPU 두 개로 계산하고, 하이퍼스레딩을 지원하는 각 프로세서를 CPU 하나로 계산합니다.
같은 크기의 데이터 파일을 만듭니다.
중요
SharePoint Server 2010에 기본 제공된 백업 및 복구 도구를 사용하여 동일한 위치에 덮어쓰는 경우에는 여러 데이터 파일을 백업하고 복구할 수 있지만 여러 데이터 파일을 다른 위치에 복원할 수는 없습니다. 따라서 콘텐츠 데이터베이스에 여러 데이터 파일을 사용하는 경우 SQL Server 백업 및 복구 도구를 사용하는 것이 좋습니다. SharePoint Server 2010을 백업 및 복구하는 방법에 대한 자세한 내용은 SharePoint Server 2010의 백업 및 복구 계획을 참조하십시오.
파일 그룹을 만들고 관리하는 방법에 대한 자세한 내용은 실제 데이터 파일 및 파일 그룹(https://go.microsoft.com/fwlink/p/?LinkId=117909)을 참조하세요.
콘텐츠 데이터베이스 크기를 제한하여 관리 효율성 향상
환경의 관리 효율성, 성능 및 업그레이드 편의성을 향상시킬 수 있도록 데이터베이스 크기 지정을 계획합니다.
시스템 성능을 보장하려면 특정 사용 시나리오 및 조건이 더 큰 크기를 지원하는 경우를 제외하고, 콘텐츠 데이터베이스의 크기를 200GB로 제한하는 것이 좋습니다. 콘텐츠 데이터베이스 크기 제한에 대한 자세한 내용은 SharePoint Server 2010 용량 관리: 소프트웨어 경계 및 제한 사항의 콘텐츠 데이터베이스 제한 섹션을 참조하세요.
필요한 경우 SharePoint Server 2010의 세분화된 백업 도구를 사용하여 사이트 모음을 다른 데이터베이스로 이동할 수 있도록 하려면, 사이트 모음이 데이터베이스의 유일한 사이트 모음인 경우를 제외하고는 100GB를 초과하지 않는 것이 좋습니다.
대규모 문서 저장소에 대한 자세한 내용은 성능 및 용량 테스트 결과와 권장 사항(SharePoint Server 2010)의 "대규모 문서 저장소의 성능 및 용량 요구 사항 예측"을 참조하세요.
데이터 및 로그 파일의 증가를 사전에 관리
다음 권장 사항을 고려하여 데이터 및 로그 파일의 증가를 사전에 관리하는 것이 좋습니다.
가능한 경우 모든 데이터 및 로그 파일을 예상되는 최종 크기까지 미리 늘려 봅니다.
안전을 위해 자동 증가를 사용하도록 설정하는 것이 좋습니다. 기본 자동 증가 설정에 의존하지 말고, 다음 지침을 참고하여 자동 증가를 구성합니다.
권장 크기(200GB)를 초과하는 콘텐츠 데이터베이스를 계획할 때는 데이터베이스 자동 증가 값을 비율 대신 고정된 메가바이트 단위 수로 설정합니다. 이렇게 하면 SQL Server에서 파일 크기를 증가시키는 빈도가 줄어듭니다. 파일 크기를 증가시키는 것은 새 공간을 빈 공간으로 채우는 차단 작업입니다.
Search Service 응용 프로그램 속성 저장소 데이터베이스에 대한 자동 증가 값을 10%로 설정합니다.
계산된 콘텐츠 데이터베이스의 크기가 1년 내에 최대 권장 크기(200GB)에 이를 것으로 예상되지 않는 경우 ALTER DATABASE MAXSIZE 속성을 사용하여 이를 데이터베이스가 1년 내에 도달할 것으로 예상되는 최대 크기(오류에 대한 20%의 추가 마진 포함)로 설정합니다. 이 설정을 주기적으로 검토하여 과거의 증가율을 토대로 이 값이 여전히 적절한지 확인합니다.
디스크에 최소한 25%의 사용 가능한 공간을 유지하여 증가 및 최대 사용 패턴을 허용합니다. 디스크를 RAID 배열에 추가하거나 추가 저장 용량을 할당하는 방식으로 증가율을 관리하는 경우 공간이 부족한 상황이 발생하지 않도록 하려면 디스크 크기를 주의 깊게 모니터링합니다.
저장소 및 SQL Server 성능 유효성 검사 및 모니터링
하드웨어의 성능 및 백업 솔루션을 통해 SLA(서비스 수준 계약)를 충족할 수 있는지 테스트합니다. 특히, 성능이 만족스러운지 확인하려면 SQL Server가 실행되는 컴퓨터의 I/O 하위 시스템을 테스트합니다.
사용하는 백업 솔루션을 테스트하여 허용되는 유지 관리 창 이내에 시스템을 백업할 수 있는지 확인합니다. 백업 솔루션이 비즈니스에서 요구되는 SLA를 충족할 수 없는 경우 System Center Data Protection Manager(DPM) 2010 등의 증분 백업 솔루션을 사용하는 것이 좋습니다.
SQL Server를 실행하는 서버의 리소스 구성 요소인 CPU, 메모리, 캐시 적중률 및 I/O 하위 시스템을 추적하는 것이 중요합니다. 하나 이상의 구성 요소가 느려지거나 부하가 과도한 것처럼 보이면 현재 및 예상 작업량을 기반으로 적합한 전략을 분석합니다. 자세한 내용은 SQL Server 2008 성능 문제 해결(https://go.microsoft.com/fwlink/p/?LinkID=168448)을 참조하세요.
다음 섹션에서는 SharePoint Server 2010 환경에서 실행되는 SQL Server 데이터베이스의 성능을 모니터링하기에 적합한 성능 카운터를 소개합니다. 또한 각 카운터의 대략적인 상태 값도 나와 있습니다.
성능을 모니터링하고 성능 카운터를 사용하는 방법에 대한 자세한 내용은 성능 모니터링(https://go.microsoft.com/fwlink/p/?LinkId=189032)을 참조하세요.
모니터링할 SQL Server 카운터
다음 SQL Server 카운터를 모니터링하여 서버의 상태를 확인합니다.
General statistics 이 개체는 현재 연결 수 및 SQL Server 인스턴스를 실행하는 컴퓨터에서 초당 연결하는 사용자와 연결이 끊어지는 사용자 수 같은 일반적인 전체 서버 작업을 모니터링하는 카운터를 제공합니다. 모니터링할 카운터는 다음과 같습니다.
- User connections 이 카운터는 SQL Server를 실행하는 컴퓨터의 사용자 연결량을 보여 줍니다. 이 수치가 초기 계획에서 500% 상승하면 성능이 감소할 수 있습니다.
Databases 이 개체는 대량 복사 작업, 백업 및 복원 처리량, 트랜잭션 로그 작업을 모니터링하는 카운터를 제공합니다. 트랜잭션 및 트랜잭션 로그를 모니터링하여 데이터베이스에 발생한 사용자 작업의 양과 트랜잭션 로그가 찬 정도를 확인합니다. 사용자 작업의 양은 데이터베이스의 성능을 결정하며 로그 크기, 잠금 및 복제에 영향을 줄 수 있습니다. 낮은 수준의 로그 작업을 모니터링하여 사용자 작업과 리소스 사용량을 측정하면 성능 병목 현상을 식별하는 데 도움이 될 수 있습니다. 모니터링할 카운터는 다음과 같습니다.
- Transactions/sec 이 카운터는 특정 데이터베이스 또는 전체 서버에 발생하는 초당 트랜잭션의 양을 보여 줍니다. 이 수치는 초기 계획에 가까우며 문제를 해결하는 데 도움이 됩니다.
Locks 이 개체는 개별 리소스 유형의 SQL Server 잠금에 대한 정보를 제공합니다. 모니터링할 카운터는 다음과 같습니다.
Average Wait Time (ms) 이 카운터는 대기를 발생시킨 각 잠금 요청의 평균 대기 시간을 보여 줍니다.
Lock Wait Time (ms) 이 카운터는 마지막 초의 잠금에 대한 대기 시간을 보여 줍니다.
Lock waits/sec 이 카운터는 바로 충족할 수 없어 리소스를 기다려야 했던 초당 잠금 수를 보여 줍니다.
Number of deadlocks/sec 이 카운터는 SQL Server를 실행하는 컴퓨터의 초당 교착 상태 수를 보여 줍니다. 이 수치가 0보다 커서는 안 됩니다.
Latches 이 개체는 래치라는 내부 SQL Server 리소스 잠금을 모니터링하는 카운터를 제공합니다. 래치를 모니터링하여 사용자 작업 및 리소스 사용량을 확인하면 성능 병목 현상을 식별하는 데 도움이 될 수 있습니다. 모니터링할 카운터는 다음과 같습니다.
Average Latch Wait Time (ms) 이 카운터는 대기해야 했던 래치 요청의 평균 래치 대기 시간을 보여 줍니다.
Latch Waits/sec 이 카운터는 바로 승인할 수 없었던 래치 요청의 수를 보여 줍니다.
SQL Statistics 이 개체는 SQL Server 인스턴스로 보낸 요청의 유형과 컴파일을 모니터링하는 카운터를 제공합니다. 쿼리 컴파일 및 재컴파일의 수와 SQL Server 인스턴스에서 수신한 일괄 처리 수를 모니터링하면 SQL Server에서 사용자 쿼리를 처리하는 속도와 쿼리 최적화 프로그램에서 쿼리를 처리하는 효율성 수준을 확인할 수 있습니다. 모니터링할 카운터는 다음과 같습니다.
SQL Compilations/sec 이 카운터는 컴파일 코드 경로가 입력되는 초당 횟수를 나타냅니다.
SQL Re-Compilations/sec 이 카운터는 문이 다시 컴파일되는 초당 횟수를 나타냅니다.
Buffer Manager 이 개체는 SQL Server에서 메모리를 사용하여 데이터 페이지, 내부 데이터 구조 및 프로시저 캐시를 저장하는 방법을 모니터링하는 카운터와 SQL Server가 데이터베이스 페이지를 읽고 쓸 때 물리적 I/O를 모니터링하는 카운터를 제공합니다. 모니터링할 카운터는 다음과 같습니다.
Buffer Cache Hit Ratio
이 카운터는 디스크에서 읽어들이지 않고 버퍼 캐시에서 검색된 페이지의 비율을 보여 줍니다. 이 비율은 최근 수천 페이지의 액세스가 발생하는 동안의 총 캐시 조회 수로 총 캐시 적중 수를 나눈 것입니다. 캐시에서 읽어들이면 디스크에서 읽어들이는 경우보다 비용이 훨씬 저렴하므로 이 비율은 높아야 합니다. 일반적으로 SQL Server에서 사용할 수 있는 메모리의 양을 늘리면 버퍼 캐시 적중률을 높일 수 있습니다.
Plan Cache 이 개체는 SQL Server에서 메모리를 사용하여 저장 프로시저, 임시 및 준비된 Transact-SQL 문, 트리거 같은 개체를 저장하는 방법을 모니터링하는 카운터를 제공합니다. 모니터링할 카운터는 다음과 같습니다.
Cache Hit Ratio
이 카운터는 계획에 대한 캐시 적중 수와 캐시 조회 수 간의 비율을 나타냅니다.
모니터링할 물리적 서버 카운터
다음 카운터를 모니터링하여 SQL Server를 실행하는 컴퓨터의 상태를 확인합니다.
Processor: % Processor Time: _Total 이 카운터는 프로세서가 유휴 상태가 아닌 응용 프로그램 또는 운영 체제 프로세스를 실행하는 시간 비율을 보여 줍니다. SQL Server를 실행하는 컴퓨터에서 이 카운터는 50%와 75% 사이에서 유지되어야 합니다. 과부하가 일정하게 발생하는 경우 비정상적인 프로세스 작업이 진행 중인지 또는 서버에 추가 CPU가 필요한지 여부를 조사합니다.
System: Processor Queue Length 이 카운터는 프로세서 큐의 스레드 수를 보여 줍니다. 이 카운터를 모니터링하여 이 수치가 코어 CPU 수의 두 배보다 작게 유지되는지 확인합니다.
Memory: Available Mbytes 이 카운터는 컴퓨터에서 실행되는 프로세스에서 사용할 수 있는 물리적 메모리의 양을 메가바이트(MB) 단위로 보여 줍니다. 이 카운터를 모니터링하여 사용 가능한 총 물리적 RAM의 20% 이상으로 유지되는지 확인합니다.
Memory: Pages/sec 이 카운터는 페이지를 디스크에서 읽어오거나 디스크에 작성하여 하드 페이지 폴트를 해결하는 속도를 보여 줍니다. 이 카운터를 모니터링하여 수치가 100 미만으로 유지되는지 확인합니다.
메모리 문제 해결 방법과 자세한 내용은 메모리 사용 모니터링(https://go.microsoft.com/fwlink/p/?LinkID=105585)을 참조하세요.
모니터링할 디스크 카운터
다음 카운터를 모니터링하여 디스크의 상태를 확인합니다. 다음 값은 시간이 지남에 따라 측정된 값을 나타내며, 갑작스럽게 요청이 폭주하는 동안 발생한 값이나 단일 측정을 토대로 한 값이 아닙니다.
Physical Disk: % Disk Time: DataDrive 이 카운터는 선택한 디스크 드라이브가 읽기 또는 쓰기 요청을 처리하기 위해 사용된 경과된 시간의 비율을 보여 줍니다. 이는 디스크의 사용률을 나타내는 일반적인 지표입니다. PhysicalDisk: % Disk Time 카운터의 수치가 높은 경우(90% 이상) PhysicalDisk: Current Disk Queue Length 카운터를 확인하여 디스크 액세스를 위해 대기하는 시스템 요청 수를 살펴봅니다. 대기하는 I/O 요청 수는 물리적 디스크를 구성하는 스핀들 수의 1.5 ~ 2배를 넘지 않도록 유지되어야 합니다.
Logical Disk: Disk Transfers/sec 이 카운터는 디스크에서 읽기 및 쓰기 작업이 수행되는 속도를 보여 줍니다. 이 카운터를 사용하여 증가 추세를 모니터링하고 적절히 예측합니다.
Logical Disk: Disk Read Bytes/sec 및 Logical Disk: Disk Write Bytes/sec 이들 카운터는 읽기 또는 쓰기 작업이 수행되는 동안 디스크에서 바이트가 전송되는 속도를 보여 줍니다.
Logical Disk: Avg. Disk Bytes/Read 이 카운터는 읽기 작업이 수행되는 동안 디스크에서 전송된 평균 바이트 수를 보여 줍니다. 이 값은 디스크 대기 시간을 나타낼 수 있으며, 읽기 작업 시간이 긴 경우 대기 시간이 약간 증가할 수 있습니다.
Logical Disk: Avg. Disk Bytes/Write 이 카운터는 쓰기 작업이 수행되는 동안 디스크로 전송되는 평균 바이트 수를 보여 줍니다. 이 값은 디스크 대기 시간을 나타낼 수 있으며, 쓰기 작업 시간이 긴 경우 대기 시간이 약간 증가할 수 있습니다.
Logical Disk: Current Disk Queue Length 이 카운터는 성능 데이터가 수집될 때 디스크에 있는 미해결 요청 수를 보여 줍니다. 이 카운터의 경우에는 값이 낮을수록 좋습니다. 디스크당 값이 2를 초과하면 병목 현상을 나타낼 수 있으므로 조사해야 합니다. 즉, 네 개의 디스크로 구성된 LUN(논리 단위)에 대해 허용되는 최대값은 8입니다. 병목 현상이 발생하면 현재 디스크에 액세스하고 있는 서버를 넘어 확산될 수 있는 백로그가 만들어져 사용자가 장시간 대기하게 될 수 있습니다. 병목 현상에 대한 해결책은 RAID 배열에 디스크를 추가하거나, 기존 디스크를 보다 빠른 디스크로 교체하거나, 일부 데이터를 다른 디스크로 이동하는 것입니다.
Logical Disk: Avg. Disk Queue Length 이 카운터는 동일한 간격 동안 선택한 디스크에 대해 대기한 평균 읽기 및 쓰기 요청 수를 보여 줍니다. 규칙은 스핀들당 두 개 이하의 미해결 읽기 및 쓰기 요청이 있어야 하는 것이지만, 저장소 가상화 및 구성 간 RAID 수준의 차이로 인해 이는 측정하기가 어려울 수 있습니다. 평균 디스크 큐 길이보다 긴 경우와 평균 디스크 대기 시간보다 긴 경우를 함께 살펴봅니다. 이 조합은 저장소 배열 캐시가 과도하게 사용되고 있거나 다른 용도와 공유하는 스핀들로 인해 성능에 영향을 미치고 있음을 나타낼 수 있습니다.
Logical Disk: Avg. Disk sec/Read 및 Logical Disk: Avg. Disk sec/Write 이들 카운터는 디스크에 대한 평균 읽기 또는 쓰기 작업 시간을 초단위로 보여 줍니다. 이들 카운터를 모니터링하여 해당 수치가 디스크 용량의 85% 미만을 유지하는지 확인합니다. 읽기 또는 쓰기 작업이 디스크 용량의 85%를 초과하면 디스크 액세스 시간이 크게 증가합니다. 하드웨어의 구체적인 용량을 확인하려면 공급업체 설명서를 참조하거나 SQLIO Disk Subsystem Benchmark Tool을 사용하여 계산합니다. 자세한 내용은 SQLIO Disk Subsystem Benchmark Tool(https://go.microsoft.com/fwlink/p/?LinkID=105586)을 참조하세요.
Logical Disk: Avg. Disk sec/Read 이 카운터는 디스크에서 읽어들이는 작업의 평균 시간을 초단위로 보여 줍니다. 효율적으로 조정되어 있는 시스템의 경우 이상적인 값은 로그에 대해 1 ~ 5ms(이상적으로는 캐시 배열에서 1ms)이고, 데이터에 대해서는 4 ~ 20ms(이상적으로는 10ms 미만)입니다. 사용량이 많은 시간에는 대기 시간이 이보다 길 수 있지만 큰 값이 주기적으로 발생하면 원인을 조사해야 합니다.
Logical Disk: Avg. Disk sec/Write 이 카운터는 디스크에 대한 쓰기 작업의 평균 시간을 초단위로 보여 줍니다. 효율적으로 조정되어 있는 시스템의 경우 이상적인 값은 로그에 대해 1 ~ 5ms(이상적으로는 캐시 배열에서 1ms)이고, 데이터에 대해서는 4 ~ 20ms(이상적으로는 10ms 미만)입니다. 사용량이 많은 시간에는 대기 시간이 이보다 길 수 있지만 큰 값이 주기적으로 발생하면 원인을 조사해야 합니다.
RAID 구성을 Logical Disk: Avg. Disk Bytes/Read 또는 Logical Disk: Avg. Disk Bytes/Write 카운터와 함께 사용하는 경우 다음 표에 나와 있는 수식을 사용하여 디스크에 발생하는 입/출력 비율을 확인합니다.
RAID 수준 수식 RAID 0
디스크당 I/O = (읽기 + 쓰기) / 디스크 수
RAID 1
디스크당 I/O = [읽기 + (2 × 쓰기)] / 2
RAID 5
디스크당 I/O = [읽기 + (4 × 쓰기)] / 디스크 수
RAID 10
디스크당 I/O = [읽기 + (2 × 쓰기)] / 디스크 수
예를 들어 물리적 디스크가 두 개인 RAID 1 시스템이 있고 카운터에는 다음 표에 나열된 값이 나타나는 경우
카운터 값 Avg. Disk sec/Read
80
Logical Disk: Avg. Disk sec/Write
70
Avg. Disk Queue Length
5
디스크당 I/O 값은 다음과 같이 계산할 수 있습니다. (80 + (2 × 70))/2 = 110
디스크 큐 길이는 다음과 같이 계산할 수 있습니다. 5/2 = 2.5
이 경우 경계선 I/O 병목 현상이 발생하게 됩니다.
다른 모니터링 도구
SQL Server 2008의 sys.dm_io_virtual_file_stats 동적 관리 뷰를 사용하여 디스크 대기 시간을 모니터링하고 추세를 분석할 수도 있습니다. 자세한 내용은 sys.dm_io_virtual_file_stats(Transact-SQL)(https://go.microsoft.com/fwlink/p/?LinkID=105587)를 참조하세요.
See Also
Other Resources
리소스 센터: SharePoint Server 2010의 용량 관리
리소스 센터: SQL Server 및 SharePoint Server 2010 데이터베이스