Castle on a Cloud

在OpenStack kilo版本中, 提出了Magnum的支援, 不同於前述的Heat和Nova嘗試在既有的架構下結合docker的方式, Magnum是一個通用的容器管理解決方案,  支援Kubernetes和Docker, Magnum為了結合既有的OpenStack支援, 以及docker特有的叢集(Swarm)部屬方式, 而擁有以下的特點[4]: Magnum在任何需要管理容器的地方, 使用其他的OpenStack元件, 例如: Nova, Heat, Neutron, Glance和Keystone Nova用於創建輕量的虛擬機(micro VM), docker容器在虛擬機中運行 Heat用於整體資源調度, 對於docker, Heat則會創建docker Swarm叢集以及Swarm Agent Magnum創建bay-model(叢集模型), bay(叢集)以及容器的創建

嚴格上來說, docker和OpenStack是兩種不同的服務, OpenStack提供的是虛擬機(Virtual Machine)的調度與管理, docker提供的是容器(Container)的封裝與隔離機制, 然而, 對於一般使用者而言, 兩者皆提供一種獨立的, 可擴充的運算資源, 因此, 也有許多比較文章[7], 嘗試比較docker和OpenStack適用的範圍. 事實上, OpenStack也開始思考如何結合docker的運算架構, 提供容器作為一種服務(Containers-as-a-Service) [1, 2], 在OpenStack中, 有三種不同的方法和docker結合: Nova中的Docker driver [1], heat中的Docker driver以及Kilo版中推出的Magnum Project [2]. 主要的差異在於容器開啟的位置是實體機(physical machine)還是虛擬機.

在這一篇文章中, 將介紹一些docker所使用的技術, 相同的, 由於docker的相關技術已經被討論許多, 也有取多trace code, 在文章中, 只大略提及個技術的重點與限制, 並列出相關文件於參考資料作為延伸的閱讀. docker是藉由Linux Containers (LXC)技術作為基礎, LXC包括兩個部分: Linux Namespace (chroot)以及Linux CGgroup, chroot提供了一種簡單的隔離模式: chroot內部的檔案系統無法訪問外部的內容 Linux Namespace在此基礎上, 提供了對UTS (UNIX Time-sharing System), IPC (interprocess communication), mount (檔案系統), PID (處理程序), network, User等的隔離機制. 簡單來說, LXC藉由遮蔽PID, 提供分離的操作環境, 因此, docker的每個容器都有獨立的檔案系統, 處理程序ID, 以及多工架構,

在這一系列文章中, 將介紹docker這一種虛擬化技術, docker作為一種作業系統層虛擬化技術, 在網路上已經有大量的討論, 因此, 在文章中, 只簡短的總結一下個主題的結論, 並且附上連結作為進一步了解的參考. 在進入細部介紹之前, 我們先介紹docker [1]: Docker is an open platform for building , shipping and running distributed applications. It gives programmers, development teams and operations engineers the common toolbox they need to take advantage of the distributed and networked nature of modern applications. 在官方的介紹中, 說明了docker的三種功能:  building ,  shipping  和  running 其中, building是建立docker的環境, shipping則是docker容器(container)的搬移, running則是docker容器的執行.

在 上一篇文章 中, 我們介紹了MaaS, 若以雲端的三種服務類型分類(IaaS, PaaS, SaaS), MaaS提供一組實體的伺服器叢集, 應該被歸類於IaaS的服務類型. 當我們定義好一個運算支援叢集, 不論其運算資源是來自於虛擬機(例如: Amazon, OpenStack), 或是實體的伺服器群組(例如: MaaS), 都必須要部件相對應的作業系統與程式, 提供叢集內運算或是管理的需求, 以hadoop 1.2.1為例, 運算節點就分成了master和slave, 其中, master節點必須以heart beat的方式控管從集中的節點, 並根據即時的叢集狀態, 進行工作(MapReduce)與儲存(HDFS)的分配. 對於更複雜的叢集, 如OpenStack, 就擁有更多不同的角色與設定, 因此, ubuntu JuJu的目的就在於提供一套映象檔(image)與叢集設定的機制, 使得雲端上的叢集, 可以快速且自動地在運算叢集上建立起服務.

甚麼是MaaS? MaaS的全名為Metal as a Service, 其中, Metal為Bare metal, 所指的是不帶作業系統的伺服器硬體. 考量到一個資料中心的使用環境, 當管理者必須管理數以百台,甚至千台實體機器(physical nodes), 如何將這些伺服器組件起來, 變成像是hadoop或是OpenStack的叢集提供雲端服務就成了一個棘手的問題. 為了解決這樣的問題, Canonical (ubuntu的母公司) 提出了MaaS的解決方案. 透過MaaS, 管理者可以透過web介面或是API進行叢集 (cluster) 間的資源配置, 例如說, 配置一台至少有16G記憶體的伺服器, 作為hadoop叢集的資料節點. 此功能從ubuntu 12.04版本時開始支援, 提供一些預先設定的內容, 讓安裝好後的Linux作業系統能和既存的服務叢集相容. 考慮到MaaS和伺服器網路的關聯性, 對於MaaS管轄下的伺服器叢集的網路介面 (例如: DHCP和DNS), 都必須歸MaaS管轄, MaaS管轄的單元為伺服器叢集, 在叢集中, 伺服器扮演不同的角色, 以OpenStack為例: 至少包含了Control Node, Network Node以及Compute Node. 藉由監控這些節點的負載, MaaS可以平衡一個雲端服務叢集所需要的資源, 並動態配置, 增進資料中心的能源使用效率.

在hbase中, 有些時候我們須查詢某一欄位的數值是否更新, 在這個情況下, 應該如何利用hbase shell的方式查詢呢? 如果我們確知row-key的名稱, 我們可以利用get的方式執行: hbase(main):005:0> get 'UserTable', 'B8:8D:12:1A:59:76' [...] 10 row(s) in 0.4240 seconds 甚至指定欄位, 例如: hbase(main):008:0> get 'UserTable', 'B8:8D:12:1A:59:76', {COLUMN=>['x', 'y']} COLUMN                CELL  x:                   timestamp=1434519293316, value=12.847539358614743  y:                   timestamp=1434519293316, value=28.36858703324554 2 row(s) in 0.0100 seconds 然而, 若是row-key為自動產生 (由寫入程式決定),  或是, 不知道row-key的資訊 (例如: 使用者的MAC位址), 應該如何查詢呢?