실제 저장소 권장 사항(Office SharePoint Server)

업데이트 날짜: 2010년 4월

적용 대상: Office SharePoint Server 2007

 

마지막으로 수정된 항목: 2015-03-09

선택하는 디스크 및 배열과 해당 디스크 및 배열에 데이터를 배치하는 방법은 시스템 성능에 큰 영향을 줄 수 있습니다. RAID(Redundant Array of Independent Disks)에 익숙하지 않은 경우 다음 자료를 참조하십시오.

• Microsoft SQL Server 2008과 함께 사용되는 RAID의 유형에 대한 소개는 RAID 수준 및 SQL Server(https://go.microsoft.com/fwlink/?linkid=105581&clcid=0x412)를 참조하십시오.

• SQL Server 2008과 함께 사용되는 RAID 수준의 비교는 RAID 수준의 여러 가지 구현 비교(https://go.microsoft.com/fwlink/?linkid=105582&clcid=0x412)를 참조하십시오.

이 항목에서는 주로 SQL Server 2008에 대해 설명하지만 Microsoft SQL Server 2005 및 Microsoft SQL Server 2000도 지원됩니다.

적절한 디스크 및 RAID 배열 사용

다음 목록에서는 최적의 RAID 수준과 하드 디스크를 선택하기 위한 최상의 방법과 권장 사항을 제공합니다.

• 디스크 또는 배열을 더 많이 사용하거나 속도가 더 빠른 것을 사용하면 성능이 향상됩니다. 핵심은 모든 디스크에서 대기 시간과 대기를 낮은 수준으로 유지하는 것입니다.

• 높은 가용성과 성능(임의 읽기/쓰기)을 얻으려면 RAID 10을 사용하도록 배열을 구성합니다.

• RAID 배열을 구성하기 전에 저장소 하드웨어 공급업체나 설명서의 지침을 참조합니다. 빠른 임의 읽기 응답 시간이 데이터베이스에 도움이 되는지 여부를 고려합니다. 예를 들어 정적 웹 콘텐츠의 경우 RAID 5와 RAID 10이 유사한 성능을 제공합니다. 반면에 빠른 임의 쓰기 응답 시간이 더 중요할 수도 있습니다. 예를 들어 혼합된 읽기/쓰기가 사용되는 공동 작업 사이트에서는 RAID 10이 유리합니다.

• RAID 배열을 구성할 때 공급업체에서 제공하는 오프셋에 파일 시스템을 정렬해야 합니다. 공급업체 지침이 없는 경우에는 SQL Server 사전 배포 I/O 최상의 방법(영문)(https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x412)을 참조하십시오.

RAID 및 SQL Server I/O 하위 시스템 구축에 대한 자세한 내용은 SQL Server 모범 사례 문서(영문)(https://go.microsoft.com/fwlink/?linkid=168612&clcid=0x412)를 참조하십시오.

새 팜을 배포하기 전에 SQLIO Disk Subsystem Benchmark Tool을 사용하여 I/O 하위 시스템을 벤치마크하는 것이 좋습니다. 자세한 내용은 SQLIO Disk Subsystem Benchmark Tool(영문)(https://go.microsoft.com/fwlink/?linkid=105586&clcid=0x412)을 참조하십시오.

데이터 및 로그 파일 증가 사전 관리

• 데이터와 로그 파일의 크기를 미리 설정합니다.

• 자동 증가에 의존하지 않습니다. 대신 데이터와 로그 파일의 증가를 수동으로 관리합니다. 안전상의 이유로 자동 증가를 사용할 수 있지만 데이터 및 로그 파일의 증가를 사전에 관리해야 합니다.

• 배포 요구 사항에 맞도록 자동 증가 설정을 구성합니다.

  • 권장 크기(100GB)를 초과하는 콘텐츠 데이터베이스를 계획할 때는 데이터베이스 자동 증가 값을 비율 대신 고정된 메가바이트 단위 수로 설정합니다. 이는 SQL Server에서 파일 크기를 증가시키는 빈도를 줄이기 위함입니다. 파일 크기 증가는 새 공간을 빈 공간으로 채우는 차단 작업입니다.

    참고

    Windows Server 2003에서 실행 중인 SQL Server 2008에서는 인스턴트 파일 초기화를 지원합니다. 인스턴트 파일 초기화는 파일 증가 작업이 성능에 미치는 영향을 크게 줄일 수 있습니다. 자세한 내용은 데이터베이스 파일 초기화(https://go.microsoft.com/fwlink/?linkid=132063&clcid=0x412)를 참조하십시오.

  • 권장 크기(100GB)보다 작은 콘텐츠 데이터베이스를 계획할 경우에는 ALTER DATABASE MAXSIZE 속성을 사용하여 데이터베이스를 만들 때 100GB로 설정합니다.

  • 디스크 공간이 제한되어 있거나 데이터베이스 크기를 조정할 수 없는 경우에는 자동 증가 값을 고정 비율로 구성해야 합니다. 예를 들어 500GB 이하의 데이터베이스에 대해서는 자동 증가 값을 10%로 구성하고, 데이터베이스가 500GB를 초과하는 경우에는 고정된 메가바이트 단위 수로 구성합니다.

• 증가와 최대 사용 패턴을 허용하려면 디스크에 최소한 25% 수준의 사용 가능한 공간을 유지합니다. 디스크를 RAID 배열에 추가하거나 저장소를 추가로 할당하여 증가를 관리하는 경우 디스크 크기를 면밀히 모니터링하여 공간이 부족하지 않도록 합니다.

관리 용이성 개선을 위한 콘텐츠 데이터베이스 크기 제한

환경의 관리 용이성 및 성능을 향상시킬 수 있도록 데이터베이스 크기 지정을 계획합니다.

참고

여기서 권장하는 제한은 SQL Server 2008을 실행하고 Microsoft Office SharePoint Server 2007를 호스팅 중인 서버에만 적용되며 SQL Server 2008에 대한 일반 지침은 아닙니다.

• 대부분의 경우 Office SharePoint Server 2007의 성능을 높이려면 100GB보다 큰 콘텐츠 데이터베이스는 사용하지 않는 것이 좋습니다. 디자인상 100GB보다 큰 데이터베이스가 필요한 경우에는 다음의 지침을 따르십시오.

  • 둘 이상의 사이트 모음에 대해 100GB가 넘는 데이터베이스를 사용하지 않습니다.

  • 기본 제공되는 백업 및 복구 도구 대신 SQL Server 2008 또는 Microsoft System Center Data Protection Manager 2007 등의 차등 백업 솔루션을 사용합니다.

  • 100GB 콘텐츠 데이터베이스를 사용하는 솔루션으로 이전하기 전에 SQL Server 2008을 실행하는 서버 및 I/O 하위 시스템을 테스트합니다.

• 여러 사이트 모음을 포함하는 콘텐츠 데이터베이스의 크기를 약 100GB로 제한합니다.

여러 디스크에 데이터 분리 및 우선 순위 지정

tempdb 데이터베이스, 콘텐츠 데이터베이스 및 SQL Server 2008 트랜잭션 로그를 별도의 실제 하드 디스크에 배치하는 것이 이상적입니다.

다음 목록에서는 데이터 우선 순위를 지정하기 위한 최상의 방법과 권장 사항을 제공합니다.

• 더 빠른 여러 디스크에서 데이터 우선 순위를 지정할 때 다음 순위를 사용합니다.

  1. tempdb 데이터 파일 및 트랜잭션 로그

  2. 데이터베이스 트랜잭션 로그 파일

  3. 검색 데이터베이스

  4. 데이터베이스 데이터 파일

  읽기 중심의 포털 사이트에서는 로그보다 데이터의 우선 순위를 높게 지정합니다.

• 테스트 데이터 및 고객 데이터의 경우, tempdb에 대한 불충분한 디스크 I/O로 인해 Office SharePoint Server 2007 팜 성능이 크게 저하될 수 있는 것으로 나타났습니다. 이 문제를 방지하려면 tempdb에 전용 디스크를 할당합니다. 높은 작업 부하가 예상되거나 모니터링되는 경우, 즉 평균 읽기 작업이나 평균 쓰기 작업에 20밀리초 이상이 소요되는 경우에는 여러 디스크에 파일을 분리하거나 디스크를 더 빠른 디스크로 바꾸어 병목 현상을 완화해야 할 수 있습니다.

• 최상의 방법은 tempdb를 RAID 10 배열에 배치하는 것입니다. tempdb 데이터 파일의 수는 코어 CPU의 수와 같아야 하고 tempdb 데이터 파일은 동일한 크기로 설정되어야 합니다. 이 경우, 듀얼 코어 프로세서를 CPU 2개로 계산하고, 하이퍼스레딩을 지원하는 각 프로세서를 CPU 1개로 계산합니다. 자세한 내용은 tempdb 성능 최적화(https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x412)를 참조하십시오.

• 데이터베이스 데이터와 트랜잭션 로그 파일을 여러 디스크에 분리합니다. 파일이 너무 작아서 전체 디스크나 스트라이프를 차지하기에 적당하지 않거나 디스크 공간이 부족하기 때문에 여러 파일이 디스크를 공유해야 하는 경우에는 사용 패턴이 서로 다른 여러 파일을 동일한 디스크에 배치하여 동시 액세스 요청을 최소화합니다.

• 특정 저장소 솔루션에 대한 쓰기 최적화를 위해 모든 로그와 검색 데이터베이스를 구성하는 방법에 대한 자세한 내용을 저장소 하드웨어 공급업체에 문의합니다.

• 검색 데이터베이스에 전용 스핀들을 할당합니다.

대규모 콘텐츠 데이터베이스 및 SSP 검색 데이터베이스에 여러 데이터 파일 사용

대규모 콘텐츠 데이터베이스 및 SSP 검색 데이터베이스의 성능을 향상시키려면 여러 데이터 파일을 사용하는 것이 좋습니다.

참고

• 콘텐츠 데이터베이스 및 SSP 검색 데이터베이스 이외의 데이터베이스에는 여러 데이터 파일을 사용할 수 없습니다.

• SharePoint 제품 및 기술 데이터베이스에는 SQL Server 분할을 사용할 수 없습니다. 간단한 데이터 파일만 사용하십시오.

콘텐츠 데이터베이스에 여러 데이터 파일 사용

최고의 성능을 얻으려면 다음 권장 사항을 따르십시오.

• 데이터베이스의 주 파일 그룹에서만 파일을 만듭니다.

• 여러 디스크에 파일을 분산합니다.

• 데이터 파일의 수는 코어 CPU의 수보다 작거나 같아야 합니다. 이 경우, 듀얼 코어 프로세서를 CPU 2개로 계산하고, 하이퍼스레딩을 지원하는 각 프로세서를 CPU 1개로 계산합니다.

• 같은 크기의 데이터 파일을 만듭니다.

중요

SharePoint 제품 및 기술에 기본 제공된 백업 및 복구 도구를 사용하여 동일한 위치에 덮어쓰는 경우에는 여러 데이터 파일을 백업하고 복구할 수 있지만, 여러 데이터 파일을 다른 위치에 복원할 수는 없습니다. 따라서 콘텐츠 데이터베이스에 여러 데이터 파일을 사용하는 경우 SQL Server 백업 및 복구 도구를 사용하는 것이 좋습니다. Office SharePoint Server 2007을 백업하고 복구하는 방법에 대한 자세한 내용은 백업 및 복구 도구 선택(Office SharePoint Server)을 참조하십시오.

파일 그룹을 만들고 관리하는 방법에 대한 자세한 내용은 파일 및 파일 그룹 아키텍처(https://go.microsoft.com/fwlink/?linkid=117909&clcid=0x412)를 참조하십시오.

SSP 검색 데이터베이스에 여러 데이터 파일 사용

검색 데이터베이스의 경우 파일 그룹을 사용하여 주로 크롤링 및 쿼리 처리에 사용되는 테이블을 분리하는 것이 좋습니다. 크롤링의 영향을 가장 많이 받는 테이블을 호스팅하는 파일 그룹을 기본 파일 그룹이 아닌 다른 축으로 이동하면 I/O 하위 시스템이 받는 영향을 최대한 줄일 수 있습니다.

다음 표에 나열된 데이터베이스 테이블은 주로 크롤링과 관련된 테이블입니다.

MSSAnchorChangeLog	MSSCrawlDeletedErrorList
MSSAnchorPendingChangeLog	MSSCrawlDeletedURL
MSSAnchorText	MSSCrawlErrorList
MSSAnchorTransactions	MSSCrawlHostList
MSSCrawlChangedSourceDocs	MSSCrawlQueue
MSSCrawlChangedTargetDocs	MSSCrawlURL
MSSCrawlContent	MSSCrawlURLLog
	MSSTranTempTable0

중요

Transact-SQL 스크립트를 사용하여 이러한 테이블을 파일 그룹으로 이동할 수 있습니다. Transact-SQL 스크립트는 크롤링과 관련된 테이블을 이동하는 작업에 대해 유일하게 지원되는 메커니즘입니다. 스크립트는 Microsoft 엔터프라이즈 검색 블로그에 게시된 블로그 게시물 SQL 파일 그룹 및 검색(영문)(https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x412)에 있습니다.

검색 데이터베이스에서 성능을 극대화하려면 다음 권장 사항을 따르십시오.

• 테이블을 데이터베이스의 기본 파일 그룹 밖으로 이동합니다.

• 여러 디스크에 파일을 분산합니다.

중요

테이블을 새 파일 그룹으로 이동하는 프로세스는 비용이 매우 많이 들며 작업을 마치는 데 몇 시간이 걸릴 수도 있습니다. 클러스터된 인덱스를 무수히 삭제하고 다시 만들어야 하기 때문입니다. 이동 작업 동안에는 데이터베이스가 오프라인 상태인 것과 마찬가지로 간주해야 합니다.

알려진 문제

다음 섹션에서는 검색 데이터베이스에 파일 그룹을 사용할 때의 알려진 문제에 대해 설명합니다.

백업 및 복원

SharePoint 제품 및 기술의 백업 및 복원은 파일 그룹을 인식하지 않습니다. 새 파일 그룹의 복원 위치를 지정할 수 있는 방법이 없습니다. 복원 프로세스는 크롤 파일 그룹을 백업을 만들 때 해당 파일 그룹이 있었던 드라이브에 저장하려고 합니다. 복원하려면 초기 백업 드라이브와 동일한 드라이브 문자의 드라이브가 크롤 및 기본 파일 그룹에 대해 있어야 합니다.   

미래 업데이트, 서비스 팩 및 핫픽스

서버에 적용되는 각 업데이트, 서비스 팩 및 핫픽스는 크롤링 파일 그룹으로 이동한 인덱스를 수정하거나, 파일 그룹으로 이동한 테이블 중 하나에 새 인덱스를 추가할 가능성이 있습니다. 이 경우에는 인덱스가 기본 파일 그룹으로 다시 이동하거나 기본 파일 그룹에서 다시 만들어집니다. 

인덱스 수정 위험성 때문에 업데이트를 적용한 후에는 엔터프라이즈 검색 블로그에서 제공하는 스크립트를 실행하여 테이블을 파일 그룹으로 이동하는 프로세스를 반복해야 합니다.

최소 SQL Server 2005이 필요, SQL Server 2008 권장

인덱스를 이동하는 데 사용되는 제품 팀 스크립트는 SQL Server 2005에서 릴리스된 기능을 사용합니다. 이러한 기능은 SQL Server 2008에서 계속 지원됩니다. 이 최적화는 SQL Server 2005 이상을 실행 중인 경우에만 수행할 수 있습니다.

공급업체 구성 권장 사항 준수

실제 저장소 배열을 구성할 때 성능을 최적화하려면 운영 체제의 기본값에 의존하는 대신, 저장소 공급업체가 제공하는 하드웨어 구성 권장 사항을 준수합니다.

공급업체에서 지침을 받지 못하는 경우에는 DiskPart.exe 디스크 구성 유틸리티를 사용하여 SQL Server 2008에 대한 저장소를 구성하는 것이 좋습니다. 자세한 내용은 사전 배포 I/O 최상의 방법(영문)(https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x412)을 참조하십시오.

이 문서의 다운로드

이 항목은 다운로드 가능한 다음 문서에도 포함되어 있어 더 쉽게 읽고 인쇄할 수 있습니다.

• Office SharePoint Server 2007 계획 및 아키텍처(제2부)(https://go.microsoft.com/fwlink/?linkid=85548&clcid=0x412)

사용 가능한 문서의 전체 목록은 다운로드 가능한 Office SharePoint Server 2007 관련 콘텐츠(https://go.microsoft.com/fwlink/?linkid=89172&clcid=0x412)를 참조하십시오.