elastic cloud storage (ecs) · 2020-04-10 · elastic cloud storage (ecs) 3.0 버전 계획...

Elastic Cloud Storage (ECS)3.0 버전

계획 가이드302-003-219

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 계획 가이드

5

7

ECS란 무엇인가? 9개요............................................................................................................ 10ECS 플랫폼................................................................................................. 10

포털 서비스....................................................................................10스토리지 서비스 ............................................................................ 11프로비저닝 서비스..........................................................................11Fabric 서비스.................................................................................. 11인프라스트럭처 서비스...................................................................11

ECS 어플라이언스...................................................................................... 12네트워크 인터페이스......................................................................13

스토리지 리소스 용량 할당......................................................................... 13VDC(Virtual Data Center).............................................................. 13스토리지 풀.................................................................................... 13복제 그룹....................................................................................... 13네임스페이스................................................................................. 14Buckets.......................................................................................... 14사용자 및 역할............................................................................... 14

모니터링, 진단 및 ViPR SRM...................................................................... 14

새로운 기능 17ECS 3.0의 새로운 기능............................................................................... 18

V4 인증을 위해 S3 프로토콜 지원.................................................. 18버전 지정 오브젝트의 수명주기에 대한 S3 프로토콜 지원............. 18S3 프로토콜 메타데이터 검색 기능 향상........................................ 18DLO(Dynamic Large Object) 및 SLO(Static Large Object)에 대한Openstack Swift 프로토콜 지원..................................................... 18ECS에서의 SNMP 트랩 전송 지원..................................................18원격 Syslog 서버 지원.................................................................... 19부분 가비지 수집을 통해 공간 재확보............................................ 19플랫폼 잠금................................................................................... 20대시보드 및 모니터링 향상............................................................20CAS 고급 보존 관리.......................................................................20규정 준수 네임스페이스에서 오브젝트 레벨 보존 없이 작성된 오브젝트의 기본 보존 기간에 대한 CAS 동작 변경................................ 21ECS 인증을 받은 타사 스토리지 하드웨어에서 ECS 3.0 및 ECS 소프트웨어만 설치된 ECS Appliance에 대해 ECS 규정 준수 인증......... 21Atmos 지원 향상............................................................................ 21CIFS-ECS 지원.............................................................................. 22ECS SW.........................................................................................22

데이터 보호 23데이터 보호 개요........................................................................................ 24스토리지 서비스......................................................................................... 24

그림

표

1장

2장

3장

목차

Elastic Cloud Storage (ECS) 3.0 계획 가이드 3

오브젝트 생성.............................................................................................24오브젝트 읽기.............................................................................................28삭제 코딩....................................................................................................28디스크 및 노드 장애 시 복구.......................................................................30새 노드를 추가한 후 데이터 재조정............................................................ 30사이트 페일오버 및 복구............................................................................. 31

ECS 설치 계획 33ECS 설치 계획............................................................................................34설치 장소 준비............................................................................................34ECS 설치 준비 체크리스트......................................................................... 34단일 사이트에서 ECS Appliance 연결 ........................................................ 34멀티 사이트 요구 사항................................................................................ 36네트워크 분리.............................................................................................36

VIP를 사용한 네트워크 분리 계획.................................................. 38VLAN을 사용한 네트워크 분리 계획.............................................. 39

로드 밸런싱 고려 사항................................................................................ 42용량 고려 사항............................................................................................42

스토리지 풀 용량........................................................................... 42가비지 수집................................................................................... 42

4장

목차


ECS 플랫폼 서비스..................................................................................................... 10단일 사이트: 오브젝트 생성........................................................................................252개 사이트: 오브젝트 생성......................................................................................... 26오브젝트 생성: 연합 VDC(3개 이상 사이트) ...............................................................27선형 또는 데이지 체인 토폴로지.................................................................................35선형 또는 데이지 체인 스플릿 브레인.........................................................................35Ring 토폴로지.............................................................................................................35Star 토폴로지............................................................................................................. 36

12345678

그림


그림


U-Series 구성 요소......................................................................................................12C-Series 구성 요소...................................................................................................... 12여러 사이트를 구축할 때의 스토리지 오버헤드.......................................................... 29단일 사이트의 노드 장애 허용.................................................................................... 29일반 아카이브와 콜드 아카이브의 요구 사항 비교...................................................... 29

12345

표


표


1장

ECS란 무엇인가?

l 개요.................................................................................................................... 10l ECS 플랫폼.........................................................................................................10l ECS 어플라이언스.............................................................................................. 12l 스토리지 리소스 용량 할당................................................................................. 13l 모니터링, 진단 및 ViPR SRM.............................................................................. 14

ECS란 무엇인가? 9

개요ECS는 상용 하드웨어에서 대규모로 비정형 데이터를 저장, 조작 및 분석하는 기능을지원하는 완벽한 소프트웨어 정의 클라우드 스토리지 플랫폼입니다. ECS는 모바일, 클라우드, 빅데이터 및 소셜 네트워킹 애플리케이션을 지원하도록 특별히 설계되었습니다. 턴키 스토리지 어플라이언스 또는 정규화된 상용 서버 및 디스크 집합에 설치할 수있는 소프트웨어 제품으로 구축할 수 있습니다.

지리적으로 분산된 아키텍처인 ECS 스케일 아웃은 다음과 같은 이점을 제공하는 클라우드 플랫폼입니다.

l 퍼블릭 클라우드보다 낮은 비용

l 스토리지 효율성과 데이터 액세스의 뛰어난 조합

l 강력한 정합성 보장 기능을 통해 위치에 구애받지 않는 읽기/쓰기 액세스를 제공하여 애플리케이션 개발 간소화

l 완벽한 이중화로 가용성과 성능 향상

l 범용 액세스 기능을 통해 스토리지 사일로 및 비효율적인 ETL/데이터 이동 프로세스 제거

l ViPR SRM 지원. ViPR SRM은 ECS용 보고 솔루션을 제공하는 멀티벤더 스토리지리소스 보고 소프트웨어입니다.

ECS 플랫폼ECS 플랫폼에는 다음 소프트웨어 계층과 서비스가 포함됩니다.

그림 1 ECS 플랫폼 서비스

포털 서비스포털 서비스에는 스토리지 리소스의 프로비저닝, 관리 및 모니터링을 위한 인터페이스가 포함됩니다. 인터페이스는 다음과 같습니다.

l GUI: ECS Portal이라는 기본 제공 브라우저 기반 그래픽 사용자 인터페이스

l REST: 자체 ECS Portal 개발에 사용할 수 있는 RESTful API



l CLI: 브라우저 기반 인터페이스와 같은 작업을 수행하기 위해 사용하는 명령줄 인터페이스

스토리지 서비스스토리지 서비스는 데이터 손상, 하드웨어 장애 및 데이터 센터 재해 시 데이터 가용성및 보호를 보장하는 USE(Unstructured Storage Engine)에서 제공됩니다. 이 서비스를통해 지리적으로 분산되어 있는 데이터 센터 전반의 글로벌 네임스페이스 관리와 원거리 복제를 지원합니다. USE는 다음 스토리지 서비스를 지원합니다.

l 오브젝트 서비스: 비정형 데이터의 저장, 액세스 및 조작 기능을 제공합니다. 오브젝트 서비스는 기존의 Amazon S3, OpenStack Swift API, EMC CAS 및 EMCAtmos API와 호환 가능합니다.

l HDFS: 포털 스토리지 인프라스트럭처를 (같은 자리에서) Hadoop 분석 애플리케이션을 실행할 수 있는 빅데이터 저장소로 사용할 수 있게 합니다.

l NFS: NFS 내보내기로 버킷에 액세스할 수 있도록 합니다. 오브젝트 프로토콜을 사용하여 ECS 오브젝트 저장소에 기록된 오브젝트는 NFS를 사용하여 파일로 액세스할 수 있습니다. 마찬가지로 NFS를 사용하여 기록된 파일은 지원되는 오브젝트 프로토콜을 사용하여 오브젝트로 액세스할 수 있습니다.

프로비저닝 서비스프로비저닝 서비스는 스토리지 리소스 및 사용자 액세스의 프로비저닝을 관리합니다.특히 다음을 처리합니다.

l 사용자 관리: 어떤 사용자가 시스템을 관리하고, 스토리지 리소스를 프로비저닝하고, REST 요청을 통해 오브젝트에 액세스할 권한이 있는지 계속 추적합니다. ECS는 로컬 및 도메인 사용자를 모두 지원합니다.

l 모든 프로비저닝 요청에 대한 권한 부여 및 인증: 인증 도메인을 쿼리하여 사용자가관리, 프로비저닝 및 액세스 작업을 수행할 권한이 있는지 확인합니다.

l 리소스 관리: 권한이 부여된 사용자가 스토리지 풀, Virtual Data Center 및 복제 그룹을 생성할 수 있게 합니다.

l 멀티 테넌시: 테넌트와 테넌트의 관련 버킷 및 오브젝트를 나타내는 네임스페이스를 관리합니다.

Fabric 서비스Fabric 서비스는 다음을 담당하는 분산형 클러스터 관리자입니다.

l 클러스터 상태: 노드 관련 하드웨어 오류를 집계하여 클러스터의 전반적인 상태에대해 보고합니다.

l 노드 상태: 노드의 물리적 상태를 모니터링하고, 오류를 감지 및 보고합니다.

l 디스크 상태: 디스크 및 파일 시스템의 상태를 모니터링합니다. 잠금이 없고 빠른기본 읽기/쓰기 작업을 스토리지 엔진에 제공하고 개별 디스크 드라이브 및 그 상태에 대한 정보를 노출하므로, 스토리지 엔진이 내장된 데이터 보호 알고리즘에 따라 데이터를 디스크 드라이브에 분산시킬 수 있습니다.

l 소프트웨어 관리: 서비스를 설치 및 실행하는 툴과 클러스터의 노드에 Fabric 소프트웨어를 설치 및 업그레이드하기 위한 명령줄 툴을 제공합니다.

인프라스트럭처 서비스이 계층은 Commodity 노드에서 작동하는 Linux OS를 제공하고 네트워크 인터페이스와 다른 하드웨어 관련 툴을 구축합니다.


스토리지 서비스 11

ECS 어플라이언스다음 ECS 어플라이언스 모델을 사용할 수 있습니다.

l U-Series: 스토리지 용량을 극대화하기 위해 제작된 별개의 DAE(Disk ArrayEnclosure)가 있는 비정형 스토리지 서버. Gen1 및 업그레이드된 Gen2 하드웨어 구성에서 사용 가능

l C-Series: 더 큰 컴퓨팅 용량으로 제작된 통합 디스크가 있는 고밀도 컴퓨팅 서버.

아래 표에는 시리즈별 어플라이언스 구성 요소에 대한 설명이 나와 있습니다.

표 1 U-Series 구성 요소

구성 요소 설명

40U 랙 다음을 포함하는 EMC Titan D 랙:

l 전원 드롭 4개: 한 쪽에 두 개씩

l 단상 PDU(3상 wye 및 delta 사용 가능)

l 전면 및 후면 도어

l EMC 제조 설비에서 랙 장착

전용 스위치 1GbE 스위치 1개

공용 스위치 10GbE 스위치 2개

노드 4노드 및 8노드 구성의 Intel 기반 비정형 서버

DAE(Disk Array Enclosure) 8.89cm(3.5") 드라이브로 구성된 60개 디스크 DAE 서랍. Gen1하드웨어는 6TB 디스크를 사용하고 Gen2 하드웨어는 8TB 디스크를 사용합니다.

표 2 C-Series 구성 요소

구성 요소 설명

40U 랙 다음을 포함하는 EMC Titan D Compute 랙:

l 수평 전원 드롭 4개

l 단상 PDU(3상 wye 및 delta 사용 가능)

l 전면 및 후면 도어

l EMC 제조 설비에서 랙 장착

전용 스위치 1GbE 스위치 1개 또는 2개. 서버 섀시가 6개(24개 노드)보다 많은 구성에는 두 번째 스위치가 필요합니다.

공용 스위치 10GbE 스위치 2개 또는 4개. 서버 섀시가 6개(24개 노드)보다많은 구성에는 세 번째 및 네 번째 스위치가 필요합니다.

노드 8노드~48노드 구성의 Intel 기반 비정형 서버.

디스크 각 서버와 통합된 8.89cm(3.5") 드라이브 12개(노드당 3개).Gen1 하드웨어는 6TB 디스크를 사용하고 Gen2 하드웨어는8TB 디스크를 사용합니다.



네트워크 인터페이스노드에는 다음과 같은 네트워크 인터페이스가 있습니다.

l 공용: 모든 네트워크 트래픽을 처리하는 10GbE 인터페이스입니다. 인터페이스는랙에 있는 연결된 구성의 10GbE 스위치에 연결됩니다. 10GbE 스위치는 1개~4개의10GbE 업링크를 통해 고객 네트워크에 업링크됩니다.

l 전용: 내부 관리 작업에 사용되는 1GbE 인터페이스입니다. 모든 인터페이스가 전용인터페이스이며 ECS 트래픽 용도로 예약되어 있습니다. 각 노드마다 다음과 같은체계의 전용 IP 주소 2개가 자동으로 할당됩니다.

n 192.168.219.port_number: 이 네트워크는 설치 및 유지 보수 작업에 사용되며 랙로컬 트래픽만 지원합니다.

n 169.254.Rack_ID.port_number: 이 네트워크는 클러스터의 노드에 대한 분산형구성 서비스를 처리합니다. 데이터 센터 로컬 트래픽만 지원합니다.

스토리지 리소스 용량 할당ECS를 구축한 후에는 ECS Portal 서비스 인터페이스 중 하나를 사용하여 S3, Swift,CAS 또는 Atmos 애플리케이션에서 사용할 수 있도록 스토리지 리소스의 용량을 할당할 수 있습니다.

VDC(Virtual Data Center)VDC는 최상위 ECS 리소스입니다. 이는 유기적 단위로서 관리하려는 ECS 인프라스트럭처 모음을 나타내는 논리 구조입니다. 하나의 VDC를 생성하여 하나 이상의 물리적랙에 대한 리소스를 관리할 수 있지만, 단일 VDC의 ECS 리소스는 동일한 NAN(NileArea Network)에 속해야 합니다. 이와 같은 VDC를 사이트 또는 존이라고도 합니다.

여러 데이터 센터에 ECS 소프트웨어를 구축하여 원거리 연합을 생성할 수 있습니다.원거리 연합에서 ECS는 느슨하게 연결된 자율형 가상 데이터 센터의 연합처럼 작동하며, 사용자는 여기에 각 VDC를 별도로 프로비저닝합니다.

스토리지 풀스토리지 풀을 사용하여 VDC에서 사용 가능한 스토리지 리소스(노드)를 논리적으로분할할 수 있습니다. 스토리지 풀은 애플리케이션이나 멀티 테넌시 요구 사항을 기반으로 데이터를 물리적으로 분리할 수 있는 수단을 제공합니다. 스토리지 풀에는 4개 이상의 노드가 있어야 합니다. 데이터 보호 수준은 스토리지 풀을 복제 그룹에 할당하여 정의합니다.

8개 이상의 노드로 구성된 스토리지 풀을 자주 액세스하지 않는 파일을 위한 콜드 스토리지로 구성할 수 있습니다. 콜드 아카이브는 스토리지 오버헤드를 줄이는 삭제 코딩체계를 사용합니다.

복제 그룹복제 그룹은 스토리지 풀 컨텐츠가 보호되는 위치를 정의하는 논리 구조이며, WAN 트래픽 없이 데이터를 읽을 수 있는 위치입니다. 복제 그룹은 로컬 또는 글로벌일 수 있습니다. 로컬 복제 그룹은 같은 VDC 내부의 오브젝트를 디스크 또는 노드 장애로부터 보호합니다. 글로벌 복제 그룹은 여러 VDC에 걸쳐 있으며 오브젝트를 디스크, 노드 및 사이트 장애로부터 보호합니다.


네트워크 인터페이스 13

복제 그룹을 정의하는 데 사용하는 전략은 데이터 복구 성능, 스토리지 비용 및 데이터의 물리적 분리와 논리적 분리에 대한 요구 사항을 비롯하여 여러 요소에 따라 결정됩니다.

네임스페이스네임스페이스를 통해 ECS에서 다중 테넌트 작업을 처리할 수 있습니다. 네임스페이스에는 복제 그룹이 할당됩니다. 각 테넌트는 단일 네임스페이스와 해당 네임스페이스에서 오브젝트를 저장하고 액세스할 수 있는 사용자 집합으로 정의됩니다. 네임스페이스는 기업 내 부서를 나타내거나 다른 기업에 해당할 수 있습니다. 네임스페이스에 속한사용자는 다른 네임스페이스의 오브젝트에 액세스할 수 없습니다. SEC 규정 준수 기능은 네임스페이스 레벨에서 활성화됩니다.

Buckets버킷은 오브젝트 데이터의 컨테이너입니다. 버킷은 네임스페이스에서 생성되므로 적절한 권한을 가진 네임스페이스 사용자만 사용할 수 있습니다. 적절한 권한을 가진 네임스페이스 사용자는 각 오브젝트 프로토콜마다 해당 API를 사용하여 버킷을 생성하고버킷 내에 오브젝트를 생성할 수 있습니다. HDFS 및 NFS 파일 프로토콜을 지원하도록버킷을 구성할 수 있습니다. 파일 액세스용으로 구성된 버킷은 해당 오브젝트 프로토콜은 물론, 파일 프로토콜을 사용하여 읽고 쓸 수 있습니다.

네임스페이스 내에서 서브테넌트를 생성하는 수단으로서 버킷을 사용할 수 있습니다.

사용자 및 역할ECS에서는 다음과 같은 유형의 사용자 및 역할을 지원합니다.

l System Admin: 이 역할의 사용자는 VDC, 스토리지 풀, 복제 그룹, 인증 공급자, 버킷 및 사용자를 구성합니다. System Admin은 네임스페이스를 구성하고 네임스페이스 관리를 수행할 수 있거나 Namespace Admin으로 네임스페이스에 속하는 사용자를 할당할 수 있습니다. ECS의 루트 사용자 계정은 System Admin 역할에 할당되며 이를 사용하여 초기 구성을 수행할 수 있습니다.

l System Monitor: 이 역할의 사용자는 모든 구성 데이터를 볼 수 있지만 변경할 수는없습니다. 로컬 시스템 모니터는 자신의 암호를 변경할 수 있습니다.ECS의 루트 사용자 계정은 System Admin 역할에 할당되며 이를 사용하여 초기 구성을 수행할 수있습니다.

l Namespace Admin: 이 역할의 사용자는 할당량 및 보존 기간과 같은 네임스페이스설정을 구성하고, 도메인 사용자를 네임스페이스에 매핑하고 로컬 사용자를 네임스페이스에 대한 오브젝트 사용자로 할당할 수 있습니다. Namespace Admin 작업은 ECS REST API 또는 ECS Portal을 사용하는 프로그래밍 방식의 클라이언트에서도 수행할 수 있습니다.

l 오브젝트 사용자: 오브젝트 사용자는 ECS 오브젝트 스토리지의 최종 사용자입니다. 이 사용자는 ECS에서 지원되는 액세스 프로토콜(S3, Swift, CAS 또는 Atmos애플리케이션)을 사용하여 오브젝트 클라이언트를 통해 스토리지에 액세스합니다.오브젝트 사용자에게는 오브젝트 사용자가 할당된 네임스페이스 내부의 버킷 및오브젝트를 읽고 쓸 수 있는 권한이 주어질 수 있습니다.

모니터링, 진단 및 ViPR SRMECS에서는 ECS Portal을 통해 모니터링, 진단 및 이벤트 감사 기능을 제공합니다. 모니터링 페이지를 통해 스토리지, 리소스, 서비스 및 이벤트에 대한 개요를 파악할 수 있습니다. 모니터링 페이지를 드릴다운하여 진단 데이터를 파악할 수 있습니다.Dashboard가 포털에 로그인한 후 첫 번째로 표시되는 페이지입니다. 이 페이지에서는모니터링 데이터를 간단히 요약하여 보여 줍니다.



ECS는 EMC ViPR SRM도 지원합니다. ViPR SRM은 기존 스토리지 리소스와 소프트웨어 정의 스토리지 리소스에 대해 멀티벤더 용량, 성능 및 구성 보고서를 제공하는 소프트웨어 솔루션으로, 글로벌 보고서는 모든 스토리지 플랫폼에 걸쳐 용량, 차지백, 스토리지 사용량, 운영 및 성능 정보를 병합하여 전체 스토리지 인프라스트럭처의 포괄적인뷰를 제공합니다. 상세 보고서는 자산 유형에 대한 추가적인 세부 정보를 제공합니다.이외에 ViPR SRM에는 운영 알림, 규정 준수 보고, 토폴로지 맵 등의 기능이 있습니다.쉽게 파악할 수 있는 이러한 정보를 통해 스토리지 팀은 스토리지 환경을 실질적으로최적화하여 ROI를 개선할 수 있습니다.

ViPR SRM에 대한 자세한 내용은 ViPR SRM Documentation Index를 참조하십시오.


모니터링, 진단 및 ViPR SRM 15

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

2장

새로운 기능

l ECS 3.0의 새로운 기능....................................................................................... 18

새로운 기능 17

ECS 3.0의 새로운 기능ECS 3.0의 새로운 기능과 추가 사항을 설명합니다.

V4 인증을 위해 S3 프로토콜 지원

S3 프로토콜에 대한 ECS 지원에 이제 V4 인증이 포함됩니다.

버전 지정 오브젝트의 수명주기에 대한 S3 프로토콜 지원

버전 활성화 버킷에서 오브젝트 버전이 만료될 시기를 지정할 수 있도록 S3 프로토콜에 대한 ECS 지원에 이제 버전 지정 오브젝트의 수명주기에 대한 지원이 포함됩니다.이 기능을 사용하면 지정된 기간 이후 이전 버전의 오브젝트를 삭제할 수 있습니다.

파일 시스템 활성화 버킷에 수명주기를 적용할 수 없습니다.

S3 프로토콜 메타데이터 검색 기능 향상

ECS 3.0의 경우 인덱싱할 수 있는 키의 수가 5개에서 30개로 늘어났습니다. 이 키는 시스템 메타데이터 키와 사용자 메타데이터 키로 구성할 수 있습니다.

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

DLO(Dynamic Large Object) 및 SLO(Static Large Object)에 대한 OpenstackSwift 프로토콜 지원

ECS Openstack Swift 지원이 이제 SLO 및 DLO에 대한 지원을 제공합니다. SLO 지원을 통해 많은 오브젝트를 업로드하고, 매니페스트 파일을 사용하여 동일한 SLO와 연결하며, 단일 오브젝트로 다운로드할 수 있습니다.

DLO 지원을 통해 여러 오브젝트를 순서 및 키 접두사에 따라 DLO로 업로드 및 어셈블하고 단일 오브젝트로 다운로드할 수 있습니다.

DLO와 SLO 모두 대규모 오브젝트의 바이트 범위를 검색할 수 있도록 지원하는 범위요청을 수락합니다.

ECS에서의 SNMP 트랩 전송 지원

ECS는 SNMP 쿼리를 사용하여 노드 레벨 통계 보고를 지원합니다. ECS 3.0에서는 최대 10개의 네트워크 관리 스테이션 클라이언트에 SNMP v2 및 v3 트랩을 전송할 수 있도록 SNMP 지원이 확장되었습니다. SNMP 트랩은 ECS 이벤트를 보고합니다. 관리자는 ECS Portal을 통해 트랩 수신자를 구성할 수 있습니다.

새로운 기능


SNMP 쿼리 서버와 트랩 서버는 서로 다른 서버입니다. 트랩 서버는 SNMP 쿼리에 응답하지 않습니다.

support.emc.com의 ECS 영역에 있는 Add-Ons 아래의 Downloads 섹션에서 ECS-MIB정의(ECS-MIB.mib 파일)를 다운로드할 수 있습니다.

ECS는 다음과 같은 SNMPv3 암호화 해시 함수를 지원합니다.

l MD5(Message Digest 5)

l SHA-1(Secure Hash Algorithm 1)

ECS는 다음과 같은 암호화 프로토콜을 사용하여 SNMP v3 트래픽의 암호화를 지원합니다.

l 디지털 암호화 표준(56비트 키 사용)

l 고급 암호화 표준(128비트, 192비트 또는 256비트 키 사용)

ECS SNMP 트랩 기능에서 제공하는 고급 보안 모드(AES192/256) 지원은 일부 SNMP타겟(예: iReasoning)과 호환되지 않을 수 있습니다.

ECS SNMP 대한 자세한 정보는 ECS 관리자 가이드의 이벤트 알림 장을 참조하십시오.ECS 설치 가이드에는 쿼리를 지원하도록 SNMP 서버를 구성하는 방법에 대한 자세한정보가 나와 있습니다.

원격 Syslog 서버 지원

ECS는 알림 및 감사 메시지를 원격 syslog 서버로 전달하는 것을 지원하며, 다음과 같은 애플리케이션 프로토콜을 사용하는 작업을 지원합니다.

l BSD Syslog

l 정형 Syslog

부분 가비지 수집을 통해 공간 재확보부분 GC(Garbage Collection)를 통해 활성 데이터 세트 및 데이터 임의 삭제 또는 수정과 관련된 활용 사례에서 스토리지 효율성을 높일 수 있습니다. 이 기능은 ECS의 기존전체 청크 가비지 수집을 보완하여, 보존 중인 아카이브 데이터에 대한 일반적인 벌크삭제 활용 사례를 지원합니다.

부분 삭제된 청크에서 공간을 재확보할 수 있도록 다음과 같은 두 가지 새로운 기술이도입되었습니다.

l 병합을 통한 부분 가비지 수집 - 소스 청크를 확보할 수 있도록 부분적으로 비어 있는 소스 청크 세트의 유효 데이터를 새 청크에 복제합니다. 이 기술은 유효 데이터가 청크에서 작은 부분을 차지하고 있는 경우에 사용됩니다.

l 압축을 통한 부분 가비지 수집 - 가비지 데이터를 포함하는 디스크 범위가 청크에서추출되고 남아 있는 유효 데이터가 더 작은 청크로 취급됩니다. 이 기술은 유효 데이터가 청크에서 큰 부분을 차지하고 있는 경우에 사용됩니다.

글로벌 전파: 부분 GC의 공간 재확보와 관련된 변경 사항이 데이터 복제본으로도 전파됩니다. 원거리 복제 환경에서 새 데이터가 수집되면 가비지 범위로 이를 인코딩하여복제함으로써 새로 복제된 데이터가 원격 사이트에서 해당 가비지 범위를 덮어쓰도록합니다. 이를 통해 부분 가비지 수집에서 WAN 트래픽 오버헤드가 발생하지 않습니다.새로 수집된 데이터가 관련 가비지 데이터 범위로 인코딩된 후에만 재확보된 공간을 로컬 사이트에서 재사용할 수 있습니다.

새로운 기능

원격 Syslog 서버 지원 19

https://support.emc.com

부분 가비지 수집 기능은 ECS 3.0 릴리즈에서 제한적으로 사용할 수 있도록 릴리즈되었으며 필요 시 활성화할 수 있습니다. 이 기능은 워크로드 및 사용률이 높은 구축 환경을 위해 설계되었습니다. 부분 GC를 활성화하려면 ECS 3.0으로 업그레이드한 후 서비스 요청을 신청하십시오.

부분 GC를 제한적으로 제공하는 것은 중요한 아키텍처 변경을 수반하는 기능을 출시할 때 GA에 앞서 하나 이상의 릴리즈에서 제한적으로 제공하는 Best Practice에 따른것입니다.

플랫폼 잠금

노드에 대한 권한 있는 계정(루트, 관리자, emc)의 원격 액세스를 허용하는 것은 권장되지 않습니다. ECS Portal 또는 ECS Management REST API를 사용하여 한 클러스터내 특정 노드 또는 해당 클러스터 내 모든 노드를 잠글 수 있습니다. 노드를 잠글 경우잠긴 노드의 SSH 원격 액세스에만 영향을 줍니다. 잠금이 ECS Portal 및 REST API의작동 방식을 변화시키지는 않으며, 노드에 직접 연결하고 권한 있는 계정을 사용하여로그인하는 기능에도 영향을 주지 않습니다.

새로운 Lock Admin 사용자는 "emcsecurity"라는 사전 프로비저닝된 로컬 사용자입니다. Lock Admin은 자신의 암호를 변경하고 노드를 잠금 및 잠금 해제하는 작업만 수행할 수 있습니다. System Admin과 System Monitor는 노드의 잠금 상태를 볼 수 있습니다. Lock Admin 역할을 다른 사용자에게 할당할 수 없습니다.

대시보드 및 모니터링 향상

새로운 기능은 다음과 같습니다.

l ECS Portal 대시보드의 Traffic Metrics 패널: Traffic Metrics에는 전체 요청이 표시되며, 요청을 성공한 요청 및 사용자 오류로 인해 실패한 요청과 시스템 오류로 인해 실패한 요청으로 구분합니다. 사용자 오류는 일반적으로 다양한 오브젝트 헤드의 오류(HTTP 400 레벨 오류)로 알려져 있으며, 시스템 오류는 ECS 오류(HTTP500 레벨 오류)입니다.

l Traffic Metrics 모니터링 페이지의 오류 보고: History를 클릭하고 Failures bytype 패널을 선택합니다. ECS에 실패한 모든 요청이 사용자 또는 시스템 오류, 그리고 헤드(오브젝트 유형)를 기준으로 순서대로 정렬되어 나열되고, 자주 발생한오류 코드가 맨 위에 정렬됩니다.

l 온라인 용량, 오프라인 용량 및 총 용량을 보다 쉽게 구별할 수 있도록 CapacityUtilization 페이지가 새롭게 설계되었습니다.

l Hardware 페이지에는 이제 missing 및 removed 등 더 많은 디스크 상태가 표시됩니다. 누락된 디스크란 현재 접속할 수 없는 확인된 디스크입니다. 이 디스크는연결 끊김 또는 풀링 상태로 전환될 수 있습니다. 제거된 디스크란 시스템이 복구를완료하여 유효한 디스크의 스토리지 엔진 목록에서 제거된 디스크입니다.

CAS 고급 보존 관리

ECS는 이제 CAS API를 통해 사용할 수 있는 ARM(Advanced Retention Management)기능을 지원합니다. ECS에서 이러한 기능을 사용할 때 별도의 라이센스가 필요하지 않습니다. ARM 기능은 다음과 같습니다.

l 이벤트 기반 보존: CAS 애플리케이션에서 지정된 이벤트를 수신하면 보존 기간 또는 보존 클래스를 적용(트리거)하도록 C-Clip을 통해 오브젝트를 구성하는 기능입니다.

l 법적 증거 자료 보관: CAS 애플리케이션에서 C-Clip을 통해 오브젝트에 법적 증거자료 보관을 적용하여 해당 오브젝트의 삭제를 방지하는 기능입니다. CAS 애플리

새로운 기능


케이션에서는 고유 법적 증거 자료 보관 ID를 만들고 적용하여 오브젝트에 최대100개의 법적 증거 자료 보관을 적용할 수 있습니다.

l 최소/최대 관리자: 관리자가 버킷 레벨 고정 보존 기간 또는 가변 보존 기간을 설정할 수 있는 기능입니다. 가변 보존 기간은 이벤트에 대한 응답으로 설정되는 기간입니다. ECS에서 시스템 또는 네임스페이스 관리자는 ECS Portal을 통해 이 값을 설정할 수 있습니다. 프로그래머는 ECS Management API를 사용하여 이 값을 설정할수 있습니다.

규정 준수 네임스페이스에서 오브젝트 레벨 보존 없이 작성된 오브젝트의 기본 보존 기간에 대한 CAS 동작 변경

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개월 오브젝트 레벨 보존을 할당해야 합니다.

ECS 인증을 받은 타사 스토리지 하드웨어에서 ECS 3.0 및 ECS 소프트웨어만 설치된 ECS Appliance에 대해 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 이상의 설치도 인증되었습니다.

Atmos 지원 향상

ECS는 이제 다음과 같은 Atmos 기능을 지원합니다.

l 공유 가능한 URL: CIFS-ECS 툴은 사용자가 ECS에서 파일을 직접 검색할 수 있도록 하는 공유 가능한 URL을 생성합니다. ECS는 이제 CIFS-ECS 툴의 공유 URL을사용할 수 있도록 해 주는 Atmos API 공유 가능한 URL 기능을 지원합니다.

l 체크섬: x-emc-wschecksum 헤더가 이제 지원됩니다.

새로운 기능

규정 준수 네임스페이스에서 오브젝트 레벨 보존 없이 작성된 오브젝트의 기본 보존 기간에 대한 CAS 동작 변경 21

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

l Read, Write 및 Delete ACL: Atmos 데이터에 대한 이러한 ACL이 이제 Atmos와 마찬가지로 ECS에서도 실행됩니다.

l 인덱싱된 나열 가능한 태그: Atmos의 나열 가능한 태그 기능이 인덱스를 사용함으로써 ECS 3.0에서 크게 향상되었습니다. 나열 가능한 태그는 태그가 지정된 모든오브젝트를 손쉽게 검색 및 정렬할 수 있는 선택적 오브젝트 레벨 태그입니다.

CIFS-ECS 지원

ECS는 이제 애플리케이션 및 사용자가 로컬 Windows 드라이브에서 ECS에 보관된 컨텐츠에 액세스할 수 있도록 해주는 간단한 애플리케이션을 제공합니다.

파일은 Windows 시스템의 로컬 디스크 캐시에서 관리되며, S3 API를 사용하여 ECS 버킷으로 업로드되고 ECS 버킷에서 다운로드됩니다. 애플리케이션은 CIFS-ECS의 가상드라이브를 사용하여 파일을 정상적으로 생성하고 수정하고 읽을 수 있으며, 파일은 비동기식으로 ECS에 자동 업로드됩니다.

CIFS-ECS에 대한 자세한 정보는 CIFS-ECS 아키텍처 개요에서 확인할 수 있으며,CIFS-ECS 설명서는 EMC Elastic Cloud Storage (ECS) 3.0 제품 설명서에서 확인할 수있습니다.

ECS SW

ECS SW(ECS Software)는 ECS 소프트웨어를 사전 인증된 Dell 또는 HP 하드웨어에설치할 수 있도록 지원하는 새로운 오퍼링입니다.

다음은 ECS SW와 함께 사용하도록 인증된 하드웨어이며, 인증된 각 플랫폼에 대한 레퍼런스 아키텍처 문서는 support.emc.com에서 찾을 수 있습니다.

l HP Proliant SL4540 Gen8

l Dell DSS7000

l Dell R730xd 13G

EMC 고객 지원 담당자는 SolVe Desktop을 사용하여 구성 점검 및 상태 점검 툴을 다운로드함으로써 고객 문제 해결을 지원할 수 있습니다.

맞춤형 하드웨어를 사용하려는 고객은 해당 EMC 담당자에게 문의하여 요구 사항을 논의할 수 있습니다.

새로운 기능


https://support.emc.com/docu71714_CIFS-ECS_Architecture_Overview,_Performance_and_Best_Practices.pdf?language=en_US


3장

데이터 보호

l 데이터 보호 개요................................................................................................24l 스토리지 서비스.................................................................................................24l 오브젝트 생성.................................................................................................... 24l 오브젝트 읽기.................................................................................................... 28l 삭제 코딩........................................................................................................... 28l 디스크 및 노드 장애 시 복구...............................................................................30l 새 노드를 추가한 후 데이터 재조정....................................................................30l 사이트 페일오버 및 복구.....................................................................................31

데이터 보호 23

데이터 보호 개요ECS가 복제 및 삭제 코딩을 통해 노드, 디스크 및 사이트 장애로부터 비정형 데이터를보호하는 방법을 알아보십시오.

ECS는 오브젝트 복제본을 3개 생성한 후 해당 메타데이터와 함께 로컬 사이트의 여러노드 및 디스크에 분산시키는 방법으로 오브젝트의 내구성, 신뢰성 및 가용성을 보장합니다. 3개의 복제본이 성공적으로 작성되면 ECS가 오브젝트 복제본을 삭제 코딩하여스토리지 오버헤드를 줄입니다. ECS는 추가적인 백업 소프트웨어나 디바이스를 사용할 필요 없이 자동으로 장애와 복구 작업을 처리합니다.

스토리지 서비스스토리지 서비스 계층은 데이터 손상, 하드웨어 장애 및 데이터 센터 재해 시 데이터 가용성 및 보호 문제를 처리합니다.

USE(Unstructured Storage Engine)는 스토리지 서비스 계층의 일부입니다. 이는 각 노드에서 작동하는 분산형 공유 서비스로서, 트랜잭션을 관리하고 노드에 지속적으로 데이터를 전달합니다. USE는 원거리 복제를 통해 지리적으로 분산되어 있는 데이터 센터전반의 글로벌 네임스페이스 관리를 지원합니다.

USE는 청크라고 하는 인접 디스크 공간의 논리 컨테이너에 모든 오브젝트 관련 데이터(예: 사용자 데이터, 메타데이터, 오브젝트 위치 데이터)를 씁니다. 청크는 열린 상태로쓰기를 받거나, 닫힌 상태로 쓰기를 받지 않습니다. 청크가 닫힌 후, 스토리지 엔진이청크를 삭제 코딩합니다. 스토리지 엔진은 추가하는 방식으로만 청크에 쓰므로 기존 데이터가 덮어쓰이거나 수정되지 않습니다. 이 전략은 입출력 작업에 잠금 및 캐시 검증이 필요하지 않으므로 성능을 향상시킵니다. 모든 노드는 동일한 오브젝트에 대한 쓰기요청을 동시에 처리하면서 각기 다른 청크에 데이터를 쓸 수 있습니다.

스토리지 엔진은 오브젝트 이름, 청크 ID, 오프셋을 기록하는 인덱스를 통해 오브젝트위치를 추적합니다. 청크 위치는 청크 ID와 디스크 위치 세트를 기록하는 인덱스를 통해 별도로 추적됩니다. 삭제 코딩 이전에는 3개의 디스크 위치 포인터가, 삭제 코딩 이후에는 여러 개의 위치 포인터가 청크 위치 인덱스에 포함됩니다. 스토리지 엔진은 청크의 모든 스토리지 작업(예: 삭제 코딩 및 오브젝트 복구)을 수행합니다.

오브젝트 생성오브젝트 생성: 단일 VDC다음 그림은 단일 VDC가 있을 때 스토리지 엔진이 오브젝트 데이터를 쓰는 방법을 나타낸 것입니다. 이 예에서는 사이트에 단일 어플라이언스가 구축되어 있지만 더 많은어플라이언스가 구축될 때 같은 원칙이 적용됩니다. 단일 복제 그룹 내에서 단일 스토리지 풀에 8개의 노드가 있습니다.

데이터 보호


그림 2 단일 사이트: 오브젝트 생성

1. 애플리케이션이 버킷에 오브젝트를 생성합니다.

2. 스토리지 엔진은 한 청크에 오브젝트를 씁니다. 이 청크에 해당하는 디스크 위치는3개의 다른 디스크/노드 상에 있으므로, 쓰기가 3개의 다른 디스크/노드로 병렬로이루어집니다. 스토리지 엔진은 버킷의 복제 그룹에 속한 어떤 노드에든 오브젝트를 쓸 수 있습니다. 오브젝트가 생성되는 VDC가 오브젝트의 소유자입니다.

3. 스토리지 엔진은 청크 위치 인덱스에서 청크의 디스크 위치와 오브젝트 위치 인덱스에서 청크 ID 및 오프셋을 기록합니다.

4. 스토리지 엔진은 한 청크와 해당 디스크 위치에 대한 오브젝트 위치 인덱스를 3개의 다른 디스크/노드에 쓰므로, 쓰기가 3개의 다른 디스크/노드로 병렬로 이루어집니다. 인덱스 위치는 오브젝트 청크 위치와는 상관없이 선택됩니다.

5. 모든 디스크 위치가 작성된 후, 스토리지 엔진은 애플리케이션에 대한 쓰기를 확인합니다.

오브젝트 청크가 가득 차면 스토리지 엔진이 청크를 삭제 코딩합니다. 오브젝트 위치인덱스 청크를 삭제 코딩하지는 않습니다.

오브젝트 생성: 연합 VDC(2개 사이트)두 VDC의 연합 구축에서, 스토리지 엔진은 로컬 VDC뿐 아니라 원격 VDC에도 오브젝트 청크를 씁니다.

데이터 보호

오브젝트 생성 25

그림 3 2개 사이트: 오브젝트 생성


2. 스토리지 엔진은 오브젝트가 수집되는 사이트에 있는 한 청크에 오브젝트를 씁니다. 이 청크에 해당하는 디스크 위치는 3개의 다른 디스크/노드 상에 있으므로, 쓰기가 3개의 다른 디스크/노드로 병렬로 이루어집니다. 스토리지 엔진은 버킷의 복제 그룹에 속한 어떤 노드에든 오브젝트를 쓸 수 있습니다. 스토리지 엔진은 청크위치 인덱스에서 청크의 디스크 위치와 오브젝트 위치 인덱스에서 청크 ID 및 오프셋을 기록합니다. 오브젝트가 원래 수집되는 사이트가 오브젝트의 소유자입니다.


4. 스토리지 엔진이 연합 사이트에 있는 3개의 노드에 청크를 복제합니다. 스토리지엔진은 연합 사이트에 있는 3개의 다른 노드에서도 오브젝트 위치 인덱스(이 다이어그램에는 표시되지 않음)에 청크 위치를 기록합니다.

청크가 가득 차면 스토리지 엔진이 오브젝트 청크를 삭제 코딩합니다. 오브젝트 위치인덱스 청크를 삭제 코딩하지는 않습니다.

한 복제 그룹에 두 개의 VDC가 있을 때는 두 VDC에 모두 읽을 수 있는 오브젝트 복제본이 있습니다.

데이터 보호


3개 사이트: 오브젝트 생성그림 4 오브젝트 생성: 연합 VDC(3개 이상 사이트)


2. 스토리지 엔진은 오브젝트가 수집되는 사이트에 있는 한 청크에 오브젝트를 씁니다. 이 청크에 해당하는 디스크 위치는 3개의 다른 디스크/노드 상에 있으므로, 쓰기가 3개의 다른 디스크/노드로 병렬로 이루어집니다. 스토리지 엔진은 버킷의 복제 그룹에 속한 어떤 노드에든 오브젝트를 쓸 수 있습니다. 스토리지 엔진은 청크위치 인덱스에서 청크의 디스크 위치와 오브젝트 위치 인덱스(이 다이어그램에는표시되지 않음)에서 청크 ID 및 오프셋을 기록합니다. 수신된 쓰기가 오브젝트의 소유자인 VDC에는 읽을 수 있는 오브젝트 복제본이 포함됩니다.


4. 스토리지 엔진은 복제 그룹 내에 있는 다른 VDC의 노드로 청크를 복제합니다. 스토리지 효율을 높이기 위해, 스토리지 엔진은 노드에 저장된 다른 오브젝트의 다른 청크와도 청크를 XOR 처리합니다.

청크가 가득 차면 스토리지 엔진이 XOR 처리된 청크를 삭제 코딩합니다. 가능하면 복제 단계를 거치지 않고 삭제 코딩된 형식으로 직접 XOR 청크를 씁니다. 오브젝트 위치인덱스 청크를 삭제 코딩하지는 않습니다.

Replicate to All Sites 옵션Replicate to All Sites는 복제 그룹을 생성할 때 관리자가 사용할 수 있는 옵션입니다.

이 기능이 설정된 복제 그룹은 복제 그룹 내에 있는 모든 사이트(VDC)에 모든 데이터를 복제합니다. 복제 그룹의 모든 VDC에 모든 데이터를 두면 스토리지 효율성은 떨어지지만 데이터 지속성이 보장되고 모든 사이트에서 로컬 성능이 향상됩니다.

이 옵션은 생성 시에만 활성화할 수 있으며 나중에 비활성화할 수 없습니다.

오브젝트 업데이트애플리케이션이 오브젝트를 완전히 업데이트하면, 스토리지 엔진은 앞서 설명한 원칙에 따라 새 오브젝트를 씁니다. 그런 다음 새 위치를 가리키도록 오브젝트 위치 인덱스를 업데이트합니다. 인덱스가 더 이상 이전 위치를 참조하지 않기 때문에 원래 오브젝트는 데이터 재배치(Garbage Collection)의 대상이 됩니다.

데이터 보호

오브젝트 생성 27

오브젝트 읽기오브젝트 읽기에는 두 가지 단계가 포함됩니다.

1. 오브젝트 메타데이터 읽기 - 오브젝트 컨텐츠를 호스팅하는 각 청크 내 바이트 범위와 청크 목록을 비롯한 위치 정보를 포함합니다.

2. 각 청크에서 바이트 범위를 읽고 데이터를 다시 사용자에게 스트리밍합니다.

다음 섹션에서는 단일 VDC 및 연합 VDC 읽기 프로세스에 대한 자세한 내용을 제공합니다.

오브젝트 읽기: 단일 VDC단일 사이트 구축에서, 클라이언트가 읽기 요청을 제출하면 스토리지 엔진은 오브젝트위치 인덱스를 사용하여 오브젝트를 저장하고 있는 청크를 찾아 청크 또는 삭제 코딩된조각을 가져온 후, 오브젝트를 재구성해 클라이언트에 반환합니다.

오브젝트 읽기: 연합 VDC(2개 사이트)두 사이트로 된 연합에서, 오브젝트 “소유자” 존(Zone)이 오브젝트의 현재 상태에 대한정확한 정보를 포함하므로 스토리지 엔진은 이 존에서 오브젝트 메타데이터를 읽습니다. 오브젝트의 운영 사이트가 아닌 사이트에서 오브젝트에 액세스할 때, 데이터 청크가 이미 보조 사이트로 원거리 복제(Geo-Replicated)된 경우 데이터 청크 읽기는 보조사이트에서 로컬로 처리됩니다. 복제되지 않은 경우 WAN을 통해 운영 사이트에서 청크 읽기가 수행됩니다.

오브젝트 읽기: 연합 VDC(3개 이상 사이트)3개 이상의 사이트로 된 연합에서, 스토리지 엔진은 오브젝트 소유자 존에서 오브젝트메타데이터를 읽습니다.

항상 청크의 운영 사이트가 청크에 대한 완전한 복제본을 갖게 됩니다. 청크 소유자가아닌 사이트에서 읽기를 신속하게 처리하기 위해 읽기 캐시가 유지됩니다. 읽기 캐시는운영 사이트 또는 소유자가 아닌 사이트의 전체 청크 복제본을 저장합니다.

청크를 로컬로 사용할 수 있어서 청크가 운영 사이트나 다른 사이트를 위한 읽기 캐시에서 3중 미러링 또는 삭제 코딩될 수 있는 경우 청크는 해당 사이트에서 처리됩니다.읽기 작업에 필요한 청크 전체가 사이트에 존재하지 않는 읽기 캐시 비적중이 발생하면, 오브젝트를 호스팅하는 청크의 바이트 범주가 운영 사이트에서 검색되고 원격 사이트에서 사용자에 대한 응답으로 다시 스트리밍됩니다. 백그라운드에서는 추론을 기반으로 전체 청크를 원격 사이트에서 가져온 뒤 읽기 캐시에 추가할 수 있습니다. 운영 사이트와 캐싱에서 검색할 때의 성능이 보조 사이트에서 XOR 처리된 복제본을 검색할 때의 성능보다 더 우수합니다.

봉인 시 청크를 변경할 수 없기 때문에 봉인된 청크만 캐시에 추가할 수 있습니다.

삭제 코딩ECS는 EC(Erasure Coding)를 사용하여 데이터 보호 환경에 영향을 미치지 않으면서더 높은 스토리지 효율을 제공합니다.

스토리지 엔진은 오브젝트가 12개의 데이터 조각과 4개의 코딩 조각으로 나뉘는 ReedSolomon 12 + 4 삭제 코딩 체계를 사용합니다. 총 16개의 조각은 로컬 사이트 내의 여러노드로 분산됩니다. 스토리지 엔진은 12개의 조각 중 몇 개로든 오브젝트를 재구성할수 있습니다.

데이터 보호


표 3 여러 사이트를 구축할 때의 스토리지 오버헤드

사이트 수 스토리지 오버헤드

1 1.33

2 2.67

3 2.00

4 1.77

5 1.67

6 1.60

7 1.55

8 1.52

ECS의 경우 단일 사이트에서 최소 4개의 노드가 오브젝트 서비스를 실행해야 합니다.ECS는 노드 수를 기준으로 장애를 견딥니다.

표 4 단일 사이트의 노드 장애 허용

총 노드 쓰기의 노드 장애 허용

4 1

8~24 2

오브젝트에 삭제 코딩이 설정되면 원래 청크 데이터가 클러스터 전체에 분산된 16개의조각으로 구성된 단일 복제본으로 표시됩니다. 오브젝트에 삭제 코딩이 설정된 경우ECS가 디코딩이나 재구성 없이 오브젝트를 직접 읽을 수 있습니다. ECS는 하드웨어장애가 발생할 경우 오브젝트 재구성에 코드 조각만 사용합니다.

이 삭제 체계는 최대 4개의 드라이브 장애까지 복구가 가능합니다.

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

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

EC 요구 사항

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

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

필요한 최소디스크 수

권장되는 디스크 수

EC 효율성 EC 체계

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

콜드 아카이브 관리자가 구성 6 12* 24 1.2x 10 + 2

데이터 보호

삭제 코딩 29

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

디스크 및 노드 장애 시 복구ECS는 클러스터에 저장된 노드와 해당 디스크, 그리고 오브젝트의 상태를 지속적으로모니터링합니다. ECS는 데이터 보호 책임을 클러스터 전체에 분산시키므로 노드나 디스크에 장애가 발생할 때 위험 상태의 오브젝트를 자동으로 재보호할 수 있습니다.

디스크 상태ECS가 디스크 상태를 Good, Suspect 또는 Bad로 보고합니다.

l Good: 디스크의 파티션을 읽고 쓸 수 있습니다.

l Suspect: 디스크가 아직 Bad로 간주할 만한 임계값에 도달하지 않았습니다.

l Bad: 하드웨어 성능 감소의 특정 임계값에 도달했습니다. 임계값에 도달하면 데이터를 읽거나 쓸 수 없습니다.

ECS는 Good 상태의 디스크에만 데이터를 쓰고, Suspect 또는 Bad 상태의 디스크에는데이터를 쓰지 않습니다. ECS는 Good 상태의 디스크와 Suspect 상태의 디스크에서 데이터를 읽습니다. 오브젝트 청크 중 2개가 Suspect 디스크에 위치한 경우, ECS는 다른노드에 청크를 씁니다.

노드 상태ECS가 노드 상태를 Good, Suspect 또는 Bad로 보고합니다.

l Good: 노드가 사용 가능하고 입출력 요청에 늦지 않게 응답합니다.

l Suspect: 30분 넘게 노드가 중단되었습니다.

l Bad: 1시간 넘게 노드가 중단되었습니다.

ECS는 노드 상태와 관계없이 접속 가능한 노드에 쓰기 작업을 수행합니다. 오브젝트청크 중 2개가 Suspect 노드에 위치한 경우, ECS는 다른 노드에 해당 오브젝트의 새 청크 2개를 씁니다.

데이터 복구사이트의 노드 또는 드라이브에 장애가 발생하면 스토리지 엔진은 다음을 수행합니다.

1. 장애로 영향을 받는 청크 또는 EC 조각을 식별합니다.

2. 영향을 받는 청크 또는 EC 조각의 복제본을 현재 복제본을 가지고 있지 않은 Good노드 및 디스크에 씁니다.

새 노드를 추가한 후 데이터 재조정새로운 랙이나 스토리지 노드의 추가로 인해 사이트의 노드의 수가 늘어나는 경우, 삭제 코딩된 새로운 청크가 새로운 스토리지에 할당되고 기존 데이터 청크는 새로운 노드전체에 걸쳐 재분배(재조정)됩니다. 청크에 대한 삭제 코딩이 수행되려면 노드가 4개이상 있어야 합니다. 필요한 노드 개수인 4개를 초과하여 새 노드를 추가하는 경우 EC재조정 작업이 수행됩니다.

EC 조각의 재분배 작업은 백그라운드 작업으로 수행되므로 재분배 프로세스를 실행하는 동안 청크 데이터에 계속해서 액세스할 수 있습니다. 그뿐만 아니라 네트워크 대역폭 사용량을 최소화하기 위해 새로운 조각 데이터는 낮은 우선 순위로 분배됩니다.

데이터 보호


조각은 원래 인코딩될 때 사용된 것과 동일한 EC 체계에 따라 재분배됩니다. 따라서 청크가 콜드 스토리지 EC 체계를 사용하여 쓰여진 경우 재분배를 위해 새로운 조각을 생성할 때 콜드 스토리지 체계가 사용됩니다.

사이트 페일오버 및 복구ECS는 사이트를 오프라인 상태로 전환하거나 원거리 연합된 구축 환경에서 사이트를다른 사이트와는 분리되게 만드는 재해 또는 기타 문제로 인한 사이트 장애에 대해 보호 기능을 제공합니다.

일시적 사이트 장애연합된 VDC 사이에서 네트워크 연결이 중단되거나 VDC가 일시적으로 다운될 때 일시적 사이트 장애가 발생합니다. VDC가 다운되면 Replication Group 페이지에 연결할수 없는 VDC에 대해 Temporarily unavailable 상태가 표시됩니다.

Access During Outage 속성이 On으로 설정되도록 버킷이 구성되어 있으면, 사이트에연결되어 있는 동안 애플리케이션이 오브젝트를 읽을 수 있습니다. 버킷의 소유자가 아닌 사이트에 애플리케이션이 연결되어 있을 때는 버킷에 데이터를 쓰거나 그 내용을 보려면 애플리케이션이 버킷에 명시적으로 액세스해야 합니다. 애플리케이션이 소유자가 아닌 VDC에 연결되어 있는 동안 오브젝트나 버킷을 수정하는 경우, 스토리지 엔진은 변경이 시작되는 사이트에 소유권을 넘깁니다.

원거리 연합된 사이트에서는 Access During Outage 설정과는 상관없이 일시적 장애를 해결해야 다음과 같은 작업을 완료할 수 있습니다.

l Bucket: 버킷 생성 또는 이름 바꾸기, 버킷 속성 수정, 네임스페이스 소유자 사이트에 연결할 수 없을 때 네임스페이스에 대한 버킷 나열

l Namespace: create

l Login as: create

사이트가 다시 연결된 후, 스토리지 엔진은 백그라운드에서 재동기화 작업을 시작합니다. 포털의 Monitor > Recovery Status를 사용하여 재동기화 작업의 진행률을 모니터링합니다.

영구적 사이트 페일오버사이트에서 재해가 발생하고 VDC를 다시 온라인 상태로 전환할 수 없는 경우에는 VDC를 삭제해야 합니다.

데이터 보호

사이트 페일오버 및 복구 31

데이터 보호


4장

ECS 설치 계획

l ECS 설치 계획....................................................................................................34l 설치 장소 준비................................................................................................... 34l ECS 설치 준비 체크리스트.................................................................................34l 단일 사이트에서 ECS Appliance 연결 ................................................................34l 멀티 사이트 요구 사항........................................................................................36l 네트워크 분리.................................................................................................... 36l 로드 밸런싱 고려 사항........................................................................................42l 용량 고려 사항................................................................................................... 42

ECS 설치 계획 33

ECS 설치 계획전용 관리 네트워크 토폴로지뿐 아니라 물리적 환경, 데이터 센터 및 멀티 사이트 요구사항에 대해 알아보십시오.

설치 장소 준비ECS Appliance에서 사용되는 40U-D 캐비닛 관련 환경 요구 사항은 사이트 준비 가이드를 참조하십시오.

ECS 설치 준비 체크리스트성공적인 설치를 위한 이 인프라스트럭처 구성 요소 및 요구 사항 목록을 검토하십시오. 설치 담당자는 작업 시 구성 요구 사항이 ECS Designer 스프레드시트에 정의되어있는지 확인해야 합니다.

ECS Appliance 구축 환경은 다음 요소로 구성됩니다.

l 하나 이상의 랙

n 데이터 트래픽과 원격 관리를 모두 고려하여 랙을 고객 네트워크에 업링크해야합니다.

랙과 모든 노드는 전원이 켜져 있어야 합니다.

노드에는 DHCP에 의해 할당되거나 정적으로 구성된 유효한 IP 주소가 있어야합니다.

l 인프라스트럭처 요구 사항: 데이터 센터 환경에는 모든 노드에서 액세스할 수 있는다음 서버가 포함되어 있어야 합니다.

n DHCP 서버(DHCP를 통해 IP 주소를 할당할 경우)

n DNS 서버(또는 전달자) - 최소 2개 필요

n NTP 서버 - 최소 2개 필요

n SMTP 서버

다음 사항을 확인해야 합니다.

l ECS 노드에 대한 DNS 레코드가 ECS Designer에 따라 고객 DNS[정방향 및 역방향nslookups]에 생성되어야 합니다.

l 업링크 토폴로지 및 네트워크 구성을 고객과 함께 검증해야 합니다.

l 스위치가 올바르게 구성되어 있어야 합니다. 그렇지 않은 경우 SolVe Desktop에서기본 구성을 얻을 수 있습니다. 스위치 구성을 설치하는 절차는 설치 가이드: 스위치 구성에 있습니다.

l ECS 통신에 사용되는 포트 목록을 검토해야 합니다.ECS 보안 가이드에 열려 있어야 하는 포트 목록이 나와 있습니다.

단일 사이트에서 ECS Appliance 연결ECS Appliance 관리 네트워크는 Nile Area Network를 통해 함께 연결됩니다. NAN은 포트 51 또는 52를 또 다른 ECS Appliance의 다른 터틀 스위치에 연결하여 생성됩니다.어떤 세그먼트에서든 이런 연결을 통해 NAN의 다른 노드와 통신할 수 있습니다.

ECS 설치 계획


https://support.emc.com/docu34561_40U-D-Cabinet-Site-Preparation-Guide.pdf?language=en_US

https://support.emc.com/docu34561_40U-D-Cabinet-Site-Preparation-Guide.pdf?language=en_US



ECS Appliance를 함께 연결하는 가장 간단한 토폴로지에는 추가 스위치 하드웨어가 필요하지 않습니다. 모든 터틀 스위치를 선형 또는 데이지 체인 방식으로 함께 연결할 수있습니다.

그림 5 선형 또는 데이지 체인 토폴로지

이 토폴로지에서는 연결이 끊길 경우 스플릿 브레인(split-brain)이 발생할 수 있습니다.

그림 6 선형 또는 데이지 체인 스플릿 브레인

더욱 신뢰할 수 있는 네트워크를 위해, 데이지 체인 토폴로지의 끝을 함께 연결하여 링네트워크를 만들 수 있습니다. Ring 토폴로지의 경우, 스플릿 브레인이 발생하려면 토폴로지에 두 개의 케이블 링크 중단 지점이 필요하므로 더 안정적입니다. Ring 토폴로지의 주요 단점은 외부 고객 또는 Aggregation 스위치가 링에 추가되지 않으면 고객 네트워크에 RMM 포트를 연결할 수 없다는 점입니다.

그림 7 Ring 토폴로지

대규모 설치에는 데이지 체인 또는 Ring 토폴로지를 권장하지 않습니다. ECSAppliance가 4개 이상 있을 때는 Aggregation 스위치를 사용하는 것이 좋습니다. Star토폴로지에 Aggregation 스위치를 추가하면 스플릿 브레인 문제가 줄어 더 나은 페일오버 기능을 제공할 수 있습니다.

ECS 설치 계획

단일 사이트에서 ECS Appliance 연결 35

그림 8 Star 토폴로지

멀티 사이트 요구 사항멀티 사이트 ECS 설치 계획 시, 다음 요구 사항이 충족되는지 확인하십시오.

l 최소 두 개의 VDC가 필요합니다.

l 멀티 사이트 구성의 각 VDC에는 다른 VDC에 대한 IP 접속 구성이 필요합니다.

n 네트워크 지연: 사이트 간에 지연 시간은 1000ms 이하여야 합니다.

n 사용 가능한 스토리지: 재해 복구 계획에서 사이트를 즉시 복구하는 대신 한 사이트에 영구적 장애가 발생한 상태로 일정 기간 실행하려는 경우 모든 사이트전체에서 데이터 재조정을 수용할 만큼 각 사이트의 사용 가능한 스토리지 공간이 충분해야 합니다. 모든 사이트 전체에서 사용 가능하도록 남은 공간의 합계는 다음과 같아야 합니다.

free space across n sites =1.33*x/(n-1)/(n-2)

여기서 x는 모든 n개 사이트 전체의 사용자 데이터 총량입니다.

페일오버 직후 사이트를 새로 추가하는 경우에는 이 수준의 사용 가능한 공간이필요하지 않습니다. 또한 (N-1)개 사이트로 운영을 무기한 지속해서는 안 됩니다.

네트워크 분리데이터, 관리 및 (다른 지역으로의) 복제 트래픽을 개별적으로 식별할 수 있도록 공용10GbE 인터페이스를 분리할 수 있습니다. 네트워크 분리를 사용할 경우 ECSManagement REST API 호출(ECS Portal 포함) 및 데이터 액세스 프로토콜을 모두 사용하여 ECS에 액세스하려는 클라이언트가 생성한 트래픽을 분리할 수 있습니다. 마찬가지로 사이트 간 복제 트래픽을 데이터 및 제어 계층 트래픽과 별도로 식별할 수 있습니다.

특정한 요구 사항이 없을 경우 네트워크 분리를 구성할 필요가 없습니다. 대부분의ECS 설치에서는 네트워크 분리를 사용하지 않습니다.

네트워크 분리는 VIP(Virtual IP) 또는 VLAN(Virtual LAN)을 사용하여 실현할 수 있습니다. VIP로 분리된 네트워크 및 VLAN으로 분리된 네트워크를 혼용하는 것은 지원되지않습니다. 분리된 각 네트워크에 대해 고유 업링크가 구성되어 있는 경우 물리적 네트워크 분리 지원은 EMC RPQ(Request for Product Qualification) 프로세스를 따릅니다.

네트워크 구성 옵션으로는 세 가지가 있습니다.

ECS 설치 계획


표준 구성(단일 네트워크 - 분리 안 함)

모든 트래픽(관리, 데이터 및 복제)이 모두 동일한 네트워크에 있습니다. 공용 인터페이스의 IP 주소는 정적이거나 동적으로 할당될 수 있습니다.

부분 네트워크 분리

l 다음과 같은 특정 트래픽 유형이 분리됩니다.

n 복제 트래픽이 분리됩니다. 관리 및 데이터 트래픽은 공용 인터페이스에 그대로 유지됩니다.

n 데이터 트래픽이 분리됩니다. 관리 및 복제 트래픽은 공용 인터페이스에 그대로 유지됩니다.

n 관리 트래픽이 분리됩니다. 복제 및 데이터 트래픽은 공용 인터페이스에 그대로 유지됩니다.

l 또는 다음과 같은 두 가지 트래픽 유형이 분리됩니다.

n 관리 및 복제 트래픽이 분리됩니다. 데이터 트래픽은 공용 인터페이스에 그대로 유지됩니다.

n 관리 및 데이터 트래픽이 분리됩니다. 복제 트래픽은 공용 인터페이스에 그대로 유지됩니다.

n 데이터 및 복제 트래픽이 분리됩니다. 관리 트래픽은 공용 인터페이스에 그대로 유지됩니다.

이 구성에서는 정적 IP 주소가 먼저 공용 네트워크에 할당되어야 합니다. 그런 다음 VLAN 또는 VIP를 사용하여 여러 트래픽 유형이 분리되고 나머지 트래픽 유형은 정적 공용 인터페이스를 사용합니다.

전체 분리

네 가지 개별 네트워크가 사용됩니다.

l 공용(정적) - 이 IP 주소 범위는 처음에 공용 인터페이스를 정적 IP 주소로 구성하는 데 사용됩니다. 관리, 데이터 및 복제 네트워크가 분리되고 나면 정적 IP가 구성된 상태로 유지되지만 ECS의 정상 작업에는 사용되지 않습니다. 하지만 노드에 대해 SSH를 수행하는 경우 유지 보수 용도로 사용될 수 있습니다.

l 관리

l 데이터

l 복제

이러한 시나리오는 아래 표에 설명되어 있습니다.

네트워크 구성 기본 네트워크

분리된 네트워크

public public.data public.mgmt public.repl

표준(분리 안 함) 데이터, 관리및 복제

부분 분리 옵션 1 관리 및 복제 데이터

옵션 2 복제 및 데이터

관리

옵션 3 관리 및 데이터

복제

ECS 설치 계획

네트워크 분리 37

네트워크 구성 기본 네트워크

분리된 네트워크

public public.data public.mgmt public.repl

옵션 4 데이터 관리 복제

옵션 5 복제 데이터 관리

옵션 6 관리 데이터 복제

전체 분리 데이터 관리 복제

VLAN을 사용한 네트워크 분리를 구성할 경우 각 트래픽 유형(데이터, 관리 또는 복제)이 고유 VLAN ID 및 고유 IP 주소에 할당되도록 각 노드에 네트워크 인터페이스를 구성하는 것이 좋습니다. 이 경우 네트워크 패킷이 지정된 VLAN에 속하는 것으로 태그가지정됩니다. ECS에서 적절한 VLAN ID로 트래픽에 태그를 지정할 것이므로, 특정VLAN ID로 태그가 지정된 클라이언트 트래픽이 스위치 외부로 전달되도록 하려면10GbE 스위치를 구성해야 합니다.

VIP(Virtual IP)를 사용한 네트워크 분리는 트래픽 유형이 각각 다른 IP 주소에 할당될수 있도록 추가 VIP를 10GbE 인터페이스에 할당하여 실현할 수 있습니다.

VIP를 사용하든, VLAN을 사용하든 기본 게이트웨이가 항상 공용 인터페이스에 설정되어 있어야 합니다. 기본 게이트웨이에서 라우팅할 수 없는 네트워크에 분리된 인터페이스를 구성할 경우에는 인터페이스의 주소 확인을 지원하도록 정적 경로를 추가해야 합니다.

ECS에 액세스하는 클라이언트는 데이터 또는 관리 네트워크 IP 주소를 사용합니다. 데이터 네트워크의 경우, 트래픽이 데이터 네트워크에 할당된 주소에 걸쳐 고르게 분산되어야 합니다.

1. 이 릴리즈에서는 HAL 및 Fabric/Object를 설치하고 나면 시스템에 대해 구성된 IP주소 및 네트워크를 변경할 수 없습니다.

2. 멀티 랙 및 Geo 구성의 경우 다음과 같도록 노드 및 사이트 전체에 동일한 유형의네트워크 분리 구성을 구축해야 합니다.

l 한 사이트에 분리된 네트워크가 없는 경우 다른 사이트에도 분리된 네트워크가없어야 합니다. 사이트에 동일한 네트워크 분리 구성이 있어야 합니다.

l 단일 사이트의 랙에 걸쳐 노드 및 랙에 동일한 네트워크 분리 구성이 있어야 합니다.

l 각 VLAN 분리 네트워크의 VLAN ID는 동일한 브리지 도메인에 있는 모든 사이트에서 동일해야 하나, 라우터에 의해 분리 네트워크가 종료된 경우에는 다를수 있습니다.

ECS 설치 절차의 일부로 VLAN 및 VIP 구성이 수행되므로 ECS 설치를 시작하기 전에네트워크 분리를 어떻게 구성할지 결정해야 합니다. 네트워크 분리 계획에 대한 요구사항 관련 지침은 아래에 나와 있습니다.

VIP를 사용한 네트워크 분리 계획

VIP를 사용한 네트워크 분리를 계획하는 경우 다음을 수행해야 합니다.

l 노드당 하나씩 공용 IP 주소를 정합니다. 네트워크 분리를 사용할 경우 공용 IP 주소를 정적으로 할당해야 합니다.

ECS 설치 계획


l 분리하려는 네트워크를 결정합니다. 데이터, 관리 또는 복제 네트워크 중 하나 또는모두를 분리할 수 있습니다.

l 각 노드의 각 LNI(Logical Network Interface)에 대한 VIP를 결정합니다.

l 데이터 트래픽을 데이터 네트워크 IP 전체에 걸쳐 고르게 분산하도록 로드 밸런싱장치 구성을 결정합니다.

l 네트워크의 트래픽을 라우팅하는 데 필요한 정적 경로를 결정합니다.

4노드 랙에 대한 공용 IP와 가상 IP를 할당하는 예가 아래에 나와 있습니다. 다음 표에VIP를 사용하여 데이터 트래픽을 분리하는 예가 나와 있습니다.

주소 노드 1 노드 2 노드 3 노드 4 넷마스크 게이트웨이

공용 주소(정적)

10.241.51.85 10.241.51.86 10.241.51.87 10.241.51.88 255.255.252.0 10.241.48.1

데이터 네트워크

10.241.50.144 10.241.50.147 10.241.50.150 10.241.50.153 255.255.252.0 10.241.48.1

아래 표에 VIP를 사용하여 데이터, 관리 및 복제 트래픽을 분리하는 예가 나와 있습니다.

주소 노드 1 노드 2 노드 3 노드 4 넷마스크 게이트웨이


10.241.51.85 10.241.51.86 10.241.51.87 10.241.51.88 255.255.252.0 10.241.48.1


10.241.50.144 10.241.50.147 10.241.50.150 10.241.50.153 255.255.252.0 10.241.48.1

관리 네트워크 10.241.50.145 10.241.50.148 10.241.50.151 10.241.50.154 255.255.252.0 10.241.48.1

복제 네트워크 10.241.50.146 10.241.50.149 10.241.50.152 10.241.50.156 255.255.252.0 10.241.48.1

이 예에서는 게이트웨이 주소가 모든 인터페이스에서 동일하므로 공용 주소에 대한 기본 게이트웨이만 정의하면 됩니다.

VLAN을 사용한 네트워크 분리 계획

VLAN을 사용한 네트워크 분리를 계획하는 경우 다음을 수행해야 합니다.

l 노드당 하나씩 공용 IP 주소를 정합니다. 네트워크 분리를 사용할 경우 공용 IP 주소를 정적으로 할당해야 합니다.

l 분리하려는 네트워크를 결정합니다. 데이터, 관리 또는 복제 네트워크 중 하나 또는모두를 분리할 수 있습니다.

l 가상 네트워크에 사용할 VLAN ID를 결정합니다.

l 각 노드의 각 가상 네트워크 인터페이스에 대한 IP 주소를 결정합니다.

l VLAN ID를 지원하도록 ECS 10GbE(집토끼 및 산토끼) 스위치 구성을 결정합니다.이 구성은 이 설치에 포함되는 단계가 아니므로 EMC Professional Services가 설치를 실시하기 전에 수행해야 합니다.

ECS 설치 계획

VLAN을 사용한 네트워크 분리 계획 39

네트워크 분리를 지원하도록 집토끼 및 산토끼 10GbE 스위치를 구성하는 방법은분리하는 네트워크 및 업링크별로 서로 다른 물리적 연결을 사용할지 여부에 따라다릅니다(물리적 네트워크 분리에는 RPQ가 적용됨).

l 데이터 트래픽을 데이터 네트워크 IP 전체에 걸쳐 고르게 분산하도록 로드 밸런싱장치 구성을 결정합니다.

l 네트워크의 트래픽을 라우팅하는 데 필요한 정적 경로를 결정합니다.

4노드 랙에 대한 공용 IP, 분리된 네트워크 IP 및 VLAN ID를 할당하는 예가 아래에 나와있습니다. 이 예에서 VLAN ID는 각각 별도의 서브넷(10.10.10, 10.10.20 및 10.10.30)에있습니다.

다음 표에 VLAN만 사용한 데이터 트래픽의 네트워크 분리 예가 나와 있습니다.

VLAN ID 노드 1 노드 2 노드 3 노드 4 넷마스크 게이트웨이


10.241.51.35 10.241.51.36 10.241.51.37 10.241.51.38 255.255.252.0 10.241.48.1


1000 10.10.10.35 10.10.10.36 10.10.10.37 10.10.10.38 255.255.255.0 10.10.10.1

아래 표에 VLAN을 사용한 전체 네트워크 분리 예가 나와 있습니다.

VLAN ID 노드 1 노드 2 노드 3 노드 4 넷마스크 게이트웨이


10.241.51.35 10.241.51.36 10.241.51.37 10.241.51.38 255.255.252.0 10.241.48.1


1000 10.10.10.35 10.10.10.36 10.10.10.37 10.10.10.38 255.255.255.0 10.10.10.1

관리 네트워크

2000 10.10.20.35 10.10.20.36 10.10.20.37 10.10.20.38 255.255.255.0 10.10.20.1

복제 네트워크

3000 10.10.30.35 10.10.30.36 10.10.30.37 10.10.30.38 255.255.255.0 10.10.30.1

단일 업링크를 사용하는 VLAN을 통한 네트워크 분리용 스위치 구성

분리된 모든 VLAN 네트워크에서 고객 네트워크에 대해 동일한 업링크 연결을 사용 중인 경우, 모든 VLAN을 트렁킹하도록 업링크 포트를 구성해야 합니다.

또한 선택한 VLAN ID로 태그가 지정된 트래픽을 허용하고 트렁킹된 업링크 포트를 통해 통과하도록 노드에 연결하는 포트 채널을 구성해야 합니다.

아래 예에서는 데이터, 복제 및 관리 네트워크가 서로 다른 VLAN에 있고 태그가 지정된 모든 트래픽을 동일한 업링크에서 주고받습니다.

인터페이스 이름 VLAN ID 태그 지정 업링크 연결

public 없음 지원 안 함 MLAG: po100각 스위치에서 하나 이상의 포트

data 1000 지원

repl 2000 지원

ECS 설치 계획


인터페이스 이름 VLAN ID 태그 지정 업링크 연결

mgmt 3000 지원

이 구성이 아래 그림에 나와 있습니다. 이 예에서는 LAG(Link Aggregation Group)의 각스위치에 두 개의 포트가 있습니다.

Rabbit

Hare

Turtle

data/mgmt/repl(VLAN IDs 1000/2000/3000)

data/mgmt/repl(VLAN IDs 1000/2000/3000)

(VLAN IDs 1/1000/2000/3000)

po100

다음 표에 집토끼 및 산토끼 스위치에 대한 노드 포트 및 업링크 포트 구성의 예가 나와있습니다.

스위치/포트 VLAN(VLAN ID예)

구성

집토끼 및 산토끼/ECS 노드 포트-채널구성

data/mgmt/repl(VLAN ID1000/2000/3000)

interface port-channel 1-12 switchport trunk native vlan 1 switchport trunk allowed vlan 1,1000,2000,3000 switchport mode trunk

집토끼 및 산토끼/업링크 MLAG 구성

data/mgmt/repl(VLAN ID1000/2000/3000)

interface Ethernet 1 channel-group 100 mode activeinterface port-channel 100 switchport trunk allowed vlan 1,1000,2000,3000 switchport mode trunk mlag 100

ECS 설치 계획

VLAN을 사용한 네트워크 분리 계획 41

로드 밸런싱 고려 사항ECS 앞에 로드 밸런싱 장치를 사용하는 것이 좋습니다.

로드 밸런싱 장치는 ECS 클러스터 노드에 걸쳐 로드를 분산할 뿐만 아니라 트래픽을정상 작동하는 노드로 라우팅하여 ECS 클러스터에 대해 HA(High Availability)를 제공합니다. 네트워크 분리가 구축되어 데이터 및 관리 트래픽이 분리된 경우 지원되는 데이터 액세스 프로토콜을 사용한 사용자 요청이 데이터 네트워크의 IP 주소에 걸쳐 고르게 분산되도록 로드 밸런싱 장치를 구성해야 합니다. ECS Management REST API 요청은 관리 네트워크의 특정 노드 IP에 대해 직접 수행하거나 HA를 위해 관리 네트워크에걸쳐 로드 밸런싱할 수 있습니다.

로드 밸런싱 장치의 구성은 로드 밸런싱 장치 유형에 따라 크게 다르므로 검증된 구성및 Best Practice에 대한 자세한 내용은 EMC 기술 지원 부서에 문의하시기 바랍니다.

용량 고려 사항ECS에서 사용할 수 있고 사용 가능한 것으로 보고되는 스토리지 용량은 다음 요소의영향을 받을 수 있습니다.

l 스토리지 풀 용량(42페이지)

l 가비지 수집(42페이지)

스토리지 풀 용량

스토리지 풀에는 최소 4개의 노드가 있어야 하고 쓰기가 허용되려면 사용 가능한 용량이 10%가 넘는 노드가 3개 이상 있어야 합니다. 이 예약된 공간은 ECS가 시스템 메타데이터를 유지하는 동안 공간이 부족해지지 않도록 하는 데 필요합니다. 이 조건이 충족되지 않을 경우 쓰기가 실패합니다.

하나의 스토리지 풀에서 쓰기를 허용할 수 있는지 여부가 다른 풀에서 쓰기를 허용할수 있는지 여부에 영향을 미치지 않습니다. 실패한 쓰기를 감지하여 다른 VDC로 리디렉션하는 로드 밸런싱 장치가 있는 경우를 예로 들 수 있습니다.

가비지 수집

ECS의 가비지 수집은 입력/출력 작업보다 낮은 우선 순위로 실행되도록 설계되었으며, 오브젝트가 ECS에서 삭제될 경우 오브젝트에 할당된 공간을 재확보하는 데 약간의시간(5일 이상)이 걸립니다. 하지만, 오브젝트가 삭제된 것으로 표시되고 사용량 측정보고서 및 차지백 보고서를 통해 시스템 활용도를 보여 주는 사용자 뷰에 삭제가 반영됩니다. Best Practice로 삭제 후 4시간 동안의 사용량 측정 데이터를 사용하는 것이 좋습니다.

데이터 수집 중에 모든 데이터가 스트라이핑되어 청크 간에 분산됨에 따라 오브젝트가128MB 청크 집합에 매핑되므로, 단일 오브젝트 및 해당 메타데이터가 여러 데이터 청크와 메타데이터 청크에 걸쳐 있을 수 있습니다. 마찬가지로 하나의 청크가 여러 오브젝트의 데이터를 유지할 수 있습니다.

삭제가 처리되려면 오브젝트 인덱스는 물론, 청크 인덱스도 업데이트되어야 합니다. 오브젝트 인덱스는 삭제된 오브젝트 및 해당 데이터 청크와 메타데이터 청크 간 연결을제거하도록 업데이트됩니다. 청크가 재확보 대상으로 표시되기 전에 청크에 대한 모든오브젝트 참조가 제거되었는지 확인하기 위해 청크 계층에서 검사가 수행됩니다. 이를가비지 수집 검증이라고 합니다. 가비지 수집 프로세스를 통해 검증을 통과한 청크가재확보됩니다.

ECS 설치 계획


현재는 전체 청크 재확보만 지원됩니다. 청크의 공간이 재확보되려면 (다양한 오브젝트의) 청크에 포함된 모든 데이터가 삭제되어야 합니다.

사용자가 실수로 삭제한 경우 데이터가 손실되지 않도록 하기 위해 삭제 및 공간 재확보 프로세스의 단계가 연달아 수행되지 않습니다. 오브젝트 계층에서의 인덱스 업데이트 작업은 삭제되고 48시간 후 시작되는 반면, 가비지 수집 검증에서는 가비지 수집 대상으로 표시되기 전 마지막 78시간 동안 청크가 액세스되지 않았는지 확인합니다. 원격 사이트의 경우 운영 사이트에 비해 삭제를 처리하는 데 추가로 48시간이 더 지연됩니다.

ECS 설치 계획

가비지 수집 43

ECS 설치 계획


elastic cloud storage (ecs) · 2020-04-10 · elastic cloud storage (ecs) 3.0 버전 계획...

Documents