test

Sun Cluster 3.0 U1 개념

3장 주요 개념 - 관리 및 응용프로그램 개발

이 장에서는 SunPlex 시스템을 구성하는 하드웨어 구성 요소에 관련되는 주요 개념에 대해 설명합니다. 주요 내용은 다음과 같습니다.

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

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

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

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

Graphic

관리 인터페이스

여러 가지 사용자 인터페이스에서 SunPlex 시스템을 설치하고 구성하고 관리하는 방법을 선택할 수 있습니다. 문서화된 명령줄 인터페이스를 통해 시스템 관리 작업을 수행할 수 있습니다. 명령줄 인터페이스의 맨 위에는 선택한 구성 작업을 쉽게 할 수 있는 몇 가지 유틸리티가 있습니다. SunPlex 시스템에는 Sun Management Center의 일부로 실행되면서 일정한 클러스터 작업을 할 수 있는 GUI를 제공하는 모듈도 있습니다. 관리 인터페이스의 자세한 설명은 Sun Cluster 3.0 U1 시스템 관리 안내서의 소개 장을 참조하십시오.

클러스터 시간

클러스터에서 모든 노드들 사이의 시간은 동기화되어야 합니다. 클러스터 작동에서 외부 시간 소스를 사용하여 클러스터 노드를 동기화할 것인지는 중요하지 않습니다. SunPlex 시스템은 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 U1 설치 안내서에 들어 있습니다.

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

정상적인 작동 하에서는 클러스터에서 시간을 조정할 필요가 없습니다. 그러나, Solaris 운영 환경을 설치할 때 잘못 설정된 시간을 변경하려면, Sun Cluster 3.0 U1 시스템 관리 안내서에 포함된 절차를 참조하십시오.

고가용성 프레임워크

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

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

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

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

소프트웨어 복구 

하드웨어 복구 

데이터 서비스 

HA API, HA 프레임워크 

없음 

공용 네트워크 어댑터 

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

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

클러스터 파일 시스템 

1차 및 2차 복제본 

멀티호스트 디스크 

이중화된 멀티호스트 디스크 

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

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

글로벌 장치 

1차 및 2차 복제본 

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

독립 또는 개인 네트워크 

HA 전송 소프트웨어 

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

노드 

CMM, 페일페스트 드라이버 

다중 노드 

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

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

클러스터 멤버쉽 모니터

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

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

클러스터 멤버쉽

CMM의 주요 기능은 클러스터에 포함된 노드세트 상에서 항상 클러스터 전역의 일치를 구현하는 것입니다. 이러한 제약 조건을 클러스터 멤버쉽이라고 합니다.

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

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

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

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

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

클러스터 멤버쉽에서의 변경을 발견하면, 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

노드가 종료된 후에 다시 부팅되어 클러스터에 다시 연결될 수도 있고 OpenBoot PROM (OBP) 프롬프트 상태로 있을 수도 있습니다. 어떤 작업을 할 것인지는 OBP의 auto-boot? 매개 변수 설정에 따라 결정됩니다.

CCR(Cluster Configuration Repository)

CCR(Cluster Configuration Repository)은 클러스터의 구성 및 상태에 대한 정보를 저장하기 위한 전체 클러스터 -범위의 개인용 데이터베이스입니다. CCR은 분배 데이터베이스입니다. 각 노드는 데이터베이스의 전체 사본을 관리합니다. CCR을 사용하면 모든 노드에서 일관된 화면으로 클러스터 "전체"를 볼 수 있습니다. 데이터가 손상되지 않도록 하려면 각 노드에서 클러스터 자원의 현재 상태를 알아야 합니다.

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

주의 - 주의 -

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

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

글로벌 장치

SunPlex 시스템은 글로벌 장치를 사용하여, 장치가 실제로 접속되어 있는 곳에 관계없이 어떤 노드에서나 클러스터의 장치를 사용할 수 있도록 클러스터 전반의 고가용성 액세스를 제공합니다. 일반적으로, 글로벌 장치에 대한 액세스를 제공할 때 노드가 실패하면, Sun Cluster 소프트웨어는 자동으로 그 장치에 대한 경로를 찾아서 해당되는 경로로 액세스를 보냅니다 SunPlex 글로벌 장치로는 디스크, 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를 갱신하고 관리합니다. 자세한 정보는 관련된 설명서 페이지를 참조하십시오.

디스크 장치 그룹

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

등록은 어느 노드가 어떤 볼륨 관리자 디스크 그룹에 대한 경로를 가질 것인지에 대한 정보를 SunPlex 시스템에 제공합니다. 그러면 클러스터 전체에서 볼륨 관리자 디스크 그룹에 액세스할 수 있습니다. 둘 이상의 노드를 (마스터) 디스크 장치 그룹에 쓸 수 있으면 해당 디스크 장치 그룹에 저장된 데이터의 가용성이 높아집니다. 가용성이 높은 디스크 장치 그룹을 사용하면 클러스터 파일 시스템을 하우징할 수 있습니다.

주 -

디스크 장치 그룹은 자원 그룹의 영향을 받지 않습니다. 하나의 노드가 데이터 서비스에 의해 액세스되는 디스크 그룹을 마스터할 때, 다른 노드가 (데이터 서비스 프로세스 그룹을 나타내는) 자원 그룹을 마스터할 수 있습니다. 그러나 가장 실용적인 것은 동일한 노드에서 응용프로그램의 자원(응용프로그램 디먼)을 포함하는 자원 그룹과 특수 응용프로그램의 데이터를 저장하는 디스크 장치 그룹을 보존하는 것입니다. 디스크 장치 그룹과 자원 그룹 사이의 연관에 대한 자세한 정보는 Sun Cluster 3.0 U1 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 디스크 그룹에 대한 디렉토리로 구성됩니다. 이 디렉토리 각각은 해당되는 디스크 세트나 디스크 그룹의 볼륨이나 메타 장치 각각에 대해 장치 노드를 하우징합니다.

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

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

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

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

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

Component/Path 

로컬 노드 이름 공간 

글로벌 이름 공간 

Solaris 논리 이름 

/dev/dsk/c0t0d0s0

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

DID 이름 

/dev/did/dsk/d0s0

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

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)을 사용하여 클러스터 파일 시스템의 파일에 액세스할 수 있습니다.

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

클러스터 파일 시스템은 별도로 구분되는 파일 시스템 형식이 아닙니다. 즉, 클라이언트는 하부 파일 시스템(예: UFS)을 봅니다.

클러스터 파일 시스템 사용

SunPlex 시스템에서 모든 멀티호스트 디스크는 디스크 장치 그룹으로서 구성됩니다. 이 그룹은 Solstice DiskSuite 디스크 세트, VxVM 디스크 그룹 또는 소프트웨어 기반 볼륨 관리자의 제어 하에 있지 않은 개인 디스크가 될 수 있습니다.

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

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

주 -

Sun Cluster 소프트웨어가 클러스터 파일 시스템에 대한 이름지정 정책을 제시하지는 않지만, /global/ disk-device-group과 같은 동일한 디렉토리 아래의 모든 클러스터 파일 시스템에 대한 마운트 지점을 작성하여 관리를 용이라게 할 수는 있습니다. 자세한 정보는 Sun Cluster 3.0 U1 설치 안내서 및 Sun Cluster 3.0 U1 시스템 관리 안내서의 내용을 참조하십시오.

클러스터 파일 시스템의 기능

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

Syncdir 마운트 옵션

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

글로벌 장치와 클러스터 파일 시스템에 대한 FAQ는 "파일 시스템 FAQ"를 참조하십시오.

정족수 및 정족수 장치

클러스터 노드는 데이터와 자원을 공유하기 때문에 클러스터가 동시에 활성중인 별도의 파디션으로 분리되지 않도록 해야 합니다. CMM을 사용하면 클러스터 상호 연결이 분할된 경우에도 하나 이상의 클러스터가 항상 작동합니다.

클러스터 파티션에서는 기억 분리 및 기억 상실 두 가지 문제가 발생합니다. 기억 분리는 노드들 사이의 클러스터 상호 연결이 유실되고 클러스터가 서브 클러스터로 분할될 경우에 발생합니다. 이 때, 각 서브 클러스터는 스스로를 유일한 파티션이라고 간주합니다. 이 문제는 클러스터 노드 사이의 통신 문제 때문에 발생합니다. 기억 상실은 클러스터가 시스템 종료 시간보다 이전에 클러스터 데이터에 대해 시스템을 종료한 후 재시작할 경우에 발생합니다. 프레임워크 데이터 버전이 여러 개 있고 최신 버전을 사용할 수 없을 때 새로 구성된 클러스터가 시작되면 이 문제가 발생할 수 있습니다.

각 노드에 한 표만 부여하고 대부분의 표가 작동 클러스터에 참여하도록 지시하면 기억 분리 및 기억 상실 문제를 방지할 수 있습니다. 대부분의 표가 있는 파티션은 정족수가 있기 때문에 작동할 수 있습니다. 클러스터에 노드가 두 개 이상이면 이러한 다수 표 메커니즘을 사용할 수 있습니다. 노드가 두 개인 클러스터에서는 다수가 둘입니다. 이러한 클러스터가 분할되면 각 파티션이 정족수를 얻기 위해 외부 표가 필요합니다. 필요한 외부 표는 정족수 장치에서 제공합니다. 두 노드 사이에 공유하는 디스크를 정족수 장치로 사용할 수 있습니다. 정족수 장치로 사용되는 디스크에는 사용자 데이터가 저장될 수 있습니다.

표 3-3 에서는 Sun Cluster 소프트웨어에서 정족수를 사용하여 기억 분리 및 기억 상실 문제를 해결하는 방법을 설명합니다.

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

파티션 유형 

정족수 해결 방법 

기억 분리 

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

기억 상실 

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

정족수 알고리즘은 동적으로 작동됩니다. 클러스터 이벤트가 계산을 트리거하면 클러스터 수명 동안 계산 결과가 변경될 수 있습니다.

정족수 투표 계산

클러스터 노드와 정족수 장치가 모두 투표하여 정족수를 채웁니다. 기본적으로, 클러스터 노드는 부트하여 클라이언트 시스템이 될 때 하나의 정족수 투표수를 확보합니다. 또한 노드가 설치되거나 관리자가 노드를 유지보수 상태에 둘 경우, 노드는 투표 계수를 확보하지 못합니다.

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

클러스터 설치 동안 정족수 장치를 구성하거나 나중에 Sun Cluster 3.0 U1 시스템 관리 안내서에서 설명된 절차를 사용하여 정족수 장치를 구성합니다.

주 -

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

정족수 구성

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

그림 3-3 정족수 장치 구성 예

Graphic

정족수 지침

정족수 장치를 설정할 때 다음 지침을 사용하십시오.

정보 -

각 정족수 장치에 장애가 발생하지 않도록 보호하려면 노드 세트 사이에 두 개 이상의 정족수 장치를 구성하십시오. 다른 인클로저의 디스크를 사용하고, 각 노드 사이에 홀수 개의 정족수 장치를 구성하십시오.

실패 방지

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

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

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

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

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

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

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

장애 방지를 위한 페일패스트 메커니즘

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

클러스터를 구성하는 노드는 정족수 디스크를 포함하여 액세스할 수 있는 디스크에 대하여 특정 ioctl, MHIOCENFAILFAST를 계속 사용할 수 있도록 합니다. 이 ioctl은 디스크 드라이버에 대한 지시어이고, 디스크가 다른 노드에 예약되어 디스크에 액세스할 수 없을 경우에 노드가 종료될 수 있도록 합니다.

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

SCSI-2 디스크의 경우 예약이 지속되지 않습니다. 즉, 노드를 다시 부팅하면 없어집니다. PGR(Persistent Group Reservation)이 있는 SCSI-3 디스크의 경우에는 예약 정보가 디스크에 저장되어 노드를 다시 부팅한 후에도 유지됩니다. 페일패스트 메커니즘은 SCSI-2 디스크를 사용하는 경우나 SCSI-3 디스크를 사용하는 경우에 모두 동일하게 작동합니다.

노드가 클러스터의 다른 노드와 연결이 끊어지고 정족수를 채울 수 있는 파티션에 포함되지 않은 경우에는 다른 노드에 의해 강제로 클러스터에서 제거됩니다. 정족수를 채울 수 있는 파티션에 포함된 다른 노드가 공유 디스크에 예약을 설정하고, 정족수가 채워지지 않은 노드가 예약된 공유 디스크에 액세스하려고 시도하면 페일패스트 메커니즘에 의해 예약 충돌이 발생하여 종료됩니다.

노드가 종료된 후에 다시 부팅되어 클러스터에 다시 연결될 수도 있고 OpenBoot PROM (OBP) 프롬프트 상태로 있을 수도 있습니다. 어떤 작업을 할 것인지는 OBP의 auto-boot? 매개 변수 설정에 따라 결정됩니다.

볼륨 관리자

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

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

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

볼륨 관리 객체가 클러스터의 제어를 받으면 디스크 장치 그룹이 됩니다. 볼륨 관리자에 대한 자세한 내용은 볼륨 관리자 소프트웨어 설명서를 참조하십시오.

주 -

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

데이터 서비스

데이터 서비스라는 용어는 단일 서버에서 보다는 클러스터에서 실행되도록 구성된 Oracle 또는 iPlanet Web Server와 같은 타사 응용프로그램을 설명하기 위해 사용됩니다. 데이터 서비스는 응용프로그램, 특수한 Sun Cluster 구성 파일, 다음과 같은 응용프로그램 작업을 제어하는 Sun Cluster 관리 방법 등으로 구성됩니다.

그림 3-4 에서는 단일 응용프로그램 서버에서 실행되는 응용프로그램(단일 서버 모델)을 클러스터에서 실행되는 동일한 응용프로그램(클러스터 서버 모델)가 비교합니다. 사용자의 관점에서 보면 클러스터 응용프로그램이 더 빠르게 실행될 수 있고 가용성이 높다는 것 외에는 두 구성 사이에 큰 차이가 없습니다.

그림 3-4 표준 및 클러스터 클라이언트/서버 구성 비교

Graphic

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

클러스터 서버 모델에서는 공용 네트워크 인터페이스가 논리적 호스트 이름이나 공유 주소입니다. 네트워크 자원은 논리적 호스트 이름과 공유 자원을 모두 나타내는 용어입니다.

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

네트워크 자원은 특정 물리적 서버와 연결되지 않고 물리적 서버 사이에 이주할 수 있습니다.

네트워크 자원은 처음에 하나의 노드(1차)와 연결됩니다. 1차 노드에 장애가 발생하면 네트워크 자원과 응용프로그램 자원이 다른 클러스터 노드(2차)로 페일오버합니다. 네트워크 자원이 페일오버하면 잠시 지연된 후에 응용프로그램 자원이 2차 노드에서 계속 실행됩니다.

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

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

Graphic

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

논리적 호스트 이름 모델과 확장 가능한 서비스 모델 사이의 차이는 확장 가능한 서비스 모델에서는 각 노드에도 루프백 인터페이스에 활성으로 구성된 공유 주소가 있다는 것입니다. 이러한 구성 때문에 여러 노드에 대하여 여러 데이터 서비스 인스턴스를 동시에 실행할 수 있습니다. "확장 가능한 서비스"라는 용어는 클러스터 노드를 추가하여 응용프로그램에 CPU 기능을 추가하는 방법으로 성능을 확장할 수 있다는 의미입니다.

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

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

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

Graphic

데이터 서비스 방법

Sun Cluster 소프트웨어는 여러 가지 서비스 관리 방법을 지원합니다. 이 방법은 클러스터 노드에서 응용프로그램을 시작, 정지 및 모니터하기 위해 이 방법을 사용하는 Resource Group Manager(RGM)의 제어 하에 실행됩니다. 이 메소드들은 클러스터 프레임워크 소프트웨어와 멀티호스트 디스크와 함께 응용프로그램이 고가용성 데이터 서비스가 되도록 합니다.

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

Sun Cluster 소프트웨어에서 제공하는 메소드에 추가로 SunPlex 시스템에서도 API 및 여러 가지 데이터 서비스 개발 도구를 제공합니다. 응용프로그램 프로그래머가 이 도구를 사용하면 다른 응용프로그램이 Sun Cluster 소프트웨어에서 가용성이 높은 데이터 서비스로 실행될 수 있도록 필요한 데이터 서비스 메소드를 개발할 수 있습니다.

Resource Group Manager(RGM)

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

RGM은 자원 및 자원 그룹에 대하여 작동합니다. RGM 작업으로 자원 및 자원 그룹이 온라인 및 오프라인 상태로 전환될 수 있습니다. 자원 및 자원 그룹에 적용할 수 있는 상태와 설정에 대한 자세한 설명은 "자원 및 자원 그룹의 상태와 설정" 단원을 참조하십시오.

페일오버 데이터 서비스

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

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

확장 가능 데이터 서비스

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

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

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

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

주 -

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

그림 3-7 에는 페일오버, 확장 가능한 리소스 그룹, 확장 가능한 서비스를 위한 둘 사이의 관계 등에 대한 예가 있습니다. 이 예에는 세 가지 자원 그룹이 있습니다. 페일오버 자원 그룹에는 고가용성 DNS에 대한 응용프로그램 자원과 고가용성 DNS 및 고가용성 Apache 웹 서버에서 사용되는 네트워크 자원이 포함됩니다. 확장 가능 자원 그룹에는 Apache 웹 서버의 응용프로그램 인스턴스만 포함됩니다. 확장 가능 및 페일오버 자원 그룹 사이에 자원 그룹 종등록 정보(실선)이 있고 모든 Apache 응용프로그램 자원이 공유 주소(실선)인 네트워크 자원 schost-2에 종속된다는 점에 유의하십시오.

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

Graphic

확장 가능 서비스 구조

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

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

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

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

Graphic

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

로드 밸런싱 정책

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

확장 가능한 데이터 서비스에는 pure 및 sticky 두 가지가 있습니다. 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"된다고 합니다.

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

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

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

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

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

페일백 설정

자원 그룹은 한 노드에서 다른 노드로 페일오버됩니다. 그러면 초기의 2차 노드가 새로운 1차 노드가 됩니다. 페일백 설정은 초기 1차 노드가 다시 온라인 상태가 될 때 수행되는 작업을 지정합니다. 초기 1차 노드가 다시 1차 노드가 되는 페일백 옵션 또는 현재 1차 노드를 그대로 유지하는 옵션이 있습니다. Failback 리소스 그룹 등록 정보 설정을 사용하여 원하는 옵션을 지정합니다.

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

데이터 서비스 결함 모니터

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

새로운 데이터 서비스 개발

Sun에서는 클러스터에서 여러 응용프로그램이 페일오버 또는 확장 가능한 서비스로 작동하도록 할 수 있는 구성 파일과 관리 메소드 템플릿을 제공합니다. 고가용성 데이터 서비스로 실행할 응용프로그램이 현재 Sun에서 제공되는 것이 아니면, API 또는 DSDL API을 사용하여 응용프로그램을 취하고 이를 고가용성 데이터 서비스로 실행되도록 구성할 수 있습니다.

응용프로그램이 페일오버 서비스가 될 수 있도록 할 것인지를 결정하는 기준이 있습니다. 특정 기준은 응용프로그램에 대해 사용할 수 있는 API를 설명하는 SunPlex 문서에 설명됩니다.

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

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

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

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

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

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

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

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

Data Service API 및 Data Service Development Library API

SunPlex 시스템은 다음을 제공하여 응용프로그램을 고가용성으로 만듭니다

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

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

응용프로그램 트래픽을 위한 클러스터 상호 연결 사용법

클러스터에는 클러스터 상호 연결을 형성하는 노드간 여러 네트워크 연결이 있어야 합니다. 클러스터 소프트웨어는 고가용성 및 성능 향상 둘 모두를 위해 다중 상호 연결을 사용합니다. 내부 트래픽(예를 들어, 파일 시스템 데이터 또는 확장 가능 서비스 데이터)의 경우, 메시지는 사용 가능한 모든 상호 연결을 통해 라운드 로빈 방식으로 스트립됩니다.

클러스터 상호 연결은 노드사이의 고가용 통신을 위해 응용프로그램에도 사용 가능합니다. 예를 들어, 분산 응용프로그램에는 통신을 필요로 하는 다른 노드에서 실행하는 구성 요소가 있을 수 있습니다. 공용 상호 연결이 아닌 클러스터 상호 연결을 사용하여, 이 연결은 각 링크에 대한 실패로부터 안전합니다.

노드간 통신을 위해 클러스터 상호 연결을 사용하려면, 응용프로그램은 클러스터가 설치되었을 때 구성된 개인용 호스트 이름을 사용해야 합니다. 예를 들어, 노드 1의 개인용 호스트 이름이 clusternode1-priv인 경우, 해당 이름을 사용하여 클러스터 상호 연결을 통해 노드 1로 통신하십시오. 이 이름을 사용하여 열린 TCP 소켓은 클러스터 상호 연결을 통해 라우트되며 네트워크 실패의 경우 투명하게 다시 라우트될 수 있습니다.

개인용 호스트 이름이 설치 중에 구성될 수 있기 때문에, 클러스터 상호 연결은 해당 시간에 선택된 이름을 사용할 수 있다는 것에 유의하십시오. 실제 이름은 scha_privatelink_hostname_node 인수를 사용하여 scha_cluster_get(3HA)에서 얻을 수 있습니다.

클러스터 상호 연결에 대한 응용프로그램 레벨 사용의 경우, 단일 상호 연결은 각 노드 쌍 간에 사용됩니다. 예를 들어, 세 개의 노드에서 실행하고 클러스터 상호 연결을 통해 통신하는 응용프로그램을 고려하십시오. 노드 1과 2 사이의 통신이 인터페이스 hme0에서 일어날 수 있는 반면, 노드 1과 3 사이의 통신은 인터페이스 qfe1에서 일어날 수 있습니다. 즉, 두 노드간 응용프로그램 통신이 단일 상호 연결로 제한되는 반면, 내부 클러스터 통신은 모든 상호 연결을 통해 스트립됩니다.

응용프로그램이 내부 클러스터 트래픽과 상호 연결을 공유하므로, 응용프로그램에 사용 가능한 대역폭은 다른 클러스터 트래픽에 사용되는 대역폭에 따라 다릅니다. 실패할 경우, 내부 트래픽이 나머지 상호 연결을 통해 라운드 로빈될 수 있는 반면, 실패한 상호 연결의 응용프로그램 연결은 작업하는 상호 연결로 전환될 수 있습니다.

두 가지 유형의 주소가 클러스터 상호 연결을 지원하고, 개인용 호스트 이름의 gethostbyname(3N)은 정상적으로 두 개의 IP 주소를 반환합니다. 첫번째 주소는 논리 pairwise 주소라 하고, 두 번째 주소는 논리 pernode 주소라 합니다.

별도의 논리 pairwise 주소는 각 노드 쌍에 할당됩니다. 이 작은 논리 네트워크는 연결에 대한 페일오버를 지원합니다. 각 노드는 수정된 pernode 주소로도 할당됩니다. 즉, clusternode1-priv에 대한 논리 pairwise 주소가 각 노드마다 다른 반면, clusternode1-priv에 대한 논리 pernode 주소는 각 노드마다 동일합니다. 그러나 노드에는 노드 스스로에 대한 pairwise 주소가 없으므로, 노드 1에 있는 gethostbyname(clusternode1-priv)은 논리 pernode 주소만 반환합니다.

클러스터 상호 연결을 통해 연결을 승인하고 보안을 이유로 IP 주소를 확인하는 응용프로그램은 첫번째 IP 주소만이 아니라 gethostbyname에서 반환되는 모든 IP 주소에 대해 확인해야 합니다.

어느 점에 있어서도 응용프로그램에서 일관된 IP 주소를 필요로 하는 경우, 모든 연결이 pernode 주소에서 왕래하는 것으로 나타날 수 있도록 응용프로그램을 구성하여 클라이언트와 서버 측 모두에 대한 pernode 주소로 바인드하십시오.

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

데이터 서비스는 여러 종류의 자원을 사용합니다. 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 U1 Data Services Installation and Configuration Guide의 내용을 참조하십시오

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

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

자원 및 자원 그룹 등록 정보

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

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

확장 등록 정보는 응용프로그램 바이너리 위치, 구성 파일 및 자원 종등록 정보와 같은 정보를 제공합니다. 사용하는 데이터 서비스를 구성하는 것처럼 확장 등록 정보를 수정할 수 있습니다. 일련의 확장 등록 정보들에 대해서는 Sun Cluster 3.0 U1 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 U1 Data Services Installation and Configuration Guide의 내용을 참조하십시오.

주 -

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

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

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

입력 및 출력 패킷 카운터는 PNM에 의해 모니터됩니다. 따라서 입출력 모두 또는 한 가지가 일정 시간 동안 변경되지 않으면 ping 시퀀스가 시작됩니다.

핑 순서는 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 U1 시스템 관리 안내서에서 공용 네트워크 매개변수를 변경하는 절차를 참조하십시오.

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

IP 주소의 페일오버가 성공적으로 완료되면, ARP 브로드캐스트가 전송됩니다. 따라서 원격 클라이언트 연결은 유지됩니다.