SQL Server 디자인 고려 사항

System Center Operations Manager가 운영, 데이터 웨어하우스 및 ACS 감사 데이터베이스를 지원하려면 Microsoft SQL Server를 실행하는 서버 인스턴스에 액세스할 수 있어야 합니다. 운영 및 데이터 웨어하우스 데이터베이스는 관리 그룹의 첫 번째 관리 서버를 배포할 때 필요하고 생성되는 반면, ACS 데이터베이스는 관리 그룹의 ACS 수집기를 배포할 때 생성됩니다.

Operations Manager의 랩 환경 또는 소규모 배포에서는 SQL Server를 관리 그룹의 첫 번째 관리 서버에 공동 배치할 수 있습니다.

중간 및 대규모 분산 배포에서는 SQL Server 인스턴스를 전용 독립 실행형 서버 또는 SQL Server 고가용성 구성에 배치해야 합니다. 어떤 경우든 첫 번째 관리 서버 또는 ACS 수집기의 설치를 시작하기 전에 SQL Server가 이미 존재하고 액세스할 수 있어야 합니다.

다른 애플리케이션 데이터베이스가 있는 SQL 인스턴스에서 Operations Manager 데이터베이스를 사용하지 않는 것이 좋습니다. 이는 I/O 및 기타 하드웨어 리소스 제한과 관련된 잠재적인 문제를 방지하기 위해서입니다.

중요

Operations Manager는 Azure SQL Managed Instance 또는 AWS RDS(Amazon Relational Database Service)와 같은 제품을 포함하여 SQL의 PaaS(Platform as a Service) 인스턴스를 지원하지 않습니다. Windows 컴퓨터에 설치된 SQL Server instance 사용하세요. 이에 대한 유일한 예외는 Azure SQL MI를 활용하며 재구성할 수 없는 Azure Monitor SCOM Managed Instance 내에 있습니다.

SQL Server 요구 사항

다음 버전의 SQL Server Enterprise 및 Standard Edition은 기존에 설치된 System Center Operations Manager 버전에 지원되어 보고 서버, 운영, 데이터 웨어하우스 및 ACS 데이터베이스를 호스팅합니다.

• SQL Server 2022

• 2019년 SQL Server CU8(누적 업데이트 8) 이상

  참고

  • Operations Manager 2022는 CU8 이상의 SQL 2019를 지원합니다. 그러나 SQL 2019 RTM은 지원하지 않습니다.
  • ODBC 17.3 이상 및 MSOLEDBSQL 18.2 이상을 사용합니다.

• SQL Server 2017 및 누적 업데이트(여기에 자세히 설명되어 있음)

SQL Server 업그레이드하기 전에 2017의 업그레이드 정보 및 SQL 2019에 대한 업그레이드 정보를 참조하세요.

참고

• SCOM 인프라를 지원하는 다음 SQL Server 구성 요소는 각각 동일한 SQL Server 주 버전에 있어야 합니다.
  • SCOM 데이터베이스(즉, OperationManager, OperationManagerDW 및 SSRS 데이터베이스 ReportServer & ReportServerTempDB)를 호스트하는 데이터베이스 엔진 인스턴스를 SQL Server.
  • SSRS(SQL Server Reporting Services) 인스턴스
• SQL Server 데이터 정렬 설정은 아래의 SQL Server 데이터 정렬 설정 섹션에 설명된 대로 지원되는 형식 중 하나여야 합니다.
• SQL Server 전체 텍스트 검색은 SCOM 데이터베이스를 호스트하는 모든 SQL Server 데이터베이스 엔진 인스턴스에 필요합니다.
• Operations Manager 데이터베이스 구성 요소에서 지원되는 Windows Server 2016 설치 옵션(Server Core, 데스크톱 환경 포함 서버 및 Nano 서버)은 SQL Server에서 지원되는 Windows Server 설치 옵션을 기반으로 합니다.

참고

System Center Operations Manager 보고는 이전 버전의 보고 역할과 나란히 설치할 수 없으며 기본 모드로만 설치 해야 합니다 (SharePoint 통합 모드는 지원되지 않음).

추가 하드웨어 및 소프트웨어 고려 사항이 디자인 계획에 적용됩니다.

• NTFS 파일 형식의 컴퓨터에서 SQL Server를 실행하는 것이 좋습니다.
• 운영 및 데이터 웨어하우스 데이터베이스에 사용 가능한 디스크 공간이 1024MB 이상 있어야 합니다. 데이터베이스를 만들 때 적용되며 설치 후 크게 증가할 수 있습니다.
• .NET Framework 4가 필요합니다.
• .NET Framework 4.8은 Operations Manager 2022부터 지원됩니다.
• 보고 서버는 Windows Server Core에서 지원되지 않습니다.

자세한 내용은 SQL Server 설치를 위한 하드웨어 및 소프트웨어 요구 사항을 참조하세요.

참고

Operations Manager는 설치 중에 Windows 인증만 사용하지만 로컬 계정에 db_owner 역할이 없는 경우에도 SQL 혼합 모드 인증 설정이 계속 작동합니다. db_owner 역할이 있는 로컬 계정은 System Center Operations Manager에 문제를 일으키는 것으로 알려져 있습니다. 제품을 설치하기 전에 모든 로컬 계정에서 db_owner 역할을 제거하고 설치 후 로컬 계정에 db_owner 역할을 추가하지 마세요.

SQL Server 데이터 정렬 설정

System Center Operations Manager에서 지원되는 SQL Server 및 Windows 데이터 정렬은 다음과 같습니다.

참고

비교 또는 복사 작업에서 호환성 문제를 방지하려면 SQL 및 Operations Manager DB에 동일한 데이터 정렬을 사용하는 것이 좋습니다.

SQL Server 데이터 정렬

• SQL_Latin1_General_CP1_CI_AS

Windows 데이터 정렬

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

SQL Server instance 앞에서 나열된 지원되는 데이터 정렬 중 하나로 구성되지 않은 경우 Operations Manager 설치의 새 설정을 수행하지 못합니다. 그러나 전체 업그레이드는 성공적으로 완료됩니다.

방화벽 구성

Operations Manager는 기록 운영 데이터를 분석 및 제공하기 위해 SQL Server를 사용하여 해당 데이터베이스 및 보고 플랫폼을 호스트합니다. 관리 서버, 운영 및 웹 콘솔 역할은 SQL Server 성공적으로 통신할 수 있어야 하며 환경을 올바르게 구성하려면 통신 경로 및 포트를 이해하는 것이 중요합니다.

Sql Always On 가용성 그룹이 Operations Manager 데이터베이스에 대한 장애 조치 기능을 제공해야 하는 분산 배포를 디자인하는 경우 방화벽 보안 전략에 포함해야 하는 추가 방화벽 구성 설정이 있습니다.

다음 표에서 Operations Manager 관리 그룹의 서버 역할이 성공적으로 통신하기 위해 최소한 허용해야 하는, SQL Server에 필요한 방화벽 포트를 확인할 수 있습니다.

시나리오	포트	Direction	Operations Manager 역할
Operations Manager 데이터베이스를 호스트하는 SQL Server	TCP 1433 *	인바운드	관리 서버 및 웹 콘솔(Application Advisor 및 애플리케이션 진단용)
SQL Server Browser 서비스	UDP 1434	인바운드	관리 서버
SQL Server 전용 관리자 연결	TCP 1434	인바운드	관리 서버
SQL Server에서 사용되는 추가 포트 - MS RPC(Microsoft 원격 프로시저 호출) - WMI(Windows Management Instrumentation) - MS DTC(Microsoft Distributed Transaction Coordinator)	TCP 135	인바운드	관리 서버
SQL Server Always On 가용성 그룹 수신기	관리자가 구성한 포트	인바운드	관리 서버
Operations Manager 보고 서버를 호스트하는 SQL Server Reporting Services	TCP 80(기본값)/443(SSL)	인바운드	관리 서버 및 운영 콘솔

* TCP 1433이 데이터베이스 엔진의 기본 인스턴스에 대한 표준 포트이지만 독립 실행형 SQL Server에 명명된 인스턴스를 만들거나 SQL Always On 가용성 그룹을 배포한 경우 사용자 지정 포트가 정의되며, 설치하는 동안 방화벽을 제대로 구성하고 이 정보를 입력할 수 있도록 참조를 위해 문서화해야 합니다.

SQL Server에 대한 방화벽 요구 사항의 자세한 개요는 SQL Server 액세스를 허용하도록 Windows 방화벽 구성을 참조하세요.

용량 및 스토리지 고려 사항

Operations Manager 데이터베이스

Operations Manager 데이터베이스는 Operations Manager에서 일상적인 모니터링을 수행하는 데 필요한 모든 데이터를 포함하는 SQL Server 데이터베이스입니다. 데이터베이스 서버의 크기 조정 및 구성은 관리 그룹의 전반적인 성능에 매우 중요합니다. Operations Manager 데이터베이스에서 사용하는 가장 중요한 리소스는 스토리지 하위 시스템이지만 CPU와 RAM도 중요합니다.

Operations Manager 데이터베이스의 부하에 영향을 주는 요인은 다음과 같습니다.

• 운영 데이터 수집 속도. 운영 데이터는 에이전트에서 수집하는 모든 이벤트, 경고, 상태 변경 및 성능 데이터로 구성됩니다. Operations Manager 데이터베이스에서 사용하는 리소스는 대부분 시스템으로 들어오는 이 데이터를 디스크에 쓰는 데 사용됩니다. 추가 관리 팩을 가져오고 에이전트를 더 추가하면 수집되는 운영 데이터 속도가 증가하는 경향이 있습니다. 에이전트에서 모니터링하는 컴퓨터 유형도 운영 데이터 수집의 전반적인 속도를 결정할 때 사용되는 중요한 요소입니다. 예를 들어 업무상 중요한 데스크톱 컴퓨터를 모니터링하는 에이전트는 다수의 데이터베이스가 있는 SQL Server 인스턴스를 실행하는 서버를 모니터링하는 에이전트보다 적은 데이터를 수집할 것으로 예상할 수 있습니다.
• 인스턴스 공간 변경 속도. Operations Manager 데이터베이스에서 이 데이터를 업데이트하려면 새 운영 데이터를 쓰는 것보다 비용이 더 많이 듭니다. 또한 인스턴스 공간 데이터가 변경될 경우 관리 서버에서 구성 및 그룹 변경을 컴퓨팅하기 위해 Operations Manager 데이터베이스에 추가 쿼리를 수행합니다. 추가 관리 팩을 관리 그룹으로 가져오면 인스턴스 공간 변경 속도가 증가합니다. 관리 그룹에 새 에이전트를 추가하는 경우에도 인스턴스 공간 변경 속도가 일시적으로 증가합니다.
• 운영 콘솔 및 동시에 실행되는 기타 SDK 연결 수. 각 운영 콘솔은 Operations Manager 데이터베이스에서 데이터를 읽습니다. 이 데이터를 쿼리하는 경우 잠재적으로 많은 양의 스토리지 I/O 리소스, CPU 시간 및 RAM이 사용됩니다. 이벤트 보기, 상태 보기, 경고 보기 및 성능 데이터 보기에 많은 양의 운영 데이터를 표시하는 운영 콘솔은 데이터베이스에서 가장 큰 부하를 발생시키는 경향이 있습니다.

Operations Manager 데이터베이스는 관리 그룹의 단일 오류 원인이므로 SQL Server Always On 가용성 그룹 또는 장애 조치 클러스터 인스턴스와 같은 지원되는 장애 조치 구성을 통해 항상 사용 가능하게 만들 수 있습니다.

구성 후 변경 없이도 기존 SQL Always-On 설정으로 Operations Manager 데이터베이스를 설정하고 업그레이드할 수 있습니다.

Operations Manager 데이터베이스에서 SQL Broker를 사용하도록 설정

System Center Operations Manager는 SQL Server Service Broker에 의존하여 모든 작업 운영을 구현합니다. SQL Server Service Broker를 사용하지 않도록 설정하면 모든 작업 운영에 영향이 미칩니다. 결과 동작은 시작된 작업에 따라 달라질 수 있습니다. 따라서 System Center Operations Manager의 작업에서 예기치 않은 동작이 관찰될 때마다 SQL Server Service Broker의 상태를 검사 것이 중요합니다.

SQL Server Service Broker를 사용하도록 설정하려면 다음 단계를 수행합니다.

1. SQL 쿼리 를 실행합니다.

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. is_broker_enabled 필드에 표시되는 값이 is_broker_enabled(일)인 경우 이 단계를 건너뜁니다. 그러지 않은 경우 다음 SQL 쿼리를 실행합니다.

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Operations Manager 데이터 웨어하우스 데이터베이스

System Center - Operations Manager는 거의 실시간으로 보고 데이터 웨어하우스에 데이터를 삽입합니다. 보고 데이터 웨어하우스에 수집되는 모든 데이터 쓰기를 지원하는 이 서버에 충분한 용량을 갖추는 것이 중요합니다. Operations Manager 데이터베이스와 마찬가지로, 보고 데이터 웨어하우스의 가장 중요한 리소스는 스토리지 I/O 하위 시스템입니다. 대부분의 시스템에서 보고 데이터 웨어하우스의 부하는 Operations Manager 데이터베이스와 유사하지만 서로 다를 수 있습니다. 또한 보고에 의한 보고 데이터 웨어하우스의 워크로드는 운영 콘솔 사용에 의한 Operations Manager 데이터베이스의 부하와 다릅니다.

보고 데이터 웨어하우스의 부하에 영향을 주는 요인은 다음과 같습니다.

• 운영 데이터 수집 속도. 보다 효율적으로 보고할 수 있도록 보고 데이터 웨어하우스는 제한된 원시 데이터 양 외에도 집계된 데이터를 계산 및 저장합니다. 이 추가 작업으로 인해 보고 데이터 웨어하우스에 대한 운영 데이터 수집 비용이 Operations Manager 데이터베이스에 대한 비용보다 약간 더 많을 수 있습니다. 이 추가 비용은 일반적으로 보고 데이터 웨어하우스와 Operations Manager 데이터베이스의 검색 데이터 처리 비용 절감을 통해 균형을 이룹니다.
• 동시 보고 사용자 수 또는 예약된 보고서 생성. 보고서에는 대량 데이터가 요약되는 경우가 많기 때문에 각 보고 사용자가 시스템에 상당한 부하를 추가할 수 있습니다. 동시에 실행되는 보고서 수와 실행되는 보고서 유형은 둘 다 전체 용량 요구에 영향을 줍니다. 일반적으로 큰 날짜 범위나 다수의 개체를 쿼리하는 보고서에는 추가 시스템 리소스가 필요합니다.

이러한 요소에 따라 보고 데이터 웨어하우스의 크기를 조정할 때 고려해야 할 몇 가지 권장되는 사례가 있습니다.

• 적절한 스토리지 하위 시스템을 선택합니다. 보고 데이터 웨어하우스는 관리 그룹을 통한 전체 데이터 흐름의 필수적인 부분이므로 보고 데이터 웨어하우스에 적절한 스토리지 하위 시스템을 선택하는 것이 중요합니다. Operations Manager 데이터베이스와 마찬가지로, 대체로 RAID 0 + 1이 가장 적합합니다. 일반적으로 보고 데이터 웨어하우스의 스토리지 하위 시스템은 Operations Manager 데이터베이스의 스토리지 하위 시스템과 유사해야 하며, Operations Manager 데이터베이스에 적용되는 지침은 보고 데이터 웨어하우스에도 적용됩니다.
• 데이터 로그 및 트랜잭션 로그의 적절한 배치를 고려합니다. Operations Manager 데이터베이스의 경우 에이전트 수를 확장할 때 대체로 SQL 데이터와 트랜잭션 로그를 구분하는 것이 좋습니다. Operations Manager 데이터베이스와 보고 데이터 웨어하우스가 둘 다 동일한 서버에 있고 데이터와 트랜잭션 로그를 분리하려는 경우 혜택을 받으려면 Operations Manager 데이터베이스에 대한 트랜잭션 로그를 보고 데이터 웨어하우스와 분리된 실제 볼륨 및 디스크 스핀들에 배치해야 합니다. 볼륨이 적절한 용량을 제공하고 디스크 I/O 성능이 모니터링 및 보고 기능에 부정적인 영향을 주지 않는 한 Operations Manager 데이터베이스 및 보고 데이터 웨어하우스의 데이터 파일은 동일한 물리적 볼륨을 공유할 수 있습니다.
• Operations Manager 데이터베이스와 분리된 서버에 보고 데이터 웨어하우스를 배치하는 것이 좋습니다. 소규모 배포는 종종 동일한 서버에서 Operations Manager 데이터베이스 및 보고 데이터 웨어하우스를 통합할 수 있지만 에이전트 수와 들어오는 운영 데이터의 볼륨을 확장할 때 이를 분리하는 것이 유리합니다. 보고 데이터 웨어하우스와 보고 서버가 Operations Manager 데이터베이스와 분리된 서버에 있을 때 보고 성능이 향상됩니다.

Operations Manager 데이터 웨어하우스 데이터베이스는 관리 그룹의 단일 오류 원인이므로 SQL Server Always On 가용성 그룹 또는 장애 조치 클러스터 인스턴스와 같은 지원되는 장애 조치 구성을 통해 항상 사용 가능하게 만들 수 있습니다.

SQL Server Always On

SQL Server Always On 가용성 그룹에서는 사용자 데이터베이스의 개별 집합(가용성 데이터베이스)에 대한 장애 조치 환경을 지원합니다. 각 가용성 집합 데이터베이스는 가용성 복제본에 의해 호스트됩니다.

System Center 2016 이상 - Operations Manager에서는 장애 조치(failover) 클러스터링보다 SQL Always On을 사용하여 데이터베이스에 고가용성을 제공하는 것이 좋습니다. 두 개의 데이터베이스를 사용하여 영구 데이터 스토리지와 임시 스토리지 요구 사항을 분리하는 기본 모드의 Reporting Services 설치를 제외한 모든 데이터베이스를 AlwaysOn 가용성 그룹에 호스트할 수 있습니다.

Operations Manager 2022를 사용하면 구성 후 변경 없이도 기존 SQL Always-On 설정으로 Operations Manager 데이터베이스를 설정하고 업그레이드할 수 있습니다.

가용성 그룹을 설정하려면 WSFC(Windows Server 장애 조치 클러스터링) 클러스터를 배포하여 가용성 복제본(replica) 호스트하고 클러스터 노드에서 Always On 사용하도록 설정해야 합니다. 그런 다음 Operations Manager SQL Server 데이터베이스를 가용성 데이터베이스로 추가할 수 있습니다.

• Always On 필수 구성 요소에 대해 자세히 알아보세요.
• Always On 가용성 그룹에 대한 WSFC 설정에 대해 자세히 알아봅니다.
• 가용성 그룹 설정에 대해 자세히 알아봅니다.

참고

SQL Always On에 참여하는 SQL Server 노드에서 Operations Manager를 배포한 후 CLR strict security를 사용하도록 설정하려면 각 Operations Manager 데이터베이스에서 SQL 스크립트를 실행합니다.

다중 서브넷 문자열

Operations Manager는 연결 문자열 키 단어(MultiSubnetFailover=True)를 지원하지 않습니다. 가용성 그룹의 수신기 이름(WSFC 클러스터 관리자에서 네트워크 이름 또는 클라이언트 액세스 지점이라고 함)이 다른 서브넷의 여러 IP 주소에 따라 다르기 때문에 교차 사이트 간 장애 조치 구성에서 배포하는 경우와 같이 관리 서버에서 가용성 그룹 수신기로의 클라이언트 연결 요청은 연결 시간 제한에 도달합니다.

다중 서브넷 환경의 가용성 그룹에 서버 노드를 배포한 경우 이 제한을 해결하는 권장 방법은 다음을 수행하는 것입니다.

1. DNS에 단일 활성 IP 주소만 등록하도록 가용성 그룹 수신기의 네트워크 이름을 설정합니다.
2. 등록된 DNS 레코드에 낮은 TTL 값을 사용하도록 클러스터를 구성합니다.

이러한 설정을 통해 다른 서브넷에서 노드로 장애 조치할 때 새 IP 주소를 사용하는 클러스터 이름을 빠르게 복구하고 해결할 수 있습니다.

SQL 노드 중 하나에서 다음 PowerShell 명령을 실행하여 설정을 수정합니다.

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

수신기 이름으로 Always On 사용하는 경우 수신기에서도 이러한 구성을 변경해야 합니다. 가용성 그룹 수신기 구성에 대한 자세한 내용은 다음 설명서를 참조하세요. 가용성 그룹 수신기 구성 - SQL Server Always On

현재 수신기를 호스팅하는 SQL 노드에서 다음 PowerShell 명령을 실행하여 설정을 수정합니다.

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

클러스터된 인스턴스 또는 Always On SQL 인스턴스가 고가용성을 위해 사용되는 경우 노드 간에 장애 조치가 발생할 때면 언제든지 Operations Manager 데이터 액세스 서비스가 다시 시작되지 않도록 방지하기 위해 관리 서버에서 자동 복구 기능을 사용해야 합니다. 이를 구성하는 방법에 대한 자세한 내용은 SQL Server의 인스턴스가 오프라인 상태로 전환된 후에 System Center 관리 서비스가 응답을 중지했습니다. 기술 자료 문서를 참조하세요.

SQL Server 최적화

일반적으로 고객과의 이전 배포 환경은 성능 문제가 일반적으로 SQL Server 자체의 높은 리소스 사용률(즉, 프로세서 또는 메모리)으로 인한 것이 아니라 스토리지 하위 시스템의 구성과 직접 관련이 있음을 보여줍니다. 성능 병목 상태는 주로 SQL Server 데이터베이스 인스턴스용으로 프로비전된 스토리지에 대한 권장 구성 지침을 따르지 않았기 때문에 발생합니다. 이러한 예로 다음을 들 수 있습니다.

• LUN에 할당된 스핀들이 Operations Manager의 IO 요구 사항을 지원하기에 부족합니다.
• 트랜잭션 로그와 데이터베이스 파일을 동일한 볼륨에 호스트합니다. 이러한 두 워크로드는 IO 및 대기 시간 특성이 완전히 다릅니다.
• TempDB의 구성은 배치, 크기 조정 등과 관련하여 잘못되었습니다.
• 데이터베이스 트랜잭션 로그, 데이터베이스 파일 및 TempDB를 호스트하는 볼륨의 디스크 파티션 정렬이 잘못되었습니다.
• 데이터베이스 및 트랜잭션 로그 파일에 AUTOGROW 사용, 쿼리 병렬 처리를 위한 MAXDOP 설정, CPU 코어당 여러 TempDB 데이터 파일 만들기 등과 같은 기본 SQL Server 구성을 간과합니다.

스토리지 구성은 Operations Manager용 SQL Server 배포의 중요한 구성 요소 중 하나입니다. 데이터베이스 서버는 철저한 데이터베이스 읽기 및 쓰기 작업과 트랜잭션 로그 처리로 인해 과도하게 I/O에 바인딩되는 경향이 있습니다. Operations Manager의 I/O 동작 패턴은 일반적으로 80% 쓰기와 20% 읽기입니다. 따라서 I/O 하위 시스템을 잘못 구성하면 SQL Server 시스템의 성능 및 작동이 저하될 수 있으며, Operations Manager에서 두드러집니다.

SQL Server 배포하기 전에 IO 하위 시스템의 처리량 테스트를 수행하여 SQL Server 디자인을 테스트하는 것이 중요합니다. 이러한 테스트가 허용 가능한 대기 시간으로 IO 요구 사항을 달성할 수 있는지 확인합니다. Diskspd 유틸리티를 사용하여 SQL Server를 지원하는 스토리지 하위 시스템의 I/O 용량을 평가합니다. 제품 그룹의 파일 서버 팀 구성원이 작성한 다음 블로그 문서에서는 일부 PowerShell 코드와 함께 이 도구를 사용하여 스트레스 테스트를 수행하고 PerfMon을 사용하여 결과를 캡처하는 방법에 대한 자세한 지침과 권장 사항을 제공합니다. 초기 지침은 Operations Manager 크기 조정 도우미를 참조할 수도 있습니다.

NTFS 할당 단위 크기

RAID 디바이스에서 볼륨을 만들 때마다 일반적으로 섹터 맞춤이라고 하는 볼륨 맞춤을 파일 시스템(NTFS)에서 수행해야 합니다. 이렇게 하지 않으면 성능이 크게 저하 될 수 있으며 가장 일반적으로 스트라이프 단위 경계를 사용한 파티션 정렬이 잘못되었습니다. 또한 하드웨어 캐시 맞춤이 잘못되어 배열 캐시가 비효율적으로 사용될 수도 있습니다. SQL Server 데이터 파일에 사용할 파티션의 서식을 지정할 때는 데이터, 로그 및 tempdb에 64KB 할당 단위 크기(즉, 65,536바이트)를 사용하는 것이 좋습니다. 그러나 4KB보다 큰 할당 단위 크기를 사용하면 볼륨에서 NTFS 압축을 사용할 수 없습니다. SQL Server 압축된 볼륨에서 읽기 전용 데이터를 지원하지만 권장되지는 않습니다.

메모리 예약

참고

이 섹션의 정보 중 다수는 Jonathan Kehayias의 블로그 게시물 How much memory does my SQL Server actually need? (sqlskills.com)에서 발췌한 것입니다.

System Center Operations Manager(또는 이 제품 외의 다른 워크로드)를 지원하기 위해 SQL Server에 할당할 실제 메모리 및 프로세서의 적합한 양을 식별하기가 항상 쉬운 것은 아닙니다. 제품 그룹에서 제공하는 크기 조정 계산기는 워크로드 규모를 기반으로 하는 지침을 제시하기는 하지만, 그 권장 사항은 실습 환경에서 이루어진 테스트를 기반으로 하며 실제 워크로드 및 구성과는 일치하지 않을 수 있습니다.

SQL Server를 사용하면 해당 프로세스에서 예약 및 사용하는 최소 및 최대 메모리 크기를 구성할 수 있습니다. 기본적으로 SQL Server는 사용 가능한 시스템 리소스에 따라 동적으로 메모리 요구 사항을 변경할 수 있습니다. min server memory의 기본 설정은 0이고, max server memory의 기본 설정은 2147483647MB입니다.

max server memory의 값을 적절하게 설정하지 않으면 성능 및 메모리 관련 문제가 발생할 수 있습니다. 많은 요인이 운영 체제가 시스템에서 실행 중인 다른 프로세스(HBA 카드, 관리 에이전트 및 바이러스 백신 실시간 검사 등)를 지원할 수 있도록 SQL Server에 할당해야 하는 메모리에 영향을 미칩니다. 메모리가 충분하지 않으면 OS 및 SQL이 디스크를 호출합니다. 이로 인해 디스크 I/O가 증가하고, 성능 저하 및 Operations Manager에서 확인할 수 있는 파급 효과가 발생할 수 있습니다.

min server memory에 대해 4GB 이상의 RAM을 지정하는 것이 좋습니다. 이 작업은 Operations Manager 데이터베이스(운영, 데이터 웨어하우스, ACS) 중 하나를 호스트하는 모든 SQL 노드에 대해 수행해야 합니다.

max server memory에 대해 다음과 같이 초기 예약하는 것이 좋습니다.

• OS에 대한 1GB RAM
• 설치된 RAM 4GB당 1GB RAM(최대 16GB RAM)
• 설치된 8GB RAM당 1GB RAM(16GB RAM 이상)

값을 설정한 후 Windows의 Memory\Available MBytes 카운터를 모니터링하여 SQL Server에서 사용할 수 있는 메모리를 늘릴 수 있는지 확인합니다. Windows는 사용 가능한 실제 메모리가 96MB에서 부족하다는 신호를 표시하므로 버퍼가 있는지 확인하기 위해 카운터가 약 200-300MB보다 낮게 실행되어서는 안 됩니다. RAM이 256GB 이상인 서버의 경우 1GB보다 낮게 실행되지 않도록 해야 할 수 있습니다.

이러한 계산은 다른 애플리케이션을 고려하여 수정하지 않는 한 SQL Server에서 사용 가능한 모든 메모리를 사용할 수 있다는 가정 하에 수행되었습니다. OS, 기타 애플리케이션 SQL Server 스레드 스택 및 기타 다중 페이지 할당자에 대한 특정 메모리 요구 사항을 고려합니다. 일반적인 공식은 ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators))이며, 여기서 스레드 스택에 대한 메모리는 ((max worker threads) (stack size))입니다. 스택 크기는 x86 시스템의 경우 512KB, x64 시스템의 경우 2MB, IA64 시스템의 경우 4MB이며, sys.dm_os_sys_info의 max_worker_count 열에서 최대 작업자 스레드 값을 확인할 수 있습니다.

이러한 고려 사항은 가상 머신에서 실행할 SQL Server 메모리 요구 사항에도 적용됩니다. SQL Server가 버퍼 풀에서 데이터를 캐시하도록 설계되었고 가능한 많은 메모리를 사용하기 때문에 필요한 RAM의 이상적인 양을 결정하기란 어려울 수 있습니다. SQL Server 인스턴스에 할당된 메모리를 줄이면 메모리 할당 감소에 따라 디스크 I/O 액세스가 증가하는 지점에 이릅니다.

과도하게 프로비저닝된 환경에서 SQL Server 메모리를 구성하려면 우선 환경 및 현재 성능 메트릭(SQL Server Buffer Manager page life expectancy 및 page reads/sec, Physical Disk disk reads/sec 값 포함)을 모니터링합니다. 환경에 메모리가 과도하게 많은 경우 캐싱으로 인해 page life expectancy가 워크로드 감소 없이 초당 1씩 증가합니다. SQL Server Buffer Manager page reads/sec 값은 캐시 증가 이후 낮아지며, Physical Disk disk reads/sec는 낮은 값을 유지합니다.

환경 기준을 이해하면 max server memory를 1GB만큼 줄인 다음(최초 캐시 플러싱 저하 이후) 성능 카운터에 미치는 영향을 확인할 수 있습니다. 메트릭이 허용 가능한 상태로 유지되는 경우 다시 1GB만큼 줄인 다음 다시 모니터링하고, 이상적인 구성을 확인할 때까지 반복합니다.

자세한 내용은 서버 메모리 구성 옵션을 참조하세요.

TempDB 최적화

tempdb 데이터베이스의 크기와 물리적 배치는 Operations Manager의 성능에 영향을 줄 수 있습니다. 예를 들어 tempdb에 대해 정의된 크기가 너무 작으면 SQL Server 인스턴스를 다시 시작할 때마다 워크로드를 지원하는 데 필요한 크기까지 자동 증가하는 tempdb가 부하를 처리하는 시스템 부분을 차지할 수도 있습니다. tempdb 성능을 최적화하려면 프로덕션 환경에서 tempdb에 다음 구성을 사용하는 것이 좋습니다.

• tempdb의 복구 모델을 SIMPLE로 설정합니다. 이 모델은 공간 요구 사항을 작게 유지하기 위해 로그 공간을 자동으로 회수합니다.
• 환경의 일반적인 워크로드를 처리하기에 충분한 큰 값으로 파일 크기를 설정하여 모든 tempdb 파일에 대한 공간을 미리 할당합니다. 이렇게 하면 tempdb가 너무 자주 확장되어 성능에 영향을 주는 것을 방지할 수 있습니다. tempdb 데이터베이스를 자동 증가하도록 설정할 수 있지만, 이 기능은 계획되지 않은 예외를 위해 디스크 공간을 늘리는 데 사용해야 합니다.
• 디스크 대역폭을 최대화하기 위해 필요한 수만큼 파일을 만듭니다. 여러 파일을 사용하면 tempdb 스토리지 경합이 줄어들고 확장성이 향상됩니다. 그러나 성능을 줄이고 관리 오버헤드를 높일 수 있으므로 파일을 너무 많이 만들지 마세요. 일반적인 지침으로, 서버의 논리 프로세서마다 데이터 파일 하나(모든 선호도 마스크 설정 처리)를 만든 다음 필요에 따라 파일 수를 늘리거나 줄입니다. 일반적으로 논리 프로세서 수가 8보다 작거나 같으면 논리 프로세서와 동일한 개수의 데이터 파일을 사용합니다. 논리 프로세서 수가 8보다 크면 8개의 데이터 파일을 사용한 다음, 경합이 계속될 경우 경합이 허용되는 수준으로 감소할 때까지 데이터 파일 수를 논리 프로세서 수까지 4의 배수만큼 늘리거나, 워크로드/코드를 변경합니다. 경합이 줄어들지 않으면 데이터 파일 수를 더 늘려야 할 수 있습니다.
• 각 데이터 파일을 동일한 크기로 만들어 최적의 비례 채우기 성능을 허용합니다. 비례 채우기 알고리즘은 파일 크기를 기반으로 하기 때문에 동일한 데이터 파일 크기 지정이 중요합니다. 서로 다른 크기로 데이터 파일을 만들면 비례 채우기 알고리즘에서 모든 파일에 할당을 분산하는 대신 가장 큰 파일을 GAM 할당에 더 사용하려고 하므로 여러 데이터 파일을 만드는 목적이 상실됩니다.
• 성능을 최적화하려면 SSD(반도체 드라이브)를 사용하는 고속 I/O 하위 시스템에 tempdb 데이터베이스를 배치합니다. 직접 연결되어 있는 디스크가 많으면 디스크 스트라이프를 사용합니다.
• 사용자 데이터베이스에 사용되는 디스크와는 다른 디스크에 tempdb 데이터베이스를 배치합니다.

tempdb를 구성하려면 다음 쿼리를 실행하거나 Management Studio에서 해당 속성을 수정할 수 있습니다.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

T-SQL 쿼리 SELECT * from sys.sysprocesses 를 실행하여 tempdb 데이터베이스에 대한 페이지 할당 경합을 검색합니다. 시스템 테이블 출력에서 대기 리소스가 "2:1:1"(PFS 페이지) 또는 "2:1:3"(공유 전역 할당 맵 페이지)으로 표시될 수 있습니다. 경합 정도에 따라 이로 인해 SQL Server가 짧은 기간 동안 응답하지 않는 것처럼 보일 수도 있습니다. 다른 방법은 동적 관리 뷰[sys.dm_exec_request 또는 sys.dm_os_waiting_tasks]를 검사하는 것입니다. 결과에는 이러한 요청 또는 태스크가 tempdb 리소스를 기다리고 있으며 sys.sysprocesses 쿼리를 실행할 때 이전에 강조 표시된 것과 유사한 값이 있음을 보여 줍니다.

이전 권장 사항이 할당 경합을 크게 줄이지 않고 경합이 SGAM 페이지에 있는 경우 SQL Server 재활용된 후에도 추적 플래그가 계속 적용되도록 SQL Server 대한 시작 매개 변수에서 추적 플래그 -T1118을 구현합니다. 이 추적 플래그를 적용하면 SQL Server에서 각 데이터베이스 개체에 전체 범위를 할당하므로 SGAM 페이지에 대한 경합이 발생하지 않습니다.

참고

이 추적 플래그는 SQL Server instance 모든 데이터베이스에 영향을 줍니다.

최대 병렬 처리 수준

중소 규모의 Operations Manager 배포에 대한 SQL Server의 기본 구성은 대부분의 요구에 적합합니다. 그러나 관리 그룹의 워크로드가 엔터프라이즈 클래스 시나리오(일반적으로 2,000개 이상의 에이전트 관리 시스템 및 고급 가상 트랜잭션을 사용한 서비스 수준 모니터링, 네트워크 디바이스 모니터링, 플랫폼 간 등을 포함하는 고급 모니터링 구성)로 확장되는 경우 문서의 이 섹션에 설명된 SQL Server 구성을 최적화해야 합니다. 이전 지침에서 설명하지 않은 구성 옵션 중 하나는 MAXDOP입니다.

Microsoft SQL Server MAXDOP(최대 병렬 처리 수준) 구성 옵션은 병렬 계획에서 쿼리 실행에 사용되는 프로세서 수를 제어합니다. 이 옵션은 병렬로 작업을 수행하는 쿼리 계획 연산자에 사용되는 컴퓨팅 및 스레드 리소스를 결정합니다. SQL Server 대칭 다중 처리(SMP) 컴퓨터, NUMA(비균등 메모리 액세스) 컴퓨터 또는 하이퍼스레딩 사용 프로세서에 설정되어 있는지 여부에 따라 최대 병렬 처리 수준 옵션을 적절하게 구성해야 합니다.

둘 이상의 마이크로프로세서 또는 CPU가 있는 컴퓨터에서 SQL Server를 실행하면 각 병렬 계획 실행에 대한 최상의 병렬 처리 수준(즉, 단일 문을 실행하는 데 사용되는 프로세서 수)이 검색됩니다. 기본적으로 이 옵션의 값은 0이며, SQL Server가 최대 병렬 처리 수준을 결정할 수 있습니다.

운영, 데이터 웨어하우스 및 감사 데이터베이스와 관련하여 Operations Manager에 미리 정의된 저장 프로시저 및 쿼리에는 MAXDOP 옵션이 포함되지 않습니다. 설치하는 동안 운영 체제에 표시되는 프로세서 수를 동적으로 쿼리할 수 있는 방법이 없고 쿼리가 실행될 때 부정적인 결과를 초래할 수 있는 이 설정의 값을 하드 코딩하려고 시도하지 않기 때문에 MAXDOP 옵션이 포함되어 있지 않습니다.

참고

최대 병렬 처리 수준 구성 옵션은 SQL Server 사용하는 프로세서 수를 제한하지 않습니다. SQL Server에서 사용하는 프로세서 수를 구성하려면 선호도 마스크 구성 옵션을 사용합니다.

• 8개보다 많은 프로세서를 사용하는 서버의 경우 다음 구성을 사용합니다. MAXDOP=8
• 8개 이하의 프로세서를 사용하는 서버의 경우 MAXDOP=0 ~ N 구성을 사용합니다.

  참고

  이 구성에서 N은 프로세서 수를 나타냅니다.