a) Ring

Ring 代表磁盤上存儲的實體的名稱和它們的物理位置的映射。accounts, containers, and objects都有單獨的Ring。其他組件要在這三者之一進行任何操作，他們都需要合相應的Ring進行交互以確定它在集群中的位置。

Ring用zones，devices，partitions，和replicas來維護映射，在Ring中的每個分區都會在集群中默認有三個副本。分區的位置存儲在Ring維護的映射中。Ring也負責確定失敗場景中接替的設備。(這點類似HDFS副本的復制)。分區的副本要保證存儲在不同的zone。Ring的分區分布在OpenStack Object Storage installation所有設備中。分區需要移動的時候，Ring確保一次移動最少的分區，一次僅有一個分區的副本被移動。

權重能用來平衡分區在磁盤驅動上的分布。Ring在代理服務器和一些背景進程中使用。

b) Proxy Server

代理服務器負責將OpenStack Object Storage架構中其他部分結合在一起。對于每次請求，它都查詢在Ring中查詢account, container, or object的位置，并以此轉發請求。公有APIs也是通過代理服務器來暴露的。

大量的失敗也是由代理服務器來進行處理。比如一個服務器不可用，它就會要求Ring來為它找下一個接替的服務器，并把請求轉發到那里。

當對象流進或流出object server時，它們都通過代理服務器來流給用戶，或者通過它從用戶獲取。代理服務器不會緩沖它們。

Proxy服務器的功能可以總結為：查詢位置，處理失敗，中轉對象。

c) Object Server

Object Server，是非常簡單的blob存儲服務器，能存儲、檢索和刪除本地磁盤上的對象，它以二進制文件形式存放在文件系統中，元數據以文件的擴展屬性存放。

對象以源于對象名的hash和操作的時間戳的路徑來存放。上一次寫總會成功，確保最新的版本將被使用。刪除也視作文件的一個版本：這確保刪除的文件也被正確復制，更舊的把本不會因為失敗情形離奇消失。

d) Container Server

其主要工作是處理對象列表，它不知道對象在哪里，只是知道哪些對象在一個特定的container。列表被存儲為sqlite 數據庫文件，類似對象的方式在集群中復制。也進行了跟蹤統計，包括對象的總數，以及container中使用的總存儲量。

e) Account Server

它是類似于Container Server，除了它是負責containers的列表而非對象。

f) Replication

設計副本的目的是，在面臨網絡中斷或驅動失敗等臨時錯誤條件時，保持系統在一致的狀態。

副本進程會比較本地的數據和每個遠處的副本，以確保他們所有都包含最新的版本。對象副本用一個Hash列表來快速比較每個分區的片段，而containe和 account replication 用的是Hash和共享的高水印結合的方法。

副本的更新，是基于推送的。對于對象副本，更新是遠程同步文件到Peer。Account和container replication通過HTTP or rsync把整個數據庫文件推送遺失的記錄。

副本也通過tombstone設置最新版本的方式，確保數據從系統中清除。

g) 更新器(Updaters)

有時，container 或 account數據不能被立即更新，這通常是發生在失敗的情形或高負載時期。如果一個更新失敗，該更新會在文件系統上本地排隊，更新器將處理這些失敗的更新。事件一致性窗口(eventual consistency window)最可能來起作用。比如，假設一個container服務器正處于載入之中，一個新對象正被放進系統，代理服務器一響應客戶端成功，該對象就立即可讀了。然而，container服務器沒有更新Object列表，所以更新就進入隊列，以等待稍后的更新。Container列表，因此可能還不會立即包含這個對象。

實際上，一致性窗口只是與updater運行的頻率一樣大，當代理服務器將轉發清單請求到響應的第一個container服務器中，也許甚至還不會被注意。在載入之下的服務器可能還不是服務后續清單請求的那個。另外兩個副本中的一個可能處理這個清單。

h) Auditors

Auditors會檢查objects, containers, 和 accounts的完整性。如果發先損壞的文件，它將被隔離，好的副本將會取代這個壞的文件。如果發現其他的錯誤，它們會記入到日志中。