OpenStack Swift for Disaster Recovery



Evolving Swift where a single cluster can be distributed over multiple, geographically dispersed sites, joined via high-latency network connections.
Disaster Recovery will be the mechanism for continued operations when you have multiple Swift environments in various locations. In this context DR is a continued workload operations in an alternative deployment, the recovery target clouds.

OpenStack Swift in itself has architecture to deal with disasters by way of data replication to Zones that are distributed across datacenter. Swift can uniquely place replicas according to drives, nodes, racks, PDUs, network segments and datacenter rooms.

A new concept of “Region” is introduced in Swift. A Region is bigger than a Zone and extends the concept of Tiered Zones. The proxy nodes will have an affinity to a Region and be able to optimistically write to storage nodes based on the storage nodes’ Region. Affinity makes the proxy server prefer local backend servers for object PUT requests over non-local ones.

More reading:-

Openstack Install Guide (


** Some distinguish HA from DR by networking scope – LAN for HA and WAN for DR, in the cloud context a better distinction is probably the autonomy of management.
** To add more capacity to the cluster, Add new capacity to the ring with increased weight.
** To add more regions to the cluster, Change ring and add replica count by a fractional amount e.g. 3 -> 3.1 in ring.
** Replication traffic needs to be bandwidth-limited across WAN links, both for responsiveness and for cost.
** Objects(Actual data), that can help in recreating entire Swift setup after the proxy server recovery. A simple rebalance of the Rings can be used to redistribute
the data to nodes added/recovered as a part of disaster recovery and mitigation.

** To check the replication location
swift-get-nodes -a /etc/swift/object.ring.gz AUTH_adasdbd771e3cd5f2da exampledir examplefile.txt


** To check disk utilization across the cluster
swift-recon -d –top 10

** To monitor cpu/memory
top -b -d 5 -u swift

** To monitor the replication and bandwidth utilization use speedometer on ubuntu
speedometer -b -r eth0 -t eth1
speedometer -b -r eth1

Below Graph from speedometer shows that data get transfered to SWIFT from client on eth0 , once transfer completed the replication to remote site starts on eth1.


This entry was posted in ObjectStorage, OpenStack and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s