 클러스터된 환경을 사용하여 32비트 플랫폼에서 SQL Server 통합 교훈 게시 날짜: 2004년 5월 1일저자 : Mike Ruthruff 요약: Microsoft는 서로 다른 실제 서버에 배치된 기존의 Microsoft® SQL Server™ 데이터베이스를 클러스터된 32비트 단일 Windows 환경에 통합하는 시나리오를 테스트했습니다. 이 문서에서는 그러한 테스트를 통해 얻은 결과에 대해 설명합니다.
개요 통합 환경에서 Microsoft® SQL Server™의 성능은 사용 중인 하드웨어 및 관련된 SQL Server 작업 부하의 특성에 크게 좌우됩니다. 32비트 플랫폼의 아키텍처에는 몇 가지 제한 사항이 있습니다. 장착된 실제 메모리의 양이 많은 시스템을 SQL Server에서 완벽하게 활용하는 데는 이러한 제한이 적용됩니다. 한 대의 컴퓨터에서 대용량 메모리 리소스를 완벽하게 활용하는 방법 중 하나로 여러 인스턴스를 사용할 수도 있지만, 이와 같이 다중 인스턴스를 사용하려면 SQL Server 튜닝 옵션을 더 신중하게 설정해야 할 수도 있습니다. 특히 SQL Server와 함께 클러스터 서비스를 사용하는 경우에는 더욱 세심한 주의가 필요합니다. Microsoft는 서로 다른 컴퓨터에 배치된 기존의 SQL Server 인스턴스를 클러스터된 32비트 환경에 통합하기 위한 서버를 구축하고 운영하는 시나리오를 테스트했습니다. 이 문서에서는 그러한 테스트를 통해 얻은 결과에 대해 설명합니다. 이 문서에서는 특히 다음과 같은 내용을 제공합니다.
이 문서는 SQL Server 데이터베이스를 통합할 때 발생할 수 있는 모든 문제를 해결하기 위한 것이 아닙니다. 이 문서는 특정 구성에 대한 테스트 과정에서 얻은 정보를 제공하는 데 그 목적이 있습니다. 또한, 이 문서에 나와 있는 시나리오의 결과를 모든 통합 환경에 적용할 필요는 없습니다. SQL Server 통합 환경을 성공적으로 선택하고 구축하기 위해 계획해야 할 사항에 대한 자세한 내용은 부록 B의 "Microsoft SQL Server 2000을 사용한 통합 계획"(영문) 자료를 참조하십시오. 통합 환경 구성 호스트 하드웨어 구성이 문서에 나와 있는 테스트 시나리오에서는 통합 서버로 Unisys ES7000 서버를 사용합니다. 이 서버는 두 개의 파티션으로 분할되어 있으며 각 파티션에는 컴퓨터의 전체 리소스가 절반씩 할당됩니다. 각 파티션은 16개의 CPU, 32GB의 RAM 및 네 개의 Emulex LP9000 HBA(호스트 버스 어댑터)로 구성되었습니다. 각 파티션에는 서비스 팩 3(SP3)이 설치된 SQL Server 2000과 Microsoft Windows® Server™ 2003, Datacenter Edition 운영 체제가 실행됩니다. 각 파티션을 클러스터하는 데는 Windows 클러스터링이 사용되었습니다. Windows 클러스터의 두 노드 각각에서 네 개의 HBA 사이에 I/O 균형을 조정하는 데는 EMC PowerPath 소프트웨어가 사용되었습니다. 저장소 구성이 테스트 환경에 사용된 저장소 구성은 Windows 클러스터링의 요구 사항에 따른 것입니다. SQL Server의 클러스터된 인스턴스와 함께 사용되는 저장소는 크게 다음과 같은 두 가지 요구 사항을 충족해야 합니다.
이러한 요구 사항 이외에도 SAN을 사용하여 클러스터를 구현할 때는 몇 가지 사항을 추가로 고려해야 합니다. SAN 환경에서의 클러스터에 대한 자세한 내용은 부록 B를 참조하십시오. 이 문서에 나와 있는 테스트 시나리오에 사용된 저장소는 EMC Symmetrix 5.5 모델 8530 저장소 배열로 구성되었습니다. 테스트 과정에서 이 배열은 연결되지 않은 다른 SQL Server 테스트를 위한 호스트로도 사용되었습니다. 테스트 시나리오에 사용된 SAN 부분과 관련된 저장소의 총 크기는 약 1.6TB였으며, 9개의 108GB LUN(논리 단위 번호)과 13개의 54GB LUN으로 구성된 22개의 LUN 간에 분산 배치되었습니다. 이러한 LUN은 Windows 드라이브 문자에 매핑되었으며 각 LUN은 개별 볼륨으로 구성되었습니다. 테스트 시나리오에서 SQL Server의 인스턴스는 모두 16개였으며 각 인스턴스에는 한 개 또는 두 개의 볼륨이 있습니다. 데이터베이스 크기는 가장 작은 것이 10GB이고 가장 큰 것이 약 150GB였습니다. 이 문서에 나와 있는 테스트 시나리오의 저장소 구성과 성능 결과에 대한 자세한 내용은 "부록 A: 저장소 구성 및 성능"을 참조하십시오. 데이터베이스 및 통합 작업 부하Microsoft SQL Server 2000은 Windows가 실행되는 한 대의 컴퓨터에서 SQL Server 데이터베이스 엔진의 인스턴스를 최대 16개까지 지원할 수 있습니다. 이 문서에서 설명하고 있는 테스트 시나리오를 위해 Microsoft는 SQL Server의 명명된 인스턴스 16개를 두 개의 클러스터된 노드 구성에 클러스터된 가상 서버로 설치했습니다. SQL Server의 각 인스턴스에는 1개에서 25개 사이의 데이터베이스가 포함되어 있으며 대부분의 인스턴스에 포함된 데이터베이스는 평균 5개입니다. SQL Server의 인스턴스 16개 중 12개에는 Microsoft의 내부 및 외부 구축 환경 모두를 포함한 여러 원본에서 수집한 데이터베이스가 포함되어 있으며 각 원본은 실제 프로덕션 환경의 데이터베이스입니다. 이러한 데이터베이스에 작업 부하를 주는 데는 SQL 프로필러가 사용되었습니다. 프로덕션 작업 부하에 대해 이전에 캡처한 추적 내용을 SQL 프로필러를 사용하여 재생했습니다. 일부 추적에는 유지 관리 작업을 위한 쿼리와 특정 목적을 위해 작성된 기타 쿼리가 약간 포함되어 있지만, 이와 같은 추적을 통해 캡처된 작업 부하 유형은 주로 OLTP(온라인 트랜잭션 처리) 작업 부하입니다. OLTP 작업 부하는 주로 데이터 삽입, 삭제 및 업데이트로 이루어져 있으며 여기에는 몇 가지 선택 쿼리가 포함되어 있습니다. SQL Server의 인스턴스 중 나머지 4개는 대표적인 OLTP 작업 부하가 포함된 데이터베이스 두 개와 대표적인 DSS(의사 결정 지원 시스템)가 포함된 데이터베이스 두 개로 구성되었습니다. DSS는 RDW(관계형 데이터 웨어하우스) 작업 부하라고도 합니다. DSS 작업 부하는 병렬 실행 계획이 포함된 복잡한 읽기 전용 쿼리로 구성되어 있습니다. 병합 작업 부하를 정의하기 전에 Microsoft는 앞서 설명한 특정 하드웨어 환경에서 작업 부하를 사용하여 지원할 수 있는 SQL Server의 동시 인스턴스 수를 결정했습니다. 한 번에 실행할 수 있는 동시 작업 부하의 수는 클러스터의 단일 노드에 대한 하드웨어 용량을 기반으로 결정했습니다. 테스트 시나리오의 작업 부하와 하드웨어 구성에 있어서 제한된 리소스는 CPU입니다. CPU 리소스는 다른 모든 주요 하드웨어 리소스보다 먼저 고갈되었습니다. SQL Server의 동시 인스턴스 10개에 대해 작업 부하를 실행한 결과 단일 노드의 CPU 16개 모두에 걸쳐 평균 CPU 사용량이 거의 80퍼센트에 달했습니다. 이 사용량은 단일 노드의 용량에 근접해 있으며 한두 개의 작업 부하를 추가할 수 있을만큼 충분한 CPU 리소스가 남아 있는 크기이므로 이 값을 통합 작업 부하 기준으로 사용했습니다. 성능을 테스트하는 동안 Microsoft는 서로 다른 네 개의 통합 작업 부하 시나리오를 실행했습니다. 사용된 작업 부하는 표 1.1에 나와 있습니다. 이러한 시나리오는 기준 작업 부하에 OLTP, DDS 및 DBCC(데이터베이스 콘솔 명령) 유지 관리 작업 부하를 추가한 결과를 측정하기 위해 선택된 것입니다. table 1.1 통합 작업 부하 세부 정보
통합 환경에서 작업 부하 성능 관리 SQL Server 튜닝 옵션 대형 시스템의 경우 SP_CONFIGURE 저장 프로시저의 옵션을 사용하여 SQL Server를 튜닝하면 성능을 크게 향상시킬 수 있습니다. 통합 환경에서 서로 다른 구성 설정이 성능에 미치는 영향을 조사하기 위해 Microsoft는 테스트 시나리오 과정에서 서로 다른 설정을 적용한 다음 성능이 향상되거나 저하된 결과를 측정했습니다. 아래에 제시된 각 구성은 표 1.1에서 설명한 네 가지 작업 부하 모두에 대해 테스트한 것입니다.
이 문서에 나와 있는 테스트 시나리오에서는 구성에 사용되는 시스템의 RAM이 32GB이므로 /3GB 부트 옵션을 사용하지 않았습니다. 4GB 이상의 실제 메모리를 활용하려면 Boot.ini 파일에서 /PAE 부트 옵션을 사용하여 Windows를 시작해야 합니다. 16GB 이상의 실제 메모리가 장착된 시스템에 대해 /PAE를 사용하여 /3GB를 활성화하면 시스템을 시작할 때 운영 체제에서 사용 가능한 시스템 메모리를 16GB까지만 인식합니다. 이 테스트 시나리오에서는 최소 서버 메모리 또는 최대 서버 메모리 설정을 수정할 필요가 없었습니다. 이 구성에 사용되는 시스템에는 32GB의 실제 메모리가 장착되어 있고 동시에 실행되는 SQL Server의 활성 인스턴스 수는 12개에 불과했기 때문입니다. 32비트 플랫폼의 경우 SQL Server의 각 인스턴스에 대한 실제 메모리 제한은 2GB까지이므로 테스트 시나리오에서 SQL Server 프로세스에 사용되는 총 메모리의 크기는 24GB를 넘지 않았습니다. SQL Server에 대한 상한 메모리 제한을 설정하는 것이 좋으며, 인스턴스 사이에 메모리가 충돌할 가능성이 있는 경우에는 통합 환경에서 이 제한을 반드시 설정해야 합니다. 사용 가능한 시스템 메모리를 다른 인스턴스에서 거의 모두 사용한 경우 SQL Server 인스턴스를 온라인으로 연결하면 모든 인스턴스 간에 성능이 저하될 수 있습니다. 작업 부하 성능 테스트의 결과를 살펴보면 통합 환경의 경우 일반적으로 다른 SQL Server 튜닝 옵션을 사용할 때보다 기본 서버 설정을 사용할 때 전반적인 성능이 향상되는 것을 알 수 있습니다. 그림 1.1과 그림 1.2에서는 트랜잭션 작업 부하가 있는 SQL Server의 모든 인스턴스에 대한 초당 시스템 CPU 사용량과 총 트랜잭션을 보여 줍니다. 각 작업 부하 유형에 대한 자세한 내용은 표 1.1을 참조하십시오.  그림 1.1 초당 누적 트랜잭션 큰 이미지 보기  그림 1.2 총 CPU 사용량 큰 이미지 보기 그림 1.1과 그림 1.2를 살펴보면 CPU 선호도나 I/O 선호도를 설정한 경우 트랜잭션 처리량이 낮아지고 CPU 리소스가 완전히 활용되지 않는다는 것을 알 수 있습니다. 이러한 결과는 모든 작업 부하 시나리오에서 공통적으로 발견됩니다. 또한, 이와 같은 설정을 사용해도 컨텍스트 스위치의 수가 크게 줄어들지는 않았습니다. 모든 작업 부하 시나리오에서 초당 컨텍스트 스위치의 수는 20,000에서 25,000 사이에 분포해 있습니다. 한번 설정한 CPU 선호도와 I/O 선호도는 자주 변경되지 않으며 CPU의 수가 많은 시스템을 구축하는 경우에만 SQL Server의 단일 인스턴스 성능을 성공적으로 튜닝하거나 다른 인스턴스의 공존 상태를 관리하기 위해 새로 설정하면 됩니다. 그러나 이 테스트 시나리오의 통합 환경에서는 SQL Server를 통해 CPU 리소스를 관리할 수 있게 하여 구성을 단순화하고 모든 작업 부하에 걸쳐 전반적인 처리량을 향상시킬 수 있었습니다. 성능상의 이점은 관련된 작업 부하의 특성에 따라서 크게 다를 수 있으므로 어떠한 설정을 사용할지 결정할 때는 각 상황별로 테스트를 수행하는 것이 좋습니다. 위에 나와 있는 작업 부하 시나리오 중 두 시나리오에서는 MAXDOP 옵션을 기본값인 0 대신 4로 설정했을 때 트랜잭션 처리량이 더 높아졌습니다. 이 경우 트랜잭션 처리량은 증가했지만 전체 CPU 사용량은 더 낮아졌습니다. 특정 쿼리에 대해 SQL Server 쿼리 프로세서는 병렬 실행 계획을 만들며 따라서 사용 가능한 모든 CPU에서 쿼리가 실행될 수도 있습니다. 사용 가능한 모든 CPU에 걸쳐 쿼리 하나를 병렬 실행하면 그 쿼리의 성능은 향상될 수 있지만, 더 많은 CPU 리소스가 필요할 수 있으므로 동일한 시스템에서 실행되는 다른 쿼리의 성능은 오히려 저하될 수도 있습니다. 따라서 CPU의 수가 많은 시스템에서는 MAXDOP 옵션에 대한 제한값을 설정하는 것이 전체 성능에 도움이 될 수 있습니다. MAXDOP 옵션을 설정하거나 설정하지 않은 경우를 모두 테스트하여 어떠한 단일 쿼리 또는 쿼리 집합도 시스템 리소스의 양을 불균형적으로 사용하지 않도록 하는 것이 좋습니다. 유형이 다른 작업 부하 성능 결과일반적으로 DSS 및 OLTP 같이 서로 다른 유형의 작업 부하는 별도의 서버에 분리하는 것이 좋습니다. 그러나 모든 통합 시나리오에서 이러한 구성을 실현할 수 있는 것은 아닙니다. DSS 작업 부하가 다른 동시 OLTP 작업 부하에 어떠한 영향을 미치는지 확인하기 위해 Microsoft는 I/O에 집중된 DSS 작업 부하가 포함된 테스트 시나리오에서 하나의 통합 작업 부하를 사용했습니다. DSS 작업 부하는 여러 개의 복잡한 조인이 포함되어 있고 tempdb 데이터베이스를 많이 사용하는 복잡한 선택 쿼리 집합으로 구성되어 있습니다. 통합 작업 부하는 그림 1.1과 그림 1.2에서 작업 부하 C로 나타나 있습니다. 그림 1.3과 그림 1.4는 테스트 시나리오에서 DSS 및 유지 관리 작업 부하에 대해 읽기 I/O 작업이 증가했음을 보여 줍니다.  그림 1.3 초당 디스크 읽기 큰 이미지 보기  그림 1.4 초당 디스크 쓰기 큰 이미지 보기 위의 그림에서 볼 수 있듯이 DSS 및 유지 관리 쿼리가 포함된 작업 부하는 주로 OLTP 쿼리로 구성된 작업 부하보다 더 많은 디스크 읽기 작업을 수행했습니다. DSS 같이 I/O에 집중된 작업 부하가 전체 시스템 성능에 미치는 영향은 디스크 하위 시스템의 성능에 크게 좌우됩니다. 테스트 시나리오에서 DSS 작업 부하는 OLTP 작업 부하의 성능에 최소한의 영향만 미치면서 동시에 실행했습니다. 이 성능은 I/O 하위 시스템을 특별히 튜닝하지 않고도 얻을 수 있었습니다. 테스트 시나리오에는 많은 수의 데이터베이스와 데이터베이스 관련 파일이 있으므로 데이터, 로그 및 tempdb 파일을 실제로 구분하지 않은 채 저장소를 구성했습니다. 마찬가지로, 저장소를 구성할 때 DSS 작업 부하가 있는 SQL Server의 인스턴스와 OLTP 작업 부하가 있는 인스턴스를 실제로 구분하지 않았습니다. 대신 저장소는 가능한 한 많은 수의 실제 디스크에 SAN을 통해 노출된 각 LUN에 걸쳐 구성되었습니다. SQL Server의 경우에는 항상 디스크 수준에서 데이터를 로그 파일과 실제로 구분하는 것이 좋습니다. 그러나 통합 환경에서 항상 이를 실현할 수 있는 것은 아니며, 특히 SAN(저장소 영역 네트워크)이 사용되는 환경에서는 데이터와 로그 파일을 실제로 구분하기가 더욱 어렵습니다. 대부분의 경우 이 문서에 나와 있는 테스트 시나리오에서와 마찬가지로 저장소가 다른 시스템에 실제로 공유될 수도 있습니다. 단일 시스템에서 유형이 다른 작업 부하를 통합할 때의 성공 여부는 작업 부하 특성과 I/O 하위 시스템의 성능에 크게 좌우됩니다. I/O 특성이 크게 다른 작업 부하를 통합하려는 경우에는 테스트를 주의 깊게 수행하여 전체 시스템의 I/O 성능에 미치는 영향을 확인해야 합니다. SQL Server의 다중 인스턴스 사용 이 문서에서 설명하는 테스트 시나리오의 경우 크게 다음과 같은 두 가지 이유 때문에 SQL Server의 다중 인스턴스를 사용했습니다.
서로 다른 서버의 각 데이터베이스 그룹은 SQL Server의 고유한 인스턴스에 배치되었으므로 테스트 시나리오의 전반적인 구축과 구성을 단순화할 수 있었습니다. 개별 서버의 데이터베이스 백업은 통합 서버에서 복원되었습니다. 서로 다른 서버의 데이터베이스를 동일한 SQL Server 인스턴스에 통합하는 경우 로그온 충돌 같은 문제를 비롯하여 정렬 순서 설정이나 기타 서버별 설정 문제도 고려해야 합니다. SQL Server의 개별 인스턴스에 매핑하면 이 과정을 단순화할 수 있습니다. 또한, SQL Server의 다중 인스턴스를 사용하면 작업 부하를 구분하고 각 인스턴스에 고유한 tempdb 데이터베이스를 부여할 수 있습니다. 이러한 구축 문제를 계획하고 처리하는 방법에 대한 자세한 내용은 부록 B의 "Microsoft SQL Server 2000을 사용한 통합 계획"(영문)을 참조하십시오. 4GB 이상의 실제 메모리를 사용하여 구성된 32비트 플랫폼에서는 대용량의 실제 메모리를 완전히 활용하기 위하여 AWE(Address Windowing Extensions)를 사용하거나 SQL Server의 다중 인스턴스를 사용할 수 있습니다. 일부 시나리오에서는 AWE가 제대로 작동할 수 있지만, AWE 메모리는 데이터 캐시에만 사용할 수 있다는 사실을 기억해야 합니다. 프로시저 캐시, 연결, 잠금 및 SQL Server의 기타 내부 리소스에 사용되는 메모리는 가상 메모리의 2GB(사용되는 설정에 따라서는 3GB) 부분에 포함되어 있어야 합니다. 많은 수의 데이터베이스와 사용자 연결을 지원해야 하는 시스템에서는 이러한 데이터 구조에 대한 32비트 플랫폼의 2GB 또는 3GB 메모리 제약 조건을 최대한 줄일 수 있도록 SQL Server의 다중 인스턴스를 사용하는 것이 더 좋습니다. 데스크톱 힙 고려 사항서로 다른 사용자 계정으로 여러 서비스가 실행되고 있는 환경에서는 이로 인해 데스크톱 힙 리소스가 고갈될 수 있으므로 서비스를 성공적으로 시작할 수 있도록 몇 가지 사항을 튜닝해야 할 수도 있습니다. 특정 사용자 계정으로 실행되는 각 서비스는 고유한 윈도우 스테이션에서 실행됩니다. 각 윈도우 스테이션에는 임의의 수의 데스크톱이 포함될 수 있고 각 데스크톱 개체에는 이와 관련된 데스크톱 힙이 있습니다. 윈도우 스테이션에 사용할 수 있는 데스크톱 힙의 양은 한정되어 있으며, 사용 가능한 데스크톱 힙이 고갈되면 서비스를 시작할 때 문제가 발생할 수 있습니다. 레지스트리를 사용하여 각 윈도우 스테이션에 할당된 데스크톱 힙의 양을 구성할 수 있으며, 모든 서비스가 문제 없이 시작할 수 있도록 하려면 각각의 비대화형 데스크톱에 할당된 힙의 양을 줄여야 할 수도 있습니다. 이러한 설정이 필요한지 여부는 실행 중인 서비스의 수와 개별 사용자 계정의 수에 따라 달라집니다. 윈도우 스테이션, 데스크톱, 발생할 수 있는 오류의 유형 및 각각의 비대화형 윈도우 스테이션에 할당된 데스크톱 힙의 양을 제어하는 방법에 대한 자세한 내용은 부록 B를 참조하십시오. 클러스터된 환경에 대한 AWE 고려 사항 테스트 시나리오에서 통합 환경의 작업 부하 성능을 측정한 다음 Microsoft는 AWE를 사용한 SQL Server의 인스턴스를 테스트하여 장애 조치 과정에서의 동작 방식을 확인했습니다. AWE 메모리 및 시작 성능AWE 메모리를 사용하도록 구성된 인스턴스를 SQL Server가 시작할 때는 프로세스 시작 시 메모리 페이지를 할당하고 커밋해야 합니다. 보안상의 이유로 SQL Server에 사용되는 메모리 페이지는 SQL Server프로세스에 사용되기 전에 0으로 초기화해야 합니다. SQL Server를 시작하는 데 걸리는 시간은 프로세스를 시작할 때의 할당 요청을 충족할만큼 충분한 메모리 페이지가 Windows에서 0으로 초기화되었는지 여부에 따라 달라집니다. 사용할 수 있는 페이지가 충분하지 않으면 프로세스를 시작하는 동안 메모리 페이지를 0으로 초기화해야 합니다. SQL Server 프로세스를 종료할 때 메모리 페이지는 Windows에 다시 릴리스되고 사용 가능한 메모리 목록에 배치되므로 Windows에는 메모리 페이지를 영구 삭제하는 0 페이지 스레드(우선 순위 0)가 생성됩니다. Windows Server 2003에서는 부록 B에 언급된 핫픽스를 비롯하여 서비스 팩 3 이상이 설치된 Windows 2000의 경우와 마찬가지로 페이지가 모든 CPU 간에 병렬로 0으로 초기화됩니다. 이전 버전의 Windows에서는 메모리 페이지가 단일 스레드에서 0으로 초기화되었으며 그 결과 대용량 메모리 시스템에서 실행되는 AWE를 사용한 SQL Server 인스턴스의 시작 시간이 느려질 수 있었습니다. 테스트 시나리오의 경우 AWE를 사용한 SQL Server 인스턴스는 31.5GB의 RAM을 사용하도록 구성되었으며 이 인스턴스에 대한 시작 시간은 메모리 페이지를 0으로 초기화해야 하는지 여부에 따라 30초 미만에서 약 4분까지 걸리기도 했습니다. AWE를 사용하는 SQL Server 인스턴스의 시작 시간이 오래 걸리는 경우에는 클러스터 서비스와 관련된 몇 가지 설정을 변경해야 할 수도 있습니다. 클러스터 서비스에는 SQL Server 리소스에 대한 보류 제한 시간 속성이 있습니다. 설정된 제한 시간 안에 SQL Server가 시작되지 않으면 클러스터 서비스는 서비스 제어 관리자에 중지 요청을 보낸 다음 서비스를 다시 시작합니다. SQL Server에 AWE가 사용되는 대용량 메모리 시스템의 경우 제한 시간을 기본값인 30초보다 더 높은 값으로 조정해야 할 수도 있습니다. AWE를 사용한 SQL 인스턴스 및 장애 조치각 노드에 4GB 이상의 실제 메모리가 장착된 서버에 대한 활성/활성 클러스터 시나리오의 경우 AWE 메모리를 사용하여 SQL Server의 인스턴스를 구성할 수 있습니다. SQL Server를 사용하면 다중 노드에서 실행되는 모든 인스턴스에 사용되는 누적 메모리가 단일 노드에 사용할 수 있는 실제 메모리보다 크도록 메모리를 구성할 수 있습니다. AWE 메모리는 정적으로 할당되고 프로세스가 종료될 때까지 릴리스되지 않으므로 임의의 인스턴스에 사용되는 메모리 양을 제한할 수 있도록 SP_CONFIGURE 최대 서버 메모리 옵션을 설정하여 장애 조치 시 임의의 인스턴스에 사용할 수 있는 실제 메모리가 항상 충분하게 유지되도록 해야 합니다. 일반적으로 노드 간에 사용되는 누적 리소스가 단일 노드에 사용할 수 있는 리소스보다 크지 않도록 활성/활성 클러스터를 구성하는 것이 좋습니다. 이렇게 하면 장애 조치가 발생할 때 항상 적절한 시스템 리소스가 마련되도록 할 수 있습니다. 이러한 방식을 사용할 때의 단점은 모든 메모리가 항상 활용되지는 않는다는 점입니다. 장애 조치 상황에서 AWE를 사용한 SQL Server 인스턴스의 동작은 시작 시 AWE를 사용한 SQL Server 인스턴스의 동작과 동일합니다. 이 동작은 다음과 같습니다.
테스트 시나리오의 구성 결과를 살펴보면 AWE를 사용하는 경우 SQL Server는 항상 Windows에 대해 128MB에서 300MB 사이의 실제 메모리를 조금 더 남겨두려 한다는 사실을 알 수 있습니다. 실제로 성능 테스트에서 SQL Server는 항상 AWE 설정과 상관 없이 Windows에 대해 이 정도 크기의 메모리를 남겨두려 했습니다. 표 1.2에는 서로 다른 AWE 장애 조치 시나리오에 대한 장애 조치 전후의 메모리 사용 예가 나와 있습니다. 각 시나리오에서 AWE를 사용한 인스턴스는 AWE 사용 옵션을 1로 설정하고 최소 서버 메모리를 최대 서버 메모리와 동일하게 설정하여 구성했습니다. 표 1.2 AWE 메모리 사용 시나리오
AWE를 사용하지 않는 컴퓨터에서 실행되는 인스턴스가 있는 경우 AWE를 사용한 인스턴스를 온라인으로 전달해도 비-AWE 인스턴스에 사용되는 메모리가 줄어들지는 않습니다. AWE를 사용하지 않는 인스턴스에는 기존의 메모리가 모두 유지됩니다. 이러한 작동 방식은 AWE를 사용하지 않는 인스턴스가 작업 중인지 유휴 상태인지 여부와 상관 없이 적용됩니다. 이 결과는 SQL Server를 시작할 때 할당할 AWE 메모리의 양이 사용 가능한 실제 메모리의 양과 최대 서버 메모리 설정을 바탕으로 결정되기 때문입니다. SQL Server는 항상 운영 체제에 충분한 크기의 메모리를 남겨두려고 하지만 시스템에서 사용할 수 있는 실제 메모리가 매우 적고 추가 인스턴스가 온라인으로 전달되는 경우에는 시스템에서 페이지 파일의 가상 메모리를 사용할 수도 있습니다. 이러한 페이지 파일의 가상 메모리 사용을 페이징이라고도 합니다. 그 결과 전반적인 시스템 성능에 부정적인 영향을 미칠 수 있습니다. 따라서 SQL Server의 다중 인스턴스에 대한 메모리를 구성할 때는 이러한 사항을 염두에 두고 작업을 수행해야 합니다. 결론 통합 환경에서 SQL Server의 성능은 사용 중인 하드웨어 및 관련된 SQL Server 작업 부하의 특성에 크게 좌우됩니다. 이 문서에 나와 있는 테스트 시나리오를 살펴보면 통합 환경에서 SQL Server가 작동하는 방식을 알 수 있습니다. 그러나 여기에서 제시하는 결과를 모든 구성에 반드시 적용해야 하는 것은 아닙니다. SQL Server의 개별 인스턴스를 한 서버에 통합하려면 먼저 현재 시스템에서의 리소스 사용 수준을 주의 깊게 확인해야 합니다. 여러 인스턴스를 단일 서버에 통합하기 위한 계획을 수립하는 방법에 대한 자세한 내용은 부록 B의 자료를 참조하십시오. 다음은 이 문서에서 설명하는 핵심 내용에 대한 요약입니다.
부록 A: 저장소 구성 및 성능 이 문서에 나와 있는 32비트 플랫폼 통합 테스트에는 EMC Symmetrix 5.5 모델 8530 저장소 배열이 사용되었습니다. 이 테스트를 위한 저장소의 구성 방식은 SQL Server의 인스턴스를 클러스터하는 데 필요한 요구 사항에 따라 결정되었습니다. SQL Server 클러스터의 저장소에 대한 요구 사항은 크게 다음과 같은 두 가지입니다.
파일의 총 수가 제한되어 있으므로 저장소 배열을 구성할 때 스핀들 수준에서 데이터, 로그 및 tempdb 파일을 실제로 구분하여 설정하는 것은 큰 의미가 없습니다. 또한 사용 가능한 드라이브 문자의 수가 제한되어 있고 클러스터에 이러한 파일을 사용해야 하므로 데이터, 로그 및 tempdb 파일을 동일한 LUN에 배치해야 합니다. 그 결과로 SQL Server의 특정 인스턴스에 대한 모든 파일에서 동일한 실제 디스크를 공유하게 되고 각 인스턴스에는 한 두 개의 LUN이 공유 디스크 리소스로 부여됩니다. 저장소 배열은 각 LUN이 가능한 한 많은 실제 디스크로 분산되도록 구성되었으며 성능을 최적화하기 위해 RAID(Redundant Array of Independent Disks) 1+0이 사용되었습니다. 모든 SQL Server 가상 인스턴스에서 tempdb 및 시스템 데이터베이스 파일을 포함하지 않은 데이터 및 로그 파일의 총 수는 약 191개였습니다. 표 B.1에는 각 LUN의 사용에 관련된 정보가 나와 있습니다. 표 B.1 LUN 구성
그림 B.1과 B.2는 이 저장소 구성을 사용하여 테스트를 진행하는 동안 얻은 I/O 성능에 대한 참조 자료로 제공되고 있습니다. 성능 테스트에서 하드웨어 리소스 사용을 제한하는 요소는 CPU였습니다. I/O 성능은 설계상 실제 구분 없이도 상당히 일정한 결과를 보였습니다.  그림 B.1 기본 설정 구성을 사용한 디스크 처리량 큰 이미지 보기 그림 B.2 기본 설정 구성을 사용한 평균 디스크 대기 시간 큰 이미지 보기그림 B.1에 나와 있는 작업 부하 A, B, C 및 D는 이 문서의 표 1.1 "데이터베이스 및 통합 작업 부하"에서 설명하고 있는 작업 부하입니다. 이러한 작업 부하에 대한 자세한 내용은 해당 단원의 표 1.1을 참조하십시오. 부록 B: 참고 자료 Microsoft SQL Server 2000을 사용한 통합 계획(영문) http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/SQL2KCon.mspx 클러스터링 및 SAN Microsoft Windows 클러스터링: SAN(저장소 영역 네트워크)(영문) http://www.microsoft.com/korea/windowsserver2003/techinfo/overview/san.asp Microsoft 기술 자료 304415 같은 SAN 장치에 연결된 여러 클러스터 지원 http://support.microsoft.com/?id=304415 Microsoft 기술 자료 280297 클러스터된 서버에서 볼륨 탑재 지점을 구성하는 방법 http://support.microsoft.com/?id=280297 Microsoft 기술 자료 819546 탑재된 볼륨에 대한 SQL Server 2000의 지원 http://support.microsoft.com/?id=819546 데스크톱 힙 고려 사항 Microsoft 기술 자료 184802 PRB: User32.dll 또는 Kernel32.dll 초기화 실패 http://support.microsoft.com/?id=184802 윈도우 스테이션(영문) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/window_stations.asp AWE 및 대용량 메모리 지원 Microsoft 기술 자료 816488 페이지 비우기 프로세스 속도가 갑자기 느려지는 경우 http://support.microsoft.com/?id=816488 Microsoft 기술 자료 329914 AWE를 사용하는 SQL Server 2000은 시작하는 데 시간이 오래 걸릴 수 있다 http://support.microsoft.com/?id=329914 Microsoft 기술 자료 283037 Windows 2000 및 Windows Server 2003에서 대형 메모리 지원 기능을 사용할 수 있다 http://support.microsoft.com/?id=283037 Microsoft 기술 자료 274750 HOWTO: SQL Server에서 2 GB 이상의 메모리 구성 http://support.microsoft.com/?id=274750 부록 C: 하드웨어 구성 이 문서에 나와 있는 테스트 시나리오는 다음과 같은 환경을 사용하여 수행했습니다. 서버 Unisys ES7000
저장소 EMC Symmetrix 5.5(모델 8530) - 16GB 캐시, 96개의 10K RPM 73GB 드라이브 및 12개의 파이버 호스트 연결. RAID 1+0을 사용하여 구성. 패브릭 스위치 EMC 브랜드 McData 디렉터 클래스, 1Gbs, 64포트 파이버 스위치 운영 체제 Microsoft Windows Server 2003, Datacenter Edition 데이터베이스 서버 Microsoft SQL Server 2000, Enterprise Edition, Build 2000.80.194.0, 서비스 팩 3 최종수정일 : 2004년 10월 15일 | |||||||||||||||||||||||||||||||||||||||||
개요