test

Sun Cluster 3.0 개념

클러스터 관리 및 응용프로그램 개발

이 정보는 기본적으로 Sun Cluster API 및 SDK를 사용하는 시스템 관리자 및 응용프로그램 개발자를 위한 것입니다. 클러스터 시스템 관리자는 클러스터 소프트웨어 설치, 구성 및 관리에 대한 배경 정보로 이 정보를 사용할 수 있습니다. 응용프로그램 개발자는 이 정보를 사용하여 작업할 클러스터 환경을 알 수 있습니다.

다음 그림은 클러스터 관리 개념이 클러스터 구조에 맵핑되는 방법에 대한 고급 보기를 보여줍니다.

그림 3-1 Sun Cluster 소프트웨어 구조

Graphic

관리 인터페이스

몇몇 사용자 인터페이스에서 Sun Cluster 및 Sun Cluster 데이터 서비스 설치, 구성 및 관리를 선택할 수 있습니다. 문서화된 명령줄 인터페이스를 통해 시스템 관리 작업을 수행할 수 있습니다. 명령줄 인터페이스의 맨위에는 선택된 구성 작업을 단순화시키는 유틸리티가 있습니다. 또한 Sun Cluster에는 특정 클러스터 작업에 GUI를 제공하는 Sun Management Center의 일부분으로 실행되는 모듈이 있습니다. 관리 인터페이스의 자세한 설명은 Sun Cluster 3.0 System Administration Guide의 소개 장을 참조하십시오

클러스터 시간

클러스터에서 모든 노드들 사이의 시간은 동기화되어야 합니다. 클러스터 노드가 임의의 외부 시간 소스와 동기화하는지는 클러스터 작동에 중요하지 않습니다. 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에 대해 클러스터를 구성하는 방법에 대한 지시사항은 Sun Cluster 3.0 Installation Guide에 들어 있습니다.

또한 클러스터 밖에서 하나 이상의 NTP 서버를 설정하고 ntp.conf 파일을 변경하여 그 구성을 반영할 수도 있습니다.

정상적인 작동 하에서는 클러스터에서 시간을 조정할 필요가 없습니다. 그러나, Solaris 운영 환경을 설치할 때 시간을 잘못 설정하였는데 이를 변경하려고 하면, Sun Cluster 3.0 System Administration Guide에 포함된 프로시저를 참조하십시오

고가용성 프레임워크

Sun Cluster는 네트워크 인터페이스를 포함하여 사용자들 및 데이터 고가용성, 자체 응용프로그램, 파일 시스템 그리고 멀티호스트 디스크들 사이의 "경로"에 모든 구성요소를 만듭니다. 일반적으로, 클러스터 구성요소는 시스템에서 단일(소프트웨어 또는 하드웨어) 실패를 극복할 경우, 가용성이 높습니다.

다음 테이블은 Sun Cluster 구성요소 실패의 종류(하드웨어 및 소프트웨어 모두)와 고가용성 프레임워크에 형성된 복구 종류를 보여줍니다.

표 3-1 Sun Cluster 실패 감지 및 복구 레벨

실패한 클러스터 자원 

소프트웨어 복구 

하드웨어 복구 

데이터 서비스 

HA API, HA 프레임워크 

N/A 

공용 네트워크 어댑터 

네트워크 어댑터 페일오버(NAFO) 

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

클러스터 파일 시스템 

1차 및 2차 복제본 

멀티호스트 디스크 

미러링된 멀티호스트 디스크 

볼륨 관리(Solstice DiskSuite 및 VERITAS Volume Manager) 

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

글로벌 디바이스 

1차 및 2차 복제본 

디바이스, 클러스터 전송 접합에 대한 다중 경로 

사설 네트워크 

HA 전송 소프트웨어 

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

노드 

CMM, 페일페스트(failfast) 드라이버 

다중 노드 

Sun Cluster 고가용성 프레임워크는 노드 실패를 재빨리 감지하여 클러스터의 나머지 노드에서 프레임워크 자원에 대한 새로운 동등한 서버를 작성합니다 언제나 모든 프레임워크 자원이 사용 가능합니다. 훼손된 노드의 영향을 받지 않는 프레임워크 자원은 복구 동안 완전히 사용할 수 있게 됩니다. 또한 실패한 노드의 프레임워크 자원은 복구되는 대로 사용할 수 있게 됩니다. 복구된 프레임워크 자원은 다른 모든 프레임워크 자원이 복구를 완료할 때까지 기다리지 않아도 됩니다.

대부분의 고가용성 프레임워크 자원은 복구될 때 이 자원을 사용하는 응용프로그램(데이터 서비스)에 투명하게 복구됩니다. 프레임워크 자원 액세스의 시멘틱은 노드 실패에서 완전하게 보존됩니다. 응용프로그램은 프레임워크 자원 서버가 다른 노드로 이동되었다는 것을 간단하게 알릴 수 없습니다. 단일 노드의 실패는 대체 하드웨어 경로가 다른 노드의 디스크에 대해 존재한다면, 이 노드에 접속된 파일, 디바이스 및 디스크 볼륨을 사용하는 나머지 노드에 있는 프로그램에 완전하게 나타납니다. 예를 들어, 여러 노드에 대한 포트를 갖고 있는 멀티호스트 디스크를 사용할 경우가 있습니다.

클러스터 멤버쉽 모니터

CMM(Cluster Membership Monitor)은 클러스터 구성원당 하나씩 분산된 에이전트 세트입니다. 에이전트들은 클러스터 상호연결을 거쳐 메시지를 교환하여 다음을 수행합니다.

이전 Sun Cluster 릴리스와는 달리, CMM은 커널에서 전체적으로 실행됩니다.

클러스터 멤버쉽

CMM의 주요 기능은 주어진 시간에 클러스터에 참여하는 노드 세트에서 클러스터 전반에 대한 일치를 확립하는 것입니다. Sun Cluster는 이러한 제한사항을 클러스터 멤버쉽이라고 합니다.

클러스터 멤버쉽을 판별하고, 궁극적으로 데이터 무결성을 보장하기 위해 CMM은 다음을 수행합니다.

클러스터가 별도의 여러 클러스터로 스스로를 파티션하지 않도록 보호하는 방법에 대해서는 "정족수 및 정족수 디바이스"의 내용을 참조하십시오.

클러스터 멤버쉽 모니터 재구성

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

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

클러스터 멤버쉽에서의 변경을 발견하면, CMM은 클러스터의 동기화된 구성을 수행하며, 이 때 클러스터 자원은 클러스터의 새로운 멤버쉽을 기초로 재분배될 수 있습니다.

클러스터 구성 저장소(CCR)

CCR(Cluster Configuration Repository)은 클러스터의 구성 및 상태에 대한 정보를 저장하기 위한 클러스터 전반의 개인용 데이터베이스입니다. CCR은 분배 데이터베이스입니다. 각 노드는 데이터베이스의 전체 사본을 관리합니다. CCR은 모든 노드가 클러스터 "전체"의 일관된 보기를 수반하도록 합니다.

CCR은 고가용성 서비스로서 커널에서 구현됩니다.

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

주의 - 주의 -

CCR이 텍스트 파일로 구성되어도, 수동으로 CCR 파일들을 편집하지 마십시오. 각 파일에는 일관성이 유지되도록 체크섬 레코드가 포함됩니다. 수동으로 CCR 파일을 갱신하면 노드나 전체 클러스터가 기능 수행을 정지시킬 수 있습니다.

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

글로벌 디바이스

Sun Cluster는 글로벌 디바이스를 사용하여, 디바이스가 실제로 접속되어 있는 곳에 관계없이 어떤 노드에서나 클러스터의 디바이스를 사용할 수 있도록 클러스터 전반의 고가용성 액세스를 제공합니다. 일반적으로, 글로벌 디바이스에 대한 액세스를 제공할 때 노드가 실패하면, Sun Cluster는 자동으로 그 디바이스에 대한 경로를 찾아서 해당되는 경로로 액세스를 보냅니다 Sun Cluster 글로벌 디바이스로는 디스크, CD-ROM 및 테이프가 있습니다. 그러나, 디스크는 유일하게 지원되는 멀티포트 글로벌 디바이스입니다. 즉, CD-ROM 및 테이프 디바이스는 현재 고가용성 디바이스가 아닙니다. 각 서버의 로컬 디스크 역시 멀티포트 상태가 아니므로 고가용성 디바이스가 아닙니다.

클러스터는 자동으로 클러스터 내의 각 디스크, CD-ROM 및 테이프 디바이스에 고유한 ID를 할당합니다. 이러한 할당으로 인해 클러스터의 임의의 노드에서 각 디바이스에 일관되게 액세스할 수 있습니다. 글로벌 디바이스 이름공간은 /dev/global 디렉토리에 보유되어 있습니다. "글로벌 이름공간"에서 자세한 내용을 참조하십시오.

멀티포트 글로벌 디바이스는 디바이스에 대한 한 개 이상의 경로를 제공합니다. 멀티호스트 디스크의 경우, 디스크는 여러 노드에 의해 호스팅된 디스크 디바이스 그룹의 일부분이므로 멀티호스트 디스크는 가용성이 높아집니다.

디바이스 ID(DID)

Sun Cluster는 디바이스 ID(DID) 의사 드라이버로 알려진 구성을 통해 글로벌 디바이스를 관리합니다. 이 드라이버는 멀티호스트 디스크, 테이프 드라이브 및 CD-ROM과 같은 클러스터 내의 모든 디바이스에 자동으로 고유 ID를 할당하는 데 사용됩니다.

디바이스 ID(DID) 의사 드라이버는 클러스터의 글로벌 액세스 기능의 통합 일부분입니다. DID 드라이버는 클러스터의 모든 노드를 규명하고 고유한 디스크 디바이스 목록을 만들어, 클러스터의 모든 노드에서 일관되는 고유한 메이저 번호와 마이너 번호를 각각에 할당합니다. 글로벌 디바이스에 대한 액세스가 수행되어 디스크에 대한 c0t0d0과 같은 기존 Solaris 디바이스 ID 대신 DID 드라이버에 의해 할당된 고유 디바이스 ID를 이용합니다.

이러한 방법을 사용하면 디스크 디바이스를 이용하는 응용프로그램(원래 디바이스를 사용하는 볼륨 관리자나 응용프로그램)이 일관된 경로를 사용하여 디바이스에 액세스할 수 있게 합니다. 이러한 일관성은 멀티호스트 디스크에 대해 특히 유용합니다. 각 디바이스의 로컬 주 번호 및 부 번호는 노드마다 다를 수 있으므로 Solaris 디바이스 이름지정 규칙도 변경될 수 있기 때문입니다. 예를 들어, node1은 c1t2d0처럼 멀티호스트 디스크로 보이고, node2는 c3t2d0처럼 완전히 다른 동일한 디스크로 볼 수 있습니다. DID 드라이버는 글로벌 이름을 할당하여, d10처럼 각 노드에 멀티호스트 디스크에 대해 일관된 맵핑을 제공합니다.

scdidadm(1M) 및 scgdevs(1M)를 통해 디바이스 ID를 갱신하고 관리합니다. 자세한 정보는 관련된 man 페이지를 참조하십시오.

디스크 디바이스 그룹

Sun Cluster에서, 모든 멀티호스트 디스크는 Sun Cluster 프레임워크의 제어 하에 있어야 합니다. 먼저 멀티호스트 디스크에서 볼륨 관리자 디스크 그룹(Solstice DiskSuite 디스크세트 또는 VERITAS Volume Manager 디스크 그룹)을 작성합니다. 그리고 나서, 볼륨 관리자 디스크 그룹을 Sun Cluster 디스크 디바이스 그룹으로 등록합니다. 디스크 디바이스 그룹은 글로벌 디바이스의 유형입니다. 추가로, Sun Cluster는 모든 개별 디스크를 디스크 디바이스 그룹으로 등록합니다.

주 -

디스크 디바이스 그룹은 자원 그룹의 영향을 받지 않습니다. 하나의 노드가 데이터 서비스에 의해 액세스되는 디스크 그룹을 마스터할 때, 다른 노드가 자원 그룹(데이터 서비스 프로세스 그룹을 나타내는)을 마스터할 수 있습니다. 그러나 가장 실용적인 것은 동일한 노드에서 응용프로그램의 자원(응용프로그램 디먼)을 포함하는 자원 그룹과 특수 응용프로그램의 데이터를 저장하는 디스크 디바이스 그룹을 보존하는 것입니다. 디스크 디바이스 그룹과 자원 그룹 사이의 연관에 대한 자세한 정보는 Sun Cluster 3.0 Data Services Installation and Configuration Guide의 개요 장을 참조하십시오

디스크 디바이스 그룹에서 볼륨 관리자 디스크 그룹은 기초가 되는 디스크에 대한 다중 경로 지원을 제공하므로 "글로벌"이 됩니다. 실제로 멀티호스트 디스크에 접속된 각 클러스터 노드는 디스크 디바이스 그룹에 대한 경로를 제공합니다.

주 -

글로벌 디바이스는 한개 이상의 클러스터 노드에 의해 호스팅된 디바이스 그룹의 부분일 경우에 고가용성이 됩니다.

디스크 디바이스 페일오버

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

그림 3-2 디스크 디바이스 그룹 페일오버

Graphic

글로벌 이름공간

글로벌 디바이스를 작동가능하게 하는 Sun Cluster 메카니즘은 글로벌 이름공간입니다. 글로벌 이름공간에는 볼륨 관리자 이름공간 뿐 아니라 /dev/global/ 계층이 포함됩니다. 글로벌 이름공간은 멀티호스트 디스크와 로컬 디스크(그리고 CD-ROM 및 테이프와 같은 다른 클러스터 디바이스) 둘 다를 반영하며, 멀티호스트 디스크에 대한 여러 페일오버 경로를 제공합니다. 실제로 멀티호스트 디스크에 연결된 각 노드는 클러스터의 노드에 대한 스토리지 경로를 제공합니다.

정상적으로, 볼륨 관리자 이름공간은 Solstice DiskSuite의 경우, /dev/md/diskset/dsk (그리고 rdsk) 디렉토리에 상주하고, VxVM의 경우에는 /dev/vx/dsk/disk-group 및 /dev/vx/rdsk/disk-group 디렉토리에 상주합니다. 이름공간들은 각각 클러스터를 통해 가져온 각 Solstice DiskSuite 디스크세트와 각 VxVM 디스크 그룹에 대한 디렉토리로 구성됩니다. 이 디렉토리 각각은 해당되는 디스크세트나 디스크 그룹의 볼륨이나 메타디바이스 각각에 대해 디바이스 노드를 하우징합니다.

Sun Cluster에서 로컬 볼륨 관리자 이름공간의 디바이스 노드 각각은 /global/.devices/node@nodeID 파일 시스템의 디바이스 노드에 대한 기호 링크에 의해 대체됩니다. 여기서, nodeID는 클러스터에서 노드를 나타내는 정수입니다. Sun Cluster는 계속해서 표준 위치에서 기호 링크로서 볼륨 관리자 디바이스를 제시합니다. 글로벌 이름공간과 표준 볼륨 관리자 이름공간 둘 다 임의의 클러스터 노드에서 사용할 수 있습니다.

글로벌 이름공간의 장점은 다음과 같습니다.

로컬 및 글로벌 이름공간 예제

다음 테이블은 c0t0d0s0 멀티호스트 디스크에 대한 로컬 및 글로벌 이름공간 사이의 맵핑을 보여줍니다.

표 3-2 로컬 및 글로벌 이름공간 맵핑

구성요소/경로 

로컬 노드 이름공간 

글로벌 이름공간 

Solaris 논리 이름 

/dev/dsk/c0t0d0s0

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

DID 이름 

/dev/did/dsk/d0s0

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

Solstice DiskSuite 

/dev/md/diskset/dsk/d0

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

VERITAS Volume Manager 

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

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

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

클러스터 파일 시스템

클러스터 파일 시스템은 한 노드의 커널과 디스크에 물리적으로 연결되어 있는 노드에서 실행되는 볼륨 관리자 및 기초 파일 시스템 사이의 프록시입니다.

클러스터 파일 시스템은 하나 이상의 노드에 실제로 연결되어 있는 글로벌 디바이스(디스크, 테이프, CD-ROM)에 종속됩니다. 글로벌 디바이스는 노드가 스토리지 장치에 실제 연결되었는지 여부에 관계없이 동일한 파일 이름(예: /dev/global/)을 통해 클러스터의 노드로부터 액세스할 수 있습니다. 정규 디바이스와 같은 글로벌 디바이스를 사용하여, newfs나 mkfs를 통해 파일 시스템을 작성할 수 있습니다.

글로벌 디바이스에서 mount -g를 사용하여 글로벌하게 또는 mount를 사용하여 로컬로 글로벌 디바이스를 마운트할 수 있습니다. 프로그램은 동일한 파일 이름(예: /global/foo)을 통해 클러스터의 임의의 노드에서 클러스터 파일 시스템의 파일에 액세스할 수 있습니다. 클러스터 파일 시스템은 모든 클러스터 구성원에 마운트됩니다. 클러스터 구성원의 서브세트에서 클러스터 파일 시스템을 마운트할 수 없습니다.

클러스터 파일 시스템 사용

Sun Cluster에서 모든 멀티호스트 디스크는 디스크 디바이스 그룹으로서 구성됩니다. 이 그룹은 Solstice DiskSuite 디스크세트, VxVM 디스크 그룹 또는 소프트웨어 기반 볼륨 관리자의 제어 하에 있지 않은 개인 디스크가 될 수 있습니다. 또한 로컬 디스크는 디스크 디바이스 그룹으로 구성됩니다. 경로는 각 노드에서 각 로컬 디스크로 유도됩니다. 이러한 설정은 디스크의 데이터가 모든 노드로부터 반드시 사용가능해야 한다는 것을 의미하지 않습니다. 디스크의 파일 시스템이 클러스터 파일 시스템으로 글로벌하게 마운트될 경우에만 데이터가 모든 노드에 대해 사용가능하게 됩니다.

클러스터 파일 시스템으로 만들어지는 로컬 파일 시스템만 디스크 스토리지에 대한 단일 연결을 수반합니다. 디스크 스토리지에 대한 실제 연결을 가지고 있는 노드가 실패할 경우, 다른 노드는 더이상 클러스터 파일 시스템에 대해 액세스할 수 없습니다. 다른 노드에서는 직접 액세스할 수 없는 단일 노드에 로컬 파일 시스템이 있을 수도 있습니다.

HA 데이터 서비스는 해당되는 데이터가 클러스터 파일 시스템의 디스크 디바이스 그룹에 저장되도록 설정됩니다. 이 설정에는 몇 가지 장점이 있습니다. 먼저, 데이터는 고가용성입니다. 즉, 디스크는 멀티호스팅되므로 현재 1차 노드로부터의 경로가 실패할 경우, 액세스는 동일한 디스크에 대해 직접 액세스할 수 있는 또 다른 노드로 전환됩니다. 두번째는, 데이터가 클러스터 파일 시스템에 있으므로 클러스터 노드에서 직접 볼 수 있습니다. 즉, 데이터를 보기 위해 현재 디스크 디바이스 그룹을 마스터하는 노드에 로그온하지 않아도 됩니다.

프록시 파일 시스템(PXFS)

클러스터 파일 시스템은 다음과 같은 기능을 갖고 있는 프록시 파일 시스템(PXFS)을 기초로 합니다.

PXFS는 별도의 파일 시스템 유형이 아닙니다. 즉, 클라이언트는 기초가 되는 파일 시스템(예: UFS)을 봅니다.

클러스터 파일 시스템 독립성

클러스터 파일 시스템은 기초가 되는 파일 시스템과 볼륨 관리자에 대해 독립적입니다. 현재, Solstice DiskSuite 또는 VERITAS Volume Manager를 사용하여 UFS에서 클러스터 파일 시스템을 만들 수 있습니다

정상 파일 시스템과 같이 두 가지 방법으로 클러스터 파일 시스템을 마운트할 수 있습니다.

주 -

Sun Cluster가 클러스터 파일 시스템에 대한 이름지정 정책을 하도록 하는 반면, /global/disk-device-group과 같은 동일한 디렉토리 아래의 모든 클러스터 파일 시스템에 대한 마운트 지점을 작성하여 관리를 지울 수 있습니다. 자세한 정보는 Sun Cluster 3.0 Installation Guide 및 Sun Cluster 3.0 System Administration Guide의 내용을 참조하십시오.

Syncdir 마운트 옵션

syncdir 마운트 옵션을 클러스터 파일 시스템에 대해 사용할 수 있습니다. 그러나 syncdir을 지정하지 않을 경우 중요한 성능 향상이 있습니다. syncdir을 지정한 경우, 쓰기의 POSIX 호환은 보증됩니다. 그렇게 하지 않으면, UFS 파일 시스템에서와 동일한 동작을 수반하게 됩니다. 예를 들어, syncdir이 없으면, 파일을 닫을 때까지 공간 부족 상태를 발견하지 못하는 경우가 있습니다. syncdir (및 POSIX 동작)이 있으면, 쓰기 조작 동안 공간 부족 상태가 발견되었을 것입니다. syncdir을 지정하지 않아서 생기는 문제점이 간혹 있지만, 이를 지정하지 않으면 성능 향상 이점을 얻을 수 있으므로 지정하지 않는 것을 권장합니다.

글로벌 디바이스와 클러스터 파일 시스템에 대한 FAQ는 "파일 시스템 FAQ"의 내용을 참조하십시오.

정족수 및 정족수 디바이스

클러스터 노드는 데이터 및 자원을 공유하므로, 클러스터는 데이터 및 자원 무결성을 유지하기 위한 단계를 취해야 합니다. 노드가 멤버쉽에 대한 클러스터 규칙을 따르지 않으면, 클러스터는 노드가 클러스터에 참여하는 것을 허용하지 않아야 합니다.

Sun Cluster에서 클러스터에 참여하는 노드를 판별하는 메카니즘을 정족수라고 합니다. Sun Cluster는 대다수 투표 알고리즘을 사용하여 정족수를 구현합니다. 클러스터 노드와 정족수 디바이스(두 개 이상의 노드 사이에 공유되는 디스크들) 둘 다 정족수를 형성하기 위해 투표합니다. 정족수 디바이스는 사용자 데이터에 포함될 수 있습니다.

정족수 알고리즘은 동적으로 작동됩니다. 클러스터 이벤트가 해당되는 계산을 트리거하는 대로, 계산 결과는 클러스터의 수명을 변경할 수 있습니다. 정족수는 일관되지 않는 데이터를 클라이언트가 사용할 수 있게 만들 수 있는 두 가지의 가능한 클러스터 문제점(브레인 분할 및 앰네시아)으로부터 보호합니다. 다음 테이블은 이러한 두 가지 문제점과 정족수로 이 문제점을 해결하는 방법에 대해 설명합니다.

표 3-3 클러스터 정족수와 브레인 분할 및 앰네시아 문제점

문제점 

설명 

정족수의 해결 

브레인 분할 

노드들 사이의 클러스터 상호연결이 유실되고 클러스터가 서브 클러스터로 분할될 경우에 발생합니다. 이 때, 각 서브 클러스터는 스스로를 유일한 파티션이라고 간주합니다.  

대다수의 투표가 있는 파티션(서브 클러스터)만 실행되도록 합니다(그러한 대다수의 파티션은 하나만 존재합니다).  

앰네시아 

클러스터가 시스템 종료 시간보다 이전에 클러스터 데이터에 대해 시스템을 종료한 후 재시작할 경우에 발생합니다. 

클러스터가 부트될 경우, 최근 클러스터 멤버쉽의 구성원이었던 최소한 하나의 노드가 있습니다(그러므로 최근 구성 데이터를 수반함).  

정족수 투표 계산

클러스터 노드 및 정족수 디바이스(두 개 이상의 노드 사이에 공유되는 디스크들) 둘 다 정족수를 형성하기 위해 투표합니다. 기본적으로, 클러스터 노드는 부트하여 클러스터 구성원이 될 때 하나의 정족수 투표수를 확보합니다. 또한 노드가 설치되거나 관리자가 노드를 유지보수 상태에 둘 경우, 노드는 투표 계수를 확보하지 못합니다.

정족수 디바이스는 디바이스에 대한 노드 연결 수를 기초로 정족수 투표수를 확보할 수 있습니다. 정족수 디바이스가 설정되면, 최대 투표수 N-1을 확보합니다. 여기서 N은 정족수 디바이스에 대한 포트를 갖고 있는, 투표수가 0이 아닌 노드들의 수입니다. 예를 들어, 투표수가 0이 아닌 두 노드에 연결된 정족수 디바이스는 정족수가 1입니다(2 - 1).

클러스터 설치 동안 정족수 디바이스를 구성하거나 나중에 Sun Cluster 3.0 System Administration Guide에서 설명된 프로시저를 사용하여 정족수 디바이스를 구성합니다.

주 -

정족수 디바이스는 현재 접속되어 있는 노드들 중에서 최소한 하나의 노드가 클러스터 구성원일 경우에만 투표수에 포함됩니다. 또한 클러스터 부트 시, 정족수 디바이스는 현재 접속되어 있는 노드들 중에서 최소한 하나의 노드가 부팅되고 시스템이 종료되었을 때 최근에 부트된 클러스터의 구성원일 경우에만 투표수에 포함됩니다.

정족수 구성

정족수 구성은 클러스트의 노드 수에 따라 달라집니다.

그림 3-3 정족수 디바이스 구성 예

Graphic

정족수 지침

정족수 디바이스를 설정할 때 다음 지침을 사용하십시오.

정보 -

일련의 노드 사이에 여러 개의 정족수 디바이스를 구성하십시오. 다른 인클로저의 디스크를 사용하고, 각 노드 사이에 홀수 개의 정족수 디바이스를 구성하십시오. 이것은 개별 정족수 디바이스 실패에 대해 보호됩니다.

실패 방지

클러스터에 대한 주요 문제점은 클러스터가 파티션되는(브레인 분할이라고 함) 실패입니다. 이러한 상황이 발생하면, 모든 노드가 통신할 수 있는 것은 아니므로 개인 노드나 노드 서브세트가 개인 또는 서브세트 클러스터를 형성할 수도 있습니다. 각 서브세트 또는 파티션은 멀티호스트 디스크에 대해 단 하나의 액세스 및 소유권을 갖고 있는 것으로 인식할 수도 있습니다. 디스크에 기록하려고 하는 여러 노드들로 데이터가 훼손될 수 있습니다.

실패 방지는 실제로 디스크에 대한 액세스를 금지하여 멀티호스트 디스크에 대한 노드 액세스를 제한합니다. 노드가 클러스터에서 나갈 경우(실패하거나 파티션되어), 실패 방지는 그 노드가 더이상 디스크에 액세스할 수 없게 만듭니다. 현재 구성원 노드들만 디스크에 대한 액세스를 갖게 되므로, 데이터 무결성이 유지됩니다.

디스크 디바이스 서비스는 멀티호스트 디스크를 사용하는 서비스에 대한 페일오버 기능을 제공합니다. 현재 디스크 디바이스 그룹의 1차(소유자) 노드로서 서비스를 제공하는 클러스터 구성원이 실패하거나 도달할 수 없게 되면, 새로운 1차 노드가 선택되고, 계속해서 부수적인 인터럽트만으로 디스크 디바이스 그룹에 액세스할 수 있게 합니다. 이 프로세스 동안, 이전의 1차 노드는 새로운 1차 노드가 시작되기 전에 디바이스에 대한 액세스를 멈춰야만 합니다. 그러나 구성원이 클러스터 밖으로 제거되어 도달할 수 없게 되면, 클러스터는 1차 노드였던 디바이스들을 해제하도록 노드에 알릴 수 없습니다. 그러므로 살아남은 구성원이 실패한 구성원으로부터 글로벌 전역를 제어하고 액세스할 수 있도록 하는 수단이 필요합니다.

Sun Cluster는 SCSI 디스크 예약을 사용하여 실패 방지를 구현합니다. SCSI 예약을 사용하면, 실패한 노드는 멀티호스트 디스크로부터 "금지되어" 디스크에 액세스할 수 없게 됩니다.

SCSI-2 디스크 예약은 디스크에 접속된 모든 노드에 대한 액세스를 부여하거나(어떤 예약도 없을 경우) 단일 노드(예약이 있는 노드)에 대한 액세스로 제한하는 예약 양식을 지원합니다.

다른 노드가 더이상 클러스터 상호연결을 통해 통신할 수 없음을 클러스터 구성원이 발견하면, 그 구성원은 실패 방지 프로시저를 초기화하여 다른 노드가 공유 디스크에 액세스하지 못하도록 합니다. 이러한 실패 방지가 발생할 경우, 콘솔의 "예약 충돌" 메시지와 함께 금지된 노드가 공황 상태가 되는 것이 정상입니다.

예약 충돌은 노드가 더이상 클러스터 구성원이 아님을 발견한 후 SCSI 예약이 이 노드와 다른 노드 사이에 공유하는 모든 디스크에 놓이므로 발생합니다. 금지된 노드는 금지되고 있음을 인식하지 못할 수 있으므로 공유 디스크 중 하나에 액세스하려면 예약을 발견하여 공황 상태에 빠집니다.

볼륨 관리자

Sun Cluster는 미러 및 긴급 예비 디스크를 사용하여 데이터 가용성을 증가시키고 디스크 실패 및 교체를 처리하기 위해 볼륨 관리 소프트웨어를 사용합니다

Sun Cluster에는 고유한 내부 볼륨 관리자 구성요소가 없지만, 다음과 같은 볼륨 관리자의 영향을 받습니다.

클러스터의 볼륨 관리 소프트웨어는 다음에 대한 지원을 제공합니다.

Sun Cluster에서 볼륨 관리자를 설정할 경우, 멀티호스트 디스크를 Sun Cluster 디스크 디바이스(볼륨 관리자 디스크 그룹에 대한 랩퍼)로 구성합니다. 디바이스는 Solstice DiskSuite 디스크세트나 VxVM 디스크 그룹이 될 수 있습니다.

데이터 서비스에 사용되는 디스크들이 클러스터 내에서 고가용성이 되도록 미러링을 수행하도록 디스크 그룹을 구성해야 합니다.

메타디바이스나 플렉스를 원래 디바이스(데이터베이스 응용프로그램)로 사용하거나 UFS 파일 시스템을 보유하기 위해 사용할 수 있습니다.

볼륨 관리 오브젝트(메타디바이스 및 볼륨)는 클러스터 제어 하에 제공되므로 디스크 디바이스 그룹이 됩니다. 예를 들어, Solstice DiskSuite에서 클러스터 내에 하나의 디스크세트를 작성할 경우(metaset(1M) 명령을 사용하여), 동일한 이름의 해당되는 디스크 디바이스 그룹이 작성됩니다 그러면, 그 디스크세트에 메타디바이스를 작성하므로 글로벌 디바이스가 됩니다. 그러므로 디스크세트는 세트 내의 모든 디바이스가 포팅되는 호스트와 디스크 디바이스(DID 디바이스)들의 콜렉션입니다. 클러스터의 모든 디스크세트는 HA를 위해 세트 내의 여러 호스트에서 작성되어야 합니다. VERITAS Volume Manager를 사용할 경우에도 유사한 상황이 발생합니다각 볼륨 관리자를 설정하는 작업에 대한 세부사항은 Sun Cluster 3.0 Installation Guide의 부록을 참조하십시오.

디스크세트나 디스크 그룹을 계획할 때 고려해야 할 중요한 사항은 연관된 디스크 디바이스 그룹이 클러스터 내의 응용프로그램 자원(데이터)과 어떻게 연관되는 지를 이해하는 것입니다. 이러한 문제에 대해서는 Sun Cluster 3.0 Installation Guide 및 Sun Cluster 3.0 Data Services Installation and Configuration Guide의 내용을 참조하십시오.

데이터 서비스

데이터 서비스라는 용어는 단일 서버에서 보다는 클러스터에서 실행되도록 구성된 Apache Web Server와 같은 타사 응용프로그램을 설명하기 위해 사용됩니다. 데이터 서비스에는 응용프로그램 소프트웨어 및 응용프로그램을 시작, 정지 및 모니터하는 Sun Cluster 소프트웨어가 포함되어 있습니다.

Sun Cluster는 클러스터 내에서 응용프로그램을 제어하고 모니터하기 위해 사용되는 데이터 서비스 메소드를 제공합니다. 이 메소드는 클러스터 노드에서 응용프로그램을 시작, 정지 및 모니터하기 위해 이 메소드들을 사용하는 Resource Group Manager(RGM)의 제어 하에 실행됩니다. 이 메소드들은 클러스터 프레임워크 소프트웨어와 멀티호스트 디스크와 함께 응용프로그램이 고가용성 데이터 서비스가 되도록 합니다. 고가용성 데이터 서비스이므로 클러스터 내에서의 단일 실패 후에 중요한 응용프로그램 인터럽트를 방지할 수 있습니다. 실패는 노드, 인터페이스 구성요소 또는 응용프로그램 자체에 발생할 수 있습니다.

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

Sun Cluster는 또한 API와 데이터 서비스 개발 도구를 제공하여 응용프로그램 프로그래머가 다른 응용프로그램을 Sun Cluster에 대한 고가용성 데이터 서비스로 실행되도록 만들기 위해 필요한 데이터 서비스 방법들을 개발할 수 있도록 합니다.

Resource Group Manager (RGM)

Sun Cluster는 응용프로그램을 고가용성 및 확장가능성 응용프로그램으로 만들기 위한 환경을 제공합니다. RGM은 다음과 같은 논리 구성요소인 자원으로 작동합니다.

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

페일오버 데이터 서비스

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

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

확장가능 데이터 서비스

확장가능 데이터 서비스는 여러 노드에서 인스턴스가 사용되고 있을 가능성을 수반합니다. 확장가능 서비스는 확장가능 자원 그룹을 이용하여, 확장가능한 서비스가 영향을 받는 네트워크 자원(공유 주소)을 포함하도록 페일오버 자원 그룹과 응용프로그램 자원을 포함시킵니다. 확장가능 자원 그룹은 여러 노드에서 온라인 상태로 있을 수 있으므로 서비스의 여러 인스턴스가 한번에 실행될 수 있습니다. 공유 주소를 호스팅하는 페일오버 자원 그룹은 한번에 한 노드에서만 온라인 상태입니다. 확장가능 서비스에 호스팅하는 모든 노드가 동일한 공유 주소를 사용하여 서비스를 호스팅합니다.

서비스 요청은 단일 네트워크 인터페이스(글로벌 인터페이스 또는 GIF)를 통해 클러스터에 제공되고 로드 밸런싱 정책에 의해 설정된 사전 정의된 몇 가지의 알고리즘 중 하나를 기초로 노드에 분산됩니다. 클러스터는 로드 밸런싱 정책을 사용하여 몇몇 노드 사이의 서비스 부하 균형을 맞추는 로드 밸런싱 정책을 사용할 수 있습니다. 다른 공유 주소에 호스트하는 다른 노드에 여러 개의 GIF가 있을 수 있으므로 유의하십시오.

확장가능 서비스의 경우, 응용프로그램 인스턴스는 몇 개의 노드에서 동시에 실행될 수 있습니다. 글로벌 인터페이스를 호스트하는 노드가 실패할 경우, 글로벌 인터페이스는 다른 노드로 페일오버합니다. 응용프로그램 인스턴스 실행이 실패하는 경우, 인스턴스는 동일한 노드에서 재시작을 시도합니다.

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

주 -

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

그림 3-4에는 페일오버와 확장가능 자원 그룹의 예와 확장가능 서비스에 대해 그 사이에 존재할 수 있는 종속성이 나와 있습니다 이 예는 세 개의 자원 그룹을 보여줍니다. 페일오버 자원 그룹에는 고가용성 DNS에 대한 응용프로그램 자원과 고가용성 DNS 및 고가용성 Apache 웹 서버에서 사용되는 네트워크 자원이 포함됩니다. 확장가능 자원 그룹에는 Apache 웹 서버의 응용프로그램 인스턴스만 포함됩니다. 확장가능 및 페일오버 자원 그룹 사이에 자원 그룹 종속성(실선)이 있고 모든 Apache 응용프로그램 자원이 공유 주소(실선)인 네트워크 자원 schost-2에 종속된다는 점에 유의하십시오.

그림 3-4 페일오버 및 확장가능 자원 그룹 예

Graphic

확장가능 서비스 구조

클러스터 네트워킹의 기본 목적은 데이터 서비스에 대한 확장성을 제공하는 것입니다. 확장성은 서비스에 대해 제공되는 로드가 증가하는 대로 데이터 서비스는 새로운 노드가 클러스터에 추가되고 새로운 서버 인스턴스가 실행되는 것처럼 이러한 작업로드 증가 시 일정한 응답 시간을 유지할 수 있음을 의미합니다. 그러한 서비스를 확장가능 데이터 서비스라고 합니다. 확장가능 데이터 서비스의 좋은 예는 웹 서비스입니다. 일반적으로, 확장가능 데이터 서비스는 몇 가지의 인스턴스로 구성되며, 각 인스턴스는 클러스터의 서로 다른 노드에서 실행됩니다. 이러한 인스턴스들은 해당 서비스의 원격 클라이언트 관점에서는 하나의 서비스로 작동합니다. 예를 들어, 서로 다른 노드에서 실행되는 몇 개의 httpd 디먼으로 구성되는 확장가능 웹 서비스를 사용할 수 있습니다. httpd 디먼은 클라이언트 요청에 서비스를 제공할 수도 있습니다. 요청에 서비스를 제공하는 디먼은 로드 밸런싱 정책에 따라 다릅니다. 요청에 서비스를 제공한 특정 디먼이 아니라 서비스에서 제공될 클라이언트에 대한 응답이 표시되므로 단일 서비스 형태가 유지됩니다.

확장가능 서비스는 다음으로 구성됩니다.

다음 그림은 확장가능 서비스 구조를 보여줍니다.

그림 3-5 확장가능 서비스 구조

Graphic

글로벌 인터페이스를 호스트하지 않는 노드(프록시 노드)에는 해당되는 루프백 인터페이스에 호스트된 공유 주소가 있습니다. GIF의 패킷은 구성가능한 로드 밸런싱 정책을 기초로 다른 클러스터 노드에 분산됩니다. 가능한 로드 밸런싱 정책은 다음 부분에 설명되어 있습니다.

로드 밸런싱 정책

로드 밸런싱은 응답 시간과 처리량에서 확장가능 서비스의 성능을 개선합니다.

두 가지의 확장가능 데이터 서비스 클래스 pure와 sticky가 있습니다. pure 서비스는 인스턴스가 클라이언트 요청에 응답할 수 있는 서비스입니다. sticky 서비스는 클라이언트가 같은 인스턴스에 요청을 보내는 서비스입니다. 그러한 요청은 다른 인스턴스에 보내지 않아도 됩니다.

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

sticky 서비스에는 두 가지의 주요 기능인 보통 sticky와 와일드 카드 sticky가 있습니다. Sticky 서비스는 여러 TCP 연결을 거쳐 동시 응용프로그램 레벨 세션이 in-state 메모리(응용프로그램 세션 상태)를 공유할 수 있게 합니다.

보통 sticky 서비스는 클라이언트가 여러 개의 동시 TCP 연결 사이에 상태를 공유할 수 있게 합니다. 클라이언트는 단일 포트에서 청취하는 서버 인스턴스에 대해 "sticky"된다고 합니다. 클라이언트는 인스턴스가 남아 있고 액세스가능한 경우에 자체의 모든 요청이 동일한 서버 인스턴스로 가도록 보장받으며, 로드 밸런싱 정책은 서비스가 온라인인 동안에는 변경되지 않습니다.

예를 들어, 클라이언트의 웹 브라우저가 세 개의 서로 다른 TCP 연결을 사용하여 포트 80에서 고유 IP 주소에 연결되지만, 그 연결들은 서비스에서 캐시된 세션 정보를 교환합니다.

sticky 정책의 일반화는 동일한 인스턴스의 장면 뒤에서 세션 정보를 교환하는 여러 개의 확장가능 서비스로 확장됩니다. 이러한 서비스가 같은 인스턴스의 장면뒤에서 세션 정보를 교환할 경우, 클라이언트는 서로 다른 포트에서 청취하는 동일 노드의 여러 서버 인스턴스에 대해 "sticky"된다고 합니다.

예를 들어, e-commerce 사이트의 고객이 포트 80에서 일반 HTTP를 사용하여 상품들로 시장 바구니를 채우지만, 바구니의 상품 대금을 신용 카드 지불할 경우 보안 데이터를 보내기 위해 포트 443의 SSL로 전환합니다.

와일드 카드 sticky 서비스는 동적으로 할당된 포트 번호를 사용하지만, 여전히 클라이언트 요청이 같은 노드로 갈 것으로 예상합니다. 클라이언트는 동일한 IP 주소에 대해 포트를 거치는 "sticky 와일드 카드"입니다.

이 정책의 좋은 예는 수동 모드 FTP입니다. 클라이언트는 포트 21의 FTP 서버에 연결되고, 동적 포트 범위의 청취자 포트 서버에 다시 연결하도록 서버에서 알립니다. IP 주소에 대한 모든 요청은 제어 정보를 통해 서버가 클라이언트를 알린 동일 노드로 전송됩니다.

이 sticky 정책 각각에 대해 가중된 로드 밸런싱 정책이 기본적으로 적용되므로 클라이언트의 초기 요청은 로드 밸런서에 의해 지시된 인스턴스에 보내집니다. 인스턴스가 실행되는 노드에 대한 유사성을 클라이언트가 확립하고 나면, 차후 요청은 액세스할 수 있는 경우 그 인스턴스로 보내집니다. 그리고 로드 밸런싱 정책은 변경되지 않습니다.

특정 로드 밸런싱 정책에 대한 추가 세부사항이 아래에 설명되어 있습니다.

페일백 설정

자원 그룹은 한 노드에서 다른 노드로 페일오버됩니다. 이전에 실행 중이었던 노드가 클러스터로 리턴된 후 자원 그룹이 다른 노드로 페일오버되는 경우, 그 그룹은 원래 노드로 "페일백"됩니다. 이 옵션은 Failback 자원 그룹 등록 정보 설정을 사용하여 설정됩니다.

특정 인스턴스에서, 예를 들어 자원 그룹을 호스트하는 원래 노드가 반복적으로 실패하고 재부트될 경우, 페일백을 설정하면 자원 그룹에 대한 가용성이 감소될 수 있습니다.

데이터 서비스 결함 모니터

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

새로운 데이터 서비스 개발

Sun은 하나의 클러스터 내에서 다양한 응용프로그램이 고가용성 데이터 서비스처럼 작동하도록 만드는 소프트웨어를 제공합니다. 고가용성 데이터 서비스로 실행할 응용프로그램이 현재 Sun에서 제공되는 것이 아니면, API 또는 DSDL API을 사용하여 응용프로그램을 취하고 이를 고가용성 데이터 서비스로 실행되도록 구성할 수 있습니다. 데이터 서비스에는 페일오버와 확장가능 두 가지의 주요 기능이 있습니다. 응용프로그램이 이러한 데이터 서비스 주요 기능 중 하나를 사용할 수 있는지 판별하기 위한 일련의 기준이 있습니다. 특정 기준은 응용프로그램에 대해 사용할 수 있는 API를 설명하는 Sun Cluster 문서에 설명됩니다.

여기서, 사용하는 서비스가 확장가능 데이터 서비스 구조의 장점을 취할 수 있는지 알 수 있도록 도와주는 일부 지침을 제시하기로 하겠습니다. 확장가능 서비스에 대한 일반적인 정보는 "확장가능 데이터 서비스" 부분을 참조하십시오.

다음 지침을 만족시키는 새로운 서비스는 확장가능 서비스로 사용할 수 있습니다. 기존의 서비스가 이러한 지침을 정확하게 따르지 않으면, 서비스가 지침을 따르도록 부분을 재작성해야 할 수도 있습니다.

확장가능 데이터 서비스는 다음 특징을 가집니다. 먼저, 그러한 서비스는 하나 이상의 서버 인스턴스로 구성됩니다. 각 인스턴스는 클러스터의 다른 노드에서 실행됩니다. 동일한 서비스에서 두 개 이상의 인스턴스가 동일한 노드에서 실행할 수는 없습니다.

두 번째, 서비스가 외부 논리 데이터 저장소를 제공할 경우, 여러 서버 인스턴스로부터 이 저장소로의 동시 액세스를 동기화하여, 데이터가 변경되는 대로 데이터를 읽거나 갱신사항을 유실하는 일이 없도록 해야 합니다. 메모리내 상태와 저장소를 구별하기 위해 "외부"라고 말하며, 저장소 자체가 복제될 수 있어도 그 저장소가 단일 엔티티로 표시되므로 "논리"라고 합니다. 게다가, 이 논리 데이터 저장소에는 서버 인스턴스가 저장소를 갱신할 때마다 갱신사항이 즉시 다른 인스턴스에 의해 보여지는 등록정보가 있습니다.

Sun Cluster는 클러스터 파일 시스템과 해당괴는 글로벌 원시 파티션을 통해 그러한 외부 저장장치를 제공합니다. 예를 들면, 서비스가 새로운 데이터를 외부 로그 파일에 기록하거나 기존 데이터를 제 위치에서 수정한다고 가정합시다. 이 서비스의 여러 인스턴스가 실행될 경우, 각 인스턴스는 이 외부 로그에 대한 액세스를 가지므로 각각은 동시에 이 로그에 액세스할 수도 있습니다. 각 인스턴스는 해당되는 액세스를 이 로그에 동기화해야 합니다. 그렇지 않으면, 인스턴스는 서로 간섭합니다. 서비스는 fcntl(2) 및 lockf(3C)를 통해 일반 Solaris 파일 잠금을 사용하여 원하는 동기화를 수행할 수 있습니다.

그러한 저장소의 다른 예로는 고가용성 Oracle이나 Oracle Parallel Server와 같은 백엔드 데이터베이스를 들 수 있습니다. 그러한 백엔드 데이터베이스 서버는 데이터베이스 조회와 갱신 트랜잭션을 사용하여 내장된 동기화를 제공하므로, 여러 서버 인스턴스가 자체의 고유 동기화를 구현하지 않아도 됩니다.

현재 모습에서 확장가능 서비스가 아닌 서비스의 예는 Sun의 IMAP 서버입니다. 서비스는 저장소를 갱신하지만, 그 저장소는 개인용이므로 여러 IMAP 인스턴스가 저장소에 기록할 경우, 그 인스턴스들은 갱신사항이 동기화되지 않으므로 서로 겹쳐씁니다. IMAP 서버는 동시 액세스를 동기화하기 위해 다시 작성해야 합니다.

마지막으로, 인스턴스에는 다른 인스턴스의 데이터에서 분리된 개인용 데이터가 있을 수 있다는 점에 유의하십시오. 그러한 경우, 데이터는 개인용이고, 해당되는 인스턴스만 이를 조작할 수 있으므로 서비스는 자체를 동시 액세스에 동기화하는데 관여하지 않아도 됩니다. 이 경우, 글로벌로 액세스할 수 있게 될 수도 있으므로 클러스터 파일 시스템 아래에 개인 데이터를 저장하지 않도록 주의해야 합니다.

Data Service API 및 Data Service Development Library API

Sun Cluster는 다음을 제공하여 응용프로그램을 고가용성으로 만듭니다

Sun Cluster 3.0 Data Services Installation and Configuration Guide에서는 Sun Cluster와 함께 제공되는 데이터 서비스를 설치하고 구성하는 방법에 대해 설명합니다. Sun Cluster 3.0 Data Services Developers' Guide에서는 Sun Cluster 프레임워크 하에서 고가용성이 될 다른 응용프로그램을 측정하는 방법에 대해 설명합니다.

Sun Cluster API 및 Data Service Development Library API는 응용프로그램 프로그래머가 데이터 서비스 인스턴스를 시작하고 정지하는 스트립트와 결함 모니터를 개발할 수 있게 합니다. 이러한 도구를 사용하면, 응용프로그램에 페일오버 또는 확장가능 데이터 서비스 중 어느 것을 제공할 것인지 측정할 수 있습니다. 또한 Sun Cluster는 응용프로그램의 필요한 시작 및 정지 메소드를 빨리 생성하여 고가용성 데이터 서비스로 실행되도록 하는데 사용될 수 있는 "일반" 데이터 서비스를 제공합니다

자원 및 자원 유형

데이터 서비스는 몇가지 유형의 자원(Apache Web Server 또는 iPlanet Web Server와 같은 응용프로그램과 응용프로그램이 의존하는 네트워크 주소(논리 호스트 이름 및 공유 주소))을 이용합니다. 응용프로그램과 네트워크 자원은 RGM에서 관리되는 기본 단위를 형성합니다.

자원은 클러스터에 전반적으로 정의된 자원 유형의 인스턴스화입니다. 몇가지의 정의된 자원 유형이 있습니다.

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

네트워크 자원은 SUNW.LogiclaHostname 또는 SUNW.SharedAddress 자원 유형 중 하나입니다. 이들 두 자원 유형은 Sun Cluster 제품에 의해 사전에 등록됩니다.

SUNW.HAStorage 자원 유형은 자원에 따라 자원 시동 및 디스크 디바이스 그룹이 동기화되어 사용됩니다. 데이터 서비스를 시작하기 전에 클러스터 파일 시스템 마운트 포인트 경로, 글로벌 디바이스 및 디바이스 그룹 이름이 사용가능한지 확인하십시오.

RGM에서 관리되는 자원은 자원 그룹이라고 하는 그룹에 위치되므로 그 자원들은 하나의 단위로 관리될 수 있습니다. 자원 그룹은 페일오버나 스위치오버가 자원 그룹에서 초기화된 경우에 하나의 단위로 이주됩니다.

주 -

응용프로그램 자원을 포함하는 자원 그룹을 온라인으로 가져오면, 응용프로그램이 시작됩니다. 데이터 서비스 시작 메소드는 성공적으로 종료되기 전에 응용프로그램이 가동되어 실행 중 상태가 될 때까지 기다립니다. 응용프로그램이 가동되어 실행되는 시기를 판별하는 것은 데이터 서비스가 클라이언트에 서비스를 제공하는 데이터 서비스 결함 모니터가 판별하는 것과 동일한 방법으로 수행됩니다. 이 프로세스에 대한 자세한 정보는 Sun Cluster 3.0 Data Services Installation and Configuration Guide의 내용을 참조하십시오

자원 및 자원 그룹 등록 정보

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

표준 등록 정보는 보통 특정 데이터 서비스와 독립적인 자원 및 자원 그룹 등록 정보를 구성하는데 사용됩니다. 일련의 표준 등록 정보들에 대해서는 Sun Cluster 3.0 Data Services Installation and Configuration Guide의 부록에 설명되어 있습니다.

확장 등록 정보는 응용프로그램 바이너리 위치, 구성 파일 및 자원 종속성과 같은 정보를 제공합니다. 사용하는 데이터 서비스를 구성하는 것처럼 확장 등록 정보를 수정할 수 있습니다. 일련의 확장 등록 정보들에 대해서는 Sun Cluster 3.0 Data Services Installation and Configuration Guide에서 데이터 서비스에 대한 개별 장에 설명되어 있습니다.

PNM(Public Network Management) 및 NAFO(Network Adapter Failover)

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

Sun Cluster PNM(Public Network Management) 소프트웨어는 공용 네트워크 어댑터를 모니터하고 결함이 발견될 경우에 어댑터 사이에 IP 주소를 페일오버하기 위한 기본 메카니즘을 제공합니다. 각 클러스터 노드에는 다른 클러스터 노드에서는 다를 수도 있는 자체의 고유 구성이 있습니다.

공용 네트워크 어댑터는 네트워크 어댑터 페일오버 그룹(NAFO 그룹)으로 구성됩니다. 각 NAFO 그룹에는 하나 이상의 공용 네트워크 어댑터가 있습니다. 주어진 NAFO 그룹에 대해 언제든지 단 하나의 그룹만 활성화될 수 있는 반면, 활동 중인 어댑터에서 PNM 디먼에 의해 결함이 발견된 경우에 어댑터 페일오버 동안 사용되는 백업 어댑터로는 동일한 그룹의 여러 어댑터가 제공됩니다. 페일오버는 활동 중인 어댑터와 연관되는 IP 주소가 백업 어댑터로 이동되어, 노드에 대한 공용 네트워크 연결을 유지하도록 합니다. 페일오버는 어댑터 인터페이스 레벨에서 발생하므로 TCP와 같은 고급 연결은 페일오버 동안의 간단한 임시 지연을 제외하고는 영향을 받지 않습니다.

주 -

TCP의 경합 복구 특성으로, 일부 세그먼트가 페일오버 동안 유실되어 TCP에서 경합 제어 메카니즘을 활성화하므로 성공적인 페일오버 후에는 TCP 엔드포인트에서 추가 지연이 발생할 수도 있습니다.

NAFO 그룹은 논리 호스트 이름 및 공유 주소 자원에 대한 빌딩 블록을 제공합니다. scrgadm(1M) 명령은 필요하면 사용자를 위해 자동으로 NAFO 그룹을 작성합니다. 또한 사용자도 논리 호스트 이름과 공유 주소 자원의 NAFO 그룹을 독립적으로 만들어서 클러스터 노드에 대한 공용 네트워크 연결을 모니터할 수 있습니다. 한 노드의 동일한 NAFO 그룹이 여러 논리 호스트 이름이나 공유 주소 자원을 호스팅할 수 있습니다. 논리 호스트 이름과 공유 주소 자원에 대한 자세한 정보는 Sun Cluster 3.0 Data Services Installation and Configuration Guide의 내용을 참조하십시오.

주 -

NAFO 메카니즘의 설계는 어댑터 장애를 발견하고 마스크하기 위한 것입니다. 이것은 관리자가 논리(또는 공유) IP 주소 중 하나를 제거하기 위해 ifconfig(1M)를 사용하여 복구하도록 설계된 것이 아닙니다. Sun Cluster 설계는 논리 및 공유 IP 주소를 RGM에서 관리되는 자원으로 봅니다관리자가 IP 주소를 추가 또는 제거하는 올바른 방법은 scrgadm(1M)을 사용하여 자원을 포함하는 자원 그룹을 수정하는 것입니다.

PNM 결함 발견 및 페일오버 프로세스

PNM은 활동 중인 어댑터의 패킷 카운터를 정기적으로 검사하는데, 이 때 건강한 어댑터의 패킷 카운터가 어댑터를 통한 정상적인 네트워크 트래픽으로 변경할 것으로 가정합니다. 패킷 카운터가 잠깐 동안 변경되지 않으면 PNM은 ping 순서로 가서 활동 중인 어댑터를 통해 트래픽을 강요합니다. PNM은 각 순서의 끝에서 패킷 카운터 변경을 검사하고, 핑 순서가 여러 번 반복된 후에도 패킷 카운터가 변경되지 않은 채로 있으면 어댑터 결함을 선언합니다. 이러한 이벤트가 발생하면 페일오버는 백업 어댑터(사용가능한 것이 있으면)로 트리거됩니다.

입력 및 출력 패킷 카운터 둘 중 하나나 둘 다가 잠깐 동안 변경되지 않고 남아 있어서, 핑 순서가 초기화될 수 있도록, 두 패킷 카운터 모두 모니터됩니다.

핑 순서는 ALL_ROUTER 멀티캐스트 주소(224.0.0.2), ALL_HOST 멀티캐스트 주소(224.0.0.1) 및 로컬 서브넷 브로드캐스트 주소의 핑으로 구성됩니다.

핑은 최소 비용 우선(least-costly-first) 방식으로 구조화되므로 비용이 덜 드는 핑이 성공하면 비용이 더 드는 핑은 실행되지 않습니다. 또한 핑은 어댑터에서 트래픽을 생성하기 위한 수단으로서만 사용됩니다. 해당되는 종료 상태는 어댑터가 기능하는지, 아니면 결함이 있는지 결정하는데 도움이 되지 않습니다.

이 알고리즘에는 네 가지의 조정가능한 매개변수가 있습니다. inactive_time, ping_timeout, repeat_test 및 slow_network가 그 매개변수들입니다. 이 매개변수들은 결함 감지 속도와 정확도 사이에 조정가능한 타협을 제공합니다. 매개변수에 대한 세부사항과 변경 방법에 대해서는 Sun Cluster 3.0 System Administration Guide에서 공용 네트워크 매개변수를 변경하는 프로시저를 참조하십시오.

NAFO 그룹의 활동 중인 어댑터에서 결함이 감지된 후, 백업 어댑터를 사용할 수 없으면 그 그룹은 DOWN으로 선언되지만, 모든 백업 어댑터의 테스트는 계속됩니다. 그렇지 않고, 백업 어댑터를 사용할 수 있으면 백업 어댑터에 대해 페일오버가 발생합니다. 논리 주소와 해당되는 연관 플래그는 결함이 있는 활동 어댑터가 다운되어 측정할 수 없을 때 백업 어댑터로 "전송"됩니다.

IP 주소의 페일오버가 성공적으로 완료되면, 불필요한 ARP 브로드캐스트가 송신됩니다. 그러므로 원격 클라이언트에 대한 연결이 유지됩니다.