Mass: Workload-Aware Storage Policy for OpenStack Swift Yu Chen , Wei Tong, Dan Feng, Zike Wang Huazhong University of Science and Technology
Outline • Background and Motivation - Motivation study - Goals & Challenges • Mass • Evaluation • Conclusion 2
Cloud object storage • Features - Flat address space - HTTP-based RESTful web APIs (CRUD) - Storage virtualization Amazon S3 Ceph • Advantages - High availability - Flexibility - Simple data management OpenStack Swift 3
Gap between workloads and storage • Multi-tenant workloads Tenant - Di ff erent access characteristics 2 Tenant Tenant - Di ff erent requirements (latency & throughput) 1 3 • Shared storage shared storage - Monolithic configuration - Same service level • Results in… ➡ Limited workload performance ➡ Low system e ffi ciency 4
Storage policy mechanism of Swift • Two-tier architecture - Access tier forwarding requests - Storage tier managing storage devices • Proxy server - Object ring • Storage node Request forwarding - Partition 5
Storage policy mechanism of Swift • Object rings - Key role of request forwarding - Consistent hashing - Two-level mapping • Storage policy mechanism - Creation of the particular object ring - Configurable n,m values Two-level mapping of object ring 6
Motivation study - advantages • Comparing with the monolithic setup ➡ NOT similar performance level ➡ Throughput: up to 8.5x increase better workload performance ➡ Latency: up to 33% decrease • Analysis - Isolated forwarding paths - Mitigating resource competition 7
Motivation study - limitations • Stress tests - Varying request concurrency - Same storage policies • Performance results ➡ Throughput reaching saturation ➡ Latency increasing sharply • Indicates that… - Performance of intensive workloads has room for improvement Why? 8
Goals & Challenges Enhanced storage policy mechanism Goals Challenges - Covering full-path of request - Controlling request processing path - Workload-specific - Workload classification - Request identification at storage layer - Performance optimization - Policy adjustment at runtime - Dynamic mechanism 9
Mass • Control & Data planes - Controller - Monitor - Substore • Workload classification - Access characteristics - Read-dominated, write- dominated, read-write mixed • Request identification - Cross-layer tagging Overall architecture 10
Life cycle of a policy i. Policy preparation - Monitoring 1 - Workload classification 2 ii. Policy formulation - Triple: {tenant, ring, method} 3 4 5 iii. Policy deployment 6 - Optimized request processing iv. Policy execution Component interaction 11
Two-level processing optimizations • Substore-level policy • Storage node level policy - Workload-specific - Priority-based queuing - Performance optimization - System e ffi ciency - Programmable High Performance Read-dominated Workload type Policy requirement Read- Read-write mixed Latency Cache dominated Priority Write- Write-dominated Throughput Batch dominated Read-write Latency & Non-first replica write Merge mixed Throughput Low 12
Dynamic policy mechanism • Workload changes • Improper resource allocation • Policy overhead - External - Internal • Validation • Policy adjustment • Insertion • Deletion 13
Evaluation setup • Cluster • Storage setup - 2 proxy servers - Default: Swift’s original policies - 5 storage nodes - Crystal: Manual workload-specific policies - 3 workload generators - MASS: Dynamic workload-specific policies • Workload & priority-based queuing - Synthetic workloads 79.99% 99.97% - Real-world traces write read Synthetic workloads Idiada trace Arctur trace 14
Effectiveness of policy • Overall system performance ➡ 154.3% higher throughput and 67.8% lower latency Workload B Workload A Workload C 81.6% lower latency 93.7% lower latency 231.5% higher throughput 191.2% higher throughput 15
External workload change ���� ��� ������� ���� ������� ���� ��� ��������������� ��������������� ��� ��� ��� ��� ��� � � ��������� ��������� Workload A Workload C ��� ������� ���� • Three-stage test ����������� ��� - Baseline & A-dominated & C-dominated ��� - Workload A: 61.9% lower latency � - Workload C: 55.2% higher throughput ��������� Workload A 16
Internal workload change � � ������� ������� ������� ������� ��� ��� ���� ���� � ��� ��� � ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� ��� � ��� ��� ���� ��� � �� � ����� ���� ��� � ������������� ������������� � � � �� ��� ���� � �� ��� ���� ����� ��������������� ��������������� • Comparing with • Comparing with - Default: average 61.3% promotion - Default: average 59.4% promotion - Crystal: average 37.6% promotion - Crystal: average 39.3% promotion 17
Conclusion • Original storage policy mechanism - Poor performance of intensive workloads - Unable to react to workload changes • We propose Mass to enhanced flexible polices - Covering full storage path - Workload-aware optimizations based on access characteristics - Dynamic policy adjustment • Better workload performance and system e ffi ciency 18
Thanks! Q&A Email: chloe_chen@hust.edu.cn
Recommend
More recommend
