일 실시예에 따르면, 데이터를 스트리밍하기 위한 분산 저장 시스템은 컨트롤러, 제1 컴퓨터 및 제2 컴퓨터, 제1 및 제2 스위치들과 저장 장치를 포함할 수 있다. 제1 컴퓨터는 국지적 파일 시스템을 포함할 수 있고 국지적 파일 시스템을 사용해 자산 파일들을 제1 저장 장치에 저장할 수 있다. 또한, 제1 컴퓨터는 프로세스를 이용해, 자산 파일이 제1 저장 장치에 저장되는 경계들에 관한 정보를 포함하는 블록 맵(block map)을 생성할 수 있다. 블록 맵은 자산 파일 각각을 위해 생성될 수 있다.
다른 실시예에 따르면, 계층화된 캐싱 시스템은 디지털 자산들을 스트리밍하는데 이용될 수 있다. 그러한 시스템의 예시적 구현은 자산을 저장하는 제3 계층 캐시 메모리 및 제3 계층 캐시에 연결되어 있는 복수개 비디오 펌프들을 포함한다. 각각의 비디오 펌프는 제3 계층 캐시 메모리로부터 자산의 사본을 수신하고 하나 이상의 스트림들을 방출하는 제2 계층 캐시 메모리 및 제2 계층 캐시 메모리로부터 자산의 사본을 수신하고 복수개 스트림들을 방출하는 제1 계층 캐시 메모리를 포함할 수 있다. 본 시스템은 복수개 비디오 펌프들로부터, 자산을 스트리밍하기 위한 비디오 펌프를 선택하는 자원 컨트롤러도 포함할 수 있다.
도 1은 데이터를 스트리밍할 수 있는 분산 저장 시스템의 실시예를 예시한다. 도시된 바와 같이, 본 시스템은 컨트롤러(10), 제1 컴퓨터(12) 및 제2 컴퓨터(14), 제1 및 제2 스위치들(16 및 18)과 저장 장치(20)를 포함할 수 있다. 제1 컴퓨터(12)는, 자산 파일들을 제1 저장 장치(20)의 국지적 파일 시스템에 저장하는데 사용될 수 있는 국지적 파일 시스템(12B)을 포함할 수 있다. 또한, 제1 컴퓨터(12)는 프로세스(12A)를 이용해 각각의 자산 파일을 위한 블록 맵을 생성할 수도 있다. 블록 맵은, 자산 파일이 제1 저장 장치(20)에 저장되는 경계들에 관한 정보를 포함할 수 있다.
프로세스(12A)는 블록 맵의 사본(copy)을 제2 컴퓨터(14)에 연결되어 있는 제2 저장 장치(14A)에 저장할 수 있다. 도시된 바와 같이, 제2 컴퓨터(14)는 제1 저장 장치(20)에도 연결될 수 있다.
또한, 본 시스템은, 제2 컴퓨터(14)가 저장 장치(14A)에 저장된 블록 맵들의 사본들을 사용해 제1 저장 장치(20)의 자산 파일들에 액세스하는 것을 가능하게 하는 가상 파일 시스템(14B)도 포함할 수 있다.
블록 배치 알고리즘은 제1 컴퓨터(12)의 국지적 파일 시스템에 의해 이용될 수 있고, 제1 컴퓨터가 자산 파일을 저장할 때, 다수의 국지적 파일 시스템 블록들을 인접하게 기입할 수 있다. 또한, 스위치(18)는 제1 컴퓨터(12), 제2 컴퓨터(14), 및 저장 장치(20) 사이에서 동시적인 논-블로킹(non-blocking) 액세스를 제공할 수 있다. 프로세스(12A)는 자산 파일(들)의 위치들에 대한 포인터들을 포함하는 (다음에서 논의되는) "힌트 파일(hint file)"을 생성할 수 있다.
제1 저장 장치에 저장된 제1 파일로부터 데이터를 판독하기 위한 방법은 블록 맵을 제2 파일에 저장하는 단계를 포함하는데, 여기에서, 블록 맵은 논리적 블록 어드레스들의 리스트를 포함할 수 있고 리스트의 논리적 블록 어드레스 각각은 제1 파일에 데이터를 저장하는데 사용되는 섹터를 식별할 수 있다. 또한, 이 방법은 제1 파일과 연관된 가상 파일로부터 데이터를 판독하기 위해 시스템 호출을 발행하는 단계, 데이터와 연관된 논리적 블록 어드레스를 검색하는 단계, 및 연관된 논리적 블록 어드레스를 사용해 제1 저장 장치로부터 데이터를 판독하는 단계도 포함할 수 있다.
예시적 시스템의 다른 양태는 디지털 자산들을 스트리밍하기 위한 계층화된 캐싱 시스템에 관한 것이다. 그러한 시스템의 예시적 실시예는 자산을 저장하는 제3 계층 캐시 메모리를 포함할 수 있다. 이것은, 예를 들어, 도 1의 저장 장치(20)일 수 있다. 또한, 예시적 시스템은 제3 계층 캐시 메모리에 연결되어 있는 (제2 컴퓨터(14)와 같은) 하나 이상의 비디오 펌프들을 더 포함할 수도 있다. 여기에서, 비디오 펌프는 제3 계층 캐시 메모리로부터 자산의 사본을 수신하고 하나 이상의 스트림들을 방출하는 제2 계층 캐시 메모리(14A;제2 저장 장치), 제2 계층 캐시 메모리로부터 자산의 사본을 수신하고 복수개 스트림들을 방출하는 제1 계층 캐시 메모리(14C), 및 복수개 비디오 펌프들로부터, 자산을 스트리밍하기 위한 비디오 펌프를 선택하는 (컨트롤러(10)와 같은) 자원 컨트롤러를 포함할 수 있다.
분산 저장 아키텍처
도 1A는 확장 가능한 비디오-서버 복합체의 예시적 실시예를 묘사한다. 그러한 복합체는 자원 컨트롤러(10), 그들 중 하나 이상이 하나 이상의 파일 시스템들을 관리할 수 있는 다수의 컨텐츠 기입기들(12;content writers), 및 다수의 비디오 펌프들(14)을 포함할 수 있다. 부품들 중 일부 또는 전부는 이더넷(Ethernet) 및 파이버 채널 스위치들(16 및 18)을 통해 상호 접속될 수 있다. 파이버 채널 스위치들(18)은 비디오 펌프들(14), 컨텐츠 기입기들(12) 및 저장 어레이들(20) 사이에서 동시적인 논-블로킹 액세스를 제공할 수 있다.
컨텐츠 기입기(12)는 외부의 파이버 채널 저장 어레이들(20)로부터의 하나 이상의 파일 시스템 볼륨들을 관리한다. 스토리지(20)는 컨텐츠 기입기(12)에 국지적 파일 시스템으로서 탑재될 수 있다. 본 시스템은, 복합체의 다른 컴포넌트가 파일 시스템을 직접적으로 탑재하지 않도록 구성될 수도 있지만, 본 아키텍처는, 마치 그것이 각각의 비디오 펌프에 국지적으로 탑재된 것처럼, 비디오 펌프들(14)이 스토리지(20)로부터 스트리밍하는 것을 가능하게 한다. 파일 시스템들 중 하나 이상은 RAID 저장 어레이에 상주하는 단일 LUN(Logical Unit Number)을 포함할 수 있다.
수집(ingest) 또는 자산 로딩이 컨텐츠 기입기들(12)에 의해 수행될 수 있다. 수집되는 자산들은 컨텐츠 기입기의 국지적 파일 시스템에 기입될 수 있다. 자원 컨트롤러(10)는, 자산들이 저장 어레이들에 걸쳐 균일하게 그리고 무작위로 로딩된다는 것을 보장하면서, 파일 시스템들에 걸친 자산들의 분산을 유도할 수 있다.
복합체에서의 컨텐츠 기입기들(12)의 수(c)는 요구되는 총 수집 용량(total ingest capacity)에 의해 판정될 수 있다. 각각의 컨텐츠 기입기가 고정된 최대 수집 용량을 가지므로, c는 단순히 각 컨텐츠 기입기의 용량으로 나누어진 복합체의 소정의 총 수집 용량이다.
비디오 펌프들(14)의 수(v)는 복합체로부터 서빙될 스트림들의 수에 의해 판정될 수 있고, 단순히 각 비디오 펌프의 용량으로 나누어진 소정 스트림들의 총 수이다.
저장 어레이들(20)의 수(s)는 (1) 최대 저장 용량 요구 사항들, (2) 복합체의 고유한 또는 캐싱되지 않는 스트리밍 요구 사항들 및/또는 (3) 각각의 어레이로부터 이용 가능한 대역폭에 의해 판정될 수 있다. 통계적 기술들을 사용하여, 높은 확률을 가지고, 임의의 소정 시점에서 최대로 로딩된 어레이로 떨어질 부하의 최대 백분율을 판정할 수도 있다.
블록 맵 캐싱
공유된 저장 아키텍처는, 비디오 펌프들(14)이 컨텐츠 기입기들의 국지적 파일 시스템들로부터 스트리밍하는 것을 가능하게 한다. 그것은, 컨텐츠 기입기들(12)이 자산 데이터 블록들의 위치들을 비디오 펌프들(14)에 노출하는 것을 가능하게 하는 블록 맵(bmap) 캐싱 메커니즘을 사용해 이를 수행한다. 그 다음, 비디오 펌프들(14)은 파이버 채널 스위치(18)를 통해 직접적으로 데이터 블록들을 판독하여 그들로부터 스트리밍할 수 있다. 시스템의 하나 이상의 자산을 위한 블록 맵들이, 자산의 수명 동안, 하나 이상의 비디오 펌프상의 국지적 파일 시스템에 캐싱된다. 각각의 비디오 펌프에서 실행 중인 컨텐츠 싱커 프로세스(content syncher process)는, 블록 맵 캐시가 컨텐츠 기입기들(12)상의 자산들의 상태와 동일하게 유지된다는 것을 보장한다. 자산들을 위한 블록 맵들 및 힌트 파일들을 비디오 펌프(들)에 지속적으로 캐싱하는 것에 의해, 컨텐츠 기입기에서 장애가 발생하는 경우에도 스트리밍이 계속되게 할 수 있다.
BCFS(Block map Cache File System)라고 하는 새로운 파일 시스템층이 스트리밍하는 동안 애플리케이션들에 투명하게 블록 맵-대-자산-데이터 룩업(block map-to-asset-data lookup)을 구현한다. 자산들 이외에, 힌트 파일들이 스트리밍을 위해 요구된다. 힌트 파일들은 수집 프로세스 동안 컨텐츠 기입기들의 국지적 스토리지에서 발생될 수 있다. 힌트 파일들은 bmap들과 함께 비디오 펌프들(14)로 전파되어 마찬가지로 자산의 수명 동안 국지적 파일 시스템에 저장될 수 있다. 다른 방법으로, 힌트 파일들을 위한 블록 맵들이 비디오 펌프들(14)로 전파될 수도 있는데, 이는, 파일들이 자산들과 유사한 방식으로 액세스될 수 있게 하고 좀더 적 은 국지적 스토리지 및 네트워크 자원들을 요하지만, 자산 수집 동안 힌트 파일 데이터가 필요하다면, 추가적인 지연들을 도입한다.
BCFS(
Block
Map
Cache
File
System
)
BCFS는, 사용자 레벨 애플리케이션들이 국지적으로 탑재되었다면, 그것들로 하여금 계층 3 스토리지의 자산들을 개방하여 그 자산들로부터 스트리밍할 수 있게 하는, 사용자 레벨 애플리케이션들에 투명한 인터페이스를 제시하는 얇은 파일 시스템층일 수 있다.
BCFS는 파일 스토리지가 아닌데, 이것은, 그것이 임의의 온-디스크(on-disk) 데이터 구조들을 구현하지 않는다는 것을 의미한다. 그것은 하위의 UFS 파일 시스템을 사용해 모든 자산 블록 맵들 및 힌트 파일들을 관철할 수 있다.
BCFS는 적층 가능한 VNODE 인터페이스의 개념에 기초할 수 있다(E. Zadok 등의 "Extending file Systems Using Stackable Templates", Proc. 1999 USENIX Annual Technical Conf., June 1999 참고). 가상 노드(virtual node) 또는 VNODE는 파일 시스템 이름 공간에 등장하는 개방 파일들 또는 디렉토리들과 같은 엔티티들을 표현하기 위해 Unix 커널내에서 사용되는 데이터 구조일 수 있다. VNODE는 하위 오퍼레이팅 시스템의 물리적 특징들과 무관할 수 있다. VNODE 인터페이스는, 좀더 높은 레벨의 커널 모듈들이 VNODE들에 대한 연산들을 수행하기 위한 균일한 방법을 제공한다. 가상 파일 시스템(VFS)은 VNODE 인터페이스를 포함할 수 있는 공통적인 파일 시스템 코드를 구현한다.
VNODE 인터페이스는 적층(stacking)으로서 공지된 개념을 지원하는데, 여기 에서, 파일 시스템 기능들은, 하나의 VNODE 인터페이스 구현이 또 다른 것을 호출하게 하는 것에 의해 모듈화될 수 있다. VNODE 적층은, 다수의 파일 시스템 구현들이 존재할 수 있게 하고 서로 시퀀스로 호출할 수 있게 한다. 적층 가능한 VNODE 구현에서, 스택의 소정 레벨에서의 연산은 스택의 다음으로 낮은 레벨에서의 동일한 연산을 호출할 수 있다.
도 2는, 사용자 read() 호출이, BCFS에 의해 핸들링될 수 있는 VFS 판독 동작으로 변환될 수 있는 방법을 나타낸다. 단계들(1-3)은 VNODE층으로 전달되어 bcfs로 발행될 수 있는 판독을 발행하는 사용자 프로세스를 표현한다. bcfs_read는, 단계들(4-6)에서, VNODE층을 통해 회귀적 판독을 발행하는 것에 의해 자산의 bmap 파일로부터 bmap을 판독한다. 그 다음, BCFS는 bmap를 해석하여 계층 3 저장 장치상의 소정 데이터 블록들의 위치를 판정한다. 단계 7은 변환된 판독을 직접적으로 계층 3 스토리지로 발행하고 결과를 리턴하는 bcfs를 표현한다.
BCFS를 설계함에 있어서의 몇가지 고려들은 다음과 같다:
1. 안정 코드로의 변화들을 최소화하기. 새로운 파일 시스템층을 도입하는 것에 의해, 스트리밍 애플리케이션들은 공유되는 힌트 파일들 및 자산들에, 변경없이, 액세스할 수 있다.
2. 캐싱된 블록 맵들 및 힌트 파일들을 위해 영구적인 스토리지 제공하기. 이것은 블록 맵 캐시의 RAM 요구 사항들을 감소시킬 수 있고, 블록 맵들이 시스템 재부팅들을 통해 영속할 수 있게 하며, 자산 블록 맵들이, 계층 3 스토리지 상의 자산들의 수명 동안, 비디오 펌프들(14)에서 보존될 수 있게 한다.
3. 비디오 펌프들(14)과 컨텐츠 기입기들(12) 사이의 버퍼 캐시 일관성. 미가공 메타데이터 대신 블록 맵들을 사용해, 자산들로의 공유되는 액세스를 제공하는 것을 통해, 모드들이 공유되는 경우이기만 하면 발생할 수 있는 캐시 일관성 쟁점들을 방지할 수 있다.
4. 비디오 펌프들(14)과 컨텐츠 기입기들(12) 사이의 타이밍 요구 사항들. 힌트 파일들에 대한 변화들은, 능동적으로 수집 중인 컨텐츠로부터 스트리밍할 때, 컨텐츠 기입기로부터 비디오 펌프로 재빨리 전달되어야 한다. 힌트 파일 데이터가 디스크와 동기하기를 대기한 다음 비디오 펌프에서 그것을 판독하는 것은 허용 불가능한 지연들을 도입할 것이다.
FFS 파일 시스템은, 공유되는 파일 시스템이 아니도록 구현될 수도 있는데: 예를 들어, 탑재된 스토리지를 판독하거나 기입하는 단일 서버가 존재한다고 가정할 수도 있다. 이 가정에 기초해, FFS 파일 시스템은 INODE 및 간접적인 블록 메타데이터를 그것의 버퍼 캐시에 캐싱할 수도 있다. 파일 시스템 메타데이터가 자산 파일들을 기입하거나 삭제하는 결과로서 변화할 때, 이 캐시를 다른 서버들과 동기시키기 위한 메커니즘들은 존재하지 않는다. 자산의 메타데이터가 서버 A에 캐싱되고 서버 B가 자산에 기입함으로써 메타데이터를 변경한다면, 서버 A는 새로운 메타데이터에 관해 알지 못할 것이다. FFS에 버퍼 캐시 동기화를 추가하는 것이 개념적으로 가능하기는 하지만, 그렇게 하는 것은 파일 시스템 컴포넌트를 복잡하게 할 것이고 파일 시스템 컴포넌트를 불안정하게 할 수 있다. 블록 맵들을 전파하는 것은, 블록 맵들의 현재 상태를 모든 서버들에 공개함으로써 캐시 일관성 문제를 방지한다. 이 방식은, bmap 통신의 오버헤드로 인해, 공유되는 범용 파일 시스템에서는 제대로 동작하지 않을 수도 있다는 것에 주의한다. 그러나, 다음에 의해: (1) 매 자산당 하나의 기입기, (2) 한번에 기입되고 수차례 스트리밍되는 자산들, 및 (3) 컴팩트한 bmap 표현을 초래하는 거대한 자산 블록 사이즈에 의해 특징지워지는 비디오 펌프 복합체에서는, 이 접근 방법이 상당히 효율적이다.
VFS 스택은 기존 저층에 BCFS층을 탑재하는 것에 의해 확립될 수 있다. 예를 들어, mount -t bcfs /localfs/assets/cache는 탑재 포인트 "assets/cache"에 블록 캐시 파일 시스템 /localfs를 탑재한다. 이제 /assets/cache의 파일들로의 모든 액세스들은 BCFS 모듈을 통해 하위의 국지적 파일 시스템으로 전달되는데, 하위의 국지적 파일 시스템은 블록 맵 및 힌트 파일들의 사본들을 포함한다. 블록 맵 파일들은 계층 3 스토리지의 원격 파일들을 위한 프럭시들로서 동작한다. 컨텐츠 싱커 프로세스는, 국지적 블록 맵 파일들이 계층 3 스토리지의 실제 자산 파일들의 이름들과 동일한 (또는 선택적으로 ".bmap" 확장자가 첨부된) 이름들을 갖게 한다.
일 VFS 구현의 일례로서, 이러한 예시적 VFS 구현은 국지적 파일들이 아니라 원격 스토리지 상의 자산들의 목록을 나타낼 것이다. 이것이 공유되는 범용 파일 시스템을 위한 중요한 사양일 수도 있지만, bcfs는, 최소 오버헤드로써, 자산들로의 공유되는 고성능 액세스를 제공하는 문제를 구체적으로 해결하도록 설계되었다. 분산 디렉토리 서비스들을 제공하는 것은, bmap 파일들(또는 관련 구조)이, 공유되는 스토리지 상의 디렉토리 엔트리들 및 INODE들을 설명하는 메타데이터에 액세스 하기에 충분한 정보를 가질 것을 요구할 수 있다. 이 정보를 비디오 펌프들(14)로 전파하는 것은 캐시 일관성을 보존하고 로킹하기 위한 준비들을 요구할 것이고, 이것은, 추가적인 오버헤드를 부가할 것이다. 좀더 중요하게, 이러한 메타데이터 액세스들은 저장 어레이(20)에 의한 서비스를 위한 스트리밍 액세스들과 경쟁할 것이므로, 스트리밍 성능을 열화시킬 수 있다. 간단한 ls 명령어(ls command)로부터 발생되는 판독들의 버스트가 스트림 전달의 손상을 초래할 수 있다. 설계된 바와 같이, 스트리밍 동안 VP에 의해 저장 어레이(20)에 대해 형성되는 유일한 요청들은, 임의의 메타데이터에 대해서가 아니라, 스트림 데이터에 대해서이다.
블록 맵 정의
이 섹션은, 실시예에서, 블록 맵 또는 bmap이라는 용어에 의해 함축될 수 있는 것을 설명한다. 도 3에 도시된 바와 같이, 디스크에 저장된 자산은 블록이라고 하는 인접 섹터들의 시퀀스를 포함할 수 있다. 파일 시스템의 블록 배치 정책에 따라, 블록들은 인접하게 배치될 수 있거나 디스크의 어드레스 공간을 가로질러 소정 방식으로 분산될 수 있다.
블록은 그것의 LBA(logical block address) 및 길이에 의해 완전하게 특정될 수 있다. 그에 따라, 블록 맵은, LBA 및 길이가 블록을 식별하는데 사용될 수 있는 블록들의 시퀀스이다.
디스크 드라이브들로부터의 높은 처리율 레벨들을 실현하기 위해, 블록들은 거대 데이터 전송에 대한 (블록의 시작으로 디스크 헤드를 이동시키는) 탐색 + (데이터가 디스크 헤드 아래에 위치할 때까지 플래터가 회전하기를 대기하는) 지연의 비용을 상각하도록 커야 한다. 현 세대의 파이버 채널 디스크 드라이브들의 경우, 512K 내지 2MB 범위의 블록 사이즈들이 인접한 데이터에 대한 드라이브들의 지속 가능한 처리율의 50%-80%를 제공할 수 있다.
하나의 32-비트 LBA 및 16-비트 길이면 파이버 채널 장치의 블록을 설명하기에 충분하므로, 자산의 블록 맵 사이즈에 대한 자산 사이즈의 비는 기껏해야 (블록 사이즈/6):1과 동일할 수 있다. 블록들이 파일 시스템에 의해 인접하게 배치되는 결과로서, 블록 맵의 사이즈는 추가적으로 감소될 수 있다.
1MB 인접 블록 정렬에 기초해, 자산 사이즈와 블록 맵 사이즈 사이의 비는 167,000:1일 것이고, 블록들을 가능한 인접하게 배치하는 FFS로 인해, 통상적으로 훨씬 더 작을 것이다. 1GB 자산을 위한 블록 맵은, 예를 들어, 기껏해야 6KB일 것이다.
파일 시스템 블록 사이즈는 저장 어레이에 의해 판정되는 것이 아니고; 오히려, 비디오 펌프에서 실행 중인 파일 시스템에 의해 판정될 수 있다. 저장 어레이는 LBA들의 맥락에서 동작하는데, 여기에서, LBA에 의해 참조되는 각각의 블록은 통상적으로 512 바이트이다(장치의 "섹터 사이즈"). 파일 시스템은 데이터 블록들을 파일 시스템 블록 사이즈의 단위들로 어드레싱한다. FFS를 위한 최대의 파일 시스템 블록 사이즈는 64K이다. 이것이 처리율 목표들을 실현하기에 충분할 정도로 크지 않으므로, 파일 시스템의 블록 배치 알고리즘은, 파일 시스템 블록들이 자산 블록 사이즈의 배수들로 인접하게 배치될 것을 보장하도록 변경될 수 있다. 단편화(fragmentation)에 의한 쟁점들을 방지하기 위해, 단일 자산 블록 사이즈가 소 정 파일 시스템의 모든 자산들을 위해 사용될 수도 있다.
블록 맵 파일 포맷
이 섹션은 bmap 파일을 위한 샘플 포맷을 설명한다. bmap 파일은 블록 기술자들(block descriptors)의 리스트가 수반되는 헤더를 포함할 수도 있다.
헤더
bmap 파일 헤더는 버전 번호와 저장 장치의 SCSI 타깃 및 LUN ID를 포함할 수 있다.
파일 오프셋 |
필드 설명 |
필드 사이즈 |
0 |
버전 번호 |
4 바이트, LSB 우선 |
4 |
SCSI 타깃 ID |
2 바이트, LSB 우선 |
6 |
SCSI LUN |
2 바이트, LSB 우선 |
8 |
디스크 슬라이스 |
2 바이트, LSB 우선 |
10 |
디스크 파티션, 'a'=0, 'b'=1,... |
2 바이트, LSB 우선 |
12 |
파일 시스템 블록 사이즈 (예를 들어, 64K) |
4 바이트, LSB 우선 |
16 |
블록 기술자들의 번호 |
4 바이트, LSB 우선 |
20...eof |
블록 기술자들 |
6 바이트 * 블록 기술자들의 # |
"디스크 슬라이스(disk slice)"는, 드라이브가 별도 영역들 또는 "슬라이스들"로 분리되게 하는 파티션과 유사한 FreeBSD 개념이다. 슬라이스들로 인해, 서버는 다수 오퍼레이팅 시스템들을 부팅할 수 있다. 각각의 OS는 별도 슬라이스에 상주한다. 슬라이스내에서, 다수 파티션들이 정의될 수 있는데, 각각의 파티션은 논리적 디스크(예를 들어, "a:", "b:", "c:", ...)에 대응된다. 계층 3 스토리지를 포맷할 때, 정의된 특정 슬라이스 및 파티션을 사용할 수도 있지만, 슬라이스 및 파티션을 bmap 헤더에 배치하여, 하드-코딩 가정들(hard-coding assumptions)을 방지하고 계층 3 저장 구성들에서의 유연성을 허용할 수도 있다.
LUN이 bmap 헤더일 수도 있는데, 그 이유는, bcfs에 의해 어떤 저장 어레이 RAID 장치로부터 판독할 것인지를 식별하는 것이 요구될 수 있기 때문이다. 저장 어레이 RAID 장치내에서, 물리적 장치들에 걸쳐 추출된 블록들은 하나의(또는 그 이상의) LUN들로서 집합적으로 비디오 펌프에 제시될 수 있다. 비디오 펌프가 다수 LUNb를 사용할 수도 있으므로, bmap 헤더의 LUN ID가 어떤 RAID 장치로부터 판독할 것인지를 식별하는 것이 바람직스러울 수도 있다.
블록 기술자
블록 기술자는 디스크의 데이터에 대한 인접한 단일 블록의 위치 및 사이즈를 정의한다. fs-블록 사이즈의 배수들인 LBA 및 길이가 블록의 위치를 정의한다.
스트럭 오프셋 (Struck Offset) |
필드 설명 |
필드 사이즈 |
0 |
SCSI 논리적 블록 어드레스 |
4 바이트, LSB 우선 |
4 |
fs-블록들의 블록 길이 (예를 들어, 64K) |
2 바이트, LSB 우선 |
BCFS
에 의한 자산 캐싱
bmap 파일은, 자산이 로딩되는 시점에 컨텐츠 기입기(12)에서 발생될 수 있다. 비디오 펌프(14)의 컨텐츠 싱커는, /assets/cache의 bmap 파일들이 컨텐츠 기입기의 파일들과 관련하여 최신이라는 것을 보장한다. 스트림이 비디오 펌프에 할당될 때, 스트리밍 서버 프로세스는 자산을 개방하고, 마치 자산이 국지적으로 저장되어 있는 것처럼, 파일로부터 판독할 수 있다.
스트리밍 애플리케이션이 자산의 데이터를 위해 VOP_READ 판독 요청을 형성할 때, bcfs_read는 파일로부터 블록 맵 및 장치 정보를 판독하고 자산의 데이터가 상주하는 논리적 블록 어드레스를 판정하며, 그 다음, bcfs_read는, 필요에 따라, 데이터를 위한 하나 이상의 판독 요청들을 발행하고 복귀한다.
자산이 컨텐츠 기입기(12)로부터 제거된 후, 비디오 펌프(14)의 컨텐츠 싱커는 그것의 bmap 파일을 /assets/cache/assetname에서 제거한다. 이 시점에서, 컨텐츠 싱커는 계층 2의 국지적 디스크 캐시로부터도 자산을 소거한다.
BCFS
에 의한 힌트 파일 캐싱
힌트 파일들은 "트릭 모드들"(예를 들어, 빨리 감기, 되감기)을 수행하기 위한 자산 메타데이터를 포함할 수 있다. 힌트 파일들은, 자산이 스토리지로 로딩될 때, 비디오 펌프에서 발생될 수 있다. 힌트 파일들은 자산의 특정 장면들에 대한 포인터들을 포함한다.
힌트 파일들은 bmap 파일들과 유사하게 핸들링될 수 있다. 힌트 파일은, 자산이 로딩되는 시점에 컨텐츠 기입기에서 발생될 수 있다. 비디오 펌프의 컨텐츠 싱커는, /assets/cache의 힌트 파일들이 컨텐츠 기입기의 파일들과 관련하여 최신이라는 것을 보장한다. 스트림이 비디오 펌프에 할당될 때, 힌트 파일이 국지적으로 캐싱되므로, 스트리밍 서버는 힌트 파일을 개방하여 사용할 수 있다.
다른 방법으로, 수집되고 있는 자산을 스트리밍하기 위한 지연 요구 사항들이 그것을 위해 허용되면, 힌트 파일을 위한 블록 맵이 비디오 펌프에 캐싱될 수 있다. 힌트 파일 데이터를 위한 판독 요청들은, 상술된 바와 같이, 자산 판독들과 동일한 방법으로 bcfs에 의해 핸들링될 수 있다.
계층화된 캐싱
앞서 언급된 바와 같이, 다중-서버 복합체의 비디오 펌프들(14)은 컨텐츠 스토리지 및 캐싱의 3가지 계층들을 사용할 수 있다. 계층화된 캐싱의 목적은 이중적일 수 있는데: 첫번째, 그것은 자산 저장 대역폭으로부터 스트리밍 대역폭을 분리한다. 캐시의 추가에 의해, 어레이들 사이에서의 부하 불균형의 "핫 스팟들" 또는 인스턴스들이 방지될 수 있다. 캐싱이 없다면, 자산 인기도의 변동들로 인해 임의의 소정 저장 어레이로부터 요청되는 불균형한 수의 스트림들로 인해, 쉽게 부하 불균형이 발생할 수 있다. 두번째, 그것은 다른 인기도들의 자산들로부터의 스트림들을 가장 비용 효과적인 미디어 유형들로부터 서빙하는 것에 의해 자산 인기도의 자연스러운 변동들을 이용함으로써 매 스트림당 비용을 감소시킨다. 예를 들어, 하나의 아주 인기있는 자산은, 저장 요구 사항들은 낮지만 대역폭 요구 사항들은 높으므로, RAM으로부터 가장 비용 효과적으로 서빙될 수 있다. 빈번하게 액세스되지 않는 컨텐츠의 거대 라이브러리는, 높은 저장 용량 및 낮은 대역폭을 가진 느리지만 값싼 하드 드라이브들로부터 가장 비용 효과적으로 서빙될 수 있다. 계층화된 캐싱 구현은 현재 시점에서의 자산의 인기도에 기초해 동적으로 그리고 자동적으로 가장 비용 효과적인 미디어 유형으로부터 자산들을 서빙한다.
시스템의 계층 1은, 가장 인기있는 자산들 중 비교적 적은 수가 그로부터 서빙될 수 있는 국지적 RAM을 포함할 수 있다. 계층 2는 가장 빈번하게 스트리밍되는 자산들을 전체로서 저장하는 좀더 거대한 국지적 디스크 캐시를 포함할 수 있다. 계층 2 캐시는 복제도 없고 파일 시스템도 없는 미가공 블록-레벨 스토리지일 수 있다. 계층 1 및 계층 2 모두는 "저장 및 전달(store and forward)"형 캐시들이다. 계층 3는, 임의 상태에서 요청되는 고유한 스트림들의 최대 갯수와 거의 동일해야 하는 적정한 스트리밍 용량을 갖춘 거대한 장기 스토리지를 구성한다.
도 4 및 도 5는, 스트림 전달이 캐시의 3개 계층들에 걸쳐 분산될 수 있는 방법을 나타낸다. 스트림 전달을 위한 비디오 펌프들(14)을 지능적으로 선택하는 것에 의해, 자원 컨트롤러(10)는 하나 이상의 서버(들)에 부착된 캐시 계층들에 걸친 스트림들의 이러한 분산을 근사화할 것이다. 자원 컨트롤러(10)는, 각각의 비디오 펌프가 캐싱 가능한 그리고 캐싱 불가능한 자산들의 균형잡힌 혼합을 서빙하도록, 비디오 펌프들(14)에 걸쳐 스트림들을 분산하는 것에 의해, 계층 2 디스크 캐시 대역폭이 초과되지 않는다는 것을 보장하는데 사용될 수 있다. 자원 컨트롤러(10)는 하나 이상의 비디오 펌프들(14) 및 그들과 연관된 뷰어 스트림들의 현재 특징들을 모니터링함으로써, 어떤 비디오 펌프에 특정 자산과 연관된 새로운 뷰어 스트림이 할당될 것인지를 판정할 수 있다. 이런 식으로, 복합체의 대역폭 자원들은 전역적으로 최적화된다.
도 4에서, u3는, 정확히 하나의 스트림이 존재하는, 계층 3 스토리지로부터 판독되는 자산들의 수이다. 이러한 자산 판독들의 경우, 스트림들의 수(n3)는 계층 3으로부터 판독되는 자산들의 수와 동일하다. u2 + u1은, 하나 이상의 스트림이 존재하는, 계층 3 스토리지로부터 판독되는 자산들의 수를 표현한다. 이 스트림들의 경우, 계층 2 캐시는, 계층 2 캐시로 입력되는 각각의 자산 판독에 대해 다수의 뷰어 스트림들이 출력된다는 점에서, 대역폭 증폭기처럼 동작한다. n2 + n3의 수는 다수 뷰어들에 의해 계층 2 캐시로부터 출력되는 스트림들의 총 수를 표현한다. n2는 계층 2 캐시로부터 직접적으로 출력되는 그리고 계층 1 캐시로 입력되지 않는 뷰어 스트림들의 수이다. 캐시가 뷰어 스트림들 각각을 시간 이동시키므로, 계층 2 캐시로부터 출력되는 뷰어 스트림들은 계층 2 캐시로 입력되는 자산 판독들 또는 동일한 자산의 다른 뷰어 스트림들과 관련하여 시간적으로 동기화되어 있지 않다. 계층 1 캐싱 알고리즘은 캐싱 가능성이 높은 u2 + u1 스트림들의 서브세트(u1)를 선택하고 이 스트림들을 계층 1 RAM 캐시로 유도한다. 계층 2 캐시에서와 같이, 계층 1 레벨에서 스트림이 캐싱되는 계층 1 캐시의 경우, 수개 스트림들이 출력된다. 수(n3)는, 계층 2 또는 계층 3 스토리지로부터의 추가적인 I/O 대역폭을 전혀 사용하지 않는, 계층 1 캐시로부터 출력되는 스트림들의 총 수이다. 서버에 의해 제공되는 스트림들의 총 수는 n1+n2+n3일 수 있다. 계층 3 스토리지로부터 요구되는 총 대역폭은 u1+u2+u3일 수 있다. 도 5는 이 파라미터들을, 여기에 참고 문헌으로써 포함되어 있는, M. Bar 등의 "Long-term Movie Popularity Models in Video-on-Demand Systems", Proceedings of ACM Multimedia Conference, pp. 349-357, November 1997에 의해 개시된 바와 같이, 비디오 인기도로 상관지워진 zipfian 자산 인기도 분포에 의해 예측되는 IP2160 비디오 펌프를 위한 통상적인 값들과 관련짓는다.
계층 2의 국지적 디스크 캐시 증폭 효과 이외에, 계층 3 스토리지로부터 판독되는 자산이 이미 판독되어 여전히 계층 2 캐시에 상주하고 있기 때문에, 그것이 요구되지 않을 가능성이 있다. 이것이 얼마나 자주 발생하는지는 계층 3의 총 저장 사이즈에 대한 계층 2의 총 캐시 사이즈의 비로써 판정될 수 있다. 이 비는 DHCR(Disk Cache Hit Ratio)에 의해 판정될 수 있다.
계층 1
RAM
캐시
이 섹션은 계층 1 RAM 캐싱 알고리즘의 가능한 일 구현을 약술한다. 이 알고리즘은 여기에서, 계층 1 캐시가, 나머지 캐시 계층들과 함께, 확장 가능한 서버 복합체를 지원하도록 동작할 수 있는 방법을 예시하기 위해 설명된다.
구간 캐싱은, 서버 처리율을 증가시키기 위해 효율적으로 캐싱될 수 있는 일시적인 관련 스트림들의 세그먼트들을 식별하는 버퍼 관리 정책일 수 있다. 이 알고리즘은, 여기에 참고 문헌으로써 포함되어 있는, A. Dan 등의 "Buffer Management Policy for an On-Demand video server", IBM Research Report RC 19347에 설명되어 있다. 서버 비용을 감소시키는 것과 관련한 이 알고리즘의 성능은, 여기에 참고 문헌으로써 포함되어 있는, A. Dan 등의 "Buffering and Caching in Large-scale video servers", Proc. Compcon, pp. 217-224, March 1995에서 조사된다, 구간은 시간적으로 중첩하는 동일한 자산에 대한 한 쌍의 연속적인 스트림 요청들로서 정의될 수 있다. 구간 캐싱은, 순간적인 캐시 요구 사항이 스트림 시작 시간들의 오프셋에 의해 표현되는 데이터의 사이즈와 동일할 때, 쌍의 후속 스트림이 캐시로부터 서빙되게 한다. 스트림 시작들이 밀접하게 간격 조정된다면, 절감들이 상당할 수 있다. 구간-캐싱 알고리즘은, 모든 구간들의 정렬된 리스트를 보유하고 캐시를 최소 캐시 요구 사항을 가진 구간들의 세트에 할당하는 것에 의해, 이것을 이용한다.
도 6은 구간-캐싱 일례를 나타낸다. 스트림 A는 시간 0에서 서버로부터 요청될 수 있다. 소정 시간 후, 스트림 A를 완료하기 전에, 스트림 B가 요청될 수 있다. 스트림 A 및 B가 동일한 자산을 재생 중이므로, 구간이 형성될 수 있다. 중첩 A로써 표현되는 데이터량이 계산될 수 있고 구간이 구간들의 정렬된 리스트에 삽입될 수 있다. 구간을 위한 충분한 캐시 메모리가 존재할 수 있으므로, 그것이 구간으로 할당될 수 있고 스트림 B의 음영된 부분이 캐시로부터 완전하게 서빙될 수 있다.
정적인 자산 복제와 비교할 때, 구간 캐싱은 캐시 메모리를 좀더 효과적으로 사용하고, 자산 인기도의 선험적 지식 또는 수동적인 자산 복제가 불필요하다. 트릭 모드의 스트림들은 트릭 모드에 의해 호출되는 변화하는 구간 관계들로 인해 계층 1 캐싱에 참여하지 않지만, 요청되는 데이터가 우연히 계층 1 캐시에 존재한다면, 이들도 여전히 계층 1 캐시 히트들로부터 이점을 취할 수 있다.
계층 2의 국지적 디스크 캐시
계층 2 캐시의 목적은, 자산들이 외부 스토리지(20)로부터 전체가 판독됨에 따라 자산들 모두를 캐싱하는 것에 의해, 스트리밍 대역폭을 자산 저장 대역폭으로부터 분리하는 것일 수 있다. 그것은 복제도 없고 파일 시스템도 없는 미가공 블록-레벨 스토리지로서 관리될 수 있는 거대한 국지적 드라이브 어레이를 포함할 수 있다. 그것은, 블록들이 판독됨에 따라 캐시 내용들이 기입되고 저장 동작이 외부 스토리지로부터의 데이터 흐름에 영향을 미치지 않는다는 것을 의미하는, "저장 및 전달"형 캐시일 수 있다. 예를 들어, IP2160 Media Server(Midstream Technologies)에서, 계층 2 캐시는 내부 드라이브 어레이의 일부분에 상주한다.
계층 2의 국지적 디스크 캐시는 계층 1의 구간 캐시와 구조적으로 유사할 수 있다. 비디오 펌프가 캐싱되는 스트림, 즉, 외부 스토리지로부터 요청되는 스트림에 대한 판독을 발행할 때, 블록은 계층 2 캐시의 할당된 블록으로 복사될 수 있고, 디스크상의 파일 블록을 캐시 블록으로 매핑하는 해시 테이블 엔트리(hash table entry)가 생성될 수 있다. 비디오 펌프가 판독을 발행하기 전에, 비디오 펌프는, 블록이 국지적 디스크 캐시에 상주하는지를 알아보기 위해 해시 테이블을 점검할 수 있다. 그렇다면, 블록들은 계층 3 디스크 장치로부터가 아니라 캐시 블록으로부터 판독된다.
자원 컨트롤러 연산
스트림 서비스 요청을 핸들링하기 위한 비디오 펌프(14)를 선택할 때, 자원 컨트롤러(10)는 캐시에 이미 자산을 가지고 있을 것 같은 서버를 찾을 수도 있지만, 복합체의 자원들을 최적으로 사용하기 위해, 요청을 복합체의 다른 서버로 유도할 수도 있다. 예를 들어, 하나의 인기 높은 자산이 일 비디오 펌프의 계층 1 RAM 캐시로부터 서빙되고, 이 자산을 요청하는 뷰어 스트림들의 수가 비디오 펌프의 대역폭 스트리밍 용량을 포화시킨다고 가정한다. 이 경우, 비디오 펌프는 계층 3의 외부 스토리지 인터페이스 또는 계층 2의 내부 디스크 드라이브들을 이용하지 않음으로써, 이 계층들로부터 방출되는 전역적 스트림 부하의 좀더 높은 백분율이 복합체의 나머지 비디오 펌프들(14)에 배치되는 결과를 초래할 것이다. 비디오 펌프상의 계층 2의 국지적 캐시 디스크 대역폭이 제한될 수도 있으므로, 나머지 비디오 펌프들(14)에서의 캐싱된 스트림들의 결과적인 증가는, 복합체가 지원할 수 있는 스트림들의 수를 효과적으로 제한하면서, 그들의 계층 2 디스크 대역폭을 초과할 수 있다. 복합체의 처리율을 전체로서 최대화하기 위해, 캐싱 가능한 그리고 캐싱 불가능한 자산들의 균형잡힌 혼합이, 도 5에 도시된 것과 유사하게 균형 감각을 갖고, 각각의 비디오 펌프상에 보존되어야 한다.
자원 컨트롤러(10)에 의해 사용되는 비교적 단순한 일 알고리즘이 이 균형을 효과적으로 유지할 수 있다. 자원 컨트롤러와 비디오 펌프들(14) 사이에서 비디오 펌프 각각의 동적인 캐시 상태를 설명하는 통신을 최소화하기 위해 그리고 그러한 정보를 저장해야 할 필요성을 방지하기 위해, 자원 컨트롤러(10)는, 요청되는 매 자산마다 어떤 비디오 펌프가 자산으로부터의 뷰어 스트림을 서빙했는지를 지시하는 일 엔트리를 갖춘, 도표를 저장한다. 캐시들은 시간적으로 밀접하게 위치하는 스트림들에 대해 가장 효과적이므로, 새로운 스트림들을, 자산을 마지막으로 서빙한 비디오 펌프(14)로 유도하는 것이 캐시들을 효과적으로 사용하는 것이다. 부가적으로, 자원 컨트롤러는 각각의 비디오 펌프에서 현재적으로 능동인 스트림들의 수에 대한 카운트를 보유한다. 이 카운트가 설정된 임계치를 초과하면, 스트림은 최저의 스트리밍 대역폭 부하를 갖는 비디오 펌프로 유도될 것이다. 이 메커니즘은, 하나의 비디오 펌프가 인기 높은 임의의 소정 자산에 대해 지나치게 많은 스트림들을 핸들링하지 않는 경우, 인기 높은 자산들이 비디오 펌프들(14)에 걸쳐 공유된다는 것을 보장한다. 그것은 또한 스트리밍 부하를 비디오 펌프들(14)에 걸쳐 분산시킨다.
요약하면, 스트림 부하 균형 알고리즘의 예시적 구현은 다음의 단계들을 포함할 수 있다:
1. 스트림 요청이 자원 컨트롤러(10)에 도달한다.
2. 자원 컨트롤러(10)는 어떤 비디오 펌프(14)가 자산을 마지막으로 서빙했는지를 판정한다.
3. 비디오 펌프(14)가 자산을 서빙하고 있지 않다면, 자원 컨트롤러(10)는 요청을 스트리밍 대역폭의 이용 가능성이 최고인 비디오 펌프로 유도한다.
4. 그렇지 않고, 비디오 펌프(14)가 발견되면, 자원 컨트롤러(10)는, 비디오 펌프의 이 자산에 대한 현재의 능동 카운트가 소정 임계치 미만인지를 점검한다.
a. 임계치가 초과되지 않으면, 자원 컨트롤러(10)는 요청을 마지막 비디오 펌프로 유도하고;
b. 임계치가 초과되면, 자원 컨트롤러(10)는 요청을 스트리밍 대역폭의 이용 가능성이 최고인 비디오 펌프로 유도한다.
결론
청구항들은 여기에서 개시된 예시적 실시예들로 제한되지 않는다. 예를 들어, 블록 맵 캐싱 및 VFS 적층 가능 파일 시스템 모듈들에 기초한 분산 저장 아키텍처 뿐만 아니라 계층화된 캐싱에 기초한 확장 가능한 스트리밍 비디오 서버 복합체의 상기 개시는, 컨텐츠 기입기, 비디오 펌프, 컨트롤러 등과 같은, 설명에 도움이 되는 용어들을 사용하는데, 이것이, 이 출원의 보호 범위를 제한하기 위한 것으로 또는 여기에서 설명된 시스템들, 장치들 및 방법들의 발명 양태들이 개시된 특정 방법들 및 장치들로 제한된다는 것을 의미하기 위한 것으로 해석되어서는 안된다. 더 나아가, 당업자들이라면 이해할 수 있는 바와 같이, 여기에서 개시된 많은 발명 양태들이 스트리밍 미디어 또는 주문형 비디오용으로 이용되지 않는 컴퓨터 시스템들에 적용될 수도 있다. 마찬가지로, 본 발명은, 상술된 바와 같은 VFS 적층 가능 파일 시스템 모듈들 및/또는 블록 맵들을 이용하는 시스템들로 또는 컴퓨터들, 프로세서들, 스위치들, 저장 장치들, 메모리, 알고리즘들 등의 특정 유형들을 이용하는 시스템들로 제한되지 않는다. 컨텐츠 기입기들, 비디오 펌프들, 자원 컨트롤러 등은 본질적으로, 여기에서 개시된 발명 개념들로부터 벗어나지 않으면서, 다양한 형태들을 취할 수 있는 프로그램 가능한 컴퓨터들이다. 디지털 프로세싱, 네트워킹 및 저장 기능들의 비용이 빠르게 감소한다면, 시스템들의 독창적인 동작들을 변경하지 않으면서, 예를 들어, 특정 기능을 위한 프로세싱 및 스토리지를, 여기에서 설명된 기능 소자들 중 하나로부터 다른 기능 소자로 전달하는 것이 용이할 수 있다. 많은 경우들에서, 여기에서 설명된 구현(즉, 기능 소자)의 배치는 단순히 설계자의 기호일 뿐이고 반드시 그래야 하는 것은 아니다. 따라서, 명시적으로 그렇게 제한될 수 있는 경우를 제외하면, 보호 범위는, 상술된 특정 실시예들로 제한되지 않는다.