Lenovo DSS-G 监控

Lenovo DSS-G 是联想将GPFS集成的软硬件一体化设备,作为一套存储监控非常重要,等到丢数据的时候就追悔莫及了。

组件数据库

DSS-G 使用组件数据库(compDB )来描述硬件组件,如机柜、DSS-G的服务器和JBOD。使用 DSS-G 不需要compDB,但是健康监控需要。

第一步:生成组件数据库

始终使用dry run来生成组件数据库(compDB),其中dssg01是DSS-G两台服务器的node class(dssgmkstorage时创建的)

[root@dss01 ~]# dssgmkcompdb --racktype RACK42U --verbose --dryrun -N dssg01
DSS-G 5.0c
Parsing options: --racktype RACK42U --verbose --dryrun -N dssg01 --
Entering verbose mode
Entering dry run mode

Using provided nodeclass or node list
dss01
dss02
Checking whether all nodes belong to the same cluster...

Using rack type "RACK42U" of height 42U

Checking server model...

…………

# DSS-G210-1

Setting componentDB...
Note: all commands below support the --dry-run option
DRYRUN: mmaddcomp -F /root/yaoge123gpfs.io01-comp.2025-03-15.233334.851103.stanza --replace
DRYRUN: mmchcomploc -F /root/yaoge123gpfs.io01-comploc.2025-03-15.233334.851103.stanza
DRYRUN: /root/yaoge123gpfs.io01-dispid.2025-03-15.233334.851103.sh

All done

第二步:检查两个stanza文件内容,其中组件安装在机柜中的具体位置在 -comploc..stanza 文件中

第三步:导入组件数据库,照抄dssgmkcompdb最后面三行DRYRUN后面的命令运行,然后用mmlscomp和mmlscomploc检查结果。

[root@dss01 ~]# mmlscomp

    Rack Components

Comp ID  Part Number  Serial Number  Name
-------  -----------  -------------  ----
      6  RACK42U      *******        A1

    Server Components

Comp ID  Part Number  Serial Number  Name              Node Number
-------  -----------  -------------  ----------------  -----------
      9  7D9ECTOLWW   ********       SR655V3-********          101
     10  7D9ECTOLWW   ********       SR655V3-********          102

    Storage Enclosure Components

Comp ID  Part Number  Serial Number  Name            Display ID
-------  -----------  -------------  --------------  ----------
      8  7DAHCT0LWW   ********       D4390-********

    Storage Server Components

Comp ID  Part Number  Serial Number  Name
-------  -----------  -------------  ----------
      7  DSS-G210                    DSS-G210-1
[root@dss01 ~]# mmlscomploc

Rack  Location  Component
----  --------  ----------------
A1    U35-36    SR655V3-********
A1    U33-34    SR655V3-********
A1    U01-04    D4390-********

Storage Server  Index  Component
--------------  -----  ----------------
DSS-G210-1          3  SR655V3-********
DSS-G210-1          2  SR655V3-********
DSS-G210-1          1  D4390-********

设置DSS-G监控

因为DSS-G本身的冗余性(节点冗余、链路冗余等),出现故障不一定会导致整个文件系统失效,这往往会导致故障没有被立刻发现,但是这些故障会破坏冗余性或导致性能下降,管理员应该知晓这些故障并积极修复。dssghealthmon 它会周期性(默认1小时)检查整个DSS-G的健康状态,如有故障会自动发送邮件通知。dssghealthmon 可以通过confluent节点带外访问XCC(服务器的BMC)检查硬件健康状态,所以需要DSS-G服务器到Confluent的免密码SSH。

第一步:编辑配置文件 /etc/dssg/dssghealthmon.conf

  • contactEmail: 故障通知的Email,必填项。
  • 其它不想填就都注释了

第二步:先查看一下DSS-G的nodeclass名称,然后启动监控

[root@dss01 ~]# mmlsnodeclass 
Node Class Name       Members
--------------------- -----------------------------------------------------------
dssg01                dss01,dss02

[root@dss01 ~]# dssghealthmon_startup dssg01 confluent
Obtaining Confluent version from management server confluent
3.11.1

Processing nodeclass...
Node Class Name       Members
--------------------- -----------------------------------------------------------
dssg01                dss01,dss02

Parsing configuration file...

Copying configuration file...

Creating tuple file...
dss01:dss01:7D9ECTOLWW:********
dss02:dss02:7D9ECTOLWW:********

Copying tuple file...

Setting or replacing the dssghealthmon_erflist cronjob...
Warning: dssghealthmon_erflist cronjob has NOT been specified

Creating and copying daemon environment file...

Starting dssghealthmond...
The dssghealthmon system has been successfully started

第三步:在两个服务器上检查监控状态和配置文件

[root@dss01 ~]# dssghealthmon_status dssg01
Processing nodeclass...
Node Class Name       Members
--------------------- -----------------------------------------------------------
dssg01                dss01,dss02

Obtaining status of the DSS-G health monitor...
dss01: active
dss02: active
[root@dss01 ~]# systemctl status dssghealthmond.service
● dssghealthmond.service - DSS-G Health Monitor
     Loaded: loaded (/etc/systemd/system/dssghealthmond.service; disabled; preset: disabled)
     Active: active (running) since Sat 2025-04-05 18:52:43 CST; 1min 57s ago
    Process: 1361859 ExecStart=/opt/lenovo/dss/dssghealthmon/dssghealthmond $NODECLASS $MGMT (code=exited, status=0/SUCCESS)
   Main PID: 1361946 (dssghealthmond)
      Tasks: 2 (limit: 2468168)
     Memory: 2.3M
        CPU: 34.410s
     CGroup: /system.slice/dssghealthmond.service
             ├─1361946 /bin/bash /opt/lenovo/dss/dssghealthmon/dssghealthmond dssg01 confluent 1361859
             └─1362172 sleep 3600

Apr 05 18:52:43 dss01 systemd[1]: Starting DSS-G Health Monitor...
Apr 05 18:52:43 dss01 systemd[1]: Started DSS-G Health Monitor.
[root@dss01 ~]# cat /etc/dssg/dssghealthmon.env 
NODECLASS=dssg01
MGMT=confluent
[root@dss01 ~]# cat /etc/dssg/dssghealthmon.hosts 
dss01:dss01:7D9ECTOLWW:********
dss02:dss02:7D9ECTOLWW:********

[root@dss02 ~]# systemctl status dssghealthmond.service
● dssghealthmond.service - DSS-G Health Monitor
     Loaded: loaded (/etc/systemd/system/dssghealthmond.service; disabled; preset: disabled)
     Active: active (running) since Sat 2025-04-05 18:52:43 CST; 4min 52s ago
    Process: 87519 ExecStart=/opt/lenovo/dss/dssghealthmon/dssghealthmond $NODECLASS $MGMT (code=exited, status=0/SUCCESS)
   Main PID: 87601 (dssghealthmond)
      Tasks: 2 (limit: 2468168)
     Memory: 2.2M
        CPU: 1.344s
     CGroup: /system.slice/dssghealthmond.service
             ├─87601 /bin/bash /opt/lenovo/dss/dssghealthmon/dssghealthmond dssg01 confluent 87519
             └─87823 sleep 3600

Apr 05 18:52:43 dss02 systemd[1]: Starting DSS-G Health Monitor...
Apr 05 18:52:43 dss02 systemd[1]: Started DSS-G Health Monitor.
[root@dss02 ~]# cat /etc/dssg/dssghealthmon.env 
NODECLASS=dssg01
MGMT=confluent
[root@dss02 ~]# cat /etc/dssg/dssghealthmon.hosts 
dss01:dss01:7D9ECTOLWW:********
dss02:dss02:7D9ECTOLWW:********

第四步:两台服务器均配置和测试发邮件,以QQ企业邮箱为例,注意需要urlencode

[root@dss01 ~]# cat ~/.mailrc 
set v15-compat
set mta=smtps://yaoge%40yaoge123.com:************@smtp.exmail.qq.com:465 smtp-auth=login
set from=cicam@nju.edu.cn
[root@dss01 ~]# echo "$HOSTNAME" | mailx -s "TEST" yaoge@yaoge123.com

[root@dss01 ~]# scp ~/.mailrc dss02:/root/
.mailrc

[root@dss02 ~]# echo "$HOSTNAME" | mailx -s "TEST" yaoge@yaoge123.com

第五步:模拟故障测试

[root@dss01 ~]# mmvdisk rg list
[root@dss01 ~]# mmvdisk pdisk list --rg dss02
# 找到一个pdisk模拟失效
[root@dss01 ~]# mmvdisk pdisk change --rg dss02 --pdisk e1s44 --simulate-dead
[root@dss01 ~]# mmvdisk pdisk list --rg dss02 --not-ok

                              declustered                                                
recovery group  pdisk            array     paths  capacity  free space  FRU (type)       state
--------------  ------------  -----------  -----  --------  ----------  ---------------  -----
dss02           e1s44         DA1              0    20 TiB    1024 GiB  03LC215          simulatedDead/draining/replace

# 可见已经开始rebuilding
[root@dss01 ~]# mmvdisk rg list --rg dss02 --all

                                                                        needs    user 
recovery group  node class  active   current or master server          service  vdisks  remarks
--------------  ----------  -------  --------------------------------  -------  ------  -------
dss02           dssg01      yes      dss02                             yes           2  

……

declustered   needs                         vdisks       pdisks           capacity     
   array     service  type    BER    trim  user log  total spare rt  total raw free raw  background task
-----------  -------  ----  -------  ----  ---- ---  ----- ----- --  --------- --------  ---------------
NVR          no       NVR   enable   -        0   1      2     0  1          -        -  scrub 14d (66%)
SSD          no       SSD   enable   -        0   1      1     0  1          -        -  scrub 14d (20%)
DA1          yes      HDD   enable   no       2   1     44     2  2    834 TiB  144 GiB  rebuild-1r (8%)

……

vdisk               RAID code        disk group fault tolerance         remarks
------------------  ---------------  ---------------------------------  -------
RG002LOGHOME        4WayReplication  -                                  rebuilding
RG002LOGTIP         2WayReplication  1 pdisk                            
RG002LOGTIPBACKUP   Unreplicated     0 pdisk                            
RG002VS001          3WayReplication  -                                  rebuilding
RG002VS002          8+2p             -                                  rebuilding

第六步:等收到报警邮件后,恢复正常

[root@dss01 ~]# mmvdisk pdisk change --rg dss02 --pdisk e1s44 --revive
[root@dss01 ~]# mmvdisk pdisk list --rg dss02 --not-ok
mmvdisk: All pdisks of recovery group 'dss02' are ok.

第七步:检查日志

  • /var/log/dssg/dssghealthmond.log.<timestamp> 是周期性状态检查的日志,时间戳是健康检查服务启动的时刻,每次周期检查的日志会附加在文件末尾。查看两个服务器日志可见只有一个服务器实际进行了健康检查的动作,另一个服务器知道它不是leader就不干了。
  • /var/log/dssg/dssghealthmon.erf_* 是故障日志,文件名中包含故障类型、部件标识和时间戳,报警邮件正文就是这个文件的内容。
  • 一旦解决故障后,应该在DSS的所有节点上删除ERF文件。

LSI HBA 卡升级固件

storcli64 show 查一下控制器编号,就是Ctl那一列的数字

storcli64 /c0 show 查看当前版本

然后升级一堆:

storcli64 /c0 download file=HBA_9400-8e_SAS_SATA_Profile.bin

storcli64 /c0 download bios file=mpt35sas_legacy.rom

storcli64 /c2 download efibios file=mpt35sas_x64.rom

storcli64 /c0 show 查看升级后版本,然后重启搞定

Huawei 5500 v3 VMware 环境部署要点

以下各类版本如无特殊说明均指2017年4月时的情况。

在硬盘域中创建存储池和在存储池中创建LUN/文件系统,都不要把全部空间用尽,否则将来进行扩容等操作时可能会报错。

DIF需要在LUN映射前通过CLI开启。

在最新的V300R003C20SPC200版本中,SAN的重删压缩虽然已经与大多数增值业务不冲突了,但是仍旧和自动分层冲突,启用了重删压缩的LUN的SmartTier必须设定为不迁移。因此可以单独建立一个启用了重删压缩的LUN,并且设定好容量初始分配策略(如优先从容量层分配),这样的LUN用来做存档备份很好。重删默认不会进行逐个字节对比,压缩默认为高性能压缩算法,如需要启用逐个字节对比或高压缩率算法需通过CLI进行配置。

对于LUN

  1. show lun dedup_compress 确认LUN的ID
  2. change lun lun_id=2 dedup_enabled=yes bytecomparison_enabled=yes 打开ID为2的LUN重删逐字节比较
  3. change lun lun_id=2 compression_enabled=yes compression_method=deep 设置ID为2的LUN压缩策略为压缩率优先

对于文件系统

  1. show file_system general 确认文件系统的ID
  2. change file_system dedup_compress file_system_id=3 dedup_enabled=yes bytecomparison_enabled=yes  打开ID为3的文件系统重删逐字节比较
  3. change file_system dedup_compress file_system_id=3 compression_enabled=yes compression_method=deep 设置ID为3的文件系统压缩策略为压缩率优先

ACC重删压缩卡介入卸载CPU负载的条件是,每两分钟检查一次,如果CPU负载高于50%则卸载。

NAS不支持SmartTier,因此给文件系统存储池分配多个层级的存储介质是没有太大意义的。

此存储支持 VMware VAAI,从V300R003C20开始重删压缩LUN也支持VAAI,在ESXi的存储设备中可以看到相应的LUN硬件加速状态为支持。

VVol是VMware 6.0新的功能,让存储了解每一个虚拟机,需要eSDK Storage VASA 2.0支持,当前最新V100R005C60SPC006只支持VMware 6.0u2,存储固件只支持V300R003C00,这显然落后太多了。即便是最新尚未正式推出的eSDK Storage Plugins V200R001 1.0 RC4,VVol和vCenter的插件也只支持VMware 6.0。VVol和自动分层也是冲突的,综上故不建议使用。

vCenter的插件允许在vCenter中查看和配置存储,最新的eSDK Storage V100R005C70不支持最新的存储固件V300R003C20,只支持VMware 5.0/5.1/5.5/6.0,后面肯定是升级到eSDK Storage Plugins,故不建议使用。

华为存储有自己的多路径软件OceanStor UltraPath,需要在ESXi和VCSA上安装相同的版本,ESXi上可以通过命令行或者Update Manager安装,VCSA需要通过命令行安装,UltraPath可以查看和监控很多链路信息。但是VMware已经出6.5d了,UltraPath支持6.5的V200R001还没有正式推出(还在RC3),当前最新的V100R008C50SPC500只支持VMware 5.0/5.1/5.5/6.0,也不支持RHEL 6.9/7.3;多路径做为基本重要的服务,UltraPath和VMware的版本紧密相关,一旦VMware升级UltraPath也必须跟着升级,其过程要参考升级指导书,增加了整个系统后期的维护成本,因此不太建议使用。

使用VMware NMP多路径需要额外配置:

  1. 对于ESXi 5.5/6.0/6.5,T V1 Series, Dorado5100, Dorado2100 G2, T V2 Series, 18000 V1 Series, V3 Series系列存储,仅为双控且未来也没有扩控计划的,推荐启用ALUA,配置ESXi SATP为VMW_SATP_ALUA,PSP为VMW_PSP_RR;
  2. ESXi进入维护模式
  3. 存储端:修改每个主机的每个启动器,勾选使用第三方多路径,切换模式选择ALUA;
  4. SSH登录ESXi
    1. esxcli storage core device list 查看一下存储的Vendor和Model
    2. esxcli storage nmp satp rule add -V HUAWEI -M XSG1 -s VMW_SATP_ALUA -P VMW_PSP_RR -c tpgs_on 添加多路径规则
    3. esxcli storage nmp satp rule list | grep HUAWEI 看一下刚刚添加的规则
  5. ESXi上面修改存储的LUN多路径策略为循环
  6. 重启ESXi,确认存储LUN为VMW_SATP_ALUA和循环
  7. 退出维护模式

LSF资源限制配置lsb.resources中的USERS和PER_USER

LSF的lsb.resources文件中可以针对用户进行资源使用限制,用户可以用USERS和PER_USER设置,这里列出不同设置下的意义。

USERS=all:所有用户使用资源总和不能超过限制
USERS=A B C:A B C三个用户(组)使用资源总和不能超过限制
PER_USER=all:每个用户使用资源不能超过限制,按照每个用户计算不管用户组
PER_USER=A B C:A B C三个用户(组)的每个用户使用资源不能超过限制,哪怕这里的A B C是用户组,但是还是按照每个用户计算

Dell H730P – Intel SSD 730 RAID5 测试

两台Dell R730(2*E5-2670 v3,64GB内存),RAID卡为PERC H730P Mini(2GB Cache),每台5个Intel SSD 730 480GB做一个RAID5(Strip Size 128KB,Write Back,No Read Ahead),将两台节点上的SSD RAID做成一个GPFS测试。

测试命令 write rewrite read reread
iozone -i 0 -i 1 -r 128K -s 128G -t 2 -+m ./io 2595 2777 4514 4584
iozone -i 0 -i 1 -r 128K -s 2G -t 128 -+m ./io 3034 3823 4543 4582
iozone -i 0 -i 1 -r 128K -s 1G -t 256 -+m ./io 2963 3767 4505 4569
iozone -i 0 -i 1 -r 128K -s 512M -t 512 -+m ./io 2783 3549 2290 2307
iozone -i 0 -i 1 -r 128K -s 256M -t 1024 -+m ./io 2204 3743 2683 2715
iozone -i 0 -i 1 -r 64K -s 128G -t 2 -+m ./io 2504 3927 4474 4581
iozone -i 0 -i 1 -r 64K -s 2G -t 128 -+m ./io 3074 3752 4507 4584
iozone -i 0 -i 1 -r 64K -s 1G -t 256 -+m ./io 2949 3952 4509 4575
iozone -i 0 -i 1 -r 64K -s 512M -t 512 -+m ./io 2826 3565 4481 4554
iozone -i 0 -i 1 -r 64K -s 256M -t 1024 -+m ./io 2288 3647 2656 2751
iozone -i 0 -i 1 -r 32K -s 128G -t 2 -+m ./io 2507 3601 4379 4559
iozone -i 0 -i 1 -r 32K -s 2G -t 128 -+m ./io 3065 3518 4501 4587
iozone -i 0 -i 1 -r 32K -s 1G -t 256 -+m ./io 2956 3540 4516 4582
iozone -i 0 -i 1 -r 32K -s 512M -t 512 -+m ./io 2810 3587 4500 4550
iozone -i 0 -i 1 -r 32K -s 256M -t 1024 -+m ./io 2310 3224 2692 2734
iozone -i 0 -i 1 -r 16K -s 128G -t 2 -+m ./io 2517 3566 4404 4579
iozone -i 0 -i 1 -r 16K -s 2G -t 128 -+m ./io 3058 3524 4494 4571
iozone -i 0 -i 1 -r 16K -s 1G -t 256 -+m ./io 2557 2675 2669 2675
iozone -i 0 -i 1 -r 16K -s 512M -t 512 -+m ./io 2406 2491 2553 2530
iozone -i 0 -i 1 -r 16K -s 256M -t 1024 -+m ./io 2056 1953 2125 2178
iozone -i 0 -i 1 -r 8K -s 128G -t 2 -+m ./io 3179 3620 4421 4513
iozone -i 0 -i 1 -r 8K -s 2G -t 128 -+m ./io 2794 2868 3082 3045
iozone -i 0 -i 1 -r 8K -s 1G -t 256 -+m ./io 1327 1366 1348 1352
iozone -i 0 -i 1 -r 8K -s 512M -t 512 -+m ./io 1242 1269 1304 1253
iozone -i 0 -i 1 -r 8K -s 256M -t 1024 -+m ./io 1214 1121 1164 1151
iozone -i 0 -i 1 -r 4K -s 128G -t 2 -+m ./io 2370 2816 3809 3854
iozone -i 0 -i 1 -r 4K -s 2G -t 128 -+m ./io 1462 1485 1594 1596
iozone -i 0 -i 1 -r 4K -s 1G -t 256 -+m ./io 675 684 716 729
iozone -i 0 -i 1 -r 4K -s 512M -t 512 -+m ./io 623 627 639 643
iozone -i 0 -i 1 -r 4K -s 256M -t 1024 -+m ./io 645 618 575 575

Intel SSD 730 测试

Dell R730(2*E5-2670 v3,64GB内存,H730P),4个Intel SSD 730 480GB做JBOD,系统中将四个SSD做成GPFS测试

 测试命令 write rewrite read reread
iozone -i 0 -i 1 -r 128K -s 128G -t 1 1939 1899 2132 2142
iozone -i 0 -i 1 -r 128K -s 2G -t 64 1900 1925 2076 2127
iozone -i 0 -i 1 -r 128K -s 1G -t 128 1971 1898 2145 2141
iozone -i 0 -i 1 -r 128K -s 512M -t 256 1642 1872 991 1047
iozone -i 0 -i 1 -r 64K -s 128G -t 1 1960 1866 2139 2138
iozone -i 0 -i 1 -r 64K -s 2G -t 64 1871 1891 2110 2140
iozone -i 0 -i 1 -r 64K -s 1G -t 128 1948 1895 2152 2141
iozone -i 0 -i 1 -r 64K -s 512M -t 256 1555 1830 1066 1073
iozone -i 0 -i 1 -r 32K -s 128G -t 1 1904 1916 2063 2110
iozone -i 0 -i 1 -r 32K -s 2G -t 64 1937 1867 2142 2129
iozone -i 0 -i 1 -r 32K -s 1G -t 128 1886 1916 2038 2112
iozone -i 0 -i 1 -r 32K -s 512M -t 256 1855 1843 2067 2043
iozone -i 0 -i 1 -r 16K -s 128G -t 1 1881 1909 2037 2136
iozone -i 0 -i 1 -r 16K -s 2G -t 64 1962 1870 2100 2052
iozone -i 0 -i 1 -r 16K -s 1G -t 128 1320 1305 1331 1320
iozone -i 0 -i 1 -r 16K -s 512M -t 256 1251 1266 1258 1266
iozone -i 0 -i 1 -r 8K -s 128G -t 1 1858 1873 2111 2142
iozone -i 0 -i 1 -r 8K -s 2G -t 64 1437 1455 2047 1510
iozone -i 0 -i 1 -r 8K -s 1G -t 128 671 661 680 681
iozone -i 0 -i 1 -r 8K -s 512M -t 256 629 637 641 643
iozone -i 0 -i 1 -r 4K -s 128G -t 1 1458 1620 1764 1878
iozone -i 0 -i 1 -r 4K -s 2G -t 64 750 758 792 794
iozone -i 0 -i 1 -r 4K -s 1G -t 128 337 332 341 339
iozone -i 0 -i 1 -r 4K -s 512M -t 256 316 316 316 317

Dell Compellent SCv2080 测试

Dell Compellent SCv2080,双控,每控制器8GB缓存,满配84颗4TByte 3.5-inch 7.2Krpm NL-SAS。建立4个Volumes,每个Volumes容量50TB,模式为RAID 10-DM和RAID 6-10,所以实际测试的是RAID 10-DM的性能。四个卷全部映射给两台Dell R730(2*E5-2670 v3,64GB内存,单卡双口8Gb FC)IO服务器,与存储通过两台8Gb光纤交换机冗余连接。四个卷做成一个GPFS进行测试。每个IO节点通过2个万兆做LACP和核心交换机连接,6个刀片计算节点通过1个万兆和刀箱交换机连接,刀箱交换机通过2个万兆做LACP和核心交换机连接。

io为两个IO节点测试,blade为6个刀片节点测试,测试进程平均分配,单位MB/sec

 测试命令 write rewrite read reread
iozone -i 0 -i 1 -r 128K -s 128G -t 2 -+m ./io 1555 1574 2587 2600
iozone -i 0 -i 1 -r 128K -s 12G -t 20 -+m ./io 1573 1591 2560 2573
iozone -i 0 -i 1 -r 128K -s 6G -t 40 -+m ./io 1587 1602 2829 2817
iozone -i 0 -i 1 -r 128K -s 3G -t 80 -+m ./io 1600 1602 2882 2889
iozone -i 0 -i 1 -r 128K -s 1G -t 288 -+m ./io 1586 1600 2827 2841
iozone -i 0 -i 1 -r 128K -s 4G -t 252 -+m ./io 1564 1613 2844 2803
iozone -i 0 -i 1 -r 128K -s 4G -t 252 -+m ./io 1578 1616 2799 2805
iozone -i 0 -i 1 -r 128K -s 2G -t 504 -+m ./io 1050 1591 1710 1689
iozone -i 0 -i 1 -r 128K -s 1G -t 1008 -+m ./io 486 963 284 277
iozone -i 0 -i 1 -r 64K -s 4G -t 252 -+m ./io 1587 1611 2841 2848
iozone -i 0 -i 1 -r 64K -s 2G -t 504 -+m ./io 1093 1586 1751 1717
iozone -i 0 -i 1 -r 64K -s 1G -t 1008 -+m ./io 306 379 91 91
iozone -i 0 -i 1 -r 32K -s 4G -t 252 -+m ./io 1585 1612 2871 2875
iozone -i 0 -i 1 -r 32K -s 2G -t 504 -+m ./io 1161 1550 1764 1775

NetApp E2600 High Performance Tier 测试

浪潮 AS500H (NetApp E2600,MD3600也一样),双控制器,每控制器 4GB 带电池保护缓存,Write caching with mirroring, High Performance Tier。IO节点与存储双控通过MiniSAS冗余连接

测试命令:iozone -i 0 -i 1 -r 128K -s 128G

Basic High Performance Tier (MB/s)
write rewrite read reread write rewrite read reread
900GByte 2.5-inch 10Krpm 6Gb/s SAS
2个盘做一组RAID1
171 172 177 175 173 171 176 175
900GByte 2.5-inch 10Krpm 6Gb/s SAS
每5个盘做一组RAID5,4组RAID5
689 688 1892 1971 1447 1539 2440 2531
3TByte 3.5-inch 7.2Krpm 6Gb/s NL-SAS
每6个盘做一组RAID6,2组RAID6
629 617 832 867 839 801 819 856

 

IBM GPFS 仲裁机制

为维护数据一致性,防止集群出现“脑裂”的情况,GPFS设计了GPFS系统的仲裁机制:

节点仲裁:
将集群中的一些节点定义为仲裁节点(quorum nodes),每个节点如能和一半以上的仲裁节点成功通讯则GPFS可用,否则GPFS不可用。一半以上仲裁节点的意义是,1个要求1个、2个要求2个、3个要求2个、4个要求3个、5个要求3个,这样保证如果由于某些原因(如网络故障)导致集群分割,只有一个子集群GPFS可用。

节点仲裁和决胜磁盘(tiebreaker disks):
集群中仲裁节点不超过8个且应该包含集群主次配置服务器(primary and secondary cluster configuration servers),每个仲裁节点连接到所有决胜磁盘,则可以定义1-3个决胜磁盘但最好是奇数,只要有仲裁节点有一半以上的决胜磁盘可用则GPFS可用,否则GPFS不可用。这种模式适合小集群,特别只有两个NSD server和共享存储的情况,这时这两个NSD server还是cluster configuration servers和quorum nodes,共享存储上的某些LUN定义为决胜磁盘,这样两个NSD server坏一个整个GPFS还是可用的。

上面说的仲裁节点选择有一些原则:
一直开机稳定运行的节点
位于不同机架、不同供电来源、连接不同交换机的节点
最好包含这些节点:Primary configuration servers、Secondary configuration servers、Network Shared Disk servers
仲裁节点不是越多越好,最好奇数个且不要超过7,如3、5、7
仲裁节点应该是集群的核心节点,且能够代表集群

前面说的仲裁都是仲裁本地的GPFS是否可用,GPFS还有机制可以将一份数据复写2-3次,相当于做了NSD级别的Raid1,这样在损失一些NSD的情况下文件系统可能仍然可用,这个时候就需要对GPFS中的某个文件系统进行冲裁。

文件系统描述符(File system descriptor)仲裁:
在创建文件系统的时候,GPFS会根据NSD和故障组的情况在某些个NSD上面创建文件系统描述符,运行时根据可用的描述符数量来判断这个文件系统是否可用。
如果有至少5个不同的故障组则创建5个描述符副本,至少3个副本可用;

如果有至少3个NSD则创建3个描述符副本,至少2个副本可用;
如果只有1-2个NSD则每个NSD创建一个描述符副本,一个都不能少。
对于少于5个故障组,特别是只有2个故障组的情况,必定存在某一个故障组失效的情况下这个文件系统会不符合上述要求而被关闭的情况,可以通过创建专门的descOnly NSD来平衡描述符副本的分配,从而防止系统存在单点故障。