0x00 前提

万兆的起源是发现了FLR和OCP, 虽然发现的时候已经很晚了, 价格上还是比较有优势的, 假垃圾佬上线.

我的万兆配置:
交换机: H3C S5130S-28S-SI
EPYC机器(PVE+TrueNAS): 530FLR 双口LACP
蜗牛星际(G4560 + ESXi 7): CX3 ALOM直接虚拟交换机(本来想用CX341A,发现厚度超了, 341a就暂时吃灰了)
测试环境: PVE(EPYC) + ESXi(蜗牛G4560)

注: 以下大多数配置记录都是在Debian10/11或TrueNas里配置

0x01 主力NAS 530FLR记录

0x00

记录一下查询IOMMU分组的命令

总共2个, 一个简单一个比较复杂

0x00 序

AMD EPYC 7282 + H11SSL-i SATA控制器直通失败(实际上好像ryzen也可能有这个问题)

单独记录这个”简单”的直通问题, 以及整个直通SATA爬坑的过程.

记录日常各种问题

配置

1. 主板: H11SSL-i
2. CPU: EPYC 7282
3. 直通卡: LSI 9207-8i 之前给E5准备的, 目前主板使用SFF-8643 to 4Sata, LSI暂时吃灰
4. 硬盘: 4 x 4T raid5, 1 x 4T 热备; 一块银河8T冷备

0x00 前提

APC BK650M2到货, 不知道是我主板支持问题还是配置情况, apcupsd和win下官方软件都识别不到ups, 幸好NUT能用, 以下分享一下我的配置.另, 看网上有人反馈apcupsd不适用bk650m2（链接）, 所以还是直接用nut好了.

我们的目标: 1. 断电后 TrueNAS先关机; 然后PVE关机; 2. 来电后重启(最好能有延迟)

问题: 原计划是使用upsmon -c fsd, 测试发现, primary节点也能收到FSD消息, 直接进入关机流程了, 和预想(断电X秒没有恢复供电, 通知所有虚拟机, 然后主节点再关机)不一样,也可能是我配置有问题, 目前方案是: 虚拟机设置使用电池的60秒后关机, primary设置90秒关机, 和预期效果差不多吧, 其实直接在primary配置关机执行qm shutdown <vmid> 更简单, 反正也是想试试看起来高级的东西.

此文章大部分参考官方文档Network UPS Tools

为什么用shallow clone(浅克隆)

对于大仓库，使用shallow clone可以极大减少克隆时间/占用空间/网络数据。还有的时候，克隆一个特别大的仓库是，你会发现，git clone到一半就失败了，原因是内存不足。—-比如kernel.org,我当时克隆时差点疯掉，VPS失败、虚拟机也失败，最后找到了git这么的功能。

我用过的场景:

• 克隆linux.git时内存不足
• 编译grpc时，从git克隆源码实在太慢，而且还会克隆好多子仓库，太浪费时间，最后手动浅克隆下来就很快

PermitRootLogin的可选项

/etc/ssh/sshd_config文件是用来限制root的登录的，目前(Debian10目前版本是7.9)支持的选项有yes, without-password, rohibit-password, forced-commands-only, no.

2020-04-12更新：2018 年 3 月 13 日起Let’s Encrypt支持通配符证书

为什么

• Let’s Encrypt是免费并且开源的CA,由 Mozilla,思科,Akamai,IdenTrust和EFF等组织发起的,现由Linux基金会托管。
• 自动完成验证和更新
• 为了以后方便改二级域名，使用通配符证书更灵活~

BBR是什么?

bbr是Google开发的拥塞控制算法,Linux内核4.9版本开始可以使用,可以起到单边加速TCP连接的效果,效果还是很明显的。当然也不能盲目信任,bbr也是有局限的。这里有两篇分析bbr的文章可以参考。
令人躁动一时且令人不安的TCP BBR算法
Linux Kernel 4.9中TCP BBR算法的科普解释

很久以前的一次意外发现,记录一下。