丁璽潤1,2,，陳梅1,2,，李暉1,2

　　（1.貴州大學 計算機科學與技術學院,，貴州 貴陽 550025,；2.貴州大學 貴州省先進計算與醫(yī)療信息服務工程實驗室，貴州 貴陽 550025）

　　摘要：隨著Docker等的問世,，基于容器的操作系統(tǒng)級虛擬化技術受到云計算廠商的廣泛關注,。針對云平臺上不同應用領域的數據庫容器（面向事務型任務的數據庫容器與面向分析型任務的數據庫容器）在運行時對宿主機資源需求的差異,，提出一種面向容器的數據重分布策略，用于優(yōu)化容器中數據庫服務的性能。實驗結果表明,，該策略達到了預期效果,，可以有效提升容器中數據庫服務的性能,。

　　關鍵詞：云計算,；虛擬化；數據庫,；容器,；數據重分布

0引言

　　以Docker為代表的Linux容器技術為云平臺提供了更輕量級的虛擬化解決方案。Linux容器技術是一種內核虛擬化技術（即操作系統(tǒng)級虛擬化技術）,，它提供了輕量級的虛擬化解決方案,。可以在一臺主機上通過隔離進程和資源,，同時提供多個虛擬環(huán)境（即容器）,。每個容器都擁有自己的進程和獨立的網絡空間。從用戶角度看,，一個運行的容器與一臺運行的主機無異,。

　　基于容器的虛擬化技術通過隔離操作系統(tǒng)的對象，例如PID,、UID,、系統(tǒng)共享內存、IPC等,，實現對不同容器提供不同的系統(tǒng)視圖,，并且通過Cgroups和Namespace技術實現。Linux容器技術在資源管理方面依賴于Linux內核的Cgroups,，它是Linux內核提供的一個基于進程組的資源管理框架,，為特定的進程組限定可以使用的資源。Linux在隔離控制方面依賴于Linux內核的Namespace,，即將原來的全局對象隔離到不同的Namespace里,，不同容器之間不可見,。

　　目前,，應用廣泛的虛擬化技術包括以VMWare和微軟的Virtual PC為代表的全虛擬化技術以及以Xen為代表的半虛擬化技術,。與上述技術相比，容器級虛擬化可以直接運行CPU指令,，避免全虛擬化指令級模擬或即時編譯造成的系統(tǒng)開銷,，同時也避免了半虛擬化和系統(tǒng)調用替換的復雜操作。因此,，容器級虛擬化技術比傳統(tǒng)虛擬化技術具有更輕量級,，但是容器技術強制所有容器必須使用與宿主機相同的內核。

　　文獻［12］指出,，運行在云平臺上的服務,，例如Web服務，容易受到網絡帶寬,、CPU,、內存的影響，導致其服務質量降低,。傳統(tǒng)的解決方案是遷移云平臺上運行該服務的虛擬機到其他節(jié)點,，即VirtualtoVirtual。云平臺上面向容器的數據重分布技術與其類似,，通過遷移一臺宿主機的容器及其數據卷到另一臺宿主機,，以解決容器中服務的性能問題。本文針對云平臺上數據庫容器,，設計并實現了LXCDDS,，一種云平臺上面向容器的數據重分布策略，用于提升云平臺上Linux容器中不同類型任務（事務型和分析型）的數據庫服務的性能,。

1相關工作

　　1.1Docker

　　Linux容器技術（Linux Containers,，LXC）起源于1982年，由于操作復雜和維護困難等原因一直沒有得到廣泛應用,，直到Docker的出現,，Linux容器技術再次受到業(yè)界認可。Docker是dotCloud公司發(fā)起的一個開源項目,。它始于2013年初,，采用Go語言實現，以Linux容器技術為基礎,，目標是“Build, Ship, Run”,，即“一次部署，多處運行”,。文獻［34］中指出,，對于開發(fā)和運維人員來說，最希望的是一次創(chuàng)建或配置,，在任意環(huán)境中運行,。Docker的出現使之成為可能,。同時，基于操作系統(tǒng)級虛擬化技術實現的Docker,，比傳統(tǒng)的虛擬機技術更輕量化,，更易于遷移和擴展。因此,，本文采用Docker作為Linux容器技術的一種實現,。

　　1.2Flocker

　　本文采用Flocker作為容器中的數據遷移工具。Flocker是ClusterHQ公司的開源項目,，它提供了容器數據卷管理以及多主機Docker集群管理功能,。數據卷是一個可供一個或多個容器使用的特殊目錄，它繞過UFS,，可以在容器之間共享和重用,。Docker容器的數據卷可以用來存儲容器中的數據，一旦Docker容器由于某種原因宕機,，可以通過相應的數據卷恢復容器中的數據,，因此，常用在提供數據庫服務的容器中,。

　　Docker容器的數據卷只能綁定在一臺Docker宿主機上,，不能遷移到集群中的其他節(jié)點。Flocker中的數據卷也稱作數據集(dataset),，它可以隨著容器遷移到集群中的任何節(jié)點,。Flocker項目的核心是Control Service，它提供一個簡單的REST API,，Flocker Control Service使用Flocker API管理集群中的節(jié)點,，通過Flocker API，開發(fā)人員可以在多主機集群中部署多容器應用,，在集群中遷移容器及其數據卷,。目前，Docker官方正在測試Flocker項目,，并計劃將其作為未來Docker數據卷管理工具,。

2容器級數據重分布策略的設計與實現

　　2.1容器級數據重分布策略的設計

　　在Linux容器中可以運行各種應用服務，其中數據庫服務是最常見的也是最重要的應用服務,，因此,，本文重點研究如何提升Linux容器中數據庫服務的性能。

　　數據庫服務按照應用領域可以劃分為面向事務型任務的數據庫(即OLTP型數據庫)和面向分析型任務的數據庫(即OLAP型數據庫),。本文研發(fā)的容器級數據重分布策略旨在將這兩種類型的數據庫容器重新分配到集群中的不同節(jié)點,，并且通過調整節(jié)點的系統(tǒng)配置，分別提升這兩種類型的數據庫服務的性能,。

　　如圖1所示,，假設云平臺上運行Linux容器的集群中有兩個節(jié)點Node 1和Node 2,，在這兩個節(jié)點上分別運行著幾個Linux容器，其中T代表OLTP型數據庫容器,，A代表OLAP型數據庫容器。容器級數據重分布策略的本質是將這兩種執(zhí)行不同任務的數據庫容器轉移到各自的節(jié)點上,，讓同一種任務類型的數據庫容器運行在同一臺節(jié)點或同一集群上,，即將T類型容器全部遷移到Node 1節(jié)點中，A類型容器全部遷移到Node 2節(jié)點中,，最終狀態(tài)如圖2所示,。

　　從并發(fā)角度分析：對于OLTP型數據庫服務［56］，執(zhí)行I/O操作比CPU計算操作占用更多CPU時間片,。該服務的線程負責阻塞I/O,，當某一線程因為I/O阻塞進入阻塞狀態(tài)后，該線程的調度被操作系統(tǒng)內核停止,，不再占用CPU時間片段,。而其他I/O線程立即被操作系統(tǒng)內核調度，待I/O阻塞操作完成,，原來阻塞狀態(tài)的線程重新變成就緒狀態(tài)時,，可以被操作系統(tǒng)調度。因此,，理論上,，為圖2中Node 1的所有容器進程設置更多的I/O密集型線程可以提升該節(jié)點中OLTP型數據庫服務的效率。

　　相反,，對于OLAP型數據庫服務,，CPU需要執(zhí)行大量的連接、聚集操作,，而對于這種計算密集型任務,，進程中的線程越多，導致進程內每個線程的執(zhí)行時間越短,，從而影響數據分析效率,。因此，理論上,，為圖2中Node 2的所有容器進程設置更少的計算密集型線程可以提升該節(jié)點中OLAP型數據庫服務的效率,。

　　綜上所述，該容器級數據重分布策略從理論上可以提升Linux容器中數據庫服務的性能,。此外,，出于簡化運維和業(yè)務管理的需要，在同一數據中心中,，通常也更希望將同類型業(yè)務部署在物理位置更靠近的集群節(jié)點中,。

　　2.2容器級數據重分布策略的實現

　　在實際應用中有兩種情況造成圖1所示的不同類型的容器不均勻地分布在不同節(jié)點上,。第一種情況，在數據庫容器運行前,，運維人員不清楚或未對數據庫容器執(zhí)行的任務類型進行分類,，因此，導致面向事務型和面向分析型任務的數據庫容器隨機地分布到不同節(jié)點中,。第二種情況,，運維人員已經對數據庫容器執(zhí)行的任務進行分類，但由于運行同一類任務的容器的宿主機資源不足,，不能讓待運行的容器在這臺節(jié)點上運行,，而運行另一類任務的容器的宿主機可以滿足這個容器的運行條件，因此它將運行在與自己不同任務類型的容器的宿主機上,。

　　例如,，如圖2所示，T類型任務運行在Node 1上,，A類型任務運行在Node 2上,，此時有1個T類型任務容器待運行，恰好Node 1不能提供它運行所需的資源,，而Node 2可以滿足這個容器運行的條件,，因此這個新的T類型任務的容器被部署在Node 2上。經過一段時間,，兩個宿主機中就會同時運行多種類型的容器,。

　　對于第一種情況，不確定節(jié)點中運行的容器哪些是T類型哪些是A類型,。由于每個正在運行的數據庫容器都有一個通過容器ID與它綁定的數據卷,，該數據卷中存儲了該數據庫的數據、日志信息以及配置信息,，通過解析該數據庫的日志信息,，可以確定其執(zhí)行更新操作和查詢操作數目的比例，以及執(zhí)行更新操作和查詢操作消耗的時間,。執(zhí)行事務型任務的數據庫,，其更新操作頻繁，日志中更新操作的比例很高,，且執(zhí)行查詢操作消耗的時間較短,。反之，執(zhí)行分析型任務的數據庫,，其更新操作非常少,，但是由于其經常做復雜分析操作，需要執(zhí)行大量JOIN操作和聚集操作，查詢執(zhí)行時間較長,。因此,，可以確定節(jié)點中的容器哪些是T類型哪些是A類型。

　　2.3分布式環(huán)境下容器級數據重分布算法

　　算法1為分布式環(huán)境下容器級數據重分布算法,。該算法核心思想：首先,，確定節(jié)點Node中每一個數據庫容器的類型Type；然后,，對于不符合本節(jié)點容器類型的數據庫容器,，將其加入到待遷移隊列MoveList中；最后,，找到待遷移的目標節(jié)點TargetNode，判斷其是否有足夠資源運行該容器,，如果條件滿足,，則通過Flocker完成容器遷移，否則等待資源,。算法代碼描述如下：算法1 Data Distribution Algorithm輸入: NodeID, TargetNodeID, TypeNode, MoveList

　　輸出: NULL

　　1: while true do

　　2:if HasNewContainers()=true then

　　3:for each c in ListContainers(NodeID) do

　　4:TypeContainer ( GetContainType(c);

　　5:if TypeContainer= TypeNode then

　　6:else

　　7:if IfNodeInList(c)=false then

　　8:AddMoveList(c,MoveList);

　　9:end if

　　10: end if

　　11: end for

　　12: end if

　　13: while (HasElmts(MoveList)=true and

　　HasRes(TargetNodeID)=true) do

　　14: e ( GetNextContainer(MoveList);

　　15: DataMovement(e);

　　16: RmFromMoveList(e, MoveList);

　　17: end while

　　18:end while

3實驗結果與分析

　　3.1實驗環(huán)境及實驗方案

　　本實驗使用的硬件及系統(tǒng)配置見表1,。實驗中使用的數據庫容器是DockerHub提供的PostgreSQL9.4.4官方鏡像，其配置為shared_buffers=128 MB,，其他參數為PostgreSQL系統(tǒng)默認參數,。實驗使用標準的TPC-H benchmark對OLAP型數據庫的數據分析性能進行測試，總數據量為1 GB,。本實驗同時使用標準的TPC-C benchmark對OLTP型數據庫的事務性能進行測試,。

　　實驗一：4核CPU；

　　實驗二：8核CPU內存8 GB硬盤120 GB,， 15 000 r/min操作系統(tǒng)CentOS 7（內核3.10.0）Docker版本1.7.1Flocker版本1.0.3PostgreSQL9.4.4實驗一和實驗二的實驗過程相同,。首先，初始狀態(tài)時兩個節(jié)點中分別運行3個OLTP型PostgreSQL容器和3個OLAP型PostgreSQL容器,，對其中的1個OLTP型PostgreSQL容器進行TPCC benchmark測試,，同時對1個OLAP型PostgreSQL容器進行TPCH benchmark測試，得到實驗結果,。然后,，采用容器級數據重分布策略將OTLP型數據庫和OLAP型數據庫分離，使得其中一個節(jié)點上運行6個OLTP型PostgreSQL容器,，另一個節(jié)點上運行6個OLAP型PostgreSQL容器,，分別對OLTP型PostgreSQL容器進行TPCC benchmark測試，對OLAP型PostgreSQL容器進行TPCH benchmark測試,，得到實驗結果,。最后分別測試節(jié)點中僅運行1個數據庫容器時的OLTP性能和OLAP性能作為參考，得到對此結果。

　　3.2實驗結果分析

　　實驗一的結果如圖3,、圖4所示,。圖3中顯示了執(zhí)行容器級數據重分布前后數據庫事務的性能對比結果。圖3的橫坐標為測試的數據倉庫個數,，每個數據倉庫中有10個測試終端（Terminal）,；縱坐標為tpmC（數據庫每分鐘處理事務數），tpmC的值越高,，則數據庫的OLTP性能越好,。從圖3中可以看出，節(jié)點中僅運行一個OLTP型數據庫容器時,，它的事務性最好,，因為節(jié)點中沒有其他容器與其競爭CPU等資源，本實驗用其作為性能參考標準,。數據重分布后容器中數據庫的事務性能排在其后,，因為數據重分布前節(jié)點中還有3個OLAP型數據庫容器在執(zhí)行復雜的表連接和聚集操作，占用整個節(jié)點的大量CPU時間片,，導致CPU處理I/O操作的等待時間增加,，所以執(zhí)行復雜分析操作的數據庫容器會影響OLTP型數據庫容器的更新操作性能，導致事務性能下降,。因此,，執(zhí)行容器級數據重分布有利于提升事務型數據庫容器的性能。

　　圖4中顯示了容器級數據重分布前后數據庫分析性能對比結果,。圖4中橫坐標為執(zhí)行TPCH測試的22條SQL語句,，其中Q17和Q20包含了復雜的嵌套查詢以及聚集操作，且由于postgresql的shared_buffers大小設置為128 MB,，導致這兩條語句的執(zhí)行時間是其他語句執(zhí)行時間的幾千倍,，因此不作為本實驗的參考。

　　從圖4中可以看到,，數據重分布后數據庫的分析性能下降很明顯,，查詢語句響應時間比數據重分布前的響應時間長很多。通過監(jiān)控節(jié)點的CPU和內存發(fā)現,，由于本實圖4實驗一（b）數據重分布前后TPCH測試結果

　　圖5實驗二（a）數據重分布前后數據庫分析性能對比結果驗使用的CPU為4核,，內存8 GB，數據重分布前節(jié)點共執(zhí)行3個OLTP型數據庫容器和3個OLAP型容器,，CPU使用率達到70%~90%,，內存使用7.27 GB，而數據重分布后執(zhí)行6個OLAP任務,，該節(jié)點上的CPU使用率達到100%,，內存使用7.48 GB，這說明執(zhí)行OLAP型任務的數據庫容器會消耗大量 CPU時間片，而此時CPU使用率已經達到飽和,，因此數據庫的OLAP性能急劇下降,。實驗證明，當宿主機系統(tǒng)資源不足時會嚴重影響宿主機中容器的執(zhí)行效率,，因此在宿主機資源不足時,，應該執(zhí)行容器數據遷移，但如果待遷移目標主機的資源不足,，則待遷移的容器應該等待,，以免由于資源競爭引起容器性能降低。

　　實驗二在實驗一基礎上將CPU增加到8核,，來測試容器中數據庫的OLTP和OLAP性能,。實驗結果如圖5和圖6所示。圖5表明,，節(jié)點中CPU和內存充足時,，數據重分布后的數據庫的OLAP性能普遍比數據重分布前性能好，其原因如下：圖6實驗二（b）數據重分布前后數據庫事務性能對比結果

　　數據重分布前,，執(zhí)行OLTP任務的容器頻繁占用宿主機的CPU時間片來處理I/O請求,，導致執(zhí)行OLAP型數據庫容器的CPU等待時間增加,。因此,，數據重分布后的數據庫的分析性能比數據重分布前要好。圖6為數據重分布前后數據庫事務性能對比,。實驗結果表明執(zhí)行容器級數據重分布后數據庫事務性能好,，具體原因圖3中同實驗一（a）。

4結論

　　Docker技術的出現給Linux容器技術帶來巨大的發(fā)展前景,，同時也促進了云服務技術的發(fā)展與應用,。本文針對如何提升運行在云計算平臺容器中的執(zhí)行事務型任務和分析型任務的數據庫服務的性能提出了容器級數據重分布策略LXCDDS。實驗結果表明,，該數據重分布策略能夠有效提升云平臺上容器中數據庫服務的性能,。

參考文獻

　　［1］ Wei Hao, YEN I L,THURAISINGHA M B. Dynamic service and data migration in the clouds［C］. IEEE COMPSAC, 2009:134136.

　?。?］ 石杰.云計算環(huán)境下的數據挖掘應用［J］.微型機與應用,2015,34(5):1315.

　?。?］ 吳軍， 張軼君,， 白光偉.Xen下虛擬機動態(tài)遷移優(yōu)化策略的研究［J］.電子技術應用,2015,41（11）：128131.

　?。?］ 楊保華， 戴王劍,， 曹亞倫. Docker技術入門與實踐［M］. 北京：機械工業(yè)出版社, 2015.

　?。?］ QUAMAR A, ASHWIN KUMAR K, DESHPANDE A. SWORD: scalable workloadaware data placement for transactional workloads［M］. EDBT, 2013.

　　［6］ Li Yinan, PATEL J M. WideTable: an accelerator for analytical data processing［C］. Proceedings of the VLDB Endowment, 2014:907909.