歡迎來到Tungsten Fabric用戶案例系列文章，一起發現TF的更多應用場景。“揭祕LOL”系列的主人公是Tungsten Fabric用戶Riot Games遊戲公司，作爲LOL《英雄聯盟》的開發和運營商，Riot Games面臨全球範圍複雜部署的挑戰，讓我們一起揭祕LOL背後的“英雄們”，看他們是如何運行在線服務的吧。
作者：Doug Lardo和David Press（文章來源：Riot Games）譯者：TF中文社區
本文作者David Press和Doug Lardo是Riot的兩名工程師，他們致力於改善數據中心網絡，以支撐Riot的在線服務。本文是關於該主題的系列文章第三部分，將討論我們的SDN（軟件定義網絡）方法，如何將SDN與Docker集成，以及該組合爲我們解鎖的新基礎架構範例。如果你對SDN如何轉換基礎架構，如何使開發人員能夠通過API獲得並保護網絡資源，或者如何擺脫購買越來越大的專用網絡設備感到好奇，請參閱本文。
在第一篇文章中，Jonathan提到了爲支持《英雄聯盟》的新功能，在推出服務時面臨的一些網絡挑戰。事實證明，（網絡上面的部署）這並不像在服務器上安裝代碼並按回車那樣容易。
新功能需要網絡基礎架構的所提供的功能，包括：
- 連接性：對玩家和內部服務的低延遲和高吞吐量訪問
- 安全性：防止未經授權的訪問和DoS攻擊，並在需要時進行通信，以最大程度地減少發生漏洞時的影響
- 數據包服務：負載均衡，網絡地址轉換（NAT），虛擬專用網（VPN），連接性和組播轉發
傳統上，設置這些網絡服務，一直是超級專業的網絡工程師的工作領域，他們登錄單個網絡設備，並輸入那些我敢保證就是“純巫術”一樣的命令。配置這些內容通常需要對網絡、相關配置，以及出現問題時的響應有深入的瞭解。
但是，因爲不斷地擴建，數據中心之間的差異越來越大，使得情況變得更加複雜。對於兩個不同數據中心的兩個網絡工程師來說，相同的目標可能看起來完全不同的動作和任務。
所有這些都意味着，數據中心網絡基礎架構的更改，通常都會成爲推出新服務的瓶頸。幸運的是，在Riot，任何阻礙向玩家提供新奇特效的因素都會立即受到嚴重關注。rCluster平臺旨在解決這一瓶頸，在以下各節中，我們將深入研究它的關鍵組件：overlay網絡概念，OpenContrail（編者按：已更名爲Tungsten Fabric，下文中出現OpenContrail之處，均以Tungsten Fabric代替）實施，以及與Docker的集成。在本系列的下一篇文章中，我們將介紹一些細節，例如安全性、負載均衡和系統擴展。
SDN和overlay網絡
SDN變成了一個流行語，對不同的人意味着不同的事情：對於某些人來說，這意味着網絡配置應由軟件定義；但是在Riot，這意味着我們的網絡功能應通過一致的API進行編程。
通過使網絡可編程化，我們可以編寫自動化程序，從而極大地擴展了我們的能力，能夠快速將更改部署到網絡。我們只需要運行一個命令，而不必將其封裝到衆多的設備中進行更改（附註：封裝的概念是，將網絡的功能要求變成不同的的網絡設備命令）。我們將全球網絡變更的時間從天變成了分鐘級，並且這樣，還能在空閒時間裏去做其它很酷的事情。
網絡設備的可編程已經有一段時間了，不過在整個行業中，對這些設備進行編程的接口在不斷變化和發展，並且不存在適用於所有類型設備和所有供應商的統一標準。因此，編寫能夠與多個供應商的每個接口通信的強大自動化程序，是一項非常艱鉅的任務。我們也知道，在硬件上方擁有一致的API作爲抽象層，是Riot有效擴展其網絡配置管理和操作的關鍵要求。於是，我們轉向了overlay網絡。（編者按：特意在overlay前面解釋網絡設備可編程的原因是，網絡爲應用服務，因爲應用的不斷變化，因此網絡的配置也需要不斷變化，儘管網絡設備具有可編程性，可以實現業務和網絡的編排，但是也面臨挑戰，供應商不同，配置不同，API不同，很難統一。）
毫無疑問，overlay網絡位於現有網絡之上。在overlay網絡內部的應用程序並不知道網絡的存在，因爲它在感覺上完全類似於物理網絡。如果你熟悉虛擬機，則相同的“物理內部的虛擬”範例也適用於虛擬網絡。一個物理網絡可以承載許多虛擬網絡。在一個虛擬機中，應用程序認爲它們擁有一整臺物理機，但實際上，它們僅擁有一小部分虛擬機。Overlay網絡也是類似的概念，一種內部創建的有虛擬網絡的物理基礎架構（稱爲underlay網絡）。
這種方法使我們能夠將Riot工程師無需擔心的各種物理網絡細節隱藏起來。工程師不再需要問“有多少端口”，“我們有哪些供應商”，“安全策略應該放在那裏”這樣的問題。相反，我們可以提供一個一致的API程序，讓工程師專注在自己想做的事情上。
在Riot運營的每個數據中心中使用相同的API，使得我們編寫的自動化可以在任何地方、任何時間有效工作，無論是使用在過去的第一個數據中心，還是更現代化的設計。此外，我們還可以尋找其他雲服務商，例如Amazon、Rackspace、Google Compute等，並且我們的API仍然可以使用。
這樣設計，我們的底層物理硬件可能是Cisco、Juniper、Arista、Dell、D-Link、白盒、灰盒、一堆有10GE端口的Linux盒子，這都沒關係。但是Underlay網絡必須使用特定的方法來構建，例如自動配置模板（更多信息，參見下一篇系列文章），但這使我們能夠將物理構建和配置，與應用程序所需的服務配置解耦。當我們將underlay和軟件服務接口，保持underlay網絡的穩定還有更多好處，我們可以讓underlay可以專注於提供高可用性的數據包轉發，並允許我們升級物理網絡，而不必擔心會破壞以前與物理基礎架構緊密耦合的應用程序。它還簡化了我們的運營，允許服務在任何一個數據中心遷入和移出，並消除了供應商鎖定的風險。
總之，我們認爲overlay網絡非常棒。
Tungsten Fabric
在我們剛開始評估SDN時，研究了整個行業的各種SDN項目。有些通過中央控制器配置物理網絡，還有一些則提供了抽象層，將API調用轉換爲特定於某個供應商的指令。有些解決方案需要新的硬件，還有一些則可以在現有基礎架構上運行。有些是由大型公司開發的，還有一些是開源項目，或者由初創公司提供。
簡而言之，我們花了很多時間來做功課，這並不是一個容易的決定。我們需要滿足的要求包括：
- 在我們的數據中心（無論老的還是新的）、裸機和雲中提供功能性
- 是開源的項目，但是也不要在一夜之間消失
- 能夠對我們的部署征程提供專業輔助
最終，我們的視線落在了Juniper Networks的Tungsten Fabric項目上。Tungsten Fabric從一開始就被設計爲開源的、與供應商無關的解決方案，可與任何一個現有網絡一起使用。其核心是BGP和MPLS——兩者都是已被證明可以規模化擴展到整個Internet的協議。Juniper Networks肯定不會很快消失，並且在我們設計和安裝第一套集羣時，提供了很多幫助。（點擊“TF架構系列”文章，查看這個控制器的全部細節）
Tungsten Fabric包含三個主要組件：集中控制器（“大腦”），vRouter（虛擬路由器）和外部網關。每個組件都是高可用性集羣的成員，因此任何單個設備故障都不會破壞整個系統。與控制器進行API交互，會立即觸發其將所有必要的更改,並推送到vRouter和網關，然後由它們物理轉發網絡上的流量。
Overlay網絡由vRouter之間的一系列隧道組成，可供選擇的協議包括GRE w / MPLS、UDP w / MPLS或VXLAN。當一個容器想要與另一個容器通信時，vRouter首先在控制器先前向其推送的策略列表中查找該容器所在的位置，然後形成從一個計算節點到另一個計算節點的隧道。隧道接收端的vRouter會檢查內部流量以查看其是否與策略相匹配，然後將其傳遞到預期的目的地。
如果容器希望與Internet或非重疊（non-overlay）目的地通信，流量將被髮送到其中一個外部網關。該網關將移除隧道，並將流量發送到Internet，從而保持容器的唯一IP地址完整不變。這使得與遺留應用程序和網絡的集成變得容易，因爲集羣外的任何人都無法分辨出流量是否來自overlay網絡。
Docker整合
如果我們不能在overlay網絡上讓容器運轉起來，爲玩家做一些實際的工作，那麼所有這些都不過是一個有趣的思想實驗。
Tungsten Fabric是與虛擬化無關的SDN產品，因此需要與編排器集成，以將調度的計算實例與Tungsten Fabric提供的網絡功能相關聯。Tungsten Fabric通過Neutron API驅動程序與OpenStack進行了強大的集成，不過由於我們有自己的協調器Admiral，還需要編寫我們自己的自定義集成。
此外，Tungsten Fabric與OpenStack的集成最初是爲虛擬機設計的，我們希望將其應用於Docker容器。這需要與Juniper Networks合作，以提供一種我們稱爲“Ensign”的服務，可以在每臺主機上運行並處理Admiral、Docker和Tungsten Fabric之間的集成。
爲了解釋我們如何將Docker與Tungsten Fabric集成在一起，需要先來了解一點Linux網絡。Docker使用Linux內核中被稱爲“網絡命名空間（network namespace）”的功能來隔離容器，並防止它們相互訪問。網絡命名空間本質上是網絡接口、路由表和iptables規則的單獨堆棧。網絡命名空間中的那些元素，僅應用於在命名空間中啓動的進程。它與文件系統中使用的chroot很相似，但不同的是它應用於網絡。
當我們開始使用Docker時，有四種方法來配置容器，將其附加到的網絡命名空間：
- Host network 主機網絡模式：Docker將進程放置在主機網絡命名空間中，從而有效地使其完全不隔離。
- Bridge network橋接網絡模式：Docker創建一個Linux橋接器，該橋接器連接主機上所有容器的網絡命名空間，並管理iptables規則以將NAT流量從主機外部傳輸到容器。
- From network 從網絡模式：Docker使用另一個容器的網絡命名空間。
- None network 無網絡模式：Docker設置了沒有接口的網絡命名空間，這意味着其中的進程無法連接到命名空間外部的任何內容。
“無網絡模式”專爲第三方網絡整合而創建，這對我們嘗試要做的事情很有幫助。在啓動容器後，第三方可以將該容器連接到網絡所需的所有組件，全部插入網絡命名空間。
但是，這也帶來了一個問題：容器已經啓動，並且在一段時間內沒有網絡連接。對於應用程序而言，這是一種糟糕的體驗，因爲許多人想知道在啓動時分配了哪些IP地址。儘管Riot開發人員可能已經實現了重試邏輯，但我們不想給他們增加負擔。此外，許多第三方容器無法處理此問題，我們對此也無能爲力。需要一個更全面的解決方案。
爲了克服這個問題，我們在Kubernetes上找到了一個“網絡”容器，該容器在主應用程序容器之前啓動。我們先在“無網絡模式”下啓動網絡容器（因爲它不需要連接或IP地址，所以沒有問題），在使用Tungsten Fabric完成網絡設置並分配IP之後，再啓動主應用程序容器，並使用“從網絡模式”將其附加到網絡容器的網絡命名空間。通過此設置，應用程序在啓動時便具有完全可操作的網絡堆棧。
當我們在物理計算節點（或主機）內部啓動一個新容器時，vRouter會爲該容器提供一個虛擬NIC，一個全局唯一IP地址，以及與該容器關聯的任何路由或安全策略。
這與默認的Docker網絡配置大不相同，在默認配置中，服務器上的每個容器都共享相同的IP地址，並且一臺機器上的所有容器都可以自由地相互通信。此行爲違背了我們的安全策略，在默認情況下，兩個應用程序原本永遠都不能執行此操作。在一個安全的、功能豐富的虛擬網絡中爲每個容器提供自己的IP地址，使得我們能夠爲容器提供一致的、“一流的”網絡體驗。它簡化了我們的配置、安全策略，並使我們避免了許多Docker容器與主機共享相同IP地址所帶來的複雜性。
結論
我們通往SDN和基礎設施自動化的道路還很漫長。我們已經學習了很多有關如何建立自主網絡的最佳實踐，如何調試overlay網絡上的連接問題，以及如何處理新的故障模式的知識。此外，我們還必須在集羣本身的兩代網絡架構中部署此SDN，並將其與六個“傳統”的數據中心架構相集成。包括在自動化方面進行投資，並學習如何確保我們的系統值得信賴，確保測試能夠保持良好的平衡。
話雖如此，我們現在每天都能看到這項工作的成果，Riot的工程師們現在可以通過自服務工作流程，在全球範圍內開發、測試和部署其服務，使得網絡從持續的延遲和挫折中轉變出來，成爲增值服務以及每個開發人員工具箱中的一個強大工具。
在rCluster的下一篇文章中，我們將討論安全性、網絡藍圖和ACL，包括系統如何擴展，以及我們爲提升正常運行時間所做的一些工作。
如果你有任何想法或疑問，非常歡迎與我們取得聯繫。
更多“揭祕LOL”系列文章
揭祕LOL背後的IT基礎架構丨踏上部署多樣性的征程
揭祕LOL背後的IT基礎設施丨關鍵角色“調度”
關注微信：TF中文社區
