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
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
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
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
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.