SQL Server 디자인 고려 사항

System Center Operations Manager는 Microsoft SQL Server를 사용하여 운영, 데이터 웨어하우스 및 ACS 감사 데이터베이스를 지원합니다. 이러한 데이터베이스는 필수이며 관리 그룹에서 첫 번째 관리 서버 또는 ACS 수집기를 배포하는 동안 만들어집니다.

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

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

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

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 및 CU11(최소 누적 업데이트 11) 이상 업데이트는 여기에서 사용할 수 있습니다 .
• SQL Server 2019 CU8(누적 업데이트 8) 이상 업데이트는 여기에서 사용할 수 있습니다 .
• 사용 가능한 최신 업데이트 가 포함된 SQL Server 2017

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

SQL Server 드라이버

이러한 구성 요소는 데이터베이스와 직접 인터페이스하고 이러한 드라이버는 SQL에 대한 API 수준 액세스를 허용하므로 OLE DB 및 ODBC SQL Server 드라이버는 모든 관리 서버 및 웹 콘솔 서버에 설치해야 합니다.

암호화된 SQL Server 연결을 활용하는 것이 좋습니다. 이렇게 할 때 최신 버전의 SQL 드라이버를 설치해야 합니다.

• Microsoft OLE DB 드라이버 최신 버전입니다.
• Microsoft ODBC 드라이버 최신 버전입니다.

SQL 연결 암호화 구성에 대한 자세한 내용은 다음에서 찾을 수 있습니다. 연결 암호화를 위한 SQL Server 데이터베이스 엔진 구성

암호화된 SQL 연결을 사용하지 않는 경우 암호화를 적용하지 않는 SQL 드라이버의 이전 릴리스를 사용합니다.

• Microsoft ODBC Driver 버전 17.10.6.
• Microsoft OLE DB 드라이버 버전 18.7.4.

SQL Server 업데이트

Operations Manager 인프라를 지원하는 다음 SQL Server 구성 요소는 각각 동일한 SQL Server 주 버전에 있어야 합니다.

• 다음을 포함하여 Operations Manager 데이터베이스를 호스팅하는 SQL Server 데이터베이스 엔진 인스턴스:
  • OperationManager
  • OperationManagerDW
  • SSRS 데이터베이스 ReportServer 및 ReportServerTempDB
• SSRS(SQL Server Reporting Services) 인스턴스

SQL Server 인증 모드

기본적으로 SQL은 혼합 모드 인증 구성에서 작동합니다. 그러나 Operations Manager는 WINDOWS 인증 사용하여 SQL Server와 통신합니다. 기본적으로 남아 있는 경우 로컬 계정에 역할이 없는 경우 SQL 혼합 모드 인증 설정이 db_owner 계속 작동합니다. 역할이 있는 db_owner 로컬 계정은 Operations Manager에 문제를 일으키는 것으로 알려져 있습니다.

제품을 설치하기 전에 모든 로컬 계정에서 역할을 제거하고 db_owner 설치 후 로컬 계정에 역할을 추가 db_owner 하지 않는 것이 좋습니다.

기타 고려 사항

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

• NTFS 파일 형식의 SQL 디스크를 사용하는 것이 좋습니다.
• 운영 및 데이터 웨어하우스 데이터베이스에 대해 1GB 이상의 사용 가능한 디스크 공간이 있어야 합니다. 데이터베이스를 만들 때 적용됩니다. 설치 후 데이터베이스의 디스크 사용률이 크게 증가하므로 이 기본 요구 사항보다 충분한 사용 가능한 디스크 공간이 있어야 합니다.
• .NET Framework 4가 필요합니다.
• .NET Framework 4.8은 Operations Manager 2022부터 지원됩니다.
• 보고 서버는 Windows Server Core에서 지원되지 않습니다.
• SQL Server 데이터 정렬 설정은 SQL Server 데이터 정렬 설정 섹션에 설명된 대로 지원되는 형식 중 하나여야 합니다.
• Operations Manager 데이터베이스를 호스팅하는 모든 SQL Server 데이터베이스 엔진 인스턴스에는 SQL Server 전체 텍스트 검색이 필요합니다.
• Operations Manager 데이터베이스 구성 요소에서 지원하는 Windows Server 설치 옵션(Server Core, 데스크톱 환경이 있는 서버 및 Nano Server)은 SQL Server에서 지원하는 설치 옵션을 기반으로 합니다.

자세한 내용은 SQL Server 설치 및 계획 설명서 아래의 하드웨어 및 소프트웨어 요구 사항 섹션을 참조하세요. SQL Server 설치 계획

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와 성공적으로 통신할 수 있어야 하며, 환경을 올바르게 구성하려면 통신 경로 및 포트를 이해하는 것이 중요합니다.

SQL Always On 가용성 그룹을 사용하는 분산 배포를 디자인하는 경우 방화벽 보안 전략에 포함해야 하는 추가 방화벽 구성 설정이 있습니다.

다음 표에서는 관리 서버가 데이터베이스와 통신하기 위해 SQL Server에 필요한 방화벽 포트를 식별합니다.

시나리오	포트	Direction	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 데이터베이스의 부하에 영향을 주는 요인은 다음과 같습니다.

• 운영 데이터 수집 속도입니다.
  • 운영 데이터 수집 속도는 가져온 관리 팩 수, 추가된 에이전트 수 및 모니터링되는 컴퓨터 유형과 같은 요인의 영향을 받습니다. 예를 들어 중요 비즈니스용 데스크톱 컴퓨터를 모니터링하는 에이전트는 여러 데이터베이스가 있는 SQL Server를 실행하는 서버를 모니터링하는 에이전트에 비해 적은 데이터를 수집합니다.
• 인스턴스 공간 변경률입니다.
  • 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 쿼리를 실행하여 broker가 이미 활성화되어 있는지 확인합니다( 필드에서 1(1)is_broker_enabled의 결과로 표시됨:

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

2. 필드에 표시되는 is_broker_enabled 값이 0이면 다음 SQL 문을 실행하여 broker를 사용하도록 설정합니다.

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

Operations Manager Data Warehouse 데이터베이스

참고 항목

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 데이터베이스 및 데이터 웨어하우스를 통합할 수 있지만 에이전트 수와 들어오는 운영 데이터의 볼륨을 확장할 때 이를 분리하는 것이 유리합니다. 데이터 웨어하우스와 Reporting Server가 Operations Manager 데이터베이스와 별도의 서버에 있는 경우 보고 성능이 향상됩니다.

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

SQL Server Always On

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

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

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

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

팁

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.

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

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 문서를 참조하세요. SQL Server 인스턴스가 오프라인 상태가 되면 System Center 관리 서비스가 응답하지 않습니다.

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 용량을 평가합니다. 제품 그룹의 파일 서버 팀 구성원이 작성한 다음 블로그 문서에서는 DiskSpd, PowerShell 및 스토리지 성능( 로컬 디스크 및 SMB 파일 공유 모두에 대한 IOP, 처리량 및 대기 시간 측정)을 사용하여 스트레스 테스트를 수행하는 방법에 대한 자세한 지침과 권장 사항을 제공합니다.

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 인스턴스의 모든 데이터베이스에 영향을 줍니다.

최대 병렬 처리 수준

팁

SQL Server 팀의 최신 모범 사례 및 권장 사항은 다음 설명서를 참조하세요. 최적의 성능을 위해 최대 병렬 처리 수준 옵션 설정

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

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

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

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

참고 항목

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

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

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

  팁

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

• NUMA가 구성된 서버의 경우 MAXDOP는 각 NUMA 노드에 할당된 CPU 수를 초과하면 안 됩니다.

• 하이퍼스레딩을 사용하도록 설정된 서버의 경우 MAXDOP 값이 실제 프로세서 수를 초과하면 안 됩니다.

• NUMA를 구성하고 하이퍼스레딩을 사용하도록 설정한 서버의 경우 MAXDOP 값은 NUMA 노드당 실제 프로세서 수를 초과하면 안 됩니다.

를 쿼리하여 병렬 작업자 수를 모니터링할 수 있습니다 select * from sys.dm_os_tasks.

이 예제에서 서버의 하드웨어 구성은 24개의 코어 프로세서와 196GB RAM이 있는 HP 블레이드 G6이었습니다. Operations Manager 데이터베이스를 호스팅하는 인스턴스의 MAXMEM 설정은 64GB입니다. 이 섹션에서 제안된 최적화를 수행한 후 성능이 향상되었습니다. 그러나 쿼리 병렬 처리 병목 상태는 여전히 유지됩니다. 다른 값을 테스트한 후 MAXDOP=4를 설정하여 가장 최적의 성능을 찾았습니다.

초기 데이터베이스 크기 조정

배포 후 처음 몇 달 이내에 Operations Manager 데이터베이스, 특히 운영 및 데이터 웨어하우스 데이터베이스의 향후 성장을 예측하려는 시도는 간단한 연습이 아닙니다. Operations Manager 크기 조정 도우미는 랩에서의 테스트에서 제품 그룹에서 파생된 수식을 기반으로 잠재적인 성장을 예측하는 데 합리적이지만, 단기 및 장기적으로 성장에 영향을 줄 수 있는 몇 가지 요인을 고려하지 않습니다.

크기 조정 도우미에서 제안한 대로 초기 데이터베이스 크기를 예측된 크기에 할당하여 운영 및 데이터 웨어하우스 데이터베이스에 대한 설치 시간에 지정할 수 있는 조각화 및 해당 오버헤드를 줄여야 합니다. 설치하는 동안 충분한 스토리지 공간을 사용할 수 없는 경우 나중에 SQL Management Studio를 사용하여 데이터베이스를 확장한 다음, 나중에 다시 인덱싱하여 조각 모음하고 그에 따라 최적화할 수 있습니다. 이 권장 사항은 ACS 데이터베이스에도 적용됩니다.

운영 및 데이터 웨어하우스 데이터베이스의 증가에 대한 사전 모니터링은 매일 또는 매주 주기로 수행되어야 합니다. 이는 예기치 않은 중요한 성장 분출을 식별하고, 관리 팩 워크플로의 버그(즉, 검색 규칙, 성능 또는 이벤트 수집 규칙 또는 모니터 또는 경고 규칙)의 버그 또는 릴리스 관리 프로세스의 테스트 및 품질 보증 단계에서 확인되지 않은 관리 팩의 기타 증상에 의해 인과 관계를 확인하기 위해 문제 해결을 시작하는 데 필요합니다.

데이터베이스 자동 증가

예약된 데이터베이스 파일 크기가 가득 차면 SQL Server에서 크기를 백분율 또는 고정 크기로 자동으로 늘릴 수 있습니다. 또한 디스크에서 사용 가능한 모든 공간을 채우지 않도록 최대 데이터베이스 크기를 구성할 수 있습니다. 기본적으로 Operations Manager 데이터베이스는 자동 증가가 설정된 상태로 구성되지 않습니다. 데이터 웨어하우스 및 ACS 데이터베이스만 있습니다.

예기치 않은 성장을 위한 비상 사태로 자동 증가에만 의존합니다. Autogrow는 높은 트랜잭션 데이터베이스를 처리할 때 고려해야 하는 성능 저하를 도입합니다. 성능 페널티는 다음과 같습니다.

• 적절한 증가 증분을 제공하지 않으면 로그 파일 또는 데이터베이스의 조각화가 발생할 수 있습니다.
• 사용 가능한 것보다 많은 로그 공간이 필요한 트랜잭션을 실행하고 해당 데이터베이스의 트랜잭션 로그에 대해 자동 증가가 설정된 경우 트랜잭션이 완료되는 데 걸리는 시간에는 트랜잭션 로그가 구성된 양만큼 증가하는 데 걸리는 시간이 포함됩니다.
• 로그가 증가해야 하는 대규모 트랜잭션을 실행하는 경우 트랜잭션 로그에 쓰기가 필요한 다른 트랜잭션도 증가 작업이 완료될 때까지 기다려야 합니다.

자동 증가 및 자동 축소 옵션이 결합된 경우 불필요한 오버헤드가 발생할 수 있습니다. 증가 및 축소 작업을 트리거하는 임계값이 자주 증가 및 축소 크기를 변경하지 않도록 합니다. 예를 들어 트랜잭션 로그가 커밋할 때까지 100MB씩 증가하는 트랜잭션을 실행할 수 있습니다. 자동 축소가 시작되고 트랜잭션 로그가 100MB씩 축소된 후 얼마 지나지 않습니다. 그런 다음 동일한 트랜잭션을 실행하면 트랜잭션 로그가 다시 100MB씩 증가합니다. 이 예제에서는 불필요한 오버헤드를 만들고 잠재적으로 로그 파일의 조각화를 만들어 성능에 부정적인 영향을 줄 수 있습니다.

이러한 두 설정을 신중하게 구성합니다. 특정 구성은 실제로 사용자 환경에 따라 달라집니다. 일반적인 권장 사항은 디스크 조각화를 줄이기 위해 고정된 크기로 데이터베이스 크기를 늘리는 것입니다. 예를 들어 다음 그림에서는 자동 증가가 필요할 때마다 데이터베이스가 1,024MB씩 증가하도록 구성됩니다.

클러스터 장애 조치(failover) 정책

Windows Server 장애 조치(failover) 클러스터링(Failover) 클러스터링(Failover Clustering)은 클러스터에 있는 노드의 네트워크 연결 및 상태를 지속적으로 모니터링하는 고가용성 플랫폼입니다. 네트워크를 통해 노드에 연결할 수 없는 경우 복구 작업을 수행하여 클러스터의 다른 노드에서 애플리케이션 및 서비스를 온라인 상태로 만듭니다. 기본 설정은 "하드" 오류로 간주되는 서버가 완전히 손실되는 오류에 최적화되어 있습니다. 이러한 오류는 복구할 수 없는 하드웨어 또는 전원 오류와 같은 오류 시나리오입니다. 이러한 상황에서 서버가 손실되고 장애 조치(Failover) 클러스터링이 서버 손실을 신속하게 감지하고 클러스터의 다른 서버에서 신속하게 복구하는 것이 목표입니다. 하드 오류로부터 빠른 복구를 수행하기 위해 클러스터 상태 모니터링에 대한 기본 설정은 매우 공격적입니다. 그러나 다양한 시나리오에 유연성을 허용하도록 완전히 구성할 수 있습니다.

이러한 기본 설정은 대부분의 고객에게 최상의 동작을 제공합니다. 그러나 클러스터가 인치에서 마일 간격으로 늘어나면 클러스터가 노드 간에 더 많은 네트워킹 구성 요소와 잠재적으로 신뢰할 수 없는 네트워킹 구성 요소에 노출될 수 있습니다. 또 다른 요인은 중복 구성 요소(예: 이중 전원 공급 장치, NIC 팀 및 다중 경로 I/O)를 통해 보강된 복원력과 함께 상용 서버의 품질이 지속적으로 증가하고 있다는 것입니다. 하드 오류 빈도가 낮을 수 있으므로 일부 고객은 클러스터가 노드 간의 간단한 네트워크 오류에 대해 복원력이 더 뛰어난 일시적인 오류에 대해 클러스터를 조정하려고 할 수 있습니다. 기본 실패 임계값을 늘리면 짧은 기간 동안 지속되는 간단한 네트워크 문제에 대한 민감도를 줄일 수 있습니다.

여기에 정답이 없으며 최적화된 설정은 특정 비즈니스 요구 사항 및 서비스 수준 계약에 따라 달라질 수 있음을 이해하는 것이 중요합니다.

SQL Server 가상화

가상 환경에서는 성능상의 이유로 운영 데이터베이스 및 데이터 웨어하우스 데이터베이스를 가상 디스크가 아닌 직접 연결된 스토리지에 저장하는 것이 좋습니다. Operations Manager 2012용으로 릴리스된 Operations Manager 크기 조정 도우미 유틸리티를 사용하여 필요한 IOPS를 예측하고 데이터 디스크를 스트레스 테스트하여 확인할 수 있습니다. DiskSpd 유틸리티를 사용하여 스토리지 성능을 테스트할 수 있습니다. 가상화된 Operations Manager 환경에 대한 추가 지침은 Operations Manager 가상화 지원도 참조하세요.

Always On 및 복구 모델

최적화는 아니지만 Always On 가용성 그룹에 대한 중요한 고려 사항은 설계상 이 기능을 사용하려면 데이터베이스를 "전체" 복구 모델에서 설정해야 한다는 사실입니다. 즉, 전체 백업이 수행되거나 트랜잭션 로그만 수행될 때까지 트랜잭션 로그는 삭제되지 않습니다. 이러한 이유로 백업 전략은 선택 사항이 아니라 Operations Manager 데이터베이스에 대한 AlwaysOn 디자인의 필수 부분입니다. 그렇지 않으면 시간이 지나면 트랜잭션 로그가 포함된 디스크가 채워지게 됩니다.

백업 전략은 환경의 세부 정보를 고려해야 합니다. 다음 표에는 일반적인 백업 일정이 제공됩니다.

백업 유형	일정
트랜잭션 로그만	1시간마다
전체	매주, 일요일 오전 3:00

SQL Server 보고 서비스 최적화

Reporting Services 인스턴스는 데이터 웨어하우스 데이터베이스의 데이터에 액세스하기 위한 프록시 역할을 합니다. 관리 팩 내에 저장된 템플릿을 기반으로 보고서를 생성하고 표시합니다.

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

Reporting Services의 백그라운드에서 ReportServer 및 ReportServerTempDB 데이터베이스를 호스트하는 SQL Server 데이터베이스 인스턴스가 있습니다. 이 인스턴스의 성능 튜닝에 대한 일반적인 권장 사항이 적용됩니다.

참고 항목

SSRS(SQL Server Reporting Services) 2017 버전 14.0.600.1274 이상에서는 기본 보안 설정에서 리소스 확장 업로드를 허용하지 않습니다. 이로 인해 보고 구성 요소를 배포하는 동안 Operations Manager에서 ResourceFileFormatNotAllowedException 예외가 발생합니다.

이 문제를 해결하려면

1. SQL Management Studio를 엽니다.
2. Reporting Services 인스턴스에 연결합니다.
3. 개체 탐색기 창에서 서버 인스턴스를 마우스 오른쪽 단추로 클릭합니다.
4. 속성을 선택합니다.
5. 왼쪽 사이드바에서 고급을 선택합니다.
6. AllowedResourceExtensionsForUpload 목록에 추가 *.* 합니다.

또는 Operations Manager의 보고 확장 의 전체 목록을 SSRS의 허용 목록에 추가할 수 있습니다. 목록은 "해결 방법 2"에 설명되어 있습니다 . Operations Manager 보고서가 배포되지 않습니다.

다음 단계

방화벽 뒤에서 (보고) 데이터 웨어하우스 호스팅을 구성하는 방법을 이해하려면 방화벽을 통해 (보고) 데이터 웨어하우스 연결을 참조하세요.