在OpenLava中探索Fairshare调度
来源:互联网 发布:自学编程入门 编辑:程序博客网 时间:2024/06/03 21:22
分享的好处非常明显。无论我们是共享一杯苏打,公寓还是HPC集群,分享都可以降低我们的费用。
OpenLava 的功能之一是fairshare调度。对于不熟悉fairshare调度的用户,这个新特性指的是根据策略共享资源。如果一个集群花费了一百万美元,而部门A贡献了800,000美元,而部门B贡献了200,000美元,基于80/20(当有争用时)共享资源可能被认为是公平的。Fairshare不意味着“平等份额” – 但它的意思是根据政策分享,通常与现有资源成比例。A部门可能有不同级别的员工。如果我的首席科学家和实习生之间的资源冲突,我可能需要一些措施,以确保聪明的实习生不能垄断集群,留下我的首席科学家无所适从。同时我也想测试一下层次共享。
OpenLava获取Fairshare
Fairshare调度在IBM Platform LSF中已存在多年,在OpenLava中,开源调度程序添加了此功能。为了演示共享场景,我将OpenLava设置如下:
首先,一个OpenLava配置文件中,我定义了两组用户。即我公司有工作人员和合作伙伴。我为他们各自设置一个组,并声明每个组的成员。三名工作人员将以1:1:1的比例共享资源,合作伙伴组的两名成员将共享平等分配的资源,如果有需要的话,我还可以选择不同的比率。这代表我的“部门内分享”政策。
Begin UserGroup
GROUP_NAME GROUP_MEMBER USER_SHARES
#G1 (david john zebra) ([david, 1] [john,1] [zebra, 1])
#G2 (crock wlu kluk) ([crock, 2] [wlu,1] [kluk,1])
staff (william david james) ([wlu, 1] [david, 1] [james, 1])
partners (gord dan) ([gord, 1] [dan, 1])
End UserGroup
我们在lsb.users的配置中添加一个附加约束。我不想任何时候,我的任何合作伙伴单独消耗超过五个集群中的五个位置(意味着他们最多同时在集群主机上运行五个作业)。语法partners @表示限制适用于组的每个成员。
Begin User
USER_NAME MAX_JOBS JL/P
#develop@ 20 8
#support 50 –
partners@ 5 –
End User
接下来,我们定义一个称为“共享”的队列,它将在我们的两组用户(员工和合作伙伴)之间实施分配策略。这是在lsb.queues中完成的,语法如下。每分配给员工三个位置,合作伙伴只能获得一个 – 这意味着我们的员工将在保证的基础上获得75%的资源 – 如果没有合作伙伴提交工作,这个比例甚至会更大。
Begin Queue
QUEUE_NAME = share
PRIORITY = 30
NICE = 20
DESCRIPTION = Queue to demonstrate fairshare scheduling policy
FAIRSHARE = USER_SHARES[[staff,3] [partners,1]]
End Queue
模拟作业
接下来,为了产生合理的工作量,我们编写了一个脚本,将代表五个用户提交工作 – 其中三个是“工作人员”,两个是“合作伙伴”。为了增加可信度,我们生成了一个工作负载,每个用户有1,000个作业,总计5000个作业。每个作业将需要10秒钟。以10秒为单位的5,000个作业的工作负载,如果在单个计算机上运行理想情况下将花费50,000秒或138.9小时。因为我们的集群允许我们同时运行40个作业(我们有40个作业插槽配置,如下所示),我们的理论时间减少到3.47小时,几乎正是我实际调整工作量和写这个博客所需要的时间。
下面是OpenLava bhosts命令,显示我们的四个群集主机上的可用调度插槽。
[root @ ip-172-31-34-75〜]#bhosts
HOST_NAME状态JL / U MAX NJOBS运行SSUSP USUSP RSV
ip-172-31-34-75 ok – 10 0 0 0 0 0
ip-172-31-35-144 ok – 10 0 0 0 0 0
ip-172-31-35-97确定 – 10 0 0 0 0 0
ip-172-31-46-36 ok – 10 0 0 0 0 0
[root @ ip-172-31-34-75〜]#
鉴于此集群配置和共享策略,下一步是向代表我们五个用户的定义提交5,000工作量。这个脚本的作用是提交工作数组,每个用户一个,每个包含1,000个作业。
#!/ bin / sh
sudo -u gord -i bsub -q share -J“gordArray [1-1000]”sleep 10
sudo -u dan -i bsub -q share -J“danArray [1-1000]”sleep 10
sudo -u william -i bsub -q share -J“williamArray [1-1000]”sleep 10
sudo -u david -i bsub -q share -J“davidArray [1-1000]”sleep 10
sudo -u james -i bsub -q share -J“jamesArray [1-1000]”sleep 10
我们执行脚本,通过运行脚本将这5,000个耗时10秒的作业提交到我们的集群。
[root@ip-172-31-34-75 ~]# ./fairshare_demo.sh
Job is submitted to queue .
Job is submitted to queue .
Job is submitted to queue .
Job is submitted to queue .
Job is submitted to queue .
几分钟后,我们发出一个命令来查看我们的5000个作业,以了解它们的状态以及它们是如何被分配给群集主机的。显然,运行的作业正是我们所期望的比例。我们的每个员工有10个运行工作,总共30个工作(75%的插槽) – 我们的两个合作伙伴,相比之下每个运行5个工作,总计25%的插槽。
[root@ip-172-31-34-75 ~]# bjobs -u all | more
JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[1] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[2] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[3] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[4] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[5] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[6] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[7] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[8] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[9] Mar 15 16:10
313 william RUN share ip-172-31-3 ip-172-31-3 *Array[10] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[1] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[2] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[3] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[4] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[5] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[6] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[7] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[8] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[9] Mar 15 16:10
314 david RUN share ip-172-31-3 ip-172-31-4 *Array[10] Mar 15 16:10
311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[1] Mar 15 16:10
312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[1] Mar 15 16:10
311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[2] Mar 15 16:10
312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[2] Mar 15 16:10
311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[3] Mar 15 16:10
312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[3] Mar 15 16:10
311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[4] Mar 15 16:10
312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[4] Mar 15 16:10
311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[5] Mar 15 16:10
312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[5] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[1] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[2] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[3] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[4] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[5] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[6] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[7] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[8] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[9] Mar 15 16:10
315 james RUN share ip-172-31-3 ip-172-31-3 *Array[10] Mar 15 16:10
311 gord PEND share ip-172-31-3 *dArray[6] Mar 15 16:10
311 gord PEND share ip-172-31-3 *dArray[7] Mar 15 16:10
311 gord PEND share ip-172-31-3 *dArray[8] Mar 15 16:10
311 gord PEND share ip-172-31-3 *dArray[9] Mar 15 16:10
311 gord PEND share ip-172-31-3 *Array[10] Mar 15 16:10
311 gord PEND share ip-172-31-3 *Array[11] Mar 15 16:10
311 gord PEND share ip-172-31-3 *Array[12] Mar 15 16:10
311 gord PEND share ip-172-31-3 *Array[13] Mar 15 16:10
分配与我们的共享策略直接一致。
该bqueue s命令作用是显示出谁的工作是由用户执行特定的队列分配。
[root@ip-172-31-34-75 ~]# bqueues -l share
QUEUE: share
— Queue to demonstrate fairshare scheduling policy
PARAMETERS/STATISTICS
PRIO NICE STATUS MAX JL/U JL/P JL/H NJOBS PEND RUN SSUSP USUSP RSV
30 20 Open:Active – – – – 4720 4680 40 0 0 0
Interval for a host to accept two jobs is 0 seconds
SCHEDULING PARAMETERS
r15s r1m r15m ut pg io ls it tmp swp mem
loadSched – – – – – – – – – – –
loadStop – – – – – – – – – – –
SCHEDULING POLICIES: FAIRSHARE
TOTAL_SLOTS: 40 FREE_SLOTS: 0
USER/GROUP SHARES PRIORITY DSRV PEND RUN
staff/ 3 0.750 30 2760 30
william 1 0.333 10 920 10
david 1 0.333 10 920 10
james 1 0.333 10 920 10
partners/ 1 0.250 10 1920 10
gord 1 0.500 5 960 5
dan 1 0.500 5 960 5
USERS: all users
HOSTS: all hosts used by the OpenLava system
请注意,即使集群中有成千上万个作业,bqueues -l输出显示的共享策略仍具有完全保真性。有一段时间,在工作完成之后,我们看到,我们的工作人员已经完成了超过50%的工作,资源分配仍然完美平衡。
SCHEDULING POLICIES: FAIRSHARE
TOTAL_SLOTS: 40 FREE_SLOTS: 40
USER/GROUP SHARES PRIORITY DSRV PEND RUN
staff/ 3 0.750 30 1380 0
william 1 0.333 10 460 0
david 1 0.333 10 460 0
james 1 0.333 10 460 0
partners/ 1 0.250 10 1460 0
gord 1 0.500 5 730 0
dan 1 0.500 5 730 0
USERS: all users
HOSTS: all hosts used by the OpenLava system
OpenLava的Fairshare调度策略有多公平?虽然这是一个非常简单的例子,但基于这个测试,Openlava的Fairshare调度策略看起来很强大!
- 在OpenLava中探索Fairshare调度
- 在OpenLava中管理并行作业
- 【探索】在 JavaScript 中使用 C 程序
- 探索MVP在Android中使用
- 在HTML页面中调度QTP
- 在Spring中使用Quartz调度器
- 在spring中使用Quartz调度器
- 在liferay6.1中使用调度器
- 在MySQL中创建事件调度
- VxWorks 进程调度探索【转贴】
- 使用OpenLava运行MPI作业
- Ajax在Asp.net中数据绑定应用探索
- Ajax在Asp.net中数据绑定应用探索
- 探索在城市中如何找出自己的创业方向
- 在Google Nexus One中移植MeeGo探索
- 协同标绘在SuperMap中实现思路的探索
- 多核动态任务调度的进一步探索
- 如何在Web工程中实现任务计划调度
- win32 api 文件操作
- iOS 原生二维码扫描(可限制扫描区域)
- 师--链表的结点插入
- zabbix客户端 zabbix-agent 2.4版本安装
- 数据结构-递归
- 在OpenLava中探索Fairshare调度
- 关于文件中的0D、0A
- 数据模型使用(ios),浅谈ios和swift数据模型使用,set和get方法使用
- JPype入门实例
- android触屏震动以及震动强度
- 爬虫入门
- springboot配置异常
- EHCache分布式缓存集群环境配置
- schema文件的三种编写方式