###### tags: `lsa` `ncnu`
# Week 10 (2023/04/27)
- Book mode: https://hackmd.io/@ncnu-opensource/book
[TOC]
---

## OpenStack
- 雲端運算軟體
-

:::info
## RESTful API (Repersentational State Transfer)
- 特點:
- 有唯一的 URL 表示資源位置
- 無狀態，已登入系統為例
- 有狀態
- Client 端登入時，Server 端儲存 Session
- 無狀態
- Client端自行保存狀態，在向 Server 請求時，一起傳給 Server
:::

### 核心功能

> [圖片來源](https://www.openstack.org/software/)
- Nova: 運算服務
- Keysrone
- Neutron
- Cinder : 區塊儲存服務 (Block Storage)
- Swift : 物件儲存服務 (Object Storage)
- Glance : 映像檔服務 (Image Service)
- Ironic: 裸機部署服務 (Baremetal Provisioning Service)
- Horizon : 儀錶板 (Dashboard)
- Heat : 編排服務 (Orchestration)

### Nova
- 功用: 建立和管理虛擬機
- 需要搭配其他服務使用
- 架構圖
- nova-api : 接收外部請求
- nova-scheduler : 根據狀況，看要哪一個節點當作虛擬機
- Filtering : 篩選出符合的節點
- 創建虛擬機時會透過 Filtering跟 Weighting 決定節點
- Computerfilter 過濾出可以用的節點並開啟
- nova-computer: 管理虛擬機
> 不可以直接操作 Hypervisor
- nova-conductor:根據 nova-computer 的要求，取得資料庫中虛擬機的資料
- nova-computer 不可以直接存取資料庫，所以需要透過 nova-conductor 請求資料庫資料
- 避免多個系統讀取資料庫資料
- Weighting : 依照目前資源的使用率，計算出各個節點的權重，進行排序，決定出最適合的節點
- 公式 : `weight = w1_multiplier * norm(w1) + w2_multiplier * norm(w2) + ...`

- message queue
- 使用 AMQP 協定傳送 Nova 內部的 RPC 訊息
- 目的是都訊息的排序、路由、保持可靠性和安全性
:::info
### RPC (Remote Procedure Call)
- 電腦通訊協定
- 透過網路遠端呼叫其他電腦上的 function
- Openstack 中的服務內部都是用 RPC 互相通訊
:::
- AMQP (Advanced Message Queuing Protocol)
-

- nova 流程圖
1. 使用者 ( 或是其他服務 ) 透過 API 發送或建立虛擬機的請求
2.

### Keystone (身分服務)
- 功用
- 使用者管理 : 驗證使用者使用 Openstack
- 服務管理: 在使用者 ( 或服務 ) 要使用服務時，會先向 Keystone 進行認證，通過認證才可以使用服務
- 紀錄所有 OpenStack API 所在的位置（Endpoint）

#### Identity 服務
- User：人或是 OpenStack 的服務
- Group : user 的集合，方便指派 role
- Credential 第一次驗證要用的憑證
- Authentication : Openstack 驗證 credential 的過程
- Resource: 提供有關 Project 和 Domain 的資料
- project
- domain
- project User Group

- Assignment: 提供 Role 和 Role assignments 的資料 :arrow_right: 來做到 OpenStack 的 RBAC 策略
- Role: 決定使用者或是群組的權限
- Role Assignment: 紀錄 row and resource 的關係
:::info
### RBAC (Role Based Access Control)
- 使用 Role 來做訪問的控制
- 符合權限的 Role 才可以被允許做相對應的動作
:::
- Token：管理跟驗證 tocken
- 目的：增加安全性，避免 user 每次使用服務都要出示 name passwd 可能會有安全問題

- Catlog：紀錄 Openstack 服務的所在位置 (Endpoint)
- Endpoint: URL
- 使用者請求 Nova 建立虛擬機的流程 :
1. 登記使用者 (Authentication)
2. 驗證本人 (Credential)
3. 發送之後使用服務使用的 token
- token 有分各個 role 等級，決定可以使用什麼服務
4. 給導覽圖 (Catlog) 讓使用者知道整個飯店有什麼服務、設施 (Service)，分別可以從什麼路線 (Endpoint) 抵達
5. 每項設施可能有不同路線可以到
- 走後門: admin
- 員工通道: internal
- 客人通道: public
6. 找到設施要使用之前，要先檢查你的卡能不能使用這個設施，所以櫃台 (Keystone) 確認你是否可以使用，確定 OK 才可以使用。

## Neutron 網路服務
- 提供虛擬化服務，讓虛擬機可以上網
- 服務
- 交換器：提供一個網段的虛擬機 L2（資料連接層）的連通性
- 路由器：提供 L3 （網路層）網路功能，
> ex: SNAT , DNAT
- 防火牆：提供基本的防火牆
> port blocking

- SDN Service : 提供額外的網路服務
- Neutron 如果要包含所有網路服務功能的話，會需要寫一堆 agent driver 功能很複雜
- 所以一些網路服務可以使用 SDN 即可

- 提供兩種網路類型 :
- Provider Networks
- Self-Service Networks

- 預設情況，

:::info
### VXLAN (Vietual Extensible LAN)
- 把 Etehrernet Frame 裝在 UDP 封包裡
- VXLAN header 中有 24 bit 讀 VNID 用來區別不同的 L2 網路，總個可以標示 1000 多個 L2 網路

:::
- provider network
- 處理虛擬機 L2 的網路連接
- 將虛擬機連接到實體網路的 switch，使用 L3 實體網路的服務
- 只有管理員才可以建立更新
> 因為 provider network 設定要跟實體的基礎的網路設施一樣，但一般的使用者不會有這些資訊

## Cinder 區塊儲存服務
- 功能
- 提供 block Storage 管理服務，為虛擬機器提供 vloume
- vloume : 裸硬碟
- 負責掛載硬碟到虛擬機，讓虛擬機有空間
- 管理者，非儲存設備
- 提供 vloume 快照和備份服務
:::info
### Block Stroage
- 作業系統獲得儲存空間的方式有兩種
1. Block Storage
- 透過協議掛接裸硬碟、分割槽、格式化、建立檔案系統。
2. 檔案系統儲存
- 透過 NFS、CIFS 等協議 mount 遠端的檔案系統
:::
- cinder-api
- 降低外部請求，把請求透過 message queue 傳給 cinder 的其他服務
- cinder-volume
- 透過 driver 與各種 volume-provider(Back-end)連接
- 讓 volume-provider 提供儲存空間
- cinder-scheduler
- 就像 nova-scheduer 在 nova 中角色，透過 Filtering and Weighting 找出最適合的 node to build volume

- 建立 volume 流程

1. 使用者發送建立 volume 的 api 請求
2. cinder-api 驗證使用者後把請求訊息放到 message queue
3. cinder-volume 收到訊息後，就會漿訊息傳給 cinder-scheduler
> 是透過 message bus 嗎？
4. cinder-scheduler 篩選並排序適合建立的 volume的 vloume-provider
5. cinder-volume 根據排序依序讓 volume-provider 建立 volume 直到建立成功
6. volume-provider 建立好 volume
7. cinder-volume 傳遞 volume 的資訊給 cinder-api
8. cinder-api 傳遞 volume 的資訊給user
9. user 收到 volume

### 建立虛擬機的流程 (Nova , Neutron , Keystone , Cinder , Glance)

### Ceph
- 提供物件、區塊、檔案系統的儲存服務
- 非 Openstack 提供的服務，但可以在 Openstack 上使用
- RADOS
- 由一些 daemon 和多個儲存節點組成的 儲存集
* daemon：
* OSD(Object Storage Daemon)
* 負責儲存資料
* 監控自己和其他 OSD 的狀態並傳給 Monitor
* 每個儲存節點上都有一個 OSD
* Monitor
* 負責管理叢集狀態
* Manger
* 負責追蹤叢集狀態
- Metadata Server (MDS)
- 負責儲存 filesystem 的 metadata
- metadata 紀錄目錄、檔案擁有權、存取模式等

1. client 先向 Monitor 取得叢集資訊(Cluster Map)
2. File 是只要儲存的資料
3. 將 File 以設定的大小（通常是 2 或 4 mb），然後切分成多份的 object
...

- Ceph Clients
- Ceph Object Gateway
- Ceph 的區塊儲存服務
- 又稱 RADOS Block Device(RBD)
- Client 可以透過 Kernel RBD(k)
- Ceph File System
- Ceph 的檔案系統儲存服務
- 又稱 CephFS
- Client 透過 LIBCEFS 向 LIBRADOS 發出請求
- LIBRADOS 再去 RADOS進行存取
- 會有個或多個運作的

:::info
#### Journal
- 紀錄檔案寫入的過程，如果過程發生 crash ，就可以透過 Journal 復原相對應的工作
:::

- Opensta服務使用 Ceph 的關係圖

## Ironic (裸機部屬服務)
- 功用:
- 裸機部署服務，部署映像檔到實體的 Sevrer 上
- 某些使用情下，虛擬化的環境適不適合的，若要部署在實體在伺服器上，就需要 Ironic 這個服務
- 部屬裸機的原因
- 某些運算任務訪問虛擬化的硬體
- 當作資料庫主機，某些資料庫在虛擬化的環境下效能沒有很好
- 單租戶，效能和安全性較好
- 快速部屬雲基礎設施
- 架構 :
- `ironic-api` : 接收外部請求
- `ironic-conductor`
- 新增/編輯/刪除裸機節點
- 透過 driver 操作硬體
- `driver` : `ironic-conductor` 跟不同硬體溝通的介面
- `資料庫`儲存裸機硬體資訊以及狀態
- 部屬裸機流程圖 :
1. `nova-api` 和 `nova-scheduler` 發送部屬裸機請求給 `nova-compute`
2. `nova-compute` 透過 `nova virt driver` 把請求傳給 `ironic-api`
3. `ironic-api` 把請求傳給 `ironic-conductor`
4. `ironic-conductor` 透過 `driver` 部屬裸機

#### Horizon ( 儀錶板 )
- 使用者操作介面，用瀏覽器開啟操作
- 方便使用者操作與使用，不需要使用指令來操作 Openstack
## Heat(編排服務)
- 功能
- 當需要管理的資源太多，一個一個手動設定很麻煩，可透過 heat 自動化部署或配置，比如自動創建虛擬機、掛載 Volume..
- 以 template 定義對 resource 的操作順序
- resource: 指虛擬機或是 volume 等 OpenStack 中的資源
- heat 解析 template 後產生的 stack
- stack: resource 的集合
- 完成一個 stack 的創建，就能完成對多個資源的操作

## Swift(物件儲存服務)
* 功能
- 存取非結構性的資料，e.g. 文件、網路內容、被分、影像等
- 透過 REST API 操作（儲存、刪除、取得） Object
:::info
- 結構化資料
- 每筆資料有規定的格式
- 非結構化資料
- 形式自由，不用遵守格式規劃
- 通常比結構化資料更用更多儲存空間
:::

- Proxy Server：接收外部 HTTP 請求，把請求傳送到對應的 Object Server
- Ring：計路存除對像與實體位置間的映射(mapping)，分為 Object Ring, Account Ring
- Object Server
- Container Server
- Account Server
- 處理與 Account

* 服務
* 為了確保每個節點之間的資料一致性，seift 提供 **Auditor**, **Replicator** 和 **Updater** 的服務
- Auditor
- 檢查 object, container, account 資料的完整性
- 如果發現損壞 (e.g. bit rot) :
:arrow_right: 文件會被移到隔離區，Replicator 再從其他節點複製完整副本替代

- Replicator
- 確保其他 storage node 的資料和本地的資料一致
- 假如其他 storage node 的資料過舊或遺失
:arrow_right: 會把本地資料複製一份過去
- 假如是本地資料過舊或遺失 :
:arrow_right: 不會把其他 storage node 的資料複製過去
- Updater
- 在故障或高負載時，可能會更新失敗 :
:arrow_right: 此次更新的資料就會交給 Updater 處理

# 實作
用 Microstack 部署 OpenStack
- 透過 Ubuntu Snap Package 安裝
- Why Microstack?
- Openstack 部署設定複雜：Service 數量多且各自有很多設定檔和參數，會安裝很痛褲
- Microstack 安裝簡單快速：只需要 2 個指令和 30 分鐘就

### 安裝 MicroStack
- 至少要有 8 gb RAM、100 gb 記憶體、Ububtu 18.04 or 20.04
- 安裝指令
- `sudo snap install microstack --beta --devmode`
- `devmode` 軟體對系統有完全的存取權限
- `--beta`: 測試版的 channel
- 初始化
- 自動部屬、設置設定檔和啟動 OpenStack 服務

        sudo microstack init --auto --control

- 查看已經安裝了哪些服務

        microstack.openstack catalog list

#### 操作 Openstack
- 瀏覽器打開 http://10.20.20.1，進入畫面
- * username 為 admin
* password 要在 terminal 下 `sudo snap get microstack config.credentials.keystone-password` 取得
* 可以直接用介面操作或是用 terminal 以指令操作
* 新增虛擬機 : `microstack launch {映像檔名稱} --name {虛擬機名稱}`

### 微服務 Microservices

#### 定義
- 是一個軟體開發的架構，把系統模組化，將功能拆分開來，會餓自跑在獨立的環境中(通常會式容器)，建立獨立的環境和資源，最後每個功能會提供 API 讓服務可以串起來
- ex :
#### 傳統單體架構的缺點
1. **無模組化**
- 功能可重用性較低 : 如果有其他系統需要用到這個系統的其中一個功能，因為要還原部屬的環境較麻煩，因此沒辦法快速地建立出這個功能。
2. **可用性低**
- 如果有一個功能 crash ，可能整個系統就不能動了。
3. **單一功能擴展性較低**
- 因為全部功能都跑在同一台 server ，無法把資源用在較重要的地方。
4. **新增或更改功能較困難**
- 因為全部的功能都在跑同一個 server ，所以若新增或更改了某功能，需要把系統上全部的功能重新編譯一次，會花很多時間，如果沒辦法一次更新完，整個更新時間就會比較長
5. **彈性較差**
- 假如這個系統有某些功能要用不同的語言寫會有更好的performance 或更快的開發效率，就會比較困難

#### 微服務架構的優點
1. **個別開發的效率較高**
- 可以把系統切割給不同人寫
2. **有模組化，可重用性較高**
- 把各個服務個別執行，如果有其他的系統也需要用到這個服務就可以直接呼叫 API
3. **可用性比較高**
- 其中一個分開的功能有問題，系統其他服務可正常運作
4. **新增或更改的功能簡單**
- 因為一個環境只會負責單一功能，要重新建立一次整個環境比較容易
5. **單一功能的擴展性高**
- 可只針對單一的服務進行擴展

#### 微服務的特點
1. 模組之間要頻繁溝通
2. 相較傳統單體架構，需要花更多資源規劃

#### 總結
:::success
有鑑於上述 **單體架構的缺點** & **微服務的優點** ， 可知總體上微服務已經是一個趨勢
:::
## Docker Swarm
- 用於效率管理多台 node 上的 containers，盡量把流程自動化
### 架構
- 把一群 node 建立叢集，利用 manager node 去管理和分配給 worker node
- manager node
- manager status
- 分成 Leader,Reachable,Unavailable
- Leader: 主要管理 node，負責 swarm 叢集全部的管理
- Rechable: 可以在此 node 下一般的管理和部屬指令，但最後的命令還是會送到 leader node 執行
> 代表實際上會由 leader node 去改變叢集狀態，所以如果 leader node 發生問題，就無法在 reahcable node 上管理和部屬
- Unavailable: 目前不可使用的 node
- leader node 掛掉
- reacherable node 會用 **Raft 演算法** 的方式投票重新選出 leader node
:::info
### Raft 演算法的 Leader election 問題 :
- leader node 會定期地給其他 reachable node 傳送心跳，告訴他們自己還活著
- 當 reachable node 超過 election timeout 的時間(通常會介於 150~300 ms，隨機的，每次會不一樣 ) 沒有收到 leader node 的心跳
:arrow_right: reachable node 就會當 leader node 掛掉了。
- reachable node 請求其他 reachable node 投票 :
- 當超過半數(含自己)就贏了，它就會告訴其他的 reachable 的 node 現在自己是 leader node。
- 剛好有兩個候選的 node 的 election timeout 相同，又剛好又獲得同票，就會形成流票(split vote)
- 此時每個 reachable node 就會再跑一次 election timeout 再重新選一次直到選出 leader node。
- 因為要超過半數才可以決定新的 leader，以 manager node 的數量最好是奇數
:::
- manager node 之間的資料同步
- 會用 Raft 演算法確保各個manager node 的 swarm 叢集的資料相同
- 如果有 node 發生資料不一致的情況
- reachable node 會先檢查目前紀錄的 log 中 index 跟 leader node 要給自己的 index 是否相符
- 檢查自己有沒有缺少資料
- 沒有缺資料的話，直接接受新的 index 命令
- 有缺資料的話，先找舊的 index 的 log 直到符合自己目前的紀錄
- 把之前的資料補齊
- 超過半數 (含自己) 的 manager node 有成功新增資料，leader node 才會實際執行命令
### 優點
- 方便
- 可以快速同時部屬服務的 container 在不同台 sever，以及有效率的管理和監控多個在不同 server 上的 container
- 高可用性:
- 可以藉由偵測 server 目前是否正常，決定是否一把服務部屬到其他台 server
- 簡單：指令簡單明瞭，很多指令和 docker 差不多，也可以使用 docker-compose.yml 就可以設定服務內容，上手快
- 負載平衡
- 同個服務可以利用多個 replicas 來達成負載平衡
- 擴展性高
- 當流量較大時，可以快速鍵利多個 replica tasks 來分散流量
- 當流量恢復正常，可以快速減少 replica tasks， 不會過度使用資源
## Play with docker
- url : https://labs.play-with-docker.com/