# LSA - 負載平衡和高度可用性
[TOC]

## 高度可用性 （High Availability）

<!-- > HTTP 500 內部伺服器故障：
通用錯誤訊息，伺服器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。沒有給出具體錯誤資訊。 -->
<!-- 介紹一下當服務沒有了可用性(不能正常使用)的狀況。
報告GG、影片看不了、影響到我們的使用 -->

### 可用性？（Availability）：

一個系統處在能正常工作的時間比例。
> 當被委託任務時，它有＂幾％＂的時間是能正常工作的。
可用時間 ／ 整體時間 ＝ 可用性

$A = \frac{執行時間}{執行時間+回復時間} =\frac{MTBF}{MTBF+MTTR}$

- A （可用性 **A**vailability）
- MTBF （**M**ean **T**ime **B**etween **F**ailures　平均故障間隔）
- MTTR （**M**ean **T**ime **T**o **R**ecovery　平均復原時間）

> 圖片來源：https://zh.wikipedia.org/zh-tw/File:Time_between_failures.svg

- 設：
- 有個裝置的平均每 81.5 年會發生一次故障
- MTBF ＝ 81.5 x 24 x 365 ＝ 713940 （小時）
- 修好它平均要花一小時
- MTTR ＝ 1 （小時）
- 套上計算公式： $\frac{MTBF}{MTBF+MTTR}$

- 可用性（A） = $\frac{713940}{713940+1}$ = 0.9999986 ≌ 99.999%
> 意思：當你需要這個服務的時候， 99.99986％ 的時間能正常使用，故障的時間比例只有 0.00014％
- 達到了＂5個9＂的可用性。

:::info
### 幾個9：

在高度可用性中，用來 **度量可用性高低** 的方式。

如：
當某一系統的可用性達到了 0.999999 時，我們就會稱呼它有 ＂6 個 9＂ 的可用性 （小數點後面有幾個 9）。

但實現　6 個 9　的付出成本太高，因此企業裡都只討論　3～5 個 9。

故障時間比例（U） ＝ 1 － 可用時間比例

*用正常運作時間與總時間 （1年） 做比例

3個9： （1－99.9％） ＊ 365 ＊ 24 ＝ 8.76 小時。
4個9： （1－99.99％） ＊ 365 ＊ 24 ＝ 0.876 小時 ＝ 52.56 分鐘。
5個9： （1－99.999％) ＊ 365 ＊ 24 ＝ 0.0876 小時 ＝ 5 分 15.36　秒

通常是分成 12 個月故障，降低每次故障的時間長度，盡可能減少使用者受到的影響。

為什麼不討論 1、2、6 以上的幾個 9？

1個9： （1－90％） ＊ 365 ＊ 24 ＝ 876 小時 ＝ 36.5 天
2個9： （1－99％） ＊ 365 ＊ 24 ＝ 87.6 小時 ＝ 3.65 天
6個9： （1－99.9999％） ＊ 365 ＊ 24 ＝ 0.00876 小時 ＝ 31.536 秒
7個9； （1－99.99999％） ＊ 365 ＊ 24 ＝ 0.000876 小時 ＝ 3.1536 秒
> 結論：不是沒用（1跟2個9），就是太燒錢（6個9含以上）。

| | 系統可用性比例 | 故障時間（秒） | | |
| ----- | ------------:| ------------:| ----- | ---- |
| 1個9 | 90％ | 3153600 | 36.5 | 天 |
| 2個9 | 99％ | 315360 | 3.65 | 天 |
| 3個9 | 99.9％ | 31536 | 8.76 | 小時 |
| 4個9 | 99.99％ | 3153.6 | 52.56 | 分鐘 |
| 5個9 | 99.999％ | 315.36 | 5.256 | 分鐘 |
| 6個9 | 99.9999％ | 31.536 | | 秒 |
| 7個9 | 99.99999％ | 3.153599998 | | 秒 |
| 8個9 | 99.999999％ | 0.315360002 | | 秒 |
| 9個9 | 99.9999999％ | 0.031535999 | | 秒 |
| 10個9 | 99.99999999％ | 0.003153597 | | 秒 |

:::warning
此提出的年故障時間是＂標準＂邊界。表示一整年的 down time 只能低於該時間，不可超過。
- 年故障時間為　30 分鐘，未達＂5個9＂的可用性，仍屬於＂4個9＂。
:::
<!-- - 大多數業務達到 4個9（99.99％）就很夠用了。
- 而大部分IT部門大部分被要求達到 5個9（99.999％），即一年內不能中斷服務超過 6 分鐘。
像一些政府網站，經常故障服務不可用，能做到 99.9％就不錯了。 -->

<!-- > 知道了這些可用性的高低分別就能幫助業者去尋找相對應的　server　去購買他們的服務了（以免錢花得不夠服務常停機；錢花得太多買太好導致效能過剩） -->
:::info
Data Center Tier
參考標準：Uptime Institute
> 目前最有公信力的組織（目前沒有通用標準）

- Tier I
具有單一電力和冷卻途徑，且沒有備份組件的數據中心。
- 設施要求：
- 有不間斷的電源供應。
- 有為 IT 系統特別規劃出的空間
- 備有發電機
無法進行不斷電維修、維護。
- Tier II
- 擁有能夠掩護電力和冷卻路徑的備援，提供更好的維護保障。
- 備援包括：
- 能源儲備
- 發電機
- 水冷機
- 散熱設備
能夠不斷電移除組件。
- Tier III
- 能同時維護多條電力與冷卻路徑，且擁有 N+1 的冗餘。
- N+1：　能確保在故障維修時，其他的組件能正常執行。

- Tier IV
- 基於 Tier III 的設計上，再增加了
- 擁有 2N+1 的冗餘
> 代表該設施有一套完全相同且獨立的備用系統。

| | Tier I | Tier II | Tier III | Tier IV|
| ----- | ------------| -----------| ----- | ---- |
| 正常運作的時間比例 | 99.671％ | 99.741％ |99.982B％ | 99.995％ |
| 預估停機時間 | ＜28.8 小時 | ＜22 小時 | ＜1.6 小時 | ＜26.3 分鐘 |
| 冗餘 | 無 | 部分電源與冷卻冗餘(該部分N+1) | 全設備N+1 | 可容錯（2N or 2N+1） |
| 可同時維護 | 無| 無 | 部分 | 可 |
| 人員配備 | 無條件限制 | 要換班一班 | 換一班以上 | 24/7/365 管理 |
| 客戶面向 | 小公司、初創企業 | 中小企業 | 成長中的大企業 | 大型企業、政府單位 |

:::

- 做到更多 9 的方式： *不斷監控自己的服務。*
盡可能做到能夠不斷在服務掛掉的時候及時恢復服務。

>就像開車一樣，出門前做好**胎壓檢查**，在車上事先**預備備胎**，才能在爆胎時**及時補上**新輪胎，繼續上路。

### 怎樣才能叫高度可用性

- 系統具有一定的**容錯能力**。
- 保證服務**不被中斷或是當機太長時間**
>將**停機時間**所造成的**影響降至最小**。
- 盡量讓我的服務能夠正常提供。

### 實際執行的項目

- 1. 消除單點故障（single points of failure）
> 不會因為單一組件的故障，導致整個系統一起故障。

> 圖片來源： https://en.wikipedia.org/wiki/Single_point_of_failure#/media/File:Single_Point_of_Failure.png

- 2. 可靠的交叉（reliable crossover）
> 在冗餘系統中，交叉點（cross point）往往會變成單點故障，可靠的系統必須提供可靠的交叉
- 3. 偵測故障的發生

### 誰會需要到HA呢？
- 例如：
- 網路：
- 伺服器服務提供者：
- 如： Google、AWS、Microsoft。
- 電信平台業者：
-　如： 中華電信、遠傳、台灣大哥大。
- 金錢：
- 各證券交易所、銀行、保險公司。
- 基礎建設：
- 鐵路、航空、海運業者。
- 遠端操作技術：
- 無人駕駛車輛、無人機。
- 生命、安全：
- 醫院重要醫療設備、核電廠的反應爐。

:::warning
也不是所有東西都需要高可用性。如：辦公大樓的夜間停機維護，
:::
#### HA的重要性
:::warning
若是故障或無法執行的時間太久就會造成極大的損失，金額在較大型的企業可上千萬的損失（企業**通常可接受範圍的時間為秒／分鐘**）
:::
- 停機導致**商譽受損**

能夠盡可能持續、正常供人使用的服務，才會讓人想要使用。
- 故障造成的**資料丟失**

維持資料的完整性，確保客戶的權益不會因此受損，也避免在緊要關頭時服務故障，造成客戶的重大損失。
- **遵守與客戶簽訂的 SLA**

若因為可用性不夠高，使得服務提供方不能履行承諾，提供應進的服務。將會因此而賠償，進而造成額外的成本。

#### SLI、SLO、SLA？
#### 網站可靠性工程 SRE（Site Reliability Engineering）
- 由Google提出的概念，一群軟體工程師集結而成的團隊，負責**改善服務、解決問題，實現任務自動化，進而提升使用者的操作體驗。**

> Things break; that’s life. （東西早晚要壞的，這就是生活。）

#### 服務水準指標 SLI（Service-Level Indicator）
* 用來**衡量服務的使用情況的量化指標**，類似訂定對服務的效能的健康檢查項目。
- 常見標準：
- 請求延遲（request latency）
> 服務超出閥值的有效請求比例。
- 系統吞吐量（system throughput）
> 常見的衡量單位：每秒幾位元組（bytes per second）
- 請求失敗率（failure per request）
- 可用性（availability）

* 範例（來自 google 的 SRE團隊）：
* 400ms 的請求延遲
* 
> 圖片來源：https://cloud.google.com/architecture/defining-SLOs

- SRE 團隊會測量後訂定閥值（threshold），代表該服務的某項目效能的好/壞。若系統低於的該項功能低於指標過低，就可能要參考使用其他方式穩定系統。

- 透過長時間線性的測量追蹤，能夠提供出 當有服務需求時，能夠正常提供服務的可能性數據。

#### 服務水準目標 SLO（ Service-Level Objective ）
* 為系統可用性設定一個更精確的目標，重點是要與一段時間做掛勾來衡量服務**期望狀態、目標範圍**
* SLO 是由以下**三種**元素組成：
* SLI （Service-Level Indicator）
* 一段時間區間
* 目標
* 先定義每個服務的使用者可接受的最低可靠性水準
* 範例：
* 在一個月之中，99.9％ 的請求延遲有在 300ms 內

#### 服務級別協定 SLA（ Service-Level Agreement ）
* 對服務使用者的承諾，是以 SLO 標準指定的商業合約，當中會**承諾其 SLO 應在一段時間內達到特定水準，若未達到一段時間內保證的目標則會產生罰則**
* **違約就會賠錢**、退款、免費提供服務或是增加服務有效期限等**額外補償**
* 示例：
如果服務在一個日曆月內未達到 99.95％ 可用性，則該服務提供商每分鐘都會因不合規而補償客戶。
- SLA 規格範例：
<!--
總結：說到合約的效力時間、以及保障範圍，相關定義等等 。
服務描述，以及提供的水準。 如：承諾提供的
-->
> 圖片參考：
> chrome-extension://bocbaocobfecmglnmeaeppambideimao/pdf/viewer.html?file=https%3A%2F%2Fnccur.lib.nccu.edu.tw%2Fbitstream%2F140.119%2F35384%2F7%2F93260507.pdf

- Google 雲端儲存的範例：
- Google 的補償措施：
> 給credit
> 圖片參考：https://cloud.google.com/storage/sla

### 怎麼達到HA

* 計劃性停機
* 讓系統或資料離線以**執行必要維護作業**（例如夜間備份或安裝新硬體或軟體）時，高可用性可以減少使用者的影響
> 通常這種維護是破壞性的

* 避免意外停機
* 避免因**人為錯誤**、**軟體問題**、**硬體故障**及**環境問題**而導致意外停機

* 備份時間範圍縮減
* **減少系統或服務在備份期間無法使用的時間**
- 平行儲存: 多磁帶儲存。
- 儲存至非抽取式媒體: 儲存至比抽取式媒體還快速的媒體，減少一次性要備份的資料量。

* 負載平衡
* 將任務工作交給其他閒置的 port 處理，減少單一 port 乘載的服務量，以避免超載掛機。

* 冗餘

- 較完整的架構圖

* 當裝置發生故障時，有備用的裝置能夠上來**替補、維持服務**一般來説就是**備援**。
* 避免單點故障 （Single Point Of Failure）
* 形成叢集系統（Computer Cluster）

<!-- > 備份的規模? 最少規格需要幾台備份? (三重模組冗餘)
不是圖片上的只有另一台做備用(提醒) -->

* 資料復原：
- 回復目標時間 RTO（Recover Time Object）
- 回復點目標 RPO（Recovery Point Objective）
:::info

### 災難回復 DR （ Disaster recovery ）
* 盡可能的回復你的服務、功能。至少回復到能堪用的狀態。
> 只要服務能夠上線運作，才能算得上 recover 了

* 在HA裡面，只會討論到 Hot DR
#### Hot DR
- 允許系統在正常運行的情況下，系統能隨時做資料的更新、同步處裡。在災害發生時，能替代原本的系統繼續執行。

#### 回復點目標 RPO（ Recovery Point Objective ）
* 自上次資料復原點之後的**最大可接受時間長度**，決定了**最後一個復原點與服務中斷之間可接受的資料遺失**

- RPO 取決於數據中心數據恢復到 **怎樣的更新程度**，這種更新程度可以是上一周的備份數據，也可以是昨天的數據。

> 

<!-- DB就是一個cluster，當其中一台DB壞了的時候，其他台能夠take over，來達到 RPO 為 0，即：沒有任何的資料遺失。 (必備) -->

* RPO 數值越小，代表資料遺失的時間間隔越小。
* 在高可用性當中，RPO 值必須是 0

|回復點目標 RPO|
|--------|
|**零資料遺失**|
|可能會遺失進行中變更（停電一致性）|
|前次交易（數秒到數分鐘）|
|工作的前次批次（1 小時到數十分鐘）|
|前次主要中斷（4 個小時）|
|前次移位的開始（8 個小時）|
|前次儲存（每週、每日等）|

> 引用自： https://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/recovery-time-objective-rto-and-recovery-point-objective-rpo.html

#### 回復時間目標 RTO（ Recovery Time Objective ）

* 服務**中斷到恢復服務**之間的**最大可接受延遲**，決定了**可接受的服務無法使用之時間長度**

> 線路切換、備援切換、DNS　設定（將一個機房指向另一個機房），會有幾分鐘使用者是連不到的（非服務斷線）。　這個就跟幾個九有關(可用時間)。

> SLA 條約中討論的也是在＂沒調資料的情況下＂服務斷線了多久。

> 可接受範圍：30 - 50 ms，幾秒到幾分鐘算是高延遲了。

- RTO 數值越小，代表容災系統的數據恢復能力越強。

|回復時間目標 RTO|
|--------|
|接近零（接近立即）|
|小於 1 個小時|
|小於 4 個小時|
|小於 24 個小時|
|1 到 4 天|
|可接受超過 4 天|

MTTR（平均回復時間）：多個影響可用性事件中取得的**平均值**。
RTO（回復時間目標）：**單一**事件可允許的最大值、目標值。

:::

### 其他的高可用性的標準（參考自 IBM）
>出處：https://www.ibm.com/docs/zh-tw/i/7.2?topic=overview-high-availability-criteria)

#### 預算
* 每一個高可用性解決方案都有相關聯的成本,解決方案成本可包含**採購、部署解決方案的起始成本、使用解決方案的持續成本，以及任何成本**

#### 預防方面
##### 監控錯誤的發生 Monitoring
* 對於服務的健康狀態做定期**偵測和記錄**，若發生問題就要**有報錯提醒**
* 定期偵測（Heartbeat）：
* 資源的存取是否正常
* 用戶錯誤率突然提高（Error 404、Forbidden 403）
* 系統是否故障

##### 自動化失效接手及切換
* **在意外中斷執行期間進行自動化**，以進行失效接手處理。失敗時，應用程式可以自動失效接手至備份系統（包括所有應用程式環境啟動）。

#### 備份相關
##### 備援機制
* 遭遇中斷執行時要保護的資料，**備援需求是必須在正式系統中斷執行時保留 正常運作的一組應用程式、資料及系統環境**，讓服務功能能夠正常運行。

* 資料（系統、使用者）
* 系統環境
* 通訊與連線

##### 備份系統數
* **備份的次數越多次越安全**，也對資料校驗也有多一份保障

## 負載平衡 Load Balance
### 爲什麽需要負載平衡？
> 圖片來源： http://www.ifuun.com/a2018051012892641/
* 爲了解決網路流量分配問題，所以**會在多個伺服器之間分配網路流量的過程**
* **網路流量**： 來源 IP 或網址、請求 IP 或網址、走的通訊協定 Protocol 或連接埠 Port 等等
* 將網路流量有效的分配給多個設備去承載，那它的**好處**有以下這幾點
* **避免單個資源過載**
* **最大化吞吐量**
* **最小化響應時間**
* **最佳化資源使用**
* 減緩 DDoS （distributed denial-of-service）
* WAF(Web Application Firewall) 用防火墻去做**過濾**
* 降低單一主機被打爆的風險
### 常見的負載平衡演算法
#### Round Robin
* 依序分發


* 假設：**伺服器 2 硬體條件較弱**，無法有效的處理相關的服務


#### Weighted Round Robin
* 依序分發，但以權重為優先
* 假設：**伺服器 2 硬體條件較弱**，無法有效的處理相關的服務


#### Least Connection
* 連線數最少的伺服器優先接收連線

#### Weighted Least Connection
* 連線數最少的伺服器優先接收連線，但以權重為優先

#### Least Response Time
* 以最快的反應時間 N 來分發
* 假設：**伺服器 2 硬體條件較弱**，無法有效的處理相關的服務
* N = Active HTTP connection * response (Time to First Byte)


#### Random
* 純粹的快樂隨機分發


#### Other Balancing Method
:::info
* 最少連接數慢啟動時間 Least Connection **Slow Start Time**
* 當伺服器剛加入線上環境是，可以為其配置一個時間段，在這段時間內連接數是有限制的而且是**緩慢增加**的
* 這為伺服器提供了一個**過渡時間**以保證這個伺服器不會因為剛啟動後因為分配的連接數過多而超載
* 基於代理的自適應負載平衡 Agent-based adaptive
* 當所有伺服器的**負載低於管理員定義的下限時**，負載伺服器就會**自動切換**為 Weighted Round Robin / Round Robin 演算法來分配請求；如果**負載大於管理員定義的下限時**，那麼負載伺服器又會**切換回自適應方式**
* Agent 可以觀察當下伺服器的某些情況，而負載平衡器所觀察不到的
* CPU / Memory 負載

* 源 IP 雜湊 Source IP Hash
* 使用者和伺服器的源 IP 地址和目標 IP 地址以生成唯一的雜湊值
* （IP雜凑值） % （後台伺服器數量） = 目標伺服器
* % 是 mod 取餘數
* **當使用者的 IP 更動後所導向的目標伺服器會有幾率不一樣**
* Sticky / Session Persistence
* 使用者登入後以 Session 的方式去放 Cookie ，然後使用者就會在一段時間内一直導入同一台伺服器
* 要是伺服器挂掉了使用者怎麽辦呢？
* Stateful 持續的把使用者資訊導入到後台的對應 Sticky 的伺服器上
* 架構設計成讓其他資料庫 (ex: redis, memcache) 記住 session，再同步給 server
* 改成 stateless 的方式，降低對 sticky session 的依賴
* Stateless 將每一次的 session token 加密後到了後台的任意伺服器去做解密，並獲取使用者的資訊
:::

### 負載平衡器在 2、3、4、7 層的OSI模型的運作方式
#### 資料連結層 Data Link Layer
:::info
* 資料型態： frame
* 負責事項： 負責網路對硬體的溝通
* 常見協定： Ethernet
* 傳送依據： MAC Address
:::
* 負載平衡方法
* Linux Virtual Server
* Direct Routing
> 論文標題：具備負載平衡機制的虛擬機器叢集式系統的設計與實作
> 研究生：張嘉宏 指導教授：姜美玲教授
:::info
Front-end = 負載平衡器（收到 Client 的 Request）
Back-end = 伺服器（負責處理 Request）
:::
* **負載平衡器與伺服器之間要在同一個網域内**，并用 Hub 或是 Switch 等高速網路設備相聯
* **負載平衡器是唯一可以接收來至使用者 Request 的 Server**，且 Server 皆擁有相同的 VIP (Virtual IP)，位於相同的網段，爲了避免引發碰撞 (Collision)
* 後台伺服器要關閉 ARP (Address Resolution Protocol) 功能，讓使用者不能直接給伺服器送 Request
* 負載平衡器接收到 Request 封包，會去修改 data frame 的 MAC 地址，**修改成由負載平衡演算法排程所挑選的後台伺服器的 MAC 地址**去做處理
:::info
* MAC位址 （Media Access Control Address）
* 網卡地址（獨一無二）
:::
* Direct Routing 會比較快和有效率
#### 網路層 Network Layer
:::info
資料型態： packet
負責事項： 決定資料如何傳送到目的地
常見協定： IP, ICMP
傳送依據： IP Address
:::
* 負載平衡方法
* IP Tunneling
> 論文標題：具備負載平衡機制的虛擬機器叢集式系統的設計與實作
> 研究生：張嘉宏 指導教授：姜美玲教授
:::info
Front-end = 負載平衡器（收到 Client 的 Request）
Back-end = 伺服器（負責處理 Request）
:::
* 負載平衡器接收到使用者的封包後，會利用 IP 封裝 （IP Encapsulation) 的方式在原有的封包上再加上由負載平衡演算法排程所挑選的後台伺服器的 IP Header，使得負載平衡器可以將 Request 封包在不同網域中轉發給被選定的後台伺服器來做處理
* 選定的伺服器會由解封裝 (Decapsulation) 的方式處理完之後，將封包直接經由網路回傳給使用者
* IP TUN 需要對所送的封包進行封裝與解封裝的處理，**會產生額外的 Overhead 問題**

#### 傳輸層 Transport Layer
:::info
資料型態：segment
負責事項：負責傳輸過程的流量控制、錯誤處理、資料重送等工作
常見協定：TCP, UDP, RTP, SCTP
傳送依據：port
:::
* 負載平衡方法
* Network address translation (NAT)
* 負載平衡器將封包轉發給後台伺服器前會透過改寫封包的方式，**將 IP 與 Port 改寫成有負載平衡演算法排程所挑選的後台伺服器的 IP 與對應的 Port 再將封包轉發給選定的伺服器作處理**
* 選定的伺服器處理完之後會回應封包給負載平衡器，在由負載平衡器將 IP 和 Port 改成使用者的 IP 和 Port 然後傳回給使用者

#### 應用層 Application Layer
:::info
資料型態： message
負責事項： 定義應用程式如何提供服務
常見協定： HTTP, FTP, DNS, SMTP, SSH
:::
* 負載平衡方法

* GeoDNS / GeoIP
* 當使用者查詢目標的 DNS 伺服器時，DNS 伺服器會根據其在 DNS 查詢封包中的 Public IP 查找使用者的位置
* 接著 DNS 伺服器找到離該位置最近的伺服器，並在 DNS 應答中返回該伺服器的 IP 地址

* Reverse Proxy
* 内網是 Proxy 與伺服器之間的範圍
* 外網是使用者與 Proxy 之間的範圍
* 如果伺服器有更動後由 Proxy Server 去更換内網 IP 或是 Port
:::info
* 代理 Proxy/Foward Proxy
* 内網是使用者與 Proxy 之間的範圍
* 外網是 Proxy 與伺服器之間的範圍
* 也可是網路防火牆 WAF (Web Application Firewall)，阻絕外部直接存取內網資源
* 快取 Caching
* 若 Proxy 的伺服器裡面有使用者要取得的内容，就可以直接取不必在到伺服器去取

>圖片來源：https://redis.com/blog/json-web-tokens-jwt-are-dangerous-for-user-sessions/#:~:text=the%20JWT%20way.-,The%20JWT%20way,in%20the%20session%20token%20itself.
:::

### 負載平衡器硬體與軟體介紹
#### 硬體
* F5 Big-IP
* Radware

#### 軟體
* Linux Virtual Server
* Nginx / Nginix Plus
* HAproxy
* Keepalived

## 實作部分 DEMO
### 使用的代理軟體 HAproxy
* 是開源代理和負載平衡伺服器軟體
* 服務於網路 TCP 和應用 HTTP/S 層提供高可用性，通過在多個伺服器之間分配工作負載來提高速度和性能
* HAProxy 在 Linux、FreeBSD 和 Solaris 操作系統上運行
:::info
FreeBSD is a free and open-source Unix-like operating system descended from the Berkeley Software Distribution
> 資訊來源： https://en.wikipedia.org/wiki/FreeBSD

Solaris is a proprietary Unix operating system originally developed by Sun Microsystems. After the Sun acquisition by Oracle in 2010, it was renamed Oracle Solaris
> 資訊來源： https://en.wikipedia.org/wiki/Oracle_Solaris
:::
#### 好處與壞處
* 好處:
* 支援虛擬主機的，可以工作在4、7層
* 支援 Session 的保持，Cookie 的引導；同時支援通過獲取指定的 URL 來檢測後端伺服器的狀態
* 本身就只是一款負載均衡軟體；單純從效率上來講 HAProxy 會比 Nginx 有更出色的負載均衡速度，在併發處理上也是優於 Nginx
* 支援 TCP 協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對後端的 MySQL 節點進行檢測和負載均衡
* 壞處:
* 不支援 POP/SMTP 協議
* 不支援 SPDY 協議
> 也不支援 HTTP3(SPDY 舊稱)
> 如果早就有對方的key就能直接傳輸訊息，
> 可能做到 0 handshakes
> 不像HTTPS 每次都要 三項交握、再交換keys。 (5、7 次交換資訊)
* 不支援 HTTP cache 功能
* 過載配置的功能需要重啟程序
* 多程序模式支援不夠好 （multiprocess）
> Some features are single process bound as memory is not currently shared between processes
來源地址 : https://www.quora.com/What-are-the-downsides-of-using-HAproxy-Its-been-recommended-to-solve-my-kernel-panic-problems-which-come-up-under-load-Im-using-CentOS6-for-this-particular-stack

#### DEMO
* 高可用性和負載平衡器交由 HAProxy

        sudo apt install haproxy
        sudo apt install nginx
        sudo apt install lighttpd

* HAProxy 做爲高可用性的負載平衡器
* Nginx 和 Lighttpd 作爲 Web Server
* 進去 /var/www/html
* mkdir vhost
* cd /vhost
* vim demo1.html
* SERVER 1
* vim demo2.html
* SERVER 2
* vim backupdemo1.html
* BACKUP SERVER 1

> 為什麼要多增加backup server?

* 進去 /etc/nginx/sites-available
* demo1.conf

        server{
            listen 8081 default_server;
            listen[::]:8081 default_server;
            
            root /var/www/html/vhost;
            
            index demo1.html;
            
            server_name;
            
            location / {
                try_files $uri $url/ =404;
            }
        }

* demo2.conf

        server{
            listen 8082 default_server;
            listen[::]:8082 default_server;
            
            root /var/www/html/vhost;
            
            index demo2.html;
            
            server_name;
            
            location / {
                try_files $uri $url/ =404;
            }
        }

* Softlink 檔案到 sites-enable
* ln -s /etc/nginx/sites-available/demo1.conf /etc/nginx/sites-enable
* ln -s /etc/nginx/sites-available/demo2.conf /etc/nginx/sites-enable

        sudo service nginx restart

* 進去 /etc/lighttpd/lighttpd.conf
* server.document-root = "/var/www/html/vhost"
* server.port = 8090

* 進去 /etc/lighttpd/conf-available
* backupdemo1.conf

        $SERVER["socket"] == "10.0.4.15:8091"{
            server.document-root = "/var/www/html/vhost"
            server.errorlog = "/var/log/lighttpd/error.log"
            accesslog.filename = "/var/log/lighttpd/access.log"
            index-file.names := ("backupdemo1.html")
        } 

* Softlink 檔案到 conf-enable
    * ln -s /etc/lighttpd/conf-available/backupdemo1.conf /etc/lighttpd/conf-enable

sudo service lighttpd restart

* 去寫 frontend 和 backend-rear 的負載平衡資料（IP + Port）

sudo vim /etc/haproxy/haproxy.cfg

frontend http_front
bind *:80
stats refresh 3s
stats uri /haproxy?stats
default_backend htttp_rear
backend http_rear
balance roundrobin
option allbackups
server demo1.com 10.0.2.15:8081 check weight 3
server demo2.com 10.0.3.15:8082 check
server backupdemo1.com 10.0.4.15:8091 check backup

sudo systemctl restart haproxy

* 去 HAProxy 的狀態面板
    * 127.0.0.1/haproxy?stats
    
    ![](https://i.imgur.com/ajo64r3.png)

sudo apt install curl

    * 去訪問頁面用 curl 持續去訪問

while true;do curl 10.0.2.15;done;

    ![](https://i.imgur.com/zmzZQ5g.png)
    * 然後再去停掉 Nginx 的服務

sudo service nginx stop

    * 伺服器開始過渡，備用的伺服器即將上綫
    
    ![](https://i.imgur.com/LqJkGda.png)
    * 備用伺服器上綫服務了
    
    ![](https://i.imgur.com/nGxZOQ8.png)
    * 然後再去開啓 Nginx 的服務

sudo service nginx start

    * 伺服器開始過渡，備用的伺服器即將下綫
    
    ![](https://i.imgur.com/yMz5TbS.png)
    * 伺服器上綫服務了

    ![](https://i.imgur.com/4ZGhMgZ.png)

## 參考文獻
* 從服務層（Layer 7）load balnce 與 從網路層（Layer 4）load balance 的差別（OSI Layers）
    * https://avinetworks.com/glossary/layer-4-load-balancing/#:~:text=A%20Layer%207%20load%20balancer
* 服務層
    * Service層 - 概念篇 作者：Alan Tsai https://ithelp.ithome.com.tw/articles/10158249
* 負載均衡
    * 負載均衡 - 維基百科 https://zh.wikipedia.org/wiki/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1
    * 應用負載平衡設備提升跨行服務之高可用性 - 作者：許聖偉 https://www.fisc.com.tw/Upload/9678ffd1-2c9f-468f-b8cd-241fca1d5c8e/TC/11.%20%E8%A8%B1%E8%81%96%E5%81%89.pdf
    * Comparing Load Balancing Algorithms - jscapeus https://www.youtube.com/watch?v=iqOTT7_7qXY
    * NGINX and the “Power of Two Choices” Load-Balancing Algorithm - Owen Garrett https://www.nginx.com/blog/nginx-power-of-two-choices-load-balancing-algorithm/
    * Algorithms for making load-balancing decisions - IBM https://www.ibm.com/docs/en/datapower-gateway/10.0.1?topic=groups-algorithms-making-load-balancing-decisions
    * Cloud Computing｜服務型式篇 - 作者：吳其勳 
https://www.ithome.com.tw/article/93007
    * Logical Servers https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SecurityManagement_AdminGuide/Topics-SECMG/Logical-Servers.htm#:~:text=A%20Logical%20Server%20is%20a,bound%20to%20this%20physical%20server.
    * Common Interview Questions: Defining High availability and Disaster Recovery - Jose 
    https://joseesposito.com/common-interview-questions-defining-high-availability-and-disaster-recovery/
    * How does a load balancer distribute client traffic across servers? https://kemptechnologies.com/load-balancer/load-balancing-algorithms-techniques/
    * 什麼是 OSI 模型？ - CloudFlare https://www.cloudflare.com/zh-tw/learning/ddos/glossary/open-systems-interconnection-model-osi/
    * Network and Transport Layers (Data Communications and Networking) - In Depth Tutorials and Information http://what-when-how.com/data-communications-and-networking/network-and-transport-layers-data-communications-and-networking/
    * https://www.jyt0532.com/2019/11/18/proxy-reverse-proxy/
    * https://www.youtube.com/watch?v=AWTBbsn5OTA&t=236s&ab_channel=ZeroToSenior
    * https://blog.csdn.net/weiyuefei/article/details/50513667
    * https://jameshfisher.com/2017/02/08/how-does-geodns-work/
    * 姜美玲教授的研究生張嘉宏論文 https://ndltd.ncl.edu.tw/cgi-bin/gs32/gsweb.cgi/ccd=8wIwJS/search?s=id=%22103NCNU0396007%22.&openfull=1&setcurrent=1
    
* 高可用性
    * 高可用性 - 維基百科 https://zh.wikipedia.org/wiki/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7
    * 服務級別協定 - 維基百科 https://zh.wikipedia.org/wiki/%E6%9C%8D%E5%8A%A1%E7%BA%A7%E5%88%AB%E5%8D%8F%E8%AE%AE
    * SRE 必修課：一次搞懂 SLI、SLO、SLA 差異，Google DevOps 理念實踐 作者：iKala Cloud 
https://ikala.cloud/understanding-sli-slo-sla-in-sre/
    * 復原時間目標 (RTO) 和復原點目標 (RPO) https://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/recovery-time-objective-rto-and-recovery-point-objective-rpo.html
    * Technology Monitoring the status of your service 
    From: Technology community (web operations) 
    https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
    * 高可用性概觀 IBM https://www.ibm.com/docs/zh-tw/i/7.2?topic=availability-high-overview
    * [Day 01] 什麼是MVC？能吃嗎？ 作者：小魚 https://ithelp.ithome.com.tw/articles/10191216
    * 深度解剖什麼是 SLI、SLO 和 SLA
http://www.itsmcn.com/faq/368.html
    * SLA服務可用性的4個9是什麼意思?
https://www.gushiciku.cn/pl/pLMh/zh-tw
    * 軟體系統可靠性的幾個9解釋
https://www.796t.com/content/1548995783.html
    * IBM Z 的 7個9 server
https://www.ibm.com/tw-zh/it-infrastructure/z/capabilities/resiliency
    * 系統可用性幾個9
https://www.codetd.com/article/883170
    * 冗餘
    https://zh.wikipedia.org/wiki/%E5%86%97%E9%A4%98
    * 可用性分類(未)
https://www.easyatm.com.tw/wiki/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%28HA%29
    * 高可用性工作方式
https://blog.csdn.net/weixin_30750335/article/details/98149177
    * 三重模組冗餘(https://zh.wikipedia.org/wiki/%E4%B8%89%E9%87%8D%E6%A8%A1%E5%A1%8A%E5%86%97%E9%A4%98)
    * SRE
https://rickhw.github.io/2018/08/03/DevOps/An-Introduction-to-SRE/
    * High Availability: What It Is and How You Can Achieve It
    https://www.kaseya.com/blog/2021/08/10/high-availability/
    * What is Anycast and How Does it Work? - Zenlayer https://www.zenlayer.com/blog/anycast-2/
    * 5 REASONS WHY YOU NEED HIGH-AVAILABILITY FOR YOUR BUSINESS
https://www.criticalcase.com/blog/5-reasons-why-you-need-high-availability-for-your-business.html
    * 建置高可用性的企業網路
https://netmag.tw/2010/08/07/%E7%94%A2%E6%A5%AD%E7%B6%93%E9%A9%97-%E5%BB%BA%E7%BD%AE%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7%E7%9A%84%E4%BC%81%E6%A5%AD%E7%B6%B2%E8%B7%AF
    * SharePoint Server 的高可用性與災害復原概念
https://docs.microsoft.com/zh-tw/sharepoint/administration/high-availability-and-disaster-recovery-concepts
    * 高可用性伺服器叢集管理
    chrome-extension://bocbaocobfecmglnmeaeppambideimao/pdf/viewer.html?file=http%3A%2F%2Fir.lib.ypu.edu.tw%2Fbitstream%2F310904600Q%2F8761%2F2%2F20.pdf
    * SLA 的範例
chrome-extension://bocbaocobfecmglnmeaeppambideimao/pdf/viewer.html?file=https%3A%2F%2Fnccur.lib.nccu.edu.tw%2Fbitstream%2F140.119%2F35384%2F7%2F93260507.pdf
    * Define SLOs
https://cloud.google.com/architecture/defining-SLOs
    *  Cloud Storage Service Level Agreement （SLA）
https://cloud.google.com/storage/sla
    * Uptime Institute Tier
https://uptimeinstitute.com/tiers
    * Data Center Tiers Explained
https://phoenixnap.com/blog/data-center-tiers-classification

* 實作 HAProxy
    * HOW TO:CONFIGURE HA-PROXY SERVER (LOAD BALANCER) https://www.youtube.com/watch?v=TkiGgUkn_PI&ab_channel=LinuxTechie
    * https://www.imperva.com/learn/availability/haproxy/
    * 使用説明 https://www.haproxy.com/blog/the-four-essential-sections-of-an-haproxy-configuration/
    * 使用説明 https://www.haproxy.com/blog/protect-servers-with-haproxy-connection-limits-and-queues/#:~:text=Here%2C%20HAProxy%20will%20accept%20up,the%20server%27s%20memory%20resources%20allowed.