首页 > 其他分享 >使用Slurm集群进行分布式图计算:对Github网络影响力的系统分析

使用Slurm集群进行分布式图计算:对Github网络影响力的系统分析

时间:2023-12-05 11:25:19浏览次数:42  
标签:Github process ntp Slurm munge 集群 服务器 分布式

本文分享自华为云社区《基于Slurm集群的分布式图计算应用实践:Github协作网络影响力分析》,作者:yd_263841138 。

1. 引言

Slurm(Simple Linux Utility for Resource Management)是一个针对小型Linux集群的开源、容错、高可扩展的集群管理及作业调度系统,它具备统一管理集群内的计算资源、管理任务调度、监控作业任务等功能,能够在并行程序开发、验证过程中省去对集群计算资源管理配置的冗杂过程,高效助力分布式并行程序开发。

Gemini 是一个轻量级分布式图计算框架,其是后续多款大规模图计算框架的原型模板。Gemini既支持单机运行,也可以分布式多机运行。而多机运行的话,Gemini给出了在Slurm上提交作业的运行方案。

因此,一方面出于对作业调度系统部署过程的实践学习,另一方面出于后续对大规模图计算框架预研方向上的需要,最终决定尝试在通过多台华为云弹性服务器构建简易计算集群,并安装部署Slurm作业调度系统。

2. Slurm部署

2.1. 配置信息

关于华为云服务器配置,我以按需计费模式开通了三台通用入门型弹性云服务器(ECS)及其弹性公网IP,详细信息如下表。

规格类型主机名镜像处理器内存硬盘规格内网地址
通用入门型 master CentOS 7.9 64bit 1vCPUs 1GiB 通用型SSD 40 GiB 192.168.101
通用入门型 slave1 CentOS 7.9 64bit 4vCPUs 4GiB 通用型SSD 40 GiB 192.168.100
通用入门型 slave2 CentOS 7.9 64bit 4vCPUs 4GiB 通用型SSD 40 GiB 192.168.102

根据slurm部署规划,我以处理器规格为1vCPUs的master作为控制节点,不承担计算任务;以两台处理器规格为4vCPUs的slave1/2作为计算节点,构成集群的全部计算资源。

2.2. 部署过程

Slurm的部署过程比较复杂,这里以其官网文档的“Super Quick Start”指南作为参考进行部署,主要步骤包括:时钟同步、Munge配置、Slurm配置等步骤。

2.2.1. 时钟同步

这里采用ntp作为集群的时钟同步工具,其重点是对/etc/ntp.conf配置文件相关参数的编辑。

集群内时钟服务器节点

集群内的时钟服务器需要确定本服务器的所参照的时钟标准。这里将原本的默认服务器改为国内服务器。

#注释掉默认的外网时间服务器
# server 0.centos.pool.ntp.org iburst
# server 1.centos.pool.ntp.org iburst
# server 2.centos.pool.ntp.org iburst
# server 3.centos.pool.ntp.org iburst
# 添加中国国家授时中心服务器地址
server 0.cn.pool.ntp.org
server 1.cn.pool.ntp.org
server 2.cn.pool.ntp.org
server 3.cn.pool.ntp.org
# 添加允许上层时间服务器主动修改本机时间
restrict 0.cn.pool.ntp.org nomodify notrap noquery
restrict 1.cn.pool.ntp.org nomodify notrap noquery
restrict 2.cn.pool.ntp.org nomodify notrap noquery
restrict 3.cn.pool.ntp.org nomodify notrap noquery

修改完配置文件后,则先将当前服务器时钟与参照服务器进行对齐,接着开启ntp服务。

sudo ntpdate cn.pool.ntp.org
sudo service ntpd start

集群内其他服务器节点

集群内其他待同步的服务器节点的/etc/ntp.conf配置需要确定集群内时钟服务器主机名或IP地址,并允许其时钟被时钟服务器所修改。

# 从node01中同步时间
# server <YOUR CLOCK SERVER IP_ADDR/HOSTNAME>
server master
# 允许时间服务器修改本地时间
# restrict 时间服务器主机名或ip nomodify notrap noquery
restrict master nomodify notrap noquery

在完成配置文件的修改后,先将当前服务器时钟与时钟服务器的时钟进行对齐后,再启动ntp服务。

#sudo ntpdate <YOUR CLOCK SERVER IP_ADDR/HOSTNAME>
sudo ntpdate master
sudo service ntpd start

2.2.2 配置Munge

参照Munge官网安装指南中 Installing from RPMs on Red Hat compatible systems 进行安装。

首先,下载munge(munge.0.5.15.tar.xz和munge.0.5.15.tar.xz.asc两个文件)。

接着,参考Installing from RPMs onRed Hat compatible systems的指导进行安装。具体地,

  • 先从tarball构建SRPM,并根据SRPM安装依赖:
rpmbuild -ts munge-0.5.15.tar.xz
sudo dnf builddep SRPMS/munge-0.5.15-1.el9.src.rpm
  • 再验证安装下载的源码。下载dun.gpg,确保文件夹下由dun.gpg、munge-0.5.15.tar.xz和munge-0.5.15.tar.xz.asc三个文件。
rpmbuild -tb --with=verify --with=check munge-0.5.15.tar.xz
  • 此时munge、munge-devel、munge-libs或更多二进制RPMs就会生成。然后通过二进制RPMs安装:
sudo rpm --install --verbose \\
     RPMS/x86_64/munge-0.5.15-1.el9.x86_64.rpm \\
     RPMS/x86_64/munge-debugsource-0.5.15-1.el9.x86_64.rpm \\
     RPMS/x86_64/munge-devel-0.5.15-1.el9.x86_64.rpm \\
     RPMS/x86_64/munge-libs-0.5.15-1.el9.x86_64.rpm

munge不必获得root权限,但是需要具有对以下文件夹的所属:

  • ${sysconfdir}/munge [/etc/munge]
  • ${localstatedir}/lib/munge [/var/lib/munge]
  • ${localstatedir}/log/munge [/var/log/munge]
  • ${runstatedir}/munge [/run/munge]

创建munge密钥

sudo -u munge ${sbindir}/mungekey --verbose
#如果失败,则需手动切到/usr/local/sbin目录下执行mungeky

生成密钥存在于*${sysconfdir}/munge/munge.key*下,需要把这个密钥拷贝集群内所有机器的此目录中。

最后,开启munge守护进程(systemd方式)

# 开机自动启动
sudo systemctl enable munge.service
# 启动
sudo systemctl start munge.service
# 查看状态
sudo systemctl status munge.service
# 停止
sudo systemctl stop munge.service

2.2.3. 配置slurm

从官网下载slurm22xxxxx,

解压tar-ball: tar —bzip -x -f slurm*tar.bz2

进入Slurm源码目录,键入 ./configure 配置(可带例如—prefix=和—sysconfdir=选项)

键入 make 编译Slurm

键入 make install 安装程序、软件和库等。

配置slurm.conf

主要配置SlurmUser、以及节点、分区信息。

SlurmctldHost=master
ProctrackType=proctrack/linuxpro
# COMPUTE NODES
NodeName=slave2 Sockets=1 CPUs=4 CoresPerSocket=2 ThreadsPerCore=2 RealMemory=300 State=UNKNOWN NodeAddr=192.168.0.102
NodeName=slave1 Sockets=1 CPUs=4 CoresPerSocket=2 ThreadsPerCore=2 RealMemory=300 State=UNKNOWN NodeAddr=192.168.0.100
NodeName=master Sockets=1 Procs=1 CoresPerSocket=1 ThreadsPerCore=2 RealMemory=300 State=UNKNOWN NodeAddr=192.168.0.101
PartitionName=compute Nodes=slave1,slave2  Default=YES MaxTime=INFINITE State=UP
PartitionName=control Nodes=master Default=NO MaxTime=INFINITE State=UP

运行Slurm前,确保SlurmUser存在,相关目录(/var/spool/slurm/)存在,slurm.conf已拷贝到集群内所有机器同目录位置。

2.2.4. 测试运行

确保时间同步。

确保munge已开启。

控制节点

键入 slurmctld -D 显式运行,命令行打印运行信息。

计算节点

键入 slurmd -D 显式运行,命令行打印运行信息。

3. Github协作网络影响力分析

3.1. Gemini编程接口

Gemini图计算框架为用户设计自定义图应用算法提供了两个通用编程接口:process_vertices和process_edges。顾名思义,process_vertices即表示对顶点的遍历,用户需要另外提供顶点遍历时的自定义更新函数;process_edges即表示对边的遍历,用户需要另外提供自定义消息生成、规约函数。

3.1.1. process_vertices

process_vertices声明如下所示,其包含两个参数,分别是处理函数process以及活跃顶点集active。从使用角度而言,process即需要用户指明对顶点遍历时需要参照哪些数据、修改哪些数据;active的作用类似顶点开关,即在此轮顶点遍历中需要遍历哪些顶点。

template<typename R>
  R process_vertices(std::function<R(VertexId)> process, Bitmap * active);

3.1.2. process_edges

process_edges的声明如下所示。由于Gemini在实际计算过程中会采用Sparse或Dense两种模式,因此这里需要分别提供Sparse和Dense的Signal和Slot方法(即发送信息、接收消息方法)。

template<typename R, typename M>
  R process_edges(std::function<void(VertexId)> sparse_signal, 
                                    std::function<R(VertexId, M, VertexAdjList<EdgeData>)> sparse_slot, 
                                    std::function<void(VertexId, VertexAdjList<EdgeData>)> dense_signal, 
                                    std::function<R(VertexId, M)> dense_slot, 
                                    Bitmap * active, 
                                    Bitmap * dense_selective = nullptr) {

3.2. 预处理

这里通过Github日志信息来构建Github协作网络,以进一步分析得到用户、项目的影响力指标。因此,在具体分析计算之前,需要对原始数据进行抽取及预处理工作。

3.2.1. 日志抽取

针对Github日志数据的处理存在一些困难与挑战。比如,日志文件数据量大,难以处理;日志信息粒度极高,包含大量冗杂信息,需要进一步筛选。针对这些困难挑战,这里采取了相对应的处理措施。

首先,对日志文件按一定条目数进行批量切分,切分成大小均匀的一个个子文件再进行处理。如若不进行切分,那么倘若在处理程序执行过程中出现错误,则之前已处理的进度无法跟踪、处理好的数据只能舍弃再从头开始处理。

接着,再利用正则表达式结合python第三方库pandas对子文件信息进行处理。具体地,主要抽取仓库ID(repo_id)、开发者ID(actor_id)以及事件类型等字段。

3.2.2. 同构图转异构图

根据日志抽取得到的数据可构建出开发者与代码仓库之间的二部图,其分别以开发者、代码仓库为顶点,将各种事件抽象为二者之间的关系。而直接处理异构图本身是比较复杂的,因此这里将采取顶点降维的方式、将异构图分别转为仅含开发者或仅含代码仓库的同构图,分别求开发者之间的影响力指标与代码仓库之间的影响力指标。以转变为仅含代码仓库顶点的同构图为例,这里首先将开发者看作是“中继”,即一个开发者会直接与若干代码仓库产生联系。这里则将开发者所直接联系的若干代码仓库之间用边相连、相联系起来,这样即可消除起”中继“作用的开发者顶点,进而转变为只包含代码仓库顶点的同构图。

3.2.3 适配Gemini数据要求

Gemini要求用户提供图中顶点个数总数作为程序参数,并且要求对顶点序号进行顺序连续重编号。因此,为了符合Gemini的要求,这里对图的顶点序号进行重新编号,并通过哈希表记录重新编号后的顶点与原顶点的映射关系。

3.3. 程序设计

PageRank算法最初作为互联网网页重要度的计算方法,能有效反映互联网中网页的影响力。同样,将PageRank算法借鉴到Github协作网络影响力分析中也可得到开发者、代码仓库的影响力指标。因此,在算法设计上,这里参考PageRank算法,利用Gemini框架进行程序设计与实现。

Gemini源码已包含一个PageRank的测试样例,这里基于测试样例进行修改调整,以适配Github协作网络分析任务。在PageRank实现过程中,就编程方面比较核心的即是边遍历(process_edges)的过程。

graph->process_edges<int,double>(
      [&](VertexId src){
                // sparse_signal
        graph->emit(src, curr[src]);
      },
      [&](VertexId src, double msg, VertexAdjList<Empty> outgoing_adj){
                // sparse_slot
        for (AdjUnit<Empty> * ptr=outgoing_adj.begin;ptr!=outgoing_adj.end;ptr++) {
          VertexId dst = ptr->neighbour;
          write_add(&next[dst], msg);
        }
        return 0;
      },
      [&](VertexId dst, VertexAdjList<Empty> incoming_adj) {
                // dense_signal
        double sum = 0;
        for (AdjUnit<Empty> * ptr=incoming_adj.begin;ptr!=incoming_adj.end;ptr++) {
          VertexId src = ptr->neighbour;
          sum += curr[src];
        }
        graph->emit(dst, sum);
      },
      [&](VertexId dst, double msg) {
                // dense_slog
        write_add(&next[dst], msg);
        return 0;
      },
      active
    );

3.4. 程序运行

确认集群中Slurm系统正在运行,接着以提交作业的方式运行程序。

确认Slurm系统与资源状况

sinfo

编译并提交作业

make
srun -N 2 ./NewGemini/toolkits/pagerank ./NewGemini/github_data.dat 1000 8

4. 小结

本文实现了Slurm在弹性云服务器集群的安装与部署,整体流程较为简洁明了,但是在实际实施过程中仍会遇到些问题。对于Gemini框架的理解和使用仍比较局限。对此,根据整个部署过程下来后的心得体会,作如下几点小结:

  • 选择Centos镜像的话尽量选择Centos 7,否则Centos 8的话会遇到一些问题。
  • Munge的安装方法比较丰富,官网提供了git安装、RPM安装等多种安装方式。
  • 会出现缺少依赖、缺少文件夹、权限错误等问题,根据错误信息逐个解决即可。
  • Gemini对输入数据有一定要求,比如顶点需要顺序连续编号。并且如果当输入是带权图时,在写二进制文件时需额外注意。

这次实践比较简略,其目的主要实践学习作业调度软件在集群的部署过程,以及为分布式图计算应用提供初步NUMA资源架构环境,因而仅简要划分了控制节点与计算节点,并没有继续细分登录节点、部署数据库、考虑计费机制等问题。因此,在未来或需要继续深入思考以下几点内容:

  • 如何以实验场景、生产场景的标准部署Slurm。
  • 如何分析提交作业的程序性能、机器利用率。
  • 深入理解Gemini框架思想及接口,对照其他图计算框架继续学习。

参考资料

点击关注,第一时间了解华为云新鲜技术~

 

标签:Github,process,ntp,Slurm,munge,集群,服务器,分布式
From: https://www.cnblogs.com/huaweiyun/p/17876809.html

相关文章

  • 【译】使用 GitHub Copilot 编写 Git 提交
    在花费数小时修复bug或更新特性之后,我们开发人员最不愿意做的事情往往是仔细说明Git提交的内容。最新的VisualStudio预览版可以帮到您。使用新的生成Git提交消息特性来帮助您描述变更集。然后,您可以用“why”进行更改来细化消息并提交。生成有用且信息丰富的提......
  • 使用分布式事务 Seata 的 AT 模式
    有了上篇博客实现XA模式的基础,本篇博客在实现AT模式时,不需要修改任何代码,只需要增加一张数据库表,修改以下application.yml配置即可实现。AT模式也是分两个阶段提交的事务模型,它缺弥补了XA模型中资源锁定周期过长的问题。其实现的两个阶段的工作原理如下:第一阶段注册分......
  • 分布式协同(万字长文)
    分布式协同分布式协同,也叫分布式协调,是在计算机网络中,不同的硬件或软件组件完成各自的任务,然后通过协同工作来解决问题。在分布式系统中,不同的节点需要进行信息的交换,以达到一致的状态。这个过程就需要分布式协调。例如,我们要保证在分布式系统中的所有节点上的数据是最新的,就需......
  • 分布式事务~seata的使用
    springcloud-nacos-seata分布式事务组件seata的使用demo,AT模式,集成nacos、springboot、springcloud、mybatis-plus,数据库采用mysqldemo中使用的相关版本号,具体请看代码。如果搭建个人demo不成功,验证是否是由版本导致,由于目前这几个项目更新比较频繁,版本稍有变化便会出现许多奇怪......
  • LAXCUS分布式操作系统的产品规划和发展阶段​
    又是一位网友的提问,把回答贴出来给大家看看,欢迎大家在下方留言交流。问:关注你们很久了,我想问一问,Laxcus分布式操作系统有没有具体的产品规划,如果有是什么,打算怎么做?你们的主要着眼点在哪里?目前Laxcus分布式操作系统发展到什么阶段了?答:感谢关注!Laxcus做为全球第一款纯粹的分布式操......
  • 对Laxcus分布式操作系统的认知、价值、痛点解决的回答​
    下面是一位网友的提问,回答贴出来供大家参考,欢迎在下方留言评论。问:Laxcus分布式操作系统有哪些与众不同的地方?它的价值在哪里?解决了哪些市场痛点?我公司现在已经使用Linux操作系统部署了一堆服务器,你如何说服我弃用Linux使用Laxcus?回答:Laxcus分布式操作系统是操作系统的一个异类,它是......
  • 分布式数据库Apache Doris HA集群部署
    ......
  • 叮咚,你的微信年度聊天报告请查收「GitHub 热点速览」
    本周热点项目WeChatMsg是一个微信记录提取工具,据说它还能帮你分析聊天记录、生成你的年度聊天报告。而又到了年底,部分不幸的小伙伴要开始写年度总结了,这时候self-operating-computer就能让你的电脑变成熟,在你的指示下写完你的年度汇报。除了更智能的电脑,本周AnimateAnyone......
  • 使用分布式事务 Seata 的 XA 模式
    上篇博客已经搭建了分布式事务Seata的集群,本篇博客主要介绍如何使用Seata的XA模式。XA模式的规范是X/Open组织定义的分布式事务处理(DTP,DistributedTransactionProcessing)标准,XA模式规范描述了全局的TM与局部的RM之间的接口,几乎所有主流关系型数据库都对XA模式......
  • Github Actions - Creating PostgreSQL service containers
     #Servicecontainerstorunwith`container-job`services:#Labelusedtoaccesstheservicecontainerpostgres:#DockerHubimageimage:postgres#Providethepasswordforpostgresenv:......