溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
歡迎來到Tungsten Fabric用戶案例系列文章，一起發現TF的更多應用場景。“揭秘LOL”系列的主人公是Tungsten Fabric用戶Riot Games游戲公司，作為LOL《英雄聯盟》的開發和運營商，Riot Games面臨全球范圍復雜部署的挑戰，讓我們一起揭秘LOL背后的“英雄們”，看他們是如何運行在線服務的吧。
作者：Doug Lardo和David Press（文章來源：Riot Games）
本文作者David Press和Doug Lardo是Riot的兩名工程師，他們致力于改善數據中心網絡，以支撐Riot的在線服務。本文是關于該主題的系列文章第三部分，將討論我們的SDN（軟件定義網絡）方法，如何將SDN與Docker集成，以及該組合為我們解鎖的新基礎架構范例。如果你對SDN如何轉換基礎架構，如何使開發人員能夠通過API獲得并保護網絡資源，或者如何擺脫購買越來越大的專用網絡設備感到好奇，請參閱本文。
在第一篇文章中，Jonathan提到了為支持《英雄聯盟》的新功能，在推出服務時面臨的一些網絡挑戰。事實證明，（網絡上面的部署）這并不像在服務器上安裝代碼并按回車那樣容易。
新功能需要網絡基礎架構的所提供的功能，包括：
傳統上，設置這些網絡服務，一直是超級專業的網絡工程師的工作領域，他們登錄單個網絡設備，并輸入那些我敢保證就是“純巫術”一樣的命令。配置這些內容通常需要對網絡、相關配置，以及出現問題時的響應有深入的了解。
但是，因為不斷地擴建，數據中心之間的差異越來越大，使得情況變得更加復雜。對于兩個不同數據中心的兩個網絡工程師來說，相同的目標可能看起來完全不同的動作和任務。
所有這些都意味著，數據中心網絡基礎架構的更改，通常都會成為推出新服務的瓶頸。幸運的是，在Riot，任何阻礙向玩家提供新奇特效的因素都會立即受到嚴重關注。rCluster平臺旨在解決這一瓶頸，在以下各節中，我們將深入研究它的關鍵組件：overlay網絡概念，OpenContrail（編者按：已更名為Tungsten Fabric，下文中出現OpenContrail之處，均以Tungsten Fabric代替）實施，以及與Docker的集成。在本系列的下一篇文章中，我們將介紹一些細節，例如安全性、負載均衡和系統擴展。
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網絡非常棒。
在我們剛開始評估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網絡。
如果我們不能在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時，有四種方法來配置容器，將其附加到的網絡命名空間：
“無網絡模式”專為第三方網絡整合而創建，這對我們嘗試要做的事情很有幫助。在啟動容器后，第三方可以將該容器連接到網絡所需的所有組件，全部插入網絡命名空間。
但是，這也帶來了一個問題：容器已經啟動，并且在一段時間內沒有網絡連接。對于應用程序而言，這是一種糟糕的體驗，因為許多人想知道在啟動時分配了哪些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中文社區
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
