Platform LSF ELIM

LSF可以让用户自定义一些资源,其中动态资源可以通过ELIM向LSF汇报,下面以本地磁盘(一个机械盘一个SSD)负载为例:

在$LSF_ENVDIR/lsf.shared的Begin Resource中增加

diskut   Numeric    60    Y    (Percentage of CPU time during which I/O requests were issued to local disk)
ssdut   Numeric    60    Y    (Percentage of CPU time during which I/O requests were issued to local SSD disk)

在$LSF_ENVDIR/lsf.cluster.的Begin ResourceMap中增加一行

diskut              [default]
ssdut               [default]

在$LSF_SERVERDIR/下新建一个文件elim.disk内容如下并且chmod +x elim.disk

#!/bin/sh

declare -a util
while true; do
	util=(`sar -d 60 1|grep Average|grep dev8|awk '{print $10}'`)
	case "${#util[@]}" in
		1)
			echo 1 diskut ${util[0]}
			;;
		2)
			echo 2 diskut ${util[0]} ssdut ${util[1]}
			;;
	esac
done

所有节点需要lsadmin limrestart,然后用lsload -l就可以看到多出来两列了

bsub时可以使用这些参数
-R “order[diskut]” 优先选择disk负载最轻的
-R “select[diskut < 10]” 要求disk负载小于10%
-R “rusage[diskut=10]” 为这个任务预留10%的disk负载。rusage不影响lsload的显示,但是会叠加到lsload显示的实际值上面从而影响order select的结果,除非lsf确定预留的资源被这个job所使用了(比如mem)。

Platform LSF Compute Units 调度策略

Compute Units(CU)可以对一个队列中的机器在调度时进行分组,可以控制作业在这些组中的分配。

假设有三个cu,每个cu空闲的job slots如下:

cu name free job slots
cu1 4
cu2 6
cu3 8

 

cu[pref=minavail]:把cu按照空闲的job slots从小到大排序,按顺序填充分配使用cu。例:-n 4则使用cu1的4个;-n 6则使用cu1的4个和cu2的2个。

cu[pref=maxavail]:把cu按照空闲的job slots从大到小排序,按顺序填充分配使用cu。例:-n 6则使用cu3的6个;-n 10则使用cu3的8个和cu2的2个。
上面的情况下,如果cu中空闲的job slots数量一样,则按照其在lsb.hosts中Begin ComputeUnitvs中的顺序使用

cu[balance]:按照在lsb.hosts中Begin ComputeUnitvs中的顺序,在尽量少的cu中分配使用且每个cu中使用的job slots尽量平衡。例:-n 6则使用cu2的6个;-n 8则使用cu3的8个;-n 10则使用cu2和cu3的各使用5个;-n 12则cu2和cu3个使用6个;-n 14则cu1使用4个、cu2和cu3各使用5个。
cu[balance:pref=minavail]和cu[balance:pref=maxavail]:把cu按照空闲的job slots排序,在尽量少的cu中分配使用且每个cu中使用的job slots尽量平衡。例:-n 4 -R “cu[balance:pref=minavail]”使用cu1,-n 4 -R “cu[balance:pref=maxavail]”使用cu3。

对于HPC来说,​其实更想要一种类似于minavail但是又尽量分布到最少cu上的策略,如果必须跨cu则应尽量不等分减少跨cu通讯。

Plextor M5p 256GB vs Intel SSD 530 240GB

Dell R620, 2*E5-2643, 32GB RAM, RHELS 5.3, Iozone 3.414,SSD分区4K对齐, ext4打开trim

./iozone -a -i 0 -i 1 -i 2 -y 4k -q 1m -s 64g -Rb ./test.xls 

结果就是Intel SSD 530全面大幅超越Plextor M5p,具体结果如下:

Plextor M5p 256GB:

record size 4 8 16 32 64 128 256 512 1024
Writer Report 73495 49706 53834 55819 51266 51434 52833 51928 52610
Re-writer Report 82056 80580 81662 71514 71218 70992 70998 71210 73930
Reader Report 437508 437398 437296 436977 437826 437586 437788 436948 437527
Re-reader Report 437118 437650 437002 436111 437281 437213 442700 437818 437569
Random Read Report 36441 64764 91808 129377 190359 231620 309157 278560 273607
Random Write Report 53990 53750 52256 52058 52626 51981 51429 52504 52852

Intel SSD 530 240GB:

record size 4 8 16 32 64 128 256 512 1024
Writer Report 498716 523831 500965 527952 524793 525040 528580 529695 529030
Re-writer Report 523820 524679 527672 528101 525403 528344 526986 526756 527916
Reader Report 399111 405611 403717 401873 404561 401628 401842 401729 403944
Re-reader Report 399121 402200 399726 399718 408133 401520 401671 401337 401857
Random Read Report 26518 51309 81293 126808 209616 265063 336988 382371 409023
Random Write Report 270073 370813 443589 489812 511003 520004 521321 521664 524645

 

NetApp E2600 DDP测试

存储为浪潮AS500H(NetApp E2600),24个900GB 2.5-inch 10Krpm SAS。IO节点为两台浪潮NF5270M3,每台2*E5-2620v2 64GB内存 双端口MiniSAS卡。每台IO节点均和存储的两个控制器通过MiniSAS直接连接。24个盘做成一个DDP,保留盘1个或2个,划分两个卷,每个控制器一个,每个IO节点一个,持续写入约220MB,持续读取约610MB。可以说结果一塌糊涂!

RHEL6 正确关闭IPv6的方法

正确的方法是:

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sed -i '/net.ipv6.conf.all.disable_ipv6=/d' /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6=1" >> /etc/sysctl.conf
sed -i '/net.ipv6.conf.default.disable_ipv6=/d' /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6=1" >> /etc/sysctl.conf

/etc/ssh/sshd_conf中的AddressFamily any改为AddressFamily inet,否则sshd会有问题

/etc/modprobe.d/ 目录下新建一个文件,内容为install ipv6 /bin/true,的确能关闭IPv6但是会导致网卡bonding失败等各种问题

/etc/sysconfig/network 里面添加NETWORKING_IPV6=no 或者 IPV6INIT=no 都是没有用的

LSI MeagRAID CacheCade 测试

Dell R720xd,2*E5-2620,16GB RAM,PERC H720P Mini (LSI SAS2208 ROC)
Red Hat Enterprise Linux Server release 6.3
General Parallel File System (GPFS) 3.5.0.11
SSD: Intel SSD 530 Series (240GB, 2.5in SATA 6Gb/s, 20nm, MLC)
Iozone 3.414,测试命令iozone -i 0 -i 1 -i 2 -r 1m -s 64G,结果单位Kbytes/sec

Raid5:15个2.5" SAS2 10Krpm 900GB,每5个硬盘为一个Raid5共3个,每个Raid5在GPFS里面做成一个NSD,三个NSD做成一个GPFS文件系统

无CacheCade
write: 2157086
rewrite: 2164703
read: 1920239
reread: 2034515
random read: 126223
random write: 927219

有CacheCade
write: 2142893
rewrite: 2142537
read: 963505
reread: 970880
random read: 71778
random write: 862301

pagepool设置1GB或12GB测试了一下,对结果没有显著影响。

虽然结论仍然是当SSD性能落后于被加速的机械硬盘时性能反而下降,但是您肯定想问为啥测试结果和以前的这篇文章差距如此巨大?以前是刚装好就测试的,这次是高负载使用了一段时间以后测试的,还有就是GPFS的小版本有点不同。

LSI MeagRAID CacheCade 的 IO Policy

Dell R720xd,2*E5-2620,16GB RAM,PERC H720P Mini (LSI SAS2208 ROC)
Red Hat Enterprise Linux Server release 6.3
General Parallel File System (GPFS) 3.5.0.11
SSD: Intel SSD 530 Series (240GB, 2.5in SATA 6Gb/s, 20nm, MLC)

配置好CacheCade后,机械盘的IO Policy无论设置为Direct IO还是Cached IO,其结果都是一样的。
也就是说一旦配置好CacheCade后,所有机械盘阵列均能够被CacheCade加速

LSI MeagRAID SAS2208 性能测试

Dell R720,E5-2620,16GB RAM,PERC H720P Mini (LSI SAS2208 ROC)
Red Hat Enterprise Linux Server release 6.3
General Parallel File System (GPFS) 3.5.0.11
Raid5:5个2.5" SAS2 10Krpm 600GB为一个Raid5做成一个NSD,用这个NSD做成一个GPFS文件系统

Iozone 3.414,测试命令iozone -i 0 -i 1 -i 2 -r 1m -s 64G,结果单位Kbytes/sec
write: 393595
rewrite: 406162
read: 431798
reread: 434553
random read: 97135
random write: 238970

Veeam的备份方式

Veeam创建两种备份文件,vbk是一个完整的备份,vrb/vib是增量备份文件用来记录改变。

Reversed Incremental Backup

每次增量备份都会更新vbk文件,vbk中是最新的完整备份,恢复最新的备份只要恢复vbk就可以了。每次增量备份时vbk中修改的内容会被保存到vrb中,所以称之为Reversed,vrb中保存的不是修改的新数据,而是被覆盖的旧数据,恢复以前的备份需要将vrb和vbk合并出来。这种方法永远是增量备份,节省硬盘空间,这是磁盘上面备份的推荐方案。

Retention Policy

保留策略会立刻直接删除超期的增量vrb文件,最节约磁盘空间。

看这里的动画演示

Forward Incremental Backup

每次增量备份只将改变的部分保存成一个新的vib文件,如果需要将备份数据存储到磁带或远程,这种方法每次只要保存新的vib文件即可,或者有法规要求备份不得修改,那么这是最好的选择。显而易见,vib文件会越来越多,这会导致恢复的时候需要合并过多的vib文件,因此需要使用 active full 或 synthetic full backups 解决长链问题。

Forever forward incremental Backup

只有第一次备份时创建一个完整备份,以后备份只创建增量备份。到达所需的保留时间后,会将最早的增量备份和完整备份合并形成新的完整备份,就像完整备份向前移动一样,备份存储上只有一个完整的备份。

Synthetic Full Backup

使用active full backup是非常消耗源系统资源的过程,synthetic full backup则是使用以前的完整备份vbk和增量备份vib合并出一个新的完整备份。因为不需要读取源,因此对源系统的压力小得多。显然以后forward incremental backup会从这个新的完整备份为基础创建增量备份文件。

Transforming Incremental Backup Chains into Reversed Incremental Backup Chains

使用incremental backup时如果选择了synthetic full backups,那么就可以选择这种方式。系统只会保留一个完整备份,这个完整备份之前的备份会被转换成reversed incremental backup方式,只将被覆盖的数据保存到vrb中,完整备份之后数据还是正常incremental backup方式。

Active Full Backup

从源创建一个完整的备份,以后forward incremental backup会从这个新的完整备份为基础创建增量备份文件。

Retention Policy (forward incremental backup)

如果选择了Synthetic Full Backup或Active Full Backup,只有当一个增量备份链表的最后一个增量备份超期时才会删除整个增量备份链表。如果没有选择,则只会存在一个完整备份,每次备份将完整备份和前面的一个增量合并成新的完整备份。

看这里的动画演示