分类 运维技术 下的文章

如果RAID0用作CEPH OSD,则建议禁用磁盘级的缓存,也就是磁盘标签上写的那个256MB缓存:

# /opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp -DisDskCache -Immediate -Lall -aAll
                                     
Set Disk Cache Policy to Disabled on Adapter 0, VD 0 (target id: 0) success
Set Disk Cache Policy to Disabled on Adapter 0, VD 1 (target id: 1) success
Set Disk Cache Policy to Disabled on Adapter 0, VD 2 (target id: 2) success
Set Disk Cache Policy to Disabled on Adapter 0, VD 4 (target id: 4) success
Set Disk Cache Policy to Disabled on Adapter 0, VD 5 (target id: 5) success
Set Disk Cache Policy to Disabled on Adapter 0, VD 7 (target id: 7) success
Set Disk Cache Policy to Disabled on Adapter 0, VD 8 (target id: 8) success

- 阅读剩余部分 -

我的CEPH OSD因为列阵卡不支持直通是基于RAID0的,最近ceph性能不足,排查过程iostat观察发现有一些盘r_await或w_await持续1000多,这就需要换盘了。ceph存储一份数据如果是默认3副本,那么就会3份副本写完才会完成写入,如果有1个osd延迟很高,就会影响整体写入速度。

首先可以运行 ceph-volume lvm list 查看osd对应的盘符,如果是bcache,则需要再运行lsblk查看在哪个盘符下。然后查看是哪个盘符,以及盘位,进行更换重建。

- 阅读剩余部分 -

Every 1.0s: ceph -s                Wed Dec  8 10:55:43 2021

  cluster:
    id:     48ff8b6e-1203-4dc8-b16e-d1e89f66e28f
    health: HEALTH_ERR
            1 scrub errors
            Possible data damage: 1 pg inconsistent

  services:
    mon: 3 daemons, quorum ceph-node-1,ceph-node-2,ceph-node-3 (age 12h)
    mgr: ceph-node-2(active, since 4d), standbys: ceph-node-1, ceph-node-3
    osd: 20 osds: 19 up (since 16h), 19 in (since 16h)

  data:
    pools:   2 pools, 513 pgs
    objects: 2.19M objects, 8.1 TiB
    usage:   24 TiB used, 45 TiB / 70 TiB avail
    pgs:     512 active+clean
             1   active+clean+inconsistent

  io:
    client:   3.6 MiB/s rd, 14 MiB/s wr, 896 op/s rd, 1.41k op/s wr

收到CEPH错误报告,一个擦洗错误,CEPH会按设定时间定期检查所有pg校对多副本数据是否一致,而当数据不一致,又无法自身做出决断修复时就会报告错误。常规修复流程:

- 阅读剩余部分 -

今天接客户反映有台服务器下行速度有问题,一看交换机端口下行跑满了,但是在系统里iftop端口流量很低、很正常。

随后检查上联华为交换机,发现所有端口都有不同程度的错包情况、每个端口下行都跑的很高,部分没有客户的、都没开机的只是端口开着下行都在跑。

检查arp没有问题,猜测可能交换机问题,毕竟有两三年没重启了,虽然不知道原因,但保存临时配置重启了下交换机就恢复了。

其他可能的原因排查:https://support.huawei.com/enterprise/zh/knowledge/EKB1000601298

今天ceph db出现溢出情况,记录一下解决方式。

[root@ceph-node-1 ceph-admin-node]#  ceph health detail
 HEALTH_WARN 6 OSD(s) experiencing BlueFS spillover
[WRN] BLUEFS_SPILLOVER: 6 OSD(s) experiencing BlueFS spillover
     osd.4 spilled over 17 MiB metadata from 'db' device (3.6 GiB used of 35 GiB) to slow device
     osd.5 spilled over 47 MiB metadata from 'db' device (3.2 GiB used of 35 GiB) to slow device
     osd.6 spilled over 125 MiB metadata from 'db' device (3.1 GiB used of 35 GiB) to slow device
     osd.12 spilled over 4.1 MiB metadata from 'db' device (3.9 GiB used of 35 GiB) to slow device
     osd.13 spilled over 21 MiB metadata from 'db' device (3.8 GiB used of 35 GiB) to slow device
     osd.14 spilled over 22 MiB metadata from 'db' device (3.8 GiB used of 35 GiB) to slow device

- 阅读剩余部分 -

查看新插入的HDD Slot Number编号:

/opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL -NoLog|egrep "Enclosure Device ID|Slot Number|Device Id|Firmware state"

确认是3以后创建RAID0:

/opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r0[32:3] WB Direct -a0

- 阅读剩余部分 -

刚把ceph osd重建,为osd WAL/DB分配ssd专门的分区,同时也应用了bcache。想测试下不同bcache缓存模式下对性能的影响情况。

4个节点,节点配置:E5-2650/ 32GB内存 / 4*4TB ST4000NM0035 128MB缓存 + 三星zet983 480GB + 三星pro 500GB系统盘;zet983为每个hdd分配35GB DB分区、4GB WAL分区、50GB BCACHE分区。

- 阅读剩余部分 -

一般情况下可以操作以下参数实现速度控制,但是要留意,速度越快对集群性能的影响越大;可以动态的调整参数值,观察recovery对集群性能影响情况,找到合适自己的值,即不会对client请求造成过大影响的同时保障最优的recovery速度。

osd_recovery_max_single_start:指示每个可同时启动多少线程实现recovery

osd_backfill_retry_interval:osd在重试回填请求之前等待的秒数(默认30秒)

osd_recovery_sleep_hdd:指示hd磁盘在恢复过程中的休眠时间

osd_recovery_sleep_ssd:指示ssd磁盘在恢复过程中的休眠时间

osd_max_backfills:允许进出 OSD 的最大回填操作数。数字越大,恢复越快。

osd_recovery_max_active:OSD恢复请求的数量。数字越大,恢复越快。

osd_recovery_op_priority:恢复操作优先级,取值1-63,值越高占用资源越高,恢复越快。

osd_recovery_priority:同上,恢复操作的优先级,如过不希望影响业务,设置优先级低一些,数字越小,性能影响越小。

- 阅读剩余部分 -

我原来CEPH集群的OSD是默认方式创建的,即“ceph-deploy osd create ceph-node-1 --data /dev/bcache0”,因为性能遇到瓶颈,为了充分榨干nvme aic ssd,决定重建osd把WAL/DB分区放到nvme aic ssd上。目前社区和官方说只有重建方式,ceph允许同时存在2种不同的osd,所以可以平滑的过度。

我有4个节点,所以我每次重建4个osd,重建osd数量应保持在总数20%左右,不应一次性操作太多。

- 阅读剩余部分 -