test

Sun Cluster 3.0 12/01 개념

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

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

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

이 정보는 주로 SunPlex API 및 SDK를 사용하는 시스템 관리자 및 응용프로그램 개발자를 위한 내용입니다. 클러스터 시스템 관리자는 클러스터 소프트웨어 설치, 구성 및 관리를 위한 배경 정보로 이 정보를 사용할 수 있습니다. 응용프로그램 개발자는 이 정보를 통해 작업할 클러스터의 환경을 이해할 수 있습니다.

다음은 클러스터 관리 개념을 클러스터 아키텍처에 매핑하는 방법을 높은 수준으로 설명하는 그림입니다.

그림 3-1 Sun Cluster 소프트웨어 아키텍처

Graphic

관리 인터페이스

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

클러스터 시간

클러스터에서는 모든 노드 사이의 시간이 동기화되어야 합니다. 클러스터 노드를 외부 시간 소스와 동기화할 것인지는 클러스터 작동에 중요하지 않습니다. 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 12/01 소프트웨어 설치 안내서를 참조하십시오.

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

정상적인 작동에서는 클러스터의 시간을 조정할 필요가 없습니다. 그러나 Solaris 운영 환경을 설치할 때 시간이 잘못 설정되어 변경하려는 경우에는 Sun Cluster 3.0 12/01 시스템 관리 안내서의 절차를 참조하십시오.

가용성이 높은 프레임워크

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 디렉토리에 저장됩니다. 자세한 내용은 "글로벌 이름 공간"을 참조하십시오.

멀티포트 글로벌 장치는 장치에 대한 경로를 하나 이상 제공합니다. 멀티호스트 디스크의 경우에는 디스크가 하나 이상의 노드에 의해 호스트되는 디스크 장치 그룹에 포함되기 때문에 멀티호스트 디스크의 가용성이 높아집니다.

DID(장치 ID)

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

DID(장치 ID) 의사 드라이버는 클러스터의 글로벌 장치 액세스 기능을 위해 중요한 부분입니다. 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 12/01 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 디렉토리에 있습니다. 이 이름 공간은 각각 클러스터를 통해 가져온 VxVM 디스크 그룹을 위한 디렉토리와 Solstice DiskSuite 디스크 세트를 위한 디렉토리로 구성됩니다. 이 디렉토리는 해당 디스크 세트나 디스크 그룹에 있는 각 메타 장치나 볼륨에 대한 장치 노드를 하우징합니다.

SunPlex 시스템에서는 로컬 볼륨 관리자 이름 공간의 각 장치 노드가 /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)을 사용하여 클러스터 파일 시스템의 파일에 액세스할 수 있습니다.

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

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

클러스터 파일 시스템 사용

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

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

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

주 -

Sun Cluster 소프트웨어에서 반드시 클러스터 파일 시스템에 이름 지정 정책을 사용해야 하는 것은 아니지만, /global/disk-device-group과 같이 동일한 디렉토리 아래에 모든 클러스터 파일 시스템에 대한 마운트 포인트를 만들면 쉽게 관리할 수 있습니다. 자세한 내용은 Sun Cluster 3.0 12/01 소프트웨어 설치 안내서 및 Sun Cluster 3.0 12/01 시스템 관리 안내서를 참조하십시오.

클러스터 파일 시스템 기능

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

Syncdir 마운트 옵션

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

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

정족수 및 정족수 장치

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

클러스터 파티션에서는 브레인 분할 및 앰네시아 두 가지 유형의 문제가 발생합니다. 브레인 분할은 노드 사이의 클러스터 상호 연결이 끊어져서 클러스터가 하위 클러스터로 분할될 경우에 발생합니다. 그러면 각 하위 클러스터가 다른 파티션을 인식하지 못하고 자체 파티션만 있는 것으로 인식합니다. 이 문제는 클러스터 노드 사이의 통신 문제 때문에 발생합니다. 앰네시아는 클러스터가 종료된 후에 클러스터가 종료된 시간보다 오래된 클러스터 데이터를 사용하여 다시 시작할 경우에 발생합니다. 디스크에 여러 가지 프레임워크 데이터 버전이 저장되어 있을 경우에 최신 버전을 사용할 수 없으면 새로 구성된 클러스터가 시작될 때 이 문제가 발생할 수 있습니다.

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

표 3-3에서는 Sun Cluster 소프트웨어가 정족수를 사용하여 브레인 분할 및 앰네시아 문제를 해결하는 방법을 설명합니다.

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

파티션 유형 

정족수 해결 방법 

브레인 분할 

다수 표가 있는 파티션(하위 클러스터)만 클러스터로 실행되도록 합니다. 이 경우에 다수 표를 갖는 파티션은 하나만 있을 수 있습 니다. 

앰네시아 

클러스터가 부트될 때 최근 클러스터 멤버쉽의 구성원이었던 노드를 하나 이상 포함하도록 합니다. 그러면 최신 구성 데이터를 사용할 수 있습니다. 

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

정족수 표 계산

클러스터 노드와 정족수 장치가 모두 투표하여 정족수를 채웁니다. 기본적으로 클러스터 노드가 부트되어 클러스터 구성원이 되면 클러스터에 정족수 투표 수 하나가 증가합니다. 노드를 설치하는 중이거나 관리자가 노드를 유지 보수 상태로 전환한 경우에는 노드의 투표 수가 0이 될 수도 있습니다.

정족수 장치의 정족수 투표 수는 장치에 연결된 노드 수에 따라 결정됩니다. 정족수 장치가 설정되면 최대 투표 수 N-1개를 받습 니다. 여기서 N은 정족수 장치에 대한 포트가 있고 투표 수가 0이 아닌 노드 수입니다. 예를 들어, 투표 수가 0이 아닌 두 개의 노 드에 연결된 정족수 장치의 정족수 투표 수는 1(2-1)이 됩니다.

클러스터를 설치할 때 정족수 장치를 구성할 수도 있고 나중에 Sun Cluster 3.0 12/01 시스템 관리 안내서에서 설명하는 절차를 사용하여 정족수 장치를 구성할 수도 있습니다.

주 -

현재 정족수 장치가 연결된 노드 중에서 하나 이상의 노드가 클러스터 구성원인 경우에만 정족수 장치가 투표 수에 포함됩니다. 또한, 클러스터 부트 중에는 현재 정족수 장치가 연결된 노드 중 하나 이상이 부트되고 있어야 하고 최근 부트된 클러스터가 종료될때 노드가 이 클러스터의 구성원이었어야만 정족수 장치가 투표 수에 포함됩니다.

정족수 구성

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

그림 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 12/01 소프트웨어 설치 안내서 및 Sun Cluster 3.0 12/01 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 주소로, 나중에 원래 노드에서 자동으로 구성이 중지되고 다른 노드에서 구성이 시작됩니다.

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

확장 가능 데이터 서비스

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

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

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

동일한 노드에서 응용프로그램 인스턴스를 다시 시작할 수 없고, 사용되지 않는 다른 노드가 서비스를 실행하도록 구성되어 있으면, 서비스가 사용되는 않는 노드로 페일오버됩니다. 그렇지 않으면 계속 나머지 노드에서 실행되어 서비스 처리량이 감소할 수 있습니다.

주 -

각 응용프로그램 인스턴스에 대한 TCP 상태는 글로벌 인터페이스 노드에 보존되지 않고 인스턴스가 있는 노드에 보존됩니다. 따라서 글로벌 인터페이스 노드에 장애가 발생해도 연결에는 영향을 주지 않습니다.

그림 3-7은 페일오버 자원 그룹과 확장 가능 자원 그룹 및 확장 가능 서비스를 위한 둘 사이의 관계에 대한 예입니다. 이 예에는 세 가지 자원 그룹이 있습니다. 페일오버 자원 그룹에는 가용성이 높은 DNS를 위한 응용프로그램 자원과 가용성이 높은 DNS 및 가 용성이 높은 Apache Web Server에서 사용하는 네트워크 자원이 포함됩니다. 확장 가능 자원 그룹에는 Apache Web Server의 응용프로그램 인스턴스만 포함됩니다. 확장 가능 자원 그룹과 페일오버 자원 그룹 사이에는 자원 그룹 의존 관계가 있고(실선) Apache 응용프로그램 자원은 모두 공유 주소인 네트워크 자원 schost-2를 사용합니다(점선).

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

Graphic

확장 가능 서비스 아키텍처

클러스터 네트워킹의 기본 목적은 데이터 서비스에 확장성을 제공하는 것입니다. 확장성은 서비스에 요청되는 로드가 증가할 경우 에 증가하는 워크로드에 맞게 새로운 노드를 클러스터에 추가하고 새로운 서버 인스턴스를 실행하여 데이터 서비스가 일정한 응답시간을 유지하는 기능을 의미합니다. 이러한 서비스를 확장 가능 데이터 서비스라고 합니다. 확장 가능 데이터 서비스의 좋은 예로 웹 서비스가 있습니다.일반적으로 확장 가능 데이터 서비스는 각각 서로 다른 클러스터 노드에서 실행되는 여러 개의 인스턴스로 구성됩니다. 해당 서비스의 원격 클라이언트 관점에서는 이러한 모든 인스턴스가 하나의 서비스로 작동하면서 서비스의 기능을 구현합니다. 예를 들어, 서로 다른 노드에서 실행되는 여러 개의 httpd 데몬으로 확장 가능한 웹 서비스를 구성할 수 있습니다. 그러면 모든 httpd 데몬이 클라이언트 요청에 서비스를 제공할 수 있습니다. 요청에 서비스를 제공하는 데몬은 로드 밸런싱 정책에 의해 결정됩니다. 클라이언트에 응답이 전달될 때는 요청에 대하여 서비스를 제공하는 특정 데몬이 표시되는 것이 아니고 서비스로부터 전달되는 것처럼 표시되기 때문에 하나의 서비스로 표시됩니다.

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

다음 그림은 확장 가능 서비스의 아키텍처입니다.

그림 3-8 확장 가능 서비스 아키텍처

Graphic

글로벌 인터페이스를 호스트하지 않는 노드(프록시 노드)에는 자체 루프백 인터페이스에 대하여 호스트되는 공유 주소가 있습니다. 구성할 수 있는 로드 밸런싱 정책에 따라 글로벌 인터페이스에 전달되는 패킷이 다른 클러스터 노드에 분산됩니다. 구성할 수 있 는 로드 밸런싱 정책은 다음 단락에서 설명합니다.

로드 밸런싱 정책

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

확장 가능 데이터 서비스에는 pure 및 sticky 두 가지 서비스가 있습니다. pure 서비스는 포함된 모든 인스턴스가 클라이언트 요청 에 응답할 수 있는 서비스입니다. sticky 서비스는 클라이언트마다 동일한 인스턴스로 요청을 보내는 서비스입니다. 이 요청은 다른 인스턴스에 전달되지 않습니다.

pure 서비스는 가중(weighted) 로드 밸런싱 정책을 사용합니다. 이 로드 밸런싱 정책에서는 기본적으로 클라이언트 요청이 클러 스터의 서버 인스턴스에 고르게 분산됩니다. 예를 들어, 3-노드 클러스터에서 각 노드가 처리할 수 있는 로드의 크기가 1이라고 가정합니다. 각 노드는 해당 서비스를 위해 모든 클라이언트로부터 받는 요청의 1/3에 해당하는 서비스를 제공합니다. 관리자는 언제든지 scrgadm(1M) 명령 인터페이스나 SunPlex Manager GUI를 통해 노드의 처리량을 변경할 수 있습니다.

sticky 서비스에는 일반 sticky와 와일드카드 sticky 두 가지 종류가 있습니다. Sticky 서비스에서는 여러 번의 TCP 연결에 걸쳐 진행되는 동시 응용프로그램 레벨 세션이 상태 메모리(응용 프로그램 세션 상태)를 공유할 수 있습니다.

일반 sticky 서비스에서는 클라이언트가 여러 개의 동시 TCP 연결 사이에 상태를 공유할 수 있습니다. 서버 인스턴스가 단일 포트를 통해 서비스 요청을 받을 경우에 클라이언트 상태를 "sticky"라고 합니다. 서비스가 온라인 상태인 동안 인스턴스가 계속 실행되어 액세스할 수 있고 로드 밸런싱 정책이 변경되지 않으면, 클라이언트가 모든 요청을 동일한 서버 인스턴스로 보낼 수 있습니다.

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

sticky 정책을 일반화하면 동일한 인스턴스에서 백그라운드로 세션 정보를 교환하는 여러 개의 확장 가능 서비스로 확장됩니다. 이 턴스에서 백그라운드로 세션 정보를 교환하면, 동일한 노드에서 서로 다른 포트를 통해 서비스 요청을받는 여러 서버 인스턴스에 대하여 클라이언트가 "sticky"하다고 합니다.

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

와일드 카드 sticky 서비스는 동적으로 할당되는 포트 번호를 사용하지만, 그래도 클라이언트의 요청이 동일한 노드에 전달될 것이라고 예상합니다. 이러한 경우에는 클라이언트가 동일한 IP 주소의 여러 포트에 대하여 "sticky wildcard" 상태입니다.

이러한 정책의 좋은 예로 수동 모드 FTP가 있습니다. 클라이언트가 FTP 서버의 포트 21로 연결하면, 서버가 동적 포트 범위에 있 는 수신자 포트 서버에 다시 연결하도록 알립니다. 이 IP 주소에 대한 모든 요청은 서버가 제어 정보를 통해 클라이언트에 알려준것과 동일한 노드로 전달됩니다.

이러한 sticky 정책 각각에 대해 기본적으로 가중(weighted) 로드 밸런싱 정책이 적용됩니다. 따라서 클라이언트의 초기 요청은로드 밸런서가 지시하는 인스턴스로 전달됩니다. 클라이언트가 인스턴스를 실행하는 노드에 적응한 후에 계속 노드에 액세스할 수 있고 로드 밸런싱 정책이 변경되지만 않으면 이후의 요청이 노드에서 실행되는 인스턴스에 전달됩니다.

특정 로드 밸런싱 정책에 대한 자세한 내용은 아래 설명을 참조하십시오.

페일백 설정

자원 그룹은 한 노드에서 다른 노드로 페일오버됩니다. 그러면 초기의 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 서버는 동시 액세스를 동기화하도록 다시 구성해야 합니다.

끝으로, 인스턴스에 다른 인스턴스의 데이터와 분리된 개인용 데이터가 있을 수 있습니다. 이러한 경우에는 데이터가 개인용이므 로 해당 인스턴스만 이 데이터를 처리할 수 있기 때문에 서비스에서 동시 액세스를 동기화할 필요가 없습니다. 이 경우에는 나중에이 개인용 데이터에 대한 글로벌 액세스가 가능해질 수도 있기 때문에 이 개인용 데이터를 클러스터 파일 시스템에 저장하지 않도록 해야 합니다.

데이터 서비스 API 및 데이터 서비스 개발 라이브러리 API

SunPlex 시스템은 응용프로그램의 가용성을 높이기 위하여 다음과 같은 기능을 제공합니다.

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

응용프로그램 프로그래머가 Sun Cluster API를 사용하면 데이터 서비스 인스턴스를 시작하고 중지하는 스크립트와 결함 모니터를 개발할 수 있습니다. 이러한 도구를 사용하면 응용프로그램을 페일오버 또는 확장 가능 데이터 서비스로 구현할 수 있습니다. 또한 SunPlex 시스템은 응용프로그램을 페일오버 서비스나 확장 가능 서비스로 실행하기 위해 필요한 시작 및 중지 메소드를 신속하게 만들기 위해 사용할 수 있는 "일반" 데이터 서비스를 제공합니다.

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

클러스터에는 클러스터 상호 연결을 구성하는 여러 개의 네트워크 연결이 노드 사이에 있어야 합니다. 클러스터 소프트웨어는 가 용성을 높이고 성능을 향상시키기 위해 복수 상호 연결을 사용합니다. 내부 트래픽(예: 파일 시스템 데이터 또는 확장 가능 서비스 데이터)의 경우에는 메시지가 사용할 수 있는 모든 상호 연결을 통해 라운드 로빈 방식으로 스트라이프됩니다.

노드 사이에서 수행되는 통신의 가용성을 높이기 위하여 응용프로그램이 클러스터 상호 연결을 사용할 수도 있습니다. 예를 들어,분산 응용프로그램이 통신이 필요한 서로 다른 노드에서 구성 요소를 실행할 수 있습니다. 공용 전송 기능 대신 클러스터 상호 연 결을 사용하면 링크 하나에 장애가 발생해도 이러한 연결이 끊어지지 않습니다.

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

설치 중에 개인용 호스트 이름이 구성될 수 있기 때문에, 설치할 때 선택한 이름을 클러스터 상호 연결이 사용할 수 있습니다. 실제 이름은 scha_cluster_get(3HA) 명령에 scha_privatelink_hostname_node 인수를 사용하여 얻을 수 있습니다.

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

응용프로그램이 내부 클러스터 트래픽과 상호 연결을 공유하므로, 응용프로그램에 사용할 수 있는 대역폭은 다른 클러스터 트래픽 에 사용되는 대역폭에 따라 달라집니다. 장애가 발생할 경우에 내부 트래픽은 나머지 상호 연결로 라운드 로빈될 수 있고, 장애가 발생한 상호 연결의 응용프로그램 연결은 작동하는 상호 연결로 전환될 수 있습니다.

두 가지 유형의 주소가 클러스터 상호 연결을 지원하고, 개인용 호스트 이름에 대하여 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 웹 서버나 iPlanet 웹 서버와 같은 응용프로그램은 응용프로그램을 위해 네트워크 주소(논리 호스트 이름 및 공유 주소)를 사용합니다. 응용프로그램과 네트워크 자원이 RGM에 의해 관리되는 기본 단위를 구성합니다.

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

자원은 전체 클러스터에서 정의된 자원 유형의 인스턴스입니다. 몇가지의 정의된 자원 유형이 있습니다.

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

SUNW.HAStorage 자원 유형은 자원이 사용하는 디스크 장치 그룹과 자원의 시작을 동기화하는 데 사용됩니다. 이 자원 유형은 데이터 서비스를 시작하기 전에 클러스터 파일 시스템 마운트 포인트의 경로, 글로벌 장치 및 장치 그룹 이름을 사용할 수 있는지 확인합니다.

RGM에서 관리하는 자원은 하나의 단위로 관리할 수 있도록 자원 그룹이라는 그룹에 포함됩니다. 자원 그룹은 페일오버나 스위치오버가 자원 그룹에서 초기화된 경우에 하나의 단위로 이주됩니다.

주 -

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

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

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

자원 및 자원 그룹 등록 정보

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

표준 등록 정보는 보통 특정 데이터 서비스와 독립적인 자원 및 자원 그룹 등록 정보를 구성하는 데 사용됩니다. 표준 등록 정보 세트는 Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide의 부록에서 설명합니다.

확장 등록 정보는 응용프로그램 바이너리 및 구성 파일의 위치와 같은 정보를 제공합니다. 데이터 서비스를 구성할 때 확장 등록정보를 수정할 수 있습니다. 확장 등록 정보 세트는 Sun Cluster 3.0 12/01 Data Services Installation and Configuration Guide에서 데이터 서비스에 대하여 설명하는 각 장에서 설명합니다.

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

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

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

여러 개의 공용 네트워크 어댑터가 NAFO 그룹(네트워크 어댑터 페일오버 그룹)을 구성합니다. 각 NAFO 그룹에는 하나 이상의 공용 네트워크 어댑터가 있습니다. 각 NAFO 그룹에서 동시에 하나의 어댑터만 작동할 수 있고, 동일한 그룹에 속한 다른 어댑터는 PNM 데몬이 작동하는 어댑터에 대하여 결함을 발견하여 어댑터 페일오버가 발생할 경우에 사용되는 백업 어댑터 기능을 합니다.페일오버는 작동하는 어댑터와 연결된 IP 주소를 백업 어댑터로 전환하여 노드에 대한 공용 네트워크 연결을 유지합니다. 페일오 버는 어댑터 인터페이스 레벨에서 발생하기 때문에 TCP와 같은 고급 연결은 페일오버의 영향을 받지 않고 짧은 지연만 발생합니다.

주 -

페일오버 중에 일부 세그먼트가 손실될 수 있기 때문에 TCP의 혼잡 복구 특성으로 인해 TCP에서 혼잡 제어 메커니즘을 작동하기위해 성공적인 페일오버 후에 TCP 엔드포인트에 추가 지연이 발생할 수 있습니다.

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

주 -

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

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

PNM은 어댑터를 통과하는 정상적인 네트워크 트래픽 때문에 정상 어댑터의 패킷 카운터가 변경된다고 가정하고 작동 어댑터의 패킷 카운터를 주기적으로 확인합니다. 패킷 카운터가 일정 시간 동안 변경되지 않으면 PNM이 ping 시퀀스가 되어 트래픽을 강제로 현재 작동하는 어댑터로 보냅니다. PNM은 각 시퀀스의 끝에서 패킷 카운터의 변경을 확인하고, 핑 시퀀스가 여러 번 반복된 후에도 패킷 카운터가 변경되지 않으면어댑터 결함을 선언합니다. 이러한 이벤트가 발생하면 사용할 수 있는 백업 어댑터로 페일오버가 트리거됩니다.

입력 패킷과 출력 패킷의 카운터 모두 또는 두 패킷 카운터 중 하나가 일정 시간 동안 변경되지 않으면 핑 시퀀스가 시작되도록 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 12/01 시스템 관리 안내서에서 공용 네트워크 매개변수를 변경하는 절차를 참조하십시오.

NAFO 그룹의 작동 어댑터에서 결함이 발견된 후에 백업 어댑터를 사용할 수 없으면 그룹이 DOWN으로 선언되고 백업 어댑터에 대한 테스트가 계속됩니다. 그렇지 않고 백업 어댑터를 사용할 수 있으면 백업 어댑터로 페일오버가 발생합니다. 결함이 있는 작동어댑터가 중지되어 제거된 동안에는 논리 주소 및 관련 플래그가 백업 어댑터로 "이동"됩니다.

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

동적 재구성 지원

DR(동적 재구성) 소프트웨어 기능에 대한 Sun Cluster 3.0의 지원이 한 단계씩 개발되고 있습니다. 이 단원에서는 Sun Cluster 3.0 12/01의 DR 기능 지원에 대한 개념과 참고 사항을 설명합니다.

Solaris 8 DR 기능에 대하여 문서화된 요구 사항, 절차 및 제한은 모두 Sun Cluster DR 지원에 적용됩니다(운영 체제 작동 정지 제외). 따라서 Sun Cluster 소프트웨어에서 DR 기능을 사용하기 전에 Solaris 8 DR 기능에 대한 문서를 참조하십시오. 특히 DR 연결 종료 작업 중에 비네트워크 IO 장치에 영향을 주는 문제를 확인해야 합니다. Sun Enterprise 10000 Dynamic Reconfiguration User Guide 및 Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual(Solaris 8 on Sun Hardware 모음 중에 포함)은 http://docs.sun.com에서 다운로드할 수 있습니다.

동적 재구성에 대한 일반적인 설명

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

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

보드를 제거하면 보드에 있는 구성 요소를 사용하는 시스템의 기능이 중단됩니다. 보드를 제거하기 전에 DR 하위 시스템이 보드의 구성 요소가 사용되고 있는지 확인합니다. 사용하고 있는 장치를 제거하면 시스템에 장애가 발생할 수 있습니다. DR 하위 시스템이 장치를 사용하고 있는 것을 확인하면 하위 시스템이 DR 보드 제거 작업을 거부합니다. 따라서 항상 안전하게 DR 보드 제거 작업을 수행할 수 있습니다.

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

주 -

DR 하위 시스템에는 여러 레벨이 있습니다. 낮은 레벨에서 오류를 보고하면 상위 레벨도 오류를 보고합니다. 그러나 하위 레벨이 특정 오류를 보고하면 상위 레벨이 "Unknown 오류"를 보고합니다. 시스템 관리자는 상위 레벨에 의해 보고되는 "Unknown 오류"를 무시해야 합니다.

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

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

DR 보드 제거 작업이 보드에 있는 CPU에 영향을 줄 경우에는 DR 하위 시스템이 작업을 허용하고 이 CPU를 사용하는 노드를 자동으로 중지시킵니다.

DR 보드 추가 작업이 추가되는 보드의 CPU에 영향을 줄 경우에는 DR 하위 시스템이 이 CPU를 사용하여 자동으로 노드를 시작합니다.

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

DR의 목적을 위해 두 가지 유형의 메모리를 고려해야 합니다. 이 두 가지 유형은 용도만 다릅니다. 실제 하드웨어는 두 가지 유형이 동일합니다.

운영 체제에 사용되는 메모리를 커널 메모리 케이지라고 합니다. Sun Cluster 소프트웨어는 커널 메모리 케이지가 포함된 보드에 대해서는 보드 제거 작업을 지원하지 않고 이러한 작업은 모두 거부합니다. DR 보드 제거 작업이 커널 메모리 케이지가 아닌 메모리에 영향을 줄 경우에는 DR 하위 시스템이 작업을 허용하고 해당 메모리를 사용하는 노드를 자동으로 중단시킵니다.

DR 보드 추가 작업이 메모리에 영향을 줄 경우에는 DR 하위 시스템이 새 메모리를 사용하여 자동으로 노드를 시작합니다.

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

1차 노드에서 현재 작동하는 드라이브에 대한 DR 제거 작업은 허용되지 않습니다. 1차 노드에서 현재 작동하지 않는 드라이브와 2차 노드의 드라이브에 대한 DR 제거 작업만 수행할 수 있습니다. DR 작업 전후에 모두 클러스터 데이터 액세스는 계속됩니다.

주 -

정족수 장치의 가용성에 영향을 주는 DR 작업은 허용되지 않습니다. 정족수 장치에 대한 참고 사항과 정족수 장치에 대하여 DR 작업을 수행하기 위한 절차는 "정족수 장치에 대한 DR 클러스터링 참고 사항"을 참조하십시오.

다음 단계에서는 디스크나 테이프 드라이브에 대하여 DR 제거 작업을 수행하는 절차를 간략하게 설명합니다. 이 작업을 수행하기 위한 자세한 방법은 Sun Cluster 3.0 U1 System Administration Guide를 참조하십시오.

  1. 디스크나 테이프 드라이브가 현재 작동하는 장치 그룹에 포함되었는지 확인하십시오.

    • 드라이브가 현재 작동하는 장치 그룹에 포함되지 않았으면 드라이브에 대하여 DR 제거 작업을 수행할 수 있습니다.

    • DR 보드 제거 작업이 현재 작동하는 디스크나 테이프 드라이브에 영향을 줄 경우에는 시스템이 작업을 거부하고 작업의 영향을 받을 드라이브를 식별합니다. 장치가 현재 작동하는 장치 그룹에 포함되었으면 단계 2로 이동하십시오.

  2. 드라이브가 1차 노드의 구성 요소인지 아니면 2차 노드의 구성 요소인지 확인하십시오.

    • 드라이브가 2차 노드의 구성 요소이면 DR 제거 작업을 수행할 수 있습니다.

    • 드라이브가 1차 노드의 구성 요소이면 DR 제거 작업을 수행하기 전에 1차 노드와 2차 노드를 전환해야 합니다.

주의 - 주의 -

2차 노드에 대한 DR 작업을 수행할 때 현재 1차 노드에 장애가 발생하면 클러스터 가용성이 영향을 받습니다. 새로운 2차 노드가 제공될 때까지 1차 노드를 페일오버할 수 없습니다.

정족수 장치에 대한 DR 클러스터링 참고 사항

현재 정족수 장치로 구성된 장치에 대해서는 DR 제거 작업을 수행할 수 없습니다. DR 보드 제거 작업이 정족수 장치에 영향을 줄 경우에는 시스템이 작업을 거부하고 작업의 영향을 받을 정족수 장치를 식별합니다. DR 제거 작업을 수행하려면 정족수 장치의 기능을 비활성화해야 합니다.

다음 단계에서는 정족수 장치에 대하여 DR 제거 작업을 수행하기 위한 절차를 간략하게 설명합니다. 이 작업을 수행하기 위한 자세한 방법은 Sun Cluster 3.0 U1 System Administration Guide를 참조하십시오.

  1. DR 작업을 수행하는 장치가 아닌 다른 장치를 정족수 장치로 활성화하십시오.

  2. DR 작업을 수행하는 장치의 정족수 장치 기능을 해제하십시오.

  3. 장치에 대하여 DR 제거 작업을 수행하십시오.

독립 상호 연결 인터페이스에 대한 DR 클러스터링 참고 사항

현재 작동하는 독립 상호 연결 인터페이스에 대해서는 DR 작업을 수행할 수 없습니다. DR 보드 제거 작업이 현재 작동하는 독립 상호 연결 인터페이스에 영향을 줄 경우에는 시스템이 작업을 거부하고 작업의 영향을 받을 인터페이스를 식별합니다. 현재 작동하는 인터페이스를 제거하려면 먼저 비활성화해야 합니다(아래 주의 사항 참조). 인터페이스가 독립 상호 연결로 교체될 경우, 상태가 동일하게 유지되기 때문에 추가로 Sun Cluster를 재구성하는 단계가 필요없습니다.

다음 단계에서는 독립 상호 연결 인터페이스에 대하여 DR 제거 작업을 수행하기 위한 절차를 간략하게 설명합니다. 이 작업을 수행하기 위한 자세한 방법은 Sun Cluster 3.0 U1 System Administration Guide를 참조하십시오.

주의 - 주의 -

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

  1. DR 작업을 수행하는 상호 연결 인터페이스가 포함된 전송 케이블을 비활성화하면 안됩니다.

  2. 물리적인 독립 상호 연결 인터페이스에 대하여 DR 제거 작업을 수행하십시오.

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

현재 작동하지 않는 공용 네트워크 인터페이스에 대하여 DR 제거 작업을 수행할 수 있습니다. DR 보드 제거 작업이 현재 작동하는 공용 네트워크 인터페이스에 영향을 줄 경우에는 시스템이 작업을 거부하고 작업의 영향을 받을 인터페이스를 식별합니다. 먼저 현재 작동하는 공용 네트워크 인터페이스가 NAFO 그룹에 있는 현재 작동하는 어댑터 인스턴스 상태에서 제거되어야 합니다.

주의 - 주의 -

비활성화된 네트워크 어댑터에 대하여 DR 제거 작업을 수행하는 동안 현재 작동하는 네트워크 어댑터에 장애가 발생하면 가용성에 영향을 받습니다. DR 작업을 수행하는 동안에는 현재 작동하는 어댑터를 페일오버할 수 없습니다.

다음 단계에서는 공용 네트워크 인터페이스에 대하여 DR 제거 작업을 수행하기 위한 절차를 간략하게 설명합니다. 이 작업을 수행하기 위한 자세한 방법은 Sun Cluster 3.0 U1 System Administration Guide를 참조하십시오.

  1. 현재 작동하는 어댑터가 NAFO 그룹에서 제거될 수 있도록 백업 어댑터로 전환하십시오.

  2. NAFO 그룹에서 어댑터를 제거하십시오.

  3. 공용 네트워크 인터페이스에 대하여 DR 작업을 수행하십시오.