Support replicating objects in handoff partitions first

Bug #1878087 reported by Drew Freiberger
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Swift Storage Charm
Fix Released
Undecided
Drew Freiberger

Bug Description

In extreme cases of object rebalance or node failure, swift environments with millions of objects may have a hard time with objects landing in handoff or misplaced partitions and the operator of the cloud may need to prioritize migrating data in handoff partitions back to primary partitions over the 3 primary partitions replicating amongst each other.

To allow for this, the object-server.conf configuration can have handoffs_first set to True which will force the object-replicators to focus on handoff partitions before syncing primary partitions for any given object partition.

This will priorize draining the 4th, 5th, 6th, ... nth copy of objects from incorrect locations back to the 3 primary disks for that object's partition over copying that object from one primary copy to the other 2 primary disks.

This is an extreme setting as noted by the product documentation, but is needed for environments where multiple swift-ring rebalances have been performed before the prior replications have had a chance to complete.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-swift-storage (stable/18.08)

Fix proposed to branch: stable/18.08
Review: https://review.opendev.org/726939

Revision history for this message
Drew Freiberger (afreiberger) wrote :

It appears that this feature is congruent to the standalone_replicator for > trusty and should potentially only be allowed on trusty clouds.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on charm-swift-storage (stable/18.08)

Change abandoned by Drew Freiberger (<email address hidden>) on branch: stable/18.08
Review: https://review.opendev.org/726939
Reason: merging to master instead. abandoning stable backport

Changed in charm-swift-storage:
assignee: nobody → Drew Freiberger (afreiberger)
Revision history for this message
Andrea Ieri (aieri) wrote :

Subscribing field-medium since we need this urgently for a customer.
We have a merge proposal ready, we only need a review and a merge.

Revision history for this message
Paul Goins (vultaire) wrote :

For clarity, the updated review appears to be here: https://review.opendev.org/#/c/726942/

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-swift-storage (master)

Reviewed: https://review.opendev.org/726942
Committed: https://git.openstack.org/cgit/openstack/charm-swift-storage/commit/?id=9809a3b347ce68aacaef6a7b4284fc58fe28d790
Submitter: Zuul
Branch: master

commit 9809a3b347ce68aacaef6a7b4284fc58fe28d790
Author: Drew Freiberger <email address hidden>
Date: Mon May 11 15:00:03 2020 -0500

    Add support for object replication handoffs_first

    In extreme cases of object rebalance or node failure, swift environments
    with millions of objects may have a hard time with objects landing in
    handoff or misplaced partitions and the operator of the cloud may need
    to prioritize migrating data in handoff partitions back to primary
    partitions over the 3 primary partitions replicating amongst each other.

    To allow for this, the object-server.conf [object-replicator]
    configuration can have handoffs_first set to True which will force
    the object-replicators to focus on handoff partitions before syncing
    primary partitions for any given object partition.

    Change-Id: I8b44c287567a0e6d634def0b13baf0fe4ad4aa7b
    Closes-Bug: 1878087

Changed in charm-swift-storage:
status: In Progress → Fix Committed
James Page (james-page)
Changed in charm-swift-storage:
milestone: none → 20.05
David Ames (thedac)
Changed in charm-swift-storage:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.