透過90年代網絡架構看可擴展性——云網絡應有特點
本問討論了Calico項目的目的，以及探討了用從上世紀90年代以來發展起來的網絡架構，三層網絡模型，L2與L3層轉發模式，論證了如何基于現有基礎，通過采用新興的“奶牛模式”，來實現云網絡架構的可擴展性和高性能。
最近，有很多關于Calico項目的討論，但是大多數討論只是圍繞著通過把現有互聯網基礎架構應用到數據中心來實現擴展性和簡化網絡架構來進行的。
然而，當審視這個項目時，還是有一部分人會用我稱之為“經典企業鏡頭”的方式來進行，這種方式將會對Calico項目帶來誤解，或者將傳統網絡模型應用到Calico上。其原因在于Calico是從一個非常不同的視角發展而來的，因此用傳統模式來分析它不一定能奏效。
這些誤解集中在三點，下面我會逐點展開。在此之前，我還是要指出，在可擴展式架構方法和經典企業架構方法之間還是有哲學基本概念上的差別。
提起經典企業架構方法，一些特質包括：當企業數據中心建設時，系統將會長期運行而且很好地自包含(self-contained);每個應用都會有各自的需求，因此會有非常客制化的架構設計，或者說架構模板會非常多;必須要在增長的復雜度和架構靈活度之間尋找最佳點;因為需求經常是靜態的，因此，最佳點基本上需要合理的妥協。
隨著可擴展或者云中心架構時代的來臨，我們今天采用的架構知識表明：真實的基礎架構需求更多時候是統一的(同樣的協議，相似的存儲模型，相似的計算模式)，但也是更加動態和更加擴展化的。這就引出了我們常說的“寵物和奶牛模式”。不幸的是，網絡架構還是被當做寵物模式，“被接受”的模式還是試圖將正在使用的，脆弱的，靜態的設計模式一直到新的，可擴展式的，更少客制化的環境。明顯的，向一個脆弱的，靜態網絡模式注入可擴展性必將帶來新的“挑戰”。在Calio項目中，我們將在網絡上采用更多的“奶牛”模式，實際上，從云中其它模塊(可擴展式，非常動態的，單一設計模式)中借鑒驅動 (drivers)，從而整合成擴展性很好，可以用于公有云的網絡模塊。我們相信這是一條通向云、可擴展環境的可選道路，它拋棄了不必要的復雜性，從而帶來了動態和擴展性。
真正為大家所知的是Calico是可擴展架構，因此，比overlay方式更有效。但是更重要的是，對于一般的使用場景非常有效，只對必須的場景增加相應的復雜度。100%的純粹架構功能設計相對簡單，只要你并不在意復雜度帶來的操作上的困難。目前的辦法是為不同子網采用不同的架構，在盡量不碰到麻煩的情況下帶來最佳的效果。我們相信Calico項目正式朝著這個方向努力的。
關于Calico，最主要的三點建議是：
L3 vs. L2 and overlays vs. native
最近幾個項目，我們聽到很多關于“Calico為了可擴展性回歸了L2”，或者“Calico使用microsegmentation模式(一種從L3路由架構看起來更像L2層的模式) ”。這兩種說法，混淆了兩個概念：
- 網絡上轉發量子(quata)是什么?或者說轉發系統基于底層包的哪個比特?
- 網(fabric)中是什么把轉發節點整合成一個大網絡
讓我們分開討論。
網絡中什么是轉發量子?
今天在可擴展或者云架構中，大部分應用產生的數據包都是IP包。如果發現非IP包(或者IP相關，像 ICMP)，那我就可能要拍磚了。。。IPX, NetBEUI, EtherTalk, Banyan Vines, ATM, and DECNet 等系統已經過時很久了 (我猜DECNet 有可能在一些暗黑角落仍然會生存一段時間). 當人們提到“我需要L2網絡”時候，更多時候意味著“我需要一個私有IP網絡”或者“我不想為了這個應用改變從上世紀90年代就使用的架構”。(好吧， 上世紀90年代令人窒息的， 三層結婚蛋糕似的網絡回歸。)
因為IP是我們目前使用網絡的原子(quata)，因此使用它作為轉發模式才有意義。IETF選擇L2OL3打包模式(PWE3,L2VPN等等)，其原因就是：L3是現實中的標準，為什么不使用現實標準，在此之上打包呢(傳統的L2)。但是他們忘記了，這種想問題的方法會走向死胡同，就如同將基于Ethernet的IP包包裝在VXLAN上似的，有意義嗎?效率可以接受嗎?容易排錯嗎?如果我們真的認為Ethernet是正確的轉發原子(quata)，我們直接建一個L2網絡不可以嗎?---哦，看起來我們曾經嘗試過，但是并不成功，對嗎?
使用IP作為轉發原子(quata)帶來一個問題，L2層分段的概念會丟失很多信息。在一個以太網絡，兩個節點之間要么在一個段內是相連的，要么是不相連的。如果是相連的，他們之間可以轉發，如果不相連則不能轉發。 IP并沒有一個段的概念(甚至是子段，將L2層段概念對應于IP地址段)。而在一個純粹的IP網段，路由器轉發“longest prefix match(最長前綴匹配)” 一般來說IP地址可以被一組比特前綴分組， (例如： 192.0.2.0/24, 198.51.100.16/30, and 2001:db8:://128)，這些分組跟底層物理拓撲沒有任何關系，或者，可以說所有符合以上分組特征的地址從路由器角度來看共享一個路由 。因此，如果一個路由器有一條路由 192.0.2.0/24 是通過 interface 1, 而192.0.2.26/32 通過 interface 2, 那么所有的通過192.0.2.0/24的流量都會通過 interface 1, 除非目的地址是 192.0.2.26, 會通過 interface 2. 這種方式允許一些在Ethernet無效的方式也可以被采用，使得“microsegmentation”的概念在IP網絡中真正有意義。
Calico方法有一些前提。所有(或者幾乎所有)流量都是可以被轉發的IP，IP地址不是寫死的，而是采用某種自發現服務(比如，DNS)。這兩種模式在業界至少有15年歷史，也許我們可以讓這種上世紀90年代的網絡技術用的更久。基于這種模式，Calico團隊相信我們并不需要把IP流量打包進L2層，就如同將IP流量打包進其他網絡層(例如VXLAN，NVGRE等等)，最后把他們又打包成另外一個IP包，這是完全沒有必要的。我們和大家在談論Calico項目，或者在大會，交流會上期望表達這一觀點，因此，我們不希望也不會使用打包的方式作為Calico項目主要的傳輸機制。
#p#
網內如何連接節點(網：internal fabri)
一些不太理解路由網絡工作原理的人可能會說：“Calico回歸Ethernet是因為可擴展的原因”。這和Calico網站討論物理、網絡拓撲的文檔有關，這些可以從 here 和 here獲得。
在互聯網架構編年史中，你會發現如何讓背板操作和路由器更好的結合是一個長期的“宗教式的”戰爭。某些人使用switching方式(首先是 ATM，然后是Ethernet或者MPLS)，其他人使用routing(比如PPP over SDH)，其原因并不是某些人更聰明些，而是不同的操作有不同的需求和限制。IP網絡的優美之處在于幾乎有無窮多的選擇可以跟路由器相連，可以直連其它路由器(edge-router，或者core-router概念)，從數據中心角度來看更像一個L3網絡;你可以使用switching，例如 Ethernet或者MPLS，前者最有代表的是L2層，后者則是以大型服務提供商為代表。實際上，你甚至可以采用 carrier pigeons (如果某個人可以為Calico實現IP over Avian Carrier，Calico團隊會有大獎給你)。
使用IP轉發設計，然后將計算節點、服務器、從節點都連接到路由器上，我們允許基礎架構來決定這些服務器如何相連，并把這一決定對應用層隔離，或者簡單說，我們可以將架構和應用解耦。
與做任何工程設計類似，要在很多因素中間做折中，基礎架構設計必須要權衡這些因素，最終決定怎樣在Calico路由器間互連。 (今天很多大規模部署Calico的客戶使用Trident II based ToRs 作為L3互聯的方式。不帶路由聚合會產生128K IPV4的負載。對于沒有很多路由聚合的長前綴匹配場景，除了仍然具有IP的匹配性外，仍然具有高擴展性)。
我們在網站文檔部分發布了一些關于不同互聯方式的想法，但是因為存在L2和L3不同連接Calico節點的方式，不同的選擇將會影響到路由的擴展性，但是這并不意味著Calico將會“回歸Ethernet”。任何互聯Calico節點的架構， 最終都會轉發IP包。
“私有”網問題
另外一個我們經常聽到的問題是：從上世紀90年代的網絡并未消失，一些關鍵應用寫死了IP地址;或者某些公司之間收購，大家都使用10.1.1.1作為關鍵應用的IP地址，而且無法更改。我們承認這個時間并不太平，這類事情很有可能發生，那么Calico怎么處理這類問題呢?讓咱們首先看看其他人怎么做?
全部打包(Encapsulate everything)
網絡供應商最喜歡打包模式……，網絡操作人員卻恰恰相反……然而即使 overlay操作，或者打包網絡很困難，對這類問題的回答基本都是“全部打包”。如果你假設大部分流量并不是基于IPV4節點的，那么這個方案影響不大。但是如果不是這樣的話，你的基礎架構可能就很大的問題(叫做1:1 NAT和DNS ALG，NAT鏈，和更多的痛點)。如果大部分流量負載工作機制很好，為什么非要為少部分“不法之徒(miscreants)”而去改變呢?
NAT更簡單?
另外一個問題來自NAT。如果我對全部負載都打包，我需要在服務末端提供NAT功能，但是NAT有一些問題：一個就是 NAT太面向狀態。所有NAT實現中，必須為每一個鏈接或者流經NAT設備的流維護一個狀態表。如果設備宕機，所有鏈接就會斷掉。如果無法接受這種情況，就需要在多個NAT節點之間實時復制狀態。在一個大型網絡中，這回成為一個嚴重的問題。另外，如果使用NAT，有可能需要欺騙DNS(比如在NAT兩端要對同一個域名解析出不同的IP地址)。這就需要維護一個多向映射表。要想對這種環境進行排錯，就需要理解在源端和目的端應該開到什么，然后確認確實看到這些內容。這也是為什么在一個NAT/DNS-ALG云端部署一個應用第一次(有可能第二次，第三次)一般都不會成功的原因，NAT一點都不簡單。
一個工具 (464-XLAT)
因此在Calico中，我們采用了不同的方式。我們采用IETF-464-XLAT標準，IPV6標準信息傳遞機制。是的，也就是意味著底層必須要是IPv6，但是近十年之內的設備都支持IPv6。另外，因為官方宣布IPv4地址近乎衰竭，真的需要在可擴展性云中激活IPv6功能(北美ARIN最近就拒絕了一次IPv4的申請，因為沒有可用的IPv4地址了)。
現在深呼一口氣，我們一起看看使用IPv6能夠做什么。IPv6地址空間比起IPv4大很多，使得我們可以把整個IPv4地址空間(大約2百萬地址)映射到預留的IPv6空間。在Calico中，我們給每一個實例一塊重復的多租戶空間，每個都是2百萬地址。每個實例有一個不同的IPV6前綴，來假裝IPv4的源和目的地址。然后將IPv4轉換成IPv6包，轉發出去，在接收端，過程剛好反過來，應用感知不到這個IPv6與IPv4地址的映射。
因為可以把所有IPv4地址都轉換成唯一的IPv6地址，因此我們可以做一些算法上的優化，而不是只記錄每個包的狀態。重復一遍，如果愿意，Calico可以無狀態的支持所有重復的IPv4，映射工作可能失敗，當包彈回來，流量可以繼續轉發。無狀態，無狀態復制高可用，只是靜態的地址傳送。另外一個好處是，如果一旦知道“實例”如何包裝成IPv6地址，不用查看NAT狀態表，不用查看隧道映射表，只看IPv6地址，就可以查看任何數據包，精確告訴此包的IPv4源地址和目的地址，屬于哪個實例。
因此，當(因為)Calico并不把重疊的地址看成固有的負載，因此更容易操作，維護，相對于“全部打包”模式和NAT模式，更容易排錯。
接下來可能會問：“如果需要跟一個不在實例地址空間的服務通訊，怎么辦?”，那么解答如下。
如果此服務被網(fabric)提供，強烈建議這些服務都采用IPv6。然后，可以使用DC-SIIT模式，這樣IPv4節點并不知道在跟IPv6節點通訊。如果不可行，那么有狀態的464-XLAT可以被用于從一個重疊的IPv4實例訪問外部IPV4目的地址。
將策略和連接性解耦
最后一個迷惑也來自于90年代的，在那個網絡暗黑年代，唯一一個給大型網絡部署策略的方法就是通過防火墻，這也是三層模式的緣由。每一層(前端，應用，數據庫)通過物理防火墻端口互相隔離，同一層內所有節點都連接到同一個防火墻端口。這使得監控和管理變的容易。至少，當我們討論物理節點是很容易。更進一步，這種模型中，把策略和連通性合并了。連通性通過策略控制點提供。然而，本身他們都是不同的概念。一個是“我怎么能到那里?”，另外一個是“我能去哪兒嗎?本來不可以被合并的，然而不行的是，在這種模型中，他們被合并了。
很多人仍然認為他們的想法是業界最佳實踐，有時被稱為“隔離”或者“服務接入”。然而我們并不在討論物理設備。。。。
#p#
集中化 SPOFs ( firewalls) 更容易些嗎?
如果我們吧這種模式引入到可擴展年代，我們會看到很有趣的模式。如果我們使用三層模式，那么我們會有很多應用服務器分布在數據中心的所有容器中，可以作為可移動負載飄移。我們也會有很多web前端具有相似的配置。實際上，某些 web前端可能跟一些應用在同一個物理節點上。然而，我們也有虛擬防火墻容器，很可能，在大網里(或者其他一些節點上)。那么，一個應用服務如何跟web 前端通訊呢?必須經歷 IP→Ethernet→VXLAN→IP打包過程，最后通過數據中心網絡發送到防火墻，在這里逐層解包，最終剩下最里面的IP包信息。防火墻檢查此包，決定是否允許發送，然后重新打包，發送到web前端服務器，在這里數據包被再次解包，最內部IP信息被web服務器收取。看起來效率很低。。
下一個問題是“防火墻”。是的，這是一個單節點提供的服務，因此，是一個單點故障。可以有多個防火墻，但是每個防火墻保持同步。防火墻高可用是一個有趣的問題，會帶來很多麻煩。。。。
因此，這樣一個大規模可擴展的，彈性的三層應用模式，所有內部流量負載都記過一個單點故障或者脆弱HA能力的防火墻。我覺得沒必要再說下去了，而且在如今大型數據中心中也會發現這種架構。
三層架構可能會慢慢被拋棄。當應用之間各自獨立，不需要互相合作(互相只對應用本身而不是對方的數據感興趣)。今天應用棧更面向互連(更多東西向而不是南北向)。這種模式下，三層模式會對開發帶來災難。也許到了拋棄這種模式的時候。
Scale out應該是一種橫向的，平面化的模式
好了，現在我們清楚了基于單點故障的三層模式的問題，這也是Calico產生的原因。三層結構得以推廣很重要一點是因為把安全分布到多個服務點會很痛苦。對于一小部分公司而言，自動化網絡配置會同構郵件發送到維護人員。這樣，防火墻提供商就可以獨立出來，提供一個獨自的地方配置安全策略。
從那開始，可擴展式環境出現了很多自動化的配置的方式。如果沒有的話，我們也就不會有這個討論，因為整個云模式就會不穩定。我們需要一種自動部署 “奶牛”的方式，現在我們已經有了(比如Ansible,Puppet，Chef，etcd/confd，以及其他)。通過他們可以一次性將配置推送到上千臺服務點。在Calico，我們會使用每臺服務器上的代理對路由和策略編程，使用BGP和etcd將數據推送到所有其他Calico節點。這種機制保證 Calico策略的同步。
我們在Calico網絡第一跳和最后一跳安裝和管理策略，相對于中心化的防火墻模式這種模式引起很多關于安全的爭論。
我們可以簡化這個規則為：每個Calico節點只跟連接到這個節點上的特殊服務點合作。但是我們沒有SPOF問題，因為這個規則只對本節點起作用。一個節點失效只影響它容納的服務點。
最后，我們解耦可連接性和策略。我們使用BGP來分發網絡拓撲，告訴每個節點如何獲得每個服務點以便兩個服務點進行通訊。我們使用策略來決定這兩個節點是否應該通訊，如果需要，怎么做?如果策略改變了，兩個以前不需要通訊的服務點現在需要通訊，我們需要做的只是更新策略，而鏈接信息不需要改變。如果以后，他們需要拒絕通訊，可以再次更新策略，而連接性仍然不需要修改。應用變化和適應新世界，這種模式帶來的靈活性是附帶的福利。
關于性能的建議
我們也經常聽說linux世界中轉發性能問題，我們也需要仔細想想。假設你有一個服務器，連接到10GE網絡上，當然希望獲得線速(或者至少接近線速)，結果會是什么樣呢?如你所愿。那些采用linux系統，只能獲得1-2Gbps的吞吐量的日子已經成為過去了(如果不是的話，為什么人們現在會把10GE網卡作為標配呢?)。實際上，最近我聽一個朋友說他們在兩個用100GE連接的節點間獲得了97Gbps的帶寬。知道嗎?所有這些流量都是直接經過linux核心發送的。可以占滿10GE網口的服務器一般都是運行在Linux Kernel級別上發送數據。有些同事卡在一個方向上linux性能不好，而另外一個方向上卻很好，我感到很困惑，因為在一般情況下，任何從linux服務器出來的數據包都走的與Calico一樣的轉發路徑。人們在服務器內部愿意買多塊10GE卡，希望達到25GE，40GE和50GE的帶寬，不僅僅是人們愿意花錢，更多是因為這樣做確實可以達到目標。
最后的想法 (恭喜，你讀完了很長的博客)
我們已經走完了21世紀第二個十年的一半，應該是時候停下來用上世紀90年代企業架構視角來評估網絡，讓90后安靜和平的埋葬他們的網絡，并且意識到老一代的模式只可能讓我們曾經拼命脫離的痛苦長期存在下去。
