Openstack swift - VietOpenStack 6thmeeetup
•Download as PPT, PDF•
6 likes•1,564 views
Overview OpenStack Swift at 6th Meetup VietOpenStack
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Openstack swift - VietOpenStack 6thmeeetup
Similar to Openstack swift - VietOpenStack 6thmeeetup (20)
More from Vietnam Open Infrastructure User Group
More from Vietnam Open Infrastructure User Group (20)
Recently uploaded
Recently uploaded (20)
Openstack swift - VietOpenStack 6thmeeetup
- 1. ToanDomino Skype: bui.songtoan August 23, 2015 Anthony Young OpenStack Swift Introduction & Architecture
- 2. What We’ll Cover • Swift Use Cases • Intro to Swift • Swift Architecture • Demo 2
- 5. From now until 2020, the digital universe will about double every two years. 40,000 exabytes by 2020
- 6. Requirements for Data Storage • Durability • Accessibility • Low cost • Manageability
- 8. What is Object Storage? 8 - Attached directly to an OS(ex: SAN, iSCSI, local disks) - Lowest level - Useful for app with heavy random I/O.. - Openstack: Cinder - Use of a network file system that acts as abstraction layer between the OS and NAS device (NFS) -Allows different OS -File locking - Access via API at application-level - ~ Flat structure - Storing objects in containers (massive scalability) - Metadata lives with the object - Scalability - Durability - Cost
- 9. What is Object Storage? • Good for: • Media (images, music, video) • Documents • Backups • Not suited for • Relational Databases • Data requiring random access/updates within objects 9
- 10. CAP Theorem 10
- 12. CAP Theorem 12
- 13. CAP Theorem • Swift chose availability and partition tolerance and dropped consistency 13 Why???
- 14. Storage as a service 14
- 15. Storage as a service • PUT, GET, HEAD, DELETE… • RESTful API • Multi-path upload, ACL support, versioning • Metadata, distributed & replicated • Mutil-tenant service • Web/Mobile app • Massive concurrency 15
- 16. Storage as a service 16
- 17. Storage as a service 17
- 18. Storage as a service 18
- 19. Storage as a service 19 Viet Nam???
- 20. VDrive 20
- 22. What is Swift? • Object Store • Highly Scaleable • Durable • Highly Concurrent • Open Source • Runs on Commodity Hardware • Developer Friendly (Static Content, Expiring Objects, Quotas, Direct form upload…) 22
- 23. Swift is not • RAID • Distributed Filesystem • CDN • SAN/NAS/DAS 23
- 26. Swift Architecture • Account service • Container service • Object service • Consistency service 26
- 27. Swift Architecture (Account service) 27
- 28. Swift Architecture (Account service) 28
- 29. Swift Architecture (Container service) 29
- 30. Swift Architecture (Container service) 30
- 31. Swift Architecture (Container service) 31
- 32. Swift Architecture (Object service) • Use file system to store files • Files named by timestamp • Directory structure • /mount/data_dir/partition/hash_suffix/hash/object.ts 32
- 33. Swift Architecture (Consistency service) • Replicators • Auditors 33
- 37. Swift Architecture (Proxy tier) 37 • Handles Incoming Request
- 38. Swift Architecture (Ring) • Maps data (account, containner, objects) to storage server 38
- 39. Swift Architecture (Zones) 39 • Isolate Physical failures
- 42. Swift features • CORS • Upload directly from the browser via javascript to Swift • Versioning • Allow versioning all object in a container • TempURL • Temporary URL generation for objects • FormPost • Translate a browser form post into a regular Swift object PUT • Account Quotas • Give operator ability to limit or set as read only accounts 42
- 43. Swift features • Binding for different languages: python, ruby, java.. • Mutiple CLI tools: python-swiftclient, jcloud, fog.. • Vv.. 43
- 44. Referent • https://www.youtube.com/watch?v=5N5a_cgxotg • http://www.slideshare.net/openstackcommgr/openstac k-swift-overview-oscon2011 • http://www.slideshare.net/Hostingdotcom/openstack- swift-in-the-enterprise • http://www.florentflament.com/blog/openstack-swift- ring-made-understandable.html • http://www.rackspace.com/blog/introduction-to-object- storage/ 44
- 45. Principal Architect, Rackspace Cloud Builders Anthony Young Thank You!
Editor's Notes
- Block storage: Mo rong, nhung ko co lai dc Tuy thuoc vao vender Dat Network rong File system: Thiet ke cho LAN Ko truy cap tu internet Khi so luong file nhieu hieu nang giam
- Several years ago, building performance into a software system was simple - you either increased your hardware resources (scale up) or modified your application to run more efficiently (performance tuning). Today, there's a third option: horizontal scaling (scale out). Horizontal scaling of software systems has become necessary in recent years, due to the global nature of computing and the ever-increasing performance demands on applications. In many cases, it is no longer acceptable to run a single server with a single database in a single data center adjacent to your company's headquarters. We need truly distributed environments to tackle the business challenges of today. Unfortunately, the performance benefits that horizontal scaling provides come at a cost - complexity. Distributed systems introduce many more factors into the performance equation than existed before. Data records vary across clients/nodes in different locations. Single points of failure destroy system up-time, and intermittent network issues creep up at the worst possible time. http://blog.flux7.com/blogs/nosql/cap-theorem-why-does-it-matter
- Defining The Three Core Requirements Consistency (C) requires that all reads initiated after a successful write return the same and latest value at any given logical time. Availability (A) requires that every node (not in failed state) always execute queries. Let’s say we have “n” servers serving our application. To ensure better availability we would add an additional “x” servers. Partition Tolerance (P) requires that a system be able to re-route a communication when there are temporary breaks or failures in the network. The goal is to maintain synchronization among the involved nodes. Brewer’s theorem states that it’s typically not possible for a distributed system to provide all three requirements simultaneously because one of them will always be compromised. If we refer to the CAP theorem, Swift chose availability and partition tolerance and dropped consistency. That means that you'll always get your data, they will be dispersed on many places, but you could get an old version of them (or no data at all) in some odd cases (like some server overload or failure). This compromise is made to allow maximum availability and scalability of the storage platform. https://julien.danjou.info/blog/2012/openstack-swift-consistency-analysis
- If we refer to the CAP theorem, Swift chose availability and partition tolerance and dropped consistency. That means that you'll always get your data, they will be dispersed on many places, but you could get an old version of them (or no data at all) in some odd cases (like some server overload or failure). This compromise is made to allow maximum availability and scalability of the storage platform.
- - Object layer: Object server chịu trách nhiệm quản lý các object trên disk trong node của nó. Object được lưu dạng file nhị phân trên đĩa sử dụng đường dẫn được tạo bởi ( phân vùng của nó và timestamp), timestamp là thành phần dùng để sau này xác định version của object. Metadata của object được lưu theo dạng file mở rộng (xattrs). Tức là data và metadata sẽ được gắn liền với nhau.
- Replicators: Account, cotainer và object replicator là tiến trình chạy trên tất cả các node tương ứng với mỗi dịch vụ. Replicators sẽ luôn chạy và kiểm tra dữ liệu ở node của nó và so sánh account, container, object với các bản sao của nó ở node khác trong cluster. Nếu một node khác chứa version cũ hoặc bản copy lỗi, thì replicator sẽ gửi bản copy dữ liệu của nó sang node đó. Replicator chỉ đẩy dữ liệu trên chính nó sang node khác, chứ không lấy về bản copies từ xa nếu dữ liệu trên node đó bị lỗi hoặc hết hạn. Replicator có thể dử dụng tiến trình xóa container, object. Xóa object bắt đầu bằng việc đặt dấu dung lượng về 0 trong version mới nhất. Version này sau đó sẽ được replicated sang các node khác và object bị loại bỏ khỏi hệ thống. Swift chạy không thể không có lỗi phát sinh, thì thành phần consistency sẽ luôn chạy cùng hệ thống để kiểm tra tính toàn vẹn dữ liệu hay tính khả dụng của dữ liệu. 2 thành phần chính của Consisstency là : Auditors và replicators. Auditor: Là tiến trình luôn chạy trên mỗi storage node trong cluster quét ổ đĩa và đảm bảo dữ liệu được lưu không có bit lỗi. Có các tiến trình như account auditor, container auditor, object auditor. Nếu có lỗi thì auditor sẽ chuyển nó object lỗi tới khu vực cách ly riêng.
- Swift cho phép user lưu trữ dữ liệu phi cấu trúc theo không gian tên gồm: acocunt, container, object. Bằng việc sử dụng 1, 2 hay cả 3 thành phần sẽ giúp hệ thống tìm ra vị trí lưu dữ liệu. /Account: Địa chỉ lưu trữ account là duy tên duy nhất bao gồm (metadata về chính account đó, và danh sách các containers thuộc account đó, account này không phải là account để định danh như (tên tài khoản). /Account/Container: Địa chỉ lưu trữ container là user định danh bên trong account, nơi này sẽ chứa thông tin về container đó và tập hợp các objects ben trong container. /Account/Container/Object: Địa chỉ lưu trữ object là nơi lưu trữ dữ liệu object và metadata của nó. Object có thể có tên giống nhau trong cùng 1 cluster.
- Node và chỉ chạy dịch vụ proxy-server được gọi là “proxy node”. Node mà chạy một hoặc nhiều dịch vụ, account, container, object được gọi là “storage node”. Storage node sẽ làm nhiệm vụ lưu trữ dữ liệu, và nhận các request từ proxxy Để gọi các process trên các node, ta gọi là các proxy layer, account layer… Proxy layer: Là thành phần nhận các request trực tiếp từ các client vào. Cần tối thiểu 2 proxy server để đảm bảo hệ thống luôn ở trạng thái dư thừa, sẵn sàng cao. Khi có request đến proxy server, nó sẽ xác định được storage node đang quản lý object đó qua chuỗi hash tên của object, và sẽ phản hồi lại cho client. Nếu có storage node nào lỗi, nó sẽ chuyển kết nối đến storage node khác chứa object đó.
- Public face of Swift Look for account, container and object, route to the appropriate resource RING Manages the Swift API Providers fault-tolerance architecture for object servers providing alternatives to failing hosts
- Để đảm bảo hệ thống có tính dư thừa dể chịu lỗi, ta có thể tổ chức cluster thành tập hợp các region và zone. Regions: được định nghĩa như là khoanh vùng khu vực địa lý. Ví dụ ở Hà Nội ta có 2 racks, ở TP.HCM có 4 racks. Khi region ở Hà Nội lỗi thì hệ thống vẫn hoạt động bình thường. Zones: Bên trong region, Swift cho phép tạo các zone và được cấu hình để chịu lỗi. Một zone được xác định bằng tập hợp các server riêng biệt khi có lỗi xảy ra sẽ được phân tách với các zones khác. Một trung tâm dữ liệu được triển khai thì các zone có thể là các racks khác nhau và cần ít nhất 1 zone trong một region.