Ring files are a kind of catalog of the files that are stored within the Swift storage engine and where within the storage cluster they are stored. As content is written to the Swift object storage cluster, these ring files are updated across the storage cluster and on the proxy server. When alternative storage backends are used in place of the Swift object storage engine, they mock the ring file system that the proxy expects and map this ring file system to its storage engine. Because the Swift proxy service always expects a set of ring files to operate, it is important to know how these are generated and installed. Learning how to set up ring files for the Swift object storage engine will teach you the basics that will translate into object storage backed by alternative storage engines.
There are various ring files that must all be generated and copied to each of the servers that will use the ring files. These include the account, container, and object rings. To generate these rings, each of the devices on each of the storage servers need to be added to the ring files, and the files need to be rebalanced before they are copied. In our example installation in Chapter 1, RDO Installation, Packstack did the setting up for us. This example is intended to give you an idea of how ring files are generated for future interactions you may have with generating these ring files.
Let's use an example architecture that will include three storage nodes and one device on each of the nodes. If the IP addresses 192.168.123.11, 192.168.123.12, and 192.168.123.13 were the storage nodes and if each of them had a partition on a second drive named sdb1, then these three devices across the servers would be added to a new set of ring files using the swift-ring-builder command. First, create the ring files; this can be done on any of the storage nodes, and then the ring files will be copied to the other nodes. Here's how we use the swift-ring-builder command:
storage-node$ swift-ring-builder account.builder create 12 3 24 storage-node$ swift-ring-builder container.builder create 12 3 24 storage-node$ swift-ring-builder object.builder create 12 3 24
Here, you see a create command for each of the types of ring files. The three numbers behind the create command are the part power (12), replica count (3), and minimum part hours (24). There are partitions created within the Swift storage engine that help Swift to distribute the storage properly. The number of partitions is equal to 2 raised to the part power (12). In this example, 2^12 means that 4,096 partitions will be created in each ring. The replica count is how many copies of each item will be stored; it is recommended that you use three here. The minimum part hours is the minimum number of hours before a partition can be moved in succession. Swift recommends 24 as a good value for the minimum part hours. For more information on these values, search the Internet for Swift preparing the rings and you should find the official Swift documentation that goes into greater detail on how to choose values for these properties. Next, add the devices to the rings using the Swift ring builder command again. Here's how we go about it:
storage-node$ swift-ring-builder account.builder add z1- 192.168.123.11:6002/sdb1 100 storage-node$ swift-ring-builder account.builder add z1- 192.168.123.12:6002/sdb1 100 storage-node$ swift-ring-builder account.builder add z1- 192.168.123.13:6002/sdb1 100 storage-node$ swift-ring-builder account.builder rebalance storage-node$ swift-ring-builder container.builder add z1- 192.168.123.11:6001/sdb1 100 storage-node$ swift-ring-builder container.builder add z1- 192.168.123.12:6001/sdb1 100 storage-node$ swift-ring-builder container.builder add z1- 192.168.123.13:6001/sdb1 100 storage-node$ swift-ring-builder container.builder rebalance storage-node$ swift-ring-builder object.builder add z1- 192.168.123.11:6000/sdb1 100 storage-node$ swift-ring-builder object.builder add z1- 192.168.123.12:6000/sdb1 100 storage-node$ swift-ring-builder object.builder add 192.168.123.13:6000/sdb1 100 storage-node$ swift-ring-builder object.builder rebalance
In this example, there is only one zone used that is referenced by z1- as a prefix to each of the IP addresses. It is recommended that a minimum of five zones are used to avoid conflicts within zones on the same IP address. Behind each of the addresses and device names in these commands, there is a weight. This weight helps Swift to determine how many partitions are placed on the device relative to the rest of the devices in the cluster. It is recommended that you start with 100 times the number of terabytes on the drive. When this is complete, you should be able to list the files in your /etc/swift directory and see a .ring.gz file for each of the ring types. These are the files that need to be copied to each of the storage nodes and the Swift proxy server node before services are started. Also, ensure that these files on each of the nodes are owned by root:swift.
Once these files are in place across the servers, the services can be started. Note that Swift's configuration files do not reference the other servers in the storage cluster. The servers reference each other by way of ring files. These ring files can also be updated to help Swift work around hardware failures in the storage cluster. Just make sure that any changes that are made are copied across the cluster so that the ring files match on all the nodes.