基于OpenStack的云存儲技術(shù)

熊建

摘要

隨著大數(shù)據(jù)時代的來臨，數(shù)據(jù)信息的存儲呈現(xiàn)出爆發(fā)式的增長，在數(shù)據(jù)挖掘、視頻點(diǎn)播等各個領(lǐng)域，大數(shù)據(jù)量的存儲都占據(jù)著重要的地位，對現(xiàn)有的存儲方案和存儲技術(shù)都提出了嚴(yán)峻的挑戰(zhàn)。尤其是對于目前最火的互聯(lián)網(wǎng)行業(yè)來說，數(shù)據(jù)就是它們的命脈。本文重點(diǎn)研究了OpenStack的存儲技術(shù)，該技術(shù)是通過代理節(jié)點(diǎn)的方式對外提供服務(wù)，當(dāng)訪問量特別大時，尤其是電商網(wǎng)站，訪問的性能會出現(xiàn)很大的影響，需要對負(fù)載均衡問題進(jìn)行處理。本文提出了一種基于時延的遷移策略來解決該問題。

【關(guān)鍵詞】OpenStack 云存儲 代理節(jié)點(diǎn) 訪問性能 負(fù)載均衡

1 引言

在云存儲系統(tǒng)中，主要的操作就是I/O才做，也就是輸入和輸出，外部調(diào)用服務(wù)存儲數(shù)據(jù)，也可查詢數(shù)據(jù)。I/O任務(wù)往往都具有很大的隨機(jī)性，這時就會出現(xiàn)有的節(jié)點(diǎn)超負(fù)荷工作，有的節(jié)點(diǎn)被閑置下來，從而就引發(fā)了負(fù)載不均衡的問題，產(chǎn)生了嚴(yán)重的性能問題。尤其是對于電商網(wǎng)站來說，經(jīng)常會做大型的活動，每秒的訪問量都有可能達(dá)到上百萬次。要想解決這種問題，就需要重新分配各個節(jié)點(diǎn)的工作量，優(yōu)化資源配置，從而提高整體的性能指標(biāo)。一般來說，負(fù)載均衡有兩種表現(xiàn)形式，一種是將大量的訪問量分配到各個分服務(wù)器上進(jìn)行處理，減少訪問的響應(yīng)時間，另一種是當(dāng)某個節(jié)點(diǎn)負(fù)載較大時，將其任務(wù)量分配到其他的節(jié)點(diǎn)，降低它的工作量。

2 swift對象存儲

Swift對象存儲是OpenStack云計算平臺的主要項(xiàng)目，它提供了強(qiáng)大的持久性云存儲服務(wù)，主要用來存儲長期保存的靜態(tài)數(shù)據(jù)，如郵件存儲、日志、圖片文件、存儲當(dāng)貝等類型的數(shù)據(jù)。Swift是一個可擴(kuò)展、存多份的分布式存儲系統(tǒng)，沒有主控節(jié)點(diǎn)，可擴(kuò)展到PB級另1J0主要有consistency server、storage server和proxy server組成。一致性服務(wù)和存儲服務(wù)部署在同一個存儲節(jié)點(diǎn)上，所有的認(rèn)證都使用keystone驗(yàn)證和授權(quán)。其架構(gòu)部署圖如圖1所示。

3 proxy負(fù)載均衡

Swift各個組件之間的通信主要有代理服務(wù)器負(fù)責(zé)。有關(guān)swift的所有服務(wù)都需要通過proxy，它提供了符合HTTP協(xié)議的對外API接口，外部只需要訪問該API接口就可以完成輸入輸出等操作。由于proxy起著主要的通信作用，因此負(fù)載均衡的主要任務(wù)就在它身上，需要對proxy加入負(fù)載均衡才能保證系統(tǒng)的穩(wěn)定性，否則集群存儲系統(tǒng)也無法充分的發(fā)揮各自的作用。隨著互聯(lián)網(wǎng)的興起，對網(wǎng)絡(luò)帶寬和數(shù)據(jù)存儲處理能力提出了更加嚴(yán)格的要求，普通的單一服務(wù)器無法滿足其需求，而超級計算機(jī)又太貴，因此，集群服務(wù)器成了一種趨勢。有很多的創(chuàng)業(yè)公司都無法承擔(dān)這種復(fù)雜的任務(wù)或者費(fèi)用，多數(shù)租借阿里云、新浪云、百度云或者騰訊云作為自己的云存儲服務(wù)器。而這些阿里云、騰訊云由于其自身企業(yè)的需要，也需要眾多的服務(wù)器資源，因此建立商業(yè)化的、高性能的云存儲服務(wù)對外提供服務(wù)的同時，也能作為自己盈利的一個方向。

4 負(fù)載均衡的改進(jìn)

負(fù)載均衡主要有兩種策略可以實(shí)現(xiàn)，一種是通過調(diào)整對應(yīng)的I/O策略，讓集中的訪問均勻的分布在各個存儲服務(wù)器節(jié)點(diǎn)上，每個節(jié)點(diǎn)都會得到均勻的訪問，從而能夠更好的工作。另外一種是檢測空閑的節(jié)點(diǎn)和負(fù)載過重的節(jié)點(diǎn)，一旦發(fā)現(xiàn)有負(fù)載過重的節(jié)點(diǎn)，就會立馬把任務(wù)往空間的節(jié)點(diǎn)上分配，對于每一個節(jié)點(diǎn)的負(fù)載都會有一個隊(duì)列去記錄其負(fù)載量。從而合理的分配各個節(jié)點(diǎn)的負(fù)載。

常見的動態(tài)負(fù)載調(diào)度算法有輪叫調(diào)度、加權(quán)輪叫調(diào)度、最小連接調(diào)度、加權(quán)最小連接調(diào)度、基于局部性的最少連接調(diào)度、帶復(fù)制的基于局部性最小連接調(diào)度。

4.1 WLC調(diào)度算法

綜合考慮資源消耗和性能，在上述的六種動態(tài)調(diào)度算法中，效果最為理想的是加權(quán)最小連接調(diào)度算法，該算法根據(jù)各個存儲服務(wù)節(jié)點(diǎn)的處理能力，賦予不同的權(quán)值，然后用這些權(quán)值來代表其存儲和處理能力。在服務(wù)器節(jié)點(diǎn)權(quán)值設(shè)置中，對于不可用的服務(wù)器權(quán)值設(shè)置為1，管理員可根據(jù)每一個服務(wù)器性能的好壞對他們賦予不同的權(quán)值。每一個服務(wù)器的負(fù)載是通過當(dāng)前服務(wù)器連接的活躍數(shù)量來決定的，活躍的連接數(shù)越多，代表該服務(wù)器的負(fù)載量越大，反之該服務(wù)器的負(fù)載量越小。加權(quán)最小連接調(diào)度算法的流程如下：

假設(shè)有一個服務(wù)器集群S={S1，S2，S3，S4，……，Sn}，各個服務(wù)器Si的權(quán)值為W（Si），C（Si）表示當(dāng)前服務(wù)器節(jié)點(diǎn)的活躍數(shù)量，也就是負(fù)載數(shù)量。所有節(jié)點(diǎn)的負(fù)載總數(shù)之和為

當(dāng)有新的請求到達(dá)分配調(diào)度時，需要滿足一定的判斷條件：

該算法充分的考慮了每一個節(jié)點(diǎn)的處理能力，因此避免了因?yàn)楣?jié)點(diǎn)處理能力的不同導(dǎo)致出現(xiàn)的雖然分配均衡，但任然出現(xiàn)嚴(yán)重的性能問題現(xiàn)象，進(jìn)一步的均衡了每一個節(jié)點(diǎn)的負(fù)載。

4.2 改進(jìn)的負(fù)載均衡算法

4.1中的WLC加權(quán)最小連接調(diào)度算法的負(fù)載效果已經(jīng)很好了，但是也存在著巨大的局限性：

（1）使用連接的數(shù)量作為負(fù)載的數(shù)量，無法準(zhǔn)確的表示當(dāng)前服務(wù)器節(jié)點(diǎn)的負(fù)載情況；

（2）服務(wù)器節(jié)點(diǎn)的權(quán)值是通過手動的方式設(shè)置的，可能并不能準(zhǔn)確的表示該服務(wù)器節(jié)點(diǎn)的處理能力。

對于服務(wù)器節(jié)點(diǎn)來說，它的負(fù)載能力應(yīng)該通過該服務(wù)器節(jié)點(diǎn)的I/O、內(nèi)存和CPU等資源情況來綜合計算出來，而不是僅僅使用連接數(shù)量來表示。通過手動設(shè)置權(quán)值的方式，有可能會導(dǎo)致不合理的權(quán)值分配，結(jié)果導(dǎo)致整個集群系統(tǒng)在性能和效率上降低。

結(jié)合proxy-server和Swift的特點(diǎn)，改進(jìn)的負(fù)載均衡算法，在4.1中加權(quán)最小連接算法的基礎(chǔ)上，增加了CPU使用情況的統(tǒng)計，從而提出了一種改進(jìn)的負(fù)載均衡算法。由于I/O時間的差異不大，proxy屬于Ring上的一種映射關(guān)系，因此主要的不同就在CPU上。因此，改進(jìn)的負(fù)載均衡算法將以CPU利用率和活躍連接數(shù)的數(shù)量作為節(jié)點(diǎn)負(fù)載情況的計算結(jié)果。算法的主要思想如下：

負(fù)載分配調(diào)度器會在每個周期T時，向每一個服務(wù)器節(jié)點(diǎn)發(fā)送CPU利用率請求，獲取每一個服務(wù)器節(jié)點(diǎn)的CPU利用率。然后結(jié)合4.1中的活躍連接數(shù)計算出當(dāng)前服務(wù)器節(jié)點(diǎn)的負(fù)載。為了避免由于周期T的不合理導(dǎo)致的頻繁請求或者不準(zhǔn)確，因此根據(jù)經(jīng)驗(yàn)值，將時間T設(shè)置為5-30秒之間。

通過上述的方式，可以比4.1中的算法，更好的反應(yīng)各個服務(wù)器節(jié)點(diǎn)的負(fù)載情況，要想更加準(zhǔn)確的反應(yīng)每一個節(jié)點(diǎn)的負(fù)載情況，就需要通過動態(tài)的調(diào)整權(quán)值的方式。在本文中，利用CPU的利用率來動態(tài)調(diào)整權(quán)值，比如當(dāng)出現(xiàn)某一個服務(wù)器A出現(xiàn)負(fù)載不均衡的情況時，就需要調(diào)用負(fù)載均衡的算法，如果調(diào)用了3次以上，仍然無法調(diào)整負(fù)載均衡，就有可能是權(quán)值設(shè)置的不合理，就需要調(diào)整該服務(wù)器節(jié)點(diǎn)的權(quán)值。

通過以上的方式，在改進(jìn)的負(fù)載均衡算法中加入了對CPU利用率和節(jié)點(diǎn)請求數(shù)量來計算每個服務(wù)器節(jié)點(diǎn)的負(fù)載，在通過不停的請求服務(wù)器節(jié)點(diǎn)的CPU利用率，來不斷的調(diào)整權(quán)值，如果出現(xiàn)連續(xù)負(fù)載不均衡，及時調(diào)整權(quán)值等多種方法，來改進(jìn)負(fù)載均衡算法，從而盡可能的提升集群服務(wù)器的訪問性能和效率。

4.3 改進(jìn)算法性能測試

為了更加準(zhǔn)確的仿真OpenStack集群的負(fù)載均衡問題，本文中使用WAS軟件來作為性能測試的工具，通過虛擬用戶發(fā)送請求到集群服務(wù)器，并實(shí)時統(tǒng)計各個服務(wù)器節(jié)點(diǎn)的性能和負(fù)載情況，從而驗(yàn)證算法的高效性。Proxy負(fù)載均衡部署圖如圖2所示。

負(fù)載情況以八次不同的訪問量為準(zhǔn)，平均的響應(yīng)時間如表1所示。

通過表1可以看出，在訪問量比較少時，WLC算法的平均響應(yīng)時間要比改進(jìn)的算法少，說明了在訪問量低的情況下，WLC算法要優(yōu)于改進(jìn)的負(fù)載均衡算法。但是隨著訪問量的不斷增加，會看到改進(jìn)算法的優(yōu)勢越來越明顯，改進(jìn)算法的平均響應(yīng)時間在不斷減少，當(dāng)達(dá)到2萬以上時，改進(jìn)的負(fù)載均衡算法的評價響應(yīng)時間要少于WLC算法的一半，這說明了一旦達(dá)到百萬訪問級別之后，兩種負(fù)載均衡算法的優(yōu)勢將會很明顯的顯現(xiàn)出現(xiàn)，改進(jìn)算法的性能將會大大的優(yōu)于WLC算法，這也驗(yàn)證了本文提出的改進(jìn)算法的有效性和合理性。

5 結(jié)束語

本文主要研究了基于OpenStack的云存儲技術(shù)，隨著互聯(lián)網(wǎng)和大數(shù)據(jù)技術(shù)的火爆，云存儲技術(shù)作為各種技術(shù)的基礎(chǔ)服務(wù)承擔(dān)著非常重要的作用，在本文中，主要討論和研究了基于OpenStack的云存儲所面臨的負(fù)載不均衡的問題，將proxy所造成的負(fù)載不均衡問題進(jìn)行改進(jìn)，在傳統(tǒng)的WLC算法的基礎(chǔ)上加入了CPU利用率的指標(biāo)，并且可以動態(tài)的改變各個服務(wù)器節(jié)點(diǎn)的權(quán)值，從而更加準(zhǔn)備的表示了各個服務(wù)器節(jié)點(diǎn)的負(fù)載，最終準(zhǔn)確的執(zhí)行負(fù)載均衡算法，確保各個服務(wù)器節(jié)點(diǎn)都能夠高效的被利用，整體的集群服務(wù)器性能和效率也得到了大大的提升。

參考文獻(xiàn)

[1]王彬.基于OpenStack的云平臺管理系統(tǒng)的設(shè)計與實(shí)現(xiàn)[D].北京交通大學(xué)，2016.

[2]晏強(qiáng)，張曉鋒，丁蕊.云存儲技術(shù)研究[J].計算機(jī)與信息技術(shù)，2011（12）.