다음을 통해 공유

저장소 및 SQL Server 용량 계획 및 구성(SharePoint Server)

  • 아티클

적용 대상:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

Microsoft에서 제공하는 용량 계획 정보에는 SharePoint Server 환경에서 스토리지 및 SQL Server 데이터베이스 계층을 계획하고 구성하는 데 도움이 되는 지침이 포함되어 있습니다. 이 정보는 Microsoft에서 실제 속성에 대해 수행한 테스트 결과를 기반으로 합니다. 그러나 사용하는 장비 및 사이트에 대해 구현하는 기능에 따라 결과는 달라질 수 있습니다.

Microsoft 365에서 SharePoint에 대한 사이트 저장소 제한을 관리에 대해 알아봅니다.

SP1(SQL Server 2014), SQL Server 2016, SQL Server 2017 RTM 또는 SQL Server 2019에서 테스트가 실행되지 않았지만 이러한 테스트 결과를 SharePoint Server 구독 버전, 2019 또는 2016 환경에서 스토리지 및 SQL Server 데이터베이스 계층을 계획하고 구성하는 데 도움이 되는 가이드로 사용할 수 있습니다. SQL Server 2012를 구성하고 튜닝하는 방법에 대한 자세한 내용은 SharePoint Server 2013용 SQL Server 2012를 참조하세요. 테스트 결과는 SharePoint 2013과 동일합니다.

이 문서는 SharePoint Server 팜 구현자와 SQL Server 데이터베이스 관리자가 공동으로 사용하기 위한 것입니다. SharePoint Server는 종종 별도의 SQL Server 데이터베이스 관리자가 데이터베이스를 관리하는 환경에서 실행됩니다. SharePoint Server와 SQL Server를 모두 잘 이해하고 있다고 가정합니다.

이 문서에서는 SharePoint Server 2013의 용량 관리 및 크기 조정 개요에 나와 있는 개념에 이미 익숙한 것으로 가정합니다.

SharePoint Server 2016 이상을 위한 저장소 및 데이터베이스 계층 디자인 및 구성 프로세스

저장소 및 데이터베이스 계층 디자인 프로세스는 다음 단계로 나누는 것이 좋습니다. 이러한 섹션에서는 저장소 요구 사항 및 모범 사례를 포함하여 각 디자인 단계에 대한 세부 정보를 제공합니다.

  1. 저장소 및 SQL Server의 공간 및 I/O 요구 사항 수집

  2. SQL Server 버전 및 에디션 선택

  3. 용량 및 I/O 요구 사항에 따른 저장소 아키텍처 디자인

  4. 메모리 요구 사항 예측

  5. 네트워크 토폴로지 요구 사항 이해

  6. SQL Server 구성

  7. 스토리지 및 SQL Server 성능 유효성 검사 및 모니터링

스토리지 및 SQL Server의 공간 및 I/O 요구 사항 수집

몇 가지 SharePoint Server 아키텍처 요소는 스토리지 디자인에 영향을 줍니다. 주요 요인은 콘텐츠 양, 사용 가능한 기능, 배포된 서비스 애플리케이션, 팜 수 및 가용성 요구 사항입니다.

저장소 계획을 시작하기 전에 먼저 SharePoint Server에서 사용할 수 있는 데이터베이스를 이해해야 합니다.

이 섹션의 내용

SharePoint Server에서 사용되는 데이터베이스

SharePoint Server(Subscription Edition, 2019 또는 2016)와 함께 설치된 데이터베이스는 환경에서 사용되는 서비스 애플리케이션에 따라 달라집니다. 모든 SharePoint Server 환경은 SQL Server 시스템 데이터베이스를 사용합니다. 이 섹션에서는 SharePoint 서버와 함께 설치된 데이터베이스에 대한 요약을 제공합니다. 자세한 내용은 Database types and descriptions in SharePoint Server을 참조하세요.

일부 SharePoint Server, SQL Server 데이터베이스 엔진 및 SSRS(SQL Server Reporting Services) 데이터베이스에는 특정 위치 권장 사항 또는 요구 사항이 있습니다. 이러한 데이터베이스 위치에 대한 자세한 내용은 Database types and descriptions in SharePoint Server을 참조하세요. 빠른 참조 가이드: SharePoint Servers 2016 및 2019 데이터베이스는 PDF 또는 Visio 파일로 다운로드할 수 있습니다.

다음 데이터베이스는 SharePoint Server 시스템 데이터베이스이며 자동으로 설치됩니다.

  • 구성

  • 중앙 관리 콘텐츠

  • 콘텐츠(하나 이상)

다음 목록은 데이터베이스를 포함하는 SharePoint Server 서비스 응용 프로그램입니다.

  • 앱 관리 서비스

  • Sharepoint용 앱

  • Business Data Connectivity

  • Managed Metadata

  • PerformancePoint Services

  • Project Server(SharePoint Server 2013만 해당)

  • Search Service

    • Search Administration

    • 분석 보고

    • 크롤링

    • 링크

  • Secure Store Service

  • SharePoint Translation Service

  • SQL Server Power Pivot Service

  • State Service

  • Subscription Settings Service

  • Usage and Health data collection

  • User Profile Service

    • 프로필

    • 공유 태그 지정

    • 동기화

  • Word Automation Services

다음 목록에는 SharePoint Foundation 2013 데이터베이스가 나와 있습니다.

  • 구성

  • 중앙 관리 콘텐츠

  • 콘텐츠(하나 이상)

  • 앱 관리 서비스

  • Search Service 응용 프로그램:

    • 검색 관리

    • 분석 보고(하나 이상)

    • 크롤링(하나 이상)

    • 링크(하나 이상)

  • Secure Store Service

  • 구독 설정 서비스 응용 프로그램(Windows PowerShell을 통해 사용하도록 설정된 경우)

  • Usage and Health Data Collection Service

  • Word Conversion Service

SQL Server와 추가로 통합하는 경우 다음 시나리오와 같이 환경에 더 많은 데이터베이스가 포함될 수도 있습니다. SQL Server 2016 RTM Enterprise Edition 및 SQL Server 2016 SSAS(SQL Server Analysis Services)를 사용하는 경우에만 SharePoint용 SQL Server Power Pivot을 SharePoint Server 2016 환경에서 사용할 수 있습니다. 사용 중인 경우 Power Pivot 애플리케이션 데이터베이스와 시스템의 추가 부하도 지원하도록 계획해야 합니다. 자세한 내용은 새로운 SharePoint 2016에서 SQL Server 2016 PowerPivot 및 Power View 배포 백서를 다운로드하세요. 다중 서버 SharePoint Server 2016 팜에서 비즈니스 인텔리전스를 구성 및 배포하는 방법에 대한 자세한 내용은 다중 계층 SharePoint 2016 팜에서 SQL Server 2016 PowerPivot 및 Power View 배포를 다운로드하세요.

SQL Server 2016 Reporting Services(SSRS) 추가 기능은 모든 SharePoint Server 2016 환경에서 사용할 수 있습니다. 추가 기능을 사용하는 경우 두 개의 SQL Server Reporting Services 데이터베이스와 SQL Server Reporting Services에 필요한 추가 로드를 지원하도록 계획합니다.

  • SQL Server 2012 Power Pivot for SharePoint 2013은 SQL Server 2008 R2 Enterprise Edition 및 SQL Server Analysis Services를 포함하는 SharePoint 2013 환경에서 사용할 수 있습니다. 사용 중인 경우 Power Pivot 애플리케이션 데이터베이스와 시스템의 추가 부하도 지원하도록 계획해야 합니다. 자세한 내용은 SharePoint 팜에서 PowerPivot 배포 계획, Power Pivot - 개요 및 학습 및파워 뷰 - 개요 및 학습을 참조하세요.

  • SQL Server 2008 R2 Reporting Services(SSRS) 플러그 인은 모든 SharePoint 2013 환경에서 사용할 수 있습니다. 플러그 인을 사용하는 경우 두 개의 SQL Server 2008 R2 Reporting Services 데이터베이스와 SQL Server 2008 R2 Reporting Services에 필요한 추가 부하를 지원하도록 계획합니다.

참고

SharePoint Server 2019와 SQL Server Reporting Services 통합은 더 이상 지원되지 않습니다. 자세한 내용은 Reporting Services 보고서 서버(SharePoint 모드) 및 SharePoint 및 Reporting Services 서버의 지원되는 조합을 참조하세요.

SQL Server 및 IOPS 이해

SQL Server 인스턴스를 호스트하는 모든 서버에서 서버는 I/O 하위 시스템에서 가능한 가장 빠른 응답을 달성하는 것이 중요합니다.

보다 많고 더 빠른 디스크 또는 배열은 충분한 IOPS(초당 I/O 작업 수)를 제공하는 동시에 모든 디스크에서 대기 시간 및 대기열을 작게 유지합니다

I/O 하위 시스템의 느린 응답을 보정하기 위해 CPU 또는 메모리와 같은 다른 유형의 리소스를 추가할 수 없습니다. 그러나 팜 전체에서 영향을 미치고 문제를 일으킬 수 있습니다. 배포 전에 최소 대기 시간을 계획하고 기존 시스템을 모니터링합니다.

새 팜을 배포하기 전에 Diskspd 유틸리티를 사용하여 I/O 하위 시스템을 벤치마킹하는 것이 좋습니다. 이 도구는 모든 버전의 SQL Server를 사용하는 모든 Windows Server 버전에서 작동합니다. 자세한 내용은 Diskspd 유틸리티: 강력한 스토리지 테스트 도구를 참조하세요.

스트레스 테스트는 SQL Server에 대한 중요한 정보도 제공합니다. 자세한 내용은 DiskSpd를 사용하여 스토리지 벤치마킹을 참조하세요.

SQL Server 측면에서 IOPS 요구 사항을 분석하는 방법에 대한 자세한 내용은 SQL Server 데이터베이스 응용 프로그램에 대한 I/O 요구 사항 특성 분석 및 저장소 시스템 크기 조정을 참조하세요.

스토리지 및 IOPS 관련 핵심 요구 사항 예측

구성 및 콘텐츠 스토리지와 IOPS는 모든 SharePoint Server 배포에서 반드시 계획해야 하는 기본 계층입니다.

구성 저장소 및 IOPS

구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스에 대한 스토리지 요구 사항은 크지 않습니다. 구성 데이터베이스에 2GB, 중앙 관리 콘텐츠 데이터베이스에 1GB를 할당하는 것이 좋습니다. 시간이 지남에 따라 구성 데이터베이스는 1GB를 초과할 수 있습니다. 빠르게 증가하지는 않습니다. 각 50,000개의 사이트 모음에 대해 약 40MB 증가합니다.

구성 데이터베이스의 트랜잭션 로그가 클 수 있습니다. 구성 데이터베이스의 트랜잭션 로그는 정기적으로 백업하여 자르기를 강제로 적용하는 것이 좋습니다. SQL Server Always On 가용성 그룹 또는 데이터베이스 미러링을 사용하는 경우 데이터베이스를 전체 복구 모드로 실행해야 합니다. 자세한 내용은 트랜잭션 로그 (SQL Server)를 참조하세요.

팁

전체 복구 모델을 사용해야 하는 SQL Server 고 가용성 솔루션을 사용하지 않는 경우 구성 데이터베이스를 단순 복구 모델로 변경하는 것이 좋습니다.

구성 데이터베이스 및 중앙 관리 콘텐츠 데이터베이스에 대한 IOPS 요구 사항은 최소 수준입니다.

콘텐츠 저장소 및 IOPS

콘텐츠 데이터베이스에 필요한 저장소 및 IOPS를 예측하는 일은 정밀하게 수행되는 작업이 아닙니다. 다음 정보를 테스트 및 설명하는 과정을 잘 살펴보면 초기 배포 규모를 결정하는 데 사용할 근사값을 손쉽게 얻을 수 있을 것입니다. 그러나 환경이 실행 중인 경우에는 실제 환경의 데이터를 토대로 용량 요구 사항을 조정해야 합니다.

전체 용량 계획 방법에 대한 자세한 내용은 SharePoint Server 2013의 용량 관리 및 크기 조정 개요를 참조하세요.

콘텐츠 데이터베이스 저장소를 예측하는 수식

다음 프로세스에서는 로그 파일을 제외하고 콘텐츠 데이터베이스에 필요한 저장소를 대략적으로 예측하는 방법을 설명합니다.

  1. 다음 수식을 사용하여 콘텐츠 데이터베이스의 크기를 예측합니다.

    데이터베이스 크기 = ((D x V) x S) + (10KB x (L + (V x D)))

    참고

    수식의 값 10KB는 SharePoint Server에 필요한 메타데이터 양을 대략적으로 예측하는 상수입니다. 시스템에서 많은 양의 메타데이터를 사용해야 하는 경우 이 상수를 늘려야 합니다.

  2. 예상 문서 수를 계산합니다. 이 값은 수식에서 D로 나타냅니다.

    문서 수를 계산하는 방식은 사용하는 기능에 따라 결정됩니다. 예를 들어 내 사이트 또는 공동 작업 사이트의 경우 사용자당 예상 문서 수를 계산하고 사용자 수를 곱하는 것이 좋습니다. 또한 레코드 관리 또는 콘텐츠 게시 사이트의 경우에는 프로세스를 통해 관리 및 생성되는 문서의 수를 계산할 수 있습니다.

    현재 시스템에서 마이그레이션하는 경우에는 현재 증가율 및 사용량을 추정하기가 더 쉬울 수 있습니다. 새 시스템을 만드는 경우 기존 파일 공유 또는 다른 저장소를 검토하고 해당 사용률을 토대로 예측합니다.

  3. 저장할 평균 문서 크기를 예측합니다. 이 값은 수식에서 S 로 나타냅니다. 각기 다른 사이트 유형 또는 그룹에 대한 평균치를 예측하는 것도 도움이 될 수 있습니다. 내 사이트, 미디어 리포지토리 및 여러 부서 포털의 평균 파일 크기는 크게 다를 수 있습니다.

  4. 환경의 목록 항목 수를 예측합니다. 이 값은 수식에서 L로 나타냅니다.

    목록 항목은 문서보다 예측하기가 어렵습니다. 일반적으로 문서 수(D)의 3배에 달하는 추정치를 사용하지만 예상 수식은 사이트 사용 방식에 따라 달라집니다.

  5. 대략 버전 수를 결정합니다. 라이브러리에 있는 문서의 평균 버전 수를 예측합니다. 이 값은 일반적으로 허용되는 최대 버전 수보다 훨씬 낮습니다. 이 값을 수식에서 V라고 합니다.

    V 값은 0보다 커야 합니다.

예를 들어 이 수식과 다음 표의 특성을 사용하여 공동 작업 환경에 대한 콘텐츠 데이터베이스의 데이터 파일에 필요한 스토리지 공간을 추정합니다. 그 결과 약 105GB가 필요합니다.

입력 값
문서 수(D) 200,000
10,000명의 사용자와 20개의 문서를 곱한 것으로 가정하여 계산
평균 문서 크기(S) 250KB
목록 항목(L) 600,000
최신 버전이 아닌 버전의 수(V) 2
허용되는 최대 버전 수를 10으로 가정

데이터베이스 크기 = (((200,000 x 2)) x 250) + ((10KB x (600,000 + (200,000 x 2))) = 110,000,000KB 또는 105GB

참고

SharePoint Server의 효율적인 파일 I/O는 파일이 별도로 저장 및 업데이트되는 조각으로 분할되는 스토리지 방법입니다. 이러한 위치는 사용자가 파일을 요청하면 함께 스트리밍됩니다. 이렇게 하면 I/O 성능은 향상되지만 일반적으로 파일 크기는 증가하지 않습니다. 그러나 작은 파일은 필요한 디스크 저장소에서 약간 증가할 수 있습니다.

콘텐츠 데이터베이스의 크기에 영향을 주는 기능

다음 SharePoint Server 기능은 콘텐츠 데이터베이스의 크기에 영향을 줄 수 있습니다.

  • 휴지통 문서가 첫 번째 단계와 두 번째 단계 휴지통 모두에서 완전히 삭제될 때까지 콘텐츠 데이터베이스의 공간을 차지합니다. 매달 삭제되는 문서 수를 계산하여 휴지통이 콘텐츠 데이터베이스 크기에 미치는 영향을 확인합니다.

  • 감사 감사 데이터는 특히 보기 감사가 켜져 있는 경우 콘텐츠 데이터베이스에서 대량의 공간을 빠르게 복합화하고 사용할 수 있습니다. 제약 조건 없이 감사 데이터를 증가시키는 대신 규정 요구 사항 또는 내부 제어를 충족하는 데 중요한 이벤트에 대해서만 감사를 사용하도록 설정하는 것이 좋습니다. 다음 지침을 사용하여 감사 데이터를 위해 예약해야 하는 공간을 추정합니다.

    • 사이트에 대한 새 감사 항목 수를 예측하고 이 수치에 2KB를 곱합니다(항목은 대개 4KB로 제한되며 평균 크기는 약 1KB임).

    • 할당하려는 공간에 따라 감사 로그를 유지할 일 수를 결정합니다.

참고

Office Online Server는 차기 버전의 Office Web Apps 서버입니다. SharePoint Server 2016, 2019에서 Office Online Server를 사용하는 구독 버전은 콘텐츠 데이터베이스의 크기에 영향을 주지 않습니다. SharePoint Server 2016 팜에 Office Online Server를 배포하려면 Office Online Server 배포를 참조하세요.

콘텐츠 데이터베이스 IOPS 요구 사항 예측

콘텐츠 데이터베이스에 대한 IOPS 요구 사항은 환경 사용 방법, 사용 가능한 디스크 공간 및 서버 수에 따라 달라집니다. 일반적으로 환경의 예상 작업량과 Microsoft에서 테스트한 솔루션 중 하나를 비교하는 것이 좋습니다. 최신 버전의 SharePoint에 적용할 수 있는 자세한 내용은 성능 및 용량 테스트 결과 및 권장 사항(SharePoint Server 2013)을 참조하세요.

테스트 결과, 콘텐츠 데이터베이스의 범위는 0.05IOPS/GB~0.2 IOPS/GB인 것으로 확인되었습니다. 또한 상한을 0.5IOPS/GB로 증가하는 것이 가장 좋은 것으로 확인되었습니다. 이 증가된 비율은 필요한 것보다 많으며 사용자 환경에서 필요한 것보다 훨씬 더 많을 수 있습니다. 미러링을 사용하는 경우 이 비율이 증가하면 주 콘텐츠 데이터베이스보다 훨씬 더 많은 IO가 발생합니다. 미러된 콘텐츠 데이터베이스는 결코 간단하지 않습니다.

서비스 애플리케이션 스토리지 요구 사항 및 IOPS 예측

콘텐츠 저장소 및 IOPS 요구 사항을 예측한 후에는 환경에서 현재 사용되는 서비스 응용 프로그램에 필요한 저장소 및 IOPS를 결정해야 합니다.

SharePoint Server 서비스 응용 프로그램 저장소 및 IOPS 요구 사항

시스템의 서비스 응용 프로그램에 대한 저장소 요구 사항을 예측하려면 먼저 서비스 응용 프로그램과 해당 응용 프로그램을 사용하는 방식을 확인해야 합니다. SharePoint Server 2016에서 사용할 수 있고 데이터베이스가 있는 서비스 애플리케이션은 다음 표에 나와 있습니다. SharePoint Server Subscription Edition, 2019 또는 2016의 모든 서비스 애플리케이션에 대한 스토리지 및 IOPS 데이터는 SharePoint Server 2010 및 2013과 동일하게 유지됩니다.

Search Service 애플리케이션 스토리지 및 IOPS 요구 사항

Database 확장 디스크 IOPS 디스크 크기 1,000만 개의 항목 1억 개의 항목
크롤링 2,000만 개의 항목당 DB 하나
SQL IOPS: 1DPS당 10		 보통/높음 보통 15GB
2GB 로그		 110GB
50GB 로그
링크 6,000만 개의 항목당 DB 하나
SQL IOPS: 100만 개의 항목당 10		 보통 보통 10GB
0.1GB 로그		 80GB
5GB 로그
분석 보고 100~300GB에 도달하면 분할 보통 보통 사용량에 따라 다름 사용량에 따라 다름
Search Administration DB 하나 낮음 낮음 0.4GB
1GB 로그		 데이터 1GB
2GB 로그

서비스 응용 프로그램 저장소 요구 사항 및 IOPS 권장 사항

서비스 응용 프로그램 크기 예측 권장 사항
User Profile 응용 프로그램은 세 개의 데이터베이스(프로필, 동기화 및 공유 태그 지정)와 연결되어 있습니다.
참고: 사용자 프로필 데이터베이스 스토리지 요구 사항 및 IOPS 권장 사항에 대한 테스트는 아직 완료되지 않았습니다. 자세한 내용은 다시 확인하세요.
User Profile 데이터베이스에 대한 자세한 내용은 SharePoint Server의 데이터베이스 형식 및 설명을 참조하세요.
Managed Metadata Service 응용 프로그램에는 하나의 데이터베이스가 포함되어 있습니다. 데이터베이스의 크기는 시스템에서 사용되는 콘텐츠 형식 및 키워드의 수의 영향을 받습니다. 많은 환경에는 여러 개의 Managed Metadata Service 응용 프로그램 인스턴스가 포함됩니다
Secure Store Service Secure Store 서비스 애플리케이션 데이터베이스의 크기는 저장소의 자격 증명 수와 감사 테이블의 항목 수에 따라 결정됩니다. 1,000개 자격 증명마다 5MB를 할당하는 것이 좋습니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다.
State Service 상태 서비스 애플리케이션에는 하나의 데이터베이스가 있습니다. 1GB를 할당하는 것이 좋습니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다.
Word Automation Services Word Automation 서비스 애플리케이션에는 하나의 데이터베이스가 있습니다. 1GB를 할당하는 것이 좋습니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다.
PerformancePoint Services PerformancePoint 서비스 애플리케이션에는 하나의 데이터베이스가 있습니다. 1GB를 할당하는 것이 좋습니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다.
Business Data Connectivity 서비스 Business Data Connectivity 서비스 애플리케이션에는 하나의 데이터베이스가 있습니다. 이 데이터베이스는 작으며 상당한 증가 가능성은 낮습니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다. PerformancePoint Services는 구독 버전에 적용되지 않습니다.
App Management App Management 서비스 애플리케이션에는 하나의 데이터베이스가 있습니다. 이 데이터베이스는 작으며 상당한 증가 가능성은 낮습니다. 이 데이터베이스의 경우 자격 증명 1천 개마다 5MB를 할당하는 것이 좋으며 IOPS는 최소 수준입니다.
Power Pivot Power Pivot Service 애플리케이션에는 하나의 데이터베이스가 있습니다. 이 데이터베이스는 크기가 작고 유의한 I/O 영향이 없습니다. 동일한 IOPS를 SharePoint 콘텐츠 데이터베이스로 사용하는 것이 좋습니다. 콘텐츠 데이터베이스는 Power Pivot 서비스 애플리케이션 데이터베이스보다 I/O 요구 사항이 훨씬 높습니다.

가용성 요구 사항 확인

가용성은 사용자가 사용할 수 있는 SharePoint Server 환경의 양입니다. 사용 가능한 시스템은 복원력이 있는 시스템입니다. 즉, 서비스에 영향을 주는 인시던트는 드물게 발생하며, 발생할 때 시기적절하고 효과적인 조치를 취합니다.

가용성 요구 사항에 따라 저장소 요구 사항이 크게 증가할 수 있습니다. 자세한 내용은 Create a high availability architecture and strategy for SharePoint Server을 참조하세요. 또한 SQL Server 2012 백서 Always On 아키텍처 가이드: Always On 가용성 그룹을 사용하여 고가용성 및 재해 복구 솔루션 구축을 참조하세요.

SQL Server 버전 및 에디션 선택

SharePoint Server 구독 버전, 2019 또는 2016의 경우 다음 SQL Server의 Enterprise Edition 환경을 실행하여 이러한 버전에서 제공하는 다른 성능, 가용성, 보안 및 관리 기능을 활용하는 것이 좋습니다.

  • SQL Server 2019(SharePoint 구독 버전, 2019 및 2016)

  • SQL Server 2017 RTM(SharePoint Server 2016 및 2019)

  • SQL Server 2016(SharePoint Server 2016 및 2019)

  • SQL Server 2014 SP1(서비스 팩 1)(SharePoint Server 2016만)

이러한 버전의 이점에 대한 자세한 내용은 SQL Server 2014 버전에서 지원되는 기능, SQL Server 2016의버전 및 지원되는 기능, SQL Server 2017의 버전 및 지원되는 기능, SQL Server 2019(15.x)의 버전 및 지원되는 기능을 참조하세요.

SharePoint Server 2013의 경우 이러한 버전이 제공하는 다른 성능, 가용성, 보안 및 관리 기능을 활용하려면 SQL Server 2008 R2 SP1(서비스 팩 1), SQL Server 2012 또는 SQL Server 2014의 Enterprise Edition에서 환경을 실행하는 것이 좋습니다. SP1, SQL Server 2012 및 SQL Server 2014 Enterprise Edition을 사용하는 SQL Server 2008 R2의 이점에 대한 자세한 내용은 SQL Server 2014 버전에서 지원하는 기능, SQL Server 2012버전에서 지원하는 기능 및 SQL Server 2008R2 버전에서 지원하는 기능을 참조하세요.

특히, 다음 기능에 대한 요구 사항을 고려해야 합니다.

  • 백업 압축 백업 압축은 모든 SharePoint 백업 속도를 높일 수 있으며 모든 버전의 SQL Server 2008 이상에서 사용할 수 있습니다. 백업 스크립트에서 압축 옵션을 설정하거나 기본적으로 압축하도록 SQL Server를 실행하는 서버를 구성하여 데이터베이스 백업 및 제공된 로그의 크기를 크게 줄일 수 있습니다. 자세한 내용은 백업 압축(SQL Server)을 참조하세요.

    참고

    SQL Server 데이터 압축은 Search Service 응용 프로그램 데이터베이스를 제외하고는 SharePoint Server에서 지원되지 않습니다.

  • 투명한 데이터 암호화 보안 요구 사항에 투명한 데이터 암호화에 대한 요구 사항이 포함되어 있는 경우 SQL Server 엔터프라이즈 버전을 사용해야 합니다.

  • 콘텐츠 배포 콘텐츠 배포 기능을 사용하려는 경우 시스템에서 데이터베이스 스냅숏을 활용할 수 있도록 SQL Server 엔터프라이즈 버전을 사용하는 것이 좋습니다.

    참고

    데이터베이스 스냅숏을 지원하지 않는 원격 BLOB 저장소 공급자를 사용하는 경우 콘텐츠 배포 또는 백업에 스냅숏을 사용할 수 없습니다.

  • 원격 BLOB 스토리지 각 콘텐츠 데이터베이스와 연결된 파일 외부에 있는 위치 또는 데이터베이스에 대해 원격 BLOB 스토리지를 활용하려는 경우 다음의 Enterprise Edition을 사용해야 합니다.

    SharePoint Server 구독 버전

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint Server 2019

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint Server 2016:

    • SQL Server 2014(SP1)

    • SQL Server 2016

    • SQL Server 2017 RTM

    • SQL Server 2019

    SharePoint 2013:

    • SQL Server 2008 R2 SP1

    • SQL Server 2012 Enterprise Edition

  • 리소스 관리자 Resource Governor는 들어오는 요청에 의한 리소스 사용 제한을 지정하여 SQL Server 워크로드 및 리소스를 관리할 수 있도록 SQL Server 2008에 도입된 기술입니다. 또한 리소스 관리자를 통해 각 작업을 구분하고 지정된 제한에 따라 작업 요청 시 CPU와 메모리를 할당할 수 있습니다. 리소스 관리자를 사용하는 방법에 대한 자세한 내용은 리소스 관리자를 참조하세요.

    다음 작업을 수행할 때 리소스 관리자와 SharePoint Server를 함께 사용하는 것이 좋습니다.

    • 검색 크롤링 구성 요소의 대상이 되는 웹 서버에서 사용하는 SQL Server 리소스의 양을 제한합니다. 시스템에 부하가 많을 때는 크롤링 구성 요소의 CPU 사용량을 전체의 10%로 제한하는 것이 가장 좋습니다.

    • 시스템의 각 데이터베이스에서 사용되는 리소스의 수 모니터링. 예를 들어 리소스 관리자를 사용하여 SQL Server를 실행하는 컴퓨터 중에서 최적의 데이터베이스 배치를 손쉽게 결정할 수 있습니다.

  • SharePoint용 Microsoft 파워 피벗 사용자가 웹용 Excel에서 사용자가 생성한 데이터 모델 및 분석을 공유하고 공동 작업하면서 해당 분석을 자동으로 새로 고침할 수 있습니다. 웹용 Excel을 SharePoint 및 SharePoint Server 2016용 파워 피벗과 함께 사용하려면 웹용 Office가 있어야 합니다. SharePoint Server 2016에서 비즈니스 인텔리전스용 SQL Server 2014(SP1) 또는 SQL Server 2016 RTM Enterprise Edition 및 SQL Server Analysis Services를 사용할 수 있습니다. 그러나 SQL Server 2014(SP1)가 아닌 SQL Server 2016 RTM에서만 SharePoint용 파워 피벗을 사용할 수 있습니다.

  • SharePoint 2013용 파워 피벗 사용자가 Excel 및 브라우저에서 사용자가 생성한 데이터 모델 및 분석을 공유하고 공동 작업하면서 해당 분석을 자동으로 새로 고침할 수 있습니다. SQL Server 2008 R2 Analysis Services(SSAS) 데이터 센터 및 Enterprise Edition, SQL Server 2012 SP1 Analysis Services(SSAS) Enterprise Edition 및 SQL Server 2014 Analysis Services(SSAS) Enterprise 및 Business Intelligence Edition의 일부입니다.

용량 및 I/O 요구 사항에 따른 스토리지 아키텍처 디자인

환경에 대해 선택하는 저장소 아키텍처 및 디스크 유형은 시스템 성능에 영향을 줄 수 있습니다.

이 섹션의 내용

저장소 아키텍처 선택

SharePoint Server는 DAS(직접 연결 스토리지), SAN(스토리지 영역 네트워크) 및 NAS(네트워크 연결 스토리지) 스토리지 아키텍처를 지원하지만 NAS는 원격 BLOB 스토리지를 사용하도록 구성된 콘텐츠 데이터베이스에서만 사용할 수 있습니다. 선택은 비즈니스 솔루션 및 기존 인프라 내에 포함된 요소에 따라 달라집니다.

모든 저장소 아키텍처는 가용성 요구 사항을 지원하고 적절한 IOPS 및 대기 시간의 성능을 갖추어야 합니다. 시스템이 적절히 유지되려면 데이터의 첫 번째 바이트를 20밀리초(ms) 이내에 일관되게 반환해야 합니다.

DAS(직접 연결된 저장소)

DAS는 중간에 저장소 네트워크 없이 서버 또는 워크스테이션에 바로 연결되는 디지털 저장소 시스템입니다. DAS 실제 디스크 유형에는 SAS(Serial Attached SCSI)와 SATA(Serial Attached ATA)가 있습니다.

일반적으로 공유 저장소 플랫폼에서 20ms의 응답 시간과 평균 및 최대 IOPS에 대한 충분한 용량을 보장할 수 없는 경우 DAS 아키텍처를 선택하는 것이 좋습니다.

SAN(Storage Area Network)

SAN은 장치가 운영 체제에 로컬로 연결된 것처럼 보이도록(예: 블록 저장소) 원격 컴퓨터 저장 장치(예: 디스크 배열 및 테이프 라이브러리)를 서버에 연결하는 아키텍처입니다.

일반적으로 SAN은 공유 저장소의 이점이 조직에 중요한 역할을 하는 경우에 선택하는 것이 좋습니다.

공유 저장소의 이점은 다음과 같습니다.

  • 서버 간 디스크 저장 용량 재할당 용이

  • 여러 서버 지원 가능

  • 액세스할 수 있는 디스크 수에 제한이 없음

NAS

NAS 단위는 네트워크에 연결된 자체 포함 컴퓨터입니다. 유일한 목적은 네트워크의 다른 디바이스에 파일 기반 데이터 스토리지 서비스를 제공하는 것입니다. NAS 장치의 운영 체제 및 기타 소프트웨어는 데이터 저장소, 파일 시스템 및 파일 액세스 기능과 이러한 기능의 관리(예: 파일 저장소) 기능을 제공합니다.

참고

NAS는 RBS(원격 BLOB 저장소)를 사용하도록 구성된 콘텐츠 데이터베이스에 대해서만 사용할 수 있습니다. 모든 네트워크 저장소 아키텍처는 1ms 이내에 ping에 대해 응답하고 20ms 이내에 데이터의 첫 번째 바이트를 반환해야 합니다. 이 제한은 동일한 서버에 로컬로만 데이터를 저장하기 때문에 로컬 SQL Server FILESTREAM 공급자에는 적용되지 않습니다.

참고

iSCSI(Internet Small Computer System Interface)를 사용하고 이를 NAS 프로토콜로 가정할 경우 약간의 혼동이 발생합니다. CFIS(Common Internet File System)를 통해 이 iSCSI 저장소에 액세스할 경우 이는 NAS 프로토콜입니다. 따라서 RBS를 사용하도록 구성되지 않은 경우 콘텐츠 데이터베이스에서 이 저장소를 사용할 수 없습니다. 그러나 로컬로 연결된 하드 디스크를 통해 이 iSCSI에 액세스하는 경우 이는 SAN 아키텍처로 간주됩니다. 따라서 NAS에서 사용할 수 있습니다.

디스크 유형 선택

시스템에서 사용하는 디스크 유형은 안정성과 성능에 영향을 줄 수 있습니다. 다른 구성 요소도 마찬가지이지만 드라이브가 크면 평균 탐색 시간이 증가합니다. SharePoint Server는 다음과 같은 유형의 드라이브를 지원합니다.

  • 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에는 모든 RAID 유형이 지원됩니다. 그러나 RAID 10 또는 동등한 성능을 가진 공급업체별 RAID 솔루션을 사용하는 것이 좋습니다.

RAID 배열을 구성할 때는 공급업체에서 제공하는 오프셋에 파일 시스템을 정렬해야 합니다.

SQL Server에 대해 RAID를 구축하는 방법에 대한 자세한 내용은 RAID를 참조하세요.

메모리 요구 사항 예측

SharePoint Server에 필요한 메모리는 SQL Server가 실행되는 서버에서 호스팅하는 콘텐츠 데이터베이스의 크기와 직접 관련이 있습니다.

서비스 응용 프로그램과 기능을 추가하면 그에 따라 요구 사항도 증가하는 경향이 있습니다. 다음 표에는 권장되는 메모리의 양에 대한 지침이 나와 있습니다.

다양한 크기 조합의 콘텐츠 데이터베이스 SQL Server가 실행되는 컴퓨터에 권장되는 RAM
소규모 프로덕션 배포를 위한 최소 용량 8GB
중간 규모 프로덕션 배포를 위한 최소 용량 16GB
최대 2TB에 대한 권장 용량 32GB
2TB에서 최대 5TB에 이르는 범위에 대한 권장 용량 64GB
5TB가 넘는 규모에 대한 권장 용량 64GB를 초과하는 추가 RAM은 SQL Server 캐싱 속도를 향상시킬 수 있습니다.

참고

이러한 값은 SharePoint Server 환경에 필요한 데이터의 분포로 인해 SQL Server의 최소값으로 권장되는 값보다 높습니다. SQL Server 시스템 요구 사항에 대한 자세한 내용은 SQL Server 2014 설치를 위한 하드웨어 및 소프트웨어 요구 사항 및 SQL Server 2016 및 2017용 SQL Server 설치를 위한 하드웨어 및 소프트웨어 요구 사항을 참조하세요.

SQL Server 용량 제한 및 사양에 대한 자세한 내용은 SQL Server 버전별 컴퓨팅 용량 제한 및 SQL Server 최대 용량 사양을 참조하세요.

필요한 메모리에 영향을 줄 수 있는 다른 요인은 다음과 같습니다.

  • SQL Server 미러링 사용

  • 15MB가 넘는 파일의 빈번한 사용

네트워크 토폴로지 요구 사항 이해

팜 내에는 물론 팜 간에도 네트워크 연결을 계획합니다. 네트워크는 대기 시간이 짧은 것을 사용하는 것이 좋습니다.

다음 목록에서는 몇 가지 모범 사례와 권장 사항을 제공합니다

  • 팜의 모든 서버에는 SQL Server를 실행하는 서버에 대한 LAN 대역폭 및 대기 시간이 있어야 합니다. 대기 시간은 1밀리초 이내여야 합니다.

  • SQL Server가 실행되는 서버를 대기 시간이 1ms를 초과하는 네트워크를 통해 팜의 다른 구성 요소에서 원격으로 배포하는 WAN(Wide Area Network) 토폴로지는 사용하지 않는 것이 좋습니다. 이 토폴로지는 아직 테스트를 받지 않았습니다.

  • AlwaysOn 구현 제품군, 미러링, 로그 전달 또는 장애 조치(failover) 클러스터링을 SQL Server를 사용하여 원격 사이트를 최신 상태로 유지하려는 경우 적절한 WAN 네트워크를 계획합니다.

  • 웹 서버 및 응용 프로그램 서버에는 두 개의 네트워크 어댑터가 있는 것이 좋습니다. 이 경우 네트워크 어댑터 하나는 최종 사용자 트래픽을 처리하고 다른 하나는 SQL Server가 실행되는 서버와의 통신을 처리합니다.

    참고

    iSCSI를 사용하는 경우 각 네트워크 어댑터가 네트워크 통신과 iSCI 중 하나에만 전용되도록 해야 합니다.

SQL Server 구성

SharePoint Server에 대해 SQL Server를 구성하는 방법을 설명합니다.

이 섹션의 내용

필요한 서버 수 예측

일반적으로 SharePoint Server은 SQL Server 수평 확장을 활용하도록 디자인되었습니다. 예를 들어 SharePoint Server은 몇 대에 불과한 대규모 서버보다는 SQL Server가 실행되는 많은 수의 중간 규모 서버에서 더 뛰어난 성능을 낼 수 있습니다.

항상 다른 팜 역할을 실행하거나 다른 애플리케이션에 대한 데이터베이스를 호스팅하지 않는 전용 서버에 SQL Server를 배치합니다. 이러한 권장 지침의 유일한 예외는 개발 환경 또는 성능이 중요하지 않은 테스트 환경용 독립 실행형 서버에 시스템을 배포한 경우입니다. SQL Server를 SharePoint가 실행되는 동일한 서버에서 실행할 수 있지만 성능 향상을 위해 별도 서버에서 SQL Server를 실행하는 것이 좋습니다.

다음은 SQL Server 인스턴스를 실행할 추가 서버를 배포하는 경우를 위한 일반적인 지침입니다.

  • 용량에서 실행되는 웹 서버가 4개 이상인 경우 다른 데이터베이스 서버를 추가합니다.

  • 현재 서버가 RAM, CPU, 디스크 IO 처리량, 디스크 용량 또는 네트워크 처리량의 유효 리소스 제한에 도달하면 다른 데이터베이스 서버를 추가합니다.

자세한 내용은 SQL Server 버전에 따른 컴퓨팅 용량 제한 및 SQL Server의 최대 용량 사양을 참조하세요.

Secure Store Service 응용 프로그램을 실행할 때 자격 증명을 보다 안전하게 저장할 수 있도록 Secure Store 데이터베이스는 액세스 권한이 한 명의 관리자로 제한된 별도의 데이터베이스 인스턴스에서 호스팅하는 것이 좋습니다.

저장소 및 메모리 구성

SQL Server이 실행되는 서버에서는 메모리를 개선하기 위해 CPU당 L2 캐시가 최소 2MB인 것이 좋습니다.

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

실제 저장소 배열을 구성할 때 최상의 성능을 얻으려면 운영 체제의 기본값에 의존하지 말고 저장소 공급업체에서 제공하는 하드웨어 구성 권장 사항을 준수합니다.

공급업체의 지침이 없는 경우 Windows Server 2012 R2에 사용할 수 있는 PowerShell 스토리지 cmdlet을 사용하는 것이 좋습니다. 자세한 내용은 Windows PowerShell의 스토리지 Cmdlet을 참조하세요.

가능한 한 많은 리소스 제공

디스크에 대한 SQL Server 채널이 페이징 파일 및 IIS(인터넷 정보 서비스) 로그 등의 다른 용도로 공유되지 않도록 합니다.

가능한 한 많은 버스 대역폭을 제공합니다. 더 큰 버스 대역폭은 안정성과 성능을 향상시키는 데 도움이 됩니다. 디스크가 버스 대역폭의 유일한 사용자가 아니라는 점을 고려합니다. 예를 들어 네트워크 액세스도 고려해야 합니다.

SQL Server 옵션 설정

다음은 SharePoint Server를 배포하기 전에 구성해야 하는 SQL Server 설정 및 옵션입니다.

  • SQL Server를 호스트하고 SharePoint Server를 지원하는 서버에서 자동 생성 통계를 사용하도록 설정하지 마세요. SharePoint Server는 프로비전 및 업그레이드 시 필요한 설정을 구성합니다. 통계 자동 생성은 쿼리의 실행 계획을 SQL Server의 한 인스턴스에서 SQL Server의 다른 인스턴스로 변경할 수 있습니다. 따라서 모든 고객에게 일관된 지원을 제공하기 위해 SharePoint Server는 모든 시나리오에서 최상의 성능을 제공하기 위해 필요에 따라 쿼리에 대한 코딩된 힌트를 제공합니다.

  • 최적의 성능을 보장하려면 최대 병렬 처리 수준(MAXDOP) 을 SharePoint Server 데이터베이스를 호스트하는 1개의 SQL Server 인스턴스로 설정하는 것이 좋습니다. 최대 병렬 처리 수준을 설정하는 방법에 대한 자세한 내용은 최대 병렬 처리 수준 서버 구성 옵션 구성을 참조하세요.

데이터베이스 구성

다음 지침에서는 환경의 각 데이터베이스를 구성할 때 계획을 세우기 위한 모범 사례를 설명합니다.

디스크 간 데이터 분리 및 우선 순위 지정

tempdb 데이터베이스, 콘텐츠 데이터베이스, 데이터베이스, 검색 데이터베이스, SQL Server 2019, SQL Server 2017 RTM, SQL Server 2016, SQL Server 2014(SP1), SQL Server 2012 및 SQL Server 2008 R2 SP1 트랜잭션 로그를 별도의 물리적 하드 디스크에 배치하는 것이 가장 이상적입니다.

다음 목록에는 데이터의 우선 순위를 지정하기 위한 모범 사례 및 권장 사항이 나와 있습니다.

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

    • Tempdb 데이터 파일 및 트랜잭션 로그

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

    • 검색 데이터베이스(검색 관리 데이터베이스는 제외)

    • 데이터베이스 데이터 파일

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

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

  • 최상의 성능을 위해 tempdb를 RAID 10 배열에 배치합니다. tempdb 데이터 파일의 수는 코어 CPU 수와 같아야 하며 tempdb 데이터 파일은 동일한 크기로 설정해야 합니다. 이 목적을 위해 이중 코어 프로세서를 두 CPU로 계산합니다. 하이퍼 스레딩을 지원하는 각 프로세서를 단일 CPU로 계산합니다. 자세한 내용은 tempdb 성능 최적화를 참조하세요.

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

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

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

최상의 성능을 얻으려면 다음 권장 사항을 따릅니다.

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

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

  • 데이터 파일 수는 코어 CPU 수보다 작거나 같아야 합니다. 이 목적을 위해 이중 코어 프로세서를 두 CPU로 계산합니다. 하이퍼 스레딩을 지원하는 각 프로세서를 단일 CPU로 계산합니다.

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

중요

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

파일 그룹을 만들고 관리하는 방법에 대한 자세한 내용은 실제 데이터베이스 파일 및 파일 그룹을 참조하세요.

콘텐츠 데이터베이스 크기를 제한하여 관리 효율성 향상

환경의 관리 효율성, 성능 및 업그레이드 편의성을 향상시킬 수 있도록 데이터베이스 크기 지정을 계획합니다.

시스템 성능을 손쉽게 높이려면 특정 사용 시나리오 및 조건에서 더 큰 크기를 지원하는 경우를 제외하고는 콘텐츠 데이터베이스의 크기를 200GB로 제한하는 것이 좋습니다. 콘텐츠 데이터베이스 크기 제한에 대한 자세한 내용은 SharePoint Server 2016 및 2019에 대한 소프트웨어 경계 및 제한의 "콘텐츠 데이터베이스 제한" 섹션을 참조하세요.

사이트 모음은 데이터베이스의 유일한 사이트 모음인 경우를 제외하고 100GB를 초과하지 않아야 합니다. 이러한 제한을 통해 SharePoint Server 세분화된 백업 도구를 사용하여 필요한 경우 사이트 모음을 다른 데이터베이스로 이동할 수 있습니다.

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

다음 권장 사항을 고려하여 데이터 및 로그 파일의 증가를 사전에 관리하는 것이 좋습니다.

  • 가능한 경우 모든 데이터 및 로그 파일을 예상되는 최종 크기까지 미리 늘려 봅니다.

  • 안전상의 이유로 자동 증가를 사용하도록 설정하는 것이 좋습니다. 기본 자동 증가 설정은 사용하지 마세요. 자동 증가를 구성할 때 다음 지침을 고려합니다.

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

    • 콘텐츠 데이터베이스의 계산된 크기가 내년에 권장되는 최대 크기인 200GB에 도달하지 않을 것으로 예상되는 경우 ALTER DATABASE MAXSIZE 속성을 사용하여 데이터베이스가 1년에 도달할 것으로 예상되는 최대 크기(오류의 경우 20%의 추가 여백)로 설정합니다. 이 설정을 주기적으로 검토하여 과거의 증가율을 토대로 이 값이 여전히 적절한지 확인합니다.

  • 디스크에 최소한 25%의 사용 가능한 공간을 유지하여 증가 및 최대 사용 패턴을 허용합니다. 디스크를 RAID 배열에 추가하거나 추가 저장 용량을 할당하는 방식으로 증가율을 관리하는 경우 공간이 부족한 상황이 발생하지 않도록 하려면 디스크 크기를 주의 깊게 모니터링합니다.

저장소 및 SQL Server 성능 유효성 검사 및 모니터링

하드웨어의 성능 및 백업 솔루션을 통해 SLA(서비스 수준 계약)를 충족할 수 있는지 테스트합니다. 특히 SQL Server를 실행하는 컴퓨터의 I/O 하위 시스템을 테스트하여 성능이 만족스러운지 확인합니다.

사용하는 백업 솔루션을 테스트하여 허용되는 유지 관리 창 이내에 시스템을 백업할 수 있는지 확인합니다. 백업 솔루션이 비즈니스에 필요한 SLA를 충족할 수 없는 경우 Microsoft System Center Data Protection Manager와 같은 증분 백업 솔루션을 사용하는 것이 좋습니다.

SQL Server를 실행하는 서버의 리소스 구성 요소인 CPU, 메모리, 캐시/적중률 및 I/O 하위 시스템을 추적하는 것이 중요합니다. 하나 이상의 구성 요소가 느려지거나 부하가 과도한 것처럼 보이면 현재 및 예상 작업량을 기반으로 적합한 전략을 분석합니다. 자세한 내용은 성능 모니터링 및 조정을 참조하세요.

다음 섹션에서는 SharePoint Server 환경에서 실행되는 SQL Server 데이터베이스의 성능을 모니터링하는 데 사용하는 것이 좋습니다. 또한 각 카운터의 대략적인 상태 값도 나와 있습니다.

성능을 모니터링하고 성능 카운터를 사용하는 방법에 대한 자세한 내용은 Windows 성능 모니터 및 성능 모니터링을 참조하세요.

모니터링할 SQL Server 카운터

다음 SQL Server 카운터를 모니터링하여 서버의 상태를 확인합니다.

  • 일반 통계 이 개체는 현재 연결 수 및 SQL Server 인스턴스를 실행하는 컴퓨터에서 초당 연결 및 연결 끊기 사용자 수와 같은 일반 서버 전체 활동을 모니터링하는 카운터를 제공합니다. 모니터링할 카운터는 다음과 같습니다.

    • 사용자 연결 이 카운터는 SQL Server를 실행하는 컴퓨터의 사용자 연결 수를 보여 줍니다. 이 수가 기준선에서 500%까지 증가하면 성능이 저하될 수 있습니다.

  • 데이터베이스 이 개체는 대량 복사 작업, 백업 및 복원 처리량 및 트랜잭션 로그 활동을 모니터링하는 카운터를 제공합니다. 트랜잭션 및 트랜잭션 로그를 모니터링하여 데이터베이스에서 발생하는 사용자 작업의 양과 트랜잭션 로그가 얼마나 채워지고 있는지 알 수 있습니다. 사용자 작업량은 데이터베이스 성능을 좌우하며 로그 크기, 잠금 및 복제에 영향을 줄 수 있습니다. 낮은 수준의 로그 작업을 모니터링하여 사용자 작업과 리소스 사용량을 측정하면 성능 병목 현상을 식별하는 데 도움이 될 수 있습니다. 모니터링할 카운터는 다음과 같습니다.

    • Transactions/sec 이 카운터는 지정된 데이터베이스 또는 초당 전체 서버의 트랜잭션 수를 보여 줍니다. 이 수치는 초기 계획에 가까우며 문제를 해결하는 데 도움이 됩니다.

  • 잠금 이 개체는 개별 리소스 종류에 대한 SQL Server 잠금에 대한 정보를 제공합니다. 모니터링할 카운터는 다음과 같습니다.

    • Average Wait Time (ms) 이 카운터는 대기를 발생시킨 각 잠금 요청의 평균 대기 시간을 보여 줍니다.

    • Lock Wait Time (ms) 이 카운터는 마지막 초의 잠금에 대한 대기 시간을 보여 줍니다.

    • Lock waits/sec 이 카운터는 바로 충족할 수 없어 리소스를 기다려야 했던 초당 잠금 수를 보여 줍니다.

    • 교착 상태 수/초 이 카운터는 초당 SQL Server를 실행하는 컴퓨터의 교착 상태 수를 보여 줍니다. 이 숫자는 0을 초과하면 안 됩니다.

  • 래치 이 개체는 래치라는 내부 SQL Server 리소스 잠금을 모니터링하는 카운터를 제공합니다. 래치를 모니터링하여 사용자 작업 및 리소스 사용량을 확인하면 성능 병목 현상을 식별하는 데 도움이 될 수 있습니다. 모니터링할 카운터는 다음과 같습니다.

    • Average Latch Wait Time (ms) 이 카운터는 대기해야 했던 래치 요청의 평균 래치 대기 시간을 보여 줍니다.

    • Latch Waits/sec 이 카운터는 바로 승인할 수 없었던 래치 요청의 수를 보여 줍니다.

  • SQL 통계 이 개체는 컴파일 및 SQL Server 인스턴스로 전송된 요청 유형을 모니터링하는 카운터를 제공합니다. 쿼리 컴파일 및 다시 컴파일 수와 SQL Server 인스턴스에서 받은 일괄 처리 수를 모니터링하면 SQL Server가 사용자 쿼리를 처리하는 빈도와 쿼리 최적화 프로그램이 쿼리를 얼마나 효과적으로 처리하고 있는지를 알 수 있습니다. 모니터링할 카운터는 다음과 같습니다.

    • SQL Compilations/sec 이 카운터는 컴파일 코드 경로가 입력되는 초당 횟수를 나타냅니다.

    • SQL Re-Compilations/sec 이 카운터는 문이 다시 컴파일되는 초당 횟수를 나타냅니다.

  • 버퍼 관리자 이 개체는 SQL Server가 메모리를 사용하여 데이터 페이지, 내부 데이터 구조 및 프로시저 캐시를 저장하는 방법을 모니터링하는 카운터를 제공하고 SQL Server가 데이터베이스 페이지를 읽고 쓸 때 물리적 I/O를 모니터링하는 카운터도 제공합니다. 모니터링할 카운터는 다음과 같습니다.

    • Buffer Cache Hit Ratio

    • 이 카운터는 디스크에서 읽어들이지 않고 버퍼 캐시에서 검색된 페이지의 비율을 보여 줍니다. 이 비율은 최근 수천 페이지의 액세스가 발생하는 동안의 총 캐시 조회 수로 총 캐시 적중 수를 나눈 것입니다. 캐시에서 읽어들이면 디스크에서 읽어들이는 경우보다 비용이 훨씬 저렴하므로 이 비율은 높아야 합니다. 일반적으로 SQL Server에서 사용할 수 있는 메모리를 늘려 버퍼 캐시 적중률을 높일 수 있습니다.

  • 계획 캐시 이 개체는 SQL Server에서 메모리를 사용하여 저장 프로시저, 준비되지 않은 준비된 Transact-SQL 문 및 트리거와 같은 개체를 저장하는 방법을 모니터링하는 카운터를 제공합니다. 모니터링할 카운터는 다음과 같습니다.

    • Cache Hit Ratio

    • 이 카운터는 계획에 대한 캐시 적중 수와 캐시 조회 수 간의 비율을 나타냅니다.

모니터링할 실제 서버 카운터

다음 카운터를 모니터링하여 SQL Server를 실행하는 컴퓨터의 상태를 확인합니다.

  • 프로세서: % 프로세서 시간: _Total 이 카운터는 프로세서가 유휴 상태 이외의 애플리케이션 또는 운영 체제 프로세스를 실행하는 시간의 백분율을 보여줍니다. SQL Server를 실행하는 컴퓨터에서 이 카운터는 50%에서 75% 사이로 유지되어야 합니다. 일정한 오버로드가 있는 경우 비정상적인 프로세스 작업이 있는지 또는 서버에 더 많은 CPU가 필요한지 조사합니다.

  • 시스템: 프로세서 큐 길이 이 카운터는 프로세서 큐의 스레드 수를 보여 줍니다. 이 카운터를 모니터링하여 이 수치가 코어 CPU 수의 두 배보다 작게 유지되는지 확인합니다.

  • 메모리: 사용 가능한 Mbytes 이 카운터는 컴퓨터에서 실행되는 프로세스에 사용할 수 있는 실제 메모리(MB)를 보여줍니다. 이 카운터를 모니터링하여 사용 가능한 총 실제 RAM의 20% 이상의 수준을 유지 관리합니다.

  • 메모리: Pages/sec 이 카운터는 하드 페이지 오류를 해결하기 위해 디스크에서 페이지를 읽거나 디스크에 쓰는 속도를 보여 줍니다. 이 카운터를 모니터링하여 수치가 100 미만으로 유지되는지 확인합니다.

자세한 내용 및 메모리 문제 해결 방법을 보려면 다음 리소스를 참조하세요.

메모리 문제 해결 방법에 대한 자세한 내용은 SQL Server 2008 R2 SP1의 메모리 사용률 모니터링, SQL Server 2012의 메모리 사용률 모니터링 및 SQL Server 2014의 메모리 사용률 모니터링을 참조하세요.

모니터링할 디스크 카운터

다음 카운터를 모니터링하여 디스크의 상태를 확인합니다. 다음 값은 시간에 따라 측정된 값을 나타내며, 급격한 급증 시 발생하는 값이 아니라 단일 측정값을 기반으로 하는 값이 아닙니다.

  • 실제 디스크: % 디스크 시간: DataDrive 이 카운터는 선택한 디스크 드라이브가 읽기 또는 쓰기 요청을 처리할 때 경과된 시간의 백분율을 보여 줍니다. 이는 디스크 사용량이 얼마나 많은지를 나타내는 일반적인 지표입니다. PhysicalDisk: % Disk Time 카운터가 높은 경우(90% 이상) PhysicalDisk: 현재 디스크 큐 길이 카운터를 확인하여 디스크 액세스를 기다리는 시스템 요청 수를 확인합니다. 대기 중인 I/O 요청 수는 실제 디스크를 구성하는 스핀들 수의 1.5~2배 이하로 유지되어야 합니다.

  • 논리 디스크: 디스크 전송/초 이 카운터는 디스크에서 읽기 및 쓰기 작업이 수행되는 속도를 보여 줍니다. 이 카운터를 사용하여 증가 추세를 모니터링하고 적절히 예측합니다.

  • Logical Disk: Disk Read Bytes/sec 및 Logical Disk: Disk Write Bytes/sec 이러한 카운터는 읽기 또는 쓰기 작업이 수행되는 동안 디스크에서 바이트가 전송되는 속도를 보여 줍니다.

  • 논리 디스크: 평균 디스크 바이트/읽기 이 카운터는 읽기 작업 중에 디스크에서 전송된 평균 바이트 수를 보여 줍니다. 이 값은 디스크 대기 시간을 나타낼 수 있으며, 읽기 작업 시간이 긴 경우 대기 시간이 약간 증가할 수 있습니다.

  • 논리 디스크: 평균 디스크 바이트/쓰기 이 카운터는 쓰기 작업 중에 디스크로 전송되는 평균 바이트 수를 보여 줍니다. 이 값은 디스크 대기 시간을 나타낼 수 있으며, 쓰기 작업 시간이 긴 경우 대기 시간이 약간 증가할 수 있습니다.

  • 논리 디스크: 현재 디스크 큐 길이 이 카운터는 성능 데이터가 수집될 때 디스크에서 미해결 요청 수를 보여 줍니다. 이 카운터의 경우에는 값이 낮을수록 좋습니다. 디스크당 값이 2를 초과하면 병목 현상을 나타낼 수 있으므로 조사해야 합니다. 따라서 4개의 디스크로 구성된 LUN(논리 단위)에 대해 최대 8의 값을 사용할 수 있습니다. 병목 현상이 발생하면 현재 디스크에 액세스하고 있는 서버를 넘어 확산될 수 있는 백로그가 만들어져 사용자가 장시간 대기하게 될 수 있습니다. 병목 현상에 대한 해결책은 RAID 배열에 디스크를 추가하거나, 기존 디스크를 보다 빠른 디스크로 교체하거나, 일부 데이터를 다른 디스크로 이동하는 것입니다.

  • 논리 디스크: 평균 디스크 큐 길이 이 카운터는 샘플 간격 동안 선택한 디스크에 대해 큐에 대기된 읽기 및 쓰기 요청의 평균 수를 보여 줍니다. 규칙은 스핀들당 두 개 이하의 미해결 읽기 및 쓰기 요청이 있어야 한다는 것입니다. 그러나 스토리지 가상화 및 구성 간의 RAID 수준 차이로 인해 이 요청 수를 측정하기 어려울 수 있습니다. 평균 디스크 대기 시간보다 큰 디스크 큐 길이와 함께 평균보다 큰 디스크 큐 길이를 찾습니다. 이 조합은 스토리지 배열 캐시가 과용되거나 다른 애플리케이션과의 스핀들 공유가 성능에 영향을 미치고 있음을 나타낼 수 있습니다.

  • 논리 디스크: 평균 디스크 초/읽기 및 논리 디스크: 평균 디스크 초/쓰기 이 카운터는 디스크에 대한 읽기 또는 쓰기 작업의 평균 시간(초)을 표시합니다. 이들 카운터를 모니터링하여 해당 수치가 디스크 용량의 85% 미만을 유지하는지 확인합니다. 읽기 또는 쓰기 작업이 디스크 용량의 85%를 초과하면 디스크 액세스 시간이 크게 증가합니다. 하드웨어의 구체적인 용량을 확인하려면 공급업체 설명서를 참조하거나 저장소 테스트 도구인 Diskspd Utility를 사용하여 계산합니다. 자세한 내용은 Diskspd: 강력한 스토리지 성능 도구를 참조하세요.

    • 논리 디스크: 평균 디스크 초/읽기 이 카운터는 디스크의 읽기 작업의 평균 시간(초)을 보여줍니다. 잘 조정된 시스템에서 이상적인 값은 로그의 경우 1~5ms(캐시된 배열의 경우 이상적으로는 1ms), 데이터의 경우 4~20ms(이상적으로는 10ms 미만)입니다. 사용량이 많은 시간에 더 높은 대기 시간이 발생할 수 있습니다. 그러나 높은 값이 정기적으로 발생하는 경우 원인을 조사해야 합니다.

    • 논리 디스크: 평균 디스크 초/쓰기 이 카운터는 디스크에 대한 쓰기 작업의 평균 시간(초)을 보여줍니다. 잘 조정된 시스템에서 이상적인 값은 로그의 경우 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과 같이 계산할 수 있습니다.

  • disk queue length 는 5/2 = 2.5와 같이 계산할 수 있습니다.

  • 이 경우 경계선 I/O 병목 현상이 발생하게 됩니다.

다른 모니터링 도구

SQL Server 2008의 sys.dm_io_virtual_file_stats 동적 관리 뷰를 사용하여 디스크 대기 시간을 모니터링하고 추세를 분석할 수도 있습니다. 자세한 내용은 sys.dm_io_virtual_file_stats(Transact-SQL)를 참조하세요.

SharePoint Server 2013용 SQL Server 2012

일련의 온라인 SQL Server 2012 교육 모듈을 제공하기 위해 Microsoft 선임 제품 마케팅 관리자이자 MicroTechPoint의 CEO이자 설립자인 Brian Alderman은 Bill Baer에게 감사를 드립니다. 특히 이러한 온라인 교육 모듈을 호스팅하도록 도와주신 Channel 9 Microsoft에 감사드립니다. 다음 교육 모듈에서는 SharePoint Server 2016 성능, 가용성 및 보안을 개선하는 방법을 알아보는 데 도움이 되는 SQL Server 2012 데이터베이스 설정에 대한 세부 정보를 제공합니다.

참고 항목

개념

SharePoint Server 2016 및 2019 환경의 SQL Server 개요

SharePoint Server 2013의 성능 최적화

SharePoint Server 팜의 SQL Server 모범 사례

SharePoint Server 2013에서 계획 하는 성능에 대 한 계획

SharePoint Server 2013의 용량 관리 및 크기 조정 개요

SharePoint Server 2013에 대한 용량 계획

기타 리소스

SharePoint Server 2013 환경의 SQL Server 개요