OpenStack Object Storage（Swift）component 


Dependent component:

1. Memcached
Distributed caching system, mainly in the swift for the token and account information, the container information storage

2. Sqlite
Lightweight database engine in the swift is mainly used to manage the account and the container database

3. rsync
Remote synchronization tool for data synchronization between the storage node

4. XFS
File system

5. WSGI
Python Web services gateway interface, package management tool through paste.deploy swift various service processes, middleware processes

6. Eventlet
Python engage in concurrent network programming library, swift all server processes are dependent on the library

Major components:

1. Ring
在基本架構圖中，沒有畫出ring文件，但是它卻是整個Swift中最重要的組件。 ring文件是由一致性哈希算法生成，它的主要作用是存儲名字到位置的映射。
ring文件分為三類，分別是：account.ring，container.ring，object.ring。
對於account的請求，就能通過account_name查詢account.ring得到{'/account_name' : account_db_position}的映射，從而知道account數據庫文件在集群的位置；
對於container的請求，通過account_name和container_name查詢container.ring文件，得到{'/account_name/container_name' : container_db_position}的映射；
對於object的請求，通過account_name，container_name，object_name查詢object.ring文件，得到{'/account_name/container_name/object_name' : object_position}的映射；
Ring文件作為一個靜態文件存儲在每個節點的/etc/swift目錄下，被用於各節點之間的位置查詢，使得swift的內部網絡是一個P2P網絡，不依賴某幾個節點進行位置查詢，避免了單點瓶頸。
生成ring文件的一致性哈希算法不但為數據的冗餘性，分區容忍性提供了保證，也為整體架構上實現性能、容量的橫向擴展奠定了基礎。

2. proxy-server
proxy-server是proxy node中唯一運行的服務進程，也是swift集群的endpoint，向用戶提供RESTful API。
對於用戶的請求，proxy-server會根據配置文件的配置，將請求交給各個中間件進行處理，其中最重要的就是Auth中間件（認證），在處理完成後會根據請求路徑將請求轉發給相應的storage node中的account-server。 container-server或object-server進程處理。
swift集群的流入數據和流出數據都需要經過proxy-server，proxy-server不會對數據進行緩存。

3. auth-server
驗證服務進程，為用戶生成token和驗證每個請求的token及token的權限。 swift的驗證服務是作為一個中間件被proxy-server使用，是可選的，可以自己開發，也可以使用OpenStack Keystone。 Keystone是官方開發的驗​​證服務，使用Keystone可以無縫的與其它OpenStack項目整合。

4. account-server
account-server是storage node中負責處理對account的GET、HEAD、PUT、DELETE、RELICATION請求的服務進程，account-server使用sqlite的數據庫文件保存account的相關信息

5. container-server
container-server是storage node中負責處理對container的GET、HEAD、PUT、DELETE、RELICATION請求的服務進程，container-server使用sqlite的數據庫文件保存container的相關信息。

6. object-server
object-server是storage node中負責處理對object的GET、HEAD、PUT、PSOT、DELETE、RELICATION請求的服務進程，object-server直接操作object，並利用XFS文件系統的xattr包存object的元數據。

7. account-auditor、container-auditor、object-auditor
這三個進程運行在storage node中，分別檢測account的db文件，container的db文件，object是否損壞，如果損壞，將會向存儲有其它副本的storage node請求副本，替換損壞的。

8. account-replicator、container-replicator、object-replicator
這三個進程運行在storage node中，分別負責account的db文件，container的db文件，object在集群中副本的同步。
例如，一個object在swift集群中通常被存儲在3個不同的storage node中，對於一個PUT /account/container/object的請求，proxy-server會根據/account/container/object查詢ring文件，得到該object應該存儲的節點列表（長度為3），proxy-server會將請求轉發到這三個節點。如果只有兩個節點寫入成功，就認為這次PUT操作成功。寫入失敗的節點在一段時間後將會得到寫入成功的節點object-replicator進程推送過來的數據。

9. container-updater、account-updater
這兩個進程運行在storage node中，負責container數據庫和account數據庫的異步更新。使用異步更新的原因：在請求來量大時，container-server和account-server不能實時處理對數據庫更新的請求，這些請求將被本地化到隊列中，由updater進程進行異步更新​​。

留言

張貼留言

這個網誌中的熱門文章

Json概述以及python對json的相關操作

圖片
什麼是json： JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。它基於JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一個子集。JSON採用完全獨立於語言的文本格式，但是也使用了類似於C語言家族的習慣（包括C, C++, C#, Java, JavaScript, Perl, Python等）。這些特性使JSON成為理想的數據交換語言。 JSON建構於兩種結構： “名稱/值”對的集合（A collection of name/value pairs）。不同的語言中，它被理解為對象（object），紀錄（record），結構（struct），字典（dictionary），哈希表（hash table），有鍵列表（keyed list），或者關聯數組（associative array）。 值的有序列表（An ordered list of values）。在大部分語言中，它被理解為數組（array）。 這些都是常見的數據結構。事實上大部分現代計算機語言都以某種形式支持它們。這使得一種數據格式在同樣基於這些結構的編程語言之間交換成為可能。 jso官方說 ​​明參見：http://json.org/ Python操作json的標準api庫參考：http://docs.python.org/library/json.html 對簡單數據類型的encoding 和decoding： 使用簡單的json.dumps方法對簡單數據類型進行編碼，例如： import json obj = [[ 1 , 2 , 3 ], 123 , 123.123 , 'abc' ,{ 'key1' :( 1 , 2 , 3 ), 'key2' :( 4 , 5 , 6 )}] encodedjson = json.dumps(obj) print repr (obj) print encodedjson 輸出： [[1, 2, 3], 123, 123.123, 'abc', {'ke
閱讀完整內容

Docker容器日誌查看與清理

1. 問題 docker容器日誌導致主機磁盤空間滿了。 docker logs -f container_name 劈裡啪啦一大堆，很佔用空間，不用的日誌可以清理掉了。  2. 解決方法 2.1 找出Docker容器日誌 在linux上，容器日誌一般存放在 /var/lib/docker/containers/container_id/ 下面，查看各個日誌文件大小的腳本docker_log_size.sh，內容如下： #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do ls -lh $log done # chmod +x docker_log_size.sh # ./docker_log_size.sh 2.2 清理Docker容器日誌（治標） 如果docker容器正在運行，那麼使用 rm -rf 方式刪除日誌後，通過 df -h 會發現磁盤空間並沒有釋放。 原因是在Linux或者Unix系統中，通過 rm -rf 或者文件管理器刪除文件，將會從文件系統的目錄結構上解除鏈接（unlink）。 如果文件是被打開的（有一個進程正在使用），那麼進程將仍然可以讀取該文件，磁盤空間也一直被佔用。 正確姿勢是 cat /dev/null > *-json.log ，當然你也可以通過 rm -rf 刪除後重啟docker。 接下來，提供一個日誌清理腳本 clean_docker_log.sh ，內容如下： #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs d
閱讀完整內容

利用 Keepalived 提供 VIP

Keepalived 是一種基於 VRRP 協定實現的高可靠 Web 服務方案，用於防止單點故障問題。因此一個 Web 服務運作至少會擁有兩台伺服器執行 Keepalived，一台作為 master，一台作為 backup，並提供一個虛擬 IP（VIP），master 會定期發送特定訊息給 backup 伺服器，當 backup 沒收到 master 訊息時，表示 master 已故障，這時候 backup 會接管 VIP，繼續提供服務，來確保服務的高可靠性。 VRRP VRRP（Virtual Router Redundancy Protocol，虛擬路由器備援協定），是一個提供備援路由器來解決單點故障問題的協定，該協定有兩個重要概念： * VRRP 路由器與虛擬路由器：VRRP 路由器是表示運作 VRRP 的路由器，是一個實體裝置，而虛擬路由器是指由 VRRP 建立的邏輯路由器。一組 VRRP 路由器協同運作，並一起構成一台虛擬路由器，該虛擬路由對外提供一個唯一固定的 IP 與 MAC 位址的邏輯路由器。 * 主控制路由器（master）與備援路由器（backup）：主要是在一組 VRRP 中的兩種互斥角色。一個 VRRP 群組中只能擁有一台是 master，但可以有多個 backup 路由器。 VRRP 協定使用選擇策略從路由器群組挑選一台作為 master 來負責 ARP 與轉送 IP 封包，群組中其他路由器則作為 backup 的角色處理等待狀態。當由於某種原因造成 master 故障時，backup 會在幾秒內成為 master 繼續提供服務，該階段不用改變任何 IP 與 MAC 位址。 Keepalived 節點配置 IP ADDRESS ROLE 172.16.1.101 vip 172.16.1.102 master 172.16.1.103 backup 安裝與設定 這 ubuntu 14.04 LTS Server 中已經內建了 Keepalived 可以透過 apt-get 來安裝： $ sudo apt-get install -y keepalived 也可以透過 source code 進行安裝，流程如下： $ sudo apt-get install build-essential libssl-dev $ wge
閱讀完整內容