Dell ECS Administration Guide

Download

ECS

Version 3.4.0.1

Administration Guide

302-999-901

02 February 2020

Dell believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS-IS.” DELL MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. USE, COPYING, AND DISTRIBUTION OF ANY DELL SOFTWARE DESCRIBED IN THIS PUBLICATION REQUIRES AN APPLICABLE SOFTWARE LICENSE.

Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property of their respective owners. Published in the USA.

Dell EMC Hopkinton, Massachusetts 01748-9103 1-508-435-1000 In North America 1-866-464-7381 www.DellEMC.com

2 ECS Administration Guide

Figures

Tables

Chapter 1

Chapter 2

Overview 11

Introduction.......................................................................................................12

ECS platform.....................................................................................................12

ECS data protection.......................................................................................... 14

Configurations for availability, durability, and resilience........................15

ECS network..................................................................................................... 17

Load balancing considerations........................................................................... 17

Getting Started with ECS 19

Initial configuration........................................................................................... 20

View the Getting Started Task Checklist........................................................... 21

View the ECS Portal Dashboard........................................................................22

Upper-right menu bar...........................................................................22

View requests...................................................................................... 22

View capacity utilization.......................................................................22

View performance................................................................................ 23

View storage efficiency........................................................................23

View geo monitoring.............................................................................23

View node and disk health.................................................................... 23

View alerts........................................................................................... 23

Chapter 3

Chapter 4

Storage Pools, VDCs, and Replication Groups 25

Introduction to storage pools, VDCs, and replication groups.............................26

Working with storage pools in the ECS Portal...................................................27

Create a storage pool...........................................................................28

Edit a storage pool............................................................................... 29

Working with VDCs in the ECS Portal .............................................................. 29

Create a VDC for a single site............................................................... 31

Add a VDC to a federation.................................................................... 31

Edit a VDC........................................................................................... 33

Remove VDC from a Replication Group................................................35

Fail a VDC (PSO)................................................................................. 36

Guidelines to check failover and bootstrap process............................. 36

Working with replication groups in the ECS Portal............................................37

Create a replication group....................................................................38

Edit a replication group........................................................................ 40

Authentication Providers 41

Introduction to authentication providers........................................................... 42

Working with authentication providers in the ECS Portal..................................42

Considerations when adding Active Directory authentication providers...

ECS Administration Guide 3

Contents

AD or LDAP authentication provider settings....................................... 43

Add an AD or LDAP authentication provider.........................................46

Add a Keystone authentication provider...............................................46

Chapter 5

Chapter 6

Namespaces 49

Introduction to namespaces..............................................................................50

Namespace tenancy.............................................................................50

Working with namespaces in the ECS Portal..................................................... 51

Namespace settings............................................................................. 51

Create a namespace............................................................................ 55

Edit a namespace................................................................................. 57

Delete a namespace............................................................................. 58

Users and Roles 59

Introduction to users and roles......................................................................... 60

Users in ECS.....................................................................................................60

Management users...............................................................................60

Default management users.................................................................. 60

Object users......................................................................................... 61

Domain and local users.........................................................................62

User scope........................................................................................... 63

User tags............................................................................................. 64

Management roles in ECS.................................................................................64

System Administrator.......................................................................... 64

System Monitor................................................................................... 65

Namespace Administrator....................................................................65

Lock Administrator...............................................................................65

Tasks performed by role...................................................................... 65

Working with users in the ECS Portal............................................................... 68

Add an object user............................................................................... 70

Add a domain user as an object user..................................................... 71

Add domain users into a namespace.....................................................72

Create a local management user or assign a domain user or AD group to

a management role...............................................................................72

Assign the Namespace Administrator role to a user or AD group..........73

Chapter 7

4 ECS Administration Guide

Buckets 75

Introduction to buckets.....................................................................................76

Working with buckets in the ECS Portal........................................................... 76

Bucket settings.................................................................................... 76

Create a bucket....................................................................................79

Edit a bucket........................................................................................ 81

Set ACLs..............................................................................................82

Set bucket policies...............................................................................85

Create a bucket using the S3 API (with s3curl)................................................ 89

Bucket HTTP headers...........................................................................91

Bucket, object, and namespace naming conventions........................................ 92

S3 bucket and object naming in ECS....................................................92

OpenStack Swift container and object naming in ECS......................... 93

Atmos bucket and object naming in ECS..............................................93

CAS pool and object naming in ECS..................................................... 93

Disable unused services.................................................................................... 94

Contents

Chapter 8

Chapter 9

File Access 97

Introduction to file access.................................................................................98

ECS multi-protocol access................................................................................98

S3/NFS multi-protocol access to directories and files......................... 98

Multi-protocol access permissions....................................................... 99

Working with NFS exports in the ECS Portal................................................... 101

Working with user/group mappings in the ECS Portal..................................... 101

ECS NFS configuration tasks.......................................................................... 102

Create a bucket for NFS using the ECS Portal................................... 102

Add an NFS export using the ECS Portal............................................104

Add a user or group mapping using the ECS Portal.............................105

Configure ECS NFS with Kerberos security........................................106

Mount an NFS export example......................................................................... 112

Best practices for mounting ECS NFS exports....................................114

NFS access using the ECS Management REST API......................................... 114

NFS WORM (Write Once, Read Many)............................................................115

S3A support..................................................................................................... 118

Configuration at ECS.......................................................................... 118

Configuration at Ambari Node............................................................. 118

Geo-replication status......................................................................................119

Certificates 121

Introduction to certificates..............................................................................122

Generate certificates.......................................................................................122

Create a private key............................................................................123

Generate a SAN configuration............................................................ 123

Create a self-signed certificate...........................................................124

Create a certificate signing request....................................................126

Upload a certificate......................................................................................... 130

Authenticate with the ECS Management REST API........................... 130

Upload a management certificate........................................................131

Upload a data certificate for data access endpoints........................... 132

Add custom LDAP certificate..............................................................133

Verify installed certificates.............................................................................. 136

Verify the management certificate..................................................... 136

Verify the object certificate................................................................ 137

Chapter 10

ECS Settings 139

Introduction to ECS settings........................................................................... 140

Object base URL..............................................................................................140

Bucket and namespace addressing..................................................... 140

DNS configuration.............................................................................. 142

Add a Base URL.................................................................................. 142

Key Management.............................................................................................143

Native Key Management.....................................................................146

External Key Management..................................................................146

External Key Manager Configuration.................................................. 147

Key Rotation.......................................................................................152

EMC Secure Remote Services.........................................................................152

ESRS prerequisites ............................................................................153

Add an ESRS Server...........................................................................154

Verify that ESRS call home works...................................................... 155

Disable call home................................................................................ 155

Alert policy...................................................................................................... 156

ECS Administration Guide 5

Contents

New alert policy..................................................................................156

Event notification servers................................................................................157

SNMP servers.................................................................................... 157

Syslog servers.................................................................................... 162

Platform locking.............................................................................................. 165

Lock and unlock nodes using the ECS Portal...................................... 166

Lock and unlock nodes using the ECS Management REST API...........166

Licensing......................................................................................................... 167

Obtain the Dell EMC ECS license file..................................................168

Upload the ECS license file.................................................................168

Security...........................................................................................................168

Password............................................................................................169

Password Rules.................................................................................. 169

Sessions.............................................................................................. 171

User Agreement.................................................................................. 171

About this VDC................................................................................................ 172

Chapter 11

Chapter 12

ECS Outage and Recovery 173

Introduction to ECS site outage and recovery................................................. 174

TSO behavior...................................................................................................174

TSO behavior with the ADO bucket setting turned off........................174

TSO behavior with the ADO bucket setting turned on........................ 176

TSO considerations............................................................................ 182

NFS file system access during a TSO................................................. 182

PSO behavior.................................................................................................. 182

Recovery on disk and node failures..................................................................183

NFS file system access during a node failure...................................... 183

Data rebalancing after adding new nodes........................................................ 184

Advanced Monitoring 185

Advanced Monitoring...................................................................................... 186

View Advanced Monitoring Dashboards..............................................186

Share Advanced Monitoring Dashboards............................................ 192

Flux API........................................................................................................... 192

List of metrics for performance-related data......................................195

Dashboard API's to be deprecated or changed in the next release.................. 198

6 ECS Administration Guide

FIGURES

1 2 3 4 5 6 7 8 9 10 11 12 13

16 17 18 19

ECS component layers...................................................................................................... 13

Guide icon .........................................................................................................................21

Getting Started Task Checklist..........................................................................................21

Upper-right menu bar....................................................................................................... 22

Replication group spanning three sites and replication group spanning two sites.............. 27

Adding a subset of domain users into a namespace using one AD attribute.......................62

Adding a subset of domain users into a namespace using multiple AD attributes.............. 63

Bucket Policy Editor code view.........................................................................................86

Bucket Policy Editor tree view.......................................................................................... 86

Data encryption using system-generated keys................................................................ 145

Encryption of the master key in a geo-replicated environment........................................145

Native key management.................................................................................................. 146

Read/write request fails during TSO when data is accessed from non-owner site and

owner site is unavailable.................................................................................................. 175

Read/write request succeeds during TSO when data is accessed from owner site and non-

owner site is unavailable.................................................................................................. 176

Read/write request succeeds during TSO when ADO-enabled data is accessed from non-

owner site and owner site is unavailable...........................................................................177

Object ownership example for a write during a TSO in a two-site federation...................179

Read request workflow example during a TSO in a three-site federation.........................180

Passive replication in normal state................................................................................... 181

TSO for passive replication.............................................................................................. 181

ECS Administration Guide 7

Figures

8 ECS Administration Guide

TABLES

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

ECS supported data services.............................................................................................13

Erasure encoding requirements for regular and cold archives ........................................... 14

Storage overhead.............................................................................................................. 15

ECS data protection schemes........................................................................................... 16

Storage pool properties.....................................................................................................27

VDC properties................................................................................................................. 30

Replication Group properties............................................................................................ 38

Authentication provider properties....................................................................................42

AD or LDAP authentication provider settings.................................................................... 43

Keystone authentication provider settings........................................................................ 47

Namespace properties.......................................................................................................51

Namespace settings.......................................................................................................... 51

Default management users................................................................................................ 61

Tasks performed by ECS management user role...............................................................66

Object user properties...................................................................................................... 69

Management user properties............................................................................................ 69

Bucket settings................................................................................................................. 77

Bucket ACLs..................................................................................................................... 83

Bucket headers..................................................................................................................91

NFS export properties......................................................................................................101

ECS Management REST API calls for managing NFS access........................................... 114

Autocommit terms........................................................................................................... 115

Key Management properties............................................................................................148

Create cluster..................................................................................................................148

New external key servers.................................................................................................149

Key Management properties............................................................................................ 151

ESRS properties.............................................................................................................. 152

Syslog facilities used by ECS...........................................................................................164

Syslog severity keywords................................................................................................ 164

ECS Management REST API calls for managing node locking .........................................167

Password rules................................................................................................................ 169

Sessions........................................................................................................................... 171

User agreement................................................................................................................171

Advanced monitoring dashboards....................................................................................186

Advanced monitoring dashboard fields............................................................................ 186

Metrics for performance-related data............................................................................. 195

API - Remove.................................................................................................................. 198

API - Change................................................................................................................... 198

API - No change.............................................................................................................. 199

ECS Administration Guide 9

Tables

10 ECS Administration Guide

CHAPTER 1

Overview

Introduction........................................................................................................................... 12

ECS platform......................................................................................................................... 12

ECS data protection...............................................................................................................14

ECS network..........................................................................................................................17

Load balancing considerations................................................................................................17

ECS Administration Guide 11

Overview

Introduction

Dell EMC ECS provides a complete software-defined cloud storage platform that supports the storage, manipulation, and analysis of unstructured data on a massive scale on commodity hardware. You can deploy ECS as a turnkey storage appliance or as a software product that is installed on a set of qualified commodity servers and disks. ECS offers the cost advantages of a commodity infrastructure and the enterprise reliability, availability, and serviceability of traditional arrays.

ECS uses a scalable architecture that includes multiple nodes and attached storage devices. The nodes and storage devices are commodity components, similar to devices that are generally available, and are housed in one or more racks.

A rack and its components that are supplied by Dell EMC and that have preinstalled software, is referred to as an ECS referred to as a Dell EMC ECS

A rack, or multiple joined racks, with processing and storage that is handled as a coherent unit by the ECS infrastructure software is referred to as a

Data Center

Management users can access the ECS UI, which is referred to as the ECS Portal, to perform administration tasks. Management users include the System Administrator, Namespace Administrator, and System Monitor roles. Management tasks that can be performed in the ECS Portal can also be performed by using the ECS Management REST API.

ECS administrators can perform the following tasks in the ECS Portal:

Object users cannot access the ECS Portal, but can access the object store to read and write objects and buckets by using clients that support the following data access protocols:

For more information about object user tasks, see the

ECS Product Documentation page.

For more information about System Monitor tasks, see the the ECS Product Documentation page.

appliance

. A rack and commodity nodes that are not supplied by Dell EMC, is

software only solution

. Multiple racks are referred to as a

site

, and at the ECS software level as a

cluster

Virtual

(VDC).

Configure and manage the object store infrastructure (compute and storage resources) for object users.

Manage users, roles, and buckets within namespaces. Namespaces are equivalent to tenants.

Amazon Simple Storage Service (Amazon S3)

EMC Atmos

OpenStack Swift

ECS CAS (content-addressable storage)

ECS Data Access Guide

ECS Monitoring Guide

, available from the

, available from

ECS platform

The ECS platform is composed of the data services, portal, storage engine, fabric, infrastructure, and hardware component layers.

12 ECS Administration Guide

Figure 1 ECS component layers

Data

Services

Portal

Storage Engine

Fabric

Infrastructure

Hardware

ECS Software

Data services

The data services component layer provides support for access to the ECS object store through object, HDFS, and NFS v3 protocols. In general, ECS provides multi-protocol access, data that is ingested through one protocol can be accessed through another. For example, data that is ingested through S3 can be modified through Swift, NFS v3, or HDFS. This multiprotocol access has some exceptions due to protocol semantics and representations of how the protocol was designed.

The following table shows the object APIs and the protocols that are supported and that interoperate.

Overview

Table 1

ECS supported data services

Protocols Support Interoperability

Object S3 Additional capabilities such as byte range

updates and rich ACLS

Atmos Version 2.0 NFS (only path-based objects, not object ID

Swift V2 APIs, Swift, and Keystone v3

authentication

CAS SDK v3.1.544 and later Not applicable

HDFS Hadoop 2.6.2 compatibility S3, Swift*

NFS NFSv3 S3, Swift, Atmos (only path-based objects)

* When a bucket is enabled for file system access, permissions set using HDFS are in effect when you access the bucket as an NFS file system, and vice versa.

File systems (HDFS and NFS), Swift

style objects)

File systems (HDFS and NFS), S3

Portal

The ECS Portal component layer provides a Web-based GUI that allows you to manage, license, and provision ECS nodes. The portal has the following comprehensive reporting capabilities:

l Capacity utilization for each site, storage pool, node, and disk

l Performance monitoring on latency, throughput, transactions per second, and replication

progress and rate

l Diagnostic information, such as node and disk recovery status and statistics on hardware

and process health for each node, which helps identify performance and system bottlenecks

ECS Administration Guide 13

Overview

Storage engine

The storage engine component layer provides an unstructured storage engine that is responsible for storing and retrieving data, managing transactions, and protecting and replicating data. The storage engine provides access to objects ingested using multiple object storage protocols and the NFS and HDFS file protocols.

Fabric

The fabric component layer provides cluster health management, software management, configuration management, upgrade capabilities, and alerting. The fabric layer is responsible for keeping the services running and managing resources such as the disks, containers, firewall, and network. It tracks and reacts to environment changes such as failure detection and provides alerts that are related to system health. The 9069 and 9099 ports are public IP ports protected by Fabric Firewall manager. Port is not available outside of the cluster.

Infrastructure

The infrastructure component layer uses SUSE Linux Enterprise Server 12 as the base operating system for the ECS appliance, or qualified Linux operating systems for commodity hardware configurations. Docker is installed on the infrastructure to deploy the other ECS component layers. The Java Virtual Machine (JVM) is installed as part of the infrastructure because ECS software is written in Java.

Hardware

The hardware component layer is an ECS appliance or qualified industry standard hardware. For more information about ECS hardware, see the from the ECS Product Documentation page.

ECS data protection

ECS protects data within a site by mirroring the data onto multiple nodes, and by using erasure coding to break down data chunks into multiple fragments and distribute the fragments across nodes. Erasure coding (EC) reduces the storage overhead and ensures data durability and resilience against disk and node failures.

By default, the storage engine implements the Reed-Solomon 12 + 4 erasure coding scheme in which an object is broken into 12 data fragments and 4 coding fragments. The resulting 16 fragments are dispersed across the nodes in the local site. When an object is erasure-coded, ECS can read the object directly from the 12 data fragments without any decoding or reconstruction. The code fragments are used only for object reconstruction when a hardware failure occurs. ECS also supports a 10 + 2 scheme for use with cold storage archives to store objects that do not change frequently and do not require the more robust default EC scheme.

The following table shows the requirements for the supported erasure coding schemes.

Table 2

Erasure encoding requirements for regular and cold archives

ECS Hardware and Cabling Guide

, available

Use case Minimum

required nodes

Regular archive 4 16 32 1.33 12 + 4

Cold archive 6 12 24 1.2 10 + 2

Minimum required disks

Recommended disks

EC efficiency EC scheme

Sites can be federated, so that data is replicated to another site to increase availability and data durability, and to ensure that ECS is resilient against site failure. For three or more sites, in addition to the erasure coding of chunks at a site, chunks that are replicated to other sites are combined using a technique called XOR to provide increased storage efficiency.

14 ECS Administration Guide

Overview

The following table shows the storage efficiency that can be achieved by ECS where multiple sites are used.

Table 3 Storage overhead

Number of sites in replication group

1 1.33 1.2

2 2.67 2.4

3 2.00 1.8

4 1.77 1.6

5 1.67 1.5

6 1.60 1.44

7 1.55 1.40

8 1.52 1.37

Storage overhead

Default (Erasure Code: 12+4) Cold archive (Erasure Code:

10+2)

If you have one site, with erasure coding the object data chunks use more space (1.33 or 1.2 times storage overhead) than the raw data bytes require. If you have two sites, the storage overhead is doubled (2.67 or 2.4 times storage overhead) because both sites store a replica of the data, and the data is erasure coded at both sites. If you have three or more sites, ECS combines the replicated chunks so that, counter intuitively, the storage overhead reduces.

When one node is down in a four nodes system, ECS starts to rebuild the EC on priority to avoid DU. As one node is down, EC segment separates to other three nodes, which results in segment number being greater than the EC code number. If the down node comes back, things go back to normal. When another node with the most number of EC segments goes down, the DU window is as large as the node NA window, when the node does not recover it causes DL.

EC retiring feature converts unsaved EC chunk into three mirror copies chunk for data safety. However, EC retiring has some limitations:

It increases system capacity, and protection overhead from 1.33 to 3.

When there is no node down situation, EC retiring introduce unnecessary IO.

The feature applies to four nodes system. EC retiring does not automatically trigger, you need to trigger it on demand using an API through service console.

For a detailed description of the mechanism used by ECS to provide data durability, resilience, and availability, see the

ECS High Availability Design White Paper

Configurations for availability, durability, and resilience

Depending on the number of sites in the ECS system, different data protection schemes can increase availability and balance the data protection requirements against performance. ECS uses the replication group to configure the data protection schemes (see Introduction to storage pools,

VDCs, and replication groups on page 26). The following table shows the data protection schemes

that are available.

ECS Administration Guide 15

Overview

Table 4 ECS data protection schemes

Number of sites Data protection scheme

Local Protection Full Copy

Protection*

1 Yes Not applicable Not applicable Not applicable

2 Yes Always Not applicable Not applicable

3 or more Yes Optional Normal Optional

* Full Copy Protection can be selected with Active. Full Copy Protection is not available if Passive is selected.

Active Passive

Local Protection

Data is protected locally by using triple mirroring and erasure coding which provides resilience against disk and node failures, but not against site failure.

Full Copy Protection

When the Replicate to All Sites setting is turned on for a replication group, the replication group makes a full readable copy of all objects to all sites within the replication group. Having full readable copies of objects on all VDCs in the replication group provides data durability and improves local performance at all sites at the cost of storage efficiency.

Active

Active is the default ECS configuration. When a replication group is configured as Active, data is replicated to federated sites and can be accessed from all sites with strong consistency. If you have two sites, full copies of data chunks are copied to the other site. If you have three or more sites, the replicated chunks are combined (XOR'ed) to provide increased storage efficiency.

When data is accessed from a site that is not the owner of the data, until that data is cached at the non-owner site, the access time increases. Similarly, if the owner site that contains the primary copy of the data fails, and if you have a global load balancer that directs requests to a non-owner site, the non-owner site must recreate the data from XOR'ed chunks, and the access time increases.

Passive

The Passive configuration includes two, three, or four active sites with an additional passive site that is a replication target (backup site). The minimum number of sites for a Passive configuration is three (two active, one passive) and the maximum number of sites is five (four active, one passive). Passive configurations have the same storage efficiency as Active configurations. For example, the Passive three-site configuration has the same storage efficiency as the Active three-site configuration (2.0 times storage overhead).

In the Passive configuration, all replication data chunks are sent to the passive site and XOR operations occur only at the passive site. In the Active configuration, the XOR operations occur at all sites.

If all sites are on-premise, you can designate any of the sites as the replication target.

If there is a backup site hosted off-premise by a third-party data center, ECS automatically selects it as the replication target when you create a Passive geo replication group (see

Create a replication group on page 38). If you want to change the replication target from a

hosted site to an on-premise site, you can do so using the ECS Management REST API.

16 ECS Administration Guide

ECS network

ECS network infrastructure consists of top of rack switches allowing for the following types of network connections:

Public network – connects ECS nodes to your organization's network, providing data.

Internal private network – manages nodes and switches within the rack and across racks.

For more information about ECS networking, see the

Paper

CAUTION It is required to have connections from the customer's network to both front end

switches (rabbit and hare) in order to maintain the high availability architecture of the ECS appliance. If the customer chooses not to connect to their network in the required HA manner, there is no guarantee of high data availability for the use of this product.

Load balancing considerations

It is recommended that a load balancer is used in front of ECS.

In addition to distributing the load across ECS cluster nodes, a load balancer provides High Availability (HA) for the ECS cluster by routing traffic to healthy nodes. Where network separation is implemented, and data and management traffic are separated, the load balancer must be configured so that user requests, using the supported data access protocols, are balanced across the IP addresses of the data network. ECS Management REST API requests can be made directly to a node IP on the management network or can be load balanced across the management network for HA.

The load balancer configuration is dependent on the load balancer type. For information about tested configurations and best practice, contact your customer support representative.

Overview

ECS Networking and Best Practices White

ECS Administration Guide 17

Overview

18 ECS Administration Guide

CHAPTER 2

Getting Started with ECS

Initial configuration................................................................................................................20

Log in to the ECS Portal........................................................................................................20

View the Getting Started Task Checklist............................................................................... 21

View the ECS Portal Dashboard............................................................................................ 22

ECS Administration Guide 19

Getting Started with ECS

Initial configuration

The initial configuration steps that are required to get started with ECS include logging in to the ECS Portal for the first time, using the ECS Portal Getting Started Task Checklist and Dashboard, uploading a license, and setting up an ECS virtual data center (VDC).

About this task

To initially configure ECS, the root user or System Administrator must at a minimum:

Procedure

1. Upload an ECS license.

See Licensing on page 167.

2. Select a set of nodes to create at least one storage pool.

See Create a storage pool on page 28.

3. Create a VDC.

See Create a VDC for a single site on page 31.

4. Create at least one replication group.

See Create a replication group on page 38.

a. Optional: Set authentication.

You can add Active Directory (AD), LDAP, or Keystone authentication providers to ECS to enable users to be authenticated by systems external to ECS. See Introduction to

authentication providers on page 42.

5. Create at least one namespace. A namespace is the equivalent of a tenant.

See Create a namespace on page 55.

a. Optional: Create object and/or management users.

See Working with users in the ECS Portal on page 68.

6. Create at least one bucket.

See Create a bucket on page 79.

After you configure the initial VDC, if you want to create an additional VDC and federate it with the first VDC, see Add a VDC to a federation on page 31.

Log in to the ECS Portal

Log in to the ECS Portal to set up the initial configuration of a VDC. Log in to the ECS Portal from the browser by specifying the IP address or fully qualified domain name (FQDN) of any node, or the load balancer that acts as the front end to ECS. The login procedure is described below.

Before you begin

Logging in to the ECS Portal requires the System Administrator, System Monitor, Lock Administrator (emcsecurity user), or Namespace Administrator role.

Note:

configure the system, only with the System Administrator role.

20 ECS Administration Guide

You can login to the ECS Portal for the first time with any valid login. However, you can

Procedure

1. Type the public IP address of the first node in the system, or the address of the load balancer that is configured as the front-end, in the address bar of your browser: https://<node1_public_ip>.

2. Log in with the default root credentials:

User Name: root

Password: ChangeMe

You are prompted to change the password for the root user immediately.

3. After you change the password at first login, click Save.

You are logged out and the ECS login screen is displayed.

4. Type the User Name and Password.

5. To log out of the ECS Portal, in the upper-right menu bar, click the arrow beside your user name, and then click logout.

View the Getting Started Task Checklist

Getting Started with ECS

The Getting Started Task Checklist in the ECS Portal guides you through the initial ECS configuration. The checklist appears when you first log in and when the portal detects that the initial configuration is not complete. The checklist automatically appears until you dismiss it. On any ECS Portal page, in the upper-right menu bar, click the Guide icon to open the checklist.

Figure 2

Guide icon

The Getting Started Task Checklist displays in the portal.

Figure 3

Getting Started Task Checklist

1. The current step in the checklist.

2. An optional step. This step does not display a check mark even if you have completed the step.

3. Information about the current step.

4. Available actions.

5. Dismiss the checklist.

A completed step appears in green color.

ECS Administration Guide 21

Getting Started with ECS

A completed checklist gives you the option to browse the list again or recheck your configuration.

View the ECS Portal Dashboard

The ECS Portal Dashboard provides critical information about the ECS processes on the VDC you are currently logged in to.

The Dashboard is the first page you see after you log in. The title of each panel (box) links to the portal monitoring page that shows more detail for the monitoring area.

Upper-right menu bar

The upper-right menu bar appears on each ECS Portal page.

Figure 4 Upper-right menu bar

Menu items include the following icons and menus:

1. The Alert icon displays a number that indicates how many unacknowledged alerts are pending for the current VDC. The number displays 99+ if there are more than 99 alerts. You can click the Alert icon to see the Alert menu, which shows the five most recent alerts for the current VDC.

2. The Help icon brings up the online documentation for the current portal page.

3. The Guide icon brings up the Getting Started Task Checklist.

4. The VDC menu displays the name of the current VDC. If your AD or LDAP credentials allow you to access more than one VDC, you can switch the portal view to the other VDCs without entering your credentials.

5. The User menu displays the current user and allows you to log out. The User menu displays the last login time for the user.

View requests

The Requests panel displays the total requests, successful requests, and failed requests.

Failed requests are organized by system error and user error. User failures are typically HTTP 400 errors. System failures are typically HTTP 500 errors. Click Requests to see more request metrics.

Request statistics do not include replication traffic.

View capacity utilization

The Capacity Utilization panel displays the total, used, available, reserved, and percent full capacity.

Capacity amounts are shown in gibibytes (GiB) and tibibytes (TiB). One GiB is approximately equal to 1.074 gigabytes (GB). One TiB is approximately equal to 1.1 terabytes (TB).

The Used capacity indicates the amount of capacity that is in use. Click Capacity Utilization to see more capacity metrics.

The capacity metrics are available in the left menu.

22 ECS Administration Guide

View performance

The Performance panel displays how network read and write operations are currently performing, and the average read/write performance statistics over the last 24 hours for the VDC.

Click Performance to see more comprehensive performance metrics.

View storage efficiency

The Storage Efficiency panel displays the efficiency of the erasure coding (EC) process.

The chart shows the progress of the current EC process, and the other values show the total amount of data that is subject to EC, the amount of EC data waiting for the EC process, and the current rate of the EC process. Click Storage Efficiency to see more storage efficiency metrics.

View geo monitoring

The Geo Monitoring panel displays how much data from the local VDC is waiting for georeplication, and the rate of the replication.

Recovery Point Objective (RPO) refers to the point in time in the past to which you can recover. The value is the oldest data at risk of being lost if a local VDC fails before replication is complete. Failover Progress shows the progress of any active failover that is occurring in the federation involving the local VDC. Bootstrap Progress shows the progress of any active process to add a new VDC to the federation. Click Geo Monitoring to see more geo-replication metrics.

Getting Started with ECS

View node and disk health

The Node & Disks panel displays the health status of disks and nodes.

A green check mark beside the node or disk number indicates the number of nodes or disks in good health. A red x indicates bad health. Click Node & Disks to see more hardware health metrics. If the number of bad disks or nodes is a number other than zero, clicking on the count takes you to the corresponding Hardware Health tab (Offline Disks or Offline Nodes) on the System Health page.

View alerts

The Alerts panel displays a count of critical alerts and errors.

Click Alerts to see the full list of current alerts. Any Critical or Error alerts are linked to the Alerts tab on the Events page where only the alerts with a severity of Critical or Error are filtered and displayed.

ECS Administration Guide 23

Getting Started with ECS

24 ECS Administration Guide

CHAPTER 3

Storage Pools, VDCs, and Replication Groups

Introduction to storage pools, VDCs, and replication groups................................................. 26

Working with storage pools in the ECS Portal....................................................................... 27

Working with VDCs in the ECS Portal .................................................................................. 29

Working with replication groups in the ECS Portal................................................................ 37

ECS Administration Guide 25

Storage Pools, VDCs, and Replication Groups

Introduction to storage pools, VDCs, and replication groups

This topic provides conceptual information on storage pools, virtual data centers (VDCs), and replication groups and the following topics describe the operations required to configure them:

Working with storage pools at the ECS Portal

Working with VDCs at the ECS Portal

Working with replication groups at the ECS Portal

The storage that is associated with a VDC must be assigned to a storage pool and the storage pool must be assigned to one or more replication groups to allow the creation of buckets and objects.

A storage pool can be associated with more than one replication group. A best practice is to have a single storage pool for a site. However, you can have as many storage pools as required, with a minimum of four nodes (and 16 disks) in each pool.

You might need to create more than one storage pool at a site for the following reasons:

The storage pool is used for Cold Archive. The erasure coding scheme used for cold archive uses 10+2 coding rather than the default ECS 12+4 scheme.

A tenant requires the data to be stored on separate physical media.

A storage pool must have a minimum of four nodes and must have three or more nodes with more than 10% free capacity in order to allow writes. This reserved space is required to ensure that ECS does not run out of space while persisting system metadata. If this criteria is not met, the write will fail. The ability of a storage pool to accept writes does not affect the ability of other pools to accept writes. For example, if you have a load balancer that detects a failed write, the load balancer can redirect the write to another VDC.

The replication group is used by ECS for replicating data to other sites so that the data is protected and can be accessed from other, active sites. When you create a bucket, you specify the replication group it is in. ECS ensures that the bucket and the objects in the bucket are replicated to all the sites in the replication group.

ECS can be configured to use more than one replication scheme, depending on the requirements to access and protect the data. The following figure shows a replication group (RG 1) that spans all three sites. RG 1 takes advantage of the XOR storage efficiency provided by ECS when using three or more sites. In the figure, the replication group that spans two sites (RG 2), contains full copies of the object data chunks and does not use XOR'ing to improve storage efficiency.

26 ECS Administration Guide

VDC C

VDC A

VDC B

SP 1

VDC C

SP 2

Federation

RG 1 (SP 1,2,3)

RG 2 (SP 1,3)

Rack 1

RG 1

SP 3

Storage Pools, VDCs, and Replication Groups

Figure 5 Replication group spanning three sites and replication group spanning two sites

The physical storage that the replication group uses at each site is determined by the storage pool that is included in the replication group. The storage pool aggregates the disk storage of each of the minimum of four nodes to ensure that it can handle the placement of erasure coding fragments. A node cannot exist in more than one storage pool. The storage pool can span racks, but it is always within a site.

Working with storage pools in the ECS Portal

You can use storage pools to organize storage resources based on business requirements. For example, if you require physical separation of data, you can partition the storage into multiple storage pools.

You can use the Storage Pool Management page available from Manage > Storage Pools to view the details of existing storage pools, to create storage pools, and to edit existing storage pools. You cannot delete storage pools in this release.

Table 5

Field Description

Name The name of the storage pool.

Nodes The number of nodes that are assigned to the storage pool.

Status The state of the storage pool and of the nodes.

Host The fully qualified host name that is assigned to the node.

Data IP The public IP address that is assigned to the node or the data IP address in network separation

Rack ID The name that is assigned to the rack that contains the nodes.

Actions The actions that can be completed for the storage pool.

Storage pool properties

Ready: At least four nodes are installed and all nodes are in the ready to use state.

Not Ready: A node in the storage pool is not in the ready to use state.

Partially Ready: Less than four nodes, and all nodes are in the ready to use state.

environment.

ECS Administration Guide 27

Storage Pools, VDCs, and Replication Groups

Table 5 Storage pool properties (continued)

Field Description

Edit: Change the storage pool name or modify the set of nodes that are included in the storage pool.

Delete: Used by Customer Support to delete the storage pool. System Administrators or root users should not attempt to delete the storage pool. If you attempt this operation in the ECS Portal, you receive an error message that states this operation is not supported. If you must delete a storage pool, contact your customer support representative.

Cold Storage A storage pool that is specified as Cold Storage. Cold Storage pools use an erasure coding

(EC) scheme that is more efficient for infrequently accessed objects. Cold Storage is also known as a Cold Archive. After a storage pool is created, this setting cannot be changed.

Create a storage pool

Storage pools must contain a minimum of four nodes. The first storage pool that is created is known as the system storage pool because it stores system metadata.

Before you begin

This operation requires the System Administrator role in ECS.

Procedure

1. In the ECS Portal, select Manage > Storage Pools.

2. On the Storage Pool Management page, click New Storage Pool.

3. On the New Storage Pool page, in the Name field, type the storage pool name (for example, StoragePool1).

4. In the Cold Storage field, specify if this storage pool is Cold Storage. Cold storage contains infrequently accessed data. The ECS data protection scheme for cold storage is optimized to increase storage efficiency. After a storage pool is created, this setting cannot be changed.

Note:

Cold storage requires a minimum hardware configuration of six nodes. For more

information, see ECS data protection on page 14.

5. From the Available Nodes list, select the nodes to add to the storage pool.

a. To select nodes one-by-one, click the + icon beside each node.

b. To select all available nodes, click the + icon at the top of the Available Nodes list.

c. To narrow the list of available nodes, in the search field, type the public IP address for

the node or the host name.

6. In the Available Capacity Alerting fields, select the applicable available capacity thresholds that will trigger storage pool capacity alerts:

a. In the Critical field, select 10 %, 15 %, or No Alert.

b. In the Error field, select 20 %, 25 %, 30 %, or No Alert.

28 ECS Administration Guide

For example, if you select 10 %, that means a Critical alert will be triggered when the available storage pool capacity is less than 10 percent.

For example, if you select 25 %, that means an Error alert will be triggered when the available storage pool capacity is less than 25 percent.

7. Click Save.

8. Wait 10 minutes after the storage pool is in the Ready state before you perform other

Edit a storage pool

You can change the name of a storage pool or change the set of nodes included in the storage pool.

Storage Pools, VDCs, and Replication Groups

c. In the Warning field, select 35 %, 40 %, or No Alert.

For example, if you select 40 %, that means a Warning alert will be triggered when the available storage pool capacity is less than 40 percent.

When a capacity alert is generated, a call home alert is also generated that alerts ECS customer support that the ECS system is reaching its capacity limit.

configuration tasks, to allow the storage pool time to initialize.

If you receive the following error, wait a few more minutes before you attempt any further configuration. Error 7000 (http: 500): An error occurred in the API

Service. An error occurred in the API service.Cause: error insertVdcInfo. Virtual Data Center creation failure may occur when Data Services has not completed initialization.

Before you begin

This operation requires the System Administrator role in ECS.

Procedure

1. In the ECS Portal, select Manage > Storage Pools.

2. On the Storage Pool Management page, locate the storage pool you want to edit in the table. Click Edit in the Actions column beside the storage pool you want to edit.

3. On the Edit Storage Pool page:

To modify the storage pool name, in the Name field, type the new name.

To modify the nodes included in the storage pool:

In the Selected Nodes list, remove an existing node in the storage pool by clicking the - icon beside the node.

In the Available Nodes list, add a node to the storage pool by clicking the + icon beside the node.

To modify the available capacity thresholds that will trigger storage pool capacity alerts, select the applicable alert thresholds in the Available Capacity Alerting fields.

4. Click Save.

Working with VDCs in the ECS Portal

An ECS virtual data center (VDC) is the top-level resource that represents the collection of ECS infrastructure components to manage as a unit.

You can use the Virtual Data Center Management page available from Manage > Virtual Data Center to view VDC details, to create a VDC, to edit an existing VDC, to update endpoints in multiple VDCs, delete VDCs, and to federate multiple VDCs for a multisite deployment. The following example shows the Virtual Data Center Management page for a federated deployment. It is configured with two VDCs named vdc1 and vdc2.

ECS Administration Guide 29

Storage Pools, VDCs, and Replication Groups

Table 6 VDC properties

Field Description

Name The name of the VDC.

Type The type of VDC is automatically set and can be either Hosted or On-Premise.

A Hosted VDC is hosted off-premise by a third-party data center (a backup site).

Replication Endpoints Endpoints for communication of replication data between VDCs when an ECS federation is

configured.

By default, replication traffic runs between VDCs over the public network. By default the public network IP address for each node is used as the Replication Endpoints.

If a separate replication network is configured, the network IP address that is configured for replication traffic of each node is used as the Replication Endpoints.

If a load balancer is configured to distribute the load between the replication IP addresses of the nodes, the address that is configured on the load balancer is displayed.

Management Endpoints

Endpoints for communication of management commands between VDCs when an ECS federation is configured.

By default, management traffic runs between VDCs over the public network. By default the public network IP address for each node is used as the Management Endpoints.

If a separate management network is configured, the network IP address that is configured for management traffic of each node is used for the Management Endpoints.

Status The state of the VDC.

Online

Permanently Failed: The VDC was deleted.

Actions The actions that can be completed for the VDC.

Edit: Change the name of a VDC, the VDC access key, and the VDC replication and management endpoints.

Delete: Delete the VDC. The delete operation triggers permanent failover of the VDC, You cannot add the VDC again by using the same name. You cannot delete a VDC that is part of a replication group until you first remove it from the replication group. You cannot delete a VDC when you are logged in to the VDC you are trying to delete.

Fail this VDC:

WARNING Failing a VDC is permanent. The site cannot be added back.

Note: Fail this VDC is available when there is more than one VDC.

30 ECS Administration Guide

Ensure that Geo replication is up-to-date. Stop all writes to the VDC.

Ensure that all nodes of the VDC are shutdown.

Replication to/from the VDC will be disabled for all replication groups.

Recovery is initiated only when the VDC is removed from the replication group. Proceed to do that next.

This VDC will display a status of Permanently Failed in any replication group to which it belongs.

To Reconstruct this VDC, it must be added as a new site. Any previous data will be lost, as that data will have failed over to other sites in the federation.

Create a VDC for a single site

You can create a VDC for a single-site deployment, or when you create the first VDC in a multi-site federation.

Before you begin

This operation requires the System Administrator role in ECS.

Ensure that one or more storage pools are available and in the Ready state.

Procedure

1. In the ECS Portal, select Manage > Virtual Data Center.

2. On the Virtual Data Center Management page, click New Virtual Data Center.

3. On the New Virtual Data Center page, in the Name field, type the VDC name (for example:

VDC1).

4. To create an access key for the VDC, either:

Type the VDC access key value in the Key field, or

Click Generate to generate a VDC access key.

The VDC Access Key is used as a symmetric key for encrypting replication traffic between VDCs in a multi-site federation.

Storage Pools, VDCs, and Replication Groups

5. In the Replication Endpoints field, type the replication IP address of each node assigned to the VDC. Type them as a comma-separated list.

By default replication traffic runs on the public network. Therefore by default, the IP address configured for the public network on each node is entered here. If the replication network was separated from the public or management network, each node's replication IP address is entered here.

If a load balancer is configured to distribute the load between the replication IP addresses of the nodes, the address configured on the load balancer is displayed.

6. In the Management Endpoints field, type the management IP address of each node assigned to the VDC. Type them as a comma-separated list.

By default management traffic runs on the public network. Therefore by default, the IP address configured for the public network on each node is entered here. If the management network was separated from the public or replication network, each node's management IP address is entered here.

7. Click Save.

When the VDC is created, ECS automatically sets the VDC's Type to either On-Premise or Hosted.

A Hosted VDC is hosted off-premise by a third-party data center (a backup site).

Add a VDC to a federation

You can add a VDC to an existing VDC (for example, VDC1) to create a federation. It is important when you perform this procedure that you DO NOT create a VDC on the rack you want to add. Retrieve only the VDC Access Key from it, and then proceed from the existing VDC (VDC1).

Before you begin

Obtain the ECS Portal credentials for the root user, or for a user with System Administrator credentials, to log in to both VDCs.

ECS Administration Guide 31

Storage Pools, VDCs, and Replication Groups

In an ECS geo-federated system with multiple VDCs, the IP addresses for the replication and management networks are used for connectivity of replication and management traffic between VDC endpoints. If the VDC you are adding to the federation is configured with:

Replication or management traffic running on the public network (default), you need the public network IP address that is used by each node.

Separate networks for replication or management traffic, you need the IP addresses of the separated network for each node.

If a load balancer is configured to distribute the load between the replication IP addresses of the nodes, you need the IP address that is configured on the load balancer.

Ensure that the VDC you are adding has a valid ECS license that is uploaded and has at least one storage pool in the Ready state.

Procedure

1. On the VDC you want to add (for example, VDC2):

a. Log in to the ECS Portal.

b. In the ECS Portal, select Manage > Virtual Data Center.

c. On the Virtual Data Center Management page, click Get VDC Access Key.

d. Select the key, and press Ctrl-c to copy it.

Important: You are only obtaining and copying the key of the VDC you want to add, you are not creating a VDC on the site you are logged in to.

e. Log out of the ECS Portal on the site you are adding.

2. On the existing VDC (for example, VDC1):

a. Log in to the ECS Portal.

b. Select Manage > Virtual Data Center.

c. On the Virtual Data Center Management page, click New Virtual Data Center.

d. On the New Virtual Data Center page, in the Name field, type the name of the new VDC

you are adding.

e. Click in the Key field, and then press Ctrl-v to paste the access key you copied from

the VDC you are adding (from step 1d).

3. In the Replication Endpoints field, enter the replication IP address of each node in the storage pools that are assigned to the site you are adding (for example, VDC2). Use the:

Public IP addresses for the network if the replication network has not been separated.

IP address configured for replication traffic, if you have separated the replication network.

If a load balancer is configured to distribute the load between the replication IP addresses of the nodes, the replication endpoint is the IP address that is configured on the load balancer.

Use a comma to separate IP addresses within the text box.

4. In the Management Endpoints fields, enter the management IP address of each node in the storage pools that are assigned to the site you are adding (for example, VDC2). Use the:

Use a comma to separate IP addresses within the text box.

32 ECS Administration Guide

Public IP addresses for the network if the management network has not been separated.

IP address configured for management traffic, if you have separated the management network.

Storage Pools, VDCs, and Replication Groups

5. Click Save.

Results

The new VDC is added to the existing federation. The ECS system is now a geo-federated system. When you add the VDC to the federation, ECS automatically sets the type of the VDC to either On-Premise or Hosted.

After you finish

Note: If External Key Manager (EKM) feature is activated for the federation, and then you

have to add the necessary VDC to EKM mapping for the newly added VDC in the key management section.

To complete the configuration of the geo-federated system, you must create a replication group that spans multiple VDCs so that data can be replicated between the VDCs. To do this, you must ensure that:

You have created storage pools in the VDCs that will be in the replication group (see Create a

storage pool on page 28).

You create the replication group, selecting the VDCs that provide the storage pools for the replication group (see Create a replication group on page 38).

After you create the replication group, you can monitor the copying of user data and metadata to the new VDC that you added to the replication group on the Monitor > Geo Replication > Geo Bootstrap Processing tab. When all the user data and metadata are successfully replicated to the new VDC, the Bootstrap State is Done and the Bootstrap Progress (%) is

100 on all the VDCs.

Edit a VDC

You can change the name, the access key, or the replication and management endpoints of the VDC.

Before you begin

This operation requires the System Administrator role in ECS.

If you have an ECS geo-federated system and you want to update VDC endpoints after you:

separated the replication or management networks for a VDC, or

changed the IP addresses of multiple nodes in a VDC

you must use the update endpoints in multiple VDCs procedure. If you attempt to update the VDC endpoints by editing the settings for an individual VDC from the Edit Virtual Data Center <

name

> page, you will lose connectivity between VDCs.

VDC

Procedure

1. In the ECS Portal, select Manage > Virtual Data Center.

2. On the Virtual Data Center Management page, locate the VDC you want to edit in the table. Click Edit in the Actions column beside the VDC you want to edit.

3. On the Edit Virtual Data Center <

to modify the VDC name, in the Name field, type the new name.

to modify the VDC access key for the node you are logged into, in the Key field, type the

VDC name

> page:

new key value, or click Generate to generate a new VDC access key.

To modify the replication and management endpoints:

ECS Administration Guide 33

Storage Pools, VDCs, and Replication Groups

Option Description

for a single VDC that is not part of an ECS federation

for a VDC that is part of an ECS federation, and for which you have separated the replication or management networks or changed multiple node IP addresses

a. In the Replication Endpoints field, enter the IP addresses for the replication endpoints.

Use the:

Public IP addresses for the network, if you did not separate the replication network.

IP address configured for replication traffic, if you separated the replication network.

IP address configured on the load balancer, if you configured a load balancer to distribute the load between the replication IP addresses of the nodes.

b. In the Management Endpoints field, enter the IP addresses for the management

endpoints. Use the:

Public IP addresses for the network, if you did not separate the management network.

IP address configured for management traffic, if you separated the management network.

Use a comma to separate IP addresses within the text boxes.

Do not modify endpoints on the Edit Virtual Data Center < modify the endpoints on the Update All VDC Endpoints page as described in Update

replication and management endpoints in multiple VDCs on page 34.

VDC name

> page, you must

4. Click Save.

Update replication and management endpoints in multiple VDCs

In an ECS geo-federated system, you can use the Update All VDC Endpoints page to update replication and management endpoints in multiple VDCs.

Before you begin

This operation requires the System Administrator role in ECS.

You must update the VDC endpoints from the Update All VDC Endpoints page after you have:

Separated the replication or management networks of a VDC in an existing ECS federation.

Changed the IP address of multiple nodes in a VDC.

If you attempt to update the VDC endpoints by editing the settings for an individual VDC from the

Edit Virtual Data Center <

About this task

In an ECS geo-federated system with multiple VDCs, the IP addresses configured for ECS replication and management networks are used for connectivity of replication and management traffic between VDC endpoints. By default, all of the ECS replication and management traffic is configured to run on the ECS public network, and by default the IP addresses of the public network configured for each node are used as the replication and management endpoints.

Optionally, you can separate the replication and management networks, and therefore must reconfigure the replication and management endpoints for a VDC.

VDC name

> page, you will lose connectivity between VDCs.

Procedure

1. In the ECS Portal, select Manage > Virtual Data Center.

2. On the Virtual Data Center Management page, click Update All VDC Endpoints.

34 ECS Administration Guide

3. On the Update All VDC Endpoints page, if the replication network was separated, or if the IP address for the node was changed, type the replication IP address of each node in the Replication Endpoints field for the VDC. Type them as a comma-separated list.

4. On the Update All VDC Endpoints page, if the management network was separated, or if the IP address for the node was changed, type the management IP address of each node in the Management Endpoints field for the VDC. Type them as a comma-separated list.

5. Click Update Endpoints.

Remove VDC from a Replication Group

You can remove a VDC from a replication group (RG) in a multi VDC federation without affecting the VDC or other RGs associated with the VDC. Removing VDC from RG no longer initiates PSO. Removing a VDC from RG initiates recovery.

Before you begin

This operation requires the System Administrator role in ECS.

Restrictions to Remove VDC

You cannot log in to a VDC and remove the same VDC.

If any VDC in the replication group is off, you cannot remove a VDC .

If it is the only VDC in a replication group, you cannot remove a VDC.

If any VDC in the replication group has Bootstrap or Failover process in progress, you cannot remove a VDC.

You cannot remove more than one VDC at a time.

If the system is not fully upgraded, you cannot remove a VDC.

You cannot delete a VDC when it is still associated with any replication groups.

It is a prerequisite to stop any workload to the system and wait until data replication is complete between the VDCs.

Storage Pools, VDCs, and Replication Groups

Note:

The time taken to complete data replication depends on the workload and network

condition.

Procedure

1. Log in to the ECS Portal.

2. In the ECS Portal, select Manage > Virtual Data Center, check to ensure the VDC you want to remove is online and working correctly.

3. Select Manage > Replication Group and click Edit for the corresponding replication group.

The Edit Replication Group window opens.

4. Click Delete... for the VDC you want to delete.

Confirm Remove VDC window opens. Read all the important notes before you click the check box to confirm removal of VDC. Click ok.

5. Click Save in the Replication Group Management Window.

6. Select Monitoring > Geo Replication > Failover Processing. The Failover Progress column must show 100% done on all remaining VDCs in the replication group.

Refer to Guidelines to check failover and bootstrap process procedure for details.

7. Select Monitoring > Geo Replication > Bootstrap Processing. The Bootstrap Progress (%) column must show 100% done on all remaining VDCs in the replication group.

The time that is taken for both the Failover process and the Bootstrap Process to complete depends on the amount of data on the failed VDC.

ECS Administration Guide 35

Storage Pools, VDCs, and Replication Groups

Refer to Guidelines to check failover and bootstrap process procedure for details.

After you finish

Note: You may have to wait for 5 to 10 minutes before the Failover and the Bootstrap process

show the status on the page.

Fail a VDC (PSO)

Failing a VDC or permanent site outage (PSO) is done from the VDC level. Removing a VDC from replication group (RG) initiates recovery, but failed VDC does not initiate recovery.

Before you begin

This operation requires the System Administrator role in ECS.

Stop any workload to the system and wait until data replication is complete between the VDCs.

Note: The time taken to complete data replication depends on the workload and network

condition.

Wait for more than 15 minutes after you power off the VDC for the system to confirm that the VDC is off. For unplanned PSO, ensure the VDC is not accessible for more than 15 minutes.

Restrictions to fail a VDC

You cannot fail a VDC that is powered on. If a VDC is powered off for less than 15 minutes, the system does not detect that the VDC is off, which results in Fail VDC operation to fail.

You cannot fail a VDC if it is the only VDC in a replication group.

Procedure

1. Log in to the ECS Portal.

2. In the ECS Portal, select Manage > Virtual Data Center. Click Edit and select Fail this VDC. Wait for a few minutes to ensure the VDC status shows Permanent Site Outage.

Refer to the restrictions in the prerequisites section for limitations of this operation.

3. Select Manage > Replication Group, click Edit and remove the failed VDC from each replication group.

Refer to the restrictions in the prerequisites section for limitations of this operation.

4. Select Monitoring > Geo Replication > Failover Processing. The Failover Progress column must show 100% done on all remaining VDCs in the replication group.

5. Select Monitoring > Geo Replication > Bootstrap Processing. The Bootstrap Progress (%) column must show 100% done on all remaining VDCs in the replication group.

The time that is taken for both the Failover process and the Bootstrap Process to complete depends on the amount of data on the failed VDC.

Note:

You may have to wait for 5 to 10 minutes before the Failover and the Bootstrap

process show the status on the page.

6. Select Manage > Virtual Data Center, click Edit and delete the Permanently failed VDC. If the VDC is still associated with any of the replication groups, this operation fails.

Guidelines to check failover and bootstrap process

The following section describes the procedure to check the failover and bootstrap process completion:

Before you begin

This operation requires the System Administrator role in ECS.

36 ECS Administration Guide

Storage Pools, VDCs, and Replication Groups

Procedure

1. Log in to each of the VDC in the replication group (RG) and check the following:

2. Select Monitoring > Geo Replication > Failover Processing and check the failover process column for the VDCs. One more row which shows the failed VDC and the failover process is shown. The Failover Progress column shows 100% when the process is complete.

3. Select Monitoring > Geo Replication > Bootstrap Processing. Addition rows for each of the remaining VDCs except for the VDC you have logged in is shown. The process is complete when bootstrap process shows 100%.

Example 1 Checking failover and bootstrap process in different cases

2 Site Case (We have vdc1 and vdc2. Vdc2 is removed from the RG).

Failover process: According to the guidelines in the procedure, you see that one other row shows that VDC2 as failed and the failover status from VDC1's UI.

Bootstrap process: According to the guidelines, there are no other remaining zones in the RG except VDC1. So no addition row is shown.

3 Site Case (We have vdc1, vdc2 and vdc3. Vdc3 is removed from the RG)

Failover process: According to the guidelines in the procedure, you see that one other row shows that VDC3 as failed and the failover status from VDC1 and VDC2's UI.

Bootstrap process: According to the guidelines, if you log in to VDC1, VDC2 is the remaining zone. As a result, you can see an extra row showing the bootstrap process of VDC2. Similarly, you can see an extra row showing bootstrap process of VDC1 while you log in to VDC2.

4 Site Case (We have vdc1, vdc2, vdc3 and vdc4. Vdc4 is removed from the RG)

Failover process: According to the guidelines in the procedure, you see that one other row shows that VDC4 as failed and the failover status from VDC1, VDC2, and VDC3's UI.

Bootstrap process:

If you log in to VDC1, then VDC2 and VDC3 are the remaining zone except VDC1. As a result, you see two extra rows showing the bootstrap process of VDC2 and VDC3.

If you log in to VDC2, then VDC1 and VDC3 are the remaining zone except VDC2. As a result, you see two extra rows showing the bootstrap process of VDC1 and VDC3

If you log in to VDC3, then VDC1 and VDC2 are the remaining zone except VDC3. As a result, you see two extra rows showing the bootstrap process of VDC1 and VDC2.

Working with replication groups in the ECS Portal

You can use replication groups to define where storage pool content is protected. Replication groups can be local or global. Local replication groups do not replicate data to other VDCs, but protect objects within the same VDC against disk or node failures using mirroring and erasure coding techniques. Global replication groups protect objects by replicating them to another site within an ECS federation and, by doing so, protect against site failures.

ECS Administration Guide 37

Storage Pools, VDCs, and Replication Groups

You can use the Replication Group Management page to view replication group details, to create replication groups, and to edit existing replication groups. You cannot delete replication groups in this release.

Note: Do not create more than eight replication groups in a cluster. If there is a requirement to

have more than eight replication groups in a cluster, contact ECS Remote Support.

Table 7 Replication Group properties

Field Description

Name The name of the replication group.

Type The replication type can be Active or Passive. Passive means that a site is designated as the

target for replication data and is only available when there is a minimum of three sites. Passive cannot be selected if Replicate to All Sites is On. If you have a Hosted site, it will automatically be selected as the target for replication in a Passive configuration.

VDC The number of VDCs in the replication group and the names of the VDCs where the storage

pools are located.

Storage Pool The names of the storage pools and their associated VDCs. A replication group can contain a

storage pool from each VDC in a federation.

Target The storage pool in the replication group that is the replication target in a Passive configuration.

Status The state of the replication group.

Online

Temp Unavailable: Replication traffic to this VDC has failed. If all replication traffic to the same VDC is in the Temp Unavailable state, further investigation about the cause of the failure is recommended.

Actions The actions that can be completed for the replication group. Edit: Modify the replication group

name and the set of VDCs and storage pools in the replication group.

Create a replication group

Replication groups can be local to a VDC or can protect data by replicating data across sites.

Before you begin

This operation requires the System Administrator role in ECS.

If you want the replication group to span multiple VDCs, you must ensure that the VDCs are federated (joined) to the primary VDC, and that storage pools have been created in the VDCs that will be included in the replication group.

Procedure

1. In the ECS Portal, select Manage > Replication Group.

2. On the Replication Group Management page, click New Replication Group.

3. On the New Replication Group page, in the Name field, type a name (for example,

ReplicationGroup1).

4. Optionally, in the Replicate to All Sites field, click On for this replication group. You can only turn this setting on when you create the replication group; you cannot turn it off later.

For a Passive configuration, leave this setting Off.

38 ECS Administration Guide

Option Description

Storage Pools, VDCs, and Replication Groups

Replicate to All Sites Off

The replication group uses default replication. With default replication, data is stored at the primary site and a full copy is stored at a secondary site chosen from the sites within the replication group. The secondary copy is protected by triple-mirroring and erasure coding. This process provides data durability with storage efficiency.

Replicate to All Sites On

The replication group makes a full readable copy of all objects to all sites (VDCs) within the replication group. Having full readable copies of objects on all VDCs in the replication group provides data durability and improves local performance at all sites at the cost of storage efficiency.

5. In the Geo Replication Type field, click Active or Passive. Active is the default ECS configuration. You cannot change this setting after you create the replication group.

Passive is available only when you have three or more sites.

Passive cannot be selected if Replicate to All Sites is On.

For more information on Active and Passive data protection schemes, see Configurations for

availability, durability, and resilience on page 15

6. Click Add VDC to add storage pools from VDCs to the replication group.

The steps to add storage pools to a replication group depends on whether you have a single VDC, an Active, or Passive environment.

7. To add storage pools to an Active (or to a single site) configuration, use the steps below.

a. From the Virtual Data Center list, select the VDC that will provide a storage pool for the

replication group.

b. From the Storage Pool list, select the storage pool that belongs to the selected VDC.

c. To include other sites in the replication group, click Add VDC.

d. Repeat these steps for each storage pool that you want to add to the replication group.

8. To add storage pools for a Passive configuration, complete the following steps.

a. In the Target VDC for Replication Virtual Data Center list, select the VDC that you

want to add as the replication target.

If you have a Hosted VDC that is hosted off-premise by a third-party data center (a backup site), it is automatically selected as the replication target.

b. In the Target VDC for Replication Storage Pool list, select the storage pool that

belongs to the selected VDC.

c. In each of the two Source VDC for Replication Virtual Data Center lists, select the

VDC that you want to add as the active site.

d. In each of the two Source VDC for Replication Storage Pool lists, select the storage

pool that belongs to each selected VDC. These storage pools will provide storage at the two active sites.

9. Click Save.

After you finish

After you create the replication group, you can monitor the copying of user data and metadata to the new VDC that you added to the replication group on the Monitor > Geo Replication > Geo Bootstrap Processing tab. When all the user data and metadata is successfully replicated to the new VDC, the Bootstrap State is Done and the Bootstrap Progress (%) is 100.

ECS Administration Guide 39

Storage Pools, VDCs, and Replication Groups

Edit a replication group

You can change the name of the replication group or change the set of VDCs and storage pools in the replication group.

Before you begin

This operation requires the System Administrator role in ECS.

About this task

CAUTION In a multisite federation, you can edit a replication group (RG) and choose to delete

a VDC from one or more replication groups to which it belongs. Removing a VDC from a RG no longer removes the VDC from the federation. It only removes it from the RG and triggers recovery for that RG. In ECS, each object has a primary, or owning VDC. The time that is taken to complete this failover process depends on the amount of data that must be moved. If you created the replication group with the Replicate to All Sites setting turned on, the time taken to move all data to the remaining sites is short, as a copy exists at all sites.

You cannot edit the Replicate to All Sites or Geo Replication Type settings. After you set these options when you first create the replication group, they cannot be changed.

Procedure

1. In the ECS Portal, select Manage > Replication Group.

2. On the Replication Group Management page, beside the replication group you want to edit, click Edit.

3. On the Edit Replication Group page,

To modify the replication group name, in the Name field, type the new name.

To add a VDC to the replication group, click Add VDC and select the VDC and storage pool from the list.

To delete a VDC from the replication group, click the Delete button beside the VDC (and its storage pool).

CAUTION

Deleting a VDC from one or more replication groups to which it belongs means that you are removing this VDC from the replication group and not from the federation.

VDC removed from a specific Replication group cannot be added back to the same replication group after deletion.

Ensure that Geo replication is up-to-date. Stop all writes to the VDC.

Ensure that the nodes are shut down only for failing (PSO) VDC at the federation level.

Recovery is initiated only when the VDC is removed from the replication group. Proceed to do that next.

This VDC will display a status of Permanently Failedfor failed VDC and not for removed VDC.

In case of failing VDC, to reconstruct this VDC, it must be added as a new site. Any previous data will be lost, as that data will have failed over to other sites in the federation.

4. Click Save.

40 ECS Administration Guide

CHAPTER 4

Authentication Providers

Introduction to authentication providers............................................................................... 42

Working with authentication providers in the ECS Portal...................................................... 42

ECS Administration Guide 41

Authentication Providers

Introduction to authentication providers

You can add authentication providers to ECS if you want users to be authenticated by systems external to ECS.

An authentication provider is a system that is external to ECS that can authenticate users on behalf of ECS. ECS stores the information that allows it to connect to the authentication provider so that ECS can request authentication of a user.

In ECS, the following types of authentication provider are available:

Active Directory (AD) authentication or Lightweight Directory Access Protocol (LDAP) authentication: Used to authenticate domain users that are assigned to management roles in ECS.

Keystone: Used to authenticate OpenStack Swift object users.

Authentication providers can be created from the ECS Portal or by using the ECS Management REST API or CLI.

Working with authentication providers in the ECS Portal

You can use the Authentication Provider Management page available from Manage > Authentication to view the details of existing authentication providers, to add AD/LDAP or

Keystone authentication providers, to edit existing authentication providers, and to delete authentication providers.

Table 8

Field Description

Name The name for the authentication provider.

Type The type of authentication provider. The authentication provider is an Active Directory

Domains The domains that the authentication provider provides access to.

Status Indicates whether the authentication provider is Enabled or Disabled.

Actions The actions that can be completed for the authentication provider.

Authentication provider properties

(AD), Lightweight Directory Access Protocol (LDAP), or Keystone V3 server.

Edit: Change the AD or LDAP authentication provider settings that are listed in

Table 9 on page 43 or change the Keystone authentication provider settings that

are listed in Table 10 on page 47.

Delete: Delete the authentication provider.

New Authentication Provider button: Add an authentication provider.

Considerations when adding Active Directory authentication providers

When you configure ECS to work with Active Directory (AD), you must decide whether to add a single AD authentication provider to manage multiple domains, or to add separate AD authentication providers for each domain.

The decision to add a single AD authentication provider, or multiple, depends on the number of domains in the environment, and the location on the tree from which the manager user can search.

42 ECS Administration Guide

Authentication Providers

Authentication providers have a single search base from which the search begins, and a single manager account that has read access at the search base level and below.

You can add a single authentication provider for multiple domains in the following conditions:

You manage an AD forest

The manager account has privileges to search all user entries in the tree

The search is conducted throughout the whole forest from a single search base, not just the domains listed in the provider

Otherwise, add separate authentication providers for each domain.

Note: If you manage an AD forest and you have the necessary manager account privileges,

there are scenarios in which you might still want to add an authentication provider for each domain. For example, if you want tight control on each domain and more granularity on setting the search base starting point for the search.

The search base must be high enough in the directory structure of the forest for the search to correctly find all the users in the targeted domains. The following search examples describe the best options for adding either single or multiple authentication providers:

In the scenario where the forest in the configuration contains ten domains but you want to target only three, you would not want to add a single authentication provider to manage multiple domains, because the search would unnecessarily span the whole forest. This might adversely affect performance. In this case, you should add three separate authentication providers for each domain.

In the scenario where the forest in the configuration contains ten domains and you want to target ten domains, adding a single authentication provider to manage multiple domains is a good choice, because there is less overhead to set up.

AD or LDAP authentication provider settings

You must provide authentication provider information when you add or edit an AD or LDAP authentication provider. You can customize LDAP certificate for ECS authentication.

Table 9

Field Description and requirements

Name The name of the authentication provider. You can have multiple providers for different

Description Free text description of the authentication provider.

Type The type of authentication provider. Active Directory or LDAP.

Domains The collection of administratively defined objects that share a common directory database,

Server URLs The LDAP or LDAPS (secure LDAP) with the domain controller IP address. The default port

AD or LDAP authentication provider settings

domains.

security policies, and trust relationships. A domain can span multiple physical locations or sites and can contain millions of objects. Example: mycompany.com

If an alternate UPN suffix is configured in the Active Directory, the Domains field should also contain the alternate UPN configured for the domain. For example, if myco is added as an alternate UPN suffix for mycompany.com, then the Domains field should contain both myco and mycompany.com.

for LDAP is 389. The default port for LDAPS is 636.

You can specify one or more LDAP or LDAPS authentication provider.

ECS Administration Guide 43

Authentication Providers

Table 9 AD or LDAP authentication provider settings (continued)

Field Description and requirements

Example: ldap://<Domain controller IP>:<port> (if not default port) or ldaps://<Domain controller IP>:<port>(if not default port)

If the authentication provider supports a multidomain forest, use the global catalog server IP and always specify the port number. The default port for LDAP is 3268. The default port for LDAPS is 3269.

Example: ldap(s)://<Global catalog server IP>:<port>

Manager DN The Active Directory Bind user account that ECS uses to connect to the Active Directory or

LDAP server. This account is used to search Active Directory when an ECS administrator specifies a user for role assignment.

This user account must have Read all inetOrgPerson information in Active Directory. The InetOrgPerson object class is used in several non-Microsoft, LDAP and X.500 directory services to represent people in an organization.

To set this privilege in Active Directory:

1. Open Active Directory Users and Computers.

2. Right-click the domain, select Delegate Control, and then click Next.

3. In the Delegation of Control wizard, click Next, and then click Add.

4. In the Select Users, Computers, or Groups dialog box, select the user that you are using for managerdn, and then click Next.

5. In the Tasks to Delegate page, in Delegate the following common tasks, check the

Read all inetOrgPerson information task, and then click Next.

6. Click Finish.

In this example: CN=Manager,CN=Users,DC=mydomaincontroller,DC=com, the Active Directory Bind user is Manager, in the Users tree of the mydomaincontroller.com domain. Usually managerdn is a user who has fewer privileges than Administrator, but has sufficient privileges to query Active Directory for users attributes and group information.

Important: You must update this user account in ECS if the managerdn credentials change in Active Directory.

Manager Password

Providers This setting is Enabled by default when adding an authentication provider. ECS validates the

The password of the managerdn user.

Important: You must update this password in ECS if the managerdn credentials change in Active Directory.

connectivity of the enabled authentication provider and that the name and domain of the enabled authentication provider are unique. Select Disabled only if you want to add the authentication provider to ECS, but you do not immediately want to use it for authentication. ECS does not validate the connectivity of a disabled authentication provider, but it does validate that the authentication provider name and domain are unique.

Group Attribute This attribute applies only to Active Directory; it does not apply to other types of

authentication providers. The AD attribute that is used to identify a group. Used for searching the directory by groups.

Example: CN

44 ECS Administration Guide

Table 9 AD or LDAP authentication provider settings (continued)

Field Description and requirements

Note: After you set this attribute for an AD authentication provider, you cannot change

it, because the tenants using this provider might already have role assignments and permissions configured with group names in a format that uses this attribute.

Group Whitelist This setting applies only to Active Directory; it does not apply to other types of

authentication providers.

Optional. One or more group names as defined by the authentication provider. This setting filters the group membership information that ECS retrieves about a user.

When a group or groups are included in the whitelist, ECS is aware only of a user's membership in the specified groups. Multiple values (one value on each line in the ECS Portal, and values comma-separated in CLI and API) and wildcards (for example MyGroup*,TopAdminUsers*) are allowed.

The default setting is blank. ECS is aware of all groups that a user belongs to. Asterisk (*) is the same as blank.

Example:

UserA belongs to Group1 and Group2.

Authentication Providers

If the whitelist is blank, ECS knows that UserA is a member of Group1 and Group2.

If the whitelist is Group1, ECS knows that UserA is a member of Group1, but does not know that UserA is a member of Group2 (or of any other group).

Use care when adding a whitelist value. For example, if you map a user to a namespace that is based on group membership, then ECS must be aware of the user's membership in the group.

To restrict access to a namespace to only users of certain groups, complete the following tasks.

Add the groups to the namespace user mapping. The namespace is configured to accept only users of these groups.

Add the groups to the whitelist. ECS is authorized to receive information about them.

By default, if no groups are added to the namespace user mapping, users from any groups are accepted, regardless of the whitelist configuration.

Search Scope

The levels to search. Possible values are:

One Level (search for users one level under the search base)

Subtree (search the entire subtree under the search base)

Search Base The Base Distinguished Name that ECS uses to search for users or AD groups at login time

and when assigning roles or setting ACLs. The following example searches for all users in the Users container.

CN=Users,DC=mydomaincontroller,DC=com

The following example searches for all users in the Users container in the myGroup organization unit. Note that the structure of the search base value begins with the leaf level and goes up to the domain controller level, which is the reverse of the structure seen in the Active Directory Users and Computers snap-in.

CN=Users,OU=myGroup,DC=mydomaincontroller,DC=com

Search Filter The string used to select subsets of users.

ECS Administration Guide 45

Authentication Providers

Table 9 AD or LDAP authentication provider settings (continued)

Field Description and requirements

Example: userPrincipalName=%u

Note: ECS does not validate this value when you add the authentication provider.

If an alternate UPN suffix is configured in the Active Directory, the Search Filter value must be of the format sAMAccountName=%U where %U is the username, and does not contain the domain name.

Add an AD or LDAP authentication provider

You can add one or more authentication providers to ECS to perform user authentication for ECS domain users.

Before you begin

This operation requires the System Administrator role in ECS.

You need access to the authentication provider information listed in AD/LDAP authentication

provider settings. Note especially the requirements for the Manager DN user.

Procedure

1. In the ECS Portal, select Manage > Authentication.

2. On the Authentication Provider Management page, click New Authentication Provider.

3. On the New Authentication Provider page, type values in the fields. For more information about these fields, see AD/LDAP authentication provider settings.

4. Click Save.

5. To verify the configuration, add a user from the authentication provider at Manage > Users > Management Users, and then try to log in as the new user.

After you finish

If you want these users to perform ECS object user operations, add (assign) the domain users into a namespace. For more information, see Add domain users into a namespace on page 72.

Add a Keystone authentication provider

You can add a Keystone authentication provider to authenticate OpenStack Swift users.

Before you begin

This operation requires the System Administrator role in ECS.

You can add only one Keystone authentication provider.

Obtain the authentication provider information listed in Keystone authentication provider

settings.

Procedure

1. In the ECS Portal, select Manage > Authentication.

2. On the Authentication Provider Management page, click New Authentication Provider.

3. On the New Authentication Provider page, in the Type field, select Keystone V3.

The required fields are displayed.

46 ECS Administration Guide

Authentication Providers

4. Type values in the Name, Description, Server URL, Keystone Administrator, and Admin Password fields. For more information about these fields, see Keystone authentication

provider settings.

5. Click Save.

Keystone authentication provider settings

You must provide authentication provider information when you add or edit a Keystone authentication provider.

The table lists the Keystone authentication provider settings

Table 10 Keystone authentication provider settings

Field Description

Name The name of the Keystone authentication provider. This name is used to

identify the provider in ECS.

Description Free text description of the authentication provider.

Type Keystone V3.

Server URL URl of the Keystone system that ECS connects to in order to validate Swift

users.

Keystone Administrator Username for an administrator of the Keystone system. ECS connects to the

Keystone system using this username.

Admin Password Password of the specified Keystone administrator.

ECS Administration Guide 47

Authentication Providers

48 ECS Administration Guide

CHAPTER 5

Namespaces

Introduction to namespaces.................................................................................................. 50

Working with namespaces in the ECS Portal......................................................................... 51

ECS Administration Guide 49

Namespaces

Introduction to namespaces

You can use namespaces to provide multiple tenants with access to the ECS object store and to ensure that the objects and buckets written by users of each tenant are segregated from the other tenants.

ECS supports access by multiple tenants, where each tenant is defined by a namespace and the namespace has a set of configured users who can store and access objects within the namespace. Users from one namespace cannot access the objects that belong to another namespace.

Namespaces are global resources in ECS. A System Administrator or Namespace Administrator can access ECS from any federated VDC and can configure the namespace settings. The object users that you assign to a namespace are global and can access the object store from any federated VDC.

You configure a namespace with settings that define which users can access the namespace and what characteristics the namespace has. Users with the appropriate privileges can create buckets, and can create objects within buckets, in the namespace.

You can use buckets to create subtenants. The bucket owner is the subtenant administrator and can assign users to the subtenant by using access control lists (ACLs). However, subtenants do not provide the same level of segregation as tenants. Any user assigned to the tenant could be assigned privileges on a subtenant, so care must be taken when assigning users.

An object in one namespace can have the same name as an object in another namespace. ECS can identify objects by the namespace qualifier.

You can configure namespaces to monitor and meter their usage, and you can grant management rights to the tenant so that it can perform configuration, monitoring, and metering operations.

The namespace configuration tasks that you can perform in the ECS Portal can also be performed using the ECS Management REST API.

Namespace tenancy

A System Administrator can set up namespaces in the following tenant scenarios:

Enterprise single tenant

All users access buckets and objects in the same namespace. Buckets can be created for subtenants, to allow a subset of namespace users to access the same set of objects. For example, a subtenant might be a department within the organization.

Enterprise multitenant

Departments within an organization are assigned to different namespaces and department users are assigned to each namespace.

Cloud Service Provider single tenant

A single namespace is configured and the Service Provider provides access to the object store for users within the organization or outside the organization.

Cloud Service Provider multitenant

The Service Provider assigns namespaces to different companies and assigns an administrator for the namespace. The Namespace Administrator for the tenant can then add users and can monitor and meter the use of buckets and objects.

50 ECS Administration Guide

Working with namespaces in the ECS Portal

You can use the Namespace Management page available from Manage > Namespace to view the details of existing namespaces, to create new namespaces, to edit existing namespaces, and to delete namespaces.

Table 11 Namespace properties

Field Description

Name The name of the namespace.

Default Replication Group The default replication group for the namespace.

Notification Quota The quota limit at which notification is generated.

Max Quota The quota limit at which writes to the namespace are blocked.

Encryption Specifies if D@RE server-side encryption is enabled for the namespace.

Actions The actions that can be completed for the namespace.

Edit: Change the namespace name, the Namespace Administrator, the default replication group, namespace quota, bucket quota, server-side encryption, access during outage, and compliance settings for the namespace.

Delete: Delete the namespace.

Namespaces

Namespace settings

The following table describes the settings that you can specify when you create or edit an ECS namespace.

How namespace and bucket names are used when addressing objects in ECS is described in Object

base URL on page 140.

Table 12

Field Description Can be

Name The name of the namespace, in lowercase characters. No

Namespace Admin The user ID of one or more users who are assigned to the Namespace

Domain Group Admin The domain group that is assigned to the Namespace Administrator role. Any

Namespace settings

edited

Yes Administrator role; a list of users is comma that is separated. Namespace Administrators can be local or domain users. If the Namespace Administrator is a domain user, ensure that an authentication provider is added to ECS. See Introduction to users and roles on page 60 for details.

Yes member, when authenticated, is assigned the Namespace Administrator role for the namespace. The domain group must be assigned to the namespace by setting the Domain User Mappings for the namespace. To use this feature, you must ensure that an authentication provider is added to ECS. See Introduction to users and roles on page 60 for details.

Replication Group The default replication group for the namespace. Yes

ECS Administration Guide 51

Namespaces

Table 12 Namespace settings (continued)

Field Description Can be

edited

Namespace Quota The storage space limit that is specified for the namespace. You can specify

a storage limit for the namespace and define notification and access behavior when the quota is reached. The quota setting for a namespace cannot be less than 1 GiB. You can specify namespace quota settings in increments of GiB. You can select one of the following quota behavior options:

Notification Only at <

quota_limit_in_GiB

> Soft quota setting at which

you are notified.

Block Access Only at <

quota_limit_in_GiB

> Hard quota setting which,

when reached, prevents write/update access to buckets in the namespace.

Block Access at < <

quota_limit_in_GiB

> and Send Notification at

> Hard quota setting which, when reached,

prevents write/update access to the buckets in the namespace and the quota setting at which you are notified.

Default Bucket Quota The default storage limit that is specified for buckets that are created in this

namespace. This is a hard quota which, when reached, prevents write/ update access to the bucket. Changing the default bucket quota does not change the bucket quota for buckets that are already created.

Server-side Encryption The default value for server-side encryption for buckets created in this

namespace.

Server-side encryption, also known as Data At Rest Encryption or D@RE, encrypts data inline before storing it on ECS disks or drives. This encryption helps prevent sensitive data from being acquired from discarded or stolen media.

If you turn this setting on for the namespace, and then all its buckets are encrypted and this setting cannot be changed when a bucket is created. If you want the buckets in the namespace to be unencrypted, and then you must leave this setting off. If you leave this setting off for the namespace, individual buckets can be set as encrypted when created.

For a complete description of the feature, see the

Configuration Guide

, available from the ECS Product Documentation

ECS Security

page.

Yes

Access During Outage The default behavior when accessing data in the buckets created in this

namespace during a temporary site outage in a geo-federated setup.

If you turn this setting on for the namespace and a temporary site outage occurs, if you cannot access a bucket at the failed site where the bucket was created (owner site), you can access a copy of the bucket at another site. Objects that you access in the buckets in the namespace might have been updated at the failed site, but changes might not have been propagated to the site from which you are accessing the object.

If you leave this setting off for the namespace, data in the site which has the temporary outage is not available for access from other sites, and object reads for data that is owned by the failed site will fail.

52 ECS Administration Guide

Yes

Table 12 Namespace settings (continued)

Field Description Can be

edited

For more information, see TSO behavior with the ADO bucket setting

turned on on page 176.

Namespaces

Compliance

The rules that limit changes that can be made to retention settings on objects under retention. ECS has object retention features enabled or defined at the object level, bucket level, and namespace level. Compliance strengthens these features by limiting changes that can be made to retention settings on objects under retention.

You can turn this setting on only at the time the namespace is created; you cannot change it after the namespace is created.

Compliance is supported by S3 and CAS systems. For details about the rules enforced by compliance, see the

ECS Data Access Guide

from the ECS Product Documentation page.

Retention Policies Enables one or more retention policies to be added and configured.

A namespace can have one or more associated retention policies, where each policy defines a retention period. When you apply a retention policy to several objects, rather than to an individual object, a change to the retention policy changes the retention period for all the objects to which the policy is applied. A request to modify an object before the expiration of the retention period is disallowed.

In addition to specifying a retention policy for several objects, you can specify retention policies and a quota for the entire namespace.

For more information about retention, see Retention periods and policies on page 53.

, available

Yes

Domain Enables Active Directory (AD) or Lightweight Directory Access Protocol

(LDAP) domains to be specified and the rules for including users from the domain to be configured.

Domain users can be assigned to ECS management roles and can use the ECS self-service capability to register as object users.

The mapping of domain users into a namespace is described in Domain

users require an assigned namespace to perform object user operations

on page 62.

You can set the following attribute using the ECS Management REST API, but not from the ECS Portal.

Allowed (and Disallowed) Replication Groups

Enables a client to specify the replication groups that the namespace can use.

Retention periods and policies

ECS provides the ability to prevent data from being modified or deleted within a specified retention period.

You can specify retention by using retention periods and retention policies that are defined in the metadata that is associated with objects and buckets. The retention periods and retention policies

ECS Administration Guide 53

Yes

Namespaces

are checked each time a request to modify an object is made. Retention periods are supported on all ECS object protocols (S3, Swift, Atmos, and CAS).

Note: For detailed information about setting retention on object interfaces, including CAS

retention and CAS advanced retention, see the

ECS Data Access Guide

, available from the ECS

Product Documentation page.

Retention Periods

You can assign retention periods at the object level or the bucket level. Each time a user requests to modify or delete an object, an expiration time is calculated. The object expiration time equals the object creation time plus the retention period. When you assign a retention period for a bucket, the object expiration time is calculated based on the retention period set on the object and the retention period set on the bucket, whichever is the longest.

When you apply a retention period to a bucket, the retention period for all objects in a bucket can be changed at any time, and can override the value written to the object by an object client by setting it to a longer period.

You can specify that an object is retained indefinitely.

Auto-Commit Period

Auto-commit period is the time interval in which the updates through NFS are allowed for objects under retention. This attribute enables NFS files that are written to ECS to be WORM compliant. The interval is calculated from the last modification time.

The auto-commit value must be less than or equal to the retention value with a maximum of 1 day. A value of 0 indicates no auto-commit period.

Retention Policies

Retention policies are associated with a namespace. Any policy that is associated with the namespace can be assigned to an object belonging to the namespace. A retention policy has an associated retention period.

When you change the retention period that is associated with a policy, the retention period automatically changes for objects that have that policy that is assigned.

You can apply a retention policy to an object. When a user attempts to modify or delete an object, the retention policy is retrieved. The retention period in the retention policy is used with object retention period and bucket retention period to verify whether the request is allowed.

For example, you could define a retention policy for each of the following document types, and each policy could have an appropriate retention period. When a user requests to modify or delete the legal document four years after it was created, the larger of the bucket retention period or the object retention period is used to verify whether the operation can be performed. In this case, the request is not allowed, and the document cannot be modified or deleted for one more year.

l Email - six months

l Financial - three years

l Legal - five years

ECS Management REST API retention policy methods

The retention policy creation and configuration tasks that can be performed in the ECS Portal can also be performed using the ECS Management REST API. The following table describes the ECS Management REST API methods that relate to retention policies:

54 ECS Administration Guide

Namespaces

ECS Management REST API method

PUT /object/bucket/{ retention

GET /object/bucket/{ retention

POST /object/namespaces/ namespace/{

PUT /object/namespaces/ namespace/{ retention/{

GET /object/namespaces/ namespace/{

namespace

class

namespace

bucketName

}/retention

}

}/retention

For information about how to access the ECS Management REST API, see the

Guide

Description

The retention value for a bucket that defines a mandatory retention period which is applied to every object within a bucket. If the retention value is one year, an object from the bucket cannot be modified or deleted for one year.

Returns the retention period that is set for a specified bucket.

The retention setting for namespaces that acts like a policy, where each policy is a < policies for a namespace and you can assign a policy, by name, to an object within the namespace. This allows you to change the retention period for a set of objects that have the same policy assigned, by changing the corresponding policy.

Updates the period for a retention class that is associated with a namespace.

Returns the retention classes that are defined for a namespace.

name

>: <

retention period

> pair. You can define several retention

, available from the ECS Product Documentation page.

ECS Data Access

Create a namespace

You can create a namespace.

Before you begin

This operation requires the System Administrator role in ECS.

A replication group must exist. The replication group provides access to storage pools in which object data is stored.

If you want to enable domain users to access the namespace, an authentication provider must be added to ECS. To configure domain object users or a domain group, you must plan how you want to map users into the namespace. For more information about mapping users, see Domain

users require an assigned namespace to perform object user operations on page 62.

About this task

For more information about namespaces, see Namespace settings on page 51.

Procedure

1. In the ECS Portal, select Manage > Namespace.

2. On the Namespace Management page, click New Namespace.

3. On the New Namespace page, in the Name field, type the name of the namespace.

The name cannot be changed once created.

4. In the Namespace Admin field, specify the user ID of one or more domain or local users to whom you want to assign the Namespace Administrator role.

You can add multiple users or groups as comma-separated lists.

5. In the Domain Group Admin field, you can also add one or more domain groups to whom you want to assign the Namespace Administrator role.

6. In the Replication Group field, select the default replication group for this namespace.

ECS Administration Guide 55

Namespaces

7. In the Namespace Quota field, click On to specify a storage space limit for this namespace. If you enable a namespace quota, select one of the following quota behavior options:

a. Notification Only at <

quota_limit_in_GiB

Select this option if you want to be notified when the namespace quota setting is reached.

b. Block Access Only at <

quota_limit_in_GiB

Select this option is you want write/update access to the buckets in this namespace that is blocked when the quota is reached.

c. Block Access at <

quota_limit_in_GiB

> and Send Notification at

Select this option if you want write/update access to the buckets in this namespace that is blocked when the quota is reached and you want to be notified when the quota reaches a specified storage limit.

8. In the Default Bucket Quota field, click On to specify a default storage space limit that is automatically set on all buckets that are created in this namespace.

9. In the Server-side Encryption field, click On to enable server-side encryption on all buckets that are created in the namespace and to encrypt all objects in the buckets. If you leave this setting Off, you can apply server-side encryption to individual buckets in the namespace at the time of creation.

10. In the Access During Outage field, click On or Off to specify the default behavior when accessing data in the buckets created in this namespace during a temporary site outage in a geo-federated setup.

If you turn this setting on, if a temporary site outage occurs in a geo-federated system and you cannot access a bucket at the failed site where it was created (owner site), you can access a copy of the bucket at another site.

If you leave this setting off, data in the site which has the temporary outage is not available for access from other sites, and object reads for data that is owned by the failed site will fail.

11. In the Compliance field, click On to enable compliance features for objects in this namespace.

Once you turn this setting on, you cannot turn it off.

You can only turn this setting on during namespace creation.

Once you turn this setting on, you can add a retention policy by completing the following steps:

a. In the Retention Policies area, in the Name field, type the name of the policy.

b. In the Value fields, select a numerical value and then select the unit of measure

(seconds, minutes, hours, days, months, years, infinite) to set the retention period for this retention policy.

Instead of specifying a specific retention period, you can select Infinite as a unit of measure to ensure that buckets that are assigned to this retention policy are never deleted.

c. Click Add to add the new policy.

12. To specify an Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) domain that contains the users who can log in to ECS and perform administration tasks for the namespace, click Domain.

56 ECS Administration Guide

13. Click Save.

Edit a namespace

You can change the configuration of an existing namespace.

Before you begin

This operation requires the System Administrator role in ECS.

The Namespace Administrator role can modify the AD or LDAP domain that contains the users in the namespace that are object users or management users that can be assigned the Namespace Administrator role for the namespace.

About this task

You cannot edit the Name, Server-side Encryption, or Compliance fields after the namespace has been created.

Namespaces

a. In the Domain field, type the name of the domain.

b. Specify the groups and attributes for the domain users that are allowed to access ECS in

this namespace by typing the values in the Groups, Attribute, and Values fields.

For information about how to perform complex mappings using groups and attributes, see

Domain users require an assigned namespace to perform object user operations on page

62.

Procedure

1. In the ECS Portal, select Manage > Namespace.

2. On the Namespace Management page, locate the namespace that you want to edit in the table. Click Edit in the Actions column beside the namespace you want to edit.

3. On the Edit Namespace page:

To modify the domain or local users to whom you want to assign the Namespace Administrator role, in the Namespace Admin or Domain Group Admin fields, change the user IDs.

To modify the default replication group for this namespace, in the Replication Group field, select a different replication group.

To modify which of the following settings are enabled, click the appropriate On or Off options.

Namespace Quota

Default Bucket Quota

Access During Outage

4. To modify an existing retention policy, in the Retention Policies area:

a. Click Edit in the Actions column beside the retention policy you want to edit.

b. To modify the policy name, in the Name field, type the new retention policy name.

c. To modify the retention period, in the Value field, type the new retention period for this

retention policy.

5. To modify the AD or LDAP domain that contains the object users in the namespace and management users that can be assigned the Namespace Administrator role for the namespace, click Domain.

a. To modify the domain name, in the Domain field, type the new domain name.

ECS Administration Guide 57

Namespaces

b. To modify the groups and attributes for the domain users that are allowed to access ECS

6. Click Save.

Delete a namespace

You can delete a namespace, but you must delete the buckets in the namespace first.

Before you begin

This operation requires the System Administrator role in ECS.

Procedure

1. In the ECS Portal, select Manage > Namespace.

2. On the Namespace Management page, locate the namespace that you want to delete in the table. Click Delete in the Actions column beside the namespace you want to delete.

An alert displays informing you of the number of buckets in the namespace and instructs you to delete the buckets in the namespace before removing the namespace. Click OK.

3. Delete the buckets in the namespace.

in this namespace, type the new values in the Groups, Attribute, and Values fields.

a. Select Manage > Buckets.

b. On the Bucket Management page, locate the bucket that you want to delete in the

table. Click Delete in the Actions column beside the bucket you want to delete.

c. Repeat step 4b. for all the buckets in the namespace.

4. On the Namespace Management page, locate the namespace that you want to delete in the table. Click Delete in the Actions column beside the namespace you want to delete.

Since there are no longer any buckets in this namespace, a message displays to confirm that you want to delete this namespace. Click OK.

5. Click Save.

58 ECS Administration Guide

CHAPTER 6

Users and Roles

Introduction to users and roles..............................................................................................60

Users in ECS......................................................................................................................... 60

Management roles in ECS..................................................................................................... 64

Working with users in the ECS Portal....................................................................................68

ECS Administration Guide 59

Users and Roles

Introduction to users and roles

In ECS you can configure users and roles to control access to the ECS management tasks and to the object store. Management users can perform administration tasks in the ECS Portal. Object users cannot access the ECS Portal but can access the object store using clients that support the ECS data access protocols.

Roles in ECS determine the operations that a management user can perform in the ECS Portal or by using the ECS Management REST API.

Management users and object users are stored in different tables and their credentials are different. Management users require a local username and password, or a link to a domain user account. Object users require a username and a secret key. You can create a management user and an object user with the same name, but they are effectively different users as their credentials are different.

Management user and object user names can be unique across the ECS system or can be unique within a namespace, which is referred to as user scope.

Domain and local users can be assigned as management users or object users. Local user credentials are stored by ECS. Domain users are users defined in an Active Directory AD/LDAP database and ECS must talk to the AD or LDAP server to authenticate user login request.

Users in ECS

ECS requires two types of user: management users, who can perform administration of ECS, and object users, who access the object store to read and write objects and buckets.

Management users

Management users can perform the configuration and administration of the ECS system and of namespaces (tenants) configured in ECS.

The roles that can be assigned to management users are System Administrator, System Monitor, Namespace Administrator, and Lock Administrator as described in Management roles in ECS on page 64.

Management users can be local users or domain users. Management users that are local users are authenticated by ECS against the locally held credentials. Management users that are domain users are authenticated in Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) systems. For more information about domain and local users, see Domain and local users on page

62.

Management users are not replicated across geo-federated VDCs.

Default management users

On installation, ECS creates two default local management users, root and emcsecurity, to enable for the initial and ongoing configuration of ECS. The root and emcsecurity management users can access the ECS system by using the ECS Portal or the ECS Management REST API. These default users cannot be removed from the ECS system and they are not replicated across sites in a geofederation. The following table describes the default management users:

60 ECS Administration Guide

Table 13 Default management users

Users and Roles

Default user

root ChangeMe This user performs the initial

emcsecurity ChangeMe This user can prevent remote SSH

Default password

User description Role assigned

configuration of the ECS system, and creates users with System Administrator roles. The first time the root user accesses ECS, the user is prompted to change the password and immediately log in again with the new password. From an audit perspective, it is important to know which user carried out changes to the system, so the root user should not be used after system initialization. After system initialization, each System Administrator user should log in to the system using their own credentials, not the root user credentials.

access to nodes by locking them. The password for this user should be changed after system installation and securely recorded.

to user

System Administrator

Lock Administrator

Role permissions Can more

users be created?

Create and delete management and object users

Change user passwords

Grant permissions to object users

Create, delete, modify storage pools, namespaces, buckets, and replication groups

View monitoring metrics

Lock and unlock nodes

Change its own password

Yes

Object users

Object users are users of the ECS object store. They access ECS through object clients that are using the object protocols that ECS supports (S3, EMC Atmos, OpenStack Swift, and CAS). Object users can be assigned Unix-style permissions to access buckets exported as file systems for HDFS.

A management user (System or Namespace Administrator) can create an object user. The management user defines a username and assigns a secret key to the object user when the user is created or at any time thereafter. A username can be a local name or a domain-style username that includes @ in the name. The object user uses the secret key to access the ECS object store. The secret key of object user is distributed by email or other means.

Users that are added to ECS as domain users can later add themselves as object users by creating their own secret key using the ECS self-service capability through a client that communicates with the ECS Management REST API. The object username that they are given is the same as their domain name. Object users do not have access to the ECS Portal. For more information about domain users, see the Domain and local users on page 62. For information about creating a secret key, see the

ECS Data Access Guide

, available from the ECS Product Documentation page.

Object users are global resources. An object user can have privileges to read and write buckets, and objects within the namespace to which they are assigned, from any VDC.

ECS Administration Guide 61

Users and Roles

Domain and local users

ECS supports for local user and domain users. Local and domain users can be assigned as management users or object users.

The ECS self-service capability authenticates domain users and enables domain users to create a secret key for themselves. When a domain user creates their own secret key, they become an object user in the ECS system. You can use AD and LDAP to give many users from an existing user database access to the ECS object store (as object users). Without creating each user individually.

Note: Domain users that are object users must be added (mapped) into a namespace. For

more information, see Add domain users into a namespace on page 72

ECS stores credentials of local users. The credentials for object users are global resources and are available from all VDCs in ECS.

Domain users are defined in an Active Directory AD or LDAP database. Domain usernames are defined by using the user@domain.com format. Usernames without @ are authenticated against the local user database. ECS uses an authentication provider to supply the credentials to communicate with the AD or LDAP server to authenticate a domain user login request. Domain users assigned to management roles can be authenticated against their AD or LDAP credentials to enable them to access ECS and perform ECS administration operations.

Domain users require an assigned namespace to perform object user operations

You must add (assign) domain users into a namespace if you want these users to perform ECS object user operations. To access the ECS object store, object users and Namespace Administrators must be assigned to a namespace. You can add an entire domain of users into a namespace, or you can add a subset of the domain users into a namespace by specifying a particular group or attribute associated with the domain.

A domain can provide users for multiple namespaces. For example, you might decide to add a set of users such as the Accounts department in the yourco.com domain into Namespace1, and a set of users such as the Finance department in the yourco.com domain into Namespace2. In this case, the yourco.com domain is providing users for two namespaces.

An entire domain, a particular set of users, or a particular user cannot be added into more than one namespace. For example, the yourco.com domain can be added into Namespace1, but the domain cannot also be added into Namespace2.

The following example shows that a System or Namespace Administrator has added into a namespace a subset of users in the yourco.com domain; the users that have their Department attribute = Accounts in Active Directory. The System or Namespace Administrator has added the users in the Accounts department from this domain into a namespace by using the Edit Namespace page in the ECS Portal.

Figure 6

Adding a subset of domain users into a namespace using one AD attribute

The following example shows a different example where the System or Namespace Administrator is using more granularity in adding users into a namespace. In this case, the System or Namespace

62 ECS Administration Guide

Users and Roles

Administrator has added the members in the yourco.com domain who belong to the Storage Admins group with the Department attribute = Accounts AND Region attribute = Pacific, OR belong to the Storage Admins group with the Department attribute = Finance.

Figure 7 Adding a subset of domain users into a namespace using multiple AD attributes

For more information about adding domain users into namespaces using the ECS Portal, see Add

domain users into a namespace on page 72.

User scope

The user scope setting affects all object users, in all namespaces across all federated VDCs.

The user scope can be GLOBAL or NAMESPACE. If the scope is set to GLOBAL, object user names are unique across all VDCs in the ECS system. If the scope is set to NAMESPACE, object user names are unique within a namespace, so the same object user names can exist in different namespaces.

The default setting is GLOBAL. If you intend to use ECS in a multitenant configuration and you want to ensure that namespaces can use names that are in use in another namespace, you must change this setting to NAMESPACE.

Set the user scope

You can set the user scope using the ECS Management REST API.

Before you begin

This operation requires the System Administrator role in ECS.

If you are going to change the default user scope setting from GLOBAL to NAMESPACE, you must do so before you create the first object user in ECS.

Note:

Set the user scope before you create the first object user.

About this task

The user scope setting affects all object users in ECS.

Procedure

1. In the ECS Management REST API, use the PUT /config/object/properties API call and pass the user scope in the payload.

ECS Administration Guide 63

Users and Roles

User tags

The following example shows a payload that sets the user_scope to NAMESPACE.

PUT /config/object/properties/

<property_update> <properties> <properties> <entry> <key>user_scope</key> <value>NAMESPACE</value> </entry> </properties> </property_update>

A tag in the form of name=value pairs can be associated with the user ID for an object user, and retrieved by an application. For example, an object user can be associated with a project or costcenter. Tags cannot be associated with management users.

This functionality is not available from the ECS Portal. Tags can be set on an object user, and the tags that are associated with the object user can be retrieved by using the ECS Management REST API. You can add a maximum of 20 tags.

Management roles in ECS

ECS defines roles to determine the operations that a user can perform in the ECS Portal or when accessing ECS using the ECS Management REST API. Management users and groups can be assigned to administration roles in ECS and can be either local users or domain users. Roles can also be assigned to Active Directory group names.

The following list provides the four possible management roles that exist in ECS:

System Administrator

System Monitor

Namespace Administrator

Lock Administrator

System Administrator

The System Administrator role allows a user to configure ECS and during initial configuration, specify the storage used for the object store, how the store is replicated, how tenant access to the object store is configured (by defining namespaces), and which users have permissions within an assigned namespace. The System Administrator can also configure namespaces and perform namespace administration, or can assign a user who belongs to the namespace as the Namespace Administrator.

The System Administrator has access to the ECS Portal and system administration operations can also be performed from programmatic clients using the ECS Management REST API.

After initial installation of ECS, the System Administrator is a pre-provisioned local management user called root. The default root user is described in Default management users on page 60.

Because management users are not replicated across sites, a System Administrator must be created at each VDC that requires one.

64 ECS Administration Guide

System Monitor

The System Monitor role enables a user to have read-only access to the ECS Portal. The System Monitor can view all ECS Portal pages and all information on the pages, except user detail information such as passwords and secret key data. The System Monitor cannot provision or configure the ECS system. For example, the monitor cannot create or update storage pools, replication groups, namespaces, buckets, users through the portal or ECS Management REST API. Monitors cannot modify any other portal setting except their own passwords.

Because management users are not replicated across sites, a System Monitor must be created at each VDC that requires one.

Namespace Administrator

The Namespace Administrator is a management user who can access the ECS Portal. The Namespace Administrator can assign local users as object users for the namespace and create and manage buckets within the namespace. Namespace Administrator operations can also be performed using the ECS REST API. A Namespace Administrator can only be the administrator of a single namespace.

Because authentication providers and namespaces are replicated across sites (they are ECS global resources), a domain user who is a Namespace Administrator can log in at any site and perform namespace administration from that site.

Users and Roles

Note:

If a domain user is to be assigned to the Namespace Administrator role, the user must be

mapped into the namespace if the user is not a namespace administrator.

Local management users are not replicated across sites, so a local user who is a Namespace Administrator can only log in at the VDC at which the management user was created. If you want the same username to exist at another VDC, the user must be created at the other VDC. As they are different users, changes to a same-named user at one VDC, such as a password change, is not propagated to the user with the same name at the other VDC.

For more details see the

Documentation page.

Lock Administrator

The Lock Administrator is the only management user who can lock and unlock nodes from the ECS Portal or the ECS Management REST API. access to the node. The Lock Administrator is a default local user called emcsecurity. The emcsecurity user is described in Default management users on page 60.

The Lock Administrator can only change their passwords and lock and unlock nodes. The Lock Administrator role cannot be assigned to another user. System Administrators and System Monitors can view the lock status of nodes. For instructions on locking and unlocking nodes, see

Lock and unlock nodes using the ECS Portal on page 166.

Tasks performed by role

ECS Administration Guide

Locking

which is available on the ECS Product

a node is the ability to disable remote SSH

The tasks that can be performed in the ECS Portal or ECS Management REST API by each role are described in the following table:

ECS Administration Guide 65

Users and Roles

Table 14 Tasks performed by ECS management user role

Task System Admin System Monitor Namespace Admin Lock Admin

Tenancy

Create namespaces (tenants) Yes No No No

Delete namespaces Yes No No No

User management (management and object users unless otherwise noted)

Create local object users and assign them to namespaces

Create local management

Yes (in all namespaces) No Yes (in one

namespace)

Yes (in all namespaces) No No No users and assign them to namespaces

Delete local object users Yes (in all namespaces) No Yes (in one

namespace)

Delete/unlock local

Yes No No No management users

Edit/change password of local

Yes No No No management users

Set user scope (global or

Yes No No No namespace) for all object users

Add an AD, LDAP, or Keystone

Yes (in all namespaces) No No No authentication provider

Delete an AD, LDAP, or

Yes (in all namespaces) No No No Keystone authentication provider

Add AD and LDAP domain users or AD groups into a

Yes (in all namespaces) No Yes (in one

namespace)

namespace

Create an AD group (LDAP

Yes (in all namespaces) No No No and Keystone groups are not supported)

Delete domain users or AD

Yes (in all namespaces) No No No groups

Role management

Assign administration roles to

Yes (in all namespaces) No No No local and domain management users and AD groups

Revoke roles from local and

Yes (in all namespaces) No No No domain users and AD groups

Storage configuration

Create, modify, storage pools Yes (in the VDC where

the System Admin was

created)

66 ECS Administration Guide

No No No

Table 14 Tasks performed by ECS management user role (continued)

Task System Admin System Monitor Namespace Admin Lock Admin

Users and Roles

Create, modify, delete VDCs Yes (in the VDC where

No No No the System Admin was created)

Create, modify replication groups

Yes (in the VDC where the System Admin was

No No No

created)

Create, modify, delete buckets Yes (in all namespaces) No Yes (in one

namespace)

Set the bucket ACL permissions for a user

Create, modify, delete NFS exports

Create, modify, delete mapping of users and groups

Yes (buckets in all namespaces)

No Yes (buckets in one

namespace)

No Yes (buckets in one

namespace)

No Yes (buckets in one

namespace)

to files and objects in buckets

Add, modify, delete the object

Yes (in all namespaces) No No No

Base URL to use ECS object storage for Amazon S3 applications

Monitoring and reports

Get metering information for each namespace and bucket

Get audit information (list of all activity of users using the

Yes (in all namespaces) Yes (in all

namespaces)

Yes (in all namespaces) Yes (in all

namespaces)

Yes (in one

namespace)

No No

ECS Portal and ECS Management REST API)

View alerts and perform alert actions (such as

Yes (in all namespaces) Yes (in all

namespaces)

No No

acknowledging or assigning alerts)

Configure alerts Yes (in all namespaces) No No No

Monitor capacity utilization of storage pools, nodes, disks,

Yes (in all namespaces) Yes (in all

namespaces)

No No

and the entire VDC

Monitor the health and utilization of the infrastructure

Yes (in all namespaces) Yes (in all

namespaces)

No No

environment (nodes, disks, NIC bandwidth, CPU, and memory utilization)

Monitor requests and network performance for VDCs and

Yes (in all namespaces) Yes (in all

namespaces)

No No

nodes

ECS Administration Guide 67

Users and Roles

Table 14 Tasks performed by ECS management user role (continued)

Task System Admin System Monitor Namespace Admin Lock Admin

Monitor status of data erasure encoding for each storage pool

Monitor recovery status of storage pools after an outage or failure (data rebuilding process)

Monitor disk use metrics at the VDC or individual node level

Monitor geo-replication metrics including network traffic, data pending replication and XOR, failover and bootstrapping processing status

Monitor information on cloudhosted VDCs and cloud replication traffic

Licensing, ESRS, security, and event configuration

View license and subscription information for all components

Yes (in all namespaces) Yes (in all

Yes Yes No No

No No

namespaces)

No No

namespaces)

No No

namespaces)

No No

namespaces)

No No

namespaces)

Procure and apply new licenses

Add, modify, delete EMC Secure Remote Services (ESRS) server

Change password Yes Yes Yes Yes

Lock nodes to prevent remote access through SSH

Add or delete an SNMP trap recipient to forward ECS events

Add or delete a syslog server to remotely store ECS logging messages

Yes No No No

No No No Yes

Yes No No No

Working with users in the ECS Portal

You can use the User Management page available from Manage > Users to create local users who are assigned as object users for a namespace. You can also create management users, which can

68 ECS Administration Guide

be new local users to whom you assign management roles, or domain users to whom you assign management roles.

The User Management page has two tabs: the Object Users tab and the Management Users tab.

Object Users tab

You can use the Object Users tab to view the details of object users, to edit object users, and to delete object users. The object users who are listed on this page include:

The local object users who are created by a System or Namespace Administrator in the ECS Portal.

The domain users that have become object users by way of obtaining a secret key using a client that communicates with the ECS Management REST API.

A System Administrator sees the object users for all namespaces. A Namespace Administrator sees only the object users in their namespace.

Table 15 Object user properties

Field Description

Name The name of the object user.

Users and Roles

Namespace The namespace to which the object user is assigned.

Actions The actions that can be completed for the object user.

Edit: Change the object user's name, the namespace to which the user is assigned, or the S3, Swift, or CAS object access passwords for the user.

Delete: Delete the object user.

New Object User button: Adds a new object user.

Management Users tab

You can use the Management Users tab to view the details of local and domain management users, to edit management users, and to delete management users. This tab is only visible to System Administrators.

Table 16

Field Description

Name The name of the management user.

Actions The actions that can be completed for the management user.

Management user properties

Edit: For a local management user: Change the user's name, password, and System Administrator or System Monitor role assignment. For a domain management user: Change the AD or LDAP username or AD group name, and System Administrator or System Monitor role assignment.

Delete: Delete the management user.

New Management User button: Add a new management user that can be assigned the System Administrator role or the System Monitor role.

Unlock: A system administrator can unlock a management user who is locked out.

ECS Administration Guide 69

Users and Roles

Add an object user

You can create object users and configure them to use the supported object access protocols. You can edit an object user configuration by adding or removing access to an object protocol, or by creating a new secret key for the object user.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

A System Administrator can assign new object users into any namespace.

A Namespace Administrator can assign new object users into the namespace in which they are the administrator.

If you create an object user who will access the ECS object store through the OpenStack Swift object protocol, the Swift user must belong to an OpenStack group. A group is a collection of Swift users that have been assigned a role by an OpenStack administrator. Swift users that belong to the admin group can perform all operations on Swift buckets (containers) in the namespace to which they belong. Do not add ordinary Swift users to the admin group. For Swift users that belong to any group other than the admin group, authorization depends on the permissions that are set on the Swift bucket. You can assign permissions on the bucket from the OpenStack Dashboard UI or in the ECS Portal using the Custom Group ACL for the bucket. For more information, see Set custom group bucket ACLs on page 84.

Procedure

1. In the ECS Portal, select Manage > Users.

2. On the User Management page, click New Object User.

3. On the New Object User page, in the Name field, type a name for the local object user.

You can type domain-style names that include @ (for example, user@domain.com). You might want to do this to keep names unique and consistent with AD names. However, local object users are authenticated using a secret key that is assigned to the username, not through AD or LDAP.

Note:

User names can include uppercase letters, lowercase letters, numbers, and any of

the following characters: ! # $ & ' ( ) * + , - . / : ; = ? @ _ ~

4. In the Namespace field, select the namespace that you want to assign the object user to, and then complete one of the following steps:

To add the object user, and return later to specify passwords or secret keys to access the ECS object protocols, click Save.

To specify passwords or secret keys to access the ECS object protocols, click Next to Add Passwords.

5. On the Update Passwords for User <

username

> page, in the Object Access area, for

each of the protocols that you want the user to use to access the ECS object store, type or generate a key for use in accessing the S3/Atmos, Swift, or CAS interfaces.

a. For S3 access, in the S3/Atmos box, click Generate & Add Secret Key.

The secret key (password) is generated.

70 ECS Administration Guide

To view the secret key in plain text, select the Show Secret Key checkbox.

To create a second secret key to replace first secret key for security reasons, click Generate & Add Secret Key.

Users and Roles

The Add S3/Atmos Secret Key/Set Expiration on Existing Secret Key dialog is displayed. When adding a second secret key, you can specify for how long to retain the first password. Once this time has expired, the first secret key expires.

In the Minutes field, type the number of minutes for which you want to retain the first password before it expires. For example, if you typed 3 minutes, you would see This password will expire in 3 minute(s).

After 3 minutes, you would see that the first password displays as expired and you could then delete it.

b. For Swift access:

In the Swift Groups field, type the OpenStack group to which the user belongs.

In the Swift password field, type the OpenStack Swift password for the user.

Click Set Groups & Password.

If you want an S3 user to be able to access Swift buckets, you must add a Swift password and group for the user. The S3 user is authenticated by using the S3 secret key, and the Swift group membership enables access to Swift buckets.

c. For CAS access:

In the CAS field, type the password and click Set Password or click Generate to automatically generate the password and click Set Password.

Click Generate PEA file to generate a Pool Entry Authorization (PEA) file. The file output displays in the PEA file box and the output is similar to the following example. The PEA file provides authentication information to CAS before CAS grants access to ECS; this information includes the username and secret. The secret is the base64encoded password that is used to authenticate the ECS application.

Note:

Generate PEA file button is displayed after the password is set.

<pea version="1.0.0"> <defaultkey name="s3user4"> <credential id="csp1.secret" enc="base64">WlFOOTlTZUFSaUl3Mlg3VnZaQ0k=</credential> </defaultkey> <key type="cluster" id="93b8729a-3610-33e2-9a38-8206a58f6514" name="s3user4"> <credential id="csp1.secret" enc="base64">WlFOOTlTZUFSaUl3Mlg3VnZaQ0k=</credential> </key> </pea>

In the Default Bucket field, select a bucket, and click Set Bucket.

Optional. Click Add Attribute and type values in the Attribute and Group fields.

Click Save Metadata.

6. Click Close.

The passwords/secret keys are saved automatically.

Add a domain user as an object user

You can configure domain users so that they can access the ECS object store and generate secret keys for themselves. By doing so, they add themselves as object users to ECS.

Before you begin

AD or LDAP domain users must have been added to ECS through an AD or LDAP authentication provider. Adding an authentication provider must be performed by a System Administrator and is described in Add an AD or LDAP authentication provider on page 46.

ECS Administration Guide 71

Users and Roles

Domain users must have been added into a namespace by a System or Namespace Administrator as described in Add domain users into a namespace on page 72.

Procedure

1. Domain users can create secret keys for themselves by using the instructions in the

Data Access Guide

, available from the ECS Product Documentation page.

When a domain user creates their own secret key, they become an object user in the ECS system.

Add domain users into a namespace

In the ECS Portal, you can add domain users into a namespace based on the AD or LDAP domain, groups, and attributes associated with the users. Domain users must be added (mapped) into a namespace to perform ECS object user operations.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

An authentication provider must exist in the ECS system that provides access to the domain that includes the users you want to add into the namespace.

Procedure

1. In the ECS Portal, select Manage > Namespace.

2. On the Namespace Management page, beside the namespace, click Edit.

3. On the Edit Namespace page, click Domain and type the name of the domain in the Domain field.

4. In the Groups field, type the names of the groups that you want to use to add users into the namespace.

ECS

The groups that you specify must exist in AD.

5. In the Attribute and Values fields, type the name of the attribute and the values for the attribute.

The specified attribute values for the users must match the attribute values specified in AD or LDAP.

If you do not want to use attributes to add users into the namespace, click the Attribute button with the trash can icon to remove the attribute fields.

6. Click Save.

Create a local management user or assign a domain user or AD group to a management role

You can create a local management user, and you can assign a management role to a local user, a domain user, or an AD group. Management users can perform system-level administration (VDC administration) and namespace administration. You can also remove the management role assignment.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

By default, the ECS root user is assigned the System Administrator role and can perform the initial assignment of a user to the System Administrator role.

To assign a domain user or an AD group to a management role, the domain users or AD group must have been added to ECS through an authentication provider. Adding an authentication

72 ECS Administration Guide

Users and Roles

provider must be performed by a System Administrator and is described in Add an AD or LDAP

authentication provider on page 46.

To assign the Namespace Administrator role to a management user, you must create a management user using the following procedure and perform the role assignment on the Edit Namespace page in the ECS Portal (see Assign the Namespace Administrator role to a user or

AD group on page 73). The user cannot log in until the Namespace Administrator role is

assigned.

Procedure

1. In the ECS Portal, select Manage > Users.

2. On the User Management page, click the Management Users tab.

3. Click New Management User.

4. Click AD/LDAP User or AD Group or Local User.

For a domain user, in the Username field, type the name of the user. The username and password that ECS uses to authenticate a user are held in AD or LDAP, so you do not need to define a password.

For an AD group, in the Group Name field, type the name of the group. The username and password that ECS uses to authenticate the AD group are held in AD, so you do not need to define a password.

For a local user, in the Name field, type the name of the user and in the Password field, type the password for the user.

Note:

User names can include uppercase letters, lowercase letters, numbers and any of

the following characters: ! # $ & ' ( ) * + , - . / : ; = ? @ _ ~

5. To assign the System Administrator role to the user or AD group, in the System Administrator box, click Yes.

If you select Yes, but later you want to remove System Administrator privileges from the user, you can edit this setting and select No.

6. To assign the System Monitor role to the user or AD group, in the System Monitor box, click Yes.

7. Click Save.

Assign the Namespace Administrator role to a user or AD group

You can assign the Namespace Administrator role to a local management user, a domain user, or AD group that exists in the ECS system.

Before you begin

This operation requires the System Administrator role in ECS.

Procedure

1. In the ECS Portal, select Manage > Namespace.

2. On the Namespace Management page, beside the namespace into which you want to assign the Namespace Administrator, click Edit.

3. On the Edit Namespace page:

a. For a local management user or a domain user, in the Namespace Admin field, type the

name of the user to whom you want to assign the Namespace Administrator role.

To add more than one Namespace Administrator, separate the names with commas.

A user can be assigned as the Namespace Administrator only for a single namespace.

ECS Administration Guide 73

Users and Roles

b. For an AD group, in the Domain Group Admin field, type the name of the AD group to

which you want to assign the Namespace Administrator role.

When the AD group is assigned the Namespace Administrator role, all users in the group are assigned this role.

An AD group can be the Namespace Administrator only for one namespace.

4. Click Save.

74 ECS Administration Guide

CHAPTER 7

Buckets

Introduction to buckets......................................................................................................... 76

Working with buckets in the ECS Portal................................................................................76

Create a bucket using the S3 API (with s3curl).....................................................................89

Bucket, object, and namespace naming conventions.............................................................92

Disable unused services.........................................................................................................94

ECS Administration Guide 75

Buckets

Introduction to buckets

Buckets are object containers that are used to control access to objects and to set properties that define attributes for all contained objects, such as retention periods and quotas.

In S3, object containers are called ECS. In Atmos, the equivalent of a bucket is a

container

In ECS, buckets are assigned a type, which can be S3, Swift, Atmos, or CAS. S3, Atmos, or Swift buckets can be configured to support file system access (for NFS and HDFS). A bucket that is configured for file system access can be read and written by using its object protocol and by using the NFS or HDFS protocol. S3 and Swift buckets can also be accessed using each other's protocol. Accessing a bucket using more than one protocol is often referred to as

support

You can create buckets for each object protocol using its API, usually using a client that supports the appropriate protocol. You can also create S3, file system-enabled (NFS or HDFS), and CAS buckets using the ECS Portal and the ECS Management REST API.

Bucket ownership

. In CAS, a bucket is a

buckets

CAS pool

and this term has been adopted as a general term in

subtenant

. In Swift, the equivalent of a bucket is a

cross-head

A bucket is assigned to a namespace and object users are also assigned to a namespace. An object user can create buckets only in the namespace to which the object user is assigned. An ECS System or Namespace Administrator can assign the object user as the owner of a bucket, or a grantee in a bucket ACL, even if the user does not belong to the same namespace as the bucket, so that buckets can be shared between users in different namespaces. For example, in an organization where a namespace is a department, a bucket can be shared between users in different departments.

Bucket access

Objects in a bucket that belong to a replication group spanning multiple VDCs can be accessed from all of the VDCs in the replication group. Objects in a bucket that belongs to a replication group that is associated with only one VDC can be accessed from only that VDC. Buckets cannot be accessed or listed from other VDCs that are not in the replication group. However, because the identity of a bucket and its metadata, such as its ACL, are global management information in ECS, and the global management information is replicated across the system storage pools, the existence of the bucket can be seen from all VDCs in the federation.

For information about how objects in buckets can be accessed during site outages, see TSO

behavior with the ADO bucket setting turned on on page 176.

Working with buckets in the ECS Portal

You can use the Bucket Management page available from Manage > Buckets to view the details of existing buckets in a selected namespace, to modify the Access Control List (ACL) for buckets, to modify the policy for buckets, and to delete buckets.

To ensure that the system works correctly, always have life cycle policies that are configured with versioned buckets.

Bucket settings

The following table describes the settings that you can specify when you create or edit a bucket:

76 ECS Administration Guide

Table 17 Bucket settings

Attribute Description Can be

Edited

Buckets

Name Name of the bucket. For information about bucket naming, see Bucket,

object, and namespace naming conventions on page 92.

Namespace Namespace with which the bucket is associated. No

Replication Group Replication group in which the bucket is created. No

Bucket Owner Bucket owner. Yes

File System Indicates whether the bucket can be used as a file system (NFS export or

No HDFS). To simplify access to the file system, a default group, and default permissions that are associated with the group, can be defined. For more information, see Default group on page 79.

Note: File system-enabled buckets only support the / delimiter when

listing objects.

CAS Indicates whether the bucket can be used for CAS data. No

Metadata Search Indicates that metadata search indexes are created for the bucket based on

No specified key values.

If turned on, metadata keys that are used as the basis for indexing objects in the bucket can be defined. These keys must be specified at bucket creation time.

After the bucket is created, search can be turned off altogether, but the configured index keys cannot be changed.

The way the attribute is defined is described in Metadata search fields on page 79.

Note: Metadata that is used for indexing is not encrypted, so metadata

search can still be used on a bucket when Server-side Encryption (D@RE) is turned on.

Access During Outage (ADO)

The ECS system behavior when accessing data in the bucket during a temporary site outage in a geo-federated setup.

If you turn this setting on, and a temporary site outage occurs, if you cannot access a bucket at the failed site where the bucket was created (owner site), you can access a copy of the bucket at another site. Note that objects that you access in the buckets in the namespace might have been updated at the failed site, but changes might not have been propagated to the site from which you are accessing the object.

If you turn this setting off, data in the site which has the temporary outage is not available for access from other sites, and object reads for data that is owned by the failed site will fail. This is the default ECS system behavior to maintain strong consistency by continuing to allow access to data owned by accessible sites and preventing access to data owned by a failed site.

Read-Only option: Specifies whether a bucket with the ADO setting that is turned on is accessible as read-only or read/write during a temporary site outage. If you select the Read-Only option, the bucket is only accessible in read-only mode during the outage.

Yes

ECS Administration Guide 77

Buckets

Table 17 Bucket settings (continued)

Attribute Description Can be

Edited

For more information, see TSO behavior with the ADO bucket setting

turned on on page 176.

Server-side Encryption Indicates whether server-side encryption is turned on or off.

If the bucket's namespace is encrypted, then every bucket is encrypted. If the namespace is not encrypted, you can select encryption for individual buckets.

For a complete description of the feature, see the

Configuration Guide

, available from the ECS Product Documentation

ECS Security

page.

Quota The storage space limit that is specified for the bucket. You can specify a

storage limit for the bucket and define notification and access behavior when the quota is reached. The quota setting for a bucket cannot be less than 1 GiB. You can specify bucket quota settings in increments of GiB. You can select one of the following quota behavior options:

Notification Only at <

quota_limit_in_GiB

> Soft quota setting at which

you are notified.

Block Access Only at <

quota_limit_in_GiB

> Hard quota setting which,

when reached, prevents write/update access to the bucket.

Block Access at < <

quota_limit_in_GiB

> and Send Notification at

> Hard quota setting which, when reached,

prevents write/update access to the bucket and the quota setting at which you are notified.

Note: Quota enforcement depends on the usage reported by ECS

metering. Metering is a background process that is designed so that it does not impact foreground traffic and so the metered value can lag the actual usage. Because of the metering lag, there can be a delay in the enforcement of quotas.

Yes

Bucket Tagging Name-value pairs that are defined for a bucket and enable buckets to be

classified. For more information about bucket tagging, see Bucket tagging on page 79.

Bucket Retention Retention period for a bucket.

The expiration of a retention period on an object within a bucket is calculated when a request to modify an object is made and is based on the value set on the bucket and the objects themselves.

The retention period can be changed during the lifetime of the bucket.

You can find more information about retention and applying retention periods and policies in Retention periods and policies on page 53.

78 ECS Administration Guide

Yes

Table 17 Bucket settings (continued)

Attribute Description Can be

Edited

Buckets

Auto-Commit Period Auto-commit period is the time interval in which the updates through NFS

are allowed for objects under retention. This attribute enables NFS files that are written to ECS to be WORM compliant. The interval is calculated from the last modification time. The auto-commit value must be less than or equal to the retention value with a maximum of 1 day. A value of 0 indicates no auto-commit period.

Default group

When you turn the File System setting on for a bucket to enable file system access, you can assign a default group for the bucket. The default group is a Unix group, the members of which have permissions on the bucket when it is accessed as a file system. Without this assignment, only the bucket owner can access the file system.

You can also specify Unix permissions that are applied to files and directories created using object protocols so that they are accessible when the bucket is accessed as a file system.

Metadata search fields

When you set the Metadata Search option to On for a bucket, objects in the bucket can be indexed based on their metadata fields. S3 object clients can search for objects based on the indexed metadata using a rich query language.

Each object has a set of system metadata that is automatically assigned, and can also have user assigned metadata. Both system and user metadata can be included in the index and used as the subject of metadata searches.

When metadata search is enabled on a bucket, you can select System or User as the metadata search Type. When you select a metadata search Type as System, metadata that is automatically assigned to objects in a bucket is listed for selection in the Name drop-down menu.

When you select a metadata search Type of User, you must specify the name of the user metadata to create an index for. You must also specify its data type so that ECS knows how to interpret the metadata values provided in search queries.

You can read more about the metadata search feature in the the ECS Product Documentation page.

ECS Data Access Guide

Yes

, available from

Bucket tagging

Bucket tags are key-value pairs that you can associate with a bucket so that the object data in the bucket can be categorized. For example, you could define keys like Project or Cost Center on each bucket and assign values to them. You can add up to ten tags to a bucket.

You can assign bucket tags and values using the ECS Portal or using a custom client through the ECS Management REST API. Bucket tags are included in the metering data reports displayed in the ECS Portal or retrieved using the ECS Management REST API.

Create a bucket

You can create and configure S3, S3+FS, or CAS buckets in the ECS Portal.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

ECS Administration Guide 79

Buckets

A System Administrator can create buckets in any namespace.

A Namespace Administrator can create buckets in the namespace in which they are the administrator.

About this task

For CAS-specific instructions on setting up a CAS bucket for a CAS object user, see

Access Guide

, available from the ECS Product Documentation page.

Procedure

1. In the ECS Portal, select Manage > Buckets.

2. On the Bucket Management page, click New Bucket.

3. On the New Bucket page, on the Basic tab, do the following:

a. In the Name field, type the bucket name.

b. In the Namespace field, select the namespace that you want the bucket and its objects

to belong to.

c. In the Replication Group field, select the replication group that you want to associate

the bucket with.

d. In the Bucket Owner field, type the bucket owner, or select the Set current user as

Bucket Owner checkbox.

The bucket owner must be an ECS object user for the namespace. If you do not specify a user, you are assigned as the owner. However, you cannot access the bucket unless your username is also assigned as an object user.

The user that you specify is given Full Control.

e. Click Next.

4. On the New Bucket page, on the Required tab, do the following:

ECS Data

a. In the File System field, click On to specify that the bucket supports operation as a file

system (for NFS or HDFS access).

The bucket is an S3 bucket that supports file systems.

You can set a default UNIX group for access to the bucket and for objects that are created in the bucket. For more information, see Default group on page 79.

b. In the CAS field, click On to set the bucket as a CAS bucket.

By default, CAS is disabled and the bucket is marked as an S3 bucket.

In the Reflection Expiration field, click On to configure an expiration time for reflections in the bucket.

In the Reflection Age field, select the appropriate expiration time. (The minimum expiration time is 1 day and the maximum is 99 years.)

If there is no configured expiration time for a reflection, the reflection is never deleted.

c. In the Metadata Search field, click On to specify that the bucket supports searches

based on object metadata.

If the Metadata Search setting is turned on, you can add user and system metadata keys that are used to create object indexes. For more information about entering metadata search keys, see Metadata search fields on page 79.

80 ECS Administration Guide

Note: If the bucket supports CAS, metadata search is automatically enabled and a

CreateTime key is automatically created. The metadata can be searched using the S3 metadata search capability or using the Centera API.

d. In the Access During Outage field, click On if you want the bucket to be available during

a temporary site outage. For more information about this option, see TSO behavior with

the ADO bucket setting turned on on page 176.

If the Access During Outage setting is turned on, you have the option of selecting the Read-Only checkbox to restrict create, update, or delete operations on the objects in the bucket during a temporary site outage. Once you turn the Read-Only option on for the bucket, you cannot change it after the bucket is created. For more information about this option, see TSO behavior with the ADO bucket setting turned

on on page 176.

e. In the Server-side Encryption field, click On to specify that the bucket is encrypted.

f. Click Next.

5. On the New Bucket page, on the Optional tab, do the following:

a. In the Quota field, click On to specify a quota for the bucket and select the quota setting

you require.

Buckets

Edit a bucket

The settings that you can specify are described in Bucket settings on page 76.

b. In the Bucket Tagging field, click Add to add tags, and type name-value pairs.

For more information, see Bucket tagging on page 79.

c. In the Bucket Retention Period field, type a time period to set a bucket retention period

for the bucket, or click Infinite if you want objects in the bucket to be retained forever.

For more information about retention periods, see Retention periods and policies on page

53.

d. In the Auto-Commit Period field, type a time period to enable updates to the files that

are under retention. The interval applies only to file enabled buckets.

The auto-commit value must be less than or equal to the retention value with a maximum of 1 day. A value of 0 indicates no auto-commit period.

e. Click Save to create the bucket.

Results

To assign permissions on the bucket for users or groups, see the tasks later in this section.

You can edit some bucket settings after the bucket has been created and after it has had objects that are written to it.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

A System Administrator can edit the settings for a bucket in any namespace.

A Namespace Administrator can edit the settings for a bucket in the namespace in which they are the administrator.

To edit a bucket, you must be assigned to the Namespace Administrator or System Administrator role.

ECS Administration Guide 81

Buckets

About this task

You can edit the following bucket settings:

Quota

Bucket Owner

Bucket Tagging

Access During Outage

Bucket Retention

Reflection Expiration and Reflection Age (for CAS buckets)

You cannot change the following bucket settings:

Replication Group

Server-side Encryption

File System

CAS

Metadata Search

Known issue with changing NFS bucket owners

If you change the bucket owner and try to revert the changes, reverting the bucket ownership does not work. You cannot access the NFS mount over the previous bucket owner until you reset the bucket ownership using the API mentioned in the support KB article KB 534080.

Set ACLs

Procedure

1. In the ECS Portal, select Manage > Buckets.

2. On the Bucket Management page, in the Buckets table, select the Edit action for the bucket for which you want to change the settings.

3. Edit the settings that you want to change.

You can find out more information about the bucket settings in Bucket settings on page 76.

4. Click Save.

The privileges a user has when accessing a bucket are set using an Access Control List (ACL). You can assign ACLs for a user, for a set of pre-defined groups, such as all users, and for a custom group.

When you create a bucket and assign an owner to it, an ACL is created that assigns a default set of permissions to the bucket owner - the owner is, by default, assigned full control.

You can modify the permissions assigned to the owner or you can add new permissions for a user by selecting the Edit ACL operation for the bucket.

In the ECS Portal, the Bucket ACLs Management page has User ACLs, Group ACLs, and Custom Group ACLs tabs to manage the ACLs associated with individual users and pre-defined groups, and to allow groups to be defined that can be used when accessing the bucket as a file system.

Note:

from the ECS Product Documentation page.

82 ECS Administration Guide

For information about ACLs with CAS buckets, see the

ECS Data Access Guide

, available

Bucket ACL permissions reference

The ACL permissions that can be assigned are provided in the following table. The permissions that are applicable depend on the type of bucket.

Table 18 Bucket ACLs

ACL Permission

Read Allows user to list the objects in the bucket.

Read ACL Allows user to read the bucket ACL.

Write Allows user to create or update any object in the bucket.

Write ACL Allows user to write the ACL for the bucket.

Execute Sets the execute permission when accessed as a file system. This

Full Control Allows user to Read, Write, Read ACL, and Write ACL.

Buckets

permission has no effect when the object is accessed using the ECS object protocols.

Note: Non-owners can Read, Write, Read ACL, and Write ACL if

the permission has been granted or can only list the objects.

Privileged Write Allows user to perform writes to a bucket or object when the user

does not have normal write permission. Required for CAS buckets.

Delete Allows user to delete buckets and objects. Required for CAS buckets.

None User has no privileges on the bucket.

Set the bucket ACL permissions for a user

The ECS Portal enables you to set the bucket ACL for a user or for a pre-defined group.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

A System Administrator can edit the ACL settings for a bucket in any namespace.

A Namespace Administrator can edit the ACL settings for a bucket n the namespace in which they are the administrator.

Procedure

1. In the ECS Portal, select Manage > Buckets.

2. On the Bucket Management page, locate the bucket that you want to edit in the table and select the Edit ACL action.

3. On the Bucket ACLs Management page, the User ACLs tab displays by default and shows the ACLs that have been applied to the users who have access to the bucket.

The bucket owner has default permissions that are assigned.

Note:

Because the ECS Portal supports S3, S3 + File system (HDFS or NFS), and CAS

buckets, the range of permissions that can be set are not applicable to all bucket types.

4. To set (or remove) the ACL permissions for a user that already has permissions that are assigned, in the ACL table, in the Action column, click Edit or Remove.

5. To add a user and assign ACL permissions to the bucket, click Add.

ECS Administration Guide 83

Buckets

a. Enter the username of the user that the permissions apply to.

b. Select the permissions for the user.

For more information about ACL permissions, see Bucket ACL permissions reference on page 83.

6. Click Save.

Set the bucket ACL permissions for a pre-defined group

You can set the ACL for a bucket for a pre-defined group from the ECS Portal.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

A System Administrator can edit the group ACL settings for a bucket in any namespace.

A Namespace Administrator can edit the group ACL settings for a bucket in the namespace in which they are the administrator.

Procedure

1. In the ECS Portal, select Manage > Buckets.

2. On the Bucket Management page, locate the bucket that you want to edit in the table and select the Edit ACL action.

3. Click the Group ACLs tab to set the ACL permissions for a pre-defined group.

4. Click Add.

5. The Edit Group page is displayed.

The group names are described in the following table:

Group

public All users, authenticated or not.

all users All authenticated users.

other Authenticated users but not the

log delivery Not supported.

6. Select the permissions for the group.

7. Click Save.

Set custom group bucket ACLs

You can set a group ACL for a bucket in the ECS Portal and you can set bucket ACLs for a group of users (Custom Group ACL), for individual users, or a combination of both. For example, you can grant full bucket access to a group of users, but you can also restrict (or even deny) bucket access to individual users in that group.

Before you begin

This operation requires the System Administrator or Namespace Administrator role in ECS.

A System Administrator can edit the group ACL settings for a bucket in any namespace.

A Namespace Administrator can edit the group ACL settings for a bucket in the namespace in which they are the administrator.

Description

bucket owner.

84 ECS Administration Guide

Buckets

About this task

Custom group ACLs enable groups to be defined and for permissions to be assigned to the group. The main use case for assigning groups to a bucket is to support access to the bucket as a file system. For example, when making the bucket available for NFS or HDFS.

Members of the UNIX group can access the bucket when it is accessed as a file system (using NFS or HDFS).

Procedure

1. In the ECS Portal, select Manage > Buckets.

2. On the Bucket Management page, locate the bucket that you want to edit in the table and select the Edit ACL action.

3. Click the Custom Group User ACLs tab to set the ACL for a custom group.

4. Click Add.

The Edit Custom Group page displays.

5. On the Edit Custom Group page, in the Custom Group Name field, type the name for the group.

This name can be a Unix/Linux group, or an Active Directory group.

6. Select the permissions for the group.

7. Click Save.

Set bucket policies

The ECS Portal provides a Bucket Policy Editor to enable you to create a bucket policy for an existing bucket.

For each bucket, you can define ACLs for an object user. Bucket policies provide greater flexibility than ACLs and allow fine grained control over permissions for bucket operations and for operations on objects within the bucket. Policy conditions are used to assign permissions for a range of objects that match the condition and are used to automatically assign permissions to newly uploaded objects.

Policies are defined in JSON format and the syntax used for policies is the same as that used for Amazon AWS. The operations for which permissions can be assigned are limited to those operations supported by ECS. For more information, see the the ECS Product Documentation page.

The bucket policy editor has a code view and a tree view. The code view, shown in the following screenshot, enables you to enter JSON policies from scratch or to paste existing policies into the editor and modified. For example, if you have existing policies in JSON format, you can paste them into the code view and modify them.

At a minimum you should assign Read, Write, Execute, and Read ACL.

ECS Data Access Guide

, available from

ECS Administration Guide 85

Buckets

Figure 8 Bucket Policy Editor code view

The tree view, shown in the following screenshot, provides a mechanism for navigating a policy and is useful where you have a large number of statements in a policy. You can expand and contract the statements and search them.

Figure 9 Bucket Policy Editor tree view

Bucket policy scenarios

In general, the bucket owner has full control on a bucket and can grant permissions to other users and can set S3 bucket policies using an S3 client. In ECS, it is also possible for an ECS System or Namespace Administrator to set bucket policies using the Bucket Policy Editor from the ECS Portal.

You can use bucket policies in the following typical scenarios:

Grant bucket permissions to a user

Grant bucket permissions to all users

Automatically assign permissions to created objects

86 ECS Administration Guide

Grant bucket permissions to a user

To grant permission on a bucket to a user apart from the bucket owner, specify the resource that you want to change the permissions for. Set the principal attribute to the name of the user, and specify one or more actions that you want to enable.

The following example shows a policy that grants a user who is named user1 the permission to update and read objects in the bucket that is named mybucket:

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

You can also add conditions. For example, if you only want the user to read and write object when accessing the bucket from a specific IP address, add a IpAddress condition as shown in the following policy:

Buckets

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

Grant bucket permissions to all users

To grant permission on a bucket to a user apart from the bucket owner, specify the resource that you want to change the permissions for. Set the principal attribute as anybody (*), and specify one or more actions that you want to enable.

The following example shows a policy that grants anyone permission to read objects in the bucket that is named mybucket:

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

ECS Administration Guide 87

Buckets

] }

Automatically assign permissions to created objects

You can use bucket policies to automatically enable access to ingested object data. In the following example bucket policy, user1 and user2 can create subresources (that is, objects) in the bucket that is named mybucket and can set object ACLs. With the ability to set ACLs, the users can then set permissions for other users. If you set the ACL in the same operation, a condition can be set. Such that a canned ACL public-read must be specified when the object is created. This ensures anybody can read all the created objects.

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

Create a bucket policy

You can create a bucket policy for a selected bucket using the Bucket Policy Editor in the ECS Portal.

Before you begin

This operation requires the System Administrator or Namespace Administrator role (for the namespace to which the bucket belongs).

About this task

You can also create a bucket policy in a text editor and deploy it using the ECS Management REST API or the S3 API.

Procedure

1. In the ECS Portal, select Manage > Buckets

2. From the Namespace drop-down, select the namespace to which the bucket belongs.

3. In the Actions column for the bucket, select Edit Policy from the drop-down menu.

4. Provided your policy is valid, you can switch to the tree view of the Bucket Policy Editor.

5. In the Bucket Policy Editor, type the policy or copy and paste a policy that you have

The tree view makes it easier to view your policy and to expand and contract statements.

previously created.

Some examples are provided in Bucket policy scenarios on page 86 and full details of the supported operations and conditions are provided in

ECS Data Access Guide

, available from

the ECS Product Documentation page.

6. Save.

88 ECS Administration Guide

The policy is validated and, if valid, the Bucket Policy Editor exits and the portal displays the Bucket Management page. If the policy is invalid, the error message provides information on the reason the policy is invalid.

Create a bucket using the S3 API (with s3curl)

You can use the S3 API to create a bucket in a replication group. Because ECS uses custom headers (x-emc), the string to sign must be constructed to include these headers. In this procedure the s3curl tool is used. There are also several programmatic clients you can use, for example, the S3 Java client.

Before you begin

To create a bucket, ECS must have at least one replication group configured.

Ensure that Perl is installed on the Linux machine on which you run s3curl.

Ensure that curl tool and the s3curl tool are installed. The s3curl tool acts as a wrapper around curl.

To use s3curl with x-emc headers, minor modifications must be made to the s3curl script. You can obtain the modified, ECS-specific version of s3curl from the EMCECS Git Repository.

Ensure that you have obtained a secret key for the user who will create the bucket. For more information, see

ECS Data Access Guide

, available from the ECS Product Documentation page.

Buckets

About this task

The EMC headers that can be used with buckets are described in Bucket HTTP headers on page

91.

Procedure

1. Obtain the identity of the replication group in which you want the bucket to be created, by typing the following command:

GET https://<ECS IP Address>:4443/vdc/data-service/vpools

The response provides the name and identity of all data services virtual pools. In the following example, the ID is urn:storageos:ReplicationGroupInfo:8fc8e19bedf0-4e81bee8-79accc867f64:global.

<data_service_vpools> <data_service_vpool> <creation_time>1403519186936</creation_time> <id>urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81-bee8-79accc867f64:global</ id> <inactive>false</inactive> <tags/> <description>IsilonVPool1</description> <name>IsilonVPool1</name> <varrayMappings> <name>urn:storageos:VirtualDataCenter:1de0bbc2-907c-4ede-b133-f5331e03e6fa:vdc1</ name> <value>urn:storageos:VirtualArray:793757ab-ad51-4038-b80a-682e124eb25e:vdc1</ value> </varrayMappings> </data_service_vpool> </data_service_vpools>

ECS Administration Guide 89

Buckets

2. Set up s3curl by creating a .s3curl file in which to enter the user credentials.

The .s3curl file must have permissions 0600 (rw-/---/---) when s3curl.pl is run.

In the following example, the profile my_profile references the user credentials for the user@yourco.com account, and root_profile references the credentials for the root account.

%awsSecretAccessKeys = ( my_profile => { id => 'user@yourco.com', key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN' }, root_profile => { id => 'root', key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN' }, );

3. Add the endpoint that you want to use s3curl against to the .s3curl file.

The endpoint is the address of your data node or the load balancer that sits in front of your data nodes.

push @endpoints , ( '203.0.113.10', 'lglw3183.lss.dell.com', );

4. Create the bucket using s3curl.pl and specify the following parameters:

Profile of the user

Identity of the replication group in which to create the bucket (<vpool_id>, which is set using the x-emc-dataservice-vpool header

Any custom x-emc headers

Name of the bucket (<BucketName>).

The following example shows a fully specified command:

./s3curl.pl --debug --id=my_profile --acl public-read-write

--createBucket -- -H 'x-emc-file-system-access-enabled:true'

-H 'x-emc-dataservice-vpool:<vpool_id>' http://<DataNodeIP>:9020/<BucketName>

The example uses thex-emc-dataservice-vpool header to specify the replication group in which the bucket is created and the x-emc-file-system-access-enabled header to enable the bucket for file system access, such as for NFS or HDFS.

90 ECS Administration Guide

Note:

T2he -acl public-read-write argument is optional, but can be used to set permissions to enable access to the bucket. For example, if you intend to access to bucket as NFS from an environment that is not secured using Kerberos.

If successful, (with --debug on) output similar to the following is displayed:

s3curl: Found the url: host=203.0.113.10; port=9020; uri=/S3B4; query=; s3curl: ordinary endpoint signing case s3curl: StringToSign='PUT\n\n\nThu, 12 Dec 2013 07:58:39 +0000\nx-amz-acl:public-readwrite \nx-emc-file-system-access-enabled:true\nx-emc-dataservice-vpool: urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81-bee8-79accc867f64:global:\n/S3B4' s3curl: exec curl -H Date: Thu, 12 Dec 2013 07:58:39 +0000 -H Authorization: AWS root:AiTcfMDhsi6iSq2rIbHEZon0WNo= -H x-amz-acl: public-read-write -L -H content-type:

--data-binary -X PUT -H x-emc-file-system-access-enabled:true

-H x-emc-dataservice-vpool:urn:storageos:ObjectStore:e0506a04-340b-4e78a694-4c389ce14dc8: http://203.0.113.10:9020/S3B4

After you finish

You can list the buckets using the S3 interface, using:

./s3curl.pl --debug --id=my_profile http://<DataNodeIP>:9020/

Bucket HTTP headers

Buckets

There are various headers that determine the behavior of ECS when creating buckets using the objects APIs.

The following x-emc headers are provided:

Table 19

Header Description

x-emc-dataservice-vpool Determines the replication group is used to store the objects associated

x-emc-file-system-access-enabled Configures the bucket for NFS or HDFS access. The header must not

x-emc-namespace Specifies the namespace that is used for this bucket. If the namespace is

x-emc-retention-period Specifies the retention period that is applied to objects in a bucket. Each

Bucket headers

with this bucket. If you do not specify a replication group using the x- emc-dataservice-vpool header, ECS selects the default replication group that is associated with the namespace.

conflict with the interface that is used. That is, a create bucket request from NFS or HDFS cannot specify x-emc-file-system-access- enabled=false.

not specified using the S3 convention of host-style or path-style request, and then it is specified using the x-emc-namespace header. If the namespace is not specified in this header, the namespace that is associated with the user is used.

time a request is made to modify an object in a bucket, the expiration of the retention period for the object is calculated based on the retention period that is associated with the bucket.

x-emc-is-stale-allowed Specifies whether the bucket is accessible during a temporary VDC

outage in a federated configuration.

x-emc-server-side-encryption-enabled Specifies whether objects that are written to a bucket are encrypted.

ECS Administration Guide 91

Buckets

Table 19 Bucket headers (continued)

Header Description

x-emc-metadata-search Specifies one or more user or system metadata values that are used to

create indexes of objects for the bucket. The indexes are used to perform object searches that are filtered based on the indexed metadata.

Bucket, object, and namespace naming conventions

Bucket and object (also referred to as key) names for the S3, OpenStack Swift, Atmos, and CAS protocols must conform to the ECS specifications described in this section.

Note: To use a bucket for HDFS, you must not use underscores in the bucket name as they are

not supported by the URI Java class. For example, viprfs://my_bucket.ns.site/ is an invalid URI and is thus not understood by Hadoop.

Namespace name

The following rules apply to the naming of ECS namespaces:

Cannot be null or an empty string

Length range is 1..255 (Unicode char)

Valid characters are defined by regex /[a-zA-Z0-9-_]+/. That is, alphanumeric characters and hyphen (-) and underscore (_) special characters.

S3 bucket and object naming in ECS

Bucket and object names must conform to the ECS naming specification when using the ECS S3 Object API.

Bucket name

The following rules apply to the naming of S3 buckets in ECS:

Must be between one and 255 characters in length. (S3 requires bucket names to be 1–255 characters long)

Can include dot (.), hyphen (-), and underscore (_) characters and alphanumeric characters ([a-zA-Z0-9])

Can start with a hyphen (-) or alphanumeric character.

Cannot start with a dot (.)

Cannot contain a double dot (..)

Cannot end with a dot (.)

Must not be formatted as IPv4 address.

You can compare this with naming restriction that is specified by the S3 specification: http://

docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html.

Object name

The following rules apply to the naming of S3 objects in ECS:

Cannot be null or an empty string

Length range is 1..255 (Unicode char)

92 ECS Administration Guide

No validation on characters

OpenStack Swift container and object naming in ECS

Container and object names must conform to the ECS naming specification when using the ECS OpenStack Swift Object API.

Container name

The following rules apply to the naming of Swift containers:

Cannot be null or an empty string

Length range is 1..255 (Unicode char)

Can include dot (.), hyphen (-), and underscore (_) characters and alphanumeric characters ([a-zA-Z0-9])

Can include the at symbol (@) with the assistance of your customer support representative.

Object name

The following rules apply to the naming of Swift objects:

Cannot be null or an empty string

Length range is 1..255 (Unicode char)

No validation on characters

Buckets

Atmos bucket and object naming in ECS

Subtenant and object names must conform to the ECS naming specification when using the ECS Atmos Object API.

Subtenant (bucket)

The subtenant is created by the server, so the client does not need to know the naming scheme.

Object name

The following rules apply to the naming of Atmos objects:

Cannot be null or an empty string

Length range is 1..255 (Unicode characters)

No validation on characters

Name should be percent-encoded UTF-8.

CAS pool and object naming in ECS

clips

CAS pools and objects ( specification when using the CAS API.

CAS pool naming

The following rules apply to the naming of CAS pools in ECS:

Can contain a maximum of 255 characters

Cannot contain: ' " / & ? * < > <tab> <newline> or <space>

in CAS terminology) names must conform to the ECS naming

Clip naming

The CAS API does not support user-defined keys. When an application using CAS API creates a clip, it opens a pool, creates a clip, and adds tags, attributes, streams and so on. After a clip is complete, it is written to a device.

ECS Administration Guide 93

Buckets

A corresponding clip ID is returned by the CAS engine and can be referred to using <pool name>/ <clip id>.

Disable unused services

This section provides you information about the ECS supported services and the available connection options.

About this task

ECS supports the following services and the connection options to connect to those services:

S3 - http/https/https,http/disabled

Atmos - http/https/https,http/disabled

Swift - http/https/https,http/disabled

HDFS - enabled/disabled

NFS - enabled/disabled

CAS - enabled/disabled

The service waits on the key for changes and takes appropriate action. For example, S3 waits for changes to the S3 key. When it realizes that HTTP is no longer requested, then you cannot connect to the service using the HTTP protocol.

To update a single service, run:

PUT /service/{service_name} { "name": "{service_name}", "settings": ["setting1", "setting2", "settingN"] }

For example,

PUT /service/atmos { "name": "atmos", "settings": ["disabled"] }

To update multiple services, run:

PUT /service { "service": [{ "name": "{service_name}", "settings": ["setting1", "setting2", "settingN"] }, { "name": "{service_name}", "settings": ["setting1", "setting2", "settingN"] }]

For example,

PUT /service { "service": [{

94 ECS Administration Guide

"name": "s3", "settings": ["http", "https"] }, { "name": "swift", "settings": ["http"] }, { "name": "cas", "settings": ["enabled"] }] }

Buckets

ECS Administration Guide 95

Buckets

96 ECS Administration Guide

CHAPTER 8

File Access

Introduction to file access..................................................................................................... 98

ECS multi-protocol access.................................................................................................... 98

Working with NFS exports in the ECS Portal........................................................................101

Working with user/group mappings in the ECS Portal..........................................................101

ECS NFS configuration tasks...............................................................................................102

Mount an NFS export example............................................................................................. 112

NFS access using the ECS Management REST API..............................................................114

NFS WORM (Write Once, Read Many)................................................................................ 115

S3A support..........................................................................................................................118

Geo-replication status.......................................................................................................... 119

ECS Administration Guide

File Access

Introduction to file access

ECS allows you to configure object buckets for access as NFS file systems using NFSv3.

In the ECS Portal, you can make ECS buckets and the directories within them accessible as file systems to Unix users by:

creating NFS exports of ECS buckets and specifying the hosts that you want to be able to access the export.

mapping ECS object users/groups to Unix users/groups so that the Unix users can access the NFS export.

Mapping the ECS bucket owner to a Unix ID gives that Unix user permissions on the file system. In addition, ECS allows you to assign a default custom group to the bucket so that members of a Unix group mapped to the ECS default custom group can access the bucket.

ECS NFS supports:

multi-protocol access, so that files written using NFS can also be accessed using object protocols, and vice versa.

Kerberos security

advisory locking and locking over multiple sites as well as shared and exclusive locks.

The ECS NFS configuration tasks that you can perform in the ECS Portal can also be performed using the ECS Management REST API or CLI.

ECS multi-protocol access

ECS supports multi-protocol access, so that files written using NFS can also be accessed using Amazon Simple Storage Service (Amazon S3), OpenStack Swift, and EMC Atmos object protocols. Similarly, objects written using S3 and OpenStack Swift object protocols can be made available through NFS. For Atmos, objects created using the namespace interface can be listed using NFS, however, objects created using an object ID cannot. Objects and directories created using object protocols can be accessed by Unix users and by Unix group members by mapping the object users and groups.

S3/NFS multi-protocol access to directories and files

ECS supports writing objects using the S3 protocol and accessing them as files using NFS and, conversely, writing files using NFS and accessing the files as objects using the S3 protocol. You must understand how directories are managed when you use multi-protocol access.

The S3 protocol does not make provision for the creation of folders or directories.

To enable multi-protocol operation, ECS support for the S3 protocol formalizes the use of / and creates c.txt results in the creation of a file object named c.txt and directory objects for a and b. The directory objects are not exposed to users through the S3 protocol, and are maintained only to provide multi-protocol access and compatibility with file system-based APIs. This means that ECS can display files within a directory structure when the bucket is viewed as an NFS or HDFS file system.

Multi-protocol access permissions

Objects can be accessed using NFS and using the object service. Each access method has a way of storing permissions: Object Access Control List (ACL) permissions and File System permissions.

When an object is created or modified using the object protocol, the permissions associated with the object owner are mapped to NFS permissions and the corresponding permissions are stored. Similarly, when an object is created or modified using NFS, ECS maps the NFS permissions of the owner to object permissions and stores them.

The S3 object protocol does not have the concept of groups. Changes to group ownership or permissions from NFS do not need to be mapped to corresponding object permissions. When you create a bucket or an object within a bucket (the equivalent of a directory and a file), ECS can assign Unix group permissions, and they can be accessed by NFS users.

For NFS, the following ACL attributes are stored:

Owner

Group

Other

For object access, the following ACLs are stored:

Users

Custom Groups

Groups (Pre-defined)

Owner (a specific user from Users)

Primary Group (a specific group from Custom Groups)

For more information on ACLs, see Set ACLs on page 82.

The following table shows the mapping between NFS ACL attributes and object ACL attributes.

File Access

NFS ACL attribute

Owner User who is also Owner

Group Custom Group that is also Primary Group

Others Pre-Defined Group

Object ACL attribute

Examples of this mapping are discussed later in this topic.

The following Access Control Entries (ACE) can be assigned to each ACL attribute.

NFS ACEs:

ECS Administration Guide 99

File Access

Read (R)

Write (W)

Execute (X)

Object ACEs:

Read (R)

Write (W)

Execute (X)

ReadAcl (RA)

WriteAcl (WA)

Full Control (FC)

Creating and modifying an object using NFS and accessing using the object service

When an NFS user creates an object using the NFS protocol, the owner permissions are mirrored to the ACL of the object user who is designated as the owner of the bucket. If the NFS user has RWX permissions, Full Control is assigned to the object owner through the object ACL.

The permissions that are assigned to the group that the NFS file or directory belongs to are reflected onto a custom group of the same name, if it exists. ECS reflects the permissions associated with Others onto pre-defined groups permissions.

The following example illustrates the mapping of NFS permissions to object permissions.

NFS ACL Setting Object ACL Setting

Owner John : RWX Users John : Full Control Group ecsgroup : R-X ---> Custom Groups ecsgroup : R-X Other RWX Groups All_Users : R, RA Owner John Primary Group ecsgroup

When a user accesses ECS using NFS and changes the ownership of an object, the new owner inherits the owner ACL permissions and is given Read_ACL and Write_ACL. The previous owner permissions are kept in the object user's ACL.

When a chmod operation is performed, the ECS reflects the permissions in the same way as when creating an object. Write_ACL is preserved in Group and Other permissions if it already exists in the object user's ACL.

Creating and modifying objects using the object service and accessing using NFS

When an object user creates an object using the object service, the user is the object owner and is automatically granted Full Control of the object. The file owner is granted RWX permissions. If the owner permissions are set to other than Full Control, ECS reflects the object RWX permissions onto the file RWX permissions. An object owner with RX permissions results in an NFS file owner with RX permissions. The object primary group, which is set using the Default Group on the bucket, becomes the Custom Group that the object belongs to and the object permissions are set based on the default permissions that have been set. These permissions are reflected onto the NFS.group permissions. If the object Custom Group has Full Control, these permissions become the RWX permissions for the NFS group. If pre-defined groups are specified on the bucket, these are applied to the object and are reflected as Others permissions for the NFS ACLs.

The following example illustrates the mapping of object permissions onto NFS permissions.

Object ACL Setting NFS ACL

100 ECS Administration Guide

Dell ECS Administration Guide

Specifications and Main Features

Frequently Asked Questions

User Manual

CONTENTS

FIGURES

TABLES

Overview

Introduction

ECS platform

ECS data protection

Configurations for availability, durability, and resilience

ECS network

Load balancing considerations

Getting Started with ECS

Initial configuration

Log in to the ECS Portal

View the Getting Started Task Checklist

View the ECS Portal Dashboard

Upper-right menu bar

View requests

View capacity utilization

View performance

View storage efficiency

View geo monitoring

View node and disk health

View alerts

Storage Pools, VDCs, and Replication Groups

Introduction to storage pools, VDCs, and replication groups

Working with storage pools in the ECS Portal

Create a storage pool

Edit a storage pool

Working with VDCs in the ECS Portal

Create a VDC for a single site

Add a VDC to a federation

Edit a VDC

Remove VDC from a Replication Group

Fail a VDC (PSO)

Guidelines to check failover and bootstrap process

Working with replication groups in the ECS Portal

Create a replication group

Edit a replication group

Authentication Providers

Introduction to authentication providers

Working with authentication providers in the ECS Portal

Considerations when adding Active Directory authentication providers

AD or LDAP authentication provider settings

Add an AD or LDAP authentication provider

Add a Keystone authentication provider

Namespaces

Introduction to namespaces

Namespace tenancy

Working with namespaces in the ECS Portal

Namespace settings

Create a namespace

Edit a namespace

Delete a namespace

Users and Roles

Introduction to users and roles

Users in ECS

Management users

Default management users

Object users

Domain and local users

User scope

User tags

Management roles in ECS

System Administrator

System Monitor

Namespace Administrator

Lock Administrator

Tasks performed by role

Working with users in the ECS Portal

Add an object user

Add a domain user as an object user

Add domain users into a namespace

Create a local management user or assign a domain user or AD group to a management role

Assign the Namespace Administrator role to a user or AD group

Buckets

Introduction to buckets