Energy-Cost Aware Scheduling/Forecasting Competition

摘要

在本说明中，我们描述了有关能源成本感知云计算的预测/调度竞赛的设置、规则和格式，计划在科克举行的 CP-AI-OR 2014 和里昂的 CP2014 举行。 我们讨论了预测和调度问题，提出了问题的数学公式，并定义了使用的数据格式。 参与者可以通过提供在现有调度系统上评估的价格预测、基于给定价格预测的调度系统或通过提供预测和调度工具的组合来决定参与。 解决方案的质量是通过所产生的计划的总实际成本来评估的。

1 背景

我们考虑以下问题：您正在运行云计算服务，客户在其中签订合同以运行计算服务（任务）。 每个任务都有一个持续时间、最早开始和最晚结束，以及以 CPU、内存和 I/O 属性的整数值表示的资源需求。 任务可以安排在多台服务器中的一台上，每台服务器的 CPU、内存和 I/O 属性的容量都是有限的。 如果所有属性的总资源消耗低于各自的容量，则多个任务可以在同一台机器上同时运行。 所有任务都必须在其发布日期和截止日期内安排，这些日期的设置是为了使两天之间没有任务超过午夜。 任务不能被中断，一旦开始，它们必须运行给定的持续时间。
如果一台机器被一个任务使用，它必须在那个时候运行。 除了运行分配的任务的成本外，如果机器处于开启状态，它还会消耗一些空闲电量。 每次打开或关闭机器时，都会启动一次。 必须支付停工费用。 所有机器在计划期开始时都关闭，所有机器必须在计划期结束时关闭。
数据中心的电价是实时价格，全天变化。 实际价格事先不知道，必须使用预测来生成时间表。 通过将实际电价应用于每个时间段的能源消耗，事后确定时间表的总成本。 组织者给出了一种价格预测。 图 1 显示了预测与实际价格之间的差异示例，提供了基于历史数据生成更好预测的机会需求和价格数据，以及之前的预测信息。 请注意，具有低误差的预测并不能自动保证导致总成本低的计划。
目标是在一定的时间限制内生成具有最低总实际成本的计划。
比赛分为三个类别： 1. 您使用提供的价格预测来生成您的最佳时间表。
所有的任务都必须有计划，计划的成本由实际的电价给出。 生成的计划的有效性和成本由解决方案检查器测试。
2. 您生成自己的价格预测，并使用提供的调度系统生成调度。 解决方案的成本将取决于您的价格预测质量。
3. 您生成价格预测和调度系统。 您提供一个时间表，其成本将由解决方案检查员确定。

2 调度问题

在本节中，我们将介绍比赛日程安排部分的正式描述。
2.1 符号
模型中定义了以下按字母顺序排序的实体。
c mr 机器 m 的资源容量 r
dj 任务的持续时间 j
关闭 m 服务器的关闭成本 m
ej 最早的任务开始 j
ft 预测时间段 t 的电价
idle m 服务器的空闲成本 m
j 任务索引
lj 最晚的任务结束 j
m 机器索引
pj 任务的功耗 j
q 时间分辨率
r 资源索引
rt 时间段内的实际电价 t
t 时间索引
u jr 任务 j 的资源使用 r
up m 服务器的启动成本 m
v mt 服务器 m 在时间 t
x 运行 jmt 任务 j 在时间 t
y 在机器 m 上启动 mt 服务器 m 在时间 t
z 启动 mt 服务器 m 在时间 t 关闭
2.2 集合和索引
我们在模型中使用以下对象集：
J 一天安排的一组任务。 所有给定的任务必须在当天完成，任务不能被拒绝。
T 一天中的一组时间段。 我们考虑 q 分钟的时间分辨率，即一天中有 1440/q 个时间段。
M 考虑的服务器集
R 考虑的资源集
我们还尝试在描述中使用一致的索引：
j 任务索引范围
t 时间段索引范围
m 服务器（机器）索引范围
r 资源范围索引
2.3 常量
q 调度模型中的时间分辨率。 该值是以分钟为单位的整数，即有 |T | = 24 * 60/q + 一天中的 1 个时间段。
d j 任务 j 的持续时间，值是小于或等于 |T | 的正整数。
持续时间给出了任务的长度，因此结束是开始加上持续时间。 该任务在其结束时不被视为活动。
e j 任务 j 的最早开始，值是 0 到 |T | 之间的整数。
l j 任务 j 的最新结束，取值为 0 到 |T | 之间的整数。 这个最新的结束对应于 l j - d j 的最新开始。
u jr resource use for task j for resource r，这是一个正整数值。
p j 任务 j 的功率使用，在任务执行期间功率使用是恒定的。
这是一个非负整数值。
c mr 服务器 m 对资源 r 的容量，这是一个正整数。
idle m 运行服务器 m 一个时间段的空闲功率，这是一个非负整数。
增加服务器 m 的启动成本。 启动机器 m 一次的成本。 此成本不取决于此时的能源成本。 该值是一个非负浮点数。
down m 服务器 m 的关闭成本。 关闭服务器一次的成本。
该成本不依赖于停机时的能源成本。 这些值是一个非负浮点数。
f t 这是时间段 t 内一单位能源的预测价格。 这是一个浮点数，可以为零甚至负数。
r t 时间段 t 内一单位能源的实际价格。 这是一个浮点数，可以为零甚至负数。 此信息不能用于制定调度决策，仅用于评估结果调度。
2.4 模型
我们现在描述模型的变量、约束和目标。
2.4.1 变量
x jmt 任务 j 在机器 m 上的时间 t 开始。 一个 0/​​1 整数变量，指示任务运行的时间和地点。 由于必须安排每个任务，因此必须将链接到任务的变量之一设置为一个。
v mt 服务器 m 在时间 t 运行。 如果任何任务在某个时间 t 在机器上运行，则该机器必须处于活动状态。
y mt 机器 m 在时间 t 启动。 最初，所有机器都关闭。
z mt 机器 m 在时间段 t 后关闭。 机器在时间 t 处于活动状态，但不是在时间 t + 1。所有机器必须在调度范围结束时关闭。
2.4.2 约束
我们首先需要强制每个任务都安排在一台机器上，恰好一次：
公式1
在最早开始之前不能安排任何任务：
公式2
不能安排任何任务在其最近结束后结束：
公式3
在同一台机器上同时调度的所有任务的资源需求必须在机器的容量范围内：
公式4
以下约束都链接了与机器相关的不同类型的变量。
如果一台机器在时间 t 开始，那么我们认为它在这个时间运行。
公式5
如果一台机器在时间 t 启动，那么它在时间 t - 1没有运行。

6

如果一台机器在时间 t 关闭，那么它此时仍在运行。

7

如果一台机器在时间 t 关闭，那么它在时间 t + 1 没有运行。

8

如果任务在某台机器 m 上的时间 t 开始，那么该机器必须至少在任务运行时处于活动状态，即对于从 t 到的所有时间点

9

如果一台机器在时间 t 运行，那么它要么已经在时间 t - 1运行，要么它在时间 t 启动。

10

如果一台机器在时间 t 运行，那么它要么也在时间 t + 1 运行，要么在时间 t 关闭。

11

2.4.3 目标函数

目标是最小化运营总成本，包括运行所有任务的能源成本 c J 、服务器处于活动状态时运行的成本 c M 、服务器启动成本 c up 和服务器关闭成本c 下来。这意味着我们最小化以下函数

12

运行所有任务的能量成本由总和给出

13

请注意，我们必须通过乘以时间段的持续时间（以小时为单位）将任务的功率使用转换为能量值。由于我们不’知道电力RT的实际成本创建计划时，我们可能会在优化使用的预测价格，而不是英尺。这可能意味着预测的最佳解决方案对于实际价格并不是最佳的。但对解决方案质量的最终评估将以实际价格为准，这是事后才知道的。

运行服务器的能源成本（忽略任务的成本）是

由

14

启动成本由总和给出

15

关闭成本由总和给出

16

2.5 数据格式

调度问题以以下文本文件格式给出。中的数字

括号给出值的典型大小。

时间_分辨率 (5)

Nr_of_Resources n (3)

Nr_of_Machines (>20)

Machine[k 1…Nr_of_Machines] 空闲起来

资源_1 资源_2 …资源_n

Nr_of_Tasks (> 2000)

任务[j 1…Nr_of_Tasks] 持续时间最早_开始最新_结束功率

资源_1 资源_2 …资源_n

持续时间、最早开始和最晚结束以 q 分钟的倍数的整数形式给出，总范围从 0 到 1440/q。除成本外的所有值都是整数，数字由一个或多个空格字符分隔。

价格数据由以下文件格式给出：

期数 (288)

Period[l…nr_of_Periods] 成本 [欧元/千瓦时]

价格以浮点数形式给出。必须以相同的格式生成预测价格解决方案。

生成时间表，列出每个任务的机器和开始时间：

Nr_machines

机器[m 1…Nr_Machines]

Nr_events

开/关[1/0] time_period

Nr_of_Tasks (> 2000)

任务[j 1…Nr_of_Tasks] 机器启动

开始时间以当天午夜起的时间段给出，以倍数形式给出

q。

2.6 数据格式的替代描述

本节介绍各种组件的数据格式。第一部分描述了调度问题的格式，第二部分描述了能源价格的格式，最后一部分描述了调度解决方案的格式。示例数据在每个部分旁边给出，并缩进以表示重复的部分。价格以浮点数形式给出。所有时间都是从当天午夜开始的时间段，以 q 的倍数给出。

2.6.1 调度问题

调度问题以以下文本文件格式给出，并用一些示例值说明。前两行包含一个整数，每个整数表示 q 和资源数 |R| 分别。

q 5

nr_of_resources 3

下一行输入包含一个整数，表示机器的数量 |M | 可用的。对于每台机器，我们定义两行输入。

第一行包含标识符 m ，后跟三个数字，分别表示空闲 m 、向上 m 和向下 m 。idle m 是机器 m 在运行时的能量使用率，单位为瓦特。上 m 和下 m 均以欧元成本给出。第二行包含 |R| 代表机器m的各自资源容量c mr 的整数。

nr_of_machines 20

m idle_m up_m down_m 0 50 1.0 1.0

c_m0 c_m1 c_m2 92 71 63

下一行包含一个整数 |J|，要调度的任务数。每个任务后面跟着两行。第一个描述任务 ID、dj、ej 和 lj。第二行包含任务 u jr 的资源需求。

nr_tasks 100

task_j d_j e_j l_j p_j 0 13 185 219 142.0

u_j1 u_j2 u_j3 16 18 29

2.6.2 能源价格数据

本节描述将提供的能源价格预测的格式。必须以相同的格式生成预测价格解决方案。

第一行包含一天中的时间段数，其值为 1440/q。接下来的 1440/q 行将包含两个数字：时间段的索引，后跟代表该时间段能源价格的小数。

nr_of_periods 288

t_0 [f_0|r_0] 0 0.04331

t_1 [f_1|r_1] 1 0.04331

2.6.3 调度方案

调度问题的解决方案应该以表示机器数量|M| 的整数开始。下一个 |M | 行应该包含机器的索引和与机器关联的开/关事件的数量，nr_events。接下来的 nr_events 行应该包含两个整数，动作和时间段 t。如果机器应在时间段 t 关闭（开启），则动作应为 0 (1)。所有机器最初都是关闭的，并且在一天结束时也应该关闭。

下一行应该包含一个代表任务数量的整数，|J|。下一个|J| 行应该包含三个整数：索引任务 j、它应该分配到的机器 m 以及该机器上任务的开始时间。

nr_machines 20

machine_m 0

nr_events 2

开/关[1/0] time_t 1 0

开/关[1/0] time_t 0 287

nr_of_tasks 100

task_j 机器启动 0 4 256

2.6.4 示例实例

为了说明数据格式，下面给出了具有 1 台机器、3 个资源和 10 个任务的完整示例实例。

5

3

1

0 100 1.0 1.0

122 135 107

10

0 8 206 265 0.03

10 9 9

1 5 7 67 0.59

10 9 9

2 44 83 153 0.10

10 9 9

3 37 202 275 0.55

9 10 9

4 37 216 274 0.29

10 9 9

5 6 28 105 0.21

10 9 9

6 19 46 228 0.64

9 9 10

7 15 230 279 0.27

9 9 9

8 24 173 234 0.25

10 9 9

9 13 160 277 0.51

9 9 10

此实例的调度解决方案是：

1

0

2

1 0

0 287

10

0 0 256

1 0 61

2 0 83

3 0 237

4 0 236

5 0 41

6 0 53

7 0 263

8 0 174

9 0 263

3 预测问题

在预测问题中，我们必须根据历史和预测数据来预测未来一天的实际电价。历史数据可从 2011 年 9 月起获取。缺失值用 NaN 标记。定义了以下字段：

DateTime String，定义采样的日期和时间

假日字符串，如果一天是银行假日，则给出假日名称

HolidayFlag 整数，如果一天是银行假日则为 1，否则为零

DayOfWeek 整数 (0-6)，0 星期一，星期几

WeekOfYear 整数，在该日期的一年内运行一周

日期整数，日期的天数

月份整数，日期的月份

年份整数，日期的年份

PeriodOfDay 整数，表示一天中的半小时周期 (0-47)

WindForecast 这一时期的预测风力发电量

LoadForecast 本期全国负荷预测

PriceForecast 本期价格预测

温度在科克机场测量的实际温度

Windspeed 在科克机场测得的实际风速

CO2Intensity 电力项目的实际 CO2 强度（g/kWh）

引出

ActualWind 此期间的实际风能产量

ActualLoad 本期实际全国系统负载

ActualPrice 本期实际价格，待预测值

最后四个字段仅可用于历史数据，即它们不能用于进行预测。

下面显示了可用历史数据的示例日期，以 # 开头的标题行描述字段是数据文件的第一行：

数据

.

.

请注意，预测问题使用与调度问题不同的时间分辨率，将提供两种格式之间的自动接口。

4 评价

报名和公开排行榜可在挑战网站上获得：http://iconchallenge.insight-centre.org 每个团队每个类别只能提交一个求解器，但您可以向在线排行榜提交解决方案，每个实例每天最多 3 次. 个人不得参加多个团队。ICON 组的成员可以参加，但他们的团队没有资格获得奖品。

排行榜 排行榜将在整个比赛期间在线发布。为此，团队只需提交他们已解决的任何实例的解决方案输出。鼓励团队在整个比赛期间定期提交他们的解决方案。2014 年 6 月 9 日至 8 月 15 日期间，最长排名第一的团队将获得奖励。

日期 公开排行榜的提交将于 2014 年 6 月 9 日开放；排行榜提交的截止日期是 2014 年 8 月 15 日 23:59 UTC12。团队将被要求在 2014 年 8 月 17 日 UTC-12 之前提交他们的源代码，这将在 50 个看不见的实例上进行评估。这些实例在性质上类似于公共排行榜集。结果展示将于9 月8 日至12 日在法国里昂举行的 CP 2014 上进行。

环境提交将在具有两个英特尔至强处理器 E5-2640 2.5GHz（12 核、24 线程）和 64GB RAM 的机器上运行。如果解决方案需要任何第三方工具，则它们必须免费提供，至少在学术许可下。对于仅计划和仅预测类别，解决方案将被限制为每个实例 5 分钟（300 秒）的挂钟时间，对于组合预测和计划类别，此限制为 10 分钟（600 秒）挂钟时间。这些限制仅适用于离线评估，不适用于公开排行榜提交。

排名 团队根据所有实例的实际能源成本进行排名。仅预测类别的条目将用于提供参考调度程序，并将按生成的调度排序。排名不考虑求解器的运行时间，最重要的是在时限内解决实例，其次是解决方案的相对质量。在这个评分系统中，越低越好。

使用实际能源价格数据而不是预测的能源价格为每个实例计算目标函数。如果没有求解器为实例提供解决方案，则不考虑对该实例进行评分。如果一个求解器未能解决一个实例而其他求解器这样做了，它的分数等于解决该实例的求解器的数量。相对于实例的难度，这会惩罚求解器。如果只有一个求解器解决了一个实例，则其得分为零。

在多个求解器求解一个实例的情况下，它们的相对分数计算如下。令 S 为实例的解决方案集，其中 si ∈ S 是求解器 i 的目标值（使用实际能源价格数据）。

如果所有目标值都相等，那么每个求解器的得分为零，否则让α = min sj ∈ S sj 是最好的，而β = max sj ∈ S sj 是所有求解器中最差的目标值。然后，求解器 i 为实例获得的相对分数为：