# 本週任務

- 你們至少跑完四種 schedule 方法、改一次 job 資源再重跑，並將實驗結果(job 的資源要求量、兩個excel檔案)存下來

## 不會可以問，但不要太晚做
## 切記
- 在使用之前：先確認其他人沒有在使用(透過Discord聯繫)
- 在使用完後：要記得[關閉 yunikorn](#左上的視窗)、[刪除 job](#右上的視窗)

## 跑實驗測試方法說明

### terminal
- 主要用來跑 yunikorn，跟觀察 job
#### 連線到 40 核的 yunikorn0 的 vm

ssh 40yk.tailda8ba.ts.net

- 密碼：

user

- 註：請先確認 tailscale 有連線到

#### 使用 tmux
- 進入 tmux session <uk>

tmux a -t uk

- 離開 tmux session
先按 `ctrl` + `B`，鬆開兩個按鍵並按 `D`

- 進入後，會看到以下畫面 (下面會有三個視窗的說明)，用滑鼠看邊框顏色就知道當前在哪個視窗了

##### 左上的視窗

- 開關 `yunikorn`

- 啟動 `yunikorn` ，並將 log 訊息存入 `~/uk/ntcu114-yunikorn-k8shim/yunikorn_log.txt`

    make run > yunikorn_log.txt

- 關閉 `yunikorn`
`ctrl` + `c`
- 清理 `yunikorn cache`，通常簡單放入 log，就需要此操作。因為過於簡單的修改程式碼，重新 `make run yunikorn`是不會 apply 上去的

    make clean

---

##### 右上的視窗

- 部署與刪除 job
- 部署 job

    ./apply.sh

- 刪除 job

    ./delete.sh

---

##### 下方的視窗

- 觀測 job 是否完成

- 觀察 job 完成狀況

    ./watchJobs.sh

- 關閉
`ctrl` + `c`
- 觀察 pod 狀況

    ./watchPods.sh

- 關閉
`ctrl` + `c`

---

### VSCode
- 主要用來修改程式碼，以及看 yunikorn_log

- 照上面[連線到yunikorn-0](#連線到-40-核的-yunikorn0-的-vm)直接開啟到 `~/uk/ntcu114-yunikorn-core` 這個位置

#### 改 schedule 部署的策略
- 在 `~/uk/ntcu114-yunikorn-core/pkg/scheduler/scheduler.go` 的第 88 行
`customSchedule()` 是我們的 schedule 方法

##### 把他改成 `normalScheduleWithMonitor()`，就變成用 default 的 yunikorn

##### 改 default yunikorn 的 sort config
- 在 `~/uk/ntcu114-yunikorn-core/pkg/common/configs/config.go` 的第 200 行可以看到
- 可以參考官方文件去改：
- [application sort policy](https://yunikorn.apache.org/docs/next/user_guide/sorting_policies#application-sorting)
- [nodeSorting policy](https://yunikorn.apache.org/docs/next/user_guide/sorting_policies#node-sorting)

- 註：這是default 版的 yunikorn 的設定檔。需要先[將 yunikorn schedule 換成 default 版本](#把他改成-normalScheduleWithMonitor，就變成用-default-的-yunikorn)跑才會啟用，然後[重啟配一個 make clean 確保有 apply 更改到設定](#左上的視窗)

##### 改成學長的
- 先切換到`~/uk/ntcu114-yunikorn-core`
- 查看所有分支( * 代表當前所在的分支)

    git branch


- 學長的分支為 `FALB-original`，我們的分支為 `FALB-DL`
- 切換分支

    git checkout <branch-name>

- 註：要用學長的排程節點的方法，一樣[這邊](#改-schedule-部署的策略)要是`customSchedule()`
#### 查看 schedule 狀況
- 在 `~/uk/ntcu114-yunikorn-k8shim`


- 說明
- `build` 目錄 (註：以下兩個檔案在停止 yunikorn 後，才會產生)
- nodesResourceRecord.xlsx
- 節點的各種使用率變化以及圖表
- tenantsResourceRecord.xlsx
- 租戶的各種使用率變化以及圖表
- yunikorn_log.txt
- 能查看 yunikorn 的部署情況

## 能做的實驗方向
- 記得在完成後，在VSCode的[兩個excel](#查看-schedule-狀況)點右鍵下載檔案，主要是看 nodesResourceRecord.xlsx，如果更改app 的 sort策略，則是看 tenantsResourceRecord.xlsx
### 直接跑四種策略
- 不用改 job 的資源量跑以下[四種 schedule 方法](#schedule-方法)

### job 資源量調整
- 方向：可以修改成記憶體更高，因為目前都是 CPU 吃的比例比較高(資源佔叢集的比例)
- 註：一台 VM 目前 8 CPU、 32G Memory，所以不要讓 job 的資源要求量超過 4 CPU、 16G Memory

#### 修改 job 的方法
- 在`~/uk/test/job`，有 job1~job4共四個job，能改他們的資源量(不會改，去問 [chatGPT](https://chatgpt.com/) 或 [google](https://www.google.com/))

## schedule 方法 (節點的sort策略)
- yunikorn binpacking
- yunikorn fair
- 我們的
- 學長的
- 註：不用特別去調 app sort 策略，因為我之前有測過了，不過要試著換策略跑看看也是OK

- DL 的優勢case
- chatGPT
1. 极端不平衡资源需求
CPU和Memory需求极端不平衡： 例如，你可以设计某些任务几乎只需要CPU，而另一些任务则几乎只需要Memory。由于B算法基于主导负载进行评估，它在这种不平衡场景下可能会更合理地选择放置节点，避免CPU或Memory资源浪费。
示例：一个任务可能配置为cpu: 90%, memory: 10%，另一个任务为cpu: 10%, memory: 90%。
2. 平均使用率测试
设计具有相对平均的CPU和Memory需求的任务： 这种情况下，A算法和B算法都会表现得比较接近。你可以用这类测试任务作为对比组，看看两种算法在均衡任务负载的表现。
示例：cpu: 50%, memory: 50%的任务。
3. 轻量级和重量级混合任务
混合轻量级和重量级任务： 将一部分任务设置为只需要少量资源，另一部分任务设置为需要大量资源，这样可以让B算法基于主导资源负载，合理选择更能满足重量级任务需求的节点。
示例：设计一组轻量任务为cpu: 10%, memory: 10%，另一组重量级任务为cpu: 80%, memory: 80%。
4. 主导资源测试
设置其中一个资源为主导： 如果你有一组任务，其CPU和Memory需求比较接近，但其中一个资源需求稍高，那么B算法会优先考虑主导资源（即更高的那个）。这种任务组合可以测试B算法如何处理这些微小差异。
示例：任务设置为cpu: 60%, memory: 40%，以及cpu: 40%, memory: 60%。

通过这些设计，你可以测试B算法是否能更有效地分配资源，特别是在主导负载明确且资源需求不平衡的情况下，从而展示其在负载平衡方面的优势。