分类 运维技术 下的文章

我们在近期运营中，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.

- 阅读剩余部分 -

巡检中发现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

- 阅读剩余部分 -

Proxmox+VE用于公有云、VPS的可靠性得到了很多同行长期的验证认可，整个生态环境也满足我的需求，所需功能也基本都能满足，所以我开始用PVE了。我考虑用本地存储，如果是用智简魔方的公有云平台，一般情况只有硬卡RAID10是最好方案；但PVE出现了多个方案，我挑了几个，但很犹豫哪个最合适我：ZFS-RAID-Z2、ZFS-RAID-Z3、ZFS-RAID10，以及硬卡RAID10。

- 阅读剩余部分 -

今天遇到一个很狗血的问题…有1台华为S6720-32X-LI-32S-AC万兆交换机，设备只跑了100Mbps左右，但交换机的统计却显示跑了7-8%，也就是800Mbps左右。

输入 dis mac-address 检查发现没有学习到任何mac地址，判断可能是流量泛洪。

MAC地址转发时，采用相同的HASH算法去查找对应的VLAN+MAC表项，如果无法找到对应的表项，则产生流量泛洪。

- 阅读剩余部分 -

基于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()

如果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

- 阅读剩余部分 -

  1. 1
  2. 2
  3. 3
  4. 4
  5. ...
  6. 13