Chapter 6. Migrating the Object Storage service to Red Hat OpenStack Services on OpenShift nodes


If you are using the Red Hat OpenStack Platform Object Storage service (swift) as an Object Storage service, you must migrate your Object Storage service to Red Hat OpenStack Services on OpenShift nodes.

If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see Migrate the Red Hat Ceph Storage cluster. If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in Deploying a Ceph ingress daemon and Create or update the Object Storage service endpoints.

The data migration happens replica by replica. For example, if you have 3 replicas, move them one at a time to ensure that the other 2 replicas are still operational, which enables you to continue to use the Object Storage service during the migration.

Note

Data migration to the new deployment is a long-running process that executes mostly in the background. The Object Storage service replicators move data from old to new nodes, which might take a long time depending on the amount of storage used. To reduce downtime, you can use the old nodes if they are running and continue with adopting other services while waiting for the migration to complete. Performance might be degraded due to the amount of replication traffic in the network.

The Object Storage service (swift) migration involves the following steps:

  1. Add new nodes to the Object Storage service rings.
  2. Set weights of existing nodes to 0.
  3. Rebalance rings by moving one replica.
  4. Copy rings to old nodes and restart services.
  5. Check replication status and repeat the previous two steps until the old nodes are drained.
  6. Remove the old nodes from the rings.

Prerequisites

  • Adopt the Object Storage service. For more information, see Adopting the Object Storage service.
  • For DNS servers, ensure that all existing nodes are able to resolve the hostnames of the Red Hat OpenShift Container Platform (RHOCP) pods, for example, by using the external IP of the DNSMasq service as the nameserver in /etc/resolv.conf:

    $ oc get service dnsmasq-dns -o jsonpath="{.status.loadBalancer.ingress[0].ip}" | $CONTROLLER1_SSH sudo tee /etc/resolv.conf
    Copy to Clipboard Toggle word wrap
  • Track the current status of the replication by using the swift-dispersion tool:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-populate'
    Copy to Clipboard Toggle word wrap

    The command might need a few minutes to complete. It creates 0-byte objects that are distributed across the Object Storage service deployment, and you can use the swift-dispersion-report afterward to show the current replication status:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-dispersion-report'
    Copy to Clipboard Toggle word wrap

    The output of the swift-dispersion-report command looks similar to the following:

    Queried 1024 containers for dispersion reporting, 5s, 0 retries
    100.00% of container copies found (3072 of 3072)
    Sample represents 100.00% of the container partition space
    Queried 1024 objects for dispersion reporting, 4s, 0 retries
    There were 1024 partitions missing 0 copies.
    100.00% of object copies found (3072 of 3072)
    Sample represents 100.00% of the object partition space
    Copy to Clipboard Toggle word wrap

Procedure

  1. Add new nodes by scaling up the SwiftStorage resource from 0 to 3:

    $ oc patch openstackcontrolplane openstack --type=merge -p='{"spec":{"swift":{"template":{"swiftStorage":{"replicas": 3}}}}}'
    Copy to Clipboard Toggle word wrap

    This command creates three storage instances on the Red Hat OpenShift Container Platform (RHOCP) cluster that use Persistent Volume Claims.

  2. Wait until all three pods are running and the rings include the new devices:

    $ oc wait pods --for condition=Ready -l component=swift-storage
    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-builder object.builder search --device pv'
    Copy to Clipboard Toggle word wrap
  3. From the current rings, get the storage management IP addresses of the nodes to drain:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-ring-builder object.builder search _' | tail -n +2 | awk '{print $4}' | sort -u
    Copy to Clipboard Toggle word wrap

    The output looks similar to the following:

    172.20.0.100
    swift-storage-0.swift-storage.openstack.svc
    swift-storage-1.swift-storage.openstack.svc
    swift-storage-2.swift-storage.openstack.svc
    Copy to Clipboard Toggle word wrap
  4. Drain the old nodes. In the following example, the old node 172.20.0.100 is drained:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c '
    swift-ring-tool get
    swift-ring-tool drain 172.20.0.100
    swift-ring-tool rebalance
    swift-ring-tool push'
    Copy to Clipboard Toggle word wrap

    Depending on your deployment, you might have more nodes to include in the command.

  5. Copy and apply the updated rings to the original nodes. Run the ssh commands for your existing nodes that store the Object Storage service data:

    $ oc extract --confirm cm/swift-ring-files
    $CONTROLLER1_SSH "tar -C /var/lib/config-data/puppet-generated/swift/etc/swift/ -xzf -" < swiftrings.tar.gz
    $CONTROLLER1_SSH "systemctl restart tripleo_swift_*"
    Copy to Clipboard Toggle word wrap
  6. Track the replication progress by using the swift-dispersion-report tool:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c "swift-ring-tool get && swift-dispersion-report"
    Copy to Clipboard Toggle word wrap

    The output shows less than 100% of copies found. Repeat the command until all container and object copies are found:

    Queried 1024 containers for dispersion reporting, 6s, 0 retries
    There were 5 partitions missing 1 copy.
    99.84% of container copies found (3067 of 3072)
    Sample represents 100.00% of the container partition space
    Queried 1024 objects for dispersion reporting, 7s, 0 retries
    There were 739 partitions missing 1 copy.
    There were 285 partitions missing 0 copies.
    75.94% of object copies found (2333 of 3072)
    Sample represents 100.00% of the object partition space
    Copy to Clipboard Toggle word wrap
  7. Move the next replica to the new nodes by rebalancing and distributing the rings:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c '
    swift-ring-tool get
    swift-ring-tool rebalance
    swift-ring-tool push'
    
    $ oc extract --confirm cm/swift-ring-files
    $CONTROLLER1_SSH "tar -C /var/lib/config-data/puppet-generated/swift/etc/swift/ -xzf -" < swiftrings.tar.gz
    $CONTROLLER1_SSH "systemctl restart tripleo_swift_*"
    Copy to Clipboard Toggle word wrap

    Monitor the swift-dispersion-report output again, wait until all copies are found, and then repeat this step until all your replicas are moved to the new nodes.

  8. Remove the nodes from the rings:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c '
    swift-ring-tool get
    swift-ring-tool remove 172.20.0.100
    swift-ring-tool rebalance
    swift-ring-tool push'
    Copy to Clipboard Toggle word wrap
    Note

    Even if all replicas are on the new nodes and the swift-dispersion-report command reports 100% of the copies found, there might still be data on the old nodes. The replicators remove this data, but it might take more time.

Verification

  1. Check the disk usage of all disks in the cluster:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-recon -d'
    Copy to Clipboard Toggle word wrap
  2. Confirm that there are no more \*.db or *.data files in the /srv/node directory on the nodes:

    $CONTROLLER1_SSH "find /srv/node/ -type f -name '*.db' -o -name '*.data' | wc -l"
    Copy to Clipboard Toggle word wrap

You can troubleshoot issues with the Object Storage service (swift) migration.

  • If the replication is not working and the swift-dispersion-report is not back to 100% availability, check the replicator progress to help you debug:

    $ CONTROLLER1_SSH tail /var/log/containers/swift/swift.log | grep object-server
    Copy to Clipboard Toggle word wrap

    The following shows an example of the output:

    Mar 14 06:05:30 standalone object-server[652216]: <f+++++++++ 4e2/9cbea55c47e243994b0b10d8957184e2/1710395823.58025.data
    Mar 14 06:05:30 standalone object-server[652216]: Successful rsync of /srv/node/vdd/objects/626/4e2 to swift-storage-1.swift-storage.openstack.svc::object/d1/objects/626 (0.094)
    Mar 14 06:05:30 standalone object-server[652216]: Removing partition: /srv/node/vdd/objects/626
    Mar 14 06:05:31 standalone object-server[652216]: <f+++++++++ 85f/cf53b5a048e5b19049e05a548cde185f/1710395796.70868.data
    Mar 14 06:05:31 standalone object-server[652216]: Successful rsync of /srv/node/vdb/objects/829/85f to swift-storage-2.swift-storage.openstack.svc::object/d1/objects/829 (0.095)
    Mar 14 06:05:31 standalone object-server[652216]: Removing partition: /srv/node/vdb/objects/829
    Copy to Clipboard Toggle word wrap
  • You can also check the ring consistency and replicator status:

    $ oc debug --keep-labels=true job/swift-ring-rebalance -- /bin/sh -c 'swift-ring-tool get && swift-recon -r --md5'
    Copy to Clipboard Toggle word wrap

    The output might show a md5 mismatch until approximately 2 minutes after pushing the new rings. After the 2 minutes, the output looks similar to the following example:

    [...]
    Oldest completion was 2024-03-14 16:53:27 (3 minutes ago) by 172.20.0.100:6000.
    Most recent completion was 2024-03-14 16:56:38 (12 seconds ago) by swift-storage-0.swift-storage.openstack.svc:6200.
    ===============================================================================
    [2024-03-14 16:56:50] Checking ring md5sums
    4/4 hosts matched, 0 error[s] while checking hosts.
    [...]
    Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat