KR102547126B1 - 블록 스토리지 시스템들을 위한 분산된 복제본 - Google Patents

블록 스토리지 시스템들을 위한 분산된 복제본 Download PDF

Info

Publication number
KR102547126B1
KR102547126B1 KR1020207033888A KR20207033888A KR102547126B1 KR 102547126 B1 KR102547126 B1 KR 102547126B1 KR 1020207033888 A KR1020207033888 A KR 1020207033888A KR 20207033888 A KR20207033888 A KR 20207033888A KR 102547126 B1 KR102547126 B1 KR 102547126B1
Authority
KR
South Korea
Prior art keywords
volume
partitions
replica
servers
partition
Prior art date
Application number
KR1020207033888A
Other languages
English (en)
Other versions
KR20210003217A (ko
Inventor
키란-쿠마르 무니스와미-레디
크리스토퍼 매기 그린우드
콜린 윌리엄스
웰스 린
대니 웨이
이고르 에이. 코스틱
Original Assignee
아마존 테크놀로지스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/967,023 external-priority patent/US10768850B2/en
Priority claimed from US15/967,025 external-priority patent/US10459655B1/en
Priority claimed from US15/967,284 external-priority patent/US11023157B2/en
Application filed by 아마존 테크놀로지스, 인크. filed Critical 아마존 테크놀로지스, 인크.
Publication of KR20210003217A publication Critical patent/KR20210003217A/ko
Application granted granted Critical
Publication of KR102547126B1 publication Critical patent/KR102547126B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/065—Replication mechanisms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Abstract

일반적으로 설명하면, 본 출원의 하나 이상의 측면들은 네트워크 컴퓨팅 환경에 저장된 볼륨의 고도로 분산된 복제본에 대응된다. 볼륨의 제1 및 제2 복제본은 동기식으로 복제될 수 있으며, 3차 복제본의 일부 구현예들은 비동기식드로 복제된다. 3차 복제본의 고도로 분산된 특성은 볼륨 데이터의 병렬 데이터 전송을 지원하므로, 백업 및 새로운 볼륨의 사본을 더 빠르게 생성할 수 있다.

Description

블록 스토리지 시스템들을 위한 분산된 복제본
일반적으로 클라우드 컴퓨팅은 웹 서비스들과 같은 서비스들을 통해 정보 기술 리소스들에 대한 액세스를 제공하는 접근 방식으로서, 이러한 서비스들을 지원하는 데 사용되는 하드웨어 및/또는 소프트웨어는 주어진 시간에 서비스들의 요구를 충족하도록 동적으로 확장 가능하다. 클라우드 컴퓨팅에서, 탄력성은 사용자의 변화하는 요구 사항에 적응하기 위해 클라우드 서비스 공급자가 확장 및 축소할 수 있는 네트워크 전달 컴퓨팅 리소스들을 말한다. 이러한 리소스들의 탄력성은 처리 능력, 스토리지, 대역폭 등의 측면에서 볼 수 있다. 탄력적 컴퓨팅 리소스들은 요청 시 자동으로 제공될 수 있으며, 주어진 사용자 시스템에서 또는 내에서 리소스 요구 사항의 변화들에 동적으로 적응할 수 있다. 예를 들어, 사용자는 클라우드 서비스를 사용하여 대규모 온라인 스트리밍 서비스를 호스팅하고, 탄력적 리소스들로 설정하여 사용자들에게 콘텐트를 스트리밍하는 웹 서버의 수가 최대 시청 시간 동안 대역폭 요구 사항을 충족하도록 확장한 다음 시스템 사용량이 더 적을 때 다시 축소할 수 있도록 한다.
사용자는 일반적으로 클라우드를 통해 리소스들에 대한 액세스를 렌트, 리스 아니면 지불할 것이며, 따라서 이러한 리소스들에 대한 액세스를 제공하기 위해 하드웨어 및/또는 소프트웨어를 구입하고 유지 관리할 필요가 없다. 이는 사용자가 기업의 변화하는 요구에 대응하여 사용 가능한 컴퓨팅 리소스를 빠르게 재구성할 수 있도록 하고, 클라우드 서비스 공급자가 사용량, 트래픽 또는 기타 운영 요구 사항에 따라 제공된 컴퓨팅 서비스 리소스들을 자동으로 확장할 수 있도록 하는 등 다양한 이점을 제공한다. 이는 네트워크 기반 컴퓨팅 서비스들의 이러한 동적 특성은 상대적으로 온-프레미스 컴퓨팅 환경들의 인프라와 달리, 사용자 기반의 변화하는 요구에 따라 하드웨어를 안정적으로 다시 할당할 수 있는 시스템 아키텍처를 필요로 한다.
도 1a는 본 개시에 따른 다양한 실시예들이 구현될 수 있는 탄력적 컴퓨팅 시스템의 개략도를 도시한다.
도 1b는 도 1a의 탄력적 컴퓨팅 시스템 내에서 본 개시에 따른 복제된 데이터 인스턴스들의 개략도를 도시한다.
도 2a는 도 1a의 탄력적 컴퓨팅 시스템 내에서 분산된 3차 복제본을 생성하는 개략도를 도시한다.
도 2b는 도 2a의 분산된 3차 복제본을 생성하기 위한 예시적인 프로세서의 흐름도이다.
도 3a는 도 1a의 탄력적 컴퓨팅 시스템 내의 1차 복제본과 분산된 3차 복제본 사이에서 데이터 업데이트들을 복제하는 개략도를 도시한다.
도 3b는 도 3a의 분산된 3차 복제본을 업데이트하기 위한 예시적인 프로세스의 흐름도이다.
도 4a는 도 1a의 탄력적 컴퓨팅 시스템 내의 분산된 3차 복제본으로부터 볼륨의 클론을 생성하는 개략도를 도시한다.
도 4b는 도 4a에 따른 분산된 3차 복제본으로부터 클론 생성을 위한 예시적인 프로세스의 흐름도이다.
도 5a는 도 1a의 탄력적 컴퓨팅 시스템 내의 분산된 3차 복제본으로부터 볼륨의 스냅샷 백업을 생성하는 개략도를 도시한다.
도 5b는 도 5a에 따른 분산된 3차 복제본으로부터 스냅샷 생성을 위한 예시적인 프로세스의 흐름도이다.
도 5c는 도 5a에 따른 분산된 3차 복제본으로부터 스냅샷 생성을 위한 또 다른 예시적인 프로세스의 흐름도이다.
도 6은 쓰기 동작들로부터 도 1a의 탄력적 컴퓨팅 시스템의 분산된 스토리지 볼륨으로의 메시지들의 스트림을 생성하기 위한 예시적인 상호 작용들을 도시한다.
도 7은 도 1a의 탄력적 컴퓨팅 시스템의 분산된 3차 복제본을 비동식으로 업데이트하기 위해 분산된 스토리지 볼륨에 대한 쓰기 동작들을 반영하는 메시지들의 스트림을 사용하기 위한 예시적인 상호 작용들을 도시한다.
도 8은 도 1a의 탄력적 컴퓨팅 시스템의 분산된 3차 복제본을 비동기식으로 업데이트하기 위해 분산된 스토리지 볼륨에 쓰기 동작들을 반영하는 메시지 번들을 생성하고 이러한 번들을 객체 스토리지 시스템에 저장하기 위한 예시적인 상호 작용들을 도시한다.
도 9a는 볼륨에 쓰기들을 반역하는 메시지들의 스트림에 기초하여 특정 시점에서 도 1a의 탄력적 컴퓨팅 시스템의 볼륨의 상태를 복제하는 개략도를 도시한다.
도 9b는 도 9a에 따라 볼륨의 상태를 반영하기 위한 예시적인 프로세스의 흐름도이다.
도 10a 내지 10c는 볼륨에 대한 중간 듀플리케이트 파티션들을 생성하기 위해 중앙 집중식 권한의 사용에 의해 볼륨 또는 볼륨의 일부의 대량 듀플리케이션을 용이하게 하기 위한 예시적인 상호 작용들을 도시한다.
도 11a 내지 11c는 볼륨에 대한 중간 듀플리케이트 파티션들을 생성하기 위해 피어 투 피어 통신의 사용에 의해 볼륨 또는 볼륨의 일부의 대량 듀플리케이션을 용이하게 하기 위한 예시적인 상호 작용들을 도시한다.
도 12는 볼륨에 대한 중간 듀플리케이트 파티션들의 사용에 의해 볼륨 또는 볼륨의 일부의 대량 듀플리케이션을 용이하게 하기 위한 예시적인 라우팅을 도시한다.
일반적으로 설명되는 본 개시의 양태들은 예를 들어, 네트워크화된 탄력적 컴퓨팅 시스템 내에서 블록 스토리지를 사용하여 저장된 데이터 볼륨의 고도로 분산된 데이터 복제 인스턴스의 생성 및 관리에 관한 것이다. 일반적으로, 볼륨은 사용자를 대신하여 유지되는 데이터 세트와 같은 데이터의 논리적 콜렉션에 대응될 수 있다. 볼륨은 볼륨(복제된 인스턴스들은 컴퓨팅 시스템의 볼륨을 집합적으로 나타낼 수 있음)의 여러 복제 인스턴스들을 제공하기 위해 컴퓨팅 시스템 내에서 여러 번 복제될 수 있다. 네트워크로 연결된 탄력적 컴퓨팅 시스템에서의 볼륨의 복제된 인스턴스들은 1차 또는 2차 복제본의 장애가 볼륨 정보에 대한 액세스를 금지하지 않도록, 예를 들어, 사용자가 볼륨의 1차 복제본 또는 블록 레벨에서 1차 복제본에 동기화되는 볼륨의 2차 복제본에 액세스하도록 허용함으로써 자동 장애 조치 및 복구를 유리하게 제공할 수 있다. 그러나, 빈번한 백업 또는 대량의 볼륨 복제본 생성과 같은 특정 작업들은 볼륨(예를 들어, 볼륨의 복제본들)이 저장되는 하드웨어의 사용 가능한 데이터 통신 대역폭에 부담을 줄 수 있다. 이는 볼륨의 사용자가 경험하는 긴 레이턴시를 초래한다.
그 중에서도, 앞서 언급된 문제들은 볼륨의 고도의 분산된 3차 복제본을 생성하고 사용하기 위한 개시된 기법들에 의해 일부 실시예들에서 다루어 진다. 일 예에서, 볼륨의 1차 복제본은 일반적으로 단일 파티션 또는 최대 16개의 서로 다른 파티션들에 저장되며, 볼륨의 2차 복제본은 해당 개수의 서로 다른 파티션들에 저장된다. 각 파티션은 분산 컴퓨팅 환경의 서버와 같은 다른 컴퓨팅 장치에 저장될 수 있거나, 다중 파티션들이 단일 컴퓨팅 장치에 저장될 수 있다. 볼륨의 고도로 분산된 3차 복제본을 생성하기 위해, 볼륨의 데이터는 여러 컴퓨팅 장치들에 걸쳐 스토리지를 위해 분산되는 다수의 파티션들(예를 들어, 100개, 1,000개, 백만 개, 또는 그 이상)로 분할된다. 이는 일반적으로 1차 복제본 또는 2차 복제본이 저장되는 적은 개수의 장치들보다는, 볼륨의 데이터를 전송하기 위해 많은 개수의 장치들의 연결 대역폭을 이용하여 레이턴시 이슈를 해결한다.
예를 들어, 사용자 읽기 및 쓰기를 실시간으로 처리해야 하는 요구 사항으로 인해(예를 들어, 사용자가 그 볼륨에 읽기 또는 쓰기를 요청하므로) 1차 및 2차 복제본들이 3차 복제본만큼 대량으로 상당히 분산되지 않을 수 있음이 이해될 것이다. 예를 들어, 다른 서버들(또는 다른 컴퓨터 저장 장치들)의 응답 시간들은 다를 수 있으며, 전체 볼륨에 대한 응답 시간은 가장 느린 서버의 응답성에 의해 제한될 수 있다. 따라서, 사용자가 읽기 또는 쓰기에 임계 시간(예를 들어, 서비스 레벨 계약 또는 "SLA"에 의해 설정됨)보다 오래 걸릴 가능성을 줄이기 위해, 1차 및 2차 복제본의 최대 분배가 실제로 제한될 수 있다. 오히려, 더 작은 하드웨어 장치 세트에서 1차 및 2차 복제본들을 유지함으로써, 시스템은 볼륨에 대한 읽기 및 쓰기 동안 낮은 레이턴시 사용자 경험을 유지할 수 있다.
1차 및 2차 복제본들과 달리, 3차 복제본은 이러한 복제본이 볼륨에 대한 사용자 읽기 또는 쓰기를 직접 제공할 것으로 예상되지 않을 수 있으므로, 대량으로 분산될 수 있다. 따라서, 3차 복제본의 볼륨에 대한 읽기 또는 쓰기를 구현 시 지연이 허용될 수 있다. 일 실시예에서, 3차 복제본의 볼륨에 대한 이러한 읽기 또는 쓰기의 구현은 1차 또는 2차 복제본에 포함된 정보에 기초하여, 3차 복제본을 비동기식으로 업데이트하는 것을 수반할 수 있다. 비동기식 업데이팅은 1차 및 2차 복제본들에 대한 임의의 쓰기들로 3차 복제본을 최신 데이터로 유지하는 것을 포함하여, 많은 이점들을 제공한다. 또 다른 이점은 수백만 개의 노드들을 업데이트하는 것이 1차 및 2차 복제본들의 더 적은 개수의 노드들을 업데이트하는 것보다 느릴 수 있다는 사실과 관련이 있으므로, 비동기식 업데이팅은 1차 복제본에서 쓰기를 늦추지 않고 3차 복제본으로부터 빠른 읽기의 이점들을 제공한다.
일 실시예에서, 3차 복제본은 다양한 방식들로 볼륨과 상호 작용할 때 낮은 사용자 레이턴시를 제공하기 위해 1차 및 2차 복제본들과 보완적으로 작동한다. 예를 들어, 1차 복제본은 볼륨에서 읽기 및 쓰기(때때로 "입력 출력 동작들" 또는 단순히 "I/O 동작들"이라 함)를 용이하게 하도록 구성될 수 있어, 볼륨에 대한 사용자 경험을 유지한다. 2차 본제본은 1차 복제본과 동기식으로 업데이트될 수 있으며, 예를 들어 1차 복제본을 호스팅하는 컴퓨팅 하드웨어가 실패할 경우 장애 조치 동작들 동안 원활한 전환을 제공할 수 있다. 유리하게는, 3차 복제본의 스토리지 아키텍처는 1차 및 2차 복제본들에 비해 많은 개수의 컴퓨팅 장치들에 걸쳐 볼륨을 복제하도록 구성될 수 있으므로, 수천 개의 클론들(예를 들어, 원래의 볼륨으로부터 직접 복사된 새 볼륨들)의 생성을 가능하게 하며, 동시에 백업 복제본들의 더 빠른 생성을 가능하게 하고, 고도로 확장된 3차 복제본은 1차 및 2차 복제본만 사용할 수 있는 것보다 볼륨의 새 복제본들의 빠른 생성을 가능하게 할 수 있으므로 더 빠른 복구를 가능하게 한다. 일 실시예에서, 3차 복제본은 1차 및 2차 복제본들과 동기식으로 업데이트되지 않으며, 따라서 볼륨에 대한 표준 사용자 I/O 동작들에 사용되지 않는다. 예시적으로, 3차 복제본은 여러 파티션들에 걸친 볼륨 데이터의 분산 스토리지이고, 3차 복제본에 데이터를 요청하거나 기록할 때, 응답이 가장 느린 파티션들은 "테일 레이턴시(tail latency)"라고 하는 전체 동작의 지연을 야기할 수 있다. 수천 또는 수백만 개의 파티션들에 걸쳐 저장된 3차 복제본을 사용하면, 어느 하나의 파티션이 사용될 수 없거나 주어진 시간에 지연이 발생할 가능성이 높을 수 있어, I/O 동작에 대한 레이턴시가 증가할 수 있다. 이와 같이, 3차 복제본은 동기식 사용자 I/O 동작들을 처리하는 데 적합하지 않을 수 있지만, 그럼에도 불구하고 볼륨으로부터의 데이터의 빠른 전송을 위한 이점들을 제공할 수 있다.
설명을 위해, 8 테라바이트("TB")의 볼륨과 장치 당 초당 1 기가바이트("GB")의 데이터 전송 제한의 예를 고려해보자. 단일 장치에서 볼륨 외부로 데이터를 전송하는 데는 최소 2시간 13분 20초(예시를 위해 전송 용량의 전체 사용을 가정할 경우)가 걸릴 것이다. 1차 및 2차 복제본들은 최대 16개의 파티션들로 분할될 수 있으며, 데이터 전송 제한은 파티션 단위로(예를 들어, 장치당 하나의 파티션으로) 적용된다. 16개의 파티션들을 사용하면, 볼륨으로부터 데이터를 전송하는 데 여전히 최소 8 분 20초가 걸릴 것이다. 따라서, 볼륨으로부터의 데이터의 전송은 기본적으로 볼륨이 분산된 장치들의 개수에 의해 결부된다. 그러나, 볼륨이 1,000개의 장치들로 분할되는 경우, 각 장치는 볼륨 데이터의 1/1,000만 푸시하면 되고, 현재 예에서는 (1차 또는 2차 복제보들이 아닌, 3차 복제본으로부터) 볼륨의 완전한 데이터를 전송하는 데 필요한 시간은 8초로 감소된다.
본 개시의 양태들은 볼륨과의 상호 작용의 로깅(logging)을 용이하게 하기 위한 스트림 로깅 시스템의 이용과 더 관련 있다. 특히, 컴퓨팅 장치의 수집은 볼륨에 대한 수정들(예를 들어, 사용자 I/O 동작들에 반영됨)이 볼륨과 관련된 하나 이상의 메시지 스트림들 내에 메시지들로 반영되는 "로거 플릿(logger fleet)"을 구현할 수 있다. 본원에 개시된 바와 같이, 로거 플릿은 분산된 3차 복제본과 1차 및 2차 복제본의 비동기식 업데이팅을 가능하게 할 수 있어, 로거 플릿은 분산된 3차 복제본이 1차 및 2차 복제본(복제본들이 예를 들어, 동기식으로 업데이트될 수 있음)과 "최종적으로 일치"되게 할 수 있다. 예를 들어, 볼륨에 대한 각 수정은 볼륨과 관련된 스트림 내의 메시지로 로거 플릿에 (예를 들어, 1차 복제본을 구현하는 장치에 의해) 제출될 수 있다. 로거 플릿은 스트림에 제출된 메시지들이 나중에 볼륨에 대해 분산된 3차 복제본을 호스팅하는 장치로 정확한 순서로 전송되도록 하기 위해 데이터 중복 및 리던던시와 같은 다양한 메커니즘들을 적용할 수 있다. 그런 다음, 장치는 각 메시지로부터, 볼륨에 대한 분산된 3차 복제본에 대한 수정을 재생성하여, 메시지가 생성된 시점의 1차 복제본의 상태와 일치하는 상태로 3차 복제본을 배치할 수 있다. 따라서, 로거 플릿의 사용은 분산된 3차 복제본을 호스팅하는 장치에서 각 수정 사항이 정확한 순서로 성공적으로 커밋되도록 보장하는 것과 같은 1차 복제 기능들을 호스팅하는 장치로부터 오프로드될 수 있다.
메시지 스트림으로 볼륨에 대한 수정들을 레코딩하기 위한 로거 플릿의 사용은 본원에 설명된 바와 같이, 추가 기능들을 사용가능하게 할 수 있다. 예를 들어, 메시지 스트림으로서의 볼륨에 대한 수정들의 저장은 본원에 개시된 탄력적 컴퓨팅 시스템이 볼륨에 대한 동작들을 "리와인드"하거나 그렇지 않으면 스트림의 메시지들에 반영된 특정 시점에서 볼륨의 상태를 재생성할 수 있다. 예시적으로, 사용자는 볼륨에 대한 마지막 n개의 수정 동작들이 "실행 취소"되도록 요청할 수 있으며, 탄력적 컴퓨팅 시스템은 볼륨을 이러한 동작들 이전의 상태로 되돌리기 위해 이러한 수정들을 반영하는 메시지들의 스트림을 활용할 수 있다. 다른 예로, 시스템은 볼륨이 해당 상태에 있었던 이후 수정된 경우에도 임의의 상태에서 볼륨의 특정 시점 스냅샷을 생성하기 위해 메시지들의 스트림을 활용할 수 있다. 특히, 시스템은 스냅샷이 요구되는 시점에 원래의 볼륨이 있었던 상태로 임시 볼륨을 배치하기 위해 알려진 상태(예를 들어, 그 자체로 스냅샷에 반영될 수 있는 현재 상태 또는 이전 알려진 상태)로부터 임시 볼륨을 생성하고 (예를 들어, 나중 상태로부터 역방향으로 작동될 때 메시지들을 되돌리거나 또는 새 스냅샷이 요구되는 시점 이전의 상태로부터 역방향으로 작동될 때 메시지들을 구현하는) 메시지들을 적용할 수 있다. 그런 다음, 시스템은 임시 볼륨의 스냅샷을 생성할 수 있으며, 이에 따라 메시지 스트림 내에 반영된 임의의 과거 시점의 볼륨에 대한 스냅샷들의 생성을 가능하게 할 수 있다. 하기에 논의된 바와 같이, 로커 플릿은 볼륨에 대한 다양한 다른 기능들을 가능하게 할 수 있다. 예를 들어, 탄력적 컴퓨팅 시스템은 사용자들이 로거 플릿에 보유된 볼륨에 대한 메시지들을 읽을 수 있는 어플리케이션 프로그래밍 인터페이스(API)를 제공할 수 있으며, 이에 따라 로거 플릿에서 특정 기준을 충족하는 수정들이 검출될 때 사용자에게 알림과 같은 기능들을 사용가능 하게 할 수 있다.
상기에 언급된 바와 같이, 분산된 3차 복제본의 사용은 분산된 3차 복제본의 파티션들에 걸쳐 제공되는 높은 병렬 처리로 인해 볼륨의 신속한 복제를 가능하게 할 수 있다. 그러나, 그럼에도 불구하고 원하는 복제가 분산된 3차 복제본만을 사용할 때 과도한 시간을 필요로 하는 경우가 있을 수 있다. 예를 들어, 사용자가 소스 볼륨을 수백 또는 수천 개의 타겟 볼륨들에 복제하고자 하는 경우, 단일의 분산된 3차 복제본의 사용은 이러한 동작을 완료하는 데 많은 시간을 필요로 할 수 있다. 이를 해결하기 위해, 본 출원의 실시예들은 볼륨의 대규모 복제를 용이하게 하기 위해 추가의 고도로 분산된 복제본들 또는 이러한 복제본들의 일부들의 구현 및 사용을 가능하게 한다. 예시적으로, 사용자가 소스 볼륨을 1000번 복제하고자 하는 경우, 제1 고도로 분산된 복제본(예를 들어, 3차 복제본)은 제2 고도로 분산된 복제본을 생성하는 데 사용될 수 있다. 그런 다음, 두 개의 고도로 분산된 복제본 각각은 추가의 고도로 분산된 복제본을 생성하는 데 사용될 수 있다. 이러한 방식으로, 볼륨에 대해 고도로 분산된 복제본들의 개수가 기하급수적으로 증가될 수 있다. 볼륨에 대해 고도로 분산된 복제본들의 개수가 충분한 레벨(예를 들어, 미리 결정된 최대값, 타겟 볼륨들에 대한 복제가 임계 시간 기간 내에 완료될 것으로 예상되는 레벨 등)에 도달하면, 고도로 분산된 복제본들의 수집은 소스 볼륨을 원하는 타겟 볼륨들(예를 들어, 블록 저장 서버 세트의 볼륨들, 컴퓨팅 서버의 인스턴스들의 가상 디스크 드라이브들 등)에 복제하는 데 사용될 수 있다. 이후, 추가의 고도로 분산된 복제본들은 이러한 많은 고도로 분산된 복제본들을 제공할 때 컴퓨팅 리소스들의 과도한 사용을 피하기 위해 추가의 고도로 분산된 복제본들이 제거될 수 있다.
일부 경우에, 사용자는 그 전체에서 볼륨의 대량 복제를 요청할 수 있다. 이러한 경우에, 복제를 용이하게 하기 위해 많은 추가의 고도로 분산된 복제본이 생성될 수 있다. 이러한 추가 복제본들은 일반적으로 본원에서 "중간 복제(intermediary duplicate)" 복제본이라고 하는데, 복제본은 초기 고도로 분산된 복제본(예를 들어, 3차 복제본)과 대량 복제가 요청되는 타겟 볼륨들 사이의 매개체로 사용될 수 있기 때문이다. 다른 경우에, 사용자는 볼륨의 일부만 대량 복제를 요청할 수 있다. 예를 들어, 사용자는 볼륨의 단일 파일(예를 들어, 구성 파일) 또는 섹터(예를 들어, 부트 섹터)를 많은 개수의 타겟 볼륨들에 복사하고자 할 수 있다. 이러한 경우에, 볼륨의 추가의 고도로 분산된 복제본을 생성하는 대신, 고도로 분산된 복제본의 하나 이상의 파티션들이 복제될 수 있다. 예를 들어, 고도로 분산된 3차 복제본의 단일 파티션에 저장된 파일의 복제가 요청되는 경우, 블록 저장 서버들은 (예를 들어, 임계 시간 기간 내에) 타겟 볼륨들에 파일을 복사하기에 충분한 개수의 복제 파티션들이 존재할 때까지 해당 단일 파티션을 (예를 들어, 상기의 지수 프로세스를 사용하여) 복제하도록 구성될 수 있다. 이러한 복제된 파티션들은 일반적으로 본원에서 "중간 복제(intermediary duplicate)" 복제본이라고 하는데, 파티션들은 초기 고도로 분산된 복제본(예를 들어, 3차 복제본)의 파티션과 대량 복제가 요청되는 타겟 볼륨들 사이의 매개체로 사용될 수 있기 때문이다. 중간 듀플리케이트 복제본들(예를 들어, 그 전체가 볼륨을 나타냄) 및 중간 듀플리케이트 파티션들(예를 들어, 고도로 분산된 복제본의 개별 파티션을 나타냄)은 총괄하여 본원에서는 "중간 듀플리케이트들(intermediary duplicates)"로 지칭된다.
일 실시예에서, 중간 듀플리케이트들의 생성은 중앙 집중식 권한에 의해 용이하게 된다. 예를 들어, 고도로 분산된 복제본으로부터 정보 복사 요청들을 수신하고, 요청들이 중간 듀플리케이트들의 생성을 위한 임계 레벨을 충족하는지 여부를 결정하고, 중간 듀플리케이트들의 생성을 야기하고, 중간 듀플리케이트들을 사용하여 요청된 정보 사본을 구현하는 컨트롤러가 제공될 수 있다. 다른 실시예에서, 중간 듀플리케이트들의 생성은 고도로 분산된 복제본의 파티션들을 구현하는 서버들의 피어 투 피어 동작에 의해 촉진된다. 예를 들어, 고도로 분산된 복제본을 구현하는 서비스들의 수집 내의 각 서버는 서버의 복제본의 파티션들로부터 정보를 복사하라는 요청들을 모니터링하고, 요청들이 파티션들에 대한 하나 이상의 중간 듀플리케이트들의 생성을 위한 임계 레벨을 충족하는지 여부를 결정할 수 있다. 충족하는 경우, 서버는 소스 파티션을 콜렉션 내의 다른 서버로 복사하고, 파티션을 복사하기 위한 요청들 중 적어도 일부를 다른 서버로 전송함으로써 중간 듀플리케이션 파티션들을 생성할 수 있다. 이 기능은 각 서버에서 구현될 수 있으므로, 이 피어 투 피어 동작은 중앙 집중식 제어를 요구하지 않고 파티션의 중간 듀플리케이션들의 수의 기하급수적 증가를 용이하게 할 수 있다.
당업자에 의해 이해되는 바와 같이, 본원에 개시된 바와 같은 고도로 분산된 복제본 및/또는 로거 플릿의 사용은 이전 구현예들에 비해 상당한 기술적 진보를 나타낸다. 특히, 본원기에 개시된 바와 같은 고도로 분할된 3차 복제본의 사용은 탄력적 컴퓨팅 시스템이 데이터 볼륨의 신속한 복제를 용이하게 하거나, 이전 시스템들의 대역폭이나 처리량 제한을 경험하지 않고도 데이터 볼륨에 대해 기타 집약적인 I/O 동작들을 수행하게 할 수 있다. 게다가, 고도로 분할된 3차 복제본과 덜 고도로 분할된 1차 및 2차 복제본들과의 조합은 높은 레벨의 파티셔닝으로 인한 잠재적 레이턴시들과 같은, 고도로 분할된 복제본만을 사용하는 어려움들을 극복한다. 따라서, 고도로 분할된 3차 복제본과 덜 고도로 분할된 1차 및 2차 복제본들의 조합은 탄력적 컴퓨팅 시스템이 사용자 I/O 동작들에 대한 응답성이 높게 하고 볼륨의 신속한 듀플리케이션 또는 집약적인 I/O 동작들이 용이해지도록 둘 다를 가능하게 할 수 있다. 이러한 I/O 집약적인 동작들의 속도를 증가시키면서 일반적인 사용자 I/O 동작들에 대한 응답성을 유지함으로써, 본 개시는 탄력적 컴퓨팅 시스템의 동작에 대한 상당한 개선을 나타낸다. 예를 들어, 본원에 개시된 실시예들은 탄력적 컴퓨팅 시스템의 컴퓨팅 리소스들이 사용되는 효율성을 크게 개선시킬 수 있으며, 그 결과 시스템의 응답성이 증가하고 총 리소스 사용량이 감소한다. 볼륨에 대한 데이터 수정 메시지들을 저장하기 위한 로거 플릿의 구현예는 예를 들어, 덜 분산된 복제본에 대해 분산된 3차 복제본의 비동기식 업데이팅을 가능하게 함으로써, 상기에 언급된 이점들을 사용 가능하게 할 수 있다. 본원에 개시된 로거 플릿은 또한 볼륨에 대한 동작들을 "리와인드"하거나 볼륨을 이전 상태로 재생성하는 능력과 같은, 탄력적 컴퓨팅 시스템의 동작에 대한 기타 개선들을 촉진시킬 수 있다. 볼륨을 과거 상태로 되돌리는 이 기능은 (예를 들어, 악성 소프트웨어로 인해) 장치에 잘못된 쓰기 이후 장치를 과거 상태로 복원하는데 있어서의 어려움과 같이, 스토리지 장치들 내에서 오래동안 지속되는 이슈들을 해결한다. 게다가, 당업자가 인지하고 있는 바와 같이, 본원에 설명된 실시예들(예를 들어, 더 낮은 분할된 복제본과 고도로 분할된 복제본의 조합 사용, 메시지 스트림으로서 볼륨에 대한 수정들을 저장하기 위한 로거 플릿의 구현)은 개별 컴퓨팅 장치들의 제한된 대역폭, 분산 컴퓨팅 시스템들에 의해 부과되는 레이턴시, 이러한 시스템들에 걸친 대역폭과 레이턴시 우려의 밸런싱의 어려움, 및 이러한 시스템들에서 (특히 시간이 지남에 따라) 데이터 복원력을 보장하는 데 있어서의 어려움과 같은, 정보 검색 및 데이터 저장 분야의 오랫동안 지속되는 기술적 문제에 대한 기술적 솔루션을 제공한다. 이와 같이, 본원에 설명된 실시예들은 컴퓨터 관련 기술의 상당한 개선을 나타낸다.
본 개시의 다양한 양태들이 이제 본 개시를 제한하는 것이 아니라 예시하기 위한 것으로 의도되는, 특정 예들 및 실시예들과 관련하여 설명될 것이다. 본원에 설명된 예들 및 실시예들이 예시, 특정 계산 및 알고리즘을 위해 초점을 맞출 것이지만, 당업자는 예들이 단지 예시일 뿐이며 제한하려는 의도가 아니라는 것을 이해할 것이다. 예를 들어, 실시예들은 "3차" 복제본을 참조하여 본원에 개시되어 있지만, 이 용어는 단지 예시 목적으로만 사용되며, 복제본이 2개의 대체 복제본들을 포함하는 시스템에 도입된다는 가정하에 사용된다. 그러나, 본 개시의 실시예들은 더 많거나 더 적은 대안 복제본들을 포함할 수 있다. 예를 들어, 일 실시예에서, 고도로 분할된 복제본은 덜 분할된 단일 복제본 또는 3개 이상의 덜 분할된 복제본들과 함께 사용될 수 있다. 따라서, 본원에 사용된 1차 또는 2차 복제본에 대한 언급은 일반적으로 덜 분할된 복제본(예를 들어, 1개와 16개의 복제본 사이에 볼륨이 분할되어 있거나, 테일 레이턴시가 표준 사용자 I/O 동작들의 응답성에 큰 영향을 미치지 않을 것으로 예상되는 다수의 복제본들) 예를 말하는 것으로 이해되어야 한다. 게다가, 실시예들은 고도로 분할된 "3차" 복제본을 참조하여 본원에서 논의되었지만, 본 개시의 일부 실시예들은 하나 이상의 고도로 분할된 복제본을 이용할 수 있으며, 이들 중 임의의 것은 단순성을 위해 "3차" 복제본으로 지칭될 수 있다. 따라서, 본원에 사용된 바와 같은, 3차 복제본에 대한 언급은 (예를 들어, 동일한 볼륨을 나타내는 덜 분할된 복제본과 관련하여)고도로 분할된 복제본을 지칭하는 것으로 이해되어야 한다. 하기에 논의된 바와 같이, 이러한 고도로 분할된 복제본은 전체 볼륨의 복제와 같은, 집약적인 I/O 동작들을 신속하게 구현할 수 있도록 충분한 수의 파티션들을 포함할 수 있다. 예를 들어, 이 파티션 수는 1000 개에서 수백만 개 사이일 수 있다. 하기에 제공된 예들은 일부 경우에 볼륨에 대한 수정을 "쓰기 동작들"로 지칭할 수 있다. "쓰기 동작"이라는 용어는 볼륨에 새 정보를 쓰거나 볼륨 내의 기존 정보를 수정 또는 삭제하는 요청을 포함하여 볼륨에 포함된 데이터를 수정하라는 모든 요청을 의미하는 것으로 이해해야 한다.
3차 복제본을 사용한 예시적인 컴퓨팅 환경의 개요
도 1a는 개시된 3차 복제본이 구현될 수 있는 탄력적 컴퓨팅 시스템(120)을 포함하는 예시적인 컴퓨팅 환경(100)을 도시한다. 탄력적 컴퓨팅 시스템(120)은 네트워크(125)를 통해 사용자 장치들(130)에 의해 액세스될 수 있다. 탄력적 컴퓨팅 시스템(120)은 그 중에서도 인스턴스들(116), 볼륨들(111) 및 버킷들(106)을 포함하는 컴퓨팅 리소스들에 대한 온-디맨드 액세스를 사용자들에게 제공하기 위해 서로 그리고 네트워크(125)와 네트워크 통신하는 하나 이상의 컴퓨팅 서버들(115), 하나 이상의 객체 저장 서버들(110) 및 하나 이상의 블록 저장 서버들(105)을 포함한다. 이러한 특정 리소스들은 하기에 더 상세하게 설명된다. 탄력적 컴퓨팅 시스템(120)의 일부 구현예들은 온-디맨드 클라우드 컴퓨팅 플랫폼들을 지원하기 위한 도메인 네임 서비스("DNS") 서버들, 관계형 데이터베이스 서버들 및 기타 서버 구성들(도시되지 않음)을 추가로 포함할 수 있다. 각 서버는 하드웨어 컴퓨터 메모리 및/또는 프로세서들, 해당 서버의 일반적인 관리 및 동작을 위한 실행 가능 프로그램 인스트럭션들을 제공하는 운영 체제, 및 서버의 프로세서에 의해 실행 시, 서버가 그 의도된 기능들을 수행하도록 하는 인스트럭션들을 저장하는 컴퓨터 판독 가능 매체를 포함한다.
탄력적 컴퓨팅 시스템(120)은 예를 들어 사용자들이 컴퓨팅 서버들(115), 객체 스토리지 서버들(110) 및 블록 저장 서버들(105)의 사용을 통해 확장 가능한 "가상 컴퓨팅 장치들"을 마음대로 가질 수 있도록, 네트워크(125)를 통해 사용자들에게 온-디맨드, 확장 가능한 컴퓨팅 플랫폼들을 제공할 수 있다. 이러한 가상 컴퓨팅 장치들은 하드웨어(다양한 유형의 프로세서들, 로컬 메모리, 랜덤 액세스 메모리("RAM"), 하드 디스크 및/또는 솔리드 스테이트 드라이브("SSD") 스토리지), 운영 체제, 네트워킹 능력 및 사전 로딩된 어플리케이션 소프트웨어를 포함한 개인용 컴퓨팅 장치의 속성들을 갖는다. 각 가상 컴퓨팅 장치는 또한 콘솔 입력 및 출력("I/O")(예를 들어, 키보드, 디스플레이 및 마우스)을 가상화 할 수 있다. 이 가상화는 사용자들이 개인용 컴퓨팅 장치처럼 가상 컴퓨팅 장치를 구성하고 사용하기 위해, 사용자들이 브라우저, 어플리케이션 프로그래밍 인터페이스, 소프트웨어 개발 키트 등과 같은 컴퓨터 어플리케이션을 사용하여 그 가상 컴퓨팅 장치에 연결할 수 있게 한다. 사용자가 이용할 수 있는 고정된 양의 하드웨어 리소스들을 보유한 개인용 컴퓨팅 장치들과 달리, 가상 컴퓨팅 장치들과 관련된 하드웨어는 사용자가 필요로 하는 리소스들에 따라 확장 또는 축소될 수 있다. 사용자들은 그들 자신의 사용 및/또는 고객들이나 클라이언트들에 의한 사용을 위해 네트워크 기반 서비스들을 제공하기 위한 가상 컴퓨팅 시스템들을 배포하도록 선택할 수 있다.
탄력적 컴퓨팅 시스템(120)은 예를 들어 그들의 지리적 위치에 또는 그 근처에 그들의 가상 컴퓨팅 장치들을 가짐으로써 사용자들에게 더 낮은 레이턴시들을 제공하기 위해, 다수의 지리적으로 분리된 영역들에 걸쳐 제공될 수 있다. 각 영역은 위치 및 전원 공급 측면에서 다른 모든 영역과 물리적으로 격리되고 독립적이며 네트워크(125)를 통해 다른 영역들과 데이터를 통신할 수 있다. 각 영역은 중복 및 별도의 전원, 네트워킹 및 연결성이 제공되는 하나 이상의 물리적 데이터 센터들에 의해 각각 지원되는 둘 이상의 이용 가능 구역들을 포함하여, 두 구역들이 동시에 고장 날 가능성을 줄일 수 있다. 단일 이용 가능 구역은 여러 데이터 센터들에 걸쳐 있을 수 있지만, 두 개의 이용 가능 구역들은 데이터 센터를 공유하지 않는다. 이는 데이터 센터 레벨 장애들로부터 사용자들을 보호할 수 있다. 데이터 센터는 컴퓨팅 서버들(115), 객체 스토리지 서버들(110) 및 블록 저장 서버들(105) 중 하나 이상을 수용하고 그에 전력 및 냉각을 제공하는 물리적 건물 또는 인클로저(enclosure)를 지칭한다. 이용 가능 구역 내의 데이터 센터들과 영역 내의 이용 가능 구역들은 예를 들어, 광섬유 네트워크 케이블들과 같은 로우 레이턴시 링크들을 통해 서로 연결된다. 컴퓨팅 하드웨어의 이러한 구획화 및 지리적 분포는 탄력적 컴퓨팅 시스템(120)이 높은 수준의 허용 오차 및 안정성으로 글로벌 규모의 사용자들에게 빠른 서비스를 제공할 수 있게 한다. 주어진 영역의 구역들에 걸쳐 고르게 리소스들을 분배하기 위해, 탄력적 컴퓨팅 시스템(120)의 제공자는 각 사용자 계정에 대한 식별자들에 이용 가능 구역들을 독립적으로 매핑시킬 수 있다.
특히 탄력적 컴퓨팅 시스템 내에서 서로 다른 서버들의 역할들을 살펴보면, 컴퓨팅 서버들(115)은 소프트웨어 시스템을 구축하고 호스팅하기 위해 사용자들에게 크기 조정 가능한 컴퓨팅 용량을 제공하는 하나 이상의 서버들을 포함한다. 사용자들은 그들이 필요한 만큼 "인스턴스들"(116)이라고 하는, 많은 가상 컴퓨팅 환경들을 런칭하기 위해 컴퓨팅 서버들(115)을 사용할 수 있다. 인스턴스들(116)은 사용자 요구에 따라 처리 능력, 메모리, 스토리지 및 네트워킹 용량의 다양한 구성들을 가질 수 있다. 컴퓨팅 서버들(115)은 또한 인스턴스가 실행되는 동안 사용되는 임시 데이터를 위한 컴퓨터 스토리지를 포함할 수 있지만, 인스턴스가 종료되는 즉시 데이터는 손실된다.
블록 저장 서버들(105)은 볼륨들(106)의 형태로 컴퓨팅 서버들(115)를 위한 영구 데이터 스토리지를 제공한다. 블록 저장 서버들(105)은 데이터가 블록들로 저장되는 하나 이상의 서버들을 포함한다. 블록은 일반적으로 블록 크기의 최대 길이를 갖는 일부 전체 레코드 수를 포함하는 바이트 또는 비트의 시퀀스이다. 블록화된 데이터는 일반적으로 데이터 버퍼에 저장되며, 한 번에 전체 블록을 읽거나 쓴다. 블록화는 오버 헤드를 줄이고 데이터 스트림의 처리 속도를 높일 수 있다. 각 블록은 저장 및 검색될 수 있는 고유 식별자가 할당되지만, 일반적으로 추가 컨텍스트를 제공하는 메타 데이터는 할당되지 않는다. 데이터 블록은 예를 들어, 구현예에 따라 512 바이트, 1 킬로바이트("kB"), 4kB, 8kB, 16kB, 32kB 또는 그 이상일 수 있다. 3차 복제본의 파티션들은 한 블록 또는 여러 블록들의 크기일 수 있다. 예를 들어, 3차 복제본의 파티션들은 객체 스토리지 서버들(110)에 의해 사용되는 최소 저장 단위의 크기와 동일한 블록들의 수 또는 객체 스토리지 서버들(110)에 대한 처리량을 최대화하는 블록들의 수로 크기 조정될 수 있다. 예를 들어, 객체 스토리지 서버들(110)이 1,000개의 블록들의 최소 저장 단위(예를 들어, 블록 크기가 1KB인 경우 1MB의 데이터)를 구현하는 경우, 3차 복제본의 각 파티션은 크기가 1000개의 블록들(1MB)일 수 있다. 반대로, 1차 및 2차 복제본들의 일반적인 파티션들은 예를 들어 사용자 볼륨의 크기에 따라 크기가 8GB 내지 62.5GB(또는 그 이상)의 범위에 있다.
예를 들어 크기가 1GB 내지 1 테라바이트(TB)의 범위에 있는 개별 하드 드라이브로 취급될 수 있는 사용자 볼륨들(106)은 블록 저장 서버들(105)에 저장된 하나 이상의 블록들로 구성된다. 개별 하드 드라이브로 취급되지만, 볼륨은 하나 이상의 기본 물리적 호스트 장치들에 구현된 하나 이상의 가상화 장치들로 저장될 수 있음이 이해될 것이다. 볼륨들(106)은 일부 구현예들에서 초당 약 1GB("Gbps")로 데이터를 전송할 수 있는 능력을 갖는 탄력적 컴퓨팅 시스템(120)의 장치에 의해 호스팅되는 각 파티션으로 적은 횟수(예를 들어, 최대 16개)로 분할될 수 있다. 이러한 볼륨들은 컴퓨팅 서버들(115)의 특정 인스턴스들에 부착될 수 있는 영구적인 전용 스토리지를 제공했다. 각 볼륨은 컴퓨팅 서버(115)에서 실행되는 단일 인스턴스에 부착될 수 있으며, 해당 인스턴스에서 분리되어 다른 인스턴스에 다시 부착될 수 있다. 도 1b에 대해 더 상세하게 설명되는 바와 같이, 블록 저장 서버들(105)은 이용 가능 구역 내의 여러 서버들에 걸쳐 볼륨을 복제함으로써 볼륨들에 대한 리던던시를 내장하고 있으며, 이는 개별 드라이브가 장애가 있거나 일부 다른 단일 장애가 발생하더라도 볼륨들이 고장 나지 않을 것임을 의미한다.
객체 스토리지 서버들(110)은 탄력적 컴퓨팅 환경(120) 내의 다른 유형의 스토리지를 나타낸다. 객체 스토리지 서버들(110)은 버킷들(111)이라고 하는 리소스들 내의 객체들로서 데이터가 저장되는 하나 이상의 서버들을 포함한다. 각 객체는 일반적으로 저장되는 데이터, 저장된 객체를 분석하는 것과 관련하여 객체 저장 서버들(110)에 대한 다양한 기능들을 가능하게 하는 가변적인 양의 메타 데이터, 및 객체를 검색하는 데 사용될 수 있는 글로벌 고유 식별자 또는 키를 포함한다. 객체 저장 서버들(110)에 저장된 객체들은 고유 식별자와 관련되어 있으므로, 객체에 대한 승인된 액세스는 임의의 위치에서 네트워크로 연결된 컴퓨팅 장치들로부터의 요청들을 통해 획득될 수 있다. 각 버킷은 주어진 사용자 계정과 관련된다. 사용자들은 버킷들에 원하는 만큼의 많은 객체들을 저장할 수 있고, 버킷들에서 객체들을 쓰고, 읽고, 삭제할 수 있으며, 버킷들 및 포함된 객체들에 대한 액세스를 제어할 수 있다. 또한, 상기에 설명된 영역들 중 서로 다른 영역들에 걸쳐 분산된 다수의 서로 다른 객체 스토리지 서버들(110)을 갖는 실시예들에서, 사용자들은 예를 들어 레이턴시의 최적화를 위해 버킷이 저장되는 영역(또는 영역들)을 선택할 수 있다. 사용자들은 몇 가지 예를 들면, 소셜 미디어 웹사이트에 사진을 저장하거나, 음악 스트리밍 웹사이트에 노래들을 저장하거나, 온라인 협업 서비스들에 파일들을 저장하는 것과 같은 목적으로 객체 저장 서버들(110)을 사용할 수 있다. 클라우드에서 개발된 어플리케이션들은 종종 객체 스토리지의 방대한 확장성과 메타데이터 특성들을 활용한다. 객체 스토리지 서버들(110)은 고도의 병렬 데이터 액세스 및 전송을 지원할 수 있다.
객체 스토리지 서버들(110)이 데이터를 다수의 이용 가능 구역들로 자동으로 복제할 수 있으므로, 객체 스토리지 서버들(110)은 블록 저장 서버들(105)보다 더 큰 리던던시를 제공할 수 있다. 객체 스토리지 서버들(110)은 또한 블록 저장 서버들(105)과 다른 데이터 처리량, 예를 들어 단일 데이터 스트림의 경우 약 20Mbps를 갖는다. 객체 스토리지 서버들(110)은 상기에 설명된 인스턴스들 및 볼륨들과 독립적으로 사용될 수 있지만, 이들은 또한 스냅샷들(예를 들어, 볼륨 데이터의 객체 저장 백업들)과 관련하여 하기에 설명되는 바와 같은 데이터 백업을 제공하는 데 사용될 수 있다.
탄력적 컴퓨팅 시스템(120)은 네트워크(125)를 통해 사용자 장치들(130)과 통신할 수 있다. 네트워크(125)는 인트라넷, 인터넷, 셀룰러 네트워크, 근거리 통신망 또는 임의의 다른 이러한 네트워크 또는 이들의 조합을 포함하는, 임의의 적절한 네트워크를 포함할 수 있다. 예시된 실시예에서, 네트워크(125)는 인터넷이다. 인터넷 또는 전술한 임의의 다른 유형의 통신 네트워크들을 통해 통신하기 위한 프로토콜들 및 컴포넌트들은 컴퓨터 통신 분야의 당업자에게 알려져 있으며 따라서 본원에서 더 상세하게 설명될 필요가 없다. 사용자 장치들(130)은 임의의 네트워크 장착 컴퓨팅 장치, 예를 들어 데스크탑 컴퓨터들, 랩톱들, 스마트폰들, 태블릿들, 전자-리더기들, 게임 콘솔들 등을 포함할 수 있다. 사용자들은 네트워크(125)를 통해 탄력적 컴퓨팅 시스템(120)에 액세스하여 자신의 데이터 및 컴퓨팅 리소스들을 보거나 관리할 뿐만 아니라, 탄력적 컴퓨팅 시스템 120)에 의해 호스팅되는 웹사이트들 및/또는 어플리케이션들을 사용할 수 있다.
사용자들은 블록 저장 서버들(105)에 저장된 볼륨들의 스냅샷들을 생성하도록 탄력적 컴퓨팅 시스템(120)에 지시할 수 있다. 일 실시예에서, 스냅샷은 객체 스토리지 서버들(110) 중 하나 이상의 볼륨 상에 데이터 사본으로서(예를 들어, 단일 객체 또는 객체들의 콜렉션으로서) 저장되는, 볼륨의 특정 시점 블록 레벨 백업이다. 객체 스토리지 서버들(110)에 대한 일반 인터페이스들을 통한 스냅샷들을 관리하는 것 외에 또는 대안으로서, 스냅샷들은 블록 저장 서버들(105)의 어플리케이션 프로그래밍 인터페이스("API")를 통해 관리될 수 있다. 일 예에서, 스냅샷들은 볼륨 내 데이터의 증분 레코드들로 구현된다. 예시적으로, 볼륨의 제1 스냅샷이 생성되면, 유효한 데이터를 포함하는 볼륨의 모든 블록들이 하나 이상의 객체들로 객체 스토리지 서버들(110)에 복사된 다음, 스냅샷 "목록(table of contents)" 또는 "매니페스트(manifest)" 파일이 하나 이상의 객체들의 레코드뿐만 아니라, 하나 이상의 객체들 각각이 대응되는 볼륨의 블록들을 포함하는 객체 스토리지 서버들(110)에 기록된다. 증분 스냅샷들의 사용으로 인해, 동일한 볼륨에 대해 후속 스냅샷들이 생성될 때 제1 스냅샷 이후 변경된 블록들만이 객체 스토리지 서버들(110)에 복사되면 되고, 목록 또는 매니페스트 파일은 각 데이터 블록의 최신 버전을 가리키도록 업데이트될 수 있다(또는 제2 목록 또는 매니페스트 파일이 생성되어, 초기 목록 또는 매니페스트 파일이 볼륨의 이전 버전의 레코드로 유지되게 할 수 있다). 초기 스냅샷은 초기 스냅샷의 시점에 볼륨을 재구성될 수 있거나, 후속 시점으로부터의 스냅샷들은 임의의 개별 후속 시점에서 전체 볼륨을 재구성하기 위해 초기 스냅샷과 함께 결합되거나 초기 스냅샷과 결합될 수 있다. 이러한 방식으로, 스냅샷들은 주어진 볼륨의 증분 백업 및 전체 백업 둘 다를 제공할 수 있다.
스냅샷을 생성할 때, 스냅 샷이 시작될 때까지 볼륨에 기록된 모든 데이터가 스냅샷에 포함될 수 있으며, 사용자들은 스냅샷에 영향을 주지 않고 스냅샷 생성 동안 그 볼륨들에 대한 I/O 동작들을 계속 수행할 수 있다. 사용자들은 예를 들어, 볼륨들의 듀플리케이트들을 생성하거나 데이터를 복원하기 위해 스냅샷으로부터 새로운 볼륨을 생성할 수 있다. 새 볼륨은 스냅샷에 저장된 모든 데이터를 포함할 것이며, 따라서 스냅샷이 시작되는 시점의 원래의 볼륨의 듀플리케이트일 것이다. 이러한 방식으로, 스냅샷들은 또한 한 이용 가능 구역에서 다른 구영으로 볼륨의 데이터를 전송하는 데 사용될 수 있다. 마찬가지로, 스냅샷들은 해당 인스턴스의 새로운 가상 머신 인스턴스를 생성하기 위해 인스턴스들을 만들 수 있다.
도 1b는 본 개시의 실시예들에 따라, 블록 저장 서버들(105)이 볼륨들의 1차, 2차 및 3차 복제본들을 저장하도록 구성될 수 있는 방법의 예를 도시한다. 블록 저장 서버들(105)은 서버들(105) 간에 블록 장치들의 콘텐트를 미러링하고 리던던트 서버들에 걸쳐 데이터를 동기식으로 복제하도록 구성된다. 도 1b는 또한 탄력적 컴퓨팅 시스템(120)의 데이터 평면(150) 및 제어 평면(155)을 도시한다. 데이터 평면(150)은 탄력적 컴퓨팅 시스템(120)을 통한 사용자 데이터의 이동을 나타내는 반면, 제어 평면(155)은 탄력적 컴퓨팅 시스템(120)을 통한 제어 신호들의 이동을 나타낸다. 당업자는 데이터 평면(150) 및 제어 평면(155)이 서버들(105)의 물리적 구성보다는 서버들(105)의 동작과 관련된 논리적 구성들을 나타낸다는 것을 이해할 것이다.
제어 평면(155)은 시스템 및 사용자 요청들을 조정하고 이들을 탄력적 컴퓨팅 시스템(120)의 적절한 서버들로 전파하기 위한 컴퓨터 실행 가능 소프트웨어를 갖는 적어도 하나의 서버에 의해 구현될 수 있는 논리적 구성이다. 제어 평면(155)의 기능들은 데이터의 복제, 장애 조치 동작, 및 데이터 평면(150)에 대해 수행될 특정 조치들에 대한 사용자들로부터의 요청들의 수신을 포함한다. 이들은 볼륨들(106)을 생성, 복제 및 스냅샷 생성하는 것을 포함할 수 있다. 예시된 실시예의 데이터 평면(150)은 1차 복제본(135), 2차 복제본(140) 및 3차 복제본(145)에 대한 동작들의 실행에 의해 구현된다.
상기에 설명된 바와 같이, 사용자 I/O 동작들은 2차 복제본(140)과 동기식으로 정보를 복제하는 블록 레벨 복제 메커니즘을 사용하여 1차 복제본(135)에서 실행될 수 있다. 1차 복제본(135) 및 2차 복제본(140)은 높아진 데이터 무결성을 위해 서로 다른 블록 저장 서버들(105A, 105B)에 프로비저닝될 수 있다. 서버들(105A, 105B)이 단일 서버로 도시되어 있지만, 일부 구현예에서 1차 복제본(135) 및 2차 복제본(140)은 각각 다수의 파티션들을 포함할 수 있으며, 각 파티션은 다른 서버에 저장될 수 있다. 볼륨의 1차 및 2차 복제본 모두는 1차 복제본(135)에 대한 임의의 I/O 동작이 2차 복제본(140)에 복제될 수 있도록 하는 블록 레벨 복제 메커니즘을 설치할 수 있다. 다수의 복제본들에 걸쳐 볼륨에 동기식 I/O 동작들을 제공하기 위한 다양한 메커니즘들이 당업계에 공지되어 있으며, 따라서 본원에서는 상세히 설명되지 않을 것을 것이다. 1차 복제본(135)의 모든 장애 또는 중단은 2차 복제본(140)에 대한 장애 조치 동작을 수행함으로써 해결될 수 있다. "새로운" 1차 복제본을 활용하기 위해 사용자 측에서 필요한 액션이 없도록, 장애 조치 동안 2차 복제본(140)에 이름이 별칭될 수 있도록 DNS 이름 또는 다른 이러한 접근 방식이 사용될 수 있다. 대안으로, 1차 복제본에 부착되는 인스턴스를 호스팅하는 서버는 볼륨의 IP 주소, 볼륨 ID 또는 2차 복제본에 연결하기 위한 기타 식별 데이터 또는 장애 조치가 발생하는 경우 앞서 언급된 데이터를 제공할 수 있는 제어 평면 시스템의 IP 주소를 메모리에 저장할 수 있다. 복제된 볼륨의 프로비저닝 및 새로운 볼륨들의 생성은 제어 평면(155)에 의해 제어될 수 있다.
1차 및 2차 복제본들은 최대 16개의 파티션들로 분할될 수 있다. 일반적으로 설명되는, 파티셔닝은 컴퓨터 스토리지에 하나 이상의 영역들을 생성하여 운영 체제가 각 영역의 정보를 개별적으로 관리할 수 있도록 하는 것으로, 각 파티션은 물리적 컴퓨터 스토리지의 일부를 사용하는 별개의 "논리적" 스토리지 장치이다. 각 파티션은 탄력적 컴퓨팅 시스템(120)의 별개의 장치에 의해 호스팅될 수 있으며, 파티션이 구현되는 호스트 장치에 이용 가능한 컴퓨팅 리소스들까지 기능적 데이터 전송 제한을 가질 수 있다. 예를 들어, 파티션이 1Gbps 네트워크 인터페이스가 있는 물리적 장치에서 호스팅되는 경우, 파티션은 1Gbps(또는 호스트 장치가 동시에 네트워크 인터페이스를 통해 전송되어야 하는 여러 파티션들을 호스팅하는 경우, 그 이하)의 기능적 데이터 전송 제한을 가질 수 있다. 상기에 설명된 바와 같이, 이 기능적 데이터 전송 제한으로 인해 특히 대용량 데이터 볼륨의 경우, 볼륨의 데이터에서 상당한 전송이 필요한 특정 사용자 액션들에 대한 레이턴시가 발생된다. 예를 들어, 사용자는 인스턴스의 여러 클론들을 생성할 수 있으며, 각 새로운 인스턴스에 부착하기 위해 관련 볼륨을 복제하기를 원할 수도 있다. 이는 예를 들어, 사용자 볼륨이 실시간 마켓 데이터를 포함하고, 사용자가 데이터를 분석하기 위해 서로 다른 알고리즘들을 테스트하는 수천 번의 실험들을 실행하여 다음 거래일까지 최상의 알고리즘을 내놓으려는 경우 유용할 수 있다. 이러한 실험들은 볼륨 내에 상주하는 소프트웨어를 기반으로 수행되며, 따라서 볼륨을 1000대의 머신들에 복제하여 실험들이 실행되도록 할 수 있다. 이는 짧은 기간 내에 많은 수의 클론들을 생성해야 하는 사용자 요구의 한 예시적인 예일뿐이라는 것이 이해될 것이다. 1차 및 2차 복제본들의 데이터 전송 대역폭은 파티션들이 호스팅되는 소스 장치들의 기능적 데이터 전송 제한에 의해 제한되며, 제어 평면(155)은 또한 (예를 들어, 표준 사용자 I/O 동작들이 클로닝 동작 동안 계속될 수 있도록) 1차 복제본(135)에서 I/O 동작들 및 2차 복제본(140)으로의 블록의 동기식 복제를 지원하기 위해 이 대역폭의 일부를 예약할 수 있다.
반대로, 3차 복제본(145)은 1차 및 2차 복제본들의 파티션들의 개수보다 더 많은 개수의 파티션들로 분할될 수 있다. 일부 실시예들에서, 이 개수는 1,000개의 파티션에서 3,200만 개의 파티션(예를 들어, 볼륨 블록 당 하나의 파티션) 범위에 있을 수 있다. 일부 실시예들에서, 3차 복제본에는 더 적은 개수의, 예를 들어 임계 시간 기간 내에 전체 볼륨이 복제되게 하거나 스냅샷이 생성되게 할 수 있는 특정 개수의 파티션들이 사용될 수 있다. 이 예에서, 네트워크 인터페이스들의 대역폭, 객체 저장소에 대한 대역폭, 볼륨 크기 및 목표 완료 시간이 사용할 파티션들의 개수를 결정하는 데 사용될 수 있다. 유리하게는, 증가된 개수의 파티션들은 3차 복제본의 데이터를 전송하는 데 사용 가능한 총 대역폭을 증가시킨다. 각 파티션은 하나 이상의 볼륨 블록들을 포함할 수 있으며, 이러한 파티션들은 탄력적 컴퓨팅 시스템(120)의 다른 장치들에 있는 컨테이너들에 저장될 수 있다. 일 실시예에서, 컨테이너는 구조화되지 않은 원시 이진 파일, 예를 들어, 이진 대형 객체(Binary Large Object; "BLOB") 데이터 파일들을 저장하고, 쿼리할 때 이들을 다시 반환한다. 제어 평면(155)은 볼륨의 데이터(예를 들어, 1차 또는 2차 복제본에 저장됨)를 개별 파티션들로 분할할 수 있으며, 그 각각은 용량이 있는 탄력적 컴퓨팅 시스템(120)(또는 지정된 영역 또는 그 이용 가능 구역)의 임의의 컨테이너에 저장될 수 있다. 이러한 컨테이너들은 추가만 가능하며 컨테이너의 스토리지 공간이 완전히 사용되면 밀봉될 수 있다(예를 들어, 스토리지의 임의의 나머지 부분이 너무 작아서 3차 복제본의 다른 파티션을 저장할 수 없다). 리던던시를 위해, 일부 구현예들에서는 컨테이너 서버들은 컨테이너들의 다수의 사본들을 복제하기 위해 컴퓨터 실행 가능 인스트럭션들로 구성될 수 있다.
3차 복제본(145)은 볼륨들의 스냅샷 생성 및 클로닝을 가속화하기 위해 탄력적 컴퓨팅 시스템(120) 내에서 새로운 리소스로 간주될 수 있다. 이 3차 복제본(145)은 한 사용자가 예를 들어 자신의 볼륨에 1000개의 클론들을 만들고 서버의 연결 대역폭을 다른 사용자들의 손해에 사용할 수 있도록 요청할 수 있는 탄력적 컴퓨팅 환경(120)에서 멀티-테넌트(multi-tenant) 서버들의 병목 현상을 유익하게 감소시킨다. 일 실시예에서, 3차 복제본(145)은 사용자들의 스냅샷 생성 및 클로닝 요청들을 지원하도록 구성될 수 있지만, 사용자에게 직접 노출되지 않을 수 있다. 일부 실시예들은 예를 들어, 다수의 새로운 볼륨들의 생성을 병렬로 공급하는 것을 지원하기 위해, 3차 복제본의 다수의 사본들을 유지할 수 있다. 3차 복제본(145)의 분산 스토리지는 객체 스토리지 서버들(110) 상의 버킷들에 대해 병렬성이 높지만 낮은 처리량 연결들을 이용하는 것뿐만 아니라, 블록 저장 서버들(105)에서 높은 처리량을 구동할 수 있는 것을 포함하여 많은 이점들을 제공한다. 3차 복제본(145)의 생성, 저장 및 사용에 관한 추가 세부 사항들이 하기에 더 상세하게 설명된다.
예시적인 3차 복제본의 개요
도 2a는 탄력적 컴퓨팅 시스템(120) 내에 분산된 3차 복제본, 예를 들어 도 1b의 3차 복제본(145)의 구현예를 생성하는 개략도(200)를 도시한다. 3차 복제본은 이 복제본의 파티션들이 컨테이너들(C1-Cn)에 저장되므로도 2a에 도시되어 있지 않다. "정적" 분산된 3차 복제본은 1차 또는 2차 복제본들로부터 동기식으로 또는 비동기식으로 블록 레벨 업데이트들을 수신하지 않는 1차 또는 2차 복제본을 말한다. 이 특정 예는 정적 분산된 3차 복제본으로 생성될 수 있지만, 일부 실시예들에서 이 복제본은 나중에, 예를 들어 도 3a 및 3b와 관련하여 설명된 바와 같은 로거 플릿에 대한 연결에 의해 1차 또는 2차 복제본들로부터 업데이트들을 수신할 수 있다.
객체 스토리지(215)는 볼륨의 스냅샷을 포함하는 상기에 설명된 객체 스토리지 서버들(110)의 하나 이상의 버킷들일 수 있다. 예시된 실시예에서, 분산 복제본 코디네이터(205A, 205N)는 객체 스토리지(215)에 저장된 스냅샷들로부터 분산된 3차 복제본의 생성을 구동하는 컴포넌트이다. 다른 실시예들은 예를 들어 1차 및/또는 2차 복제본들로부터 이를 직접 생성함으로써 객체 스토리지(215)에 도달하지 않고 3차 복제본을 생성할 수 있다.
다수의 분산 복제본 코디네이터들(205A, 205N)은 예를 들어 로거 플릿(315)에 의해 업데이트되는 3차 복제본 당 하나씩 있을 수 있다. 예시적으로, 워커들(210A-210N)은 분산 복제본 코디네이터(205A, 205N)에 의해 지시된 바와 같이 각 파티션(또는 파티션들의 범위)에 저장될 데이터를 다운로드하는 상태비보존형(stateless) 워크 플릿이다. 분산 복제본 코디네이터(205A, 205N) 및 워커들(210A-210N)은 예를 들어 컴퓨팅 서버(115)에서 인스턴스로서 실행되는 데이터 스트림 처리 클라이언트일 수 있다.
워커들(210A-210N)은 컨테이너 서버들(220) 상의 컨테이너들(C1-Cn)에 3차 복제본 파티션들을 저장하며, 예를 들어 용량이 있는 임의의 컨테이너를 선택하고 3차 볼륨 파티션을 선택된 컨테이너로 보낸다. 예시된 예에서, 각 컨테이너는 내결함성을 위해 다수의 서버들(220)에 걸쳐 복제되지만, 다른 구현예들은 컨테이너들을 복제하지 않을 수 있다. 각 컨테이너(C1-Cn)는 본질적으로 컨테이너 서버들(220) 중 하나의 파티션이다. 각 컨테이너(C1-Cn)는 다수의 3차 복제본 볼륨 파티션들을 저장하기 위한 용량을 가질 수 있다. 일 실시예에서, 각 컨테이너(C1-Cn)는 용량이 있는 한 키/값들을 저장하고 요청시 저장된 데이터를 반환하는 추가-전용 키 값 저장소를 포함한다. 사용자의 단일 볼륨에 속하는 상기에 설명된 볼륨 파티션들과 달리, 컨테이너들(C1-Cn)은 서로 다른 사용자들의 다수의 볼륨들로부터 데이터를 저장할 수 있다는 점에서 멀티-테넌트일 수 있다.
컨테이너 서버들(220)은 블록 저장 서버들(105)의 전용 서버들일 수 있거나, 상기에 설명된 볼륨들을 저장하는 블록 저장 서버들(105)과 공유될 수 있다. 객체 스토리지 서버들(110)에 저장된 스냅샷도 1차 복제본의 사본으로 간주될 수 있지만, 블록 저장 서버들(105)과 객체 저장 서버들(110)의 버킷들 사이의 각 연결은 일반적으로 처리량이 낮고 레이턴시가 높은 반면, 주어진 이용 가능한 구역 내 탄력적 블록 저장 서버들(105)은 일반적으로 높은 처리량, 낮은 레이턴시 연결로 연결된다. 따라서, 객체 스토리지 서버들(110)에 저장된 스냅샷 대신 컨테이너 서버들(220)에 저장된 3차 복제본을 사용함으로써, 전체 볼륨의 데이터를 새로운 볼륨으로 전송하는 데 필요한 시간은 몇 시간에서 몇 분으로 감소될 수 있다.
도 2b는 도 2a의 분산된 3차 복제본을 생성하기 위한 예시적인 프로세스(230)의 흐름도이다. 프로세스(230)는 일부 실시예들에서 탄력적 컴퓨팅 시스템(120)의 제어 평면(155)의 제어 하에 수행될 수 있다.
블록(235)에서, 제어 평면(155)은 3차 복제본의 생성을 제출한다. 이는 블록 저장 서버들(105)에서 특정 볼륨을 식별하고, 볼륨이 스냅샷이 되었는지를 확인하고, 볼륨의 스냅샷을 생성하지 않는 경우를 포함할 수 있다. 다른 실시예들에서, 3차 복제본의 데이터는 1차 및/또는 2차 복제본들로부터 직접 인출될 수 있다.
블록(240)에서, 분산 복제본 코디네이터(205A, 205N)는 객체 스토리지(215)로부터 객체 매니페스트 파일을 다운로드한다. 객체 매니페스트 파일은 볼륨의 블록들을 나타내는 객체들의 저장 위치들을 식별할 수 있다.
블록(245)에서, 분산 복제본 코디네이터(205A, 205N)는 예를 들어, 각 워커의 능력 및 파티션 당 블록 개수에 기초하여 3차 복제본의 하나 이상의 파티션들을 각 워커(210A-210N))에게 할당한다. 더 많은 수의 파티션들은 사용할 수 없게 되는 특정 파티션들의 (예를 들어, 스냅샷으로부터의) 재생성의 용이성을 증가시킬 수 있으며, 높은 수요(예를 들어, 장치 또는 파티션이 데이터 전송에 많이 사용되는 경우)를 처리하기 위해 컨테이너 서버들(220)에서 파티션들을 복제하며, 사용되지 않은 용량을 사용할 수 있다. 그러나, 1차 복제본의 각 파티션은 3차 복제본의 파티션들의 해당 서브셋에 대한 연결들을 유지하기 위해 필요할 수 있으며(예를 들어, 도 5A 참조), 또한 이를 유지할 수 있는 최대 연결 개수를 갖는다. 따라서, 3차 복제본 내의 파티션들 수는 특정 시스템 구성들에 따라 이러한 관심 사항들 간의 트레이드오프일 수 있다.
블록(250)에서, 서로 다른 워크들(210A-210N)은 객체 스토리지(215)로부터 그들이 담당하는 파티션들의 블록들을 다운로드한다. 각 워커는 또한 예를 들어 용량이 있는 임의의 컨테이너를 식별하는 것에 기초하여, 자신이 담당하는 각 파티션에 대한 컨테이너를 선택한 다음, 다운로드된 블록 데이터를 파티션 내에 포함시킴으로써 선택된 컨테이너에 파티션을 생성한다. 일 실시예에서, 파티션들은 컨테이너들에 걸쳐 스트라이프될 수 있으며, 여기서 스트라이핑은 연속적인 세그먼트들이 서로 다른 물리적 저장 장치들에 저장되도록 논리적으로 순차적인 데이터를 세그먼트화하는 것을 말한다. 각 파티션에 대한 컨테이너를 선택하는 이 프로세스는 예를 들어 대부분의 파티션들이 동일한 스위치를 공유하지 않도록 파티션들이 데이터 센터 내에서 지리적으로 다소 다양하다는 것을 보장할 수 있다. 또한, 컨테이너들을 선택하는 프로세스는 파티션들이 "핫(hot)"스토리지 호스트들(예를 들어, 다수의 또는 대부분의 연결 대역폭을 사용하는 호스트들)에 배치되지 않도록 후보 호스트들에서 대역폭 경합을 고려할 수 있다.
블록(255)에서, 각 워커는 자신이 담당하는 파티션에 대한 부분 매니페스트를 구성하고 이를 분산 복제본 코디네이터에게 다시 전송한다. 이러한 부분 매니페스트들은 파티션 ID(또는 블록 ID)로부터 컨테이너 ID로의 매핑일 수 있으며, 부분 매니페스트들은 3차 복제본의 파티션들의 스토리지 위치들을 식별하는 매니페스트 파일로 어셈블링될 수 있다. 3차 복제본(145)의 분산 스토리지는 주어진 볼륨에 대한 블록들을 갖는 모든 컨테이너들을 찾는 문제를 야기한다. 매니페스트 파일은 3차 복제본의 각 파티션을 파티션이 있는 컨테이너에 매핑시키기 때문에, 이 문제에 대한 솔루션이다. 요청 시 파티션이 사용될 수 없는 경우, 제어 평면(155)은 객체 스토리지 서버들(110)에서 파티션의 스냅샷 표현의 위치를 식별하기 위해 객체 매니페스트 파일을 사용하고 스냅샷으로부터 다운로드를 다시 구동시킬 수 있다.
블록(260)에서, 분산 복제본 코디네이터(205A, 205N)는 서로 다른 워커들(210A-210N)로부터의 부분 매니페스트들을 완전한 분산 볼륨 매니페스트로(예를 들어, 분산된 3차 복제본의 모든 파티션들에 대한 파티션 ID에서 컨테이너 ID로) 어셈블링하고 이를 객체 스토리지(215)에 저장한다. 이 동작이 완료되면, 분산 복제본 코디네이터(205A, 205N)는 제어 평면(155)에 통지할 수 있으며 프로세스(230)는 종료된다.
3차 복제본에 대한 예시적인 업데이트들의 개요
도 3a는 탄력적 컴퓨팅 시스템(120) 내의 1차 복제본과 분산된 3차 복제본, 예를 들어 도 1b의 3차 복제본(145) 사이에서 데이터 업데이트들을 복제하는 개략도(300)를 도시한다. 3차 복제본은 이 복제본의 파티션들이 컨테이너들(C1-Cn)에 저장되므로 도 3a에 도시되어 있지 않다. 분산된 3차 복제본(145)의 이 구현은 1차 복제본의 비동기식 사본으로 유지된다.
사용자는 클라이언트(305)를 통해 1차 복제본에서 I/O 동작들을 수행할 수 있다. 1차 복제본은 예시적으로 블록 저장 서버들(105)의 제1 블록 저장 서버(310)에 저장된다. 이 서버(310)는 업데이트들의 로그를 유지하고 이 로그를 사용하여 예를 들어 하기에 설명된 바와 같은 로거 플릿(315)을 통해 3차 복제본을 업데이트할 수 있다. 2차 복제본은 제2 블록 저장 서버(도시되지 않음)에 저장된다. 도 3a는 업데이트들(330)을 로거 플릿(315)에 전파하는 1차 복제본의 서버(310)를 도시하지만, 다른 구현예들에서 로거 플릿(315)으로의 업데이트들(330)의 전파는 예를 들어, I/O 동작들(325)을 처리하기 위해 제1 서버의 더 많은 대역폭을 보존하기 위해 2차 복제본이 1차 복제본과 동기식으로 유지되기 때문에, 2차 복제본의 서버에 의해 수행될 수 있다.
도 2a와 관련하여 설명된 바와 같이, 분산된 3차 복제본은 컨테이너 서버들(220)의 컨테이너들(C1-Cn)에 볼륨의 수천 또는 수백만 개의 파티션들로 저장된다. 그러나, 이 실시예에서, 분산된 3차 복제본은 1차 복제본으로부터 블록 레벨 업데이트들을 수신한다. 3차 복제본의 파티션들의 지리적 다양성은 2차 복제본에 의해 경험될 수 있는 것보다 업데이트 복제에 대한 더 큰 레이턴시를 초래할 수 있지만, 이는 3차 복제본으로부터의 병렬 데이터 전송 능력이 증가한다는 점에서 허용될 수 있다. 2차 복제본은 동기식으로(예를 들어, 1차 복제본에 대한 데이터 쓰기와 동시에) 복제되는 반면, 제3 복제본에 대한 업데이트들은 비동기식으로(예를 들어, 1차 복제본에 대한 데이터 쓰기 이후) 복제될 수 있다. 예를 들어, 사용자가 스냅샷 또는 클론을 생성할 것을 요청하고 3차 본제본이 이를 위해 사용될 경우, 업데이트들은 이들이 최신 상태인지를 확인하기 위해 3차 복제본으로 전파될 수 있다. 이후, 3차 복제본은 스냅샷 또는 클론이 3차 복제본으로부터 생성되는 동안 "동결(frozen)"될 수 있다. 동결되는 동안, 3차 복제본은 데이터를 클론 또는 스냅샷으로 전송하는 동안 1차 복제본에 대한 임의의 새로운 쓰기를 일시적으로 유지할 수 있으며, 클로닝 또는 스냅샷 생성 프로세스를 완료한 후 이러한 업데이트들을 적절한 파티션들에 순차적으로 쓸 수 있다.
예시적인 실시예에서, 로거 플릿(315)은 3차 복제본과 1차 복제본 사이의 매개물이다. 로거 플릿(315)은 예를 들어 하나 이상의 컴퓨팅 서버들(115)에서 하나 이상의 인스턴스들로서 실행되는, 데이터 스트림 처리 클라이언트일 수 있다. 예시적으로, 로거 플릿(315)은 AMAZON KINESISTM 서비스 또는 APACHE KAFKATM 소프트웨어를 통해 구현될 수 있으며, 그 동작은 당업계에 공지되어 있다. 로거 플릿(315)을 활용함으로써, 3차 복제본을 최신 상태로 유지하기 위한 로직이 탄력적 블록 스토리지 서버(310)로부터 오프로드될 수 있으며, 블록 저장 서버(310)의 메모리 사용이 감소될 수 있다. 예시적으로, 로거 플릿(315)은 1차 복제본으로부터 업데이트들을 수신하고 이들을 3차 복제본에 직렬 방식으로 적용한다. 로거 플릿(315)은 1차 복제본으로부터 업데이트들을 꺼내올 수 있거나 1차 복제본이 로거 플릿(315)에 업데이트들을 푸시할 수 있다. 특히, 로거 플릿(315)은 블록 저장 서버(310)로부터 업데이트들(330)을 수신한 다음, 이러한 업데이트들을 컨테이너들(C1-Cn) 중 적절한 컨테이너들로 전파한다. 컨테이너 서버가 다운되면, 로거 플릿(315) 없이 1차 복제본의 일부 실시예들은 업데이트 로그에 백업될 수 있으며, 이는 제어 평면(155)이 사용자 I/O 동작들을 스로틀링하기 시작하도록 트리거될 수 있다. 유리하게는, 예시된 실시예에서, 1차 복제본은 일정 기간(예를 들어, 24 시간) 동안 이들을 저장할 수 있는 로거 플릿(315)에 업데이트들을 전송할 수 있다. 로거 플릿(315)은 이 시간 기간 동안 3차 복제본을 업데이트할 수 있다. 로거 플릿(315)은 각각 스트림을 형성하는 순차적 업데이트들(예를 들어, 볼륨에 대한 업데이트의 변경 로그)를 수신하고 업데이트들을 3차 복제본에 전파하는 다수의 워커들을 가질 수 있다. 일부 실시예들에서, 로거 플릿(315)은 서로 다른 볼륨들의 다수의 3차 복제본들을 관리할 수 있으며, 로그 스트림은 이러한 서로 다른 볼륨들에 대한 순차적 업데이트들의 변경 로그들을 나타낼 수 있다.
대안 실시예에서, 로거 플릿(315) 대신, 마스터 슬레이브 아키텍처는 업데이트들을 3차 복제본으로 푸시하는 데 사용될 수 있으며, 1차 복제본은 마스터이고 2차 복제본은 3차 복제본에 업데이트들을 푸시하는 슬레이브이다. 마스터는 3차 복제본의 각 파티션이 저장되어 위치를 알 수 있으며, 이러한 파티션들이 얼마나 최신 상태인지에 대한 로그를 유지할 수도 있다. 마스터는 슬레이브를 업데이트할 수 있으며, 이는 그런 다음 업데이트들을 3차 복제본으로 푸시할 수 있다. 1차 및/또는 2차 복제본들은 3차 복제본에 대한 쓰기들의 확인 응답(acknowledgement)을 수신할 수 있다. 해당 확인 응답이 없는 임의의 업데이트들의 경우, 1차 및/또는 2차 복제본들은 해당 업데이트를 3차 복제본의 적절한 파티션으로 재전송할 수 있다.
일부 실시예들은 마스터가 로거 플릿(315)을 업데이트하고 로거 플릿(315)이 슬레이브를 업데이트하도록 마스터와 슬레이브 사이에 로거 플릿(315)을 유리하게 위치시킬 수 있다. 마스터는 로거 플릿(315)이 업데이트들을 수신하는지를 확인하기만 하면 되며, 그런 다음 로거 플릿(315)은 업데이트들이 3차 복제본에 의해 수신되었음을 확인한다. 마스터-슬레이브 접근 방식과 비교하여 로거 플릿(315)에 의해 제공되는 한 가지 이점은 3차 복제본의 더 큰 정도의 파티셔닝 및/또는 분산을 가능하게 한다는 점이다. 마스터가 업데이트들을 3차 복제본으로 푸시하는 경우, 마스터는 자체 내에 3차 복제본에 대한 모든 메타 데이터 및 로직을 포함해야할 수 있다.
도 3b는 도 3a의 분산된 3차 복제본을 업데이트하기 위한 예시적인 프로세스(320)의 흐름도이다. 프로세스(320)는 일부 실시예들에서 탄력적 컴퓨팅 시스템(120)의 제어 평면(155)의 제어 하에 수행될 수 있다.
블록(325)에서, 사용자는 1차 복제본에서 I/O 동작을 수행한다. 이는 예를 들어 새로운 데이터의 쓰기, 기존 데이터의 변경 또는 기존 데이터의 삭제를 포함할 수 있다.
블록(330)에서, 1차 복제본은 상기에 설명된 바와 같이 이 업데이트를 로거 플릿(315)으로 전송한다. 업데이트는 업데이트들의 시퀀스 및 기타 명령들(예를 들어, 스냅샷 및 클론 명령들)을 포함하는 로그 스트림의 일부일 수 있다. 로거 플릿(315)은 비순차적 업데이트들을 거부하는 인텔리전스가 제공될 수 있다.
블록(335)에서, 로거 플릿(315)은 업데이트에 대응되는 파티션들을 저장하는 임의의 컨테이너들을 식별한다. 이는 변경된 볼륨의 블록들을 식별하고 분산 볼륨 매니페스트에서 이러한 블록들에 대응되는 파티션들을 저장하는 컨테이너들을 찾는 것을 포함할 수 있다.
블록(340)에서, 로거 플릿(315)은 업데이트에 따라 3차 복제본을 업데이트하기 위해 컨테이너들에 업데이트들을 전송한다. 이는 비동식으로 수행될 수 있다. 상기에 설명된 바와 같이, 3차 복제본의 일부가 사용될 수 없는 경우, 로거 플릿(315)은 해당 부분이 이용 가능해질 때까지 업데이트들을 유지할 수 있다. 일부 예들에서, 사용자 I/O가 처음 두 복제본들에 대한 대역폭을 사용하는 경우, 1차 및 2차 복제본들은 사용자 경험을 유지하기 위해 3차 복제본에 대한 업데이트들의 전파를 지연시킬 수 있다.
선댁적으로, 블록(345)에서, 로거 플릿은 업데이트 로그들을 객체 스토리지(215)에 백업할 수 있다. 이는 업데이트 로그를 사용하여 새로운 볼륨들의 생성을 허용 시 스냅샷 백업과 유사하게 기능할 수 있다. 이와 같이, 일부 실시예들에서, 객체 스토리지(215)의 업데이트 로그들은 볼륨의 스냅샷이 생성되면 삭제될 수 있으며, 이후 새로운 업데이트 로그들이 주기적으로 객체 스토리지에 백업될 수 있다. 새로운 볼륨은 스냅샷을 업데이트하기 위해 업데이트 로그를 사용하여 생성될 수 있다. 이와 같이, 객체 스토리지(215)에 업데이트 로그들을 저장하는 것은 스냅샷만을 저장하는 것보다 더 세밀한 데이터 복구를 제공한다. 상기에 설명된 바와 같이, 객체 스토리지 서버들(110)은 사용 가능 구역들에 걸쳐 버킷들을 복제하도록 구성될 수 있는 반면, 블록 저장 서버들(105)은 사용 가능 구역 내에서만 볼륨들을 복제할 수 있다. 따라서, 업데이트 로그들을 객체 스토리지(215)에 백업하는 것은 사용 가능 구역 장애의 경우에도 사용자의 데이터가 지속될 가능성을 증가시킬 수 있다.
결정 블록(350)에서, 로거 플릿(315)은 로그 스트림이 스냅샷 요청을 포함하는지 여부를 결정한다. 스냅샷 요청은 3차 복제본에 도달할 때까지 3차 복제본이 스냅샷에 필요한 임의의 업데이트들을 수신할 수 있도록 로그 스트림의 일부일 수 있다. 스냅샷 요청이 있는 경우, 블록(355)에서 컨테이너들은 그 파티션들을 객체 스토리지(215)로 푸시하여, 스냅샷 요청 시점에 3차 복제본의 스냅샷을 생성한다. 예를 들어, 1차 복제본은 스냅샷 요청들을 로그 스트림으로 주입할 수 있다. 로거 플릿(315)의 각각의 로깅 머신들은 메시지를 3차 복제본의 파티션들로 전파할 것이며, 이는 파티션들 내의 데이터를 객체로서 병렬 방식으로 객체 스토리지(215)에 저장할 수 있으며, 따라서 스냅샷의 신속한 생성을 가능하게 한다. 이러한 스냅샷 생성의 병렬화는 1차 또는 2차 복제본이 동일한 양의 데이터를 객체 스토리지(215)로 푸시하기를 기다리는 것보다 훨씬 더 빠르게 스냅샷들을 생성할 수 있다. 대안으로, 로그 스트림 내에 스냅샷 요청이 없는 경우, 프로세스는 블록(360)으로 전환된다.
결정 블록(360)에서, 로거 플릿(315)은 로그 스트림이 체크포인트 요청을 포함하는지 여부를 결정한다. 있는 경우, 블록(365)에서, 컨테이너들은 프로세스(230)와 관련하여 상기에 설명된 바와 같이 해당 시점의 볼륨을 나타내는 새로운 3차 복제본을 생성하는 데 사용된다. 예를 들어, 1차 복제본은 체크포인트 요청들을 로그 스트림으로 주입할 수 있다. 로거 플릿(315)은 그 후 해당 체크 포인트 요청을 3차 복제본의 모든 파티션으로 전송할 수 있다. 그런 다음, 3차 복제본의 각 파티션은 동일한 또는 다른 컨테이너 내의 새 파티션으로 데이터를 푸시하여, 3차 복제본의 추가 시점 복제본을 생성할 수 있다.
3차 복제본으로부터의 예시적인 클론 생성의 개요
도 4a는 탄력적 컴퓨팅 시스템(120) 내의 분산된 3차 복제본으로부터 볼륨의 클론을 생성하는 개략도(400)를 도시한다. 본원에 설명된 바와 같이, 고도로 분산된 특성으로 인해 3차 복제본은 주어진 볼륨의 많은 데이터 조각들이 동시에 전송될 수 있는 높은 수준의 병렬 처리를 지원한다. 클론은 결정된 개수의 파티션들(405)("지오메트리")을 갖는 타겟 볼륨(401)으로 생성된다. 파티션들(405)은 상기에 설명된 블록 저장 서버들(105) 중 하나 이상에 저장될 수 있다.
도 4a의 상호 작용에 대한 추가 설명은 도 4b를 참조하여 설명될 것이다. 구체적으로, 도 4b는 도 4a에 따른 분산된 3차 복제본 내에 저장된 정보에 기초하여 새로운 데이터 볼륨(예를 들어, 볼륨의 1차 및 2차 복제본으로서)의 클론 생성을 위한 예시적인 프로세스의 흐름도이다. 프로세스(410)는 일부 실시예들에서 탄력적 컴퓨팅 시스템(120)의 제어 평면(155)의 제어 하에 수행될 수 있다.
블록(415)에서, 제어 평면(155)은 파티션들(405)에 타겟 볼륨(401)을 생성한다. 타겟 볼륨(401)은 3차 복제본을 사용하여 생성될 새로운 볼륨을 말한다.
블록(420)에서, 제어 평면(155)은 객체 스토리지(215)로부터 분산 볼륨 매니페스트를 페치하고 매니페스트(또는 매니페스트의 일부)를 타겟 볼륨 파티션들(405)에 저장한다. 상기에 설명된 바와 같이, 분산 볼륨 매니페스트는 파티션 ID를 3차 복제본의 각 파티션에 대한 컨테이너 ID에 매핑시킨다. 일부 구현예들에서, 타겟 볼륨(401)의 각 파티션에는 타겟 볼륨 파티션에 쓰여 지게 될 3차 복제본 파티션들의 컨테이너 위치들을 식별하는 분산 볼륨 매니페스트의 관련 서브셋이 제공될 수 있다.
블록(425)에서, 타겟 볼륨의 각 파티션은 관련 컨테이너들로부터 분산 볼륨 매니페스트의 관련 부분에 나열된 파티션들의 데이터를 검색한다. "겟(get)" 오류가 있는 경우, 즉 볼륨의 사용자가 아직 타겟 볼륨으로 검색되지 않은 파티션의 데이터에 액세스하려고 시도하려는 경우, 타겟 볼륨(401)은 해당 파티션을 호스팅하는 컨테이너로의 겟을 수행할 수 있다. 도 4a는 타겟 볼륨(401)의 해당 파티션(405)으로의 3차 복제본의 단일 파티션의 단일 페치를 도시하고, 이러한 페칭은 3차 복제본의 각각의 필요한 파티션이 페치될 때까지 예시적으로 반복될 수 있다. 도 4a는 각각의 컨테이너 서버(220)로부터 파티션들(405) 중 하나로 이어지는 단일 화살표를 도시하지만, 이는 도면에서 단순성과 명료함을 위한 것으로, 각각의 파티션은 다수의 또는 모든 컨테이너 서버들(220)로부터 데이터를 수신할 수 있다는 것이 이해될 것이다. 컨테이너가 응답하지 않는 경우, 타겟 볼륨(401)은 객체 스토리지로부터 분산 볼륨 매니페스트 내에서 식별된 파티션의 데이터를 검색하기 위해 도 2a 및 2b와 관련하여 설명된 객체 스토리지 매니페스트를 사용할 수 있다.
블록(425)에서, 타겟 볼륨(401)은 새로운 볼륨을 생성하는 것 완료되면 객체 스토리지(215)에 신호를 전송한다.
3차 복제본으로부터의 예시적인 스냅샷 생성의 개요
도 5a는 탄력적 컴퓨팅 시스템(100) 내의 분산된 3차 복제본으로부터 볼륨의 스냅샷 백업을 생성하는 개략도를 도시한다. 상기에 설명된 바와 같이, 스냅샷은 객체 스토리지(215)의 볼륨 상에 데이터 사본으로서(예를 들어, 단일 객체 또는 객체들의 콜렉션으로서) 저장되는, 볼륨의 특정 시점 블록 레벨 백업이다. 일부 구현예들에서, 스냅샷들은 볼륨의 제1 스냅샷이 생성될 때 유효한 데이터를 포함하는 볼륨의 모든 블록들이 하나 이상의 객체들로 객체 스토리지(215)에 복사되고, 동일한 볼륨의 후속 스냅샷들이 생성될 때 제1 스냅샷 이후 변경된 블록들만이 객체 스토리지(215)에 복사하면 되도록 볼륨 내 데이터의 증분 레코드들로 구현된다. 스냅샷을 생성할 때, 스냅 샷이 시작될 때까지 볼륨에 기록된 모든 데이터가 스냅샷에 포함될 수 있으며, 사용자들은 스냅샷에 영향을 주지 않고 스냅샷 생성 동안 그 볼륨들에 대한 I/O 동작들을 계속 수행할 수 있다.
3차 복제본의 고도로 분산된 특성은 볼륨의 많은 부분들이 동시에 전송될 수 있는 높은 수준의 병렬 처리를 지원하여, 객체 스토리지(215)에서 신속한 백업들의 생성을 지원한다. 예시된 바와 같이, 사용자는 클라이언트(305)로부터 1차 복제본(하나 이상의 블록 저장 서버들(310)에 저장됨)으로 스냅샷 요청(510)을 만들 수 있으며, 이는 차례로 데이터를 객체 스토리지(215)로 전송하여 스냅샷 백업을 생성하도록 컨테이너 서버들(220)에 저장된 3차 복제본의 파티션들에 인스트럭션들을 전송한다. 도 3b의 블록들(350 및 355)와 관련하여 상기에 설명된 바와 같이, 스냅샷 생성 프로세스는 일부 구현예들에서 업데이트 스트림의 스냅샷 요청들을 따라 3차 복제본으로 전달하는 로거 플릿(315)을 포함할 수 있다.
도 5a의 상호 작용에 대한 추가 설명은 도 5b 및 5c를 참조하여 설명될 것이다. 구체적으로, 도 5b 및 5c는 도 5a에 따른 분산된 3차 복제본으로부터 스냅샷 생성을 위한 예시적인 프로세스들(505A, 505B)의 두 구현예들의 흐름도들이다. 프로세스들(505A, 505B)의 공통 블록들은 프로세스들(505A, 505B)의 서로 다른 블록들을 개별적으로 다루는 설명과 하기에 함께 설명된다. 프로세스들(505A, 505B)은 일부 실시예들에서 탄력적 컴퓨팅 시스템(120)의 제어 평면(155)의 제어 하에 수행될 수 있다.
도 5b 및 5c 둘 다를 참조하면, 블록(510)에서, 그 볼륨의 스냅샷을 만들기 위한 사용자 요청은 1차 복제본을 호스팅하는 블록 저장 서버들(310)의 클라이언트들(305)로부터 수신된다. 상기에 설명된 바와 같이, 스냅샷은 객체 스토리지 서버들(110)에 저장된 볼륨의 데이터의 백업 사본이며, 이는 사용 가능 구역들에 걸쳐 데이터를 자동으로 복제하기 위한 객체 스토리지 서버들(110)의 구성으로 인해 블록 저장 서버들(105)에 저장된 사본들에 비해 더 큰 내결함성의 이점을 제공할 수 있다. 이와 같이, 일부 사용자들은 객체 스토리지(215)에 데이터의 업데이트된 백업들을 유지하기 위해 빈번한 스냅샷들을 요청하며, 이러한 스냅샷들을 생성하기 위해 높은 대역폭 사용량을 필요로 한다.
블록(515)에서, 1차 복제본을 호스팅하는 블록 저장 서버(310) 세트는 컨테이너 서버들(220)에 저장된 3차 복제본의 파티션들로 스냅샷 요청을 전파한다. 일부 실시예들에서, 1차 복제본의 블록 저장 서버들(310)은 이 태스크를 2차 복제본을 호스팅하는 블록 스저장 서버(들)(310)로 오프로드할 수 있다. 상기에 설명된 바와 같이, 일부 구현예들에서, 스냅샷을 생성하는 것은 마지막 백업 이후 업데이트들을 받은 볼륨의 파티션들만이 객체 스토리지로 전송되는 증분 프로세스일 수 있다. 증분 스냅샷 구현예들에서, 1차 복제본을 호스팅하는 블록 저장 서버들(310)은 또한 백업 맵(backup map)을 유지하고 스냅샷 요청과 함께 이 백업 맵을 전송할 수 있다. 백업 맵은 볼륨의 이전 스냅샷(예를 들어, 바로 이전 스냅샷) 이후에 수정된 볼륨의 일부들(예를 들어, 블록들, 블록들의 콜렉션들 등)의 매핑 또는 목록을 말한다. 스냅샷이 생성될 때, 블록 저장 서버들(310)은 각 부분이 마지막 스냅샷 이후 수정되지 않았음을 반영하도록 백업 맵을 수정할 수 있다. 사용자가 볼륨의 일부들을 수정할 때, 1차 복제본을 호스팅하는 블록 저장 서버들(310) 중 하나 이상(또는 탄력적 컴퓨팅 시스템의 다른 컴퓨팅 장치)은 이러한 블록들이 이전 스냅샷 이후 수정되었음을 반영하도록 백업 맵을 수정할 수 있다. 3차 복제본 파티션들을 호스팅하는 컨테이너 서버들(220)은 이 스냅샷 요청에 응답하여 객체 스토리지(215)로 전송되어야 하는 임의의 부분들(예를 들어, 이전 스냅샷 이후 수정된 부분들)을 식별하기 위해 백업 맵을 사용할 수 있다.
3차 복제본을 호스팅하는 컨테이너 서버들(220)이 스냅샷 요청을 수신한 후, 도 5b 및 5c의 서브 프로세스들 (520A 및 520B)에 의해 반영된 바와 같이, 프로세스의 2개의 서로 다른 구현예들 중 하나가 수행될 수 있다. 구체적으로 도 5b를 참조하면, 서브 프로세스(520A)는 3차 복제본으로부터 직접 스냅샷을 생성하는 프로세스(505A)의 제1 구현예를 반영한다.
구체적으로 도 5b를 참조하면, 블록(540)에서, 컨테이너 서버들(220)은 3차 복제본의 파티션들의 데이터를 객체 스토리지(215)로 전송한다. 컨테이너 서버들(220)은 이러한 파티션들의 일부 또는 전부의 데이터를 객체 스토리지(215)에 병렬로 전송할 수 있다. 도 5a에서, 객체 스토리지(215)는 단일 객체로 도시되어 있지만, 객체 스토리지(215)는 사실상 컨테이너 서버들(220)에 대한 다중 물리적 연결들을 갖는 분산 시스템으로 표현될 수 있다. 따라서, 3차 복제본의 파티션들의 데이터는 많은 수의 서로 다른 물리적 연결들을 따라 전송될 수 있다. 각 데이터 전송은 예를 들어, 개별 HTTP 연결일 수 있다. 유리하게, 개시된 3차 복제본 아키텍처는 소스측(예를 들어, 컨테이너 서버들(220)) 및 목적지측(예를 들어, 객체 스토리지(215))의 높은 대역폭 둘 다를 제공한다. 더 많은 물리적 연결들로부터의 더 큰 대역폭 외에, 개시된 3차 복제본의 사용은 각 장치는 객체 스토리지(215)에 대한 연결들의 작은 부분만 유지하면 되기 때문에, 각 컨테이너 서버(220)에서 병렬화의 메모리 요구 사항을 감소시킬 수 있다.
유리하게, 이 기술은 1차 및 2차 복제본들의 제한된 수의 파티션들로부터 동일한 데이터를 전송하는 것과 관련하여 스냅샷을 생성하는 시간을 단축할 수 있으며, 이는 또한 계속되는 사용자 I/O 동작들을 처리하기 위해 1차 및 2차 복제본들의 데이터 전송 대역폭을 확보할 수 있다. 실제로, 덜 파티셔닝된 1차 또는 2차 복제본의 사용과 달리, 스냅샷을 생성하기 위해 고도로 파티셔닝된 3차 복제본의 사용은 예를 들어 쓰기에 필요한 시간을 10 시간(예를 들어, 덜 파티셔닝된 복제본으로부터 쓰는 경우)에서 단 1시간까지 감소시켜 스냅샷을 객체 스토리지(215)에 쓰는 데 필요한 시간을 크게 감소시킬 수 있다.
계속해서 도 5b를 참조하면, 스냅샷이 3차 복제본에서 생성되는 동안 1차 복제본에서 사용자 I/O 동작들이 계속되는 경우, 블록(545)에서, 3차 복제본의 특정 파티션들에 필요한 임의의 업데이트들은 예를 들어, 로거 플릿(315) 또는 업데이트 슬레이브(예를 들어, 2차 복제본)에 의해 보류될 수 있다. 업데이트들은 전체 스냅샷이 완료될 때까지 또는 이러한 업데이트들 위해 지정된 파티션들이 데이터를 객체 스토리지(215)로 전송하는 것을 완료할 때까지 유지될 수 있다.
이제 도 5c를 참조하면, 블록(520B)은 3차 복제본("추가 3차 복제본" 이라고 함)의 시점 사본을 생성하는 프로세스(505B)의 제2 구현예를 반영한다. 추가 3차 복제본은 스냅샷 요청시 볼륨의 데이터를 나타내지만, 원래의 3차 복제본은 1차 복제본에 대한 쓰기에 기초하여 계속 업데이트될 수 있다.
계속해서 도 5c를 참조하면, 블록(525)에서, 컨테이너 서버들(220)은 추가적인 3차 복제본을 생성하기 위해 3차 복제본의 파티션들을 복사한다. 예를 들어, 3차 복제본의 각 파티션(또는 백업 맵의 블록들에 대응되는 서브셋)은 원래의 파티션과 동일한 컨테이너 또는 다른 컨테이너로 복사될 수 있다. 이러한 추가 3차 복제본 파티션 사본들은 사본이 스냅샷 요청 시점의 데이터의 볼륨을 반영하도록 (적어도 객체 스토리지(215)의 스냅샷으로 데이터를 전송하는 기간 동안) 1차 복제본에서 사용자 I/O 동작들에 기초하는 임의의 추가 업데이트들을 수신하지 않는다.
블록(525)으로부터, 프로세스(505B)는 추가적인 3차 복제본의 파티션들이 그들의 데이터를 객체 스토리지(215)로 전송하는 블록(530)으로 이동한다. 이들 파티션들 중 일부 또는 전부는 객체 스토리지(215)에 병렬로 데이터를 전송할 수 있으며, 도 5b의 블록(540)에 대해 설명된 것과 유사한 이점들을 제공한다.
스냅샷이 생성되는 동안 1차 복제본에서 사용자 I/O 동작들이 계속되는 경우, 블록(535)에서 원래의 3차 복제본 사본의 파티션들이 사용자 I/O 동작들에 대한 응답하여 업데이트될 수 있다. 유리하게, 스냅샷 생성을 지원하기 위해 추가의 3차 복제본을 사용하는 접근 방식은 스냅샷을 위해 볼륨 데이터를 객체 스토리지(215)로 전송하기 위해 원래의 3차 복제본 사본의 파티션들이 필요하지 않기 때문에,예를 들어, 도 3a 및 3b와 관련하여 설명된 바와 같이 지속적인 사용자 I/O 동작들로 인해 업데이트들을 계속 수신하도록 원래의 3차 복제본을 확보한다.
도 5c의 블록(535) 또는 도 5b의 블록(545)로부터, 프로세스들(505A, 505B)는 3차 복제본(또는 그 사본)의 파티션들이 데이터 전송이 완료될 때 1차 복제본에 신호를 보내는 블록(550)으로 전환된다. 그런 다음, 1차 복제본은 볼륨의 각 블록(또는 일부 다른 부분)이 객체 스토리지(215)에 저장되는 위치를 나타내는 객체 매니페스트를 생성할 수 있다. 객체 매니페스트와 관련하여, 각 컨테이너(C1-Cn) 또는 컨테이너 서버(220)는 객체 스토리지(215) 내에서 볼륨 데이터의 각 객체 표현을 어디에 배치했는지 알 수 있다. 따라서, 매니페스트 생성을 제어하는 서버(예를 들어, 1차 복제본을 제어하는 서버)는 각각의 컨테이너 서버들로부터 해당 위치들을 수집하고 이들을 볼륨의 일부들(예를 들어, 블록들)을 객체 스토리지(215) 내의 객체들에 맵핑시키는 데이터 파일로 컴파일링할 수 있다.
상기에 설명된 바와 같이, 매니페스트는 증분 스냅샷 생성이 사용될 때 이전 스냅샷들을 참조할 수도 있다. 그래서, 예를 들어, 매니페스트는 이전 매니페스트 내에서 식별된 블록들(1-433)의 위치를 나타낼 수 있으며, 이전 매니페스트는 더 오래된 매니페스트 등을 참조할 수 있다. 대안으로, 매니페스트 생성 장치는 단일 매니페스트 파일이 볼륨 데이터 부분들의 위치들을 포함하도록 수정되지 않은 블록들의 객체 표현의 위치들을 이전 매니페스트로부터 현재 매니페스트로 직접 통합할 수 있다.
선택적으로, 일부 구현예들에서, 프로세스(505) 동안 임의의 추가 3차 복제본이 생성된 경우, 이 시점에서 추가 3차 복제본이 삭제될 수 있다. 다른 구현예들에서, 추가 3차 복제본은 예를 들어 사용자가 볼륨의 새로운 클론들을 생성할 수 있도록 일정 기간 동안 보관될 수 있다. 이와 같이, 프로세스(505)는 클라이언트(505)로부터 임의의 클로닝 인스트럭션들을 확인하는 것 및/또는 추가적인 3차 복제본을 삭제하기 전에 소정의 시간 동안 이러한 인스트럭션들을 기다리는 것을 포함할 수 있다.
프로세스들(505A, 505B)이 단일 스냅샷과 관련하여 설명되어 있지만, 이들은 예를 들어 사용자가 매 쓰기 이후 스냅샷을 요청하는 경우, 동시에 여러 번 또는 적어도 부분적으로 동시에 구현될 수 있다. 이러한 구현예들에서, 프로세스들(505A, 505B)의 한 반복은 제1 스냅샷을 생성하는 것일 수 있는 반면, 또 다른 반복은 제2 스냅샷을 생성하는 것이다.
로깅 플릿을 구현하는 실시예들의 개요
도 6 내지 9b를 참조하면, 로거 플릿(315)을 구현하는 본 개시의 예시적인 실시예들이 설명될 것이다. 상기에 언급된 바와 같이, 로거 플릿(315)은 일부 실시예들에서는 3차 복제본을 업데이트하는 기능들이 예를 들어 1차 또는 2차 복제본을 구현하는 장치들로부터 오프로드되도록 분산된 3차 복제본의 비동기식 업데이팅을 용이하게 할 수 있다. 로거 플릿(315)은 메시지들의 스트림으로 볼륨에 대한 수정들의 레코드를 유지하는 것과 같은(예를 들어, 각 메시지가 볼륨에 대한 수정을 반영하는 경우), 다른 기능들을 추가로 또는 대안으로 제공할 수 있다. 하기에 설명되는 바와 같이, 볼륨에 대한 메시지 스트림을 유지하는 것은 (예를 들어, 스트림의 메지시들에 반영된 수정들을 되돌리는 것에 기초하여 볼륨을 이전 시간으로 "리와인딩"함으로써) 메시지 스트림 내에 반영된 임의의 이전 상태로 볼륨을 되돌리는 기능과 같은, 많은 이점들을 제공할 수 있다.
도 6을 참조하면, 로거 플릿이 볼륨에 대한 수정들을 반영하는 메시지들의 스트림을 유지할 수 있도록 하는 예시적인 상호 작용들(600)이 도시되어 있다. 도 6의 상호 작용들은 (1)에서 시작하며, 여기서 클라이언트(305)는 하나 이상의 볼륨 복제본들(예를 들어, 1차 및/또는 2차 복제본)을 구현하는 블록 저장 서버들(310)에 쓰기 동작을 제출한다. 볼륨이 가상화된 스토리지 장치(예를 들어, 하드 디스크 드라이브 또는 솔리드 스테이트 디스크 드라이브)로 클라이언트 장치(305)에 제공될 수 있기 때문에, 쓰기 동작은 다수의 버스 인터페이스 프로토콜들 중 어느 하나에 따라 블록 저장 서버들(310)로 전송될 수 있으며, 이들 중 다양한 프로토콜은 당업계에 알려져 있다. 예를 들어, 클라이언트(305)의 쓰기 동작은 SATA(Serial AT Attachment) 데이터 패킷으로 포맷될 수 있다. 상기에 언급된 바와 같이, "쓰기 동작(write operation)"이라는 용어는 본 개시에서 타겟 볼륨에 대한 수정을 반영하도록 의도되었으며, 따라서 새로운 데이터를 작성하거나, 기존 데이터를 수정하거나, 데이터를 삭제하거나, 아니면 서버들(310)에 구현된 바와 같은 볼륨의 내용을 수정하는 동작들을 포함할 수 있다.
쓰기 동작을 수신한 후, 블록 저장 서버들(310)은 수신된 동작을 이용하여 볼륨에 대응되는 메시지 스트림에 포함하기 위한 쓰기 동작에 대응되는 메시지를 생성할 수 있다. (블록 저장 서버들(310)은 쓰기 동작에 따라, 1차 및/또는 2차 복제본과 같은 볼륨의 복제본들을 수정하기 위해 쓰기 동작들을 추가로 처리할 수 있다. 네트워크 기반 스토리지 장치에 대한 쓰기 동작들의 일반적인 구현은 당업계에 공지되어 있으므로, 이러한 상호 작용은 본원에서는 설명되지 않는다.) 일 실시예에서, 볼륨은 볼륨에 대한 모든 쓰기 동작들이 단일 메시지 스트림 내에 메시지들로 포함되도록 단일 메시지 스트림과 연관된다. 다른 실시예에서, 볼륨은 볼륨에 대한 쓰기 동작들이 메시지 스트림들 간에 분할되도록 다수의 메시지 스트림들가 연관된다. 이러한 분할은 예를 들어, 볼륨의 1차 복제본 및/또는 2차 복제본의 파티셔닝을 기반으로 할 수 있다. 예시적으로, 1차 및/또는 2차 복제본들이 16개의 파티션들으로 분할되는 경우, 로거 플릿(315)은 볼륨에 대한 16개의 메시지 스트림들을 유지하는 데 사용될 수 있으며, 각 메시지 스트림은 16개의 파티션들 중 개별 파티션과 관련된 쓰기 동작들을 반영하는 메시지들을 포함한다. 스트림들 간의 쓰기 동작들의 다른 분할들이 고려된다. 예를 들어, 쓰기 동작들은 로드 밸런싱 알고리즘(예를 들어, 라운드 로빈 분할 등)을 통해 서로 다른 메시지 스트림들로 나뉠 수 있다. 다수의 메시지 스트림들 간에 쓰기 동작들의 분할은 각 스트림을 유지 관리 시 메모리 요구 사항들을 줄이고, 로거 플릿(315)에서 병렬화를 가능하게 하고, (예를 들어, 쓰기 동작이 적용되는 파티션의 지식에 기초하여) 메시지 스트림들 내에서 특정 쓰기 동작을 찾는 데 필요한 시간을 줄이는 데 이로울 수 있다. 다음의 상호 작용들은 각각이 볼륨의 1차 및/또는 2차 복제본의 파티션에 대응되는, 볼륨에 대한 쓰기 동작들의 로그를 유지하기 위해 다수의 메시지 스트림들의 사용과 관련하여 예시적으로 설명될 것이다. 그러나, 단일 메시지 스트림이 이용되거나 쓰기 동작이 적용되는 파티션 이외의 기준에 따라 메시지 스트림들이 분할되는 경우(예를 들어, 로드 밸런싱 분할) 유사한 상호 작용들이 구현될 수 있다.
따라서, (2)에서, 블록 저장 서버들(310)은 쓰기 동작에 의해 수정되는 볼륨의 파티션(예를 들어, 1차 및/또는 2차 본제본)을 결정한다. 추가로, (3)에서, 블록 저장 서버(310)는 적절한 메시지 스트림에 포함될 쓰기 동작을 반영하는 메시지를 생성한다. 메시지는 예를 들어 쓰기 동작의 내용에 대한 레코드(예를 들어, 쓰기 동작을 나타내는 SATA 데이터 패킷)뿐만 아니라, 예를 들어, 쓰기 동작이 적용되는 특정 블록 주소들, 쓰기 동작이 제출된 클라이언트(305)의 아이덴티티, 쓰기 동작이 적용되는 볼륨의 식별자, 블록 저장 서버들(310)에 의해 쓰기 동작에 할당된 시퀀스 번호 등과 같은, 나중에 쓰기 동작을 재생성하는 데 필요하거나 사용할 수 있는 임의의 추가 메타 데이터를 포함할 수 있다. 메시지는 임의의 공지된 메시징 프로토콜들에 따라 포맷될 수 있다. 예를 들어, 메시지는 MQTT(Message Queuing Telemetry Transport) 포맷에 따라 포맷될되거나, APACHE KAFKATM 소프트웨어를 구현하는 서버에 의해 사용하기 위해 포맷되거나, AMAZON KINESISTM 서비스에 의해 제공되는 스트림에 포함되도록 포맷될 수 있다.
(4)에서, 블록 스토어 서버(310)는 쓰기 동작이 적용된 1차 및/또는 2차 복제본의 파티션에 대응되는 스트림에 포함되도록 메시지(볼륨에 대한 쓰기 동작을 반영함)를 로거 플릿(315)에 전송한다. 도 6에 도시된 바와 같이, 로거 플릿(315)은 다수의 파티션 스트림들(608A-608N)을 유지할 수 있으며, 이들 각각은 예를 들어 1차 및/또는 2차 복제본의 서로 다른 파티션에 대응될 수 있다. 도 6의 예시적인 예에서, 쓰기 메시지는 예를 들어 쓰기 동작이 볼륨의 제2 파티션을 수정했음을 반영하는 파티션 스트림(608B)에 제출된다. (5)에서, 로거 플릿(315)은 메시지를 스트림(608B)으로 인큐잉(enqueue)한다. 로거 플릿(315)은 일부 실시예들에서 메시지들을 저장하기 위해 리던던트 서버들을 사용하는 것과 같이, 플릿(315)의 다양한 장애에 대한 복원성을 보장하는 기능들을 구현할 수 있다. 일 실시예에서, 로거 플릿(315)은 큐(queue) 내의 각 메시지를 각 수신자에게 "정확히 한 번" 또는 "적어도 한 번" 전달하도록 구성된다. 예시적으로, "정확히 한 번" 기능들은 동일한 쓰기 동작의 여러 번의 적용은 쓰기 동작이 적용되는 블록들에 대해 항상 동일한 상태가 되는 것은 아니므로, 쓰기 동작들이 멱등(idempotent)이 아닌 경우에 이로울 수 있다. "적어도 한 번" 기능들은 예를 들어, 쓰기 동작들이 멱등(예를 들어, 동일한 블록에 적용된 동일한 동작이 동작의 반복에 관계없이 항상 블록의 동일한 상태를 초래함)인 경우, 사용될 수 있으며, 로거 플릿(315)에서 컴퓨팅 리소스들이 감소되는 것과 연관될 수 있다. "적어도 한 번" 기능들을 구현하는 로거 플릿(315)에 대한 한 예시적인 구현예가 "FAST SEQUENTIAL MESSAGE STORE" 라는 제목의 미국 특허 번호 제8,261,286호에 설명되어 있으며, 전체 내용은 본원에 참조로서 통합된다.
하기에 설명되는 바와 같이, 로거 플릿(315)은 각 스트림(608) 내의 메시지들을 다양한 수신자들에게 전달하도록 구성될 수 있다. 예를 들어, 로거 플릿(315)은 분산된 3차 복제본에 메시지들을 전달하여, 3차 복제본이 메시지들에 반영된 쓰기 동작들에 따라 1차 및/또는 2차 복제본들의 상태로 비동기식으로 업데이트되도록 할 수 있다. 다른 예로서, 로거 플릿(315)은 객체 스토리지(215)에 메시지들을 전달할 수 있으며, 이러한 객체 스토리지(215)는 시간이 지남에 따라 볼륨에 대한 쓰기 동작들의 레코드를 유지할 수 있다. 예시적으로, 로거 플릿(315)은 주어진 스트림 내의 메시지들이 각 수신자에게 정확한 순서로 수신되도록 메시지들의 순서를 강제할 수 있다. 일 실시예에서, '정확한 순서'는 로거 플릿(315)에서 메시지들을 인큐잉하는 것에 기초하여(예를 들어, 메시지들이 수신된 것과 동일한 순서로 수신자들에게 전달되도록) 설정된다. 다른 실시예에서, "정확한 순서"는 메시지 자체의 내용에 기초하여 설정된다. 예를 들어, 메시지가 시퀀스 번호를 나타내는 메타 데이터를 포함하는 경우, 시퀀스 번호는 스트림에서 메시지의 정확한 순서를 설정하기 위해 로거 플릿(315)에 의해 활용될 수 있다. 일부 경우에, 로거 플릿(315)은 메시지의 수신 순서를 메시지의 내용과 동기화되도록 구성될 수 있다. 예를 들어, 로거 플릿(315)은 순서가 있는 시퀀스 번호들(예를 들어, 증가하는 번호들, 감소하는 번호들, 증가하는 인접 번호들, 감소하는 인접 번호들 등)이 있는 메시지들만 수락하고, 순서가 없는 시퀀스 번호를 포함하는 메시지가 수신되면 전송 장치에 알리도록 구성될 수 있다.
도 6의 상호 작용들은 쓰기 동작들에 대해 상기에 설명되어 있지만, 볼륨에 대한 다른 동작들은 볼륨에 대한 메시지 스트림 내에 추가로 또는 대안으로 포함될 수 있다. 예를 들어, 주어진 시점에서의 볼륨의 상태를 반영하는 파일의 생성을 요청하는 "스냅샷" 동작들은 메시지 스트림의 메시지 내에 반영될 수 있다. 예시적으로, 스냅샷은 볼륨에 대한 각 메시지 스트림에 포함될 수 있으며, 볼륨의 3차 복제본의 파티션을 유지하는 각 장치는 스냅샷 메시지 수신 시, 스냅샷의 관련 부분을 객체 스토리지(215) 내의 파일로 생성하도록 구성될 수 있다. 3차 복제본으로부터의 스냅샷의 생성은 하기에 더 상세하게 설명된다. 일부 실시예들에서, 메시지 스트림에 포함된 스냅샷 메시지는 객체 스토리지(215) 상에서 스냅샷의 위치를 나타낼 수 있다. 하기에 설명되는 바와 같이, 이는 장치가 특정 시점에서의 볼륨의 상태를 재생성하기 위해 메시지 스트림 내에 식별된 쓰기 동작들과 함께, 메시지 스트림 내에 식별된 스냅샷을 사용하게 함으로써, 특정 시점에서의 볼륨 상태의 재생성을 용이하게 할 수 있다.
도 7을 참조하면, 로거 플릿(315)의 메시지 스트림 내의 메시지들을 사용하여 분산된 3차 복제본의 비동기식 업데이팅을 가능하게 하는 예시적인 상호 작용들(700)이 설명될 것이다. 도 7의 상호 작용들은 예를 들어, 도 6의 상호 작용들 이후 및/또는 도 6의 상호 작용들과 동시에(예를 들어, 도 6의 상호 작용들이 다수의 쓰기 동작들에 대해 반복되는 경우) 일어날 수 있다.
도 7의 상호 작용들은 (1)에서 시작하며, 여기서 로거 프릿(315)은 아직 수신자에게 전달되지 않은 메시지 스트림에 메시지가 존재함을 검출한다. 구체적으로, 도 7의 상호 작용드에서, 로거 플릿(315)은 관련 컨테이너 서버(220)에 아직 전달되지 않은 메시지가 파티션 스트림(608B) 내에 존재함을 검출할 수 있다. 관련 컨테이너 서버 (220)는 예를 들어 메시지들에 의해 나타낸 쓰기 동작이 적용되는 볼륨의 3차 복제본의 파티션을 구현하는 서버(220)에 대응될 수 있다. 일 실시예에서, 로거 플릿(315)은 각 스트림의 경우, 스트림에 대한 수신자 목록뿐만 아니라, 수신자가 스트림 내에서 메시지를 수신했음을 나타내는 확인 응답 목록을 유지할 수 있다. 따라서, 상호 작용(1)은 스트림(608B) 내의 메시지가 스트림(608B)의 수신자에 의해 아직 확인되지 않았음을 검출함으로써 구현될 수 있다. 일 실시예에서, 스트림의 수신자는 메ㅅ시지 내에 포함된 쓰기 동작에 적어도 부분적으로 기초하여 구현될 수 있다. 예를 들어, 메시지 내에 반영된 쓰기 동작이 볼륨 내의 특정 블록 오프셋에 적용되는 경우, 메시지 수신자는 해당 블록 오프셋에 대응되는 3차 복제본의 파티션을 유지하는 서버(220)에 기초하여 결정될 수 있다. 일부 실시예들에서, 로거 플릿(315)은 게시/구독("pub/sub") 모델에 따라 동작하도록 구성되고, 각 컨테이너 서버(220)는 로거 플릿(315)의 스트림(608)의 관련 부분을 "구독"하도록 구성되며, 이에 따라 서버(220)가 스트림(608)의 이러한 부분에 대한 수신자임을 로거 플릿(315)에게 알린다. 다른 실시예들에서, 로거 플릿(315)은 어떤 컨테이너 서버(220)가 3차 복제본의 어떤 파티션들을 유지하는지에 대해 (예를 들어, 볼륨에 대한 1차 및/또는 2차 복제본을 구현하는 서버(310)에 의해) 통지되며, 이러한 통지에 기초하여 각 메시지의 수신자들을 결정한다.
수신자에게 전달하기 위해 스트림 내에 메시지가 존재한다고 결정한 한, 로거 플릿(315)은 (2)에서 수신자 컨테이너 서버(220)에 메시지를 제출한다. 컨테이너 서버(220)는 (3)에서, 메시지를 활용하여 쓰기 동작을 생성하고 쓰기 동작에 따라 볼륨의 3차 복제본의 파티션을 수정할 수 있다. 예를 들어, 컨테이너 서버(220)는 일부 실시예들에서 메시지 내의 정보를 이용하여 쓰기 동작을 나타내는 초기 SATA 데이터 패킷을 재생성하고, 쓰기 동작이 적용되는 3차 복제본의 관련 파티션에 대해 해당 SATA 데이터 패킷을 적용할 수 있다. 따라서, 볼륨의 3차 복제본은 이전에 1차 및/또는 2차 복제본들에 적용된 쓰기 동작들로 비동기식으로 업데이트될 수 있다. 상기에 언급된 바와 같이, 일부 경우에, 메시지들은 쓰기 동작들 이외의 다른 동작드을 포함할 수 있다. 예를 들어, 메시지는 스냅샷에 대한 클라이언트 요청을 나타낼 수 있다. 이러한 경우, 서버들(220)은 (예를 들어, 도 5a 내지 5c와 관련하여) 상기에 설명된 바와 같이, 볼륨에 대한 스냅샷의 생성을 개시함으로써 메시지를 처리할 수 있다.
도 7은 단일 메시지를 단일 수신자에게 전송하는 것을 도시하고 있지만, 로거 플릿(315)은 임의 개수의 수신자들에게로의 임의 개수의 메시지들의 전달을 용이하게 하도록 기능할 수 있다. 일 실시예에서, 로거 플릿(315)은 메시지들이 스트림에 인큐잉되는 순서와 관련하여 "선입 선출"(FIFO) 순서로 전송되도록 해당 스트림에 대해 순차적인 순서로 각 수신자(예를 들어, 스트림에 대한 구독으로 식별됨)에게 메시지들을 전송한다. 예를 들어, FIFO 순서의 사용은 3차 복제본과 1차 및/또는 2차 복제본의 일관성을 유지할 수 있다.
일부 실시예들에서, 로거 플릿(315)은 미해결 메시지들(예를 들어, 각 수신자가 확인되지 않은 메시지들)이 임계량을 초과하지 않도록 각 파티션 스트림(608)의 크기를 모니터링는 것을 가능하게 할 수 있다. 예시적으로, 로거 플릿(315)은 메시지들이 수신될 때 인큐잉될 수 있으며, 각 메시지 수신자에 의해 확인될 때마다 확인된 메시지들로 표시될 수 있다. 그러나, 수신자가 (예를 들어, 오류, 하드웨어 오류 등으로 인해) 메시지들을 확인하지 못하는 경우, 큐의 확인되지 않은 메시지들의 수가 임계 크기를 초과할 수 있다. 이런 경우, 로거 플릿(315)은 메시지를 스트림에 작성하기 위한 후속 요청들을 거부하는 것과 같이, 이러한 고장을 블록 저장 서버들(310)에 통지하도록 구성될 수 있다. 블록 저장 서버들(310)은 클라이언트 장치(305)로부터의 쓰기 동작들을 거부하거나 그렇지 않으면 이러한 쓰기 동작들이 볼륨의 3차 복제본에 작성되지 않음을 나타낼 수 있다.
도 8을 참조하면, 메시지 스트림 내의 메시지들의 레코드를 객체 스토리지(215)에 쓰기 위한 예시적인 상호 작용들(800)이 설명될 것이다. 이러한 메시지들의 레코드는 예를 들어, 볼륨에 대한 메시지 스트림 내에 반영된 임의의 시점에서의 볼륨의 상태를 재생성하는 데 활용될 수 있다. 도 8의 예시적인 상호 작용들은 단일 메시지 스트림, 파티션 스트림(608B)에 대해 설명될 것이다. 그러나, 유사한 상호 작용들은 볼륨에 대한 임의의 메시지 스트림과 관련하여 구현될 수 있다.
도 8의 상호작용들은 (1)에서 시작하며, 여기서 로거 플릿(315)은 큐 수집 이벤트를 검출한다. 큐 콜렉션 이벤트는 예시적으로 메시지 스트림(예를 들어, 스트림(608B)) 내의 이벤트들이 디큐잉되어 객체 스토리지(215)(예를 들어, 장기 저정을 위한)로 전송되어야 함을 나타내는 임의의 이벤트에 대응된다. 일 실시예에서, 큐 콜렉션 수집 이벤트는 임계 개수(예를 들어, 로거 플릿(315)의 관리자에 의해 설정됨) 이상으로 증가하는 스트림 내의 메시지들의 개수에 대응된다. 다른 실시예에서, 큐 콜렉션 이벤트는 스트림의 메시지 내에서 스냅샷 동작의 검출에 대응된다. 또 다른 실시예에서, 큐 콜렉션 이벤트는 이전 큐 콜렉션 이벤트 이후의 임계 시간 기간(예를 들어, 24 시간)이 경과하는 것에 대응된다.
큐 수집 이벤트의 검출 시, (2)에서, 로거 플릿(315)은 스트림(608B) 내의 메시지들을 객체 스토리지(215)에 기록될 데이터 객체로 묶거나, 수집하거나 아니면 컴파일하며, 이 데이터 객체를 본원에서는 "번들 객체(bundle object)"라고 한다. 번들 객체는 번들 객체의 생성시 스트림 내의 메시지들을 식별하는 임의의 데이터 객체일 수 있다. 예를 들어, 번들 객체는 ZIP이거나 다른 압축 데이터 파일일 수 있다. 일 실시예에서, 로거 플릿(315)은 모든 수신자들(예를 들어, 컨테이너 서버들(220))에 의해 확인된 메시지들만 번들 객체 내에 포함한다. 그런 다음, 로거 플릿(135)은, (3)에서, 번들 객체를 객체 스토리지(215) 내에 저장한다. 하기에 설명되는 바와 같이, 번들 객체는 나중에 번들 객체 내의 메시지들에 의해 반영된 일정 기간 동안 볼륨에 수행된 쓰기 동작들의 레코드로서 객체 스토리지(215)로부터 검색될 수 있다. 메시지들이 객체 스토리지(215)에 저장되었기 때문에, 로거 프릿(315)은 이후에 (4)에서 파티션 스트림(608B)으로부터 번들 객체의 메시지를 디큐잉(dequeue)하여, 후속 메시지들을 위한 스트림 내 공간을 확보할 수 있다.
파티션 스트림(608B)으로부터 메시지들을 디큐잉하는 것은 주기적 동작(예를 들어, 큐 콜렉션 이벤트들이 수신될 때)으로 상기에 설명되어 있지만, 로거 플릿(315)의 일부 실시예들은 대안적으로 이들이 모든 수신자들에 의해 확인될 때 메시지들을 디큐잉할 수 있다. 예시적으로, 객체 스토리지(215)는 객체 또는 객체들의 콜렉션에 개별 메시지들의 쓰기를 가능하게 할 수 있으며, 객체 스토리지(215)는 볼륨에 대한 각 메시지 스트림의 수신자로 구성될 수 있다. 따라서, 로거 플릿(315)은 다른 수신자들(예를 들어, 컨테이너 서버들(220))과 동일하거나 유사한 방식으로 객체 스토리지(215)에 메시지들을 전송하도록 구성될 수 있다. 이러한 경우, 메시지들은 객체 스토리지(215)를 포함한 모든 수신자들로부터의 수신 확인 응답 후 메시지 스트림으로부터 디큐잉될 수 있다.
도 9a 및 9b를 참조하면, 볼륨에 대한 쓰기 동작들을 반영하는 메시지들의 스트림(또는 이러한 스트림의 로그)을 참조하여 특정 시점에서의 볼륨의 상태를 재생성하기 위한 예시적인 상호 작용들이 설명될 것이다. 구체적으로, 상기에 논의된 바와 같이, 볼륨에 대한 수정들이 볼륨에 대한 메시지들의 스트림 내에 반영되는 경우, 이러한 메시지들의 스트림은 메시지들의 스트림 내에 반영된 어느 시점에서의 볼륨의 상태를 재생성하는 데 사용될 수 있다. 특정 시점에서의 볼륨의 상태를 재생성하기 위한 예시적인 상호 작용들(900)이 도 9a에 도시되어 있는 반면, 특정 시점에서의 볼륨의 상태를 재생성하기 위한 예시적인 루틴(901)이 도 9a에 도시되어 있다. 루틴(901)은 예를 들어, 제2 볼륨의 상태가 재생성될 제1 볼륨을 유지하는 장치에 의해 수행될 수 있다. 제1 및 제2 볼륨들은 동일한 볼륨일 수 있으며, 이에 따라 클라이언트가 볼륨에 대한 동작들을 "리와인드"하여 해당 볼륨을 그 이전 상태에 놓이게 할 수 있다. 제1 및 제2 볼륨들은 서로 다른 볼륨들일 수 있으며, 이에 따라 클라이언트가 새 볼륨에서 이전에 존재하던 볼륨의 이전 상태를 재새성하게 할 수 있다. 도 9a에서, 이전에 존재하는 볼륨의 상태를 새 볼륨으로 재생성하기 위해 블록 저장 서버(310)에 의해 구현되는 루틴(901)이 예시되며, 새 볼륨은 예를 들어 블록 저장 서버들(310)에서 구현되는 1차 및 2차 복제본을 포함한다. 루틴(901)은 이전에 존재하는 볼륨의 상태를 새로운 고도로 분산된 볼륨 또는 복제본으로 재생성하기 위해 컨테이너 서버들(220)에 의해 추가로 또는 대안으로 구현될 수 있다.
도 9a 및 9b를 참조하면, 블록(902)에서, 블록 저장 서버들(310)은 특정 시점에 이전에 존재하는 볼륨의 상태를 재생성하라는 요청을 획득한다. 예를 들어, 요청은 클라이언트(305)에 의해 생성될 수 있으며, 이전에 존재하는 볼륨, 특정 시점 및 특정 시점에 이전에 존재하는 볼륨의 상태를 재생성하기 위한 타겟 볼륨(타겟 볼륨은 이전에 존재하는 볼륨과 동일하거나 다른 볼륨일 수 있음)을 지정할 수 있다.
다른 실시예에서, 요청은 로거 플릿(315) 또는 탄력적 컴퓨팅 시스템(120)의 제어 평면(155)을 구현하는 장치에 의해 생성될 수 있다. 예시적으로, 도 9a 및 9b를 참조하여 설명된 상호 작용들은 일정 기간 동안 볼륨에 대한 쓰기 동작들을 반영하는 메시지들의 스트림을 특정 시점에서 볼륨의 스냅샷으로 변환하는 데 사용될 수 있다. 이러한 스냅샷은 메시지들의 스트림보다 저장하는 데 더 적은 메모리를 필요로 할 수 있기 때문에, 이러한 상호 작용들은 탄력적 컴퓨팅 시스템(120)이 시스템(120)의 메모리 사용량을 줄이게 할 수 있다. 예시적으로, 볼륨에 대한 메시지들의 스트림이 임계 크기를 초과하는 경우, 시스템(120)은 스트림이 임계 크기를 초과하도록 하는 스트림 내의 초기 메시지를 결정하고, 이러한 초기 메시지들에 반영된 쓰기 동작들의 구현 후 볼륨의 상태를 반영하는 볼륨에 대한 스냅샷을 생성하도록 구성될 수 있다. 이후, 시스템(120)은 메시지가 스냅샷 내에 보관된 직후의 시스템의 상태에 따라, 이러한 초기 메시지들을 삭제할 수 있다.
블록(904)에서, 블록 저장 서버들(310)은 참조 시점과 요청과 관련된 특정 시점 사이의 볼륨에 대한 쓰기 동작들을 반영하는 메시지들을 검색한다. 참조 시점은 예시적으로 특정 시점 이전의 임의의 시점이며, 전체 볼륨의 상태가 알려진 시점일 수 있다. 예를 들어, 기준 시점은 볼륨의 초기 생성 또는 볼륨의 스냅샷의 생성에 대응될 수 있다. 따라서, 검색된 메시지들은 참조 시점의 볼륨의 상태에서 시작하고, 메시지에 포함된 쓰기 동작들을 적용하여 특정 시점의 볼륨 상태를 재새성하는 데 활용될 수 있다. 예시적으로, 블록 저장 서버(310)는 볼륨에 대한 기준 시점의 레코드를 유지할 수 있으며, 루틴(901)의 특정 구현에 사용될 기준 시점을 요청과 연관된 특정 시점 이전의 제1 기준 시점으로 선택할 수 있다.
블록(904)에서 검색된 메시지들은 객체 스토리지(215) 내에 저장된 번들 객체 포함 메시지들 또는 로거 플릿(315) 내에 저장된 번들되지 않은 메시지들 중 하나 또는 둘 다를 포함할 수 있다. 예시적으로, 각 메시지 또는 번들 객체는 볼륨 식별자 및 메시지에 반영된 쓰기 동작에 대한 시간 또는 시간 범위와 연관될 수 있다. 따라서, 블록 서버(310)는 객체 스토리지(215) 및/또는 로거 플릿(315)에 참조 시점과 요청의 특정 시점 사이의 기간과 관련된 메시지들을 요청할 수 있다.
블록(906)에서, 블록 저장 서버(310)는 타겟 볼륨(604)이 요청에 지정된 특정 시점에 요청에 지정된 이전에 존재하는 볼륩의 상태를 재생성하게 하기 위해, 검색된 메시지들로부터 생성된 쓰기 동작 세트를 타겟 볼륨(604)에 적용한다. 일 실시예에서, 블록 저장 서버(310)는 (예를 들어, 참조 시점이 볼륨의 초기 생성인 경우 모든 쓰여 지지 않도록 모든 블록들을 설정함으로써, 참조 시점이 스냅샷의 생성에 대응되는 경우 모든 블록들을 스냅샷에 반영되는 값들로 설정함으로써, 등) 초기에 볼륨(604)의 상태가 참조 시점의 상태와 매칭되게 한다. 이후, 블록 저장 서버(310)는 검색된 메시지들의 순서와 매칭되는 순서로 볼륨에 쓰기 동작들을 적용할 수 있으며, 이에 따라 이전에 존재하는 볼륨에 대해 이루어진 수정들을 재생성하고 타겟 볼륨(310)이 특정 시점의 이전에 존재하는 볼륨의 상태와 매칭되게 할 수 있다.
다른 실시예에서, 블록 스토어 서버(310)는 먼저 마지막 메시지에 대응되는 쓰기 동작을 적용한 다음, 순차적으로 초기 메시지들의 쓰기 동작들을 적용함으로써, 검색된 메시지들의 순서의 역방향인 순서로, 예를 들어 시간의 역순으로 볼륨에 쓰기 동작들을 적용할 수 있다. 쓰기 동작들을 역순으로 적용할 때, 블록 저장 서버들(310)은 이전에 존재하는 볼륨의 동일한 블록에 대한 제2 및 후속 쓰기들을 무시할 수 있으며, 따라서 (메시지들의 타이밍에 반영되는 대로) 마지막 쓰기들을 타겟 볼륨의 블록의 상태와 같은 블록에 대한 상태로 설정한다. 일부 경우에, 역순으로 쓰기 동작들을 적용하는 것은 블록 저장 서버(310)가 기준 시점을 미리 설정하지 않고도 동작하게 할 수 있다. 예를 들어, 블록 저장 서버(310)는 로거 플릿(315) 또는 객체 스토리지(215)로부터 볼륨에 대한 최신 메시지들을 검색하기 시작하고, 타겟 볼륨(604)의 모든 블록들이 알려진 상태를 가질 때까지 메시지들을 검색하고 메시지들의 역순으로 타겟 볼륨에 대한 대응되는 쓰기 동작들을 적용(예를 들어, 동일한 블록에 대한 제2 또는 후속 쓰기들을 무시)하는 것을 계속하도록 구성될 수 있다. 예시적으로, 블록 저장 서버(310)는 기준 시점이 메시지들의 시간의 역순으로 도달되었다고 결정하거나, 모든 블록들이 이러한 메시지들 내에 작성되었다고 결정함으로써 타겟 볼류(604)의 모든 블록들이 알려진 상태를 가진다고 결정할 수 있다.
이후, 블록(908)에서, 블록 저장 서버(310)는 타겟 볼륨(604)이 특정 시점에서의 이전에 존재하는 볼륨의 상태에 놓여있음을 수신자에게 통지한다. 수신자는 예를 들어, 이전에 존재하는 볼륨의 상태의 재생성을 처음에 요청한 클라이언트에 해당될 수 있다. 추가로 또는 대안으로, 시스템(120)애 의해 볼륨의 재생성이 요청된 경우, 수신자는 시스템의 제어 평면(155)일 수 있다. 이러한 경우, 제어 계획(155)은 이후 타겟 볼륨(604)의 스냅샷의 생성이 객체 스토리지(215) 내에 저장되게 하여, 타겟 볼륨(604)의 상태를 생성하는 데 사용되는 메시지들의 삭제를 가능하게 한다.
블록(906)에서의 쓰기 동작들의 적용은 특정 시점 이전 또는 특정 시점에 블록에 대한 쓰기 동작을 반영하는 최신 메시지가 특정 시점의 블록의 상태에 대한 권한이 있는 것으로 간주되도록 주어진 블록에 대한 반영과 함께 순차적으로 발생할 수 있다. 그러나, 블록(906)에서의 쓰기 동작들의 적용은 또한 상이한 블록들 또는 블록들의 일부들에 대해 병렬로 발생할 수 있다. 예시적으로, 블록 저장 서버들(310)은 블록(906)의 다수의 인스턴스들을 구현하도록 구성될 수 있거나, 일부 경우에는 루틴(901) 전체를 병렬로 구현하도록 구성될 수 있다. 예를 들어, 블록(906)의 개별 구현 또는 루틴(901)이 타겟 볼륨(906)의 각 파티션에 대해 발생할 수 있다. 이러한 병렬화는 블록 저장 서버들(310)이 타겟 볼륨(906)을 특정 시점에 이전에 존재하는 볼륨의 상태와 매칭되는 상태로 신속하게 놓이도록 할 수 있다.
로거 플릿(315)의 예시적인 기능들이 상기에 논의되었지만, 추가 기능들이 로거 플릿(315)에 의해 추가로 또는 대안적으로 구현될 수 있다. 예시적으로, 로거 플릿(315)은 승인된 클라이언트들이 데이터 볼륨(예를 들어, 액세스 권한이 있는 볼륨)과 관련된 메시지 스트림들을 구독할 수 있는 공개적으로 액세스 가능한 API를 제공하도록 구성될 수 있다. 따라서, 클라이언트는 데이터 볼륨의 수정에 관한 통지들과 같은, 다양한 기능들을 구현하기 위해 이러한 API를 사용할 수 있다. 예를 들어, 클라이언트 장치는 데이터 볼륨으로부터 메시지 스트림을 구독하고, 기준 세트를 충족하는 수정들이 메시지 스트림 내에 포함되는 시점을 결정하고, 이러한 수정을 최종 사용자에게 통지하도록 구성될 수 있다. 따라서, 본원에 설명된 기능들은 사실상 예시적인 것이다.
중간 듀플리케이트를 이용한 실시예들의 개요
상기에 언급된 바와 같이, 고도로 분산된 3차 복제본은 볼륨의 빠른 듀플리케이션을 용이하게 할 수 있지만, 그럼에도 불구하고 요청된 듀플리케이션의 레벨이 고도로 분산된 단일 복제본을 사용하는 경우 과도한 시간을 필요로 하는 경우가 있을 수 있다. 예를 들어, 사용자가 소스 볼륨 또는 해당 볼륨의 일부(예를 들어, 부트 섹터)를 수백 또는 수천 번 듀플리케이트하고자 하는 경우, 이러한 듀플리케이션은 단일 고도로 분산된 3차 복제본을 사용할 때 상당한 시간을 필요로 할 수 있다. 이와 같이, 본 개시의 실시예들은 보다 신속한 대량 듀플리케이션을 가능하게 하기 위해, 중간 듀플리케이트 복제본, 또는 복제본의 중간 듀플리케이션 파티션들의 생성을 가능하게 할 수 있다. 일 실시예에서, 볼륨(또는 볼륨의 일부)의 대량 듀플리케이션에 대한 요청은 먼저 하나 이상의 중간 듀플리케이트 복제본 또는 중간 듀플리케이션 파티션들(이들 중 하나를 본원에서는 "중간 듀플리케이트" 이라 할 수 있음)을 생성한 다음, 하나 이상의 타겟 볼륨들로 볼륨의 대량 듀플리케이션을 가능하게 하기 이러한 중간 듀플리케이트들을 사용함으로써 촉진될 수 있다.
하나 이상의 중간 듀플리케이트들의 생성은 도 2a의 분산 복제본 코디네이터(205)와 같은 중앙 집중식 권한에 의해 용이하게 될 수 있거나, 또는 초기 고도로 분산된 복제본의 파티션들을 호스팅하는 서버들(예를 들어, 도 2a의 컨테이너 서버들(220))에 의해 용이하게 될 수 있다. 중간 듀플리케이트들의 구현 및 사용을 위한 예시적인 상호 작용들은 도 10a 내지 11c와 관련하여 하기에 설명될 것이다. 구체적으로, 도 10a 내지 10c의 상호 작용들은 볼륨으로부터 정보의 대량 복사를 용이하게 하기 위해 중간 듀플리케이트들의 생성 및 사용을 관리하기 위한 중앙 집중식 권한의 역할을 하는 분산 복제본 코디네이터(205)의 사용을 위한 상호 작용들 도시한다. 도 11a 내지 11c의 상호 작용들은 또한 볼륨으로부터 정보의 대량 복사를 용이하게 하는 중간 듀플리케이트들의 생성 및 사용을 관리하기 위한 상호 작용들을 도시하지만, 중앙 집중식 권한을 요구하는 대신 컨테이너 서버들(220)의 피어 투 피어 동작을 활용한다. 도 10a 내지 11c는 다수의 타겟 볼륨들에 듀플리케이트되는 소스 볼륨에 대응된는 고도로 분산된 복제본의 단일 파티션을 참조하여 예시적으로 설명된다. 이 단일 파티션은 예를 들어, 구성 파일 또는 많은 수의 타겟 볼륨들에 복사되도록 요청된 기타 정보를 포함할 수 있다. 그러나, 유사한 상호 작용들은 고도로 분산된 복제본의 여러 파티션들 또는 복제본의 모든 파티션들(예를 들어, 전체 데이터 볼륨)로부터 정보의 듀플리케이션을 용이하게 하는 데 활용될 수 있다. 예시적으로, 고도로 분산된 복제본의 모든 파티션들에 대한 도 10a 내지 10c, 또는 도 11a 내지 11c의 상호 작용드을 구현함으로써, 고도로 분산된 복제본으로 표시되는 전체 소스 볼륨은 많은 수의 타겟 볼륨들로 빠르게 듀플리케이트될 수 있다. 게다가, 도 10a 내지 11c의 상호 작용들은 타겟 볼륨 세트로의 볼륨(또는 그 일부)의 듀플리케이션과 관련하여 설명되어 있지만, 유사한 상호 작용들이 임의의 네트워크 장치에 대한 볼륨(또는 그 일부)의 듀플리케이션을 용이하게 하는 데 사용될 수 있다. 예를 들어, 중간 듀플리케이트들은 객체 스토리지 서버들(110)(예를 들어, 수백 또는 수천 개의 소스 볼륨의 특정 시점 "스냅샷을 생성함) 내의 하나 이상의 객체들로의 또는 탄력적 컴퓨팅 시스템(120) 외부의 하나 이상의 네트워크 목적지들로의 소스 볼륨(또는 그 일부)의 대량 듀플리케이션을 용이하게 하는 데 활용될 수 있다.
상기에 언급된 바와 같이, 도 10a 내지 10c의 상호 작용들은 소스 볼륨의 고도로 분산된 복제본의 단일 파티션으로부터 정보의 대량 복사를 용이하게 하기 위해 중간 듀플리케이트들의 생성 및 사용을 관리하기 위한 중앙 집중식 권한의 역할을 하는 분산 복제본 코디네이터(205)의 사용을 위한 상호 작용들 도시한다. 고도로 분산된 복제본의 파티션은 예시적으로 이러한 파티션들을 호스팅하는 데 사용할 수 있는 컨테이너 서버 세트(220)의 제1 컨테이너 서버(220A) 내에 저장된다.
도 10a 내지 10c의 상호 작용들은 (1)에서 시작하며, 여기서 분산 복제본 코디네이터는 소스 볼륨의 고도로 분산된 복제본의 파티션을 타겟 볼륨 세트로 복사하라는 요청을 수신한다. 일 실시예에서, 요청은 블록 저장 서버들(105)에 의해 제공되는 API를 통해 사용자에 의해 제출된다. API는 분산 복제본 코디네이터(205A)에 직접 요청을 제출하거나, 차례로 분산 복제본 코디네이터(205A)에 요청을 제출하는 (예를 들어, 제어 평면(155)을 구현하는) 다른 장치로의 제출을 용이하게 할 수 있다. 요청은 예를 들어, 복사될 소스 볼륨의 정보 및 정보가 복사되어야 하는 타겟 볼륨 세트를 식별할 수 있다. 정보는 예를 들어, 소스 볼륨에 대한 고도로 분산된 복제본의 파티션으로 지정되거나, (예를 들어, 정보가 저장되는 소스 볼륨의 블록 범위에 기초하여) 코디네이터(205A)가 파티션에 매핑될 수 있는 소스 볼륨의 하나 이상의 파일들로 지정될 수 있다. 타겟 볼륨 세트는 예를 들어, 블록 저장 서버들(105)의 타겟 볼륨들, 컴퓨팅 서버들(115)의 인스턴스들(116), 또는 이들의 조합으로 지정될 수 있다. 객체 저장 서버들(110) 또는 외부 네트워크 장치들에 대한 듀플리케이션이 필요한 경우, 타겟 셋트는 객체 저장 서버들(110) 또는 외부 네트워크 장치들의 위치들로 지정될 수 있다.
(2)에서, 분산 복제본 코디네이터(205A)는 파티션을 복제하기 위한 미해결 요청들의 개수가 임계 레벨을 초과한다고 결정한다. 일 실시예에서, 임계 레벨은 컴퓨팅 시스템(110)의 관리자 또는 소스 볼륨의 사용자와 같이, 설정값으로 미리 설정될 수 있다. 다른 실시예에서, 임계 레벨은 파티션을 듀플리케이트하라는 모든 미해결 요청들을 완료하는 데 필요할 것으로 예상되는 인계 시간일 수 있다. 예를 들어, 코디네이터(205A)는 (예를 들어, 파티션을 듀플리케이트하라는 요청들을 완료하기 위한 시간에 관한 이력 정보를 기반으로) 파티션을 듀플리케이트하라는 미해결 요청의 큐를 중지하는 데 필요한 예상 시간을 결정할 수 있으며, 큐를 중지시키는 데 필요한 예상 시간이 임계 시간(예를 들어, 컴퓨팅 시스템(110)의 관리자 또는 소스 볼륨의 사용자에 의해 설정됨)을 초과할 때 파티션을 듀플리케이트하라는 미해결 요청들의 수가 임계 레벨을 초과했다고 결정할 수 있다.
파티션을 복제하라는 미해결 요청들의 개수가 임계 레벨을 초과한다는 결정 후에, (3)에서, 코디네이터는 소스 파티션의 복제를 용이하게 하기 위해 생성되어야 하는 중간 듀플리케이트 파티션들의 개수를 결정한다. 일 실시예에서, 중간 파티션들의 수는 파티션을 듀플리케이트하라는 미해결 요청들의 수에 적어도 부분적으로 기초한다. 예시적으로, 중간 파티션들의 수는 중간 듀플리케이트 파티션들과 소스 파티션의 조합이 임계 시간 내에 듀플리케이트하라는 미해결 요청들의 충족을 용이하게 할 수 있도록 코디네이터(205A)에 의해 결정될 수 있다. 다른 경우에, 관리자 또는 사용자는 소스 파티션 또는 중간 듀플리케?憐? 파티션 당 원하는 개수의 미해결 요청들을 지정할 수 있다. 예를 들어, 파티션 당 원하는 미해결 요청들의 수가 20인 경우, 중간 듀플리케이트들의 수는 미해결 요청을들을 20으로 나누고 1을 빼서(초기 소스 파티션을 고려하여) 계산될 수 있다. 일부 경우에, 결정된 수가 최대값을 초과하지 않도록 중간 듀플리케이트 파티션들의 최대 수가 설정될 수 있다. 이는 (예를 들어, 대량 듀플리케이션이 임계 레벨에 걸쳐 파티션을 듀플리케이트하라는 미해결 요청들의 수로 표현되는 경우) 파티션의 대량 듀플리케이션을 용이하게 하는 데 사용되는 컴퓨팅 시스템(110)의 총 리소스들을 제한할 수 있다.
(4)에서, 분산 복제본 코디네이터(205A)는 초기 파티션을 제2 컨테이너 서버(도 10b의 컨테이너 서버(220B)로 도시됨)에 복사하고, 이에 따라 제2 컨테이너 서버에 중간 듀플리케이트 복제본을 생성하기 위해 고도로 분산된 복제본의 초기 파티션을 호스팅하는 컨테이너 서버(220)(도 10a의 컨테이너 서버(220A)로 도시됨)에 인스트럭션들을 제출한다. 일 실시예에서, 인스트럭션들은 제2 컨테이너 서버를 지정한다. 다른 실시예들에서, 제2 컨테이너 서버는 초기 파티션을 호스팅하는 컨테이너 서버에 의해 (예를 들어, 무작위 선택으로) 선택된다. (5)에서, 컨테이너 서버(220A)는 초기 파티션을 컨테이너 서버(220B)에 복사하며, 이에 따라 컨테이너 서버(220B)에 중간 듀플리케이트 파티션을 생성한다. (6)에서, 컨테이너 서버(220B)는 컨테이너 서버(220B)에 중간 듀플리케이트 파티션이 생성되었다는 확인 응답을 코디네이터(205A)에 전송한다.
이후, 상호 작용 (4) 내지 (6)은 중간 듀플리케이트 파티션들의 수가 (3)에서 코디네이터(205A)에 의해 결정된 수와 일치될 때까지, 직렬, 병렬 또는 이들의 조합으로 반복될 수 있다. 예를 들어, 컨테이너 서버(220B)에서 중간 듀플리케이트의 생성의 확인 응답을 수신한 후, 코디네이터(205)는 상호 작용 (4)을 두 번(잠재적으로 일제히 또는 동시에) 반복할 수 있는데, 한 번은 컨테이너 서버(220C)에 중간 듀플리케이트를 생성하도록 컨테이너 서버(220A)에 지시하고, 한 번은 컨테이너 서버(220N)에 중간 듀플리케이트를 생성하도록 컨테이너 서버 (220B)에 지시한다. 상호 작용 (4) 내지 (6)의 각각의 반복 시, 초기 파티션의 정보에 대한 소스들의 수가 증가할 수 있으며, 따라서 더 많은 중간 듀플리케이트들의 생성을 용이하게 할 수 있으며, 이는 차례로 초기 파티션의 정보의 추가 소스들을 나타낸다. 이러한 방식으로, 상호 작용 (4) 내지 (6)의 반복은 소스 파티션의 중간 듀플리케이트들의 수를 기하급수적으로 증가시킬 수 있다.
충분한 수의 중간 듀플리케이트들이 생성된 후(예를 들어, (3)에서 결정된 수를 충족함), 도 10a의 상호 작용들은 도 10b에 도시된 바와 같이 계속될 수 있다. 특히, 코디네이터(205A)는, (7)에서, 충분한 개수의 중간 듀플리케이트들이 생성되었음을 검출하고, (8)에서, 초기 파티션 및 중간 듀플리케이트들을 호스팅하는 서버들(220)에게 타겟 볼륨들에 파티션 정보(초기 파티션 및 중간 듀플리케이트 파티션들으로 표시됨)의 복사를 실행하도록 지시한다. 도 10b의 상호 작용들에서, 각 컨테이너 서버들(220N) 간에 파티션 정보가 듀플리케이트된 것으로 가정된다. 그러나, 듀플리케이션은 또한 모든 컨테이너 서버들(220N) 미만에서도 가능하다. 더욱이, 예시를 위해 타겟 볼륨들의 상호 작용들에서 블록 블록 저장 서버들(110C)의 볼륨들이 있도록 가정된다. 따라서, (9)에서, 각 컨테이너 서버(220)는 파티션 복사 동작을 실행하여, 소스 파티션의 정보를 목적지 블록 저장 서버(310)에 복사한다. 이러한 동작들은 병렬로 수행될 수 있기 때문에, 컨테이너 서버(220A)의 초기 파티션으로부터 직렬로 파티션 복사 동작을 실행하는 것과 비교하여 소스 파티션의 정보는 블록 저장 서버들(310)로 빠르게 복사될 수 있다.
도 10b는 파티션 복사 동작의 단일 병렬화를 도시하고 있지만, 이러한 상호 작용들은 소스 파티션의 정보를 임의 개수의 블록 저장 서버들(310) 또는 기타 네트워크 장치들로 복사하는 것을 용이하게 하기 위해 반복될 수 있다. 예시적으로, 코디네이터(205A)는 소스 파티션을 타겟 볼륨에 듀플리케이트하라는 미해결 요청을 수행하기 위해 개별 컨테이너 서버들(220)에 인스트럭션들을 전송하는 워크플로우 제어 알고리즘을 구현할 수 있다. 각 파티션 복사 동작이 완료될 때, 컨테이너 서버(220)는 이러한 완료를 코디네이터(205A)에게 보고할 수 있으며, 이 코디네이터는 소스 파티션을 듀플리케이트하라는 또 다른 미해결 요청(존재하는 경우)을 수행하기 위한 인스트럭션들을 컨테이너 서버(220)에 전송할 수 있다. 이러한 상호 작용들은 소스 파티션을 듀플리케이트하라는 미해결 요청들이 더 이상 존재하지 않을 때까지 또는 미해결 요청의 수가 도 10c에 대해 설명되는 바와 같이, 초과 중간 듀플리케이트들이 가비지 수집 프로세스를 통해 제거되어야 함을 나타내는 임계 레벨 아래로 떨어질 때까지 반복될 수 있다. 일부 경우에, 각 컨테이너 서버(220)는 다수의 미해결 요청들을 처리하도록 구성될 수 있으며, 이와 같이, 코디네이터(205A)는 다수의 파티션 복사 동작들을 실행하기 위한 인스트럭션들을 각 컨테이너 서버(220)에 제출할 수 있다.
상기에 언급된 바와 같이, 도 10c는 초과 중간 듀플리케이트가 컨테이너 서버들(220)로부터 제거되어, 컨테이너 서버들(220)에 필요한 컴퓨팅 리소스들을 감소시킬 수 있도록, 중간 듀플리케이트들과 관련하여 "가비지 수집"을 구현하기 위한 예시적인 상호 작용들을 도시한다. 구체적으로, 도 10c의 상호 작용들은 (10)에서 시작하며, 여기서 분산 복제본 코디네이터(205A)는 미해결된 파티션 복사 요청들의 개수가 임계 레벨 미만으로 떨어졌음을 검출한다. 일 실시예에서, 임계 레벨은 소스 파티션들의 총 수로 나눈 미해결 복사 요청들의 총 수(예를 들어, 초기 파티션 및 파티션의 중간 듀플리케이트들을 포함함)가 임계 레벨 미만으로 떨어질 때 임계값이 충족되도록 파티션 당 값으로 설정될 수 있다. 예를 들어, 컨테이너 서버(220)에서 5번 듀플리케이트된 파티션에 대해 요청이 100개 미만인 경우, 파티션 당 20개인 요청들의 임계값이 충족될 수 있다. 다른 실시예에서, 임계 레벨은 미해결 파티션 복사 요청을 충족하는 데 필요한 임계 시간으로 지정될 수 있다. 예를 들어, 컨테이너 서버들(220)의 정보에 대한 현재 듀플리케이트 파티션들의 수가 30 초 이내에 모든 미해결 요청들을 충족할 것으로 예상되는 경우, 임계 레벨이 충족될 수 있다.
파티션을 복사하라는 미해결 요청들이 임계 레벨 미만으로 떨어졌음을 검추한 후, 분산 복제본 코디네이터(205A)는 (12)에서, 불필요한 중간 듀플리케이트들을 삭제하라는 인스트럭션들을 컨테이너 서버들(220)로 전송한다. 일 실시예에서, 분산 복제본 코디네이터(205A)는 중간 듀플리케이트(예를 들어, 무작위)를 호스팅하는 단일 컨테이너 서버(220)를 선택하고, 호스팅된 중간 듀플리케이트를 삭제하라는 인스트럭션들을 컨테이너 서버(220)에 전송할 수 있다. 이후, 상호 작용들 (11) 및 (12)은 미해결 파티션 복사 요청들이 더 이상 임계 레벨 미만으로 떨어지지 않을 때까지 반복될 수 있다. 다른 실시예에서, 분산 복제본 코디네이터(205A)는 미해결 파티션 복사 요청들이 더 이상 임계 레벨 미만으로 떨어지지 않도록 삭제될 중간 듀플리케이트들의 수를 결정할 수 있으며, (12)에서, 해당 개수의 중간 듀플리케이트들을 호스팅하는 컨테이너 서버들(220)에 인스트럭션들을 전송할 수 있다. 이러한 방식으로, 코디네이터(205A)는 컨테이너 서버(220) 내에서 과도한 중간 듀플리케이트들이 유지되지 않도록 하여, 컨테이너 서버들(220)의 리소스들을 다른 동작들(예를 들어, 다른 파티션들, 다른 볼륨들의 듀플리케이션 등)에 사용할 수 있게 할 수 있다.
상기에 논의된 실시예들이 미해결 파티션 복사 요청들에 기초한 중간 듀플리케이트의 삭제와 관련되어 있지만, 추가 또는 대체 메트릭들이 중간 듀플리케이트를 삭제할지 여부를 결정하는 데 사용될 수 있다. 예를 들어, 분산 복제본 코디네이터(205A)는 초기 파티션에 대한 복사 요청들의 이력 사용량을 얻거나 결정할 수 있으며, 이러한 이력 사용량으로부터 (예를 들어, 이력 사용량을 향후 시간으로 투영하여) 파티션에 대한 향후 복사 요청들을 예측할 수 있다. 이후, 분산 복제본 코디네이터(205A)는 파티션에 대한 예측된 향후 복사 요청들(예를 들어, 향후 기간 동안)이 임계 레벨 미만으로 떨어질 때만 하나 이상의 중간 듀플리케이트들을 삭제하도록 기능할 수 있다. 일 실시예에서, 향후 시간 기간은 컨테이너 서버들(220)에 의해 중간 듀플리케이트 파티션을 삭제하고 재생성하는 데 필요한 시간에 적어도 부분으로 기초하여 설정될 수 있다. 따라서, 예를 들어, 향후 파티션 복사 요청들이 중간 듀플리케이트 파티션을 삭제하고 재생성하는 데 필요한 시간보다 짧은 시간 내에 중간 듀플리케이트 파티션의 사용을 보증하기에 충분할 것으로 예상되는 경우, 분산 복제본 코디네이터(205A)는 중간 듀플리케이트 파티션이 삭제되지 않아야 한다고 결정할 수 있다.
도 11a 내지 11c를 참조하면, 도 10a 내지 10c의 상호 작용들에 대한 추가 또는 대안 상호 작용 세트가 설명될 것이다. 구체적으로, 도 10a 내지 10c의 상호 작용들은 분산된 복제본의 파티션의 대량 듀플리케이션을 제어하기 위한 중앙 집중식 권한으로서 분산 복제본 코디네이터(205A)의 사용과 관련되지만, 11a 내지 11c는 분산된 복제본의 파티션의 대량 듀플리케이션을 제어하기 위한 컨테이너 서버들(220)의 피어 투 피어 동작과 관련된다. 도 11a 내지 11c의 상호 작용들은 도 10a 내지 10c의 상호 작용들(예를 들어, 분산 복제본 코디네이터(205A)에 대한 운영 부하를 줄이기 위해)에 대한 대안으로서 또는 도 10 내지 10c의 상호 작용들에 더해 구현될 수 있다. 예를 들어, 코디네이터(205A)가 고도로 분산된 복제본의 각 파티션에 대한 워크로드 정보를 유지하기 위해 과도한 컴퓨팅 리소스들이 필요한 경우, 코디네이터(205A)는 고도로 액세스되는 파티션들의 대량 듀플리케이션만을 제어하는 중앙 집중식 권한으로서의 역을 하도록 구성될 수 있으며, 컨테이너들(220)은 덜 액세스되는 파티션들을 듀플리케이트해야 하는 할 필요가 발생하는 경우, 덜 액세스되는 파티션의 듀플리케이션을 제어하기 위해 피어 투 피어 구성으로 추가로 작동할 수 있다. 고도로 액세스된 파티션들은 예를 들어, 그 예들이 당업계에 알려진 "헤비 히터(heavy hitter)" 알고리즘의 사용에 의해 또는 값들의 스트림(예를 들어, 모든 복사 요청들) 내에서 값들(예를 들어, 개별 타피션을 복사하라는 요청들)의 빈번한 발생을 추적하는 다른 메모리 효율적 알고리즘의 사용에 의해 코디네이터에서 식별될 수 있다.
도 11a의 상호 작용들은 (1)에서 시작되며, 여기서 분산 복제본 코디네이터(205A)는 볼륨에 대한 고도로 분산된 복제본의 파티션을 도 10a의 상호 작용 (1)과 유사한 방식으로 타겟 볼륨 세트에 복사하라는 요청을 수신한다. 그러나, 도 10a의 상호 작용들과는 대조적으로, 도 11a의 분산 복제본 코디네이터(205A) 초기 파티션의 중간 듀플리케이트들의 생성을 용이하게 할 필요가 없다. 오히려, (2)에서, 코디네이터(205A)는 요청된 파티션 복사 동작들을 실행하기 위한 인스트럭션들을 초기 파티션(여기서는, 컨테이너 서버(220A))을 호스팅하는 컨테이너 서버(220)에 전송할 수 있다.
(3)에서, 컨테이너 서버(220A)는 파티션을 복사하라는 미해결 요청들(예를 들어, 컨테이너 서버(220)의 요청들의 큐 내에 유지됨)이 임계 레벨을 초과함을 검출한다. 상기에 논의된 방식과 유사한 방식으로, 임계 레벨은 컴퓨팅 시스템(110)의 관리자나 소스 볼륨의 사용자 또는 파티션을 듀플리케이트하라는 모든 미해결 요청들을 완료하는 데 필요할 것으로 예상되는 임계 시간에 의해서와 같은 설정값으로 미리 설정될 수 있다. 예를 들어, 컨테이너 서버(220A)는 (예를 들어, 파티션을 듀플리케이트하라는 요청들을 완료하기 위한 시간에 관한 이력 정보를 기반으로) 파티션을 듀플리케이트하라는 미해결 요청의 큐를 중지하는 데 필요한 예상 시간을 결정할 수 있으며, 큐를 중지시키는 데 필요한 예상 시간이 임계 시간(예를 들어, 컴퓨팅 시스템(110)의 관리자 또는 소스 볼륨의 사용자에 의해 설정됨)을 초과할 때 파티션을 듀플리케이트하라는 미해결 요청들의 수가 임계 레벨을 초과했다고 결정할 수 있다.
(3)의 검출에 응답하여, 컨테이너 서버(220A)는, (4)에서, 초기 파티션을 다른 컨테이너 서버(220C)에 복사하여, 파티션의 중간 듀플리케이트를 컨테이너 서버(220C)에 생성한다. 컨테이너 서버(220A)는 임의 개수의 공지된 로드 밸런싱 또는 임의 선택, 라운드 로빈 선택 등과 같은 선택 알고리즘들에 따라 컨테이너 서버(220C)를 선택할 수 있다. 일 실시예에서, 서버(220C)에 초기 파티션을 복사하기 전에, 컨테이너 서버(220A)는 서버(220C)에 중간 듀플리케이트의 생성을 요청하기 위해 서버(220C)에 쿼리할 수 있다. 서버(220C)가 수락하는 경우, 상호 작용들이 상기에 설명된 바와 같이 진행될 수 있다. 서버(220C)가 거절하는 경우, 컨테이너 서버(220A)는 중간 듀플리케이트의 생성을 요청할 서버(220)를 선택및 대체할 수 있다. 예를 들어, 서버(220C)는 서버(220C)가 이미 초기 파티션의 중간 듀플리케이트를 호스팅하는 경우, 서버(220C)의 현재 워크로드가 너무 커서 중간 듀플리케이트의 생성 등을 가능하게 할 수 없는 경우, 거부할 수 있다.
서버(220C)가 수락한다는 가정하에서, 상호 작용들은 (5)로 진행되며, 여기서 컨테이너 서버(220A)는 현재 파티션 복사 인스트럭션들의 큐의 일부를 컨테이너 서버(220C)로 전송한다. 일 실시예에서, 서버(220A)는 파티션 복사 인스트럭션들의 기존 큐의 절반을 전송할 수 있으며, 따라서 서버들(220A 및 220C) 간에 파티션 복사 인스트럭션들을 나눌 수 있다.
이후, 상호 작용들 (3) 및 (4)와 유사한 상호 작용들은 각 컨테이너 서버(220A)가 상기에 논의된 임계 레벨 미만으로 떨어지는 파티션 복사 인스트럭션들을 유지할 때까지, 컨테이너 서버들(220) 내에서 계속 발생할 수 있다. 예를 들어, 두 컨테이너 서버들(220) 사이의 미해결 파티션 복사 인스트럭션들의 분할이 서버(220)의 큐가 미해결 요청들의 임계 레벨 미만으로 떨어지게 하기에 충분하지 않은 상호 작용들이 도 11b에 도시된다. 따라서, 도 11b에 도시된 바와 같이, 각 컨테이너 서버(220A 및 220C)는 미해결 파티션 복사 요청들의 큐가 (6') 및 (6'')(주요 표기법은 반드시 필요한 것은 아니나, 동시에 발생할 수 있는 독립적인 상호 작용들을 나타냄)에서 임계 레벨(예를 들어, 상기에 설명된 바와 같이 결정됨)을 초과한다고 독립적으로 결정할 수 있다. 이후, (7') 및 (7'')에서, 서버들(220A 및 220C) 각각은 파티션을 다른 서버(각각, 서버들(220B 및 220N))로 복사하여, 서버들(220) 간에 파티션의 듀플리케이트들의 수를 두 배로 증가시킨다. 이와 유사한 상호 작용들은 각 서버(220)가 임계값 미만으로 떨어지는 미해결 파티션 복사 인스트럭션들의 큐를 유지할 때까지 컨테이너 서버들 (220) 간에 계속 발생할 수 있다. 이후, (8)에서, 초기 파티션 또는 중간 듀플리케이트 파티션들을 호스팅하는 서버들(220)은 블록 저장 서버들(310)에 대한 파티션 복사 동작들을 실행하여, 파티션을 타겟 볼륨들에 복사할 수 있다. 상호 작용 (9)에서 단일 동작으로 표시되어 있지만, 각 서버(220)는 파티션 복사를 병렬로 실행할 수 있으며, 따라서 블록 저장 서버들(310)로의 파티션의 정보의 신속한 전달을 가능하게 한다. 게다가, 각 서버(220)는 보류중인 파티션 복사 인스트럭션들의 자체 유지 관리된 큐를 처리하도록 구성될 수 있으며, 이와 같아, 서버(220)의 큐 내의 미해결 인스트럭션들의 수가 임계 레벨 미만으로 떨어질 때까지 파티션 사본들 자체를 병렬로, 직렬로 또는 이들의 조합으로 실행할 수 있다.
도 11a 및 11b의 상호 작용들이 파티션을 복사하라는 하나의 요청 세트에 대해 설명되어 있지만, 컨테이너 서버들(220)은 이전에 생성된 중간 듀플리케이트들을 기반으로 후속 요청들을 계속 라우팅하도록 구성될 수 있다. 예를 들어, 분산 복제본 코디네이터(205A)는 서버(220A)가 이 인스턴스에서 복사될 초기 파티션을 호스팅하는 것으로 가정되므로, 컨테이너 서버(220A)로 파티션 복사를 실행하기 위한 인스트럭션들을 계속 전송할 수 있다. 서버(220A)는 그 자체와 서버(220A)에 알려진 임의의 서버들 (220) 중에서 후속 파티션 복사 인스트럭션들을 분산시켜 파티션의 중간 듀플리케이트를 호스팅할 수 있다. 예를 들어, 도 11a 및 11b의 상호 작용들에서, 서버(220)는 서버들(220B 및 220C)에 중간 듀플리케이트들이 존재함을 인식할 수 있으며, 따라서 추후에 알려진 여러 로드 밸런싱 기술들에 따라(예를 들어, 라운드 로빈 분산을 이용하여) 서버들(220A, 220B 및 220C) 각각에 요청들을 분산시킬 수 있다. 다른 서버들(220)은 유사하게 중간 듀플리케이트들을 호스팅하는 추가의 알려진 서버들(220)에 요청들을 포워딩할 수 있으며, 따라서 후속 요청들이 파티션의 중간 듀플리케이트들 사이에서 분산되도록 할 수 있다.
도 11c를 참조하면, 컨테이너 서버들(220)의 피어 투 피어 구성 내에서 가비지 수집을 구현하기 위한 예시적인 상호 작용이 도시되어 있다. 구체적으로, 각 컨테이너(220)는 상위 임계 레벨(예를 들어, 도 11a 및 11b를 참조하여 상기에 설명됨) 이하로 또는 하위 임계 레벨 이상으로 떨어지는 미해결 파티션 복사 인스트럭션들의 큐를 유지하도록 구성될 수 있다. 하위 임계 레벨은 상기에 논의된 상위 임계 레벨과 유사한 방식으로, 예를 들어 각 서버에서 최소 미해결 요청들의 수 또는 모든 미해결 파티션 복사 요청들을 완료하는 데 필요한 최소 시간과 관련하여 지정될 수 있다. 일부 경우에, 하위 임계 레벨은 0으로 설정될 수 있어, 컨테이너 서버(220)가 서버(220)에 파티션을 복사하라는 미해결 요청들이 존재하지 않을 때만 파티션의 중간 듀플리케이트을 삭제하도록 구성될 수 있도록 한다. 일부 경우에, 주어진 서버(220)는 "다운스트림" 서버들(220)이 중간 듀플리케이트을 유지하는 것으로 알려진 경우에만 중간 듀플리케이트를 삭제하도록 구성되며, 다운 스트림 서버들(220)은 주어진 서버(220)가 중간 듀플리케이트을 생성하게 하는 서버들(220)을 말한다.
도 11c에서, 두 개의 컨테이너 서버들(220)인, 서버들(220B 및 220N)이 상호 작용 (9') 및 (9'')에서 서버들(220)의 미해결 요청들이 하위 임계 레벨 미만으로 떨어지는 것을 검출한다고 가정한다. 이와 같이, (10') 및 (10'')에서, 서버들(220)은 중간 듀플리케이트들을 삭제하여, 서버들(220)의 컴퓨팅 리소스들을 확보한다. 추가로, (11') 및 (11'')에서, 서버들(220)은 중간 듀플리케이트들의 삭제를 '업스트림' 서버(220)에 보고하며, 주어진 서버(220)에 대한 업스트림 서버(220)는 주어진 서버(220)가 중간 듀플리케이트를 생성하게 하는 서버(220)를 말한다. 추가로, (11') 및 (11'') 상호 작용들에서, 서버들(220)은 서버들(220)의 임의의 나머지 파티션 복사 인스트럭션들을 업스트림 서버(220)로 전송한다. 따라서, 업스트림 서버(220)는 미해결 복사 인스트럭션들이 하위 임계값 미만으로 떨어지는 서버들(220)의 워크로드를 채택하는 것으로 볼 수 있다.
도 11c를 참조하여 상기에 언급된 바와 같이, 상기에 논의된 실시예들이 미해결 파티션 복사 요청들에 기초한 중간 듀플리케이트의 삭제와 관련되어 있지만, 추가 또는 대체 메트릭들이 중간 듀플리케이트를 삭제할지 여부를 결정하는 데 사용될 수 있다. 예를 들어, 컨테이너 서버(220)는 중간 듀플리케이트들로 표현된 파티션에 대한 복사 요청들의 이력 사용량을 얻거나 결정할 수 있으며, 이러한 이력 사용량으로부터 (예를 들어, 이력 사용량을 향후 시간으로 투영하여) 파티션에 대한 향후 복사 요청들을 예측할 수 있다. 이후, 컨테이너 서버(220)는 파티션에 대한 예측된 향후 복사 요청들(예를 들어, 향후 시간 기간 동안)이 임계 레벨 미만으로 떨어질 때만 그 중간 듀플리케이트들을 삭제하도록 기능할 수 있다. 일 실시예에서, 향후 시간 기간은 컨테이너 서버들(220)에 의해 중간 듀플리케이트 파티션을 삭제하고 재생성하는 데 필요한 시간에 적어도 부분으로 기초하여 설정될 수 있다. 따라서, 예를 들어, 향후 파티션 복사 요청들이 중간 듀플리케이트 파티션을 삭제하고 재생성하는 데 필요한 시간보다 짧은 시간 내에 중간 듀플리케이트 파티션의 사용을 보증하기에 충분할 것으로 예상되는 경우, 컨테이너 서버(220)는 중간 듀플리케이트 파티션이 삭제되지 않아야 한다고 결정할 수 있다.
도 12를 참조하면, 볼륨(또는 볼륨의 일부)을 타겟 볼륨 세트로 대량 듀플리케이션하는 것을 용이하게 하기 위해 하나 이상의 중간 듀플리케이트들을 활용하는 예시적인 루틴(1200)이 도시되어 있다. 루틴(1220)은 예를 들어, 볼륨에 대해 고도로 분산된 복제본을 호스팅하는 컨테이너 서버 세트(220)에 의해 독립적으로 또는 분산 복제본 컨테이너(205)와 같은 컴퓨팅 시스템(120)의 다른 요소들과 함께 수행될 수 있다.
루틴(1200)은 1202에서 시작하며, 여기서 볼륨의 하나 이상의 파티션을 타겟 볼륨 세트로 복사하라는 요청들은 컨테이너 서버들(220) 또는 코디네이터(205)에 의해 수신된다. 상기에 언급된 바와 같이, 요청은 예를 들어, 컴퓨팅 시스템(120)의 API를 통해 사용자에 의해 제출될 수 있으며, 예를 들어 타겟 볼륨 세트로 복사될 하나 이상의 파티션들 내에 저장된 정보를 식별할 수 있다.
블록(1204)에서, 컨테이너 서버들(220)은 하나 이상의 파티션들 각각에 대해, 하나 이상의 중간 듀플리케이트 파티션들을 생성하여 요청된 사본을 용이하게 하는 데 활용한다. 일 실시예에서, 중간 듀플리케이트 파티션들은 예를 들어, 상기의 도 10a 내지 10c의 상호 작용들에 따른, 복제본 코디네이터(205)와 같은 중앙 집중식 권한에 의해 생성된다. 다른 실시예들에서, 중간 듀플리케이트 파티션들은 예를 들어, 상기의 도 11a 내지 11c의 상호 작용들에 따른, 컨테이너 서버들(220)의 피어 투 피어 상호 작용들을 통해 생성된다.
블록(1206)에서, 하나 이상의 파티션들을 복사하라는 요청들은 중간 듀플리케이트들을 호스팅하는 서버들(220) 사이에서 나뉜다. 일 실시예에서, 복제본 코디네이터(205)와 같은 중앙 집중식 권한은 예를 들어, 상기의 도 10a 내지 10c의 상호 작용들에 따른 중간 듀플리케이트들을 호스팅하는 서버들(220) 사이에서 요청들을 나누도록 동작한다. 다른 실시예에서, 서버(220)는 예를 들어, 상기의 도 11a 내지 11c의 상호 작용들에 따른, 서버들(220) 사이에서 요청들을 나누도록 피어 투 피어 방식으로 상호 작용한다.
블록(1208)에서, 파티션 복사 동작들은 하나 이상의 파티션들의 정보(예를 들어, 파티션들의 초기 사본들 또는 파티션들의 중간 듀플리케이트들 내에 포함됨)를 타겟 볼륨들에 복사하도록 서버들(220)에 의해 수행된다. 파티션 복사 동작들은 적어도 부분적으로 병렬로 구현될 수 있기 때문에, 그리고 중간 듀플리케이트들의 수가 타겟 볼륨의 수에 비해 높을 수 있기 때문에(잠재적으로 타겟 볼륨과 1 대 1 비율로), 파티션 복사 동작들은 중간 듀플리케이트들 없이 하나 이상의 파티션들의 초기 복사들만 사용하는 것에 비해 빠르게 완료될 수 있다.
블록(1210)에서, 서버들(220)은 가비지 수집을 수행하여 서버들(220)에서 과도한 중간 듀플리케이트들을 삭제한다. 가비지 수집은 예를 들어, 상기 도 10c의 상호 작용들에 따른, 중앙 집중식 권한에 의해 용이하게 될 수 있다. 다른 실시예에서, 서버들(220)은 예를 들어, 상기의 도 11c의 상호 작용들에 따른, 가비지 수집을 구현하기 위해 피어 투 피어 방식으로 상호 작용한다. 그런 다음, 루틴(1200)이 종료된다.
루틴(1200)이 사용자 요청에 기초하여 예시적으로 시작된 것으로 상기에 설명되어 있지만, 일부 실시예들에서 루틴(1200)은 대안적인 메커니즘들을 통해 구현될 수 있다. 예시적으로, 루틴(1200)은 타겟 볼륨으로부터 해당 파티션의 데이터를 읽으라는 사용자 요청에 응답하여 특정 파티션의 빠른 듀플리케이션을 제공하기 위한 메커니즘으로 구현될 수 있다. 예를 들어, 사용자가 초기 볼륨(예를 들어, 1차, 2차 및 3차 복제본으로 표시되며, 그 각각은 파티션들의 수로 분할될 수 있음)을 대규모 타겟 볼륨 세트(예를 들어, 수백 또는 수천 개의 볼륨들)에 복사할 것을 요청하는 경우를 고려한다. 본 개시의 일 실시예에서, 블록 저장 서버들(105)은 이러한 복사 동작들이 기존 파티션들로부터 타겟 볼륨 세트를 생성하는 데 많은 시간이 필요할 수 있다는 예상에도 불구하고, 기존 파티션들(예를 들어, 1차, 2차 및 3차 복제본들)을 기반으로 복사 동작 세트를 시작할 수 있다. 그러나, 블록 저장 서버들(105)은 복사 동작 세트가 완료되기 전에도, 초기 볼륨의 데이터가 타겟 볼륨 세트에서 이용 가능함을 사용자에게 추가로 통지할 수 있다. 블록 저장 서버들(105)은 초기 볼륨의 파티션으로부터 읽기 볼륨으로 데이터를 복사하라는 요청을 시작함으로써 타겟 볼륨 세트의 볼륨에 대한 읽기 요청에 응답하는 기능을 추가로 수행할 수 있다. 예시적으로, 타겟 볼륨 세트의 볼륨들에서 충분한 수의 읽기 요청들이 수신되면, 초기 볼륨의 파티션으로부터 데이터를 복사하라는 해당 요청 세트가 루틴(1200)을 시작할 수 있다. 따라서, 일부 경우에, 루틴(1200)의 구현은 블록 저장 서버(105)가 사용자들로부터 이러한 볼륨을 읽으라는 요청들에 응답하여 "즉시" 타겟 볼륨들에 데이터를 채우게 할 수 있다.
용어
본원에 설명된 모든 방법들 및 태스크들은 컴퓨터 시스템에 의해 수행되고 완전히 자동화될 수 있다. 컴퓨터 시스템은 일부 경우에, 설명된 기능들을 수행하기 위해 네트워크를 통해 통신하고 상호 운용하는 다수의 별도의 컴퓨터들 또는 컴퓨팅 장치들(예를 들어, 물리적 서버들, 워크스테이션들, 스토리지 어레이들, 클라우드 컴퓨팅 리소스들 등)을 포함할 수 있다. 각각의 이러한 컴퓨팅 장치는 일반적으로 메모리 또는 다른 비일시적 컴퓨터 판독 가능 저장 매체 또는 장치(예를 들어, 솔리드 스테이트 스토리지 장치들, 디스크 드라이브들 등)에 저장된 프로그램 인스트럭션들 또는 모듈들을 실행하는 프로세서(또는 다수의 프로세서들)를 포함한다. 본원에 개시된 다양한 기능들은 이러한 프로그램 인스트럭션들로 구현될 수 있거나, 컴퓨터 시스템의 주문형 반도체(예를 들어, ASIC 또는 FPGA)들에 구현될 수 있다. 컴퓨터 시스템이 다수의 컴퓨팅 장치들을 포함하는 경우, 이러한 장치들은 반드시 필요한 것은 아니나, 함께 배치될 수 있다. 개시된 방법들 및 태스크들의 결과들은 솔리드 스테이트 메모리 칩들 또는 자기 디스크들과 같은 물리적 스토리지 장치들을 다른 상태로 변환함으로써 지속적으로 저장될 수 있다. 일부 실시예들에서, 컴퓨터 시스템은 클라우드 기반 컴퓨팅 시스템일 수 있으며, 그 처리 리소스들은 다수의 별도의 엔터티들 또는 다른 사용자들에 의해 공유된다.
프로세스들(230, 320, 410, 505A, 505B 및 901)은 미리 결정되거나 동적으로 결정된 스케줄과 같은 이벤트에 대한 응답하여, 사용자 또는 시스템 관리자에 의해 시작될 때 요구에 따라 또는 일부 다른 이벤트에 응답하여 시작할 수 있다. 프로세스(230, 320, 410, 505A, 505B, 901 또는 1201)가 시작되면, 하나 이상의 비일시적 컴퓨터 판독 가능 매체(예를 들어, 하드 드라이브, 플래시 메모리, 이동식 매체, 등)은 서버 또는 다른 컴퓨팅 장치의 메모리(예를 들어, RAM)에 로드될 수 있다. 그런 다음, 실행 가능한 인스트럭션들은 컴퓨팅 장치의 하드웨어 기반 컴퓨터 프로세서에 의해 실행될 수 있다. 일부 실시예들에서, 프로세스(230, 320, 410, 505A, 505B, 901, 1201) 또는 그 일부들은 다수의 컴퓨팅 장치들 및/또는 다수의 프로세서들에서 직렬로 또는 병렬로 구현될 수 있다.
실시예에 따라, 본원에 설명된 임의의 프로세스들 또는 알고리즘들의 특정 액션들, 이벤트들 또는 기능들은 다른 순서로 수행될 수 있고, 추가, 병합 또는 모두 생략될 수 있다(예를 들어, 설명된 모든 동작들 또는 이벤트들이 알고리즘의 실행을 위해 반드시 필요한 것은 아니다). 게다가, 특정 실시예들에서, 동작들 또는 이벤트들은 예를 들어, 다중 스레드 처리, 인터럽트 처리 또는 다중 프로세서들 또는 프로세서 코어들을 통해 또는 다른 병렬 아키텍처에서 순차적으로 보다는 동시에 수행될 수 있다.
본원에 개시된 실시예들과 관련하여 설명된 다양한 예시적인 논리 블록들, 모듈들, 루틴들 및 알고리즘 단계들은 전자 하드웨어(예를 들어, ASIC 또는 FPGA 장치들), 컴퓨터 하드웨어에서 실행되는 컴퓨터 소프트웨어, 또는 둘 모두의 조합으로 구현될 수 있다. 게다가, 본원에서 개시된 실시예들과 관련하여 설명된 다양한 예시적인 논리블록들 및 모듈들은 프로세서 장치, 디지털 신호 프로세서(DSP), 주문형 반도체(ASIC), 필드 프로그래밍 가능 게이트 어레이(FPGA) 또는 기타 프로그래밍 가능 로직 장치, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들 또는 본원에 설명된 기능들을 수행하도록 설계된 이들의 임의의 조합과 같은, 머신에 의해 구현되거나 수행될 수 있다. 프로세서 장치는 마이크로 프로세서일 수 있지만, 대안으로 프로세서 장치는 컨트롤러, 마이크로컨트롤러 또는 상태 머신, 이들의 조합들 등일 수 있다. 프로세서 장치는 컴퓨터 실행 가능 인스트럭션들을 처리하도록 구성된 전기 회로부를 포함할 수 있다. 다른 실시예에서, 프로세서 장치는 컴퓨터 실행 가능 인스트럭션들을 처리하지 않고 논리 동작들을 수행하는 FPGA 또는 기타 프로그래밍 가능 장치를 포함한다. 프로세서 장치는 또한 컴퓨팅 장치들의 조합, 예를 들어, DSP 및 마이크로 프로세서, 다수의 마이크로프로세서들, DSP 코어와 관련된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 구성의 조합으로 구현될 수 있다. 본원에서는 주로 디지털 기술과 관련하여 설명되었지만, 프로세서 장치는 주로 아날로그 컴포넌트들을 포함할 수도 있다. 예를 들어, 본원에 설명된 렌더링 기술들의 일부 또는 전부는 아날로그 회로부 또는 혼합 아날로그 및 디지털 회로부로 구현될 수 있다. 컴퓨팅 환경은 이에 제한되는 되는 것은 아니나, 몇 가지 예를 들면, 마이크로프로세서에 기반한 컴퓨터 시스템, 메인프레임 컴퓨터, 디지털 신호 프로세서, 휴대용 컴퓨팅 장치, 장치 컨트롤러 또는 기기 내 계산 엔진을 포함하여, 임의 유형의 컴퓨터 시스템을 포함할 수 있다.
본원에 개시된 실시예들과 관련하여 설명된 방법, 프로세스, 루틴 또는 알고리즘의 요소들은 하드웨어로, 프로세서 장치에 의해 실행되는 소프트웨어 모듈로, 또는 이 둘의 조합으로 직접 구현될 수 있다. 소프트웨어 모듈은 RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터, 하드 디스크, 이동식 디스크, CD-ROM 또는 임의의 다른 형태의 비일시적 컴퓨터 판독 가능 저장 매체에 상주할 수 있다. 예시적인 저장 매체는 프로세서 장치가 저장 매체로부터 정보를 읽고 저장 매체에 정보를 쓸 수 있도록 프로세서 장치에 결합될 수 있다. 대안으로, 저장 매체는 프로세서 장치에 통합될 수 있다. 프로세서 장치 및 저장 매체는 ASIC에 상주할 수 있다. ASIC는 사용자 단말에 상주할 수 있다. 대안으로, 프로세서 장치 및 저장 매체는 사용자 단말기에서 개별 컴포넌트들로 상주할 수 있다.
달리 구체적으로 언급되지 않거나 사용된 문맥 내에서 달리 이해되지 않는 한, 그 중에서도, "할 수 있다(can)", "할 수 있다(could)", "할 수 있다(might)", "할 수 있다(may)", "예를 들어(e.g.)" 등과 같이 본원에 사용된 조건부 언어는 일반적으로 특정 실시예들은 특정 특징들, 요소들 또는 단계들을 포함하지만 다른 실시예들은 특정 특징들, 요소들 또는 단계들을 포함하지 않는다는 점을 전달하도록 의도된다. 따라서, 이러한 조건부 언어는 일반적으로 특징들, 요소들 또는 단계들이 하나 이상의 실시예에 대해 어떤 식으로든 필요하다는 것을 암시하거나, 다른 입력 또는 프롬프트의 유무에 상관없이, 하나 이상의 실시예들이 이러한 특징들, 요소들 또는 단계들이 포함되는지 또는 임의의 특정 실시예들에서 수행될 것인지를 결정하기 위한 로직을 반드시 포함하는 것을 의미하는 것으로 의도되지 않는다. "포함하는(comprising)", "포함하는(including)", "갖는(having)" 등과 같은 용어들은 동의어로서 개방형 방식으로 포괄적으로 사용되며, 추가 요소들, 특징들, 액션들, 동작들 등을 배제하지 않는다. 또한, "또는(or)"이라는 용어는 포괄적인 의미로(배타적인 의미가 아님) 사용되므로, 예를 들어 요소들의 목록을 연결하는 데 사용되는 경우, "또는" 이라는 용어는 목록의 요소들 중 하나, 일부 또는 전부를 의미한다.
달리 구체적으로 언급되지 않는 한, "X, Y 또는 Z 중 적어도 하나"라는 문구와 같은 이접적 언어는 항목, 용어 등이 X, Y 또는 Z 중 하나 또는 그(예를 들어, X, Y 또는 Z) 임의의 조합일 수 있음을 나타내기 위해 일반적으로 사용되는 문맥으로 이해된다. 따라서, 이러한 이접적 언어는 일반적으로 특정 실시예들이 X 중 적어도 하나, Y 중 적어도 하나, 및 Z 중 적어도 하나가 각각 존재하는 것을 필요로 한다는 것을 의미하는 것은 아니며, 그렇게 암시해서는 안된다.
상기의 상세한 설명은 다양한 실시예들에 적용되는 신규 특징들을 도시하고, 설명하고 지적하였지만, 예시된 장치들 또는 알고리즘들의 형태 및 세부 사항에 대한 다양한 생략, 대체 및 변경이 본 개시의 사상을 벗어나지 않고 이루어질 수 있음이 이해될 수 있다. 알 수 있는 바와 같이, 본원에 설명된 특정 실시예들은 일부 특징들이 다른 특징들과 별도로 사용되거나 실행될 수 있기 때문에, 본원에 설명된 모든 특징들 및 이점들을 제공하지 않는 형태로 구현될 수 있다. 청구 범위와 동등한 의미와 범위 내에 있는 모든 변경들은 그 범위 내에 포함되어야 한다.
전술한 내용은 다음 조항 세트의 측면에서 더 잘 이해될 수 있다:
조항 1. 시스템에 있어서,
볼륨의 1차 복제본의 제1 개수의 파티션들이 저장된 제1 서버 세트;
제1 서버와 데이터 통신하는 제2 서버 세트로서, 제2 서버 세트는 1차 복제본과 동기식으로 업데이트들을 수신하는 볼륨의 2차 복제본이 저장되며, 제1 서버 세트 및 제2 서버 세트 중 하나 또는 둘 다는 볼륨으로부터 사용자 시작 읽기들 또는 쓰기들을 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 상기 제2 서버 세트; 및
제1 서버 세트 및 제2 서버 세트 중 하나 또는 둘 다와 데이터 통신하는 복수의 추가 서버들로서, 복수의 추가 서버들은 1차 복제본과 비동기식으로 업데이트들을 수신하는 볼륨의 3차 복제본이 집합적으로 저장되고, 3차 복제본은 다수의 추가 서버들 사이에서 분산된 제2 개수의 파티션들로 저장되고, 복수의 추가 서버들은 3차 복제본의 사용에 의해 볼륨의 복제를 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되고, 제2 개수의 파티션들은 제1 개수의 파티션들보다 큰, 상기 복수의 추가 서버들을 포함한다.
조항 2. 조항 1의 시스템에 있어서, 제1 서버 세트, 제2 서버 세트 및 복수의 추가 서버들은 블록 스토리지를 사용하여 볼륨을 저장하도록 구성되며, 제3 복제본의 제2 개수의 파티션들 각각은 적어도 하나의 볼륨 블록을 나타낸다.
조항 3. 조항 1의 시스템에 있어서, 복수의 추가 서버들은 제2 개수의 파티션들 중 다수의 파티션들의 데이터를 병렬로 전송함으로써 볼륨의 복제를 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 4. 조항 1의 시스템에 있어서, 제2 개수의 파티션들은 복수의 추가 서버들에 걸쳐 스트라이프되어, 볼륨의 제1 부부을 나타내는 제1 파티션 및 제1 부분과 순차적인 볼륨의 제2 부분을 나타내는 제2 파티션이 복수의 추가 서버들 중 서로 다른 추가 서버들에 저장되도록 한다.
조항 5. 조항 1의 시스템에 있어서, 컴퓨터 실행 가능 인스트럭션들에 의해,
1차 복제본 및 2차 복제본 중 하나 또는 둘 다로부터 업데이트를 수신하고;
업데이트들을 3차 복제복으로 비동기식으로 전파하도록 하는 컴퓨터 실행 가능 인스트럭션들에 의해 구성된 로거 플릿을 더 포함한다.
조항 6. 조항 1의 시스템에 있어서,
시스템의 제어 평면을 구현하는 컴퓨팅 장치; 및
제1 개수의 파티션들을 사용하여 볼륨의 새로운 사본을 저장하기 위해 제어 평면에 의해 설정된 제3 서버 세트로서, 제3 서버 세트의 제1 개수의 파티션들 각각은 제3 복제본을 사용하여 볼륨의 새 사본을 생성하기 위해 복수의 추가 서버들로부터 제2 개수의 파티션들 중 특정 파티션들의 데이터를 검색하는, 상기 제3 서버 세트를 더 포함한다.
조항 7. 조항 6의 시스템에 있어서, 제1 복제본과 데이터 통신하고 제1 복제본으로부터 볼륨의 데이터에 액세스하도록 구성되는 컴퓨팅 리소스를 호스팅하는 제3 서버를 더 포함하며, 제3 서버는 제1 복제본의 이용 불가능한 경우에 제2 복제본으로 장애 조치하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되고, 컴퓨팅 장치는 볼륨의 새로운 사본을 새로운 제2 복제본으로 생성하도록 구성되는 제어 평면을 구현한다.
조항 8. 컴퓨터 구현 방법에 있어서,
제1 서버 세트에 제1 개수의 파티션들을 사용하여 볼륨의 1차 복제본을 저장하는 단계;
제2 서버 세트에 제1 개수의 파티션들을 사용하여 볼륨의 2차 복제본을 저장하는 단계로서, 제1 서버 세트 및 제2 서버 세트 중 하나 또는 둘 다는 1차 및 2차 복제본의 수정을 통해 볼륨으로부터 사용자 시작 읽기들 또는 쓰기들을 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 상기 저장하는 단계; 및
볼륨의 3차 복제본을 생성하는 단계로서, 적어도
제2 개수의 파티션들로 볼륨의 데이터를 분할하는 단계로서, 제2 개수의 파티션들은 제1 개수의 파티션들보다 큰, 상기 분할하는 단계, 및
제2 개수의 타피션들을 복수의 추가 서버들에 걸쳐 분산시키는 단계에 의해 상기 3차 복제본을 생성하는 단계를 포함하며,
복수의 추가 서버들은 3차 복제본의 사용에 의해 볼륨의 복제를 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 9. 조항 8의 컴퓨터 구현 방법에 있어서,
1차 복제본 및 2차 복제본을 동기식으로 업데이트하는 단계; 및
1차 복제본에 대한 업데이트들로 3차 복제본을 비동기식으로 업데이트하는 단계를 더 포함한다.
조한 10. 조항 9의 컴퓨터 구현 방법에 있어서, 3차 복제본을 비동기식으로 업데이트하는 단계는,
로거 플릿에서 업데이트들을 수신하는 단계;
3차 복제본에 적용될 수 있을 때까지 로거 플릿에서 업데이트들을 저장하는 단계; 및
제2 개수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 포함한다.
조항 11. 조항 8의 컴퓨터 구현 방법에 있어서, 3차 복제본을 생성하는 단계는,
적어도 하나의 객체 스토리지 서버로부터 볼륨의 데이터를 검색하는 단계;
제2 개수의 파티션들의 각 파티션에 대해,
복수의 추가 서버들 중 파티션을 저장하기 위한 서버를 선택하는 단계, 및
파티션이 선택된 서버에서 저장을 위한 선택된 서버로 전송되게 하는 단계; 및
제2 개수의 파티션들의 각 파티션에 대해, 파티션에 대한 위치 정보를 식별하는 매니페스트를 생성하는 단계를 더 포함한다.
조항 12. 조항 8의 컴퓨터 구현 방법에 있어서, 제2 개수의 파티션들을 복수의 추가 서버들에 걸쳐 분산시키는 단계는 제2 개수의 파티션들을 복수의 추가 서버들에 걸쳐 스트라이핑하는 단계를 포함한다.
조항 13. 조항 8의 컴퓨터 구현 방법에 있어서,
볼륨의 스냅샷을 생성할 것을 결정하는 단계; 및
제2 개수의 파티션들 각각이 스냅샷을 생성하기 위해 적어도 하나의 객체 스토리지 서버로 전송되게 하는 단계로서, 제2 개수의 파티션들 중 적어도 일부가 서로 병렬로 전송되는, 상기 전송되게 하는 단계를 더 포함한다.
조항 14. 조항 8의 컴퓨터 구현 방법에 있어서,
볼륨의 새로운 복제본을 생성할 것을 결정하는 단계; 및
제2 개수의 파티션들 각각이 새로운 복제본을 생성하기 위해 하나 이상의 제3 서버들로 전송되게 하는 단계로서, 제2 개수의 파티션들 중 적어도 일부가 서로 병렬로 제3 서버들로 전송되는, 상기 전송되게 하는 단계를 더 포함한다.
조항 15. 비일시적 컴퓨터 판독 매체로서, 컴퓨팅 시스템에 의해 실행 시, 컴퓨팅 시스템이,
컴퓨팅 시스템의 제1 스토리지 장치 세트에 볼륨의 1차 복제본을 저장하는 단계로서, 제1 스토리지 장치 세트는 1차 복제본의 수정을 통해 볼륨으로부터 사용자 시작 읽기들 또는 쓰기들을 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 상기 저장하는 단계; 및
볼륨의 2차 복제본을 생성하는 단계로서, 적어도,
볼륨의 데이터를 복수의 파티션들로 분할하는 단계, 및
복수의 파티션들을 컴퓨팅 시스템의 제2 스토리지 장치 세트에 걸쳐 분산시키는 단계로서, 제2 스토리지 장치 세트는 2차 복제본의 사용에 의해 컴퓨팅 시스템 내에서 볼륨의 듀플리케이션을 용이하게 하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되고, 복수의 파티션들의 수가 제1 스토리지 장치 세트의 수보다 큰, 상기 분산시키는 단계에 의해 상기 2차 복제본을 생성하는 단계를 포함하는 동작들을 수행하도록 하는 인스트럭션들을 저장한다.
조항 16. 조항 15의 비일시적 컴퓨터 판독 가능 매체에 있어서, 동작들은 1차 복제본에 대한 업데이트들로 2차 복제본을 비동기식으로 업데이트하는 단계를 더 포함한다.
조항 17. 조항 16의 비일시적 컴퓨터 판독 가능 매체에 있어서, 비동기식으로 2차 복제본을 업데이트하는 단계는,
로거 플릿에서 업데이트들을 수신하는 단계;
2차 복제본에 적용될 수 있을 때까지 로거 플릿에서 업데이트들을 저장하는 단계; 및
복수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 포함한다.
조항 18. 조항 15의 비일시적 컴퓨터 판독 가능 매체에 있어서, 2차 복제본을 생성하는 단계는,
적어도 하나의 객체 스토리지 서버로부터 볼륨의 데이터를 검색하는 단계;
복수의 파티션들의 각 파티션에 대해,
제2 스토리지 장치 세트 중 파티션을 저장하기 위해 스토리지 장치를 선택하는 단계,
파티션을 선택된 스토리지 장치로 라우팅하는 단계, 및
선택된 스토리지 장치의 컨테이터 파티션을 저장하는 단계; 및
복수의 파티션들의 각 파티션에 대해, 파티션이 저장되는 컨테이너를 식별하는 매니페스트를 생성하는 단계를 더 포함한다.
조항 19. 조항 15의 비일시적 컴퓨터 판독 가능 매체에 있어서, 복수의 파티션을 제2 스토리지 장치 세트에 걸쳐 분사시키는 단계는 복수의 파티션들을 제2 스토리지 장치 세트에 걸쳐 스트라이핑하는 단계를 포함한다.
조항 20. 조항 15의 비일시적 컴퓨터 판독 가능 매체에 있어서, 동작들은,
볼륨의 스냅샷을 생성할 것을 결정하는 단계로서, 스냅샷은 적어도 하나의 객체 스토리지 서버에 저장된 볼륨의 객체 표현인, 상기 결정하는 단계; 및
스냅샷을 생성하기 위해 복수의 파티션들 각각을 적어도 하나의 객체 스토리지 서버에 푸시하는 단계로서, 복수의 파티션들 중 적어도 일부는 적어도 하나의 객체 스토리지 서버에 병렬로 푸시되는, 상기 푸시하는 단계를 더 포함한다.
조항 21. 컴퓨팅 시스템에 있어서,
볼륨의 1차 복제본이 저장된 제1 서버 세트로서, 제1 서버 세트는 1차 복제본을 저장하는 제1 개수의 파티션들에 대응되는, 상기 제1 서버 세트;
제1 서버와 데이터 통신하는 제2 서버 세트로서, 제2 서버 세트는 1차 복제본과 동기식으로 업데이트들을 수신하는 볼륨의 2차 복제본이 저장되며, 제1 개수의 파티션들에 대응되는 제2 서버 세트는 2차 복제본을 저장하는, 상기 제2 서버 세트; 및
제1 서버 세트 및 제2 서버 세트 중 하나 또는 둘 다와 데이터 통신하는 복수의 추가 서버들로서, 복수의 추가 서버들은 1차 복제본과 비동기식으로 업데이트들을 수신하는 볼륨의 3차 복제본이 집합적으로 저장되고, 3차 복제본은 복수의 추가 서버들 사이에서 분산된 제2 개수의 파티션들로 저장되고, 제2 개수의 파티션들은 제1 개수의 파티션들보다 큰, 상기 복수의 추가 서버들을 포함하며,
제1 서버 세트 및 제2 서버 세트 중 하나 또는 둘 다는,
1차 및 2차 복제본들의 수정을 통해 볼륨에 대한 사용자 시작 쓰기들을 처리하고,
볼륨에 대한 사용자 시작 쓰기들로 3차 복제본의 업데이트를 가능하게 하는 컴퓨터 실행 가능 인스트럭션들로 구성되고;
볼륨의 백업을 생성하라는 요청을 수신하는 것에 응답하여, 복수의 추가 서버들은 3차 복제본의 사용에 의해 컴퓨팅 시스템 내에서 볼륨의 백업을 생성하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 22. 조항 21의 컴퓨팅 시스템에 있어서, 복수의 추가 서버들은 제2 개수의 파티션들 중 적어도 일부의 데이터를 백업을 저장하도록 구성된 적어도 하나의 다른 서버로 병렬로 전송함으로써 볼륨의 백업을 생성하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 23. 조항 21의 컴퓨팅 시스템에 있어서, 백업을 생성하기 위해, 복수의 추가 서버들은 제2 개수의 파티션들 중 지정된 파티션들을 객체 스토리지를 사용하여 지정된 파티션들을 저장하도록 구성된 하나 이상의 스토리지 서버들로 전송하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구현된다.
조항 24. 조항 23의 컴퓨팅 시스템에 있어서, 제1 서버 세트 및 제2 서버 세트 중 하나 또는 둘 다는 볼륨의 이전 백업의 생성 이후 변경된 볼륨의 임의의 볼록들을 나열하는 백업 맵을 생성하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되며, 복수의 추가 서버들은 백업 맵을 사용하여 지정된 파티션들을 식별하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 25. 조항 21의 컴퓨팅 시스템에 있어서,
사용자 백업 요청을 수신하고;
사용자 백업 요청을 복수의 추가 서버들로 전파하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 26. 조항 24의 컴퓨팅 시스템에 있어서, 복수의 추가 서버들은 사용자 백업 요청을 수신하는 것에 응답하여, 제2 개수의 파티션들 중 적어도 일부의 데이터를 백업을 저장하도록 구성된 적어도 하나의 다른 서버로 전송하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 27. 조항 24의 컴퓨팅 시스템에 있어서,
복수의 추가 서버들은 사용자 백업 요청을 수신하는 것에 응답하여, 3차 복제돈의 사본을 생성하되, 3차 복제본의 사본은 제3 서버 세트에 집합적으로 저장된 제2 개수의 파티션들을 사용하여 저장된 볼륨의 데이터를 갖는, 컴퓨터 실행 가능 인스트럭션들로 구성되며;
제3 서버 세트는 제2 개수의 파티션들 중 적어도 일부의 데이터를 백업을 저장하도록 구성된 적어도 하나의 다른 서버로 전송하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성된다.
조항 28. 컴퓨터 구현 방법에 있어서,
제1 서버 세트에 제1 개수의 파티션들을 사용하여 볼륨의 1차 복제본을 저장하는 단계;
제2 서버 세트에 제1 개수의 파티션들을 사용하여 볼륨의 2차 복제본을 저장하는 단계;
볼륨의 3차 복제본을 생성하는 단계로서, 적어도
제2 개수의 파티션들로 볼륨의 데이터를 분할하는 단계로서, 제2 개수의 파티션들은 제1 개수의 파티션들보다 큰, 상기 분할하는 단계, 및
제2 개수의 타피션들을 복수의 추가 서버들에 걸쳐 분산시키는 단계에 의해, 상기 3차 복제본을 생성하는 단계;
1차 및 2차 복제본들의 수정을 통해 볼륨에 대한 사용자 시작 쓰기들을 처리하는 단계;
볼륨에 대한 사용자 시작 쓰기들로 3차 복제본을 업데이트하는 단계;
볼륨의 백업을 생성하라는 사용자 백업 요청을 수신하는 단계;
사용자 백업 요청을 3차 복제본으로 전파하는 단계; 및
3차 복제본의 사용에 의해 볼륨의 백업을 생성하는 단계를 포함한다.
조항 29. 조항 28의 컴퓨터 구현 방법에 있어서, 백업을 생성하는 단계는 제2 개수의 파티션들 중 적어도 일부로부터 데이터를 병렬로 전송하는 단계를 포함한다.
조항 30. 조항 28의 컴퓨터 구현 방법에 있어서,
1차 복제본에서 사용자 백업 요청을 수신하는 단계;
1차 복제본으로부터 3차 복제본으로 사용자 백업 요청을 전파하는 단계; 및
3차 복제본에서 사용자 백업 요청을 수신하는 것에 응답하여 백업을 생성하는 단계를 더 포함한다.
조항 31. 조항 28의 컴퓨터 구현 방법에 있어서, 백업을 생성하는 단계는,
3차 복제본의 사본을 생성하는 단계로서, 3차 복제본의 사본은 제3 서버 세트에 집합적으로 저장된 제2 개수의 파티션들을 사용하여 저장된 볼륨의 데이터를 갖는, 상기 생성하는 단계; 및
3차 복제본의 사본의 제2 개수의 파티션들 중 적어도 일부의 데이터를 백업을 저장하도록 구성된 적어도 하나의 다른 서버로 전송하는 단계를 포함한다.
조항 32. 조항 31의 컴퓨터 구현 방법에 있어서,
1차 복제본에 대한 업데이트들을 수신하는 단계; 및
3차 복제본의 사본이 적어도 하나의 다른 서버로 데이터를 전송하는 동안 3차 복제본의 제2 개수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 더 포함한다.
조항 33. 조항 28의 컴퓨터 구현 방법에 있어서, 백업을 생성하는 단계는,
1차 복제본에 대한 업데이트들을 수신하는 단계;
백업이 3차 복제본으로부터 생성될 때까지 업데이트들을 저장하는 단계; 및
백업이 생성된 후, 제2 개수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 포함한다.
조항 34. 조항 33의 컴퓨터 구현 방법에 있어서,
1차 복제본에서 백업이 생성되었다는 확인 응답을 수신하는 단계; 및
확인 응답을 수신하는 것에 응답하여, 제2 개수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 더 포함한다.
조항 35. 비일시적 컴퓨터 판독 매체로서, 컴퓨팅 시스템에 의해 실행 시, 컴퓨팅 시스템이,
컴퓨팅 시스템의 제1 스토리지 장치 세트에 볼륨의 1차 복제본을 저장하는 단계;
볼륨의 2차 복제본을 생성하는 단계로서, 적어도,
볼륨의 데이터를 복수의 파티션들로 분할하는 단계, 및
복수의 파티션들을 컴퓨팅 시스템의 제2 스토리지 장치 세트에 걸쳐 분산시키는 단계로서, 복수의 파티션들의 수는 제1 스토리지 장치 세트의 수보다 큰, 상기 분산시키는 단계에 의해, 상기 2차 복제본을 생성하는 ㄷ단계;
1차 복제본들의 수정을 통해 볼륨에 대한 사용자 시작 쓰기들을 처리하는 단계;
볼륨에 대한 사용자 시작 쓰기들로 2차 복제본을 업데이트하는 단계;
볼륨의 백업을 생성하라는 사용자 백업 요청을 수신하는 단계;
사용자 백업 요청을 2차 복제본으로 전파하는 단계; 및
2차 복제본의 사용에 의해 컴퓨팅 시스템 내에서 볼륨의 백업을 생성하는 단계를 포함하는 동작들을 수행하도록 하는 인스트럭션들을 저장한다.
조항 36. 조항 35의 비일시적 컴퓨터 판독 가능 매체에 있어서, 동작들은 제2 스토리지 장치 세트 중 적어도 일부로부터 2차 복제본의 데이터를 병렬로 전송하는 단계를 더 포함한다.
조항 37. 조항 35의 비일시적 컴퓨터 판독 가능 매체에 있어서, 백업을 생성하기 위한 동작들은,
2차 복제본의 사본을 생성하는 단계로서, 2차 복제본의 사본은 제3 스토리지 장치 세트에 집합적으로 저장된 복수의 파티션들을 사용하여 저장된 볼륨의 데이터를 갖는, 상기 생성하는 단계; 및
2차 복제본의 사본의 복수의 파티션들 중 적어도 일부의 데이터를 백업을 저장하도록 구성된 적어도 하나의 다른 서버로 전송하는 단계를 더 포함한다.
조항 38. 청구항 37의 비일시적 판독 가능 매체에 있어서, 동작들은,
1차 복제본에 대한 업데이트들을 수신하는 단계; 및
2차 복제본의 사본이 적어도 하나의 다른 서버로 데이터를 전송하는 동안 2차 복제본의 복수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 더 포함한다.
조항 39. 조항 35의 비일시적 컴퓨터 판독 가능 매체에 있어서, 동작들은,
1차 복제본에 대한 업데이트들을 수신하는 단계;
백업이 2차 복제본으로부터 생성될 때까지 업데이트들을 저장하는 단계; 및
백업이 생성된 후, 복수의 파티션들 중 지정된 파티션들에 업데이트들을 연속으로 적용하는 단계를 더 포함한다.
조항 40. 조항 35의 비일시적 컴퓨터 판독 가능 매체에 있어서, 동작들은,
볼륨의 1차 복제본을 하나 이상의 블록들로 저장하는 단계;
적어도 하나의 객체 스토리지 서버에 볼륨의 백업을 하나 이상의 객체들로 저장하는 단계; 및
적어도 하나의 객체 스토리지 서버에 볼륨의 블록들을 대응되는 위치들과 매핑시키는 매니페스트를 생성하는 단계를 더 포함한다.
조항 41. 시스템에 있어서,
데이터 볼륨의 분산된 복제본을 구현하는 서버 컴퓨팅 장치 세트로서, 분산된 복제본은 서버 컴퓨팅 방치 세트 중 적어도 일부 사이에 분산된 파티션 세트를 포함하고, 분산된 복제본은 데이터 볼륨의 복제를 위해 지정되며 볼륨의 데이터에 대한 수정들을 처리하기 위해 지정된 추가 복제본과 구별되는, 상기 서버 컴퓨팅 장치 세트; 및
컴퓨터 실행 가능 인스트럭션들로 구성된 코디네이터 컴퓨팅 장치로서,
파티션 세트 중 하나의 파티션 내의 정보가 타겟 볼륨 세트에 복사되어야 함을 나타내는 하나 이상의 요청들을 수신하고;
파티션 내의 정보를 타겟 볼륨 세트로 복사하도록 요구된 복사 동작의 수가 임계값을 충족한다고 결정하고;
중간 듀플리케이트 파티션들을 생성하기 위해 서버 컴퓨팅 장치 세트 내에 파티션을 듀플리케이트하고;
중간 듀플리케이트 파티션들로부터 정보를 타겟 볼륨 세트로 복사하는 복사 동작 세트를 병렬로 시작하도록 하는, 상기 코디네이터 컴퓨팅 장치를 포함한다.
조항 42. 조항 41의 시스템에 있어서, 하나 이상의 요청들은 볼륨 전체가 타겟 볼륨 세트에 복사되어야 함을 나타내고, 중간 듀플리케이트 파티션들을 생성하기 위한 파티션의 듀플리케이션은 파티션들의 중간 듀플리케이트 세트 생성하기 위한 파티션 세트의 듀플리케이션을 더 포함한다.
조항 43. 조항 41의 시스템에 있어서, 임계값은 파티션을 이용하는 복사 동작들의 수를 완료하기 위해 예상되는 시간에 적어도 부분적으로 기초한다.
조항 44. 조항 41의 시스템에 있어서, 복사 동작 세트는 파티션으로부터 타겟 볼륨 세트로의 복사 동작을 더 포함한다.
조항 45. 조항 41의 시스템에 있어서, 복사 동작 세트는 중간 듀플리케이트 파티션들로부터 타겟 볼륨 세트의 제1 서브셋으로 정보를 복사하는 제1 복사 동작 세트에 대응되고, 컨트롤러 컴퓨팅 장치는 중간 듀플리케이트 파티션들로부터 타겟 볼륨 세트의 제2 서브셋으로 정보를 복사하는 제2 복사 동작 세트를 병렬로 시작하도록 하는 컴퓨터 실행 가능 인스트럭션들로 더 구성된다.
조항 46. 컴퓨터 구현 방법에 있어서,
데이터 볼륨의 분산된 복제본을 구현하는 단계로서, 분산된 복제본은 서버 컴퓨팅 방치 세트 중 적어도 일부 사이에 분산된 파티션 세트를 포함하고, 분산된 복제본은 데이터 볼륨의 복제를 위헤 지정되며 볼륨의 데이터에 대한 수정들을 처리하기 위해 지정된 추가 복제본과 구별되는, 상기 구현하는 단계;
파티션 세트 중 하나의 파티션 내의 정보가 네트워크 장치 세트 복사되어야 한다는 표시를 수신하는 단계;
중간 듀플리케이트 파티션들을 생성하기 위해 서버 컴퓨팅 장치 세트 내에 파티션을 듀플리케이트하는 단계;
중간 듀플리케이트 파티션들로부터 정보를 네트워크 장치 세트로 복사하는 복사 동작 세트를 병렬로 시작하는 단계를 포함한다.
조항 47. 조항 46의 컴퓨터 구현 벙법에 있어서, 표시는 서버 컴퓨팅 장치 세트의, 파티션을 호스팅하는, 제1 서버 컴퓨팅 장치에서 수신되며, 서버 컴퓨팅 장치 세트 내에서 파티션들을 듀플리케이트하는 단계는 제1 서버 컴퓨팅 장치에서, 서버 컴퓨팅 장치 세트 중 중간 듀플리케이트 파티션들 중 제1 중간 듀플리케이트 파티션을 생성하기 위한 제2 서버 컴퓨팅 장치를 선택하는 단계를 포함한다.
조항 48. 조항 47의 컴퓨터 구현 방법에 있어서, 제1 서버 컴퓨팅 장치에 의해, 복사 동작 세트 중 적어도 일부를 시작하도록 제2 서버 컴퓨팅 장치에 지시하는 단계를 더 포함한다.
조항 49. 조항 48의 컴퓨터 구현 방법에 있어서, 제2 서버 컴퓨팅 장치에서,
서버 컴퓨팅 장치들 중 중간 듀플리케이트 파티션들의 제2 중간 듀플리케이트 파티션을 생성하기 위한 제3 서버 컴퓨팅 장치를 선택하는 단계; 및
복사 동작 세트 중 적어도 일부를 시작하도록 제3 서버 컴퓨팅 장치에 지시하는 단계를 더 포함한다.
조항 50. 조항 48의 컴퓨터 구현 방법에 있어서, 제2 서버 컴퓨팅 장치에서,
제2 서버 컴퓨팅 장치에서 완료를 위해 미해결된 제1 중간 듀플리케이트 파티션에 관한 복사 동작의 수가 임계 레벨 미만으로 떨어졌음을 검출하는 단계;
제2 컴퓨팅 장치들로부터 제1 중간 듀플리케이트 파티션을 삭제하는 단계; 및
제1 중간 듀플리케이트 파티션이 제2 컴퓨팅 장치로부터 삭제되었음을 제1 서버 컴퓨팅 장치에 알리는 단계를 더 포함한다.
조항 51. 조항 46의 컴퓨터 구현 방법에 있어서, 표시는 컨트롤러 컴퓨팅 장치에서 수신되고, 파티션은 서버 컴퓨팅 장치 세트의 제1 서버 컴퓨팅 장치에서 호스팅되며, 서버 컴퓨팅 장치 세트 내에서 파티션을 듀플리케이트하는 단계는 컨트롤러 컴퓨팅 장치에서,
서버 컴퓨팅 장치들 세트 중 중간 듀플리케이트 파티션들의 제1 중간 듀플리케이트 파티션을 호스팅하기 위한 제2 서버 컴퓨팅 장치를 선택하는 단계; 및
제2 서버 컴퓨팅 장치에 대한 파티션을 적어도 부분적으로 듀플리케이트하는 제1 중간 듀플리케이트 파티션을 생성하도록 하는 인스트럭션들을 제1 서버 컴퓨팅 장치에 전송하는 단계를 포함한다.
조항 52. 조항 51의 컴퓨터 구현 방법에 있어서, 컨트롤러 컴퓨팅 장치에서,
제1 중간 듀플리케이트 파티션이 생성되다는 표시를 수신하는 단계;
서버 컴퓨팅 장치들 세트 중 중간 듀플리케이트 파티션들의 제2 중간 듀플리케이트 파티션을 호스팅하기 위한 제3 서버 컴퓨팅 장치를 선택하는 단계; 및
제3 서버 컴퓨팅 장치에 대한 제1 중간 듀플리케이트 파티션을 적어도 부분적으로 듀플리케이트하는 제2 중간 듀플리케이트 파티션을 생성하도록 하는 인스트럭션들을 제2 서버 컴퓨팅 장치에 전송하는 단계를 포함한다.
조항 53. 조항 51의 컴퓨터 구현 방법에 있어서, 컨트롤러 컴퓨팅 장치에서, 복사 동작 세트의 완료 후 제1 중간 듀플리케이트 파티션을 삭제하도록 제2 서버 컴퓨팅 장치에 지시하는 단계를 더 포함한다.
조항 54. 데이터 볼륨의 분산된 복제보을 구현하는 시스템에서 실행 가능한 인스트럭션들을 포함하는 비일시적 컴퓨터 판독 가능 매체로서, 분산된 복제본은 서버 컴퓨팅 장치 세트 중 적어도 일부 사이에 분사된 파티션 세트를 포함하고, 분삭된 복제본은 데이터 볼륨에 대한 수정들을 처리하기 위해 지정된 추가 복제본과 구분되며, 상기 인스트럭션들은 상기 시스템에 의해,
파티션 세트 중 하나의 파티션 내의 정보가 네트워크 장치 세트 복사되어야 한다는 표시를 수신하고;
중간 듀플리케이트 파티션들을 생성하기 위해 서버 컴퓨팅 장치 세트 내에 파티션을 듀플리케이트하고;
중간 듀플리케이트 파티션들로부터 정보를 네트워크 장치 세트로 복사하는 복사 동작 세트를 병렬로 시작하도록 실행 가능하다.
조항 55. 조항 54의 비일시적 컴퓨터 판독 가능 매체에 있어서, 인스트럭션들은 파티션 내의 정보를 네트워크 장치 세트로 복사하는데 필요한 복사 동작의 수가 임계값을 충족하는지를 결정하기 위해 시스템에 의해 추가로 실행 가능하다.
조항 56. 조항 55의 비일시적 컴퓨터 판독 가능 매체에 있어서, 임계값은 파티션을 활용하는 복사 동작들의 수를 완료하기 위해 예상되는 시간에 적어도 부분적으로 기초한다.
조항 57. 조항 54의 비일시적 컴퓨터 판독 가능 매체에 있어서, 복사 동작 세트는 파티션으로부터 타겟 볼륨 세트로의 복사 동작을 더 포함한다.
조항 58. 조항 54의 비일시적 컴퓨터 판독 가능 매체에 있어서, 인스트럭션들은 중앙 집중식 장치가 서버 컴퓨팅 장치 세트에 파티션을 듀플리케이트하도록 지시하거나 중간 듀플리케이트 파티션드을 생성하기 위해 서버 컴퓨팅 장치 세트 내의 파티션을 듀플리케이트하도록 서버 컴퓨팅 장치 세트 간에 피어 투 피어 통신을 시작하는 것 중 적어도 하나에 의해 적어도 부분적으로 서버 컴퓨팅 장치 세트 내에 파티션을 듀플리케이트하도록 시스템의 의해 실행 가능하다.
조항 59. 조항 54의 비일시적 컴퓨터 판독 가능 매체에 있어서, 인스트럭션들은 네트워크 장치 세트에 파티션을 복사하는 데 필요한 미해결 복사 동작들의 수가 임계 레벨 이하로 떨어짐을 검출하고, 중간 듀플리케이트 파티션들을 삭제하도록 시스템에 의해 더 실행 가능하다.
조항 60. 조항 59의 비일시적 컴퓨터 판독 가능 매체에 있어서, 인스트럭션들은 중간 듀플리케이트 파티션들의 삭제 전에, 향후 시간 기간 내에 발생할 것으로 예상되는 향후 파티션을 복사하라는 요청들의 수가 임계 레벨 이하로 떨어졌다고 결정하도록 시스템에 의해 더 실행 가능하다.
조항 61. 조항 59의 비일시적 컴퓨터 판독 가능 매체에 있어서, 임계 레벨은 중간 듀플리케이트 파티션들의 수에 적어도 부분적으로 기초하여 결정된다.
조항 62. 조항 54의 비일시적 컴퓨터 판독 가능 매체에 있어서, 파티션 내의 정보가 네트워크 장치 세트로 복사되어야 한다는 표시는 네트워크 장치 세트 중 적어도 하나로부터 정보를 읽으라는 요청을 포함한다.
상기 설명된 실시예들에 대해 많은 변형들 및 수정들이 이루어질 수 있으며, 그 요소들은 다른 허용 가능한 예들 중에 있는 것으로 이해되어야 한다는 것이 강조되어야 한다. 이러한 모든 수정들 및 변경들은 본 개시의 범위 내에 포함되고 다음의 청구 범위에 의해 보호되도록 의도된다.

Claims (15)

  1. 컴퓨팅 시스템에 있어서,
    볼륨의 1차 복제본의 제1 개수의 파티션들이 저장된 제1 서버 세트;
    상기 제1 서버 세트와 데이터 통신하는 제2 서버 세트로서, 상기 제2 서버 세트는 상기 1차 복제본과 동기식으로 업데이트들을 수신하는 상기 볼륨의 2차 복제본이 저장되며, 상기 제1 서버 세트 및 상기 제2 서버 세트 중 하나 또는 둘 다는 상기 볼륨으로부터 사용자 시작 읽기들 또는 쓰기들을 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 상기 제2 서버 세트; 및
    상기 제1 서버 세트 및 상기 제2 서버 세트 중 하나 또는 둘 다와 데이터 통신하는 복수의 추가 서버들로서, 상기 복수의 추가 서버들은 상기 1차 복제본과 비동기식으로 상기 업데이트들을 수신하는 상기 볼륨의 3차 복제본이 집합적으로 저장되고, 상기 3차 복제본은 상기 복수의 추가 서버들 사이에서 분산된 제2 개수의 파티션들로 저장되고, 상기 복수의 추가 서버들은 상기 3차 복제본의 사용에 의해 상기 볼륨의 복제를 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되고, 상기 제2 개수의 파티션들은 상기 제1 개수의 파티션들보다 큰, 상기 복수의 추가 서버들을 포함하는, 컴퓨팅 시스템.
  2. 제1항에 있어서,
    상기 제1 서버 세트 및 상기 제2 서버 세트 중 하나 또는 둘 다는,
    상기 1차 및 2차 복제본들의 수정을 통해 상기 볼륨에 대한 사용자 시작 쓰기들을 처리하고,
    상기 볼륨에 대한 사용자 시작 쓰기들로 상기 3차 복제본의 업데이트를 가능하게 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 컴퓨팅 시스템.
  3. 제2항에 있어서,
    상기 볼륨의 백업을 생성하라는 요청을 수신하는 것에 응답하여, 상기 복수의 추가 서버들은 상기 3차 복제본의 사용에 의해 상기 컴퓨팅 시스템 내에서 상기 볼륨의 상기 백업을 생성하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 컴퓨팅 시스템.
  4. 제3항에 있어서, 상기 백업을 생성하기 위해, 상기 복수의 추가 서버들은 상기 제2 개수의 파티션들 중 지정된 파티션들을 객체 스토리지를 사용하여 상기 지정된 파티션들을 저장하도록 구성된 하나 이상의 객체 스토리지 서버들로 전송하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 컴퓨팅 시스템.
  5. 제1항에 있어서, 상기 제1 서버 세트, 상기 제2 서버 세트 및 상기 복수의 추가 서버들은 블록 스토리지를 사용하여 상기 볼륨을 저장하도록 구성되며, 상기 3차 복제본의 상기 제2 개수의 파티션들 각각은 상기 볼륨의 적어도 하나의 블록을 나타내는, 컴퓨팅 시스템.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 복수의 추가 서버들은 상기 제2 개수의 파티션들 중 적어도 일부의 데이터를 병렬로 전송함으로써 상기 볼륨의 상기 복제를 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 컴퓨팅 시스템.
  7. 제1항에 있어서, 상기 제2 개수의 파티션들은 상기 복수의 추가 서버들에 걸쳐 스트라이프되어, 상기 볼륨의 제1 부분을 나타내는 제1 파티션 및 상기 제1 부분과 순차적인 상기 볼륨의 제2 부분을 나타내는 제2 파티션이 상기 복수의 추가 서버들 중 서로 다른 추가 서버들에 저장되도록 하는, 컴퓨팅 시스템.
  8. 제1항에 있어서,
    상기 1차 복제본 및 상기 2차 복제본 중 하나 또는 둘 다로부터 상기 업데이트들을 수신하고;
    상기 업데이트들을 상기 3차 복제본으로 비동기식으로 전파하도록 하는 컴퓨터 실행 가능 인스트럭션들에 의해 구성된 로거 플릿을 더 포함하는, 컴퓨팅 시스템.
  9. 제1항에 있어서,
    상기 컴퓨팅 시스템의 제어 평면을 구현하는 컴퓨팅 장치; 및
    상기 제1 개수의 파티션들을 사용하여 상기 볼륨의 새로운 사본을 저장하기 위해 상기 제어 평면에 의해 설정된 제3 서버 세트로서, 상기 제3 서버 세트의 상기 제1 개수의 파티션들 각각은 상기 3차 복제본을 사용하여 상기 볼륨의 새 사본을 생성하기 위해 상기 복수의 추가 서버들로부터 상기 제2 개수의 파티션들 중 특정 파티션들의 데이터를 검색하는, 상기 제3 서버 세트를 더 포함하는, 컴퓨팅 시스템.
  10. 컴퓨터 구현 방법에 있어서,
    제1 서버 세트에 제1 개수의 파티션들을 사용하여 볼륨의 1차 복제본을 저장하는 단계;
    제2 서버 세트에 상기 제1 개수의 파티션들을 사용하여 상기 볼륨의 2차 복제본을 저장하는 단계로서, 상기 제1 서버 세트 및 상기 제2 서버 세트 중 하나 또는 둘 다는 상기 1차 및 2차 복제본의 수정을 통해 상기 볼륨으로부터 사용자 시작 읽기들 또는 쓰기들을 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 단계;
    상기 볼륨의 3차 복제본을 생성하는 단계로서, 적어도
    제2 개수의 파티션들로 상기 볼륨의 데이터를 분할하는 단계로서, 상기 제2 개수의 파티션들은 상기 제1 개수의 파티션들보다 큰, 상기 분할하는 단계,
    상기 제2 개수의 파티션들을 복수의 추가 서버들에 걸쳐 분산시키는 단계에 의해 상기 3차 복제본을 생성하며,
    상기 복수의 추가 서버들은 상기 3차 복제본의 사용에 의해 상기 볼륨의 복제를 처리하도록 하는 컴퓨터 실행 가능 인스트럭션들로 구성되는, 상기 볼륨의 3차 복제본을 생성하는 단계;
    상기 1차 복제본 및 상기 2차 복제본을 동기식으로 업데이트하는 단계; 및
    상기 1차 복제본에 대한 업데이트들로 상기 3차 복제본을 비동기식으로 업데이트하는 단계를 포함하는, 컴퓨터 구현 방법.
  11. 제10항에 있어서, 상기 3차 복제본을 비동기식으로 업데이트하는 단계는,
    로거 플릿(logger fleet)에서 상기 업데이트들을 수신하는 단계;
    상기 3차 복제본에 적용될 수 있을 때까지 상기 로거 플릿에서 상기 업데이트들을 저장하는 단계; 및
    상기 제2 개수의 파티션들 중 지정된 파티션들에 상기 업데이트들을 연속으로 적용하는 단계를 포함하는, 컴퓨터 구현 방법.
  12. 제10항에 있어서, 상기 3차 복제본을 생성하는 단계는,
    적어도 하나의 객체 스토리지 서버로부터 상기 볼륨의 데이터를 검색하는 단계;
    상기 제2 개수의 파티션들의 각 파티션에 대해,
    상기 복수의 추가 서버들 중 상기 파티션을 저장하기 위한 서버를 선택하는 단계, 및
    상기 파티션이 선택된 서버에서의 저장을 위해 상기 선택된 서버로 전송되게 하는 단계; 및
    상기 제2 개수의 파티션들의 각 파티션에 대해, 상기 파티션에 대한 위치 정보를 식별하는 매니페스트를 생성하는 단계를 더 포함하는, 컴퓨터 구현 방법.
  13. 제10항에 있어서, 상기 제2 개수의 파티션들을 상기 복수의 추가 서버들에 걸쳐 분산시키는 단계는 상기 제2 개수의 파티션들을 상기 복수의 추가 서버들에 걸쳐 스트라이핑하는 단계를 포함하는, 컴퓨터 구현 방법.
  14. 제10항에 있어서,
    상기 볼륨의 스냅샷을 생성할 것을 결정하는 단계; 및
    상기 제2 개수의 파티션들 각각이 상기 스냅샷을 생성하기 위해 적어도 하나의 객체 스토리지 서버로 전송되게 하는 단계로서, 상기 제2 개수의 파티션들 중 적어도 일부가 서로 병렬로 전송되는, 상기 전송되게 하는 단계를 더 포함하는, 컴퓨터 구현 방법.
  15. 제10항에 있어서,
    상기 볼륨의 새로운 복제본을 생성할 것을 결정하는 단계; 및
    상기 제2 개수의 파티션들 각각이 상기 새로운 복제본을 생성하기 위해 하나 이상의 제3 서버들로 전송되게 하는 단계로서, 상기 제2 개수의 파티션들 중 적어도 일부가 서로 병렬로 상기 제3 서버들로 전송되는, 상기 전송되게 하는 단계를 더 포함하는, 컴퓨터 구현 방법.
KR1020207033888A 2018-04-30 2019-04-19 블록 스토리지 시스템들을 위한 분산된 복제본 KR102547126B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US15/967,023 US10768850B2 (en) 2018-04-30 2018-04-30 Distributed replica for block storage systems
US15/967,025 US10459655B1 (en) 2018-04-30 2018-04-30 Rapid volume backup generation from distributed replica
US15/967,025 2018-04-30
US15/967,023 2018-04-30
US15/967,284 2018-04-30
US15/967,284 US11023157B2 (en) 2018-04-30 2018-04-30 Intermediary duplication to facilitate copy requests in distributed storage systems
PCT/US2019/028320 WO2019212768A1 (en) 2018-04-30 2019-04-19 Distributed replica for block storage systems

Publications (2)

Publication Number Publication Date
KR20210003217A KR20210003217A (ko) 2021-01-11
KR102547126B1 true KR102547126B1 (ko) 2023-06-23

Family

ID=66530441

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020207033888A KR102547126B1 (ko) 2018-04-30 2019-04-19 블록 스토리지 시스템들을 위한 분산된 복제본

Country Status (5)

Country Link
EP (1) EP3788466A1 (ko)
JP (1) JP7171757B2 (ko)
KR (1) KR102547126B1 (ko)
AU (1) AU2019262799B2 (ko)
WO (1) WO2019212768A1 (ko)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10452296B1 (en) 2018-03-23 2019-10-22 Amazon Technologies, Inc. Accelerated volumes
US10459655B1 (en) 2018-04-30 2019-10-29 Amazon Technologies, Inc. Rapid volume backup generation from distributed replica
US11343314B1 (en) 2018-04-30 2022-05-24 Amazon Technologies, Inc. Stream-based logging for distributed storage systems
US11023157B2 (en) 2018-04-30 2021-06-01 Amazon Technologies, Inc. Intermediary duplication to facilitate copy requests in distributed storage systems
US10956442B1 (en) 2018-07-30 2021-03-23 Amazon Technologies, Inc. Dedicated source volume pool for accelerated creation of block data volumes from object data snapshots
US10931750B1 (en) 2018-07-30 2021-02-23 Amazon Technologies, Inc. Selection from dedicated source volume pool for accelerated creation of block data volumes
US11068192B1 (en) 2019-03-26 2021-07-20 Amazon Technologies, Inc. Utilizing mutiple snapshot sources for creating new copy of volume in a networked environment wherein additional snapshot sources are reserved with lower performance levels than a primary snapshot source
US10983719B1 (en) 2019-03-28 2021-04-20 Amazon Technologies, Inc. Replica pools to support volume replication in distributed storage systems
CN111273859B (zh) * 2020-01-14 2023-09-15 北京百度网讯科技有限公司 分发模式下复制组成员的变更方法、装置、设备和介质
CN111880740A (zh) * 2020-07-29 2020-11-03 平安科技（深圳）有限公司 数据处理方法、装置、计算机系统及可读存储介质
US11755590B2 (en) 2020-11-04 2023-09-12 Netapp, Inc. Data connector component for implementing integrity checking, anomaly detection, and file system metadata analysis
EP3995964B1 (en) * 2020-11-04 2023-09-20 NetApp, Inc. Data connector component for implementing integrity checking, anomaly detection, and file system metadata analysis
CN114579039B (zh) * 2020-12-02 2024-02-02 北京金山云网络技术有限公司 一种表格副本的扩展方法、系统、装置及电子设备

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5434994A (en) * 1994-05-23 1995-07-18 International Business Machines Corporation System and method for maintaining replicated data coherency in a data processing system
US8447938B2 (en) * 2008-01-04 2013-05-21 International Business Machines Corporation Backing up a deduplicated filesystem to disjoint media
US8261286B1 (en) 2008-06-18 2012-09-04 Amazon Technologies, Inc. Fast sequential message store
JP6035992B2 (ja) * 2012-08-16 2016-11-30 日本電気株式会社 情報処理システム、データバックアップ方法、データバックアッププログラム
JP2014157397A (ja) * 2013-02-14 2014-08-28 Nec Corp 情報処理システム、情報処理装置、データバックアップ方法、及びデータ分散送信用制御プログラム
JP2014186364A (ja) * 2013-03-21 2014-10-02 Kddi Corp 分散システム
JP2015005037A (ja) * 2013-06-19 2015-01-08 富士通株式会社 情報処理装置、情報処理装置の制御プログラム、および情報処理装置の制御方法
US9720620B1 (en) * 2014-03-11 2017-08-01 Amazon Technologies, Inc. Efficient data volume replication for block-based storage
US9600203B2 (en) * 2014-03-11 2017-03-21 Amazon Technologies, Inc. Reducing data volume durability state for block-based storage
WO2017028885A1 (en) * 2015-08-14 2017-02-23 Hewlett-Packard Development Company, L.P. Data replication in memory systems.

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
미국공개특허 제2017-0329528호(2017.11.16.) 1부.*
미국등록특허 제5434994호(1995.07.18.) 1부.*
미국등록특허 제7739233호(2010.06.15.) 1부.*
한국공개특허 제10-2010-0099231호(2010.09.10.) 1부.*

Also Published As

Publication number Publication date
JP2021521551A (ja) 2021-08-26
AU2019262799A1 (en) 2020-11-19
EP3788466A1 (en) 2021-03-10
WO2019212768A1 (en) 2019-11-07
CN112470112A (zh) 2021-03-09
AU2019262799B2 (en) 2021-12-16
KR20210003217A (ko) 2021-01-11
JP7171757B2 (ja) 2022-11-15

Similar Documents

Publication Publication Date Title
KR102547126B1 (ko) 블록 스토리지 시스템들을 위한 분산된 복제본
US11182095B2 (en) Rapid volume backup generation from distributed replica
US10768850B2 (en) Distributed replica for block storage systems
US11023157B2 (en) Intermediary duplication to facilitate copy requests in distributed storage systems
US10983719B1 (en) Replica pools to support volume replication in distributed storage systems
US10896104B2 (en) Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, using ping monitoring of target virtual machines
US11836155B2 (en) File system operation handling during cutover and steady state
US20220317882A1 (en) Methods and systems to interface between a multi-site distributed storage system and an external mediator to efficiently process events related to continuity
US11262933B2 (en) Sharing memory resources between asynchronous replication workloads
Mundkur et al. Disco: a computing platform for large-scale data analytics
US11567899B2 (en) Managing dependent delete operations among data stores
US20210165768A1 (en) Replication Barriers for Dependent Data Transfers between Data Stores
US11343314B1 (en) Stream-based logging for distributed storage systems
US11733874B2 (en) Managing replication journal in a distributed replication system
CN112470112B (zh) 块存储系统的分布式副本
US11966294B2 (en) Journal barrier consistency determination
US11537312B2 (en) Maintaining replication consistency during distribution instance changes
US20230236936A1 (en) Automatic backup distribution for clustered databases

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant