KR20150052036A - 소프트웨어 정의 네트워크 연결 저장 시스템 및 방법 - Google Patents

Abstract

소프트웨어 정의 네트워크 연결 저장 시스템을 설정하는 방법은 (가상 컴퓨터 시스템들일 수 있는) 제 1 및 제 2 세트의 논리 컴퓨터 시스템들을 각각 네임 스페이스 서버들 및 데이터 스페이스 서버들로서 설정하는 단계를 포함한다. 각각의 네임 스페이스 서버는 (a) 그 메모리 내에서, 파일 및 디렉토리 이름들과 파일 및 디렉토리 이름들과 결합된 사용자 데이터가 존재하는 위치에 대한 정보를 포함하는, 파일 시스템 메타데이터를 저장하고, 파일 시스템 메타데이터의 동적으로 업데이트된 카피를 그 저장 시스템 내에 저장하도록 구성되고, (b) 네임 스페이스의 사전 설정된 서브세트에 대해서 적어도 하나의 요청 클라이언트 컴퓨터로부터의 저장 시스템 경로 이름 요청들을 처리하고, 각각의 요청에 응답하여 요청 클라이언트 컴퓨터의 의해 사용되기 위한 핸들을 반송하도록 구성되고, (ii) 각각의 데이터 스페이스 서버는 네임 스페이스 서버들에 의해 결정되는 핸들들에 기초하여 그 저장 시스템 내에 사용자 데이터를 저장하고 검색하도록 구성된다.

Description

소프트웨어 정의 네트워크 연결 저장 시스템 및 방법 {SOFTWARE-DEFINED NETWORK ATTACHABLE STORAGE SYSTEM AND METHOD}

(관련 출원의 상호 참조)

본 출원은 상기한 발명의 명칭과 동일한 발명의 명칭으로 2012년 9월 14일자로 출원한 미국 가출원 제 61/701,441 호의 우선권을 주장한다. 본 출원은 또한 상기한 발명의 명칭과 동일한 발명의 명칭으로 2013년 2월 5일자로 출원한 미국 특허출원 제 13/759,799 호의 우선권을 주장한다. 이들 관련 출원들은 참고자료로서 본 명세서에 통합된다.

(기술 분야)

본 발명은 네트워크 연결 저장 시스템(network attachable storage system)에 관한 것으로, 특히 소프트웨어 정의(software-defined) 저장 시스템에 관한 것이다.

네트워크 연결 저장 시스템에 대한 문헌이 다수 존재한다.

(실시들의 요약) 본 발명의 실시예들은 저장 요청들을 처리함에 있어서 종래의 파일 시스템(file system)들과 비교하여 현저히 증가된 효율을 제공한다. 본 발명의 실시예들은 네임 스페이스(namespace) 서버(server)들을 사용함으로써, 단지 네임 스페이스 서버들의 메모리(memory) 내에 저장되어 있는 메타데이터(metadata)에 기초하여 데이터(data) 스페이스 서버들에 의해 액세스(access)된 파일 오브젝트(object)들에 대한 핸들(handle)들을 결정하기 때문에, 본 발명의 실시예들은 이들 핸들을 결정하기 위하여 디스크(disk)로부터의 읽기 동작들을 수행할 필요가 없다. 감소된 디스크 동작 횟수는 파일 시스템의 성능을 향상시킨다. 실제로, 파일 시스템의 구현예들은 전형적으로 저장 요청들을 처리함에 있어서 종래의 파일 시스템보다 한자리수만큼 더욱 뛰어난 성능 향상을 보여준다.

본 발명의 제 1 실시예에 있어서, 다수의 논리 컴퓨터 시스템(plurality of logical computer system)들 내에 소프트웨어 정의 네트워크 연결 저장 시스템(software-defined network attachable storage system)을 설정하는 방법이 제공된다. 각각의 컴퓨터 시스템은 메모리(memory), 프로세서(processor), 및 저장 시스템을 구비한다. 소프트웨어 정의 네트워크 연결 저장 시스템을 설정하는 방법은 제 1 세트(set)의 논리 컴퓨터 시스템들을 네임 스페이스 내에서 동작하는 네임 스페이스 서버들로서 설정하고, 제 2 세트의 논리 컴퓨터 시스템들을 데이터 스페이스 서버들로서 설정하는 한 세트의 프로그램들을 논리 컴퓨터 시스템들 내에서 실행하는 단계를 포함한다. 제 1 세트의 논리 컴퓨터 시스템들은 적어도 두 대의 논리 컴퓨터 시스템들을 포함한다. 각각의 논리 컴퓨터 시스템은 네임 스페이스의 별개의 부분에서 자율적으로 동작하도록 구성된다. 논리 컴퓨터 시스템들의 일부는 가상(virtual) 컴퓨터 시스템들일 수 있다.

이 실시예에 있어서, 각각의 네임 스페이스 서버는 그 메모리 내에서, 파일 및 디렉토리(directory) 이름들과 파일 및 디렉토리 이름들과 결합된 사용자 데이터가 존재하는 위치에 대한 정보를 포함하는, 파일 시스템 메타데이터를 지속적으로 저장하고, 파일 시스템 메타데이터의 동적으로 업데이트(update)된 카피(copy)를 그 저장 시스템 내에 저장하도록 구성된다. 각각의 네임 스페이스 서버는 네임 스페이스의 사전 설정된 서브세트(subset)에 대해서 그 메모리 내에 지속적으로 저장되는 메타데이터에 기초하여 적어도 하나의 요청 클라이언트(client) 컴퓨터로부터의 저장 시스템 경로 이름 요청들을 처리하고, 각각의 요청에 응답하여 요청 클라이언트 컴퓨터의 의해 사용되기 위한 핸들을 반송하도록 또한 구성된다. 모든 네임 스페이스에 대해서는 모든 네임 스페이스 서버들이 저장 시스템 경로 이름 요청들을 집합적으로 처리한다. 각각의 데이터 스페이스 서버는 직접적으로 네임 스페이스 서버들에 의해 결정되고 적어도 하나의 요청 클라이언트 컴퓨터로부터 수신되는 핸들들에 기초하여 그 저장 시스템 내에 사용자 데이터를 저장하고 검색하도록 구성된다.

본 발명의 또 다른 실시예에 있어서, 다수의 논리 컴퓨터 시스템들 내에 소프트웨어 정의 네트워크 연결 저장 시스템을 설정하는 방법이 제공된다. 각각의 컴퓨터 시스템은 메모리, 프로세서, 및 저장 시스템을 구비한다. 소프트웨어 정의 네트워크 연결 저장 시스템을 설정하는 방법은 제 1 세트의 논리 컴퓨터 시스템들을 네임 스페이스 서버들로서 설정하고, 제 2 세트의 논리 컴퓨터 시스템들을 데이터 스페이스 서버들로서 설정하는 한 세트의 프로그램들을 논리 컴퓨터 시스템들 내에서 실행하는 단계를 포함한다. 논리 컴퓨터 시스템들의 일부는 가상 컴퓨터 시스템들일 수 있다.

이 실시예에 있어서, 각각의 네임 스페이스 서버는 그 메모리 내에서, 파일 및 디렉토리 이름들과 파일 및 디렉토리 이름들과 결합된 사용자 데이터가 존재하는 위치에 대한 정보를 포함하는, 파일 시스템 메타데이터를 저장하고, 파일 시스템 메타데이터의 동적으로 업데이트된 카피를 그 저장 시스템 내에 저장하도록 구성된다. 각각의 네임 스페이스 서버는 네임 스페이스의 사전 설정된 서브세트에 대해서 적어도 하나의 요청 클라이언트 컴퓨터로부터의 저장 시스템 경로 이름 요청들을 처리하고, 각각의 요청에 응답하여 요청 클라이언트 컴퓨터의 의해 사용되기 위한 핸들을 반송하도록 또한 구성된다. 각각의 데이터 스페이스 서버는 네임 스페이스 서버들에 의해 결정되는 핸들들에 기초하여 그 저장 시스템 내에 사용자 데이터를 저장하고 검색하도록 구성된다

하나의 관련 실시예에 있어서, 네임 스페이스 서버들의 적어도 하나의 적절한 서브세트는 네임 스페이스의 공유된 서브세트에 대해 클러스터(cluster)로서 동작하고, 저장 시스템 경로 이름 요청들을 처리하도록 구성되며, 네임 스페이스의 공유된 서브세트의 파일 시스템 메타데이터는 클러스터 내의 각각의 네임 스페이스 서버의 메모리 내에 존재한다. 선택적으로, 클러스터 내의 네임 스페이스 서버들의 수는 계획된 부하 조건들 하에서 소정 레벨(level)의 속도, 리던던시(redundancy), 및 이용 가능성을 달성할 수 있도록 선택된다.

또 다른 하나의 관련 실시예에 있어서, 데이터 스페이스 서버들의 적어도 하나의 적절한 서브세트는 데이터 스페이스의 공유된 서브세트에 대해 클러스터로서 동작하고, 네임 스페이스 서버들에 의해 결정되는 핸들들에 기초하여 그 저장 시스템 내에 사용자 데이터를 저장하고 검색하도록 구성된다. 선택적으로, 클러스터 내의 데이터 스페이스 서버들의 수는 계획된 부하 조건들 하에서 소정 레벨의 속도, 리던던시, 및 이용 가능성을 달성할 수 있도록 선택된다.

관련 실시예들에 있어서, 논리 컴퓨터 시스템들의 적어도 일부는 가상 컴퓨터 시스템들이다. 다른 관련 실시예들에 있어서, 논리 컴퓨터 시스템들은 모두 가상 컴퓨터 시스템들이다.

또한 관련 실시예들에 있어서, 제 1 세트의 논리 컴퓨터 시스템들과 제 2 세트의 논리 컴퓨터 시스템들은 따로 떨어져 있다. 대안으로서, 제 1 세트의 논리 컴퓨터 시스템들과 제 2 세트의 논리 컴퓨터 시스템들은 따로 떨어져 있지 않다.

또 다른 하나의 관련 실시예에 있어서, 파일 시스템 메타데이터는, 경로 이름들의 공유된 접두사들이 촘촘히 저장되도록, 파트리시아(Patricia) 트리(tree) 데이터(data) 구조에 따라 구성된다. 선택적으로, 파일 시스템 메타데이터는 (i) 파트리시아 트리를 인코딩(encoding)하는 노드(node) 테이블(table)과, (ii) 파일들 및 디렉토리들의 속성들을 인코딩하는 파일 테이블과, (iii) 노드 테이블 내에서 사용되는 최대 길이보다 큰 길이를 가지는 스트링(string)들의 이름들을 인코딩하는 스트링 테이블 내에 저장된다. 또 다른 하나의 선택 사항으로서, 노드 테이블과 파일 테이블과 스트링 테이블 각각은 지속성을 위해 별개의 파일 내에 동적으로 저장된다. 또 다른 하나의 선택 사항으로서, 노드 테이블, 파일 테이블, 또는 스트링 테이블로의 변경은 인텐트(intent) 로그(log) 내에 저장되고, 상기 인텐트 로그는 그러한 테이블들에 대응하는 파일들을 업데이트하기 위하여 동적으로 사용된다. 단일 동작과 관련된 변경들은 함께 링크(link)될 수 있다. 또한, 노드 테이블과 파일 테이블과 스트링 테이블 각각은 고정된 크기의 엔트리들(entries)을 갖는 별개의 어레이(array)일 수 있다.

또 다른 하나의 관련 실시예에 있어서, 클러스터에 의해 관리되는 네임 스페이스 데이터의 공유된 서브세트에 대한 업데이트들을 처리하는 동안 각각의 연속하는 업데이트에는 시퀀스(sequence) 번호가 제공되고, 클러스터의 논리 컴퓨터 시스템들은 시퀀스 번호에 기초하여 업데이트하는 사전 설정된 순서를 유지하면서 비동기적으로 동작하도록 구성된다.

전술한 실시예들의 특징들은 첨부도면을 참조하는 이하의 상세한 설명을 통해 더욱 명확히 이해될 것이다.
도 1은 본 발명의 일 실시예에 따른 하이퍼 파일러(Hyperfiler)의 블록 선도이다.
도 2는 여러 개의 서브 디렉토리들을 포함하는 경로 이름을 갖는 파일에 액세스하기 위한 종래의 네트워크 연결 저장(NAS) 시스템의 특징을 잘 나타내는 디스크 및 네트워크 입/출력(I/O) 동작들을 예시하는 도면이다.
도 3은 도 2와 동일한 경로 이름을 갖는 파일에 액세스하기 위한 본 발명의 일 실시예에 따른 하이퍼 파일러에 의해 요구되는 디스크 및 네트워크 입/출력 동작들을 예시하는 도면이다.
도 4는 경로 이름이 "x/y/z012345678"인 파일을 생성하기 위한 본 발명의 일 실시예에 따른 하이퍼 파일러 내에서의 동작들을 예시하는 도면이다.

정의. 발명의 상세한 설명 및 청구의 범위에 있어서, 다음의 용어들은 문맥상 달리 요구되지 않는 한 이하에서 설명되는 의미들을 가져야 한다.

"액티브(active) 디렉토리"는 디렉토리의 일 버전으로, 하이퍼 서버(hyperserver) 상에 존재하고, 자신의 이름은 해시(hashed)되며, 파일들 및 서브디렉토리들을 생성하고, 삭제하고, 리스트(list) 작성하고, 액세스하기 위해 사용되는 디렉토리이다. 하이퍼 파일러에서, 각각의 디렉토리는 두 가지 버전들을 가질 수 있다. 하나는 방금 설명한 액티브 디렉토리이고, 다른 하나는 패시브(passive) 디렉토리이다. 패시브 디렉토리는 해시된 부모 디렉토리를 가지며, 그 부모의 리스트 작성 및 순회(traversal)에서 올바르게 보고되도록 제공된다. 때때로, 액티브 디렉토리 및 패시브 디렉토리는 동일한 하이퍼 서버에 해시될 수 있으며, 따라서 단일 디렉토리로 통합될 수 있다.

"백킹 스토어(backing store)"는 노드 테이블, 스트링 테이블, 및 파일 테이블의 내용을 복제하는 세 개의 파일들의 집합이다.

"카디날리티(cardinality)"는 하이퍼 서버 내에서 구성되는 하이퍼 서버 멤버들의 카운트를 지시하는 숫자이다. 하이퍼 파일러 내의 각각의 하이퍼 서버는 실행을 위해 선택하는 리던던시(redundancy)의 레벨에 따라 1 내지 4의 범위에서 다른 카디날리티를 가질 수 있다.

하이퍼 파일러 "클라이언트"는 하이퍼 파일러의 파일 시스템 네임 스페이스 내에서의 디렉토리의 마운트(mount)를 수행하는 컴퓨터이다. 하이퍼 파일러 클라이언트는 퓨즈(FUSE) 클라이언트 컴포넌트(component)를 실행하여 이용 가능한 다양한 서비스들을 요청하는 리모트 프로시저 콜들(RPCs, Remote Procedure Calls)을 통해 저장 서비스들에 원격으로 접속한다. 마운트 동작은 클라이언트가 하이퍼 파일러와 대화(interact)하기를 원하는 모든 데이터 구조들을 로드(load)하며, 이들 데이터 구조들이 변경될 경우 하이퍼 파일러는 이들 데이터 구조들을 업데이트한다. "클라이언트 컴퓨터"라는 용어는 자신의 클라이언트로서 동작하고 있는 서버를 포함한다.

"데이터 스페이스"는 사용자 파일 데이터가 저장되는 저장 자원들을 관리하는 하이퍼 파일러의 일 부분이다. 전체 데이터 스페이스는 하이퍼 파일러 내의 모든 데이터-케이퍼블 하이퍼 서버들을 통해 분할된다. 데이터-케이퍼블 하이퍼 서버들 각각은 지정된 레벨의 카디날리티를 제공할 수 있도록 구성된다. 이에 의해 가장 높은 카디날리티를 가지고 하이퍼 볼륨들을 관리하는 하이퍼 서버들 내에 바이탈 데이터를 저장할 수 있다. 반면에, 일시적인 데이터는 1로 설정된 카디날리티를 가지고 하이퍼 볼륨 상에 저장될 수 있어서 저장 비용을 최적화할 수 있다. 파일들 및 심볼 링크들은 논리적으로 연속적인 익스텐트들(Extents)의 집합체로서 저장된다.

"디렉토리 해시 테이블(DHT)"은 경로 이름에 기반하는 모든 동작들을 수행하기 위해 사용되는 테이블이다. 모든 하이퍼 파일러 멤버들 및 클라이언트들에 알려져 있는 해시 기능은 디렉토리 해시 테이블(DHT) 내의 슬롯 내로 관심의 대상이 되는 파일 시스템 오브젝트의 부모 디렉토리의 이름에 대한 다수 대 일의 맵핑(mapping)을 수행한다. 타겟(target) 슬롯(slot)은 그 오브젝트(object)에 대해서 동작들을 수행하기 위해 사용될 하이퍼 서버의 하이퍼 서버 (HID)를 포함한다. 효과적으로, 이 테이블에 의해 전체 글로벌(global) 네임 스페이스가 하이퍼 파일러 내의 모든 하이퍼 서버들에 걸쳐 분할될 수 있다. 디렉토리 해시 테이블(DHT)은 단조롭게 증가하는 생성 번호에 의해 보호된다. 하나의 디렉토리 해시 테이블(DHT) 슬롯의 내용이 변경될 때마다 또는 디렉토리 해시 테이블(DHT)의 크기가 변경될 때마다, 생성 번호가 증가한다. 경로 이름에 기반하는 원격 프로시저 콜들은 항상 디렉토리 해시 테이블(DHT) 생성 번호를 가짐으로써 타겟 하이퍼 서버는 클라이언트에 의해 사용되는 효력이 없어진 디렉토리 해시 테이블(DHT)을 검출하고 업데이트할 수 있다.

"익스텐트(Extent)"는 사용자 데이터를 저장하는 하이퍼 볼륨의 논리적으로 연속하는 부분이다. 하이퍼 파일러 내의 어떠한 익스텐트라도 전면적으로 유니크한 익스텐트 (Extent ID)를 통해 식별된다. 익스텐트는 최대 4 메가바이트의 길이를 가질 수 있다. 이는 길이가 4 메가바이트 이하인 파일들에 액세스하기 위해서는 단지 단일 디스크 입/출력 동작만이 요구된다는 것을 암시한다.

"익스텐트 (EID)"는 하이퍼 파일러 전체에 걸쳐서 익스텐트를 유니크하게 식별하는 8 비트 숫자이다. 익스텐트 (EID)는 자신을 소유하는 하이퍼 볼륨/하이퍼 서버의 하이퍼 서버 (HID)를, 하이퍼 볼륨이 관리하는 데이터 저장소 내의 어느 곳에 익스텐트가 위치하는지에 대한 정보와 함께, 임베드(imbed)하며, 익스텐트의 길이를 또한 임베드한다. 특히, 익스텐트 (EID)는 다음의 필드들을 포함하며, 그것을 포함하는 하이퍼 볼륨 밖의 불명료한 스칼라로서 취급된다. (i) 익스텐트가 할당된 하이퍼 볼륨의 하이퍼 서버 (HID). 이것은 익스텐트를 전반적으로 유니크하게 만들며 전체 하이퍼 파일러 내에서 어드레스 가능하게 만든다. (ii) 포함하는 하이퍼 볼륨 내에서의 익스텐트의 스타팅 블록의 논리적인 블록 오프셋. 이것은 하이퍼 볼륨 내의 스타팅 블록의 논리적인 블록 인덱스를 직접적으로 식별한다. (iii) 익스텐트가 스팬(span)하는 논리적인 블록의 카운트. 이것은 캐시 매니저가 익스텐트 내에서 읽혀질 캐시 내에 얼마나 많은 메모리가 이용 가능한지를 알게 해 준다.

"파일 테이블(FT)"은 각각의 하이퍼 서버 상에서 로컬 네임 스페이스가 구현되는 세 개의 연속하는 어레이들 중의 하나이다. (나머지 두 개는 스트링 테이블(ST) 및 노드 테이블(NT)이다.) 이 어레이는 각각의 파일의 첫번째 익스텐트의 익스텐트 와 함께 파일 또는 디렉토리의 속성들을 저장한다. 익스텐트 ID는 전체 하이퍼 파일러에 걸쳐서 전면적(global)이기 때문에, 데이터가 그 네임 스페이스 컴포넌트가 존재하는 동일한 하이퍼 서버 내에 존재할 필요가 없다.

본 명세서에서 사용되는 "하이퍼 파일러(Hyperfiler)"라는 용어는 본 출원의 양수인인 픽시 인코퍼레이티드(Peaxy, Inc.)에서 개발한 소프트웨어로, 종래의 컴퓨터 하드웨어 환경에서 실행되며, 본 명세서에서는 "하이퍼 서버들"로 불리는 하나 이상의 이용 가능성이 매우 높은 미니 클러스터를 단일 네임 스페이스 내의 파일 저장을 위한 스케일러블(scalable) 퍼실리티(facility)를 제공하기 위해 동적으로 확장될 수 있는 분산 파일 시스템의 컴포넌트들로서 설정한다. 더욱 일반적으로는, 하이퍼 파일러(HYPERFILER)는 본 출원의 양수인인 픽시 인코퍼레이티드(Peaxy, Inc.)의 폭넓은 범위의 하드웨어 환경에서 고성능의 스케일러블 파일 서버들을 구현하는 소프트웨어에 대한 상표이다. 그러나, 본 명세서에서 사용되는 "하이퍼 파일러(Hyperfiler)"라는 용어는 앞의 문장에서 상술한 특정의 의미를 갖는다.

"하이퍼 서버(hyperserver)"는 하이퍼 파일러 내에서 네임 스페이스 또는 데이터 스페이스의 일부 또는 네임 스페이스 및 데이터 스페이스의 일부에 대해 협력적으로 프로세스를 수행할 수 있도록 구성된 논리적인 컴퓨터들의 집단이다. (다양한 실시예들에 있어서, 논리적인 컴퓨터들은 가상 머신들로서 구현된다.) 따라서, 하이퍼 파일러 앱스트랙션은 네임 스페이스 및/또는 데이터 스페이스의 일부에 대해 모두 협력하여 동작하는 사전 설정된 수의 가상 머신들을 하이퍼 서버로서 그룹화한다. 하이퍼 서버의 카디날리티는, 하이퍼 서버의 각각의 논리적인 컴퓨터(예를 들어, 각각의 가상 머신)가 여분을 가지고 파일 시스템을 관리하여 여분의 하이퍼 볼륨을 구현한다는 점에서, 그 리던던시를 정의한다. 개개의 가상 머신 멤버들이 충돌, 연결성의 손실, 및 손실 멤버들의 교체로 인하여 하이퍼 서버에 가입하거나 탈퇴할 수 있기 때문에, 하이퍼 서버는 시간에 따라 변할 수 있는 성질을 갖는다. 클라이언트는 하이퍼 서버들과 대화하여 요청들이 수행되도록 하며, 하이퍼 서버의 멤버쉽을 알 필요는 없다. 따라서, 클라이언트들은 언제든 하이퍼 서버의 멤버들인 가상 머신들의 아이피 (IP) 어드레스들로부터 추출한 하이퍼 서버 ID들을 통해 하이퍼 서버들에 어드레스 한다.

"하이퍼 서버 아이디(HID)"는 하이퍼 파일러 내의 하나의 특정한 하이퍼 서버를 식별하는 16 비트 ID이다. 이에 의해 클라이언트는 요청한 타겟을 식별하게 된다.

"하이퍼 서버 멤버(HM)"는 하이퍼 서버로서 협력적으로 프로세스를 수행할 수 있도록 구성된 논리적인 컴퓨터 집단 내의 하나의 논리적인 컴퓨터이다. 다양한 실시예에 있어서, 논리적인 컴퓨터들은 가상 머신들로서 구현되며, 각각의 하이퍼 서버 멤버(HM)는 하나의 가상 머신이다.

"하이퍼 서버 테이블(HT)"은 하이퍼 파일러 및 그 클라이언트들에 알려진 글로벌 테이블로서, 하이퍼 서버의 카디날리티의 관점에서 하이퍼 파일러 내의 각각의 하이퍼 서버의 멤버쉽(membership)을 설명한다. 반면에, 하이퍼 서버는 하이퍼 서버 사용 멤버들인 가상 머신들의 아이피(IP) 어드레스들의 관점에서 네임 스페이스 만을, 데이터 스페이스만을, 또는 네임 스페이스 및 데이터 스페이스 양자를 서비스한다. 하이퍼 서버 테이블(HT)의 각각의 엔트리는, 그것이 설명하는 하이퍼 서버의 멤버쉽이 변경될 때마다 단조롭게 증가하는 생성 번호에 의해 개별적으로 보호된다. 이 숫자는 주어진 하이퍼 서버를 타겟으로 하는 모든 원격 프로시저 콜들(RPCs) 내에서 전송되며, 이에 의해 주어진 하이퍼 서버는 가능한 불일치를 검출하고 필요하다면 효력이 없어진 하이퍼 서버 테이블(HT) 엔트리를 업데이트할 수 있다.

"하이퍼 볼륨"은 하이퍼 서버에 의해 관리되는 네임 스페이스 및 데이터 스페이스 컴포넌트들의 집합체이다. 이것은 하이퍼 볼륨을 소유하고 관리하는 하이퍼 서버와 공유되는, 하이퍼 서버 ID를 통해 식별된다.

"인텐트 로그"는 백킹 스토어에 대한 한 세트의 업데이트들의 저장소이다. 백킹 스토어에 대한 한 세트의 업데이트들이 필요할 때마다, 이들은, 각각이 관련된 테이블의 표시와 함께, 인텐트 로그에 카피된다.

"논리적인" 컴퓨터 시스템은 실제 컴퓨터 시스템일 수 있고 가상 컴퓨터 시스템일 수 있다. 논리적인 컴퓨터 시스템이 가상 컴퓨터 시스템인 경우, 가상 컴퓨터 시스템은 실제 컴퓨터 시스템 내의 가상화 소프트웨어를 실행함으로써 설정된다.

"메모리"라는 용어는 임의 접근 메모리(램, RAM) 및 보조 메모리를 의미하며, 또한 그와 함께 램 및 보조 메모리를 확장하기 위하여 사용되는 페이징 등의 장치를 의미한다.

하이퍼 파일러 내에서의 "마운트" 동작은 클라이언트가 하이퍼 파일러에게 알려지게 만들며, 클라이언트가 하이퍼 파일러와 대화하도록 하는 데 있어서 필요한 모든 데이터 구조들을 검색하며, 로컬 마운트 포인트 밑의 타겟 하이퍼 파일러 디렉토리 아래에서 파일 시스템 트리가 이용 가능하게 되도록 만든다. 마운트 동작을 수행한 후에, 마운트 포인트 아래의 파일들 및 디렉토리들로의 모든 접근은 하이퍼 파일러로의 원격 프로시져 콜 요청으로 전환된다. 그러나, 이들은 여전히 로컬 파일 시스템을 향하는 것으로 보인다. 마운트 동작은 클라이언트가 네트워크 파일 시스템 (NFS) 서버 상에서 디렉토리의 마운트를 수행할 때 발생하는 것과 유사한 목적을 달성한다.

"마운트 포인트"는 마운트 동작을 수행할 때 클라이언트에 의해 선택되는 로컬 파일 시스템 내의 디렉토리의 경로 이름이다. 마운트 동작이 성공적으로 수행된 후에, 마운트 포인트 아래에 보이는 모든 파일들은 마운트 동작에서 사용된 파일 시스템의 타겟 디렉토리 내에 저장된 파일들 및 디렉토리들이다.

"네임 스페이스"는 하이퍼 파일러에 의해 구현되는 계층 파일/디렉토리 구조를 관리하는 하이퍼 파일러의 일 부분이다. 전체 네임 스페이스는 하이퍼 파일러의 멤버들인 하이퍼 서버들에 걸쳐 분할된다. 파일 시스템 계층과 함께, 네임 스페이스 컴포넌트는, 오너쉽 정보, 접속 승인, 생성 및 변경 날짜들 등의 파일들, 디렉토리들, 및 심볼 링크들의 기본적인 속성들을, 파일 및 심볼 링크의 제 1 익스텐트의 익스텐트 아이디(EID)와 함께, 또한 저장한다.

"노드 테이블(NT)"은, 스트링의 크기가 노드 테이블(NT) 엔트리 내의 이용 가능한 저장 범위를 초과할 때 스트링 테이블 내의 스트링 또는 스트링의 ID와 함께 각각의 노드의 잠금(lock)을 저장하고, 파트리시아 트리(Patricia Tree) 내의 연결된 노드 테이블(NT) 엔트리들의 인덱스들과, 필요하다면 통합된 파일 테이블(FT) 엔트리의 인덱스를 저장하는 데이터 구조이다. 노드 테이블(NT)의 두 개의 엔트리들은 특별하다. 엔트리 0은 이용 가능한 모든 네임 스페이스의 루트에 대한 포인터로서 동작한다. 이러한 레벨의 인디렉션(indirection)은 미래에 네임 스페이스 또는 다수의 네임 스페이스들의 스냅(snap) 사진 촬영을 구현할 수 있다. 노드 테이블(NT)의 엔트리 1은 이식 가능 운영 체제 인터페이스 (portable operating system interface)(포직스, POSIX) 네임 스페이스의 루트 디렉토리이며, "I"에 대응한다.

"정책(policy)"은 파일들의 생성 또는 저장 티어(Tier)들로의 데이터 컴포넌트들의 할당 및, 간접적으로는, 그러한 티어들을 구현하는 데이터 스페이스 하이퍼 파일러들로의 데이터 컴포넌트들의 할당을 필요로 하는 프로세싱에 있어서 적용되는 한 세트의 규칙들이다. 정책은 주어진 티어 내에 저장되기 위해 파일이 가져야 하는 특성들 (접미사, 부모 디렉토리 이름, 소유자, ...)를 결정할 수 있다. 정책은 워크플로우들(Workflows), 예를 들어 거의 사용되지 않게 되거나 과도한 접속이 막 일어나려고 할 때 하나의 티어에서 또 다른 하나의 티어로 파일을 이동시키기 위해 필요한 것들을 통해 수행되어야 할 시간 기반 또는 이벤트(event) 기반 동작들을 또한 특정할 수 있다.

"프라이머리(primary) 멤버"는 주어진 시간에 자신이 관리하는 하이퍼 볼륨의 상태에 대한 정당한 실체이며 따라서 하이퍼 서버 내에서 주요 역할을 수행하는 하이퍼 서버 멤버이다. 하이퍼 서버 내에서, 하나의 특정 멤버는 단번에 주요 역할을 수행한다. 모든 다른 멤버들은 세컨더리(secondary) 멤버들이다. 세컨더리 멤버 같은 프라이머리 멤버는 (읽기 동작들과 같은) 기본적인 하이퍼 볼륨의 상태를 변경하지 않는 요청들을 서비스하지만 또한 상태 변경 요청들을 수행하고 세컨더리 멤버들에 대한 동작들을 조정하는 하나의 멤버이다. 이러한 구성 하에서는, 요청이 완료될 때까지, 하이퍼 서버의 모든 멤버들은 각각의 개별적인 요청에 대해 동일한 상태에 이르게 된다. 프라이머리 멤버는 연결성의 손실 또는 기타 비정상적인 거동으로 인하여 충돌하거나 하이퍼 서버로부터 퇴거될 때까지 주요 역할을 계속해서 수행한다.

"원격 프로시저 콜(RPC)"은 네트워크 프로토콜인데, 이 네트워크 프로토콜에 의해 라이언트가 하이퍼 파일러에 서비스를 요청하게 된다. 원격 프로시저 콜(RPC)은 구현되어야 할 필요가 있는 기능성에 맞추어지며, 파일 시스템 레벨에서 동기된다. 프로토콜의 기본이 되는 레이어들은 원격 프로시저 콜(RPC)의 타겟인 하이퍼 서버에 고유한 평행 관계의 장점을 취하며, 필요한 경우 이를 이용하여 개개의 하이퍼 서버 멤버들과 비동기적으로 통신을 한다. 이러한 양상은 스택의 상위 레이어들로부터 감추어져 있어서 콜들의 의미를 단순화한다.

"패시브 디렉토리"는 디렉토리의 일 버전으로, 하이퍼 서버(hyperserver) 상에 존재하고, 자신의 부모 디렉토리는 해시되며, 그 부모의 리스트 작성 및 순회에서 올바르게 보고되도록 제공된다. 하이퍼 파일러 내에서, 각각의 디렉토리는 두 가지 버전들을 가질 수 있다. 하나는 방금 설명한 패시브 디렉토리이고, 다른 하나는 액티브 디렉토리이다. 액티브 디렉토리는 디렉토리의 일 버전으로, 하이퍼 서버(hyperserver) 상에 존재하고, 자신의 이름은 해시(hashed)되며, 파일들 및 서브디렉토리들을 생성하고, 삭제하고, 리스트 작성하고, 액세스하기 위해 사용되는 디렉토리이다. 때때로, 액티브 디렉토리 및 패시브 디렉토리는 동일한 하이퍼 서버에 해시될 수 있으며, 따라서 단일 디렉토리로 통합될 수 있다.

하이퍼 서버의 "세컨더리 멤버"는 하이퍼 서버에 의해 관리되는 기본적인 하이퍼 볼륨의 상태를 변경하지 않는 클라이언트 요청들을 수행할 수 있는 하이퍼 서버 멤버이다. 파일에 쓰기를 하거나 파일 생성 또는 삭제 등과 같이 하이퍼 서버에 의해 관리되는 하이퍼 볼륨의 상태가 변경되여야 할 때, 하이퍼 서버의 프라이머리 멤버는 세컨더리 멤버들과 함께 그러한 동작들을 내고 조정하며, 세컨더리 멤버들은 슬레이브들로서 그러한 요청들을 수행한다. 하이퍼 볼륨의 프라이머리 멤버가 하이퍼 볼륨에서 탈퇴하는 경우, 하나의 세컨더리 멤버가 승격되어 주요 역할을 커버한다.

"서버 아이디(SID)"는 하이퍼 서버 내의 하이퍼 서버 멤버(HM)에 할당되는 숫자이다. 각각의 멤버는, 하이퍼 서버에 가입하고 하이퍼 서버를 탈퇴할 때까지 가입 상태를 유지하는 경우 또는 충돌이 발생하는 경우, 서버 아이디(SID)를 수신한다. 새로운 하이퍼 서버 멤버(HM)는 그 시점에서 사용되지 않은 서버 아이디(SID)를 수신한다. (퇴거되거나 충돌된 하이퍼 서버 멤버(HM)가 이전에 사용했던 서버 ID(SID)일 수 있다.) 종래에 있어서는, 하이퍼 서버 멤버(HM)의 가장 낮은 서버 아이디(SID)는 0이고, 각각의 연속하는 서버 아이디(SID)는 1, 2, ...이다. 따라서, 서버 아이디(SID)는 하이퍼 서버의 카디날리티보다 항상 작은 숫자이다.

"세트"는 적어도 하나의 멤버를 포함한다.

"저장 티어"는 관리되는 하이퍼 볼륨들을 구현하기 위하여 사용되는 저장 장치들의 능력과 성능 및 카디날리티의 유사성에 기초하는 하이퍼 파일러 내의 데이터 스페이스 하이퍼 서버들의 하이-레벨 그룹핑이다. 개개의 데이터 스페이스 하이퍼 서버들은 저장 티어에 할당되며, 티어의 속성들을 물려받는다.

"스트링 테이블(ST)"은 한데 모여 연속하는 청크를 구성할 수 있는 길이가 고정된 셀들로 이루어진 어레이이며, 노드 테이블 내에 제공되지 않은 스트링들을 저장하기 위해 사용된다.

주어진 세트의 "서브세트"는 선택적으로 주어진 세트 전체를 포함할 수 있다.

주어진 세트의 "적합한 서브세트"는 주어진 세트 전체를 포함하지 않는다.

"가상 컴퓨터 시스템"(때때로 "가상 머신"으로 불린다)은 프로세서, 메모리, 및 저장 장치를 포함하는 속성들이 기본적인 실제 하드웨어 환경과 사실상 별개로 구현되는 가상 머신이다.

"워크플로우(Workflow)"는 실시예들에 따른 저장 시스템에 의해 조정되는 한 세트의 동작들로서, 특정된 정책들을 수행하거나, 하이퍼 파일러의 소프트웨어 업그레이드, 새로운 가상 머신들의 추가를 통한 하이퍼 파일러의 확장 등과 같은 요청된 동작들을 수행하는 동작들이다.

하이퍼 파일러(HYPERFILER)는 본 출원의 양수인인 픽시 인코퍼레이티드(Peaxy, Inc.)의 폭넓은 범위의 하드웨어 환경에서 고성능의 스케일러블 파일 서버들을 구현하는 소프트웨어에 대한 상표이다. 명세서에서 사용되는 "하이퍼 파일러(Hyperfiler)"라는 용어는 픽시 인코퍼레이티드(Peaxy, Inc.)에서 개발한 소프트웨어의 특별한 하나의 예로서, 종래의 컴퓨터 하드웨어 환경에서 실행되며, 본 명세서에서는 "하이퍼 서버들"로 불리는 하나 이상의 이용 가능성이 매우 높은 미니 클러스터를 단일 네임 스페이스 내의 파일 저장을 위한 스케일러블 퍼실리티를 제공하기 위해 동적으로 확장될 수 있는 분산 파일 시스템의 컴포넌트들로서 설정한다.

실시예들에 있어서, 하이퍼 파일러와 그의 컴포넌트 하이퍼 서버들은 파일들로의 포직스(POSIX) 액세스를 제공하지만 데이터베이스 타입 워크로드를 지원하는 것을 의미하지는 않는다.

일 실시예에 있어서, 하이퍼 파일러들은 리눅스(Linux) 머신들을 클라이언트들로서 지원한다. 다른 실시예들은 미합중국 워싱톤 레드몬드에 소재하는 마이크로소프트(Microsoft)사에 의해 제공되는 윈도우즈 운영 체제와 같은 기타 운영 체제들의 클라이언트들을 지원하기 위하여 설정될 수 있다.

본 명세서에서 상세하게 설명되는 하이퍼 파일러의 일 실시예 내에서 사용되는 파일 저장 액세스 프로토콜은 간소화되며 사용자 데이터그램 프로토콜(UDP)에 기초한다. 기본 파일 서비스를 이용하는 클라이언트들은 하이퍼 파일러를 인터페이스 하는 동적으로 로딩 가능한 리눅스 모듈을 배치할 필요가 있다. 이 클라이언트는 간섭이 최소화되며 로컬 호스트 자원을 극히 제한된 상태로 사용하는 매우 가벼운 클라이언트이다.

포직스(POSIX) 파일 시스템 인터페이스 외에, 파일들에 액세스하기 위한 스케일러블 HTTP/HTTPS 인터페이스가 이 실시예에 있어서 또한 제공된다.

이하, 주요 서브 컴포넌트들에 대해 상세히 설명함으로써 구조에 대한 설명을 제공한다. 구조의 설명은 이하의 주요 섹션들에서 제공된다.

I. 하이퍼 파일러의 물리적인 기초

II. 주요 하이퍼 파일러 앱스트랙션

III. 동작 거동

I. 하이퍼 파일러의 물리적인 기초

본 발명의 다양한 실시예들에 있어서, 하이퍼 파일러는 클라이언트 컴퓨터로부터의 저장 요청들에 응답하도록 구성된 하나 이상의 하이퍼 서버들에 의해 구현된다. 각각의 하이퍼 서버는 하이퍼 서버 멤버들(HMs)로서 동작하는 하나 이상의 논리적인 컴퓨터 집단으로서 구현된다. 또한, 본 발명의 실시예들에 있어서, 하나의 하이퍼 서버 멤버로서 동작하는 각각의 논리적인 컴퓨터는 중앙 처리 장치(CPU), 램, 및 네트워크 자원들이 KVM, VMware, Xen 등의 하이퍼 바이저들에 의해 가상화되는 물리적인 컴퓨터 상에서 실행되는 가상 머신(VM)으로서 구현된다.

시스템 매니지먼트 컴포넌트는 하이퍼 서버 멤버들(HMs)을 모아서 가능성이 높은 서버 앱스트랙션을 구현하는 하이퍼 서버들을 구성한다. 또한, 시스템 매니지먼트 소프트웨어는 하이퍼 서버들을 모아서 하이퍼 파일러로서 알려진 소프트웨어 앱스트랙션을 구성한다.

하이퍼 파일러의 클라이언트들은 하이퍼 파일러 시스템이 마운트되는 것을 허용하고 종래의 포직스(POSIX) 프로그래밍 응용 프로그래밍 인터페이스(Application Programming Interfaces)(APIs)를 통해 액세스되는 것을 허용하는 소프트웨어 컴포넌트를 실행한다. ("마운트" 동작은 네트워크 파일 시스템 (NFS) 파일러로의 액세스를 획득하기 위해 수행된 것과 유사하다.)

각각의 하이퍼 서버 멤버(HM)는 하드웨어로서 이용 가능하거나 (존재한다면) 기본이 되는 하이퍼 바이저에 의해 가상화되는 이용 가능한 저장 장치, 중앙 처리 장치(CPU), 램, 및 네트워크 자원들을 구비한다.

저장 장치

분산 파일 저장 장치를 지원하기 위하여, 각각의 하이퍼 서버 멤버(HM)는 블록 저장 장치를 이용 가능하게 만든다. 이는 다른 방식들로 구현될 수 있다.

하이퍼 서버 멤버들(HMs)은 스토리지 에어리어 네트워크(SAN) 인프라스트럭처를 통해 논리 단위 번호들(LUNs)을 이용 가능하게 만든다. 그러나, 엄밀히 말하면, 이것은 스토리지 에어리어 네트워크(SAN)를 필요로 하지 않는다. 실제 스토리지 에어리어 네트워크들(SANs) 이외에, 가상 스토리지 에어리어 네트워크(VSAN) 제품을 통한 가상 머신 웨어(VMware)에 의해 또는 코레이드(Coraid), 님블(Nimble), 틴트리(Tintri) 등의 회사에 의해 제공되는 저장 퍼실리티 등의 가상 머신들(VMs)을 위한 저장 장치를 제공하는 스토리지 에어리어 네트워크(SAN)와 유사한 퍼실리티를 지원하기 위한 다수의 대안들이 존재한다. 채용되는 특정 저장 퍼실리티와 관계없이, 하이퍼 서버 멤버(HM) 레벨에서의 저장 장치는 스토리지 에어리어 네트워크(SAN)에 의해 이용 가능하게 된 논리 단위 번호(LUN)와 유사해 보인다. 그러한 논리 단위 번호들(LUNs)이 몇몇 형태의 리던던시를 구현하는 경우, 이러한 유형의 저장 장치는 이용 가능성이 높은 속성들을 제공할 수 있다. 그러나, 기본적인 논리 단위 번호들(LUNs)은 여분을 가지며 저장 레벨에서 높은 이용 가능성(HA)을 지원할 수 있는 반면, 이들 논리 단위 번호들(LUNs)을 관리하고 파일들 및 디렉토리들의 형태로 저장 내용을 보여주는 서버 소프트웨어가 여분의 하이퍼 서버 멤버들(HMs) 상에서 실행되지 않는 한, 하이퍼 서버 멤버(HM)의 충돌은 하이퍼 서버 멤버(HM)가 관리하는 논리 단위 번호들(LUNs) 내에 저장된 데이터로의 액세스를 위태롭게 한다. 따라서, 리던던시 및 기본적인 저장 장치의 높은 이용 가능성(HA) 속성들과 관계 없이, 하이퍼 파일러는 하이퍼 서버 멤버들(HMs) 내의 리던던시가 지원되는 방식으로 구축되어야 한다.

다른 한 가지 방법은 산업 표준 컴퓨터 내에서 실행되는 하이퍼 서버 멤버(들)(HM(s))에 물리적 저장 장치를 결합시키고 컴퓨터 내의 디스크 드라이브들을 하이퍼 서버 멤버들(HMs) 용 저장 장치로서 사용하는 것이다. 이 경우, 컴퓨터 내의 드라이브들 각각을 하이퍼 서버 멤버들(HMs)이 관리할 수 있다. 앞서의 방법과의 차이는, 이 경우에, 하이퍼 파일러 소프트웨어가 하이퍼 서버 멤버들(HMs) 및 기본이 되는 저장 장치에서 리던던시를 지원하기 위해 준비되어야 한다는 점이다.

상기한 두 가지 방법들은 실제적인 결과에서 매우 다르다. 전형적인 실시예들에 있어서, 물리적인 디스크 드라이브들이 동작하는 머신 내의 물리적인 디스크 드라이브들을 하이퍼 서버 멤버들(HMs)이 직접 관리할 때 다수의 하이퍼 서버 멤버들(HMs)에 걸쳐 저장 복제 전략이 구현된다. 명백히, 리던던시 및 높은 이용 가능성(HA)이 스토리지 에어리어 네트워크들(SANs) 또는 저장 자원들을 지원하는 스토리지 에어리어 네트워크(SAN)와 유사한 퍼실리티에 의해 제공될 때 이것은 필요하지 않다. 필요한 경우, 고객이 원하는 복제의 정도를 선택함으로써 복제를 구성할 수 있다 (이하 참조). 복제는 미러링으로서 구현되며, 액티브 데이터를 포함하는 저장 장치의 일부로 제한된다. 이것은 미러들에 걸친 재동기화의 속도를 향상시키고 재동기화가 진행됨에 따라 성능을 크게 향상시킨다.

하이퍼 서버 멤버들(HMs)는 주로 제한없는 스토리지 복제를 지원하며(storage-agnostic), SSDs를 포함하여 모든 형태의 물리적인 데이터를 지원할 수 있다.

전형적으로, 하이퍼 서버 내의 개개의 하이퍼 서버 멤버(HM)는 한 쌍의 분리된 저장 파티션들을 관리한다. 하나는 네임 스페이스에 할당되고, 다른 하나는 데이터 스페이스에 할당된다. 이는 이하에서 더욱 상세히 설명된다. 그러나, 기본 개념들 중의 하나는 네임 스페이스와 데이터 스페이스를 특정 배치를 위해 고객이 요청하는 성능을 최대로 달성할 수 있는 물리적인 매체 상에 배치할 수 있다는 것이다. 이 전략은 (본 발명의 실시예들이 적용 가능한 경우에서처럼) 액세스되는 파일의 세트가 매우 랜덤할 때마다 효과적이지 않기 때문에, 이것은 순수하게 캐싱에 고속 장치들을 할당하는 것보다 양호하다.

중앙 처리 장치(CPU) 및 메모리

하이퍼 서버 멤버들(HMs)는 멀티-코어 중앙 처리 장치들(CPUs)을 사용하는 시스템들 상에서 실행되는 것으로 예상된다. 하이퍼 파일러 설계에서 이루어지는 선택들 중 많은 선택들은 필요에 따라 입/출력 대역폭의 프로세싱을 트레이드 오프함으로써 멀티-코어 구조의 프로세싱 파워를 이용한다.

메모리에 경우에는, 하이퍼 파일러는 서비스하고자 하는 시장 세그먼트들의 제약 내에서 여러 다른 타입의 로드들을 지원하도록 설계된다. 따라서, 각각의 하이퍼 서버 멤버(HM)가 사용하도록 허용되는 램의 양은 원하는 성능과 각각의 배치를 위한 비용 목표의 함수이다. 그러나, 일반적으로 각각의 하이퍼 서버 멤버(HM)는 1 내지 4 기가바이트의 램을 이용 가능하게 하여야 하는 것으로 예상된다.

네트워크

하이퍼 파일러들은 이더넷 상의 IP 이외의 다른 특정 타입의 네트워크 연결에 의존하지 않는다. 이것은 비용을 낮추고, 매우 일반적인 기술로의 액세스를 허용하며, 다양한 타입의 네트워크 인프라스트럭처의 관리 필요성을 회피함으로써, 오너쉽의 전체 비용(TCO)를 감소시킨다.

산업 표준 서버들에서 이용 가능한 전형적인 네트워크 인터페이스 카드(NIC)는 직업에 완전히 알맞다. 그러나, 한 가지 중요한 주의 사항이 있다. 동일한 박스 내에서 실행되는 하이퍼 서버 멤버들(HMs)은 중앙 처리 장치(CPU) 코어들 및 네트워크 인터페이스 카드들(NICs)을 공유하며, 따라서 이들이 균형을 이루는 것이 매우 바람직하다. 예를 들어, 그의 역할이 드라이브들의 내용에 대한 액세스가 빈번하지 않은 것으로 생각되는 저장 계층에서 낮은 티어의 역할이 아닌 한, 16 개의 디스크 드라이브들을 호스팅하는 (그리고 추측건대 16 개의 하이퍼 서버 멤버들(HMs)를 실행하는) 컴퓨터는 각각의 하이퍼 서버 멤버들(HMs)의 각각의 쌍에 대해 1 GBit/s 이상의 네트워크 인터페이스 카드(NIC) 포트를 이용 가능하게 하여야 한다.

부가적인 하드웨어 요건들

하이퍼 파일러는, NVRAM 과 같은 것을 이용하지만, 다른 특정 타입의 하드웨어의 존재를 지시하지 않는다.

도 1은 본 발명의 일 실시예에 따른 하이퍼 파일러의 블록 선도이다. 하이퍼 파일러(101)는 하이퍼 파일러(101)와 결합된 네임 스페이스(104)를 처리하기 위한 네임 스페이스 하이퍼 서버들(106, 107, 108)의 집합체 및 동일한 네임 스페이스에 대응하는 데이터 스페이스(105)를 처리하기 위한 데이터 스페이스 하이퍼 서버들(121, 122, 123, 124, 125)의 집합체에 의해 구현된다. 이 예에 있어서, 각각의 네임 스페이스 하이퍼 서버는 두 개의 하이퍼 서버 멤버들(HMs)에 의해 구현되며, 각각의 하이퍼 서버 멤버는 가상 머신(VM)이다. 따라서, 네임 스페이스 하이퍼 서버(106)는 가상 머신(109) 및 가상 머신(110)에 의해 구현되며, 네임 스페이스 하이퍼 서버(107)는 가상 머신(111) 및 가상 머신(112)에 의해 구현된다. 이와 유사하게, 이 예에 있어서, 각각의 데이터 스페이스 하이퍼 서버는 세 개의 하이퍼 서버 멤버들(HMs)에 의해 구현되며, 각각의 하이퍼 서버 멤버는 가상 머신(VM)이다. 따라서, 데이터 스페이스 하이퍼 서버(121)는 가상 머신(126), 가상 머신(127), 및 가상 머신(128)에 의해 구현된다. (다른 하이퍼 파일들(102, 103)은 단일 하이퍼 파일러의 성능이 불충분한 것으로 생각될 때 더 큰 스케일의 저장 장치로의 액세스를 제공하기 위해 추가될 수 있는 것으로 도시되어 있다.)

하이퍼 서버들 내의 가상 머신들은 도면부호 113, 114, 115, 및 116으로 도시한 서버들을 포함하여, 종래의 일련의 서버들에서 실행되는 소프트웨어에 의해 설정된다. 적절한 리던던시를 제공하기 위하여, 주어진 하이퍼 서버 내의 각각의 가상 머신은 다른 물리적인 서버 내에서 구현된다. 따라서, 네임 스페이스 서버(106)의 가상 머신(109) 및 가상 머신(110)은 별개의 물리적인 서버들(113, 114) 내에서 구현된다. 이와 유사하게, 네임 스페이스 서버(107)의 가상 머신(111) 및 가상 머신(112) 또한 별개의 물리적인 서버들(113, 114) 내에서 구현된다. 데이터 스페이스 서버(121)의 경우, 세 개의 가상 머신들(126, 127, 128)이 별개의 물리적인 서버들(113, 114, 115) 내에서 각각 구현된다.

도 1로부터 알 수 있듯이, 물리적인 서버들은 동일할 필요가 없다. 실제로, 예를 들어, 서버들(113, 114, 115)은 티어 1 스토리지를 위해 사용되고, 서버(116)를 포함한 서버들은 티어 2 스토리지를 위해 사용된다. 최종적으로, 이 예에 있어서, 서버들(131, 132)은 클라우드 기반 서버들로서, 데이터 스페이스 하이퍼 서버(125)에 의해 인터넷을 통해 접속되고, 접속 시의 레이턴시가 덜 중요한 것으로 생각되는, 덜 빈번하게 액세스되는 데이터 용으로 사용된다.

II. 주요 하이퍼 파일러 앱스트랙션

이 섹션에서는 주요 앱스트랙션을 설명함으로써, 앞의 내용에 더하여, 시스템 구현 및 기본이 되는 물리적인 장치와 관련된 방식을 설명한다.

하이퍼 볼륨들 및 하이퍼 서버들

하이퍼 볼륨은 물리적인 저장 매체의 상부에 이용 가능성이 높은 복제된 저장 장치를 구축하고 네트워크에 걸쳐 저장 장치에 어드레스 하는 방법을 제공하는 앱스트랙션이다. 본질적으로, 하이퍼 볼륨을 하이퍼 서버의 모든 멤버들에 걸쳐 구현되는 여분의 논리적인 저장 볼륨으로서 생각할 수 있다. (하이퍼 서버들이 단일 멤버를 갖는 특별한 경우, 사용되는 물리적인 저장 장치가 스토리지 에어리어 네트워크(SAN) 및 논리 단위 번호(LUN)의 경우에서와 같이 블록 레벨에서 여분을 갖지 않는 한, 하이퍼 볼륨은 리던던시를 제공하지 않는다.) (이 앱스트랙션은 하이퍼 파일러 내의 저장 장치를 시스템이 제공하는 통합된 상태의 일 부분인 다수의 관리 가능한 부분들로 분할하기 위하여 사용된다.)

각각의 하이퍼 서버는 하이퍼 서버 멤버들(HMs)를 통해 전용 하이퍼 볼륨에 액세스하고 관리한다.

스토리지 에어리어 네트워크(SAN)에서의 논리 단위 번호들(LUNs)의 경우처럼, 여분의 블록 저장 장치의 경우에서도, 비록 불필요하고 추측건대 저장 자원의 낭비를 야기할 수 있더라도, 하이퍼 볼륨은 엑스트라 리던던시를 구축할 수 있다.

하이퍼 볼륨이 다수의 하이퍼 서버 멤버들(HMs)에 걸쳐 물리적인 볼륨의 내용을 복제함으로써 구축될 때, 하이퍼 서버 멤버들(HMs)를 통해 하이퍼 서버는 모든 복제품들이 엄밀하게 진화됨을 보장하여야 한다.

하이퍼 볼륨은 하이퍼 파일러의 별개의 두 컴포넌트들이 존재할 수 있는 저장소이다. 두 컴포넌트들은 다음과 같다.

네임 스페이스 컴포넌트

데이터 스페이스 컴포넌트

두 컴포넌트들 중의 적어도 하나는 하이퍼 볼륨의 일부여야 함에 주목할 필요가 있다. 그러나, 이들 두 컴포넌트들이 항상 존재할 필요는 없으며, 하이퍼 파일러의 동작 및 관리에 있어서 높은 레벨의 유연성을 허용한다.

하이퍼 서버는 하이퍼 볼륨의 액티브 매니저이고, 하이퍼 볼륨은 하이퍼 서버의 전용적인 사용을 위한 잠재적으로 여분을 갖는 저장 자원이기 때문에, 하이퍼 볼륨들과 하이퍼 서버들은 상호 협력한다. 따라서, 하이퍼 볼륨의 상태를 변경하기 위하여 (파일들 또는 디렉토리들을 생성하거나 삭제하기 위하여 또는 파일들에 쓰기를 하기 위하여), 클라이언트는 적절한 요청들을 하이퍼 서버에 보내야 한다.

시스템은 각각의 하이퍼 볼륨/하이퍼 서버에 정수 식별자들(하이퍼 볼륨 아이디 또는 HID)를 할당하며, 그러한 컴포넌트들의 모든 어드레싱은 그러한 식별자들을 통해 수행된다. (동일한 ID는 하이퍼 서버와 그의 하이퍼 볼륨을 식별한다.) 이에 의해 주어진 하이퍼 볼륨/하이퍼 서버의 물리적인 멤버들의 지식으로부터 통신 양상을 분리할 수 있어서, 하이퍼 서버 내의 하나의 하이퍼 서버 멤버(HM)의 손실은 항상 데이터 또는 메타데이터에 액세스하고자 하는 클라이언트들에 항상 명백하다. 더욱이, 오작동 또는 다른 이유들로 인하여 하이퍼 서버 멤버들(HMs)이 교체되는 경우, 전체 하이퍼 서버를 이용 할 수 없게 되는 커다란 손실이 발생하지 않는 한. 서비스를 받는 클라이언트들은 여전히 이것을 전부 의식하지 못한 채로 있게 된다. (이 종류의 이벤트들은 하이퍼 파일러가 제공하는 고도의 리던던시 때문에 발생할 것으로 예상되지 않는다.)

하이퍼 서버 내의 하이퍼 서버 멤버들(HMs)의 수는 하이퍼 서버의 "카다날리티"로 불린다. (이것은 또한 그것이 속하는 하이퍼 서버의 카다날리티 만큼 많은 복제품을 갖는 기본적인 하이퍼 볼륨의 속성이다.)

언제 하이퍼 서버가 최초로 구성되는지가 선택된다. 이는 나중에 변경될 수 있다. 그러나, 카디날리티는 항상 구현을 위해 선택되는 리던던시의 레벨에 따라 1 내지 4의 범위 내에 있는 작은 숫자이다. 각각의 개별적인 하이퍼 서버는 다른 카디날리티를 제공할 수 있도록 구성될 수 있음에 주목할 필요가 있다.

각각의 하이퍼 서버 멤버(HM)에 서버 아이디 (SID)가 할당된다. 종래에는, 할당되는 첫번째 서버 아이디 (SID)가 SID = 0이기 때문에, SID는 하이퍼 서버의 카다날리티보다 항상 작은 숫자이다. 각각의 멤버는, 하이퍼 서버에 가입하고 하이퍼 서버를 탈퇴할 때까지 가입 상태를 유지하는 경우 또는 충돌이 발생하는 경우, 서버 아이디(SID)를 수신한다. 새로운 하이퍼 서버 멤버(HM)는 그 시점에서 사용되지 않은 서버 아이디(SID)를 수신한다. (퇴거되거나 충돌된 하이퍼 서버 멤버(HM)가 이전에 사용했던 서버 아이디(SID)일 수 있다.)

하이퍼 서버 내에서, 하나의 멤버는 항상 프라이머리 멤버로서 선택된다. 이 멤버는, 데이터 또는 메타데이터 내의 상태의 변경을 수반하는 요청들을 중재하기 때문에, 특별한 지위를 갖는다.

어떠한 이유로 인하여 하이퍼 서버의 프라이머리 멤버가 충돌하거나 퇴출되는 경우, 하이퍼 서버의 또다른 멤버가 주요 역할을 이어 받으며, 이용 가능하다면, 새로운 하이퍼 서버 멤버(HM)가 시스템 매니지먼트 소프트웨어에 의해 자동으로 들어오게 되어 손실된 하이퍼 서버 멤버(HM)를 대신하게 된다. 어떤 하이퍼 서버 멤버가 주요 역할을 이어 받을지의 선택은, 그러한 선택은 결정되어 있으며 개개의 멤버들의 정적인 속성들에 기초하기 때문에, 선정 과정을 필요로 하지 않는다. 어떠한 하이퍼 서버 멤버들(HMs)도 주요 역할을 이어 받는 것이 가능하지 않은 경우, 하이퍼 서버는 계속해서 저급 모드에서 동작을 수행한다.

프라이머리 멤버가 되는 세컨더리 하이퍼 서버 멤버(HM)는 계속해서 SID를 유지함에 주목할 필요가 있다.

하나의 하이퍼 서버 멤버(HM)는 오직 이하의 변화들을 수행할 수 있다.

비 멤버에서 프라이머리 멤버 또는 세컨더리 멤버로의 변화

세컨더리 멤버에서 프라이머리 멤버로의 변화

프라이머리 멤버 또는 세컨더리 멤버에서 비 멤버로의 변화. 이 마지막 변화는, 멤버가 충돌하거나 불일치 상태의 검출에 의해 야기되는 멤버의 퇴출에 의해 야기되는 경우, 자동적으로 발생한다.

퇴출되거나 충돌이 일어나지 않는 한, 어떤 일이 있어도 프라이머리 멤버는 자신의 역할을 포기함으로써 세컨더리 멤버가 될 수 없다는 점에 주목할 필요가 있다.

클라이언트가 하이퍼 파일러에 요청을 전송할 때, 그것은 네임 스페이스 요청 또는 데이터 요청일 수 있다. 네임 스페이스 요청들은 경로 이름을 포함하는 요청들이며, 그 경로 이름을 관리하고 있는 하이퍼 서버에 전송되어야 한다. 경로 이름과 관련 하이퍼 서버 간의 맵핑은 이하에서 설명되는 메커니즘들을 통해 발생한다. 데이터 요청들은, 타겟 하이퍼 서버의 HID를 포함하는 핸들에 기초하여 동작하기 때문에, 스스로 식별 가능하다.

하이퍼 서버 내로 도입되는 요청들은 두 가지 타입이 있다.

읽기 타입 요청들: 이 카테고리 내의 요청들이 수행된 후에, 하이퍼 볼륨 내의 데이터 또는 메타데이터의 상태는 변경된다. 이러한 타입의 요청들은 파일 읽기, 디렉토리 리스트 작성, 파일 메타데이터의 검색 등을 포함한다.

쓰기 타입 요청들: 이 클래스 내의 요청들은 하이퍼 볼륨 내의 데이터 또는 메타데이터의 변경을 야기한다. 이 카테고리 내의 요청들은 파일 쓰기, 파일 생성, 삭제, 및 개명 등이다.

하이퍼 서버의 개개의 멤버는 읽기 타입 요청들을 처리할 수 있다. 하이퍼 서버로 전송된 요청들은 그 멤버들 사이에서 분배되어 로드를 분할한다. 시스템은, 그 멤버가 항상 파일 데이터의 로컬 캐싱을 이용하기 위하여 특정 파일 익스텐트에 속하는 요청들을 처리하는 동일한 멤버임을 보장하여야 한다. 시스템은 클라이언트에 이용 가능한 엘레멘트들, 즉 경로 이름에 기반한 요청들의 경로 이름 및 아이디(ID) 기반 요청들의 아이디(ID)에 기초하여 클라이언트 내에서 알고리듬적으로 읽기 타입 요청들의 분산을 달성한다.

읽기 타입 요청들을 서비스하는 것 이외에, 다른 모든 멤버들이 그러한 것처럼, 프라이머리 멤버 또한 쓰기 타입 요청들의 처리를 조정하는 책임을 갖는다. 프라이머리 멤버는, 그러한 요청들이 완료되었을 때 모든 멤버들이 여전히 동기되어 있어야 함을 보장하여야 하며, 따를 수 없거나 재동기화 될 수 없는 하이퍼 서버의 멤버들을 수리하고 재동기화 하거나 퇴출할 수 있어야 한다. 따라서, 프라이머리 멤버는, 모든 멤버들이 요청의 실행을 성공적으로 완료하였을 때에만, 클라이엔트에 긍정의 애크날리지먼트(acknowledgement)를 보낼 수 있다. 대안으로, 그리고 시스템이 구성되는 방식에 따라, 하이퍼 서버의 대부분의 멤버들이 동작을 수행한 후에 프라이머리 멤버는 애크날리지먼트(acknowledgement)를 보낼 수 있다. 후자의 경우, 트랜잭션을 완료할 수 없는 멤버들은 적절히 라벨 처리될 수 있으며, 딜레이된 상태로 트랜잭션이 완료되거나 멤버가 하이퍼 서버로부터 퇴출된다.

하이퍼 파일러는 다양한 수의 하이퍼 서버들을 한데 모으고 하이퍼 서버들은 동일한 내용을 복제하기 때문에, 효율적인 하이퍼 파일러 동작들은 오직 주어진 하이퍼 서버 내에서의 효율적인 대화(상호 작용)에 좌우된다. 실제로, 쓰기 타입 요청을 (하이퍼 볼륨 상태를 변경함에 따라 조정이 필요한 타입의 경우에만) 조정하기 위해 필요한 통신의 양은 최소이다. 따라서, 요청들이 수행되는 신속성이 전반적인 하이퍼 파일러 크기의 함수가 아니고 단지 본질적으로 작은 하이퍼 서버 크기의 함수이기 때문에, 하이퍼 파일러는 무한히 확장될 수 있다. 따라서, 하이퍼 파일러는 하이퍼 서버들의 연합체로서 행동하며, 성능은 하이퍼 파일러의 크기에 선형적으로 비례한다.

파일 동작들을 위한 ID 기반 요청들은 하이퍼 볼륨 내에 저장되어 있고 하이퍼 서버 아이디(HID)를 포함하는 유니크한 아이디들(IDs)을 통해 식별되는 파일 세크먼트들(익스텐트들) 상에서 동작한다. 따라서, 각각의 그러한 익스텐트 아이디(ID)는 항상 전체 하이퍼 파일러에 걸쳐 전면적으로 유니크하다.

드라이버 또는 노드가 고장나고 결합된 하이퍼 서버 멤버(HM)가 고장나는 경우, 시스템 매니저는 대체 하이퍼 서버 멤버(HM)를, 만일 이용 가능하다면, 가져 온다. 이것은 하이퍼 서버 멤버들과 통신하기 위해 사용되는, 하이퍼 서버 아이디들(HIDs)과 기본이 되는 아이피(IP) 어드레스들 간의 맵핑을 수반한다. 그러면, 하이퍼 볼륨의 잔존하는 멤버들 내에 저장된 데이터가 새로운 멤버로서 하이퍼 볼륨에 가입한 새로운 하이퍼 서버 멤버(HM)에 (데이터 자체가 본질적인 저장 리던던시를 제공하는 스토리지 에어리어 네트워크(SAN) 또는 스토리지 에어리어 네트워크(SAN)와 유사한 퍼실리티에 의존하지 않는 한) 복제된다. 일단 새로운 멤버가 하이퍼 서버의 나머지 멤버들과 동기화 되면, 이 새로운 멤버는, 다른 멤버들과 함께, 도입되는 요청들에 대한 서비스를 시작한다.

동일한 하이퍼 파일러 내에서 다른 하이퍼 서버들로 다른 카디날리티를 할당하는 능력은, 카라날리티가 결합된 하이퍼 볼륨이 제공하는 복제의 정도를 한정하기 때문에, 장점을 갖는다. 어떤 하이퍼 서버 (및 하이퍼 볼륨)가 주어진 파일을 호스트할지를 선택함으로써, 시스템은 파일 데이터에 더 높거나 더 낮은 고유의 리던던시를 할당하는 것을 허용한다. 이에 의해, 고객들은 더 높거나 더 낮은 리던던시가 부여된 파일들을 선택하게 되고, 따라서 고객에 대해 특정 데이터가 갖는 중요도에 기초하여 이용 가능한 최적의 저장 할당을 허용한다. 원하는 레벨의 리던던시로의 할당은 파일이 존재하는 디렉토리 또는 기타의 기준에 따라, 예를 들어 파일의 접미사에 기초하여 수행될 수 있다. 대안으로서, 단순화된 실시예에 있어서, 모든 하이퍼 서버들의 카디날리티는 단일 하이퍼 파일러 범위의 값으로 제한된다.

네트워크 레이어

네트워크 레이어는 하이퍼 파일러 파일 저장 프로토콜을 구현하는 책임이 있다. 이 프로토콜은 TCP 보다는 UDP에 기초한다. 이 네트워크 레이어는 다음과 같은 장점들을 갖는다.

이 네트워크 레이어는 통신을 간소하게 그리고 매우 효율적으로 수행할 수 있도록 한다.

이 네트워크 레이어는 연결 중심 대화에 기초하지 않는다. 이것은, 오버헤드를 줄이고, 엔드-투-엔드 시맨틱스의 구현을 단순화하고, 네트워크 차단을 더욱 양호하게 처리하고, 요청에 응답하는 실체가 요청이 전송된 실체와는 다른 경우들을 더욱 양호하게 처리하기 때문에, 바람직하다. (예를 들어, 이것은 후자가 다른 멤버에 의해 성공적으로 완료될 수 있었을 때 요청을 처리하고 있던 하이퍼 서버 멤버 내의 에러들을 처리하기에 매우 유용하다.)

한편, 이 네트워크 레이어는 원격 프로시져 콜(PRC)이 순수한 트랜스포트의 상부에서 구현되는 것을 요구하며, 메시지의 시퀀싱, 보장된 딜리버리, 비 복제 등등을 올바르게 처리할 것을 또한 요구한다.

하이퍼 파일 시스템의 상위 레이어들은 동기 요청들의 관점에서 하이퍼 서버들과 상대하며, 앞의 서브섹션에서 언급한 바와 같이, 하이퍼 서버 멤버들에 결합된 IP 어드레스들을 알고 있을 필요가 없고 개개의 하이퍼 서버들의 카다날리티를 알고 있을 필요가 없다. 그럼에도 불구하고, 네트워크 퍼실리티의 하위 레이어들은 하이퍼 서버의 모든 멤버들인 특정 IP 어드레스들에 대한 유니캐스트 메시지들의 관점에서 통신을 처리하며, 밑에 있는 비동기 메커니즘들을 사용하여 동기 네트워크 시맨틱스를 구현한다. 이것은 하부 레벨에서의 비동기 및 평행 네트워크 입/출력의 유연성 및 효율성에 의존하면서 분산 파일 시스템 레이어들 내의 로직을 단순화한다.

네트워크 레이어를 적용하는 파일 시스템 레이어는 하이퍼 서버의 어느 멤버에 주어진 메시지가 전송되어야 하는지를 특정할 수 있다. 이것은 달성될 동작에 따라 두 가지 방법으로 수행될 수 있다.

클라이언트가 요청을 하이퍼 서버의 프라이머리 멤버, 세컨더리 멤버, 모든 세컨더리 멤버들, 또는 모든 멤버들로 전송하기를 원하는 경우, 이것은 상기한 경우들 중 어느 하나를 특정하기 위하여 허용된다.

대안으로서, 비트맵에 기초하여, 클라이언트는 주어진 요청의 타겟이 하나 이상의 멤버들인지를 특정할 수 있다. 각각의 멤버는, 그 멤버가 하이퍼 세버에 속하는 한 그리고 인덱스를 사용하고 있던 멤버가 하이퍼 서버 멤버쉽을 탈퇴할 때 새로운 멤버에 재할당되는 한, 보유된 내부 하이퍼 서버 인덱스를 수신하기 때문에, 이것은 관심의 대상이 되는 멤버를 명확하게 식별한다. 비트맵은 이러한 목적을 위해 사용되기 때문에, 오직 하나의 멤버, 일부 멤버들, 또는 전체 멤버들이 이러한 방식으로 어드레스될 수 있음을 또한 주목할 필요가 있다.

이것은 네트워크 레이어로 전송된 각각의 요청이 두 개의 어드레싱 모드들 중 어느 것이 그 요청에 대해 사용되었는지, 그리고 전자에 기초하여, 멤버들 중 어느 멤버가 선택된 포맷에 따라 타겟되는지를 식별하는 플래그를 포함하는 것을 필요로 한다.

요청하는 클라이언트에 의해 수신되는 응답들은 응답한 멤버들의 인덱스로 식별됨에 또한 주목할 필요가 있다. 네트워크 레이어는 동기된 더 높은 레벨의 요청을 선택된 어드레스(들)에 대한 비동기 요청들에 맵핑하기 때문에, 다수의 응답들이 존재하는 경우, 이 동일한 레이어는 그러한 모든 응답들을 조합하여 단일 응답을 구성한다. 응답의 각각의 세그먼트는 응답된 멤버의 인덱스를 (그리고 그 역할을) 갖는다.

네트워크 레이어는 하이퍼 파일러의 클라이언트들 내의 서버 퍼실리티들을 또한 구현한다. 클라이언트 측에서 제공되는 서비스들은 최소이고 아주 단순하지만, 클라이언트들이 여전히 액티브 한지 또는 획득된 특정 오브젝트들이 여전히 사용 가능한지를 판단하고 시스템의 유연성을 향상시키기에 유용하다.

하이퍼 파일러에 있어서, 파일 시스템 레이어들은 다음과 같이 클라이언트 요청들을 수행한다.

클라이언트는 하이퍼 파일러 네임 스페이스를 로컬 마운트 포인트(비어 있고, 클라이언트가 보게 되며, 하이퍼 파일러의 네임 스페이스에 액세스하기 위해 클라이언트가 나타나게 되는 로컬 디렉토리)에 마운트한다. 마운트는 마운팅하는데 책임이 있는 하이퍼 파일러에 잘 알려진 실체에 어드레스된다. 이것은 단일 하이퍼 서버가 시스템이 기동되었을 때 요청들과 함께 플러드되는 것을 방지하기 위하여 복제된 실체일 수 있음에 주목할 필요가 있다. 마운트가 수행될 때, 클라이언트는 하이퍼 파일러의 구성을 설명하는 데이터 구조를 하이퍼 파일러로부터 수신한다. 이들은 해시 버킷들을 하이퍼 서버에 맵핑하는 해시 테이블과, 하이퍼 파일러 내의 하이퍼 서버들의 수와, 각각의 하이퍼 서버의 멤버쉽을 설명하는 테이블들을 포함한다.

파일 시스템 동작이 필요할 때, 클라이언트 내의 파일 시스템 레이어는 하위 레이어들에 적절한 요청을 보낸다. 요청의 본질은 필요한 대화의 타입을 판단하는 것이다. 파일 오픈과 같은 이름과 관련된 요청은 경로 이름이 64 비트 숫자로 해시되도록 한다. 이 숫자는 하이퍼 서버 ID가 저장된 해시 테이블 내의 어느 하나의 특정 슬롯을 어드레스하기 위해 사용된다. 이것은 어떤 하이퍼 서버에 클라이언트가 그 요청을 어드레스 해야 하는지의 표시를 하위 클라이언트 레이어들에 제공한다.

그런 다음, 요청은 지정된 하이퍼 서버에 어드레스될 네트워크 레이어로 전송된다. 네트워크 레이어는 하이퍼 서버 ID를 그 멤버들 중 하나의 IP 어드레스로 변환하고, 적절한 하이퍼 서버 숫자에 요청을 전송한다. 네트워크 레이어는 응답을 기다리고, 응답이 발생하면, 그 응답은 파일 시스템의 상위 레이어들로 전송된다.

이 모든 경우에, 다양한 상황이 고려될 수 있다. 먼저, 하이퍼 파일러는 시간이 경과함에 따라 진화하게 된다. 이는 하이퍼 서버들의 수가 증가할 수 있고, 하이퍼 서버 내의 멤버들(HMs)의 카운트가 변경될 수 있고, 하이퍼 서버 멤버들(HMs)은 충돌하거나 교체될 수 있음을 의미한다. 이 모든 것은 각각의 하이퍼 서버의 구성은 물론 해시 테이블의 변경을 야기할 수 있다. 이러한 이유로 인하여, 해시 테이블 및 하이퍼 서버를 설명하는 각각의 테이블은 연관되며 단조롭게 증가하는 생성 번호를 갖는다. 해시 테이블이 변경될 때마다, 이 번호는 상승한다. 원격 프로시저 콜(RPC)은 사용되는 해시 테이블에 대한 생성 번호와 원격 프로시저 콜(RPC)이 향하는 하이퍼 서버에 대한 생성 번호를 갖는다. 이것은 수신 단에서의 실체가 업데이트가 필요함을 클라이언트에 알림으로써 쓸모 없어진 생성 번호를 갖는 요청에 반응하는 것을 허용한다. 이것은 해시 테이블 및 하이퍼 서버 구성이 필요에 따라, 매우 비동기적이고 점진적인 방식으로, 증식되는 것을 허용한다.

하이퍼 파일러의 시스템 매니지먼트 컴포넌트는, 개개의 생성 번호를 갖는 하이퍼 서버 구성들은 물론, 해시 테이블 및 그 생성 번호를 유지하는데 책임이 있다.

하이퍼 파일러 네임 스페이스

본 발명의 다양한 실시예들에 따른 시스템의 네임 스페이스는 완전히 분산된다. 하이퍼 파일러 클라이언트들은 파일 또는 디렉토리의 경로 이름에 기초하여 주어진 파일 또는 디렉토리를 관리하는 하이퍼 서버의 HID를 식별할 수 있다. 이것은, 파일 시스템 오브젝트에 액세스하기 위하여, 클라이언트가 이야기를 할 필요가 있는 하이퍼 서버를 아는 것을 허용한다. 경로 이름들을 하이퍼 서버 아이디들(HIDs)에 맵핑하는 것은 해싱을 통해 달성된다. 본질적으로, 각각의 하이퍼 서버 클라이언트는, 네트워크 파일 시스템 (NFS)에 대해서 그러하였던 것처럼, 클라이언트 자신에 대해 로컬인 디렉토리 상에서 하이퍼 파일러의 "마운트" 동작을 수행한다. 마운트 시에, 클라이언트는 두 개의 테이블들, 즉 하이퍼 서버 테이블(HT) 및 디렉토리 해시 테이블(DHT)을 포함하는 일정한 양의 하이퍼 파일러 정보를 검색한다.

하이퍼 서버 테이블(HT)은 하이퍼 파일러 내의 이용 가능한 모든 하이퍼 서버들을, 그 구성과 함께, 열거한다. 이것은 하이퍼 서버 아이디들(HIDs)과 하이퍼 서버들의 멤버들의 IP 어드레스들 간의 맵핑을 제공한다. 기본이 되는 네트워크 레이어는 하이퍼 파일러가 하이퍼 서버 멤버들과 대화하는 것을 허용하는 이 테이블의 프라이머리 유저이다. 앞서 언급한 바와 같이, 하이퍼 서버 생성 번호는 각각의 하이퍼 서버 구성을 보호한다. 이것은 각각의 하이퍼 서버 내에서의 구성의 변화를 끊임없이 얻어내는 것을 허용한다. 네트워크 레이어는 하이퍼 서버로 전송된 각각의 메시지 내에 이 생성 번호를 자동적으로 삽입하기 때문에, 하이퍼 서버는 생성 번호의 불일치를 진단할 수 있고 따라서 하이퍼 서버 테이블(HT)의 카피를 새롭게 하는 것이 필요함을 클라이언트에 경고할 수 있다. 하이퍼 파일러에 대한 변경이 적용될 때마다, 예를 들어 하이퍼 서버 멤버들(HMs)이 충돌하거나 액세스 불가능하게 될 때, 또는 새로운 하이퍼 서버 멤버들(HMs)이 하이퍼 파일러에 연결되면, 하이퍼 서버 테이블(HT) 내의 엔트리들은 변경된다.

디렉토리 해시 테이블(DHT)은 디렉토리들을 하이퍼 서버 아이디들(HIDs)에 맵핑한다. 개념적인 관점에서 보면, 이것은 단지 하이퍼 서버의 ID를 각각 포함하는 슬롯들의 어레이이다. 맵핑은 다수 대 일의 방식으로 이루어지며, 이는 일반적으로 다수의 슬롯들이 동일한 하이퍼 서버로 향하게 됨을 의미한다. 클라이언트가 경로 이름을 결정할 필요가 있을 때, (관심의 대상이 되는 파일 시스템 오브젝트의 부모 디렉토리 까지 및 그를 포함하여) 하이퍼 파일러 상의 절대 경로 이름을 디렉토리 해시 테이블(DHT) 내의 하나의 엔트리에 해시한다. 이 엔트리는 디렉토리를 관리하며 그 디렉토리 내의 오브젝트들에 대한 요청들이 전송되어야 하는 하이퍼 서버의 HID를 제공한다. 디렉토리 해시 테이블(DHT)은 생성 번호에 의해 보호되며, 하이퍼 파일러 상태와 그의 클라이언트의 상태 간의 불일치를 검출하는 것을 허용한다. 따라서, 그러한 불일치는 검출되는 순간 신속히 수리될 수 있으며, 관심의 대상이 되는 디렉토리 해시 테이블(DHT) 엔트리가 사용되고 있을 때 검출될 수 있기 때문에 위험하지 않다. 해싱의 본질로 인하여, 단일 디렉토리 해시 테이블(DHT) 엔트리는 다수의 디렉토리들을 맵핑한다. 또한, 디렉토리 해시 테이블(DHT)은 하이퍼 서버 테이블(HT)보다 많은 엔트리들을 포함하는 것으로 예상되기 때문에, 다수의 디렉토리 해시 테이블(DHT) 엔트리들은 동일한 하이퍼 서버로 향할 수 있다. 이 개념은 100:1의 비율이 디렉토리 해시 테이블(DHT) 슬롯들의 수와 하이퍼 서버들의 수 사이에 존재하여야 한다는 것이다. 이것은, 예를 들어, 병목 현상을 해소하기 위해 또는 하이퍼 서버들에 걸쳐 디렉토리 해시 테이블(DHT) 엔트리들을 재분산하는 것이 필요할 때, 하나의 하이퍼 서버에서 다른 하나의 하이퍼 서버로 특정 엔드리들의 재타겟팅 (및 결합된 디렉토리들의 재타겟팅)을 허용한다.

두 테이블들 모두 하이퍼 파일러 내의 하이퍼 서버들의 수에 민감하다는 점에 주목할 필요가 있다. 이 수는 동적으로 변할 수 있기 때문에, 테이블들은 적절한 때에 업데이트될 필요가 있다. 하이퍼 파일러 측에서, 하이퍼 서버 테이블(HT)은 하이퍼 서버의 구성의 변화가 발생할 때마다 업데이트된다. 클라이언트 측에서는, 생성 번호가 변화된 하이퍼 서버를 클라이언트가 사용하고 있을 때에만 하이퍼 서버 테이블(HT)의 업데이트가 필요하다.

디렉토리 해시 테이블(DHT)은, 새로운 하이퍼 서버들이 하이퍼 파일러에 추가될 때, 업데이트 될 수 있다. 이것은, 새로운 하이퍼 서버들이 추가된 후에 디렉토리 해시 테이블(DHT)이 업데이트 되지 않더라도, 하이퍼 파일러가 계속해서 그 기능을 수행할 수 있다는 의미에서, 의무적이지 않다. 이 경우, 새로운 하이퍼 서버는 여전히 데이터 파일들을 저장할 수 있지만 네임 스페이스의 분산에는 관여하지 않는다. 이것은 (상위 티어 하이퍼 서버들의 경우) 일시적인 상태이지만, (데이터 파일들만을 저장하는) 하위 티어 하이퍼 서버들의 경우에는 영구적인 상태이다.

디렉토리 해시 테이블(DHT)은 또한 한 가지 중요한 특성을 만족하여야 한다. 확장 후에 테이블 엔트리가 고의로 변경되지 않는 한, 디렉토리 해시 테이블(DHT)이 확장되는 경우에도, 확장 전에 해싱을 통해 해싱된 HID가 확장 후에 검색된 HID와 동일하도록, 해싱 방식이 이루어져야 한다. 이를 명확히 하기 위하여, 주어진 디렉토리 이름을 해싱함으로써 확장 전의 디렉토리 해시 테이블(DHT)로부터 검색된 HID가 N이라 가정하자. 만일 디렉토리 해시 테이블(DHT)의 크기가 확장되면, 확장이 완료된 후에, 동일한 디렉토리는 여전히 N을 가져야 한다. 그러나, 테이블 확장이 완료된 후에, 시스템은, 필요하다면, 더욱 균일한 분산을 제공하기 위하여, 엔트리들에 걸쳐 하이퍼 서버 아이디들(HIDs)을 재분산하는 것이 허용되는 점에 주목할 필요가 있다. 그러나, 이것은 이어 받는 하이퍼 서버로 대체되는 하이퍼 서버에 의해 이전에 관리된 디렉토리들을 이동하는 것을 수반한다. 따라서, 디렉토리 해시 테이블(DHT) 확장과 함께 맵핑을 유지한다면, 디렉토리들의 이동을 요구하는 동작들과 하이퍼 서버들의 액티브한 연루가, 다소의 디렉토리 해시 테이블(DHT) 엔트리들이 교체될 때, 수행될 필요가 있다.

저장 클래스들

메타데이터 및 경로 이름들을 처리하는 네임 스페이스에 대응하는 것은 고객들의 파일들을 저장하기 위해 사용되는 실제 저장 인프라스트럭처이다.

하이퍼 서버의 특성들 때문에, 하이퍼 파일러가 구성되고 확장됨에 따라, 클래스의 일 부분을 이루는 하이퍼 서버들의 카디날리티와 저장 특성들에 의해 식별될 수 있는 별개의 저장 클래스들을 생성하는 하이퍼 서버들을 구성하는 것은 쉽다. 따라서, 한편으로는 최대 보호를 위해 3 개 또는 4 개의 멤버들에 걸쳐 복제가 수행되는 하이 리던던시 저장 클래스들에 속하는 하이퍼 서버들을 구비할 수 있고, 다른 한편으로 복제를 전혀 제공할 수 없으며 일시적인 데이터 또는 적당한 고유의 값을 갖는 데이터에 대해서만 사용되는 노 리던던시 저장 클래스들에 속하는 하이퍼 서버들을 구비할 수 있다. 마찬가지로, 하이퍼 서버 멤버들(HMs)에 걸쳐 리던던시를 가지지 않지만 복원력을 증가시키고 그러나 높은 이용 가능성을 구현하지는 않는 약간의 내부 리던던시를 가지는 하이퍼 서버들 및 저장 클래스들을 구성할 수 있다. (1(리던던시 없음)로 설정된 카디날리티를 가지며, 하이퍼 볼륨이 RAID 세트로 이루어진, 하이퍼 서버들은 이를 달성할 수 있다. 이 경우, (구성에 따라) RAID 세트 내의 하나 이상의 드라이브의 손실에 대한 복원력을 가지지만, 그러한 하이퍼 서버들을 지원하는 물리적인 장치 또는 가상의 장치의 충돌 중에 이용 가능성의 손실에 대한 보호는 제공하지는 않는다.)

저장 클래스들은 사용되고 있는 드라이브들의 종류에 또한 기초할 수 있다. 예를 들어, 고객은, SAS 드라이브들을 더욱 양호하게 보호할 필요가 있는 데이터에 할당하기 위하여, SATA 및 SAS 드라이브들 양쪽을 사용하는 하이퍼 파일러들을 구비하길 원할 수도 있다. 더욱이, 저장 클래스는 실제로 빈번하게 사용되지 않는 데이터를 저비용으로 저장하기 위하여 외부 오브젝트 스토어와 인터페이스 할 수 있다.

새로운 파일이 생성되면, 하이퍼 파일러의 네임 스페이스는, 파일들이 존재하는 디렉토리, 그 이름의 접미사 등등에 기초하여 저장 클래스들을 파일들에 할당하는 구성 규칙을 이용하여 적절한 저장 클래스를 선택한다.

하이퍼 파일러는 메타데이터를 스캐닝하고 고객이 선택한 시간 창 내에서 각각의 파일에 대한 액세스가 이루어졌는지에 대해 검증함으로써 저장 클래스들에 걸쳐 파일들을 이동시킬 수 있는 내장 메커니즘을 구비한다. 그러면, 고객이 선택한 정책들은 최근에 액세스가 이루어지지 않은 파일들을, 낮은 이용 가능성 및/또는 높은 액세스 시간을 가지고, 하위 저장 클래스들로 이동시킬 수 있다. 이것은 자동으로 이루어지고, 그러한 파일들의 경로 이름들이 완전히 영향을 받지 않기 때문에 네임 스페이스에 대해 영향을 미치지 않으며, 스캐닝은, 오직 네임 스페이스에 영향을 미치기 때문에, 실제의 디스크 입/출력 없이 수행된다.

네임 스페이스 앱스트랙션

네임 스페이스는 하이퍼 파일러의 핵심이다. 메타데이터 및 데이터 모두 완전히 분산되기 때문에, 네임 스페이스의 분산된 본질은 하이퍼 파일러의 선형 스케일링의 열쇠이다.

네임 스페이스의 설계는 많은 종래의 파일 시스템 설계들의 일부가 아니며 현대의 서버의 컴포넌트들의 상대적인 성능 및 능력으로 인하여 이해가 되는 다수의 중요한 관찰 기록들을 고려한다.

현대의 네트워크 인터페이스 카드들(NICs)에 의해 제공되는 네트워크 대역폭 및 레이턴시는 로컬 하드 드라이브들의 특성들에 필적하거나 그 특성들을 초과한다. 더욱이, 하드 디스크가 지속할 수 있는 초당 입/출력 동작들의 최대의 수는 지난 수년 동안 별로 변하지 않았고, 여전히 드라이브 당 약 100으로 제한되어 있다.

현재의 멀티 코어 중앙 처리 장치들(CPUs)은 저장 및 입/출력 동작들을 위해 컴퓨터 파워를 트레이드 오프하는 것을 허용한다.

네임 스페이스는 데이터 스페이스로부터 완전히 분리될 수 있다. 이렇게 함으로써, 데이터 스페이스가 저장되는 장치들과 성능 속성들의 관점에서 매우 다를 수 있는 장치들 상에 네임 스페이스를 위치시키는 것이 허용된다. 이것은 데이터 스토어에 대한 액세스 시간과 상관 없이 효율적이고 빠른 경로 이름 탐색을 보증하기 위해 중요하다.

컴퓨터 또는 하이퍼 서버 멤버(HM) 내에서 이용 가능한 램의 양은 통상적으로 1 기가바이트를 초과한다. 이것은 파일 시스템 메타데이터를 구성하기 위한 새로운 방법들을 허용한다.

하이퍼 파일러는 단일 하이퍼 서버를 가질 수 있도록 구성될 수 있음에 주목할 필요가 있다. 이 경우, 네임 스페이스와 데이터 스페이스 모두 하나의 하이퍼 서버에 의해 관리된다. 결과적으로 얻어지는 네임 스페이스는 전형적으로 네트워크에 걸쳐 액세스될 수 있도록 이용 가능하다. 그러나, 그 구조는, 그것이 지원하는 앱스트랙션이 이를 허용하기 때문에, 로컬 파일 시스템을 또한 효율적으로 구현할 수 있다.

그러나, 하이퍼 파일러는 일반적으로 다수의 하이퍼 서버들을 스팬 하는 것으로 예상된다. 이를 달성하기 위하여, 네임 스페이스 및 데이터 스페이스 양쪽 다 하이퍼 서버들에 걸쳐 분산된다. 하이퍼 서버들에 걸쳐 어떻게 이름들이 분산되는 지에 대해 논의하고, 그런 다음 하이퍼 서버 내에서 네임 스페이스의 로컬 부분이 어떻게 처리되는지에 대해 논의한다.

하이퍼 서버들에 걸친 네임 스페이스의 분산

하이퍼 서버들에 걸친 네임 스페이스의 분산은 클라이언트가 즉시 요청이 전송되어야 하는 하이퍼 서버를 알게 되는 방식으로 수행된다. 분산 기준은 다음의 고려 사항들에 기초한다.

디렉토리의 내용을 효율적으로 열거하는 능력이 분산된 네임 스페이스 내에 유지되어야 하며, 성능은 집중된 네임 스페이스보다 떨어지지 않아야 한다.

네임 스페이스 내에 새로운 컴포넌트들을 생성하는 능력은 이름의 상충이 존재하는지의 여부를 검증하는 능력에 기초하며, 이것은 효율적으로 지원되어야 한다.

디렉토리 내의 파일의 존재는 데이터 파일이 부모 디렉토리를 서비스하는 동일한 하이퍼 서버에 의해 관리되는 것을 암시해서는 안된다. 이것은 병목 현상을 해소하기 위해 중요하며, 파일들 및 디렉토리들이 하이퍼 서버들에 걸쳐 분산되는 것을 허용한다.

파일 시스템 오브젝트 이름들은 파일 시스템 오브젝트의 부모 디렉토리에 기초하여 하이퍼 파일러에 걸쳐 분산된다. 이 방식은 코샤(Kosha)에서 채택된 방식과 유사하며, 디렉토리 이름들을 다른 하이퍼 서버들에 해시한다. 2004년 11월 6일 - 12일, 미합중국 펜실베이니아 피츠버그, ACM/IEEE SC2004 학회: 고성능 컴퓨팅, 네트워킹, 및 스토리지 컨퍼런스(High Performance Computing, Networking and Storage Conference)에서 알리 라자 버트(Ali Raza Butt), 트로이 에이. 존슨(Troy A. Johnson), 일리 젱(Yili Zheng), 및 와이. 찰리 후(Y. Charlie Hu)가 기고한 논문 "코샤: 네트워크 파일 시스템에 있어서의 피어-투-피어 향상"(Kosha: A Peer-to-Peer Enhancement for the Network File System") 참조. 그러나, 코샤와의 주요 차이점은 해싱이 서브트리들보다는 개개의 디렉토리에 적용된다는 점이다. 따라서, 디렉토리 및 그의 자식 서브디렉토리는 다른 하이퍼 서버들에 의해 관리된다. 디렉토리들은 네임 스페이스 내에서 직접 표현된다. 따라서, 디렉토리들은 파일들에 대해 사용되는 데이터 스페이스 내의 별개의 저장 영역을 요구하지 않는다.

경로 이름을 보는 것만으로는, 클라이언트가 경로 이름이 파일 또는 디렉토리를 인용하는지의 여부를 알지 못할 수도 있음에 주목할 필요가 있다. 어떠한 경우에라도, 경로 이름 내의 잎사귀 컴포넌트의 본질이 무엇인지를 식별하기 위하여 부모 디렉토리를 사용하게 된다. 그것이 파일인 경우, 부모 디렉토리를 관리하는 하이퍼 서버는 모든 조회들이 전송되어야 하는 곳이다. 잎사귀 컴포넌트가 디렉토리인 경우, 부모는 디렉토리에 대한 관련된 모든 속성들을 저장하며, 부모의 하이퍼 서버는 요청의 타겟이 되어야 한다. 그러나, 디렉토리의 내용을 열거하라는 요청들은 디렉토리를 관리하는 하이퍼 서버로 전송될 필요가 있다. 본질적으로, 디렉토리들은 다수의 하이퍼 서버들 내에서 다수의 구체화된 형태로 존재한다.

디렉토리 정보는 그 부모를 관리하는 하이퍼 서버 내에 저장된다. 이것은 디렉토리에 대해 정당한 권한을 가진 하이퍼 서버이다.

디렉토리를 관리하는 하이퍼 서버는 디렉토리의 내용에 대해 정당한 권한을 가진 하이퍼 서버이며, 그 디렉토리 내의 모든 것에 대한 모든 요청들은 이 하이퍼 서버에 도달되어야 한다.

디렉토리의 섀도우 카피들이, 필요에 따라 네임 스페이스의 연결성을 보장하기 위하여, 하이퍼 서버들 내에 존재할 수 있다.

이를 예증하기 위하여, "/제1/제2/제3"으로 명명된 디렉토리의 경우를 고려해 볼 수 있다. "/"(전체 하이퍼 파일러의 루트)가 하이퍼 서버 A에 해시된다고 가정하면, "제1"은 하이퍼 서버 B에 해시되고, "제2"는 하이퍼 서버 C에 해시되고, "제3"은 하이퍼 서버 D에 해시된다. 이제, "/제1/제2/제3"의 속성들을 요청하기를 원하는 경우에, 요청은 하이퍼 서버 C로 전송되어야 한다. 다른 한편으로, "/제1/제2/제3"의 내용을 열거하라는 요청들 또는 "/제1/제2/제3" 아래의 파일에 액세스하라는 요청들은 하이퍼 서버 D를 타겟으로 하여야 한다. 이에 더하여, "/제1/제2/제3/제4/제5"로 명명된 디렉토리가 존재하는 경우, "/제1/제2/제3/제4/제5"를 포함하는 요청들을 처리할 수 있어야 하는 하이퍼 서버는 "/제1/제2/제3/제4"의 섀도우 카피들을 또한 포함하여야 한다.

네임 스페이스의 지속성

가상 메모리 기반 네임 스페이스는 명백히 지속성을 가져야 하는데, 이는 그 내용이 사실상 디스크에 백업 되어서 가상 메모리 내의 파일 메타데이터에 대해 수행된 어떠한 변경이라도, 충돌이 일어난 이후에도, 이용 가능하여야 함을 의미한다. 이것은 하이퍼 파일러에 대한 경우로, 시스템 성능에 대한 영향을 최소화 하면서 이것을 제공하기 위해 인텐트 로그 퍼실리티를 사용한다. 인텐트 로그는 트랜잭셔널하며, 마지막으로 완료된 네임 스페이스 트랜잭션에 대해 네임 스페이스가 항상 최신의 정보를 갖는 것을 허용한다. 충돌의 경우, 하이퍼 서버의 재시동은 디스크 상에서 네임 스페이스의 지속적인 카피에 로그된 마지막 트랜잭션을 적용하고 메모리의 관점에서 최근에 완료된 트랜잭션에 대한 초기화를 수반한다.

하이퍼 파일러 내의 네임 스페이스는, 데이터 저장소 내에 그 데이터를 저장할 필요가 없기 때문에, 데이터 저장소(참조 [2])로부터 분리된다. 이러한 분리는 이들 실시예에 있어서 파일 시스템의 설계를 단순화하고 네임 스페이스 내의 데이터의 양을 최소화한다. 따라서, 후자는 램 내에서 그것을 저장하기에 적합하게 된다.

키 데이터 구조

하이퍼 파일러의 네임 스페이스 내의 경로 이름들의 집합은 파트리시아 트리(Patricia Tree), 즉 일종의 순서 트리 데이터 구조로서 구현된다. 특히, 이 트리 형태의 데이터 구조는 몇가지 매우 중요한 속성들을 갖는다.

이 데이터 구조는 트리의 크기에 의존하지 않지만 탐색되는 스트링의 크기에 의존하는 매우 빠른 검색을 달성한다 (하이퍼 파일러 내의 경로 이름).

이 데이터 구조는 공통 스템을 갖는 아이템들을 그룹화한다는 점에서 매우 컴팩트하다.

이 데이터 구조는 정렬된 순서로 엔트리들을 유지한다.

최악의 경우, 개개의 파트리시아 트리 노드는 256 개 미만의 아이들(children)을 가지며. 이는 트리 구조가 링크된 리스트와 비슷한 무언가로 통합되는 것을 방지하기 위한 자동 메커니즘을 제공한다. 이것은 주요 성능 영향을 갖는다.

하이퍼 파일러 파트리시아 트리는, (파일 시스템 파일 또는 디렉토리 등의 파일 시스템 노드보다는 파트리시아 트리를 조합할 필요가 있는 내부 노드인지의 여부를 나타내는) 노드의 타입과, 그에 결합되는 스트링과, 노드 및 그의 아이들 위에서 동작할 필요가 있는 잠금(lock), 아이들과 부모에 대한 포인터들 등을 포함하는, 노드의 본질에 대한 기본적인 정보를 유지하는 고정 크기의 노드들로 이루어진다.

파일 시스템 내의 각각의 노드가 임의의 길이를 갖는 스트링을, (허용, 오너쉽 정보, 날짜, 및 익트텐트 ID들 같은) 파일 속성들과 함께, 저장할 수 있어야 한다면, 많은 노드들이 일부 필드들을 사용하지 않는 큰 데이터 구조를 가져야 한다. 예를 들어, 내부 파트리시아 트리 노드들은 파일 속성들을 필요로 하지 않는다. 디렉토리 노드들은, 그와 결합된 모든 정보는 데이터 저장소 내부 보다는 파트리시아 트리 내부에 있기 때문에, 외부 ID들을 필요로 하지 않는다.

이를 가장 잘 처리하기 위하여, 각각의 하이퍼 서버 상의 로컬 네임 스페이스는 고정된 크기의 엔트리들의 세 개의 연속하는 어레이들의 관점에서 구현된다.

파일 테이블(FT) - 이 어레이는 각각의 파일의 첫번째 익스텐트에 대한 외부 ID와 함께 파일 또는 디렉토리의 속성들을 저장한다. 참조 [2]에서 설명한 바와 같이, 이 ID는 전체 하이퍼 파일러에 걸쳐 글로벌하기 때문에, 데이터는 그 네임 스페이스 컴포넌트가 존재하는 동일한 하이퍼 서버 내에 존재할 필요가 없다.

스트링 테이블(ST) - 이 어레이는 연속하는 청크로 결합될 수 있는 고정된 길이의 셀들로 이루어지며, 노드 테이블 내에서는 적합하지 않은 스트링들을 저장한다.

노드 테이블(NT) - 이 데이터 구조는 각각의 노드의 잠금을, 필요하다면 스트링의 크기가 노드 테이블(NT) 엔트리 내에서 이용 가능한 저장 범위를 초과하는 경우 스트링 테이블(ST) 내의 스트링 또는 스트링의 ID와, 파트리시아 트리 내의 연결된 노드 테이블(NT) 엔트리들의 인덱스들과, 노드 테이블(NT) 엔트리들과 결합된 플래그들과, 결합된 파일 테이블(FT) 엔트리의 인덱스와 함께, 저장한다.

노드 테이블(NT)의 두 개의 엔트리들은 특별하다.

엔트리 0은 이용 가능한 모든 네임 스페이스들의 루트에 대한 포인터로서 동작한다. 이러한 레벨의 인디렉션은 미래에 네임 스페이스 또는 다수의 네임 스페이스들의 스냅 사진 촬영을 구현할 수 있다.

노드 테이블(NT)의 엔트리 1은 이식 가능 운영 체제 인터페이스 (portable operating system interface)(POSIX) 네임 스페이스의 루트 디렉토리이며, "/"에 대응한다.

노드 테이블(NT) 엔트리는 다음과 같은 엔트리들과 결합하거나 결합할 수 없다.

결합된 짧은 스트링을 가지는 한, 내부 파트리시아 트리 노드 또는 경로 이름의 중간 컴포넌트인 디렉토리의 경우에서처럼, 결합된 스트링이 엔트리 내에서 적합하고 엔트리가 결합된 파일 테이블(FT) 엔트리를 가지지 않는 경우, 다른 테이블들 내의 엔트리들과는 결합할 수 없다.

짧은 스트링을 갖는 파일 또는 디렉토리인 경우, 파일 테이블(FT) 내의 하나의 엔트리와 결합할 수 있다.

내부 파트리시아 트리 노드 또는 경로 이름의 중간 컴포넌트인 디렉토리이고 스트링이 노드의 용량을 초과하는 용량을 가지는 경우, 스트링 테이블(ST) 내의 하나 이상의 연속하는 엔트리들과 결합할 수 있다.

노드 테이블(NT) 엔트리의 용량을 초과하는 스트링을 갖는 파일 또는 디렉토리인 경우, 하나의 파일 테이블(FT) 엔트리와 하나 이상의 연속하는 스트링 테이블(ST) 엔트리들과 결합할 수 있다.

각각의 하이퍼 서버 멤버(HM) 내의 네임 스페이스 서버는 (존재한다면) 결합된 데이터 저장소를 또한 작동시키는 다중 스레트 프로세스로서 실행되는 것에 주목할 필요가 있다. 네임 스페이스에 액세스할 때 스레드들 간의 동기화는 필요하며, 독점적인 액세스는 업데이트된 노들들로 제한되면서 변경되지 않은 파트리시아 트리 노드들에 대한 공유된 액세스를 허용하기 때문에, 이에 대한 읽기-쓰기 잠금을 사용하는 것이 바람직하다. 그러나, 여기서 게임의 이름은 파일 테이블(FT), 스트링 테이블(ST), 및 노드 테이블(NT)의 컴팩트한 데이터 구조를 갖는다. 각각의 잠금이 많은 바이트들을 요구하는 경우, 노드 테이블(NT)의 크기는 매우 증가하게 되고, 이것은 램 내에서의 그것을 유지할 수 있는 가능성을 제한한다. 따라서, 하이퍼 파일러 내에서 사용되는 스레딩 퍼실리티들은 작은 메모리 풋프린트(footprint)를 갖는 읽기-쓰기 잠금들을 구현한다.

더욱이, 파트리시아 트리를 횡단하는 경우의 잠금(locking) 알고리듬은, 읽기 타입 동작들의 경우 읽기 모드에서 각각의 노드가 잠금(locked)되고 아이의 노드가 획득될 때에는 부모의 노드가 잠금 해제(unlock)되도록, 이루어져야 한다. 이것은 로킹을 두 가지 레벨들로 제한하며, 계층이 내려감에 따라 파트리시아 트리 내의 상위 노드들이 이용 가능하게 되도록 계층 방식으로 로킹을 수행한다. 이것은 리더들과 라이터들 간의 다툼을 최소화하며, 데드록(deadlock)(원형)의 필요한 네 가지 조건들 중 하나를 제거하는 잠금들 간의 순서를 유도하기 때문에, 데드록들을 회피한다.

쓰기 타입 동작들의 경우, 변형될 노드의 부모가 도달하면, 읽기 모드에서는 잠금되고 네임 스페이스 변경이 완료될 때까지 잠금된 상태로 유지되는 것을 제외하면, 유사한 알고리듬이 적용된다.

파트리시아 트리 노드를 로킹함으로써, (만일 존재한다면) 노드 테이블(NT)에 결합된 파일 테이블(FT) 및 스트링 테이블(ST) 엔트리들이, 다른 스레드들과의 가능한 충돌 없이, 동작할 수 있다는 점에 또한 주목할 필요가 있다.

별개의 뮤텍스들(mutexes)은, 자유 리스트들 상에서의 다툼을 피하기 위하여, 네임 스페이스의 일 부분인 각각의 테이블 내에 엔트리들을 할당하고 할당을 해제하기 위해 사용된다.

지속성 및 인텐트 로그

지속성은 파일 시스템에서 가장 중요하며, 네임 스페이스 파트리시아 트리는 지속성을 가져야 한다. 완전한 램 기반 하에서는 지속성이 달성되지 않는다. 이러한 이유로, 앞서 설명된 각각의 테이블은 변경이 기록되고 재시작 시에 테이블의 내용이 판독되는 백킹 스토어로서의 파일을 갖는다.

네임 스페이스 내에서, 노드 테이블(NT), 파일 테이블(FT), 및 스트링 테이블(ST) 내의 각각의 엔트리는 사이클릭 리던던시 체크(CRC) 코드를 포함한다. 이것은 엔트리가 변경될 때마다 계산된다. 이들 코드는 엔트리들이 디스크로부터 판독될 때 체크됨으로써, 키 네임 스페이스 데이터 구조들을 비트로트(bitrot)로부터 보호하고, 하이퍼 파일러가 동작하는 상태에서는 무시되지 않는, 드물지만 가능한 검출되지 않은 디스크 판독 에러들로부터 보호한다.

테이블 엔트리들 각각의 작은 크기를 고려하면, 백킹 파일들 내에서 다수의 임의의 검색이 필요하고 따라서 드라이브가 수행할 수 있는 이용 가능한 입/출력 동작들의 일부를 취하기 때문에, 쓰기 동작들은 매우 많은 비용이 든다.

이러한 이유로, 모든 업데이트들은 인텐트 로그를 사용하여 수행된다. 인텐트 로그는 (현재 1 메가바이트로 설정된) 메모리의 고정된 크기 면적을 메모리 맵핑함으로써 구현된다. 한 세트의 백킹 스토어로의 업데이트들이 필요할 때마다, 이들 업데이트들은, 각각이 관련된 테이블의 표시와 함께, 인텐트 로그에 카피된다. 단일 동작의 업데이트들은 함께 링크된다. (하이퍼 서버 프라이머리) 업데이트들을 수행하는 스레드는 링크된 변경들을 인텐트 로그에 비동기적으로 푸시(push)하고, 그 후에 업데이트들을 세컨더리들에 푸시한다. 동기적인 거동이 요구되는 경우, 스레드는 세컨더리 업데이트들이 완료되기를 기다리고, 그 후에 인텐트 로그가 종료되기를 기다린다. 다른 한편으로, 비동기 업데이트들이 승인되는 경우, 스레드는 다만 그때까지 유지된 쓰기 잠금 상태를 해제함으로써 동작을 완료하기 전에 세컨더리 업데이트들이 수신되기를 기다릴 필요가 있다.

실제 배킹 파일들 내의 최종 임의 오프셋들을 타겟팅하는 것은 중간 검색을 요구하지는 않지만, 인텐트 로그는 연속하는 파일에, 따라서 업데이트들의 리스트에, 맵핑되는 것으로 예상된다. 새로운 업데이트들이 초기에 비어 있는 인텐트 파일에 첨부되기 때문에, 맵핑된 각각의 페이지가 가득 차게 되면, 비동기적으로 쏟아져 나오게 되고, 이에 의해 업데이트는 지속성을 갖게 된다. 동기 입/출력이 요구되거나 콜러(caller)가 'fsyc()' 콜을 수행하면, 관심의 대상이 되는 인텐트 로그의 일부가 디스크에 남겨지는 경우에만 클라이언트에 대한 애크날리지먼트가 발생한다. 따라서, 업데이트는 애크날리지먼트가 반송될 때까지 안정된 상태로 저장된다. 인텐트 로그의 끝 부분이 도달하는 순간, 서비스 스레드가 인텐트 로그로부터 업데이트들을 비동기적으로 추출하기 시작하고 그것들을 실제 백킹 파일들에 남겨두면서, 도입되는 업데이트들에 대해 새로운 인텐트 로그가 생성된다. 이것이 종료되면, 인텐트 로그는 폐기된다. 충돌이 발생하면, 재기동 시에, 네임 스페이스의 초기화는, 업데이트들이 백킹 파일들로 전달되도록, 여전히 존재하는 모든 인텐트 로그들의 프로세싱을 수반한다. 미해결된 모든 인텐트 로그들이 처리되고, 삭제되고, 백킹 스토어가 업데이트될 때에만, 이들은 메모리 내의 네임 스페이스 데이터 구조들을 구성하는 세 개의 어레이들(파일 테이블(FT), 스트링 테이블(ST), 및 노드 테이블(NT)) 내에 읽어 넣어지게 된다.

백킹 스토어 및 인텐트 로그에 대한 추가적인 관찰

첫 번째로 공개한 타겟인 상기한 방식의 대안들에 대해 이하에서 설명하기로 한다.

여기서, 백킹 스토어(노드 테이블(NT), 스트링 테이블(ST), 및 파일 테이블(FT)의 내용을 복제하는 세 개의 파일들)가, 완전히 정착된 네임 스페이스를 가지기 위하여, 하이퍼 서버 멤버가 재시작될 때에만 사용되는 것을 분명히 알아야 한다.

인텐트 로그로부터 백킹 스토어를 업데이트하면, 개개의 테이블 엔트리들을 업데이트 하기 위하여, 다수의 검색이 디스크 상에서 이루어지게 된다. 이것은, 직접적인 클라이언트 요청들을 처리하기 위하여 디스크가 수행할 수 있는 입/출력 동작들의 수를 감소시키기 때문에, 바람직하지 않다. 그래서, 백킹 스토어를 업데이트 하는 좋은 전략은 인텐트 로그로부터 파일들로의 업데이트들을 수행되는 디스크 입/출력 동작들의 수가 문턱 값 미만일 때의 시간 주기로 연기시키는 것일 수 있다. 명백하게, 이 숫자는 잠재적으로 무한히 증가할 수 있고 적절한 범위를 넘어 디스크 공간을 사용할 수 있기 때문에, 너무 많은 인텐트 로그들을 유지하는 않는 것을 보장할 필요가 있다. 따라서, 역압(back pressure)의 일부 형태가, 매우 긴 시간 동안 업데이트들이 지연되는 것으로 피하기 위하여, 존재하여야 한다.

다른 한편으로, 인텐트 로그의 일부 통합을 또한 수행할 필요가 있다. 업데이트된 테이블 엔트리들의 비트 맵들을 유지할 수 있다. 이들 비트 맵들은 초기에 0으로 설정될 수 있다. 인텐트 로그들을 거꾸로 스캔할 수 있고, 업데이트 될 비트 맵들에 대해 업데이트 비트를 설정할 수 있다. 스캐닝되고 있는 로그 내에서 엔트리 업데이트가 발견되는 경우, 엔트리의 업데이트 비트가 이미 설정되어 있다면, 후속하는 버전의 데이터와 함께 이미 업데이트 되었기 때문에, 엔트리는 추가로 업데이트될 필요가 없다. 따라서, 그 업데이트 엔트리는 통합된 로그 밖으로 추방될 수 있다. 더 오래된 인텐트 로그가 처리될 때까지 프로세스가 계속된다. 이 방식은 다수의 인텐트 로그들을 효력이 없어진 엔트리들을 갖지 않는 하나의 로그로 주기적으로 통합시키는 것을 허용한다.

최종적으로, 개개의 백킹 스토어 파일들을 완전히 제거하는 것이 또한 가능하다. 실제로, 업데이트 트래픽이 존재하는 경우 증가하게 되는, 사용되는 스토리지의 양을 제한하기 위하여, 램 테이블들이 디스크로부터 읽어 들일 필요가 있는 재기동 시에만 인텐트 로그들로부터 직접 판독함으로써 수행될 수 있고 로그들의 주기적인 통합이 수행될 수 있다는 결론에 도달할 수 있다.

한편, 단일 로그 파일이 사용되도록, 그러나 주기적으로 그의 후속하는 섹션들이 메모리 맵핑되어 새로운 업데이트들을 첨부하도록, 인텐트 로그들에 대한 약간 다른 방법을 또한 고려해 볼 수 있다. 이것은 인텐트 로그들의 카운트를 감소시킨다. 효력이 없어진 업데이트들을 없애기 위하여, 더 큰 파일은 앞서 논의한 것과 유사한 방식으로 통합될 수 있다.

이것은 미래의 하이퍼 파일러 공개 시의 실제적인 요구에 기초하여, 네임 스페이스의 지속성을 관리하기 위한 초기 방식을 진화시킬 수 있는 방법이다.

세컨더리 하이퍼 서버 멤버들의 업데이팅

프라이머리 및 세컨더리 하이퍼 서버 멤버들(HMs)은 독립적으로 동작하며, 다른 읽기 타입 요청들을 처리한다. 그러나, 쓰기 타입 요청들은 로컬 변화를 수행하는 프라이머리 하이퍼 서버 멤버에 의해 조정되며, 성공적인 경우에, 요청 클라이언트에 응답하기 전에 세컨더리 하이퍼 서버 멤버들의 상태가 프라이머리 하이퍼 서버 멤버와 일치하도록 하여야 한다.

하이퍼 서버 멤버들 간의 프로세싱의 비동기적 거동 및 각각의 멤버 내에서 실행되는 다수의 스레드들로 인하여, 프라이머리 하이퍼 서버 멤버가 수신한 쓰기 타입 요청들을 세컨더리 하이퍼 서버 멤버들에 지금 막 전송하였다면, 이들은 달리 처리되고, 기능적으로 등가인 결과들을 산출하지만, 다른 멤버들이 여러 네임 스페이스 테이블들에 대해 다른 엔트리들을 사용하도록 한다.

이것은 재앙은 아니지만, 멤버들 간의 일관성에 대한 입증 및 복원을 매우 복잡하게 만든다. 또한 또 다른 결과를 갖는다. 데이터 저장소 내에서 네임 스페이스가 향하는 파일들은 그들의 네임 스페이스 컴포넌트들로 다시 향할 필요가 있다. 이것은 네임 스페이스와 데이터 스페이스 간의 추가적인 일관성 체크가 수행되는 것을 허용하며, 부모가 없는 데이터 파일들을 교정하기 위하여 쓸데없는 컬렉션이 이용 가능하게 되는 것을 허용한다. 네임 스페이스가 (데이터 측 하이퍼 서버의 멤버들 상에서) 주어진 파일이 항상 네임 스페이스 하이퍼 서버의 멤버 상의 동일한 노드 테이블(NT) 엔트리에 항상 연결됨을 보장한다면, 데이터 파일들은 노드 테이블(NT) 엔트리의 인덱스를 저장할 수 있다. 그렇지 않으면, 데이터 파일들은 네임 스페이스 하이퍼 서버의 멤버들 각각에 대해 노드 테이블(NT) 엔트리들 각각의 인덱스를 저장하거나 (한편으로는 경로 이름에 영향을 미치는 개명이 발생할 때마다 변경되어야 하는) 컴포넌트에 대해 가변 길이의 경로 이름을 저장하여야 한다.

상기한 모든 복잡한 상태들을 피하기 위하여, 하이퍼 파일러의 네임 스페이스는 네임 스페이스 내의 동일한 테이블 엔트리들이 네임 스페이스 하이퍼 서버 멤버들 상에서 주어진 파일 시스템 오브젝트에 대해 사용되도록 하는 것에 기초한다. 그러나, 이것은, 클라이언트 요구들의 비동기적인 실행에 상관없이, 할당될 테이블 엔트리들이 동일할 필요가 있기 때문에, 세컨더리 멤버들 상에서의 요청들의 실행이 다루어져야 하는 방법에 대한 변화들을 필요로 한다. 이것은 또한 프라이머리 멤버의 상태를 반영하기 위하여 테이블 엔트리들을 변경할 필요가 있는 방법에 대해 세컨더리 멤버들이 들을 필요가 있기 때문에, 세컨더리 동작들을 간소화할 수 있는 기회이다.

주목해야 할 한 가지 사실은 진행중인 읽기 타입 요청들은 프라이머리 멤버로부터의 쓰기 업데이트들이 적용됨에 따라 자유로이 흐를 수 (flow) 있어야 한다는 점이다. 이것이 성공적으로 수행되면, 프라이머리 멤버는 업데이트를 수행하기 위해 독점적인 모드에서 잠겨야 하는 노드 테이블(NT) 엔트리의 표시를 전송하여야 한다. 이것은 도입되는 읽기 타입 요청들이 일시적인 상태에 있는 데이터 구조들로 액세스하게 되는 것을 방지한다. 나머지의 경우, 프라이머리 멤버는, 생성되어 로컬 인텐트 로그에 남겨진 업데이트 리스트를, 이 리스트가 프라이머리 멤버 상에서 수행된 것을 복제하기 위한 정확한 방법이기 때문에, 각각의 세컨더리 멤버에게 단지 전송할 필요가 있다.

하나 이상의 약간의 복잡한 상태가 존재한다. 업데이트들이 프라이머리 멤버 상에서 공동의 스레드들에 의해 수행되기 때문에, 그러한 업데이트들은 세컨더리 멤버들 상에서 동일한 순서로 수행되는 것이 바람직하다. 이러한 이유로, 프라이머리 멤버와 세컨더리 멤버는, 동작들이 수행되는 순서를 끊임없이 얻어내는 모듈인, 시퀀서를 실행한다. 이것은 프라이머리 멤버와 세컨더리 멤버 상에서 다른 방식으로 사용되고 동작한다.

프라이머리 멤버 상에서, 각각의 업데이트가 시작될 때, 독점적인 노드 테이블(NT) 엔트리 잠금이 획득된 후에, 업데이팅 스레드는 시퀀스 ID를 요청하고 저장한다. 이것은 시퀀서가 단조롭게 (랩어라운드(wrap-around)를 가지고) 발생시키는 64 비트 숫자이다. 제외되는 단 하나의 값은 0이다. 프라이머리 멤버는, 업데이트 리스트와 함께 이 숫자를 세컨더리 멤버들에게 전송하기 위하여, 이 숫자를 획득하고 저장한다.

세컨더리 멤버 상에서, 업데이트 요청을 수신한 스레드는 시퀀서의 로컬 카피에게 시퀀스 ID를 승인할 것을 요구한다. 이전의 시퀀스 ID가 이미 처리된 경우, 시퀀서는 스레드가 진행되는 것을 허용한다. 그렇지 않으면, 스레드들은 이전의 시퀀스 ID가 완전히 처리될 때까지 대기한다. 스레드가 그 시퀀스 ID의 처리를 위한 승인을 수신한 후에, 관심의 대상이 되는 노드 테이블(NT) 엔트리에 대해 독점적인 잠금을 획득하며, 올바른 순서로 모든 테이블 엔트리들을 계속해서 업데이트 한다. 모든 것이 업데이트 되면, 스레드는 시퀀서에게 시퀀스 ID가 수행되었음을 말하며, 이로 인해 다음의 업데이트가 계속되는 것이 허용된다. (ID의 획득이 중단되어야 하는 동작의 경우에는, 스레드가 시퀀스 ID를 폐기하는 것을 허용하는 퍼실리티가 이용 가능하다.)

프라이머리 멤버 대 세컨더리 멤버들의 업데이트들의 실행에 있어서 한 가지 중요한 양상은 모든 할당 선택들이 프라이머리 멤버 내에서 수행되고 프라이머리 멤버는, 프라이머리 멤버가 유지하는 자유 리스트 밖의 각각의 테이블 내에서 이용 가능한 다음 엔트리를 가로챔으로써, 이것을 수행한다는 사실과 관계가 있다. 자유 리스트는 사용되지 않는 각각의 테이블의 엔트리들을 함께 링크시킨다. 다른 한편으로, 세컨더리 멤버들은 할당할 테이블 엔트리들을 선택할 필요가 없다. 그 이유는 사용되는 엔트리들의 인덱스들이 각각의 세컨더리 멤버가 수신한 업데이트 리스트 내에 들어 있기 때문이다. 따라서, 세컨더리 멤버들은 자신의 자유 리스트들을 유지할 필요가 없다.

네임 스페이스의 상태에 대한 업데이트들을 처리함에 있어 하이퍼 서버 멤버들의 비동기적인 거동에 대해 요약하면 다음과 같다. 주어진 하이퍼 서버의 멤버들은, 동일한 식별자들을 갖는 네임 스페이스의 서브컴포넌트들, 즉 파일 테이블(FT) 엔트리들, 스트링 테이블(ST) 엔트리들, 및 노드 테이블(NT) 엔트리들이 하이퍼 서버의 멤버들 간의 동일한 동작을 위해 할당되거나 삭제될 수 있도록, 구성된다. 동일한 식별자들을 갖는 서브컴포넌트들이 사용되는 경우에도, 하이퍼 서버의 멤버들은 업데이트 요청들, 즉 네임 스페이스의 상태의 업데이트를 야기하는 요청들을 처리함에 있어서 비동기적으로 동작하도록 구성된다. 멤버들의 비동기적인 동작을 가능하게 하기 위하여, 프라이머리 멤버에 의해 업데이트 요청들에 시퀀스 번호가 할당되며, 이들 시퀀스 번호들은 세컨더리 멤버들에 의해 업데이트들이 수행되는 순서를 제공하기 위하여 사용된다. 프라이머리 멤버에 의해 쓰기 잠금이 적용되어, 삭제되고, 생성되고, 변경될 실체(파일 또는 디렉토리 또는 심볼 링크)의 부모인 파일 시스템 노드를 사용한다. 그런 다음, 프라이머리 멤버는 로컬 업데이트를 수행한다. 그런 다음, 시퀀스 번호, 획득될 잠금들의 리스트, 업데이트 될 네임 스페이스 엔트리들의 새로운 내용을 포함하는 패킷을 조합한다. 그런 다음, 패킷을 세컨더리 멤버들 각각에 전송한다. 패킷을 수신하면, 각각의 세컨더리 멤버는 시퀀스 번호가 현재의 번호가 되기를 기다리며, 그런 다음 패킷 내에 특정된 쓰기 잠금을 파일 시스템 노드의 대응하는 컴포넌트에 적용하고, 그런 다음 로컬 업데이트를 수행한다. 최종적으로, 세컨더리 멤버는 프라이머리 멤버에 애크날리지먼트를 제공한다. 이 때, 세컨더리 멤버는, 공존하는 다른 업데이트들이 수행될 수 있도록, 다음 시퀀스 번호로 진행한다. 업데이트가 삭제 및 덮어 쓰기를 포함하는 경우, 삭제는 여분의 것이기 때문에, 프라이머리 멤버는 오직 덮어 쓰기만을 전송한다.

각각의 세컨더리 멤버로부터 애크날리지먼트를 수신하는 경우, 프라이머리 멤버는 쓰기 잠금을 제거하고, 이 때 프라이머리 멤버는 다음의 프로토콜들 중 하나에 따라 요청 클라이언트에 응답을 한다. (1) 업데이트가 수행되고 안정된 스토리지 내에 놓이는 경우, 세컨더리 멤버는 프라이머리 멤버에 애크날리지먼트를 제공한다. (2) 업데이트가 수행되었지만 업데이트가 안정된 스토리지 내에 놓일 때까지 대기하지 않는 경우, 세컨더리 멤버는 프라이머리 멤버에 애크날리지먼트를 제공한다. (3) 프라이머리 요청을 수신하였지만 세컨더리 멤버가 실제로 업데이트를 수행하기 전인 경우, 세컨더리 멤버는 프라이머리 멤버에 애크날리지먼트를 제공한다. 이들 프로토콜들 중 어느 것을 사용할지에 대한 판단은 성능 및 신뢰성 간의 원하는 트레이드 오프에 따라 행해진다.

몇몇 중요한 고려 사항들이 상기로부터 유래한다.

액티브 프라이머리 멤버만이 자유 리스트들을 사용하고 업데이트할 필요가 있는 멤버이기 때문에, 이들은 가동중인 프라이머리 멤버에 대해서만 관련이 있다.

노드 테이블(NT)이 주요 역할을 하는 반면에 파일 테이블(FT)과 스트링 테이블(ST)은 보조 역할을 하는 테이블들 간의 계층이 존재한다. 다시 말해서, 하나의 노드 테이블(NT)에 의해 참조되지 않는 한, 파일 테이블(FT)과 스트링 테이블(ST) 내의 엔트리들은 할당될 수 없다.

또 다른 엔트리에 의해 노드 테이블(NT) 내에서 참조될 경우에만, 노드 테이블(NT) 내의 엔트리들이 사용된다.

테이블들은, 각각의 테이블이 램 밖에서 처리되거나 재시작 후에 백킹 스토어로부터 판독됨으로써 처리될 때 자유 리스트들이 재생성될 수 있는 방식으로, 설정된다.

이것은 두 가지 주요 결과들을 갖는다.

필요에 따라, 즉 세컨더리 멤버가 활동을 그친 프라이머리 멤버를 대신하거나 하이퍼 서버가 재시작하여 프라이머리 멤버가 동작하여야 할 때 재구성될 수 있기 때문에, 자유 리스트가 지속성을 가지도록 하고 각각의 테이블에 대해 파일 스토어 상에 백킹하도록 할 필요가 없다.

그 자유롭거나 바쁜 상태가 나머지 테이블 엔트리들로부터 재구성될 수 있기 때문에, (테이블 내에서) 테이블 엔트리를 해방하는 동작은 백킹 스토어에 이를 필요가 없다.

상기한 내용의 실제적인 의미들은 다음과 같다.

테이블 엔트리들을 포함하는 자유 동작들 중 어느 것도 세컨더리 멤버들에 도달할 필요가 없다.

테이블 엔트리들을 포함하는 자유 동작들 중 어느 것도 인텐트 로그 및 백팅 스토어에 도달할 필요가 없다.

이것은 네임 스페이스에 대한 하이퍼 서버 업데이트들의 로직을 단순화하고 인텐트 로그 및 백팅 스토어에 대한 입/출력 트래픽을 줄일 수 있다는 점에서 매우 유용하다.

어떤 경우에서도, 일단 프라이머리 멤버가 요청한 업데이트들을 세컨더리 멤버가 수행하면, 먼저 세컨더리 멤버는 업데이트들을 인텐트 로그 및 백팅 스토어로 전송하여야 하고, 그 다음에 동작이 시작될 때 획득된 노드 테이블(NT) 엔트리 잠금을 포기하여야 하고, 최종적으로 그것이 사용하고 있던 시퀀스 ID가 완전히 처리되었음을 시퀀서가 알도록 해야 한다.

하이퍼 서버 멤버의 재시작

앞서 개략적으로 설명한 바와 같이, 프라이머리 멤버들은 오직 그들이 속하는 하이퍼 서버를 떠남으로써 그들의 역할을 변경할 수 있는 반면에, 세컨더리 멤버는, 프라이머리 멤버가 더 이상 활동하지 않을 때, 프라이머리 멤버가 될 수 있다.

이와 다소 비슷한 상황으로서 하이퍼 서버가 시스템 셧다운의 결과로서 그리고 후속하는 시동의 결과로서 재시작되는 상황이 있다.

이들 두 가지 경우는, 그 역할을 가지지 못한 멤버가 프라이머리 멤버가 되어야 한다는 점에서, 유사하다. 이들 두 가지 경우 간의 차이점은 세컨더리 멤버에서 프라이머리 멤버로의 변경이 멤버가 이미 활동하여 실행 중인 반면에 재시작은 전체 하이퍼 서버 멤버 환경의 설정을 요구한다는 점이다.

세컨더리 멤버에서 프라이머리 멤버로의 변경이 이루어지는 경우, 세컨더리 멤버는 이미 활동하여 실행되고 있다. 이것은 단지 쓰기 타입 요청들을 계속해서 처리할 필요가 있으며 세컨더리 멤버들 상에서 쓰기 타입 동작들을 조정할 능력이 있어야 한다. 이를 달성하기 위하여, 네임 스페이스에 대하여, 모든 테이블들이 일관된 상태에 있어야 하고 필요에 따라 이용 가능한 자유 리스트들을 새로운 테이블 엔트리들을 할당하도록 할 필요가 있다.

상기한 사항을 달성하기 위하여, 새로이 선출되는 프라이머리 멤버는 다음과 같은 동작을 수행한다.

프라이머리 멤버는 노드 테이블(NT), 파일 테이블(FT), 및 스트링 테이블(ST)의 각각의 엔트리 내에서 '참조' 비트를 재설정한다.

프라이머리 멤버는 루트 네임 스페이스부터 시작하여 노드 테이블(NT)을 스캐닝하고 노드 트리를 가로지를 때 만나게 되는 엔트리들에 대하여 '참조' 비트를 설정한다.

이전 단계의 끝 부분에서, 프라이머리 멤버는 전체 노드 테이블(NT)을 다시 스캐닝한다. 프라이머리 멤버는 '참조' 비트가 설정되지 않은 모든 엔트리들을 해방하고 이들을 노드 테이블(NT) 자유 리스트에 추가한다. '참조' 비트가 설정된 모든 노드 테이블(NT) 엔트리들의 경우, 프라이머리 멤버는 그들이 파일 테이블(FT) 엔트리들 및/또는 스트링 테이블(ST) 엔트리들을 참조하는지를 체크하고 이들 엔트리들에 대해 '참조' 비트를 설정한다.

그런 다음, 프라이머리 멤버는 파일 테이블(FT) 및 스트링 테이블(ST)을 스캐닝하고, '참조' 비트가 설정되지 않은 모든 엔트리들을 해방하고 이들을 적절한 자유 리스트에 추가한다.

상기의 끝 부분에서, 테이블들 및 자유 리스트등의 인테그리티(integrity)가 완전히 재구성되고, 새로운 프라이머리 멤버는 완전하게 동작할 수 있다.

하이퍼 서버가 재시작되는 경우, 프라이머리 멤버는 상기의 동작들을 수행할 필요가 있다. 그러나, 그 이전에, 각각의 하이퍼 서버 멤버는 (존재한다면) 인텐트 로그 파일들을 읽어야 하고, 업데이트들을 백킹 스토어들에 적용하여야 하고, 처리된 인텐트 로그들을 삭제하여야 한다. 이러한 동작이 완료되면, 각각의 멤버는 각각의 파일을 적절한 테이블 내로 읽어 들여서 초기화를 완료하여야 하며, 오직 프라이머리 멤버만이 자유 리스트들을 재구성하여야 한다.

새로운 멤버들의 초기화

멤버가 하이퍼 서버로부터 퇴출되거나 충돌이 일어날 경우, (이용 가능하다면) 새로운 멤버가 떠난 멤버를 대신할 필요가 있다.

전형적으로, 그러한 멤버는 네임 스페이스의 카피를 재생성할 필요가 있는 정보를 가지지 않는다. 따라서, 프라이머리 멤버는 다음의 동작들을 수행함으로써 새로운 멤버의 초기화를 이어 받아 수행한다.

프라이머리 멤버는, 초기에 클라이언트 동작들을 수행하는 것이 허용되지 않도록 그리고 클라이언트들에 전해진 하이퍼 서버의 상태가 이것을 반영하도록, 새로운 멤버를 설정한다.

프라이머리 멤버는 네임 스페이스 테이블들 각각의 시작 지점에 현재의 위치를 설정한다.

프라이머리 멤버는 각각의 테이블을 스캐닝하기 시작하고 사용되고 있는 각각의 엔트리의 내용을 새로운 세컨더리 멤버에게 전달한다.

이것이 진행됨에 따라, 프라이머리 멤버는 각각의 테이블에 대해 처리되는 엔트리 테이블의 개념을 업데이트한다.

도입되는 클라이언트 요청들이 도달하면, 그 요청들을 프라이머리 멤버에 전달함으로써 새로운 세컨더리 멤버에는 어드레스 되지 않거나 새로운 세컨더리 멤버는 도달할 수도 있는 요청들을 폐기한다. 프라이머리 멤버가 수행하는 모든 업데이트들은 세컨더리 멤버에 이미 카피된 각각의 테이블 내의 엔트리들 또는 카피된 엔트리를 넘어서는 엔트리들에 영향을 미치는 업데이트들로 분할될 수 있다. 카피가 수행된 이후 카피된 엔트리들의 상태는 변경되었기 때문에, 현재의 엔트리에 선행하는 엔트리들은 세컨더리 멤버에 대해 업데이트들을 발생시킬 필요가 있다. 엔트리들이 도달함에 따라 업데이트들이 적용되기 때문에, 현재의 엔트리에 후속하는 엔트리들은 무시될 수 있다.

모든 엔트리 테이블들이 처리되면, 프라이머리 멤버는 하이퍼 서버의 상태를 변경할 수 있고 새로운 세컨더리 멤버를 동작 가능한 상태인 것으로 표시할 수 있다.

이 단계의 끝 부분에서, 새로운 세컨더리 멤버는 네임 스페이스 요청들을 또한 처리할 수 있다. 데이터 저장소를 가지는 경우, 파일들에 대한 요청들에 응답하는 능력은 데이터 저장소 서브시스템의 상태에 좌우되며 그 컴포넌트에 의해 처리될 필요가 있다.

네임 스페이스의 기타 용도

네임 스페이스의 구조는 일반적인 것으로서, 경로 이름의 포직스(POSIX) 관점으로 한정되지 않는다. 특히, 엔트리 0은 모든 네임 스페이스들의 루트 노드이기 때문에, 포직스(POSIX) 네임 스페이스의 루트로 향하는 것을 제외하면, 다른 아이들(children)을 또한 구비할 수 있다.

이것은, 특정 형태의 대안으로서의 분산된 네임 스페이스를 구현하기를 원하는 경우에, 쉽게 달성된다. 두 가지의 가능성이 존재한다.

익스텐트 핑거프린트들(fingerprints)을 수집하는 대안으로서의 네임 스페이스. 이들은 하이퍼 서버들에 걸쳐 분포되며, 그들을 해싱함으로써 각각의 엔트리를 관리하는 하이퍼 서버의 HID를 산출한다. 이것은, 시스템의 첫번째 공개를 위한 타겟은 아니지만, 익스텐트 복제를 구현하기 위하여 사용될 수 있다.

또 다른 대안으로서의 네임 스페이스는 하이퍼 파일러 시스템 자체에 의해 사용되는 분산 디렉토리로서 사용될 수 있다.

네임 스페이스가 하이퍼 파일러 상에서 아마존 S3-스타일 오브젝트 스토어를 구현하기 위하여 사용될 수 있지만, 파일의 첫 번째 익스텐트 ID(이하 참조)가 오브젝트 ID로서 사용될 수 있기 때문에, 특별한 네임 스페이스를 사용할 필요는 없다. 익스텐트 ID는 이미 그것이 저장된 하이퍼 서버를 식별하며, 따라서 추가적인 인디렉션은 필요하지 않다.

데이터 스페이스

데이터 스페이스는 데이터 저장소 서브시스템을 통해 구현된다. 데이터 스페이스는 각각의 컨테이너가 존재하는 하이퍼 볼륨과 관련된 유니크한 하이퍼 파일러 와이드 익스텐트 ID들(EIDs)을 통해 식별되는 파일 데이터용 컨테이너들을 한데 모으게 된다. 따라서, 네임 스페이스 내의 데이터 컨테이너에 대한 참조는 하나의 유니크한 ID이며, 네임 스페이스 컴포넌트가 위치하는 동일한 하이퍼 서버 상에 호스트될 필요는 없다.

하이퍼 볼륨의 데이터 스페이스 컴포넌트는 파일 데이터가 저장되는 저장소이다. 이것은 4 킬로바이트의 논리 블록을 관리하는 익스텐트 기반 파일 시스템이다. (이론적으로, 1 킬로바이트의 논리 블록은, 파일당 낭비되는 평균 스토리지가 파일당 512 바이트이며, 이는 매우 많은 작은 파일들이 존재할 때마다 사실상의 저장량을 절약할 수 있다는 장점을 제공한다. 다른 한편으로, 4 킬로바이트의 논리 블록의 경우에는, 파일당 2 킬로바이트를 평균적으로 낭비함으로써 낭비되는 공간이 4 배 증가하게 된다. 그러나, 더 새로운 디스크 드라이브들은, 종래의 512 바이트 디스크 섹터 대신에 4 킬로바이트 디스크 섹터들을 사용하기 때문에, 4 킬로바이트를 선택하는 것은 두 기술과 호환되며, 더 큰 파일을 스팬 하는 데 필요한 블록 포인터들의 수를 또한 감소시킨다.)

따라서, 비어 있지 않은 파일의 디스크 상에서의 최소 크기는 4 킬로바이트이다. 이것은, 파일 메타데이터가 네임 스페이스 내에서 전체적으로 유지됨에 따라, 순수한 데이터 블록 저장소이다.

유니크한 익스텐트 ID(EID)는 데이터 스페이스 내의 익스텐트를 식별하며, 클라이언트 또는 다른 하이퍼 서버는 물론 데이터 스페이스를 관리하는 하이퍼 서버 내부로부터의 익스텐트의 어드레싱을 허용한다. EID는 다음의 필드들을 포함하여 그것을 포함하는 하이퍼 볼륨의 불명료한 스칼라로서 취급되는 8 바이트의 구조이다.

익스텐트가 할당된 하이퍼 볼륨의 하이퍼 서버 (HID). 이것은 익스텐트를 전면적으로 유니크하게 만들며 전체 하이퍼 파일러 내에서 어드레스 가능하게 만든다.

포함하는 하이퍼 볼륨 내에서의 익스텐트의 스타팅 블록의 논리적인 블록 오프셋. 이것은 하이퍼 볼륨 내의 스타팅 블록의 논리적인 블록 인덱스를 직접적으로 식별한다.

익스텐트가 스팬 하는 논리적인 블록의 카운트. 이것은 캐시 매니저가 익스텐트 내에서 읽혀질 캐시 내에 얼마나 많은 메모리가 이용 가능한지를 알게 해 준다.

단일 익스텐트는 최대 4 메가바이트를 커버한다. 익스텐트에 대한 액세스가 이루어지면, 익스텐트는 전체적으로 판독된다. 이것은 4 메가바이트 미만의 파일은 단일 디스크 입/출력 동작을 통해 판독될 수 있음을 의미한다. 이것은 입/출력 서브시스템의 효율을 크게 상승시킨다. 익스텐트는, 최근 최소 사용(LRU) 알고리듬이 스페이스가 리클레임되는(reclaimed) 것을 요구할 때까지 캐시 내에서 유지되며, 캐시는, 순차적인 액세스가 검출될 때, 읽기 요청이 수신되기 전에 후속하는 익스텐트가 읽어 들여질 수 있도록 자유페칭(prefetching)을 구현한다. (이것은 하이퍼 파일러 내의 주된 액세스 모드이다.)

다수의 익스텐트들을 스팬 하는 파일들의 경우, 순방향으로 고속 검색을 수행할 수 있도록, 첫 번째 익스텐트는 모든 파일 익스텐트들의 맵을 또한 저장한다. 초기 익스텐트가 익스텐트 캐시로부터 제거될 필요가 있는 경우, 익스텐트 맵에 사용되는 면적은, 파일이 닫혀질 때까지, 메모리 내에서 유지된다. 익스텐트 맵은 전형적인 유닉스 파일 시스템 i-노드(i-node) 내에서 블록 포인터들의 맵과 유사하게 구성된다. 이것은 처음의 몇몇 익스텐트들이 직접적으로 향하게 되는 반면, 후속하는 익스텐트들은 이중의 인디렉션을 야기하고, 매우 큰 파일들의 경우 삼중의 인디렉션을 야기하는 불균형 트리 타입 구조이다.

각각의 파일 익스텐트는, 익스텐트가 기록될 때마다 계산되는, 익스텐트에 대해 20 바이트 SHA-1 핑거프린트를 또한 포함한다. 이 개별적인 익스텐트 핑거프린트는 익스텐트의 인테그리티의 검증을 허용한다. 파일의 첫 번째 세그먼트는 개개의 익스텐트들의 모든 핑거프린트들을 또한 계산한다. 이러한 전체적인 핑거프린트는, 파일 길이와 함께, 파일 인스턴스에 대해 유니크한 ID를 결국 제공할 수 있다. 이것은 두 가지 방법으로 사용된다. 전체 파일의 인테그리티를 검증하기 위해 사용되며, 미래에 시스템을 공개할 때 파일 레벨의 중복 제거(deduplication)를 구현하게 된다.

익스텐트들에 대한 쓰기는, 파일의 타입이 이것을 무의미하게 만들지 않는 한, 익스텐트의 내용을 최초로 압축한 후에, 수행된다. 구성 퍼실리티는, 이 결정 단계에서, 가상적으로 압축될 수 없는 파일들이 중앙 처리 장치(CPU) 사이클들을 낭비하는 것을 방지하는 데 도움을 준다. 이와 유사하게, 파일 시스템으로부터의 데이터 판독은, 그것이 사용되기 전에, 압축 해제된다. 고객들은 이러한 거동이 중앙 처리 장치(CPU) 사이클 동안 데이터 스페이스를 트레이드 오프하는 것을 가능하게 할 수 있다. 데이터 스페이스 및 데이터 스페이스를 지원하는 데이터 저장소에 대한 더욱 상세한 내용이 참조된다.

클라이언트 요청들의 관리

일단 클라이언트가 하이퍼 파일러 내에서 이용 가능한 루트 디렉토리를 (또는 다른 디렉토리를) 마운트 하면, 하이퍼 파일러는, 요청 클라이언트에 주어진 액세스 보호 특권에 따라, 마운트 된 디렉토리 아래에서 이용 가능하게 만드는 파일들 및 디렉토리들에 액세스하는 것이 허용된다.

클라이언트와 하이퍼 파일러 간의 전형적인 대화는 다음과 같은 방식으로 이루어진다. 이 예는 열기, 읽기, 쓰기, 및 닫기 콜들이 어떻게 작용하는지는 보여준다.

클라이언트가 하이퍼 파일러의 마운트 포인트 하에서 파일을 열고자 하는 경우, 클라이언트는 마운트 시에 수신하는 디렉토리 해시 테이블(DHT)을 통해 파일 네임을 국부적으로 해시하여 그 이름에 대해 책임이 있는 하이퍼 서버의 하이퍼 서버 ID (HID)를 검색한다.

그런 다음, 클라이언트는 하이퍼 파일러 네트워크 레이어에 열기 요청을, 이전 단계에서 HID가 검색되는, 네임 스페이스 하이퍼 서버에 전송할 것을 요구한다.

클라이언트 상의 하이퍼 파일러 네트워크 레이어는 HID를 타겟 네임 스페이스 하이퍼 서버의 하이퍼 서버 멤버들(HMs)의 어드레스들에 맵핑한다. 이 때, 네트워크 레이어는 요청이 파일을 여는 것인지, 읽는 것인지, 또는 쓰는 것인지에 따라 다르게 행동한다. 읽기를 위한 열기의 경우, 타겟 네임 스페이스 하이퍼 서버 내의 하이퍼 서버 멤버(HM)는 요청을 처리할 수 있다. 따라서, 클라이언트는 (요청들을 분산하기 위하여) 임의의 방식으로 하나의 하이퍼 서버 멤버(HM)를 선택하고 그 하이퍼 서버 멤버(HM)에 요청을 전송한다. 쓰기를 위한 열기의 경우, 네임 스페이스 하이퍼 서버의 프라이머리 하이퍼 서버 멤버(HM)는 요청을 처리하여야 한다. 따라서, 클라이언트는 요청을 프라이머리 하이퍼 서버 멤버(HM)로 전송한다.

성공적이라면, 네임 스페이스 하이퍼 서버의 하이퍼 서버 멤버(HM)는 파일을 저장하는 데이터 베이스 하이퍼 서버를 또한 향하는 파일에 대한 EID를 포함하는 레코드를 검색한다.

네임 스페이스 하이퍼 서버 멤버(HM)는 읽기를 위한 열기와 쓰기를 위한 열기를 구별함으로써 파일 데이터로의 액세스를 제공하여야 하는 데이터 스페이스 하이퍼 서버의 하이퍼 서버 멤버(HM)를 또한 선택한다. 네임 스페이스 하이퍼 서버 멤버(HM)는 적절한 데이터 스페이스 하이퍼 서버 멤버(HM)를 선택한다. 쓰기를 위한 열기 이후의 열기와 쓰기의 경우에는, 선택된 데이터 스페이스 하이퍼 서버 멤버(HM)가 하이퍼 서버 프라이머리 멤버가 된다.

네임 스페이스 하이퍼 서버의 하이퍼 서버 멤버(HM)는, (파일을 저장하는 데이터 베이스 하이퍼 서버로 또한 향하는) 파일에 대한 EID를 포함하는 레코드를 단계 5에서 선택한 데이터 베이스 하이퍼 서버 멤버(HM)와 함께 반송함으로써, 클라이언트 요청에 응답한다. 동시에, 클라이언트로부터의 후속하는 입/출력 요청이 데이터에 액세스하기 위해 필요한 시간을 최소화할 수 있도록, 파일을 캐시 내로 가져와야만 한다는 것을 데이터 스페이스 하이퍼 서버의 하이퍼 서버 멤버(HM)에 또한 경고한다.

데이터 스페이스 하이퍼 서버 멤버(HM)가 후속하는 읽기 요청에 응답하지 않으면, 읽기를 위한 열기의 경우, 에러를 처리하기 위하여, 클라이언트는 랜덤하게 또 다른 하이퍼 서버 멤버(HM)를 선택할 수 있다. 다른 한편으로, 쓰기를 위한 열기의 경우, 클라이언트는 데이터 스페이스 프라이머리 멤버가 응답하기를 기다릴 필요가 있다 (원래의 프라이머리 멤버가 더 이상 이용 가능하지 않은 경우, 데이터 스페이스 하이퍼 서버의 재구성이 필요할 수도 있다).

최종적으로, 클라이언트는 단계 3에서 선택한 네임 스페이스 하이퍼 서버 멤버(HM)에 닫기 요청을, 요청들을 수행한 데이터 스페이스 하이퍼 서버 멤버(HM)의 SID와 함께, 전송한다. 이는 단계 7에서 설명한 바와 같이 네임 스페이스 하이퍼 서버 멤버(HM)가 선택한 것에 대해 후자가 변경될 수도 있었기 때문이다. 네임 스페이스 하이퍼 서버 멤버(HM)는 이전의 입/출력 요청들을 처리한 이터 스페이스 하이퍼 서버 멤버(HM)에 닫기 요청을 전달하고, 이로써 대화는 종결된다.

이 모든 경우에, 선택이 어디에서 수행되든지 간에 데이터 스페이스 상의 하이퍼 서버 멤버들(HMs)의 선택이 일관성이 있도록 보드에 걸쳐 동일한 알고리듬들이 적용되는 것이 중요하다.

이하에서는, 종래의 전형적인 네트워크 연결 저장(NAS) 시스템 상에서의 입/출력 동작들의 몇몇 특정 예들과 하이퍼 파일러의 사용에 대해 설명하기로 한다.

도 2는 4 개의 디렉토리 레벨들을 포함하는 경로 이름을 갖는 파일에 액세스하기 위한 종래의 네트워크 연결 저장(NAS) 시스템의 특징을 잘 나타내는 디스크 및 네트워크 입/출력 동작들을 예시하는 도면이다. 양호한 디렉토리 액세스 속도를 위해 전형적으로 4 개의 디렉토리 레벨들을 제공하는 것이 바람직하다. 여기서, 경로는 "/mnt/netapp/a/b/c/d/E"이고, 경로에 따른 각각의 단계는 중요한 행위를 요구한다. 단계 1에서는, 루트로 가서 i-노드(i-node)를 읽을 필요가 있다. 단계 2에서는, 루트 데이터가 "a"의 i-번호를 검색하고 그 핸들을 반송하기 위하여 사용된다. 단계 3에서는, 핸들이 "a"를 탐색하고 "a"의 i-노드를 읽기 위하여 사용된다. 단계 4에서는, 검색된 데이터가 "b"의 i-번호를 검색하고 그 핸들을 반송하기 위하여 사용된다. 단계 5에서는, "b"의 핸들이 그의 i-노드를 읽기 위하여 사용된다. 단계 6에서는, 검색된 데이터가 "c"의 i-번호를 검색하고 그 핸들을 반송하기 위하여 사용된다. 단계 7에서는, "c"의 핸들이 그의 i-노드를 읽기 위하여 사용된다. 단계 8에서는, 검색된 데이터가 "d"의 i-번호를 검색하고 그 핸들을 반송하기 위하여 사용된다. 단계 9에서는, "d"의 핸들이 그의 i-노드를 읽기 위하여 사용된다. 단계 10에서는, 검색된 데이터가 "E"의 i-번호를 검색하고 그 핸들을 반송하기 위하여 사용된다. 단계 11에서는, "E"의 핸들이 "E"의 데이터를 읽고 "E"의 데이터를 반송하기 위하여 사용된다. 이들 동작들을 위한 디스크 입/출력의 전체 횟수는 10이고, 6 개의 네트워크 입/출력 동작들이 제공된다.

도 3은 도 2와 동일한 경로 이름을 갖는 파일에 액세스하기 위한 본 발명의 일 실시예에 따른 하이퍼 파일러에 의해 요구되는 디스크 및 네트워크 입/출력 동작들을 예시하는 도면이다. 이 경우, 클라이언트는 해시 테이블(301)을 저장한다. 단계 1에서, 클라이언트는 경로 이름의 해시(301a)를 결정하고, 해시 테이블(301)에 액세스하고, 클라이언트가 저장 요청을 제공할 수 있는 관련 네임 스페이스 하이퍼 서버를 식별하는 네임 스페이스 하이퍼 서버 ID(301b)를 획득한다. 단계 2에서, 클라이언트는 핸들(302b)과 관련 데이터 스페이스 하이퍼 서버의 ID를 클라이언트에 반송하는 식별된 네임 스페이스 하이퍼 서버에 파일 열기 요청(302a)을 수행한다. 단계 3에서, 클라이언트는 식별된 데이터 스페이스 하이퍼 서버에 읽기 요청(303a)을 수행하고, 그에 대한 응답으로서 식별된 데이터 스페이스 하이퍼 서버로부터 데이터(303b)를 획득한다. 이들 동작들에 있어서는, 단일 디스크 입/출력 동작이 제공되고, 단지 2 개의 네트워크 입/출력 동작들이 제공된다.

도 3은 스토리지 읽기를 예시한 것인 반면에, 도 4는 스토리지 쓰기를 예시한다. 도 4는 경로 이름이 "x/y/z012345678"인 파일을 생성하기 위한 본 발명의 일 실시예에 따른 하이퍼 파일러 내에서의 동작들을 예시하는 도면이다. 도 4에서, 클라이언트는 초기에 경로 이름의 해시를 형성하고 저장된 해시 테이블(402)를 사용하여 저장 요청을 하기 위하여 어떤 네임 스페이스 하이퍼 서버를 사용하여야 하는지를 결정한다. 이 예에서, 네임 스페이스 하이퍼 서버(HS0)에 요청을 하는 것으로 결정한다. 또한, 이 예에서, 네임 스페이스 하이퍼 서버(HS0)는 프라이머리 멤버(421) 및 세컨더리 멤버(422)를 포함한다. 프라이머리 멤버는 저장 요청을 획득하고, 단계 1에서는, 이 요청에 네임 스페이스 엔트리(35)를 할당하고, 이 엔트리 내에 경로 데이터를 저장하고, 네임 스페이스 엔트리(35)를 잠근다. 이와 유사하게, 단계 2에서 프라이머리 멤버는 파일 테이블 엔트리(51)를 만들고, 단계 3에서 스트링 테이블 엔트리(66)를 만든다. 단계 4에서, 프라이머리 멤버는 시퀀스 번호(513)를 이 쓰기 요청에 할당하고, (프라이머리 멤버(431) 및 세컨더리 멤버(432)를 포함하는) 데이터 스페이스 하이퍼 서버(HS2)를 이용하여 이 시퀀스 번호를 디스크로 전송한다. 또한, 프라이머리 멤버는, 네임 스페이스 엔트리(35)를 잠그는 명령을 포함하는, 시퀀스(513)와 파일 테이블 엔트리(51) 및 스트링 테이블 엔트리(66)의 데이터에 관한 리포트를 세컨더리 멤버(422)에 전송한다. 단계 5에서, (단계 4에서 전송된 명령들을 수행하고 후속하여 시퀀스가 시작될 때 잠겨진 노드 엔트리(35)의 잠금을 해제한) 세컨더리 멤버(422)로부터 애크날리지먼트를 수신한 후에, 프라이머리 멤버는 네임 스페이스 엔트리(35)의 잠금을 해제한다. 단계 6에서, 프라이머리 멤버는 데이터 스페이스 하이퍼 서버(HS2)로부터 익스텐트 ID를 요청하고, 클라이언트에 생성 요청이 완료되었음을 또한 보고하고, 네임 스페이스 하이퍼 서버(HS0)와의 추가적인 대화 없이 데이터 스페이스 하이퍼 서버(HS2) 상에서 읽기와 쓰기를 수행하기 위하여 클라이언트가 사용할 수 있는 핸들을 클라이언트에 반송한다.

도 4에서는 파일이 생성될 때 네임 스페이스 엔트리(35)를 잠그는 것을 설명하였지만, 다양한 실시예에 있어서, (1) 동일한 시간에 동일한 디렉토리 상에서 다른 동작들이 수행되는 것을 방지하고, (2) 부모 디렉토리 노드가 새로운 파일을 나타내는 새로이 생성된 아이(child) 노드로 향하도록, 네임 스페이스 내의 부모 디렉토리를 나타내는 노드에 대한 추가적인 잠금(lock)이 제공된다. 파일 동작이 단지 존재하는 파일의 속성을 변경하는 것이라면, 부모 디렉토리의 잠금은 요구되지 않으며, 따라서 오직 영향을 받는 노드만이 잠궈질 필요가 있다. 위에서 언급한 부모 디렉토리의 경우처럼 추가적인 노드들이 잠궈질 필요가 있는 경우, 그러한 잠금을 위한 명령은 단계 4에서 네임 스페이스 하이퍼 서버 프라임 멤버(421)가 세컨더리 멤버들 (예를 들어, 세컨더리 멤버(422))에 전송하는 명령들의 일부이다.

III. 동작 거동

이 섹션에서는 하이퍼 파일러의 표준 거동을, 시스템 인테그리티, 장애, 및 데이터 복구를 자동적으로 처리할 수 있도록 이용 가능하게 된 퍼실리티들과 함께, 설명한다.

시스템 설정 및 관리

하이퍼 파일러는 약 10 분만에 하이퍼 파일러가 구성될 수 있도록 하고 새로운 하이퍼 서버 멤버들(HMs)이 5 분 미만의 시간에 추가될 수 있도록 하는 단순한 그래픽 유저 인터페이스(GUI)를 통해 관리된다.

하이퍼 파일러의 시스템 매니지먼트 컴포넌트는, 관찰하고 경보를 발하는 것을 포함하여, 시스템을 자동적을 관리하는 데 필요한 모든 서버 측 기능들을 수행한다.

하이퍼 파일러 설정은 초기에 하이퍼 파일러에 하이퍼 서버 멤버들(HMs)을 할당함으로써 달성된다. 구성 상태에서, 각각의 하이퍼 서버 멤버(HM)가 존재하는 물리적인 서버를 또한 식별하는 것이 중요하다. 어떤 하이퍼 서버 멤버들(HMs)이 동일한 하이퍼 서버의 멤버가 되기에 좋은 후보들인지를 시스템 매니지먼트가 알도록 하기 때문에, 이것은 정보의 중요한 부분이다. 단일 장애점(SPOF)를 피하기 위하여, 각각의 하이퍼 서버는 별개의 물리적 노드들에 호스트되는 하이퍼 서버 멤버들(HMs)로 구성되어야 한다.

동일한 스토리지 티어 내에서 사용되는 하이퍼 서버 멤버들(HMs)은 (램, 중앙 처리 장치(CPU), 및 네트워크 능력의 관점에서) 비교될 수 있는 하드웨어 상에서 동작하고, 동일한 종류의 스토리지(스토리지 에어리어 네트워크들(SANs), 로컬 드라이브들 등)에 기초하고, 비교될 수 있는 물리적 볼륨들을 관리하는 것이 중요하다. 여기에서의 주요 차이점은 실제로 가장 약한 컴포넌트의 성능에 대해 하이퍼 서버의 성능을 낮춤으로써 성능 문제를 야기할 수 있다는 것이다.

시스템 매니지먼트는, 단일 장애점들(SPOFs)이 회피될 수 있도록 함으로써 하이퍼 서버들을 한데 모은다. 시스템 매니지먼트는 동일한 용량 및 능력을 갖는 하이퍼 서버 멤버들(HMs)를 그룹화할려고 또한 노력한다.

통상적인 시스템 동작

하이퍼 파일러를 사용하기를 원하는 리눅스(Linux) 클라이언트들은 커널 로더블 모듈을 로드할 필요가 있다. 커널 로더블 모듈은 리눅스 시스템이 동작함에 따라 로드될 수 있고 언로드될 수 있다. 언로드 동작은 단지 클라이언트가 하이퍼 파일러에 액세스하는 것을 중단하고 그것을 "언마운트"할 때에만 허용된다 (이하 참조).

커널 모듈이 로드되어 액티브 상태가 되면, 네트워크 파일 시스템(NFS)에서처럼, 클라이언트는 로컬 파일 시스템 내의 비어 있는 디렉토리 (마운트 포인트) 상에서 마운트 동작을 수행할 수 있다. 그 후에, 경로 이름이 마운트 포인트 아래에 도달하는 파일들 또는 디렉토리들로의 액세스는 하이퍼 파일러 내의 적절한 파일 시스템 오브젝트에 경로 이름을 맵핑하는 커널 모듈을 필요로 한다. 이 프로세스는 어플리케이션들에는 명백하다. 동일하거나 다른 하이퍼 파일러들에 대한 다수의 마운트 포인트들이 동일한 클라이언트 내에서 공존할 수 있고 클라이언트는 하이퍼 파일러들은 물론 네트워크 파일 시스템(NFS) 파일러 디렉토리들을 마운트할 수 있음에 주목할 필요가 있다.

앞서 설명한 포직스(POSIX) 시맨틱스에 대한 사소한 제한들이 그러한 액세스들에 적용된다. 가장 명백하게는, 파일이 닫혀서 파일의 현재의 버전이 될 때까지 후속하는 요청들이 에러(EBUSY 에러)를 반송하면서 쓰기를 위한 최초의 읽기가 이루어진다는 점에서, 다수의 스레드들은 동일한 파일에 대해 허용되는 동시의 쓰기 액세스가 아니다. 다른 한편으로, 쓰기를 위해 파일이 열리면서 읽기를 위해 열리는 동작들은 파일의 이전 버전을 자동적으로 참고한다.

하이퍼 파일러가 포직스(POSIX) 시맨틱스를 구현한다는 사실은 클라이언트 상에서 실행되고 하이퍼 파일러 내의 파일들 및 디렉토리들에 액세스하는 어플리케이션들이 변화없이 실행된다는 것을 암시한다.

하이퍼 파일러는 파일들에 대한 HTTP/HTTPS 액세스를 또한 가능하게 한다. 이를 위해, 이 프로토콜을 지원하는 컴포넌트가 하이퍼 파일러 내에서 실행되고, 각각의 하이퍼 파일러는 서브도메인(subdomain) 서버를 실현한다. 따라서, 하이퍼 파일러가 지원하도록 구성된 서브도메인들에 상대적인 이름들을 참조하는 요청들이 직접적으로 HTTP/HTTPS 컴포넌트에 전달된다. 서브도메인 매니저는 전체 하이퍼 파일러에 걸쳐 로드를 분산시키기 위해 이용 가능한 모든 그러한 컴포넌트들에 걸쳐 도입되는 요청들을 순차적으로 제공한다(round-robbin). 그러나, 보편적인 리소스 로케이터(URL)의 해석에 있어서, 서브도메인 서버는 관심의 대상이 되는 오브젝트를 관리하는 하이퍼 서버에 의해 요청들이 처리되도록 노력을 한다.

시스템의 미래 버전들은 유사한 방식으로 네트워크 파일 시스템(NFS) 액세스를 지원할 것이다. 미래의 하이퍼 파일러 버전 또한 고유한 하이퍼 파일러 프로토콜을 사용하는 윈도우즈 리디렉터(redirector)를 지원함으로써 윈도우즈 클라이언트들을 지원할 것이다.

에러 검출 및 복구

하이퍼 파일러는 분산된 파일 시스템 내의 파일들 및 디렉토리들의 인테그리티를 관찰하며, 일어날 수도 있는 불일치를 검출할 수 있다. 국부적인 불일치는 즉시 처리된다. 예를 들어, 하이퍼 서버의 멤버가 파일을 읽는 중에 입/출력 에러를 검출하는 경우, 파일 익스텐트가 불량(bad)하다고 즉시 표시하고, 하이퍼 서버의 또 다른 멤버에게 요청을 완료할 것을 요구하고, 파일의 내용을 유효한 카피를 갖는 멤버의 내용과 재동기화한다.

하이퍼 볼륨 및 하이퍼 서버의 복원

하이퍼 서버의 멤버가 하이퍼 볼륨 인스턴스 내의 불일치를 검출하는 경우, 불일치의 본질에 따라 달리 동작할 수 있다. 앞서 설명한 바와 같이, 사소한 불일치는 즉시 처리되어야 한다. 그러나, 네임 스페이스의 내용 또는 데이터 스페이스의 내용이 절충되는 경우, 하이퍼 서버 멤버(HM)는 완전한 하이퍼 볼륨 재동기화를 수행하여야 한다. 새로운 하이퍼 서버 멤버(HM)가 하이퍼 서버에 할당될 때 동일한 상황이 발생된다.

동작은 두 단계로 이루어진다.

첫 번째 단계는, 존재하는 것으로 추정되고 네임 스페이스 재동기화가 필요한 경우, 네임 스페이스를 재동기화하는 것이다. 이것은 하이버 서버 프라이머리 멤버 상에서 이용 가능한 지속적인 이미지 내에 저장된 것과 같은, 네임 스페이스 내용을 복사하는 것을 수반한다. 프로세스의 끝 부분에서, 프라이머리 멤버는, 새로운 하이퍼 서버 멤버(HM)가 완전히 동기화될 때까지 도입되는 업데이트 요청들을 잠깐 보유한다. 그 후에, 새로운 멤버가 인에이블되는 것처럼 업데이트 요청들이 인에이블된다. (네임 스페이스 내에서 이것이 어떻게 달성되는지에 대한 상세한 내용은 상기한 "새로운 멤버들의 초기화" 부분에 기재되어 있다.)

두 번째 단계는, 복구되는 하이퍼 서버에 대해 존재하는 경우, 데이터 스페이스의 유사한 태스크를 달성한다.

첫 번째 단계는, 복구되는 두 저장소들의 상대 크기 때문에, 두 번째 단계보다 확실히 빠르다는 점에 주목할 필요가 있다. 그럼에도 불구하고, 새로운 멤버는, 단계 1의 끝 부분에서, 네임 스페이스가 완전히 복구되자마자 요청에 대한 서비스를 시작할 수 있다. 단계 2가 완료될 때까지, 새로운 하이퍼 서버 멤버(HM)는 데이터 스페이스를 필요로 하는 요청들에 응답하지 않고, 대신에 다른 하이퍼 서버 멤버가 응답하도록 한다.

하이퍼 서버의 모든 멤버들이 나가 버리거나 충돌하는 경우, 그 하이퍼 서버에 의해 지원되는 파일 시스템 오브젝트들은 이용이 불가능한 상태가 된다. 이러한 이유로, 적절한 리던던시를 갖도록 시스템을 구성하는 것이 매우 바람직하다. 이러한 경우, 시스템 매니지먼트는 하이퍼 볼륨이 이용 가능성이 높은 블록 스토리지에 의존하는 경우 또는 리던던시가 로컬 하드 드라이브들의 상부에서 하이퍼 파일러에 의해 구축되는지의 여부 사이에서 달리 동작한다.

첫 번째 경우에는, 시스템 매니지먼트는 이용 가능한 하이퍼 서버 멤버들(HMs) 밖에서 단지 새로운 하이퍼 바이저를 제조하여야 하고 그것을 하이퍼 서버가 소유하고 있는 여분의 스토리지 자원들에 할당하여야 한다.

그러나, 스토리지가 여분이 없는 로컬 스토리지의 복제를 통해 구현되는 경우, 시스템은 원래의 하이퍼 바이저 멤버들 중 하나가 재시작되기를 기다리고, 그런 다음 네임 스페이스 상에서 리던던시를 재구축하고 이용 가능한 카피로부터 데이터의 리던던시를 재구축한다.

스토리지 티어들 사이의 이동

다수의 스토리지 티어들이 하이퍼 파일러 내에 존재하고 이 특징이 인에이블되는 경우, 시스템은 파일들로의 액세스들을 관찰한다. 고객은 파일 이동 창으로 불리는 참조 시간 창을 설정하는 것이 허용된다. 주기적으로 시스템은 각각의 하이퍼 서버 내의 네임 스페이스를 주시한다. 주어진 파일이 마지막 이동 창 내에서 참조되지 않았다면, (존재한다면) 하위 스토리지 티어로 이동하게 된다. 인에이블 되면, 시스템은 또한 하위 티어 내의 파일이 참조될 때 파일들이 상위 스토리지 티어로 이동하도록 하여, 파일들이 속해야 하는 스토리지 티어들 내에 파일들을 유지한다.

스크러빙(scrubbing) 및 스캐빈징(scavenging)

데이터가 한번 쓰여지면 비트로트 및 섹터의 열화가 일어날 수 있다. 이러한 이유로, 시스템은 현재의 데이터에 대한 스크러빙을 수행한다. 각각의 하이퍼 서버 내의 프라이머리 멤버는 모든 멤버 상에서의 각각의 하이퍼 볼륨의 데이터 부분과 네임 스페이스를 스캐닝하여 그들이 동기되도록 함으로써, 오염된 데이터가 없고 오동작으로 인하여 고아가 되지만 삭제되지는 않는 데이터가 제거되도록 한다.

이것은 집중적인 입/출력 행위이며, 하이퍼 서버들의 전반적인 성능에 대해 결국 영향을 미칠 수 있다. 따라서, 시스템이 진행 중에 입/출력의 양을 끊임없이 얻어내기 때문에, 시스템이 과도하게 로드되지 않을 때에만 이것이 발생하도록 할 수 있으며, 중앙 처리 장치(CPU), 램, 디스크, 및 네트워크 대역폭의 미리 구성된 비율이 초과되지 않게 발생하도록 할 수 있다.

하이퍼 파일러의 확장 및 업그레이드

그 구성으로 인하여, 하이퍼 파일러는 본질적으로 확장 가능하다. 추가적인 스토리지가 필요하거나 추가적인 성능이 요구될 때마다, 동적으로, 즉 진행중인 동작들을 중단시키지 않으면서, 하이퍼 파일러에 새로운 하이퍼 서버 멤버들(HMs)을 추가할 수 있다.

이렇게 할 경우, 다음과 같은 기준들이 예상된다.

주어진 스토리지 클래스에 추가될 하이퍼 서버 멤버들(HMs)의 수는 그 클래스의 카디날리티의 배수이어야 한다. 주어진 스토리지 티어에 추가되는 하이퍼 서버 멤버들(HMs)은 램과 이용 가능한 스토리지의 관점에서 유사한 구성을 가져야 하며, 유사한 파워를 가지고 중앙 처리 장치들(CPUs) 상에서 실행되어야 한다.

동일한 하이퍼 서버의 멤버들이 동일한 머신 상에서 실행되는 환경들을 피하기 위하여, 하이퍼 서버 멤버(HM)가 호스트되는 서버의 설명은 항상 정확하여야 한다. 이에 의해 실제로 하이퍼 서버 멤버(HM) 레벨의 리던던시가 존재하지 않을 수도 있다.

또한 스토리지 티어 내의 카디날리티의 증가는 동일하게 처리될 수 있음에 주목할 필요가 있다. 또한, 하이퍼 파일러의 고유한 리던던시를 사용함으로써, 진행중인 동작들을 중단시키지 않으면서 업그레이드들을 수행할 수 있다. 기본적으로, 한 번에 하나의 하이퍼 서버 멤버(HM)가 업그레이드 되며, 따라서 이 프로세스가 수행됨에 따라 하이퍼 서버 멤버들이 속하는 하이퍼 서버가 계속해서 동작하는 것이 허용된다.

본 실시예에 있어서의 제약 및 제한

하이퍼 파일러의 구성은 매우 일반적이며, 많은 배치 변화를 수용할 수 있다. 그러나, 초기 공개를 위한 개발을 단순화하기 위하여, 가능한 조합의 수를 줄이는 것이 바람직하다. 이하에서는 이러한 제한에 대해 논의한다.

하이퍼 볼륨들 및 하이퍼 서버들

네임 스페이스 서비스 및 데이터 스페이스 양쪽을 지원하는 하이퍼 서버 멤버들(HMs)를 구현함에 있어서, 특히 하이퍼 서버 멤버들(HMs)를 하이퍼 서버에 한데 모을 것으로 예상되는 시스템 매니지먼트의 경우, 배치를 단순화한다. 그러나, 스토리지 에어리어 네트워크들(SANs) 또는 스토리지 에어리어 네트워크(SAN)와 유사한 인프라스트럭처를 통해 제공되는 논리 단위 번호들(LUNs)은 물론 직접 연결 하드 드라이브들을 사용할 필요가 있기 때문에 (이러한 경우는 직접 접근 기억 장치(Directly Attached Storage Device)의 약자인 "DASD"를 포함하는 것으로 언급된다), 몇 가지 복잡한 상태가 발생하고, 이는 다음과 같은 사항에 의해 야기된다.

스토리지 에어리어 네트워크(SAN) 상에서의 논리 단위 번호들(LUNs)은 일반적으로 이용 가능성이 높아서, 데이터 스페이스에 대한 복제를 제공할 때 고유의 값이 존재하지 않는다. 논리 단위 번호들(LUNs)은 이미 리던던시를 제공하고 하이퍼 서버들을 통한 추가적인 복제가 필요하지 않기 때문에, 실제로 이것은 스토리지의 낭비이다.

네임 스페이스는, 적어도 2로 설정된 카디날리티를 갖는 하이퍼 서버를 사용함으로써, 항상 복제되어야 한다. 이것은, 하이퍼 서버 멤버(HM)가 재시작될 때 네임 스페이스의 특정 부분들이 일시적으로 액세스 가능하지 않게 될 가능성을 현저히 감소시키기 때문에, 바람직하다. 더욱이, 이것은 네임 스페이스 로드가 다수의 하이퍼 서버 멤버들(HMs)에 걸쳐 공유되는 것을 허용한다. 이러한 고려 사항들이 직접 접근 기억 장치(DASD) 스토리지 및 여분의 논리 단위 번호들(LUNs) 양쪽에 적용된다.

논리 단위 번호들(LUNs)의 경우, 네임 스페이스가 복제되도록 하는 반면에, 데이터 스페이스는 하이퍼 파일러 내에서 복제되지 않는다. 이것은, 직접 접근 기억 장치(DASD) 기반 구현의 경우에 양쪽 서비스가 복제로부터 이익을 얻기 때문에, 명확히 스토리지 에어리어 네트워크(SAN) 기반 구현과 직접 접근 기억 장치(DASD) 기반 구현 사이의 여건이 나뉘어진다는 점을 나타낸다. 하이퍼 서버 멤버들(HMs)을 독점적으로 네임 스페이스 서비스 또는 데이터 스페이스 서비스에 사용하는 것은, 각각의 개별적인 하이퍼 서버 멤버(HM)의 경우에 커널에 의해 사용되는 램이 증가되기 때문에, 일부 하이퍼 서버 멤버들(HMs)이 양쪽을 호스트할 때보다 더 많은 램을 차지할 수 있다. 그러나, 그러한 서비스의 분리는 몇 가지 이익을 또한 가질 수 있다. 예를 들어, 직접 접근 기억 장치(DASD) 기반 구성 및 스토리지 에어리어 네트워크(SAN) 기반 구성을 동일한 방식으로 처리함으로써 하이퍼 서버 멤버들(HMs)의 생성 및 관리를 단순화한다. 네임 스페이스 서비스가 갖는 문제점이 동일한 하이퍼 서버 멤버(HM) 내에서 함께 호스트될 수 있는 데이터 스페이스 서비스에 나타나지 않도록 더욱 양호한 결점 격리를 제공한다. 하나의 하이퍼 서버 멤버(HM) 내에서 필요로 하는 커널 데이터의 양은 하이퍼 서버 멤버(HM)에 의해 실행되는 서비스들의 수 및 복잡성과 엄밀하게 연관된다. 개략적으로 말해서, 주어진 서비스에 의해 필요한 커널 램의 양은 서비스가 하나의 하이퍼 서버 멤버(HM) 내에서 분리되는지 아닌지에 상관없이 거의 같다고 예상할 수 있다. 최종적으로, 커널 이미지의 크기와 각각의 하이퍼 서버 멤버(HM) 내에서 사용되는 실행 가능한 것들을 최소화할 수 있으며, 메모리 요건을 또한 낮추는, 커널 코드 페이지들이 하이퍼 서버 멤버들(HMs)에 걸쳐 공유될 수 있음을 하이퍼 바이저에 알릴 수 있다. 상기한 모든 고려 사항으로 인하여, 하이퍼 파일러의 첫 번째 공개 시에, 각각의 하이퍼 서버 멤버(HM)가 네임 스페이스 서비스 또는 데이터 스페이스 서비스에는 사용되지만 양쪽에는 사용되지 않도록 하는 것이 합당하다고 생각된다.

각각의 하이퍼 서버 멤버(HM)의 구성

첫 번째 하이퍼 파일러의 공개 시에 각각의 하이퍼 서버 멤버(HM)가 네임 스페이스 서비스 또는 데이터 스페이스 서비스를 호스트 한다는 점에 기초하여, 다음의 기준이 자원의 할당을 선택함에 있어서 적용된다. 각각의 하이퍼 서버 멤버(HM)가 네임 스페이스 서비스를 실행하는 경우에는 10 기가바이트의 데이터 공간이 이용 가능하다. 각각의 하이퍼 서버 멤버(HM)가 데이터 스페이스 서비스를 실행하는 경우에는 가능한 한 많은 드라이브가 이용 가능하다. 각각의 하이퍼 서버 멤버(HM) 타입에 있어서는, 루트 파일 시스템의 공간의 적절한 양과 스왑(swap) 면적이 이용 가능하다. 각각의 하이퍼 서버 멤버(HM)가 실행하는 서비스에 의해 사용될 각각의 하이퍼 서버 멤버(HM)에 대해 약 1.5 내지 2 기가바이트의 램이 이용 가능하다. 각각의 하이퍼 서버 멤버(HM) 커널에 대해 약 800 메가바이트가 이용 가능하다. (이것은 최대치이다. 가능하다면, 필요한 컴포넌트들의 양을 감소시키고 하이퍼 서버 멤버들(HMs)에 걸쳐 커널 코드 페이지들을 공유함으로써, 이 값은 더욱 감소되어야 한다.) 각각의 하이퍼 서버 멤버(HM)에 대해 코어의 대략 1/4이 사용된다. 각각의 드라이브에 대략 두 개의 하이퍼 서버 멤버들(HMs)이 할당된다.

결론

실시예들에 있어서, 하이퍼 파일러는 단일 네임 스페이스를 갖는 이용 가능성이 높은 스케일-아웃 파일 시스템을 구현한다. 이론상으로, 시스템은 웹-스케일 어플리케이션들을 목표로 하는 이용 가능성이 높은 공유 파일 저장 플랫폼으로서, 용량 및 성능의 관점에서 무한한 스케일러빌리티를 제공하고, 고유의 병목 현상을 해소하고, 단일의 디스크 입/출력 동작으로 랜덤하게 파일들을 열 수 있는 능력을 갖춘 저장 플랫폼을 제공하기에 적합하다. 이 마지막 특성만으로도 대부분의 파일들에 대해 10 배의 성능 향상을 수반하며, 드라이브 스핀들의 카운트가 현저하게 줄어든다. 네임 스페이스와 데이터 스페이스를 분리하게 되면, 이들 네임 스페이스와 데이터 스페이스가, SATA 드라이브들 또는 SSDs 등의 어플리케이션 환경에 가장 적합한 이차 매체 상에서 배치될 수 있다. 이러한 특성들을 갖는 파일 시스템은 현대 산업 표준 서버들의 컴포넌트들에 의존하는 트레이드-오프에 기초하며, 따라서 멀티 코어 중앙 처리 장치들(CPUs)의 이용 가능성, 다량의 램, 큰 네트워크 대역폭, 낮은 네트워크 레이턴시를 이용한다. 이 시스템의 이상적인 작업 부하는, 데이터베이스 타입 액세스가 필요하지 않은, 주된 읽기 동작들을 갖는 읽기-쓰기 트래픽으로 구성된다. 시스템은 포직스(POSIX) 표준을 따르며, 따라서 어플리케이션 개발자들이 벤더-지정 응용 프로그래밍 인터페이스들(APIs) 내로 속박되는 것으로부터 자유롭게 해주며 네트워크 파일 시스템(NFS)에 기초하는 기존의 어플리케이션들이 변경 없이 실행되는 것을 허용한다. 하이퍼 파일러가 단일 네임 스페이스 내에서 무한히 확장될 수 있다는 사실은 하이퍼 파일러가 거동하고 단일 실체로서 관리됨에 따라 고객이 모든 저장 장치에 이를 수 있도록 복잡한 마운트 맵들을 가지고 노력할 필요가 없다는 것을 의미한다. 사용되는 램의 양과 스왑 장치의 본질의 관점에서 네임 스페이스가 처리되는 유연성은, 지원되는 스토리지 티어들의 수 및 타입과 함께, 획득될 원하는 비용/성능비의 극도의 유연성을 허용한다.

하이퍼 파일러가 수천의 하이퍼 서버 멤버들(HMs)을 모아서 최대 4 개의 하이퍼 서버 멤버들(HMs)을 갖는 하이퍼 서버들을 구성한다. 업데이트들의 조정만이 단일 하이퍼 서버 내에서 수행될 필요가 있다. 따라서, 종래의 클러스터들 내에서의 선형성을 파괴하고 그들이 지원할 수 있는 노드들의 수를 구속하는 통신의 폭발적 증가가 하이퍼 파일러를 제한하지 않기 때문에, 시스템의 성능은 선형적으로 증가할 수 있다. 종래의 파일 이름과 포직스(POSIX) 시맨틱스의 사용은 어플리케이션 개발자가 파일 이름들을 통해 정보를 전하는 것을 허용한다. 이것은, 일부 레벨에서 이름들 및 속성들을 오브젝트 ID들에 옮기기 위하여 항상 외부 맵핑 레이어들에 의존할 필요가 있는 오브젝트 스토어들과 대비될 수 있다. HA 인프라스트럭처는 어플리케이션 층 내에 복제 특징들을 임베드할 필요를 해소한다. 하이퍼 서버 멤버들(HMs) 및 하이퍼 서버 멤버들(HMs)이 사용하는 저장 장치들에 의존함으로써, 사용자들은 특화된 장치들 또는 특별 하드웨어를 구입하지 않아도 된다. 대체로, 하이퍼 파일러와 같은 시스템, 특히 큰 스케일의 웹 어플리케이션을 위해 설계된 시스템은 시장 세그먼트가 요구하는 트레이드 오프를 달성할 수 있다. 하이퍼 파일러는, 그 혁신적인 기술 덕분에, 하이퍼 파일러가 주로 자동적으로 스스로를 관리함에 따라, 복잡성의 감소, 줄어든 획득 비용, 어플리케이션 및 인프라스트럭처 쪽에서의 줄어든 개발 비용, 줄어든 운영 비용의 관점에서 많은 절약을 달성한다. 시스템은 우수한 성능과 이용 가능성을 또한 제공한다.

Claims (18)

1. 다수의 논리 컴퓨터 시스템(logical computer system)들 내에 소프트웨어 정의 네트워크 연결 저장 시스템(software-defined network attachable storage system)을 설정하는 방법으로서, 각각의 시스템은 메모리(memory), 프로세서(processor), 및 저장 시스템을 가지며, 상기 방법은:
   제 1 세트(set)의 논리 컴퓨터 시스템들을 네임 스페이스(namespace) 내에서 동작하는 네임 스페이스 서버들로서 설정하고, 제 2 세트의 논리 컴퓨터 시스템들을 데이터 스페이스 서버들로서 설정하는 한 세트의 프로그램(program)들을 논리 컴퓨터 시스템들 내에서 실행하는 단계를 포함하며, 상기 제 1 세트의 논리 컴퓨터 시스템들은 적어도 두 대의 논리 컴퓨터 시스템들을 포함하고, 각각의 논리 컴퓨터 시스템은 네임 스페이스의 별개의 부분에서 자율적으로 동작하도록 구성되며,
   (i) 각각의 네임 스페이스 서버는 (a) 그 메모리 내에서, 파일(file) 및 디렉토리(directory) 이름들과 상기 파일 및 디렉토리 이름들과 결합된 사용자 데이터(data)가 존재하는 위치에 대한 정보를 포함하는, 파일 시스템 메타데이터(metadata)를 지속적으로 저장하고, 상기 파일 시스템 메타데이터의 동적으로 업데이트(update)된 카피(copy)를 그 저장 시스템 내에 저장하도록 구성되고, (b) 네임 스페이스의 사전 설정된 서브세트에 대해서 그 메모리 내에 지속적으로 저장되는 메타데이터에 기초하여 적어도 하나의 요청 클라이언트(client) 컴퓨터(computer)로부터의 저장 시스템 경로 이름 요청들을 처리하고, 각각의 요청에 응답하여 요청 클라이언트 컴퓨터의 의해 사용되기 위한 핸들(handle)을 반송하도록 구성되고, 따라서 모든 네임 스페이스에 대해서는 모든 네임 스페이스 서버들이 저장 시스템 경로 이름 요청들을 집합적으로 처리하며,
   (ii) 각각의 데이터 스페이스(dataspace) 서버는 직접적으로 상기 네임 스페이스 서버들에 의해 결정되고 상기 적어도 하나의 요청 클라이언트 컴퓨터로부터 수신되는 핸들들에 기초하여 그 저장 시스템 내에 사용자 데이터를 저장하고 검색하도록 구성되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
2. 제 1 항에 있어서,
   상기 네임 스페이스 서버들의 적어도 하나의 적절한 서브세트는 상기 네임 스페이스의 공유된 서브세트(subset)에 대해 클러스터(cluster)로서 동작하고, 저장 시스템 경로 이름 요청들을 처리하도록 구성되며, 상기 네임 스페이스의 공유된 서브세트의 파일 시스템 메타데이터는 상기 클러스터 내의 각각의 네임 스페이스 서버의 메모리 내에 지속적으로 존재하는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
3. 제 2 항에 있어서,
   상기 클러스터 내의 네임 스페이스 서버들의 수는 계획된 부하 조건들 하에서 소정 레벨(level)의 속도, 리던던시(redundancy), 및 이용 가능성을 달성할 수 있도록 선택되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
4. 제 1 항에 있어서,
   상기 데이터 스페이스 서버들의 적어도 하나의 적절한 서브세트는 상기 데이터 스페이스의 공유된 서브세트에 대해 클러스터로서 동작하고, 상기 네임 스페이스 서버들에 의해 결정되는 핸들들에 기초하여 그 저장 시스템 내에 사용자 데이터를 저장하고 검색하도록 구성되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
5. 제 4 항에 있어서,
   상기 클러스터 내의 데이터 스페이스 서버들의 수는 계획된 부하 조건들 하에서 소정 레벨의 속도, 리던던시, 및 이용 가능성을 달성할 수 있도록 선택되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
6. 제 1 항에 있어서,
   상기 논리 컴퓨터 시스템들의 적어도 일부는 가상(virtual) 컴퓨터 시스템들인 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
7. 제 2 항에 있어서,
   상기 논리 컴퓨터 시스템들의 적어도 일부는 가상 컴퓨터 시스템들인 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
8. 제 2 항에 있어서,
   상기 논리 컴퓨터 시스템들은 모두 가상 컴퓨터 시스템들인 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
9. 제 4 항에 있어서,
   상기 논리 컴퓨터 시스템들의 적어도 일부는 가상 컴퓨터 시스템들인 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
   
10. 제 4 항에 있어서,
    상기 논리 컴퓨터 시스템들은 모두 가상 컴퓨터 시스템들인 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
11. 제 1 항에 있어서,
    상기 제 1 세트의 논리 컴퓨터 시스템들과 상기 제 2 세트의 논리 컴퓨터 시스템들은 따로 떨어져 있는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
12. 제 1 항에 있어서,
    상기 제 1 세트의 논리 컴퓨터 시스템들과 상기 제 2 세트의 논리 컴퓨터 시스템들은 따로 떨어져 있지 않은 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
13. 제 1 항에 있어서,
    상기 파일 시스템 메타데이터는, 경로 이름들의 공유된 접두사들이 촘촘히 저장되도록, 파트리시아 트리 데이터 구조에 따라 구성되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
14. 제 13 항에 있어서,
    상기 파일 시스템 메타데이터는 (i) 상기 파트리시아 트리(Partricia Tree)를 인코딩하는 노드 테이블(nodes table)과, (ii) 파일들 및 디렉토리들의 속성들을 인코딩(encoding)하는 파일 테이블과, (iii) 상기 노드 테이블 내에서 사용되는 최대 길이보다 큰 길이를 가지는 스트링(string)들의 이름들을 인코딩하는 스트링 테이블 내에 저장되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
15. 제 14 항에 있어서, 상기 노드 테이블과 상기 파일 테이블과 상기 스트링 테이블 각각은 지속성을 위해 별개의 파일 내에 동적으로 저장되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
16. 제 15 항에 있어서,
    상기 노드 테이블, 상기 파일 테이블, 또는 상기 스트링 테이블로의 변경은 인텐트 로그(intent log) 내에 저장되고, 상기 인텐트 로그는 상기 테이블들에 대응하는 상기 파일들을 업데이트하기 위하여 동적으로 사용되고, 단일 동작과 관련된 변경들은 함께 링크(link)되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
17. 제 2 항에 있어서,
    상기 클러스터에 의해 관리되는 상기 네임 스페이스 데이터의 공유된 서브세트에 대한 업데이트들을 처리하는 동안 각각의 연속하는 업데이트에는 시퀀스(sequence) 번호가 제공되고, 상기 클러스터의 논리 컴퓨터 시스템들은 상기 시퀀스 번호에 기초하여 업데이트하는 사전 설정된 순서를 유지하면서 비동기적으로 동작하도록 구성되는 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
18. 제 14 항에 있어서,
    상기 노드 테이블과 상기 파일 테이블과 상기 스트링 테이블 각각은 고정된 크기의 엔트리들(entries)을 갖는 별개의 어레이(array)인 것을 특징으로 하는 소프트웨어 정의 네트워크 연결 저장 시스템의 설정 방법.
    
    
    

Images