Analysis Services 배포에 대한 요구 사항 및 고려 사항
MicrosoftSQL ServerAnalysis Services 프로젝트를 배포하기 전에 Analysis Services의 안정성과 성능을 향상시키기 위해 고려해야 할 중요한 문제가 있습니다. 예를 들어 서버의 기존 인스턴스에 다른 Analysis Services 인스턴스를 추가하거나 프로젝트에서 복잡한 큐브를 처리하는 경우 하드웨어 리소스를 늘려야 할 수 있습니다. 하드웨어나 소프트웨어 장애가 발생한 경우와 특정 처리 태스크 동안에 프로젝트 가용성을 확보하기 위한 조치도 취해야 합니다. 마지막으로 성능 요구에 따라 여러 컴퓨터에 SQL Server 또는 Analysis Services 인스턴스를 확장해야 할 수 있습니다.
요구 사항 및 고려 사항
배치 요구 사항과 고려 사항은 다음 섹션에서 다룹니다.
리소스 요구 사항
가용성 고려 사항
확장성 고려 사항
리소스 요구 사항
Analysis Services 프로젝트를 배포하기 전에 Analysis Services의 리소스 요구 사항을 고려해야 합니다. 특히 메모리 및 프로세서 요구 사항과 디스크 공간 요구 사항을 고려합니다.
메모리 및 프로세서 요구 사항
다음과 같은 경우에는 Analysis Services에 더 많은 메모리와 프로세서 리소스가 필요합니다.
크거나 복잡한 큐브를 처리할 경우. 이러한 큐브에는 작거나 간단한 큐브보다 더 많은 메모리와 프로세서 리소스가 필요합니다.
단일 데이터베이스 내의 큐브 수가 증가할 경우
단일 Analysis Services 인스턴스 내의 데이터베이스 수가 늘어날 경우
단일 컴퓨터의 Analysis Services 인스턴스 수가 증가할 경우
동시에 Analysis Services 리소스에 액세스하는 사용자 수가 늘어날 경우
Analysis Services에서 사용할 수 있는 메모리와 프로세서 리소스의 양은 서버 컴퓨터에 설치된 Microsoft Windows 버전에 따라 다릅니다. 다음 표에서는 설치된 Windows 버전에 따라 Analysis Services에서 처리할 수 있는 메모리와 프로세서 리소스를 나열합니다.
Windows 버전 |
Analysis Services에서 사용할 수 있는 최대 메모리 양 |
Analysis Services에서 사용할 수 있는 최대 프로세서 수 |
|---|---|---|
Windows Server 2003, Enterprise, 64비트 버전 |
64GB |
8 |
Windows Server 2003, Datacenter, 64비트 버전 |
512GB |
32 |
Windows Server 2003, Standard |
3GB(/3GB 스위치 사용) |
4 |
Windows Server 2003, Enterprise |
3GB(/3GB 스위치 사용) |
8 |
Windows Server 2003, Datacenter |
3GB(/3GB 스위치 사용) |
32 |
Windows 2000 Server |
2GB |
4 |
Windows 2000 Advanced Server |
3GB(/3GB 스위치 사용) |
8 |
Windows 2000 Datacenter Server |
3GB(/3GB 스위치 사용) |
32 |
.gif "중요 정보") 중요 |
|---|
Analysis Services는 컴퓨터에 설치된 실제 메모리와 관계없이 Windows 32비트 버전에서 최대 3GB의 메모리를 처리할 수 있습니다. /3GB 스위치에 대한 자세한 내용은 Microsoft KB(기술 자료) 문서 283037을 참조하십시오. |
디스크 공간 요구 사항
Analysis Services 구성 요소와 개체 처리 관련 태스크에 따라 필요한 디스크 공간이 다릅니다. 다음 목록에서는 이러한 요구 사항을 설명합니다.
큐브
큰 팩트 테이블이 있는 큐브에는 작은 팩트 테이블이 있는 큐브보다 더 많은 디스크 공간이 필요합니다. 마찬가지로 팩트 테이블에 비해 정도는 적지만 큰 차원이 많이 있는 큐브에는 보다 작은 차원 멤버가 있는 큐브보다 더 많은 디스크 공간이 필요합니다. 일반적으로 Analysis Services 데이터베이스에는 기본 관계형 데이터베이스에 동일 데이터를 저장하는 데 필요한 공간의 약 20%가 필요합니다.집계
집계에는 추가된 집계에 비례하여 추가 공간이 필요합니다. 즉, 집계가 많을수록 공간도 더 필요합니다. 필요 없는 집계를 만들지 않으려면 집계에 필요한 추가 디스크 공간이 대체로 기본 관계형 데이터베이스에 저장되는 데이터 크기의 약 10% 이하여야 합니다.데이터 마이닝
기본적으로 마이닝 구조는 학습에 사용된 데이터 집합을 디스크에 캐시합니다. 마이닝 구조 개체에서 구조 지우기 처리 처리 옵션을 사용하여 디스크에서 이 캐시된 데이터를 제거할 수 있습니다. 자세한 내용은 데이터 마이닝 개체 처리를 참조하십시오.개체 처리
처리 과정에서 Analysis Services는 처리가 완료될 때까지 처리 트랜잭션에서 처리 중인 개체의 복사본을 디스크에 저장합니다. 처리가 완료되면 원래 개체가 개체의 처리된 복사본으로 바뀝니다. 따라서 각 개체의 복사본을 처리하기 위해서는 충분한 추가 디스크 공간이 있어야 합니다. 예를 들어 단일 트랜잭션에서 전체 큐브를 처리하려면 전체 큐브의 복사본을 저장하기에 충분한 하드 디스크 공간이 있어야 합니다.
맨 위로 이동
가용성 고려 사항
Analysis Services 환경에서 하드웨어나 소프트웨어 장애 때문에 큐브나 마이닝 모델을 쿼리에 사용할 수 없는 경우가 있습니다. 큐브를 처리해야 하기 때문에 사용할 수 없는 경우도 있습니다.
하드웨어나 소프트웨어 장애 발생 시 가용성 제공
다양한 이유로 하드웨어나 소프트웨어 장애가 발생할 수 있습니다. 그러나 Analysis Services의 가용성을 유지하는 작업은 장애 원인을 찾아내서 문제를 해결하는 작업인 동시에 오류 발생 시 사용자가 시스템을 계속 사용할 수 있도록 대체 리소스를 제공하는 작업이기도 합니다. 하드웨어나 소프트웨어 장애 발생 시 대개 서버 클러스터링과 로드 균형 조정을 사용하여 가용성을 유지하는 데 필요한 대체 리소스를 제공합니다.
하드웨어나 소프트웨어 장애 발생 시 가용성을 제공하려면 장애 조치 클러스터에 Analysis Services를 배포해 봅니다. 장애 조치 클러스터에서 어떤 이유로든 주 노드에 장애가 발생하거나 주 노드를 다시 부팅해야 할 경우 Microsoft Windows 클러스터링이 보조 노드로 장애 조치합니다. 장애 조치는 매우 빠르게 수행되며 이후부터 쿼리를 실행하는 사용자는 보조 노드에서 실행되고 있는 Analysis Services 인스턴스에 액세스하게 됩니다.
가용성 문제를 해결하는 또 다른 방법은 둘 이상의 프로덕션 서버에 Analysis Services 프로젝트를 배포하는 것입니다. 그런 다음 Windows 서버의 네트워크 로드 균형 조정(NLB) 기능을 사용하여 이러한 프로덕션 서버를 단일 클러스터로 결합할 수 있습니다. NLB 클러스터에서 하드웨어나 소프트웨어 문제로 인해 클러스터의 서버를 사용할 수 없으면 NLB 서비스가 사용 가능한 서버로 사용자 쿼리를 보냅니다. Windows 클러스터링 및 NLB에 대한 자세한 내용은 Microsoft Windows Server 2003 웹 사이트의 기술 센터에 있는 클러스터링 서비스를 참조하십시오.
구조 변경 처리 시 가용성 제공
큐브의 특정 변경 내용으로 인해 큐브가 처리될 때까지 해당 큐브를 사용할 수 없는 경우가 있습니다. 예를 들어 큐브에 있는 차원의 구조를 변경하면 차원을 다시 처리해야 할 뿐 아니라 수정된 차원을 사용하는 각 큐브도 처리해야 합니다. 이러한 큐브를 처리할 때까지 사용자는 해당 큐브를 쿼리하거나 수정된 차원이 있는 큐브를 기반으로 하는 마이닝 모델을 쿼리할 수 없습니다.
Analysis Services 프로젝트에서 하나 이상의 큐브에 영향을 줄 수 있는 구조 변경 내용을 처리하는 동안 가용성을 제공하려면 준비 서버를 통합하고 데이터베이스 동기화 마법사를 사용해 봅니다. 이 기능을 사용하면 준비 서버에서 데이터와 메타데이터를 업데이트한 다음 프로덕션 서버와 준비 서버(staging server)의 온라인 동기화를 수행할 수 있습니다. 자세한 내용은 Analysis Services 데이터베이스 동기화를 참조하십시오.
원본 데이터에 대한 증분 업데이트를 투명하게 처리하려면 자동 관리 캐싱을 사용합니다. 자동 관리 캐싱은 수동 처리 없이 큐브 가용성에 영향을 주지 않고 새 원본 데이터로 큐브를 업데이트합니다. 자세한 내용은 자동 관리 캐싱(파티션)을 참조하십시오.
맨 위로 이동
확장성 고려 사항
한 컴퓨터에 MicrosoftSQL Server 및 Analysis Services 인스턴스가 여러 개 있으면 성능 문제가 발생할 수 있습니다. 이러한 문제를 해결하는 방법 중 하나는 서버의 프로세서, 메모리 및 디스크 리소스를 늘리는 것입니다. 그러나 여러 컴퓨터에 SQL Server 및 Analysis Services 인스턴스를 확장해야 할 수도 있습니다.
여러 컴퓨터에 Analysis Services 확장
여러 컴퓨터에 Analysis Services를 확장하는 방법은 다양합니다. 다음 목록에서는 이러한 방법에 대해 설명합니다.
한 컴퓨터에 Analysis Services 인스턴스가 여러 개 있으면 하나 이상의 인스턴스를 다른 컴퓨터로 이동할 수 있습니다.
한 컴퓨터에 Analysis Services 데이터베이스가 여러 개 있으면 하나 이상의 데이터베이스를 다른 컴퓨터에 있는 자체 Analysis Services 인스턴스로 이동할 수 있습니다.
Analysis Services 데이터베이스에 데이터를 제공하는 관계형 데이터베이스가 여러 개 있으면 이러한 데이터베이스를 다른 컴퓨터로 이동할 수 있습니다. 데이터베이스를 이동하기 전에 Analysis Services 데이터베이스와 해당 기본 데이터베이스 간의 네트워크 속도와 대역폭을 고려합니다. 네트워크가 느리거나 혼잡한 경우 기본 데이터베이스를 다른 컴퓨터로 이동하면 처리 성능이 영향을 받게 됩니다.
처리가 쿼리 성능에 영향을 주지만 쿼리 로드가 적을 때 처리할 수 없으면 처리 태스크를 준비 서버(staging server)로 이동한 다음 프로덕션 서버와 준비 서버(staging server)의 온라인 동기화를 수행해 봅니다. 자세한 내용은 Analysis Services 데이터베이스 동기화를 참조하십시오. 원격 파티션을 사용하여 여러 Analysis Services 인스턴스에 처리를 분산할 수도 있습니다. 원격 파티션 처리에는 로컬 컴퓨터의 리소스 대신 원격 서버의 프로세서와 메모리 리소스가 사용됩니다. 원격 파티션 관리에 대한 자세한 내용은 Analysis Services 파티션 관리를 참조하십시오.
쿼리 성능이 나쁘지만 로컬 서버의 프로세서와 메모리 리소스를 늘릴 수 없으면 Analysis Services 프로젝트를 둘 이상의 프로덕션 서버에 배포해 봅니다. 그런 다음 NLB를 사용하여 서버를 단일 클러스터로 결합할 수 있습니다. NLB 클러스터에서 쿼리는 NLB 클러스터에 속한 모든 서버에 자동으로 분산됩니다. 자세한 내용은 Microsoft Windows Server 2003 웹 사이트의 기술 센터에 있는 Clustering Services를 참조하십시오.
맨 위로 이동