CN104798356A - 用于控制水平扩展软件应用中的利用率的方法和装置 - Google Patents

用于控制水平扩展软件应用中的利用率的方法和装置 Download PDF

Info

Publication number
CN104798356A
CN104798356A CN201380060597.2A CN201380060597A CN104798356A CN 104798356 A CN104798356 A CN 104798356A CN 201380060597 A CN201380060597 A CN 201380060597A CN 104798356 A CN104798356 A CN 104798356A
Authority
CN
China
Prior art keywords
stream
application example
local
application
restriction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201380060597.2A
Other languages
English (en)
Other versions
CN104798356B (zh
Inventor
帕·卡尔森
米卡埃尔·卡尔松
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN104798356A publication Critical patent/CN104798356A/zh
Application granted granted Critical
Publication of CN104798356B publication Critical patent/CN104798356B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/20—Traffic policing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明包括用于水平扩展应用中的分布式业务控制的装置和方法，其中，基于软件的应用被实现为多个对等应用实例，每一个应用实例提供应用的总能力或容量的一部分。在每一个应用实例处实例化或以其他方式实现包括分布式业务控制器的装置，并且这些装置共同操作以根据例如服务水平协议或SLA限制各个客户端或附属客户端组对应用的总利用率，并且还操作以防止应用实例中的任意一个的不成比例利用率。有利地，根据本文的教导在分布式业务控制器之间使用有效信息传播协议来完成这些操作。

Description

用于控制水平扩展软件应用中的利用率的方法和装置
技术领域
本发明大体上涉及分布式处理，具体地，涉及水平扩展(horizontally scaled)处理系统。
背景技术
在本文设想的类型的水平扩展系统中，在多个对等应用实例中实现整个软件应用，每一个对等应用实例提供了应用的整个功能并且每一个对等应用实例表示总应用容量或性能能力的一部分。然而，用于管理来自客户端池的应用业务的现有解决方案基于通常对于水平扩展系统不成立的大量假设。
这种操作源自以下传统假设：在单个实例中执行针对客户端池的业务控制，例如，通过单个硬件服务器建立整个系统，并且通过单个点来路由所有业务，其中可以在该单个点处对业务进行观测和控制。然而，在水平扩展系统中，例如由于故障、升级等，硬件和/或软件实例可能在任意时间点来去。
可能更关键的是，从客户端池向水平扩展应用中的对等应用实例分发业务可能导致一些应用实例被过度利用而一些应用实例未被充分利用。例如，给定客户端或至少源自相同客户端上下文的给定连接可能比其他客户端或连接“更具粘性”。在这一方面，“粘性”连接是持久的并且与持续的应用业务相关联。
本文认为以循环“负载分发”方案向各个应用实例指派来自不同客户端池的应用业务未考虑以下事实：由分布式应用业务引起的粘性连接可能聚合在应用实例中的一个或多个处。此外，在对等应用实体之间同步业务控制参数的状态在可用网络带宽和达到和/或维护同步状态所需的消息数量方面可能是昂贵的。
发明内容
本发明包括用于水平扩展应用中的分布式业务控制的装置和方法，其中，基于软件的应用被实现为多个对等应用实例，每一个应用实例提供应用的总能力或容量的一部分。在每一个应用实例处实例化或以其他方式实现包括分布式业务控制器的装置，并且这些装置共同操作以根据例如服务水平协议或SLA限制各个客户端或附属客户端组对应用的总利用率，并且还操作以防止应用实例中的任意一个的不成比例利用率。有利地，根据本文的教导在分布式业务控制器之间使用有效信息传播协议来完成这些操作。
在更详细的示例中，本文的教导公开了控制单独客户端对软件应用的利用率的方法。应用被实现为多个对等应用实例，这些对等应用实例从多个客户端中的任意一个或多个客户端接收应用业务，并且在每一个应用实例处实现所述方法。
有了该理解，所述方法包括：将进入进入所述应用实例的应用业务分类为与所述客户端中的不同客户端和/或不同类型的应用业务相对应的流；以及关于所述应用实例估计每一个流的本地需求值。所述方法还包括：与所述应用实例中的一个或多个其他应用实例交换本地需求信息。所述交换包括：发送针对所述应用实例处的所述流所估计的本地需求值，以及接收所述应用实例中的其他应用实例处的所有相似流的相似估计的本地需求值。
根据该方法，在每一个应用实例处使用交换的本地需求信息来确定应用实例处的每一个流的总体需求值。关于应用确定总体需求值。在这个意义上，在非限制性示例中可以将针对给定应用实例处的给定流所确定的总体需求值理解为针对该应用实例处的该流所估计的本地需求值和针对其他应用实例处的所有相似流所估计的本地需求值之和。
有利地，所述方法继续使用针对每一个流所确定的总体需求值来计算应用实例处的流的本地利用率限制。
相应地，所述方法还包括：根据是否超出所述流的本地利用率限制，将每一个流中的应用业务标记为不符合策略业务或符合策略业务。该操作可以被理解为第一级监管，在该第一级监管中应用了逐流利用率限制。
作为第二步或第二级监管，所述方法附加地包括：确定所述应用实例处的所有流的应用业务的聚合是否超出本地聚合利用率限制。根据所述方法，基于是否超出所述本地聚合利用率限制和/或基于对符合策略业务和不符合策略业务的区分，控制对去往所述应用实例的聚合应用业务的缓存。例如，虽然可以响应于不符合策略业务来约束单独流，但是也可以是以下情况：对聚合应用业务进行缓存涉及：至少在超出本地聚合利用率限制期间向符合策略业务和不符合策略业务应用不同的缓存优先级。
在本文教导的一个或多个实施例中使用包括分布式业务控制器和通信控制器的装置实现上述方法及其变形或扩展。装置可以是基于软件的，例如，根据存储在计算机可读介质中的计算机程序指令的执行被实现为逻辑或功能电路。在示例性情况下，装置被实现为每一个应用实例的一部分，或者被实现为联合主机操作系统环境中的应用实例执行的伴随程序。
在示例性配置中，分布式业务控制器将进入进入其相关联的应用实例的应用分类为流，并且对每一个流应用第一级基于令牌桶的监管。也即是说，将逐流令牌桶监管方案应用于每一个流中的业务，以根据是否超出流的本地利用率限制将流中的应用业务标记为符合策略的或不符合策略的，并且可选择地，以每一个流为基础应用第一级业务调节(例如，通过丢弃来自流的应用业务中的一些)。
根据由分布式业务控制器针对与该分布式业务控制器配对的应用实例处的流所估计的本地需求值和由其他分布式业务控制器在其他应用实例处针对所有相似流所估计的本地需求值来确定这些逐流利用率限制。也即是说，通过每一个应用实例处的每一个流的分类参数——例如，业务类型、客户端域等——来定义该流，并且具有相同分类参数的另一应用实例处的任意流是相似流。因此，与任意给定流相关联的总需求或总体需求取决于所有应用实例之间的所有相似流的本地需求。
与分布式业务控制器配对的通信控制器交换本地需求信息，从而提供本地需求值在所有分布式业务控制器之间的传播，从而使得能够在考虑所有其他应用实例处的相应流需求的情况下计算准确的总体需求值并且以每一个流为基础动态地调节本地利用率限制。
作为另一优点，每一个分布式业务控制器向每一个应用实例处的应用业务的聚合——即，组合应用实例处的所有各流的聚合流——应用第二级监管。聚合级的监管可以涉及：根据是否超出本地聚合利用率限制来选择性地调节聚合流。
根据独立权利要求的本发明的效果是针对给定应用实例处的给定流所准许的容量或其他应用资源的比例随着与该流相关联的总体需求而改变。当然，本发明不限于这些或其他前述特征和优点。实际上，本领域技术人员在阅读以下详细描述之后并且在查看附图之后将认识到附加特征和优点。
附图说明
图1是实现水平扩展应用的分布式处理系统的一个实施例的框图。
图2是示出了图1的分布式处理系统的示例性细节的框图。
图3是本文设想的分布式业务控制器的一个实施例的框图。
图4是图3的分布式业务控制器的其他示例性细节的框图。
图5是本文设想的分布式业务控制方法的一个实施例的逻辑流程图。
图6A和图6B是提供可以在分布式业务控制器中实现的业务分类器和逐流(per-flow)监管布置的其他示例性细节的框图。
图7是图示了基于将应用业务标记为符合策略或不符合策略的逐流监管的一个实施例的框图。
图8A、图8B以及图9-11是由分布式业务控制器根据本文教导的一个或多个实施例执行的基于令牌桶的业务监管的逻辑流程图。
图12是在分布式业务控制器之间交换本地需求信息的一个实施例的信号流程图。
图13是产生并发送同步(SYN)消息作为交换本地需求信息的一部分的一个实施例的逻辑流程图。
图14是接收并处理在分布式业务控制器处接收的特定消息类型作为交换本地需求信息的一部分的一个实施例的逻辑流程图。
图15是图示了本文的分布式业务控制教导规定的分布式业务控制的示例的示意图。
具体实施方式
图1示出了基于软件的应用10，其在该讨论中被称作“应用10”。客户端池12-1、12-2等使用应用10，并且将理解的是，每一个客户端12-1、12-2等将在使用应用10时消耗其总容量或能力的特定部分。为了便于参考，在没有后缀的情况下使用附图标记12来一般地指代客户端12-1、12-2等中的任意一个或多个。因此，术语“客户端12”和“多个客户端12”分别是指客户端中的任意一个和客户端中的任意两个或更多个。
此外，如本文所使用的术语客户端是“多含义”术语。通常，客户端12包括某一软件组件实例——该软件组件实例在系统设备或系统中被实例化——该软件组件实例产生去往应用10的一种或多种应用业务。示例性客户端12可以产生多个不同消息类型，例如，创建、读取、更新等，并且每一个消息类型可以被视为关于应用10的各个业务“流”，其中每一个此类流可以通过服务水平协议或SLA来管理，其中，服务水平协议或SLA是在提供应用10的组织与经由一个或多个客户端12利用应用的订制组织之间协商的。附属于订制组织的多个用户可以运行多个相似客户端12或多个不同类型的客户端12，每一个客户端12根据SLA条款利用应用10，其中，SLA条款可应用于由所有此类客户端12对应用10的共同利用。
记住上面提及的方案，可以看到，应用10被实现为多个对等应用实例14-1、14-2等。除非为了清楚起见而需要后缀，否则该讨论将使用术语“应用实例14”来一般地指代应用实例14-1、14-2等中的任意给定应用实例，并且将类似地使用术语“多个应用实例14”来指代应用实例14-1、14-2等中的任意给定两个或更多个应用实例。
每一个应用实例14作为应用10的副本操作，因此提供应用10的整个功能，但是仅提供总应用能力或容量的一部分。通过对等应用实例14的集合以水平扩展形式表示可以根据每秒事务量等来测量的总能力或容量。应用10(全体地)以及每一个应用实例14将被理解为包括以下各项或由以下各项表示：在数字处理电路中实现的功能电路配置和一个或多个计算机系统上的相关联存储器，例如，运行操作系统的服务器，其中，应用实例14在该操作系统中执行。附图以全体意义描绘了该处理电路，其被称作“分布式处理系统16”。
客户端12中的单个客户端经由通过一个或多个计算机网络18(例如，一个或多个公共数据网络或私有数据网络，可以包括互联网，并且可以包括在其中支持虚拟专用网(VPN)连接)的通信耦合与应用实例14中的单个应用实例进行通信。每一个客户端12向应用10发送应用业务，其中，该业务包括例如根据定义协议发送的请求消息。负载均衡器20接收从客户端池12输入的应用业务，并且使用例如循环分发功能将其分发给应用实例14中的相应应用实例，其中，进入进入负载均衡器20的每一个新应用消息或一批新的应用消息被分发给应用实例14中的下一个。
因此，进入进入应用实例14中的任意一个的应用业务包括任意数量的应用业务流22，如上所述。也即是说，针对任意给定应用实例14，输入的应用业务可以包括来自客户端12中的多个客户端的多种类型的消息。
稍后将在本文中详细描述的处理在逻辑上将进入进入每一个应用实例14的应用业务分离为各个流22，其中每一个流22通常表示给定类型的应用业务并且具有给定的客户端关联。客户端关联可以是特定的，例如，来自客户端12-1或12-2的业务等，或者客户端关联可以是域方面的关联，例如，与相同的SLA与其他订制许可相关联的任何客户端12，其中所述其他订制许可给予所有此类客户端12对应用10的访问权。在这一方面，还应当注意的是，从负载均衡器20进入进入任何给定应用实例14的应用业务通常还未在逻辑上分类为流22——这种分类是结合本文教导的分布式业务控制执行的。因此，图1中的标签“22”的布置并不旨在如同该术语在本文被定义的一样仅是指输入业务包括与任意数量的流22相关联的业务。
虽然负载均衡器20采取的业务分发方法可以“公平地”向各个应用实例14分发初始请求消息，但是这些请求中的一些请求被快速地服务，同时请求涉及与后续业务的“粘性”或持久连接，其中，后续业务锚定到该粘性连接。因此，不是每一个输入请求消息或其他类型的业务都在接收应用实例14处导致相同的处理负载。因此，当在不考虑该业务的粘性的情况下分发应用业务时，可以出现负载失衡。
因为从各种客户端12到应用实例14中的任意一个的应用业务的混合流表示粘性事务和非粘性事务的任意可能的组合，因此每一个应用实例14包括被配置为控制应用业务的特定流对软件应用10的最大总利用率的装置28或者与该装置28配对。简而言之，装置28提供了对应用实例14的集合的复杂形式的分布式业务控制，而未妨碍应用10的性能并且无需其之间的大量信令。
将理解的是，装置28可以表示例如通过执行存储的计算机程序指令在分布式处理系统16的数字处理电路中实现的功能电路布置，其中，存储的计算机程序指令具体实现本文针对装置28所述的处理逻辑。还将理解的是，装置28可以在每一个应用实例处被复制，使得针对包括整个应用10的相应应用实例14实现相似的装置28。每一个此类装置28可以实现在包括应用实例14的计算机程序中，或者可以实现为关于应用实例14的附属或“伴随”程序。
装置28包括分布式业务控制器30，在附图中将该分布式业务控制器30缩写为“DTC”。为了方便起见，在下文中将使用缩写词“DTC”。DTC 30被配置为关于应用实例14针对应用实例14处的应用业务的每一个流22估计本地需求值。
装置28还包括通信控制器32，在附图中根据缩写词CC对通信控制器32进行描绘。在下文中将使用该缩写词。CC 32被配置为与应用实例14中的一个或多个其他应用实例交换本地需求信息。交换本地需求信息包括：发送在应用实例14处针对应用实例14处的应用业务的每一个流22估计的本地需求值，以及接收应用实例14中的其他应用实例处的相似流22的相似估计的本地需求值。
如本文稍后将详细描述的，如果两个不同应用实例14处的应用业务的两个流22包括相同类型的应用业务并且源自相同的客户端12或者源自相同的客户端域或上下文，则它们被认为是“相似流”。术语“域”是指以下情况：使用单个订制实体标识潜在很多客户端12，使得源自这些客户端12的所有应用业务属于相同的客户端域或者上下文，从而作为整体符合由订制实体签订的SLA。更简单的说，如果应用实例14之一处的流22和另一应用实体14处的另一流22的分类是相同的(例如，两个流22包括相同类型的应用业务并且两个流22与相同的客户端上下文相关联)，则应用实例14之一处的流22与另一应用实体14处的另一流22“相似”。
还需要注意的是，图1中针对装置28提议的逻辑或功能电路分离可以具有某些优点，例如，布置将装置28分离为逻辑控制器30和32，其中一个此类控制器在其相应应用实例14处处理分布式业务控制，另一个此类控制器处理装置28之间的信息交换从而维持所有DTC 30之间的状态同步。然而，也可以实现组合的控制电路和/或可以使用其他功能划分来实现装置28。因此，所描绘的布置不应当被理解为限制性的。
DTC 30被进一步配置为在整体意义上关于应用10确定应用实例14处的每一个流22的总体需求值。这可以被理解为评定在应用实例14处确定的每一个流22的本地需求值、以及评估其他应用实例14处的所有相似流22的本地需求值。因此，与每一个流22相关联的总体需求值的确定基于CC 32之间对本地需求信息的交换。
DTC 30被进一步配置为：根据针对每一个流22所确定的总体需求值来计算该流22的本地利用率限制；根据是否超出流22的本地利用率限制来将每一个流中的应用业务标记为不符合策略业务或符合策略业务；确定应用业务14处的所有流22中的应用业务的聚合是否超出本地聚合利用率限制；以及基于是否超出本地聚合利用率限制以及对符合策略业务和不符合策略业务的区分，以每一流和/或聚合流为基础控制对去往应用实例14的聚合应用业务的缓存。
因此，在至少一些实施例中，DTC 30可以被理解为基于使用针对DTC 30处的流22和其他应用实例14处的相似流22所确定的利用率(需求)信息来确定应用实例14处的每一个流22的本地利用率限制，对每一个单独流22中的应用业务流进行监管，其中，流22的本地利用率限制与流22和其所有相似流22所表示的总需求成正比。这允许对所有应用实例14之间的所有相似流22的应用业务进行共同监管，并且对客户端的应用业务施加总体控制或网络控制，而无需集中式的流控制机制。
在一些实施例中，DTC 30被配置为与CC 32协作以通过经由基于gossip的逆熵协议与应用实例14中的一个或多个其他应用实例进行通信来交换本地需求信息，其中，经由基于gossip的逆熵协议将在应用实例14中的任意一个处估计的本地需求值传播到应用实例14的所有其他应用实例。参见例如Van Renesse,R.,Dumitriu,D.,Gough,V.,&Thomas,C.,“Efficient Reconciliation and Flow Control forAnti-Entropy Protocols,”Second Workshop on Large-Scale DistributedSystems and Middleware(LADIS 2008),Yorktown Heights,NY:ACM(ISBN:978-1-60558-296-2)。此外，参见Bailly F,Longo G.,Biologicalorganization and anti-entropy,J BiolSyst 17(1):63–96(2009)。这两个参考文献提供了基于gossip的信息交换的示例性细节，并且它们通过引用的方式并入本文。
返回DTC 30的示例性细节，本文设想了多种用于估计每一个流22的本地需求值的方法。在非限制性示例中，DTC 30被配置为通过以下至少一种方式来估计每一个流22的本地需求值：对应用实例14处针对流22活动的协议会话的数量进行计数；基于在定义间隔内在流22中是否存在任何新业务来估计预期的流速率；以及基于测量流22中的应用业务的到达速率来估计预期流速率。
每一个DTC 30还被配置为确定其相应的应用实例14处的每一个流22的总体需求值。该总体需求值当然是关于整个应用10来确定的，并且例如通过对针对流22估计的本地需求值和其他应用实例14处的DTC 30针对相似流22估计的本地需求值进行求和来确定该总体需求值。通过经由CC 32在DTC 30之间交换本地需求信息来获知该信息。
关于确定应用实例14中的任何给定应用实例处的每一个流22的本地利用率限制，在一些实施例中，相应的DTC 30被配置为通过计算每一个流22中的应用业务的本地流速率限制来计算该流22的本地利用率限制。在这一方面，需要记住的是，每一个应用实例14观测到来自各个客户端12的由负载均衡器20动态分发的应用业务的混合；因此，任何给定应用实例处的DTC 30可以被配置为基于业务类型、与请求相关联的起源标识等将输入的应用业务归类或以其他方式分类为不同的流22。例如，流22可以是soap/http或远程登录消息中包含的来自给定客户端12的所有应用请求，其中，所有请求具有相同的用户标识。每一个流22可以与特定服务水平协议或SLA相关联。因此，DTC 30必须以分散方式操作，但是履行应用10关于客户端12及其相应或组合的应用业务流22要整体满足的SLA承诺。
在一些实施例中，每一个给定DTC 30还被配置为通过以下方式计算每一个流22中的应用业务的本地流速率限制：用比例因子缩放所有相似流22的已知总最大流速率限制来计算本地流速率限制，其中，比例因子被确定为流22的本地需求值与该流22和其他应用实例处的其所有相似流22的总体需求值之比。总最大流速率限制可能源自SLA或其他预配置的约束，并且可以是存储器中存储的配置数据项，其中，存储器包括在每一个装置28中或者可以由每一个装置28访问。还应当注意的是，DTC 30还可以被配置为进一步通过计算流22中的应用业务的本地突发大小限制来计算流22的本地利用率限制。
因此，在每一个应用实例14处，从负载均衡器20进入进入应用实例14的应用业务可以被分类为流22，其中，每一个流22服从监管——例如，最大流速率和/或突发大小限制——并且根据聚合利用率限制对应用实例14处的此类流22的应用业务的聚合流进行进一步约束。每一个DTC 30关于应用实例14中的相应应用实例的此类操作允许以以下方式对应用利用率进行分散控制：防止各个客户端12或附属多个客户端12使给定的应用实例14超负荷，同时仍然确保应用10满足关于这些客户端12的SLA要求。
关于控制对去往应用实例14的应用业务的聚合流的缓存，在一些实施例中，DTC 30被配置为将聚合的应用业务缓存在一个或多个延迟缓存中，并且根据优先级划分方案对针对应用实例14的一个或多个延迟缓存进行清空，其中，与不符合策略业务相比，该优先级划分方案通常对符合策略业务施加更短的缓存延迟。
例如，如果超出本地聚合利用率限制，则DTC 30例如通过根据优先级划分方案清空缓存来调节去往应用实例14的应用业务的聚合流，其中，与符合策略应用业务相比，优先级划分方案不喜欢不符合策略应用业务。由于不符合策略应用业务表示给定流22的本地过度利用，因此这具有以下影响：对应用实例14处的一个或多个流22进行节流或抑制。
当然，如上所述，DTC 30可以被进一步配置为根据可用于各个流22的任何SLA中定义的一个或多个服务参数来对一个或多个延迟缓存中的任何聚合应用业务划分优先级。此外，如上所述，以每一个流为基础将应用业务标记为符合策略或不符合策略。因此，一个流22可能在任意时刻过度利用应用实例14，使得该流22中的业务被标记为不符合策略，而处于其本地利用率限制以下的另一流22中的业务被标记为符合策略业务。
通过将输入的应用业务分类为流22以及将每一个流22的应用业务标记为符合策略业务或不符合策略业务，DTC 30可以被进一步配置为根据需要对流22中的各个流中的应用消息进行节流或选择性丢弃，从而维持与在可用于流22的相应SLA中保证的最大服务水平的符合性。因此，可以在每一个应用实例14处针对各个流22以及通过各个流22的组合表示的聚合流应用业务整形、选择性分组丢弃或者其他类型的应用业务速率限制或调节。
图2示出了应用实例14及其相应装置28可以实现在相同或分离的计算系统——例如，相同或分离的服务器硬件——上，并且还可以使用虚拟化服务器来实现。在该示例性示意图中，应用实例14-1和14-2被实现在驻留在第一物理服务器上的虚拟化服务器上，该虚拟化服务器为其执行提供了操作系统环境。当然，其相应装置28驻留在该相同的操作系统环境中。
应用实例14-3和14-4及其相应装置28也驻留在该相同的服务器，但是它们是在托管应用实例14-1和14-2的虚拟化服务器之外实现的。两个附加服务器中的每一个托管图示中所示的两个附加应用实例14-5和14-6中的相应应用实例。这些附加服务器可以或不可以与其他服务器位于同一位置处，但是它们至少可通信地链接，以提供在相应的装置28中的CC 32之间交换本地需求信息。
图3示出了结合每一个应用实例14实现的装置28中包括的DTC30的示例性功能电路实现。在所示的示例中，DTC 30包括SLA分类器40、SLA限制器42、需求存储设备33、速率计算器46、以及需求分发器加接收机48，其可以被理解为包括整个CC 32或CC 32的元件，以用于交换本地需求信息。
DCT 30的输入应用业务是由负载均衡器20(未示出)向应用实例发送的所有应用业务的聚合，并且因此包括来自任意数量的流22的业务的混合。同样地，流出DTC 30并且流入应用实例14的应用业务表示聚合流。然而，与DTC 30观测到的来自负载均衡器20的输入聚合相比，可以对从DTC 30到应用实例的业务的聚合流进行监管、整形、或以其他方式调节。例如，与流入DTC 30的聚合应用业务相比，可以对流出DTC 30的聚合应用业务进行速率限制或其他方式整形。
为了更好地理解示例性配置中的SLA限制器42的操作，图4示出了根据一个实施例的SLA限制器42的功能电路配置。在所示的实施例中，SLA限制器42包括令牌桶选择器50，在附图及下文中简称为“TB选择器50”。SLA限制器42还包括业务监管器52，该业务监管器52在逻辑上包括针对相应流22(标记为“A”、“B”、“C”等)的令牌桶“A”、“B”、“C”等，并且使用这些令牌桶操作。此外，SLA限制器42包括TB监管SLA限制器54、队列处理器56、以及相应的高优先级队列58和低优先级队列60，相应的高优先级队列58和低优先级队列60实际上可以包括多个高优先级队列和低优先级队列并且可以在主机操作环境中在装置28可用的工作存储器中被实现。这些实体可以作为整体被理解为SLA实施器62。
虽然针对这些详细功能电路布置的操作给出了示例性细节，但是这有助于参考每一个装置28实现的整个操作方法。图5提供了该方法的示例，在示意图中将该方法表示为“方法500”。方法500将被理解为控制单独客户端12对软件应用10的最大总利用率的方法，其中，跨越多个对等应用实例14实现应用10，所述多个对等应用实例14接收从多个客户端12动态地分发给它们的应用业务。
每一个应用实例14处的方法500包括：将进入进入应用实例14的应用业务划分为流22(框502)；关于应用实例14对每一个流22的本地需求值进行估计(框504)；与应用实例14中的一个或多个其他应用实例交换本地需求信息(框506)，包括：发送在应用实例14处针对应用实例14处的每一个流22估计的本地需求值，以及接收其他应用实例处的相似流22的相似估计的本地需求值；基于交换的本地需求信息关于应用10确定流22的总体需求值(框508)；根据针对每一个流22所确定的总体需求值来计算该流22的本地利用率限制(框510)；以及根据是否超出流22的本地利用率限制将每一个流22中的应用业务标记为不符合策略业务或符合策略业务(框512)。
方法500还包括：确定应用实例14处的所有流22的应用业务的聚合是否超出本地聚合利用率限制(框514)；以及基于是否超出本地聚合利用率限制和/或基于例如根据缓存优先级对符合策略业务和不符合策略业务的区分，来控制对去往应用实例的聚合应用业务的缓存。
方法500以分散方式控制任意数量的服务器/应用实例14之间的应用业务，并且其主要优点是产生任意数量的客户端12对应用资源的受控共享。概括地说，利用本文设想的装置28和方法500，不存在对资源分配进行实施或控制的中心点。更确切地说，每一个装置28用作应用实例14中的相应应用实例的业务调节器，并且运行两个主要算法：由DTC 30提供的本地业务控制算法以及由CC 32提供的状态传播算法。
虽然以下细节可以在某些方面改变，但是在一个或多个实施例中，每一个应用实例14处的DTC 30基于在一个或多个分类流22中针对应用实例14输入的应用业务定期地计算并存储“需求”。使用传播算法将这些估计的需求值定期地且有效地传播到其他DTC 30——即，将每一个DTC 30处计算的本地需求信息与其他DTC 30共享。此外，每一个DTC 30基于其自己的需求计算和其他DTC 30的需求计算以及用相同的测量项表示总应用容量的配置或已知的值来计算资源限制值——例如，速率。每一个DTC 30基于调节应用实例处的应用业务流22来限制每一个流22中由其相应应用实例14处理的应用业务，而不论其对等体如何，从而提供应用容量的公平或均衡共享。
因此，应用实例14本身不需要共享状态信息，并且应用实例14与其对等应用实例14相比不具有特殊作用。类似地，装置28与其对等装置28相比不具有特殊作用。每一个装置28简单地使用在装置28之间传播的本地需求值以相似的方式操作，以在每一个应用实例处提供独立的业务调节功能，但是这允许整个应用10满足针对各个客户端12的SLA要求，而不允许这些客户端中的任意一个过度利用应用10。因此，装置28在应用实例14之间提供了足够的协调以在应用级别实施SLA。
如上所述，可以基于与针对任意给定应用实例14输入的应用业务相关联的起源标识将该业务分类为不同的流。例如，流可以是soap/http或远程登录消息中包含的来自客户端12的请求，其中，所有此类请求具有相同的用户标识。因此，每一个流可以与特定SLA相关联，例如，应用10要整体满足的最小请求速率和/或最大突发大小。
为了进一步讨论示例性操作细节，转回图3，SLA分类器40读取或以其他方式确定针对给定应用业务——例如，给定输入请求消息——的客户端标识，并且针对该客户端12使用适合的SLA分类器对业务加标签。注意，SLA分类器40还可以实现在应用实例14中，使得输入的应用业务由应用实例14识别和加标签，被传递到装置28以进行受控缓存(如本文所教导的)，然后DTC 30将得到的经调节的应用业务返回应用实例14以进行处理。
应用客户端标识(ID)可以存储在需求存储设备44中。SLA限制器42通过实施由SLA分类器40设置的SLA标签作为业务整形器操作，其中，SLA标签可以被理解为类型流分类或标识符。在这一点上，可以使用令牌桶方案来实现业务整形。参见例如Kim,Han Seok；Park,Eun-Chan；Heo,Seo Weon,“A Token-Bucket Based Rate ControlAlgorithm with Maximum and Minimum Rate Constraints,”IEICETransactions on Communications,Volume E91.B,Issue 5,pp.1623-1626(2010)，其通过引用的方式并入本文。
速率计算器46以给定间隔“A”读取需求存储设备44中的信息，并且与TB选择器50相关联地更新SLA限制器42中的所有令牌桶速率——参见例如客户端A、B和C的令牌桶，如图4中的业务监管器52中所示。需求分发器和接收机48以给定间隔“B”读取需求存储设备44，并且使用基于gossip的逆熵协议算法对其他应用实例14处的本地需求信息进行同步。间隔A和B无需相等，例如，间隔B可以比间隔A更长，并且可以在特定应用的上下文中根据需要或期望对这两个间隔的绝对值进行设置。更短的间隔提供更好的“系统”响应，但是增加了对等装置28之间的信令开销。然而，存在明显的灵活性，这是因为与CC 32相比，速率计算器46和DTC 30通常作为装置28内的分离进程操作。
转向图4中所示的示例性SLA限制器实现，可以看出，SLA限制器42基于多个功能电路的操作来执行业务整形。SLA限制器42可操作地对到达的每一个应用消息实施计算出的本地利用率限制——例如，本地速率限制——以便由应用实例14处理。SLA限制器42对进入进入应用实例14的每一个应用消息执行以下逻辑处理操作：(1)由TB选择器50读取来自应用消息的SLA标签，以及基于SLA标签从业务监管器52中的现有TB监管实例集合中挑选专用令牌桶监管实例。换言之，识别应用消息所属的流22，并且例如针对流A、B、C等识别适合的令牌桶。
通过业务监管器52中的TB监管实例中的适当TB监管实例来评估应用消息。根据流22的应用业务是否超出针对该流22计算出的本地利用率限制，将应用消息标记为符合策略的或不符合策略的。相应地，队列处理器56使用来自业务监管器52的监管结果来选择正确的队列(低优先级或高优先级)。如上所述，还可以根据其他优先级划分(例如，基于SLA的最小服务速率，其导致某些缓存的应用业务以比其他缓存的应用业务更高的优先级被缓存)来组织SLA实施器62中包括的队列58和60。
业务监管器52可以被理解为施加第一级或第一步业务监管，其是以每一流为基础执行的。相应地，SLA实施器62可以被理解为施加第二级或第二步业务监管，其中关键区别是由SLA实施器62实施的监管对装置28/应用实例14处的所有业务流22的聚合操作。在示例性配置中，SLA实施器62基于是否超出本地聚合利用率限制和/或基于符合策略业务和不符合策略业务之间的区分，来控制对去往应用实例14的聚合应用业务的缓存。例如，控制缓存可以是指只要未超出本地聚合利用率限制，就不缓存消息，或者消息可以终止于不同的缓存，其中以不同的优先级排空每一个缓存。
此外，可以例如根据一个或多个流参数来表达本地聚合利用率限制，例如，最大聚合流速率和/或最大聚合突发大小。
在一个方法中，队列处理器56检查缓存58、60是否包含任何应用业务。如果所有此类队列是空的，则SLA实施器62不施加业务调节，并且在没有经优先级划分的缓存延迟的情况下将给定的应用消息传递到应用实例14。
另一方面，如果缓存58、60不为空，则队列处理器56根据定义的优先级方案排空缓存58、60，例如，以速率0.99*R_tot排空高优先级缓存中缓存的应用业务，而以速率0.01*R_tot排空低优先级缓存中的应用业务，其中R_tot表示最大聚合流速率。
因此，在本文所述的至少一些实施例中，可以将不同的流22映射到不同的缓存。由缓存58和60表示的高优先级和低优先级是其示例。可以将所有应用业务放置于此类缓存中，然后根据本地利用率限制和/或根据本地聚合利用率限制来排出这些应用业务。
图6A示出了SLA分类器40的示例性操作，该SLA分类器40对例如来自负载均衡器20或其他源的针对应用实例输入的所有应用业务进行“滤波”或以其他方式进行逻辑处理。作为其处理的结果，例如经由上述SLA加标签将输入应用业务分类为流22，其中，每一个流22包括与相同的客户端上下文相关联的所有应用业务。在该示例中，可以看出SLA分类器40将输入应用业务归类为多个流22，例如，FLOWA、FLOWB、FLOWC直到FLOWN。
图6B根据一个实施例通过示出了SLA限制器42对各个流22的操作扩展了该相同的流处理示例。然而，在深入研究细节之前，介绍用于此类处理的标记将是有帮助的：
-“flow_x”表示所有应用实例14之间针对相同客户端上下文的所有应用业务；
-“flow_x,i”表示任意给定应用实例14处针对相同客户端上下文的所有应用业务，即，“i”指示应用实例14中的特定应用实例，因此将理解的是，应用实例14-i处的DTC 30估计flow_x,i的本地需求值，并且基于接收到flow_x,y、flow_x,z等来估计flow_x的相关联的总体需求值，其中，“y”和“z”表示flow_x在相应其他应用实例14-y和14-z处的其他实例；
-“d_x,i”表示针对flow_x,i所估计的本地需求值；
-“r_x,i”表示在流速率方面针对flow_x,i的本地流利用率限制，并且其他限制可以附加地或备选地适用，例如，最大突发大小，其被表示为“b_x,i”；
-“r_tot,i”和“b_tot,i”表示用流速率限制和突发大小限制表示的可应用于给定应用实例14-i处的所有流的聚合的本地聚合利用率限制——例如，r_tot,i＝r_x,i+r_y,i+r_z,i，其中，r_y,i和r_z,i表示应用实例14-i处的flow_y和flow_z的最大流速率限制；
利用上面的标记，“R_x”可以用于表示针对flow_x的所有实例flow_x,i的最大总利用率。类似地，“B_x”可以用于表示针对flow_x的所有实例flow_x,i的最大总突发大小限制。
此外，“R_tot”可以用于表示所有应用实例14之间的所有流实例的聚合的最大聚合流速率。同样地，“B_tot”可以用于表示所有应用实例之间的所有流实例的聚合的最大突发大小限制。
记住上面的标记，装置28在每一个应用实例i处例如以定期间隔执行以下操作：通过以下方式来估计每一个flow_x的d_x,i：例如对flow_x使用的协议会话的数量进行计数或者估计flow_x近期的预期流速率(例如，假设将来的流速率等于当前到达速率)，或者如果最近已经在flow_x中观测到任何应用消息，则将d_x,i设置为“1”，否则将d_x,i设置为“0”，其中，该二进制方法可以特别有利于对来自负载均衡器20的业务进行完全平均分发。
此外，每一个装置28在每一个应用实例i以定期间隔——但是不一定是与用于需求估计的间隔相同的间隔——执行以下操作：
-“公布”应用实例i处的所有流22的所有d_x,i值，其中，可以使用基于gossip的逆熵协议来完成公布；
-基于来自其他应用实例的已知需求估计来计算应用实例i处的所有流22的总体需求值，例如，给定flow_x的总体需求是D_x＝所有应用实例i＝1至N上的所有d_x,i之和；以及
-调整应用实例i处的每一个flow_x,i流的r_x,i，以进行与其他实例处的状态(需求)成比例的本地分配，例如，按照r_x,i＝R_x*(d_x,i/D_x)来计算按流速率表达的每一个flow_x,i的本地利用率限制。
注意，上面的调整步骤表示了简单的示例性本地利用率限制确定。给定应用实例14处的每一个流22的本地利用率限制可以包括：实施最小和最大流速率。此外，注意，还可以以类似地方式(例如，使用类似的线性表达)来更新b_x,i和B_x。此外，在一些实施例中，例如，针对在每秒最大事务量限制情况下的业务整形，还可以调整r_tot和b_tot，例如，r_tot,i＝R_tot*d_x,i针对所有x之和除以d_x,i针对所有x和所有N之和。
上面的操作对分布式系统16实施R_tot限制——即，在关于应用10的整体意义上。可以关于最大聚合突发大小等来完成类似的实施。
因此，仍然在图6B的上下文中，将理解的是，SLA限制器42执行多个操作步骤，包括第一操作步骤：根据关于相应本地利用率速率定义的优先级对应用业务进行分类——一种形式的“监管”。在缓存58、60中实现的给定优先级队列之一中聚合来自所有应用业务流22的每一个分类的应用消息。优先级队列是由装置28执行的聚合应用业务调节的单个检查站。优先级队列业务参数——例如，最大流速率和最大突发大小——实施可达业务，包括所有输入流22，本文示例为流22-1、22-2等，其中每一个流22对应于不同的客户端上下文。本文，“可达业务”可以是最大可能利用率，其可以由最大可能“负载”给出，或者通过尺寸标注(dimensioning)和/或经营策略来管理地定义，例如，许可配额。此类速率总计高达例如R_tot。
将FLOWA的业务参数值与来自具有类似FLOWA——即，具有相同的应用业务类型和客户端域——的其他应用实例14的参数值进行快速同步。利用先前介绍的标记，可以将相似的流22表示为给定flow_x的不同实例，例如，应用实例14-i处的flow_x,i、应用实例14-j处的flow_x,j、以及应用实例14-k处的flow_x,k。本文，“x”表示公共客户端上下文，并且“i”、“j”和“k”表示接收属于该客户端上下文的应用业务的应用实例14中的不同应用实例。
图7图示了在业务监管器52和/或TB监管SLA限制器54的实例“内”执行的处理。在一个或多个实施例中，由两个此类处理单元使用的监管算法是相同的。
图8A和图8B描述了令牌桶算法的示例性细节，其中令牌桶算法在业务监管器52和TB监管SLA限制器54内的子功能块内执行。在图示中，算法被表示为“方法800”。此外，在这些子功能块中运行的算法可以是相同的，区别在于实体52以每一个客户端流为基础操作用户的每客户端流利用率限制，而实体54使用聚合利用率限制操作聚合业务流。因此，可以看到令牌桶处理方法800的两个入口点，即，入口点“B”(在图8A中，针对实体52)和入口点“K”(在图8B中，针对实体54)，以及相应的两个出口点“C”(针对实体52)和“L”(针对实体54)。
方法800中的处理从以下步骤“开始”：接收指示到时间执行令牌桶更新的信号(步骤1)。确定针对给定流22要添加到令牌桶的令牌的数量，并且这表示针对流22实施本地利用率限制(步骤2)。基于多个因素来对该确定作出决策，其中，多个因素包括例如自从最近更新以来的增量时间、业务服务或流类别等。步骤3包括：基于例如自从最近更新以来的时间、业务服务类别、当前令牌桶缓存大小、最大突发速率等来确定要在涉及的令牌桶中设置的令牌的数量。利用做出的这些确定，步骤4-11概述了用于确定应用消息是符合策略的还是不符合策略的示例性方法。
图9描绘了在一个或多个实施例中在队列处理器56中运行的算法，其中该算法一般地被表示为“方法900”。所示的方法900包括处理步骤1-11，并且对每一个给定装置28中的聚合消息流操作，并针对进入进入装置28的应用业务的每一项执行，例如，对每一个新输入的应用消息执行。
注意，流示意图中的项“R”与图11中所述的方法1100相对应，其是作为单独过程被执行的并且用于移除应用业务的各项——例如，包括进入进入装置28和/或应用实例14的应用业务的各个请求或其他应用消息——如果队列处理器56的队列中的任意一个中存在多于一个消息的话。
在图9中所示的处理的更详细示例性解释中，每一个输入消息具有相关联的优先级，在算法中使用该相关联的优先级来确定消息的服务的特性(例如，延迟、丢弃、重排序)。算法在两个模式中操作。当新消息到达时，以下情况发生：
如果已经存在排队消息，则立即对消息进行排队。基于消息的优先级来选择队列。
如果所有队列为空，则检查最近观测到的业务(＝消息的到达过程)以确定当前消息是否在当前消息所属的流22的本地聚合利用率限制内。该检查基于本文详细描述的令牌桶算法。该动作对在彼此之后立即到达的消息实施可持续速率和最大突发大小。如果消息在本地聚合利用率限制内，则直接释放该消息以便由应用实例14进行处理。如果消息违反限制，则将消息放入与其优先级相匹配的队列中。
当对第一消息进行排队时，计算直到可以将该消息释放的时间段。根据速率限制(来自本地聚合利用率限制的r_tot,i)和自从允许上一个消息通过所经过的时间来得到该时间段。(考虑经过的时间防止施加太低的速率)。然后，该算法将调度睡眠，直到该时间段过去为止。
当时间段已经过去时，从队列之一中释放请求。通过队列的优先级来确定从哪个队列进行释放，与较低优先级的队列相比，以较高的概率选择较高优先级的队列。如果所选择的队列为空，则选择较低优先级的队列(重复该过程，直到找到消息为止，如果需要的话，“回绕”至较高优先级)。
如果在任何队列中仍然存在消息，则调度新的睡眠，否则不进行任何操作。
图10示出了例如在速率计算器46内执行的更新会话表和令牌桶策略参数的方法1000。可以看到处理步骤1-6，其中，基于装置28与其对等装置中的一个或多个之间的本地需求值交换来更新给定装置28处的逆熵数据结构(aEDS)(步骤1)，并且将更新的信息与标识应用/服务器、时间戳和版本信息一起写入相应会话表(步骤2和3)。处理继续更新连接的客户端12的本地利用率限制(其是经由在业务监管器52中实现的令牌桶处理来实施的)(步骤4)，等待定义的aEDS更新间隔期满(步骤5)，并且发信号通知/触发新的更新(步骤6)。
此类处理包括例如在装置28之间定期或周期性地交换本地需求信息。此外，应当理解的是，在一个或多个实施例中，aEDS包括数据结构，该数据结构包含应用实例14处的流22的所有相关需求估计。
估计装置28中的任意给定装置处的给定流22的需求的一种方法是基于当前在应用实例14处针对流22打开的客户端会话的数量来估计需求。考虑到每一个附加会话给出了发出去往该特定应用实例14的更多请求的可能性，针对每一个流22打开的会话的计数用作流22对应用实例14施加的需求的粗略估计。
当前，可以使用其他度量来表示需求。例如，可以使用由应用实例14支持/分配的会话、连接的数量、或事务计数或速率和/或可以使用应用消息的观察到达时间或应用实例14住宿在其上的服务器的当前负载。在每一个应用实例14处操作的装置28中的DTC 30基于设置本地业务控制参数(例如，本地利用率限制)定期地计算配置的应用容量的适当/公平共享，以便在业务监管器52处以每一流为基础进行分配。配置的应用容量可以被理解为配置的全系统速率，该全系统速率在应用实例14之间在本地划分并且在每一个应用实例14处由伴随装置28在本地实施。
如上所述，针对应用业务的每一个流22的容量计算(r_x,i和r_tot,i)可以基于：针对其他应用实例14处的相似流22的已知需求以及针对客户端12配置的SLA。在一种方法中，用于监管应用实例14中的任意给定应用实例中的给定流22的应用业务的本地利用率限制用于与本地需求和总需求之比成比例地计算容量分配，例如，流的本地利用率限制＝针对此类流所分配的应用容量*(流的本地需求/流的总体需求)。根据先前的标记，按照下式给出应用实例i处的流x的本地利用率限制：
r_x,i＝R_x*(d_x,i/D_x)。
例如根据与流22相关联的客户端标识，分配的容量可以是已知的。此外，如上所述，可以按照在涉及的应用实例14处估计的本地需求值与针对其他应用实例处的所有相似流22估计的本地需求值之和来计算流22的总体需求。当然，其他算法可以用于计算每一个流的本地利用率限制。可以通过针对应用实例14处的每一个流22的最小容量分配和最大容量分配来获得公平性的整体提高。
关于在不同的应用实例14处的装置28之间交换本地需求值的细节，图12示出了两个对等装置28之间的示例性三次协调握手。假设在应用实例14-1处的装置28与应用实例14-2处的装置28之间交换消息，三个消息是SYN、ACK和ACK2。SYN消息包括具有ID和版本信息的所有条目，而不具有来自应用实例14-1的需求表的需求数据。ACK消息包含基于应用实例14-2处的需求表信息的相应新的内容条目以及缺失的版本条目。
也即是说，应用实例14-2处的装置28将其需求数据与从应用实例14-1处的装置28接收的需求数据进行比较，并且在ACK消息中提供更新以及对任何缺失条目的请求，即，在应用实例14-1处的装置28中维护的信息中未考虑的任何流22的需求数据。类似地，向应用实例14-2返回的ACK2消息包括在应用实例14-2处可用但是在应用实例14-1处缺失的信息。通过这种方式，在相应应用实例14的所有装置28之间传播所有应用实例14处的所有流22的所有信息，而不必需要在装置28的所有可能的配对之间直接交换本地需求信息。
因此，图12可以被理解为由装置28中的CC 32采用以共享本地需求值的基于gossip的逆熵协议的非限制性示例。优选地，被选择用于交换此类信息的任何逆熵算法将使用三次协调握手。始终在两个相互了解的对等体之间执行协调。不是所有对等体都需要相互了解，但是必须存在至少一个所有应用实例最初已知的应用实例14，其被称作“种子”。
更具体地，存在具有所有其他装置28的本地需求值的至少一个装置28，使得被添加以支持整个应用10的每一个新的应用实例/装置28可以开始与该种子装置28进行协调握手。仅在启动时才需要该操作，使得对等体可以开始相互通信。在每一个逆熵群集中应当存在至少两个种子，以避免单个故障点。在群集中的几个消息来回之后，所有对等体相互了解。
一将新的应用实例14放入群集中，就开始与已知的对等体进行协调握手。选择种子的过程是随机的，这是确保快速分发的有效方式。
图13和图14更详细地描述了用于在装置28之间交换本地需求信息的示例性逆熵算法。这些算法例如在每一个此类装置28处实现的CC32中运行。
在图13中，看到处理步骤1-4，其被概括地表示为“方法1300”。方法1300包括第一步骤：算法等待指示到时间交换本地需求信息(例如通过发送来自先前提到的aEDS的信息)的信号。步骤2包括：可能随机地选择与之交换本地需求信息的对等CC 32，而步骤3和步骤4包括：向所选择的对等CC 32发送SYN信号以及发送用于发送aEDS的信号。
也即是说，步骤3向随机对等体发送aEDS并且步骤4使算法回到步骤1中所述的等待状态。显而易见，可以在步骤3和步骤4之间施加等待步骤——例如，间隔定时器——以控制可以发出SYN请求的速率。
在图14中，看到用于处理各种类型的接收的握手消息的处理步骤1-11。这些步骤被概括地表示为“方法1400”并且处理从以下步骤开始：等待从对等体接收aEDS信号(步骤1)，并且继续决定已经接收到哪种类型的aEDS消息(步骤2)。例如，消息可以是包括aEDS请求(即，对包括接收CC 32的装置28处的本地需求信息的请求)的SYN消息。对于该消息，方法1400包括处理接收的SYN消息，确定要发送哪些本地条目，要请求哪些远程条目，以及发送得到的ACK消息(步骤3、6、和9)。
对于接收的ACK消息，方法1400包括：处理ACK消息，确定在ACK2消息中要返回哪些本地条目，使用来自ACK的数据更新本地需求信息，然后将ACK2消息发送回接收的ACK消息所源自的CC32(步骤4、7和10)。示出了用于接收ACK2消息的类似处理(步骤5和8)。
作为本文的教导的很多示例性应用之一，水平扩展应用10可以使用所公开的装置28及其功能等同物来对用户利用电信供应系统设置保证的服务水平协议，其中，电信供应系统使多个用户共享相同的硬件平台。在电信行业中，很多电信运营商已经开始将事务其划分为更小的组织单元。这些电信运营商希望在所有此类子运营商之间共享硬件投资。本文教导的用于控制水平扩展装置10中的利用率的方法500和装置28允许任何电信运营商使用本发明来在任意数量的更小组织单元之间共享给定的硬件投资。此外，本文的教导使得可以收集业务模型数据，以设置此类系统的每一个客户的正确尺寸。
在另一示例中，在“每秒事务量”或“按需付费”处理模型中使用方法500和装置28。在此类模型中，客户支付许可费，从而向客户准许定义的最大数量的每秒事务量(TPS)。因此，给定的客户可能具有产生去往应用10的应用业务的任意数量的客户端12，并且装置28将关于包括应用10的应用实例14操作，以限制应用10向客户提供的最大TPS并且均衡事务处理在应用实例14之间的分布。
在另一示例中，本文的教导规定了用户分离的软件利用率作为可扩展“云”服务。这是可能的，其原因在于这些教导使得可以在水平扩展的任何给定的硬件/软件系统上分离由用户名、应用ID、IP地址或任何其他标识所标识的每用户应用利用率。通过向用户软件准许每用户利用率限制，云提供商避免了任何单个用户不公平地垄断云服务。显而易见，这使流受益，而不论主机操作系统是否允许施加用户限制。
在提供本文教导的另一示例性应用的情况下，图15提供了本文教导的分布式业务控制的简单应用。存在两个应用实例14，其具有四个连接的客户端A、AS、B和C，其中，AS表示“粘性”客户端。本文的目的是对整个应用实施应用消息速率，其中，整个应用是由运行在两个不同的服务器上的两个应用实例14表示的。
配置的总应用实例速率是1000应用消息每秒(msg/sec)。该值针对整个两节点群集给出了2000msg/sec。针对冗余场景的每虚拟服务器的多余容量是200msg/sec，总计为400。在应用中向应用客户端12提供以下速率：向用户A的应用客户端提供600msg/sec、向用户B的应用客户端提供800msg/sec，并且向用户C的应用客户端提供600msg/sec。针对所示场景假设的其他属性包括以下事实：未分配多余容量200msg/sec，即，在故障的情况下将其用作冗余。
用户客户端As——参见示意图中的“p1”——稍后启动同步循环，并且将理解的是，As表示多个粘性客户端连接。应用客户端C在第二同步循环上将负载——在示意图中参见“p3”——从400msg/sec增加到600msg/sec。本文，每一个同步循环应当被理解为基于来自应用实例14已知的本地需求信息和远程需求信息的输入在本地重新计算需求信息。
在另一示例中，由较大的电信运营商组织来使用水平扩展的应用10。组织被划分为更小的部分，例如，19个不同的组织单元。分布式处理系统16包括运行应用的十个不同的服务器，经由输入请求的负载均衡在这些服务器之间水平扩展该应用。系统的总供应容量是10*400＝4000个供应请求/秒。每一个组织子单元得到4000个请求/秒容量的可配置共享，其中，该共享基于每一个子单元负责多少个订户。供应请求创建、修改、或删除归属位置寄存器(HLR)订户数据库中的移动订制。
十个服务器(其中每一个运行供应软件应用10的应用实例14)形成由负载均衡器20馈送的“群集”。群集中的每一个应用实例14从负载均衡器接收业务，其中负载均衡器在十个服务器之间分发输入的供应业务请求。由于与应用实例14中的相应应用实例配对的装置28提供的复杂利用率限制，因此负载均衡器20可以非常简单，例如，业务请求的循环分发。
在该实施例中使用两个不同的协议，即，TELNET和HTTP。基于会话/寿命较长的TELNET连接使得更难在群集上平均分发整个负载。HTTP是可以使用负载均衡器以每一请求为基础进行分发的无状态协议。可以通过仅添加新的服务器来将供应容量每服务器增加400个请求/秒。然而，这些协议的组合使得业务负载分布不均匀。有利地，因为在装置28执行的本地需求值估计中考虑了粘性连接，因此即使在群集中利用非常简单的业务分发方案，也可以实现负载均衡。
在另一示例中，应用实例14包括二十个异构负载均衡器，其在具有16000个虚拟化服务器和非虚拟化服务器的大型网络中分发负载。在该示例中，本文教导的分布式处理方法基于应用消息的应用ID将负载均衡器容量划分为不同的流。在该情况下，负载均衡器的目的是基于可用负载均衡器容量在主机服务器提供商上下文中对负载均衡器的用户进行计费，而不是针对专用硬件成本对用户进行计费。
显而易见，在受益于前述描述和相关联的附图中给出的教导的情况下，本领域技术人员将想到所公开的发明的修改和其他实施例。因此，应当理解的是，本发明并不限于所公开的具体实施例，并且修改和其他实施例旨在包含在本公开的范围内。虽然可以在本文采用特定术语，但是这些术语仅在一般的描述性意义上被使用而不用于限制的目的。

Claims (20)

1.一种控制单独客户端(12)对软件应用(10)的利用率的方法(500)，其中所述应用被实现为多个对等应用实例(14)，所述多个对等应用实例(14)从多个客户端(12)中的任意一个或多个客户端(12)接收应用业务，并且所述方法(500)在每一个应用实例(14)处包括：
将进入所述应用实例(14)的应用业务分类(502)为与所述客户端(12)中的不同客户端和/或不同类型的应用业务相对应的流(22)；
关于所述应用实例(14)估计(504)每一个流(22)的本地需求值；
与所述应用实例(14)中的一个或多个其他应用实例交换(506)本地需求信息，包括：发送针对所述应用实例(14)处的所述流(22)所估计的所述本地需求值，以及接收针对在所述应用实例(14)中的其他应用实例处的所有相似流(22)的相似估计的本地需求值；
基于所交换的本地需求信息来关于所述应用(10)确定(508)每一个流(22)的总体需求值；
根据针对所述流(22)所确定的总体需求值来计算(510)每一个流(22)的本地利用率限制；
根据是否超出所述流(22)的本地利用率限制，将每一个流(22)中的所述应用业务标记(512)为不符合策略业务或符合策略业务；
确定(514)所述应用实例(14)处的所有流(22)的应用业务的聚合是否超出本地聚合利用率限制；以及
基于是否超出所述本地聚合利用率限制以及对符合策略业务和不符合策略业务的区分，以每一个流和/或聚合流为基础来控制对去往所述应用实例(14)的聚合应用业务的缓存。
2.根据权利要求1所述的方法(500)，其中，交换所述本地需求信息包括：经由基于gossip的逆熵协议与所述应用实例(14)中的一个或多个其他应用实例进行通信，所述基于gossip的逆熵协议将所述应用实例(14)中的任意一个应用实例处估计的本地需求值传播到所述应用实例(14)中的所有其他应用实例。
3.根据权利要求1或2所述的方法(500)，其中，估计每一个流(22)的本地需求值包括以下至少一项：对所述应用实例(14)处针对所述流(22)活动的协议会话的数量进行计数；基于在定义间隔内是否已经接收到所述流(22)中的任意新的应用业务来估计所述流(22)的预期流速率；以及基于测量所述流(22)中的所述应用业务的到达速率来估计所述流(22)的预期流速率。
4.根据权利要求1至3中任一项所述的方法(500)，其中，确定所述流(22)的总体需求值包括：对针对所述应用实例(14)处的所述流(22)所估计的本地需求值和通过所述本地需求信息的交换而获知的针对所述应用实例(14)中的其他应用实例处的所有相似流(22)所估计的所述本地需求值进行求和。
5.根据权利要求1至4中任一项所述的方法(500)，其中，计算每一个流(22)的所述本地利用率限制包括：计算所述流(22)的本地流速率限制。
6.根据权利要求5所述的方法(500)，其中，计算所述流(22)的本地流速率限制包括：根据关于所述应用(10)针对所述流(22)和其所有相似流(22)的已知总最大流速率限制来计算所述本地流速率限制，以及通过比例因子对所述总最大流速率限制进行缩放，所述比例因子是根据所述流(22)的本地需求值与所述流(22)的总体需求值之比来确定的。
7.根据权利要求5所述的方法(500)，其中，计算每一个流(22)的本地利用率限制还包括：计算所述流(22)中的应用业务的本地突发大小限制。
8.根据前述权利要求中任一项所述的方法(500)，其中，控制对去往所述应用实例(14)的聚合应用业务的缓存包括：相对于不符合策略业务优先处理符合策略业务，包括：根据优先级划分方案清空针对所述应用实例(14)的一个或多个延迟缓存(58、60)，其中与所述不符合策略业务相比，所述优先级划分方案通常对所述符合策略业务施加更短的缓存延迟。
9.根据权利要求8所述的方法(500)，还包括：根据在与所述流(22)中的各个流相关联的相应服务水平协议SLA中定义的一个或多个服务参数对所述一个或多个延迟缓存中的聚合应用业务进一步划分优先级，以便满足在所述SLA中的一个或多个中针对所述流(22)所定义的一个或多个最小应用业务参数。
10.根据前述权利要求中任一项所述的方法(500)，其中，所述标记步骤还包括监管步骤，所述监管步骤包括：根据需要对每一个流(22)中的应用业务中的应用消息进行节流或选择性丢弃，以保持与针对所述流(22)的已知相应服务水平协议SLA中保证的最大服务水平符合。
11.一种用于控制单独客户端(12)对软件应用(10)的利用率的装置(28)，其中所述应用(10)被实现为多个对等应用实例(14)，所述多个对等应用实例(14)从多个客户端(12)中的任意一个或多个客户端(12)接收应用业务，并且所述装置(28)被实现在每一个应用实例(14)处并且包括：
分布式业务控制器(30)，被配置为将进入所述应用实例(14)的应用业务分类为与所述客户端(12)中的不同客户端和/或不同类型的应用业务相对应的流(22)，并且关于所述应用实例(14)估计每一个流(22)的本地需求值；以及
通信控制器(32)，被配置为与所述应用实例(14)中的一个或多个其他应用实例交换本地需求信息，包括：发送在所述应用实例(14)处针对所述应用实例(14)处的所述流(22)所估计的本地需求值，以及接收针对在其他应用实例(14)处的所有相似流(22)的相似估计的本地需求值；以及
所述分布式业务控制器(30)被进一步配置为：
基于所交换的本地需求信息来关于所述应用(10)确定每一个流(22)的总体需求值；
根据针对所述流(22)所确定的总体需求值来计算每一个流(22)的本地利用率限制；
根据是否超出所述流(22)的本地利用率限制，将每一个流(22)中的应用业务标记为不符合策略业务或符合策略业务；
确定所述应用实例(14)处的所有流(22)的应用业务的聚合是否超出本地聚合利用率限制；以及
基于是否超出所述本地聚合利用率限制以及对符合策略业务和不符合策略业务的区分，以每一个流和/或聚合流为基础来控制对去往所述应用实例(14)的聚合应用业务的缓存。
12.根据权利要求11所述的装置(28)，其中，所述分布式业务控制器(30)被配置为与所述通信控制器(32)协作以通过以下方式交换所述本地需求信息：经由基于gossip的逆熵协议与所述应用实例(14)中的一个或多个其他应用实例进行通信，所述基于gossip的逆熵协议将所述应用实例(14)中的任意一个应用实例处估计的本地需求值传播到所述应用实例(14)中的所有其他应用实例。
13.根据权利要求11或12所述的装置(28)，其中，所述分布式业务控制器(30)被配置为通过以下至少一项来估计每一个流(22)的本地需求值：对所述应用实例(14)处针对所述流(22)活动的协议会话的数量进行计数；基于在定义间隔内是否已经在所述流(22)中接收到任意一个新的应用业务来估计所述流(22)的预期流速率；以及基于测量所述流(22)中的应用业务的到达速率来估计所述流(22)的预期流速率。
14.根据权利要求11至13中任一项所述的装置(28)，其中，所述分布式业务控制器(30)被配置为通过以下方式来确定每一个流(22)的总体需求值：对针对所述应用实例(14)处的所述流(22)所估计的本地需求值和通过交换所述本地需求信息而获知的针对其他应用实例(14)处的所有相似流(22)所估计的本地需求值进行求和。
15.根据权利要求11至14中任一项所述的装置(28)，其中，所述分布式业务控制器(30)被配置为通过以下方式来计算每一个流(22)的本地利用率限制：计算所述流(22)的本地流速率限制。
16.根据权利要求15所述的装置(28)，其中，所述分布式业务控制器(30)被配置为通过以下方式来计算所述流(22)的本地流速率限制：根据关于所述应用针对所述流(22)的已知总最大流速率限制缩放比例因子来计算所述本地流速率限制，所述比例因子是根据所述流(22)的本地需求值与所述流(22)的总体需求值之比来确定的。
17.根据权利要求15所述的装置(28)，其中，所述分布式业务控制器(30)被配置为进一步通过以下方式来计算每一个流(22)的本地利用率限制：计算所述流(22)的本地突发大小限制。
18.根据权利要求11至17中任一项所述的装置(28)，其中，所述分布式业务控制器(30)被配置为通过以下方式来控制对去往所述应用实例(14)的聚合应用业务的缓存：对一个或多个延迟缓存(58、60)中的聚合应用业务进行缓存，以及根据优先级划分方案清空针对所述应用实例(14)的一个或多个延迟缓存(58、60)，其中与所述不符合策略业务相比，所述优先级划分方案通常对所述符合策略业务施加更短的缓存延迟。
19.根据权利要求18所述的装置(28)，其中，所述分布式业务控制器(30)被进一步配置为：根据在与所述应用实例处的所述流(22)中的各个流相关联的相应服务水平协议SLA中定义的一个或多个服务参数对所述一个或多个延迟缓存(58、60)中的任何聚合应用业务划分优先级，以满足在所述SLA中的一个或多个中定义的一个或多个最小应用业务参数。
20.根据权利要求11至19中任一项所述的装置(28)，其中，连同将每一个流(22)中的应用业务标记为符合策略业务或不符合策略业务一起，所述分布式业务控制器(30)被进一步配置为根据需要对每一个流(22)中的应用消息进行节流或选择性丢弃，以保持与针对所述流(22)的已知相应服务水平协议SLA中保证的最大服务水平符合。
CN201380060597.2A 2012-11-21 2013-09-10 用于控制水平扩展软件应用中的利用率的方法和装置 Active CN104798356B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/683,549 US9112809B2 (en) 2012-11-21 2012-11-21 Method and apparatus for controlling utilization in a horizontally scaled software application
US13/683,549 2012-11-21
PCT/SE2013/051048 WO2014081370A1 (en) 2012-11-21 2013-09-10 Method and apparatus for controlling utilization in a horizontally scaled software application

Publications (2)

Publication Number Publication Date
CN104798356A true CN104798356A (zh) 2015-07-22
CN104798356B CN104798356B (zh) 2018-02-16

Family

ID=49382562

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201380060597.2A Active CN104798356B (zh) 2012-11-21 2013-09-10 用于控制水平扩展软件应用中的利用率的方法和装置

Country Status (7)

Country Link
US (1) US9112809B2 (zh)
EP (1) EP2923479B1 (zh)
CN (1) CN104798356B (zh)
BR (1) BR112015011655A2 (zh)
MX (1) MX340418B (zh)
MY (1) MY172784A (zh)
WO (1) WO2014081370A1 (zh)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104519021B (zh) * 2013-09-29 2018-07-20 新华三技术有限公司 防止恶意流量攻击的方法及装置
EP2919510A1 (en) * 2014-03-10 2015-09-16 Telefonaktiebolaget L M Ericsson (publ) Technique for controlling bandwidth usage of an application using a radio access bearer on a transport network
JP6237397B2 (ja) * 2014-03-27 2017-11-29 富士通株式会社 制御装置、および、通信方法
US10680957B2 (en) 2014-05-28 2020-06-09 Cavium International Method and apparatus for analytics in a network switch
US11838851B1 (en) * 2014-07-15 2023-12-05 F5, Inc. Methods for managing L7 traffic classification and devices thereof
EP3016345A1 (en) * 2014-10-28 2016-05-04 Alcatel Lucent Method and device for controlling a content delivery device
WO2016074759A1 (en) 2014-11-11 2016-05-19 Unify Gmbh & Co. Kg Method and system for real-time resource consumption control in a distributed computing environment
US9871733B2 (en) * 2014-11-13 2018-01-16 Cavium, Inc. Policer architecture
US10182013B1 (en) 2014-12-01 2019-01-15 F5 Networks, Inc. Methods for managing progressive image delivery and devices thereof
US9654483B1 (en) * 2014-12-23 2017-05-16 Amazon Technologies, Inc. Network communication rate limiter
US11895138B1 (en) 2015-02-02 2024-02-06 F5, Inc. Methods for improving web scanner accuracy and devices thereof
US9959152B2 (en) * 2015-02-27 2018-05-01 Matrixx Software, Inc. Adaptive quota management system
US10463957B2 (en) * 2015-03-17 2019-11-05 Amazon Technologies, Inc. Content deployment, scaling, and telemetry
US20160285957A1 (en) * 2015-03-26 2016-09-29 Avaya Inc. Server cluster profile definition in a distributed processing network
US10110458B2 (en) * 2015-10-27 2018-10-23 Nec Corporation VM-to-VM traffic estimation in multi-tenant data centers
US10552768B2 (en) * 2016-04-26 2020-02-04 Uber Technologies, Inc. Flexible departure time for trip requests
KR102424356B1 (ko) * 2017-11-06 2022-07-22 삼성전자주식회사 어플리케이션의 QoS 제어 방법, 장치 및 시스템
EP3776198A1 (en) * 2018-03-27 2021-02-17 Netflix, Inc. Techniques for scheduled anti-entropy repair design
JP7507250B2 (ja) * 2020-05-19 2024-06-27 アビニシオ テクノロジー エルエルシー 分散コンピューティングネットワークにおける通信の最適化
CN112394960B (zh) * 2020-11-23 2024-06-07 中国农业银行股份有限公司 业务流量的控制方法、装置、电子设备和计算机存储介质
CN114884889B (zh) * 2022-07-11 2022-10-14 三未信安科技股份有限公司 一种关于分布式服务的组合限流方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7418494B2 (en) * 2002-07-25 2008-08-26 Intellectual Ventures Holding 40 Llc Method and system for background replication of data objects
CN101491025A (zh) * 2006-07-10 2009-07-22 国际商业机器公司 用于遍布机群进行通信量整形的方法
CN101496005A (zh) * 2005-12-29 2009-07-29 亚马逊科技公司 具有网络服务客户接口的分布式存储系统
CN102498696A (zh) * 2009-07-17 2012-06-13 英国电讯有限公司 数据网络的使用监管

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4009344A (en) * 1974-12-30 1977-02-22 International Business Machines Corporation Inter-related switching, activity compression and demand assignment
US7286474B2 (en) * 2002-07-12 2007-10-23 Avaya Technology Corp. Method and apparatus for performing admission control in a communication network
US7305431B2 (en) * 2002-09-30 2007-12-04 International Business Machines Corporation Automatic enforcement of service-level agreements for providing services over a network
US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
JP5023899B2 (ja) * 2007-09-03 2012-09-12 日本電気株式会社 ストリームデータ制御システム、ストリームデータ制御方法およびストリームデータ制御用プログラム
EP2138972A1 (en) * 2008-06-24 2009-12-30 Nicolas Duchamp Method for automatically classifying money transfers made on a bank account
US8606899B1 (en) * 2012-05-29 2013-12-10 Sansay, Inc. Systems and methods for dynamic session license control

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7418494B2 (en) * 2002-07-25 2008-08-26 Intellectual Ventures Holding 40 Llc Method and system for background replication of data objects
CN101496005A (zh) * 2005-12-29 2009-07-29 亚马逊科技公司 具有网络服务客户接口的分布式存储系统
CN101491025A (zh) * 2006-07-10 2009-07-22 国际商业机器公司 用于遍布机群进行通信量整形的方法
CN102498696A (zh) * 2009-07-17 2012-06-13 英国电讯有限公司 数据网络的使用监管

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROBBERT VAN RENESSE 等: "Efficient Reconciliation and Flow Control for Anti-Entropy Protocols", 《ACM 2008 ISBN:978-1-60558-296-2》 *

Also Published As

Publication number Publication date
MX2015006471A (es) 2015-08-14
MY172784A (en) 2019-12-12
MX340418B (es) 2016-07-08
US9112809B2 (en) 2015-08-18
WO2014081370A1 (en) 2014-05-30
CN104798356B (zh) 2018-02-16
US20140143300A1 (en) 2014-05-22
EP2923479A1 (en) 2015-09-30
BR112015011655A2 (pt) 2017-07-11
EP2923479B1 (en) 2017-06-28

Similar Documents

Publication Publication Date Title
CN104798356A (zh) 用于控制水平扩展软件应用中的利用率的方法和装置
CN109618002B (zh) 一种微服务网关优化方法、装置及存储介质
CN107733689A (zh) 基于优先级的动态加权轮询调度策略方法
CN101009655B (zh) 流量调度方法及装置
CN107995045B (zh) 网络功能虚拟化的可适性服务功能链路径选择方法及系统
US20030200317A1 (en) Method and system for dynamically allocating bandwidth to a plurality of network elements
Ayoubi et al. MINTED: Multicast virtual network embedding in cloud data centers with delay constraints
CN103457881B (zh) 执行数据直通转发的系统
RU2643666C2 (ru) Способ и устройство для управления авторизацией виртуальной очереди вывода, а также компьютерный носитель информации
US11929911B2 (en) Shaping outgoing traffic of network packets in a network management system
Wang et al. Optimizing network slice dimensioning via resource pricing
CN116389491B (zh) 一种云边算力资源自适应计算系统
CN107919982A (zh) 一种dci管理平台及其管理方法
JP2016208195A (ja) パケット中継装置、パケット中継装置におけるコピー機能分散方法。
Liu et al. Revenue maximizing online service function chain deployment in multi-tier computing network
Bruschi et al. Move with me: Scalably keeping virtual objects close to users on the move
CN109862591A (zh) 一种基于Qos空口切片的带宽借用与缓存共享方法
WO2024055780A1 (zh) 算力网络信息通告与路由决策方法、装置及介质
Buzhin et al. Evaluation of Telecommunication Equipment Delays in Software-Defined Networks
Guan et al. Virtual network embedding supporting user mobility in 5G metro/access networks
Chakravarthy et al. Software-defined network assisted packet scheduling method for load balancing in mobile user concentrated cloud
KR20120055947A (ko) 가입자 인지 플로우별 ＱｏＳ 제공 방법 및 장치
CN113810305B (zh) 报文转发方法、装置、转发节点以及计算机可读存储介质
Narman et al. DDSS: Dynamic dedicated servers scheduling for multi priority level classes in cloud computing
Bonald et al. The multi-source model for dimensioning data networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
EXSB Decision made by sipo to initiate substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant