之所以要寫這樣的一篇博文的目的是對於大多數搞IT的人來說，一般都會對這個topic很感興趣，因為底層架構直接關乎到一個公有雲平台的performance，其實最主要的原因是我們的客戶對此也非常感興趣，畢竟很多客戶以前都是做網絡存儲系統出身，他們對底層架構的興趣甚至超過了Azure所提供的功能，基於以上原因，所以筆者感覺有必要初步分析一下Azure的底層架構。
在分析Azure的底層架構之前，我覺得有必要說一下Azure的所使用的硬件，其實在初期，Azure的cpu使用過AMD的，但是現在Azure的cpu都是Intel Xeon E系列，x86架構，RS全部為cisco的設備，負載均衡器都為F5的
接下來我們來分析Azure的底層架構，我們都知道，在傳統的網絡架構中，我們都采用pod架構，如下圖，這種架構是基於L2來做的，先由接入層到核心層，核心層連路由網關，或者在中間有firewall
但是我們知道，這種傳統的基於大量二層+少量三層的架構有致命的缺陷，就是stp與vlan的限制，我們知道交換機在處理廣播報文的方式是泛洪，為防止形成廣播風暴，必須運行stp來block掉某個端口，這樣就會有造成如下的缺點，低效的路徑，造成大量閑置帶寬，維護成本高昂，可靠性很低，在運行stp的架構中數據中心最多可接入百台雙網卡服務器，遠不能滿足大型數據中心的要求，第二點，就是傳統vlan的數量限制（4096個，遠不能滿足數據中心的大規模組網），同時基於IP子網的區域划分限制了需要二層連通性的應用負載的部署，TOR交換機mac表耗盡，以及多租戶場景都無法滿足，此外虛擬化技術的發展，使得虛擬機在二層域的動態遷移中顯得非常困難，以及收斂比等問題，這時就急需一種新的網絡架構，fabric架構應運而生
fabric架構應用了大量的新興的技術，實現了大二層，運用了trill vxlan等技術，架構圖如下
fabric架構有相對於傳統的網絡架構，fabric架構將多台物理的交換機看成一台巨大的邏輯交換機，不受stp限制，互相之間都可以通信，節約物理鏈路的帶寬，優化了收斂比，可以實現二三層飄移，同時沒有ARP廣播和未知單播泛洪等現象，像傳統的路由網絡一樣可以擴展，任意服務器可以在任意vlan，vlan可以擴展到全網， 任意位置都可以做任意vlan路由，同一vlan網關要一致，任意vlan內和任意vlan之間都可以做類似三層路由的方式通信 ，提供更靈活的拓撲，節點小型化，分布扁平化等優點 。
以上就是筆者粗淺地對比了兩種架構，有興趣的讀者可以自行百度，這里就不再展開細說，接下來我們重點來看Azure的底層架構，並且這里隱去RS部分，只看計算單元，首先附上兩張圖，第一張是Azure的計算單元的實物圖，另一張是本人手繪的Azure的計算單元圖，廢話不多說，上圖
實物圖
手繪圖
Azure是將計算單元分成一個個獨立的cluster，在這里筆者想提醒一句，在老的portal里面，以前有一個地緣組的概念affinity group，很多人不明白這一概念，以為只是中國東部數據中心和中國北部數據中心的別名，這一認識是完全錯誤的，地緣組的概念其實不是這樣，在我們的Azure數據中心內部，是由若干個容器組成，每個容器包含了群集/機架，每個容器都有特定的服務與功能，包括計算和存儲，舉個例子來說，當你建了一台vm，然后你又給該vm建立了存儲賬戶，假如我們在建立這兩個服務的時候計算資源放在數據中心的內部，而存儲資源放到了數據中心外圍，顯而易見這不是我們想預見的結果，最好的結果是能放在同一數據中心比較靠近的位置，最好能在同一群集里，所以就有了地緣組的概念，放在同一地緣組的雲資源會放在同一數據中心比較靠近的地方，甚至同一個群集里，這樣的好處是能夠降低時延，但是Azure已經逐步淡化這一概念，在這里筆者只是想提醒大家一下，以后再碰到這個概念不要混淆。
從上面的圖中我們可以看出，一個cluster中包含了20個chassis，每個chassis有96台機器，每個chassis上都有幾台SLB，在以前，Azure的SLB（負載均衡器）都由虛擬機來做，但是后來微軟發現用虛擬機來做SLB性能並不理想，所以全部用物理機來做，在SLB外面附着一些VIP（在這里你可以將它看成一個SLB的公網IP地址，關於Azure的幾種IP地址，筆者會在后續的博文中詳細介紹，這里先不展開敘述），每個chassis上面還有一個FC（Fabric Controller），管理這個chassis上資源的分配，千萬不要小看它，它是一個chassis的核心部位，每個chassis上包含了不同類別的虛擬機，可能有只有A系列的虛擬機，如A0-A4或者A1-A7，也或者包括了D系列，Dv2系列虛擬機，甚至還有F系列虛擬機（G系列與H系列虛擬機在國內仍沒有preview，只有global賬戶才能建立）。
但是我們會發現一個重要的問題，並不是每個chassis上都包含所有系列的虛擬機，有的甚至只有A0—A4或者A1—A7的虛擬機（這都是Azure初建數據中心的老的chassis，現在可能只有很少的一部分了），還記得在上面的博客中筆者提醒大家在建虛擬機的時候先建立D系列虛擬機，然后再降為A系列虛擬機，就是這個原因造成的，當我們在建立vm的時候，FC會去看哪個chassis上的資源比較閑置，然后扔給最不忙的那個chassis ，如果你先選建立一個A系列虛擬機，FC有可能碰巧將它扔在了某個只有A系列虛擬機的chassis上，等你再想做縱向擴展的時候會發現虛擬機不能D系列了，就是這個原因造成的，所以我竭力建議大家先建高配的虛擬機，然后再降為低配的虛擬機。
但是就是這樣就結束了嘛，其實遠不是這樣，其實在Azure最老某些的cluster里面只有A系列虛擬機，這就相當可怕了，因為這樣你不僅不能縱向擴展，也不能橫向擴展，為什么？所謂橫向擴展就是建立可用性集，然后將多台虛機加入同一可用性集，以實現HA，同一可用性集的虛擬機的意思就是在同一cluster而不在同一chassis上面，這樣既提供高可用有提供了冗余（不在同一chassis的目的是為了防止該chassis出問題而導致整個可用性集里的虛擬機全部掛掉），但是你整個cluster里面都只有A系列虛擬機，那你橫向擴展只能擴展多台A系列虛擬機，這就是某些客戶碰到的問題，說先建立了某兩台A系列的虛擬機，並且加入了某個可用性集，但是后來發現再建了一台D系列的虛擬機不能加入這個可用性集了，就是這個原因造成的，因為那兩台虛擬機很有可能被扔進了某個只有A系列的虛擬機的cluster里造成的，但是反過來如果我們先建立一台D系列虛擬機，並且加入某個可用性集，再去A系列虛擬機加入該可用性集，這樣就一定不會出問題，因為第一台D系列虛擬機決定了你的cluster，這句話一定要理解，所以我們在建立虛擬機的時候一定要記得先建立高配置的虛擬機，然后再降為低配的！！！