基于自主计算的代理缓存集群异常检测系统

暂无

基于自主计算的代理缓存集群异常检测系统\n技术领域\n[0001] 本发明涉及代理缓存集群异常检测系统。\n背景技术\n[0002] 自主计算的核心是自我管理，正如人体的整个神经系统一样，感知自身内部和外界环境某些因素的变化情况，从而自主的来调节和改变状态以便适应新的变化。不同于以往的其他管理模式，自主计算的整个感知和修复的过程均不需要人的干预。目前对于自主计算相关的研究主要集中在IBM，它们分析了在设计自主计算系统和理解自主计算系统行为时所要面对的各种问题。Jann等人研究了自主计算的动态配置方法。Arizona大学的Hariri研制了一个自主计算环境AUTONOMIA。在国内，中科院计算所研究了面向服务的主体自主协商和服务匹配。\n[0003] 为了满足用户的大量访问需求，代理集群系统规模一般较为庞大，内部的管理也变得越来越复杂，一旦不能及时检测出内部的异常并加以修复，后果将会很严重。传统的异常检测机制主要有：(1)基于统计的异常检测机制，但是该机制的缺点是未考虑时间的发生顺序，因此对利用事件顺序关系的攻击难以检测；当攻击者意识到被监控后，可能会利用统计轮廓的动态自适应性，通过缓慢改变其行为，来训练正常特征轮廓，最终使检测系统将其异常活动判为正常；难以确定评判正常和异常的阈值，阈值太低或太高易出现虚警或漏警；\n(2)预测模式的异常检测机制，但是该机制的确定是规则产生不充分，容易导致高的虚警率；计算量比较大；(3)基于系统调用的异常检测技术，但是该机制的缺点是不能检测出合作攻击者与盗用者的。\n发明内容\n[0004] 本发明为了解决现有代理集群系统规模庞大责，产生异常时不能及时检测导致严重后果的问题，从而提供一种基于自主计算的代理缓存集群异常检测系统。\n[0005] 基于自主计算的代理缓存集群异常检测系统，它包括：\n[0006] 状态检测模块，用于对分布式代理集群进行状态监测，获取分布式代理集群运行时的详细数据；\n[0007] 状态自感知模块，用于接收状态检测模块提供的状态数据，对状态数据进行分析，识别当前分布式代理集群的运行状态；\n[0008] 状态自恢复模块，用于根据状态自感知模块获得的运行状态结果判断需要调整的参数以及调整的程度，并向算法执行模块发送参数调整命令；\n[0009] 算法执行模块，用于执行自恢复模块发送的调整参数命令，动态改变运行参数。\n[0010] 本发明实现了基于自主计算的代理缓存集群异常的检测，解决了现有代理集群系统规模庞大责，产生异常时不能及时检测导致严重后果的问题。\n附图说明\n[0011] 图1为本发明基于自主计算的代理缓存集群异常检测系统的结构示意图；\n[0012] 图2为具体实施方式六没有使用I-Ketama算法的方案1实验结果示意图；\n[0013] 图3为具体实施方式六使用I-Ketama算法的方案1实验结果示意图；\n[0014] 图4为具体实施方式六没有使用I-Ketama算法的方案2实验结果示意图；\n[0015] 图5为具体实施方式六使用I-Ketama算法的方案2实验结果示意图；\n[0016] 图2-图5中，曲线1代表Cache Server1的曲线图，曲线2代表Cache Server2的曲线图；\n[0017] 图6为具体实施方式七的定时请求模块具体的请求数据包格式示意图；\n[0018] 图7为具体实施方式七的定时请求模块的响应数据包格式示意图\n[0019] 图8为具体实施方式七的收集监测项数据模块的位于后端缓存节点上的监测项采集流程示意图；\n[0020] 图9为具体实施方式七的感知监测项的处理模块的工作流程。\n具体实施方式\n[0021] 具体实施方式一、结合图1说明本具体实施方式。基于自主计算的代理缓存集群异常检测系统，它包括：\n[0022] 状态检测模块，用于对分布式代理集群进行状态监测，获取分布式代理集群运行时的详细数据；\n[0023] 状态自感知模块，用于接收状态检测模块提供的状态数据，对状态数据进行分析，识别当前分布式代理集群的运行状态；\n[0024] 状态自恢复模块，用于根据状态自感知模块获得的运行状态结果判断需要调整的参数以及调整的程度，并向算法执行模块发送参数调整命令；\n[0025] 算法执行模块，用于执行自恢复模块发送的调整参数命令，动态改变运行参数。\n[0026] 状态检测模块：该模块通过设置在分布式代理集群上的状态监测程序，获取分布式代理集群运行时各方面的详细数据。这些数据包括了系统资源使用情况、日志信息等运行状态数据。状态检测模块并不是简单的把获取的所有原始数据发送给状态自感知模块，而是首先对这些原始数据进行归一化处理之后向状态自感知模块提供。\n[0027] 状态自感知模块：该模块接收状态检测模块提供的状态数据，对这些数据加以分析，从而识别出当前分布式代理集群的运行状态，以便于判断系统是否处于异常状态，决定是否对系统进行调整。一旦需要调整的时候，该模块将向自恢复模块发送当前的系统状态S。状态自感知模块关键是要能准确的根据状态数据，判断当前系统是否处于异常状态。\n[0028] 状态自恢复模块：该模块核心是针对缓存服务器动态负载均衡的算法。该算法可以动态接收和调整执行参数，以便试试解决代理系统的异常情况。当自恢复模块接收到系统的异常状态S时，根据异常状态S决定需要调整的参数用以及调整的程度，接下来将会向算法执行模块发送参数调整的命令，实现恢复系统异常状态的目的。\n[0029] 算法执行模块：该模块执行自恢复模块发送的调整参数的命令，接收到命令之后，被选定的算法将会动态改变运行的参数。此时系统在算法的作用下，将会逐步从异常状态中恢复过来。若是此次调整力度不够，系统将会继续检测状态数据，直到将系统恢复至正常的状态为止。\n[0030] 具体实施方式二、本具体实施方式与具体实施方式一不同的是所述状态检测模块的监测项为硬件资源监测项、网络资源监测项和服务资源监测项；\n[0031] 硬件资源监测项，用于监测CPU使用率C、内存使用率M和磁盘I/O使用率D；\n[0032] 网络资源监测项，用于监测连接数使用率P和网络带宽使用率B；\n[0033] 服务资源监测项，用于监测缓存URL请求频率F。\n[0034] 状态检测模块是整个自决策框架的基础，它定时的收集HTTP缓存服务器的系统信息，获取监测数据值，并进行归一化处理。综合考虑，根据分布式代理缓存系统中HTTP缓存服务器使用的资源属性，将监测项划分为硬件资源、网络资源和服务资源三个部分。\n[0035] 理论上，全部监测这些信息可以较为准确的反应当前个缓存服务器的状态，但是如此多的监测数据有很多对于HTTP缓存服务器的状态影响不大。如果全部监测表中所列的所有数据项，不仅实现起来耗费很大的带宽和资源，而且数据处理起来很会耗费不少时间。\n这些因素都会导致监测模块的“过监测”，所以在本发明中，将选取几种对于系统状态变化影响最为重大的数据项加以监测。他们分别是：CPU使用率、内存使用率、连接数使用率、网络带宽使用率、磁盘I/O使用率以及缓存URL请求频率。\n[0036] 具体实施方式三、本具体实施方式与具体实施方式二不同的是所述硬件资源监测项用于监测CPU使用率C、内存使用率M和磁盘I/O使用率D的方法为：\n[0037] Ⅰ、CPU使用率C的计算方法为：\n[0038] 监测模块采集两次CPU使用情况的总和时间Ttot和CPU空闲时间Tidle，两次采集数据的间隔t为5s，通过分别做差并除以间隔时间获得CPU使用率C：\n[0039] C＝1-(Tidle(ti+1)-Tidle(ti))/((Ttot(ti+1)-Ttot(ti))*t)\n[0040] ti表示上次采集信息的时刻；\n[0041] 在监测CPU利用率信息时，查看/proc/stat文件。HTTP缓存服务器的多个CPU使用信息都存储在这个文件中，而CPU运行情况的汇总信息位于cpu字段一行。该行记录了从开机到现在CPU在不同状态的时间使用情况。状态检测模块需要采集所有CPU使用情况的总和时间(total time)Ttot，以及CPU空闲时间(idle time)Tidle。采集两次Ttot和Tidle之后，通过分别做差并除以间隔时间就可以得到这段时间内CPU空闲率(间隔时间即为两次采集数据的间隔时间5秒钟)。从而CPU的使用率可以得到\n[0042] Ⅱ、内存使用率M的计算方法为：\n[0043] 获取/proc/meminfo文件中物理内存Mtot和可用的物理内存Mfree信息，计算内存使用率M：\n[0044] M＝(Mtot-Mfree)/Mtot\n[0045] 在监测内存使用率信息时，查看/proc/meminfo文件。该文件中有MemTotal和MemFree字段，分别表示总的物理内存大小以及可用的物理内存大小。\n[0046] Ⅲ、磁盘I/O使用率D的计算方法为：\n[0047] 监测模块根据各磁盘的最大读写I/O次数Dmax和每一次采集时刻主机的磁盘读写I/O次数Drw，采集两次后计算得到这段时间内的磁盘I/O使用率D：\n[0048] D＝(Drw(ti+1)-Drw(ti))/(Dmax*t)\n[0049] 在采集磁盘I/O使用率时，需要查看/proc/diskstats文件。此文件中统计了各磁盘的读写次数等信息。本文需要其中的读次数和写次数的总和。对于磁盘支持的最大读写I/O次数使用dd命令创建一个大的文件测试I/O次数来取得。本文测得的开发主机磁盘每秒最大I/O次数为330。同样此文件的统计信息也是从开机时开始累计的，所以采集两次后可以得到这段时间内的磁盘I/O次数利用率。\n[0050] 所述服务资源监测项用于监测连接数使用率P和网络带宽使用率B的方法为：\n[0051] Ⅳ、连接数使用率P的计算方法为：\n[0052] 监测模块获取当前系统中的连接总数Pnow和系统支持的最大连接数Pmax，这两个数据的比值为连接使用率P；\n[0053] P＝Pnow/Pmax\n[0054] 在监测网络连接数时候，查看/proc/sys/net/netfilter/nf_conntrack_count文件。该文件中只有一个数据，该数值就是当前系统中连接总数。系统支持的最大连接数在文件/proc/net/netfiter/nf_conntrack_max中，这两个数据的比值就是连接使用率。\n[0055] Ⅴ、网络带宽使用率B的计算方法为：\n[0056] 监测模块采集用户发送给客户输的发送字节数Bsend和数据发送最大带宽Bmax，采集两次后计算这段时间带宽使用率B：\n[0057] B＝(Bsend(ti+1)-Bsend(ti))/(Bmax*t)\n[0058] 在采集网络带宽使用率时，需要查看/proc/net/dev文件。该文件中统计了主机各个网卡从启动到现在的所有收发包数目、收发字节数的信息。本文需要采集用户发送给客户数据的那块网卡的发送字节数信息。最大带宽以网卡接入时显示的带宽为准。同样需要采集两次才能得出这段时间带宽使用率。\n[0059] 所述网络资源监测项用于监测缓存URL请求频率F的方法为：\n[0060] Ⅵ、缓存URL请求频率F的计算方法为：\n[0061] 监测模块采集URL被代理服务器请求的次数Frefs，采集两次服务请求的次数，计算缓存URL请求频率F：\n[0062] F＝Frefs(ti+1)-Frefs(ti)\n[0063] ti+1表示本次采集信息的时刻。\n[0064] 在缓存主机上，使用squidclient:mgr:object命令获得当前上所有URL在时刻的引用次数，对于每一条URL，均记录了上一时刻的引用次数。\n[0065] 具体实施方式四、本具体实施方式与具体实施方式三不同的是所述状态自感知模块用于接收状态检测模块提供的状态数据，对状态数据进行分析，识别当前分布式代理集群的运行状态的过程为：\n[0066] 状态自感知模块通过CPU使用率C、内存使用率M、磁盘I/O使用率D、连接数使用率P和网络带宽使用率B进行加权求累加和：\n[0067] L＝1-(1-λcC)*(1-λmM)*(1-λpP)*(1-λbB)*(1-λdD)\n[0068] 其中，λi≥0，且0≤(1-λiXi)≤1；\n[0069] 判断本次缓存状态L是否需要异常，定义该缓存的历史状态集Lhistory为：\n[0070] Lhistory＝{Lhistoryο1,Lhistoryο2,...,Lhistoryοn}\n[0071] 定义Lhistory中所有历史状态的平均值 为：\n[0072]\n[0073] n表示历史数据的个数；\n[0074] 如果满足：\n[0075]\n[0076] 则判断代理缓存集群已经处于异常状态，其中\n[0077] {λc,λm,λp,λb,λd}＝{0.5,0.4,0.4,0.4,0.35},\n[0078] 状态检测模块对原始数据数据进行处理之后，分别得到了六个监测项：CPU使用率C、内存使用率M、连接数使用率P、网络带宽使用率B、磁盘I/O使用率D以及缓存URL请求频率F。状态识别则使用这些监测项来进行计算，最简单的形式化公式即对前五个监测项进行加权求累加和，对最后一个监测项单独处理：\n[0079] L＝λ1C+λ2M+λ3P+λ4B+λ5D，且λ1+λ2+λ3+λ4+λ5＝1\n[0080] 可以使用使用率系数来调整各种资源在系统整体中的重要程度。由于系数的归一化，最后的结果L∈[0,1]。当某项资源使用率很高时，整个系统将会出现瓶颈，该公式中只能指定某一个资源的重要程度，不能同时反应其他资源使用率高时的系统情况。一般的加权综合方法有加权平均值、乘积平均值和混合型三种，考虑到课题中的情况是缓存系统中某一资源使用率超高时接受新请求的能力会大大下降，所以选择乘积平均法比较合适：\n[0081] L＝1-(1-λcC)*(1-λmM)*(1-λpP)*(1-λbB)*(1-λdD)\n[0082] 在该公式之中，调节系数λi≥0，且0≤(1-λiXi)≤1。某项资源对于系统的整体服务性能产生的影响大，则可以相应的提高对应的系数调节系数λi，且各系数和不在有等于1的限制。某项资源对于缓存服务性能影响很大的话，当该资源的利用率很高的时候，那么L将会接近于1，表明此时该缓存服务器对外服务性能大大下降，需要自决策模块进行一定的调整。L的数值直接决定着下一个自决策模块如何调整缓存服务器动态负载均衡算法的相关参数，进而反馈给分布式代理缓存系统的算法执行模块。\n[0083] 具体实施方式五、本具体实施方式与具体实施方式一或四不同的是所述状态自恢复模块用于根据状态自感知模块获得的运行状态结果判断需要调整的参数以及调整的程度，并向算法执行模块发送参数调整命令的过程为：\n[0084] 步骤一：根据状态自感知模块识别得到的当前分布式代理集群的运行状态中的异常状态，确定需要自恢复的缓存集合；\n[0085] 步骤二：计算处于异常状态缓存的每一条URL的周期引用次数，提取引用次数最多的100条URL；\n[0086] 步骤三：状态自恢复模块将所述100条URL进行MD5哈希运算，得到100个哈希值；\n[0087] 步骤四：利用Ketama算法将所述100个哈希值在哈希环IK对应的缓存服务器变更为互助缓存主机。\n[0088] 在分布式代理缓存集群系统中，多台缓存服务器构成的缓存集群位于代理服务器的后端，实时接受代理服务器的请求，并根据请求的URL将已经缓存的内容返回给代理服务器。由于是一个缓存服务器集群，为了充分利用该缓存服务器的集群，首先就是要解决缓存服务器负载均衡的问题。在本发明中，可以利用自决策的框架最终实现缓存集群动态负载均衡，将代理服务器的访问请求均衡的分发给后端的缓存服务器集群。本发明中使用一致性哈希(Consistent Hashing)的分布式方法来解决缓存服务器集群的负载均衡问题，一致性哈希的基本原理如下所述。\n[0089] 一个node节点对应一个真实的缓存服务器，而所有代理服务器的请求在哈希之后将会分布在整个0～232的一致性哈希环之上。请求的哈希值在一致性哈希环上顺时针方向进行查找，找到的第一个node节点就是该请求应该定位到的真实缓存服务器，但是传统的一致性哈希方法不能很好的实现动态负载均衡，主要原因如下是真实服务器对应的这些node节点在一致性哈希环上不是均匀分布的，直接导致了某些node节点在环上影响的范围小，即请求命中率小，而某些node节点在环上影响的范围大，即请求命中率达，这本身就会造成负载不均衡。为了解决这个问题，最容易想到的方法就是改善哈希算法，使得node能够均匀的分布在一致性哈希环上，但是改善目前主流的哈希算法的空间已经很小，难度很大，效果也不尽人意。针对上述的问题，课题中提出了一种改进的一致性哈希算法——I-Ketama算法，它可以实现分布式缓存服务器集群的动态负载均衡。I-Ketama算法为了解决上述一致性哈希的问题，提出了虚拟节点(v-node)的思想，即一个真实缓存服务器在I-Ketama环上不再仅仅对应一个node，而是可以对应100～200个v-node，这样就可以有效的解决节点分布不均匀的情况，很大程度的控制在服务器增加和减少时候所造成的负载突变的问题。在I-Ketama算法之中，根据代理服务器的请求哈希值定位真实缓存服务器的方法和传统的一致性哈希相同，所以适应性也很好\n[0090]\n[0091] 在I-Ketama算法中，缓存服务器的可变因子集合f是根据状态感知模块获得的L得出的，SERVMULIT是一个v-node数目的初始值，根据文献资料，在本发明中设置为160较为合理。L代表了当前缓存服务器的负载情况：\n[0092]\n[0093] 可知，当某个缓存服务器负载较高的时候，其L值也会相应变高，而f(Si)的值就会降低。由算法可知，该缓存服务器在I-Ketama环上对应的v-node会减少，该缓存服务器的访问请求数目也会减少，负载就会降低。根据集合f即可计算得出各个缓存服务器应该分配的v-node的数目，实现了动态调整缓存服务器集群各个节点的负载情况，有效的缓解了负载过重的服务器的压力，充分挖掘了整个分布式缓存集群的性能。该算法的时间复杂度为O(n2)，但是由于在实际的环境之中，n的值一般远远小于m的值，实际平均时间复杂度接近于O(n)，运行的时间情况较为理想。\n[0094] 具体实施方式六、本具体实施方式所述为代理缓存集群异常状态监测机制的实验分析：\n[0095] 针对提出的缓存服务器动态负载均衡算法，在分布式代理缓存系统上的测试方案如下表1所示：\n[0096] 表1实验方案说明\n[0097]\n[0098] 对于方案1，没有使用I-Ketama算法和使用I-Ketama算法的实验结果分别如图2和图3所示。在图2中，Cache Server1、Cache Server2收到的代理服务器的请求数分别为2290和10，负载比例达到了299:1，如果不利用I-Ketama算法进行调整，那么在Cache Server1负载很高、服务性能下降的时候，Cache Server2却依旧没有被充分使用。而在图3中，对比很明显，当到达了调整阀值的时候，I-Ketama算法显著使Cache Server1的负载被配到了Cache Server2之上，既使自己的负载下降了，又调动了Cache Server2的空闲资源，达到了预期的目标。\n[0099] 对于方案2，没有使用I-Ketama算法和使用I-Ketama算法的实验结果分别如图4和图5所示。为了更进一步验证I-Ketama算法对于缓存服务器的调整程度，又设置了更加悬殊的请求比例399:1，根据相关参考资料和对分布式代理缓存系统的测试，4000个连接基本上是缓存服务器瞬时所能达到的服务极限值，可以从图4和图5的对比中得出，I-Ketama算法依旧能很好的解决两台缓存服务器的负载不均匀问题，该算法性能理想。\n[0100] 具体实施方式七、本具体实施方式与具体实施方式一不同的是所述状态自感知模块对状态数据进行分析采用感知监测项的处理模块，感知监测项的处理模块包括：\n[0101] 定时请求监测项模块，用于每隔固定的时间，前端的代理服务器向后端的缓存节点发送监测项请求信息；\n[0102] 在图6中，包总长度代表请求数据包的总长度，包括包总长度字段；代理编号表示发出请求的前端代理服务器编号；请求编号是一个递增的序号，每发一次请求加1，防止数据包的丢失和乱序；请求类型表示的是请求的监测项内容，这里设置为1，代表5种监测项。\n[0103] 在图7中，包总长度和代理编号的意义和图6表示的一致，响应数据包中的请求编号字段必须与对应的上一次请求数据包一致，否则接收端视为错误；响应类型字段代表响应的监测项，这里设置为2，代表后面的内容是正在的监测项数据；5个监测项的数值转化成了字符串的形式紧跟在响应字段的后面，各个监测项之间用特殊符号“#”分隔开，方便后续的提取。\n[0104] 收集监测项数据模块，用于从应用程序中获取后端缓存节点响应的数据包；\n[0105] 图8为位于后端缓存节点上的监测项采集流程，其中最重要的是将监听套接字添加到对应的组播地址中；为了在缓存节点主机上方便的获取各个监测项数据，使用了处理字符串比较快捷的脚本，调用各项系统命令可以较为方便的获取原始的数据；之后，接收请求数据包并发送响应包。\n[0106] 处理监测项数据模块，根据公式计算该缓存节点的当前状态值\n[0107] L＝1-(1-λcC)*(1-λmM)*(1-λpP)*(1-λbB)*(1-λdD)；\n[0108] 提取历史状态序列模块。\n[0109] 图9为位于前端代理服务器上的感知监测项的处理流程，由于这个过程中同时需要发送请求数据包和接收响应数据包，考虑用多线程的方式来进行设计。首先，定时请求监测项部分会在一开始将Alarm信号阻塞，设置器启动时间为1秒，Alarm信号启动后就会执行处理监测项数据的函数，接着向缓存节点发送请求数据包；然后，由于需要接收后端多个缓存节点的响应数据包，所以发收集监测项数据部分会使用pselect函数来同时检查多个套接字是否变为可读状态；最后，当pselect超时或者由套接字变为可读状态时候，都会启动Alarm信号，此时执行处理监测项数据的函数，并且同时读取缓存节点的监测项，写入到对应的缓存节点数据结构中，以便后续的计算使用。\n[0110] 本发明的工作原理：如图1所示，首先在代理缓存集群中部署状态检测模块、状态自感知模块，实现状态监测、监测数据处理、状态识别以及异常模块定位，然后部署自恢复模块、算法执行模块，从而可以使系统从异常状态中恢复过来。