elastic cloud storage (ecs) · 2020-03-09 · hadoop 인증 모드..... 140 파일 시스템으로...

Elastic Cloud Storage (ECS)3.0 버전

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

04

Copyright © 2013-2017년 EMC Corporation All rights reserved.

발행: 2017년년 1월

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.0 데이터 액세스 가이드

9

11

S3 13

ECS의 Amazon S3 지원 기능 소개 15ECS의 Amazon S3 API 지원 기능................................................................16

S3의 지원되는 기능 17S3 API의 지원되는 기능 및 지원되지 않는 기능.......................................... 18

S3 확장 21S3 확장.......................................................................................................22바이트 범위 확장........................................................................................ 22

오브젝트 내의 바이트 범위 업데이트.............................................22오브젝트의 부분 덮어쓰기............................................................. 23오브젝트에 데이터 추가.................................................................24오브젝트 내의 여러 바이트 범위 읽기............................................25

Retention................................................................................................... 26수명주기(만료) 및 보존................................................................. 27

파일 시스템 활성화.....................................................................................27

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

암호 키 생성 및 관리 41암호 키 생성 및 관리...................................................................................42오브젝트 사용자용 키 생성.........................................................................42

ECS Portal에서 암호 키 생성......................................................... 42ECS Management REST API를 사용하여 S3 암호 키 생성 ............42

S3 암호 키 생성: 셀프 서비스..................................................................... 43셀프 서비스 키를 사용한 작업........................................................44

S3 서비스로 인증 47S3 서비스로 인증....................................................................................... 48

Java 클라이언트 액세스 51

그림

표

1부

1장

2장

3장

4장

5장

6장

7장

목차

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

SDK를 사용하여 S3 서비스에 액세스......................................................... 52Java Amazon SDK 사용................................................................. 52ECS용 Java SDK 클라이언트 ........................................................54

OpenStack Swift 57

ECS의 OpenStack Swift 지원 소개 59ECS의 OpenStack Swift API 지원 기능...................................................... 60

Swift의 지원되는 기능 61지원되는 OpenStack Swift 작업.................................................................62

Swift 확장 65Swift API 확장............................................................................................66오브젝트 내의 바이트 범위 업데이트..........................................................66오브젝트의 부분 덮어쓰기..........................................................................67오브젝트에 데이터 추가............................................................................. 68오브젝트 내의 여러 바이트 범위 읽기.........................................................69

Authentication 71OpenStack Swift 인증................................................................................ 72

ECS Portal에서 Swift 사용자 생성.................................................72OpenStack 버전 1 인증 .............................................................................. 73OpenStack 버전 2 인증...............................................................................75ECS Keystone V3 통합을 사용한 인증........................................................ 77

Keystone 사용자를 인증하도록 ECS 구성......................................78

인증 79컨테이너에 대한 인증.................................................................................80

EMC Atmos 83

ECS의 EMC Atmos 지원 기능 소개 85ECS의 EMC Atmos API 지원 기능.............................................................. 86

Atmos의 지원되는 기능 87지원되는 EMC Atmos REST API 호출........................................................ 88지원되지 않는 EMC Atmos REST API 호출................................................ 89EMC Atmos REST API 호출의 서브테넌트 지원......................................... 90

Atmos API 확장 93API 확장..................................................................................................... 94

오브젝트에 데이터 추가................................................................ 94

CAS 97

2부

8장

9장

10장

11장

12장

3부

13장

14장

15장

4부

목차


ECS에서 CAS 지원 설정 99ECS에서 CAS 지원 설정........................................................................... 100콜드 스토리지........................................................................................... 100Compliance................................................................................................ 101

플랫폼 강화 및 규정 준수..............................................................101규정 준수 및 보존 정책.................................................................102규정 준수 에이전트...................................................................... 103

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

ECS Management API 119

ECS Management REST API 소개 121ECS Management REST API..................................................................... 122

ECS Management Service로 인증 123ECS Management REST API로 인증......................................................... 124

AUTH-TOKEN으로 인증 .............................................................. 124쿠키로 인증.................................................................................. 125로그아웃...................................................................................... 126Whoami........................................................................................ 126

ECS Management REST API 요약 129ECS Management REST API 요약.............................................................130

HDFS 135

ECS HDFS는 무엇입니까? 137ECS HDFS란 무엇인가?............................................................................138ECS HDFS를 사용하도록 Hadoop 구성 .................................................... 139파일 시스템 액세스를 위한 ECS HDFS URI...............................................140Hadoop 인증 모드..................................................................................... 140

파일 시스템으로 버킷 액세스........................................................141버킷 사용자 지정 그룹 ACL 및 기본 그룹...................................... 141Hadoop 수퍼유저 및 수퍼그룹......................................................142멀티 프로토콜(교차 헤드) 액세스.................................................142Hadoop Kerberos 인증 모드......................................................... 143프록시 사용자.............................................................................. 143동등 사용자.................................................................................. 143SymLink 지원............................................................................... 144

단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션............... 144파일 시스템 상호 작용...............................................................................144

16장

5부

17장

18장

19장

6부

20장

목차


지원되는 Hadoop 애플리케이션 및 지원되지 않는 Hadoop 애플리케이션....145

HDFS 파일 시스템용 버킷 생성 147ECS Portal을 사용하여 HDFS에 사용할 버킷 생성.................................... 148

사용자 지정 그룹 버킷 ACL 설정.................................................. 150사용자에 대한 버킷 ACL 권한 설정.............................................. 152

Hadoop 및 ECS 버킷 사용 권한 예............................................................ 153

Hortonworks Ambari를 사용하여 ECS HDFS에 Hadoop 설정 155Ambari를 사용하여 Hortonworks 클러스터 구축....................................... 156Ambari 다운로드....................................................................................... 156ECS HDFS Client Library 다운로드........................................................... 156ECS 클라이언트 라이브러리를 구축하는 데 소스로 사용할 로컬 저장소 설정................................................................................................................. 156Ambari 서버 설치...................................................................................... 157Ambari Hadoop ECS 스택 활성화.............................................................. 157수동으로 Ambari 에이전트 설치................................................................ 158Hadoop 설치 ............................................................................................ 159

단순 Hadoop 클러스터와 ECS HDFS 통합 구성 163단순 Hadoop 클러스터와 ECS HDFS 통합 구성........................................ 164ECS HDFS 및 Hadoop 통합 계획...............................................................164ECS HDFS 설치 및 지원 패키지 가져오기................................................. 165ECS HDFS Client Library 구축.................................................................. 165Hadoop core-site.xml 파일 편집................................................................ 167HBASE hbase-site.xml 편집...................................................................... 170재시작 후 액세스 확인............................................................................... 171

보안(Kerberized) Hadoop 클러스터와 ECS HDFS 통합 구성 173ECS HDFS와 보안 Hadoop 클러스터 통합 ................................................174단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획.................... 174그룹 이름 매핑.......................................................................................... 174ECS 서비스 주체를 사용하여 ECS 노드 구성............................................ 175메타데이터를 사용하여 ECS 버킷 보안 유지............................................. 179

Management REST API를 사용하여 ECS에 메타데이터 값 로드... 181core-site.xml 편집..................................................................................... 183재시작 후 액세스 확인...............................................................................186

Kerberos 구성에 대한 지침 189Kerberos 구성에 대한 지침........................................................................190

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

ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성.....193

문제 해결 197문제 해결.................................................................................................. 198AD/LDAP가 보안 Hadoop 클러스터로 올바로 구성되어 있는지 확인........ 198hbase 구성 후 서비스 재시작.................................................................... 199Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음.............................199AD 사용자에 대해 거부되는 권한.............................................................. 199

21장

22장

23장

24장

25장

26장

목차


사용 권한 오류.......................................................................................... 199요청 처리 실패..........................................................................................203Kerberos 클라이언트 측 로깅 및 디버깅 활성화........................................203KDC 상의 Kerberos 디버그....................................................................... 204시간 차이 제거..........................................................................................204

ECS HDFS의 Hadoop core-site.xml 속성 205ECS HDFS의 Hadoop core-site.xml 속성..................................................206

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

보안 버킷 메타데이터 예 211보안 버킷 메타데이터................................................................................212

27장

28장

목차


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

12345678910

그림


그림


지원되는 S3 API..........................................................................................................18추가 기능.................................................................................................................... 19지원되지 않는 S3 API................................................................................................. 20지원되는 OpenStack Swift 호출.................................................................................62지원되지 않는 OpenStack Swift 호출.........................................................................63지원되는 Atmos REST API 호출................................................................................. 88지원되지 않는 Atmos REST API 호출......................................................................... 90오브젝트 API 확장...................................................................................................... 94일반 아카이브와 콜드 아카이브의 요구 사항 비교.................................................... 100보존을 위한 ECS Management API 리소스............................................................... 105이벤트 기반 보존에 대한 CAS API 함수.....................................................................109법적 증거 자료 보관에 대한 CAS API 함수................................................................. 111버킷 ACL................................................................................................................... 116버킷 ACL 그룹........................................................................................................... 116ECS Management REST API메서드 요약.................................................................. 130단순 모드에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예................................ 153Kerberos 모드에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예......................... 154ECS HDFS 구성 사전 요구 사항................................................................................ 164ECS HDFS Client Library.......................................................................................... 165core-site.xml 위치..................................................................................................... 167hbase-site.xml 위치................................................................................................... 170core-site.xml 파일의 위치......................................................................................... 183Hadoop core-site.xml 속성....................................................................................... 206

1234567891011121314151617181920212223

표


표


1부

S3

1장, "ECS의 Amazon S3 지원 기능 소개"

2장, "S3의 지원되는 기능"

3장, "S3 확장"

4장, "S3 메타데이터 검색 확장"

5장, "암호 키 생성 및 관리"

6장, "S3 서비스로 인증"

7장, "Java 클라이언트 액세스"

S3 13

S3


1장

ECS의 Amazon S3 지원 기능 소개

l ECS의 Amazon S3 API 지원 기능....................................................................... 16

ECS의 Amazon S3 지원 기능 소개 15

ECS의 Amazon S3 API 지원 기능이 부분에서는 Amazon S3 API에 대한 ECS 지원에 대해 설명합니다.

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

프로토콜 포트

HTTP 9020

HTTPS 9021

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

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

l S3 확장(22페이지)

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

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

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

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

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

l 관리자 가이드: 기본 URL 설정

ECS의 Amazon S3 지원 기능 소개


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

2장

S3의 지원되는 기능

l S3 API의 지원되는 기능 및 지원되지 않는 기능..................................................18

S3의 지원되는 기능 17

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

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

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

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

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

표 1 지원되는 S3 API

기능 참고

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

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

예:

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

DELETE Bucket

DELETE Bucket cors

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

GET Bucket (List Objects)

GET Bucket cors

GET Bucket acl

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

GET Bucket Object versions

GET Bucket versioning

HEAD Bucket

List Multipart Uploads

PUT Bucket

PUT Bucket cors

PUT Bucket acl



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

기능 참고

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

PUT Bucket versioning

DELETE Object

Delete Multiple Objects

GET Object

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

표 2 추가 기능

기능 참고

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

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

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

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


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

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

표 3 지원되지 않는 S3 API

기능 참고

DELETE Bucket policy

DELETE Bucket tagging

DELETE Bucket website

GET Bucket policy

GET Bucket location ECS는 단일 가상 데이터 센터만 인식합니다.

GET Bucket logging

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

GET Bucket tagging

GET Bucket requestPayment ECS에는 고유한 결제 모델이 있습니다.

GET Bucket website

PUT Bucket policy

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에서는 지원되지 않습니다.



3장

S3 확장

l S3 확장.............................................................................................................. 22l 바이트 범위 확장................................................................................................22l Retention........................................................................................................... 26l 파일 시스템 활성화............................................................................................ 27

S3 확장 21

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

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

l 바이트 범위 확장

l 보존 확장

l 파일 시스템 활성화 확장

l 메타데이터 검색 확장

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

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

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

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

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

오브젝트 내의 바이트 범위 업데이트오브젝트의 바이트 범위를 업데이트하기 위해 ECS API 확장을 사용하는 예가 아래에나와 있습니다.

먼저 bucket1에 있는 object1이라는 오브젝트에 대해 GET 요청을 수행하여 오브젝트를 검토합니다. object1 의 값은 The quick brown fox jumps over thelazy 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>

S3 확장


아래 예에서 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

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


The quick green fox jumps over the lazy dog.

오브젝트의 부분 덮어쓰기오브젝트의 부분을 덮어쓰기 위해 ECS API 확장을 사용하는 예가 아래에 나와 있습니다.

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

S3 확장

오브젝트의 부분 덮어쓰기 23

예를 들어 오프셋 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-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

오브젝트를 가져오면 최종 값 The quick brown cat jumps over the lazydog and cat.을 확인할 수 있습니다(green fox가 brown 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.

오브젝트에 데이터 추가오브젝트에 데이터를 추가하기 위해 ECS API 확장을 사용하는 예가 아래에 나와 있습니다.

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

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

형식은 다음과 같습니다. Range: bytes=-1-

S3 확장


다음은 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

오브젝트를 다시 가져오면 전체 값 The quick green fox jumps over thelazy 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.

오브젝트 내의 여러 바이트 범위 읽기오브젝트 내의 여러 바이트 범위를 읽기 위해 ECS API 확장을 사용하는 예가 아래에 나와 있습니다.

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

S3 확장

오브젝트 내의 여러 바이트 범위 읽기 25

Amazon S3 API는 읽기에 HTTP 헤더 Range 사용 시 한 범위만 지원하나, ECS는 여러바이트 범위를 지원합니다.

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--

Retention

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

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

오브젝트의 보존 기간

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

오브젝트의 보존 정책

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

버킷의 보존 기간

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

S3 확장


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

또한 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 헤더를 사용하여 파일 시스템 액세스를 활성화할 수 있습니다. (ECSManagement REST API를 사용하여) ECS Portal에서 버킷을 만들 때도 파일 시스템 액세스를 활성화할 수 있습니다.

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

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

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

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

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

파일 시스템에서의 교차 헤드 지원에 대한 자세한 정보는 다음에서 확인할 수 있습니다.

l HDFS 구성

l 관리자 가이드: NFS 파일 액세스 구성

S3 확장

수명주기(만료) 및 보존 27


S3 확장


4장

S3 메타데이터 검색 확장

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

S3 메타데이터 검색 확장 29

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

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

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

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

시스템 메타데이터뿐만 아니라 오브젝트에는 메타데이터 검색 결과의 일부로 반환될수 있는 속성도 있습니다.

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

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

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

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

사용 가능하고 인덱싱할 수 있는 시스템 메타데이터 값과 선택적으로 검색 쿼리 결과에반환될 수 있는 메타데이터 값은 여기에 나와 있습니다.

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

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

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

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

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




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> <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>


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

<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> </IndexableKeys></MetadataSearchList>

S3 API를 사용한 값 설정

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

API 경로 설명

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

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

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

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



API 경로 설명

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-" 헤더를 사용하여 오브젝트에 사용자 메타데이터를 할당할 수 있습니다. 할당되는 값은 모든 텍스트 문자열이 될 수 있으며 대/소문자를 구분합니다.

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

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

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

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

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

날짜 및 시간

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


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

예아래 예에서는 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} (…also standard pagination parameters apply)

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <IsTruncated>false</IsTruncated> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <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> </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가 테스트되는 데 기준이 되는 값입니다.

attributes=[fieldname,...]

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

l ContentEncoding

l ContentType

l Retention

l Expiration

l Expires

sorted=[selector]

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

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

include-older-versions=[true|false]

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


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

max-num

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

marker

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

날짜 및 시간 쿼리

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

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

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

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

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

?query=CreateTime>2015-01-01:00: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-num을 사용하여 결과 페이지 매김

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

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

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

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



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

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

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

<NextMarker>NO MORE PAGES</NextMarker>

쿼리에 특수 문자 사용

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

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> <IsTruncated>false</IsTruncated>


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

<ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <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> </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 지원이 나와 있습니다.

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에서는 지원되지 않습니다.


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

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

이름(별칭) 유형

ContentType string

Expiration datetime

ContentEncoding string

Expires datetime

Retention integer



5장

암호 키 생성 및 관리

l 암호 키 생성 및 관리.......................................................................................... 42l 오브젝트 사용자용 키 생성................................................................................ 42l S3 암호 키 생성: 셀프 서비스............................................................................. 43

암호 키 생성 및 관리 41

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

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

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

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

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

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

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

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

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

시작하기 전에

l ECS System Admin 또는 Namespace Admin이어야 함

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

절차

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

2. Object Users 테이블에서 암호 키를 할당하려는 사용자에 대해 Edit를 선택합니다.

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

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

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

API는 다음과 같습니다.

API 경로 설명

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



API 경로 설명

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

ECS Management REST API 참조에서 API 호출에 대한 자세한 정보를 확인할 수 있습니다.

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

특정 ECS 관리 작업을 수행하기 위해 사용자 지정 클라이언트를 생성하려는 경우 ECSManagement REST API 참조를 사용할 수 있습니다. 간단한 작업을 위해, 도메인 사용자는 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/>

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


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

http://www.emc.com/techpubs/api/ecs/v3-0-0-0/index.htm



셀프 서비스 키를 사용한 작업ECS Management REST API 참조를 사용하여 셀프 서비스 암호 키로 수행할 수 있는다양한 작업이 있습니다.

제공되는 예제에서는 curl 툴을 사용하여 다음 활동을 보여줍니다.

l 도메인 사용자로 로그인(44페이지)l 첫 번째 키 생성(44페이지)l 두 번째 키 생성(44페이지)l 키 확인(45페이지)l 모든 암호 키 삭제(45페이지)

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

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> <key_expiry_timestamp/> <key_timestamp>2015-04-27 17:39:13.813</key_timestamp></user_secret_key>

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

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwN




zQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -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


셀프 서비스 키를 사용한 작업 45

6장

S3 서비스로 인증

l S3 서비스로 인증............................................................................................... 48

S3 서비스로 인증 47

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



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


S3 서비스로 인증 49

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

7장

Java 클라이언트 액세스

l SDK를 사용하여 S3 서비스에 액세스.................................................................52

Java 클라이언트 액세스 51

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

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

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

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

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

ECS API 확장(S3 확장(22페이지) 참조)을 사용할 경우 EMC 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 검증 오류가 발생하고 연결에 실패합니다.



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

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

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

경로 스타일 주소 지정(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");


Java Amazon SDK 사용 53

listObjects(client);

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

client.copyObject(bucketName,objectFile.getName(),bucketName, "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) { } }}


ECS용 Java SDK 클라이언트 55

2부

OpenStack Swift

8장, "ECS의 OpenStack Swift 지원 소개"

9장, "Swift의 지원되는 기능"

10장, "Swift 확장"

11장, "Authentication"

12장, "인증"

OpenStack Swift 57

OpenStack Swift


8장

ECS의 OpenStack Swift 지원 소개

l ECS의 OpenStack Swift API 지원 기능..............................................................60

ECS의 OpenStack Swift 지원 소개 59

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

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

프로토콜 포트

HTTP 9024

HTTPS 9025

다음 항목에서는 지원되는 메서드, ECS 확장 기능 및 인증 메커니즘을 설명합니다.

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

l Swift API 확장(66페이지)

l OpenStack Swift 인증(72페이지)

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

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

l OpenStack API 예

ECS의 OpenStack Swift 지원 소개


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

9장

Swift의 지원되는 기능

l 지원되는 OpenStack Swift 작업........................................................................ 62

Swift의 지원되는 기능 61

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

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

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

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

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

표 4 지원되는 OpenStack Swift 호출

방법 경로 설명

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

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}

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

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

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

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

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

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

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

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



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

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

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


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

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

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

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


HEAD v1/{account} 컨테이너 수, 계정/테넌트의 OpenStackObject 스토리지에 저장된 총 바이트 등의 계정 메타데이터를 가져옵니다.

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

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

Copy는 PUT v1/{account}/{container}/{object}를X-Copy-From 헤더와 함께 사용하는 방식으로 지원됩니다.


지원되는 OpenStack Swift 작업 63

10장

Swift 확장

l Swift API 확장....................................................................................................66l 오브젝트 내의 바이트 범위 업데이트................................................................. 66l 오브젝트의 부분 덮어쓰기................................................................................. 67l 오브젝트에 데이터 추가.....................................................................................68l 오브젝트 내의 여러 바이트 범위 읽기................................................................ 69

Swift 확장 65

Swift API 확장오브젝트 API의 여러 가지 확장이 지원됩니다.

오브젝트 내의 바이트 범위 업데이트오브젝트의 바이트 범위를 업데이트하기 위해 ECS API 확장을 사용하는 예가 아래에나와 있습니다.

먼저 bucket1에 있는 object1이라는 오브젝트에 대해 GET 요청을 수행하여 오브젝트를 검토합니다. 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


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

green

HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52a

Swift 확장


Content-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


The quick green fox jumps over the lazy dog.

오브젝트의 부분 덮어쓰기오브젝트의 부분을 덮어쓰기 위해 ECS API 확장을 사용하는 예가 아래에 나와 있습니다.

데이터 요청에서 시작 오프셋을 제공하여 오브젝트의 부분을 덮어쓸 수 있습니다. 이요청에 포함된 데이터는 제시된 오프셋부터 쓰여지기 시작합니다. 형식은 다음과 같습니다. 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-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

Swift 확장

오브젝트의 부분 덮어쓰기 67

오브젝트를 가져오면 최종 값 The quick brown cat jumps over the lazydog and cat.을 확인할 수 있습니다(green fox가 brown 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.






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

Swift 확장



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


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

오브젝트 내의 여러 바이트 범위 읽기오브젝트 내의 여러 바이트 범위를 읽기 위해 ECS API 확장을 사용하는 예가 아래에 나와 있습니다.

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

Amazon S3 API는 읽기에 HTTP 헤더 Range 사용 시 한 범위만 지원하나, ECS는 여러바이트 범위를 지원합니다.

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--

Swift 확장

오브젝트 내의 여러 바이트 범위 읽기 69

Swift 확장


11장

Authentication

l OpenStack Swift 인증........................................................................................72l OpenStack 버전 1 인증 ......................................................................................73l OpenStack 버전 2 인증...................................................................................... 75l ECS Keystone V3 통합을 사용한 인증................................................................77

Authentication 71

OpenStack Swift 인증

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

v1

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

v2

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

v3

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

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

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

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

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

시작하기 전에

ECS System Admin이어야 합니다.

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

절차

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

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

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

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

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

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

Authentication




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

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

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

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

절차

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

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

요청:

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

응답:

HTTP 200

Authentication

OpenStack 버전 1 인증 73

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: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb 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)

$ curl -v -X GET -s -H "X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435"

Authentication


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-Type: application/json" -d '{"auth":

Authentication

OpenStack 버전 2 인증 75

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

{"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"}]}]}}

Authentication


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 네임스페이스도 생성되어 있어야 합니다. 자세한 내용은 Keystone 사용자를인증하도록 ECS 구성(78페이지)에 나와 있습니다.

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

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

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

3. 작업이 컨테이너 작업이면 ECS가 다음과 같이 프로젝트의 사용자 역할을 기준으로요청된 작업을 평가합니다.

a. 작업이 컨테이너 나열 작업이고 사용자에게 관리자 역할이 있는 경우 허용

b. 작업이 컨테이너 생성 작업이고 사용자에게 관리자 역할이 있는 경우 허용

c. 작업이 컨테이너 메타데이터 업데이트 작업이고 사용자에게 관리자 역할이 있는 경우 허용

d. 작업이 컨테이너 메타데이터 읽기 작업이고 사용자에게 관리자 역할이 있는 경우 허용

Authentication

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

e. 작업이 컨테이너 삭제 작업이고 사용자에게 관리자 역할이 있는 경우 허용

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

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

Keystone 사용자를 인증하도록 ECS 구성Keystone 사용자를 인증하려면 인증 공급자를 ECS에 추가하고 Swift 사용자가 속하는네임스페이스를 생성해야 합니다.

시작하기 전에

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

l ECS System Admin 계정 자격 증명이 필요합니다.

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

절차

1. System Admin으로 ECS에 로그인합니다.

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

자세한 내용은 관리자 가이드: 인증 공급자 구성 섹션을 참조하십시오.

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

Keystone 프로젝트 ID를 가져와야 합니다.

결과

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

Authentication



12장

인증

l 컨테이너에 대한 인증........................................................................................ 80

인증 79

컨테이너에 대한 인증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 컨테이너 내의 오브젝트 - 컨테이너 내에 있는 오브젝트의 컨텐츠를 읽습니다.

관리자가 컨테이너에 대한 쓰기 액세스를 할당"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 스토리지 내의 오브젝트 - 컨테이너 내에 오브젝트를 쓰거나 재정의합니다.

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

인증

컨테이너에 대한 인증 81

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

인증


3부

EMC Atmos

13장, "ECS의 EMC Atmos 지원 기능 소개"

14장, "Atmos의 지원되는 기능"

15장, "Atmos API 확장"

EMC Atmos 83

EMC Atmos


13장

ECS의 EMC Atmos 지원 기능 소개

l ECS의 EMC Atmos API 지원 기능......................................................................86

ECS의 EMC Atmos 지원 기능 소개 85

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

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

프로토콜 포트

HTTP 9022

HTTPS 9023

지원되는 작업에 대한 추가 정보는 EMC 지원 영역에서 제공되는 Atmos Programmer’sGuide에서 확인할 수 있습니다.

l Atmos Programmer's Guide

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

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

ECS의 EMC Atmos 지원 기능 소개


14장

Atmos의 지원되는 기능

l 지원되는 EMC Atmos REST API 호출................................................................ 88l 지원되지 않는 EMC Atmos REST API 호출........................................................ 89l EMC Atmos REST API 호출의 서브테넌트 지원.................................................90

Atmos의 지원되는 기능 87

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

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

표 6 지원되는 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 오브젝트 이름 변경

메타데이터 작업

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

오브젝트 정보 가져오기



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


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 오브젝트의 만료 및 보존은 지원되지 않습니다.

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

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

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

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

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

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


지원되지 않는 EMC Atmos REST API 호출 89

표 7 지원되지 않는 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 REST API 호출의 서브테넌트 지원ECS에는 ECS 서브테넌트 지원을 Atmos 애플리케이션에 추가하는 2개의 기본 RESTAPI 호출이 포함되어 있습니다.

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

API 호출 예

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

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

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



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


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

15장

Atmos API 확장

l API 확장.............................................................................................................94

Atmos API 확장 93

API 확장오브젝트 API의 여러 가지 확장이 지원됩니다.

확장 및 확장을 지원하는 API가 다음 표에 정리되어 있습니다.

표 8 오브젝트 API 확장

기능 참고

PUT Object (range-append)

Range 헤더를 사용하여 추가될 오브젝트 범위를 지정합니다.

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






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)

Atmos API 확장


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


Atmos API 확장

오브젝트에 데이터 추가 95

Atmos API 확장


4부

CAS

16장, "ECS에서 CAS 지원 설정"

CAS 97

CAS


16장

ECS에서 CAS 지원 설정

l ECS에서 CAS 지원 설정................................................................................... 100l 콜드 스토리지...................................................................................................100l Compliance....................................................................................................... 101l ECS의 CAS 보존...............................................................................................103l CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최

대 관리자..........................................................................................................105l 네임스페이스 보존 정책 설정.............................................................................111l CAS 사용자를 위한 버킷 생성 및 설정...............................................................112l CAS 오브젝트 사용자 설정................................................................................ 113l CAS를 위한 버킷 ACL 설정............................................................................... 114l CAS 사용자를 지원하는 ECS Management API.................................................116l CAS(Content Addressable Storage) SDK API 지원............................................117

ECS에서 CAS 지원 설정 99

ECS에서 CAS 지원 설정ECS의 CAS(Content Addressable Storage) 지원을 소개합니다.

ECS CAS를 통해 CAS SDK 기반 클라이언트 애플리케이션은 변경되지 않는 컨텐츠 오브젝트를 ECS 스토리지에서 저장, 검색 및 삭제할 수 있습니다.

ECS 설정을 구성하려면 먼저 기본 ECS 스토리지를 프로비저닝해야 합니다. 프로비저닝은 보통 새 ECS 랙이 설치될 때 완료됩니다. 여기에는 스토리지 풀, VDC 및 복제 그룹의 설정이 포함됩니다. ECS CAS에서는 CAS를 지원하기 위해 이러한 오브젝트를 생성하거나 편집할 필요가 있을 경우 표준 설명서를 참조할 수 있습니다. 자세한 내용은 관리자 가이드: 스토리지 풀, VDC 및 복제 그룹 구성 섹션을 참조하십시오.

스토리지 풀의 경우 콜드 아카이브 설정을 고려해 볼 수 있습니다. 자세한 내용은 콜드스토리지(100페이지) 섹션을 참조하십시오.

다음으로, 표준 설명서를 참조하여 네임스페이스, 사용자 및 버킷을 설정합니다.

l 관리자 가이드: 네임스페이스 구성

l 관리자 가이드: 사용자 및 역할 관리

l 관리자 가이드: 버킷 생성 및 관리

이 장에서는 CAS를 지원하기 위해 기본 구성을 수정하는 방법을 설명합니다.

콜드 스토리지콜드 스토리지 아카이브에 대해 설명합니다.

콜드 아카이브는 자주 변경되지 않는 오브젝트를 저장하므로 강력한 기본 EC 체계가필요하지 않습니다. 콜드 아카이브에 사용되는 EC 체계는 10개 데이터 조각과 2개 코딩 조각(10/12)입니다. 효율성은 1.2x입니다.

새로운 스토리지 풀을 생성할 때 콜드 아카이브(콜드 스토리지)를 지정할 수 있습니다.스토리지 풀을 생성한 후에는 EC 체계를 변경할 수 없습니다. 이 체계는 단일 노드가손실되는 경우를 지원할 수 있습니다. 또한 2개의 개별 노드에서 6개 드라이브 중 1개또는 12개 드라이브 중 2개가 손실되는 경우도 지원합니다.

EC 요구 사항

표 9 일반 아카이브와 콜드 아카이브의 요구 사항 비교

활용 사례 활성화되는 방식 필요한 최소노드 수

필요한 최소디스크 수

권장되는 디스크 수

EC 효율성 EC 체계

일반 아카이브 기본값 4 16* 32 1.33x 12/16

콜드 아카이브 시스템 관리자가 구성 8 12* 24 1.2x 10/12

*C-Series 어플라이언스에 대한 구축 가능한 최소 구성은 각각 12개 디스크가 있는 2개의 어플라이언스이므로 24개 디스크가 유효한 최소 구성입니다.

스토리지 풀 구성포털에서 콜드 아카이브를 설정하려면 새로운 스토리지 풀을 생성할 때 Cold Storage를 선택하십시오. 스토리지 풀을 생성한 후에는 이 설정을 변경할 수 없습니다.







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 플랫폼 보안 기능:


Compliance 101

l 노드에 대한 루트 액세스가 비활성화되어 있습니다. 즉, 루트 계정에 대한 로그인이허용되지 않습니다.

l ECS 고객은 설치 시 설정되는 admin 계정을 사용하여 노드에 액세스할 수 있습니다.

l 권한이 부여된 admin 계정 사용자는 sudo를 사용하여 노드에 대한 명령을 실행합니다.

l sudo 명령에 대한 전체 감사 로깅 기능이 있습니다.

l ESRS는 노드에 대한 모든 원격 액세스를 종료할 수 있는 기능을 제공합니다. ESRSPolicy Manager에서 Start Remote Terminal 작업을 Never Allow로 설정합니다.

l ftpd, sshd 등의 모든 불필요한 포트가 닫힙니다.

l ECS Lock Admin(로그인: emcsecurity)은 클러스터의 노드를 잠글 수 있습니다.이는 네트워크를 통한 SSH의 원격 액세스가 비활성화됨을 뜻합니다. Lock Admin은 원격 유지 보수 작업 또는 기타 권한이 있는 액세스를 허용하도록 노드를 잠금해제할 수 있습니다. 노드 잠금은 ECS Portal 또는 ECS Management API의 권한 있는 사용자에게 영향을 미치지 않습니다. 노드 잠금 및 잠금 해제에 대한 자세한 내용은 ECS 관리자 가이드를 참조하십시오.

규정 준수 및 보존 정책규정 준수가 설정된 ECS 시스템에서 기록 보존에 관한 향상된 규칙에 대해 설명합니다.

ECS에는 오브젝트, 버킷 및 네임스페이스 레벨에서 활성화되거나 정의된 오브젝트 보존 기능이 있습니다. 규정 준수는 보존 중인 오브젝트에 대한 보존 설정에서 변경할 수있는 범위를 제한함으로써 이러한 기능을 강화합니다. 규칙은 다음과 같습니다.

l 규정 준수는 네임스페이스 레벨에서 활성화됩니다. 이는 네임스페이스에 포함된모든 버킷의 보존 기간이 0보다 커야 함을 의미합니다. CAS의 경우, EnforceRetention Information in Object 설정이 활성화되어 있어야만 보존 값이 0인 버킷을 생성할 수 있습니다.

l 규정 준수는 네임스페이스를 생성할 때만 네임스페이스에 대해 활성화할 수 있습니다. (기존 네임스페이스에는 규정 준수를 추가할 수 없습니다.)

l 규정 준수를 활성화하고 나면 비활성화할 수 없습니다.

l 네임스페이스에 포함된 모든 버킷의 보존 기간이 0보다 커야 합니다.

오브젝트 레벨 보존 기간을 할당하는 애플리케이션을 사용하는 경우 ECS를 사용하여 애플리케이션 보존 기간보다 길게 보존 기간을 할당하지 마십시오. 이 작업으로인해 애플리케이션 오류가 발생합니다.

l 데이터가 저장된 버킷은 보존 값에 관계없이 삭제할 수 없습니다.

l 버킷에 Infinite 옵션을 사용하면 규정 준수가 설정된 네임스페이스에 속한 버킷에저장된 오브젝트를 삭제할 수 없습니다.

l 오브젝트에 대한 보존 기간은 삭제하거나 단축할 수 없습니다. 따라서, 버킷에 대한보존 기간도 삭제하거나 단축할 수 없습니다.

l 오브젝트 및 버킷 보존 기간은 늘릴 수 있습니다.

l 보존 중인 오브젝트를 삭제할 수 있는 사용자는 없습니다. CAS의 승인된 삭제 권한이 있는 사용자도 삭제가 불가능합니다.



그림 1 ECS Portal에서 새로운 네임스페이스에 대해 규정 준수 활성화

규정 준수 에이전트규정 준수 에이전트의 작동에 대해 설명합니다.

규정 준수 기능은 규정 준수 모니터링을 제외하고 기본적으로 모두 활성화됩니다. 모니터링 기능이 활성화된 경우 에이전트가 정기적으로 메시지를 스레드에 로깅합니다.

규정 준수 모니터링을 활성화하려면 EMC 고객 지원 본부와 계약을 체결해야 합니다.모니터링 메시지는 노드에서 명령을 실행하여 확인할 수 있습니다. ECS Portal에는 표시되지 않습니다.

ECS의 CAS 보존CAS C-Clip은 애플리케이션에서 삭제하기 전까지 연결된 오브젝트가 ECS 스토리지에보존되는 기간을 제어하는 보존 기간을 가질 수 있습니다.


규정 준수 에이전트 103

보존 기간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 보존 적용 방식ECS Portal에서, 또는 ECS Management API를 사용하여 네임스페이스에 대한 보존 정책을 정의할 수 있습니다. 네임스페이스 보존 정책 설정을 참조하십시오.

외부 CAS 애플리케이션은 C-Clip 생성 중에 C-Clip에 고정된 보존 기간 또는 보존 정책을 할당할 수 있습니다.

API를 통해 보존 기간을 적용할 때, 기간을 초 단위로 지정합니다.

ECS CAS는 모든 보존 관련 계산에 마이그레이션 시간이 아니라 C-Clip의 생성 시간을사용합니다.

ECS Management API로 보존 정책을 생성하는 방법ECS Management REST API를 사용하여 보존 기간 및 정책을 생성할 수 있는데, 아래에 요약된 내용이 나와 있습니다.

표 10 보존을 위한 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 ManagementREST API온라인 참고 자료는 다음을 참조하십시오. ECS Management REST API 참조.

CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최대 관리자

ECS에서 지원되는 CAS API에서 사용할 수 있는 고급 보존 기능에 대해 설명합니다.

고객 애플리케이션에서는 CAS API를 사용하여 보존 전략을 지원합니다. CAS 워크로드가 ECS로 마이그레이션되면 ECS가 CAS API 기능을 인식하므로 고객 애플리케이션에서 마이그레이션된 데이터를 계속 작업할 수 있습니다. ECS에서는 별도의 라이센스없이 다음과 같은 ARM(Advanced Retention Management) 기능을 사용할 수 있습니다.


CAS 애플리케이션의 고급 보존: 이벤트 기반 보존, 법적 증거 자료 보관, 최소/최대 관리자 105



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 버킷 보존 기능이 설명되어 있습니다.



기능 설명

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이



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 보존을 적용하는 경우 가변 보존 기간에 대한 최소/최대 관리자 설정을 준수해야합니다.



표 11 이벤트 기반 보존에 대한 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 수명주기는 다음과 같습니다.



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에서 이러한 제한을 적용합니다.



표 12 법적 증거 자료 보관에 대한 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 확인란을 선택합니다.


네임스페이스 보존 정책 설정 111

그림 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. 필드를 아래와 같이 입력합니다.



필드 값

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 작업을 선택합니다.


CAS 오브젝트 사용자 설정 113

그림 7 오브젝트 사용자에 대한 CAS 설정

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를 선택합니다.

그림 9 버킷 ACL 관리

4. 권한을 수정합니다.


CAS를 위한 버킷 ACL 설정 115

표 13 버킷 ACL

ECS ACL ACL 정의

READ 읽기, 쿼리 및 존재 기능

WRITE 쓰기 및 법적 증거 자료 보관 기능

FULL_CONTROL 읽기, 삭제, 쿼리, 존재, 클립 복사, 쓰기, 법적증거 자료 보관

PRIVILEDGED_WRITE 권한이 필요한 삭제

DELETE 삭제

다른 ECS ACL은 CAS에 아무런 의미도 없습니다.


6. 그룹 수준에서 ACL을 편집할 수도 있습니다. 그룹은 사전 정의되며 그룹의 구성원은 사용자 기준을 바탕으로 자동으로 정해집니다. Group ACLs를 선택합니다.

7. Add를 선택합니다.

8. Group Name 목록에서 편집하려는 그룹을 선택합니다.

표 14 버킷 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 사용자 메타데이터를 가져옵니다.

자세한 내용은 ECS Management REST API 참조 항목을 참조하십시오.

CAS(Content Addressable Storage) SDK API 지원지원되는 버전ECS는 CAS 빌드 3.1.544 이상 버전을 지원합니다. 또한 이용 중인 ISV의 애플리케이션이 ECS를 지원하는지 확인해야 합니다.

ECS CAS 지원에 대한 자세한 내용은 ECS Portal로 CAS SDK 애플리케이션에 대한 지원 구성에 나와 있습니다.

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


CAS(Content Addressable Storage) SDK API 지원 117


l FPClip_IsEBREnabled



5부

ECS Management API

17장, "ECS Management REST API 소개"

18장, "ECS Management Service로 인증"

19장, "ECS Management REST API 요약"

ECS Management API 119

ECS Management API


17장

ECS Management REST API 소개

l ECS Management REST API.............................................................................122

ECS Management REST API 소개 121

ECS Management REST API이 부분에서는 ECS Management REST API에 액세스하고 이를 사용하여 인증하는 방법을 설명하고, API 경로를 요약해서 제공합니다. ECS Management REST API를 사용하여 오브젝트 저장소를 구성하고 관리할 수 있습니다. 오브젝트 저장소가 구성되면 후속 오브젝트 생성, 읽기, 업데이트 및 삭제 작업이 ECS에서 지원되는 오브젝트 및 파일프로토콜을 사용하여 수행됩니다.

다음 항목을 참조하여 REST API에 액세스하는 방법과 인증 방법을 파악할 수 있습니다.

l ECS Management REST API로 인증(124페이지)

API 경로는 다음 섹션에 요약되어 있습니다.

l ECS Management REST API 요약(130페이지)

그리고 다음에서 API 참조 정보가 제공됩니다.

l ECS Management REST API 참조

ECS Management REST API 참조는 소스 코드에서 자동 생성되고 API에서 사용 가능한 메서드에 대한 참조를 제공합니다.

ECS Management REST API 소개




18장

ECS Management Service로 인증

l ECS Management REST API로 인증................................................................. 124

ECS Management Service로 인증 123

ECS Management REST API로 인증ECS는 모든 REST API 호출에 토큰 기반 인증 시스템을 사용합니다. 쿠키를 사용하거나 사용하지 않는 경우, ECS REST API로 인증하는 예를 제시합니다.

사용자가 ECS에 대해 인증되면 인증 토큰이 반환되며 후속 호출에는 이를 사용자 인증에 사용할 수 있습니다.

l 클라이언트가 자동으로 리디렉션을 따르는 경우 HTTP 401 코드가 반환되는데, 새토큰을 받으려면 로그인 후 인증해야 함을 의미합니다.

l 클라이언트가 자동으로 리디렉션을 따르지 않으면 HTTP 302 코드가 반환됩니다.302 코드는 클라이언트에 다시 인증을 받을 곳을 지정합니다.

다음 방법으로 인증 토큰을 검색하고 사용할 수 있습니다.

l 성공적인 인증 요청에서 X-SDS-AUTH-TOKEN 쿠키를 저장하고 후속 요청에 따라해당 쿠키를 보냅니다.

l 성공적인 인증 요청에서 X-SDS-AUTH-TOKEN HTTP 헤더를 읽고 후속 요청에 해당 헤더를 복제합니다.

REST API는 포트 :4443에서 사용할 수 있고 클라이언트는 다음 형식으로 로그인 요청을 발급하여 ECS에 액세스합니다.

https://<ECS_IP>:4443/login

AUTH-TOKEN으로 인증이 예제에서는 성공한 인증 요청에서 X-SDS-AUTH-TOKEN http 헤더를 읽어 후속 요청에 복제하여 인증 토큰을 사용하는 방법을 보여줍니다. 이 예제에서는 쿠키를 사용하지 않습니다. 여기서는 가독성을 고려하여 curl로 작성되고 포맷된 예제를 보여줍니다.

이 명령은 /login 리소스에서 GET을 실행합니다. -u 옵션은 기본 인증 헤더의 사용자를나타냅니다. 요청에는 사용자 지정이 포함되어야 합니다. 인증에 성공하면, 인코딩된토큰을 포함한 X-SDS-AUTH-TOKEN 헤더뿐 아니라 HTTP 200 코드도 반환됩니다.

기본 관리 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):

그러면 다음 API 호출에서 토큰을 다시 전달할 수 있습니다. X-SDS-AUTH-TOKEN 내용을 복제하여 curl의 -H 스위치를 통해 다음 요청으로 전달할 수 있습니다.

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>

쿠키로 인증이 예제에서는 성공적인 인증 요청에서 쿠키를 저장한 다음 후속 요청에서 쿠키를 전달하여 인증 토큰을 사용하는 방법을 보여줍니다. 여기서는 가독성을 고려하여 curl로 작성되고 포맷된 예제를 보여줍니다.

이 예제에서는 ?using-cookies=true 매개 변수를 지정하여 정상적인 HTTP 헤더 외에쿠키를 받으려는 의사를 표시합니다. 이 curl 명령을 실행하면 인증 토큰이 현재 디렉토리에 cookiefile이라는 이름의 파일에 저장됩니다.

curl -L --location-trusted -k https://<ECS_IP>:4443/login?using-cookies=true -u "root:Password" -c cookiefile -v

다음 명령은 -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>


쿠키로 인증 125

<id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name> </namespace></namespaces>

로그아웃로그아웃 API는 세션을 종료합니다.

지정된 사용자에게는 최대 100개의 동시 인증 토큰이 허용됩니다. 이 한계를 넘어서면,시스템에서는 토큰을 사용할 수 있을 때까지 이 사용자에 대한 새로운 연결을 모두 거부합니다. 토큰이 자연스럽게 만료되거나 다음 URI를 명시적으로 호출하면 토큰을 사용할 수 있습니다.

https://<ECS_IP>:4443/logout

여러 세션이 동시에 실행 중인 경우 이 URI를 호출하면 현재 사용자와 관련된 모든 토큰이 강제로 종료됩니다.

GET https://<ECS_IP>:4443/logout?force=true

다음은 로그아웃 요청의 예입니다.

요청

GET https://<ECS_IP>:4443/logout

X-SDS-AUTH-TOKEN:{Auth_Token}

로그아웃하려면 인증 토큰과 함께 헤더 또는 쿠키를 전달합니다.

응답

HTTP 200

WhoamiECS 사용자는 whoami API 호출을 사용하여 자신의 사용자 이름, 테넌트 연결 및 역할을 볼 수 있습니다.

요청

GET https://<ECS_IP>:4443/user/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>

이 예에서는 루트 사용자와 "ns1" 네임스페이스에 대한 NAMESPACE_ADMIN 역할에할당된 사용자에 대한 whoami 출력을 보여줍니다.


Whoami 127

19장

ECS Management REST API 요약

l ECS Management REST API 요약.................................................................... 130

ECS Management REST API 요약 129

ECS Management REST API 요약ECS Management REST API를 사용하여 ECS 오브젝트 저장소를 구성하고 관리할 수있습니다.

다음 표에는 ECS Management REST API가 요약되어 있습니다.

표 15 ECS Management REST API메서드 요약

API 영역 설명

구성

인증서 /object-cert인증서를 관리하기 위한 API입니다.

/object-cert/keystoreEMC가 사용하는 인증서 체인을 지정하고 인증서를 순환하기 위한 API입니다.

구성 속성 /config/object/properties사용자 범위를 GLOBAL 또는 NAMESPACE로 설정할 수 있는 API입니다.

GLOBAL 범위에서는 사용자가 글로벌이며 네임스페이스 간 공유가 가능합니다. 이 경우, 사용자와 연결된 기본 네임스페이스가 오브젝트 작업을 위한 네임스페이스를 결정하고 작업을 위해 네임스페이스를 제공할 필요가 없습니다. 사용자 범위가 NAMESPACE인 경우, 사용자는 어떤 네임스페이스와 연결되므로 각각 다른 네임스페이스와 연결되어 있지만 이름은 같은 사용자가 더 있을 수 있습니다. NAMESPACE 모드에서는 모든 작업에 네임스페이스가 제공되어야 합니다.

첫 번째 사용자가 생성되기 전에 설정되어야 합니다. 기본값은GLOBAL입니다.

라이센스 /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입니다.



표 15 ECS Management REST API메서드 요약 (계속)

API 영역 설명

파일 시스템 액세스

NFS /object/nfsECS 버킷을 기반으로 NFS 내보내기를 생성하고 Unix 사용자 및 그룹이 내보내기에 액세스할 수 있는 API입니다.

사용량 측정

비용 청구 /object/billing테넌트 및 버킷 레벨에서 오브젝트 저장소 사용량을 측정할 수 있는API입니다. 자세한 내용은 관리자 가이드: 테넌트 관리 섹션을 참조하십시오.

마이그레이션

변환 /object/transformation데이터를 변환할 수 있는 API입니다.

모니터링

Capacity /object/capacity현재 관리되는 용량을 검색하기 위한 API입니다.

대시보드

알림 /vdc/alerts감사 알림을 검색하기 위한 API입니다.

이벤트 /vdc/events지정된 네임스페이스에 대한 감사 이벤트를 반환하는 API입니다.

멀티 테넌시

네임스페이스 /object/namespaces네임스페이스를 생성하고 관리할 수 있는 API입니다.

또한, 네임스페이스의 보존 기간을 설정할 수 있습니다. 자세한 내용은 관리자 가이드: 테넌트 관리 섹션을 참조하십시오.

원거리 복제

복제 그룹 /data/data-service/vpools복제 그룹의 생성 및 관리를 위한 API입니다.

일시적 장애 영역 /tempfailedzone/모든 또는 지정된 복제 그룹에 대한 일시적 장애 영역을 검색할 수 있는 API입니다.

프로비저닝

기본 URL /object/baseurl






API 영역 설명

기존 애플리케이션이 ECS 오브젝트 저장소와 작동할 수 있도록 해주는 기본 URL을 생성할 수 있는 API입니다. 기본 URL에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 관리자 가이드: 기본 URL 설정.

버킷 /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/vdcsVDC를 추가하고 VDC 엔드포인트 간 그리고 ECS 사이트 간 데이터 복제를 위해 암호 키를 지정할 수 있습니다.

VDC 키 저장소 /vdc/keystoreVDC에 대한 인증서를 관리하기 위한 API입니다.

지원

Call Home /vdc/callhome/ConnectEMC를 구성하고 ConnectEMC에 대한 알림 이벤트를 생성하는 API입니다.

CLI 패키지 /cliECS 패키지를 다운로드하는 API입니다.

사용자 관리

인증 공급자 /vdc/admin/authproviders인증 공급자가 추가 및 관리할 수 있는 API입니다.

암호 그룹(Swift) /object/user-passwordOpenStack Swift 인증에 사용할 암호를 생성할 수 있는 API입니다.

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







API 영역 설명

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

사용자(오브젝트) /object/users오브젝트 사용자를 생성하고 관리하기 위한 API입니다. 오브젝트 사용자는 항상 네임스페이스와 연결됩니다. API는 S3 액세스에 사용할 수있는 암호 키를 반환합니다. S3 암호 키에 할당된 오브젝트 사용자는REST API를 사용하여 이를 변경할 수 있습니다.

/object/users/lock.

사용자 액세스를 잠글 수 있습니다.

사용자(관리) /vdc/users관리 사용자를 생성하고 관리하기 위한 API입니다. 관리 사용자를System Admin 역할 또는 Namespace Admin 역할에 할당할 수 있습니다. 로컬 관리 사용자 암호를 변경할 수 있습니다.



6부

HDFS

20장, "ECS HDFS는 무엇입니까?"

21장, "HDFS 파일 시스템용 버킷 생성"

22장, "Hortonworks Ambari를 사용하여 ECS HDFS에 Hadoop 설정"

23장, "단순 Hadoop 클러스터와 ECS HDFS 통합 구성"

24장, "보안(Kerberized) Hadoop 클러스터와 ECS HDFS 통합 구성"

25장, "Kerberos 구성에 대한 지침"

26장, "문제 해결"

27장, "ECS HDFS의 Hadoop core-site.xml 속성"

28장, "보안 버킷 메타데이터 예"

HDFS 135

HDFS


20장

ECS HDFS는 무엇입니까?

l ECS HDFS란 무엇인가?................................................................................... 138l ECS HDFS를 사용하도록 Hadoop 구성 ............................................................139l 파일 시스템 액세스를 위한 ECS HDFS URI...................................................... 140l Hadoop 인증 모드.............................................................................................140l 단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션...................... 144l 파일 시스템 상호 작용...................................................................................... 144l 지원되는 Hadoop 애플리케이션 및 지원되지 않는 Hadoop 애플리케이션........ 145

ECS HDFS는 무엇입니까? 137

ECS HDFS란 무엇인가?ECS HDFS는 ECS 스토리지 인프라스트럭처를 기반으로 Hadoop 2.X 애플리케이션을실행할 수 있게 해 주는 HCFS(Hadoop Compatible File System)입니다.

기본으로 제공되는 Hadoop 파일 시스템 환경에서, ECS HDFS 환경에서, 또는 HDFS나ECS HDFS, 환경에서 사용 가능한 다른 Hadoop Compatible File System이 조합된 환경에서 Hadoop 배포판을 실행하도록 구성할 수 있습니다. 다음 그림은 ECS HDFS와 기존 Hadoop 클러스터의 통합 방식을 보여 줍니다.

그림 10 Hadoop 클러스터에 통합된 ECS HDFS

Hadoop Cluster

ResourceManager

Hadoop Client

ECS Client Library

Node Manager

MapReduce Task

Appliance Commodity

MapReduce Request

Node Manager

MapReduce Task

Node Manager

MapReduce Task

ECS data nodes

ECS data nodes

ECS data nodes

ECS Client Library ECS Client Library

ECS HDFS를 사용하도록 구성된 Hadoop 환경에서 ECS HDFS 데이터 노드 각각은 기존 Hadoop NameNode의 역할을 합니다. 다시 말해, 모든 ECS HDFS 데이터 노드는HDFS 요청을 받아서 처리할 수 있습니다.

Hadoop 클라이언트를 기존 HDFS가 아닌 ECS HDFS를 사용하도록 설정하면 ECSHDFS가 모든 HDFS 활동을 수행하게 됩니다. 각 ECS HDFS 클라이언트 노드에서 기존의 모든 Hadoop 구성 요소는 ECS HDFS Client Library(ViPRFS JAR 파일)를 사용하여HDFS 활동을 수행하게 됩니다.

ECS HDFS를 기존 Hadoop 환경과 통합하려면 다음 요구 사항을 충족해야 합니다.



l Hadoop 클러스터가 이미 설치 및 구성되어 있어야 합니다. 다음 배포판이 지원됩니다.

n Hortonworks 2.0, 2.1, 2.2, 2.3

ECS의 HDFS는 Cloudera 또는 Pivotal HD로부터 공인 인증을 받지 않았습니다. 이는 향후 ECS Hadoop 로드맵의 일부입니다.

Hortonworks 배포판을 사용하는 경우 Hortonworks Ambari를 사용할 수 있습니다.Hortonworks 2.3(Hadoop 2.7)은 ECS 스택과 함께 제공됩니다. 이를 활성화하여ECS HDFS 통합을 단순화할 수 있습니다. 이러한 배포판을 사용하는 지침은 다음에 나와 있습니다. Ambari를 사용하여 Hortonworks 클러스터 구축(156페이지).

l Hadoop이 설치되어 있고 ECS HDFS를 지원하도록 구성되어 있어야 합니다. 이를위해서는 다음이 필요합니다.

n 하나 이상의 파일 시스템에 HDFS 액세스에 사용되는 버킷이 활성화되어 있어야 합니다.

n ECS 클라이언트 라이브러리가 클러스터에 구축되어 있어야 합니다.

l Hadoop 클러스터의 경우 Kerberos를 사용하거나 Active Directory와 Kerberos를 사용해야 합니다.

n Kerberos 서비스 보안 주체가 ECS 노드에 구축되어 있어야 합니다.

n 보안 메타데이터가 버킷에 구축되어 있어야 합니다.

ECS HDFS를 사용하도록 Hadoop 구성Hadoop은 시스템 구성 정보를 core-site.xml, hdfs-site.xml, hive-site.xml등의 여러 파일에 저장합니다. core-site.xml을 편집하는 작업은 ECS HDFS 구성에 있어 반드시 필요한 부분입니다.

core-site.xml에서 추가하거나 수정할 수 있는 속성에는 다음과 같은 유형이 있습니다.

l ECS HDFS Java 클래스: 이 속성 세트는 ECS HDFS Client Library에 포함되어 있는ECS HDFS 구축 클래스를 정의하며, 필수 항목입니다.

l 파일 시스템 위치 속성: 이 속성은 Hadoop 작업을 실행할 때 사용할 파일 시스템URI(체계 및 권한)와 특정 ECS 파일 시스템에 사용할 ECS 데이터 노드의 IP 주소를 정의합니다.

l Kerberos 영역 및 서비스 보안 주체 속성: 이 속성은 Kerberos가 있는 Hadoop 환경에서 실행 중일 때만 필요하며, Hadoop 및 ECS HDFS 사용자를 매핑합니다.

core-site.xml은 Hadoop 클러스터의 각 노드에 위치합니다. core-site.xml의각 인스턴스에 동일한 속성을 추가해야 합니다.

구성 파일을 수정할 경우 수작업으로 파일을 편집하는 것보다 관리 인터페이스를 사용하는 것이 좋습니다. 또한, 관리 인터페이스를 사용하여 수행한 변경 내용은 클러스터전체에 걸쳐 유지됩니다.


ECS HDFS를 사용하도록 Hadoop 구성 139

파일 시스템 액세스를 위한 ECS HDFS URIECS 파일 시스템을 사용하도록 Hadoop을 구성한 후에는 ECS HDFS URI를viprfs:// 체계와 ECS 버킷, 테넌트 네임스페이스, 사용자 정의 설치 이름을 조합한권한으로 지정하여 액세스할 수 있습니다.

ECS HDFS URI는 다음과 유사하게 나타납니다.

viprfs://bucket_name.namespace.installation/path

bucket_name은 HDFS 사용 버킷에 해당합니다. 여기에는 Hadoop으로 분석할 데이터가 포함됩니다. namespace는 테넌트 네임스페이스이며, installation_name은 특정 ECS노드 세트 또는 로드 밸런싱 장치에 지정된 이름입니다. ECS HDFS는 ECS 노드 또는로드 밸런싱 장치의 IP 주소가 포함된 fs.vipr.installation.[installation_name].hosts 속성을 사용하여 ECS 노드 세트 또는 로드 밸런싱 장치에 대해 installation_name 을 확인합니다.

installation_name이 ECSECS 노드 세트에 매핑되는 경우 ECS에 활성 노드 목록을 쿼리할 빈도를 지정할 수 있습니다. fs.vipr.installation.[installation_name].resolution을dynamic으로 설정하고 fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms 값을 설정하여 ECS에 활성 노드 목록을 쿼리할 빈도를 지정합니다.

단순 환경 및 Kerberos 환경 모두에 대해 ECS HDFS URI를 core-site.xml에서fs.defaultFS 속성 값으로 설정하여 이 URI를 기본 파일 시스템으로 지정할 수도 있지만, 필수 사항은 아닙니다. ECS HDFS가 기본 파일 시스템이 아닌 경우 ECS 데이터에 액세스할 때마다 경로를 포함한 전체 URI를 사용해야 합니다. 이미 다른 기본 파일시스템을 사용 중인 기존 애플리케이션이 있다면 해당 애플리케이션을 업데이트해야합니다.

Hadoop 인증 모드Hadoop은 사용자 ID를 확인하는 데 단순 모드와 Kerberos 모드의 두 가지 작업 모드를지원합니다.

단순단순 모드에서는 클라이언트 프로세스의 ID가 호스트 운영 체제에 의해 확인됩니다. Unix와 유사한 시스템에서는 사용자 이름이 'whoami'와 동일합니다.

Kerberos

Kerberized 작업에서는 클라이언트 프로세스의 ID가 해당 Kerberos 자격 증명에의해 확인됩니다. 예를 들어, Kerberized 환경에서는 사용자가 kinit 유틸리티를 사용하여 Kerberos TGT(Ticket-Granting-Ticket)를 획득하고 klist를 사용하여 현재보안 주체를 확인할 수 있습니다. auth_to_local Hadoop 속성을 사용하여Kerberos 보안 주체를 HDFS 사용자 이름에 매핑하는 경우 기본 구성 요소를 제외한 모든 구성 요소가 삭제됩니다. 예를 들어 todd/[email protected]이라는 보안 주체는 HDFS에서 단순한 사용자 이름인 todd로 작동합니다.

ECS HDFS는 단순 인증 모드 또는 Kerberos 인증 모드를 사용하도록 구성된 Hadoop클러스터와 통합됩니다.

Hadoop 클러스터가 Kerberos를 사용하여 보호되는 경우 ECS는 [email protected] 형식의 Kerberos 보안 주체가 할당된 사용자에게 액세스 권한을 부여하도록 구성할 수 있습니다. 또한, ECS가 AD를 사용하여 사용자를 인증하는 경우에는 사용자가



[email protected] 형식의 AD 자격 증명을 사용하여 인증을 받을 수 있도록 Kerberos환경과 AD 사이에 1방향 트러스트를 구성할 수 있습니다.

파일 및 디렉토리 사용 권한은 umask(fs.permissions.umask-mode)에 의해 확인됩니다.권장되는 umask는 022입니다.

파일 시스템으로 버킷 액세스HDFS 파일 시스템 스토리지는 ECS 버킷으로 제공됩니다. 버킷을 생성할 때 이를 파일시스템으로 사용할 수 있게 설정하도록 ECS에 지시해야 합니다.

파일 시스템에 대한 액세스 권한을 부여할 때 ECS(ECS 클라이언트 라이브러리를 통해)는 Hadoop core-site.xml 파일 내 설정 및 버킷에 대해 구성된 사용 권한을 사용하여 액세스 권한을 확인합니다. Hadoop 사용자 및 서비스가 루트 파일 시스템(버킷)에서 파일 및 디렉토리를 생성할 수 있을 정도로 충분한 액세스 권한을 구성했는지 확인해야 합니다.

버킷 소유자는 루트 파일 시스템의 소유자이며, 버킷에 대해 이 소유자에 할당된 사용권한은 루트 파일 시스템에 대한 사용 권한으로 해석됩니다. 또한, HDFS 파일 시스템에 액세스해야 하는 모든 사용자가 버킷에 대한 사용 권한을 갖도록 버킷 ACL을 할당해야 합니다. 이 작업은 버킷의 개별 사용자 모두에 대해 사용자 ACL을 명시적으로 추가하거나 사용자 지정 그룹 ACL을 지정하여 수행할 수 있습니다. 버킷 사용자 지정 그룹 ACL 및 기본 그룹(141페이지) 섹션을 참조하십시오. 버킷의 소유자는 ECS 오브젝트 사용자여야 하며, 다른 사용자는 그럴 필요가 없으며 Hadoop 클러스터의 Unix 사용자 이름일 수 있습니다.

사용자가 버킷을 소유하기 때문에 파일 시스템에 대한 액세스 권한을 가지고 있거나 파일 시스템이 속하는 그룹의 구성원이기 때문에 버킷에 사용자로 추가된 경우 이러한 사용자가 생성하는 파일 및 디렉토리에는 core-site.xml에서 umask 속성으로 확인되는 사용 권한이 할당됩니다.

ECS는 HDFS에 대한 액세스를 활성화하는 데 사용할 수 있는 수퍼유저 및 수퍼그룹 메커니즘도 지원합니다.

버킷 사용자 지정 그룹 ACL 및 기본 그룹사용자 ACL을 기반으로 하거나 사용자 지정 그룹 ACL을 할당하는 방식으로 버킷에 대한 액세스를 활성화할 수 있습니다. 사용자 지정 그룹은 Hadoop 클러스터에 정의된 사용자 그룹의 이름이며, 이를 통해 Hadoop 사용자는 HDFS를 사용하여 버킷에 액세스할수 있습니다.

Hadoop 클러스터에 정의된 일반적인 그룹은 hdfs(hdfs 사용자 포함), hadoop(일반적으로 모든 서비스 사용자 포함), 사용자(Hadoop 클러스터에서 애플리케이션에 액세스하는 기타 서비스 계정이 아닌 사용자 포함)이며, ECS Portal에서 해당 그룹을 생성하고 이 그룹에 사용 권한을 할당할 수 있습니다.

또한 버킷에 대해 기본 그룹을 할당할 수도 있습니다. 기본 그룹은 루트 '/' 파일 시스템에 할당되는 그룹입니다. 예를 들어, 버킷 소유자가 hdfs이고 기본 그룹이 hadoop으로설정된 경우 '/'는 hdfs:hadoop으로 설정됩니다. 이는 각각 사용자 및 그룹에 해당합니다. 기본 그룹은 사용자 지정 그룹이기도 하므로 사용자 지정 그룹 ACL 목록에 표시됩니다.

기본 그룹이 정의되지 않은 경우 아래 표시된 것처럼 파일 시스템의 루트에 그룹이 없습니다.

drwx---rwx+ - hdfs 0 2015-12-09 12:30 /


파일 시스템으로 버킷 액세스 141

기본 그룹으로 "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 오브젝트 사용자일 필요는 없습니다. 이름은 Unix 로컬 사용자, Kerberos 사용자 또는 AD 사용자(사용되는 인증 모드에 따라 다름)와 일치해야 합니다.

hdfs 사용자나 hdfs 보안 주체가 버킷 소유자(수퍼유저)이거나 수퍼유저 그룹의 구성원이도록 하는 것이 좋습니다.

멀티 프로토콜(교차 헤드) 액세스ECS는 S3 프로토콜을 사용하여 버킷에 데이터를 쓰고 HDFS를 통해 데이터를 파일로사용할 수 있도록 하는 기능을 지원합니다.

멀티 프로토콜 액세스(교차 헤드 액세스라고도 함)는 S3 프로토콜을 사용하여 버킷에쓰여진 오브젝트가 MapReduce와 같은 Hadoop 작업의 주체가 될 수 있음을 의미합니다. 마찬가지로, HDFS에서 기록한 디렉토리 및 파일도 S3 클라이언트를 사용하여 읽고수정할 수 있습니다.

S3를 사용하여 기록된 데이터를 파일 형태로 액세스할 수 있게 하기 위해 버킷 관리자는 버킷에 대한 기본 그룹을 설정하고 이 그룹이 소유하는 파일 및 디렉토리에 대한 기본 사용 권한을 설정할 수 있습니다. HDFS가 액세스할 때 S3에서 생성된 오브젝트에소유자뿐만 아니라 Hadoop 클러스터에서 액세스할 수 있는 그룹 구성원 자격 및 사용권한도 부여될 수 있도록 이러한 오브젝트에 이 기본 Unix 그룹이 할당됩니다.

HDFS를 사용하여 생성되고 S3 프로토콜을 사용하여 액세스되는 파일에는 기본 사용권한이 적용되지 않습니다. 기본 사용 권한은 S3 프로토콜을 사용하여 생성되는 파일에만 적용됩니다.



Hadoop Kerberos 인증 모드Kerberos와 ECS Active Directory 서버가 통합될 때 Kerberos 영역은 사용자의 단일 네임스페이스를 제공하므로 kinit로 인증받은 Hadoop 사용자는 자격 증명이 있는 ECS사용자로 인식됩니다.

Kerberos 모드로 실행 중인 Hadoop 클러스터에서 ECS 사용자를 인증하려면 Kerberos영역에서 Active Directory 영역으로 진행되는 1방향 교차 영역 트러스트가 있어야 합니다.

Hadoop과 core-site.xmlECS 간의 적절한 사용자 변환을 위해 에서 다음과 같은 ID변환 속성이 사용됩니다.

l fs.permissions.umask-mode: 값을 022로 설정합니다.

l fs.viprfs.auth.anonymous_translation: 값을 CURRENT_USER로 설정합니다.

l fs.viprfs.auth.identity_translation: 값을 CURRENT_USER_REALM으로 설정합니다. 그러면 사용자 영역이 자동으로 검색됩니다.

또한 서비스 보안 주체를 정의하려면 core-site.xml에서 다음 속성을 설정해야 합니다.

l viprfs.security.principal

프록시 사용자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 인증이 수행되도록 할 수 있습니다.


Hadoop Kerberos 인증 모드 143

SymLink 지원표준 HDFS에서, 파일의 전체 URI가 지정되지 않은 심볼 링크는 동일한 HDFS 인스턴스 내의 경로를 가리킵니다.

이는 ECS HDFS에서도 마찬가지입니다. SymLink에 전체 URI를 지정하지 않으면 ECSHDFS는 현재 네임스페이스와 버킷을 루트로 사용합니다. 현재 네임스페이스 및 버킷외부의 파일에 대한 SymLink를 제공하려면 체계와 권한을 모두 포함하는 전체 URI를제공해야 합니다.

Hadoop 2.2는 SymLink를 지원하지 않습니다.

단순 클러스터에서 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 클러스터에서 액세스하는 경우에는 매핑을 할당하여 그룹 구성원자격을 직접 구성할 수 있습니다.

Active Directory 자격 증명을 사용하는 경우, AD 보안 주체와 Unix 보안 주체 간 매핑은도메인 접미사를 제거하여 이루어지므로 [email protected] 사용자는 hdfs가 됩니다. 이는 hdfs에 [email protected]과 같은 매핑을 허용하는 Kerberos 보안 주체매핑을 사용하는 경우만큼 유연하지는 않습니다.

Active Directory에 그룹을 사용하는 경우 그룹의 구성원 자격이 확인될 수 있도록 인증공급자가 ECS에 구성되어 있어야 합니다.

파일 시스템 상호 작용ECS HDFS와 직접 상호 작용하는 경우, 표준 HDFS 파일 시스템과 상호 작용할 때와 달리 다음과 같은 차이점이 나타날 수 있습니다.



l 파일 시스템이 DistributedFileSystem의 인스턴스가 되어야 하는 애플리케이션은작동하지 않습니다. 기본 제공 HDFS 구축 환경에 대해 작동하도록 하드코딩된 애플리케이션이 ECS HDFS를 사용하려면 변경이 필요합니다.

l ECS HDFS는 데이터의 체크섬을 지원하지 않습니다.

l listCorruptFileBlocks 함수를 사용할 때 모든 블록이 OK로 보고됩니다. 이는 ECSHDFS에 손상된 블록에 대한 개념이 없기 때문입니다.

l 복제 인수가 항상 상수 N(여기서는 N=1)으로 보고됩니다. 데이터는 Hadoop 복제가 아닌 ECS SLA로 보호됩니다.

지원되는 Hadoop 애플리케이션 및 지원되지 않는 Hadoop 애플리케이션

ECS HDFS는 Hadoop 환경에 속하는 대부분의 애플리케이션을 지원합니다.

지원되는 애플리케이션Hadoop 환경에서 지원되는 애플리케이션은 다음과 같습니다.

l HDFS

l MapRedeuce

l Yarn

l Pig

l Hive

l HBase

지원되지 않는 애플리케이션Hadoop 환경에서 지원되지 않는 애플리케이션은 다음과 같습니다.

l HttpFS

l Hue

l Cloudera Impala


지원되는 Hadoop 애플리케이션 및 지원되지 않는 Hadoop 애플리케이션 145

21장

HDFS 파일 시스템용 버킷 생성

l ECS Portal을 사용하여 HDFS에 사용할 버킷 생성............................................148l Hadoop 및 ECS 버킷 사용 권한 예.................................................................... 153

HDFS 파일 시스템용 버킷 생성 147

ECS Portal을 사용하여 HDFS에 사용할 버킷 생성ECS Portal을 사용하여 HDFS에 사용하도록 구성된 버킷을 생성할 수 있습니다.

시작하기 전에

l ECS Portal에서 버킷을 생성하려면 Namespace Admin 또는 System Admin이어야합니다.

l Namespace Admin인 경우 자신의 네임스페이스에 버킷을 생성할 수 있습니다.

l System Admin인 경우에는 어떤 네임스페이스에 속한 버킷이라도 생성할 수 있습니다.

Hadoop 사용자 및 서비스에 HDFS 파일 시스템(버킷)에 대한 액세스 권한이 있고 이들이 생성하는 파일 및 디렉토리를 적절한 사용자 및 그룹에서 액세스할 수 있도록 해야합니다.

다음 방법을 사용하여 이 작업을 수행할 수 있습니다.

l 버킷 소유자를 Hadoop 수퍼유저(대개 "hdfs" 또는 "[email protected]")와 동일하게 설정합니다.

l 그룹 구성원 자격을 기준으로 버킷에 대한 액세스를 활성화합니다.

n 기본 그룹을 버킷에 할당합니다. 그러면 사용자 지정 그룹 ACL이 자동으로 할당됩니다.

n 버킷 생성을 마친 후 액세스가 필요한 다른 그룹에 대해서도 사용자 지정 그룹ACL을 추가합니다.

l 버킷에 사용자 ACL을 추가하여 개별 사용자의 액세스 권한을 활성화합니다.

l HDFS에 대한 수퍼유저 액세스 권한이 필요한 Hadoop 사용자는 Hadoop 수퍼그룹에 속해 있어야 합니다.

오브젝트 프로토콜을 사용하여 버킷에 쓰여진 오브젝트 데이터를 HDFS에서 액세스할수 있게 하려면 기본 그룹이 버킷에 할당되어 있고 기본 파일 및 디렉토리 사용 권한이이 그룹에 설정되어 있어야 합니다.

파일 시스템으로 버킷 액세스(141페이지)에서 사용자 및 사용 권한에 대한 자세한 내용을 확인할 수 있으며, 일반적인 버킷 사용자 권한은 Hadoop 및 ECS 버킷 사용 권한 예(153페이지)에 나와 있습니다.

절차

1. ECS Portal에서 Manage > Buckets > New Bucket을 선택합니다.

2. 버킷의 이름을 입력합니다.

URI Java 클래스는 밑줄을 지원하지 않으므로 버킷 이름에 밑줄을 사용하면 안됩니다. 예를 들어 viprfs://my_bucket.ns.site/는 유효하지 않은 URI여서 작동하지 않기 때문에 Hadoop에서 인식하지 못합니다.

3. 버킷이 속할 네임스페이스를 지정합니다.

4. 네임스페이스에 사용할 복제 그룹을 선택합니다. 기본 복제 그룹을 사용하려면빈 상태로 둡니다.

5. 버킷 소유자의 이름을 입력합니다.

HDFS 버킷의 경우 버킷 소유자는 일반적으로 "hdfs"이고, Kerberos 버킷의 경우에는 "[email protected]"입니다. Hadoop hdfs 사용자는 HDFS에 대한 수퍼유



저 권한이 있어야 하고, 이 권한은 hdfs를 버킷 소유자로 지정함으로써 부여할 수있습니다. 기타 Hadoop 사용자도 수퍼유저 권한이 필요할 수 있으며, 이러한 권한은 사용자를 그룹에 할당하고 그룹을 수퍼유저 그룹으로 지정하는 방식으로부여할 수 있습니다.

6. CAS를 활성화하지 마십시오.

HDFS로 사용하도록 생성된 버킷을 CAS에 사용할 수는 없습니다. 파일 시스템이 활성화된 경우 CAS 컨트롤이 비활성화됩니다.

7. 필요한 다른 모든 버킷 기능을 활성화합니다.

HDFS 버킷에 대해 다음과 같은 기능을 활성화할 수 있습니다.

l 할당량

l 서버 측 암호화

l 메타데이터 검색

l 운영 중단 중 액세스

l 규정 준수(참고 참조)

l 버킷 보존

이러한 각각의 설정과 이를 구성하는 방법에 대한 자세한 내용은 관리자 가이드:버킷 생성 및 관리 에서 확인할 수 있습니다.

규정 준수가 설정된 버킷에는 HDFS 프로토콜을 사용하여 데이터를 쓸 수 없습니다. 하지만 오브젝트 프로토콜을 사용하여 쓴 데이터는 HDFS에서 읽을 수 있습니다.

8. File System을 Enabled로 설정합니다.

파일 시스템이 활성화되면 파일 시스템/버킷의 기본 그룹을 설정하는 컨트롤과버킷에 생성된 파일 및 디렉토리의 사용 권한을 그룹에 할당하는 컨트롤을 사용할 수 있습니다.

9. 아래에 나와 있는 File System 패널에서 Default Bucket Group의 이름을 입력합니다.


ECS Portal을 사용하여 HDFS에 사용할 버킷 생성 149



이 그룹이 HDFS 루트 파일 시스템에 연결되는 그룹이고, 이 그룹을 통해 그룹의구성원인 Hadoop 사용자가 HDFS에 액세스할 수 있습니다.

이 그룹은 HDFS의 데이터에 액세스해야 하는 서비스가 속하는 그룹(예: "hdfs"또는 "hadoop")일 수 있지만, Hadoop 구성에 적합하기만 하다면 어떠한 그룹 이름이든 가능합니다. 예를 들어, 관리자가 버킷에 업로드된 모든 S3 파일이'S3DataUsers'라는 그룹에 할당되도록 할 수도 있습니다. 이 경우 모든 S3 파일에 이 그룹이 할당됩니다. Hadoop 노드에서 Hadoop 관리자는 'S3DataUsers' 그룹에 속하는 사용자를 가지게 됩니다. S3DataUsers는 Linux 그룹이거나 ActiveDirectory 그룹일 수 있습니다. Hadoop 사용자가 S3 데이터에 액세스하려는 경우 S3 파일이 해당 그룹에 업로드되고 할당되었기 때문에 액세스가 가능합니다.

이 그룹은 버킷 생성 시 지정해야 합니다. 그렇지 않은 경우, 파일 시스템 소유자가 Hadoop에서 나중에 이 그룹을 할당해야 합니다.

10. 오브젝트 프로토콜을 사용하여 버킷에 생성되는 파일 및 디렉토리의 기본 사용권한을 설정합니다.

이러한 설정은 오브젝트 프로토콜을 사용하여 생성되는 오브젝트에 Unix 그룹사용 권한을 적용하는 데 사용됩니다. 이들 사용 권한은 오브젝트나 디렉토리가Hadoop에 나열된 경우 HDFS 그룹(기본 버킷 그룹)에 적용됩니다. 파일 시스템에 대한 기본 그룹 및 사용 권한을 설정하는 방법에 대한 자세한 내용은 멀티 프로토콜(교차 헤드) 액세스(142페이지)에서 확인할 수 있습니다.

a. 적절한 사용 권한 버튼을 클릭하여 Group File Permissions를 설정합니다.

일반적으로 읽기 및 실행 권한을 설정합니다.

b. 적절한 사용 권한 버튼을 클릭하여 Group Directory Permissions를 설정합니다.

일반적으로 읽기 및 실행 권한을 설정합니다.

11. Save를 클릭하여 버킷을 생성합니다.

사용자 지정 그룹 버킷 ACL 설정ECS Portal을 통해 버킷에 대한 그룹 ACL을 설정할 수 있습니다. 버킷 ACL은 사용자그룹(사용자 지정 그룹 ACL)에 부여되거나 개별 사용자 또는 이 둘 모두에 부여될 수있습니다. 예를 들어 사용자 그룹에 전체 버킷 액세스 권한을 부여할 수 있지만, 해당그룹에 속한 개별 사용자로 버킷 액세스를 제한(또는 거부)할 수도 있습니다.



시작하기 전에

l Namespace Admin 또는 System Admin이어야 버킷의 그룹 ACL을 편집할 수 있습니다.

l Namespace Admin 사용자는 자신의 네임스페이스에 속한 버킷의 그룹 ACL 설정을편집할 수 있습니다.

l System Admin 사용자는 어떤 네임스페이스에 속한 버킷이라도 그룹 ACL 설정을편집할 수 있습니다.

HDFS를 사용하여 버킷에 액세스하는 경우 Unix 그룹 구성원은 ECS 멀티 프로토콜 액세스를 사용하여 버킷에 액세스할 수 있습니다.

절차

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

2. Buckets 테이블에서 설정을 변경하려는 버킷에서 Edit ACL 작업을 선택합니다.

3. 사용자 지정 그룹의 ACL을 설정하려면 Custom Group User ACLs를 선택합니다.

4. Custom Group User ACLs 페이지에서 Add를 선택합니다.

5. 그룹의 이름을 입력합니다.

이 이름은 Unix/Linux 그룹이거나 Active Directory 그룹일 수 있습니다.

6. 그룹에 대한 사용 권한을 설정합니다.

최소한 Read, Write, Execute, Read ACL을 할당해야 합니다.


사용자 지정 그룹 버킷 ACL 설정 151


사용자에 대한 버킷 ACL 권한 설정ECS Portal을 통해 사용자에 대해 버킷의 ACL을 설정할 수 있습니다. 버킷 소유자에는사용 권한이 자동으로 할당됩니다. 기타 Hadoop 사용자에는 사용자 ACL이 할당될 수있습니다. 이 ACL을 통해 버킷/파일 시스템에 대한 액세스가 허용됩니다. 또한, 사용자지정 그룹 ACL이 할당된 그룹의 구성원이 됨으로써 버킷에 대한 액세스 권한을 부여받을 수도 있습니다.

시작하기 전에

l ECS Namespace Admin 또는 System Admin이어야 버킷의 ACL을 편집할 수 있습니다.

l Namespace Admin 사용자는 자신의 네임스페이스에 속한 버킷의 ACL 설정을 편집할 수 있습니다.

l System Admin 사용자는 어떤 네임스페이스에 속한 버킷이라도 ACL 설정을 편집할수 있습니다.

절차

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

2. Buckets 테이블에서 설정을 변경하려는 버킷에서 Edit ACL 작업을 선택합니다.

3. 사용자의 ACL 권한을 설정하려면 User ACLs 버튼을 선택합니다.

4. 이미 권한이 할당된 사용자의 권한을 편집하거나 권한을 할당하려는 사용자를추가할 수 있습니다.

l 이미 권한이 있는 사용자에 대한 ACL 권한을 설정하거나 제거하려면 ACL 테이블의 Action 열에서 Edit(또는 Remove)를 선택합니다.

l 권한을 할당하려는 사용자를 추가하려면 Add를 선택합니다.

버킷 소유자로 설정한 사용자는 이미 할당된 기본 권한을 가지고 있을 것입니다.

아래에 표시된 버킷은 "hdfs" 사용자가 소유하며, 소유자로서 이 사용자에게 전체 제어 권한이 부여되었습니다. Hadoop/Unix 환경에서 전체 제어 권한은 읽기-쓰기-실행 권한을 의미합니다. "sally" 사용자에게는 이 사용자가 버킷에 액세스할 수 있도록 허용하는 읽기-실행 권한이 부여되었습니다.

ACL 권한에 대한 추가 정보는 관리자 가이드: 버킷 생성 및 관리 에 제공됩니다.




5. ACL을 추가했으면 권한이 적용될 사용자의 사용자 이름을 입력합니다.

6. 사용자에게 적용할 권한을 지정합니다.


Hadoop 및 ECS 버킷 사용 권한 예Hadoop 사용자 및 그룹과 ECS 사용자 ACL 및 사용자 지정 그룹 ACL을 통해 버킷에 액세스할 수 있도록 사용자 및 그룹에 할당되는 사용 권한 사이의 관계에 대한 예가 나와있습니다.

버킷 생성 시 설정되는 버킷 소유자와 기본 그룹에 따라 HDFS를 사용하여 액세스할 때버킷에 할당된 소유자 및 그룹이 확인되고, ACL은 이 소유자와 그룹에 자동으로 할당됩니다. 버킷에는 항상 소유자가 있어야 하지만, 기본 그룹은 버킷에 할당되지 않아도됩니다. 버킷 소유자 및 기본 그룹과 별개인 다른 사용자 및 그룹(사용자 지정 그룹이라고 함)에 버킷에 대한 ACL을 할당할 수 있으며, 이렇게 할당된 ACL은 Hadoop 사용자에 대한 사용 권한으로 해석됩니다.

표 16 단순 모드에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예

Hadoop 사용자 및 그룹 버킷 사용 권한 버킷/파일 시스템 액세스

그룹 ACL을 사용한 버킷 액세스

사용자(서비스)

hdfs. mapred, yarn, hive, pig

사용자(애플리케이션)

sally, fred

그룹

hdfs(hdfs)

hadoop(hdfs, mapred,yarn, hive, pig)

사용자(sally, fred)

수퍼그룹hdfs

버킷 소유자입니다

hdfs

기본 그룹

사용자 지정 그룹ACL

hadoop, 사용자

사용자 ACL

hdfs(소유자)

버킷에 설정된 사용자 지정 그룹ACL을 통해 hadoop 및 사용자 그룹은 버킷/루트 파일 시스템에 대한 사용 권한을 가질 수 있습니다.

이 예에서는 hdfs가 수퍼유저, 즉namenode를 시작한 사용자라고가정합니다.

s3 사용자가 생성하는 버킷 - 교차 헤드 액세스


hdfs. mapred, yarn, hive, pig


sally, fred

그룹

hdfs(hdfs)

hadoop(hdfs, mapred,yarn, hive, pig)

사용자(sally, fred)


s3user

기본 그룹hadoop


hadoop(기본값)

s3 사용자가 쓰는 오브젝트가HDFS에서 파일로 액세스될 수 있도록 하려는 경우 Hadoop 사용자및 서비스에 그룹 구성원 자격을기반으로 파일에 대한 사용 권한이부여되도록 기본 그룹(hadoop)이정의되어 있어야 합니다.

기본 그룹에는 자동으로 버킷/파일 시스템에 대한 사용자 지정 그룹 ACL이 할당됩니다. 기본 그룹


Hadoop 및 ECS 버킷 사용 권한 예 153

표 16 단순 모드에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예 (계속)

Hadoop 사용자 및 그룹 버킷 사용 권한 버킷/파일 시스템 액세스

수퍼그룹hdfs

사용자 ACL

s3user(소유자),sally, fred

이 설정된 경우 루트 파일 시스템에는 777이 할당됩니다.

drwxrwxrwx+ - s3userhadoop 0 2015-12-0912:28 /

사용자에게는 사용자 ACL을 추가하거나 사용자가 속한 그룹에 대한사용자 지정 그룹 ACL을 추가하여액세스 권한을 부여할 수 있습니다.

표 17 Kerberos 모드에서 파일 시스템 액세스에 대한 버킷 사용 권한의 예

Hadoop 사용자 버킷 사용 권한 버킷/파일 시스템 액세스


[email protected]@REALM.COM,[email protected],[email protected],[email protected]


[email protected], [email protected], [email protected]

그룹

hdfs([email protected] )hadoop([email protected] OM,[email protected], [email protected], [email protected], [email protected])사용자([email protected], [email protected])

수퍼그룹hdfs


[email protected]

기본 그룹hadoop


hadoop(기본),사용자

사용자 ACL

[email protected](소유자)

버킷에 설정된 사용자 지정 그룹ACL을 통해 hadoop 및 사용자 그룹은 버킷/루트 파일 시스템에 대한 사용 권한을 가질 수 있습니다.

Hadoop 클러스터의 사용자 정보는 ECS가 버킷에 대한 보안 액세스를 제공할 수 있도록 ECS에서사용할 수 있어야 합니다. 이 메타데이터에 대한 정보는 Hadoop 및ECS 버킷 사용 권한 예(153페이지)에 나와 있으며, 예제 메타데이터 파일은 여기에 나와 있습니다.



22장

Hortonworks Ambari를 사용하여 ECS HDFS에Hadoop 설정

l Ambari를 사용하여 Hortonworks 클러스터 구축...............................................156l Ambari 다운로드...............................................................................................156l ECS HDFS Client Library 다운로드...................................................................156l ECS 클라이언트 라이브러리를 구축하는 데 소스로 사용할 로컬 저장소 설정.. 156l Ambari 서버 설치.............................................................................................. 157l Ambari Hadoop ECS 스택 활성화......................................................................157l 수동으로 Ambari 에이전트 설치........................................................................158l Hadoop 설치 .................................................................................................... 159

Hortonworks Ambari를 사용하여 ECS HDFS에 Hadoop 설정 155

Ambari를 사용하여 Hortonworks 클러스터 구축Ambari는 Hortonworks Hadoop 클러스터를 손쉽게 구축할 수 있도록 지원하고 스택이라는 개념을 활용하여 특정 Hadoop 릴리즈에 필요한 서비스를 통합합니다.Hortonworks 2.3(Hadoop 2.7)은 ECS를 위한 사용자 지정 Hadoop 스택을 제공합니다.이는 ECS와 Hadoop의 통합을 간소화합니다. 이외 Hortonworks 릴리즈에서는 정상 모드로 Ambari를 사용할 수 있습니다.

HDP ECS(Hortonworks Hadoop ECS) 스택은 ECS 클라이언트 라이브러리를 모든Hadoop 노드에 구축하고 ECS HDFS를 사용하도록 클러스터를 구성하는 작업을 간소화하여 ECS HDFS와 Hadoop을 손쉽게 통합할 수 있도록 지원합니다.

Hortonworks HDP ECS 스택을 구축하고 구성하려면 다음 단계를 수행하십시오.

1. Ambari 다운로드

2. ECS HDFS Client Library 다운로드

3. ECS 클라이언트 라이브러리를 구축하는 데 소스로 사용할 로컬 저장소 설정

4. Ambari 서버 설치

5. Ambari ECS 스택 활성화

6. 수동으로 Ambari 에이전트 설치

7. Hadoop 클러스터 설치

Ambari 다운로드Ambari 2.2를 다운로드합니다.

Ambari를 사용하여 HDP(Hadoop) 배포판을 설치하고 관리할 수 있습니다. Ambari 2.2는 Hortonworks Hadoop ECS 스택을 설치할 수 있는 기능을 제공합니다.

다음 링크에서 Ambari 저장소를 다운로드할 수 있습니다.

http://hortonworks.com/hdp/downloads/

Ambari 서버가 서버 노드에 설치되고 Ambari 에이전트가 모든 노드에 설치될 수 있도록 하려면 클러스터에 포함된 모든 노드에 Ambari 저장소를 다운로드해야 합니다.

ECS HDFS Client Library 다운로드ECS Support Zone에서 ECS HDFS Client Library RPM을 다운로드합니다.

http://support.emc.com

ECS 클라이언트 라이브러리를 구축하는 데 소스로 사용할 로컬저장소 설정

Ambari가 Hadoop 스택을 사용하여 ECS 클라이언트 라이브러리를 구축하는 데 소스로사용할 로컬 저장소를 설정합니다.

시작하기 전에

Hortonworks Ambari를 사용하여 ECS HDFS에 Hadoop 설정


저장소를 설정하는 작업에는 일반적으로 Package Manager를 사용하여 저장소 디렉토리에 포함되는 패키지에 대한 메타데이터 세트를 생성하고 HTTP나 네트워크를 통해서와 같이 저장소 디렉토리에 액세스하기 위한 메커니즘을 제공하는 작업이 포함됩니다.

저장소를 생성하는 데 사용할 수 있는 툴은 여러 가지가 있습니다. yum을 사용하여 패키지 저장소를 생성하는 방법에 대한 정보는 여기에 나와 있습니다.

절차

1. 로컬 저장소를 생성합니다.

2. ECS 클라이언트 라이브러리 RPM을 로컬 저장소에 추가합니다.

Ambari 서버 설치Ambari 서버를 설치합니다.

이 절차에는 Ambari 서버를 설치하고 설정하기 위한 기본 명령이 나와 있습니다. 자세한 내용은 Hortonworks 설명서(여기)에서 확인할 수 있습니다.

절차

1. 다음 명령을 사용하여 Ambari 서버를 설치합니다.

yum install ambari-server -y

2. 다음과 같이 Ambari 서버를 설정합니다.

ambari-server setup -s

3. 다음과 같이 Ambari 서버를 시작합니다.

ambari-server start

Ambari Hadoop ECS 스택 활성화HDP(Hortonworks Hadoop) ECS 스택은 기본적으로 비활성화되어 있으므로 구축하도록 선택할 수 있으려면 이를 활성화해야 합니다. 스택은 명령줄에서 활성화할 수 있습니다.

절차

1. Ambari 서버 시스템에서 명령 프롬프트를 엽니다.

2. 다음 명령을 실행합니다.

ambari-server enable-stack --stack HDP --version 2.3.ECS


Ambari 서버 설치 157

http://yum.baseurl.org/wiki/RepoCreate

http://docs.hortonworks.com/HDPDocuments/Ambari-2.1.2.1/bk_Installing_HDP_AMB/content/ch_Installing_Ambari.html

둘 이상의 스택을 활성화하려면 각각의 추가 스택에 --version 옵션을 포함하면 됩니다. 예:

ambari-server enable-stack --stack HDP --version 2.3.ECS --version <stack_name>

수동으로 Ambari 에이전트 설치이 절차에는 각 노드에서 수동으로 Ambari 에이전트를 설치하는 단계가 나와 있습니다.

시작하기 전에

l 노드에 에이전트를 설치하려면 각 클러스터 노드에 Ambari 저장소가 있어야 합니다.

절차

1. Ambari 슬레이브 호스트 중 하나에서 명령 프롬프트를 엽니다.

2. 다음 명령을 사용하여 Ambari 에이전트를 설치합니다.

yum install ambari-agent -y

3. Ambari 서버 노드의 호스트 이름을 가져옵니다.

hostname 명령을 사용하여 이를 수행할 수 있습니다.

4. ambari-agent.ini 파일을 편집하여 Ambari 서버의 호스트 이름을 지정합니다.

예를 들어 vi를 사용하여 다음을 입력할 수 있습니다.

vi /etc/ambari-agent/conf/ambari-agent.ini

서버 호스트 이름은 아래에 표시된 것처럼 [server] 매개 변수에 있으며,"localhost"를 Ambari 서버의 호스트 이름으로 바꿔야 합니다.

[server]hostname=localhosturl_port=8440secure_url_port=8441

5. Ambari 에이전트를 시작합니다.

ambari-agent start

6. 각 Ambari 슬레이브 노드마다 이 단계를 반복합니다. Hadoop 클러스터에서 데이터 노드로 Ambari 서버 노드를 사용하려는 경우 해당 시스템에도 에이전트를 설치해야 합니다.



Hadoop 설치Hadoop 클러스터를 설치합니다.

절차

1. Ambari 마법사의 안내에 따라 Hadoop 클러스터를 설치합니다.

다음에 나오는 단계는 주요 ECS 통합 기능을 나타냅니다.

단계에 대한 요구 사항과 관련한 명확한 설명이 필요한 경우 Hortonworks 설명서를 참조하십시오.

2. 구축할 스택을 선택하라는 메시지가 표시되면 HDP ECS 스택을 선택합니다.

예를 들어, 아래와 같이 HDP 2.3.ECS를 선택합니다.

3. ECS 클라이언트 라이브러리 RPM이 저장된 저장소를 지정합니다.

사용하는 운영 체제에 맞게 http://ECS_CLIENT_REPO/를 ECS 클라이언트라이브러리 RPM이 저장된 저장소의 위치로 바꿉니다.


Hadoop 설치 159

4. Haddop 클러스터의 호스트 목록을 입력하고, Host Registration Information에서Perform Manual Registration을 선택합니다.

SSH 키를 생성하고 이를 모든 노드에 배포한 경우 이 메커니즘을 사용하여Ambari 에이전트를 모든 노드에 구축할 수 있습니다. 여기서는 수동으로 구축했기 때문에 이 작업을 수행할 필요가 없습니다.

5. Hadoop Hive 및 Hbase 서비스 작업을 사용자 지정하는 속성을 제공합니다.



a. Hive의 경우, metastore 데이터베이스를 제공해야 합니다.

새 데이터베이스(새 MySQL 데이터베이스)를 생성하도록 Ambari에 지시할수 있습니다. 이 경우 새 데이터베이스에 대한 암호를 제공해야 합니다. 또는,기존 데이터베이스를 사용하도록 Ambari에 지시할 수 있습니다.

b. Hbase의 경우, hbase.rootdir이 ECS 버킷(HDFS 파일 시스템)을 가리켜야 합니다.

예:

viprfs://mybucket.mynamespace.Site1/apps/hbase/data

6. Hadoop HDFS/ECS 서비스 작업을 사용자 지정하는 속성을 제공합니다.

Hortonworks Hadoop ECS 스택 사용자 지정 작업에서 ECS 관련 core-site 속성이 이미 추가되었습니다. 이러한 속성 중 일부는 고정된 값이므로 수정할 필요가전혀 없습니다. 일부 속성은 Hadoop 단순 모드 환경에 적절한 기본값으로 설정되어 있으므로, Kerberos 보안을 사용하도록 환경을 설정하는 경우에만 변경해야 합니다.

일부 매개 변수는 클라스터와 관련된 것이므로 제공해야 합니다.

ECS/HDFS core-site 구성 속성 중 누락된 속성을 입력합니다.

a. 기본 파일 시스템 속성 fs.defaultFS에 대한 값을 입력합니다.

이는 다음과 같습니다.

viprfs://<bucket>.<namespace>.<installation>

예:

viprfs://mybucket.mynamespace.Site1


Hadoop 설치 161

b. fs.vipr.installation.<site>.hosts(기본적으로 fs.vipr.installation.Site1.hosts) 속성에 ECS 노드 주소를 입력합니다.

이는 쉼표로 구분된 IP 주소 목록일 수 있습니다. 예를 들어 다음과 같습니다.

203.0.113.10,203.0.113.11,203.0.113.12

이 속성에 대한 자세한 내용은 Hadoop core-site.xml 파일 편집(167페이지)에서확인할 수 있습니다. 여기에는 단순 Hadoop 클러스터에 대한 속성 설정에 대한설명이 나와 있습니다.

결과

Hadoop ECS 클러스터용 Ambari 인터페이스가 설치되고 나면 HDFS 서비스가 ECS로표시되도록 맞춤 구성됩니다. 또한, 일반적으로 추가되어야 하는 ECS 관련 core-site.xml 속성이 이미 제공되어 있고 대부분의 매개 변수에 기본값이 설정되어 있습니다.이렇게 맞춤 구성된 인터페이스는 아래에 나와 있습니다.



23장

단순 Hadoop 클러스터와 ECS HDFS 통합 구성

l 단순 Hadoop 클러스터와 ECS HDFS 통합 구성................................................ 164l ECS HDFS 및 Hadoop 통합 계획...................................................................... 164l ECS HDFS 설치 및 지원 패키지 가져오기........................................................ 165l ECS HDFS Client Library 구축.......................................................................... 165l Hadoop core-site.xml 파일 편집........................................................................167l HBASE hbase-site.xml 편집.............................................................................. 170l 재시작 후 액세스 확인....................................................................................... 171

단순 Hadoop 클러스터와 ECS HDFS 통합 구성 163

단순 Hadoop 클러스터와 ECS HDFS 통합 구성이 절차에서는 ECS HDFS에서 ECS 스토리지 인프라스트럭처를 사용하도록 기존Hadoop 배포판을 설정하는 방법에 대해 설명합니다.

Hortonworks Ambari 배포판을 사용하는 경우 Ambari를 사용하여 Hortonworks 클러스터 구축(156페이지)에 설명되어 있는 절차를 사용하여 Hadoop을 설치하고 구성할 수있습니다.

이 통합 절차를 수행하려면 다음이 필요합니다.

l Hadoop 배포판 및 관련 툴에 대한 최신 지식

l Hadoop 노드에 로그인해서 Hadoop 시스템 파일을 수정하고 Hadoop 서비스를 시작 및 중지하는 데 사용할 수 있는 Hadoop 자격 증명

다음 단계를 수행해야 합니다.

1. ECS HDFS 및 Hadoop 통합 계획(164페이지)

2. ECS HDFS 설치 및 지원 패키지 가져오기(165페이지)

3. ECS HDFS Client Library 구축(165페이지)(Ambari Hortoworks for ECS를 사용하는 경우에는 수행할 필요 없음)

4. Hadoop core-site.xml 파일 편집(167페이지)

5. HBASE hbase-site.xml 편집(170페이지)

6. 재시작 후 액세스 확인(171페이지)

ECS HDFS 및 Hadoop 통합 계획성공적인 통합을 위해 아래의 목록을 이용해 필요한 정보를 가지고 있는지 확인합니다.

표 18 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 지원 페이지에서 다운로드할 수 있습니다.

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 설치 및 지원 패키지 가져오기(165페이지)의 설명에 따라 EMC의 ECS 지원사이트에서 Hadoop 배포판용 ECS HDFS Client Library를 가져옵니다.

HDFS Client Library는 다음과 같은 명명 규칙 viprfs-client-<ECS version>-hadoop-<Hadoop version>.jar을 사용하며 각 릴리즈에 사용할 수 있는 JAR은아래 표에 나와 있습니다.

표 19 ECS HDFS Client Library

Hadoop 배포

버전 ECS HDFS JAR

Hortonworks HWX 2.0 viprfs-client-<ECS version>-hadoop-2.2.jar

HWX 2.1 viprfs-client-<ECS version>-hadoop-2.3.jar(Hadoop 2.5 - 2.4 클라이언트 사용 안 함)

HWX 2.2 viprfs-client-<ECS version>-hadoop-2.6.jar

HWX 2.3 viprfs-client-<ECS version>-hadoop-2.7.jar

l 최신 버전의 ECS로 업그레이드하는 경우 업그레이드한 릴리즈에 대해 ECS HDFSClient Library를 구축해야 합니다.

l Hortonworks 2.3(Hadoop 2.7)의 경우, Ambari를 사용하여 ECS 클라이언트 라이브러리에서 미리 구성된 HDP 릴리즈를 설치할 수 있습니다.


ECS HDFS 설치 및 지원 패키지 가져오기 165

절차

1. ECS 클라이언트 노드에 로그인합니다.

2. 클래스 경로 명령을 실행하여 클래스 경로에 포함된 디렉토리 목록을 가져옵니다.

# hadoop classpath3. classpath 명령으로 나열된 폴더 중에서 /conf 폴더 다음에 나오는 폴더 하나에

ECS HDFS Client Library JAR을 복사합니다.

예를 들어, classpath 명령 출력은 일반적으로 다음과 같이 표시됩니다.

/usr/hdp/2.2.0.0-1256/hadoop/conf:/usr/hdp/2.2.0.0-1256/hadoop/lib/*:/usr/hdp/2.2.0.0-1256/hadoop/.//*:/usr/hdp/2.2.0.0-1256/hadoop-hdfs/./:/usr/hdp/2.2.0.0-1256/hadoop-hdfs/lib/*:/

/conf 폴더가 먼저 나열됩니다. 클라이언트 라이브러리 JAR은 일반적으로 아래 표에 나와 있는 것처럼 첫 번째 /lib 폴더에 추가하는 것이 좋습니다.

ECS 배포 클래스 경로 위치(권장)

Hortonworks /usr/hdp/<version>/hadoop/lib

4. 각 ECS 클라이언트 노드에서 위 절차를 반복합니다.

5. MapReduce 및 yarn에 대한 클래스 경로 구성 설정을 업데이트하고 Tez에 대해서는 JAR 경로를 명시적으로 지정합니다.

이러한 구성 설정의 예는 아래에 나와 있습니다.

mapreduce.application.classpath$PWD/mr-framework/hadoop/share/hadoop/mapreduce/*:$PWD/mr-framework/hadoop/share/hadoop/mapreduce/lib/*:$PWD/mr-framework/hadoop/share/hadoop/common/*:$PWD/mr-framework/hadoop/share/hadoop/common/lib/*:$PWD/mr-framework/hadoop/share/hadoop/yarn/*:$PWD/mr-framework/hadoop/share/hadoop/yarn/lib/*:$PWD/mr-framework/hadoop/share/hadoop/hdfs/*:$PWD/mr-framework/hadoop/share/hadoop/hdfs/lib/*:$PWD/mr-framework/hadoop/share/hadoop/tools/lib/*:/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar:/etc/hadoop/conf/secure:/usr/hdp/2.3.2.0-2950/hadoop/lib/*

yarn.application.classpath$HADOOP_CONF_DIR,/usr/hdp/current/hadoop-client/*,/usr/hdp/current/hadoop-client/lib/*,/usr/hdp/current/hadoop-hdfs-client/*,/usr/hdp/current/hadoop-hdfs-client/lib/*,/usr/hdp/current/hadoop-yarn-client/*,/usr/hdp/current/hadoop-yarn-client/lib/*,/usr/hdp/2.3.2.0-2950/hadoop/lib/*

tez.cluster.additional.classpath.prefix/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar:/etc/hadoop/conf/secure:/usr/hdp/2.3.2.0-2950/hadoop/lib/viprfs-client-2.2.0.0-hadoop-2.7.jar



Hadoop core-site.xml 파일 편집이 절차를 사용해 ECS HDFS와 단순 인증 모드를 사용하는 Hadoop 클러스터를 통합하는 데 필요한 속성으로 core-site.xml을 업데이트합니다.

시작하기 전에

l 오류가 발생할 가능성을 줄이고 수행한 변경 내용이 클러스터 전체에 유지되도록항상 Hadoop 관리 UI를 사용하여 이러한 속성을 추가/관리하는 것이 좋습니다. 여러 Hadoop 노드에서 파일을 수동으로 편집하는 작업은 번거로우며 오류가 발생하기 쉽습니다. 배포판의 관리 UI에 로그인하는 데 필요한 사용자 자격 증명이 있어야합니다.

l core-site.xml을 직접 수정하는 경우 Hadoop 노드에 로그인하고 core-site.xml을 수정하는 데 필요한 사용자 자격 증명이 있어야 합니다.

일부 속성은 ECS와 관련된 것이므로 대개 core-site.xml에 추가해야 합니다.Hortonworks Ambari Hadoop ECS 스택을 사용하는 경우에는 ECS 관련 매개 변수가 이미 있습니다.

core-site.xml을 직접 편집하려는 경우 core-site.xml의 위치는 다음 표에 나와있는 것처럼 사용하는 배포판에 따라 다릅니다.

표 20 core-site.xml 위치

Hadoop 배포 core-site.xml 위치 업데이트할 노드

Hortonworks /etc/hadoop/conf 모든 노드

core-site.xml은 Hadoop 클러스터의 각 노드에 있습니다. 각 인스턴스에서 동일한속성을 수정해야 합니다. 하나의 노드에서 속성을 변경한 후 scp(secure copy) 명령을사용하여 클러스터의 다른 노드에 파일을 복사할 수 있습니다.

설정해야 할 각 속성에 대한 자세한 내용은 core_site.xml 속성 참조를 참조하십시오.

절차

1. Ambari와 같은 관리 인터페이스를 사용하는 경우 관리자로 로그인하고 HDFS 구성 페이지로 이동합니다.

2. core-site.xml을 수동으로 편집하여 변경을 수행하려는 경우 다음 단계를 따릅니다.

a. core-site.xml이 위치한 HDFS 노드 중 하나에 로그인합니다.

b. core-site.xml의 백업본을 만듭니다.

cp core-site.xml core-site.backupc. 원하는 텍스트 편집기를 사용하여 편집할 core-site.xml을 엽니다.

3. 다음 속성과 값을 추가해 ECS HDFS 파일 시스템을 구축하는 Java 클래스를 정의합니다.

<property><name>fs.viprfs.impl</name>


Hadoop core-site.xml 파일 편집 167

<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>

4. fs.vipr.installations 속성을 추가합니다. 다음 예에서는 값이 Site1로 설정되었습니다.

<property> <name>fs.vipr.installations</name> <value>Site1</value></property>

5. 쉼표로 구분된 ECS 데이터 노드 목록 또는 로드 밸런싱 장치 IP 주소 목록으로fs.vipr.installation.[installation_name].hosts 속성을 추가합니다. 다음 예에서는installation_name이 Site1로 설정되었습니다.

<property> <name>fs.vipr.installation.Site1.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value></property>

6. fs.vipr.installation.[installation_name].resolution 속성을 추가하고 다음 값 중 하나로 설정합니다.

옵션 설명

dynamic 로드 밸런싱 장치 없이 ECS 데이터 노드에 직접 액세스할 때 사용합니다.

fixed 로드 밸런싱 장치를 통해 ECS 데이터 노드에 액세스할 때 사용합니다.

다음 예에서는 installation_name이 Site1로 설정되었습니다.

<property> <name>fs.vipr.installation.Site1.resolution</name> <value>dynamic</value></property>

a. fs.vipr.installation.[installation_name].resolution을 dynamic으로 설정한 경우, fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms 속성을 추가해 ECS에 활성 노드 목록을 얼마나 자주 쿼리할 것인지 지정합니다.


<property><name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live_ms</name><value>900000</value></property>

7. fs.defaultFS 속성을 찾아 ECS 파일 시스템 URI를 지정하도록 값을 수정합니다.



이 설정은 선택 사항이며, ECS ViPRFS에 연결할 전체 파일 시스템 URL을 지정할 수 있습니다.

다음 형식을 사용합니다. viprfs://<bucket_name.namespace.installation_name. 구문 설명:

l bucket_name: Hadoop 작업을 실행할 때 사용할 데이터가 포함되어 있는 버킷의 이름입니다. 단순 인증 모드로 실행 중일 경우 버킷 소유자가 모두에게사용 권한을 부여해야 합니다. 다음 예에서는 bucket_name이 mybucket으로설정되었습니다.

l namespace: bucket_name이 있는 테넌트 네임스페이스입니다. 다음 예에서는 namespace가 mynamespace로 설정되었습니다.

l installation_name: fs.vipr.installations 속성에 의해 지정된 값입니다. 다음 예에서는 installation_name이 Site1로 설정되었습니다.

<property> <name>fs.defaultFS</name> <value>viprfs://mybucket.mynamespace.Site1/</value></property>

8. fs.permissions.umask-mode를 찾아 값을 022로 설정합니다.

일부 구성에서는 이 속성이 없을 수도 있습니다. 속성이 없다면 추가합니다.

<property> <name>fs.permissions.umask-mode</name> <value>022</value></property>

9. fs.viprfs.auth.anonymous_translation 속성을 추가합니다. 이 속성은 HDFS를 사용하여 생성되는 파일 또는 디렉토리의 소유자 및 그룹을 지정하는 데 사용됩니다.

ECS 2.2 이전 버전에서 이 매개 변수는 소유자 없이 생성된 파일 및 디렉토리(익명으로 소유된 파일)에 소유자를 할당하여 현재 사용자가 이러한 파일을 수정할수 있는 권한을 갖도록 하는 데 사용되었습니다. 파일 및 디렉토리는 더 이상 익명으로 생성되지 않으며 이 매개 변수 설정에 따라 소유자가 할당됩니다.

옵션 설명

LOCAL_USER 단순 보안을 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. Hadoop 클러스터의 Unix 사용자 및 그룹을 새로 생성된 파일 및 디렉토리에 할당합니다.

CURRENT_USER Kerberized Hadoop 클러스터에 이 설정을 사용합니다.Kerberos 보안 주체([email protected])를 파일 또는 디렉토리 소유자로 할당하고 버킷에 대한 기본 그룹으로 할당된그룹을 사용합니다.

NONE(기본값) (더 이상 사용되지 않음) 앞에서 언급했듯이 익명으로 소유된 오브젝트를 현재 사용자에 매핑하는 작업은 수행되지 않습니다.

<property> <name>fs.viprfs.auth.anonymous_translation</name>


Hadoop core-site.xml 파일 편집 169

<value>LOCAL_USER</value></property>

10. fs.viprfs.auth.identity_translation 속성을 추가합니다. 이 속성은 Kerberos가 없을 때 사용자를 영역에 지정하는 방법을 제공합니다.

옵션 설명

CURRENT_USER_REALM Kerberized Hadoop 클러스터에 이 설정을 사용합니다. 이 설정을 지정하면 영역이 자동으로 검색됩니다.

NONE(기본값) 단순 보안을 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. 이 설정을 사용하면 ECS HDFS에서 영역 변환을 수행하지 않습니다.

FIXED_REALM (더 이상 사용되지 않음) fs.viprfs.auth.realm 속성을 사용하여 사용자 영역을 하드 코딩할 수 있는기능을 제공합니다.

<property> <name>fs.viprfs.auth.identity_translation</name> <value>NONE</value></property>

11. core-site.xml을 저장합니다.

12. Hadoop 클러스터의 필요한 노드에서 core-site.xml을 업데이트합니다.

13. Hortonworks Ambari를 사용하여 동일한 속성 및 값으로 core-site.xml을 업데이트합니다.

HBASE hbase-site.xml 편집ECS HDFS가 포함된 HBASE를 사용할 때 hbase-site.xml의 hbase.rootdir을core-site.xml fs.defaultFS 속성과 동일한 값으로 설정해야 합니다.

hbase-site.xml은 다음 위치 중 하나에 있습니다.

표 21 hbase-site.xml 위치

Hadoop 배포 hbase-site.xml 위치

Hortonworks /etc/hbase/conf/

절차

1. hbase-site.xml을 엽니다.

2. /hbase를 접미사로 추가하는 fs.defaultFS와 동일한 값으로 hbase.rootdir 속성을 설정합니다.

3. 변경 내용을 저장합니다.

4. 배포 환경의 서비스를 재시작합니다.



Hadoop 배포 설명

Hortonworks# bin/start-hbase.sh

예제 1 hbase.rootdir 항목

<property> <name>hbase.rootdir</name> <value>viprfs://testbucket.s3.testsite/hbase</value></property>

재시작 후 액세스 확인구성 단계를 수행하고 나면 Hadoop 서비스를 재시작하고 HDFS에 대한 액세스가 가능한지 확인할 수 있습니다.

시스템이 ECS HDFS를 사용하도록 구성된 경우 HDFS NameNode가 시작되지 않을 수있습니다. ECS HDFS가 HDFS로 구성된 경우 ECS HDFS가 모든 NameNode 기능을 수행하므로 NameNode를 가동할 필요가 없습니다.

절차

1. Hadoop 서비스를 재시작합니다.

이 서비스에는 일반적으로 HDFS, MapReduce, Yarn 및 HBase가 포함됩니다.

서비스를 수동으로 재시작하는 경우 아래 표를 참조할 수 있습니다.

Hadoop 배포 Commands

Hortonworks # stop-all.sh# start-all.sh

2. 디렉토리 목록을 가져오는 다음 명령을 실행하여 구성을 테스트합니다.

# hdfs dfs -ls viprfs://mybucket.mynamespace.Site1/

13/12/13 22:20:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS for viprfs://mybucket.mynamespace.Site1/

fs.defaultFS를 설정한 경우 다음 명령을 사용할 수 있습니다.# hdfs dfs -ls /


재시작 후 액세스 확인 171

24장

보안(Kerberized) Hadoop 클러스터와 ECSHDFS 통합 구성

l ECS HDFS와 보안 Hadoop 클러스터 통합 ....................................................... 174l 단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획............................174l 그룹 이름 매핑.................................................................................................. 174l ECS 서비스 주체를 사용하여 ECS 노드 구성.................................................... 175l 메타데이터를 사용하여 ECS 버킷 보안 유지.....................................................179l core-site.xml 편집.............................................................................................183l 재시작 후 액세스 확인...................................................................................... 186

보안(Kerberized) Hadoop 클러스터와 ECS HDFS 통합 구성 173

ECS HDFS와 보안 Hadoop 클러스터 통합이 절차에서는 Kerberos를 사용하여 보안이 유지되는 기존 Hadoop 배포판을 ECSHDFS와 통합하는 방법에 대해 설명합니다.

단순 인증에 대해 구성된 Hadoop 클러스터에서 작동하도록 ECS HDFS를 구성한 후Kerberos 인증을 사용하도록 Hadoop 클러스터를 마이그레이션한 경우에도 이 절차를사용할 수 있습니다.

통합 단계를 수행하기 전에 다음을 수행하십시오.

l Kerberos KDC가 설치되어 있고 Hadoop 서비스 보안 주체의 인증을 처리하도록 구성되어 있는지 확인합니다. Active Directory를 사용하여 ECS 사용자를 인증하고있다면, Kerberos 영역과 ECS 사용자 영역 사이의 상호 영역 신뢰를 설정해야 합니다. Kerberos KDC 설정 및 신뢰 구성과 관련된 도움말은 Kerberos 구성에 대한 지침(190페이지)에 제공됩니다.

l HDFS 파일 시스템에 사용할 버킷을 생성했는지 확인합니다(ECS Portal을 사용하여 HDFS에 사용할 버킷 생성(148페이지) 참조).

l 통합 계획과 관련된 지침을 읽었는지 확인합니다(ECS HDFS 및 Hadoop 통합 계획(164페이지) 참조).

l 설치 및 지원 패키지를 다운로드했는지 확인합니다(ECS HDFS 설치 및 지원 패키지 가져오기(165페이지) 참조).

ECS HDFS를 보안 Hadoop 클러스터와 통합하려면 다음 작업을 완료합니다.

1. 단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획(174페이지)

2. 그룹 이름 매핑(174페이지)

3. ECS 서비스 주체를 사용하여 ECS 노드 구성(175페이지)

4. 메타데이터를 사용하여 ECS 버킷 보안 유지(179페이지)

5. 재시작 후 액세스 확인(186페이지)

단순 클러스터에서 Kerberos 클러스터로 마이그레이션 계획ECS는 단순 보안을 사용하는 Hadoop 클러스터에서 Kerberos로 보안이 유지되는Hadoop 클러스터로의 마이그레이션을 지원합니다.

단순 환경에서 보안 환경으로 마이그레이션하려면 마이그레이션 관련 섹션(단순 클러스터에서 Kerberos Hadoop 클러스터로 마이그레이션(144페이지))을 참조하십시오.

일반적으로, ECS 마이그레이션 기능은 Kerberos 사용자가 작동 중단 없이 원활하게 파일 및 디렉토리에 액세스할 수 있도록 지원합니다. 하지만 다음 참고 사항이 적용됩니다.

l Hadoop 클러스터를 Kerberos로 마이그레이션하고 클러스터를 다시 시작하면MapReduce 같은 프로세스가 이전에 생성한 디렉토리에 액세스하지 못하게 됩니다. Hadoop을 재시작하기 전에 이 절차를 사용하여 ECS HDFS를 구성할 때까지 기다려야 합니다.

l 사용자 및 프로세스가 버킷에 액세스할 수 있으려면 버킷에 대한 액세스 권한이 있는 그룹의 구성원이거나, Kerberos 사용자가 액세스 권한을 가지도록 버킷 ACL을변경해야 합니다.

그룹 이름 매핑

보안(Kerberized) Hadoop 클러스터와 ECS HDFS 통합 구성


ECS는 hdfs, hive 등과 같은 Hadoop 서비스 보안 주체에 대한 그룹 세부 정보를 매핑할수 있어야 합니다. Active Directory를 사용 중인 경우, 버킷 메타데이터 또는 ActiveDirectory라는 2개의 소스에서 그룹 정보를 찾을 수 있습니다. ECS는[hdfs.fs.request] 섹션에 있는 /opt/storageos/conf/hdfssvc.conf 구성파일의 구성 매개 변수 설정에서 사용할 소스를 결정합니다.

ECS에서 그룹 정보(있는 경우)를 찾을 때 Active Directory보다 버킷 메타데이터를 우선적으로 사용하도록 하려면 매개 변수를 다음과 같이 정의합니다.

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = true

ECS에서 버킷 메타데이터보다 Active Directory의 그룹 정보를 우선적으로 결정하도록하려면 매개 변수를 다음과 같이 정의합니다.

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = false

기본값은 true이며 이 값이 정의되지 않은 경우, ECS는 버킷 메타데이터에서 Kerberos보안 주체에 대한 그룹 세부 정보를 결정합니다. 변경할 경우 dataheadsvc를 다시 시작해야 합니다.

ECS 서비스 주체를 사용하여 ECS 노드 구성ECS 서비스 주체 및 해당 keytab 파일은 각 ECS 데이터 노드에 있어야 합니다. 제공된Ansible Playbook을 사용하여 이러한 단계를 자동화합니다.

시작하기 전에

이 절차를 완료하려면 다음 항목들이 있어야 합니다.

l Ansible Playbook에 액세스합니다. ECS HDFS 설치 및 지원 패키지 가져오기(165페이지)에 설명된 대로 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 컨테이너를 사용하여 실행됩니다.

절차

1. ECS 노드 1에 로그인한 후 해당 노드에 hdfsclient-<ECS version>-<version>.zip을 복사합니다.


ECS 서비스 주체를 사용하여 ECS 노드 구성 175

예:

/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입니다.


export ANSIBLE_HOST_KEY_CHECKING=False


ECS 서비스 주체를 사용하여 ECS 노드 구성 177

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입니다.

메타데이터를 사용하여 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": "internal.kerberos.user.hdfs.name", "value": "hdfs-cluster999@EXAMPLE_HDFS.EMC.COM"},{ "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs"},{


메타데이터를 사용하여 ECS 버킷 보안 유지 179

"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,hbase 등) 중 하나를 의미합니다.

아래 예에서 hive 애플리케이션에 대한 프록시 지원 기능은 s3users 그룹(AD 또는Linux 그룹)의 구성원인 사용자에게 부여되고, Hadoop 클러스터의 모든 호스트에서



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 파일의 예는 보안 버킷 메타데이터(212페이지)에 나와 있습니다.

보안 및 비보안 버킷메타데이터가 버킷에 로드된 경우 이를 "보안 버킷"이라고 하고 이 버킷에 액세스하려면 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 명령을 실행하여 제공할 수 있습니다.


Management REST API를 사용하여 ECS에 메타데이터 값 로드 181

시작하기 전에

이때 ECS System Admin 자격 증명이 있어야 합니다.

Hadoop 관리자가 ECS 관리자가 아닌 경우 보안 메타데이터를 버킷에 로드하기 위해서는 ECS System Admin과 협력해야 합니다.

Hadoop 관리자는 ECS System Admin이 사용할 수 있는 JSON 메타데이터 파일을 생성할 수 있습니다. 그러면 ECS System Admin이 다음 절차를 사용하여 메타데이터를 로드할 수 있습니다. 동일한 사용자가 이 두 가지 역할을 모두 수행하는 경우 이 사용자가JSON 메타데이터 파일을 생성하는 작업과 이를 ECS 버킷에 로드하는 작업을 모두 수행해야 합니다.

절차

1. 메타데이터를 사용하여 ECS 버킷 보안 유지(179페이지)에 설명되어 있는 메타데이터를 포함하는 JSON 파일을 생성합니다.

2. ECS 관리 명령을 실행할 때 사용할 수 있는 인증 토큰을 획득하기 위해 SystemAdmin 자격 증명을 사용하여 ECS에 로그인합니다.

curl을 사용하여 이 명령을 실행할 수 있습니다. 아래 예에서는<username>:<password>를 ECS System Admin 자격 증명으로 바꾸고 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. ECS Management REST API 명령을 실행하여 메타데이터를 구축합니다.

이때 실행하는 API 명령은 PUT object/bucket/<bucketname>/metadata입니다.curl을 사용하여 이 명령을 실행하는 예는 아래에 나와 있습니다.

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 Admin 사용자 이름의 암호로 바꿉니다.

l <bucketname>: HDFS 데이터에 대해 사용하는 버킷 이름으로 바꿉니다.

l <hostname>: ECS 노드의 IP 주소 또는 호스트 이름으로 바꿉니다.

l <bucketdetails>: 이름-값 쌍을 포함하는 JSON 파일의 파일 이름으로 바꿉니다.

l <namespace>: 버킷이 상주하는 네임스페이스의 이름으로 바꿉니다.

구축이 완료되고 나면 모든 ECS 노드에서 메타데이터를 사용할 수 있습니다.



core-site.xml 편집Kerberos 인증 모드를 사용하는 ECS 클러스터와 함께 ECS HDFS를 사용할 때 필요한속성으로 core-site.xml을 업데이트하려는 경우 이 절차를 사용합니다.

시작하기 전에

l 오류가 발생할 가능성을 줄이고 수행한 변경 내용이 클러스터 전체에 유지되도록항상 Hadoop 관리 UI를 사용하여 이러한 속성을 추가/관리하는 것이 좋습니다. 여러 Hadoop 노드에서 파일을 수동으로 편집하는 작업은 번거로우며 오류가 발생하기 쉽습니다. 배포판의 관리 UI에 로그인하는 데 필요한 사용자 자격 증명이 있어야합니다.

l core-site.xml을 직접 수정하는 경우 Hadoop 노드에 로그인하고 core-site.xml을 수정하는 데 필요한 사용자 자격 증명이 있어야 합니다.

일부 속성은 ECS와 관련된 것이므로 대개 core-site.xml에 추가해야 합니다.Hortonworks Ambari Hadoop ECS 스택을 사용하는 경우에는 ECS 관련 매개 변수가 이미 있습니다.

core-site.xml을 직접 편집하려는 경우 core-site.xml의 위치는 다음 표에 나와있는 것처럼 사용하는 배포판에 따라 다릅니다.

표 22 core-site.xml 파일의 위치

ECS 배포 core-site.xml 위치 업데이트할 노드

Hortonworks /etc/hadoop/conf 모든 노드

core-site.xml은 Hadoop 클러스터의 각 노드에 있으며 각 인스턴스에서 동일한 속성을 수정해야 합니다. 하나의 노드에서 속성을 변경한 후 scp(secure copy) 명령을 사용하여 클러스터의 다른 노드에 파일을 복사할 수 있습니다. Best Practice로, 구성 절차를 시작하기 전에 core-site.xml을 백업합니다.

설정해야 할 각 속성에 대한 자세한 내용은 core_site.xml 속성 참조를 참조하십시오.

절차

1. Hortonworks Ambari와 같은 관리 인터페이스를 사용하는 경우 관리자로 로그인하고 HDFS 구성 페이지로 이동합니다.

2. core-site.xml을 수동으로 편집하여 변경을 수행하려는 경우 다음 단계를 따릅니다.

a. core-site.xml이 위치한 HDFS 노드 중 하나에 로그인합니다.

b. core-site.xml의 백업본을 만듭니다.

cp core-site.xml core-site.backupc. 원하는 텍스트 편집기를 사용하여 편집할 core-site.xml을 엽니다.

3. 다음 속성과 값을 추가해 ECS HDFS 파일 시스템을 구축하는 Java 클래스를 정의합니다.

<property><name>fs.viprfs.impl</name>


core-site.xml 편집 183

<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>

4. fs.vipr.installations 속성을 추가합니다. 다음 예에서는 값이 Site1로 설정되었습니다.


5. 쉼표로 구분된 ECS 데이터 노드 목록 또는 로드 밸런싱 장치 IP 주소 목록으로fs.vipr.installation.[installation_name].hosts 속성을 추가합니다. 다음 예에서는installation_name이 Site1로 설정되었습니다.


6. fs.vipr.installation.[installation_name].resolution 속성을 추가하고 다음 값 중 하나로 설정합니다.

옵션 설명

dynamic 로드 밸런싱 장치 없이 ECS 데이터 노드에 직접 액세스할 때 사용합니다.

fixed 로드 밸런싱 장치를 통해 ECS 데이터 노드에 액세스할 때 사용합니다.



a. fs.vipr.installation.[installation_name].resolution을 dynamic으로 설정한 경우, fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms 속성을 추가해 ECS에 활성 노드 목록을 얼마나 자주 쿼리할 것인지 지정합니다.


<property><name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live_ms</name><value>900000</value></property>

7. fs.defaultFS 속성을 찾아 ECS 파일 시스템 URI를 지정하도록 값을 수정합니다.



이 설정은 선택 사항이며, ECS ViPRFS에 연결할 전체 파일 시스템 URL을 지정할 수 있습니다.

다음 형식을 사용합니다. viprfs://<bucket_name.namespace.installation_name. 구문 설명:

l bucket_name: Hadoop 작업을 실행할 때 사용할 데이터가 포함되어 있는 버킷의 이름입니다. 단순 인증 모드로 실행 중일 경우 버킷 소유자가 모두에게사용 권한을 부여해야 합니다. 다음 예에서는 bucket_name이 mybucket으로설정되었습니다.

l namespace: bucket_name이 있는 테넌트 네임스페이스입니다. 다음 예에서는 namespace가 mynamespace로 설정되었습니다.

l installation_name: fs.vipr.installations 속성에 의해 지정된 값입니다. 다음 예에서는 installation_name이 Site1로 설정되었습니다.


8. fs.permissions.umask-mode를 찾아 값을 022로 설정합니다.

일부 구성에서는 이 속성이 없을 수도 있습니다. 속성이 없다면 추가합니다.

<property> <name>fs.permissions.umask-mode</name> <value>022</value></property>

9. fs.viprfs.auth.anonymous_translation 속성을 추가합니다. 이 속성은 HDFS를 사용하여 생성되는 파일 또는 디렉토리의 소유자 및 그룹을 지정하는 데 사용됩니다.

ECS 2.2 이전 버전에서 이 매개 변수는 소유자 없이 생성된 파일 및 디렉토리(익명으로 소유된 파일)에 소유자를 할당하여 현재 사용자가 이러한 파일을 수정할수 있는 권한을 갖도록 하는 데 사용되었습니다. 파일 및 디렉토리는 더 이상 익명으로 생성되지 않으며 이 매개 변수 설정에 따라 소유자가 할당됩니다.

옵션 설명

LOCAL_USER 단순 보안을 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. Hadoop 클러스터의 Unix 사용자 및 그룹을 새로 생성된 파일 및 디렉토리에 할당합니다.

CURRENT_USER Kerberized Hadoop 클러스터에 이 설정을 사용합니다.Kerberos 보안 주체([email protected])를 파일 또는 디렉토리 소유자로 할당하고 버킷에 대한 기본 그룹으로 할당된그룹을 사용합니다.

NONE(기본값) (더 이상 사용되지 않음) 앞에서 언급했듯이 익명으로 소유된 오브젝트를 현재 사용자에 매핑하는 작업은 수행되지 않습니다.

<property> <name>fs.viprfs.auth.anonymous_translation</name>


core-site.xml 편집 185

<value>LOCAL_USER</value></property>

10. fs.viprfs.auth.identity_translation 속성을 추가한 후 CURRENT_USER_REALM으로 설정합니다. 이 값은 kinit를 통해 사용자가 로그인한 영역으로 매핑됩니다.

<property> <name>fs.viprfs.auth.identity_translation</name> <value>CURRENT_USER_REALM</value></property>

11. viprfs.security.principal 속성을 추가합니다. 이 속성은 KDC에 ECS 사용자가 누구인지 알려 줍니다.

보안 주체 이름에는 실행 시 실제 데이터 노드 FQDN으로 자동으로 바뀌는"_HOST"가 포함될 수 있습니다.

<property> <name>viprfs.security.principal</name> <value>vipr/[email protected]</value></property>

12. Kerberos 티켓이 캐싱된 위치를 추가합니다.

예:

<property><name>hadoop.security.kerberos.ticket.cache.path</name> <value>/tmp/<krbcc_1000</value></property>

이 값은 klist 명령 출력에서 얻을 수 있습니다.

13. Hortonworks Ambari를 사용하여 동일한 속성 및 값으로 core-site.xml을 업데이트합니다.

재시작 후 액세스 확인구성 단계를 수행하고 나면 Hadoop 서비스를 재시작하고 HDFS에 대한 액세스가 가능한지 확인할 수 있습니다.

시스템이 ECS HDFS를 사용하도록 구성된 경우 HDFS NameNode가 시작되지 않을 수있습니다. ECS HDFS가 HDFS로 구성된 경우 ECS HDFS가 모든 NameNode 기능을 수행하므로 NameNode를 가동할 필요가 없습니다.

절차

1. Hadoop 서비스를 재시작합니다.

이 서비스에는 일반적으로 HDFS, MapReduce, Yarn 및 HBase가 포함됩니다.

서비스를 수동으로 재시작하는 경우 아래 표를 참조할 수 있습니다.


Hortonworks # stop-all.sh




# start-all.sh

2. 디렉토리 목록을 가져오는 다음 명령을 실행하여 구성을 테스트합니다.

# kinit <service principal>

# hdfs dfs -ls viprfs://mybucket.mynamespace.Site1/

13/12/13 22:20:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS for viprfs://mybucket.mynamespace.Site1/


재시작 후 액세스 확인 187

25장

Kerberos 구성에 대한 지침

l Kerberos 구성에 대한 지침............................................................................... 190l ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성............ 193

Kerberos 구성에 대한 지침 189

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 사용자 인증 구성 191

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

ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성

ECS 구성에 하나 이상의 새 노드를 추가하는 경우 ECS 서비스 보안 주체와 해당keytab이 새 노드에 구축되어야 합니다.

시작하기 전에

l 이 절차에서는 여기에 나와 있는 단계를 이전에 수행했으며 Ansible Playbook이 설치되어 액세스 가능하다고 가정합니다.

이 절차를 완료하려면 다음 항목들이 있어야 합니다.

l ECS 노드 IP 주소의 목록입니다.

l KDC의 IP 주소입니다.

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를 가져옵니다.


ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성 193

예:

admin@provo-lilac:~> sudo docker images

출력에 다음과 같은 이미지 ID가 표시됩니다.

REPOSITORY TAG IMAGEID CREATED VIRTUAL SIZEutilities 1.5.0.0-403.cb6738e186bd8577a7a 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입니다.


ECS 서비스 보안 주체를 사용하여 하나 이상의 새로운 ECS 노드 구성 195

26장

문제 해결

l 문제 해결.......................................................................................................... 198l AD/LDAP가 보안 Hadoop 클러스터로 올바로 구성되어 있는지 확인................198l hbase 구성 후 서비스 재시작............................................................................ 199l Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음.................................... 199l AD 사용자에 대해 거부되는 권한......................................................................199l 사용 권한 오류..................................................................................................199l 요청 처리 실패................................................................................................. 203l Kerberos 클라이언트 측 로깅 및 디버깅 활성화............................................... 203l KDC 상의 Kerberos 디버그...............................................................................204l 시간 차이 제거................................................................................................. 204

문제 해결 197

문제 해결이 영역에서는 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 서버에 직접적인 문제가 있을 가능성이 높습니다.

문제 해결


hbase 구성 후 서비스 재시작hbase-site.xml의 hbase.rootdir 속성을 편집한 후 hbase 서비스가 올바로 재시작되지않습니다.

해결 방법Hortonworks에서 이 문제가 발생할 때 다음 단계를 수행하여 hbase-master를 실행해야 합니다.

1. zookeeper cli에 연결합니다.

hbase zkcli

2. hbase 디렉토리를 제거합니다.

rmr /hbase

3. hbase 서비스를 재시작합니다.

Pig 테스트 실패: Kerberos 보안 주체를 가져올 수 없음Pig 테스트에 실패하고 다음 오류가 발생합니다. "Info:Error: java.io.IOException:Unable to obtain the Kerberos principal"(AD 사용자로 kinit 후에도) 또는 "Unable toopen iterator for alias firstten".

문제의 원인은 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

사용 권한 오류사용 권한이 충분하지 않음 오류는 여러 가지 원인으로 발생할 수 있습니다. hadoop fs명령을 실행할 때 이 오류가 나타나거나 mapreduce 또는 hive에 대한 로그와 같은 애플리케이션 로그에서 이 오류를 확인할 수도 있습니다.

INSUFFICIENT_PERMISSIONS 오류

문제 해결

hbase 구성 후 서비스 재시작 199

아래 예에서는 "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-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

이것은 오류가 아닙니다. 이 메시지는 서버가 요청을 생성하는 보안 주체 사용자에 대해 캐싱된 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임)

문제 해결

사용 권한 오류 201

l 경로(/mr-history/done)

추가 디버깅을 위한 두 가지 접근 방식이 있습니다.

l Blobsvc 로그 디버깅(202페이지)

l Hadoop 클라이언트 디버깅(202페이지)

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

다음은 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인데 다른 설정이'-'(0)인 것입니다. 요청을 생성하는 사용자는 jhs@REALM이고 이 사용자는 hdfs가 아니라 hadoop의 구성원입니다. 따라서 이 사용자에게는 /mr-history/done 디렉토리를

문제 해결


나열할 수 있는 오브젝트 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"

문제 해결

요청 처리 실패 203

KDC 상의 Kerberos 디버그더 쉽게 디버그하려면 HDFS 작업을 수행할 때 KDC의 /var/log/krb5kdc.log 파일에 대해 tail 명령을 사용합니다.

tail -f /var/log/krb5kdc.log

시간 차이 제거Kerberos는 정확한 시간에 의존하는 기술이므로, 클라이언트와 서버 간에 시간이 동기화되어 있는지 확인하는 것이 중요합니다.

AD와 데이터 노드/KDC 간에 시간 차이가 있을 경우, NTP 서버를 올바로 구성해야 합니다. 다음과 같이 하면 됩니다.

1. Remote Desktop을 사용하여 AD 서버에 연결합니다.


a. w32tm /config /syncfromflags:manual /manualpeerlist:<ntp-server1>,<ntp-server2>

b. net stop w32time

c. net start w32time

문제 해결


27장

ECS HDFS의 Hadoop core-site.xml 속성

l ECS HDFS의 Hadoop core-site.xml 속성......................................................... 206

ECS HDFS의 Hadoop core-site.xml 속성 205

ECS HDFS의 Hadoop core-site.xml 속성Hadoopcore-site.xml 파일을 구성할 때 아래 표의 속성 및 관련 값을 참조로 사용하십시오.

표 23 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.[installation_name].hosts 속성에 의해 이름이 더욱 세부적으로 정의됩니다. 이름은 ECS HFDS 파일시스템 URI의 권한 섹션의 구성 요소로 사용됩니다. 예:

<property> <name>fs.vipr.installations</name> <value><site1>,<abc>,<testsite></value> </property>

fs.vipr.installation.[installation_name].hosts

fs.vipr.installations 속성에 나열된 각 이름에 대한 ECS 클러스터의 데이터 노드 또는 로드 밸런싱 장치의 IP 주소. 쉼표로 구분된 IP 주소 목록의 형태로 값을 지정합니다. 예:

<property> <name>fs.vipr.installation.<site1>.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value> </property>

<property> <name>fs.vipr.installation.<abc>.hosts</name> <value>198.51.100.0,198.51.100.1,198.51.100.2</value> </property>

<property> <name>fs.vipr.installation.<testsite>.hosts</name> <value>198.51.100.10,198.51.100.11,198.51.100.12</value>



표 23 Hadoop core-site.xml 속성 (계속)

속성 설명

</property>

fs.vipr.installation.[installation_name].resolution

ECS HDFS 소프트웨어가 ECS 데이터 노드에 액세스하는 방법을 어떻게 인식하는지 지정합니다. 값은 다음과 같습니다.

l dynamic: 로드 밸런싱 장치 없이 직접 ECS 데이터 노드에 액세스할 때 이 값을 사용합니다.

l fixed: 로드 밸런싱 장치를 통해 ECS 데이터 노드에 액세스할 때 이 값을 사용합니다.

<property> <name>fs.vipr.installation.testsite.resolution</name> <value>dynamic</value> </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.<testsite>.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].[installation_name]

l bucket_name: Hadoop 작업을 실행할 때 사용할 데이터가 포함되어 있는 HDFS 지원 버킷의 이름입니다.

l namespace: HDFS 지원 버킷과 연결된 테넌트 네임스페이스입니다.

l installation_name: Hadoop이 ECS 데이터에 액세스하는 데 사용할 수 있는 ECS 데이터 노드 세트와 연결된 이름입니다. 이 속성의 값은 fs.vipr.installations 속성에 지정된 값 중 하나와 일치해야합니다.

예:

<property> <name>fs.defaultFS</name> <value>viprfs://testbucket.s3.testsite</value> </property>


ECS HDFS의 Hadoop core-site.xml 속성 207


속성 설명

HBase를 사용하려면 기본 파일 시스템이 정의되어 있어야 합니다.

UMASK 속성

fs.permissions.umask-mode

이 표준 Hadoop 속성은 ECS HDFS가 오브젝트에 대한 권한을 계산하는 방식을 지정합니다. 권한은입력 권한에 umask를 적용하는 방식으로 계산됩니다. 단순 및 Kerberos 구성 모두에 권장되는 값은022입니다. 예:

<property><name>fs.permissions.umask-mode</name><value>022</value></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

이 속성은 새로 생성된 파일에 사용자 및 그룹이 할당되는 방법을 결정하는 데 사용됩니다.




속성 설명

이전에는 이 속성이 소유자가 없는 파일에 발생한 작업을 확인하는 데 사용되었습니다. 이러한 파일을 "익명"이 소유한다고 했습니다. 파일 및 디렉토리는 더 이상 익명으로 소유되지 않습니다.

값은 다음과 같습니다.

l LOCAL_USER: 단순 보안을 사용하는 Hadoop 클러스터에 이 설정을 사용합니다. Hadoop 클러스터의 Unix 사용자 및 그룹을 새로 생성된 파일 및 디렉토리에 할당합니다.

l CURRENT_USER: Kerberized 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 속성 예입니다.

예제 2 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>


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

예제 2 core-site.xml (계속)

<value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value></property>




<property> <name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live_ms</name> <value>900000</value></property>


<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>CURRENT_USER</value></property>

<property> <name>fs.viprfs.auth.identity_translation</name> <value>FIXED_REALM</value></property>

<property> <name>fs.viprfs.auth.realm</name> <value>MY.TEST.REALM</value></property>



28장

보안 버킷 메타데이터 예

l 보안 버킷 메타데이터....................................................................................... 212

보안 버킷 메타데이터 예 211

보안 버킷 메타데이터이에 대한 목록은 다음과 같습니다.

{ "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.amshbase.name", "value": "amshbase@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.amshbase.shortname", "value": "ams" }, { "name": "internal.kerberos.user.amshbase.groups", "value": "hadoop" }, { "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.hbase.name", "value": "hbase@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hbase.shortname", "value": "hbase" }, {



"name": "internal.kerberos.user.hbase.groups", "value": "hadoop" }, { "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.oozie.name", "value": "oozie@EXAMPLE_HDFS.EMC.COM" }, {


보안 버킷 메타데이터 213

"name": "internal.kerberos.user.oozie.shortname", "value": "oozie" }, { "name": "internal.kerberos.user.oozie.groups", "value": "hadoop,users" }, { "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" }, { "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.hbase.hosts", "value": "*" }, { "name": "hadoop.proxyuser.hbase.users", "value": "cmaurer" }, { "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" } ]}


보안 버킷 메타데이터 215