After completing this section, you should be able to describe the purpose, benefits and operations for object-based storage use cases. Create and manage containers, folders and objects.

Object storage, first and foremost, is simply an available OpenStack resource that can be implemented by your OpenStack configuration personnel in multiple ways. Swift is an object storage service and API for working with stored objects, regardless of the back end implementation. Swift, as an OpenStack service, actually has two APIs; the standard Swift API, and an Amazon S3 compatible API. Developers choose whichever API they prefer to use in their object-using applications. Red Hat OpenStack Platform installs Ceph as the default storage for all other storage service requirements, including the object storage requirements of the Image Service. Swift, however, is not configured to use Ceph as its back end, but instead uses local devices to build a Swift-native back end.

The comparison between having Swift use its own native storage format and the using Ceph object storage is discussed on the following section that discusses object storage technologies. Ceph also offers two APIs for direct access of its object storage service, the Swift API, and the Amazon S3 compatible API. However, using the Ceph APIs directly would bypass the OpenStack infrastructure, leaving OpenStack without access to object storage activities and metrics. In Red Hat OpenStack Platform environments, developers use the Swift service instead of going directly to Ceph.

The domain operator can be asked to advise cloud users about object storage as a resource for specific application use cases. For example, the backup and archiving of images and snapshots, static content, and file sharing. An object container or object store is the best storage method for unorganized small objects. These objects can easily be shared, anyone with the public URL access to objects in the container can save them locally.

The five major use cases for Openstack object storage are described below.

An object is stored as a binary file along with metadata which is stored in the file's extended attributes (xattrs). Objects can be text files, videos, images, emails, or virtual machine images. Objects are simply identified with a GUID and have no relationship to other objects in the container.

Objects can be stored in pseudo-directories by including a forward-slash in the object name. Using a forward-slash as the delimiter during queries makes the results appear as if the objects are laid out in directories.

When an object is created, it is owned by an account. For example, an OpenStack project or service. The account service uses a database to track which containers are owned by which account. The object service also uses a database to track and store container objects.

The Object Storage service uses virtual object containers to allow users to store and retrieve files and other data objects without a file system interface. Object redundancy is provided through software-based data replication. Object storage is well suited to data center deployments across different geographical areas.

Storage Replicas are used to maintain the state of objects in the case of outage. A minimum of three replicas is recommended. Storage Zones are used to host replicas. Zones ensure that each replica of a given object can be stored separately. A zone might represent an individual disk drive or array, a server, all the servers in a rack, or even an entire data center.

Storage Regions are a group of zones sharing a location. Regions can be groups of servers or server farms, usually located in the same geographical area. Regions have a separate API endpoint per Object Storage Service installation, which allows for discrete separation of services.

Many of the OpenStack services use swift for object storage. Glance creates images but cannot actually store them, it utilizes swift as an image store Cinder backups can also be stored in swift. The Nova service can create snapshots of instances which are passed to Glance for storage in a swift container. Ironic stores introspection results as objects in swift. Ironic bare metal images are stored in a swift container. Swift also supports the Amazon Simple Storage Service (S3) API.

[user@demo ~(admin)]$ openstack container create demo-container1
+------------------+-----------------+-------------+
| account          | container       | x-trans-id  |
+------------------+-----------------+-------------+
| AUTH_c0cb...e5cd | demo-container1 | txf6...52f5 |
+------------------+-----------------+-------------+

[user@demo ~(admin)]$ openstack object create demo-container1 cdr.object
+------------+-----------------+-------------+
| object     | container       | etag        |
+------------+-----------------+-------------+
| cdr.object | demo-container1 | 598d...9fe5 |
+------------+-----------------+-------------+

[user@demo ~(admin)]$ openstack object show demo-container1 cdr.object
+----------------+---------------------------------------+
| Field          | Value                                 |
+----------------+---------------------------------------+
| account        | AUTH_c0cbb4890bcd45828bf31dc1d64fe5cd |
| container      | demo-container1                       |
| content-length | 8462                                  |
| content-type   | application/octet-stream              |
| etag           | 598d1e6b4f0a3583244e1b4e09b49fe5      |
| last-modified  | Thu, 25 Jun 2020 07:35:50 GMT         |
| object         | cdr.object                            |
+----------------+---------------------------------------+

[user@demo ~(admin)]$ openstack object save demo-container1 cdr.object

[user@demo ~(admin)]$ openstack container delete \
> demo-container1 --recursive

One of the main differences between block storage and object storage is that a volume can only be accessed via instances, and by one instance at a time, whereas any instance or service can access the objects stored in containers because all objects stored within Swift have an accessible URL.

Object storage has several distinct advantages over volume storage. Object storage is accessible from any OpenStack service, and is fully distributed. Swift is best used for large pools of small objects.

Many Telecommunication companies produce massive amounts of call data records or CDR data. Those records need to be accessed by many applications and users, possibly in many geographical locations. Therefore, object storage is the best storage method for this kind of data as it can be accessed using a public URL. It is also the most cost effective method of storage for massive amounts of data. In object storage you only pay for the storage that is actually used. For example, if you upload 5 GB then you pay for that exact amount of storage. In volume storage you pay for the size of the disk created. If you create a 50 GB volume, you will pay for all 50 GB whether it is all used. However, be aware that if you use Swift over multiple data centers, then the cost can increase due to replication and network bandwidth requirements.

CDR data has many uses, primarily for billing, but also analysis using Big Data techniques. Analysis of CDR data can provide near-realtime monitoring, analysis of usage patterns, or even early warning for potential issues and outages. It also allows Telecommunication organizations to make capacity predictions and plan upgrades accordingly.

Many medical researchers work on projects simultaneously in many geographical locations. Object storage can be used to easily store and share the results of tests, diagnostics, or to archive medical data. Offloading archive data from primary storage has many benefits, the first being cost savings. It can also reduce backup complexities because properly configured object storage protects itself. Object storage requires no additional software to store data and therefore does not require any specific data protection.

It is possible to create, manage, and delete containers and objects using the Dashboard.

Navigate to Project+Object Store → Containers. To create a new container click +Container. Enter a container name, click either Public or Not Public, then click Submit.

Figure 6.1: Container creation in the Dashboard

To upload an object into the container, click the container name. Click the upload button, browse to find the file to upload and click Upload File. To view the details of a specific object, click the actions menu and select view details. Note that the unique ID for the object is not named etag in the Dashboard, it is named Hash. The etag and hash are two names for the same attribute. The value of this attribute is the calculated MD5 hash of the object. This hash only applies to a complete object, so it cannot be used to integrity check partial downloads caused by performing a range GET. The hash value will be recalculated whenever the object is updated.

Figure 6.2: Object details in the Dashboard

An object can be deleted by clicking on Delete in the Actions menu. A container can be deleted by clicking on the dustbin icon next to its name. A window appears asking to confirm the deletion, click Delete. Note that a container can only be deleted in the Dashboard if it is empty. There is no force option to delete the container and all of its objects when using the Dashboard. Containers can only be deleted recursively from the command line.