Solaris Container Manager 3.6.1 설치 및 관리

컨테이너 작성 정보

모든 프로젝트는 컨테이너를 사용하여 시작합니다. 프로젝트는 작성하는 동안 선택하는 프로젝트 유형에 따라 세 가지 유형 중 하나가 될 수 있습니다. 프로젝트 유형으로 프로세스를 추적하는 방법이 결정됩니다.

프로젝트 유형

새 컨테이너를 만들 때 프로젝트 유형을 선택합니다. 프로젝트는 관련 작업에 대한 전체 네트워크 관리 식별자(ID)입니다. 컨테이너에서 실행되는 모든 프로세스는 동일한 프로세스 ID를 가지며, 컨테이너는 프로젝트 ID로 사용되고 있는 자원을 추적합니다. 컨테이너 유형은 컨테이너를 작성할 때 선택하는 프로젝트 유형을 기반으로 합니다.

모든 컨테이너에는 프로젝트 이름이 있으며, 이 이름은 해당 정보의 일부로 영구히 보존됩니다. 컨테이너가 호스트에서 활성화되면 이 프로젝트 이름이 해당 호스트의 /etc/project 파일에 추가됩니다. 이 항목은 컨테이너가 해당 호스트에서 활성화되어 있는 동안 남아 있게 됩니다.

같은 프로젝트 이름을 가진 두 개의 프로젝트를 호스트에서 동시에 사용할 수 없습니다. 컨테이너에서 실행되는 프로세스는 프로젝트 ID로 추적되므로 호스트의 모든 프로젝트 이름은 고유해야 합니다.

사용자 기반 및 그룹 기반 프로젝트를 만들 때 사용자 또는 그룹 이름은 프로젝트 이름의 일부가 됩니다. 사용자 기반 컨테이너의 경우 프로젝트 이름은 사용자.사용자이름이 됩니다. 그룹 기반 컨테이너의 경우 프로젝트 이름은 그룹.그룹이름이 됩니다. 따라서 사용자 기반 또는 그룹 기반 프로젝트를 작성할 때 기본 컨테이너에 대한 /etc/project 항목과 중복되는 사용자 이름 또는 그룹 이름은 사용할 수 없습니다. 자세한 내용은 기본 컨테이너를 참조하십시오.

응용 프로그램 기반 컨테이너에 대한 작성 프로세스의 일부로 프로젝트 이름을 선택하여 제공합니다. 프로젝트 작성 마법사는 서로 다른 응용 프로그램 기반의 프로젝트에 대해 중복된 프로젝트 이름을 허용합니다. 그러나 같은 프로젝트 이름을 가진 두 개의 응용 프로그램 기반 프로젝트를 호스트에서 동시에 사용할 수는 없습니다. 서로 다른 호스트에서 이러한 컨테이너를 활성화하려는 경우에만 응용 프로그램 기반 프로젝트를 작성할 때 프로젝트 이름을 다시 사용하십시오. 동일한 프로젝트 이름을 가진 프로젝트가 이미 있는 호스트에서 두 번째 프로젝트를 활성화하려는 경우에는 활성화되지 않습니다.

다음 표는 사용 가능한 세 가지 유형의 프로젝트 및 선택에 따라 나타나는 변경 사항에 대한 자세한 내용을 제공합니다.

표 3–2 프로젝트 유형 세부사항


프로젝트 유형	OS 버전	세부 정보
사용자 기반	Solaris 8	Solaris 8 릴리스에서 지원되는 프로젝트 유형만 해당됩니다. `/etc/project` 파일의 프로젝트 이름은 사용자.`사용자이름`이 됩니다. 프로젝트는 해당 사용자의 주요 기본 프로젝트가 됩니다.
	Solaris 9 및 Solaris 10	`/etc/project` 파일의 프로젝트 이름은 사용자.`사용자이름`입니다. 유효한 형식은 `사용자이름`입니다.
그룹 기반	Solaris 9 및 Solaris 10	`/etc/project` 파일의 프로젝트 이름은 그룹.`그룹이름`이 됩니다. 유효한 형식은 `그룹이름`입니다.
응용 프로그램 기반	Solaris 9 및 Solaris 10	프로젝트 이름은 응용 프로그램 이름 또는 기타 선택한 이름이 될 수 있습니다. 제공한 이름이 `/etc/project` 파일에 추가됩니다. 일치하는 프로세스를 프로젝트 이름에 자동으로 이동하기 위해 일치식을 제공할 수 있습니다. 이 표현식은 대소문자를 구별합니다. 프로세스가 현재 실행되고 있는 해당 `사용자이름` 또는 `그룹이름`을 제공해야 합니다.

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

프로젝트를 사용하여 응용 프로그램의 자원을 만들기 전에 우선 응용 프로그램에 대한 자원 경향을 알아야 합니다. 메모리 캡 용량이 충분하지 않으면 ORACLE® 같은 특정 응용 프로그램의 성능이 상당히 저하됩니다. 모든 프로젝트에는 자원 예약, 즉최소 CPU 공유 및 선택 사항인 최대 메모리 예약(메모리 캡)이 설정되어 있어야 합니다. 응용 프로그램에 대한 자원 요구 사항을 설정한 이후에 이러한 예약을 관리하기 위해서만 프로젝트 사용을 시작해야 합니다.

주의 –

응용 프로그램에서 일반적으로 사용하는 프로젝트보다 작은 프로젝트에 대해 물리적 메모리 캡을 설정하지 마십시오. 그렇게 할 경우, 응용 프로그램에 보다 많은 가상 메모리가 사용되기 때문에 페이징 및 스와핑이 증가하여 응용 프로그램의 성능에 부정적인 영향을 주므로 상당한 지연이 발생할 수 있습니다.

프로젝트를 사용하여 시스템 자원을 관리하기 전에 서버 통합 계획을 종료해야 합니다. 중요한 관련 작업은 통합 계획에 포함한 응용 프로그램에 대한 자원 소비의 경향을 식별하는 것입니다. 이상적으로는작업 환경에 계획을 구현하기 전에 테스트 환경에서 최소 한 달 이상 응용 프로그램에 대한 자원 이용률의 경향을 식별합니다. CPU 및 메모리 소비 경향을 설정한 후, 일반적인 메모리 요구 사항보다 최소한 몇 포인트(백분율)를 더 허용해야 합니다.

프로젝트에 필요한 CPU 공유 양을 예약할 때 CPU의 양을 정수로 할당합니다. 예를 들어, 25, 1, 37 등은 모두 유효한 양입니다. 공유라는 용어를 사용하여 프로젝트에 할당되어 있는 시스템의 CPU 자원 일부를 정의합니다. 다른 프로젝트에 비례하여 한 프로젝트에 많은 수의 CPU 공유를 할당하면 해당 프로젝트가 페어 쉐어 스케줄러로부터 더 많은 CPU 자원을 받습니다.

CPU 공유는 CPU 자원의 백분율과 같지 않습니다. 공유는 다른 작업 부하와 관련하여 작업 부하의 상대적인 중요성을 정의하는 데 사용됩니다. 예를 들어, 판매 프로젝트가 마케팅 프로젝트보다 두 배 중요한 경우, 판매 프로젝트에는 마케팅 프로젝트에 대해 두 배의 공유를 할당해야 합니다. 할당하는 공유 수와는 무관합니다. 판매 프로젝트 공유 2개와 마케팅 프로젝트 공유 1개는 판매 프로젝트 공유 18개와 마케팅 프로젝트 공유 9개와 동일합니다. 두 경우 모두에서 판매 프로젝트에는 마케팅 프로젝트에 대해 두 배의 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 공유를 할당합니다.

이 풀의 경우Project X, Project Y 및 Project Z로 이루어진 세 개의 프로젝트가 있다고 가정합니다. 가장 중요한 프로젝트인 Project X에 50개의 CPU 공유를 할당하고, 다음 프로젝트인 Project Y와 Project Z에는 각각 10개 및 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 영역 공유

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

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

새 영역 마법사의 4단계에서 프로젝트 CPU 공유도 입력할 수 있습니다. 이 필드는 영역 안의 프로젝트에 할당되는 CPU 공유 수를 지정합니다. 이 값을 만들 때 해당 영역에 대한 프로젝트 CPU 공유 값을 설정하게 됩니다. 모든 정수를 입력할 수 있습니다. 입력하는 정수에 따라 얻으려는 값이 결정됩니다.

예를 들어, 영역 A에 대한 프로젝트 CPU 공유를 1000으로 할당한다고 가정합니다. 물리적 수준에서 1000 프로젝트 CPU 공유는 자원 풀에서 상속된 20 CPU 공유를 1000 공유로 나눈 값입니다. 이 예제에서 1개의 프로젝트 CPU 공유와 CPU 공유 사이의 관계를 보여주는 공식은 다음과 같습니다.

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

영역 A에서 프로젝트 1을 작성할 때 프로젝트 1은 공유를 자원 풀에서 직접 가져오지 않고 영역에서 가져옵니다. 영역 A에서 프로젝트 1에 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 공유가 있습니다.

전역 영역의 프로젝트는 배치되어 있는 풀의 CPU 공유 1개로부터 해당 CPU 자원을 가져옵니다.

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

페어 쉐어 스케줄러(FSS)

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

예를 들어, 판매, 마케팅, 데이터베이스의 세 프로젝트에 각각 2개, 1개, 4개의 공유가 할당되어 있습니다. 모든 프로젝트는 활성 프로젝트입니다. 자원 풀에 대한 CPU 자원은 다음과 같이 할당됩니다. 판매 프로젝트는 2/7, 마케팅 프로젝트는 1/7, 데이터베이스 프로젝트는 4/7의 CPU 자원을 받습니다. 판매 프로젝트가 유휴 상태인 경우, 마케팅 프로젝트는 1/5, 데이터베이스 프로젝트는 4/5의 CPU 자원을 받습니다.

페어 쉐어 스케줄러는 CPU에 대한 경쟁이 있을 경우 CPU 사용만 제한합니다. 시스템에서 유일하게 활성인 프로젝트는 보유하는 공유 수에 관계없이 100퍼센트의 CPU를 사용할 수 있습니다. CPU 주기는 낭비되지 않습니다. 프로젝트에 수행할 작업이 없어서 사용할 CPU를 모두 사용하지 않게 되는 경우, 남은 CPU 자원은 다른 활성 프로세스에 배포됩니다. 프로젝트에 정의된 CPU 공유가 없는 경우, 하나의 공유로 할당됩니다. 공유가 0개인 프로젝트의 프로세스는 가장 낮은 시스템 우선 순위로 실행됩니다. 이러한 프로세스는 공유가 1개 이상인 프로젝트가 CPU 자원을 사용하지 않을 때만 실행됩니다.

타임 쉐어 스케줄러(TS)

타임 쉐어 스케줄러(TS)는 모든 프로세스가 사용 가능한 CPU를 상대적으로 균등하게 액세스하도록 하여 우선 순위를 기반으로 CPU 시간을 할당합니다. TS는 관리하지 않아도 되기 때문에 사용이 쉽습니다. 그러나 TS는 특정 응용 프로그램에 대한 성능을 보장하지는 않습니다. CPU 할당이 필수가 아닌 경우, TS를 사용해야 합니다.

예를 들어, FSS 자원 풀에 두 프로젝트가 할당되고 각 프로젝트에 두 개의 공유가 있는 경우, 이 두 프로젝트에서 실행되는 프로세스의 수는 아무런 관련이 없습니다. 프로젝트는 사용 가능한 CPU의 절반만 액세스할 수 있습니다. 따라서 판매 프로젝트에서 1개의 프로세스가 실행되고 마케팅 프로젝트에서 99개의 프로세스가 실행될 경우, 판매 프로젝트의 하나의 프로세스는 CPU의 절반에 액세스할 수 있습니다. 마케팅 프로세스의 99개 프로세스는 사용 가능한 CPU 자원의 절반을 공유해야 합니다.

TS 자원 풀에서는 CPU가 프로세스마다 할당됩니다. 판매 프로젝트에 있는 1개의 프로세스는 CPU의 1퍼센트에만 액세스할 수 있는 반면, 마케팅 프로젝트에 있는 99개의 프로세스는 사용 가능한 CPU 자원의 99퍼센트에 액세스할 수 있습니다.

페어 쉐어 스케줄러 또는 타임 쉐어 스케줄러에 대한 자세한 내용은 System Administration Guide: Network Services를 참조하십시오.

컨테이너 관리자를 사용하여 응용 프로그램 자원 소비 경향 파악

테스트 환경에서 컨테이너 관리자를 도구로 사용하여 다음 작업을 통해 응용 프로그램 자원 소비의 경향을 파악할 수 있습니다.

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

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

자세한 내용은 2 장, 컨테이너 관리자 설치 및 설정 및 Sun Management Center 3.6.1 Performance Reporting Manager User’s Guide를 참조하십시오.
경향을 파악하려는 응용 프로그램에 대한 활성 응용 프로그램 기반 컨테이너를 작성합니다. 새 작성 마법사에서 최소 CPU 예약만 만듭니다. 메모리 캡을 설정하지 마십시오.

자세한 내용은 응용 프로그램 기반 프로젝트 작성 및 응용 프로그램 기반 프로젝트 작성을 참조하십시오.
일별, 주별 또는 실시간 그래프를 사용하여 2주 동안 사용된 자원을 모니터링합니다. 개별 호스트에서 실행 중인 컨테이너에 대한 그래프 및 사용된 CPU 및 메모리 자원에 대한 그래프로 총 2개의 그래프를 사용할 수 있습니다. 또한 프로세스 테이블을 통해 응용 프로그램에서 실행 중인 프로세스를 모니터할 수도 있습니다.

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

자세한 내용은 등록 정보를 사용하여 프로젝트 수정을 참조하십시오.
사용된 메모리가 설정된 메모리 캡을 초과하기 시작하면 알려주도록 경보를 설정합니다. 등록 정보 시트를 사용하여 메모리 캡을 조정합니다.

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

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

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