之所以要寫這樣的一篇博文的目的是對(duì)于大多數(shù)搞IT的人來說，一般都會(huì)對(duì)這個(gè)topic很感興趣，因?yàn)榈讓蛹軜?gòu)直接關(guān)乎到一個(gè)公有云平臺(tái)的performance，其實(shí)最主要的原因是我們的客戶對(duì)此也非常感興趣，畢竟很多客戶以前都是做網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)出身，他們對(duì)底層架構(gòu)的興趣甚至超過了Azure所提供的功能，基于以上原因，所以筆者感覺有必要初步分析一下Azure的底層架構(gòu)。

在分析Azure的底層架構(gòu)之前，我覺得有必要說一下Azure的所使用的硬件，其實(shí)在初期，Azure的cpu使用過AMD的，但是現(xiàn)在Azure的cpu都是Intel Xeon ?E系列，x86架構(gòu)，RS全部為cisco的設(shè)備，負(fù)載均衡器都為F5的

接下來我們來分析Azure的底層架構(gòu)，我們都知道，在傳統(tǒng)的網(wǎng)絡(luò)架構(gòu)中，我們都采用pod架構(gòu)，如下圖，這種架構(gòu)是基于L2來做的，先由接入層到核心層，核心層連路由網(wǎng)關(guān)，或者在中間有firewall

? ? ? ? ? ? ? ? ? ? ? ? ?

但是我們知道，這種傳統(tǒng)的基于大量二層+少量三層的架構(gòu)有致命的缺陷，就是stp與vlan的限制，我們知道交換機(jī)在處理廣播報(bào)文的方式是泛洪，為防止形成廣播風(fēng)暴，必須運(yùn)行stp來block掉某個(gè)端口，這樣就會(huì)有造成如下的缺點(diǎn)，低效的路徑，造成大量閑置帶寬，維護(hù)成本高昂，可靠性很低，在運(yùn)行stp的架構(gòu)中數(shù)據(jù)中心最多可接入百臺(tái)雙網(wǎng)卡服務(wù)器，遠(yuǎn)不能滿足大型數(shù)據(jù)中心的要求，第二點(diǎn)，就是傳統(tǒng)vlan的數(shù)量限制（4096個(gè)，遠(yuǎn)不能滿足數(shù)據(jù)中心的大規(guī)模組網(wǎng)），同時(shí)基于IP子網(wǎng)的區(qū)域劃分限制了需要二層連通性的應(yīng)用負(fù)載的部署，TOR交換機(jī)mac表耗盡，以及多租戶場景都無法滿足，此外虛擬化技術(shù)的發(fā)展，使得虛擬機(jī)在二層域的動(dòng)態(tài)遷移中顯得非常困難，以及收斂比等問題，這時(shí)就急需一種新的網(wǎng)絡(luò)架構(gòu)，fabric架構(gòu)應(yīng)運(yùn)而生

fabric架構(gòu)應(yīng)用了大量的新興的技術(shù)，實(shí)現(xiàn)了大二層，運(yùn)用了trill vxlan等技術(shù)，架構(gòu)圖如下

?

fabric架構(gòu)有相對(duì)于傳統(tǒng)的網(wǎng)絡(luò)架構(gòu)，fabric架構(gòu)將多臺(tái)物理的交換機(jī)看成一臺(tái)巨大的邏輯交換機(jī)，不受stp限制，互相之間都可以通信，節(jié)約物理鏈路的帶寬，優(yōu)化了收斂比，可以實(shí)現(xiàn)二三層飄移，同時(shí)沒有ARP廣播和未知單播泛洪等現(xiàn)象，像傳統(tǒng)的路由網(wǎng)絡(luò)一樣可以擴(kuò)展，任意服務(wù)器可以在任意vlan，vlan可以擴(kuò)展到全網(wǎng)， 任意位置都可以做任意vlan路由，同一vlan網(wǎng)關(guān)要一致，任意vlan內(nèi)和任意vlan之間都可以做類似三層路由的方式通信?，提供更靈活的拓?fù)?#xff0c;節(jié)點(diǎn)小型化，分布扁平化等優(yōu)點(diǎn) 。

以上就是筆者粗淺地對(duì)比了兩種架構(gòu)，有興趣的讀者可以自行百度，這里就不再展開細(xì)說，接下來我們重點(diǎn)來看Azure的底層架構(gòu)，并且這里隱去RS部分，只看計(jì)算單元，首先附上兩張圖，第一張是Azure的計(jì)算單元的實(shí)物圖，另一張是本人手繪的Azure的計(jì)算單元圖，廢話不多說，上圖

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?實(shí)物圖

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 手繪圖 ?

Azure是將計(jì)算單元分成一個(gè)個(gè)獨(dú)立的cluster，在這里筆者想提醒一句，在老的portal里面，以前有一個(gè)地緣組的概念affinity group，很多人不明白這一概念，以為只是中國東部數(shù)據(jù)中心和中國北部數(shù)據(jù)中心的別名，這一認(rèn)識(shí)是完全錯(cuò)誤的，地緣組的概念其實(shí)不是這樣，在我們的Azure數(shù)據(jù)中心內(nèi)部，是由若干個(gè)容器組成，每個(gè)容器包含了群集/機(jī)架，每個(gè)容器都有特定的服務(wù)與功能，包括計(jì)算和存儲(chǔ)，舉個(gè)例子來說，當(dāng)你建了一臺(tái)vm，然后你又給該vm建立了存儲(chǔ)賬戶，假如我們?cè)诮⑦@兩個(gè)服務(wù)的時(shí)候計(jì)算資源放在數(shù)據(jù)中心的內(nèi)部，而存儲(chǔ)資源放到了數(shù)據(jù)中心外圍，顯而易見這不是我們想預(yù)見的結(jié)果，最好的結(jié)果是能放在同一數(shù)據(jù)中心比較靠近的位置，最好能在同一群集里，所以就有了地緣組的概念，放在同一地緣組的云資源會(huì)放在同一數(shù)據(jù)中心比較靠近的地方，甚至同一個(gè)群集里，這樣的好處是能夠降低時(shí)延，但是Azure已經(jīng)逐步淡化這一概念，在這里筆者只是想提醒大家一下，以后再碰到這個(gè)概念不要混淆。

從上面的圖中我們可以看出，一個(gè)cluster中包含了20個(gè)chassis，每個(gè)chassis有96臺(tái)機(jī)器，每個(gè)chassis上都有幾臺(tái)SLB，在以前，Azure的SLB（負(fù)載均衡器）都由虛擬機(jī)來做，但是后來微軟發(fā)現(xiàn)用虛擬機(jī)來做SLB性能并不理想，所以全部用物理機(jī)來做，在SLB外面附著一些VIP（在這里你可以將它看成一個(gè)SLB的公網(wǎng)IP地址，關(guān)于Azure的幾種IP地址，筆者會(huì)在后續(xù)的博文中詳細(xì)介紹，這里先不展開敘述），每個(gè)chassis上面還有一個(gè)FC（Fabric Controller），管理這個(gè)chassis上資源的分配，千萬不要小看它，它是一個(gè)chassis的核心部位，每個(gè)chassis上包含了不同類別的虛擬機(jī)，可能有只有A系列的虛擬機(jī)，如A0-A4或者A1-A7，也或者包括了D系列，Dv2系列虛擬機(jī)，甚至還有F系列虛擬機(jī)（G系列與H系列虛擬機(jī)在國內(nèi)仍沒有preview，只有g(shù)lobal賬戶才能建立）。

但是我們會(huì)發(fā)現(xiàn)一個(gè)重要的問題，并不是每個(gè)chassis上都包含所有系列的虛擬機(jī)，有的甚至只有A0—A4或者A1—A7的虛擬機(jī)（這都是Azure初建數(shù)據(jù)中心的老的chassis，現(xiàn)在可能只有很少的一部分了），還記得在上面的博客中筆者提醒大家在建虛擬機(jī)的時(shí)候先建立D系列虛擬機(jī)，然后再降為A系列虛擬機(jī)，就是這個(gè)原因造成的，當(dāng)我們?cè)诮m的時(shí)候，FC會(huì)去看哪個(gè)chassis上的資源比較閑置，然后扔給最不忙的那個(gè)chassis ，如果你先選建立一個(gè)A系列虛擬機(jī)，FC有可能碰巧將它扔在了某個(gè)只有A系列虛擬機(jī)的chassis上，等你再想做縱向擴(kuò)展的時(shí)候會(huì)發(fā)現(xiàn)虛擬機(jī)不能D系列了，就是這個(gè)原因造成的，所以我竭力建議大家先建高配的虛擬機(jī)，然后再降為低配的虛擬機(jī)。?

但是就是這樣就結(jié)束了嘛，其實(shí)遠(yuǎn)不是這樣，其實(shí)在Azure最老某些的cluster里面只有A系列虛擬機(jī)，這就相當(dāng)可怕了，因?yàn)檫@樣你不僅不能縱向擴(kuò)展，也不能橫向擴(kuò)展，為什么？所謂橫向擴(kuò)展就是建立可用性集，然后將多臺(tái)虛機(jī)加入同一可用性集，以實(shí)現(xiàn)HA，同一可用性集的虛擬機(jī)的意思就是在同一cluster而不在同一chassis上面，這樣既提供高可用有提供了冗余（不在同一chassis的目的是為了防止該chassis出問題而導(dǎo)致整個(gè)可用性集里的虛擬機(jī)全部掛掉），但是你整個(gè)cluster里面都只有A系列虛擬機(jī)，那你橫向擴(kuò)展只能擴(kuò)展多臺(tái)A系列虛擬機(jī)，這就是某些客戶碰到的問題，說先建立了某兩臺(tái)A系列的虛擬機(jī)，并且加入了某個(gè)可用性集，但是后來發(fā)現(xiàn)再建了一臺(tái)D系列的虛擬機(jī)不能加入這個(gè)可用性集了，就是這個(gè)原因造成的，因?yàn)槟莾膳_(tái)虛擬機(jī)很有可能被扔進(jìn)了某個(gè)只有A系列的虛擬機(jī)的cluster里造成的，但是反過來如果我們先建立一臺(tái)D系列虛擬機(jī)，并且加入某個(gè)可用性集，再去A系列虛擬機(jī)加入該可用性集，這樣就一定不會(huì)出問題，因?yàn)榈谝慌_(tái)D系列虛擬機(jī)決定了你的cluster，這句話一定要理解，所以我們?cè)诮⑻摂M機(jī)的時(shí)候一定要記得先建立高配置的虛擬機(jī)，然后再降為低配的！！！

?

轉(zhuǎn)載于:https://www.cnblogs.com/chenjie520/p/6169208.html

總結(jié)

以上是生活随笔為你收集整理的Azure底层架构的初步分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。