There was an error in this gadget

Tuesday, April 1, 2014

OpenStack Swift - Container Sync (New & Old ways)

OpenStack Swift Container-Sync 

Swift 內建功能利用背景工作, 讓 Container to Container 如同鏡像一樣同步所有資料. 不僅僅是自己的Container, 還可以跟其他人Account內的Container相互同步資料. 這個功能也被部分企業用來將資料從舊的Swift Cluster轉移到新的環境上.

提示
如果User request是對object做POST的操作, 操作內容不一定會被同步, 除非object_post_as_copy = true 在 Proxy server 的設定, 目前這個值預設為開啟 true.


同步的設定可以有幾種模式 :

  1. One-way sync : 單向同步 containerA --> containerB
  2. Two-way sync : 雙向同步 containerA <--> containerB
  3. Chain : 鏈狀同步 containerA --> containerB --> containerC --> containerA

首先你必須要知道目前有兩種方法(新/舊)來設定 Container Sync
First of all, you need to know there are two styles for setting container-sync currently. 
  • OLD-style(舊): Supported since Swift's initial release. 任何版本,包含新版本
  • NEW-style(新): Implemented in Swift 1.12 or later. 在1.12版本後才釋出
不論新舊styles, 都有一個重要的前提, 原資料所在的Container Server, 必須要能跟遠端目標Container 的 Proxy Server 透過網路連結的到.

NEW-Style - 多了realm(域)的觀念.
新的做法需要先建立一個設定檔 ( /etc/swift/container-sync-realms.conf )在兩個叢集的"所有"節點. 具體一點來說, 只要會涉及到這個同步過程的所有Proxy Server與Container Server 上面都必須要有這個設定檔案.

範例

[DEFAULT]
[realm1]
key = realm1key
key2 = realm1key2
cluster_name1 = https://host1/v1/
cluster_name2 = https://host2/v1/

[realm2]
key = realm2key
key2 = realm2key2
cluster_name3 = https://host3/v1/
cluster_name4 = https://host4/v1/


realm1 的名稱是可以自行定義, 用來配置一組Container-Sync域. 這個新的觀念可以提高Container-Sync功能的安全性還有彈性. Key則是用來做Request驗證的數位簽章. 送出請求的Container-Sync含有這個key, 接收到的 Proxy server 會驗證是否符合他這邊對應的資料, 如果送過來的key. 這個key並不等同于x-sync-key這個header.


[NEW-Style]

On both clusters (在兩邊的叢集都需要設定)
1. Create /etc/swift/container-sync-realms.conf on all nodes 所有節點都需要
    (https://github.com/openstack/swift/blob/master/etc/container-sync-realms.conf-sample)


      

2. Adding [container-sync] section in /etc/swift/container-server/1.conf on Container Nodes 
   所有container-server運作的節點都需要設定.
   (https://github.com/openstack/swift/blob/master/etc/container-server.conf-sample#L148)

3. Setting container_sync middleware in proxy’s pipline
    To add the container_sync middleware to your proxy pipeline. It needs to be after any memcache middleware     and before any auth middleware.     
    The container_sync section only needs the “use” item. For example:

               [pipeline:main]
               pipeline = healthcheck proxy-logging cache container_sync tempauth proxy-logging proxy-server

               [filter:container_sync]
               use = egg:swift#container_sync


Efforts on Cluster1

     Set the sync-to and sync-key headers on container con1
          $> swift post -t "//realm1/name1/AUTH_test/con2" -k "key" con1


Efforts on Cluster2

     Set the sync-to and sync-key headers on container con1
          $> swift post -t "//realm1/name2/AUTH_test/con1" -k "key" con2


[ OLD-style ]
     
     One-Way sync - Sync data from c1con to c2con 
     Two-Way sync - Sync data from c1con to c2con, also c2con to c1con

Efforts on Cluster1
     Configure container-sync in /etc/swift/container-server/1.conf on all SwiftStack Nodes running container servers in Cluster1

     1. Adding allowed_sync_hosts = $host1,$host2,$host3 in [DEFAULT] 
        section. $host can use either IP or HOSTNAME of the another 
        cluster's API entry point.  

        Example: (192.168.30.1 is the API IP of Cluster2)
        


     2. Adding [container-sync] section in 
        /etc/swift/container-server/1.conf on all Nodes running container servers in Cluster1.

        Example: 
     REF: https://github.com/openstack/swift/blob/master/etc/container-server.conf-sample#L148-L164

     3. Restart Container-server to apply the changes

        $> sudo -i swift-init all restart

     4. Create and add sync information to a container by Swift CLI

        * Create a container (skip it if it's already created)

          $> swift post c1con

        * Retrieve the account URI of c2con on Cluster2.
          It's supposed to look like:

          http://192.168.30.1/v1/AUTH_c2user2/c2con
          
        * Set container-sync required headers on c1con

          $> swift post -t 'http://192.168.30.1/v1/AUTH_c2user2/c2con
             -k ‘secret-key-must-same-on-both-container’ c1con 

        After the above operations, the container c1con should have two 
        headers now. 



        


Efforts on Cluster2
     Configure container-sync in /etc/swift/container-server/1.conf on all Nodes running container servers in Cluster2.

     If you don’t want to setup Two-Way sync, please skip this step. 
     1. Adding allowed_sync_hosts = $host1,$host2,$host3 in [DEFAULT] 
        section. $host can use either IP or HOSTNAME of the another 
        cluster's API entry point.  

        Example: (192.168.20.1 is the API IP of Cluster1)
        


     2. Adding [container-sync] section in /etc/swift/container-server/1.conf on all Nodes 
        running container servers in Cluster2.

        Example: 

        REF: https://github.com/openstack/swift/blob/master/etc/container-server.conf-sample#L148-L164

     3. Restart Container-server to apply the changes

        $> sudo -i swift-init all restart 

     4. Create and add sync information to a container by Swift CLI

        * Create a container (skip it if it's already created) 
 
          $> swift post c1con
          
        # For Two-Way sync

        * Retrieve the account URI of c1con on Cluster1.
          It's supposed to look like:

          http://192.168.20.1/v1/AUTH_c1user1/c1con
               
        * Set container-sync headers required on c1con

        # For Two-Way sync

        $> swift post -t 'http://192.168.20.1/v1/AUTH_c1user1/c1con
           -k ‘secret-key-must-same-on-both-container’ c2con 

        # For One-Way sync, the secret key on c2con is enough.

        $> swift post -k ‘secret-key-must-same-on-both-container’ c2con

        After the above operations, the container c2con should have two
        headers now.  

        


[驗證]
The swift-container-sync daemons will perform the sync periodically. You can upload some objects into c1con on Cluster1. Wait 5 minutes and check the container c2con on Cluster2 for updates. Also, you can find the PUT logs in /var/log/swift/proxy_access.log in Cluster2. 

[Important] Those PUT requests are issued by the container server on Cluster1. So, the Cluster2 API IP must be reachable by the container servers (nodes) on Cluster1.

If you don't want to wait for 5 minutes, you can stop the container-sync worker and execute the worker on Cluster1.

 $> sudo -i swift-init container-sync stop
 $> sudo -i swift-container-sync -o /etc/swift/container-server/1.conf





Friday, March 21, 2014

OpenStack Swift (ep0) - 進化的儲存系統與需求

存儲方案的演進

OpenStack Object Storage, 代號 Swift 的計劃在2011年 OpenStack Cloud Computing 計劃中正式啟動.

起初的目標要能夠支撐史無前例快速增長的資料量, 它也證明了Open Source的儲存系統確實能處理極大規模的資料.

就在大量線上資料被產出的年代, 對於 Object Storage 而言, 無疑是出現在世界上最佳的時間點. Software Defined Storage(SDS) 正是演化中的新一代儲存選擇.


今日的資料儲存需求

在連接裝置(行動裝置, 終端設備) 爆炸的年代, 對於儲存系統的需求正以指數型成長. 使用者正以前所未有的速度產生資料與消耗存儲資源. 包含社交媒體, 線上影音, 用戶資料, 遊戲資訊還有玲琅滿目的 Software-as-a-Service 應用. 對於儲存系統有了新的需求, 廣泛的應用方法, 方便的存取, 不能有臨界點的增長能力. 廣大的企業與機構正面臨越來越多的儲存需求. 在科學界, 分析出來的數據如果能更有效被儲存與取得也更具價值. 動態影像正無止盡的追求高畫質產品. 企業累積越來越大量的資料, 員工需要更即時的存取資料來提升協同工作的效率.

這些都是什麼資料? 大多數都是 "Unstructured data". 這意味著資料並沒有預先定義的形態而且基本上都是儲存為個別的檔案, 相對於資料庫中的某筆資料(structured data). 包含靜態影像, 動態影像, 電子郵件, 文件以及各種格式的檔案. 這些資料來自每一年消費者與各行業數十億的終端裝置藉由網路存取.


儲存Unstructured Data的條件

通常需要確保資料的耐久力, 可存取性, 可管理性還有相對低成本.

耐久力 - 資料可以說是最重要的東西而且有無法取代的特性. 許多形態的資料必須被永久保存. 在資料中心, 大部分Unstructured Data需要能被保存非常久的時間以符合客戶的期望或是一些法律上面的條件.

可存取性 - 讓許多終端裝置無論在何時何處都能立即的取得. 使用者期望在行動裝置, 筆電或是在家裡的桌上電腦都能夠順利獲取需要的資料.

可管理性 - 大型儲存系統的管理也是一個重要的課題. 如何讓幾個管理者輕鬆管理大量的儲存設備.

低成本 - 只要資金足夠, 相信很多儲存的問題都能被解決, 然而在現實世界中, 金錢的條件是被限制住的. 基於預算考量, 低成本的儲存方案是必要的.


沒有完美的分散式儲存系統

如果有一種Unstructured Data儲存方案是集合所有優點於一身, 當然是最迷人的. 但是那不可能存在. 根據實際需求與情況去權衡適合的方案.

Eric Brewster 2000 年首先提出 CAP 定理, 簡潔的點出一個問題, 分散是運算系統無法同時提供C.A.P三個特質. 只能符合其二再利用其他機制彌補不足的條件


  • Consistency - 使用者在同一時間點看一致(相同)的資料內容
  • Availability - 當對該系統讀寫的時候, 保證可以取系統回應
  • Partition Tolerance - 在部分有問題(硬碟故障, 網路線損壞)的狀況下, 整體系統依然可以運作


必須根據你的情況從三個特質中選擇兩項在分散是系統中實做. 道理其實相似於生活中只能從快速/低廉/良好中取其二.

如果系統在Consistency(如銀行記錄帳戶的額度)有高度依賴性, 那就得犧牲Availability或是Partition Tolerance. 普遍來說會利用資料庫來支撐這種負載的需求. 今天如果你的情況是需要Availability與Partition Tolerance, 那麼你的應用就需要能接受短暫偶發性的資料不一致. 然而, 特別設計的專用儲存系統在應付特定的工作負載會比通用儲存系統來的更可靠. 當一個系統聲稱能均衡完美的符合這三個特質, 那你肯定需要有更仔細的觀察與測試. 這三個特質之間, 總是存在一些交易與犧牲.

Swift 的使命是要應付極大數量的 Unstructured Data 負載. 根據CAP定理, Swift 選擇最終一致性(eventual consistency) 代替 Consistency 來獲得 Availability 與 Partition Tolerance. 所謂的 "最終一致性" 參照了常用的方法來處理分散式儲存. 在最新寫入的資料尚未被通知寫入成功之前, 它並不保證讀取者能立即獲得最新的更新. 但是保證所有讀取者能在合理的短時間能看到更新後的資料.

如此的做法讓 Swift 擁有資料高耐久性與高可靠度. 隨後的章節會有更深入的探討.


Object Storage 與其他形態儲存的比較

以下有三個廣義的資料存儲形態 : Block Storage, File Storage 與 Object Storage. 不同形態的資料有不同的存取模式. 因此不同的資料性質的資料最好能放在不同的儲存系統上.

Block Storage
這代表資料放在同等大小的blocks (例: 2^^12 bits / per block) 的時候, 不用對這些儲存元做解釋. 通常來說, 這種儲存非常適用於上層軟體對資料的結構需要緊密掌控的應用. 一個很常見的例子是資料庫(Database). 資料庫能夠從儲存裝置(raw block device)上有效率的讀寫structured data. 另外, block storage 透過抽象層的檔案系統(filesystem) 讓作業系統在上面運行與儲存資料. 高效能的儲存媒體(SSD, Flash)常常被用來提升整體系統效能, 這也是Block Storage需要的條件.

File Storage
這是一個電腦使用者最常接觸的形態. File storage 將格式化過的硬碟在電腦上做成檔案系統來使用. 不論你在電腦上打開或是關閉文件的時候, 你都可以看見檔案系統. 在資料中心, 會透過網路來提供檔案系統(ex. NAS). 雖然檔案系統在硬碟上提供了很方便的抽象層, 但是在擴展上會是一個大挑戰. 當規模成長後, File Storage 對於Consistency還是有強烈的要求.

Object Storage
這對常常透過網路或是利用行動裝置讀取遠端資料的人是很熟悉的. 只是也許你不知道他是Object Storage. 使用者並沒有直接指定檔案在儲存媒體的實體位置. 它提供使用者存取整個物件或是整個blob(Binary Large Object). 而存取的方式通常是透過該系統特定的APIs. 個別物件透過某種協定或是方法來定義它的位置. 例如Swift利用一串網路位址(URL)讓使用者讀取. Object Storage 將後端物件儲存的實際裝置轉化(抽象化)為一個位置(URL). 所以當後端的儲存池需要擴展的時候, 即使資料的實體位置重新分配, 還是可以透過 Object Storage 對抽象的位置(URL) 進行解析的機制, 正確無誤地取得使用者的資料. 這讓Object Storage 具有強大的擴展能力.

Object Storage 其中一個主要的好處是能分散讀寫的請求跨越整個叢集到很多儲存節點. 如此一來, 同樣有大量資料的各種儲存形態, 在要求資料可靠度與擴展能力的時候, 能相對的降低成本.

在系統擴展的時候, 它還能呈現單一命名空間的. 不像檔案系統, 操作者需要管理多個儲存目標. 由於單一命名空間的特性, 上層的應用軟體甚至是使用者完全不需要了解該用什麼檔案系統, 只需要永遠都用同一個存取定址即可. 也因為如此, 當後端儲存池長大後, 也不需要去搬移檔案, 或是切割檔案等等的操作. 大大降低擴展後對檔案操作的複雜度.


全新的存儲邏輯 : Software Defined Storage

資料儲存的歷史始於將硬碟連接到主機上面. 接著是把硬碟移到跟主機分開的專用儲存控制器上面. 地球在轉動, 世界也不停的持續改變, 現在的應用軟體的規模遠遠超過過去的時代. 這意味著儲存的架構需要再改變, 超越 in-line controller 的機制來達成新的需求.

過去世代的存儲經常是運行訂製的硬體與封閉的軟體. 通常這意味著昂貴的維護合約, 困難的資料遷移以及緊密關聯的控制元件生態系統. 這些系統要求制式化的操作來避免錯誤.

由於Unstructured Data 存儲的規模迫使存儲架構的遊戲必須要改變. 這也是Software Defined Storage(SDS) 這個故事的開端. 也說明了該如何儲存資料這件事情的巨大改變. 藉由SDS, 整個存儲結構被重新鑄造以符合耐久性, 易存取性, 低成本與易管理性的全新標準.

SDS將存儲方案需要的功能全部以軟體來實踐, 不需要特定規格的硬體設備. 面對各種硬體錯誤的發生, SDS 的設計邏輯是允許錯誤的發生, 但是在部分元件失效的同時, 整體系統依然要能正常運作, 而不是把重點放在如何避免硬體問題.

不論是總量或是成長速度 Unstructured Data 正大幅超越 Structured Data. 如果錯誤都是能夠自行解決, 那你會發現將系統運行在泛用的硬體上是可行的, 即使會有少量偶發的問題, 還是可以自行採購通用的硬體做更換. 說到擴展叢集的規模, 可以輕易地漸進式增加需要的硬體來提升叢集的各項負載能力. 你也會發現硬體的不設限, 讓硬體汰換或是移植系統到不同的硬體供應商都相對的容易許多. 如此在採購時便可以選擇更理想的硬體.

以上這些代表著, 你所建立的叢集將不再只是放在同一個機架或是同一個機房, 甚至是可以在不同的地理位置的資料中心.

Software Defined Storage 元件
SDS 系統將底層的實體硬體切割為資訊管理與資料存取兩個大方向. 由四個機制組成.


  • Storage Routing - 儲存路由
    儲存路由層如同存儲系統的大門. 這個單元可以將使用者的請求分散到不同的實體裝置, 甚至跨越地理限制的不同資料中心. 這個路由層也可以透過增加節點的方式來橫向擴展, 提供更好的資料存取能力.

    在SDS系統內, 即使出現部分網路或硬體異常的狀況, 這個路由層需能夠將使用者請求導向正常運作的其他節點. 如果在大檔案資料傳輸過程中, 後端存儲硬體故障, 這個路由層必須要能輕易的從其他正常的節點延續檔案的下載.

    這邊提到的服務(services) 在SDS系統的路由層中, 表示存取控制, 啟動支援的通訊協議, 回應API 請求等等.
  • Storage resilience - 復原能力
    在SDS系統中, 可靠度是由軟體來負責而非硬體. 多種資料保護的機制被用來確保資料不會遺失或是損壞.
    這方面可以在系統中運用不同的程序, 跨越資料中心, 持續的監控資料存在與否, 健康狀態. 一旦資料出現可能的損壞, 系統會主動處理掉這個問題.
  • Physical hardware - 實體的硬體
    SDS內, 實體的硬體裝置僅負責將位元數據存入硬碟. 儲存節點不是各自負責該節點上的資料完整性. 而是由方才提到的 Storage resilience 機制, 在各節點上的特定程序交換資訊完成. 相同的, 當實體節點掛掉的時候, Storage Routing 機制會將使用者請求導向正常運作的節點上.
  • Out-of-band controller -
    一個SDS系統必須能有效率的管理與擴展規模. 分散式儲存系統需要一個方法來取代傳統方案的管理機制. 不可能讓每個節點都有一個控制器吧. 因此將控制單元切割出來是一個絕佳的選擇. 這個控制器讓操作者可以對SDS系統中所有節點進行管理.
    這個控制器也能對系統進行動態調整來優化總體效能, 進行升級, 管理能力. 還有快速修復硬體錯誤的, 提供狀況訊息給操作者, 以便最快速度對系統錯誤進行處理. 基於這些條件, 一個SDS控制器便可以配置整個叢集的儲存資源, 網路, 路由, 服務等等.
Software Defined Storage 帶來的好處

SDS系統有效的管理各種規模並且帶給基礎建設高效率的操作. 容量管理變得更為簡單, 由於每個元件都是分散式儲存的一個成員, 因此再沒有任何服務暫停的狀況下, 可以達成系統升級, 擴張叢集, 機器汰換而且也沒有實體上(硬碟拆裝)的資料轉移工作. 
將硬體跟軟體分開有幾個好處, 可以使用混合的硬體, 異質的硬碟, 不同規格的CPU, 讓叢集的總支撐力以漸進式的方法增加. 需要的時候再進行新硬體採購,
SDS 方案通常出現在Open Source的領域, 這也造就了一件很重要的事情叫做 "標準". 現在開發軟體的時候, 對各種裝置的相容性成為一個重要的課題. 這也代表 "標準協定" 越來越重要. Open Source 代表著更好的標準與更豐富的工具.


為何選擇 OpenStack Swift
Swift 的應用範圍很廣, 包含Web/Mobile應用程式, 備份, 及時保存等等. 多層式的服務界面, 讓使用者簡單的透過泛用的HTTP介面來跟Swift 做資料交換. 或是可以用封裝好的指令工具, 檔案系統轉換工具, 簡單的程式在你各種終端設備上來儲存與同步資料.
有別于傳統的儲存系統, Swift 選擇弱一致性替代強一致性, 如此的設計, 讓Swift擁有高可靠度, 高冗餘, 高吞吐量, 高容量. 將重點放在可靠度上, Swift並不會有transaction 或 Locking的延遲. 大量併發的讀取速度跟大量的寫入效能不相上下. 這也表示Swift能利用橫向的擴展來達到承受高併發連線數與高資料量的能力. 從Swift開始到現在, 已經有數百位貢獻者, 更穩定, 更快速, 還有更多的新功能.

Swift 可以安裝在通用的硬體上面. 這意味標準的硬體, 低成本的零件可以被用來打造一套儲存系統. 相對於需要特定硬體製造商的方案, 仰賴Swift對資料的邏輯軟體管理, 在部署, 擴展, 新功能增加都變得很有彈性. 這就是Software Defined Storage(SDS) 最重要的靈魂所在.
最有趣的也許是發生在你沒看見的地方, Swift 是一種全新的儲存系統. 不是獨立存在的系統. 而是一個能夠輕易橫向擴展,良好容錯能力並且對於資料可靠度有高度要求的系統.除此之外, Swift 也創造新的儲存的工作觀念,流程與介面. 而非嘗試去取代既有的存取界面. 

當然這也帶來了一些使用上的限制, 卻完美的符合今日各種新開發出的軟體. Swift 有越來越廣泛應用的趨勢, 慢慢演進成一種分散儲存大量資料的標準方法.

Conclusion

近年來, 兩個主要的改變, 短時間內快速的衝擊存儲市場. 第一個是Web 與行動裝置的軟體, 直接從根本就改變了資料產生與存儲被消耗方式. 起初是大量網站的出現隨後跟著的是越來越多企業所開發出來提供給消費者的行動軟體.
第二個主要的改變, 是Software Defined Storage的出現. 這開啟了一種基礎的標準, 讓通用的硬體可以被用來建立龐大的分散式儲存系統. 而且還不需要依賴特定的硬體元件就能達到耐久的能力. 這讓各種資料密集的應用領域有了顯著的成本降低.
在隨後的章節裡, 我們會介紹OpenStack Swift. 透過更全面地討論, 讓你了解各種功能與優點. 之後繼續針對Swift的架構進行更深入的剖析.

Tuesday, July 26, 2011

Lost connection of instances after reboot Nova-Network host......

The network connection of instance has been lost after restart Nova-Network host 


In my consideration , all services should not affect others while restart/stop service within cloud platform...

That means instances connection should be alive while admin restart nova-network host , but it won't work as your expectation. I faced this issue one month ago. And I spend around 1 hour to understand what's going on with this problem.

In regular nova deployment , nova-network host is the gateway of all instances.  This Linux network box works like a router.  So that has a ARP table over the box.

In my test , if the flat_interface(or vlan_interface)  do not auto up after reboot , the box will lose ARP table. And you can not ping or ssh  instance anymore.  While you up the nic manually , you have to wait for ARP rebuild .

Tuesday, July 19, 2011

OpenStack turns 1. What’s next?



Link from http://gigaom.com/cloud/openstack-turns-1-whats-next/?utm_source=earth2tech&utm_medium=specialtopics




OpenStack, the open-source, cloud-computing software project founded by Rackspace and NASA, celebrates its first birthday tomorrow. It has been a busy year for the project, which appears to have grown much fas
ter than even its founders expected it would. A year in, OpenStack is still picking up steam and looks not only like an open source alternative to Amazon Web Services and VMware vCloud in the public Infrastructure as a Service space, but also a democratizing force in the private-cloud software space.
Let’s take a look at what happened in the past year — at least what we covered — and what to expect in the year to come.

A Easy way to build UEC-style tarball from exist instance

There's a easy way to build UEC tarball for me
From an exist Ubuntu instance......
!!Still in test!!
Very smooth in Maverick , but failed with Natty server b64

===In instance==
1. source novarc to import environment variable  

2. bundle a virtual disk, don't specify the kernel id 
#euca-bundle-vol -d  destination_of_img -p name_of_image -s img_size 

Monday, July 18, 2011

I'm in IRC@ freenode #openstack #openstack-dev

找我請到IRC的 freenode
#openstack
#openstack-dev 頻道

謝謝.....blogger 這樣討論效率不是很高

ID hugokuo