TY - JOUR
T1 - On the Synchronization Bottleneck of OpenStack Swift-Like Cloud Storage Systems
AU - Ruan, Mingkang
AU - Titcheu, Thierry
AU - Zhai, Ennan
AU - Li, Zhenhua
AU - Liu, Yao
AU - Jinlong, E.
AU - Cui, Yong
AU - Xu, Hong
N1 - Funding Information:
This work is supported by the High-Tech R&D Program of China (“863–China Cloud” Major Program) under grant 2015AA01A201, and the NSFC under grants 61471217, 61432002, 61632020 and 61472337. Thierry Titcheu is supported by the AFR PhD Grant of the National Research Fund, Luxembourg. Ennan Zhai is partly supported by the NSF under grants CCF-1302327 and CCF-1715387.
Publisher Copyright:
© 1990-2012 IEEE.
PY - 2018/9/1
Y1 - 2018/9/1
N2 - As one type of the most popular cloud storage services, OpenStack Swift and its follow-up systems replicate each object across multiple storage nodes and leverage object sync protocols to achieve high reliability and eventual consistency. The performance of object sync protocols heavily relies on two key parameters: r (number of replicas for each object) and n (number of objects hosted by each storage node). In existing tutorials and demos, the configurations are usually r=3 and n<1,000 by default, and the sync process seems to perform well. However, we discover in data-intensive scenarios, e.g., when r>3 and n\gg 1,000, the sync process is significantly delayed and produces massive network overhead, referred to as the sync bottleneck problem. By reviewing the source code of OpenStack Swift, we find that its object sync protocol utilizes a fairly simple and network-intensive approach to check the consistency among replicas of objects. Hence in a sync round, the number of exchanged hash values per node is Θ (n\times r). To tackle the problem, we propose a lightweight and practical object sync protocol, LightSync, which not only remarkably reduces the sync overhead, but also preserves high reliability and eventual consistency. LightSync derives this capability from three novel building blocks: 1) Hashing of Hashes, which aggregates all the h hash values of each data partition into a single but representative hash value with the Merkle tree; 2) Circular Hash Checking, which checks the consistency of different partition replicas by only sending the aggregated hash value to the clockwise neighbor; and 3) Failed Neighbor Handling, which properly detects and handles node failures with moderate overhead to effectively strengthen the robustness of LightSync. The design of LightSync offers provable guarantee on reducing the per-node network overhead from Θ (n\times r) to Θ (nh). Furthermore, we have implemented LightSync as an open-source patch and adopted it to OpenStack Swift, thus reducing the sync delay by up to 879 × and the network overhead by up to 47.5 ×.
AB - As one type of the most popular cloud storage services, OpenStack Swift and its follow-up systems replicate each object across multiple storage nodes and leverage object sync protocols to achieve high reliability and eventual consistency. The performance of object sync protocols heavily relies on two key parameters: r (number of replicas for each object) and n (number of objects hosted by each storage node). In existing tutorials and demos, the configurations are usually r=3 and n<1,000 by default, and the sync process seems to perform well. However, we discover in data-intensive scenarios, e.g., when r>3 and n\gg 1,000, the sync process is significantly delayed and produces massive network overhead, referred to as the sync bottleneck problem. By reviewing the source code of OpenStack Swift, we find that its object sync protocol utilizes a fairly simple and network-intensive approach to check the consistency among replicas of objects. Hence in a sync round, the number of exchanged hash values per node is Θ (n\times r). To tackle the problem, we propose a lightweight and practical object sync protocol, LightSync, which not only remarkably reduces the sync overhead, but also preserves high reliability and eventual consistency. LightSync derives this capability from three novel building blocks: 1) Hashing of Hashes, which aggregates all the h hash values of each data partition into a single but representative hash value with the Merkle tree; 2) Circular Hash Checking, which checks the consistency of different partition replicas by only sending the aggregated hash value to the clockwise neighbor; and 3) Failed Neighbor Handling, which properly detects and handles node failures with moderate overhead to effectively strengthen the robustness of LightSync. The design of LightSync offers provable guarantee on reducing the per-node network overhead from Θ (n\times r) to Θ (nh). Furthermore, we have implemented LightSync as an open-source patch and adopted it to OpenStack Swift, thus reducing the sync delay by up to 879 × and the network overhead by up to 47.5 ×.
KW - Cloud storage
KW - object synchronization
KW - OpenStack Swift
KW - performance bottleneck
UR - http://www.scopus.com/inward/record.url?scp=85042878059&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=85042878059&partnerID=8YFLogxK
U2 - 10.1109/TPDS.2018.2810179
DO - 10.1109/TPDS.2018.2810179
M3 - Article
AN - SCOPUS:85042878059
VL - 29
SP - 2059
EP - 2074
JO - IEEE Transactions on Parallel and Distributed Systems
JF - IEEE Transactions on Parallel and Distributed Systems
SN - 1045-9219
IS - 9
M1 - 8303732
ER -