本研究擬結合本年度所實現的 Novel K-U bridge schemes for HA middleware 為基本架 構，針對 Kernel space 中的 routing table 提出一個共同介面，讓各個不同的 routing protocol 可以透過此介面來進行 routing table 的管理以及備援，本年度將先選擇 OSPF routing protocol 設計，以達到高可靠度之目的來進行研究討論。以下分別說明 Novel K-U bridge schemes for
HA middleware 及 HA OSPF Routing 的架構設計：
3.3.1 Novel K-U bridge schemes for HA middleware 的架構設計與效能分析
本年度針對 System Model、Group Communication、Messaging mechanism 等核心技 術 進 行 更 深 入 的 探 討 ， 並 提 出 Novel K-U (Kernal-User) bridge schemes for HA middleware 的架構設計以實現在圖九中 HA Middleware Enhanced Functionality 的 Kernal-User Bridge Service。相關設計與效能分析結果分別說明如下：
A. System Model 之設計
Middleware 的管理與運作，必須依據整個系統的配置與組態。System Model 在設計上，必須包含以下各部分：
1. 系統配置與組態的描述：包括了所有被管理的軟硬體元件與資源(resource)之 描述，含名稱/ID、編號、屬性等；服務元件、服務單元的群組關係；備援 (redundancy)保護關係，以及 active/standby 的決定與委派方式；各元件及服務 間的依存關係(dependency)等。
2. 組態的動態調整的支援：即時得知系統配置組態的動態變化，如軟硬元件的 新增與消減等。尤其是須考量及支援硬體元件或卡板的 hot swap 熱插拔能力。
3. Active/Standby 角色管理：依所設定之 active/standby 的決定與委派方式，以 及系統配置組態的動態變化，進行 Active/Standby 角色之調整與管理。
4. 服務元件與服務單元的群組關係及依存關係之管理：可將數個服務元件群組 成一個服務單元，視為單一個服務單位來進行管控，若某服務單元中的一服 務元件停止運作，則同屬該服務單元的其他服務元件也將自動被停止。另外，
也要支援各服務間的 dependency 關係，例如在 MPLS 的應用中， 流量工程 (traffic engineering) 功能需使用路由(routing)功能所產出的路徑表，因此當 active node 中的路由功能發生故障時，該 node 的 MPLS 流量工程功能也無法 正常運作，因此應該與路由功能一起切換至另一個 standby node 來執行。
B. Group Communication、Messaging mechanism 之架構設計與效能分析
由於 HA Middleware 的各服務模組，必須依賴 IPC(Inter-Process Communication) 機制來進行相關的資料傳輸，若能有一支援 process-group multicast 的 IPC 機制，
將能使整個 middleware 的設計更加的簡易、有效。因此，設計及建置一個分散式 計算架構(distributed computing framework)，提供一有效率的群組通訊及訊息傳輸 (group communication & group messaging) 機制，將是設計整個 HA Middleware 的 重要關鍵。這個機制的主要項目如下：
1. 傳輸(delivery)服務機制：將設計一 group communication 協定，以提供可靠的 多點傳送(reliable multicast)能力，使其具順序性、整體性(integrity & atomicity) 與一致性，並達成高效率且正確的大量資料傳輸性能，以支援 process-group 及 node-group 的傳輸需求。利用本機制，將可直接支援 HA Middleware 的 event service 及 message service 等服務，也支援 checkpoint service 進行對 cluster nodes 的資料同步傳輸(data synchronization)，並對 availability management 等 middleware 服務模組進行相關資料傳輸，提供一個高階的通訊機制。
2. Membership & Configuration 管理：為進行 group 群組通訊，通常需要掌握對 group 成員及配置(membership & configuration)的最新資訊與管理，以隨時得 知最新的群組成員加入或離開等狀態。透過此功能，將可直接支援 HA Middleware 的 cluster membership service 及 availability management 等服務。
C. Linux-based Kernel/User Spaces 橋接(bridging)的架構設計
開放架構採用的 Linux 作業系統內部區分為 user space 與 kernel space，前者主 要為一般的應用軟體模式，其開發除錯較易，工具與環境之支援也較充足，後者 主要為驅動軟體、系統程式的運用模式，執行效率較佳，但於開發除錯上也較困 難。目前 HA Middleware Genric Functionality 的實現上普遍都在 user space 進行，
但不少寬頻設備基於效能與硬體控管的考量，常會將功能實現在 kernel space。為 了讓 kernel space 各模組能有效的利用 HA middleware Generic Functionality 來滿足 系統可靠度的要求，如圖十六的一個有效率的 Kernel–User Bridge 是不可或缺的。
本年度依據上述三項架構設計要點，所設計出的 Novel K-U bridge schemes for HA middleware 之運作架構如圖十七所示，主要包含兩大部分：
¾ User-side Relay：包含一 "User Relay Manager" 程式。
¾ Kernel-side Relay ： 包 含 了 "Kernel Relay Manager" 及 "Kernel Interface Module" 等二項模組 module。
其中，"user relay manager" 是以 polling 的方法去向"kernel relay manager" 詢問以取 得所傳送之資料，其計有 3 種可行的設計方式：
¾ Continue Polling
¾ Pause xx msuc per polling
¾ Pause 10 msec per xxK polling times
本年度已實作完成圖十七所示的 Novel K-U bridge schemes for HA middleware 設計，並採用 HA Middleware Generic Fuctionality 中的 "Checkpoint" service API function 服務功能來架構系統測試程式 Benchmark，其運作如圖十八所示。
Protocols / Applications
Protocols / ApplicationsKernel HA API HA Middleware
Kernel -side Relay HA API
Kernel Space Protocols / modules
Kernel Space Protocols / modules
User Space
Kernel Space
User-side Relay
U-K Bridge
圖十六、Kernel–User Bridge 機制示意圖
Kernel Modules with High Availability
HA Middleware
return & output data to called functioninvoking
return &
output data
invoking
Kernel Space User Space
HA API Interface
HA API Interface
Calling Data Calling Data
Return Data
Kernel-side Relay
User-side Relay
Queue圖十七、Novel K-U bridge schemes for HA middleware 之運作架構
利用 checkpoint 功能將資料以 reliable 傳遞至各 Cluster Nodes，以量測其所花費 之時間。共計針對不同的 nodes 數及"user relay manager" 方式之組合，去量測其資料 傳輸速度，並計算出 Throughput 資料流量(Mbytes Per Sec)，以觀察、分析其效能；
並針對 Linux-based 之 User-Space 及 Kernel-Space 之應用分別設計 Benchmark 測試程 式，以瞭解在 Novel K-U bridge schemes for HA middleware 之運作效能，如圖十九所 示。
User Space Benchmarking
User Space
Kernel Space
Kernel Space User Space
Kernel Space Benchmarking
Benchmarking program,
ServiceCKPT CKPT
Service ServiceCKPT Group
Communication
圖十八、Checkpoint-Based Benchmarking 測試示意圖
圖十九、Kernel-Space vs. User-Space Benchmarking
圖二十、Novel K-U bridge schemes for HA middleware 效能測試－Throughput for 2 Nodes
在以下硬體環境量測所得的效能結果，如圖二十所示。
¾ PC ： 2 nodes
¾ CPU ： x86 platform, Celeron 2.6G
¾ Network ： 100Mbits/s , private LAN
分析效能結論：在 User-Space 之效能頗佳，資料傳送速度可近於 wire-speed；在 Kernel-Space 應用測試中，以 Continue Polling 及 Pause 10ms per 10k polling 等二種 方式的 Kernel-User Bridge 效能較佳；Kernel-Space 之效能較 User-Space 略為降低，
約為 User-Space 之 60%左右。所以本 Novel K-U bridge schemes for HA middleware 的架構設計之效能，將可符合 Carrier-Grade 之需求。
3.3.2 Fast recovery mechanisms of routing paths for HA middleware 的架構設計與效能分析
當網路中 Router 中斷服務，一般做法是利用 Redundant Router 來接手封包轉送之工作。
若是 OSPF 則利用 Graceful Restart 方式避免路由資訊重新計算，如圖二十一所示以 OSPF 為例，圖中所有路由節點皆支援 Graceful Restart，因此當 Router 3 無法繼續服務，則 Router 2 的鄰居路由節點將進入 Helper 模式進行 Graceful Restart，但是此方式所造成服務中斷時 間往往太長，而無法達到寬頻電信等級之標準。
pause 10ms per 10k polling pause 10ms per 1k polling pause 1-10ms per polling pause 20ms per polling Kernel Space Benchmarking
User Space Benchmarking
Route
在網路中加入了另外一個 HA-OSPF router，如圖二十三所示，在此 router 中包含了 2 個 router 模組，分別為 active 與 standby，在同一時間之內只會有一個 router 模組進行封包 轉送服務，並且與其他 router 進行控制訊息的交換
我們將利用 HA Middleware Generic Functionality 所提供之 AMF 來提供 Heartbeat 服 務，如圖二十四所示，我們將利用 2N 方式進行備援，我們定義了 OSPF_SG1 這一個 Service Group 以及 OSPF_PG1 這一個 Protection Group，OpenAIS 會根據此二定義來決定哪一個模 組是 Active 或是 Standby 來進行備援。
Active 會定期送 heartbeat 給 standby，standby 可以根據 heartbeat 得知 active 現在仍在 服務，當 standby 沒有接收到 heartbeat 之後便知道 active 中斷服務，此時 standby 可以接手 原本 active 的封包轉送工作，且此時 standby 的狀態也會變成 active。
本計畫利用工研院所設計定義的 API，其中 iclhaInit()用來初始化 AMF 以及 Checkpoint 相關設定，iclhaGetState()可以在程式中快速取得程式的身分，如 active 或是 standby，以方 便設計相關程式流程，iclhaWrite()以及 iclhaRead()是用來對 checkpoint 進行寫入以及讀取的 動作，這一些 API 可以幫助我們在開發的時候更容易進行。
HA-OSPF router
OSPF daemon
HA middleware (OpenAIS) Linux Operating
System Moduler 1:
OSPF daemon
HA middleware (OpenAIS) Linux Operating
System Moduler 2:
OSPF Router A OSPF Router B
OSPF Router C
OSPF Router D
圖二十三： HA-OSPF router system design
圖二十四: HA-OSPF router with SAF 2N Model
圖二十五是 Active 與 Standby 執行時的 pseudo code，當 router 模組的身分為 Standby 的時候，會從 checkpoint 讀出 routing table，再將 routing table 備援寫入系統中，若 router 模組是 Active 的時候分為 2 種情形，若先前狀態是 standby，則代表是剛接手工作，所以必 須先執行 ospf 路由程式，並且立刻發送 Hello 以及 Link State Request 訊息給 neighbor router，
否則就定期將 routing table 寫入 checkpoint 供 standby 進行備援動作。
void callback() {
iclhaGetState();
if(haState is Active) {
if(previous haState is Standby) { //takeover occurred start the OSPF routring procedure;
send the OSPF Hello and Link State Request message;
}
else {
write the routing information to the checkpoint;
} }
if(haState is Standby) {
read the routing information from the checkpoint;
update the information to its routing table }
}
圖二十五: Callback function pseudo code
如圖二十六所示，在換手的過程中網路拓蹼可能會有所變更，因為 standby 在接手之前 所得到的路由資訊並不包含拓蹼改變後的資訊，因此若不處理，資料封包將可能無法被轉 送至正確的網路區段，因此我們提出了 OSPF 狀態快速轉換機制用來加快更新後的路由資 訊。
圖二十六：Topology changed between checkpoints
如圖二十七為 OSPF 狀態轉換圖，我們將加快狀態轉換的流程，讓 router 可以快速進 入 Full 狀態，作法如下：
1. 當 router 模組接手工作之後，一開始狀態為 Down，router 將立刻送出 Hello 訊息並將狀態設 定成為 Init
2. 我們將略過 ExStart 狀態讓 router 直接進入 Exchange 狀態，準備交換 link state 封包
3. 在 Exchange 狀態 router 將會送出 link state request 訊息，向其每一個 neighbor router 要求最新 的路由資訊，並且進入 Full 狀態，在此狀態下，再根據先前取得的 link state 資訊求得最新的 routing information，此時 router 便有最新的網路拓蹼的路由資訊
圖二十七：The state diagram of the proposed mechanism
如圖十五所示，當 active 在轉送封包的時候，active 也會將目前 active 上的路由資訊透 過 K-U Bridge 介面取得再利用 HA Middleware Generic Functionality 的 checkpoint 傳送給 standby，以確保 standby 會收到來自於 active 最新的路由資訊。當 standby 接收到此路由資 訊，standby 再透過 K-U Bridge 將此路由資訊更新至 kernel space 的 routing table，因此 standby 可以將自己本身的路由資訊更新成為與 active 一樣，故 standby 上將擁有與 active 一樣之路 由表資訊，當 standby 接手封包轉送之工作，可以知道如何將封包轉送至正確的網路位置。
而在實際測試系統架構方面如圖二十八所示，其中 R1、R4、以及 R5 為一般的路由器，
而 R2 以及 R3 為我們所設計有包含 HA Middleware Generic Functionality 以及設計有 K-U Bridge 的路由器，支援 checkpoint 與 AMF 服務，R2 與 R3 之間有一連結，所有 AMF 以及 checkpoint 資料皆由此介面傳遞。
在此圖中，R2 與 R3 連接二個網路，負責將封包轉交至正確的網路位置，且 R2 與 R3
在此圖中，R2 與 R3 連接二個網路，負責將封包轉交至正確的網路位置，且 R2 與 R3