KR101891425B1 - 분산형 저장 시스템에서의 이름공간 관리 - Google Patents
분산형 저장 시스템에서의 이름공간 관리 Download PDFInfo
- Publication number
- KR101891425B1 KR101891425B1 KR1020167029945A KR20167029945A KR101891425B1 KR 101891425 B1 KR101891425 B1 KR 101891425B1 KR 1020167029945 A KR1020167029945 A KR 1020167029945A KR 20167029945 A KR20167029945 A KR 20167029945A KR 101891425 B1 KR101891425 B1 KR 101891425B1
- Authority
- KR
- South Korea
- Prior art keywords
- node
- dag
- entry
- new
- list
- Prior art date
Links
Images
Classifications
-
- G06F17/30958—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
- G06F16/137—Hash-based
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
방향성 비사이클 그래프(DAG)는 디렉터리의 이름공간을 표현하도록 발생된다. 특정된 이름을 갖는 새로운 객체를 생성하라는 요청에 응답하여, 해시 값 비트 시퀀스는 이름에 대해 컴퓨팅된다. DAG의 복수의 레벨은 특정된 이름에 대응하는 새로운 엔트리를 저장하기 위해 후보 노드를 식별하도록 비트 시퀀스의 연속하는 서브시퀀스를 사용하여 항행된다. 후보 노드가 분할 기준을 만족하면, 엔트리의 후보 노드의 리스트의 엔트리의 적어도 하나의 선택된 서브세트 및 새로운 엔트리는, 각각의 분산된 엔트리에 대해 해시 함수를 적용함으로써 획득된 각각의 비트 시퀀스를 사용하여, 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드 간 분산된다.
Description
많은 회사 및 다른 조직은, (예를 들어, 로컬 네트워크의 일부분으로서) 병설되거나 또는 대신에 (예를 들어, 하나 이상의 사설 또는 공중 중간 네트워크를 통하여 접속된) 다수의 구별되는 지리적 장소에 위치하는 컴퓨팅 시스템과와 같이, 그들 연산을 지원하기 위해 수많은 컴퓨팅 시스템을 상호접속하는 컴퓨터 네트워크를 운용한다. 예를 들어, 상당한 수의 상호접속된 컴퓨팅 시스템을 하우징하는 데이터 센터는, 단일 조직에 의해 그리고 그것을 대리하여 운용되는 사설 데이터 센터, 및 컴퓨팅 자원을 고객에 제공하기 위한 사업으로서 개체에 의해 운용되는 공중 데이터 센터와 같이, 아주 흔하게 되었다. 일부 공중 데이터 센터 운용자는 다양한 고객에 의해 소유된 하드웨어에 네트워크 액세스, 전력 및 보안 설치 설비를 제공하는 한편, 다른 공중 데이터 센터 운용자는 그들 고객에 의한 사용에 이용가능하게 된 하드웨어 자원도 포함하는 "풀 서비스" 설비를 제공한다.
일부 대규모 제공자 네트워크는, 각각의 URL을 통하여 액세스가능한 임의 비트 버킷으로서 모델링될 수 있는 블록-레벨 디바이스(볼륨) 또는 객체를 구현하는 서비스와 같은, 각종 저장 서비스를 구현한다. 그렇지만, 제공자 네트워크의 데이터 센터에서 실행되는 여러 애플리케이션은, 다양한 산업-표준 파일 시스템 인터페이스와 같은, 더 공통적인 저장-관련 프로그램 인터페이스 중 일부의 그들 사용에 대해서는 여전히 제한에 직면할 수 있다. 일부 산업-표준 파일 시스템은 네트워크-액세스가능한 서비스의 대규모 전개 이전에 설계되었을 수 있고, 그래서 비동기식 컴퓨터계산 상호작용, 개개의 컴포넌트 및 네트워크 파티션의 장애 또는 네트워킹-관련 지연이 모두 비교적 공통적인 분산형 시스템에서 구현하기에 간단하지 않은 일관성 모델 및 다른 시맨틱스를 지원할 수 있다.
도 1은, 적어도 일부 실시형태에 따른, 분산형 파일 저장 서비스의 하이-레벨 개관도;
도 2는, 적어도 일부 실시형태에 따라, 파일 저장 서비스를 구현하기 위해 제공자 네트워크의 복수의 가용성 컨테이너에서의 자원의 사용의 예시도;
도 3은, 적어도 일부 실시형태에 따라, 고립형 가상 네트워크와 연관된 네트워크 주소가 저장 서비스의 액세스 서브시스템 노드에 배정되는 구성의 예시도;
도 4는, 적어도 일부 실시형태에 따른, 파일 저장 서비스 객체, 논리적 블록, 및 하나 이상의 익스텐트(extent)에서의 물리적 페이지 간 매핑의 예시도;
도 5는, 적어도 일부 실시형태에 따른, 데이터 및 메타데이터 익스텐트에 대한 복제본 그룹의 구성의 예시도;
도 6은, 적어도 일부 실시형태에 따라, 파일 저장 서비스의 액세스 서브시스템 노드에서 메타데이터를 캐싱하는 것과 연관된 상호작용의 예의 예시도;
도 7은, 적어도 일부 실시형태에 따라, 파일 스토어에 대한 데이터 영속성, 성능, 및 논리적-대-물리적 데이터 매핑과 관련 있는 정책의 구별되는 조합의 사용의 예의 예시도;
도 8a는, 적어도 일부 실시형태에 따라, 확장가능한 분산형 파일 시스템 저장 서비스를 구현하도록 수행될 수 있는 관리-관련 연산 및 구성의 태양을 예시하는 순서도;
도 8b는, 적어도 일부 실시형태에 따라, 확장가능한 분산형 파일 시스템 저장 서비스에서 클라이언트 요청에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 9는, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스에서 복제-기반 영속성 정책을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 10은, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스의 액세스 서브시스템 노드에서 메타데이터를 캐싱하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 11은, 적어도 일부 실시형태에 따라, 기록 오프셋 및 기록 크기가 때로는 물리적 저장소의 원자 단위의 경계와 정렬되지 않을 수 있는 파일 저장 서비스에서 구현될 수 있는 판독-수정-기록 시퀀스의 예의 예시도;
도 12는, 적어도 일부 실시형태에 따라, 익스텐트 복제본 그룹에 대한 합의-기반 복제 상태 머신의 사용의 예시도;
도 13은, 적어도 일부 실시형태에 따라, 일부 유형의 기록 연산에 사용될 수 있는 조건부 기록 프로토콜에 관여된 예시적 상호작용의 예시도;
도 14는, 적어도 일부 실시형태에 따라, 조건부 기록 프로토콜을 구현하도록 확립될 수 있는 예시적 기록 로그 버퍼의 예시도;
도 15는, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스에서 조건부 기록 프로토콜을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 16은, 적어도 일부 실시형태에 따라, 파일 저장 서비스에서 분산형 트랜잭션의 커밋을 초래할 수 있는 일례의 메시지 흐름의 예시도;
도 17은, 적어도 일부 실시형태에 따라, 파일 저장 서비스에서 분산형 트랜잭션의 중단을 초래할 수 있는 일례의 메시지 흐름의 예시도;
도 18은, 적어도 일부 실시형태에 따라, 트랜잭션의 조정자로서 지정된 노드를 포함하는 분산형 트랜잭션 특정 노드 체인의 일례의 예시도;
도 19는, 적어도 일부 실시형태에 따라, 노드 체인의 노드 중 하나에서 장애의 경우에 분산형 트랜잭션 완료를 용이하게 하도록 수행될 수 있는 예시적 연산의 예시도;
도 20은, 적어도 일부 실시형태에 따라, 파일 시스템 저장 서비스에서 분산형 트랜잭션을 조정하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 21은, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-준비 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 22는, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-커밋 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 23은, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-중단 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 24는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 초과-가입된 저장 익스텐트의 예의 예시도;
도 25는, 적어도 일부 실시형태에 따라, 온-디맨드 물리적 페이지-레벨 할당 및 익스텐트 초과가입을 구현하는 저장 서비스의 서브시스템들 간 상호작용의 예시도;
도 26a는 자유 공간 임계치가 지정된 익스텐트의 예시도; 한편 도 26b는, 적어도 일부 실시형태에 따라, 자유 공간 임계치의 위반으로부터 초래되는 익스텐트의 확장의 예시도;
도 27은, 적어도 일부 실시형태에 따라, 초과가입을 지원하는 익스텐트에서 온-디맨드 물리적 페이지 할당을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 28은, 적어도 일부 실시형태에 따라, 익스텐트 초과가입 파라미터를 동적으로 수정하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 29는, 적어도 일부 실시형태에 따라, 가변 스트라이프 크기를 사용하여 스트라이핑된 파일 스토어 객체의 예의 예시도;
도 30은, 적어도 일부 실시형태에 따라, 파일 스토어 객체에 사용될 수 있는 스트라이프 크기결정 시퀀스의 예의 예시도;
도 31은, 적어도 일부 실시형태에 따라, 파일 스토어 객체에 대한 스트라이프 크기 결정 및/또는 통합 결정을 하기 위해 메타데이터 서브시스템에서 고려될 수 있는 인자의 예의 예시도;
도 32는, 적어도 일부 실시형태에 따라, 가변 스트라이프 크기를 사용하여 스트라이핑을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 33은, 적어도 일부 실시형태에 따라, 논리적 블록으로의 모든 판독 요청이 서로에 비해 동등한 우선순위를 승인받는 스케줄링 환경에서 저장 서비스 객체의 논리적 블록으로 지향된 다수의 병행 판독 요청에 의해 이루어진 진행의 일례의 타임라인의 예시도;
도 34는, 적어도 일부 실시형태에 따라, 오프셋-기반 정체 제어 정책이 사용되는 스케줄링 환경에서 저장 서비스 객체의 논리적 블록으로 지향된 다수의 병행 판독 요청에 의해 이루어진 진행의 일례의 타임라인의 예시도;
도 35a는, 저장 서비스에서 I/O 요청을 스케줄링하는데 사용될 수 있는 토큰-기반 정체 제어 메커니즘의 일례의 예시도; 한편 도 35b는, 적어도 일부 실시형태에 따라, 채용될 수 있는 오프셋-기반 토큰 소비 정책의 예의 예시도;
도 36은, 적어도 일부 실시형태에 따라, 저장 서비스에서의 정체 제어에 오프셋-기반 지연을 사용하는 일례의 예시도;
도 37은, 적어도 일부 실시형태에 따라, 액세스되는 저장 객체의 유형 및 요청된 액세스의 다양한 특성에 종속할 수 있는 정체 제어 정책의 예의 예시도;
도 38은, 적어도 일부 실시형태에 따라, 저장 서비스에서 I/O 연산을 스케줄링하기 위해 오프셋-기반 정체 제어를 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 39는, 적어도 일부 실시형태에 따라, 이름변경 연산을 구현하도록 저장 서비스의 복수의 메타데이터 서브시스템 노드에서 수행되어야 할 수 있는 메타데이터 변경의 일례의 예시도;
도 40은, 적어도 일부 실시형태에 따라, 병행 이름변경 연산에 대한 교착상태 회피 메커니즘의 사용의 예시도;
도 41은, 적어도 일부 실시형태에 따라, 이름변경 연산에 대해 저장 서비스에서 결정될 수 있는, 2개의 가능한 로크 순서화 중, 제1 로크 순서화에 기반하여 제1 이름변경 작업흐름을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 42는, 적어도 일부 실시형태에 따라, 이름변경 연산에 대해 저장 서비스에서 결정될 수 있는, 2개의 가능한 로크 순서화 중, 제2 로크 순서화에 기반하여 제2 이름변경 작업흐름을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 43은, 적어도 일부 실시형태에 따라, 이름변경 작업흐름에 참가하는 한 쌍의 메타데이터 서브시스템 노드 중 하나의 메타데이터 서브시스템 노드의 장애에 응답하여 수행될 수 있는 복구 연산의 태양을 예시하는 순서도;
도 44는, 적어도 일부 실시형태에 따라, 이름변경 작업흐름에 참가하는 그 쌍의 메타데이터 서브시스템 노드 중 다른 하나의 메타데이터 서브시스템 노드의 장애에 응답하여 수행될 수 있는 복구 연산의 태양을 예시하는 순서도;
도 45는, 적어도 일부 실시형태에 따라, 파일 스토어 이름공간 관리에 사용될 수 있는 해시-기반 방향성 비사이클 그래프(DAG)의 일례의 예시도;
도 46은, 적어도 일부 실시형태에 따라, 파일 이름에 대해 획득된 해시 값의 연속하는 서브시퀀스를 사용하여 HDAG를 순회하기 위한 기술의 예시도;
도 47은, 적어도 일부 실시형태에 따라, 이름공간에 엔트리를 삽입하려는 시도로부터 초래될 수 있는 HDAG 노드 분할의 2개의 유형 중 제1 유형의 일례의 예시도;
도 48은, 적어도 일부 실시형태에 따라, 이름공간에 엔트리를 삽입하려는 시도로부터 초래될 수 있는 HDAG 노드 분할의 2개의 유형 중 제2 유형의 일례의 예시도;
도 49는, 적어도 일부 실시형태에 따라, HDAG 노드 삭제 연산의 2개 유형 중 제1 유형의 일례의 예시도;
도 50은, 적어도 일부 실시형태에 따라, HDAG 노드 삭제 연산의 2개 유형 중 제2 유형의 일례의 예시도;
도 51은, 적어도 일부 실시형태에 따라, 제1 유형의 HDAG 노드 분할을 초래하는 이름공간으로의 엔트리의 삽입에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 52는, 적어도 일부 실시형태에 따라, 제2 유형의 HDAG 노드 분할을 초래하는 이름공간으로의 엔트리의 삽입에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 53은, 적어도 일부 실시형태에 따라, 이름공간으로부터 엔트리의 삭제에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 54는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 세션-지향형 파일 시스템 프로토콜에 대해 유지되고 있을 수 있는 2차원의 메타데이터의 예시도;
도 55는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스의 서브컴포넌트들 간 클라이언트 세션 메타데이터-관련 상호작용의 일례의 예시도;
도 56은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서의 클라이언트 세션 리스 갱신에 대한 대안의 접근법의 예시도;
도 57a 및 도 57b는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 세션-지향형 파일 시스템 프로토콜에 대해 로크 상태 관리에 대한 대안의 접근법의 예시도;
도 58은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 수행될 수 있는 클라이언트 세션 메타데이터 관리 연산의 태양을 예시하는 순서도;
도 59는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 수행될 수 있는 클라이언트 세션 리스 갱신 연산의 태양을 예시하는 순서도;
도 60은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에 대해 부하 밸런서 계층이 구성되는 시스템의 예시도;
도 61은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스의 복수의 액세스 서브시스템 노드와 부하 밸런서 노드 간 상호작용례의 예시도;
도 62는, 적어도 일부 실시형태에 따라, 행한 커넥션 시도의 수에 따라 달라질 수 있는 커넥션 수락 기준의 예의 예시도;
도 63은, 적어도 일부 실시형태에 따라, 커넥션 확립 시도 카운트에는 물론, 복수의 자원과 연관된 작업부하 레벨에도 종속할 수 있는 커넥션 수락 기준의 예의 예시도;
도 64는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 시도 카운트에 기반하여 커넥션 밸런싱을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 65는, 적어도 일부 실시형태에 따라, 액세스 노드의 피어 그룹의 멤버의 작업부하 표시자에 기반하여 클라이언트 커넥션 리-밸런싱이 시도될 수 있는 분산형 저장 서비스의 액세스 서브시스템의 일례의 예시도;
도 66은, 적어도 일부 실시형태에 따라, 액세스 서브시스템 노드에서 사용될 수 있는 커넥션 수락 및 리-밸런싱 기준의 일례의 예시도;
도 67은, 적어도 일부 실시형태에 따라, 커넥션 리-밸런싱을 구현하도록 분산형 저장 서비스의 액세스 서브시스템에서 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 68은, 적어도 일부 실시형태에 따라, 커넥션 리-밸런싱 이벤트를 가로질러 클라이언트 세션을 보존하도록 분산형 저장 서비스에서 수행될 수 있는 연산의 태양을 예시하는 순서도; 및
도 69는 적어도 일부 실시형태에서 사용될 수 있는 일례의 컴퓨팅 디바이스를 예시하는 블록 선도.
도 2는, 적어도 일부 실시형태에 따라, 파일 저장 서비스를 구현하기 위해 제공자 네트워크의 복수의 가용성 컨테이너에서의 자원의 사용의 예시도;
도 3은, 적어도 일부 실시형태에 따라, 고립형 가상 네트워크와 연관된 네트워크 주소가 저장 서비스의 액세스 서브시스템 노드에 배정되는 구성의 예시도;
도 4는, 적어도 일부 실시형태에 따른, 파일 저장 서비스 객체, 논리적 블록, 및 하나 이상의 익스텐트(extent)에서의 물리적 페이지 간 매핑의 예시도;
도 5는, 적어도 일부 실시형태에 따른, 데이터 및 메타데이터 익스텐트에 대한 복제본 그룹의 구성의 예시도;
도 6은, 적어도 일부 실시형태에 따라, 파일 저장 서비스의 액세스 서브시스템 노드에서 메타데이터를 캐싱하는 것과 연관된 상호작용의 예의 예시도;
도 7은, 적어도 일부 실시형태에 따라, 파일 스토어에 대한 데이터 영속성, 성능, 및 논리적-대-물리적 데이터 매핑과 관련 있는 정책의 구별되는 조합의 사용의 예의 예시도;
도 8a는, 적어도 일부 실시형태에 따라, 확장가능한 분산형 파일 시스템 저장 서비스를 구현하도록 수행될 수 있는 관리-관련 연산 및 구성의 태양을 예시하는 순서도;
도 8b는, 적어도 일부 실시형태에 따라, 확장가능한 분산형 파일 시스템 저장 서비스에서 클라이언트 요청에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 9는, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스에서 복제-기반 영속성 정책을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 10은, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스의 액세스 서브시스템 노드에서 메타데이터를 캐싱하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 11은, 적어도 일부 실시형태에 따라, 기록 오프셋 및 기록 크기가 때로는 물리적 저장소의 원자 단위의 경계와 정렬되지 않을 수 있는 파일 저장 서비스에서 구현될 수 있는 판독-수정-기록 시퀀스의 예의 예시도;
도 12는, 적어도 일부 실시형태에 따라, 익스텐트 복제본 그룹에 대한 합의-기반 복제 상태 머신의 사용의 예시도;
도 13은, 적어도 일부 실시형태에 따라, 일부 유형의 기록 연산에 사용될 수 있는 조건부 기록 프로토콜에 관여된 예시적 상호작용의 예시도;
도 14는, 적어도 일부 실시형태에 따라, 조건부 기록 프로토콜을 구현하도록 확립될 수 있는 예시적 기록 로그 버퍼의 예시도;
도 15는, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스에서 조건부 기록 프로토콜을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 16은, 적어도 일부 실시형태에 따라, 파일 저장 서비스에서 분산형 트랜잭션의 커밋을 초래할 수 있는 일례의 메시지 흐름의 예시도;
도 17은, 적어도 일부 실시형태에 따라, 파일 저장 서비스에서 분산형 트랜잭션의 중단을 초래할 수 있는 일례의 메시지 흐름의 예시도;
도 18은, 적어도 일부 실시형태에 따라, 트랜잭션의 조정자로서 지정된 노드를 포함하는 분산형 트랜잭션 특정 노드 체인의 일례의 예시도;
도 19는, 적어도 일부 실시형태에 따라, 노드 체인의 노드 중 하나에서 장애의 경우에 분산형 트랜잭션 완료를 용이하게 하도록 수행될 수 있는 예시적 연산의 예시도;
도 20은, 적어도 일부 실시형태에 따라, 파일 시스템 저장 서비스에서 분산형 트랜잭션을 조정하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 21은, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-준비 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 22는, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-커밋 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 23은, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-중단 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 24는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 초과-가입된 저장 익스텐트의 예의 예시도;
도 25는, 적어도 일부 실시형태에 따라, 온-디맨드 물리적 페이지-레벨 할당 및 익스텐트 초과가입을 구현하는 저장 서비스의 서브시스템들 간 상호작용의 예시도;
도 26a는 자유 공간 임계치가 지정된 익스텐트의 예시도; 한편 도 26b는, 적어도 일부 실시형태에 따라, 자유 공간 임계치의 위반으로부터 초래되는 익스텐트의 확장의 예시도;
도 27은, 적어도 일부 실시형태에 따라, 초과가입을 지원하는 익스텐트에서 온-디맨드 물리적 페이지 할당을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 28은, 적어도 일부 실시형태에 따라, 익스텐트 초과가입 파라미터를 동적으로 수정하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 29는, 적어도 일부 실시형태에 따라, 가변 스트라이프 크기를 사용하여 스트라이핑된 파일 스토어 객체의 예의 예시도;
도 30은, 적어도 일부 실시형태에 따라, 파일 스토어 객체에 사용될 수 있는 스트라이프 크기결정 시퀀스의 예의 예시도;
도 31은, 적어도 일부 실시형태에 따라, 파일 스토어 객체에 대한 스트라이프 크기 결정 및/또는 통합 결정을 하기 위해 메타데이터 서브시스템에서 고려될 수 있는 인자의 예의 예시도;
도 32는, 적어도 일부 실시형태에 따라, 가변 스트라이프 크기를 사용하여 스트라이핑을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 33은, 적어도 일부 실시형태에 따라, 논리적 블록으로의 모든 판독 요청이 서로에 비해 동등한 우선순위를 승인받는 스케줄링 환경에서 저장 서비스 객체의 논리적 블록으로 지향된 다수의 병행 판독 요청에 의해 이루어진 진행의 일례의 타임라인의 예시도;
도 34는, 적어도 일부 실시형태에 따라, 오프셋-기반 정체 제어 정책이 사용되는 스케줄링 환경에서 저장 서비스 객체의 논리적 블록으로 지향된 다수의 병행 판독 요청에 의해 이루어진 진행의 일례의 타임라인의 예시도;
도 35a는, 저장 서비스에서 I/O 요청을 스케줄링하는데 사용될 수 있는 토큰-기반 정체 제어 메커니즘의 일례의 예시도; 한편 도 35b는, 적어도 일부 실시형태에 따라, 채용될 수 있는 오프셋-기반 토큰 소비 정책의 예의 예시도;
도 36은, 적어도 일부 실시형태에 따라, 저장 서비스에서의 정체 제어에 오프셋-기반 지연을 사용하는 일례의 예시도;
도 37은, 적어도 일부 실시형태에 따라, 액세스되는 저장 객체의 유형 및 요청된 액세스의 다양한 특성에 종속할 수 있는 정체 제어 정책의 예의 예시도;
도 38은, 적어도 일부 실시형태에 따라, 저장 서비스에서 I/O 연산을 스케줄링하기 위해 오프셋-기반 정체 제어를 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 39는, 적어도 일부 실시형태에 따라, 이름변경 연산을 구현하도록 저장 서비스의 복수의 메타데이터 서브시스템 노드에서 수행되어야 할 수 있는 메타데이터 변경의 일례의 예시도;
도 40은, 적어도 일부 실시형태에 따라, 병행 이름변경 연산에 대한 교착상태 회피 메커니즘의 사용의 예시도;
도 41은, 적어도 일부 실시형태에 따라, 이름변경 연산에 대해 저장 서비스에서 결정될 수 있는, 2개의 가능한 로크 순서화 중, 제1 로크 순서화에 기반하여 제1 이름변경 작업흐름을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 42는, 적어도 일부 실시형태에 따라, 이름변경 연산에 대해 저장 서비스에서 결정될 수 있는, 2개의 가능한 로크 순서화 중, 제2 로크 순서화에 기반하여 제2 이름변경 작업흐름을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 43은, 적어도 일부 실시형태에 따라, 이름변경 작업흐름에 참가하는 한 쌍의 메타데이터 서브시스템 노드 중 하나의 메타데이터 서브시스템 노드의 장애에 응답하여 수행될 수 있는 복구 연산의 태양을 예시하는 순서도;
도 44는, 적어도 일부 실시형태에 따라, 이름변경 작업흐름에 참가하는 그 쌍의 메타데이터 서브시스템 노드 중 다른 하나의 메타데이터 서브시스템 노드의 장애에 응답하여 수행될 수 있는 복구 연산의 태양을 예시하는 순서도;
도 45는, 적어도 일부 실시형태에 따라, 파일 스토어 이름공간 관리에 사용될 수 있는 해시-기반 방향성 비사이클 그래프(DAG)의 일례의 예시도;
도 46은, 적어도 일부 실시형태에 따라, 파일 이름에 대해 획득된 해시 값의 연속하는 서브시퀀스를 사용하여 HDAG를 순회하기 위한 기술의 예시도;
도 47은, 적어도 일부 실시형태에 따라, 이름공간에 엔트리를 삽입하려는 시도로부터 초래될 수 있는 HDAG 노드 분할의 2개의 유형 중 제1 유형의 일례의 예시도;
도 48은, 적어도 일부 실시형태에 따라, 이름공간에 엔트리를 삽입하려는 시도로부터 초래될 수 있는 HDAG 노드 분할의 2개의 유형 중 제2 유형의 일례의 예시도;
도 49는, 적어도 일부 실시형태에 따라, HDAG 노드 삭제 연산의 2개 유형 중 제1 유형의 일례의 예시도;
도 50은, 적어도 일부 실시형태에 따라, HDAG 노드 삭제 연산의 2개 유형 중 제2 유형의 일례의 예시도;
도 51은, 적어도 일부 실시형태에 따라, 제1 유형의 HDAG 노드 분할을 초래하는 이름공간으로의 엔트리의 삽입에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 52는, 적어도 일부 실시형태에 따라, 제2 유형의 HDAG 노드 분할을 초래하는 이름공간으로의 엔트리의 삽입에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 53은, 적어도 일부 실시형태에 따라, 이름공간으로부터 엔트리의 삭제에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 54는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 세션-지향형 파일 시스템 프로토콜에 대해 유지되고 있을 수 있는 2차원의 메타데이터의 예시도;
도 55는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스의 서브컴포넌트들 간 클라이언트 세션 메타데이터-관련 상호작용의 일례의 예시도;
도 56은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서의 클라이언트 세션 리스 갱신에 대한 대안의 접근법의 예시도;
도 57a 및 도 57b는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 세션-지향형 파일 시스템 프로토콜에 대해 로크 상태 관리에 대한 대안의 접근법의 예시도;
도 58은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 수행될 수 있는 클라이언트 세션 메타데이터 관리 연산의 태양을 예시하는 순서도;
도 59는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 수행될 수 있는 클라이언트 세션 리스 갱신 연산의 태양을 예시하는 순서도;
도 60은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에 대해 부하 밸런서 계층이 구성되는 시스템의 예시도;
도 61은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스의 복수의 액세스 서브시스템 노드와 부하 밸런서 노드 간 상호작용례의 예시도;
도 62는, 적어도 일부 실시형태에 따라, 행한 커넥션 시도의 수에 따라 달라질 수 있는 커넥션 수락 기준의 예의 예시도;
도 63은, 적어도 일부 실시형태에 따라, 커넥션 확립 시도 카운트에는 물론, 복수의 자원과 연관된 작업부하 레벨에도 종속할 수 있는 커넥션 수락 기준의 예의 예시도;
도 64는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 시도 카운트에 기반하여 커넥션 밸런싱을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 65는, 적어도 일부 실시형태에 따라, 액세스 노드의 피어 그룹의 멤버의 작업부하 표시자에 기반하여 클라이언트 커넥션 리-밸런싱이 시도될 수 있는 분산형 저장 서비스의 액세스 서브시스템의 일례의 예시도;
도 66은, 적어도 일부 실시형태에 따라, 액세스 서브시스템 노드에서 사용될 수 있는 커넥션 수락 및 리-밸런싱 기준의 일례의 예시도;
도 67은, 적어도 일부 실시형태에 따라, 커넥션 리-밸런싱을 구현하도록 분산형 저장 서비스의 액세스 서브시스템에서 수행될 수 있는 연산의 태양을 예시하는 순서도;
도 68은, 적어도 일부 실시형태에 따라, 커넥션 리-밸런싱 이벤트를 가로질러 클라이언트 세션을 보존하도록 분산형 저장 서비스에서 수행될 수 있는 연산의 태양을 예시하는 순서도; 및
도 69는 적어도 일부 실시형태에서 사용될 수 있는 일례의 컴퓨팅 디바이스를 예시하는 블록 선도.
여기에서는 수 개의 실시형태 및 예시적 도면에 대하여 예로서 실시형태가 설명되고 있기는 하지만, 당업자는 실시형태가 설명된 실시형태 또는 도면으로 한정되는 것은 아님을 인식할 것이다. 거기에서의 도면 및 상세한 설명은 개시된 특정 형태로 실시형태를 한정하려는 의도가 아니라, 반대로, 첨부 청구범위에 의해 정의되는 바와 같은 취지 및 범위 내에 드는 모든 수정물, 균등물 및 대안물을 망라하려는 의도임을 이해하여야 한다. 여기에서 사용되는 제목은 단지 편성 목적일 뿐이고 청구범위 또는 설명의 범위를 제한하도록 사용됨을 의미하지는 않는다. 본 출원의 곳곳에서 사용될 때, 단어 "할 수 있다"는 의무적 의미(즉, 필수를 의미)보다는 허용적 의미(즉, 잠재성을 가짐을 의미)로 사용된다. 유사하게, 단어 "포함한다" 및 그 활용형은 포함하지만 국한되지는 않음을 의미한다.
높은-가용성(availability), 높은-영속성(durability) 확장가능한 파일 저장 서비스를 위한 방법 및 장치의 다양한 실시형태가 설명된다. 적어도 일부 실시형태에서, 파일 저장 서비스는, 파일의 크기 및/또는 병행 사용자의 수에 독립적이도록 목표로 되는 성능, 가용성 및 영속성 레벨로, 수천 클라이언트에 의한 파일로의 공유된 액세스를 지원하도록 설계될 수 있으며, 여기서 각각의 개개의 파일은 매우 많은 양(예를 들어, 페타바이트)의 데이터를 포함할 수 있다. NFS(네트워크 파일 시스템), SMB(서버 메시지 블록), CIFS(공통 인터넷 파일 시스템) 등과 같은 하나 이상의 산업-표준 파일 시스템 인터페이스 또는 프로토콜이 서비스에 의해 지원될 수 있다. 따라서, 적어도 일부 실시형태에서, 분산형 파일 저장 서비스에 의해 지원된 일관성(consistency) 모델은 적어도 산업-표준 프로토콜에 의해 지원된 모델만큼 강력할 수 있다 - 예를 들어, 서비스는 순차적 일관성을 지원할 수 있다. 순차적 일관성 모델을 구현하는 분산형 시스템에서, 복수의 실행 개체(예를 들어, 분산형 시스템의 서버 또는 노드)에서 집합적으로 구현된 연산의 실행의 결과는 모든 연산이 소정 순차적 순서로 실행된 것처럼 동일할 것으로 예상된다. 파일 저장 서비스는, 파일 콘텐츠 서빙(예를 들어, 웹 서버 팜, 소프트웨어 개발 환경, 및 콘텐츠 관리 시스템), 고성능 컴퓨팅(HPC), 및 파일 스토어 용량 및 성능의 온-디맨드 스케일링을 요구하는 미디어, 금융, 및 과학 솔루션과 같은 "빅 데이터" 애플리케이션 등와 같은, 광범위한 각종 애플리케이션에 의한 사용을 위해 설계될 수 있다. 용어 "파일 스토어"는 여기에서는 파일 시스템의 논리적 균등물을 표시하도록 사용될 수 있다 - 예를 들어, 소정 클라이언트는 2개의 다른 NFS-준수 파일 스토어(FS1, FS2)를 생성할 수 있으며, FS1의 파일은 마운트가능한 루트 디렉터리의 서브디렉터리의 일 세트 내에 저장되고, 그리고 FS2의 파일은 다른 마운트가능한 루트 디렉터리의 서브디렉터리 세트 내에 저장된다.
높은 레벨의 확장성(scalability)을 가능하게 하는 것을 돕기 위해, 적어도 일부 실시형태에서는 모듈형 아키텍처가 서비스에 사용될 수 있다. 예를 들어, 소정 수의 멀티-테넌트(multi-tenant) 저장 노드를 포함하는 물리적 저장 서브시스템은 파일 스토어 콘텐츠에 대해 사용될 수 있는 한편, 그 자신의 메타데이터 노드 세트를 갖는 논리적으로 구별되는 메타데이터 서브시스템은 일 구현에서 파일 스토어 콘텐츠를 관리하는데 사용될 수 있다. 메타데이터와 데이터의 논리적 분리는, 예를 들어, 메타데이터에 대한 성능, 영속성 및/또는 가용성 요건은 적어도 일부 경우에서 데이터에 대한 대응하는 요건과는 다를 수 있다(예를 들어, 그보다 더 엄격할 수 있다)는 사실에 의해 동기가 부여될 수 있다. 메타데이터 및 저장 노드와는 구별되는 그 자신의 액세스 노드 세트를 갖는 프론트-엔드 액세스 서브시스템은 클라이언트가 산업-표준 인터페이스를 통하여 파일 스토어를 생성, 판독, 업데이트, 수정 및 삭제하라는 요청을 제출할 수 있게 하는 네트워크 종단점을 노출시키는 것, 및 클라이언트 상호작용과 연관된 커넥션 관리, 부하 밸런싱, 인증, 권한부여 및 다른 태스크를 취급하는 것을 책임지고 있을 수 있다. 자원은 일부 실시형태에서는, 다른 서브시스템에서의 대응하는 전개 변경을 요구함이 없이, 서브시스템 중 어느 하나에, 예를 들어, 액세스 서브시스템, 메타데이터 서브시스템 또는 저장 서브시스템에 독립적으로 전개될 수 있다. 예를 들어, 잠재적 성능 병목과 같은 트리거링 조건이 액세스 서브시스템에서 식별되면, 또는 소정 액세스 서브시스템 노드 세트가 네트워크 불능 또는 다른 장애를 경험하면, 추가적 액세스 서브시스템 노드는 저장 또는 메타데이터 서브시스템에 영향을 미치지 않고 그리고 클라이언트 요청의 흐름을 멈추게 하지 않고 온라인으로 될 수 있을 수 있다. 유사한 전개 변경은 다양한 유형의 트리거링 조건에 응답하여 다른 서브시스템에서 역시 이루어질 수 있다. 일부 실시형태에서, 특히 액세스 서브시스템 노드는, 액세스 노드 장애로부터의 복구가 특히 효율적일 수 있도록, 대체로 무상태 방식으로 구현될 수 있다.
적어도 일부 실시형태에서, 파일 스토어 메타데이터 객체(예를 들어, 디렉터리 엔트리, 링크 등의 속성을 표현하는 데이터 구조)의 콘텐츠는 저장 서브시스템에 의해 관리되는 디바이스 상에 자체가 저장될 수 있기는 하지만 - 아래에서 설명되는 바와 같이, 일부 경우에서는 메타데이터에 대해 사용되는 저장 객체에 적용되는 것과는 다른 정책이 데이터에 대해 사용되는 저장 객체에 적용될 수 있다. 그러한 실시형태에서, 메타데이터 서브시스템 노드는, 예를 들어, 메타데이터 관리 로직을 실행하고 저장 서브시스템에서 메타데이터 콘텐츠의 저장을 조정하는 다양한 실행 스레드 또는 프로세스를 포함할 수 있다. 소정 저장 서브시스템 노드는 일부 실시형태에서는, 회전 자기 디스크를 채용하는 소정 수의 디바이스 및 고체 상태 드라이브(SSD)를 채용하는 소정 수의 디바이스와 같은, 수 개의 다른 유형의 저장 매체를 포함할 수 있다. 일부 실시형태에서, 소정 저장 서브시스템 노드는, 각각의 다른 저장 디바이스에서든 동일한 저장 디바이스 상에든, 메타데이터도 그리고 데이터도 저장할 수 있다. 용어 "파일 스토어 객체"는 여기에서는, 데이터 객체를 관리 및 저장하도록 사용된, (예를 들어 아래에서 논의되는 논리적 블록, 물리적 페이지 및 익스텐트 간 매핑을 포함하는) 전형적으로는 내부 메타데이터 구조에 뿐만 아니라, 저장 서비스의 클라이언트에도 보이는 파일, 디렉터리 등과 같은 데이터 객체를 총칭하도록 사용될 수 있다.
적어도 일부 실시형태에서, 분산형 파일 저장 서비스는 제공자 네트워크의 자원을 사용하여 구축될 수 있고, 주로 제공자 네트워크 내에서의 다른 개체로부터의 저장 요청을 이행하도록 설계될 수 있다. 인터넷 및/또는 다른 네트워크를 통하여 분산형 클라이언트 세트에 액세스가능한 (다양한 유형의 클라우드-기반 컴퓨팅 또는 저장 서비스와 같은) 하나 이상의 네트워크-액세스가능한 서비스를 제공하도록 공중 부문 조직 또는 회사와 같은 개체에 의해 셋업된 네트워크는 여기에서 제공자 네트워크라고 칭해질 수 있다. 서비스 중 일부는 더 높은-레벨 서비스를 구축하는데 사용될 수 있다: 예를 들어, 컴퓨팅, 저장 또는 데이터베이스 서비스는 콘텐츠 유통 서비스 또는 스트리밍 데이터 프로세싱 서비스를 위한 구축 블록으로서 사용될 수 있다. 제공자 네트워크의 서비스 중 적어도 일부는 소위 "인스턴스"라는 서비스 단위로 클라이언트 사용을 위해 패키징될 수 있다: 예를 들어, 가상화된 컴퓨팅 서비스에 의해 인스턴스화된 가상 머신은 "컴퓨트 인스턴스"를 표현할 수 있다. 제공자 네트워크의 그러한 컴퓨트 인스턴스가 구현되는 컴퓨팅 디바이스는 여기에서는 "인스턴스 호스트"라고 또는 더 단순히 여기에서는 "호스트"라고 지칭될 수 있다. 소정 인스턴스 호스트는 수 개의 컴퓨트 인스턴스를 포함할 수 있고, 그리고 특정 인스턴스 호스트에서의 컴퓨트 인스턴스의 집합은 하나 이상의 클라이언트의 애플리케이션을 구현하도록 사용될 수 있다. 일부 실시형태에서, 파일 저장 서비스는, 예를 들어, 저장 서비스의 액세스 서브시스템 노드에 적합한 네트워크 주소를 배정하는 것, 가상 컴퓨팅 서비스에 사용되는 권한부여/인증 프로토콜을 구현하는 것 등의 결과로서 제공자 네트워크의 컴퓨트 인스턴스의 소정 서브세트(또는 전부)로부터 액세스가능할 수 있다. 일부 실시형태에서는, 제공자 네트워크 밖의 클라이언트에도 파일 저장 서비스로의 액세스가 제공될 수 있다. 다양한 실시형태에서, 제공자 네트워크 서비스 중 적어도 일부는 사용-기반 가격책정 정책을 구현할 수 있다 - 예를 들어, 고객은 인스턴스가 얼마나 오래 사용되었는지에, 또는 컴퓨트 인스턴스로부터 제출되었던 다양한 유형의 요청의 수에 적어도 부분적으로 기반하여 컴퓨트 인스턴스에 대해 요금 청구될 수 있다. 적어도 일부 그러한 실시형태에서, 파일 저장 서비스는 또한 클라이언트 요청의 적어도 일부 카테고리에 대해 사용-기반 가격책정을 채용할 수 있다 - 예를 들어, 서비스는 소정 고객을 대리하여 완료된 특정 파일 시스템 인터페이스 요청의 레코드를 유지할 수 있고, 그들 레코드에 기반하여 고객에 대한 과금량을 발생시킬 수 있다.
파일 스토어 서비스는, 예를 들어 여러 다른 복제 기술 중 어느 것이라도 사용하여, 일부 실시형태에서 높은 레벨의 데이터 영속성을 지원할 수 있다. 예를 들어, 일 실시형태에서, 파일 스토어 데이터 및 메타데이터는 소위 익스텐트라는 저장 유닛을 사용하여 물리적으로 저장될 수 있고, 그리고 익스텐트의 콘텐츠는 다양한 물리적 저장 디바이스에서 복제될 수 있다. 익스텐트의 콘텐츠는 그것을, "익스텐트 복제본", "복제본 그룹 멤버", 또는 "익스텐트렛" 또는 "복제본 그룹"이라고 지칭될 수 있는, 여러 다른 물리적 저장 디바이스에서의 물리적 사본과 구별하기 위해 여기에서는 "논리적 익스텐트"라고 지칭될 수 있다. 일 구현에서, 예를 들어, 파일(또는 메타데이터 객체)은 논리적 블록의 시퀀스로서 조직될 수 있으며, 각각의 논리적 블록은 하나 이상의 물리적 데이터 페이지에 매핑된다. 논리적 블록은, 적어도 일부 구현에서 동일한 파일(또는 동일한 메타데이터 구조)의 2개의 다른 논리적 블록의 콘텐츠가 동일한 저장 디바이스에서 저장될 확률이 낮게 될 수 있다는 점에서, 스트라이핑(striping)의 단위로 고려될 수 있다. 소정 논리적 익스텐트의 각각의 복제본은 소정 수의 물리적 데이터 페이지를 포함할 수 있다. 일부 실시형태에서는, 소거-코딩 기반 익스텐트 복제본이 사용될 수 있는 한편, 다른 실시형태에서는, 완전 복제와 같은 다른 복제 기술이 사용될 수 있다. 적어도 하나의 실시형태에서는, 소거 코딩과 완전 복제의 조합이 사용될 수 있다. 따라서, 클라이언트로부터의 소정 수정 요청은, 대응하는 파일 스토어 객체 또는 메타데이터에 사용 중인 복제 정책의 본성에 종속하여, 각각의 저장 디바이스 및/또는 각각의 저장 서브시스템 노드에서의 복수의 물리적 수정으로 번역될 수 있다. 일부 실시형태에서, 복제본 그룹의 익스텐트 복제본 중 하나 이상은 마스터 복제본으로서 지정될 수 있고, 그리고 익스텐트에 대한 업데이트는 현재 마스터를 호스팅하고 있는 저장 서비스 노드에 의해, 예를 들어 합의-기반 복제 상태 머신을 사용하여, 조정될 수 있다. 그러한 저장 서비스 노드는 그것이 마스터 복제본을 저장하는 익스텐트에 대해 여기에서는 "마스터 노드" 또는 "리더"라고 칭해질 수 있다. 일 구현에서, 소정 논리적 익스텐트의 N개의 익스텐트 복제본이 유지되고 있으면, 복제본 중 M개(여기서 M >= N/2)의 정족수가 필요할 수 있고, 그러한 정족수는, 특정 업데이트가 커밋팅되기 전에, 리더/마스터 노드에 의해 개시된 업데이트 프로토콜을 사용하여 획득될 수 있다. 일 실시형태에서, 일부 익스텐트는 파일 콘텐츠 또는 데이터에 전적으로 사용될 수 있는 한편, 다른 익스텐트는 메타데이터에만 배타적으로 사용될 수 있다. 다른 실시형태에서, 소정 익스텐트는 데이터도 그리고 메타데이터도 저장할 수 있다. 일부 구현에서, 합의-기반 프로토콜은 소정 파일 스토어의 상태 변화를 표시하는 로그 레코드를 복제하도록 사용될 수 있고, 그리고 상태의 콘텐츠는 복수의 익스텐트를 사용하여 (예를 들어, 완전 복제 또는 소거-코딩된 복제본 중 어느 것을 사용하여) 복제될 수 있다. 복제 상태 머신은 또한 다양한 실시형태에서 판독 연산의 적어도 일부 유형에 대해 일관성을 보장하도록 사용될 수 있다. 예를 들어, 단일 클라이언트 판독 요청은 실제로는 다양한 익스텐트에서 (예를 들어, 메타데이터 및/또는 데이터의) 복수의 물리적 판독 연산을 요구할 수 있고, 그리고 복제 상태 머신의 사용은 그러한 분산형 판독의 결과가 표적 파일 스토어의 판독 일관성 요건을 위반하지 않음을 보장할 수 있다.
아래에서 설명되는 바와 같이 여러 다른 실시형태에서 다양한 다른 할당 및 크기결정 정책이 데이터 및 메타데이터에 대한 논리적 블록, 물리적 페이지, 및/또는 익스텐트의 크기 및 그들 간 관계를 결정하도록 사용될 수 있다. 예를 들어, 하나의 간단한 구현에서, 파일은 소정 수의 고정 크기(예를 들어, 4-메가바이트) 논리적 블록을 포함할 수 있고, 각각의 논리적 블록은 소정 수의 고정 크기(예를 들어, 32-킬로바이트) 물리적 페이지를 포함할 수 있고, 그리고 각각의 익스텐트는 고정 수의 페이지를 저장하기에 충분한 저장 공간(예를 들어, 16 기가바이트)을 포함할 수 있다. 다른 실시형태에서, 다른 논리적 블록은 크기가 다를 수 있거나, 물리적 페이지는 크기가 다를 수 있거나, 익스텐트는 크기가 다를 수 있다. 익스텐트는 일부 실시형태에서 동적으로 재크기결정(증대 또는 축소)될 수 있다. 일부 실시형태에서는 논리적 블록에 대해 정적 할당이 사용될 수 있는 한편(예를 들어, 전체 논리적 블록에 대한 모든 물리적 저장소는, 블록의 크기 대비 기록 페이로드의 크기에 무관하게, 블록으로 지향된 제1 기록에 응답하여 할당될 수 있음), 다른 것들에서는 동적 할당이 사용될 수 있다. 논리적 블록 구성 및 대응하는 물리적 저장 공간 할당을 지배하는 다양한 기술 및 정책은 아래에서 더 상세히 설명된다. 일부 실시형태에서, 파일 저장 서비스에 의해 관리되는 여러 다른 파일 스토어는 구별되는 블록/페이지/익스텐트 크기결정 및 구성 정책을 구현할 수 있다. 사용되는 파일 시스템 인터페이스가 클라이언트가 특정할 수 있게 하는 기록 크기에 종속하여, 클라이언트로부터의 소정 기록 연산은 일부 경우에서 전체 페이지라기보다는 페이지의 일부분만의 수정을 초래할 수 있다. 소정 구현에서, 물리적 페이지가 저장 서브시스템에 의해 지원되는 기록에 대해 최소 원자성(atomicity) 레벨이지만, 기록 요청이 임의 양의 데이터로 지향될 수 있으면(즉, 기록이 페이지-정렬되어야 할 필요가 없고 진정수의 페이지의 모든 콘텐츠를 수정할 필요가 없음), 일부 기록은 판독-수정-기록 시퀀스로서 저장 서비스 내에서 내부적으로 처리될 수 있다. 일부 그러한 실시형태에서 페이지 경계를 횡단하지 않는 기록에 대해 채용될 수 있는 낙관적 조건부-기록 기술에 관한 상세는 아래에서 제공된다. 일반적으로, 각각의 저장 디바이스 및/또는 저장 서비스 노드는 적어도 일부 실시형태에서 복수의 다른 고객에 대한 연산을 지원하고 그리고/또는 그에 대한 데이터를 저장할 수 있다.
일반적으로, 고객으로부터 수신된 단일 파일 스토어 연산 요청에 대해 판독 또는 수정되어야 할 수 있는 메타데이터 및/또는 데이터는 복수의 저장 서비스 노드 간 분산될 수 있다. 예를 들어, 삭제 연산, 이름변경 연산 등은 수 개의 다른 저장 디바이스 상에 위치하는 메타데이터 구조의 다수의 요소에 대한 업데이트를 요구할 수 있다. 순차적 일관성 모델에 따라, 적어도 하나의 실시형태에서, 하나의 메타데이터 서브시스템 노드에서의 제1 메타데이터 수정 및 다른 메타데이터 서브시스템 노드에서의 제2 메타데이터 수정을 포함하는, 파일 시스템 메타데이터 수정 그룹을 포함하는 원자 메타데이터 연산은 단일 클라이언트 요청에 응답하도록 수행될 수 있다. 순차적 일관성을 지원하는 다양한 분산형 업데이트 프로토콜이 여러 다른 실시형태에서 사용될 수 있다 - 예를 들어, 아래에서 더 상세히 설명되는 분산형 트랜잭션 메커니즘은 적어도 일부 실시형태에서는 그러한 멀티-페이지, 멀티-노드 또는 멀티-익스텐트 업데이트에 대해 사용될 수 있다. 물론, 사용되는 복제 전략에 종속하여, 메타데이터 수정의 각각의 하나는 일부 실시형태에서는 순차로 복수의 익스텐트 복제본에 대한 업데이트를 수반할 수 있다.
일부 실시형태에서, 객체 이름변경 프로토콜, 커넥션 장수를 고려하는 부하 밸런싱 기술, 이름공간 관리 기술, 클라이언트 세션 메타데이터 캐싱, 오프셋-기반 정체 제어 정책 등의 사용과 같은, 파일 저장 서비스의 다양한 태양과 연관된 최적화 기술이 채용될 수 있다. 저장 서비스의 이들 특징에 관한 상세는 다양한 도면의 설명과 함께 아래에서 제공된다.
파일 저장 서비스 개관
도 1은, 적어도 일부 실시형태에 따른, 분산형 파일 저장 서비스의 하이-레벨 개관을 제공한다. 도시된 바와 같이, 저장 서비스(102)를 포함하는 시스템(100)은 적어도 3개의 서브시스템으로 논리적으로 분할될 수 있다: 저장 서브시스템(130), 메타데이터 서브시스템(120) 및 액세스 서브시스템(110). 각각의 서브시스템은, 저장 서브시스템(130)의 저장 노드(SN)(132A, 132B), 메타데이터 서브시스템(120)의 메타데이터 노드(MN)(122A, 122B), 및 액세스 서브시스템(110)의 액세스 노드(AN)(112A, 112B)와 같은, 복수의 노드를 포함할 수 있다. 각각의 노드는, 예를 들어, 일부 실시형태에서는 각각의 물리적 또는 가상화형 서버에서 실행되는 프로세스 또는 스레드 세트로서 구현될 수 있다. 어느 소정 서브시스템에서라도 노드의 수는 적어도 일부 실시형태에서는 다른 서브시스템에서의 노드의 수와는 독립적으로 수정될 수 있고, 그리하여 서브시스템 중 어느 것에서라도 필요에 따른 추가적 자원의 전개는 물론 (서브시스템 중 어느 것에서의 자원의 유사하게 독립적인 감축도) 가능하게 한다. 용어 "액세스 서버", "메타데이터 서버" 및 "저장 서버"는 여기에서는 각각 용어 "액세스 노드", "메타데이터 노드" 및 "저장 노드"의 균등물로서 사용될 수 있다.
묘사된 실시형태에서, 저장 노드(132)는, 예를 들어, SSD 및 회전 디스크의 소정 조합을 사용하여 (저장 노드(132A)에서의 익스텐트(134A, 134), 및 저장 노드(132B)에서의 익스텐트(134K, 134L)와 같은) 익스텐트(134)를 저장하는 것을 책임지고 있을 수 있다. 예를 들어 소정 물리적 저장 디바이스 세트에서 (전형적으로는 그러나 항상 그렇지는 않은) 인접 저장 공간의 소정 수의 기가바이트를 포함할 수 있는 익스텐트는 일부 실시형태에서는 저장 복제의 단위를 표현할 수 있다 - 그리하여, 어느 소정 논리적 익스텐트의 소정 수의 물리적 복제본이라도 저장될 수 있다. 각각의 익스텐트 복제본은 일부 실시형태에서는 소정 수의 물리적 페이지로서 조직될 수 있으며, 판독 또는 기록하는 가장 작은 단위를 표현하는 페이지는 저장 서브시스템 내에 구현된다. 도 4에 대해 아래에서 논의되는 바와 같이, 소정 파일 스토어 객체(예를 들어, 파일 또는 메타데이터 구조)는 논리적 블록 세트로서 조직될 수 있고, 그리고 각각의 논리적 블록은 데이터 익스텐트 내에서의 페이지 세트에 매핑될 수 있다. 파일 스토어 객체에 대한 메타데이터는 (데이터에 대한 대응하는 논리적 블록과는 잠재적으로 다른 크기의) 논리적 블록 세트를 자체가 포함할 수 있고, 다른 익스텐트(134)의 페이지에 저장될 수 있다. 복제 상태 머신은 적어도 일부 실시형태에서는 익스텐트 복제본에 대한 업데이트를 관리하도록 사용될 수 있다.
액세스 서브시스템(110)은, 묘사된 실시형태에서는 파일 시스템 API(애플리케이션 프로그래밍 인터페이스)(140)와 같은, 하나 이상의 파일 시스템 인터페이스를 클라이언트(180)에 제시할 수 있다. 적어도 일부 실시형태에서, 아래에 더 상세히 설명되는 바와 같이, 부하 밸런서(load balancer)(예를 들어, 저장 서비스 자체와는 독립적으로 구성될 수 있는 소프트웨어 또는 하드웨어 디바이스) 세트는 액세스 서브시스템과 저장 서비스의 클라이언트 간 중개자로서 역할할 수 있다. 일부 경우에서, 부하 밸런싱 기능성의 적어도 일부 태양은 액세스 서브시스템 자체 내에 구현될 수 있다. 적어도 일부 실시형태에서, 액세스 서브시스템 노드(112)는 클라이언트(180)에 의해 병행 사용되고 있는 적합한 네트워크 패브릭 내에 확립된 서비스 종단점을 표현할 수 있다. 도 3에 대해 아래에서 설명되는 바와 같이, 일부 실시형태에서는 고립형 가상 네트워크와 연관된 특별 네트워크 주소가 AN(112)에 배정될 수 있다. AN(112)는, 예를 들어, 클라이언트의 네트워크 신원은 물론 사용자 신원에도 기반하여 들어오는 클라이언트 커넥션을 인증할 수 있다; 일부 경우에 AN는 능동 디렉터리 서비스 또는 커버로스와 유사한 신원/인증 서비스와 상호작용할 수 있다. (NFSv4 및 SMB2.1과 같은) 분산형 파일 저장 서비스(102)에 의해 지원될 수 있는 일부 파일 시스템 프로토콜은 파일 서버가, 예를 들어, 로크 및 열린 파일 식별자와 관련 있는 상태를 유지하고 있도록 요구할 수 있다. 일부 실시형태에서, 로크 및 열린 파일 상태를 포함하는 영속성 서버 상태는 액세스 서브시스템보다는 메타데이터 서브시스템(120)에 의해 취급될 수 있고, 결과로서 액세스 서브시스템은 필요에 따라 업 및 다운 스케일링될 수 있는 대체로 무상태 서버 플리트라고 생각될 수 있다. 일부 실시형태에서, 도 6에 대해 아래에서 설명되는 바와 같이, AN(112)는 다양한 파일 스토어 객체와 관련 있는 메타데이터 상태를 캐싱할 수 있고, 메타데이터 노드와의 상호작용을 요구함이 없이 저장 노드에 직접 적어도 일부 내부 I/O 요청을 제출하도록 그 캐싱된 메타데이터를 사용할 수 있다.
메타데이터 서브시스템(120)은 묘사된 실시형태에서는, 예를 들어, 아이노드의 논리적 균등물, 액세스 제어 리스트(ACL)와 같은 파일/디렉터리 속성, 링크 카운트, 수정 시간, 실제 파일 크기, 저장 서브시스템 페이지를 가리키는 논리적 블록 맵 등을 포함하는 다양한 유형의 파일 스토어 메타데이터 구조를 관리하는 것을 책임지고 있을 수 있다. 부가적으로, 메타데이터 서브시스템은 일부 실시형태에서는 파일 스토어 객체의 열림/닫힘 상태를 그리고 다양한 파일 스토어 객체 상의 로크를 추적하고 있을 수 있다. 메타데이터 서브시스템(120)은, NFS 클라이언트에 의해 예상된 닫힘-대-열림 시맨틱스와 같은, 소망의 파일 스토어 객체 일관성 시맨틱스를 유지하고 있도록 연산을 시퀀싱 및 조정할 수 있다. 메타데이터 서브시스템은 또한, 예를 들어, 아래에서 설명되는 분산형 트랜잭션 기술을 사용하여, 이름변경, 삭제, 잘라버림 및 덧붙임과 같은, 다수의 메타데이터 요소를 수반할 수 있는 연산을 가로질러 순차적 일관성을 보장할 수 있다. 메타데이터 서브시스템(120)이 저장 서브시스템(130)과는 논리적으로 독립적이기는 하지만, 적어도 일부 실시형태에서, 영속적 메타데이터 구조는 저장 서브시스템에서 저장될 수 있다. 그러한 실시형태에서는, 메타데이터 구조가 저장 서브시스템에 물리적으로 저장될 수 있더라도, 메타데이터 서브시스템 노드는 사용될 특정 저장 노드를 식별시키는 것, 메타데이터로 지향된 저장 연산을 조정 또는 시퀀싱하는 것 등과 같은 그러한 태스크를 책임지고 있을 수 있다. 적어도 일부 실시형태에서, 메타데이터 서브시스템은 일부 실시형태에서는, 저장 서브시스템의 합의-기반 상태 복제 머신과 같은, 저장 서브시스템에 의해 채용된 상태 관리 기술 중 일부를 재사용할 수 있다.
파일 저장 서비스의 제공자 네트워크 구현
앞서 언급된 바와 같이, 일부 실시형태에서 분산형 저장 서비스는 제공자 네트워크의 자원을 사용하여 구현될 수 있고, 제공자 네트워크의 컴퓨트 인스턴스에서 실행되는 클라이언트 또는 애플리케이션에 의한 파일-관련 연산에 사용될 수 있다. 일부 실시형태에서, 제공자 네트워크는 복수의 지리적 영역으로 조직될 수 있고, 그리고 각각의 영역은, 여기에서는 "가용성 존"이라고 칭해질 수도 있는, 하나 이상의 가용성 컨테이너를 포함할 수 있다. 순차로 가용성 컨테이너는, (예를 들어, 전력-관련 장비, 냉각 장비 및 물리적 보안 컴포넌트와 같은 독립적 기반구조 컴포넌트로) 소정 가용성 컨테이너에서의 자원이 다른 가용성 컨테이너에서의 장애로부터 격리되는 그러한 식으로 엔지니어링된, 하나 이상의 구별되는 장소 또는 데이터 센터를 포함할 수 있다. 하나의 가용성 컨테이너에서의 장애는 어느 다른 가용성 컨테이너에서의 장애도 초래할 것으로 예상되지 않을 수 있다; 그리하여, 자원의 가용성 프로파일은 다른 가용성 컨테이너에서의 자원의 가용성 프로파일과는 독립적이도록 의도된다. 다양한 유형의 애플리케이션은 각각의 가용성 컨테이너에 다수의 애플리케이션 인스턴스를 론칭함으로써 단일 장소에서의 장애로부터 보호될 수 있다. 저장 서비스의 다양한 서브시스템의 노드는 또한, 예를 들어, 다양한 파일 스토어에 대한 데이터 중복 요건 및/또는 서비스의 가용성/업타임 목표에 따라 일부 실시형태에서는 수 개의 다른 가용성 컨테이너를 가로질러 분산될 수 있다. 동시에, 일부 구현에서는, 동일한 지리적 영역 내에 상주하는 (분산형 파일 저장 서비스에 사용되는 호스트 또는 저장 디바이스와 같은) 자원들 간 저렴한 그리고 낮은 레이턴시 네트워크 접속성이 제공될 수 있고, 그리고 동일한 가용성 컨테이너의 자원들 간 네트워크 전송은 훨씬 더 고속일 수 있다. 일부 클라이언트는, 그들 애플리케이션의 다양한 컴포넌트가 실행되는 바로 그곳의 소망 제어 정도를 유지하고 있도록, 그들 파일 스토어에 사용되는 자원 중 적어도 일부가, 예를 들어, 영역 레벨에서든, 가용성 컨테이너 레벨에서든, 또는 데이터 센터 레벨에서든 예약 및/또는 인스턴스화되는 장소를 특정하기를 바랄 수 있다. 다른 클라이언트는, 자원이, 예를 들어, 성능, 높은 가용성 등에 대한 클라이언트 요건을 만족하는 한, 그들 자원이 예약 또는 인스턴스화되는 바로 그 장소에는 관심이 더 적을 수 있다.
적어도 일부 실시형태에서, 소정 데이터 센터 내에서의 자원은 예상된 가용성 또는 장애 허용성 레벨에서의 차이에 기반하여 서브-그룹으로 더 파티셔닝될 수 있다. 예를 들어, 데이터 센터에서의 하나 이상의 서버 랙은, 랙 내에서의 상관된 장애의 확률이 적어도 일부 실시형태에서는 다른 랙을 가로지르는 상관된 장애의 확률보다 더 높을 수 있으므로, 더 낮은-레벨 가용성 컨테이너로서 지정될 수 있다. 적어도 일부 실시형태에서, 저장 서비스의 다양한 컴포넌트 또는 노드를 어디에서 인스턴스화할지 결정할 때, 설명된 가용성 컨테인먼트의 다양한 레벨(예를 들어, 영역 레벨, 데이터 센터 레벨 또는 랙 레벨)의 어느 조합이라도 성능 목표 및 영속성 목표와 함께 고려될 수 있다. 그리하여, 일부 유형의 저장 서비스 컴포넌트에 대해서는, 랙 레벨에서의 중복/복제가 충분하다고 생각될 수 있고, 그래서 일반적으로 다른 랙은 동일한 기능을 제공하는(또는 동일한 데이터/메타데이터의 복제본을 저장하는) 다른 컴포넌트에 사용될 수 있다. 다른 컴포넌트에 대해서는, 중복/복제가 데이터 센터 레벨에서 또는 영역 레벨에서 또한 또는 대신 구현될 수 있다.
도 2는, 적어도 일부 실시형태에 따라, 파일 저장 서비스를 구현하기 위해 제공자 네트워크(202)의 복수의 가용성 컨테이너(212)에서의 자원의 사용을 예시한다. 묘사된 실시형태에서는, 3개의 가용성 컨테이너(212A, 212B, 212C)가 도시되어 있으며, 그 각각은 저장 서비스의 소정 수의 저장 노드, 메타데이터 노드 및 액세스 노드를 포함한다. 각각의 가용성 컨테이너는 전형적으로는 가용성 컨테이너 경계를 횡단하는 상관된 장애 이벤트를 방지하도록 셋업되므로, 소정 파일 스토어에 배정되는 저장 서비스 노드 세트는 전형적으로는 여러 다른 가용성 컨테이너를 가로질러 확산되어 있을 수 있다. 일부 파일 스토어는 다른 것들보다 더 낮은 가용성 또는 영속성 요건을 가질 수 있고, 그래서 적어도 일부 실시형태에서는 단일 가용성 컨테이너 내에 구현될 수 있음을 주목한다. 일 실시형태에서, 파일 저장 서비스가 셋업될 때, 노드 풀은 수 개의 가용성 컨테이너(212)의 각각에서의 3개의 서브시스템의 각각에 대해 확립될 수 있으며, 그로부터 특정 노드는 필요에 따라 소정 파일 스토어에 배정될 수 있다. 다른 실시형태에서, 예비-구성된 저장 서비스 노드 풀을 확립하는 대신에, 새로운 노드가 필요에 따라 인스턴스화될 수 있다.
소정 파일 스토어 또는 파일 시스템에 대한 파일 저장을 집합적으로 구현하는 AN, MN 및 SN의 집합은 그 파일 스토어에 대한 "노드 세트"(250)라고 지칭될 수 있다. 도 2에 도시된 실시형태에서, 저장 서비스 노드는, 서브시스템 중 어느 것의 소정 노드라도 수 개의 다른 클라이언트 및/또는 수 개의 다른 고객으로부터의 요청을 취급하는 것을 책임지고 있을 수 있다는 점에서, 멀티-테넌트이다. 다양한 실시형태에서, 소정 고객(예를 들어, 대리에 의해 저장 서비스에서 과금 계정이 확립된 사업체 또는 개인)은 묘사된 실시형태에서는 수 개의 다른 파일 스토어를 셋업할 수 있음과, 많은 다른 클라이언트 디바이스(프로그램 인터페이스가 인보크될 수 있는 컴퓨팅 디바이스)는 소정 고객에 의해 또는 그를 대리하여 단일 파일 스토어에 파일 서비스 요청을 발행하도록 사용될 수 있음을 주목한다. 적어도 일부 실시형태에서, 다수의 사용자 계정(예를 들어, 고객 사업 조직의 여러 종업원의 각각에 대한 하나 이상의 사용자 계정)은 단일 과금 계정의 보호 하에 셋업될 수 있고, 그리고 사용자 계정의 각각은 각종 클라이언트 디바이스로부터 파일 저장 요청을 제출할 수 있다.
고객(C1)의 파일 스토어(FS1)에 사용된, 도 2의 노드 세트(250A)는 2개의 가용성 컨테이너(212A, 212B) 간 분산된 SN(132A, 132B, 132K), MN(122A, 122B, 122F), 및 AN(112A, 112B, 112H)을 포함한다. 다른 고객(C2)의 파일 스토어(FS2)에 사용된 노드 세트(250B)는 3개의 가용성 컨테이너(212A, 212B, 212C)에서의 노드를 포함한다: SN(132B, 132K, 132L, 132P), MN(122B, 122F, 122G, 122R), 및 AN(112B, 112M). 고객(C1)의 파일 스토어(FS3)에 사용된 노드 세트(250C)는 가용성 컨테이너(212C)의 노드를 단독으로 사용한다: SN(132P, 132Q), MN(122R, 122S), 및 AN(112M, 112N). 소정 파일 스토어에 사용되게 되는 특정 노드는, 예를 들어, 저장 서비스의 배치 컴포넌트에 의해 다양한 인자에 기반하여 온-디맨드 선택될 수 있고, 그리고 노드 세트는 변하는 저장 공간 요구, 성능 요구, 장애 등을 고려하여 시간의 흐름에 따라 변할 수 있다. 단일 저장 노드에서의 소정 저장 디바이스는 적어도 일부 실시형태에서는 다른 클라이언트에 속하는 데이터 및/또는 메타데이터를 저장할 수 있다. 적어도 일부 실시형태에서, 단일 익스텐트는 복수의 클라이언트 또는 고객의 데이터 및/또는 메타데이터를 포함할 수 있다.
적어도 SN에 대해, 중복 또는 복제는 일부 실시형태에서는 소정 파일 스토어에 대해 수 개의 다른 차원을 따라 구현될 수 있다. 소정 파일에서의 데이터의 양이 증대함에 따라, 예를 들어, 파일의 다양한 논리적 블록은 일반적으로 여러 다른 논리적 익스텐트에 매핑될 수 있다. 그리하여, 파일 스트라이핑은 논리적-블록 레벨에서 구현될 수 있으며, I/O 요청의 소정 패턴에 대해 성능을 개선하는 것을 도울 수 있고 또한 파일에 사용되는 저장 노드 또는 디바이스 중 하나가 실패하는 경우 큰 파일을 복구하는데 걸리는 시간을 감축할 수 있다. 파일에 대한 메타데이터는 일부 구현에서는 또한 다수의 메타데이터 논리적 익스텐트를 가로질러 스트라이핑되고 다수의 MN에 의해 관리될 수 있다. (데이터에 대해서든 메타데이터에 대해서든) 각각의 논리적 익스텐트는 순차로, 예를 들어, 소망의 데이터 영속성 정도를 달성하도록 소거 코딩 또는 완전 복제를 사용하여 여러 다른 가용성 컨테이너(212)에서의 다수의 SN를 가로질러 복제될 수 있다. 앞서 언급된 바와 같이, 적어도 하나의 실시형태에서, 복제는, 예를 들어, 다른 복제본에 대해 동일한 데이터 센터 내에서의 다른 랙을 선택함으로써 더 낮은-레벨 가용성 컨테이너를 가로질러 구현될 수 있다. AN 및 MN은 또한, 어떤 AN 또는 MN이 실패하면, 그 작업부하가 그 중복 그룹의 다른 멤버에 의해 신속히 차지될 수 있도록, 일부 실시형태에서는 중복 그룹으로 조직될 수 있다.
일부 실시형태에서, 제공자 네트워크(202)는 다양한 고객을 대리하여 "고립형 가상 네트워크"(IVN)의 확립을 지원할 수 있다. 소정 고객에 대해 셋업된 (일부 환경에서는 가상 사설 클라우드 또는 VPC라고 지칭될 수도 있는) IVN는, 고객이 통하여 네트워킹 구성에 대해 실질적 제어를 승인받는, 제공자 네트워크의 논리적으로 고립된 섹션에서의 컴퓨팅 및/또는 다른 자원의 집합을 포함할 수 있다. 일부 실시형태에서, 예를 들어, 고객은 IVN 자원에 사용될 IP(인터넷 프로토콜) 주소 범위를 선택하고, IVN 내에서의 서브넷의 생성, 및 IVN에 대한 루트 테이블, 게이트웨이 등의 구성을 관리할 수 있다. IVN 내에서의 디바이스 중 적어도 일부에 대해, 네트워크 주소는, 적어도 디폴트에 의해서는, IVN 밖에서는 보이지 않을 수 있다. IVN와 고객의 외부 네트워크(예를 들어, 고객의 데이터 센터 또는 사무소 부지에서의 디바이스) 간 접속성을 가능하게 하기 위해, 사설 주소와의 사용을 위해 구성되는(그래서 사설 가상 인터페이스라고 칭해질 수 있는) 가상 인터페이스 및 가상 사설 게이트웨이가 셋업될 수 있다. 일부 실시형태에서는, 하나 이상의 VPN(가상 사설 네트워크)가 (고객의 사무소 네트워크 또는 고객의 데이터 센터와 같은) 외부 네트워크와 고객의 IVN 간 구성될 수 있다. 적어도 일부 실시형태에서, 그러한 VPN는 IPSec(인터넷 프로토콜 보안), SSL/TLS(보안 소켓 계층/전송 계층 보안), DTLS(데이터그램 전송 계층 보안) 등과 같은 보안 네트워킹 프로토콜을 이용할 수 있다.
일부 실시형태에서, 보안 또는 다른 이유로, 분산형 저장 서비스에 의해 관리되는 소정 파일 스토어로의 액세스는 하나 이상의 IVN 내에서의 특정 클라이언트 디바이스 세트로 한정될 수 있다. 도 3은, 적어도 일부 실시형태에 따라, 고립형 가상 네트워크(302)와 연관된 네트워크 주소가 저장 서비스의 액세스 서브시스템 노드에 배정되는 구성을 예시한다. 그러한 주소 배정의 결과로서, 네트워크 주소가 또한 IVN 내에 놓여 있는 그들 클라이언트만이 AN(112)를 통하여 파일 스토어에 액세스할 수 있을 수 있다. 도시된 바와 같이, 도 3에서의 제공자 네트워크(202)는 SN(132A-132F), MN(122A-122F), 및 AN(112A-112F)를 포함한다. 2개의 IVN(302A, 302B)는, 각각 고객(A, B)에 대해, 제공자 네트워크(202)에 셋업되었다. 각각의 IVN는, 파일 저장 서비스를 요구하는 애플리케이션이 실행될 수 있는, 가상 컴퓨팅 서비스(302)의 소정 수의 컴퓨트 인스턴스(CI)를 포함한다. IVN(302A) 내에 도시된 CI(예를 들어, CI(380A, 380B)) 및 (302B) 내에 도시된 CI(380K, 380L)에 부가하여, 묘사된 실시형태에서는 다른 CI(예를 들어, 380P 및 380Q)가 또한 IVN 밖의 인스턴스 호스트 상에서 실행될 수 있다 - 그리하여, 파일 저장 서비스의 모든 클라이언트가 반드시 IVN(302)에 속할 필요가 있는 것은 아니다.
IVN(302A) 내에서의 CI로부터 파일 저장 서비스로의 액세스를 가능하게 하기 위해, AN(112A, 112D)에는 IVN(302A)과 연관된 사설 IP(인터넷 프로토콜) 주소(350A)가 배정되었다. 결과로서, IVN(302A)의 클라이언트 CI(380A, 380B)는 주소(350A)를 사용하여 파일 저장 서비스 인터페이스를 인보크할 수 있고, 파일 저장 서비스와 상호작용할 때 IVN에 대해 이미 구현된 다양한 네트워크 고립 및 보안 특징에 의존할 수 있다. 유사하게, AN(112D, 112E)에는 IVM(302B)의 사설 네트워크 주소가 배정되어, IVN(302B)의 클라이언트 CI(380K, 380L)로부터의 보안 액세스를 가능하게 할 수 있다. (112D와 같은) 소정 AN에는 적어도 일부 실시형태에서는 하나보다 많은 네트워크 주소가 배정되어, 단일 AN의 자원이 다수의 IVN에 의해 공유될 수 있게 할 수 있음을 주목한다. 다른 실시형태에서, 각각의 AN는 하나에 불과한 IVN의 네트워크 주소로 제한될 수 있다. 사설 주소에 부가하여, 일부 실시형태에서는, 공중 네트워크 주소(예를 들어, 공중 인터넷으로부터 액세스가능한 IP 주소)가 또한 AN(112C)과 같은 적어도 일부 AN에 사용되어, IVN의 부분이 아닌 (380P) 또는 (380Q)와 같은 CI로부터의 액세스를 가능하게 할 수 있다. 일 실시형태에서는, 제공자 네트워크(202) 밖에 위치하는 클라이언트도 공중 IP 주소를 사용하여 저장 서비스에 액세스할 수 있을 수 있다. 일부 실시형태에서, 단일(사설 또는 공중) 네트워크 주소는 복수의 AN(112)에 배정될 수 있어서, 예를 들어, 들어오는 작업 요청은 다수의 AN을 가로질러 밸런싱될 수 있고, 그리고 AN 페일오버는 클라이언트에 충격을 주지 않고 구현될 수 있다(예를 들어, 클라이언트는 특정 AN이 실패한 후에도, 동일한 네트워크 주소를 갖는 나머지 AN이 계속 클라이언트 요청에 응답할 수 있기 때문에, 동일한 주소에 파일 스토어 요청을 계속 보낼 수 있다).
논리적 블록, 페이지 및
익스텐트
도 4는, 적어도 일부 실시형태에 따라, 파일 저장 서비스 객체, 논리적 블록, 및 하나 이상의 익스텐트에서의 물리적 페이지 간 매핑을 예시한다. 3개의 논리적 블록(LB)(402A, 402B, 402C)이 파일(F1)에 대해 구성되었다. 파일 또는 메타데이터 구조와 같은 소정 객체의 여러 다른 논리적 블록의 콘텐츠는 전형적으로는 구별되는 저장 장소에서 저장될 수 있으므로, 논리적 블록은 여기에서는 스트라이프라고 지칭될 수도 있다. 일부 실시형태에서는, 파일(F1)의 스트라이프(A, B, C)와 같은 스트라이프의 물리적 분리가 시행될 수 있다 - 예를 들어, 소정 객체의 어느 2개의 스트라이프도 동일한 물리적 저장 디바이스에서 저장되지는 않을 수 있다. 다른 실시형태에서, 스트라이프의 물리적 분리는 명시적 시행 없이, 예를 들어, 다수의 물리적 디바이스를 가로지르는 스트라이프의 무작위 또는 준-무작위 분산의 사용에 기인하여 높은 확률로 일어날 수 있다. 적어도 일부 실시형태에서, 논리적 블록 크기는 소정 파일 또는 메타데이터 구조 내에서 달라질 수 있다. 다른 실시형태에서, 적어도 일부 저장 서비스 객체의 모든 논리적 블록은 동일한 크기일 수 있다. 각각의 논리적 블록(402)의 콘텐츠는 묘사된 실시형태에서는 소정 데이터 익스텐트(434)의 하나 이상의 물리적 페이지(PP)(412)에 저장될 수 있다. 그리하여, 예를 들어, LB(402)의 콘텐츠는 저장 노드(132D)의 데이터 익스텐트(434C)에서의 PP(412J, 412K, 412L)에 기록되었다. LB(403)의 콘텐츠는 저장 노드(132B)의 데이터 익스텐트(434A) 내에서의 PP(412B)에 저장되고, 그리고 LB(404)의 콘텐츠는 저장 노드(132C)에서의 저장 익스텐트(434B)에서의 PP(412F)에 저장된다. 블록과 페이지 간 매핑의 논의를 단순화하기 위해, 익스텐트 복제본은 도 4에 도시되지 않는다. 적어도 묘사된 실시형태에서, 익스텐트의 복제에 사용된 기술은 블록을 페이지에 매핑하는데 사용된 기술과는 독립적일 수 있다.
적어도 일부 실시형태에서는, 아래에서 더 상세히 설명되는 바와 같이, 동적 온-디맨드 할당이 물리적 저장소에 사용될 수 있으며, 그에 따라 소정 기록 요청의 기록 페이로드를 저장하는데 실제 필요한 페이지 세트만이 기록 요청이 수신될 때 실제 할당될 수 있다. 특정 LB의 논리적 블록 크기가 8 메가바이트이고, 64 킬로바이트의 고정 페이지 크기가 LB이 매핑되는 익스텐트에 사용되고 있고, 그리고 LB로 지향된 제1 기록이 56 킬로바이트의 기록 페이로드를 포함하는 일례의 시나리오를 고려한다. 그러한 시나리오에서는, 온-디맨드 할당이 사용되고 있는 실시형태에서 요청에 응답하여 저장 공간의 하나의 페이지(64 킬로바이트)만이 할당될 수 있다. 다른 실시형태에서는, 기록 페이로드 크기와 무관하게, LB로 지향된 제1 기록 요청에 응답하여 전체 LB에 대한 물리적 저장소를 따로 떼어 둘 수 있다.
클라이언트가 처음으로 특정 파일에 기록할 때, 선택된 메타데이터 서브시스템 노드는 하나 이상의 논리적 블록(402)에 대한 메타데이터(475)를 발생시킬 수 있다(예를 들어, 논리적 블록 크기 대비 기록 페이로드의 크기에 종속하여, 하나보다 많은 논리적 블록이 일부 경우에서는 요구될 수 있다). 이러한 메타데이터(475) 자체는 묘사된 실시형태에서는 메타데이터 익스텐트(464)의 PP(412Q)와 같은 하나 이상의 물리적 페이지에 저장될 수 있다. 메타데이터 구조에 사용되는 블록 크기 및/또는 페이지 크기는 적어도 일부 실시형태에서는 대응하는 데이터에 사용되는 것들과는 다를 수 있다. 적어도 하나의 실시형태에서, 메타데이터 익스텐트는 데이터에 사용되는 것(예를 들어, 회전 디스크)과는 다른 클래스 또는 유형의 저장 디바이스(예를 들어, SSD)를 사용하여 저장될 수 있다. 일부 구현에서, 메타데이터의 적어도 일부 및 동일한 파일 스토어 객체에 대한 메타데이터의 적어도 일부는 동일한 익스텐트 상에 저장될 수 있다.
일부 실시형태에서는, 위에서 논의된 바와 같이, 메타데이터 익스텐트(464) 및/또는 데이터 익스텐트(434)의 콘텐츠가, 예를 들어, 각각의 데이터 영속성 요건을 만족하기 위해 복제될 수 있다. 그러한 실시형태에서, 아래에 더 상세히 설명되는 바와 같이, 논리적 익스텐트의 특정 복제본은 마스터 복제본으로서 선택될 수 있고, 그리고 익스텐트에 대한 업데이트는, 예를 들어, 대응하는 업데이트 요청이 성공하였음을 표시하기 전에 마스터로부터 요구된 수의 복제본에 대한 업데이트를 전파함으로써 마스터 복제본(또는 마스터 복제본이 상주하는 저장 노드)에 의해 개시 및/또는 조정될 수 있다.
소정 논리적 블록의 콘텐츠가 익스텐트의 어느 소정 복제본이라도 저장되는 저장 디바이스에 기록되는 순서는 달라질 수 있다 - 즉, 특정 1-메가바이트 논리적 블록에 대응하는 2개의 32-킬로바이트 물리적 페이지(P1, P2)가 디스크 또는 SSD 상에서 "P1 다음에 P2" 순서로 위치하고 있으면, 이것은 반드시 P1에서의 데이터가 P2에서의 데이터보다 논리적 블록 내에서 더 낮은 시작 오프셋을 가짐을 내포하지는 않을 수 있다. 일부 실시형태에서, 페이지는 그것들이 처음 기록된 후에, 예를 들어, 개선된 순차적 판독 또는 기록 성능을 용이하게 하기 위해 이동(즉, 그들 저장 디바이스 내에서 재배열)될 수 있다. 소정 익스텐트 또는 익스텐트 복제본 내에, 수 개의 다른 파일과 연관된 물리적 페이지가 저장될 수 있다 - 예를 들어, 메타데이터 익스텐트(634)에서는, F1 이외의 하나 이상의 파일의 블록-대-페이지 맵(또는 다른 메타데이터)이 PP(412P, 412R, 412S)에 저장될 수 있다. 유사하게, 페이지(412A, 412C, 412D, 412E, 412G, 412H, 412M)는 모두 F1 이외의 파일의 콘텐츠를 저장할 수 있다. 일부 실시형태에서는, 동일한 파일의 어느 2개의 논리적 블록이라도 동일한 익스텐트에(예를 들어, 익스텐트의 동일한 복제본 그룹에) 매핑되는 확률이 아주 낮을 수 있는 많은 충분한 수의 익스텐트가 확립될 수 있다. 그러한 시나리오에서는, 요청들이 (대부분의 경우에) 다른 저장 노드 및 다른 저장 디바이스로 지향될 수 있으므로, 동일한 파일의 다른 논리적 블록으로 지향된 병행 I/O 요청들에 병렬로 응답하는 것이 가능할 수 있다. 적어도 하나의 실시형태에서, 저장 시스템은 일반적으로는, 예를 들어, 특정 블록이 처음 기록되는 때 가용 자유 공간의 양과 같은 인자에 기반하여 특정 블록에 사용될 익스텐트를 선택함으로써 가용 익스텐트 간 외관상 무작위 또는 준-무작위 방식으로 논리적 블록을 분산시키려는 경향이 있을 수 있다.
도 5는, 적어도 일부 실시형태에 따라, 데이터 및 메타데이터 익스텐트에 대한 복제본 그룹(510)의 구성을 예시한다. 데이터 익스텐트(D1, D2)에 대한 2개의 복제본 그룹(510A, 510B)이 도시되어 있고, 그리고 메타데이터 익스텐트(M1, M2)에 대한 2개의 복제본 그룹(510C, 510D)이 도시되어 있다. 예시된 각각의 복제본 그룹은, 일반적으로 동일한 논리적 익스텐트의 2개의 물리적 복제본은 동일한 저장 디바이스 상에 또는 동일한 저장 노드에서의 다른 저장 디바이스 상에 저장되는 것이 때로는 사실일 수 있기는 하지만, 저장 서브시스템의 각각의 저장 노드(132)에서의 각각의 저장 디바이스(532)에서의 2개 이상의 복제본을 포함한다.
각각의 복제본 그룹(510)은 하나의 마스터 복제본 및 하나 이상의 비-마스터 복제본을 포함하는 것으로 도시되어 있다. 마스터 복제본은, 예를 들어, 복제 상태 머신 및/또는 합의-기반 업데이트 프로토콜을 사용하여 복제본 그룹의 멤버로의 기록을 조정하는 것을 책임지고 있을 수 있다. 일부 실시형태에서, 복제 상태 머신 및/또는 합의-기반 프로토콜은 또한 판독에 역시 사용될 수 있다. 복제 그룹에서의 복제본의 총 수는 복제본에서 저장되는 파일 데이터 및/또는 메타데이터에 대한 영속성 요건의 함수로서 달라질 수 있다. 도 5에서, 복제본(564A)은 그룹(510A)의 마스터 복제본이고, 복제본(565B)은 그룹(510B)의 마스터 복제본이고, 복제본(575B)은 복제본 그룹(510C)의 마스터 복제본이고, 그리고 복제본(576B)은 복제본 그룹(510D)의 마스터 복제본이다. 복제본 그룹(510A, 510C)은 2개의 비-마스터 복제본을 각각 포함한다(그룹(510A)에 대해서는 복제본(564B, 564C), 그리고 그룹(510B)에 대해서는 복제본(575A, 575C)). 소거-코딩 기술, 완전 복제, 또는 완전 및 소거-코딩된 복제본의 조합과 같은 다른 유형의 복제 기술이 다양한 실시형태에서 사용될 수 있다. 일부 실시형태에서, 다른 복제 기술은 다른 파일 스토어에 사용될 수 있다.
적어도 일부 실시형태에서는, 회전 자기 디스크에 기반하는 개별 또는 어레이형 디바이스 및/또는 SSD 중 하나 이상의 유형과 같은 각종 다른 저장 디바이스가 익스텐트 복제본을 저장하는데 이용가능할 수 있다. 일부 실시형태에서, 소정 저장 노드(132)는 수 개의 다른 유형의 저장 디바이스를 포함할 수 있는 한편, 다른 실시형태에서 소정 저장 노드는 단일 유형의 가용 저장 디바이스만을 가질 수 있다. 묘사된 실시형태에서, 저장 노드(132A, 132B, 132C)는 각각 SSD 디바이스(3개의 노드에서 각각 디바이스(532B, 532L, 532T))는 물론 회전 디스크-기반 디바이스(각각, 532A, 532K, 및 532S)도 갖는다. 일부 구현에서는, 데이터 익스텐트 복제본을 저장하기 위해, 메타데이터 익스텐트 복제본을 저장하기 위해, 또는 공간이 이용가능한 한 양 유형의 익스텐트를 저장하기 위해, 하나의 특정 저장 디바이스 기술이 선호될 수 있다. 일부 구현에서, 예를 들어, 메타데이터 익스텐트는 가능할 때 SSD 상에 저장될 수 있는 한편, 데이터 익스텐트는 더 값싼 회전 디스크 상에 저장될 수 있다. 일부 실시형태에서, 데이터 및/또는 메타데이터 익스텐트, 또는 그 일부는, 예를 들어 사용 레벨에 기반하여, 하나의 유형의 저장 디바이스로부터 다른 하나로 이주될 수 있다.
메타데이터 캐싱
도 6은, 적어도 일부 실시형태에 따라, 파일 저장 서비스의 액세스 서브시스템 노드에서 메타데이터를 캐싱하는 것과 연관된 상호작용의 예를 예시한다. 앞서 언급된 바와 같이, 일부 실시형태에서는 외부 부하 밸런서가 가용 액세스 서브시스템 노드 간 클라이언트 작업부하를 분산시키도록 구성될 수 있다. 도 6에 묘사된 실시형태에서, (파일로 지향된 기록 또는 판독과 같은) 서비스 요청(644A)은 클라이언트(180)로부터 부하 밸런서(646)에서 수신된다. 부하 밸런서(646)는 원래 서비스 요청(644A)에 사용되었던 것과는 다른 네트워크 커넥션을 통하여 대응하는 서비스 요청(644B)을 선택된 액세스 노드(112)에 포워딩한다.
액세스 노드(112)는 다양한 파일 스토어 객체에 관한 메타데이터 객체의 캐시(604)를 유지하고 있을 수 있다. 포워딩된 서비스 요청(644B)에 대응하는 적합한 페이지 세트를 저장하는 저장 서브시스템 노드(132)를 식별시키기에 충분한 메타데이터가 캐시(604)에 있게 되면, 액세스 노드는 저장 노드에 판독/기록 요청을 발행할 수 있다. 그렇지만, 메타데이터가 캐싱되어 있지 않으면, 액세스 노드(112)는, 화살표(693)에 의해 표시된 바와 같이, 선택된 메타데이터 서브시스템 노드(122)에 메타데이터 요청(650)을 제출할 수 있다. 앞서 언급된 바와 같이, 메타데이터 콘텐츠는 일부 실시형태에서는 저장 서브시스템 노드에서 실제 저장될 수 있다. (예를 들어, 메타데이터 관리 코드를 실행하는 프로세스를 포함할 수 있는) 메타데이터 노드(122)는, 다른 캐시 계층을 포함하는, 메타데이터의 인-메모리 세트(612)를 자체가 유지하고 있을 수 있다. 액세스 노드에 의해 요청된 메타데이터가 인-메모리 세트(612)에 있지 않으면, 메타데이터 노드는, 화살표(694)에 의해 표시된 바와 같이, 하나 이상의 저장 노드(132A)로부터 메타데이터를 포함하고 있는 페이지(654)를 획득하고 메타데이터를 그 인-메모리 세트(612)에 저장할 수 있다. 일부 경우에서, 클라이언트로부터의 요청(644A)은 새로운 메타데이터가 발생될 것을 요구할 수 있고(예를 들어, 요청이 파일에 대한 제1 기록이었으면, 메타데이터 노드는 파일의 제1 논리적 블록에 대한 메타데이터 엔트리를 생성할 수 있고), 그 경우 메타데이터 노드는 묘사된 실시형태에서는 요청(650)에 응답하기 전에 새로운 메타데이터가 저장 노드(132)에서 안전하게 저장되는 것을 보장할 수 있다.
적어도 클라이언트의 요청에 응답하는데 요구되는 저장 노드(132A)로부터 획득된 메타데이터의 부분(요청-관련 메타데이터(652)라고 칭함)은, 화살표(695)에 의해 표시된 바와 같이, 액세스 노드(112)에 제공될 수 있다. 액세스 노드는 메타데이터를 판독하고, 그것을 캐시(604)에 저장하고, 그리고, 화살표(696)에 의해 표시된 바와 같이, 판독 또는 기록 요청(들)(655)을 메타데이터에 의해 식별된 적합한 저장 노드(들)(132)에 제출할 수 있다. 저장 노드(들)(132B)는, 도 6에는 도시되지 않은, 판독/기록 요청(들)에 대한 응답을 제공할 수 있고, 그리고 액세스 노드는 일부 실시형태에서는 요청된 서비스 연산이 성공하였는지 여부를 표시하도록 클라이언트(180)에 응답할 수 있다. 액세스 노드(112)는, 메타데이터 서브시스템으로부터 메타데이터를 재-획득해야 할 필요 없이, 캐싱된 메타데이터를 사용하여 적어도 일부 후속 클라이언트 요청에 응답할 수 있을 수 있다.
묘사된 실시형태에서는, 명시적 캐시 실효 메시지 대신에, 타임아웃-기반 기술이 액세스 노드에서 메타데이터 캐시 엔트리의 잠재적 케케묵음을 관리하는데 사용될 수 있다. 그리하여, 액세스 노드(112)는 캐시(604)로부터 메타데이터의 어느 소정 요소라도 언제 퇴거시킬지 결정하도록 캐싱 타임아웃 설정(들)(608)을 사용할 수 있다. 일부 구현에서, 소정 메타데이터 엔트리는 단순히, 그것이 다른 클라이언트 요청에 대해 필요로 될 때까지 그것을 재-캐싱하려는 시도 없이, 그 타임아웃(608)이 만료한 후에 캐시(604)로부터 제거될 수 있다. 다른 구현에서, 또는 일부 선택된 유형의 메타데이터 엔트리에 대해서, 액세스 노드(112)는 그 캐시 타임아웃이 만료할 때 메타데이터 노드(122)로부터 메타데이터 엔트리를 재-요청하거나, 또는 메타데이터 엔트리가 유효한 채로 있는지 점검할 수 있다. 후자의 시나리오에서, 타임아웃은 엔트리가 재-유효성검증되거나 리프레시될 때마다 원래 값으로 재-설정될 수 있다. 메타데이터 노드(122)에서, 묘사된 실시형태에서는 메타데이터의 소정 논리적 블록에 대해 다른 유형의 타임아웃 설정이 사용될 수 있다. 메타데이터 노드(122)가 초기에 어떤 파일 스토어 객체에 대한 메타데이터를 발생시키고 메타데이터를 메타데이터 구조의 소정 논리적 블록에 저장할 때, 그 메타데이터 논리적 블록이 재-할당될 수 있기 전에 지나야 하는 최소 시간량을 표시하는, 메타데이터 블록 재-할당 부적격 타임아웃 기간이 시작될 수 있다. (그러한 메타데이터 재-할당은 결국에는, 예를 들어, 메타데이터가 블록에 저장되어 있는 객체가 삭제되는 경우에 일어날 수 있다). 블록 재-할당 부적격 타임아웃 설정(들)(614)은 전형적으로는 대응하는 블록 메타데이터에 대한 캐시 타임아웃 설정(608)보다 더 긴 시간 기간으로 설정될 수 있다. 예를 들어, 일 구현에서, 블록 재-할당 타임아웃 값은 2주일 수 있는 한편, 캐시 타임아웃 설정은 1일일 수 있다. 그러한 시나리오에서, 액세스 노드(112)는 매일마다 한 번 메타데이터의 소정 블록의 유효성을 재-점검할 수 있는 한편, 메타데이터 노드(122)는 블록의 초기 할당 이후 2주가 지나가기 전에 그 블록이 어떤 다른 목적으로 재-사용되지 않는 것을 보장할 수 있다.
일부 실시형태에서는, 타임아웃-기반 메커니즘을 사용하는 대신에, 명시적 리스 또는 로크가 액세스 노드에서 캐싱된 메타데이터 엔트리에 대해 사용될 수 있다. 적어도 하나의 실시형태에서는, 예를 들어 메타데이터의 어떤 요소가 더 이상 유효하지 않을 때 메타데이터 노드(122)가 실효 메시지를 내보낼 수 있는, 명시적 캐시 실효 메커니즘이 사용될 수 있다. 일 실시형태에서, 메타데이터 서브시스템은 메타데이터 변경에 응답하여 메타데이터의 블록을 "실효" 또는 "액세스불가능"인 것으로 마킹할 수 있다. 액세스 노드가 실효된 캐싱된 메타데이터를 사용하여 데이터 블록에 액세스하려고 시도할 때, 메타데이터가 실효되었음을 표시하는 오류 메시지가 메타데이터 서브시스템 또는 저장 서브시스템에 의해 액세스 노드에 반환될 수 있다. 그리하여, 캐싱된 메타데이터는 그러한 오류 메시지의 결과로서 묵시적으로 실효될 수 있다. 타임아웃-기반, 로크/리스-기반, 묵시적 및 명시적 실효-기반 전략의 다양한 조합이 액세스 노드에서 캐싱된 메타데이터에 대해 여러 다른 실시형태에서 사용될 수 있다.
라벨이 붙은 화살표(693, 694, 696)에 의해 표시된 것들과 같은, 도 6에 묘사된 상호작용 중 일부에서는, 저장 서비스의 일부 컴포넌트가 다른 컴포넌트의 클라이언트로서 역할할 수 있다. 예를 들어, 액세스 노드(112)는, 메타데이터 노드의 클라이언트로서 역할하여, 내부 요청(즉, 저장 서비스 내에서 발생되고 저장 서비스의 고객이 직접 액세스가능하지는 않은 네트워크 경로를 사용하는 요청)을 메타데이터 노드에 보낼 수 있다(화살표(693)). 유사하게, 메타데이터 노드 및 액세스 노드 양자는, 저장 노드의 클라이언트로서 역할하여, 내부 요청을 저장 노드(132)에 보낼 수 있다. 일부 실시형태에서, 다양한 서브시스템은 그러한 상호작용을 가능하게 하도록 저장 서비스의 다른 컴포넌트에 의해 인보크될 수 있는 내부 API를 구현할 수 있다. 저장 노드(132)는, 예를 들어, 특정 저장 서비스 API가 액세스 노드(112)로부터 인보크되었든 메타데이터 노드(122)로부터 인보크되었든 동일한 방식으로 응답할 수 있다. 그리하여, 적어도 일부 실시형태에서, 저장 서비스 노드는 그것들이 내부 요청을 수신하고자 하는 소스에 대해 얽매이지 않을 수 있다.
파일
스토어
정책
일부 실시형태에서, 클라이언트는 특정 파일 스토어에 대해 파일 저장 서비스의 거동의 다양한 태양을 제어하도록 실질적 융통성을 승인받을 수 있다. 예를 들어, 하나 이상의 관리 API는, 동일한 클라이언트 또는 다른 클라이언트를 대리하여 생성된 다른 파일 스토어에 대한 대응하는 요건과는 다를 수 있는, 특정 파일 스토어에 대한 영속성, 성능, 가용성 또는 다른 요건을 클라이언트가 설정 또는 수정할 수 있게 하도록 구현될 수 있다. 도 7은, 적어도 일부 실시형태에 따라, 파일 스토어에 대한 데이터 영속성, 성능, 및 논리적-대-물리적 데이터 매핑과 관련 있는 정책의 구별되는 조합의 사용의 예를 예시한다.
칼럼(704, 714)에서 제시된 바와 같이, FS1과 같은 소정 파일 스토어에 대해 각각 데이터 및 메타데이터에 대한 영속성 정책은 다를 수 있고, 그리고 FS1 및 FS2와 같은 다른 파일 스토어에서 사용된 영속성 정책은 데이터, 메타데이터 또는 양자에 대해 다를 수 있다. FS1에 대해, 10-웨이 완전 복제가 메타데이터에 대해 사용되는 한편(메타데이터의 각각의 페이지의 10개의 완전 사본이 유지되고 있음), 12/6 소거 코딩이 데이터 영속성에 대해 사용된다(각각의 데이터 페이지의 12개의 소거 코딩된 사본이 저장되고, 그 중 6개는 페이지의 콘텐츠를 복원하는데 필요로 된다). 파일 스토어(FS1, FS2)의 메타데이터 및 데이터에 대한 성능 목표/요건은 각각 칼럼(706, 716)에 표시된다. 성능 목표는 다양한 단위, 예를 들어, (칼럼(706, 716)에서 라벨 "응답시간"에 의해 표시된) 응답 시간 또는 레이턴시에 대한 단위 대 (라벨 "tput"에 의해 표시된) 처리율에 대한 단위로 표현될 수 있고, 그리고 일부 경우에서 다른 요건 세트는 (라벨(W)에 의해 표시된) 기록에 대해서보다 (칼럼(706, 716)에서 라벨(R)에 의해 표시된) 판독에 대해서 특정될 수 있다. 성능 목표는, 예를 들어, 소정 파일 스토어의 메타데이터 또는 데이터에 대해 사용되어야 하는 저장 디바이스의 유형을 선택하도록 사용될 수 있다.
다른 접근법은 묘사된 실시형태에서는 각각의 파일 스토어에 대한 저장 객체에 대한 저장 공간을 할당하는데 사용될 수 있다. 예를 들어, 칼럼(708)에서 제시된 바와 같이, 512 킬로바이트의 고정 논리적 블록 크기 및 동적 페이지 할당의 정책이 FS1 메타데이터에 대해 사용되는 한편, FS2 메타데이터에 대해서는, 1-메가바이트 논리적 블록에 대한 물리적 저장소가 정적으로 할당될 수 있다. 칼럼(718)에서 제시된 바와 같이, FS1 데이터에 대해서는, 소정 파일의 처음 수 개의 논리적 블록이 1 킬로바이트, 1 킬로바이트, 2 킬로바이트, 2 킬로바이트 등으로 설정되는 가변 논리적 블록 크기가 사용될 수 있으며, 파일이 증대함에 따라 논리적 블록 크기는 점진적으로 증가한다. FS2 데이터에 대해서는, 대조적으로, 고정-크기 4-메가바이트 논리적 블록이 사용될 수 있다. 메타데이터에 대해 사용되는 물리적 페이지 크기는 다음과 같이 설정될 수 있다(칼럼(710)): FS1에 대해서는 8 킬로바이트 및 FS2에 대해서는 16 킬로바이트. 데이터에 대해, 칼럼(720)에서 제시된 바와 같이, 페이지 크기는 FS1에 대해서는 논리적 블록 크기와 같게 설정될 수 있는 한편, 페이지 크기는 FS2에 대해서는 32 킬로바이트로 설정될 수 있다. 도 6을 참조하여 위에서 논의된 메타데이터 캐시 타임아웃 및 블록 재할당 부적격 타임아웃을 포함하는, FS1 및 FS2에 대한 각각의 메타데이터 캐시-관련 설정은 칼럼(712)에서 제시되어 있다. 일부 실시형태에서는, 예를 들어, 파일 저장 서비스의 구현 복잡도를 감소시키기 위해, 영속성 정책, 블록 및 페이지 크기 결정 정책 등에 대해 이산 옵션 세트만이 지원될 수 있다. 가용성-관련 또는 업타임 요건, 파일 스토어 공간 한계 등과 같은 다른 유형의 정책은 또한 일부 실시형태에서는 다른 파일 스토어에 대해 다르게 설정될 수 있다. 적어도 하나의 실시형태에서, 클라이언트는 역시 파일-스토어-당 단위로 복수의 가격책정 정책 중으로부터 선택할 수 있을 수 있다 - 예를 들어, 일부 클라이언트는 저장-공간-사용-기반 가격책정 정책을 선택할 수 있는 한편, 다른 클라이언트는 파일 시스템 API-카운트-기반 가격책정 정책을 선택할 수 있다.
확장가능한
파일 저장 서비스를 구현하는 방법
도 8a는, 적어도 일부 실시형태에 따라, 확장가능한 분산형 파일 시스템 저장 서비스를 구현하도록 수행될 수 있는 관리-관련 연산 및 구성의 태양을 예시하는 순서도이다. 요소(801)에서 제시된 바와 같이, M개의 공백 익스텐트의 초기 세트는, 예를 들어, 서비스 초기화 프로시저 동안 분산형 파일 저장 서비스의 N개의 다른 저장 서브시스템 노드에서 데이터 및/또는 메타데이터에 대해 확립될 수 있다. 저장 서비스는 일부 실시형태에서는 제공자 네트워크에서 확립된 가상 컴퓨팅 서비스의 컴퓨트 인스턴스 상에서 실행되는 클라이언트 애플리케이션을 대리하여 파일 저장 연산을 구현하도록 셋업될 수 있다. 다양한 실시형태에서, 각각의 저장 노드는 복수의 익스텐트를 포함할 수 있다, 예를 들어, M은 N보다 더 클 수 있다. 익스텐트 콘텐츠가 데이터 영속성을 위해 복제되는 실시형태에서, M개의 공백 익스텐트의 각각은 논리적 익스텐트의 콘텐츠의 각각의 복제본을 저장할 수 있을 수 있다. 각각의 저장 노드는, 예를 들어 어떤 수의 회전 디스크-기반 디바이스 및/또는 고체-상태 저장 디바이스를 포함하는, 하나 이상의 저장 디바이스를 포함할 수 있다. 소정 익스텐트는 일부 실시형태에서는 단일 저장 디바이스 내에 편입될 수도 있고, 다른 실시형태에서는 다수의 저장 디바이스에 걸쳐 확산되어 있을 수도 있다. 일 실시형태에서, 모든 익스텐트는, 예를 들어, 저장 서비스와 연관된 구성가능한 파라미터에 기반하여 동일한 크기일 수 있다. 다른 실시형태에서, 다른 익스텐트는 다른 크기를 가질 수 있고, 그리고/또는 익스텐트의 크기는 시간의 흐름에 따라 변할 수 있다. 저장 서비스의 소정 인스턴스화에서의 익스텐트의 총 수는 시간의 흐름에 따라 달라질 수 있다 - 예를 들어, 메타데이터 및 데이터의 크기가 증대함에 따라, 더 많은 저장 디바이스 및/또는 더 많은 익스텐트가 전개될 수 있다. 익스텐트는 일부 실시형태에서는 저장 서비스의 데이터 및 메타데이터에 대해 복구의 단위를 표현할 수 있다 - 예를 들어, 각각의 익스텐트는, 소거 코딩, 완전 복제, 또는 복제 기술들의 어떤 조합을 사용하여, 영속성 정책 또는 설정에 기반하여 복제될 수 있다. 각각의 익스텐트 복제본 그룹(즉, 동일한 논리적 데이터 또는 메타데이터 익스텐트의 복제본의 그룹)은 (논리적 익스텐트에 대해 마스터 노드 또는 리더 노드라고 지칭될 수도 있는) 저장 노드가 그룹 멤버 간 업데이트를 조정하는 것을 책임지고 있는 마스터 복제본으로서 지정된 적어도 하나의 복제본을 포함할 수 있다. 일부 실시형태에서, 복제본 그룹의 멤버십 및/또는 마스터 선택에 관한 결정은 파일 스토어의 제1 객체가 기록될 때까지 연기될 수 있다. 적어도 일부 구현에서, 익스텐트는 멀티-테넌트일 수 있다 - 예를 들어, 각각의 익스텐트는 여러 다른 클라이언트 또는 고객의 데이터 또는 메타데이터를 저장할 수 있다.
소정 수의 액세스 서브시스템 노드는 묘사된 실시형태에서는 적어도 특정 파일 스토어(FS1)로의 액세스를 가능하게 하도록 초기에 확립될 수 있다(요소(804)). 예를 들어, 파일 스토어 클라이언트가 고립형 가상 네트워크(IVN)의 컴퓨트 인스턴스를 포함하는 일 실시형태에서는, IVN 내로부터만 액세스가능한 사설 IP 주소가 P개의 액세스 서브시스템 노드에 배정될 수 있다. 일부 실시형태에서는 또한 또는 대신 공중 IP 주소가 액세스 서브시스템 노드 중 일부 또는 전부에 배정될 수 있다. 일부 실시형태에서는, 부분적으로 예비-구성된 액세스 서브시스템 노드 풀이 셋업될 수 있고, 그리고 특정 액세스 노드가 풀로부터 특정 파일 스토어에 대해 배정될 수 있다; 다른 실시형태에서는, 액세스 노드가 온-디맨드 인스턴스화될 수 있다. 소정 네트워크 주소는 적어도 하나의 실시형태에서는 하나보다 많은 액세스 서브시스템 노드에 배정될 수 있다.
일부 실시형태에서, Q개의 메타데이터 노드의 세트는 파일 스토어 생성시 파일 스토어(FS1)에 배정될 수 있다. 다른 실시형태에서, (예비-구성된 풀로부터 선택될 수도 있고, 동적으로 인스턴스화될 수도 있는) 메타데이터 노드는, 예를 들어, (도 8b에 대해 아래에서 설명되는 바와 같이) 파일 또는 디렉터리와 같은 FS1의 객체에 대한 제1 기록 요청이 수신될 때 FS1에 온-디맨드 배정될 수 있다. 파일 저장 서비스의 관리 컴포넌트는 묘사된 실시형태에서는 액세스 서브시스템, 메타데이터 서브시스템 및 저장 서브시스템의 다양한 노드의 성능 및/또는 건전 상태를 모니터링할 수 있다(요소(807)). 어느 소정 클라이언트라도 대리하여 수행된 완료된 또는 성공한 파일 스토어 연산의 레코드는 저장될 수 있고, 그리고 그러한 레코드는 묘사된 실시형태에서는 클라이언트에 대한 사용-기반 과금량을 발생시키도록 추후 사용될 수 있다. 관찰된 성능 메트릭 및/또는 건전 상태 변화의 분석에 응답하여, 노드는 다른 계층의 파퓰레이션(population)에 영향을 미치지 않고 그리고 들어오는 파일 저장 요청의 스트림에 충격을 주지 않고 서브시스템 중 어느 것으로부터라도 동적으로 제거 또는 추가될 수 있다(요소(810)). 예를 들어, 액세스 서브시스템에서의 가능한 성능 병목의 검출, 또는 실패한 또는 무응답 액세스 서브시스템 노드의 검출에 응답하여, 다른 서브시스템 노드 중 어느 것에도 영향을 미치지 않고 더 많은 액세스 서브시스템 노드가 인스턴스화될 수 있다. 일부 경우에서, 하나 이상의 노드에서의 자원 이용(예를 들어, CPU 또는 저장소 이용)이 소정 시간 기간 동안 임계치 아래인 채로 있으면, 그러한 노드는 제거될 수 있고 그리고 그들 작업부하는 다른 노드 간 분산될 수 있다. 그리하여, 서브시스템의 각각은 필요에 따라 독립적으로 업 또는 다운 스케일링될 수 있다.
도 8b는, 적어도 일부 실시형태에 따라, 확장가능한 분산형 파일 시스템 저장 서비스에서 클라이언트 요청에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 파일 스토어(FS1)의 파일로 지향된 생성(예를 들어, "열기" API의 인보크) 또는 제1 기록 요청에 응답하여, 예를 들어, 공간은 하나 이상의 선택된 메타데이터 익스텐트 및 데이터 익스텐트에서 할당될 수 있다(요소(851)). 묘사된 실시형태에서, 메타데이터 서브시스템은 저장 서브시스템 노드에서 메타데이터 콘텐츠를 저장할 수 있다, 예를 들어, 메타데이터에 대해 순 별개 저장 계층을 구현하는 대신에 저장 서브시스템의 저장 능력이 메타데이터에 재-사용될 수 있다. 다른 실시형태에서, 별개 저장 서브시스템은 데이터에 대해 사용되기보다는 메타데이터에 대해 사용될 수 있다. 소망 데이터 영속성을 달성하도록 복제가 사용되고 있는 실시형태에서, 공간은, 예를 들어, 적합한 익스텐트 복제본 그룹의 모든 멤버에 대해 복수의 메타데이터 및/또는 데이터 익스텐트에서 할당될 수 있다. 특정 익스텐트는 여러 다른 실시형태에서 다양한 인자에 기반하여 - 예를 들어, 익스텐트가 현재 얼마나 가득 차 있는지에 기반하여, 생성되는 객체의 성능 요건 대비 익스텐트의 성능 특성에 기반하여 등 제1 기록에 응답하기 위해 하나 이상의 페이지를 할당하도록 선택될 수 있다. 적어도 일부 실시형태에서는, 익스텐트를 선택할 때 파일 스토어의 객체의 현재 "확산"이 또한 고려될 수 있다 - 예를 들어, 저장 서브시스템은 동일한 저장 노드에서 또는 동일한 익스텐트에서 소정 파일 스토어의 데이터 또는 메타데이터의 너무 많은 블록을 저장하는 것을 회피함으로써 "핫 스폿"의 확률을 감축하려고 시도할 수 있다.
추가적 기록이 FS1 내에서의 객체로 지향될 때, 예를 들어, 적용가능한 스트라이핑 정책(즉, 논리적-블록-대-물리적-페이지 매핑 정책)에 기반하여 다른 저장 서브시스템 노드에서 추가적 공간이 데이터 및/또는 메타데이터에 대해 할당될 수 있고, 그리고 추가적 메타데이터 노드가 필요에 따라 구성될 수 있다(요소(854)). 3개의 서브시스템의 - 저장 서브시스템, 액세스 서브시스템 및 메타데이터 서브시스템의 - 각각의 노드는 적어도 일부 실시형태에서는 멀티-테넌시를 지원하도록 구성될 수 있다 - 예를 들어, 각각의 저장 서비스 노드는 동시에 수 개의 다른 클라이언트의 데이터/메타데이터를 저장하거나, 또는 그로부터의 저장 요청을 취급할 수 있다. 클라이언트는 그들 저장 요청에 대해 사용되고 있는 동일한 자원이 또한 다른 클라이언트로부터의 요청에 대해 사용되고 있는 것을 알고 있지 못할 수 있다. 각각의 저장 서비스 노드는, 예를 들어, 일부 실시형태에서는 제공자 네트워크의 서버 또는 호스트를 사용하여 실행될 수 있는 하나 이상의 프로세스 또는 스레드를 포함할 수 있다.
시간의 흐름에 따라, 디렉터리 또는 파일과 같은 소정 파일 스토어 객체에 대응하는 메타데이터는 결국 수 개의 다른 저장 노드에서의 수 개의 다른 익스텐트를 가로질러 분산되게 될 수 있다. 일부 파일 저장 연산(예를 들어, 이름변경 연산 또는 삭제 연산)은 하나보다 많은 익스텐트에서 또는 하나보다 많은 저장 노드에서 메타데이터에 대한 수정을 요구할 수 있다. 그러한 연산에 대한 요청에 응답하여, 저장 서비스는 순차적 일관성을 지원 또는 시행하는 방식으로 하나보다 많은 메타데이터 페이지 또는 하나보다 많은 메타데이터 익스텐트에서의 변경을 포함하는 원자 업데이트 연산을 수행할 수 있다(요소(857)). 양자가 아래에서 더 상세히 설명되는 분산형 트랜잭션 기술 또는 일관된 객체 이름변경 기술과 같은 여러 다른 유형의 일관성 시행 기술 중 어느 것이라도 여러 다른 실시형태에서 사용될 수 있다.
도 9는, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스에서 복제-기반 영속성 정책을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(901)에서 제시된 바와 같이, 소정 파일 스토어 객체(F1)의 데이터 및/또는 메타데이터에 대해 사용되게 되는 영속성-관련 파라미터 세트의 각각에 대한 값은, 예를 들어, 객체가 생성되는 때 결정될 수 있다. 파라미터는 복제본 카운트 - 예를 들어, 각각의 페이지, 그래서 일부 실시형태에서는 객체의 콘텐츠 또는 객체와 관련된 메타데이터의 콘텐츠를 저장하는 각각의 익스텐트의 복제본의 수를 포함할 수 있다. 복제 전략(예를 들어, 완전 복제가 사용되어야 하는지, 소거-코딩된 복제가 사용되어야 하는지, 또는 그러한 기술들의 어떤 조합이 사용되어야 하는지), 및/또는 가용 데이터 센터 자원 간 복제본의 배치는 또한 일부 실시형태에서는 파라미터로서 특정될 수 있다. 예를 들어, 저장 서비스가 복수의 가용성 컨테이너를 포함하는 일부 실시형태에서, 적어도 하나의 복제본은 K개의 가용성 컨테이너의 각각 내에 배치될 수 있다. 익스텐트 복제본의 적합한 세트는 그 후 파라미터에 따라 식별될 수 있다(요소(904)). 일부 실시형태에서, 특정 물리적 익스텐트는 다양한 후보에서 이용가능한 자유 공간의 양의 분석, 익스텐트 또는 그들 포함하고 있는 저장 서버에서의 최근 작업부하 레벨, 클라이언트 요청의 예상된 소스에 대한 로컬러티, 앞서 설명된 바와 같이 공간이 할당되고 있는 파일 스토어의 "확산", 또는 다른 메트릭에 기반하여 선택될 수 있다. 복제본 중 하나는 마스터 복제본으로서 지정될 수 있고, 그리고 그 저장 노드는 복제본 그룹의 멤버 간 파일 스토어 객체로 지향된 기록과 같은 다양한 연산을 조정하는 것을 책임지고 있는 리더로서 지정될 수 있다(요소(907)). 적어도 일부 실시형태에서, 소정 파일 스토어 객체로의 데이터 기록을 조정하기 위한 리더로서 선택된 특정 저장 노드는 또한 (메타데이터 중 적어도 일부가 데이터와는 다른 저장 노드에서 저장될 수 있더라도) 그 파일 스토어 객체에 대한 메타데이터 기록을 조정하기 위한 리더로서 선택될 수 있다.
클라이언트로부터 파일 스토어 객체의 논리적 블록으로 지향된 특정 기록 요청에 응답하여, 내부 기록 요청은 그 논리적 블록이 매핑되는 논리적 익스텐트의 마스터 익스텐트 복제본으로 지향될 수 있다(요소(910)). 그리하여, 예를 들어, 클라이언트의 요청을 수신한 액세스 노드는, 예를 들어, 적합한 메타데이터 서브시스템 노드로부터 추출된 메타데이터를 사용하여 논리적 블록에 대한 마스터 익스텐트 복제본을 우선 식별해야 하고, 그 후 마스터 복제본을 저장하는 저장 노드로 내부 기록 요청을 지향시킬 수 있다. 내부 기록 요청을 수신하는 것에 응답하여, 리더 노드는 복제본 그룹 멤버 간 기록 페이로드를 복제하도록 합의-기반 상태 관리 프로토콜의 상호작용을 개시할 수 있다(요소(913)). 적어도 일부 구현에서, 합의-기반 프로토콜은 상태 변화의 로그 레코드를 복제하도록 사용될 수 있고, 그리고 상태 자체의 표현은 소거 코딩을 사용하여 또는 완전 복제를 사용하여 복제될 수 있다. 프로토콜 상호작용의 결과로서 기록이 커밋팅되면, 예를 들어, 기록이 복제본 그룹 멤버 중 정족수에서 성공하면, 일부 실시형태에서는 요청하는 클라이언트는 결국 기록 요청이 성공하였다는 알림을 받을 수 있다. 다른 실시형태에서, 적어도 일부 유형의 연산 및 일부 파일 시스템 프로토콜에 대해, 클라이언트는 그들 요청이 성공하였는지 여부에 관한 표시를 반드시 제공받지는 않을 수 있다. 대신에, 예를 들어, 클라이언트는 성공하지 못한 것처럼 보이는 연산을 재시도할 것으로 예상될 수 있다.
도 10은, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스의 액세스 서브시스템 노드에서 메타데이터를 캐싱하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(1001)에서 제시된 바와 같이, 클라이언트가 분산형 파일 저장 서비스의 액세스 서브시스템 노드 세트에 파일 스토어-관련 요청을 제출할 수 있게 하는 서비스 종단점 주소가 구성될 수 있다. 일부 실시형태에서는, 앞서 논의된 바와 같이, 고립형 가상 네트워크 내에서만 액세스가능한 사설 IP 주소가 액세스 노드에 대해 배정될 수 있다. 다른 실시형태에서는, 비-IVN 클라이언트에 의해 액세스될 수 있는 공중 IP 주소가 또한 또는 대신 사용될 수 있다. 액세스 서브시스템 노드는 하나 이상의 산업-표준 파일 시스템 프로토콜(예를 들어, NFS, SMB, CIFS 등의 하나 이상의 버전)에 순응하는 다양한 유형의 커맨드, 시스템 호출 또는 API 인보크에 응답하도록 구성될 수 있다. 일부 실시형태에서, 소정 액세스 서브시스템 노드는 복수의 그러한 표준 또는 프로토콜에 따라 포맷팅된 커맨드에 응답할 수 있을 수 있다. 일 실시형태에서는, 전유 파일 시스템 인터페이스가 또한 또는 대신 지원될 수 있다.
API/프로토콜 중 하나에 따라 포맷팅되고 특정 파일 스토어 객체(F1)로 지향된 커맨드(예를 들어, 생성, 판독, 기록, 수정, 재구성 또는 삭제 커맨드)는 특정 액세스 노드(AN1)에서 수신될 수 있다(요소(1004)). AN1는, 예를 들어, 커맨드를 수락할지 거절할지 결정하도록 네트워크 신원(예를 들어, 소스 네트워크 주소), 사용자 신원(예를 들어, 사용자 계정 식별자) 또는 다른 인자에 기반하여 인증 및/또는 권한부여 연산 세트를 수행할 수 있다(요소(1007)).
커맨드가 인증/권한부여 점검을 통과하면, AN1는, 요청된 연산을 구현하도록 사용될, F1과 관련 있는 메타데이터가 획득되게 되는 메타데이터 노드(MN1)를 식별할 수 있다(요소(1010)). 그 후 액세스 노드(AN1)는 MN1에 메타데이터 요청을 제출할 수 있다(요소(1013)). 일부 실시형태에서, 적합한 메타데이터 노드의 식별은, 예를 들어, 저장 객체와 다른 메타데이터 노드 간 매핑을 관리하는 메타데이터 노드에 다른 요청의 제출을 자체가 수반할 수 있다. 파일 스토어 객체(F1)와 관련 있는 메타데이터의 블록이 그 후 AN1에서 획득될 수 있다. AN1는, 메타데이터의 블록이 언제 (잠재적으로 케케묵은 것으로서) 폐기되어야 하거나 재-유효성검증되어야 하는지를 표시하는 캐시 타임아웃 설정으로, 로컬 메타데이터 캐시에 메타데이터를 저장할 수 있다(요소(1016)). 적어도 일부 실시형태에서, 캐시 타임아웃 간격은 다른 목적으로(예를 들어, F1이 삭제되는 경우 다른 파일 스토어 객체(F2)에 대한 메타데이터를 저장하기 위해) 메타데이터의 블록을 리사이클링하도록 재-사용하는 것이 언제 수락될 수 있는지를 결정하기 위해 메타데이터 노드에서 사용된 메타데이터 블록 재-할당 타임아웃 설정보다 더 작은 값으로 설정될 수 있다.
AN1는 수신된 메타데이터 블록을 사용하여 내부 판독/기록 요청이 지향되어야 하는 특정 저장 노드(SN1)를 식별하고, 그에 따라 내부 요청을 제출할 수 있다(요소(1019)). 캐시 타임아웃의 만료 이전에, AN1는 캐싱된 메타데이터 블록을 재-사용하여 API/프로토콜의 추가적 인보크로부터 초래될 수 있는 추가적 내부 요청을 발행할 수 있다(요소(1022)). 캐시 타임아웃 기간의 종료시, 메타데이터 블록은 일부 실시형태에서는 실효된 것으로 마킹되거나 삭제될 수 있다. 적어도 하나의 실시형태에서, 메타데이터를 단지 폐기하는 대신에, 액세스 노드는, 예를 들어, 메타데이터가 획득되었던 메타데이터 노드에 다른 요청을 보냄으로써 그것을 재-유효성검증할 수 있다.
단일-페이지
업데이트에
대한 조건부 기록
앞서 논의된 바와 같이, 적어도 일부 실시형태에서 파일 저장 서비스는, 수천 개의 파일 스토어 객체로 잠재적으로 지향된, 수백 개 또는 수천 개의 클라이언트로부터의 다수의 병행 연산을 취급하도록 설계될 수 있다. 원자성 및 일관성을 보장하기 위한 전통적 로킹-기반 메커니즘은, 로킹 시스템 자체가 병목이 될 수 있으므로, 그러한 높은-처리율 높은-병행 환경에서는 작동하지 않을 수 있다. 따라서, 하나 이상의 낙관적 기법이, 아래에서 설명되는 바와 같이, 적어도 일부 실시형태에서는 병행 제어에 사용될 수 있다. 우선, 단일-페이지 기록(즉, 수정이 단일 논리적 익스텐트의 단일 페이지로 한정되는 기록 요청)에 대한 병행 제어 메커니즘이 설명되고, 그리고 원자 연산으로서 멀티-페이지 기록을 구현하도록 사용될 수 있는 분산형 트랜잭션 메커니즘이 추후 설명된다.
적어도 일부 구현에서, 위에서도 설명된 바와 같이, 소정 파일 스토어의 데이터 및 메타데이터를 저장하는데 사용된 물리적 페이지는 대응하는 객체의 논리적 블록과는 크기가 다를 수 있는 한편, 기록 연산은 일반적으로 임의 오프셋으로 지향되고 임의 크기의 기록 페이로드를 가질 수 있다. 예를 들어, 적어도 일부 파일 시스템 프로토콜/API에 대해, 파일의 최종 사용자의 관점에서, 파일에 대한 단일 기록은 파일 내에서의 어느 소망의 바이트-레벨 오프셋에서라도 시작하여 데이터를 수정할 수 있고, 그 바이트-레벨 오프셋으로부터 시작하여 어느 수의 바이트라도 수정(또는 처음으로 기록)할 수 있다. 그렇지만, 파일 저장 서비스의 저장 서브시스템은 일부 실시형태에서는 물리적 페이지를 원자성의 단위로서 처리할 수 있다 - 예를 들어, 구현 복잡도를 감축하기 위해, 페이지는 저장 서브시스템의 내부 판독 및 기록 API에 의해 지원되는 최소 세밀도를 표현할 수 있다. 그리하여, 최종 사용자에 노출된 파일 스토어 API의 융통성과, 저장 서브시스템에 의해 지원되는 내부 연산에 대한 제약 간에는 부정합이 있을 수 있다. 따라서, 저장 서브시스템의 클라이언트(예를 들어, 액세스 노드 또는 메타데이터 노드)는 그러한 실시형태에서는 임의 기록 요청을 페이지-레벨 내부 기록 연산으로 번역하도록 강제될 수 있다. 적어도 일부 실시형태에서, 외부 클라이언트 요청으로부터 직접 초래되지 않을 수 있는 적어도 일부 내부 메타데이터 조작은 일부 경우에서는 메타데이터의 소정 페이지의 작은 부분만을 수정할 필요가 있을 수 있다. 그러한 메타데이터 기록 요청은 또한 페이지 세밀도에서 구현되어야 할 수 있다.
따라서, 물리적 페이지로 지향된 적어도 일부 기록 연산은 판독-수정-기록 시퀀스로서 구현될 수 있다. 도 11은, 적어도 일부 실시형태에 따라, 기록 오프셋 및 기록 크기가 때로는 물리적 저장소의 원자 단위의 경계와 정렬되지 않을 수 있는 파일 저장 서비스에서 구현될 수 있는 판독-수정-기록 시퀀스의 예를 예시한다. 도시된 바와 같이, (파일 또는 메타데이터 구조와 같은) 파일 스토어 객체는, LB(1102A, 1102B, 1102C)를 포함하는, 논리적 블록(LB)(1102)의 세트로서 조직될 수 있다. 각각의 논리적 블록은 저장 서브시스템의 익스텐트(예를 들어, 하나의 논리적 익스텐트 및 복수의 물리적 익스텐트 복제본) 내에서의 페이지의 세트에 매핑될 수 있으며, 여기서 페이지는 저장 서브시스템의 API에 대해 원자성의 단위를 표현한다. 예를 들어, 논리적 블록(1102A)은 묘사된 실시형태에서는 익스텐트(1164)의 물리적 페이지(PP)(1112A, 1112B, 1112C, 1112D)에 매핑된다.
특정 기록 요청(1160)에 응답하여, (기록 요청(1160A)의 경우에는 PP(1112A)의 음영 부분, 및 기록 요청(1160B)의 경우에는 PP(1102D)의 음영 부분과 같은) 단일 페이지의 일부만이 실제로 변경되어야 할 수 있다. 그렇지만, 묘사된 실시형태에서는 저장 서브시스템 API가 부분적-페이지 기록을 허용하지 않을 수 있기 때문에, 도시된 기록 요청의 각각은 대응하는 물리적 페이지로 지향된 판독-수정-기록 시퀀스로 번역될 수 있다. 그리하여, 클라이언트(예를 들어, 내부 기록 요청(1160)을 발행한 액세스 노드 또는 메타데이터 노드)는 의도된 부분적 기록을 구현하기 위해 그것이 우선 표적 페이지를 판독하고, 소망 변경을 가하고, 그 후 전체 페이지의 기록을 제출하여야 한다고 결정할 수 있다. 기록 요청(1160A)에 대해서는, 페이지(1112A)의 판독, 클라이언트에서 페이지(1112A)의 콘텐츠의 로컬 수정, 및 전체 페이지(1112A)의 기록을 포함하는 판독-수정-기록 시퀀스(RMW)(1177A)가 구현될 수 있다. 기록 요청(1160B)에 대해서는, 페이지(1112D)의 판독, 다음에 수정 및 그 후 전체 페이지(1112D)의 기록을 수반하는 RMW(1177B)가 구현될 수 있다.
동일한 물리적 페이지에 요청되는 병행 또는 준-병행 업데이트의 가능성을 고려해 볼 때, 저장 서비스는 소정 물리적 페이지의 콘텐츠가 RMW 시퀀스의 판독과 RMW 시퀀스의 기록 사이에 수정되지 않았음을 보장하여야 할 수 있다. 적어도 일부 실시형태에서, 저장 서브시스템에서 복제 상태 관리를 위해 구현될 수 있는 논리적 타임스탬프 메커니즘은 아래에서 설명되는 바와 같이 그러한 순차적 일관성을 보장하도록 사용될 수 있다.
앞서 언급되고 도 5에서 도시된 바와 같이, 논리적 익스텐트의 복제본 그룹은 적어도 일부 실시형태에서는 소망 레벨의 데이터 영속성을 달성하도록 사용될 수 있다. 도 12는, 적어도 일부 실시형태에 따라, 익스텐트 복제본 그룹에 대한 합의-기반 복제 상태 머신의 사용을 예시한다. 논리적 익스텐트(E1)에 대해, 묘사된 실시형태에서는 4개의 익스텐트 복제본이 도시되어 있다: 저장 노드(132)에서의 마스터 복제본(1264A), 및 각각의 저장 노드(132B, 132C, 132D)에서의 비-마스터 복제본(1264B, 1264C, 1264D). 다른 논리적 익스텐트(E2)에 대해서는, 저장 노드(132D)에서의 마스터 익스텐트 복제본(1265C) 및 2개의 비-마스터 복제본((저장 노드(132A)에서의) 1265A, 및 (저장 노드(132B)에서의) 1265B)이 도시되어 있다. 합의-기반 복제 상태 머신(1232A)은 E1 복제본 상의 다양한 연산을 조정하도록 노드(132A)(마스터 복제본이 저장되는 노드)에 의해 사용될 수 있고, 그리고 다른 합의-기반 복제 상태 머신(1232B)은 E2 복제본 상의 연산을 조정하도록 노드(132D)(마스터 복제본(1265C)이 상주하는 노드)에 의해 사용될 수 있다.
상태 머신(1232A)은 묘사된 실시형태에서는 논리적 클록(1222A)을 이용할 수 있고, 그리고 상태 머신(1232B)은 다른 논리적 클록(1222B)을 이용할 수 있다. 논리적 클록은 대응하는 상태 머신을 사용하여 관리되는 다양한 연산의 상대적 순서화를 표시하도록 사용될 수 있고, 적어도 일부 실시형태에서는 벽-시계 시간 또는 어느 특정 물리적 시계와도 직접 관련되지는 않을 수 있다. 그리하여, 예를 들어, 특정 논리적 클록 값(LC1)은 상태 머신(1232A)을 사용하여 조정된 기록 연산의 커밋과 연관될 수 있고, 그리고 다른 논리적 클록 값(LC2)은 판독 연산에 대한 응답이 언제 복제본 그룹으로부터 제공되었는지를 표시할 수 있다. 이러한 예에서 LC1 < LC2이면, 이것은 저장 서브시스템의 관점에서 기록 연산이 판독 연산 이전에 완료되었음을 표시할 것이다. 논리적 클록의 값은 여기에서는 "논리적 타임스탬프"라고 또는 (그것들이 연관된 복제 상태 머신을 사용하여 다양한 판독 또는 기록 연산이 완료된 시퀀스를 표시할 수 있으므로) "연산 시퀀스 번호"라고 지칭될 수도 있다. 일부 구현에서는 마스터 복제본이 상주하는 저장 노드에서 구현된 정수 카운터가 논리적 클록으로서 사용될 수 있고, 그리고 그 저장 노드는 클록의 값에 대한 변경을 책임지고 있을 수 있다(예를 들어, 카운터는 상태 머신을 사용하여 판독 또는 기록 연산이 완료될 때마다 증분될 수 있다).
저장 노드는 상태 머신(1232)으로부터 획득된 논리적 타임스탬프 값을 위에서 설명된 RMW 시퀀스의 판독 및 기록 요청과 연관시킬 수 있고, 다양한 실시형태에서 특정 단일-페이지 기록이 커밋팅되어야 하는지 중단되어야 하는지 결정하도록 논리적 타임스탬프를 사용할 수 있다. 도 13은, 적어도 일부 실시형태에 따라, 일부 유형의 기록 연산에 사용될 수 있는 조건부 기록 프로토콜에 관여된 예시적 상호작용을 예시한다. 도시된 바와 같이, 특정 기록 연산에 대응하는 판독-수정-기록 시퀀스의 일부분으로서, (액세스 노드 또는 메타데이터 노드와 같은) 저장 서브시스템의 클라이언트(1310)는 저장 노드(132)(예를 들어, 페이지가 속하는 익스텐트의 마스터 복제본이 저장되는 노드)에 페이지 판독 요청(1351)을 제출할 수 있다. 저장 노드는 요청된 페이지의 콘텐츠뿐만 아니라 판독 연산에 배정된 판독 논리적 타임스탬프(RLT)도 포함하는 판독 응답(1352)을 제공할 수 있다. RLT는, 예를 들어, 익스텐트에 대해 사용되는 복제 상태 머신으로부터 획득될 수 있다.
RMW 시퀀스를 계속하여, 저장 서브시스템 클라이언트(310)는 후속하여 전체 페이지에 대한 기록 요청(1361)을 저장 노드(132)에 제출할 수 있고, 판독 응답에 포함되었던 RLT를 포함할 수 있다. 저장 노드는 RLT가 발생된 이후로 페이지가 성공적으로 업데이트되었는지 결정할 수 있다. RLT가 발생된 이후로 페이지가 업데이트되지 않았으면, 요청된 기록은 완료될 수 있고 그리고 성공을 표시하는 기록 응답(1362)은 저장 서브시스템 클라이언트에 제공될 수 있다. RLT가 발생된 이후로 다른 개입하는 기록 요청의 결과로서 페이지가 업데이트되었으면, 기록 요청은 거절될 수 있다. 그러한 기록 요청을 수락하는 것은 일부 경우에서는 데이터 모순을 초래할 수 있는데, 예를 들어, 소정 기록 요청에 응답하여 기록될 특정 데이터(D1)가 페이지로부터 앞서 판독된 값(R1)에 종속할 수 있고, 그리고 그 값(R1)은 개입하는 기록에 의해 겹쳐쓰였을 수 있기 때문이다. 일부 구현에서, 클라이언트(1310)로부터의 기록 요청이 거절되면, 기록이 중단되었음을 표시하는 기록 응답(1362)이 클라이언트에 제공될 수 있다; 다른 구현에서는 기록 응답이 제공되지 않을 수 있다. 기록이 중단되면, 클라이언트(1310)는, 예를 들어, 기록이 결국 성공할 때까지 또는 어떤 임계 수의 기록 시도가 실패할 때까지 일부 실시형태에서는 동일한 페이지에 대한 하나 이상의 추가적 RMW 시퀀스를 개시할 수 있다.
RLT가 발생된 이후로 동일한 페이지에 대한 개입하는 기록이 성공하였는지 검출하기 위해, 일부 실시형태에서는 기록 논리적 타임스탬프를 저장하는 기록 로그 버퍼가 저장 노드(132)에서 구현될 수 있다. 도 14는, 적어도 일부 실시형태에 따라, 조건부 기록 프로토콜을 구현하도록 확립될 수 있는 예시적 기록 로그 버퍼를 예시한다. 묘사된 실시형태에서, 각각의 원형 기록 로그 버퍼(1450)는, 예를 들어, 익스텐트의 마스터 복제본이 저장되는 저장 노드에서 각각의 논리적 익스텐트에 대해 유지되고 있다. 원형 버퍼(1450A)는, E1의 마스터 복제본(1410A)을 관리하는 저장 노드(1432A)에 의해, 익스텐트(E)에 대해 유지되고 있고, 그리고 원형 버퍼(1450B)는 E2의 마스터 복제본(1410B)이 저장되는 저장 노드(1432B)에 의해 유지되고 있다. 각각의 원형 버퍼는, 버퍼(1450A)에서의 레코드(1460A, 1460B, 1460C, 1460D) 및 버퍼(1450B)에서의 레코드(1460K, 1460L, 1460M, 1460N)와 같은, 복수의 기록 로그 레코드(1460)를 포함한다. 묘사된 실시형태에서 각각의 로그 엔트리(1460)는, 기록된 페이지 식별자, 기록의 완료와 연관된 논리적 타임스탬프, 및 대리에 의해 기록이 수행된 클라이언트를 표시하는, 커밋팅된(즉, 성공한) 페이지 기록의 각각의 표시를 포함한다. 그리하여, 버퍼(1450A)에서, 레코드(1460A-1460D)는, 각각의 식별자(1419A-1419D)를 갖는 클라이언트를 대리하여 각각의 기록 논리적 타임스탬프(1417A-1417D)에 의해 표시된 순서로, 식별자(1415A-1415D)를 갖는 페이지가 각각 기록되었음을 표시한다. 유사하게, 버퍼(1450B)는, 각각의 식별자(1419K-1419N)를 갖는 클라이언트를 대리하여 각각의 기록 논리적 타임스탬프(1417K-1417N)에 의해 표시된 순서로, 식별자(1415K-1415N)를 갖는 페이지가 각각 기록되었음을 표시한다. 적어도 일부 실시형태에서, 기록 로그 버퍼는 고속 액세스를 위해 주 메모리에 유지되고 있을 수 있다. 적어도 하나의 구현에서, 소정 레코드(1460)의 기록 논리적 타임스탬프는 버퍼 내에서의 그 레코드의 상대적 위치에 의해 묵시적으로 표시될 수 있다. 그리하여, 그러한 일 구현에서는, 기록 논리적 타임스탬프의 명시적 값이 버퍼에 저장될 필요가 없다. 일부 실시형태에서, 로그 버퍼는 영속적 메모리에 저장될 수 있고, 타임스탬프 값에 의한, 페이지 식별자에 의한, 그리고/또는 클라이언트 식별자에 의한 스피드 검색을 위해 셋업된 인덱스를 가질 수 있다. 다양한 실시형태에서, 도 14에 도시된 것과 유사한 기록 논리적 타임스탬프 정보는 다른 세밀도에서 - 예를 들어, 물리적 페이지 세밀도에서, 익스텐트 세밀도에서, 또는 어떤 다른 레벨에서 유지되고 있을 수 있다.
저장 노드(1432)가 판독-수정-기록 시퀀스의 특정 기록이 수락되어야 하는지 거절되어야 하는지 결정해야 하고, 그리고 기록 요청이 시퀀스의 판독 연산의 판독 논리적 타임스탬프(RLT)를 포함할 때, 그것은 RLT보다 더 큰 논리적 타임스탬프를 갖는 어느 기록이라도 동일한 페이지에 일어났는지 알아보도록 기록 로그 버퍼를 검사할 수 있다. 예를 들어, 페이지(P1)에 대한 RMW 시퀀스의 기록 요청에 대응하는 RLT 값이 V1이고, 레코드(1460) 중 최소 기록 논리적 타임스탬프는 V2 < V1이고, 그리고 값 V3 > V1을 갖는 버퍼에서의 레코드는 없으면, 그때 저장 노드(1432)는 페이지(P1)로의 개입하는 기록은 일어나지 않았다고 결론지을 수 있고, RMW의 기록은 수락될 수 있다. 페이지(P1)에 대해 기록 논리적 타임스탬프 V3 > V1를 갖는 엔트리가 있으면, 기록은 묘사된 실시형태에서는 거절 또는 중단될 수 있다. 원형 버퍼(1450)에서의 레코드 중 최소 기록 논리적 타임스탬프(V2)가 V1보다 더 크면, 이것은 P1으로 지향된 일부 기록이 RLT가 발생된 이후로 성공하였을 수 있지만 (예를 들어, 버퍼 공간 제한에 기인하여) 그들 기록 로그 레코드가 겹쳐쓰였을 수 있음을 표시할 수 있고, 그래서 적어도 일부 실시형태에서는 P1에 대한 기록 요청이 또한 그러한 시나리오에서는 거절될 수 있다. RMW의 기록 요청이 수락되면, 새로운 기록 로그 레코드(1460)는 기록의 커밋에 대응하는 기록 논리적 타임스탬프로 (앞서-발생된 로그 레코드를 잠재적으로 겹쳐쓰는) 원형 기록 로그 버퍼에 추가될 수 있다. (업데이트되어야 하는 복제본의 수, 및 사용되는 복제 프로토콜에 종속하여, 기록을 성공적으로 완료 또는 커밋팅하기에 충분한 복제본들에 수정이 전파되기 전에 소정 시간이 걸릴 수 있음을 주목한다).
원형 버퍼는 묘사된 실시형태에서는 버퍼에 사용된 메모리의 총량이 낮은 채로 있고, 그리고 예전 기록 로그 레코드가 더 유용한 최근 기록 로그 레코드에 의해 점진적으로 겹쳐쓰이게 되도록 사용될 수 있다. 특정 판독-수정-기록 시퀀스의 기록 연산은 전형적으로는 판독 후에 아주 신속히 수행될 것으로 예상되므로, 예전 기록 로그 레코드는 전형적으로는 RMW 시퀀스의 기록을 커밋팅할지 중단할지 결정하는데 많은 도움이 되지 않을 수 있다. 그렇지만, 위에서 논의된 바와 같이, 일부 시나리오에서는 익스텐트로의 기록은 잠재적으로 유용한 기록 로그 레코드가 원형 버퍼 내에서 겹쳐쓰이게 될 수 있을 정도로 빈번한 것이 사실일 수 있다. 일부 실시형태에서, 저장 서비스는 그러한 겹쳐쓰기 때문에 거절되는 기록의 수를 추적하고 있을 수 있다, 즉, 구체적으로는 버퍼의 가장 앞선 논리적 타임스탬프와 판독 논리적 타임스탬프의 비교(및 판독 논리적 타임스탬프가 가장 앞선 논리적 타임스탬프 전에 있다는 후속 결정)의 결과로서 야기된 기록 거절 비율이 모니터링될 수 있다. 일부 그러한 실시형태에서, 원형 로그 버퍼의 크기는 동적으로 수정될 수 있다 - 예를 들어, 그것은 버퍼 공간 제약으로부터 초래되는 기록 거절 비율이 소정 임계치를 초과하였다는 결정에 응답하여 증가될 수 있거나, 또는 그것은 단순히 과중한 작업부하 기간 동안 증가될 수 있다. 유사하게, 버퍼 크기는 버퍼 크기 제약에 기인하는 거절 비율이 소정 임계치보다 더 낮다는 결정에 응답하여 또는 가벼운 작업부하 기간 동안 감소될 수 있다. 일부 실시형태에서, 다른 유형의 버퍼(즉, 원형이 아닌 버퍼)가 사용될 수 있다. 적어도 하나의 실시형태에서, 클라이언트 식별자는 기록 로그 버퍼에 저장되지 않을 수 있다. 일부 실시형태에서는, 도 14에 도시된 것들과 유사한 버퍼가 기록뿐만 아니라 판독도 레코딩하도록 사용될 수 있다. 적어도 하나의 실시형태에서, 버퍼의 길이는 미결 판독-수정-기록 시퀀스의 판독의 타이밍에 기반하여 동적으로 조절될 수 있다. 예를 들어, 특정 RMW 시퀀스의 판독이 시간(T1)에서 일어나고, 그리고 버퍼가 그 시퀀스의 대응하는 기록 요청이 수신되기 전에 소정 시간(T2)에서 가득 차게 되면, 버퍼 크기는 대응하는 기록을 수락하는 것에 관하여 올바른 결정을 하려는 시도로 (예를 들어, 소정 최대 길이 임계치 및/또는 소정 최대 시간 임계치 내에서) 증가될 수 있다. 일부 그러한 시나리오에서, 대응하는 기록이, 가령 시간(T3)에서, 수신될 때, 버퍼 크기는 그 이전 길이로 다시 감축될 수 있다.
적어도 하나의 실시형태에서, 저장 서비스는 페이지-당 레벨에서 버저닝 정보를 유지하고 있고, RMW의 기록이 수락되어야 하는지 여부를 결정하도록 버저닝 정보를 사용할 수 있다. 예를 들어, 익스텐트-당 레벨에서 기록 연산의 로그 버퍼를 유지하고 있는 대신에, 하나의 그러한 버저닝 접근법에서, 로그 엔트리는 페이지-당 레벨에서 유지되고 있을 수 있어서, RMW의 기록이 대응하는 판독과 동일한 버전으로 지향되는지 결정하는 것이 가능하게 된다. 판독 이후로 새로운 버전이 생성되었으면, 기록은 거절될 수 있다.
도 15는, 적어도 일부 실시형태에 따라, 분산형 파일 시스템 저장 서비스에서 조건부 기록 프로토콜을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(1501)에서 제시된 바와 같이, 특정 파일 스토어 연산을 구현하기 위해, 특정 페이지(P) 상의 판독-수정-기록 시퀀스가 구현되어야 한다는 결정이 (액세스 노드 또는 메타데이터 노드와 같은) 저장 서브시스템의 클라이언트(C)에서 이루어질 수 있다. 일부 실시형태에서는, 전체 페이지가 수정되고 있더라도, 모든 단일-페이지 기록이 디폴트로 판독-수정-기록 연산으로 번역될 수 있다; 그리하여, 그러한 실시형태에서는, 어느 페이지로의 어느 기록이라도 RMW 시퀀스로 번역될 수 있고, 그리고 RMW가 필요로 되는지 여부에 관한 결정이 요구될 수 있다. 다른 실시형태에서, 전체 페이지를 수정하는 기록은 RMW 시퀀스로의 번역을 요구하지 않을 수 있는 한편, 페이지의 일부분만을 수정하는 기록은 RMW 시퀀스로 번역될 수 있다.
요소(1504)에서 제시된 바와 같이, RMW 시퀀스의 일부분으로서, P로 지향된 판독 요청은 저장 노드(SN1)(P가 속하는 익스텐트의 마스터 복제본이 저장되는 노드)에서 C로부터 수신될 수 있다. 판독이 동일한 익스텐트에서의 다른 판독 및 기록에 비해 수행되는 순서를 표시하는, 판독 요청에 대응하는 판독 논리적 타임스탬프(RLT)는, 예를 들어, P의 익스텐트를 관리하는데 사용되는 복제 상태 머신으로부터 획득될 수 있다(요소(1507)). RLT는 판독 요청을 제출한 클라이언트(C)에 제공될 수 있다.
후속하여, 페이지(P)로 지향된 RMW 시퀀스의 기록 요청(WR1)은 SN1에서 C로부터 수신될 수 있다(요소(1510)). 기록 요청은 요소(1507)의 판독 응답에서 C에 제공되었던 RLT 값은 물론, 기록 페이로드(즉, P에 가해질 수정)도 포함할 수 있다. 저장 노드(SN1)는, 예를 들어, 최근 성공적 기록과 연관된 논리적 타임스탬프를 저장하는 기록 로그 버퍼의 콘텐츠를 검사함으로써 RLT가 발생된 이후로 페이지(P)가 수정되었는지 결정할 수 있다. RLT가 발생된 이후로 P가 수정되지 않았다고 결정되면(요소(1513)), P에 적합한 수정을 하고 수정을 적합한 수의 복제본에 전파함으로써 기록이 구현될 수 있다(요소(1516)). 기록의 완료에 대응하는 기록 논리적 타임스탬프는 묘사된 실시형태에서는 기록 로그 버퍼에 저장될 수 있고, 그리고 적어도 일부 실시형태에서는 기록이 완료되었다는 표시가 RMW 시퀀스를 발행한 클라이언트에 보내질 수 있다. 일부 구현에서, 기록 논리적 타임스탬프는 완료 표시의 일부분으로서 클라이언트에 제공될 수 있다. RLT가 발생된 이후로 P가 수정되었다고 (또한 요소(1513)에 대응하는 연산에서) 결정되면, 기록은 거절될 수 있고 그리고 일부 실시형태에서는 "기록 중단됨" 응답이 클라이언트에 보내질 수 있다.
순서화된 노드 체인을 사용하는 분산형 트랜잭션
위에서 설명된 조건부 기록 기술은 다양한 실시형태에서 단일-페이지 기록 연산 간 순차적 일관성을 보장하도록 사용될 수 있다. 그렇지만, (삭제, 이름변경 등과 같은) 분산형 파일 저장 서비스의 연산의 일부 유형에 대해, 메타데이터 및/또는 데이터의 다수의 페이지는 원자성으로 수정되어야 할 수 있다 - 즉, 관여된 모든 페이지에 대한 모든 변경이 커밋팅되어야 하거나, 또는 모든 변경이 거절되어야 한다. 분산형 트랜잭션을 수반하는 더 높은-레벨 낙관적 일관성 시행 메커니즘이 적어도 일부 실시형태에서는 이러한 목적으로 채용될 수 있다. 그러한 일 실시형태에서 분산형 트랜잭션을 구현하기 위해, 조정자 노드(예를 들어, 관여된 메타데이터 및/또는 저장 노드 중 하나)가 선택될 수 있다. 조정자는 변경에 참가하여야 하는 저장 노드를 식별하고, 개개의 페이지-레벨 변경이 각각의 저장 노드에서 수락 또는 거절을 위해 조사되어야 하는 시퀀스를 결정하고, 그리고 그 후 노드의 각각이 그들 페이지-레벨 변경에 대한 각각의 커밋/중단 결정을 할 수 있는 저장 노드 간 순서화된 연산 시퀀스를 개시할 수 있다. 모든 참가자가 그들 로컬 변경이 커밋팅가능하다고 결정하면, 트랜잭션은 전체로서 커밋팅될 수 있는 한편, 참가자 중 어느 하나가 그들 로컬 페이지-레벨 변경이 커밋팅될 수 없다고 결정하면, 트랜잭션은 전체로서 중단될 수 있다. 조정자 및 참가자 노드의 연산의 다양한 태양에 관한 상세는 아래에서 제공된다.
도 16은, 적어도 일부 실시형태에 따라, 파일 저장 서비스에서 분산형 트랜잭션의 커밋을 초래할 수 있는 일례의 메시지 흐름을 예시한다. 예를 들어, 액세스 서브시스템 노드에서든 또는 메타데이터 노드에서든 특정 파일 스토어 연산이 다수의 페이지가 기록될 것을 요구한다는 결정이 이루어질 수 있다. 대응하는 멀티-페이지 기록 요청(1610)이 발생될 수 있다. 수정될 페이지의 세트는 여기에서는 트랜잭션의 "표적 페이지"라고 칭해질 수 있다. (다양한 실시형태에서 액세스 노드, 메타데이터 노드, 또는 저장 노드 중 어느 하나일 수 있는) 저장 서비스의 특정 노드는 표적 페이지로의 기록의 세트를 원자성으로 구현하도록 분산형 트랜잭션에 대한 조정자 노드(1612)로서 선택될 수 있다. 조정자는 수정되어야 하는 페이지의 세트 및 페이지-레벨 변경이 개시 또는 수행되어야 하는 (조정자가 저장 노드이면 자신을 포함할 수 있는) 저장 노드의 세트(예를 들어, 표적 페이지를 포함하고 있는 마스터 복제본 익스텐트가 저장되는 저장 노드의 세트)를 식별할 수 있다. 다양한 기술 중 어느 것이라도 조정자 노드를 선택하는데 사용될 수 있다 - 예를 들어, 일부 실시형태에서는, 수정될 페이지의 세트의 무작위-선택된 페이지가 상주하는 저장 노드가 조정자로서 선택될 수 있는 한편, 다른 실시형태에서는 후보 조정자 노드에서의 작업부하 레벨이 고려될 수 있고, 그리고 서비스의 저장 노드 간 트랜잭션 조정과 연관된 작업을 분산시키려는 시도가 행해질 수 있다.
적어도 일부 실시형태에서, 수정을 위한 표적 페이지가 로킹되어야 하는 시퀀스는 교착상태 회피 기술에 따라 조정자(1612)에 의해 결정될 수 있다. 예를 들어, 교착상태 분석 모듈은 트랜잭션에서 수정될 페이지 및 익스텐트의 식별자에 제공될 수 있고, 교착상태 분석 모듈은 로킹 순서를 결정하기 위해 소정 선택된 정렬 순서(예를 들어, 익스텐트 ID, 페이지 ID 및/또는 다른 인자의 연접에 기반하는 사전식 정렬 순서)에 기반하여 식별자를 정렬할 수 있다. 동일한 정렬 순서가 파일 스토어에 대한 모든 분산형 트랜잭션을 가로질러 일관되게 사용될 수 있고, 그리고 결과로서 어느 소정 쌍의 페이지(P1, P2)에 대해서라도 로크는 항상 동일한 순서로 요청될 수 있다. 예를 들어, 교착상태 분석 모듈이 트랜잭션(Tx1)에 대해 P1 상의 로크가 P2 상의 로크 전에 취득되어야 한다고 표시하면, 그것은 어느 다른 트랜잭션(Tx2)에 대해서도 결코 P2 상의 로크가 P1 상의 로크 전에 취득되어야 한다고 표시하지 않을 것이고, 그리하여 교착상태를 회피한다.
적어도 일부 실시형태에서, 분산형 트랜잭션의 예비 단계의 일부분으로서, 선택된 조정자 노드(1612)는 또한 표적 페이지로 지향된 판독 요청을 발행하고, 앞서 설명된 기술에 따라 그들 판독에 대한 대응하는 판독 논리적 타임스탬프(RLT)를 획득할 수 있다. 판독 논리적 타임스탬프는, 아래에서 설명되는 바와 같이, 표적 페이지가 상주하는 저장 노드의 각각에서 페이지-레벨 커밋 결정을 하는데 사용될 수 있다.
선택된 조정자 노드(1612)는 그 후, 각각의 페이지-레벨 커밋 결정을 위해 표적 페이지가 분석되어야 하는 순서, 그 순서로 페이지-레벨 커밋 결정을 하는 것을 책임지고 있는 저장 노드를 포함하는 노드 체인, 페이지에 이루어질 실제 변경(기록될 바이트), 및 표적 페이지의 각각에 대한 RLT의 표시를 포함하는, 트랜잭션-준비(Tx-준비(Tx-prepare)) 메시지(1642A)를 작성할 수 있다. 노드 체인(1602)은 일례로서 도 16에 도시되어 있다. 노드 체인의 최후 또는 말단 멤버(예를 들어, 노드 체인(1602)에서의 노드(1632C))는, 그 자신의 로컬 페이지-레벨 커밋 결정이 전체로서 트랜잭션의 커밋을 초래할 수 있으므로, "커밋 결정자" 또는 "결정자" 노드로서 지정될 수 있다.
조정자는 표적 페이지 중 적어도 하나(도 16에서는 논리적 익스텐트(E1)의 페이지(P1))를 저장하는, 노드 체인(1602)의 저장 노드(1632A)와 같은, 노드 체인의 제1 노드에 Tx-준비 메시지(1642A)를 송신할 수 있다. 노드(1632A)는 P1에 대한 변경이 커밋팅될 수 있는지 결정하기 위해, 예를 들어, 페이지(P1)에 대한 RLT를 사용하여 로컬 페이지-레벨 커밋 분석을 수행할 수 있다. 조건부 기록 및 RMW 시퀀스에 대해 앞서 설명된 것과 유사한 기술을 사용하여, 그 RLT가 획득된 이후로 P1이 수정되지 않았으면, P1에 대한 변경은 커밋팅가능하다고 여겨질 수 있다. RLT가 획득된 이후로 P1이 수정되었으면, 변경은 거절되어야 할 수 있다(거절 시나리오는 도 17에서 예시되고 아래에서 설명된다; 도 16은 모든 페이지-레벨 커밋 결정이 긍정인 시나리오를 예시한다). P1에 대한 제안된 변경이 커밋팅가능하다고 가정하면, 노드(1632A)는 P1을 로킹하고(예를 들어, 익스텐트(E1)에 대해 사용된 복제 상태 머신에 의해 관리되는 로크를 취득하고) "의도 레코드"를 영속적 저장소에 저장할 수 있다. 페이지(P1)가 로킹되는 한, 판독 또는 업데이트는 묘사된 실시형태에서는 어느 다른 트랜잭션 또는 어느 다른 RMW 시퀀스를 대신해서도 P1 상에 수행될 수 없다. 의도 레코드는 노드(1632A)가 P1에 대한 제안된 수정을 수행하려고 의도하고, 나머지 체인 멤버도 그들 각각의 페이지-레벨 수정을 수행하는데 동의할 수 있으면, 그렇게 할 것임을 표시할 수 있다. 노드(1632A)는 그 후 노드 체인의 다음 노드(1632B)에 (콘텐츠가 (1642A)의 그것들과 유사하거나 똑같을 수 있는) Tx-준비 메시지(1642B)를 송신할 수 있다.
유사한 로컬 페이지-레벨 커밋 분석이 논리적 익스텐트(E5)의 페이지(P7)에 대해 노드(1632B)에서 수행될 수 있다. 노드(1632B)가 (예를 들어, Tx-준비 메시지(1642B)에 포함되었던 P7의 RLT를 사용하여) 그 로컬 페이지-레벨 변경이 커밋팅가능하다고 결정하면, 노드(1632B)는 P7 상의 로크를 취득하고, 그 자신의 의도 레코드를 저장하고, ((1642B)와 유사하거나 똑같은) Tx-준비 메시지(1642C)를 결정자 노드(1632C)에 송신할 수 있다.
결정 노드(1632C)(체인에서의 말단 또는 최후 노드)는 익스텐트(E8)의 페이지(P9)에 대해 그 자신의 페이지-레벨 커밋 분석을 수행할 수 있다. 페이지(P8)에 대한 제안된 수정이 커밋팅가능하면(예를 들어, P8의 RLT가 조정자에 의해 획득된 이후로 P8로의 기록이 수행되지 않았으면), 결정자는 트랜잭션이 전체로서 커밋팅되어야 한다고 결정할 수 있고, P8에 대한 제안된 변경을 수행 또는 개시할 수 있다. 결정자 노드는 분산형 트랜잭션이 커밋팅되어야 함을 표시하는 Tx-커밋(Tx-commit) 메시지(1644A)를 발생시키고, 그것을 체인의 다른 노드에 송신할 수 있다. 묘사된 실시형태에서, Tx-커밋은 Tx-준비 메시지의 전파에 비해 역순으로 순차적으로 전파될 수 있다. 다른 실시형태에서, Tx-커밋은 조정자 및/또는 비-결정자 노드 중 일부 또는 전부에 병렬로 보내질 수도 있고, 도 16에서 도시된 것과는 다른 순차적 순서로 보내질 수도 있다.
체인(1602)의 비-결정자 노드가 Tx-커밋 메시지를 수신할 때, 그것은 그 로컬 페이지-레벨 수정을 수행 또는 개시하고, 로컬 표적 페이지(예를 들어, 노드(1632B)의 경우에는 P7 그리고 노드(1632A)의 경우에는 P1) 상의 로크를 해제하고, 그것이 페이지에 대해 앞서 발생시켰던 의도 레코드를 삭제하고, (요구되면) Tx-커밋 메시지를 다른 노드에 송신할 수 있다(예를 들어, 노드(1632B)는 Tx-커밋 메시지(1644B)를 노드(1632A)에 보낼 수 있고, 그리고 노드(1632A)는 Tx-커밋 메시지(1644C)를 다시 조정자에 보낼 수 있다). 조정자 노드(1612)가 Tx-커밋 메시지를 수신할 때, 일부 실시형태에서 그것은 멀티-페이지 기록(1610)의 요청자에 기록 성공 응답(1650)을 송신할 수 있다. 교착상태를 회피하도록 결정된 예비-결정된 순서로 로컬 페이지-레벨 커밋 분석을 수행하고, Tx-준비 메시지가 수신되고 로컬 커밋 분석이 성공할 때만 페이지를 로킹하고, 그리고 의도 레코드를 (그것들이, 예를 들어, 트랜잭션이 완료되기 전에 일어날 수 있는 장애의 결과로서 의도 레코드를 책임지고 있는 저장 노드가 대체되는 경우 액세스될 수 있는) 영속적 저장소에 저장하는 위에서 설명된 기술들은 모두 분산형 저장 서비스에서 다수의 기록에 대해 원자성을 요구하는 연산의 복구가능성 및 효율을 증가시키는 것을 도울 수 있다.
적어도 일부 실시형태에서, 소정 분산형 트랜잭션에 대해 식별된 노드 체인의 저장 노드 중 어느 하나라도, 그 로컬 커밋 분석에 기반하여, 그 로컬 페이지에 대한 제안된 수정이 수락가능하지 않다고 결정할 수 있고, 그래서 전체로서 트랜잭션의 중단을 개시할 수 있다. 도 17은, 적어도 일부 실시형태에 따라, 파일 저장 서비스에서 분산형 트랜잭션의 중단을 초래할 수 있는 일례의 메시지 흐름을 예시한다. 도 16의 경우에서와 같이, 노드(1612)는 멀티-페이지 기록 요청(1610)에 응답하여 시도되는 분산형 트랜잭션의 조정자로서 선택될 수 있다. 조정자는, 로컬 페이지-레벨 커밋 결정이 이루어져야 하고 로크가 취득되어야 하는 순서를 결정하는 것, 노드 체인(1602)을 발생시키는 것 및 Tx-준비 메시지(1642A)를 생성하는 것과 같은, 도 16의 맥락에서 설명된 것들과 유사한 트랜잭션의 예비 연산 세트를 수행할 수 있다. Tx-준비 메시지는 조정자(1612)에 의해 체인의 제1 노드(1632A)에 보내질 수 있다.
노드(1632A)는 그 로컬 커밋 분석을 수행하고, 익스텐트(E1)의 페이지(P1)에 대한 제안된 변경이 수락가능하다고 결정할 수 있다. 도 16에서 도시된 시나리오에서와 같이, 노드(1632A)는 P1 상의 로크를 취득하고, 의도 레코드를 영속적 저장소에 저장하고, Tx-준비 메시지(1642B)를 체인(1602)의 다음 노드(1632B)에 송신할 수 있다. 도 17에 예시된 시나리오에서, 노드(1632B)는 익스텐트(E5)의 페이지(P7)에 대한 제안된 변경이, 예를 들어 그 RLT가 조정자(1612)에 의해 획득된 이후로 P7이 성공적으로 수정되었기 때문에, 수락가능하지 않다고 결정할 수 있다. 따라서, 그것이 P7에 대한 제안된 수정을 수행하고자 함을 표시하는 의도 레코드를 저장하는 대신에, 노드(1632B)는 트랜잭션이 중단되어야 함을 표시하는 Tx-중단(Tx-abort) 메시지(1744A)를 대신 발생시킬 수 있다. Tx-중단 메시지(1744A)는 묘사된 실시형태에서는 수신된 Tx-준비 메시지(1642B)가 유래한 노드에 보내질 수 있기는 하지만, 다른 실시형태에서 그것은 성공적 로컬 커밋 분석 후에 의도 레코드를 이미 저장한 다른 노드 체인 멤버에 병렬로 보내질 수 있다. Tx-중단 메시지(1744A)를 수신시, 노드(1632A)는 그 의도 레코드를 삭제하고, 페이지(P1) 상의 로크를 해제하고, Tx-커밋 메시지(1644C)를 다시 조정자(1612)에 송신할 수 있다. 조정자(1612)는 일부 실시형태에서는 순차로 기록 실패 응답(1750)을 멀티-페이지 기록의 요청자에 보낼 수 있다. 적어도 일부 실시형태에서, 그리고 사용되는 API의 시맨틱스에 종속하여, 기록 실패 응답(1750)도 그리고 기록 성공 응답(1650)도 적어도 일부 실시형태에서는 송신되지 않을 수 있다 - 대신에, 요청하는 개체는 다른 커맨드를 사용하여 그들 요청이 성공하였는지 여부를 결정할 수 있다(예를 들어, 디렉터리 리스팅 커맨드는 삭제 또는 이름변경이 성공하였는지 결정하도록 사용될 수 있다). 노드 체인에서의 모든 노드가 중단되게 되는 트랜잭션에 참가하지는 않을 수 있음을 주목한다 - 예를 들어, 도 17에서의 결정자 노드(1632C)는 그것이 분산형 트랜잭션에 참가하기로 되어 있었다는 것을 알아차리지도 못할 수 있다. 그리하여, 중단은 결국 체인 멤버 중 수 개에서 어느 자원도 낭비하지 않게 될 수 있어서, 어떤 다른 기술에 비해 분산형 트랜잭션과 연관된 프로세싱의 총량을 감축하는 것을 도울 수 있다.
위에서 언급된 바와 같이, 트랜잭션에 대해 식별된 노드 체인의 특정 저장 노드 중 하나는 일부 실시형태에서는 자신이 트랜잭션의 조정자로서 선택될 수 있다. 조정자는 적어도 일부 실시형태에서는 체인의 제1 노드일 필요도 없고, 조정자는 반드시 결정자 노드인 것도 아닐 수 있다. 도 18은, 적어도 일부 실시형태에 따라, 트랜잭션의 조정자로서 지정된 노드를 포함하는 분산형 트랜잭션 특정 노드 체인(1804)의 일례를 예시한다. 도시된 바와 같이, 노드 체인(1804)은 저장 노드(1632A, 1632B, 1632K, 1632C)를 포함하며, (1632A)는 체인의 제1 노드로서 그리고 (1632C)는 체인에서 말단 및 결정자 노드로서 지정되어 있다. 수정되어야 하는 트랜잭션의 표적 페이지는 노드(1632A)에서의 익스텐트(E1)의 페이지(P1), 노드(1632B)에서의 익스텐트(E5)의 페이지(P7), 노드(1632K)에서의 익스텐트(E6)의 페이지(P4), 및 노드(1632C)에서의 익스텐트(E8)의 페이지(P9)를 포함한다. (도 16, 도 17 및 도 18의 예는 모두 각각의 체인 멤버에서 단일 페이지만이 수정되는 것을 도시하고 있기는 하지만, 다양한 실시형태에서는 일반적으로 어느 수의 페이지라도 각각의 체인 멤버에서 수정될 수 있다). 노드(1632K)는 또한 트랜잭션 조정자로서 지정되었다.
따라서, 트랜잭션 조정자로서의 그 역할로, 노드(1632K)는 Tx-준비 메시지(1801)를 체인의 제1 노드(1632A)에 보낼 수 있다. 도 16에서 예시된 시나리오에서와 같이, Tx-준비 메시지는 노드 체인을 따라 순차적으로 전파될 수 있다, 예를 들어, 중개자 노드의 각각에서의 각각의 로컬 페이지-레벨 커밋 결정이 긍정적이라고 가정하면, Tx-준비(1802)는 노드(1632A)로부터 노드(1632B)로 보내질 수 있고, Tx-준비(1803)는 노드(1632B)로부터 (1632K)로 보내질 수 있고, 그리고 Tx-준비(1804)는 노드(1632K)로부터 결정자 노드(1632C)로 보내질 수 있다.
결정자 노드(1632C)는 역의 시퀀스로 Tx-커밋 메시지의 전파를 개시할 수 있다, 예를 들어, Tx-커밋 메시지(1851)는 노드(1632C)로부터 노드(1632K)로 보내질 수 있고, Tx-커밋 메시지(1852)는 노드(1632K)로부터 노드(1632B)로 보내질 수 있고, 그리고 Tx-커밋 메시지(1853)는 노드(1632B)로부터 노드(1632B)로 보내질 수 있다. 트랜잭션을 완료하기 위해, 묘사된 실시형태에서, 노드(1632A)는 최종 Tx-커밋 메시지(1804)를 조정자 노드(1632K)에 보낼 수 있다. 적어도 일부 실시형태에서, 조정자로서 노드 체인의 특정 노드의 동적 선택은 조정자가 정적으로 선택되었더라면 가능하였을 것보다 저장 서브시스템 노드 간 조정 작업부하(예를 들어, Tx-준비 메시지에 필요로 되는 정보가 수집 및 분석되는 트랜잭션의 예비 단계와 관련된 작업부하)를 더 균등하게 분산시키는 것을 도울 수 있다.
적어도 일부 실시형태에서, 노드 체인 멤버의 각각은, 도 19를 참조하여 아래에서 논의되는 바와 같이, 트랜잭션 후에도 소정 시간 동안 트랜잭션 상태 레코드를 로컬 저장할 수 있다. 상태 정보는, 예를 들어, (커밋팅되든 중단되든) 트랜잭션이 완료되기 전에 참가자 노드 중 하나가 실패하는 경우에 필요로 될 수 있는 복구 연산 동안 사용될 수 있다. 시간의 흐름에 따라, 그러한 트랜잭션 상태 정보는 메모리 및/또는 저장 공간을 점점 더 많이 소모할 수 있다. 따라서, 예전 트랜잭션에 대한 상태 정보에 전념한 메모리 및/또는 저장소를 자유롭게 해주기 위해, 소정 트랜잭션이 커밋팅되거나 중단된 후 소정 시점에서, 조정자 노드(1632K)는 도 18에서 묘사된 실시형태에서는 Tx-클린업(Tx-cleanup) 메시지(1871, 1872, 1873)를 체인(1804)의 노드들에 송신할 수 있다. Tx-클린업 메시지는 저장 노드로부터 상태 레코드가 삭제되어야 하는 트랜잭션의 식별자를 표시할 수 있다. 따라서, 적어도 일부 실시형태에서, 저장 노드는 Tx-클린업 메시지를 수신시 특정된 트랜잭션 상태 레코드를 제거할 수 있다. Tx-클린업 메시지는 (도 18에서 시사된 바와 같이) 병렬로 조정자로부터 저장 노드 체인 멤버로 보내질 수도 있고 다양한 실시형태에서는 순차적으로 전파될 수도 있다. 조정자는 일부 실시형태에서는 트랜잭션이 커밋팅되거나 중단된 이후로 튜닝가능한 또는 구성가능한 시간 기간이 경과한 후에 소정 트랜잭션에 대한 Tx-클린업 메시지를 송신하기로 결정할 수 있고, 그리고 시간 기간은 다양한 저장 노드에서 오래된 트랜잭션 레코드에 의해 소모된 저장/메모리 공간의 양의 측정치와 같은 다양한 인자에 기반하여 조절될 수 있다. 조정자 노드는 도 18에서는 노드 체인(1804)의 멤버이게 되기는 하지만, Tx-클린업 메시지는 조정자가 노드 체인의 멤버인지 여부와 무관하게 조정자 노드에 의해 보내질 수 있다. 일부 실시형태에서, 단일 Tx-클린업 메시지는 레코드가 클린업되어야 하는 수 개의 다른 트랜잭션의 표시를 포함할 수 있다. 적어도 하나의 실시형태에서는, 도 18에 도시된 바와 같이 조정자가 Tx-클린업 메시지를 보내는 대신에, 체인의 어떤 다른 선택된 멤버가 Tx-클린업 메시지를 송신하는 것을 책임지고 있을 수 있다. 예를 들어, Tx-클린업 메시지는 하나의 그러한 실시형태에서는 체인의 제1 멤버(예를 들어, 도 18에서의 노드(1632A))에 의해 보내질 수 있다.
어느 분산형 컴퓨팅 환경, 특히 수천 개의 상품 컴퓨팅 및/또는 저장 디바이스가 사용되고 있는 대규모 제공자 네트워크에서라도, 컴포넌트의 소정 서브세트에서 하드웨어 및/또는 소프트웨어 장애의 가능성은 구현되는 서비스를 설계할 때 다루어져야 한다. 도 19는, 적어도 일부 실시형태에 따라, 노드 체인의 노드 중 하나에서 장애의 경우에 분산형 트랜잭션 완료를 용이하게 하도록 수행될 수 있는 예시적 연산을 예시한다. 3개의 저장 노드(1932A, 1932B, 1932C)가 동일한 논리적 익스텐트(E1)의 각각의 복제본(1902A, 1902B, 1902C)을 저장하는 것으로 도시되어 있다. 초기에, 복제본(1902A)은 마스터 복제본으로 지정되는 한편, (1902B) 및 (1902C)는 비-마스터 복제본으로 지정된다.
어느 소정 분산형 트랜잭션에 대해서라도 발생된 저장 노드 체인은 전형적으로는 트랜잭션에 관여된 익스텐트의 마스터 복제본이 저장되는 저장 노드를 포함할 수 있다. 그러한 노드는 거기에 마스터 복제본이 저장되는 그들 익스텐트에 대해 "마스터 노드" 또는 "리더 노드"라고 지칭될 수도 있다. 물리적 페이지에 소정 노드 체인 멤버에서 이루어진 변경은 마스터 노드로부터 다른 복제본들 간 전파될 수 있다. 그리하여, 앞서 논의된 메시지(예를 들어, Tx-준비, Tx-커밋 및 Tx-중단)는 적어도 일부 실시형태에서는 전형적으로 트랜잭션에 관여된 익스텐트에 대한 마스터 노드에 보내질 수 있다.
묘사된 실시형태에서, 마스터 노드(1932A)는 E1의 복제본 그룹의 멤버가 저장되는 다른 저장 노드도 액세스가능한 영속적 공유된 리파지토리(1980)에서 의도 레코드(1915), 페이지 로크(1910), 및 트랜잭션 상태 레코드(1905)를 저장할 수 있다. 적어도 일부 실시형태에서, (도 16의 노드(1632A, 1632B, 1632C), 및 도 17의 노드(1632A, 1632B)와 같은) 분산형 트랜잭션 메시지 흐름에 참가하는 각각의 노드 체인 멤버는 Tx-준비, Tx-커밋 또는 Tx-중단 메시지가 노드 체인 멤버로부터 보내지는 때 분산형 트랜잭션의 상태의 그 로컬 뷰를 표시하는 트랜잭션 레코드(1905)를 저장할 수 있다. 예를 들어, 로컬 페이지 수정을 위한 커밋 분석이 수정이 수락가능하다고 표시하고, 그리고 로컬 페이지를 수정하려는 의도 레코드가 저장되면, 트랜잭션 상태 레코드는 (조정자에 의해 선택되고 Tx-준비 메시지에 포함된 고유 식별자에 의해 식별된) 트랜잭션이 노드 체인 멤버의 관점에서 준비됨 상태에 있음을 표시한다. 결정자 노드가 트랜잭션이 전체로서 커밋팅되어야 한다고 결정할 때, 그것은 커밋팅됨으로 설정된 상태를 갖는 트랜잭션 레코드를 저장할 수 있다. 비-결정자 노드가 Tx-커밋 메시지를 수신할 때, (이전에는 준비됨이었던) 트랜잭션의 상태는 묘사된 실시형태에서는 커밋팅됨으로 변경될 수 있다. 체인의 어느 노드라도 트랜잭션을 중단하기로 결정할 때, 중단됨으로 설정된 상태를 갖는 트랜잭션 상태 레코드는 리파지토리(1980)에 저장될 수 있다. 어느 노드 체인 멤버라도 Tx-중단 메시지를 수신할 때, 트랜잭션 상태 레코드는 상태를 중단됨으로 설정하도록 수정될 수 있다. 위에서 Tx-클린업 메시지에 관한 논의에서 언급된 바와 같이, 적어도 일부 실시형태에서 트랜잭션 상태 레코드(1905)는 트랜잭션과 연관된 메시징이 소정 저장 노드의 관점에서 완료된 후에 소정 시간 기간 동안 그 노드에서 보유될 수 있다. 이것은 여러 다른 실시형태에서 다양한 목적으로 - 예를 들어, 상실된 메시지로부터 초래되는 장애 상황으로부터의 복구에 도움을 주기 위해, 디버깅을 위해, 감사 목적으로 등 행해질 수 있다. 소정 트랜잭션에 대해 Tx-클린업 메시지가 수신될 때, 트랜잭션 상태 레코드는 일부 실시형태에서는 삭제 또는 아카이빙될 수 있다.
영속적 상태 리파지토리(1980)는 트랜잭션이 완료되기 전에(예를 들어, 모든 Tx-준비, Tx-커밋, Tx-중단 또는 마스터가 소정 트랜잭션에 대해 보내는 것을 책임지고 있는 메시지가 그들 의도된 수신자에서 성공적으로 수신되기 전에) 마스터 노드가 실패하면 페일오버 노드가 트랜잭션-관련 연산을 인수할 수 있도록 사용될 수 있다. 예를 들어, "1"로 라벨이 붙은 화살표에 의해 표시된 바와 같이, (익스텐트(E1)에 대해) 마스터 노드(1932A)는 그것이 Tx-준비 메시지를 수신한 소정 트랜잭션(Tx1)에 대한 트랜잭션 상태 레코드(1905), 페이지 로크(1910)의 표시, 및 의도 레코드(1915)를 리파지토리(1980)에 시간(T1)에서 기록할 수 있다. 대응하는 Tx-커밋 또는 Tx-중단 메시지가 수신되기 전에, 노드(1932)는, "2"로 라벨이 붙은 문자 및 "X"에 의해 표시된 바와 같이, 실패할 수 있다. 복제 상태 관리 프로토콜에 따라, 노드(1932B)는, 예를 들어, 복제본(1902B)을 새로운 마스터로서 지정함으로써 ("3"이라는 라벨에 의해 표시된 바와 같이) 익스텐트(E1)에 대해 새로운 마스터 노드로서 선택될 수 있다. 일부 실시형태에서는 합의-기반 정책이 새로운 마스터를 선출하도록 사용될 수 있다. 대신에, Tx-커밋 또는 Tx-중단을 (노드(1932A)의 실패 이전에) 노드(1932A)에 송신하였을 노드 체인 멤버가 익스텐트(E1)에 대해 마스터 역할이 노드(1932B)에 이관된 것을 발견할 수 있고, 그래서 대신에 노드(1932B)에 Tx-커밋 또는 Tx-중단을 보낼 수 있다. 의도 레코드, 로크 및 트랜잭션 상태 레코드가 모두 영속적 리파지토리(1980)에 저장되었기 때문에, 노드(1932B)는 Tx1에 대한 요구된 트랜잭션 정보를 리파지토리(1980)로부터 판독하고 노드(1932A)에 의해 수행되었을 트랜잭션-관련 태스크를 용이하게 수행할 수 있을 수 있다. 적어도 일부 실시형태에서, 영속적 리파지토리(1980)는 복제본 간 변경을 전파하는 것, 논리적 타임스탬프를 판독 및 기록과 연관시키는 것 등에 사용되는 복제 상태 관리 시스템의 컴포넌트로서 구현될 수 있다.
도 20은, 적어도 일부 실시형태에 따라, 파일 시스템 저장 서비스에서 분산형 트랜잭션을 조정하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(2001)에서 표시된 바와 같이, 수정을 수반하는 파일 스토어 연산 요청이, 예를 들어, 메타데이터 노드에서 액세스 노드로부터 또는 다른 메타데이터 노드로부터 수신될 수 있다. 요청의 분석은, 예를 들어, 여러 다른 익스텐트 및/또는 여러 다른 저장 노드에서 (메타데이터든, 데이터든 또는 양자든 포함하고 있는) 다수의 페이지가 요청을 이행하도록 요구되는지 밝힐 수 있다. 요소(2004)에서 검출되는 바와 같이, 단일 페이지만이 수정되어야 하면, 앞서 설명된 것들과 유사한 판독-수정-기록 시퀀스가 개시될 수 있다(요소(2007)).
(요소(2004)에서 또한 검출되는 바와 같이) 다수의 페이지가 수정 또는 기록될 필요가 있으면, 식별하는 조정자 노드를 선택함으로써 분산형 트랜잭션이 시작될 수 있다(요소(2010)). 다양한 기술이 여러 다른 실시형태에서 조정자를 선택하는데 사용될 수 있다. 적어도 하나의 실시형태에서는, 트랜잭션에 관여된 참가자 중 하나 - 예를 들어, 표적 페이지 중 하나의 마스터 복제본이 저장되는 저장 노드, 또는 트랜잭션에 의해 영향을 받는 메타데이터를 발생 및 관리하는 것을 책임지고 있는 메타데이터 노드들 중 하나가 선택될 수 있다. 일부 실시형태에서는, 저장 서브시스템, 메타데이터 서브시스템 또는 액세스 서브시스템 노드의 세트가 조정자 후보로서 미리 지정될 수 있고, 그리고 후보들 중으로부터 특정 노드가 선택될 수 있다.
조정자는 트랜잭션을 완료하는데 필요한 정보의 다양한 요소를 수집할 수 있다(요소(2013)). 그러한 정보는 묘사된 실시형태에서는, 예를 들어, 수정되어야 하는 모든 페이지의 리스트를 포함할 수 있고 그리고 대응하는 기록 페이로드(기록될 바이트의 콘텐츠)의 리스트가 발생될 수 있다. 조정자는 또한, 예를 들어 교착상태 회피 메커니즘을 사용하여, 트랜잭션에 대해 페이지-레벨 커밋 분석이 수행되어야 하는 순서(및 그리하여 로크가 취득되어야 하는 순서)를 결정할 수 있다. 일부 실시형태에서, 예를 들어, 교착상태 회피 메커니즘을 사용하는 것은, 어느 2개의 페이지 상에서라도 로크가 획득되는 순서가 하나의 트랜잭션부터 다른 트랜잭션까지 변경되지 않도록, 모든 분산형 트랜잭션에 적용되는 일관된 정렬 방법론을 사용하여 표적 페이지의 식별자를 정렬하는 것을 포함할 수 있다. 조정자는 묘사된 실시형태에서는, 예를 들어, 페이지가 표적으로 되는 모든 익스텐트에 대해 (현재) 마스터 저장 노드를 식별하고 그것들을 커밋 분석이 수행되어야 하는 순서로 배열함으로써 트랜잭션에 대한 저장 노드 체인을 구축할 수 있다. 적어도 하나의 실시형태에서, 조정자는 또한 고유 트랜잭션 식별자(예를 들어, 무작위-발생된 스트링이 편입되어 있는 범용 고유 식별자 또는 UUID)를 발생시키는 것을 책임지고 있을 수 있다. 위에서 설명된 조건부 기록 기술에 대해 논의된 것들과 같은 판독 논리적 타임스탬프(RLT) 또는 연산 시퀀스 번호가 I/O 연산에 이용가능한 일부 실시형태에서, 조정자는 또한 모든 표적 페이지를 판독하고 판독과 연관된 RLT를 결정할 수 있다(요소(2016)). 그 후 조정자는 노드 체인, 기록 페이로드 및 RLT를 표시하는 Tx-준비 메시지를 구축하고 Tx-준비 메시지를 체인의 제1 노드에 송신할 수 있다(요소(2019)).
적어도 일부 실시형태에서, 조정자는 그 후 선택된 타임아웃 기간 후에 만료하도록 설정된 타이머를 시작시키고 그 Tx-준비 메시지에 대한 응답을 기다릴 수 있다. (요소(2023)에서 검출되는 바와 같이) 타임아웃 기간 내에 응답이 수신되지 않으면, 일부 실시형태에서는 연산의 결과가 미지임을 표시하는 응답이 요소(2001)의 파일 스토어 연산을 요청한 클라이언트에 제공될 수 있다(요소(2035)). 적어도 하나의 실시형태에서, 트랜잭션 상태 복구 연산은, 예를 들어, 그 노드가 아직 액세스가능하면 체인의 제1 노드에, 또는 하나가 발견 또는 구성될 수 있으면 그 제1 노드 대신에 대체 노드에 다른 Tx-준비 메시지를 보냄으로써 개시될 수 있다.
(요소(2026)에서 결정되는 바와 같이) 타임아웃 기간 내에 Tx-커밋 메시지가 조정자에서 수신되면, 이것은 트랜잭션의 모든 개개의 페이지 수정이 성공적으로 수행되었음을 표시할 수 있다. 따라서, 일부 실시형태에서, 조정자는 요청된 연산이 성공하였다는 표시를 연산을 요청한 클라이언트에 보낼 수 있다(요소(2029)). 적어도 하나의 실시형태에서, Tx-클린업 메시지는, 노드 체인 멤버에서 커밋팅된 트랜잭션에 대한 트랜잭션 상태를 유지하고 있는 어느 자원이라도 해제될 수 있도록, 예를 들어 Tx-커밋의 수신에 대해 비동기식으로, 체인 노드에 보내질 수 있다. 앞서 논의된 바와 같이, Tx-클린업 메시지는 조정자에 의해서든 또는 체인의 제1 멤버와 같은 어떤 다른 선택된 체인 멤버에 의해서든 보내질 수 있다.
(요소(2026)에서 또한 검출되는 바와 같이) Tx-중단 메시지가 조정자에서 수신되면, 조정자는 일부 실시형태에서 옵션으로서는 요청된 연산이 실패하였다는 표시를 클라이언트에 보낼 수 있다(요소(2032)). 일부 실시형태에서, 또한 Tx-클린업 메시지는, 조정자에 의해서든 또는 체인의 어떤 다른 멤버에 의해서든, 중단된 트랜잭션에 참가하였던 그들 체인 멤버에 보내질 수 있다. 트랜잭션이 체인 멤버 중 어느 하나에 의해서라도 중단될 수 있으므로, 중단이 일어나기 전에 멤버의 서브세트만이 트랜잭션 상태 레코드를 저장하였을 수 있고, 그리하여 일부 구현에서는 체인 멤버의 서브세트에만 Tx-클린업 메시지가 보내질 수 있다. 다른 구현에서, Tx-클린업 메시지는 단순히 체인의 모든 노드에 보내질 수 있고, 그리고 Tx-클린업 메시지에서 식별된 트랜잭션에 대한 어느 트랜잭션 상태도 저장하지 않은 그들 노드는 Tx-클린업 메시지를 무시할 수 있다.
도 21은, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-준비(Tx-준비) 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 조정자에 의해 구축된 노드 체인의 멤버(CM), 예를 들어, 트랜잭션의 일부분으로서 페이지가 수정되어야 하는 익스텐트 중 하나의 마스터 복제본을 저장하는 노드는 어떤 다른 노드로부터(예를 들어, 전형적으로는 조정자로부터든 또는 체인의 어떤 비-결정자 멤버로부터든) Tx-준비 메시지를 수신할 수 있다(요소(2101)). Tx-준비 메시지는, 트랜잭션에 대한 제안된 페이지 수정의 리스트에서, 부모 익스텐트의 마스터 복제본이 CM에서 저장되는 페이지(P)에 대한 하나 이상의 제안된 페이지-레벨 수정을 표시할 수 있다. CM는, 예를 들어, Tx-준비 메시지에서의 P에 대해 표시된 판독 논리적 타임스탬프가 획득된 이후로 페이지(P)가 수정되었는지 (도 14에 도시된 버퍼와 유사한) 기록 로그 버퍼에서 점검함으로써, 그 관점에서 변경이 수락가능한지/커밋팅가능한지 결정할 수 있다. 일부 경우에서, CM에서 저장되어 있는 여러 다른 페이지에 대해서든 또는 동일한 페이지에 대해서든, 다수의 페이지 레벨 수정은 Tx-준비 메시지에 표시될 수 있고, 그리고 모든 그러한 변경은 수락가능성에 대해 점검될 수 있다.
요소(2107)에서 결정되는 바와 같이 로컬 페이지-레벨 수정이 커밋팅가능하면, CM이 결정자(노드 체인의 최후 멤버)인지 여부에 종속하여 여러 다른 조치가 취해질 수 있다. (요소(2110)에서 검출되는 바와 같이) CM이 결정자이면, 로컬 페이지 또는 페이지들에 대한 수정이 개시될 수 있고, 그리고 묘사된 실시형태에서는 트랜잭션이 커밋팅됨 상태에 있음을 표시하는 트랜잭션 레코드가 영속적 저장소에 저장될 수 있다(요소(2113)). 결정자 노드는 그 후 노드 체인의 다른 멤버에 Tx-커밋 메시지의 전파를 개시할 수 있다(요소(2116)). Tx-커밋 메시지는 일부 실시형태에서는 순차적으로, 예를 들어, 동일한 트랜잭션에 대해 Tx-준비 메시지가 송신되었던 순차적 순서에 비해 역순으로 전파될 수 있다. 다른 실시형태에서, Tx-커밋 메시지는 병렬로 보내질 수 있다.
(요소(2107) 및 요소(2110)에서 또한 결정되는 바와 같이) 로컬 페이지-레벨 수정이 커밋팅가능하고 그리고 CM이 결정자 노드가 아니면, 묘사된 실시형태에서 CM은 (a) (나머지 노드 체인 멤버가 또한 그들 로컬 변경이 커밋팅가능함을 발견하면 CM이 그 로컬 수정을 수행하려고 의도함을 표시하는) 의도 레코드를 저장하고, (b) (예를 들어, 분산형 트랜잭션이 전체로서 커밋팅/중단될 때까지 그들 페이지로의 어느 기록도 방지하기 위해) CM의 표적 로컬 페이지를 로킹하고, 그리고 (c) 트랜잭션이 준비됨 상태에 있음을 표시하는 트랜잭션 상태 레코드를 저장할 수 있다(요소(2119)). 그 후 CM은 체인에서의 다음 노드에 계속 Tx-준비 메시지를 보낼 수 있다(요소(2122)).
(요소(2107)에서 또한 검출되는 바와 같이) 로컬 페이지-레벨 수정이 커밋팅가능하지 않으면, 예를 들어, Tx-준비 메시지에 표시된 P에 대한 RLT가 획득된 이후로 페이지(P)가 기록되었으면, 트랜잭션은 전체로서 순차적 일관성 시맨틱스를 지원하기 위해 중단되어야 할 수 있다. 따라서, (비-결정자 노드일 수도 결정자 노드일 수도 있는) CM은 트랜잭션이 중단되었다는 표시를 저장할 수 있다(요소(2125)). 일부 구현에서는, 트랜잭션이 중단됨 상태에 있음을 표시하는 트랜잭션 상태 레코드가 저장될 수 있다. 다른 구현에서는, 더미 또는 "무연산" 기록 레코드가 (도 14의 버퍼(1450)와 유사한) 로컬 기록 로그 버퍼에 저장될 수 있다. 그러한 더미 기록은 중단됨 상태를 표시하는 상태 레코드와 동일한 효과를 가질 것이다. 즉, 어떤 이유로(예를 들어, 잘못된 또는 지연된 메시지를 수신하는 결과로서) CM에서 트랜잭션을 재-시도하려는 시도가 행해지면, 그 재시도는 실패할 것이다. CM은 Tx-준비 메시지를 이미 보낸 체인에서의 다른 노드에 (어느 그러한 노드라도 있는 경우) 그리고/또는 조정자에 Tx-중단 메시지의 전파를 개시할 수 있다(요소(2128)).
도 22는, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-커밋(Tx-커밋) 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(2201)에서 제시된 바와 같이, 트랜잭션에 대한 Tx-준비 메시지에서 트랜잭션 조정자에 의해 표시된 노드 체인 멤버(CM)는 Tx-커밋 메시지를 수신할 수 있다. Tx-커밋 메시지는 (적어도 정상 동작 조건 하에서는) 전형적으로는 CM이 그 로컬 페이지-레벨 커밋 분석을 수행하고 트랜잭션이 준비됨 상태에 있음을 표시하는 트랜잭션 레코드를 저장한 후 소정 시간에서 수신될 수 있다. Tx-커밋 메시지를 수신하는 것에 응답하여, CM은 로컬 표적 페이지에 대한 실제 수정을 개시하고(요소(2104)) 트랜잭션이 이제 커밋팅됨 상태에 있음을 표시하도록 트랜잭션 상태 레코드를 수정할 수 있다. 일부 실시형태에서, 익스텐트(E)의 데이터 영속성 요건에 종속하여, 로컬 페이지 기록이 완료되었다고 생각될 수 있기 전에 다수의 익스텐트 복제본이 수정되어야 할 수 있다. 일부 그러한 시나리오에서, CM은, 페이지 수정을 개시한 후에, 트랜잭션 레코드를 변경하기 전에 충분한 복제본이 업데이트될 때까지 기다릴 수 있다.
그 후 CM은 그것이 표적 페이지 또는 페이지들 상에 유지하고 있었던 로크(들)를 해제할 수 있다(요소(2207)). 적어도 일부 실시형태에서, CM이 트랜잭션에 대한 Tx-준비 메시지에 응답할 때 저장하였던 의도 레코드는 이 시점에서 삭제될 수 있다(요소(2210)). 앞서 언급된 바와 같이, 일부 실시형태에서, Tx-커밋 메시지는 Tx-준비 메시지에 비해 역순으로 체인 멤버 간 순차적으로 전파될 수 있는 한편, 다른 실시형태에서는, 병렬 전파가 사용될 수도 있고, 순차 및 병렬 전파의 어떤 조합이 사용될 수도 있다. 순차적 전파가 사용되고 있으면, 또는 CM이 (예를 들어, 그것이 수신한 Tx-커밋 메시지 내에서의 표시에 기반하여) 체인의 일부 노드가 아직 Tx-커밋 메시지를 수신하지 않았다고 결정할 수 있으면, 그때 CM은 조정자에 또는 체인에서의 선택된 노드에 계속 Tx-커밋 메시지를 송신할 수 있다(요소(2213)). 일부 실시형태에서, 중복 Tx-커밋 메시지는 무시될 수 있다 - 예를 들어, 소정 노드 또는 조정자가 트랜잭션(Tx1)에 대한 Tx-커밋 메시지를 수신하고 그리고 Tx1이 이미 커밋팅된 것으로 레코딩되어 있으면, 새로운 Tx-커밋 메시지는 무시될 수 있다. 일부 그러한 실시형태에서는, 트랜잭션을 완료하는데 걸리는 총 시간을 단축하기 위해 Tx-커밋 메시지에 비-순차적 전파 메커니즘이 사용될 수 있으며, 거기에서는, 예를 들어, Tx-커밋 메시지를 수신하는 각각의 노드가 체인에서의 N개의 다른 노드에 Tx-커밋 메시지를 포워딩할 수 있다.
도 23은, 적어도 일부 실시형태에 따라, 저장 서비스의 노드에서 트랜잭션-중단(Tx-중단) 메시지를 수신하는 것에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(2301)에서 제시된 바와 같이, Tx-중단 메시지는 체인 멤버(CM)에서 수신될 수 있다. Tx-커밋 메시지처럼, Tx-중단 메시지는 (적어도 정상 동작 조건 하에서는) 전형적으로는 CM이 그 로컬 페이지-레벨 커밋 분석을 수행하고 트랜잭션이 준비됨 상태에 있음을 표시하는 트랜잭션 레코드를 저장한 후 소정 시간에서 수신될 수 있다.
Tx-중단 메시지를 수신하는 것에 응답하여, CM은 그것이 표적 페이지 또는 페이지들 상에 유지하고 있었던 로크(들)를 해제할 수 있다(요소(2304)). 적어도 일부 실시형태에서, CM이 트랜잭션에 대한 Tx-준비 메시지에 응답할 때 저장하였던 의도 레코드는 이 시점에서 삭제될 수 있다(요소(2307)). Tx-커밋 메시지의 경우에서와 같이, 여러 다른 구현에서는, 순차, 병렬 또는 하이브리드(즉, 순차 및 병렬의 어떤 조합) 중 어느 전파가 Tx-중단 메시지에 채용될 수 있다. 일부 실시형태에서, Tx-중단 메시지는, 예를 들어, Tx-준비 메시지에 비해 역순으로 체인 멤버 간 순차적으로 전파될 수 있다. 순차적 전파가 사용되고 있으면, 또는 CM이 (예를 들어, 그것이 수신한 Tx-중단 메시지 내에서의 표시에 기반하여) 앞서 Tx-준비 메시지를 보낸 체인의 일부 노드가 아직 Tx-중단 메시지를 수신하지 않았다고 결정할 수 있으면, 그때 CM은 조정자에 또는 체인에서의 선택된 노드에 계속 Tx-중단 메시지를 송신할 수 있다(요소(2310)). 일부 실시형태에서, 중복 Tx-커밋 메시지에 대해서와 같이, 중복 Tx-중단 메시지는 무시될 수 있다 - 예를 들어, 소정 노드 또는 조정자가 트랜잭션(Tx1)에 대한 Tx-중단 메시지를 수신하고 그리고 Tx1이 이미 중단된 것으로 레코딩되어 있으면, 새로운 Tx-중단 메시지는 무시될 수 있다. 일부 그러한 실시형태에서는, 트랜잭션을 중단하는데 걸리는 총 시간을 단축하기 위해 Tx-중단 메시지에 비-순차적 전파 메커니즘이 사용될 수 있으며, 거기에서는, 예를 들어, Tx-중단 메시지를 수신하는 각각의 노드가 체인에서의 N개의 다른 노드에 Tx-중단 메시지를 포워딩할 수 있다.
익스텐트
초과가입 모델을 사용하는 온-
디맨드
페이지 할당
많은 저장 시스템에서, 성능 목표는 때로는 공간-효율 목표와 잠재적으로 상충할 수 있다. 예를 들어, 일반적으로, 관리되는 데이터의 양에 비해 비교적 작은 (논리적-블록-대-물리적-페이지 매핑을 포함하는 구조와 같은) 메타데이터의 양을 유지하는 것은 다양한 유형의 파일 스토어 연산의 속도를 높이는 것을 도울 수 있다. 메타데이터가 너무 크게 증대하면, 액세스 노드의 메타데이터 캐시에서의 캐시 적중률은 떨어질 수 있어서, 동일한 수의 클라이언트 요청에 서비싱하기 위해 액세스 서브시스템과 메타데이터 서브시스템 간 더 많은 상호작용을 초래할 수 있다. 적어도 일부 메타데이터는 논리적-블록-당 단위로 유지되고 있을 수 있으므로, 이것은 큰 논리적 블록(예를 들어, 4 메가바이트 또는 16 메가바이트 논리적 블록)을 갖는 것이 작은 논리적 블록을 갖는 것보다 성능 관점에서 더 좋을 것임을 시사할 것이다. 그렇지만, 논리적 블록으로의 제1 기록이 요청되는 때 전체 논리적 블록에 대한 물리적 페이지가 할당되면, 이것은 최적에 미달하는 공간 사용 효율을 초래할 수 있다. 예를 들어, 논리적 블록 크기가 4MB이고(그리하여, 전체 논리적 블록에 대한 충분한 공간이 한 번에 할당되면 어느 소정 파일에 대해서라도 최소 4MB의 물리적 공간이 할당될 것이고), 그리고 소정 디렉터리 또는 파일 시스템 내에서의 파일에 저장된 데이터의 중앙값 양은, 가령, 32KB인 시나리오를 고려한다. 그러한 시나리오에서는, 많은 양의 물리적 저장 공간이 낭비될 것이다. 그렇지만, 논리적 블록 크기가 중앙값 파일 크기에 가깝도록 설정되면, 이것은 큰 파일에 대해 매우 많은 양의 메타데이터를 초래할 수 있고, 그리하여 단지 큰 파일로 지향된 것만이 아니라 전체로서 파일 저장 서비스로 지향된 연산을 잠재적으로 감속시킨다.
여러 다른 실시형태에서, 공간 효율과 성능 간 절충을 다루는데 여러 기술이 사용될 수 있다. 하나의 기술에서는, 초과가입 모델이 익스텐트에 사용될 수 있고, 그리고 소정 논리적 블록 내에서의 물리적 페이지는 모두 한꺼번에라기보다는 온-디맨드 할당될 수 있을 뿐이다(즉, 논리적 블록 크기가 X 킬로바이트로 설정되고, 그리고 논리적 블록으로의 제1 기록이 (X-Y) 킬로바이트만의 페이로드를 가지면, X-Y 킬로바이트를 저장하기에 충분한 페이지만이 제1 기록에 응답하여 할당될 수 있다). 초과가입 모델의 논의 후 설명되는 다른 기술에서는, 여러 다른 크기의 논리적 블록이, 객체의 스트라이프 중 적어도 일부의 크기가 다른 스트라이프의 크기와 다를 수 있도록, 소정 파일 스토어 객체 내에서 채용될 수 있다. (익스텐트가 초과가입되고 그리고/또는 가변 논리적 블록 크기가 사용되는 실시형태에서를 포함하여) 앞서 설명된 바와 같은 다양한 실시형태에서 익스텐트가 데이터 영속성을 위해 복제될 수 있기는 하지만, 익스텐트 복제 기술은, 여기에서 논의되는 바와 같이, 익스텐트 초과가입에 그리고 논리적-블록-대-페이지 매핑에 직교한다고 생각될 수 있음을 주목한다. 따라서, 익스텐트 복제본은 초과가입된 익스텐트에 대해 또는 가변-크기의 스트라이프에 대해 여기에서 상세히 논의되지는 않을 수 있다. 제시를 단순화하기 위해, 논리적 익스텐트는 익스텐트 초과가입 관리 기술의 대부분에 대해 그리고 가변-크기의 스트라이프 또는 가변-크기의 논리적 블록에 사용되는 기술의 논의에 대해 단일 물리적 익스텐트를 포함한다고 가정될 수 있다.
도 24는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 초과-가입된 저장 익스텐트의 예를 예시한다. 묘사된 실시형태에서, (파일(2400A, 2400B, 또는 2400C)과 같은) 소정 파일 스토어 객체의 논리적 블록은 모두 동일한 크기이고, 그리고 소정 논리적 블록에 대해 할당된 모든 물리적 페이지는 단일 익스텐트의 일부분이다. 소정 익스텐트 내에서의 물리적 페이지는 묘사된 실시형태에서는 전형적으로 또한 익스텐트의 다른 물리적 페이지와 동일한 크기일 수 있다. 그리하여, 일례의 구현에서, 익스텐트는 32-KB 물리적 페이지의 16 기가바이트를 포함할 수 있는 한편, 논리적 블록은 4 메가바이트를 포함할 수 있다. 익스텐트, 논리적 블록 및/또는 물리적 페이지의 크기는 적어도 일부 실시형태에서는 각각의 구성 파라미터를 사용하여 설정될 수 있다.
도시된 바와 같이, 동일한 파일의 다른 논리적 블록은 적어도 일부 경우에서는 다른 익스텐트에 매핑될 수 있고, 그리고 결과로서 논리적 블록은 스트라이프의 균등물이라고 생각될 수 있다. 파일(2400A)은 LB(논리적 블록)(2402A, 2402B)을 포함한다. LB(2402A)는 익스텐트(E2434A)의 소정 수의 물리적 페이지(PP)(2410A)에 온-디맨드 매핑된다. 유사하게, 익스텐트(E2434B)에서의 소정 수의 물리적 페이지(2410B)는 LB(2402B)에 대해 온-디맨드 할당된다. 익스텐트(E2434A)에서, 소정 수의 페이지(2410A)는 파일(2400B)의 LB(2402L)에 대해서는 물론 파일(2400C)의 LB(2402P)에 대해서도 온-디맨드 할당된다. 익스텐트(E2434B)에서, 소정 수의 페이지(2410B)는 파일(2400B)의 LB(2420K)에 대해서는 물론 파일(2400C)의 LB(2402Q)에 대해서도 온-디맨드 할당된다. 온-디맨드 할당 기술은 묘사된 실시형태에서는 다음과 같이 구현될 수 있다: 특정 논리적 블록으로 지향된 기록 요청이 수신될 때마다, 파일 내에서의 시작 오프셋, 및 기록 페이로드의 크기(예를 들어, 기록 또는 수정될 바이트의 수)는 어느 새로운 물리적 페이지라도 할당되어야 하는지, 그리고 그러하다면, 얼마나 많은 새로운 물리적 페이지가 할당될 필요가 있는지 결정하도록 사용될 수 있다. (일부 기록 요청은, 그것들이 이전에-할당된 페이지로 지향될 수 있으므로, 어느 새로운 페이지도 할당될 필요가 없을 수 있다. 예를 들어, 잠재적으로 논리적 블록의 일부분으로서 기록될 수 있는 물리적 페이지의 전체 세트를 한 번에 할당하는 대신에, 기록 페이로드를 수용하는데 요구되는 새로운 물리적 페이지의 수만이 할당될 수 있다. 다음의 예를 고려한다: LB(2402A)는 크기가 4 메가바이트이고, 그리고 PP(2410A)는 크기가 32KB이다. 28KB의 기록 페이로드를 포함하는, LB(2402A)로의 제1 기록이 수신된다. 이 시점 이전에, 그 예의 시나리오에서는 LB(2402A)에 대해 물리적 저장소가 할당되지 않았다. 저장 서비스는 (28KB가 단일 32-KB 페이지 내에 수용될 수 있으므로) 하나의 PP(2410A)만이 제1 기록에 필요하다는 결정을 한다. 결과로서, 묘사된 실시형태에서는 소정 논리적 블록의 모든 페이지가 동일한 익스텐트 내로부터 할당되어야 하므로, LB(2402A)의 전체 4MB가 결국에는 익스텐트(E2434A) 내에 저장되어야 할 수 있더라도, 하나의 PP(2410A)만이 익스텐트(E2434A) 내에서 할당된다.
일반적으로, 적어도 일부 실시형태에서는, 논리적 블록의 얼마의 비율이 결국에 기록될 것인지 예측하는 것이 간단하지 않을 수 있다; 예를 들어, 일부 성긴 파일은 광범위하게 다른 논리적 오프셋에서 데이터의 작은 영역을 포함하고 있을 수 있다. 묘사된 실시형태에서 공간 사용 효율을 개선하기 위해, 익스텐트(E2434A, E2434B)는 각각 초과가입될 수 있다. 익스텐트는 그것이 그 현재 크기 내에 가득 물리적으로 수용될 수 있는 것보다 더 많은 논리적 블록으로의 기록 요청을 수락하도록 구성되면 초과가입되는 것으로 생각될 수 있다 - 예를 들어, 모든 논리적 블록 내에서의 완전 오프셋 범위가 어떤 일로 동시에 기록되게 되면, 익스텐트는 확대되어야 할 수 있다(또는 다른 익스텐트가 사용되어야 할 수 있다). 그리하여, 초과가입 파라미터(2455A)에 도시된 바와 같이, N개의 논리적 블록은 익스텐트(E2434A)에 매핑될 수 있고, 그리고 각각의 논리적 블록은 각각 Y 킬로바이트의 최대 M개의 물리적 페이지에 매핑될 수 있다. 익스텐트(E2434A)의 현재 크기는 X 킬로바이트이고, 여기서 X는 (N*M*Y)보다 작다. 초과가입 인자(OF1)는 묘사된 실시형태에서는 익스텐트(E2434A)에 적용되며, 잠재적 오버플로 저장량((N*M*Y) - X) 대 익스텐트의 실제 크기(X)의 비와 같다. 유사한 초과가입 파라미터(2455B)가 익스텐트(E2434B)에 적용된다. (E2434B)는 현재 Z 킬로바이트까지만 저장할 수 있지만, 그것은, 각각 R KB의 Q개의 물리적 페이지에 각각 매핑될 수 있는, P개의 논리적 블록으로 지향된 기록 요청을 수락하도록 구성된다. Z는 (P*Q*R)보다 작고, 그래서 (E2434B)에 대한 초과가입 인자(OF2)는 ((P*Q*R) - Z)/Z이다. 일부 실시형태에서는, 다른 익스텐트가 다른 초과가입 인자로 구성될 수 있다. 일 실시형태에서는, 모든 익스텐트에 대해 균일한 초과가입 인자가 사용될 수 있다. 아래에서 논의되는 바와 같이, 일부 실시형태에서, 초과가입 인자 및/또는 초과가입 인자와 연관된 자유 공간 임계치는, 예를 들어, 파일 시스템 사용 또는 거동의 수집된 메트릭에 기반하여 시간의 흐름에 따라 적어도 일부 익스텐트에 대해 수정될 수 있다. 익스텐트-당 레벨에서의 초과가입 관리에 대해 여기에서 설명된 것들과 유사한 기술들이 또한 또는 대신 다양한 실시형태에서 다른 레벨에서의 초과가입에 적용될 수 있다 - 예를 들어, 저장 서브시스템 노드가 그들 익스텐트의 초과가입에 기반하여 초과가입될 수 있고, 개개의 저장 디바이스가 초과가입될 수 있고, 등이다.
도 25는, 적어도 일부 실시형태에 따라, 온-디맨드 물리적 페이지-레벨 할당 및 익스텐트 초과가입을 구현하는 분산형 멀티-테넌트 저장 서비스의 서브시스템들 간 상호작용을 예시한다. 도시된 바와 같이, (E2534A와 같은) 메타데이터 익스텐트와 (E2534B와 같은) 데이터 익스텐트 양자는 묘사된 실시형태에서 초과가입될 수 있다. 특정 논리적 블록(LB)으로 지향된 제1 기록 요청은, 화살표(2501)에 의해 표시된 바와 같이, 액세스 노드(2512)로부터 메타데이터 노드(2522)에서 수신될 수 있다. 기록 요청은 크기 "WS"의 기록 페이로드를 포함할 수 있고, 예를 들어, 파일(2400)로 지향된 클라이언트의 기록 요청에 응답하여 액세스 노드(2512)에서 발생되었을 수 있다.
논리적 블록에 대한 메타데이터 자체는 기록 요청(2501)이 수신되는 때 생성되어 있지 않았을 수 있다 - 예를 들어, 기록은 단순히 파일이 열린 후에 파일(2400)로 지향된 제1 기록일 수 있다. 묘사된 실시형태에서, 메타데이터 노드(2522)는 우선 LB의 메타데이터를 발생 및 기록할 수 있다. 요청(2554)은, 예를 들어, LB의 메타데이터를 저장하도록 저장 노드(2532A)에 보내질 수 있다. 저장 노드는, 블록(2558)에 의해 표시된 바와 같이, 초과가입된 메타데이터 익스텐트(E2534A)로부터의 페이지를 할당하고, 메타데이터 노드(2522)에 의해 발생된 메타데이터를 저장할 수 있다. 사용될 특정 메타데이터 익스텐트는 여러 다른 실시형태에서 메타데이터 노드(2522)에 의해서든, 저장 노드(2532A)에 의해서든, 또는 저장 서비스의 다른 배치 컴포넌트에 의해서든 선택될 수 있다. 선택은, 예를 들어, 수정되는 파일의 이름, 다양한 익스텐트에서 이용가능한 자유 공간의 양 등과 같은 다양한 인자에 기반할 수 있다.
메타데이터 노드(2522)는 또한 묘사된 실시형태에서는 얼마나 많은 새로운 물리적 데이터 페이지가 WS 바이트의 기록 페이로드를 저장하도록 할당되어야 하는지 결정할 수 있다. WS 바이트를 수용하기에 적합한 수의 물리적 페이지에 대한 요청(2562)은 적어도 일부 실시형태에서는 LB 메타데이터에 사용되는 것과는 다른 저장 노드(2532B)에 보내질 수 있다. 저장 노드(2532B)는 묘사된 실시형태에서는 초과가입된 데이터 익스텐트(2534B)에서 (적어도 일부 경우에서는 논리적 블록의 전체 주소 범위가 한꺼번에 기록되었으면 요구되었을 페이지의 수보다 작을 수 있는) 요청된 수의 물리적 페이지를 할당할 수 있다. 물리적 페이지의 신원은 묘사된 실시형태에서는 익스텐트(2534A)에서 저장된 LB 메타데이터 내에 저장될 수 있다 - 예를 들어, 저장 노드(2534B)는 익스텐트(2534B) 내에서의 데이터 페이지의 주소를 메타데이터 노드(2522)에 송신할 수 있고, 그리고 메타데이터 노드(2522)는 LB 메타데이터 내에 주소를 기록하도록 저장 노드(2532A)에 요청을 제출할 수 있다. 일부 실시형태에서, 데이터 페이지는, 예를 들어 메타데이터 페이지의 할당이 부가적 메시지를 요구하지 않고 데이터 페이지 주소의 기록과 조합될 수 있도록, 메타데이터 페이지가 할당되기 전에 할당될 수 있다. 일 실시형태에서, 기록 페이로드는 데이터 페이지에 대한 할당 요청(2562)과 함께 메타데이터 노드(2522)에 의해 저장 노드(2532B)에 송신될 수 있으며, 그 경우 WS 바이트의 기록은, 부가적 메시지를 요구하지 않고, 데이터 페이지의 할당과 조합될 수 있다. 적어도 일부 실시형태에서, 데이터 페이지 또는 페이지들이 제1 기록 요청(2501)에 대해 할당된 후에, 데이터가 저장되어야 하는 적합한 저장 노드(2532B)의 신원은 액세스 노드(2512)에 제공될 수 있고, 그리고 액세스 노드(2512)는 저장 노드에 기록 페이로드를 제출할 수 있다.
적어도 일부 실시형태에서, 앞서 언급된 바와 같이, 초과가입 모델의 사용은 소정 익스텐트가 그것이 콘텐츠를 저장하도록 지정되는 모든 논리적 블록에 대한 충분한 저장 공간이 부족할 수 있는 상황을 초래할 수 있다. 따라서, 일부 실시형태에서, 초과가입된 익스텐트는 때때로 확장되어야 할 수 있거나, 또는 익스텐트 콘텐츠는 그들 원래 익스텐트로부터 더 큰 익스텐트로 이동 또는 복사되어야 할 수 있다. 일부 실시형태에서는, 그렇지 않으면 초래될 수 있는 동기식 지연을 회피하기 위해, 익스텐트-레벨 데이터 복사 또는 익스텐트 확장이 지원되면, 자유 공간 임계치가 초과가입된 익스텐트에 배정될 수 있다. 비동기식 익스텐트 확장 연산, 또는 익스텐트 콘텐츠의 비동기식 이송은 그러한 실시형태에서는 자유-공간 임계치가 위반되면 구현될 수 있다. 다른 익스텐트는, 그것들로 지향된 저장 작업부하의 본성에 종속하여, 다른 비율로 증대할 수 있다. 최대 익스텐트 크기는 (예를 들어, 사용되는 특정 저장 디바이스의 용량에 기반하여) 적어도 일부 익스텐트에 대해 정의될 수 있다. 결과로서, 특정 익스텐트에 대해 그러한 최대 익스텐트 크기에 도달될 때, 익스텐트는 더 이상 초과가입된다고 생각되지 않을 수 있고, 그리고 저장 서비스는 아직 증대할 수 있는 익스텐트에 사용되는 로직과는 다른 로직을 채용하여 그러한 최대-크기로 된 익스텐트를 다룰 수 있다. 일부 실시형태에서, 선택된 익스텐트는 다른 익스텐트의 증대를 위해 자리를 내주기 위해 선제적으로 다른 저장 노드 또는 다른 저장 디바이스로 이동될 수 있다. 그러한 선제적 이동은 일부 구현에서는, 진행 중인 클라이언트-요청된 연산에 대한 지장을 최소화하도록, 백그라운드 태스크로서 수행될 수 있다. 여러 다른 실시형태에서 여러 다른 규칙, 정책 또는 휴리스틱스는 어느 익스텐트가 다른 익스텐트에 자리를 내주기 위해 선제적으로 이동되어야 하는지 선택하도록 사용될 수 있다 - 예를 들어, 일 실시형태에서, 그들 용량의 대부분이 사용되고 있지 않은 익스텐트는 그들 용량의 대부분이 이미 사용 중인 익스텐트보다 우선적으로 선제적 이동을 위해 선택될 수 있다. 다른 실시형태에서는 반대 접근법이 사용될 수 있다 - 예를 들어, 그들 최대 크기에 이미 도달한(또는 그들 최대 크기에 도달하는 것에 더 가까운) 익스텐트는 아직 실질적 증대가 가능한 것들보다 우선적으로 이동될 수 있다. 유사하게, 익스텐트가 이동되는 표적 저장 디바이스 또는 저장 노드는 또한 다양한 실시형태에서는 구성가능한 정책에 기반하여 선택될 수 있다. 일 실시형태에서, 익스텐트는 절대적으로 필요할 때만 이동될 수 있다(예를 들어, 선제적 이동은 구현되지 않을 수 있다).
도 26a는 자유 공간 임계치가 지정된 익스텐트를 예시하는 한편, 도 26b는, 적어도 일부 실시형태에 따라, 자유 공간 임계치의 위반으로부터 초래되는 익스텐트의 확장을 예시한다. 도 26a에 도시된 바와 같이, 초과가입된 익스텐트(E2634A)에 대해 설정된 자유 공간 임계치는 확장이 트리거링되기 전에 M개의 물리적 페이지의 최대 한계(2650)가 익스텐트 내에서 할당될 수 있도록 설정될 수 있다. 익스텐트(2634A)의 할당된 페이지의 수(K)가 M보다 작은 한(즉, 할당되지 않은 페이지의 수(L)가 자유 임계 한계 위에 있는 한), 새로운 페이지는 도 25에 예시된 바와 같이 기록 요청에 응답하여 온-디맨드 할당될 수 있다. M번째 페이지가 할당되면/그때, 도 26b의 화살표(2655)에 의해 표시된 바와 같이, 더 큰 또는 확장된 익스텐트(2634B)로 원래 익스텐트(2634A)의 콘텐츠의 비동기식 복사가 개시될 수 있다. 도시된 바와 같이, 확장된 익스텐트(2634B)의 최대 할당 한계(N개의 페이지)는 원래 익스텐트(2634A)의 M개의 페이지의 할당 한계보다 더 클 수 있다. 일부 실시형태에서는, 페이지를 복사하지 않고 적어도 일부 익스텐트를 확장하는 것이 가능할 수 있다 - 예를 들어, 소정 초과가입된 익스텐트가 소망 확장을 수용하기에 충분한 공간을 갖는 저장 디바이스 상에 위치하고 있으면, 익스텐트의 크기는 저장 디바이스 내에서 증가될 수 있다. 다른 실시형태에서, 원래 익스텐트의 콘텐츠는, 잠재적으로 다른 저장 노드에서, 다른 저장 디바이스에 복사되어야 할 수 있다. 그리하여, 일 구현에서, 확장된 익스텐트(2634B)는 원래 익스텐트(2634A)와는 다른 물리적 저장 디바이스를 점유할 수 있다. 적어도 일부 구현에서는, 수 개의 다른 크기의 익스텐트가 저장 서비스에서 생성될 수 있다 - 예를 들어, 10GB의 N1개의 익스텐트가 생성될 수 있고, 20GB의 N2개의 익스텐트가 생성될 수 있고, 등이다. 그러한 실시형태에서, 익스텐트의 확장은, 예를 들어, 10GB 익스텐트로부터 기-존재하는 20GB 익스텐트로 페이지를 복사하는 것을 수반할 수 있다. 용어 "익스텐트 확장"은, 여기에서 사용될 때, 그 자유 공간 임계치가 위반될 때 초과가입된 익스텐트에서 추가적 데이터 또는 메타데이터 콘텐츠를 저장할 수 있는 능력을 초래하는 이들 유형의 연산 중 어느 것이라도 일반적으로 지칭하도록 의도된다 - 예를 들어, 연산이 익스텐트의 제자리 확대를 수반하든지 아니면 하나의 저장 디바이스로부터 다른 하나로 익스텐트 콘텐츠의 이송을 수반하든지. 그리하여, 익스텐트는 일부 실시형태에서는, 원래 디바이스와 동일한 저장 노드에서든 또는 다른 저장 노드에서든, 사실상, 익스텐트에 사용되는 저장 디바이스를 다른 저장 디바이스로 대체함으로써 확장될 수 있다. 일부 실시형태에서, 익스텐트 식별자(E1)가 확장 이전에 익스텐트를 지칭하도록 사용되었고, 그리고 다른 저장 디바이스가 확장-후에 사용되면, 다른 익스텐트 식별자(E2)가 확장-후에 사용될 수 있다. 다른 실시형태에서는, 동일한 식별자가 확장-후에 사용될 수 있다.
도 27은, 적어도 일부 실시형태에 따라, 익스텐트 초과가입을 지원하는 저장 서비스에서 온-디맨드 물리적 페이지 할당을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(2701)에서 제시된 바와 같이, 복수의 물리적 익스텐트는 분산형 멀티테넌트 파일 저장 서비스의 복수의 저장 서브시스템 노드에서 셋업될 수 있다. 일부 실시형태에서, 하나 이상의 다른 크기의 소정 수의 익스텐트는, 예를 들어, 저장 서비스가 제공자 네트워크의 자원 세트에서 시작되는 때 예비-구성될 수 있다. 다른 실시형태에서, 익스텐트 세트는 새로운 파일 스토어(예를 들어, 파일 시스템)가 초기화될 때 셋업될 수 있다. 각각의 익스텐트는 소정 선택된 수의 물리적 페이지에 충분한 공간을 포함할 수 있으며, 각각의 페이지는 일부 실시형태에서는 데이터 또는 메타데이터 중 어느 것의 논리적 블록의 콘텐츠를 저장하도록 사용될 수 있는 소정 수의 바이트를 포함한다. 예를 들어, 일 실시형태에서, 익스텐트 세트의 각각은 특정 SSD 또는 회전-디스크-기반 저장 디바이스 상에 8 기가바이트의 저장 공간을 포함할 수 있고, 익스텐트에서 콘텐츠가 저장되어야 하는 객체에 사용되는 디폴트 논리적 블록 크기는 4MB일 수 있고, 그리고 물리적 페이지 크기는 32KB로 설정될 수 있다. 이러한 파라미터 세트로, 각각의 논리적 블록은 128개까지의 물리적 페이지를 포함할 수 있고, 그리고 각각의 익스텐트는 대략 2000개까지의 가득-파퓰레이팅된 논리적 블록(논리적 블록 내에 기록되지 않은 오프셋 범위가 없도록, 적어도 4MB의 데이터가 실제로 기록된 블록)을 저장할 수 있다. 일반적으로는, 적어도 일부 파일 시스템 프로토콜에서 기록은 파일 또는 메타데이터 구조 내에서의 무작위 오프셋으로 지향될 수 있으므로, 논리적 블록 내에서의 모든 오프셋 범위가 데이터(또는 메타데이터)를 포함하고 있지는 않을 수 있는 것이 사실일 수 있다. 소정 논리적 블록의 콘텐츠는 묘사된 실시형태에서는 소정 익스텐트 내에 포함되어 있을 수 있다 - 예를 들어, 논리적 블록이 매핑되는 모든 물리적 페이지는 동일한 익스텐트의 일부분이어야 할 수 있다.
논리적 블록에서의 기록되지 않은 갭에 대한 잠재성 때문에, 초과가입 파라미터 세트는 익스텐트의 적어도 일부 서브세트에 대해 결정될 수 있고(요소(2704)), 그에 따라 블록이 가득 파퓰레이팅되게 되면 수용될 수 있는 것보다 더 많은 논리적 블록이 소정 익스텐트에 배정될 수 있다. 소정 익스텐트에 대한 파라미터는, 예를 들어, 초과가입 인자(예를 들어, 얼마나 많은 추가적 공간이 익스텐트에 매핑되는 논리적 블록에 잠재적으로 요구될 수 있는지의 척도), 익스텐트 확장과 같은 다양한 조치가 트리거링되어야 하는 (위에서 논의된 자유 공간 임계치와 같은) 하나 이상의 임계치, 임계치가 만족되면 현재 익스텐트의 콘텐츠가 복사/이동되어야 하는 선호되는 저장 디바이스 또는 익스텐트 등을 표시할 수 있다.
파일로의 또는 메타데이터 구조로의 제1 기록과 같은, 파일 스토어 객체의 논리적 블록(LB1)으로 지향된 특정 기록 요청에 응답하여, 가용 익스텐트 중 특정 익스텐트(E1)는 논리적 블록의 콘텐츠를 저장하도록 선택될 수 있다(요소(2707)). 예를 들어, E1은, LB1의 M개까지의 페이지를 포함하여, (멀티-테넌트 환경에서 수 개의 다른 파일 스토어 객체의 일부분일 수 있는) 총 P1개까지의 페이지를 저장할 수 있을 수 있다. 적어도 일부 시나리오에서, E1은 그것이 선택되는 때 초과가입될 수 있다 - 예를 들어, 그것에 매핑되는 논리적 블록(그 중 적어도 일부는 데이터 또는 메타데이터로 가득 파퓰레이팅되지는 않을 수 있음)의 조합된 크기는 E1의 현재 크기를 초과할 수 있다. E1은, 여러 다른 실시형태에서, 자유로운 그 저장 공간의 비율, 파일 스토어 객체에 선호되는 저장 디바이스의 유형(SSD 또는 회전 디스크-기반) 등과 같은 다양한 기준에 기반하여 선택될 수 있다. 하나 이상의 페이지가 제1 기록에 대해 E1 내에서 할당될 수 있고, 그리고 제1 기록 요청의 페이로드가 거기에 기록될 수 있다(요소(2710)). 할당된 페이지의 조합된 크기는 페이로드를 수용하기에 충분할 수 있지만, 할당된 페이지의 조합된 크기는 적어도 일부 경우에서는 (예를 들어, 페이로드 크기가 LB1의 크기보다 더 작으면) 논리적 블록(LB1)의 크기보다 더 작을 수 있다. 정상 동작 조건 하에서, 적어도 일부 실시형태에서는 E1은 기록을 구현하는 것이 E1의 자유 공간 제약을 위반하지 않았을 경우에만 제1 기록에 대해 선택되었을 것이다.
E1으로 지향된 크기(WS)의 기록 페이로드를 갖는 후속 기록 요청이 수신될 수 있다(요소(2713)). 후속 기록 요청은 LB1으로든 또는 E1에 매핑된 어떤 다른 논리적 블록으로든 지향될 수 있다. (요소(2716)에서 검출되는 바와 같이) 기록 페이로드(WS)를 수용하기에 충분한 물리적 페이지를 할당하는 것이 E1의 자유 공간 임계치 세트를 위반하지 않을 것이면, 요구된 수의 물리적 페이지가 할당될 수 있고, 요청된 기록이 수행될 수 있다(요소(2719)). (요소(2716)에서 또한 검출되는 바와 같이) E1의 자유 공간 임계치가 위반될 것이면, 묘사된 실시형태에서는 하나의 동기식 연산 및 하나의 비동기식 연산이 개시될 수 있다. 예를 들어, 기록 요청에 응답함에 있어서 어느 너무 긴 지연이라도 회피하도록, 기록 요청에 대해 동기식으로, 하나 이상의 추가적 페이지가 E1 내에서 할당될 것이다. 비동기식으로, 도 26b에 대해 위에서 논의된 종류의 익스텐트 확장 연산이 개시될 수 있다. 익스텐트 확장은, 예를 들어, 그 원래 저장 디바이스에서 E1-관련 메타데이터를 변경함으로써 E1의 제자리 확대를 수반할 수 있거나, 또는 그것은 더 큰 익스텐트가 구성될 수 있는 어떤 다른 저장 디바이스(및/또는 어떤 다른 저장 노드)로 E1의 콘텐츠 중 적어도 일부를 이송하는 것을 수반할 수 있다. 적어도 일부 실시형태에서, E1은 LB1이 블록인 파일 스토어와 연관된 데이터 영속성 정책에 따라 구성된 복제본 그룹의 (마스터 복제본과 같은) 하나의 익스텐트 복제본일 수 있고 그리고 E1에서 수행된 기록은 앞서 논의된 종류의 복제 기술(예를 들어, 소거 코딩, 완전 복제 등)에 따라 하나 이상의 추가적 복제본에 전파될 수 있음을 주목한다. 익스텐트가 초과가입되고 소정 블록 내에서의 페이지가 온-디맨드 할당되는 적어도 일부 실시형태에서, 소정 익스텐트 또는 논리적 블록 내에서의 페이지의 크기는 다를 수 있고, 그리고/또는 소정 파일 또는 메타데이터 구조 내에서의 논리적 블록의 크기는 다를 수 있다.
저장소의 동적 온-디맨드 페이지-레벨 할당은 동일한 논리적 블록의 부분들을 분리시키는 부작용을 가질 수 있다 - 예를 들어, 소정 논리적 블록에 대해 할당된 페이지는 적어도 일부 경우에서는 사용되는 저장 디바이스(들) 상에서 인접하지 않을 수 있다. 일부 실시형태에서는, 시간의 흐름에 따라 파일 스토어 연산의 다양한 특성을 모니터링하고, 예를 들어 초과가입 정도는 물론, 소정 논리적 블록의 페이지가 물리적 저장 디바이스 상에서 배치되는 방식도 포함하는, 익스텐트 초과가입이 구현되고 있는 방식을 최적화하는 것이 가능할 수 있다. 도 28은, 적어도 일부 실시형태에 따라, 익스텐트 초과가입 파라미터를 동적으로 수정하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(2801)에서 제시된 바와 같이, 물리적 페이지는 익스텐트(E1, E2 등)의 소정 세트에 대해 설정된 초과가입 파라미터의 초기 세트에 따라 데이터 및/또는 메타데이터에 대해 시간 기간(T1)에 걸쳐 할당될 수 있다.
초과가입된 익스텐트를 사용하여 수행되는 파일 스토어 연산에 관한 여러 다른 메트릭이 T1 동안 수집될 수 있다(요소(2804)). 예를 들어, 파일 액세스 패턴은, 예를 들어, 무작위 대 순차인 판독 및/또는 기록의 비율을 결정하기 위해 분석될 수 있다. 파일 크기에 관한(예를 들어, 평균 또는 중앙값 파일 크기에 관한, 그리고 파일의 크기가 시간의 흐름에 따라 변하려는 경향이 얼마나 있는지에 관한), 파일 내에서의 갭(예를 들어, 논리적 블록이 파퓰레이팅되는 정도)에 관한, 그리고/또는 다양한 유형의 연산에 대한 응답 시간 및 처리율에 관한 통계가 수집될 수 있다. 일부 실시형태에서 그리고 소정 유형의 연산에 대해, 파일 이름으로부터 파일 액세스의 개연적 패턴을 추론하는 것이 실현가능할 수 있다 - 예를 들어, 이-메일을 저장하는데 사용된 파일은 파일 이름 확장자에 기반하여 식별가능할 수 있고 특정 방식으로 액세스될 것으로 예상될 수 있고, 데이터베이스 로그 또는 웹 서버 로그에 사용된 파일은 이름에 의해 식별가능할 수 있고 특성 액세스 패턴을 가질 수 있고, 등이다. 저장소 사용에 관한 그러한 정보 및 메트릭은 초과가입 파라미터 중 어느 것을 수정하는 것이 바람직할 수 있는지, 또는 일부 논리적 블록의 물리적 페이지가 통합되어야 하는지 결정하기 위해, 예를 들어, 기계 학습 기술에 따라 저장 서비스의 옵티마이저 컴포넌트에서 분석될 수 있다. 초과가입 임계치를 변경하는 것이 공간 이용 레벨을 개선할 수 있다는 결정이 이루어지면(요소(2807)), 임계치는 그에 따라 수정될 수 있고(요소(2810)) 그리고 수정된 파라미터를 갖는 메트릭의 새로운 세트가 수집될 수 있다. 예를 들어, 일 실시형태에서, 파일 시스템(FS1)에 대한 초과가입 파라미터 설정은 초기에는 보수적으로 설정될 수 있다 - 예를 들어, 10%만의 초과가입 인자가 설정될 수 있다. 추후, FS1 내에서의 객체에 대한 주소 범위 갭 및 저장소 사용 메트릭이 분석된 후에, 허용된 초과가입 레벨은 가령 20%로 증가될 수 있다. (예를 들어, 순차적 판독/기록에 대한) 파일 스토어 성능이 소정 논리적 블록 세트의 물리적 페이지를 재배열함으로써 개선될 수 있다고 결정되면, 선택된 물리적 페이지의 콘텐츠는 (예를 들어, 소정 블록의 콘텐츠를 수용하도록 인접 공간을 할당하고, 그들 원래의 비-인접 장소로부터 인접 장소로 블록의 콘텐츠를 복사함으로써) 재배열될 수 있다(요소(2813)). 적어도 일부 실시형태에서, 그러한 재배열은 전형적으로는, 판독/기록 요청을 발행하는 클라이언트가 최적화 연산에 기인하는 지연을 체감하지 않도록, 들어오는 I/O 요청에 대해 비동기식으로 수행될 수 있다. 예를 들어 일부 익스텐트를 현재 사용되고 있는 것들보다 (SSD 같은) 더 빠른 저장 디바이스 또는 더 느린 저장 디바이스로 이동시키는 것과 같은 다른 유형의 최적화가 또한 다양한 실시형태에서 유사한 분석에 기반하여 개시될 수 있다.
가변
스트라이프
크기
일부 실시형태에서는, 메타데이터 크기와 저장 공간 효율 간 위에서 논의된 절충으로의 다른 접근법이 취해질 수 있다. 이러한 기술을 채용하는 일부 실시형태에서, 익스텐트는 초과가입될 필요가 없고, 그리고 소정 논리적 블록에 잠재적으로 요구될 수 있는 모든 저장소는, 예를 들어, 제1 기록이 블록으로 지향되는 때 선행 취득될 수 있다. 그렇지만, (위에서 논의된 바와 같이, 익스텐트, 저장 디바이스 또는 저장 노드를 가로질러 파일 데이터 및/또는 메타데이터를 스트라이핑하는 단위를 표현할 수 있는) 소정 저장 객체 내에서의 논리적 블록은 모두 동일한 크기는 아닐 수 있다. 일부 그러한 실시형태에서, 논리적 블록 크기, 및 한 번에 할당되는 공간의 양은 파일 내에서의 논리적 오프셋의 함수로서 증가될 수 있다. 처음 블록에 대해 할당되는 비교적 작은 양의 저장 공간으로 시작하여, 점점 더 많은 공간이 후속 블록에 대해 할당될 수 있다; 그리하여, 둘 다 객체 크기에 따라 선형으로 증가하는 양의 메타데이터를 생성하지 않고 작은 파일도 그리고 큰 파일도 구현하는 것이 가능할 수 있다.
도 29는, 적어도 일부 실시형태에 따라, 가변 스트라이프 크기를 사용하여 콘텐츠가 저장되는 파일 스토어 객체의 예를 예시한다. 도 4를 참조하여 논의된 바와 같이, 파일 스토어 객체의 다른 논리적 블록은 (반드시는 아니지만) 전형적으로는 각각의 저장 노드에서 다른 저장 디바이스에서의 다른 익스텐트에 매핑될 수 있음과, 그래서 논리적 블록은 스트라이프에 대한 균등물로 생각될 수 있음을 상기하라. 다양한 메타데이터 구조가 또한 다양한 실시형태에서 가변 스트라이프 크기를 사용하여 구현될 수 있기는 하지만, 파일(2900)이 저장 객체의 일례로서 선택된다. 파일(2900)은 4개의 스트라이프 또는 논리적 블록(LB)(2902A, 2902B, 2902C, 2902D)을 포함하는 것으로 도시되어 있다. 논리적 블록의 소정 서브세트는 동일한 크기일 수 있기는 하지만, 논리적 블록(2902) 중 적어도 일부는 나머지 중 적어도 일부와 크기가 다를 수 있다.
2개 유형의 익스텐트가 도 29에 도시되어 있다 - 고정-크기 페이지를 갖는 익스텐트 및 가변-크기 페이지를 갖는 익스텐트. 익스텐트(2934A)는 물리적 페이지(2910)를 포함하며, 그 각각은 크기가 S1 KB이다. 익스텐트(2934B)의 페이지(2910B)는 각각 크기가 S2 KB인 한편, 익스텐트(2934C)의 페이지의 각각은 크기가 S3 KB이다. S1, S2 및 S3는 묘사된 실시형태에서는 서로 다를 수 있다, 예를 들어, S1은 S2보다 더 작을 수 있고, 그리고 S2는 S3보다 더 작을 수 있다. 앞서 언급된 바와 같이, 적어도 고정 페이지 크기를 갖는 익스텐트에 대해, 물리적 페이지는 일부 실시형태에서는 지원되는 I/O의 가장 작은 단위를 표현할 수 있다. 그리하여, 묘사된 실시형태에서는 (2934B) 또는 (2934C)에서보다 익스텐트(2934A)에서 더 작은 판독 및 기록을 지원하는 것이 가능할 수 있다. 익스텐트(2934D)는 가변-크기 페이지를 지원한다 - 즉, (소정 특정된 최소치 및 최대치를 갖는) 임의 양의 물리적 공간이 익스텐트(2934D) 내에서 한 번에 할당될 수 있다. 대조적으로, 익스텐트(2934A, 2934B, 2934C) 내에서, 공간은 그들 각각의 페이지 크기의 배수로 할당될 수 있다. 적어도 일부 실시형태에서는, 단일 페이지 크기, 또는 페이지 크기의 이산 세트만이 지원될 수 있다.
LB(2902)로 지향된 제1 기록에 응답하여, 적어도 일부 실시형태에서는 (제1 기록의 기록 페이로드에 요구되는 물리적 공간보다 더 많을 수 있는) 전체 스트라이프에 대한 물리적 저장 공간이 선택된 익스텐트로부터 할당될 수 있다. 그리하여, 예를 들어, 익스텐트(2934A)의 하나 이상의 페이지(2910A)가 LB(2902A)에 사용될 수 있고, 그리고 익스텐트(2934B)의 하나 이상의 페이지(2910B)가 LB(2902B)에 사용될 수 있다. 유사하게, LB(2902C)에 대해서는, 하나 이상의 페이지(2910C)가 익스텐트(2934C)로부터 할당될 수 있고, 그리고 익스텐트(2934D)로부터의 하나 이상의 페이지는 LB(2902D)에 대해 할당될 수 있다. 일부 실시형태에서는, 어느 소정 논리적 블록 또는 스트라이프라도 물리적 저장 공간의 하나의 인접 영역에 매핑될 수 있는 한편, 다른 실시형태에서는, 소정 논리적 블록에 대해 할당된 물리적 공간은 적어도 일부 경우에서 저장 디바이스 주소 공간 내에서 비-인접일 수 있다. 예를 들어, 파일의 처음 몇개의 스트라이프에 대해 비교적 작은 스트라이프 크기가 사용되면, 작은 파일도 다수의 익스텐트를 가로질러 스트라이핑될 수 있고, 그리하여, 그와 달리 단일 큰 스트라이프 크기가 사용되었더라면 달성되지 않았을 수 있는 스트라이핑의 성능 혜택을 획득할 수 있다.
일반적으로, 묘사된 실시형태에서는, 특정된 오프셋 및 기록 페이로드 크기를 갖는 기록 요청이 수신될 때, 기록이 추가적 저장 공간이 할당될 것을 요구하는지에 관한 결정이 (오프셋 및 페이로드 크기에 기반하여) 이루어질 수 있다. 그러한 결정은 적어도 일부 실시형태에서는 저장 서비스의 메타데이터 노드에서 이루어질 수 있다. 공간이 할당될 필요가 있으면, 페이로드에 대해 할당될 (반드시는 아니지만 전형적으로) 인접 물리적 저장 공간의 양이 결정될 수 있다. 적어도 일부 실시형태에서, 할당되는 공간의 그 양은 기록 오프셋에 종속할 수 있다. (파일의 존속 동안의 스트라이프 크기결정 패턴, 및 스트라이프 크기를 결정할 때 고려될 수 있는 인자의 종류 중 일부의 예는 아래에서 더 상세히 논의된다). 소망 양의 공간을 할당하는데 사용될 수 있는 익스텐트를 갖는 하나 이상의 저장 노드가 식별될 수 있다. 예를 들어, 일-킬로바이트 스트라이프에 대한 공간이 할당되어야 하면, 저장 서비스는 1KB 페이지를 갖는 그리고 스트라이프의 기록을 수용하기에 충분한 자유 공간을 갖는 익스텐트를 식별하려고 시도할 수 있다. 선택된 익스텐트에서의 최소 페이지 크기는 스트라이프 또는 논리적 블록 크기와 같을 필요는 없음을 주목한다 - 예를 들어, 스트라이프 크기는 3KB일 수 있지만, 4KB 페이지를 지원하는 익스텐트가 사용될 수 있거나, 또는 2KB 페이지 또는 1KB 페이지를 지원하는 다른 익스텐트가 사용될 수 있다. 소망 스트라이프 크기에 대한 물리적 저장소가 획득된 후에, 기록 페이로드에 표시된 수정이 개시될 수 있다. 익스텐트가 복제되는 일부 실시형태에서, 예를 들어, 수정은 마스터 복제본이 저장되는 저장 노드로부터 조정될 수 있고, 마스터 노드로부터 또는 그에 의해 비-마스터 복제본에 전파될 수 있다.
일부 실시형태에서, 소정 파일 또는 메타데이터 구조 내에서의 스트라이프 크기는 예측가능한 방식으로 오프셋의 함수로서 변경될 수 있다. 도 30은, 적어도 일부 실시형태에 따라, 파일 스토어 객체에 사용될 수 있는 스트라이프 크기결정 시퀀스의 예를 예시한다. 스트라이프 크기 시퀀스(3010A)에서, 파일 스토어 객체의 처음 9개의 논리적 블록의 크기는 예를 들어, 각각, 1KB, 1KB, 2KB, 2KB, 4KB, 4KB, 8KB, 16KB 및 32KB로 설정될 수 있다. 그러한 패턴은, 예를 들어, 작을 것으로 예상되는 파일 또는 메타데이터 구조에 대해, 또는 비교적 느리게 증대할 것으로 예상되는 파일 또는 구조에 대해 사용될 수 있다. 예를 들어 많은 수의 순차적 기록이 어떤 높은 확률로 예상되는 다른 파일에 대해서는, 처음 4개의 블록의 크기가 각각 1MB, 4MB, 16MB 및 64MB로 설정되는, 다른 스트라이프 크기 시퀀스(3010B)가 사용될 수 있다. 그리하여, 스트라이프 크기의 이산 세트가 구현되는 구현에서도, 하나의 파일(F1)에 사용된 스트라이프 크기는 다른 파일(F2)에 사용된 스트라이프 크기 중 어느 것과도 다를 수 있다. 일부 실시형태에서, 사용될 스트라이프 크기 시퀀스(3010) 중 적어도 일부는 저장 서브시스템의 구성 파라미터로서 특정될 수 있다. 일부 경우에서는, 파일이 증대함에 따라, 더 작은 스트라이프를 더 큰 스트라이프로 통합하는 것이 (메타데이터 성능에도 그리고 데이터 액세스 성능에도) 유용할 수 있다.
도 31은, 적어도 일부 실시형태에 따라, 파일 스토어 객체에 대한 스트라이프 크기 결정(3170) 및/또는 통합 결정(3172)을 하기 위해 메타데이터 서브시스템에서 고려될 수 있는 인자의 예를 예시한다. 묘사된 실시형태에서, 메타데이터 서브시스템 노드(122)는, 파일 및 메타데이터 구조를 포함하는, 다양한 파일 스토어 객체에 대한 스트라이프/논릴적 블록 크기를 결정하는 것, 및 물리적 페이지 및/또는 논리적 블록이 조합 또는 통합되어야 하는지 및 그때를 결정하는 것을 책임지고 있을 수 있다. 공간이 할당되어야 하는 파일 스토어 객체의 다음 부분에 사용될 스트라이프 크기를 결정할 때, 메타데이터 노드(112)는 객체의 현재 크기(3101) 및 기록 요청 페이로드 크기(3103)를 고려할 수 있다. 일 구현에서, 예를 들어, 파일 스토어 객체에 대해 할당되는 제1 스트라이프의 크기는 객체로 지향된 제1 기록의 기록 페이로드에 기반할 수 있다 - 예를 들어, 제1 기록의 페이로드가 3.5 메가바이트이면, 4 메가바이트 스트라이프 크기가 선택될 수 있는 한편, 제1 기록이 2 메가바이트보다 작거나 같으면, 2 메가바이트 스트라이프 크기가 선택될 수 있다. 일부 실시형태에서, 파일 또는 디렉터리가 고객의 요청시 생성될 때, 예를 들어 객체가 주로 순차적 기록 및 판독에 사용될 것인지, 무작위 기록 및 판독에 사용될 것인지, 또는 순차적 및 무작위 액세스의 어떤 혼합에 사용될 것인지 표시하는 힌트(3105)가 저장 서비스에 제공될 수 있고, 그러한 힌트는 스트라이프/논리적 블록 크기를 선택하는데 사용될 수 있다. 여러 다른 크기의 기록 및/또는 판독에 대해 달성된 평균 응답 시간과 같은, 파일 시스템 성능의 메트릭(3110)은 또한 일부 실시형태에서는 논리적 블록 크기의 선택, 및/또는 앞서-생성된 스트라이프의 콘텐츠가 더 큰 스트라이프로 조합되는 통합 연산의 스케줄링에 영향을 미칠 수 있다.
일부 시나리오에서는, 앞서 논의된 바와 같이, 파일 또는 디렉터리의 이름(또는 파일 확장자와 같은, 이름의 일부분)은 파일 또는 디렉터리의 콘텐츠가 증대 또는 액세스될 것으로 예상되는 방식에 관한 소정 안내를 제공할 수 있다. 예를 들어, 이-메일 서버, 웹 서버, 데이터베이스 관리 시스템, 애플리케이션 서버 등과 같은 일부 애플리케이션은 그들 기능성의 다양한 부분에 대해 주지의 파일 확장자 및/또는 디렉터리 계층을 사용하고, 그리고 메타데이터 노드(112)의 옵티마이저 컴포넌트가 그러한 파일/디렉터리 이름(3115)에 기반하여 더 지능적으로 스트라이프 크기를 선택하는 것이 가능할 수 있다. 적어도 하나의 실시형태에서, 메타데이터 노드(112)는 액세스 패턴(예를 들어, 무작위 대 순차, 퍼센트 판독 대 퍼센트 기록, 판독 크기 분산, 기록 크기 분산)을 결정하고 그에 따라 스트라이프 크기를 선택할 수 있다. 객체 수명(예를 들어, 평균적으로, 얼마나 많은 시간이 소정 파일 스토어에서 파일의 생성과 삭제 사이에 경과하는지)의 측정치(3125)는 일부 실시형태에서는 스트라이프 크기 결정을 하는데 유용할 수 있다 - 예를 들어, 소정 디렉터리 내에서의 대부분의 파일이 생성 후 X 시간 내에 삭제될 것으로 예상되면, 그들 스트라이프 크기에 관한 결정은 많은 장기 충격을 갖지는 않을 수 있다. 일부 실시형태에서, (사용되고 있는 저장 노드의 CPU, 메모리 또는 네트워크 이용 레벨과 같은) 저장 노드 자원 이용 메트릭(3135) 및/또는 익스텐트 공간 이용 메트릭(3130)은 또한 스트라이프 크기를 결정하는데 역할할 수 있다. 일 실시형태에서, 소정 파일 또는 메타데이터 구조의 작은 스트라이프는 하나 이상의 트리거링 기준에 기반하여, 예를 들어, 파일 또는 구조가 임계 크기 이상으로 증대하면/그때 또는 파일로의 빈번한 순차적 액세스가 검출되면/그때 더 큰 스트라이프로 조합될 수 있다. 사용되고 있는 익스텐트의 특성에(예를 들어, 여러 다른 익스텐트에서 지원되는 특정 페이지 크기에) 종속하여, 그러한 조합 연산은 하나의 저장 디바이스로부터 다른 하나로 또는 하나의 익스텐트로부터 다른 하나로 데이터/메타데이터를 이동 또는 복사하는 것을 수반할 수 있다. 적어도 일부 실시형태에서는, 시간의 흐름에 따라 저장 서비스에서 이루어지는 스트라이프 크기결정 및/또는 통합 결정을 개선하도록 기계 학습 기술이 채용될 수 있다. 그러한 기계 학습 접근법의 일부분으로서, 전반적 파일 스토어 성능 및/또는 비용에 관한 도 31에 예시된 다양한 인자의 상대적 충격이 분석될 수 있다.
도 32는, 적어도 일부 실시형태에 따라, 가변 스트라이프 크기를 사용하여 스트라이핑을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 파일 스토어 객체 내에서의 기록 오프셋, 및 기록 페이로드를 표시하는 기록 요청은, 예를 들어, 분산형 멀티-테넌트 저장 서비스의 메타데이터 노드(112)에서 수신 또는 발생될 수 있다(요소(3201)). 일부 경우에서, 기록 요청은 파일 기록과 같은 고객-발행된 파일 시스템 API 호출에 응답하여 액세스 노드(122)에서 발생될 수 있는 한편, 다른 경우에서 메타데이터 노드는 소정 새로운 메타데이터가 저장되어야 한다고, 또는 기존 메타데이터가 수정되어야 한다고 자체가 결정할 수 있다. 기록 오프셋, 기록 페이로드, 및 표적 객체의 (있다면) 기존 메타데이터의 분석에 기반하여, 추가적 저장소가 기록을 구현하기 위해 할당되어야 한다는 결정이 이루어질 수 있다(요소(3204)). (앞서 언급된 바와 같이, 기-기록된 콘텐츠의 수정으로 전적으로 이루어진 일부 기록은 추가적 저장소를 요구하지 않을 수 있다).
파일 스토어 객체의 다음 새로운 스트라이프 또는 논리적 블록의 크기는, 예를 들어, (도 30에 도시된 시퀀스와 유사한) 파일 스토어 객체에 사용 중인 오프셋-기반 스트라이프 크기결정 시퀀스에 그리고/또는, 객체의 크기, 검출된 액세스 패턴 등과 같은, 도 31에 도시된 인자의 어떤 조합에 기반하여 결정될 수 있다(요소(3207)). 선택된 크기의 스트라이프의 적어도 하나의 복제본을 저장하도록 사용될 특정 익스텐트, 저장 노드 및/또는 저장 디바이스가 그 후 식별될 수 있다(요소(3210)). 도 29의 맥락에서 논의된 바와 같이, 적어도 일부 실시형태에서, 소정 익스텐트는 특정 물리적 페이지 크기를 사용하도록 구성될 수 있고, 결과로서 모든 익스텐트가 소정 논리적 블록 크기에 대해 공간을 할당하는데 적합하지는 않을 수 있다; 따라서, 익스텐트는 그 페이지의 크기에 기반하여 선택될 수 있다. 일부 시나리오에서는, 지원된 익스텐트의 물리적 페이지 크기의 이산 세트에 매핑되는 논리적 블록 크기의 이산 세트만이 허용될 수 있다. (도 29의 익스텐트(2911)와 같이) 가변 페이지 크기를 지원하도록 구성되는 익스텐트가 일부 실시형태에서는 이용가능할 수 있고, 그러한 익스텐트는 다양한 크기의 논리적 블록/스트라이프에 대해 공간을 할당하도록 선택될 수 있다. 일부 실시형태에서, (예를 들어, 수 개의 가용성 컨테이너 또는 데이터 센터 간 분산된) 복수의 저장 노드는 새로운 논리적 블록 또는 스트라이프에 대한 공간이 할당될 때 익스텐트의 복제본 그룹에 대해 식별될 수 있다.
소망 양의 물리적 저장 공간에 대한 할당 요청은 적어도 하나의 선택된 저장 노드에 보내질 수 있다(요소(3213)). 저장 노드는 요청된 물리적 저장소, 예를 들어, 스트라이프가 가득 파퓰레이팅되면 스트라이프의 콘텐츠를 저장하기에 충분한 페이지를 할당할 수 있다(요소(3216)). 기록 요청에서 표시된 수정은 그 후 개시 또는 수행될 수 있다(요소(3219)). 파일 스토어 객체와 연관된 데이터 영속성 정책에 종속하여, 기록 페이로드는 기록이 완료되었다고 생각될 수 있기 전에 수 개의 다른 복제본에 전파되어야 할 수 있다. 적어도 일부 실시형태에서는 온-디맨드 페이지 할당 및/또는 초과가입된 익스텐트가 위에서 설명된 종류의 가변 스트라이프 크기결정과 조합하여 사용될 수 있음을 주목한다.
오프셋-기반 정체 제어 기술
높은 병행으로 데이터 세트의 작은 부분들에 액세스하는 고객 작업부하는 분산형 파일 저장 서비스에서 핫 스폿을 야기할 수 있다. 예를 들어, 고객이 대략 동시에 다수의 실행 스레드를 사용하여 파일의 다수의 순차적 판독을 요청하면, 모든 스레드는 결국 처음에 파일의 초반 가까이에서 단일 스트라이프 또는 논리적 블록에 액세스하게 될 수 있다. 더욱, 판독 페이로드(고객으로부터의 각각의 판독 요청에서 요청되는 데이터의 양) 및 논리적 블록의 상대적 크기에 종속하여, 다수의 판독 요청이 각각의 스레드로부터 단일 스트라이프로 지향될 수 있다. 그러한 시나리오에서, 많은 클라이언트가 대략 동시에 동일한 논리적 블록으로부터의 다수의 판독을 요청할 때, 정체 제어 기술은 개개의 스레드에 대한 불량한 응답 시간 및/또는 불량한 전반적 처리율을 방지하기 위해 논리적 블록의 주소 범위 내에서 구현될 수 있다. 일부 실시형태에서, 그러한 정체 제어 기술은 I/O 요청과 오프셋-기반 우선순위를 연관시킬 수 있으며, 거기서 예를 들어 판독 요청에 부여된 스케줄링 우선순위는 논리적 블록 내에서의 판독 오프셋에 따라 증가할 수 있다.
오프셋-종속적 정체 제어 기술의 논의의 동기를 부여하기 위해, 우선순위결정되지 않은 판독 요청 스케줄링으로부터 초래될 수 있는 잠재적으로 문제 있는 시나리오의 예시가 유용할 수 있다. 도 33은, 적어도 일부 실시형태에 따라, 논리적 블록으로의 모든 판독 요청이 서로에 비해 동등한 우선순위를 승인받는 스케줄링 환경에서 저장 서비스 객체의 논리적 블록으로 지향된 다수의 병행 판독 요청에 의해 이루어진 진행의 일례의 타임라인을 예시한다. 잠재적 문제를 더 명확히 예시하기 위해 그 예의 다양한 파라미터에 대해 극단적 값이 선택되었다; 선택된 파라미터는 공통적 사용 시나리오를 표현하는 것으로 의도되지 않는다.
도 33에서 경과된 시간은 좌측으로부터 우측으로 증가한다. 대략 시간(T0)에서, 100개의 클라이언트 스레드는 익스텐트(E3334)의 2개의 물리적 페이지(PP1, PP2)에서 콘텐츠(예를 들어, 데이터든 메타데이터든)가 저장되는 논리적 블록(3302)의 순차적 판독을 각각 시작한다. 논리적 블록(3302)은, 예를 들어, 다른 논리적 블록(도시되지 않음)을 또한 포함하는 파일의 제1 논리적 블록을 표현할 수 있다. LB(3302)의 콘텐츠가, 예를 들어, 전체 논리적 블록을 판독하기 위해 한 번에 한 페이지 판독된다고 가정하면, 소정 클라이언트는 우선 PP1을 판독하고 그 후 PP2를 판독해야 한다. 익스텐트(E3334)는, 익스텐트 용량(3302)에 의해 표시된 바와 같이, 초당 25개까지의 페이지 I/O를 취급할 수 있다. 이러한 용량 한계는 불과 25개의 페이지 판독이 소정 초의 시간 동안 시작하도록 허용됨을 보장함으로써 예시된 예의 시나리오에서 시행된다고 가정될 수 있다. I/O 우선순위결정 정책(3301)에 의해 표시된 바와 같이, 모든 판독 요청은 (우선순위결정을 사용하지 않는 것과 동일한 효과를 갖는) 동등한 우선순위를 갖는 것으로 처리된다. 이들 파라미터를 고려하여, 타임라인을 따른 다음 시간들에서 클라이언트 요청의 상태를 생각해 본다: T0, T0+1초, T0+2초, T0+3초, 및 T0+4초.
대략 T0에서, 100개의 요청이 페이지(PP1) 판독을 시작하기를 기다리고 있다. 익스텐트 용량 제약에 기인하여, 25개만이 T0와 T0+1 사이에서 PP1 판독을 시작(및 완료)하도록 허용된다. 따라서, T0+1에서, 75개의 클라이언트는 아직 PP1을 판독하여야 하는 한편, 25개의 클라이언트는 PP1 판독을 완료하였다. 그렇지만, 모든 요청이 동등한 우선순위로 처리되기 때문에, PP1 판독을 완료한 25개의 클라이언트는 나머지 75개의 클라이언트가 PP1을 판독할 때까지 페이지(PP2)로 진행할 수 없을 수 있는 것이 사실일 수 있을 것이다. 그리하여, T0+1에서 더 어두운 둥근 모서리 직사각형에 의해 표시되는 25개의 클라이언트는 다른 75개가 PP1 판독을 완료하기를 기다릴 수 있다. 시간(T0+2)에서, 25개 더 클라이언트가 PP1 판독을 완료하였을 수 있지만, 그것들 역시, 나머지 50개의 클라이언트가 PP1을 판독할 때까지, 기다려야 할 수 있다. 시간(T0+3)에서, 25개의 클라이언트가 아직 PP1을 판독해야 할 수 있고, PP0를 판독한 75개는 그것들을 기다리도록 강제될 수 있다. LB(3302)의 페이지로 지향된 모든 판독 요청에 동등한 우선순위가 배정되는 예의 시나리오에서는 T0+4에서만, 모든 100개의 클라이언트가 제1 페이지를 판독하였을 때, 클라이언트 중 어느 것이라도 페이지(PP2)로 진행하도록 허용된다.
적어도 일부 실시형태에서는 더 많이 진행한 그들 클라이언트에 더 높은 우선순위(또는, 균등하게는, 더 낮은 비용)를 배정함으로써 순차적 판독에 대해 달성되는 전반적 성능을 개선하는 것이 가능할 수 있다. 도 34는, 적어도 일부 실시형태에 따라, 오프셋-기반 정체 제어 정책이 사용되는 스케줄링 환경에서 저장 서비스 객체의 논리적 블록으로 지향된 다수의 병행 판독 요청에 의해 이루어진 진행의 일례의 타임라인을 예시한다. 논리적 블록(3302)은 재차 초당 25개의 페이지 I/O의 용량을 갖는 익스텐트(E3334)에서의 2개의 페이지(PP1, PP2)를 포함한다. 묘사된 실시형태에서, LB(3302)는 정체 제어를 구현하기 위해 오프셋-기반 I/O 우선순위결정 정책(3401)을 갖는다. 정책에 따라, LB(3302) 내에서의 더 높은 오프셋으로 지향된 판독 요청에는 더 낮은 오프셋으로 지향된 판독 요청보다 더 높은 우선순위가 부여된다.
대략 T0에서, 100개의 클라이언트는 그들 순차적 판독 연산을 시작한다. T0+1에서, 25개의 클라이언트는 페이지(PP1) 판독을 완료하였고, 그리고 이들 25개의 클라이언트는 이제 나머지 75개보다 더 높은 오프셋에서의 판독을 요청하고 있다. 오프셋-기반 우선순위결정 정책에 따라, PP1 판독을 마친 25개의 클라이언트는 시간(T0+1)에서 나머지 75개보다 더 높은 우선순위를 승인받는다. 그리하여, 그들 25개의 클라이언트는 이제 페이지(PP2) 판독을 시작하는 한편, 나머지 75개는 기다린다. 시간(T0+2)에서, 25개의 클라이언트는 LB(3302) 전부를 판독하는 것을 마쳤고, 순차적으로 판독되는 파일 또는 메타데이터 구조의 (있다면) 다음 논리적 블록으로 계속 진행할 수 있다. 다음 논리적 블록은 (높은 확률로) 다른 저장 디바이스에서 저장될 것이므로, 이것은, T0+2로부터 시작하여, 100개의 클라이언트의 작업부하는, 동등한 우선순위가 사용되고 있는 경우에서처럼 아직 동일한 익스텐트로 지향되는 대신에, 2개의 저장 디바이스를 가로질러 분산되기 시작할 것임을 의미한다. T0+3에서, 25개 더 클라이언트가 PP1 판독을 마쳤고, 아직 PP1을 판독하여야 하는 나머지 50개의 클라이언트보다 더 높은 우선순위를 승인받는다. T0+4에서, 25개 더 클라이언트가 양 페이지 판독을 마쳤고, 다음 논리적 블록으로 진행할 수 있다. 그러는 동안, 50개의 클라이언트는 도 34에서는 T0+4에서 아직 페이지(PP1)를 판독해야 한다(그것은, 그들 50개의 클라이언트의 관점에서는, T0+4에서 모든 100개의 클라이언트가 페이지(PP1) 판독을 마치는 도 33에 도시된 바와 같이 모든 클라이언트에 동등한 우선순위가 사용되고 있었으면 달성되었을 수 있는 것보다 더 나쁜 결과이다). 그렇게, 일부 클라이언트 요청은 도 34에 예시된 기법에서는 다른 것들에 대해 다소 "불공평하게" 처리될 수 있다. 불공평의 다른 예시로서, I/O 요청(R1, R2)이 각각 클라이언트(C1, C2)로부터 시간(Tk) 및 시간(Tk+delta)에서 수신되는 시나리오를 생각해 보는데, 여기서 R1은 논리적 블록 내에서의 오프셋(O1)으로 지향되고, R2는 논리적 블록 내에서의 오프셋(O2)으로 지향되고, 그리고 O2는 O1보다 더 크다. R2가 R1 후에 수신되더라도, R2는 그 더 높은 오프셋에 기반하여 더 높은 우선순위를 배정받을 수 있고, 그리하여 도 34의 기법 하에서는 R1보다 앞서 스케줄링 및/또는 완료될 수 있다. 일부 경우에, R2가 순차적 판독 패턴의 일부분이면, 예를 들어, 순차적 판독의 전체 세트는 오프셋-기반 우선순위결정의 결과로서 R1이 스케줄링되기 전에 완료될 수 있다. 그렇지만, 이러한 "불공평"에도 불구하고, 도 34의 기법은, 다양한 클라이언트 세트의 순차적 판독이 오프셋에 무관하게 모든 요청에 동등한 우선순위가 사용되는 경우보다 여러 다른 저장 디바이스 간 더 빨리 분산되게 되는 경향이 있을 것이므로, 일반적으로는 더 신속히 I/O 작업부하 병렬성을 초래하는 경향이 있을 것이다. (대부분의 파일 스토어 객체에 대해 그럴 것으로 예상되는) 액세스되는 파일 스토어 객체가 여러 다른 저장 디바이스에서의 복수의 스트라이프를 포함하는 시나리오에서, 오프셋-기반 우선순위결정을 사용하여 저장 디바이스를 가로질러 더 균등하게 작업부하의 그러한 확산은 순차적 연산에 대한 전반적 처리율 및 전반적 평균 완료 시간을 개선하는 것을 도울 수 있다. 수백 또는 수천 개의 클라이언트를 병행 지원하는 멀티-테넌트 저장 서비스의 컴포넌트의 관점에서, 특정 페이지 판독 요청이 무작위 판독인지 순차적 판독 시퀀스의 일부분인지 추적하는 것이 항상 간단(또는 효율적)하지는 않을 수 있고, 그리고 결과로서 일부 실시형태에서 오프셋-기반 우선순위결정은, 판독이 더 큰 순차적 스캔의 일부분인지 여부에 무관하게, 일반적으로 페이지-레벨 판독에 사용될 수 있다. 적어도 일부 실시형태에서, 논리적 블록 내에서의 오프셋-기반 우선순위결정은 데이터 및/또는 메타데이터 상의 다음 유형의 연산의 어느 조합에 대해서라도 사용될 수 있다: 순차적 판독, 순차적 기록, 무작위 판독, 또는 무작위 기록.
도 34에 예시된 것들과 유사한 원리에 기반하는 여러 다른 오프셋-기반 정체 제어 기술이 여러 다른 실시형태에서 채용될 수 있다. 도 35a는, 저장 서비스에서 I/O 요청을 스케줄링하는데 사용될 수 있는 토큰-기반 정체 제어 메커니즘의 일례를 예시하는 한편, 도 35b는, 적어도 일부 실시형태에 따라, 채용될 수 있는 오프셋-기반 토큰 비용 정책의 예를 예시한다. 일반적으로 말하자면, 토큰-기반 메커니즘은, 저장 객체, 데이터베이스 테이블, 데이터베이스 파티션 등과 같은 다양한 유형의 개체의 작업부하 관리에 사용될 수 있다. 분산형 파일 저장 서비스의 맥락에서, 그러한 버킷은 다양한 실시형태에서 파일의 논리적 블록에 대해, 메타데이터 구조의 논리적 블록에 대해, 전체 파일에 대해, 그리고/또는 전체 메타데이터 구조에 대해 유지되고 있을 수 있다. 제시의 단순함을 위해 토큰(3501)의 단일 버킷(3508)을 사용하는 메커니즘이 도 35a에 예시되어 있다; 그렇지만, 판독 연산에 대한 하나의 버킷 및 기록 연산에 대한 다른 버킷과 같은 다수의 버킷의 조합이 일부 실시형태에서는 사용될 수 있다. 메커니즘에 따라, 파일의 논리적 블록과 같은 특정 작업 표적과 연관된 정체 제어 목적으로 셋업된 버킷(3508)(예를 들어, 적어도 일부 실시형태에서는 소프트웨어 정체 제어 모듈 내에서의 데이터 구조로서 구현될 수 있는 논리적 컨테이너)은, 화살표(3504A)를 통하여 표시된 바와 같이, 버킷 초기화 동안 토큰(3501)의 초기 세트로 파퓰레이팅될 수 있다. 초기 파퓰레이션은 다양한 실시형태에서, 예를 들어, 병행 작업부하 레벨의 예상, 작업 표적과 연관된 프로비저닝된 연산 한계, 또는 그러한 인자의 어떤 조합에 기반하여 결정될 수 있다. 일부 유형의 버킷에 대해, 초기 파퓰레이션은 일부 실시형태에서 영으로 설정될 수 있다. 일부 구현에서, 버킷의 초기 파퓰레이션은 버킷이 구성되는 최대 파퓰레이션으로 설정될 수 있다.
(판독 요청 또는 기록 요청과 같은) 새로운 I/O 요청(3522)이, 예를 들어, 저장 노드(132)의 정체 제어 서브컴포넌트에서 수신될 때, 정체 컨트롤러는 묘사된 실시형태에서는 소정 수(N)의 토큰(여기서, 구현에 또는 구성 파라미터에 종속하여, N은 1보다 크거나 같을 수 있음)이 버킷(3508)에 존재하는지 결정하려고 시도할 수 있다. 그 수의 토큰이 버킷에서 이용가능하면, I/O 요청(3522)은 즉시 실행이 수락될 수 있고, 그리고 토큰은 버킷으로부터 제거 또는 소비될 수 있다(화살표(3506)). 그와 달리, N개의 토큰이 존재하지 않으면, 요청된 저장 연산의 실행은 묘사된 실시형태에서는 충분한 토큰이 이용가능하게 될 때까지 연기될 수 있다. 소정 I/O 요청에 소모된 토큰의 수는 I/O 요청을 수락하는 "비용"이라고 지칭될 수 있다.
(3504B)로 라벨이 붙은 화살표에 의해 제시된 바와 같이, 버킷(3508)은, 예를 들어 버킷과 연관된 보충률과 같은 구성 파라미터에 기반하여, 시간의 흐름에 따라 보충 또는 리파퓰레이팅될 수 있다. 일부 구현에서, 토큰 보충 연산은 소비 연산에 수반하거나 그에 근접한 가까운 시간에 수행될 수 있다 - 예를 들어, 단일 소프트웨어 루틴 내에서, 요청을 수락하는데 N개의 토큰이 소비될 수 있고, 그리고 버킷이 마지막으로 보충된 이후로 경과한 시간 및 보충률에 기반하여 M개의 토큰이 추가될 수 있다. 소정 버킷의 토큰 카운트 또는 보충률은, 예를 들어, 전형적으로 단시간 간격 동안, 더 높은 작업 요청률이 취급될 수 있게 하기 위해 일부 구현에서 수정될 수 있다. 일부 실시형태에서는 버킷이 수용할 수 있는 토큰의 최대 수에 관해 그리고/또는 토큰의 최소 수에 관해, 예를 들어, 구성 파라미터를 사용하여 한계를 둘 수 있다. 구성 파라미터 설정의 다양한 조합을 사용하여, 여러 다른 실시형태에서 토큰 버킷을 사용하는 아주 정교한 수락 제어 기법이 구현될 수 있다. 특히, 아래에서 설명되는 바와 같이, 다른 오프셋으로 지향된 I/O 요청에 대해 다른 토큰 비용을 요구함으로써, 도 34의 예와 유사한 오프셋-기반 우선순위결정이 구현될 수 있다.
단순한 일례의 시나리오에서, 논리적 블록(LB1)에서 동등한 우선순위의 25개의 초당 I/O 요청(IOPS)의 정상 부하를 지원하기 위해, 버킷(3508)은 25개 토큰의 초기 파퓰레이션, 25개 토큰의 최대 허용가능한 파퓰레이션 및 영 토큰의 최소치로 구성될 수 있다. I/O당 비용은 1개 토큰으로 설정될 수 있고, 보충률은 초당 25개 토큰으로 설정될 수 있고, 그리고 40 밀리초마다 한 번 하나의 토큰이 (최대 파퓰레이션 한계가 초과되지 않는다고 가정할 때) 보충 목적으로 추가될 수 있다. I/O 요청(3522)이 도착할 때, 각각의 요청에 대해 하나의 토큰이 소비될 수 있다. 각각의 초 동안 균일하게 분산된, 25 IOPS에서의 정상 상태 작업부하가 가해지면, 보충률과 작업부하 도착률은 서로 밸런싱할 수 있다. 그러한 정상-상태 작업부하는, 위에 열거된 버킷 파라미터를 고려하면, 일부 실시형태에서는 무한 지속될 수 있다. 그렇지만, 25개보다 많은 I/O 요청이 소정 초 동안 수신되면, 일부 요청은 기다려야 할 수 있고 그리고 도 33에 예시된 종류의 시나리오가 초래될 수 있다.
오프셋에 무관하게 I/O 요청당 1개 토큰으로 비용을 설정하는 대신에, 일 실시형태에서는 파일에서의 더 높은 오프셋으로 향하여 지향된 I/O 요청에 요구되는 것보다 더 많은 토큰이 더 작은 오프셋으로 향하여 지향된 I/O 요청에 요구될 수 있다. 그러한 토큰 비용 정책(3576)의 일례는 도 35b에 도시되어 있다. 정책(3575)에 따라, 논리적 블록 내에서의 0과 64KB 사이의 오프셋으로 지향된 각각의 I/O에 대해서는 10개 토큰이 요구되고, 64KB와 256KB 사이의 오프셋으로 지향된 I/O에 대해서는 5개 토큰이 요구되고, 그리고 256KB보다 더 큰 오프셋으로 지향된 각각의 I/O에 대해서는 1개 토큰이 요구된다. 더 많은 토큰이 더 낮은 오프셋에 요구되므로, 더 낮은 오프셋으로 지향된 I/O는 소정 토큰 버킷 파퓰레이션 및 보충률에 대해서는 지연 또는 차단될 개연성이 더 많을 수 있는 한편, 더 높은 오프셋으로 향하여 지향된 I/O는 일반적으로 더 신속히 스케줄링될 수 있다. 여러 다른 실시형태에서 다양한 다른 수학적 함수 또는 매핑이 오프셋으로부터 비용을 컴퓨팅하도록 (예를 들어, 휴리스틱스, 저장 시스템의 기계 학습 컴포넌트, 또는 관리자에 의해 선택된 구성 설정에 기반하여) 선택될 수 있다. 일부 실시형태에서는 선형 오프셋-기반 토큰 비용 정책(3561)이 사용될 수 있는 한편, 다른 실시형태에서는 (3562)와 같은 비-선형 비용 정책이 사용될 수 있다. 다양한 논리적 블록, 파일 또는 메타데이터 구조에 사용되는 비용 정책, 보충률 및 다른 정체 제어 파라미터는, 예를 들어 저장 서비스로부터 획득된 성능 메트릭의 분석에 응답하여, 시간의 흐름에 따라 수정될 수 있다. 일부 실시형태에서 소정 파일 스토어 객체 내에서의 다른 논리적 블록에는 다른 파라미터가 사용될 수 있고, 그리고/또는 다른 파일 스토어 객체에 대해서는 다른 파라미터가 선택될 수 있다. 적어도 일부 실시형태에서는, 유사한 오프셋-기반 정체 제어 기술이 논리적 블록 레벨에서 대신에 또는 그에 부가하여 파일 스토어 객체 레벨에서 적용될 수 있다 - 예를 들어, 오프셋(Y)으로 지향된 I/O에 배정되는 것보다 더 높은 우선순위가 파일 내에서의 오프셋(X)으로 지향된 I/O에 배정될 수 있으며, 여기서 Y는 X보다 더 작다. 토큰-기반 기술을 사용하는 대신에, 일부 구현에서는, 다른 가변 비용 배정 기술이 논리적 블록 내에서 또는 저장 객체 내에서 지향된 I/O 요청에 여러 다른 우선순위를 배정하도록 일부 실시형태에서 사용될 수 있다. 예를 들어, 일 실시형태에서는, 단순히 수치 비용이 각각의 I/O 요청에 배정될 수 있고, 그리고 미결 I/O 요청은 배정된 비용의 역순으로 취급될 수 있다.
적어도 하나의 실시형태에서, 각각의 큐는 논리적 블록 또는 파일 스토어 객체 내에서의 여러 다른 오프셋 범위로 지향된 I/O 요청에 대해 셋업될 수 있다. 각각의 그러한 큐는 그 큐잉된 I/O 요청 중 어느 하나라도 서비싱되기 전에 연관된 지연 간격을 가질 수 있으며, 더 낮은-오프셋 I/O 요청에 더 큰 지연이 배정된다. 도 36은, 적어도 일부 실시형태에 따라, 저장 서비스에서의 정체 제어에 오프셋-기반 지연을 사용하는 일례를 예시한다. 묘사된 실시형태에서는, 4개의 큐(3602A, 3602B, 3602C, 3602D)가 도시되어 있으며, 각각은 논리적 블록의 특정 오프셋 범위 내에서의 (요청(R3631)과 같이, "R"로 시작하는 라벨에 의해 표시된) I/O 요청에 지정된다. 큐(3602A)는 0과 P-1 사이의 (예를 들어, 바이트에서의) 오프셋으로의 I/O 요청에 사용되고; 큐(3602B)는 P와 2P-1 사이의 오프셋으로의 I/O 요청에 사용되고; 큐(3602C)는 2P와 4P-1 사이의 오프셋을 갖는 I/O 요청에 사용되고; 큐(3602D)는 4P보다 더 높은 오프셋을 갖는 I/O 요청에 사용된다. 각각의 큐(3602)는, 그 큐의 어느 2개의 큐잉된 I/O 요청의 구현 사이에 경과해야 하는 최소 시간을 표시하는, 연관된 최소 지연을 갖는다. 큐(3602A, 3602B, 3602C, 3602D)에 대한 최소 지연은 각각 4d, 2d, d, 및 0으로서 도시되어 있다. d가 1초로 설정되고, 시간(T)에서의 다양한 큐의 파퓰레이션이 도시된 대로이고, 그리고 적어도 수 초 동안 새로운 요청이 도착하지 않는 일례의 시나리오를 생각해 본다. 큐(3602D)의 요청이 영 초의 최소 지연을 가지므로, 처음에 요청(R3634)이, 다음에 (R3638)이 스케줄링될 수 있다. 그 후, 큐(3602C) 내에서의 요청이, 각각의 요청의 완료와 다음 것의 개시 사이에 1초의 지연으로, 스케줄링될 수 있다. 그 후 큐(3602B)의 요청이 2-초 간격으로, 다음에 큐(3602A)의 요청이 각각의 쌍의 요청 간 4초의 지연으로 스케줄링될 수 있다. 묘사된 실시형태에서, 최소 지연이 I/O 요청의 큐잉 지연에 부가될 수 있다. 예를 들어, 특정 요청(R1)은 단순히 R1 전에 도착한 동일한 오프셋 범위에 다른 요청이 있기 때문에 그 큐에서 K초 기다려야 할 수 있고, 그리고 그 후, R1이 큐의 앞에 도달할 때, R1은 그 큐와 연관된 최소 지연 동안 아직 기다려야 할 수 있다. 요청들을 스케줄링하는 것 사이의 지연은 일반적으로 묘사된 실시형태에서는 그들 지연 동안 도착하는 더 높은-오프셋(및 그리하여 더 높은-우선순위) 요청이 더 신속히 서비싱될 수 있게 할 수 있다. 간단한 오프셋-기반 큐잉 기술의 여러 변종이 여러 다른 실시형태에서 정체 제어에 사용될 수 있다 - 예를 들어, 일 실시형태에서, 소정 큐(3602)와 연관된 지연은 서비스를 기다리고 있는 더 높은-우선순위 요청의 수에 종속할 수 있다. 일 구현에서, 소정 I/O 요청에 사용될 지연은 단순히 그 오프셋에 상수를 승산함으로써 컴퓨팅될 수 있다.
일부 실시형태에서는, 오류 메시지가 오프셋-기반 우선순위결정을 구현하기 위한 메커니즘으로서 사용될 수 있다. 특정 I/O 요청(R1)이 더 낮은 오프셋 어떤 다른 요청 또는 요청들로 지향되면, 더 많은 토큰이 R1에 사용될 것을 요구하거나 R1을 큐에 배치하는 대신에, R1을 제출한 클라이언트에 오류 메시지가 반환될 수 있다. 그 후 클라이언트는 (I/O가 클라이언트에 의해 아직 필요하다고 생각된다고 가정하면) I/O 요청을 재시도할 수 있다. 재시도로부터 초래되는 지연은 위에서 설명된 바와 같이 오프셋-기반 큐에서 요청의 삽입과 유사하다고 생각될 수 있다.
적어도 일부 실시형태에서, 논리적 블록이 저장되는 저장 디바이스는 우선순위결정 정책이 시행되기 전에 임계 작업부하 레벨에 도달해야 할 수 있다. 예를 들어, 도 35에서, 익스텐트(E3334)는 초당 25개 페이지 I/O의 정의된 또는 베이스라인 용량을 갖고, 결과로서, 우선순위결정 정책은 묘사된 실시형태에서 작업부하가 용량을 초과할 때(또는 적어도 다가갈 때)만 적용될 수 있다. 우선수위결정을 트리거링하는 임계치는 적어도 일부 실시형태에서는 자체가 수정가능한 파라미터일 수 있다. 예를 들어, 다양한 실시형태에서는, 구별되는 임계치가 여러 다른 익스텐트에, 여러 다른 저장 노드에, 여러 다른 물리적 저장 디바이스에, 또는 동일한 익스텐트 내에서의 여러 다른 논리적 블록에 적용될 수 있다. 그러한 임계치는 다양한 인자에 기반하여 동적으로 수정될 수 있다. 일 구현에서, 임계치는 익스텐트의 (예를 들어, 소정 시간 기간에 걸쳐 획득된 측정치의 통계적 분석에 기반하여 컴퓨팅된 바와 같은) 전반적 작업부하 레벨, 익스텐트가 위치하고 있는 저장 노드 또는 저장 디바이스, 또는 임계치가 적용되는 특정 논리적 블록에도 적어도 부분적으로 기반하여 변경될 수 있다. 임계치를 조절하는데 사용될 수 있는 다른 인자는, 예를 들어, 대리에 의해 논리적 블록을 포함하고 있는 저장 서비스 객체가 생성된 클라이언트 또는 논리적 블록으로의 I/O 요청을 제출하는 클라이언트(들)의 신원(예를 들어, 일부 클라이언트는 다른 것들보다 더 중요하다고 생각될 수 있고 그리하여 더 높은 임계치를 배정받을 수 있음), 시각(예를 들어, 임계치는 11PM과 6PM 사이와 같은 전형적으로 낮은-사용 기간 동안에는 증가될 수 있음), 또는 익스텐트를 사용하여 구현된 파일 시스템, 디렉터리, 파일, 볼륨 또는 다른 저장 객체의 이름을 포함할 수 있다.
일부 실시형태에서는, 무작위의 요소가 정체 제어 기술에 부가될 수 있다 - 예를 들어, 각각의 오프셋 범위에 대해 고정 지연을 구현하는 대신에, (소정 선택된 난수 발생기를 사용하여 획득된) 무작위 컴포넌트를 포함하는 지연이 사용될 수 있다. 토큰-기반 정체 제어 기법에서는, 난수의 토큰이 소정 오프셋 범위로의 I/O 요청에 대한 요건에 부가될 수 있다. 그러한 무작위화는 일부 경우에서 작업부하 분산을 고루 펴는 것을 도울 수 있고, 예를 들어, 저장 디바이스가 결국 충분히 이용되지 않게 될 수 있는 바람직하지 못한 에지 케이스의 확률을 감축하는 것을 도울 수 있다.
적어도 일부 실시형태에서는, 다른 정체 제어 정책이 다른 카테고리의 저장 연산에 사용될 수 있다. 도 37은, 적어도 일부 실시형태에 따라, 액세스되는 저장 객체의 유형 및 요청된 액세스의 다양한 특성에 종속할 수 있는 정체 제어 정책의 예를 예시한다. 테이블(3780)에서 제시된 바와 같이, 정체 제어 파라미터 설정(3710)은 콘텐츠 유형(3702)(예를 들어, 메타데이터 대 데이터), 요청이 판독인지 아니면 기록인지(I/O 유형 칼럼(3704)), 및/또는 요청이 순차적 시퀀스의 일부분인지 아니면 무작위 시퀀스의 일부분인지(액세스 패턴 칼럼(3706))에 기반하여 달라질 수 있다. 여러 다른 정체 제어 설정이 I/O 페이로드 크기(칼럼(3708))(예를 들어, 얼마나 많은 바이트의 데이터/메타데이터가 판독 또는 기록되고 있는지)에 그리고/또는 표적 객체의 현재 크기(칼럼(3710))에 기반하여 또한 또는 대신 사용될 수 있다.
개개의 판독 페이로드 크기가 4KB보다 더 작고 그리고 메타데이터 구조가 S1 MB보다 더 작은, 메타데이터 구조의 순차적 판독에 대해, 묘사된 실시형태에서는 선형 오프셋-기반 우선순위결정이 정체 제어에 사용될 수 있다. 어느 크기의 무작위 메타데이터 기록 연산이라도 동등한 우선순위를 갖는 것으로 처리되게 된다. 크기 > 128MB인 파일로 지향된, 64KB보다 더 큰 페이로드 크기를 갖는 순차적 데이터 판독은 오프셋의 함수로서 지수함수형 감쇠를 갖는 오프셋-기반 우선순위를 사용하게 된다. 정체 제어 정책의 (각각의 우선순위 레벨과 연관된 비용, 여러 다른 우선순위에 대한 오프셋 경계, 또는 요청들 간 최소 지연과 같은) 다양한 상세는 제시를 단순화하기 위해 도 36에서는 생략되었다. 도 36에서 제시된 것들과 다른 인자가 여러 다른 실시형태에서 정체 제어 파라미터를 배정하는데 사용될 수 있음과, 적어도 일부 실시형태에서는 도 36에서 제시된 모든 인자가 고려될 필요는 없음을 주목한다. 예를 들어, 일부 실시형태에서, 정체 제어 기술은 병행 순차적 판독에만 사용될 수 있다.
도 38은, 적어도 일부 실시형태에 따라, 저장 서비스에서 I/O 연산을 스케줄링하기 위해 오프셋-기반 정체 제어를 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(3801)에서 제시된 바와 같이, 멀티-테넌트 파일 저장 서비스에 의해 관리되는 (파일 또는 메타데이터 구조와 같은) 저장 객체의 논리적 블록(LB1)의 적어도 일부로 지향된 I/O 요청(판독 또는 기록)이 수신될 수 있다. 다른 실시형태에서, 오프셋-기반 정체 제어 결정은 위에서 설명된 다양한 서브시스템 중 어느 것에서라도, 또는 서브시스템의 조합에 의해 이루어질 수 있다. 일부 실시형태에서 파일 판독/기록에 대한 정체 제어 결정은 액세스 서브시스템 노드에서 이루어질 수 있는 한편, 메타데이터에 대한 결정은 메타데이터 서브시스템에서 이루어질 수 있다. 다른 실시형태에서, 정체 제어 결정은 데이터에 대해서도 그리고 메타데이터에 대해서도 저장 서브시스템 노드에서 이루어질 수 있다. I/O 요청을 이행하기 위해 하나 이상의 저장 연산이 수행되어야 하는 논리적 블록(LB1) 내에서의 오프셋이 결정될 수 있다(요소(3804)).
오프셋에 적어도 부분적으로 기반하여, 하나 이상의 정체 제어 파라미터의 값(예를 들어, 저장 연산의 실행 전 지연, 또는 토큰 버킷으로부터 소비될 토큰의 수와 같은, IO 요청에 배정되는 비용 값)이 결정될 수 있다(요소(3807)). 적어도 일부 실시형태에서, 선택된 파라미터는 더 낮은 오프셋에서의 요청에보다는 논리적 블록(LB1) 내에서의 더 높은 오프셋에서의 요청에, 더 높은 우선순위를 부여하거나, 유리할 수 있다. 그 후 I/O 요청에 대응하는 저장 연산은 선택된 정체 제어 파라미터에 따라 스케줄링될 수 있다(요소(3810)). 적어도 일부 실시형태에서 그리고 소정 유형의 I/O 요청에 대해, 응답이 요청자에 제공될 수 있다(요소(3813)). 파일 시스템 인터페이스/프로토콜을 구현하는 서비스, 저장 객체가 범용 레코드 식별자(URI)와 연관되는 웹 서비스 인터페이스를 구현하는 서비스, 또는 블록-레벨 디바이스 인터페이스를 구현하는 서비스를 포함하는, 여기에서 설명된 것들과 유사한 오프셋-기반 정체 제어 기술이 여러 다른 실시형태에서 다양한 저장 서비스 환경에서 사용될 수 있음을 주목한다.
일관된 객체 이름변경 기술
분산형 파일 저장 서비스에서, 객체 이름변경 연산 - 예를 들어, 파일 또는 디렉터리의 이름을 변경하라는 고객 요청에 응답하여 수행되는 연산은 적어도 일부 경우에서는 하나보다 많은 메타데이터 노드(또는, 메타데이터 서브시스템이 저장 서브시스템에서 그 구조를 저장하면, 하나보다 많은 저장 노드)에서 저장된 메타데이터 요소에 대한 업데이트를 수반할 수 있다. 앞서 설명된 분산형 트랜잭션 기술이 그러한 멀티-노드 이름변경을 구현하는데 사용될 수 있기는 하지만, 적어도 일부 실시형태에서는 다른 이름변경-특정적 메커니즘이 아래에서 설명되는 바와 같이 사용될 수 있다. 도 39는, 적어도 일부 실시형태에 따라, 이름변경 연산을 구현하도록 파일 저장 서비스의 복수의 메타데이터 서브시스템 노드에서 수행되어야 할 수 있는 메타데이터 변경의 일례를 예시한다. 예로서, 파일 "A.txt"을 "B.txt"로 이름변경하는데 필요한 메타데이터 변경이 예시되기는 하지만, 디렉터리 이름변경, 링크 이름변경 등에 유사한 변경이 이루어질 수 있다. 묘사된 실시형태에서는, 저장 서비스의 3개의 메타데이터 서브시스템 노드(3922A, 3922K, 3922P)가 도시되어 있다. 예를 들어 하나 이상의 저장 노드에서 객체에 사용되는 물리적 페이지의 아이디, 객체의 소유자의 사용자 식별자 및/또는 그룹 식별자, 객체의 현재 크기, 마지막 수정 시간, 액세스 허가 또는 ACL(액세스 제어 리스트), 얼마나 많은 하드 링크가 객체를 가리키는지를 표시하는 링크 카운트 등을 포함하는, 초기에 "A.txt"라고 이름 붙여진 특정 파일 스토어 객체의 다양한 속성(3912)은 메타데이터 노드(3922A)에서 DFS-아이노드(DFS-Inode)(3910)라고 라벨이 붙은 DFS 노드 엔트리 구조에 저장될 수 있다. DFS-아이노드 구조(3910)는 많은 전통적 파일 시스템에서 구현된 아이노드 구조와 개념이 유사할 수 있으며, DFS-아이노드의 추가된 또는 수정된 특징의 소정 세트는 파일 저장 서비스의 분산형 본성으로부터 초래된다.
(이름변경 연산 작업흐름의 구현 이전에) 파일 스토어 객체의 이름 "A.txt"은, 묘사된 실시형태에서는 다른 메타데이터 노드(3922K)에서, 소위 DFS-디렉터리엔트리(DFS-DirectoryEntry)(3930)라는 다른 메타데이터 구조에 저장될 수 있다. DFS-디렉터리엔트리(3930)는 객체의 속성을 저장하는 DFS-아이노드(3910)로의 포인터 및 객체 이름에 대한 필드(3934)를 포함할 수 있다. 적어도 일부 실시형태에서, DFS-디렉터리엔트리(3930)는 또한 객체의 부모 디렉터리의 DFS-디렉터리엔트리를 가리키는 부모 디렉터리 포인터(DFS-부모디렉터리포인터(DFS-ParentDirPtr))(3952)를 포함할 수 있다. 그리하여, 예를 들어, "A.txt"가 디렉터리 "dir1"에 있으면, DFS-부모디렉터리포인터는 "dir1"의 DFS-디렉터리엔트리를 가리킬 수 있다. DFS-디렉터리엔트리 메타데이터 구조는 후속 논의에서는 단순히 디렉터리 엔트리라고 지칭될 수 있는 한편, DFS-아이노드 구조는 단순히 노드 엔트리라고 지칭될 수 있다.
소정 객체의 디렉터리 엔트리를 관리하도록 선택되는 특정 메타데이터 노드(3922A)는, 객체가 생성되는 때 객체의 이름을 해싱함으로써, 그 현재 가용 작업부하 용량 또는 공간 가용성에 기반하여 메타데이터 노드를 선택함으로써 등과 같이, 여러 다른 실시형태에서 여러 다른 기술을 사용하여 선택될 수 있다. 결과로서, 적어도 일부 경우에서는 다른 메타데이터 노드(3922P)가 "A.txt를 B.txt로 이름변경" 연산의 제2 피연산자("B.txt")에 대해 생성될 디렉터리 엔트리를 관리하도록 선택될 수 있다.
"B.txt"로 "A.txt"의 이름변경을 구현하는데 요구되는 변경은 라벨 "이름변경-전 상태(3945)" 및 "이름변경-후 상태(3947)"에 의해 도 39에 표시되어 있다. 이름변경 작업흐름을 구현하기 위해, DFS-아이노드(3910)를 가리키는 포인터 필드, 및 "B.txt"로 설정된 객체 이름 필드(3938)를 갖는 새로운 디렉터리 엔트리(3931)가 생성되어야 하고, 그리고 이름 필드 "A.txt"를 갖는 원래 디렉터리 엔트리(3930)가 제거되어야 한다. 노드 엔트리(3910) 자체는 적어도 일부 실시형태에서는 이름변경 동안 수정되지 않을 수 있다. 일관성을 위해, 도 39에 도시된 메타데이터 변경의 조합은 (관여된 양 메타데이터 노드에서) 모든 변경이 성공하든지 아니면 아무것도 성공하지 못하든지 하는 그러한 방식으로 수행되어야 할 수 있다. 일부 실시형태에서는, 앞서 설명된 바와 같이, 메타데이터 구조는 실제로는 서비스의 저장 서브시스템 노드의 물리적 저장 디바이스에서 구현된 익스텐트를 사용하여 저장될 수 있다. 후자의 시나리오에서는, 4개 유형의 개체가 이름변경 작업흐름에 관여될 수 있으며, 그 중 어느 하나라도 다른 것과 독립적으로 실패할 수 있거나, 또는 들어오는 또는 나가는 네트워크 패킷을 독립적으로 상실할 수 있다: 원래 디렉터리 엔트리("A.txt"의 디렉터리 엔트리)의 메타데이터 노드 및 저장 노드 그리고 새로운 디렉터리 엔트리("B.txt"의 디렉터리 엔트리)의 메타데이터 노드 및 저장 노드). 따라서, 참가자 노드 중 어느 것에서라도 가능한 실패 및/또는 통신 지연을 취하도록 설계된 이름변경 작업흐름이, 아래에서 설명되는 바와 같이 적어도 2개의 원자 연산 시퀀스를 사용하여, 구현될 수 있다. 시퀀스의 각각의 원자 연산은 메타데이터 노드 중 하나로 국한될 수 있고, 그래서 멀티-노드 원자 연산보다 구현하기가 더 용이할 수 있다. 관여된 각각의 메타데이터 노드(및/또는 저장 노드)는 멀티-테넌트 환경에서 저장 서비스의 수많은 클라이언트에 잠재적으로 속하는, 수많은 파일 스토어 객체에 대한 메타데이터를 관리하도록 구성될 수 있고, 그리고 결과로서 각각의 메타데이터 또는 저장 노드는 다수의 이름변경 요청 및 다른 파일 스토어 연산 요청을 병행 취급해야 할 수 있음을 주목한다.
모순 및/또는 메타데이터 변질을 방지하기 위해, 디렉터리 엔트리와 같은 메타데이터 구조는 일부 실시형태에서는 이름변경 작업흐름 동안 (예를 들어, 배타적 로크를 사용하여) 로킹될 수 있다. (예를 들어, 2개의 이름변경 요청 "A.txt를 B.txt로 이름변경" 및 "B.txt를 A.txt로 이름변경"이 매우 가까운 시간 근접하여 수신되면 잠재적으로 일어날 수 있는) 교착상태를 방지하기 위해, 적어도 일부 실시형태에서는 로크 순서화 프로토콜이 채용될 수 있다. 도 40은, 적어도 일부 실시형태에 따라, 병행 이름변경 연산에 대한 그러한 교착상태 회피 메커니즘의 사용을 예시한다. 교착상태 회피 분석기 모듈(4004)(예를 들어, 메타데이터 서브시스템의 서브컴포넌트)은 묘사된 실시형태에서는 이름변경 요청의 피연산자(4001)(예를 들어, "X를 Y로 이름변경" 요청의 피연산자 "X" 및 "Y")를 입력으로서 취하고 특정 로크 취득 순서를 발생시킬 수 있다.
묘사된 실시형태에서는 "X를 Y로 이름변경"에 대해 2개의 대안의 로크 취득 시퀀스(4010, 4012)가 도시되어 있으며, 그 중 정확히 하나가 교착상태 회피 분석기 모듈(4004)에 의해 출력으로서 발생될 수 있다. 취득 시퀀스(4010)에 의하면, X의 디렉터리 엔트리 상의 로크가 이름변경 작업흐름의 제1 원자 연산의 일부분으로서 획득되게 된다. 취득 시퀀스(4012)에 의하면, Y에 대한 디렉터리 엔트리가 이름변경 작업흐름의 제1 원자 연산에서 (필요하다면 디렉터리 엔트리를 생성한 후에) 획득되게 된다. 묘사된 실시형태에서는, 로크 시퀀스에 이르도록 교착상태 회피 모듈에 의해 이름 비교기(4008)가 사용될 수 있다. 2개의 피연산자는, 예를 들어, 사전식으로 비교될 수 있고, 그리고 적어도 일부 실시형태에서는 사전식 순서에서 처음에 있는 피연산자가 제1 원자 연산에서 로킹될 하나로서 선택될 수 있다. (다른 실시형태에서는, 사전식 순서에서 두 번째에 있는 피연산자가 우선 로킹될 수 있다; 순서화 로직이 여러 다른 이름변경 연산을 가로질러 일관되게 적용되는 한, 피연산자 중 어느 특정 하나가 우선 로킹되는지는 문제되지 않을 수 있다). 그리하여, 그러한 실시형태에서는, 이름변경 요청이 "X를 Y로 이름변경"이었는지 아니면 "Y를 X로 이름변경"이었는지에 무관하게 동일한 디렉터리 엔트리가 우선 로킹될 수 있다. 이러한 방식으로, 2개의 요청 "X를 Y로 이름변경" 및 "Y를 X로 이름변경"이 준-병행 수신되더라도, 제1 요청에 대해 X가 로킹되고 제2 요청에 대해 Y가 로킹되는 것이 가능하지 않을 것이므로, 교착상태는 회피될 수 있다. 일부 실시형태에서는, 사전식 비교와는 다른 기술이 이름변경 피연산자 간 로크 순서를 결정하도록 사용될 수 있다. 다수의 객체(예를 들어, 다수의 파일 또는 디렉터리)는 소정 파일 스토어 내에서 동일한 이름을 가질 수 있는 한편, DFS-아이노드에 배정된 식별자는 전형적으로는 파일 스토어 내에서 고유할 것으로 예상될 수 있으므로, 적어도 일부 실시형태에서 비교기로의 입력으로서 사용되는 "이름"은 객체와 연관된 선택된 DFS-아이노드(예를 들어, 객체의 부모 DFS-아이노드)의 식별자를 객체의 이름과 연접 아니면 조합함으로써 획득될 수 있다. 다른 실시형태에서는 다른 모호성해소 기술이 파일 이름(또는 디렉터리 이름) 재-사용의 잠재적-문제를 극복하도록 사용될 수 있다 - 예를 들어, 일 실시형태에서는 파일 스토어의 루트로부터 객체로까지의 전체 경로가 로크 시퀀스 결정을 위한 "이름"으로서 사용될 수 있거나, 또는 경로의 디렉터리 중 수 개와 연관된 DFS-아이노드 식별자가 객체 이름과 조합될 수 있다.
적어도 일부 실시형태에서는, 교착상태 회피 분석의 출력에 기반하여, 2개의 다른 이름변경 작업흐름 중 하나가 소정 이름변경 요청에 대해 구현될 수 있다. 2개의 작업흐름은 어느 디렉터리 엔트리가 우선 로킹되는지에 있어서 다를 수 있다. 이름변경 작업흐름의 각각은 적어도 3개의 단계를 포함하는 것으로 생각될 수 있다: (작업흐름의 "제1 원자 연산"이라고 총칭될 수 있는) 원자성으로 수행되는 제1 연산 세트, ("제2 원자 연산"이라고 총칭될 수 있는) 원자성으로 수행되는 제2 연산 세트, 및 원자성이 구현-종속적일 수 있는 제3 연산 세트. 부가적 (전형적으로는 비동기식) 단계가 또한 아래에서 설명되는 바와 같이 일부 경우에 포함될 수 있다. 도 41은, 적어도 일부 실시형태에 따라, 이름변경 연산에 대해 저장 서비스에서 결정될 수 있는, 2개의 가능한 로크 순서화 중, 제1 로크 순서화에 기반하여 제1 이름변경 작업흐름을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(4101)에서 제시된 바와 같이, 현재 이름이 "A"인, 파일 또는 디렉터리와 같은, 특정 파일 스토어 객체를 "B"로 이름변경하라는 요청은, 예를 들어, 분산형 저장 서비스의 메타데이터 서브시스템에서 수신될 수 있다. 예를 들어, 액세스 서브시스템 노드는 고객으로부터 이름변경 커맨드를 수신하고, 대응하는 내부 이름변경 요청을 선택된 메타데이터 노드에 송신할 수 있다. 서비스의 저장 서브시스템이 메타데이터에도 그리고 데이터에도 사용되는 실시형태에서, 메타데이터 노드는 예를 들어 저장 노드와 동일한 하드웨어 서버에서 병설된 프로세스 또는 스레드를 포함할 수 있다. "A"에 대한 디렉터리 엔트리는 현재, 소유권 식별, 판독/기록 허가 등과 같은, 객체의 다양한 속성의 값을 포함하는 노드 엔트리(DI1)를 가리킬 수 있다. "B"에 대한 디렉터리 엔트리는 아직 존재하지 않을 수 있다.
이름변경 작업흐름의 일부분으로서 "A"의 디렉터리 엔트리 상의 로크가 우선 취득되어야 하는지, 또는 (우선 생성되어야 할 수 있는) "B"에 대한 디렉터리 엔트리 상의 로크가 우선 취득되어야 하는지 결정이, 예를 들어, 교착상태 회피 분석에 기반하여 이루어질 수 있다(요소(4104)). B의 디렉터리 엔트리가 우선 로킹되어야 하면(요소(4107)), 도 41에서의 라벨 "4201로 간다"에 의해 표시된 바와 같이, 도 42에 예시된 작업흐름 단계가 사용될 수 있다. (요소(4107)에서 또한 결정되는 바와 같이) "A"의 엔트리가 우선 로킹되어야 하면, 이름변경 작업흐름의 제1 원자 연산이 저장 서비스의 특정 메타데이터 노드(MN1)에서 시도될 수 있다(요소(4110)). 제1 원자 연산은 묘사된 실시형태에서 다음의 단계를 포함할 수 있다: (a) "A"의 디렉터리 엔트리 상의 로크(L1)를 획득하는 단계, (b) 시도되고 있는 작업흐름에 대한 고유 이름변경 작업흐름 식별자(WFID1)를 발생시키는 단계, 및 (c) 현재 A라고 이름 붙여진 객체가 B로 이름변경되어야 함을 표시하는 의도 레코드(IR1)를 저장하는 단계. 적어도 일부 구현에서 의도 레코드는 작업흐름 식별자(WFID1)를 표시 또는 포함할 수 있다. 일 구현에서는, (예를 들어, 도 12에 예시된 복제 상태 머신과 유사한) 저장 서비스의 상태 관리 서브컴포넌트가 3개의 단계를 하나의 원자 연산으로 조합하도록 사용될 수 있다. 제1 원자 연산의 3개의 단계가 서로에 비해 수행되는 순서는 다른 구현에서 달라질 수 있다. 일부 실시형태에서, 로크(L1), 의도 레코드(IR1) 및/또는 작업흐름 식별자(WFID1)의 각각의 표현은 각각, 예를 들어 앞서 설명된 바와 같은 저장 서브시스템의 익스텐트 복제본을 사용하여, 영속적 저장 디바이스 상에 복제될 수 있다. 적어도 하나의 실시형태에서, 로크, 의도 레코드 및/또는 작업흐름 식별자를 저장하도록 선택된 영속적 저장 장소는 MN1의 장애의 경우에 대체 메타데이터 노드로부터 액세스가능할 수 있다. 로크(L1)가 유지되고 있는 한, 묘사된 실시형태에서는 다른 수정이 "A"의 디렉터리 엔트리에 적용되지 않을 수 있다. 제1 원자 연산이 시도될 때, 예를 들어 어떤 다른 병행 또는 준-병행 수정 연산을 대리하여, 로크가 이미 유지되고 있으면, 제1 원자 연산은 로크가 이용가능하게 될 때까지 지연될 수 있다.
요소(4113)에서 결정되는 바와 같이, 초기 원자 연산이 성공하면, 이름변경 작업흐름의 제2 원자 연산이 시도될 수 있다. 도 41 및 도 42에 예시된 작업흐름의 원자 연산의 각각에 대해, 적어도 일부 실시형태에서는 연산이 제1 시도시 완료될 수 없는 경우 원자 연산은 (예를 들어, 소정 구성가능한 최대 재시도 카운트에 기반하여) 1회 이상 재-시도될 수 있음을 주목한다. 제2 원자 연산은 "B"에 대한 디렉터리 엔트리를 관리 및/또는 저장하도록 지정되는 메타데이터 노드(MN2)에서 수행될 수 있다. 일부 실시형태에서는, 제1 원자 연산이 MN1에서 완료된 후에, 제2 원자 연산을 수행하라는 요청이 MN1으로부터 MN2로 보내질 수 있다. 요청은 적어도 일부 구현에서는 작업흐름 식별자(WFID1)를 포함할 수 있다. 요소(4116)에서 제시된 바와 같이, 제2 원자 연산은 다음의 단계를 포함할 수 있다: (a) "B"의 디렉터리 엔트리가 어떤 다른 수정 연산을 대리하여 현재 로킹되어 있지 않음을 검증하는 단계, (b) 이름변경되는 객체에 대한 노드 엔트리(DI1)를 가리키도록 B의 디렉터리 엔트리를 설정하는 단계, 및 (c) 식별자(WFID1)를 갖는 작업흐름에 대해, "B"의 디렉터리 엔트리의 포인터 수정 단계가 성공하였음을 표시하는 레코드를 저장하는 단계. 적어도 일부 경우에, "B"의 디렉터리 엔트리는 제2 원자 연산이 시도되는 때 존재하지 않을 수 있으며, 그 경우 그것이 로킹되어 있지 않음을 검증하는 단계는 "B"에 대한 새로운 디렉터리 엔트리를 생성함으로써 묵시적으로 구현될 수 있다. 적어도 일부 실시형태에서, 로크는, 예를 들어 "B"의 디렉터리 엔트리의 어느 병행 수정이라도 방지하기 위해, 포인터가 수정되기 전에 B의 디렉터리 엔트리 상에 취득될 수 있다. 로크는 일부 그러한 실시형태에서 DI1으로의 포인터가 설정된 후에 해제될 수 있다. 제1 원자 연산의 일부분으로서 수행되는 기록의 경우에서와 같이, 제2 원자 연산의 기록(예를 들어, 포인터의 설정 및 성공 표시)은 그것들이 MN2에서의 실패의 경우에 추후 판독될 수 있는 복제 익스텐트와 같은 영속적 저장 장소에서 수행될 수 있다. 저장 서비스의 상태 관리 서브컴포넌트는 기록의 조합의 원자성을 시행하도록 사용될 수 있다.
(요소(4119)에서 결정되는 바와 같이) 제2 원자 연산이 성공하면, 제3 연산 세트가 시도될 수 있다(요소(4122)). 제1 원자 연산처럼, 이러한 제3 연산 세트도 MN1에서 실행될 수 있다. 적어도 일부 실시형태에서, 제2 원자 연산이 성공하였다는 MN1에서 수신된 표시(예를 들어, 제2 원자 연산에 대해 MN1으로부터 MN2로 보내진 요청에 대한 응답)는 제3 연산 세트를 트리거링할 수 있다. 제3 연산 세트에서는, "A"의 디렉터리 엔트리 상에 취득된 로크(L1)가 삭제될 수 있고, 의도 레코드(IR1)가 삭제될 수 있고, 그리고 "A"의 디렉터리 엔트리 자체가 삭제될 수 있다. 앞서 언급된 바와 같이, 일부 구현에서, 이러한 제3 연산 세트도 원자 단위로서 수행될 수 있고, 그리고 그러한 경우에 제3 세트의 연산은 작업흐름의 "제3 원자 연산"이라고 지칭될 수 있다. 다른 구현에서, 원자성은 제3 연산 세트에 대해 시행되지 않을 수 있다. 제1 원자 연산 동안 발생된 메타데이터(예를 들어, 의도 레코드, 작업흐름 식별자 및 로크의 표시)가 영속적 저장소에 저장되는 실시형태에서는, 제3 세트가 원자성으로 수행되는지 여부와 무관하게, 다양한 종류의 장애에 기인하여 하나 이상의 재시도가 요구되더라도, 제3 연산 세트가 결국 성공할 것으로 예상될 수 있다. (요소(4125)에서 검출되는 바와 같이) 제3 연산 세트가 역시 성공하면, 이름변경 작업흐름은 전체로서 성공하였다고 여겨질 수 있다(요소(4128)). 적어도 일부 실시형태에서는, 이름변경이 성공하였음을 표시하는, 이름변경 요청에 대한 응답이 보내질 수 있다. 일부 실시형태에서는, 요청자에 응답이 보내지지 않을 수 있다.
묘사된 실시형태에서, 2개의 원자 연산 중 어느 것도 성공하지 못했으면, 작업흐름은 전체로서 중단될 수 있고(요소(4131)), 그리고 (의도 레코드(IR1), 로크(L1)의 취득의 표현 및/또는 MN2에서 저장된 성공 레코드와 같은) 작업흐름의 앞선 부분에서 발생된 레코드 중 어느 것이라도 삭제될 수 있다. (요소(4125)에서 검출되는 바와 같이) 제3 연산 세트 중 어느 연산이라도 실패하면, 그것은 다시 요소(4122)에 이르는 화살표에 의해 표시된 바와 같이 묘사된 실시형태에서는 단순히 재시도될 수 있다. 앞서 언급된 바와 같이, 적어도 일부 실시형태에서는 실패를 선언하기 전에 원자 연산의 각각에 대해 다수의 시도가 시도될 수 있다. 일부 실시형태에서, 식별자(WFID1)를 갖는 작업흐름의 제3 연산 세트가 완료된 후의 소정 시점에서, MN2에서 저장된 성공 레코드는, 예를 들어 제3 연산 세트의 완료에 대해 비동기식으로, 삭제될 수 있다(요소(4134)).
도 41의 요소(4107)의 부정적 출력에서 표시된 바와 같이, "B"에 대한 디렉터리 엔트리가 우선 로킹되어야 하면 다른 이름변경 작업흐름이 시도될 수 있다. 도 42는, 적어도 일부 실시형태에 따라, 이름변경 연산에 대해 저장 서비스에서 결정될 수 있는, 2개의 가능한 로크 순서화 중, 그러한 제2 로크 순서화에 기반하여 제2 이름변경 작업흐름을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 이러한 제2 작업흐름도 묘사된 실시형태에서는 "A"를 "B"로 이름변경하는데 사용될 2개의 연속하는 원자 연산을 포함할 수 있으며, 구현에 종속하여 원자성으로 구현될 수도 있고 그렇지 않을 수도 있는 제3 연산 세트가 뒤따른다. 메타데이터 노드(MN2)(객체 이름 "B"에 대한 디렉터리 엔트리를 저장하는 것을 책임지고 있는 노드)에서 수행되는 제1 원자 연산(도 42의 요소(4201))은 "B"의 디렉터리 엔트리가 어떤 다른 연산에 대해 로킹되어 있지 않음을 검증하는 것, 필요하다면 "B"의 디렉터리 엔트리를 생성하는 것, "B"의 디렉터리 엔트리를 로킹하는 것, 이름변경 작업흐름에 대한 고유 작업흐름 식별자(WFID2)를 발생 및 저장하는 것, 및 현재 "A"라고 이름 붙여진 객체가 "B"로 이름변경될 것임을 표시하는 의도 레코드(IR2)를 저장하는 것을 포함할 수 있다. 적어도 일부 구현에서 의도 레코드(IR2)는 작업흐름 식별자(WFID2)를 표시 또는 포함할 수 있다.
(요소(4204)에서 검출되는 바와 같이) 제1 원자 연산이 성공하면, 작업흐름(WFID2)의 제2 원자 연산이 시도될 수 있다(요소(4207)). 이러한 제2 원자 연산은 "A"의 디렉터리 엔트리가 관리되는 메타데이터 노드(MN1)에서 수행될 수 있고, 일부 실시형태에서는 제1 원자 연산이 성공하였음을 표시하는 MN2로부터의 요청에 의해 트리거링될 수 있다. 제2 원자 연산은 A의 디렉터리 엔트리가 로킹되어 있지 않음을 검증하는 것, "A"의 디렉터리 엔트리를 삭제하는 것, 및 작업흐름(WFID2)의 일부분으로서 "A"의 디렉터리 엔트리가 성공적으로 삭제되었다는 영속적 레코드를 저장하는 것을 포함할 수 있다. (요소(4210)에서 결정되는 바와 같이) 제2 원자 연산이 성공하면, 제3 연산 세트가 MN2에서 시도될 수 있다(요소(4213)). 일부 실시형태에서, 제2 원자 연산이 성공하였다는 표시, 예를 들어, 제2 원자 연산에 대해 앞서 MN2로부터 MN1으로 보내진 요청에 대해 MN2에서 수신된 응답은 제3 연산 세트를 수행하려는 시도를 트리거링할 수 있다. 제3 연산 세트는 DI1(이름변경되는 객체에 대한 노드 엔트리)을 가리키도록 "B"의 디렉터리 엔트리를 설정하는 것, 로크(L2)를 해제/삭제하는 것, 및 의도 레코드(IR2)를 삭제하는 것을 포함할 수 있다.
(요소(4216)에서 검출되는 바와 같이) 제3 연산 세트가 성공하면, 작업흐름은 전체로서 성공하였다고 여겨질 수 있고(요소(4219)), 그리고 일부 실시형태에서는 성공 표시자가 이름변경 연산의 요청자에 반환될 수 있다. 도 41에 예시된 작업흐름에서와 같이, 요소(4216)로부터 다시 요소(4213)에 이르는 화살표에 의해 표시된 바와 같이 장애 시나리오에서 하나 이상의 재시도가 요구될 수 있기는 하지만, 도 42의 제3 연산 세트는 결국 성공할 것으로 예상될 수 있다. 제3 연산 세트의 완료에 대해 비동기식으로, ("A"의 디렉터리 엔트리가 삭제되었음을 표시하는) MN1에 의해 저장된 성공 레코드는 적어도 일부 실시형태에서는 자체가 삭제될 수 있다(요소(4225)). 2개의 원자 연산 중 어느 것이든 실패하면, 이름변경 작업흐름은 전체로서 중단될 수 있고(요소(4222)), 그리고 중단된 작업흐름의 앞선 연산 동안 저장된 레코드는 클린업될 수 있다. 도 41에 예시된 연산에서와 같이, 저장 서비스의 상태 관리 메커니즘 및/또는 복제 익스텐트는 제2 작업흐름의 원자 연산에 사용될 수 있다.
도 41 및 도 42에 예시된 연산 및 교착상태-회피 로크 순서화 시퀀스를 사용하여, 파일 스토어 객체에 대한 이름변경 연산은 사용되는 파일 시스템 프로토콜에 의해 예상된 소망의 일관성 레벨을 달성하도록 구현될 수 있다. 고유 작업흐름 식별자와 연관된 의도 레코드를 영속적 저장소에 저장하는 기술은 여러 다른 실시형태에서 다양한 유형의 장애로부터의 복구에 유용할 수 있다. 도 43은, 적어도 일부 실시형태에 따라, 이름변경 작업흐름에 참가하는 한 쌍의 메타데이터 서브시스템 노드 중 하나의 메타데이터 서브시스템 노드의 장애에 응답하여 수행될 수 있는 복구 연산의 태양을 예시하는 순서도인 한편, 도 44는, 적어도 일부 실시형태에 따라, 이름변경 작업흐름에 참가하는 그 쌍의 메타데이터 서브시스템 노드 중 다른 하나의 메타데이터 서브시스템 노드의 장애에 응답하여 수행될 수 있는 복구 연산의 태양을 예시하는 순서도이다. 제시를 단순화하기 위해, 도 43 및 도 44는 도 41에 예시된 작업흐름 시퀀스 동안 단일 메타데이터 노드 실패가 일어나면 수행될 수 있는 연산을 각각 예시하기는 하지만, 적어도 일부 실시형태에서는 작업흐름에 관여된 메타데이터 노드 양자가 실패하더라도 유사한 복구 전략이 채용될 수 있다.
도 43의 요소(4301)에서 제시된 바와 같이, 노드(MN1)의 실패는 도 41의 작업흐름 시퀀스의 제1 원자 연산(그 단계는 요소(4110)에 예시되었음)이 완료된 후에 그리고 도 41의 작업흐름 시퀀스의 제3 연산 세트(요소(4122))가 시작되기 전에 소정 시점에서 검출될 수 있다. 예를 들어, "A"의 디렉터리 엔트리가 관리되는 메타데이터 노드(MN1)를 구현하는 프로세스 또는 스레드는 조기에 존재할 수 있거나, 또는 MN1은 처짐을 초래하는 소프트웨어 버그에 기인하여 또는 네트워크-관련 장애에 기인하여 건전 점검에 응답하지 않게 될 수 있다. 그러한 상황 하에서, 대체 메타데이터 노드(MN-R)는 묘사된 실시형태에서 MN1의 책임을 인수하도록 지정 또는 구성될 수 있다(요소(4304)). 일부 실시형태에서, 앞서 언급된 바와 같이, MN1은 복수의 메타데이터 노드를 포함하는 중복 그룹의 멤버로서 구성되었을 수 있고, 페일오버를 위해 예비 구성된 중복 그룹의 다른 멤버가 대체로서 신속히 지정될 수 있다. 다른 실시형태에서, 대체 메타데이터 노드(MN-R)는 예비 구성된 중복 그룹의 일부분이 아닐 수 있다.
도 41의 작업흐름의 제1 원자 연산에서, MN-1은 영속적 저장소에 의도 레코드(IR1) 및 작업흐름 식별자(WFID1)를, 로크(L1)의 표현과 함께, 저장하였다. 대체 메타데이터 노드(MN-R)는 MN-1의 실패 이전에 기록되었던 의도 레코드(IR1) 및 작업흐름 식별자(WFID1)를 판독할 수 있다(요소(4307)). 그 후 MN-R은 묘사된 실시형태에서는 작업흐름(WFID1)의 상태를 결정하기 위해 - 예를 들어, 작업흐름의 제2 원자 연산의 일부분으로서 B의 디렉터리 엔트리 포인터가 DI1(이름변경되는 객체의 노드 엔트리)을 가리키도록 이미 설정되었는지 알아내기 위해, 질의를 MN2, "B"의 디렉터리 엔트리를 책임지고 있는 메타데이터 노드에 보낼 수 있다(요소(4310)).
앞서 언급된 바와 같이, 각각의 메타데이터 노드는 분산형 저장 서비스가 멀티-테넌트인 실시형태에서 수 개의 다른 파일에 대한 그리고/또는 수 개의 다른 클라이언트에 대한 메타데이터를 관리하는 것을 책임지고 있을 수 있다. 그 결과 MN2는 수많은 이름변경 작업흐름의 제2 원자 연산에 대응하는 각각의 성공 레코드를 저장하였을 수 있다. 식별자(WFID1)를 갖는 작업흐름의 상태에 관한 질의를 수신시, MN2는 성공적 원자 연산의 그 레코드를 룩업할 수 있다. (요소(4313)에서 결정되는 바와 같이) WFID1의 제2 원자 연산에 대한 성공 레코드를 MN2가 발견하면, 그것은 제2 원자 연산이 완료되었음(즉, "B"의 디렉터리 엔트리가 노드 엔트리(DI1)를 가리키도록 설정되었음)을 MN-R에 알려줄 수 있다. 따라서, 묘사된 실시형태에서, 그 후 MN-R은 WFID1에 의해 식별된 이름변경 작업흐름을 완료하려는 노력으로 제3 연산 세트를 시도할 수 있다(요소(4316)).
적어도 일부 시나리오에서는, 작업흐름(WFID1)의 제2 원자 연산이 성공하지 못하는 것이 사실일 수 있다. 예를 들어, MN1은 제2 원자 연산을 시작하라는 MN2로의 그 요청이 성공적으로 송신되기 전에 실패하였을 수 있거나, 또는 요청이 상실되었을 수 있거나, 또는 MN2는 요청된 제2 원자 연산을 성공적으로 구현할 수 없었을 수 있다. 일부 실시형태에서, (요소(4313)에서 또한 결정되는 바와 같이) 제2 원자 연산이 성공하지 못했다는 알림을 MN-R이 받으면, MN-R은 작업흐름을 포기하든지 재개하든지 하는 옵션을 가질 수 있다. 묘사된 실시형태에서, (요소(4319)에서 검출되는 바와 같이) 취소 기준이 만족되면, 이름변경 작업흐름은 중단될 수 있고 그리고 MN1에 의해 저장되었던 WFID1과 연관된 메타데이터 레코드는 제거될 수 있다(예를 들어, 의도 레코드(IR1) 및 로크(L1)의 표현은 영속적 저장소로부터 삭제될 수 있다)(요소(4322)). 일 실시형태에서는, 원래 이름변경 요청이 클라이언트로부터 수신된 이후로 경과한 시간이 소정 구성된 임계치를 초과하면 취소 기준이 만족될 수 있다. 이름변경 작업흐름의 경과된-시간-종속적 종결은, 예를 들어, 긴 경과된 시간에 비추어, 이름변경을 요청한 클라이언트가 원래 요청이 성공하지 못했음을 깨달았을 것이고 그래서 이름변경이 이 시점에서 성공할 것으로 예상하고 있지 않았을 것이라는 가정 하에 구현될 수 있다. 일부 실시형태에서, 식별자(WFID1)를 갖는 작업흐름이 중단/취소되었음을 표시하는 취소 레코드는, 예를 들어, MN-R에서든, MN2에서든, MN-R과 MN2 양자에서든 소정 구성가능한 시간 기간 동안 저장될 수 있다. 하나의 그러한 실시형태에서, 작업흐름이 포기되어야 한다고 결정한 후에, MN-R은 우선 취소 레코드를 저장하라는 요청을 MN2에 보낼 수 있고, MN2가 영속적 저장소에 취소 레코드를 성공적으로 저장하였다는 알림을 그것이 받은 후에 의도 레코드 및 로크 양자를 삭제할 수 있다.
그렇지만, (요소(4319)에서 또한 검출되는 바와 같이) 취소 기준이 만족되지 않으면, 묘사된 실시형태에서 MN-R은 제2 원자 연산을 구현하라는 요청을 MN2에 보냄으로써 작업흐름을 재개할 수 있다(요소(4325)). MN1 실패에 응답하기 위한 다른 전략이 다양한 실시형태에서 구현될 수 있다 - 예를 들어, 일부 실시형태에서 이름변경 작업흐름은 초기 이름변경 요청이 수신된 이후로 경과한 시간에 무관하게 항상 재개될 수 있고, 그리고 적어도 하나의 실시형태에서 이름변경 작업흐름은 제1 원자 연산의 완료 후 MN1의 실패의 경우에 항상 포기될 수 있다.
도 44는, 적어도 일부 실시형태에 따라, 도 41에 예시된 작업흐름 시퀀스 동안 메타데이터 노드(MN2)가 실패하면 수행될 수 있는 연산을 예시한다. 요소(4401)에서 제시된 바와 같이, 예를 들어 작업흐름의 제2 원자 연산(요소(4116))을 구현하라는 요청이 MN2에 보내진 후에, MN2의 실패가 검출될 수 있다. 위에서 MN-R로 MN1을 대체하도록 논의된 것과 유사한 방식으로, 묘사된 실시형태에서는 MN-R에 대해 대체 메타데이터 노드(MN-R2)가 지정 또는 구성될 수 있다(요소(4404)). MN-R2는 MN2에 의해 그 실패 이전에 영속적 저장소에 기록된 성공 레코드를 판독할 수 있을 수 있다.
MN-R2에서, 식별자(WFID1)를 갖는 작업흐름의 제2 원자 연산이 성공적으로 완료되었는지 MN1이 결정 가능하게 하도록 MN1으로부터의 질의가 수신될 수 있다(요소(4407)). (요소(4410)에서 검출되는 바와 같이) 제2 원자 연산이 MN2의 실패 이전에 완료되었으면, MN-R2는 WFID1에 대한 성공 레코드를 발견할 수 있을 수 있고, 따라서 MN1에 응답할 수 있다. 그 후 MN1은 제3 연산 세트를 시도함으로써 작업흐름을 재개할 수 있다(요소(4413)).
WFID1의 제2 원자 연산이 완료되지 않았으면, 도 43에서 구현되었던 것과 유사한 프로시저가 도 44에 묘사된 실시형태에서 구현될 수 있다. (요소(4416)에서 검출되는 바와 같이) 이름변경 연산에 대한 취소 기준이 만족되면 - 예를 들어, 이름변경이 요청된 이후로 경과된 시간이 소정 임계 시간(T)을 초과하면 - 이름변경 연산은 중단될 수 있고 그리고 WFID1와 관련된 데이터 구조는 클린업될 수 있다(요소(4419)). 그와 달리, 취소 기준이 만족되지 않았으면, 작업흐름은 제2 원자 연산을 수행하라는 요청을 MN-R2에 보냄으로써 MN1에 의해 재개될 수 있다(요소(4422)).
도 43 및 도 44는 도 41의 작업흐름 동안 어느 메타데이터 노드에서든 실패에 응답하는 복구 기술을 예시하고 있지만, 적어도 일부 실시형태에서는 또한 유사한 기술이 도 42에 예시된 작업흐름 동안 어느 메타데이터 노드든 실패하면 구현될 수 있다. 실패된 메타데이터 노드에 대해 구성된 대체 노드가 영속적 저장소로부터 작업흐름 레코드(예를 들어, 의도 레코드, 로크 및/또는 성공 레코드)를 판독할 수 있는 한, 실패 후에 작업흐름을 재개하는 것이 가능할 수 있다. 예를 들어, 도 42의 작업흐름에서, 제1 원자 연산 후에 MN2가 실패하고 대체 MNR-2가 지정되면, MNR2는 의도 레코드(IR2) 및 작업흐름 식별자(WFID2)를 판독하고 MN1에 관한 상태 질의를 보낼 수 있고, 등이다. 도 43 및 도 44에 도시된 것과 유사한 방식으로, 실패를 검출하고 대체 노드를 구성하는데 얼마나 오래 걸리는지 및 이름변경 작업흐름이 실패 이전에 얼마나 많이 진행하였는지에 종속하여, 일부 경우에서 도 42의 이름변경 작업흐름은 메타데이터 노드 실패 후에 포기될 수 있다. 데이터에 대해 사용되는 바와 같이 동일한 기저 저장 서브시스템을 사용하여 메타데이터가 저장되는 실시형태에서는, 도 43 및 도 44에 예시된 것들과 유사한 복구 기술이 저장 노드 장애에 응답하도록 역시 사용될 수 있다. 일부 실시형태에서, 저장 노드 및 메타데이터 노드의 기능성은 동일한 호스트 또는 하드웨어 서버에서 수행될 수 있고, 그리고 결과로서 그 호스트 또는 서버의 장애는 양 유형의 노드에 영향을 미칠 수 있다.
확장가능한
이름공간 관리
분산형 저장 서비스의 목표는 다양한 실시형태에서 확장가능한 방식으로 매우 많은 수의 파일, 디렉터리, 링크 및/또는 다른 객체를 취급하는 것을 포함할 수 있다. 예를 들어, 일부 대규모 고객에 대해, 소정 파일 시스템은 백만 이상의 디렉터리를 포함할 수 있고, 그리고 소정 디렉터리는 백만 이상의 파일을 포함할 수 있다. 일부 실시형태에서는, 이름공간에서의 객체의 수가 그러한 레벨로 증가함에 따라 응답 시간이 디렉터리 리스팅, 룩업, 삽입 및 삭제와 같은 다양한 이름공간 연산에 대해 높은 병행에서 비교적 평탄한 채로 있음을 보장하기 위해 그리고/또는 높은 처리율을 지원하기 위해, 소위 해시-방향성 비사이클 그래프(HDAG)라는 데이터 구조가 이름공간 엔트리를 관리하는데 사용될 수 있다. 용어 이름공간은 여기에서는 소정 파일 시스템 또는 다른 데이터 스토어 논리적 컨테이너 내에서 생성된 객체(파일, 디렉터리, 하드 및 소프트 링크 등)의 이름의 집합을 그리고 객체들 간 관계(예를 들어, 부모-자식 관계)를 지칭하도록 사용된다. 일부 실시형태에서, 각각의 HDAG는, 예를 들어 서비스의 메타데이터 서브시스템에 의해, 파일 시스템의 각각의 디렉터리에 대해 발생될 수 있다. 아래에서 설명되는 HDAG-기반 이름공간 관리 기술은, 단일 원자 연산으로 복수의 저장 디바이스에서의 수정을 수행할 수 있는 능력 및 다수의 저장 익스텐트를 가로지르는 구성가능한 세밀도에서의 메타데이터 구조의 스트라이핑과 같은, 앞서 설명된 분산형 저장 서비스의 특징 중 일부를 이용할 수 있다. 예를 들어, 일 구현에서는 (각각의 익스텐트의 하나 이상의 페이지에 매핑될 수 있는) 각각의 논리적 블록이 특정 HDAG의 각각의 노드에 대해 사용될 수 있고, 그리하여 복수의 저장 서버 간 이름공간 엔트리를 잠재적으로 파티셔닝한다.
도 45는, 적어도 일부 실시형태에 따라, 파일 스토어 이름공간 관리에 사용될 수 있는 해시-방향성 비사이클 그래프(HDAG)의 일례를 예시한다. 디렉터리에 대한 HDAG는 묘사된 실시형태에서는 적어도 2개 유형의 노드를 포함할 수 있다: 엔트리 리스트(EL) 노드(그 각각은, 대응하는 객체에 대한 다른 속성 값을 포함하고 있는 각각의 DFS-아이노드로의 포인터를 갖는, 도 39에 도시된 DFS-디렉터리엔트리 구조와 유사한 디렉터리 엔트리의 리스트를 포함함), 및 노드 식별자 어레이(NI어레이(NIArray)) 노드(그 각각은 자식 노드 세트로의 포인터 어레이를 포함함). 노드의 유형은, 헤더 필드(4504A 또는 4520A)와 같은, 헤더 필드에 표시될 수 있다. 디렉터리(D1)가 생성될 때, (HDAG의 루트 노드라고 지칭되는, 노드(4500A)와 같은) 단일 EL 노드를 포함하는, 초기 상태(4590A)에서의 HDAG가 디렉터리에 대해 생성될 수 있다. 일부 구현에서, 디렉터리에 대한 DFS-아이노드는 자체가 HDAG의 루트 노드로서 사용될 수 있다. 루트 노드(4500A)는 소정 세트의 디렉터리 속성(4502A), 루트 노드의 유형(초기에는 EL)을 표시하는 헤더 필드(4520R), 및 D1 내에서 생성된 제1 적은 수의 파일 또는 서브디렉터리에 대한 루트 엔트리 리스트(4506)를 수용하기에 충분한 공간을 포함할 수 있다. 소정 EL 노드는 소정 구성가능한 수(예를 들어, 소정 파일 스토어의 모든 EL 엔트리에 대해 선택될 수 있는 값)까지의 이름공간 엔트리를 저장할 수 있고, 그리고 소정 NI어레이 노드는 소정 구성가능한 수까지의 노드 식별자(예를 들어, 소정 파일 스토어의 모든 NI어레이 엔트리에 대해 선택되는 다른 값)를 저장할 수 있다. 적어도 일부 실시형태에서, HDAG 노드의 최대 허용가능한 크기는 하나의 HDAG 노드의 콘텐츠가 단일 원자 연산으로 저장소에 기록될 수 있게 되도록 결정될 수 있다 - 예를 들어, 일 구현에서, HDAG 노드가 절대로 4 킬로바이트보다 많이 점유하지 않게 되도록 HDAG 파라미터가 선택되면, 4 킬로바이트 페이지를 지원하는 익스텐트가 HDAG에 사용될 수 있고, 그리고/또는 4 킬로바이트의 논리적 블록 크기가 사용될 수 있다. 다른 구현에서는 HDAG, 논리적 블록 크기, 및 페이지 크기 간 다른 매핑이 사용될 수 있다.
(화살표(4525)에 의해 표시된 바와 같이) D1 내에서 더 많은 파일 또는 서브디렉터리가 추가됨에 따라, 루트 엔트리 리스트(4506)는 결국 가득 차게 될 수 있고, 그리고 루트 노드(4500A)는 그 엔트리 리스트 멤버를 자식 노드로 분산시키도록 해시 함수를 사용하여 소정 수의 자식 노드로 분할될 수 있다. 루트 노드의 유형은 EL로부터 NI어레이로 변경될 수 있고, 그리고 자식 노드로의 포인터(예를 들어, 자식 노드가 저장되는 논리적 또는 물리적 저장소 주소)는 루트 노드에서 NI어레이에서의 각각의 요소에 기록될 수 있다. 선택된 강력한 해시 함수는 소망 크기의 해시 값을 산출하도록 엔트리 이름(예를 들어, 파일 이름 또는 서브디렉터리 이름)의 각각에 적용될 수 있고, 소정 엔트리에 대한 해시 값의 비트-시퀀스 표현의 부분들은 엔트리를 새로운 자식 노드에 매핑하는데 사용될 수 있다. (아래에서 상세히 설명되는) 수 개 유형의 분할된 연산은 비-루트 노드 상에서 그것들이 가득 채워짐에 따라, 새롭게-생성된 자식 노드들 간 엔트리의 유사한 해시-기반 분산을 사용하여, 다양한 실시형태에서 구현될 수 있다. 룩업 요청에 응답하여, 동일한 해시 함수는 또한, 예를 들어 표적 엔트리를 갖는 노드가 발견될 때까지 각각의 HDAG 레벨을 항행하도록 인덱스로서 해시 값의 비트 시퀀스 표현의 연속하는 서브시퀀스를 사용하여, 특정된 객체 이름에 대한 엔트리를 찾도록 사용될 수 있다. 디렉터리 리스팅을 획득하기 위해, (루트 노드가 분할되었다고 가정하면) 루트 노드의 NI어레이로부터 시작하는 모든 포인터를 전체 HDAG가 순회되었고 모든 그 엔트리가 검색되었을 때까지 재귀적으로 뒤따를 수 있다. 다양한 유형의 HDAG 연산에 관한 추가적 상세가 아래에서 제공된다.
엔트리 리스트 노드의 유형은 일부 조건 하에 하나 이상의 유형의 HDAG 연산의 결과로서 변경될 수 있다 - 예를 들어, 루트 노드(4500A)는 그 엔트리가 자식 노드들 간 분산된 후에 NI어레이 노드가 되었다(그리고 아래에서 더 상세히 설명되는 바와 같이, 일부 경우에 NI어레이 노드는 삭제 후에 엔트리 리스트 노드로 변환될 수 있다). NI어레이(4510A)는 HDAG 상태(4590B)에서 자식 노드(4550A, 4550B, 4550C)의 포인터(예를 들어, 저장소 주소)를 포함한다. 원래 루트 엔트리 리스트(4506)에 있었던 엔트리는 초기에 자식 노드에서 각각의 엔트리 리스트(예를 들어, 노드(4550A)의 엔트리 리스트(4522A), 노드(4550C)의 엔트리 리스트(4522B), 및 노드(4550B)에서 초기에 생성된 다른 엔트리 리스트) 간 분산될 수 있다. 그리하여, 자식 노드(4550A, 4550B, 4550C)의 각각은 EL 노드로서 시작하였을 수 있다. 그렇지만, 상태(4590B)에 도달되는 때까지, 노드(4550B) 자체가 분할되고 NI어레이 노드가 되었으며, 그 자신의 자식 노드(4550K, 4550L)로의 포인터가 NI어레이(4510B)에 저장된다. 노드(4550L)는 또한 상태(4590B)에서 EL로부터 NI어레이로 상태를 변경하였고, 그 NI어레이(4510C)는 그 자식 노드로의 포인터를 포함한다. 노드(4550K)는 아직 EL 노드인 채로 있으며, D1 내에서 생성된 파일/디렉터리 중 일부를 표현하는 엔트리 리스트(4522K)를 갖는다. 노드의 각각의 헤더(예를 들어, 헤더(4520R, 4520A, 4520B) 등)는 묘사된 실시형태에서는 노드 분할(또는 일부 유형의 엔트리 삭제 후 노드 결합)의 결과로서 노드의 유형이 변경되면 그리고 그때 수정될 수 있다. 일부 구현에서는, 적어도 일부 시점에서, 루트 노드(4500A) 및/또는 다른 HDAG 노드는 사용 중이지 않은 소정 수의 바이트를 포함할 수 있다. 상태(4590B)에서, HDAG는 루트 레벨, (루트 노드의 NI어레이 포인터를 사용하여 단일 룩업으로 액세스될 수 있는 노드(4550A, 4550B, 4550C)를 포함하는) HDAG 레벨 1, 및 (레벨 1 노드의 NI어레이 포인터를 사용하여 단일 룩업으로 액세스될 수 있는 노드(4550K, 4550L)를 포함하는) HDAG 레벨 2를 포함하는 적어도 3개의 "레벨"을 포함하는 것으로 생각될 수 있다. 용어 "HDAG 레벨"은 여기에서는 소정 특정 노드에 도착하기 위해, HDAG의 루트 노드로부터 시작하여, 조우하였던 노드의 수의 표시로서 사용될 수 있다. 자식을 갖지 않는 HDAG 노드는 리프 노드라고 지칭될 수 있다. 적어도 일부 실시형태에서는, HDAG의 2개의 리프 노드(L1, L2)에 대해, HDAG 루트로부터 리프 노드로 향하는 각각의 순회 동안, L2에 도달하기 전에 조우한 것과는 다른 수의 노드를 L1에 도달하기 전에 조우할 수 있는 것이 사실일 수 있다. 도 45에 예시된 실시형태에서, 노드들 간 엔트리를 분산시키는데 그리고 그 후 엔트리를 룩업하는데 사용되는 해시 값은 HDAG 자체 내에 저장될 필요는 없을 수 있음을 주목한다.
앞서 언급된 바와 같이, 이름공간 관리 기술의 목표 중 하나는 이름에 의한 고속 룩업을 가능하게 하는 것일 수 있다. 도 46은, 적어도 일부 실시형태에 따라, 파일 이름에 대해 획득된 해시 값의 연속하는 서브시퀀스를 사용하여 HDAG를 항행하기 위한 기술을 예시한다. (유사한 기술이 디렉터리, 링크 또는 다른 파일 스토어 객체에 대해 사용될 수 있다). 파일의 이름(4602)은, 예를 들어 파라미터로서 이름을 갖는 룩업 요청에 응답하여, 선택된 해시 함수(4604)로의 입력으로서 사용된다. 일부 실시형태에서는, K(예를 들어, 255)개까지의 UTF-8 캐릭터의 스트링이 파일 이름 또는 디렉터리 이름으로서 사용될 수 있다. 다른 실시형태에서는 파일 스토어 객체 이름의 다른 길이 제한 또는 인코딩이 사용될 수 있다. 일 실시형태에서는, 여러 다른 해시 함수가 각각의 파일 스토어에 대해 사용될 수 있다 - 예를 들어, 해시 함수는 구성 파라미터로서 특정될 수도 있고, 파일 스토어에 대한 이름공간 크기의 예상, 대리에 의해 파일 스토어가 생성되고 있는 클라이언트에 의해 제공된 힌트 등에 기반하여 저장 서비스에 의해 선택될 수도 있다. 적어도 하나의 실시형태에서, 이름공간 엔트리의 소정 수에 대한 HDAG의 레벨의 평균 수, 또는 HDAG가 밸런싱되는 정도(예를 들어, 일부 엔트리가 다른 것들보다 훨씬 더 적은 레벨을 통과함으로써 도달되는지)와 같은, 사용 중인 해시 함수의 유효성의 다양한 메트릭은 시간의 흐름에 따라 추적될 수 있고, 그리고 측정된 유효성이 충분하지 않으면 (적어도 장래 사용에) 다른 해시 함수가 선택될 수 있다.
묘사된 실시형태에서는, (적어도) N*M 비트의 시퀀스로서 표현가능한 해시 값(4610)이 발생될 수 있으며, 여기서 N 및 M은 구성가능한 파라미터일 수 있다. M 비트의 해시 값(4610)의 N개의 서브시퀀스(예를 들어, S1, S2, ...SN)는 각각 HDAG의 대응하는 레벨로의 인덱스로서 사용될 수 있다 - 예를 들어, 서브시퀀스(S1)는 레벨 1을 항행하는데 사용될 (루트 노드의) NI어레이 포인터를 선택하도록 사용될 수 있고, 서브시퀀스(S2)는 레벨 1 노드로부터 시작하여 레벨 2를 항행하는데 사용될 NI어레이 포인터를 선택하도록 사용될 수 있고, 등이다. 소정 서브시퀀스에서의 모든 비트가 소정 검색 또는 항행 레벨에 사용될 필요는 없다 - 예를 들어, 일부 경우에서는 q개의 고-차수 비트(여기서 q < M)만이 사용될 수 있다. 일부 실시형태에서, 해시 값의 일부 비트(4666)는 어느 레벨에 대해서도 사용되지 않을 수 있다.
새로운 엔트리가, 예를 들어 파일 열기 커맨드 또는 디렉터리 생성 커맨드에 응답하여, 파일 스토어에 추가되어야 할 때, 새로운 엔트리의 이름에 대한 해시 값이 획득될 수 있고, 그리고 HDAG는 이름이 매핑되는 후보 EL 노드가 발견될 때까지 위에서 설명된 서브시퀀스-기반 항행 기술을 사용하여 순회될 수 있다. (일부 시나리오에서는, 이름공간이 엔트리에 대한 공간을 다 써버린 것이 사실일 수 있다 - 그러한 특별한 경우는 아래에서 논의된다). 후보 노드가 그 엔트리 리스트에서 더 이상 자유 공간을 갖고 있지 않으면, 또는 그 자유 공간 중 새로운 엔트리가 추가되면 임계 레벨 아래로 떨어질 것이면, 후보 노드는 분할될 수 있다. 분할되는 노드의 엔트리 중 적어도 일부는, 예를 들어 아래에서 설명되는 바와 같이 엔트리의 해시 값의 선택된 서브시퀀스를 사용하여, HDAG에 추가된 하나 이상의 새로운 노드 간 분산될 수 있다. 일부 실시형태에서는 적어도 2개의 다른 유형의 HDAG 노드 분할 연산이 수행될 수 있다.
도 47은, 적어도 일부 실시형태에 따라, 이름공간에 엔트리를 삽입하려는 시도로부터 초래될 수 있는 HDAG 노드 분할의 2개의 유형 중 제1 유형의 일례를 예시한다. 이러한 제1 유형의 분할에서, HDAG 노드의 유형은 아래에서 상세히 설명되는 바와 같이 엔트리 리스트(EL)로부터 NI어레이로 변경될 수 있다. 이름공간 엔트리 삽입은 일부 실시형태에서는 파일과 같은 이름공간 객체를 생성하라는 클라이언트 요청에 응답하여 취해지는 수 개의 단계 중 하나일 수 있다 - 예를 들어, 다른 단계는 파일과 연관된 DFS-아이노드 객체에 대한 공간을 할당하는 것, 파일의 초기 속성을 설정하는 것 및/또는 이름공간 엔트리로부터 DFS-아이노드로의 그리고 아이노드로부터 파일 콘텐츠를 저장하는데 사용될 하나 이상의 물리적 페이지로의 포인터를 설정하는 것을 포함할 수 있다. 이들 단계가 취해지는 순서는 여러 다른 실시형태에서 다를 수 있다.
도 47에 도시된 실시형태에서는 이름공간에 이름(예를 들어, 파일 이름) "리마"를 갖는 엔트리(4701)를 삽입하라는 요청이 수신되고, 그리고 이름 "리마"를 갖는 객체의 삽입이 시도되고 있는 디렉터리에 대해 생성된 HDAG 내에서의 항행 후에 후보 EL 노드(4750A)가 발견된다. HDAG의 식별자의 초기 부분(그들 저장소 주소에 또한 대응할 수 있고, 그리하여 저장 서브시스템으로 지향된 판독 또는 기록 연산에 대한 파라미터로서 사용될 수 있음)은 도 47에서는 16진 스트링으로서 도시되어 있다 - 예를 들어, 노드(4750)는 ID "0x432d12..."를 갖는다. 도 47에 예시된 제1 유형의 노드 분할은 묘사된 실시형태에서는 다음의 조건 하에 시도될 수 있다: (a) 후보 노드(4750A)가 루트 노드이든지 또는 (b) (도 47에 도시되지 않은) 노드(4750A)의 부모 노드에서의 하나의 NI어레이 포인터 엔트리만이 노드(4750A)를 가리키든지. 이들 조건 중 어느 것이든 만족되면, 묘사된 실시형태에서는 2개의 새로운 HDAG 노드(4750B, 4750C)에 대해 (각각의 메타데이터 익스텐트에서) 공간이 할당될 수 있다. (표현의 용이함을 위해 도 47에는 2개의 자식 노드가 예시되어 있음을 주목한다; 다른 실시형태에서는, 2개보다 많은 새로운 자식 노드가 분할 동안 생성될 수 있다). 이전에 노드(4750A)에 있었던 엔트리(예를 들어, "알파", "브라보", "찰리" 등)의 각각 및 새로운 엔트리 "리마"는, "1"이라는 라벨이 붙은 화살표에 의해 표시된 바와 같이, 그들 각각의 해시 값에 기반하여 새로운 노드(4750B 또는 4750C) 중 하나에 매핑될 수 있다. 일 구현에서, 예를 들어, 후보 노드가 HDAG의 K번째 레벨에 있었으면, 엔트리에 대한 해시 값의 (K+1)번째 서브시퀀스는 그들 최상위 비트에 기반하여 정렬될 수 있고, 그리고 해시 값이 그들 최상위 비트로서 "1"을 갖는 엔트리는 노드(4750B)에 매핑될 수 있는 한편, 해시 값이 그들 최상위 비트로서 "0"을 갖는 엔트리는 노드(4750C)에 매핑될 수 있다. 2개보다 많은 자식 노드가 분할 동안 생성되는 실시형태에서는, 더 많은 비트가 엔트리의 매핑에 사용될 수 있다 - 예를 들어, 4개의 자식 노드가 생성되면, 해시 서브시퀀스 값의 2개의 최고-차수 비트가 사용될 수 있고, 등이다. 묘사된 실시형태에서는, 예를 들어 객체 이름 및 해시 함수에 종속하여, 분할되는 노드(묘사된 예에서는 4750A)의 엔트리가 자식 노드들 간 균일하게 분산되는 것이 항상 사실이지는 않을 수 있고, 그리고 적어도 일부 실시형태에서는 그러한 균일성을 달성하려고 함으로써 HDAG를 "밸런싱"하려는 시도가 행해지지 않을 수 있다. 대신에, 그러한 실시형태에서는 노드들 간 엔트리의 합리적으로 밸런싱된 분산을 달성하기 위해 해시 함수의 강도 및 품질에 의존할 수 있다. 묘사된 예에서는 자식 노드들 간 엔트리의 분산 후에, 자식 노드(4750B)는 후속 삽입에 사용될 수 있는 자유 공간(4710A)을 갖는 한편, 자식 노드(4750C)는 후속 삽입에 사용될 수 있는 자유 공간(4710B)을 갖는다.
분할 이전에 EL 노드이었던 노드(4750A)는, 도 47에서 "2"라는 라벨이 붙은 화살표에 의해 표시된 바와 같이, NI어레이 노드로 변환될 수 있다. NI어레이 엔트리의 절반은 (예를 들어, (4750B)의 ID(0x786aa2...)를 저장함으로써) 노드(4750B)를 가리키도록 설정될 수 있고 그리고 다른 절반은 (예를 들어, (4750C)의 ID(0xc32176...)를 저장함으로써) 노드(4750C)를 가리키도록 설정될 수 있다. 최상위 비트가 엔트리를 분할하는데 사용된 일 구현에서, NI어레이 엔트리의 하위 절반(예를 들어, 인덱스 0 내지 (NI어레이크기/2)-1을 갖는 엔트리)은 노드(4750C)(해시 값이 "0"으로 시작하는 엔트리)를 가리키도록 설정될 수 있고, 그리고 NI어레이 엔트리의 상위 절반(예를 들어, 인덱스 (NI어레이크기/2) 내지 (NI어레이크기-1)을 갖는 엔트리)은 다른 자식 노드(4750C)를 가리키도록 설정될 수 있다. 분할의 결과로서 n개의 자식 노드가 생성되는 실시형태에서는, NI어레이 엔트리의 1/n이 자식의 각각을 가리키도록 설정될 수 있다. 3개의 노드(4750A, 4750B, 4750C)에 대한 변경은 저장 서브시스템에서 영속적 저장소에 저장될 수 있다. 일부 실시형태에서, 모든 3개의 노드에 대한 변경은, 예를 들어 앞서 설명된 분산형 트랜잭션 기술을 사용하여, 단일 원자 연산으로 수행될 수 있다. 다른 실시형태에서는, 앞서 설명된 조건부 기록이 3개의 노드 중 적어도 하나에 대한 변경을 다른 노드와 별개로 영속적이게 하도록 사용될 수 있다.
제1 유형의 분할 연산을 수행하기 위한 위에서 개괄된 조건이 만족되지 않으면(예를 들어, 후보 노드의 부모 노드가 후보 노드로의 하나보다 많은 NI어레이 포인터를 가지면), 제2 유형의 분할 연산이 수행될 수 있다. 도 48은, 적어도 일부 실시형태에 따라, 이름공간에 엔트리를 삽입하려는 시도로부터 초래될 수 있는 HDAG 노드 분할의 2개의 유형 중 제2 유형의 일례를 예시한다. 묘사된 예에서, 노드(4750C)는 새로운 엔트리 "퀸"(4801)에 대한 후보 노드로서 식별되었고, 그리고 노드(4750C)는 그 엔트리 리스트에 남은 자유 공간을 갖고 있지 않다. 부모 노드(4750A)는 "퀸"의 삽입이 시도되는 때 노드(4750C)로의 수많은 포인터(예를 들어, ID 값(0xc32176...)을 갖는 NI어레이 엔트리)를 포함한다. 동일한 값 "0x786aa2..."을 갖는 다수의 요소 및 값 "0x32176..."을 갖는 다수의 요소에 의해 표시된 바와 같이, 묘사된 실시형태에서, NI어레이 요소는 각각, 노드 내에서의 개개의 EL 엔트리가 아니라, 노드의 콘텐츠가 저장되는 블록을 가리킨다. 다른 실시형태에서는 블록-레벨 포인터 대신에 또는 그에 부가하여 엔트리-레벨 포인터가 사용될 수 있다. 도 48에 묘사된 시나리오에서는, 도 47에 예시된 바와 같은 2개의 노드 대신에 하나의 새로운 노드(ID(0x223123...)를 갖는 노드(4850A))만이 생성된다. 노드(4750C)의 엔트리에 대한 해시 값은 도 47에서 (4750A) 엔트리에 사용된 것과 유사한 방식으로 컴퓨팅될 수 있다. 해시 값은 최상위 비트에 기반하여 정렬될 수 있다. 1이라는 라벨이 붙은 화살표에 의해 표시된 바와 같이, 분할시 (4750C)에서의 엔트리 중 최상위 비트로서 "1"을 갖는 것들은 새로운 노드(4850A)에 매핑될 수 있는 한편, 나머지(최상위 비트로서 "0"을 갖는 것들)는 노드(4750C) 내에 유지될 수 있다.
부모 노드의 NI어레이 엔트리는 묘사된 실시형태에서는, 화살표(2)에 의해 표시된 바와 같이, 새롭게-추가된 노드(4850A)로의 포인터를 추가하도록 수정될 수 있다. 이전에 (4750C)를 가리키고 있었던 (4750A) NI어레이 엔트리 중에서, 하나의 절반(예를 들어, 어레이 인덱스 범위의 상위 절반)은 새로운 노드(4850A)를 가리키도록 설정될 수 있는 한편, 다른 절반은 계속 (4750C)를 가리킬 수 있다. 그리하여, 분할 후에, 노드(4750A)의 NI어레이 엔트리 중, 절반은 (분할에서 영향을 받지 않았던) (4750B)의 ID를 포함하고 있을 수 있고, 1/4은 (4750C)를 가리킬 수 있고, 그리고 1/4은 (4850A)를 가리킬 수 있다. 위에서 논의된 제1 유형의 노드 분할의 경우에서와 같이, 일부 실시형태에서, EL이 가득 찬 후보 노드(4750C)의 엔트리는 (후보 노드 자체를 포함하는) 2개보다 많은 노드들 간 재분산될 수 있다 - 예를 들어, 분산을 위한 2 비트의 엔트리 해시 값을 사용하여 총 4개의 노드가 사용될 수 있다. 일부 상황 하에서, 소정 노드의 분할은 HDAG의 루트로 향하여 상향 전파되어야 할 수 있다 - 예를 들어, 노드(N1)는 삽입에 기인하여 분할되어야 할 수 있고, 결과로서 N1의 부모도 분할되어야 할 수 있고, 등이다. 그러한 경우 후보 노드에 도달하기 위해 HDAG를 순회하는 프로시저는, HDAG의 루트로부터 시작하여, 반복되어야 할 수 있다.
도 47 및 도 48에 예시된 분할 연산은 분할이 시도되는 때 새로운 레벨(예를 들어, 새로운 자식 포인터)이 HDAG에 추가될 수 있다고 가정한다. 그렇지만, 적어도 일부 실시형태에서는, 예를 들어 각각의 HDAG 레벨을 항행하는데 사용되는 비트의 수 및 해시 값 크기에 기반하여, 소정 시점에서 해시 함수에 의해 허용된 레벨의 최대 수에 도달할 수 있고, 더 이상의 레벨은 추가되지 않을 수 있다. 그러한 시나리오에서는, 도 47 및 도 48에 예시된 해시-기반 분할을 수행하는 대신에, 해시-기반 분할에 의해 수용될 수 없는 새로운 엔트리에 대한 체인 또는 링크형 리스트가 (예를 들어, 제3 유형의 HDAG 노드를 사용하여) 생성될 수 있다. 예를 들어, 도 48에서, 노드(4850)가 가득 차게 되고 그리고 노드 "톰"을 삽입하려는 시도가 행해질 때 레벨의 수에 대한 한계에 도달되었으면, 유형 "체인"의 새로운 노드가 "톰"의 엔트리를 저장하도록 생성될 수 있고, 그리고 체인 노드로의 포인터는 후보 노드에서의 선택된 장소에서 삽입될 수 있다. 체인 노드는 필요하다면 다른 체인 노드를 가리키도록 자체가 수정될 수 있다. 체인 노드에 포함된 어느 소정 엔트리라도 위치를 찾아내기 위해, 다른 유형의 노드에서 사용되는 바와 같은 해시-기반 룩업 대신에 체인의 순차적 스캔이 사용될 수 있다. 이러한 식으로, 체인형 엔트리가 룩업을 위해 순차적으로 순회되어야 할 수 있으므로, 물론 해시-기반 순회의 속도 이점 중 일부가 상실될 수 있기는 하지만, HDAG가 "밸런싱되지 않게" 되더라도 다수의 엔트리가 수용될 수 있다. 다양한 실시형태에서, 합리적으로 긴 해시 값 및 강력한 해시 함수의 선택은 체인 노드를 사용해야 할 확률을 수락가능한 임계치 아래로 감축할 수 있다.
이름공간 엔트리(E)가 삭제되어야 할 때(예를 들어, 클라이언트의 요청시 대응하는 파일 또는 디렉터리가 삭제될 때), 엔트리가 삭제되어야 하는 EL 노드는, 객체의 이름에 대한 해시 값의 각각의 서브시퀀스가 HDAG의 연속하는 레벨에서의 인덱스로서 사용되는, 위에서 개괄된 해시-기반 순회 기술을 사용하여 발견될 수 있다. 엔트리가 제거되어야 하는 EL 노드는 삭제 표적 노드라고 지칭될 수 있다. 삭제 표적이 하나보다 많은 엔트리를 포함하고 있으면, E의 엔트리는 단순히 삭제되거나 자유로운 것으로 마킹될 수 있고, 추가적 연산이 요구되지 않을 수 있다. 그렇지만, 삭제 표적에서 다른 이름공간 엔트리가 없으면(즉, E의 엔트리를 제거하는 것이 공백 엔트리 리스트를 초래할 것이면), 그때는 삭제 표적 노드 자체가 삭제되어야 할 수 있다. 도 49는, 적어도 일부 실시형태에 따라, HDAG 노드 삭제 연산의 2개 유형 중 제1 유형의 일례를 예시한다. 묘사된 예에서는, HDAG에 의해 표현된 이름공간으로부터 "줄리엣"을 삭제하라는 요청이 수신된다. "줄리엣"에 대한 해시 값이 컴퓨팅되고, 그리고 해시 값의 연속하는 서브시퀀스가 HDAG의 루트로부터 노드(4950)로 향하여 항행하는데 사용된다. 노드(4950)는 단일 엔트리(삭제되어야 하는 "줄리엣"에 대한 엔트리)가 남아 있는 EL 노드이다. 줄리엣 엔트리는 ("X" 기호 및 수반되는 라벨 "1"에 의해 표시된 바와 같이) 삭제될 수 있다. 줄리엣의 엔트리를 제거하는 것은 노드(4950)에서 공백 엔트리 리스트를 초래하기 때문에, 노드(4950)는 자체가 삭제되어야 할 수 있다. 그 부모 노드(4948) 상에서의 노드(4950)를 삭제하는 결과는 노드(4948)의 NI어레이 리스트의 상태에 종속하여 다를 수 있다.
묘사된 실시형태에서, 삭제 표적 노드의 부모 노드는 일반적으로는 ("삭제 표적 포인터"라고 칭해질 수 있는) 삭제 표적 노드를 가리키는 하나 이상의 NI어레이 요소, 및 삭제 표적 노드 이외의 노드를 가리키는 영 개 이상의 NI어레이 요소를 갖고 있을 수 있다. 삭제 표적 노드 이외의 노드를 가리키고 NI어레이 내에서 삭제 표적 포인터 다음에(예를 들어, 어레이 내에서 바로 인접하는 하위 인덱스에) 있는 그들 NI어레이 요소는 삭제 표적 포인터의 "이웃"이라고 칭해질 수 있다. 삭제 표적 노드의 마지막 엔트리가 삭제될 때 적어도 하나의 이웃이 (4948)의 NI어레이 리스트에 존재하면, 이웃 포인터 값은 묘사된 실시형태에서는 단순히 삭제 표적 포인터에 복사될 수 있다. 도 49에 묘사된 시나리오에서는, 예를 들어, ((4950)의 ID(0xc44321...)가 (4901) 및 (4902)에 저장된다는 사실에 의해 표시된 바와 같이) 삭제 표적 노드(4950)를 가리키는 부모 노드(4948)에서의 2개의 삭제 표적 포인터(4901, 4902)가 있다. 또한, 부모 노드(4948)의 NI어레이는, 노드 ID(0x32176...)를 저장하는, 이웃 요소(4903)를 포함한다. 그리하여, 2라는 라벨이 붙은 화살표에 의해 표시된 바와 같이, 줄리엣 엔트리의 삭제가 삭제 표적 노드(4950)에서 공백 엔트리 리스트를 초래하고 부모 노드(4948)가 그 NI어레이에 적어도 하나의 이웃을 포함할 때, 그 이웃의 콘텐츠는 이전에 삭제 표적 노드(4950)를 가리키고 있었던 NI어레이 엔트리에 복사된다. 부가적으로, 묘사된 실시형태에서, 삭제 표적 노드(4950)는, 예를 들어 그 저장 공간을 해제하라는 요청을 저장 서브시스템에 보냄으로써, 자유롭게 될 수 있다. 이웃 포인터의 콘텐츠로 삭제 표적 포인터 어레이 요소의 콘텐츠의 대체는 화살표(4904)에 의해 표시되어 있다. 다른 실시형태에서는 삭제 표적 포인터의 이웃을 지정하는데 다른 기술이 사용될 수 있음을 주목한다 - 일부 실시형태에서는, 예를 들어, NI어레이 내에서 다음의 상위 인덱스를 갖는 NI어레이 엔트리가 이웃으로서 선택될 수 있다.
삭제 표적 노드의 부모 노드의 NI어레이 엔트리에 이웃이 없으면, 부모 노드는 일부 실시형태에서는 다른 방식으로 재조직될 수 있다. 도 50은, 적어도 일부 실시형태에 따라, HDAG 노드 삭제 연산의 2개 유형 중 제2 유형의 일례를 예시한다. 도시된 바와 같이, 삭제 표적 노드(4950)는 그 엔트리 리스트에 단일 엔트리를 포함한다. 그 유일한 나머지 엔트리("줄리엣")는, "X" 기호 및 수반되는 라벨 "1"에 의해 표시된 바와 같이, 삭제된다. 묘사된 예의 시나리오에서, 부모 노드(4948)의 NI어레이는 어느 이웃 요소(즉, 삭제 표적 노드를 가리키지 않는 NI어레이 요소)도 포함하고 있지 않다. 그리하여, 이용가능한 이웃 포인터 값이 없으므로, 도 49에 예시된 접근법은 실현가능하지 않을 수 있다. 따라서, "2"라는 라벨이 붙은 화살표에 의해 예시된 바와 같이, 다른 접근법이 취해질 수 있다: 부모 노드(4948)의 유형은 NI어레이 대신에 EL(엔트리 리스트)로 변경될 수 있고, 그리고 공백 엔트리 리스트는 노드(4948)에 대해 초기화될 수 있다. 새롭게-초기화된 EL 노드는, 예를 들어 앞서 설명된 유형의 분할 연산의 결과로서 새로운 노드가 HDAG에 추가되어야 할 때, 재-사용될 수 있다. 삭제 표적 노드(4950)는, 도 49에 대해 위에서 논의된 것과 유사한 방식으로, 자유롭게 될 수 있다. 다양한 실시형태에서, 소정 HDAG 레벨에서 이루어진 수정은 일부 경우에서는 다른 레벨에서의 변경을 요구할 수 있다 - 예를 들어, 일 실시형태에서는, 노드(4848)의 유형이 위에서 설명된 바와 같이 변경될 때, (4848)의 부모 노드의 NI어레이 엔트리가 수정되어야 할 수 있고, 그리고 변경의 효과가 HDAG의 루트로 향하여 상향 전파될 수 있다. 앞서 언급된 바와 같이, 다양한 실시형태에서 앞서 설명된 조건부 기록 기술 및/또는 분산형 트랜잭션 기술은 소정 삽입 또는 삭제로부터 초래되는 소망 수의 HDAG 변경을 원자 연산으로 조합하도록 사용될 수 있다.
도 51은, 적어도 일부 실시형태에 따라, 제1 유형의 HDAG 노드 분할을 초래하는 이름공간으로의 엔트리의 삽입에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 그러한 분할 연산의 단순한 예는 도 47에 제공된다. 요소(5101)에서 제시된 바와 같이, 분산형 멀티-테넌트 저장 서비스의 이름공간에 엔트리(E)를 추가하라는 요청이 수신된다. 요청은, 예를 들어, 서비스에서 구현된 파일 시스템의 클라이언트에 의해 발행된, 파일 "F이름(Fname)"을 생성하거나 파일 "F이름"을 열라는 커맨드에 응답하여 발생될 수 있다. 일 실시형태에서, 요청은 특정 메타데이터 서브시스템 노드에서의 커맨드 해석기 컴포넌트에서 발생될 수 있고, 다른 메타데이터 서브시스템 노드에서의(또는 동일한 메타데이터 서브시스템 노드에서의) 이름공간 매니저 컴포넌트에서 수신될 수 있다. 해시 함수는 (예를 들어, 해시 함수의 강도, 파일 스토어의 예상된 크기 및/또는 성능 요건, 및/또는 다른 인자에 기반하여) 표적 파일 시스템에 대한 이름공간 관리를 위해 선택되었을 수 있다. 해시 함수는 "F이름"에 대응하는 해시 값(H값(Hvalue))을 발생시키도록 사용될 수 있으며, 여기서 H값은 각각 M 비트의 N개의 서브시퀀스로서 표현될 수 있다(요소(5104)). 일 구현에서, 예를 들어, H값은 각각 8 비트의 8개의 서브시퀀스를 포함할 수 있고, 그리하여 적어도 64 비트를 소비할 수 있다.
적어도 2개 유형의 노드(앞서 설명된 바와 같은 노드 식별자 어레이(NI어레이) 노드 및 엔트리 리스트(EL) 노드)를 포함하는 HDAG는, 예를 들어, 새로운 파일(F이름)이 추가되고 있는 디렉터리에 대한 이름공간에 대해 셋업되었을 수 있다. 엔트리 리스트 노드는 묘사된 실시형태에서는 Max-EL개까지의 엔트리를 수용할 수 있을 수 있으며, 여기서 Max-EL은 지원되는 객체 이름의 최대 길이, 엔트리 리스트에 저장된 DFS-아이노드 주소 또는 식별자의 길이, HDAG 노드에 사용되는 바이트의 수 등과 같은 인자에 종속할 수 있다. 유사하게, NI어레이는 묘사된 실시형태에서는 Max-NID개까지의 요소를 수용할 수 있으며, Max-NID는 노드 ID의 크기 및 HDAG 노드의 크기에 종속한다. 적어도 하나의 실시형태에서, 엔트리의 임계 파퓰레이션(EL-임계치)은, 삽입의 결과로서 엔트리의 수가 EL-임계치를 초과하면 노드 분할이 개시되게 되도록, 지정될 수 있다. 일부 구현에서, EL-임계치에 대한 디폴트 값은 Max-EL로 설정될 수 있다, 예를 들어, 분할은 EL이 가득 차게 될 때만 구현될 수 있다. 유사하게, 적어도 하나의 실시형태에서는 NI어레이 노드에 대한 임계치가 정의될 수 있다, 예를 들어, 노드에서 NI어레이에서의 요소의 수가 NID-임계치를 초과할 때, NI어레이 노드는 분할될 수 있다. NID-임계치는 일부 실시형태에서는 디폴트로 Max-EL로 설정될 수 있다. 일부 구현에서는 EL-임계치든, NI-임계치든, El-임계치와 NI-임계치 양자든 구성가능한 파라미터로서 구현될 수 있다.
HDAG의 루트(영번째 레벨)로부터 시작하여, 하나 이상의 HDAG 레벨은, 각각의 레벨에서 조사될 특정 노드 또는 노드들을 식별하도록 H값의 연속하는 M-비트 서브시퀀스를 사용하여, E가 추가되어야 하는 후보 노드(CN)를 식별하기 위해 항행 또는 순회될 수 있다(요소(5107)). 적어도 일부 실시형태에서, HDAG의 노드의 각각은 다른 논리적 블록에 대응할 수 있고, 그리고 다른 HDAG 노드에 대해서와는 다른 저장 서브시스템 노드에서의 다른 익스텐트가 그것에 사용되고 있을 확률은 높을 수 있다. 요소(5110)에서 결정되는 바와 같이 후보 노드가 발견되지 않으면(일부 경우에서는 메타데이터 서브시스템이 HDAG에 대한 공간을 다 써버렸으면 일어날 수 있음), 오류(예를 들어, "디렉터리에서 허용된 파일의 최대 수가 초과되었음")가 반환될 수 있다(요소(5113)). (요소(5110)에서 또한 결정되는 바와 같이) 후보 노드(CN)가 발견되고, 그리고 (요소(5116)에서 검출되는 바와 같이) 그 엔트리 리스트가 새로운 엔트리(E)를 수용하기에 충분한 공간을 갖고 있으면(예를 들어, E의 추가는 EL 길이가 EL-임계치를 초과하게 야기하지 않을 것임), 새로운 엔트리(E)는 리스트에서 현재 사용되고 있지 않은 엔트리 중 하나에 기록될 수 있다(요소(5119)). CN에 대한 수정은 묘사된 실시형태에서는, 예를 들어 하나 이상의 메타데이터 익스텐트 복제본에서, 영속적 저장소에 저장될 수 있다. 적어도 일부 실시형태에서, DFS-아이노드 구조는 이름을 갖는 객체(F이름)에 대해 할당될 수 있고, 그리고 그 DFS-아이노드 구조로의 포인터는 E 내에 포함될 수 있다. "F이름"에 대한 후속 룩업 요청에 응답하여, 요소(5104, 5107)에 예시된 것과 유사한 해시-기반 항행이 사용될 수 있다(즉, "F이름"에 대해 획득된 해시 값의 각각의 서브시퀀스는 "F이름"에 대한 엔트리가 발견될 때까지 HDAG 항행의 각각의 레벨에 사용될 수 있다).
(요소(5116)에서 또한 검출되는 바와 같이) CN이 E에 대한 충분한 공간을 갖고 있지 않으면(예를 들어, EL-임계치에 도달되었거나, E의 삽입에 의해 도달될 것이면), CN을 가리키는 CN의 부모 NI어레이 리스트에서의 포인터의 수가 결정될 수 있다. (요소(5122)에서 검출되는 바와 같이) 부모 노드가 CN으로의 하나의 포인터만을 갖고 있으면(또는 마침 HDAG의 루트 노드이면), (도 47에 예시된 것과 유사한) 제1 유형의 노드 분할 연산이 개시될 수 있다. 각각의 해시 값은, 새로운 엔트리(E)에 대해 이미 획득된 H값에 부가하여, CN의 리스트에서의 엔트리의 각각에서의 객체 이름에 대해 획득될 수 있다(요소(5125)). 해시 값은 묘사된 실시형태에서는, 예를 들어 정렬/분산 기준으로서 해시 값의 log2P 최상위 비트를 사용하여, 엔트리 리스트 멤버 및 E를 P개의 그룹으로 분산시키도록 사용될 수 있다(요소(5128)). 일례의 구현에서, P는 2로 설정될 수 있고, 그래서 단일 최상위 비트만이 사용될 수 있다. P개의 그룹의 각각은 HDAG에 추가될 각각의 새로운 노드의 엔트리 리스트로서 저장될 수 있다(요소(5131)). 새로운 NI어레이가 생성될 수 있으며, 어레이 요소의 대략 1/P이 P개의 새로운 노드의 각각을 가리킨다(예를 들어, 그 저장소 주소 또는 식별자를 포함하고 있다). CN의 헤더는 그것이 EL 노드라기보다는 NI어레이 노드임을 표시하도록 수정될 수 있고, 새로운 NI어레이는 CN에 기록될 수 있다(요소(5134)). 수정된 CN 및 HDAG의 P개의 새로운 노드의 콘텐츠는, 예를 들어 하나 이상의 저장 서브시스템 노드에서, 영속적 저장소에 저장될 수 있다. 일부 실시형태에서, 위에서 설명된 분산형 트랜잭션 기술은 HDAG에 대한 변경 전부 또는 소정 서브세트를 단일 원자 연산으로 조합하도록 사용될 수 있다. 다른 실시형태에서는, 앞서 설명된 유형의 조건부 기록이 HDAG 노드 중 적어도 일부에 대해 사용될 수 있다.
(요소(5122)에서 또한 검출되는 바와 같이) CN의 부모 노드로부터 CN을 가리키고 있었던 NI어레이 요소의 수가 하나를 초과하였으면, (도 51의 "5201로 간다" 요소에 의해 표시된 바와 같이) 제2 유형의 분할 연산이 CN 상에 수행될 수 있다. 도 52는, 적어도 일부 실시형태에 따라, 그러한 제2 유형의 HDAG 노드 분할을 초래하는 이름공간으로의 엔트리의 삽입에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 이러한 유형의 분할은 여기에서는 유형-2 분할이라고 지정될 수 있고, 그리고 도 51에 예시된 분할의 유형은 유형-1 분할이라고 지칭될 수 있다. 유형-2 분할에서, CN의 엔트리 리스트의 멤버 중 일부는 Q개의 새로운 HDAG EL 노드로 이동될 수 있는 한편(여기서 Q는 하나보다 작지 않음), 일부는 CN에 남아 있을 수 있고, 그리고 부모 노드의 NI어레이 포인터는 그에 따라 변경될 수 있다. 묘사된 실시형태에서, CN의 엔트리 리스트의 서브-리스트는 CN 자체에서 그리고 Q개의 새로운 HDAG 노드(NN1, NN2, ... NNQ)들 간 재분산을 위해 선택될 수 있다. 일 구현에서는, Q가 1로 설정될 수 있고 그리고 대략(또는 정확히) 엔트리 리스트의 절반이 재분산에 고려될 수 있는 한편, 다른 구현에서는 3/4이 고려될 수 있다. 서브-리스트의 각각의 멤버에 대해 각각의 해시 값이 결정될 수 있다(요소(5204)). 해시 값은, 예를 들어 분산 기준으로서 해시 값의 소정 수의 최상위 비트를 사용하여, 서브-리스트 멤버를 Q+1개의 그룹으로 배열하도록 사용될 수 있다(요소(5207)).
그룹 중 Q개가 각각의 새로운 HDAG EL 노드에 배치될 수 있는 한편, 나머지 그룹은 CN 내에 보유될 수 있다. CN을 가리키고 있었던 CN의 부모 노드에서의 NI어레이 엔트리 중 일부는 새로운 노드(NN1, ..., NNQ)를 가리키도록 설정될 수 있다(요소(5210)). 묘사된 실시형태에서, 분할의 결과로서 수정 또는 생성된 HDAG 노드(예를 들어, Q개의 새로운 노드, CN 및 CN의 부모 노드)는 단일 원자 연산으로 영속적 저장소에 기록될 수 있다(요소(5213)). 일부 실시형태에서는 위에서 설명된 분산형 트랜잭션 기술이 사용될 수 있다. 다른 실시형태에서는 단일 원자 연산이 사용되지 않을 수 있다; 예를 들어, HDAG 노드 중 적어도 일부에 대해서는 조건부 기록 기술이 사용될 수 있다.
엔트리 리스트 멤버가 유형-2 분할로 재-분산되게 하는 기술은 일부 실시형태에서는 도 52에 예시된 것과 다를 수 있음을 주목한다. 예를 들어, 일부 실시형태에서, 서브-리스트 멤버는 그것들이 Q개의 새로운 노드들 간 전적으로 분산될 수 있는 그러한 식으로 선택될 수 있다. 일부 실시형태에서, 서브-리스트의 크기는 무작위로 선택될 수 있다 - 예를 들어, 소정 HDAG에서 또는 소정 파일 스토어에서 구현되는 모든 유형-2 분할이 동일한 수의 새로운 노드를 초래할 수 있는 것은 아니다. 일부 실시형태에서는, 무작위의 요소가 또한 유형-1 분할에 도입될 수 있다 - 예를 들어, 사용되는 EL-임계치는 소정 범위 내에서 무작위로 가변될 수도 있고, 새로운 노드의 수(P)는 소정 범위로부터 무작위로 선택될 수도 있다.
도 53은, 적어도 일부 실시형태에 따라, 이름공간으로부터 엔트리의 삭제에 응답하여 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(5301)에서 제시된 바와 같이, 이름을 갖는 파일 스토어 객체(F이름)에 대한 엔트리(E)를 분산형 저장 서비스의 이름공간으로부터 제거하라는 요청이 수신될 수 있다. 그러한 요청은, 예를 들어, 파일 또는 디렉터리를 제거하라는 클라이언트 요청의 결과로서 발생될 수 있다. 선택된 해시 함수를 사용하여, 비트 시퀀스가 각각 M 비트의 N개의 서브시퀀스로 분할될 수 있는 해시 값(H값)이 획득될 수 있다(요소(5304)).
이름공간에 대해 발생된 HDAG는 E를 포함하고 있는 삭제 표적 노드(N1)를 식별하도록, 그 루트 노드로부터 시작하여, 항행 또는 순회될 수 있다(요소(5307)). 각각의 HDAG 레벨에서, N개의 서브시퀀스의 연속하는 서브시퀀스는 판독 또는 조사될 노드를 식별하는데 사용될 수 있다. (요소(5310)에서 검출되는 바와 같이) N1의 엔트리 리스트가 엔트리를 적어도 하나 더 포함하면, 엔트리 리스트 내에서의 E의 슬롯은 단순히 사용되고 있지 않거나 자유로운 것으로 마킹될 수 있고(요소(5313)) 그리고 삭제 연산은 완료될 수 있다. 일부 구현에서는, 예를 들어 비-공백 엔트리를 발견하는 것을 더 신속히 하기 위해, 자유롭게 된 엔트리는 리스트의 일단으로 이동될 수 있다. 그리하여, 예를 들어, 길이(N)의 엔트리 리스트가 2개의 비-공백 엔트리를 포함하고 있으면, 하나의 그러한 구현에서, 그들 2개의 비-공백 엔트리는 리스트 내에서 오프셋 0 및 오프셋 1에서 발견될 것인 한편, 오프셋 2, 3, ..., N-1을 갖는 엔트리는 공백일 것이다. 일부 실시형태에서, N1에 대한 변경은 동기식으로 영속적이게 될 수 있는 한편, 다른 실시형태에서, N1은 E에 대한 삭제 요청에 대해 비동기식으로 하나 이상의 익스텐트에서 영속적 저장소에 기록될 수 있다.
(요소(5310)에서 또한 검출되는 바와 같이) E가 N1의 엔트리 리스트에서 마지막 엔트리이었으면, N1의 부모 노드(PN)의 NI어레이가 조사될 수 있다. PN의 NI어레이는 N1을 가리키고 있는(예를 들어, 그 주소 또는 식별자를 저장하고 있는) 하나 이상의 요소(NP1, NP2, ...)를 포함할 수 있다. (요소(5316)에서 결정되는 바와 같이) PN의 NI어레이가 또한 N1 이외의 어떤 노드를 가리키는 적어도 하나의 "이웃" 요소(NX)를 포함하면, NX의 콘텐츠는 PN이 더 이상 N1으로의 포인터를 포함하고 있지 않도록 NP1, NP2, ...에 복사될 수 있다(요소(5319)). 적어도 일부 실시형태에서, 어레이 요소(NP1, NP2, ...)는 또한 또는 대신 실효된 것으로 마킹될 수 있다.
(요소(5316)에서 또한 검출되는 바와 같이) PN의 NI어레이가 N1 이외의 노드를 가리키는 그러한 이웃 요소를 포함하고 있지 않으면, PN은 묘사된 실시형태에서 다른 방식으로 수정될 수 있다. 요소(5322)에서 제시된 바와 같이, PN의 유형은, 예를 들어 그 헤더를 수정함으로써, NI어레이로부터 EL로 변경될 수 있다. 부가적으로, 새로운 엔트리 리스트는 PN에 대해 초기화될 수 있다 - 예를 들어, NI어레이에 사용되고 있었던 바이트 중 적어도 일부는 겹쳐쓰일 수 있다. 묘사된 실시형태에서, 이웃 요소가 부모 노드(PN)에서 발견되었는지 여부와 무관하게, 삭제 표적 노드는 자유롭거나 사용되고 있지 않은 것으로 마킹될 수 있다(요소(5325)). 삭제에 의해 영향을 받은 노드, 예를 들어, PN 및 N1의 각각의 콘텐츠는 저장 서브시스템의 하나 이상의 익스텐트에서 영속적 저장소에 저장될 수 있다. 일부 실시형태에서, 앞서 설명된 유형의 분산형 트랜잭션은 단일 원자 연산의 일부분으로서 적어도 요소(5322, 5325)에서 제시된 변경을 하도록 사용될 수 있다. 다른 실시형태에서, 요소(5319)에서 제시된 수정은 또한 단일 원자 연산 또는 분산형 트랜잭션으로 요소(5322, 5325)의 것들과 조합될 수 있다. 조건부 기록은 적어도 하나의 실시형태에서 변경의 각각에 대해 사용될 수 있다.
다양한 실시형태에서, (예를 들어, 파일 시스템 레벨에서든, 파일 저장 서비스에 대해 전체로서든 정의된) 구성가능한 파라미터는 해시-기반 이름공간 관리 기술의 다양한 태양을 결정하도록 사용될 수 있다. 그러한 구성가능한 파라미터는 (a) 사용될 특정 해시 함수(들) 또는 해시 함수 패밀리, (b) 해시 함수에 의해 출력된 비트 시퀀스의 요구되는 길이, (c) DAG의 각각의 레벨을 순회하도록 사용될 해시 값 출력의 다양한 서브시퀀스의 길이, (d) 각각의 유형의 분할의 팬-아웃(예를 들어, 각각의 분할 유형에서 분할 노드의 엔트리가 배정되게 되는 리스트의 수), (e) 분할 후에 각각의 새로운 노드의 식별자가 저장되게 되는 NI어레이 요소의 수(또는 비율), (f) 각각의 유형의 분할에 대한 임계 파퓰레이션 레벨, 또는 (g) DAG의 레벨의 최대 허용가능한 수 또는 DAG의 총 크기의 어느 조합에 대해서라도 특정될 수 있다. 일부 실시형태에서는 부가적 제약(예를 들어, 익스텐트 배치 제약)이 또한 파라미터를 통하여 특정될 수 있다 - 처음 N개 레벨의 모든 HDAG 노드가 동일한 익스텐트에서 저장되어야 한다는 제약이 특정될 수도 있고, 어느 2개의 HDAG 노드도 동일한 익스텐트에서 저장되지 않아야 한다는 제약이 특정될 수도 있다. 일부 실시형태에서, 이들 파라미터 중 하나 이상은 수집된 성능 결과에 기반하여 수정될 수 있다. 예를 들어, 이름공간-관련 성능이 특정 파일 시스템에 대한 소정 파라미터 세트로 만족스럽지 못하면, 저장 서비스는 - (온 더 플라이로든지 재구성 다운타임 기간 동안에든지 생성될 새로운 HDAG를 수반할 수 있는) 동일한 파일 시스템에 대해서든지 또는 후속하여 생성된 파일 시스템에 대해서든지 파라미터를 조절할 수 있다.
클라이언트 세션 메타데이터 관리
적어도 일부 실시형태에서, 분산형 저장 서비스는 NFS와 같은 하나 이상의 상태 기반 또는 세션-지향형 파일 시스템 프로토콜을 지원할 수 있다. 일부 그러한 프로토콜에서, 서비스의 클라이언트 컴포넌트(예를 들어, 클라이언트-측 실행 플랫폼에서 실행되는 데몬)는 전형적으로는 서버 컴포넌트(예를 들어, 서버-측 실행 플랫폼에서 실행되는 다른 데몬)와 하나 이상의 통신을 통하여 세션을 생성할 수 있으며, 세션은 서비스가 소정 종류의 클라이언트 요청에 대한 응답을 우선처리할 수 있는 연관된 만료 시간을 갖고, 그리고 세션은 일부 조건 하에서는 연장 또는 갱신될 수 있다. 세션 동안, 클라이언트는, 예를 들어, 파일과 같은 객체 상의 로크를 획득할 수 있고, 그리고 로크는 세션이 종료되든지 클라이언트가 로크를 해제하든지 할 때까지 유효한 채로 있을 수 있다. 세션 동안 클라이언트로부터의 객체의 후속 액세스는 추가적 로킹을 요구하지 않을 수 있다. 일부 파일 시스템 프로토콜에 의하면, 서버로부터 클라이언트로의 파일(또는 다른 유형의 파일 스토어 객체)의 상태의 제어의 그러한 시간-구속 승인은 "리스"라고 지칭될 수 있다. 단일 리스는 복수의 파일 스토어 객체 상의 로크와 연관될 수 있고, 클라이언트에 의해 명시적으로든 묵시적으로든 갱신될 수 있다. 적어도 일부 실시형태에서, 세션-지향형 프로토콜은 세션 상태 정보(예를 들어, 클라이언트의 리스와 연관된 로킹된 파일 또는 디렉터리의 리스트, 리스의 만료 시간 등)가 "파일 서버"에 의해 유지되고 있을 것을 요구할 수 있다. 분산형 파일 저장 서비스에서, 파일 서버의 프로토콜-위임 책임은 위에서 설명된 다양한 서브시스템들 - 예를 들어, 액세스 서브시스템, 메타데이터 서브시스템, 및/또는 저장 서브시스템 간 분산될 수 있다. 확장가능한 응답 시간 및 처리율 목표, 메타데이터 영속성 요건 등과 같은 다양한 인자는 여러 다른 실시형태에서 여러 다른 서브시스템에서 구현되어야 하는 프로토콜-위임 세션-관련 기능성의 특정 부분을 결정할 때 고려될 수 있다.
도 54는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 세션-지향형 파일 시스템 프로토콜에 대해 유지되고 있을 수 있는 2차원의 메타데이터를 예시한다. 소정 클라이언트 세션 동안 열렸던 그리고/또는 로킹되었던 모든 객체에 대한 정보는 (예를 들어, 세션의 모든 로크가 해제될 것을 요구할 수 있는 리스 만료에 대해) 소정 유형의 연산에 대해 저장 서비스에 의해 효율적으로 액세스되어야 할 수 있다. 메타데이터 정보의 이러한 제1 차원은, 클라이언트 세션(CS1) 상의 리스-관련 연산에 대해 액세스될 수 있는 메타데이터 세트(5401)의 콘텐츠와 같은, 도시된 개념적 메타데이터 테이블(5401)에서의 로우에 의해 표현된다. 메타데이터 세트(5401)는, 예를 들어, 복수의 파일, 디렉터리, 링크 등에 대해, 아래에서 더 상세히 사용이 논의되는 (NFS "상태ID(StatelD)"와 같은) 로크 상태 표시자(LSI)를 포함할 수 있다. 도시된 예에서는, 클라이언트 세션(CS1)에 대해 기록 로크 상태 표시자(W-로크)가 디렉터리(D1)에 대해 제시되어 있고, 그리고 R-로크(판독 로크 표시자)가 파일(F1, FP)에 대해 제시되어 있다. 적어도 일부 구현에서는, 로킹이 파일 레벨에서는 구현될 수 있지만 디렉터리 레벨에서는 구현되지 않을 수 있음을 주목한다.
제2 차원은, 파일(F1)에 관한 메타데이터 세트(5420)와 같은, 어느 소정 객체에 관해서라도 파일 시스템 프로토콜에 따라 유지되고 있어야 하는 세션-관련 정보의 세트이다. (클라이언트 세션(CS1)의 R-로크와 같은 로크 상태 표시자를 또한 포함할 수 있는) 메타데이터의 이러한 제2 집합은, 예를 들어, 객체를 로킹하라는 새로운 요청이 수신될 때 또는 객체의 상태 또는 속성을 보라는 요청이 수신될 때 효율적으로 액세스되어야 할 수 있다. 수백만의 객체(그 중 다수는 적어도 잠재적으로 다수의 익스텐트를 가로질러 분산됨)를 저장할 수 있고 여러 다른 유형의 로킹 모드 및/또는 리스 모드가 지원되는 수만의 병행 클라이언트 세션을 가질 수 있는 파일 스토어에서는, 도 54에 예시된 유형의 세션-관련 정보 전부를 단일 중앙집중형 장소에 저장하는 것이 실용적 또는 효율적이지 않을 수 있다. 그리하여 도 54는 다양한 실시형태에서 효율적으로 액세스되어야 할 수 있는 적어도 2종류의 세션-관련 메타데이터의 개념도를 제공하고, 어느 특정 구현 접근법도 내포하려는 의도는 아니다.
특정 파일 시스템 프로토콜에 의해 요구되는 세션-지향형 메타데이터(5401)에 부가하여, (위에서 설명된 바와 같은 HDAG를 포함하는 이름공간 관리 메타데이터, 앞서 설명된 바와 같은 논리적-블록-대-물리적-페이지 매핑 등과 같은) 다른 내부 메타데이터도 유지되고 있을 수 있음을 주목한다. 메타데이터의 여러 다른 유형은 적어도 일부 실시형태에서 메타데이터 서브시스템의 독립적 서브컴포넌트에 의해 관리될 수 있다 - 예를 들어, 스트라이핑 또는 논리적-블록-대-물리적-페이지 매핑의 관리는 도 54에 예시된 유형의 클라이언트 세션 정보의 관리에 대해 직교하여 구현될 수 있다. 더욱, 분산형 저장 서비스는, 적어도 하나의 실시형태에서, 복수의 상태 기반 또는 세션-지향형 파일 시스템 프로토콜을 지원할 수 있으며, 그 각각은 각각의 세션 메타데이터 객체 유형 및 시맨틱스를 정의할 수 있다. 예를 들어, NFS는 그 메타데이터 객체 및 관계 세트를 특정할 수 있고, SMB는 다른 세트를 특정할 수 있고, 등이다. 그러한 시나리오에서는, 여러 다른 프로토콜의 각각과 연관된 파일 시스템에 대해 별개의 세션-지향형 메타데이터 세트(5401)가 유지되고 있을 수 있다.
적어도 일부 실시형태에서, (제공자 네트워크의 컴퓨트 인스턴스에서 하나 이상의 프로세스를 사용하여 구현된 NFS 클라이언트와 같은) 클라이언트는 파일 시스템 프로토콜에 따라 포맷팅된 메시지를 분산형 저장 서비스에 송신함으로써 클라이언트 세션의 확립을 요청할 수 있다. 도 55는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스의 서브컴포넌트들 간 클라이언트 세션 메타데이터-관련 상호작용의 일례를 예시한다. 파일 시스템 클라이언트(5501)는 액세스 서브시스템 노드(5512), 예를 들어, 클라이언트에 의해 사용되는 파일 시스템에 대한 종단점으로서 IP 주소가 광고 또는 노출된 액세스 서브시스템 노드에 세션 요청(5550)을 보낼 수 있다. 사용되는 파일 시스템 프로토콜이 NFS인 일부 구현에서는, 예를 들어, 세션 요청이 "클라이언트ID설정(SetClientID)" 요청을 포함할 수 있고, (클라이언트에 의해 발생된) 클라이언트의 아이디 및 (또한 클라이언트에 의해 발생된) 소위 "검증자"라는 고유, 비-반복 객체를 포함할 수 있다. 일부 그러한 구현에서 검증자는 세션이 원래 인스턴스화된 이후로 클라이언트가 리부팅하였는지 결정하도록 서비스에 의해 사용될 수 있다; 그리하여, 다른 검증자를 갖는 제2 클라이언트ID설정 요청의 제출은 서비스가 클라이언트의 앞선 세션/리스를 만료시킬 수 있게 할 수 있다. 세션 요청에 응답하여, 사용 중인 파일 시스템 프로토콜은 (오류 조건을 조우하지 않는 한) 세션 식별자(5563)(예를 들어, NFS "클라이언트ID(ClientID)" 객체)가 궁극적으로 서비스에 의해 요청자에 제공될 것을 요구할 수 있다.
적어도 일부 실시형태에서, 분산형 저장 서비스의 메타데이터 서브시스템은 클라이언트 세션 상태 정보를 관리하는 것을 책임지고 있을 수 있다. 예를 들어, 메타데이터 서브시스템은 클라이언트 세션 상태 정보가 논리적 블록에 매핑되는 방식은 물론 그들 논리적 블록 대 익스텐트의 매핑도 제어할 수 있다. 익스텐트 자체는 일부 실시형태에서는 저장 서브시스템 노드에서, 그리고 앞서 설명된 바와 같은 다른 실시형태에서는 메타데이터 서브시스템 노드에서 저장될 수 있다. 액세스 서브시스템 노드가 일부 실시형태에서 일시적으로 세션-관련 메타데이터를 캐싱할 수 있지만, 메타데이터 서브시스템이 분산형 저장 서비스 내에서 클라이언트 세션 정보의 권위 있는 소스로서 지정될 수 있다.
묘사된 실시형태에서, 클라이언트 세션 요청을 수신시, 액세스 서브시스템 노드(5512)는 세션 초기화 요청(5553)을 선택된 메타데이터 노드(5522)에 송신하여, 세션 식별자가 메타데이터 서브시스템에 의해 발생되도록 요청할 수 있다. 클라이언트에 의해 제공된 파라미터(예를 들어, 클라이언트의 식별자 및/또는 검증자)는 적어도 일부 실시형태에서 액세스 노드에 의해 메타데이터 노드에 전달될 수 있다. 메타데이터 노드(5522)는 클라이언트의 세션 메타데이터의 적어도 일부를 저장하도록 새로운 논리적 블록(LB1)을 발생시킬 수 있다. LB1은 묘사된 실시형태에서는, 예를 들어, 메타데이터 노드에 의해 클라이언트 세션에 대해 발생된 세션 식별자(5563), 세션에 대한 리스 타임아웃 설정(5544), 및 "책임지고 있는 액세스 노드"(RAN) 필드(5546)를 포함할 수 있다. RAN 필드는 뒤따르는 세션 동안의 클라이언트의 요청이 통하여 백-엔드 서브시스템(예를 들어, 메타데이터 서브시스템 또는 저장 서브시스템)에서 수신될 것으로 예상되는 특정 액세스 노드(5512)를 식별시킬 수 있다. 메타데이터 노드(5522)는, 화살표(5557)에 의해 표시된 바와 같이, 묘사된 실시형태에서는 선택된 익스텐트(5580)의 하나 이상의 페이지에서 세션 메타데이터의 논리적 블록의 콘텐츠를 저장한다. 일부 구현에서, 메타데이터 노드(5522)는 논리적 블록 콘텐츠를 저장하라는 요청을 저장 서브시스템에 제출할 수 있는 한편, 다른 실시형태에서, 메타데이터 노드(5522)는 메타데이터 서브시스템 자체에 의해 관리되는 익스텐트에 콘텐츠를 기록할 수 있다.
적어도 일부 실시형태에 의하면, 클라이언트에 대해 선택 또는 발생된 세션 식별자(예를 들어, NFS 클라이언트ID)는 논리적 블록의 저장소 주소에 적어도 부분적으로 기반할 수 있다 - 예를 들어, 세션 식별자는 클라이언트 세션 메타데이터를 신속히 룩업하도록 판독 연산에서 파라미터로서 추후 사용될 수 있다. 예를 들어, 일 구현에서, 각각의 논리적 블록에는 128-비트 논리적 저장소 주소가 배정될 수 있고, 그리고 LB1에 사용된 128-비트 논리적 주소는 클라이언트에 대한 세션 식별자(5563)로서 제공될 수 있거나, 세션 식별자(5563) 내에 포함 또는 인코딩될 수 있다. 다른 실시형태에서, 세션 식별자는 세션 메타데이터 요소를 저장하도록 사용되는 물리적 블록(들) 중 적어도 하나의 물리적 저장소 주소에 적어도 부분적으로 기반할 수 있다. 메타데이터 노드(5522)는 세션 초기화 요청(5553)에 대한 응답(5560)을 송신할 수 있다. 응답(5560)은, 묘사된 실시형태에서는 액세스 노드(5512)에서 캐시(5578)에서 캐싱되고 요청하는 클라이언트(5502)에 제공될 수 있는, 세션 식별자(5563)를 포함할 수 있다. 일부 실시형태에서, 파일 시스템의 세션 확립 프로토콜은 하나 이상의 부가 상호작용을 요구할 수 있다, 예를 들어, 세션 식별자를 포함하는 확인 요청 메시지가 클라이언트(5502)에 의해 저장 서비스에 보내질 수 있고 그리고 그 후 클라이언트는 세션 식별자의 유효성을 확인해 주는 응답을 수신할 수 있다. 파일 열기, 닫기, 로크 요청 등과 같은, 클라이언트로부터의 후속 요청은 적어도 일부 실시형태에서는 세션 식별자(5563)를 포함하도록 요구될 수 있다. 그러한 추후 요청을 수신시, 액세스 노드(5512)는 캐시(5578)를 사용하여 클라이언트의 세션 식별자를 유효성검증할 수 있다. 세션 식별자가 캐시로부터 빠져 있으면, 액세스 노드는 세션에 관하여 질의를 메타데이터 서브시스템에 제출할 수 있고, 세션이 아직 열려 있는 경우(또는 질의에 응답하여 새로운 세션이 메타데이터 서브시스템에 의해 인스턴스화되는 경우)에만 요청된 연산을 진행할 수 있다.
앞서 표시된 바와 같이, 일부 실시형태에서 NFS와 같은 파일 시스템 프로토콜은 파일 시스템 객체로의 병행 액세스를 효율적으로 관리하도록 리스 기술을 구현할 수 있다. 일부 그러한 실시형태에서, 클라이언트 세션과 연관된 리스는 클라이언트에 파일 시스템의 하나 이상의 파일, 디렉터리, 링크 또는 다른 클라이언트-액세스가능한 객체의 상태의 제어의 시간-구속 승인을 표현할 수 있다. 적어도 하나의 실시형태에서는, 여기에서 로크 상태 표시자라고 지칭되는 다른 메타데이터 객체가 저장 서비스에 의한 특정 파일 시스템 객체의 로킹 상태를 표현하도록 사용될 수 있다. 예를 들어, NFS 프로토콜의 적어도 일부 구현에서, 로크 상태 표시자는 "상태ID"라고 칭해질 수 있다. 파일(F1)과 같은 객체에 대한 로크 상태 표시자는 적어도 일부 실시형태에서는 소정 클라이언트 세션(CS)의 맥락에서 정의될 수 있다. 그리하여, 예를 들어, 클라이언트(Cl1)가 클라이언트 세션(CS1)의 일부분으로서 파일(F1)을 로킹할 때, CS1에 특정적인 F1에 대한 로크 상태 표시자(LSI1)가 생성될 수 있고; 그리고 추후, 다른 클라이언트(Cl2)가 클라이언트 세션(CS2)의 일부분으로서 파일(F1)을 로킹할 때, 다른 로크 상태 표시자(LSI1)가 저장 서비스에 의해 발생될 수 있다. 적어도 일부 실시형태에서, LSI는 대응하는 클라이언트 세션의 세션 식별자로의 포인터를 편입 또는 포함할 수 있다 - 예를 들어, 일 구현에서, NFS-준수 상태ID는 대응하는 클라이언트ID로의 포인터(또는 그 실제 값)를 포함할 수 있다. 각각의 열린 클라이언트 세션은 일부 실시형태에서 연관된 리스 타임아웃 기간을 가질 수 있으며, 그 종료시 세션의 LSI 전부와 연관된 로크가 자유롭게 될 수 있다. 일부 실시형태에서, (LSI와 유사한) 열림 상태 표시자는 특정 파일 스토어 객체가 클라이언트에 의한 액세스를 위해 현재 열려 있음을 표시하는데 사용될 수 있다. 파일 스토어 객체의 로킹된 상태 및 열린 상태의 표시는 일부 구현에서는 단일 메타데이터 구조(예를 들어, 열림/로크 상태 표시자)를 사용하여 표현될 수 있다.
리스를 구현하는 적어도 일부 파일 시스템 프로토콜의 시맨틱스에 의하면, 리스 갱신을 위한 하나 이상의 메커니즘이 지원될 수 있다. 예를 들어, 연산 유형 세트는, 열린 세션 동안 클라이언트에 의한 그 연산 유형 세트의 연산에 대한 요청이 소정 특정된 리스 갱신 기한 동안 리스의 갱신을 자동으로 초래할 수 있게 되도록, 정의될 수 있다. 그러한 일 실시형태에서, 예를 들어 리스가 시간(T1)에서 만료하도록 설정되었던 세션(CS1) 동안, 클라이언트가 파일(F1)을 판독하라는 요청을 발행하면, 리스는 추후의 시간(T2)으로 연장될 수 있다. 일부 실시형태에서는, 리스를 명시적으로 갱신하기 위한 API가 또한 또는 대신 지원될 수 있다. 자동(또는 명시적) 리스 갱신을 초래하는 요청의 유형 중 어느 것도 특정된 기간 동안 수신되지 않으면, 리스는 만료할 수 있다. 일부 실시형태에서, 리스 만료시, (LSI에 의해 표시된) 대응하는 로크는 저장 서비스에 의해 해제될 수 있고, 세션 동안 열려 있었고 리스 만료 시점 전에 닫히지 않았던 파일 시스템 객체는 닫힐 수 있고, 그리고 적어도 일부 실시형태에서 세션 메타데이터는 메타데이터 서브시스템의 영속적 리파지토리로부터 그리고/또는 액세스 서브시스템의 캐시로부터 삭제될 수 있다.
도 56은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서의 클라이언트 세션 리스 갱신에 대한 대안의 접근법을 예시한다. 묘사된 실시형태에서, 자동-갱신 연산 리스트(5678)는 클라이언트에 의해 사용되는 파일 시스템 프로토콜에 의해 특정될 수 있다. 자동-갱신 연산 리스트(5678)는, 현재 열린 세션 동안 요청될 때, 세션과 연관된 리스(들)의 자동 갱신을 초래하는 연산 유형을 표시할 수 있다. 예를 들어, 일부 NFS 구현에서, 자동-갱신 연산 리스트는 (특히) 판독, 기록, 열기, 로크, 로크 해제 및 속성-설정 연산을 포함할 수 있다. 일부 구현에서는, 리스의 명시적 갱신을 대한 갱신 연산도 연산 리스트(5678)에 포함될 수 있다.
묘사된 실시형태에서, 액세스 서브시스템 노드(5512)는 파일 스토어 연산 요청(5650)을 수신할 수 있다. 연산 요청이 자동-갱신 연산 리스트에 표시된 유형(또는 클라이언트의 리스를 갱신하라는 명시적 요청)이면, 액세스 노드(5612)는 묘사된 실시형태에서 2개의 옵션을 가질 수 있다. 액세스 노드는 즉각적 또는 비-일괄 리스 갱신 요청(5653)을 메타데이터 노드(5522)에 제출하든지, 소정 구성가능한 시간 기간까지 동안 리스 갱신을 연기하고 일괄 리스 갱신 요청(5654)을 메타데이터 노드(5522)에 제출하든지 할 수 있다. 일괄 리스 갱신 요청은, 예를 들어, 타임 윈도 동안 자동-갱신 연산 요청 또는 명시적 갱신 요청이 수신된 복수의 클라이언트 세션에 대한 세션 식별자를 포함할 수 있다. 리스 갱신 요청의 일괄은 적어도 일부 실시형태에서는 메타데이터 노드(5522) 및/또는 액세스 노드(5512)에서 갱신-관련 오버헤드(예를 들어, 통신 오버헤드, 프로세싱 오버헤드, 또는 양자)를 감축하는 것을 도울 수 있다.
일부 실시형태에서, 구성가능한 즉각적 갱신 임계치(5688)는 클라이언트의 연산 요청(5650)에 응답하여 즉시 소정 리스 갱신이 송신되어야 하는지, 또는 연기된 일괄 접근법이 클라이언트의 리스 갱신에 사용되어야 하는지 결정하도록 액세스 노드에 의해 사용될 수 있다. 즉각적 갱신 임계치가, 예를 들어, X초로 설정되고 그리고 클라이언트의 리스가 액세스 노드에 의해 연산 요청(5650)이 수신되는 때에서 X초 내에 만료하도록 설정되면, 묘사된 실시형태에서는 비-일괄 또는 즉각적 리스 갱신 요청(5653)이 발생될 수 있다. 그와 달리, 리스가 만료하도록 설정되어 있는 것 전에 X초보다 많이 남아 있으면, 클라이언트의 갱신 요청의 표현은 일괄 갱신 버퍼(5679)에 저장될 수 있고, 그리고 소정 수의 갱신은 추후 일괄 리스 갱신 요청(5654)으로 메타데이터 노드(5522)에 보내질 수 있다. 액세스 노드는 묘사된 실시형태에서 액세스 노드가 책임지고 있는 다양한 클라이언트 세션에 대한 리스 만료 시간을 세션 메타데이터 캐시(5578) 내에 캐싱하였을 수 있고, 즉각적 갱신 요청을 보낼지 아니면 일괄 갱신 요청을 보낼지에 관한 결정을 하도록 캐시 콘텐츠를 사용할 수 있다. 리스 갱신과 독립적으로, 액세스 노드는 (캐싱된 클라이언트 세션 메타데이터 및/또는 캐싱된 논리적-블록-대-물리적-페이지 매핑을 사용하여) 클라이언트를 대리하여 요청된 연산을 개시할 수 있고, 적합한 파일 스토어 연산 응답(5663)을 클라이언트(5502)에 제공할 수 있다.
소망 성능 레벨로 다양한 유형의 파일 스토어 연산을 수행하기 위해, 파일 스토어 객체에 대한 로크 상태 정보의 저장에 대한 수 개의 접근법 중 어느 것이라도 채용될 수 있다. 도 57a 및 도 57b는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 세션-지향형 파일 시스템 프로토콜에 대해 로크 상태 관리에 대한 대안의 접근법을 예시한다. 도 57a에 예시된 하나의 접근법에서, 특정 파일 시스템의 로크 상태 표시자(5705)는 다수의 익스텐트 간 분산될 수 있다. 이러한 접근법의 일부 구현에서, 다양한 파일 스토어 객체에 대한 로크 및/또는 열림 상태 정보를 포함하고 있는 LSI는 엔트리에 대해 유지되고 있는 다른 유형의 메타데이터, 예를 들어, 대응하는 이름공간 DFS-디렉터리엔트리(이름공간 엔트리), DFS-아이노드, 및/또는 파일 시스템의 객체에 대한 논리적-블록-대-물리적-페이지 매핑과 함께 저장될 수 있다. 그리하여, 예를 들어, 루트 디렉터리에 대한 LSI(5705A)는 특정 익스텐트의 하나 이상의 논리적 블록에서 루트 디렉터리에 대한 다른 메타데이터(5704A)와 저장될 수 있고, 디렉터리(D1)에 대한 LSI(5705B)는 다른 익스텐트에서 디렉터리(D1)에 대한 다른 메타데이터(5704B)와 저장될 수 있고, 등이다. 유사하게, 각각의 열림/로크 상태 정보 엔트리(5705C, 5705D, 5705E, 5705F)는 각각 디렉터리(D2), 디렉터리(D3), 파일(F1), 및 파일(F2)에 대한 각각의 논리적 블록에 저장될 수 있다. 도 57b에 예시된 제2 접근법에서, 소정 파일 시스템의 모든 객체에 대한 열림/로크 상태 정보는 통합형 방식으로, 예를 들어, 단일 메타데이터 익스텐트(5754) 내에 저장될 수 있다. 예를 들어 세션 실효 연산에 대해, 소정 클라이언트 세션에 대한 모든 LSI 엔트리를 룩업할 때, 도 57a에 예시된 분산형 접근법이 사용되면 다수의 익스텐트가 액세스되어야 할 수 있는 한편, 도 57b에 예시된 통합형 접근법이 사용되면 하나 또는 적은 수의 익스텐트만이 요구될 수 있다. 그렇지만, 일부 상황 하에서는, 예를 들어, LSI가 파일 스토어 객체의 파퓰레이션이 변함에 따라 삭제될 수 있기 때문에, 그리고/또는 소정 파일 시스템에 대한 로크/열림 상태 정보에 결국 요구되는 저장의 양은 파일 시스템이 생성되고 그리고 그 LSI에 대한 익스텐트가 획득되는 때 예측하기가 용이하지 않을 수 있기 때문에, 분산형 접근법보다 통합형 접근법이 더 불량한 자원 이용을 초래할 수 있다.
도 58은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 수행될 수 있는 클라이언트 세션 메타데이터 관리 연산의 태양을 예시하는 순서도이다. 요소(5801)에서 제시된 바와 같이, 클라이언트 세션을 초기화 또는 생성하라는 요청은 NFS 또는 SMB와 같은 상태 기반 또는 세션-지향형 파일 시스템 프로토콜을 지원하는 분산형 저장 서비스의 액세스 서브시스템 노드에서 클라이언트로부터 수신될 수 있다. 일부 구현에서는, NFS 클라이언트ID설정 API와 유사한 명시적 세션 초기화를 요청하는 API가 클라이언트에 의해 사용될 수 있다. 다른 구현에서, 세션을 확립하라는 요청은 묵시적일 수 있다, 예를 들어, 하나가 이미 존재하지 않으면, open() API가 클라이언트로부터 인보크되는 것에 응답하여, 세션이 초기화될 수 있다. 일부 구현에서 세션 요청은 특정 클라이언트의 아이디(예를 들어, 하나 또는 클라이언트 프로세스들이 실행되고 있는 호스트의 호스트 이름 및/또는 IP 주소로부터 유도된 값)는 물론 고유 단일-사용-전용 검증자 값도 포함할 수 있다. 클라이언트 프로세스가 존재하고 재시작되어야 하면, 또는 클라이언트 프로세스가 실행된 호스트 또는 컴퓨트 인스턴스가 리부팅되면, 적어도 일부 실시형태에서는 새로운 세션이 초기화되어야 할 수 있고, 그리고 대응하는 세션 초기화 요청에서 다른 검증자가 저장 서비스에 공급될 수 있다.
묘사된 실시형태에서, 분산형 저장 서비스의 메타데이터 서브시스템은 하나 이상의 익스텐트에서의 영속적 저장소에서 클라이언트 세션 정보를 저장하는 것을 책임지고 있을 수 있는 한편, 액세스 서브시스템은, 예를 들어 액세스 노드에서 휘발성 메모리 및/또는 로컬 영속적 저장소에, 세션 상태 정보를 캐싱하도록 구성될 수 있다. 세션 요청을 수신하는 것에 응답하여, 액세스 노드는 세션 식별자에 대한 요청을, 예를 들어 클라이언트의 세션 요청의 내부 버전으로, 선택된 메타데이터 노드에 송신할 수 있다(요소(5804)). 메타데이터 노드는 일부 실시형태에서 클라이언트의 식별 정보에 기반하여 선택될 수 있다 - 예를 들어, 일 실시형태에서 2개의 다른 메타데이터 노드(MN1, MN2)는 클라이언트(Cl1, Cl2)에 대해 확립될 각각의 클라이언트 세션에 대해 선택될 수 있다. 선택된 메타데이터 노드는, 예를 들어, 세션에 대한 리스 설정, 클라이언트의 신원, 클라이언트 세션에 대해 책임지고 있는 액세스 노드의 신원 등을 포함하는, 저장될 클라이언트 세션 메타데이터의 다양한 요소에 대한 (앞서 설명된 매핑 기술 중 하나를 사용하여 메타데이터 익스텐트에서의 소정 수의 물리적 페이지에 매핑되는) 논리적 블록을 할당할 수 있다(요소(5807)). 적어도 일부 실시형태에서, 세션 식별자(예를 들어, NFS 클라이언트ID)는 세션 메타데이터가 저장되는 주소에 적어도 부분적으로 기반하여 새로운 세션에 대해 결정될 수 있다 - 예를 들어, 논리적 블록 주소 또는 물리적 페이지 주소는 세션 식별자 내에 편입되거나 그것으로서 사용될 수 있다. 묘사된 실시형태에서 세션 식별자 및 초기 리스 설정은 메타데이터 노드로부터 액세스 노드로 제공될 수 있다(요소(5810)). 일부 실시형태에서는, 세션 식별자만이 액세스 노드에 제공될 수 있고, 그리고 액세스 노드는 판독 요청에서 파라미터로서 세션 식별자의 적어도 일부를 사용하여 저장 서브시스템으로부터 세션 메타데이터의 다른 요소를 검색할 수 있을 수 있다.
세션 식별자 및 리스 정보는 액세스 노드에 의해 세션 메타데이터 캐시에 캐싱될 수 있고, 그리고 세션 식별자는 클라이언트에 반환될 수 있다(요소(5813)). 클라이언트는 후속 파일 스토어 연산 요청에, 예를 들어, 파일 시스템의 파일 또는 디렉터리로 지향된 open(), read(), write(), getattribute(), 또는 close() 호출에 파라미터로서 세션 식별자를 포함할 수 있다. 액세스 노드가 그러한 연산 요청을 수신할 때, 그것은, 예를 들어 클라이언트의 세션이 아직 열려 있음을 검증하기 위해, 그 로컬 캐시에서 세션 정보를 룩업할 수 있다.
묘사된 실시형태에서의 소정 유형의 연산, 예를 들어, 파일로 지향된 기록 연산에 대해, 사용 중인 파일 시스템 프로토콜의 병행 관리 기술에 따라 로크가 요구될 수 있다. 파일 스토어 객체(F1)로 지향된 기록 또는 판독과 같은, (세션 식별자를 포함하는) 소정 파일 시스템 연산 요청을 수신시, 액세스 노드는 그러한 로크가 필요한지 결정할 수 있다(요소(5816)). 로크가 필요하고 액세스 노드에서 이미 캐싱되어 있지 않으면, 연산 요청의 대응하는 내부 버전은 액세스 노드로부터 메타데이터 노드로 송신될 수 있다(요소(5819)). 메타데이터 노드는 (예를 들어, F1이 다른 클라이언트를 대리하여 이미 로킹되어 있기 때문에) 상충하는 로크 상태 표시자가 이미 존재하는지 결정할 수 있다. (요소(5820)에서 결정되는 바와 같이) 그러한 상충하는 로크가 발견되면, 예를 들어 표적 객체가 이미 로킹되어 있음을 표시하는 오류 메시지를 보냄으로써, 클라이언트의 파일 시스템 연산 요청은 거절될 수 있다(요소(5821)). 상충이 발견되지 않으면, 메타데이터 노드는, 예를 들어 대응하는 로크 상태 표시자를 포함하는, F1에 대한 상태 정보를 저장하는데 사용될 논리적 블록에 대한 영속적 저장 장소를 결정할 수 있다(요소(5822)). 예를 들어, 일부 실시형태에서, 도 57a 및 도 57b에 예시된 기술 중 하나는 F1에 대해 저장될 로크 상태 표시자 및/또는 다른 상태 메타데이터에 대한 공간을 할당하도록 사용될 수 있다. 상태 정보는 영속적 저장 장소에서 저장될 수 있고(요소(5825)), 그리고 로크 상태 표시자를 포함하는 상태 메타데이터의 적어도 일부는 액세스 노드에 제공될 수 있다.
요청된 연산(예를 들어, F1으로 지향된 판독 또는 기록)은, 예를 들어 액세스 노드에 의해서든 메타데이터 노드에 의해서든 저장 서브시스템으로 지향된 내부 I/O 요청의 결과로서, 완료될 수 있고, 그리고 대응하는 응답은 클라이언트에 보내질 수 있다. 액세스 노드는 로크 상태 표시자를 그 세션 메타데이터 캐시에 추가하고 그 캐싱된 로크 상태 표시자, 캐싱된 리스 설정 및/또는 캐싱된 세션 식별자를 사용하여, 예를 들어 후속 요청 중 적어도 일부에 대해 메타데이터 서브시스템과의 상호작용을 요구함이 없이, 세션 요소(5828) 동안 클라이언트로부터의 후속 요청에 응답할 수 있다. 세션이 만료하면 그리고 그때, 묘사된 실시형태에서 그 메타데이터는 메타데이터 노드의 요청시 할당된 영속적 저장소로부터도 그리고 액세스 노드의 캐시로부터도 삭제될 수 있다(요소(5831)). 일부 파일 시스템 프로토콜에 따라, 세션-관련 메타데이터의 적어도 일부는 또한 서비스의 클라이언트-측 컴포넌트, 예를 들어, 파일 저장 서비스를 이용하는 애플리케이션이 실행되는 호스트에서 인스턴스화된 데몬에 제공되고 그리고/또는 거기에서 캐싱될 수 있음을 주목한다.
도 59는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 수행될 수 있는 클라이언트 세션 리스 갱신 연산의 태양을 예시하는 순서도이다. 앞서 설명된 바와 같이, 리스는 저장 서비스로부터 클라이언트에 파일, 디렉터리 또는 다른 클라이언트-액세스가능한 저장 객체 세트의 상태의 제어의 시간-구속 승인을 표현할 수 있다. 요소(5901)에서 제시된 바와 같이, 자동 리스 갱신을 초래하는 연산의 카테고리에 속하는 파일 스토어 연산 요청(OR1)은 클라이언트 세션(CS1) 동안 저장 서비스의 액세스 노드에서 클라이언트(Cl1)로부터 수신될 수 있다. 예를 들어, NFS와 같은 세션-지향형 파일 시스템의 특정 파일로 향하여 지향된 판독, 기록, 열기 또는 닫기 요청이 수신될 수 있다. 다양한 실시형태에서 여러 다른 파일 시스템 프로토콜은 각각의 리스-갱신 연산 세트를 정의할 수 있다. 도 59에 예시된 나머지 연산은 또한 적어도 일부 실시형태에서는 명시적 리스 갱신 커맨드에 응답하여 수행될 수 있다. 요청은, 액세스 노드의 세션 메타데이터 캐시에서의 메타데이터 레코드에 대한 인덱스 값으로서 사용가능할 수 있는, 클라이언트의 세션 식별자(예를 들어, NFS 클라이언트ID)를 포함할 수 있다.
액세스 노드는, 예를 들어 세션 메타데이터 캐시에서, 클라이언트 세션에 대해 (예를 들어, 리스가 만료하도록 설정될 때) 리스 정보를 룩업할 수 있다(요소(5904)). (요소(5907)에서 결정되는 바와 같이) 리스가 소정 임계 시간 간격(T) 내에 만료하기로 되어 있으면, 액세스 노드는 CS1에 대한 즉각적 리스 갱신 요청을 메타데이터 노드에 송신할 수 있다(요소(5913)). 그렇지만, 리스가 임계 시간 간격(T) 후에 만료하기로 되어 있으면, CS1에 대한 리스 갱신 요청은 일괄로 메타데이터 노드에 보내지도록 계류 중인 리스 갱신 요청의 버퍼링된 세트에 추가될 수 있다. 저장 연산이 수행될 것을 연산 요청(OR1)이 요구하면(예를 들어, 요청이 액세스 노드에서 이미 캐싱된 데이터 또는 메타데이터에 의해 충족될 수 없으면), 즉각적 갱신 요청이 보내졌는지 여부에 무관하게, 저장 연산이 액세스 노드에 의해 요청될 수 있다(요소(5916)). CS1의 리스 갱신 요청이 버퍼링되는 시나리오에서, 버퍼링된 리스 갱신 요청 중 하나 이상은 연산 요청(OR1)에 대해 비동기식으로 메타데이터 노드에 송신될 수 있다(요소(5919)).
리스 갱신 요청에 대한 버퍼링 기술이 구현되는 적어도 일부 실시형태에서는, 메타데이터 노드의 요청시 저장된 세션 메타데이터의 영속적 버전에 대해 설정되는 것과는 다른 유효성 타임아웃이 (예를 들어 세션의 LSI 및 세션 식별자를 포함하는) 액세스 노드에서 캐싱되는 세션 메타데이터의 버전에 대해 설정 또는 구성될 수 있다. 예를 들어, 일 구현에서, 리스 타임아웃이 파일 시스템 프로토콜 설정에 따라 90초로 설정되면, 120초의 유효성 타임아웃이 메타데이터 서브시스템에서의 영속적 세션 메타데이터 레코드에 대해 사용될 수 있는 한편, (예를 들어, 메타데이터 서브시스템의 유효성 타임아웃과 프로토콜의 리스 타임아웃 간 차이에 적어도 부분적으로 기반하는) 30초의 유효성 타임아웃이 액세스 노드의 캐시에서의 대응하는 레코드에 대해 설정될 수 있다. 그러한 다른 타임아웃 조합을 사용하여, 액세스 노드에서의 잠재적 실패 또는 지연 중 적어도 일부 유형이 클라이언트가 그들 리스의 이점을 조기에 상실하게 야기함이 없이 수용될 수 있다. 예를 들어, 위에서 도입된 예의 타임아웃 설정으로, 액세스 노드는 어느 경우에라도 메타데이터 서브시스템으로부터 30초마다 한 번씩 그 캐싱된 리스 정보를 리프레시하도록 요구될 것인 한편, 클라이언트의 실제 리스는 90초 동안 유효하므로, 수 초의 일괄 지연(예를 들어, 대체 노드로 액세스 노드의 페일오버에 의해 야기된 30초 미만의 지연)은 전형적으로는 프로토콜 리스 시맨틱스의 어느 위반도 초래할 것으로 예상되지 않을 것이다. 리스-갱신 연산이 아주 빈번하게 일어날 것으로 예상될 수 있으므로, 그러한 구현에서 액세스 노드의 더 짧은 유효성 타임아웃이 액세스 노드와 메타데이터 서브시스템 간 가외 트래픽을 초래할 확률은 아주 낮게 유지될 수 있다. 일반적으로 판독-수정-기록 시퀀스에서의 조건부 기록, 분산형 트랜잭션, 및/또는 복제 상태 머신의 사용과 같은, 앞서 설명된 기술 중 적어도 일부는 또한 클라이언트 세션-관련 메타데이터를 관리하는데 역시 사용될 수 있음을 주목한다. 예를 들어, 일 구현에서, 클라이언트 세션 리스가 만료하고 그리고 서비스의 다양한 노드들 간 분산된 복수의 세션-연관된 로크 상태 표시자가 삭제되어야 할 때, 분산형 트랜잭션이 사용될 수 있다.
시도 카운트를 사용하는
커넥션
밸런싱
수천 노드를 포함할 것으로 예상된 그리고 수만 또는 수십만 병행 클라이언트 요청을 취급할 것으로 예상된 일부 분산형 저장 시스템에서, 클라이언트 작업부하를 부하 밸런싱하는 것은 목표 성능 및 자원 이용 목표를 달성하는데 필수적일 수 있다. 적어도 일부 제공자 네트워크 환경에서, 부하 밸런싱 노드의 집합은 다양한 서비스와 그 서비스를 이용하기를 바라는 클라이언트 간 중개자로서 확립될 수 있다. 일부 실시형태에서, 그러한 중개 부하 밸런싱 계층은 분산형 저장 서비스의 액세스 서브시스템과 클라이언트 디바이스 간 확립될 수 있다. 분산형 저장 서비스로 클라이언트를 대리하여 확립된 (NFS 마운트 커넥션과 같은) 네트워크 커넥션은 전형적으로 아주 장수할 수 있고, 그 결과 작업부하 밸런싱의 문제는 사용자 세션이 전형적으로는 더 짧은 환경(예를 들어, 웹 서버 환경의 일부 유형)에서보다 더 복잡하게 될 수 있다. 여러 다른 기술이 분산형 저장 서비스 액세스 노드의 작업부하 레벨을 관리하는데 사용될 수 있으며, 예를 들어, 특정 클라이언트를 대리하여 커넥션을 확립하도록 이전에 행해졌던 성공하지 못한 시도의 수를 고려하는 아래에서 설명되는 커넥션 밸런싱 기술을 포함한다. 일부 실시형태에서, 커넥션은, 아래에서 또한 설명되는 바와 같이, 소정 작업부하 조건 하에서는 액세스 노드에 의해 자발적으로 종결될 수 있다.
도 60은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에 대해 부하 밸런서 계층이 구성되는 시스템을 예시한다. 묘사된 실시형태에서, 부하 밸런서 계층(6090)은 제공자 네트워크(6002)의 자원을 사용하여 구현된, 노드(6070A, 6070B, 6070C)와 같은, 복수의 부하 밸런서 노드(LBN)(6070)를 포함한다. 분산형 저장 서브시스템의 액세스 서브시스템(6010)은, AN(6012A, 6012B, 6012C)을 포함하는 AN 피어 그룹(6060A) 및 AN(6012K, 6012L, 6012M)을 포함하는 AN 피어 그룹(6060B)과 같은, 복수의 액세스 노드(AN) 피어 그룹(6060)을 포함한다. AN 피어 그룹의 멤버는, 더 상세히 아래에서 설명되는 바와 같이, 적어도 일부 실시형태에서 커넥션 리밸런싱 연산을 위해 서로 협업할 수 있다. AN 피어 그룹(6060)의 멤버는 여러 다른 실시형태에서 다양한 기준의 어느 조합에라도 기반하여 - 예를 들어, (예를 들어, 단일 로컬라이징된 전력 불능 또는 다른 기반구조 불능이 AN 그룹의 모든 멤버에서 실패를 야기하지 않게 되도록) 액세스 서브시스템의 가용성 요건, (예를 들어, 그룹의 여러 다른 멤버가 유사한 레이턴시 레벨을 지원할 수 있게 되도록) 레이턴시 요건, (AN 피어 그룹에 의해 집합적으로 취급될 수 있는 총 처리율이 소정 소망 최소치 위에 있게 되도록) 성능 용량 요건에 기반하여 저장 서비스의 복수의 액세스 서브시스템 노드 중으로부터 선택될 수 있다. 일부 구현에서, AN 피어 그룹은 단일 랙에 탑재된 하드웨어 서버 상에서 모두 구현되는 복수의 액세스 노드를 포함할 수 있다. 다른 구현에서, AN 피어 그룹 경계는 랙 경계와 일치하지 않을 수 있다; 대신에, 공유된 네트워크 주소 프리픽스, 장애에 대한 허용성 또는 취급되는 파일 스토어의 유형/수와 같은 다른 인자가 피어 그룹을 정의하는데 사용될 수 있다.
적어도 일부 실시형태에서는, 프로토콜 중 TCP/IP(전송 제어 프로토콜/인터넷 프로토콜) 패밀리가 클라이언트(180)와 저장 서비스 간 통신에 사용될 수 있다. 클라이언트(180)는 저장 서비스에 액세스하기 위한 종단점으로서 네트워크 주소(예를 들어, 가상 IP 주소)가 노출된 LBN(6070)에 커넥션 확립 요청을 송신할 수 있다. 여러 다른 실시형태에서 다양한 유형의 물리적 또는 가상 네트워크(6022)가 클라이언트에 의해 사용될 수 있다. 일 실시형태에서, 앞서 설명된 바와 같이, (고립형 가상 네트워크의 일부분으로서 구성된 컴퓨트 인스턴스와 같은) 클라이언트 중 일부 또는 전부는 제공자 네트워크 내에서 호스트에서 인스턴스화될 수 있고, 그리하여 내부 네트워크를 사용하여 부하 밸런서 노드에 접속할 수 있다. 적어도 하나의 실시형태에서, 저장 서비스의 클라이언트 및 부하 밸런서 노드 양자는 (예를 들어, 별개 가상 머신으로서) 동일한 호스트에서 실행될 수 있으며, 그 경우 오프-호스트 네트워크 커넥션은 요구되지 않을 수 있다. 다른 실시형태에서는, 인터넷의 일부와 같은, 제공자 네트워크(6002) 외부의 네트워크의 일부가 사용될 수 있다. 일부 실시형태에서, 복수의 LBN은 저장 서비스와 연관된 단일 IP 주소로 지향된 트래픽에 응답하도록 구성될 수 있다. 일 구현에서, 특정 LBN(6070)은 우선 잠정적으로 클라이언트의 커넥션 확립 요청을 수락할 수 있고, 그리고 그 후 그 LBN(6070)은 제공자 네트워크(6002)의 네트워크 패브릭(6024)(예를 들어, L3 네트워크)을 통하여 액세스 노드(6012)로의 대응하는 내부 커넥션을 확립하려고 시도할 수 있다. 적어도 일부 실시형태에서, 아래에 설명되는 바와 같이, 소정 액세스 노드(6012)는 소정 작업부하 조건 하에서는 LBN에 의해 발행된 내부 커넥션 요청을 거절할 수 있고, 그리고 그 결과 LBN은 내부 커넥션을 확립하고자 하는 다른 액세스 노드(6012)를 발견하려고 시도할 수 있다. 일부 실시형태에서, 액세스 노드가 LBN의 요청을 수락 또는 거절하는데 사용하는 특정 기준은 LBN이 이미 한 성공하지 못한 시도의 수에 종속할 수 있다 - 예를 들어, 기준은, 커넥션 확립의 확률이 시도의 수에 따라 증가할 수 있도록, 성공하지 못한 시도의 수가 증가함에 따라 완화될 수 있다.
묘사된 실시형태에서, 각각의 AN(6012)은 2개의 서브컴포넌트를 포함한다: 로컬 부하 밸런서 모듈(LLBM)(6017)(예를 들어, LLBM(6017A, 6017B, 6017C, 6017K, 6017L, 6017M)), 및 액세스 매니저(AM)(6015)(예를 들어, AM(6015A, 6015B, 6015C, 6015K, 6015L, 6015M)). 커넥션 요청이 수락된 후에, 일부 실시형태에서, LLBM은 네트워크 패브릭(6024)을 통하여 클라이언트를 대리하여 LBN에 의해 보내진 캡슐화된 TCP 패킷을 수신할 것을 책임지고 있을 수 있다. 다양한 구현에서, LBN은 다른 프로토콜(예를 들어, 제공자 네트워크 내에서 내부적으로 사용된 소정 전유 프로토콜 또는 사용자 데이터그램 프로토콜(UDP))을 사용하여, 또는 TCP 자체를 사용하여 클라이언트의 TCP 패킷을 캡슐화할 수 있다 - 예를 들어, 클라이언트의 TCP 패킷(그 헤더를 포함함)은 LBN과 LLBM 간 송신을 위해 LBN TCP 패킷 내에 포함될 수 있다. LLBM은 로컬 AM과 연관된 TCP 프로세싱 스택에 패킷을 전하기 전에 패킷을 캡슐화-해제 또는 패킹해제할 수 있다. 일부 구현에서, LLBM은 TCP 프로세싱 스택에 전달 전에 TCP 시퀀스 번호와 같은 하나 이상의 클라이언트 패킷 헤더의 콘텐츠를 변경할 수 있다. 적어도 일부 실시형태에서, LBN과 LLBM의 조합에 의한 클라이언트 패킷의 조작(예를 들어, 캡슐화/패킹해제, 헤더 변경 등)은 패킷이 LBN 및 LLBM을 통하여서라기보다는 클라이언트(180)와 직접 확립된 TCP 커넥션 상에서 수신된 것처럼 그것이 TCP 프로세싱 스택에 보이게 할 수 있다. AM(6015)은, 예를 들어, 메타데이터 캐싱, 메타데이터 서브시스템(120) 및/또는 저장 서브시스템(130)과의 상호작용 관리 등을 포함하는, 저장 서비스 프론트-엔드 로직을 구현할 수 있다. 부가적으로, 일부 실시형태에서, AM(6015)은 추가적 커넥션을 수락하는 것에 관한 결정에 사용될 수 있는, CPU 메트릭, 네트워크 메트릭, 메모리 메트릭 등과 같은, AN의 다양한 자원의 로컬 작업부하 메트릭 세트를 수집할 수 있다. 일 실시형태에서, 피어 그룹(6060)의 여러 다른 피어의 AM은 아래에서 더 상세히 설명되는 바와 같이 그들 작업부하 레벨에 관하여 서로 질의할 수 있다.
적어도 일부 실시형태에 의하면, 시도 카운트 파라미터를 포함하는 커넥션 요청이 클라이언트(180)를 대리하여 LBN(6070)으로부터 액세스 노드(6012)에서 수신될 수 있다. 시도 카운트 파라미터는 부하 밸런서 컴포넌트가 그 특정 클라이언트(180)를 대리하여 커넥션을 확립하려고 시도하였던 횟수를 표시할 수 있다. 일 실시형태에서, 클라이언트는 파일 시스템을 마운트하라는 요청(예를 들어, 그리고 NFS 마운트 커맨드)을 제출할 수 있고, 그리고 LBN은 마운트 커맨드를 수신하는 것에 응답하여 그 커넥션 요청을 발생시킬 수 있다; 결과로서 확립된 커넥션은 "마운트 커넥션"이라고 칭해질 수 있고 동일한 클라이언트로부터의 수 개의 후속 요청에 사용될 수 있다. 다른 실시형태에서는 다른 저장 서비스 커맨드 또는 요청(즉, 마운트 요청 이외의 요청)이 커넥션 확립 요청을 또한 또는 대신 트리거링할 수 있다. 커넥션 요청을 수신시, AN은 커넥션 요청에 관한 수락 결정에 사용될 하나 이상의 작업부하 임계 레벨(예를 들어, 복수의 자원에 대한 각각의 임계 레벨(Th1, Th2, ...))을 식별할 수 있다. 임계 레벨 중 적어도 하나는 일부 실시형태에서는 시도 카운트 파라미터에 기반할 수 있다 - 예를 들어, 제1 시도에 대해, CPU 작업부하 임계치는 Tc일 수 있는 한편, 제2 시도에 대해, CPU 작업부하 레벨은 (Tc+delta)로 설정될 수 있어서, 제2 시도시 커넥션이 수락되는 것을 더 개연성 있게 한다. 일례의 시나리오에서, 임계 레벨(Tc)이 CPU 작업부하에 대해 식별되고 그리고 임계 레벨(Tn)이 네트워크 작업부하에 대해 식별되면, 커넥션은 AN의 CPU 작업부하 메트릭이 Tc 아래에 있고 그리고 네트워크 작업부하 메트릭이 Tn 아래에 있으면 수락될 수 있다. 다른 시나리오에서, 커넥션은 CPU 작업부하 메트릭이든 네트워크 작업부하 메트릭이든 대응하는 임계치 아래에 있으면 수락될 수 있다. 임계치와의 비교에 사용되는 작업부하 메트릭은, 예를 들어 커넥션 수락 결정에 대해 단기 작업부하 요동의 충격을 감축하기 위해, 아래에서 논의되는 바와 같이 일부 실시형태에서는 소정 시간 간격에 걸쳐 컴퓨팅될 수 있다.
액세스 서브시스템 노드의 로컬 작업부하 메트릭 또는 메트릭들이 대응하는 작업부하 임계 레벨 아래에 있다는 결정에 응답하여, 커넥션이 수락된다는 표시가 요청하는 LBN(6070)에 제공될 수 있다. 커넥션 요청도 그리고 수락 표시도 LBN과 LLBM 간 통신에 사용되는 특정 프로토콜(예를 들어, UDP, TCP 또는 어떤 다른 프로토콜)에 따라 포맷팅될 수 있다. 일부 실시형태에서, LBN(6070)은 커넥션이 AN에 의해 수락되었음을 클라이언트에 확인해 줄 수 있다. LBN에 의해 선택된 AN(6012)이 커넥션을 수락할 수 없으면(예를 들어, 로컬 작업부하 메트릭이 식별된 임계치 위에 있으면), 커넥션 거절 메시지가 LBN에 보내질 수 있다. 그 후 LBN은 (시도 카운트 파라미터가 증분된) 그 요청을 다른 AN에 송신할 수 있고, 그리고 이러한 프로세스는, 커넥션이 성공적으로 확립되든 시도 수가 허용된 소정 최대 시도 수를 초과하든지 할 때까지, 도 61에 예시되고 아래에서 설명되는 바와 같이 반복될 수 있다.
커넥션이 성공적으로 확립된 후에, LBN(6070)이 저장 서비스 요청을 표시하는 클라이언트-발생된 패킷을 수신할 때, LBN은 (예를 들어, 캡슐화된 포맷으로) 패킷을 액세스 서브시스템 노드에서의 LLBM에 송신할 수 있다. LLBM은 (예를 들어, 원래 클라이언트-발생된 패킷을 패킹해제하도록) LBN으로부터 수신된 메시지의 콘텐츠를 조작하고, 원래 패킷을 프로세싱을 위해 AM(6015)에 전할 수 있다. 저장 요청에 응답하여 수행되어야 하는 연산의 본성에 종속하여, 일부 경우에서, AM은 메타데이터 서브시스템(120)과든, 저장 서브시스템(130)과든, 양 백-엔드 서브시스템과든 연락해야 할 수 있다. 저장 서비스 요청의 표시는 적합한 서브시스템(들)에 송신될 수 있다. 클라이언트의 서비스 요청이 응답을 요구하면, 응답은 반대 방향으로 - 예를 들어, 백-엔드 서브시스템(들)으로부터 AN으로, AN으로부터 LBN을 통하여 클라이언트로 흐를 수 있다. 들어오는 패킷이 LBN에 의해 캡슐화되고 LLBM에 의해 언패킹되는 적어도 일부 실시형태에서, LLBM은 나가는 패킷을 유사하게 캡슐화할 수 있고 그리고 LBN은 패킷을 클라이언트(180)에 전하기 전에 그것을 언패킹할 수 있다.
도 61은, 적어도 일부 실시형태에 따라, 분산형 저장 서비스의 복수의 액세스 서브시스템 노드와 부하 밸런서 노드 간 상호작용례를 예시한다. 묘사된 실시형태에서, 가상 IP 주소(6105)(예를 들어, 예를 들어 제공자 네트워크의 가상 컴퓨팅 서비스의 여러 다른 컴퓨트 인스턴스에서, 여러 다른 네트워크 인터페이스와 동적으로 연관될 수 있고 단일 네트워크 인터페이스에 구속되지 않는 IP 주소)는 클라이언트가 커넥션 요청 및 다른 저장 서비스 요청을 저장 서비스에 제출 가능하게 하도록 노출될 수 있다. 하나 이상의 LBN(6070)은 어느 소정 시간에서라도 가상 IP 주소로 지향된 트래픽을 수락하는 것을 책임지고 있을 수 있다. 적어도 일부 실시형태에서, LBN(및/또는 AN)은 컴퓨트 인스턴스를 사용하여 구현될 수 있다 - 예를 들어, 소정 LBN은, 상품 하드웨어 서버에서 론칭된, 제공자 네트워크의 가상 컴퓨팅 서비스의 컴퓨트 인스턴스에서 실행되는 프로세스를 포함할 수 있다. 클라이언트는 커넥션 확립 요청(6108)을 가상 IP 주소(6108)에 제출할 수 있다.
묘사된 실시형태에서, LBN(6070)은 클라이언트의 요청을 수신하고, 대응하는 내부 커넥션 요청을 그것이 보내야 하는 제1 AN으로서 특정 AN(6012B)을 선택할 수 있다. 여러 다른 기술이 AN을 선택하는데 사용될 수 있다 - 예를 들어, 일부 실시형태에서는 무작위 선택이 사용될 수 있고, 다른 실시형태에서는 라운드-로빈 선택이 사용될 수 있고, 등이다. 일부 실시형태에서, 각각의 LBN은 (가용성, 레이턴시, 용량, 또는 앞서 언급된 다른 기준에 기반하여 정의된 하나 이상의 AN 피어 그룹과 같은) AN 세트와 연계될 수 있고, 그리고 LBN은 그 커넥션 시도에 대해 지정된 순서로 그 연계된 AN들을 순환할 수 있다. 일부 실시형태에서, 소정 수의 LBN 및 소정 수의 AN 양자는 동일한 랙에 위치하고 있을 수 있고, 그리고 LBN은 우선 그 자신의 랙 내로부터 AN을 선택할 수 있다. LBN은, 예를 들어 시도 카운트 파라미터가 묘사된 실시형태에서는 1로 설정된, 제1 커넥션 시도(6132A)를 선택된 AN(6012B)에서의 LLBM(6017B)에 제출할 수 있다. (시도 카운트 파라미터는 일부 구현에서 제1 시도에 대해 영으로 설정될 수 있다). 요청의 수락 또는 거절에 관한 결정은, 여러 다른 실시형태에서, 표적 AN에서의 AM(6015)에 의해서든, 표적 AN에서의 LLBM에 의해서든, 또는 표적 AN에서의 AM과 LLBM의 조합에 의해서든 이루어질 수 있다.
연락된 제1 AN이 (예를 들어, 하나 이상의 로컬 작업부하 메트릭(6115B)이 대응하는 임계치를 초과한다는 것에 적어도 부분적으로 기반하여) 거절(61234A)을 LBN에 보내면, LBN은 제2 AN(묘사된 예에서는 AN(6012A))을 선택할 수 있다. LBN(6070)은, 증분된 시도 카운트 파라미터를 갖는, 제2 커넥션 요청 시도(6132B)를 제2 AN에서의 LLBM(6017A)에 제출할 수 있다. (예를 들어, AN(6012A)의 로컬 작업부하 메트릭(6115A)에 기반하여) 거절(6134B)이 재차 수신되면, LBN(6070)은 제3 AN(6012C)을 선택하고, 제3 시도(6132C)를 그 LLBM(6017C)에 제출할 수 있다. 묘사된 예의 시나리오에서, 제3 AN(6012C)은 그 로컬 작업부하 메트릭(6115C)의 분석에 기반하여 수락(6136)을 회신하고, 그리고 그에 따라 커넥션이 AM(6015C)과 클라이언트(180) 간 확립된다. 커넥션의 성공적인 확립 후에, 저장 서비스와 클라이언트(180) 간 네트워크 패킷은 묘사된 실시형태에서는 경로(6157)를 따라 흐른다. 예를 들어, 클라이언트는 패킷을 LBN(6070)에 보낼 수 있고, LBN은 패킷을 (잠재적으로는 캡슐화되거나 수정된 표현을 사용하여) LLBM(6017C)에 보낼 수 있고, LLBM의 패킷 조작기(6155)는 수신된 패킷을 언패킹 또는 수정하고, 조작의 출력을 AM(6015C)에 보낼 수 있다. 그 후 AM(6015C)은, 메타데이터 및/또는 저장 서브시스템과의 상호작용을 수반할 수 있는, 요구되는 저장 연산을 개시할 수 있다.
도 62는, 적어도 일부 실시형태에 따라, 행한 커넥션 시도의 수에 따라 달라질 수 있는 커넥션 수락 기준의 예를 예시한다. 묘사된 실시형태에서, 소정 자원에 대해, (CPU 또는 네트워크 대역폭과 같은) 그 자원에 대한 AN의 네이티브 또는 베이스라인 용량(6202)은 커넥션 수락 결정에 사용될 조절된 용량(AC)(6206)에 이르도록 장애 오버헤드 인자(6204)에 의해 수정될 수 있다. 예를 들어, AN의 네이티브 CPU 능력이 초당 X개의 연산이면, 일 시나리오에서, 그 용량의 1/5(0.2X)은 다양한 종류의 장애의 경우에 일어날 수 있는 일시적 작업부하 증가를 보상하도록 따로 떼어 둘 수 있다. 그리하여, 그러한 시나리오에서, 조절된 CPU 용량은 초당 0.8X(X - 0.2X)개의 연산으로 설정될 것이다.
AN에서의 소정 자원에 대해 수집된 로컬 작업부하 메트릭은 단기 변동은 물론 장기 추세도 나타내 보일 수 있다. (NFS에 대해 셋업된 마운트 커넥션과 같은) 저장 서비스 연산에 대해 확립된 커넥션은 전형적으로 오래-지속될 수 있으므로, 단지 가장 최근 메트릭 단독 기반으로 커넥션을 수락/거절하는 것은 바람직하지 않을 수 있다. 따라서, 조절된 부하 메트릭(AL)(6216)이 가장 최근 메트릭(6212)과 소정 세트의 이력 메트릭(6214)(예를 들어, 마지막 15분 또는 한 시간에 걸쳐 그 자원에 대해 수집된 메트릭)의 조합으로부터 획득될 수 있다. 일부 실시형태에서는, 예를 들어 시간의 흐름에 따른 메트릭의 중요도에서의 감축을 표현 또는 모델링하기 위해, 조절된 부하를 컴퓨팅할 때 이력 메트릭에 감쇠 함수(6215)(예를 들어, 지수함수형 감쇠 또는 선형 감쇠)가 적용될 수 있다.
AN에서 특정된 시도 카운트 파라미터를 갖는 커넥션 요청을 수락하기 위해, 소정 자원에 대한 조절된 부하(6216)는 시도 카운트에 종속하는 (그 자원에 대한 조절된 용량의 항으로 표현된) 임계치에 비교될 수 있다. 그리하여, 커넥션 수락 기준 테이블(6255)에서 표시된 바와 같이, 시도 카운트 파라미터가 1과 같은 커넥션 요청은 고려되고 있는 자원에 대한 AL이 0.5*AC보다 작거나 같으면 수락될 수 있다. 커넥션 요청이 한 번 실패하였고, 그에 따라 시도 카운트가 2로 설정되면, 커넥션은 AL이 0.55*AC보다 크지 않으면 수락될 수 있다. 시도 카운트 값 3에 대해, 수락 기준은 AL이 0.6*AC보다 크지 않으면 커넥션이 수락되도록 더 완화될 수 있고; 시도 카운트 = 4에 대해, AL은 0.75*AC보다 크지 않아야 할 수 있고, 그리고 시도 카운트 5에 대해, AL은 0.85*AC보다 크지 않아야 할 수 있다. 그리하여, 묘사된 실시형태에서는 커넥션이 거절되는 횟수가 더 많을수록, 그것을 결국 수락하는 AN은 더 과중한 부하가 걸릴 수 있게 허용될 수 있다. 다른 실시형태에서는, 시도 카운트(K)를 갖는 커넥션 요청을 수락하기 위해, 수락하는 노드의 작업부하 레벨은 더 낮은 시도 카운트(K-L)를 갖는 커넥션 요청을 수락하는데 요구되는 작업부하 레벨보다 더 낮아야 할 수 있는 반대 접근법이 사용될 수 있다. 시도 카운트가 증가함에 따라 커넥션의 수락의 상대적 용이함이 감소하는 그러한 접근법은, 예를 들어, 새로운 커넥션 시도가 과중한 부하 조건 하에서 단념되어야 하는 시나리오에서 사용될 수 있다. 적어도 일부 실시형태에서, 임계 조건은 물론, AC 및 AL의 컴퓨터계산에 사용된 파라미터 및 함수(예를 들어, 감쇠 함수)도 모두 구성가능한 설정일 수 있다. 수락 기준이 정의되는 구별되는 시도 카운트 값의 수는 여러 다른 실시형태에서 달라질 수 있고, 적어도 일부 실시형태에서는 자체가 구성가능한 파라미터일 수 있다. 일부 실시형태에서, 파라미터, 함수 및/또는 임계치는, 예를 들어 달성된 결과의 분석에 기반하여, 시간의 흐름에 따라 동적으로 수정될 수 있다. 적어도 일부 실시형태에서, 수락 기준 중 일부는 소정 범위의 시도 카운트 값에 대해 동일할 수 있다 - 예를 들어, 시도 카운트 1 및 2에 대해 동일한 임계 값이 사용될 수 있다.
일부 실시형태에서는, 위에서 언급된 바와 같이, 하나보다 많은 자원과 연관된 로컬 작업부하 레벨이 커넥션 수락 결정을 할 때 고려될 수 있다. 도 63은, 적어도 일부 실시형태에 따라, 커넥션 확립 시도 카운트에는 물론, 복수의 자원과 연관된 작업부하 레벨에도 종속할 수 있는 커넥션 수락 기준의 예를 예시한다. 조절된 부하 레벨 및 대응하는 조절된 용량의 5개의 예가 어레이(6312)에 제시되어 있다. AL[CPU]는 액세스 노드의 조절된 CPU 작업부하를 표현하는 한편, AC[CPU]는 조절된 CPU 용량을 표현한다. AL[Net]은 조절된 네트워크 부하를 표현하고, 그리고 AC[Net]은 조절된 네트워크 용량을 표현한다. AL[Mem]은 조절된 메모리 부하를 표현하고, 그리고 AC[Mem]은 조절된 메모리 용량을 표현한다. AL[Dsk]는 액세스 노드에서의 조절된 로컬 저장 디바이스 용량 부하를 표현하고, 그리고 AC[Dsk]는 조절된 저장 디바이스 용량을 표현한다. 적어도 일부 실시형태에서, 조절된 부하 및 용량은 또한 액세스 노드에서의 운영 체제 구조에 의해 표현되는 오픈 소켓과 같은 논리적 자원에 대해 결정될 수 있다. 그러한 운영 체제 구조에 대한 조절된 작업부하(AL[OSS]) 및 조절된 용량(AC[OSS])은 적어도 일부 실시형태에서는 커넥션 수락 결정에서 고려될 수 있다. 각각의 자원에 대해, 조절된 부하 및 조절된 용량은 동일한 단위로 표현될 수 있다 - 예를 들어, 네트워크 부하가 패킷/초로 표현되면, 네트워크 용량도 패킷/초로 표현될 수 있다.
AC 어레이 요소의 항으로 표현된 임계치는, 다중-자원 커넥션 수락 기준 테이블(6355)에 표시된 바와 같이, 다양한 시도 카운트 값의 각각에 대해 결정될 수 있다. 묘사된 실시형태에서는 자원의 여러 다른 조합이 여러 다른 시도 카운트 레벨에 대해 고려될 수 있다 - 예를 들어, 시도 카운트 = 2에 대해서는, CPU, 네트워크 및 메모리에 대한 임계치가 대응하는 조절된 부하에 비교될 수 있는 한편, 시도 카운트 = K에 대해서는, CPU 부하와 임계치만이 비교될 수 있다. 테이블(6355)에서의 "&&" 기호는, 예를 들어, 시도 카운트 = 4에서는 CPU와 네트워크 기준 양자가 커넥션을 수락하기 위해 만족되어야 할 수 있도록, 불 "AND"을 표시한다. 다양한 실시형태에서는, 여러 다른 자원에 대한 부하 대 임계치 비교의 여러 다른 불 조합이 사용될 수 있다 - 예를 들어, OR든, AND든, OR와 AND 양자든 사용될 수 있다.
도 64는, 적어도 일부 실시형태에 따라, 분산형 저장 서비스에서 시도 카운트에 기반하여 커넥션 밸런싱을 구현하도록 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(6401)에서 제시된 바와 같이, 소정 세트의 부하 밸런서 노드의 네트워크 주소(예를 들어, 도 3에서 예시된 유형의 고립형 가상 네트워크 내로부터 액세스가능할 수 있는 가상 IP 주소)는 클라이언트에 노출되어 그것들이 서비스로의 저장-관련 요청을 제출 가능하게 할 수 있다. 클라이언트로부터의 커넥션 요청은 특정 LBN(LBN1)에서 수신될 수 있다(요소(6404)). 순차로, LBN1은, 커넥션을 확립하려는 시도가 행해졌던 횟수를 표시하는 시도 카운트 파라미터를 포함하는, 대응하는 커넥션 요청을 선택된 액세스 노드(AN)에 제출할 수 있다(요소(6407)). 커넥션 확립 시도가 지향되는 다음 AN을 선택하는데 다양한 접근법이 사용될 수 있다 - 예를 들어, AN은, LBN1으로부터 AN에서 얼마나 최근에 커넥션이 확립되었는지와 같은 어떤 다른 인자에 기반하여, 또는 라운드-로빈 접근법을 사용하여, 무작위로 선택될 수 있다.
AN은 하나 이상의 자원에 대한 조절된 로컬 작업부하 메트릭(WM), 및 커넥션을 수락/결정하기 위해 그들 작업부하 메트릭이 비교되어야 하는 임계 값(WT)을 결정할 수 있다(요소(6410)). 임계치 중 적어도 일부는 여러 다른 시도 카운트 값에 대해 다를 수 있다. 일부 실시형태에서 임계치는 조절된 자원 용량의 항으로 표현될 수 있고, 그리고 순차로 조절된 자원 용량은 네이티브 또는 베이스라인 자원 용량 및 장애 조절 인자로부터 유도될 수 있다. 일부 실시형태에서는, 도 63에 표시된 바와 같이, 자원-특정적 수락 조건의 다양한 불 조합이 사용될 수 있다. 수락 기준이 만족되면, 예를 들어, 요소(6413)에서 결정되는 바와 같이, 시도 카운트 값에 대해 고려되는 자원에 대해 WM <= WT이면, LBN1은 커넥션이 수락되었다는 알림을 받을 수 있다(요소(6428)). 커넥션이 수락된 후에, 저장 요청을 표현하는 패킷은 클라이언트로부터 LBN1에서 수신되고 커넥션이 확립된 AN에서의 LLBM(로컬 부하 밸런서 모듈)에 송신될 수 있다(요소(6431)). 일부 구현에서, 클라이언트의 패킷은 LBN1에 의해 캡슐화되고 LLBM에 의해 언패킹 또는 추출될 수 있다(요소(6434)). LLBM은, 클라이언트의 요청에 응답하기 위해 어느 저장 서비스 연산이 필요한지 결정하도록 패킷 콘텐츠가 분석될 수 있는, AN에서의 네트워크 프로세싱 스택에 패킷을 전달할 수 있다. 그들 연산에 대한 요청은 필요에 따라 서비스의 다른 서브시스템에(예를 들어, 메타데이터 서브시스템 및/또는 저장 서브시스템에) 보내질 수 있다(요소(6437)).
(요소(6413)에서 또한 검출되는 바와 같이) LBN1에 의해 선택된 AN에서 커넥션을 수락하기 위한 기준이 만족되지 않으면, 커넥션 시도는 거절될 수 있다(요소(6417)). (요소(6419)에서 검출되는 바와 같이) LBN1이 커넥션을 확립하는데 허용된 최대 수의 시도("최대-시도-카운트")를 이미 하였으면, 일부 실시형태에서는 커넥션 확립이 실패하였음을 표시하는 오류 메시지가 클라이언트에 반환될 수 있다(요소(6422)). 여러 실시형태에서, 시도-카운트-기반 수락 기준은 커넥션 확립 실패의 개연성이 매우 낮게 유지되는 그러한 식으로 선택될 수 있다. 커넥션 확립 실패의 수는 추적될 수 있고, 그리고 실패의 수 또는 비율을 목표 레벨 아래로 유지하도록 필요에 따라 추가적 AN이 구성될 수 있다.
(요소(6419)에서 또한 검출되는 바와 같이) LBN1이 아직 클라이언트에 대해 최대 허용가능한 수의 커넥션 시도를 제출하지 않았으면, LBN1은 커넥션 요청이 제출되어야 하는 다른 AN을 선택할 수 있다(요소(6425)). 시도 카운트 파라미터가 증분된 새로운 커넥션 시도는 선택된 AN에 보내질 수 있고, 그리고 요소(6407)부터 계속 대응하는 연산이 반복될 수 있다. 일부 실시형태에서는, 제1 AN을 선택하도록 LBN1에 의해 사용되었던 동일한 종류의 기술이 후속 시도에 대해 AN을 선택하는데 사용될 수 있다. 다른 실시형태에서, LBN1은 시도 카운트에 기반하여 AN을 선택하기 위한 그 기준을 변경할 수 있다 - 예를 들어, 제1 AN은 무작위로 선택될 수 있는 한편, 다음 AN은 LBN1이 다양한 AN과의 커넥션 확립에서의 이전 시도에서 얼마나 성공적이었는지에 기반하여 선택될 수 있다. 하나의 그러한 실시형태에서, LBN은 다양한 AN과의 그 커넥션 확립 성공률에 관한 통계를 유지하고 있을 수 있고, 통계를 사용하여 과거에 더 빈번하게 커넥션을 수락할 수 있었던 AN을 선택할 수 있다.
피어 그룹 작업부하 정보를 사용하는
커넥션
리-
밸런싱
NFS 마운트 커넥션과 같은, 파일 저장 시스템으로의 확립된 커넥션은 보통 장시간 동안 지속될 수 있다. 소정 이전 시간 간격 동안 하나 이상의 자원의 자원 작업부하 레벨과 같은, 커넥션 요청이 수신되었던 시간에서 커넥션 수락 결정과 관련 있었던 정보는 반드시 커넥션의 수명 동안의 소정 추후 시점에서의 액세스 노드의 현재 조건을 표시하지는 않을 수 있다. 일례에서, 액세스 노드는 그 조절된 CPU 부하가 X이었을 때의 시간에서는 커넥션을 수락하였을 수 있지만, 조절된 CPU 부하가 소정 기간 동안 1.5X인 채로 있었을 때의 추후 시간에서는 커넥션이 아직 사용 중일 수 있다. 따라서, 일부 실시형태에서, 액세스 노드는 일부 상황 하에서는 그들 작업부하를 리-밸런싱하려고 시도할 수 있다.
도 65는, 적어도 일부 실시형태에 따라, 액세스 노드의 피어 그룹의 멤버의 작업부하 표시자에 기반하여 클라이언트 커넥션 리-밸런싱이 시도될 수 있는 분산형 저장 서비스의 액세스 서브시스템의 일례를 예시한다. 3개의 노드, AN(6512A, 6512B, 6512C)를 포함하는 액세스 노드 피어 그룹이 도시되어 있다. 피어 그룹에서의 멤버십은, 예를 들어 가용성, 레이턴시, 용량, 병설, 또는 공유된 네트워크 주소 프리픽스를 포함하는, 위에서 언급된 바와 같은 여러 다른 실시형태에서의 다양한 인자에 기반하여 결정될 수 있다. 묘사된 실시형태에서, 각각의 피어 그룹 멤버는 적어도 2개 유형의 작업부하 메트릭을 수집할 수 있다: AN의 CPU, 네트워크, 메모리 및 다른 자원에 대한 앞서 논의된 관찰된 부하와 같은 로컬 작업부하 메트릭(6155)(예를 들어, 6115 A, 6115B 또는 6115C), 및 피어 그룹의 다른 AN에서의 작업부하 레벨의 표시자(6502). 묘사된 예의 구성에서, AN(6512A)은 AN(6512B, 6512C)으로부터 피어 작업부하 표시자(6502A)를 수집할 수 있고, AN(6512B)은 AN(6512A, 6512C)으로부터 피어 작업부하 표시자(6502B)를 수집할 수 있고, 그리고 AN(6512C)은 AN(6512A, 6512B)으로부터 피어 작업부하 표시자를 수집할 수 있다. 작업부하 표시자가 수집되는 방식, 및/또는 작업부하 표시자의 본성 또는 콘텐츠는 여러 다른 실시형태에서 다를 수 있다. 일부 실시형태에서, 예를 들어, 소정 AN은 단순히 커넥션 확립 질의를 소정 선택된 시점에서 그 피어의 각각에 보내고, 피어가 커넥션을 수락하고자 하는지 여부를 표시하는 응답을 수신할 수 있다. 앞서 논의된 바와 같은 시도 카운트 파라미터에 의해 커넥션 수락 결정이 영향을 받을 수 있는 일부 실시형태에서, 커넥션 확립 질의는 또한 시도 카운트 파라미터를 포함할 수 있다(예를 들어, 시도 카운트 파라미터 값 "1"이 사용될 수 있다). 질의를 보내는 AN은 피어의 각각이 소정 시간 간격 동안 얼마나 많은 커넥션을 수락하고자 하였는지 추적하고 있을 수 있다. 각각의 AN이 커넥션 수락 결정을 할 때 그 로컬 작업부하 메트릭을 고려할 것으로 예상되는 실시형태에서, 커넥션 수락률은 정확하고 획득이 용이한 작업부하 표시자로서 역할할 수 있다. 다른 실시형태에서, AN은 단순히 그들 로컬 작업부하 메트릭의 다이제스트 또는 요약을 주기적으로 또는 소정 스케줄에 따라 교환할 수 있고, 그리고 그러한 요약은 작업부하 표시자로서 사용될 수 있다. 일부 실시형태에서, 작업부하 표시자는 질의에 응답하여서만 보내질 수 있는 한편, 다른 실시형태에서, 작업부하 표시자는 질의가 수신되었는지 여부에 무관하게 피어 그룹 멤버에 푸싱될 수 있다. 작업부하 정보를 공유하는데 사용된 특정 기술은 묘사된 실시형태에서는 질의/응답(6570)과 연관된 총 트래픽 및 프로세싱 오버헤드가 임계치 아래로 유지되도록 선택(또는 수정)될 수 있다.
피어 그룹의 각각의 AN은, AN(6512A)에서의 커넥션(C11, C12, ...C1n), AN(6512B)에서의 커넥션(C21, C22, ...C2p), 및 AN(6512C)에서의 커넥션(C31, C32, ..., C3n)과 같은, 소정 확립된 또는 열린 커넥션 세트를 갖는다. 액세스 노드는 각각 그들 열린 커넥션에 관한 각각의 커넥션 통계(6504)를 유지하고 있을 수 있다 - 예를 들어, 통계(6504A)는 AN(6512A)에서 유지되고 있을 수 있고, 통계(6504B)는 AN(6512B)에서 유지되고 있을 수 있고, 그리고 통계(6504C)는 AN(6512C)에서 유지되고 있을 수 있다. 특정 커넥션(Cjk)에 대해 유지되고 있는 커넥션 통계(6504)는, 예를 들어, (Cjk가 확립되었을 때) 커넥션의 연령의 척도, 커넥션 상의 트래픽의 양 및 시간 분포, 커넥션 상에서 요청되었던 저장 연산(예를 들어, 파일 열기, 판독, 기록 등)의 수, 패킷의 크기, 누락된 패킷의 수 등을 포함할 수 있다. 작업부하 리밸런싱을 위해 커넥션이 폐쇄되거나 접속해제되어야 한다고 AN이 결정하면 그리고 그때, 커넥션 통계(6504)는 분석될 수 있고, 그리고 하나 이상의 커넥션은 통계에 기반할 수 있는 폐쇄 표적 선택 기준에 따라 폐쇄될 수 있다. 사용 중인 네트워크 프로토콜에 종속하여, AN은 접속해제를 개시하는데 적합한 메시지를 클라이언트에 보낼 수 있다; 일부 실시형태에서, 메시지의 교환은 커넥션을 깨끗이 폐쇄하는데 요구될 수 있다.
일부 실시형태에서는, 다음 조건 양자가 만족되면 액세스 노드(6512)에서 커넥션을 폐쇄한다고 결정될 수 있다: (a) 액세스 노드에서의 적어도 하나의 로컬 작업부하 메트릭(6115)이 리밸런싱 임계치를 초과함 그리고 (b) 수집된 작업부하 표시자로부터 유도된 피어 용량 가용성 기준이 만족됨. 예를 들어, 하나의 시나리오에서, AN(6512)의 피어 중 적어도 70%가 가장 최근 가용 작업부하 표시자에 기반하여 새로운 커넥션을 수락하고자 할 것이고, 그리고 AN(6512)의 자신의 작업부하 레벨이 높은 충분한 레벨에 도달하였으면, AN(6512)은 선택된 커넥션을 폐쇄하거나 끊기로 결정할 수 있다. 로컬 작업부하-기반 기준은 AN의 로컬 자원이 과중하게 이용될 때(예를 들어, 과중하게 이용되어 새로운 커넥션이 수락되지 않을 것일 때)만 커넥션 리밸런싱이 시도되도록 사용될 수 있다. 피어 용량 가용성 기준은, 예를 들어, 폐쇄된 커넥션의 타단에서의 클라이언트가 커넥션을 확립하고 그 저장 서비스 요청 스트림을 계속할 합리적 가능성을 갖도록 고려될 수 있다.
소정 커넥션(또는 복수의 커넥션)을 폐쇄한다고 결정되면, 적어도 일부 실시형태에서, 폐쇄될 특정 커넥션(들)은 앞서 언급된 바와 같이 커넥션 통계(6504)의 분석에 기반하여 선택될 수 있다. 예를 들어, 동일한 클라이언트의 커넥션이 여러 다른 AN에서 반복적으로 폐쇄되는 오락가락하는 시나리오를 회피하기 위해, 소정 임계치보다 더 긴 시간 동안 존속하고 있었던 커넥션이 폐쇄 표적으로서 선호될 수 있다. 일부 실시형태에서, 트래픽이 더 많은 자원 사용을 초래한 커넥션(예를 들어, 자원 집약적 저장 연산에 사용되었던 커넥션)은, AN에서 더 온당한 자원 이용을 초래한 그들 커넥션에 비해, 폐쇄에 선호되는 표적으로 고려될 수 있다. 그 후 AN은 사용되고 있는 특정 네트워크 프로토콜(예를 들어, TCP)에 따라 그 선택된 커넥션(들)의 폐쇄를 개시할 수 있다. 커넥션의 폐쇄에 응답하여, 적어도 일부 실시형태에서 클라이언트는 다른 커넥션을 확립하려고 할 수 있다. 그 후, (지금-폐쇄된 커넥션의 확립에 참가했던 것과 동일한 LBN일 수도 있고, 다른 LBN일 수도 있는) 부하 밸런서 노드는 클라이언트를 대리하여 커넥션 확립 요청을 (예를 들어, 커넥션을 폐쇄한 AN의 피어 그룹에 속하는) 선택된 AN에 발행할 수 있다. 앞서 설명된 것과 유사한 커넥션 확립 프로토콜은 클라이언트의 커넥션을 수락하고자 하는 AN이 발견될 때까지(또는 부하 밸런서가 최대 시도 카운트에 도달할 때까지) 사용될 수 있다. 커넥션 리밸런싱 결정을 하는데 사용된 피어 용량 가용성 기준이 커넥션을 수락하려는 AN의 의향의 양호한 표시자이면, 클라이언트는 곧 폐쇄된 커넥션을 대체할 새로운 커넥션을 확립할 수 있을 수 있다. 세션-지향형 파일 시스템이 지원되는 적어도 일부 실시형태에서는, 도 68을 참조하여 아래에서 설명되는 바와 같이, 클라이언트가 커넥션 리밸런싱 전에 사용되고 있었던 동일한 세션으로 계속하는 것도 가능할 수 있다. 일 실시형태에서, 특정 AN이 특정 클라이언트(C1)와의 커넥션을 폐쇄한 후에, AN이 리-커넥션 임계 시간 간격 내에 동일한 클라이언트(C1)를 대리하여 후속 커넥션 요청을 수신하면, 커넥션 요청은, 예를 들어 동일한 클라이언트가 그 커넥션이 반복적으로 폐쇄되는 시나리오를 회피하도록, 거절될 수 있다.
일 실시형태에서, 부하 밸런서 노드는 클라이언트에 대해 투명하게 - 예를 들어, 클라이언트가 그 커넥션의 폐쇄가 AN에 의해 개시되었음을 알게 되거나 알림을 받지 않고 대체 커넥션을 확립할 수 있을 수 있다. 부하 밸런서 노드는 리밸런싱-관련 접속해제가 개시되었음을 (예를 들어, AN으로부터 수신된 패킷 헤더 및/또는 패킷 바디 콘텐츠를 조사함으로써) 검출할 수 있을 수 있다. 이것을 발견시, 부하 밸런서 노드는 다른 AN을 선택하고, 클라이언트에 알려주거나 통지함이 없이 다른 AN으로의 다른 커넥션 확립을 개시할 수 있다. 부하 밸런서 노드가 그 요청을 수락하는 AN을 발견할 수 있으면, 적어도 일부 실시형태에서는, 클라이언트의 관점에서 변경된 것으로 보이는 것은 아무것도 없을 수 있다(즉, 클라이언트가 리-밸런싱의 효과를 의식하지 못할 수 있다). 그러한 투명성을 달성하기 위해, 일부 구현에서, 집합적으로 부하 밸런서와 액세스 서브시스템은 접속해제를 개시한 AN과 대체 AN 간 커넥션 상태 정보 이송을 관리하여야 할 수 있다.
도 66은, 적어도 일부 실시형태에 따라, 액세스 서브시스템 노드에서 사용될 수 있는 커넥션 수락 및 리-밸런싱 기준의 일례를 예시한다. 묘사된 실시형태에서는, 앞서 설명된 것과 유사한 방식으로, 시도-카운트 기반 커넥션 수락 임계치가 사용될 수 있다. 그렇지만, 적어도 일부 실시형태에서, 사용된 커넥션 리밸런싱 기술은 커넥션 수락 기준에 직교할 수 있음을 주목한다 - 예를 들어, 일 실시형태에서는 위에서 설명된 시도-카운트 기반 커넥션 수락 기술이 사용되지 않더라도 커넥션 리밸런싱이 사용될 수 있다.
도 66에 묘사된 실시형태에서, 앞서 논의된 예 중 일부에서와 같이, 여러 다른 시도 카운트 레벨에 대해 사용된 임계치는 시도 카운트 값이 상승함에 따라 커넥션이 수락되는 것을 더 용이하게 할 수 있다. 그리하여, 예를 들어, 시도 카운트가 3과 같은 커넥션 요청을 거절하기 위해, AN의 조절된 CPU 부하(AL[CPU])는 조절된 CPU 용량(AC[CPU])의 0.6배를 초과하여야 할 것이고 그리고 AN의 조절된 네트워크 부하(AL[net])는 조절된 네트워크 용량(AC[net])의 0.6배를 초과하여야 할 것이다. 그렇지만, 시도 카운트 값 4를 갖는 커넥션 요청을 거절하기 위해, CPU 및 네트워크에 대한 조절된 부하는 각각 더 높아야 할 것이다(각각, AC[CPU]의 0.8배 및 AC[net]의 0.8배).
수 개의 인자의 조합은 도 66에 예시된 예의 리밸런싱 기준에 기여한다. 첫째로, CPU, 네트워크, 또는 양자에 대한 조절된 로컬 부하 레벨은 대응하는 조절된 용량의 0.85배를 초과하여야 한다. 둘째로, 조절된 메모리 부하는 조절된 메모리 용량의 0.85배를 초과하여야 한다. 셋째로, 리밸런싱에 기인하여 액세스 노드에서 이전 커넥션이 폐쇄된 이후로 적어도 600초가 경과하였어야 한다. 그리고 넷째로, (피어 그룹 멤버로부터 수집된 작업부하 표시자로부터 획득될 수 있는) 피어 액세스 노드가 새로운 커넥션을 수락하고자 할 추정된 확률은 70%를 초과하여야 할 수 있다. 그리하여, 묘사된 실시형태에서는 AN에 의해 커넥션이 종결되기 전에 아주 엄격한 테스트 세트가 통과되어야 할 수 있다.
도 67은, 적어도 일부 실시형태에 따라, 커넥션 리-밸런싱을 구현하도록 분산형 저장 서비스의 액세스 서브시스템에서 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 요소(6701)에서 제시된 바와 같이, 소정 수의 네트워크 커넥션(C1, C2, ..., Cn)은 서비스의 하나 이상의 클라이언트를 대리하여 하나 이상의 부하 밸런서 노드(LBN)와 멀티-테넌트 분산형 저장 서브시스템의 액세스 노드(AN1) 간 확립될 수 있다. 앞서 설명된 바와 같이, 일부 실시형태에서, 소정 세트의 네트워크 주소(예를 들어, 제공자 네트워크의 고립형 가상 네트워크 내로부터 액세스가능한 사설 가상 IP 주소, 또는 인터넷으로부터 액세스가능한 공중 액세스가능한 IP 주소)는 부하 밸런서에 대해 구성되고 서비스에 액세스하기를 바라는 클라이언트에 노출될 수 있다. 일부 실시형태에서, 시도-카운트 기반 커넥션 수락 기준은 커넥션(C1-Cn)을 셋업하는데 사용되었을 수 있는 한편, 다른 실시형태에서, 커넥션은 시도 카운트를 고려하지 않고 확립되었을 수 있다. 일부 실시형태에서, AN1은 앞서 설명된 바와 같이 LBN에 의해 보내진 패킷을 가로채고 조작하는 로컬 부하 밸런서 모듈(LLBM)을 포함할 수 있는 한편, 다른 실시형태에서, AN1은 그러한 LLBM을 포함하지 않을 수 있다.
소정 시간 기간(T) 동안, AN1은 2개 종류의 작업부하 정보를 수집할 수 있다(요소(6704)): AN의 CPU(들), AN의 네트워킹 모듈 등과 같은 자원과 관련 있는 로컬 작업부하 정보, 및 소정 수의 피어 AN으로부터 획득된 피어 그룹 작업부하 표시자. 일부 실시형태에서, AN1은 작업부하-관련 질의를 선택된 피어 세트(예를 들어, 앞서 언급된 종류의 기준에 기반하여 선택된 피어 그룹의 멤버들)에 제출할 수 있고, 그리고 작업부하 표시자는 응답하여 수신될 수 있고; 다른 실시형태에서, 피어 그룹의 AN은 선제적으로 그들 작업부하 표시자를 다양한 시점에서 서로에 푸싱할 수 있다. 일부 구현에서, AN1은 AN-k가 커넥션을 수락하고자 하는지 결정하도록 때때로 피어 AN(예를 들어, AN-k)에 질의를 제출할 수 있고, 그리고 AN-k의 응답은 AN-k의 작업부하의 표시자라고 생각될 수 있다. 적어도 하나의 구현에서, AN1은 (예를 들어, 커넥션 확립에 대한 질의를 보내는 대신에) 커넥션 확립 요청을 AN-k에 보낼 수 있다. 일부 실시형태에서, AN은, 온-디맨드로든 선제적으로든, 그 현재 로컬 작업부하 추정치의 다이제스트 또는 요약을 주기적으로 피어 AN에 제공할 수 있다. 일 실시형태에서, 작업부하 표시자는 AN들 간 교환되는 다른 유형의 메시지 상에, 예를 들어, 관리 메시지 또는 하트비트 메시지 상에 피기백 될 수 있다.
묘사된 실시형태에서는 종결 또는 폐쇄를 위해 커넥션이 선택되기 전에 수 개의 기준이 만족되어야 할 수 있다. AN1은 그 로컬 작업부하 메트릭이 제1 리-밸런싱 임계치를 초과하는지 결정할 수 있다(요소(6707)). 로컬 작업부하 메트릭은, 커넥션 수락을 위한 조절된 부하(AL) 계산에 대해 앞서 설명된 바와 같이, 일부 실시형태에서는 시간의 흐름에 따른 원시 메트릭의 변동을 고려하는 조절된 값을 사용하여 표현될 수 있다. 제1 리-밸런싱 임계치는, 커넥션 수락 기준을 정의하는데 사용된 조절된 용량(AC)에 대해 앞서 또한 설명된 바와 같이, 가능한 장애를 다루기 위한 오버헤드로서 네이티브 자원 용량의 일부를 따로 떼어 두는 일부 실시형태에서 다양한 자원에 대한 조절된 용량 단위로 표현될 수 있다. 다른 실시형태에서는, 커넥션 수락 결정에 고려되는 것과는 다른 작업부하 메트릭 및/또는 자원 세트가 리-밸런싱 결정에 고려될 수 있다.
리-밸런싱을 위한 로컬 작업부하-기반 기준이 만족되면, AN1은 피어 용량 가용성 기준이 만족되었는지 결정할 수 있다(요소(6710)). 피어 용량 가용성 기준은 묘사된 실시형태에서는 다른 AN으로부터 획득된 작업부하 표시자에 기반하여 결정될 수 있다. 적어도 일부 실시형태에서, 피어 가용성 기준을 만족하는 것은, AN1이 특정 클라이언트로의 커넥션을 종결하면, 그 클라이언트가 다른 AN과의 커넥션을 확립할 수 있을 합리적으로 높은 확률이 있음을 표시할 수 있다. 예를 들어, 일 시나리오에서는, (소정 선택된 자원 세트에 대한) AN1의 자신의 조절된 부하가 대응하는 조절된 용량의 90%를 초과하는 한편, AN1이 피어 작업부하 표시자를 사용하여 그 피어 그룹의 멤버 중 적어도 75%가 대응하는 조절된 용량의 40% 미만의 조절된 부하를 갖고 그래서 새로운 커넥션을 수락할 개연성이 있을 것이라고 결정할 수 있으면 피어 용량 가용성 기준이 만족될 수 있다. 적어도 일부 실시형태에서, 소정 피어 AN-k에 대해 AN1에서 이용가능한 가장 최근 작업부하 표시자는 소정 이전 시점 현재 AN-k의 상태를 표현할 수 있고, 그리고 그 여러 다른 작업부하 표시자는 여러 다른 시점을 표현할 수 있음을 주목한다. 그러한 실시형태에서, 피어 용량 가용성 결정은 그래서 정확하기보다는 근사적인 데이터에 기반할 수 있다.
리-밸런싱을 위한 로컬 작업부하 기준 및 피어 용량 가용성 기준이 만족되면, 묘사된 실시형태에서, AN1은 또한 그 커넥션 중 어느 것이라도 마지막 Tmin 시간 단위 내에서 리-밸런싱 목적으로 폐쇄되었는지 결정할 수 있다(요소(6713)). 예를 들어, 도 66에 예시된 시나리오에서, Tmin은 600초로 설정되었다. 이전 리밸런싱-관련 커넥션 종결 이후로 최소 임계 설정(Tmin)보다 더 큰 시간이 만료하였으면(또는 이것이 AN1에서 시도되는 처음 리-밸런싱이면), 폐쇄 표적 선택 정책에 기반하여 특정 커넥션(Cj)이 종결을 위해 선택될 수 있다(요소(6716)). 표적 선택 정책은 커넥션의 연령(더 최근에 확립된 커넥션은 오락가락하는 거동을 회피하기 위해 일부 실시형태에서는 선택될 개연성이 더 작을 수 있음), 커넥션 상의 트래픽의 양, 커넥션과 연관된 다양한 AN 자원(예를 들어, CPU, 메모리 등)의 사용량 등과 같은 다양한 인자를 고려할 수 있다. 일부 실시형태에서, AN1은 폐쇄 표적을 선택하는데 커넥션 통계(6504)를 이용할 수 있다.
선택된 표적 커넥션의 종결 또는 폐쇄는, 예를 들어 사용 중인 네트워킹 프로토콜의 적합한 커넥션 종결 신택스에 따라, 묘사된 실시형태에서는 AN1으로부터 개시될 수 있다(요소(6719)). 커넥션이 끊겼다/폐쇄되었다고 결정시, 대리에 의해 Cj가 확립되었던 클라이언트는 다른 커넥션 확립 요청을 선택된 LBN에 제출할 수 있다(요소(6722)). 그에 따라 LBN은 클라이언트를 대리하여, 예를 들어, 어떤 다른 AN, 예를 들어, AN2와의 커넥션을 확립할 수 있다(요소(6725)). 사용 중인 커넥션 수락 기준에 그리고 AN1의 작업부하 변화에 종속하여, 이러한 새로운 커넥션은 일부 상황에서는 AN1 자체에 의해 수락될 수 있음을 주목한다.
도 67에 묘사된 실시형태에서, (요소(6707)에서 검출되는 바와 같이) 로컬 작업부하-기반 리밸런싱 임계치가 만족되지 않으면, AN1은 그 정규 연산을 계속하여, 요소(6704)에서 표시된 바와 같이 후속 시간 기간 동안 로컬 및 피어 작업부하 정보를 수집할 수 있다. 리-밸런싱을 위한 다른 2개의 조건 중 하나가 만족되지 않으면 - 예를 들어, 피어 용량 가용성 기준이 만족되지 않으면(요소(6710)) 또는 리-밸런싱을 위해 마지막 커넥션이 종결된 이후로 불충분한 시간이 경과하였으면 - 묘사된 실시형태에서 AN1은 그 과도한 작업부하를 다루기 위한 소정 추가적 조치를 취할 수 있다. 예를 들어, 요소(6728)에서 제시된 바와 같이, AN1은 옵션으로서, 예를 들어 선택된 패킷의 프로세싱을 지연시킴으로써 또는 패킷을 누락시킴으로써, 그 열린 커넥션 중 하나 이상을 스로틀링하기 시작할 수 있다. 물론, 사용 중인 네트워킹 프로토콜의 본성에 종속하여, 일부 경우에서 그러한 조치는 클라이언트로부터의 재송신을 초래할 수 있고, 적어도 커넥션이 종결을 위해 선택될 수 있는 충분한 시간이 경과할 때까지, 많은 즉각적 도움이 되지는 않을 수 있다. 다른 실시형태에서, 요소(6707)의 로컬 작업부하-기반 리밸런싱 임계치가 만족되면, AN1은 (요소(6710, 6713)에 대응하는) 다른 2개의 조건 중 적어도 하나가 만족되지 않더라도 선택된 커넥션을 폐쇄할 수 있다. 도 67에서 커넥션을 폐쇄할지 결정하는데 고려되는 3개의 조건은 일부 실시형태에서는 도시된 것과는 다른 순서로 점검될 수 있음을 주목한다, 예를 들어, 일부 실시형태에서는 이전 종결 이후로 경과한 시간이 우선 점검될 수 있거나, 또는 피어 용량 가용성이 우선 점검될 수 있는 것이 사실일 수 있다.
일부 실시형태에서, 분산형 저장 서비스에서 지원되는 파일 시스템 프로토콜 중 적어도 하나는 앞서 설명된 바와 같이 세션-지향형일 수 있다, 예를 들어, 세션 식별자는 클라이언트에 대해 발생되고 자원 리스 및/또는 로크와 연관될 수 있다. 그러한 실시형태에서, 리밸런싱을 위한 클라이언트 커넥션의 종결은 선제적 예방 단계가 취해지지 않는 한 바람직하지 않은 세션 종결을 초래할 수 있다. 도 68은, 적어도 일부 실시형태에 따라, 커넥션 리-밸런싱 이벤트를 가로질러 클라이언트 세션을 보존하도록 분산형 저장 서비스에서 수행될 수 있는 연산의 태양을 예시하는 순서도이다. 예를 들어, 클라이언트(Cl1)가 특정 유형의 저장 요청을 발행할 때 또는 명시적 세션 확립 요청에 응답하여 클라이언트(Cl1)에 대해 클라이언트 세션(CS1)이 확립될 때, 대응하는 세션 메타데이터는 특정 AN으로부터 세션 확립 요청을 수신하는 서비스의 메타데이터 서브시스템 노드에서 또는 그에 의해 저장될 수 있다. 요소(6801)에서 제시된 바와 같이, 그 세션 메타데이터는 CS1에 사용되고 있는 특정 액세스 노드(예를 들어, 세션 확립 요청을 메타데이터 노드에 제출하였고 Cl1으로부터의 후속 저장 요청에 사용되도록 의도되는 AN)를 식별시키는 필드를 포함할 수 있다. 도 55에 또한 예시된 바와 같이, 그러한 필드는 "책임지고 있는 액세스 노드"(RAN) 필드라고 지칭될 수 있다. 클라이언트(Cl1)는 AN1을 통하여 보내진 그 후속 저장-관련 요청에서 세션 메타데이터의 일부분으로서 발생되는 세션 식별자(예를 들어, NFS "클라이언트ID" 파라미터)를 특정할 수 있다.
요소(6804)에서 제시된 바와 같이, 후속하여 AN1은, 예를 들어 위에서 논의된 종류의 리-밸런싱 기준을 사용하여, Cl1의 커넥션이 리밸런싱을 위해 종결되어야/폐쇄되어야 한다고 결정할 수 있다. 그에 따라, 세션 메타데이터의 RAN 필드는 "널"로(또는 책임지고 있는 AN이 없음을 표시하는 어떤 다른 값으로) 설정될 수 있다(요소(6807)). 메타데이터에 대한 변경은 일부 실시형태에서 AN1의 요청시 메타데이터 노드에 의해 수행될 수 있다. 커넥션은 AN1의 발의로 종결될 수 있다.
결국, 커넥션이 폐쇄됨을 Cl1이 깨달은 후에, Cl1은 저장 서비스로의 접속성을 재-확립하려고 하기 위해, 예를 들어 부하 밸런서 노드에, 다른 요청을 보낼 수 있다(요소(6810)). 다른 액세스 노드(AN2)는 커넥션을 수락하도록 LBN에 의해 Cl1을 대리하여 제출된 커넥션 확립 요청에 응답할 수 있다(요소(6813)). 클라이언트(Cl1)는 커넥션의 종결 이전에 그것이 사용하고 있었던 동일한 세션 식별자를 갖는 저장 서비스 요청(예를 들어, open(), read() 또는 write())을 제출할 수 있다(요소(6816)). AN2는 그러한 저장 서비스 요청을 수신하고, 클라이언트-특정된 세션 식별자에 대응하는 메타데이터의 상태를 결정하기 위한 질의를 메타데이터 서브시스템에 보낼 수 있다(요소(6819)). 메타데이터 서브시스템이 특정된 세션 식별자에 대한 세션 메타데이터를 발견할 수 있으면, 그리고 (요소(6822)에서 검출되는 바와 같이) 그 메타데이터의 RAN 필드가 "널"로 설정되어 있으면, 이것은 기존 메타데이터로 CL1의 세션을 계속하는 것, 및 Cl1의 세션에 대한 책임을 떠맡는 것이 AN2에 수락될 수 있음을 AN2에 표시할 수 있다. 그에 따라, CS1의 메타데이터의 RAN 필드는 AN2의 식별자로 설정될 수 있고(요소(6825)) 그리고 CS1은 재개될 수 있다. 그와 달리, 어떤 이유로 CS1의 메타데이터 레코드가 발견되지 않으면, 또는 CS1의 메타데이터에서의 RAN 필드가 "널"로 설정되어 있지 않았으면, 묘사된 실시형태에서는 새로운 세션이 클라이언트에 대해 생성될 수 있다(요소(6828)). 새로운 세션을 확립하는 것은 적어도 일부 실시형태에서는 하나 이상의 로크/리스의 취득을 수반할 수 있고, 그러한 실시형태에서는 책임지고 있는 액세스 노드로서 AN2로 현재 세션이 재개될 수 있는 경우보다 더 많은 자원을 요구할 수 있다.
다양한 실시형태에서, 도 8a, 도 8b, 도 9, 도 10, 도 15, 도 20, 도 21, 도 22, 도 23, 도 27, 도 28, 도 32, 도 38, 도 41, 도 42, 도 43, 도 44, 도 51, 도 52, 도 53, 도 58, 도 59, 도 64, 도 67 및 도 68의 순서도에 예시된 것들 이외의 연산이 위에서 설명된 분산형 파일 저장 서비스 기술을 구현하는데 사용될 수 있음을 주목한다. 제시된 연산 중 일부는 일부 실시형태에서 구현되지 않을 수도 있고, 다른 순서로 구현될 수도 있고, 순차적이라기보다는 병렬로 구현될 수도 있다. 적어도 일부 실시형태에서, 위에서 설명된 기술은 파일 스토어와는 다른 유형의 저장 서비스에서 작업부하 변동을 관리하는데 사용될 수 있다 - 예를 들어, 유사한 기술은 볼륨-레벨 블록 저장 인터페이스를 노출시키는 저장 디바이스에, 파일 시스템 인터페이스라기보다는 웹 서비스 인터페이스를 사용하여 임의 저장 객체가 액세스될 수 있게 하는 비구조화 저장 디바이스에, 또는 관계형 또는 비-관계형 데이터베이스의 파티션 또는 테이블에 액세스하는데 사용될 수 있다.
사용례
하나 이상의 산업-표준 파일 시스템 인터페이스를 지원하는 높은 확장성, 가용성 그리고 영속성 파일 저장 시스템을 구현하는 위에서 설명된 기술은 여러 시나리오에서 그리고 다양한 고객에 유용할 수 있다. 제공자 네트워크의 많은 고객은 하니싱될 수 있는 막대한 양의 컴퓨팅 능력을 이용하기 위해 수 개의 그들 애플리케이션을 클라우드에 이미 이주시켰다. 그렇지만, 단일 파일 내에 매우 많은 양의 데이터(예를 들어, 페타바이트)를 저장하고 그 후 성능에 충격을 주지 않고 다수의 클라이언트로부터 파일에 병행 액세스할 수 있는 능력에 대해 그러한 애플리케이션에 수 개의 제약이 여전히 있을 수 있다. 확장성 제약도 파일 시스템 디렉터리 계층 - 예를 들어, 소정 디렉터리가 저장할 수 있는 객체의 수 및 디렉터리 계층이 포함하고 있을 수 있는 레벨의 수에 대해 여전히 있을 수 있다. 액세스 서브시스템, 메타데이터 서브시스템 및 저장 서브시스템과 같은 다양한 파일 저장 서비스 서브시스템에 노드를 무결절성 추가할 수 있는 능력은 그러한 확장성 제한을 경감하는 것을 도울 수 있다. 데이터로부터 메타데이터의 논리적 분리는, 데이터 상에 (더 엄격한 요구를 가질 수 있는) 메타데이터의 요건을 부과하지 않고, 메타데이터와 데이터 양자에 대한 소망의 구별되는 성능 레벨, 가용성 및 영속성을 달성하는 것을 도울 수 있다. 예를 들어, 메타데이터는 SSD 상에 우선 저장될 수 있는 한편, 데이터는 덜 비싼 회전 디스크-기반 디바이스 상에 수용될 수 있다. 제공자 네트워크 환경에서의 다른 저장 시스템은 많은 애플리케이션이 의존하도록 설계되는 종류의 일관성 시맨틱스 및 친숙한 파일 시스템 인터페이스를 지원하지 않을 수 있다.
단일-페이지 기록에 대한 조건부 기록 메커니즘 및 멀티-페이지 기록에 대한 분산형 트랜잭션 기법을 포함하는 설명된 낙관적 병행 제어 메커니즘은 더 전통적인 로킹-기반 기법이 사용될 때 전형적으로 유발되는 병목 유형 중 일부를 회피하는 것을 도울 수 있다. 익스텐트 초과가입 및 가변 스트라이프 크기결정은 공간 이용 효율과 메타데이터 크기 간 절충을 관리하는데 사용될 수 있다. 오프셋-기반 정체 제어 기술은 소정 유형의 애플리케이션, 예를 들어, 소정 구성 파일이 애플리케이션 시동시 다수의 병행 클라이언트 스레드에 의해 판독되어야 할 수 있는 애플리케이션에 대한 전반적 I/O 성능을 개선하는 것을 도울 수 있다. 객체 이름변경 기술은 대규모 분산형 파일 스토어에서 불가피하게 유발될 수 있는 메타데이터 노드 장애의 경우에 파일 시스템 일관성을 보장하는 것을 도울 수 있다. 앞서 논의된 이름공간 관리 기술은 객체의 수가 증가함에 따라 비교적 평탄 응답 시간을 유지하면서 (단일 디렉터리 내에서도) 수백만 객체를 갖는 파일 시스템을 구현하는데 사용될 수 있다. 클라이언트 세션 관리 캐싱 및 리스 갱신 기술은 세션-관련 오버헤드를 낮게 유지하는 것을 도울 수 있다. 부하 밸런싱 및 리밸런싱 접근법은 과부하-유발된 실패의 개연성을 감축하는 것을 도울 수 있다.
본 발명의 실시형태는 이하의 조항을 고려하여 설명될 수 있다:
1. 시스템으로서,
하나 이상의 컴퓨팅 디바이스를 포함하고, 하나 이상의 컴퓨팅 디바이스는
디렉터리의 이름공간을 표현하도록 방향성 비사이클 그래프(DAG)를, 분산형 멀티-테넌트 파일 저장 서비스의 메타데이터 서브시스템에서, 발생시키되, DAG의 복수의 노드의 각각의 노드는 (a) DAG의 하위 레벨의 노드 식별자의 어레이(NI어레이) 또는 (b) 이름공간 엔트리의 리스트 중 하나를 포함하고, 그리고 DAG의 적어도 하나의 노드는 DAG의 다른 하나의 노드와는 다른 저장 디바이스에서 저장되고;
파일 스토어 객체에 대한 룩업 요청에 응답하여,
선택된 길이의 제1 비트 시퀀스로서 표현가능한 특정 해시 값을 획득하도록 파일 스토어 객체의 이름에 해시 함수를 적용하고;
파일 스토어 객체의 이름공간 엔트리를 포함하는 DAG의 표적 노드를 식별하기 위해, DAG의 루트 레벨로부터 시작하여 DAG의 복수의 레벨을, 각각의 레벨에서 조사될 DAG 노드를 식별하도록 제1 비트 시퀀스의 연속하는 서브시퀀스를 사용하여, 항행하고; 그리고
파일 스토어 객체의 하나 이상의 속성을 결정하도록 이름공간 엔트리의 콘텐츠를 이용하고; 그리고
특정된 이름을 갖는 새로운 파일 스토어 객체를 생성하라는 요청에 응답하여,
선택된 길이의 제2 비트 시퀀스로서 표현가능한 다른 하나의 해시 값을 획득하도록 특정된 이름에 해시 함수를 적용하고;
새로운 파일 스토어 객체에 대응하는 새로운 엔트리를 저장하기 위한 DAG의 후보 노드를 식별하도록 DAG의 복수의 레벨을, 제2 비트 시퀀스의 연속하는 서브시퀀스를 사용하여, 항행하되, 후보 노드는 엔트리의 특정 리스트를 포함하고; 그리고
후보 노드가 분할 기준을 만족한다는 결정에 응답하여, 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드 간 엔트리의 특정 리스트의 엔트리의 적어도 하나의 선택된 서브세트 및 새로운 엔트리를, 각각의 엔트리에 대해 해시 함수를 적용함으로써 획득된 각각의 비트 시퀀스를 사용하여, 분산시키도록 구성된 시스템.
2. 제1 조항에 있어서, 하나 이상의 컴퓨팅 디바이스는
새로운 엔트리에 대해 식별된 후보 노드가 복수의 분할 기준 중 제1 분할 기준을 만족한다는 결정에 응답하여,
후보 노드의 특정 리스트의 각각의 엔트리에 대한 해시 값을 표현하는 각각의 비트 시퀀스를 컴퓨팅하고;
복수의 새로운 리스트에 특정 리스트의 대응하는 엔트리를, 각각의 비트 시퀀스의 각각의 선택된 서브시퀀스를 사용하여, 배정하고;
복수의 새로운 리스트 중 하나의 리스트에 새로운 엔트리를, 제2 비트 시퀀스의 선택된 서브시퀀스를 사용하여, 배정하고;
DAG의 각각의 새로운 노드에 복수의 새로운 리스트의 각각의 리스트를 저장하고; 그리고
각각의 새로운 노드의 노드 식별자를 포함하는 NI어레이로 후보 노드의 엔트리 리스트를 대체하도록 더 구성되는 시스템.
3. 제2 조항에 있어서, 하나 이상의 컴퓨팅 디바이스는
다른 특정된 이름을 갖는 다른 하나의 파일 스토어 객체를 생성하라는 요청에 응답하여, 다른 특정된 이름에 대응하는 제2 새로운 엔트리에 대해 식별된 제2 후보 노드가 복수의 분할 기준 중 다른 분할 기준을 만족한다고 결정하되, 제2 후보 노드는 엔트리의 제2 리스트를 포함하고;
제2 리스트와 새로운 리스트 간 재분산될 엔트리의 제2 리스트의 서브-리스트를 식별하고;
서브-리스트의 각각의 엔트리에 대한 해시 값의 각각의 비트 시퀀스를 획득하고;
제2 리스트와 새로운 리스트 간, 서브-리스트의 엔트리, 및 다른 엔트리를, 그들 각각의 비트 시퀀스에 적어도 부분적으로 기반하여, 재분산시키고;
DAG의 새로운 노드에서 새로운 리스트를 저장하고; 그리고
제2 후보 노드의 부모 노드의 NI어레이 요소의 선택된 서브세트에 새로운 노드의 노드 식별자를 저장하도록 더 구성되는 시스템.
4. 제2 조항에 있어서, 하나 이상의 컴퓨팅 디바이스는
각각의 구성 파라미터에 적어도 부분적으로 기반하여,
(a) 해시 함수, (b) 해시 함수로부터 획득된 비트 시퀀스의 최소 길이, (c) DAG의 특정 레벨을 순회하도록 사용될 제1 비트 시퀀스의 특정 서브시퀀스의 길이, (d) 특정 리스트의 엔트리가 배정되게 되는 리스트의 수, (e) 특정 새로운 노드의 식별자가 저장되게 되는 NI어레이 요소의 수, (f) 임계 파퓰레이션 레벨, 또는 (g) DAG의 레벨의 최대 수 중 하나 이상을 결정하도록 더 구성되는 시스템.
5. 제1 조항에 있어서, DAG는 이름공간의 엔트리의 적어도 하나의 서브세트에 대응하는 해시 값을 저장하지 않는 시스템.
6. 방법으로서,
하나 이상의 컴퓨팅 디바이스에 의해,
디렉터리의 이름공간을 표현하도록 방향성 비사이클 그래프(DAG)를 발생시키는 단계로서, DAG의 복수의 노드의 각각의 노드는 (a) DAG의 하위 레벨의 노드 식별자의 어레이(NI어레이) 또는 (b) 이름공간 엔트리의 리스트 중 하나를 포함하는 발생시키는 단계;
파일 스토어 객체에 대한 룩업 요청에 응답하여,
제1 비트 시퀀스로서 표현가능한 특정 해시 값을 획득하도록 파일 스토어 객체의 이름에 해시 함수를 적용하는 단계;
파일 스토어 객체의 이름공간 엔트리를 포함하는 DAG의 표적 노드를 식별하기 위해, DAG의 루트 레벨로부터 시작하여 DAG의 복수의 레벨을, 각각의 레벨에서 조사될 DAG 노드를 식별하도록 제1 비트 시퀀스의 연속하는 서브시퀀스를 사용하여, 항행하는 단계; 및
파일 스토어 객체의 하나 이상의 속성을 결정하도록 이름공간 엔트리의 콘텐츠를 이용하는 단계; 및
특정된 이름을 갖는 새로운 파일 스토어 객체를 생성하라는 요청에 응답하여,
제2 비트 시퀀스로서 표현가능한 다른 하나의 해시 값을 획득하도록 특정된 이름에 해시 함수를 적용하는 단계;
새로운 파일 스토어 객체에 대응하는 새로운 엔트리를 저장하기 위한 DAG의 후보 노드를 식별하도록 DAG의 복수의 레벨을, 제2 비트 시퀀스의 연속하는 서브시퀀스를 사용하여, 항행하는 단계로서, 후보 노드는 엔트리의 특정 리스트를 포함하는 항행하는 단계; 및
후보 노드가 분할 기준을 만족한다고 결정하는 것에 응답하여, 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드 간 엔트리의 특정 리스트의 엔트리의 적어도 하나의 선택된 서브세트 및 새로운 엔트리를 분산시키는 단계로서, 각각의 분산된 엔트리에 대해 해시 함수를 적용함으로써 획득된 각각의 비트 시퀀스를 사용하는 단계를 포함하는 상기 분산시키는 단계를 수행하는 것을 포함하는 방법.
7. 제6 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
새로운 엔트리에 대해 식별된 후보 노드가 복수의 분할 기준 중 제1 분할 기준을 만족한다고 결정하는 것에 응답하여,
후보 노드의 특정 리스트의 각각의 엔트리에 대한 해시 값을 표현하는 각각의 비트 시퀀스를 컴퓨팅하는 단계;
복수의 새로운 리스트에 특정 리스트의 대응하는 엔트리를, 각각의 비트 시퀀스의 각각의 선택된 서브시퀀스를 사용하여, 배정하는 단계;
복수의 새로운 리스트 중 하나의 리스트에 새로운 엔트리를, 제2 비트 시퀀스의 선택된 서브시퀀스를 사용하여, 배정하는 단계;
DAG의 각각의 새로운 노드에 복수의 새로운 리스트의 각각의 리스트를 저장하는 단계; 및
각각의 새로운 노드의 노드 식별자를 포함하는 NI어레이로 후보 노드의 엔트리 리스트를 대체하는 단계를 수행하는 것을 더 포함하는 방법.
8. 제7 조항에 있어서, 상기 후보 노드가 제1 분할 기준을 만족한다고 결정하는 것은 (a) 특정 리스트의 파퓰레이션이 임계 파퓰레이션 레벨을 초과하고 그리고 (b) 후보 노드의 부모 노드가 후보 노드의 노드 식별자를 갖는 정확히 하나의 NI어레이 요소를 포함한다고 결정하는 것을 포함하는 방법.
9. 제7 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
각각의 구성 파라미터에 적어도 부분적으로 기반하여, (a) 해시 함수, (b) 해시 함수로부터 획득된 비트 시퀀스의 최소 길이, (c) DAG의 특정 레벨을 순회하도록 사용될 제1 비트 시퀀스의 특정 서브시퀀스의 길이, (d) 특정 리스트의 엔트리가 배정되게 되는 리스트의 수, (e) 특정 새로운 노드의 식별자가 저장되게 되는 NI어레이 요소의 수, (f) 임계 파퓰레이션 레벨, 또는 (g) DAG의 레벨의 최대 수 중 하나 이상을 결정하는 단계를 수행하는 것을 더 포함하는 방법.
10. 제7 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
다른 특정된 이름을 갖는 다른 하나의 파일 스토어 객체를 생성하라는 요청에 응답하여, 다른 특정된 이름에 대응하는 제2 새로운 엔트리에 대해 식별된 제2 후보 노드가 복수의 분할 기준 중 다른 분할 기준을 만족한다고 결정하는 단계로서, 제2 후보 노드는 엔트리의 제2 리스트를 포함하는 결정하는 단계;
제2 리스트와 새로운 리스트 간 재분산될 엔트리의 제2 리스트의 서브-리스트를 식별하는 단계;
서브-리스트의 각각의 엔트리에 대한 해시 값의 각각의 비트 시퀀스를 획득하는 단계;
제2 리스트와 새로운 리스트 간, 서브-리스트의 엔트리, 및 다른 엔트리를, 그들 각각의 비트 시퀀스에 적어도 부분적으로 기반하여, 재분산시키는 단계;
DAG의 새로운 노드에서 새로운 리스트를 저장하는 단계; 및
제2 후보 노드의 부모 노드의 NI어레이 요소의 선택된 서브세트에 새로운 노드의 노드 식별자를 저장하는 단계를 수행하는 것을 더 포함하는 방법.
11. 제10 조항에 있어서, 상기 제2 후보 노드가 다른 분할 기준을 만족한다고 결정하는 단계는 (a) 제2 리스트의 파퓰레이션이 임계 파퓰레이션 레벨을 초과하고 그리고 (b) 제2 후보 노드의 부모 노드가 제2 후보 노드의 노드 식별자를 갖는 하나보다 많은 NI어레이 요소를 포함한다고 결정하는 단계를 포함하는 방법.
12. 제10 조항에 있어서, 제2 후보의 부모 노드의 NI어레이 요소의 선택된 서브세트는 제2 후보의 노드 식별자를 이전에 포함하였던 NI어레이 요소 서브세트를 포함하는 방법.
13. 제10 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
(a) 상기 새로운 노드에서 새로운 리스트를 저장하는 단계 및 (b) 상기 제2 후보의 부모 노드의 NI어레이 요소의 선택된 서브세트에 새로운 노드의 노드 식별자를 저장하는 단계를, 원자 기록 연산 내에서, 조합하는 단계를 수행하는 것을 더 포함하는 방법.
14. 제6 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
이름공간으로부터 특정 엔트리를 삭제하라는 요청을 수신하는 단계;
특정 엔트리가 DAG의 다른 노드의 엔트리 리스트 내에서 유일한 엔트리라고 결정하는 단계;
다른 노드의 부모 노드가 다른 노드의 식별자를 저장하는 특정 NI어레이 요소, 및 다른 하나의 노드의 식별자를 저장하는 인접하는 제2 NI어레이 요소를 포함한다고 결정하는 단계;
특정 NI어레이 요소에 다른 하나의 노드의 식별자를 저장하는 단계; 및
DAG로부터 다른 노드를 삭제하는 단계를 수행하는 것을 더 포함하는 방법.
15. 제6 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
이름공간으로부터 특정 엔트리를 삭제하라는 요청을 수신하는 단계;
특정 엔트리가 DAG의 다른 노드의 엔트리 리스트 내에서 유일한 엔트리라고 결정하는 단계;
다른 노드의 부모 노드가 다른 노드 이외의 어느 다른 하나의 노드의 식별자를 저장하는 NI어레이 요소도 포함하지 않는다고 결정하는 단계;
다른 노드의 부모 노드에서의 공백 엔트리 리스트를 초기화하는 단계; 및
DAG로부터 다른 노드를 삭제하는 단계를 수행하는 것을 더 포함하는 방법.
16. 제6 조항에 있어서, 하나 이상의 컴퓨팅 디바이스에 의해,
(a) DAG에서의 레벨의 수가 최대 허용가능한 레벨에 도달하였고 그리고 (b) 다른 엔트리의 삽입을 위해 식별된 다른 후보 노드의 엔트리 리스트가 가득 찼다고 결정하는 것에 응답하여,
DAG의 오버플로 체인에 추가될 추가적 DAG 노드를 초기화하는 단계로서, 순차적 스캔이 오버플로 체인에 삽입된 엔트리를 식별하도록 사용되게 되는 초기화하는 단계;
다른 후보 노드 내에 추가적 DAG 노드로의 포인터를 삽입하는 단계; 및
추가적 DAG 노드에 다른 엔트리를 삽입하는 단계를 수행하는 것을 더 포함하는 방법.
17. 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때,
디렉터리의 이름공간을 표현하도록 방향성 비사이클 그래프(DAG)를 발생시키되, DAG의 복수의 노드의 각각의 노드는 (a) DAG의 하위 레벨의 노드 식별자의 어레이(NI어레이) 또는 (b) 이름공간 엔트리의 리스트 중 하나를 포함하고;
특정된 이름을 갖는 새로운 파일 스토어 객체를 생성하라는 요청에 응답하여,
제1 비트 시퀀스로서 표현가능한 해시 값을 획득하도록 특정된 이름에 해시 함수를 적용하고;
새로운 파일 스토어 객체에 대응하는 새로운 엔트리를 저장하기 위한 DAG의 후보 노드를 식별하도록 DAG의 복수의 레벨을 항행하되, 후보 노드는 엔트리의 특정 리스트를 포함하고 그리고, 복수의 레벨의 특정 레벨을 항행하기 위해, 비트 시퀀스의 선택된 서브시퀀스는 인덱스로서 사용되고; 그리고
후보 노드가 분할 기준을 만족한다는 결정에 응답하여, 각각의 분산된 엔트리에 대해 해시 함수를 적용함으로써 획득된 각각의 비트 시퀀스를 사용하여 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드 간 엔트리의 특정 리스트의 엔트리의 적어도 하나의 선택된 서브세트 및 새로운 엔트리를 분산시키는 프로그램 명령어들을 저장하는 비-일시적 컴퓨터-액세스가능한 저장 매체.
18. 제17 조항에 있어서, 명령어들은, 하나 이상의 프로세서 상에서 실행될 때,
새로운 엔트리에 대해 식별된 후보 노드가 복수의 분할 기준 중 제1 분할 기준을 만족한다는 결정에 응답하여,
후보 노드의 특정 리스트의 각각의 엔트리에 대한 해시 값을 표현하는 각각의 비트 시퀀스를 컴퓨팅하고;
복수의 새로운 리스트에 특정 리스트의 대응하는 엔트리를, 각각의 비트 시퀀스의 각각의 선택된 서브시퀀스를 사용하여, 배정하고;
복수의 새로운 리스트 중 하나의 리스트에 새로운 엔트리를, 제2 비트 시퀀스의 선택된 서브시퀀스를 사용하여, 배정하고;
DAG의 각각의 새로운 노드에 복수의 새로운 리스트의 각각의 리스트를 저장하고; 그리고
각각의 새로운 노드의 노드 식별자를 포함하는 NI어레이로 후보 노드의 엔트리 리스트를 대체하는 비-일시적 컴퓨터-액세스가능한 저장 매체.
19. 제18 조항에 있어서, 후보 노드가 제1 분할 기준을 만족한다고 결정하기 위해, 명령어들은, 하나 이상의 프로세서 상에서 실행될 때,
(a) 특정 리스트의 파퓰레이션이 임계 파퓰레이션 레벨을 초과하고 그리고 (b) 후보 노드의 부모 노드가 후보 노드의 노드 식별자를 갖는 정확히 하나의 NI어레이 요소를 포함한다고 결정하는 비-일시적 컴퓨터-액세스가능한 저장 매체.
20. 제18 조항에 있어서, 명령어들은, 하나 이상의 프로세서 상에서 실행될 때
각각의 구성 파라미터에 적어도 부분적으로 기반하여,
(a) 해시 함수, (b) 해시 함수로부터 획득된 비트 시퀀스의 최소 길이, (c) DAG의 특정 레벨을 순회하도록 사용될 제1 비트 시퀀스의 특정 서브시퀀스의 길이, (d) 특정 리스트의 엔트리가 배정되게 되는 리스트의 수, (e) 특정 새로운 노드의 식별자가 저장되게 되는 NI어레이 요소의 수, (f) 임계 파퓰레이션 레벨, 또는 (g) DAG의 레벨의 최대 수 중 하나 이상을 결정하는 비-일시적 컴퓨터-액세스가능한 저장 매체.
21. 제18 조항에 있어서, 명령어들은, 하나 이상의 프로세서 상에서 실행될 때,
다른 특정된 이름을 갖는 다른 하나의 파일 스토어 객체를 생성하라는 요청에 응답하여, 다른 특정된 이름에 대응하는 제2 새로운 엔트리에 대해 식별된 제2 후보 노드가 복수의 분할 기준 중 다른 분할 기준을 만족한다고 결정하되, 제2 후보 노드는 엔트리의 제2 리스트를 포함하고;
제2 리스트와 새로운 리스트 간 재분산될 엔트리의 제2 리스트의 서브-리스트를 식별하고;
서브-리스트의 각각의 엔트리에 대한 해시 값의 각각의 비트 시퀀스를 획득하고;
제2 리스트와 새로운 리스트 간, 서브-리스트의 엔트리, 및 다른 엔트리를, 그들 각각의 비트 시퀀스에 적어도 부분적으로 기반하여, 재분산시키고;
DAG의 새로운 노드에서 새로운 리스트를 저장하고; 그리고
제2 후보 노드의 부모 노드의 NI어레이 요소의 선택된 서브세트에 새로운 노드의 노드 식별자를 저장하는 비-일시적 컴퓨터-액세스가능한 저장 매체.
22. 제21 조항에 있어서, 제2 후보 노드가 다른 분할 기준을 만족한다고 결정하기 위해, 명령어들은, 하나 이상의 프로세서 상에서 실행될 때,
(a) 제2 리스트의 파퓰레이션이 임계 파퓰레이션 레벨을 초과하고 그리고 (b) 제2 후보 노드의 부모 노드가 제2 후보 노드의 노드 식별자를 갖는 하나보다 많은 NI어레이 요소를 포함한다고 결정하는 비-일시적 컴퓨터-액세스가능한 저장 매체.
예시적 컴퓨터 시스템
적어도 일부 실시형태에서, 부하 밸런서 노드 및/또는 분산형 파일 저장 서비스의 액세스, 메타데이터 및 저장 서브시스템의 컴포넌트를 구현하기 위한 기술을 포함하는, 여기에서 설명되는 기술 중 하나 이상 중 일부 또는 전부를 구현하는 서버는 하나 이상의 컴퓨터-액세스가능한 매체를 포함하거나 그에 액세스하도록 구성되는 범용 컴퓨터 시스템을 포함할 수 있다. 도 69는 그러한 범용 컴퓨팅 디바이스(9000)를 예시한다. 예시된 실시형태에서, 컴퓨팅 디바이스(9000)는 입/출력(I/O) 인터페이스(9030)를 통하여 (비휘발성 및 휘발성 메모리 모듈 양자를 포함할 수 있는) 시스템 메모리(9020)에 결합된 하나 이상의 프로세서(9010)를 포함한다. 컴퓨팅 디바이스(9000)는 I/O 인터페이스(9030)에 결합된 네트워크 인터페이스(9040)를 더 포함한다.
다양한 실시형태에서, 컴퓨팅 디바이스(9000)는 하나의 프로세서(9010)를 포함하는 유니프로세서, 또는 수 개의 프로세서(9010)(예를 들어, 2개, 4개, 8개 또는 다른 적합한 수)를 포함하는 멀티프로세서 시스템일 수 있다. 프로세서(9010)는 명령어를 실행할 수 있는 어느 적합한 프로세서라도 될 수 있다. 예를 들어, 다양한 실시형태에서, 프로세서(9010)는, x86, PowerPC, SPARC, 또는 MIPS ISA, 또는 어느 다른 적합한 ISA와 같은 각종 명령어 세트 아키텍처(ISA) 중 어느 것이라도 구현하는 범용 또는 내장 프로세서일 수 있다. 멀티프로세서 시스템에서, 프로세서(9010)의 각각은, 반드시는 아니지만, 공통으로 동일한 ISA를 구현할 수 있다. 일부 구현에서는, 관용적 프로세서에 부가하여 또는 그 대신에 그래픽 프로세싱 유닛(GPU)이 사용될 수 있다.
시스템 메모리(9020)는 프로세서(들)(9010)가 액세스가능한 데이터 및 명령어를 저장하도록 구성될 수 있다. 적어도 일부 실시형태에서, 시스템 메모리(9020)는 휘발성 부분도 그리고 비-휘발성 부분도 포함할 수 있다; 다른 실시형태에서는, 휘발성 메모리만이 사용될 수 있다. 다양한 실시형태에서, 시스템 메모리(9020)의 휘발성 부분은, 정적 램(SRAM), 동기식 동적 RAM 또는 어느 다른 유형의 메모리와 같은, 어느 적합한 메모리 기술이라도 사용하여 구현될 수 있다. (예를 들어, 하나 이상의 NVDIMM를 포함할 수 있는) 시스템 메모리의 비-휘발성 부분에 대해, 일부 실시형태에서는 NAND-플래시 디바이스를 포함하는 플래시-기반 메모리 디바이스가 사용될 수 있다. 적어도 일부 실시형태에서, 시스템 메모리의 비-휘발성 부분은, 슈퍼커패시터 또는 다른 전력 축적 디바이스(예를 들어, 배터리)와 같은, 전원을 포함할 수 있다. 다양한 실시형태에서, 멤리스터 기반 저항성 램(ReRAM), 3-차원 NAND 기술, 강유전성 RAM, 자기저항성 RAM(MRAM), 또는 다양한 유형의 상 변화 메모리(PCM) 중 어느 것이라도 적어도 시스템 메모리의 비-휘발성 부분에 사용될 수 있다. 예시된 실시형태에서, 위에서 설명된 그들 방법, 기술 및 데이터와 같은, 하나 이상의 소망 기능을 구현하는 프로그램 명령어 및 데이터는 코드(9025) 및 데이터(9026)로서 시스템 메모리(9020) 내에 저장되는 것으로 도시되어 있다.
일 실시형태에서, I/O 인터페이스(9030)는 프로세서(9010)와, 시스템 메모리(9020)와, 네트워크 인터페이스(9040) 또는 데이터 객체 파티션의 물리적 복제본을 저장하는데 사용된 다양한 유형의 영속적 그리고/또는 휘발성 저장 디바이스와 같은 다른 주변 인터페이스를 포함하는, 디바이스 내 어느 주변 디바이스 간 I/O 트래픽을 조정하도록 구성될 수 있다. 일부 실시형태에서, I/O 인터페이스(9030)는 어느 필요한 프로토콜, 타이밍, 또는 다른 데이터 변환이라도 수행하여 하나의 컴포넌트(예를 들어, 시스템 메모리(9020))로부터의 데이터 신호를 다른 컴포넌트(예를 들어, 프로세서(9010))에 의한 사용에 적합한 포맷으로 변환할 수 있다. 일부 실시형태에서, I/O 인터페이스(9030)는, 예를 들어, 주변 컴포넌트 상호접속(PCI) 버스 표준 또는 범용 직렬 버스(USB) 표준의 변종과 같이 다양한 유형의 주변 버스를 통해 배속된 디바이스에 대한 지원을 포함할 수 있다. 일부 실시형태에서, I/O 인터페이스(9030)의 기능은, 예를 들어, 노스 브리지 및 사우스 브리지와 같은 2개 이상의 별개 컴포넌트로 나뉠 수 있다. 또한, 일부 실시형태에서, 시스템 메모리(9020)로의 인터페이스와 같은, I/O 인터페이스(9030)의 기능성 중 일부 또는 전부는 프로세서(9010)에 직접 편입될 수 있다.
네트워크 인터페이스(9040)는 컴퓨팅 디바이스(9000)와, 예를 들어, 도 1 내지 도 68에 예시된 바와 같은 다른 컴퓨터 시스템 또는 디바이스와 같이 네트워크 또는 네트워크들(9050)에 배속된 다른 디바이스(9060) 간 데이터가 교환될 수 있게 하도록 구성될 수 있다. 다양한 실시형태에서, 네트워크 인터페이스(9040)는, 예를 들어, 이더넷 네트워크 유형과 같은 어느 적합한 유선 또는 무선 일반 데이터 네트워크라도 통하여 통신을 지원할 수 있다. 부가적으로, 네트워크 인터페이스(9040)는 아날로그 음성 네트워크 또는 디지털 광섬유 통신 네트워크와 같은 원격통신/전화 네트워크를 통하여, 광섬유 채널 SAN과 같은 저장소 영역 네트워크를 통하여, 또는 어느 다른 적합한 유형의 네트워크 및/또는 프로토콜이라도 통하여 통신을 지원할 수 있다.
일부 실시형태에서, 시스템 메모리(9020)는 대응하는 방법 및 장치의 실시형태를 구현하도록 도 1 내지 도 68에 대해 위에서 설명된 바와 같은 프로그램 명령어 및 데이터를 저장하도록 구성된 컴퓨터-액세스가능한 매체의 일 실시형태일 수 있다. 그렇지만, 다른 실시형태에서, 프로그램 명령어 및/또는 데이터는 여러 다른 유형의 컴퓨터-액세스가능한 매체 상에서 수신, 송신 또는 저장될 수 있다. 일반적으로 말하면, 컴퓨터-액세스가능한 매체는 자기 또는 광학 매체, 예를 들어, I/O 인터페이스(9030)를 통하여 컴퓨팅 디바이스(9000)에 결합된 디스크 또는 DVD/CD와 같은 메모리 매체 또는 비-일시적 저장 매체를 포함할 수 있다. 비-일시적 컴퓨터-액세스가능한 저장 매체는 또한 시스템 메모리(9020) 또는 다른 유형의 메모리로서 컴퓨팅 디바이스(9000)의 일부 실시형태에 포함될 수 있는 RAM(예를 들어, SDRAM, DDR SDRAM, RDRAM, SRAM 등), ROM 등과 같은 어느 휘발성 또는 비-휘발성 매체라도 포함할 수 있다. 더욱, 컴퓨터-액세스가능한 매체는 네트워크 인터페이스(9040)를 통하여 구현될 수 있는 바와 같은 네트워크 및/또는 무선 링크와 같은 통신 매체를 통하여 전해지는 전기, 전자기 또는 디지털 신호와 같은 신호 또는 전송 매체를 포함할 수 있다. 도 69에 예시된 것과 같은 다수의 컴퓨팅 디바이스 중 일부 또는 전부는 다양한 실시형태에서 설명된 기능성을 구현하도록 사용될 수 있다; 예를 들어, 다양한 다른 디바이스 및 서버 상에서 실행되는 소프트웨어 컴포넌트는 기능성을 제공하도록 협업할 수 있다. 일부 실시형태에서, 설명된 기능성 중 일부는, 범용 컴퓨터 시스템을 사용하여 구현되는 대신에 또는 그에 부가하여, 특수용 컴퓨터 시스템, 네트워크 디바이스, 또는 저장 디바이스를 사용하여 구현될 수 있다. 용어 "컴퓨팅 디바이스"는, 여기에서 사용될 때, 적어도 모든 이들 유형의 디바이스를 지칭하고, 이들 유형의 디바이스로 한정되지는 않는다.
결론
다양한 실시형태는 컴퓨터-액세스가능한 매체 상에서 상기 설명에 따라 구현된 명령어 및/또는 데이터를 수신, 송신 또는 저장하는 것을 더 포함할 수 있다. 일반적으로 말하면, 컴퓨터-액세스가능한 매체는 자기 또는 광학 매체, 예를 들어, 디스크 또는 DVD/CD-ROM, RAM(예를 들어, SDRAM, DDR, RDRAM, SRAM 등), ROM과 같은 휘발성 또는 비-휘발성 매체 등과 같은 메모리 매체 또는 저장 매체는 물론, 네트워크 및/또는 무선 링크와 같은 통신 매체를 통하여 전해지는 전기, 전자기 또는 디지털 신호와 같은 신호 또는 전송 매체도 포함할 수 있다.
여기에서 설명되고 도면에서 예시된 바와 같은 다양한 방법은 방법의 대표적 실시형태를 표현한다. 방법은 소프트웨어, 하드웨어, 또는 그 조합으로 구현될 수 있다. 방법의 순서는 변경될 수 있고, 다양한 요소가 부가, 순서변경, 조합, 생략, 수정 등이 될 수 있다.
본 개시가 유익한 당업자에게 자명할 바와 같이 다양한 수정 및 변경이 이루어질 수 있다. 모든 그러한 수정 및 변경을 포괄하려는 의도이고, 그에 따라, 위 설명은 제한적 의미라기보다는 예시적으로 간주되려는 의도이다.
Claims (15)
- 시스템으로서,
하나 이상의 컴퓨팅 디바이스를 포함하고, 상기 하나 이상의 컴퓨팅 디바이스는
분산형 멀티-테넌트 파일 저장 서비스의 메타데이터 서브시스템에서 디렉터리의 이름공간(namespace)을 표현하도록 방향성 비사이클 그래프(DAG: directed acyclic graph)를 발생시키되, 상기 DAG의 복수의 노드의 각각의 노드는 (a) 상기 DAG의 하위 레벨의 노드 식별자의 어레이(NI어레이) 또는 (b) 이름공간 엔트리의 리스트 중 하나를 포함하고, 상기 DAG의 적어도 하나의 노드는 상기 DAG의 다른 하나의 노드와는 다른 저장 디바이스에서 저장되고;
파일 스토어 객체(file store object)에 대한 룩업 요청에 응답하여,
선택된 길이의 제1 비트 시퀀스로서 표현가능한 특정 해시 값을 획득하도록 상기 파일 스토어 객체의 이름에 해시 함수를 적용하고;
상기 파일 스토어 객체의 이름공간 엔트리를 포함하는 상기 DAG의 표적 노드를 식별하기 위해, 상기 DAG의 루트 레벨로부터 시작하여 상기 DAG의 복수의 레벨을, 각각의 레벨에서 조사될 DAG 노드를 식별하도록 상기 제1 비트 시퀀스의 연속하는 서브시퀀스를 사용하여, 항행(navigate)하고;
상기 파일 스토어 객체의 하나 이상의 속성을 결정하도록 상기 이름공간 엔트리의 콘텐츠를 이용하고;
특정된 이름을 갖는 새로운 파일 스토어 객체를 생성하라는 요청에 응답하여,
상기 선택된 길이의 제2 비트 시퀀스로서 표현가능한 다른 하나의 해시 값을 획득하도록 상기 특정된 이름에 상기 해시 함수를 적용하고;
상기 새로운 파일 스토어 객체에 대응하는 새로운 엔트리를 저장하기 위한 상기 DAG의 후보 노드를 식별하도록 상기 DAG의 복수의 레벨을, 상기 제2 비트 시퀀스의 연속하는 서브시퀀스를 사용하여 항행하되, 상기 후보 노드는 특정 리스트의 엔트리들을 포함하고;
상기 후보 노드가 분할 기준을 만족한다는 결정에 응답하여, 각각의 엔트리에 대해 상기 해시 함수를 적용하여 획득된 각각의 비트 시퀀스를 사용하여 상기 새로운 엔트리 및 상기 특정 리스트의 엔트리들 중 적어도 하나의 선택된 엔트리 서브세트를 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드에 분산시키도록 구성된, 시스템. - 제1항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스는
상기 새로운 엔트리에 대해 식별된 상기 후보 노드가 복수의 분할 기준 중 제1 분할 기준을 만족한다는 결정에 응답하여,
상기 후보 노드의 상기 특정 리스트의 각각의 엔트리에 대한 해시 값을 표현하는 각각의 비트 시퀀스를 컴퓨팅하고;
복수의 새로운 리스트에 상기 특정 리스트의 대응하는 엔트리를, 상기 각각의 비트 시퀀스의 각각의 선택된 서브시퀀스를 사용하여, 배정하고;
상기 복수의 새로운 리스트 중 하나의 리스트에 상기 새로운 엔트리를, 상기 제2 비트 시퀀스의 선택된 서브시퀀스를 사용하여, 배정하고;
상기 DAG의 각각의 새로운 노드에 상기 복수의 새로운 리스트의 각각의 리스트를 저장하고; 그리고
상기 각각의 새로운 노드의 노드 식별자를 포함하는 NI어레이로 상기 후보 노드의 엔트리 리스트를 대체하도록 더 구성되는, 시스템. - 제2항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스는
다른 특정된 이름을 갖는 다른 하나의 파일 스토어 객체를 생성하라는 요청에 응답하여,
상기 다른 특정된 이름에 대응하는 제2 새로운 엔트리에 대해 식별된 제2 후보 노드가 상기 복수의 분할 기준 중 다른 분할 기준을 만족한다고 결정하되, 상기 제2 후보 노드는 엔트리의 제2 리스트를 포함하고;
상기 제2 리스트와 새로운 리스트 간 재분산될 엔트리의 상기 제2 리스트의 서브-리스트를 식별하고;
상기 서브-리스트의 각각의 엔트리에 대한 해시 값의 각각의 비트 시퀀스를 획득하고;
상기 제2 리스트와 상기 새로운 리스트 간, 상기 서브-리스트의 상기 엔트리, 및 다른 엔트리를, 당해 각각의 비트 시퀀스에 적어도 부분적으로 기반하여, 재분산시키고;
상기 DAG의 새로운 노드에서 상기 새로운 리스트를 저장하고; 그리고
상기 제2 후보 노드의 부모 노드의 NI어레이 요소의 선택된 서브세트에 상기 새로운 노드의 노드 식별자를 저장하도록 더 구성되는, 시스템. - 방법으로서,
하나 이상의 컴퓨팅 디바이스에 의해,
디렉터리의 이름공간을 표현하도록 방향성 비사이클 그래프(DAG)를 발생시키는 단계로서, 상기 DAG의 복수의 노드의 각각의 노드는 (a) 상기 DAG의 하위 레벨의 노드 식별자의 어레이(NI어레이) 또는 (b) 이름공간 엔트리의 리스트 중 하나를 포함하는 상기 발생시키는 단계;
파일 스토어 객체에 대한 룩업 요청에 응답하여,
제1 비트 시퀀스로서 표현가능한 특정 해시 값을 획득하도록 상기 파일 스토어 객체의 이름에 해시 함수를 적용하는 단계;
상기 파일 스토어 객체의 이름공간 엔트리를 포함하는 상기 DAG의 표적 노드를 식별하기 위해, 상기 DAG의 루트 레벨로부터 시작하여 상기 DAG의 복수의 레벨을, 각각의 레벨에서 조사될 DAG 노드를 식별하도록 상기 제1 비트 시퀀스의 연속하는 서브시퀀스를 사용하여, 항행하는 단계; 및
상기 파일 스토어 객체의 하나 이상의 속성을 결정하도록 상기 이름공간 엔트리의 콘텐츠를 이용하는 단계; 및
특정된 이름을 갖는 새로운 파일 스토어 객체를 생성하라는 요청에 응답하여,
제2 비트 시퀀스로서 표현가능한 다른 하나의 해시 값을 획득하도록 상기 특정된 이름에 상기 해시 함수를 적용하는 단계;
상기 새로운 파일 스토어 객체에 대응하는 새로운 엔트리를 저장하기 위한 상기 DAG의 후보 노드를 식별하도록 상기 DAG의 복수의 레벨을, 상기 제2 비트 시퀀스의 연속하는 서브시퀀스를 사용하여 항행하는 단계로서, 상기 후보 노드는 특정 리스트의 엔트리들을 포함하는 상기 항행하는 단계; 및
상기 후보 노드가 분할 기준을 만족한다고 결정하는 것에 응답하여, 상기 새로운 엔트리와, 상기 특정 리스트의 엔트리들 중 적어도 하나의 선택된 엔트리 서브세트를 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드에 분산시키는 단계로서, 각각의 분산된 엔트리에 대해 상기 해시 함수를 적용하여 획득된 각각의 비트 시퀀스를 사용하는 단계를 포함하는 상기 분산시키는 단계를 수행하는 것을 포함하는, 방법. - 제4항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
상기 새로운 엔트리에 대해 식별된 상기 후보 노드가 복수의 분할 기준 중 제1 분할 기준을 만족한다고 결정하는 것에 응답하여,
상기 후보 노드의 상기 특정 리스트의 각각의 엔트리에 대한 해시 값을 표현하는 각각의 비트 시퀀스를 컴퓨팅하는 단계;
복수의 새로운 리스트에 상기 특정 리스트의 대응하는 엔트리를, 상기 각각의 비트 시퀀스의 각각의 선택된 서브시퀀스를 사용하여, 배정하는 단계;
상기 복수의 새로운 리스트 중 하나의 리스트에 상기 새로운 엔트리를, 상기 제2 비트 시퀀스의 선택된 서브시퀀스를 사용하여, 배정하는 단계;
상기 DAG의 각각의 새로운 노드에 상기 복수의 새로운 리스트의 각각의 리스트를 저장하는 단계; 및
상기 각각의 새로운 노드의 노드 식별자를 포함하는 NI어레이로 상기 후보 노드의 엔트리 리스트를 대체하는 단계를 수행하는 것을 더 포함하는, 방법. - 제4항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
각각의 구성 파라미터에 적어도 부분적으로 기반하여, (a) 상기 해시 함수, (b) 상기 해시 함수로부터 획득된 비트 시퀀스의 최소 길이, (c) 상기 DAG의 특정 레벨을 순회하도록 사용될 상기 제1 비트 시퀀스의 특정 서브시퀀스의 길이, (d) 상기 특정 리스트의 상기 엔트리가 배정되게 되는 리스트의 수, (e) 특정 새로운 노드의 식별자가 저장되게 되는 NI어레이 요소의 수, (f) 임계 파퓰레이션 레벨(population level), 또는 (g) 상기 DAG의 레벨의 최대 수 중 하나 이상을 결정하는 단계를 수행하는 것을 더 포함하는, 방법. - 제4항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
다른 특정된 이름을 갖는 다른 하나의 파일 스토어 객체를 생성하라는 요청에 응답하여,
상기 다른 특정된 이름에 대응하는 제2 새로운 엔트리에 대해 식별된 제2 후보 노드가 복수의 분할 기준 중 다른 분할 기준을 만족한다고 결정하는 단계로서, 상기 제2 후보 노드는 엔트리의 제2 리스트를 포함하는 상기 결정하는 단계;
상기 제2 리스트와 새로운 리스트 간 재분산될 엔트리의 상기 제2 리스트의 서브-리스트를 식별하는 단계;
상기 서브-리스트의 각각의 엔트리에 대한 해시 값의 각각의 비트 시퀀스를 획득하는 단계;
상기 제2 리스트와 상기 새로운 리스트 간, 상기 서브-리스트의 상기 엔트리, 및 다른 엔트리를, 당해 각각의 비트 시퀀스에 적어도 부분적으로 기반하여, 재분산시키는 단계;
상기 DAG의 새로운 노드에서 상기 새로운 리스트를 저장하는 단계; 및
상기 제2 후보 노드의 부모 노드의 NI어레이 요소의 선택된 서브세트에 상기 새로운 노드의 노드 식별자를 저장하는 단계를 수행하는 것을 더 포함하는, 방법. - 제7항에 있어서, 상기 제2 후보 노드가 상기 다른 분할 기준을 만족한다고 결정하는 단계는 (a) 상기 제2 리스트의 파퓰레이션이 임계 파퓰레이션 레벨을 초과하고 그리고 (b) 상기 제2 후보 노드의 부모 노드가 상기 제2 후보 노드의 노드 식별자를 갖는 하나보다 많은 NI어레이 요소를 포함한다고 결정하는 단계를 포함하는, 방법.
- 제7항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
(a) 상기 새로운 노드에서 상기 새로운 리스트를 저장하는 단계 및 (b) 상기 제2 후보의 상기 부모 노드의 NI어레이 요소의 상기 선택된 서브세트에 상기 새로운 노드의 상기 노드 식별자를 저장하는 단계를, 원자 기록 연산(atomic write operation) 내에서, 조합하는 단계를 수행하는 것을 더 포함하는, 방법. - 제4항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
상기 이름공간으로부터 특정 엔트리를 삭제하라는 요청을 수신하는 단계;
상기 특정 엔트리가 상기 DAG의 다른 노드의 엔트리 리스트 내에서 유일한 엔트리라고 결정하는 단계;
상기 다른 노드의 부모 노드가 상기 다른 노드의 식별자를 저장하는 특정 NI어레이 요소, 및 다른 하나의 노드의 식별자를 저장하는 인접하는 제2 NI어레이 요소를 포함한다고 결정하는 단계;
상기 특정 NI어레이 요소에 상기 다른 하나의 노드의 상기 식별자를 저장하는 단계; 및
상기 DAG로부터 상기 다른 노드를 삭제하는 단계를 수행하는 것을 더 포함하는, 방법. - 제4항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
상기 이름공간으로부터 특정 엔트리를 삭제하라는 요청을 수신하는 단계;
상기 특정 엔트리가 상기 DAG의 다른 노드의 엔트리 리스트 내에서 유일한 엔트리라고 결정하는 단계;
상기 다른 노드의 부모 노드가 상기 다른 노드 이외의 어느 다른 하나의 노드의 식별자를 저장하는 NI어레이 요소도 포함하지 않는다고 결정하는 단계;
상기 다른 노드의 상기 부모 노드에서의 공백 엔트리 리스트를 초기화하는 단계; 및
상기 DAG로부터 상기 다른 노드를 삭제하는 단계를 수행하는 것을 더 포함하는, 방법. - 제4항에 있어서, 상기 하나 이상의 컴퓨팅 디바이스에 의해,
(a) 상기 DAG에서의 레벨의 수가 최대 허용가능한 레벨에 도달하였고 그리고 (b) 다른 엔트리의 삽입을 위해 식별된 다른 후보 노드의 엔트리 리스트가 가득 찼다고 결정하는 것에 응답하여,
상기 DAG의 오버플로 체인(overflow chain)에 추가될 추가적 DAG 노드를 초기화하는 단계로서, 순차적 스캔이 상기 오버플로 체인에 삽입된 엔트리를 식별하도록 사용되게 되는 상기 초기화하는 단계;
상기 다른 후보 노드 내에 상기 추가적 DAG 노드로의 포인터를 삽입하는 단계; 및
상기 추가적 DAG 노드에 상기 다른 엔트리를 삽입하는 단계를 수행하는 것을 더 포함하는, 방법. - 비-일시적 컴퓨터-액세스가능한 저장 매체로서, 하나 이상의 프로세서 상에서 실행될 때,
디렉터리의 이름공간을 표현하도록 방향성 비사이클 그래프(DAG)를 발생시키되, 상기 DAG의 복수의 노드의 각각의 노드는 (a) 상기 DAG의 하위 레벨의 노드 식별자의 어레이(NI어레이) 또는 (b) 이름공간 엔트리의 리스트 중 하나를 포함하고;
특정된 이름을 갖는 새로운 파일 스토어 객체를 생성하라는 요청에 응답하여,
제1 비트 시퀀스로서 표현가능한 해시 값을 획득하도록 상기 특정된 이름에 해시 함수를 적용하고;
상기 새로운 파일 스토어 객체에 대응하는 새로운 엔트리를 저장하기 위한 상기 DAG의 후보 노드를 식별하도록 상기 DAG의 복수의 레벨을 항행하되, 상기 후보 노드는 특정 리스트의 엔트리들을 포함하고, 상기 복수의 레벨 중 특정 레벨을 항행하기 위해, 상기 비트 시퀀스의 선택된 서브시퀀스는 인덱스(index)로서 사용되고;
상기 후보 노드가 분할 기준을 만족한다는 결정에 응답하여, 각각의 분산된 엔트리에 대해 상기 해시 함수를 적용함으로써 획득된 각각의 비트 시퀀스를 사용하여 상기 새로운 엔트리 및 상기 특정 리스트의 엔트리들 중 적어도 하나의 선택된 엔트리 서브세트를 적어도 하나의 새로운 DAG 노드를 포함하는 복수의 DAG 노드에 분산시키는 프로그램 명령어들을 저장하는, 비-일시적 컴퓨터-액세스가능한 저장 매체. - 제13항에 있어서, 상기 명령어들은, 상기 하나 이상의 프로세서 상에서 실행될 때,
상기 새로운 엔트리에 대해 식별된 상기 후보 노드가 복수의 분할 기준 중 제1 분할 기준을 만족한다는 결정에 응답하여,
상기 후보 노드의 상기 특정 리스트의 각각의 엔트리에 대한 해시 값을 표현하는 각각의 비트 시퀀스를 컴퓨팅하고;
복수의 새로운 리스트에 상기 특정 리스트의 대응하는 엔트리를, 상기 각각의 비트 시퀀스의 각각의 선택된 서브시퀀스를 사용하여, 배정하고;
상기 복수의 새로운 리스트 중 하나의 리스트에 상기 새로운 엔트리를, 제2 비트 시퀀스의 선택된 서브시퀀스를 사용하여, 배정하고;
상기 DAG의 각각의 새로운 노드에 상기 복수의 새로운 리스트의 각각의 리스트를 저장하고; 그리고
상기 각각의 새로운 노드의 노드 식별자를 포함하는 NI어레이로 상기 후보 노드의 엔트리 리스트를 대체하는, 비-일시적 컴퓨터-액세스가능한 저장 매체. - 제14항에 있어서, 상기 후보 노드가 상기 제1 분할 기준을 만족한다고 결정하기 위해, 상기 명령어들은, 상기 하나 이상의 프로세서 상에서 실행될 때,
(a) 상기 특정 리스트의 파퓰레이션이 임계 파퓰레이션 레벨을 초과하고 그리고 (b) 상기 후보 노드의 부모 노드가 상기 후보 노드의 노드 식별자를 갖는 정확히 하나의 NI어레이 요소를 포함한다고 결정하는, 비-일시적 컴퓨터-액세스가능한 저장 매체.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/231,095 US9495478B2 (en) | 2014-03-31 | 2014-03-31 | Namespace management in distributed storage systems |
| US14/231,095 | 2014-03-31 | ||
| PCT/US2015/022647 WO2015153259A1 (en) | 2014-03-31 | 2015-03-26 | Namespace management in distributed storage systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20160140800A KR20160140800A (ko) | 2016-12-07 |
| KR101891425B1 true KR101891425B1 (ko) | 2018-08-24 |
Family
ID=54190735
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020167029945A KR101891425B1 (ko) | 2014-03-31 | 2015-03-26 | 분산형 저장 시스템에서의 이름공간 관리 |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US9495478B2 (ko) |
| EP (1) | EP3127019B1 (ko) |
| JP (1) | JP6259532B2 (ko) |
| KR (1) | KR101891425B1 (ko) |
| CN (1) | CN106255967B (ko) |
| AU (1) | AU2015241298B2 (ko) |
| BR (1) | BR112016022551A2 (ko) |
| CA (1) | CA2944361C (ko) |
| SG (1) | SG11201608142QA (ko) |
| WO (1) | WO2015153259A1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210019751A (ko) | 2019-08-13 | 2021-02-23 | 주식회사 블루밴드 | 분산복제저장시스템에서 퍼블릭 클라우드로의 실시간 백업방법 및 백업장치 |
Families Citing this family (116)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9621666B2 (en) * | 2005-05-26 | 2017-04-11 | Citrix Systems, Inc. | Systems and methods for enhanced delta compression |
| US9558220B2 (en) | 2013-03-04 | 2017-01-31 | Fisher-Rosemount Systems, Inc. | Big data in process control systems |
| US9665088B2 (en) | 2014-01-31 | 2017-05-30 | Fisher-Rosemount Systems, Inc. | Managing big data in process control systems |
| US10223327B2 (en) | 2013-03-14 | 2019-03-05 | Fisher-Rosemount Systems, Inc. | Collecting and delivering data to a big data machine in a process control system |
| US10649424B2 (en) | 2013-03-04 | 2020-05-12 | Fisher-Rosemount Systems, Inc. | Distributed industrial performance monitoring and analytics |
| US10909137B2 (en) * | 2014-10-06 | 2021-02-02 | Fisher-Rosemount Systems, Inc. | Streaming data for analytics in process control systems |
| US10866952B2 (en) | 2013-03-04 | 2020-12-15 | Fisher-Rosemount Systems, Inc. | Source-independent queries in distributed industrial system |
| US10649449B2 (en) | 2013-03-04 | 2020-05-12 | Fisher-Rosemount Systems, Inc. | Distributed industrial performance monitoring and analytics |
| US10678225B2 (en) | 2013-03-04 | 2020-06-09 | Fisher-Rosemount Systems, Inc. | Data analytic services for distributed industrial performance monitoring |
| US10386827B2 (en) | 2013-03-04 | 2019-08-20 | Fisher-Rosemount Systems, Inc. | Distributed industrial performance monitoring and analytics platform |
| US10282676B2 (en) | 2014-10-06 | 2019-05-07 | Fisher-Rosemount Systems, Inc. | Automatic signal processing-based learning in a process plant |
| US11112925B2 (en) | 2013-03-15 | 2021-09-07 | Fisher-Rosemount Systems, Inc. | Supervisor engine for process control |
| EP3200131A1 (en) | 2013-03-15 | 2017-08-02 | Fisher-Rosemount Systems, Inc. | Data modeling studio |
| US10928970B2 (en) * | 2014-07-18 | 2021-02-23 | Apple Inc. | User-interface for developing applications that apply machine learning |
| US9847918B2 (en) * | 2014-08-12 | 2017-12-19 | Microsoft Technology Licensing, Llc | Distributed workload reassignment following communication failure |
| US10587688B2 (en) * | 2014-09-19 | 2020-03-10 | Netapp, Inc. | Techniques for coordinating parallel performance and cancellation of commands in a storage cluster system |
| US10372760B2 (en) * | 2014-09-26 | 2019-08-06 | Oracle International Corporation | Building queries directed to objects hosted on clouds |
| US10168691B2 (en) | 2014-10-06 | 2019-01-01 | Fisher-Rosemount Systems, Inc. | Data pipeline for process control system analytics |
| US9697227B2 (en) | 2014-10-27 | 2017-07-04 | Cohesity, Inc. | Concurrent access and transactions in a distributed file system |
| WO2016128941A1 (en) * | 2015-02-13 | 2016-08-18 | Eutech Cybernetic | Integration platform to enable operational intelligence and user journeys for smart cities and the internet of things |
| WO2017039775A2 (en) * | 2015-06-11 | 2017-03-09 | PeerNova, Inc. | Making cryptographic claims about stored data using an anchoring system |
| US10747753B2 (en) | 2015-08-28 | 2020-08-18 | Swirlds, Inc. | Methods and apparatus for a distributed database within a network |
| US9390154B1 (en) | 2015-08-28 | 2016-07-12 | Swirlds, Inc. | Methods and apparatus for a distributed database within a network |
| US10001944B2 (en) | 2015-08-28 | 2018-06-19 | Qualcomm Incorporated | Systems and methods for data organization in storage systems using large erasure codes |
| US10733147B2 (en) | 2015-10-19 | 2020-08-04 | Google Llc | Distributed management of file modification-time field |
| CN106649401A (zh) * | 2015-11-03 | 2017-05-10 | 阿里巴巴集团控股有限公司 | 分布式文件系统中的数据写入方法和装置 |
| US10768959B2 (en) * | 2015-11-24 | 2020-09-08 | Red Hat Israel, Ltd. | Virtual machine migration using memory page hints |
| CN105512283B (zh) * | 2015-12-04 | 2019-05-03 | 国网江西省电力公司信息通信分公司 | 数据质量管理控制方法及装置 |
| US10503483B2 (en) | 2016-02-12 | 2019-12-10 | Fisher-Rosemount Systems, Inc. | Rule builder in a process control network |
| WO2017141249A1 (en) * | 2016-02-16 | 2017-08-24 | Technion Research & Development Foundation Limited | Optimized data distribution system |
| US11301422B2 (en) * | 2016-02-23 | 2022-04-12 | Samsung Electronics Co., Ltd. | System and methods for providing fast cacheable access to a key-value device through a filesystem interface |
| CN107181637B (zh) | 2016-03-11 | 2021-01-29 | 华为技术有限公司 | 一种心跳信息发送方法、装置及心跳发送节点 |
| US10796348B2 (en) * | 2016-04-22 | 2020-10-06 | International Business Machines Corporation | Data resiliency of billing information |
| JP6227055B1 (ja) * | 2016-05-25 | 2017-11-08 | ヤフー株式会社 | ストレージシステム、およびファイル書き込み方法 |
| US11567972B1 (en) * | 2016-06-30 | 2023-01-31 | Amazon Technologies, Inc. | Tree-based format for data storage |
| CN106202367B (zh) * | 2016-07-07 | 2019-03-05 | 腾讯科技（深圳）有限公司 | 一种对象信息的处理方法及装置 |
| US11422719B2 (en) * | 2016-09-15 | 2022-08-23 | Pure Storage, Inc. | Distributed file deletion and truncation |
| US10248659B2 (en) * | 2016-10-04 | 2019-04-02 | International Business Machines Corporation | Consistent hashing configurations supporting multi-site replication |
| LT3539026T (lt) | 2016-11-10 | 2022-03-25 | Swirlds, Inc. | Būdai ir aparatas paskirstytajai duomenų bazei, apimančiai anonimines įvestis |
| US10171509B2 (en) * | 2016-11-10 | 2019-01-01 | International Business Machines Corporation | Filtering and redacting blockchain transactions |
| CN106708968B (zh) * | 2016-12-01 | 2019-11-26 | 成都华为技术有限公司 | 分布式数据库系统和分布式数据库系统中的数据处理方法 |
| US11044145B2 (en) | 2016-12-13 | 2021-06-22 | International Business Machines Corporation | Configuring and naming of cloud provisioning entities |
| US10623252B2 (en) | 2016-12-13 | 2020-04-14 | International Business Machines Corporation | Performing actions that have been defined for provisioned instances |
| US11153273B2 (en) | 2016-12-13 | 2021-10-19 | International Business Machines Corporation | Generating and managing names of instances |
| US10547506B2 (en) | 2016-12-13 | 2020-01-28 | International Business Machines Corporation | Determining identities for executing cloud processing and approvers of the executing |
| AU2017382161B2 (en) | 2016-12-19 | 2022-07-07 | Hedera Hashgraph, Llc | Methods and apparatus for a distributed database that enables deletion of events |
| WO2018140625A1 (en) * | 2017-01-26 | 2018-08-02 | Hrl Laboratories, Llc | Scalable and efficient episodic memory in cognitive processing for automated systems |
| US11042330B2 (en) | 2017-03-01 | 2021-06-22 | Samsung Electronics Co., Ltd. | Methods and systems for distributed data storage |
| US11003381B2 (en) | 2017-03-07 | 2021-05-11 | Samsung Electronics Co., Ltd. | Non-volatile memory storage device capable of self-reporting performance capabilities |
| US10360009B2 (en) * | 2017-03-17 | 2019-07-23 | Verizon Patent And Licensing Inc. | Persistent data storage for a microservices application |
| US10565115B2 (en) | 2017-03-30 | 2020-02-18 | Western Digital Technologies, Inc. | Calculating the optimal number of LBNS to prefetch per CPU |
| KR102348418B1 (ko) | 2017-07-11 | 2022-01-07 | 스월즈, 인크. | 네트워크 내의 분산 데이터베이스를 효율적으로 구현하기 위한 방법들 및 장치 |
| US10754696B1 (en) * | 2017-07-20 | 2020-08-25 | EMC IP Holding Company LLC | Scale out capacity load-balancing for backup appliances |
| US10642488B2 (en) | 2017-10-23 | 2020-05-05 | Micron Technology, Inc. | Namespace size adjustment in non-volatile memory devices |
| US10503404B2 (en) | 2017-10-23 | 2019-12-10 | Micron Technology, Inc. | Namespace management in non-volatile memory devices |
| US10437476B2 (en) | 2017-10-23 | 2019-10-08 | Micron Technology, Inc. | Namespaces allocation in non-volatile memory devices |
| US10678703B2 (en) | 2017-11-16 | 2020-06-09 | Micron Technology, Inc. | Namespace mapping structual adjustment in non-volatile memory devices |
| US11580034B2 (en) | 2017-11-16 | 2023-02-14 | Micron Technology, Inc. | Namespace encryption in non-volatile memory devices |
| US10768820B2 (en) | 2017-11-16 | 2020-09-08 | Samsung Electronics Co., Ltd. | On-demand storage provisioning using distributed and virtual namespace management |
| US10223254B1 (en) | 2017-11-16 | 2019-03-05 | Micron Technology, Inc. | Namespace change propagation in non-volatile memory devices |
| US10915440B2 (en) | 2017-11-16 | 2021-02-09 | Micron Technology, Inc. | Namespace mapping optimization in non-volatile memory devices |
| CN111557086B (zh) * | 2017-11-17 | 2023-08-22 | 皇家Kpn公司 | 从与兴趣匹配的多个项中进行选择 |
| EP3490191B1 (en) * | 2017-11-22 | 2020-01-15 | Siemens Aktiengesellschaft | Processing method of service requests performed by a service provider node |
| US10866963B2 (en) | 2017-12-28 | 2020-12-15 | Dropbox, Inc. | File system authentication |
| US10592340B2 (en) * | 2018-02-28 | 2020-03-17 | International Business Machines Corporation | Dynamic authorization batching in a dispersed storage network |
| KR102503177B1 (ko) * | 2018-03-05 | 2023-02-24 | 에스케이하이닉스 주식회사 | 메모리 시스템 및 그것의 동작 방법 |
| US10778646B2 (en) | 2018-05-07 | 2020-09-15 | Cisco Technology, Inc. | Globally deployable context aware VPN headends in scale through namespaces |
| US11030123B2 (en) * | 2018-06-06 | 2021-06-08 | Oracle International Corporation | Fine grained memory and heap management for sharable entities across coordinating participants in database environment |
| CN115421671A (zh) * | 2018-06-22 | 2022-12-02 | 慧荣科技股份有限公司 | 闪存存储装置的命名空间操作方法 |
| US10735369B2 (en) * | 2018-06-22 | 2020-08-04 | Microsoft Technology Licensing, Llc | Hierarchical namespace service with distributed name resolution caching and synchronization |
| US11074135B2 (en) * | 2018-06-29 | 2021-07-27 | Cohesity, Inc. | Large content file optimization |
| US10664461B2 (en) | 2018-06-29 | 2020-05-26 | Cohesity, Inc. | Large content file optimization |
| US10855754B1 (en) * | 2018-07-16 | 2020-12-01 | Amazon Technologies, Inc. | Isolated read channel categories at streaming data service |
| JP7111964B2 (ja) * | 2018-07-31 | 2022-08-03 | 富士通株式会社 | ストレージ管理装置、ストレージシステムおよびプログラム |
| US11134055B2 (en) * | 2018-08-02 | 2021-09-28 | Memverge, Inc. | Naming service in a distributed memory object architecture |
| US11061609B2 (en) | 2018-08-02 | 2021-07-13 | MemVerge, Inc | Distributed memory object method and system enabling memory-speed data access in a distributed environment |
| US11314700B1 (en) | 2018-08-06 | 2022-04-26 | Amazon Technologies, Inc. | Non-native transactional support for distributed computing environments |
| US10929106B1 (en) * | 2018-08-13 | 2021-02-23 | Zoho Coroporation Private Limited | Semantic analyzer with grammatical-number enforcement within a namespace |
| US10958545B2 (en) * | 2018-08-27 | 2021-03-23 | Illumio, Inc. | Monitoring traffic flows of containers in a segmented network environment |
| CN109271113B (zh) * | 2018-09-28 | 2022-03-29 | 武汉烽火众智数字技术有限责任公司 | 一种基于云存储的数据管理系统及方法 |
| US11341052B2 (en) * | 2018-10-15 | 2022-05-24 | Texas Instruments Incorporated | Multi-processor, multi-domain, multi-protocol, cache coherent, speculation aware shared memory and interconnect |
| US11514000B2 (en) * | 2018-12-24 | 2022-11-29 | Cloudbrink, Inc. | Data mesh parallel file system replication |
| US11676063B2 (en) * | 2019-03-28 | 2023-06-13 | International Business Machines Corporation | Exposing payload data from non-integrated machine learning systems |
| US11151093B2 (en) * | 2019-03-29 | 2021-10-19 | International Business Machines Corporation | Distributed system control for on-demand data access in complex, heterogenous data storage |
| US11580444B2 (en) | 2019-04-16 | 2023-02-14 | Apple Inc. | Data visualization machine learning model performance |
| CN110222212B (zh) * | 2019-04-25 | 2021-07-20 | 南京维沃软件技术有限公司 | 一种显示控制方法及终端设备 |
| CN113874876A (zh) | 2019-06-05 | 2021-12-31 | 万事达卡国际公司 | 用于分布式计算系统的安全模型 |
| WO2020247095A1 (en) * | 2019-06-05 | 2020-12-10 | Mastercard International Incorporated | Event management in distributed computing system |
| CN112181899A (zh) * | 2019-07-05 | 2021-01-05 | 中兴通讯股份有限公司 | 一种元数据的处理方法、装置及计算机可读存储介质 |
| KR102258456B1 (ko) * | 2019-08-22 | 2021-06-01 | 성균관대학교산학협력단 | 인-메모리 데이터처리 프레임워크 기반에서 데이터 캐싱 방법 및 시스템, 이를 위한 기록매체 |
| JP2021033856A (ja) * | 2019-08-28 | 2021-03-01 | 富士ゼロックス株式会社 | 情報処理装置、情報処理システム、及び情報処理プログラム |
| CN112445569B (zh) * | 2019-09-02 | 2023-01-17 | 阿里巴巴集团控股有限公司 | 部署方法、装置、电子设备及存储介质 |
| KR102130016B1 (ko) * | 2019-09-03 | 2020-07-03 | 성균관대학교산학협력단 | 자동 캐싱을 위한 컴파일링 방법 및 장치, 이를 위한 기록매체 |
| US10901645B1 (en) | 2019-09-06 | 2021-01-26 | International Business Machines Corporation | Converting small extent storage pools into large extent storage pools in place |
| US11132138B2 (en) | 2019-09-06 | 2021-09-28 | International Business Machines Corporation | Converting large extent storage pools into small extent storage pools in place |
| US11853450B2 (en) * | 2019-11-05 | 2023-12-26 | Saudi Arabian Oil Company | Detection of web application anomalies using machine learning |
| US11349930B2 (en) | 2019-11-19 | 2022-05-31 | EMC IP Holding Company LLC | Identifying and deleting idle remote sessions in a distributed file system |
| US11308028B2 (en) * | 2019-12-23 | 2022-04-19 | EMC IP Holding Company LLC | Predicting and deleting idle remote sessions in a distributed file system |
| JP2021131613A (ja) | 2020-02-18 | 2021-09-09 | 富士通株式会社 | 情報処理プログラム、情報処理装置および情報処理方法 |
| US10860609B1 (en) * | 2020-03-25 | 2020-12-08 | Snowflake Inc. | Distributed stop operator for query processing |
| US11321194B2 (en) * | 2020-04-03 | 2022-05-03 | International Business Machines Corporation | Recovery from a clustered file system queue failure event using a modified extended attribute of a file |
| US11537609B2 (en) * | 2020-06-30 | 2022-12-27 | Oracle International Corporation | Transforming a function-step-based graph query to another graph query language |
| US11829500B2 (en) * | 2020-09-04 | 2023-11-28 | Netflix, Inc. | File interface to dynamically manage access to remote files |
| WO2022020265A1 (en) * | 2020-07-20 | 2022-01-27 | Netflix, Inc. | File interface to dynamically manage access to remote files |
| US11206305B1 (en) * | 2020-09-17 | 2021-12-21 | Sap Se | Latency minimization in datacenters |
| US20220107916A1 (en) * | 2020-10-01 | 2022-04-07 | Netapp Inc. | Supporting a lookup structure for a file system implementing hierarchical reference counting |
| US20220164396A1 (en) * | 2020-11-25 | 2022-05-26 | International Business Machines Corporation | Metadata indexing for information management |
| US11356524B1 (en) * | 2020-12-18 | 2022-06-07 | International Business Machines Corporation | Coordinating requests actioned at a scalable application |
| US11720630B2 (en) * | 2021-01-04 | 2023-08-08 | Oracle International Corporation | Generating new and unique distributed graph ID |
| CN112784120B (zh) * | 2021-01-25 | 2023-02-21 | 浪潮云信息技术股份公司 | 一种基于范围分片方式的kv内存数据库存储管理方法 |
| US20220405240A1 (en) * | 2021-06-16 | 2022-12-22 | Qnap Systems, Inc. | Index node allocation method, data processing device and computer-readable medium |
| US20230006814A1 (en) * | 2021-06-30 | 2023-01-05 | Scality, S.A. | Method and apparatus for implementing changes to a file system that is emulated with an object storage system |
| US11789948B2 (en) * | 2021-12-10 | 2023-10-17 | Sap Se | Computational dependency directory |
| US20230237022A1 (en) * | 2022-01-24 | 2023-07-27 | Nutanix, Inc. | Protocol level connected file share access in a distributed file server environment |
| US12001481B2 (en) * | 2022-04-13 | 2024-06-04 | Oracle International Corporation | Graph-organized file system |
| CN116991333B (zh) * | 2023-09-25 | 2024-01-26 | 苏州元脑智能科技有限公司 | 分布式数据存储方法、装置、电子设备及存储介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040148306A1 (en) | 2000-02-18 | 2004-07-29 | Moulton Gregory Hagan | Hash file system and method for use in a commonality factoring system |
| US20050027795A1 (en) | 1998-08-24 | 2005-02-03 | Microsoft Corporation | Directory service for a computer network |
Family Cites Families (35)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1999038095A1 (en) | 1998-01-26 | 1999-07-29 | Telenor As | Database management system and method for conditional conflict serializability of transactions and for combining meta-data of varying degrees of reliability |
| US6654772B1 (en) | 1999-04-28 | 2003-11-25 | Emc Corporation | Multi-volume extent based file system |
| US8429248B1 (en) | 1999-12-17 | 2013-04-23 | Intel Corporation | Distributed file system including multicast retrieval |
| US20020138559A1 (en) | 2001-01-29 | 2002-09-26 | Ulrich Thomas R. | Dynamically distributed file system |
| US7043637B2 (en) | 2001-03-21 | 2006-05-09 | Microsoft Corporation | On-disk file format for a serverless distributed file system |
| US7062490B2 (en) | 2001-03-26 | 2006-06-13 | Microsoft Corporation | Serverless distributed file system |
| US6842754B2 (en) | 2001-04-17 | 2005-01-11 | Hewlett Packard Development Company, L.P. | Lease enforcement in a distributed file system |
| US7685126B2 (en) | 2001-08-03 | 2010-03-23 | Isilon Systems, Inc. | System and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system |
| US7240114B2 (en) | 2001-09-25 | 2007-07-03 | Hewlett-Packard Development Company, L.P. | Namespace management in a distributed file system |
| AU2003236543A1 (en) * | 2002-06-13 | 2003-12-31 | Mark Logic Corporation | A subtree-structured xml database |
| US7428751B2 (en) | 2002-12-05 | 2008-09-23 | Microsoft Corporation | Secure recovery in a serverless distributed file system |
| JP2004280283A (ja) | 2003-03-13 | 2004-10-07 | Hitachi Ltd | 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法 |
| JP4729844B2 (ja) * | 2003-10-16 | 2011-07-20 | 富士ゼロックス株式会社 | サーバ装置、情報の提供方法、及びプログラム |
| WO2006029508A1 (en) * | 2004-09-13 | 2006-03-23 | Solace Systems Inc. | Highly scalable subscription matching for a content routing network |
| US20060074980A1 (en) * | 2004-09-29 | 2006-04-06 | Sarkar Pte. Ltd. | System for semantically disambiguating text information |
| US7730114B2 (en) | 2004-11-12 | 2010-06-01 | Microsoft Corporation | Computer file system |
| US8229985B2 (en) | 2005-02-07 | 2012-07-24 | Cisco Technology, Inc. | Arrangement for a distributed file system having data objects mapped independent of any data object attribute |
| US20070067332A1 (en) | 2005-03-14 | 2007-03-22 | Gridiron Software, Inc. | Distributed, secure digital file storage and retrieval |
| US20070271242A1 (en) * | 2006-05-19 | 2007-11-22 | Mark Logic Corporation | Point-in-time query method and system |
| WO2007143666A2 (en) * | 2006-06-05 | 2007-12-13 | Mark Logic Corporation | Element query method and system |
| US7895666B1 (en) | 2006-09-01 | 2011-02-22 | Hewlett-Packard Development Company, L.P. | Data structure representation using hash-based directed acyclic graphs and related method |
| US8356162B2 (en) | 2008-03-18 | 2013-01-15 | International Business Machines Corporation | Execution unit with data dependent conditional write instructions |
| TWI476610B (zh) * | 2008-04-29 | 2015-03-11 | Maxiscale Inc | 同級間冗餘檔案伺服器系統及方法 |
| CN101334797B (zh) | 2008-08-04 | 2010-06-02 | 中兴通讯股份有限公司 | 一种分布式文件系统及其数据块一致性管理的方法 |
| CN101520805B (zh) | 2009-03-25 | 2011-05-11 | 中兴通讯股份有限公司 | 一种分布式文件系统及其文件处理方法 |
| US8447734B2 (en) | 2009-11-30 | 2013-05-21 | Hewlett-Packard Development Company, L.P. | HDAG backup system with variable retention |
| JP5485866B2 (ja) * | 2010-12-28 | 2014-05-07 | 株式会社日立ソリューションズ | 情報管理方法、及び情報提供用計算機 |
| US8539008B2 (en) | 2011-04-29 | 2013-09-17 | Netapp, Inc. | Extent-based storage architecture |
| WO2012164735A1 (ja) * | 2011-06-03 | 2012-12-06 | 富士通株式会社 | 情報処理装置、データ管理方法およびデータ管理プログラム |
| US9805054B2 (en) * | 2011-11-14 | 2017-10-31 | Panzura, Inc. | Managing a global namespace for a distributed filesystem |
| US20130218934A1 (en) | 2012-02-17 | 2013-08-22 | Hitachi, Ltd. | Method for directory entries split and merge in distributed file system |
| US9317511B2 (en) * | 2012-06-19 | 2016-04-19 | Infinidat Ltd. | System and method for managing filesystem objects |
| CN103761162B (zh) * | 2014-01-11 | 2016-12-07 | 深圳清华大学研究院 | 分布式文件系统的数据备份方法 |
| US9483482B2 (en) * | 2014-02-17 | 2016-11-01 | Netapp, Inc. | Partitioning file system namespace |
| US9274710B1 (en) * | 2014-03-31 | 2016-03-01 | Amazon Technologies, Inc. | Offset-based congestion control in storage systems |
-
2014
- 2014-03-31 US US14/231,095 patent/US9495478B2/en not_active Expired - Fee Related
-
2015
- 2015-03-26 AU AU2015241298A patent/AU2015241298B2/en active Active
- 2015-03-26 BR BR112016022551A patent/BR112016022551A2/pt not_active Application Discontinuation
- 2015-03-26 SG SG11201608142QA patent/SG11201608142QA/en unknown
- 2015-03-26 KR KR1020167029945A patent/KR101891425B1/ko active IP Right Grant
- 2015-03-26 EP EP15774145.5A patent/EP3127019B1/en active Active
- 2015-03-26 WO PCT/US2015/022647 patent/WO2015153259A1/en active Application Filing
- 2015-03-26 JP JP2016559994A patent/JP6259532B2/ja active Active
- 2015-03-26 CN CN201580023997.5A patent/CN106255967B/zh active Active
- 2015-03-26 CA CA2944361A patent/CA2944361C/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050027795A1 (en) | 1998-08-24 | 2005-02-03 | Microsoft Corporation | Directory service for a computer network |
| US20040148306A1 (en) | 2000-02-18 | 2004-07-29 | Moulton Gregory Hagan | Hash file system and method for use in a commonality factoring system |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20210019751A (ko) | 2019-08-13 | 2021-02-23 | 주식회사 블루밴드 | 분산복제저장시스템에서 퍼블릭 클라우드로의 실시간 백업방법 및 백업장치 |
Also Published As
| Publication number | Publication date |
|---|---|
| BR112016022551A2 (pt) | 2017-08-15 |
| AU2015241298B2 (en) | 2018-03-15 |
| EP3127019B1 (en) | 2023-05-03 |
| CN106255967B (zh) | 2019-10-18 |
| EP3127019A1 (en) | 2017-02-08 |
| EP3127019A4 (en) | 2017-11-08 |
| US9495478B2 (en) | 2016-11-15 |
| CN106255967A (zh) | 2016-12-21 |
| CA2944361A1 (en) | 2015-10-08 |
| WO2015153259A1 (en) | 2015-10-08 |
| US20150278397A1 (en) | 2015-10-01 |
| SG11201608142QA (en) | 2016-10-28 |
| KR20160140800A (ko) | 2016-12-07 |
| CA2944361C (en) | 2020-03-24 |
| AU2015241298A1 (en) | 2016-10-27 |
| JP6259532B2 (ja) | 2018-01-10 |
| JP2017515215A (ja) | 2017-06-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101891425B1 (ko) | 분산형 저장 시스템에서의 이름공간 관리 | |
| KR101867949B1 (ko) | 가변 스트라이프 크기를 사용하는 파일 저장소 | |
| KR101865491B1 (ko) | 다중-익스텐트 연산에 대한 원자 기록 | |
| KR101764559B1 (ko) | 분산형 저장 시스템에서의 세션 관리 | |
| KR101856402B1 (ko) | 확장가능한 파일 저장 서비스 | |
| US9779015B1 (en) | Oversubscribed storage extents with on-demand page allocation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E701 | Decision to grant or registration of patent right |