IBM Cloud Object Storage System Version Packed Slice Storage IBM DSNADM_PSS D

IBM Cloud Object Storage System ^™

Version 3.14.6

Packed Slice Storage

DSNADM_PSS-20160318D

IBM

Note

Before using this information and the product it supports, read the following information:

v The general information in Notices

v The information in Safety and environmental notices

v The information in the IBM Environmental Notices and User Guide (provided on a DVD)

This edition applies to IBM Cloud Object Storage System

and is valid until replaced by new editions.

© Copyright IBM Corporation 2016, 2019.

US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract

with IBM Corp.

Contents

Chapter 1. Overview . . . 1

Chapter 2. New capabilities . . . 3

Chapter 3. Benefits . . . 5

Chapter 4. Terminology and components 7 Chapter 5. Workflows . . . 9

Writing an object . . . . . . . . . . . . . 9

Writing a slice to an existing bin . . . . . . . 9

Writing a slice to a new bin . . . . . . . . 9

Committing a slice . . . . . . . . . . . 9

Finalizing a slice. . . . . . . . . . . . 10

Reading a slice . . . . . . . . . . . . . 10

Deleting a slice . . . . . . . . . . . . . 10

Listing a slice. . . . . . . . . . . . . . 10

Compacting a bin file . . . . . . . . . . . 11

Improved performance with small objects . . . . 11

Deploying to new storage pools only . . . . . . 11

Chapter 6. Deploying . . . 13

Chapter 7. Operations . . . 15

Index . . . 17

Trademarks. . . 19

Homologation statement . . . 21

© Copyright IBM Corp. 2016, 2019

iii

iv

Chapter 1. Overview

IBM Cloud Object Storage System

provides various interfaces to store and retrieve objects on an IBM Cloud Object Storage Slicestor

system.

Every object is converted into a set of system-addressable entities called data sources. For every object, a metadata data source and zero or more object data sources exists. Metadata data sources contain system object metadata, while object data sources contain user-supplied object data. If an object is relatively small, all of the object data will be embedded in the metadata object and no data object sources will be generated. In addition, to support name listing operations, the system maintains additional data sources that store a name index.

Each data source undergoes multiple transformations and additional data is added to guarantee data reliability and integrity. The result of these transformations are called slices: pieces of data sufficient to recreate the original data with bit-level accuracy as long as a defined threshold of slices out of the entire defined IDA width are available. Slices are sent to IBM Cloud Object Storage Slicestor

nodes, which persist each slice to a specific disk for long-term data storage. The process by which a IBM Cloud Object Storage Slicestor

appliance organizes, persists, and retrieves slices on a given disk is called a backend storage methodology.

Traditionally, all data source slices have been stored with the File Slice Storage (FSS) backend storage mechanism. File Slice Storage stores slices as one file per slice. While this generally works well, there are disadvantages for smaller slices (metadata data source slices):

v Significant storage overhead per slice v Inefficient structure for listing slices v Low throughput and IOPS

© Copyright IBM Corp. 2016, 2019

1

2

Chapter 2. New capabilities

Release 3.4.0 introduced a new backend storage methodology called Packed Slice Storage (PSS). Packed Slice Storage works in conjunction with File Slice Storage; it stores metadata data source slices efficiently while other data source slices continue to be managed by File Slice Storage.

v PSS is shared storage for all vaults deployed on a given Slicestor

Node.

v PSS greatly improves performance in the storage and retrieval of small objects.

© Copyright IBM Corp. 2016, 2019

3

4

Chapter 3. Benefits

PSS offers the following benefits:

v Use storage space more efficiently.

v Read objects with greater efficiency: single seek in most cases.

v Write objects with greater efficiency: data is appended to the end of one of a fixed number of files that PSS maintains.

v Improve IOPS and lowered latency. In most cases, no actual I/O occurs when trying to read non-existent slices.

v Reduce the burden on underlying file system.

v Improve listing operations in both speed and system resources utilized.

v Perform at the same level for long periods at a wide range of fills due to the reduced load on underlying drives.

© Copyright IBM Corp. 2016, 2019

5

6

Chapter 4. Terminology and components

PSS instance

A set of Bin Files on a single drive. One is deployed separately per drive. There are as many instances as there are active drives in a running Slicestor node.

Bin Files (128 per drive)

The source for all data associated with a PSS instance. Bin files are used for all data-related operations and to recover other components in disaster recovery situations. Each bin file contains a header, and zero or more bins.

Bin A container that stores zero or more slices that can be referenced individually in a bin file. Slices are assigned to bins based on a slice name hash value.

Note: Potentially, multiple slices could share a bin, which is known as a hash collision. The number of bins on disk is large enough to avoid frequent hash collisions.

In-memory pointers

All bin locations are stored in memory; these in-memory pointers are used when servicing normal client IO. The amount of pointers that can be held depends on available system memory at the time of storage pool creation.

Pointer file (one per disk)

Every running PSS instance maintains a log-based journal file for bin locations written to PSS. It is used to restore bin references to system memory during system startup only. It is not needed to perform operations. The pointer file is appended with bin references each time a slice is written.

It is periodically compressed to remove old pointer values.

Catalog (one instance per disk)

A database that holds extant slice names and their revisions. This database allows for efficient client object slice listing operations.

© Copyright IBM Corp. 2016, 2019

7

8

Chapter 5. Workflows

Writing an object

Writing an Object to PSS works exactly like FSS. Writes are completed in three phases: write, commit, and finalize.

Write Slice data is written to disk. The slice is now durable, but cannot be read back until it is committed.

Commit

Data is made visible to client systems or APIs. An attempt to access this object will succeed. The commit phase starts once slices are written to a number of IBM Cloud Object Storage Slicestor

nodes equal to the IDA Write Threshold.

Finalize

If the object being written is an update of an existing object, the previous revision of the data is removed from the system when it is finalized. The finalize phase starts once slices have been committed to a number of IBM Cloud Object Storage Slicestor

nodes equal to the IDA Write Threshold.

Writing a slice to an existing bin

If the slice is being written to an existing bin:

1. The slicename is hashed to determine bin file and bin number.

2. Existence of an in-memory pointer indicates the bin in question already exists on disk.

3. The bin location is retrieved from the in-memory pointers.

4. The entire bin is read into system memory.

5. The bin is modified to include the new slice data.

6. The entire new bin is appended to the end of the bin file.

7. The in-memory bin pointers are updated to reflect the new position of this bin.

8. The Pointer File is updated with the new location of the bin.

Writing a slice to a new bin

About this task

You can write a slice to a new bin.

Procedure

1. The slicename is hashed to determine bin file and bin number.

2. Non-existence of an in-memory pointer indicates the bin in question does not already exist on disk.

3. A new bin is created in memory containing the slice.

4. The new bin is appended to the appropriate bin file.

5. The in-memory bin pointers are updated to reflect the new position of this bin.

6. The Pointer File is updated with the location of the new bin.

Committing a slice

1. The slicename is hashed to determine bin file and bin number.

2. The bin location is retrieved from in-memory pointers.

© Copyright IBM Corp. 2016, 2019

9

3. The bin header is updated in place on disk to reflect that the slice data has been committed.

4. The Catalog is updated with the name of the slice data and its current revision.

Finalizing a slice

About this task

You can finalize a slice.

Procedure

1. The slicename is hashed to determine bin file and bin number.

2. The bin location is retrieved from in-memory pointers.

3. The bin header is updated in place on disk to reflect that old revisions of the slice data have been finalized.

4. Old revision entries for the slice data are removed from the Catalog.

Reading a slice

About this task

A slice can be read.

Procedure

1. The slicename is hashed to determine bin file and bin number.

2. The bin location is retrieved from in-memory pointers.

3. The bin is read from disk using said location.

Results

The slice is sent to the IBM Cloud Object Storage Accesser

node for reassembly into an object to be sent to the client system.

Deleting a slice

About this task

A slice can be deleted.

Procedure

1. The slicename is hashed to determine bin file and bin number.

2. The bin location is retrieved from in-memory pointers.

3. The bin header is modified in place on disk to indicate the slice has been deleted.

Results

Deletes are committed and finalized like normal writes.

Listing a slice

All slice names are stored in the Catalog. Any list operations request the slice names from the Catalog and return the requested values.

10

Compacting a bin file

Some write (if overwriting a bin is required) and delete operations remove references to the affected bin, making the contained data inaccessible. The unreferenced bin still occupies space in a bin file. The

process of removing unreferenced bins from bin files is called compaction. It is executed in the background without disrupting regular storage functions. Compaction occurs more frequently when disk utilization is close to 100% to reclaim unused space more quickly.

Improved performance with small objects

PSS has advantages over FSS as it uses a predictable access pattern to store and retrieve data.

v A read operation requires a single seek to find the location of a bin containing the requested slice on a disk.

v A write operation always appends the content of a slice as part of an associated bin to a bin file based on hash value for this slice name. If an affected bin already exists, it has to be first read, then modified with the content of the new slice and then appended to the bin file. Checking for the existence of a bin prior to a write operation does not require disk access or any I/O operations.

PSS exhibits far less performance degradation than FSS over the system lifetime. Read and write operation performance does not degrade due to number of objects. During compaction, performance could degrade temporarily.

Deploying to new storage pools only

PSS can be deployed on new storage pools only. All vaults sharing a PSS-enabled pool would have relevant slices stored in PSS. There is no mechanism to grant PSS access on the vault level. PSS improves performance and improves disk space utilization when used in CSO mode with large number of objects under 10 MB in size. The impact is especially significant when system load is dominated by objects smaller than 100 KB. PSS could improve latency even for large objects when storage pools have a variety of object sizes.

Note: Do not enable PSS for pools exclusively used with SO vaults.

Note: For workloads that contain exclusively large object sizes, PSS does not offer any performance benefits.

Chapter 5. Workflows

11

12

Chapter 6. Deploying

About this task

You can deploy the software.

Procedure

1. Create a storage pool:

a. Click the Configure tab.

b. Click the link Create Storage Pool in the Summary section.

Storage pools can have different capacity nodes. A model group, consisting of nodes that can be included in the same storage pool, must be selected. If nodes across multiple sites are available, the required site must be selected. If a storage pool will have nodes spanning multiple sites, balance the nodes across the sites. Not balancing the nodes can introduce read or write availability issues in the case of a single site outage.

2. Type a name for this storage pool in the Name field.

3. Select an IDA width for this storage pool from the Width drop-down box.

4. Select the Packed Storage radio button to enable packed slice storage for this storage pool.

Note: Contact support to determine if enabling packed slice storage will benefit current storage needs.

Note: Packed storage can only be enabled when all IBM Cloud Object Storage Slicestor

nodes have been upgraded to 3.4.

5. Nodes may be selected either automatically (Suggest Devices) per the above rules, or manually. To select multiple devices:

a. Select the first node.

b. Hold down the B key.

c. Select the last device.

6. Once the devices are identified, click Save to create the Storage Pool.

CAUTION: If there is not an even distribution of Slicestor

Nodes across the available sites where the loss of one site would make Vaults either unusable or read-only, the Manager Web Interface displays a confirmation dialog box that asks the operator if they accept the settings with the risks they present:

The selected devices are not balanced evenly across sites. This could lead to read and write availability issues in the case of a site outage. Do you still wish to continue?

You can click Cancel or OK to change or keep the settings.

From the Configure Storage Pool page, click Change to rename this storage pool or Monitor > to shortcut to the monitor function for this storage pool. A different storage pool may be selected from the Storage Pool landing page.

© Copyright IBM Corp. 2016, 2019

13

14

Chapter 7. Operations

Quarantined disk events are typically generated with a reason code parameter.

The table below provides reason codes for packed storage.

Table 1. Reason codes

Code Reason

30 An unreadable pointer file. Contact support.

31 An unreadable catalog file. Contact support.

32 An invalid packed directory structure. Contact support.

33 Too many unreadable bin files - retention area is full. Contact support.

Example of new event message for packed slice storage:

Disk in drive bay <bay> with S/N <serial> is quarantined, due to an unreadable pointer file. Please contact Customer Support. Reason code is 30.

© Copyright IBM Corp. 2016, 2019

15

16

Index H

homologation statement 21

T

trademarks 19

© Copyright IBM Corp. 2016, 2019

17

18

Trademarks

IBM

, the IBM logo, and ibm.com

are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at Copyright and trademark information at www.ibm.com/legal/copytrade.shtml.

Accesser

, Cleversafe

, ClevOS

, Dispersed Storage

, dsNet

, IBM Cloud Object Storage Accesser

, IBM Cloud Object Storage Dedicated

, IBM Cloud Object Storage Insight

, IBM Cloud Object Storage

Manager

, IBM Cloud Object Storage Slicestor

, IBM Cloud Object Storage Standard

, IBM Cloud Object Storage System

, IBM Cloud Object Storage Vault

, SecureSlice

, and Slicestor

are trademarks or registered trademarks of Cleversafe, an IBM Company and/or International Business Machines Corp.

Other product and service names might be trademarks of IBM or other companies.

© Copyright IBM Corp. 2016, 2019

19

20

Homologation statement

This product may not be certified in your country for connection by any means whatsoever to interfaces of public telecommunications networks. Further certification may be required by law prior to making any such connection. Contact an IBM representative or reseller for any questions.

© Copyright IBM Corp. 2016, 2019

21

22

IBM®

Printed in USA