KR100470259B1 - 리소스 그룹을 세부적이고 지속적으로 교환하기 위한방법, 시스템 및 프로그램 제품 - Google Patents

Abstract

리소스 그룹의 하나 이상의 리소스들에 대한 쓰기 요청이 지속적이고 세부적 방식으로 수행된다. 쓰기 요청이 수신되면, 현재의 리소스 그룹 내의 데이타를 반영하도록 백업 리소스 그룹이 갱신된다. 그 후, 백업 리소스 그룹에 대해 쓰기 요청이 수행된다. 쓰기 동작(들)을 성공적으로 수행한 후에, 백업 리소스 그룹이 새로운 현재의 리소스 그룹이 되도록 하는 방식으로 백업 리소스 그룹과 현재의 리소스 그룹이 세부적이며 일관된 방식으로 교환된다.

Description

리소스 그룹을 세부적이고 지속적으로 교환하기 위한 방법, 시스템 및 프로그램 제품{METHOD, SYSTEM AND PROGRAM PRODUCTS FOR ATOMICALLY AND PERSISTENTLY SWAPPING RESOURCE GROUPS}

본 발명은 대체적으로 컴퓨팅 환경 내에서의 처리에 관한 것으로, 보다 구체적으로는, 일관되고 지속적이며 세부적인 리소스 그룹 교환(consistent, persistent and atomic swap of resource groups)을 제공하는 것에 관한 것이다.

데이타 무결성(integrity)은 컴퓨팅 환경 내에서에 동작을 수행할 때 발생하는 가장 중요한 관심사항중 하나이다. 특히, 임의의 유형의 데이타 수정사항을 잃지 않는 것은 중요하다. 컴퓨팅 환경 내의 시스템이 고장나면, 전형적으로 적절한 복구 시나리오를 갖는 것이 필수적이다.

적절한 복구를 제공하기 위하여, 데이타 백업을 유지하는 것이 상례이다. 이 예에서, 이러한 백업은 주기적으로 수행된다. 나아가, 데이타에 대한 변경 사항은, 마지막 백업 이후에 발생한 사항을 기록하는 로그 파일(log file)에 기록된다. 복구하는 동안에, 고장 이전에 발생했던 동작들을 재건하고 데이타를 복구하기 위해 로그 파일뿐만 아니라 백업이 사용된다.

적절한 백업을 제공하기 위한 노력들이 이루어져 왔지만, 여전히 개선의 여지가 있다. 예를 들어, 플랫폼에 독립적이고 애플리케이션 수준에서 제공되며 효율적인 데이타 백업의 능력이 필요하다.

컴퓨팅 환경의 리소스 그룹에 대한 수정사항을 관리하는 방법의 제공을 통해 종래 기술의 단점이 극복되며 추가적인 이점이 제공된다. 이 방법은, 예를 들어, 백업 리소스 그룹중의 하나 이상의 리소스에 대하여 현재의 수정 요청을 실행하는 단계와; 수정된 백업 리소스 그룹이 현재의 리소스 그룹이 되도록 수정된 백업 리소스 그룹과 현재의 리소스 그룹을 세부적으로 교환하는 단계－상기 세부적 교환은, 백업 리소스 그룹의 명칭과 현재의 리소스 그룹의 명칭을 명칭의 길이에 영향을 주지 않고 변경하는 단계를 포함함－를 포함한다.

상술한 방법에 대응하는 시스템 및 컴퓨터 프로그램 제품도 역시 기술되며 본 명세서에서 청구될 것이다.

추가적인 특징 및 이점들이 본 발명의 가르침을 통해 실현된다. 본 발명의 다른 실시예들과 특징들도 본 명세서에서 상세히 기술되며 특허청구범위에 기재된 발명의 일부로서 간주된다.

도 1은 본 발명의 특징들을 수용하며 이용하는 컴퓨팅 환경의 실시예를 도시하는 도면.

도 2는 본 발명의 특징에 따른 현재의 리소스 그룹과 그 백업 복사본의 한 예를 도시하는 도면.

도 3은 본 발명의 특징에 따라 세부적이고 지속적인 방식으로 리소스 그룹의 리소스들을 수정하기 위해 수행되는 다양한 단계들의 예를 도시하는 도면.

도 4는 본 발명의 특징에 따른 현재 리소스 그룹 및 백업 리소스 그룹의 세부적 교환의 예를 도시한 도면.

<도면의 주요 부분에 대한 부호의 설명>

100 : 분산 컴퓨팅 환경

102 : 프레임

104 : LAN 게이트

106 : 처리 노드

본 발명의 한 특징에 따라, 리소스 그룹들 중 하나 이상의 리소스(예를 들어, 파일, 테이블, 오브젝트등)에 대한 수정이 세부적이고도 지속적으로 수행된다. 특히, 일관되고 지속적이며 세부적인 2개 세트 이상의 리소스 교환이 제공된다.

본 발명의 특징들을 수용하고 이용하는 컴퓨팅 환경의 한 예가 도 1에 도시되고 기술된다. 분산 컴퓨팅 환경(100)은, 예를 들어, LAN 게이트(104)를 통해 서로 결합된 복수개의 프레임(102)를 포함한다. 프레임(102) 및 LAN 게이트(104)는 본 명세서에서 상세히 기술될 것이다.

한 예에서, 분산 컴퓨팅 환경(100)은 8개의 프레임을 포함하며, 그 각각은 복수개의 처리 노드(106)을 포함한다. 한 예에서, 각각의 프레임은 16개의 처리 노드를 포함하며, 처리 노드 각각은 하나 이상의 프로세서를 포함한다. 각각의 처리 노드는, 예를 들어, AIX(등록상표) 또는 UNIX(등록상표) 운영 체제 기반에서 동작하는 RISC/6000(등록상표) 컴퓨터이다. 프레임 내의 각각의 처리 노드는 예를 들어, 내부 LAN 접속을 통해 프레임의 다른 처리 노드에 결합된다. 추가적으로, 각각의 프레임은 LAN 게이트(104)를 통해 다른 프레임들에 결합된다.

예를 들어, 각각의 LAN 게이트(104)는 RISC/6000(등록상표)) 컴퓨터 또는 LAN으로 임의의 컴퓨터 네트워크 접속, 또는 네트워크 라우터를 포함한다. 그러나, 이들은 단지 예일 뿐이다. 다른 유형의 LAN 게이트도 있으며 프레임들을 서로 결합시키기 위해 다른 메카니즘이 이용될 수 있다는 것은 당업자에게 명백하다.

도 1의 분산 컴퓨팅 환경은 단지 예일 뿐이다. 8개 이상 또는 이하의 프레임, 또는 프레임당 16개 이상 또는 이하의 노드를 가질 수도 있다. 나아가, 처리 노드가 반드시 AIX(등록상표)를 실행하는 RISC/6000(등록상표)이어야만 하는 것도 아니다. 처리 노드들 중 일부 또는 전부는 서로 다른 유형의 컴퓨터 및/또는 서로 다른 운영 체제를 포함할 수 있다. 예를 들어, 본 발명은 LINUX(등록상표) 및/또는 Windows(등록상표) 운영 체제를 채택할 수도 있다. 나아가, 하나 이상의 노드 및/또는 운영 체제가 나머지 노드 및 운영 체제와 구별되는 그러한 이종 환경도 본 발명의 특징을 포함하고 이용할 수 있다. 이와 같은 이종 환경의 노드들은 서로 협동하며 자원을 공유하는 식으로 상호작용한다.

분산 컴퓨팅 환경의 사용자들은, 컴퓨팅 환경의 노드들 또는 이들에 부착된 저장 장치 내에 저장된 (파일, 테이블, 오브젝트와 같은) 리소스로부터 데이타를 판독하거나 기록한다. 한 예에서, 논리적으로 관련된 리소스 세트상에서 동작이 수행된다. 이러한 리소스 세트는 본 명세서에서 리소스 그룹이라 불린다. 리소스 그룹의 리소스들은 판독 또는 기록 동작을 수행하는 사용자들에 의해 액세스된다.리소스 그룹들중 하나 이상의 리소스에 대한 기록 요청이 수행될때마다 본 발명의 특징에 따라 지속이고도 세부적으로 변경이 수행된다.

지속적이고도 세부적으로 변경을 수행하기 위해, 적어도 2개의 리소스 그룹이 유지된다. 하나의 리소스 그룹은 리소스의 현재 상태를 나타내고 현재의 리소스 그룹(current resource group)라 불린다. 또 다른 리소스 그룹은 리소스의 백업 또는 쉐도우 버전을 나타내며 백업(또는 작업) 리소스 그룹(backup resource group)이라 불린다.

도 2에 도시된 바와 같이, 현재의 리소스 그룹(200)은 하나 이상의 리소스(202)를 가지며, 백업 리소스 그룹(204)는 이들 리소스의 복사본(206)을 가진다. 리소스 그룹들중의 하나 이상의 리소스를 갱신하고자 할 때, 갱신은 백업 리소스 그룹 내에서 수행되며, 그 다음, 본 발명의 특징에 따라 리소스 그룹이 세부적으로 교환된다. 따라서, 교환 이후에, 변경 사항이 양쪽 리소스 그룹 모두에 반영된다.

리소스를 세부적, 일관적, 및 지속적으로 수정하는데 연관된 논리의 한 실시예가 도 3을 참조하여 기술된다. 이 예에서, 이 논리는 노드(예를 들어, 서버) 내의 기능에 의해 수행된다.

초기에, 사용자는, 예를 들어, (한 예로서) 쓰기 요청(300)을 컴퓨팅 환경 내의 한 노드로 포워딩한다. 이 요청이 노드에 의해 수신될 때, 이 노드내의 논리는 여러가지 동작을 수행한다. 예를 들어, 노드는 단계(306)에서 현재의 리소스 그룹으로부터의 0개 이상의 최근 수정사항들을 백업 리소스 그룹(304)로 복사한다. 구체적으로, 백업 리소스 그룹은 현재의 리소스 그룹 내의 데이타를 반영하도록 갱신된다. 이것은 양쪽 리소스 그룹이 록스텝(lockstep)으로 갱신되도록 유지함으로써 될 수 있다. 특히, 임의의 시점에서, 2개의 그룹은 마지막 쓰기 동작에 의해 유발된 수정사항만큼만 다르다. 따라서, 백업 리소스 그룹은 이전의 쓰기 동작으로 갱신된다.

현재의 리소스 그룹 내의 데이타를 반영하도록 백업 리소스 그룹을 갱신한 후에, 노드는 단계(308)에서 백업 리소스 그룹에 대한 새로운 쓰기 요청을 수행한다. 한편, 단계(310)에서 소정의 읽기 요청이 현재의 리소스 그룹상에서 진행될 수 있다.

일단 쓰기 동작이 성공적으로 수행되고 나면, 단계(312)에서 백업 리소스 그룹 및 현재의 리소스 그룹이 교환된다. 한 실시예에서, 이 교환은 세부적 방식으로 수행됨으로써, 교환 동작 동안에 시스템이 고장나거나 에러가 발생하더라도 복구 절차 또는 시스템의 차기 초기화시에 일치된 리소스 상태가 여전히 얻어질 수 있다.

한 예에서, 세부적 교환은 리소스를 리네임함으로써 수행된다. 특히, 각각의 리소스는 자신과 관련된 명칭을 가지며, 각각의 명칭은 리소스의 버젼을 가리키는 첨자(suffix)를 가진다. 한 예로서, 가능한 버전 꼬리표로서 .0, .1, .2가 있을 수 있으며, 자릿수는 모듈로 3(modulo 3)에 따라 순서가 매겨진다. 즉, 0<1, 1<2, 및 2<0이다. 이러한 순서 매김에서 가장 높은 버전은 리소스의 현재 상태를 반영하는 반면, 가장 낮은 버전은 리소스가 백업 리소스 그룹에 속한다는 것을 가리킨다. 따라서, 리소스의 버전 꼬리표에 기초하여 어떤 리소스가 현재 버전에 대응하는지를 판별하는 것이 가능하다.

본 발명의 한 특징에 따라, 변경의 미세성을 제공하기 위하여 최소 개수의 리소스 동작을 이용하여 버전 넘버가 토글링된다. 토글링 한예는, 특정예를 도시하는 도4를 참조하여 기술될 것이다.

도 4의 예에서, 2개의 리소스 그룹(400과 402)가 있다고 가정하고, 각각의 리소스 그룹은 A 및 B라 불리는 2개의 리소스를 가진다고 가정하자. 따라서, 백업 리소스 그룹은 A.0 및 B.0)을 포함하는 반면, 현재의 리소스 그룹은 A.1 및 B.1을 포함한다. 이 예에서, 초기화시에, 양쪽 리소스 세트는 동일한 정보를 포함한다.

다음으로, 기록 동작이 요청된다. 기록 동작은 (현재의 리소스 그룹의 내용을 반영하도록 갱신된) 백업 (또는 작업) 리소스 그룹 내에서 발생한다. 갱신이 성공적이면, 데이타는 예를 들어 최하위 버전을 갖는 리소스의 디스크에 저장된다. 이 예에서, 최하위 버전은 0이다. 어떠한 에러도 발생하지 않는다면, 이제 백업 그룹은 리소스 그룹의 현재 버전을 포함한다. 따라서, 최하위 버전은 모듈로 3 순서를 이용하여 최상위 버전으로 리네임된다.

특히, 이 예에서, 리소스의 리네임은 동일한 순서, 예를 들어, 사전순으로수행된다. 따라서, 이 경우에, 먼저 리소스 A.0이 A.2로 리네임된다(참조 번호 404를 참조한다). 반면, 현재의 리소스 그룹의 명칭은 바뀌지 않는다(참조 번호 406을 참조한다). 그 다음, 리소스 B.0은 B.2로 리네임된다(참조 번호 408을 참조한다). 그룹의 마지막 리소스의 리네임을 성공적으로 마치면 현재의 그룹과 백업 그룹의 세부적 교환이 완료된다. 따라서, 리소스 A.2와 B.2는 이제 새로운 현재의 리소스 그룹(408)의 일부가 되고, 리소스 A.1 및 B.1은 새로운 백업 리소스 그룹(410)의 멤버가 된다.

현재의 리소스 그룹과 백업 리소스 그룹의 세부적 교환이 앞서 상세히 기술되었다. 본 명세서에서 기술된 예들에서는, 비록 리소스의 명칭이 수정되고 있지만, 명칭의 길이는 일정하게 유지된다(이는 모듈로 3 산술 방식때문이다). 전형적으로, UNIX와 같은 파일 시스템에서, 명칭 변경은 I-노드 또는 등가의 리소스 구조 정의의 수정을 포함한다. 파일 시스템이 풀(full) 상태이어도, 이러한 수정은 안전하게 수행될 수 있다.

리소스 그룹의 세부적 교환을 성립시키는 것은 마지막 리네임 동작(이 경우에는 두번째 리네임 동작)이다. 이전의 동작들이 성공적이었다면, 리소스 그룹은 갱신된 것으로 간주된다. 따라서, 이제 백업 리소스 그룹은 현재의 리소스 그룹이 되고 그 역도 성립한다. 리소스를 제어하는 서비스가 고장나면, 더 높은 버전을 현재의 버전으로서 선언함으로써 데이타가 복구될 수 있다.

리소스 그룹이 2개 이상의 리소스, 예를 들어 n개의 리소스를 가진다면, 마지막 리소스의 리네임 동작은 리소스 그룹의 세부적 교환으로 간주된다. 나아가,특정 리소스 그룹의 전체 리소스보다는 작은 하나 이상의 리소스를 리네임한 후에 고장이 발생하면, 리소스 그룹 버전의 불일치가 있을 것이다. 따라서, 일치되지 않는 리소스 그룹의 버전은 파괴된 것으로 선언되고, 다른 버전이 여전히 현재의 버전으로 간주된다. 이것은 일치되는 가장 높은 버전이 현재의 버전이기 때문이다(즉, 모든 리소스 세트가 동일한 버전을 가진다면 리소스 그룹은 일치된다).

많은 시나리오에서, 리소스 그룹들중 어느 것이 쓰기 동작의 타겟인지에 관계없이 모듈로 (n)과 순서매김이 이용될 수 있다. 나아가, 본 발명의 기법은 n개의 리소스를 갖는 리소스 그룹에도 적용될 수 있다. 리소스는 미리 결정된 순서를 이용하여 리네임될 것이고 이 순서에서 마지막 리네임이 양쪽 리소스를 교환하는 세부적 동작으로 간주된다. n개의 리소스 그룹에서 본 발명을 이용할 때, 모듈로 (n+1) 산술식이 이용된다. 이 산술식은 n개의 리소스 세트에 대해 순서를 매기기 위해 이용된다.

본 발명은, 양쪽 그룹의 리소스들간에 대응관계가 항상 성립되지는 않는 경우에도 적용될 수 있다. 특히, 구동 프로그램이 양쪽 그룹에서 적어도 2개의 리소를 확인할 수 있다면, 2개의 리소스로 이루어진 쌍의 한쪽은 처음에 리네임되고, 나머지는 마지막에 리네임됨으로써, 시스템의 셧다운시에, 이들쌍은 서로간에 호환성이 있는지를 판별하기 위해 비교될 수 있다. 다시 한번, 호환되는 버전을 갖는 최상위 쌍을 갖는 리소스 그룹이 현재의 리소스 그룹으로서 선언된다.

본 발명은, 고정된 크기의 명칭부여 방법을 제공하고 리소스 그룹의 어떤 버전이 현재 버전인지를 판별하는 기법을 제공함으로써 하부 운영 체제의 세부 수준에서 모두 리네임되어 있지 않으면 인정하지 않는 방식(all or nothing semantics)을 제공하는 플랫폼 독립형의 응용-레벨 기법을 제공한다. 나아가, 본 발명은, 추가적인 리소스를 이용하지 않고도 데이타 무결성을 해결해 줄 수 있는 (즉, 제어 파일이 파괴되면, 데이타 파일 그 자체도 파괴됨) 리소스 그룹의 적어도 하나의 일치되는 버전이 발견될 수 있도록 해준다.

본 발명의 특징들은, 데이타의 현재의 버전과 백업 버전이 일치되는 방식으로 유지되어야 하는 어떠한 시나리오에도 적용가능하다. 한 예에서, 이 기법은 하나의 테이블이 리소스 세트로서 저장되고 세부적 기록 동작이 범위에 관계없이 지원되는 관계형 데이타 저장소를 위해 이용된다.

본 발명은 분산 컴퓨팅 환경에만 제한되는 것은 아니며, 단일 시스템 환경을 포함한 임의의 컴퓨팅 환경에도 사용될수 있다. 나아가, 본 발명의 하나 이상의 특징들은 이종 시스템뿐만 아니라 동종 시스템에도 적용가능하다. 한 예로서, 이종 환경 시스템의 공동작용을 용이하게 해주는 능력이 제공된다.

본 발명은, 예를 들어, 컴퓨터 이용가능 매체를 갖는 (예를 들어, 하나 이상의 컴퓨터 프로그램 제품과 같은) 제조품 내에도 포함될 수 있다. 이 매체는 예를 들어 본 발명의 능력을 제공하며 용이하게 해주는 컴퓨터 판독가능 프로그램 코드수단을 가진다. 제조품은 컴퓨터 시스템의 일부로서 포함될 수도 있고 독립적으로 판매될 수도 있다.

추가적으로, 본 발명의 능력을 수행하기 위해 머신에 의해 실행가능한 명령어들로 이루어진 적어도 하나의 프로그램을 유형적으로 구현해주며, 머신에 의해 판독될수 있는 적어도 하나의 프로그램 저장 장치가 제공될 수 있다.

본 명세서에서 기술된 흐름도는 단지 예시적인 것이다. 본 발명의 정신으로부터 벗어나지 않고 본 명세서에 기술된 이들 도면 및 단계들에 다양한 변형이 이루어질 수도 있다. 예를 들어, 단계들은 다양한 순서로 수행될 수도 있고, 단계들이 추가, 삭제 또는 수정될 수도 있다. 이들 변형들 모두 특허청구범위에서 청구되고 있는 본 발명의 일부로서 간주된다.

양호한 실시예들이 본 명세서에서 도시되고 기술되었지만, 본 발명의 정신으로부터 벗어나지 않고도 다양한 수정, 추가, 대체등이 이루어질 수 있다는 것은 당업자에게 명백할 것이다. 아울러, 이러한 것들은 첨부된 특허청구범위에서 정의된 바와 같은 본 발명의 영역 내에 포함되는 것으로 간주된다.

플랫폼에 독립되어 있으며 애플리케이션 수준에서 제공되며 효율적인 데이타 백업이 제공된다.

Claims (21)

1. 컴퓨팅 환경의 데이터 리소스 그룹(data resource group)에 대한 수정사항을 관리하기 위한 방법에 있어서,

   백업 리소스 그룹의 하나 이상의 리소스에 대하여 현재의 수정 요청을 실행하는 단계와,

   상기 수정된 백업 리소스 그룹이 현재의 리소스 그룹이 되도록 상기 리소스 그룹들의 명칭을 변경함으로써 상기 수정된 백업 리소스 그룹과 현재의 리소스 그룹을 세부적으로 교환(atomically swapping)하는 단계 - 상기 세부적 교환 단계는, 명칭의 길이에 영향을 주지 않고 상기 백업 리소스 그룹의 하나 이상의 명칭을 변경하는 단계를 포함함-

   을 포함하는 방법.
2. 삭제
3. 삭제
4. 제1항에 있어서, 상기 현재의 수정 요청을 실행하기 이전에, 상기 백업 리소스 그룹의 하나 이상의 리소스를 갱신하는 단계를 더 포함하는 방법.
5. 제4항에 있어서, 상기 갱신 단계는 상기 현재의 리소스 그룹으로부터 상기 백업 리소스 그룹에 하나 이상의 리소스에 대한 하나 이상의 수정사항을 복제하는 단계를 더 포함하는 방법.
6. 제1항에 있어서, 상기 백업 리소스 그룹의 하나 이상의 명칭을 변경하는 상기 단계는 상기 백업 리소스 그룹의 하나 이상의 리소스의 하나 이상의 명칭을 갱신하는 단계를 포함하는 방법.
7. 제6항에 있어서, 상기 하나 이상의 명칭을 갱신하는 단계는 갱실될 각 명칭의 첨자(suffix)를 변경하는 단계를 포함하는 방법.
8. 제7항에 있어서, 상기 첨자를 변경하는 단계는 상기 첨자를 변경하기 위해 모듈로(modulo) 연산을 이용하는 단계를 포함하는 방법.
9. 제6항에 있어서,상기 갱신 단계는 미리 정해진 순서로 수행되고, 상기 미리 정해진 순서의 마지막 리소스 명칭이 갱신되면 세부적 교환이 완료되는 방법.
10. 제1항에 있어서, 상기 하나 이상의 명칭을 변경하는 단계는 미리 정해진 순서로 상기 하나 이상의 명칭을 변경하는 단계를 포함하고, 상기 미리 정해진 순서의 마지막 명칭의 변경이 세부적 교환의 완료를 나타내는 방법.
11. 제1항에 있어서, 상기 하나 이상의 명칭을 변경하는 단계는 상기 하나 이상의 명칭의 상기 하나 이상의 첨자를 변경하기 위해 모듈로 연산을 이용하는 단계를 포함하는 방법.
12. 제1항에 있어서, 상기 세부적으로 교환하는 단계는 상기 컴퓨팅 환경의 플랫폼에 독립적으로 수행되는 방법.
13. 제1, 4, 5, 6, 7, 8, 9, 10, 11 및 12항중 어느 한 항에 따른 방법의 각 단계들을 실행하는 각각의 수단들을 포함하는 시스템.
14. 제1, 4, 5, 6, 7, 8, 9, 10, 11 및 12항중 어느 한 항에 따른 방법을 수행하기 위해 컴퓨터에 의해 실행가능한 명령어들로 이루어진 컴퓨터 프로그램이 기록된 컴퓨터에 의해 판독될 수 있는 기록매체.
15. 컴퓨팅 환경의 데이터 리소스 그룹(data resource group)에 대한 수정사항을 관리하는 방법에 있어서,

    백업 리소스 그룹의 적어도 하나의 리소스에 대한 수정 요청을 수신하는 단계와,

    상기 백업 리소스 그룹의 상기 적어도 하나의 리소스에 대하여 수정 요청을 실행하는 단계와,

    상기 수정된 백업 리소스 그룹이 현재의 리소스 그룹이 되도록 상기 수정된 리소스 그룹과 상기 현재의 리소스 그룹을 세부적으로 교환하는 단계 - 상기 세부적 교환 단계는, 명칭의 길이에 영향을 주지 않고 상기 백업 리소스 그룹의 하나 이상의 리소스의 하나 이상의 명칭을 변경하는 단계를 포함함-

    를 포함하는 방법.
16. 제15항에 있어서, 상기 하나 이상의 명칭을 변경하는 단계는 상기 하나 이상의 명칭의 하나 이상의 첨자를 변경하기 위해 모듈로 연산을 이용하는 단계를 포함하는 방법.
17. 제16항에 있어서, 상기 하나 이상의 명칭을 변경하는 단계는 미리 정해진 순서로 상기 하나 이상의 명칭을 변경하는 단계를 포함하고, 상기 미리 정해진 순서로 마지막 명칭을 변경하는 단계는 상기 세부적 교환의 완료를 나타내는 방법.
18. 제15항 내지 제17항중 어느 한 항에 따른 방법의 각 단계들을 실행하는 각각의 수단들을 포함하는 시스템.
19. 컴퓨팅 환경의 데이터 리소스 그룹(data resource group)에 대한 수정사항을 관리하는 시스템에 있어서, 상기 시스템은,

    백업 리소스 그룹의 하나 이상의 리소스들에 대한 현재의 수정 요청과,

    상기 수정된 백업 리소스 그룹이 현재의 리소스 그룹이 되도록 상기 수정된 백업 리소스 그룹과 현재의 리소스 그룹을 세부적으로 교환하는 노드 - 상기 세부적 교환은 상기 백업 리소스 그룹의 하나 이상의 명칭 길이에 영향을 주지않고 상기 하나 이상의 명칭을 변경하는 것을 포함함-

    를 포함하는 시스템.
20. 컴퓨팅 환경의 데이터 리소스 그룹(data resource group)에 대한 수정사항을 관리하는 시스템에 있어서, 상기 시스템은,

    백업 리소스 그룹의 적어도 하나의 리소스에 대한 현재의 수정 요청과,

    상기 백업 리소스 그룹의 하나 이상의 리소스를 갱신하는데 사용되는 현재 리소스 그룹의 데이터와,

    상기 백업 리소스 그룹의 상기 적어도 하나의 리소스에 대한 상기 수정 요청을 실행시키는 노드를 포함하고,

    상기 노드는 상기 수정된 백업 리소스 그룹이 현재의 리소스 그룹이 되도록 상기 수정된 백업 리소스 그룹과 현재의 리소스 그룹을 세부적으로 교환하되, 상기 세부적 교환은 상기 백업 리소스 그룹의 하나 이상의 명칭 길이에 영향을 주지않고 상기 하나 이상의 명칭을 변경하는 것을 포함하는 시스템.
21. 제15항 내지 제17항중 어느 한 항에 따른 방법을 수행하기 위해 컴퓨터에 의해 실행가능한 명령어들로 이루어진 컴퓨터 프로그램이 기록된 컴퓨터에 의해 판독될 수 있는 기록매체.