前言 想要深入了解一個協定的內容，看規格書是最快的，因為剛開始學習 SDN 相關的知識，所以目前正在讀OpenFlow1.0相關的內容，這篇文章會先主要介紹OpenFlow 1.0的架構，以及一些 spec 的整理. 之後也會整理一些 OpenFlow 1.3版本的內容，並且簡單描述跟 OpenFlow 1.0的差異。 為什麼會著重在1.0與1.3兩個版本呢？ 1.0版本與之後的版本不兼容，所以1.0要最先介紹。 1.0以及1.3版本被選為長期支持的穩定版本 1.3為目前的主流版本，多數支持OpenFlow的硬體是支援OpenFlow1.3 參考資料: OpenFlow 協定演進 OpenFlow 1.0 架構 OpenFlow 1.0 spec 架構圖 Flow Table 在 OpenFlow Switch 中存放轉發規則的表稱之為 Flow Table OpenFlow 1.0 中每個Switch只能存放一個Flow Table Flow Table中每個項目被稱為 Flow Entry 在 OpenFlow 1.0 中，每個 Flow Entry 中都包含三個部份 Header Fields Counters Actions Header Fields OpenFlow 1.0 協定中共有12種可供匹配的條件， IP部份只支援IPv4。 分別如下，僅列出條列，細節說明請參考 OpenFlow 1.0 spec L1 Ingress Port: 封包進入 Switch 的Port L2 Ether source: 來源Mac Address Ether dst: 目標Mac Address Ether type: 乙太類型 VLAN ID VLAN priority L3 IPv4 source: 來源IP Address IPv4 dst: 目標IP Address IPv4 proto: IP協定表 IPv4 Tos bits: Type of service L4 TCP/UDP source port TCP/UDP dst port Counters Counter 會針對每張 Flow Table, 每條 Flow entry, 每個 switch 上的 port 以及每個佇列分別紀錄一些相關資訊。

跟著 MIT6.824 的課程進度， 在 Lec3 終於拜讀了這篇經典的論文，GFS 是一個分散式的檔案系統，由 Google 開發。 在2003年時 Google 發表了 The Google File System 這篇論文來分享一些 GFS 開發上的細節， 雖然 Google 沒有開源這個著名的檔案系統， 不過還是可以由 paper 來窺探當初 Google 設計的細節以及整體的架構。 背景 為了滿足當初 Google 日漸增長的資料處理需求， Google開發了 GFS 這套分散式檔案系統。 用分散式的原因: 要處理的檔案大小已經遠遠超過單機可以容納的資料量 跟過往很多分散式系統一樣，GFS 也追求著以下幾點需求: performance 性能 scalability 擴展性 reliability 可靠性 availability 可用性 因為成本以及其他因素的考量之下，Google 並沒有選擇商業用的 server 來製作 GFS 這套系統， 而且採用一般的 普通主機(inexpensive commidity hardware) 來作為叢集成員。因為是普通的主機，所以沒有商業用的 server 穩定， 在設計 GFS 的時候必須一併考慮容錯問題來增加穩定性。 在 Introduction 中也有先簡單介紹了 GFS 的幾個特色 元件失效(component failures) 被認為是常態 GFS 中包含著數以百計或者更多的儲存機器，每一台都有可能在任何一個時間點發生不可預期的錯誤，也有些錯誤是無法從中恢復的。 所以 GFS 需要實現持續的監控，錯誤偵測，容錯跟自動恢復等功能。