一、LVS簡(jiǎn)介
LVS（Linux Virtual Server）即Linux虛擬服務(wù)器，是由章文嵩博士主導(dǎo)的開(kāi)源負(fù)載均衡項(xiàng)目，目前LVS已經(jīng)被集成到Linux內(nèi)核模塊中。該項(xiàng)目在Linux內(nèi)核中實(shí)現(xiàn)了基于IP的數(shù)據(jù)請(qǐng)求負(fù)載均衡調(diào)度方案，其體系結(jié)構(gòu)如圖1所示，終端互聯(lián)網(wǎng)用戶從外部訪問(wèn)公司的外部負(fù)載均衡服務(wù)器，終端用戶的Web請(qǐng)求會(huì)發(fā)送給LVS調(diào)度器，調(diào)度器根據(jù)自己預(yù)設(shè)的算法決定將該請(qǐng)求發(fā)送給后端的某臺(tái)Web服務(wù)器，比如，輪詢算法可以將外部的請(qǐng)求平均分發(fā)給后端的所有服務(wù)器，終端用戶訪問(wèn)LVS調(diào)度器雖然會(huì)被轉(zhuǎn)發(fā)到后端真實(shí)的服務(wù)器，但如果真實(shí)服務(wù)器連接的是相同的存儲(chǔ)，提供的服務(wù)也是相同的服務(wù)，最終用戶不管是訪問(wèn)哪臺(tái)真實(shí)服務(wù)器，得到的服務(wù)內(nèi)容都是一樣的，整個(gè)集群對(duì)用戶而言都是透明的。最后根據(jù)LVS工作模式的不同，真實(shí)服務(wù)器會(huì)選擇不同的方式將用戶需要的數(shù)據(jù)發(fā)送到終端用戶，LVS工作模式分為NAT模式、TUN模式、以及DR模式。
二、三種工作模式的解析。
1、基于NAT的LVS模式負(fù)載均衡
NAT（Network Address Translation）即網(wǎng)絡(luò)地址轉(zhuǎn)換，其作用是通過(guò)數(shù)據(jù)報(bào)頭的修改，使得位于企業(yè)內(nèi)部的私有IP地址可以訪問(wèn)外網(wǎng)，以及外部用用戶可以訪問(wèn)位于公司內(nèi)部的私有IP主機(jī)。VS/NAT工作模式拓?fù)浣Y(jié)構(gòu)如圖2所示，LVS負(fù)載調(diào)度器可以使用兩塊網(wǎng)卡配置不同的IP地址，eth0設(shè)置為私鑰IP與內(nèi)部網(wǎng)絡(luò)通過(guò)交換設(shè)備相互連接，eth1設(shè)備為外網(wǎng)IP與外部網(wǎng)絡(luò)聯(lián)通。
第一步，用戶通過(guò)互聯(lián)網(wǎng)DNS服務(wù)器解析到公司負(fù)載均衡設(shè)備上面的外網(wǎng)地址，相對(duì)于真實(shí)服務(wù)器而言，LVS外網(wǎng)IP又稱VIP（Virtual IP Address），用戶通過(guò)訪問(wèn)VIP，即可連接后端的真實(shí)服務(wù)器（Real Server），而這一切對(duì)用戶而言都是透明的，用戶以為自己訪問(wèn)的就是真實(shí)服務(wù)器，但他并不知道自己訪問(wèn)的VIP僅僅是一個(gè)調(diào)度器，也不清楚后端的真實(shí)服務(wù)器到底在哪里、有多少真實(shí)服務(wù)器。
第二步，用戶將請(qǐng)求發(fā)送至124.126.147.168，此時(shí)LVS將根據(jù)預(yù)設(shè)的算法選擇后端的一臺(tái)真實(shí)服務(wù)器（192.168.0.1~192.168.0.3），將數(shù)據(jù)請(qǐng)求包轉(zhuǎn)發(fā)給真實(shí)服務(wù)器，并且在轉(zhuǎn)發(fā)之前LVS會(huì)修改數(shù)據(jù)包中的目標(biāo)地址以及目標(biāo)端口，目標(biāo)地址與目標(biāo)端口將被修改為選出的真實(shí)服務(wù)器IP地址以及相應(yīng)的端口。
第三步，真實(shí)的服務(wù)器將響應(yīng)數(shù)據(jù)包返回給LVS調(diào)度器，調(diào)度器在得到響應(yīng)的數(shù)據(jù)包后會(huì)將源地址和源端口修改為VIP及調(diào)度器相應(yīng)的端口，修改完成后，由調(diào)度器將響應(yīng)數(shù)據(jù)包發(fā)送回終端用戶，另外，由于LVS調(diào)度器有一個(gè)連接Hash表，該表中會(huì)記錄連接請(qǐng)求及轉(zhuǎn)發(fā)信息，當(dāng)同一個(gè)連接的下一個(gè)數(shù)據(jù)包發(fā)送給調(diào)度器時(shí)，從該Hash表中可以直接找到之前的連接記錄，并根據(jù)記錄信息選出相同的真實(shí)服務(wù)器及端口信息。
2、基于TUN的LVS負(fù)載均衡
在LVS（NAT）模式的集群環(huán)境中，由于所有的數(shù)據(jù)請(qǐng)求及響應(yīng)的數(shù)據(jù)包都需要經(jīng)過(guò)LVS調(diào)度器轉(zhuǎn)發(fā)，如果后端服務(wù)器的數(shù)量大于10臺(tái)，則調(diào)度器就會(huì)成為整個(gè)集群環(huán)境的瓶頸。我們知道，數(shù)據(jù)請(qǐng)求包往往遠(yuǎn)小于響應(yīng)數(shù)據(jù)包的大小。因?yàn)轫憫?yīng)數(shù)據(jù)包中包含有客戶需要的具體數(shù)據(jù)，所以LVS（TUN）的思路就是將請(qǐng)求與響應(yīng)數(shù)據(jù)分離，讓調(diào)度器僅處理數(shù)據(jù)請(qǐng)求，而讓真實(shí)服務(wù)器響應(yīng)數(shù)據(jù)包直接返回給客戶端。VS/TUN工作模式拓?fù)浣Y(jié)構(gòu)如圖3所示。其中，IP隧道（IP tunning）是一種數(shù)據(jù)包封裝技術(shù)，它可以將原始數(shù)據(jù)包封裝并添加新的包頭（內(nèi)容包括新的源地址及端口、目標(biāo)地址及端口），從而實(shí)現(xiàn)將一個(gè)目標(biāo)為調(diào)度器的VIP地址的數(shù)據(jù)包封裝，通過(guò)隧道轉(zhuǎn)發(fā)給后端的真實(shí)服務(wù)器（Real Server），通過(guò)將客戶端發(fā)往調(diào)度器的原始數(shù)據(jù)包封裝，并在其基礎(chǔ)上添加新的數(shù)據(jù)包頭（修改目標(biāo)地址為調(diào)度器選擇出來(lái)的真實(shí)服務(wù)器的IP地址及對(duì)應(yīng)端口），LVS（TUN）模式要求真實(shí)服務(wù)器可以直接與外部網(wǎng)絡(luò)連接，真實(shí)服務(wù)器在收到請(qǐng)求數(shù)據(jù)包后直接給客戶端主機(jī)響應(yīng)數(shù)據(jù)。
3、基于DR的LVS負(fù)載均衡
在LVS（TUN）模式下，由于需要在LVS調(diào)度器與真實(shí)服務(wù)器之間創(chuàng)建隧道連接，這同樣會(huì)增加服務(wù)器的負(fù)擔(dān)。與LVS（TUN）類似，DR模式也叫直接路由模式，其體系結(jié)構(gòu)如圖4所示，該模式中LVS依然僅承擔(dān)數(shù)據(jù)的入站請(qǐng)求以及根據(jù)算法選出合理的真實(shí)服務(wù)器，最終由后端真實(shí)服務(wù)器負(fù)責(zé)將響應(yīng)數(shù)據(jù)包發(fā)送返回給客戶端。與隧道模式不同的是，直接路由模式（DR模式）要求調(diào)度器與后端服務(wù)器必須在同一個(gè)局域網(wǎng)內(nèi)，VIP地址需要在調(diào)度器與后端所有的服務(wù)器間共享，因?yàn)樽罱K的真實(shí)服務(wù)器給客戶端回應(yīng)數(shù)據(jù)包時(shí)需要設(shè)置源IP為VIP地址，目標(biāo)IP為客戶端IP，這樣客戶端訪問(wèn)的是調(diào)度器的VIP地址，回應(yīng)的源地址也依然是該VIP地址（真實(shí)服務(wù)器上的VIP），客戶端是感覺(jué)不到后端服務(wù)器存在的。由于多臺(tái)計(jì)算機(jī)都設(shè)置了同樣一個(gè)VIP地址，所以在直接路由模式中要求調(diào)度器的VIP地址是對(duì)外可見(jiàn)的，客戶端需要將請(qǐng)求數(shù)據(jù)包發(fā)送到調(diào)度器主機(jī)，而所有的真實(shí)服務(wù)器的VIP地址必須配置在Non-ARP的網(wǎng)絡(luò)設(shè)備上，也就是該網(wǎng)絡(luò)設(shè)備并不會(huì)向外廣播自己的MAC及對(duì)應(yīng)的IP地址，真實(shí)服務(wù)器的VIP對(duì)外界是不可見(jiàn)的，但真實(shí)服務(wù)器卻可以接受目標(biāo)地址VIP的網(wǎng)絡(luò)請(qǐng)求，并在回應(yīng)數(shù)據(jù)包時(shí)將源地址設(shè)置為該VIP地址。調(diào)度器根據(jù)算法在選出真實(shí)服務(wù)器后，在不修改數(shù)據(jù)報(bào)文的情況下，將數(shù)據(jù)幀的MAC地址修改為選出的真實(shí)服務(wù)器的MAC地址，通過(guò)交換機(jī)將該數(shù)據(jù)幀發(fā)給真實(shí)服務(wù)器。整個(gè)過(guò)程中，真實(shí)服務(wù)器的VIP不需要對(duì)外界可見(jiàn)。
三、LVS負(fù)載均衡調(diào)度算法
根據(jù)前面的介紹，我們了解了LVS的三種工作模式，但不管實(shí)際環(huán)境中采用的是哪種模式，調(diào)度算法進(jìn)行調(diào)度的策略與算法都是LVS的核心技術(shù)，LVS在內(nèi)核中主要實(shí)現(xiàn)了一下十種調(diào)度算法。
1.輪詢調(diào)度
輪詢調(diào)度（Round Robin 簡(jiǎn)稱'RR'）算法就是按依次循環(huán)的方式將請(qǐng)求調(diào)度到不同的服務(wù)器上，該算法最大的特點(diǎn)就是實(shí)現(xiàn)簡(jiǎn)單。輪詢算法假設(shè)所有的服務(wù)器處理請(qǐng)求的能力都一樣的，調(diào)度器會(huì)將所有的請(qǐng)求平均分配給每個(gè)真實(shí)服務(wù)器。
2.加權(quán)輪詢調(diào)度
加權(quán)輪詢（Weight Round Robin 簡(jiǎn)稱'WRR'）算法主要是對(duì)輪詢算法的一種優(yōu)化與補(bǔ)充，LVS會(huì)考慮每臺(tái)服務(wù)器的性能，并給每臺(tái)服務(wù)器添加一個(gè)權(quán)值，如果服務(wù)器A的權(quán)值為1，服務(wù)器B的權(quán)值為2，則調(diào)度器調(diào)度到服務(wù)器B的請(qǐng)求會(huì)是服務(wù)器A的兩倍。權(quán)值越高的服務(wù)器，處理的請(qǐng)求越多。
3.最小連接調(diào)度
最小連接調(diào)度（Least Connections 簡(jiǎn)稱'LC'）算法是把新的連接請(qǐng)求分配到當(dāng)前連接數(shù)最小的服務(wù)器。最小連接調(diào)度是一種動(dòng)態(tài)的調(diào)度算法，它通過(guò)服務(wù)器當(dāng)前活躍的連接數(shù)來(lái)估計(jì)服務(wù)器的情況。調(diào)度器需要記錄各個(gè)服務(wù)器已建立連接的數(shù)目，當(dāng)一個(gè)請(qǐng)求被調(diào)度到某臺(tái)服務(wù)器，其連接數(shù)加1；當(dāng)連接中斷或者超時(shí)，其連接數(shù)減1。
（集群系統(tǒng)的真實(shí)服務(wù)器具有相近的系統(tǒng)性能，采用最小連接調(diào)度算法可以比較好地均衡負(fù)載。)
4.加權(quán)最小連接調(diào)度
加權(quán)最少連接（Weight Least Connections 簡(jiǎn)稱'WLC'）算法是最小連接調(diào)度的超集，各個(gè)服務(wù)器相應(yīng)的權(quán)值表示其處理性能。服務(wù)器的缺省權(quán)值為1，系統(tǒng)管理員可以動(dòng)態(tài)地設(shè)置服務(wù)器的權(quán)值。加權(quán)最小連接調(diào)度在調(diào)度新連接時(shí)盡可能使服務(wù)器的已建立連接數(shù)和其權(quán)值成比例。調(diào)度器可以自動(dòng)問(wèn)詢真實(shí)服務(wù)器的負(fù)載情況，并動(dòng)態(tài)地調(diào)整其權(quán)值。
5.基于局部的最少連接
基于局部的最少連接調(diào)度（Locality-Based Least Connections 簡(jiǎn)稱'LBLC'）算法是針對(duì)請(qǐng)求報(bào)文的目標(biāo)IP地址的 負(fù)載均衡調(diào)度，目前主要用于Cache集群系統(tǒng)，因?yàn)樵贑ache集群客戶請(qǐng)求報(bào)文的目標(biāo)IP地址是變化的。這里假設(shè)任何后端服務(wù)器都可以處理任一請(qǐng)求，算法的設(shè)計(jì)目標(biāo)是在服務(wù)器的負(fù)載基本平衡情況下，將相同目標(biāo)IP地址的請(qǐng)求調(diào)度到同一臺(tái)服務(wù)器，來(lái)提高各臺(tái)服務(wù)器的訪問(wèn)局部性和Cache命中率，從而提升整個(gè)集群系統(tǒng)的處理能力。LBLC調(diào)度算法先根據(jù)請(qǐng)求的目標(biāo)IP地址找出該目標(biāo)IP地址最近使用的服務(wù)器，若該服務(wù)器是可用的且沒(méi)有超載，將請(qǐng)求發(fā)送到該服務(wù)器；若服務(wù)器不存在，或者該服務(wù)器超載且有服務(wù)器處于一半的工作負(fù)載，則使用'最少連接'的原則選出一個(gè)可用的服務(wù)器，將請(qǐng)求發(fā)送到服務(wù)器。
6.帶復(fù)制的基于局部性的最少連接
帶復(fù)制的基于局部性的最少連接（Locality-Based Least Connections with Replication 簡(jiǎn)稱'LBLCR'）算法也是針對(duì)目標(biāo)IP地址的負(fù)載均衡，目前主要用于Cache集群系統(tǒng)，它與LBLC算法不同之處是它要維護(hù)從一個(gè)目標(biāo)IP地址到一組服務(wù)器的映射，而LBLC算法維護(hù)從一個(gè)目標(biāo)IP地址到一臺(tái)服務(wù)器的映射。按'最小連接'原則從該服務(wù)器組中選出一一臺(tái)服務(wù)器，若服務(wù)器沒(méi)有超載，將請(qǐng)求發(fā)送到該服務(wù)器；若服務(wù)器超載，則按'最小連接'原則從整個(gè)集群中選出一臺(tái)服務(wù)器，將該服務(wù)器加入到這個(gè)服務(wù)器組中，將請(qǐng)求發(fā)送到該服務(wù)器。同時(shí)，當(dāng)該服務(wù)器組有一段時(shí)間沒(méi)有被修改，將最忙的服務(wù)器從服務(wù)器組中刪除，以降低復(fù)制的程度。
7.目標(biāo)地址散列調(diào)度
目標(biāo)地址散列調(diào)度（Destination Hashing 簡(jiǎn)稱'DH'）算法先根據(jù)請(qǐng)求的目標(biāo)IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列表找出對(duì)應(yīng)的服務(wù)器，若該服務(wù)器是可用的且并未超載，將請(qǐng)求發(fā)送到該服務(wù)器，否則返回空。
8.源地址散列調(diào)度U
源地址散列調(diào)度（Source Hashing 簡(jiǎn)稱'SH'）算法先根據(jù)請(qǐng)求的源IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列表找出對(duì)應(yīng)的服務(wù)器，若該服務(wù)器是可用的且并未超載，將請(qǐng)求發(fā)送到該服務(wù)器，否則返回空。它采用的散列函數(shù)與目標(biāo)地址散列調(diào)度算法的相同，它的算法流程與目標(biāo)地址散列調(diào)度算法的基本相似。
9.最短的期望的延遲
最短的期望的延遲調(diào)度（Shortest Expected Delay 簡(jiǎn)稱'SED'）算法基于WLC算法。舉個(gè)例子吧，ABC三臺(tái)服務(wù)器的權(quán)重分別為1、2、3 。那么如果使用WLC算法的話一個(gè)新請(qǐng)求進(jìn)入時(shí)它可能會(huì)分給ABC中的任意一個(gè)。使用SED算法后會(huì)進(jìn)行一個(gè)運(yùn)算
A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把請(qǐng)求交給得出運(yùn)算結(jié)果最小的服務(wù)器。
10.最少隊(duì)列調(diào)度
最少隊(duì)列調(diào)度（Never Queue 簡(jiǎn)稱'NQ'）算法，無(wú)需隊(duì)列。如果有realserver的連接數(shù)等于0就直接分配過(guò)去，不需要在進(jìn)行SED運(yùn)算。
---------------------
作者：chenhuyang
來(lái)源：CSDN
原文：https://blog.csdn.net/weixin_40470303/article/details/80541639
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！
運(yùn)維在“云江湖”的地位毋庸置疑。可以說(shuō)，沒(méi)有云運(yùn)維就沒(méi)有云計(jì)算。這其中，不僅是傳統(tǒng)數(shù)據(jù)中心的運(yùn)維管理，還有新技術(shù)如Container運(yùn)維、Hadoop運(yùn)維、Spark運(yùn)維、安全運(yùn)維等。在世紀(jì)互聯(lián)藍(lán)云事業(yè)部技術(shù)運(yùn)維總經(jīng)理湯濤看來(lái)：“中國(guó)本土市場(chǎng)，混合云和公有云在IT預(yù)算上的比例是10：1，即10元投入在混合云，1元在公有云。而快速發(fā)展的混合云市場(chǎng)，使得傳統(tǒng)運(yùn)維也在迅速向云運(yùn)維轉(zhuǎn)型。其中，有挑戰(zhàn)，更有機(jī)遇。”
在混合云的場(chǎng)景中，現(xiàn)有應(yīng)用遷入云是比較多的一類。企業(yè)希望新系統(tǒng)能夠更加“高可用”。湯濤就Cluster集群和混合云方案做了一個(gè)對(duì)比。為了保證高可用，傳統(tǒng)方案多是2臺(tái)或者4臺(tái)服務(wù)器做Cluster集群，一臺(tái)宕機(jī)另一臺(tái)還可以正常運(yùn)行。但此方案局限性也很明顯：
湯濤分析道：“如果同樣場(chǎng)景采用混合云方案，傳統(tǒng)IT架構(gòu)需要250臺(tái)服務(wù)器，云架構(gòu)也許只需要100臺(tái)服務(wù)器或者更少就夠了。在硬件和電力支出等方面都有很大的節(jié)省，應(yīng)用層以下的運(yùn)維也全面由云服務(wù)提供商所承擔(dān)，節(jié)省人力、物力和財(cái)力。”
世紀(jì)互聯(lián)藍(lán)云事業(yè)部技術(shù)運(yùn)維總經(jīng)理 湯濤
事實(shí)上，關(guān)于運(yùn)維工作范疇的變化，已經(jīng)被很多云上初創(chuàng)團(tuán)隊(duì)所驗(yàn)證：混合云架構(gòu)下，傳統(tǒng)運(yùn)維負(fù)責(zé)應(yīng)用層，云運(yùn)維負(fù)責(zé)數(shù)據(jù)中心的風(fēng)火水電以及云操作系統(tǒng)等。湯濤表示：“以前在系統(tǒng)出現(xiàn)問(wèn)題時(shí)，技術(shù)部門會(huì)對(duì)服務(wù)器、桌面、應(yīng)用系統(tǒng)等進(jìn)行排查，但混合云后，傳統(tǒng)IT架構(gòu)變成基于云架構(gòu)，應(yīng)用更多在云端。而云計(jì)算的本質(zhì)就是資源共享，每一個(gè)操作所影響的都是平臺(tái)上若干企業(yè)用戶的應(yīng)用。所以云運(yùn)維工程師需要從針對(duì)單機(jī)、單系統(tǒng)向多服務(wù)器、多系統(tǒng)、多平臺(tái)的管理，更集中、更專業(yè)化的方向轉(zhuǎn)變，需要更加小心和謹(jǐn)慎，更具精準(zhǔn)度的處理。比如服務(wù)器打補(bǔ)丁，原來(lái)是下載后，工程師直接安裝，但現(xiàn)在需要全方位測(cè)試和部署。云平臺(tái)的運(yùn)維每一個(gè)操作都要遵守嚴(yán)格的規(guī)定（運(yùn)維SOP編制指南）。這對(duì)運(yùn)維工程師的學(xué)歷、技術(shù)水平、專業(yè)能力等都有更的高要求。在藍(lán)云運(yùn)維團(tuán)隊(duì)中，多數(shù)工程師都需要半年或者更長(zhǎng)時(shí)間的專業(yè)性訓(xùn)練后，才能正式進(jìn)入云運(yùn)維工作。”
而隨著混合云應(yīng)用的逐步深入，湯濤對(duì)CSDN云計(jì)算表示：“現(xiàn)在很多新業(yè)務(wù)上線速度很快，很多企業(yè)都和藍(lán)云運(yùn)維團(tuán)隊(duì)溝通，希望能夠?qū)崿F(xiàn)運(yùn)維的外包服務(wù)。同樣我們也看到，ITSM（IT服務(wù)管理）也開(kāi)始走向云化服務(wù)。”
從運(yùn)維的角度來(lái)看，自動(dòng)縮放、彈性擴(kuò)容、負(fù)載均衡（SLB技術(shù)）都是很重要的技術(shù)。尤其是已獲得了可信云計(jì)算認(rèn)證的WindowsAzure的全網(wǎng)負(fù)載均衡（Traffic Manager）。簡(jiǎn)單來(lái)說(shuō)，就是在擁有不同的數(shù)據(jù)中心、多個(gè)操作單元的基礎(chǔ)上，根據(jù)狀態(tài)的有無(wú)、服務(wù)器負(fù)載、網(wǎng)絡(luò)帶寬和速度等因素，將流量變化智能地導(dǎo)向到不同的服務(wù)器集群上。如同一個(gè)智能的交通調(diào)度中心，這個(gè)智能全網(wǎng)負(fù)載系統(tǒng)通過(guò)循環(huán)負(fù)載均衡、性能負(fù)載均衡、故障轉(zhuǎn)移負(fù)載均衡等功能，幫助企業(yè)自動(dòng)監(jiān)測(cè)并自動(dòng)定向交通流量，為企業(yè)選擇一條最快最高效的交通線路到達(dá)目的地。但云服務(wù)往往都是跨地域的，所以要真正實(shí)現(xiàn)全網(wǎng)負(fù)載均衡并不容易。“從研發(fā)走向穩(wěn)定至少需要2-3年，這也是為何目前僅有由世紀(jì)互聯(lián)運(yùn)營(yíng)的Windows Azure能夠通過(guò)該項(xiàng)認(rèn)證的原因。”
在湯濤看來(lái)，全網(wǎng)負(fù)載均衡的技術(shù)點(diǎn)包括故障轉(zhuǎn)移、輪詢、按性能分配等，這些對(duì)用戶而言都很重要。事實(shí)上，雷擊、斷網(wǎng)、DDos攻擊等宕機(jī)，包含私有云、混合云、公有云都會(huì)遇到，通過(guò)全網(wǎng)負(fù)載均衡可以不僅可以指向Azure云服務(wù)，還可以指向用戶的私有云或者混合云，即使是其他的云服務(wù)提供商的云服務(wù)也是可以的。比如同樣一個(gè)用戶端域名可以指向分布在10個(gè)不同云上的10個(gè)站點(diǎn)，任何一個(gè)云節(jié)點(diǎn)故障發(fā)生時(shí)，用戶都可以指向其他9個(gè)。所以只要10個(gè)云節(jié)點(diǎn)中的1個(gè)不宕，服務(wù)就能有效提供。
湯濤詳細(xì)解釋：從底層技術(shù)來(lái)看，用戶的架構(gòu)設(shè)計(jì)時(shí)，傳統(tǒng)IT架構(gòu)和云架構(gòu)不同，前者更多在IaaS層，后者會(huì)用到云的虛擬機(jī)，而在真正能體現(xiàn)云價(jià)值的軟件層涉及較少。這也是曾經(jīng)業(yè)內(nèi)有人將虛擬化和云計(jì)算試圖劃等號(hào)的原因。然而僅有虛擬化是不夠的，更多是基于PaaS層的云化服務(wù)，更多特征或者功能的服務(wù)。比如跨中心的高可用，HA（High Availability），從架構(gòu)上使應(yīng)用無(wú)狀態(tài)化，是PaaS層的技術(shù)。舉個(gè)例子，10臺(tái)虛擬機(jī)跑一個(gè)應(yīng)用，這10臺(tái)虛擬機(jī)中都存有與用戶相關(guān)的所有狀態(tài)，保存在共享緩存中或者數(shù)據(jù)庫(kù)中，然后通過(guò)數(shù)據(jù)中心同步實(shí)現(xiàn)變化的統(tǒng)一性。當(dāng)這10臺(tái)中任何1-2臺(tái)宕掉時(shí)不會(huì)影響業(yè)務(wù)正常運(yùn)轉(zhuǎn)，也不會(huì)影響暫存數(shù)據(jù)或者已存儲(chǔ)數(shù)據(jù)。
Azure在國(guó)內(nèi)的北京和上海的數(shù)據(jù)中心中，數(shù)據(jù)是自動(dòng)同步的，所以簡(jiǎn)單地說(shuō)只需將無(wú)狀態(tài)應(yīng)用直接放到兩個(gè)數(shù)據(jù)中心，再架一個(gè)全網(wǎng)負(fù)載指向即可。當(dāng)一個(gè)出現(xiàn)問(wèn)題，自動(dòng)轉(zhuǎn)到另一個(gè)上。當(dāng)架構(gòu)重新設(shè)計(jì)時(shí)，全網(wǎng)負(fù)載可以指向用戶私有云數(shù)據(jù)中心，或者第三方數(shù)據(jù)中心（其他公有云數(shù)據(jù)中心），所采用的就是Azure Traffic Manager技術(shù)。相當(dāng)于在Azure和其他數(shù)據(jù)中心通過(guò)VPN架設(shè)起來(lái)，在不停機(jī)的情況下執(zhí)行升級(jí)和服務(wù)維護(hù)，實(shí)現(xiàn)高速通路。無(wú)論是其他辦公室還是數(shù)據(jù)中心，都可以享受全網(wǎng)負(fù)載的優(yōu)勢(shì)。
談到具有財(cái)務(wù)保障的高達(dá)99.9%的月度SLA服務(wù)等級(jí)協(xié)議保證，湯濤還分享了一些技術(shù)細(xì)節(jié)：由于Azure提供6份備份，容災(zāi)方面的考慮，首先是數(shù)據(jù)層面，其次是應(yīng)用層面，出現(xiàn)問(wèn)題不僅是保護(hù)數(shù)據(jù)，還有讓用戶可以隨時(shí)訪問(wèn)到關(guān)鍵應(yīng)用。比如有些關(guān)鍵應(yīng)用可能一分鐘都不能宕機(jī)。這時(shí)就不僅需要應(yīng)用級(jí)容災(zāi)，還需要異地災(zāi)備，跨城（1000公里以上）異地災(zāi)備。而Azure的北京和上海的數(shù)據(jù)中心是通過(guò)高速“雙”光纖連接的，兩條通路是相對(duì)獨(dú)立的，可以避免如地震、“挖掘機(jī)”這類問(wèn)題。如果用Azure的PaaS，只要將虛擬機(jī)放入可用級(jí)中，就已自動(dòng)實(shí)現(xiàn)跨區(qū)管理，比如說(shuō)同一數(shù)據(jù)中心不同機(jī)架，或者不同數(shù)據(jù)中心之間，任何一個(gè)機(jī)器宕掉，系統(tǒng)都能自動(dòng)識(shí)別，并且自動(dòng)啟動(dòng)一個(gè)新的實(shí)例起來(lái)。再加上自動(dòng)縮放、實(shí)時(shí)監(jiān)測(cè)，就能自動(dòng)適應(yīng)，并提供高度穩(wěn)定、可用的解決方案，效果很好。
舉個(gè)例子，用戶配置是4臺(tái)虛擬機(jī)，其中2臺(tái)出現(xiàn)問(wèn)題，不需人工干預(yù)，系統(tǒng)自動(dòng)會(huì)從不同機(jī)架上調(diào)配2臺(tái)新虛擬機(jī)實(shí)例，這樣在上海和北京的數(shù)據(jù)中心，這樣就一直保持4個(gè)虛擬機(jī)在響應(yīng)用戶需求。這是Azure PaaS實(shí)例層面一個(gè)很重要的技術(shù)，國(guó)內(nèi)其他云服務(wù)企業(yè)在藍(lán)云的帶領(lǐng)下，也在逐步提供這樣的服務(wù)。
不止如此，為了提升運(yùn)維服務(wù)水平，除了高效響應(yīng)和分級(jí)處理制度外，運(yùn)維團(tuán)隊(duì)還從不同指標(biāo)中選擇最優(yōu)組合指標(biāo)來(lái)判斷問(wèn)題的出現(xiàn)、狀況、處理方案，湯濤表示：“不僅有傳感器，還需要有監(jiān)控傳感器的體系，通過(guò)這樣的二級(jí)防護(hù)體系來(lái)保障運(yùn)維穩(wěn)定、安全和高效。在一些實(shí)際場(chǎng)景中，在用戶的請(qǐng)求下藍(lán)云還會(huì)幫助用戶分析是解決方案的問(wèn)題還是平臺(tái)的Bug，甚至可以從代碼角度進(jìn)行排查。”
隨著云計(jì)算的深入，傳統(tǒng)IT運(yùn)維過(guò)度到云運(yùn)維，已是趨勢(shì)。而無(wú)論是自動(dòng)化還是規(guī)模化，運(yùn)維都是朝高精尖方向發(fā)展，如果運(yùn)維工程師能主動(dòng)學(xué)習(xí)，更寬廣的云運(yùn)維之路就在前方。