揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨SDN解鎖新基礎(chǔ)架構(gòu)

歡迎來到Tungsten Fabric用戶案例系列文章，一起發(fā)現(xiàn)TF的更多應(yīng)用場景?！敖颐豅OL”系列的主人公是Tungsten Fabric用戶Riot Games游戲公司，作為LOL《英雄聯(lián)盟》的開發(fā)和運(yùn)營商，Riot Games面臨全球范圍復(fù)雜部署的挑戰(zhàn)，讓我們一起揭秘LOL背后的“英雄們”，看他們是如何運(yùn)行在線服務(wù)的吧。
作者：Doug Lardo和David Press（文章來源：Riot Games）

本文作者David Press和Doug Lardo是Riot的兩名工程師，他們致力于改善數(shù)據(jù)中心網(wǎng)絡(luò)，以支撐Riot的在線服務(wù)。本文是關(guān)于該主題的系列文章第三部分，將討論我們的SDN（軟件定義網(wǎng)絡(luò)）方法，如何將SDN與Docker集成，以及該組合為我們解鎖的新基礎(chǔ)架構(gòu)范例。如果你對(duì)SDN如何轉(zhuǎn)換基礎(chǔ)架構(gòu)，如何使開發(fā)人員能夠通過API獲得并保護(hù)網(wǎng)絡(luò)資源，或者如何擺脫購買越來越大的專用網(wǎng)絡(luò)設(shè)備感到好奇，請(qǐng)參閱本文。

在第一篇文章中，Jonathan提到了為支持《英雄聯(lián)盟》的新功能，在推出服務(wù)時(shí)面臨的一些網(wǎng)絡(luò)挑戰(zhàn)。事實(shí)證明，（網(wǎng)絡(luò)上面的部署）這并不像在服務(wù)器上安裝代碼并按回車那樣容易。

新功能需要網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的所提供的功能，包括：

• 連接性：對(duì)玩家和內(nèi)部服務(wù)的低延遲和高吞吐量訪問
• 安全性：防止未經(jīng)授權(quán)的訪問和DoS 攻 擊，并在需要時(shí)進(jìn)行通信，以最大程度地減少發(fā)生漏洞時(shí)的影響
• 數(shù)據(jù)包服務(wù)：負(fù)載均衡，網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT），虛擬專用網(wǎng)（V P N），連接性和組播轉(zhuǎn)發(fā)

傳統(tǒng)上，設(shè)置這些網(wǎng)絡(luò)服務(wù)，一直是超級(jí)專業(yè)的網(wǎng)絡(luò)工程師的工作領(lǐng)域，他們登錄單個(gè)網(wǎng)絡(luò)設(shè)備，并輸入那些我敢保證就是“純巫術(shù)”一樣的命令。配置這些內(nèi)容通常需要對(duì)網(wǎng)絡(luò)、相關(guān)配置，以及出現(xiàn)問題時(shí)的響應(yīng)有深入的了解。

但是，因?yàn)椴粩嗟財(cái)U(kuò)建，數(shù)據(jù)中心之間的差異越來越大，使得情況變得更加復(fù)雜。對(duì)于兩個(gè)不同數(shù)據(jù)中心的兩個(gè)網(wǎng)絡(luò)工程師來說，相同的目標(biāo)可能看起來完全不同的動(dòng)作和任務(wù)。

所有這些都意味著，數(shù)據(jù)中心網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的更改，通常都會(huì)成為推出新服務(wù)的瓶頸。幸運(yùn)的是，在Riot，任何阻礙向玩家提供新奇特效的因素都會(huì)立即受到嚴(yán)重關(guān)注。rCluster平臺(tái)旨在解決這一瓶頸，在以下各節(jié)中，我們將深入研究它的關(guān)鍵組件：overlay網(wǎng)絡(luò)概念，OpenContrail（編者按：已更名為Tungsten Fabric，下文中出現(xiàn)OpenContrail之處，均以Tungsten Fabric代替）實(shí)施，以及與Docker的集成。在本系列的下一篇文章中，我們將介紹一些細(xì)節(jié)，例如安全性、負(fù)載均衡和系統(tǒng)擴(kuò)展。

SDN和overlay網(wǎng)絡(luò)

SDN變成了一個(gè)流行語，對(duì)不同的人意味著不同的事情：對(duì)于某些人來說，這意味著網(wǎng)絡(luò)配置應(yīng)由軟件定義；但是在Riot，這意味著我們的網(wǎng)絡(luò)功能應(yīng)通過一致的API進(jìn)行編程。

通過使網(wǎng)絡(luò)可編程化，我們可以編寫自動(dòng)化程序，從而極大地?cái)U(kuò)展了我們的能力，能夠快速將更改部署到網(wǎng)絡(luò)。我們只需要運(yùn)行一個(gè)命令，而不必將其封裝到眾多的設(shè)備中進(jìn)行更改（附注：封裝的概念是，將網(wǎng)絡(luò)的功能要求變成不同的的網(wǎng)絡(luò)設(shè)備命令）。我們將全球網(wǎng)絡(luò)變更的時(shí)間從天變成了分鐘級(jí)，并且這樣，還能在空閑時(shí)間里去做其它很酷的事情。

網(wǎng)絡(luò)設(shè)備的可編程已經(jīng)有一段時(shí)間了，不過在整個(gè)行業(yè)中，對(duì)這些設(shè)備進(jìn)行編程的接口在不斷變化和發(fā)展，并且不存在適用于所有類型設(shè)備和所有供應(yīng)商的統(tǒng)一標(biāo)準(zhǔn)。因此，編寫能夠與多個(gè)供應(yīng)商的每個(gè)接口通信的強(qiáng)大自動(dòng)化程序，是一項(xiàng)非常艱巨的任務(wù)。我們也知道，在硬件上方擁有一致的API作為抽象層，是Riot有效擴(kuò)展其網(wǎng)絡(luò)配置管理和操作的關(guān)鍵要求。于是，我們轉(zhuǎn)向了overlay網(wǎng)絡(luò)。（編者按：特意在overlay前面解釋網(wǎng)絡(luò)設(shè)備可編程的原因是，網(wǎng)絡(luò)為應(yīng)用服務(wù)，因?yàn)閼?yīng)用的不斷變化，因此網(wǎng)絡(luò)的配置也需要不斷變化，盡管網(wǎng)絡(luò)設(shè)備具有可編程性，可以實(shí)現(xiàn)業(yè)務(wù)和網(wǎng)絡(luò)的編排，但是也面臨挑戰(zhàn)，供應(yīng)商不同，配置不同，API不同，很難統(tǒng)一。）

毫無疑問，overlay網(wǎng)絡(luò)位于現(xiàn)有網(wǎng)絡(luò)之上。在overlay網(wǎng)絡(luò)內(nèi)部的應(yīng)用程序并不知道網(wǎng)絡(luò)的存在，因?yàn)樗诟杏X上完全類似于物理網(wǎng)絡(luò)。如果你熟悉虛擬機(jī)，則相同的“物理內(nèi)部的虛擬”范例也適用于虛擬網(wǎng)絡(luò)。一個(gè)物理網(wǎng)絡(luò)可以承載許多虛擬網(wǎng)絡(luò)。在一個(gè)虛擬機(jī)中，應(yīng)用程序認(rèn)為它們擁有一整臺(tái)物理機(jī)，但實(shí)際上，它們僅擁有一小部分虛擬機(jī)。Overlay網(wǎng)絡(luò)也是類似的概念，一種內(nèi)部創(chuàng)建的有虛擬網(wǎng)絡(luò)的物理基礎(chǔ)架構(gòu)（稱為underlay網(wǎng)絡(luò)）。

這種方法使我們能夠?qū)iot工程師無需擔(dān)心的各種物理網(wǎng)絡(luò)細(xì)節(jié)隱藏起來。工程師不再需要問“有多少端口”，“我們有哪些供應(yīng)商”，“安全策略應(yīng)該放在那里”這樣的問題。相反，我們可以提供一個(gè)一致的API程序，讓工程師專注在自己想做的事情上。

在Riot運(yùn)營的每個(gè)數(shù)據(jù)中心中使用相同的API，使得我們編寫的自動(dòng)化可以在任何地方、任何時(shí)間有效工作，無論是使用在過去的第一個(gè)數(shù)據(jù)中心，還是更現(xiàn)代化的設(shè)計(jì)。此外，我們還可以尋找其他云服務(wù)商，例如Amazon、Rackspace、Google Compute等，并且我們的API仍然可以使用。

這樣設(shè)計(jì)，我們的底層物理硬件可能是Cisco、Juniper、Arista、Dell、D-Link、白盒、灰盒、一堆有10GE端口的Linux盒子，這都沒關(guān)系。但是Underlay網(wǎng)絡(luò)必須使用特定的方法來構(gòu)建，例如自動(dòng)配置模板（更多信息，參見下一篇系列文章），但這使我們能夠?qū)⑽锢順?gòu)建和配置，與應(yīng)用程序所需的服務(wù)配置解耦。當(dāng)我們將underlay和軟件服務(wù)接口，保持underlay網(wǎng)絡(luò)的穩(wěn)定還有更多好處，我們可以讓underlay可以專注于提供高可用性的數(shù)據(jù)包轉(zhuǎn)發(fā)，并允許我們升級(jí)物理網(wǎng)絡(luò)，而不必?fù)?dān)心會(huì)破壞以前與物理基礎(chǔ)架構(gòu)緊密耦合的應(yīng)用程序。它還簡化了我們的運(yùn)營，允許服務(wù)在任何一個(gè)數(shù)據(jù)中心遷入和移出，并消除了供應(yīng)商鎖定的風(fēng)險(xiǎn)。

總之，我們認(rèn)為overlay網(wǎng)絡(luò)非常棒。

Tungsten Fabric

在我們剛開始評(píng)估SDN時(shí)，研究了整個(gè)行業(yè)的各種SDN項(xiàng)目。有些通過中央控制器配置物理網(wǎng)絡(luò)，還有一些則提供了抽象層，將API調(diào)用轉(zhuǎn)換為特定于某個(gè)供應(yīng)商的指令。有些解決方案需要新的硬件，還有一些則可以在現(xiàn)有基礎(chǔ)架構(gòu)上運(yùn)行。有些是由大型公司開發(fā)的，還有一些是開源項(xiàng)目，或者由初創(chuàng)公司提供。

簡而言之，我們花了很多時(shí)間來做功課，這并不是一個(gè)容易的決定。我們需要滿足的要求包括：

• 在我們的數(shù)據(jù)中心（無論老的還是新的）、裸機(jī)和云中提供功能性
• 是開源的項(xiàng)目，但是也不要在一夜之間消失
• 能夠?qū)ξ覀兊牟渴鹫鞒烫峁I(yè)輔助

最終，我們的視線落在了Juniper Networks的Tungsten Fabric項(xiàng)目上。Tungsten Fabric從一開始就被設(shè)計(jì)為開源的、與供應(yīng)商無關(guān)的解決方案，可與任何一個(gè)現(xiàn)有網(wǎng)絡(luò)一起使用。其核心是BGP和MPLS——兩者都是已被證明可以規(guī)?；瘮U(kuò)展到整個(gè)Internet的協(xié)議。Juniper Networks肯定不會(huì)很快消失，并且在我們設(shè)計(jì)和安裝第一套集群時(shí)，提供了很多幫助。（點(diǎn)擊“TF架構(gòu)系列”文章，查看這個(gè)控制器的全部細(xì)節(jié)）

Tungsten Fabric包含三個(gè)主要組件：集中控制器（“大腦”），vRouter（虛擬路由器）和外部網(wǎng)關(guān)。每個(gè)組件都是高可用性集群的成員，因此任何單個(gè)設(shè)備故障都不會(huì)破壞整個(gè)系統(tǒng)。與控制器進(jìn)行API交互，會(huì)立即觸發(fā)其將所有必要的更改,并推送到vRouter和網(wǎng)關(guān)，然后由它們物理轉(zhuǎn)發(fā)網(wǎng)絡(luò)上的流量。

Overlay網(wǎng)絡(luò)由vRouter之間的一系列隧道組成，可供選擇的協(xié)議包括GRE w / MPLS、UDP w / MPLS或VXLAN。當(dāng)一個(gè)容器想要與另一個(gè)容器通信時(shí)，vRouter首先在控制器先前向其推送的策略列表中查找該容器所在的位置，然后形成從一個(gè)計(jì)算節(jié)點(diǎn)到另一個(gè)計(jì)算節(jié)點(diǎn)的隧道。隧道接收端的vRouter會(huì)檢查內(nèi)部流量以查看其是否與策略相匹配，然后將其傳遞到預(yù)期的目的地。

如果容器希望與Internet或非重疊（non-overlay）目的地通信，流量將被發(fā)送到其中一個(gè)外部網(wǎng)關(guān)。該網(wǎng)關(guān)將移除隧道，并將流量發(fā)送到Internet，從而保持容器的唯一IP地址完整不變。這使得與遺留應(yīng)用程序和網(wǎng)絡(luò)的集成變得容易，因?yàn)榧和獾娜魏稳硕紵o法分辨出流量是否來自overlay網(wǎng)絡(luò)。

Docker整合

如果我們不能在overlay網(wǎng)絡(luò)上讓容器運(yùn)轉(zhuǎn)起來，為玩家做一些實(shí)際的工作，那么所有這些都不過是一個(gè)有趣的思想實(shí)驗(yàn)。

Tungsten Fabric是與虛擬化無關(guān)的SDN產(chǎn)品，因此需要與編排器集成，以將調(diào)度的計(jì)算實(shí)例與Tungsten Fabric提供的網(wǎng)絡(luò)功能相關(guān)聯(lián)。Tungsten Fabric通過Neutron API驅(qū)動(dòng)程序與OpenStack進(jìn)行了強(qiáng)大的集成，不過由于我們有自己的協(xié)調(diào)器Admiral，還需要編寫我們自己的自定義集成。

此外，Tungsten Fabric與OpenStack的集成最初是為虛擬機(jī)設(shè)計(jì)的，我們希望將其應(yīng)用于Docker容器。這需要與Juniper Networks合作，以提供一種我們稱為“Ensign”的服務(wù)，可以在每臺(tái)主機(jī)上運(yùn)行并處理Admiral、Docker和Tungsten Fabric之間的集成。

為了解釋我們?nèi)绾螌ocker與Tungsten Fabric集成在一起，需要先來了解一點(diǎn)Linux網(wǎng)絡(luò)。Docker使用Linux內(nèi)核中被稱為“網(wǎng)絡(luò)命名空間（network namespace）”的功能來隔離容器，并防止它們相互訪問。網(wǎng)絡(luò)命名空間本質(zhì)上是網(wǎng)絡(luò)接口、路由表和iptables規(guī)則的單獨(dú)堆棧。網(wǎng)絡(luò)命名空間中的那些元素，僅應(yīng)用于在命名空間中啟動(dòng)的進(jìn)程。它與文件系統(tǒng)中使用的chroot很相似，但不同的是它應(yīng)用于網(wǎng)絡(luò)。

當(dāng)我們開始使用Docker時(shí)，有四種方法來配置容器，將其附加到的網(wǎng)絡(luò)命名空間：

• Host network 主機(jī)網(wǎng)絡(luò)模式：Docker將進(jìn)程放置在主機(jī)網(wǎng)絡(luò)命名空間中，從而有效地使其完全不隔離。
• Bridge network橋接網(wǎng)絡(luò)模式：Docker創(chuàng)建一個(gè)Linux橋接器，該橋接器連接主機(jī)上所有容器的網(wǎng)絡(luò)命名空間，并管理iptables規(guī)則以將NAT流量從主機(jī)外部傳輸?shù)饺萜鳌?/li>
• From network 從網(wǎng)絡(luò)模式：Docker使用另一個(gè)容器的網(wǎng)絡(luò)命名空間。
• None network 無網(wǎng)絡(luò)模式：Docker設(shè)置了沒有接口的網(wǎng)絡(luò)命名空間，這意味著其中的進(jìn)程無法連接到命名空間外部的任何內(nèi)容。

“無網(wǎng)絡(luò)模式”專為第三方網(wǎng)絡(luò)整合而創(chuàng)建，這對(duì)我們嘗試要做的事情很有幫助。在啟動(dòng)容器后，第三方可以將該容器連接到網(wǎng)絡(luò)所需的所有組件，全部插入網(wǎng)絡(luò)命名空間。

但是，這也帶來了一個(gè)問題：容器已經(jīng)啟動(dòng)，并且在一段時(shí)間內(nèi)沒有網(wǎng)絡(luò)連接。對(duì)于應(yīng)用程序而言，這是一種糟糕的體驗(yàn)，因?yàn)樵S多人想知道在啟動(dòng)時(shí)分配了哪些IP地址。盡管Riot開發(fā)人員可能已經(jīng)實(shí)現(xiàn)了重試邏輯，但我們不想給他們增加負(fù)擔(dān)。此外，許多第三方容器無法處理此問題，我們對(duì)此也無能為力。需要一個(gè)更全面的解決方案。

為了克服這個(gè)問題，我們在Kubernetes上找到了一個(gè)“網(wǎng)絡(luò)”容器，該容器在主應(yīng)用程序容器之前啟動(dòng)。我們先在“無網(wǎng)絡(luò)模式”下啟動(dòng)網(wǎng)絡(luò)容器（因?yàn)樗恍枰B接或IP地址，所以沒有問題），在使用Tungsten Fabric完成網(wǎng)絡(luò)設(shè)置并分配IP之后，再啟動(dòng)主應(yīng)用程序容器，并使用“從網(wǎng)絡(luò)模式”將其附加到網(wǎng)絡(luò)容器的網(wǎng)絡(luò)命名空間。通過此設(shè)置，應(yīng)用程序在啟動(dòng)時(shí)便具有完全可操作的網(wǎng)絡(luò)堆棧。

當(dāng)我們在物理計(jì)算節(jié)點(diǎn)（或主機(jī)）內(nèi)部啟動(dòng)一個(gè)新容器時(shí)，vRouter會(huì)為該容器提供一個(gè)虛擬NIC，一個(gè)全局唯一IP地址，以及與該容器關(guān)聯(lián)的任何路由或安全策略。

這與默認(rèn)的Docker網(wǎng)絡(luò)配置大不相同，在默認(rèn)配置中，服務(wù)器上的每個(gè)容器都共享相同的IP地址，并且一臺(tái)機(jī)器上的所有容器都可以自由地相互通信。此行為違背了我們的安全策略，在默認(rèn)情況下，兩個(gè)應(yīng)用程序原本永遠(yuǎn)都不能執(zhí)行此操作。在一個(gè)安全的、功能豐富的虛擬網(wǎng)絡(luò)中為每個(gè)容器提供自己的IP地址，使得我們能夠?yàn)槿萜魈峁┮恢碌?、“一流的”網(wǎng)絡(luò)體驗(yàn)。它簡化了我們的配置、安全策略，并使我們避免了許多Docker容器與主機(jī)共享相同IP地址所帶來的復(fù)雜性。

結(jié)論

我們通往SDN和基礎(chǔ)設(shè)施自動(dòng)化的道路還很漫長。我們已經(jīng)學(xué)習(xí)了很多有關(guān)如何建立自主網(wǎng)絡(luò)的最佳實(shí)踐，如何調(diào)試overlay網(wǎng)絡(luò)上的連接問題，以及如何處理新的故障模式的知識(shí)。此外，我們還必須在集群本身的兩代網(wǎng)絡(luò)架構(gòu)中部署此SDN，并將其與六個(gè)“傳統(tǒng)”的數(shù)據(jù)中心架構(gòu)相集成。包括在自動(dòng)化方面進(jìn)行投資，并學(xué)習(xí)如何確保我們的系統(tǒng)值得信賴，確保測試能夠保持良好的平衡。

話雖如此，我們現(xiàn)在每天都能看到這項(xiàng)工作的成果，Riot的工程師們現(xiàn)在可以通過自服務(wù)工作流程，在全球范圍內(nèi)開發(fā)、測試和部署其服務(wù)，使得網(wǎng)絡(luò)從持續(xù)的延遲和挫折中轉(zhuǎn)變出來，成為增值服務(wù)以及每個(gè)開發(fā)人員工具箱中的一個(gè)強(qiáng)大工具。

在rCluster的下一篇文章中，我們將討論安全性、網(wǎng)絡(luò)藍(lán)圖和ACL，包括系統(tǒng)如何擴(kuò)展，以及我們?yōu)樘嵘＿\(yùn)行時(shí)間所做的一些工作。

如果你有任何想法或疑問，非常歡迎與我們?nèi)〉寐?lián)系。

更多“揭秘LOL”系列文章
揭秘LOL背后的IT基礎(chǔ)架構(gòu)丨踏上部署多樣性的征程
揭秘LOL背后的IT基礎(chǔ)設(shè)施丨關(guān)鍵角色“調(diào)度”

關(guān)注微信：TF中文社區(qū)