자원 예약 만들기 정보(CPU 공유) (Solaris Container Manager 1.1 설치 및 관리)

Solaris Container Manager 1.1 설치 및 관리

자원 예약 만들기 정보(CPU 공유)

응용프로그램의 자원을 관리하는 데 프로젝트를 사용하기 전에 응용프로그램에 대한 자원 경향을 먼저 알아야 합니다. ORACLE®과 같은 특정 응용프로그램의 성능은 메모리 캡의 양이 부적절한 경우 현저히 저하됩니다. 모든 프로젝트에는 자원 예약 세트가 있어야 합니다. 최소 CPU 공유 및 선택적으로 최대 메모리 예약(메모리 캡). 응용프로그램에 대한 자원 요구 사항을 설정한 후 이러한 예약을 관리하기 위해서만 프로젝트를 사용하기 시작해야 합니다.

주의 –

응용프로그램이 일반적으로 사용하는 것보다 더 작은 프로젝트에 대해 물리적 메모리 캡을 설정하지 마십시오. 이 연습은 응용프로그램이 더 많은 가상 메모리를 사용하는 데 필요한 경우 더 높은 페이지 지정 및 스와핑으로 인해 응용프로그램의 성능에 부정적인 영향을 미쳐 상당한 지연이 발생할 수도 있습니다.

프로젝트를 사용하여 시스템 자원을 관리하기 전에 서버 통합 계획을 마쳐야 합니다. 관련된 주요 작업은 통합 계획에 포함하는 응용프로그램의 자원 소비 경향을 확인하는 것입니다. 이상적으로프로덕션 환경에서 계획을 구현하기 전에 테스트 환경에서 최소한 한 달 동안 응용프로그램의 자원 이용율 경향을 식별합니다. CPU 및 메모리 소비 경향을 설정한 후 일반적인 메모리 요구 사항을 넘어 최소한 약간의 백분율 포인트를 허용해야 합니다.

프로젝트에 필요한 CPU 공유의 양에 대한 예약을 할 때 CPU의 양을 정수로 할당합니다. 예를 들어, 25, 1, 37은 모두 유효한 양입니다. 용어 공유는 프로젝트에 할당된 시스템의 CPU 자원의 부분을 정의하는 데 사용됩니다. 다른 프로젝트에 비례하여 많은 수의 CPU 공유 수를 프로젝트에 할당하는 경우, 프로젝트는 페어 쉐어 스케줄러에서 더 많은 CPU 자원을 받습니다.

CPU 공유는 CPU 자원의 백분율과 같지 않습니다. 공유는 다른 작업 부하에 관하여 상대적인 작업 부하의 중요성을 정의하는 데 사용됩니다. 예를 들어, sales 프로젝트는 marketing 프로젝트의 두 배가 중요한 경우, sales 프로젝트는 marketing 프로젝트의 두 배가 되는 공유가 할당되어야 합니다. 할당하는 공유의 수는 부적절합니다. sales 프로젝트의 2개의 공유 대 marketing 프로젝트의 1개의 공유는 sales 프로젝트의 18개의 공유 대 marketing 프로젝트의 9개의 공유와 동일합니다. 두 경우 모두, slaes 프로젝트는 marketing 프로젝트의 두 배의 CPU를 가질 자격이 있습니다.

CPU 공유는 두 개의 범주로 더 분리될 수 있습니다.

CPU 공유
(Solaris 10 전용) 프로젝트 CPU 공유 (특정 영역에서)

풀 또는 프로젝트 작성 중 할당된 CPU 공유

Solaris 8 OS를 실행중인 호스트에서 하나의 자원 풀인 pool_default만 사용 가능합니다. pool_default에는 100 개의 CPU 공유 값이 있습니다.

Solaris 9 및 Solaris 10 OS를 실행중인 호스트에서 새 자원 풀을 작성할 때 풀에 대해 CPU 공유 값을 설정합니다. Solaris Container Manager는 기본값을 제공하지만 어떤 정수든 입력할 수 있습니다. 일부 시스템 관리자는 자원 풀에 사용 가능한 CPU 당 100 개의 CPU 공유의 공식을 사용합니다. 예를 들어, 1 CPU를 가진 풀에 100 CPU 공유를 할당할 수도 있습니다.

이 풀에 대해 다음 세 개의 프로젝트가 있다고 가정합니다. 프로젝트 X, 프로젝트 Y 및 프로젝트 Z. 가장 중요한 프로젝트인 프로젝트 X, 50 CPU 공유 및 다음 프로젝트인 프로젝트 Y, 10 공유 및 다음 프로젝트인 프로젝트 Z, 40 공유를 할당합니다.

그림 3–8 프로젝트 CPU 공유

새 프로젝트 마법사를 사용하여 프로젝트를 작성할 때 프로젝트에 CPU 공유를 할당합니다. 새 프로젝트 마법사는 풀에 대해 예약되지 않은 CPU 공유를 표시하여 사용 가능한 해당 CPU 공유를 결정하고 프로젝트에 적절한 양을 할당할 수 있습니다.

그림 3–9 CPU 공유

(Solaris 10 전용) 영역 작성 중 할당된 CPU 공유

호스트가 Solaris 10 운영 체제에서 실행되는 경우, 영역을 작성하고 전체로서 영역에 대한 CPU 공유 및 영역의 프로젝트에 대한 프로젝트 CPU 공유를 할당할 수 있습니다. 이들은 관련된 칭호들입니다.

새 영역 마법사를 사용하여 영역 작성 중 CPU 공유 및 프로젝트 CPU 공유를 할당합니다. 새 영역 마법사의 4 단계에서 자원 풀을 선택합니다. 마법사는 풀에 대한 전체 CPU 공유 및 풀에 대한 전체 사용 가능한 CPU 공유를 표시합니다.

자원 풀에서 이 영역을 할당하려는 CPU 공유에 대한 값을 입력합니다. 이 정수는 풀에 대한 전체 사용 가능한 CPU 공유와 동일하거나 더 적어야 합니다.

그림 3–10 영역 공유

풀에 전체 사용 가능한 CPU 공유 100이 있는 경우, 이 영역에 모두 또는 100개의 공유 중 일부를 할당할 수 있습니다. 이 예에서, 자원 풀로부터 영역에 20 CPU 공유를 할당한다고 가정합니다.

영역 작성 중 할당된 프로젝트 CPU 공유

새 영역 마법사의 4단계에서 프로젝트 CPU 공유도 입력할 수 있습니다. 이 필드는 영역의 프로젝트에 할당되는 CPU 공유의 수를 지정합니다. 이 값을 작성할 경우, 영역에 대해 프로젝트 CPU 공유의 값을 설정합니다. 모든 정수를 입력할 수 있습니다. 입력한 정수는 얻으려는 세분도를 결정합니다.

예를 들어, 영역 A에 대한 프로젝트 CPU를 1000으로 할당한다고 가정합니다. 물리적 레벨에서, 1000 프로젝트 CPU 공유는 자원 풀에서 상속되어 1000 공유로 분리된 20 CPU 공유입니다. 다음은 이 예에서 1 프로젝트 CPU 공유 및 CPU 공유 사이의 관계를 표시하는 공식입니다.

1 프로젝트 CPU 공유 = 20 (영역에 할당된 CPU 공유의 수)/1000 (프로젝트 CPU 공유의 수) = 0.02 CPU 공유

영역 A에서 프로젝트 1 프로젝트를 작성할 때 프로젝트 1은 자원 풀에서 바로가 아니라 영역에서 공유를 얻습니다. 프로젝트1에 영역 A의 300 공유가 할당된 경우, 300 프로젝트 CPU 공유 또는 300/1000 x 20/100 = 0.06 CPU 공유가 됩니다.

그림 3–11 영역 CPU 공유

새 프로젝트 마법사를 실행할 때 프로젝트에 프로젝트 CPU 공유를 할당합니다. 새 프로젝트 마법사의 7 단계, 프로젝트에 대한 자원 예약 제공에서 CPU 예약으로 레이블 지정된 필드에 프로젝트 CPU 공유를 입력합니다(CPU 공유). Solaris 10 호스트 전용의 영역에서만 프로젝트를 작성할 때 이것은 참입니다.

그림 3–12 프로젝트 CPU 공유

주 –

Solaris 8 또는 Solaris 9 호스트에서 프로젝트를 작성할 경우, 예약되지 않은 CPU 공유 필드는 CPU 공유 입력에 사용됩니다(프로젝트 CPU 공유가 아님).

주의 –

명령줄(zonecfg 명령)을 사용하여 CPU 공유를 수동으로 변경하지 마십시오. 이것은 Solaris Container Manager 계산을 방해합니다.

전역 영역 및 해당 프로젝트

전역 영역은 하나의 자원 풀에만 바운드되지 않는 유일한 영역입니다. 임의의 풀에서 CPU 자원을 얻을 수 있습니다. 숨겨진 전역 영역이 호스트의 모든 자원 풀에 나타나기 때문에 전역 영역의 프로젝트는 모든 자원 풀에서 CPU 자원을 얻을 수 있습니다.

예를 들어, 자원 풀 Pool_default에는 4개의 CPU가 있고 여기에서 zone_1 및 zone_2가 배포되어 있습니다. Pool_default에는 10개의 CPU 공유가 있습니다. Zone_1에는 5 개의 CPU 공유, zone_2에는 4 개의 CPU 공유 및 전역 영역에는 1 개의 CPU 공유가 있습니다.

또 다른 자원 풀, Pool_1에는 2 개의 CPU 및 10개의 CPU 공유가 있습니다. Pool_1에는 하나의 영역 zone_3만 배포되었습니다. Zone_3에는 9 개의 CPU 공유가 있습니다. 전역 영역에는 1 개의 CPU 공유가 있습니다.

전역 영역의 프로젝트는 배포된 풀의 1개의 CPU 공유에서 CPU 자원을 얻습니다.

Solaris Container Manager에서 전역 영역의 프로젝트는 pool_default로 배포되어야 합니다.

FSS(Fair Share Scheduler)

컨테이너 관리자는 FSS(fair share scheduler)를 사용하여 설정한 최소 CPU 공유를 확인합니다. FSS는 기본 스케줄러입니다. FSS는 활성 프로젝트의 공유의 전체 수로 프로젝트에 대한 공유를 나누어 프로젝트에 할당된 CPU의 비율을 계산합니다. 활성 프로젝트는 CPU를 사용하는 최소한 하나의 프로세스를 가진 프로젝트입니다. 유휴 프로젝트, 즉 활성 프로세스가 없는 프로젝트에 대한 공유는 계산에 사용되지 않습니다.

예를 들어, 세 개의 프로젝트, sales, marketing 및 database에는 각각 두 개, 하나 및 네 개의 공유가 할당되어 있습니다. 모든 프로젝트가 활성 상태입니다. 자원 풀에 대한 CPU 자원은 다음과 같이 분배됩니다. sales 프로젝트는 CPU 자원의 2/7, marketing 프로젝트는 1/7 및 database 프로젝트는 4/7를 받습니다. sales 프로젝트가 유휴인 경우, marketing 프로젝트는 CPU 자원의 1/5 및 database 프로젝트는 4/5를 받습니다.

CPU에 대한 경쟁이 있는 경우 FSS는 CPU 사용만 제한합니다. 시스템에서 유일한 활성 프로젝트인 프로젝트는 포함한 공유의 수에 상관없이 CPU 100 퍼센트를 사용할 수 있습니다. CPU 주기는 허비되지 않습니다. 수행할 작업이 없기 때문에 프로젝트가 사용할 수 있는 모든 CPU를 사용하지 않는 경우, 남은 CPU 자원이 다른 활성 프로세스 사이에서 분배됩니다. 프로젝트에 CPU 공유가 정의되지 않은 경우, 하나의 공유가 할당됩니다. 영(0) 개의 공유를 가진 프로젝트의 프로세스는 최저 시스템 우선 순위에서 실행됩니다. 0이 아닌 공유를 가진 프로젝트가 CPU 자원을 사용하지 않는 경우에만 이러한 프로세스가 실행됩니다.

시분할 스케줄러(TS)

시분할 스케줄러는 우선 순위를 기초로 CPU 시간을 할당하여 사용 가능한 CPU에 비교적 동일한 액세스를 제공합니다. TS는 관리될 필요가 없기 때문에 사용하기 쉽습니다. 그러나 TS는 특정 응용프로그램에 대해 성능을 보장할 수 없습니다. CPU 할당이 필요하지 않은 경우, TS를 사용해야 합니다.

예를 들어, 두 개의 프로젝트가 FSS 자원 풀에 할당되고 각각에 두 개의 공유가 있는 경우, 해당 프로젝트에서 실행중인 프로세스의 수는 중요하지 않습니다. 프로젝트는 사용 가능한 CPU의 50 퍼센트에만 액세스할 수 있습니다. 따라서 하나의 프로세스가 sales 프로젝트를 실행 중이고 99개의 프로세스가 marketing 프로젝트에서 실행 중인 경우, sales 프로젝트의 하나의 프로세스는 CPU의 50 퍼센트에 액세스할 수 있습니다. marketing 프로젝트의 99 개의 프로세스는 사용 가능한 CPU 자원의 50 퍼센트를 공유해야 합니다.

TS 자원 풀에서 프로세스 당 CPU가 할당됩니다. sales 프로젝트의 한 프로세스에 CPU 1 퍼센트에 대해서만 액세스 권한이 있는 반면, marketing 프로젝트의 99 개의 프로세스는 사용 가능한 CPU 자원의 99 퍼센트에 대한 액세스 권한을 갖습니다.

FSS 및 TS에 대한 자세한 정보는 System Administration Guide: Network Services를 참조하십시오.

응용프로그램 자원 소비 경향에 컨테이너 관리자 사용

다음을 수행하여 응용프로그램 자원 소비 경향을 돕는 도구로 테스트 환경에서 컨테이너 관리자를 사용할 수 있습니다.

필요한 소프트웨어와 함께 컨테이너 관리자 소프트웨어 설치 및 설정.

자세한 정보는 2 장, 컨테이너 관리자 설치 및 설정을 참조하십시오.
모니터하려는 모든 에이전트 시스템에 Performance Reporting Manager 설치.

자세한 정보는 2 장, 컨테이너 관리자 설치 및 설정 및 Sun Management Center 3.5 Performance Reporting Manager 사용자 설명서를 참조하십시오.
원하는 응용프로그램에 대한 활성 응용프로그램 기반 컨테이너 작성. 새 작성 마법사에서 최소 CPU 예약만 만듭니다. 메모리 캡을 설정하지 마십시오.

자세한 정보는 응용 프로그램 기반 프로젝트 작성 및 응용 프로그램 기반 프로젝트 작성을 참조하십시오.
일별, 주별 또는 실시간 그래프를 사용하여 두 주에 대해 사용된 자원 모니터링. 두 개의 그래프(사용된 CPU 및 메모리 자원용 하나)는 개별 호스트에서 실행중인 컨테이너에 사용 가능합니다. 응용프로그램에서 실행중인 프로세스를 모니터하기 위해 프로세스 표를 볼 수도 있습니다.

자세한 정보는 활성 프로젝트에 대한 자원 이용률 보고서 요청 및 프로젝트 프로세스 보기를 참조하십시오.
응용프로그램에 대해 최대 물리적 메모리 요구 사항을 설정한 후 컨테이너의 등록 정보를 수정하여 메모리 캡에 포함시킵니다. 응용프로그램이 사용중인 최대 메모리보다 작은 캡을 설정하지 마십시오.

자세한 정보는 등록 정보 시트를 사용하여 프로젝트 수정을 참조하십시오.
사용된 메모리가 메모리 캡 설정을 초과하는지 알 수 있도록 경보 설정. 등록 정보 시트를 사용하여 메모리 캡을 조정합니다.

자세한 정보는 경보 임계값 설정 및 등록 정보 시트를 사용하여 프로젝트 수정을 참조하십시오.

컨테이너 관리자를 사용하여 자원 이용율 경향을 설정한 후 컨테이너를 사용하여 프로덕션 환경에서 서버를 통합할 수 있습니다.

서버 통합 계획 및 실행 방법에 대한 자세한 정보는 David Hornby 및 Ken Pepple의 Sun Blueprints 문서 Consolidation in the Data Center를 참조하십시오. ORACLE 데이터베이스를 실행하는 시스템의 서버 통합에 대한 자세한 정보는 Sun 백서 Consolidating Oracle RDBMS Instances Using Solaris Resource Manager Software를 참조하십시오.