“微軟的云產(chǎn)品Azure遍布在世界各地的22個超大規(guī)模的區(qū)域。Azure的存儲和計算每六個月就會翻一番，Azure每個月新增9萬用戶。世界500強(qiáng)中有百分之五十七的企業(yè)都在使用Azure，主機(jī)的數(shù)量迅速從10萬增長到幾百萬。”這是AzureCTO在2015opennetworkingsummit主題演講中透露的數(shù)據(jù)。
為了應(yīng)對快速增長的業(yè)務(wù)，Azure需要一個通過軟件交付的虛擬化的、可擴(kuò)展性網(wǎng)絡(luò)架構(gòu)。但是當(dāng)微軟在做這件事情的時候發(fā)現(xiàn)你幾乎不能以一個正常人的思維去詳細(xì)業(yè)務(wù)規(guī)模的增長，這樣一套對可擴(kuò)展性、靈活性以及具備快速交付能力的網(wǎng)絡(luò)系統(tǒng)需要自己從0開始。于是他們從頭開始寫了一整套AzureSDN的代碼。
微軟使用overlay技術(shù)和網(wǎng)絡(luò)功能虛擬化服務(wù)軟件構(gòu)建的虛擬網(wǎng)絡(luò)（Vnets）。Vnets通過Azure控制器進(jìn)行劃分，建立一組相互關(guān)聯(lián)的服務(wù)，每個服務(wù)再按規(guī)模劃分，并利用高可用性在多個實例上運行協(xié)議。控制器集群所在區(qū)域能夠部署10萬到50萬臺主機(jī)。在這些區(qū)域中，又存在小的控制器集群扮演著無狀態(tài)緩存器的角色，他們能夠控制1000臺主機(jī)。
微軟使用Azure內(nèi)部開發(fā)的ServiceFabric來構(gòu)建這些控制器。ServiceFabric有一個基于微服務(wù)的架構(gòu)，能夠讓客戶更新單個應(yīng)用程序組件，而無需更新整個應(yīng)用程序。
AzureSDN的可編程在硬件的協(xié)助下運行在主機(jī)服務(wù)器上。Hyper-V主機(jī)上的虛擬過濾平臺（VFP）能夠使Azure的數(shù)據(jù)平面在網(wǎng)絡(luò)代理中扮演Hyper-V的虛擬網(wǎng)絡(luò)可編程交換機(jī)的角色，網(wǎng)絡(luò)代理代表控制器完成Vnet功能和其他功能，如負(fù)載均衡。
數(shù)據(jù)包處理是在能夠?qū)zure的數(shù)據(jù)平面的規(guī)模從1Gbps擴(kuò)展到40Gbps的主機(jī)上進(jìn)行，這有助于保持客戶虛擬主機(jī)的CPU周期。
雖然SDN和開源攜手并進(jìn)，但在AzureSDN中并沒有開源軟件，因為在開源社區(qū)中沒有提供Azure需要的功能。而且就算有別的途徑可以滿足這些功能需求，轉(zhuǎn)換的成本也是相當(dāng)大的。微軟考慮將AzureServiceFabric架構(gòu)貢獻(xiàn)給開源社區(qū)，但需要建立一些合作關(guān)系。
構(gòu)造AzureSDN的一個挑戰(zhàn)在于將現(xiàn)有的控制器改裝到ServiceFabric，這導(dǎo)致了一些擴(kuò)展性問題，因為一些原始的控制器沒有使用ServiceFabric，所以并不是面向?qū)ο蟮摹?/p>
另一個挑戰(zhàn)是VFP如何處理數(shù)據(jù)包。我們需要確保在連接建立以后，對每個數(shù)據(jù)包的處理都是高效的。有效運作、迅速擴(kuò)展規(guī)模、迅速轉(zhuǎn)化功能和服務(wù)器的負(fù)載均衡都面臨挑戰(zhàn)，所以我們可以運行虛擬機(jī)。
AzureSDN接下來需要更多的爆炸式增長的微軟云。從客戶API的角度看，我們會在網(wǎng)絡(luò)層面得到更加豐富和強(qiáng)大的抽象。我們將在幾年內(nèi)看到10倍規(guī)模的AzureSDN。
