Day-to-day administration of our OpenStack Object Storage cluster involves ensuring the files within the cluster are replicated to the right number of nodes, reporting on usage within the cluster, and dealing with failure of the cluster. This particular field builds upon the work in Using OpenStack Object Storage., to show you the tools and processes required to administer OpenStack Object Storage.
OpenStack Object Storage doesn’t have any dependencies on any particular filesystem, as long as that filesystem supports extended attributes (xattr). It has been generally acknowledged that the XFS filesystem yields the best all-round performance and resilience.
Before we start, we need to add a disk to our swift node. To do this, edit your Vagrant file to include the following section:
Next, start your Swift node:
vagrant up swift
Log in to a swift node that has a disk ready to be formatted for use with OpenStack Object Storage:
vagrant ssh swift
Carry out the following steps to prepare a hard drive for use within an OpenStack Object Storage node. For this, we will assume our new drive is ready for use, has been set up with an appropriate partition, and is now ready for formatting. Take for example the partition /dev/sdb1.
1. To format it for use, using XFS, we run the following command:
2. This produces a summary screen of the new drive and partition, as follows:
3. Once formatted, we set the mount options in our /etc/fstab file, as follows:
4. Create the mount point, and mount the filesystem as follows:
How it works…
While it is recommended, you do thorough testing of OpenStack Object Storage for your own environments, it is generally recommended that you use the XFS filesystem. OpenStack Object Storage requires a filesystem that supports extended attributes (xattr) and it has been shown that XFS offers good all-round performance in all areas.
In order to accommodate the metadata used by OpenStack Object Storage, we increase the inode size to 1024. This is set at the time of the format with the -i size=1024 parameter.
Further performance considerations are set at mount time. We don’t need to record file access times (noatime) and directory access times (nodiratime). Barrier support flushes the write-back cache to disk at an appropriate time. Disabling this yields a performance boost, as the highly available nature of OpenStack Object Storage allows for the failure of a drive (and therefore, write of data), so this safety net in our filesystem can be disabled (with the nobarrier option), to increase speed.
OpenStack Interview Questions
Free Demo for Corporate & Online Trainings.