elastic cloud storage (ecs)...ecs hdfs 소개..... 122 ecs hdfs를 사용하도록 hadoop 구성...

Elastic Cloud Storage (ECS)3.1 버전

데이터 액세스 가이드302-003-865

01

Copyright © 2013-2017 Dell Inc. or its subsidiaries. All rights reserved.

발행: 2017년 8월

Dell은 본 발행물의 정보가 해당 발행일 현재 정확한 것으로 간주합니다. 모든 정보는 예고 없이 변경될 수 있습니다.

본 발행물의 정보는 "있는 그대로" 제공됩니다. Dell은 본 발행물의 정보와 관련하여 어떠한 진술이나 보증도 하지 않으며, 특히 상품성이나 특정 목

적을 위한 적합성에 대하여 어떠한 묵시적인 보증도 부인합니다. 본 발행물에 설명된 Dell 소프트웨어를 사용, 복사 및 배포하려면 해당 소프트웨어

라이센스가 필요합니다.

Dell, EMC 및 기타 상표는 Dell Inc. 또는 해당 자회사의 상표입니다. 기타 모든 상표는 해당 소유주의 자산일 수 있습니다. Published in the USA.

한국이엠씨컴퓨터시스템즈(주)서울특별시 강남구 테헤란로 152 강남파이낸스센터 18층 (우)06236대표 전화: (02)2125-7000 구입/상담 문의: 080-775-7000 팩스: (02)2125-7280www.DellEMC.com/ko-kr/index.htm

2 Elastic Cloud Storage (ECS) 3.1 데이터 액세스 가이드

7

9

S3 11

S3 13ECS의 Amazon S3 API 지원 기능................................................................ 14S3 API의 지원되는 기능 및 지원되지 않는 기능.......................................... 14

버킷이 이미 존재하는 경우의 동작................................................. 17버킷 정책 지원............................................................................................ 18

버킷 정책 생성, 할당 및 관리..........................................................19버킷 정책 시나리오........................................................................20지원되는 버킷 정책 작업................................................................22지원되는 버킷 정책 조건................................................................23

S3 확장.......................................................................................................24바이트 범위 확장........................................................................... 24보존...............................................................................................28파일 시스템 활성화........................................................................29

메타데이터 검색.........................................................................................30버킷에 메타데이터 인덱스 값 할당................................................. 31메타데이터 검색에 암호화 사용.....................................................33S3 프로토콜을 사용하여 오브젝트에 메타데이터 할당.................. 33메타데이터 검색 쿼리 사용............................................................ 34ECS Java SDK에서 메타데이터 검색 사용 .................................... 39ECS 시스템 메타데이터 및 선택적 속성........................................ 40

S3와 Swift의 상호 운용성.......................................................................... 40암호 키 생성 및 관리...................................................................................43

오브젝트 사용자용 키 생성............................................................ 43S3 암호 키 생성: 셀프 서비스.........................................................44

S3 서비스로 인증........................................................................................47ECS에 s3curl 사용...................................................................................... 48SDK를 사용하여 S3 서비스에 액세스......................................................... 48

Java Amazon SDK 사용................................................................. 49ECS용 Java SDK 클라이언트......................................................... 51

OpenStack Swift 53

OpenStack Swift 55ECS의 OpenStack Swift 지원 기능............................................................ 56지원되는 OpenStack Swift 작업.................................................................56Swift 확장.................................................................................................. 58Swift 바이트 범위 확장...............................................................................58

오브젝트 내의 바이트 범위 업데이트.............................................58오브젝트의 부분 덮어쓰기.............................................................60오브젝트에 데이터 추가................................................................. 61

그림

표

1부

1장

2부

2장

목차

Elastic Cloud Storage (ECS) 3.1 데이터 액세스 가이드 3

오브젝트 내의 여러 바이트 범위 읽기............................................62보존............................................................................................................62파일 시스템 지원........................................................................................ 63S3와 Swift의 상호 운용성.......................................................................... 63OpenStack Swift 인증................................................................................ 64

ECS Portal에서 Swift 사용자 생성.................................................64OpenStack 버전 1 인증 ................................................................. 65OpenStack 버전 2 인증..................................................................67ECS Keystone V3 통합을 사용한 인증........................................... 69

컨테이너에 대한 인증................................................................................. 72

EMC Atmos 75

EMC Atmos 77ECS의 EMC Atmos API 지원 기능.............................................................. 78지원되는 EMC Atmos REST API 호출.........................................................78지원되지 않는 EMC Atmos REST API 호출................................................ 80EMC Atmos REST API 호출의 서브테넌트 지원..........................................81API 확장...................................................................................................... 81

오브젝트에 데이터 추가................................................................. 81Atmos 오브젝트의 보존 및 보존 만료 기간에 대한 ECS 지원.........82

CAS 87

CAS 89ECS에서 CAS 지원 설정.............................................................................90콜드 스토리지............................................................................................ 90Compliance................................................................................................. 91

플랫폼 강화 및 규정 준수............................................................... 91규정 준수 및 보존 정책.................................................................. 92규정 준수 에이전트........................................................................93

ECS에서 CAS 보존.....................................................................................93CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최대 관리자...........................................................................................95네임스페이스 보존 정책 설정.................................................................... 101CAS 사용자를 위한 버킷 생성 및 설정.......................................................102CAS 오브젝트 사용자 설정........................................................................103CAS를 위한 버킷 ACL 설정....................................................................... 104CAS 사용자를 지원하는 ECS Management API........................................ 106CAS(Content Addressable Storage) SDK API 지원................................... 107

ECS Management REST API 109

ECS Management REST API 111ECS Management REST API 소개............................................................. 112ECS Management REST API의 인증을 받습니다....................................... 112

쿠키를 사용하지 않고 인증 .......................................................... 112로그아웃....................................................................................... 114ECS Management REST API whoami 명령....................................114ECS Management REST API 요약................................................ 115

3부

3장

4부

4장

5부

5장

목차


HDFS 119

ECS HDFS 소개 121ECS HDFS 소개........................................................................................ 122ECS HDFS를 사용하도록 Hadoop 구성 .................................................... 123Hadoop 인증 모드..................................................................................... 123

파일 시스템으로 버킷 액세스....................................................... 124버킷 사용자 지정 그룹 ACL 및 기본 그룹..................................... 125Hadoop 수퍼유저 및 수퍼그룹......................................................125멀티 프로토콜(교차 헤드) 액세스................................................ 126프록시 사용자.............................................................................. 126동등 사용자.................................................................................. 126

단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션............... 127Hadoop Kerberos 인증 모드..........................................................127

파일 시스템 상호 작용...............................................................................128지원되는 Hadoop 애플리케이션................................................................ 128

ECS HDFS를 사용하여 단순 Hadoop 클러스터 구성 129ECS HDFS와 단순 Hadoop 클러스터 통합................................................ 130Ambari를 사용하여 Hortonworks HDP 설치.............................................. 130ECS Portal을 사용하여 HDFS에 사용할 버킷 생성.................................... 132

사용자 지정 그룹 버킷 ACL 설정.................................................. 135사용자 버킷 ACL 설정.................................................................. 136Hadoop 및 ECS 버킷 사용 권한 예................................................137

ECS HDFS 및 Hadoop 통합 계획...............................................................139ECS HDFS 설치 및 지원 패키지 가져오기................................................. 139ECS HDFS Client Library 구축.................................................................. 140ECS 클라이언트 속성 구성........................................................................ 141Hive 설정...................................................................................................142ECS에 대한 Hadoop 액세스 확인.............................................................. 143버킷에 보안 적용.......................................................................................144HDFS에서 ECS 버킷으로 기본 파일 시스템 재배치...................................145

ECS HDFS를 사용하여 Kerberized Hadoop 클러스터 구성 147ECS HDFS와 보안 Hadoop 클러스터 통합 ................................................148단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획....................148그룹 이름 매핑.......................................................................................... 149ECS 서비스 주체를 사용하여 ECS 노드 구성............................................ 149Ambari를 사용하여 Kerberos 활성화......................................................... 153메타데이터를 사용하여 ECS 버킷 보안 유지.............................................154

Management REST API를 사용하여 ECS에 메타데이터 값 로드.. 156ECS 클라이언트 속성 재구성.................................................................... 157Hadoop 서비스를 시작하고 ECS에 대한 Hadoop 액세스를 확인합니다.... 158

문제 해결 159소개.......................................................................................................... 160AD/LDAP가 보안 Hadoop 클러스터로 올바로 구성되어 있는지 확인........ 160Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음............................. 161AD 사용자에 대해 거부되는 권한............................................................... 161사용 권한 오류........................................................................................... 161요청 처리 실패.......................................................................................... 164Kerberos 클라이언트 측 로깅 및 디버깅 활성화........................................ 164

6부

6장

7장

8장

9장

목차


KDC 상의 Kerberos 디버그........................................................................165시간 차이 제거.......................................................................................... 165ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성.....165Yarn 디렉토리가 없다는 오류에 대한 해결 방법........................................ 167

부록: Kerberos 구성에 대한 지침 169Kerberos 구성에 대한 지침........................................................................170

Kerberos KDC 설정.......................................................................170Kerberos에 대한 AD 사용자 인증 구성.......................................... 171

부록: ECS HDFS의 Hadoop core-site.xml 속성 175ECS HDFS의 Hadoop core-site.xml 속성...................................................176

단순 인증 모드의 core-site.xml 샘플............................................ 179

부록: 보안 버킷 메타데이터 예 181보안 버킷 메타데이터................................................................................182

10장

11장

12장

목차


ECS Portal에서 새로운 네임스페이스에 대해 규정 준수 활성화................................. 93CAS 버킷에 대한 보존 옵션........................................................................................ 96EBR 시나리오.............................................................................................................98법적 증거 자료 보관 시나리오................................................................................... 100새 보존 정책.............................................................................................................. 102네임스페이스에 대한 보존 정책................................................................................ 102오브젝트 사용자에 대한 CAS 설정............................................................................ 103버킷 ACL 편집...........................................................................................................104버킷 ACL 관리...........................................................................................................105Hadoop 클러스터에 통합된 ECS HDFS..................................................................... 122

12345678910

그림


그림


지원되는 S3 API..........................................................................................................14추가 기능.................................................................................................................... 16지원되지 않는 S3 API.................................................................................................. 17오브젝트 작업에 대한 사용 권한.................................................................................22버킷 작업에 대한 사용 권한........................................................................................ 22버킷 하위 리소스 작업에 대한 사용 권한.................................................................... 23지원되는 일반 AWS 조건 키....................................................................................... 23오브젝트 작업에 지원되는 S3 전용 조건 키입니다..................................................... 23버킷 작업에 지원되는 S3 전용 조건 키입니다.............................................................24지원되는 OpenStack Swift 호출.................................................................................56추가 기능....................................................................................................................58지원되지 않는 OpenStack Swift 호출.........................................................................58Keystone 인증 공급자 설정......................................................................................... 71지원되는 Atmos REST API 호출................................................................................. 78지원되지 않는 Atmos REST API 호출......................................................................... 80Atmos 보존 기간.........................................................................................................82일반 아카이브와 콜드 아카이브의 요구 사항 비교......................................................90보존을 위한 ECS Management API 리소스.................................................................95이벤트 기반 보존에 대한 CAS API 함수...................................................................... 99법적 증거 자료 보관에 대한 CAS API 함수.................................................................101버킷 ACL...................................................................................................................105버킷 ACL 그룹...........................................................................................................106ECS Management REST API메서드 요약...................................................................115단순 Hadoop 클러스터에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예............138Kerberized Hadoop 클러스터에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예.. 138ECS HDFS 구성 사전 요구 사항................................................................................ 139ECS HDFS Client Library...........................................................................................140ECS 액세스를 활성화하기 위한 Hadoop 구성............................................................ 141Hive templeton 구성..................................................................................................142Hive 동시 접속 및 ACID 트랜잭션을 활성화하도록 Hadoop 구성...............................145ECS 액세스를 활성화하기 위한 Hadoop 구성........................................................... 158Hadoop core-site.xml 속성........................................................................................ 176

1234567891011121314151617181920212223242526272829303132

표


표


1부

S3

1장, "S3"

S3 11

S3


1장

S3

l ECS의 Amazon S3 API 지원 기능....................................................................... 14l S3 API의 지원되는 기능 및 지원되지 않는 기능..................................................14l 버킷 정책 지원....................................................................................................18l S3 확장.............................................................................................................. 24l 메타데이터 검색.................................................................................................30l S3와 Swift의 상호 운용성.................................................................................. 40l 암호 키 생성 및 관리.......................................................................................... 43l S3 서비스로 인증............................................................................................... 47l ECS에 s3curl 사용..............................................................................................48l SDK를 사용하여 S3 서비스에 액세스.................................................................48

S3 13

ECS의 Amazon S3 API 지원 기능ECS는 Amazon S3(Amazon Simple Storage Service) API(Application ProgrammingInterface)를 지원합니다.

Amazon S3 Object Service는 다음 포트에서 사용할 수 있습니다.

프로토콜 포트

HTTP 9020

HTTPS 9021

다음 항목에서는 S3 API에 대한 지원, ECS에서 제공되는 확장 기능, 서비스로 인증하는 방법, SDK(Software Development Kit)를 사용하여 서비스에 액세스하는 클라이언트를 개발하는 방법 등을 설명합니다.

l S3 API의 지원되는 기능 및 지원되지 않는 기능(14페이지)

l S3 확장(24페이지)

l 메타데이터 검색(30페이지)

l 암호 키 생성 및 관리(43페이지)

l S3 서비스로 인증(47페이지)

l SDK를 사용하여 S3 서비스에 액세스(48페이지)

버킷 주소 지정 및 인증의 일부 측면은 ECS에 따라 달라집니다. ECS와 통신하도록 기존 애플리케이션을 구성하거나 ECS와 통신하기 위해 S3 API를 사용하는 새 애플리케이션을 개발하려면 ECS Product Documentation 페이지에 있는 ECS 관리 가이드의 기본 URL 섹션을 참조하십시오.

S3 API의 지원되는 기능 및 지원되지 않는 기능ECS는 Amazon S3 REST API의 하위 집합을 지원합니다.

다음 섹션에서는 지원되는 API 및 지원되지 않는 API를 자세히 설명합니다.

l 지원되는 S3 API(14페이지)

l 지원되지 않는 S3 API(17페이지)

지원되는 S3 API다음 표에는 지원되는 S3 API 메서드가 정리되어 있습니다.

표 1 지원되는 S3 API

기능 참고

GET Service ECS는 버킷 목록의 페이징을 활성화하기 위해 마커 및 max-keys 매개 변수를 지원합니다.

GET /?marker=<bucket>&max-keys=<num>

S3


https://community.emc.com/docs/DOC-56978

표 1 지원되는 S3 API (계속)

기능 참고

예:

GET /?marker=mybucket&max-keys=40

DELETE Bucket

DELETE Bucket cors

DELETE Bucket lifecycle 수명주기에서 만료 부분만 지원됩니다. 아카이빙(AWSGlacier)과 관련된 정책은 지원되지 않습니다. 수명주기는 파일시스템 지원 버킷에서 지원되지 않습니다.

DELETE Bucket policy

GET Bucket (List Objects) 파일 시스템 지원 버킷의 경우 버킷의 오브젝트를 나열할 때 구분 기호로 /만 지원됩니다.

GET Bucket cors

GET Bucket acl

GET Bucket lifecycle 수명주기에서 만료 부분만 지원됩니다. 아카이빙(AWSGlacier)과 관련된 정책은 지원되지 않습니다. 수명주기는 파일시스템 지원 버킷에서 지원되지 않습니다.

GET Bucket policy

GET Bucket Object versions

GET Bucket versioning

HEAD Bucket

List Multipart Uploads

PUT Bucket 기존 버킷에 대해 PUT이 실행되는 경우 버킷이 이미 존재하는경우의 동작(17페이지) 항목을 참조하십시오.

PUT Bucket cors

PUT Bucket acl

PUT Bucket lifecycle 수명주기에서 만료 부분만 지원됩니다. 아카이빙(AWSGlacier)과 관련된 정책은 지원되지 않습니다. 수명주기는 파일시스템 지원 버킷에서 지원되지 않습니다.

PUT Bucket policy 파일 시스템 지원 버킷 또는 CAS 지원 버킷에는 버킷 정책을구성할 수 없습니다. ECS에서 지원되지 않는 작업에 대해서는버킷 정책을 구성할 수 없습니다. 버킷 정책 지원에 대한 자세한 내용은 버킷 정책 지원에 나와 있습니다.

PUT Bucket versioning

DELETE Object

Delete Multiple Objects

GET Object

S3

S3 API의 지원되는 기능 및 지원되지 않는 기능 15

표 1 지원되는 S3 API (계속)

기능 참고

GET Object ACL

HEAD Object

PUT Object 청크 분할 PUT 지원

PUT Object acl

PUT Object - Copy

OPTIONS object

Initiate Multipart Upload

Upload Part

Upload Part - Copy

Complete Multipart Upload ECS는 이 요청에 대해 ETag 00을 반환합니다. 이는 AmazonS3 응답과 다릅니다.

Abort Multipart Upload

List Parts

l 3자 미만의 이름을 가진 버킷을 생성하려고 하면 작업이 실패하고 400 BadRequest, InvalidBucketName이 반환됩니다.

l 빈 컨텐츠의 버킷 또는 오브젝트를 생성하려고 하면 ECS에서 400 invalidcontent-length value가 반환됩니다. 반면 이런 경우에 AWS에서는 400 BadRequest가 반환됩니다.

l 동일한 사용자 메타데이터 인덱스 키를 인덱싱하지만 다른 데이터 유형을 갖는 다른 버킷으로 오브젝트를 복제하는 것은 지원되지 않으며 작업이 실패하고 500Server Error가 반환됩니다.

l 버킷의 오브젝트를 나열할 때 접두사와 구분 기호를 사용하지만 잘못 된 마커를 제공하는 경우 500 Server Error 또는 400 Bad Request(파일 시스템 지원 버킷)가 반환됩니다. 반면 AWS에서는 200 OK를 반환하며 오브젝트가 나열되지 않습니다.

표 2 추가 기능

기능 참고

Pre-signed URLs ECS는 자격 증명 없이도 오브젝트에 대한 액세스 권한을 부여받을 수 있도록 미리 서명된 URL을 사용할 수 있도록 지원합니다.

추가 정보는 여기에서 찾을 수 있습니다.

Chunked PUT PUT 작업을 사용하여 청크에 있는 오브젝트를 업로드할 수 있습니다. 이를 통해 페이로드의 총 크기가 알려지기 전에 컨텐츠를 전송할 수 있습니다. 청크 전송에서는 전송 인코딩 헤더

S3


http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

표 2 추가 기능 (계속)

기능 참고

(전송 인코딩: 청크)를 사용하여 컨텐츠가 청크 단위로 전송될것임을 지정합니다.

지원되지 않는 S3 API다음 표에는 지원되지 않는 S3 API 메서드가 정리되어 있습니다.

표 3 지원되지 않는 S3 API

기능 참고

DELETE Bucket tagging

DELETE Bucket website

GET Bucket location ECS는 단일 VDC(Virtual Data Center)만 인식합니다.

GET Bucket logging

GET Bucket notification S3에서 알림은 축소된 이중화 기능에 대해서만 정의됩니다. 현재 ECS는 알림을 지원하지 않습니다.

GET Bucket tagging

GET Bucket requestPayment ECS에는 고유한 결제 모델이 사용됩니다.

GET Bucket website

PUT Bucket logging

PUT Bucket notification S3에서 알림은 축소된 이중화 기능에 대해서만 정의됩니다. 현재 ECS는 알림을 지원하지 않습니다.

PUT Bucket tagging

PUT Bucket requestPayment ECS에는 고유한 결제 모델이 사용됩니다.

PUT Bucket website

오브젝트 API

GET Object torrent

POST Object

POST Object restore 이 작업은 AWS Glacier와 관련 있으며 ECS에서는 지원되지 않습니다.

버킷이 이미 존재하는 경우의 동작

이미 있는 이름을 사용하여 버킷을 생성하려고 할 경우에 ECS의 동작은 AWS의 동작과 다를 수 있습니다.

버킷에 대한 FULL CONTROL 권한 또는 기타 사용 권한을 가진 사용자가 버킷을 다시생성하려고 할 경우 AWS는 항상 409 Conflict를 반환합니다. 한편, 버킷에 대한FULL_CONTROL 또는 WRITE_ACP 권한을 가진 ECS 사용자가 버킷을 다시 생성하려고 할 경우 ECS는 200 OK를 반환하고 ACL을 덮어씁니다. 하지만 소유자가 변경되지

S3

버킷이 이미 존재하는 경우의 동작 17

않습니다. WRITE/READ 권한이 있는 ECS 사용자가 버킷을 다시 생성하려고 할 경우ECS는 409 Conflict를 반환합니다.

버킷 소유자가 버킷을 다시 생성하려고 할 경우 ECS는 200 OK를 반환하고 ACL을 덮어쓰며, AWS도 동일한 방식으로 동작합니다.

버킷에 대한 액세스 권한이 없는 사용자가 버킷을 다시 생성하려고 할 경우 ECS는 409Conflict 오류를 반환하며, AWS도 동일한 방식으로 동작합니다.

버킷 정책 지원ECS는 S3 버킷 액세스 정책을 설정할 수 있도록 지원합니다. 모든 작업을 허용하거나아무 작업도 허용하지 않는 ACL과 달리, 액세스 정책은 특정 사용자 또는 모든 사용자에게 특정 작업에 대한 조건부의 세분화된 사용 권한을 부여할 수 있습니다. 정책 조건을 사용하여 해당 조건과 일치하는 일련의 오브젝트에 대한 사용 권한을 할당하고 새로업로드된 오브젝트에 대한 사용 권한을 자동으로 할당할 수 있습니다.

S3 프로토콜을 사용하여 리소스에 대한 액세스를 관리하는 방식이 http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html에 설명되어 있습니다. 이를 이해의 토대로 삼아 ECS에서 S3 버킷 정책을 사용할 수 있습니다. 이 섹션에서는 버킷 정책 사용에 대한 기본적인 정보를 제공하고 ECS에서 버킷 정책을 사용할 때 무엇이 다른지를 설명합니다.

다음은 ECS 버킷 정책의 예입니다.

{ "Version": "2012-10-17", "Id": "S3PolicyIdNew2", "Statement":[ { "Sid":"Granting PutObject permission to user2 ", "Effect":"Allow", "Principal": "user_n2", "Action":["s3:PutObject"], "Resource":["PolicyBuck1/*"], "Condition": { "StringEquals": {"s3:x-amz-server-side-encryption": [ "AES256"]} } } ]}

각 정책은 버전, 식별자 및 하나 이상의 문으로 구성된 JSON(JavaScript ObjectNotation) 문서입니다.

Version

Version 필드는 정책 언어 버전을 지정하며 2012-10-17 또는 2008-10-17이 될수 있습니다. 버전이 지정되지 않은 경우 2008-10-17이 자동으로 삽입됩니다.

새 정책의 정책 언어를 최신 버전 2012-10-17으로 설정하는 것이 좋습니다.

Id

ID는 선택 필드입니다.

각 문은 다음 요소로 구성됩니다.

SID

문 ID입니다. 문의 기능을 설명하는 문자열입니다.

S3


http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

Resource

문의 대상인 버킷 또는 오브젝트입니다. 리소스는 Resource 또는 NotResource 문에 연결할 수 있습니다.

리소스는 버킷 및 키 이름이며, 아래와 같이 가상 호스트 형식 주소 지정을 사용하는지 아니면 경로 형식 주소 지정을 사용하는지에 따라 다르게 지정됩니다.

Host Style: http://bucketname.ns1.emc.com/objectnamePath Style: http://ns1.emc.com/bucketname/objectname

두 경우에 모두 리소스 이름은 다음과 같습니다. bucketname/objectname .

* 및 ? 와일드카드 문자를 사용할 수 있습니다. 별표(*)는 0자 이상의 모든 문자 조합을 나타내며 물음표(?)는 모든 단일 문자를 나타냅니다. 예를 들어 bucketname이라는 버킷의 모든 오브젝트를 나타내려면 다음을 사용합니다.

bucketname/*

Actions

사용 권한(허용 또는 거부)을 할당할 일련의 작업입니다. 지원되는 작업은 지원되는 버킷 정책 작업(22페이지)에 나열되어 있습니다.

작업은 Action 또는 NotAction 문에 연결할 수 있습니다.

Effect

Allow 또는 Deny로 설정할 수 있습니다. 지정된 작업을 허용할지 아니면 거부할지를 결정합니다.

Principal

지정된 작업이 허용되거나 거부되는 ECS 오브젝트 사용자입니다.

모든 사용자에게 사용 권한을 부여하려는 경우(익명 액세스라고도 함) 아래와 같이 Principal 값을 와일드카드 "*"로 설정할 수 있습니다.

"Principal":"*"

ECS 버킷 정책은 통합 사용자와 Amazon IAM 사용자 및 역할을 지원하지 않습니다.

조건정책이 적용되는 조건입니다. 조건식을 사용하여 정책에 제공된 조건과 요청에 제공된 조건이 일치하는지 확인됩니다.

다음 조건 연산자는 지원되지 않습니다. Binary, ARN, IfExists, Check Key Exists.지원되는 조건 키는 지원되는 버킷 정책 조건(23페이지)에 나열되어 있습니다.

정책에 사용할 수 있는 요소에 대한 자세한 내용은 Amazon S3 설명서(여기)에 나와 있습니다.

버킷 정책 생성, 할당 및 관리

S3

버킷 정책 생성, 할당 및 관리 19

http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html

ECS Portal에서 버킷에 대한 버킷 정책을 생성할 수 있습니다(ECS ProductDocumentation 페이지에 있는 ECS 관리 가이드 참조). 또한 다른 편집기를 사용하여 정책을 생성한 후 ECS Management REST API 또는 ECS S3 API를 사용하여 해당 정책을버킷에 연결할 수도 있습니다.

ECS Management REST API는 버킷 정책 하위 리소스를 추가, 검색 및 삭제할 수 있는다음과 같은 API를 제공합니다.

l PUT /object/bucket/{bucketName}/policyl GET /object/bucket/{bucketName}/policyl DELETE /object/bucket/{bucketName}/policyECS Management REST API를 사용하여 정책을 설정하려면 ECS SystemAdministrator 또는 Namespace Administrator 역할이 있어야 합니다.

ECS S3 API는 다음 API를 제공합니다.

l PUT Bucket Policyl GET Bucket Policyl DELETE Bucket Policy

S3 API를 사용하여 정책을 설정하려면 버킷 소유자여야 합니다.

이러한 API에 대한 자세한 내용은 ECS API 참조에 나와 있습니다.

버킷 정책 시나리오

일반적으로 버킷 소유자는 버킷에 대한 모든 권한을 가지며, 다른 사용자에게 권한을부여할 수 있고, S3 클라이언트를 사용하여 S3 버킷 정책을 설정할 수 있습니다. 또한ECS에서는 ECS System Administrator 또는 Namespace Administrator가 ECS Portal의버킷 정책 편집기를 사용하여 버킷 정책을 설정할 수 있습니다.

다음과 같은 일반적인 시나리오에서 버킷 정책을 사용할 수 있습니다.

l 사용자에게 버킷 사용 권한 부여(20페이지)

l 모든 사용자에게 버킷 사용 권한 부여(21페이지)

l 자동으로 오브젝트 생성 권한 할당(21페이지)

사용자에게 버킷 사용 권한 부여버킷 소유자가 아닌 사용자에게 버킷에 대한 사용 권한을 부여하려는 경우 관련 권한을변경할 리소스를 지정하고, 보안 주체 속성을 사용자 이름으로 설정하고, 허용할 하나이상의 작업을 지정할 수 있습니다.

다음 예에서는 user1이라는 사용자에게 mybucket이라는 버킷의 오브젝트를 업데이트하고 읽을 수 있는 권한을 부여하는 정책을 보여 줍니다.

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "Grant permission to user1", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] }

S3




http://doc.isilon.com/ECS/3.1/API/index.html

]}

또한 조건을 추가할 수 있습니다. 예를 들어 사용자가 특정 IP 주소에서 버킷에 액세스하는 경우에만 오브젝트를 읽고 쓸 수 있도록 하려면 다음 정책에 나온 것처럼IpAddress 조건을 추가할 수 있습니다.

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "Grant permission ", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] "Condition": {"IpAddress": {"aws:SourceIp": "<Ip address>"} } ]}

모든 사용자에게 버킷 사용 권한 부여버킷 소유자가 아닌 사용자에게 버킷에 대한 사용 권한을 부여하려는 경우 관련 권한을변경할 리소스를 지정하고, 보안 주체 속성을 anybody(*)로 설정하고, 허용할 하나 이상의 작업을 지정할 수 있습니다.

다음 예에서는 모든 사용자에게 mybucket이라는 버킷의 오브젝트를 읽을 수 있는 권한을 부여하는 정책을 보여 줍니다.

{ "Version": "2012-10-17", "Id": "S3PolicyId2", "Statement": [ { "Sid": "statement2", "Effect": "Allow", "Principal": ["*"], "Action": [ "s3:GetObject" ], "Resource":[ "mybucket/*" ] } ]}

자동으로 오브젝트 생성 권한 할당버킷 정책을 사용하여 수집된 오브젝트 데이터에 대한 액세스를 자동으로 활성화할 수있습니다. 다음 예의 버킷 정책에서 user1 및 user2는 mybucket이라는 버킷에 하위리소스(즉, 오브젝트)를 생성할 수 있고 오브젝트 ACL을 설정할 수 있습니다. ACL을설정하는 권한이 있는 사용자는 다른 사용자에게 권한을 설정할 수 있습니다. 동일한작업에서 ACL을 설정하는 경우 오브젝트를 생성할 때 사전 구성된 ACL public-read를지정해야 한다는 것과 같은 조건을 설정할 수 있습니다. 이를 통해 생성되는 모든 오브젝트를 누구나 읽을 수 있습니다.

{ "Version": "2012-10-17", "Id": "S3PolicyId3", "Statement": [ {

S3

버킷 정책 시나리오 21

"Sid": "statement3", "Effect": "Allow", "Principal": ["user1", "user2"], "Action": [ "s3:PutObject, s3:PutObjectAcl" ], "Resource":[ "mybucket/*" ] "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}} } ]}

지원되는 버킷 정책 작업

다음 표에는 지원되는 사용 권한 키워드와 이러한 키워드를 통해 제어되는 버킷, 오브젝트 및 하위 리소스에 대한 작업이 정리되어 있습니다.

표 4 오브젝트 작업에 대한 사용 권한

사용 권한 키워드 지원되는 S3 작업

s3:GetObject. 버전 지정 버킷의 최신 버전에 적용됩니다.

GET Object, HEAD Object

s3:GetObjectVersion GET Object, HEAD Object이 사용 권한은 버전 번호를 지정하는 요청을 지원합니다.

s3:PutObject PUT Object, POST Object, Initiate Multipart Upload, UploadPart, Complete Multipart Upload PUT Object - Copy

s3:GetObjectAcl GET Object ACL

s3:GetObjectVersionAcl GET ACL(특정 오브젝트 버전에 해당)

s3:PutObjectAcl PUT Object ACL

s3:PutObjectVersionAcl PUT Object(특정 오브젝트 버전에 해당)

s3:DeleteObject DELETE Object

s3:DeleteObjectVersion DELETE Object(특정 오브젝트 버전에 해당)

s3:ListMultipartUploadParts List Parts

s3:AbortMultipartUpload Abort Multipart Upload

표 5 버킷 작업에 대한 사용 권한


s3:DeleteBucket DELETE Bucket

s3:ListBucket GET Bucket (List Objects), HEAD Bucket

s3:ListBucketVersions GET Bucket Object versions

s3:GetLifecycleConfiguration GET Bucket lifecycle

s3:PutLifecycleConfiguration PUT Bucket lifecycle

S3


표 6 버킷 하위 리소스 작업에 대한 사용 권한


s3:GetBucketAcl GET Bucket acl

s3:PutBucketAcl PUT Bucket acl

s3:GetBucketCORS GET Bucket cors

s3:PutBucketCORS PUT Bucket cors

s3:GetBucketVersioning GET Bucket versioning

s3:PutBucketVersioning PUT Bucket versioning

s3:GetBucketPolicy GET Bucket policy

s3:DeleteBucketPolicy DELETE Bucket policy

s3:PutBucketPolicy PUT Bucket policy

지원되는 버킷 정책 조건조건 요소는 정책이 적용되는 경우를 결정하는 조건을 지정하는 데 사용됩니다.

다음 표에는 ECS에서 지원되며 조건 표현식에 사용될 수 있는 조건 키가 정리되어 있습니다.

표 7 지원되는 일반 AWS 조건 키

키 이름 설명 해당 연산자

aws:CurrentTime 날짜/시간 조건을 확인하는 데 사용됩니다. 날짜 연산자

aws:EpochTime Epoch 또는 UNIX 시간 기준의 날짜를 사용하여 날짜/시간 조건을 확인하는 데 사용됩니다(날짜 조건 연산자 참조).

날짜 연산자

aws:principalType 현재 요청의 보안 주체(사용자, 계정, 통합 사용자 등) 유형을 확인하는 데 사용됩니다.

문자열 연산자

aws:SourceIp 요청자의 IP 주소를 확인하는 데 사용됩니다. 문자열 연산자

aws:UserAgent 요청자의 클라이언트 애플리케이션을 확인하는 데 사용됩니다.

문자열 연산자

aws:username 요청자의 사용자 이름을 확인하는 데 사용됩니다.

문자열 연산자

표 8 오브젝트 작업에 지원되는 S3 전용 조건 키입니다.

키 이름 설명 해당 사용 권한

s3:x-amz-acl 사용자가 오브젝트를 업로드할 때 특정 액세스 권한을 요구하는 조건을 설정합니다.

s3:PutObject,s3:PutObjectAcl,s3:PutObjectVersionAcl

s3:x-amz-grant-permission(명시적 사용 권한에 해당), 여기서 사용 권한은 read, write,

버킷 소유자는 이러한 키를 사용하여 특정 사용 권한을 요구

s3:PutObject,s3:PutObjectAcl,s3:PutObjectVersionAcl

S3

지원되는 버킷 정책 조건 23

표 8 오브젝트 작업에 지원되는 S3 전용 조건 키입니다. (계속)


read-acp, write-acp, full-control이 될 수 있습니다.

하는 조건을 추가할 수 있습니다.

s3:x-amz-server-side-encryption

사용자가 요청에 이 헤더를 지정하도록 요구합니다.

s3:PutObject,s3:PutObjectAcl

s3:VersionId 사용자가 특정 오브젝트 버전의 데이터만 액세스하도록 제한합니다.

s3:PutObject,s3:PutObjectAcl,s3:DeleteObjectVersion

표 9 버킷 작업에 지원되는 S3 전용 조건 키입니다.


s3:x-amz-acl 사용자가 오브젝트를 업로드할 때 특정 액세스 권한을 요구하는 조건을 설정합니다.

s3:CreateBucket,s3:PutBucketAcl

s3:x-amz-grant-permission(명시적 사용 권한에 해당), 여기서 사용 권한은 read, write,read-acp, write-acp, full-control이 될 수 있습니다.

버킷 소유자는 이러한 키를 사용하여 특정 사용 권한을 요구하는 조건을 추가할 수 있습니다.

s3:CreateBucket,s3:PutBucketAcl

s3:prefix 특정 접두사를 갖는 오브젝트키만 검색합니다.

s3:ListBucket,s3:ListBucketVersions

s3:delimiter 사용자가 Get Bucket (ListObject) 요청에서 구분 기호매개 변수를 지정하도록 요구합니다.


s3:max-keys 사용자 max-keys 매개 변수를지정하도록 요구함으로써 GetBucket (List Objects) 요청에대한 응답으로 ECS가 반환하는 키 개수를 제한합니다.


S3 확장ECS는 S3 API의 여러 가지 확장을 지원합니다.

확장 및 확장을 지원하는 API가 아래에 나와 있습니다.

l 바이트 범위 확장(24페이지)

l 보존(28페이지)

l 파일 시스템 활성화(29페이지)

l 메타데이터 검색(30페이지)

바이트 범위 확장

다음과 같은 바이트 범위 확장이 제공됩니다.

S3


l 오브젝트 내의 바이트 범위 업데이트(25페이지)l 오브젝트의 부분 덮어쓰기(26페이지)l 오브젝트에 데이터 추가(27페이지)l 오브젝트 내의 여러 바이트 범위 읽기(28페이지)

버전 지정 오브젝트에 대한 바이트 범위 작업(업데이트/추가/덮어쓰기)은 새 버전을생성하지 않으며 최신 버전이 업데이트됩니다.오브젝트의 이전 버전에 대한 바이트 범위 작업(업데이트/추가/덮어쓰기)은 최신 버전을 업데이트합니다.

오브젝트 내의 바이트 범위 업데이트S3 프로토콜에 대한 ECS 확장을 사용하여 오브젝트 내의 바이트 범위를 업데이트할수 있습니다.

부분적으로 오브젝트를 업데이트하는 것은 많은 경우에 매우 유용할 수 있습니다. 대용량 파일의 시작 부분에 저장된 바이너리 헤더를 수정하려는 경우를 예로 들 수 있습니다. Amazon 또는 기타 S3 호환 플랫폼에서는 전체 파일을 다시 전송해야 합니다.

바이트 범위 업데이트를 사용하는 예가 아래에 나와 있습니다. 이 예에서 object1 은The quick brown fox jumps over the lazy dog. 값을 갖습니다.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:04:40 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:04:40 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:04:28 GMTETag: 6Content-Type: application/jsonContent-Length: 43 The quick brown fox jumps over the lazy dog.

이 오브젝트 내에서 특정 바이트 범위를 업데이트하려면 업데이트할 오브젝트의 시작오프셋 및 종료 오프셋을 오브젝트 데이터 요청의 Range 헤더에 포함해야 합니다. 형식은 다음과 같습니다. Range: bytes=<startOffset>-<endOffset>.

아래 예에서 PUT 요청은 값 bytes=10-14를 갖는 Range 헤더를 포함하며, 이 값은 바이트 10, 11, 12, 13, 14가 이 요청에서 보낸 값으로 교체될 것을 나타냅니다. 여기서는 새값으로 green을 보냅니다.

PUT /bucket1/object1 HTTP/1.1Content-Length: 5Range: bytes=10-14ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:15:16 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=Accept-Encoding: gzip, deflate, compress

S3

바이트 범위 확장 25

green HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52aContent-Length: 0Date: Mon, 17 Jun 2013 20:15:16 GMT

오브젝트를 다시 읽으면 이제 The quick green fox jumps over the lazydog.가 새 값입니다. 이 오브젝트 내의 특정 바이트 범위가 업데이트되었습니다(단어brown이 green으로 교체됨).

GET /bucket1/object1 HTTP/1.1Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtuACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:16:00 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:16:00 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:15:16 GMTETag: 10Content-Type: application/jsonContent-Length: 43 The quick green fox jumps over the lazy dog.

오브젝트의 부분 덮어쓰기S3 프로토콜에 대한 ECS 확장을 사용하여 오브젝트의 일부를 덮어쓸 수 있습니다.

오브젝트의 일부를 덮어쓰려면 쓸 데이터와 시작 오프셋을 제공합니다. 이 요청에 포함된 데이터는 제시된 오프셋부터 쓰여지기 시작합니다. 형식은 다음과 같습니다.Range: <startingOffset>-.

예를 들어 오프셋 10에서 시작하여 데이터 brown cat을 쓰려면 다음 PUT 요청을 실행합니다.

PUT /bucket1/object1 HTTP/1.1Content-Length: 9Range: bytes=10-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:51:41 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=Accept-Encoding: gzip, deflate, compress brown cat HTTP/1.1 204 No ContentETag: 25x-amz-id-2: object1x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3b

S3


Content-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

오브젝트가 검색될 때 제시된 시작 오프셋에서 데이터의 일부분이 대체되고(greenfox가 brown cat로 바뀜) 최종 값은 다음과 같습니다. The quick brown catjumps over the lazy dog and cat.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTETag: 25Content-Type: application/jsonContent-Length: 51 The quick brown cat jumps over the lazy dog and cat.

오브젝트에 데이터 추가S3 프로토콜에 대한 ECS 확장을 사용하여 오브젝트에 데이터를 추가할 수 있습니다.

오브젝트에 데이터를 추가해야 하지만 정확한 바이트 오프셋을 결정하는 것이 효율적이거나 유용하지 않은 경우도 있습니다. 이러한 경우에 대비하여 ECS는 오프셋을 지정하지 않고 데이터를 오브젝트에 추가할 수 있는 기능을 제공합니다. 정확한 오프셋은응답을 통해 반환됩니다. 예를 들어 로그 파일에 줄을 추가하기 위해 Amazon 또는 기타S3 호환 플랫폼에서는 전체 로그 파일을 다시 전송해야 합니다.

특수 값이 bytes=-1-인 Range 헤더가 데이터를 오브젝트에 추가하는 데 사용될 수있습니다. 이렇게 하면 기존 오브젝트 크기를 알지 못해도 오브젝트가 확장될 수 있습니다. 형식은 다음과 같습니다. Range: bytes=-1-다음은 Range 값으로 bytes=-1-를 사용하여 기존 오브젝트에 추가하는 것을 보여 주는 샘플 요청입니다. 여기서는 요청을 통해 값 and cat을 보냅니다.

PUT /bucket1/object1 HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=Accept-Encoding: gzip, deflate, compress and cat HTTP/1.1 204 No ContentETag: 24x-amz-id-2: object1x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732Content-Length: 0Date: Mon, 17 Jun 2013 20:46:01 GMT

S3

바이트 범위 확장 27

오브젝트를 가져오면 and cat이 추가되어 있고 다음과 같은 전체 값을 확인할 수 있습니다. The quick green fox jumps over the lazy dog and cat.

GET /bucket1/object1 HTTP/1.1ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:56 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:46:56 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:46:01 GMTETag: 24Content-Type: application/jsonContent-Length: 51 The quick green fox jumps over the lazy dog and cat.

오브젝트 내의 여러 바이트 범위 읽기S3 프로토콜에 대한 ECS 확장을 사용하여 오브젝트 내의 여러 바이트 범위를 읽을 수있습니다.

오브젝트의 여러 부분을 읽는 것은 많은 경우에 매우 유용할 수 있습니다. 여러 비디오부분을 가져오려는 경우를 예로 들 수 있습니다. Amazon 또는 기타 S3 호환 플랫폼에서는 각 부분에 대해 서로 다른 요청을 전송해야 합니다.

object1이라는 오브젝트 내의 바이트 범위 2개를 읽으려면 Range:bytes==4-8,41-44에 대해 아래의 GET 요청을 실행합니다. 읽기 응답은 단어quick 및 lazy에 대한 것입니다.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcRange: bytes==4-8,41-44Content-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 206 Partial ContentDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: multipart/byteranges;boundary=bound04acf7f0ae3cccLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTContent-Length: 230 --bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 4-8/50quick--bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

보존

S3


ECS S3 헤드는 오브젝트가 지정된 기간 동안 삭제되거나 수정되지 않도록 보존합니다. 이는 ECS 확장으로 표준 S3 API에서는 사용할 수 없습니다.

보존은 다음과 같은 방법으로 설정할 수 있습니다.

오브젝트의 보존 기간

오브젝트의 보존 기간을 저장합니다. 보존 기간은 오브젝트의 x-emc-retention-period 헤더를 사용하여 설정합니다.

오브젝트의 보존 정책

오브젝트의 보존 정책을 설정하고 네임스페이스에 대해 정책과 연결된 기간을 설정할 수 있습니다. 정책을 사용하여 오브젝트 그룹의 보존 기간을 동일한 값으로설정할 수 있으며 정책을 변경하여 모든 오브젝트의 보존 기간을 변경할 수 있습니다. 정책을 사용하면 오브젝트에 보존 기간을 적용하는 것보다 훨씬 더 유연한 적용이 가능합니다. 또한 네임스페이스에 여러 개의 보존 정책을 설정하여 여러 오브젝트 그룹에 각각 다른 보존 기간을 적용할 수 있습니다.오브젝트의 x-emc-retention-policy 헤더를 사용하여 오브젝트에 적용되는보존 정책 및 정책 보존 기간은 ECS Portal 또는 ECS Management REST API를 사용하여 ECS 관리자가 설정해야 합니다.

버킷의 보존 기간

버킷에 대해 저장된 보존 기간을 사용하여 모든 오브젝트의 보존 기간을 설정하고,오브젝트 레벨 보존 기간 또는 정책을 사용하여 더 긴 보존이 필요한 경우 오브젝트별 설정을 제공할 수 있습니다. 보존 기간은 버킷의 x-emc-retention-period 헤더를 사용하여 설정합니다.

오브젝트를 수정하거나 삭제하려고 시도할 경우, 버킷 보존 기간과 오브젝트 기간 중더 긴 기간에 따라 작업 수행 가능 여부가 결정됩니다. 오브젝트 기간은 오브젝트에 직접 설정되거나 오브젝트 보존 정책을 사용하여 설정됩니다.

또한 ECS Management REST API 또는 ECS Portal에서 S3 버킷을 생성하고 버킷의 보존 기간을 설정할 수 있습니다.

수명주기(만료) 및 보존

ECS는 버전 관리가 활성화된 버킷과 버전 관리가 활성화되지 않은 버킷에 대해 S3LifecycleConfiguration을 지원합니다.

오브젝트를 수정 및 삭제해야 하나 일정 기간 동안 보존해야 하는 경우, 버킷에 대해 버전 관리를 활성화하고 수명주기 기능을 사용하여 오브젝트의 삭제된 버전을 ECS에서제거할 시기를 결정할 수 있습니다.

버전 관리 및 수명주기는 표준 S3 기능입니다. 그러나 수명주기 만료는 ECS 확장인 보존과 밀접하게 관련되어 있습니다. 수명주기가 보존 기간이 만료되기 전에 만료되는 경우, 보존 기간이 끝날 때까지 오브젝트가 삭제되지 않습니다.

파일 시스템 활성화

S3 버킷은 S3 프로토콜을 사용하여 쓴 파일을 NFS 및 HDFS 같은 파일 프로토콜을 사용하여 읽거나 쓸 수 있고, 그 반대 작업도 가능하도록 FS(Filesystem)를 활성화할 수도있습니다.

FS 액세스 활성화S3 프로토콜을 사용하여 버킷을 생성할 때 x-emc-file-system-access-enabled 헤더를 사용하여 FS 액세스를 활성화할 수 있습니다. ECS Portal(또는 ECS

S3

파일 시스템 활성화 29

Management REST API 사용)에서 버킷을 생성할 때도 파일 시스템 액세스를 활성화할수 있습니다.

FS 지원에 대한 제한 사항다음 제한 사항이 적용됩니다.

l 버킷에 FS가 활성화되어 있는 경우 S3 수명주기 관리를 활성화할 수 없습니다.

l 버킷에 FS가 활성화되어 있는 경우 보존을 사용할 수 없습니다.

FS에 대한 교차 헤드 지원교차 헤드 지원이란 한 프로토콜을 사용하여 쓴 오브젝트에 ECS에서 지원되는 다른 프로토콜을 사용하여 액세스하는 것을 말합니다. S3 헤드를 사용하여 쓴 오브젝트는NFS 및 HDFS 파일 시스템 프로토콜을 사용하여 읽고 쓸 수 있습니다.

교차 헤드 지원에서 중요한 측면은 오브젝트/파일 사용 권한이 프로토콜 간에 변환되는 방법과, 파일 시스템 액세스의 경우 사용자 및 그룹 개념이 오브젝트 프로토콜과 파일 프로토콜 간에 변환되는 방법입니다.

파일 시스템에서의 교차 헤드 지원에 대한 자세한 정보는 ECS Product Documentation페이지에 있는 ECS 관리 가이드에서 확인할 수 있습니다.

메타데이터 검색ECS S3 호환 API에서는 메타데이터 검색 확장을 제공합니다. 이를 통해 버킷에 포함된오브젝트를 메타데이터를 기준으로 인덱싱할 수 있고 메타데이터 인덱스를 쿼리하여오브젝트 및 이와 연결된 데이터를 찾을 수 있습니다.

일반적으로 메타데이터는 ECS S3 API를 사용하여 오브젝트와 연결될 수 있으며, 관심있는 오브젝트의 ID를 알고 있는 경우 이 오브젝트의 메타데이터를 읽을 수 있습니다.하지만 ECS 메타데이터 검색 기능 없이는 버킷에 포함된 오브젝트 세트를 일일이 확인하지 않고는 메타데이터를 기준으로 오브젝트를 찾는 것이 불가능합니다.

메타데이터는 사용자 메타데이터일 수도 있고 시스템 메타데이터일 수도 있습니다. 시스템 메타데이터는 ECS에서 정의되고 자동으로 오브젝트에 쓰여지며 사용자 메타데이터는 최종 사용자 요구 사항을 기반으로 클라이언트가 씁니다. 시스템 메타데이터와 사용자 메타데이터 모두 인덱싱할 수 있으며 메타데이터 검색 기준으로 사용할 수 있습니다. 인덱싱 가능한 메타데이터 값은 30개로 제한되며 버킷을 생성할 때 정의해야 합니다.

소규모 오브젝트(100KB 이하)의 경우, 데이터 수집률은 인덱스 키의 수가 증가함에 따라 조금씩 감소합니다. ECS 성능 백서에서 소규모 오브젝트에 메타데이터 인덱스를 사용한 데 따른 영향을 보여 주는 성능 테스트 데이터를 확인할 수 있습니다.

인덱싱된 메타데이터를 기준으로 오브젝트를 쿼리하면 쿼리와 일치하는 오브젝트와인덱싱된 메타데이터 값이 반환됩니다. 또한 반환되는 오브젝트와 관련된 모든 시스템및/또는 사용자 메타데이터를 반환하도록 선택할 수 있습니다. 시스템 메타데이터뿐만아니라 오브젝트에는 메타데이터 검색 결과의 일부로 반환될 수 있는 속성도 있습니다.사용 가능하고 인덱싱할 수 있는 시스템 메타데이터 값과 선택적으로 검색 쿼리 결과에반환될 수 있는 메타데이터 값은 여기에 나와 있습니다.

다음 항목에서는 메타데이터 검색 기능을 설정하고 사용할 때 수행해야 하는 단계를 설명합니다.

l 버킷에 메타데이터 인덱스 값 할당(31페이지)

l S3 프로토콜을 사용하여 오브젝트에 메타데이터 할당(33페이지)

S3




l 메타데이터 검색 쿼리 사용(34페이지)

버킷에 메타데이터 인덱스 값 할당ECS Portal 또는 ECS Management REST API를 사용하거나 S3 프로토콜을 사용하여버킷에 메타데이터 인덱스 값을 설정할 수 있습니다. 인덱스 값은 인덱싱하는 메타데이터 이름을 반영해야 하고 시스템 메타데이터나 사용자 메타데이터를 기반으로 할 수 있습니다.

사용 가능한 시스템 메타데이터 목록은 ECS 시스템 메타데이터 및 선택적 속성(40페이지)에 나와 있습니다.

인덱스 값은 버킷을 생성할 때 설정합니다. 버킷에 대해 인덱싱 사용을 비활성화할 수있지만, 개별 인덱스 값을 변경하거나 삭제할 수는 없습니다.

포털을 사용한 인덱스 값 설정

Manage > Bucket 페이지에서 버킷을 생성하고 버킷 생성 과정에서 인덱스 값을 할당할 수 있습니다. 자세한 내용은 ECS Product Documentation 페이지에 있는 ECS 관리가이드 항목을 참조하십시오.

ECS Management REST API를 사용한 인덱스 값 설정

인덱스 사용과 관련하여 ECS Management REST API에서 제공하는 방법은 아래 표에나와 있으며 API 참조에 이에 대한 링크가 나와 있습니다.

API 경로 설명

GET /object/bucket/searchmetadata 새 버킷에 할당할 수 있는 모든 시스템 메타데이터 키 이름을 나열합니다.

POST /object/bucket 지정된 버킷에 대해 인덱싱되는 메타데이터 인덱스 이름을 할당합니다. 인덱스 이름은 메서드 페이로드에서 제공됩니다.

GET /object/bucket 버킷의 목록을 가져옵니다. 각 버킷에 대한 버킷 정보에는 메타데이터 검색 정보가 표시됩니다.

GET /object/bucket/{bucketname}/info 선택된 버킷에 대한 버킷 세부 정보를 가져옵니다. 버킷 정보에는 메타데이터 검색 정보가포함됩니다.

DELETE /object/bucket/{bucketname}/searchmetadata

메타데이터 키를 사용한 인덱싱을 중지합니다.

예를 들어 사용 가능한 메타데이터 이름 목록 가져오기다음 예에서는 인덱싱에 사용할 수 있고 쿼리에서 반환될 수 있는 메타데이터 이름의전체 목록을 가져옵니다.

s3curl.pl --id myuser -- http://{host}:9020/?searchmetadata

쿼리 결과는 다음과 같습니다.

<MetadataSearchList xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <IndexableKeys>

S3

버킷에 메타데이터 인덱스 값 할당 31


<Key> <Name>LastModified</Name> <Datatype>datetime</Datatype> </Key> <Key> <Name>Owner</Name> <Datatype>string</Datatype> </Key> <Key> <Name>Size</Name> <Datatype>integer</Datatype> </Key> <Key> <Name>CreateTime</Name> <Datatype>datetime</Datatype> </Key> <Key> <Name>ObjectName</Name> <Datatype>string</Datatype> </Key> </IndexableKeys> <OptionalAttributes> <Attribute> <Name>ContentType</Name> <Datatype>string</Datatype> </Attribute> <Attribute> <Name>Expiration</Name> <Datatype>datetime</Datatype> </Attribute> <Attribute> <Name>ContentEncoding</Name> <Datatype>string</Datatype> </Attribute> <Attribute> <Name>Expires</Name> <Datatype>datetime</Datatype> </Attribute> <Attribute> <Name>Retention</Name> <Datatype>integer</Datatype> </Attribute> </OptionalAttributes></MetadataSearchList>

예를 들어 버킷에 대해 인덱싱된 키 목록 가져오기다음 예에서는 버킷에 대해 현재 인덱싱된 메타데이터 키 목록을 가져옵니다.

s3curl.pl --id myuser -- http://{host}:9020/mybucket/?searchmetadata

이 예의 결과는 다음과 같습니다.

<MetadataSearchList xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <MetadataSearchEnabled>true</MetadataSearchEnabled> <IndexableKeys> <Key> <Name>Size</Name> <Datatype>integer</Datatype> </Key> <Key> <Name>x-amz-meta-DAT</Name> <Datatype>datetime</Datatype> </Key>

S3


</IndexableKeys></MetadataSearchList>

S3 API를 사용한 값 설정

인덱스 사용과 관련하여 S3 API에서 제공하는 방법은 아래 표에 나와 있으며 API 참조에 이에 대한 링크가 나와 있습니다.

API 경로 설명

GET /?searchmetadata 새 버킷에 대한 인덱싱에 사용할 수 있는 모든시스템 메타데이터 이름을 나열합니다.

PUT /{bucket} -H x-emc-metadata-search:{name[;datatype],...}

헤더에 지정된 검색 메타데이터 키를 사용하여버킷을 생성합니다.

datatype은 사용자 메타데이터 키와 연결되어야 하지만, 시스템 메타데이터 키와는 연결되지 않아도 됩니다.

GET /{bucket}/?searchmetadata 버킷에 대해 현재 인덱싱된 메타데이터 키 목록을 가져옵니다.

예아래 예에서는 3개의 시스템 메타데이터 키와 2개의 사용자 메타데이터 키에 대한 메타데이터 인덱스를 설정하여 버킷을 생성하는 방법을 보여 줍니다.

s3curl.pl --id myuser --createbucket -- http://{host}:9020/mybucket -H "x-emc-metadata-search:Size,CreateTime,LastModified,x-amz-meta-STR;String,x-amz-meta-INT;Integer"

x-amz-meta-가 있는 새 오브젝트를 추가할 때 특수 문자가 포함된 값은 url로 인코딩하지 않아도 됩니다.

메타데이터 검색에 암호화 사용

버킷에 암호화가 사용된 경우 인덱싱된 오브젝트 메타데이터가 암호화되지 않은 형식으로 저장되므로 암호화된 버킷에 대한 메타데이터 검색을 항상 수행할 수 있습니다.

시스템 제공 키를 사용하여 암호화가 수행된 경우 쿼리에 의해 반환되는 오브젝트 메타데이터가 해독되어 텍스트 형식으로 표시됩니다. 하지만 사용자가 제공한 암호화 키를사용하여 데이터가 암호화된 경우 인덱싱되지 않은 메타데이터가 메타데이터 검색 쿼리에 의해 반환될 때 계속 암호화되어 있습니다. 사용자 암호화 키는 쿼리를 통해 제공될 수 없기 때문입니다.

S3 프로토콜을 사용하여 오브젝트에 메타데이터 할당최종 사용자는 "x-amz-meta-" 헤더를 사용하여 오브젝트에 사용자 메타데이터를 할당할 수 있습니다. 할당되는 값은 모든 텍스트 문자열이 될 수 있으며 대/소문자를 구분합니다.

S3

메타데이터 검색에 암호화 사용 33

메타데이터를 오브젝트 검색 기준으로 사용할 수 있도록 인덱싱할 때는(메타데이터 검색 기능) 데이터 유형을 데이터에 할당합니다. 메타데이터를 오브젝트에 쓸 때 클라이언트는 검색에 올바르게 사용될 수 있도록 데이터를 적절한 형식으로 써야 합니다.

데이터 유형은 다음과 같습니다.

문자열검색 인덱스 용어를 텍스트로 표시하면 메타데이터 문자열이 모든 검색 비교에서문자열로 처리됩니다.

정수검색 인덱스 용어를 정수로 표시하면 메타데이터 문자열이 모든 검색 비교에서 정수로 처리됩니다.

십진수검색 인덱스 용어를 십진수로 표시하면 "." 문자가 소수점으로 처리되도록 메타데이터 문자열이 십진수 값으로 변환됩니다.

날짜 및 시간

검색 인덱스 용어를 날짜 및 시간으로 표시하면 메타데이터 문자열이 yyyy-MM-ddTHH:mm:ssZ 형식의 날짜 및 시간으로 처리됩니다. 문자열이 날짜 및 시간으로처리되도록 하려면 메타데이터를 지정할 때 yyyy-MM-ddTHH:mm:ssZ 형식을 사용해야 합니다.

예아래 예에서는 S3 API를 사용하여 하나의 오브젝트와 이 오브젝트에 대한 2개의 사용자 메타데이터 값을 업로드합니다.

s3curl.pl --id myuser --put myfile -- http://{host}:9020/mybucket/file4 -i -H x-amz-meta-STR:String4 -H x-amz-meta-INT:407

메타데이터 검색 쿼리 사용메타데이터 검색 기능은 인덱싱된 메타데이터가 있는 오브젝트가 검색될 수 있도록 하는 풍부한 쿼리 언어를 제공합니다.

구문은 아래 표에 나와 있습니다.

API 구문 응답 본문

GET /{bucket}/?query={expression}&attributes={fieldname,…}&sorted={selector}&include_older_version={true|false}&max-keys=(num_keys)&marker=(marker value)

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <versionId>0</versionId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778025</value> </entry>

S3


API 구문 응답 본문

<entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778025</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>407</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>String4</value> </entry> </mdMap> </queryMds> <indexKey/> </object> <object ... </object> </ObjectMatches></BucketQueryResult>

표현식 키워드와 해당 의미는 아래에 정리되어 있습니다.

표현식표현식 형식:

[(]{condition1}[%20[and/or]%20{condition2}][)][%20[and/or]%20…]

여기서 "condition"은 다음 형식의 메타데이터 키 이름 필터입니다.

{selector} {operator}{argument},

예:

LastModified > 2015-09-02T11:22:00Z

selector

버킷과 연결된 검색 가능한 키 이름입니다.

Operator

연산자입니다. ==, >, <, <=, >= 중 하나입니다.

매개 변수

selector가 테스트되는 데 기준이 되는 값입니다.

S3

메타데이터 검색 쿼리 사용 35

attributes=[fieldname,...]

보고서에 포함할 선택적 오브젝트 속성을 지정합니다. 속성이 오브젝트에 대해 지정된 경우 해당 속성 값이 보고서에 포함됩니다. 선택적인 속성 값은 다음과 같습니다.

l ContentEncoding

l ContentType

l Retention

l Expiration

l Expires

또한 다음과 같이 검색 쿼리에 의해 반환되는 오브젝트와 관련된, 인덱싱되지 않은메타데이터를 반환할 수 있습니다.

ALL

반환되는 오브젝트와 관련된 시스템 및 사용자 메타데이터를 나열합니다.

ALL_SMD

반환되는 오브젝트와 관련된 시스템 메타데이터를 나열합니다.

ALL_UMD

반환되는 오브젝트와 관련된 사용자 메타데이터를 나열합니다.

sorted=[selector]

버킷에 연결된 검색 가능한 키 이름 하나를 지정합니다. 키 이름은 표현식에 표시된 키여야 합니다. &sorted=keyname을 지정하지 않으면 출력이 쿼리 표현식에 표시된 첫 번째 키 이름을 기준으로 정렬됩니다.

"or" 연산자가 표현식에 사용된 경우 정렬 순서는 규정되지 않습니다.

include-older-versions=[true|false]

버킷에 S3 버전 관리가 활성화되어 있는 경우 이를 true로 설정하면 표현식과 일치하는 오브젝트의 현재 버전 및 이전 버전이 반환됩니다. 기본값은 false입니다.

max-keys

반환해야 하는 쿼리와 일치하는 오브젝트의 최대 수입니다. 오브젝트가 max-keys보다 많을 경우, 더 많은 일치를 검색하는 데 사용할 수 있는 마커가 반환됩니다.

marker

이전 쿼리에서 반환되었으며 쿼리 일치 결과가 반환되어야 하는 지점을 나타내는마커입니다.

날짜 및 시간 쿼리

사용자 메타데이터의 날짜 및 시간 값은 ISO-8601 형식인 "yyyy-MM-dd'T'HH:mm:ssZ"로 지정되며 이 형식으로 ECS에서 보존됩니다. 메타데이터 쿼리도이 형식을 사용합니다. 하지만 ECS는 시스템 메타데이터의 날짜 및 시간 값을 1970년의 시작 시점 이후 경과된 밀리초에 해당하는 epoch 시간으로 보존합니다.

쿼리가 결과를 반환할 때는 ECS에서 보존하는 날짜 및 시간 형식을 그대로 반환합니다. 이 두 가지 형식에 대한 예가 아래에 나와 있습니다.

S3


사용자 메타데이터 업로드 헤더 예:

-H x-amz-meta-Foo:2015-11-30T12:00:00Z

사용자 및 시스템 쿼리 표현식 형식:

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z

쿼리 결과 조각 - 시스템 메타데이터

<key>createtime</key> <value>1449081777620</value>

쿼리 결과 조각 - 사용자 메타데이터

<key>x-amz-meta-Foo</key> <value>2015-11-30T12:00:00Z</value>

마커 및 max-keys를 사용하여 결과 페이지 매김

max-keys 쿼리 매개 변수를 사용하여 쿼리에서 반환할 오브젝트의 최대 수를 지정할수 있습니다.

아래 예에서는 오브젝트의 최대 수를 3으로 지정했습니다.

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z&max-keys=3

쿼리가 지정된 max-key보다 더 많은 오브젝트와 일치하는 경우, 쿼리와 일치하지만 반환되지 않은 다음 페이지 오브젝트를 반환하는 데 사용할 수 있는 마커도 반환됩니다.

아래 쿼리에서는 이전 쿼리에서 검색한 마커를 지정합니다.

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z&max-keys=3&marker=rO0ABXNyAD...

반환된 오브젝트가 오브젝트의 마지막 페이지인 경우, 응답 본문의 NextMarker에 NOMORE PAGES가 반환됩니다.

<NextMarker>NO MORE PAGES</NextMarker>

쿼리에 특수 문자 사용

ECS REST 서비스에서 특수 문자를 올바르게 수신하려면 url 인코딩을 사용해야 하며,ECS에서 쿼리를 구문 분석할 때 기호를 잘못 해석하지 않도록 하려면 따옴표 처리가필요할 수 있습니다. 예:

S3

메타데이터 검색 쿼리 사용 37

l x-amz-meta 값에 대해 쿼리하는 경우, 특수 문자를 url로 인코딩해야 합니다. 예를들어, "%" (ASCII 25 hex) 또는 "/" ( ASCII 2F)를 사용하는 경우 각각 %25 및 %2F로 인코딩해야 합니다.

l SQL 예약 문자가 있는 x-amz-meta 값에 대해 쿼리하는 경우, 예약 문자를 이스케이프해야 합니다. ECS에서 사용하는 SQL 파서가 예약 문자를 연산자로 간주하지않도록 하기 위해서입니다. 예: 'ab < cd'(즉, ECS에서 사용하는 SQL 파서가 이를연산자로 간주하지 않도록 서비스에 따옴표 쌍을 전달). SQL 예약 문자에는 비교연산자(=, <, >, +, -, !, ~)와 구문 구분 기호(쉼표, 세미콜론)가 포함됩니다.사용 중인 클라이언트에 따라 다양한 방법으로 따옴표 처리할 수 있습니다.S3curl.pl과 같은 Unix 명령줄 툴의 예는 다음과 같습니다.

?query="'ab+cd<ed;ef'"

이 경우 검색 값은 작은따옴표이며 이는 다시 큰따옴표로 묶여 있습니다.

메타데이터 검색 예

아래 예에서는 S3 API를 사용하여 버킷에서 특정 오브젝트 크기 및 일치하는 사용자 메타데이터 값을 검색합니다.

일부 REST 클라이언트에서는 "공백"을 url 코드 %20으로 인코딩해야 합니다.

s3curl.pl --id myuser -- "http://{host}:9020.mybucket?query=Size>1000%20and%20x-amz-meta-STR>=String4

검색과 일치하는 3개의 오브젝트가 결과로 반환됩니다.

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <versionId>0</versionId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778025</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778025</value> </entry> </mdMap>

S3


</queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>407</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>String4</value> </entry> </mdMap> </queryMds> <indexKey/> </object> <object> <objectName>file5</objectName> <objectId>1ad87d86ef558ca0620a26855662da1030f7d9ff1d4bbc7c2ffdfe29943b9150</objectId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778396</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778396</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>507</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>Sring5</value> </entry> </mdMap> </queryMds> <indexKey/> </object> </ObjectMatches></BucketQueryResult>

ECS Java SDK에서 메타데이터 검색 사용

3.0 SDK에는 3.0 이전 ECS에 연결할 경우 서명에서 "search" 및 "searchmetadata" 매개 변수를 제외시키는 옵션이 있습니다. 이러한 매개 변수는 ECS 2.x의 서명 계산에는포함되지 않았지만, 이제 보안을 강화하기 위해 계산에 포함됩니다.

다음 호환성 표에 메타데이터 검색 기능에 대한 SDK 지원이 나와 있습니다.

S3

ECS Java SDK에서 메타데이터 검색 사용 39

ECS 버전

2.x 3.x

SDK 2.x 지원 지원 안 함

SDK 3.x 지원 지원

ECS 시스템 메타데이터 및 선택적 속성시스템 메타데이터는 오브젝트 저장소에 저장된 각 오브젝트에 자동으로 연결됩니다.일부 시스템 메타데이터는 항상 채워져 있고 인덱스 키로 사용될 수 있으며, 다른 메타데이터는 항상 채워져 있지는 않지만, 제공되는 경우 메타데이터 검색 쿼리 결과에 반환될 수 있습니다.

시스템 메타데이터아래 표에 나와 있는 시스템 메타데이터는 메타데이터 검색 인덱스의 키로 사용될 수있습니다.

이름(별칭) 유형 설명

ObjectName string 오브젝트의 이름입니다.

Owner string 오브젝트 소유자의 ID입니다.

Size integer 오브젝트의 크기입니다.

CreateTime datetime 오브젝트가 생성된 시간입니다.

LastModified datetime 오브젝트가 마지막으로 수정된 시간 및 날짜입니다.

수정은 ECS S3 바이트 단위 업데이트 확장에서 지원되며, pure S3 API에서는 지원되지 않습니다.

선택적 메타데이터 속성선택적 시스템 메타데이터 속성은 오브젝트에 대해 채워지거나 채워지지 않을 수 있지만 검색 쿼리 결과와 함께 선택적으로 반환될 수 있습니다. 선택적 시스템 메타데이터속성은 아래 표에 나와 있습니다.

이름(별칭) 유형

ContentType string

만료 datetime

ContentEncoding string

만료 datetime

보존 integer

S3와 Swift의 상호 운용성S3 프로토콜과 Swift 프로토콜은 상호 운용 가능하여 S3 애플리케이션에서 Swift 버킷의 오브젝트에 액세스할 수 있고 Swift 애플리케이션에서 S3 버킷의 오브젝트에 액세스할 수 있습니다.

S3


S3 헤드를 사용하여 생성된 오브젝트를 Swift 헤드를 사용하여 액세스할 수 있고 또 그반대가 가능한지 여부를 고려할 때는 먼저 사용자가 해당 버킷(Swift에서는 컨테이너라고 함)에 액세스할 수 있는지를 고려해야 합니다. 버킷에는 버킷을 생성한 ECS 헤드에 따라 버킷 유형(예: S3 또는 Swift)이 할당되며, 애플리케이션이 Swift와 S3 버킷에모두 액세스할 수 있도록 하려면 오브젝트 사용자에게 각 버킷 유형에 대한 적절한 권한이 있는지 확인해야 합니다. Swift 버킷과 S3 버킷에 대한 사용 권한이 결정되는 방식이 서로 다르기 때문에 주의가 필요합니다.

버킷 정책을 사용하는 데는 S3와 Swift의 상호 운용성이 지원되지 않습니다. 버킷 정책은 S3 헤드를 사용한 버킷 액세스에만 적용되며 Swift API를 사용한 버킷 액세스에는적용되지 않습니다.

ECS에서는 동일한 오브젝트 사용자 이름에 S3 자격 증명과 Swift 자격 증명을 모두 지정할 수 있습니다. 즉, ECS 환경에서는 Swift 사용자로 인증되는 john이라는 사용자가john에게 액세스가 허용된 모든 S3 리소스에 액세스할 수 있습니다.

버킷 소유자가 되거나 ACL을 사용하여 버킷에 대한 사용 권한이 할당되면 리소스에 대한 액세스가 허용됩니다. 예를 들어 S3 사용자가 생성한 버킷은 해당 S3 사용자 이름이소유하고 관련 모든 권한을 가지며 동일한 이름을 가진 Swift 사용자도 이 버킷에 대한모든 권한을 갖게 됩니다.

소유자 이외의 사용자가 버킷에 액세스할 수 있도록 하려면 ACL을 사용하여 사용 권한을 할당할 수 있습니다. Swift 컨테이너에 대한 액세스 권한은 그룹 ACL(ECS에서는 사용자 지정 그룹 ACL)을 사용하여 부여될 수 있습니다. Swift 헤드는 그룹 ACL 사용 권한을 확인하기 전에 그룹 구성원 자격을 확인합니다. Swift 컨테이너는 admin 그룹이암시적으로 추가된 것으로 간주되며, 이에 따라 admin 그룹의 구성원인 모든 사용자(admin 사용자)가 다른 모든 admin 사용자의 컨테이너에 액세스할 수 있습니다.admin 사용자만 모든 컨테이너를 생성, 삭제 및 열거할 수 있는 권한을 가지며, admin사용자의 사용 권한은 해당 사용자가 속한 네임스페이스에만 적용 됩니다. S3 버킷에대한 액세스는 그룹 사용 권한이 아니라 사용자의 사용 권한(사용자 ACL)에 따라 결정됩니다. 버킷에 대한 액세스 권한을 확인하기 위해 S3 헤드는 사용자에게 해당 버킷에대한 ACL 사용 권한이 있는지 확인합니다. 아래 그림을 참조하십시오.

S3

S3와 Swift의 상호 운용성 41

S3 HEAD SWIFT HEAD

S3 APPLICATION

S3 BUCKET ACCESS SWIFT BUCKET ACCESS

GROUP ACLUSER ACL

SWIFT APPLICATION

ECS OBJECT USER

S3 KEY

SWIFT PASSWORDSWIFT GROUP

Swift user accessto Swift containerS3 user access

to S3 bucket

check Swift group ACLpermissions

Swift user access to S3 bucket

S3 user access to Swift container

check S3user ACL

CROSSHEAD

Swift는 그룹을 사용하여 리소스에 대한 액세스를 허용하기 때문에 S3 사용자가 Swift컨테이너에 액세스하려면 Swift 그룹(admin 그룹 또는 컨테이너에서 사용자 지정 그룹 ACL이 부여된 그룹)에도 할당되어야 합니다.

요약하면, S3 버킷에 액세스하려면 다음 조건 중 하나를 충족해야 합니다.

l Swift 또는 S3 사용자가 버킷 소유자여야 합니다.

l Swift 또는 S3 사용자가 버킷에 대한 사용자 ACL에 추가되어 있어야 합니다.

Swift 컨테이너에 액세스하려면 다음 조건 중 하나를 충족해야 합니다.

l S3 또는 Swift 사용자가 컨테이너 소유자여야 합니다.

l S3 사용자가 동시에 Swift 사용자이고 Swift 그룹에 추가되어 있어야 합니다. Swift그룹은 사용자 지정 그룹으로 추가되어야 합니다. 단, 사용자가 Swift admin 그룹의 구성원인 경우 이 그룹이 사용자 지정 그룹에 자동으로 추가됩니다.

l Swift 사용자가 컨테이너에 대한 그룹 ACL에 추가되어 있거나 Swift admin 그룹(자동으로 사용자 지정 그룹에 추가됨)에 속해 있어야 합니다.

S3 API를 통해 Swift DLO 오브젝트를 읽는 것은 작동하지 않습니다. 읽기 요청이 개별경로의 오브젝트를 다시 연결할 수 있는 X-Object-Manifest 메타데이터 키의 존재를 인식하지 않고 일반 코드 경로를 따르기 때문입니다.

S3


MPU 업로드 시 Swift list parts 작업이 실패합니다. '?uploadId=<uploadId>' 하위리소스를 이해하지 못하기 때문입니다.

암호 키 생성 및 관리ECS 오브젝트 서비스의 사용자가 서비스로 인증하려면 암호 키가 필요합니다.

다음 방법으로 암호 키를 생성하고 오브젝트 사용자에게 제공할 수 있습니다.

l 관리자가 키를 생성하여 오브젝트 사용자에게 배포합니다(오브젝트 사용자용 키생성(43페이지)).

l 도메인 사용자는 ECS Management REST API에서 제공되는 셀프 서비스 API를 사용하여 새 암호 키를 생성함으로써 오브젝트 사용자 계정을 생성합니다(S3 암호 키생성: 셀프 서비스(44페이지)).

한 명의 사용자가 2개의 암호 키를 가질 수 있습니다. 암호 키를 변경하는 경우(경우에따라 "롤오버"라고 함) 이전 키에 대해 만료 시간(분)을 설정할 수 있습니다. 만료 기간동안 두 키 모두 요청에 허용됩니다. 이에 따라 새 키를 사용하도록 애플리케이션을 업데이트할 수 있는 유예 기간이 제공됩니다.

오브젝트 사용자용 키 생성ECS Management 사용자는 오브젝트 사용자를 위해 암호 키를 생성할 수 있습니다.

l ECS Portal에서 암호 키 생성(43페이지)

l ECS Management REST API를 사용하여 S3 암호 키 생성(44페이지)

ECS 사용자에 대한 자세한 내용은 ECS Product Documentation 페이지에 있는 ECS 관리 가이드 항목을 참조하십시오.

ECS Portal에서 암호 키 생성ECS Portal에서 암호 키를 생성할 수 있습니다.

시작하기 전에

l ECS System Administrator 또는 Namespace Administrator여야 합니다.

System Administrator 사용자는 어떤 네임스페이스에 속한 오브젝트 사용자에 대해서도 암호 키를 생성할 수 있습니다. Namespace Administrator 사용자는 자신의 네임스페이스에 속한 오브젝트 사용자에 대한 암호 키를 생성할 수 있습니다.

절차

1. ECS Portal에서 Manage > Users 페이지를 선택합니다.

2. Object Users 테이블에서 New Object User를 선택하거나 Edit(암호 키를 할당하려는 기존 사용자에 대해)를 선택합니다.

3. S3의 경우 Generate & Add Password를 선택합니다.

사용자에 대한 암호 키를 변경하려는 경우 두 번째 암호 키를 생성하고 첫 번째키가 만료되는 시기를 지정할 수 있습니다.

4. 생성된 키를 복제하여 오브젝트 사용자에게 e-메일로 보냅니다.

S3

암호 키 생성 및 관리 43


ECS Management REST API를 사용하여 S3 암호 키 생성관리 사용자는 ECS Management REST API를 사용하여 S3 오브젝트 사용자를 위한 암호 키를 생성할 수 있습니다.

API는 다음과 같습니다.

API 경로 설명

/object/user-secret-keys/{uid} 오브젝트 사용자에 암호 키를 할당하고 암호키를 관리할 수 있는 API입니다.

Namespace Administrator는 네임스페이스에있는 사용자를 위한 키를 생성할 수 있습니다.System Administrator는 어떤 네임스페이스에있는 사용자에게든 키를 할당할 수 있습니다.

키를 변경하기 위해 두 번째 키를 할당하고 첫번째 키가 만료되는 시점을 지정할 수 있습니다.

API 호출에 대한 자세한 내용은 ECS API 참조 항목을 참조하십시오.

S3 암호 키 생성: 셀프 서비스ECS Management REST API는 인증된 도메인 사용자가 오브젝트 저장소에 액세스할수 있도록 암호 키 요청을 허용하는 기능을 제공합니다.

특정 ECS 관리 작업을 수행하기 위해 사용자 지정 클라이언트를 생성하려는 경우 ECSAPI 참조를 사용할 수 있습니다. 간단한 작업을 위해, 도메인 사용자는 curl 또는 브라우저 기반 HTTP 클라이언트를 사용하여 암호 키를 생성하는 API를 실행할 수 있습니다.

사용자가 object/secret-keys API를 실행하면 ECS가 오브젝트 사용자를 자동으로 생성하고 암호 키를 할당합니다.

API 경로 설명

/object/secret-keys S3 클라이언트 사용자가 네임스페이스 내에있는 오브젝트와 버킷에 액세스할 수 있도록새 암호 키를 생성할 수 있는 API입니다.

이를 셀프 서비스 API라고도 합니다.

/object/secret-keys에 대한 페이로드에는 기존 키 만료 시간이 옵션으로 포함될수 있습니다.

<secret_key_create_param> <existing_key_expiry_time_mins></existing_key_expiry_time_mins> </secret_key_create_param>

암호 키를 처음으로 생성하는 경우 existing_key_expiry_time_mins 매개 변수를 생략할 수 있고 호출은 다음과 같습니다.

POST object/secret-keys

Request body <?xml version="1.0" encoding="UTF-8"?> <secret_key_create_param/>

S3





Response <user_secret_key> <secret_key>...</secret_key> <key_timestamp>...</key_timestamp> <link rel="..." href="..." /> </user_secret_key>

셀프 서비스 키를 사용한 작업여기에 제시된 예를 참고하여 ECS Management REST API를 통해 암호 키를 생성하고읽고 관리할 수 있습니다.

암호 키에 대한 작업을 수행하려면 먼저 Management API로 인증해야 합니다. 여기에제시된 예에서는 curl 툴을 사용합니다.

l 도메인 사용자로 로그인(45페이지)

l 첫 번째 키 생성(45페이지)

l 두 번째 키 생성(46페이지)

l 키 확인(46페이지)

l 모든 암호 키 삭제(46페이지) .

도메인 사용자로 로그인도메인 사용자로 로그인하고 후속 요청의 인증에 사용할 수 있는 인증 토큰을 획득할수 있습니다.

curl -ik -u [email protected]:<Password> https://10.241.48.31:4443/loginHTTP/1.1 200 OKDate: Mon, 27 Apr 2015 17:29:38 GMTContent-Type: application/xmlContent-Length: 107Connection: keep-aliveX-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>[email protected]</user></loggedIn>

첫 번째 키 생성암호 키를 생성할 수 있습니다.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{}" https://10.241.48.31:4443/object/secret-keys | xmllint --format -

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user_secret_key> <link rel="self" href="/object/user-secret-keys/[email protected]"/> <secret_key>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</secret_key>

S3

S3 암호 키 생성: 셀프 서비스 45

<key_expiry_timestamp/> <key_timestamp>2015-04-27 17:39:13.813</key_timestamp></user_secret_key>

두 번째 키 생성두 번째 암호 키를 생성하고 첫 번째 키에 대한 만료 시점을 설정할 수 있습니다.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{\"existing_key_expiry_time_mins\": \"10\"}" https://10.241.48.31:4443/object/secret-keys | xmllint --format -

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user_secret_key> <link rel="self" href="/object/user-secret-keys/[email protected]"/> <secret_key>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</secret_key> <key_expiry_timestamp/> <key_timestamp>2015-04-27 17:40:12.506</key_timestamp></user_secret_key>

키 확인자신에게 할당된 키를 확인할 수 있습니다. 이 경우에는 만료 날짜/시간이 있는 첫 번째키를 포함하여 두 개의 키가 있습니다.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" https://10.241.48.31:4443/object/secret-keys | xmllint --format -<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user_secret_keys> <secret_key_1>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</secret_key_1> <secret_key_2>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</secret_key_2> <key_expiry_timestamp_1>2015-04-27 17:50:12.369</key_expiry_timestamp_1> <key_expiry_timestamp_2/> <key_timestamp_1>2015-04-27 17:39:13.813</key_timestamp_1> <key_timestamp_2>2015-04-27 17:40:12.506</key_timestamp_2> <link rel="self" href="/object/secret-keys"/></user_secret_keys>

모든 암호 키 삭제암호 키를 삭제한 후 다시 생성해야 할 경우, 다음을 사용할 수 있습니다.

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{}" https://10.241.48.31:4443/object/secret-keys/deactivate

S3


S3 서비스로 인증ECS S3 서비스에서 Signature Version 2와 Signature Version 4를 사용하여 인증할 수있습니다. 이 항목에서는 인증 프로세스에서 ECS와 관련된 측면을 살펴봅니다.

Amazon S3는 모든 요청에 반드시 있어야 하는 인증 헤더를 사용하여 사용자를 식별하고 요청에 서명을 제공합니다. 인증 헤더의 형식은 Signature Version 2 인증과Signature Version 4 인증 간에 서로 다릅니다.

인증 헤더를 생성하려면 AWS 액세스 키 ID와 암호 액세스 키가 필요합니다. ECS에서AWS 액세스 키 ID는 ECS 사용자 ID(UID)에 매핑됩니다. AWS 액세스 키 ID는 20개의문자(S3 브라우저 등의 일부 S3 클라이언트에서 이를 확인함)로 구성되지만 ECS 데이터 서비스에는 이러한 제한이 없습니다.

Signature V2와 Signature V4를 사용한 인증이 다음에 나와 있습니다.

l Signature V2를 사용한 인증l Signature V4를 사용한 인증

다음 참고 사항이 적용됩니다.

l ECS 오브젝트 데이터 서비스에서 UID는 암호 키 2개를 사용하여 ECS API 또는ECS UI를 통해 구성될 수 있습니다. ECS 데이터 서비스는 첫 번째 암호 키의 사용을 시도하며, 계산된 서명이 일치하지 않으면 두 번째 암호 키의 사용을 시도합니다. 두 번째 키가 실패하면 요청은 거부됩니다. 암호 키를 추가하거나 변경할 경우사용자는 모든 데이터 서비스 노드를 새 암호 키로 새로 고칠 수 있도록 2분을 기다린 후에 새 암호 키를 사용해야 합니다.

l ECS 데이터 서비스에서 네임스페이스 또한 HMAC 서명 계산에 포함됩니다.

Signature V2를 사용한 인증

Signature V2를 사용하는 경우 인증 헤더는 다음과 같습니다.

Authorization: AWS <AWSAccessKeyId>:<Signature>

예:

GET /photos/puppy.jpg?AWSAccessKeyId=user11&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1Host: myco.s3.amazonaws.comDate: Mon, 26 Mar 2007 19:37:58 +0000

Signature V2를 사용한 인증이 다음에 설명되어 있습니다.

l http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

Signature V4를 사용한 인증

Signature V4를 사용하는 경우 인증 헤더는 다음과 같습니다.

Authorization: AWS4-HMAC-SHA256 Credential=user11/20130524/us/s3/aws4_request, SignedHeaders=host;range;x-amz-date,Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

S3

S3 서비스로 인증 47

http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

자격 증명 구성 요소는 액세스 키 ID와 그 뒤에 나오는 자격 증명 범위로 구성됩니다. 자격 증명 범위는 날짜/지역/서비스 이름/종료 문자열로 구성됩니다. ECS의 경우 서비스 이름은 항상 s3이며 지역은 모든 문자열일 수 있습니다. 서명을 컴퓨팅할 때 ECS는클라이언트가 전달하는 지역 문자열을 사용합니다.

Signature V4를 사용한 인증이 다음에 설명되어 있습니다.

l http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html 및

l http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

Signature V4를 사용한 PUT 버킷 요청의 예가 아래에 나와 있습니다.

PUT /bucket_demo HTTP/1.1x-amz-date: 20160726T033659ZAuthorization: AWS4-HMAC-SHA256 Credential=user11/20160726/us/s3/aws4_request,SignedHeaders=host;x-amz-date;x-emc-namespace,Signature=e75a150daa28a2b2f7ca24f6fd0e161cb58648a25121d3108f0af5c9451b09cex-emc-namespace: ns1x-emc-rest-client: TRUEx-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855Content-Length: 0Host: 10.247.195.130:9021Connection: Keep-AliveUser-Agent: Apache-HttpClient/4.2.1 (java 1.5)

응답:

HTTP/1.1 200 OKDate: Tue, 26 Jul 2016 03:37:00 GMTServer: ViPR/1.0x-amz-request-id: 0af7c382:156123ab861:4192:896x-amz-id-2: 3e2b2280876d444d6c7215091692fb43b87d6ad95b970f48911d635729a8f7ffLocation: /bucket_demo_2016072603365969263Content-Length: 0

ECS에 s3curl 사용ECS에 s3curl을 사용하려면 수정된 버전의 s3curl이 필요합니다.

ECS 사용자 지정 헤더(x-emc)를 사용하는 경우 인증 헤더의 서명 요소에 사용자 지정헤더가 포함되도록 구성해야 합니다. 또한, ECS 3.0 이상에 연결하는 경우 "search" 및"searchmetadata" 매개 변수가 서명 계산에 포함되어야 합니다.

이러한 조건을 처리하도록 수정된 ECS용 s3curl 버전은 EMCECS Git Repository에서얻을 수 있습니다.

SDK를 사용하여 S3 서비스에 액세스ECS S3 서비스와 통신하는 애플리케이션을 개발할 경우 개발 작업에 도움이 되는 다양한 SDK를 활용할 수 있습니다.

ECS 커뮤니티는 사용 가능한 여러 클라이언트에 대한 정보와 활용 지침을 제공합니다. ECS 커뮤니티: 개발자 리소스

S3


http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

https://github.com/EMCECS/s3curl

https://community.emc.com/community/products/ecs#developer

다음 항목에서는 Amazon S3 SDK와 ECS Java SDK를 사용하는 방법에 대해 설명합니다.

l Java Amazon SDK 사용(49페이지)

l ECS용 Java SDK 클라이언트(51페이지)

ECS API 확장(S3 확장(24페이지) 참조)을 사용할 경우 ECS Java SDK에서 제공하는지원 기능을 활용할 수 있습니다. ECS 확장에 대한 지원이 필요하지 않거나 이 확장을사용하는 기존 애플리케이션이 있으면 Amazon Java SDK를 사용하면 됩니다.

ECS Java SDK와 메타데이터 검색 확장 간 호환성은 ECS Java SDK에서 메타데이터 검색 사용 (39페이지)에 설명되어 있습니다.

Java Amazon SDK 사용Java S3 SDK를 사용하여 ECS 오브젝트 스토리지에 액세스할 수 있습니다.

기본적으로 AmazonS3Client 클라이언트 오브젝트는 amazon.com에 대해 직접적으로작동하도록 코딩됩니다. 이 섹션에서는 ECS에 대해 작동하도록 AmazonS3Client를 설정하는 방법을 보여 줍니다.

AmazonS3Client 오브젝트의 인스턴스를 생성하려면 이 오브젝트에 자격 증명을 전달해야 합니다. 이를 위해 AWSCredentials 오브젝트를 생성하고 이 오브젝트에 AWS 액세스 키(ECS 사용자 이름) 및 생성된 ECS 암호 키를 전달합니다.

다음 코드는 이러한 설정 방법을 보여 줍니다.

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));

기본적으로 Amazon 클라이언트는 Amazon WebService에 연결하려고 시도합니다. 이동작을 재정의하고 ECS에 연결하려면 특정 엔드포인트를 설정해야 합니다.

엔드포인트는 setEndpoint 메서드를 사용하여 설정할 수 있습니다. 엔드포인트에 대해지정된 프로토콜은 클라이언트가 HTTP 포트(9020) 또는 HTTPS 포트(9021) 중 어느것을 대상 포트로 해야 하는지 지시합니다.

HTTPS 포트를 사용할 경우 애플리케이션의 JDK에서 ECS 인증서를 성공적으로 검증할 수 있도록 설정해야 합니다. 그렇지 않으면 클라이언트에서 SSL 검증 오류가 발생하고 연결에 실패합니다.

아래 코드에서 클라이언트는 HTTP를 통해 ECS에 액세스하는 데 사용됩니다.

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));client.setEndpoint("http://ecs1.emc.com:9020");

S3

Java Amazon SDK 사용 49

경로 스타일 주소 지정(ecs1.emc.com/mybucket)을 사용하는 경우, 아래와 같이setPathStyleAccess 옵션을 설정해야 합니다.

S3ClientOptions options = new S3ClientOptions();options.setPathStyleAccess(true);

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));client.setEndpoint("http://ecs1.emc.com:9020");client.setS3ClientOptions(options);

다음 코드는 버킷의 오브젝트를 나열하는 방법을 보여 줍니다.

ObjectListing objects = client.listObjects("mybucket");for (S3ObjectSummary summary : objects.getObjectSummaries()) { System.out.println(summary.getKey()+ " "+summary.getOwner());}

CreateBucket 작업은 영역 지정이 필요하다는 점에서 다른 작업과 차이가 있습니다.S3의 경우 영역은 버킷이 생성되어야 하는 데이터 센터를 가리킵니다. 그러나 ECS는영역을 지원하지 않습니다. 그러므로 CreateBucket 작업을 호출할 때는 표준 영역을지정하여 AWS 클라이언트가 Amazon CloudFront에서 Amazon Region 구성 파일을 다운로드하지 못하도록 합니다.

client.createBucket("mybucket", "Standard");

ECS S3 데이터 서비스와의 통신, 버킷 생성 및 오브젝트 조작에 대한 전체적인 예제가아래에 나와 있습니다.

public class Test { public static String uid = "root"; public static String secret = "KHBkaH0Xd7YKF43ZPFbWMBT9OP0vIcFAMkD/9dwj"; public static String viprDataNode = "http://ecs.yourco.com:9020";

public static String bucketName = "myBucket"; public static File objectFile = new File("/photos/cat1.jpg");

public static void main(String[] args) throws Exception {

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));

S3ClientOptions options = new S3ClientOptions(); options.setPathStyleAccess(true);

AmazonS3Client client = new AmazonS3Client(credentials); client.setEndpoint(viprDataNode); client.setS3ClientOptions(options);

client.createBucket(bucketName, "Standard"); listObjects(client);

client.putObject(bucketName, objectFile.getName(), objectFile); listObjects(client);

client.copyObject(bucketName,objectFile.getName(),bucketName,

S3


"copy-" + objectFile.getName()); listObjects(client); }

public static void listObjects(AmazonS3Client client) { ObjectListing objects = client.listObjects(bucketName); for (S3ObjectSummary summary : objects.getObjectSummaries()) { System.out.println(summary.getKey()+ " "+summary.getOwner()); } }}

ECS용 Java SDK 클라이언트ECS Java SDK는 Amazon S3 Java SDK를 기반으로 구축되며 ECS API 확장을 지원합니다.

다음은 ViPRS3client 사용의 예입니다.

package com.emc.ecs.sample;

import com.amazonaws.util.StringInputStream;import com.emc.vipr.services.s3.ViPRS3Client;

public class BucketCreate {

private ViPRS3Client s3;

public BucketCreate() {

URI endpoint = new URI(“http://ecs.yourco.com:9020”); String accessKey = “[email protected]”; String secretKey = “pcQQ20rDI2DHZOIWNkAug3wK4XJP9sQnZqbQJev3”; BasicAWSCredentials creds = new BasicAWSCredentials(accessKey, secretKey); ViPRS3Client client = new ViPRS3Client(endpoint, creds);

}

public static void main(String[] args) throws Exception { BucketCreate instance = new BucketCreate(); instance.runSample(); } public void runSample() { String bucketName="mybucket"; String key1 = "test1.txt"; String content = "Hello World!"; try { s3.createBucket(bucketName); s3.putObject(bucketName, key1, new StringInputStream(content), null); } catch (Exception e) { }

S3

ECS용 Java SDK 클라이언트 51

}}

S3


2부

OpenStack Swift

2장, "OpenStack Swift"

OpenStack Swift 53

OpenStack Swift


2장

OpenStack Swift

l ECS의 OpenStack Swift 지원 기능.................................................................... 56l 지원되는 OpenStack Swift 작업........................................................................ 56l Swift 확장..........................................................................................................58l Swift 바이트 범위 확장...................................................................................... 58l 보존................................................................................................................... 62l 파일 시스템 지원................................................................................................63l S3와 Swift의 상호 운용성.................................................................................. 63l OpenStack Swift 인증........................................................................................64l 컨테이너에 대한 인증.........................................................................................72

OpenStack Swift 55

ECS의 OpenStack Swift 지원 기능ECS는 OpenStack Swift API를 지원하여 OpenStack 환경의 Swift를 대체할 수 있습니다. 이 부분에서는 지원되는 작업과 권한 부여 및 인증을 위한 메커니즘에 대해 설명합니다.

OpenStack Swift Service는 다음 포트에서 사용할 수 있습니다.

프로토콜 포트

HTTP 9024

HTTPS 9025

ECS는 OpenStack Swift API를 지원하며 이 API를 지원하는 애플리케이션에 사용할 수있습니다. 다음 항목에서는 지원되는 메서드, ECS 확장 기능 및 인증 메커니즘을 설명합니다.

l 지원되는 OpenStack Swift 작업(56페이지)

l Swift 확장(58페이지)

l OpenStack Swift 인증(64페이지)

l 컨테이너에 대한 인증(72페이지)

다음은 OpenStack Swift API의 사용을 보여 주는 예입니다.

l OpenStack API 예

OpenStack 환경에서 ECS를 OpenStack Swift 구성 요소의 대체 요소로 사용하거나 기존에 설치된 OpenStack Swift와 함께 사용할 수 있습니다. ECS는 모든 OpenStack 배포판과 함께 사용할 수 있지만 Mirantis OpenStack 9.1과 함께 테스트를 거쳤습니다. 참고로, ECS는 최종 사용자 오브젝트 스토리지를 위한 Swift 대체 요소로 테스트되었으며 Glance 백엔드로는 테스트되지 않았습니다.

ECS와 함께 OpenStack을 사용하려면 OpenStack 사용자를 인증할 수 있도록 ECS를구성해야 합니다. 인증 구성에 대한 자세한 내용은 ECS Keystone V3 통합을 사용한 인증 섹션을 참조하십시오.

지원되는 OpenStack Swift 작업다음 섹션에는 ECS에서 지원되는 OpenStack REST API 요청이 나열되어 있습니다.

l 지원되는 OpenStack Swift 호출(56페이지)

l 지원되지 않는 OpenStack Swift 호출(58페이지)

이 정보는 OpenStack API 참조 설명서의 오브젝트 스토리지 API V1 섹션에서 발췌한것입니다.

지원되는 OpenStack Swift 호출다음 OpenStack Swift REST API 호출이 ECS에서 지원됩니다.

표 10 지원되는 OpenStack Swift 호출

방법 경로 설명

GET v1/{account} 이름순으로 정렬된 기존 스토리지 컨테이너의 목록을가져옵니다.

OpenStack Swift


http://docs.openstack.org/api/openstack-object-storage/1.0/content/ch_object-storage-dev-troubleshooting.html

http://developer.openstack.org/api-ref-objectstorage-v1.html

표 10 지원되는 OpenStack Swift 호출 (계속)


POST v1/{account} 맞춤형 메타데이터 헤더를 계정 레벨 URI와 연결하여계정 메타데이터를 생성하거나 업데이트합니다. 이러한 헤더는 X-Account-Meta-* 형식을 갖추어야 합니다.

GET v1/{account}/{container}

컨테이너에 저장된 오브젝트의 목록을 가져옵니다.

PUT v1/{account}/{container}

컨테이너를 생성합니다.

DELETE v1/{account}/{container}

빈 컨테이너를 삭제합니다.

POST v1/{account}/{container}

맞춤형 메타데이터 헤더를 컨테이너 레벨 URI와 연결하여 임의의 컨테이너 메타데이터를 생성하거나 업데이트합니다. 이러한 헤더는 X-Container-Meta-* 형식을 갖추어야 합니다.

HEAD v1/{account}/{container}

컨테이너 메타데이터를 가져옵니다. 현재는 오브젝트개수 및 사용된 바이트를 포함하지 않습니다.사용자에게 관리자 권한이 필요합니다.

GET v1/{account}/{container}/{object}

오브젝트의 데이터를 가져옵니다.

ECS 3.0 이전에 세그먼트가 생성된 경우 SLO(StaticLarge Object)에 대한 GET range가 작동하지 않습니다.

PUT v1/{account}/{container}/{object}

오브젝트의 컨텐츠 및 메타데이터를 쓰거나 덮어씁니다.소스를 지정하기 위한 X-Copy-From 헤더를 사용하여 기존 오브젝트를 다른 오브젝트에 복제하는 데 사용됩니다.

DLO(Dynamic Large Object) 또는 SLO의 경우, 여기에 설명된 바와 같이 오브젝트가 매니페스트일 수 있습니다.

DELETE v1/{account}/{container}/{object}

스토리지 시스템에서 영구적으로 오브젝트를 제거합니다. COPY 명령과 결합하여 COPY를 먼저 사용한후 DELETE를 사용하면 오브젝트를 효과적으로 이동할 수 있습니다.

HEAD v1/{account}/{container}/{object}

오브젝트 메타데이터 및 다른 표준 HTTP 헤더를 가져옵니다.

POST v1/{account}/{container}/{object}

임의의 오브젝트 메타데이터를 설정하고 덮어씁니다.이러한 메타데이터는 X-Object-Meta-* 형식을 갖추어야 합니다. 오브젝트 만료를 위한 X-Delete-At 또는X-Delete-After가 이 작업에 의해 할당될 수도 있습니다. 그러나 Content-Type 등의 다른 헤더는 이 작업에의해 변경될 수 없습니다.

OpenStack Swift

지원되는 OpenStack Swift 작업 57

http://docs.openstack.org/developer/swift/api/large_objects.html#static-large-objects

표 11 추가 기능

기능 참고

임시 URL ECS는 사용자가 자격 증명 없이도 오브젝트에 대한 액세스 권한을 부여받을 수 있도록 임시 URL을 사용할 수 있도록 지원합니다.

추가 정보는 여기에서 찾을 수 있습니다.

지원되지 않는 OpenStack Swift 호출다음 OpenStack Swift REST API 호출은 ECS에서 지원되지 않습니다.

표 12 지원되지 않는 OpenStack Swift 호출


COPY v1/{account}/{container}/{object}

Copy 작업은 PUT v1/{account}/{container}/{object}를 X-Copy-From 헤더와 함께 사용하여 수행할 수 있습니다.

HEAD v1/{account} 계정 메타데이터를 가져옵니다. 저장된 바이트(X-Account-Bytes-Used)에 대해서는 0을 반환하므로 완벽하게 지원되지는 않습니다.

Swift 확장ECS는 Swift API의 여러 가지 확장을 지원합니다.


l Swift 바이트 범위 확장(58페이지)

l 보존(62페이지)

l 파일 시스템 지원(63페이지)

Swift 바이트 범위 확장다음과 같은 바이트 범위 확장이 제공됩니다.

l 오브젝트 내의 바이트 범위 업데이트(58페이지)

l 오브젝트의 부분 덮어쓰기(60페이지)

l 오브젝트에 데이터 추가(61페이지)

l 오브젝트 내의 여러 바이트 범위 읽기(62페이지)

오브젝트 내의 바이트 범위 업데이트Swift 프로토콜에 대한 ECS 확장을 사용하여 오브젝트 내의 바이트 범위를 업데이트할수 있습니다.

부분적으로 오브젝트를 업데이트하는 것은 많은 경우에 매우 유용합니다. 대용량 파일의 시작 부분에 저장된 바이너리 헤더를 수정하려는 경우를 예로 들 수 있습니다. Swift또는 기타 Swift 호환 플랫폼에서는 전체 파일을 다시 전송해야 합니다.

OpenStack Swift


https://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

바이트 범위 업데이트를 사용하는 예가 아래에 나와 있습니다. 이 예에서 object1 은The quick brown fox jumps over the lazy dog. 값을 갖습니다.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:04:40 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:04:40 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:04:28 GMTETag: 6Content-Type: application/jsonContent-Length: 43 The quick brown fox jumps over the lazy dog.

이 오브젝트 내에서 특정 바이트 범위를 업데이트하려면 업데이트할 오브젝트의 시작오프셋 및 종료 오프셋을 오브젝트 데이터 요청의 Range 헤더에 포함해야 합니다. 형식은 다음과 같습니다. Range: bytes=<startOffset>-<endOffset>.

아래 예에서 PUT 요청은 값 bytes=10-14를 갖는 Range 헤더를 포함하며, 이 값은 바이트 10, 11, 12, 13, 14가 이 요청에서 보낸 값으로 교체됨을 나타냅니다. 여기서는 새 값으로 green을 보냅니다.

PUT /container1/object1 HTTP/1.1Content-Length: 5Range: bytes=10-14ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:15:16 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=Accept-Encoding: gzip, deflate, compress green HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52aContent-Length: 0Date: Mon, 17 Jun 2013 20:15:16 GMT

오브젝트를 다시 읽으면 이제 The quick green fox jumps over the lazydog.가 새 값입니다. 이 오브젝트 내의 특정 바이트 범위가 업데이트되었습니다(단어brown이 green으로 교체됨).

GET /container1/object1 HTTP/1.1Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtuACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:16:00 -0000x-emc-namespace: emcContent-Type: application/octet-stream

OpenStack Swift

오브젝트 내의 바이트 범위 업데이트 59

Authorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:16:00 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:15:16 GMTETag: 10Content-Type: application/jsonContent-Length: 43 The quick green fox jumps over the lazy dog.

오브젝트의 부분 덮어쓰기Swift 프로토콜에 대한 ECS 확장을 사용하여 오브젝트의 일부를 덮어쓸 수 있습니다.

오브젝트의 일부를 덮어쓰려면 쓸 데이터와 시작 오프셋을 제공합니다. 이 요청에 포함된 데이터는 제시된 오프셋부터 쓰여지기 시작합니다. 형식은 다음과 같습니다.Range: <startingOffset>-예를 들어 오프셋 10에서 시작하여 데이터 brown cat을 쓰려면 다음 PUT 요청을 실행합니다.

PUT /container1/object1 HTTP/1.1Content-Length: 9Range: bytes=10-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:51:41 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=Accept-Encoding: gzip, deflate, compress brown cat HTTP/1.1 204 No ContentETag: 25x-amz-id-2: object1x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

오브젝트가 검색될 때 제시된 시작 오프셋에서 데이터의 일부분이 대체되고(greenfox가 brown cat로 바뀜) 최종 값은 다음과 같습니다. The quick brown catjumps over the lazy dog and cat.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTETag: 25Content-Type: application/jsonContent-Length: 51

OpenStack Swift


The quick brown cat jumps over the lazy dog and cat.

오브젝트에 데이터 추가Swift 프로토콜에 대한 ECS 확장을 사용하여 오브젝트에 데이터를 추가할 수 있습니다.

오브젝트에 데이터를 추가해야 하지만 정확한 바이트 오프셋을 결정하는 것이 효율적이거나 유용하지 않은 경우도 있습니다. 이러한 경우에 대비하여 ECS는 오프셋을 지정하지 않고 데이터를 오브젝트에 추가할 수 있는 기능을 제공합니다. 정확한 오프셋은응답을 통해 반환됩니다. 예를 들어 로그 파일에 줄을 추가하기 위해 Swift 또는 기타Swift 호환 플랫폼에서는 전체 로그 파일을 다시 전송해야 합니다.

특수 값이 bytes=-1-인 Range 헤더가 데이터를 오브젝트에 추가하는 데 사용될 수있습니다. 이렇게 하면 기존 오브젝트 크기를 알지 못해도 오브젝트가 확장될 수 있습니다. 형식은 다음과 같습니다. Range: bytes=-1-다음은 Range 값으로 bytes=-1-를 사용하여 기존 오브젝트에 추가하는 것을 보여 주는 샘플 요청입니다. 여기서는 요청을 통해 값 and cat을 보냅니다.

PUT /container1/object1 HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=Accept-Encoding: gzip, deflate, compress and cat HTTP/1.1 204 No ContentETag: 24x-amz-id-2: object1x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732Content-Length: 0Date: Mon, 17 Jun 2013 20:46:01 GMT


GET /container1/object1 HTTP/1.1ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:56 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:46:56 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:46:01 GMTETag: 24Content-Type: application/jsonContent-Length: 51

OpenStack Swift

오브젝트에 데이터 추가 61

The quick green fox jumps over the lazy dog and cat.

오브젝트 내의 여러 바이트 범위 읽기Swift 프로토콜에 대한 ECS 확장을 사용하여 오브젝트 내의 여러 바이트 범위를 읽을수 있습니다.

오브젝트의 여러 부분을 읽는 것은 많은 경우에 매우 유용합니다. 여러 비디오 부분을가져오려는 경우를 예로 들 수 있습니다. Swift 또는 기타 Swift 호환 플랫폼에서는 각부분에 대해 서로 다른 요청을 전송해야 합니다.

object1이라는 오브젝트 내의 바이트 범위 2개를 읽으려면 Range:bytes==4-8,41-44에 대해 아래의 GET 요청을 실행합니다. 읽기 응답은 단어quick 및 lazy에 대한 것입니다.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcRange: bytes==4-8,41-44Content-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 206 Partial ContentDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: multipart/byteranges;boundary=bound04acf7f0ae3cccLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTContent-Length: 230 --bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 4-8/50quick--bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

보존

ECS Swift 헤드는 오브젝트가 지정된 기간 동안 삭제되거나 수정되지 않도록 보존합니다. 이는 ECS 확장으로 표준 Swift API에서는 사용할 수 없습니다.

보존은 다음과 같은 방법으로 설정할 수 있습니다.

오브젝트의 보존 기간

오브젝트의 보존 기간을 저장합니다. 보존 기간은 오브젝트의 x-emc-retention-period 헤더를 사용하여 설정합니다.

오브젝트의 보존 정책

오브젝트의 보존 정책을 설정하고 네임스페이스에 대해 정책과 연결된 기간을 설정할 수 있습니다. 정책을 사용하여 오브젝트 그룹의 보존 기간을 동일한 값으로설정할 수 있으며 정책을 변경하여 모든 오브젝트의 보존 기간을 변경할 수 있습니다. 정책을 사용하면 오브젝트에 보존 기간을 적용하는 것보다 훨씬 더 유연한 적용이 가능합니다. 또한 네임스페이스에 여러 개의 보존 정책을 설정하여 여러 오브젝트 그룹에 각각 다른 보존 기간을 적용할 수 있습니다.

OpenStack Swift


오브젝트의 x-emc-retention-policy 헤더를 사용하여 오브젝트에 적용되는보존 정책 및 정책 보존 기간은 ECS Management REST API(또는 ECS Portal)를사용하여 설정해야 합니다.

버킷의 보존 기간

버킷에 대해 저장된 보존 기간을 사용하여 모든 오브젝트의 보존 기간을 설정하고,오브젝트 레벨 보존 기간 또는 정책을 사용하여 더 긴 보존이 필요한 경우 오브젝트별 설정을 제공할 수 있습니다. 보존 기간은 버킷의 x-emc-retention-period 헤더를 사용하여 설정합니다.

오브젝트를 수정하거나 삭제하려고 시도할 경우, 오브젝트에 직접 설정되거나 오브젝트 보존 정책을 사용하여 설정된 버킷 보존 기간 또는 오브젝트 기간 중 더 긴 기간에 따라 작업 수행 가능 여부가 결정됩니다.

파일 시스템 지원Swift 버킷은 Swift 프로토콜을 사용하여 쓴 파일을 NFS 및 HDFS 같은 파일 프로토콜을 사용하여 읽거나 쓸 수 있고, 그 반대 작업도 가능하도록 FS(Filesystem)를 활성화할수도 있습니다.

FS 액세스 활성화Swift 프로토콜을 사용하여 버킷을 생성할 때 x-emc-file-system-access-enabled 헤더를 사용하여 파일 시스템 액세스를 활성화할 수 있습니다. (ECSManagement REST API를 사용하여) ECS Portal에서 버킷을 만들 때도 파일 시스템 액세스를 활성화할 수 있습니다.

FS 지원에 대한 제한 사항다음 제한 사항이 적용됩니다.

l 버킷에 FS가 활성화되어 있는 경우 보존을 사용할 수 없습니다.

FS에 대한 교차 헤드 지원교차 헤드 지원이란 한 프로토콜을 사용하여 쓴 오브젝트에 ECS에서 지원되는 다른 프로토콜을 사용하여 액세스하는 것을 말합니다. Swift 헤드를 사용하여 쓴 오브젝트는NFS 및 HDFS 파일 시스템 프로토콜을 사용하여 읽고 쓸 수 있습니다.

교차 헤드 지원에서 중요한 측면은 오브젝트/파일 사용 권한이 프로토콜 간에 변환되는 방법과, 파일 시스템 액세스의 경우 사용자 및 그룹 개념이 오브젝트 프로토콜과 파일 프로토콜 간에 변환되는 방법입니다.

파일 시스템에서의 교차 헤드 지원에 대한 자세한 정보는 ECS Product Documentation페이지에 있는 ECS 관리 가이드에서 확인할 수 있습니다.

S3와 Swift의 상호 운용성S3 프로토콜과 Swift 프로토콜은 상호 운용 가능하여 S3 애플리케이션에서 Swift 버킷의 오브젝트에 액세스할 수 있고 Swift 애플리케이션에서 S3 버킷의 오브젝트에 액세스할 수 있습니다.

Swift와 S3의 상호 운용성에 대한 자세한 내용은 S3와 Swift의 상호 운용성 항목을 참조하십시오.

OpenStack Swift

파일 시스템 지원 63



버킷 정책을 사용하는 데는 S3와 Swift의 상호 운용성이 지원되지 않습니다. 버킷 정책은 S3 헤드를 사용한 액세스에만 적용되며 Swift API를 사용한 버킷 액세스에는 적용되지 않습니다.

OpenStack Swift 인증

ECS는 여러 버전의 OpenStack Swift 인증 프로토콜을 지원합니다.

v1

오브젝트 사용자가 ECS Swift 서비스에 대한 인증을 받고 ECS Swift 서비스에 대해 후속 API 호출을 수행할 때 사용할 수 있는 인증 토큰을 받을 수 있습니다. 자세한 내용은 OpenStack 버전 1 인증 (65페이지) 섹션을 참조하십시오.

v2

오브젝트 사용자가 ECS Swift 서비스에 대한 인증을 받아 ECS Swift 서비스에 대해 후속 API 호출을 수행할 때 사용할 수 있는 범위가 지정된 토큰, 즉 특정 테넌트(프로젝트에 해당)와 연결된 토큰을 받을 수 있습니다. 자세한 내용은 OpenStack버전 2 인증(67페이지) 섹션을 참조하십시오.

v3

ECS가 Keystone 프로젝트로 범위가 지정된 토큰을 제공하는 Keystone V3 사용자를 검증합니다. 자세한 내용은 ECS Keystone V3 통합을 사용한 인증(69페이지)섹션을 참조하십시오.

v1 및 v2 프로토콜의 경우, OpenStack Swift 프로토콜을 사용하여 ECS 오브젝트 저장소에 액세스하려면 ECS 오브젝트 사용자 계정과 Swift 암호가 필요합니다.

v3의 경우, Keystone V3 서비스를 사용하여 ECS 외부에서 사용자가 생성되고 프로젝트 및 역할에 할당됩니다. ECS가 인증을 수행하지는 않지만, Keystone V3 서비스를 사용하여 인증 토큰을 검증합니다.

ECS 오브젝트 사용자에 Swift 자격 증명을 할당하는 방법에 대한 설명은 ECS Portal에서 Swift 사용자 생성(64페이지) 섹션에 나와 있습니다.

ECS Portal에서 Swift 사용자 생성ECS 오브젝트 사용자에게는 OpenStack Swift 프로토콜을 사용하여 ECS 오브젝트 저장소에 액세스할 수 있도록 자격 증명을 부여할 수 있습니다.

시작하기 전에

ECS System Administrator여야 합니다.

ECS 오브젝트 사용자를 추가하는 방법에 대한 자세한 내용은 ECS ProductDocumentation 페이지에 있는 ECS 관리 가이드에서 확인할 수 있습니다.

절차

1. ECS Portal에서 Manage > Users를 선택합니다.

User Management 페이지가 표시됩니다.

2. User Management 페이지에서 New Object User를 선택하거나 사용자 테이블에나열된 특정 사용자에 대해 Edit 작업을 선택하여 기존 사용자에 Swift 암호를추가합니다.

새 사용자를 생성하는 경우 사용자의 이름을 입력하고 사용자가 속할 네임스페이스를 선택합니다.

OpenStack Swift




3. Swift 영역의 Groups 필드에 사용자가 속할 그룹을 입력합니다.

아래 그림에 Swift 영역이 강조 표시되어 있습니다.

admin 그룹을 지정하면 사용자가 모든 컨테이너 작업을 수행할 수 있도록 자동으로 권한이 부여됩니다. 다른 그룹을 지정하면 해당 그룹에 컨테이너에 대한 권한을 부여해야 합니다. 컨테이너 권한 부여에 대한 자세한 내용은 컨테이너에 대한 인증(72페이지) 섹션을 참조하십시오.

4. Swift 사용자의 암호를 입력합니다.

5. Set Password & Groups를 선택합니다.

OpenStack 버전 1 인증V1 버전의 인증 프로토콜을 사용하여 ECS OpenStack Swift 서비스로 인증을 받을 수있습니다.

절차

1. ECS 오브젝트 사용자의 UID 및 암호를 얻습니다.

ECS Portal(ECS Portal에서 Swift 사용자 생성(64페이지) 참조)에서 이 작업을수행할 수 있으며 다음 ECS REST API를 호출하여 암호를 생성할 수도 있습니다.

요청:

PUT /object/user-password/[email protected] <user_password_create> <password>myPassword</password> <namespace>EMC_NAMESPACE</namespace> </user_password_create>

OpenStack Swift

OpenStack 버전 1 인증 65

응답:

HTTP 200

2. 아래에 표시된 OpenStack 인증 REST API를 호출합니다. HTTP의 경우 포트9024를 사용하고 HTTPS의 경우 9025를 사용합니다.

요청:

GET /auth/v1.0 X-Auth-User: [email protected] X-Auth-Key: myPassword

응답:

HTTP/1.1 204 No Content Date: Mon, 12 Nov 2010 15:32:21 GMT Server: Apache

X-Storage-Url: https://{hostname}/v1/account X-Auth-Token: ECS_e6384f8ffcd849fd95d986a0492ea9a6 Content-Length: 0

결과

UID 및 암호가 ECS에 의해 검증되면 스토리지 URL 및 토큰이 응답 헤더에 반환됩니다.추가적인 요청은 이 토큰을 포함함으로써 인증됩니다. 스토리지 URL은 호스트 이름 및리소스 주소를 제공합니다. 다음 X-Storage-Url 헤더를 제공하여 컨테이너 및 오브젝트에 액세스할 수 있습니다.

X-Storage-Url: https://{hostname}/v1/{account}/{container}/{object}

생성된 토큰은 생성 이후 24시간이 지나면 만료됩니다. 동일한 UID 및 암호를 사용하여24시간 이내에 인증 요청을 반복하면 OpenStack에서 동일한 토큰을 반환합니다. 24시간 만료 기간이 지나면 OpenStack에서 새 토큰을 반환합니다.

아래의 간단한 인증 예제에서는 첫 번째 REST 호출이 X-Auth-Token을 반환합니다. 두번째 REST 호출은 이 X-Auth-Token을 사용하여 계정에 대해 GET 요청을 수행합니다.

$ curl -i -H "X-Storage-User: [email protected]" -H "X-Storage-Pass: 1fO9X3xyrVhfcokqy3U1UyTY029gha5T+k+vjLqS" http://ecs.yourco.com:9024/auth/v1.0

HTTP/1.1 204 No Content X-Storage-Url: http://ecs.yourco.com:9024/v1/s3 X-Auth-Token: ECS_8cf4a4e943f94711aad1c91a08e98435 Server: Jetty(7.6.4.v20120524)

OpenStack Swift


$ curl -v -X GET -s -H "X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435" http://ecs.yourco.com:9024/v1/s3

* About to connect() to ecs.yourco.com port 9024 (#0) * Trying 203.0.113.10... * Adding handle: conn: 0x7f9218808c00 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7f9218808c00) send_pipe: 1, recv_pipe: 0 * Connected to ecs.yourco.com (203.0.113.10) port 9024 (#0)

> GET /v1/s3 HTTP/1.1 > User-Agent: curl/7.31.0 > Host: ecs.yourco.com:9024 > Accept: */* > X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435 > < HTTP/1.1 204 No Content < Date: Mon, 16 Sep 2013 19:31:45 GMT < Content-Type: text/plain * Server Jetty(7.6.4.v20120524) is not blacklisted < Server: Jetty(7.6.4.v20120524) <

* Connection #0 to host ecs.yourco.com left intact

OpenStack 버전 2 인증ECS는 OpenStack 버전 2(Keystone) 인증을 제한적으로 지원합니다.

시작하기 전에

ECS는 V2 인증을 사용하여 사용자를 인증하는 Swift 애플리케이션을 지원하는OpenStack Swift V2 ID 서비스를 구축합니다. 사용자는 Swift 프로토콜을 사용하여ECS 오브젝트 저장소에 액세스할 수 있는 OpenStack Swift 자격 증명이 할당된 ECS오브젝트 사용자여야 합니다.

ECS 네임스페이스(Swift 프로젝트에 해당)로 범위가 지정된 토큰만 Swift API 호출을수행하는 데 사용할 수 있습니다. 테넌트로 범위가 지정된 토큰 및 서비스 엔드포인트를 얻기 전에 테넌트 ID를 검색하기 위해 범위가 지정되지 않은 토큰을 얻어 ID 서비스에 액세스하는 데 사용할 수 있습니다.

범위가 지정된 토큰과 서비스 엔드포인트는 V1 인증에 대한 이전 섹션에 설명된 대로ECS에 대해 인증을 받는 데 사용할 수 있습니다.

아래에 나열된 두 문서에서는 중요한 배경 정보를 설명합니다.

l OpenStack Keystone 워크플로우 및 토큰 범위 지정

l Admin 인증 API

절차

1. ECS에서 범위가 지정되지 않은 토큰을 가져오려면 /v2.0/tokens API를 사용하고 ECS Swift 서비스에 대한 사용자 이름 및 암호를 입력하면 됩니다.

curl -v -X POST -H 'ACCEPT: application/json' -H "Content-

OpenStack Swift

OpenStack 버전 2 인증 67

http://bodenr.blogspot.com/2014/03/openstack-keystone-workflow-token.html

http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_authenticate_v2.0_tokens_.html

Type: application/json" -d '{"auth": {"passwordCredentials" : {"username" : "swift_user", "password" : "123"}}}' http://203.0.113.10:9024/v2.0/tokens

응답은 다음과 같습니다. 범위가 지정되지 않은 토큰에는 ID 및 ECS에서 생성한토큰과 "ecs_" 접두사가 앞에 지정됩니다.

{"access": {"token": {"id":"ecs_d668b72a011c4edf960324ab2e87438b","expires":"1376633127950"l},"user": {"name": "sysadmin", "roles":[ ], "role_links":[ ] },"serviceCatalog":[ ] }} , }

2. 범위가 지정되지 않은 토큰과 연관된 테넌트 정보를 가져옵니다.

curl -v http://203.0.113.10:9024/v2.0/tenants -H 'X-Auth-Token: d668b72a011c4edf960324ab2e87438b'

응답은 다음과 같습니다.

{"tenants_links":[], "tenants":[{"description":"s3","enabled":true, "name": "s3"}]}

3. 범위가 지정된 토큰을 storageUrl과 함께 가져옵니다.

curl -v -X POST -H 'ACCEPT: application/json' -H "Content-Type: application/json" -d '{"auth": {"tenantName" : "s3", "token":{"id" : ecs_d668b72a011c4edf960324ab2e87438b"}}}' http://203.0.113.10:9024/v2.0/tokens

예제 응답은 다음과 같습니다. 두 번째 토큰 앞에는 ID가 추가됩니다.

{"access":{"token":{"id":"ecs_baf0709e30ed4b138c5db6767ba76a4e","expires":"1376633255485","tenant":{"description":"s3","enabled":true,"name":"s3"}},"user":{"name":"swift_admin","roles":[{"name":"member"},{"name":"admin"}],"role_links":[]}, "serviceCatalog":[{"type":"object-store", "name":"Swift","endpoints_links":[],"endpoint":[{"internalURL": "http://203.0.113.10:9024/v1/s3","publicURL":"http://203.0.113.10:9024/v1/s3"}]}]}}

OpenStack Swift


4. 범위가 지정된 토큰 및 서비스 엔드포인트 URL을 Swift 인증에 사용합니다. 이단계는 OpenStack V1의 경우와 동일합니다.

curl -v -H "X-Auth-Token: baf0709e30ed4b138c5db6767ba76a4e" http://203.0.113.10:9024/v1/s3/{container}/{object}

ECS Keystone V3 통합을 사용한 인증ECS는 OpenStack Swift 사용자가 제공하는 인증 토큰을 검증하는 방식으로 KeystoneV3를 지원합니다. Keystone V3의 경우, Keystone V3 서비스를 사용하여 ECS 외부에서사용자가 생성됩니다. ECS가 인증을 수행하지는 않지만, Keystone V3 서비스를 사용하여 인증 토큰을 검증합니다.

Keystone 도메인에서는 프로젝트를 ECS 테넌트/네임스페이스로 생각할 수 있습니다.ECS 네임스페이스는 테넌트로 생각할 수 있습니다.

Keystone V3에서는 사용자를 역할에 할당하고, 사용자가 수행할 수 있는 작업이 사용자 역할 구성원 자격을 기반으로 하도록 할 수 있습니다. 하지만 Keystone V3에 대한ECS 지원에서 현재 Keystone 정책을 지원하지 않으므로 사용자가 컨테이너 작업을 수행하려면 admin 그룹(역할)에 속해 있어야 합니다.

인증 토큰은 특정 프로젝트로 범위가 지정되어야 합니다. ECS에서는 범위가 지정되지않은 토큰이 허용되지 않습니다. 프로젝트(ECS의 테넌트에 해당) 목록 가져오기 등의범위가 지정되지 않은 토큰과 관련된 작업은 Keystone 서비스에 대해 직접 사용자가수행해야 합니다. 그런 다음 사용자는 Keystone 서비스에서 범위가 지정된 토큰을 가져와야 합니다. 이렇게 가져온 토큰은 ECS에 의해 검증되고, 유효한 경우 ECS에 인증을 받는 데 사용될 수 있습니다.

ECS 검증을 활성화하려면 인증 공급자가 ECS에 구성되어 있어야 합니다. 그래야 사용자로부터 특정 프로젝트로 범위가 지정된 토큰이 수신된 경우 ECS가 Keystone V3 인증 공급자에 대해 이러한 토큰을 검증할 수 있습니다. 또한, Keystone 프로젝트에 해당하는 ECS 네임스페이스도 생성되어 있어야 합니다. 자세한 내용은 OpenStack Swift와ECS 통합 구성(70페이지)에 나와 있습니다.

인증 확인ECS는 Keystone 토큰이 제공하는 정보를 사용하여 인증 결정을 수행합니다. 인증 확인절차는 다음과 같습니다.

1. ECS가 토큰의 범위로 지정된 프로젝트가 URI의 프로젝트와 일치하는지 확인합니다.

2. 작업이 오브젝트 작업이면 ECS가 오브젝트와 연결된 ACL을 평가하여 작업 허용여부를 확인합니다.

3. 작업이 컨테이너 작업이면 ECS가 요청된 작업을 평가합니다. 사용자가 admin 역할을 갖는 경우 나열, 생성, 업데이트, 읽기 및 삭제 컨테이너 작업을 수행할 수 있습니다.

도메인Keystone V3에서는 모든 사용자가 하나의 도메인에 속하며 하나의 도메인에 여러 프로젝트가 있을 수 있습니다. 사용자에게는 해당 역할에 따라 프로젝트에 대한 액세스가할당됩니다. 사용자가 특정 도메인에 할당되지 않은 경우 default 도메인에 할당됩니다.

OpenStack Swift

ECS Keystone V3 통합을 사용한 인증 69

Swift Keystone V3 사용자를 사용하여 생성된 오브젝트 및 컨테이너는<user>@<domain.com>이 소유합니다. 사용자가 특정 도메인에 할당되지 않은 경우 컨테이너 및 오브젝트에 할당되는 사용자 이름은 <user>@default입니다.

OpenStack Swift와 ECS 통합 구성Keystone V3를 사용하는 OpenStack Swift 서비스가 ECS에서 인증할 수 있도록 하려면 Swift와 ECS 구성이 일치해야 합니다.

시작하기 전에

다음과 같은 사전 요구 사항을 따라야 합니다.

l Swift 서비스 관리자 계정에 대한 자격 증명이 있어야 합니다. ECS가 Keystone 서비스를 통해 인증할 수 있도록 하려면 이러한 자격 증명이 필요합니다.

l ECS에 액세스하는 Swift 사용자가 속하는 Keystone 프로젝트의 ID가 있어야 합니다.

l ECS System Administrator 계정에 대한 자격 증명이 있어야 합니다.

절차

1. ECS 엔드포인트가 Swift 서비스 카탈로그에 추가되었고 형식이 올바른지 확인합니다.

엔드포인트가 "default" Keystone 도메인에 있는지 확인해야 합니다.

2. System Administrator로 ECS Portal에 로그인합니다.

3. Keystone V3 서비스 엔드포인트와 토큰 검증에 사용할 수 있는 관리자 계정의자격 증명을 지정하는 인증 공급자를 생성합니다.

자세한 내용은 Keystone 인증 공급자 추가(70페이지) 섹션을 참조하십시오.

4. 인증하려는 사용자가 속하는 Keystone 프로젝트/계정과 동일한 ID를 갖는 ECS네임스페이스를 생성합니다.

Keystone 프로젝트 ID를 얻습니다.

a. ECS Portal에서 Manage > Namespace > New Namespace를 선택합니다.

b. 네임스페이스의 이름을 입력합니다.

Swift 프로젝트의 이름을 지정해야 합니다.

c. User Admin인 네임스페이스 관리자 계정을 입력합니다.

이전에 생성된 관리 사용자의 이름을 지정해야 합니다.

d. 필요한 기타 네임스페이스 설정을 구성합니다.

네임스페이스 설정 및 ECS에서 사용자를 생성하는 방법에 대한 자세한 내용은 ECS Product Documentation 페이지에 있는 ECS 관리 가이드에서 확인할수 있습니다.

결과

네임스페이스가 생성되고 나면 해당 Keystone 프로젝트에 속하고 해당 프로젝트로 범위가 지정된 토큰을 가진 사용자가 ECS에 대해 인증을 받고(Keystone 인증 공급자와통신하는 ECS를 통해) Swift API를 사용하여 ECS 오브젝트 저장소에 액세스할 수 있습니다.

Keystone 인증 공급자 추가OpenStack Swift 사용자를 인증할 Keystone 인증 공급자를 추가할 수 있습니다.

OpenStack Swift



시작하기 전에

l 이 작업을 수행하려면 ECS에서 System Administrator 역할이 필요합니다.

l Keystone 인증 공급자를 하나만 추가할 수 있습니다.

l Keystone 인증 공급자 설정(71페이지)에 나열된 인증 공급자 정보를 확인합니다.

절차

1. ECS Portal에서 Manage > Authentication을 선택합니다.

2. Authentication Provider Management 페이지에서 New AuthenticationProvider를 클릭합니다.

3. New Authentication Provider 페이지의 Type 필드에서 Keystone V3를 선택합니다.

필수 필드가 표시됩니다.

4. Name, Description, Server URL, Keystone Administrator 및 AdminPassword 필드에 값을 입력합니다. 이러한 필드에 대한 자세한 내용은 Keystone 인증 공급자 설정(71페이지) 항목을 참조하십시오.

5. Save를 클릭합니다.

Keystone 인증 공급자 설정Keystone 인증 공급자를 추가 또는 편집할 경우 인증 공급자 정보를 제공해야 합니다.

표 13 Keystone 인증 공급자 설정

필드 설명

Name Keystone 인증 공급자의 이름입니다. 이 이름은 ECS에서 공급자를 식별하는 데 사용됩니다.

Description 인증 공급자에 대해 자유롭게 입력한 텍스트 설명입니다.

OpenStack Swift

ECS Keystone V3 통합을 사용한 인증 71

표 13 Keystone 인증 공급자 설정 (계속)

필드 설명

Type Keystone V3.

Server URL ECS에서 Swift 사용자를 검증하기 위해 접속하는 Keystone 시스템의 URL입니다.

Keystone Administrator Keystone 시스템 관리자의 사용자 이름입니다. ECS는 이 사용자 이름을 사용하여Keystone 시스템에 접속합니다.

Administrator Password 지정된 Keystone 관리자의 암호입니다.

컨테이너에 대한 인증OpenStack Swift 인증은 컨테이너만을 대상으로 합니다.

현재 Swift는 두 가지 유형의 인증을 지원합니다.

l 참조 스타일 인증

l 그룹 스타일 인증

ECS는 그룹 기반 인증만 지원합니다.

관리 사용자는 계정 내에서 모든 작업을 수행할 수 있습니다. 비관리 사용자는 컨테이너의 X-Container-Read 및 X-Container-Write ACL(Access Control List)에 따라 각 컨테이너에 대해서만 작업을 수행할 수 있습니다. 다음 작업은 비관리 사용자에게 허용될수 있습니다.

관리자가 컨테이너에 대한 읽기 액세스를 할당"admin" 사용자는 다음을 사용하여 그룹에 읽기 권한을 할당할 수 있습니다.

curl -X PUT -v -H 'X-Container-Read: {GROUP LIST}' -H 'X-Auth-Token: {TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}"

이 명령은 GROUP LIST에 속하는 사용자가 container1에 대한 읽기 액세스 권한을 갖도록 합니다. 예를 들어, "Member"라는 그룹에 읽기 권한을 할당하려면 다음을 사용합니다.

curl –X PUT -v –H 'X-Container-Read: Member' –H 'X-Auth-Token: {ADMIN_TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}

읽기 권한이 부여되면 타겟 그룹에 속하는 사용자는 다음 작업을 수행할 수 있습니다.

l HEAD 컨테이너 - 컨테이너 메타데이터를 가져옵니다. 테넌트 관리자 권한을 갖는그룹에 사용자가 할당된 경우에만 허용됩니다.

l GET 컨테이너 - 컨테이너 내의 오브젝트를 나열합니다.

l GET 컨테이너 내의 오브젝트 - 컨테이너 내에 있는 오브젝트의 컨텐츠를 읽습니다.

OpenStack Swift


관리자가 컨테이너에 대한 쓰기 액세스를 할당"admin" 사용자는 다음을 사용하여 그룹에 읽기 권한을 할당할 수 있습니다.

curl -XPUT -v -H 'X-Container-Write: {GROUP LIST}' -H 'X-Auth-Token: {TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}"

이 명령을 실행하면 GROUP LIST에 속하는 사용자가 container1에 대한 쓰기 액세스 권한을 갖게 됩니다. 예를 들어, "Member"라는 그룹에 쓰기 권한을 할당하려면 다음을사용합니다.

curl –X PUT -v –H 'X-Container-Write: Member' –H 'X-Auth-Token: {ADMIN_TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}

그룹 GROUP LIST의 사용자에게 쓰기 권한이 부여됩니다. 쓰기 권한이 부여되면 타겟그룹에 속하는 사용자는 다음 작업을 수행할 수 있습니다.

l POST 컨테이너 - 메타데이터를 설정합니다. 접두사 "X-Container-Meta"로 시작됩니다.

l PUT 스토리지 내의 오브젝트 - 컨테이너 내에 오브젝트를 쓰거나 재정의합니다.

인증에 대한 자세한 내용은 다음을 참조하십시오. 컨테이너 작업.

OpenStack Swift

컨테이너에 대한 인증 73

http://ceph.com/docs/master/radosgw/swift/containerops/

OpenStack Swift


3부

EMC Atmos

3장, "EMC Atmos"

EMC Atmos 75

EMC Atmos


3장

EMC Atmos

l ECS의 EMC Atmos API 지원 기능......................................................................78l 지원되는 EMC Atmos REST API 호출................................................................ 78l 지원되지 않는 EMC Atmos REST API 호출........................................................80l EMC Atmos REST API 호출의 서브테넌트 지원................................................. 81l API 확장..............................................................................................................81

EMC Atmos 77

ECS의 EMC Atmos API 지원 기능ECS는 일부 EMC Atmos API를 지원합니다. 이 부분에는 지원되는 작업과 ECS 확장 기능이 나와 있습니다.

Atmos Object Service는 다음 포트에서 사용할 수 있습니다.

프로토콜 포트

HTTP 9022

HTTPS 9023

지원되는 작업에 대한 자세한 정보는 ECS지원 사이트에서 제공되는 AtmosProgrammer’s Guide에서 확인할 수 있습니다.

l Atmos Programmer's Guide

모든 지원되는 작업에 대해 WIRE 형식의 호환성이 제공됩니다. 따라서 AtmosProgrammer's Guide에서 설명한 작업이 ECS에 의해 표시된 API 작업에 적용됩니다.

Atmos Programmer's Guide에서는 Atmos API 인증에 대한 정보도 제공하고 지원되는 여러 기능에 대한 개괄적인 예도 제공합니다.

지원되는 EMC Atmos REST API 호출ECS는 일부 EMC Atmos API를 지원합니다.

다음 Atmos REST API 호출이 지원됩니다. 오브젝트 및 네임스페이스 인터페이스 모두에 대한 호출이 표시됩니다.

표 14 지원되는 Atmos REST API 호출


서비스 운영

GET /rest/service 시스템에 대한 정보 가져오기

오브젝트 작업

POST /rest/objects/rest/namespace/<path>

오브젝트 생성

(아래의 참고 사항 확인)

DELETE /rest/objects/<ObjectID>/rest/namespace/<path>

오브젝트 삭제

PUT /rest/objects/<ObjectID>/rest/namespace/<path>

오브젝트 업데이트

(아래의 참고 사항 확인)

GET /rest/objects/<ObjectID>/rest/namespace/<path>

오브젝트(또는 디렉토리목록) 읽기

POST /rest/namespace/<path>?rename 오브젝트 이름 변경

메타데이터 작업

EMC Atmos


http://support.emc.com

표 14 지원되는 Atmos REST API 호출 (계속)


GET /rest/objects/<ObjectID>?metadata/user/rest/namespace/<path>?metadata/user

오브젝트에 대한 사용자메타데이터 가져오기

POST /rest/objects/<ObjectID>?metadata/user/rest/namespace/<path>?metadata/user

사용자 메타데이터 설정

DELETE /rest/objects/<objectID>?metadata/user/rest/namespace/<path>?metadata/user

사용자 메타데이터 삭제

GET /rest/objects/<ObjectID>?metadata/system/rest/namespace/<path>?metadata/system

오브젝트에 대한 시스템메타데이터 가져오기

GET /rest/objects/<ObjectID>?acl/rest/namespace/<path>?acl

ACL 가져오기

POST /rest/objects/<ObjectID>?acl/rest/namespace/<path>?acl

ACL 설정

GET /rest/objects/<ObjectID>?metadata/tags/rest/namespace/<path>?metadata/tags

오브젝트에 대한 메타데이터 태그 가져오기

GET /rest/objects/<ObjectID>?info/rest/namespace/<path>?info

오브젝트 정보 가져오기

Head /rest/objects/<ObjectID>/rest/namespace/<path>

모든 오브젝트 메타데이터 가져오기

오브젝트-스페이스 작업

GET /rest/objects 오브젝트 나열

GET /rest/objects?listabletags 나열 가능한 태그 가져오기

익명 액세스

GET /rest/objects/<ObjectId>?uid=<uid>&expires=<exp>&signature=<sig>/rest/namespace/<path>?uid=<uid>&expires=<exp>&signature=<sig>

공유 가능한 URL

l x-emc-wschecksum 헤더는 ECS에서 지원되지 않습니다.

l HTML 형식 업로드는 지원되지 않습니다.

l GET /rest/objects는 x-emc-accept로 다른 응답 유형을 지원하지 않습니다.예를 들어, text/plain은 지원되지 않습니다.

l ACL 읽기, 쓰기 및 삭제는 Atmos와 마찬가지로 ECS에서 실행됩니다.

l POST /rest/objects는 기존(44자) 오브젝트 ID를 사용할 수 있도록 x-emc-object-id 헤더를 지원합니다.

EMC Atmos

지원되는 EMC Atmos REST API 호출 79

Atmos 나열 가능한 태그나열 가능한 태그는 오브젝트를 나열하거나 필터링하는 데 사용되는 특수한 사용자 정의 태그입니다. 예를 들어, 최종 사용자는 애플리케이션을 통해 “Vacation2016”과 같은태그로 사진 그룹(오브젝트)에 태그를 지정할 수 있습니다. 이후 애플리케이션은 이 나열 가능한 태그로 태그가 지정된 오브젝트만 나열하여 "Vacation2016" 쿼리에 응답할수 있습니다.

ECS와 함께 Atmos 프로토콜을 사용하여 다른 사용자의 나열 가능한 태그를 삭제하거나 수정할 수 없습니다. 상황에 따라 기본 Atmos에서 이 기능을 사용할 수 있습니다.

나열 가능한 태그가 ECS에서 인덱싱되어 태그가 지정된 오브젝트의 검색 성능 및 확장성을 높일 수 있습니다.

ECS에서 EMC_TAGS 메타데이터 태그는 나열 가능한 태그를 유지하는 데 사용됩니다.이 태그 이름은 사용자 정의 메타데이터 태그에서 사용할 수 없습니다.

오브젝트 ID 길이ECS의 Atmos API 지원은 오브젝트 길이를 44자에서 101자로 확장합니다. 따라서Atmos에서 ECS로 애플리케이션을 이동하는 경우 오브젝트 ID 길이가 다르다는 점에유의해야 합니다.

기존 44자 ID 길이를 갖는 오브젝트를 생성하려는 경우 x-emc-object-id 헤더를 사용할수 있습니다. 이를 통해 Atmos로 오브젝트를 마이그레이션할 수 있습니다.

지원되지 않는 EMC Atmos REST API 호출다음 Atmos REST API 호출은 지원되지 않습니다.

표 15 지원되지 않는 Atmos REST API 호출


오브젝트 버전 관리

POST /rest/objects/<objectID>?versions

오브젝트 버전 생성

DELETE /rest/objects/<objectID>?versions

오브젝트 버전 삭제

GET /rest/objects/<objectID>?versions

오브젝트 버전 나열

PUT /rest/objects/<objectID>?versions

오브젝트 버전 복구

익명 액세스

POST /rest/accesstokens 액세스 토큰 생성

GET /rest/accesstokens/<token_id>?info

액세스 토큰 세부 정보 가져오기

DELETE /rest/accesstokens/<token_id>

액세스 토큰 삭제

GET /rest/accesstokens 액세스 토큰 나열

GET /rest/accesstokens/<token_id>

컨텐츠 익명 다운로드

EMC Atmos


EMC Atmos REST API 호출의 서브테넌트 지원ECS에는 ECS 서브테넌트 지원을 Atmos 애플리케이션에 추가하는 2개의 기본 RESTAPI 호출이 포함되어 있습니다.

이러한 호출은 다음과 같습니다.

API 호출 예

Subtenant create PUT Http url: /rest/subtenant필수 헤더: x-emc-uid(예: [email protected]) 및 x-emc-signature.

서브테넌트 ID는 응답의 "subtenantID" 헤더에설정되어 있습니다.

Subtenant delete DELETE Http url: /rest/subtenants/{subtenantID}필수 헤더: x-emc-uid(예: [email protected]) 및 x-emc-signature.

서브테넌트 ID가 마이그레이션 후 ECS에 보존됩니다. 헤더는 x-emc-subtenant-id: {original_subt_id}입니다.

API 확장ECS는 Atmos API의 여러 가지 확장을 지원합니다.


l 오브젝트에 데이터 추가(81페이지)

l Atmos 오브젝트의 보존 및 보존 만료 기간에 대한 ECS 지원(82페이지)

오브젝트에 데이터 추가EMC Atmos 프로토콜에 대한 ECS 확장을 사용하여 오브젝트에 데이터를 추가할 수 있습니다.

오브젝트에 데이터를 추가해야 하지만 정확한 바이트 오프셋을 결정하는 것이 효율적이거나 유용하지 않은 경우도 있습니다. 이러한 경우에 대비하여 ECS는 오프셋을 지정하지 않고 자동으로 데이터를 오브젝트에 추가할 수 있는 기능을 제공합니다. 정확한오프셋은 응답을 통해 반환됩니다.

특수 값이 bytes=-1-인 Range 헤더가 데이터를 오브젝트에 추가하는 데 사용될 수있습니다. 이렇게 하면 기존 오브젝트 크기를 알지 못해도 오브젝트가 확장될 수 있습니다. 형식은 다음과 같습니다. Range: bytes=-1-

EMC Atmos

EMC Atmos REST API 호출의 서브테넌트 지원 81

다음은 Range 값으로 bytes=-1-를 사용하여 기존 오브젝트에 추가하는 것을 보여 주는 샘플 요청입니다. 여기서는 요청을 통해 값 and cat을 보냅니다.

PUT /rest/namespace/myObject HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-date: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcx-emc-uid: fa4e31a68d3e4929bec2f964d4cac3de/[email protected]: ZpW9KjRb5+YFdSzZjwufZUqkExc=Content-Type: application/octet-streamAccept-Encoding: gzip, deflate, compress

and cat

HTTP/1.1 200 OKx-emc-mtime: 1431626712933Date: Mon, 17 Jun 2013 20:46:01 GMTx-emc-policy: defaultx-emc-utf8: truex-emc-request-id: 0af9ed8d:14cc314a9bc:112f6:9x-emc-delta: 8x-emc-append-offset: 24Content-Length: 0Server: Jetty(7.6.4.v20120524)

데이터가 추가된 오프셋 위치는 x-emc-append-offset 헤더 형태로 반환됩니다.


Atmos 오브젝트의 보존 및 보존 만료 기간에 대한 ECS 지원ECS는 Atmos 오브젝트의 보존 기간과 보존 만료 기간을 설정할 수 있도록 지원합니다.

보존 기간보존 기간은 오브젝트를 편집하거나 삭제할 수 있기 전에 ECS에서 오브젝트가 보존되는 기간을 정의합니다. 보존 기간 동안에는 오브젝트를 편집하거나 시스템에서 삭제할수 없고 보존 기간이 만료될 때까지 기다려야 합니다.

ECS에서 Atmos 오브젝트를 생성하는 동안 다음 방법으로 오브젝트 보존을 적용할 수있습니다.

l 오브젝트에 직접 정의

l 오브젝트가 생성된 ECS 버킷에 설정된 보존 기간에서 상속

ECS 네임스페이스에 보존 정책이 설정된 경우 오브젝트에 직접 보존 기간을 설정해야합니다. 네임스페이스의 보존 정책은 오브젝트에 의해 상속되지 않습니다.

표 16 Atmos 보존 기간

보존 설정 대상 설정 방법 참고

오브젝트 Atmos API로 다음 방법 사용:

l 헤더 보존 기간(초):'x-emc-retention-period:60'

l 오브젝트 설정을 생성하거나 업데이트하는 동안 오브젝트에 보존을 설정할 수있습니다.

l 헤더 보존 기간은 초 단위로 정의됩니다.

EMC Atmos


표 16 Atmos 보존 기간 (계속)

보존 설정 대상 설정 방법 참고

l UMD(User Meta Data),종료 날짜:'x-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2016-10-21:10:00Z'

l 헤더 및 UMD:'x-emc-meta:user.maui.retentionEnable =true,user.maui.retentionEnd=2016-10-21T18:14:30Z' -header 'x-emc-retention-period:60'

l UMD 보존은 종료 날짜로 정의됩니다.

l 보존 기간이 헤더와 UMD에서 모두 설정되는 경우 UMD 속성이 먼저 확인되며 헤더의 설정보다 우선합니다.

l 오브젝트에 보존 기간이 설정된 후에는기간이 만료될 때까지 보존 기간을 수정할 수 없습니다.

l x-emc 헤더를 사용하여 보존을 설정하는 경우

n -1은 보존 기간을 무기한으로 설정하며 만료 기간이 정의된 경우 이를 비활성화합니다.

n -2는 오브젝트에 설정된 보존 기간을 비활성화합니다.

ECS 네임스페이스

ECS Portal의 NewNamespace 또는 EditNamespace 페이지

l 오브젝트에 보존 기간을 설정하려는 경우 오브젝트 사용자의 네임스페이스에보존 정책이 정의되어 있더라도 위에 설명된 대로 오브젝트에 직접 보존 기간을설정해야 합니다.

l ECS 네임스페이스에 보존 정책이 설정되어 있거나 네임스페이스 내 버킷에 보존 기간이 설정되어 있고 버킷 내에서오브젝트가 생성되는 경우, ECS는 네임스페이스 또는 버킷에 설정된 값 중 가장 긴 보존 기간 동안 네임스페이스, 버킷 및 오브젝트를 보존합니다.

l 오브젝트 헤더를 통해 오브젝트 자체에보존 기간이 설정된 경우 ECS는 네임스페이스, 버킷 또는 오브젝트에 설정된값 중 가장 긴 기간 동안 오브젝트를 보존합니다.

l Atmos API를 통해 오브젝트에 보존 종료 날짜가 정의된 경우 ECS는 오브젝트에 설정된 Atmos API 보존 종료 날짜를사용하며 오브젝트를 생성할 때 네임스페이스 보존 정책과 버킷 보존 기간을무시합니다.

l Atmos 오브젝트가 포함된 서브테넌트(버킷)에 보존 정책을 적용하는 경우, 보존 정책이 설정된 후 서브테넌트에서 생성된 오브젝트와 보존 정책이 설정되기전에 서브테넌트에서 생성된 오브젝트에 모두 보존 정책이 적용됩니다.

ECS REST APIPOST /object/namespaces/namespace/{namespace}/retention

ECS 버킷 ECS Portal의 New Bucket또는 Edit Bucket 페이지

ECS REST APIPUT /object/bucket/{bucketName}/retention

EMC Atmos

Atmos 오브젝트의 보존 및 보존 만료 기간에 대한 ECS 지원 83

네임스페이스 보존 정책 및 버킷 보존 기간에 대한 자세한 내용은 ECS ProductDocumentation 페이지에 있는 ECS 관리 가이드을 참조하십시오.

예: 보존이 설정된 오브젝트 생성 요청 및 응답:

POST /rest/namespace/file1 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 16 Feb 2017 19:28:13 GMTx-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2017-06-30T06%3A38%3A44Zx-emc-uid:f082110e13f249649340e172fb7b4956/u1x-emc-utf8:trueContent-Type:plain/textx-emc-signature:2Gz51WT+jQdMjlobDV0mz7obsXM=Content-Length: 774

Response

HTTP/1.1 201 CreatedDate: Thu, 16 Feb 2017 19:28:17 GMTx-emc-policy: defaultx-emc-utf8: truex-emc-request-id: 0af7b3e4:15a4849d95e:37c:0x-emc-delta: 774Location: /rest/objects/0a40bd045f7373d367639f095d1db0d15acadb82d5d2cd108e2142f4be04635c-59bdb9b6-20c0-4f55-bc91-9db728a58854x-emc-mtime: 1487273295379Content-Length: 0Server: ViPR/1.0

예: 오브젝트 메타데이터 가져오기 요청 및 응답:

curl --head -H "x-emc-date:Mon, 30 Jan 2017 16:56:35 GMT" -H "x-emc-uid:7a2593be81374744adbf8e3983e7bd84/u1" -H "x-emc-signature:CQgfoiIQ/DCif7TafcIskWyVpME=" http://10.247.179.228:9022/rest/objects/d1bced53f2ebbcbc51af1d84747bd198d123d3b8585293a5bf0d32bb73c6cf4b-365f4482-c24a-4eca-b24a-070efe29bf63

Response

HTTP/1.1 200 OKDate: Mon, 30 Jan 2017 16:56:35 GMTx-emc-mtime: 1485795387838x-emc-retention-period: 21798212x-emc-meta: user.maui.retentionEnd=2017-10-10T00:00:00Z,user.maui.retentionEnable=true,allow-inline-update=false,atime=2017-01-30T16:45:48Z,ctime=2017-01-30T16:56:27Z,ctype=plain/text,data-range=CAAQgFA=,dek=kq/W1Rg/7qbmaCcLF8pFvqlDJ8+suPTdVddBBZFwZA86muG3P0Pb7w==,dekAlgo=AESKeyWrapRFC5649,etag=0-,fs-mtime-millisec=1485795387838,itime=2017-01-30T16:45:48Z,kekId=s3.7a2593be81374744adbf8e3983e7bd843cdda755061bac6c12c06eb02800a7fee4b11ac2e03f62bb01eee02995068e56,keypoolid=s3.7a2593be81374744adbf8e3983e7bd84,keypoolname=7a2593be81374744adbf8e3983e7bd84,keyversion=0,mtime=2017-01-30T16:56:27Z,namespace=s3,nlink=1,object-name=,objectid=d1bced53f2ebbcbc51af1d84747bd198d123d3b8585293a5bf0d3

EMC Atmos




2bb73c6cf4b-365f4482-c24a-4eca-b24a-070efe29bf63,objname=file,parentOid=53ae036bfcfb46f5580b912222f3026835e3ef972c7e3e532ba4a5de30b1946e,parentZone=urn:storageos:VirtualDataCenterData:365f4482-c24a-4eca-b24a-070efe29bf63,policyname=default,retention=CgYIoKOZmlE=,size=0,type=regular,uid=u1,parent=apache,gid=apachex-emc-useracl: u1=FULL_CONTROLx-emc-groupacl: other=READx-emc-policy: defaultx-emc-request-id: 0af7b3e4:159f0185cf7:957:4Content-Type: plain/textContent-Length: 0Server: ViPR/1.0

예: 보존 값을 사용하여 오브젝트 업데이트

POST /rest/namespace/file2?metadata/user HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 16 Feb 2017 19:37:15 GMTx-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2017-07-30T06%3A38%3A44Zx-emc-uid:f082110e13f249649340e172fb7b4956/u1x-emc-utf8:trueContent-Type:plain/textx-emc-signature:5UPpZcCfO0vtxMTW62fa2/2SmLg=

Response

HTTP/1.1 200 OK

Date: Thu, 16 Feb 2017 19:37:16 GMTx-emc-policy: _intx-emc-utf8: truex-emc-request-id: 0af7b3e4:15a4849d95e:582:0Content-Length: 0Server: ViPR/1.0

만료 기간Atmos 오브젝트에 대한 보존 기간 종료 날짜가 정의되어 있고 만료 기간도 설정되어있는 경우 ECS는 만료 기간에 정의된 날짜에 오브젝트를 자동으로 삭제합니다. 만료기간:

l Atmos API 또는 x-emc 헤더를 사용하여 오브젝트에 설정할 수 있습니다.

l 만료 기간은 보존 종료 날짜 이후여야 합니다.

l 기본적으로 만료 기간은 비활성화되어 있습니다.

l x-emc 헤더를 사용하여 보존 및 만료를 설정하는 경우, 값이 -1이면 만료 기간이 비활성화됩니다.

예: x-emc 헤더를 사용하여 만료 기간 설정:

POST /rest/namespace/file2 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Tue, 31 Jan 2017 19:38:00 GMTx-emc-expiration-period:300x-emc-uid:a2b85977fd08488b80e646ea875e990b/u1Content-Type:plain/text

EMC Atmos

Atmos 오브젝트의 보존 및 보존 만료 기간에 대한 ECS 지원 85

x-emc-signature:krhYBfKSiM3mFOT6FtRB+2/xZnw=Content-Length: 10240Expect: 100-continue

예: Atmos API를 사용한 요청 및 응답:

POST /rest/namespace/file2 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 02 Feb 2017 02:47:32 GMTx-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Zx-emc-uid:239e20dec7a54301a0b02f6090edcace/u1Content-Type:plain/textx-emc-signature:5tGEyK/9qUZCPSnQ9OPOdktN+Zo=Content-Length: 10240Expect: 100-continue

Response

HTTP/1.1 100 ContinueHTTP/1.1 201 CreatedDate: Thu, 02 Feb 2017 02:47:33 GMTx-emc-policy: defaultx-emc-request-id: 0af7b3e4:159fb81ddae:345e:0x-emc-delta: 10240Location: /rest/objects/5c3abaf60e0e207abec96baf0618c0461b7cd716898f8a12ee236aed1ec94bea-c86ee0e9-8709-4897-898e-c3d1895e1d93x-emc-mtime: 1486003652813Content-Length: 0Server ViPR/1.0 is not blacklistedServer: ViPR/1.0

예: Atmos API를 사용한 메타데이터 업데이트 요청 및 응답:

POST /rest/namespace/file?metadata/user HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 02 Feb 2017 02:44:13 GMTx-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Zx-emc-uid:239e20dec7a54301a0b02f6090edcace/u1Content-Type:plain/textx-emc-signature:9pzcc/Ce4Lq3k52QKdfWLYlZ1Yc=

Response

HTTP/1.1 200 OKDate: Thu, 02 Feb 2017 02:44:14 GMTx-emc-policy: _intx-emc-request-id: 0af7b3e4:159fb81ddae:339e:0Content-Length: 0Server ViPR/1.0 is not blacklistedServer: ViPR/1.0

EMC Atmos


4부

CAS

4장, "CAS"

CAS 87

CAS


4장

CAS

l ECS에서 CAS 지원 설정.................................................................................... 90l 콜드 스토리지.................................................................................................... 90l Compliance.........................................................................................................91l ECS에서 CAS 보존............................................................................................ 93l CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최

대 관리자........................................................................................................... 95l 네임스페이스 보존 정책 설정............................................................................ 101l CAS 사용자를 위한 버킷 생성 및 설정.............................................................. 102l CAS 오브젝트 사용자 설정............................................................................... 103l CAS를 위한 버킷 ACL 설정...............................................................................104l CAS 사용자를 지원하는 ECS Management API................................................ 106l CAS(Content Addressable Storage) SDK API 지원...........................................107

CAS 89

ECS에서 CAS 지원 설정ECS의 CAS(Content Addressable Storage) 지원을 소개합니다.

ECS CAS를 통해 CAS SDK 기반 클라이언트 애플리케이션은 변경되지 않는 컨텐츠 오브젝트를 ECS 스토리지에서 저장, 검색 및 삭제할 수 있습니다.

ECS 설정을 구성하려면 먼저 기본 ECS 스토리지를 프로비저닝해야 합니다. 프로비저닝은 보통 새 ECS 랙이 설치될 때 완료됩니다. 여기에는 스토리지 풀, VDC 및 복제 그룹의 설정이 포함됩니다. ECS CAS에서는 CAS를 지원하기 위해 이러한 오브젝트를 생성하거나 편집할 필요가 있을 경우 표준 설명서를 참조할 수 있습니다. ECS ProductDocumentation 페이지에 있는 ECS 관리 가이드 항목을 참조하십시오.

스토리지 풀의 경우 콜드 아카이브 설정을 고려해 볼 수 있습니다. 콜드 스토리지(90페이지) 항목을 참조하십시오.

다음으로, 표준 설명서를 참조하여 네임스페이스, 사용자 및 버킷을 설정합니다. ECSProduct Documentation 페이지에 있는 ECS 관리 가이드 항목을 참조하십시오.

이 장에서는 CAS를 지원하기 위해 기본 구성을 수정하는 방법을 설명합니다.

콜드 스토리지콜드 스토리지 아카이브에 대해 설명합니다.

콜드 아카이브는 자주 변경되지 않는 오브젝트를 저장하므로 강력한 기본 EC 체계가필요하지 않습니다. 콜드 아카이브에 사용되는 EC 체계는 10개 데이터 조각과 2개 코딩 조각(10/12)입니다. 효율성은 1.2x입니다.

새로운 스토리지 풀을 생성할 때 콜드 아카이브(콜드 스토리지)를 지정할 수 있습니다.스토리지 풀을 생성한 후에는 EC 체계를 변경할 수 없습니다. 이 체계는 단일 노드가손실되는 경우를 지원할 수 있습니다. 또한 2개의 개별 노드에서 6개 드라이브 중 1개또는 12개 드라이브 중 2개가 손실되는 경우도 지원합니다.

EC 요구 사항

표 17 일반 아카이브와 콜드 아카이브의 요구 사항 비교

활용 사례 활성화되는 방식 필요한 최소노드 수

필요한 최소디스크 수

권장되는 디스크 수

EC 효율성 EC 체계

일반 아카이브 기본값 4 16* 32 1.33x 12/16

콜드 아카이브 시스템 관리자가 구성 8 12* 24 1.2x 10/12

*C-Series 어플라이언스에 대한 구축 가능한 최소 구성은 각각 12개 디스크가 있는 2개의 어플라이언스이므로 24개 디스크가 유효한 최소 구성입니다.

스토리지 풀 구성포털에서 콜드 아카이브를 설정하려면 새로운 스토리지 풀을 생성할 때 Cold Storage를 선택하십시오. 스토리지 풀을 생성한 후에는 이 설정을 변경할 수 없습니다.

CAS






Compliance전자 기록 저장에 관한 정부 및 업계 표준을 지원하는 ECS 기능을 설명합니다.

ECS는 Cohasset Associates Inc에서 인증한 바와 같이 다음 표준의 스토리지 요구 사항을 준수합니다.

l SEC(Securities and Exchange Commission) 규정 17 C.F.R. § 240.17a-4(f)

l CFTC(Commodity Futures Trading Commission) 규정 17 C.F.R. § 1.31(b)-(c)

ECS 버전 2.2.1 소프트웨어 이상을 사용하는 ECS Appliance에 대해 규정 준수가 인증되었습니다. ECS 인증 타사 하드웨어에서 실행되는 ECS 소프트웨어 전용 버전 3.0 이상의 설치도 인증되었습니다.

규정 준수는 세 가지 구성 요소로 이루어져 있습니다.

l 플랫폼 강화: 일반적인 보안 취약성을 해결합니다.

l 정책 기반 기록 보존: 보존 중인 기록에 대한 보존 정책을 변경할 수 있는 기능을 제한합니다.

l 규정 준수 보고: 시스템 에이전트가 정기적으로 시스템의 규정 준수 상태에 대해 보고합니다.

플랫폼 강화 및 규정 준수규정 준수 표준을 지원하는 ECS 보안 기능에 대해 설명합니다.

ECS 플랫폼 보안 기능:

CAS

Compliance 91

l 노드에 대한 사용자 루트 액세스가 비활성화되어 있습니다(사용자의 루트 로그인이 허용되지 않음).

l ECS 고객은 처음 설치 시 설정되는 관리 사용자를 통해 노드에 액세스할 수 있습니다.

l 관리 사용자는 sudo를 사용하여 노드에 대한 명령을 실행합니다.

l sudo 명령에 대한 전체 감사 로깅 기능이 있습니다.

l ESRS는 노드에 대한 모든 원격 액세스를 종료할 수 있는 기능을 제공합니다.ESRS Policy Manager에서 Start Remote Terminal 작업을 Never Allow로 설정합니다.

l ftpd, sshd 등의 모든 불필요한 포트가 닫힙니다.

l Lock Administrator 역할을 가진 emcsecurity 사용자는 클러스터의 노드를 잠글수 있습니다. 이는 네트워크를 통한 SSH의 원격 액세스가 비활성화됨을 뜻합니다.Lock Administrator는 원격 유지 보수 작업 또는 기타 권한이 있는 액세스를 허용하도록 노드를 잠금 해제할 수 있습니다.

노드 잠금은 ECS Portal 또는 ECS Management API의 권한 있는 사용자에게 영향을 미치지 않습니다.

규정 준수 및 보존 정책규정 준수가 활성화된 ECS 시스템에서 기록 보존에 관한 향상된 규칙에 대해 설명합니다. ECS는 오브젝트, 버킷 및 네임스페이스 레벨에서 오브젝트 보존 기능을 Enabled로설정합니다. 규정 준수는 보존 중인 오브젝트에 대한 보존 설정에 수행할 수 있는 변경사항을 제한함으로써 이러한 기능을 강화합니다. 규칙은 다음과 같습니다.

l 규정 준수는 네임스페이스 레벨에서 활성화됩니다. 이는 네임스페이스에 포함된모든 버킷의 보존 기간이 0보다 커야 함을 의미합니다. CAS의 경우, EnforceRetention Information in Object 설정이 활성화되어 있어야만 보존 값이 0인 버킷을 생성할 수 있습니다.

l 규정 준수는 네임스페이스를 생성할 때만 네임스페이스에 대해 활성화할 수 있습니다. (기존 네임스페이스에는 규정 준수를 추가할 수 없습니다.)

l 규정 준수를 활성화하고 나면 비활성화할 수 없습니다.

l 네임스페이스에 포함된 모든 버킷의 보존 기간이 0보다 커야 합니다.

오브젝트 레벨 보존 기간을 할당하는 애플리케이션을 사용하는 경우 ECS를 사용하여 애플리케이션 보존 기간보다 길게 보존 기간을 할당하지 마십시오. 이 작업으로인해 애플리케이션 오류가 발생합니다.

l 데이터가 저장된 버킷은 보존 값에 관계없이 삭제할 수 없습니다.

l 버킷에 Infinite 옵션을 적용하면 규정 준수가 활성화된 네임스페이스에 속한 버킷에 저장된 오브젝트를 영구적으로 삭제할 수 없습니다.

l 오브젝트에 대한 보존 기간은 삭제하거나 단축할 수 없습니다. 따라서, 버킷에 대한보존 기간도 삭제하거나 단축할 수 없습니다.

l 오브젝트 및 버킷 보존 기간은 늘릴 수 있습니다.

l 보존 중인 오브젝트를 삭제할 수 있는 사용자는 없습니다. CAS의 승인된 삭제 권한이 있는 사용자도 삭제가 불가능합니다.

CAS


그림 1 ECS Portal에서 새로운 네임스페이스에 대해 규정 준수 활성화

규정 준수 에이전트규정 준수 에이전트의 작동에 대해 설명합니다.

규정 준수 기능은 규정 준수 모니터링을 제외하고 기본적으로 활성화됩니다. 모니터링기능이 활성화된 경우 에이전트가 정기적으로 메시지를 로깅합니다.

규정 준수 모니터링을 활성화하려면 고객 지원 본부와 계약을 체결해야 합니다. 모니터링 메시지는 노드에서 명령을 실행하여 확인할 수 있습니다. ECS Portal에는 표시되지않습니다.

ECS에서 CAS 보존CAS C-Clip은 애플리케이션에서 삭제하기 전까지 연결된 오브젝트가 ECS 스토리지에보존되는 기간을 제어하는 보존 기간을 가질 수 있습니다.

CAS

규정 준수 에이전트 93

보존 기간CAS 애플리케이션이 C-Clip에서 오브젝트에 대한 보존 기간을 할당합니다.

예를 들어 재무 관련 문서를 만든 날짜로부터 3년간 보존해야 한다면, 해당 재무 문서와 연결된 C-Clip의 보존 기간이 3년으로 지정됩니다. 문서가 무기한으로 보존되도록지정할 수도 있습니다.

보존 정책(보존 클래스)

"보존 클래스"의 Centera 개념이 ECS의 "보존 정책"에 매핑됩니다. 이 설명서에서는"보존 정책”을 사용합니다.

보존 정책을 사용하여 보존 활용 사례를 캡처하고 C-Clip에 적용할 수 있습니다. 예를들어 다양한 유형의 문서가 저마다 보존 기간이 다를 수 있습니다. 다음 보존 기간을 필수 사항으로 요구할 수 있습니다.

l 재무: 3년

l 법률: 5년

l 이메일: 6개월

다수의 C-Clip에 보존 기간이 적용될 때는 정책을 변경하면 해당 정책이 적용되는 모든오브젝트의 보존 기간이 바뀝니다.

보존 정책은 ECS의 네임스페이스와 연결되며, CAS 애플리케이션은 이를 보존 클래스로 인식합니다.

ECS 버킷 레벨 보존 및 CAS버킷 레벨 보존은 Centera에서 기본 풀 보존이 아닙니다. ECS에서 CAS 기본 보존은 지속적으로 0입니다.

규정 준수 네임스페이스에 오브젝트 레벨 보존 없이 작성된 오브젝트의 기본 보존 기간에 대한 동작 변경ECS 3.0부터는 애플리케이션에서 규정 준수 네임스페이스의 ECS CAS 버킷에 오브젝트 보존 없이 C-Clip을 쓸 때 버킷에 보존 값(예: 6개월)이 있는 경우, 기본 보존 기간인무제한(-1)이 C-Clip에 할당됩니다. C-Clip의 유효 보존 기간은 버킷 레벨 보존 기간과기본 오브젝트 레벨 보존 기간 중 더 긴 기간이므로 C-Clip을 삭제할 수 없습니다.

이는 Centera 동작에 따라 ECS를 불러오는 ECS 2.2.1 동작에서 변경된 것으로, CE+ 규정 준수 모드에서 기본 풀 보존은 항상 무제한(-1)입니다.

ECS 2.2.1에서는 애플리케이션에서 규정 준수 네임스페이스의 ECS CAS 버킷에 오브젝트 보존 없이 C-Clip을 쓸 때 버킷에 보존 값(예: 6개월)이 있는 경우, C-Clip에 할당되는 보존 기간이 0이 됩니다. 이때 C-Clip의 유효 보존 기간은 버킷 보존 값(6개월)이 됩니다. C-Clip은 6개월 후 삭제할 수 있습니다.

ECS 2.2.1에서 ECS 3.0 이상 버전으로 업그레이드한 후에는 ECS 2.2.1 동작을 사용하는 애플리케이션에서 쓰는 C-Clip을 삭제할 수 없습니다.

애플리케이션을 중지 및 재구성하여 적절한 오브젝트 레벨 보존을 할당한 후 ECS 3.0이상 버전과 상호 작용하도록 하십시오.

위의 예에서는 애플리케이션에서 C-Clip에 6개월 오브젝트 레벨 보존을 할당해야 합니다.

CAS 우선 순위ECS에 있는 CAS 오브젝트에 여러 보존 기간이 적용될 때, 보존 적용 방식에 상관없이값이 더 높은 보존 기간이 우선합니다.

CAS


CAS 보존 적용 방식ECS Portal에서, 또는 ECS Management API를 사용하여 네임스페이스에 대한 보존 정책을 정의할 수 있습니다. 네임스페이스 보존 정책 설정(101페이지) 항목을 참조하십시오.

외부 CAS 애플리케이션은 C-Clip 생성 중에 C-Clip에 고정된 보존 기간 또는 보존 정책을 할당할 수 있습니다.

API를 통해 보존 기간을 적용할 때, 기간을 초 단위로 지정합니다.

ECS CAS는 모든 보존 관련 계산에 마이그레이션 시간이 아니라 C-Clip의 생성 시간을사용합니다.

ECS Management API로 보존 정책을 생성하는 방법ECS Management REST API를 사용하여 보존 기간 및 정책을 생성할 수 있는데, 아래에 요약된 내용이 나와 있습니다.

표 18 보존을 위한 ECS Management API 리소스

방법 설명

PUT /object/bucket/{bucketName}/retention

버킷의 보존 값에 따라 버킷 내에 있는 모든 오브젝트에 적용되는 필수 보존 기간이 정의됩니다. 보존 기간을 1년으로 설정하면 버킷의 오브젝트를 1년간 삭제할 수 없습니다.

GET /object/bucket/{bucketName}/retention

지정된 버킷에 대해 현재 설정된 보존 기간을반환합니다.

POST /object/namespaces/namespace/{namespace}/retention

네임스페이스의 경우 보존 설정은 정책과 같이작동하며, 여기서 각각의 정책은<Name>:<Retention period> 쌍입니다. 네임스페이스에 대해 다수의 보존 정책을 정의할 수있고 이름을 기준으로 네임스페이스 내부의 오브젝트에 정책을 할당할 수 있습니다. 이를 통해 해당 정책을 변경하여 동일한 정책이 할당된 오브젝트 세트의 보존 기간을 변경할 수 있습니다.

PUT /object/namespaces/namespace/{namespace}/retention/{class}

네임스페이스와 연결된 보존 정책의 기간을 업데이트합니다.

GET /object/namespaces/namespace/{namespace}/retention

네임스페이스에 정의된 보존 정책을 반환합니다.

ECS Management API에 대한 자세한 내용은 ECS Management REST API 소개(112페이지) 항목을 참조하십시오. 온라인 참고 자료는 ECS API 참조 항목을 참조하십시오.

CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최대 관리자

ECS에서 지원되는 CAS API에서 사용할 수 있는 고급 보존 기능에 대해 설명합니다.

고객 애플리케이션에서는 CAS API를 사용하여 보존 전략을 지원합니다. CAS 워크로드가 ECS로 마이그레이션되면 ECS가 CAS API 기능을 인식하므로 고객 애플리케이션에서 마이그레이션된 데이터를 계속 작업할 수 있습니다. ECS에서는 별도의 라이센스

CAS

CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최대 관리자 95


없이 다음과 같은 ARM(Advanced Retention Management) 기능을 사용할 수 있습니다.

l 이벤트 기반 보존: CAS 애플리케이션에서 지정된 이벤트를 수신하면 보존 기간 또는 보존 정책을 적용(트리거)하도록 C-Clip을 통해 오브젝트를 구성하는 기능입니다.

l 법적 증거 자료 보관: CAS 애플리케이션에서 C-Clip을 통해 오브젝트에 법적 증거자료 보관을 적용한 경우 해당 오브젝트의 삭제를 방지하는 기능입니다. CAS 애플리케이션에서는 고유 법적 증거 자료 보관 ID를 만들고 적용하여 오브젝트에 최대100개의 법적 증거 자료 보관을 적용할 수 있습니다.

l 최소/최대 관리자: 관리자가 고정 보존 기간 또는 가변 보존 기간에 대해 버킷 레벨제한을 설정할 수 있는 기능입니다. 가변 보존 기간은 이벤트 기반 보존을 지원하도록 설정된 기간입니다. ECS에서 시스템 또는 네임스페이스 관리자는 ECS Portal을통해 이 값을 설정할 수 있습니다. 프로그래머는 ECS Management API를 사용하여이 값을 설정할 수 있습니다.

임의의 명명 체계를 사용하여 기록되고 ECS로 마이그레이션되는 레거시 CAS 데이터에 대해 ARM이 지원됩니다.

CAS 버킷 레벨 보존에 대한 최소/최대 관리자ECS Portal에서 CAS 버킷을 찾은 다음 Edit를 선택합니다. 아래 화면에 표시된 모든 컨트롤은 Bucket Retention Period 컨트롤을 제외하고 CAS 전용 기능입니다. BucketRetention Period는 모든 ECS 버킷 유형에서 지원되는 표준 ECS 버킷 보존 기능입니다.

그림 2 CAS 버킷에 대한 보존 옵션

다음 표에 CAS 버킷 보존 기능이 설명되어 있습니다.

CAS


기능 설명

EnforceRetentionInformation inObject

이 컨트롤을 활성화하면 모든 CAS 오브젝트가 보존 정보(기간 또는 정책)와 함께 생성됩니다. 그러한 오브젝트를 저장하려고 하면 오류가 반환됩니다. 이 컨트롤을 사용하면 규정 준수 활성화 환경에서도 BucketRetention Period를 구성할 수 없습니다.

CE+ 모드 Centera를 ECS로 마이그레이션하면 Enforce RetentionInformation in Object가 버킷에서 기본적으로 활성화됩니다.

Bucket RetentionPeriod

버킷 보존 기간을 지정할 때 버킷 레벨 보존 기간과 오브젝트 레벨 보존 기간이 모두 있는 경우 더 긴 기간이 적용됩니다.규정 준수 활성화 환경에서는 오브젝트의 보존 정보를 적용한 경우를 제외하고 Bucket Retention Period가 필수입니다. 그러나 구성한 후에는 오브젝트의 보존 정보를 적용하는 경우에도 Bucket Retention Period를재설정할 수 없습니다.

Minimum FixedRetention Period

이 기능은 오브젝트에 지정된 보존 기간을 제어합니다. 오브젝트의 보존 기간이 여기에서 지정된 범위를 벗어나면 오브젝트 쓰기 시도가 실패합니다.보존 정책을 사용하는 경우 최소/최대 설정이 적용되지 않습니다.

Minimum Fixed Retention Period에 대해 Infinite를 선택하면 모든보존 값이 무제한이 됩니다. Maximum Fixed Retention Period에 대해이를 선택하면 최대 제한이 없습니다.

버킷에 쓴 모든 C-Clip에 최소/최대 보존 제약이 적용됩니다. 클립을 SDK기반 타사 툴로 마이그레이션하는 경우, 보존이 범위 안에 있어야 합니다.그렇지 않으면 오류가 발생합니다.

Maximum FixedRetention Period

Minimum VariableRetention Period

이 기능은 EBR(Event-Based Retention)을 사용하여 오브젝트에 지정된 가변 보존 기간을 제어합니다. EBR에는 기본 보존 기간이 설정되어 있으며프로그래밍된 트리거 함수는 트리거 발생 시 보존 기간을 늘릴 수 있습니다. 오브젝트의 새 보존 기간이 여기에 지정된 범위를 벗어나면 트리거에대한 응답으로 오브젝트 쓰기 시도가 실패합니다.보존 정책을 사용하는 경우 최소/최대 설정이 적용되지 않습니다.

Minimum Variable Retention Period에 대해 infinite를 선택하면 모든 보존 값이 무제한이 됩니다. Maximum Variable Retention Period에 대해 이를 선택하면 최대 제한이 없습니다.

버킷에 쓴 모든 C-Clip에 최소/최대 보존 제약이 적용됩니다. 클립을 SDK기반 타사 툴로 마이그레이션하는 경우, 보존이 범위 안에 있어야 합니다.그렇지 않으면 오류가 발생합니다.

MaximumVariableRetention Period

시스템 관리자 또는 프로그래머가 고정 및 가변 보존 기간 값을 설정하지 않은 경우,ECS Management API get 함수가 최소/최대 설정 값을 반환하지 않습니다. EnforceRetention Information in C-Clip은 기본 값 false를 반환합니다.

이벤트 기반 보존EBR(Event-Based Retention)은 이벤트 전이나 이벤트 후 지정된 기간 동안 레코드를삭제할 수 없음을 지정하는 지침입니다. CAS에서 EBR은 지정된 기본 보존 기간 또는보존 정책 및 트리거 발생 시 더 긴 보존 기간을 설정할 수 있는 애플리케이션 정의 트리거가 있는 C-Clip입니다. 보존 기간은 트리거가 발생할 경우에만 시작됩니다. C-Clip이

CAS


EBR용으로 표시되어 있으면 권한이 필요한 삭제를 사용하지 않는 한 이벤트 전에 삭제할 수 없습니다.

EBR을 사용하는 경우 C-Clip 수명주기는 다음과 같습니다.

l 생성: 애플리케이션에서 새 C-Clip을 생성하고 EBR이 적용됨을 표시합니다. 애플리케이션은 최소 보존을 실행하는 고정 보존 기간을 제공할 수 있으며, 이벤트 기반보존 기간 또는 정책을 제공해야 합니다.

l 이벤트 트리거: 애플리케이션에서 이벤트를 트리거합니다. 이는 이벤트 기반 보존기간 또는 보존 정책의 시작 시점입니다. 이때 애플리케이션은 C-Clip 생성 시점에할당된 기간보다 더 긴 새 이벤트 기반 보존 기간을 할당할 수 있습니다.

l 삭제: 애플리케이션에서 C-Clip을 삭제하려는 경우 다음 조건을 충족해야 합니다.

n 정책(네임스페이스) 보존이 만료되었습니다.

n 버킷 보존이 만료되었습니다.

n 고정 보존이 만료되었습니다.

n 이벤트가 트리거되었습니다.

n 생성 시 설정된 EBR 및 이벤트 트리거 시 후속 변경 사항(확장)이 모두 만료되었습니다.

다음 그림에 EBR이 적용된 C-Clip에 대한 세 가지 시나리오가 나와 있습니다.

l C1에는 이벤트가 트리거되기 전에 이미 만료된 고정 또는 최소 보존이 있습니다.

l C2에는 EBR이 만료되기 전에 만료될 고정 또는 최소 보존이 있습니다.

l C3에는 EBR이 만료된 후 만료될 고정 또는 최소 보존이 있습니다.

그림 3 EBR 시나리오

호환되지 않는 네임스페이스의 경우 권한이 필요한 삭제 명령이 EBR에 대한 고정 및가변 보존을 재정의할 수 있습니다.

EBR 보존을 적용하는 경우 가변 보존 기간에 대한 최소/최대 관리자 설정을 준수해야합니다.

CAS


표 19 이벤트 기반 보존에 대한 CAS API 함수

기능 설명

FPClip_EnableEBRWithClass 이 함수는 앞으로의 이벤트를 수신할 수 있도록C-Clip을 설정하고 C-Clip 생성 시에 EBR(Event-Based Retention) 클래스를 C-Clip에 할당할 수있도록 합니다.

FPClip_EnableEBRWithPeriod 이 함수는 앞으로의 이벤트를 수신할 수 있도록C-Clip을 설정하고 C-Clip 생성 시에 EBR(Event-Based Retention) 기간을 C-Clip에 할당할 수 있도록 합니다.

FPClip_IsEBREnabled 이 함수는 C-Clip에 EBR(Event-BasedRetention)이 활성화되어 있는지 여부를 나타내는 부울 값을 반환합니다.

FPClip_GetEBRClassName 이 함수는 C-Clip에 할당된 EBR(Event-BasedRetention) 정책의 이름을 검색합니다.

FPClip_GetEBREventTime 이 함수는 C-Clip에 대한 EBR(Event-BasedRetention) 이벤트가 트리거된 경우 해당 C-Clip에 설정된 이벤트 시간을 반환합니다.

FPClip_GetEBRPeriod 이 함수는 C-Clip과 연결된 EBR(Event-BasedRetention) 기간의 값(초)을 반환합니다.

FPClip_TriggerEBREvent 이 함수는 EBR(Event-Based Retention)이 활성화된 C-Clip의 이벤트를 트리거합니다.

FPClip_TriggerEBREventWithClass 이 함수는 EBR(Event-Based Retention)이 활성화된 C-Clip의 이벤트를 트리거하고 해당 C-Clip에 새 EBR 정책을 할당합니다.

FPClip_TriggerEBREventWithPeriod 이 함수는 EBR(Event-Based Retention)이 활성화된 C-Clip의 이벤트를 트리거하고 해당 C-Clip에 새 EBR 기간을 할당합니다.

법적 증거 자료 보관CAS 애플리케이션은 법적 증거 자료 보관을 통해 C-Clip이 삭제되는 것을 일시적으로방지할 수 있습니다. 법적 증거 자료 보관은 공식 수사, 소환 또는 조사 대상으로 수사가 끝날 때까지 삭제할 수 없는 데이터에 유용합니다. 데이터를 저장할 필요가 없게 되면 애플리케이션에서 법적 증거 자료 보관을 해제할 수 있으며 정상 보존 동작이 재개됩니다. CAS 애플리케이션은 C-Clip 레벨에서 법적 증거 자료 보관을 배치 및 제거합니다.

권한이 필요한 삭제로도 법적 증거 자료 보관 상태의 C-Clip을 삭제할 수 없습니다.

C-Clip 하나에 여러 개의 법적 증거 자료 보관이 적용될 수 있습니다. 이 애플리케이션은 고유 법적 증거 자료 보관 ID를 생성하고 C-Clip과 연결된 특정 법적 증거 자료 보관을 추적할 수 있습니다. 이 애플리케이션은 이 정보에 대해 C-Clip을 쿼리할 수 없습니다. C-Clip의 법적 증거 자료 보관 상태를 결정하는 유일한 함수가 있습니다. C-Clip에하나 이상의 법적 증거 자료 보관이 있으면 이 함수는 true를 반환하고, 그렇지 않으면false를 반환합니다.

법적 증거 자료 보관을 사용하는 경우 C-Clip 수명주기는 다음과 같습니다.

CAS


l 생성: 애플리케이션에서 새 C-Clip을 생성하고 고정 및/또는 이벤트 기반 보존 기간을 제공합니다.

l 법적 증거 자료 보관 설정: 애플리케이션에서 C-Clip을 보관합니다. 이 애플리케이션은 C-Clip을 쓴 애플리케이션과 다를 수 있습니다.

l 법적 증거 자료 보관 해제: 애플리케이션에서 C-Clip을 해제합니다. 이 애플리케이션은 법적 증거 자료 보관을 설정하거나 C-Clip을 쓴 애플리케이션과 다를 수 있습니다.

l 삭제: 애플리케이션에서 C-Clip을 삭제하려는 경우 다음 조건을 충족해야 합니다.

n C-Clip에 처리되지 않은 법적 증거 자료 보관이 없습니다.

n 정책 보존이 만료되었습니다.

n 표준 버킷 보존이 만료되었습니다. (표준 버킷 보존은 모든 ECS 오브젝트 유형에 사용할 수 있지만 CAS에는 권장되지 않습니다.)

n 고정 보존 기간(CAS 전용 기능)이 만료되었습니다.

n 이벤트 기반 보존(CAS 전용 기능)이 만료되었습니다.

다음 그림에 법적 증거 자료 보관이 적용된 C-Clip에 대한 세 가지 시나리오가 나와 있습니다.

l C1에는 보관 시 이미 만료된 고정 보존이 있습니다.

l C2에는 보관 중에 만료되는 고정 보존이 있습니다.

l C3에는 보관 해제 후 만료될 고정 보존이 있습니다.

그림 4 법적 증거 자료 보관 시나리오

C-Clip에는 여러 개의 법적 증거 자료 보관이 할당될 수 있습니다. 이 경우 각 법적 증거자료 보관에는 고유 식별자가 있는 서로 다른 API 호출이 필요합니다.

법적 증거 자료 보관 ID의 최대 길이는 64자입니다. C-Clip당 법적 증거 자료 보관 ID의최대 개수는 100개입니다. CAS API에서 이러한 제한을 적용합니다.

CAS


표 20 법적 증거 자료 보관에 대한 CAS API 함수

기능 설명

FPClip_GetRetentionHold 이 함수는 C-Clip의 보관 상태를 결정하고true 또는 false를 반환합니다.

FPClip_SetRetentionHold 이 함수는 C-Clip의 보존 보관을 설정하거나재설정합니다. 법적 증거 자료 보관이 여러개인 경우, 각 보관에 대해 고유 법적 증거 자료 보관 ID를 제공합니다. 보관이 여러 개인경우, ID당 한 번씩 호출합니다.

네임스페이스 보존 정책 설정네임스페이스 보존 정책에 대한 CAS 관련 설정 지침을 제공합니다.

네임스페이스에 대한 보존 정책 기능은 네임스페이스에서 생성되는 모든 C-Clip의CAS 보존 클래스를 정의하고 관리하기 위한 방법을 제공합니다.

네임스페이스에는 다수의 보존 정책이 있을 수 있으며, 각 정책은 보존 기간을 정의합니다. (API를 사용하여) 다수의 C-Clip에 보존 정책을 적용함으로써, 보존 정책을 변경하면 그 정책과 관련된 모든 오브젝트의 보존 기간이 변경됩니다. CAS의 경우, 보존 클래스는 애플리케이션에 의해 오브젝트의 C-Clip에 적용됩니다. 오브젝트의 보존 기간이 지나지 않은 경우 오브젝트 수정 요청은 허용되지 않습니다.

절차

1. ECS포털에서 Manage > Namespace를 선택합니다.

2. 기존 네임스페이스의 구성을 편집하려면 기존 네임스페이스와 관련된 Edit 작업을 선택합니다.

3. 보존 정책을 추가하고 구성합니다.

a. Retention Policies 영역에서 Add를 선택하여 새 정책을 추가합니다.

b. 정책의 이름을 입력합니다.

c. Retention Policy의 기간을 지정합니다.

이 정책과 연결된 오브젝트가 절대로 삭제되지 않도록 하려면 Infinite 확인란을 선택합니다.

CAS

네임스페이스 보존 정책 설정 101

그림 5 새 보존 정책

4. Save를 선택합니다.

그림 6 네임스페이스에 대한 보존 정책

CAS 사용자를 위한 버킷 생성 및 설정CAS 사용자를 지원하도록 버킷을 구성합니다.

ECS에서 관리 사용자는 버킷을 생성하고 버킷 소유자가 됩니다. CAS의 경우 오브젝트사용자를 버킷 소유자로 설정해야 합니다. 다음 절차를 따라 CAS 버킷을 적절하게 설정하고 CAS 사용자를 버킷 소유자로 만듭니다. 이 예에서는 newcasadmin1이 관리 사용자, newcasuser1이 CAS 오브젝트 사용자, newcasns1이 네임스페이스입니다. 이 절차에서는 두 명의 사용자와 네임스페이스가 설정되었다고 가정합니다.

절차

1. ECS Portal에 newcasadmin1로 로그인합니다.

2. ECS포털에서 Manage > Bucket을 선택합니다.

3. New Bucket을 선택합니다.

4. 필드를 아래와 같이 입력합니다.

CAS


필드 값

Replication Group 복제 그룹

Set current user as Bucket Owner 선택

CAS 활성화됨


6. Manage > User를 선택합니다.

7. Object User 탭이 활성화되어 있는지 확인하고, newcasuser1을 검색한 다음Edit를 선택합니다.

8. Default Bucket에 newcasbucket1을 입력하고 Set Bucket을 선택합니다.

9. Close를 선택합니다.

10. Manage > Bucket을 선택합니다.

11. newcasbucket1을 검색하고 Edit bucket을 선택합니다.

12. Bucket Owner에 newcasuser1을 입력합니다.


CAS 오브젝트 사용자 설정CAS를 사용하도록 오브젝트 사용자를 설정합니다.

오브젝트 사용자를 설정할 때, CAS 프로필의 요소를 구성하는 프로필에 CAS 기능을할당할 수 있습니다. CAS 애플리케이션에서 사용하기 위한 결과 PEA 파일을 볼 수 있습니다.

절차

1. ECS포털에서 Manage > Users를 선택합니다.

2. 기존 오브젝트 사용자의 구성을 편집하려면 사용자와 관련된 Edit 작업을 선택합니다.

그림 7 오브젝트 사용자에 대한 CAS 설정

CAS

CAS 오브젝트 사용자 설정 103

3. CAS 영역에 암호를 직접 입력하거나, Generate를 선택하여 포털에서 자동으로생성하도록 합니다.

4. Set Password를 선택합니다.

5. Generate PEA File을 선택하여 애플리케이션이 ECS의 CAS 스토리지에 인증해야 하는 PEA 파일을 생성합니다.

6. 기본 버킷을 설정하면, 버킷을 지정하지 않은 채 사용자가 취하는 모든 조치에서는 지정된 기본 버킷을 사용합니다. 기본 버킷의 이름을 입력하고 Set Bucket을선택합니다.

7. Add Attribute를 선택하여 사용자에게 메타데이터 태그를 추가합니다.

8. 메타데이터 태그 이름과 값을 추가합니다.

메타데이터 태그에 관한 자세한 내용은 CAS SDK 문서를 참조하십시오.

9. Save Metadata를 선택합니다.

CAS를 위한 버킷 ACL 설정버킷의 ACL(Access Control List)을 편집하여 사용자의 액세스를 제한합니다.

일부 ECS 버킷 ACL은 CAS 권한에 매핑되지만, CAS 데이터에 의미가 없는 것도 있습니다.

절차

1. ECS포털에서 Manage > Bucket을 선택합니다.

2. 기존 버킷의 ACL을 편집하려면 기존 버킷과 연결된 Edit ACL 작업을 선택합니다.

그림 8 버킷 ACL 편집

3. 사용자와 연결된 Edit를 선택합니다.

CAS


그림 9 버킷 ACL 관리

4. 권한을 수정합니다.

표 21 버킷 ACL

ECS ACL ACL 정의

READ 읽기, 쿼리 및 존재 기능

WRITE 쓰기 및 법적 증거 자료 보관 기능

FULL_CONTROL 읽기, 삭제, 쿼리, 존재, 클립 복사, 쓰기, 법적증거 자료 보관

PRIVILEDGED_WRITE 권한이 필요한 삭제

DELETE 삭제

다른 ECS ACL은 CAS에 아무런 의미도 없습니다.


6. 그룹 수준에서 ACL을 편집할 수도 있습니다. 그룹은 사전 정의되며 그룹의 구성원은 사용자 기준을 바탕으로 자동으로 정해집니다. Group ACLs를 선택합니다.

CAS

CAS를 위한 버킷 ACL 설정 105

7. Add를 선택합니다.

8. Group Name 목록에서 편집하려는 그룹을 선택합니다.

표 22 버킷 ACL 그룹

버킷 ACL 그룹 설명

public 인증 여부에 상관없이 모든 사용자

all users 인증된 모든 사용자

other 인증된 사용자(버킷 소유자 제외)

log delivery 지원되지 않음.

9. ACL을 편집하고 Save를 선택합니다.

CAS 사용자를 지원하는 ECS Management APICAS 사용자와 프로필 설정을 관리하는 데 사용할 수 있는 ECS Management API 리소스를 설명합니다.

ECS Management API 리소스 설명:

l GET /object/user-cas/secret/{uid} : 지정된 사용자의 CAS 암호를 가져옵니다.

l GET /object/user-cas/secret/{namespace}/{uid}: 지정된 네임스페이스 및 사용자의 CAS 암호를 가져옵니다.

l POST /object/user-cas/secret/{uid}: 지정된 사용자의 CAS 암호를 생성하거나 업데이트합니다.

l GET /object/user-cas/secret/{namespace}/{uid}/pea: 지정된 사용자를 위한 PEA 파일을 생성합니다.

l POST /object/user-cas/secret/{uid}/deactivate: 지정된 사용자의CAS 암호를 삭제합니다.

l GET /object/user-cas/bucket/{namespace}/{uid}: 지정된 네임스페이스 및 사용자의 기본 버킷을 가져옵니다.

l GET /object/user-cas/bucket/{uid}: 지정된 사용자의 기본 버킷을 가져옵니다.

l POST /object/user-cas/bucket/{namespace}/{uid}: 지정된 네임스페이스 및 사용자의 기본 버킷을 업데이트합니다.

l GET /object/user-cas/applications/{namespace}: 지정된 네임스페이스의 CAS 등록 애플리케이션을 가져옵니다.

l POST /object/user-cas/metadata/{namespace}/{uid}: 지정된 네임스페이스 및 사용자의 CAS 등록 애플리케이션을 업데이트합니다.

l GET /object/user-cas/metadata/{namespace}/{uid}: 지정된 네임스페이스 및 사용자의 CAS 사용자 메타데이터를 가져옵니다.

자세한 내용은 항목을 참조하십시오.

CAS


CAS(Content Addressable Storage) SDK API 지원지원되는 버전ECS는 CAS 빌드 3.1.544 이상 버전을 지원합니다. 또한 이용 중인 ISV의 애플리케이션이 ECS를 지원하는지 확인해야 합니다.

ECS CAS 지원에 대한 자세한 내용은 ECS에서 CAS 지원 설정(90페이지)에 나와 있습니다.

CAS Query 지원ECS 2.2 버전부터 CAS Query가 지원됩니다.

ECS에서 CAS Query 작업은 기존 C-Clip 생성 시간과 삭제된 C-Clip 삭제 시간(리플렉션)을 기준으로 결과를 반환합니다. EMC Centera에서 쿼리 작업은 오브젝트 작성 시간을 기준으로 결과를 반환합니다.

ECS 3.0 이전의 ECS 버전에서 지원되지 않는 APICAS SDK API 호출은 ECS 3.0 이전의 ECS 버전에서 지원되지 않습니다.

l FPClip_EnableEBRWithClass

l FPClip_EnableEBRWithPeriod

l FPClip_SetRetentionHold

l FPClip_TriggerEBREvent

l FPClip_ TriggerEBREventWithClass

l FPClip_ TriggerEBREventWithPeriod

l FPClip_GetEBRClassName

l FPClip_GetEBREventTime

l FPClip_GetEBRPeriod

l FPClip_GetRetentionHold

l FPClip_IsEBREnabled

CAS

CAS(Content Addressable Storage) SDK API 지원 107

CAS


5부

ECS Management REST API

5장, "ECS Management REST API"


5장


l ECS Management REST API 소개..................................................................... 112l ECS Management REST API의 인증을 받습니다...............................................112


ECS Management REST API 소개이 섹션에서는 ECS Management REST API를 사용한 액세스 및 인증 방법을 설명하고API 경로에 대한 요약 정보를 제공합니다. ECS Management REST API를 사용하여 오브젝트 저장소를 구성하고 관리할 수 있습니다. 오브젝트 저장소를 구성한 후에는 ECS에서 지원되는 오브젝트 및 파일 프로토콜을 사용하여 오브젝트 생성, 읽기, 업데이트및 삭제 작업을 수행할 수 있습니다.

ECS Management REST API에 대한 자세한 내용은 다음 항목을 참조하십시오.

l ECS Management REST API의 인증을 받습니다.(112페이지)

l ECS Management REST API 요약(115페이지)

또한 ECS API 참조를 참조할 수 있습니다. 이는 소스 코드에서 자동 생성되고 API에서사용 가능한 메서드에 대한 참조를 제공합니다.

ECS Management REST API의 인증을 받습니다.

ECS는 REST API 호출에 토큰 기반 인증 시스템을 사용합니다. 이 섹션에서는 쿠키를사용하거나 사용하지 않는 경우 ECS API로 인증하는 예를 제시합니다.

ECS에서 인증되면 ECS API에서 인증 토큰이 반환되며, 후속 호출 시 인증에 이 토큰을사용할 수 있습니다.

l 클라이언트가 자동으로 리디렉션을 따르면 ECS API에서 HTTP 401 코드가 반환됩니다. 이 경우 로그인 후 인증을 거쳐 새 토큰을 받아야 합니다.

l 클라이언트가 자동으로 리디렉션을 따르지 않으면 ECS API에서 HTTP 302 코드가반환됩니다. 302 코드는 클라이언트에 다시 인증을 받을 곳을 지정합니다.

다음 방법으로 인증 토큰을 검색하고 사용할 수 있습니다.

l 성공적인 인증 요청에서 X-SDS-AUTH-TOKEN 쿠키를 저장하고 후속 요청에 따라해당 쿠키를 보냅니다.

l 성공적인 인증 요청에서 X-SDS-AUTH-TOKEN HTTP 헤더를 읽고 후속 요청에 해당 헤더를 복제합니다.

ECS API는 포트 :4443에서 사용할 수 있고 클라이언트는 다음 형식으로 로그인 요청을발급하여 ECS에 액세스합니다.

https://<ECS_IP>:4443/login

쿠키를 사용하지 않고 인증다음 예제에서는 성공한 인증 요청에서 X-SDS-AUTH-TOKEN HTTP 헤더를 읽어 후속요청에 복제하여 인증 토큰을 사용하는 방법을 보여줍니다. 이 예제에서는 쿠키를 사용하지 않습니다. 이 예제는 curl 명령줄 툴을 사용하여 작성되고 읽기 쉽도록 조정되었습니다.

다음 ECS API 호출은 /login 리소스에서 GET를 실행합니다. -u 옵션은 기본 인증 헤더의 사용자를 지정합니다. 요청에 해당 사용자를 지정해야 합니다. 인증에 성공하면,HTTP 200 코드와 인코딩된 토큰을 포함한 X-SDS-AUTH-TOKEN 헤더가 반환됩니다.

기본 ECS API 토큰 수명은 8시간입니다. 즉, 8시간이 지나면 토큰이 더 이상 유효하지않습니다. 토큰의 기본 유휴 시간은 2시간입니다. 즉, 2시간의 유휴 시간이 지나면 토큰




이 만료됩니다. 만료된 토큰을 사용하면 /login URL로 리디렉션되고, 이후에도 만료된 토큰을 사용할 경우 HTTP 상태 오류 코드 401이 반환됩니다.

curl -L --location-trusted -k https://10.247.100.247:4443/login -u "root:ChangeMe" -v

> GET /login HTTP/1.1> Authorization: Basic cm9vdDpDaGFuZ2VNZQ==> User-Agent: curl/7.24.0 (i386-pc-win32) libcurl/7.24.0 OpenSSL/0.9.8t zlib/1.2.5> Host: 10.247.100.247:4443> Accept: */*>< HTTP/1.1 200 OK< Date: Tue, 26 Nov 2013 22:18:25 GMT< Content-Type: application/xml< Content-Length: 93< Connection: keep-alive< X-SDS-AUTH-TOKEN: BAAcQ0xOd3g0MjRCUG4zT3NJdnNuMlAvQTFYblNrPQMAUAQADTEzODU0OTQ4NzYzNTICAAEABQA5dXJu OnN0b3JhZ2VvczpUb2tlbjo2MjIxOTcyZS01NGUyLTRmNWQtYWZjOC1kMGE3ZDJmZDU3MmU6AgAC0A8=<<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn> <user>root</user></loggedIn>* Connection #0 to host 10.247.100.247 left intact* Closing connection #0* SSLv3, TLS alert, Client hello (1):

다음 예와 같이 X-SDS-AUTH-TOKEN 내용을 복제하여 curl 툴의 -H 스위치를 통해 다음 API 호출에 전달할 수 있습니다.

curl https://10.247.100.247:4443/object/namespaces -k -H "X-SDS-AUTH-TOKEN: BAAcOHZLaGF4MTl3eFhpY0czZ0tWUGhJV2xreUE4PQMAUAQADTEzODU0OTQ4NzYzNTICAAEABQA5dXJu OnN0b3JhZ2VvczpUb2tlbjpkYzc3ODU3Mi04NWRmLTQ2YjMtYjgwZi05YTdlNDFkY2QwZDg6AgAC0A8="

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <namespaces> <namespace> <id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name> </namespace></namespaces>

쿠키로 인증이 예제에서는 성공적인 인증 요청에서 쿠키를 저장한 다음 후속 요청에서 쿠키를 전달하여 인증 토큰을 사용하는 방법을 보여줍니다.

다음 예제에서는 ?using-cookies=true 매개 변수를 사용하여 정상적인 HTTP 헤더 외에 쿠키를 받으려는 의사를 표시합니다. 이 Curl 명령을 실행하면 인증 토큰이 현재 디렉토리에 cookiefile이라는 이름의 파일에 저장됩니다.

curl -L --location-trusted -k https://<ECS_IP>:4443/login?using-cookies=true


쿠키를 사용하지 않고 인증 113

-u "root:Password" -c cookiefile -v

다음 명령은 Curl 명령의 -b 스위치를 통해 인증 토큰과 함께 쿠키를 전달하고, 사용자의 테넌트 정보를 반환합니다.

curl -k https://10.247.100.247:4443/object/namespaces -b cookiefile -v

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <namespaces> <namespace> <id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name> </namespace></namespaces>

로그아웃로그아웃 API는 세션을 종료합니다.

각 사용자에게는 최대 100개의 동시 인증 토큰이 허용됩니다. 이 한계를 넘어서면, 시스템에서는 토큰을 사용할 수 있을 때까지 해당 사용자에 대한 새로운 연결을 모두 거부합니다. 토큰이 자연스럽게 만료되거나 다음 ECS API 호출을 실행하면 토큰을 사용할 수 있습니다.

GET https://<ECS_IP>:4443/logout

여러 세션이 동시에 실행 중인 경우 다음 API를 호출하면 현재 사용자와 관련된 모든 토큰이 강제로 종료됩니다.

GET https://<ECS_IP>:4443/logout?force=true

다음 예에서는 로그아웃 요청을 보여 줍니다. 로그아웃하려면 헤더 또는 쿠키에서 인증토큰을 전달합니다.

GET https://<ECS_IP>:4443/logout

X-SDS-AUTH-TOKEN:{Auth_Token}

응답은 HTTP 200여야 합니다.

ECS Management REST API whoami 명령ECS 사용자는 whoami API 호출을 사용하여 자신의 사용자 이름, 테넌트 연결 및 역할을 볼 수 있습니다.



요청

GET https://<ECS_IP>:4443/user/whoami

다음 응답에서는 루트 사용자와 ns1 네임스페이스에 대한 NAMESPACE_ADMIN 역할에 할당된 사용자에 대한 whoami 출력을 보여줍니다.

응답

HTTP 200

GET /user/whoami<user> <common_name>root</common_name> <distinguished_name/> <namespace/> <roles> <role>SYSTEM_ADMIN</role> </roles></user>

HTTP 200

GET /user/whoami<user> <common_name>[email protected]</common_name> <distinguished_name/> <namespace>ns1</namespace> <roles> <role>NAMESPACE_ADMIN</role> </roles></user>

ECS Management REST API 요약ECS Management REST API를 사용하여 ECS 오브젝트 저장소를 구성하고 관리할 수있습니다.

다음 표에는 ECS Management REST API가 요약되어 있습니다.

표 23 ECS Management REST API메서드 요약

API 영역 설명

구성

인증서 /object-cert인증서를 관리하기 위한 API입니다.

/object-cert/keystoreECS에 사용되는 인증서 체인을 지정하고 순환하기 위한 API입니다.

구성 속성 /config/object/properties사용자 범위를 GLOBAL 또는 NAMESPACE로 설정하기 위한 API입니다. 이는 첫 번째 사용자가 생성되기 전에 설정되어야 합니다. 기본값은 GLOBAL입니다.

GLOBAL 범위에서는 사용자가 글로벌이며 네임스페이스 간 공유가 가능합니다. 이 경우, 사용자와 연결된 기본 네임스페이스가 오브젝트 작


ECS Management REST API 요약 115

표 23 ECS Management REST API메서드 요약 (계속)

API 영역 설명

업을 위한 네임스페이스를 결정하고 작업을 위해 네임스페이스를 제공할 필요가 없습니다. NAMESPACE 범위에서는 사용자가 네임스페이스와 연결됩니다. 이 경우 각각 다른 네임스페이스와 연결되어 있지만이름은 같은 사용자가 둘 이상 있을 수 있으므로 모든 작업에 네임스페이스가 제공되어야 합니다.

라이센스 등록 /license라이센스를 추가하고 라이센스 세부 정보를 검색하기 위한 API입니다.

기능 /feature/기능에 대한 세부 정보를 검색하기 위한 API입니다.

Syslog /vdc/syslog/configSyslog 구성을 관리하고 문제 해결 및 디버깅 목적으로 Syslog 서버에알림을 보내기 위한 API입니다.

SNMP /vdc/snmp/configSNMP 구성을 관리하고 문제 해결 및 디버깅 목적으로 SNMP 서버에알림을 보내기 위한 API입니다.

CAS

CAS 사용자 프로필 /object/user-casCAS 사용자에게 암호 키를 할당하고 PEA(Pool Entry Authorization)를생성하기 위한 API입니다.

파일 시스템 액세스

NFS /object/nfsECS 버킷을 기반으로 NFS 내보내기를 생성하고 UNIX 사용자 및 그룹이 내보내기에 액세스할 수 있도록 하기 위한 API입니다.

사용량 측정

비용 청구 /object/billing테넌트 및 버킷 레벨에서 오브젝트 저장소 사용량을 측정하기 위한API입니다.

마이그레이션

변환 /object/transformation데이터를 변환할 수 있는 API입니다.

모니터링

용량 /object/capacity현재 관리되는 용량을 검색하기 위한 API입니다.

대시보드

알림 /vdc/alerts




API 영역 설명

감사 알림을 검색하기 위한 API입니다.

이벤트 /vdc/events지정된 네임스페이스에 대한 감사 이벤트를 반환하는 API입니다.

멀티 테넌시

네임스페이스 /object/namespaces네임스페이스를 생성하고 관리하기 위한 API입니다.

또한, 네임스페이스의 보존 기간을 설정할 수 있습니다. 보존 기간에대한 자세한 내용은 ECS Product Documentation 페이지에 있는 ECS관리 가이드 항목을 참조하십시오.

원거리 복제

복제 그룹 /data/data-service/vpools복제 그룹을 생성 및 관리하기 위한 API입니다.

일시적 장애 영역 /tempfailedzone/모든 또는 지정된 복제 그룹에 대한 일시적 장애 발생 영역을 검색하기위한 API입니다.

프로비저닝

기본 URL /object/baseurl기존 애플리케이션이 ECS 오브젝트 저장소와 작동할 수 있도록 해주는 기본 URL을 생성하기 위한 API입니다. 기본 URL에 대한 자세한 내용은 ECS Product Documentation 페이지에 있는 ECS 관리 가이드 항목을 참조하십시오.

버킷 /object/bucket버킷을 프로비저닝하고 관리하기 위한 API입니다.

/object/bucket/{bucketName}/lock버킷 액세스를 잠그기 위한 API입니다.

데이터 저장소 /vdc/data-stores파일 시스템(/vdc/data-stores/filesystems) 또는 상용 노드(/vdc/data-stores/commodity)에서 데이터 저장소를 생성하기 위한 API입니다.

노드 /vdc/nodes클러스터에 대해 현재 구성되어 있는 노드를 검색하기 위한 API입니다.

스토리지 풀 /vdc/data-services/varrays스토리지 풀을 생성하고 관리하기 위한 API입니다.

가상 데이터 센터 /object/vdcs


ECS Management REST API 요약 117




API 영역 설명

VDC를 추가하고 VDC 엔드포인트 간 그리고 ECS 사이트 간 데이터 복제를 위해 암호 키를 지정하기 위한 API입니다.

VDC 키 저장소 /vdc/keystoreVDC에 대한 인증서를 관리하기 위한 API입니다.

지원

Call Home /vdc/callhome/ESRS 구성을 관리하고 ConnectEMC에 알림을 보내기 위한 API입니다.

CLI 패키지 /cliECS CLI 패키지를 다운로드하기 위한 API입니다.

사용자 관리

인증 공급자 /vdc/admin/authproviders인증 공급자를 추가 및 관리하기 위한 API입니다.

암호 그룹(Swift) /object/user-passwordOpenStack Swift 인증에 사용할 암호를 생성하기 위한 API입니다.

암호 키 /object/user-secret-keys오브젝트 사용자에 암호 키를 할당하고 암호 키를 관리하기 위한 API입니다.

암호 키 셀프 서비스 /object/secret-keys오브젝트 저장소의 네임스페이스 내에 있는 오브젝트와 버킷에 액세스할 수 있도록 S3 사용자가 새 암호 키를 생성할 수 있는 API입니다.

사용자(오브젝트) /object/users오브젝트 사용자를 생성하고 관리하기 위한 API입니다. 오브젝트 사용자는 항상 네임스페이스와 연결됩니다. API는 S3 액세스에 사용할 수있는 암호 키를 반환합니다. S3 암호 키에 할당된 오브젝트 사용자는REST API를 사용하여 이를 변경할 수 있습니다.

/object/users/lock.

사용자 액세스를 잠그기 위한 API입니다.

/object/users/{userName}/tags.

사용자 ID와 태그를 연결하기 위한 API입니다. 태그는 이름=값 쌍 형식입니다.

사용자(관리) /vdc/users사용자를 생성하고 관리하기 위한 API입니다. 관리 사용자를 SystemAdministrator 역할 또는 Namespace Administrator 역할에 할당할 수있습니다. 이 API를 사용하여 로컬 관리 사용자 암호를 변경할 수 있습니다.



6부

HDFS

6장, "ECS HDFS 소개"

7장, "ECS HDFS를 사용하여 단순 Hadoop 클러스터 구성"

8장, "ECS HDFS를 사용하여 Kerberized Hadoop 클러스터 구성"

9장, "문제 해결"

10장, "부록: Kerberos 구성에 대한 지침"

11장, "부록: ECS HDFS의 Hadoop core-site.xml 속성"

12장, "부록: 보안 버킷 메타데이터 예"

HDFS 119

HDFS


6장

ECS HDFS 소개

l ECS HDFS 소개................................................................................................ 122l ECS HDFS를 사용하도록 Hadoop 구성 ............................................................123l Hadoop 인증 모드............................................................................................. 123l 단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션.......................127l 파일 시스템 상호 작용...................................................................................... 128l 지원되는 Hadoop 애플리케이션....................................................................... 128

ECS HDFS 소개 121

ECS HDFS 소개ECS HDFS는 ECS 스토리지 인프라스트럭처를 기반으로 Hadoop 2.x 애플리케이션을실행할 수 있게 해 주는 HCFS(Hadoop Compatible File System)입니다.

ECS HDFS를 사용하는 경우 기본으로 제공되는 Hadoop 파일 시스템 대신 ECS HDFS에서 Hadoop 배포판을 실행하도록 구성됩니다. 다음 그림은 ECS HDFS와 기존Hadoop 클러스터의 통합 방식을 보여 줍니다.

그림 10 Hadoop 클러스터에 통합된 ECS HDFS

Hadoop Cluster

ResourceManager

Hadoop Client

ECS Client Library

Node Manager

MapReduce Task

Appliance Software

MapReduce Request

Node Manager

MapReduce Task

Node Manager

MapReduce Task

ECS nodes

ECS nodes

ECSnodes

ECS Client Library ECS Client Library

ECS HDFS를 사용하도록 구성된 Hadoop 환경에서 ECS 노드 각각은 기존 HadoopNameNode 및 DataNode의 역할을 합니다. 다시 말해, 모든 ECS 노드는 HDFS 요청을받아서 처리할 수 있습니다.

Hadoop 클라이언트를 기존 HDFS가 아닌 ECS HDFS를 사용하도록 설정하면 ECSHDFS가 모든 HDFS 활동을 수행하게 됩니다. 각 ECS HDFS 클라이언트 노드에서 기존의 모든 Hadoop 구성 요소는 ECS Client Library(ViPRFS JAR 파일)를 사용하여 HDFS활동을 수행하게 됩니다.

ECS HDFS를 기존 Hadoop 환경과 통합하려면 다음 요구 사항을 충족해야 합니다.

ECS HDFS 소개


l Hadoop 클러스터가 이미 설치 및 구성되어 있어야 합니다. 다음 배포판이 지원됩니다.

n Hortonworks HDP 2.5

l Hadoop 클러스터가 설치되어 있고 ECS HDFS를 지원하도록 구성되어 있어야 합니다. 이를 위해서는 다음이 필요합니다.

n HDFS에 액세스하기 위한 파일 시스템 지원 버킷

Hadoop 클러스터당 하나의 버킷만 지원되며 ECS HDFS가 기본 파일 시스템이어야 합니다.

n ECS 클라이언트 라이브러리가 클러스터에 구축되어 있어야 합니다.

l Hadoop 클러스터의 경우 Kerberos를 사용하거나 Active Directory와 Kerberos를 사용해야 합니다.

n Kerberos 구성 파일 및 서비스 보안 주체 keytab 파일이 ECS 클러스터에 구축되어 있어야 합니다.

n 보안 메타데이터가 버킷에 구축되어 있어야 합니다.

ECS HDFS를 사용하도록 Hadoop 구성Hadoop은 core-site.xml, hdfs-site.xml, hive-site.xml을 비롯한 여러 파일에 시스템 구성 정보를 저장합니다. ECS HDFS를 구성하려면 core-site.xml을 편집해야 합니다.

core-site.xml 파일에서 다음을 비롯한 여러 유형의 속성을 추가하거나 수정해야합니다.

l ECS HDFS Java 클래스: 이 속성 세트는 ECS HDFS Client Library에 포함되어 있는ECS HDFS 구축 클래스를 정의하며,

l 파일 시스템 위치 속성: 이 속성은 Hadoop 작업을 실행할 때 사용할 파일 시스템URI(체계 및 권한)와 특정 ECS 파일 시스템에 사용할 ECS 데이터 노드의 IP 주소또는 FQDN을 정의합니다.

l Kerberos 영역 및 서비스 보안 주체 속성: 이 속성은 Kerberos가 있는 Hadoop 환경에서만 필요하며, Hadoop 및 ECS HDFS 사용자를 매핑합니다.

core-site.xml 파일은 Hadoop 클러스터의 각 노드에 위치합니다. core-site.xml의 각 인스턴스에 동일한 속성을 추가해야 합니다.

구성 파일을 수정할 경우 수동으로 파일을 편집하지 말고 관리 인터페이스(Ambari)를사용해야 합니다. Ambari 관리 인터페이스를 사용하여 수행한 변경 내용은 클러스터전체에 걸쳐 유지됩니다.

Hadoop 인증 모드Hadoop은 사용자 ID를 확인하는 데 단순 모드와 Kerberos 모드의 두 가지 작업 모드를지원합니다.

단순단순 모드에서는 클라이언트 프로세스의 ID가 호스트 운영 체제에 의해 확인됩니다. Unix와 유사한 시스템에서는 사용자 이름이 whoami와 동일합니다.

ECS HDFS 소개

ECS HDFS를 사용하도록 Hadoop 구성 123

Kerberos

Kerberos를 사용하는 Hadoop 환경에서는 클라이언트 프로세스의 ID가 해당Kerberos 자격 증명에 의해 확인됩니다. 예를 들어, kinit 유틸리티를 사용하여Kerberos TGT(Ticket-Granting-Ticket)를 획득하고 klist를 사용하여 현재 보안주체를 확인할 수 있습니다. auth_to_local Hadoop 속성을 사용하여 Kerberos보안 주체를 HDFS 사용자 이름에 매핑하는 경우 기본 구성 요소를 제외한 모든 구성 요소가 삭제됩니다. 예를 들어 todd/[email protected]이라는 보안 주체는 HDFS에서 단순한 사용자 이름인 “todd”로 작동합니다.

ECS HDFS는 단순 인증 모드 또는 Kerberos 인증 모드를 사용하도록 구성된 Hadoop클러스터와 통합됩니다.

Hadoop 클러스터가 Kerberos를 사용하는 경우 [email protected] 형식의 Kerberos 보안 주체가 할당된 사용자에게 액세스 권한을 부여하도록 ECS를 구성할 수 있습니다.또한, ECS가 AD를 사용하여 사용자를 인증하는 경우에는 사용자가[email protected] 형식의 AD 자격 증명을 사용하여 인증을 받을 수 있도록 Kerberos환경과 AD 사이에 단방향 트러스트를 구성할 수 있습니다.

새로 생성되는 파일 및 디렉토리의 사용 권한은 umask(fs.permissions.umask-mode)에 의해 제한됩니다. 권장되는 umask는 022입니다.

파일 시스템으로 버킷 액세스HDFS 파일 시스템 스토리지는 ECS 버킷으로 제공됩니다. 버킷을 생성할 때 이를 파일시스템으로 사용할 수 있게 설정하도록 ECS에서 구성해야 합니다.

ECS(ECS 클라이언트 라이브러리를 통해)는 Hadoop core-site.xml 파일 내 설정및 버킷에 대해 구성된 사용 권한을 사용하여 루트 파일 시스템(버킷)에 대한 액세스권한을 확인합니다. Hadoop 사용자 및 서비스가 버킷에서 파일 및 디렉토리를 생성할수 있을 정도로 충분한 액세스 권한을 구성했는지 확인해야 합니다.

일반적으로 모든 파일 및 디렉토리 작업이 버킷 ACL에서 허용되어야 합니다. 또한 버킷 내 개별 파일 및 디렉토리 오브젝트에 자체 오브젝트 ACL이 있고 해당 오브젝트ACL에서 모든 오브젝트 작업이 허용되어야 합니다. 버킷 ACL을 충족하지 않는 오브젝트 작업은 거부됩니다. 또한 오브젝트 ACL을 충족하지 않는 오브젝트 작업도 거부됩니다.

이에 대한 예외로, 버킷 소유자와 hdfs-site.xml에 정의된 Hadoop 수퍼 그룹의Hadoop 수퍼 유저 및 구성원은 버킷 및 오브젝트 ACL에 관계없이 모든 파일 시스템 작업을 수행할 수 있도록 항상 허용됩니다.

버킷 ACL은 개별 사용자 모두에 대해 버킷에 사용자 ACL을 명시적으로 추가하거나 사용자 지정 그룹 ACL을 지정하여 설정할 수 있습니다. 자세한 내용은 버킷 사용자 지정그룹 ACL 및 기본 그룹(125페이지) 항목을 참조하십시오. 버킷 소유자는 ECS 오브젝트 사용자여야 합니다. 다른 사용자는 ECS 오브젝트 사용자일 필요가 없으며 Hadoop클러스터의 Unix 사용자 이름일 수 있습니다.

또 다른 예외가 있습니다. 일반 ECS 버킷과 달리 파일 시스템 지원 ECS 버킷에는 루트디렉토리를 나타내는 특수 오브젝트와 각 디렉토리의 특수 오브젝트가 있습니다. 새 파일 시스템 지원 버킷에는 루트 디렉토리 오브젝트가 없으며 해당 버킷에서 첫 번째 파일 시스템 작업이 수행될 때 루트 디렉토리 오브젝트가 생성됩니다. 이러한 루트 디렉토리 오브젝트가 있으면 일부 ECS HDFS API 호출이 버킷 ACL 확인을 수행하지 않습니다.

API 호출에 관계없이 일관된 사용 권한을 갖도록 하려면 루트 디렉토리 오브젝트 ACL이 버킷 ACL을 복제하도록 해야 합니다.

ECS HDFS 소개


사용자가 파일 시스템에 대한 액세스 권한을 갖게 되면 이러한 사용자가 생성하는 파일및 디렉토리에는 core-site.xml 파일에서 umask 속성으로 확인되는 사용 권한이할당됩니다.

버킷 사용자 지정 그룹 ACL 및 기본 그룹사용자 ACL을 기반으로 하거나 사용자 지정 그룹 ACL을 할당하는 방식으로 버킷에 대한 액세스를 활성화할 수 있습니다. 사용자 지정 그룹은 Hadoop 클러스터에 정의된 사용자 그룹의 이름이며, 이를 통해 Hadoop 사용자는 HDFS를 사용하여 버킷에 액세스할수 있습니다.

Hadoop 클러스터에 정의되는 일반적인 그룹은 hdfs(hdfs 사용자 포함), hadoop(일반적으로 모든 서비스 사용자 포함), users(Hadoop 클러스터에서 애플리케이션에 액세스하는 기타 서비스 계정이 아닌 사용자 포함)이며, ECS Portal에서 해당 그룹을 생성하고 이 그룹에 사용 권한을 할당할 수 있습니다.

또한 버킷에 대해 기본 그룹을 할당할 수도 있습니다. 기본 그룹은 루트(/) 파일 시스템에 할당되는 그룹입니다. 예를 들어, 버킷 소유자가 hdfs이고 기본 그룹이 hadoop으로 설정된 경우 /는 hdfs:hadoop으로 설정됩니다. 이는 각각 사용자 및 그룹에 해당합니다. 기본 그룹은 사용자 지정 그룹이기도 하므로 사용자 지정 그룹 ACL 목록에 표시됩니다.

기본 그룹이 정의되지 않은 경우 아래 예와 같이 파일 시스템의 루트에 그룹이 없습니다.

drwx---rwx+ - hdfs 0 2015-12-09 12:30 /

기본 그룹으로 hadoop이 정의된 경우 소유권 및 사용 권한이 다음 예와 같이 표시됩니다.

drwxrwxrwx+ - hdfs hadoop 0 2015-12-09 12:28 /

이러한 사용 권한은 루트에서 생성되는 디렉토리에서 상속되지 않습니다.

기본 그룹이 할당되지 않은 경우 버킷 소유자(루트 파일 시스템 소유자)는 hdfs dfs-chgrp 및 hdfs dfs -chmod 명령을 사용하여 Hadoop에서 HDFS에 액세스할 때 그룹을 할당할 수 있습니다.

Hadoop 수퍼유저 및 수퍼그룹

Hadoop 환경에서 수퍼 유저는 namenode를 시작하는 사용자이며, 대개 hdfs 또는[email protected]입니다. ECS HDFS 구성에서 수퍼 유저는 버킷 소유자입니다. 따라서, Hadoop 환경에서 Active Directory를 사용하여 사용자를 인증하는 경우 Hadoop 수퍼 유저가 ECS 버킷에 대한 수퍼 유저 액세스 권한을 갖도록 하려면 hdfs,[email protected] 또는 [email protected]이 버킷을 소유하는지 확인해야 합니다.

Hadoop 클라이언트가 수퍼 유저 액세스 권한을 가지도록 하려면 core-site.xml 파일에서 dfs.permissions.superusergroup 속성을 사용하여 수퍼 유저 그룹을 구성할 수도 있습니다. 단순 모드에서는 사용자가 수퍼 그룹 구성원인지 확인하는 검사가dfs.permissions.supergroup Hadoop 속성의 값을 확인하는 방식으로 클라이언트에서 수행됩니다. Kerberos 모드에서는 사용자가 수퍼그룹 구성원인지 확인하는 검사가 ECS 서버에서 수행됩니다.

일반적으로 버킷이 Hadoop 수퍼 유저 또는 Hadoop 수퍼 유저 그룹의 액세스에 대해 구성된 경우 수퍼 유저가 버킷에 대한 전체 액세스 권한(읽기 및 쓰기)을 가집니다. 수퍼유저 권한이 없는 사용자는 일반적으로 읽기 액세스 권한을 가지지만 버킷이 생성된 방

ECS HDFS 소개

버킷 사용자 지정 그룹 ACL 및 기본 그룹 125

식에 따라 달라집니다. 사용자가 버킷에 대한 액세스 권한을 부여받기 위해 ECS 오브젝트 사용자일 필요는 없습니다. 이름은 Unix 로컬 사용자, Kerberos 사용자 또는 AD 사용자(사용되는 인증 모드에 따라 다름)와 일치해야 합니다.

hdfs 사용자나 hdfs 보안 주체가 버킷 소유자(수퍼 유저)이거나 수퍼 유저 그룹의 구성원인 것이 가장 좋습니다.

멀티 프로토콜(교차 헤드) 액세스ECS는 S3 프로토콜을 사용하여 버킷에 데이터를 쓰고 HDFS를 통해 데이터를 파일로사용할 수 있도록 하는 기능을 지원합니다.

멀티 프로토콜 액세스(교차 헤드 액세스라고도 함)는 S3 프로토콜을 사용하여 버킷에쓰여진 오브젝트가 MapReduce와 같은 Hadoop 작업의 주체가 될 수 있음을 의미합니다. 마찬가지로, HDFS에서 기록한 디렉토리 및 파일도 S3 클라이언트를 사용하여 읽고수정할 수 있습니다.

S3를 사용하여 기록된 데이터를 파일 형태로 액세스할 수 있게 하기 위해 버킷 관리자는 버킷에 대한 기본 그룹을 설정하고 이 그룹이 소유하는 파일 및 디렉토리에 대한 기본 사용 권한을 설정할 수 있습니다. S3에서 생성된 오브젝트에 소유자뿐만 아니라HDFS가 Hadoop 클러스터에서 액세스할 수 있는 그룹 구성원 자격 및 사용 권한도 부여될 수 있도록 이러한 오브젝트에 이 기본 Unix 그룹이 할당됩니다.

HDFS를 사용하여 생성되고 S3 프로토콜을 사용하여 액세스되는 파일에는 기본 사용권한이 적용되지 않습니다. 기본 사용 권한은 S3 프로토콜을 사용하여 생성되는 오브젝트에만 적용됩니다.

프록시 사용자ECS HDFS는 Hadoop 프록시 사용자 사용을 지원합니다.

프록시 사용자를 통해 Hadoop 사용자는 다른 사용자를 대신하여 작업을 제출하거나HDFS에 액세스할 수 있습니다. 프록시 사용자 기능은 한 사용자가 실행 파일에 대한사용 권한 설정으로 식별되는 다른 사용자의 ID를 가장하므로 명령 실행 측면에서UNIX/Linux의 유효한 사용자 기능과 비교될 수 있습니다.

네임스페이스별(또는 버킷별)로 보안 가장을 위한 프록시 사용자를 구성합니다. 프록시 사용자는 단순 모드와 Kerberos 모드에서 지원됩니다. 두 모드 모두 관리자는hadoop.proxyuser.*.* 속성을 사용하여 프록시 가장을 제한할 수 있습니다.

동등 사용자ECS는 3개 파트로 구성된 보안 주체를 2개 파트로 구성된 보안 주체로 변환합니다.

Kerberos 보안 주체는 일반적으로 인스턴스가 필요하지 않은 경우에도 primary/instance@realm 형식입니다. 따라서 primary@realm 보안 주체는 영역 내 모든 호스트에 적용됩니다. 인스턴스를 지정하는 경우 이를 통해 특정 호스트(예: joe/[email protected] 또는 joe/[email protected])를 지정할 수 있습니다. 이 두 보안 주체는 모두 동일한 기본 사용자(joe)에 대한 것이지만, 호스트(host1 또는 host2)에서만 인증을받도록 지정되었습니다.

강화된 수준의 보안을 제공하려면 이러한 유형의 사용자 보안 주체를 사용하는 것이 좋습니다. ECS 측면에서 각 보안 주체는 ECS에 추가되어야 합니다. 이 작업은 상당히 번거로워지고 있습니다. 따라서 동등 사용자 기능을 사용하면 3개 파트로 구성된 보안 주체가 사용되는 경우에도 2개 파트로 구성된 보안 주체(primary@realm)를 사용하여ECS 인증이 수행되도록 할 수 있습니다.

ECS HDFS 소개


단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션ECS는 단순 Hadoop 환경에서 Kerberos로 보안이 유지되는 Hadoop 환경으로 마이그레이션을 지원합니다.

ECS HDFS가 단순 보안을 사용하는 Hadoop 환경에 통합된 경우 Hadoop 사용자 및 프로세스가 생성하는 파일 및 디렉토리는 비보안 사용자가 소유하게 됩니다. 이후Kerberos 보안을 사용하도록 Hadoop 클러스터를 마이그레이션하면 이러한 사용자가ECS HDFS에 기록된 파일 및 디렉토리에 더 이상 액세스하지 못하게 됩니다.

ECS는 마이그레이션 기능을 기본 제공합니다. 사용자는 이를 통해 ECS에 간단한 이름및 Kerberos 보안 주체 간 매핑을 제공할 수 있습니다. 그렇게 하면 매핑된 Kerberos 보안 주체로 비보안 간단한 이름 사용자가 소유하는 파일에 액세스할 수 있습니다.

간단한 이름 사용자가 기록한 파일의 수가 적은 경우 Kerberos 보안 주체가 소유하도록chown을 사용하여 소유자를 변경할 수 있습니다. 하지만 이러한 파일의 수가 많은 경우 마이그레이션 기능을 사용하면 많은 수의 파일에 대한 소유권을 변경할 필요가 없습니다.

이 기능은 버킷에 대해서는 구현되지 않으므로 사용자별 액세스를 사용하는 경우Kerberos 보안 주체를 기준으로 액세스를 허용하도록 버킷 ACL을 변경해야 합니다. 하지만 액세스를 활성화하는 기본 수단으로 그룹 구성원 자격을 사용하는 경우 버킷 ACL을 변경할 필요가 없습니다.

ECS에서는 그룹을 사용하여 버킷, 파일 및 디렉토리에 대한 액세스를 단순화할 수 있습니다. 그룹은 항상 UNIX의 단순한 이름을 사용하므로, 버킷에 연결된 그룹 이름, 파일 또는 디렉토리는 단순 클러스터에서 액세스하든 Kerberized 클러스터에서 액세스하든 동일합니다. 단순 환경에서 액세스하는 경우 그룹 구성원 자격은 UNIX 시스템에서확인합니다. Kerberized 클러스터에서 액세스하는 경우에는 매핑을 할당하여 그룹 구성원 자격을 구성할 수 있습니다. 매핑 그룹 이름에 대한 자세한 내용은 그룹 이름 매핑(149페이지) 항목을 참조하십시오.

AD 자격 증명을 사용하는 경우, AD 보안 주체와 UNIX 보안 주체 간 매핑은 도메인 접미사를 제거하여 이루어지므로 [email protected] 사용자는 hdfs가 됩니다. 이는hdfs에 [email protected]과 같은 매핑을 허용하는 Kerberos 보안 주체 매핑을 사용하는 경우만큼 유연하지는 않습니다.

AD에 그룹을 사용하는 경우 그룹의 구성원 자격이 확인될 수 있도록 인증 공급자가ECS에 구성되어 있어야 합니다.

Hadoop Kerberos 인증 모드Kerberos와 ECS AD 서버가 통합될 때 Kerberos 영역은 사용자의 단일 네임스페이스를제공하므로 kinit로 인증받은 Hadoop 사용자는 자격 증명이 있는 ECS 사용자로 인식됩니다.

Kerberos 모드로 실행 중인 Hadoop 클러스터에서 ECS 사용자를 인증하려면 Kerberos영역에서 AD 영역으로 진행되는 단방향 교차 영역 트러스트가 있어야 합니다.

Hadoop과 ECS 간의 적절한 사용자 변환을 위해 core-site.xml 파일에서 다음과 같은 ID 변환 속성이 사용됩니다.

l fs.permissions.umask-mode: 값을 022로 설정합니다.

l fs.viprfs.auth.anonymous_translation: 값을 CURRENT_USER로 설정합니다.

l fs.viprfs.auth.identity_translation: 값을 CURRENT_USER_REALM으로 설정합니다. 그러면 사용자 영역이 자동으로 검색됩니다.

ECS HDFS 소개

단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션 127

또한 서비스 보안 주체를 정의하려면 core-site.xml 파일에서 다음 속성을 설정해야 합니다.

l viprfs.security.principal: vipr/[email protected](REALM.COM은Kerberos 영역 이름으로 대체됨)

파일 시스템 상호 작용ECS HDFS와 직접 상호 작용하는 경우, 표준 HDFS 파일 시스템과 상호 작용할 때와 달리 다음과 같은 차이점이 나타날 수 있습니다.

l 파일 시스템이 DistributedFileSystem의 인스턴스가 되어야 하는 애플리케이션은작동하지 않습니다. 기본 제공 HDFS 구축 환경에 대해 작동하도록 하드코딩된 애플리케이션이 ECS HDFS를 사용하려면 변경이 필요합니다.

l ECS HDFS는 데이터의 체크섬을 지원하지 않습니다.

l listCorruptFileBlocks 함수를 사용할 때 모든 블록이 OK로 보고됩니다. 이는 ECSHDFS에 손상된 블록에 대한 개념이 없기 때문입니다.

l 복제 인수가 항상 상수 N(여기서는 N=1)으로 보고됩니다. 데이터는 Hadoop 복제가 아닌 ECS SLA로 보호됩니다.

지원되는 Hadoop 애플리케이션ECS HDFS는 Hadoop 환경에 속하는 대부분의 애플리케이션을 지원합니다.

Hadoop 환경에서 지원되는 애플리케이션은 다음과 같습니다.

l Yarn

l MapRedeuce

l Pig

l Hive

l Spark

l Zookeeper

l Ambari

l Sqoop

l Flume

ECS HDFS 소개


7장

ECS HDFS를 사용하여 단순 Hadoop 클러스터구성

l ECS HDFS와 단순 Hadoop 클러스터 통합........................................................ 130l Ambari를 사용하여 Hortonworks HDP 설치......................................................130l ECS Portal을 사용하여 HDFS에 사용할 버킷 생성............................................132l ECS HDFS 및 Hadoop 통합 계획...................................................................... 139l ECS HDFS 설치 및 지원 패키지 가져오기.........................................................139l ECS HDFS Client Library 구축.......................................................................... 140l ECS 클라이언트 속성 구성................................................................................ 141l Hive 설정.......................................................................................................... 142l ECS에 대한 Hadoop 액세스 확인...................................................................... 143l 버킷에 보안 적용.............................................................................................. 144l HDFS에서 ECS 버킷으로 기본 파일 시스템 재배치.......................................... 145

ECS HDFS를 사용하여 단순 Hadoop 클러스터 구성 129

ECS HDFS와 단순 Hadoop 클러스터 통합ECS HDFS와 함께 ECS 스토리지 인프라스트럭처를 사용하도록 Hadoop 배포판을 구성할 수 있습니다.

이 통합 절차를 수행하려면 다음이 필요합니다.

l Hadoop 배포판 및 관련 툴에 대한 최신 지식

l Hadoop 노드에 로그인해서 Hadoop 시스템 파일을 수정하고 Hadoop 서비스를 시작 및 중지하는 데 사용할 수 있는 Hadoop 자격 증명

다음 단계를 수행해야 합니다.

1. Ambari를 사용하여 Hortonworks HDP 설치(130페이지)

2. ECS Portal을 사용하여 HDFS에 사용할 버킷 생성(132페이지)

3. ECS HDFS 및 Hadoop 통합 계획(139페이지)

4. ECS HDFS 설치 및 지원 패키지 가져오기(139페이지)

5. ECS HDFS Client Library 구축(140페이지)(Ambari Hortoworks for ECS를 사용하는 경우에는 수행할 필요 없음)

6. ECS 클라이언트 속성 구성(141페이지)

7. ECS에 대한 Hadoop 액세스 확인(143페이지)

8. HDFS에서 ECS 버킷으로 기본 파일 시스템 재배치(145페이지)

구성이 완료되면 Hadoop 클러스터의 기본 파일 시스템에 있는 파일이 ECS 버킷에 있는 파일에 매핑됩니다. 예를 들어 기본 파일 시스템에 있는 /foo/bar가 viprfs://<bucket_name>.<namespace>.<federation_name>/foo/bar에 매핑됩니다.

Ambari를 사용하여 Hortonworks HDP 설치Ambari 서버를 설치하고 이 서버를 사용해 Hortonworks HDP를 설치합니다.

이 절차에는 Ambari 서버를 설치하고 설정하기 위한 기본 명령이 나와 있습니다.Ambari 서버를 설치하는 방법에 대한 자세한 내용은 Hortonworks 설명서를 참조하십시오.

절차

1. Ambari 저장소를 다운로드합니다.

wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.4.2.0/ambari.repo -O /etc/yum.repos.d/ambari.repo

2. Ambari 서버를 설치합니다.

yum install -y ambari-server

3. Ambari 서버를 설정합니다.

ambari-server setup -s

ECS HDFS를 사용하여 단순 Hadoop 클러스터 구성


https://docs.hortonworks.com/HDPDocuments/Ambari-2.4.2.0/bk_ambari-installation/content/ch_Getting_Ready.html

4. Ambari 서버를 시작합니다.

ambari-server start

5. http://ambari.example.com:8080/으로 이동합니다.

6. Select Stack 페이지에서 Hadoop 버전, HDP 2.5를 선택하고 OS 버전을 선택합니다.

7. 다음 예에 나와 있는 대로, 활성화하려는 Hadoop 서비스를 선택합니다.


Ambari를 사용하여 Hortonworks HDP 설치 131

8. 설치 마법사를 완료합니다.

ECS Portal을 사용하여 HDFS에 사용할 버킷 생성ECS Portal을 사용하여 HDFS에 사용하도록 구성된 버킷을 생성할 수 있습니다.



시작하기 전에

Namespace Administrator 또는 System Administrator 역할이 할당되어 있어야 합니다.Namespace Administrator인 경우 자신의 네임스페이스에 버킷을 생성할 수 있습니다.System Administrator인 경우에는 어떤 네임스페이스에 속한 버킷이라도 생성할 수 있습니다.

Hadoop 사용자 및 서비스에 HDFS 파일 시스템(버킷)에 대한 액세스 권한이 있고 파일및 디렉토리를 적절한 사용자 및 그룹에서 액세스할 수 있도록 해야 합니다. 다음 방법을 사용하여 이 작업을 수행할 수 있습니다.

l 버킷 소유자를 Hadoop 수퍼 유저(대개 hdfs 또는 [email protected])와 동일하게설정합니다.

l 그룹 구성원 자격을 기준으로 버킷에 대한 액세스를 활성화합니다.

n 기본 그룹을 버킷에 할당합니다. 그러면 사용자 지정 그룹 ACL이 자동으로 할당됩니다.

n 버킷 생성을 마친 후 액세스가 필요한 다른 그룹에 대해서도 사용자 지정 그룹ACL을 추가합니다.

l 버킷에 사용자 ACL을 추가하여 개별 사용자의 액세스 권한을 활성화합니다.

l HDFS에 대한 수퍼유저 액세스 권한이 필요한 Hadoop 사용자는 Hadoop 수퍼그룹에 속해 있어야 합니다.

오브젝트 프로토콜을 사용하여 버킷에 쓰여진 오브젝트 데이터를 HDFS에서 액세스할수 있게 하려면 기본 그룹이 버킷에 할당되어 있고 기본 파일 및 디렉토리 사용 권한이이 그룹에 설정되어 있어야 합니다.

사용자 및 사용 권한에 대한 자세한 내용은 파일 시스템으로 버킷 액세스(124페이지)및 Hadoop 및 ECS 버킷 사용 권한 예(137페이지) 항목을 참조하십시오.

절차

1. ECS Portal에서 Manage > Buckets > New Bucket을 선택합니다.

2. New Bucket 페이지의 Name 필드에 버킷의 이름을 입력합니다.

URI Java 클래스는 밑줄을 지원하지 않으므로 버킷 이름에 밑줄을 사용하지 마십시오. 예를 들어 viprfs://my_bucket.ns.site/는 유효하지 않은 URI여서 작동하지 않기 때문에 Hadoop에서 인식하지 못합니다.

3. Namespace 필드에서 버킷이 속할 네임스페이스를 선택합니다.

4. Replication Group 필드에서 네임스페이스에 사용할 복제 그룹을 선택합니다.기본 복제 그룹을 사용하려면 빈 상태로 둡니다.

5. Bucket Owner 필드에 버킷 소유자의 이름을 입력합니다.

HDFS 버킷의 경우 버킷 소유자는 일반적으로 hdfs이고, Kerberos 버킷의 경우에는 [email protected]입니다. Hadoop hdfs 사용자는 HDFS에 대한 수퍼 유저 권한이 있어야 하고, 이 권한은 hdfs를 버킷 소유자로 지정함으로써 부여할수 있습니다. 기타 Hadoop 사용자도 수퍼 유저 권한이 필요할 수 있으며, 이러한권한은 사용자를 그룹에 할당하고 그룹을 수퍼 유저 그룹으로 지정하는 방식으로 부여할 수 있습니다.

6. CAS를 활성화하지 마십시오.


ECS Portal을 사용하여 HDFS에 사용할 버킷 생성 133

HDFS로 사용하도록 생성된 버킷을 CAS에 사용할 수는 없습니다. File System이 활성화된 경우 CAS 필드가 비활성화됩니다.

7. 필요한 다른 모든 버킷 기능을 활성화합니다.

HDFS 버킷에 대해 다음과 같은 기능을 활성화할 수 있습니다.

l Quota

l Server-side Encryption

l Metadata Search

l Access During Outage

l 규정 준수(참고 참조)

l Bucket Retention

이러한 각각의 설정과 이를 구성하는 방법에 대한 자세한 내용은 ECS ProductDocumentation 페이지에 있는 ECS 관리 가이드에서 확인할 수 있습니다.

규정 준수가 설정된 버킷에는 HDFS 프로토콜을 사용하여 데이터를 쓸 수 없습니다. 하지만 오브젝트 프로토콜을 사용하여 쓴 데이터는 HDFS에서 읽을 수 있습니다.

8. File System 필드에서 Enabled를 선택합니다.

파일 시스템이 활성화되면 파일 시스템/버킷의 기본 그룹을 설정하는 필드와 버킷에 생성된 파일 및 디렉토리의 그룹 권한을 할당하는 컨트롤을 사용할 수 있습니다. 다음 예에 이러한 필드가 나와 있습니다.

9. Default Bucket Group 필드에 기본 버킷 그룹의 이름을 입력합니다.

이 그룹이 HDFS 루트 파일 시스템에 연결되는 그룹이고, 이 그룹을 통해 그룹의구성원인 Hadoop 사용자가 HDFS에 액세스할 수 있습니다.

기본 그룹은 HDFS의 데이터에 액세스해야 하는 서비스가 속하는 그룹(예: hdfs또는 hadoop)일 수 있지만, Hadoop 구성에 적합하기만 하다면 어떠한 그룹 이름이든 가능합니다. 예를 들어, 관리자가 버킷에 업로드된 모든 S3 파일이





S3DataUsers라는 그룹에 할당되도록 할 수도 있습니다. 이 경우 모든 S3 파일에 이 그룹이 할당됩니다. Hadoop 노드에서 Hadoop 관리자는 S3DataUsers 그룹에 속하는 사용자를 가지게 됩니다. S3DataUsers는 Linux 그룹이거나 AD 그룹일 수 있습니다. Hadoop 사용자가 S3 데이터에 액세스하려는 경우 파일이 해당 그룹에 업로드되고 할당되었기 때문에 액세스가 가능합니다.

버킷 생성 시 기본 그룹을 지정해야 합니다. 그렇지 않은 경우, 파일 시스템 소유자가 Hadoop에서 나중에 이 그룹을 할당해야 합니다.

10. Group File Permissions 및 Group Directory Permissions 필드에 오브젝트 프로토콜을 사용하여 버킷에 생성되는 파일 및 디렉토리의 기본 사용 권한을 설정합니다.

이러한 설정은 오브젝트 프로토콜을 사용하여 생성되는 오브젝트에 UNIX 그룹사용 권한을 적용하는 데 사용됩니다. 이들 사용 권한은 오브젝트나 디렉토리가Hadoop에 나열된 경우 HDFS 그룹(기본 버킷 그룹)에 적용됩니다. 파일 시스템에 대한 기본 그룹 및 사용 권한을 설정하는 방법에 대한 자세한 내용은 멀티 프로토콜(교차 헤드) 액세스(126페이지)에서 확인할 수 있습니다.

a. Group File Permissions 필드에서 적절한 사용 권한 버튼을 선택합니다. 일반적으로 Read 및 Execute 권한을 설정합니다.

b. Group Directory Permissions 필드에서 적절한 사용 권한 버튼을 선택합니다. 일반적으로 Read 및 Execute 권한을 설정합니다.

11. Save를 클릭하여 버킷을 생성합니다.

사용자 지정 그룹 버킷 ACL 설정ECS Portal에서 버킷에 대한 그룹 ACL을 설정할 수 있으며 사용자 그룹(사용자 지정그룹 ACL), 개별 사용자 또는 이 둘 모두에 버킷 ACL을 설정할 수 있습니다. 예를 들어사용자 그룹에 전체 버킷 액세스 권한을 부여할 수 있지만, 해당 그룹에 속한 개별 사용자로 버킷 액세스를 제한(또는 거부)할 수도 있습니다.

시작하기 전에

l 이 작업을 수행하려면 ECS에서 System Administrator 또는 NamespaceAdministrator 역할이 필요합니다.

l System Administrator는 어떤 네임스페이스에 속한 버킷이라도 그룹 ACL 설정을편집할 수 있습니다.

l Namespace Administrator는 관리자 권한을 가진 네임스페이스에 속한 버킷에 대한그룹 ACL 설정을 편집할 수 있습니다.

사용자 지정 그룹 ACL을 통해 그룹을 정의하고 이 그룹에 사용 권한을 할당할 수 있습니다. 그룹을 버킷에 할당하는 주요 활용 사례는 버킷을 NFS 또는 HDFS용으로 사용할수 있도록 설정하는 경우와 같이 파일 시스템으로서의 버킷에 대한 액세스를 제공하는것입니다.

UNIX 그룹의 구성원은 버킷을 파일 시스템(NFS 또는 HDFS)으로서 액세스할 수 있습니다.

절차

1. ECS Portal에서 Manage > Buckets를 선택합니다.

2. Bucket Management 페이지의 테이블에서 편집하려는 버킷을 찾아 Edit ACL작업을 선택합니다.

3. Custom Group User ACLs를 클릭하여 사용자 지정 그룹의 ACL을 설정합니다.

4. Add를 클릭합니다.


사용자 지정 그룹 버킷 ACL 설정 135

다음 스크린샷에 나온 것처럼 Edit Custom Group 페이지가 표시됩니다.

5. Edit Custom Group 페이지의 Custom Group Name 필드에 그룹의 이름을 입력합니다.

이 이름은 UNIX/Linux 그룹이거나 Active Directory 그룹일 수 있습니다.

6. 그룹에 대한 사용 권한을 설정합니다.

최소한 Read, Write, Execute, Read ACL을 할당해야 합니다.


사용자 버킷 ACL 설정ECS Portal에서 버킷에 대한 사용자 ACL을 설정할 수 있습니다. 버킷 소유자에는 사용권한이 자동으로 할당됩니다. 기타 Hadoop 사용자에는 사용자 ACL을 할당할 수 있습니다. 이 ACL을 통해 버킷/파일 시스템에 대한 액세스가 허용됩니다. 또한, 사용자 지정 그룹 ACL이 할당된 그룹의 구성원이 됨으로써 버킷에 대한 액세스 권한을 부여받을수도 있습니다.

시작하기 전에

l ECS Namespace Administrator 또는 System Administrator여야 버킷의 ACL을 편집할 수 있습니다.

l Namespace Administrator 사용자는 자신의 네임스페이스에 속한 버킷의 ACL 설정을 편집할 수 있습니다.

l System Admin 사용자는 어떤 네임스페이스에 속한 버킷이라도 ACL 설정을 편집할수 있습니다.



절차

1. ECS Portal에서 Manage > Buckets를 선택합니다.

2. Bucket Management 페이지의 테이블에서 편집하려는 버킷을 찾아 Edit ACL작업을 선택합니다.

3. Bucket ACLs Management 페이지에서 User ACLs 탭이 선택되어 있는지 확인합니다. 이는 기본 설정입니다.

4. User ACLs 탭에서 이미 권한이 할당된 사용자의 권한을 편집하거나 권한을 할당하려는 사용자를 추가할 수 있습니다.

l 이미 권한이 있는 사용자에 대한 ACL 권한을 설정하거나 제거하려면 ACL 테이블의 Action 열에서 Edit(또는 Remove)를 선택합니다.

l 사용 권한을 할당할 사용자를 추가하려면 Add를 클릭하고 사용 권한이 적용될 사용자의 사용자 이름을 입력합니다. 사용자에게 적용할 권한을 지정합니다.

버킷 소유자로 설정한 사용자는 이미 할당된 기본 권한을 가지고 있습니다.

다음 예에 나온 버킷은 hdfs 사용자가 소유하며, 소유자로서 hdfs에 전체 제어권한이 부여되어 있습니다. Hadoop/UNIX 환경에서 전체 제어 권한은 읽기, 쓰기 및 실행 권한을 의미합니다. sally 사용자에게는 버킷에 대한 읽기 및 실행액세스 권한이 부여되어 있습니다.

ACL 권한에 대한 자세한 내용은 ECS Product Documentation 페이지에 있는ECS 관리 가이드 항목을 참조하십시오.


Hadoop 및 ECS 버킷 사용 권한 예이 항목에는 Hadoop 사용자/그룹과 ECS 사용자 ACL 및 사용자 지정 그룹 ACL을 통해버킷에 액세스할 수 있도록 사용 권한이 할당되는 사용자/그룹 사이의 관계에 대한 예가 나와 있습니다.

버킷 생성 시 설정되는 ECS는 버킷 소유자와 HDFS를 사용하여 액세스할 때 버킷에 할당된 기본 그룹에 자동으로 ACL을 할당합니다. 버킷에는 항상 소유자가 있어야 하지만, 기본 그룹은 버킷에 할당되지 않아도 됩니다. 버킷 소유자가 아닌 사용자와 그룹(사용자 지정 그룹이라고 함)에 버킷에 대한 ACL을 할당할 수 있으며, 이렇게 할당된 ACL은 Hadoop 사용자에 대한 사용 권한으로 해석됩니다.


Hadoop 및 ECS 버킷 사용 권한 예 137


표 24 단순 Hadoop 클러스터에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예

Hadoop 사용자 및 그룹 버킷 권한 버킷/파일 시스템 액세스

그룹 ACL을 사용한 버킷 액세스

사용자(서비스)

hdfs. mapred, yarn, hive, pig

사용자(애플리케이션)

sally, fred

그룹

hdfs(hdfs)

hadoop(hdfs, mapred, yarn, hive, pig)

사용자(sally, fred)

수퍼그룹hdfs

버킷 소유자입니다hdfs

기본 그룹

사용자 지정 그룹 ACL

hadoop, users, hive,spark(전체 제어 권한)

사용자 ACL

hdfs(소유자)

ECS Portal에서 버킷에 대해 설정되는 사용자지정 그룹 ACL은 버킷/루트 파일 시스템에 대한 전체 제어 권한을 hadoop,users, hive 및spark 그룹에 할당합니다.

이 예에서는 hdfs가 수퍼 유저, 즉 namenode

를 시작한 사용자라고 가정합니다.

s3 사용자가 생성하는 버킷 - 교차 헤드 액세스


hdfs. mapred, yarn, hive, pig


sally, fred

그룹

hdfs(hdfs)

hadoop(hdfs, mapred, yarn, hive, pig)

사용자(sally, fred)

수퍼그룹hdfs

버킷 소유자입니다s3user

기본 그룹hadoop(그룹 파일 사용 권한: 읽기, 쓰기

그룹 디렉토리 사용 권한:읽기, 쓰기, 실행)


hadoop(기본값)

사용자 ACL

s3user(소유자), sally,fred

S3 사용자가 쓰는 오브젝트가 HDFS에서 파일로 액세스될 수 있도록 하려는 경우 Hadoop 사용자 및 서비스에 그룹 구성원 자격을 기반으로 파일에 대한 사용 권한이 부여되도록 기본그룹(hadoop)이 정의되어 있어야 합니다.

기본 그룹에는 자동으로 버킷/파일 시스템에대한 사용자 지정 그룹 ACL이 할당됩니다. 다음 예제에서는 hadoop이 기본 그룹으로 설정되었고 루트 파일 시스템 사용 권한이 777인것을 보여 줍니다.

drwxrwxrwx+ - s3user hadoop 0 2015-12-09 12:28 /

사용자에게는 사용자 ACL을 추가하거나 사용자가 속한 그룹에 대한 사용자 지정 그룹 ACL을 추가하여 액세스 권한을 부여할 수 있습니다.

표 25 Kerberized Hadoop 클러스터에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예

Hadoop 사용자 버킷 사용 권한 버킷/파일 시스템 액세스


[email protected]@REALM.COM,[email protected],[email protected], [email protected]

버킷 소유자입니다[email protected]

기본 그룹hadoop

Portal에서 버킷에 설정된 사용자 지정 그룹ACL을 통해 hadoop 및 users 그룹은 버킷/

루트 파일 시스템에 대한 사용 권한을 가질 수있습니다.

Hadoop 클러스터의 사용자 정보는 ECS가 버킷에 대한 보안 액세스를 제공할 수 있도록ECS에서 사용할 수 있어야 합니다. 이 정보는버킷 메타데이터를 사용하여 제공되며 예제 메



표 25 Kerberized Hadoop 클러스터에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예

Hadoop 사용자 버킷 사용 권한 버킷/파일 시스템 액세스


[email protected],[email protected], [email protected]

그룹

hdfs([email protected])

hadoop([email protected],[email protected],[email protected],[email protected],[email protected])

사용자([email protected],[email protected])

수퍼그룹hdfs


hadoop(기본), 사용자

사용자 ACL

[email protected](소유자)

타데이터 파일은 보안 버킷 메타데이터(182페이지)에 나와 있습니다.

ECS HDFS 및 Hadoop 통합 계획성공적인 통합을 위해 다음 표를 이용해 필요한 정보를 가지고 있는지 확인합니다.

표 26 ECS HDFS 구성 사전 요구 사항

요소 해야 할 일

Hadoop 클러스터 클러스터가 설치되어 작동 중인지 확인합니다.

이 절차에서 나중에 사용할 관리 자격 증명을 기록합니다.

ECS 클러스터:ECS 노드

이 절차에서 나중에 사용할 ECS 노드 IP 주소를 기록합니다.

ECS 클러스터: 버킷 HDFS에서는 ECS 복제 그룹 내에 HDFS를 지원하는 버킷을 생성해야하며, 이 버킷은 네임스페이스와 버킷 이름을 사용하는 파일 시스템으로서 액세스됩니다.

버킷의 이름을 기록합니다.

ECS 클러스터: 테넌트네임스페이스

테넌트 네임스페이스가 구성되어 있는지 확인합니다. 이름을 기록합니다.

ECS HDFS 설치 및 지원 패키지 가져오기ECS HDFS 클라이언트 라이브러리 및 HDFS 지원 툴은 HDFS 클라이언트 ZIP 파일인hdfsclient-<ECS version>-<version>.zip으로 제공되며, 이 파일은support.emc.com의 ECS 지원 페이지에서 다운로드할 수 있습니다.


ECS HDFS 및 Hadoop 통합 계획 139

ZIP 파일에는 /playbooks 및 /client 디렉토리가 포함되어 있습니다. 파일의 압축을 풀기 전, 파일의 내용물을 담을 디렉토리를 만든 후(사용 중인 압축 해제 툴에서 이작업이 자동으로 수행될 수 있음) 이 디렉토리에 압축을 풉니다. 파일 압축을 풀면 디렉토리에 다음 항목들이 나타납니다.

l /playbooks: ECS HDFS와 통신하도록 보안 Hadoop 환경을 구성하기 위한Ansible Playbook이 있습니다.

l /client: 다음 파일이 포함되어 있습니다.

n ECS 클라이언트 라이브러리(ViPRFS) JAR 파일(viprfs-client-<ECSversion>-hadoop-<Hadoop version>.jar): 다른 Hadoop 배포판을 구성하는 데 사용됩니다.

ECS HDFS Client Library 구축이 절차를 사용하여 Hadoop 클러스터를 구성하는 각 클라이언트 노드의 클래스 경로에 ECS HDFS Client Library JAR을 설치합니다.

시작하기 전에ECS HDFS 설치 및 지원 패키지 가져오기(139페이지)의 설명에 따라 ECS 지원 페이지에서 Hadoop 배포판용 ECS HDFS Client Library를 가져옵니다.

HDFS Client Library는 다음과 같은 명명 규칙 viprfs-client-<ECS version>-hadoop-<Hadoop version>.jar을 사용하며 각 릴리즈에 사용할 수 있는 JAR 파일은 다음 표에 나와 있습니다.

표 27 ECS HDFS Client Library

Hadoop 배포 버전 ECS HDFS JAR

Hortonworks HDP 2.5 viprfs-client-<ECS version>-hadoop-2.7.jar

l 최신 버전의 ECS로 업그레이드하는 경우 업그레이드한 릴리즈에 대해 ECS HDFSClient Library를 구축해야 합니다.

절차

1. 암호 없이 SSH를 통해 모든 Hadoop 노드에 액세스할 수 있는 노드에 로그인합니다.

2. 클래스 경로 명령을 실행하여 클래스 경로에 포함된 디렉토리 목록을 가져옵니다.# hadoop classpath

3. 다음 단계를 수행하여 모든 Hadoop 노드에 클라이언트 JAR 파일을 배포합니다.

a. 모든 Hadoop 마스터 노드의 IP 주소 또는 FQDN이 줄당 하나씩 나열된 목록이 들어 있는 masters라는 이름의 텍스트 파일을 생성합니다.

b. 모든 Hadoop 작업자 노드의 IP 주소 또는 FQDN이 줄당 하나씩 나열된 목록이 들어 있는 workers라는 이름의 텍스트 파일을 생성합니다.

c. 모든 노드에 대해 /usr/lib/hadoop/lib 디렉토리를 생성합니다. 다음 명령을 사용합니다.

# cat masters workers | xargs -i -n 1 ssh root@{} mkdir -p /usr/lib/hadoop/lib



d. 다음 명령을 사용하여 모든 노드에 ECS 클라이언트 jar를 복사합니다.

cat masters workers | xargs -i -n 1 scp viprfs-client-3.1.0.0-hadoop-2.7.jar root@{}:/usr/lib/hadoop/lib/

ECS 클라이언트 속성 구성Ambari를 사용하여 ECS 클라이언트에 필요한 다음 구성 속성을 설정할 수 있습니다.

core-site.xml 매개 변수에 대한 자세한 내용은 ECS HDFS의 Hadoop core-site.xml속성(176페이지) 항목을 참조하십시오.

표 28 ECS 액세스를 활성화하기 위한 Hadoop 구성

Hadoop의 위치

속성 값

core-site fs.viprfs.impl com.emc.hadoop.fs.vipr.ViPRFileSystem

fs.AbstractFileSystem.viprfs.impl com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem

fs.viprfs.auth.identity_translation NONE

fs.viprfs.auth.anonymous_translation LOCAL_USER

fs.vipr.installations 원하는 이름(예: federation1)을 설정할 수 있고$FEDERATION으로 지칭됩니다.여러 개의 독립적인 ECS 페더레이션을 사용하는 경우여러 개의 값을 쉼표로 구분하여 입력합니다.

fs.vipr.installation.$FEDERATION.hosts 로컬 사이트에 있는 각 ECS 호스트의 FQDN 또는 IP주소 목록으로 쉼표로 구분된 형식입니다.

fs.vipr.installation.$FEDERATION.hosts.resolution dynamic

fs.vipr.installation.$FEDERATION.resolution.dynamic.time_to_live_ms

900000

hdfs-site fs.permissions.umask-mode 022

yarn-site yarn.application.classpath 다음을 추가합니다.

/usr/lib/hadoop/lib/*

mapred-site mapreduce.application.classpath 다음을 추가합니다.



ECS 클라이언트 속성 구성 141

표 28 ECS 액세스를 활성화하기 위한 Hadoop 구성 (계속)

Hadoop의 위치

속성 값

tez-site tez.cluster.additional.classpath.prefix 다음을 추가합니다.


HDFS hadoop-env template 다음을 추가합니다.

export HADOOP_CLASSPATH=${HADOOP_CLASSPATH}:/usr/lib/hadoop/lib/*

Spark spark-env template 다음을 추가합니다.

export SPARK_DIST_CLASSPATH="${SPARK_DIST_CLASSPATH}:/usr/lib/hadoop/lib/*:/usr/hdp/current/hadoop-client/client/guava.jar"

Hive 설정다음 절차에 나온 추가 단계가 Hive를 구성하는 데 필요합니다.

시작하기 전에

Hive를 사용하는 경우 Hive metastore 웨어하우스가 ViPRFS 위치로 지정되어 있는지확인해야 합니다. mysql을 사용하여 Hive metastore 위치를 식별한다고 할 경우 mysql을 시작한 후 Hive 데이터베이스로 이동하여 DB 테이블의 컨텐츠를 표시하고 아래와같이 설정합니다.

절차

1. Hive에서 templeton을 사용하는 경우 다음 속성을 수정해야 하며 이러한 속성이이미 정의되어 있어야 합니다.

표 29 Hive templeton 구성

Hadoop의 위치 속성 값(예)

Advanced webhcat-site templeton.hive.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/hive/hive.tar.gz

templeton.pig.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/pig/pig.tar.gz

templeton.sqoop.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/sqoop/sqoop.tar.gz

templeton.streaming.jar viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/mapreduce/hadoop-streaming.jar



2. mysql을 시작합니다.

[root@hdfs-pansy2 lib]# mysql -u hive -pEnter password: Welcome to the MySQL monitor. Commands end with ; or \g.

3. Hive 데이터베이스로 이동합니다.

mysql> use hive;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -A

4. 데이터베이스의 컨텐츠를 표시합니다.

select * from DBS;+------+-------------+-----------------------------------+--------+-------+------+|DB_ID | DESC | DB_LOCATION_URI | NAME | OWNER | OWNER|| | | | | _NAME | _TYPE|+------+-------------+-----------------------------------+--------+-------+------+| 1 | Default Hive| hdfs://hdfs-pansy1.ecs.lab.emc. |default |public |ROLE || | database | com:8020/apps/hive/warehouse | | | || | | | | | || 6 | NULL | viprfs://hdfsbucket.ns.Site1/ |retail |hdfs |USER || | | apps/hive/warehouse/retail_demo.db| _demo | | |+------+-------------+-----------------------------------+--------+-------+------+2 rows in set (0.00 sec)

5. 데이터베이스를 변경합니다.

mysql> update DBS set DB_LOCATION_URI='viprfs://hdfsbucket3.ns.Site1/apps/hive/warehouse' where DB_ID=1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0

ECS에 대한 Hadoop 액세스 확인ECS 버킷에 대한 액세스를 확인해야 합니다.

모든 Hadoop 클라이언트 서비스가 시작된 후에 Hadoop CLI를 사용하여 ECS 버킷에액세스할 수 있는지 확인합니다. URI는 viprfs://bucket.namespace.federation/ 형식입니다.

URI가 viprfs://hive-warehouse-1.ns1.federation1/인 버킷의 경우 다음을사용하여 디렉토리 열거를 시도할 수 있습니다.

[root@mycluster1-master-0 ~]# hdfs dfs -ls viprfs://hive-warehouse-1.ns1.federation1/

새 버킷은 비어 있고 아무것도 반환되지 않습니다.


ECS에 대한 Hadoop 액세스 확인 143

동일한 버킷에 대해 다음 명령은 빈 파일을 생성하고 디렉토리 열거를 통해 해당 파일을 표시합니다.

[root@mycluster1-master-0 ~]# hdfs dfs -touchz viprfs://hive-warehouse-1.ns1.federation1/hive-warehouse-1[root@mycluster1-master-0 ~]# hdfs dfs -ls viprfs://hive-warehouse-1.ns1.federation1/

버킷에 보안 적용버킷 ACL을 구성하는 것 외에도 버킷을 생성한 후 즉시 루트 디렉토리 항목을 생성하고 보안을 적용해야 합니다.

시작하기 전에

이 절차는 버킷 소유자(이 예에서 hdfs)로 수행해야 합니다.

절차

1. 버킷 소유자와 기본 그룹만 버킷에 액세스할 수 있도록 루트 디렉토리 오브젝트ACL에서 모드 비트를 설정합니다. 모든 ECS HDFS 클라이언트 사용자를 포함한other 그룹은 루트 디렉토리 액세스가 허용되지 않으므로 버킷에 있는 모든 파일에 대한 액세스가 허용되지 않습니다.

[hdfs@hadoop-0 ~]$fs=viprfs://bucket.ns.fedhadoop fs -chmod 750 $fs/hadoop fs -chown hdfs:hdfs $fs/

2. setfacl 명령을 사용하여 특정 그룹 및 사용자를 루트 디렉토리 오브젝트 ACL에 추가해야 합니다.

이러한 사용 권한은 버킷의 사용자 지정 그룹 ACL을 복제하여 모든 HDFS API가동일한 유효 사용 권한을 갖게 됩니다.

hadoop fs -setfacl -m group:hadoop:r-x $fs/hadoop fs -setfacl -m group:users:r-x $fs/hadoop fs -setfacl -m group:hive:r-x $fs/hadoop fs -setfacl -m group:spark:r-x $fs/

3. 사용 권한을 확인합니다.

hadoop fs -ls -d $fs/drwxr-x---+ - hdfs hdfs 0 2017-08-22 20:44 viprfs://bucket.ns.fed/

hadoop fs -getfacl $fs/# file: viprfs://bucket.ns.fed/# owner: hdfs# group: hdfsuser::rwxgroup::r-xgroup:hadoop:r-xgroup:hive:r-xgroup:spark:r-xgroup:users:r-x



mask::r-xother::---

HDFS에서 ECS 버킷으로 기본 파일 시스템 재배치시스템이 현재 사용 가능하고 제대로 작동하는 것으로 나타날 수 있지만 HDFS를 기본파일 시스템으로 구성하는 것은 지원되지 않습니다. 따라서 기본 파일 시스템을 HDFS에서 ECS 버킷으로 재배치해야 합니다. 이 절차에서는 HDFS 파일 시스템의 모든 파일을 ECS 버킷에 복제한 후 ECS 버킷을 기본 파일 시스템으로 설정합니다.

절차

1. Ambari를 사용하여 HDFS, YARN 및 Zookeeper를 제외한 모든 서비스를 중지합니다.

2. DAS HDFS 파일 시스템에 있는 모든 기존 파일을 ECS 버킷에 복제합니다.Hadoop을 새로 설치하는 경우에도 기본 Hadoop 파일 시스템에 존재해야 하는중요한 디렉토리가 있습니다. DistCp를 사용하여 파일 복제를 수행합니다.

[hdfs@mycluster1-master-0~]$ hadoop distcp -skipcrccheck -update -pugp -i / viprfs://mycluster1-root.ns1.federation/

3. Ambari를 사용하여 다음 설정을 구성합니다.

표 30 Hive 동시 접속 및 ACID 트랜잭션을 활성화하도록 Hadoop 구성

Hadoop의 위치 속성 값(예)

HDFS Advanced core-site fs.defaultFS viprfs://<bucket_name>.<namespace>.<federation_name>예:

viprfs://mycluster1-root.ns1.federation1

Spark Advanced spark-defaults spark.eventLog.dir viprfs://<bucket_name>.<namespace>.<federation>/<spark-history>예:

viprfs://mycluster1-root.ns1.federation1/spark-history

Spark Advanced spark-defaults spark.history.fs.logDirectory viprfs://<bucket_name>.<namespace>.<federation>/<spark-history>예:

viprfs://mycluster1-root.ns1.federation1/spark-history

4. Ambari를 사용하여 모든 서비스를 중지했다가 시작합니다.


HDFS에서 ECS 버킷으로 기본 파일 시스템 재배치 145

5. 적절한 디렉토리 사용 권한을 확인합니다. DistCp에서 오류가 발생하는 경우필요한 사용 권한이 중요 디렉토리에 적용되지 않았기 때문일 수 있습니다. 다음명령을 사용하여 올바른 사용 권한을 설정합니다.

[hdfs@mycluster1-master-0~]$hadoop fs -chmod 777 /apps/hive/warehousehadoop fs -chown hive:hdfs /apps/hive/warehousehadoop fs -chmod -R 770 /user/ambari-qahadoop fs -chown -R ambari-qa:hdfs /user/ambari-qa



8장

ECS HDFS를 사용하여 Kerberized Hadoop 클러스터 구성

l ECS HDFS와 보안 Hadoop 클러스터 통합 ....................................................... 148l 단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획........................... 148l 그룹 이름 매핑..................................................................................................149l ECS 서비스 주체를 사용하여 ECS 노드 구성....................................................149l Ambari를 사용하여 Kerberos 활성화.................................................................153l 메타데이터를 사용하여 ECS 버킷 보안 유지.................................................... 154l ECS 클라이언트 속성 재구성............................................................................157l Hadoop 서비스를 시작하고 ECS에 대한 Hadoop 액세스를 확인합니다............ 158

ECS HDFS를 사용하여 Kerberized Hadoop 클러스터 구성 147

ECS HDFS와 보안 Hadoop 클러스터 통합Kerberos를 사용하여 보안이 유지되는 기존 Hadoop 배포판을 ECS HDFS와 통합할 수있습니다.

필요에 따라 Kerberos를 활성화하는 경우 사전에 Hadoop과 ECS의 비보안 설치를 완료해야 합니다.

통합 단계를 수행하기 전에 다음을 수행해야 합니다.

l Kerberos KDC(Key Distribution Center)가 설치되어 있고 Hadoop 서비스 보안 주체의 인증을 처리하도록 구성되어 있는지 확인합니다. Active Directory를 사용하여ECS 사용자를 인증하고 있다면, Kerberos 영역과 ECS 사용자 영역 사이의 상호 영역 신뢰를 설정해야 합니다. Kerberos KDC 설정 및 트러스트 구성에 대한 자세한내용은 Kerberos 구성에 대한 지침(170페이지) 항목을 참조하십시오.

l HDFS 파일 시스템에 사용할 버킷을 생성했는지 확인합니다(ECS Portal을 사용하여 HDFS에 사용할 버킷 생성(132페이지) 참조).

l 통합 계획과 관련된 지침을 읽었는지 확인합니다(ECS HDFS 및 Hadoop 통합 계획(139페이지) 참조).

l 설치 및 지원 패키지를 다운로드했는지 확인합니다(ECS HDFS 설치 및 지원 패키지 가져오기(139페이지) 참조).

ECS HDFS를 보안 Hadoop 클러스터와 통합하려면 다음 작업을 완료합니다.

1. 단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획(148페이지)

2. 그룹 이름 매핑(149페이지)

3. ECS 서비스 주체를 사용하여 ECS 노드 구성(149페이지)

4. 메타데이터를 사용하여 ECS 버킷 보안 유지(154페이지)

5. ECS 클라이언트 속성 재구성(157페이지)

6. Hadoop 서비스를 시작하고 ECS에 대한 Hadoop 액세스를 확인합니다.(158페이지)

단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획ECS는 단순 보안을 사용하는 Hadoop 클러스터에서 Kerberos로 보안이 유지되는Hadoop 클러스터로의 마이그레이션을 지원합니다.

단순 환경에서 보안 환경으로 마이그레이션하려면 단순 클러스터에서 KerberosHadoop 클러스터로 마이그레이션(127페이지) 항목을 참조하십시오.

일반적으로, ECS 마이그레이션 기능은 Kerberos 사용자가 작동 중단 없이 원활하게 파일 및 디렉토리에 액세스할 수 있도록 지원합니다. 하지만 다음 참고 사항이 적용됩니다.

l Hadoop 클러스터에 보안을 적용하는 Ambari 마법사가 Hadoop 서비스를 시작할 때마지막 단계에서 오류를 보고합니다. 이는 예상된 동작입니다. 보안을 적용하여ECS 버킷이 재구성된 후에 Hadoop 서비스를 시작할 수 있습니다.

l 사용자 및 프로세스가 버킷에 액세스하려면 버킷에 대한 액세스 권한이 있는 그룹의 구성원이어야 합니다. 그렇지 않은 경우, Kerberos 사용자가 액세스할 수 있도록버킷 ACL을 변경해야 합니다.



그룹 이름 매핑ECS는 hdfs, hive 등과 같은 Hadoop 서비스 보안 주체에 대한 그룹 세부 정보를 매핑할 수 있어야 합니다. AD(Active Directory)를 사용 중인 경우, 버킷 메타데이터 또는AD라는 2개의 소스에서 그룹 정보를 찾을 수 있습니다. ECS는 [hdfs.fs.request]섹션에 있는 /opt/storageos/conf/hdfssvc.conf 구성 파일의 구성 매개 변수설정에서 사용할 소스를 결정합니다.

ECS에서 그룹 정보(있는 경우)를 찾을 때 AD 대신 버킷 메타데이터를 사용하도록 하려면 매개 변수를 다음과 같이 정의합니다.

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = true

ECS가 버킷 메타데이터 대신 AD에서 그룹 정보를 확인하도록 하려면 매개 변수를 다음과 같이 정의합니다.

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = false

기본값은 true이며 이 값이 정의되지 않은 경우, ECS는 버킷 메타데이터에서 Kerberos보안 주체에 대한 그룹 세부 정보를 확인합니다. 변경 사항을 모든 ECS 노드에 적용하고 모든 노드에서 dataheadsvc를 다시 시작해야 합니다.

ECS 서비스 주체를 사용하여 ECS 노드 구성ECS 서비스 주체 및 해당 keytab 파일은 각 ECS 데이터 노드에 있어야 합니다. 제공된Ansible Playbook을 사용하여 이러한 단계를 자동화해야 합니다.

시작하기 전에

이 절차를 완료하려면 다음 항목들이 있어야 합니다.

l Ansible Playbook에 액세스합니다. ECS HDFS 설치 및 지원 패키지 가져오기(139페이지)에 설명된 대로 ECS HDFS 소프트웨어 패키지에서 Ansible Playbook을 가져옵니다.

l ECS 노드 IP 주소의 목록입니다.

l KDC의 IP 주소입니다.

l 이 스크립트를 실행하는 DNS 확인이 Hadoop 호스트에 대한 DNS 확인과 같아야하며, 그렇지 않으면 vipr/_HOST@REALM이 작동하지 않습니다.

ECS는 Python 스크립트, YAML 기반 작업 목록 및 템플릿 파일로 구성된 '역할'이라는재사용 가능한 Ansible 컨텐츠를 제공합니다.

l vipr_kerberos_config: Kerberos에 대한 ECS 노드를 구성합니다.

l vipr_jce_config: JCE 정책 파일을 설치하여 무제한 강도의 암호화를 위한ECS 데이터 노드를 구성합니다.

l vipr_kerberos_principal: ECS 노드에 대한 서비스 주체를 인식합니다.

이 절차에서 Ansible은 ECS와 함께 설치된 유틸리티 Docker 컨테이너를 사용하여 실행됩니다.


그룹 이름 매핑 149

절차

1. ECS 노드 1에 로그인한 후 해당 노드에 hdfsclient-<ECS version>-<version>.zip 파일을 복사합니다.

예: /home/admin/ansible . wget를 사용하여 support.emc.com에서 직접패키지를 가져오거나, 다른 컴퓨터에 다운로드한 경우 scp를 사용할 수 있습니다.

2. hdfsclient-<ECS version>-<version>.zip 파일의 압축을 풉니다.

이 절차의 단계에서는 viprfs-client-<ECS version>-<version>/playbooks/samples 디렉토리에 포함된 Playbook을 사용하고 단계 역시viprfs-client-<ECS version>-<version>/playbooks/samples/README.md에 포함됩니다.

3. ECS 데이터 노드 및 KDC 서버를 참조하도록 playbooks/samples 디렉토리의 inventory.txt 파일을 편집합니다.

기본 항목은 아래에 표시되어 있습니다.

[data_nodes]192.168.2.[100:200]

[kdc]192.168.2.10

4. oracle.com에서 무제한의 JCE 정책 아카이브를 다운로드하고 viprfs-client-<ECS version>-<version>/playbooks/samples의UnlimitedJCEPolicy 디렉토리에 압축을 풉니다.

강력한 암호화 유형을 사용 중인 경우에만 이 단계를 수행해야 합니다.

Kerberos는 AES-256과 같은 강력한 암호화 유형을 사용하도록 구성될 수 있습니다. 이 경우 ECS 노드 내에서 JRE를 재구성하여

정책을 사용하도록 해야 합니다.

5. ECS 노드 1에서 유틸리티 컨테이너를 시작하고 Ansible Playbook을 컨테이너에서 사용할 수 있도록 합니다.

a. 유틸리티 컨테이너 이미지를 로드합니다.

예:

sudo docker load -i /opt/emc/caspian/checker/docker/images/utilities.txz

b. docker 이미지의 ID를 가져옵니다.

예:

admin@provo-lilac:~> sudo docker images

출력에 다음과 같은 이미지 ID가 표시됩니다.

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE



utilities 1.5.0.0-403.cb6738e 186bd8577a7a 2 weeks ago 738.5 MB

c. 시작하고 유틸리티 이미지를 입력합니다.

예:

sudo docker run -v /opt/emc/caspian/fabric/agent/services/object/main/log:/opt/storageos/logs -v /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks:/ansible --name=ecs-tools -i -t --privileged --net=host 186bd8577a7a /bin/bash

이 예에서는 Ansible Playbook이 압축 해제된 위치인 /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks가유틸리티 컨테이너의 /ansible 디렉토리에 매핑됩니다.

6. 컨테이너의 작업 디렉토리로 변경합니다.

예:

cd /ansible

7. KDC에서 작업 디렉토리로 krb5.conf 파일을 복사합니다.

8. 제공된 Ansible 역할을 설치합니다.

ansible-galaxy install -r requirements.txt -f

9. 필요에 따라 generate-vipr-keytabs.yml을 편집하고 도메인 이름을 설정합니다.

예:

[root@nile3-vm22 samples]# cat generate-vipr-keytabs.yml---#### Generates keytabs for ViPR/ECS data nodes.### - hosts: data_nodes serial: 1 roles: - role: vipr_kerberos_principal kdc: "{{ groups.kdc | first }}" principals: - name: vipr/[email protected] keytab: keytabs/[email protected]

이 예에서 기본값(vipr/[email protected])이 (vipr/[email protected])으로 바뀌었고 도메인은 MA.EMC.COM입니다.

10. 다음 명령을 실행합니다.

export ANSIBLE_HOST_KEY_CHECKING=False


ECS 서비스 주체를 사용하여 ECS 노드 구성 151

11. Ansible Playbook을 실행하여 keytab을 생성합니다.

ansible-playbook -v -k -i inventory.txt --user admin –b --become-user=root generate-vipr-keytabs.yml

12. 필요에 따라 setup-vipr-kerberos.yml 파일을 편집합니다.

기본 파일 내용은 아래에 표시되어 있습니다.

# cat setup-vipr-kerberos.yml

---### # Configures ViPR/ECS for Kerberos authentication.# - Configures krb5 client # - Installs keytabs# - Installs JCE policy### - hosts: data_nodes roles: - role: vipr_kerberos_config krb5: config_file: krb5.conf service_principal: name: vipr/[email protected] keytab: keytabs/[email protected]

- role: vipr_jce_config jce_policy: name: unlimited src: UnlimitedJCEPolicy/

이 예에서 기본값(vipr/[email protected])이 (vipr/[email protected])으로 바뀌었고 도메인은 MA.EMC.COM입니다.

강력한 암호화 유형을 사용하지 않는 경우에는 vipr_jce_config 역할을 제거해야 합니다.

13. Ansible Playbook을 실행하여 ECS 서비스 주체로 데이터 노드를 구성합니다.

/ansible/samples/keytab 디렉토리가 있고 krb5.conf 파일이 작업 디렉토리 /ansible/samples에 있는지 확인합니다.

ansible-playbook -v -k -i inventory.txt --user admin –b --become-user=root setup-vipr-kerberos.yml

데이터 노드당 하나씩, 올바른 ECS 서비스 주체가 생성되었는지 확인합니다(KDC에서).

# kadmin.local -q "list_principals" | grep viprvipr/[email protected]/[email protected]



올바른 keytab이 생성되어 /data/hdfs/krb5.keytab 위치(모든 ECS 데이터노드)에 저장되어 있는지 확인합니다. keytab에서 strings 명령을 사용하여 사람이 읽을 수 있는 텍스트를 추출하고 여기에 올바른 주체가 포함되어 있는지 확인할 수 있습니다. 예:

dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytabMA.EMC.COMviprnile3-vm42.centera.lab.emc.com

이 경우 주체는 vipr/nile3-vm42.centera.lab.emc.com입니다.

Ambari를 사용하여 Kerberos 활성화Ambari를 사용하여 Kerberos를 활성화할 수 있습니다.

이 절차는 Kerberos를 활성화하기 위해 수행해야 하는 기본적인 단계를 제공합니다.Ambari Kerberos Wizard에 대한 자세한 내용은 여기를 참조하십시오.

절차

1. Ambari 인터페이스에서 Ambari > Admin > Kerberos > Enable Kerberos를 선택하여 Enable Kerberos Wizard를 시작합니다.

2. 마법사의 Kerberize Cluster 패널에 나온 단계를 수행합니다. Kerberos 마법사를중단하려면 X를 클릭합니다.

이 시점에서는 Hadoop 서비스를 시작할 수 없기 때문에 Kerberize Cluster 단계를 건너뛸 수 있습니다.

3. Confirmation 대화상자에서 Exit Anyway를 클릭하여 마법사를 종료하려 한다는것을 확인합니다.


Ambari를 사용하여 Kerberos 활성화 153

https://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Security_Guide/content/_running_the_kerberos_wizard.html

메타데이터를 사용하여 ECS 버킷 보안 유지ECS 버킷이 보안 Hadoop 클러스터에서 작동할 수 있으려면 버킷이 클러스터 관련 정보에 액세스할 수 있어야 합니다.

보안 Hadoop 클러스터에서 Kerberos 보안 주체는 HDFS 사용자 이름에 매핑되어야 합니다. 또한, 사용자는 UNIX 그룹에 매핑되어야 합니다. Hadoop 클러스터 내에서NameNode는 Hadoop 노드 자체와 구성 파일(core-site.xml 및 hdfs.xml)에서 이러한 정보를 수집합니다.

ECS 노드가 이러한 정보를 확인하고 클라이언트 요청을 검증할 수 있으려면 ECS 노드에서 다음 데이터를 사용할 수 있어야 합니다.

l UNIX 사용자 및 그룹에 대한 Kerberos 사용자 매핑

l 수퍼유저 그룹

l 프록시 사용자 설정

데이터는 메타데이터로 보존되는 이름-값 쌍 세트로 ECS 노드에서 사용할 수 있습니다.

Kerberos 사용자버킷에 대한 Hadoop 액세스가 필요한 모든 Kerberos 사용자(AD 사용자 이외)에 대한정보는 ECS에 업로드되어야 합니다. 다음 데이터가 필요합니다.

l 보안 주체 이름

l 보안 주체 간단한 이름(매핑된 이름)

l 보안 주체 그룹

Hadoop 노드에 10개의 Kerberos 보안 주체가 있는 경우 JSON 입력 파일에 30개의 이름-값 쌍을 생성해야 합니다. 모든 이름은 고유해야 하므로, 보안 주체 이름, 보안 주체간단한 이름 및 보안 주체 그룹마다 고유한 이름을 할당해야 합니다. ECS에서는 JSON항목 이름에 대해 일정한 접두사 및 접미사를 사용하도록 요구합니다.

모든 Kerberos 사용자 입력에 필요한 접두사는 internal.kerberos.user이고, 접미사로는 name, shortname, groups의 세 가지를 사용할 수 있습니다. 다음 예를 참조하십시오.

{ "name": "internal.kerberos.user.hdfs.name", "value": "hdfs-cluster999@EXAMPLE_HDFS.EMC.COM"},{ "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs"},{ "name": "internal.kerberos.user.hdfs.groups",



"value": "hadoop,hdfs"},

접두사와 접미사 사이의 값은 항목을 고유하게 식별하기만 한다면 무엇이든 사용할 수있습니다. 예를 들어, 다음을 사용할 수 있습니다.

"name": "internal.kerberos.user.1.name","name": "internal.kerberos.user.1.shortname","name": "internal.kerberos.user.1.groups",

보안 주체는 각각 다른 사용자에 매핑될 수 있습니다. 예를 들어, rm 보안 주체 사용자는 다음과 같이 일반적으로 Hadoop 클러스터의 auth_to_local 설정을 사용하여yarn 사용자에 매핑됩니다.

RULE:[2:$1@$0](rm@EXAMPLE_HDFS.EMC.COM)s/.*/yarn/

따라서 다른 보안 주체에 매핑되는 보안 주체(예: yarn 보안 주체에 매핑된 rm 보안 주체)에 대해서는 rm 보안 주체에 대한 항목이 다음과 같도록 간단한 이름 값에 '매핑된'보안 주체를 사용해야 합니다.

{"name": "internal.kerberos.user.rm.name","value": "rm@EXAMPLE_HDFS.EMC.COM"},{"name": "internal.kerberos.user.yarn.shortname","value": "yarn@EXAMPLE_HDFS.EMC.COM"},{"name": "internal.kerberos.user.yarn.groups","value": "hadoop"},

수퍼그룹Hadoop 노드에서 어떠한 Linux 그룹의 사용자가 자신이 속한 그룹을 기반으로 수퍼 유저 권한을 얻게 되는지 ECS에 알려야 합니다. 수퍼 그룹은 JSON 입력 파일에서 단일항목으로 지정합니다. 다음과 같이 지정해야 합니다.

{ "name": "dfs.permissions.supergroup", "value": "hdfs"}

프록시 설정프록시 지원을 위해 각 Hadoop 애플리케이션에 허용되는 모든 프록시 설정을 식별해야 합니다. 여기서 애플리케이션은 Hadoop에서 지원되는 애플리케이션(예: hive 등)중 하나를 의미합니다.

다음 예에서 hive 애플리케이션에 대한 프록시 지원 기능은 s3users 그룹(AD 또는Linux 그룹)의 구성원인 사용자에게 부여되고, Hadoop 클러스터의 모든 호스트에서


메타데이터를 사용하여 ECS 버킷 보안 유지 155

hive를 실행할 수 있습니다. 따라서 이에 대한 JSON 항목은 2개 이름/값 쌍으로 구성됩니다. 하나는 호스트를 설정하고, 하나는 그룹을 설정합니다.

{ "name": "hadoop.proxyuser.hive.hosts", "value": "*"},{ "name": "hadoop.proxyuser.hive.groups", "value": "s3users"}

완전한 파일세 가지 메타데이터 유형을 단일 JSON 파일에 결합해야 합니다. JSON 파일 형식은 다음 예와 같습니다.

{ "head_type": "hdfs", "metadata": [ { "name": "METADATANAME_1", "value": "METADATAVALUE_1" }, { "name": "METADATANAME_2", "value": "METADATAVALUE_2" },

:

{ "name": "METADATANAME_N", "value": "METADATAVALUE_N" } ]}

마지막 이름/값 쌍에는 후행 “,” 문자가 없습니다.

JSON 파일의 예는 다음 항목에 나와 있습니다. 보안 버킷 메타데이터(182페이지).

보안 및 비보안 버킷메타데이터가 버킷에 로드된 경우 이를 보안 버킷이라고 하고 이 버킷에 액세스하려면Kerberos 보안 주체가 있어야 합니다. 비보안 Hadoop 노드에서 전송된 요청은 거부됩니다. 메타데이터가 로드되지 않은 경우 버킷은 보안이 유지되지 않으며, 이 경우 보안Hadoop 노드에서 전송된 요청이 거부됩니다.

비보안 클러스터에서 보안 버킷에 액세스하려고 하면 다음 오류가 표시됩니다. 보안 클러스터에서 비보안 버킷에 액세스하려고 하는 경우에도 유사한 메시지가 표시됩니다.

[hdfs@sandbox ~]$ hadoop fs -ls -R viprfs://hdfsBucket3.s3.site1/ls: ViPRFS internal error (ERROR_FAILED_TO_PROCESS_REQUEST).

Management REST API를 사용하여 ECS에 메타데이터 값 로드보안 Hadoop 클러스터에 사용할 ECS 버킷에 대한 보안을 유지하는 데 필요한 메타데이터 값은 ECS Management REST API 명령을 실행하여 제공할 수 있습니다.



시작하기 전에

이때 ECS System Administrator 자격 증명이 있어야 합니다.

Hadoop 관리자가 ECS System Administrator가 아닌 경우 보안 메타데이터를 버킷에로드하기 위해서는 ECS System Administrator와 협력해야 합니다.

Hadoop 관리자는 ECS System Administrator가 사용할 수 있는 JSON 메타데이터 파일을 생성할 수 있습니다. 그러면 ECS System Administrator가 다음 절차를 사용하여 메타데이터를 로드할 수 있습니다. 동일한 사용자가 이 두 가지 역할을 모두 수행하는 경우 이 사용자가 JSON 메타데이터 파일을 생성하는 작업과 이를 ECS 버킷에 로드하는작업을 모두 수행해야 합니다.

절차

1. 다음 항목에 설명된 대로 메타데이터를 포함하는 JSON 파일을 생성합니다. 메타데이터를 사용하여 ECS 버킷 보안 유지(154페이지).

2. ECS 관리 명령을 실행할 때 사용할 수 있는 인증 토큰을 획득하기 위해 SystemAdministrator 자격 증명을 사용하여 ECS에 로그인합니다.

curl을 사용하여 login 명령을 실행할 수 있습니다. 다음 예에서는<username>:<password>를 ECS System Administrator 자격 증명으로 바꾸고 ECS 노드의 IP 주소 또는 호스트 이름을 제공해야 합니다.

TOKEN=$(curl -s -k -u <username>:<password> -D - -o /dev/null https://<ECS node IP or hostname>:4443/login | grep X-SDS-AUTH-TOKEN | tr -cd '\40-\176')

3. 다음 예와 같이 PUT object/bucket/<bucketname>/metadata ECSManagement REST API 명령을 실행하여 메타데이터를 구축합니다.

curl -s -k -X PUT -H "$TOKEN" -H "Accept: application/json" -H "Content-Type: application/json" -T <bucketDetails>.json https:/<hostname>:4443/object/bucket/<bucketname>/metadata?namespace=<namespace>

다음과 같이 바꿔야 합니다.

l <username>: ECS 시스템 관리자 사용자 이름으로 바꿉니다.

l <password>: 지정된 ECS System Administrator 사용자 이름의 암호로 바꿉니다.

l <bucketname>: HDFS 데이터에 대해 사용하는 버킷 이름으로 바꿉니다.

l <hostname>: ECS 노드의 IP 주소 또는 호스트 이름으로 바꿉니다.

l <bucketdetails>: 이름-값 쌍을 포함하는 JSON 파일의 파일 이름으로 바꿉니다.

l <namespace>: 버킷이 상주하는 네임스페이스의 이름으로 바꿉니다.

구축이 완료되고 나면 모든 ECS 노드에서 메타데이터를 사용할 수 있습니다.

ECS 클라이언트 속성 재구성Ambari를 사용하여 ECS 클라이언트에 필요한 구성 속성을 설정할 수 있습니다.

다음 표에 필요한 속성이 나와 있습니다.


ECS 클라이언트 속성 재구성 157

표 31 ECS 액세스를 활성화하기 위한 Hadoop 구성

Hadoop의 위치

속성 값

core-site fs.viprfs.auth.identity_translation CURRENT_USER_REALM

fs.viprfs.auth.anonymous_translation CURRENT_USER

viprfs.security.principal vipr/[email protected]. 여기서 REALM.COM은Kerberos 영역 이름으로 대체됩니다.

각 core_site.xml 매개 변수에 대한 자세한 내용은 ECS HDFS의 Hadoop core-site.xml 속성(176페이지) 항목을 참조하십시오.

Hadoop 서비스를 시작하고 ECS에 대한 Hadoop 액세스를 확인합니다.

Hadoop 서비스를 시작합니다.

절차

1. Ambari를 사용하여 Hadoop 서비스를 시작합니다.

2. 모든 Hadoop 클라이언트 서비스가 시작된 후에 Hadoop CLI로 다음 명령을 사용하여 ECS 버킷에 액세스할 수 있는지 확인합니다.

hdfs dfs -ls /



9장

문제 해결

l 소개.................................................................................................................. 160l AD/LDAP가 보안 Hadoop 클러스터로 올바로 구성되어 있는지 확인................160l Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음..................................... 161l AD 사용자에 대해 거부되는 권한.......................................................................161l 사용 권한 오류.................................................................................................. 161l 요청 처리 실패..................................................................................................164l Kerberos 클라이언트 측 로깅 및 디버깅 활성화................................................ 164l KDC 상의 Kerberos 디버그............................................................................... 165l 시간 차이 제거..................................................................................................165l ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성............ 165l Yarn 디렉토리가 없다는 오류에 대한 해결 방법................................................ 167

문제 해결 159

소개이 섹션에서는 ECS HDFS를 구성할 때 발생할 수 있는 문제에 대한 해결 방법을 제시합니다.

AD/LDAP가 보안 Hadoop 클러스터로 올바로 구성되어 있는지확인

AD 또는 LDAP가 Kerberos(KDC) 및 Hadoop 클러스터로 올바로 설정되어 있는지 확인해야 합니다.

구성이 올바르면 AD/LDAP 사용자에 대한 kinit를 사용할 수 있어야 합니다. 그 밖에도, Hadoop 클러스터가 로컬 HDFS에 대해 구성되어 있는 경우 ECS가 클러스터에 추가되기 전에 로컬 HDFS 디렉토리를 나열할 수 있는지 확인해야 합니다.

해결 방법Hadoop 클러스터에서 KDC를 사용하여 AD/LDAP 사용자로 인증할 수 없는 경우, ECSHadoop 구성으로 진행하기 전에 이 문제를 해결해야 합니다.

다음은 성공한 로그인의 예입니다.

[kcluser@lvipri054 root]$ kinit [email protected] for [email protected]:

[kcluser@lvipri054 root]$ klistTicket cache: FILE:/tmp/krb5cc_1025Default principal: [email protected]

Valid starting Expires Service principal04/28/15 06:20:57 04/28/15 16:21:08 krbtgt/[email protected] renew until 05/05/15 06:20:57

위 로그인에 실패할 경우 다음 체크리스트에 따라 그 원인을 조사할 수 있습니다.

l KDC 서버에서 /etc/krb5.conf 파일이 정확하고 구문이 올바른지 확인합니다.영역은 구성 파일에서만이 아니라 kinit 명령과 함께 사용할 때도 대/소문자를 구분할 수 있습니다.

l KDC 서버에서 모든 Hadoop 노드로 /etc/krb5.conf 파일이 복제되는지 확인합니다.

l AD/LDAP와 KDC 서버 사이의 1방향 트러스트가 올바로 설정되었는지 확인합니다.

l AD/LDAP 서버의 암호화 유형이 KDC 서버의 암호화 유형과 일치하는지 확인합니다.

l /var/kerberos/krb5kdc/kadm5.acl 및 /var/kerberos/krb5kdc/kdc.conf 파일이 올바른지 확인합니다.

l KDC 서버에서 서비스 보안 주체로 로그인하여 KDC 서버 자체가 올바로 작동 중임을 나타냅니다.

l KDC 서버에서 같은 AD/LDAP 사용자로 직접 로그인합니다. 로그인되지 않으면KDC 서버에 직접적인 문제가 있을 가능성이 높습니다.

문제 해결


Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음Pig 테스트에 실패하고 다음 오류가 발생합니다. Info:Error:java.io.IOException: Unable to obtain the Kerberos principal(AD사용자로 kinit 후에도) 또는 Unable to open iterator for aliasfirstten.

문제의 원인은 Pig(릴리즈 0.13 이하)가 보조 스토리지로서 ViPRFS를 위한 위임 토큰을 생성하지 않는다는 것입니다.

해결 방법viprfs://bucket.ns.installation/을 mapreduce.job.hdfs-servers 구성 설정에 추가합니다. 예:

set mapreduce.job.hdfs-servers viprfs://KcdhbuckTM2.s3.site1

AD 사용자에 대해 거부되는 권한AD 사용자로 애플리케이션을 실행하면 Permission denied 오류가 표시됩니다.

해결 방법/user 디렉토리에 대한 권한을 다음으로 설정합니다.

hdfs dfs -chmod 1777 /user

사용 권한 오류사용 권한이 충분하지 않음 오류는 여러 가지 원인으로 발생할 수 있습니다. hadoopfs 명령을 실행할 때 이 유형의 오류가 나타나거나 mapreduce 또는 hive에 대한 로그와 같은 애플리케이션 로그에서 이 오류를 확인할 수도 있습니다.

INSUFFICIENT_PERMISSIONS 오류

아래 예에서는 jhs 보안 주체가 디렉토리(/tmp)를 생성하려고 시도했는데INSUFFICIENT_PERMISSIONS 오류가 발생했습니다. 이 경우 루트 디렉토리의 사용권한이 이 사용자가 디렉토리를 생성하도록 허용하지 않습니다.

root@lrmk042:/etc/security/keytabs# hadoop fs -mkdir /tmp15/11/08 21:03:09 ERROR vipr.ViPRFileSystemClientBase: Permissions failure for request: User: jhs/lrmk042.lss.emc.com@HOP171_HDFS.EMC.COM (auth:KERBEROS), host: hdfsBucket3.s3.site1, namespace: s3, bucket: hdfsBucket315/11/08 21:03:09 ERROR vipr.ViPRFileSystemClientBase: Request message sent: MkDirRequestMessage[kind=MKDIR_REQUEST,namespace=s3,bucket=hdfsBucket3,path=/tmp,hdfsTrustedStatus=HDFS_USER_NOT_TRUSTED,permissions=rwxr-xr-x,createParent=true]mkdir: java.security.AccessControlException: ERROR_INSUFFICIENT_PERMISSIONS

root@lrmk042:/etc/security/keytabs# hadoop fs -ls -d /drwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /root@lrmk042:/etc/security/keytabs#

클라이언트에서 사용 권한이 충분하지 않음 오류의 원인이 명확하게 표시되지 않을 경우 서버 로그를 확인해야 할 수 있습니다. 오류를 찾아볼 때는 dataheadsvc-

문제 해결

Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음 161

error.log부터 시작합니다. 각 ECS 노드에 대한 터미널 창을 열고 dataheadsvc-error.log 파일을 편집합니다. 클라이언트에서 오류를 확인한 시간에 해당하는 오류를 찾습니다.

자격 증명 가져오기 실패

dataheadsvc-error.log에 다음과 같은 오류가 표시됩니다.

2015-11-08 22:36:21,985 [pool-68-thread-6] ERROR RequestProcessor.java (line 1482) Unable to get group credentials for principal 'jhs@HOP171_HDFS.EMC.COM'. This principal will default to use local user groups. Error message: java.io.IOException: Failed to get group credentials for 'jhs@HOP171_HDFS.EMC.COM', status=ERROR

이것은 오류가 아닙니다. 이 메시지는 서버가 요청을 생성하는 보안 주체 사용자에 대해 캐싱된 AD(Active Directory) 그룹이 있는지 확인하기 위해 보안 주체 이름을 조회하려고 시도했음을 알리는 내용입니다. Kerberos 사용자에 대해 이 오류가 반환됩니다.

이 오류에는 요청을 생성하는 사용자 이름이 표시됩니다. 이 사용자 이름을 기록해 두십시오.

버킷 액세스 오류

사용자가 ACL 권한이 없는 버킷에 대한 액세스를 요청하는 경우 dataheadsvc-error.log에 이 오류가 표시될 수 있습니다.

2015-11-08 21:35:26,652 [pool-68-thread-1] ERROR BucketAPIImpl.java (line 220) Getting bucket failed withcom.emc.storageos.objcontrol.object.exception.ObjectAccessException: you don't have GET_KEYPOOL_ACL permission to this keypoolat com.emc.storageos.objcontrol.object.exception.ObjectAccessException.createExceptionForAPI(ObjectAccessException.java:286)at com.emc.storageos.data.object.ipc.protocol.impl.ObjectAccessExceptionParser.parseFrom(ObjectAccessExceptionParser.java:61)

이 경우 버킷에 대한 명시적인 사용자 ACL을 추가하거나 이 사용자가 속하는 그룹 중하나에 대해 사용자 지정 그룹 ACL을 추가해야 합니다.

오브젝트 액세스 오류

또 다른 유형의 사용 권한 오류는 오브젝트 액세스 오류입니다. 오브젝트(파일 및 디렉토리)에 대한 액세스를 버킷에 대한 액세스와 혼동하지 않아야 합니다. 사용자가 버킷에 대한 전체 제어 권한(읽기/쓰기/삭제)을 가지고 있는 경우에도 액세스하려는 경로에 있는 하나 이상의 오브젝트에 대한 액세스 권한을 가지고 있지 않는 경우 이로 인해INSUFFICIENT_PERMISSIONS 오류가 나타날 수 있습니다. 다음은 오브젝트 액세스오류의 예입니다.

2015-11-08 22:36:21,995 [pool-68-thread-6] ERROR FileSystemAccessHelper.java (line 1364) nfsProcessOperation failed to process path: mr-history/done2015-11-08 22:36:21,995 [pool-68-thread-6] ERROR ObjectControllerExceptionHelper.java (line 186) Method nfsGetSMD failed due to exceptioncom.emc.storageos.data.object.exception.ObjectControllerException: directory server returns error ERROR_ACCESS_DENIEDat com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessHelper.nfsProcessOperation(FileSystemAccessHelper.java:1368)

문제 해결


at com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessHelper.getSystemMetadata(FileSystemAccessHelper.java:466)at com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessLayer.getSystemMetadata(FileSystemAccessLayer.java:532)at com.emc.storageos.data.object.blob.client.BlobAPI.getStat(BlobAPI.java:1294)at com.emc.vipr.engine.real.RealBlobEngine.stat(RealBlobEngine.java:1976)at com.emc.vipr.engine.real.RealBlobEngine.stat(RealBlobEngine.java:802)at com.emc.vipr.hdfs.fs.RequestProcessor.accept(RequestProcessor.java:499)at com.emc.vipr.hdfs.net.ConnectionManager$RequestThread.run(ConnectionManager.java:136)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at java.lang.Thread.run(Thread.java:745)

여기서 확인해야 할 두 가지 중요한 항목은 요청된 작업(stat)과 오브젝트 경로(mr-history/done)입니다. 참고로 선행 슬래시 문자는 표시되어 있지 않습니다. 따라서실제 경로는 /mr-history/done입니다. 이제, 디버깅에 중요한 정보 세 가지를 확보했습니다.

l 사용자 보안 주체(jhs@HOP171_HDFS.EMC.COM)

l 작업(stat는 hadoop fs -ls)

l 경로(/mr-history/done)

추가 디버깅을 위한 두 가지 접근 방식이 있습니다.

l Blobsvc 로그 디버깅(163페이지)

l Hadoop 클라이언트 디버깅(163페이지)

Blobsvc 로그 디버깅사용 권한 요청이 실패할 경우 다음과 같이 blobsvc에 오류가 기록됩니다.

2015-11-08 22:36:21,994[TaskScheduler-BlobService-COMMUNICATOR-ParallelExecutor-5892]ERROR ObjectAclChecker.java (line 101) not permit, cred jhs@HOP171_HDFS.EMC.COM[hadoop]false1 withaction GET_OBJECT_ACL on object with acl/owner/group user={hdfs@hop171_hdfs.emc.com=[FULL_CONTROL]},groups={hdfs=[READ_ACL, EXECUTE, READ]}, other=[], owner=hdfs@hop171_hdfs.emc.com, group=hdfs

not permit을 찾으면 됩니다. 여기에는 요청을 생성하는 사용자(jhs), 오브젝트의소유자(hdfs), 오브젝트 그룹(hdfs) 그리고 소유자와 그룹 및 기타 항목에 대한 사용권한이 표시됩니다. 사용 권한 검사에 실패한 실제 오브젝트는 표시되지 않습니다.Hadoop 노드에서는 hdfs 보안 주체를 사용하여 해당 경로부터 시작하여 트리 위쪽 방향으로 작업하고 이는 클라이언트에서 Hadoop 파일 시스템을 확인하는 나머지 디버깅방법으로 이어집니다.

Hadoop 클라이언트 디버깅사용 권한 오류가 표시되면 요청을 생성하는 사용자 보안 주체, 요청에 해당하는 작업,요청되는 항목을 파악해야 합니다. 이 예에서는 jhs 사용자가 /mr-history/done디렉토리를 나열할 때 오류가 표시되었습니다. 근본 원인을 파악하기 위해 몇 가지 분석 작업을 수행할 수 있습니다. 수퍼유저 계정에 대한 액세스 권한이 있는 경우 이 계정으로 다음 단계를 수행하십시오.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /mr-history/donedrwxrwxrwt - mapred hadoop 0 2015-11-08 16:58 /mr-history/done

문제 해결

사용 권한 오류 163

다음 예에서는 jhs 보안 주체에 이 디렉토리를 나열할 권한이 있음을 보여 줍니다.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /mr-historydrwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /mr-history

마찬가지로, 다음 출력에서는 디렉토리에 액세스 문제가 없음을 보여 줍니다.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /drwxr-x--- - hdfs hdfs 0 2015-11-08 16:58 /

여기서 문제는 루트 디렉토리를 hdfs가 소유하고, 그룹 이름이 hdfs인데 others 설정이 -(0)인 것입니다. 요청을 생성하는 사용자는 jhs@REALM이고 이 사용자는 hdfs가 아니라 /mr-history/done의 구성원입니다. 따라서 이 사용자에게는 hadoop 디렉토리를 나열할 수 있는 오브젝트 ACL이 없습니다. 루트 디렉토리에 대해 chmod 명령을 수행하면 이 사용자가 이러한 작업을 수행할 수 있습니다.

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -chmod 755 /

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /drwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /

요청 처리 실패버킷을 열거할 때 Failed to Process Request가 표시됩니다.

예를 들어 다음과 같이 list bucket 명령을 수행하는 경우:

# hadoop fs -ls viprfs://hdfsBucket2.s3.site1/

다음과 같은 ViPRFS 내부 오류가 발생합니다.

ERROR_FAILED_TO_PROCESS_REQUEST

해결 방법이 오류의 가능한 원인은 다음과 같습니다.

1. Hadoop 노드의 viprfs-client JAR 파일이 ECS 소프트웨어와 동기화된 상태가 아닙니다.

2. 비보안(비 Kerberos) Hadoop 노드에서 보안(Kerberos) 버킷에 액세스하려고 합니다.

3. 보안(Kerberos) Hadoop 노드에서 비보안(비 Kerberos) 버킷에 액세스하려고 합니다.

Kerberos 클라이언트 측 로깅 및 디버깅 활성화인증 문제를 해결하기 위해 사용 중인 Hadoop 클러스터 노드에서 세부 정보 로깅 및 디버깅을 활성화할 수 있습니다.

문제 해결


클라이언트 측 세부 정보 로깅 활성화다음 예와 같이 세부 정보 로깅은 현재 SSH 세션에만 적용되는 환경 변수를 사용하여활성화됩니다.

export HADOOP_OPTS="-Dsun.security.krb5.debug=true"

Hadoop 클라이언트 측 디버깅 활성화Hadoop 노드와 ECS 사이의 Hadoop 작업에 대한 문제를 해결하기 위해 다음과 같이Hadoop 세부 정보 로깅을 활성화할 수 있습니다.

export HADOOP_ROOT_LOGGER="Debug,console"

KDC 상의 Kerberos 디버그KDC /var/log/krb5kdc.log 파일에서 tail 명령을 사용하여 KDC 상의 Kerberos를 디버그하면 HDFS 작업을 수행할 때 더 쉽게 디버그할 수 있습니다.

tail -f /var/log/krb5kdc.log

시간 차이 제거Kerberos는 정확한 시간에 의존하는 기술이므로, 클라이언트와 서버 간에 시간이 동기화되어 있는지 확인하는 것이 중요합니다.

AD(Active Directory)와 데이터 노드/KDC 간에 시간 차이가 있을 경우, NTP 서버를 올바로 구성해야 합니다. 다음과 같이 하면 됩니다.

1. Remote Desktop을 사용하여 AD 서버에 연결합니다.

2. 다음 명령을 실행합니다.

a. w32tm /config /syncfromflags:manual /manualpeerlist:<ntp-server1>,<ntp-server2>

b. net stop w32timec. net start w32time

ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성

ECS 구성에 하나 이상의 새 노드를 추가하는 경우 ECS 서비스 보안 주체와 해당keytab이 새 노드에 구축되어야 합니다.

시작하기 전에

l 이 절차에서는 여기에 나와 있는 단계를 이전에 수행했으며 Ansible Playbook이 설치되어 액세스 가능하다고 가정합니다.

이 절차를 완료하려면 다음 항목들이 있어야 합니다.

l ECS 노드 IP 주소의 목록입니다.

l KDC의 IP 주소입니다.

문제 해결

KDC 상의 Kerberos 디버그 165

l 이 스크립트를 실행하는 DNS 확인이 Hadoop 호스트에 대한 DNS 확인과 같아야하며, 그렇지 않으면 vipr/_HOST@REALM이 작동하지 않습니다.

절차

1. 노드 1에 로그인한 후 툴이 이미 설치되었으며 Playbook을 사용할 수 있는지 확인합니다.

이전에 사용된 예는 다음과 같습니다.

/home/admin/ansible/viprfs-client-<ECS version>-<version>/playbooks

2. playbooks/samples 디렉토리의 inventory.txt 파일을 편집하여 ECS 노드를 추가합니다.

다음 추출 내용에 기본 항목이 나와 있습니다.

[data_nodes]192.168.2.[100:200]

[kdc]192.168.2.10

3. ECS 노드 1에서 유틸리티 컨테이너를 시작하고 Ansible Playbook을 컨테이너에서 사용할 수 있도록 합니다.

a. 유틸리티 컨테이너 이미지를 로드합니다.

예:

sudo docker load -i /opt/emc/caspian/checker/docker/images/utilities.txz

b. docker 이미지의 ID를 가져옵니다.

예:

admin@provo-lilac:~> sudo docker images

출력에 다음과 같은 이미지 ID가 표시됩니다.

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEutilities 1.5.0.0-403.cb6738e 186bd8577a7a 2 weeks ago 738.5 MB

c. 시작하고 유틸리티 이미지를 입력합니다.

예:

sudo docker run -v /opt/emc/caspian/fabric/agent/services/object/main/log:/opt/storageos/logs -v /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks:/ansible --name=ecs-tools -i -t --privileged --net=host 186bd8577a7a /bin/bash

이 예에서는 Ansible Playbook이 압축 해제된 위치인 /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks가유틸리티 컨테이너의 /ansible 디렉토리에 매핑됩니다.

문제 해결


4. 컨테이너의 작업 디렉토리로 변경합니다.

예:

cd /ansible

5. Ansible Playbook을 실행하여 keytab을 생성합니다.

ansible-playbook -v -k -i inventory.txt generate-vipr-keytabs.yml

6. Ansible Playbook을 실행하여 ECS 서비스 주체로 데이터 노드를 구성합니다.

/ansible/samples/keytab 디렉토리가 있고 krb5.conf 파일이 작업 디렉토리 /ansible/samples에 있는지 확인합니다.

ansible-playbook -v -k -i inventory.txt setup-vipr-kerberos.yml

데이터 노드당 하나씩, 올바른 ECS 서비스 주체가 생성되었는지 확인합니다(KDC에서).

# kadmin.local -q "list_principals" | grep viprvipr/[email protected]/[email protected]

올바른 keytab이 생성되어 /data/hdfs/krb5.keytab 위치(모든 ECS 데이터노드)에 저장되어 있는지 확인합니다. keytab에서 strings 명령을 사용하여 사람이 읽을 수 있는 텍스트를 추출하고 여기에 올바른 주체가 포함되어 있는지 확인할 수 있습니다. 예:

dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytabMA.EMC.COMviprnile3-vm42.centera.lab.emc.com

이 경우 주체는 vipr/nile3-vm42.centera.lab.emc.com입니다.

Yarn 디렉토리가 없다는 오류에 대한 해결 방법Kerberized HDP 클러스터를 사용하여 ECS를 기본 파일 시스템으로 구성하는 경우 /ats/done does not exist와 같은 오류가 표시될 수 있습니다. 또한 ResourceManager가 시작되지 않습니다.

다음 절차는 이러한 문제에 대한 해결 방법을 제공합니다.

절차

1. Hadoop 노드가 ECS 노드를 확인할 수 있는지 점검합니다.

a. Hadoop 노드에 nslookup 툴을 설치합니다.

yum install -y bind-utils

문제 해결

Yarn 디렉토리가 없다는 오류에 대한 해결 방법 167

b. 이 툴이 ECS 노드를 확인할 수 있는지 점검합니다.

nslookup <address of ECS node>

c. ECS 노드가 올바른 호스트 이름으로 확인되지 않는 경우면, Hadoop 노드의 /etc/resolv.conf에 ECS DNS를 추가합니다.

다음을 실행하여 DNS 항목이 있는지 확인할 수 있습니다.

cat /etc/resolv.conf

d. 이제 Hadoop 노드가 ECS 노드를 확인할 수 있을 것입니다.

nslookup을 다시 실행하여 확인할 수 있는지 점검합니다.

nslookup <address of ECS node>

2. Hadoop 노드, ECS 노드 및 KDC의 시스템 시간을 확인합니다.

다음을 사용합니다.

# date

시스템 시간이 통합되지 않은 경우 동일한 ntp 서버로 동기화되어야 합니다.

이에 대한 설명이 NTP 활성화에 나와 있습니다.

3. 앞의 단계가 작동하지 않을 경우 /ats 아래에 done 또는 active 폴더를 수동으로 생성해 볼 수 있습니다.

# sudo -u hdfs hdfs dfs -mkdir /ats/done

# sudo -u hdfs hdfs dfs -mkdir /ats/active

그런 다음 해당 디렉토리가 존재하는지 확인합니다.

$ hdfs dfs -ls /ats

Found 2 items drwxrwxrwt - yarn hadoop 0 2016-07-12 09:00 /ats/active drwx------ - yarn hadoop 0 2016-07-12 09:00 /ats/done

문제 해결


HTTPS://DOCS.HORTONWORKS.COM/HDPDOCUMENTS/AMBARI-2.4.2.0/BK_AMBARI-INSTALLATION/CONTENT/ENABLE_NTP_ON_THE_CLUSTER_AND_ON_THE_BROWSER_HOST.HTML

10장

부록: Kerberos 구성에 대한 지침

l Kerberos 구성에 대한 지침............................................................................... 170

부록: Kerberos 구성에 대한 지침 169

Kerberos 구성에 대한 지침Hadoop 클러스터에서 Kerberos의 구성에 관한 지침을 제공합니다.

Kerberos KDC 설정다음 단계에 따라 Kerberos KDC를 설정합니다.

절차

1. krb5-workstation을 설치합니다.

다음 명령을 사용합니다.

yum install -y krb5-libs krb5-server krb5-workstation

2. /etc/krb5.conf를 수정하고 영역 이름과 확장명을 변경합니다.

3. /var/kerberos/krb5kdc/kdc.conf를 수정하고 자신의 영역 이름과 일치하도록 영역 이름을 변경합니다.

4. KDC가 VM인 경우 /dev/random을 재생성합니다(그렇지 않으면 KDC 데이터베이스를 생성하는 다음 단계를 완료하는 데 매우 오랜 시간이 걸림).

a. 다음을 사용하여 제거합니다.

# rm -rf /dev/random

b. 다음을 사용하여 재생성합니다.

# mknod /dev/random c 1 9

5. KDC 데이터베이스를 생성합니다.

# kdb5_util create -s

초기 보안 주체에 실수를 한 경우, 예를 들어 "kdb5_util create -s"를 잘못 실행한 경우 /var/kerberos/krb5kdc/ 디렉토리에서 이런 보안 주체를 명시적으로 삭제해야 할 수도 있습니다.

6. 관리자 권한을 가진 사용자를 지정하도록 kadm5.acl를 수정합니다.

*/[email protected] *

7. /var/kerberos/krb5kdc/kdc.conf를 수정하고 des-cbc-crc:normal을 제외한 모든 암호화 유형을 제거합니다. 또한, 영역 이름을 수정합니다.



8. 모든 노드(Hadoop 노드뿐 아니라 KDC 서버도 포함)에서 iptables와 selinux가OFF 상태인지 확인합니다.

9. KDC 서비스를 시작하고 로컬 관리 보안 주체를 생성합니다.

kadmin.local

# service krb5kdc start

# service kadmin start

# /usr/kerberos/sbin/kadmin.local-q "addprinc root/admin"

# kinit root/admin

10. krb5.conf 파일을 모든 Hadoop 노드에 복제합니다.

어떤 구성 파일이든 수정할 때마다 아래 서비스를 재시작하고 관련 Hadoop 호스트와 ECS 노드로 krb5.conf 파일을 복제합니다.

11. 서비스를 재시작합니다.

service krb5kdc restart

service kadmin restart

12. 다음 링크를 방문하여 http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-kerberos-server.html의 단계를 바탕으로 Kerberos KDC를 설정할 수 있습니다.

Kerberos에 대한 AD 사용자 인증 구성Kerberos 보안으로 Hadoop 환경을 구성한 경우, ECS AD 도메인에 대해 인증하도록 이환경을 구성할 수 있습니다.

ADREALM에 대한 AD 사용자가 있는지 확인합니다. 아래 예에서는 ADREALMCAMBRIDGE.ACME.COM에 대해 사용자 "detscr"이 사용됩니다. 예에 표시된 것처럼KDCREALM과 ADREALM 사이에 1방향 트러스트를 생성합니다. "netdom trust"를 사용하여 이 영역의 유효성 검사를 수행하지 마십시오.

Active Directory에서KDC 영역에서 AD 영역으로 1방향 교차 영역 트러스트를 설정해야 합니다. 이를 위해명령 프롬프트에서 다음 명령을 실행하십시오.

ksetup /addkdc KDC-REALM <KDC hostname>netdom trust KDC-REALM /Domain:AD-REALM /add /realm /passwordt:<TrustPassword>ksetup /SetEncTypeAttr KDC-REALM <enc_type>

예:

ksetup /addkdc LSS.EMC.COM lcigb101.lss.emc.comnetdom trust LSS.ACME.COM /Domain:CAMBRIDGE.ACME.COM /add /realm /passwordt:ChangeMeksetup /SetEncTypeAttr LSS.ACME.COM DES-CBC-CRC

이 예제에서는 des-cbc-crc 암호화가 사용되었습니다. 하지만 이것은 데모 목적으로만선택한 약한 암호화입니다. 어떤 암호화를 선택하든, AD, KDC 및 클라이언트가 그 암호화를 지원해야 합니다.


Kerberos에 대한 AD 사용자 인증 구성 171

https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-kerberos-server.html

https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-kerberos-server.html

사용자의 KDC에서(루트로)1방향 트러스트를 설정하려면 "krbtgt" 서비스 보안 주체를 생성해야 합니다. 이를 위한이름은 krbtgt/KDC-REALM@AD-REALM입니다. 이에 대한 암호를 ChangeMe로 지정하거나, 위의 /passwordt 인수에 지정한 암호로 지정합니다.

1. KDC에서(루트로)

# kadminkadmin: addprinc -e "des-cbc-crc:normal" krbtgt/[email protected]

구축 시, 암호화 유형을 사용자가 선택한 것으로 제한하는 것이 최선입니다. 이것이작동하면 추가적인 암호화 유형을 추가할 수 있습니다.

2. core-site.xml hadoop.security.auth_to_local 속성에 다음 규칙을 추가합니다.

RULE:[1:$1@$0](^.*@CAMBRIDGE\.ACME\.COM$)s/^(.*)@CAMBRIDGE\.ACME\.COM$/$1/gRULE:[2:$1@$0](^.*@CAMBRIDGE\.ACME\.COM$)s/^(.*)@CAMBRIDGE\.ACME\.COM$/$1/g

3. AD 또는 LDAP가 Kerberos(KDC) 서버와 올바로 설정되어 있는지 확인합니다. 사용자는 AD 사용자에 대해 "kinit"를 수행하고 로컬 HDFS 디렉토리를 나열할 수 있어야 합니다.

AD를 통해 인증하도록 Hadoop 클러스터 및 ECS를 구성할 경우, kinit가 수행될 AD사용자에 대한 모든 Hadoop 노드에서 로컬 Linux 사용자 계정을 생성하고 그 AD 사용자를 사용하여 모든 Hadoop 호스트에서 kinit가 수행되는지도 확인하십시오. 예를 들어 userX@ADREALM으로 kinit를 수행할 경우 모든 Hadoop 호스트에서 userX를 로컬 사용자로 생성하고 그 사용자에 대해 모든 호스트에서 'kinituserX@ADREALM'을 사용하여 kinit를 수행합니다.

아래 예에서는 "kinit [email protected]"으로 인증하므로, "detscr"이라는 사용자를 생성하고 Hadoop 호스트에서 이 사용자로 kinit를 수행합니다. 아래에 표시된 것과 같습니다.

[root@lviprb159 ~]# su detscr [detscr@lviprb159 root]$ whoami detscr [detscr@lviprb159 root]$ kinit [email protected] Password for [email protected]: [detscr@lviprb159 root]$ klist Ticket cache: FILE:/tmp/krb5cc_1010 Default principal: [email protected] Valid starting Expires Service principal 12/22/14 14:28:27 03/02/15 01:28:30 krbtgt/[email protected] renew until 09/17/17 15:28:27 [detscr@lviprb159 root]$ hdfs dfs -ls /Found 4 itemsdrwx---rwx - yarn hadoop 0 2014-12-23 14:11 /app-logsdrwx---rwt - hdfs 0 2014-12-23 13:48 /apps



drwx---r-x - mapred 0 2014-12-23 14:11 /mapreddrwx---r-x - hdfs 0 2014-12-23 14:11 /mr-history


Kerberos에 대한 AD 사용자 인증 구성 173

11장

부록: ECS HDFS의 Hadoop core-site.xml 속성

l ECS HDFS의 Hadoop core-site.xml 속성.......................................................... 176

부록: ECS HDFS의 Hadoop core-site.xml 속성 175

ECS HDFS의 Hadoop core-site.xml 속성Hadoopcore-site.xml 파일을 구성할 때 아래 표의 속성 및 관련 값을 참조로 사용하십시오.

표 32 Hadoop core-site.xml 속성

속성 설명

파일 시스템 구축 속성

fs.viprfs.impl<property><name>fs.viprfs.impl</name><value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value></property>

fs.AbstractFileSystem.viprfs.impl <property>

<name>fs.AbstractFileSystem.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value> </property>

ECS HDFS 파일 시스템 URI의 권한 섹션을 정의하는 속성

fs.vipr.installations 쉼표로 구분된 이름 목록 ECS 데이터 노드 세트를 고유하게 식별하기 위해 fs.vipr.installation.[federation].hosts 속성에 의해 이름이 더욱 세부적으로 정의됩니다. 이름은 ECS HDFS 파일 시스템URI의 권한 섹션의 구성 요소로 사용됩니다. 예:

<property> <name>fs.vipr.installations</name> <value><federation>,<site1>,<testsite></value> </property>

fs.vipr.installation.[federation].hosts

fs.vipr.installations 속성에 나열된 각 이름에 대한 ECS 클러스터의 데이터 노드 또는 로드 밸런싱 장치의 IP 주소. 쉼표로 구분된 IP 주소 또는 FQDN 목록의 형태로 값을 지정합니다. 예:

<property> <name>fs.vipr.installation.<federation>.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value> </property>

fs.vipr.installation.[installation_name].resolution

ECS HDFS 소프트웨어가 ECS 데이터 노드에 액세스하는 방법을 어떻게 인식하는지 지정합니다. 값은 다음과 같습니다.

l dynamic: 로드 밸런싱 장치 없이 직접 ECS 데이터 노드에 액세스할 때 이 값을 사용합니다.

l fixed: 로드 밸런싱 장치를 통해 ECS 데이터 노드에 액세스할 때 이 값을 사용합니다.

<property> <name>fs.vipr.installation.<federation>.resolution</name> <value>dynamic</value>



표 32 Hadoop core-site.xml 속성 (계속)

속성 설명

</property>

fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms

fs.vipr.installation.[installation_name].resolution 속성이 dynamic으로 설정되면, 이 속성은 ECS에 활성 노드 목록을 쿼리하는 주기를 지정합니다. 값은 밀리초 단위입니다. 기본값은 10분입니다.

<property> <name>fs.vipr.installation.<federation>.resolution.dynamic.time_to_live_ms</name> <value>600000</value> </property>

ECS 파일 시스템 URI

fs.defaultFS 기본 파일 시스템에 대한 URI를 지정하는 표준 Hadoop 속성. 이 속성을 ECS HDFS 파일 시스템으로설정하는 것은 선택 사항입니다. 이 속성을 ECS HDFS 파일 시스템으로 설정하지 않을 경우 각 파일시스템 작업에 대한 전체 URI를 지정해야 합니다. ECS HDFS 파일 시스템 URI의 형식은 다음과 같습니다.

viprfs://[bucket_name].[namespace].[federation]

l bucket_name: Hadoop 작업을 실행할 때 사용할 데이터가 포함되어 있는 HDFS 지원 버킷의 이름입니다.

l namespace: HDFS 지원 버킷과 연결된 테넌트 네임스페이스입니다.

l federation: Hadoop이 ECS 데이터에 액세스하는 데 사용할 수 있는 ECS 데이터 노드 세트와 연결된 이름입니다. 이 속성의 값은 fs.vipr.installations 속성에 지정된 값 중 하나와 일치해야 합니다.

예:

<property> <name>fs.defaultFS</name> <value>viprfs://testbucket.s3.federation1</value> </property>

umask property

fs.permissions.umask-mode

이 표준 Hadoop 속성은 ECS HDFS가 오브젝트에 대한 권한을 계산하는 방식을 지정합니다. 권한은입력 권한에 umask를 적용하는 방식으로 계산됩니다. 단순 및 Kerberos 구성 모두에 권장되는 값은022입니다. 예:

<property><name>fs.permissions.umask-mode</name><value>022</value>


ECS HDFS의 Hadoop core-site.xml 속성 177


속성 설명

</property>

ID 변환 속성

fs.viprfs.auth.identity_translation

이 속성은 Kerberos 영역이 지정되지 않은 경우 ECS HDFS 클라이언트에서 특정 사용자가 속하는Kerberos 영역을 결정하는 방식을 지정합니다. ECS 데이터 노드는 username@REALM으로 파일 소유자를 저장하는 반면, Hadoop은 사용자 이름으로만 파일 소유자를 저장합니다.가능한 값은 다음과 같습니다.

l NONE: 기본값입니다. 사용자가 영역에 매핑되지 않습니다. 단순 보안을 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. 이 설정을 사용하면 ECS HDFS에서 영역 변환을 수행하지 않습니다.

l CURRENT_USER_REALM: Kerberos가 있을 때 유효합니다. 사용자 영역이 자동으로 감지되고, 이영역이 현재 로그인된 사용자의 영역입니다. 아래 예에서는 sally가 EMC.COM 영역에 있기 때문에EMC.COM이 영역이 됩니다. 이 파일 소유권은 [email protected]으로 변경됩니다.

# kinit [email protected]# hdfs dfs -chown john /path/to/file

명령줄로 제공되는 영역은 속성 설정보다 우선 적용됩니다.

<property> <name>fs.viprfs.auth.identity_translation </name> <value>CURRENT_USER_REALM</value> </property>

FIXED_REALM 이제 더 이상 사용되지 않습니다.

fs.viprfs.auth.realm fs.viprfs.auth.identity_translation 속성이 FIXED_REALM으로 설정된 경우 사용자에게할당된 영역입니다.이는 이제 더 이상 사용되지 않습니다.

fs.viprfs.auth.anonymous_translation

이 속성은 새로 생성된 파일에 사용자 및 그룹이 할당되는 방법을 결정하는 데 사용됩니다.

이 속성은 소유자가 없는 파일에 발생한 작업을 확인하는 데 사용되었습니다. 이러한 파일을anonymous가 소유한다고 했습니다. 파일 및 디렉토리는 더 이상 익명으로 소유되지 않습니다.

값은 다음과 같습니다.

l LOCAL_USER: 단순 보안을 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. Hadoop 클러스터의 Unix 사용자 및 그룹을 새로 생성된 파일 및 디렉토리에 할당합니다.

l CURRENT_USER: Kerberos를 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. Kerberos 보안 주체([email protected])를 파일 또는 디렉토리 소유자로 할당하고 버킷에 대한 기본 그룹으로 할당된 그룹을 사용합니다.




속성 설명

l NONE: (더 이상 사용되지 않음) 앞에서 언급했듯이 익명으로 소유된 오브젝트를 현재 사용자에매핑하는 작업은 수행되지 않습니다.

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>CURRENT_USER</value> </property>

Kerberos 영역 및 서비스 보안 주체 속성

viprfs.security.principal 이 속성은 ECS 서비스 주체를 지정합니다. 이 속성은 KDC에 ECS 서비스에 대해 알려 줍니다. 이 값은 구성과 관련이 있습니다.보안 주체 이름에는 실행 시 실제 데이터 노드 FQDN으로 자동으로 바뀌는 _HOST가 포함될 수 있습니다.

예:

<property> <name>viprfs.security.principal</name> <value>vipr/[email protected]</value></property>

단순 인증 모드의 core-site.xml 샘플다음 core-site.xml 파일은 단순 인증 모드의 ECS HDFS 속성 예입니다.

예제 1 core-site.xml

<property> <name>fs.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value></property>

<property> <name>fs.AbstractFileSystem.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value></property>

<property> <name>fs.vipr.installations</name> <value>federation1</value></property>

<property> <name>fs.vipr.installation.federation1.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value></property>

<property> <name>fs.vipr.installation.federation1.resolution</name> <value>dynamic</value>


단순 인증 모드의 core-site.xml 샘플 179

예제 1 core-site.xml (계속)

</property>

<property> <name>fs.vipr.installation.federation1.resolution.dynamic.time_to_live_ms</name> <value>900000</value></property>

<property> <name>fs.defaultFS</name> <value>viprfs://mybucket.mynamespace.federation1/</value></property>

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>LOCAL_USER</value></property>

<property> <name>fs.viprfs.auth.identity_translation</name> <value>NONE</value></property>



12장

부록: 보안 버킷 메타데이터 예

l 보안 버킷 메타데이터....................................................................................... 182

부록: 보안 버킷 메타데이터 예 181

보안 버킷 메타데이터다음 예에서는 보안 버킷 메타데이터 이름-값 쌍의 목록을 보여 줍니다.

{ "head_type": "hdfs", "metadata": [ { "name": "internal.kerberos.user.ambari-qa.name", "value": "ambari-qa@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.ambari-qa.shortname", "value": "ambari-qa" }, { "name": "internal.kerberos.user.ambari-qa.groups", "value": "hadoop,users" }, { "name": "internal.kerberos.user.cmaurer.name", "value": "cmaurer@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.cmaurer.shortname", "value": "cmaurer" }, { "name": "internal.kerberos.user.cmaurer.groups", "value": "cmaurer,adm,cdrom,sudo,dip,plugdev,users,lpadmin,sambashare" }, { "name": "internal.kerberos.user.dn.name", "value": "dn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.dn.shortname", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.dn.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.hdfs.name", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs" }, { "name": "internal.kerberos.user.hdfs.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.hive.name", "value": "hive@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hive.shortname", "value": "hive" },



{ "name": "internal.kerberos.user.hive.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.jhs.name", "value": "jhs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.jhs.shortname", "value": "mapred" }, { "name": "internal.kerberos.user.jhs.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.nm.name", "value": "nm@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nm.shortname", "value": "yarn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nm.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.nn.name", "value": "nn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nn.shortname", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nn.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.rm.name", "value": "rm@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.rm.shortname", "value": "yarn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.rm.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.spark.name", "value": "spark@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.spark.shortname", "value": "spark" }, { "name": "internal.kerberos.user.spark.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.yarn.name", "value": "yarn@EXAMPLE_HDFS.EMC.COM" },


보안 버킷 메타데이터 183

{ "name": "internal.kerberos.user.yarn.shortname", "value": "yarn" }, { "name": "internal.kerberos.user.yarn.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.zookeeper.name", "value": "zookeeper@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.zookeeper.shortname", "value": "ams" }, { "name": "internal.kerberos.user.zookeeper.groups", "value": "hadoop" }, { "name": "hadoop.proxyuser.hcat.groups", "value": "*" }, { "name": "hadoop.proxyuser.hcat.hosts", "value": "*" }, { "name": "hadoop.proxyuser.yarn.users", "value": "*" }, { "name": "hadoop.proxyuser.yarn.hosts", "value": "*" }, { "name": "hadoop.proxyuser.hive.hosts", "value": "10.247.179.42" }, { "name": "hadoop.proxyuser.hive.users", "value": "*" }, { "name": "hadoop.proxyuser.hcat.groups", "value": "*" }, { "name": "hadoop.proxyuser.hcat.hosts", "value": "*" }, { "name": "dfs.permissions.supergroup", "value": "hdfs" } ]}

