Understanding and managing Object services

Use the following information to manage services related to IBM Spectrum Scale™ for object storage.

IBM Spectrum Scale uses the mmces service command to enable, start, stop, or disable Object services on all protocol nodes.

The enable and disable operations are cluster-wide operations. To enable or disable the Object protocol, use mmces service [enable | disable] OBJ. The Object protocol must have been initially configured using the mmobj swift base command before it can be enabled in the cluster.

CAUTION:
Disabling the object service unconfigures the Object protocol and discards OpenStack Swift configuration and ring files from the CES cluster. If Openstack Keystone configuration is configured locally, disabling object storage also discards the Keystone configuration and database files from the CES cluster. However, to avoid accidental data loss, the associated filesets used for the object data are not automatically removed during disable. The filesets for the object data and any filesets created for optional object storage policies need to be removed manually. For enabling the object service subsequently, either different fileset names need to be specified or the existing filesets need to be cleaned up. For information on cleaning up the object filesets, see the steps "Remove the fileset created for object" and "Remove any fileset created for an object storage policy"(if applicable) in the Cleanup procedures required if reinstalling with the spectrumscale installation toolkit topic of IBM Spectrum Scale: Concepts, Planning, and Installation Guide.
Note: To disable the object protocol, first remove the object authentication. For complete usage information, see the mmuserauth command.

In addition, enabled Object service can be started and stopped on individual nodes or cluster-wide.

To start or stop the Object protocol cluster-wide. use -a flag mmces service [start | stop] OBJ -a.

To start or stop the Object protocol on individual nodes, use mmces service [start | stop] OBJ -N <node>.

Attention: If object services on a protocol node are stopped by the administrator manually, access to object data might be impacted unless the CES IP addresses are first moved to another node. There are multiple ways to accomplish this, but the simplest is to suspend the node. After suspending a node, CES automatically moves the CES IPs to the remaining nodes in the cluster. However, doing this suspends operation for all protocols running on that protocol node.
If you want to stop object services on a protocol node, you can use the following steps:
  1. Suspend CES operations on the protocol node using the mmces node suspend command.
  2. View the CES IP addresses on that node using the mmces address list command and verify that all CES IP addresses have been moved to other protocol nodes.
  3. Stop the object services using the mmces service stop OBJ command.
Performing these steps ensures that object functionality is available on other nodes in the cluster.
To restore object services on that protocol node, you can use the following steps:
  1. Resume CES operations on the protocol node using the mmces node resume command.
  2. View the CES IP addresses on that node using the mmces address list command and verify that all CES IP addresses have been moved to that protocol node.
  3. Start the object services using the mmces service start OBJ command.
Use the mmces service list command to list the protocols enabled on IBM Spectrum Scale. List a verbose output of object services running on the local node using the -v flag as shown in the following example:
# mmces service list -v
Enabled services: OBJ SMB NFS
 OBJ is running
	OBJ:openstack-swift-object                   is running
	OBJ:openstack-swift-account                  is running
	OBJ:openstack-swift-container                is running
	OBJ:openstack-swift-proxy                    is running
	OBJ:memcached                                is running
	OBJ:openstack-swift-object-replicator        is running
	OBJ:openstack-swift-account-reaper           is running
	OBJ:openstack-swift-account-replicator       is running
	OBJ:openstack-swift-container-replicator     is running
	OBJ:openstack-swift-object-sof               is running
	OBJ:httpd (keystone)                         is running 
 SMB is running 
 NFS is running

For complete usage information, see mmces command.

Every object protocol node can access every virtual device in the shared file system, and some OpenStack Swift object services can be optimized to take advantage of this by running from a single Object protocol node.

Even though objects are not replicated by OpenStack Swift, the swift-object-replicator runs to periodically clean up tombstone files from deleted objects. It is run on a single Object protocol node and manages cleanup for all of the virtual devices.

The swift-object-updater is responsible for updating container listings with objects that were not successfully added to the container when they were initially created, updated, or deleted. Like the object replicator, it is run on a single object protocol node.

The following table shows each of the object services and the set of object protocol nodes on which they need to be executed.

Table 1. Object services and object protocol nodes
Object service GPFS™ protocol node
ibmobjectizer object-singleton_node 1
openstack-swift-account All
openstack-swift-account-auditor object_singleton_node
openstack-swift-account-reaper All
openstack-swift-account-replicator All
openstack-swift-container All
openstack-swift-container-auditor object_singleton_node
openstack-swift-container-updater object_singleton_node
openstack-swift-container-replicator All
openstack-swift-object All
openstack-swift-object-auditor object_singleton_node 2
openstack-swift-object-replicator All
openstack-swift-object-sof All 1
openstack-swift-object-updater object_singleton_node
openstack-swift-object-expirer object_singleton_node
openstack-swift-proxy All
memcached All
openstack-keystone All 3, 4
postgresql-obj object_database_node 3

1 If unified file and object access is enabled.
2 If multi-region object deployment  is enabled.
3 If local OpenStack Keystone Identity Service is configured.
4 Updated to httpd (keystone) on all nodes, if using local authentication.