多租户saas应用中的mysql集群性能分析

《多租户saas应用中的mysql集群性能分析》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

万方数据山东大学硕士学位论文同时充当应用服务器)、SQL节点和数据节点的CPU、内存利用率进行分析以及几种典型交互的响应时间的分析。本文的创新点主要体现在：1．通过实验分析了keepalived与mysql—proxy连接方式下，MySQL集群的性能。到目前为止，很少有人研究这个问题，有的是专门针对其中的一个进行研究，而缺乏比较分析。2．研究SQL节点与数据节点的不同数目节点配置对MySQL集群性能的影响。通过实验可以清楚地看到在访问数据库集群时，不同角色节点所承担压力的大小，可以对数据库集群有一个更加深入的了解。3．通过研究多租户条件下，不同规模业务组合对数据库集群性能的影响，能够对多租户应用的数据库整体优化部署提出分析建议，在保证用户良好的数据库访问性能的同时，又保持应用设备较高的利用率，有着较高的使用价值。关键词：MySQL集群，keepalived，mysql-proxy，多租户，性能分析Il 万方数据山东大学硕士学位论文ABSTRACTWiththedevelopmentofIntemettechnologyandthematurityofapplicationSoftware，thedemandforprovidingtheSoftwareforthecustomersasaformofservicesisgrowinggradually,thestudyofnewSoftwaredeliverytechnologyhasbecomethecurrenttrend，whilethisnewpattern，SaaS(SoftwareasaService)iscompliedwiththerequirementsofthecurrentSoftwaremarket，itCanhelpSoftwaredeveloperstowincustomersintheformofprovidingservices．AsthecoretechnologyofSaaSapplications，multi—tenantisgainingmoreandmoreattention，theideaofthemulti—tenantSaaSismanagingandstoringdataandbusinessprocessofmultipletenantsonthesanleservergroupofSaaSprovider,itspurposeistoallowmultipletenantstosharesoftwareandhardwareresources，improvetheutilizationrateofresources，reducetheaverageallocationonsingletenant’Sinfrastructureandmanagementcosts．However，whenthenumberofusersthatcallaccessconcurrentlyreachacertainone，aseriesofproblemswillbecaused，thedataserverresources(CPU，memory,etc．)aretight，theabilityofprocessingdatacan’tkeeppace，andSOon，andtheuserwaitingtimeincreases，theproblemsuchasaccesserrorwillOCCur,therefore，inordertOachieveservicelevelagreements(SLAs)andmaintainthehighperformanceandutilizationoftheapplicationsequipment(applicationserveranddatabaseserver)，solvingtheaboveproblemisallimportantchallengeforSaaSapplicationsDatabaseclusterisaneffectivemechanismcarlimprovethethroughputandreducethedatabaserequestresponsetimeofthedatabase，isoftenusedtosolvethenetworkserviceofhighdataaccesssinglepointboaleneckproblem．Butbecauseoftheblockadeofforeigncompaniesintechnology,thepurchaseandmaintenancecosts&rerelativelyhigh，MySQLdatabaseiswelcomedbyenterprisesbyitsfleeandopensource，useMySQLtobuildadatabaseclustersystemwithhighavailabilityand，CaneffectivelycontrolthecostofITenterprise．Basedonsuccessfullysettingupahi曲availabilityMySQLcluster,thispaperIll 万方数据山东大学硕士学位论文hopethatthroughallin·depthstudyontheMySQLcluster,Comparisontheperformanceofdatabaseclusterunderdifferentconnectiontypes；Studytheeffectsonthedatabaseclusterperformancewi廿1differentnumberofdatanodesandsqlnodescombination．Infoundabetcerwayofconnectingtothedatabaseandthenumberofnodesinoptimalconfiguration，analysistheimpactofthemulti—tenantcombinationofdifferentbusinessscaletotheMySQLClusterperformance．Thispaperusesthemethodoftestdrive，afteralotofexperiments，analysistheperformanceofdatabaseclusterunderdifferentconnectiontypesanddifferentnumberofdatanodesandsqlnodescombination，anddifferentscalebusinesscombinations．AnalysisontheperformanceofMySQLclustermainlyintheCPU’Sutilizationrateandmemeory’Sutilizationrateofmanagementnode(themanagementnodealsoactastheapplicationserver)，SQLnodesanddatanodes，atthesametime，analysistheresponsetimeofseveraltypicalinteractions．Theinnovationpointsofthispaperismainlyreflectedinthe：1．AnalysistheperformanceofMySQLclusterofthekeepalivedandmysql·proxyconnectionmode，．Sofar,fewpeoplestudytheproblem，somearespecificallyforoneofthem，andlackofcomparativeanalysis．2．StudytheeffectsontheMySQLClusterperformancewithdifferentnumberofdatanodesandsqlnodescombination．ThroughtheexperimentscallbeclearlyseenthepressuredistributedtodifferentrolesofnodesinMySQLCluster,Canhaveamorein—depthunderstandingofdatabasecluster．3．ThroughthestudyoftheeffectsontheMySQLClusterperformanceofmulti-tenantsapplicationswitlldifferentbusinessscales．canproposesuggestionsaimedatoveralloptimizationdeploymentofmultitenantapplicationdata．base，whileinensuringthegoodperformanceofdataaccess，keepthehighutilizationrateofresources，whichhasahighpracticalvalue．Keywords：MySQLCluster,keepalived，mysql—proxy,Multi-tenant，performanceevaluationIV 万方数据山东大学硕士学位论文1．1课题背景和研究意义第1章绪论软件即服务(SaaS)是一种新型的软件应用模式，也是当前很多研究的热点问题。在该模式下，服务提供商负责提供必要的硬件基础设施和软件运行服务平台，租户使用简单的定制功能在服务平台上构建专属于自己的个性化业务系统，并通过在线租赁的形式使用。SaaS模式引入了多租户环境特征，要求不同租户问共用数据库、操作系统以及硬件等资源和基础设施。如何保证新的环境下，数据存储结构既能满足不同租户特定的存储需要，又能保持较高的资源利用率，提供良好的总体数据访问性能，成为SaaS数据存储的重要设计目标。尤其是当租户数目大量增加时，通过添加硬件资源或者部署到集群即可满足使用要求，而不用改变数据的存储结构，满足系统可伸缩性。本文通过对MySQL集群进行了深入的研究，比较了不同连接方式(mysql—proxy、keepalived)下，MySQL集群的性能以及研究不同数目节点(SQL节点与数据节点)的配置对MySQL集群性能的影响。在找到了较优的数据库连接方式以及较优的节点数目配置之后，分析不同业务规模的租户组合对数据库性能的影响。通过本文的研究，当不同业务规模的租户组合访问MySQL集群时，可以对应用服务器、SQL节点、数据节点的资源利用率以及请求的响应时间有一个前瞻性的预测，在保证用户良好的数据访问性能的同时，可以灵活的配置服务器资源，保证资源较高的利用率，有着较高的使用价值。1．2国内外研究现状从SaaS服务提供商的角度，如何在维持设备较高资源利用率的同时，为每个租户提供一定的性能指标保障一直是多租户SaaS应用的一个热点问题。文献[4]提出了一种数据存储模型，通过对现有的通用表、透视表等模式进行研究比较，分析其定制能力及导致性能下降的关键因素，对透视表存储模型进行改进， 万方数据山东大学硕士学位论文提高定制能力，从而形成新的多租户共享数据存储模型。基于新的数据存储模型，实现租户逻辑数据与物理存储模式之间的模式映射和查询转换机制，达到定制能力与系统性能平衡的目的。通过实验，测试数据库中表的数量对数据库吞吐率及缓冲池命中率的影响，并对提出的数据存储模型与透视表模型的查询转换性能进行对比测试，验证了数据存储模型的有效性。文献[13]通过实现对WebN务器集群的准入控制，提出了一种基于负载均衡的算法。由于很难准确地通过分布式Webn艮务器代理的反馈确定web服务器的负载，文章提出了一个分析模型来估计web服务器的负载。为了实现这一目标，该算法根据请求的服务时间和请求的资源需求将请求分类，并跟踪每一类请求中的典型请求，来动态的确定每一个Web节点的负载。文章使用控制理论中的比例积分(PI)来处理该模型的误差，然后每个web服务器的估计可用容量用于负载均衡和准入控制决策。通过标准的基准测试证实了该方案的有效性，从而提高了平均响应时间和吞吐量。文献[18]文中定义了一个特定的多租户架构一MDSA，并从业务逻辑层和数据处理层两方面探索多租户应用的性能管理问题，提出了基于延迟的应用级请求调度算法ADRS以及惰性副本管理算法LRM．在业务逻辑层，ADRS通过逐步降低服务需求较大的请求的优先级来避免其对整体性能造成影响．在数据处理层，LRM通过动态调整负载在各个副本之间的分配以及副本在节点间的放置来适应负载的动态变化。文中将典型的Web应用TPC—w转换成多租户应用，并以此为基础进行了实验分析，结果表明了上述算法的可行性和有效性。以上简要列举了一些解决多租户SaaS应用关键问题的一些方法，本文从数据库的角度出发，在维持设备较高资源利用率，为每个租户提供一定的性能指标保障的同时，研究不同业务规模的租户组合对数据库性能的影响是本文的主要研究内容。对于应用与数据库的连接方式，也有人做了大量的相关工作。文献[10]分析了设备高可用性的需求，介绍了VRRP协议以及工作原理、keepalived开源软件对VRRP协议的实现，研究了keepalived的安装配置以及keepalived在网桥模式中的应用，添加了keepa]jved功能配置项，达到了双机切换的预期效果。文献[11]对MySQLProxy进行简要的分析与研究，文献[12]对MySQLProxy2 万方数据山东大学硕士学位论文进行深入研究后，发现MySQLProxy在读写分离和负载均衡两个功能上存在一定缺陷。为了对这些缺陷进行修正，主要做了以下几个方面的工作：(1)利用MySQLProxy和MySOLReplJcation构建集群系统，用触发器法来解决主从不一致导致的读写分离缺陷。(2)提出了基于概率分布和剩余负载率的负载均衡算法。该算法综合考虑各个服务器节点的真实负载和服务器自身的处理性能，很好的反映出每个节点的实时处理能力，均衡了服务器负载，发挥每个节点的最大处理性能。从而提高系统的处理性能，降低整个系统的平均响应时间。(3)在深入分析研究动态反馈模型和当前流行的集群系统之后，设计出MySQLProxy扩展系统框架，并实现整个系统。该系统首先收集节点信息，然后根据收集的信息通过改进的负载均衡算法生成可用节点概率分布，根据概率分布来转发请求。(4)最后搭建整个系统的测试环境，利用当前常用的性能测试工具JMeter对整个数据库集群系统进行测试，并与搭配最小连接数均衡算法的MySQLProxy进行比较。然后得出扩展前后的实验数据，进行分析得出扩展后的结论。通过实验证明，经过扩展后的平台，能够明显缩短用户的请求响应时问，并提高系统吞吐量，提高集群的稳定性。文献[6]对特定的数据库服务器做了性能测试，并对测试得到的数据进行了数据处理和结果分析。利用PC-Farm集群环境对特定的数据库服务器做了性能测试，着重测试了查询速度、插入速度与连接线程数的关系，以及数据量大小对查询速度和插入速度的影响。测试方法和结果为CSNS(中国散裂中子源)谱仪靶站数据库服务器的选型和数据库系统的设计提供了重要的参考。1．3数据库集群发展现状目前数据库集群系统应用得比较成功、应用范围比较广泛的是：Oracle公司的OracleRAC与IBM公司DB2ICE。Orac]eRAC采用Shared—storage的技术，DB2ICE选择了Shared—nothing的技术，二者各有长短。3 万方数据山东大学硕士学位论文图2．1OracleRAC采用的Shared—storage技术与DB2ICE采用的Shared—nothing技术最新的数据库集群系统的理论基础是分布式计算，将数据分布到每个节点，所有的计算节点并行处理数据，将结果汇总。这样的方式无疑是最完美的。但是目前仍然不能实现全部的功能。1．3．1OracleRAC简介RAC，全称realapplicationclusters，译为“实时应用集群”，是Oracle新版数据库中采用的一项新技术，为Oracle数据库提供了较高的可用性、可伸缩性。如果集群内的一个节点发生故障，Oracle数据库可以在其余的节点上继续运行，并且当应用规模需要扩充时，用户可以按需扩展系统，以保证系统的性能。OracleRAC采用了Shared—storage的实现模式，如图2．1所示，通过CPU共享和存储设备共享来实现多节点之间的无缝集群，用户提交的每一项任务被自动分配给集群中的多台机器执行，实现多节点的负载均衡，用户不必通过冗余的硬件来满足可靠性需求：另一方面，RAC可以实现CPU的共享，以普通服务器组成的集群实现过去只有大型主机才能提供的高性能。OracleRAC的优势在于：(1)多节点负载均衡；(2)提供高可用：故障容错和无缝切换功能，将硬件和软件错误造成的影响最小化；(3)通过并行执行技术提高事务响应时间～一通常用于数据分析系统；(4)通过横向扩展提高每秒交易数和连接数一一通常对于联机事务系统；(5)节约硬件成本，可以用多个廉价PC服务器代替昂贵的小型机或大型机，同时节约相应维护成本；(6)可扩展性好，可以方便添加删除节点，扩展硬件资源。4 万方数据山东大学硕士学位论文OracleRAC在有着较多优势的同时，也有着不可回避的缺陷，主要表现在：(1)相对单机，管理更复杂，要求更高；(2)在系统规划设计较差时性能甚至不如单节点；(3)可能会增加软件成本(如果使用高配置的pc服务器，Oracle一般按照CPU个数收费)。1．3．2DB2ICE简介DB2ICE(IntegratedClusterEnvoronment)是一种预打包的Linux数据库集群解决方案，可以帮助任何规模的公司实现一个基于IBM通用数据库Linux版和IBMeServer平台的低成本、高性能的数据库平台。专为实现快速投资回报和降低总计算成本而设计的DB2ICE为公司创建高度可用和动态可扩展的Linux数据库集群(拥有1到1000个节点)提供了基本的组建模块。DB2ICE采用了Shared—nothing技术，如图2．1所示，其中有专用的存储节点、服务节点以及任务调度节点组成的子集群，创造了ITBTPC—H基准测试的新纪录，拥有目前最高的事务处理性能。很明显，DB2ICE需要有专门的硬件设备才能有效的发挥它的性能。DB2ICE的优势主要在于无限能力(1)为各种事务处理工作负载提供了几乎无限的产能。系统扩展非常简单，只需要与一个新节点连接，并发出两个简单的命令即可，有效利用系统资源，降低了成本；(2)应用程序透明，无需改变应用程序代码，就可以有效地运行在多个节点上，能够按需扩展自己的应用程序，以满足变化的业务需求。DB2为常用的语法规则和PL／SQL语言提供了全面的支持，使从Oracle数据库迁移到DB2变得比以往更轻松了；(3)持续的可用性，通过在IBMPowerSystems上和冗余架构中使用高可靠的IBMPowerHApureScale技术，提供了持续的可用性，此系统能够瞬间从节点故障中恢复，立即将工作负载重新分配给其他可用的节点。IBM的DB2ICE设计的初衷是让企业在不牺牲性能的前提下扩展他们的DB2集群，需要有专门的硬件设备支持。除了以上介绍的两种商业产品，其余的商业产品还包括MocrosoftMSCS(MocrosoftClusterService)、SybaseASE、PCTIICE—UDX、EmiCm／cluster以及后来的Continuentuni／cluster。当前数据库集群产品是如此之多、而且5 万方数据山东大学硕士学位论文由于此类软件本身的复杂性，本文不可能对所有的数据库集群软件的性能进行研究，考虑到本组工作的需要，本文主要对MySQL集群的性能进行研究。1．4本文的主要研究内容本文的主要研究内容如下：(1)比较了不同连接方式(mysql—proxy、keepalived)下，MySQL集群的性能，实验用到了三台物理服务器(serverl、server2和server3)，serverl充当应用服务器和集群管理节点，server2充当sql节点和数据节点，server3充当管理节点和数据节点，通过分析serverl，server2和server3的CPU、内存利用率，比较不同连接方式下MySQL集群的性能。(2)研究不同数目节点(SOL节点与数据节点)的配置对MySQL集群性能的影响，主要做了三组实验，包括(两个SQL节点和两个数据节点)、(一个SOL节点和三个数据节点)和(三个SQL节点和一个数据节点)，通过分析应用服务器(同时充当管理节点)、SQL节点和数据节点的CPU、内存利用率，可以发现不同数目节点的配置对MySQL集群性能的影响，以及不同的集群节点所承担的负载压力大小。(3)在找到了较优的数据库连接方式以及较优的节点数目配置之后，分析不同业务规模的租户组合对数据库性能的影响。实验采用了keepalived的连接方式以及一个SQL节点和三个数据节点的节点配置，假设在多租户服务系统的客户端只有两个租户，我们在多租户组合分别是(1，6)和(3，4)和(1，3)三种情况下分别做了一组实验，通过分析应用服务器(同时充当管理节点)、SQL节点和数据节点的CPU、内存利用率以及几种典型交互的响应时间，可以看到不同业务规模的租户组合对数据库性能的影响。本文第l章为绪论，首先介绍了课题背景和研究意义，然后概述了国内外研究现状和数据库集群发展现状，最后总结了本文的主要研究内容和组织结构。第2章是本文的简介部分，主要介绍了MySQL集群、keepalived、mysqlproxy和基准测试工具S-BM。6 万方数据山东大学硕士学位论文第3章首先比较了不同连接方式(mysql—proxy、keepalived)下，MySQL集群的性能，然后研究不同数目节点(SOL节点与数据节点)的配置对MySQL集群性能的影响，针对不同数目节点的配置主要做了三组实验，分别是(两个数据节点和两个SQL节点)、(三个数据节点和一个SOL节点)、(一个数据节点和三个SOL节点)。对MySQL集群性能的分析主要包括对管理节点(同时充当应用服务器)、SOL节点、数据节点的CPU和内存利用率的分析。第4章分析了不同业务规模的租户组合对MySQL集群性能的影响。在第3章工作的基础上，我们使用keepalived连接应用与MySQL集群，并配置了三个数据节点和一个SQL节点，实验分析了几种不同业务规模的租户组合条件下，管理节点(同时充当应用服务器)、SOL节点、数据节点的CPU和内存利用率，以及几种典型交互的响应时间。第5章对现有工作进行了总结，对多租户应用的数据库整体优化部署提出了分析建议，并针对尚未解决的问题，给出了进一步的工作展望。7 万方数据山东大学硕士学位论文2．1MySQL集群第2章预备知识目前数据库应用状况大致分为两类，第一类是数据量在IOOG以下，数据库访问频繁，请求密集。主要是WebAPP类型的应用，例如：网站，论坛等。这些WebAPP类型的应用访问数据库的特点是：访问频繁，数据库每秒钟要接受几千次以上的查询，需要经常追加数据，同时对数据的响应速度要求比较高。另一类是用于科学计算、存储历史数据的应用，数据量往往达到几百G。这些应用访问数据库的特点是：多为查询操作，数据都是分批、定时、集中倒入数据库，数据库的记录非常多，积累了大量的数据，对数据库的响应速度没有太高要求。对于第一类应用，由于访问比较频繁，每秒钟的请求不断增加，会使得服务器负载增加，响应单个请求的速度越来越慢，如果库文件比较大，出现写操作的时候还会出现锁表时间过长等影响访问效率的事情。首先应当从硬件、软件、程序、索引、SQL语句这几个方面进行优化，如果仍然不能解决问题，我们就要考虑数据库系统的集群(并行处理)了。MySOL集群是一种技术，该技术允许在无共享的系统中部署“内存中”数据库。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。MySQL集群由一组计算机构成，包括管理服务器、SQL节点和数据节点，其中管理服务器(ManagementServer—ndb—mgmd)的作用是管理MySQLCluster内的其他节点(包括SQL节点与数据节点)，如提供配置数据、启动并停止节点、运行备份等，它获取各个节点的状态和错误信息，并反映给整个集群中所有节点，管理节点是用命令“ndb_mgmd”启动的；数据节点(Datanode—ndbd)存储层的NDB节点，即Cluster环境下的存储引擎，用于保存C】uster的数据，将数据存放在内存中，数据节点的数目与副本的数目相关，是片段的倍数。例如，对于两个副本，每个副本有两个片段，那么就有4个数据节点。不过没有必要设置多个副本。数据节点是用命令“ndbd”启动；SOL节点(SQLnode～mysqld)负责存储层之外的事情，例如连接管理、query处理和优化、cache管理等，即 万方数据山东大学硕士学位论文剥离了存储层的MySQL服务器，用来访问Cluster数据，通常，SQL节点是使用命令“mysqld—ndbcluster”启动的，或将“ndbcluster”添加到“my．cnf”后使用“mysqld”启动。MySQL集群结构图1．1所示：Clients／APls图1．1MySQL集群结构所有的这些节点构成一个完成的MySQL集群体系。数据保存在“NDB存储服务器”的存储引擎中，表(结构)则保存在“MySQL服务器”中。应用程序通过“MySQL服务器”访问这些数据表，集群管理服务器通过管理工具(ndb_mgmd)来管理“NDB存储服务器”。MySQLCluster是MySQL适合于分布式计算环境的高实用、高冗余版本。它采用了NDBCluster(NetworkDatabaseCluster)存储引擎，允许在1个Cluster中运行多个MySQL服务器。在MyQL5．0及以上的二进制版本中、以及与最新的Linux版本兼容的RPM中提供了该存储引擎。。在MySQL集群中，只有当table引擎为NDBCLUSTER(NetworkDatabaseCluster)时才做集群，其他非NDBCLUSTER表和一般MySQL数据库表一样，不会共享数据。NDBCLUSTER表数据存储在数据节点(Datanode)内存中，数据节点(DataNode)可以为1台或多台服务器，它们之间存放共享数据，因此MySQL对内存需求量巨大。另外，由于NDB(NetworkDatabase)的每项操作都与网络相关，因此连接MySQL集群各节点之间的网络环境对于MySQL集群的性能有着重要影响。0 山东大学硕士学位论文目前能够运行MySQLCluster的操作系统有Linux、MacOSX和Solaris(一些用户通报成功地在FreeBSD上运行了MySQLC1uster，但MySQLAB公司尚未正式支持该特性)，最新版本MySQLCluste7．1．10支持更多操作系统，包括Windows。MySQL集群的优点主要表现在：(1)99．999％的高可用性；(2)快速的自动失效切换：(3)灵活的分布式体系结构，没有单点故障：(4)高吞吐量和低延迟；(5)可扩展性强，支持在线扩容。MySQL集群的缺点主要表现在：(1)存在很多限制，比如：不支持外键；(2)部署、管理、配置很复杂：(3)占用磁盘空间大，内存大；(4)备份和恢复不方便；(5)重启的时候，数据节点将数据load到内存需要很长时间。通过将MySQLCluster引入开放源码世界，MySQL为所有需要它的人员提供了具有高可用性、高性能和可缩放性的Cluster数据管理。本文中，我们使用Keepalived或者MySQL—Proxy用于应用与MySQL集群的连接，研究不同的连接方式下单租户访问数据库的性能是我们的主要目的之一。zkq201509242．2KeepalivedVRRP(VirtualRouterRedundancyProtocol，虚拟路由冗余议)是一种容错协议。通常，一个网络内的所有主机都设置一条缺省路由，这样，主机发出的目的地址不在本网段的报文将被通过缺省路由发往路由器RouterA，从而实现了主机与外部网络的通信。当路由器RouterA坏掉时，本网段内所有以RouterA为缺省路由下一跳的主机将断掉与外部的通信产生单点故障。VRRP就是为解决上述问题而提出的，它为具有多播、组播或广播能力的局域网(如：以太网)设计。VRRP通过竞选协议实现虚拟路由功能，协议报文通过IP多播(多播地址224．0．0．18)形式发送。在虚拟路由器中，只有MASTER(主机)对外广播协议报文，即VRRP广告包。BACKUP(备机)不会抢占MASTER(主机)，除非BACKUP(备机)的优先级高，且配置抢占模式。当MASTER(主机)出现故障，自动降低优先级进入FAULT状态。此时处于VRRP虚拟路由器的其它BACKUP(备机)因收不到MASTER(主机)发送的广告包而竞争MASTER(主机)，优先级最高的BACKUP(备机)成为blASTER(主机)，接手业务工作，以保证服务的连续性。若原来出10万方数据 山东大学硕士学位论文现故障的MASTER(主机)修复之后，会根据配置信息决定是否重新成为MASTER(主机)。MASTER拥有虚拟路由器的IP地址，负责转发数据包和相应的ARP请求。出于安全考虑，广告包可以以认证模式或者加密模式发送。Keepalived是一个开源软件，实现了VRRP协议，它的作用是检测服务器的状态，如果有一台服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从集群中剔除，当服务器恢复正常后Keepa]ived自动将服务器加入到数据库集群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。2．3MySQLProxyLua是一个小巧的脚本语言，其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。Lua由标准C编写而成，可以很容易的被C／C++代码调用，也可以反过来调用C／C++的函数，几乎在所有操作系统和平台zkq20150924上都可以编译、运行；Lua不仅仅作为扩展脚本，也可以作为普通的配置文件，代替XML、ini等文件格式，并且更容易理解和维护；一个完整的Lua解释器不过200k，在目前所有脚本引擎中，Lua的速度是最快的，这一切都决定了Lua是作为嵌入式脚本的最佳选择。Lua并没有提供强大的库，这是由它的定位决定的，所以Lua不适合作为开发独立应用程序的语言。MySQLProxy是一个中间层代理，处于client端和MySQLserver端之间的简单程序，简单的说，MySQLProxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用]ua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQLProxy是完全透明的，应用则只需要连接到MySQLProxy的监听端口即可。MySQLProxy很强大的一项功能是实现“读写分离”，基本原理是让主数据库处理事务性查询(insert、update、delete)，让从库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从库。MySQLProxy为mysql开源项目，虽然是mysql官方产品，但是mysql官方并不建议将MySQLProxy用到生产环境。万方数据 山东大学硕士学位论文2．4基准测试工具S．BMSBM-供应商管理系统，提供了装配工厂与供应商交互的功能，以方便两者之间的业务处理；SBM支持订单查询、采购计划查询、库存管理、账单管理等服务：而s—BM是以SBM应用为基础构建，通过模拟对SBM的业务请求来评估服务器的性能以及应用本身的表现力。下图为S—BM的结构：zkq20150924图1．2S-BM结构·C1lent端是工作负载的产生源，负责模仿用户向测试系统发起HTTP访问。·C1lent端安装在用户机上，用户机创建并控制模拟浏览器(EmulateBrowser)EB，通过一个浏览器来模拟一个真实用户。·通过设置不同的参数，我们可以控制web业务的工作量，并可以评估指定服务器的性能。●当一个EB被创建，它会启动一个用户会话，这个会话包含了一些在EB和前端服务器之间的web业务，而一个web业务又包含了一系列的行为。·根据不同的工作负载组合，一个页面有不同的导航选项。当EB选择了下一个导航选项时，它在下一个web业务里面加入了IP地址，同时，仿真器生成思考时间t。在t这个时间段内进行睡眠动作以模仿用户浏览网页并进行思考之后，就会接着进行下一个web业务。当用户会话结束之后，EB会结束所有之前打开的网络连接，并会立即准备启动下一个会话。再检查完会话之后，口向前端服务器发送新的请求。万方数据 山东大学硕士学位论文在本文中，我们主要分析不同EB数访问应用时，应用服务器和数据库集群(管理节点、SQL节点以及数据节点)的CPU、内存利用率以及响应时间，来研究MySQL集群的性能。2．5本章小结本章首先介绍了MySOL集群，包括MySQL集群的组成、每种节点功能的介绍、MySQL集群的优缺点等，然后介绍了应用与数据库集群的两种连接方式：Keepa]ived和mysql-proxy，包括他们的功能、基本原理，最后介绍了实验所用到的基准测试工具S—BM。zkq2015092413万方数据 山东大学硕士学位论文第3章不同的连接方式及节点数目配置对MySQL集群性能的影响3．1比较不同连接方式下(keepalived、MySQL-Proxy)，数据库集群的性能我们的这组实验用到了三台物理服务器，每台服务器的角色以及配置如表3．1所示：角色CPU内存硬盘serverl管理节点、应用服务器1．2GHz(6cores)8G550Gserver2SQL节点、数据节点2．1GHz(8cores)62G2Tserver3SQL节点、数据节点2．1GHz(8cores)62G2T网络lOOMb／s操作系统rhel6．3Tomcat版本Tomcat6．0zkq20150924，表3．I服务器角色及配置由于MySQL集群对管理节点要求较低，并且无需安装MySQL，因此我们将管理节点同时充当应用服务器。使用keepalived实验环境如下图所示：一一一一。一。^“．．：：图3．2使用keepalived的实验环境应用服务器(serverl)通过keepalived配置的虚拟IP(VIP)连接到数据14万方数据 山东大学硕士学位论文库服务器(server2或者server3)，任意时刻只能同一台数据库服务器相连，这是因为每台数据库服务器(server2和server3)上的keepalived的配置里面只有本机的IP+VIP，而不是两台MySQL的IP+VIP，因此不用担心两个MySQL会同时提供数据更新操作。使用MySQL—Proxy的实验环境如下图所示：、L^、?一一一一一’{．一。图3．3使用MySQL—Proxy的实验环境zkq20150924MySQL—Proxy只安装在管理节点(同时充当应用服务器)上，应用与代理IP(即管理节点IP)相连接，通过MySQL—Proxy自带的lua脚本进行sql判断，把读操作定向到server2或者server3，把写操作定向到server3(在本实验中，应用与数据库的交互都是读操作，没有考虑写操作)。两种不同连接方式下，应用服务器(管理节点)的CPU、内存利用率如图3．4所示。CPU，memoryutilizationrateofapplicationserver(mana9emenlnode)70—。一CPUutilizationrateusingkeepalived‘～CPUutilizationrateusingmysqt-proxy6Dutilizationratememoryusingkeepalived享n)50memoryutilizationrateusingmysql-proxy石‘c40．殳器30三了2000盖三===垒]=二=兰：==二!二[：=二生工二二二=工二==!口二二．兰二二二二兰】k4006∞8001∞01200140016001咖2000EBs图3．4应用服务器、管理节点的CPU、内存利用率万方数据 万方数据山东大学硕士学位论文从图3．4看出，使用mysql—proxy连接数据库，应用服务器(管理节点)的CPU、内存利用率明显比使用keepalived连接数据库要高，这是因为mysq]一proxy是安装在serverl上的，而keepa]ived是安装在server2和server3上的，因此当使用keepalived连接数据库时，访问的是server2数据库或者server3数据库，而不经过serverl；当使用mysq卜proxy连接数据库时，要先经过mysql—proxy代理，进行读写分离的判断，再访问server2数据库或者server3数据库，因此消耗了serverl的一部分CPU和内存资源。server2和server3的CPU、内存利用率如图3．5、3．6所示。80CPU，memoryutilizationrateofserver27。’i60}iso：巴c40．殳器30三320OCPUutilizationrateusingkeepalivedCPUutilizationrateusingmysql·proxymemoryutilizationrateusingkeepalivedmemoryutilizationrateusingmysql-proxy_。——一——90200400600800100012001400160018002000EBs图3．5server2的CPU、内存利用率CPU，memoryutilizationrateofserver380=320—CPUutilizationrateusingkeepalived—————CPUutilizationrateusingmysql-proxymemoryutilizationrateusingkeepalived’memoryutilizationrateusingmysql-proxy———=I—I。I-200I∞啪80010001200140016001800200CEBs图3．6server3服务器CPU、内存利用率。i一。ale≥。!l警!l 万方数据山东大学硕士学位论文从图3．5、图3．6中可以发现，1)使用keepalived连接数据库，server2服务器和server3服务器的内存利用率明显要比使用mysql—proxy连接数据库时内存利用率低；2)两种连接方式下，server2服务器和server3服务器CPU利用率差别并不明显，几乎重合在一起；3)server2服务器和server3服务器的CPU、内存利用率有着较高的一致性。Keepalived与MySQLProxy的性能比较如表3．7所示：keepalivedMySQLProxyCPU利用率低鬲serverl—一内存利用率低局CPU利用率重合server2—．一内存利用率低向CPU利用率重合server3内存利用率低同表3．7Keepalived与MySQLProxy的性能比较从实验3．1可以看出，在不涉及数据库写操作的前提下情况下keepa]ived的性能要优于MySQLProxy。3．2研究不同数目节点的配置对于数据库集群性能的影响．本节我们使用VMware—Workstation—Full一9．0．4—1945795．x86—64．bundle在server2服务器(服务器配置如表3．1所示)安装了VMwareWorkstation，并成功生成了多个虚机。本节我们主要做了三组实验：3．2．1两个数据节点，两个SQL节点(2D2S)虚机配置如表3．8所示：17 万方数据山东大学硕士学位论文VCPU(S)内存硬盘管理节点，应用服务器2processors5G30GSql节点12processors5G30GSq]节点22processors5G30G数据节点12processors5G30G数据节点22processors5630G操作系统rhel6．3Tomcat版本Tomcat6．0实验环境如图3．9所示表3．82D2S虚机配置图3．92D2S实验环境管理节点、应用服务器(两者在一台虚机上)的CPU、内存利用率如图3．10所示：CPU，memoryutilizationrateofapplicationserver(managementnode)memoryutilizationrate000图3．10管理节点，应用服务器的CPU、内存利用率卜叶卜扣一孚一。le．Ico11∞N三ln 万方数据山东大学硕士学位论文从图3．10可以看出，应用服务器(管理节点)的CPU、内存利用率并不高，在12％以下。SQL节点1、SQL节点2的CPU、内存利用率如图3．11所示。CPU．memoryutilizationrateofSQLnodel．SQLnode250一一CPUutilizationrateofSQLnode2—、一memoryutilizationrateofSQLnode2§一一memoryutilizalJonrateofSQLnodel竺一CPUutilizationrateofSQLnodel2004006008∞10口0EBs图3．1lSQL节点l、2的CPC、内存利用率从图3．11可以看出，SQL节点2的CPU利用率要比SQL节点1的CPU利用率高的多，这是因为Keepalived配置的VIP映射的是SQL节点2的IP，而不是SQL节点1的IP，因此对数据库的查询都要先经过SQL节点2，再访问数据节点，因此SQL节点2的CPU利用率要比SQL节点1的CPU利用率高。与此同时，SQL节点1的内存利用率与SQL节点2的内存利用率差别并不明显。数据节点1、数据节点2的CPU、内存利用率如图3．12所示CPU，memoryutilizationrateofdatanodel，datanode2CPUutilz越ionrateofdatanode2CPUutihzationrateofdatanodelmemoryulillza'oonrateofdatanode,7．二竺!竺!竺!!竺竺竺!竺竺!型!1200400600800100CEBs图3．12数据节点1、数据节点2的CPU、内存利用率19岳；卅耻卅一墨一mle．Ico；∞N兰ln 万方数据山东大学硕士学位论文从图3．12可以看出，随着EB数的增加，数据节点1和数据节点2的内存利用率呈明显上升的趋势，当EB数达到1200左右的时候，它们的内存利用率都已接近100％，与此同时，它们的CPU利用率却不是很高，这说明数据节点的内存成为访问数据库的瓶颈；数据节点1和数据节点2的CPU、内存利用率有着较高的一致性。通过本组实验可以发现：1)管理节点(应用服务器)的CPU、内存利用率都不是很高；2)SQL节点2的CPU利用率明显要比SQL节点1的CPU利用率高，而它们之间的内存利用率差别并不明显；3)数据节点l和数据节点2的内存利用率会随着EB数的增加呈明显上升的趋势，当EB数达到1200左右的时候，它们的内存利用率都已接近100％，与此同时，它们的CPU利用率却不是很高。3．2．2三个数据节点，一个SQL节点(3D1S)虚机配置如表3．13所示：VCPU9(S)内存硬盘管理节点，应用服务器2processors5G30GSOL节点2processors5G30G数据节点12processors5G30G数据节点22processors5G30G数据节点32processors5G30G操作系统rhel6．3Tomcat版本Tomcat6．0实验环境如图3．14所示：表3．123D1S虚机配置 万方数据山东大学硕士学位论文图3．143D1S实验环境管理节点、应用服务器(两者在一台虚机上)的CPU、内存利用率如图3．15所示：CPU，memoryutilizationrateofapplicationserver(managementnode)CPUutilizationratememoryutilizationrate7卜—————盍—————葛厂————1}—————盎—————苗r———％EBs图3．15管理节点，应用服务器的CPU、内存利用率从图3．15可以看出，应用服务器(管理节点)的CPU、内存利用率并不是很高，当EB数达到1150时，它们的利用率都不到16％。SQL节点的CPU、内存利用率如图3．16所示：2l弘非”⋯矿卜卧ll¨卜一更一ole．Ico；∞N兰1n 万方数据山东大学硕士学位论文60r孚50。；40i呈30一‘=20‘CPU，memoryutilizationrateofSQLnodeCPUutilizationratememoffutilizationrate图3．16SQL节点的CPU、内存利用率从图3．16可以看出，在EB数未达到950前，SQL节点的CPU、内存利用率变化都不是很明显，当EB数超过950时，SOL节点的CPU、内存利用率呈现明显上升的趋势，此时如果有更多的EB数去访问数据库集群，则可能需要增加SQL节点的数目来缓解SQL节点的压力。数据节点1、数据节点2、数据节点3的CPU、内存利用率如图3．17所示：CPU，memoryutilizationrateofdatanodel，datanode2，datanode3Hr——————————————1———————一墅}一∞l≯i、—，竺∞。2c“r呈；砬一呈I；帅ii、、＼／__／omemoryutilizationrate0fdatanode3。memoryutilizationrate0fdatanodel一memoryutilizationrate0fdatanode2CPUutilizationrate0fdatanode3I——CPUutilizationrate0‘datanode2CPUutilizationrate0fdalanodel0瑚枷∞EBs图3．17数据节点l、2、3的CPU、内存利用率从图3．17可以看出，随着EB数的增加，数据节点1、数据节点2和数据节点3的内存利用率保持平稳，在46％左右，没有出现2D2S实验发生的数据节点内存紧张问题，同时我们发现一个有趣的问题，当EB数达到950的时候，数据节点1、数据节点2和数据节点3的CPU利用率出现了暂时的下降，这个问题值 万方数据山东大学硕士学位论文得进一步研究。通过本组实验可以发现：1)管理节点(应用服务器)的CPU、内存利用率都不是很高；2)在EB数不大的情况下，SQL节点的CPU、内存利用率不是很高；3)数据节点1、数据节点2和数据节点3的CPU、内存利用率都不是很高。3．2．3三个SQL节点，一个数据节点(1D3S)所示虚机配置如表3．18所示VCPU(S)内存硬盘管理节点，应用服务器2processors5G30GSql节点12processors5G30GSql节点22processors5G30GSql节点32processors5G30G数据节点12processors5G30G操作系统rhel6．3Tomcat版本Tomcat6．0实验环境如图3．19所示：表3．181D3S虚机配置图3．191D3S实验环境管理节点、应用服务器(二者在一台虚机上)的CPU、内存利用率如图3．20 万方数据山东大学硕士学位论文CPU，memoryutilizationrateofapplicationserver(managementnode)CPUutilizationratememoryutilizationrate600EBs200图3．20管理节点、应用服务器CPU、内存利用率从图3．20可以看出，应用服务器(管理节点)的CPU利用率会随着EB数的增加呈现明显上升的趋势，内存利用率保持相对稳定，但两者的利用率都不是很高。SQL节点1、SQL节点2、SQL节点3的CPU、内存利用率如图3．21所示：CPU．memoryutilizationrateofSQLnodel，SQLnode2SQLnode3一memoryutilizalionrateofSQInodel——memoryuti]iza自onrateofSQLnode2一+CPUutilizationrate0fSQLnode2·memoryutilizationrateofSQLnode3CPUutilizationrate0fSQLnode3—一CPUutilizationrateofSQLnodel—==：=二二======)—《=!赢————-_商————1赫400图3．21SQL节点1、2、3的CPU、内存利用率从图3．21可以看出，SQL节点1、SQL节点3的CPU、内存利用率都保持相对稳定，SQL结点2的CPU利用率随着EB数的增加呈上升趋势，这是因为keepalived的virtualip映射的是SQL节点2的ip，访问数据库的请求会先经过SQL节点2，再访问数据节点。与此同时，我们发现，当SQL节点数目增加到三个的时候，并没有出现24弩|⋯j似畔．．叶让卅卜矗一零一oleLco；∞N兰ln 万方数据山东大学硕士学位论文3D1S实验中SOL节点的CPU利用率发生的突然上升现象，从另一方面验证了我们在图3．15所做的假设，即在EB数较大的情况下，增加SQL节点的数目可以缓解SOL节点的压力。数据节点的CPL、内存利用率如图3．22所示：CPU，memoryutilizationrateofdatanodememOryutilizationrateCPUutilizationrate200400600EBs图3．22数据节点的CPU、内存利用率从图3．22可以看出，数据节点的内存利用率一直居高不下，而它的CPU利用率却不是很高，这说明单个数据节点不能满足用户访问的需求，数据节点的内存资源成为用户访问数据库的瓶颈。三组实验中不同角色节点的性能比较如表3．23所示。CPU利用率内存利用率2D2S管理节点低SOL节点1保持平稳，在4％左右保持平稳，在8％左右SqL节点2SOL节点2的CPU利用率要比同SOL节点1SQL节点1的CPU利用率高的多，在20％以上，且随着EB数的增加呈上升趋势数据节点1保持平稳，在52％左右随着EB数的增加，内存利用率呈明显上升的趋势，当EB数达到1200左右的时候，它们的内存利用率已接近100％数据节点2同数据节点125 万方数据山东大学硕士学位论文3D1S管理节点低SQL节点1在EB数未达到950前，CPU在EB数未达到950前，内存利用率变化都是很明显，在利用率变化都不是很明显，20％左右，当EB数超过950在9％左右，当EB数超过950时，CPU利用率呈现明显上时，内存利用率呈现明显上升的趋势数据节点1保持在54％以下，当EB数达保持平稳，在46％左右到950的时候，CPU利用率出现了瞬间的下降数据节点2同数据节点1数据节点3同数据节点1同数据节点l1D3S管理节点低SOL节点1保持相对稳定，在2％左右保持相对稳定，在15％左右SQL节点2CPU利用率随着EB数的增加内存利用率随着EB数的增加呈明显上升趋势，在EB数达呈缓慢上升趋势，在EB数达到1150的时候，利用率达到26％17％SQL节点3保持相对稳定，在2％左右保持相对稳定，在7％左右数据节点1CPU利用率保持相对稳定，在内存利用率一直居高不下，54％左右在94％左右表3．23三组实验中不同角色节点的性能比较通过本组实验可以发现：1)应用服务器(管理节点)、SQL节点1、SQL节点2和SOL节点3的CPU、内存利用率都不是很高；2)数据节点的内存利用率很高，而CPU利用率并不是很高，这说明，数据节点的内存成为用户访问数据库集群的瓶颈，需要增加数据节点来提高数据访问性能。3．3本章小结本章首先比较了不通连接方式(Keepalived、MySQL—Proxy)下，MySQL集群的性能，实验结果发现在不涉及数据库写操作的情况下，keepalived的性能 万方数据山东大学硕士学位论文要优于MySQLProxy，然后研究了不同数目节点的配置配置对MySQL集群的影响，我们做了三组实验，分别是2D2S(两个数据节点和两个SQL节点)、1D3S(一个数据节点和三个SQL节点)、3D1S(三个数据节点和一个SOL节点)，实验结果发现：1)较多的数据节点数能够提升Mysql集群的性能。在2D2S组试验中，当Eb数达到1200左右时，两个数据节点的内存利用率都上升到了98％左右，在3D1S组试验中，我们配置了三个数据节点，在Eb数达到1200时三个数据节点的内存利用率均不到50％，在1D3S组试验中，我们只配置了一个数据节点，数据节点内存利用率一直保持在90％以上；2)数据节点承担了数据库的绝大部分压力，而SQL节点以及管理节点压力要小得多；3)当并发访问的明数较多而SQL节点的CPU利用率偏高时，需要增加SQL节点的数目来减轻SOL节点的压力；4)数据节点之间的CPU、内存利用率保持着较高的一致性，这一点可以在2D2S组实验和1D3S组实验看出来，它们分别有两个和三个数据节点，不同数据节点之间的CPU、内存利用率的大小和变化趋势基本一致。 万方数据山东大学硕士学位论文第4章多租户条件下，不同规模业务组合对数据库集群性能的影响多租户服务系统的客户端，往往是由1～n(1≤n)个租户组成。每个租户在制造业中相当于一个主机厂。每个租户下面又会有很多的用户，每个用户相当于制造业中的一个供应商。当多租户服务系统的客户端的每个租户，分别并发多个交互去访问应用的时候，多租户服务系统中的数据库服务器里的数据规模，很大程度上影响到数据查询检索的速度，进而影响每种交互的响应时间。而数据库服务器里的数据规模，往往是由租户的规模和业务忙闲决定的。租户的规模主要是由产品数决定的，业务忙闲主要是由订单天数决定的。多租户环境下，不同规模和业务类型的租户的组合会产生不同的负载压力，从而影响彼此发出的交互的查询响应时间。因此本文中，我们按照租户的规模和业务忙闲两个因素，把多租户服务系统的客户端的租户种类简单分为以下六种类型：l：小型企业淡季(产品数=1，订单天数=1)2：小型企业忙季(产品数=1，订单天数=3)3：中型企业淡季(产品数=3，订单天数=1)Lt：中型企业忙季(产品数=3，订单天数=3)5：大型企业淡季(产品数=5，订单天数--1)6：大型企业忙季(产品数=5，订单天数--3)本文中，我们假设在多租户服务系统的客户端只有两个租户，则相应的多租户的组合有21组，如图3．23所示：29租户，勃罩合情况≥国营诺罄?⋯鞴孥i。辩磐懈潍耩juM峙莹}{I兰基她堇隧垃基鬟瑟辩暑跫兰主兰_L(1．1)(2．，】(2．2)露蠹类型3(3．1)}"Ⅳ4)z!【y4-(d．】)(d．2)(4，3)(d．‘)#!薹i=：-尘!E生于E帕‘；(5．1)‘5．2)‘5．3)(5．4)(5．5)li黧；聋s透墅6(6．1)(6。2)(6，3)(6．d)(6．5)(6。6)图3．23：租户组合情况 万方数据山东大学硕士学位论文我们在多租户组合是(1，6)和(3，4)和(1，3)三种情况下分别做了一组实验。在第三章工作的基础上，我们使用keepalived连接数据库，并配置了一个数据节点和三个SQL节点。虚机配置如表3．24所示：VCPU(S)内存硬盘管理节点，应用服务器1processors5G30GSQL节点12processors5G30G数据节点12processors5G30G数据节点22processors5G30G数据节点32processors5G30G操作系统rhel6．3Tomcat版本Tomcat6．0实验环境如图3．25所示：表3．24图3．25多租户实验环境29 万方数据山东大学硕士学位论文4．1CPU、内存利用率的分析应用服务器、管理节点(两者在一台虚机上)的CPU、内存利用率如图3．26所示：CPU．memoryutilizationrateofapplicationserver(managementnode)25——⋯一§卜一万≠爹群一一夕一了一／／／／雪匕／一二：二二二：：一一一一一一～一一一=一=二三≥≥7≮／一’～一—]：丽面丽而丽cPuutil|zationrateof(1，3)Il—CPUutilEationrateof(3，4)I--memoryutilizationrateof(1，6州memoryutil吲ion陷Ieof(1，3)J图3．26应用服务器、管理节点的CPU、内存利用率从图3．26可以看出，多租户不同组合情况下，应用服务器(管理节点)的CPU、内存利用率都不是很高。随着两个租户(客户端)同时并发的EB数的不断增加，应用服务器(管理节点)的CPU、内存利用率呈明显上升趋势。应用服务器(管理节点)的CPU、内存利用率在三种不同租户组合条件下，差别并不是很大。SQL节点的CPU、内存利用率如图3．27所示：CPU，memoryutilizationrateofSQLnode30旺)一一CPUutilizationrateof(1，6)CPUutilizationrateof(1,3)”【一CPUutilizationrateof(3、4)一I—memoryutilizationrateof(1，6)野r黑c碡呈星∞I；———■刁。r／∥◆＼墨mem；o墨吖篓rateo盥3,4；l。∥多夕77‘嘶I瞄Iaon“)f，一二—／一一一j≯歹乏7一—：≥：==二．7一￡二一一一一一一一一炒乡10。15。20。葛D300350EBS面——]F丁蠢图3．27SOL节点的CPU、内存利用率 万方数据山东大学硕士学位论文从图3．27可以看出，多租户不同组合情况下，SQL节点的CPU、内存利用率都不是很高。不同多租户组合条件下，随着两个租户(客户端)同时并发的EB数不断增加，SQL节点的内存利用率变化不是很明显，而CPU利用率会随着EB数的增加呈上升趋势，相比之下，多租户组合(1，6)和(3，4)上升的速度比(1，3)组合要快得多。数据节点l的CPU、内存利用率如图3．28所示：CPU，memoryutilizationrateofdatanode1s卜_歹第二一一I／，，7／7邑∞l／，，7，一——／7JCPUutilizationrateof(1，6)CPUutilizationrateof(1，3)CPUutilizationrateof(3,4)memoryutilizationrateof(1，6)memoryutilizationrateof(1，3)memoryutilizationrateof(3,4)】留1丽15020。。0⋯⋯2面面——面面—1五而一550EBS图3．28数据节点1的CPU、内存利用率从图3．28可以看出，不同的多租户组合情况下，数据节点1的CPU利用率并不是很高，但是随着两个租户(客户端)同时并发的EB数的不断增加，数据节点l的CPU利用率呈现明显上升的趋势，相比之下，多租户组合(1，6)和(3，4)上升的速度I：L(1，3)组合要快得多；数据节点1的内存利用率不是很高，而且保持在相对稳定的水平，三种不同的多租户组合条件下，数据节点1的内存利用率几乎重合在一起。数据节点2的CPU、内存利用率如图3．29所示：31 万方数据山东大学硕士学位论文CPU，memoryutilizationrateofdatanode270—————————————————————————————————————————1——————————r—————————T—————————?——————————r—————r———————一60一至孓o÷n)∞c4卜。一7=30一／一一一一一]7CPUutilizationrateof(1，6)CPUutilizationrateof(1，3)一CPUutilizationrateof(3,4)一memoryutilizationrateof(1，6)memoryutilizationrateof(1，3)一?memoryutilizationrateof(3,4)10——～一～————～_一_一一一～——50100150200250300350400450500550EBS图3．29数据节点2的CPU、内存利用率从图3．29可以看出，数据节点2的CPU、内存利用率与数据节点l的CPU、内存利用率有着较高的一致性。数据节点3的CPU、内存利用率如图3．30所示：CPU，memoryutilizationofdatanode360一一——一——，⋯一一一一一．，55～一一一一一一一50一一一一一一一一——一‘一———^一————————————————————_—^————————————===========——e——======一———-—·——————。，—～／琴45一／7，a)40—7一·一，巾c35—0；30一．；25—320-15一／CPUutilizationrateof(1，6)／t-，，CPUutilizationrateof(1，3)一CPUutilizationrateof(3,4)一一memoryutilizationrateof(1，6)memoryutilizationrateof(1，3)一memonjutilizationrateof(3,4)一250300350400EBs图3．30数据节点3的CPU、内存利用率从图3．30可以看出，数据节点3的CPU利用率与数据节点1、数据节点2的CPU利用率有一致性。三组实验不同角色节点的性能比较如表3．31所示。32 万方数据山东大学硕士学位论文CPU利用率内存利用率(1，6)组合管理节点随着髓数的增加呈明显随着EB数的增加呈缓慢上升趋势，在EB数为上升趋势，在EB数为5050时，利用率为5％，当时，利用率为16％，当EB数达到1150的时EB数达到1150的时候，候，利用率达到15％利用率达到19％SQL节点随着EB数的增加呈明显保持相对稳定，在20％左上升趋势，在朗数为右50时，利用率为8％，当朗数达到1150的时候，利用率达到56％数据节点1随着EB数的增加呈明显保持相对稳定，在48％左上升趋势，在EB数为右50时，利用率为27％，当EB数达到1150的时候，利用率达到53％数据节点2与数据节点l的CPU利与数据节点1的内存利用率存在较高的一致性数据节点3与数据节点l的CPU利与数据节点1的内存利用率存在较高的一致性(3，4)组合管理节点随着EB数的增加呈明显上升趋势，在EB数为上升趋势，在EB数为5050时，利用率为3％，当时，利用率为13％，当EB数达到1150的时EB数达到1150的时候，候，利用率达到15％利用率达到23％SQL节点随着EB数的增加呈缓慢保持相对稳定，在30％左上升趋势，在EB数为右50时，利用率为7％，当EB数达到1150的时候，利用率达到60％33 万方数据山东大学硕士学位论文数据节点1随着EB数的增加呈明显保持相对稳定，在48％左上升趋势，在EB数为右，同(1，6)组合50时，利用率为20％，当EB数达到1150的时候，利用率达到53％数据节点2与数据节点1的CPU利与数据节点1的内存利用率存在较高的一致性数据节点3与数据节点1的CPU利与数据节点1的内存利用率存在较高的一致性(1，3)组合管理节点随着朗数的增加呈明显随着EB数的增加呈明显上升趋势，在EB数为上升趋势，在EB数为5050时，利用率为7％，当时，利用率为13％，当EB数达到1150的时EB数达到1150的时候，候，利用率达到17％利用率达到24％SOL节点随着阻数的增加呈缓慢保持相对稳定，在30％左上升趋势，在EB数为右50时，利用率为5％，当EB数达到1150的时候，利用率达到32％数据节点1随着EB数的增加呈明显保持相对稳定，在48％左上升趋势，在EB数为右，同(1，6)组合50时，利用率为12％，当EB数达到1150的时候，利用率达到48％数据节点2与数据节点1的CPU利与数据节点1的内存利用率存在较高的一致性数据节点3与数据节点1的CPU利与数据节点1的内存利用率存在较高的一致性表3．31三组实验不同角色节点的性能比较 万方数据山东大学硕士学位论文从本组实验可以发现，不同多租户组合条件下，随着两个租户(客户端)同时并发的EB数不断增加，数据节点1、数据节点2和数据节点3的内存利用率变化不是很明显，且维持在相对稳定的水平，而CPU利用率会随着EB数的增加呈上升趋势，相比之下，多租户组合(1，6)情况下，CPU利用率上升的速度最快，多租户组合(1，3)情况下，CPU利用率上升的速度最慢。从实验中，我们发现，增加数据节点可以有效地避免数据节点内存紧张的问题。4．2响应时间的分析负载客户端生成还需要考虑到的很重要的一方面就是模拟用户行为模式的设计。这些行为模式其实就是SRM应用中的各种业务，虽然在SRM应用中的业务比较多(包括好多大类，每个大类里面又有比较细的划分)，但是在现实生活中，用户经常使用到的SRM中的业务种类比较固定的，为了便于实现，我们可以从每个大类中把用户常用到的、比较典型的业务提取出来，而那些不常用的，我们在基准测试系统中就可以抛弃了，选取的主要业务交互及类型如表3．31所示：模块只读类型读／写类型计划3天采购计划查询(1)周采购计划查询(2)月采购计划查询(3)库存库存查询(4)账单账单信息查询(5)发票发票信息查询(6)财务财务信息查询(7)零部件零部件信息查询(8)招标招标信息查询(9)招投标(10)订单订单查询(11)订单打印(12)订单发布(13)用户主页(14)登陆(16)用户配置(15)密码修改(17)用户配置修改(18)表3．31SRM主要交互业务及类型35 万方数据山东大学硕士学位论文我们主要分析了不同多租户组合条件下，第2、3、6、9种交互的响应时间。不同租户组合下第二种交互的响应时间如图3．32所示：theresponsetimeofsecondkindinteraction25——————一——————————一——————accessdatabase6undercombination(1，6)l一accessdatabase4undercombination(3，4)20-一accessdatabase3undercombination(3，4)一accessdatabase1undercombination(1，6)；，_o—accessdatabase3undercombination(1，3)：，E,”15【—+accessdatab—ase1undercombin—atio必n(1,3)，，7／1圣e，／c=，詈叶，．j--，／1△21。}二一一一一二一j一二一一一一一一一一一一一二}7’／／7’／。，’7J5f二一一一一一一一一?—一一一一一一一一7]上!垂乏兰丝三三三至三三i三至三!巨三=二二：j一，。。一一一一一一～：==二===：=。。—1～50106150200250300350400450500550EBs图3．32不同租户组合下第二种交互响应时间从图3．32可以看出，当多租户组合是(1，6)的时候，访问租户六数据库的响应时间最长，其次是租户组合是(3，4)的时候，访问租户四数据库的响应时间。其余情况访问数据库的响应时间差别并不明显。不同租户组合下第三种交互的响应时间如图3．33所示：theresponsetimeofthirdkindinteractionaccessdatabase6undercombination(1，6)13。l{accessdatabase4undercombination(3,4)jaccessdatabase3undercombination(3,4)11(1，)，ooelaccessdalabaseundercombination6二生。Iaccessdatabase3undercombination(1，3)《，7’∞6accessdalabase1undercombination(1，3)，，三狲甜0．萤。i上生兰主二：二兰：—壬兰至三三三三E三三三王三主50100150200250300350400450500550EBs图3．33不同租户组合下第三种交互响应时间 万方数据山东大学硕士学位论文从图3．33可以看出，不同租户组合下第三种查询响应时间与第二种查询的响应时间有着一致性。不同租户组合下第六种查询响应时间如图3．34所示：theresponsetimeofsixthkindinteractionaccessdatabase6undercombination㈧6)～一accessdatabase4undercombination(3,4)⋯一accessdatabase3undercombination(3,4)』。accessdatabase1undercombination(1,6)oI—accessdatabase1undercombination㈠3)∞一e—accessdatabase3undercombination㈠3)s}，，争一一一一《JL二：：J[／一L一一一一I一三‘I一茎I刍EBs图3．34不同租户组合下第六种交互响应时间从图3．34可以看出，不同租户组合下第六种查询响应时间与第二种查询的响应时间、第三种查询的响应时间有着一致性。不同租户组合下第九种查询响应时间如图3．35所示：theresponsetimeofninthkindinteractionaccessdatabase6undercombination(1，6)14。accessdatabase4undercombination(3,4)accessdatabase3undercombination(3,4)12。accessdatabase1undercombination(1，6)accessdatabase3undercombination(1，3)一>10’二二!!堡!!!!!塑堕!!!型!!!!!!!!塑!!!!：翌4一∥'，一一t：．，≥二。一一，一一一一一一一‘2_E：一_一。二。。二／7一—。一一一一一一一一EBs图3．35不同租户组合下第九种交互响应时间37 万方数据山东大学硕士学位论文从图3．35可以看出，当多租户组合是(1，6)的时候，访问租户六数据库的响应时间最长。与第二种交互的响应时间、第三种查询的交互时间、第六种交互的响应时间不同的是，不同租户组合情况下的第九种交互的响应时间差别拉大。4．3本章总结本章首先研究了多租户不同组合条件下，应用服务器(管理节点)、SQL节点、数据节点的CPU、内存利用率，实验结果发现，在数据节点内存资源充足的情况下，对于不同的租户组合，应用服务器(管理节点)与SQL节点的CPU、内存利用率都不是很高，数据节点1、数据节点2和数据节点3的CPU利用率、内存利用率也不是很高。随着两个租户(客户端)同时并发的EB数不断增加，数据节点1、数据节点2和数据节点3的内存利用率变化不是很明显，且维持在相对稳定的水平，而CPU利用率会随着EB数的增加呈上升趋势，相比之下，多租户组合(1，6)情况下，CPU利用率上升的速度最快，多租户组合(1，3)情况下，CPU利用率上升的速度最慢。本章然后分析了不同多租户组合条件下，四种典型交互的响应时间，实验结果发现，当多租户组合是(1，6)的时候，访问租户六数据库的响应时间最长，其次是租户组合是(3，4)的时候，访问租户四数据库的响应时问；第二种交互的响应时间、第三种交互的响应时间与第六种交互的响应时间有着一致性，第九种交互的响应时间差别比较大。 万方数据山东大学硕士学位论文5．1本文工作总结第5章总结、建议与展望本文主要做了三个方面的工作：1)比较了不同连接方式(mysql～proxy、keepalived)下，MySQL集群的性能，实验用到了三台物理服务器serverl、server2和server3，服务器的配置、角色以及实验环境如章节3．1所介绍，分析了serverl、server2和server3的CPU、内存利用率，分析结果表明，在不涉及数据库写操作的情况下，keepalived的性能要优于MySQLProxy。2)研究了不同数目节点(SQL节点与数据节点)的配置对MySQL集群性能的影响，针对不同数目节点的配置主要做了三组实验，分别是(两个数据节点和两个SQL节点)、(--个数据节点和一个SQL节点)、(一个数据节点和三个SQL节点)。分析了管理节点(应用服务器)、SQL节点和数据节点的CPU、内存利用率，分析结果表明：(1)较多的数据节点数能够提升Mysql集群的性能；(2)数据节点承担了数据库的绝大部分压力，而SOL节点以及管理节点压力要小得多；(3)当并发访问的EB数较多而SQL节点的CPU利用率偏高时，需要增加SQL节点的数目来减轻SQL节点的压力；(4)所有数据节点的CPU、内存利用率存在着一致性(大小、变化趋势等)。3)分析了不同业务规模的租户组合对MySQL集群性能的影响，在第3章工作的基础上，实验使用keepalived连接应用与MySQL集群，并配置了三个数据节点和一个SQL节点，分析了几种不同业务规模的租户组合条件下，管理节点(同时充当应用服务器)、SQL节点、数据节点的CPU和内存利用率，以及几种典型交互的响应时间，分析结果发现：(1)在数据节点内存资源充足的情况下，对于不同的租户组合，应用服务器(管理节点)与SQL节点的CPU、内存利用率都不是很高，数据节点1、数据节点2和数据节点3的CPU利用率、内存利用率也不是很高。随着两个租户(客户端)同时并发的EB数不断增加，数据节点1、数据节点2和数据节点3的内存利用率变化不是很明显，且维持在相对稳定的水平，而CPU利用率会随着EB数的增加呈上升趋势，相比之下，多租户组合(1，39 万方数据山东大学硕士学位论文6)情况下，CPU利用率上升的速度最快，多租户组合(1，3)情况下，CPU利用率上升的速度最慢；(2)当多租户组合是(1，6)的时候，访问租户六数据库的响应时间最长，其次是租户组合是(3，4)的时候，访问租户四数据库的响应时间；第二种交互的响应时间、第三种交互的响应时间与第六种交互的响应时间有着一致性，第九种交互的响应时问差别比较大。5．2多租户应用的数据库整体优化部署的分析建议1)针对应用与数据库的连接方式，我们建议使用keepal]ved，这是因为，尽管mysql—proxy可以实现读写分离的功能，但是通过3．1节实验可以发现，使用keepalived连接数据库，server2服务器和server3服务器的内存利用率明显要比使用mysql-proxy连接数据库时内存利用率低，而它们的CPU利用率差别并不明显，几乎重合在一起。2)针对SQL节点与数据节点数目配置的问题，通过3．2节实验可以发现，MySQL集群对数据节点的内存有着较高的需求，数据节点承担了访问数据库集群的大部分压力，当数据节点内存资源利用较高时，增加数据节点的数目能够有效的提升MySQL集群的性能；当SOL节点的CPU利用率较高时，增加SOL节点的数目可以缓解SOL节点的压力，提升MySQL集群的性能。5．3未来工作展望由于时间关系，本文尚存在一些不足，希望在未来的工作中加以改进完善：1)在章节3．2．2所做实验(3DIS)中，当EB数达到950的时候，数据节点1、数据节点2和数据节点3的CPU利用率出现了暂时的下降，这个问题值得进一步研究。2)可以将keepalived与mysql—proxy结合在一起，测试不同业务规模的租户组合多数据库性能的影响。具体的，要在SQL节点和管理节点都要配置keepalived，keepalived的虚拟IP(VIP)仅映射到本机的实际IP，并且把管理节点的优先级设置成最高，这样管理节点成为MASTER，拥有虚拟路由器的IP地址，负责转发数据包和相应的ARP请求；管理节点需要安装mysql-proxy，这样，管理节点转发的数据包和相应的ARP请求就会经过mysql-proxy自带lua 万方数据山东大学硕士学位论文脚本进行读写分离的判断，然后再访问数据库。3)本文只是在多租户组合是(1，6)和(3，4)和(1，3)三种情况下分别做了一组实验，分析了管理节点(应用服务器)、SQL节点、数据节点l、数据节点2和数据节点3的CPU、内存利用率，还有剩余18种多租户组合没有分析。4)多租户组合是(1，6)和(3，4)和(1，3)三种情况下，我们只分析了第2、3、6、9种查询的响应时间，还有剩余14种查询的响应时间没有分析。5)可以固定SOL节点与数据节点的数目，研究内存大小与CPU核数对MySQL集群性能的影响。41 万方数据山东大学硕士学位论文参考文献【1]ZeyuDi，shijUnLiu，CaltomPu，XiaoningHao．S-BM：Abenchmarksuiteformulti—tenantsupplierrelationshipmanagementservice．201310thInternationalConferenceonServiceSystemsandServiceManagement(ICSSSM)，2013，Page(s)：692-697[2]Oracle．OracleRealApplicationServerCluster109．TechnicalWhitePaper，May2005[3]Whei·JenChen，RavAhuja,eta1．DB2IntegratedClusterEnvironmentDeploymentGuide．IBMredbooks．October2004．2--62[4】杨睿．SaaS平台多租户数据管理及逻辑存储模型的研究．2013．06[5】韩顺．基于虚拟化技术的多租户应用系统性能隔离算法研究．2010．04[6】李现艳，赵书俊，初元平．基于MySQL的数据库服务器性能测试[J】．核电子学与探测技术．2011(01)[7】邱朝阳，沈程吴．基于MySQLReplication的数据库集群解决方案[J]．电脑与电信．2009(08)[8]DavidRaflen．ParallelSysplexClusterTechnologyOverview．IEEETransactionsonKnowledgeandDataEngineering．2002[9]StephenA．Cook，JanPachl，IrwinS．Pressman．TheoptimallocmionofreplicasinanetworkusingaREAD-ONE-WRITE-ALLpolicy．DistributedComputing．2002(1)[10】汪海洋，凌永兴，包丽红，姚萌萌．基于keepalived的高可用性应用研究．电子技术研发ElectronicsR&D．2014．07【11】杨芳萍，马宏艳，王斌．数据库集群中间件MySQLProxy探讨．电子制作．2013．11．25【12】祝雄锋．数据库集群中间件MySQLProxy研究与分析．2011．05【13]SaeedSharifian，SeyedA．Motamedi，MohammadK．Akbari．Anapproximation—basedload-balancingalgorithm、们madmissioncontrolforclusterwebserverswithdynamicworkloads【J】．TheJournalofSupercomputing．2010(3)42