Solaris OS용 Sun Cluster 개념 안내서

데이터 서비스 프로젝트 구성

RGM을 사용하여 온라인 상태로 가져올 때 Solaris 프로젝트 이름으로 시작하도록 데이터 서비스를 구성할 수 있습니다. 구성은 RGM에 의해 관리되는 자원 또는 자원 그룹을 Solaris 프로젝트 ID와 연결합니다. 자원 또는 자원 그룹을 프로젝트 ID로 매핑하면 Solaris 환경에서 사용할 수 있는 세부 제어 기능을 사용하여 클러스터 내에서 작업 로드 및 소비를 관리할 수 있습니다.


주 –

이 구성은 Solaris 9에서 Sun Cluster 소프트웨어의 현재 릴리스를 실행하는 경우에만 수행할 수 있습니다.


클러스터 환경에서 Solaris 관리 기능을 사용하면 노드를 다른 응용 프로그램과 공유할 때 가장 중요한 응용 프로그램에 우선 순위가 부여되게 할 수 있습니다. 통합된 서비스가 있거나 응용 프로그램이 페일오버된 경우에 여러 응용 프로그램이 하나의 노드를 공유할 수 있습니다. 여기에서 설명하는 관리 기능을 사용하면 우선 순위가 낮은 다른 응용 프로그램이 CPU 시간과 같은 시스템 자원을 과소비하지 못하게 하여 중요 응용 프로그램의 가용성을 향상시킬 수 있습니다.


주 –

이 기능에 대한 Solaris 설명서에서는 CPU 시간, 프로세스, 작업 및 유사 구성 요소를 '자원'으로 설명합니다. 반면에 Sun Cluster 설명서에서는 '자원'이 RGM의 제어를 받는 항목을 설명하는 용어로 사용됩니다. 다음 절에서는 RGM의 제어를 받는 Sun Cluster 항목을 나타내는 용어로 '자원'을 사용하고, CPU 시간, 프로세스 및 작업을 나타내는 용어로 '공급 항목'을 사용합니다.


이 절에서는 지정된 Solaris 9 project(4)에서 프로세스를 시작하도록 데이터 서비스를 구성하는 방법에 대한 개념을 설명합니다. 또한, Solaris 환경에서 제공되는 관리 기능의 사용 계획을 위한 여러 페일오버 시나리오 및 권장 사항을 설명합니다. 관리 기능에 대한 자세한 개념과 절차는 Solaris 9 System Administrator CollectionSystem Administration Guide: Resource Management and Network Services를 참조하십시오.

클러스터에서 Solaris 관리 기능을 사용하도록 자원 및 자원 그룹을 구성할 경우 다음과 같은 고급 프로세스를 사용하는 것이 좋습니다.

  1. 응용 프로그램을 자원의 일부로 구성합니다.

  2. 자원을 자원 그룹의 일부로 구성합니다.

  3. 자원 그룹에서 자원을 사용합니다.

  4. 자원 그룹을 관리 대상으로 만듭니다.

  5. 자원 그룹에 대한 Solaris 프로젝트를 생성합니다.

  6. 자원 그룹 이름을 단계 5에서 생성한 프로젝트에 연결하는 표준 등록 정보를 구성합니다.

  7. 자원 그룹을 온라인 상태로 전환합니다.

표준 Resource_project_name 또는 RG_project_name 등록 정보를 구성하여 Solaris 프로젝트 ID를 자원 또는 자원 그룹에 연결하려면 scrgadm(1M) 명령에 -y 옵션을 사용합니다. 자원 또는 자원 그룹에 대한 등록 정보 값을 설정합니다. 등록 정보 정의는 Sun Cluster Data Services Planning and Administration Guide for Solaris OS의 “Standard Properties”를 참조하십시오. 등록 정보에 대한 설명은 r_properties(5)rg_properties(5)를 참조하십시오.

지정된 프로젝트 이름이 프로젝트 데이터베이스( /etc/project)에 존재해야 하며, 루트 사용자는 명명된 프로젝트의 구성원으로 구성되어야 합니다. 프로젝트 이름 데이터베이스에 대한 개념은 Solaris 9 System Administrator Collection에서 System Administration Guide: Resource Management and Network Services의 “Projects and Tasks”를 참조하십시오. 프로젝트 파일 구문에 대한 자세한 내용은 project(4)를 참조하십시오.

RGM은 자원 또는 자원 그룹을 온라인 상태로 전환할 때 관련 프로세스를 프로젝트 이름으로 시작합니다.


주 –

사용자는 언제든지 프로젝트를 사용하여 자원 또는 자원 그룹에 연결할 수 있습니다. 그러나 자원 또는 자원 그룹이 오프라인 상태로 전환된 다음 RGM을 사용하여 온라인 상태로 다시 전환할 때까지는 새 프로젝트 이름이 적용되지 않습니다.


자원 및 자원 그룹을 프로젝트 이름으로 시작하면 다음과 같은 기능을 구성하여 클러스터 전체에서 시스템이 제공하는 항목을 관리할 수 있습니다.

프로젝트 구성에 대한 요구 사항 결정

Sun Cluster 환경에서 Solaris가 제공하는 컨트롤을 사용하도록 데이터 서비스를 구성하기 전에 전환 또는 페일오버를 통해 자원을 제어 및 추적할 방법을 결정해야 합니다. 새 프로젝트를 구성하기 전에 클러스터 내에서 종속성을 식별하는 것이 좋습니다. 예를 들어, 자원과 자원 그룹은 디스크 장치 그룹에 종속합니다. scrgadm (1M)과 함께 구성된 nodelist, failback , maximum_primariesdesired_primaries 자원 그룹 등록 정보를 사용하여 자원 그룹에 대한 노드 목록 우선 순위를 식별합니다. 자원 그룹과 디스크 장치 그룹 사이의 노드 목록 종속성에 대한 설명은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS의 “Relationship Between Resource Groups and Disk Device Groups”를 참조하십시오. 등록 정보에 대한 자세한 내용은 rg_properties(5)를 참조하십시오.

scrgadm(1M)scsetup(1M)과 함께 구성된 preferencedfailback 등록 정보를 사용하여 디스크 장치 그룹 노드 목록 등록 정보를 확인합니다. 절차 정보는Solaris OS용 Sun Cluster 시스템 관리 안내서의 “디스크 장치 그룹 관리”에 있는 “디스크 장치 등록 정보를 변경하는 방법”을 참조하십시오. 노드 구성과 페일오버 및 확장 가능 데이터 서비스의 동작에 대한 개념은 SunPlex 시스템 하드웨어 및 소프트웨어 구성 요소를 참조하십시오.

모든 클러스터 노드를 동일하게 구성할 경우 기본 노드와 보조 노드에 동일한 사용 한계를 적용합니다. 모든 노드에서 구성 파일에 있는 모든 응용 프로그램에 대해 동일한 프로젝트 구성 매개 변수를 적용할 필요는 없습니다. 적어도 응용 프로그램의 모든 잠정적 마스터에 있는 프로젝트 데이터베이스에서는 해당 응용 프로그램과 연결된 모든 프로젝트에 액세스할 수 있어야 합니다. 응용 프로그램 1이 phys-schost-1에 의해 마스터로 지정되지만 phys-schost-2 또는 phys-schost-3으로 전환되거나 페일오버될 수 있다고 가정합니다. 응용 프로그램 1에 연결된 프로젝트를 세 노드(phys-schost-1, phys-schost-2, phys-schost-3) 모두에서 액세스할 수 있어야 합니다.


주 –

프로젝트 데이터베이스 정보는 로컬 /etc/project 데이터베이스 파일에 저장될 수도 있고 NIS 맵이나 LDAP 디렉토리 서비스에 저장될 수도 있습니다.


Solaris 환경에서는 사용 매개 변수를 유연하게 구성할 수 있지만 Sun Cluster에서는 몇 가지 제한이 부과됩니다. 구성 선택 항목은 사이트의 필요에 따라 다릅니다. 시스템을 구성하기 전에 다음 절의 일반 지침을 따르십시오.

선행 프로세스 가상 메모리 한계 설정

선행 프로세스를 기준으로 가상 메모리를 제한하도록 process.max-address-space 컨트롤을 설정합니다. process.max-address-space 값 설정에 대한 자세한 내용은 rctladm(1M)을 참조하십시오.

Sun Cluster에서 관리 컨트롤을 사용할 경우 불필요한 응용 프로그램 페일오버 및 응용 프로그램 “핑퐁” 효과를 금지하도록 메모리 한계를 적절하게 구성합니다. 일반적으로 다음과 같습니다.

페일오버 시나리오

일반 클러스터 작업 중 및 스위치오버 또는 페일오버 상황에서 프로젝트 구성(/etc/project) 할당 작업이 수행되도록 관리 매개 변수를 구성할 수 있습니다.

다음 절은 시나리오 예입니다.

클러스터 환경에서 응용 프로그램은 자원의 일부로 구성되고 자원은 자원 그룹(RG)의 일부로 구성됩니다. 페일오버가 발생하면 자원 그룹은 연결된 응용 프로그램과 함께 다른 노드로 페일오버됩니다. 다음 예에서는 자원이 명시적으로 표시되지 않습니다. 각 자원에 응용 프로그램이 하나만 있는 것으로 가정합니다.


주 –

페일오버는 RGM에 설정된 기본 노드 목록 순서로 발생됩니다.


다음 예에서는 이러한 제한 조건을 갖습니다.

할당된 공유 개수는 동일하게 유지되지만 각 응용 프로그램에 할당된 CPU 시간 비율은 페일오버 후에 변경됩니다. 이 비율은 노드에서 실행 중인 응용 프로그램의 수 및 각 활성 응용 프로그램에 할당된 공유 수에 따라 다릅니다.

이 시나리오에서는 다음과 같은 구성을 가정합니다.

두 응용 프로그램이 있는 2노드 클러스터

2노드 클러스터에서 두 응용 프로그램을 구성하여 각 물리적 호스트(phys-schost-1, phys-schost-2)가 한 응용 프로그램에 대한 기본 마스터 역할을 하는지 확인할 수 있습니다. 각 물리적 호스트는 다른 물리적 호스트에 대한 보조 노드 역할을 합니다. 응용 프로그램 1 및 응용 프로그램 2에 연결된 모든 프로젝트가 두 노드 모두에서 프로젝트 데이터베이스 파일에 표시되어야 합니다. 클러스터가 일반적으로 실행 중일 때는 각 응용 프로그램이 기본 마스터에서 실행되고, 이 때는 관리 기능에 의해 응용 프로그램에 모든 CPU 시간이 할당됩니다.

페일오버 또는 전환이 발생한 후에는 두 응용 프로그램 모두 단일 노드에서 실행되고 구성 파일에 지정된 대로 응용 프로그램에 공유가 할당됩니다. 예를 들어, /etc/project 파일의 이 항목에 응용 프로그램 1에 4개의 공유가 할당되고 응용 프로그램 2에 1개의 공유가 할당된다고 지정한 경우는 다음과 같습니다.

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

다음 다이어그램에서는 이 구성의 일반 작업과 페일오버 작업을 설명합니다. 할당되는 공유 수는 변경되지 않습니다. 그러나, 각 응용 프로그램에서 사용할 수 있는 CPU 시간 비율은 CPU 시간을 요구하는 각 프로세스에 할당된 공유 개수에 따라 변경될 수 있습니다.

그림: 그래픽에 대한 설명은 이전 컨텍스트를 참조하십시오.

세 응용 프로그램이 있는 2노드 클러스터

세 응용 프로그램이 있는 2노드 클러스터에서는 물리적 호스트(phys-schost-1) 하나를 한 응용 프로그램의 기본 마스터로 구성하고 두 번째 물리적 호스트(phys-schost-2)를 나머지 두 응용 프로그램의 기본 마스터로 구성할 수 있습니다. 모든 노드에서 다음 예 프로젝트 데이터베이스 파일을 가정합니다. 페일오버 또는 전환이 발생할 때 프로젝트 데이터베이스 파일은 변경되지 않습니다.

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)  

클러스터가 정상적으로 실행 중인 경우 기본 마스터 phys-schost-1에서 응용 프로그램 1에 5개의 공유가 할당됩니다. 응용 프로그램 1이 이 노드에서 CPU 시간을 필요로 하는 유일한 응용 프로그램이기 때문에 이 수는 CPU 시간의 100%에 해당합니다. 응용 프로그램 2와 3은 해당 기본 마스터 phys-schost-2에서 각각 3개와 2개의 공유가 할당됩니다. 일반 작업 중에 응용 프로그램 2는 CPU 시간의 60%를 받고 응용 프로그램 3은 40%를 받습니다.

페일오버 또는 스위치오버가 발생하고 응용 프로그램 1이 phys-schost-2로 전환되더라도 세 응용 프로그램 모두에 대한 공유 수는 동일하게 유지됩니다. 그러나, CPU 자원 비율은 프로젝트 데이터베이스 파일에 따라 재할당됩니다.

다음 다이어그램에서는 이 구성의 일반 작업과 페일오버 작업을 설명합니다.

그림: 그래픽에 대한 설명은 이전 컨텍스트를 참조하십시오.

자원 그룹 전용 페일오버

여러 자원 그룹이 동일한 기본 마스터를 갖는 구성에서는 자원 그룹과 관련 응용 프로그램이 보조 노드로 페일오버되거나 전환될 수 있습니다. 반면에 기본 마스터는 클러스터에서 실행됩니다.


주 –

페일오버 중에 페일오버되는 응용 프로그램에는 보조 노드의 구성 파일에 지정된 대로 자원이 할당됩니다. 이 예에서 기본 노드와 보조 노드의 프로젝트 데이터베이스 파일은 동일한 구성을 갖습니다.


예를 들어, 다음 샘플 구성 파일에서는 응용 프로그램 1에 1개의 공유가, 응용 프로그램 2에 2개의 공유가, 응용 프로그램 3에 2개의 공유가 할당되도록 지정합니다.

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)
 

다음 다이어그램에서는 이 구성의 일반 작업과 페일오버 작업을 설명합니다. 여기서 응용 프로그램 2를 포함하는 RG-2는 phys-schost-2에 페일오버됩니다. 할당되는 공유 수는 변경되지 않습니다. 그러나, 각 응용 프로그램에서 사용할 수 있는 CPU 시간 비율은 CPU 시간을 요구하는 각 응용 프로그램에 할당된 공유 개수에 따라 변경될 수 있습니다.

그림: 그래픽에 대한 설명은 이전 컨텍스트를 참조하십시오.