分配模擬工作

在 EstiNet 網路模擬器原本的架構中，一個 Dispatcher 可服務多個 GUI、處 理多個模擬工作。但在雲端系統中，由於一個模擬工作會再產生多個模擬子工作，

且每個模擬子工作皆可獨立執行（可視為原有架構中的一個模擬工作）。為了簡 化 Dispatcher 的工作，我們以一個 Dispatcher 處理一個模擬工作，也就是一個 Dispatcher 處理一個模擬工作的所有模擬子工作。一個模擬工作的所有子工作皆 完成時，代表該模擬工作完成。如果一個使用者有多個模擬工作，則每個模擬工 作皆有一個 Dispatcher 處理。

Manager 是整個雲端系統的控管中心，負責分配 Dispatcher 及 Coordinator。

Dispatcher 及 Coordinator 啟動時皆會連向 Manager，因此 Manager 知道目前系統 中有哪些 Dispatcher、Coordinator 可供分配。

在 Manager 收到模擬工作要求後，會先檢查系統中是否有空閒的 Dispatcher 及 Coordinator，若有則以空閒的 Dispatcher 及 Coordinator 提供服務，若無足夠 空閒的 Dispatcher 或 Coordinator 則開啟新的虛擬機器，即 DVM、CVM，以服務 此模擬工作。如圖 4-3 所示：

33

圖 4-3、分配模擬工作流程

Manager 分配 Dispatcher 給一個模擬工作的方式是通知 Dispatcher 模擬工作 的相關資訊、要求 Dispatcher 開始處理模擬工作。在 EstiNet 原有架構中，

Coordinator 於啟動時讀取設定檔、得知 Dispatcher 所在 IP Address，接著連向 Dispatcher 並向其註冊，Dispatcher 之後便可管理模擬機器。但在雲端系統中有 多個 Dispatcher，且無法以固定設定檔設定 Dispatcher 的 IP Address。我們修改原 有的連線機制，讓 Manager 於分配 Coordinator 時將負責該模擬工作的 Dispatcher 的 IP Address 告知 Coordinator，Coordinator 則可再自行連向 Dispatcher。

另外，Manager 開啟及分配虛擬機器時，會要求 NFS Exporter 分享相關目錄 給這些虛擬機器，此將於章節 4.4 說明。Manager 分配完模擬工作後，會將模擬 工作及負責虛擬機器的對應記錄在資料庫中。

Manager 開啟虛擬機器有兩個步驟：

1. 以事先建立的硬碟映像檔及 flavor 開啟虛擬機器。

2. 將一個未使用的 Floating IP Address 關聯至新啟動的虛擬機器。

34

在此雲端系統的建置中，須先手動在虛擬機器中安裝 EstiNet 網路模擬器需 要的環境，接著以此虛擬機器的硬碟製作硬碟映像檔，供開啟虛擬機器時使用。

如背景中所述，在 Openstack 中開啟虛擬機器須指定虛擬機器的運算資源，此設 定稱為 flavor。我們在 Manager 中指定事先建立好硬碟映像檔及 flavor，用於開 啟虛擬機器。

Manager 在資料庫中維護一份 Floating IP Address 表，記錄 Floating IP Address 跟虛擬機器的對應，代表哪台虛擬機器使用哪個 Floating IP Address。每開啟一 台虛擬機器，Manager 會找一個沒被使用的 Floating IP Address，將之關聯到新開 啟的虛擬機器，並更新資料庫、標示此 IP Address 由哪台虛擬機器使用。

由於 Floating IP Address 的關聯需在虛擬機器以從 Openstack 取得 Fixed IP Address 後才得以進行，因此「開啟虛擬機器」及「將 Floating IP Address 關聯至 虛擬機器」兩個步驟之間會有一小段時間的間隔。

「開啟虛擬機器」及「將 Floating IP Address 關聯至虛擬機器」是使用 Openstack 的功能。如背景中所介紹，Openstack API 是一 RESTful Web 服務，我 們透過傳送 HTTP 要求、接收 HTTP 回應使用 Openstack API。實作上我們使用 libcurl 函式庫（library）收送 HTTP 要求及回應。Manager 先以我們架設的 Openstack 系統的帳號及密碼取得認證 token，之後以 Openstack API 定義的指令 及格式傳送 HTTP 要求，進行「開啟虛擬機器」、「將 Floating IP Address 關聯至 虛擬機器」的操作。

在系統架構中提到，我們將虛擬機器分為專門執行 Dispatcher 的 DVM 及專 門執行 Coordinator 及模擬引擎的 CVM。為達到雲端系統的自動化，我們需讓 Dispatcher 及 Coordinator 能自動啟動。因此我們將 Dispatcher 及 Coordinator 加入 Linux 開機時會啟動的程序中，讓在 Dispatcher 及 Coordinator 能在虛擬機器開啟 後自動執行。我們依照 DVM 及 CVM 不同的需求撰寫啟動腳本（shell script）， 並將此腳本加入虛擬機器的/etc/rc.d/rc.local，Linux 於開機最後便會執行我們的 啟動腳本。

35

在 Dispatcher 跟 Coordinator 間有兩條連線。一連線用於傳輸控制命令，如 Dispatcher 要求模擬機器開始模擬、Coordinator 註冊等控制命令皆透過此連線。

另一連線用於傳輸模擬進度，此部分將於章節 4.2.7 說明。以下分別說明 Dispatcher 及 Coordinator 的啟動流程。

DVM 的啟動腳本執行以下動作：

1. 掛載（mount）NFS 上的目錄。

2. 執行 Dispatcher Manager。

為簡化軟體元件間的溝通及檔案傳輸，我們將模擬設定檔儲存在 NFS 中，

讓 Dispatcher、Coordinator 及模擬引擎透過掛載 NFS 存取模擬設定檔。

DVM 中 Dispatcher 都是由 Dispatcher Manager 啟動。Dispatcher Manager 負 責維持 DVM 中 Dispatcher 的個數，當一個 Dispatcher 完成工作、結束後 Dispatcher Manager 會再執行一個 Dispatcher。

實作上，Dispatcher Manager 先用迴圈 fork 出固定個數的子程序（child process），子程序以 execlp()執行 Dispatcher。接著用 sigsuspend()讓 Dispatcher Manager 暫停執行直到收到表示有 Dispatcher 結束的信號（signal）SIGCHLD 時，

再 fork 子程序執行 Dispatcher。有多少 Dispatcher 結束 Dispatcher Manager 就會 再 fork 多少子程序，讓一台 DVM 維持一定數量的 Dispatcher。

Dispatcher 啟動後的執行流程如下：

1. 讀取設定檔。

2. 建立資料庫連線，用於將模擬工作的資訊更新至資料庫。

3. 以亂數產生兩個 Port Number 並監聽。

4. 連接 Manager。

5. 向 Manager 註冊，將 IP Address 及控制用監聽 Port 告知 Manager。

36

6. 等待 Coordinator 的連線或來自 Manager 或 Coordinator 的控制命令

Dispatcher 完成上述啟動流程後，進入可接收模擬工作的狀態。其中會有兩 個監聽 Port 等待 Coordinator 之連線。一用於建立控制用連線，一用於建立傳送 模擬進度用連線。第 3 步中須以亂數產生 Port Number 是因一台 DVM 中會有多 個 Dispatcher，無法以固定 Port 監聽。

CVM 的啟動腳本執行以下動作：

1. 設定執行 EstiNet 網路模擬器所需要的環境變數。

2. 關閉防火牆 iptables。

3. 執行 Fip Asker，若 Fip Asker 執行成功且正常結束則執行 Coordinator。

前兩個步驟為以 EstiNet 網路模擬器運行模擬時所需要的步驟，需要第 3 步 驟之原因將於後說明。

Coordinator 啟動後的執行流程如下：

1. 初始化變數、產生相關物件，設定環境變數及讀取設定檔。

2. 連接 Manager。Manager 的 IP Address 及監聽 Port 由第一步讀取設定檔時取 得。

3. 等待 Manager 的分配命令。此命令帶有這個 Coordinator 被分配給哪個模擬 工作、由哪個 Dispatcher 管理的資訊。

4. 收到 Manager 命令後從中取得 Dispatcher 的 IP Address、Port 以及此模擬工 作所屬的使用者。

5. 掛載該使用者在 NFS 上用以存放模擬設定檔及結果檔的目錄。

6. 以第四步取得的資訊連接 Dispatcher，此為 Coordinator 及 Dispatcher 間用於 傳送控制命令的連線。

37

7. 向 Dispatcher 註冊，從 Dispatcher 收到另一個監聽 Port Number。

8. 以第七步取得的資訊與 Dispatcher 建立第二條連線，此連線用於傳送模擬進 度，於章節 4.2.7 詳細說明。

Coordinator 完成上述啟動流程後，進入可開始進行模擬的狀態。

在我們的系統架構中，虛擬機器存取 NFS 時，NFS 看到的虛擬機器 IP Address 是 Openstack 架構中的 Floating IP Address，因此在 NFS 的設定上是以 Floating IP Address 進行目錄的分享設定。在前述 Manager 啟動虛擬機器的流程中，開啟虛 擬機器到虛擬機器擁有 Floating IP Address 間會間隔一小段時間，此段時間會隨 著虛擬機器開啟數量的增加而增長。

Coordinator 啟動後會連向 Manager，如果此時 CVM 尚未擁有 Floating IP Address，Manager 以 getpeername()取得連線對方的 IP Address 時無法取得 CVM 的 Floating IP Address，會由於 Floating IP Address 的機制而得到 Controller 的 IP Address。這會造成 CVM 無法掛載 NFS 或對應錯誤使 Manager 無法識別此台 CVM。

有此問題是因為 Coordinator 在 CVM 尚未取得 Floating IP Address 時便連向 Manager。我們希望 Coordinator 是在已有 Floating IP Address 時才連向 Manager，

因為 Floating IP Address 的機制，我們無法從 CVM 中得知自己的 Floating IP Address 再傳送給 Manager。最後我們以 Fip Checker 跟 Fip Asker 解決此問題，

以下說明解決方式。

在 Worker 上執行 Fip Checker，功能為檢查 IP Address 是否為 Floating IP Address。在 CVM 啟動後且 Coordinator 執行前，我們會先執行 Fip Asker 用於確 認虛擬機器已取得 Floating IP Address。

Fip Checker 查詢 Openstack 資料庫中資料表 floating_ips 中欄位 deleted 為 0 的 IP Address，得到目前 Openstack 系統中使用的 Floating IP Address 範圍。Fip Asker 啟動後會連接 Fip Checker，Fip Checker 用 getpeername()取得 Fip Asker 的 IP Address，比對是否為 Floating IP Address，是則回傳 OK 後關閉連線，若不是

38

Floating IP Address 則直接關閉連線。Fip Asker 如果偵測到 Fip Checker 直接關閉 連線則呼叫 sleep()睡眠一秒後再重新連線，Fip Asker 會不斷嘗試連線直到收到 OK 則結束執行。

在 CVM 的啟動腳本中，我們讓 Coordinator 在 Fip Asker 正常結束時啟動，

因此當 Fip Asker 收到 OK 時正常結束即可讓 Coordinator 得以啟動。如此便可達 到讓 Coordinator 在 CVM 擁有 Floating IP Address 的狀況下向 Manager 建立連線。