在上一篇《AIGC 利器 Ray 雲原生探索之路--Ray Core 篇 (上)》中，已經基本介紹了 Ray Core 的一些架構、關鍵概念等，在這裡繼續補充剩餘的一些部分，并結合一些實踐的操作，來幫助了解。
01 排程能力
當資源請求 (i.e RequestWorkerLease PRC) 被 raylet 接受之後, 整個過程就如上圖的狀态機一樣，主要包含三個狀态:
Granted: 在這個狀态下，client 是可以使用申請的資源和 raylet 傳回來的對應的 worker 去運作 actor 和 task 的。
Reschedule: 如果有比本地節點更合适的節點的時候，就需要重新排程到别的節點，這個過程就是重新排程的過程。在這個過程中，本地節點是可以從叢集視角去看到叢集全部節點的資源使用情況。
Canceled: 當申請的資源無法被滿足的時候，就會取消本地的排程。比如一個 client 請求了一個特定的機器，但是這個機器挂了。再比如，給 task 請求配置設定的運作環境不能正常的建立出來，就會導緻 raylet 不能啟動 worker 去運作 task，這個時候排程的請求也會被取消。
排程政策主要包含：
Hybrid Policy：如果不指定特定的排程政策，這個就是一種預設的排程政策。該政策首先是嘗試将 task 放在自己本地來運作，但是當本地節點的資源使用量超過了配置的門檻值（預設為 50%），就将 task 配置設定到其它的機器上，這個配置設定機器的過程是按照機器的 ID 進行排序（保證每次都按照相同順序來），這裡有第一遠端節點、第二遠端節點等等，依此類推，直到所有節點上的關鍵資源使用率都超過門檻值。它将選擇資源使用率最低的節點。該政策是在 bin-packing 和 load-balancing 之間進行平衡。bin-packing 的場景就是先緊着第一台機器，等第一台機器實在不行了，再到第二台，這種會造成大部分有 task 的機器的負載都很高，會導緻一些不确定的問題，機器的負載高了，什麼問題都可能發生。load-balancing 就是下面介紹的 spread 的方式，簡單了解就是，有 task 大家一起均攤來運作，這種會有資源碎片化的問題。
Spread Policy：該政策使用輪詢的方式，在具有可用資源的節點之間配置設定 task，這樣可以保證所有的 task 在整個叢集中比較均衡地分布，不至于某一些機器的負載很高，其它的機器又很空閑。但這種排程的問題是，可能會導緻資源碎片化。
Node Affinity Policy：使用此政策，使用者可以明确指定 task 或 actor 應運作的目标節點。如果目标節點處于活動狀态，則任務或參與者隻會在那裡運作。如果目标節點已挂了，則取決于親和力是否是軟限制，task 或 actor 可能會被安排到其他節點或無法被安排。
Data Locality Policy：簡單了解就是，task 可能依賴很多參數對象，task 依賴的參數對象分布在哪個節點多，就排程到哪個節點去，這樣就不需要将依賴的參數對象搬來搬去了。就是所謂的，資料本地化政策。
Placement Group Policy：task 和 actor 将在 placement group 所在的位置運作。
02 運作時環境
運作時環境 (Runtime Env)，定義了 python 腳本運作所需要的依賴，包括檔案包，還有環境變量等，它是在運作時動态的被安裝的，可以提供給一個 Ray 的 job，或者 actors，或者 tasks 去運作。
運作時環境的安裝和删除是通過運作在每一個 node 上的 RuntimeEnvAgent gRPC server 服務來完成的。在排程 tasks 和 actors 的時候，RuntimeEnvAgent 元件也是一個關鍵的元件。
當一個 actor 或者 task 需要運作時環境的時候，raylet 會發送一個 gRPC 請求到 RuntimeEnvAgent 去建立運作時環境，如果不存在就建立。當建立一個環境的時候會涉及到以下的一些工作：通過 pip install 去下載下傳和安裝包；為 worker process 設定環境變量；在啟動一個 worker process 之前，先調用 conda activate；從遠端的雲存儲中下載下傳檔案等。
運作時環境中的一些資源，如下載下傳的檔案、被安裝的 conda 環境，這些會被緩存在每一個 node 上，這樣在不同的 jobs、actors、tasks 之間可以共享這些資源。隻有當緩存的大小超過一定的大小，那些目前沒有被任何 jobs、actors、tasks 使用的資源就可以從緩存中删除。
可以在程式中指定，也可以在送出 job 的時候，設定 Runtime Env。同時也支援為 actor 或者 task 指定特定的 runtime env。
03 日志能力
當一個 actor 或者 task 列印日志到 stdout or stderr，這些 stdout or stderr 會被自動的重定向到對應的 worker 的日志檔案中，因為 actor 和 task 的運作都是在一個 worker process 中的。log monitor 元件會運作在每一個 node 上，同時它會周期性地讀取 Ray 的這些本地日志檔案，然後通過 GCS 的 pubsub 機制，釋出這些日志消息給到 driver 程式。driver 程式會負責聚合和列印所有來自于 actors 和 tasks 的日志。
04 Metrics 能力
Ray 原生地內建了 OpenCensus，同時預設支援将 metrics 資料導出到 Prometheus。所有的 Ray 的元件，包括 GCS、raylet、workers 将自己的 metrics 資料 push 到它們本地的 Ray agent 程序中，然後每個節點的 Ray agent 通過 OpenCensus 去暴露 metrics 資料，作為 Prometheus 的一個 exporter，這樣資料就可以被 Prometheus pull 到 Prometheus 裡。
05 GPU 能力
預設情況下，Ray 将通過自動檢測主機硬體的方式得知 GPU 的裝置數量，同時設定給自己，當然也可以通過設定來覆寫自動檢測出來的結果。如果一個 actor 或者 task 的執行需要 GPU 資源的時候，可以通過給 actor 或者 task 指定需要的資源請求，如@ray.remote(num_gpus=1)。這個時候，Ray 會排程 actor 或者 task 到滿足資源需求的機器，也就是有空閑 GPU 的機器去運作 actor 或者 task，同時在 actor 或者 task 在運作之前，通過設定 CUDA_VISIBLE_DEVICES 環境變量，将 GPU 指定給 actor 或者 task。下面舉例說明了這個過程：
在雲原生的場景下，需要使容器可以識别 GPU 的裝置，同時将裝置資訊傳遞給到 Ray 内部。Ray 的官方的 docker 鏡像版本中，提供了 GPU 版本的鏡像了。在使用的時候，需要在 RayJob 的定義中指定類似 “ nvidia.com/gpu: 1 ” 這樣的資源申請方式，同時在 actor 或者 task 上指定需要的 GPU 請求，如：
06 Autoscaler 能力
Ray Autoscaler 負責從叢集中添加和删除節點。它檢視分布式排程器公開的邏輯資源需求、叢集中目前的節點、叢集的節點配置檔案，計算所需的叢集配置，并執行将叢集移動到所需狀态的操作。Autoscaler 會從 GCS 中去拉取目前叢集的負載情況，然後調用雲廠商的實作去添加和移除節點。
自動擴縮容的主要工作包含以下幾點：
1. 當應用送出 actors、tasks、placement groups 去請求資源，如 CPU、GPU 等。
2. 排程器會檢視資源的要求和可用的資源，然後決定 tasks 應該放置的位置，或者資源不滿足的時候就會阻塞，這個資訊會被作為一個快照放到 GCS 中。
3. Autoscaler 作為一個獨立的程序運作，它周期性地從 GCS 中抓取步驟 2 中提到的快照，然後從中檢視叢集的可用資源、請求的資源、有什麼 tasks 是阻塞的，以及 worker 節點被設定的配置，然後運作 bin-packing 算法（在排程部分提到過）去計算一下，在能保證運作中的 tasks/actors/placement group 和阻塞的這些 tasks/actors/placement group 的資源都能滿足的情況下，一共需要多少節點。
4. 然後 Autoscaler 使用 node provider interface 去添加和移除節點，各種 cloud provider 可以去實作自己的 node provider interface，如 AWS、 GCP、Azure、Kubernetes 以及 on-premise 的資料中心。
5. 當新的節點啟動了，也注冊到 Ray 的叢集中了，這些節點就可以接收應用的工作負載了。
07 實踐
安裝 KubeRay：
建立 RayJob：
檢視 RayJob：
通路 Ray Dashboard：
- 全局視圖：
- Job 視圖：
- 叢集視圖：
- Actor 視圖：
- Metrics 視圖：
- Log 視圖：
08 總結
以上從 Ray Core 本身介紹了相關的知識，同時也基于社群 Kuberay 結合 Kubernetes 的方案，通過實踐展示了一下 Ray Core 的相關能力。
參考連結：
[1]https://docs.ray.io/en/latest/
[2]https://docs.google.com/document/d/1tBw9A4j62ruI5omIJbMxly-la5w4q_TjyJgJL_jN2fI/preview#
本文作者 ：熊中祥
現任「DaoCloud 道客」技術合夥人兼雲原生技術專家