KR20130081552A

KR20130081552A - 장애 복구 장치 및 방법

Info

Publication number: KR20130081552A
Application number: KR1020120002591A
Authority: KR
Inventors: 정복득; 이성민
Original assignee: 삼성전자주식회사
Priority date: 2012-01-09
Filing date: 2012-01-09
Publication date: 2013-07-17
Also published as: US20130179730A1; US9417973B2

Abstract

일 양상에 따른 장치는, 스레드(thread)에 대한 시스템 리소스 할당 정보를 기록하는 로그 관리자, 장애(fault)와 관련된 목적 스레드(target thread)의 역할을 대신하기 위한 복구 스레드(recovery thread)를 생성하는 복구 관리자, 및 시스템 리소스 할당 정보를 이용하여 목적 스레드가 사용하던 시스템 리소스를 복구 스레드에 매핑하는 리소스 관리자를 포함할 수 있다.

Description

장애 복구 장치 및 방법{Apparatus and method for recovery of fault}

마이크로커널(microkernel)을 기반으로 내고장성(fault-tolerance)를 높이기 위한 기술과 관련된다.

내고장성(fault-tolerance) 기술이란 시스템의 일부에 장애가 발생하더라도 요구되는 기능의 전부 또는 일부를 유지하는 기술을 말하는 것이 일반적이다.

내고장성 기술은 주로 서버-클라이언트 환경에 적용된다. 내고장성 유지를 위하여 물리적으로 복수개의 컴퓨팅 머신에 복수개의 서버프로그램을 동작시킨다. 따라서 클라이언트로부터 요청 받은 서비스를 처리 중인 컴퓨팅 머신에서 장애가 발생하더라도 다른 컴퓨팅 머신이 기존 서비스를 받아 대신 처리하는 방식으로 내고장성이 유지될 수 있다.

한편 최근에는 스마트폰, 휴대폰, 개인용 헬스 케어 기기와 같은 모바일 기기에서의 내고장성 유지에 대한 관심이 급증하고 있다. 그러나 이러한 모바일 기기는 서버에 비해 컴퓨팅 파워가 낮고, 대부분의 연산이 로컬 머신에서 처리되는 특징이 있다.

따라서 서버프로그램의 복사 및 분배 기법과 같이 서버에 적용되는 내고장성 기술을 모바일 기기에 적용하기에는 한계가 있다.

모바일 기기와 같이 서버에 비해 컴퓨팅 파워가 낮은 기기에서 고신뢰성을 필요로 하는 프로그램 또는 사용자 레벨에서 동작하는 OS 서비스의 동작 중 발생하는 장애에 대해 서비스를 이용하는 클라이언트 프로그램에 영향을 미치지 않고 투명하고(Transparent) 빠르게(Fast) 장애를 복구하는 장치 및 방법이 제공된다.

다른 양상에 따른 장치는, 전술한 구성 외에 주소 공간 지정자(address space identifier, ASID)를 이용하여 복구 관리자를 보호하는 복구 스레드 보호부를 더 포함할 수 있다.

또 다른 양상에 따른 장치는, 전술한 구성 외에 목적 스레드와 관련된 IPC(inter-process communication) 메시지를 복구 스레드로 제공하는 IPC 관리자를 더 포함할 수 있다.

한편 일 양상에 따른 방법은, 스레드(thread)에 대한 시스템 리소스 할당 정보를 기록하는 단계, 장애(fault)와 관련된 목적 스레드(target thread)의 역할을 대신하기 위한 복구 스레드(recovery thread)를 생성하는 단계, 및 시스템 리소스 할당 정보를 이용하여 목적 스레드가 사용하던 시스템 리소스를 복구 스레드에 매핑하는 단계를 포함할 수 있다.

다른 양상에 따른 방법은, 전술한 단계 외에 목적 스레드와 관련된 IPC(inter-process communication) 메시지를 복구 스레드로 제공하는 단계를 더 포함할 수 있다.

개시된 내용은 마이크로커널 기반의 내고장성 유지를 제공하기 때문에 모바일 기기와 같이 컴퓨팅 파워가 낮은 시스템에도 적용될 수가 있다. 또한 장애와 관련된 태스크 또는 스레드가 사용하던 시스템 리소스를 재활용하면서 장애 복구가 이루어지기 때문에 빠른 복구가 가능하고, 또한 IPC 메시지가 복구 스레드로 적절하게 제공되기 때문에 투명한 장애 복구가 가능하다.

도 1은 일 실시예에 따른 장애 복구 장치가 동작하는 시스템 환경을 도시한다.
도 2는 일 실시예에 따른 장애 복구 장치의 구성을 도시한다.
도 3은 다른 실시예에 따른 장애 복구 장치의 구성을 도시한다.
도 4는 또 다른 실시예에 따른 장애 복구 장치의 구성을 도시한다.
도 5는 일 실시예에 따른 복구 관리자의 보호 방법을 도시한다.
도 6은 일 실시예에 따른 장애 복구 방법을 도시한다.

이하, 첨부된 도면을 참조하여 본 발명의 실시를 위한 구체적인 예를 상세히 설명한다.

도 1은 일 실시예에 따른 장애 복구 장치가 동작하는 시스템 환경을 도시한다.

도 1을 참조하면, 본 실시예에 따른 장애 복구(fault recovery) 장치는 마이크로커널(microkernel) 기반의 운영체제(operation system, OS) 환경에 적용될 수 있다. 마이크로커널 기반의 운영체제 환경은 커널 계층(120)과 사용자 계층(140)을 포함할 수 있다.

마이크로커널 기반의 운영체제 환경에 있어서, 기본적인 OS기능은 커널 계층(120)에서 제공되고, 나머지 OS기능은 사용자 계층(140)에서 태스크(task) 형태로 제공될 수 있다. 다시 말해, 마이크로커널(101)은 스케줄링(scheduling), 페이지 테이블(page table) 관리와 같은 기본적인 OS기능을 수행하고, 그 밖의 나머지 OS기능은 사용자 계층(140)에서 각각의 태스크(102a, 102b, 102c, 102d)를 통해 수행되는 것이 가능하다. 예컨대, 특정한 태스크(예컨대, 102b)는 시스템 리소스를 관리하고 다른 태스크(예컨대, 102a)에게 OS 서비스를 제공할 수 있다.

마이크로커널(101)은 IPC(inter-process communication), 태스크 정보, 스레드 정보 등을 관리하는 커널 오브젝트(kernel object)(103)를 포함할 수 있다. 사용자 계층(140)에 있는 태스크(102a, 102b, 102c, 102d)는 마이크로커널(101)이 제공하는 커널 오브젝트(103) 형태의 시스템 리소스를 사용할 수 있다. 또한 사용자 계층(140)에 있는 태스크(102a, 102b, 102c, 102d)는 마이크로커널(101)이 제공하는 IPC 오브젝트(104)를 통해 다른 태스크가 제공하는 시스템 리소스를 사용할 수도 있다.

특정한 태스크(예컨대, 102d)는 다른 태스크(예컨대, 102c)를 생성하고, 생성된 태스크(102c)에 기초 리소스를 할당해주며, 태스크(102c)에서 처음에 실행될 스레드를 생성해서 그 태스크(102c)에 바인드(bind)하고 그 스레드를 시작시키는 역할을 수행할 수 있다. 본 실시예에 따라, 이러한 태스크(102d)는 로더(loader)라고 지칭될 수 있다. 또한 이러한 로더(102d)는 생성한 태스크(102c)의 부모 태스크로서 태스크 종료 상황에 태스크(102c) 및 그 태스크(102c)에 속한 스레드들로부터 종료 신호를 받아 처리하는 것이 가능하다.

도 2는 일 실시예에 따른 장애 복구 장치의 구성을 도시한다.

도 2를 참조하면, 장애 복구 장치는 로그 관리자(201), 복구 관리자(202), 리소스 관리자(203)를 포함할 수 있다.

로그 관리자(201)는 스레드(thread)에 대한 시스템 리소스 할당 정보를 기록한다. 로그 관리자(201)는 임의의 태스크(예컨대, 211)가 정상적으로 동작하는 동안에 그 태스크(211) 또는 그 태스크(211)가 속한 스레드(402)가 다른 태스크(예컨대, 213) 또는 마이크로커널(101)에 요청하여 할당받은 시스템 리소스 정보를 소정의 로그 테이블(log table)에 기록할 수 있다. 또한 선택적으로, 로그 관리자(201)는 그 태스크(211) 또는 그 태스크(211)가 속한 스레드(402)가 클라이언트(client)인 다른 태스크(예컨대, 213)에게 제공한 서비스 정보를 로그 테이블(log table)에 기록할 수도 있다. 로그 테이블의 각 엔트리는 "스레드의 식별자, 시스템 콜 요청 정보, 시스템 콜 요청에 대한 결과 정보"를 포함하는 튜플(tuple)로 구성될 수 있다. 만약, 스레드 별로 로그 테이블이 생성되는 경우, 각 엔트리에서 '스레드의 식별자'는 생략될 수도 있다. 시스템 콜 요청 정보 및 시스템 콜 요청에 대한 결과 정보는 시스템 콜의 처리를 위한 레지스터 값과 사용자 스레드 제어 블록(user thread control block, UTCB) 정보가 될 수 있다.

로그 관리자(201)에 의해 기록된 시스템 리소스 할당 정보는 태스크 또는 스레드에 대한 장애를 복구하기 위한 동작에서 참조될 수 있다. 다시 말해, 장애를 일으킨 태스크(이하, '목적 태스크(target task)'라 함)(예컨대, 211) 또는 스레드(이하, '목적 스레드(target thread)'라 함)(예컨대, 402)를 대신하는 복구 스레드(recovery thread)(401)가 목적 스레드(402)의 리플레이(replay)를 수행할 때, 로그 관리자(201)에 의해 기록된 시스템 리소스 할당 정보를 참조하여 목적 태스크(211) 또는 목적 스레드(402)가 사용하던 시스템 리소스를 재활용함으로써 빠르게 복구가 이루어지도록 할 수 있다.

로그 관리자(201)는 생성된 로그 테이블에서 불필요한 정보를 삭제할 수 있다. 일 양상에 따라, 스테이트리스 서버 태스크(stateless server task)의 경우, 클라이언트 태스크(client task)와 주고 받은 트랜잭션(transaction) 정보는 로그 테이블에서 삭제되는 것이 가능하다. 다른 양상에 따라, 서버 태스크가 클라이언트 태스크에 IPC(inter-process communication)를 할당했는데 클라이언트에 대한 서비스 종료로 IPC가 삭제된 경우, 클라이언트 태스크의 신규 IPC 할당 요청과 이에 대한 서버 태스크의 응답, 신규 IPC를 통한 메시지 트랜잭션 정보는 로그 테이블에서 삭제되는 것이 가능하다. 전술하였듯이, 복구 스레드(401)는 로그 테이블을 참조하여 리플레이를 수행하는데, 이러한 정보는 리플레이될 필요가 없는 부분므로 로그 테이블에서 삭제되면 더 빠른 복구가 이루어질 수 있다.

로그 관리자(201)는 커널 계층, 즉 마이크로커널(101)에 존재할 수 있으나 그 형성 위치가 반드시 여기에 한정되는 것은 아니다.

복구 관리자(202)는 태스크의 장애 상황에 대하여 그 태스크가 사용하던 시스템 리소스를 해제하지 않고 장애를 일으킨 스레드를 종료시키며 그 스레드를 대신하는 복구 스레드(401)를 생성할 수 있다. 복구 스레드(401)는 장애(fault)와 관련된 태스크에 속한 스레드의 역할을 대신하여 장애 복구를 실행하는 스레드가 될 수 있다.

복구 관리자(202)는 소정의 리커버리 요청에 따라 복구 스레드(401)를 생성할 수 있다. 리커버리 요청은 로더(loader)(212), 페이지 폴트 핸들러(page fault handler), 예외 핸들러(exception handler), 장애 감지 모듈, 장애 예측 모듈 등으로부터 수신될 수 있다. 로더(212)는 다른 태스크(예컨대, 211)의 부모 태스크이다. 따라서 자식 태스크(211)가 종료되면, 자식 태스크(211)로부터 소정의 종료 메시지를 받을 수가 있다. 로더(212)는 수신된 종료 메시지를 분석하여 자식 태스크(211) 또는 자식 태스크(211)에 속한 스레드(예컨대, 402)의 종료가 정상적인 종료인지 여부를 판단하고, 판단 결과에 따라 리커버리 요청을 복구 관리자(202)로 전송할 수 있다. 태스크의 페이지 폴트 핸들러 역시 태스크 또는 태스크에 속한 스레드가 비정상적인 메모리를 참조하여 페이지 폴트가 발생하면 리커버리 요청을 복구 관리자(202)로 전송할 수 있다. 그 밖에도, 별도의 장애 감지 모듈 또는 장애 예측 모듈로부터 리커버리 요청을 수신할 수도 있다.

복구 관리자(202)는 생성된 복구 스레드(401)의 실행 컨택스트(context)를 설정하여 복구 스레드(401)의 실행을 준비할 수 있다. 예컨대, 복구 관리자(202)는 복구 스레드(401)가 복구 모드(recovery mode)에서 동작하는 것임을 알려주는 플래그(flag), 로그 테이블에 대한 접근 정보 등을 복구 스레드(401)의 환경 변수 저장 공간인 스택(stack)에 기록하여 실행 컨택스트를 설정할 수 있다. 또한 선택적으로, 복구 스레드(401)가 맨처음 실행해야할 인스트럭션 실행 지점, 복구 필요 여부, 태스크 또는 스레드의 스테이트 속성(예컨대, stateless or stateful) 등이 복구에 필요한 설정 정보로서 설정될 수 있다. 인스트럭션 실행 지점은 목적 스레드(402)의 프로그램 코드 헤더에서 지정하는 엔트리 포인트가 될 수 있다.

복구 관리자(202)는 생성된 복구 스레드(401)를 목적 스레드(402)가 속한 태스크(이하, '목적 태스크'라 함)(211)에 매핑할 수 있다. 따라서 복구 스레드(401)가 목적 스레드(402)의 컨텍스트에 따라 실행되는 것이 가능하다.

복구 관리자(202)는 마이크로커널(101)에 IPC redirection을 요청할 수 있다. IPC redirection 요청을 수신한 마이크로커널(101)은 목적 태스크(211)에 할당된 커널 오브젝트들을 수집하고 목적 스레드(402)의 IPC 종단점(endpoint)을 복구 스레드(401)로 수정할 수 있다.

복구 관리자(202)는 로그 관리자(201)에 의해 기록되는 로그 테이블이 마이크로커널(101) 또는 태스크(예컨대, 211)와 공유되도록 로그 테이블용 메모리 영역을 할당할 수 있다. 예컨대, 복구 관리자(202)는 먼저 로그 테이블을 위한 메모리 영역을 할당한다. 선택적으로, 메모리 영역의 페이징(paging)으로 인한 오버헤드를 줄이기 위해 해당 메모리 영역을 'pinned property'로 설정할 수 있다. 그리고 복구 관리자(202)는 할당된 메모리 영역에 목적 태스크(211)가 접근할 수 있도록 접근 권한을 부여하고, 목적 태스크(211)의 주소 공간에 매핑한다. 또한 선택적으로, 복구 관리자(202)는 로그 테이블용 메모리 영역의 가상 주소와 실제 페이지의 물리 주소 간의 매핑이 페이지 테이블(page table)에 기록되지 않아서 런타임(runtime) 중 페이지 폴트(page fault)가 발생되는 것을 막기 위해 페이지 터치(page touch)를 미리 수행할 수도 있다.

복구 관리자(202)는 사용자 계층, 즉 로더(212)에 형성될 수 있으나 그 형성 위치가 반드시 여기에 한정되는 것은 아니다.

리소스 관리자(203)는 로그 관리자(201)에 의해 기록된 시스템 리소스 할당 정보를 이용하여 목적 스레드(402)가 사용하던 시스템 리소스를 복구 스레드(401)에 매핑한다. 다시 말해, 복구 모드에서 복구 스레드(401)가 목적 스레드(402)의 동작을 리플레이할 때, 목적 스레드(401)가 할당받았던 시스템 리소스를 복구 스레드(401)가 재사용하게 함으로써 시스템 리소스 할당에 대한 처리 시간을 단축시킬 수 있다. 예컨대, 리소스 관리자(203)는 복구 스레드(401)로부터 시스템 리소스 할당 요청을 수신하고, 로그 관리자(201)에 의해 기록된 시스템 리소스 할당 정보를 참조하여 목적 스레드(401)가 사용하던 시스템 리소스를 복구 스레드(401)로 반환할 수 있다.

리소스 관리자(203)는 목적 스레드(402)가 속한 태스크(211) 내의 시스템 콜 인터페이스(301)에 형성될 수 있다. 따라서 IPC 오버헤드나 컨텍스트 스위칭없이 빠르게 시스템 리소스가 재활용되도록 하는 것이 가능하다.

IPC 관리자(204)는 목적 스레드(402)와 관련된 IPC 메시지를 복구 스레드(401)로 제공한다. 예컨대, IPC 관리자(204)는 목적 스레드(402)가 사용하던 IPC 종단점(endpoint)을 복구 스레드(401)로 전환하거나, 또는 클라이언트 태스크의 IPC 메시지를 복구 스레드(401)로 재전송하는 것이 가능하다. 목적 스레드(401)가 클라이언트로부터 전송 받은 IPC 메시지를 처리하는 도중에 장애를 겪으면, IPC 메시지에 대한 처리 결과는 클라이언트로 전송되지 아니한다. 따라서 클라이언트는 응답을 기다리는 상태에 머물러 있게 된다. IPC 관리자(204)는 복구 스레드(401)가 클라이언트와 IPC 메시지 교환을 계속하게 함으로써 투명한(transparent) 복구 환경을 제공한다. 예를 들어, 복구 스레드(401)가 IPC 메시지 수신을 위해 IPC 대기 시스템 콜을 호출하면, 마이크로커널(101)에서 시스템 콜 호출자가 IPC 메시지에 대한 처리 결과를 대기하고 있는 클라이언트 태스크가 있는지 판단하고, 그러한 클라이언트 태스크가 있다면, 원래의 IPC handshake 루틴은 종료하고 IPC 메시지를 복구 스레드(401)로 재전송할 수 있다.

도 2에서, 로그 관리자(201), 복구 관리자(202), 리소스 관리자(203), IPC 관리자(204) 등의 구성요소는 스레드 또는 스레드의 컴포넌트 형태로 구현될 수 있다. 또한 각 구성요소의 단지 그 기능에 따른 논리적인 구분의 일례이다. 따라서 도시된 것과는 다른 기준에 따라서 각 구성요소가 구현될 수도 있고, 둘 이상의 기능 유닛은 통합되어 구현되거나 또는 개별적으로 구현될 수 있으며, 또한 어느 하나의 기능 유닛에서 수행되는 기능의 일부가 하나 또는 그 이상의 다른 기능 유닛에서 수행될 수도 있다.

도 3은 다른 실시예에 따른 장애 복구 장치의 구성을 도시한다.

도 3을 참조하면, 본 실시예에 따른 장애 복구 장치는 로그 관리자(201), 복구 관리자(202), 리소스 관리자(203), 및 IPC 관리자(204)를 포함한다. 각 구성요소에 관한 구체적인 설명은 도 2와 동일하다.

도 2와 다르게 도 3의 로그 관리자(201)는 사용자 계층, 즉 로더(212)에 형성될 수 있다. 로더(212)에 존재하는 로그 관리자(201)가 시스템 리소스 할당 정보를 기록하기 위해서 시스템 콜 랩퍼(wrapper) 라이브러리의 도움을 받을 수 있다. 예컨대, 시스템 콜 랩퍼 라이브러리가 시스템 리소스 할당 정보를 추출해서 로그 관리자(201)로 전달하면, 로그 관리자(201)는 전달 받은 시스템 리소스 할당 정보를 로그 테이블에 기록할 수 있다.

추가적 양상에 따라, 로그 관리자(201)가 로더(212)에 형성되는 경우, 목적 태스크(211)의 시스템 콜 인터페이스(301)에 존재하는 리소스 관리자(203)가 시스템 콜 요청 정보 및 시스템 콜 요청에 대한 결과 정보를 로그 관리자(201)로 제공할 수 있다.

도 4는 또 다른 실시예에 따른 장애 복구 장치의 구성을 도시한다.

도 4를 참조하면, 본 실시예에 따른 장애 복구 장치는 로그 관리자(201), 복구 관리자(202), 리소스 관리자(203), IPC 관리자(204), 및 복구 스레드 보호부(205)를 포함한다. 각 구성요소에 관한 구체적인 설명은 도 2와 동일하다.

도 2와 다르게 도 4의 복구 관리자(202)는 목적 태스크(211) 내에 형성될 수 있다. 복구 관리자(202)가 목적 태스크(211) 내에 존재하는 경우, 복구 관리자(202)는 목적 태스크(211) 내의 다른 스레드(예컨대, 402)의 장애 상황에 영향을 받지 않아야 한다.

복구 스레드 보호부(205)는 주소 공간 지정자(address space identifier, ASID)를 이용하여 복구 관리자(202) 또는 복구 관리자(202)에 속한 스레드를 보호할 수 있다. 복구 관리자 보호부(205)의 구체적인 기능은 후술한다.

일 양상에 따라, 복구 관리자(202)는 로그 관리자(201)에 의해 기록되는 로그 테이블이 마이크로커널(101) 또는 태스크(예컨대, 211)와 공유되도록 로그 테이블용 메모리 영역을 할당할 수 있다. 예컨대, 복구 관리자(202)는 먼저 로그 테이블을 위한 메모리 영역을 할당한다. 선택적으로, 메모리 영역의 페이징(paging)으로 인한 오버헤드를 줄이기 위해 해당 메모리 영역을 'pinned property'로 설정할 수 있다. 그리고 복구 관리자(202)는 목적 태스크(211)의 주소 공간에 매핑한다. 도 2와 다르게, 복구 관리자(202)가 목적 태스크(211)에 존재하므로, 목적 태스크(211)에 접근 권한을 부여하지 않아도 목적 태스크(211)가 할당된 메모리 영역에 접근하는 것이 가능하다. 또한 선택적으로, 복구 관리자(202)는 로그 테이블용 메모리 영역의 가상 주소와 실제 페이지의 물리 주소 간의 매핑이 페이지 테이블(page table)에 기록되지 않아서 런타임(runtime) 중 페이지 폴트(page fault)가 발생되는 것을 막기 위해 페이지 터치(page touch)를 미리 수행할 수도 있다.

도 5는 일 실시예에 따른 복구 관리자의 보호 방법을 도시한다.

도 4 및 도 5를 참조하면, 복구 관리자(202)는 Domain Access Control Resister(DACR)(501)를 통해 제공되는 address space identifier(ASID)에 의해 보호될 수 있다. 예를 들어, 복구 스레드 보호부(205)가, 목적 태스크(211)가 사용하는 메모리 영역(502) 중에서 복구 관리자(202)가 사용할 메모리 영역(503)에 다른 스레드가 사용하지 아니하는 ASID(예컨대, t)를 부여하는 것이 가능하다. 그리고 해당 영역(503)에 대한 access permission을 어떤 스레드가 실행되느냐에 따라 다르게 설정할 수 있다. 만약, 복구 스레드(401)가 스케줄되면, DACR(501) 값 중 Domain ID(t)의 permission을 TLB entry에서 지정하는 값을 따르도록 설정하고, 복구 스레드(401)가 아닌 스레드가 스케줄되면, 해당 Domain ID(t)의 permission을 No access, 즉, TLB entry에서 지정한 접근 권한과 상관없이 스레드가 접근할 수 없는 영역임을 표시하는 것이 가능하다.

도 6은 일 실시예에 따른 장애 복구 방법을 도시한다. 이것은 도 2 내지 도 4와 같은 장애 복구 장치에 의해 실행될 수 있다.

도 6을 참조하여 본 실시예에 따른 장애 복구 방법을 살펴보면, 먼저 스레드(thread)에 대한 시스템 리소스 할당 정보가 기록될 수 있다(601). 예컨대, 로그 관리자(201)가 동작 중인 스레드의 시스템 콜 요청 정보 및 시스템 콜 요청에 대한 결과 정보를 포함하는 튜플(tuple)을 생성하고, 생성된 튜플을 소정의 로그 테이블의 각 엔트리에 기록할 수 있다.

그리고 장애(fault)와 관련된 목적 스레드(target thread)의 역할을 대신하기 위한 복구 스레드(recovery thread)가 생성될 수 있다(602). 예컨대, 복구 관리자(202)가 목적 스레드가 사용하던 시스템 리소스를 해제하지 않고, 시스템 리소스 할당 정보를 참조하여 목적 스레드가 사용하던 시스템 리소스를 재사용하면서 목적 스레드의 리플레이(replay)를 수행하는 복구 스레드를 생성할 수 있다.

그리고 시스템 리소스 할당 정보를 토대로 목적 스레드가 사용하던 시스템 리소스가 복구 스레드에 매핑될 수 있다(603). 예컨대, 리소스 관리자(203)가 복구 스레드로부터 시스템 리소스 할당 요청을 수신하고, 시스템 리소스 할당 정보를 참조하여 목적 스레드가 사용하던 시스템 리소스를 반환하는 것이 가능하다.

그리고 목적 스레드와 관련된 IPC(inter-process communication) 메시지가 복구 스레드로 제공될 수 있다(604). 예컨대, IPC 관리자(204)가 목적 스레드가 사용하던 IPC 종단점(endpoint)을 복구 스레드로 전환하거나, 또는 클라이언트 태스크의 IPC 메시지를 복구 스레드로 재전송하는 것이 가능하다.

이상에서 살펴본 것과 같이, 개시된 실시예에 의하면, 장애와 관련된 태스크 또는 스레드가 사용하던 시스템 리소스를 재활용하면서 장애 복구가 이루어지기 때문에 빠른 복구가 가능하고, 또한 IPC 메시지가 복구 스레드로 적절하게 제공되기 때문에 투명한 장애 복구가 가능하다.

한편, 본 발명의 실시 예들은 컴퓨터로 읽을 수 있는 기록 매체에 컴퓨터가 읽을 수 있는 코드로 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록 매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록 장치를 포함한다.

컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현하는 것을 포함한다. 또한, 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산 방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고 본 발명을 구현하기 위한 기능적인(functional) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술 분야의 프로그래머들에 의하여 용이하게 추론될 수 있다.

나아가 전술한 실시 예들은 본 발명을 예시적으로 설명하기 위한 것으로 본 발명의 권리범위가 특정 실시 예에 한정되지 아니할 것이다.

201: 로그 관리자
202: 복구 관리자
203: 리소스 관리자
204: IPC 관리자
205: 복구 관리자 보호부
401: 복구 스레드
402: 목적 스레드

Claims

스레드(thread)에 대한 시스템 리소스 할당 정보를 기록하는 로그 관리자;
장애(fault)와 관련된 목적 스레드(target thread)의 역할을 대신하기 위한 복구 스레드(recovery thread)를 생성하는 복구 관리자; 및
상기 시스템 리소스 할당 정보를 이용하여 상기 목적 스레드가 사용하던 시스템 리소스를 상기 복구 스레드에 매핑하는 리소스 관리자; 를 포함하는 장애 복구 장치.
제 1 항에 있어서, 상기 복구 스레드는
상기 시스템 리소스 할당 정보를 참조하여 상기 목적 스레드가 사용하던 시스템 리소스를 재사용하면서 상기 목적 스레드의 리플레이(replay)를 수행하는 장애 복구 장치.
제 1 항에 있어서, 상기 로그 관리자는
동작 중인 스레드의 시스템 콜 요청 정보 및 시스템 콜 요청에 대한 결과 정보를 포함하는 튜플(tuple)을 생성하고, 생성된 튜플을 소정의 로그 테이블의 각 엔트리에 기록하는 장애 복구 장치.
제 1 항에 있어서, 상기 로그 관리자는
상기 스레드가 속한 태스크의 실행 환경을 제공하는 계층인 커널 계층(kernel level)에 형성되는 장애 복구 장치.
제 1 항에 있어서, 상기 로그 관리자는
상기 스레드가 속한 태스크가 동작하는 계층인 사용자 계층(user level)에 형성되는 장애 복구 장치.
제 5 항에 있어서, 상기 로그 관리자는
시스템 콜 랩퍼(wrapper) 라이브러리를 이용하여 상기 시스템 리소스 할당 정보를 기록하는 장애 복구 장치.
제 1 항에 있어서, 상기 로그 관리자는
상기 스레드가 속한 태스크의 스테이트 속성(state type)을 고려하여 불필요한 시스템 리소스 할당 정보를 삭제하는 장애 복구 장치.
제 1 항에 있어서, 상기 복구 관리자는
상기 목적 스레드가 사용하던 시스템 리소스를 해제하지 않고 유지시키는 장애 복구 장치.
제 1 항에 있어서, 상기 복구 관리자는
상기 복구 스레드가 상기 목적 스레드의 리플레이(replay)를 수행할 수 있도록 상기 복구 스레드의 실행 컨텍스트(execution context)를 설정하는 장애 복구 장치.
제 1 항에 있어서, 상기 복구 관리자는
상기 목적 스레드가 속한 태스크에 형성되는 장애 복구 장치.
제 10 항에 있어서,
주소 공간 지정자(address space identifier, ASID)를 이용하여 상기 복구 관리자를 보호하는 복구 스레드 보호부; 를 더 포함하는 장애 복구 장치.
제 1 항에 있어서, 상기 복구 관리자는
상기 목적 스레드가 속한 태스크를 생성하는 로더(loader)에 형성되는 장애 복구 장치.
제 1 항에 있어서, 상기 리소스 관리자는
상기 복구 스레드로부터 시스템 리소스 할당 요청을 수신하고, 상기 시스템 리소스 할당 정보를 참조하여 상기 목적 스레드가 사용하던 시스템 리소스를 반환하는 장애 복구 장치.
제 1 항에 있어서, 상기 리소스 관리자는
상기 목적 스레드가 속한 태스크 내의 시스템 콜 인터페이스에 형성되는 장애 복구 장치.
제 1 항에 있어서,
상기 목적 스레드와 관련된 IPC(inter-process communication) 메시지를 상기 복구 스레드로 제공하는 IPC 관리자; 를 더 포함하는 장애 복구 장치.
제 15 항에 있어서, 상기 IPC 관리자는
상기 목적 스레드가 사용하던 IPC 종단점(endpoint)을 상기 복구 스레드로 전환하는 장애 복구 장치.
제 15 항에 있어서, 상기 IPC 관리자는
클라이언트 태스크의 IPC 메시지를 상기 복구 스레드로 재전송하는 장애 복구 장치.
제 15 항에 있어서, 상기 IPC 관리자는
상기 스레드가 속한 태스크의 실행 환경을 제공하는 계층인 커널 계층(kernel level)에 형성되는 장애 복구 장치.
스레드(thread)에 대한 시스템 리소스 할당 정보를 기록하는 단계;
장애(fault)와 관련된 목적 스레드(target thread)의 역할을 대신하기 위한 복구 스레드(recovery thread)를 생성하는 단계; 및
상기 시스템 리소스 할당 정보를 이용하여 상기 목적 스레드가 사용하던 시스템 리소스를 상기 복구 스레드에 매핑하는 단계; 를 포함하는 장애 복구 방법.
제 19 항에 있어서,
상기 목적 스레드와 관련된 IPC(inter-process communication) 메시지를 상기 복구 스레드로 제공하는 단계; 를 더 포함하는 장애 복구 방법.