27、面向市场计算的Gridbus中间件-优快云博客

本文链接：https://blog.youkuaiyun.com/mars5/article/details/150756560

面向市场计算的Gridbus中间件

1. 引言

网格旨在利用自主分布式实体合作产生的协同效应，这些效应包括地理上分散的资源（如计算机、数据库、软件和科学仪器）的共享、交换、选择和聚合，以解决科学、工程和商业中的大规模问题。为了使这种合作可持续，参与者需要经济激励，因此“激励”机制应作为设计和开发端到端网格架构的关键参数之一。

Gridbus项目致力于设计和开发面向服务的集群和网格中间件技术，以支持电子科学和电子商务应用。它广泛利用相关软件技术，为应用开发者提供抽象层，隐藏异构资源和底层中间件技术的特性。同时，该项目专注于实现从集群到网格再到对等计算系统的效用计算模型，使用经济模型来有效管理共享资源，促进服务的商品化。Gridbus支持在不同层面实现网格服务的商品化：
- 原始资源层面（如出售CPU周期和存储资源）
- 应用层面（如药物设计应用中的分子对接操作）
- 聚合服务层面（如跨多个领域的服务代理和转售）

Gridbus提供的软件技术涵盖以下类别：
- 基于服务级别协议（SLA）的资源分配的企业网格中间件（Aneka）
- 网格经济和虚拟企业（网格市场目录）
- 网格交易和会计服务（GridBank）
- 网格资源代理和调度（Gridbus Broker）
- 网格工作流管理（Gridbus工作流引擎）
- 网格应用开发工具（可视化参数建模器）
- 网格门户（Gridscape）

2. 架构

Gridbus项目旨在开发软件框架和算法，以实现市场驱动的网格计算环境。资源提供者提供各种资源，其动机是最大化利润和资源利用率。用户的需求是根据自身要求执行应用程序，如访问特定数据集进行处理和/或在截止日期前完成。用户受访问资源的预算限制，可能还受其他因素限制，如对某些存储资源和计算环境的访问限制。用户通过网格资源代理操作，代理根据用户需求和约束发现合适的资源，与资源提供者协商访问权限，执行应用程序并将结果返回给用户。代理与提供者之间的接口通过市场基础设施实现，该基础设施提供提供者目录、会计和银行等功能。

Gridbus软件栈主要分为五层：网格应用层、用户级中间件层、核心网格中间件层、网格结构软件层和网格结构硬件层。网格经济学的概念在每一层都很普遍。在网格应用层，Gridbus项目通过其监控和应用组合网格门户做出贡献，这些门户能够与用户级中间件层的服务无缝交互，包括Gridbus资源代理和工作流引擎。在核心网格中间件层，Gridbus开发了用于企业桌面网格集成（Aneka）、会计（GridBank）、合作资源管理（Grid-Federation）和资源发现（网格市场目录）的软件服务。在网格结构软件层运行的Libra系统支持基于市场的集群计算资源分配。

网格结构硬件层包括属于不同网格资源共享域的各种计算、数据和存储设施。有不同类型的提供者为用户提供不同类型的服务，如计算提供者和存储提供者。计算提供者将高性能计算资源（如超级计算机或集群）租赁给网格环境，这些资源通常由基于队列的调度系统管理。与大多数集群管理系统不同，Libra是一种基于经济的集群调度器，专注于提高每个用户的服务质量（QoS），并且资源可能提供提前预留节点或处理器的功能。存储提供者具有类似的组件，但资源管理功能被存储管理功能取代。提供者还通过会计机制跟踪资源使用情况，以便向用户收费。

Gridbus网格资源代理在面向市场的环境中充当用户代理。代理通过查询网格信息服务（如Globus的网格信息索引服务）发现合适的网格资源，并从市场目录查询市场信息（如价格和报价）。然后，代理识别合适的提供者，进行一对一协商或参与资源份额的拍卖，并在获取的资源份额上调度用户作业，以满足用户的截止日期要求。

当前市场基础设施的主要组件是网格市场目录（GMD）和GridBank。GMD使提供者能够通过注册服务向用户宣传其服务，代理可以查询GMD以查找所需服务并查询其属性（如服务地址、定价和输入方法）。其他信息服务（如GIIS）也可视为市场基础设施的一部分。GridBank是一种会计和微支付服务，为用户和提供者之间的安全支付提供基础设施，还可作为会计和授权机制，只有账户中有足够信用的用户才能与提供者签订合同。

3. 网格资源代理

Gridbus代理是一种高级的面向服务的元调度器，支持计算和数据网格，以及广泛的网格中间件和服务。它能够满足网格应用的许多需求，包括为特定用户应用发现合适的资源、调度作业以满足截止日期以及处理执行过程中可能出现的故障。具体来说，代理为需要分布式网格资源执行的任何应用提供资源选择、作业调度、作业管理和数据访问等功能，处理与运行不同网格中间件的资源的通信、作业失败、资源可用性变化以及不同的用户目标（如在截止日期前完成执行或在一定预算内限制执行）。

3.1 架构

Gridbus代理的设计采用分层架构，包括接口层、核心层和执行层，共同提供面向市场的代理所需的功能。接口层由应用程序编程接口（APIs）和输入文件解析器组成，分别用于外部程序和用户与代理进行通信。资源发现和协商、调度以及作业监控在核心层进行。作业执行通过执行层完成，其中特定于中间件的适配器与目标资源进行通信。

3.2 输入

可以通过多种方式向代理指定用户需求，例如使用代理自己的XPML（扩展参数建模语言）格式。以下是一个使用XPML格式指定用户需求的示例：

<xpml>
    <qos>
        <deadline value="2007-ll-10T19 :30 :"/>
        <budget value="l0000.0"/>
        <optimisation value="COST"/>
    </qos>
    <parametar name="X" type=" integer" domain="range">
        <range from="1" to="10" interval="l"/>
    </parameter>
    <parameter name="time_value" type="integer" domain=" single">
        <single value="3000"/>
    </parameter>
    <job-requirements>
        <property name="estimatedTime" value="60.00"/>
    </job-requirements>
    <task>
        <execute>
            <command value="calc"/>
            <arg valuer="$X"/>
            <arg value="$time_value "/>
        </execute>
    </task>
</xpml>

在这个示例中，qos标签包含用户的QoS要求，如作业必须执行的截止日期和执行预算。用户希望以最低成本完成执行，这由优化值表示。XPML用于指定参数扫描应用程序，其中单个应用程序在一系列参数上执行。参数标签指示参数，任务标签指定要执行的应用程序。目前，代理识别的参数仅包括截止日期、预算和优化值，此类输入的数量仅受代理中调度器功能的限制。

3.3 发现、协商和调度

代理查询资源的能力和可用性，并从网格市场目录（GMD）查询资源成本信息。一旦确定资源，代理可能会与它们进行一对一协商。Gridbus代理能够使用交替报价协议与资源进行双边协商，协商过程包括代理与资源交换提案和反提案，直到双方达成可接受的协议或一方退出流程。以下是一个基于可扩展标记语言（XML）的提前预留资源节点的协商提案示例：

<xml - fragment xmlns: ws =" http: // www.gridbua.org/negotiation/ws">
    <ws : Reward>200.0</ws: Reward>
    <ws : Penalty>50.0</ws: Penalty>
    <ws: Requirements>
        <ws:ReservationRecordType>
            <ws:ReservationStartTime>
                2008-04-01T18:22:00.437+11:00
            </ws:ReservationStartTime>
            <ws:Duration>750000.0</ws:Duration>
            <ws:NodeRequirement>
                <ws:Count>4</ws:Count>
            </ws:NodeRequirement>
            <ws:CpuRequirement>
                <ws: Measure>Ghz</ws :Measure>
                <ws: Speed>2.5</ws:Speed>
                <ws:CpuRequirement>
            </ws:ReservationRecordType>
        </ws:Requirements>
    </xml-fragment>

奖励字段表示提供者提供所需数量资源的收益，惩罚字段表示提供者接受提案但未提供所需资源时需支付的惩罚。此提案要求在2008年4月1日下午6:22开始的750秒内，提供四个最小CPU速度为2.5 GHz的节点。提供者可以修改代理的提案部分内容，创建反提案并作为回复发送。报价和反报价会持续进行，直到一方接受当前提案或完全拒绝。目前，代理只能与Aneka资源管理系统进行协商。

代理根据用户的目标和资源类型支持不同类型的调度。目前，代理可以处理基于时间（1网格美元/秒）或容量（1网格美元/1 MB）定价的计算、存储、网络和信息资源，还可以满足用户的目标，如在预算内实现最快计算（时间优化）或在截止日期内实现最便宜计算（成本优化），适用于计算密集型和数据密集型应用。计算密集型算法基于之前在Nimrod/G中开发的算法，以下是一个用于数据密集型应用的成本时间最小化算法：
1. 对于每个调度间隔，只要有未处理的作业，就重复执行以下步骤。
2. 对于每个作业，找到它依赖的数据文件，并定位这些文件的数据主机。
3. 找到一个数据计算集（由一个用于执行的计算资源和每个涉及文件的一个数据主机组成），该集保证该作业的成本最小。
4. 按成本递增的顺序对作业进行排序。
5. 从排序列表中分配作业，从最便宜的作业开始，直到所有作业都分配完毕或所有计算资源都分配了最大数量的作业。

在时间最小化的情况下，除了步骤2中的标准改为所需的最小执行时间外，遵循相同的启发式方法。该调度算法在澳大利亚分布的资源上进行了评估，使用了一个合成应用程序来传输和处理大型数据文件。实验结果表明，成本最小化调度产生最小的计算和数据传输费用，而时间最小化在最短时间内完成实验。

以下是评估使用的资源信息表：
| 组织 | 机器详情 | 角色 | 成本[G$/(CPU·s)] | 时间成本 | 总执行作业数 |
| — | — | — | — | — | — |
| 墨尔本大学计算机科学系（UniMelb CS） | belle.cs.mu.oz.au; IBM eServer, 4 CPU, 2 GB RAM, 70 GB HD, Linux | 代理主机、数据主机、NWS服务器 | NA（不用于计算资源） | - | - |
| 墨尔本大学物理系（UniMelb Physics） | fleagle.ph.unimelb.edu.au; PC, 1 CPU, 512 MB RAM, 70 GB HD, Linux | 副本目录主机、数据主机、计算机资源、NWS传感器 | 2 | 3 | 94 |
| 阿德莱德大学计算机科学系（Adelaide CS） | belle.cs.adelaide.edu.au; IBM eServer, 4 CPU（仅1个可用）, 2 GB RAM, 70 GB HD, Linux | 数据主机、NWS传感器 | NA（不用于计算资源） | - | - |
| 澳大利亚国立大学（ANU） | belle.anu.edu.au; IBM eServer, 4 CPU, 2 GB RAM, 70 GB HD, Linux | 数据主机、计算机资源、NWS传感器 | 4 | 2 | 2 |
| 悉尼大学物理系（Sydney Physics） | belle.physics.usyd.edu.au; IBM eServer, 4 CPU（仅1个可用）, 2 GB RAM, 70 GB HD, Linux | 数据主机、计算资源、NWS传感器 | 4 | 72 | 2 |
| 维多利亚高级计算伙伴关系（VPAC） | brecca 2.vpac.org; 180节点集群（仅使用头节点）, Linux | 计算资源、NWS传感器 | 6 | 23 | 2 |

网络连接成本表如下：
| 数据节点\计算节点 | ANU | UniMelb Physics | Sydney Physics | VPAC |
| — | — | — | — | — |
| ANU | 0 | 34.0 | 31.0 | 38.0 |
| Adelaide CS | 34.0 | 36.0 | 31.0 | 33.0 |
| UniMelb Physics | 40.0 | 0 | 32.0 | 39.0 |
| UniMelb CS | 36.0 | 30.0 | 33.0 | 37.0 |
| Sydney Physics | 35.0 | 33.0 | 0 | 37.0 |

评估结果总结如下：
| 调度策略 | 总耗时（分钟） | 计算成本（G$） | 数据成本（G$） | 总成本（G$） |
| — | — | — | — | — |
| 成本最小化 | 71.07 | 26,865 | 7560 | 34,425 |
| 时间最小化 | 48.5 | 50,938 | 7452 | 58,390 |

4. 网格市场目录（GMD）

网格被设想为能够创建虚拟组织（VOs）、虚拟企业（VEs）或计算市场。在典型的基于市场的模型VO/VE中，网格服务提供者（GSPs）在市场目录（或目录）中发布其服务，网格服务消费者（GSCs）使用网格资源代理（GRB）通过市场目录识别GSPs，并利用满足其QoS要求的合适资源的服务。

为了实现这一愿景，网格需要支持多样化的基础设施和服务，包括允许创建一个或多个网格市场（GMP）注册表、贡献者将自己注册为GSPs并提供其资源/应用服务、GSPs在一个或多个GMP中发布自己及服务价格，以及网格资源代理发现满足用户QoS要求的资源/服务及其属性（如访问价格和使用限制）的基础设施。

GMD作为虚拟组织中高级服务发布和发现的注册表，使服务提供者能够发布其提供的服务及相关成本，允许消费者浏览GMD以找到满足其QoS要求的服务。GMD的关键组件包括：
- GMD门户管理器（GPM），便于服务发布、管理和浏览，允许服务提供者和消费者使用Web浏览器作为简单的图形客户端访问GMD。
- GMD查询Web服务（GQWS），使应用程序（如资源代理）能够查询GMD，以找到满足作业执行要求（如预算）的合适服务。

这两个组件通过HTTP服务器接收客户端请求，此外，还配置了一个数据库（GMD存储库）来记录网格服务和服务提供者的信息。GMD基于标准的Web服务技术（如简单对象访问协议（SOAP）和XML）构建，因此可以被程序查询，而不受其操作环境（平台独立）和软件库（语言独立）的限制。为了提供额外的透明度，还提供了一个客户端API，使程序能够直接查询GMD，开发者无需关心SOAP细节。Gridbus资源代理与GMD交互，以发现测试平台资源及其高级属性（如访问价格）。

5. GridBank

早期的网格计算和使用场景大多是学术性或探索性的，没有强制执行网格经济机制。随着向多机构生产规模的网格基础设施（如TeraGrid设施）的转变，对网格经济和会计的需求日益增加。为了实现跨多个管理域的资源共享，会计基础设施需要支持明确记录用户身份与资源使用情况。在Gridbus项目的背景下，提供这种服务的基础设施称为GridBank。

GridBank是一个安全的全网格会计和（微）支付处理系统，它在数据库中维护用户（消费者和提供者）的账户和资源使用记录，支持与GSCs的资源代理和GSPs的资源交易者进行交互的协议。它主要用于实现网格经济，也可用于电子商务应用，其服务可在合作和竞争的分布式计算环境中使用。

GridBank可以被视为用于网格会计和支付的Web服务，它使用基于Globus工具包套接字的SOAP，该套接字针对安全性进行了优化。客户端使用与访问网格上其他资源相同的用户代理/组件来访问GridBank，用户代理是用户签署的证书，用于反复向资源验证用户身份，这保留了网格的单点登录策略，避免了反复输入用户密码的需要。使用现有的支付系统无法满足这一策略。

GridBank服务器与网格各组件之间的交互流程如下：
1. GSPs和GSCs首先在GridBank开设账户。
2. 用户向GRB提交应用程序处理要求和QoS要求（如截止日期和预算）。
3. GRB与GSP的网格交易服务（GTS）或网格市场目录（GMD）交互，确定服务成本，然后选择合适的GSP。
4. GRB将用户作业提交给GSP进行处理，并提供其在GridBank的可收费账户ID或从GridBank购买的GridCheque。
5. GSP通过执行用户作业提供服务，GSP的网格资源计量器测量处理用户作业时消耗的资源量。
6. GSP的计费模块向GridBank发送请求，对用户账户进行收费，并传递与收费原因相关的信息（资源使用记录）。

6. Aneka：基于SLA的资源供应

Aneka是一个面向服务的企业网格平台，可使用高级预留实现基于SLA的企业网格资源供应。企业网格利用企业内部网络或互联网上连接的桌面计算机的未使用计算资源，而不影响用户的生产力，从而增加企业内可用的计算资源量，加速应用程序性能。

6.1 Aneka的设计

Aneka是一个基于.NET的面向服务的平台，用于构建企业网格。它设计为支持多种应用模型、持久性和安全解决方案以及通信协议，使得可以在不影响现有Aneka生态系统的情况下随时更改首选选择。要创建企业网格，资源提供者只需在每个选定的桌面节点上启动一个可配置的Aneka容器实例，该容器用于初始化服务，并作为与企业网格其余部分交互的单点。

Aneka容器在单个桌面节点上的设计旨在支持可扩展性，通过提供企业网格节点所需的最少功能，使其轻量级。它提供了包括持久性、安全性（授权、认证和审计）和通信（消息处理和调度）服务的基础架构。Aneka容器中的每个通信都被视为一条消息，通过消息处理/调度器进行处理和调度，该调度器充当前端控制器。Aneka容器托管一个强制的成员目录服务，该服务维护系统中当前活动服务的资源发现索引（如.NET远程地址）。

Aneka容器可以托管任意数量的可选服务，以增强企业网格节点的功能，例如索引、调度、执行和存储服务。这为编排不同类型的网格应用模型提供了一个单一、灵活和可扩展的框架。为了支持可靠性和灵活性，容器中的服务设计为相互独立，一个服务只能通过已知接口与本地节点或其他节点上的其他服务进行交互，这意味着故障服务不会影响其他正常工作的服务和/或容器。因此，资源提供者可以无缝配置和管理现有服务，或向容器中引入新服务。

Aneka为资源提供者提供了实现任何企业网格网络架构的灵活性，实现的网络架构取决于企业网格节点之间服务的交互，因为每个节点上的Aneka容器可以直接与网络上可访问的其他Aneka容器进行交互。企业网格可以具有分散式网络架构（直接连接各个桌面节点）、分层网络架构（连接层次结构中的节点）或集中式网络架构（通过单个控制器连接节点）。

6.2 资源管理架构

在具有集中式网络架构的企业网格中，用户/代理、主节点和执行节点之间的交互如下：
1. 请求预留阶段 ：资源用户（或代表其行事的代理）首先需要提前为未来指定时间所需的资源进行预留。用户/代理通过主节点的预留服务提交预留请求，预留服务通过与执行节点上的分配服务交互，发现企业网格中可用的执行节点。每个执行节点上的分配服务跟踪该节点已确认的所有预留，因此可以检查新请求是否可以满足。通过在每个执行节点而不是主节点分配预留，可以将做出分配决策产生的计算开销分布到多个节点，从而最小化开销，与在单个主节点上累积开销相比。预留服务然后选择所需数量的执行节点，并通知它们的分配服务暂时锁定预留的时隙。在执行节点上的所有必需预留都暂时锁定后，预留服务将预留结果及其价格（如果成功）反馈给用户/代理。
2. 确认预留阶段 ：用户/代理可以确认或拒绝预留，预留服务随后根据情况通知选定执行节点的分配服务锁定或移除暂时锁定的时隙。假设存在一个支付服务，以确保用户/代理有足够的资金，并在预留服务进行最终确认之前成功扣除所需的付款。
3. 执行阶段 ：当预留时间到达时，用户/代理将需要执行的应用程序提交给主节点的调度服务。调度服务在将应用程序调度到执行节点之前，确定任何预留的执行节点是否可用；否则，应用程序将排队等待下一个可用的预留执行节点。每个执行节点上的执行服务在从调度服务接收到应用程序后开始执行，并向调度服务更新执行状态的变化。因此，调度服务可以监控应用程序的执行，并在完成时通知用户/代理。

6.3 分配高级预留

高级预留的分配过程在两个层面进行：每个执行节点的分配服务和主节点的预留服务。这两个服务都设计为支持可插拔策略，以便资源提供者可以灵活地轻松定制和替换不同级别和/或节点的现有策略，而不会干扰整体资源管理架构。

分配服务确定如何在执行节点上调度新的预留。为了简单起见，每个执行节点上的分配服务可以实现相同的时隙选择策略。如果请求的时隙可用，则分配该时隙；否则，分配请求开始时间之后下一个可用的、能够满足所需持续时间的时隙。

预留服务进行节点选择，从执行节点中选择所需数量的可用时隙，并通过接受或拒绝预留请求来进行准入控制。它还根据实施的定价策略计算确认预留的价格，可以实施各种定价策略。根据用户的应用程序要求选择可用的时隙。

考虑的应用程序要求是执行应用程序的任务并行性。顺序应用程序只有一个任务，因此需要单个处理器运行，而并行应用程序需要所需数量的处理器同时运行。
- 对于顺序应用程序，选择的时隙不需要具有相同的开始和结束时间，因此首先选择价格最低的可用时隙。如果有多个价格相同的可用时隙，则首先选择开始时间最早的时隙。这确保了如果最便宜的请求时隙可用，则首先分配该时隙。首先选择价格最低的可用时隙是公平和现实的，实际上，较早确认的预留享有更便宜价格的特权，而较晚到达的预留请求则不然。
- 对于并行应用程序，所有选择的时隙必须具有相同的开始和结束时间。同样，首先分配最早的（具有相同开始和结束时间）时隙，以确保如果请求的时隙可用，则首先分配该时隙。如果可用的（具有相同开始和结束时间）时隙数量超过所需的时隙数量，则首先选择价格最低的时隙。

准入控制根据用户的服务要求进行操作，检查的服务要求是完成应用程序的截止日期和预算。假设截止日期和预算都是硬约束，因此确认的预留不能在截止日期之后结束，并且成本不能超过预算。因此，如果执行节点上没有足够的在截止日期内结束的可用时隙，并且预留的总成本超过预算，则不接受预留请求。

6.4 性能评估

使用包含33台个人计算机（PC）的企业网格进行性能评估，其中包括1个主节点和32个执行节点，这些节点分布在墨尔本大学计算机科学与软件工程系的三个学生计算机实验室中。通过利用跟踪数据创建合成工作负载，实验使用了Feitelson的并行工作负载存档中SDSC SP2跟踪（1998年4月 - 2000年4月）版本2.2的最后7天中的238个预留请求。选择SDSC SP2跟踪是因为它在可用跟踪中具有最高的资源利用率（83.2%），可以理想地模拟重负载场景。

由于跟踪只提供了预留请求的到达间隔时间、要预留的处理器数量以及要预留的持续时间，而没有服务要求信息，因此采用了类似的方法通过两个请求类（低紧急性和高紧急性）来合成分配服务要求。

评估了七种定价机制在企业网格中对高紧急性预留请求（短截止日期和高预算）的顺序应用程序（需要一个处理器执行）的性能。企业网格仅根据每个处理器（CPU）每小时（h）的使用情况向用户收取计算资源类型的费用，用户不支付其他资源类型（如内存、存储和带宽）的费用。此外，如果请求的预留时隙不可用，每个用户/代理肯定会接受企业网格提出的另一个预留时隙，只要该时隙仍然满足用户的应用程序和服务要求。

七种定价机制代表了三种基本类型的定价机制：
- 固定（Fixed） ：在所有时间收取固定价格。
- 固定时间（FixedTime） ：对不同的资源使用时间段收取固定价格，非高峰时段（凌晨12点 - 下午12点）收取较低价格，高峰时段（下午12点 - 凌晨12点）收取较高价格。
- Libra + $ ：使用更细粒度的定价函数，满足防止工作负载过载的资源定价的四个基本要求：灵活性、公平性、动态性和适应性。每个计算节点j上预留请求i使用的每单位资源的价格Pij计算为Pij = (a × PBasej) + (b × PUtilij)。基础价格PBasej是在节点j使用资源的静态定价组件，资源提供者可以使用它来收取最低价格以收回运营成本。利用率价格PUtilij是一个动态定价组件，根据节点j上资源在请求i的所需截止日期内的利用率，作为PBasej的一个因子计算：PUtilij = RESMaxj / RESFreeij × PBasej。RESMaxj和RESFreeij分别是节点j上资源在请求i的截止日期持续时间内的最大单位数和剩余可用单位数，因此，RESFreeij已经扣除了为其他确认的预留和请求i在其截止日期持续时间内承诺的资源单位数。

评估结果表明，在企业网格中对高紧急性请求的顺序应用程序进行为期7天的评估中，四种固定定价机制中，FixedMax提供最高的收入（最大界限），其次是FixedTimeMax、FixedTimeMin和FixedMin（最低收入，最小界限）。然而，FixedTime机制比Fixed机制更容易推导且更可靠，因为它支持资源使用不同时间段的价格范围，但所有四种机制都不考虑用户的服务要求（如截止日期和预算）。

另一方面，Libra + $对截止日期较长的请求收取较低的价格，以鼓励用户提交截止日期较长的请求，这些请求比截止日期较短的请求更有可能得到满足。对于截止日期较短的请求，Libra + $Max和Libra + $Min根据其b值收取较高的价格，由于b值较高，Libra + $Max提供的收入比Libra + $Min更高。

Libra + $Auto和Libra + $Max都能够通过对较短截止日期收取更高的价格，提供比其他定价机制显著更高的收入。当需求高时（如第1、2、3和5天的后半段），Libra + $Auto继续提高价格，高于Libra + $Max和其他定价机制；但当需求低时（如第2、3、5和6天的前半段），它继续降低价格，低于Libra + $Max，以接受不愿意支付更高价格的请求。因此，Libra + $Auto能够利用预算限制，通过在节点可用性低时自动调整到更高的b值来提高价格，在有更多未使用节点时调整到更低的b值来降低价格，从而实现最高的收入。

7. 网格联盟（Grid-Federation）

随着企业网格的发展，资源数量大幅增加，集中式管理模型的弊端逐渐显现。它不仅难以应对大量组件的协调和消息处理，还缺乏容错能力，需要昂贵的服务器硬件支持。而且，网格参与者的动态加入和退出，使得集中式管理几乎无法实现。因此，需要一种高效的分布式解决方案，以适应不断变化的环境。网格联盟通过将资源集划分为较小的部分，再将它们联合起来，形成一个合作的分布式资源共享环境，从而解决了这些问题。

7.1 网格联盟的特点

网格联盟在管理分布式网格计算环境时面临着独特的挑战，具体特点如下：
- 分布式所有权 ：每个参与者独立做出决策。
- 开放和动态 ：参与者可以随意加入或离开系统。
- 自利性 ：每个参与者有不同的利益和目标。
- 大规模 ：由众多分布式参与者组成，形成庞大的环境。
- 资源竞争 ：由于资源需求模式和用户之间缺乏合作，特定资源可能会因过度负载而降低系统效用。

为了克服这些挑战，网格联盟的设计聚焦于分布式资源发现系统和基于市场的资源分配系统。它允许合作共享拓扑和管理上分布的网格资源，并通过实例化网格联盟代理（GFA）来实现基于策略的透明资源共享。GFA负责资源共享、选择和报告等活动，并通过分布式哈希表（DHT）覆盖网络相互连接，实现系统的可扩展性和去中心化。

7.2 资源发现

网格联盟的分布式资源发现服务允许GFA高效地搜索符合用户QoS参数的可用资源。该服务通过在DHT覆盖网络上维护一个逻辑多维发布/订阅索引来组织信息。GFA主要进行两种类型的查询：
- 资源查找查询（RLQ） ：用于定位符合用户应用QoS要求的资源。
- 资源更新查询（RUQ） ：由GFA代表网格站点所有者向资源发现服务发送，用于更新底层资源的状态。

由于网格资源由多个属性标识，RLQ和RUQ通常是多维的，并且可以指定不同类型的属性值约束，包括点查询和范围查询。资源提供者可以通过RUQ定期更新资源状态，这些查询通过多维发布/订阅索引映射到DHT覆盖网络。该索引基于网格资源属性构建多维笛卡尔空间，并将空间区域分配给GFA，GFA负责处理与该区域相关的RLQ和RUQ活动。

此外，资源发现服务还支持对等协调/合作空间的抽象，参与者可以在其中进行协作。在Aneka - 联盟软件系统中，Aneka对等服务负责去中心化资源发现和协调，FreePastry结构化对等路由基板促进了动态资源和调度信息的路由。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    A(用户):::process -->|提交应用| B(GFA - 站点 s):::process
    B -->|发送RLQ| C(资源发现服务):::process
    D(GFA - 站点 p):::process -->|发送RUQ| C
    C -->|匹配通知| B
    B -->|SLA协商| D
    D -->|同意SLA| B
    B -->|部署作业| D

7.3 资源市场

网格联盟以计算经济为基础，促进参与者之间的分布式合作。它采用去中心化的商品市场模型，为资源分配和应用调度提供支持。在这个模型中，每个资源都有基于需求、供应和价值的价格，资源提供者向用户收取访问成本，用户则表达自己的预算和截止日期要求。

参与者通过GridBank等会计系统管理虚拟或真实信用。网格联盟的调度方法考虑了资源提供者的目标和用户的QoS约束，通过SLA - 基于的协调和协商协议实现资源的有效分配。该协议包括QoS查询和QoS保证消息的交换，SLA是资源提供者对远程作业调度器的承诺，确保在指定的截止日期和预算内完成作业。

SLA - 基于的作业调度具有以下显著优势：
- 促进参与者之间的合作。
- 避免资源过度负载。
- 确保用户获得承诺的QoS。
- 减少作业排队和处理延迟。
- 增强每个站点对本地资源分配的自主性和控制。

在网格联盟中，GFA根据作业的资源配置要求进行一对一的合同协商，分别扮演经理和承包商的角色。调度和资源分配过程如下：用户向本地GFA提交应用，GFA发送RLQ查询资源，其他GFA更新RUQ报告资源状态。当RUQ与RLQ匹配时，GFA进行SLA协商，如果达成协议，则部署作业。

7.4 性能评估

为了评估网格联盟系统的性能，进行了一系列模拟实验，重点测试资源发现和资源市场服务的效率、可扩展性和可用性。实验环境结合了GridSim和PlanetSim两个离散事件模拟器构建。

7.5 结果与讨论

通过以下指标衡量网格联盟系统的性能：
- 资源发现延迟 ：指从发送RLQ到找到符合要求的资源所需的时间。
- 作业响应时间 ：包括RLQ映射、等待匹配、SLA协商和作业执行的总时间。
- 提供者总激励 ：提供者因执行本地和远程作业获得的总收入。

实验结果表明：
- 在RUQ更新间隔较长且RLQ请求率较高时，资源发现延迟增加。这是因为大量竞争请求导致RLQ需要更长时间等待RUQ匹配，同时为避免资源竞争，分配过程也会更加谨慎。
- 提供者的总激励在不同RLQ和RUQ速率下基本相似，这是由于模拟期间资源访问成本保持静态。但实际上，提供者可以根据供需动态调整价格。
- 作业响应时间与资源发现延迟趋势相似，在RLQ到达延迟较长时，作业面临的资源发现延迟较低，因为此时网络流量和竞争请求较少。