SQL Server 디자인 고려 사항

System Center Operations Manager는 운영, 데이터 웨어하우스 및 ACS 감사 데이터베이스를 지원하기 위해 Microsoft SQL Server를 실행하는 서버 인스턴스에 액세스해야 합니다. 관리 그룹에 첫 번째 관리 서버를 배포할 때는 운영 및 데이터 웨어하우스 데이터베이스가 필요하며, 관리 그룹에 ACS 수집기를 배포할 때 ACS 데이터베이스가 만들어집니다.

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

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

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

Important

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

SQL Server 요구 사항

다음 버전의 SQL Server Enterprise 및 Standard Edition은 Reporting Server, Operational, Data Warehouse 및 ACS 데이터베이스를 호스트하기 위해 System Center Operations Manager 버전의 기존 설치에 대해 지원됩니다.

• SQL Server 2022

• 여기에 설명된 대로 CU8(누적 업데이트 8) 이상의 SQL Server 2019

  참고 항목

  • Operations Manager 2022는 CU8 이상의 SQL 2019를 지원합니다. 그러나 SQL 2019 RTM은 지원하지 않습니다.
  • ODBC 17.3 또는 17.10.6 및 MSOLEDBSQL 18.2 또는 18.7.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 Reporting은 이전 버전의 보고 역할 과 함께 설치할 수 없으며 기본 모드로만 설치해야 합니다 (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 인스턴스가 이전에 나열된 지원되는 데이터 정렬 중 하나로 구성되지 않은 경우 Operations Manager 설정의 새 설정을 수행하지 못합니다. 그러나 현재 위치 업그레이드가 성공적으로 완료됩니다.

방화벽 구성

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

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

다음 표에서는 Operations Manager 관리 그룹의 서버 역할이 성공적으로 통신하기 위해 최소한 허용해야 하는 SQL Server에 필요한 방화벽 포트를 식별하는 데 도움이 됩니다.

시나리오	포트	방향	Operations Manager 역할
Operations Manager 데이터베이스를 호스팅하는 SQL Server	TCP 1433 *	인바운드	관리 서버 및 웹 콘솔(Application Advisor 및 애플리케이션 진단용)
SQL Server Browser 서비스	UDP 1434	인바운드	Management Server
SQL Server 전용 관리자 연결	TCP 1434	인바운드	Management Server
SQL Server에서 사용하는 추가 포트 - Microsoft 원격 프로시저 호출(MS RPC) - WMI(Windows Management Instrumentation) - MS DTC(Microsoft Distributed Transaction Coordinator)	TCP 135	인바운드	Management Server
SQL Server Always On 가용성 그룹 수신기	관리자가 구성한 포트	인바운드	Management Server
Operations Manager Reporting Server를 호스팅하는 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 가용성 그룹 또는 장애 조치(failover) 클러스터 인스턴스와 같은 지원되는 장애 조치(failover) 구성을 사용하여 고가용성을 만들 수 있습니다.

구성 후 변경 없이도 기존 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 값이 1(1)이면 이 단계를 건너뜁니다. 그렇지 않으면 다음 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 데이터베이스 및 보고 데이터 웨어하우스의 데이터 파일은 동일한 물리적 볼륨을 공유할 수 있습니다.
• Reporting Data Warehouse를 Operations Manager 데이터베이스와 별도의 서버에 배치하는 것이 좋습니다. 소규모 배포는 종종 동일한 서버에서 Operations Manager 데이터베이스 및 보고 데이터 웨어하우스를 통합할 수 있지만 에이전트 수와 들어오는 운영 데이터의 볼륨을 확장할 때 이를 분리하는 것이 유리합니다. 보고 데이터 웨어하우스와 Reporting Server가 Operations Manager 데이터베이스와 별도의 서버에 있는 경우 보고 성능이 향상됩니다.

Operations Manager 데이터 웨어하우스 데이터베이스는 관리 그룹에 대한 단일 오류 원본이므로 SQL Server Always On 가용성 그룹 또는 장애 조치(failover) 클러스터 인스턴스와 같은 지원되는 장애 조치(failover) 구성을 사용하여 고가용성을 만들 수 있습니다.

SQL Server Always On

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

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

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

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

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

참고 항목

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

다중 서브넷 문자열

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

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

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

이러한 설정을 사용하면 다른 서브넷의 노드로 장애 조치(failover)할 때 새 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 인스턴스가 고가용성을 위해 사용되는 경우 노드 간의 장애 조치(failover)가 발생할 때마다 Operations Manager 데이터 액세스 서비스가 다시 시작되지 않도록 관리 서버에서 자동 복구 기능을 사용하도록 설정해야 합니다. 이를 구성하는 방법에 대한 자세한 내용은 다음 KB 문서를 참조하세요. System Center Management Service는 SQL Server 인스턴스가 오프라인 상태가 된 후 응답을 중지합니다.

SQL Server 최적화

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

• Operations Manager의 IO 요구 사항을 지원하기 위해 LUN에 대한 스핀들 할당이 부족합니다.
• 동일한 볼륨에서 트랜잭션 로그 및 데이터베이스 파일을 호스팅합니다. 이러한 두 워크로드에는 서로 다른 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에서 가져온 것입니다 얼마나 많은 메모리 내 SQL Server 실제로 필요 합니까? (sqlskills.com).

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

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

최대 서버 메모리에 적절한 값을 설정하지 않으면 성능 및 메모리 관련 문제가 발생할 수 있습니다. 운영 체제가 HBA 카드, 관리 에이전트 및 바이러스 백신 실시간 검사와 같은 해당 시스템에서 실행되는 다른 프로세스를 지원할 수 있도록 하기 위해 SQL Server에 할당해야 하는 메모리 양에 많은 요인이 영향을 줍니다. 충분한 메모리가 설정되지 않은 경우 OS 및 SQL은 디스크에 페이지로 이동됩니다. 이로 인해 디스크 I/O가 증가하여 성능이 더욱 저하되고 Operations Manager에서 눈에 띄는 파급 효과가 생성될 수 있습니다.

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

최대 서버 메모리의 경우 처음에 총을 예약하는 것이 좋습니다.

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

이러한 값을 설정한 후 Windows에서 Memory\Available MBytes 카운터를 모니터링하여 SQL Server에서 사용할 수 있는 메모리를 늘릴 수 있는지 확인합니다. Windows는 사용 가능한 실제 메모리가 96MB에서 낮게 실행되고 있음을 알리므로 버퍼가 있는지 확인하기 위해 카운터가 약 200-300MB보다 낮게 실행되지 않아야 합니다. 256GB 이상의 RAM이 있는 서버의 경우 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 페이지 예상 수명 및 페이지 읽기/초 및 실제 디스크 디스크 읽기/초 값을 포함하여 환경 및 현재 성능 메트릭을 모니터링합니다. 환경에 초과 메모리 가 있는 경우 캐싱으로 인해 워크로드에서 감소하지 않고 페이지 평균 수명이 초당 1초씩 증가합니다. 캐시가 증가하면 SQL Server Buffer Manager 페이지 읽기/초 값이 낮아지고 실제 디스크 읽기/초 도 낮게 유지됩니다.

환경 기준을 이해하면 최대 서버 메모리를 1GB 줄인 다음, 초기 캐시 플러시가 가라앉은 후 성능 카운터에 미치는 영향을 확인할 수 있습니다. 메트릭이 허용 가능한 상태로 유지되면 1GB를 더 줄인 다음, 이상적인 구성을 결정할 때까지 원하는 대로 반복하여 다시 모니터링합니다.

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

TempDB 최적화

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

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

최대 병렬 처리 수준

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

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

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

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

참고 항목

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

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

  참고 항목

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