野草博客 - 运维技术
type: channel
link: http://www.cnweed.com/category/system/
items: Proxmox VE的ZFS（系统启动盘）如何更换故障盘
items: Proxmox Backup Server增量备份魔方云
items: Proxmox VE pve-firewall : status update error: iptables_restore_cmdlist : Try `iptables-restore -h'
items: Proxmox VE的ZFS如何更换故障盘
items: Proxmox VE的ZFS-RAID-Z2与ZFS-RAID-Z3，以及硬卡RAID10差异
items: 华为S6720-32X-LI-32S-AC交换机不学习MAC
items: Python对mdadm组建的RAID软列阵定时检测异常自动短信/电话通知
items: DELL630 H730P RAID10不同Strip Size设置的IOPS差异
items: Linux CEPH RAID0 OSD使用MegaCli在线禁用磁盘缓存
items: Linux MegaCli 根据盘符获取 RAID 位置与 盘位

Proxmox VE的ZFS（系统启动盘）如何更换故障盘
type: item
date: 2025-12-14T17:22:00+00:00
description: 之前写过一篇PVE ZFS更换故障盘的文章“Proxmox VE的ZFS如何更换故障盘”，有个大佬点评：其实你这样替换会有些问题，因为是用一个新盘的整盘替换了一个旧盘的分区。随着不停替换，以后会影响启动的。目前看没问题。我挺在意这个问题，所以去查了一下，在Reddit和一些论坛上确实有人分享这个经验，和大佬点评的一样：如果像我之前那样直接把整盘当作新设备加入，而 ZFS 最初 pool 是以 “分区 (partition)” 作为 member（例如p3）的话，可能造成分区结构和 GUID / 分区表不一致，长期累积多次替换，可能会影响启动 (boot)，尤其是当 pool 包含系统盘(boot pool / rpool) 的情况下。也有人说如果新盘没有明确 copy 分区表 (partition layout) + 重建 boot 分区 (EFI/BIOS) + 安装boot loader (如 grub 或 proxmox-boot-tool)，系统可能无法从新盘启动。可以看到，这些问题都是基于将ZFS作为系统盘启动会遇到的，如果你不是将ZFS作为系统盘，而是作为数据盘则我原文是没问题的。但如果将ZFS作为系统盘，则建议使用下文方法更换故障盘，避免潜在风险。在此谢谢大佬指正！本文以/dev/nvme2n1故障为例，其实也不能说是故障，这个设备不支持3个PCIE 4.0的U.2盘，装上容易掉盘，当前虽然lsscsi显示了盘，实际上是不可用的，可以看到zfs status中有个盘状态是REMOVED。root@usa-zfs-amd-23:~# lsscsi [16:0:0:0] cd/dvd AMI Virtual CDROM0 1.00 /dev/sr0 [N:0:0:1] disk INTEL SSDPF2KX038XZ__1 /dev/nvme0n1 [N:1:0:1] disk INTEL SSDPF2KX038XZ__1 /dev/nvme1n1 [N:2:0:1] disk INTEL SSDPF2KX038XZ__1 /dev/nvme2n1 root@usa-zfs-amd-23:~# root@usa-zfs-amd-23:~# ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx 1 root root 9 Jun 12 11:05 pci-0000:04:00.3-usb-0:2.1:1.0-scsi-0:0:0:0 -> ../../sr0 lrwxrwxrwx 1 root root 13 Jun 12 11:05 pci-0000:41:00.0-nvme-1 -> ../../nvme2n1 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:41:00.0-nvme-1-part1 -> ../../nvme2n1p1 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:41:00.0-nvme-1-part2 -> ../../nvme2n1p2 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:41:00.0-nvme-1-part3 -> ../../nvme2n1p3 lrwxrwxrwx 1 root root 13 Jun 12 11:05 pci-0000:82:00.0-nvme-1 -> ../../nvme0n1 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:82:00.0-nvme-1-part1 -> ../../nvme0n1p1 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:82:00.0-nvme-1-part2 -> ../../nvme0n1p2 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:82:00.0-nvme-1-part3 -> ../../nvme0n1p3 lrwxrwxrwx 1 root root 13 Jun 12 11:05 pci-0000:83:00.0-nvme-1 -> ../../nvme1n1 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:83:00.0-nvme-1-part1 -> ../../nvme1n1p1 lrwxrwxrwx 1 root root 15 Jun 12 11:05 pci-0000:83:00.0-nvme-1-part2 -> ../…

Proxmox Backup Server增量备份魔方云
type: item
date: 2025-11-02T01:00:00+00:00
description: PBS备份PVE很好用，对于PVE以外的系统，PBS给了proxmox-backup-client这个客户端，在Debian/Ubuntu下有官方维护的包，但CentOS下没有。github上有个大神封装了RHEL8和RHEL9的客户端，也支持RockyLinux8 / RockyLinux9 / AlmaLinux8 / AlmaLinux 9。魔方云有提供一个冷备份的功能，但是我不太喜欢。魔方云的这个冷备份功能是通过libvirt的blockcopy功能导出备份，然后scp去备份服务器。例如：virsh -c qemu+tcp:///system blockcopy kvm100 vda --xml /home/kvm/kvm100/backup-disk.xml --wait --transient-job --verbose 这样能安全的克隆出正在运行的虚拟机副本，但这也相当于将虚拟机全盘在宿主服务器硬盘重写了一遍，然后再全盘scp复制去备份服务器硬盘也重写一边，每次备份都会重复这一循环。对硬盘寿命的损耗、和每次scp出去对内网宽带的占用是很大的，另外我测试单节点3TB+数据、200虚拟机、内网到备份服务器10Gbps端口的情况下，魔方云冷备份需要24小时左右耗时也很长。PBS支持权限控制、备份压缩等，最重要的是支持增量备份，这点很好！完成首次备份之后，第二次备份它会校对首次备份数据和本次备份数据，只会备份和传输修改、新增部分，这意味着之后的备份不用再次“全盘打包”以“劳民伤财”的方式进行。如果你直接用proxmox-backup-client客户端备份魔方云的/home目录，那么对正在运行的虚拟机来说，这个备份数据是不完整的，将丢失还未存储的临时数据，比如内存中待写入硬盘的数据、缓存数据。对备份高要求的人来说，应该和魔方云官方做法一样，写个脚本读取所有kvmid，然后通过libvirt的blockcopy功能逐个导出备份，然后再通过proxmox-backup-client客户端上传，然后删除本地的备份，循环这步骤。但对我这种不承诺提供备份、也无备份服务，仅做内部安全风险控制的，直接默认整个/home打包就行，简单、方便。这种备份也不是不能用，因为现代系统是具备纠错功能的，你恢复后其实就相当于断电关机后再启动。对要求不高的普通用户来说比起极端情况下数据丢失，断电关机这点影响算不得什么。当然，如果是收了客户备份的钱，还是建议开放魔方云自己的冷备份功能给客户或者基于blockcopy进行备份。魔方云宿主服务器系统是CentOS Stream 8，需要安装大佬封装的客户端：https://github.com/TomGem/proxmox-backup-client安装依赖：dnf install systemd-libs libgcc libzstd libacl fuse3-libs libuuid openssl-libs 下载并安装rpm：wget https://github.com/TomGem/proxmox-backup-client/releases/download/3.0.4/proxmox-backup-3.0.4-1.rhel8.x86_64.rpm dnf install proxmox-backup-3.0.4-1.x86_64.rpm 完成后查看版本能正常输出就安装好了：proxmox-backup-client version PBS配置好以后在魔方云宿主服务器登入测试：[root@node127 ~]# proxmox-backup-client login --repository mfy-hk-platinum-33@pbs@192.168.2.253:8007:mfy-hk-platinum-33 Password for "mfy-hk-platinum-33@pbs": ****************** fingerprint: 40:6d:39:a2:32:45:ee:ac:28:d4:24:eb:89:79:ac:54:11:a7:33:f9:29:d1:ef:21:d0:cb:83:73:bf:f1:d6:5e Are you sure you want to continue connecting? (y/n): y fingerprint: 40:6d:39:a2:32:45:ee:ac:28:d4:24:eb:89:79:ac:54:11:a7:33:f9:29:d1:ef:21:d0:cb:83:73:bf:f1:d6:5e Are you sure you want to continue connecting? (y/n): y 备份整个/home目录pr…

Proxmox VE pve-firewall : status update error: iptables_restore_cmdlist : Try `iptables-restore -h'
type: item
date: 2024-08-22T05:21:00+00:00
description: 我们在近期运营中，PVE节点开通的VM客户反馈了一些异常情况：1、PVE VM启用firewall/ macfilter/ ipfilter，ipset rules正确，但没有网络，重装系统/ 防火墙关闭也无法恢复；但在PVE VM网卡停用firewall网络即恢复。2、PVE VM网络正常，但firewall rules不生效。3、pve-firewall出现错误: status update error: iptables_restore_cmdlist: Try `iptables-restore -h' or 'iptables-restore --help' for more information.对于第1个问题，通过简单的排错可以很明确知道是firewall异常，但在PVE GUI发现防火墙处于运行状态。登入SSH运行:iptables-save -c | grep 2804（This is vmid） 找到异常VM的iptables规则:[0:0] -A tap2804i0-OUT -m mac ! --mac-source bc:24:11:b8:97:88 -j DROP tap2804i0中，2804是vmid，i0是第0个网卡；根据这个信息，对比iptables规则与vm的mac确认了mac是不匹配的。由此可以确认firewall已经异常，无法正常更新iptables rules。（tip：pve-firewall并不是独立组件，它最终会生成命令载入iptables。）如果我们简单pve-firewall restart，此时VM网络即恢复正常。看似一切正常，但第2个问题即出现，所有防火墙规则失效。当我再次执行iptables-save -c，返回已经只剩下：~# iptables-save -c # Generated by iptables-save v1.8.9 on Wed Aug 21 19:00:45 2024 *raw :PREROUTING ACCEPT [348735666585:213325671547273] :OUTPUT ACCEPT [4591886294:3380972084311] COMMIT # Completed on Wed Aug 21 19:00:45 2024 # Generated by iptables-save v1.8.9 on Wed Aug 21 19:00:45 2024 *filter :INPUT ACCEPT [6813060:3638198461] :FORWARD ACCEPT [215129855:125354233180] :OUTPUT ACCEPT [5768979:4211817661] COMMIT 这是因为pve-firewall生成的iptables rules存在错误，无法被载入到iptables。执行systemctl status pvefw-logger pve-firewall可以看到类似的错误日志：root@testnode:~# systemctl status pvefw-logger pve-firewall ● pvefw-logger.service - Proxmox VE firewall logger Loaded: loaded (/lib/systemd/system/pvefw-logger.service; enabled; preset: enabled) Active: active (running) since Wed 2024-08-21 00:00:09 HKT; 19h ago Main PID: 1649446 (pvefw-logger) Tasks: 2 (limit: 629145) Memory: 444.0K CPU: 8.328s CGroup: /system.slice/pvefw-logger.service └─1649446 /usr/sbin/pvefw-logger Aug 21 00:00:09 testnode systemd[1]: Starting pvefw-logger.service - Proxmox VE firewall logger... Aug 21 00:00:09 testnode pvefw-logger[1649446]: starting pvefw logger Aug 21 00:00:09 testnode systemd[1]: Started pvefw-logger.service - Proxmox VE firewall logger. ● pve-firewall.service - Pro…

Proxmox VE的ZFS如何更换故障盘
type: item
date: 2024-06-12T15:21:00+00:00
description: 巡检中发现PVE的zfs-raidz2坏了一个盘，查询显示：~# zpool status rpool pool: rpool state: DEGRADED status: One or more devices has been removed by the administrator. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Online the device using zpool online' or replace the device with 'zpool replace'. scan: scrub repaired 0B in 00:43:00 with 0 errors on Sun May 12 01:07:02 2024 config: NAME STATE READ WRITE CKSUM rpool DEGRADED 0 0 0 raidz2-0 DEGRADED 0 0 0 ata-INTEL_SSDSC2KB019TZ_PHYI334000GD1P9DGN-part3 ONLINE 0 0 0 ata-INTEL_SSDSC2KB019TZ_PHYI334000NS1P9DGN-part3 ONLINE 0 0 0 ata-INTEL_SSDSC2KB019TZ_PHYI334000Q21P9DGN-part3 ONLINE 0 0 0 ata-INTEL_SSDSC2KB019TZ_PHYI334000Y91P9DGN-part3 ONLINE 0 0 0 ata-INTEL_SSDSC2KB019TZ_PHYI334000GE1P9DGN-part3 REMOVED 0 0 0 请留意，如果你将ZFS作为数据盘则本文适用；如果作为系统盘（系统安装在ZFS）请通过替换分区方式更换故障盘，避免潜在风险：https://www.cnweed.com/archives/4420/故障盘的状态已经是 REMOVED。我现在把坏的拔出来，插入了一个新的盘，再次执行 zpool status rpool 回显信息是不变的。但ls -la /dev/disk/by-id 可以看到没有配置的 sdd 盘：~# ls -la /dev/disk/by-id total 0 drwxr-xr-x 2 root root 720 Jun 11 00:30 . drwxr-xr-x 8 root root 160 Apr 29 11:33 .. lrwxrwxrwx 1 root root 9 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000GD1P9DGN -> ../../sda lrwxrwxrwx 1 root root 10 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000GD1P9DGN-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000GD1P9DGN-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000GD1P9DGN-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 May 12 00:38 ata-INTEL_SSDSC2KB019TZ_PHYI334000NS1P9DGN -> ../../sdb lrwxrwxrwx 1 root root 10 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000NS1P9DGN-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000NS1P9DGN-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000NS1P9DGN-part3 -> ../../sdb3 lrwxrwxrwx 1 root root 9 Apr 29 11:33 ata-INTEL_SSDSC2KB019TZ_PHYI334000Q21P9DGN -…

Proxmox VE的ZFS-RAID-Z2与ZFS-RAID-Z3，以及硬卡RAID10差异
type: item
date: 2024-04-21T12:19:00+00:00
description: Proxmox+VE用于公有云、VPS的可靠性得到了很多同行长期的验证认可，整个生态环境也满足我的需求，所需功能也基本都能满足，所以我开始用PVE了。我考虑用本地存储，如果是用智简魔方的公有云平台，一般情况只有硬卡RAID10是最好方案；但PVE出现了多个方案，我挑了几个，但很犹豫哪个最合适我：ZFS-RAID-Z2、ZFS-RAID-Z3、ZFS-RAID10，以及硬卡RAID10。首先硬卡RAID10就被淘汰了，因为我计划使用NVMe+U.2的盘，常见的硬卡无法对U.2做列阵。列阵原理：ZFS-RAID-Z2、ZFS-RAID-Z3以下官方的解释：A raidz group can have single, double, or triple parity, meaning that the raidzgroup can sustain one, two, or three failures, respectively, without losing anydata.The raidz1 vdev type specifies a single-parity raidz group; the raidz2 vdev type specifies a double-parity raidz group; and the raidz3 vdev typespecifies a triple-parity raidz group.The raidz vdev type is an alias for raidz1.通俗理解就是如果我有6个NVMe+U.2盘组建ZFS-RAID-Z2，则最大可以故障任意2个盘；ZFS-RAID-Z3+则可以最大故障任意3个盘；而可用容量则是6个盘-2个盘（Z2），或3个盘（Z3）。ZFS-RAID-Z10与硬卡RAID10是相同的原理。多个RAID1组建为RAID0，则为RAID10，只能大于等于4的偶数盘位数量组建，可用容量为一半。性能区别：6个盘的情况下，我测试了ZFS-RAID-Z10、ZFS-RAID-Z2性能差别不大，但可用容量Z2多出了1个盘。安全性：有关安全性的讨论很激烈，仁者见仁。RAID10我用了很多年，是非常可靠的，但并不意味着万无一失，正如上面提到的，其是多个RAID1(镜像)组建的RAID0。RAID10可以在故障多个盘的时候保持数据可用，可如果坏的2个盘是同一组镜像内的，RAID10列阵将损坏；即便你有12、24个盘的RAID10，同一组镜像内的盘坏了，也会面临同样的结局。我已经遇到了多次……但如果选用好的硬盘可以很大程度上减少这个情况，例如Intel+S4520+SSD，目前还没一例这个情况。ZFS-RAID-Z2和ZFS-RAID-Z3则面临着另外一个问题，当一个盘发生故障后，剩余磁盘的IO压力将增加，因此如果同步恢复速度慢（或没有即时去更换故障盘），剩下磁盘接连故障的可能性就会增加；而RAID10同一组镜像内故障了一个盘，另一个盘不会因此而IO压力增加，同一组镜像内接连故障的可能性相对较低。不同安全级别的硬盘磨损（重写）问题RAID10几乎没有写入放大问题，ZFS-RAIDZ-2/3则存在写入放大的问题，即写入1T数据实际可能会对硬盘写入2T，这会造成硬盘的寿命比预期更短，我们需要实际测试观察写入放大的程度，决定是否使用。如果是SATA+SSD用硬卡还是ZFS-RAID10呢？虽然可能会占用一些内存、CPU性能，但我个人仍然会更倾向ZFS-RAID10，因为其具备在线扩展的能力，初始硬盘数量并不需要特别大，如果不足时候可以后面再补硬盘扩大列阵，这些都可以通过PVE在线完成。虽然硬卡RAID10也可以后期扩展，但其操作相对复杂还有数据损坏的风险，且需要停机重启。结论我最后决定6盘的话使用+ZFS-RAIDZ-2，7-8盘位使用+ZFS-RAIDZ-3；我们使用了企业级的Intel+NVMe+U.2或者Intel+S4520，以及有人员可以即时响应更换，可以忽略写入放大的问题；但长期来看ZFS-RAID10仍然是安全、性能的最佳平衡。还有个情况就是ZFS-RAIDZ-2/3官方建议集群盘数量要小于等于16个，但我认为应该更小；大于10个盘应该选择RAID10。另外日常维护中，可以偶尔拔掉一两个盘和不同批次的硬盘互换、或者在组建之前逐一写入一些测试数据，让列阵中的盘写入寿命不相同，避免同时故障的可能性。本文参考：https://www.reddit.com/r/homelab/comments/15fzf44/zfs_raid10_or_raidz2_which_one_to_chose_for_6x1tb/https://www.reddit.com/r/Proxmox…

华为S6720-32X-LI-32S-AC交换机不学习MAC
type: item
date: 2023-06-19T14:48:32+00:00
description: 今天遇到一个很狗血的问题…有1台华为S6720-32X-LI-32S-AC万兆交换机，设备只跑了100Mbps左右，但交换机的统计却显示跑了7-8%，也就是800Mbps左右。输入 dis mac-address 检查发现没有学习到任何mac地址，判断可能是流量泛洪。MAC地址转发时，采用相同的HASH算法去查找对应的VLAN+MAC表项，如果无法找到对应的表项，则产生流量泛洪。尝试绑定mac-端口-vlan，后流量泛洪消失。mac-address static 0024-XXXX-424f GigabitEthernet 1/7/0/44 vlan 199 参考引用：https://support.huawei.com/enterprise/zh/knowledge/EKB1000601298检查了交换机里的配置，没有mac、arp相关的额外设置，也就是都是默认使能、最宽松的设置。然后检查了发生的时间，找了当日的其他配置，trunk上联interface Vlanif多加了一个/24。超出交换机限制？应该不至于，三十多个/24而已。S5720都不会出现这个情况，一脸懵逼。。。

Python对mdadm组建的RAID软列阵定时检测异常自动短信/电话通知
type: item
date: 2023-01-27T08:34:00+00:00
description: 基于mysubmail接口发送短信、电话语音通知。创建脚本后可以通过crontab -e每小时或半小时运行一次，例如：/30 * python /etc/weed/checkRAID.py可以在raid出现异常状态时快速获知及时处理，避免故障扩大。# -*- coding: utf-8 -*- #!/usr/bin/python import os import requests node = '香港vps-nvmenode-1' error = 0 def get_status(value): try: status = value.split(": ") return status[1].strip() except: return False def send_warning(): global node # 语音通知 voice_url = 'http://api.mysubmail.com/voice/send.json' voice_params = { 'appid': '*****', 'to': '13200000000', 'content': '紧急事态：'+node+'硬盘状态异常，请立即检查', 'signature': '**************' } #voice_res = requests.post(voice_url, data=voice_params) # print voice_res.text # 短信通知 message_url = 'http://api.mysubmail.com/message/send.json' message_params = { 'appid': '*****', 'to': '13200000000', 'content': '【XXX】紧急事态：'+node+'硬盘状态异常，请立即检查', 'signature': '**************' } message_res = requests.post(message_url, data=message_params) # print(message_res.text) # 检查RAID状态，注意/dev/md10是变动参数，自行fdisk -l查看你的软列阵磁盘名称，如raid1则为/dev/md1 raidinfos = os.popen('mdadm -D /dev/md10').readlines() for raidinfo in raidinfos: raidinfo = raidinfo.strip('\n') print(raidinfo) if "State : " in raidinfo: status = get_status(raidinfo) if status != 'active' and status != 'active, checking': error = 1 if "Failed Devices : " in raidinfo: status = get_status(raidinfo) if status != '0': error = 1 if "Active Devices : " in raidinfo: status = get_status(raidinfo) if status != '2': error = 1 # 发送通知 if error == 1: send_warning()

DELL630 H730P RAID10不同Strip Size设置的IOPS差异
type: item
date: 2023-01-24T03:28:00+00:00
description: 服务器配置：DELL 630，E5-2680v42，32GB DDR416，H730P列阵卡。RAID10高级配置：Read Policy/默认，Write Policy/Write Back，Disk cache Policy/默认（启用）。根据测试结果，默认Strip Size 64K有助于提高4K IOPS，磁盘数量6个或4个IOPS差异并不是非常大。SAMSUNG 870 EVO保固信息：1TB 600 TBW，2TB 1200 TBW，4TB 2400 TBW。当前价格上 1TB约650HKD，2TB约1250HKD；如果按照61TB则需要3900HKD，42TB则需要5000HKD，在性能、价格差异不是很大的情况下，选择4*2TB组建RAID10将获得双倍的TBW，但较少的磁盘数量安全性将有所下降，同时故障2个盘或以上是时有发生的。6*1TB SAMSUNG 870 EVO，Strip Size: 1MBfio Disk Speed Tests (Mixed R/W 50/50): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 87.45 MB/s (21.8k) | 1.19 GB/s (18.6k) Write | 87.68 MB/s (21.9k) | 1.20 GB/s (18.7k) Total | 175.14 MB/s (43.7k) | 2.39 GB/s (37.4k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 1.53 GB/s (2.9k) | 1.50 GB/s (1.4k) Write | 1.61 GB/s (3.1k) | 1.60 GB/s (1.5k) Total | 3.14 GB/s (6.1k) | 3.11 GB/s (3.0k) 6*1TB SAMSUNG 870 EVO，Strip Size: 64Kfio Disk Speed Tests (Mixed R/W 50/50): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 94.86 MB/s (23.7k) | 898.86 MB/s (14.0k) Write | 95.11 MB/s (23.7k) | 903.59 MB/s (14.1k) Total | 189.98 MB/s (47.4k) | 1.80 GB/s (28.1k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 1.55 GB/s (3.0k) | 1.68 GB/s (1.6k) Write | 1.63 GB/s (3.1k) | 1.79 GB/s (1.7k) Total | 3.18 GB/s (6.2k) | 3.47 GB/s (3.3k) 4*1TB SAMSUNG 870 EVO，Strip Size: 64K缓存fio Disk Speed Tests (Mixed R/W 50/50): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 90.71 MB/s (22.6k) | 811.66 MB/s (12.6k) Write | 90.95 MB/s (22.7k) | 815.93 MB/s (12.7k) Total | 181.66 MB/s (45.4k) | 1.62 GB/s (25.4k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 1.65 GB/s (3.2k) | 1.39 GB/s (1.3k) Write | 1.74 GB/s (3.4k) | 1.49 GB/s (1.4k) Total | 3.39 GB/s (6.6k) | 2.89 GB/s (2.8k)

Linux CEPH RAID0 OSD使用MegaCli在线禁用磁盘缓存
type: item
date: 2022-03-25T15:50:00+00:00
description: 如果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 如果要启用target id 0 （系统盘）缓存则运行：/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp -EnDskCache -Immediate -L0 -a0 查看结果：# /opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp -DskCache -Lall -a0 Adapter 0-VD 0(target id: 0): Disk Write Cache : Disabled Adapter 0-VD 1(target id: 1): Disk Write Cache : Disabled Adapter 0-VD 2(target id: 2): Disk Write Cache : Disabled Adapter 0-VD 4(target id: 4): Disk Write Cache : Disabled Adapter 0-VD 5(target id: 5): Disk Write Cache : Disabled Adapter 0-VD 7(target id: 7): Disk Write Cache : Disabled Adapter 0-VD 8(target id: 8): Disk Write Cache : Disabled 如果计划对RAID0使用RAID的缓存，则务必确保机器电池有电要定期检查，否则突然断电可能造成RAID缓存中的数据丢失，这种情况很少，但还是要留意；最好是不启用RAID的缓存，也就是直写硬盘，或者writethrough模式。如果还没买设备，或者后面还有计划增加设备，最好买有直通的raid卡！如果因为一些原因没办法用直通卡，只能raid0来创建osd则建议禁用磁盘缓存、禁用raid卡缓存或使用writethrough模式。学习参考自：https://bean-li.github.io/disk-cache-policy/https://serverfault.com/questions/505275/megaraid-changing-cache-policy-onlinehttps://www.dell.com/community/PowerEdge-HDD-SCSI-RAID/How-do-I-view-change-physical-disk-cache-policy-on-PowerEDGE/td-p/2581739

Linux MegaCli 根据盘符获取 RAID 位置与 盘位
type: item
date: 2022-03-25T15:09:00+00:00
description: 我的CEPH OSD因为列阵卡不支持直通是基于RAID0的，最近ceph性能不足，排查过程iostat观察发现有一些盘r_await或w_await持续1000多，这就需要换盘了。ceph存储一份数据如果是默认3副本，那么就会3份副本写完才会完成写入，如果有1个osd延迟很高，就会影响整体写入速度。首先可以运行 ceph-volume lvm list 查看osd对应的盘符，如果是bcache，则需要再运行lsblk查看在哪个盘符下。然后查看是哪个盘符，以及盘位，进行更换重建。Python基于MegaCli获取raid卡状态的代码：https://raw.githubusercontent.com/eLvErDe/hwraid/master/wrapper-scripts/megaclisas-status这个大佬的python脚本可以快速帮忙定位，运行完后再执行下：lsscsi 查看盘符在系统中的编号就可以定位到盘了，记得MegaCli得先安装。代码贴上：#!/usr/bin/python # $Id: megaclisas-status,v 1.78 2018/10/01 03:52:57 root Exp root $ # # Written by Adam Cecile <gandalf@NOSPAM.le-vert.net> # Modified by Vincent S. Cojot <vincent@NOSPAM.cojot.name> # import os import re import sys import pdb import inspect import argparse os.system('lsscsi') if sys.platform == "win32": import ctypes def_megaclipath = "/opt/MegaRAID/MegaCli/MegaCli64" # Non-Nagios Mode defaults nagiosmode = False nagiosoutput = "" nagiosgoodarray = 0 nagiosbadarray = 0 nagiosgooddisk = 0 nagiosbaddisk = 0 # Sane defaults printarray = True printcontroller = True debugmode = False notempmode = False totaldrivenumber = 0 totalconfdrivenumber = 0 totalunconfdrivenumber = 0 # Hardcode a max of 16 HBA and 128 LDs for now. LDTable must be initialized to accept populating list of LD's into each ctlr's list. MaxNumHBA = 16 MaxNumLD = 128 LDTable = [[] * MaxNumHBA for i in range(MaxNumLD)] NestedLDTable = [[False for i in range(MaxNumLD)] for j in range(MaxNumHBA)] # Outputs is a 'dict' of all MegaCLI outputs so we can re-use them during loops.. Outputs = {} ConfDisks = {} NagiosBadDisks = {} NagiosGoodDisks = {} # We need root access to query if __name__ == "__main__": # deal with command line options parser = argparse.ArgumentParser() parser.add_argument("--nagios", help="enable nagios support", action="store_true") parser.add_argument("--debug", help="enable debugging output", action="store_true") parser.add_argument("--notemp", help="disable temperature reporting", action="store_true") args = parser.parse_args() nagiosmode = a…