test

Solaris OS용 Sun Cluster 개념 안내서

3장 시스템 관리자와 응용 프로그램 개발자를 위한 주요 개념

이 장에서는 Sun Cluster 시스템의 소프트웨어 구성 요소와 관련된 주요 개념에 대해 설명합니다. 주요 내용은 다음과 같습니다.

이 정보는 Sun Cluster API 및 SDK를 사용하는 시스템 관리자와 응용 프로그램 개발자를 주요 대상으로 합니다. 클러스터 시스템 관리자는 클러스터 소프트웨어를 설치, 구성 및 관리하기 위한 준비 단계에서 이 정보를 사용할 수 있습니다. 응용 프로그램 개발자는 이 정보를 사용하여 작업할 클러스터 환경을 알 수 있습니다.

관리 인터페이스

여러 사용자 인터페이스 중에서 Sun Cluster 시스템을 설치, 구성 및 관리하는 방법을 선택할 수 있습니다. SunPlex Manager 그래픽 사용자 인터페이스(GUI) 또는 문서화된 명령줄 인터페이스를 통해 시스템 관리 작업을 수행할 수 있습니다. 명령줄 인터페이스의 맨 위에는 선택한 설치 및 구성 작업을 간소화하는 scinstall 및 scsetup 등의 유틸리티가 있습니다. 또한 Sun Cluster 시스템에는 Sun Management Center의 일부로 실행되어 특정 클러스터 작업에 GUI를 제공하는 모듈이 있습니다. 이 모듈은 SPARC 기반 클러스터에서만 사용할 수 있습니다. 관리 인터페이스에 대한 자세한 내용은 Solaris OS용 Sun Cluster 시스템 관리 안내서의 관리 도구를 참조하십시오.

클러스터 시간

클러스터에 있는 모든 노드 간의 시간은 동기화해야 합니다. 클러스터 작동에서 외부 시간 소스를 사용하여 클러스터 노드를 동기화할 것인지는 중요하지 않습니다. Sun Cluster 시스템은 NTP(Network Time Protocol)를 사용하여 노드 간에 클럭을 동기화합니다.

일반적으로 초의 끝자리 수 부분에 대해 시스템 시계를 변경해도 문제는 없습니다. 그러나 작동하는 클러스터에서 date(1), rdate(1M) 또는 xntpdate(1M) 명령을 실행하면(대화식으로 또는 cron 스크립트 내에서), 시스템 시계를 시간 소스와 동기화하기 위해 초의 끝자리 소수 부분보다 훨씬 큰 시간 값을 강제로 변경할 수 있습니다. 이러한 강제 변경으로 파일 수정 타임스탬프에 문제가 되거나 NTP 서비스에 혼란이 올 수 있습니다.

각 클러스터 노드에 Solaris 운영 체제를 설치할 때 해당 노드의 기본 시간과 날짜 설정을 변경할 수 있습니다. 일반적으로 출하 시의 기본값을 승인할 수 있습니다.

scinstall(1M) 명령을 사용하여 Sun Cluster 소프트웨어를 설치하는 프로세스 중에 클러스터에 NTP를 구성하는 단계가 있습니다. Sun Cluster 소프트웨어는 모든 클러스터 노드 사이에 동등한 관계를 설정하는 템플릿 파일인 ntp.cluster를 제공합니다(설치된 클러스터 노드의 /etc/inet/ntp.cluster 참조). 한 개의 노드는 “선호하는” 노드로 지정됩니다. 노드들은 개인 호스트 이름으로 식별되고 시간 동기화가 클러스터 상호 연결을 거쳐 발생합니다. NTP에 대한 클러스터를 구성하는 방법에 대한 지침은 Solaris OS용 Sun Cluster 소프트웨어 설치 안내서의 2 장, Sun Cluster 소프트웨어 설치 및 구성를 참조하십시오.

대신 클러스터 외부에 하나 이상의 NTP 서버를 설정하고 이 구성을 적용하여 ntp.conf 파일을 변경할 수도 있습니다.

일반적인 작동 하에서는 클러스터에서 시간을 조정할 필요가 없습니다. 그러나 Solaris 운영 체제를 설치할 때 시간이 잘못 설정되어 이를 변경하려는 경우 수행해야 할 절차는 Solaris OS용 Sun Cluster 시스템 관리 안내서의 7 장, 클러스터 관리에 있습니다.

고가용성 프레임워크

Sun Cluster 시스템은 네트워크 인터페이스, 응용 프로그램, 파일 시스템 및 멀티 호스트 장치를 포함하여 사용자와 데이터 사이의 “경로”에 있는 모든 구성 요소의 가용성을 향상시킵니다. 일반적으로, 클러스터 구성 요소는 시스템에서 단일(소프트웨어 또는 하드웨어) 실패를 극복할 경우, 가용성이 높습니다.

다음 표에서는 Sun Cluster 구성 요소의 장애 종류(하드웨어 및 소프트웨어 모두)와 고가용성 프레임워크에 기본 제공되는 복구 종류에 대해 설명합니다.

표 3–1 Sun Cluster 장애 감지 및 복구 수준

장애가 발생한 클러스터 구성 요소 

소프트웨어 복구 

하드웨어 복구 

데이터 서비스 

HA API, HA 프레임워크 

해당 없음 

공용 네트워크 어댑터 

IP (Internet Protocol) Network Multipathing 

다중 공용 네트워크 어댑터 카드 

클러스터 파일 시스템 

기본 및 보조 복제본 

멀티 호스트 장치 

미러된 멀티 호스트 장치 

볼륨 관리(Solaris 볼륨 관리자 및 SPARC 기반 클러스터 전용으로 사용 가능한 VERITAS Volume Manager) 

하드웨어 RAID-5 (예: Sun StorEdgeTM A3x00)

전역 장치 

기본 및 보조 복제본 

장치, 클러스터 전송 연결 장치에 대한 다중 경로 

독립 네트워크 

HA 전송 소프트웨어 

여러 개인용 하드웨어 독립 네트워크 

노드 

CMM, 페일페스트 드라이버 

다중 노드 

Sun Cluster 소프트웨어의 고가용성 프레임워크는 노드 장애를 즉각적으로 감지하고 클러스터의 나머지 노드에 프레임워크 자원을 제공하는 새로운 서버를 만듭니다. 모든 프레임워크를 동시에 사용하지 못하는 경우는 없습니다. 손상된 노드의 영향을 받지 않는 프레임워크 자원은 복구가 진행 중인 동안에도 아무 제한없이 사용할 수 있습니다. 또한 실패한 노드의 프레임워크 자원은 복구되는 대로 사용할 수 있게 됩니다. 복구된 프레임워크 자원은 다른 모든 프레임워크 자원이 복구를 완료할 때까지 기다리지 않아도 됩니다.

대부분의 고가용성 프레임워크 자원은 해당 자원을 사용하는 응용 프로그램(데이터 서비스)으로 투명하게 복구됩니다. 프레임워크 자원 액세스의 시멘틱은 노드 실패에서 완전하게 보존됩니다. 응용 프로그램에서는 프레임워크 자원 서버가 다른 노드로 이동했음을 쉽게 감지할 수 없습니다. 한 노드에 장애가 발생하면 이 노드에 연결된 파일, 장치 및 디스크 볼륨을 사용하는 나머지 노드의 프로그램에서 이런 사실을 분명하게 알 수 있습니다. 다른 노드의 디스크에 대체 하드웨어 경로가 있는 경우에는 이 사실이 분명해집니다. 여러 노드에 대한 포트를 갖고 있는 멀티 호스트 장치를 사용하는 경우를 한 가지 예로 들 수 있습니다.

클러스터 구성원 모니터

데이터를 훼손하지 않고 안전하게 보존하려면, 모든 노드가 클러스터 구성원에서 일관되게 일치해야 합니다. 필요한 경우, CMM은 실패에 대한 응답에서 클러스터 서비스(응용 프로그램)의 클러스터 재구성에 통합됩니다.

CMM은 클러스터 전송 계층으로부터 다른 노드에 대한 연결 정보를 수신합니다. CMM은 클러스터 상호 연결을 사용하여 재구성 동안의 상태 정보를 교환합니다.

클러스터 구성원의 변경을 발견한 다음 CMM은 해당 클러스터에 대해 동기화된 구성을 수행합니다. 동기화된 구성에서는 클러스터 자원이 클러스터의 새 구성원을 기준으로 재배포될 수 있습니다.

이전의 Sun Cluster 소프트웨어 릴리스와는 달리, CMM은 전적으로 커널에서 실행됩니다.

클러스터가 여러 개의 별도 클러스터로 분할되지 않도록 보호하는 방법에 대한 자세한 내용은 장애 차단 정보를 참조하십시오.

페일패스트 기법

CMM이 노드에서 치명적인 문제를 확인하면 클러스터 프레임워크를 호출하여 강제로 해당 노드를 종료(패닉)시키고 클러스터 구성원에서 제거합니다. 이러한 작업을 수행하는 기법을 페일패스트라고 합니다. 페일패스트에 의해 노드가 종료되는 경우는 다음 두 가지가 있습니다.

클러스터 데몬이 중단되면 노드가 강제 종료(패닉)되고 다음과 유사한 메시지가 해당 노드의 콘솔에 표시됩니다. 


panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

패닉이 발생한 후에 노드가 재부트되어 클러스터로 다시 결합하려고 시도할 수 있습니다. 또한 클러스터가 SPARC 기반 시스템으로 구성된 경우에는 노드가 OpenBootTM PROM(OBP) 프롬프트에 남아 있을 수 있습니다. 노드의 다음 작업은 auto-boot? 매개 변수의 설정에 따라 결정됩니다. OpenBoot PROM ok 프롬프트에서 eeprom(1M)을 사용하여 auto-boot?를 설정할 수 있습니다.

CCR(Cluster Configuration Repository)

CCR은 갱신 사항에 대해 2단계 완결 알고리즘을 사용합니다. 모든 클러스터 구성원이 성공적으로 업데이트되어야 하며 그렇지 않은 경우에는 업데이트 사항이 롤백됩니다. CCR은 클러스터 상호 연결을 사용하여 분배된 갱신 사항을 적용합니다.

주의 – 주의 –

CCR은 텍스트 파일로 구성되어 있지만 직접 CCR 파일을 편집하면 안됩니다. 각 파일에는 일관성이 유지되도록 체크섬 레코드가 포함됩니다. 수동으로 CCR 파일을 갱신하면 노드나 전체 클러스터의 기능이 정지될 수도 있습니다.

CCR은 쿼럼이 확립될 때만 클러스터가 실행되도록 하기 위해 CMM에 의존합니다. CCR은 클러스터에서 데이터 일관성을 확인해야 하는 책임을 갖고 있으므로 필요에 따라 복구를 수행하고 데이터를 갱신합니다.

전역 장치

Sun Cluster 시스템에서는 전역 장치를 사용하여 장치가 물리적으로 연결된 위치와 상관없이 어느 노드에서나 클러스터의 모든 장치로 액세스할 수 있는 클러스터 전반에 걸친 고가용성 액세스를 제공합니다. 일반적으로 전역 장치에 액세스된 상태에서 노드에 장애가 발생하면 Sun Cluster 소프트웨어는 해당 장치에 대한 다른 경로를 자동으로 검색하여 해당 경로로 액세스를 재지정합니다. Sun Cluster 전역 장치에는 디스크, CD-ROM 및 테이프가 포함됩니다. 그러나 Sun Cluster 소프트웨어에서 지원하는 멀티 포트 전역 장치는 디스크뿐입니다. 따라서 CD-ROM과 테이프 장치는 현재 고가용성 장치가 아닙니다. 각 서버의 로컬 디스크 역시 멀티 포트 상태가 아니므로 고가용성 장치가 아닙니다.

클러스터는 클러스터 내의 각 디스크, CD-ROM 및 테이프 장치에 고유 ID를 자동으로 할당합니다. 이러한 할당은 클러스터의 어떤 노드에서도 각 장치에 일관되게 액세스할 수 있게 합니다. 전역 장치 이름 공간은 /dev/global 디렉토리에 저장됩니다. 자세한 내용은 전역 이름 공간을 참조하십시오.

멀티 포트 전역 장치는 장치에 대한 한 개 이상의 경로를 제공합니다. 멀티 호스트 디스크는 둘 이상의 노드가 호스트하는 디스크 장치 그룹의 일부이므로 고가용성 멀티 호스트 디스크입니다.

장치 ID 및 DID 의사 드라이버

Sun Cluster 소프트웨어는 DID 의사 드라이브라고 알려진 구성을 통해 전역 장치를 관리합니다. 이 드라이버는 멀티 호스트 디스크, 테이프 드라이브 및 CD-ROM을 비롯하여 클러스터의 모든 장치에 고유 ID를 자동 할당할 때 사용합니다.

DID 의사 드라이버는 클러스터 전역 장치 액세스 기능의 필수 요소입니다. DID 드라이버는 클러스터의 모든 노드를 검사하여 고유한 디스크 장치 목록을 만든 다음 클러스터의 모든 노드에서 일관된 고유한 주 번호와 부 번호를 각 장치에 할당합니다. 전역 장치에 액세스할 때는 이전의 Solaris 장치 ID대신 고유한 장치 ID를 사용합니다. 예를 들어 디스크의 경우에는 c0t0d0를 사용합니다.

이러한 접근 방법을 통해 디스크에 액세스하는 모든 응용 프로그램(볼륨 관리자 또는 원시 장치를 사용하는 응용 프로그램 등)은 클러스터 전체에 걸쳐 일관된 경로를 사용하게 됩니다. 이러한 일관성은 멀티 호스트 디스크에 대해 특히 유용합니다. 각 장치의 로컬 주 번호 및 부 번호는 노드마다 다를 수 있으므로 Solaris 장치 이름지정 규칙도 변경될 수 있기 때문입니다. 예를 들어, Node1에서는 멀티 호스트 디스크를 c1t2d0으로 식별하고 Node2에서는 동일한 디스크를 완전히 다르게 c3t2d0으로 식별할 수 있습니다. DID 드라이버는 노드에서 대신 사용하는 d10 등의 전역 이름을 할당하므로 각 노드에 멀티 호스트 디스크에 대한 일관된 매핑을 제공합니다.

장치 ID는 scdidadm(1M) 및 scgdevs(1M)를 통해 업데이트 및 관리합니다. 자세한 내용은 다음의 매뉴얼 페이지를 참조하십시오.

디스크 장치 그룹

Sun Cluster 시스템에서 모든 멀티 호스트 장치는 Sun Cluster 소프트웨어로 제어되어야 합니다. 먼저 Solaris 볼륨 관리자 디스크 세트나 VERITAS Volume Manager 디스크 그룹(SPARC 기반 클러스터에서만 사용 가능) 같은 볼륨 관리자 디스크 그룹을 멀티 호스트 디스크에 만듭니다. 그런 다음에 볼륨 관리자 그룹을 디스크 장치 그룹으로 등록합니다. 디스크 장치 그룹은 전역 장치의 유형입니다. Sun Cluster 소프트웨어는 자동으로 클러스터의 각 디스크와 테이프 장치에 대한 원시 장치 그룹을 만듭니다. 그러나 사용자가 클러스터 장치 그룹을 전역 장치로 액세스할 때까지 이 클러스터 장치 그룹이 오프라인 상태를 유지합니다.

등록을 통해 특정 볼륨 관리자 디스크 그룹에 대한 경로가 있는 노드의 정보를 Sun Cluster 시스템에 제공합니다. 그러면 클러스터 전체에서 볼륨 관리자 디스크 그룹에 액세스할 수 있습니다. 둘 이상의 노드가 (마스터) 디스크 장치 그룹에 쓸 수 있으면 해당 디스크 장치 그룹에 저장된 데이터의 가용성이 높아집니다. 고가용성 디스크 장치 그룹을 사용하여 클러스터 파일 시스템을 포함시킬 수 있습니다.

주 –

디스크 장치 그룹은 자원 그룹의 영향을 받지 않습니다. 한 노드가 데이터 서비스에서 액세스하고 있는 디스크 그룹을 마스터하는 동안 다른 노드는 자원 그룹(데이터 서비스 프로세스 그룹을 지칭)을 마스터할 수 있습니다. 그러나 가장 좋은 방법은 특정 응용 프로그램 데이터를 저장하는 디스크 장치 그룹과 응용 프로그램 자원(응용 프로그램 데몬)이 들어있는 자원 그룹을 동일한 노드에 보관하는 것입니다. 디스크 장치 그룹과 자원 그룹 간의 연관에 대한 자세한 내용은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS의 Relationship Between Resource Groups and Disk Device Groups를 참조하십시오.

노드가 디스크 장치 그룹을 사용하는 경우 볼륨 관리자 디스크 그룹은 기본 디스크에 다중 경로 지원을 제공하기 때문에 “전역”이 됩니다. 멀티 호스트 디스크에 물리적으로 연결된 각 클러스터 노드는 디스크 장치 그룹에 대한 경로를 제공합니다.

디스크 장치 그룹 장애 복구

디스크 엔클로저는 여러 개의 노드에 연결되어 있으므로 그 엔클로저에 있는 모든 디스크 장치 그룹은 현재 장치 그룹을 마스터하는 노드가 실패할 경우에 대체 경로를 통해 액세스할 수 있습니다. 장치 그룹을 마스터하는 노드의 실패는 복구 및 일관성 검사를 수행하는 데 시간이 소요되는 것을 제외하고는 장치 그룹에 대한 액세스에 영향을 주지 않습니다. 이 시간 동안, 모든 요청은 시스템이 장치 그룹을 사용가능하게 할 때까지 정체됩니다(응용 프로그램에서 알 수 있음).

그림 3–1 페일오버 전후의 디스크 장치 그룹

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

멀티 포트 디스크 장치 그룹

이 절에서는 멀티 포트 디스크 구성에서 성능과 가용성의 균형을 유지할 수 있는 디스크 장치 그룹 등록 정보에 대해 설명합니다. Sun Cluster 소프트웨어는 다음과 같은 두 가지 등록 정보를 사용하여 멀티 포트 디스크 구성을 설정합니다. preferenced 및 numsecondaries. 페일오버가 발생할 경우에는 preferenced 등록 정보를 사용하여 노드에서 제어를 가정하는 순서를 제어할 수 있습니다. numsecondaries 등록 정보를 사용하여 장치 그룹에 대해 원하는 보조 노드 수를 설정합니다.

기본 노드에 장애가 발생한 경우 적절한 보조 노드를 기본 노드로 승격할 수 없으면 고가용성 서비스가 종료된 것으로 간주합니다. 서비스 페일오버가 발생하고 preferenced 등록 정보가 true이면 노드에서는 노드 목록에 지정된 순서에 따라 보조 노드를 선택합니다. 설정된 노드 목록은 노드가 기본적인 제어의 가정을 시도하거나 예비 노드에서 보조 노드로 전환하는 순서를 정의합니다. 장치 서비스의 기본 설정은 scsetup(1M) 유틸리티를 사용하여 동적으로 변경할 수 있습니다. 종속 서비스 공급자(예: 전역 파일 시스템)와 관련된 기본 설정은 장치 서비스의 기본 설정과 동일합니다.

보조 노드는 일반 작업 중에 기본 노드에 의해 검사점이 지정됩니다. 멀티 포트 디스크 구성에서 각 보조 노드의 검사점을 지정하면 클러스터 성능이 저하되고 메모리 오버헤드가 발생합니다. 예비 노드 지원을 구현하여 검사점 지정으로 발생한 성능 저하 및 메모리 오버헤드를 최소화합니다. 기본적으로 디스크 장치 그룹에는 한 개의 기본 노드와 한 개의 보조 노드가 있습니다. 사용 가능한 나머지 공급자 노드는 예비 노드가 됩니다. 페일오버가 발생하면 보조 노드가 기본 노드가 되고 노드 목록에서 우선 순위가 가장 높은 노드가 보조 노드가 됩니다.

원하는 보조 노드 수는 1부터 장치 그룹에 있는 작동 가능한 기본 공급자 노드 외의 공급자 노드 수 사이의 정수로 설정할 수 있습니다.

주 –

Solaris 볼륨 관리자를 사용하는 경우 numsecondaries 등록 정보를 기본값 이외의 수로 설정하려면 디스크 장치 그룹을 만들어야 합니다.

장치 서비스를 위한 보조 노드의 기본 개수는 1입니다. 복제본 프레임워크에서 유지 관리되는 보조 공급자의 실제 수는 원하는 수로 지정할 수 있습니다. 단, 작동 가능한 기본 공급자 외의 공급자 수가 필요한 수보다 작지 않아야 합니다. numsecondaries 등록 정보를 변경하고 구성에 추가하거나 구성에서 삭제한 경우에는 노드 목록에서 다시 확인해야 합니다. 노드 목록과 원하는 보조 노드 수를 유지 관리하면 구성된 보조 노드 수와 프레임워크에서 허용하는 실제 노드 수 간의 충돌을 방지할 수 있습니다.

전역 이름 공간

전역 장치를 활성화하는 Sun Cluster 소프트웨어 기법이 전역 이름 공간입니다. 전역 이름 공간에는 볼륨 관리자 이름 공간뿐 아니라 /dev/global/ 계층이 포함됩니다. 전역 이름 공간은 멀티 호스트 디스크와 로컬 디스크(그리고 CD-ROM 및 테이프와 같은 다른 클러스터 장치) 둘 다를 반영하며, 멀티 호스트 디스크에 대한 여러 페일오버 경로를 제공합니다. 멀티 호스트 디스크에 물리적으로 연결된 각 노드는 클러스터의 모든 노드에 대해 저장소에 대한 경로를 제공합니다.

일반적으로 Solaris Volume Manager의 볼륨 관리자 이름 공간은 /dev/md/diskset/dsk (및 rdsk) 디렉토리에 있습니다. Veritas VxVM의 경우 볼륨 관리자 이름 공간은 /dev/vx/dsk/disk-group 및 /dev/vx/rdsk/disk-group 디렉토리에 있습니다. 이러한 이름 공간은 클러스터 전체에서 가져온 각각의 Solaris 볼륨 관리자 디스크 세트 및 VxVM 디스크 그룹의 디렉토리로 구성됩니다. 각 디렉토리에는 해당 디스크 세트 또는 디스크 그룹의 메타 장치나 볼륨에 필요한 장치 노드가 들어 있습니다.

Sun Cluster 시스템에서는 로컬 볼륨 관리자 이름 공간의 각 장치 노드가 /global/.devices/node@nodeID 파일 시스템의 장치 노드에 대한 심볼릭 링크로 교체됩니다. 여기서 nodeID는 클러스터의 노드를 나타내는 정수입니다. 또한 Sun Cluster 소프트웨어는 볼륨 관리자 장치를 해당 표준 위치에 심볼릭 링크로 계속 표시합니다. 전역 이름 공간과 표준 볼륨 관리자 이름 공간 둘 다 임의의 클러스터 노드에서 사용할 수 있습니다.

전역 이름 공간의 장점은 다음과 같습니다.

로컬 및 전역 이름 공간 예제

다음 표는 멀티 호스트 디스크 c0t0d0s0에 대한 전역 이름 공간과 로컬 이름 공간 사이의 매핑입니다.

표 3–2 로컬 및 전역 이름 공간 매핑

구성 요소 또는 경로 

로컬 노드 이름 공간 

전역 이름 공간 

Solaris 논리 이름 

/dev/dsk/c0t0d0s0

/global/.devices/node@nodeID/dev/dsk/c0t0d0s0

DID 이름 

/dev/did/dsk/d0s0

/global/.devices/node@nodeID/dev/did/dsk/d0s0

Solaris 볼륨 관리자 

/dev/md/diskset/dsk/d0

/global/.devices/node@nodeID/dev/md/diskset/dsk/d0

SPARC: VERITAS Volume Manager 

/dev/vx/dsk/disk-group/v0

/global/.devices/node@nodeID/dev/vx/dsk/disk-group/v0

전역 이름 공간은 설치 시 자동으로 생성되며 재구성 부트를 실행할 때마다 갱신됩니다. scgdevs(1M) 명령을 실행하여 전역 이름 공간을 생성할 수도 있습니다.

클러스터 파일 시스템

클러스터 파일 시스템에는 다음과 같은 기능이 있습니다.

파일 시스템을 전역 장치에 mount -g 명령을 사용하여 전역으로 또는 mount 명령을 사용하여 로컬로 마운트할 수 있습니다.

클러스터의 모든 노드에서 동일한 파일 이름(예: /global/foo)을 사용하여 클러스터 파일 시스템의 파일에 액세스할 수 있습니다.

클러스터 파일 시스템은 모든 클러스터 구성원에 마운트됩니다. 클러스터 구성원의 서브세트에서 클러스터 파일 시스템을 마운트할 수 없습니다.

클러스터 파일 시스템은 별도로 구분되는 파일 시스템 형식이 아닙니다. 클라이언트는 기본 파일 시스템을 확인합니다(예: UFS).

클러스터 파일 시스템 사용

Sun Cluster 시스템에서는 모든 멀티 호스트 디스크가 디스크 장치 그룹에 포함되며 Solaris 볼륨 관리자 디스크 세트, VxVM 디스크 그룹 또는 소프트웨어 기반 볼륨 관리자의 제어를 받지 않는 개별 디스크 등이 디스크 장치 그룹이 될 수 있습니다.

클러스터 파일 시스템의 가용성을 높이려면 기본 디스크 저장소를 둘 이상의 노드에 연결해야 합니다. 따라서 클러스터 파일 시스템에 만든 로컬 파일 시스템(노드의 로컬 디스크에 저장된 파일 시스템)은 가용성이 높지 않습니다.

파일 시스템을 마운트할 때 클러스터 파일 시스템을 마운트할 수 있습니다.

주 –

Sun Cluster 소프트웨어에서 클러스터 파일 시스템에 대한 이름 지정 정책을 반드시 사용해야 하는 것은 아니지만 /global/disk-device-group과 같이 동일한 디렉토리에 모든 클러스터 파일 시스템의 마운트 지점을 만들면 관리가 쉬워집니다. 자세한 내용은 Sun Cluster 3.1 9/04 Software Collection for Solaris OS(SPARC Platform Edition) 및 Solaris OS용 Sun Cluster 시스템 관리 안내서를 참조하십시오.

HAStoragePlus 자원 유형

HAStoragePlus 자원 유형은 UFS 및 VxFS 등의 비전역 파일 시스템 구성의 가용성을 높이도록 설계되었습니다. 로컬 파일 시스템을 Sun Cluster 환경에 통합하고 파일 시스템의 가용성을 높이려면 HAStoragePlus를 사용합니다. HAStoragePlus는 Sun Cluster가 로컬 파일 시스템을 페일오버할 수 있도록 검사, 마운트 및 강제 마운트 해제와 같은 추가 파일 시스템 기능을 제공합니다. 로컬 파일 시스템이 페일오버 기능을 사용하려면 유사 스위치오버 기능이 있는 전역 디스크 그룹에 있어야 합니다.

HAStoragePlus 자원 유형의 사용 방법에 대한 자세한 내용은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS의 Enabling Highly Available Local File Systems를 참조하십시오.

HAStoragePlus는 자원과 자원이 종속된 디스크 장치 그룹의 시작을 동기화하는 데에도 사용됩니다. 자세한 내용은 자원, 자원 그룹 및 자원 유형을 참조하십시오.

Syncdir 마운트 옵션

syncdir 마운트 옵션은 UFS를 기본 파일 시스템으로 사용하는 클러스터 파일 시스템에서 사용할 수 있습니다. 그러나 syncdir을 지정하지 않으면 성능이 크게 향상됩니다. syncdir를 지정하면 쓰기는 POSIX 규격을 따르게 됩니다. syncdir를 지정하지 않으면 NFS 파일 시스템과 동일하게 작동합니다. 예를 들어 syncdir이 없으면 파일을 닫기 전까지 공간 부족 상태를 발견하지 못할 수도 있습니다. syncdir(및 POSIX 동작)이 있으면 쓰기 작업 동안 공간 부족 상태가 발견되었을 것입니다. syncdir를 지정하지 않아서 문제가 발생하는 경우는 거의 없습니다.

SPARC 기반 클러스터를 사용하는 경우 VxFS에는 UFS의 syncdir 마운트 옵션과 동일한 마운트 옵션이 없습니다. syncdir 마운트 옵션을 지정하지 않으면 VxFS가 UFS와 동일하게 작동합니다.

전역 장치 및 클러스터 파일 시스템에 대한 FAQ(자주 물어보는 질문)는 파일 시스템 FAQ를 참조하십시오.

디스크 경로 모니터링

현재 릴리스의 Sun Cluster 소프트웨어에서는 디스크 경로 모니터링(DPM)을 지원합니다. 이 절에서는 DPM, DPM 데몬, 디스크 경로 모니터링에 사용하는 관리 도구 등에 대한 개념 정보를 제공합니다. 디스크 경로 상태를 모니터, 모니터 해제 및 검사하는 방법에 대한 절차 정보는 Solaris OS용 Sun Cluster 시스템 관리 안내서를 참조하십시오.

주 –

DPM은 Sun Cluster 3.1 10/03 소프트웨어보다 먼저 릴리스된 버전을 실행하는 노드에서는 지원되지 않습니다. 순환 업그레이드가 진행되는 동안에는 DPM 명령을 사용하지 마십시오. 모든 노드를 업그레이드한 후 DPM 명령을 사용하려면 노드가 온라인 상태여야 합니다.

DPM 개요

DPM은 보조 디스크 경로 가용성을 모니터링하여 페일오버 및 전환의 전체 안정성을 향상시킵니다. scdpm 명령을 사용하여 자원이 전환되기 전에 해당 자원이 사용하는 디스크 경로의 가용성을 확인합니다. scdpm 명령과 함께 제공되는 옵션을 사용하여 클러스터의 단일 노드 또는 모든 노드에 대한 디스크 경로를 모니터할 수 있습니다. 명령줄 옵션에 대한 자세한 내용은 scdpm(1M) 설명서 페이지를 참조하십시오.

DPM 구성 요소는 SUNWscu 패키지에서 설치됩니다. SUNWscu 패키지는 표준 Sun Cluster 설치 절차에 따라 설치됩니다. 설치 인터페이스에 대한 자세한 내용은 scinstall(1M) 설명서 페이지를 참조하십시오. 다음 표에서는 DPM 구성 요소의 기본 설치 위치에 대해 설명합니다.

위치 

구성 요소 

데몬 

/usr/cluster/lib/sc/scdpmd

명령줄 인터페이스 

/usr/cluster/bin/scdpm

공유 라이브러리 

/user/cluster/lib/libscdpm.so

데몬 상태 파일(런타임으로 작성됨) 

/var/run/cluster/scdpm.status

멀티스레드 DPM 데몬이 각 노드에서 실행됩니다. DPM 데몬(scdpmd )은 노드가 부트될 때 rc.d 스크립트에 의해 시작됩니다. 문제가 발생하면 데몬이 pmfd에 의해 관리되고 자동으로 다시 시작됩니다. 다음 목록은 초기 시작 시 scdpmd가 수행되는 방식을 설명합니다.

주 –

시작 시에 각 디스크 경로의 상태는 알 수 없음으로 초기화됩니다.

  1. DPM 데몬은 이전 상태 파일이나 CCR 데이터베이스에서 디스크 경로와 노드 이름 정보를 수집합니다. CCR에 대한 자세한 내용은 CCR(Cluster Configuration Repository)을 참조하십시오. DPM 데몬이 시작된 후 데몬이 지정된 파일 이름에서 모니터링되는 디스크의 목록을 읽게 할 수 있습니다.

  2. DPM 데몬은 통신 인터페이스를 초기화하여 명령줄 인터페이스와 같이 데몬의 외부에 있는 구성 요소의 요청에 응답합니다.

  3. DPM 데몬은 scsi_inquiry 명령을 사용하여 10분마다 모니터되는 목록의 각 디스크 경로를 핑합니다. 통신 인터페이스가 수정 중인 항목의 내용에 액세스하지 못하도록 각 항목을 잠급니다.

  4. DPM 데몬은 Sun Cluster Event Framework에게 알리고 UNIX syslogd(1M) 기법을 통해 경로의 새 상태를 기록합니다.

주 –

데몬과 관련된 모든 오류는 pmfd (1M)에 의해 보고됩니다. API의 모든 함수는 성공 시 0을 반환하고 실패 시 -1을 반환합니다.

DPM 데몬은 Sun StorEdge Traffic Manager, HDLM 및 PowerPath 등의 다중 경로 드라이버를 통해 볼 수 있는 논리적 경로의 가용성을 모니터합니다. 다중 경로 드라이버는 DPM 데몬에서 개별적으로 오류를 발생하기 때문에 이 드라이버에 의해 관리되는 개별 물리 경로는 모니터되지 않습니다.

디스크 경로 모니터

이 절에서는 클러스터에서 디스크 경로를 모니터링하는 두 가지 방법을 설명합니다. 첫 번째 방법은 scdpm 명령에 의해 제공됩니다. 이 명령을 사용하여 클러스터의 디스크 경로 상태를 모니터, 모니터 해제 또는 표시합니다. 이 명령은 오류가 있는 디스크의 목록을 인쇄하고 파일에서 디스크 경로를 모니터할 때도 유용합니다.

클러스트의 디스크 경로를 모니터하는 두 번째 방법은 SunPlex Manager GUI (Graphical User Interface)에 의해 제공됩니다. SunPlex Manager는 클러스터에서 모니터되는 디스크 경로에 대한 토폴로지 뷰를 제공합니다. 이 뷰는 10분마다 업데이트되어 실패한 핑의 개수 정보를 제공합니다. SunPlex Manager GUI에 의해 제공되는 정보를 scdpm(1M) 명령과 함께 사용하여 디스크 경로를 관리합니다. SunPlex Manager에 대한 자세한 내용은 Solaris OS용 Sun Cluster 시스템 관리 안내서의 10 장, GUI를 사용한 Sun Cluster 관리를 참조하십시오.

scdpm 명령을 사용하여 디스크 경로 모니터

scdpm(1M) 명령은 다음 작업을 수행할 수 있는 DPM 관리 명령을 제공합니다.

활성 노드에서 디스크 경로 인자와 함께 scdpm(1M) 명령을 실행하여 클러스터에서 DPM 관리 작업을 수행합니다. 디스크 경로 인자는 항상 노드 이름과 디스크 이름으로 구성됩니다. 노드 이름은 필수 항목이 아니며 노드 이름을 지정하지 않은 경우 기본적으로 all로 설정됩니다. 다음 표에서는 디스크 경로에 대한 이름 지정 규약을 설명합니다.

주 –

전역 디스크 경로 이름은 전체 클러스터에 걸쳐 일관되므로 전역 디스크 경로 이름을 사용할 것을 권장합니다. UNIX 디스크 경로 이름은 전체 클러스터에 걸쳐 일관성이 없습니다. 한 디스크의 UNIX 디스크 경로는 클러스터 노드 간에 서로 다를 수 있습니다. 한 노드에서는 디스크 경로가 c1t0d0이고, 다른 노드에서는 c2t0d0이 될 수 있습니다. UNIX 디스크 경로 이름을 사용할 경우 DPM 명령을 실행하기 전에 scdidadm -L 명령을 사용하여 UNIX 디스크 경로 이름을 전역 디스크 경로 이름으로 매핑하십시오. scdidadm(1M) 설명서 페이지를 참조하십시오.

표 3–3 샘플 디스크 경로 이름

이름 유형 

샘플 디스크 경로 이름 

설명 

전역 디스크 경로 

schost-1:/dev/did/dsk/d1

schost-1 노드의 디스크 경로 d1

all:d1

클러스터에 있는 모든 노드의 d1 디스크 경로

 

UNIX 디스크 경로 

schost-1:/dev/rdsk/c0t0d0s0

schost-1 노드의 디스크 경로 c0t0d0s0

schost-1:all

schost-1 노드의 모든 디스크 경로

 

모든 디스크 경로 

all:all

클러스터에 있는 모든 노드의 모든 디스크 경로 

SunPlex Manager를 사용하여 디스크 경로 모니터

SunPlex Manager를 사용하여 다음과 같은 기본 DPM 관리 작업을 수행할 수 있습니다.

SunPlex Manager를 사용하여 디스크 경로 관리를 수행하는 절차는 SunPlex Manager 온라인 도움말을 참조하십시오.

쿼럼 및 쿼럼 장치

이 절에서는 다음 항목에 대해 설명합니다.

주 –

Sun Cluster 소프트웨어에서 쿼럼 장치로 지원하는 특정 장치 목록은 Sun 서비스 공급자에게 문의하십시오.

클러스터 노드는 데이터와 자원을 공유하기 때문에 클러스터 한 개를 동시에 활성화되는 별도 분할 영역으로 분할하면 안됩니다. 활성화된 분할 영역이 여러 개이면 데이터가 훼손될 수 있습니다. CMM(Cluster Membership Monitor)과 쿼럼 알고리즘은 클러스터 상호 연결이 분할되더라도 같은 클러스터의 한 인스턴스가 항상 운영되도록 보장합니다.

쿼럼과 CMM에 대한 소개는 Solaris OS용 Sun Cluster 개요의 클러스터 멤버쉽을 참조하십시오.

클러스터 분할 영역에서는 두 가지 유형의 문제가 발생합니다.

정보 분리는 노드 간의 클러스터 상호 연결이 끊어지고 하위 클러스터로 분할되는 경우에 발생합니다. 한 분할 영역의 노드는 다른 분할 영역의 노드와 통신할 수 없기 때문에 각 분할 영역은 자체를 유일한 분할 영역으로 “인식합니다.”

정보 유실은 클러스터가 종료된 후, 종료하기 전의 클러스터 구성 데이터를 사용하여 다시 시작할 경우에 발생합니다. 이 문제는 최근에 작동한 클러스터 분할 영역에 속하지 않은 노드에서 클러스터를 시작하면 발생할 수 있습니다.

Sun Cluster 소프트웨어는 다음 두 가지 방법으로 정보 분리 및 정보 유실을 방지합니다.

대부분의 투표를 가진 분할 영역은 쿼럼을 얻어 작동할 수 있습니다. 이러한 다수 투표 체계는 한 클러스터에 세 개 이상의 노드가 구성된 경우 정보 분리와 정보 유실을 방지합니다. 그러나, 세 개 이상의 노드가 한 클러스터에 구성되어 있을 때는 노드 투표 수를 세는 것 만으로 충분하지 않습니다. 노드가 두 개인 클러스터에서는 다수가 둘입니다. 그러한 2 노드 클러스터가 분할되는 경우 두 분할 영역 중 한 쪽에서 쿼럼을 얻으려면 외부 투표가 필요합니다. 필요한 외부 투표는 쿼럼 장치에서 제공합니다.

쿼럼 투표 수 정보

다음 정보를 확인하려면 scstat -q 명령을 사용합니다.

이 명령에 대한 자세한 내용은 scstat(1M)을 참조하십시오.

두 노드와 쿼럼 장치는 쿼럼을 형성하기 위해 클러스터에 투표를 제공합니다.

노드는 노드의 상태에 따라 투표를 제공합니다.

쿼럼 장치는 장치에 연결된 투표 수를 기준으로 투표를 제공합니다. 쿼럼 장치를 구성할 때 Sun Cluster 소프트웨어는 N-1의 투표 수를 쿼럼 장치에 할당합니다. 여기서 N은 쿼럼 장치에 연결된 투표 수입니다. 예를 들어, 투표 수가 0이 아닌 두 노드에 연결된 쿼럼 장치는 쿼럼이 1입니다(2 - 1).

쿼럼 장치가 투표를 제공하는 경우는 다음 중 하나의 조건이 충족될 때입니다.

쿼럼 장치는 Solaris OS용 Sun Cluster 시스템 관리 안내서의 5 장, 쿼럼 관리에 설명된 절차를 사용하여 클러스터 설치 중이나 이후에 구성할 수 있습니다.

장애 차단 정보

클러스터에서 가장 중요한 문제는 클러스터를 분할하는 장애(정보 분리)입니다. 정보 분리 현상이 발생하면 일부 노드에서는 통신을 할 수 없으므로 개별 노드나 일부 노드가 개별 클러스터나 하위 집합 클러스터를 형성하려고 할 수 있습니다. 각 하위 집합 또는 분할 영역은 멀티 호스트 장치를 단독으로 액세스하고 소유하고 있다고 “인식”할 수 있습니다. 여러 노드에서 디스크에 쓰기를 시도하면 데이터가 손상됩니다.

장애 차단 기능은 디스크에 대한 액세스를 물리적으로 막음으로써 멀티 호스트 장치에 대한 노드 액세스를 제한합니다. 노드가 클러스터에서 나갈 경우(실패하거나 분할되어), 실패 방지는 그 노드가 더이상 디스크에 액세스할 수 없게 만듭니다. 현재 구성원 노드들만 디스크에 대한 액세스를 갖게 되므로, 데이터 무결성이 유지됩니다.

디스크 장치 서비스는 멀티 호스트 장치를 사용하는 서비스에 대한 페일오버 기능을 제공합니다. 현재 디스크 장치 그룹의 기본 노드(소유자) 역할을 하는 클러스터 구성원에 장애가 발생하거나 연결할 수 없으면 새 기본 노드가 선택됩니다. 새 기본 노드를 사용하면 잠시 중단되었던 디스크 장치 그룹에 대한 액세스를 계속 수행할 수 있습니다. 이 프로세스 중에 기존의 기본 노드에 있는 장치에 대한 액세스 권한을 제거한 다음 새 기본 노드를 시작해야 합니다. 그러나 구성원이 클러스터에서 이탈하여 도달할 수 없게 되면 클러스터는 기본 노드였던 장치를 해제하도록 해당 노드에 알릴 수 없습니다. 그러므로 남아있는 구성원이 실패한 구성원의 전역 장치를 제어하고 액세스할 수 있도록 하는 수단이 필요합니다.

Sun Cluster 시스템은 SCSI 디스크 예약 기능을 사용하여 실패 방지를 구현합니다. SCSI 예약 기능을 사용하면 장애가 발생한 노드가 멀티 호스트 디스크에 액세스하지 못하도록 멀티 호스트 장치가 해당 노드를 “차단”합니다.

SCSI-2 디스크 예약 기능은 디스크에 연결된 모든 노드에 대한 액세스 권한을 부여하는 예약 형식을 지원합니다(예약이 없는 경우). 또한 액세스를 단일 노드로 제한합니다(예약이 있는 노드).

클러스터 상호 연결을 통해 다른 노드가 더 이상 통신할 수 없다는 것을 발견한 클러스터 구성원은 장애 차단 절차를 시작하여 다른 노드가 공유 디스크에 액세스하지 못하도록 합니다. 장애 차단이 발생하면 차단된 노드는 중단(패닉)되고 “예약 충돌” 메시지가 콘솔에 나타납니다.

노드가 더 이상 클러스터 구성원이 아닌 경우에는, 이 노드와 다른 노드가 공유하는 모든 디스크에 대한 SCSI 예약이 트리거됩니다. 차단된 노드는 차단된 사실을 “인식”하지 못할 수도 있으며, 공유 디스크 중 하나에 액세스를 시도하면 예약이 감지되어 작동이 중단(패닉)됩니다.

장애 방지를 위한 페일패스트 기법

장애가 발생한 노드가 다시 부트되어 공유 저장소에 쓰지 못하도록 하기 위하여 클러스터 프레임워크에서 사용하는 기법을 페일패스트라고 합니다.

클러스터를 구성하는 노드는 쿼럼 디스크를 포함하여 액세스할 수 있는 디스크에 대하여 특정 ioctl, MHIOCENFAILFAST를 계속 사용할 수 있도록 합니다. ioctl은 디스크 드라이버에 대한 지시어입니다. ioctl은 다른 노드에서 예약된 디스크이기 때문에 디스크에 액세스할 수 없는 경우 노드가 자체적으로 중단(패닉)할 수 있는 기능을 제공합니다.

MHIOCENFAILFAST ioctl을 사용하면 드라이브는 노드가 디스크에 대해 실행하는 모든 읽기 및 쓰기 작업에서 반환되는 오류에서 Reservation_Conflict 오류 코드를 검사합니다. ioctl은 백그라운드에서 주기적으로 디스크에 테스트 작업을 실행하여 Reservation_Conflict 오류 코드를 검사합니다. Reservation_Conflict 오류 코드가 반환되면 포그라운드 및 백그라운드 제어 흐름 경로가 모두 중단됩니다.

SCSI-2 디스크의 경우에는 예약이 지속되지 않습니다. 즉, 노드를 재부트하면 예약이 취소됩니다. PGR (Persistent Group Reservation)이 있는 SCSI-3 디스크의 경우에는 예약 정보가 디스크에 저장되어 노드를 재부트한 후에도 유지됩니다. 페일패스트 기법은 SCSI-2 디스크를 사용했는지 또는 SCSI-3 디스크를 사용했는지 여부에 관계없이 동일하게 작동합니다.

노드가 클러스터의 다른 노드와 연결이 끊어지고 쿼럼을 채울 수 있는 분할 영역에 포함되지 않은 경우에는 다른 노드에 의해 강제로 클러스터에서 제거됩니다. 분할 영역에 포함되고 쿼럼을 채울 수 있는 또 다른 노드가 공유 디스크를 예약할 수 있습니다. 쿼럼이 없는 노드에서 공유 디스크에 액세스를 시도하면 페일패스트 기법이 작동하여 예약 충돌이 발생하고 시스템이 중단(패닉)됩니다.

패닉 후에는 노드가 재부트되어 클러스터에 다시 연결될 수도 있고, 클러스터가 SPARC 기반 시스템으로 구성된 경우에는 OpenBootTM PROM (OBP) 프롬프트가 표시될 수도 있습니다. auto-boot? 매개 변수 설정에 따라 수행할 작업이 결정됩니다. SPARC 기반 클러스터의 OpenBoot PROM ok 프롬프트에서 eeprom(1M)을 사용하여auto-boot?를 설정할 수 있습니다. 또한 x86 기반 클러스터에서는 이 매개 변수를 BIOS가 부트된 후에 선택적으로 실행하는 SCSI 유틸리티를 사용하여 설정할 수 있습니다.

쿼럼 구성 정보

다음 목록에는 쿼럼 구성에 대한 정보가 포함되어 있습니다.

피해야 하는 쿼럼 구성에 대한 예는 바람직하지 않은 쿼럼 구성을 참조하십시오. 권장되는 쿼럼 구성에 대한 예는 권장되는 쿼럼 구성을 참조하십시오.

쿼럼 장치 요구 사항 준수

다음 요구 사항을 준수해야 합니다. 이 요구 사항을 무시하면 클러스터의 가용성이 손상될 수 있습니다.

피해야 하는 쿼럼 구성에 대한 예는 바람직하지 않은 쿼럼 구성을 참조하십시오. 권장되는 쿼럼 구성에 대한 예는 권장되는 쿼럼 구성을 참조하십시오.

쿼럼 장치 모범 사례 준수

다음 정보를 사용하여 토폴로지에 가장 적합한 쿼럼 구성을 평가합니다.

문제를 피해가는 쿼럼 구성에 대한 예는 바람직하지 않은 쿼럼 구성을 참조하십시오. 권장되는 쿼럼 구성에 대한 예는 권장되는 쿼럼 구성을 참조하십시오.

권장되는 쿼럼 구성

이 절에서는 권장되는 쿼럼 구성에 대한 예를 보여줍니다. 피해야 하는 쿼럼 구성에 대한 예는 바람직하지 않은 쿼럼 구성을 참조하십시오.

2–노드 구성 쿼럼

2 노드 클러스터를 형성하려면 두 개의 쿼럼 투표가 필요합니다. 두 개의 투표는 두 개의 클러스터 노드 또는 한 개의 노드와 한 개의 쿼럼 장치에서만 얻을 수 있습니다.

그림 3–2 2–노드 구성

그림: 하나의 쿼럼 장치를 두 노드에 연결한 노드 A와 노드 B를 보여줍니다.

세 개 이상의 노드로 구성된 쿼럼

세 개 이상의 노드로 구성된 클러스터는 쿼럼 장치 없이 구성할 수 있습니다. 그러나 이렇게 구성하면 클러스터에서 대부분의 노드 없이 클러스터를 시작할 수 없습니다.

그림: 구성1: NodeA-D. A/B는 (->) QD1에 연결. C/D -> QD2. 구성2: NodeA-C. A/C -> QD1. B/C -> QD2. 구성3: NodeA-C -> 한 개의 QD.

비전형적인 쿼럼 구성

그림 3–3에서는 노드 A 및 노드 B에서 업무에 필수적인 응용 프로그램(예: Oracle 데이터베이스)을 실행하고 있다고 가정합니다. 노드 A와 노드 B를 사용할 수 없고 공유 데이터에 액세스할 수 없는 경우 전체 클러스터를 다운시키는 것을 원할 수 있습니다. 그렇지 않은 경우 이 구성은 고가용성을 제공하지 않기 때문에 최적의 구성이 아닙니다.

이러한 예외 사항과 관련된 모범 사례에 대한 자세한 내용은 쿼럼 장치 모범 사례 준수를 참조하십시오.

그림 3–3 비전형적 구성

그림: 노드 A-D. 노드 A/B는 QD1-4에 연결. 노드 C는 QD4에 연결. 노드 D는 QD4에 연결. 총 투표 수 = 10. 쿼럼을 위해 필요한 투표 수 = 6.

바람직하지 않은 쿼럼 구성

이 절에서는 피해야 하는 쿼럼 구성에 대한 예를 보여줍니다. 권장되는 쿼럼 구성에 대한 예는 권장되는 쿼럼 구성을 참조하십시오.

그림: 구성1: NodeA-B. A/B -> QD1/2. 구성2: NodeA-D. A/B -> QD1/2. 구성3: NodeA-C. A/B-> QD1/2 & C -> QD2.

데이터 서비스

데이터 서비스는 Sun Java System Web Server 또는 Oracle과 같이 단일 서버가 아닌 클러스터에서 실행되도록 구성된 응용 프로그램을 가리키는 용어입니다. 데이터 서비스는 응용 프로그램, 특수 Sun Cluster 구성 파일 및 다음과 같은 응용 프로그램 작업을 제어하는 Sun Cluster 관리 메소드 등으로 구성됩니다.

데이터 서비스 유형에 대한 자세한 내용은 Solaris OS용 Sun Cluster 개요의 데이터 서비스를 참조하십시오.

그림 3–4 에서는 단일 응용 프로그램 서버에서 실행되는 응용 프로그램(단일 서버 모델)과 클러스터에서 실행 중인 동일한 응용 프로그램(클러스터 서버 모델)을 비교합니다. 두 구성 간의 유일한 차이점은 클러스터 응용 프로그램이 보다 빠르게 실행되고 가용성이 더 높다는 점입니다.

그림 3–4 표준 대 클러스터 클라이언트 서버 구성

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

단일 서버 모델에서는 특정의 공용 네트워크 인터페이스(호스트 이름)를 통해 서버에 액세스하도록 응용 프로그램을 구성합니다. 따라서 호스트 이름이 물리적 서버와 연결됩니다.

클러스터 서버 모델에서 공용 네트워크 인터페이스는 논리 호스트 이름 또는 공유 주소입니다. 네트워크 자원이라는 용어는 논리 호스트 이름과 공유 주소를 모두 가리킬 때 사용합니다.

일부 데이터 서비스에서는 논리 호스트 이름이나 공유 주소를 네트워크 인터페이스로 지정해야 합니다. 논리 호스트 이름과 공유 주소는 서로 호환되지 않습니다. 그 외의 데이터 서비스에서는 논리 호스트 이름이나 공유 주소를 지정할 수 있습니다. 지정해야 하는 인터페이스 유형에 대한 자세한 내용은 각 데이터 서비스의 설치 및 구성을 참조하십시오.

네트워크 자원이 특정의 물리적 서버에 연결되어 있지 않습니다. 네트워크 자원은 물리적 서버 간에 마이그레이션할 수 있습니다.

네트워크 자원은 먼저 기본 노드에 연결됩니다. 기본 노드에 장애가 발생하면 네트워크 자원과 응용 프로그램 자원을 다른 클러스터 노드(보조 노드)로 페일오버합니다. 네트워크 자원이 페일오버하면 잠시 지연된 후에 응용 프로그램 자원이 보조 노드에서 계속 실행됩니다.

그림 3–5에서는 단일 서버 모델과 클러스터 서버 모델을 비교합니다. 클러스터 서버 모델에서는 네트워크 자원(이 예에서는 논리 호스트 이름)이 둘 이상의 클러스터 노드 사이에 이동할 수 있습니다. 응용 프로그램은 특정 서버와 연결된 호스트 이름 대신 논리 호스트 이름을 사용하도록 구성됩니다.

그림 3–5 고정 호스트 이름과 논리 호스트 이름 비교

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

공유 주소 역시 처음에는 한 개의 노드에 연결됩니다. 이 노드를 GIN(Global Interface Node)이라고 합니다. 공유 주소(일명 전역 인터페이스)는 클러스터에 대한 단일 네트워크 인터페이스로 사용됩니다.

논리 호스트 이름 모델과 확장 가능한 서비스 모델 간의 차이점은 확장 가능한 서비스 모델에는 각 노드에도 루프백 인터페이스에 활성 상태로 구성된 공유 주소가 있다는 것입니다. 이러한 구성에서는 데이터 서비스의 여러 인스턴스를 여러 노드에서 동시에 활성화할 수 있습니다. “확장 가능 서비스”는 클러스터 노드를 추가하여 응용 프로그램에 CPU 기능을 추가하는 방법으로 성능을 확장할 수 있는 기능입니다.

GIF 노드에 장애가 발생하면 응용 프로그램 인스턴스를 실행하는 다른 노드에서 공유 주소를 시작하고 변경한 노드를 새 GIF 노드로 만들 수 있습니다. 아니면 이전에 응용 프로그램을 실행하지 않던 다른 클러스터 노드로 페일오버할 수 있습니다.

그림 3–6에서는 단일 서버 구성과 확장 가능한 클러스터 서비스 구성을 비교합니다. 확장 가능한 서비스 구성에서는 모든 노드에 대한 공유 주소가 있습니다. 페일오버 데이터 서비스에 논리 호스트 이름을 사용하는 방법과 유사한 방법으로 특정 서버와 연결된 호스트 이름 대신 이 공유 주소를 사용하도록 응용 프로그램이 구성됩니다.

그림 3–6 고정 호스트 이름과 공유 주소 비교

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

데이터 서비스 메소드

Sun Cluster 소프트웨어는 일련의 서비스 관리 메소드를 제공합니다. 이 메소드는 Resource Group Manager(RGM)의 제어에 따라 실행되어 클러스터 노드의 응용 프로그램을 시작하고 중지하고 모니터합니다. 이 메소드는 클러스터 프레임워크 소프트웨어, 멀티 호스트 장치와 함께 사용하여 응용 프로그램이 페일오버 또는 확장 가능 데이터 서비스가 되도록 합니다.

또한 RGM은 응용 프로그램의 인스턴스와 네트워크 자원(논리 호스트이름 및 공유 주소)과 같은 클러스터 내의 자원도 관리합니다.

Sun Cluster 소프트웨어에서 제공하는 메소드 외에 Sun Cluster 시스템에서도 API와 여러 가지 데이터 서비스 개발 도구를 제공합니다. 응용 프로그램 개발자는 이 도구를 사용하여 다른 응용 프로그램을 Sun Cluster 소프트웨어에서 가용성이 높은 데이터 서비스로 실행시키는 데이터 서비스 메소드를 개발할 수 있습니다.

페일오버 데이터 서비스

데이터 서비스가 실행되는 노드가 실패할 경우, 서비스는 사용자 간섭 없이 다른 작업 노드로 이주됩니다. 페일오버 서비스는 페일오버 자원 그룹을 사용합니다. 이 자원 그룹은 응용 프로그램 인스턴스 자원 및 네트워크 자원(논리 호스트 이름)을 위한 컨테이너입니다. 논리 호스트 이름은 하나의 노드에서 구성될 수 있는 IP 주소로, 나중에 기존 노드는 자동으로 구성이 중지되고 다른 노드에서 구성이 시작됩니다.

페일오버 데이터 서비스의 경우, 응용 프로그램 인스턴스는 단일 노드에서만 실행됩니다. 오류 모니터가 오류를 감지하면 동일한 노드에서 인스턴스를 다시 시작하거나 다른 노드에서 인스턴스를 시작하려고 시도합니다(페일오버). 데이터 서비스가 구성되는 방법에 따라 결과가 달라집니다.

확장 가능 데이터 서비스

확장 가능 데이터 서비스는 여러 노드에서 인스턴스가 사용되고 있을 가능성을 수반합니다. 확장 가능 서비스에서는 다음 두 가지의 자원 그룹을 사용합니다.

확장 가능 자원 그룹은 여러 노드에서 온라인 상태로 있을 수 있으므로 서비스의 여러 인스턴스가 한 번에 실행될 수 있습니다. 공유 주소를 호스트하는 페일오버 자원 그룹은 한 번에 한 노드에서만 온라인 상태입니다. 확장 가능 서비스를 호스트하는 모든 노드는 동일한 공유 주소를 사용하여 서비스를 호스트합니다.

서비스 요청은 단일 네트워크 인터페이스(전역 인터페이스)를 통해 클러스터에 보내집니다. 이러한 요청은 로드 균형 조정 정책에 따라 설정한 몇 가지 사전 정의 알고리즘 중 하나를 기준으로 각 노드에 분산됩니다. 클러스터는 로드 균형 조정 정책을 사용하여 몇몇 노드 사이의 서비스 부하 균형을 맞추는 로드 균형 조정 정책을 사용할 수 있습니다. 서로 다른 공유 주소를 호스트하는 노드에는 전역 인터페이스가 여러 개 있을 수 있습니다.

확장 가능 서비스의 경우 응용 프로그램 인스턴스는 여러 노드에서 동시에 실행됩니다. 전역 인터페이스를 호스트하는 노드가 실패할 경우, 전역 인터페이스는 다른 노드로 페일오버합니다. 실행 중인 응용 프로그램 인스턴스가 실패할 경우, 인스턴스는 동일한 노드에서 다시 시작하려고 시도합니다.

응용 프로그램 인스턴스는 동일한 노드에서 재시작될 수 없으며, 사용되지 않는 다른 노드는 서비스를 실행하도록 구성된 경우, 서비스는 사용되지 않는 노드로 페일오버됩니다. 그렇지 않은 경우에는 나머지 노드에서 서비스가 계속 실행되므로 서비스 처리 능력이 저하될 수 있습니다.

주 –

각 응용 프로그램 인스턴스에 대한 TCP 상태는 GIF 노드가 아니라 인스턴스가 있는 노드에 보존됩니다. 그러므로 GIF 노드의 실패는 연결에 영향을 주지 않습니다.

그림 3–7에서는 페일오버 자원 그룹 및 확장 가능 자원 그룹과, 확장 가능 서비스에 대한 이 둘 사이의 종속성에 대한 예를 보여줍니다. 이 예에는 세 가지 자원 그룹이 있습니다. 페일오버 자원 그룹에는 고가용성 DNS에 대한 응용 프로그램 자원과 고가용성 DNS 및 고가용성 Apache Web Server(SPARC 기반 클러스터 전용)에서 사용하는 응용 프로그램 자원이 포함됩니다. 확장 가능 자원 그룹에는 Apache Web Server의 응용 프로그램 인스턴스만 포함됩니다. 확장 가능 자원 그룹과 페일오버 자원 그룹 간에는 자원 그룹 종속성이 존재합니다(실선). 또한 모든 Apache 응용 프로그램 자원은 공유 주소인 네트워크 자원 schost-2에 종속됩니다(실선).

그림 3–7 SPARC: 페일오버 및 확장 가능 자원 그룹의 예

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

로드 균형 조정 정책

로드 균형 조정은 응답 시간과 처리량의 두 가지 측면 모두에서 확장 가능 서비스의 성능을 향상시킵니다. 확장 가능 데이터 서비스에는 두 가지 클래스가 있습니다.

pure 서비스에서는 모든 인스턴스가 클라이언트의 요청에 응답할 수 있습니다. sticky 서비스에서는 클라이언트가 동일한 인스턴스에 요청을 보낼 수 있습니다. 그러한 요청은 다른 인스턴스에 보내지 않아도 됩니다.

pure 서비스는 가중된 로드 균형 조정 정책을 사용합니다. 이 로드 균형 조정 정책에서 클라이언트 요청은 기본적으로 클러스터의 서버 인스턴스에서 일정하게 분산됩니다. 예를 들어 3-노드 클러스터에서 각 노드의 가중치가 1이라고 가정합니다. 각 노드는 해당 서비스대신 클라이언트의 요청 중 1/3을 처리합니다. 관리자는 scrgadm(1M) 명령 인터페이스 또는 SunPlex Manager GUI를 통해 언제든지 가중치를 변경할 수 있습니다.

Sticky 서비스에는 일반 sticky와 와일드카드 sticky라는 두 가지 종류가 있습니다. Sticky 서비스를 사용하면 여러 TCP 연결을 통해 동시 응용 프로그램 수준 세션에서 in-state 메모리(응용 프로그램 세션 상태)를 공유할 수 있습니다.

일반 sticky 서비스를 사용하면 클라이언트가 여러 개의 동시 TCP 연결 간에 상태를 공유할 수 있습니다. 클라이언트는 단일 포트를 수신하는 서버 인스턴스에 대해 “sticky”라고 합니다. 해당 서버 인스턴스가 활성 상태이고 액세스 가능하며, 서비스가 온라인 상태인 동안 로드 균형 조정 정책이 변경되지 않는 경우 클라이언트의 모든 요청은 동일한 서버 인스턴스로 가도록 보장됩니다.

예를 들어 클라이언트의 웹 브라우저는 세 개의 서로 다른 TCP 연결을 사용하여 포트 80의 공유 IP 주소로 연결됩니다. 그러나 이들 연결 간에 서비스에서 캐시된 세션 정보가 교환됩니다.

sticky 정책을 일반화하면 동일한 인스턴스에서 백그라운드로 세션 정보를 교환하는 여러 확장 가능 서비스까지 범위를 확장할 수 있습니다. 이러한 서비스가 세션 정보를 동일한 인스턴스에서 백그라운드로 교환할 때 클라이언트는 서로 다른 포트를 수신하는 동일한 노드의 여러 서버 인스턴스에 대해 “sticky”라고 합니다. .

예를 들어, 전자 상거래 사이트에서 고객이 장바구니에 상품을 채울 때는 포트 80에서 HTTP를 사용하지만 고객이 장바구니의 상품 대금을 신용 카드로 지불하기 위해 보안 데이터를 보낼 때는 포트 443에서 SSL로 전환합니다.

와일드 카드 sticky 서비스는 동적으로 할당된 포트 번호를 사용하지만 클라이언트 요청은 여전히 동일한 노드로 전달합니다. 클라이언트는 IP 주소가 동일한 포트에 대해 “sticky 와일드 카드”입니다.

이 정책의 좋은 예는 수동 모드 FTP입니다. 예를 들어, 클라이언트가 포트 21의 FTP 서버에 연결되면 서버에서 해당 클라이언트를 동적 포트 범위에 있는 수신 포트 서버로 다시 연결하라는 지시를 내보냅니다. 이 IP 주소에 대한 모든 요청동일한 노드로 전달됩니다. 서버에서 제어 정보를 통해 클라이언트에게 알립니다. .

이러한 각 sticky 정책마다 가중치가 적용된 로드 균형 조정 정책이 기본값으로 사용됩니다. 따라서, 클라이언트의 초기 요청은 로드 균형 조정기에서 지정한 인스턴스로 보내집니다. 클라이언트가 인스턴스를 실행 중인 노드에 대해 유사성을 설정한 이후에 들어온 요청은 조건에 따라 해당 인스턴스로 보내집니다. 노드에 액세스할 수 있어야 하며 로드 균형 조정 정책은 변경되지 않아야 합니다.

특정 로드 균형 조정 정책에 대한 추가 세부 정보는 다음과 같습니다.

페일백 설정

자원 그룹은 한 노드에서 다른 노드로 페일오버됩니다. 페일오버가 발생하면 기존의 보조 노드가 새 기본 노드가 됩니다. 페일백 설정은 기존의 기본 노드가 다시 온라인 상태가 될 때 발생할 작업을 지정합니다. 기존 기본 노드가 다시 기본 노드가 되는 페일백 옵션 또는 현재 기본 노드를 그대로 유지하는 옵션이 있습니다. Failback 자원 그룹 등록 정보 설정을 사용하여 원하는 옵션을 지정합니다.

자원 그룹을 호스트하는 기존 노드에서 장애가 발생하고 재부트되는 일이 반복될 때 페일백을 설정하면 자원 그룹의 가용성이 감소될 수 있습니다.

데이터 서비스 결함 모니터

각 Sun Cluster 데이터 서비스는 정기적으로 데이터 서비스를 규명하여 상태를 판별하는 오류 모니터를 제공합니다. 오류 모니터는 응용 프로그램 데몬이 실행 중인지 그리고 클라이언트 서비스가 제공되고 있는지 확인합니다. 프로브에 의해 반환된 정보를 기초로 데몬을 다시 시작하거나 페일오버를 야기하는 것과 같은 사전에 정의된 조치가 시작될 수 있습니다.

새로운 데이터 서비스 개발

Sun에서는 클러스터에서 여러 응용 프로그램이 페일오버 또는 확장 가능한 서비스로 작동하도록 할 수 있는 구성 파일과 관리 메소드 템플리트를 제공합니다. Sun에서 페일오버나 확장 가능 서비스로 실행할 응용 프로그램을 제공하지 않는 경우에는 다른 대안이 있습니다. Sun Cluster API 또는 DSET API를 사용하여 페일오버나 확장 가능 서비스로 실행할 응용 프로그램을 구성합니다. 그러나 모든 응용 프로그램이 확장 가능 서비스가 될 수 있는 것은 아닙니다.

확장 가능 서비스의 특성

응용 프로그램이 확장 가능 서비스가 될 수 있는지 여부는 일련의 기준에 따라 결정됩니다. 응용 프로그램이 확장 가능 서비스가 될 수 있는지를 결정하려면 Solaris OS용 Sun Cluster 데이터 서비스 개발 안내서의 응용 프로그램 적합성 분석를 참조하십시오. 일련의 기준을 요약하면 다음과 같습니다.

Data Service API 및 Data Service Development Library API

Sun Cluster 시스템에서는 응용 프로그램의 가용성을 높이기 위해 다음과 같은 기능을 제공합니다.

Sun Cluster 시스템에서 제공하는 데이터 서비스를 설치하고 구성하는 방법에 대해서는 Sun Cluster Data Services Planning and Administration Guide for Solaris OS를 참조하십시오. Sun Cluster 3.1 9/04 Software Collection for Solaris OS(SPARC Platform Edition)에서는 Sun Cluster 프레임워크에서 다른 응용 프로그램의 가용성을 높이는 방법에 대해 설명합니다.

응용 프로그램 개발자는 Sun Cluster API를 사용하여 데이터 서비스 인스턴스를 시작하고 중지하는 스크립트와 오류 모니터를 개발할 수 있습니다. 이러한 도구를 사용하여 응용 프로그램은 페일오버 또는 확장 가능 데이터 서비스로 구현될 수 있습니다. Sun Cluster 시스템에서는 “일반적인” 데이터 서비스를 제공합니다. 이러한 일반적인 데이터 서비스는 응용 프로그램이 요구하는 시작과 중지 메소드를 신속하게 생성하여 데이터 서비스를 페일오버나 확장 가능 서비스로 구현하는 데 사용됩니다.

데이터 서비스 트래픽을 위한 클러스터 상호 연결 사용

클러스터에는 클러스터 상호 연결을 형성하는 노드 간 여러 네트워크 연결이 있어야 합니다. Sun Cluster 소프트웨어는 여러 개의 상호 연결을 사용하여 다음과 같은 목적을 달성합니다.

내부 트래픽(예: 파일 시스템 데이터 또는 확장 가능 서비스 데이터)의 경우에는 메시지가 사용 가능한 모든 상호 연결을 통해 라운드 로빈 방식으로 스트라이프됩니다. 클러스터 상호 연결은 노드 사이의 고가용 통신을 위해 응용 프로그램에도 사용 가능합니다. 예를 들어, 분산 응용 프로그램에는 통신을 필요로 하는 다른 노드에서 실행하는 구성 요소가 있을 수 있습니다. 공용 상호 연결이 아닌 클러스터 상호 연결을 사용하여, 이 연결은 각 링크에 대한 실패로부터 안전합니다.

노드 간 통신을 위해 클러스터 상호 연결을 사용하려면 응용 프로그램에서 Sun Cluster 설치 시 구성된 개인 호스트 이름을 사용해야 합니다. 예를 들어, node 1에 대한 개인 호스트 이름이 clusternode1-priv이면 클러스터 상호 연결을 통해 node 1과 통신할 때 이 이름을 사용합니다. 이 이름을 사용하여 열리는 TCP 소켓은 클러스터 상호 연결을 통해 라우트되며 네트워크 장애가 발생하더라도 투명하게 다시 라우트될 수 있습니다.

개인 호스트 이름은 Sun Cluster 설치 시 구성할 수 있으므로 클러스터 상호 연결에서는 그 당시에 선택한 이름을 사용합니다. 실제 이름을 결정하려면 scha_cluster_get(3HA)명령을 scha_privatelink_hostname_node 인수와 함께 사용합니다.

응용 프로그램 통신과 내부 클러스터 통신은 모든 상호 연결을 통해 스트라이프됩니다. 응용 프로그램은 내부 클러스터 트래픽과 클러스터 상호 연결을 공유하므로 응용 프로그램이 사용할 수 있는 대역폭은 다른 클러스터 트래픽에서 사용하는 대역폭에 따라 달라집니다. 장애가 발생하면 내부 트래픽과 응용 프로그램 트래픽은 사용 가능한 모든 상호 연결을 통해 스트라이프됩니다.

각 노드에는 고정 pernode 주소도 할당됩니다. 이 pernode 주소는 clprivnet 드라이버로 연결됩니다. IP 주소는 다음 노드의 개인 호스트 이름에 매핑됩니다. clusternode1-priv. Sun Cluster 개인 네트워크 드라이버에 대한 자세한 내용은 clprivnet(7) 설명서 페이지를 참조하십시오.

응용 프로그램이 모든 지점에서 일관된 IP 주소를 필요로 하면 클라이언트와 서버측 모두에서 pernode 주소에 바인드하도록 응용 프로그램을 구성합니다. 이렇게 하면 모든 연결이 pernode 주소에서 시작되어 다시 돌아가는 것으로 보입니다.

자원, 자원 그룹 및 자원 유형

데이터 서비스는 여러 가지 유형의 자원을 사용합니다. Apache 웹 서버나 Sun Java System Web Server와 같은 응용 프로그램은 해당 응용 프로그램이 종속된 네트워크 주소(논리 호스트 이름 및 공유 주소)를 사용합니다. 응용 프로그램과 네트워크 자원이 RGM에 의해 관리되는 기본 단위를 구성합니다.

데이터 서비스는 자원 유형입니다. 예를 들어, Sun Cluster HA for Oracle는 SUNW.oracle-server 자원 유형이고 Sun Cluster HA for Apache는 SUNW.apache 자원 유형입니다.

자원은 전체 클러스터에서 정의된 자원 유형을 인스턴스화한 것입니다. 여러 자원 유형이 정의됩니다.

네트워크 자원은 SUNW.LogicalHostname 또는 SUNW.SharedAddress 자원 유형입니다. 이 두 가지 자원 유형은 Sun Cluster 소프트웨어에 의해 사전 등록됩니다.

HAStorage 및 HAStoragePlus 자원 유형은 자원이 종속된 디스크 장치 그룹과 자원의 시작을 동기화하는 데 사용됩니다. 이 자원 유형은 데이터 서비스를 시작하기 전에 클러스터 파일 시스템 마운트 지점, 전역 장치 및 장치 그룹 이름에 대한 경로를 사용할 수 있는지를 확인합니다. 자세한 내용은 Data Services Installation and Configuration Guide의 “Synchronizing the Startups Between Resource Groups and Disk Device Groups”를 참조하십시오. Sun Cluster 3.0 5/02 업데이트에서는 HAStoragePlus 자원 유형을 사용할 수 있고 로컬 파일 시스템의 가용성을 높혀주는 다른 기능이 추가되었습니다. 이 기능에 대한 자세한 내용은 HAStoragePlus 자원 유형을 참조하십시오.

RGM이 관리하는 자원은 자원 그룹이라는 그룹에 포함되므로 하나의 단위로 관리할 수 있습니다. 자원 그룹에 대하여 페일오버나 전환이 시작될 때 자원 그룹은 하나의 단위로 이동됩니다.

주 –

응용 프로그램 자원이 포함된 자원 그룹을 온라인으로 전환하면 해당 응용 프로그램이 시작됩니다. 데이터 서비스 시작 메소드는 응용 프로그램이 실행될 때까지 대기했다가 성공적으로 종료됩니다. 데이터 서비스 오류 모니터에서 데이터 서비스가 클라이언트에 서비스를 제공하는 것을 결정하는 것과 동일한 방법으로 응용 프로그램이 시작되어 실행되는 시기가 결정됩니다. 이 프로세스에 대한 자세한 내용은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS를 참조하십시오.

Resource Group Manager (RGM)

RGM은 데이터 서비스(응용 프로그램)을 자원 유형으로 구현하여 자원으로 관리합니다. 이 구현은 Sun에서 제공되거나 개발자가 일반 데이터 서비스 템플리트, 데이터 서비스 개발 라이브러리(DSDL API) 또는 자원 관리 API (RMAPI)를 사용하여 작성합니다. 클러스터 관리자는 자원 그룹이라는 컨테이너에 자원을 만들고 관리합니다. RGM은 클러스터 구성원 변경에 대한 응답으로 선택된 노드에서 자원을 정지하였다가 시작합니다.

RGM은 자원과 자원 그룹을 대상으로 작업을 합니다. RGM 작업을 수행하면 자원과 자원 그룹의 상태가 온라인과 오프라인 상태로 전환됩니다. 자원 및 자원 그룹에 적용할 수 있는 상태 및 설정에 대한 자세한 내용은 자원 및 자원 그룹의 상태와 설정 절을 참조하십시오.

RGM이 제어하는 환경에서 Solaris 프로젝트를 시작하는 방법에 대한 자세한 내용은 데이터 서비스 프로젝트 구성을 참조하십시오.

자원 및 자원 그룹의 상태와 설정

관리자는 자원과 자원 그룹에 정적 설정을 적용합니다. 이 설정은 관리 작업을 통해서만 변경될 수 있습니다. RGM은 동적 “상태” 간에 자원 그룹을 전환합니다. 이 설정과 상태는 다음 목록에서 자세히 설명합니다.

자원 및 자원 그룹 등록 정보

Sun Cluster 데이터 서비스에 대해 자원 및 자원 그룹의 등록 정보 값을 구성할 수 있습니다. 표준 속성은 모든 데이터 서비스에 공통입니다. Extension 속성은 각 데이터 서비스에만 적용됩니다. 일부 표준 및 확장 등록 정보는 수정하지 않아도 되도록 기본 설정으로 구성됩니다. 다른 등록 정보들은 자원 작성 및 구성 프로세스의 일부로 설정해야 합니다. 각 데이터 서비스에 대한 설명서에서는 설정할 수 있는 자원 등록 정보와 설정 방법을 지정합니다.

표준 등록 정보는 보통 특정 데이터 서비스와 독립적인 자원 및 자원 그룹 등록 정보를 구성하는데 사용됩니다. 표준 등록 정보 집합에 대한 내용은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS의 부록 A, Standard Properties를 참조하십시오.

RGM 확장 등록 정보는 응용 프로그램 바이너리 위치, 구성 파일 등과 같은 정보를 제공합니다. 사용하는 데이터 서비스를 구성하는 것처럼 확장 등록 정보를 수정할 수 있습니다. 확장 등록 정보에 대한 설명은 각 데이터 서비스 설명서를 참조하십시오.

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

데이터 서비스는 RGM을 사용하여 온라인으로 전환할 때 Solaris 프로젝트 이름으로 시작하도록 구성할 수 있습니다. 구성은 RGM에 의해 관리되는 자원 또는 자원 그룹을 Solaris 프로젝트 ID와 연결합니다. 자원이나 자원 그룹을 프로젝트 ID로 매핑하면 Solaris 운영 체제에서 사용할 수 있는 정교한 제어 기능을 사용하여 클러스터 내의 작업 로드 및 사용량을 관리할 수 있습니다.

주 –

이러한 구성을 수행하려면 Solaris 9 이상에서 현재 릴리스의 Sun Cluster 소프트웨어를 실행해야 합니다.

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

주 –

이 기능에 대한 Solaris 설명서에서는 CPU 시간, 프로세스, 작업 및 이와 유사한 구성 요소를 “자원”으로 설명합니다. 한편, Sun Cluster 설명서에서는 “자원”을 RGM의 제어를 받는 항목을 설명하는 용어로 사용합니다. 다음 절에서는 “자원”을 RGM의 제어를 받는 Sun Cluster 항목을 일컫는 용어로 사용합니다. “제공 항목”은 CPU 시간, 프로세스 및 작업을 일컫는 용어로 사용합니다.

이 절에서는 지정된 Solaris 9 project(4)에서 프로세스를 시작하도록 데이터 서비스를 구성하는 방법에 대한 개념을 설명합니다. 또한 Solaris 운영 체제가 제공하는 관리 기능을 사용하도록 설계된 여러 페일오버 시나리오와 제안에 대해서도 설명합니다.

관리 기능의 개념 및 절차에 대한 자세한 내용은 System Administration Guide: Network Services의 1 장, Network Service (Overview)를 참조하십시오.

클러스터에서 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의 부록 A, Standard Properties를 참조하십시오. 등록 정보에 대한 설명은 r_properties(5) 및 rg_properties(5)를 참조하십시오.

지정된 프로젝트 이름은 프로젝트 데이터베이스(/etc/project)에 있어야 하며 루트 사용자는 명명된 프로젝트의 구성원으로 구성해야 합니다. 프로젝트 이름 데이터베이스에 대한 개념 정보는 System Administration Guide: Solaris Containers-Resource Management and Solaris Zones의 2 장, Projects and Tasks (Overview)를 참조하십시오. 프로젝트 파일 구문에 대한 설명은 project(4)를 참조하십시오.

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

주 –

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

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

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

Sun Cluster 환경에서 Solaris가 제공하는 컨트롤을 사용하도록 데이터 서비스를 구성하기 전에 스위치오버 또는 페일오버의 전 과정에 걸쳐 자원을 제어하고 추적하는 방법을 결정해야 합니다. 새 프로젝트를 구성하기 전에 클러스터 내의 종속성을 식별합니다. 예를 들어, 자원과 자원 그룹은 디스크 장치 그룹에 종속합니다.

scrgadm(1M)을 사용하여 구성한 nodelist, failback, maximum_primaries 및 desired_primaries 자원 그룹 등록 정보를 사용하여 자원 그룹의 노드 목록 우선 순위를 식별합니다.

디스크 장치 그룹 노드 목록 우선 순위를 결정하려면 scrgadm(1M) 및 scsetup(1M)을 사용하여 구성한 preferenced 등록 정보와 failback 등록 정보를 사용합니다.

모든 클러스터 노드를 동일하게 구성할 경우 기본 노드와 보조 노드에 동일한 사용 한계를 적용합니다. 프로젝트의 구성 매개 변수는 모든 노드의 구성 파일에 있는 응용 프로그램에서 모두 동일할 필요는 없습니다. 해당 응용 프로그램에 연결된 모든 프로젝트는 해당 응용 프로그램에 있는 모든 잠재적 마스터의 프로젝트 데이터베이스로 액세스할 수 있어야 합니다. 응용 프로그램 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) 할당 작업이 수행되도록 관리 매개 변수를 구성할 수 있습니다.

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

Sun Cluster 환경에서 응용 프로그램을 자원의 일부로 구성합니다. 그런 다음 자원을 자원 그룹(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 시간을 요구하는 각 응용 프로그램에 할당된 공유 수에 따라 변경될 수 있습니다.

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

공용 네트워크 어댑터 및 IP (Internet Protocol) Network Multipathing

클라이언트는 공용 네트워크 인터페이스를 통해 클러스터에 데이터 요청을 합니다. 각 클러스터 노드는 공용 네트워크 어댑터 쌍을 통해 최소한 하나의 공용 네트워크에 연결됩니다.

Sun Cluster의 Solaris Internet Protocol(IP) Network Multipathing 소프트웨어는 공용 네트워크 어댑터를 모니터하고 오류가 감지된 경우 한 어댑터에서 다른 어댑터로 IP 주소를 페일오버하는 기본 기법을 제공합니다. 각 클러스터 노드에는 다른 클러스터 노드의 구성과 구별될 수 있는 자체 IP (Internet Protocol) Network Multipathing 구성이 있습니다.

공용 네트워크 어댑터는 IP multipathing 그룹(multipathing 그룹)으로 구성됩니다. 각 Multipathing 그룹에는 하나 이상의 공용 네트워크 어댑터가 있습니다. Multipathing 그룹의 각 어댑터는 활성화될 수 있습니다. 또한 페일오버가 발생하기 전에는 비활성 상태인 대기 인터페이스를 구성할 수 있습니다.

in.mpathd multipathing 데몬은 테스트 IP 주소를 사용하여 오류를 감지하고 복구합니다. multipathing 데몬이 어댑터 중 하나에서 오류를 감지하면 페일오버가 발생됩니다. 모든 네트워크 액세스는 multipathing 그룹의 오류가 발생한 어댑터에서정상적으로 작동하는 다른 어댑터로 페일오버됩니다. 따라서 데몬은 해당 노드에 대한 공용 네트워크 연결을 유지 관리합니다. 대기 인터페이스가 구성된 경우 데몬은 대기 인터페이스를 선택합니다. 그렇지 않으면 데몬은 가장 작은 수의 IP 주소를 가진 인터페이스를 선택합니다. 페일오버는 어댑터 인터페이스 수준에서 발생하므로 TCP와 같은 고급 연결은 페일오버 중에 일시적으로 지연되는 경우를 제외하고는 영향을 받지 않습니다. IP 주소의 페일오버가 성공적으로 수행되면 ARP 브로드캐스트가 전송됩니다. 따라서 데몬은 원격 클라이언트에 대한 연결을 유지 관리합니다.

주 –

TCP의 정체 복구 특성으로 인해 성공적인 페일오버 후에도 TCP 끝점에서 추가 지연이 발생할 수 있습니다. TCP의 정체 제어 기법이 활성화되면 페일오버 중에 일부 세그먼트가 손실될 수 있습니다.

Multipathing 그룹은 논리 호스트 이름 및 공유 주소 자원에 대한 빌딩 블록을 제공합니다. 또한 사용자도 논리 호스트 이름과 공유 주소 자원의 Multipathing 그룹을 독립적으로 만들어서 클러스터 노드에 대한 공용 네트워크 연결을 모니터할 수 있습니다. 한 노드의 동일한 Multipathing 그룹이 여러 논리 호스트 이름이나 공유 주소 자원을 호스트할 수 있습니다. 논리 호스트 이름과 공유 주소 자원에 대한 자세한 내용은 Sun Cluster Data Services Planning and Administration Guide for Solaris OS를 참조하십시오.

주 –

IP (Internet Protocol) Network Multipathing 기법은 어댑터 장애를 감지하고 마스크하도록 설계되었습니다. 이 설계는 관리자가 ifconfig(1M)를 사용하여 논리(또는 공유) IP 주소 중 하나를 제거한 것을 복구하기 위한 것이 아닙니다. Sun Cluster 소프트웨어는 논리 및 공유 IP 주소를 RGM에서 관리하는 자원으로 인식합니다. 관리자가 IP 주소를 추가 또는 제거하는 올바른 방법은 scrgadm(1M)을 사용하여 해당 자원이 포함된 자원 그룹을 수정하는 것입니다.

IP Network Multipathing을 Solaris 에서 구현하는 방법에 대한 자세한 내용은 클러스터에 설치된 Solaris 운영 체제에 대한 해당 설명서를 참조하십시오.

운영 체제 릴리스 

지침 

Solaris 8 운영 체제 

IP Network Multipathing Administration Guide

Solaris 9 운영 체제 

IP Network Multipathing Administration Guide의 1 장, IP Network Multipathing (Overview)

Solaris 10 Operating System 

System Administration Guide: IP Services의 파트 VI, IPMP

SPARC: 동적 재구성 지원

DR(동적 재구성) 소프트웨어 기능에 대한 Sun Cluster 3.1 8/05의 지원이 점진적으로 개발되고 있습니다. 이 절에서는 Sun Cluster 3.1 8/05의 DR 기능 지원에 대한 개념과 고려 사항에 대해 설명합니다.

Solaris DR 기능의 문서화된 요구 사항, 절차 및 제한 사항은 Sun Cluster DR 지원에도 모두 적용됩니다(운영 환경의 작동이 정지된 경우는 제외). 따라서 Sun Cluster 소프트웨어에서 DR 기능을 사용하기 전에 먼저 Solaris DR 기능에 대한 설명서를 검토합니다. 특히 DR 연결 종료 작업 중에 비네트워크 IO 장치에 영향을 주는 문제를 확인해야 합니다.

Sun Enterprise 10000 Dynamic Reconfiguration User Guide 및 Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual(Solaris 8 on Sun Hardware 또는 Solaris 9 on Sun Hardware 모음에 포함)은 모두 http://docs.sun.com에서 다운로드할 수 있습니다.

SPARC: 동적 재구성 일반 설명

실행 중인 시스템에서 DR 기능을 사용하면 시스템 하드웨어 제거와 같은 작업을 수행할 수 있습니다. DR 프로세스는 시스템을 중단하거나 클러스터 가용성을 방해하지 않고 연속적으로 시스템을 작동할 수 있도록 설계되었습니다.

DR은 보드 레벨로 작동합니다. 따라서 DR 작업은 보드의 모든 구성 요소에 영향을 줍니다. 각 보드에는 CPU, 메모리를 비롯하여 디스크 드라이브, 테이프 드라이브 및 네트워크 연결을 위한 주변 장치 인터페이스를 포함한 여러 구성 요소가 포함될 수 있습니다.

활성 구성 요소가 포함된 보드를 제거하면 시스템 오류가 발생합니다. 보드를 제거하기 전에 DR 하위 시스템은 Sun Cluster와 같은 다른 하위 시스템을 쿼리하여 보드의 구성 요소가 사용 중인지를 확인합니다. 보드가 사용 중이면 DR 보드 제거 작업이 수행되지 않습니다. 따라서 DR 하위 시스템은 활성 구성 요소가 포함된 보드에 대해 작업을 거부하기 때문에 DR 보드 제거 작업을 실행해도 항상 안전합니다.

DR 보드 추가 작업도 항상 안전합니다. 새로 추가되는 보드의 CPU와 메모리는 시스템에 의해 자동으로 서비스에 포함됩니다. 그러나 새로 추가되는 보드의 구성 요소를 바로 사용하려면 시스템 관리자가 직접 클러스터를 구성해야 합니다.

주 –

DR 하위 시스템에는 여러 수준이 있습니다. 낮은 레벨에서 오류를 보고하면 상위 레벨도 오류를 보고합니다. 그러나 하위 수준에서 특정 오류를 보고하면 상위 수준에서 알 수 없는 오류를 보고합니다. 이 오류는 무시해도 됩니다.

다음 절에서는 서로 다른 장치 유형에 대한 DR 참고 사항을 설명합니다.

SPARC: CPU 장치에 대한 DR 클러스터링 참고 사항

Sun Cluster 소프트웨어에는 CPU 장치가 있으므로 DR 보드 제거 작업을 거부하지 않습니다.

DR 보드 추가 작업이 성공하면 추가된 보드의 CPU 장치가 시스템 작업에 자동으로 통합됩니다.

SPARC: 메모리에 대한 DR 클러스터링 참고 사항

DR을 위해서는 두 가지의 메모리 유형을 고려해야 합니다.

이 두 가지 유형은 용도만 다릅니다. 실제 하드웨어는 두 가지 유형이 동일합니다. 커널 메모리 케이지는 Solaris 운영 체제에서 사용하는 메모리입니다. Sun Cluster 소프트웨어는 커널 메모리 케이지가 있는 보드에서는 보드 제거 작업을 지원하지 않으며 이러한 작업은 모두 거부합니다. DR 보드 제거 작업이 커널 메모리 케이지가 아닌 메모리와 관련되어 있으면 Sun Cluster 소프트웨어에서 작업을 거부하지 않습니다. 메모리에 속하는 DR 보드 추가 작업이 성공하면 추가된 보드의 메모리가 시스템 작업에 자동으로 통합됩니다.

SPARC: 디스크 및 테이프 드라이브에 대한 DR 클러스터링 참고 사항

Sun Cluster에서는 기본 노드에서 활성 드라이브에 대한 DR 보드 제거 작업을 거부할 수 없습니다. DR 보드 제거 작업은 기본 노드의 비활성 드라이브와 보조 노드의 모든 드라이브에서 수행될 수 있습니다. DR 작업이 끝나면 작업 이전과 마찬가지로 클러스터 데이터 액세스가 계속됩니다.

주 –

Sun Cluster에서는 쿼럼 장치의 가용성에 영향을 주는 DR 작업을 할 수 없습니다. 쿼럼 장치와 쿼럼 장치에서 DR 작업을 수행하는 절차에 대한 고려 사항은 SPARC: 쿼럼 장치에 대한 DR 클러스터링 참고 사항을 참조하십시오.

이 작업을 수행하는 방법에 대한 자세한 지침은 Solaris OS용 Sun Cluster 시스템 관리 안내서의 쿼럼 장치 동적 재구성를 참조하십시오.

SPARC: 쿼럼 장치에 대한 DR 클러스터링 참고 사항

DR 보드 제거 작업이 쿼럼용으로 구성한 장치에 인터페이스가 있는 보드와 관련이 있으면 Sun Cluster 소프트웨어에서 이 작업을 거부합니다. 또한 Sun Cluster 소프트웨어는 해당 작업의 영향을 받는 쿼럼 장치도 식별합니다. DR 보드 제거 작업을 수행하기 전에 장치를 쿼럼 장치로 비활성화해야 합니다.

쿼럼을 관리하는 방법에 대한 자세한 내용은 Solaris OS용 Sun Cluster 시스템 관리 안내서의 5 장, 쿼럼 관리을 참조하십시오.

SPARC: 클러스터 상호 연결 인터페이스에 대한 DR 클러스터링 고려 사항

DR 보드 제거 작업이 활성 클러스터 상호 연결 인터페이스가 있는 보드와 관련이 있으면 Sun Cluster 소프트웨어에서 작업을 거부합니다. 또한 Sun Cluster 소프트웨어는 해당 작업의 영향을 받는 인터페이스도 식별합니다. DR 작업에 성공하려면 먼저 Sun Cluster 관리 도구를 사용하여 활성 인터페이스를 비활성화해야 합니다.

주의 – 주의 –

Sun Cluster 소프트웨어에는 각 클러스터 노드에 작동 중인 다른 클러스터 노드 경로가 하나 이상 있어야 합니다. 다른 클러스터 노드에 대한 마지막 경로를 지원하는 독립 상호 연결 인터페이스를 비활성화하면 안됩니다.

이 작업을 수행하는 방법에 대한 자세한 지침은 Solaris OS용 Sun Cluster 시스템 관리 안내서의 클러스터 상호 연결 관리를 참조하십시오.

SPARC: 공용 네트워크 인터페이스에 대한 DR 클러스터링 참고 사항

DR 보드 제거 작업이 활성 공용 네트워크 인터페이스가 있는 보드와 관련이 있으면 Sun Cluster 소프트웨어에서 작업을 거부합니다. 또한 Sun Cluster 소프트웨어는 해당 작업의 영향을 받는 인터페이스도 식별합니다. 활성 네트워크 인터페이스가 있는 보드를 제거하기 전에 먼저 if_mpadm(1M) 명령을 사용하여 해당 인터페이스의 모든 트래픽을 multipathing 그룹의 작동 중인 다른 인터페이스로 전환합니다.

주의 – 주의 –

비활성화된 네트워크 어댑터에서 DR 제거 작업을 수행하는 동안 나머지 네트워크 어댑터가 실패할 경우 가용성에 영향을 줍니다. DR 작업을 수행하는 동안 남은 어댑터를 페일오버할 수 없습니다.

공용 네트워크 인터페이스에서 DR 제거 작업을 수행하는 방법에 대한 자세한 내용은 Solaris OS용 Sun Cluster 시스템 관리 안내서의 공용 네트워크 관리를 참조하십시오.