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
閱讀完整內容

遠程控制管理工具ipmitool

圖片
IPMI（Intelligent Platform Management Interface）即智能平台管理接口是使硬件管理具備“智能化”的新一代通用接口標準。用戶可以利用IPMI 監視服務器的物理特徵，如溫度、電壓、電扇工作狀態、電源供應以及機箱入侵等。Ipmi 最大的優勢在於它是獨立於CPU BIOS 和OS 的，所以用戶無論在開機還是關機的狀態下，只要接通電源就可以實現對服務器的監控。 IPMI 是一種規範的標準，其中最重要的物理部件就是BMC(Baseboard Management Controller)，一種嵌入式管理微控制器，它相當於整個平台管理的“大腦”，通過它ipmi 可以監控各個傳感器的數據並記錄各種事件的日誌。 一般大廠的服務器都支持ipmi功能，比如DELL，HP，IBM。 此實驗選擇的硬件平台Dell R410 無idrac6卡，操作系統CentOS 5.6 1 .服務器啟動後，按'Ctrl + E'進入BMC管理工具界面 2 .設置'IPMI Over LAN'為On，啟用通過LAN方式的IPMI。 3 .選擇'IPMI LAN Channel'，進入設置IPMI的網絡屬性，IP Address '10.60.30.29'， Netmask '255.255.255.0' , Default Gateway '10.60.30.1'，與服務器eth0配置一致即可。 4 .選擇'User Configuration'，進入設置IPMI的訪問帳號, 'Admin account'保持'root'不變，'Enter Passwd'與'Confirm Passwd'填入'root' ipmitool命令使用 http://ipmitool.sourceforge.net/manpage.html 常用顯示本地網絡信息-I open表示接口本地 # ipmitool -I open lan print 1 Set in Progress : Set Complete Auth Type Suppo
閱讀完整內容