我现在尽量让我的生活和工作保持在一个很慢的节奏，这样才有足够多的时间休息、看书、思考、保持心态的松弛，因为逐渐发现越发的追赶反而犯错的概率更大，就像买股票时候的追涨杀跌、关注短期收益反而最容易亏损。

但有时候不可避免的会因为某些事情会让内心非常浮躁、烦闷，对我自己最好的办法是马上放下工作或其他手头上的事情，除非停工就会立即对客户带来损失，否则立即投身到大自然中，去骑行、散步、看看山、看看水，会使浮躁的情绪很快冷却，有时候在路上突然就灵感迸发、让我烦闷的事情就突然想开了。

遇到下雨之类天气不好的时候，我发现做做运动，比如趴下做几组俯卧撑、深蹲，然后练练字也能达到类似的效果，十几块好几本行楷的临摹本，如果像我一样只是偶尔烦闷时候平复情绪，够写两三个月，还能让写的字更漂亮！虽然现在做互联网行业几乎很少场合需要写字，最多签个名字，但如果有这样的机会，漂亮的字会让人眼前一亮，比如我就很佩服、喜欢字漂亮的人。

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

  1. 1
  2. 2
  3. 3
  4. 4
  5. ...
  6. 64