3장 컨테이너 정보 및 제품 시작

이 장은 컨테이너 및 프로젝트와 제품 시작 방법에 대해 설명합니다.

이 장은 다음 내용으로 구성되어 있습니다.

• 컨테이너 관리 개요

• 컨테이너 등록 정보 정보

• 프로젝트 상태

• 컨테이너 관리자 GUI

• 기본 컨테이너

• 컨테이너 작성 정보

컨테이너 관리 개요

컨테이너는 호스트와 연결되어 있는 컨테이너입니다. 프로젝트는 물리적 시스템 자원의 모음을 조직 및 관리하는 데 도움을 줍니다. 프로젝트는 전체 서버 통합 계획을 구현할 경우 유용합니다. 프로젝트는 다음 기능을 제공합니다.

• 시스템 자원의 균형 조절에 도움을 주는 응용프로그램에 대한 최소 CPU 예약 및 메모리 캡 세트

  각 응용프로그램은 해당 프로젝트에 대한 최소 CPU 예약 및 선택적인 메모리 캡 설정이 보증됩니다. 예를 들어, 응용프로그램 기반 프로젝트를 사용하면 네트워크에서 실행되는 응용프로그램에 대한 최소 CPU 예약 및 메모리 캡 둘 모두를 설정할 수 있습니다. 여러 프로젝트가 동일한 호스트에서 활성화된 경우, 해당 고유 프로젝트의 각 응용프로그램을 사용하여 시스템 자원에 대한 충돌이 감소됩니다. 이 경우, 각 프로젝트에 대한 자원 경계 세트가 해당 호스트에서 작동하는 Solaris 커널에 의해 실행됩니다.

• 데이터 센터의 자원 이용율 추적

  프로젝트에 의해 사용되는 전체 자원의 양이 부분적으로 프로젝트 구성원을 사용하여 추적됩니다. 사용자 및 그룹이 하나 이상의 프로젝트에 속할 수 있어도 각 UNIX 사용자는 기본 프로젝트에 할당되어야 합니다. UNIX 사용자가 시작하는 프로세스는 사용자가 구성원인 프로젝트에 바운드될 수 있습니다. 프로젝트는 응용프로그램 자원 소비 추적 및 제어를 돕기 위해 프로젝트 구성원 및 자원 풀 모두를 사용합니다.

  프로젝트 작동 방법 및 프로젝트가 사용하는 자원 관리 도구에 대한 자세한 정보는 1 장, Solaris Container Manager 1.1 소개를 참조하십시오.

• 공유된 메모리 할당

소프트웨어를 설치 및 설정하고 나면 여러 기본 프로젝트를 즉시 사용할 수 있습니다. 또한 프로세스를 통해 안내하는 마법사를 사용하여 사용자 고유의 프로젝트를 작성할 수 있습니다. 모든 프로젝트는 컨테이너와 연결됩니다. 이 컨테이너는 새 프로젝트 작성에 반복하여 사용될 수 있습니다. 프로젝트는 다음과 같은 장점을 제공합니다.

• 동일한 CPU 세트 및 메모리 자원 경계를 사용하여 다중 프로젝트 인스턴스를 생성하는 기능.

• 여러 호스트에 퍼진 다중 프로젝트 인스턴스. 단일 활성 프로젝트가 다중 호스트 범위를 정하는 반면, 동일한 컨테이너가 있는 추가 프로젝트 인스턴스는 다중 호스트에 퍼질 수 있습니다.

• 필요성의 변동에 따라 자원 분배를 빨리 할 수 있도록 새 프로젝트 인스턴스를 활성화하는 데 필요한 시간을 최소화합니다.

GUI는 브라우저 기반이며 다음 세 가지 관리 보기(탭)를 제공합니다. 호스트 투시도에서 하나, 컨테이너 투시도에서 하나 그리고 개방 경보용 하나. 그룹을 작성하고 그룹이 포함해야 하는 요소를 선택하여 호스트 보기 및 컨테이너 보기를 더 조직할 수 있습니다.

또한 사용되는 자원 및 컨테이너 내에서 실행중인 프로세스는 소프트웨어를 사용하여 즉시 검사될 수 있습니다. 또한 여러 그래프 옵션은 데이터를 파일로 내보내는 기능을 포함하여 컨테이너 또는 호스트 당 자원 활용 레벨 사정을 돕기 위해 사용 가능합니다. 이러한 기능을 사용하여 적절한 조절을 위한 자원 소비를 모니터 및 재사정할 수 있습니다.

소프트웨어의 경보 기능을 사용하여 컨테이너의 자원 이용율이 현재 설정에 대한 임계값에 도달할 경우 전자 우편으로 통지를 받을 수 있습니다. 또한 경보 아이콘은 호스트 및 컨테이너 모두에 대해 GUI에서 볼 수 있습니다.

자원 변경 작업 기능을 사용하여 하나의 요청으로 하나 이상의 컨테이너에서 현재 자원 경계에 대한 변경 사항을 예약할 수 있습니다. 마법사는 자원 변경 작업 작성 또는 수정에 필요한 단계를 통해 안내합니다.

컨테이너 등록 정보 정보

컨테이너에는 다음 등록 정보가 있습니다.

• 이름

• 설명(선택 사항)

• 프로젝트 유형

• 컨테이너와 연결된 프로젝트 이름

• 컨테이너 응용프로그램과 연결된 UNIX 사용자 및 그룹

• 일치식(하나가 존재하는 경우)

컨테이너에 할당하는 이름은 영구적이며 변경될 수 없습니다. 마찬가지로 프로젝트 이름도 영구적입니다. 컨테이너에 대한 기타 식별 정보는 변경될 수 있습니다.

컨테이너는 소프트웨어에 의해 저장되며 컨테이너가 삭제될 때까지 반복된 사용을 위해 사용 가능합니다. 프로젝트는 호스트와 연결되어 있는 컨테이너입니다. 호스트와 연결되어 있고 해당 자원 예약이 설정되어 있는 경우 프로젝트는 활성화됩니다.

동일한 정의 및 자원 예약을 가진 다중 프로젝트는 동시에 여러 다른 호스트에서 활성화될 수 있기 때문에 컨테이너는 데이터 센터에서 편리하게 프로젝트를 관리할 수 있습니다. 컨테이너가 저장되고 나면 언제라도 적절한 모든 호스트에서 프로젝트를 활성화하는 데 사용될 수 있습니다. 따라서 컨테이너는 새 프로젝트를 작성하기 위한 템플리트로 사용될 수 있습니다.

컨테이너는 다중 프로젝트에 대해 템플리트의 역할을 합니다. 컨테이너는 중앙 위치에 프로젝트의 일반 등록 정보를 저장합니다. 프로젝트의 일반 등록 정보는 다음과 같습니다.

• 프로젝트 이름.

• 프로젝트가 프로젝트에 포함되어야 하는 프로세스를 결정하는 방법(예: 컨테이너 또는 일치식과 연결된 UNIX 사용자 및 그룹).)

CPU 공유 및 메모리 제한과 같은 기타 등록 정보는 프로젝트가 활성화되어 있는 호스트에 특정합니다. Solaris Container Manager 1.1에서 중심부에 저장되는 일반 등록 정보의 이 세트는 컨테이너라고 불립니다. 컨테이너가 특정 호스트에서 활성화될 때 Solaris 프로젝트 로 예를 들어 설명되며 /etc/project에 저장됩니다.

예를 들어, 회사에서 해당 전자 우편 응용프로그램에 대해 컨테이너를 설정하려고 합니다. 프로젝트의 일반 등록 정보는 다음과 같습니다.

• 프로젝트 이름: mail_services.

• 프로젝트가 프로젝트에 포함되어야 하는 프로세스를 결정하는 방법은 “mozilla”를 포함하는 일치식이 됩니다.

컨테이너가 특정 호스트에서 활성화될 때 회사에서 프로젝트를 실증하여 이제 자원 풀, CPU 공유 및 메모리 제한을 지정할 수 있습니다.

그림 3–1 컨테이너 및 프로젝트

컨테이너를 사용하여 영역 및 호스트에서 다중 프로젝트를 작성할 수 있습니다. 예를 들어, 단일 컨테이너를 사용하여 세 개의 다른 호스트에서 세 개의 활성 프로젝트를 작성하는 경우, 해당 컨테이너에 하나의 컨테이너 및 세 개의 프로젝트가 있습니다. 컨테이너의 기본 정보 변경은 해당 컨테이너를 기초로 한 모든 프로젝트를 변경합니다.

프로젝트 작성 마법사는 모든 단계 완료시 활성화되는 프로젝트를 생성할 수 있는 옵션을 제공합니다. 컨테이너는 동시에 작성되며 해당 이름은 GUI에 저장됩니다. 또한 컨테이너를 작성하고 프로세스를 통해 안내하는 마법사를 사용하여 나중에 프로젝트를 활성화할 수 있는 옵션도 있습니다.

컨테이너의 경우, GUI를 사용하여 다음 작업을 수행할 수 있습니다.

• 새 컨테이너 만들기

• 새 그룹 만들기

• 그룹 내부 및 외부로 컨테이너 이동

• 등록 정보 수정

• 호스트에 새 프로젝트 만들기

• 컨테이너 삭제

프로젝트의 경우, GUI를 사용하여 다음 작업을 수행할 수 있습니다.

• 새 그룹 만들기

• 프로젝트 이동

• 등록 정보 수정

• 자원 예약 변경

• 자원 변경 작업 만들기

• 내부에서 실행중인 프로세스 상태 확인

• 이용율 보고서 요청 및 데이터를 파일로 내보내기

• 프로젝트 비활성화 또는 활성화

• 경보 설정

• 프로젝트 삭제

프로젝트 상태

프로젝트는 응용프로그램에 대해 설정한 자원 소비 경계를 실제로 실행하지 않습니다. 반대로, 최소 CPU 예약 및 메모리 캡을 제공하여 프로젝트를 활성화하고 나면 Solaris 커널이 이러한 경계 실행을 시작합니다. 프로젝트를 사용하기 전에 프로젝트 상태에 대해 자세히 알아야 합니다. 프로젝트는 다음 세 가지 상태 중 하나에 있을 수 있습니다. 정의됨, 활성화 및 비활성화.

그림 3–2 프로젝트 상태

프로젝트는 해당 수명 내내 이러한 상태 사이를 이동할 수 있습니다.

컨테이너 및 프로젝트

컨테이너는 프로젝트 자체가 아직 완전히 형성되지 않은 초기 단계 중에 작성됩니다. 각 프로젝트는 고유 이름을 가져야 하며 데이터베이스에 일정하지 않게 저장될 수 있습니다.

그림 3–2는 컨테이너가 호스트와 연결된 후 활성화 상태로 이동하는 프로젝트를 표시합니다. 이것이 비활성화되고 호스트와 더 이상 연결되지 않으면 나면 정의됨 상태로 비활성 프로젝트가 다시 이동할 수 있습니다.

프로젝트 활성화

프로젝트를 활성화시키는 첫 번째 단계는 해당 컨테이너를 호스트와 연결시키는 것입니다. 두 번째 단계는 자원 경계 설정, 즉 프로젝트에 대해 최소 CPU 예약 및 메모리 캡을 할당하는 것입니다. 프로젝트는 이러한 자원 경계를 지원할 수 있는 호스트와 연결되어야 합니다. 또한 활성 프로젝트는 프로젝트가 밀려 호스트에 상주한다는 의미에서 배포되는 것으로 언급될 수도 있습니다.

새 프로젝트 마법사를 사용하여 응용프로그램 기반 프로젝트를 작성할 경우, 응용프로그램과 연결된 프로세스를 식별하는 일치식가 제공될 수 있습니다. 그런 다음 일치식에 대응하는 모든 프로세스가 이 컨테이너 아래로 자동으로 이동합니다. 프로젝트 활성화 시, /etc/project 데이터베이스의 모든 항목은 컨테이너가 연결된 호스트에 작성됩니다. 마찬가지로, 일치하는 프로세스는 컨테이너의 프로젝트 이름 아래로 이동합니다. 프로세스가 이동한 후, 모든 자원 이용율 데이터가 프로젝트에 대해 수집 및 저장됩니다.

비활성 프로젝트

프로젝트가 비활성화되면 자원 경계가 더 이상 실행되지 않습니다. 비활성화된 프로젝트는 비활성화 상태가 되고 호스트의 /etc/project 파일에서 삭제됩니다. 비활성화 상태에 있는 동안, 프로젝트는 나중에 활성화될 때까지 계속 소프트웨어의 데이터베이스에 존재합니다. 비활성 프로젝트가 재활성화되고 나면 컨테이너의 자원 경계가 다시 실행됩니다.

활성화 상태에 있는 동안 프로젝트의 자원 이용에 대해 수집된 모든 데이터는 데이터베이스에 보존됩니다. 프로젝트가 비활성화된 후 최대 30일 동안 비활성 프로젝트에 대한 이용율 보고서를 요청할 수 있습니다.

컨테이너 관리자 GUI

Solaris 소프트웨어 자원 관리의 표준 명령줄 명령은 컨테이너 관리자 소프트웨어에서 지원되지 않습니다. 컨테이너 관리자 그래픽 사용자 인터페이스(GUI)에서 컨테이너를 관리해야 합니다. GUI는 브라우저를 사용하여 Java Web Console에서 시작됩니다. 다음과 같은 브라우저가 지원됩니다.

• Solaris 릴리스 8과 9의 Netscape Navigator^TM 4.7x, 6.2x 및 7.x

• Microsoft Windows (98/2000/XP)의 Netscape Navigator 4.7x, 6.2x 및 7.x

• Mozilla^TM 1.4 이상

• Microsoft Windows (98/2000/XP)의 Internet Explorer 5.0 이상 (6.x 포함)

컨테이너 관리자 GUI 시작

단계

1. UNIX 사용자 ID가 /var/opt/SUNWsymon/cfg/esusers 파일에 없는 경우, 이 항목을 작성하십시오.

   또한 사용자는 esadm 또는 esdomadm 그룹 중 하나로 할당되어야 합니다.

   항목 작성 및 그룹으로의 할당에 대한 지침은 Sun Management Center 3.5 Installation and Configuration Guide의 Setting Up Users을 참조하십시오.

2. 브라우저를 시작합니다.

   지원된 브라우저 목록은 컨테이너 관리자 GUI를 참조하십시오.

3. 컨테이너 관리자 GUI로 이동하려면 다음을 입력하십시오.

   https://sunmc-server_machine_name:6789/containers

   Java Web Console 로그인 페이지가 나타납니다.

   그림 3–3 Java Web Console 로그인 페이지

   
   

   로그인 페이지가 나타나지 않는 경우, Java Web Console을 재시작해야 할 수도 있습니다. 지침은 Java Web Console 재시작을 참조하십시오.

   ---

   정보 –

   Console 페이지로 이동한 경우, 시스템 절 아래의 Solaris Container Manager 1.1 링크를 눌러 GUI에 액세스합니다.

   ---

4. UNIX 사용자 ID 및 암호를 사용하여 Java Web Console에 로그인합니다.

   컨테이너 관리자 GUI가 나타납니다. 화면에 세 가지 탭 즉,호스트, 컨테이너 및 경보 열기가 있습니다.

   그림 3–4 컨테이너 관리자 기본 페이지

   
   

Java Web Console 재시작

Java Web Console에 액세스할 수 없는 경우, 이 명령을 사용하여 재시작합니다.

단계

수퍼유저로 다음과 같이 입력하여 Java Web Console을 다시 시작합니다.

# /usr/sbin/smcwebserver restart

컨테이너 관리자 GUI 탭

다음 표는 컨테이너 관리자 GUI의 오른쪽 창에 나타나는 탭에 대한 정보를 제공합니다.

표 3–1 컨테이너 관리자 GUI 탭

탭	탭 이름	내용
호스트 (보기)	내용	선택한 호스트의 자원 풀에 대한 정보를 제공합니다.
	등록 정보	선택한 호스트, 영역, 프로젝트 또는 자원 풀의 등록 정보에 대한 정보를 제공합니다.
	사용률	호스트, 프로젝트 또는 풀의 일일, 주별 또는 월별 자원 이용율에 대한 정보를 제공합니다. 실시간 이용율 데이터는 활성 데이터에 사용 가능합니다. Performance Reporting Manager 소프트웨어가 설치된 경우에만 이 탭이 보입니다.
	프로젝트	호스트와 연결된 프로젝트에 대한 정보를 제공합니다.
	영역	호스트와 연결된 영역에 대한 정보를 제공합니다.
컨테이너 (보기)	내용	프로젝트에 대한 정보를 제공합니다.
	등록 정보	선택한 호스트, 컨테이너, 프로젝트 또는 자원 풀의 등록 정보에 대한 정보를 제공합니다.
	사용률	호스트, 프로젝트 또는 풀의 일일, 주별 또는 월별 자원 이용율에 대한 정보를 제공합니다. 실시간 이용율 데이터는 활성 데이터에 사용 가능합니다. Performance Reporting Manager 소프트웨어가 설치된 경우에만 이 탭이 보입니다.
	작업 (자원 변경 작업)	예약된 자원 변경 작업에 대한 정보를 제공합니다. 또한 이 탭에서 새 자원 변경 작업을 작성할 수 있습니다. 기본 컨테이너는 그에 연결된 자원 변경 작업이 있을 수 없습니다.
경보 열기		심각도, 메시지, 관리된 객체, 시작 시간 및 인식을 포함하여 경보 열기에 대한 정보를 제공합니다.
자원 풀 (드릴 다운)	내용	선택한 자원 풀의 영역에 대한 정보를 제공합니다.
	등록 정보	선택한 자원 풀의 등록 정보에 대한 정보를 제공합니다.
	사용률	풀의 일일, 주별 또는 월별 자원 이용율에 대한 정보를 제공합니다. Performance Reporting Manager 소프트웨어가 설치된 경우에만 이 탭이 보입니다.
	프로젝트	선택한 자원 풀과 연결된 프로젝트에 대한 정보를 제공합니다.
영역 (드릴 다운)	내용	선택한 영역의 프로젝트에 대한 정보를 제공합니다.
	등록 정보	선택한 영역의 등록 정보에 대한 정보를 제공합니다.
	사용률	영역의 일일, 주별 또는 월별 자원 이용율에 대한 정보를 제공합니다. Performance Reporting Manager 소프트웨어가 설치된 경우에만 이 탭이 보입니다.
프로젝트 (드릴 다운)	등록 정보	선택한 프로젝트의 등록 정보에 대한 정보를 제공합니다.
	사용률	프로젝트의 일일, 주별 또는 월별 자원 이용율에 대한 정보를 제공합니다. Performance Reporting Manager 소프트웨어가 설치된 경우에만 이 탭이 보입니다.
	프로세스	선택한 프로젝트의 프로세스에 대한 정보를 제공합니다.
	임계값 경보	임계값 경보를 설정 또는 제거하는 데 사용됩니다.

호스트 보기

호스트 보기는 호스트 투시도로부터 정보를 조직합니다. 관리 중인 모든 에이전트 시스템이 탐색 창에 나타납니다. 호스트 이름 옆의 확장 삼각형을 누르면 각 호스트에 사용 가능한 자원 풀이 나타납니다. 또한 이 창에서 호스트와 연결된 컨테이너를 관리할 수 있습니다.

소프트웨어가 설치된 모든 에이전트 호스트가 자동으로 검색되고 호스트 보기에 추가됩니다. 이 보기는 탐색 창의 왼쪽 탐에서 액세스됩니다. 검색된 모든 에이전트 호스트는 초기에 호스트라는 제목의 기본 그룹 아래에 위치합니다. 새 그룹을 작성하고 호스트를 관련 그룹으로 이동시켜 이 보기를 더 조직할 수 있습니다.

---

주 –

Sun Management Center 서버 컨텍스트의 일부이고 Solaris Container Manager 1.1이 설치된 해당 에이전트 시스템만 설치되고 호스트 보기에 로드됩니다. 서버 컨텍스트에 대한 자세한 정보는 Sun Management Center 3.5 사용자 설명서의 Sun Management Center 구조을 참조하십시오.

---

호스트 보기에서 사용 가능한 탭 및 정보는 표 3–1에 나열됩니다.

호스트와 연결된 모든 프로젝트 인스턴스에 대한 정보는 프로젝트 표에 나열됩니다.

다음 그림은 기본 풀과 연결된 프로젝트 표가 있는 호스트 보기를 표시합니다.

그림 3–5 샘플: 프로젝트 표를 표시하는 호스트 보기

프로젝트 표는 줄 당 한 프로젝트를 상세화하는 각 프로젝트에 대한 정보를 제공합니다. 프로젝트 표는 다음 데이터를 제공합니다.

프로젝트 이름

프로젝트의 이름

컨테이너 이름

컨테이너의 이름

상태

프로젝트의 상태활성 및 비활성

자원 풀 이름

프로젝트가 인바운드된 자원 풀

영역 이름

프로젝트가 상주하는 영역의 이름. Solaris 8 및 Solaris 9 호스트의 경우, 영역 이름은 항상 전역입니다.

CPU 예약(CPU 공유)

프로젝트에 대해 설정된 최소 CPU 공유

CPU 사용량(CPU)

프로젝트가 사용중인 CPU의 양

메모리 캡(MB)

MB 단위의 최대 메모리 한계

메모리 사용량(MB)

MB 단위의 프로젝트가 사용한 메모리

공유 메모리(MB)

MB 단위의 이 프로젝트에서 실행되는 프로세스에 의해 사용될 수 있는 전체 메모리의 양.

자원 풀 표는 각 자원 풀에 대한 정보를 제공합니다. 자원 풀 표는 다음 데이터를 제공합니다.

자원 풀 이름

자원 풀의 이름

현재 CPU

자원 풀에 대해 현재 설정된 CPU의 수

예약되지 않은 CPU 공유

자원 풀의 영역 또는 프로젝트에 할당되지 않은 CPU 공유

스케줄러

자원 풀에 대해 설정된 스케줄러: 시분할 스케줄러 또는 페어 쉐어 스케줄러

CPU 공유

자원 풀에 대해 설정된 CPU 공유

최소 CPU 예약

자원 풀에 대해 설정된 최소 CPU 수

최대 CPU 예약

자원 풀에 대해 설정된 최대 CPU 수

영역 표는 각 영역에 대한 정보를 제공합니다. 영역 표는 다음 데이터를 제공합니다.

영역 이름

영역의 이름

영역 상태

영역의 상태: 구성됨, 불완전, 설치됨, 준비, 실행 중, 종료 중 또는 중지

영역 호스트 이름

가상 호스트로서 영역에 대한 고유 이름

영역 경로

루트(/) 디렉토리에서 시작되는 절대 경로

IP 주소

영역에 대한 IP 주소

프로젝트 CPU 공유

영역의 프로젝트에 할당된 CPU 공유의 수

예약되지 않은 CPU 공유

이 영역과 연결된 프로젝트에 대한 할당에 사용 가능한 CPU 공유의 수

예약된 CPU 공유

자원 풀의 이 영역에 할당된 CPU 공유의 수

자원 풀

이 영역에 대한 자원 풀

컨테이너 보기

컨테이너 보기는 컨테이너 투시도로부터 정보를 조직합니다. 모든 컨테이너 및 프로젝트가 탐색 창에 나타납니다. 새 프로젝트를 만드는 데 컨테이너가 반복적으로 사용될 수 있기 때문에, 다른 관리 작업 뿐 아니라 이 보기에서 컨테이너에 즉시 액세스할 수 있습니다.

설치 및 설정이 완료된 후 컨테이너 보기는 기본값으로 컨테이너 그룹을 자동으로 추가합니다. 컨테이너는 컨테이너 보기에서 관리됩니다.

다음 그림은 컨테이너 보기를 표시합니다.

그림 3–6 샘플: 기본 컨테이너와 연결된 호스트를 표시하는 컨테이너 보기

컨테이너 보기에서 사용 가능한 정보는 표 3–1에 나열됩니다.

그룹을 사용한 호스트 및 컨테이너 조직

호스트 보기에는 기본 그룹 호스트가 포함됩니다. 소프트웨어 설치 후 검색된 모든 호스트는 이 그룹에 위치합니다. 마찬가지로, 컨테이너 보기에는 호스트의 모든 기본 컨테이너가 위치하는, 기본값으로 이름 지정된 기본 그룹이 있습니다. 호스트 및 컨테이너를 조직하기 위한 각 보기에서 추가 그룹을 작성할 수 있습니다.

그룹을 사용하여 데이터 센터에 갖고 있는 수십 수백의 시스템을 조직할 수도 있습니다. 예를 들어, 그룹에 함께 있는 호스트를 놓을 수도 있습니다. 동일한 고객(내부 또는 외부) 또는 그룹의 부서가 소유한 컨테이너를 놓을 수도 있습니다. 마찬가지로 그룹의 유사한 응용프로그램을 사용하여 컨테이너를 놓을 수도 있습니다.

컨테이너 그룹 또는 호스트 그룹 작성

단계

1. 컨테이너 관리자 GUI가 아직 열리지 않은 경우, 컨테이너 관리자 GUI 시작에 설명된 대로 액세스합니다.

2. 탐색 창에서 적절한 보기를 선택하십시오.

   • 새 컨테이너 그룹의 경우, 컨테이너 보기를 선택합니다. 컨테이너 표가 오른쪽 창에 나타납니다.

   • 새 호스트 그룹의 경우, 호스트 보기를 선택합니다. 호스트 및 그룹 표가 오른쪽 창에 나타납니다.

3. 새 그룹 버튼을 누릅니다.

   대화 상자가 표시됩니다.

4. 그룹 이름을 입력하고 [확인]을 클릭하십시오.

   이름은 32자를 초과할 수 없습니다.

   선택한 보기에 새 그룹이 나타납니다.

다른 그룹으로 컨테이너 또는 호스트 이동

단계

1. 컨테이너 관리자 GUI가 아직 열리지 않은 경우, 컨테이너 관리자 GUI 시작에 설명된 대로 액세스합니다.

2. 탐색 창에서 적절한 보기를 선택하십시오.

   • 컨테이너를 다른 그룹으로 이동시키려면 컨테이너 보기를 선택합니다. 컨테이너 표가 오른쪽 창에 나타납니다.

   • 호스트를 다른 그룹으로 이동시키려면 호스트 보기를 선택합니다. 호스트 및 그룹 표가 오른쪽 창에 나타납니다.

3. 표에서 이동 버튼을 활성화하려면 이동할 컨테이너 또는 호스트에 대한 확인란을 선택합니다.

4. 오른쪽 창에서 이동 버튼을 누릅니다.

   대화 상자에 사용 가능한 그룹이 나열됩니다.

5. 컨테이너 또는 호스트가 이동될 그룹을 선택합니다.

6. 확인을 누릅니다.

   컨테이너 또는 호스트가 선택한 그룹으로 이동합니다.

기본 컨테이너

소프트웨어를 설정하고 나면 컨테이너 보기가 초기에 기본값이 제목인 그룹과 함께 로드됩니다. 이 그룹은 Solaris 9 또는 Solaris 10 OS를 실행하는 호스트에 다음 다섯 개의 기본 컨테이너를 포함합니다.

• 기본값

• 프로젝트가 없는 프로세스

• 루트 사용자

• 시스템 프로세스

• 그룹 스태프를 갖는 사용자

다섯 개의 각 기본 컨테이너는 /etc/project 파일에 대응하는 항목이 있습니다. 특히, 다섯 개의 항목은 default, noproject, user.root, system 및 group.staff에 대응합니다.

---

주 –

Solaris 8 릴리스를 실행하는 호스트에서 그룹 스태프를 갖는 사용자(group.staff) 컨테이너는 존재하지 않습니다. 그렇지 않은 경우 기본 컨테이너는 동일합니다.

---

그림 3–7 샘플: 컨테이너가 표시된 시스템 컨테이너 그룹

각 기본 컨테이너는 활성 상태에 있으며, 해당 경계는 1개의 최소 CPU 예약(CPU 공유) 및 메모리 캡 없음으로 설정됩니다. 기본 컨테이너는 항상 호스트의 기본 자원 풀(pool_default )에 바운드됩니다. Performance Reporting Manager이 설치된 경우, 자원 이용율을 모니터하고 각 기본 컨테이너에 대한 보고서를 실행할 수 있습니다.

이러한 기본 컨테이너는 비활성화, 편집 또는 삭제될 수 없습니다. 이에 따라 각 컨테이너는 읽기 전용으로 레이블 지정됩니다.

모든 UNIX 사용자는 기본 프로젝트에 할당되며 마찬가지로 기본 컨테이너에 할당됩니다. 초기에 기본 컨테이너은 시스템에서 실행중인 모든 프로세스를 포함합니다. 프로젝트를 작성할 때, 프로세스는 대응하는 기본 컨테이너에서 작성한 프로젝트로 이동합니다.

컨테이너 작성 정보

모든 프로젝트는 컨테이너와 함께 시작합니다. 프로젝트는 해당 작성 중 선택된 프로젝트 유형에 따라 세 가지 유형 중 하나일 수 있습니다. 프로젝트 유형은 프로세스가 추적되는 방법을 결정합니다.

프로젝트 유형

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

모든 컨테이너에는 해당 정보의 영구적인 일부인 프로젝트 이름이 있습니다. 컨테이너가 호스트에서 활성화되면 이 프로젝트 이름은 해당 호스트의 /etc/project 파일에 추가됩니다. 이 항목은 컨테이너가 해당 호스트에서 활성화되는 동안 유지됩니다.

동시에 호스트에서 활성화된 동일한 프로젝트 이름을 가진 두 개의 프로젝트를 가질 수 없습니다. 이것은 컨테이너에서 실행되는 프로세스가 프로젝트 ID로 추적되기 때문입니다. 따라서 호스트의 모든 프로젝트 이름은 고유해야 합니다.

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

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

다음 표는 사용 가능하고 선택 사항을 기초로 변경 사항이 발생하는 세 개의 프로젝트 유형에 대한 세부 정보를 제공합니다.

표 3–2 프로젝트 유형 세부 정보

프로젝트 유형	OS 버전	세부 정보
사용자 기반	Solaris 8	Solaris 8 릴리스에서 지원된 유일한 프로젝트 유형.  /etc/project 파일의 프로젝트 이름은 사용자가 됩니다.사용자이름. 프로젝트는 사용자의 주요 기본 프로젝트가 됩니다.
	Solaris 9 및 Solaris 10	/etc/project 파일의 프로젝트 이름은 사용자가 됩니다.이 프로젝트에 결합할 수 있는 UNIX 사용자 목록을 가진 사용자이름. 유효한 형태는 사용자이름입니다.
그룹 기반	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 자원의 백분율과 같지 않습니다. 공유는 다른 작업 부하에 관하여 상대적인 작업 부하의 중요성을 정의하는 데 사용됩니다. 예를 들어, 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를 참조하십시오.

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

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

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

   자세한 정보는 2 장, 컨테이너 관리자 설치 및 설정을 참조하십시오.

2. 모니터하려는 모든 에이전트 시스템에 Performance Reporting Manager 설치.

   자세한 정보는 2 장, 컨테이너 관리자 설치 및 설정 및 Sun Management Center 3.5 Performance Reporting Manager 사용자 설명서를 참조하십시오.

3. 원하는 응용프로그램에 대한 활성 응용프로그램 기반 컨테이너 작성. 새 작성 마법사에서 최소 CPU 예약만 만듭니다. 메모리 캡을 설정하지 마십시오.

   자세한 정보는 응용 프로그램 기반 프로젝트 작성 및 응용 프로그램 기반 프로젝트 작성을 참조하십시오.

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

   자세한 정보는 활성 프로젝트에 대한 자원 이용률 보고서 요청 및 프로젝트 프로세스 보기를 참조하십시오.

5. 응용프로그램에 대해 최대 물리적 메모리 요구 사항을 설정한 후 컨테이너의 등록 정보를 수정하여 메모리 캡에 포함시킵니다. 응용프로그램이 사용중인 최대 메모리보다 작은 캡을 설정하지 마십시오.

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

6. 사용된 메모리가 메모리 캡 설정을 초과하는지 알 수 있도록 경보 설정. 등록 정보 시트를 사용하여 메모리 캡을 조정합니다.

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

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

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