KR20000028685A

KR20000028685A - 클러스터 컴퓨터 시스템을 관리하기 위한 방법 및 장치

Info

Publication number: KR20000028685A
Application number: KR1019990039667A
Authority: KR
Inventors: 차오칭윤; 골패트릭엠.; 맥컬티리차드제임스
Original assignee: 포만 제프리 엘; 인터내셔널 비지네스 머신즈 코포레이션
Priority date: 1998-10-27
Filing date: 1999-09-15
Publication date: 2000-05-25
Also published as: CA2284376A1; KR100336729B1; US6393485B1; CA2284376C; TW497071B

Abstract

클러스터 컴퓨터 시스템은 속도와 신뢰성에 대한 장점 모두를 제공한다. 그러나 클러스터 컴퓨터들 간의 통신이 절충되면(compromised) 상기 컴퓨터들은 혼돈되고 데이터베이스 파일은 손상(corrupt)될 수 있다. 본 발명의 방법 및 장치는 클러스터 컴퓨터 시스템의 관리를 개선시키도록 사용된다. 특히, 시스템은 페일오버(failover) 조건용으로 사용 가능한 노드의 개수를 확장한다.

Description

클러스터 컴퓨터 시스템을 관리하기 위한 방법 및 장치 {METHOD AND APPARATUS FOR MANAGING CLUSTERED COMPUTER SYSTEM}

본 발명은 일반적으로 분산 데이터 처리 시스템(distributed data processing system)에 관한 것으로, 더욱 상세하게는, 분산 데이터 처리 시스템 내의 서버 시스템(server system)을 관리하기 위한 방법 및 장치에 관한 것이다. 더욱 상세하게는, 본 발명은 클러스터 컴퓨터 시스템(clustered computer system)을 관리하기 위한 방법 및 장치에 관한 것이다.

클러스터 컴퓨터 시스템은 상호 연결된 완전한 컴퓨터 시스템들(whole computer systems)의 집합(collection)으로 이루어져 있는 병렬 또는 분산된 형태의 시스템이며, 통합된 단일 계산 자원(computing resource)처럼 사용된다. 상기 정의에서 "완전한 컴퓨터"라는 용어는 독립적으로 사용 가능한 컴퓨터(stand-alone, usable computer)를 구성하는 일반 구성요소 즉, 하나 이상의 프로세서(processor), 허용 가능한(acceptable) 용량의 메모리, 입/출력 설비, 및 운영 체제(operating system)가 조합(combination)된 것을 의미한다. 클러스터와 일반 분산 시스템간의 차이는 요소들(parts) 간의 관계와 관련이 있다. 최신 분산 시스템은 피어 투 피어(peer-to-peer)인 하층 통신층(underlying communication layer)을 사용한다. 고유 계층(intrinsic hierarchy)이나 다른 구성은 존재하지 않고 통신 엔티티들(communicating entity)의 플랫 리스트(flat list)만이 존재한다. 그러나 추상적인 개념(abstraction)의 좀더 상위 레벨에서, 상기 통신 엔티티들은 일반적으로 클라이언트-서버 패러다임(client-server paradigm)으로 조직된다. 이것은 시스템의 복잡성을 가치 있게 감소시키는 결과를 초래한다. 전형적으로 클러스터는 피어 투 피어의 관계를 갖는다.

클러스터링(clustering)이 대중화(popularity)될 수 있도록 하는 세 개의 기술 경향은 다음과 같다. 첫 번째로, 마이크로프로세서가 점점 고속화된다. 마이크로프로세서가 보다 고속화 될수록, 대규모 병렬 시스템은 중요도가 보다 낮아진다. 결과를 적절히 빠르게 얻기 위해 수퍼-컴퓨터(super-computer)나 수천개의 마이크로프로세서의 집합체(aggregation)를 더 이상 사용할 필요가 없다. 클러스터 컴퓨터 시스템의 대중화를 가속화시키는 두 번째 경향은 컴퓨터들 간의 통신의 고속화가 향상됐다는 것이다. 파이버 채널 표준(Fibre Channel Standard; FCS), 비동기 전송 모드(Asynchronous Transmission Mode; ATM), 스케일러블 코히런트 인터커넥트(Scalable Coherent Interconnect; SCI), 및 교환 기가비트 이더넷(switched Gigabit Ethernet)과 같은 표준화된 통신 설비의 도입이 10메가비트/초에서 수백 메가 바이트/초 및 심지어 기가 바이트(gigabyte)/초까지 컴퓨터간의 대역폭(bandwidth)을 증가시키고 있다. 결국, 표준 도구(standard tool)가 분산 컴퓨팅(distributed computing)용으로 개발되었다. 분산 컴퓨팅의 요청에 의해 머신(machine)의 클러스터를 관리하는데 적합한 소프트웨어 도구의 집합이 만들어져 왔다. TCP/IP 및 UDP/IP라고 불리는 인터넷 통신 규약(protocol suite)과 같은 것들이 매우 일반적이어서 어디에나 있는 사실상의 표준(de facto standard)이 된다. 이러한 기반 위에서 개발된 인트라넷(intranet), 인터넷 및 월드 와이드 웹(World Wide Web)과 같은 상위 레벨 설비는 유사하게 어디에나 있게 된다. 더욱이, 다중 감지 관리(multisense administration)를 위한 다른 도구 셋트도 일반적이 되어 가고 있다. 또한, 이러한 것들은 클러스터 소프트웨어를 생성하도록 인도하는 유효한 기반이다.

이러한 세 개의 기술 경향 외에, 컴퓨터 클러스터에 대한 시장이 성장하고 있다. 본질적으로, 상기 시장은 높은 신뢰성을 갖는 계산을 요구한다. 이것을 다른 말로 하면 컴퓨터 네트워크는 "높은 가용성(high availability)"을 가져야 한다는 것이다. 예를 들면, 컴퓨터가 웹-사이트(web-site)의 호스트 역할을 하면, 상기 컴퓨터의 사용은 반드시 정상 업무시간으로만 한정되지 않는다. 바꾸어 말하면, 컴퓨터는 일년 내내 어느 시간이든지 액세스될 수 있다. 컴퓨터를 수리하기 위해 컴퓨터의 동작을 셧다운(shutdown)하는 안정된 시간(safe time)이 없다. 대신에, 클러스터 컴퓨터 시스템은 클러스터 내의 한 컴퓨터가 동작이 셧다운되면 컴퓨터가 수리될 때까지 클러스터 내의 다른 컴퓨터들이 동작이 셧다운된) 상기 컴퓨터의 임무를 자동으로 실행하므로 유용하다. 사용자에 의해 드러나거나 검출되는 고장 시간(down time)은 없다. 또한 비지니스(business)는 다른 이유에서도 높은 가용성을 필요로 한다. 예를 들면, 비지니스 대 비지니스 인트라네트(intranet)의 사용에는 하도급 계약자(subcontractor)나 공급자(vendor)에게 비지니스를 접속하는 것이 관련된다. 인트라넷의 파일 서버가 잠시 중지되면, 여러 비지니스의 업무는 큰 영향을 받는다. 비즈니스가 이동 인력(mobile workforce)을 보유하고 있다면, 상기 인력은 정보 및 메시지를 다운로드하기 위해 반드시 사무실과 접속할 수 있어야 한다. 사무실 서버가 다운되면, 상기 인력의 효율성(effectiveness)은 감소된다.

컴퓨터 시스템은 어느 하나가 페일하면 전체가 페일하는 경우에(single point of failure) 대체 장치(replaceable piece)가 없으면 전반적으로 유용하고, 대체로 다른 어떤 것이 고장나기 전에 고장난 부분을 수리할 수 있다는 것이 충분히 신뢰성이 있다. 높은 가용성을 얻기 위해 클러스터에서 사용된 기본 기술은 페일오버(failover)이다. 개념(concept)은 매우 단순하다(simple enough). 하나의 컴퓨터(A)가 다른 컴퓨터(B)를 감시한다(watch over); 컴퓨터 B가 고장나면, 컴퓨터 A가 컴퓨터 B의 업무(work)를 떠맡는다. 그래서, 페일오버는 한 노드에서 다른 노드로의 "자원(resource)" 이동을 필요로 한다. 노드(node)는 컴퓨터에 대한 다른 용어이다. 물리적인 디스크 소유권(physical disk ownership), 논리 디스크 볼륨(disk volume), IP 어드레스(address), 애플리케이션 프로세스(application process), 서브 시스템(subsystem), 프린트 큐(print queues), 공유 데이터 시스템(shared-data system)에서의 클러스터-와이드 로크(cluster-wide lock)의 집합 등과 같은 매우 다양한 종류의 것이 잠재적으로 포함된다.

자원은 서로 의존한다. 예를 들면 소정 노드가 사용하는 데이터가 다른 노드로 이동되면 상기 소정 노드로 애플리케이션을 이동시키는 것을 도와주지 않기 때문에 관계(relationship)에 문제가 발생한다. 필요한 디스크 볼륨이 장착되기 전에 애플리케이션이 시작되면 실제로 애플리케이션과 데이터 양자 모두는 상기의 동일한 노드로 이동시키는 것을 도와주지 않는다. IBM HACMP와 마이크로소프트사의 "울프팩(Wolfpack)"과 같은 최신 클러스터 시스템에서, 자원 관계 정보(resource relationship information)는 클러스터-와이드 데이터 파일(cluster-wide data file)에 유지된다. 서로 의존하는 자원은 자원 그룹으로서 조직되고 상기 데이터 파일에 계층적으로(as a hierarchy) 저장된다. 자원 그룹은 페일오버의 기본 유니트이다.

다음에 첨부된 도면, 특히 도 1을 참조하여, 본 발명이 실시될 수 있는 분산 데이터 처리 시스템을 명확하게 기술한다.

분산 데이터 처리 시스템(100)은 본 발명이 실시될 수 있는 컴퓨터 네트워크이다. 분산 데이터 처리 시스템(100)은 하나 이상의 공중망(public network; 101)을 포함하고, 자신 내에서 연결된 다양한 장치, 클라이언트 컴퓨터 및 서버 컴퓨터 간의 통신 링크를 제공하기 위해 사용된 매체(medium)이다. 네트워크(100)는 토큰 링(token ring), 이더넷, 100Mb 이더넷, 기가비트 이더넷, FDDI 링, ATM, 및 고속 스위치와 같은 상주 접속(permanent connection), 또는 전화 접속을 통해 이루어진 임시 접속(temporary connection)을 포함할 수 있다. 클라이언트 컴퓨터(130, 131)는 공중망(101)을 경유하여 서버 컴퓨터(110 내지 113)에 통신한다.

분산 데이터 처리 시스템(100)은 선택 사양으로(optionally) 자신의 전용 통신망(102)을 갖는다. 네트워크(102) 상의 통신은 상기 망(101)에서와 마찬가지로 표준 네트워크, 공유 메모리(shared memory), 공유 디스크(shared disk) 등과 같은 많은 수단을 경유하여 실행될 수 있다. 기술된 예에서, 많은 서버(110 내지 113)는 전용망(102) 뿐만 아니라 공중망(101) 양자 모두를 경유하여 서로 접속된다. 이러한 서버는 서로 하트비팅(heartbeating)하고 멤버쉽(membership) 및 n-위상 완료규약(n-phase commit protocols)을 실행하여 발생함으로써(resulting from) 통신 오버헤드(communication overhead)를 감소하도록 전용망(102)을 사용한다.

기재된 예에서, 모든 서버는 공유 디스크 저장 장치(124), 바람직하게는 사용자 애플리케이션 데이터를 저장하기 위해 사용되는 좀더 신뢰성 있는 RAID 장치에 접속된다. 서버가 실패하면(fail) 공유 디스크 분할(partition) 및 논리 디스크 볼륨은 다른 노드에 대해서도 실패할 수 있다는 점에서 데이터는 고 가용성(highly available)으로 만들어지므로, 데이터는 계속 이용 가능하게 된다. 공유 디스크 상호 접속은 SCSI 버스(bus), 파이버 채널, 및 IBM SSA가 될 수 있다. 대안적으로, 각 서버 머신(server machine)은 또한 로컬 데이터 저장 장치(local data storage device; 120 내지 123)를 구비할 수 있다. 도 1은 실시예로서 구성 된 것으로 본 발명에 따른 프로세스용으로 한정되게 구성된 것은 아니다.

도 2a를 참조하면, 마이크로소프트사가 첫 번째로 상업적으로 도입한 제품으로 코드명 "울프팩"인 마이크로소프트 클러스터 서버(Microsoft Cluster Server; MSCS) 200이 NT 서버-기반 애플리케이션(NT Server-based application)용으로 높은 가용성을 제공하도록 설계되어 있다. 초기의 MSCS는 두 개 노드(202, 204), 공유 디스크(208) 클러스터에서 페일오버 능력(capability)을 지원한다.

각 MSCS 클러스터는 하나 또는 두 개의 노드로 이루어진다. 각 노드는 마이크로소프트 클러스터 서버 중 상기 노드 자신의 복사본을 실행한다. 각 노드는 또한 클러스터 서버와 대화하는(interact) 하나 이상의 자원 모니터(Resource Monitor)를 구비한다. 이러한 모니터는 개별 자원(individual resource)의 상태에 대하여 "통지된(informed)" 클러스터 서비스(cluster service)를 유지한다. 필요하다면, 자원 모니터는 자원 DLL을 사용하여 개별 자원을 처리(manipulate)할 수 있다. 자원이 실패하면, 클러스터 서버는 자원 재시작 정책, 자원 그룹 페일오버 정책, 및 클러스터 상태에 따라 로컬 노드에서 자원을 재시작(restart)하거나 또는 다른 노드로 자원 그룹을 이동시킨다.

MSCS 클러스터내의 두 노드는 서로 하트비트(heart beat; 206)이다. 한 노드가 실패하면, 즉, 하트비트 신호를 다른 노드로 전송하는 것이 실패하면, 상기 노드의 모든 자원 그룹은 접속 상태를 유지하는(remaining) 노드에서 재시작 될 것이다. 클러스터 노드가 부팅(boot)되면, 클러스터 서비스는 사건 프로세서(event processor)의 제어 하에서 자동으로 시작된다. 다른 구성요소에 해당하는 사건 디스패칭을 하는 것 관한 사건 프로세서의 정규 역할(normal role) 외에, 상기 사건 프로세서는 초기화(initialization)를 수행하고 그런 다음 맴버쉽 매니저(membership manager)라고도 불리우는 노드 매니저(node manager)에게 클러스터를 결합하거나(join) 클러스터를 생성하도록 명령한다.

노드 매니저의 정규 작업(normal job)은 다른 노드 매니저와의 하트비트 변경(exchange)을 사용하여 클러스터 멤버쉽의 상태에 대한 일관성 뷰(consistent view)를 생성하도록 한다는 것이다. 이것은 윈도우 NT 레지스트리(registry)의 실제 부분(actually part)인(그러나 우리가 알게 되는 바와 같이, 상이하게 갱신(update)됨) 클러스터 구성 데이터베이스 내의 정보 복사본에 보관된 정보로부터 이들이 누구인지를 알아낸다. 노드 매니저는 초기에 다른 노드와 접촉하려고 시도한다. 상기 접촉 동작이 성공하면, 상기 노드 매니저는 클러스터를 결합하려고 시도하여 패스워드, 클러스터명, 클러스터 고유 식별부호(identification) 등의 인증(authentication)을 제공한다. 클러스터가 존재하고 소정 이유 때문에 결합하려고 하는 새로운 노드의 시도가 저지되면, 상기 노드와 노드 상에 위치된 클러스터 서비스는 셧다운된다.

그러나 결합하려는 노드의 요구에 아무도 응답하지 않으면, 노드 매니저는 새로운 클러스터에 대해 시작하도록 시도한다. 그것을 실행하기 위해, 노드 매니저는 구성 데이터베이스내의 모든 자원 같이 특정화된, 소위 쿼롬 자원(quorum resource)이라고 불리는 특정 자원(special resource)을 사용한다. 모든 클러스터에는 정확히 하나의 쿼롬 자원이 존재한다. 이것은 실제로 디스크이고, 디스크인 경우 여분의(redundant) 어댑터(adapter)를 부착하여 멀티-포트(multi-port)되는 것뿐만 아니라 상기 디스크를 이중화(mirror)하거나 또는 고장을 허용하도록(fault tolerant) 하는 것이 바람직하다. 그렇지 않으면 클러스터 중 어느 하나가 페일나면 전체가 페일될 수 있다(a single point of failure for the cluster). 쿼롬 자원으로서 사용된 장치는 다음 세 개의 성질을 갖는 임의의 것이 될 수 있다. 상기 세 개의 성질은 실패하더라도(across failure) 데이터를 영구 저장할 수 있고; 다른 클러스터 노드는 상기 장치로부터 얻을 수 있고, 상기 장치는 다른 모든 것을 제외하고 어느 한 노드에 의해 점유(seize)될 수 있다. SCSI와 SSA 및 FC-AL과 같은 다른 디스크 통신규약(protocol)은 정확하게 이러한 동작을 고려한다.

쿼롬 자원은 실제로 클러스터를 위한 광역 제어 로크(global control lock)이다. 성공적으로 쿼롬 자원을 점유한 노드만이 유일하게 클러스터를 정의한다. 다른 노드는 클러스터 부분(part)이 되도록 클러스터와 반드시 결합되어야 한다. 이러한 규제(prohibit)가 분할 클러스터의 문제이다. 서로 통신할 수 없는 두 부분(part)내에 존재하는 클러스터를 중단시키는(brake) 소정 방식에서 내부 클러스터 통신이 실패할 수도 있다. 쿼롬 자원을 제어하는 노드는 상기 쿼롬 자원을 소유한 클러스터이지 다른 클러스터는 존재하지 않는다.

일단 노드가 클러스터를 결합하거나 클러스터를 형성하면, 다음에 해야할 것은 상기 클러스터와 접속이 끊어져 있던 동안에 발생된 변경을 반영하도록 상기 노드 구성 데이터베이스를 갱신하는 것이다. 물론 상기 데이터베이스에 대한 변경은 모든 노드에 걸쳐 일관성있게 트랜잭션 시맥틱스(transactional semantics)를 반드시 따라야 하고, 이러한 경우에 쿼롬 장치에 저장된 모든 변경 로그(log)를 유지하기 때문에 구성 데이터베이스 매니저는 이것을 실행할 수 있다. 쿼롬 자원 로그를 처리한 후에, 새로운 노드는 자원을 요구하기 시작한다. 상기 자원은 디스크, IP 이름, 네트워크 이름(network name), 애플리케이션이 될 수 있고, 또는 오프라인(off-line)이나 온라인(on-line)이 될 수 있다. 상기 자원이 실행되는 것이 바람직한 노드, 자원이 실행될 수 있는 노드(어떤 것은 적당한 디스크나 네트워크에 연결될 수 없음), 자원간의 관계, 및 그밖에 상기 자원에 관한 모든 것과 함께 상기 자원은 구성 데이터베이스에 모두 리스트된다. 자원은 전형적으로 자원 그룹내에 형성되고 자원 그룹으로서 관리된다. 예를 들면, IP 어드레스, 파일 공유(파일 시스템의 공유 가능 유니트), 및 로직 볼륨은 클라이언트에 네트워크 파일 시스템을 제공하는 자원 그룹의 중요한 요소(key element)가 될 수 있다. 종속성(dependency)은 추적(track)되고, 자원은 하나 이상의 자원 그룹 일부가 될 수 없다. 그래서 두 개의 애플리케이션이 동일한 자원 그룹 내에 존재하지 않을 경우 이러한 두 애플리케이션에 의한 자원 공유는 금지된다.

자원이 새로운 노드로 이동(페일오버)하는 것을 실행하도록(figure out) 새로운 노드의 페일오버 매니저가 호출된다. 상기 매니저는 다른 노드 페일오버 매니저와 절충하여(negotiate) 상기 동작을 실행하고 자원에 적합한 노드(resource's preferred node)와 같은 정보를 사용한다. 상기 다른 노드의 페일 오버 매니저가 집합 결정(collective decision)을 하면, 다른 노드에서 상기 새로운 노드로 이동해야 하는 임의의 자원 그룹은 상기 다른 노드 상에서 오프라인된다(taken off-line). 노드 이동이 완료되면, 자원 매니저는 새로운 노드 상에서 온-라인으로 상기 자원 그룹을 가져오기 시작한다.

데이터베이스 소프트웨어의 모든 주 공급자는 다중 NT 서버를 거처(across) 동작하는 자신의 데이터 베이스 버전(version)을 갖는다. IBM DB2 확장 엔터프라이즈 에디션(Extended Enterprise Edition)은 32 노드 상에서 실행한다. IBM PC사는 오라클 패러럴 서버(Oracle Parallel Server)를 실행하는 6-노드 PC 서버 시스템을 판매해왔다(has shipped). 이러한 보다 대형의 클러스터용 소프트웨어를 클러스터링하는 적당한 시스템이 존재하지 않는다.

6-노드 오라클 패러럴 서버 시스템에서, 이러한 6 노드는 공통의 디스크 저장 장치를 공유한다. 오라클은 자원을 관리하고 로드의 균형을 조절하고(load balancing)과 고장 회복(failure recovery)을 수행하기 위해 자신만이 갖는 특징을 구비한 클러스터링을 사용한다. 자신의 클러스터 상에서 자신의 애플리케이션 소프트웨어를 실행하는 고객(customer)은 자신의 애플리케이션의 가용성을 높이기 위하여 시스템 클러스터링 특징을 필요로 한다.

도 2b를 참조하면, DB2는 일반적으로 각 노드(212)가 자신 소유의 데이터 저장 장치(214)를 구비하고 있고 공유하지 않는 아키텍쳐(share nothing architecture; 210)를 사용한다. 데이터베이스는 분할되고 데이터베이스 요구는 병렬 처리를 위해 모든 노드로 분산된다. 가용성을 높이기 위하여, DB2는 시스템 클러스터링으로부터 페일오버 기능(failover functionality)을 사용한다. MSCS가 단지 두 개의 노드만을 지원하기 때문에, DB2는 도시된 바와 같이 각 노드(212)에 대해 대기 노드(standby node; 216)를 각각 할당해야 한다. 대안적으로, DB2는 도 2c에 도시된 바와 같이 각 한 쌍의 MSCS 노드 간에 상호 페일오버(mutual failover)가 이루어질 수 있도록 한다. 즉, 두 개의 노드(212, 212a)는 두 개의 데이터 저장 장치(214, 214a)에 상호 연결된다. 전자의 경우에는 시스템의 비용이 두 배로 증가하고 후자의 경우에는 노드가 실패하면 성능이 저하되는 문제가 발생한다. 데이터베이스 액세스가 모든 노드로 분산되고 병렬로 처리되기 때문에, DB2 인스턴스(instance)와 페일오버된 인스턴스 모두를 실행하는 노드는 성능을 감소시키는 원인(performance bottleneck)이 된다. 즉, 노드(212a)가 실패하면, 노드(212)는 상기 노드(212a)의 임무를 떠맡고 양쪽의 데이터 저장장치 상에서 데이터를 액세스한다. 그리고 병렬로 노드(212)의 태스크(task)를 실행한다.

그러므로, 본 발명의 장점은 클러스터 컴퓨터 시스템을 관리하기 위한 향상된 방법 및 장치를 구비하는 것이다. 이러한 향상은 한 노드에서 많은 노드를 구비한 그룹으로부터 선택된 다른 노드로의 페일오버를 지원하도록 해야 한다.

도 1은 본 발명이 실시될 수 있는 분산 데이터 처리 시스템도.

도 2a 내지 도 2c는 마이크로소프트 울프팩(Microsoft Wolfpack)과 그것의 실시 제한을 예시하는 도.

도 3, 도 3a 내지 도 3d는 본 발명을 예시하고 MSCS 클러스터와 같은 다중 클러스터를 지나는(across) 본 발명의 실시 예시도.

도 4, 도 4a 내지 도 4b는 다중 클러스터를 제어하도록 본 발명에 의해 사용된 언더라잉(underlying) 방법의 순서도.

도 5 및 도 6은 본 발명에서 사용된 예시 구성, 상태, 및 사건 프로세싱 규칙(event processing rules) 포함하는 SQL 테이블.

IBMCS로서 알려진 본 발명은 클러스터 컴퓨터 시스템을 관리하기 위한 방법 및 장치를 제공하고 매우 커다란 클러스터로 MSCS 클러스터링을 확장한다. 본 발명은 보다 커다란 클러스터를 관리하도록 마이크로소프트 클러스터 매니저 기능을 확장하지만 사용 편리 특성(ease-of-use characteristic)을 유지한다. 본 출원서에 기재된, "다중-클러스터(multi-cluster)" 또는 "IBMCS 클러스터"는 하나 이상의 다른 클러스터나 노드를 갖는 클러스터를 지칭한다. 일 실시예에서, 다중 클러스터는 하나 이상의 노드로 이루어질 수 있는 MSCS 클러스터를 하나 이상 갖는 클러스터이다.

시스템 클러스터링 제품(system clustering product)은 두 개 이상의 노드를 갖는 클러스터로 MSCS를 확장한다. 또한, 본 발명의 클러스터 시스템은 두 개 이상의 노드를 갖는 보다 커다란 클러스터에서 임의의 두 노드 간의 자원 그룹 페일오버를 지원한다. 본 발명의 시스템은 또한 실패 사건의 경우에 클러스터 전체에 대한(across) 애플리케이션 상태 정보를 유지한다. 또한, 본 발명의 시스템은 MSCS의 실시를 변경하지 않고 이 시스템의 환경에서 실행시키기 위해 마이크로소프트 및 애플리케이션 공급자에게 클러스터링 코드를 수정하도록 요구하지 않는다. 대신에, 본 발명의 시스템은 MSCS 클러스터 API DLL과 호환 가능한 이진수인 NSCS 클러스터 API DLL의 실시를 제공한다.

IBMCS 클러스터는 한 쌍 이상의 MSCS 클러스터를 일반적으로 포함한다. IBMCS 클러스터 매니저는 IBMCS 클러스터와 상기 IBMCS 내에 다수의 MSCS 클러스터를 구성할 수 있다. IBMCS 클러스터에서의 자원은 클러스터 서비스의 감독 하에 각 개별저인 MSCS 클러스터에 의해 관리된다. 마이크로소프트 자원 API 및 마이크로소프트 클러스터 관리자(administrator) 확장 API를 수정할 필요가 없다. IBMCS 클러스터 매니저는 수정할 필요없이 MSCS용으로 개발된 임의의 클러스터 관리자 확장 DLL을 사용할 수 있다.

MSCS용으로 향상됐거나 그렇지 않던지 간에, 애플리케이션은 IBMCS 시스템 클러스터링 특징을 용이하게 이용할 수 있다. 한 쌍의 노드간의 상호 페일오버 대신에, IBMCS는 보다 커다란 클러스터에서 임의의 두 노드 간의 애플리케이션 페일 오버를 허용한다. 본 발명은 클러스터가 한 쌍의 노드나 단일 노드 중 어느 한 형태의 노드를 갖는 MSCS 클러스터를 부가하여 크기를 키울 수 있도록 한다. 본 발명이 세 개의 노드를 갖는 클러스터를 지원할 수 있다는 사실은 두 노드의 클러스터를 초과하는 자신의 미션 임계 애플리케이션으로(mission critical application)의 가용성을 좀더 향상시키길 원하는 고객들에게는 매우 매력적이다.

MSCS를 사용하는 DB2 확장 엔터프라이즈 에디션과 같은 애플리케이션은 IBMCS 시스템 클러스터링 특징을 용이하게 이용할 수 있다. DB2/EEE는 쌍으로 노드를 나누어 MSCS 특징을 이용하고(exploit) 도 2c를 참조하여 상기 기술된 것처럼 각각 한 쌍의 노드간에 상호 페일오버를 허용한다. 본 발명은 N-웨이(N-way) 페일오버를 지원하여 DB2 가용성을 향상시킬 수 있거나 하나의 독립 노드를 갖는 N+1 모드를 지원하여 DB2 성능 특성(performance characteristic)을 향상시킬 수 있다. 단일 노드 실패의 가장 일반적인 사건에서, 실패된 노드 상의 DB2/EEE 인스턴스는 독립 노드 상에서 재시작되고 상기 N+1 모드에서와 동일한 성능을 유지한다. 시스템 관리 정책과 회복 서비스는 애플리케이션 공급자로부터의 특정 요구에 따라 용이하게 응할 수 있도록 수정될 수 있는 고레벨 언어로 표현된다. 예를 들면, DB2/EEE가 MSCS 클러스터보다 보다 나은 다중-클러스터를 구비하여 집적되도록 한다.

본 발명의 특징이라고 여겨지는 새로운 특징은 추가된 청구범위에 기재된다. 그러나 본 발명의 추가적인 목적과 장점, 바람직한 실시예뿐만 아니라 본 발명 자체는 첨부된 도면과 함께 다음에 이어지는 본 발명의 예시적인 실시예의 상세한 설명을 참조함으로써 가장 잘 이해될 것이다.

도면들, 특히 도 3을 참조하면, 본 발명이 실시될 수 있는 분산 데이터 처리 시스템이 도시된다. 도 3, 도 3b 및 도 3c에 도시된 소프트웨어(300)는 도 3a에 도시된 하드웨어 상에서 실시될 수 있다.

IBMCS 소프트웨어는 용이하게 크기를 좀더 크게 할 수 있다. 예를 들면, 도 3a는 8-노드 구성을 도시한다. 여기서 각 노드(350)는 디스크 제어기(360)에 의해 저장 요소(340)에 연결된다. IBMCS 클러스터 서비스는 상기 8-노드 클러스터내에서 임의의 두 노드간에 페일오버가 이루어지도록 한다. 이것은 상술된 오라클 클러스터나 DB2 클러스터 모두에서 사용될 수 있다. 7노드 중 임의의 노드가 실패할 경우에, DB2 인스턴스는 8번째 노드 상에서 재시작되고 시스템 성능은 변경되지 않고 유지된다. 이것을 N+1 페일오버 모델이라고 한다. 다른 구성도 또한 지원된다. 예를 들면 각 노드는 활성중인(active) DB2 인스턴스를 실행할 수 있고 신뢰성을 최대로 하기 위해 다른 7 노드용으로 백업될 수 있다.

IBMCS는 자원 관리를 수행하도록 MSCS를 사용한다. 마이크로소프트는 윈도우 NT에서 외부의 공급자와 자신의 자원 관리(APIs)를 공유하지 않고 다른 공급자가 자원 관리를 용이하게 수행하는 방식은 존재하지 않는다. 소정 공급자가 자신의 장치 드라이버와 TCP/IP 통신규약 스택을 실시했다. 이것은 MSCS 클러스터 API 및 자원 API와는 비호환성(incompatibility)을 초래한다. 본 발명은 단일 노드 상에서 자원을 관리하도록 MSCS를 사용하므로, 내부 NT API를 알 필요가 없다. IBMCS 304는 노드(350) 상에서 온-라인 또는 오프-라인으로 자원과 자원 그룹을 가져오도록 MSCS 306을 제어한다. 도 3을 참조하면, IBMCS(304)가 상이한 노드(350, 350a) 상에 위치된 MSCS(306, 306a)를 제어하는 것이 도시된다. IBMCS(304)는 오프-라인으로 애플리케이션(370)을 포함하는 자원 그룹을 가져오기 위해 MSCS(306)를 획득하고 이후 온-라인으로 상기 자원 그룹을 가져오기 위해 MSCS(306a)를 획득한다. IBMCS는 클러스터 노드 멤버쉽, 하트비트, 노드간 통신(inter-node communication)을 관리하고, 8 노드 모두를 위한 클러스터 구성 데이터베이스의 일관성(consistency)을 유지할 책임이 있다. IBMCS는 또한 사건 통지(event notification) 및 사건 프로세싱의 책임이 있다. 클러스터 매니저(302)는 그래피컬 사용자 인터페이스(graphical user interface; GUI)를 제공한다.

IBMCS는 대체로 MSCS와 호환 가능한 이진수(binary)이다. 상기 애플리케이션이 MSCS 클러스터에서 실행될 수 있는 경우 IBMCS 클러스터에서 임의의 애플리케이션을 실행하기 위해 변경이 요구되지 않는다. IBMCS는 모든 MSCS 클러스터 API, 자원 API, 및 관리자 확장 API(administrator Extension API)를 지원한다.

도 3b 및 도 3c를 참조하면, IBMCS 클러스터에서, 각 노드는 IBMCS 클러스터 서비스의 복사본을 실행한다. 노드(350)가 부팅되면, IBMCS 클러스터 서비스(304)는 자동으로 시작된다. 그런 다음 MSCS 클러스터 서비스(306)는 IBMCS에 의해 시작된다. 본 명세서에서, MSCS 서브 클러스터로서 IBMCS 클러스터 내의 이들 MSCS 클러스터를 참조한다. IBMCS 클러스터 구성 데이터베이스내의 구성 정보는 각 MSCS 서브 클러스터내의 정보에 대한 수퍼 셋트(super set)이다. 모든 자원과 자원 그룹은 IBMCS 구성 데이터베이스 및 적절한 MSCS 서브 클러스터 내에서 정의된다. MSCS 서브 클러스터 서비스가 시작되면, 디폴트 클러스터 그룹(default cluster group)을 제외한 모든 자원 및 자원 그룹은 오프-라인 상태로 남는다. 새로운 노드 상의 IBMCS 클러스터 서비스(304)는 다른 모든 노드 상에서 IBMCS 인스턴스를 갖는 CSQL_서비스 그룹(315)을 통해 자원 그룹이 상기 새로운 노드 상에서 시작되어야 하는지를 총괄적으로(collectively) 결정한다. 그런 다음 IBMCS 클러스터 서비스(304)는 온-라인 상태로 상기 자원 그룹을 가져오도록 MSCS 클러스터 서비스 API를 호출한다(invoke).

각 MSCS 서브 클러스터는 한 쌍의 노드나 단일 노드 중 어느 하나로 이루어져 있다. 단일 노드로 이루어진 MSCS 서브 클러스터의 경우에, MSCS 쿼롬 자원은 자신이 상기 단일 노드의 로컬 디스크(local disk)임을 의미하는 로컬 쿼롬 자원(local quorum resource)으로서 구성될 수 있다. 이것은 매 MSCS 서브 클러스터에서 공유 디스크를 절약할 수 있는 바람직한 구성이다.

MSCS는 자신의 동작이 종결되는 마지막 시점에 자원과 자원 그룹의 상태를 기억하는 독특한 특징을 갖는다. 노드가 재시작되면, MSCS 클러스터 서비스는 자신의 자원과 자원 그룹을 이전 상태로 되게 할 것이다. 자원과 자원 그룹을 자신들의 온-라인 및 오프-라인 상태로 되도록 하는 결정은 IBMCS에 의해 이루어진다. MSCS 서브 클러스터(또는 MSCS 서브 클러스터를 실행하는 노드)가 실패하는 경우, IBMCS 클러스터 서비스는 소정의 다른 MSCS 서브 클러스터의 노드 상에서 실행되는 자신의 자원과 자원 그룹을 재시작할 것이다. 실패된 노드 및 그에 대응하는 MSCS 서브 클러스터가 재시작되고 IBMCS 클러스터를 재결합할 때, 새로운 노드 및 새로운 MSCS 서브 클러스터가 온-라인 상태로 자신의 자원과 자원 그룹을 가져오려고 시도하는 경우 자원 충돌(resource conflict)이 발생할 것이다. 이러한 문제를 해결하기 위해, IBMCS 클러스터 서비스는 매 자원 그룹 내에 "숨은(hidden)"자원을 부가했고 상기 숨은 자원은 상기 자원 그룹내의 다른 모든 자원에 대해 독립적인 자원이 되도록 하였다. 상기 숨은 자원은 IBMCS 클러스터 구성 데이터베이스 내의 자신의 자원 그룹의 상태를 체크할 것이고 자신의 자원 그룹이 이미 다른 MSCS 서브 클러스터 상에서 실행중인 경우 시작 동작이 실패하도록 할 것이다.

IBM 클러스터 서비스는 두 개 이상의 노드에 대한 높은 가용성의 시스템 클러스터링 특징을 확장하고 MSCS 클러스터 서비스와 이진수의 호환성을 유지한다(preserve). 이러한 기술은 보다 커다란 클러스터를 생성하는 다른 회사뿐만 아니라 마이크로소프트사로부터 입수 가능한 미래의 클러스터링 소프트웨어에 적용될 수 있다.

도 3b 및 도 3c를 참조하면, 본 발명의 클러스터링 소프트웨어(300)는 클러스터 매니저(302)와 클러스터 서비스(IBMCS)(304)인 두 개의 주요 부분으로 이루어져 있다. 클러스터 매니저(302)는 클러스터(306) 그룹내의 모든 자원을 관리하고 사용자에게 단일 클러스터 이미지를 제시하도록 설계된다. 클러스터 매니저(302)는 정보기술(Information Technology; IT) 관리자에게 사용 편리 사용자 인터페이스(easy-to-use user interface)를 제공한다. 클러스터 매니저(302)는 관리자가 클러스터 내에서 규모가 크고 복잡한 높은 가용성의 자원에 대한 집합을 유효하고 효과적으로 관리하도록 한다.

클러스터 서비스(304)는 클러스터내의 각 컴퓨터(350) 상에서 실행하는 미들웨어 계층(middle-ware layer)이다. 이것은 상주하는 마이크로소프트 윈도우 NT 서버나 다른 적합한 서버 상에서 실행되는 한 셋트의 실행 가능한 것(executable)과 라이브러리(library)를 포함한다. IBMCS(304)는 상호 실행하는 서브 시스템(inter-acting sub system)의 집합을 포함한다. 이러한 서브 시스템은 토폴로지 서비스(Topology Service; 308), 그룹 서비스(Group Service; 300), 클러스터 조정자(Cluster Coordinator)(도시되지 않음), CSQL 서비스(314), 사건 어댑터(Event Adapter; 310), 회복 서비스(Recovery Service; 316), 및 클러스터 API(318)이다.

클러스터 조정자는 클러스터 서비스(304)의 시작, 중지, 및 재시작을 위한 설비를 제공한다. 클러스터내의 각 컴퓨터 상에는 하나의 클러스터 조정자가 존재하지만, 상기 클러스터 조정자는 서로 통신하지 않으며, 상기 클러스터 조정자 각각의 유효 범위(scope)는 클러스터 조정자 각각이 실행되는 컴퓨터로 한정된다. 클러스터 조정자는 처음 시동되어야 하는 구성요소이다. 그런 다음 단독 모드(stand-alone mode)에서의 CSQL 서비스(314), 토폴로지 서비스(308), 그룹 서비스(300), 클러스터 모드에서의 CSQL 서비스(314), 회복 서비스(316), 마이크로소프트 클러스터 서비스(MSCS) 사건 어댑터, MSCS, 및 그룹 서비스 사건 어댑터(GSEA) 순으로 다른 서비스가 동작하도록 한다. 또한, 상기 클러스터 조정자는 다른 서비스를 각각 모니터하고, 실패할 경우에 다른 모든 서비스와 사용자 애플리케이션을 종료하여 IBMCS 클러스터 서비스를 재시작한다.

토폴로지 서비스(308)는 노드가 활성상태이고 적절하게 실행 중인지를 판단하기 위해 사용되는 하트비트(heartbeat)라고 하는 특정 메시지(special message)를 전송한다. 각 노드는 자신과 이웃한 노드의 하트 비트를 체크한다. 클러스터의 구성에 관한 지식(knowledge)과 대체 경로(alternate path)를 통해, 토폴로지 서비스(308)는 하트 비트의 손실(loss)이 어댑터 실패나 노드 실패를 표시하는지를 판단할 수 있다. MCSC의 노드간 하트비트는 다중 클러스터 와이드(multi-cluster wide)인 토폴로지 서비스 하트 비트를 위하여(in favor of) 무시된다. 토폴로지 서비스는 어느 노드를 다른 어느 노드들이 이용할 수 있는지에 대한 정보를 유지하고, 상기 정보는 신뢰성 있는 메시징 설비를 구성하도록 이용된다.

그룹 서비스(300)는 클러스터내의 동일하거나 상이한 머신들상에 프로세스를 포함하는 프로세스 그룹의 형성을 허용한다. 프로세스는 제공자(provider)나 가입자(subscriber)로서 그룹을 결합할 수 있다. 가입자가 그룹의 상태나 멤버쉽(제공자 목록)에 대한 변경에 대하여 통지 받는 동안, 아래에 상세하게 기술된 것처럼, 제공자는 그룹에서 통신규약에 따라 동작한다(participate in protocol action). 그룹 서비스(300)는 프로세스 그룹과의 결합과 상기 프로세스 그룹에 대한 프로세스의 결합(joint)과 떠남(leave)에 대한 통지를 지원한다. 또한 그룹 서비스(300)는 클러스터의 모든 노드 상태를 얻기 위하여 가입할 수 있는 호스트 그룹을 지원한다. 이러한 상태는 토폴로지 서비스에 의해 유지된 노드 상태 정보에 대한 일관성 뷰(view)이다.

멀티 클러스터 내의 모든 MSCS 서브 클러스터는 바람직하게 단일 노드 클러스터로서 구성된다. 그룹 서비스는 노드 업(node up) 사건과 노드 다운(node down) 사건을 모니터링하기 위해 사용된다.

그룹 서비스는 또한 실패나 복구(reintegration) 시나리오(scenarios)를 취급하도록 클러스터-인식 애플리케이션(cluster-aware application)을 위해 프로세스 결합(process join), 자발적이고(voluntary) 및 비자발적인(involuntary) 프로세스 떠남(process leave), 프로세스 퇴출(process expel), 그룹 상태 변경(group state change), 및 제공자 동보통신 메시지(provider broadcast message)를 위한 어토믹 동보(atomic broadcast) 및 n-위상 완료규약(n-phase commit protocol)과 같은 설비를 제공한다. 이러한 설비는 신뢰성 있는 메시징 설비의 최상부(top)에 설치된다.

그룹 서비스(300)는 다음 방식으로 클러스터의 분할동작을 취급한다. 분할된 클러스터가 통합되는(come together) 것을 그룹 서비스(300)가 인식하면, 그룹 서비스(300)는 보다 적은 수(the lesser number)의 클러스터 머신을 갖는, 분할 부분인 모든 그룹으로 해제 통지(dissolve notification)를 발생한다. 양쪽 분할 모두 동일한 수의 클러스터 머신을 갖는 경우, 그들 중 하나는 해제되도록 선택된다.

CSQL 서비스(314)는 구성과 상태 정보를 포함할 수 있는 데이터베이스를 위한 지원을 제공한다. 상기 CSQL 서비스(314)는 독립 모드 및 클러스터 모드 모두에서 작동할 수 있다. 데이터베이스 각각은 그룹 서비스(300)를 이용하여, 코히런트(coherent)되고 높은 가용성을 갖는 불변하는(persistent), 분산된 자원이다. 각각 데이터베이스는 모든 노드에 걸쳐 복사되고 디스크에 대한 체크점이 되어(check pointed) 변경은 IBMCS의 재부팅에 의해(across) 얻어진다. CSQL 서비스(314)는 각 노드가 동일한 데이터 복사본을 구비할 수 있도록 한다. CSQL은 또한 재부팅에 의해서는 지속되지 않지만 모든 노드 상에서 일관성 있는 일시적인 형태의 데이터를 지원한다. 일시적인 데이터(transient data)는 클러스터 서비스(304)가 재시작된 후에 시동값(startup value)에 의해 초기화된다. CSQL 서비스(314)는 데이터베이스에서 발생된 변경에 대한 통지를 지원한다. 각각의 데이터베이스는 세 개의 투플 즉, 데이터베이스가 마지막으로 수정됐을 때를 표시하는 타임스탬프(timestamp), 수정을 제안한 노드의 ID, 및 CRC 체크섬(checksum)으로 이루어진 투플(tuple)로 구분될 수 있다. 상기 타임스탬프는 전체 클러스터에 대해(across) 단조 증가하는 숫자인 논리 시간이다. CSQL 서비스(314)는 클러스터 재시작에 따라 가장 최근의 복사본을 판단하도록 데이터베이스 충돌 도출 규약(Database Conflict Resolution Protocol)을 실행한다. 노드가 클러스터를 결합하면 상기 노드는 각 대체 데이터베이스의 기존 버전을 백업한 후에 클러스터 버전으로 가장 최근의 복사본을 대체한다. 클러스터 구성 데이터베이스에 대한 수정은 단지 CSQL이 독립 모드에서 클러스터 모드로 전환된 후에만 허락된다. 클러스터 모드로 되기 위한(entering) 조건은 아래에 상세하게 기술된다. CSQL 서비스는 로컬 및 리모트(remote) 클라이언트 접속 모두를 지원한다.

사건 어댑터(312)는 서브 시스템의 조건(condition)을 모니터하고 실패 상황이 발생할 때 사건을 발생한다. 사건은 클러스터-스코프(scope) CSQL 구성 데이터베이스내의 사건 테이블로서 실시되는 분산된 사건 큐내로 삽입된다. 하나의 클러스터에는 네 개의 사건 어댑터가 존재한다. 즉, MSCS 서브 시스템을 모니터하는 MSCS 사건 어댑터, 노드와 네트워크 인터페이스 실패를 모니터하는 그룹 서비스 사건 어댑터, 사용자 요구를 IBMCS 사건으로 변환하는 IBMCS 클러스터 API 사건 어댑터, 및 네트워크 분할을 모니터하는 분할 예방 사건 어댑터(Partition Prevention Event Adapter)가 그것이다.

그룹 서비스 사건 어댑터(GSEA)(310)는 분산된 서브 시스템이다. 각각의 GSEA는 제공자로서 GSEA 그룹 서비스의 그룹(311)을 결합한다. GSEA는 그룹 서비스로부터 떠남(LEAVE), 떠남 실패(FAILURE LEAVE) 통지를 수신하고 상기 통지를 IBMCS 사건으로 변환한다. GSEA가 자발적으로 또는 실패로 인해 그룹를 떠나면 소정 그룹으로서 GSEA는 사건 큐로 하나의 사건을 정확하게 삽입한다.

마이크로소프트 클러스터 서비스 사건 어댑터(Microsoft Cluster Services Event Adapter; MSCSEA)(312)는 현재의 클러스터 매니저에 의해 MSCS 통지를 인식 가능한 사건으로 변환한다. 각 노드 상에서 실행중인 MSCSEA에 대한 하나의 인스턴스가 존재한다. 각 MSCSEA는 단지 로컬 노드 상에서만 실행중인 MSCS 자원 그룹과 MSCS 자원을 모니터하도록 사용된다. 다중 클러스터내의 MSCS 서브 클러스터가 단일-노드 클러스터로 구성되면 MSCS 하트비트 메카니즘은 효과적으로 사용 금지된다. 네트워크 인터페이스 실패와 노드 실패는 토폴로지 및 그룹 서비스 서브 시스템(308)에 의해 검출된다.

회복 서비스(316)는 규칙에 기초하고(rule-based) 객체지향적인(object-oriented) 트랜잭션의(transactional)의 사건 처리 서브시스템이다. 사건 프로세싱은 새로운 사건이 클러스터-스코프 CSQL 데이터베이스의 클러스터-와이드 사건 테이블내로 삽입되면 트리거된다. 회복 서비스는 CSQL 기능과 CSQL 서브 시스템 내로 부가된 활성적이고 객체 지향적인 SQL문(statement)의 처리 능력을 확장한다. 방법은 활성 SQL 언어로 표현된다. 특별히, 다음에 SQL형 활성 SQL문이 소개된다. 트리거 생성(CREATE TRIGGER), 평가(EVALUATE), 실행(EXECUTE), 계속(CONTINUE), 매크로 생성(CREATE MACRO), 및 DLL 로드(LOAD DLL). 트리거 생성(CREATE TRIGGER)문은 CSQL를 구비한 특정 테이블(specified table) 상에 트리거를 등록한다(register). 새로운 행(row)(사건)이 상기 특정 테이블 내로 삽입되면, CSQL은 대응하는 사건 프로세싱 규칙을 실시한다. 규칙은 SQL 및 상술된 활성 SQL문으로 표현된다. 평가(EVALUATE)문은 선택(SELECT)과 매우 유사하다. 한 셋트의 데이터를 선택하는 대신에, 평가(EVALUATE)문은 한 셋트의 규칙을 선택하고 그런 다음 선택된 규칙을 평가한다. 동일한 평가(EVALUATE)문에 의해 선택되고 처리되는 SQL 및 활성 SQL문은 동일한 트랜잭션의 일부분이다. 실행(EXECUTE)문은 사용자 정의 함수(user defined function), 외부 프로그램(external program), 커맨드 파일, 또는 셀 스크립트(shell script) 파일 중 어느 하나를 실행하여 물리적인 시스템의 상태를 변경한다. 계속(CONTINUE)문은 분산된 CSQL 서버 중 사건 프로세싱을 동기시킨다. 특히, 계속(CONTINUE)문은 계속(CONTINUE)문 지점까지 CSQL 데이터베이스를 동기시킨다. 사건 프로세싱이 트리거되는 매 시점마다 다수의 계속CONTINUE)문이 존재할 수 있다. 매크로 생성(CREATE MACRO)문은 임의의 SQL문에서 실시될 수 있는 특정 매크로를 정의한다. 매크로는 SQL문에서 사용될 수 있는 데이터 값을 돌려준다(return). DLL 로드(LOAD DLL)는 SCQL 내로 특정 동적 링크 라이브러리(Dynamically Linked Library; DLL)를 동적으로 로드한다. DLL 초기화 코드 중, DLL 로드(LOAD DLL)는 DLL의 사용자 정의 함수를 CSQL 내로 등록한다. 사용자 정의 함수는 실행(EXECUTE)문이나 다른 임의의 SQL문 중 어느 하나에서 실시될 수 있다. 사용자 정의 함수는 일반적으로 사용된 함수를 제공하여 SQL 언어를 확장하거나 또는 CSQL 서버에 대한 외부의 물리적 엔티티 상에서 동작을 초기화하는 것 중의 하나이다. 한 예로서, 사용자 정의 함수는 MSCS 자원 관리 설비를 제어하도록 사용된다.

IBMCS 클러스터 API(318)은 특정 MSCS 클러스터로 액세스 하는 것이 아니라 다중 클러스터로 액세스를 총괄적으로(as a whole) 제공한다. 상기 IBMCS 클러스터 API(318)는 커다란 클러스터를 취급할 수 있지만 기능적으로 마이크로소프트 클러스터 API의 기능과 동일하다. 이것은 다른 클러스터 인식 애플리케이션뿐만 아니라 IBM 클러스터 매니저(302)에 의해서도 사용될 수 있도록 하기 위한 것이다. IBMCS 클러스터 API에서의 기능과 마이크로소프트 클러스터 API의 기능간에는 일 대 일 대응이다. 두 개의 클러스터 API 간의 유사성은 현재는 애플리케이션 공급자가 IBMCS 클러스터링 특징을 이용하도록 하고 앞으로는 두 노드를 갖는 마이크로소프트 클러스터보다도 보다 큰 클러스터로 이동할 수 있도록 한다. IBMCS 클러스터 API DLL은 MSCS 클러스터 API DLL(clusapi.dll)과 호환 가능한 이진수이다. 질의(query) 형태의 클러스터 API 기능은 IBMCS 클러스터 API DLL에 의해 직접 처리된다. 상태 변경을 초래하는 이러한 클러스터 API 기능은 IBMCS 회복 서비스에 의해 취급되는 사건으로 변환된다. IBMCS 클러스터 API DLL은 사건 프로세싱의 결과를 대기하기 위해 CSQL 통지를 사용했다. IBMCS 클러스터 API DLL은 잘 알려진 가상 IP 어드레스를 경유하여 CSQL 서비스와 통신한다. 요약하면, 클러스터 서비스(304)는 애플리케이션이 클러스터내의 다른 노드에서 페일오버하면(fall over) 애플리케이션 프로그램에 의해 NT 클러스터 레지스트리 내로 기입된(put) 상태 정보가 이용 가능하게 될 수 있도록 한다. 클러스터 서비스(304)는 시스템 구성을 진단하고(examine) 시스템이 설치될 수 있도록 정확히 구성되며 시스템 클러스터링 특징을 정확히 실행할 수 있도록 하는 유틸리티를 제공한다. 상기 유틸리티가 처음 시작됨에 따라 클러스터가 구성된다. 클러스터 서비스(302)를 구비하는 IBM 클러스터 매니저는 클러스터와 상기 IBM 클러스터 매니저가 포함된 MSCS 클러스터를 구성하고, 관리하고, 모니터할 것이다.

다른 유틸리티는 다수의 MSCS 서브 클러스터와 IBMCS 클러스터 서비스의 설치 과정을 단순화할 수 있도록 개발될 수 있다.

클러스터 서비스 서브 시스템은 클러스터 조정자 서브 시스템(cluster coordinator subsystem)에 의해 시작된다. 클러스터 조정자는 NT 서비스로서 실시되고 시동 중에 자동으로 시작된다. 그런 다음 클러스터 조정자는 독립 모드에서의 CSQL 서비스, 토폴로지 서비스, 그룹 서비스, 클러스터 모드에서의 CSQL 서비스, 회복 서비스, MSCS 사건 어댑터, MSCS, 및 그룹 서비스 사건 어댑터 순으로 모든 다른 클러스터 서비스 서브 시스템을 시작한다.

CSQL 서비스는 독립 모드에서 초기에 시작된다. 토폴로지 서비스 및 그룹 서비스는 CSQL 데이터베이스로부터 자신의 구성 정보를 검색한다. 그룹 서비스가 검색을 시작하면, CSQL 서비스는 CSQL_서비스 그룹(315)을 형성하고 클러스터 구성 데이터베이스의 내용을 동기하도록 데이터베이스 충돌 해제 규약(DCRP)을 실행한다. 첫 번째 CSQL_서버는 그룹을 형성하고, 명령(BIDDING) 상태로 CSQL_서비스 그룹을 설정하고, 그룹을 결합하기 위해 다른 CSQL_서버를 대기하도록 타이머를 시동시킨다. 명령(BIDDING) 상태인 그룹을 결합하는 CSQL 서버는 또한 결합하기 위해 다른 CSQL_서버를 기다리도록 타이머를 시동시킨다. 타이머값은 클러스터 구성 데이터베이스 내에 정의되고 노드마다 상이할 수 있다. 상이한 타이머값은 초기에 다른 노드에 의해 사용되는 상이한 버전을 갖는 클러스터 구성 데이터베이스에 의해 발생될 수 있다. 첫 번째 타이머의 시간이 만료하면, CSQL 서버는 그룹 서비스 n-위상 규약을 사용하는 그룹으로 자신의 클러스터 구성 데이터베이스의 타임스탬프를 동보한다. 다른 CSQL 서버의 타임스탬프가 상기 수신된 CSQL 서버의 타임스탬프보다 최신의 것이면 상기 다른 CSQL 서버는 자신의 타임스탬프를 동보한다. 다수의 CSQL 서버가 자신의 타임스템프를 전송하면, 타임스탬프는 그룹 서비스에 의해 임의로 선택되고 다음 단계에서 그룹으로 동보한다. CSQL 서버는 자신의 타임스템프가 수신된 타임스탬프보다 좋을 경우에만 자신의 타임스탬프를 전송한다. CSQL 서버는 자신의 타임스탬프가 다른 버전을 갖는다는 것을 다른 CSQL 서버로 신호하기 위해 첫 번째 단계에서 자신의 타임스탬프가 수신된 타임스탬프보다 오래된 것일지라도 자신의 타임스탬프를 전송해야 한다. 결국, 규약은 종결된다. 모든 CSQL 서버가 동일한 타임스탬프를 갖거나 또는 상기 모든 CSQL 서버는 모두 가장 최근의 버전과 일치한다. 모든 타임스탬프가 동일하지 않을 경우, 자신의 최신(the last) 타임스탬프를 전송하는 CSQL 서버는 다른 모든 CSQL 서버로 자신의 데이터베이스를 동보한다. CSQL 서버는 최신 버전으로 대체되는 데이터베이스에 대한 백업 복사본을 만든다. CSQL 서버가 클러스터 구성 데이터베이스를 동기한 후, 상기 CSQL 서버는 CSQL_서비스 그룹의 상태를 실행 상태로 설정한다. 새로운 버전으로 대체된 복사본을 갖는 CSQL 서버는 클러스터 서비스를 재시작하게 한다. 실행중인(RUNNING) CSQL_서비스 그룹을 결합하는 CSQL 서버는 자신의 복사본을 반드시 저장하고 자신의 타임스탬프 값과 무관하게 클러스터 버전으로 복사본을 대체해야 한다. 새로운 버전이 현재 다른 서브 시스템에 의해 사용되고 있는 기존의 타임스탬프와 상이한 타임스탬프를 가지는 경우, CSQL 서버는 클러스터 서비스를 재시작하게 한다.

CSQL 타임스탬프는 세 개의 투플, 즉 전체 클러스터에 대해(across) 단조 증가하는(monotonically increasing) 번호, 마지막에(the last time) 데이터베이스를 수정한 노드의 노드 ID, CRC 체크섬으로 이루어진 집합으로 구분된다.

일단 CSQL 서비스가 실행(RUNNING) 상태이면, 사건 큐를 포함하는 클러스터 구성 데이터베이스는 모든 노드 상에서 동일하다(consistent). CSQL 서버는 실행중인(RUNNING) CSQL_서비스 그룹을 성공적으로 결합한 후에 클러스터 모드 내에 존재한다 말해진다. 그런 다음 회복 서비스, MSCS, MSCS 사건 어댑터(MSCSEA), 및 그룹 서비스 사건 어댑터(GSEA)가 시작된다. GSEA는 GSEA 그룹 서비스의 그룹을 결합하고 그룹 서비스 결합(JOIN) 규약을 처리하는 중에 클러스터-와이드 사건 큐내로 해당 노드(this node)에 대한 BRING_COMPUTER_UP 사건을 부가한다. IBMCS 자원 그룹은 초기에 오프라인 상태이다. BRING_COMPUTER_UP 사건을 처리하는 동안, 회복 서비스는 임의의 자원 그룹이 온라인 상태로 변환하여야 하는지를 판단한다.

DCRP 알고리즘은 다음과 같이 요약된다. (1) CSQL 서버는 CSQL_서비스 그룹으로 데이터베이스의 이름을 포함하는 개방 데이터베이스(open database) 요구와 타임스탬프를 동보한다. (2) 상이한 타임스탬프를 갖는 CSQL서버 각각은 반드시 계속(CONTINUE)을 제안해야 하고(vote) 데이터베이스 복사를 반드시 실행하도록(force) 첫 번째 단계(phase)에서 각 CSQL 서버의 타임 스탬프를 동보해야 한다. (3) 자신의 동보를 수신하는 CSQL 서버는 첫 번째 단계에서 승인(APPROVE)을 반드시 제안해야한다(vote). (4) 수신한 것과 동일한 타임스탬프를 갖는 CSQL_서버는 승인(APPROVE)을 반드시 제안해야한다. (5) 각 후속 단계 중에, 수신된 타임스탬프보다 좀더 최근의 타임 스탬프를 갖는 CSQL 서버는 자신의 타임스탬프를 동보해야 하고 계속(CONTINUE)을 반드시 제안해야 한다. (6) 자신의 타임스탬프를 수신하는 CSQL 서버는 계속(CONTINUE)을 반드시 제안해야 한다. (7) 동일하거나 좀더 빠른 임의의 타임스탬프를 갖는 CSQL 서버는 APPROVE를 반드시 제안해야 한다. (8) 단계 중에 전송된 메시지가 존재하지 않는 경우, 자신의 타임스탬프를 마지막에 동보한 서버는 다른 서버로 최근 버전의 데이터베이스를 반드시 복사한다. 서버는 자신이 대체되기 전에 항상 자신의 복사본을 백업하도록 한다.

도 3b 및 도 3c를 참조하여, IBMCS 시스템에 대한 시동(startup) 시퀀스가 예시된다. 첫 번째로, 클러스터 조정자는 NT가 시동하는 중에 NT 서비스로서 시작된다. 클러스터 조정자는 다른 IBMCS 서브 시스템을 시작하고 모니터한다. 다음에, CSQL 서비스(314)는 독립 모드에서 시작된다. 그런 다음, 토폴로지 서비스(308)가 시작되고, 그룹 서비스(300)가 시작된다. 다음에, CSQL 서비스가 CSQL_서비스 그룹(315)을 형성하거나 결합한다. CSQL 서비스는 데이터베이스 충돌 도출 규약을 실행하고 클러스터 모드로 들어간다. 그런 다음 모든 클러스터 스코프(scope) 데이터베이스는 갱신된다. 특히, 사건 큐는 갱신된다. 회복 서비스(316)가 시작되고 회복 서비스 데몬(daemon)은 MSCS 사건 어댑터(312) 및 그룹 서비스 사건 어댑터(310) 모두를 순차적으로 시작하게 한다. 그룹 서비스 사건 어댑터(GSEA)(310)가 시작된다. GSEA는 GSEA 그룹을 형성하거나 결합하고 노드 실패 사건을 모니터한다. 그런 다음 회복 서비스 데몬은 로컬 노드를 위해 A BRING-COMPUTER_UP 사건을 삽입한다. 회복 서비스는 상기 노드를 위해 BRING_COMPUTER_UP 사건을 처리한다. MSCS 서브 시스템(306)이 시작되고 그런 다음 MSCS 사건 어댑터(312)에 의해 모니터된다. 자원 그룹은 시작되거나 자원 할당 정책과 시스템 상태에 따라 새로운 노드로 이동된다.

본 발명의 다른 중요한 특징은 클러스터 큐럼 조건을 포함한다는 것이다. 자원 그룹은 다음의 큐럼 조건중 하나라도 만족시키지 않으면 온라인 상태로 변환될 수 없다. 클러스터 서비스는 HACMP에서 사용되는 동일한 대부분의 큐럼 스킴(scheme)을 채택한다. 클러스터 서비스는 대부분의 큐럼 조건을 판단하도록 그룹 서비스에 의해 제공된 연결 정보(connectivity information)를 사용한다. 부가적으로 스프릿 브레인 문제(split brain problem)를 피하도록 공유 디스크 경로나 다른 방법을 통해 관련 정보를 또한 전달한다. 네트워크가 갈라지고(severed) 클러스터가 여러 분할(partition)로 분할되면, 클러스터 서비스는 공유 디스크 상의 애플리케이션 데이터에 대한 파손(corruption)을 유발할 수 있는 시간에(the same time) 다중 분할 내에서 단일 자원 그룹이 시작되지 않도록 보장해야 한다. 디스크 경로 상으로 전달된 연결 정보는 각 분할이 다른 분할 크기에 대하여 알 수 있도록(learn)하여 데이터 파손을 방지하도록 한다. 자원 그룹은 다음의 조건이 참인 경우, 상기 자원 그룹 상에서 온라인 상태로 변환하도록 한다. (1) 분할은 대부분의 큐럼을 구비한다. 즉, 클러스터 구성 데이터베이스 내에 정의된 모든 노드중 절반 이상이 클러스터를 결합하고 상기 그 분할 내에 존재하거나, (2) 상기 분할은 클러스터 구성 데이터베이스 내에 정의된 것처럼 노드 중 정확히 반에 해당하는 노드를 갖고 동일한 크기를 갖는 다른 분할은 존재하지 않거나, 또는 (3) 상기 분할은 클러스터 구성 데이터베이스 내에 정의된 것처럼 노드 중 정확히 반에 해당하는 노드를 갖는 한편, 다른 분할은 노드의 다른 나머지 반을 포함하고 가장 작은 노드 ID는 이전 분할 내에 존재한다.

모든 클러스터 서비스 서브 시스템을 시작하게 한 후에, 클러스터 조정자는 서브 시스템 각각의 상태를 모니터한다. 임의의 서브 시스템이 비정상으로 종료하면, 클러스터 조정자는 노드를 셧다운하고 다른 서브 시스템뿐만 아니라 상기 서브 시스템 자체도 재시작한다. 임의의 서브 시스템이 실패할 때 노드를 셧다운하는 것은 IBMCS 클러스터 서비스가 실패일 때 사용자 애플리케이션이 계속 실행하는 것을 방지할 수 있도록 한다.

분할이 치료되면(heal), 그룹 서비스는 한 분할 내에서가 아니라 모든 분할 내에서 그룹을 해체한다(resolve). 이러한 분할 내에서의 그룹 서비스 데몬은 종료된다. 결과적으로 이러한 노드는 클러스터 조정자에 의해 셧다운되고 재시작된다. 회복 서비스를 위한 셧다운 절차(shutdown procedure)는 모든 자원 그룹이 반드시 오프라인 상태로 되도록 한다.

도 3c를 참조하면, 본 발명에 대한 구성요소 지원(COMPONENT SUPPORT)이 예시되어 있다. IBMCS(304)는 클러스터 자원을 관리하도록 MSCS(306)를 사용한다. 자원 그룹은 초기에 클러스터 구성 데이터베이스 내에서 정의되고 필요한 경우에만 MSCS 서브 클러스터 내에서 정의된다. 자원 관리 정책은 MSCS 자원 관리 동작(MSCS resource management behavior)을 모방하도록(mimic) 설계된다. 자원 그룹이 MSCS 서브 클러스터 내에서 정의되면, 재시작 플래그는 항상 사용 금지되어 재시작 결정은 MSCS가 아니라 사건 프로세싱 서브 시스템에 의해 이루어진다. 단일 노드 클러스터이든지 아니든지 간에, MSCS 서브 클러스터 내에 정의된 자원 그룹은 바람직한 노드 목록 내에 많아야(at most) 하나의 노드를 구비하여 MSCS 자동 페일오버 메카니즘은 사용 금지된다. 클러스터 서비스는 온라인인 모든 자원 그룹의 상태를 모니터한다. 자원 또는 자원 그룹이 실패하면, MSCS 사건 어댑터(312)는 사건 큐 내로 대응하는 사건을 삽입한다. CSQL 서비스(314)는 사건에 대한 사건 프로세싱을 트리거한다. 단 하나밖에 없는 CSQL 인스턴스만이 사건 프로세싱은 초기화한다. CSQL 인스턴스 각각은 단지 로컬 노드 상에서 단일-노드 MSCS 서브 클러스터를 포함하는 자원을 관리한다. 사건 프로세싱은 다수의 실패를 처리할 수 있도록 설계된다.

도 4 내지 도 6을 참조하면, 본 발명의 다른 특징이 사건 프로세싱과 연관을 갖는다(involve). 클러스터 서비스 내에서 정의된 사건은 다음의 것, 즉

BRING_COMPUTER_UP, BRING_COMPUTER_DOWN, BRING_RESOURCE_GROUP_ONLINE,

BRING_RESOURCE_GROUP_OFFLINE, 및 MOVE_RESOURCE_GROUP을 포함하지만 이에 제한되지 않는다. 컴퓨터가 클러스터를 결합하면, "BRING_COMPUTER_UP" 사건은 사건 큐내로 삽입된다. BRING_COMPUTER_UP 사건을 처리하기 위해, IBMCS는 다음의 것을 실행할 필요가 있다. (1) 큐럼이 존재하는지의 여부 체크, (2) 큐럼이 존재하는 경우, 임의의 자원 그룹이 새로운 컴퓨터 상에서 발생해야 하는지를 체크. 소정 자원 그룹은 다른 소정의 컴퓨터 상에서 온라인으로 될 수 있다. 이러한 자원 그룹은 우선 오프라인 상태이어야 한다. 다음에, IBMCS는 오프라인 상태로 존재하는 이러한 자원 그룹이 새로운 컴퓨터 상에서 온라인으로 되도록 한다.

모든 구성 정보, 상태 정보, 자원 관리 정책, 및 규칙은 클러스터 스코프 데이터베이스 내의 escluster.cfg에 저장된다. 컴퓨터 "힐탑(hilltop)"이 클러스터를 결합하는 것을 지원한다(support that computer "hilltop" joins a cluster). 힐탑에 대한 BRING_COMPUTER_DOWN 사건은 사건 큐내로 삽입된다. 사건과 CSQL에 관련하는 정보를 요약하는(encapsulate) 실행시간 환경(runtime environment)이 생성되는 사건 프로세싱을 수행하도록 CSQL을 트리거하는 것은 다음의 문을 처리한다.

EVALUATE action from ch_routiones where ch_routine=

"BRING_COMPUTER_UP"

상기 문은 escluster.cfg 데이터베이스 내의 ch_routines 테이블의 BRING_COMPUTER_UP 행 속의 문이 처리되어야 한다는 것을 명기한다.

ca_resource_group 테이블이 도 6에 정의된다. 상기 테이블은 테이블 중 한 행을 도시한다. 엔트리(entry) 각각은 하나의 열(column)이다. $_failback_node()이 매크로(macro)이며, 상기 매크로는 새로운 노드가 소정 클러스터를 결합하는 경우 특정 자원 그룹이 특정 페일백(failback) 정책에 기초하여 실행될 수 있는 노드를 반환한다(return). $_resource_group_online() 및 $_resource_group_offline()은 특정 컴퓨터 노드 상에 특정 자원 그룹이 오프라인 및 온라인이 되도록 호출하는 MSCS 클러스터 API 기능을 사용하는 사용자 정의 함수이다. "EVALUTE action from ch_routines where ch_routine = "BRING_COMPUTER_UP"의 처리 결과에 따라, 다음 문이 선택된 후 처리된다.

"evalute markup_action from computers where computer + $_get_event_node();

evalute action from ch_routines where $_has_quorum90 and ch_routine = NODE_UP;"

두 번째 평가(EVALUTION)문의 처리 결과로서, 다음의 세 문이 검색된 후 처리된다.

evaluate failback_action from ch_resource_groups where current_node＜＞next_node;

evaluate release_action from ch_resource_groups where current_node＜＞next_node;

evaluate acquire_action from ch_resource_groups where current_node = "" and next_node = $_get_event_node();

이러한 세 개의 평가(EVALUATE)문은 탐색 조건이 되면 ch-resource_groups 테이블내의 모든 ch-resource_group의 행(객체(object))에 대해 각각 탐색될 것이다. 소정 ch-resource_group 행(객체)이 발견되면, 특정 동작(specified action)이 그 객체에 대해 실행된다.

failback_action은 단일 문을 포함한다. 즉:

"update ch_resource_groups set next_node = $_failback_node() where ch_resource_group = this ch_resource_group;"

상기 업데이트문에서, 새로운 노드가 클러스터를 바로 결합되게 부여되는 특정 자원 그룹을 실행하기에 가장 바람직한 노드인 소정 노드를 반환해주는(return) 매크로 failback_node()가 처리된다. 상기 업데이트문은 반환된 노드 이름을 next_node 열(column)내로 저장한다. 매크로 이름은 파싱(parsing)을 단순화하도록 $_가 접두어로 붙는다.

ch_resource_group 객체의 current_node 열(colunm)은 ch_resource_group가 실행중인 현재 노드(current node)를 표시한다. release_action은 current_node가 다음 노드와 상이하면 상기 ch-resource_group에 관하여 처리된다. 이러한 경우에, 다음 문이 처리된다.

execute $_resource_group_offline();

resource_group_offline()은 포함된 자원 그룹을 오프라인 상태로 실행하도록 하는 MSCS OfflineResourceGroup() 함수를 호출하는 사용자 정의 함수이다. 사용자 정의 함수는 파싱을 단순화하도록 $_가 접두어로 붙는다.

마지막으로, acquire_action은 어디에서도 실행되고 있지 않고 새로운 노드 상에서만 실행되어야 하는 모든 ch_resource_group 객체에 대해 새로운 노드 상에서 검색되고 처리된다. acquire_action은 하나의 문을 포함한다.

execute $_resource_group_online()

resource_group_online()은 또한 포함된 자원 그룹을 온라인 상태로 실행하도록 하는 MSCS OnlineResourceGroup() 함수라고 불리우는 사용자 정의 함수이다.

클러스터 서비스는 또한 사건 시뮬레이션을 지원한다. 회복 서비스가 사건을 시뮬레이트하도록 실시(invoke)되면, 상기 회복 서비스는 먼저 클러스터 구성 데이터베이스를 복제한다(clone). 사건 시뮬레이션은 구성 데이터베이스의 사설 복사본(private copy)상에서 수행되어 원래의 구성 데이터베이스는 영향을 받지 않는다. 시뮬레이션 도중에, 실행(EXECUTE)문은 물리적 자원의 상태를 실질적으로 변경한다.

도 4는 노드가 클러스터를 결합하고자 할 때 IBMCS에 의해 실행된 방법(400)을 예시한다. 첫 번째로, 노드는 클러스터를 결합한다(단계 402), 쿼롬이 존재하는지 여부를 판단한다(단계 404). 쿼롬이 존재하지 않으면, 상기 방법은 복귀한다(단계 406). 쿼롬이 존재하면, 매 자원 그룹에 대해, 다음의 루프가 시행된다(단계 405). 첫 번째로, 임의의 자원 그룹이 새로운 모드로 페일백(failback)될 수 있는지의 여부에 대한 질의가 이루어진다(단계 408). 될 수 있는 경우, 그러한 각 자원 그룹에 대해, 시스템은 특정 자원 그룹의 오프 라인을 실행하도록 대응하는 MSCS 서브-클러스터를 얻는다(단계 410). 계속단계(단계 418)는 모든 노드를 동기하도록 수행된다. 새로운 노드 상의 MSCS 서브-클러스터는 특정 자원 그룹이 온라인 상태로 되도록 한다(단계 414). 더 이상의 자원 그룹이 존재하는지 여부를 확인하기 위한 질의가 이루어진다(단계 412). 더 이상의 자원 그룹이 존재하지 않으면, 시스템은 동작을 종료한다(단계 416). 그렇지 않으면, 상기 방법은 단계 405로 복귀한다.

도 4a는 자원 그룹이 하나의 노드에서 다른 노드로 이동하도록 하는 방법(430)에 관한 순서도를 예시한다. 모든 노드는 노드 상태, 자원 그룹의 바람직한 노드 목록, 및 페일오버 정책에 따라 자원 그룹을 실행하도록 가장 바람직한 다음 노드를 계산한다(단계 434). 대안적으로, 사용자가 간단하게 다음 노드를 지정할 수 있다. 다음에, 시스템은 현재 노드가 다음 노드와 동일하지 않은지에 관하여 물어본다(단계 436). 현재 노드가 다음 노드와 동일하지 않다면, 시스템은 동작을 종료한다(단계 438). 현재 노드가 다음 노드와 동일하면, 시스템은 현재 노드 상의 MSCS 서브-클러스터가 특정 자원 그룹을 오프라인으로 되도록 한다(단계440). 그런 다음 처리는 계속된다(단계 442). 이러한 단계 도중에, 시스템은 자신의 사건 프로세싱을 동기화한다. 그 후에, 시스템은 다음 노드 상의 MSCS 클러스터가 특정 자원 그룹을 온라인 상태로 되도록 한다(단계 444). 마지막으로, 시스템은 종료된다(단계 446).

도 4b는 노드 실패가 발생할 때 IBMCS에 의해 실시된 일반적인 방법(450)을 예시한다. 이러한 방법은 또한 자원 실패나 자원 그룹 실패 사건에 대해서도 적용될 수 있다. 그룹 서비스 사건 어댑터는 정확히 하나의 노드 다운 사건을 사건 큐내로 집합적으로 삽입한다(단계 454). Node_Down 사건 프로세싱은 트리거된다(단계 456). 다음에, 실패된 노드 상에서 실행되고 있는 매 자원 그룹에 대해, 다음의 단계가 적용된다(단계 458). 첫째, 회복 서비스는 페일오버에 대한 Next_Node를 계산한다(단계 460). 그런 다음 My_Node == Next Node인지를 결정한다. 그렇지 않다면, 시스템은 자원 그룹이 더 이상 존재하는지 여부를 체크하고(단계 462), 그렇다면, 시스템은 MSCS 서브-클러스터가 특정 자원 그룹을 온라인이 되도록 한다(단계 464). 더 이상의 자원 그룹이 이용 가능하지 않다면, 시스템은 동작을 종료한다(단계 464). 더 이상의 자원 그룹이 이용 가능하다면, 시스템은 단계 458로 되돌아간다.

본 발명은 MSCS 서브 클러스터를 사용하는 것으로 기술되었지만, 이것은 단지 본 발명의 일 실시예에 불과하다는 것을 이해하는 것이 중요하다. 예를 들면, 이러한 시스템은 IBM의 HACMP나 선 마이크로시스템(Sun Microsystem)의 울트라 엔터프라이즈 클러스터 HA 서버(Ultra Enterprise Cluster HA Server) 상에 구성될 수 있다. 본 발명이 완벽한 기능의(functioning) 데이터 프로세싱 시스템의 맥락에서 기술되었지만, 당업자는 본 발명의 프로세스가 명령에 대해 컴퓨터 판독 가능한 매체 형태나 다양한 형태로 분산될 수 있고 본 발명이 분산을 실행하도록 실제 사용된 신호 포함 매체(signal bearing media)의 특정 형태에 무관하게 동일하게 적용한다는 것을 알 수 있을 것이다. 컴퓨터 판독 가능한 매체의 예는 플로피 디스크, 하드 디스크 드라이브, 램(RAM), 씨디-롬(CD-ROM) 및 디지털 및 아날로그 통신 링크와 같은 전송형 매체(transmission-type media)와 같은 기록 가능형 매체(recordable-type media)를 포함한다.

본 발명의 기술이 예시와 설명의 목적을 위해 개시되었지만, 본 발명은 개시된 형태에 대해 포함하거나(exhaustive) 한정된 것으로 제한되지 않는다. 많은 변경과 변형은 당업자에게 자명할 것이다. 상기 실시예는 본 발명의 원리를 가장 잘 설명하기 위하여 선택되고 기술된 것이다. 또한 고안된 특정한 사용에 적합하도록 다양한 변경을 갖는 다양한 실시예에 대해 당업자가 본 발명을 가장 잘 이해할 수 있도록 한 발명을 이해하도록 선택되고 기술된 것이다.

상기와 같이 동작하는 이 발명의 효과는 클러스터 컴퓨터 시스템의 방법 및 장치를 개선하여, 시스템의 속도를 향상시키고 신뢰성을 증가시킨다.

Claims

클러스터 컴퓨터 시스템―여기서 클러스터 컴퓨터 시스템은 복수의 클러스터 서비스 애플리케이션을 포함하고, 상기 클러스터 컴퓨터 시스템 내의 컴퓨터는 소정 클러스터 서비스 애플리케이션을 사용하여 관리됨―에서 자원을 관리하는 방법에 있어서,

상기 클러스터 컴퓨터 시스템 내의 자원에 관한 정보를 상기 클러스터 서비스 애플리케이션으로부터 수신하는 단계; 및

상기 클러스터 컴퓨터 시스템 내에서 사건을 검출하는 것에 응답하여, 상기 클러스터 컴퓨터 시스템 내의 자원을 제어하도록 클러스터 서비스 애플리케이션으로 호출을 전송하는 단계

를 포함하는 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제1항에 있어서, 상기 클러스터 컴퓨터 시스템 내의 컴퓨터 각각은 복수의 클러스터 서비스 애플리케이션 중의 소정 클러스터 서비스 애플리케이션에 의해 제어되고, 상기 호출은 자원이 온라인으로 되도록 소정 클러스터 서비스 애플리케이션을 명령하기 위해 사용되는 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제1항에 있어서, 상기 클러스터 컴퓨터 시스템 내의 컴퓨터 각각은 복수의 클러스터 서비스 애플리케이션 중 소정 클러스터 서비스 애플리케이션에 의해 제어되고, 상기 호출은 자원이 오프라인으로 되도록 소정 클러스터 서비스 애플리케이션을 명령하기 위해 사용되는 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제3항에 있어서, 상기 자원이 IP 어드레스인 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제3항에 있어서, 상기 자원이 애플리케이션인 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제3항에 있어서, 상기 자원이 공유 디스크 드라이브인 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제1항에 있어서,

제1 컴퓨터에서 실패를 검출하는 것에 응답하여, 컴퓨터 상에서 서비스를 정지(halt)하도록 상기 제1 컴퓨터를 제어하는 제1 클러스터 서비스 애플리케이션으로 호출을 전송하는 단계; 및

제2 컴퓨터 상에서 서비스를 재시작하도록 상기 제2 컴퓨터를 제어하는 제2 클러스터 서비스 애플리케이션으로 인스트럭션을 전송하는 단계

를 추가로 포함하는 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제7항에 있어서, 상기 제1 클러스터 서비스 애플리케이션이 상기 제2 클러스터 서비스 애플리케이션인 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제7항에 있어서, 상기 제1 클러스터 서비스 애플리케이션이 마이크로소프트 클러스터 서비스 프로그램인 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제7항에 있어서, 제1 및 제2 클러스터 서비스 유니트로 인스트럭션을 전송하는 단계가 제1 클러스터 서비스 유니트와 제2 클러스터 서비스 유니트로 애플리케이션 인터페이스 호출을 전송하는 단계를 포함하는 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.
제1항에 있어서, 상기 클러스터 서비스 애플리케이션이 클러스터 서비스 애플리케이션이 실행중인 컴퓨터에서 자원이 온라인과 오프라인으로 되도록 사용되는 클러스터 컴퓨터 시스템에서 자원을 관리하는 방법.