This is a set of slides for OpenStack Summit Swift working session to discuss Mitaka cycle activities. From NTT, some updates for our activity, "Global EC cluster" are in this slides.

1. Copyright©2015 NTT Corp. All Rights Reserved.
Global EC Cluster Updates
[Mitaka: OpenStack Swift Design Summit]
Swift Work Session2 14:00- Wed
Kota Tsuyuzaki [IRC: kota_]
tsuyuzaki.kota@lab.ntt.co.jp
NTT Software Innovation Center
Copyright(c)2009-2015 NTT CORPORATION. All Rights Reserved.

2. 2Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
• Use Case:
• EC + Global Cluster
• Problem:
• More than 2x data redundancy reduces PUT/GET
performance significantly (approximately 1/3)
• Proposal:
• Creates duplicated fragments on overlay of EC scheme
• SPECS (In detail):
• http://specs.openstack.org/openstack/swift-
specs/specs/in_progress/global_ec_cluster.html
• Discussion Etherpad at Tokyo Summit:
• https://etherpad.openstack.org/p/tokyo-swift-global-
clusters
Overview

3. 3Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
• PoC code lives in gerrit
• PUT/GET implementation [1]
• Reconstructor changes [2]
• All changes above depends on acoles’s change[3]
• Performance analysis with PoC code
• Good progress to show the power of this challenge
• See following slides in detail
Current Status
[1]: https://review.openstack.org/#/c/219165/
[2]: https://review.openstack.org/#/c/237867/
[3]: https://review.openstack.org/#/c/215276/

4. 4Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
Performance analysis
1.6043
1.4631
1.6042
1.3715
0
0.5
1
1.5
2
6:12 6:3*2 10:18 10:4*2
ResponseTime(sec)
EC parameters
PUT Response Time (sec)
0.5705
0.382
0.6701
0.3973
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
6:12 6:3*2 10:18 10:4*2
ResponseTime（sec）
EC Parameters
GET Response Time (sec)
Object Size: 100 MB
EC Segment Size: 1MB
Concurrency: 1
Average of 10 times.
Intel Xeon CPU (Haswell)
Swift-All-In-One Lab Environment.
10% faster 15% faster
49% faster 68% faster
EC duplication makes Swift encode/
decode faster than the way to create
a dozen of unique parities.
Decode apparently faster but Encode
didn’t rather than expected.
(More analysis in next slide)

5. 5Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
PUT performance analysis
0.364334583
0.116085529
1.260665417
1.207914471
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
10:18 10:4*2
ElapsedTime（sec）
Processing Time Analysis (100MB PUT)
encode others
Elapsed time to encode decreases
1/3 as expected but other stuff (e.g.
I/O and network time waits?) looks
dominant for the turn around time on
the PUT case.
encode(blue) is 1/3 in duplication case

6. 6Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
• Good performance gain
• No major overheads
• We can go this way!!
• Further work
• Data placement control (from clayg?)
Conclusion

7. 7Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
Appendix: Basic Implementation Picture
proxy
Example:
ec_ndata = 4
ec_nparity = 2
ec_duplication_factor = 2
(Ring with 12 replica needed)
0 1 2 3 4 5 6 7 8 9 10 11
0 1 2 3 4 5 0 1 2 3 4 5
device device device device device device device device device device device device
X-Object-Sysmeta-EC-Frag-Index
(PyECLib actual EC Index)
PUTchunk_transformer:
return ec.driver.encode(data) * 2
decode from response set of
set([resp.headers[‘X-Object-Sysmeta-EC-Frag-Index’]
% (ec_ndata + ec_nparity) for resp in responses])
GET

8. 8Copyright©2015 NTT Corp. All Rights Reserved.
NTT Confidential
Misc.
1.1083
1.6043
1.4631
1.6042
1.3715
0
0.5
1
1.5
2
6:3 6:12 6:3*2 10:18 10:4*2
ResponseTime(sec)
EC parameters
PUT Response Time (sec)
0.3837
0.5705
0.382
0.6701
0.3973
0
0.2
0.4
0.6
0.8
6:3 6:12 6:3*2 10:18 10:4*2
ResponseTime（sec）
EC Parameters
GET Response Time (sec)