3. swift
1. Swift is a highly available, distributed,
eventually consistent object/blob store.
2. Organizations can use Swift to store lots of
data efficiently, safely, and cheaply.
3. written by python.
4. microservice 架構
4. hdfs 和 swift 比較
● Swift is designed with multi-tenancy in mind,
where HDFS has no notion of multi-tenancy
● HDFS uses a central system to maintain file
metadata (Namenode), where as in Swift the
metadata is distributed and replicated across
the cluster.
5. ceph 和 swift 比較
Ceph
○ Started in 2006
○ Written in C++.
○ Strongly consistent.
○ Block storage.
○ Object storage.
Swift
○ Started in 2008
○ Written in Python.
○ Eventually consistent.
○ Object storage.
○ In production on really
large public clouds.
6. Strongly consistent vs Eventually
consistent
● Eventually consistent
○ if no new updates are made to a given data item,
eventually all accesses to that item will return the
last updated value.
● Strongly consistent
○ If you successfully write a value to a key in a
strongly consistent system, the next successful read
of that key is guaranteed to show that write.
8. swift data hierarchy
● account
○ In the OpenStack environment, account is
synonymous with a project or tenant.
● container
○ namespace for objects.
○ access control list
● object
9. swift service 常見程序名稱
● proxy:負責接受 client 端的 request,並根據
request 來決定哪個 server 發 request。
● server:負責接受 proxy 的請求,處理 CRUD。
部份程序會處理 replicator 的 request。
● updater:處理非同步更新 database 的請求
14. 如何解決加入主機後,有需多資料要移
動的問題
● All problems in computer science can be
solved by another level of indirection, except
of course for the problem of too many
indirections.
17. ceph
● Each pool has a number of placement
groups. CRUSH maps PGs to OSDs
dynamically. When a Ceph Client stores
objects, CRUSH will map each object to a
placement group.
18. ceph
● Mapping objects to placement groups creates a layer of indirection
between the Ceph OSD Daemon and the Ceph Client. The Ceph Storage
Cluster must be able to grow (or shrink) and rebalance where it stores
objects dynamically. If the Ceph Client “knew” which Ceph OSD Daemon
had which object, that would create a tight coupling between the Ceph
Client and the Ceph OSD Daemon. Instead, the CRUSH algorithm maps
each object to a placement group and then maps each placement group to
one or more Ceph OSD Daemons. This layer of indirection allows Ceph to
rebalance dynamically when new Ceph OSD Daemons and the underlying
OSD devices come online. The following diagram depicts how CRUSH
maps objects to placement groups, and placement groups to OSDs.