一種多移除的多移除管理方法

一種多移除的多移除管理方法

1多農(nóng)戶應(yīng)用的架構(gòu)設(shè)計(jì)軟件即服務(wù)模式以將系統(tǒng)的開發(fā)和運(yùn)營(yíng)外包給依賴軟件的服務(wù)提供商，降低客戶在構(gòu)建、使用和維護(hù)軟件應(yīng)用程序方面的成本，并獲得廣泛的認(rèn)可和使用。在sa模式下，承擔(dān)費(fèi)用的用戶被稱為租賃用戶。最終用戶使用租賃協(xié)議，即只使用于所有虛擬系統(tǒng)的用戶。一般來說,SaaS提供商會(huì)同時(shí)為多個(gè)租戶提供軟件服務(wù),以利用規(guī)模經(jīng)濟(jì)效應(yīng),通過在租戶間共享人力、設(shè)備等資源來降低成本、提高收益.本文將基于同一基礎(chǔ)設(shè)施,同時(shí)為多個(gè)租戶提供具有共性的軟件服務(wù)的應(yīng)用稱為多租戶應(yīng)用.對(duì)于各個(gè)租戶,SaaS提供商往往采用基于租賃的銷售模式以及基于使用量和性能指標(biāo)的計(jì)費(fèi)模式.因而,SaaS提供商需要為其租戶提供明確的性能保障,以提高應(yīng)用的可信度和用戶體驗(yàn).多租戶應(yīng)用在保障各租戶性能指標(biāo)的同時(shí),還需要提高其整體資源利用率,以降低成本.如何實(shí)現(xiàn)該目標(biāo)需要依據(jù)應(yīng)用類型的不同而進(jìn)行區(qū)分考量.本文所關(guān)注的是數(shù)據(jù)驅(qū)動(dòng)的Web應(yīng)用.這是一類常見的Web應(yīng)用,其特點(diǎn)在于應(yīng)用的功能和使用模式圍繞著數(shù)據(jù)的增、刪、改、查來展開.常見的數(shù)據(jù)驅(qū)動(dòng)的Web應(yīng)用包括客戶關(guān)系管理(CRM)、網(wǎng)絡(luò)商店等等.與用于靜態(tài)信息發(fā)布的Web應(yīng)用不同,數(shù)據(jù)驅(qū)動(dòng)的Web應(yīng)用往往需要處理關(guān)鍵的業(yè)務(wù)數(shù)據(jù)、執(zhí)行復(fù)雜的業(yè)務(wù)邏輯,因而需要保障較高的數(shù)據(jù)一致性級(jí)別,支持復(fù)雜的數(shù)據(jù)查詢.另外,由于系統(tǒng)的負(fù)載可能隨時(shí)間動(dòng)態(tài)變化,因而多租戶應(yīng)用適合于建立在硬件云計(jì)算平臺(tái)之上(如AmazonEC2),以便通過動(dòng)態(tài)改變服務(wù)器的數(shù)量來適應(yīng)負(fù)載的波動(dòng).具體的,表1總結(jié)了多租戶應(yīng)用的特點(diǎn)以及多租戶應(yīng)用與在線事務(wù)處理應(yīng)用(OLTP)以及以GoogleAppEngine(GAE)等托管環(huán)境所支持的應(yīng)用之間的不同之處.多租戶應(yīng)用的上述特點(diǎn)使得針對(duì)OLTP應(yīng)用的架構(gòu)難以適應(yīng)其較大的數(shù)據(jù)量以及負(fù)載的動(dòng)態(tài)變化,而GAE的架構(gòu)難以滿足其數(shù)據(jù)一致性以及查詢表達(dá)能力方面的需求,因而需要重新考慮多租戶應(yīng)用的架構(gòu)設(shè)計(jì)問題.具體的,多租戶應(yīng)用的架構(gòu)設(shè)計(jì)依據(jù)租戶間共享資源方式的不同可以分為兩種類型:獨(dú)享應(yīng)用實(shí)例模式和共享應(yīng)用實(shí)例模式.前者為每個(gè)租戶提供獨(dú)立的物理節(jié)點(diǎn)或者虛擬機(jī)以及運(yùn)行在其上的獨(dú)立應(yīng)用實(shí)例,后者在多個(gè)節(jié)點(diǎn)上運(yùn)行單一應(yīng)用實(shí)例來支撐所用的租戶.在本文中,我們關(guān)注共享應(yīng)用實(shí)例模式.一般來說,采用共享應(yīng)用實(shí)例的架構(gòu)意味著能夠支持較高的租戶密度以及較低的軟件管理和維護(hù)成本,然而實(shí)現(xiàn)該架構(gòu)也面臨著應(yīng)用定制、按需擴(kuò)展、性能管理等方面的挑戰(zhàn),本文主要關(guān)注于該架構(gòu)下的性能管理問題.本文第2節(jié)對(duì)共享實(shí)例型多租戶架構(gòu)做進(jìn)一步介紹,并給出一個(gè)具體的架構(gòu)——MDSA;第3節(jié)闡述MDSA中的業(yè)務(wù)邏輯層的性能管理;第4節(jié)闡述MDSA中的數(shù)據(jù)管理層的性能管理;第5節(jié)對(duì)MDSA及其性能管理技術(shù)進(jìn)行實(shí)驗(yàn)分析;第6節(jié)介紹相關(guān)工作;最后是結(jié)論.2多用戶基礎(chǔ)平臺(tái)的作用本文討論的多租戶架構(gòu)如圖1所示,該架構(gòu)采用元數(shù)據(jù)驅(qū)動(dòng)模式來保障其可定制性,通過將狀態(tài)保存在數(shù)據(jù)庫層以及基于租戶的數(shù)據(jù)劃分來保障其可擴(kuò)展性,因此被命名為MDSA(Metadata-DrivenScalableArchitecture).MDSA由業(yè)務(wù)邏輯層和數(shù)據(jù)處理層構(gòu)成.一個(gè)完整的請(qǐng)求處理過程從業(yè)務(wù)邏輯層開始,中間可能需要多次訪問數(shù)據(jù)處理層,直到生成完整的應(yīng)答并且發(fā)送回客戶端為止.由于前文提到的應(yīng)用特點(diǎn),MDSA采用關(guān)系型數(shù)據(jù)庫來管理各個(gè)租戶的數(shù)據(jù).進(jìn)一步,為了保障數(shù)據(jù)的高可用性,MDSA為每個(gè)租戶數(shù)據(jù)庫維護(hù)了多個(gè)分布在不同節(jié)點(diǎn)上的數(shù)據(jù)副本.在MDSA中,每一個(gè)層次都可以通過使用多個(gè)節(jié)點(diǎn)來提高其處理能力.在這種情況下,每一個(gè)層次都需要增加一個(gè)請(qǐng)求分發(fā)器用來在節(jié)點(diǎn)之間進(jìn)行負(fù)載均衡.MDSA架構(gòu)繼承了經(jīng)典的多層架構(gòu)靈活、模塊化等好處,然而,多租戶應(yīng)用的特定需求還在可定制性、可擴(kuò)展性、可管理性等方面為MDSA的設(shè)計(jì)提出了新的挑戰(zhàn).另外,為了避免每個(gè)采用MDSA架構(gòu)的多租戶應(yīng)用都需要重復(fù)考慮這些問題,本文提出了一個(gè)支持該架構(gòu)的多租戶基礎(chǔ)平臺(tái).該平臺(tái)總結(jié)和實(shí)現(xiàn)了應(yīng)對(duì)上述問題的通用方案,以縮減構(gòu)造每個(gè)特定的多租戶應(yīng)用的開銷.下面我們分別從上述幾方面來進(jìn)一步介紹MDSA的設(shè)計(jì)及多租戶平臺(tái)在其中的作用.2.1基于元數(shù)據(jù)驅(qū)動(dòng)的業(yè)務(wù)邏輯支持企業(yè)的業(yè)務(wù)需求千差萬別,每個(gè)企業(yè)都期望擁有適合自己的租戶應(yīng)用,這使得可定制性成為了多租戶應(yīng)用的一個(gè)重要方面.具體的,支持應(yīng)用定制需要考慮如下問題:如何支持一個(gè)租戶擴(kuò)展默認(rèn)的數(shù)據(jù)對(duì)象或者引入全新的數(shù)據(jù)對(duì)象?如何支持不同的租戶定義的不同數(shù)據(jù)對(duì)象的共存?如何在數(shù)據(jù)對(duì)象可能變動(dòng)的環(huán)境下編寫業(yè)務(wù)邏輯?如何支持每個(gè)租戶添加自己的業(yè)務(wù)邏輯?當(dāng)業(yè)務(wù)邏輯和數(shù)據(jù)對(duì)象有所變動(dòng)時(shí),如何維護(hù)它們之間的一致性?在MDSA中,對(duì)可定制性的支持是通過采用元數(shù)據(jù)驅(qū)動(dòng)的架構(gòu)來實(shí)現(xiàn)的,即將應(yīng)用中易變或不確定的部分從軟件中剝離出來,用元數(shù)據(jù)(Meta-data)來描述它們.具體的,適合用元數(shù)據(jù)表示的可變的部分包括軟件界面的呈現(xiàn)邏輯、軟件中涉及到的業(yè)務(wù)規(guī)則、軟件中涉及到的流程、各種報(bào)表的擴(kuò)展字段等等.由于應(yīng)用的定制往往與應(yīng)用本身的業(yè)務(wù)功能有著緊密的聯(lián)系,因此對(duì)可定制性的支持需要在特定應(yīng)用的設(shè)計(jì)開發(fā)階段就有所考慮.然而,多租戶平臺(tái)可以通過提供常用組件和推廣最佳實(shí)踐的方式提高其開發(fā)效率.具體的,表2列舉了一些常見的元數(shù)據(jù)處理相關(guān)的組件.元數(shù)據(jù)驅(qū)動(dòng)的架構(gòu)將每個(gè)租戶應(yīng)用可能的不同之處都提取成為元數(shù)據(jù).這樣,定制一個(gè)租戶應(yīng)用就表現(xiàn)為修改該租戶應(yīng)用的元數(shù)據(jù),進(jìn)而避免了應(yīng)用定制對(duì)軟件整體邏輯的影響,為不同的租戶定制的數(shù)據(jù)對(duì)象和業(yè)務(wù)邏輯的共存提供了支撐.2.2數(shù)據(jù)處理層對(duì)可擴(kuò)展性的影響對(duì)于多租戶應(yīng)用,可擴(kuò)展性指的是當(dāng)租戶的數(shù)量及其負(fù)載增加或減少時(shí),系統(tǒng)能夠通過添加或刪除服務(wù)器來應(yīng)對(duì)這一變化.下面我們分別從業(yè)務(wù)邏輯層和數(shù)據(jù)處理層兩方面來探討MDSA的可擴(kuò)展性.對(duì)于業(yè)務(wù)邏輯層,我們采用無狀態(tài)模式來保障其可擴(kuò)展性,即應(yīng)用服務(wù)器本身不保存狀態(tài),因而,對(duì)于一個(gè)HTTP請(qǐng)求,該請(qǐng)求可以分發(fā)到任意一個(gè)應(yīng)用服務(wù)器來處理.這一模式使得系統(tǒng)可以通過添加或減少應(yīng)用服務(wù)器來動(dòng)態(tài)伸縮業(yè)務(wù)邏輯層的處理能力.對(duì)于數(shù)據(jù)處理層,對(duì)擴(kuò)展性的影響主要表現(xiàn)在兩個(gè)方面.(1)高效的處理跨節(jié)點(diǎn)、大數(shù)據(jù)量的查詢是非常困難的,系統(tǒng)需要盡可能地避免跨節(jié)點(diǎn)的數(shù)據(jù)查詢.(2)為了保障數(shù)據(jù)可用性,系統(tǒng)對(duì)租戶的數(shù)據(jù)進(jìn)行復(fù)制.如何高效的實(shí)現(xiàn)數(shù)據(jù)復(fù)制也是影響可擴(kuò)展性的一個(gè)關(guān)鍵因素.MDSA通過數(shù)據(jù)劃分來解決第一個(gè)問題.具體的,MDSA將數(shù)據(jù)劃分為多個(gè)租戶數(shù)據(jù)庫,其中每個(gè)租戶只屬于一個(gè)租戶數(shù)據(jù)庫.由于單個(gè)租戶預(yù)期的數(shù)據(jù)量較小,通過選定合適劃分模式可以使得:(1)單個(gè)數(shù)據(jù)庫節(jié)點(diǎn)能夠容納多個(gè)租戶數(shù)據(jù)庫;(2)單個(gè)數(shù)據(jù)庫節(jié)點(diǎn)所容納的租戶數(shù)據(jù)庫數(shù)量不會(huì)太多,以避免管理元數(shù)據(jù)的開銷.上述劃分使得每個(gè)數(shù)據(jù)庫查詢都可以對(duì)應(yīng)到一個(gè)特定的租戶數(shù)據(jù)庫,進(jìn)而可以由一個(gè)節(jié)點(diǎn)處理,避免了跨節(jié)點(diǎn)的查詢.MDSA通過采用文獻(xiàn)中的數(shù)據(jù)復(fù)制算法來解決第2個(gè)問題.該算法通過一組調(diào)度器節(jié)點(diǎn)來協(xié)調(diào)各個(gè)副本間的數(shù)據(jù)同步,使得對(duì)于一個(gè)查詢,當(dāng)任一副本處理完該請(qǐng)求之后,其結(jié)果就可以返回給應(yīng)用服務(wù)器,而不必等待所有副本都執(zhí)行過完該查詢.上述方案保障了MDSA在數(shù)據(jù)處理層的可擴(kuò)展性.2.3性能管理概述對(duì)于多租戶應(yīng)用,可管理性指的是如何管理系統(tǒng)中的資源總量以及資源在租戶間的分配來應(yīng)對(duì)負(fù)載變化,避免租戶間性能相互影響,以期在維持較高的資源利用率的同時(shí)為各個(gè)租戶提供一定的性能指標(biāo)保障.Web應(yīng)用請(qǐng)求的處理過程可能會(huì)涉及到多種不同的資源,其中資源利用率較高的資源被稱作資源瓶頸.對(duì)于不同類型的應(yīng)用其資源瓶頸可能不同,但是對(duì)于特定的應(yīng)用來說,資源瓶頸往往只有一個(gè).文獻(xiàn)等工作都表明,動(dòng)態(tài)Web應(yīng)用的資源瓶頸在于CPU資源,因此,本文主要考慮對(duì)CPU資源的管理.已有工作提出了很多自動(dòng)化的性能和資源管理手段.其中常用的資源管理手段包括請(qǐng)求調(diào)度、負(fù)載分配、準(zhǔn)入控制、資源提供、資源劃分等等.由于業(yè)務(wù)邏輯層及數(shù)據(jù)處理層在狀態(tài)管理、負(fù)載特性以及訪問接口等方面的不同,多租戶特性引發(fā)的問題也有所不同,解決問題所使用的資源管理手段也有所差異.因此,探討MDSA的性能管理問題需要從這兩個(gè)層面入手,分別為其面臨的難點(diǎn)問題以及已有工作的適用性.MDSA的業(yè)務(wù)邏輯層節(jié)點(diǎn)是無狀態(tài)的,即每一個(gè)請(qǐng)求可以在任意一個(gè)節(jié)點(diǎn)進(jìn)行處理.因此,租戶之間的競(jìng)爭(zhēng)主要表現(xiàn)為同一節(jié)點(diǎn)之上并發(fā)請(qǐng)求之間的競(jìng)爭(zhēng).具體的,如果某一租戶的請(qǐng)求需要很多資源來處理,則該請(qǐng)求很可能影響其他租戶的請(qǐng)求.與業(yè)務(wù)邏輯層相關(guān)的性能管理手段主要有請(qǐng)求調(diào)度、負(fù)載分配、準(zhǔn)入控制等等.而無狀態(tài)模式下的負(fù)載分配和準(zhǔn)入控制都有著較成熟工作,因此在業(yè)務(wù)邏輯層,本文的討論主要圍繞請(qǐng)求調(diào)度展開,具體內(nèi)容在第3節(jié)介紹.MDSA的數(shù)據(jù)處理層是有狀態(tài)的服務(wù),即按照管理的租戶數(shù)據(jù)庫的不同,各個(gè)節(jié)點(diǎn)有著不同的狀態(tài),處理來自于不同租戶的負(fù)載.因此,租戶之間的競(jìng)爭(zhēng)主要表現(xiàn)為放置在同一個(gè)節(jié)點(diǎn)中的不同租戶數(shù)據(jù)庫副本之間的資源競(jìng)爭(zhēng).具體的,當(dāng)某些租戶的總體負(fù)載增加時(shí),很可能影響與其部署在統(tǒng)一數(shù)據(jù)庫之上的其他租戶的性能.因此在數(shù)據(jù)處理層,本文的討論主要圍繞租戶數(shù)據(jù)庫副本在節(jié)點(diǎn)間的放置以及負(fù)載在各個(gè)副本之間的分配兩方面展開,具體內(nèi)容在第4節(jié)介紹.3資源被劫現(xiàn)象的分析業(yè)務(wù)邏輯層的性能管理面臨的挑戰(zhàn)在于請(qǐng)求服務(wù)需求的不可預(yù)計(jì)性.這種不可預(yù)計(jì)性是由Web應(yīng)用本身的復(fù)雜性引起的.以業(yè)務(wù)流程管理應(yīng)用中的流程啟動(dòng)請(qǐng)求為例,依據(jù)該請(qǐng)求的參數(shù),應(yīng)用邏輯會(huì)查找相應(yīng)的流程定義并啟動(dòng)一個(gè)新的流程實(shí)例.這個(gè)過程中消耗的資源量與流程定義的結(jié)構(gòu)、流程的啟動(dòng)參數(shù)等因素密切相關(guān),因此處理不同的流程啟動(dòng)請(qǐng)求所消耗的資源量可能相差很大.請(qǐng)求服務(wù)需求的不可預(yù)計(jì)性會(huì)使得當(dāng)某些請(qǐng)求的服務(wù)需求遠(yuǎn)遠(yuǎn)大于其他的請(qǐng)求時(shí),即使其數(shù)量很少,也會(huì)導(dǎo)致其他請(qǐng)求的性能急劇下降.我們將這一現(xiàn)象稱為資源劫持,將導(dǎo)致資源劫持的請(qǐng)求稱為資源劫持請(qǐng)求.圖2給出了一個(gè)資源劫持現(xiàn)象的實(shí)例,圖2(a)是資源劫持請(qǐng)求到來過程,圖2(b)展示了系統(tǒng)平均響應(yīng)時(shí)間的變化過程,可以看出資源劫持請(qǐng)求的到來會(huì)嚴(yán)重影響請(qǐng)求的正常處理.資源劫持現(xiàn)象的發(fā)生意味著一個(gè)租戶的請(qǐng)求可能會(huì)影響其他租戶請(qǐng)求,因此多租戶應(yīng)用應(yīng)當(dāng)避免這類現(xiàn)象.解決該問題的一個(gè)直接方法是為請(qǐng)求的處理時(shí)間設(shè)置一個(gè)嚴(yán)格的閾值,當(dāng)一個(gè)請(qǐng)求的處理時(shí)間超出該閾值則丟棄該請(qǐng)求.然而,這種方式給應(yīng)用的開發(fā)帶來較大的限制,使得開發(fā)人員難以實(shí)現(xiàn)一些復(fù)雜的請(qǐng)求處理邏輯.因此,本節(jié)我們考慮如何在避免資源劫持的同時(shí)支持較為寬松的請(qǐng)求處理時(shí)間閾值(例如GoogleAppEngine對(duì)于一個(gè)請(qǐng)求執(zhí)行的最長(zhǎng)限額為30s,而相對(duì)的,一個(gè)簡(jiǎn)單的HTTP請(qǐng)求的處理時(shí)間只需要幾毫秒).多租戶應(yīng)用對(duì)各個(gè)租戶提供的性能保障是和特定的指標(biāo)聯(lián)系在一起的.由于Web應(yīng)用交互式的訪問特征,請(qǐng)求的響應(yīng)時(shí)間是提高客戶滿意度的關(guān)鍵性指標(biāo).具體的,本節(jié)采用延長(zhǎng)因子作為主要的性能指標(biāo).延長(zhǎng)因子是指請(qǐng)求的響應(yīng)時(shí)間和服務(wù)需求的比值.其優(yōu)勢(shì)在于不依賴于具體的業(yè)務(wù)處理邏輯,能夠用來單獨(dú)分析應(yīng)用運(yùn)營(yíng)商的服務(wù)水平.從解決手段的角度,請(qǐng)求調(diào)度策略可以如下分類:如果一個(gè)策略的執(zhí)行需要預(yù)知所有已經(jīng)到達(dá)的請(qǐng)求的服務(wù)需求,則稱該策略是透視的(Clairvoyant).如果一個(gè)策略不需要預(yù)知請(qǐng)求的服務(wù)需求,則稱該策略是非透視的(Non-Clairvoyant或者Blind).由于請(qǐng)求服務(wù)需求的不可預(yù)計(jì)性,在MDSA中難以使用透視的請(qǐng)求調(diào)度策略.基于上述分析,本節(jié)的研究目標(biāo)可以定義為:設(shè)計(jì)一個(gè)非透視的請(qǐng)求準(zhǔn)入策略,使得存在資源劫持請(qǐng)求時(shí),業(yè)務(wù)邏輯層請(qǐng)求的延長(zhǎng)因子SF=R/D的數(shù)學(xué)期望不應(yīng)劇烈變化,其中R為請(qǐng)求的響應(yīng)時(shí)間,D為請(qǐng)求的服務(wù)需求.3.1adrs的描述已有工作表明,以最小化平均響應(yīng)時(shí)間為目標(biāo),最短剩余處理時(shí)間優(yōu)先調(diào)度策略(SRPT)是最優(yōu)的調(diào)度策略.圖3展示了存在資源劫持請(qǐng)求的情況下輪轉(zhuǎn)調(diào)度策略RR和SRPT的性能比較.可以看出,SRPT能夠明顯縮減由于少量資源劫持請(qǐng)求帶來的性能下降.然而SPRT是透視的算法,其使用需要知道每個(gè)請(qǐng)求的服務(wù)需求.因此,我們的設(shè)計(jì)思路是設(shè)計(jì)一個(gè)能夠模擬SPRT行為的非透視的算法.參照SPRT調(diào)度策略,本節(jié)提出ADRS(Application-levelDelay-basedRequestScheduling)調(diào)度算法.ADRS對(duì)每個(gè)請(qǐng)求處理過程中的資源消耗情況進(jìn)行監(jiān)控,并動(dòng)態(tài)降低資源消耗較多的請(qǐng)求的優(yōu)先級(jí),以避免資源劫持現(xiàn)象.具體地,我們引入如下概念.定義1.請(qǐng)求的掛起和繼續(xù).給定一個(gè)HTTP請(qǐng)求,應(yīng)用層請(qǐng)求調(diào)度器主動(dòng)暫停其處理過程的事件稱為請(qǐng)求的掛起;重新將一個(gè)掛起的請(qǐng)求恢復(fù)為可執(zhí)行狀態(tài)的事件稱為請(qǐng)求的繼續(xù).定義2.請(qǐng)求的連續(xù)處理時(shí)間.給定一個(gè)HTTP請(qǐng)求,允許該請(qǐng)求不掛起連續(xù)執(zhí)行的最長(zhǎng)時(shí)間,記作Tc.定義3.請(qǐng)求的掛起延遲時(shí)間.給定一個(gè)HTTP請(qǐng)求,該請(qǐng)求掛起到下一次嘗試?yán)^續(xù)的時(shí)間間隔稱為掛起的延遲時(shí)間,記作Td.基于上述定義,ADRS的描述如圖4所示.可以看出,在ADRS中,每個(gè)請(qǐng)求被掛起的次數(shù)(delayCount)被用作該請(qǐng)求的相對(duì)優(yōu)先級(jí).當(dāng)delayCount=0時(shí),請(qǐng)求的優(yōu)先級(jí)最高.對(duì)于服務(wù)需求較大的請(qǐng)求,其delayCount會(huì)隨著請(qǐng)求的處理過程逐漸增加,相應(yīng)的其優(yōu)先級(jí)也逐漸下降.這樣的性質(zhì)與SPRT調(diào)度策略的思路是一致的.該算法與操作系統(tǒng)中的多級(jí)反饋隊(duì)列調(diào)度(MLFQ)算法也有相似之處,其區(qū)別在于MLFQ是以線程為調(diào)度對(duì)象,而ADRS的調(diào)度對(duì)象是HTTP請(qǐng)求.Tc和Td是ADRS中的關(guān)鍵參數(shù),其設(shè)置對(duì)調(diào)度算法的性能有著重要影響.直觀上考慮,Tc過小會(huì)導(dǎo)致很多請(qǐng)求都需要經(jīng)歷延遲,會(huì)大幅降低系統(tǒng)的整體性能;另一方面,Tc過大會(huì)降低系統(tǒng)對(duì)資源劫持請(qǐng)求的防御能力.因此,Tc應(yīng)當(dāng)取較為適中的值.對(duì)于Web應(yīng)用,已有的研究表明,與網(wǎng)頁交互時(shí)人的反映時(shí)間為200ms左右,即當(dāng)請(qǐng)求響應(yīng)時(shí)間小于200ms時(shí),用戶能夠流暢地使用Web應(yīng)用.因此,考慮到網(wǎng)絡(luò)傳輸?shù)纫蛩?一個(gè)請(qǐng)求在服務(wù)器端所消耗的時(shí)間應(yīng)當(dāng)小于200ms.進(jìn)一步,考慮到由于資源競(jìng)爭(zhēng)帶來的延遲,軟件開發(fā)商應(yīng)當(dāng)將每個(gè)請(qǐng)求的服務(wù)需求限制在幾十毫秒以內(nèi).因此,Tc=100ms是一個(gè)較為合適的選擇.對(duì)于延遲時(shí)間Td來說,其值設(shè)置過大會(huì)導(dǎo)致被延遲的請(qǐng)求遲遲得不到再次運(yùn)行的機(jī)會(huì),降低被延遲的請(qǐng)求的性能,造成潛在的資源浪費(fèi).另一方面,其值設(shè)置過小則可能導(dǎo)致被延遲的請(qǐng)求過于頻繁地嘗試再次運(yùn)行,增加調(diào)度算法的開銷.這里,一次判定okToContinue()所需的開銷包括兩次線程上下文切換以及一次okToContinue()的運(yùn)行.基于上述分析,設(shè)置Td時(shí)應(yīng)當(dāng)在避免較大開銷的前提下選擇較小的值.后續(xù)的章節(jié)通過一系列實(shí)驗(yàn)表明,將Td設(shè)置為5ms能夠取得較優(yōu)的性能和較低的開銷.3.2資源檢查點(diǎn)選取為了實(shí)現(xiàn)ADRS算法,需要對(duì)每個(gè)請(qǐng)求的CPU資源使用情況進(jìn)行實(shí)時(shí)監(jiān)控.由于通過修改操作系統(tǒng)內(nèi)核來進(jìn)行請(qǐng)求調(diào)度有著影響的范圍較大、修改的難度較高、不便于移植等不足,因此本節(jié)介紹了一種基于代碼轉(zhuǎn)換的CPU資源監(jiān)控機(jī)制,以實(shí)現(xiàn)ADRS.本節(jié)描述的方法是特定于Java語言平臺(tái)的,然而我們認(rèn)為其思路具有一定的通用性,能夠擴(kuò)展到類似的語言運(yùn)行環(huán)境中,例如.NET.圖5展示了ADRS的實(shí)現(xiàn)原理.其基本思路是:(1)在應(yīng)用代碼部署之前對(duì)其進(jìn)行分析,找出一組適當(dāng)?shù)馁Y源檢查點(diǎn),并插入資源檢查代碼,將轉(zhuǎn)換后的代碼部署到多租戶平臺(tái).(2)每個(gè)HTTP請(qǐng)求的到來都會(huì)觸發(fā)一個(gè)請(qǐng)求處理線程的執(zhí)行,執(zhí)行過程中會(huì)不斷地遇到第一步插入的資源檢查點(diǎn).這時(shí)請(qǐng)求處理線程執(zhí)行資源檢查代碼,并且在請(qǐng)求使用完當(dāng)前資源限額時(shí)執(zhí)行延遲調(diào)度算法.在上述思路中,如何選定一組適當(dāng)?shù)馁Y源檢查點(diǎn)是提高上述算法性能的關(guān)鍵.選取較多的檢查點(diǎn)可能會(huì)帶來不必要的性能開銷,選取較少的檢查點(diǎn)則存在損害資源使用監(jiān)控精度的風(fēng)險(xiǎn).我們使用一種漸進(jìn)式的方式來得到合適的檢查點(diǎn)集合.具體的,我們首先采用保守的策略找到一組能夠保證精度要求的檢查點(diǎn),并隨后在不損害精度的前提下逐漸縮減檢查點(diǎn)的個(gè)數(shù).保守的檢查點(diǎn)設(shè)置策略如下:(1)在每一個(gè)方法的開始加入對(duì)checkConsumption()的調(diào)用.(2)在每一個(gè)循環(huán)的開始加入對(duì)checkConsumption()的調(diào)用.(3)在每一個(gè)方法中不包含循環(huán)的、不包含函數(shù)調(diào)用并且長(zhǎng)度超出MAXPATH的代碼塊的結(jié)束處加入對(duì)checkConsumption()的調(diào)用,其中MAXPATH是系統(tǒng)定義的一個(gè)常量.上述檢查點(diǎn)設(shè)置模式使得當(dāng)不考慮遞歸時(shí),每執(zhí)行MAXPATH長(zhǎng)度的代碼,至少會(huì)調(diào)用一次資源檢查方法.在考慮遞歸時(shí),假設(shè)系統(tǒng)為線程分配的棧的最大深度為MAXSTACK,則每執(zhí)行MAXPATH*MAXSTACK長(zhǎng)度的代碼,至少會(huì)調(diào)用一次資源檢查方法.通過設(shè)定MAXPATH以及MAXSTACK的值,系統(tǒng)能夠確保一定的資源監(jiān)控精度.為了進(jìn)一步減輕資源監(jiān)控開銷,下面我們介紹幾種減少資源檢查點(diǎn)的方法.首先,我們將不包含其他方法調(diào)用的方法稱為原子方法.顯然,省略掉原子方法中的第一類檢查點(diǎn)對(duì)于監(jiān)控的精確度的影響不大.由于Java應(yīng)用中常常存在大量的原子方法(gettersandsetters),所以省略對(duì)原子方法中的檢查點(diǎn)能夠大幅縮減監(jiān)控的開銷.其次,在每個(gè)循環(huán)的每次執(zhí)行中都調(diào)用一次資源檢查代碼往往是不必要的,我們可以在每個(gè)方法中加入一個(gè)局部變量來記錄循環(huán)的執(zhí)行次數(shù).并且只在循環(huán)執(zhí)行的次數(shù)超出特定閾值MAXLOOP時(shí),才真正調(diào)用一次資源檢查方法.通過使用局部變量操作來代替部分方法調(diào)用能夠縮減一定的監(jiān)控開銷.4多用戶數(shù)據(jù)庫的數(shù)據(jù)復(fù)制策略如第2.2節(jié)所述,從可擴(kuò)展性和數(shù)據(jù)可用性的角度出發(fā),MDSA將數(shù)據(jù)劃分為多個(gè)租戶數(shù)據(jù)庫,為每個(gè)租戶數(shù)據(jù)庫維護(hù)多個(gè)副本.對(duì)業(yè)務(wù)邏輯層來說,數(shù)據(jù)處理層提供了一個(gè)高可用的、具有一定性能保障數(shù)據(jù)管理服務(wù),并可以通過結(jié)構(gòu)化查詢語言(SQL)來訪問.已有工作能夠在執(zhí)行一個(gè)SQL語句之前預(yù)計(jì)其資源使用量,因此與業(yè)務(wù)邏輯層不同,數(shù)據(jù)處理層可以通過禁止應(yīng)用執(zhí)行服務(wù)需求過大的查詢來避免資源劫持現(xiàn)象,使得查詢調(diào)度策略的制定不是需要解決的核心問題.在數(shù)據(jù)處理層內(nèi)部,MDSA將各個(gè)數(shù)據(jù)庫副本分配到各個(gè)數(shù)據(jù)庫節(jié)點(diǎn)之上,并采用文獻(xiàn)中的數(shù)據(jù)復(fù)制算法來保障副本之間的一致性.該算法采用了“讀一個(gè)寫全部(Read-One-Write-All)”模式,即將只讀查詢分配給租戶數(shù)據(jù)庫某一個(gè)副本來處理,將更新查詢分配給該租戶數(shù)據(jù)庫的所有副本來處理.數(shù)據(jù)復(fù)制策略實(shí)現(xiàn)的具體細(xì)節(jié)請(qǐng)參見文獻(xiàn).本節(jié)主要關(guān)心的是,在能夠保障各個(gè)副本一致性的基礎(chǔ)上,如何調(diào)整負(fù)載在副本間的分配以及副本在節(jié)點(diǎn)間的放置來保障性能指標(biāo).具體的,數(shù)據(jù)處理層的性能管理面臨著如下挑戰(zhàn):(1)負(fù)載分配策略的制定.在副本放置固定的前提下,如何將只讀負(fù)載分配到各個(gè)節(jié)點(diǎn)中是性能管理問題的一個(gè)關(guān)鍵子問題,其難點(diǎn)在于在有狀態(tài)性的制約下,如何盡可能的在節(jié)點(diǎn)間均衡負(fù)載,以提高系統(tǒng)的整體性能.(2)副本放置策略的制定.負(fù)載的劇烈變化會(huì)使得單獨(dú)通過負(fù)載分配難以實(shí)現(xiàn)節(jié)點(diǎn)間的負(fù)載均衡,系統(tǒng)需要調(diào)整副本到節(jié)點(diǎn)的映射以及數(shù)據(jù)庫節(jié)點(diǎn)的總量來進(jìn)一步均衡負(fù)載.在這個(gè)過程中,系統(tǒng)還需要考慮如何最小化資源使用量以及副本遷移次數(shù),這些要求進(jìn)一步增加了制定副本放置策略的難度.(3)副本調(diào)整的執(zhí)行.副本調(diào)整的執(zhí)行關(guān)注的指標(biāo)包括調(diào)整的速度、調(diào)整過程對(duì)一致性的影響、調(diào)整過程對(duì)性能的影響等等.本章的內(nèi)容主要關(guān)注于上述問題中的前兩個(gè).副本調(diào)整的執(zhí)行可以較為獨(dú)立地分析和求解,這方面的工作可以參考文獻(xiàn).多租戶數(shù)據(jù)管理系統(tǒng)主要由數(shù)據(jù)庫節(jié)點(diǎn)、租戶數(shù)據(jù)庫副本以及外部負(fù)載等幾方面構(gòu)成,其參數(shù)主要包括用于描述節(jié)點(diǎn)、租戶以及負(fù)載的基本參數(shù)、用于描述系統(tǒng)中可控部分的控制變量以及用于描述系統(tǒng)預(yù)期運(yùn)行狀態(tài)的閾值變量.為了便于問題討論,下面首先引入本節(jié)使用的一些符號(hào),見表3～表5.4.1負(fù)載均衡及最優(yōu)加權(quán)回轉(zhuǎn)調(diào)度為了準(zhǔn)確地分析負(fù)載分配問題,需要明確負(fù)載均衡程度的度量指標(biāo),并且建立數(shù)據(jù)庫節(jié)點(diǎn)的性能模型,以用來在真正調(diào)整資源管理策略之前預(yù)計(jì)調(diào)整的效果.借鑒已有工作,本文采用一個(gè)具有多個(gè)請(qǐng)求類型的M/G/1/PS隊(duì)列作為每個(gè)數(shù)據(jù)庫節(jié)點(diǎn)的性能模型.按照排隊(duì)論結(jié)果,在節(jié)點(diǎn)sj上執(zhí)行的請(qǐng)求的延長(zhǎng)因子為SFi,j=11-Uj=11-Ν∑i=1(λWi,jDWi+λRi,jDRi).為了衡量一個(gè)負(fù)載分配策略達(dá)到的負(fù)載均衡程度,我們定義如下概念.定義4.負(fù)載傾斜度Skew=Μ∑j=111-Uj,其中Uj是指節(jié)點(diǎn)sj的資源利用率,并且0≤Uj<1.基于該定義,我們可以得到負(fù)載傾斜度如下的性質(zhì):(1)當(dāng)某一節(jié)點(diǎn)的資源利用率較高時(shí),該節(jié)點(diǎn)對(duì)于負(fù)載傾斜度的貢獻(xiàn)會(huì)大大提高.當(dāng)某一節(jié)點(diǎn)的資源利用率趨近于100%時(shí),系統(tǒng)的負(fù)載傾斜度趨近于無窮大.(2)由于負(fù)載Λ是固定的,因此所有節(jié)點(diǎn)的資源利用率的和Μ∑j=1Uj也是固定的.在上述前提下,可以證明當(dāng)每個(gè)節(jié)點(diǎn)的資源利用率相同時(shí),負(fù)載傾斜度最小.上述兩個(gè)性質(zhì)說明,負(fù)載傾斜度能夠體現(xiàn)集群中節(jié)點(diǎn)負(fù)載的不均衡程度.基于以上得到的性能模型和度量指標(biāo),我們可以將負(fù)載均衡問題進(jìn)一步形式化為minSkew(λ)=Μ∑j=111-Ν∑i=1(λWi,jDWi+λRi,jDRi),其中的限定條件為?i∈[1,N],Μ∑j=1λRi,j=ΛRi(1)?i∈[1,N],j∈[1,M],λRi,j=0若Ai,j=0(2)?i∈[1,N],j∈[1,M],0≤λi,jR≤ΛiR(3)?i∈[1,Ν],j∈[1,Μ],λi,jW={ΛiW,Ai,j=10,Ai,j=0(4)∑i=1Ν(λi,jWDiW+λi,jRDiR)<1(5)其中約束(1)～(3)限定了讀請(qǐng)求分配的合理取值范圍.約束(4)限定了寫請(qǐng)求分配的合理取值范圍.約束(5)要求對(duì)每個(gè)節(jié)點(diǎn),為其分配的負(fù)載總和應(yīng)該小于其處理能力.上述問題屬于一類特殊的優(yōu)化問題,即資源分配問題.文獻(xiàn)給出了該問題的一個(gè)基于圖的高效算法.我們將該算法得到的負(fù)載分配矩陣稱為最優(yōu)負(fù)載均衡方案(WellBalancedLoad,WBL),并將上述算法稱為WBL生成算法.WBL只確定了整體上請(qǐng)求速率的分配,負(fù)載分配算法的實(shí)現(xiàn)還需要考慮每個(gè)請(qǐng)求的分配決策.為此,我們引入如下概念:如果在某一個(gè)負(fù)載分配算法A的控制之下得到的負(fù)載傾斜度與WBL之下的負(fù)載傾斜度相同,則稱A為一個(gè)WBL實(shí)現(xiàn)算法.下面給出了兩種WBL實(shí)現(xiàn)算法.首先,我們將WBL之下每個(gè)租戶ti分配到節(jié)點(diǎn)sj的負(fù)載強(qiáng)度λi,j用作加權(quán)輪轉(zhuǎn)調(diào)度算法的權(quán)重,并且將這一調(diào)度方式稱作最優(yōu)加權(quán)輪轉(zhuǎn)調(diào)度(OptimalWeightedRound-Robin,OWRR).由其定義可知,OWRR是一種WBL實(shí)現(xiàn)算法.其次,我們提出一個(gè)稱為SSQF(StatefulShortestQueueFirst)的算法,對(duì)于租戶t的請(qǐng)求,SSQF將其分發(fā)到存有t的數(shù)據(jù)副本的節(jié)點(diǎn)集合中隊(duì)列長(zhǎng)度最小的節(jié)點(diǎn).通過圖6所示的模擬實(shí)驗(yàn)結(jié)果可知(其設(shè)計(jì)細(xì)節(jié)參見第5.2小節(jié)),SSQF能夠達(dá)到與OWRR相近的負(fù)載均衡程度,因此SSQF也是一種WBL實(shí)現(xiàn)算法.這兩種算法的性能比較和適用性分析將在后面詳細(xì)介紹.4.2當(dāng)負(fù)載的波動(dòng)較為劇烈時(shí),單純改變負(fù)載的分配難以實(shí)現(xiàn)本節(jié)的整體目標(biāo),即在保障各個(gè)租戶性能指標(biāo)的前提下,最小化資源的消耗.進(jìn)一步實(shí)現(xiàn)該目標(biāo)需要將副本放置的動(dòng)態(tài)調(diào)整納入考慮范圍.具體的,同時(shí)考慮負(fù)載分配和副本放置兩種性能管理手段,數(shù)據(jù)處理層的性能管理目標(biāo)可以形式地定義為minf(λ,Α)=∑j=1Μkjming(λ,Α)=|Α-Α0|(6)其中的限定條件為Ai,j∈{0,1}(7)?i∈[1,N],∑j=1ΜAi,j∈[RminΤ,RmaxΤ](8)?j∈[1,Μ],kj={1,∑i=1ΝAi,j>00,∑i=1ΝAi,j=0(9)?i∈[1,N],j∈[1,M],λi,jR=0若Ai,j=0(10)?i∈[1,N],∑j=1Μλi,jR=ΛiR(11)?i∈[1,N],j∈[1,M],0≤λi,jR≤ΛjR(12)?i∈[1,Ν],j∈[1,Μ],λi,jW={ΛiW,Ai,j=10,Ai,j=0(13)?j∈[1,Μ],11-∑i=1Ν(λi,jWDiW+λi,jRDiR)≤SFmax(14)約束(8)限定了每個(gè)租戶數(shù)據(jù)庫副本個(gè)數(shù)的取值范圍.約束(9)限定了只有處于運(yùn)行狀態(tài)的節(jié)點(diǎn)才能放置數(shù)據(jù)副本.約束(10)～(12)限定了讀請(qǐng)求分配的合理取值范圍.約束(13)限定了寫請(qǐng)求分配的合理取值范圍.最后一個(gè)約束(14)限定了每個(gè)租戶的性能指標(biāo)要求.通過將上述問題規(guī)約為一個(gè)K-劃分問題可以得出該問題是NP難的,因此難以得到其最優(yōu)解.本文采用一種貪心策略來試圖找到一個(gè)較優(yōu)解.我們稱其為惰性副本管理算法LRM(LazyReplicaManagement).LRM由如下幾個(gè)部分構(gòu)成:圖7所示的節(jié)點(diǎn)提供算法DB-NP(NodeProvisioning)以及圖8所示的副本放置算法DB-RP(ReplicaPlacement).LRM在多處利用WBL生成算法作為啟發(fā),為方便起見,我們將某一節(jié)點(diǎn)sj在WBL之下的資源利用率記作UWBLj.DB-NP通過動(dòng)態(tài)調(diào)整系統(tǒng)的節(jié)點(diǎn)數(shù)量來適應(yīng)總體負(fù)載強(qiáng)度的變化.具體的,在縮減節(jié)點(diǎn)數(shù)量時(shí),DB-NP采用的策略是優(yōu)先考慮刪除WBL之下負(fù)載最輕的節(jié)點(diǎn).進(jìn)一步,刪除某些節(jié)點(diǎn)可能會(huì)使得某些租戶數(shù)據(jù)庫的副本數(shù)量小于RTmin,這時(shí)不能簡(jiǎn)單地拋棄這些數(shù)據(jù)副本,而是要將其遷移到某個(gè)保留的節(jié)點(diǎn)中.DB-NP同樣利用WBL來解決這一問題,即,將這些副本遷移到WBL之下負(fù)載最輕的節(jié)點(diǎn).DB-RP算法用來在負(fù)載變動(dòng)時(shí)調(diào)整副本放置來適應(yīng)系統(tǒng)負(fù)載中各租戶比例的變化.首先,DB-RP調(diào)用DB-NP來調(diào)整節(jié)點(diǎn)總量.隨后,DB-RP開始關(guān)注節(jié)點(diǎn)之間的負(fù)載均衡.從本質(zhì)上講,DB-RP是一種貪心的算法.在每一次選擇需要調(diào)整的副本時(shí),DB-RP首先選擇能夠最大化地縮減負(fù)載不平衡程度的副本.總的來看,LRM的惰性體現(xiàn)在如下幾個(gè)方面:首先,通過利用WBL生成算法作為啟發(fā),LRM優(yōu)先考慮使用負(fù)載分配來均衡各節(jié)點(diǎn)的負(fù)載.其次,LRM為每個(gè)租戶數(shù)據(jù)庫提供的副本數(shù)量具有一定的彈性,在新建副本時(shí),如果相應(yīng)的租戶數(shù)據(jù)庫的副本數(shù)量沒有超出最大值,則并不立即刪除某一原有副本;在刪除副本時(shí),如果相應(yīng)的租戶數(shù)據(jù)庫的副本數(shù)量沒有低于最小值,則并不立即在其他節(jié)點(diǎn)上創(chuàng)建一個(gè)新的副本.上述惰性特點(diǎn)使得LRM在保障數(shù)據(jù)庫節(jié)點(diǎn)資源利用率的同時(shí),能夠減少副本添加或者縮減的次數(shù),提高系統(tǒng)的穩(wěn)定性.5adrs具有優(yōu)化設(shè)計(jì)的過程本節(jié)分別從業(yè)務(wù)邏輯層和數(shù)據(jù)處理層兩個(gè)方面討論多租戶性能管理機(jī)制的效果.實(shí)驗(yàn)的目的有如下幾個(gè):(1)對(duì)ADRS帶來的開銷進(jìn)行定量分析.(2)驗(yàn)證ADRS能否有效地避免資源劫持請(qǐng)求帶來的性能下降.(3)驗(yàn)證LRM能否通過負(fù)載分配和副本調(diào)整適應(yīng)負(fù)載的動(dòng)態(tài)變化.其中前兩項(xiàng)是基于實(shí)驗(yàn)驗(yàn)證的,最后一項(xiàng)是基于模擬分析的.5.1adrs調(diào)度模式本文通過將一個(gè)針對(duì)單租戶的基準(zhǔn)測(cè)試應(yīng)用轉(zhuǎn)化到多租戶模式來構(gòu)造多租戶基準(zhǔn)測(cè)試應(yīng)用.我們采用的是TCP-W基準(zhǔn)測(cè)試應(yīng)用.該應(yīng)用是一個(gè)和Amazon類似的網(wǎng)上商店系統(tǒng).多租戶版本的TPC-W可以看作一個(gè)可以供多個(gè)客戶按需使用的網(wǎng)上店鋪.TPC-W提供了一個(gè)負(fù)載生成器來驅(qū)動(dòng)應(yīng)用的運(yùn)行.通過配置該生成器的模擬瀏覽器的個(gè)數(shù)可以改變其生成的負(fù)載強(qiáng)度.每個(gè)模擬瀏覽器按照預(yù)定的規(guī)則生成各種HTTP請(qǐng)求.在本文的多租戶背景下,我們?yōu)槊總€(gè)租戶運(yùn)行一個(gè)負(fù)載生成器,同時(shí)驅(qū)動(dòng)多個(gè)租戶應(yīng)用的運(yùn)行.所有的機(jī)器都采用相同的硬件配置,包括1.7GHz的CPU,512MB的內(nèi)存,40GB的硬盤.服務(wù)器安裝的操作系統(tǒng)都是Linux2.6.17.機(jī)器間采用100Mbps的以太網(wǎng)連接.應(yīng)用服務(wù)器使用的是Tomcat6.0.數(shù)據(jù)庫節(jié)點(diǎn)使用的是MySQL5.0.67.在實(shí)驗(yàn)中,我們采用操作系統(tǒng)默認(rèn)的調(diào)度策略(RR)作為ADRS的比較對(duì)象.圖9給出了在RR以及ADRS調(diào)度模式下TPC-W的性能隨負(fù)載變化的趨勢(shì),其中負(fù)載強(qiáng)度以所有租戶的模擬瀏覽器個(gè)數(shù)之和作為衡量標(biāo)準(zhǔn).對(duì)于每一個(gè)不同的配置,實(shí)驗(yàn)持續(xù)一個(gè)小時(shí),并將從第5min到第55min過程中的平均響應(yīng)時(shí)間記錄為實(shí)驗(yàn)結(jié)果.可以看出,在不存在資源劫持請(qǐng)求的情況下,ADRS與RR的性能較為接近.上述實(shí)驗(yàn)表明,ADRS帶來的性能開銷是可以接受的.圖10(a)給出了存在資源劫持請(qǐng)求條件下TPC-W的性能隨負(fù)載變化的趨勢(shì).其中,資源劫持請(qǐng)求占總請(qǐng)求的0.1%,每個(gè)資源劫持請(qǐng)求的平均服務(wù)需求為10s.可以看出,在存在資源劫持請(qǐng)求的情況下,ADRS的性能要明顯好于RR.當(dāng)模擬瀏覽器數(shù)目為600時(shí),ADRS的平均響應(yīng)時(shí)間比RR縮短了40%.圖10(b)截取了10min的實(shí)驗(yàn)片斷,以深入查看資源劫持請(qǐng)求到來時(shí)ADRS和RR的不同反應(yīng).可以看出,在RR調(diào)度策略之下,每個(gè)資源劫持請(qǐng)求的到來都會(huì)使得整體響應(yīng)時(shí)間迅速升高,而ADRS調(diào)度策略能夠較好地避免這一現(xiàn)象.上述實(shí)驗(yàn)結(jié)果說明,ADRS能夠較好地避免資源劫持現(xiàn)象.5.2u3000負(fù)載均衡我們采用模擬分析的方法來驗(yàn)證LRM能否通過負(fù)載分配和副本調(diào)整適應(yīng)負(fù)載的動(dòng)態(tài)變化.使用模擬器的原因在于:(1)能夠較為容易的模擬大規(guī)模的集群,繞過實(shí)際實(shí)驗(yàn)環(huán)境的限制.(2)剝離了副本調(diào)整執(zhí)行的復(fù)雜性.具體的,本節(jié)中使用的模擬環(huán)境的特征如下:(1)使用離散事件仿真的模式構(gòu)建,其最小時(shí)間粒度設(shè)定為1ms.(2)模擬器提供了兩種負(fù)載生成方式:合成負(fù)載和真實(shí)負(fù)載.對(duì)于合成負(fù)載,本文假定其請(qǐng)求的到來過程為泊松過程;請(qǐng)求的服務(wù)需求符合指數(shù)分布.對(duì)于真實(shí)負(fù)載,本文采用WorldCup98中采集到的真實(shí)記錄.默認(rèn)情況下,本文假定請(qǐng)求服務(wù)需求的平均值為50ms.(3)對(duì)于負(fù)載分配策略,模擬器實(shí)現(xiàn)了SRR、OWRR以及SSQF3種分配策略.此處SRR指的是有狀態(tài)的輪轉(zhuǎn)負(fù)載分配策略,該策略將針對(duì)每個(gè)租戶數(shù)據(jù)庫的查詢?cè)谠撟鈶舻乃懈北局g平均分配.由第4節(jié)討論的數(shù)據(jù)處理層性能管理的目標(biāo)可知,評(píng)價(jià)LRM的指標(biāo)主要有3個(gè):系統(tǒng)的總體資源利用率、每個(gè)租戶數(shù)據(jù)庫的性能以及副本調(diào)整的次數(shù).我們首先來單獨(dú)分析本文提出的負(fù)載分配策略的效果,即在總體資源利用率相同、副本放置固定的前提下,比較各個(gè)負(fù)載分配策略能夠達(dá)到的性能指標(biāo).圖11給出了模擬實(shí)驗(yàn)的結(jié)果,其中模擬器的參數(shù)配置如下:租戶數(shù)量為200,每個(gè)租戶的副本個(gè)數(shù)為4,節(jié)點(diǎn)數(shù)量為40.在模擬過程中逐步調(diào)整了整體負(fù)載強(qiáng)度以反映節(jié)點(diǎn)平均資源利用率的變化.從圖8可以看出,SSQF和OWRR的性能遠(yuǎn)遠(yuǎn)好于SRR.其原因在于SRR沒有從整體上協(xié)調(diào)各個(gè)租戶的負(fù)載,導(dǎo)致某些節(jié)點(diǎn)負(fù)載過重、某些節(jié)點(diǎn)負(fù)載過輕.而負(fù)載過重的節(jié)點(diǎn)上處理的請(qǐng)求的性能會(huì)大大降低.上述結(jié)果表明,與非WBL算法相比,實(shí)現(xiàn)了WBL的負(fù)載分配算法具有較好的性能.對(duì)比SSQF和OWRR可知,SSQF能夠達(dá)到比OWRR算法更好的性能.其原因在于,除了在宏觀上實(shí)現(xiàn)負(fù)載均衡,SSQF能夠利用系統(tǒng)的實(shí)時(shí)負(fù)載信息實(shí)現(xiàn)微觀上較優(yōu)的分配決策.而OWRR只是基于在一定時(shí)間周期內(nèi)得到的負(fù)載信息來更新各個(gè)節(jié)點(diǎn)的權(quán)重,沒能實(shí)現(xiàn)微觀上的優(yōu)化調(diào)度.基于上述結(jié)果,我們總結(jié)出這兩種算法各自的適用情形:(1)如果系統(tǒng)在分配每個(gè)請(qǐng)求時(shí)都能夠及時(shí)地得到各個(gè)節(jié)點(diǎn)的負(fù)載信息,使用SSQF算法.(2)如果系統(tǒng)只能周期性地得到各個(gè)節(jié)點(diǎn)的負(fù)載信息,使用OWRR算法.前面提到,單獨(dú)使用負(fù)載分配難以應(yīng)對(duì)整體負(fù)載強(qiáng)度以及負(fù)載組成的大幅波動(dòng),下面將副本放置的動(dòng)態(tài)調(diào)整納入考慮范圍,驗(yàn)證LRM能否使得系統(tǒng)在資源利用率較高的前提下保障每個(gè)租戶數(shù)據(jù)庫的性能指標(biāo).由于副本調(diào)整過程會(huì)影響系統(tǒng)的性能,因此我們期望副本調(diào)整的次數(shù)越少越好.副本調(diào)整可以細(xì)化為新建副本和刪除副本,新建副本的代價(jià)遠(yuǎn)遠(yuǎn)高于刪除副本,因而,在后續(xù)的實(shí)驗(yàn)中,我們使用新建副本次數(shù)作為另一個(gè)主要評(píng)價(jià)指標(biāo).我們使用WorldCup98的負(fù)載來驅(qū)動(dòng)各個(gè)租戶.具體的,我們從中選取了第15天至第34天共20天的負(fù)載,并將每一天的負(fù)載看作一個(gè)特定的租戶類型.以每個(gè)租戶類型為藍(lán)本,我們可以通過配置一個(gè)尺度參數(shù)來得到多個(gè)具體的租戶負(fù)載.具體的,本實(shí)驗(yàn)為每個(gè)租戶類型構(gòu)造了10個(gè)租戶,即系統(tǒng)共包含200個(gè)獨(dú)立的租戶.使用上述方式來生成多租戶負(fù)載的合理性可以從以下幾個(gè)方面體現(xiàn):(1)WorldCup98網(wǎng)站的負(fù)載隨著世界杯舉行日期的臨近而逐漸增大,因而每天的負(fù)載強(qiáng)度都有所不同.這個(gè)規(guī)律能夠?qū)?yīng)到多租戶應(yīng)用中各個(gè)租戶負(fù)載強(qiáng)度大小不均的情形.(2)圖12(a)～(c)給出了其中3天的負(fù)載變化過程,可以看出WorldCup98網(wǎng)站每天的負(fù)載變化規(guī)律不盡相同,能夠?qū)?yīng)各個(gè)租戶的負(fù)載有著獨(dú)立的變化規(guī)律的情形.(3)圖12(d)給出了總體負(fù)載的圖示,可以看出總體的負(fù)載也呈現(xiàn)出一定的變化規(guī)律,能夠?qū)?yīng)多租戶系統(tǒng)整體負(fù)載變化的情形.(4)使用同一SaaS應(yīng)用的租戶之間往往具有一定的相似性,可以歸納為多個(gè)類型,上述負(fù)載構(gòu)造過程體現(xiàn)了這種相似性.基于如上幾方面原因,我們將WorldCup98的負(fù)載轉(zhuǎn)化為多租戶數(shù)據(jù)管理服務(wù)的負(fù)載,并用來驅(qū)動(dòng)本小節(jié)的模擬實(shí)驗(yàn).圖13給出了LRM算法在上述負(fù)載下的性能表現(xiàn),其中負(fù)載分配算法使用的是SSQF.圖13(a)給出了服務(wù)器的總量隨時(shí)間的變化情況.圖13(b)給出了節(jié)點(diǎn)的平均資源利用率隨時(shí)間的變化情況.圖13(c)給出了副本移動(dòng)的次數(shù)隨時(shí)間的變化情況.圖13(d)給出了所有租戶的平均響應(yīng)時(shí)間隨時(shí)間的變化情況.從圖中可以看出,對(duì)于上述負(fù)載,LRM能夠較好地保障平臺(tái)整體的資源利用率.圖13(e)給出了系統(tǒng)中各個(gè)節(jié)點(diǎn)的請(qǐng)求到達(dá)速率隨時(shí)間的變化.可以看出,LRM算法并沒有實(shí)現(xiàn)各個(gè)節(jié)點(diǎn)的絕對(duì)負(fù)載均衡.該行為模式是由LRM算法需要在優(yōu)化負(fù)載均衡度的同時(shí)最小化副本調(diào)整的次數(shù)的目標(biāo)決定的.為此,LRM算法在均衡負(fù)載時(shí)采用惰性策略,只有負(fù)載不均衡程度非常嚴(yán)重時(shí)才會(huì)進(jìn)行副本調(diào)整.例如,考慮由圖10(c)中第50min時(shí)的一次副本調(diào)整.由圖10(e)可知,此次調(diào)整之前分配給節(jié)點(diǎn)4的請(qǐng)求遠(yuǎn)遠(yuǎn)小于其它節(jié)點(diǎn),此次調(diào)整在節(jié)點(diǎn)4上創(chuàng)建了一個(gè)新的副本,并將一部分負(fù)載分配給該節(jié)點(diǎn).在此次調(diào)整完成之后,節(jié)點(diǎn)4處理的請(qǐng)求量有了顯著增加.盡管此時(shí)節(jié)點(diǎn)4的負(fù)載仍然小于其它節(jié)點(diǎn),但由于每個(gè)節(jié)點(diǎn)的資源利用率以及平臺(tái)整體的資源利用率都處于預(yù)先定義的范圍內(nèi),LRM算法并沒有進(jìn)一步增加節(jié)點(diǎn)4維護(hù)的副本數(shù)量.6性能管理手段針對(duì)Web應(yīng)用服務(wù)器端的性能管理問題,前人已經(jīng)做了大量的工作.鑒于本文主要討論的性能管理手段包括請(qǐng)求調(diào)度、負(fù)載均衡以及副本管理,本節(jié)主要從上述幾個(gè)方面來分析相關(guān)工作,并討論已有工作在多租戶應(yīng)用中的適用性以及和本文提出的技術(shù)之間的異同.更多的相關(guān)工作分析請(qǐng)參見文獻(xiàn).6.1adrs調(diào)度算法的實(shí)現(xiàn)單服務(wù)器請(qǐng)求調(diào)度問題的形式化描述和理論分析已經(jīng)有了較多的工作.以平均響應(yīng)時(shí)間為目標(biāo),最短剩余處理時(shí)間優(yōu)先(SRPT)調(diào)度策略已經(jīng)被證明是最優(yōu)的調(diào)度策略.但是SRPT要求預(yù)先知道每一個(gè)請(qǐng)求的服務(wù)需求,這在實(shí)際的系統(tǒng)中往往是不可行的.從實(shí)際系統(tǒng)設(shè)計(jì)的角度,對(duì)性能影響最大因素在于如何處理并發(fā)的請(qǐng)求.事件驅(qū)動(dòng)的模型和多線程模型是兩種主流的并發(fā)處理模型.事件驅(qū)動(dòng)模型使用一個(gè)接收器線程通過一個(gè)I/O選擇器(selector)監(jiān)聽來自于所有請(qǐng)求的I/O事件.一旦某個(gè)請(qǐng)求到來或者其處理過程中的I/O操作完成時(shí),接收器線程將其分配到某一個(gè)工作線程繼續(xù)處理該請(qǐng)求.當(dāng)該請(qǐng)求的處理過程中遇到新的I/O時(shí),工作線程再次將該請(qǐng)求注冊(cè)到selector之上等待其I/O處理完成.事件驅(qū)動(dòng)模式只需要維護(hù)少量的工作線程(每個(gè)CPU一個(gè)工作線程),因而縮減了線程上下文切換的開銷.然而請(qǐng)求處理過程中只有遇到I/O操作才會(huì)導(dǎo)致請(qǐng)求的切換,進(jìn)一步的控制需要程序員的顯式參與,因此增加了編程負(fù)擔(dān).由于這樣的限制,事件驅(qū)動(dòng)的編程模型往往只用在靜態(tài)Web服務(wù)器等特定的應(yīng)用類型的設(shè)計(jì)之中,不適用于實(shí)現(xiàn)通用的應(yīng)用服務(wù)器.多線程模型為每個(gè)請(qǐng)求分配一個(gè)線程進(jìn)行處理.由于線程之間的調(diào)度是由操作系統(tǒng)完成的,因而多線程模式下程序員不需要顯式考慮并發(fā)請(qǐng)求的調(diào)度.簡(jiǎn)單的多線程模型會(huì)導(dǎo)致線程頻繁的創(chuàng)建和結(jié)束,進(jìn)而對(duì)系統(tǒng)的性能造成影響.另外線程數(shù)量過大也會(huì)增加線程上下文切換的開銷.因此,多線程模型往往與一個(gè)線程池搭配使用.當(dāng)并發(fā)的請(qǐng)求數(shù)量超出線程池的大小時(shí),后到達(dá)的請(qǐng)求會(huì)被放置在一個(gè)外部請(qǐng)求隊(duì)列中.相應(yīng)的,多線程模式下請(qǐng)求的調(diào)度又可以細(xì)分為外部隊(duì)列調(diào)度和線程池調(diào)度.外部隊(duì)列調(diào)度考慮如何對(duì)請(qǐng)求進(jìn)入線程池的順序進(jìn)行調(diào)整來優(yōu)化系統(tǒng)的性能.然而,外部調(diào)度往往假定每個(gè)Web請(qǐng)求的服務(wù)需求是已知的,基于先驗(yàn)知識(shí)來設(shè)計(jì)調(diào)度策略,但在實(shí)際系統(tǒng)中,準(zhǔn)確預(yù)測(cè)請(qǐng)求的服務(wù)需求往往較為困難.線程池內(nèi)部調(diào)度關(guān)注的是如何調(diào)度正在處理不同請(qǐng)求的多個(gè)線程以優(yōu)化系統(tǒng)性能.然而,針對(duì)于Web應(yīng)用,由于線程池的廣泛使用,使得每個(gè)線程與請(qǐng)求之間不存在一一對(duì)應(yīng)的關(guān)系,進(jìn)而導(dǎo)致線程調(diào)度無法直接為請(qǐng)求調(diào)度帶來好處.由于線程調(diào)度的復(fù)雜性,通過線程池內(nèi)部請(qǐng)求調(diào)度來優(yōu)化Web應(yīng)用性能的工作相對(duì)較少.文獻(xiàn)通過Linux系統(tǒng)的內(nèi)核進(jìn)行修改,實(shí)現(xiàn)了一個(gè)支持多級(jí)處理器共享調(diào)度模式的請(qǐng)求調(diào)度器SRQ.由于涉及到系統(tǒng)內(nèi)核的修改,應(yīng)用上述兩種技術(shù)都需要對(duì)操作系統(tǒng)、語言運(yùn)行環(huán)境一直到應(yīng)用中間件等各個(gè)層