LTE MLB负载均衡功能介绍

LTE MLB负载均衡功能介绍
LTE MLB负载均衡功能介绍

移动性负载均衡(MLB)应用场景分析

一、概述

随着LTE用户数的快速发展,部分小区的用户数或PRB利用率已接近容量极限,然后其他小区的资源使用率却很低,如何平衡同覆盖或存在重叠覆盖区域的小区间的负载是一个极有意义的课题。移动性负载均衡(Mobility Load Balancing,简称为负载均衡MLB)是指eNodeB 判断小区的负载状态,当小区处于高负载状态时,将负载高小区中部分UE转移到负载低的小区,平衡异频或异系统之间的负载。

二、负载均衡原理介绍

移动性负载均衡(Mobility Load Balancing,简称为负载均衡MLB)是指eNodeB判断小区的负载状态,当小区处于高负载状态时,将负载高小区中部分UE转移到负载低的小区,平衡异频或异系统之间的负载。

负载平衡分为触发模式、选择目标小区、负载均衡执行三个阶段。根据这三个维度可划分为以下各种类型:

2.1 触发模式

负载均衡根据触发模式可以分为空闲态UE预均衡、同步态用户数负载均衡、PRB利用率/PRB评估值负载均衡、下行数传用户数负载均衡等模式,现阶段实现主要负载标准为PRB 利用率、同步态用户数、UE预均衡。

2.1.1 基于PRB利用率的触发模式

启动基于PRB利用率的负载均衡后,eNodeB以每秒为周期测量小区PRB利用率和小区同步态用户数。若连续5秒内同时满足以下条件,则触发基于PRB利用率的负载均衡。

●小区某类PRB利用率≥InterFreqMlbThd +LoadOffet

●小区同步态用户数≥MlbMinUeNumThd +MlbMinUeNumOffset

对于同一方向,小区PRB利用率状态判决的顺序依次为:GBR业务、Non-GBR业务、Total业务。上下行独立判决,互不影响。负载均衡触发类型为判决满足负载平衡触发条件的PRB利用率类型,负载平衡触发方向为判决满足负载平衡触发条件的上行/下行方向。

若连续5秒内满足以下任一条件,则停止异频PRB利用率负载均衡。

●小区所有PRB利用率类型<InterFreqMlbThd

●小区同步态用户数<MlbMinUeNumThd

2.1.2 基于同步态用户数的触发模式

启动基于同步态用户数的负载均衡后,eNodeB以每秒为周期测量小区同步态用户数。若连续5秒内小区同步态用户数≥InterFreqMlbUeNumThd+MlbUeNumOffset,则触发异频同步态用户数负载均衡。

若连续5秒内小区同步态用户数<InterFreqMlbUeNumThd,则停止异频同步态用户数负载平衡。

2.2 选择目标小区

触发负载均衡后,eNodeB从首个InterFreqLoadEvalPrd周期超时时刻起,从异频邻区列表中选择目标小区列表,执行负载均衡动作。如果没有选择到满足条件的邻区,则本次负载均衡不执行负载均衡工作。随后每隔InterFreqLoadEvalPrd周期重复执行算法流程,直至负载均衡停止。

2.2.1 确定候选邻区

首先,eNodeB根据参数MlbAlgoSwitch、OverlapInd和LoadBalanceNCellScope的配置情况,在异频邻区列表中按照如下原则筛选负载平衡邻区选择范围。

●如果异频邻区中存在重叠覆盖邻区(即OverlapInd配置为“YES(是)”的邻区),邻区

选择范围如下表所示。

●如果异频邻区中不存在重叠覆盖邻区,邻区选择范围如下表所示。

在确定邻区选择范围后,eNodeB筛选同时满足如下条件地小区作为候选邻区:

●处于激活态的小区。

●未被列入黑名单的小区。

●与其邻区不存在PCI冲突的小区。

●如果可以获取到小区节能状态,则要求为不处于节能(载频智能关断、异系统小区关断、

低功耗)状态的小区。

●参数NoHoFlag设置为“PERMIT_HO_ENUM(允许切换)”的小区。

●参数MlbTargetInd配置为“ALLOWED(允许)”的邻频对应的小区。

2.2.2 负载信息交互

如果勾选了参数MlbAlgoSwitch的“InterFreqMlbSwitch(异频负载均衡开关)”选项,当触发负载平衡时启动负载信息交互,当停止负载平衡时停止负载信息交互。对于站内邻区,服务小区从所属eNodeB直接获取邻区的PRB利用率、同步态用户数、传输资源和硬件资源负载信息,无需通过X2接口交互获取;对于站间邻区,服务小区所属eNodeB将对候选邻区中配置了X2链路的异站邻区发起负载信息交互流程,邻区所属基站按照请求消息指示的交互周期回复PRB利用率、同步态用户数、传输资源和硬件资源负载信息。具体介绍可参考发布于2012年3月的R10版本3GPP TS36.423的8.3.6章节。

2.2.3 识别交互邻区和盲邻区

候选邻区中,能获取到其负载信息的小区即为交互邻区。如连续6个交互周期都没有收到某邻区回复负载信息,则该小区将不再为交互邻区。候选邻区中,不为交互邻区的小区均为盲邻区。

以下针对不同MlbAlgoSwitch配置下,eNodeB根据服务小区是否发起负载信息交互、邻区响应负载信息交互情况识别交互邻区和盲邻区进行说明。

●如果勾选了参数MlbAlgoSwitch的“InterFreqMlbSwitch(异频负载均衡开关)”选项,

eNodeB根据下表识别交互邻区和盲邻区。

●如果没有勾选参数MlbAlgoSwitch的“InterFreqMlbSwitch(异频负载平衡开关)”选

项,但勾选了“InterFreqBlindMlbSwitch(盲负载均衡开关)”选项,eNodeB根据下表识别交互邻区和盲邻区。

2.2.4 确定目标小区列表

确定目标小区列表时,首先在候选邻区中的交互邻区和盲邻区按照不同条件筛选小区;

然后,在筛选出来的小区中根据FreqSelectStrategy的配置选择满足频点要求的小区,形成当前执行周期的目标小区列表。

1.根据参数MlbAlgoSwitch配置,对候选邻区中的交互邻区和盲邻区按照不同的条件进行

筛选。

交互邻区需同时满足如下条件:

●PRB利用率、硬件负载和传输负载等负载信息无缺失而且为有效值的小区。

●硬件负载为LowLoad或者MediumLoad的小区。

●传输负载为LowLoad或者MediumLoad的小区。

●与服务小区历史切换性能较好(切换成功率高于98%)的小区。

●当触发类型是GBR业务类型时,服务小区与邻区的GBR业务PRB利用率差值大于

LoadDiffThd的小区;当触发类型是Non-GBR业务类型或Total业务类型时,服务小区与邻区的Total业务PRB利用率差值大于LoadDiffThd的小区。

●当MlbTriggerMode设置为“PRB_OR_UE_NUMBER(PRB模式或用户数模式触发)”时,邻

区InterFreqMlbUeNumThd邻区同步态用户数>0的小区。

2.根据FreqSelectStrategy的配置情况,确定目标小区的频点的条件:

●如果FreqSelectStrategy配置为“FAIRSTRATEGY(公平选择策略)”,在进行异频负载

平衡时,从所有异频频点中随机选择一个频点作为目标小区的频点。

●如果FreqSelectStrategy配置为“PRIORITYBASED(根据MLB频点优先级选择)”,在进

行异频负载平衡时,按照MlbFreqPriority配置值顺序,从高到低选择最高的优先级,其对应频点(一个或者多个)作为目标频点。如果当前周期没有UE成功转移至选择的频点,则该频点将会被惩罚,后续的2分钟内不允许再作为目标频点。

2.3负载均衡执行

2.3.1UE选择

eNodeB在服务小区选择同时满足以下条件的UE进行负载均衡转移。

●如果UE配置了SPID,UE的SPID值对应的InterFreqMlbSwitch配置为“TRUE(是)”。

●UE不处于CA状态。

●UE的PRB利用率同时满足以下条件:

?对于本次负载平衡触发方向上,当触发类型是GBR业务类型时,UE的GBR业务的PRB利用率>MlbUeSelectPrbThd;当触发类型是Non-GBR业务类型或

Total业务类型时,UE的Non-GBR业务的PBR利用率>MlbUeSelectPrbThd。

?对于本次负载平衡触发方向上,当触发类型是GBR业务类型时,所有转移出的UE的GBR业务的PRB利用率总和处于一个上限以下;当触发类型是Non-GBR

业务类型或Total业务类型时,所有转移出的UE的Non-GBR业务的PRB利用

率总和处于一个上限以下。以上两个上限均由本区和邻区的PRB利用率、本

区和邻区的RB资源数以及参数InterFreqMlbThd、LoadDiffThd、LoadOffset

和LoadTransferFactor决定。

?对于非本次负载平衡触发方向上,当触发类型是GBR业务类型时,UE的GBR 业务的PRB利用率≤MlbUeSelectPrbThd;当触发类型是Non-GBR业务类型或

Total业务类型时,UE的Non-GBR业务的PRB利用率≤MlbUeSelectPrbThd。

●UE不处于惩罚状态。

每InterFreqLoadEvalPrd周期内转移的最大UE个数不能超过MlbMaxUeNum。如果本次负载平衡中服务小区所有UE都不满足条件,则不执行本次负载平衡动作。

2.3.2负载转移

根据参数MlbHoMode配置和UE能力信息,eNodeB通过基于测量的切换、盲切换、基于测量的重定向或盲重定向将选择的UE转移到目标小区。

基于测量的切换

如果UE支持测量目标小区的频点,则eNodeB下发测量控制让其执行EventA4异频测量,同时启动3秒定时器。在定时器超时前,根据UE上报的测量结果,指示满足条件的UE启动切换。切换目标为目标邻区列表中UE测量到满足EventA4门限且信号最强的邻区。定时器超时后,对UE下发删除EventA4测量控制。

2.3.3 目标小区接纳判断

当收到的切换请求消息携带的负载平衡切换原因为Reduce load in serving cell时,目标小区不做接纳判断,按照正常切换流程处理。

当收到的切换请求消息携带的负载平衡切换原因为Resource Optimisation Handover 时,如果目标小区PRB利用率处于潜在高载状态或者负载平衡触发状态,则目标小区回复切换拒绝响应消息HANDOVER PREPARATION FAILURE,否则按照正常切换流程处理。

三、相关信令分析

3.1 负载消息交互信令

3.2 确定目标邻区的规则

步骤:1、确定候选邻区:MlbAlgoSwitch、overlapInd、LoadBalanceNcellscope;

2、负载信息交互;

3、识别交互邻区和盲邻区:MlbAlgoswitch;

4、确定目标小区列表:MlbAlgoswicth、Freqselectstrategy(转移同步态用户)、IdleUeSelFreqScope(转移空闲态用户);

3.2.1 讨论是否设置存在重叠覆盖邻区overlapInd小区(即将相关邻区配置为OverlapInd)的区别;

3.2.2 讨论将LoadBalanceNcellscope设置为ADAPTIVE(自适应选择负载均衡邻区)或

ALL(全部邻区)的区别;

此时服务小区频率37900,邻频38098(共站)、39050、38400。

当设置为ADAPTIVE时当设置为LoadBalanceNcellscope时

当设置为ADAPTIVE时,但同站邻频(38098)的MlbTargetInd设置为不允许。

结论:当LoadBalanceNcellscope设置为ADAPTIVE时,优先选择同站邻区。如果同站邻区不存在或者不可用,则选择配置了X2链路的异站邻区;当LoadBalanceNcellscope设置为all时,同站邻区和配置了X2链路的异站邻区。当配置A4后,UE开始测量3S,如无合适的小区,则删除A4事件。

建议设置:ADAPTIVE,并根据现网情况,将不希望的频点设置为MlbTargetInd设置为不允许。

3.2.3 讨论FreqSelectStrategy设置为FAIRSTRATEGY(公平选择策略)或PRIORITYBASED(根据MLB频点优先级选择)的区别

两个频点的MLB频点优先级均为7时38098优先级改为7,其余邻频的优先级6;

结论:当如果FreqSelectStrategy配置为“PRIORITYBASED(根据MLB频点优先级选择)”,在进行异频负载平衡时,按照MlbFreqPriority配置值顺序,从高到低选择最高的优先级,其对应频点(一个或者多个)作为目标频点。

建议设置:现网按照FAIRSTRATEGY进行设置,可保证参与负载均衡的各频点负载公平;如

场景需要将负载定向平衡至特定频点是可采用PRIORITYBASED设置。

3.3 负载平衡均衡执行

当选择转移连接态UE时,现网采用切换的方式。

当选择转移空闲态UE时,现网采用RRC connection release方式进行均衡。

将所选邻区参数LoadBalanceNCellScope取值为ALL,将IdleUeSelFreqScope设置为负载信息频点(默认设置),观察下发频点优先级。

LTE频点优先级关系:将所选邻区参数LoadBalanceNCellScope取值为ADAPTIVE,将IdleUeSelFreqScope设置为负载信息频点,并修改负载频点(38098)重选优先级为5,观察下发频点优先级。

结论:LTE频点专有频点优先级如下

推荐设置:

几种负载均衡算法

几种负载均衡算法 本地流量管理技术主要有以下几种负载均衡算法: 静态负载均衡算法包括:轮询,比率,优先权 动态负载均衡算法包括: 最少连接数,最快响应速度,观察方法,预测法,动态性能分配,动态服务器补充,服务质量,服务类型,规则模式。 静态负载均衡算法 ◆轮询(Round Robin):顺序循环将请求一次顺序循环地连接每个服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从顺序循环队列中拿出,不参加下一次的轮询,直到其恢复正常。 ◆比率(Ratio):给每个服务器分配一个加权值为比例,根椐这个比例,把用户的请求分配到每个服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配, 直到其恢复正常。 ◆优先权(Priority):给所有服务器分组,给每个组定义优先权,BIG-IP 用户的请求,分配给优先级最高的服务器组(在同一组内,采用轮询或比率算法,分配用户的请求);当最高优先级中所有服务器出现故障,BIG-IP 才将请求送给次优先级的服务器组。这种方式,实际为用户提供一种热备份的方式。 动态负载均衡算法 ◆最少的连接方式(Least Connection):传递新的连接给那些进行最少连接处理的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配, 直到其恢复正常。 ◆最快模式(Fastest):传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP 就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。 ◆观察模式(Observed):连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障,BIG-IP就把其从服务器队列中拿出,不参加下一次的用户请求的分配,直到其恢复正常。 ◆预测模式(Predictive):BIG-IP利用收集到的服务器当前的性能指标,进行预测分析,选择一台服务器在下一个时间片内,其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测) ◆动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数,动态调整流量分配。 ◆动态服务器补充(Dynamic Server Act.):当主服务器群中因故障导致数量减少时,动态地将备份服务器补充至主服务器群。 ◆服务质量(QoS):按不同的优先级对数据流进行分配。 ◆服务类型(ToS): 按不同的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。 ◆规则模式:针对不同的数据流设置导向规则,用户可自行。 负载均衡对应本地的应用交换,大家可以通过对上述负载均衡算法的理解,结合实际的需求来采用合适你的负载均衡算法,我们常用到的一般是最少连接数、最快反应、或者轮询,决定选用那种算法,主要还是要结合实际的需求。

广域网负载均衡原理简单介绍

广域网负载均衡 多链路广域网负载均衡 (1)Inbound多链路负载均衡算法策略:RTT+Topology+RoundRobin 具体描述: 当外部用户访问九州梦网网站时,首先由F5的3DNS对客户端的LDNS进行RTT(Round Trip Time)探测,对比从两条链路返回的探测结果(可以从统计列表中看到),选择一条返回值小的链路IP地址返回给客户端,从而客户端再发起访问请求;当F5的3DNS探测不到客户端的LDNS(由于LDNS安全防护等原因)时,F5的3DNS自动启用Topology算法,来静态匹配客户端的LDNS地理位置,从而根据客户端的来源,返回正确的A记录;当探测不到的LDNS又不在地址列表中时,F5 3DNS自动启用Global Availability 算法作为默认算法,将所有无法计算结果并且不在Topology范围之内的LocalDNS请求,定义到系统的默认线路上。 F5 的3DNS具备二十多种Inbound算法,可以根据需要进行组合。 ①RTT算法运行机制: 通过3DNS的RTT就近性算法会自动运算生成一个ldns就近分布表,通过这个动态的表,每个客户上来都会提供一个最快速的链路进行访问,由于站点有ISP1和ISP2的两条广域网线路。在3DNS上会针对站点服务器(以https://www.360docs.net/doc/b96690351.html, 为例)解析ISP1和ISP2的两个不同的公网地址。 对应于https://www.360docs.net/doc/b96690351.html,域名,在3DNS上配置wideip:https://www.360docs.net/doc/b96690351.html,,对应两个Virtual Server:VS1:202.106.83.177,VS2:219.17.66.100。分别属于ISP1和ISP2两条线路分配的IP地址段。在3DNS内部,同时定义两个DataCenter分别与ISP1和ISP2相对应。 用户的访问流程如下:

负载均衡调度算法

负载调度算法 负载均衡(Load Balance),又称为负载分担,就是将负载(工作任务)进行平衡、分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。负载均衡建立在现有网络结构之上,它提供了一种廉价又有效的方法来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 在调度器的实现技术中,IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器,称之为VS/NAT技术。在分析VS/NAT 的缺点和网络服务的非对称性的基础上,提出通过IP隧道实现虚拟服务器的方法VS/TUN,和通过直接路由实现虚拟服务器的方法VS/DR,它们可以极大地提高系统的伸缩性。 在内核中的连接调度算法上,IPVS实现了以下几种调度算法: 1 轮叫调度 1.1 轮叫调度含义 轮叫调度(Round Robin Scheduling)算法就是以轮叫的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。 轮叫是基站为终端分配带宽的一种处理流程,这种分配可以是针对单个终端或是一组终端的。为单个终端和一组终端连接分配带宽,实际上是定义带宽请求竞争机制,这种分配不是使用一个单独的消息,而是上行链路映射消息中包含的一系列分配机制。 1.2 轮叫调度算法流程 轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器,从1开始,直到N(内部服务器个数),然后重新开始循环。在系统实现时,我们引入了一个额外条件,即当服务器的权值为零时,表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务(如屏蔽服务器故障和系统维护),同时与其他加权算法保持一致。所以,算法要作相应的改动,它的算法流程如下:假设有一组服务器S = {S0, S1, …, Sn-1},一个指示变量i表示上一次选择的服务器,W(Si)表示服务器Si的权值。变量i被初始化为n-1,其中n > 0。 j = i; do { j = (j + 1) mod n;

主流BI产品对比

国际主流BI产品对比

厂商产品及简介 国际厂商(主要) MicroStrategy MSTR ,国际专业BI 产品,覆盖BI 全部领域 IBM DB2以及Cognos 、SPSS 、DataStage ,覆盖BI 全部领域Oracle BIEE 、Hyperion ,覆盖BI 全部领域,数据挖掘领域有待加强 Microsoft SQLServer ,覆盖BI 全部领域,适合中小型企业,性价比高 SAP BusinessObjects 、CrystalReports 主要是报表领域和数据集成领域 国际BI 市场主要厂商

BI 产品纷纷嫁入豪门: 2007年11月,IBM收购Cognos 2008年4月,Oracle收购Hyperion 2010年10月,SAP收购Business Objects BI 产品国际阵营谁是幸存者: 目前BI产品第一阵营的唯一幸存者只有MicroStrategy,超过20年的专业技术和市场积累,让这个在巨头环伺下的BI行业领军产品一直保持着一枝独秀的良好态势。

厂商名称目标客户群 MicroStrategy金融、电信、政府、石油、电力等高端行业的高端应用,尤 其适合于数据量大,用户分布广泛的行业应用特点 SAP/BO BO定位于SAP ERP的已有用户优先实施,其它则通过OEM或 各种集成商,价格较高,不适用于中小企业 IBM/Cognos通过OEM和集成商进军企业客户,公司本身则注重已有的金 融、电信、政务领域客户 Microsoft适用于中小企业,依靠合作伙伴 Oracle基于Oracle数据库庞大的客户群,注重大型用户,但内部产 品有竞争关系 国际主流BI产品基本都已被IT业界巨头并购,技术路线及商务策略缺乏独立性,除MicroStrategy之外都缺乏BI产品技术发展方向的独立规划。

数据库负载均衡解决方案

双节点数据库负载均衡解决方案 问题的提出? 在SQL Server数据库平台上,企业的数据库系统存在的形式主要有单机模式和集群模式(为了保证数据库的可用性或实现备份)如:失败转移集群(MSCS)、镜像(Mirror)、第三方的高可用(HA)集群或备份软件等。伴随着企业的发展,企业的数据量和访问量也会迅猛增加,此时数据库就会面临很大的负载和压力,意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗?SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术,属于高可用集群,Microsoft称之为失败转移集群。 MSCS 从硬件连接上看,很像Oracle的RAC,两个节点,通过网络连接,共享磁盘;事实上SQL Server 数据库只运行在一个节点上,当出现故障时,另一个节点只是作为这个节点的备份; 因为始终只有一个节点在运行,在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点,目的是为了提高可用性,和MSCS相比,用户实现数据库的高可用更容易了,不需要共享磁盘柜,也不受地域的限制。共设了三个服务器,第一是工作数据库(Principal Datebase),第二个是镜像数据库(Mirror),第三个是监视服务器(Witness Server,在可用性方面有了一些保证,但仍然是单服务器工作;在扩展和性能的提升上依旧没有什么帮助。

F5负载均衡双机热备实施方案

F5双机热备实施说明 2012/12/4

一、项目拓扑图及说明 两台F5负载均衡设备采用旁挂的方式连接至交换机,设备地址和虚拟地址在服务器的内网地址段中划分;使用F5为认证应用服务器进行流量负载均衡。 二、设备信息及IP分配表 F5:型号BIG-IP LTM 1600 软件版本:V10.2.4 对外地址对外端口内网地址内网端口协议设备名备注 192.168.100.21 https://www.360docs.net/doc/b96690351.html, F5-1IP地址 192.168.100.22 https://www.360docs.net/doc/b96690351.html, F5-2IP地址 192.168.100.23 F5浮动地址 10.168.100.21 F5-1数据同步 10.168.100.22 F5-2数据同步 192.168.100.150 80 192.168.100.4 80 TCP 认证服务器1 192.168.100.5 80 TCP 认证服务器2 三、实施步骤及时间

3.1、F5设备加电测试 3.2、配置F5及F5双机,需2.5小时 3.3、测试F5双机切换,需0.5小时,这部分作为割接准备工作。3.4、先添加认证服务器单节点到F5设备192.168.100.150的虚拟服务中,在内网测试应用,需0.5小时 3.5、将应用服务器从双机模式更改为集群模式,将认证服务器两个节点添加到F5设备,这个时间取决于服务器模式更改的时间。 3.6、在防火墙上更改认证服务器的映射地址,将原来的地址更改为F5设备上的虚拟服务IP地址192.168.100.150 ,TCP 协议80端口。 四、回退方法 在外部网络不能访问认证服务时,回退的方法是在防火墙上把F5设备虚拟服务器192.168.100.150地址映射,更改为原单台认证服务器IP地址,将认证服务器集群模式退回双机模式。 五、F5设备配置步骤 5.1、设置负载均衡器管理网口地址 F5 BIG-IP 1600 设备的面板结构: BIG-IP 1600应用交换机具备四个10/100/1000M自适应的网络接口及二个光纤接口. 10/100/1000 interface — 4个10/100/1000 M 自适应的网络接口 Gigabit fiber interface — 2个1000M 多模光纤接口

思科负载均衡产品介绍-Introduction to Load Balancing

Introduction to Load Balancing
BRKAPP-1001
BRKAPP-1001 14503_04_2008_c2
? 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
2
? 2006, Cisco Systems, Inc. All rights reserved. 14503_04_2008_c2.scr
1

Agenda
Introduction Load Balancing and Health Monitoring Flow Management Server Offload High Availability Deployments Geographic Load Balancing What’s Next ?
BRKAPP-1001 14503_04_2008_c2
? 2008 Cisco Systems, Inc. All rights reserved.
Cisco Public
3
Cisco Application Delivery Networks
Network Classification
Quality of service Network-based app recognition Queuing, policing, shaping Visibility, monitoring, control
Application Scalability
Server load-balancing Site selection SSL termination and offload Video delivery
Application Networking
Message transformation Protocol transformation Message-based security Application visibility
WAN
Application Acceleration
Latency mitigation Application data cache Meta data cache Local services
BRKAPP-1001 14503_04_2008_c2 ? 2008 Cisco Systems, Inc. All rights reserved.
WAN Acceleration
Data redundancy elimination Window scaling LZ compression Adaptive congestion avoidance
Cisco Public
Application Optimization
Delta encoding FlashForward optimization Application security Server offload
4
? 2006, Cisco Systems, Inc. All rights reserved. 14503_04_2008_c2.scr
2

天融信负载均衡算法

1.Rr – Round Robin 默认情况下,访问请求分配的次序为: 1, 2, 3, 4, 1, 2, 3,4 若Servers之间存在性能差异,可以通过调整分配粒度值(weight),来控制访问请求分配的次序: 1, 1, 1, 2, 2, 2, 3, 3, 3,4,4,4, 2.Lc - Least Connections 新的访问请求将分配至当前连接数最少的一台服务器上。分配粒度方法定义了两个服务器的活动连接数要有多大差别,算法里才会将它们区分为不同等级。3.Sr – Shortest Response Time 基于后台服务器的最短相应时间来分配新的访问请求。 4.Pi – Persistent IP 相同IP地址的请求将会分配到相同的服务器上 5.HI - Hash IP 这是一种基于源IP地址Hash来分发新建连接的算法。客户端发送一个请求到虚拟服务器;负载均衡设备将根据源IP地址计算出的哈希值来选择将该访问请求发送到哪一台服务器;对于哈希值相同的请求连接,都将会发送到相同的服务器上。 注意:如果一台服务器失效了,将导致负载均衡设备上的哈希值重新计算,这样对所有原已维持的会话状态都将产生影响。 在负载均衡集群的方式下,客户端到服务器端的对应关系,在其他负载均衡设备上无法维持的,因此当其中一台负载均衡设备失效以后,客户端的请求将会在其他正常的负载均衡重新进行负载分配。 6.CHI – Consistent Hash IP 这是一种基于源IP地址Hash来分发新建连接的算法。 客户端发送一个请求到虚拟服务器;负载均衡设备将根据源IP地址计算出的哈希值来选择将该访问请求发送到哪一台服务器;对于哈希值相同的请求连接,都将会发送到相同的服务器上。 注意:

Radware负载均衡解决实施方案

Radware负载均衡解决实施方案

————————————————————————————————作者:————————————————————————————————日期:

Radware WSD 服务器负载均衡解决方案

1.1 WSD ―服务器负载均衡 1.1.1Radware 网络应用系统负载均衡的基本工作原理 Radware的WSD通过对于数据包的4-7层信息的检查来进行负载均衡的判断,服务器负载均衡是最普遍的一种4-7层交换的例子,下面我们就以服务器负载均衡的整个流程来介绍Radware WSD的工作原理: 1.1.1.1 会话“session”。 请看下面会话的例子: 为了识别会话,客户机和服务器都使用TCP“埠”。客户机和服务器之间的TCP会话由四个参数定义:客户机IP地址、客户机TCP端口、服务器IP地址和服务器TCP端口。所以,如果IP地址为199.1.1.1的客户机使用TCP端口1234与IP地址为145.145.100.100的服务器(TCP埠80)建立会话,则该会话定义如下: (clntIP,clntPORT,srvrIP,crvrPORT )= (199.1.1.1,1234,145.145.100.100,80) 1.1.1.2 服务器负载均衡 假设图1中所示的样例,客户机通过访问服务器负载均衡设备WSD的虚拟地址145.1.1.1 进行HTTP应用的访问。再假设选择服务器145.145.100.100响应此客户机,则客户表的记录如下所示:

如果启用此记录,WSD 会执行以下两个任务: 1. 所有从客户机199.1.1.1发送到服务器群145.145.1.1且目标TCP 端口为80的数据包将被发送到服务器145.145.100.100。 2. 所有从服务器145.145.100.100发送到客户机199.1.1.1且源TCP 端口为80的数据包将被改为源地址145.145.1.1发送出去。 即:对于用户199.1.1.1 来说,145.145.1.1 是他要访问的服务器IP 地址,当WSD(145.145.1.1),收到用户请求后,会根据后面2台服务器的“健康状况”和负载均衡算法将用户的请求转发到某一台服务器145.145.100.100 1.1.1.3 健康检查 由于负载均衡设备同应用的关系比较紧密,所以需要对负载均衡的元素进行“健康”检查,如果负载均衡设备不能在应用进行健康检查,就无法做到对应用的高可靠性的保障。 Radware 的高级健康检查模块,可以准确的做到应用层的健康检查。这种新的模块与流量复位向模块紧密相连, 可以提前检验所有应用和网络部件的可用

负载均衡的基础原理说明

大家都知道一台服务器的处理能力,主要受限于服务器自身的可扩展硬件能力。所以,在需要处理大量用户请求的时候,通常都会引入负载均衡器,将多台普通服务器组成一个系统,来完成高并发的请求处理任务。 之前负载均衡只能通过DNS来实现,1996年之后,出现了新的网络负载均衡技术。通过设置虚拟服务地址(IP),将位于同一地域(Region)的多台服务器虚拟成一个高性能、高可用的应用服务池;再根据应用指定的方式,将来自客户端的网络请求分发到

服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态,自动隔离异常状态的后端服务器,从而解决了单台后端服务器的单点问题,同时提高了应用的整体服务能力。 网络负载均衡主要有硬件与软件两种实现方式,主流负载均衡解决方案中,硬件厂商以F5为代表目前市场占有率超过50%,软件主要为NGINX与LVS。但是,无论硬件或软件实现,都逃不出基于四层交互技术的“转发”或基于七层协议的“代理”这两种方式。四层的转发模式通常性能会更好,但七层的代理模式可以根据更多的信息做到更智能地分发流量。一般大规模应用中,这两种方式会同时存在。 2007年F5提出了ADC(Application delivery controller)的概念为传统的负载均衡器增加了大量的功能,常用的有:SSL卸载、压缩优化和TCP连接优化。NGINX也支持很多ADC的特性,但F5的中高端型号会通过硬件加速卡来实现SSL卸载、压缩优化这一类CPU密集型的操作,从而可以提供更好的性能。 F5推出ADC以后,各种各样的功能有很多,但其实我们最常用的也就几种。这里我也简单的总结了一下,并和LVS、Nginx对比了一下。

F5负载均衡算法详解

应用交换技术的负载均衡算法 应用交换技术里主要包括四项关键的技术: ●截获和检查流量 ●服务器监控健康检查 ●负载均衡算法 ●会话保持 截获和检查流量保证只有合适的数据包才能通过; 服务器监控和健康检查随时了解服务器群的可用性状态; 负载均衡和应用交换功能通过各种策略导向到合适的服务器; 会话的保持以实现与应用系统完美结合; F5在应用交换技术中的优势: A、截获和检查流量 –BIG-IP 有最强的数据包截获和检查引擎去检查任何数据流量包中的任何部分,可以检测16384bytes包的深度,理论上可以检测 64Kbytes的包长度 –这使得BIG-IP 明显有别于其他的厂商的产品 B、用于定制控制的iRules工具 –可用来定义如何根据报头和/或TCP有效负载信息来引导、保存和过滤流量。 –iRules增强了企业或服务提供商定根据业务需求定制应用流量的能力。 –通用检查引擎和iRules分别是应用智能和业务决策来进行应用流量管理的方法和工具。 C、服务器监控和健康检查

–服务器(Node)-Ping(ICMP) –服务(Port)-Connect –扩展的应用验证(EA V) –扩展的内容验证(ECV) –针对VOD服务器的专用健康检查机制 –针对节点的检查频率和超时频度,e.g.10seconds响应,e.g.5seconds D、负载均衡和应用交换功能 –Global Load Balancer提供17种负载均衡算法 –F5提供最优质的负载均衡和应用交换功能 静态算法 动态算法 智能算法 I –control UIE + Irules –Local Load Balancer提供12种负载均衡算法 E、持续功能 –连续性与负载平衡是相互对立的,但它对于负载平衡又是必不可少的! –简单的连续性—基于源地址 –HTTP Cookie 连续性 –SSL Session ID 连续性 –目的地址的亲合作用--caches –standby BIG-IP实现对连续性记录的镜像 –智能与第七层的内容交换组合 F5做为应用交换领域的领导厂商,一直保持着技术上的领先地位,F5已经有40多项技术申请了专利,其它的竞争合作伙伴都在购买F5的这些专利技术。接下来我们讨论一下负载均衡算法。

负载均衡解决方案设计设计

一、用户需求 本案例公司中现有数量较多的服务器群: WEB网站服务器 4台 邮件服务器 2台 虚拟主机服务器 10台 应用服务器 2台 数据库 2台(双机+盘阵) 希望通过服务器负载均衡设备实现各服务器群的流量动态负载均衡,并互为冗余备份。并要求新系统应有一定的扩展性,如数据访问量继续增大,可再添加新的服务器加入负载均衡系统。 二、需求分析 我们对用户的需求可分如下几点分析和考虑: 1.新系统能动态分配各服务器之间的访问流量;同时能互为冗余,当其中 一台服务器发生故障时,其余服务器能即时替代工作,保证系统访问的 不中断; 2.新系统应能管理不同应用的带宽,如优先保证某些重要应用的带宽要 求,同时限定某些不必要应用的带宽,合理高效地利用现有资源;

3.新系统应能对高层应用提供安全保证,在路由器和防火墙基础上提供了 更进一步的防线; 4.新系统应具备较强的扩展性。 o容量上:如数据访问量继续增大,可再添加新的服务器加入系统; o应用上:如当数据访问量增大到防火墙成为瓶颈时,防火墙的动态负载均衡方案,又如针对链路提出新要求时关于Internet访问 链路的动态负载均衡方案等。 三、解决方案 梭子鱼安全负载均衡方案总体设计 采用服务器负载均衡设备提供本地的服务器群负载均衡和容错,适用于处在同一个局域网上的服务器群。服务器负载均衡设备带给我们的最主要功能是:

当一台服务器配置到不同的服务器群(Farm)上,就能同时提供多个不同的应用。可以对于每个服务器群设定一个IP地址,或者利用服务器负载均衡设备的多TCP端口配置特性,配置超级服务器群(SuperFarm),统一提供各种应用服务。

负载均衡技术的三种实现方法

目前,网络应用正全面向纵深发展,企业上网和政府上网初见成效。随着网络技术的发展,教育信息网络和远程教学网络等也得到普及,各地都相继建起了教育信息网络,带动了网络应用的发展。 一个面向社会的网站,尤其是金融、电信、教育和零售等方面的网站,每天上网的用户不计其数,并且可能都同时并发访问同一个服务器或同一个文件,这样就很容易产生信息传输阻塞现象;加上Internet线路的质量问题,也容易引起出 现数据堵塞的现象,使得人们不得不花很长时间去访问一个站点,还可能屡次看到某个站点“服务器太忙”,或频繁遭遇系统故障。因此,如何优化信息系统的性能,以提高整个信息系统的处理能力是人们普遍关心的问题。 一、负载均衡技术的引入 信息系统的各个核心部分随着业务量的提高、访问量和数据流量的快速增长,其处理能力和计算强度也相应增大,使得单一设备根本无法承担,必须采用多台服务器协同工作,提高计算机系统的处理能力和计算强度,以满足当前业务量的需求。而如何在完成同样功能的多个网络设备之间实现合理的业务量分配,使之不会出现一台设备过忙、而其他的设备却没有充分发挥处理能力的情况。要解决这一问题,可以采用负载均衡的方法。 负载均衡有两个方面的含义:首先,把大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间;其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,再返回给用户,使得信息系统处理能力可以得到大幅度提高。 对一个网络的负载均衡应用,可以从网络的不同层次入手,具体情况要看对网络瓶颈所在之处的具体情况进行分析。一般来说,企业信息系统的负载均衡大体上都从传输链路聚合、采用更高层网络交换技术和设置服务器集群策略三个角度实现。 二、链路聚合——低成本的解决方案 为了支持与日俱增的高带宽应用,越来越多的PC机使用更加快速的方法连入网络。而网络中的业务量分布是不平衡的,一般表现为网络核心的业务量高,而边缘比较低,关键部门的业务量高,而普通部门低。伴随计算机处理能力的大幅度提高,人们对工作组局域网的处理能力有了更高的要求。当企业内部对高带宽应用需求不断增大时(例如Web访问、文档传输及内部网连接),局域网核心部位的数据接口将产生瓶颈问题,因此延长了客户应用请求的响应时间。并且局域网具有分散特性,网络本身并没有针对服务器的保护措施,一个无意的动作,像不小心踢掉网线的插头,就会让服务器与网络断开。 通常,解决瓶颈问题采用的对策是提高服务器链路的容量,使其满足目前的需求。例如可以由快速以太网升级到千兆以太网。对于大型网络来说,采用网络系统升级技术是一种长远的、有前景的解决方案。然而对于许多企业,当需求还没有大到非得花费大量的金钱和时间进行升级时,使用升级的解决方案就显得有些浪费

几种负载均衡策略比较~

PS:Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,参考了一些资料,结合自己的一些使用经验,总结一下。 一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析,如果是中小型的Web应用,比如日PV小于1000万,用Nginx就完全可以了;如果机器不少,可以用DNS轮询,LVS所耗费的机器还是比较多的;大型网站或重要的服务,且服务器比较多时,可以考虑用LVS。一种是通过硬件来进行进行,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,所以对于规模较小的网络服务来说暂时还没有需要使用;另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,所以费用非常低廉。 目前关于网站架构一般比较合理流行的架构方案:Web前端采用 Nginx/HAProxy+Keepalived作负载均衡器;后端采用MySQL数据库一主多从和读写分离,采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。 下面说说各自的特点和适用场合。 一、Nginx Nginx的优点是: 1、工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构,它的正则规则比HAProxy更为强大和灵活,这也是它目前广泛流行的主要原因之一,Nginx单凭这点可利用的场合就远多于LVS了。 2、Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势之一;相反LVS对网络稳定性依赖比较大,这点本人深有体会; 3、Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了,LVS对网络依赖比较大。 3、可以承担高负载压力且稳定,在硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS相对小些。 4、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。 5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构,在高流量的环境中稳定性也很好。 6、Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,可以考虑用其作为反向代理加速器。 7、Nginx可作为中层反向代理使用,这一层面Nginx基本上无对手,唯一可以对比

架构设计:负载均衡层设计方案(7)

架构设计:负载均衡层设计方案(7) 1、概述 上篇文章《架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层》 (https://www.360docs.net/doc/b96690351.html,/yinwenjie/article/details/47130609) 我们讲解了Nginx的故障切换,并且承诺各位读者会尽快讲解LVS + Keepalived + Nginx的安装和配置。在中间由于工作的原因,我又插写了三篇关于zookeeper的原理使用的文章。今天这边文章我们回归主题,为各位读者讲解LVS + Keepalived + Nginx的安装及配置。 2、安装计划和准备工作 下图,我们表示了本篇文章要搭建的整个集成架构的抽象结构: 我们采用两个LVS节点(141和142),但是一个时间工作的只有一个LVS节点,另一个始终处于热备standby状态,由keepalived监控这两个节点的工作状态并完成切换。 在LVS节点下,我们采用LVS-DR工作模式挂载了两个Nginx节点(131、132)。并最终将外网请求交由这两个节点进行处理。注意:在实际工作中,Nginx下面一般就是访问静态资源、动态资源的配置了。

2-1、准备两个keepalived节点 首先我们在将要安装LVS的两个节点上,先安装keepalived,并保证这两个keepalived节点能够正常工作(监控批次的状态)。当然,您也可以先准备LVS,在准备keepalived。 我想准备keepalived节点,大家应该轻车熟路了吧,在《架构设计:负载均衡层设计方案(6)——Nginx + Keepalived 构建高可用的负载层》这篇文章中详细介绍了keepalived的最简配置方式。为了大家阅读方便,我们在这里再进行依次简要说明。准备keepalived的整个过程包括: 安装必要的支撑组件,源码安装keepalived 将keepalived注册成节点的服务,以便保证keepalived在 节点启动时就开始工作 更改keepalived的配置文件,让其可以正常工作 验证准备工作 =============安装keepalived [root@lvs1 ~]# yum install -y zlib zlib-devel gcc gcc-c++ openssl openssl-devel openssh [root@lvs1 ~]# tar -zxvf keepalived-1.2.17.tar.gz [root@lvs1 ~]# cd keepalived-1.2.17 [root@lvs1 ~]# ./configure --perfix=/usr/keepalived-1.2.17

静态负载均衡算法的简单说明

静态负载均衡算法的简单说明 实现的问题: 目前有N个资源Scale1~ScaleN,且这N个资源正在处理个数不等的请求,这时发来M个请求。 如何把M个请求分发到这N个资源中,使得分发完之后这N个资源所处理的请求是均衡的。 名词定义 Scale-资源 Order-请求 compId-每个资源的唯一标识 compId数组-compIdArr 根据每个Scale目前所处理的Order个数多少,从小到大把其对应的compId记录在数组中 负载分配数组-dispatchCountArr 对于dispatchCountArr[i],它的值表示的是可以分发的Order的个数, 分发的compId的范围是在compIdArr[0]到compIdArr[i]之间。 例,如果有3个Scale,它们的compId和当前的Order个数分别为 Scale1:1,Scale2:5,Scale3:12 那么根据这组数据可以构造一个负载分配数组 dispatchCountArr[0]=(5-1)*1=4 表示可以在Scale1上再分配4个Order dispatchCountArr[1]=(12-5)*2=14 表示可以在Scale1和Scale2上平均分配14个Order dispatchCountArr[2]=整型最大值表示可以在Scale1~Scale3上再平均分配任意个Order 当有多个Order订单,需要为每个都分配一个compId时, 1.先从dispatchCountArr[0]开始,如果dispatchCountArr[0]不为0,说明可以把这个订单指派给Scale1, 并且dispatchCountArr[0]的值减1; 2.如果发现dispatchCountArr[0]已经为0,则继续看dispatchCountArr[1], 如果大于0,说明可以再从Scale1和Scale2中取一个进行指派,用dispatchCountArr[1] mod 2产生一个0到1 的index,意思是在Scale1和Scale2之间进行平均分配,取compIdArr[index]作为分配的compId, 同时dispatchCountArr[1]减1 3.如果dispatchCountArr[1]也被减为0,那么继续看dispatchCountArr[2],类似2中的操作, 用dispatchCountArr[2] mod 3产生一个0到2的index,意思是在Scale1到Scale3

BO与Oracle BIEE产品对比 v1

第1章产品体系结构比较 第2章在企业关键BI需求上BO 与 OBIEE对比

第3章对比BO与Oracle BIEE的常见问题 1.OBIEE是一个统一的、完整的架构,还是一个将并购而来的多种工具耦合而成的平台? Oracle BIEE是ORACLE将多个收购而来的BI产品简单耦合而成的,作为企业级的BI平台显然它还不够 成熟。OBIEE拥有看似统一的多个用户界面、多个服务器和多个存储在平面文件中的元数据,这些缺点都极大的制约了它的可伸缩性。 OBIEE Plus所提供的BI功能需要三个独立的服务来支持。用户访问复杂报表的时候,查询的SQL不是由一个单独的集中的服务器产生的,而是需要两个服务通过两个步骤才能产生。首先ORACLE BI Presentation Services产生逻辑SQL,然后Oracle BI Server再将接收到的逻辑SQL转化为物理SQL。这两个步骤明显有 些冗余,直接降低了系统的性能,增大了系统故障的风险。 根据Gartner公司10年的报告,Oracle的对其BI产品和产品线的整合在近期还将继续。有强烈的证据 表明,Hyperion的原有用户都在等待和观望,并没有升级到最新版本。在所有的用户调查中,Hyperion用户运行最新版本的比率是最低的。而且报告中还专门提到,Oracle用户反映得到的技术支持不够完善,Oracle 在BIEE方面的一线技术专家还不够。 BO 产品是一个统一的、完整的架构,通过一个统一的门户向用户提供各种BI功能,整个系统采用统一的用户和权限管理。 2.OBIEE是否拥有统一的元数据? OBIEE 系统拥有三个不同版本的元数据: ●BI Server的元数据:存储逻辑数据模型 ●BI Presentation Services的元数据:主要存储 WEB目录信息,包括报表、筛选、提示和用户信息 ●BI Publisher的元数据:主要存储复杂的企业级报表及其他报表对象的信息。 这些元数据在不同的功能模块间是无法完全共享的。其中BI Server的元数据和BI Presentation Services的元数据只能保存在一个平面文件中,不能存储在关系型数据库中,从而没有负载均衡和数据回滚 的能力。 在集群的环境中,保存在平面文件中的元数据必须要通过共享文件系统才能同时被多台服务器所访问。 但共享文件系统是无法针对高并发量的访问进行系统调优的,另外平面文件本身也存在大小的限制,进而也限制了元数据的增长。 此外,集群环境中的ORACLE BI SERVER仅仅在重启的时候,才会加载存储在平面文件中的元数据。这意味着想要修改后元数据生效,管理员就必须要重启集群内的所有服务器。这样即使OBIEE在集群环境中也不可能提供7*24小时的高可靠性。 Oracle BI Publisher的元数据不能充分利用来自Oracle BI Server元数据业务逻辑模型。来自Oracle BI Answer的报表,不能被Oracle BI Publisher充分利用创建Publisher报表。在Oracle BI Answers中创建的包含提示的报表,也不能在Oracle BI Publisher中正常使用。Oracle BI Publisher报表不能在Oracle BI Presentation Services Web中被浏览,因为这两个系统的元数据库是完全独立的。 在OBIEE中报表中的提示是存储在报表级别的,这意味这用户创建了一个地区提示,这个提示不能被后来的报表所重用。用户必须为每一张需要相同提示的报表重新创建。这种缺乏元数据抽象的弱点,增加了额外的维护工作和重复的步骤。

小区负载均衡算法

小区负载均衡算法介绍 1、小区负载均衡算法配置(针对本小区与扩容小区之间) 小区负载均衡算法分为两类PRB利用率负载平衡算法和同步态用户负载均衡算法两种。其中:PRB利用率负载平衡算法用于解决在单个小区PRB利用率受限(达到或者接近满载),同时存在与之重叠覆盖的异频邻区相对低载,算法将一部分负载转移至邻区之后,达到整体PRB利用率之和最大化,从而吞吐率最大化;同步态用户数负载平衡算法用于解决在单个小区用户数受限(由于用户数过多导致整体UE 速率受限),同时存在与之重叠覆盖的异频邻区相对低载,算法将一部分负载转移至邻区之后,达到整体用户速率平均化,从而减少差性用户的比例。笼统地说,PRB利用率负载平衡算法主要用于选大包用户,同步态用户数负载平衡算法主要用于选小包用户。 因为现网用户分布符合类正态分布的特性,即小包用户出现概率大,大包用户出现概率小。所以在现网使用同步态用户负载均衡算法。 同步态用户负载均衡算法关键参数及配置方式如下: InterFreqMlbSwitch:负载均衡总开关,在CELLALGOSWITCH设置,是进行PRB利用率负载平衡算法和同步态用户负载均衡的总开关,打开此开关才可进行复杂均衡。MML:MOD CELLALGOSWITCH:LOCALCELLID=X,MLBALGOSWITCH=InterFreqMlbSwitch-1; MlbTriggerMode:异频负载平衡触发模式,当前算法支持两种模式,三种开启方案:单独打开PRB 负载模式(PRB_ONLY)、单独打开用户数模式(UE_NUMBER_ONLY)和支持两个模式同时打开(PRB_OR_UE_NUMBER),现网配置时使用用户数模式即可。MML:MOD CELLMLB:LOCALCELLID=X,MLBTRIGGERMODE=UE_NUMBER_ONLY; InterFreqUeTrsfType:异频负载均衡转移UE类型。决定转移连接态UE还是释放态UE,区分PRB模式下转移UE连接态还是空闲态,用户数模式下转移UE连接态还是空闲态,一共4个勾选项,可以独立或者同时配置。现网设置SynchronizedUE(同步态用户)、IdleUE(空闲态用户)打开,PrbMlbSynchronizedUE(PRB模式负载均衡同步态用户),异频空闲态小区PRB 利用率负载平衡算法PrbMlbIdleUE(PRB模式负载均衡空闲态用户)关闭即可。MML:MOD CELLMLB:LOCALCELLID=X,INTERFREQUETRSFTYPE=SynchronizedUE-1&IdleUE-1&PrbMlbSynchronizedUE-0&PrbMlbIdleUE-0; InterFreqMlbUeNumThd:异频负载均衡用户数门限;MlbUeNumOffset:负载均衡用户数偏置。算法高载触发门限,当算法未触发时如果小区同步态用户数大于等于InterFreqMlbUeNumThd + MlbUeNumOffset则触发异频连接态小区同步态用户数负载平衡算法,当算法触发时如果小区同步态用户数小于InterFreqMlbUeNumThd则退出算法。MlbUeNumOffset:负载均衡用户数偏置不需要进行配置,现网默认值20即可。InterFreqMlbUeNumThd异频负载均衡用户数门限设置为小区最大用户数的一半即可。MML:MOD CELLMLB:LOCALCELLID=X,INTERFREQMLBUENUMTHD=(最大用户数/2); InterFreqLoadEvalPrd:异频负载评估周期,控制算法运行时序,在算法触发之后,负载

相关文档
最新文档