OpenStack入門之若干討論

一、OpenStack 入門 之 基礎知識

二、OpenStack 入門 之 基本元件

三、OpenStack 入門 之 各元件解析（基礎）

四、OpenStack 入門 之 各元件解析（進階）

五、OpenStack 入門 之 實際操作

六、OpenStack 入門 之 擴充套件話題

七、OpenStack 入門 之 若干討論

僅供參考，如有雷同，純屬呵（qiao）呵（he）

1. 討論：如何回饋 OpenStack 社群

張三：

• 積極關注並回饋社群，貢獻程式碼，爭取成為 committer；
• 積極將研發使用中遇到的問題及程式碼 ，回饋到社群；
• 將 issue、idea、豐富的 feature 提交到 bluePrint，提交到社群；
• 利用自己的一切資源致力於擴大中國 IT 力量在國際的影響力！（評：看到這句好欣慰！我想如果有更多這樣的同學在，中國的 IT 前途很有希望）；

李四：

• 關注各種社群並加入到符合自己實際狀況的社群中，認真學習前輩的經驗，在實際中發現和探索問題，並在社群中討論自己解決不了的問題，以及幫助他人解答問題；

王五：

• 積極參加到社群的討論中來，將一些發現的問題提交到 Issue；
• 如果有新的 idea，更豐富的 Feature 想法，可以寫成 BluePrint 提交到社群；

趙六：

• 可以提交一些意見和建議（blueprint），自己在初學時遇到的一些問題（issue）
• 繼續學習，爭取早日進入社群，能夠發現問題思考問題反饋問題

王二麻子：

• 能，現在水平有限，應該先從寫文件和提交 issue、idea、blueprint 做起，同時打好程式設計基礎，多做專案，多看書，多總結。

2. 討論：OpenStack 管理的資源及提供的服務

OpenStack 管理哪些資源？提供哪些服務？這些服務在公有云上有沒有對應的例子？（請儘量多舉例）

OpenStack 管理的資源有：計算資源、儲存資源、網路資源；

提供的服務有：

• Nova 計算服務；
• Cinder 塊儲存服務；
• Neutron 網路服務；
• Swift 高可用分散式物件儲存服務；
• GLance 映象服務；
• Keystone 身份驗證服務；
• Horizon 圖形介面；
• 擴充套件服務：Heat、Sahara

例子：

1. 虛擬機器 — Nova — 對應亞馬遜上的 EC2
2. 虛擬塊儲存 — Cinder — 對應亞馬遜上的 EBS
3. 虛擬網路 — Neutron — 對應亞馬遜上的 VPC
4. 物件儲存 — Swift — 對應亞馬遜上的 S3
5. 許可權認證 — Keystone — 在 AWS 的服務是看不見的，隱藏在叫作計費系統的後端（DOS 系統的後端）
6. 映象管理 — Glance — 對應亞馬遜上的 VM Import/Export
7. 控制皮膚 — Horizon — 對應亞馬遜上的 Console

3. 討論： OpenStack 之間的通訊關係

OpenStack 之間有哪些通訊關係？分別應用在什麼地方？

OpenStack 元件之間的通訊分為四類：

1. 基於 HTTP 協議
2. 基於 AMQP 協議（基於訊息佇列協議）
3. 基於資料庫連線（主要是 SQL 的通訊）
4. Native API（基於第三方的 API）

關於應用：

• 基於 HTTP 協議進行通訊。通過各專案的 API 建立的通訊關係，基本上都屬於這一類，這些 API 都是 RESTful Web API，最常見的就是通過 Horizon 或者說命令列介面對各元件進行操作的時候產生的這種通訊，然後就是各元件通過 Keystone 對使用者身份進行校驗，進行驗證的時候使用這種通訊，還有比如說 Nova Compute 在獲取映象的時候和 Glance 之間，對 Glance API 的呼叫，還有比方說 Swift 資料的讀寫，也是通過這個 HTTP 協議的 RESTful Web API 來進行的。
• 基於高階訊息佇列協議。基於 AMQP 協議進行的通訊，主要是每個專案內部各個元件之間的通訊，比方說 Nova 的 Nova Compute 和 Scheduler 之間，然後 Cinder 的 Scheduler 和 Cinder Volume 之間。
• 基於 SQL 的通訊。通過資料庫連線實現通訊，這些通訊大多也屬於各個專案內部，也不要求資料庫和專案其它元件安裝在同一個節點上，它也可以分開安裝，還可以專門部署資料庫伺服器，把資料庫服務放到上面，之間通過基於 SQL 的這些連線來進行通訊。OpenStack 沒有規定必須使用哪種資料庫，雖然通常用的是 MySQL
• 通過 Native API 實現通訊。出現在 OpenStack 各元件和第三方的軟硬體之間，比如說，Cinder 和儲存後端之間的通訊，Neutron 的 agent 或者說外掛和網路裝置之間的通訊，這些通訊都需要呼叫第三方的裝置或第三方軟體的 API。

4. 討論：如何對 OpenStack 的元件做高可用部署或者負載均衡

請舉例說明，如何對 OpenStack 的元件做高可用部署或者負載均衡？

高可用 HA（High Availability）指的是通過儘量縮短因日常維護操作（計劃）和突發的系統崩潰（非計劃）所導致的停機時間，以提高系統和應用的可用性。 負載均衡指叢集中所有的節點都處於活動狀態，它們分攤系統的工作負載。 分散式系統 OpenStack 要想做高可用部署或者負載均衡，需要遵循如下步驟：

1. 針對不同的需求設計相應的方案，合理規劃計算資源、網路資源、儲存資源；
2. 將服務、服務中的元件拆開部署，學習 swift 的跨地域部署，有利於提高服務可用性及 OpenStack 的負載均衡；
3. 將同一服務部署在不同節點，形成雙機熱備和多機熱備的高可用叢集，最大化 SOA 架構的作用；
4. 在複雜的資料中心環境中不斷優化與第三方服務的對接和整合，最大化優化 OpenStack 從邏輯架構到物理架構的對映；

我的舉例說明：

• 規模較大的情況下，把各種管理服務部署到不同的伺服器上。把這些服務拆開部署 到不同的節點上，甚至要把同 一個服務的不同元件也拆開部署，比如說可以把 Nova 的資料庫給獨立擰出來部署成一個 MySQL 資料庫叢集，還有 Cinder 裡面的 Scheduler 和 Volume 可以部署到不同的節點上，實際上因為 Swift 專案具有一定的獨立性，所以 Swift 本身就有跨地域部署的生產環境，規模非常之大，跨地域部署，所以它的服務的可用性極高，自然有這種栽培的特性，可以提供極高可用性和資料永續性的物件儲存服務。
• 出於高可用的考慮，生產環境中我們會把 OpenStack 的同一個服務部署到不同的節點上，形成雙機熱備或者多機熱備的高可用叢集。（或者用負載均衡叢集）。
• 在複雜的資料中心環境中，還有很多第三方服務，比方說 LDAP 服務、DNS 服務等等，考慮如何與第三方服務進行對接和整合。

5. 討論：比較 Swift 和 Cinder 兩種儲存之間的異同

異：

Swift 比較獨立，Swift 是做物件儲存的，提供的是物件儲存的介面，採用的是全對等架構。Cinder 是提供塊儲存的，提供的是塊儲存的介面，遮蔽了底層的硬體異構性。 關於資料流流向，Swift 對它的操作不僅僅是通過它的 Swift Proxy Server 提供的 RESTful API 進行操作的，它的資料也是通過 RESTful API 走的，我們要把資料放在Swift裡面或者從Swift裡把資料拿出來，都是通過 RESTful Web API。但是在 Cinder 不一樣，Cinder API 基本上只能提供一些操作和管理功能，是直接通過 FC/iSCSI 傳輸資料到伺服器，資料不會通過 Volume 去走，也不會通過 RESTful API。

同：

Swift 和 Cinder 都是軟體定義儲存，都屬於資源管理層中的儲存管理模組，都是 OpenStack 最主要的儲存元件

6. 討論：比較 Neutron 和 Nova-Network 的異同

相同點：

1. 都可以實現網路管理功能；
2. （租戶之間）都可以實現基於 Vlan 的隔離；

不同點：

1. Nova-Network 只能實現簡單的網路管理，Neutron 則比較強大；
2. Nova-Network 在以前網橋的基礎上加模組實現 2 種工作模式：Flat DHCP 和基於 Vlan 的隔離的工作模式；而 Neutron 對上不僅可以提供 Vlan 的隔離，還可以實現 SDN，對下還支援第三方 API、Plugin 的擴充套件；
3. Neutron 支援每個租戶建立自己的虛擬網路，定義自己網路拓撲，租戶間隔離即 Rich Topologies。

7. 討論：Heat 中的模板和 Sahara 中的模板的異同

相同點：

都是通過模板來實現對資源的建立，銷燬，生命週期的管理等等

不同點：

• Heat 模板 Template 操作的物件是 Stack，並且只有一種方式進行呼叫，實現的是各個元件資源的整合和形成一個有機的整體
• Sahara 由於存在兩種使用模式：使用者模式（edp 模式）和管理模式（iaas 模式），所以模板的使用主要集中在 iaas 模式上，分為兩種：叢集模板和節點組模板。實現的是對 Hadoop 叢集的快速建立

8. 討論：Ceilometer 獲取計量資料的方式

獲取計量資料的方式：

（1）需要原始資料的來源

• 通過 MQP 訊息中介軟體收集各個元件發出來的訊息
• 通過 Ceilometer 的一些 agent 呼叫 OpenStack 各個 component 的 api 獲得資料
• 如果要有效的採集和 Nova 相關的資料，通過在每個計算節點上執行 Ceilometer 的 polling agent 獲得虛擬機器的資訊

（2）存在資料的儲存：依賴第三方後端來實現，預設的後端資料庫是 MongoDB。

（3）來自第三方系統：最主要的使用方式就是第三方系統，通過呼叫 Ceilometer API 獲得計量資料，設定報警條件和預值，監聽報警，進一步去實現計費和監控功能，具體使用的時候涉及到 Ceilometer 怎麼設定，每項資料通過呼叫什麼 API 獲得，怎麼設定報警的預值等等

9. 討論：安裝 Swift、Cinder 等其他服務的步驟

如果在目前已經完成的 OpenStack 演示環境部署的基礎上，繼續安裝 Swift、Cinder 等其他服務，一般來說有哪些步驟？

Cinder

1. 配置管理網路 nova-network；
2. 安裝、配置 NTP 服務（本機時間與網路時間同步，將本機作為伺服器提供給其他主機使用）；
3. 下載安裝 Cinder；
4. 建立 cinder-volumns 並進行配置；
5. 配置 keystone 驗證、資料庫訪問（刪除 sqlite 檔案）及 RabbitMQ 訊息中介軟體；
6. 重啟 volumn 服務。

或者描述為

1. 安裝 openstack 包
2. 配置管理網路網路卡
3. 修改 hosts 為 block
4. 重啟
5. 安裝 NTP 安裝LVM 包
6. 建立 LVM 卷組 cinder-volumes
7. lvm 掃描修改
8. 安裝配置塊儲存卷元件
9. 驗證安裝

參考：http://www.aboutyun.com/thread-11681-1-1.html

Swift

1. 建立 Swift 使用者和組；
2. 建立資料庫並進行配置（刪除 sqlite 配置檔案）；
3. 建立映象 glance 並配置 rsync.conf，配置完成後重啟服務;
4. 下載安裝 swift；
5. 對 swift 服務進行配置；
6. 建立 Swift 並執行指令碼。

10. 討論：面對 Ceph 和 Swift 兩種儲存方案如何進行選型

（1）規模小，節點數量少的使用 Ceph，因為 Swift 至少要用到 5 個節點，划不來。

（2）需要提供雲盤的服務的時候選擇 Swift，做雲盤就意味著要面對大量的使用者，還希望使用者的體驗好，可以讓使用者來選擇資料怎麼存，這個時候選擇 Swift 是更好的，一方面對於這種規模化部署的支援比較好，第二方面它有一些先進的 Feature，第三方面它的價格成本比 Ceph 要低一些

11. 討論：OpenStack 和 Docker 如何結合

1. 使用 Swift 做 Docker 映象的儲存後端
2. 用 Nova 排程和管理 Docker 容器
3. 使用 Heat 實現 Docker 容器
4. 使用 Heat 實現 Docker 的 Orchestration
5. 基於 Neutron 設計與實現適用於 Docker 的 SDN 方案
6. 用 Glance 來管理 Docker 的映象