掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
作者: 多顆糖 2021-10-19 09:32:08
云計算
云原生 如果應(yīng)用一層不變,那我們就沒有必要進(jìn)行討論了。我們談云原生數(shù)據(jù)中心網(wǎng)絡(luò),那這個架構(gòu)就是要為現(xiàn)代云原生應(yīng)用而設(shè)計的。所以,現(xiàn)代云原生應(yīng)用有什么特點?

干我們這行免不了要閱讀大量資料,但這個行業(yè)又存在大量細(xì)分的領(lǐng)域,我們的時間是有限的,現(xiàn)代人能投入讀書的時間更是少之又少,一個問題是我們到底應(yīng)該深入閱讀還是廣泛閱讀?
最近讀到 Shopify 某個開發(fā)團(tuán)隊前負(fù)責(zé)人 Simon Eskildsen 的采訪[1]。Simon Eskildsen 只是一個高中生,卻在 gap year 加入創(chuàng)業(yè)期的 Shopify 并跟隨公司一同成長為技術(shù)管理者。沒有任何學(xué)位的他表示,自己是靠著大量閱讀來學(xué)習(xí)計算機(jī)和管理的知識。Simon Eskildsen 在采訪中提到自己努力成為T 型人才:在一個領(lǐng)域深入,但在多個領(lǐng)域有廣博的知識面。
之前的文章中,我們聊過分布式計算、存儲、協(xié)調(diào)等主題,唯獨網(wǎng)絡(luò)方面沒有談過。在《SRE:Google運維解密》中有一句令我影響深刻的話:“UNIX 系統(tǒng)內(nèi)部細(xì)節(jié)和1~3層網(wǎng)絡(luò)知識是Google最看重的兩類額外的技術(shù)能力?!?/p>
本身我的網(wǎng)絡(luò)知識也比較薄弱,恰好最近工作設(shè)計一些網(wǎng)絡(luò)架構(gòu)相關(guān)的知識,于是從10月開始我停了下來,開始閱讀一些現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)的知識。讀者可以和我一起思考,如果新的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)讓你來設(shè)計,你會怎么做?
這在 O'REILLY 的新書《Cloud Native Data Center Networking》(中文《云原生數(shù)據(jù)中心網(wǎng)絡(luò)》)中有解答。我本來讀的原版,可是沒法理解書中一些英文網(wǎng)絡(luò)詞匯。最近中文版出版,正好找來對照著讀一下,并記此筆記。
如果應(yīng)用一層不變,那我們就沒有必要進(jìn)行討論了。我們談云原生數(shù)據(jù)中心網(wǎng)絡(luò),那這個架構(gòu)就是要為現(xiàn)代云原生應(yīng)用而設(shè)計的。所以,現(xiàn)代云原生應(yīng)用有什么特點?
書中提到,“應(yīng)用-網(wǎng)絡(luò)”架構(gòu)的演進(jìn)經(jīng)歷了如下圖的四個階段。
1.單體應(yīng)用
2.客戶端-服務(wù)器(C/S)架構(gòu)
3.Web 應(yīng)用
4.微服務(wù)
可見,分布式應(yīng)用發(fā)生巨變,網(wǎng)絡(luò)被打了個措手不及。傳統(tǒng)網(wǎng)絡(luò)為什么“跟不上節(jié)奏”?
上圖是傳統(tǒng)網(wǎng)絡(luò),這種網(wǎng)絡(luò)設(shè)計被稱為“接入-匯聚-核心(access-aggregation-core)”架構(gòu)。計算機(jī)連接到接入交換機(jī),之上是一對分布式的匯聚交換機(jī),匯聚交換機(jī)連接到核心網(wǎng)絡(luò),從而使接入層連接到外網(wǎng)。
“接入-匯聚-核心”網(wǎng)絡(luò)嚴(yán)重依賴于橋接(Bridging)技術(shù),原因有三:
路由和橋接的區(qū)別:橋接工作在 OSI 網(wǎng)絡(luò)模型第二層即鏈路層,交換機(jī)或網(wǎng)橋根據(jù) MAC 地址來交換數(shù)據(jù),鏈路層交換的是數(shù)據(jù)幀(frame)。路由工作在 OSI 第三層即網(wǎng)絡(luò)層,路由器根據(jù) IP 地址來找到目標(biāo)地址,網(wǎng)絡(luò)層交換的是數(shù)據(jù)包。
盡管傳統(tǒng)網(wǎng)絡(luò)取得很大成功,但橋接網(wǎng)絡(luò)依然有以下限制:
在轉(zhuǎn)發(fā)網(wǎng)絡(luò)中,每個數(shù)據(jù)包都攜帶兩個 MAC 地址:源地址和目標(biāo)地址。網(wǎng)橋會在自身的 MAC 地址表中查找目標(biāo) MAC 地址。如果不知道,它將數(shù)據(jù)包發(fā)送到除接收數(shù)據(jù)包的接口以外的所有其他接口。當(dāng)網(wǎng)橋在自身的 MAC 地址表中找不到待轉(zhuǎn)發(fā)數(shù)據(jù)包的目的 MAC 地址,而向所有端口發(fā)送該數(shù)據(jù)包的行為稱為泛洪(flooding)。
“接入-匯聚-核心”很適合客戶端-服務(wù)器應(yīng)用架構(gòu)這種南北向流量為主的模式,如今服務(wù)器-服務(wù)器架構(gòu)越來越多,應(yīng)用規(guī)模顯著變大,“接入-匯聚-核心”存在以下問題:
1.不可擴(kuò)展性
2.復(fù)雜性。橋接網(wǎng)絡(luò)需要很多協(xié)議支持:STP、FHRP、鏈路失效偵測、供應(yīng)商私有協(xié)議(如 VTP)
3.失效域(Failure Domain)。容易發(fā)生粗粒度的失效,比如:單個鏈路的失效造成帶寬減半
4.不可預(yù)測性。許多組件會導(dǎo)致網(wǎng)絡(luò)變得不可預(yù)測,增加故障定位難度
缺乏敏捷。云計算領(lǐng)域,不停地有租戶使用資源或銷毀資源,而 VLAN 需要網(wǎng)絡(luò)中每個節(jié)點都正確配置了 VLAN 信息才能正常工作,添加或移除 VLAN 是一個費時費力的過程。
橋接技術(shù)的支持者沒有放棄,針對這些問題提出了許多解決方案,但在當(dāng)代企業(yè)數(shù)據(jù)中心少有使用。
云原生數(shù)據(jù)中心基礎(chǔ)設(shè)施想建立一個可大規(guī)模擴(kuò)展的網(wǎng)絡(luò)架構(gòu),Clos 就是這個架構(gòu)。
Clos 拓?fù)浣Y(jié)構(gòu)以其發(fā)明者 Charles Clos 命名,如下圖所示,該拓?fù)湟卜Q為 leaf-spine 拓?fù)?或 spine-leaf 架構(gòu))。
上圖中:
Clos 拓?fù)湓谌魏蝺膳_服務(wù)器之間都有兩條以上的路徑,產(chǎn)生了一個高容量網(wǎng)絡(luò)支持東西向流量。對比傳統(tǒng)網(wǎng)絡(luò),Clos 架構(gòu)還有著很好的水平擴(kuò)展性:
而“接入-匯聚-核心”只能換成性能更強(qiáng)的匯聚交換機(jī)來進(jìn)行垂直擴(kuò)展。
1.Clos 架構(gòu)還有以下特性:
2.leaf、spine 可以使用同類、較小的交換機(jī)來構(gòu)建網(wǎng)絡(luò)
路由作為基本的互連模式
Clos 不使用STP,只在單個機(jī)架內(nèi)直接支持橋接,跨機(jī)架橋接使用更現(xiàn)代的網(wǎng)絡(luò)虛擬化解決方案(例如VXLAN)
3.Clos 收斂比
1:1 收斂比的網(wǎng)絡(luò)也稱為非阻塞網(wǎng)絡(luò),即上行鏈路帶寬等于下行鏈路帶寬。如果 spine 和 leaf 都是 n 口交換機(jī),1:1 收斂比的 Clos 拓?fù)淇蛇B接的最大服務(wù)器數(shù)量為 n^2/2
4.鏈路速率
如果交換機(jī)鏈路使用比服務(wù)器鏈路更高的速率,則可以用更少的 spine 交換機(jī)來支持相同的收斂比
5.一些現(xiàn)實的限制
受到制冷、機(jī)柜、散熱、服務(wù)器擺放等限制,以上理論并不能原封不動落實到數(shù)據(jù)中心,單個機(jī)柜一般是20或40臺服務(wù)器。導(dǎo)致spine端口數(shù)量較多而leaf端口數(shù)量較少,設(shè)備廠商一般會提供不同的spine和leaf交換機(jī)
6.細(xì)粒度失效域
如果你想要構(gòu)建一個支持?jǐn)?shù)萬或數(shù)十萬臺服務(wù)器的超大數(shù)據(jù)中心,還要拓展出三層 Clos 拓?fù)洌缦聢D所示,有兩種擴(kuò)展方法:
拓展后的三層 Clos 拓?fù)渥钌蠈咏粨Q機(jī)稱為“超級 spine 交換機(jī)”。
兩種模型的優(yōu)缺點對比:
Clos 拓?fù)浣Y(jié)構(gòu)帶來如下影響:
Clos 拓?fù)涞囊恍﹥?yōu)秀實踐:
書中提到,LinkedIn 和 Dropbox 就后悔使用不一致的交換機(jī)。
本文轉(zhuǎn)載自微信公眾號「多顆糖」,可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系多顆糖公眾號。

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流