OpenStack Swift Large Object Support

swift는 기본적으로 업로드된 파일 5G를 지원하는데 큰 파일을 만났을 때 어떻게 처리해야 하나요?Large Object Support는 공식 문서와 마찬가지로 이 문제를 해결하는 데 도움을 줍니다.
Large Object Support
개술
Swift는 단일 대상을 업로드할 때 크기의 제한이 있습니다.기본값은 5GB입니다.그러나 현재 단일 대상의 크기 사실은 현재의 통용 분할 개념이 없다.업로드의 큰 대상을 분할하여 다운로드할 때 특수한 manfest 파일이 만들어지고 모든 부분을 전송하여 하나의 단독 대상이라고 연결합니다.이것 역시 가능한 한 병렬 업로드 세션을 더 빨리 업로드할 수 있도록 제공한다.
swift를 사용하여 객체 분할
가장 빠른 방법으로 이 기능을 시험해 보는 것은python-swiftclinet 라이브러리에 swift 도구를 포함하는 것입니다.큰 파일을 분할할 때 S-S 매개 변수를 사용하여 분할 크기를 지정할 수 있습니다. 예를 들어 swift upload testcontainer -S 1073741824 large_file 이것은 large파일은 1G 크기의 세션이라고 하고 그 세션을 병렬로 업로드합니다.모든 세션을 업로드하는 데 성공하면, swift는 이 세션을 전체적으로 다운로드할 수 있도록 manfest 파일을 만들 것입니다.
그래서 현재 아래의 swift 명령은 전체 대상을 다운로드합니다: swift download testcontainer large_file swift는 그의 분할 대상에 대한 엄격한 공약을 사용합니다.위의 예에서 두 번째test 로 모든 세션을 업로드합니다.container_segments 용기.이 세션의 이름은 다음과 같습니다: largefile/1290206778.25/21474836480/00000000, large_file/1290206778.25/21474836480/00000001, etc.
단독 용기를 사용하는 가장 좋은 점은 메인 용기의 시계가 모든 부분의 이름에 오염되지 않는다는 것이다./// 의 세션 이름을 사용하는 이유는 같은 이름의 파일을 새로 올릴 때mainfest 파일이 올릴 때까지 첫 번째 내용을 다시 쓰지 않기 때문입니다.
swift는 이 세션 파일을 관리할 것입니다. 오래된 세션을 삭제하고 다시 쓰는 등 삭제할 것입니다.이 동작을 다시 쓸 수 있습니다. -leave-segments 인자가 필요하면.이것은 매우 유용하다. 만약 여러 버전의 같은 큰 대상을 원한다면 사용할 수 있다.
Direct API 직접 API
HTTP를 통해 세션과 manfest 디렉터리를 요청할 수도 있습니다.세션만 업로드할 수 있습니다. manifest 파일은 0자리 파일이고 X-Object-manifest 헤더가 추가됩니다.
모든 대상 세션은 같은 용기에 공통된 대상 접두사 이름이 있고, 이름이 연결된 순서에 따라 정렬되어야 한다.그것들은 manfest 파일과 같은 용기에 있을 필요가 없다.이것은 위의 swift와 마찬가지로 용기 목록을 조용하게 유지하는 데 도움이 된다.
manifest 파일은 추가 X-Objetc-manifest가 있는 0 바이트 파일입니다: / 머리, 는 대상 세션이 있는 용기, 는 모든 세션에 공통된 접두사입니다.
가장 좋은 것은 모든 부분을 업로드한 다음에 manfest를 만들거나 업데이트하는 것입니다.업로드가 완료될 때까지 전체 객체를 다운로드할 수 없습니다.따라서 두 번째 위치로 새 그룹을 업로드한 다음 manfest를 업데이트해서 전체 위치를 표시할 수 있습니다.새 세션을 업로드하는 동안, 처음의 manfest는 첫 번째 세션을 다운로드할 수 있습니다.
이것은 curl을 사용하여 작은 1바이트 세션에 대한 예가 있습니다.

# First, upload the segments
curl -X PUT -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject/1 --data-binary '1'
curl -X PUT -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject/2 --data-binary '2'
curl -X PUT -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject/3 --data-binary '3'

# Next, create the manifest file
curl -X PUT -H 'X-Auth-Token: <token>' \
    -H 'X-Object-Manifest: container/myobject/' \
    http://<storage_url>/container/myobject --data-binary ''

# And now we can download the segments as a single object
curl -H 'X-Auth-Token: <token>' \
    http://<storage_url>/container/myobject

기타 주의사항 1.GET나 HEAD가 있는 manifest 파일, X-Object-manifest: / 헤더는 연결된 대상을 되돌려줍니다. 연결된 대상이 어디에서 왔는지 볼 수 있도록 합니다.2. Content-Length가 GET나 HEAD에 대한 응답은 manfest 파일에서 동적으로 / 목록에 있는 모든 부분을 합산하기 때문에 추가 부분을 업로드하면 manfest가 연결된 대상이 더욱 커진다.manfest 파일을 다시 만들 필요가 없습니다.3. Content-Type이 GET나 HEAD에 대한 응답은 manfest 파일과 Content-Tpye가 PUT 요청할 때 설정한 것처럼 manfest를 생성합니다.Content-Tpye를 간단하게 변경할 수 있습니다. PUT를 다시 보낼 수 있습니다.4. ETag은 GET나 HEAD에 대한 응답이 manfest 파일 / 에 열거된 연결된 모든 부분의 ETAgs 문자열의 MD5를 동적으로 합칠 수 있습니다.swift에서 Etag은 항상 대상 내용의 MD5를 합쳐서 각각의 독립된 세션에 적용할 수 있습니다.그러나 그는 이런 ETAg를 manfest 자체에서 생산할 수 없다.그래서 이 방법은 최소한 변경된 검사를 제공하기 위해 선택되었다.
주의: 용기의 동기화 기능을 사용한다면 manfest 파일과 세션 파일이 끊임없이 용기에 동기화되어 있는지 확인해야 합니다.
History 대형 객체 지원은 구현되기 전에 여러 버전이 있습니다.
swift에서 대상의 크기를 제한하는 가장 중요한 것은 링 중의 허 노드의 균형을 유지하는 것이다.심지어 디스크의 분포를 유지하기 위해 집단을 관통하는 뚜렷한 저장 모드를 사용하는 것은 큰 대상을 작은 부분으로 나누어 다시 읽을 수 있을 때 한데 붙이는 간단한 것이다.
큰 대상 지원을 도입하기 전에, 일부 응용 프로그램은 업로드된 부분을 분리해서 클라이언트 쪽에서 하나의 부분을 검색할 수 있도록 조립할 수 있다.이 설계는 고객이 방대한 데이터 집합을 백업하고 압축할 수 있도록 허용하지만, 성능을 자주 개선하거나 네트워크 중단으로 인한 오류를 줄일 수 있도록 한다.이 방법의 주요 결함은 원시적인 구역 방안이 이 대상을 정확하게 재조립해야 한다는 것이다. 일부 장면에 있어 실제와 부합되지 않는다. 예를 들어 CDN 원본과 같다.
고객이 5G코인보다 저장 대상이 큰 시장에 진입하는 장애물을 제거하기 위해 우선 우리는 완전하고 투명하게 큰 대상을 업로드할 수 있도록 지원한다.완전 원형화 구현은 고객의 API를 바꾸지 않고 자동으로 분할된 대상을 통해 세션이 에이전트에 업로드되고 있음을 지원합니다.모든 세션은 고객의 API에 완전히 숨겨져 있습니다.
이 해결 방안은 몇몇 도전적인 실패 조건을 집단으로 만들었고, 어떠한 인자와도 병행 업로드를 할 수 없으며, 실패에서 회복할 수 있는 기초가 없었다.이런 투명화의 실현은 수익에 대해 너무 복잡하다고 여겨진다.
현재의'user manifest'디자인은 클라이언트에 투명하게 다운로드할 수 있는 큰 대상을 제공하기 위해 선택되었습니다. 클라이언트에게 세그먼트 업로드를 지원하기 위해 깨끗한 API를 제공해 왔습니다.
사용자 manifest를 표시하는 또 다른 방법은 미리 정의된 형식의 세션 목록으로 세그먼트 업로드를 완성해야 합니다.동시에 이것은 잠재적인 장점을 제공할 수 있다. 이것은 클라이언트에게 추가 부하를 전달하기로 결정했다. 이런 과정에서 젖의 행위는 더욱 간단한'API'지원을 사용해야 한다는 것을 제한한다(본질적으로'X-Object-Manifest'헤드의 형식)
개발 기간에 우리는 이러한 경로 접두사를 바탕으로 하는'은식'user manifest 방법은 최종 용기 목록 일치성 창에 영향을 미칠 수 있음을 알아차렸다. 이론적으로 한 GET가 manifest 대상에서 무효한 전체 대상을 단기간 안에 되돌려보낼 수 있다.사실 당신은 이런 상황을 겪지 않을 것이다. 아주 높은 속도로 Object-updaters나 container-replicators를 실행하는 작은 테스트 환경에 업로드하지 않으면.
모든 swift와 같이 큰 대상은 이 특성을 계속 향상시키고 변화시킬 것이다.