好久沒有更新文章了派阱，因為公司在憋大招。上周Big Cloud Fabric 3.0終于登場，博主這才得空蝗砾。先在這里做三個廣告：
1. Big Cloud Fabric 3.0在歷時兩年的開發(fā)之后，終于問世携冤。博主有幸參與了整個產品的設計悼粮，開發(fā)和測試。產品非常扎實曾棕，與openstack和vmware無縫結合扣猫。歡迎大家上手一試
2. 伴隨產品的發(fā)布，我們還發(fā)布了新的定價方式 elastic SDN pricing, 這種定價方式開了兩個先例：首先翘地，網絡設備的軟件和硬件價格全面公開申尤，這還是行業(yè)內的第一次癌幕。第二，彈性收費終于開始進入到了數(shù)據(jù)中心的日常運營昧穿。
3. 博主今年十月份會回國一個月勺远，主要在上海北京兩地轉悠，希望有機會和同行交流时鸵，歡迎大家私信胶逢。
廣告做完，開始正文寥枝。如何在SDN網絡中轉發(fā)數(shù)據(jù)包是一個太大的話題宪塔，博主想借兩到三篇文章聊一聊在一個多租戶數(shù)據(jù)中心里一個數(shù)據(jù)包是如何轉發(fā)的，博主見識有限囊拜，純粹盲人摸象某筐，歡迎大家查漏補缺。
博主首先要科普一下現(xiàn)在被絕大多數(shù)數(shù)據(jù)中心解決方案所采用的多租戶模型冠跷。(1) 一個租戶(tenant)可以創(chuàng)建一個或者多個logical router南誊，(2) 這個租戶還可以創(chuàng)建多個subnet，一個subnet可以接入到某個logical router上蜜托，(3) 一個subnet內的通信往往在2層抄囚，而同一個logical router上兩個subnet之間的通信則需要logical router作為default gateway進行轉發(fā)。(4) 如果兩個subnet接入到不同的logical router橄务，它們之間的通信有兩種方式：a.將兩個logical router以某種方式相連幔托，并在每個logical router上配置相應的路由。b. 借助NAT或者floating IP蜂挪，讓logical router進行IP地址轉換重挑。
目前絕大多數(shù)多租戶數(shù)據(jù)中心解決方案都在向以上的用戶模型靠攏，原因也很顯然：這幾乎是最簡單的網絡模型了棠涮，簡單到任何一個數(shù)據(jù)中心的租戶都不應該對該模型產生絲毫的理解困難谬哀。但是這種簡潔的用戶模型，往往意味著復雜的實現(xiàn)严肪，最大的困難緣于在這個模型中邏輯網絡和物理網絡是完全無關的史煎，也就是說我們要找到一個方法將邏輯網絡中的各個要素映射到物理網絡上，理解了這個映射也就為理解數(shù)據(jù)包轉發(fā)奠定了基礎驳糯。
就博主有限的知識儲備篇梭，目前工業(yè)界從邏輯網絡到物理網絡的映射方案分兩大類：overlay和fabric。博主這里先梳理一下那些構成邏輯網絡的最基本要素酝枢，以及這些要素在兩類方案中是如何映射到物理網絡上的很洋。
Port
一個port是指一個bare metal server或者VM的網卡與網絡相連接的地方，從邏輯上講它只有四個最關鍵的屬性：tenant, network, IP和mac隧枫。租戶其實并不在乎這個port究竟在物理網絡的什么位置喉磁。但所有SDN網絡解決方案卻需要清楚的知道如何把這個邏輯上的port映射到物理物理網絡上：這個port究竟在哪個OVS上谓苟，或者在哪臺物理交換機上？是否有vlan tag协怒？有時候人們還會在port的基礎之上采用一些冗余備份的技術(比如bond), 這樣在邏輯port向物理port映射時涝焙，就需要追加更多的信息。如果大家在玩兒openstack孕暇，會發(fā)現(xiàn)neutron數(shù)據(jù)庫里的port table是最復雜的一張表仑撞，原因就在于它將關于一個port邏輯上和物理上的所有信息都放在了一起。
Subnet
在傳統(tǒng)的數(shù)據(jù)中心里妖滔，subnet和物理網絡是嚴格耦合的：處于同一個rack的port會被劃分到同一個subnet里隧哮。但在多租戶的數(shù)據(jù)中心里，subnet與物理網絡完全解耦合：屬于同一個subnet的兩個port無論出現(xiàn)在物理網絡的任何位置座舍，它們都應該能夠直接在2層通信沮翔。這是多租戶數(shù)據(jù)中心最特別的地方，也是overlay和fabric兩類解決方案的根本區(qū)別所在曲秉。overlay方案采用隧道技術(比如vxlan, GRE)采蚀，fabric則將整個網絡當作一臺distributed switch(比如Big Cloud Fabric)。兩類方案的技術細節(jié)博主會在下篇文章中詳細分析承二。
Router
多個subnet的互聯(lián)互通是需要router作為default gateway的榆鼠。對于overlay方案而言，邏輯上的router和物理上的router是簡單的一對一映射亥鸠，這個router往往需要多個功能：隧道的封裝/解封裝妆够，路由，NAT以及floating IP负蚊。這也就是為什么絕大多數(shù)的overlay方案往往都需要采購一些功能齊全并且?guī)捵銐虻膔outer做為解決方案的一部分神妹。而fabric方案，是把整個網絡當作一個distributed router盖桥，網絡當中的各個switch都可以完成路由灾螃，NAT以及floating IP的功能题翻。兩類方案的技術細節(jié)同樣會在之后的文章中詳細分析揩徊。
以上只是初步涉及了port，subnet和router三個最關鍵的網絡要素在overlay和fabric兩種解決方案中是如何從邏輯概念映射到物理概念的嵌赠。對于那些更復雜的要素塑荒，博主目前只有些零散的觀察和想法，等有系統(tǒng)的觀點之后會陸續(xù)分享姜挺，這里先把它們寫下來以防忘掉：L2 service insertion, L3 service insertion, L4-L7 service insertion, multicast, dynamic routing protocol齿税。
在開始后續(xù)文章之前，博主想先提一句：博主堅定的認為fabric方案是技術上更優(yōu)秀的選擇炊豪，因為它在三個方面完勝overlay：第一凌箕，價格拧篮，請參見博主的第四篇文章。第二牵舱，性能串绩。分布式的硬件轉發(fā)和路由最大程度的避免了overlay方案中由于軟件封裝，解封裝以及路由帶來的性能瓶頸芜壁。博主知道有很多兄弟會在這點上持反對意見礁凡，于是列出幾個事實先：cisco和vmware都推出了在TOR交換機上進行隧道封裝和解封裝的方案，opencontrail全棄用了OVS而開發(fā)了自己的virtual switch來提高性能慧妄，這其中的原因不言自明顷牌。第三，在overlay方案中塞淹，troubleshooting簡直是一場災難窟蓝。首先，overlay網絡和物理網絡是分別管理的窖铡，任何一個網絡故障都需要兩方面的工程獅聯(lián)合調試疗锐。其次，即便聯(lián)合調試费彼，一旦一個數(shù)據(jù)包被封裝好進入物理網絡滑臊，我們便再也無法識別這個數(shù)據(jù)包了，除非在物理網絡上花大價錢進行Deep Packet Inspection箍铲。
