Chapter 3. Configuration recommendations for the Object Storage service (swift)
Chapter 3. Configuration recommendations for the Object Storage service (swift) If you choose not to deploy Red Hat OpenStack Platform (RHOSP) with Red Hat Ceph Storage, RHOSP director deploys the RHOSP Object Storage service (swift). The Object Store service is the object store for several OpenStack services, including the RHOSP Telemetry service and RabbitMQ. Here are several recommendations to improve your RHOSP performance when using the Telemetry service with the Object Storage service. 3.1. Disk recommendation for the Object Storage service Use one or more separate disks for the Red Hat OpenStack Platform (RHOSP) Object Storage service. By default, RHOSP director uses the directory /srv/node/d1 on the system disk for the Object Storage service. On the Controller this disk is also used by other services, and the disk could become a performance bottleneck after the Telemetry service starts recording events in an enterprise setting. The following example is a excerpt from an RHOSP Orchestration service (heat) custom environment file. On each Controller node, the Object Storage service uses two separate disks. The entirety of both disks contains an XFS file system: SwiftRawDisks defines each storage disk on the node. This example defines both sdb and sdc disks on each Controller node. Important When configuring multiple disks, ensure that the Bare Metal service (ironic) uses the intended root disk. Additional resources Defining the Root Disk for Nodes in the Director Installation and Usage guide. 3.2. Topology recommendation for the Object Storage service Define dedicated nodes for the Red Hat OpenStack Platform (RHOSP) Object Storage service. Doing this prevents any disk I/O by the RHOSP Telemetry service from impacting any other services on the Controller node. 3.2.1. Defining dedicated Object Storage nodes Dedicating a node to the Red Hat OpenStack Platform (RHOSP) Object Storage service improves performance. Procedure Create a custom roles_data.yaml file (based on the default /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ). Edit the custom roles_data.yaml file by removing the Object Storage service entry from the Controller node. Specifically, remove the following line from the ServicesDefault list of the Controller role: Use the ObjectStorageCount resource in your custom environment file to set how many dedicated nodes to allocate for the Object Storage service. For example, add ObjectStorageCount: 3 to the parameter_defaults in your environment file to deploy three dedicated object storage nodes: To apply this configuration, deploy the overcloud, adding roles_data.yaml to the stack along with your other environment files: Additional resources Composable Services and Custom Roles in the Advanced Overcloud Customization guide Adding and Removing Services from Roles in the Advanced Overcloud Customization guide Replacing Object Storage Nodes in the Director Installation and Usage guide Modifying the Overcloud Environment in the Director Installation and Usage guide 3.3. Partition power recommendation for the Object Storage service When using separate Red Hat OpenStack Platform (RHOSP) Object Storage service nodes, use a higher partition power value. The Object Storage service distributes data across disks and nodes using modified hash rings . There are three rings by default: one for accounts, one for containers, and one for objects. Each ring uses a fixed parameter called partition power . This parameter sets the maximum number of partitions that can be created. The partition power parameter is important and can only be changed for new containers and their objects. As such, it is important to set this value before initial deployment . The default partition power value is 10 for environments that RHOSP director deploys. This is a reasonable value for smaller deployments, especially if you only plan to use disks on the Controller nodes for the Object Storage service. The following table helps you to select an appropriate partition power if you use three replicas: Table 3.1. Appropriate partition power values per number of available disks Partition Power Maximum number of disks 10 ~ 35 11 ~ 75 12 ~ 150 13 ~ 250 14 ~ 500 Important Setting an excessively high partition power value (for example, 14 for only 40 disks) negatively impacts replication times. To set the partition power, use the following resource: Tip You can also configure an additional object server ring for new containers. This is useful if you want to add more disks to an Object Storage service deployment that initially uses a low partition power. Additional resources Configure an Object Storage Ring in the Storage Guide The Rings in swift upstream documentation Modifying the Overcloud Environment in the Director Installation and Usage guide
parameter_defaults: SwiftRawDisks: {"sdb": {}, "sdc": {}} - OS::TripleO::Services::SwiftStorage parameter_defaults: ObjectStorageCount: 3 (undercloud) USD openstack overcloud deploy --templates -e [your environment files] -e /home/stack/templates/roles_data.yaml parameter_defaults: SwiftPartPower: 11