ToanDomino
Skype: bui.songtoan
August 23, 2015
Anthony Young
OpenStack Swift
Introduction & Architecture
What We’ll Cover
• Swift Use Cases
• Intro to Swift
• Swift Architecture
• Demo
2
Swift Use Cases
3
From now until 2020, the digital universe will about double
every two years.
40,000 exabytes by 2020
Requirements for Data Storage
• Durability
• Accessibility
• Low cost
• Manageability
Object Store
7
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
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
CAP Theorem
10
CAP Theorem
11
Consistency
(C)
Partition
Tolerance
(P)
Availability
(A)
CAP Theorem
12
CAP Theorem
• Swift chose availability and partition tolerance and
dropped consistency
13
Why???
Storage as a service
14
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
Storage as a service
16
Storage as a service
17
Storage as a service
18
Storage as a service
19
Viet Nam???
VDrive
20
Intro to Swift
21
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
Swift is not
• RAID
• Distributed Filesystem
• CDN
• SAN/NAS/DAS
23
Swift Architecture
24
Swift Architecture
25
Swift Architecture
• Account service
• Container service
• Object service
• Consistency service
26
Swift Architecture (Account service)
27
Swift Architecture (Account service)
28
Swift Architecture (Container service)
29
Swift Architecture (Container service)
30
Swift Architecture (Container service)
31
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
Swift Architecture (Consistency service)
• Replicators
• Auditors
33
Swift Architecture
34
Swift Architecture
35
Swift Architecture
36
Swift Architecture (Proxy tier)
37
• Handles Incoming Request
Swift Architecture (Ring)
• Maps data (account, containner, objects) to storage
server
38
Swift Architecture (Zones)
39
• Isolate Physical failures
Swift Architecture
• Write
40
Swift Architecture
• Read
41
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
Swift features
• Binding for different languages: python, ruby, java..
• Mutiple CLI tools: python-swiftclient, jcloud, fog..
• Vv..
43
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
Principal Architect, Rackspace Cloud Builders
Anthony Young
Thank You!

Openstack swift - VietOpenStack 6thmeeetup

Editor's Notes

  • #9 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
  • #12 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
  • #13 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
  • #14 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.
  • #33 - 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.
  • #34 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.
  • #36 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.
  • #37 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 đó.
  • #38 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
  • #40 Để đả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.