導(dǎo)語
「云計(jì)算的太祖長拳」系列將全面解析UCloud可用區(qū)特性技術(shù)內(nèi)幕，闡述基礎(chǔ)網(wǎng)絡(luò)的改造和外網(wǎng)新特性技術(shù)實(shí)現(xiàn)摩幔，包括基礎(chǔ)網(wǎng)絡(luò)的改造彤委、NFV虛擬網(wǎng)關(guān)的實(shí)踐、底層SDN控制面和數(shù)據(jù)轉(zhuǎn)發(fā)面的演進(jìn)以及建設(shè)在新老架構(gòu)間平滑遷移海量用戶數(shù)據(jù)的運(yùn)營能力等各個(gè)方面或衡，分享該項(xiàng)目中的一些心得和經(jīng)驗(yàn)焦影。
在本系列的第一篇文章里（解密「云計(jì)算的太祖長拳」系列之一“膽”：基礎(chǔ)網(wǎng)絡(luò)改造與新架構(gòu)），我們詳細(xì)介紹了為了支持可用區(qū)新功能封断，UCloud在基礎(chǔ)網(wǎng)絡(luò)建設(shè)和外網(wǎng)特性方面所做的一系列改造偷办，其中包括基礎(chǔ)網(wǎng)絡(luò)的雙星型拓?fù)浣Y(jié)構(gòu)和POP點(diǎn)的建設(shè)；EIP澄港、ULB椒涯、以及共享帶寬的功能跨AZ的使用；跨AZ流量調(diào)度的核心模塊 - UVER (UCloud Virtual Edge Router)的實(shí)現(xiàn)等方面的內(nèi)容回梧。
本篇文章是該系列的第二篇废岂，我們會(huì)著重介紹在可用區(qū)研發(fā)過程中，我們對UCloud公有云平臺的底層SDN架構(gòu)所做的一系列改造狱意。這些改造有的是宏觀層面的重構(gòu)和演進(jìn)湖苞，有的看似是局部的調(diào)整但實(shí)則是在親歷了運(yùn)營一個(gè)大型IaaS平臺所遇到的那些困難之后才審慎提出的一套解決方案。
Agenda:
SDN底層架構(gòu)重構(gòu)
支持虛擬網(wǎng)絡(luò)廣播協(xié)議帶來的架構(gòu)變化
SDN封裝隧道與流表的優(yōu)化
結(jié)語
SDN底層架構(gòu)重構(gòu)（網(wǎng)元跨可用區(qū)的互訪）
UCloud IaaS平臺上支持多種不同類型的計(jì)算節(jié)點(diǎn)详囤，比如公有云上的虛擬主機(jī)（我們簡稱“公有云”）财骨，物理主機(jī)（簡稱“物理云”），以及托管區(qū)域的主機(jī)（簡稱“托管云”）等等藏姐。這些節(jié)點(diǎn)或者說網(wǎng)元在底層SDN網(wǎng)絡(luò)的支持下互相間是可以在虛擬網(wǎng)絡(luò)（Virtual Network）的層面上無縫地互相通信的隆箩，同時(shí)，虛擬網(wǎng)絡(luò)也提供了租戶間互相隔離的安全機(jī)制羔杨。這些都是IaaS平臺所應(yīng)具備的基礎(chǔ)能力捌臊。在可用區(qū)的場景下，這些能力從用戶層面看來還是保持了和從前一致的行為兜材，但事實(shí)上理澎，平臺底層的物理網(wǎng)絡(luò)以及SDN邏輯其實(shí)是經(jīng)歷了一次徹底的重構(gòu)。為了更好地理解這次重構(gòu)的意義曙寡，我們首先來了解一下原有的網(wǎng)元跨DC互通的實(shí)現(xiàn)：
如上圖所示糠爬，在之前的架構(gòu)里，不同DC間的兩臺主機(jī)的互訪是要通過跨機(jī)房的軟件網(wǎng)關(guān)（上圖中的Gateway）來轉(zhuǎn)發(fā)的举庶。當(dāng)然這里底層的邏輯還是通過SDN的方式來實(shí)現(xiàn)的执隧，其datapath的路徑如下：
這個(gè)架構(gòu)雖然能提供用戶不同機(jī)房的網(wǎng)元間互訪的能力，但從整體上來評估， 它還是具有以下三方面的問題：
互訪的SDN邏輯比較復(fù)雜：兩個(gè)節(jié)點(diǎn)間單向就需要有6條SDN的flow殴玛，所有這些flow的下發(fā)都需要經(jīng)過controller和后端manager的處理捅膘，然后要考慮鑒權(quán)隔離、跨賬號互通等其他相關(guān)的場景滚粟。同時(shí)寻仗，我們還必須考慮不同網(wǎng)元間的各種場景（比如“公有云”和“物理云”跨機(jī)房互通，“公有云”和“托管云”跨機(jī)房互通等）凡壤，那復(fù)雜度必然進(jìn)一步增加署尤。
跨機(jī)房互訪由于需要經(jīng)過兩組軟件網(wǎng)關(guān)的轉(zhuǎn)發(fā)，那么其效率一定會(huì)受到一些影響（整個(gè)邏輯鏈路的網(wǎng)絡(luò)延遲會(huì)有所增加）亚侠。并且曹体，由于這些軟件網(wǎng)關(guān)集群位于跨機(jī)房互通的關(guān)鍵路徑上，它們自身的可靠性和容災(zāi)能力也是我們不得不面對的問題硝烂。
后續(xù)在各個(gè)相連機(jī)房不斷擴(kuò)容的情況下箕别，跨機(jī)房網(wǎng)關(guān)集群也必須隨之?dāng)U容。但作為整個(gè)鏈路上必經(jīng)的中央節(jié)點(diǎn)滞谢，這個(gè)服務(wù)理論上將面臨的是O(n2)的擴(kuò)容壓力（假設(shè)兩邊機(jī)房的節(jié)點(diǎn)數(shù)是n）串稀，這對整個(gè)系統(tǒng)長期的發(fā)展來看不是一個(gè)理想的狀態(tài)。
對于大型的分布式系統(tǒng)狮杨，一般而言母截，復(fù)雜度永遠(yuǎn)是軟件系統(tǒng)穩(wěn)定性和可擴(kuò)展性的天敵。我們設(shè)計(jì)的目標(biāo)是在保證功能性的基礎(chǔ)上橄教，能盡量低去簡化系統(tǒng)清寇，把系統(tǒng)“做小”：a system achieves perfection not when there is nothing more to add, but when there is nothing left to take away.
在可用區(qū)的新架構(gòu)中，不同AZ間的網(wǎng)元之間的互通不再需要通過跨AZ網(wǎng)關(guān)做轉(zhuǎn)發(fā)护蝶，同一Region下的兩個(gè)網(wǎng)元之間在物理網(wǎng)絡(luò)層面上是三層(IP層)直連的华烟，下圖是可用區(qū)啟用前后網(wǎng)絡(luò)路徑的對比：
如此，不同AZ的網(wǎng)元間互訪的datapath就和同AZ的情況是完全一致的滓走，這就從底層保證了用戶可以在其虛擬網(wǎng)絡(luò)中部署跨AZ的云主機(jī)而不必?fù)?dān)心受到不同物理網(wǎng)絡(luò)拓?fù)涞南拗苹蛴绊懣呀谔摂M網(wǎng)絡(luò)之上的云主機(jī)與云主機(jī)之間是一個(gè)完全“點(diǎn)對點(diǎn)”直連的“大二層”拓?fù)浣Y(jié)構(gòu)，在這個(gè)框架下搅方，用戶可以無縫地獲得跨AZ部署高可用應(yīng)用的容災(zāi)能力。
對于物理云和托管云來說绽族，情況略有不同姨涡，因?yàn)樗鼈冇懈髯缘木W(wǎng)關(guān)來處理業(yè)務(wù)邏輯，但這和跨AZ互通無關(guān)吧慢，在本機(jī)房訪問物理云或托管云涛漂，也是需要經(jīng)過它們各自的業(yè)務(wù)邏輯的網(wǎng)關(guān)的。只是在可用區(qū)邏輯下，我們大力整合了對各種不同類型網(wǎng)元間互訪的支持匈仗，使得同一個(gè)Region下瓢剿，不同類型網(wǎng)元的互訪成為默認(rèn)支持的模式而無需進(jìn)過特別的協(xié)調(diào)或非標(biāo)操作：
支持虛擬網(wǎng)絡(luò)廣播協(xié)議帶來的架構(gòu)變化（廣播協(xié)議在可用區(qū)中的實(shí)現(xiàn)）
上文提到，利用可用區(qū)的特性悠轩，用戶虛擬網(wǎng)絡(luò)“大二層”的范圍事實(shí)上已經(jīng)擴(kuò)展到整個(gè)Region所有的AZ里了间狂。由此帶來的特性能力之前已經(jīng)有了諸多闡述，但同時(shí)火架，也有很多基礎(chǔ)架構(gòu)層面上的挑戰(zhàn)隨之而來鉴象。在這里我們著重對于在虛擬網(wǎng)絡(luò)中支持廣播協(xié)議這一場景做一些深入的探究。
眾多的公有云平臺在其虛擬網(wǎng)絡(luò)中是不支持廣播協(xié)議的何鸡，包括很多國內(nèi)的友商和AWS這樣的公有云技術(shù)的領(lǐng)導(dǎo)者（參見：AWS | Amazon Virtual Private Cloud (VPC)）纺弊。UCloud的虛擬網(wǎng)絡(luò)是支持廣播協(xié)議的，這里包括二層的和三層廣播報(bào)文骡男，如下圖所示：
在可用區(qū)的場景下淆游，理論上用戶的子網(wǎng)中的主機(jī)已經(jīng)不局限于某一個(gè)AZ，而是可以跨多個(gè)AZ隔盛，亦即用戶的廣播域事實(shí)上從一個(gè)AZ擴(kuò)展到整個(gè)Region稽犁，那我們在面對支持廣播協(xié)議的問題時(shí)立刻會(huì)面臨以下的挑戰(zhàn)：
對廣播協(xié)議的支持是有很大的開銷的，這里的開銷包括兩部分：
虛擬網(wǎng)絡(luò)的后臺管理面的服務(wù)在underlay網(wǎng)絡(luò)中需要?jiǎng)?chuàng)建骚亿、查詢已亥、修改或刪除的信息；
虛擬網(wǎng)絡(luò)數(shù)據(jù)轉(zhuǎn)發(fā)面上的vSwitch所需要處理的overlay網(wǎng)絡(luò)中的報(bào)文數(shù)量来屠。而隨著廣播域從一個(gè)AZ擴(kuò)展到一個(gè)Region, 我們面臨的問題的復(fù)雜度在現(xiàn)有架構(gòu)中也從AZ級別的數(shù)量級提高到了Region級別的數(shù)量級虑椎。
在現(xiàn)有架構(gòu)中，虛擬網(wǎng)絡(luò)后臺管理面的服務(wù)在子網(wǎng)中某個(gè)節(jié)點(diǎn)發(fā)起首次廣播通信的時(shí)候需要完成大量的初始化工作【愕眩現(xiàn)實(shí)中捆姜，這樣的情況并不罕見，比如說用戶新建了一臺云主機(jī)迎膜，然后從這臺云主機(jī)發(fā)起一次廣播通信泥技，后臺服務(wù)所要承擔(dān)的壓力是隨著廣播域的擴(kuò)大而線性增加的。而在數(shù)據(jù)轉(zhuǎn)發(fā)面上磕仅，任意節(jié)點(diǎn)上的vSwitch對每個(gè)廣播報(bào)文也必須完成O(n)量級的處理工作珊豹。換句話說，從全局來看榕订，支持一個(gè)子網(wǎng)中全量的廣播協(xié)議店茶，我們面臨的問題的總體復(fù)雜度是O(n2)：
如此，當(dāng)廣播域增加到一定體量的時(shí)候劫恒，我們就會(huì)遇上無法避免的性能瓶頸贩幻。如果說對于無狀態(tài)的后臺管理面服務(wù)轿腺，我們還可以通過水平擴(kuò)容來地解決一定問題的話，那對于單個(gè)節(jié)點(diǎn)上數(shù)據(jù)轉(zhuǎn)發(fā)面的核心vSwitch來說丛楚，一旦觸碰到某個(gè)之前未知的性能限制時(shí)族壳，我們很可能將束手無策。在實(shí)際應(yīng)用中趣些，我們發(fā)現(xiàn)UCloud平臺上某些較大的用戶的廣播域已經(jīng)達(dá)到了600+的數(shù)量仿荆，而此時(shí)從我們用戶提供的反饋來看，底層架構(gòu)的瓶頸確實(shí)已經(jīng)對他們的實(shí)際使用造成了可感知的影響喧务。
為了解決這個(gè)問題赖歌，我們重新設(shè)計(jì)了以下架構(gòu)來支持虛擬網(wǎng)絡(luò)中的廣播協(xié)議：
這里，我們通過一組獨(dú)立的服務(wù)集群（以下簡稱“廣播集群”）專門來處理廣播報(bào)文功茴。Overlay中的所有廣播報(bào)文都會(huì)通過特定的SDN規(guī)則送到這個(gè)集群上經(jīng)過處理后再轉(zhuǎn)發(fā)庐冯。可以看到坎穿，在這個(gè)新架構(gòu)下展父，廣播域的變化給管理面和數(shù)據(jù)轉(zhuǎn)發(fā)面帶來的新增負(fù)擔(dān)是一個(gè)常量（亦即：只需要負(fù)擔(dān)新增節(jié)點(diǎn)的那部分開銷就可以了，現(xiàn)存節(jié)點(diǎn)不會(huì)增加額外開銷）玲昧，或者說栖茉，之前的O(n2)復(fù)雜度的問題現(xiàn)在就降級為O(n)的問題了。
另外大家可以看到孵延，雖然在可用區(qū)特性的開發(fā)過程中“廣播集群”主要被用來處理廣播報(bào)文吕漂，但我們可以很容易地對這個(gè)服務(wù)的功能做一些擴(kuò)展以支持新的協(xié)議，比如廣義上的BUM（Broadcast, Unknown unicast, Multicast）報(bào)文尘应，而不需要對整體SDN后臺的架構(gòu)做大的變動(dòng)惶凝。
關(guān)于可用區(qū)中底層SDN架構(gòu)改造的最后一個(gè)話題是我們對于overlay協(xié)議中使用的隧道（tunnel）和流表（flow table）的優(yōu)化。為了理解這里面臨的問題犬钢，我們首先來看一下可用區(qū)特性之前的Overlay協(xié)議的實(shí)現(xiàn)苍鲜，以虛擬網(wǎng)絡(luò)中兩個(gè)節(jié)點(diǎn)間的單播通信為例：
Overlay中隧道的定義如下：
對應(yīng)的單播flow則是：
可以看出，所有underlay中封裝（encapsulation）所需要的信息都是包含在tunnel的定義中的玷犹，而flow只是包含overlay中虛擬網(wǎng)絡(luò)的信息（除了GRE key）混滔。
這樣的做法好處就在于它很直觀并容易理解，然而歹颓，這里最大的潛在麻煩在于所有任意兩點(diǎn)間的封裝信息都必須記錄在案以備查詢坯屿，也就是說假設(shè)虛擬網(wǎng)絡(luò)的數(shù)量級是n, 那么保證任意兩點(diǎn)間單播通信的問題的總體復(fù)雜度就是O(n2)，這點(diǎn)從后臺數(shù)據(jù)庫中存儲(chǔ)這些信息所需要占用的空間來看就很容易理解：
對于一個(gè)大小為n的虛擬網(wǎng)絡(luò)來說晴股，我們需要O(n2)條記錄來存儲(chǔ)所有相關(guān)的tunnel信息愿伴。當(dāng)虛擬網(wǎng)絡(luò)的允許范圍從一個(gè)AZ擴(kuò)大到整個(gè)Region的時(shí)候，n2的增量是很可怕的电湘。
那么我們?nèi)绾蝸斫鉀Q這個(gè)問題呢？我們重新設(shè)計(jì)了overlay協(xié)議中tunnel和flow的定義：
對應(yīng)的單播flow是：
我們將原本存在于tunnel定義內(nèi)的封裝信息全部移到了flow中，并且由于flow作用在本地的網(wǎng)卡上寂呛，因此源端的tunnel地址就無需再顯式地定義了怎诫，只需要定義對端的tunnel地址。而對端在接收到這樣一個(gè)封裝后的數(shù)據(jù)報(bào)文時(shí)贷痪，也完全可以通過tunnel的目標(biāo)地址和GRE key來解封裝(decapsulation)幻妓。這樣的設(shè)計(jì)，完全免除了原來對O(n2)的tunnel信息的增刪改查操作劫拢，所有的信息完全包含在點(diǎn)對點(diǎn)的flow中了肉津。
在本篇技術(shù)分享中，我們著重介紹了為了支持可用區(qū)特性所做的一系列底層SDN網(wǎng)絡(luò)架構(gòu)的改造：
不同類型公有云網(wǎng)元間的互訪
廣播協(xié)議的處理
SDN隧道和流表的優(yōu)化
這些底層架構(gòu)的改動(dòng)和演進(jìn)也許對于用戶而言來說大多數(shù)時(shí)間都是不可見的舱沧，但這其中要付出的努力以及敢于推翻和重構(gòu)已有架構(gòu)的魄力妹沙，所面臨的挑戰(zhàn)的難度其實(shí)絲毫不亞于提供那些用戶直觀可見的功能。有些工作我們根據(jù)已知的用戶反饋知道那是我們必須立刻解決的熟吏，而有些工作則更多的是一種前瞻性的設(shè)計(jì)距糖，因?yàn)榻Y(jié)合我們之前積累的經(jīng)驗(yàn)以及現(xiàn)網(wǎng)數(shù)據(jù)累積的趨勢來看，我們可以比較有把握的推斷出架構(gòu)上的不合理性在哪個(gè)程度會(huì)給整個(gè)平臺的可靠性和可用性帶來可感知的影響牵寺，對于這類問題悍引，我們也必須有魄力去未雨綢繆地進(jìn)行解決。
在下一篇連載中帽氓，我們將討論我們是如何運(yùn)營和發(fā)布可用區(qū)這個(gè)特性的趣斤。實(shí)現(xiàn)一個(gè)生產(chǎn)環(huán)境下的大型分布式系統(tǒng)，如果面對的問題數(shù)量級很小黎休，通常很多矛盾都不會(huì)暴露出來浓领。如果所有的新功能都能重起爐灶，同樣的奋渔，一切都會(huì)顯得很簡單美好镊逝。但真正的困難往往就是在運(yùn)營海量數(shù)據(jù)和保證現(xiàn)網(wǎng)服務(wù)不回歸這兩個(gè)前提下才會(huì)集中爆發(fā)出來，而在這兩個(gè)前提條件下穩(wěn)定地迭代新的特性和功能嫉鲸，就猶如是給高速飛馳中的跑車更換引擎撑蒜，是對一個(gè)系統(tǒng)和它背后的研發(fā)運(yùn)營團(tuán)隊(duì)的真正挑戰(zhàn)。
相關(guān)推薦閱讀：
解密「云計(jì)算的太祖長拳」系列之一“膽”：基礎(chǔ)網(wǎng)絡(luò)改造與新架構(gòu)
從Google Maglev說起玄渗，如何造一個(gè)牛逼的負(fù)載均衡座菠？
本文由『UCloud基礎(chǔ)云計(jì)算研發(fā)團(tuán)隊(duì)』提供。
關(guān)于作者：
Y3（俞圓圓）藤树，UCloud基礎(chǔ)云計(jì)算研發(fā)中心總監(jiān)浴滴，負(fù)責(zé)超大規(guī)模的虛擬網(wǎng)絡(luò)及下一代NFV產(chǎn)品的架構(gòu)設(shè)計(jì)和研發(fā)。在大規(guī)模岁钓、企業(yè)級分布式系統(tǒng)升略、面向服務(wù)架構(gòu)微王、TCP/IP協(xié)議棧、數(shù)據(jù)中心網(wǎng)絡(luò)品嚣、云計(jì)算平臺的研發(fā)方面積累了大量的實(shí)戰(zhàn)經(jīng)驗(yàn)炕倘。曾經(jīng)分別供職于Microsoft Windows Azure和Amazon AWS EC2，歷任研發(fā)工程師翰撑，高級研發(fā)主管罩旋，首席軟件開發(fā)經(jīng)理，組建和帶領(lǐng)過實(shí)戰(zhàn)能力極強(qiáng)的研發(fā)團(tuán)隊(duì)眶诈。
「UCloud機(jī)構(gòu)號」將獨(dú)家分享云計(jì)算領(lǐng)域的技術(shù)洞見涨醋、行業(yè)資訊以及一切你想知道的相關(guān)訊息。
歡迎提問&求關(guān)注 o(*////▽////*)q～
以上逝撬。
本文轉(zhuǎn)載自：https://zhuanlan.zhihu.com/p/22435422
