首页 » 标签："服务器"

RK3566之armvirt转发能力

2024-03-02 作者： Fisherworks

一言以蔽之，同用双核，略逊Pi 4B，明显不如RK3399。虽然制程和频率双双强过BCM2711（Pi 4B），但A55相比A72应该还是有明显差距的…吧，当然发行版对比也略有差异（尽管都基于debian），无法精确对比哈。

至于想劝俺上什么iStoreOS就算了，原因在之前提过，尽管估计物理跑NAT（开启软件流量分载）大概率能接近跑满千兆转发，但选型喜好是很个人的事情，总觉得所谓all-in-one在架构上反过来（upside down）不好玩。

数据上，iperf3上行700左右，下行850，看起来即使另外两核跑个容器带点儿负载，保障个500Mbps宽带应该没啥鸭梨。

innobackupex吃光root分区

2024-02-29 作者： Fisherworks

Take a look at this if your innobackupex insists on eating up most (or all) of your root partition, as playing hide and seek with you especially.

近两天总收到奇怪的推送，磁盘占用超90%，没采取人为任何措施，又自动降至正常……就很离谱。去翻了一下云监控的磁盘使用率，发现居然是系统盘，而非数据盘（后者占用率不高，多日无明显变化），就更奇怪了。

前者么，不逮住问题发生时的话，根本无从查起；考虑其发生规律，基本跟mysql冷备的时间周期比较吻合。

所以先去看mysql冷备文件的状态，就开始出问题了（截图欠奉）。

每个备份文件的结束时间都很早，从以往常见的上午9~10点提前到了凌晨4~5点。
且文件的大小也不太对劲，降了一半不止（在未删除数据的前提下）。

好办，备份文件会定期rotate但log不会，不删就会一直存，看log就好。

一看不要紧，近两天备份都是失败告终。

..........
240209 05:05:01 >> log scanned up to (58627078203151)
240209 05:05:03 >> log scanned up to (58627086878169)
innobackupex: Error writing file '/tmp/xbtempPr6mT8' (Errcode: 28 - No space left on device)
xtrabackup: Error: write to logfile failed
xtrabackup: Error: xtrabackup_copy_logfile() failed.

..........

240209 05:05:01 >> log scanned up to (58627078203151)

240209 05:05:03 >> log scanned up to (58627086878169)

innobackupex: Error writing file '/tmp/xbtempPr6mT8' (Errcode: 28 - No space left on device)

xtrabackup: Error: write to logfile failed

xtrabackup: Error: xtrabackup_copy_logfile() failed.

这里的 /tmp 就很迷，我印象中所有临时文件都不应该去系统默认的temp目录，索性检查一下。

完整阅读本篇»

从lxd迁移到incus

2024-02-27 作者： Fisherworks

Let’s talk about migration from lxd to incus. As for the reason, well I guess we have seen too much of this kinda “show” in the past half decade (just like CentOS to Rocky) so here is what happened in case you’re interested.

Technically I won’t take this as a tutorial since with the well-prepared tool lxd-to-incus by Stéphane Graber (Author of both lxd and incus) there’s nothing to do but simply running it, then everything seems working well.

PS: Tested PASS on both Debian Bookworm AMD64 (on Linux KVM based vm) and Armbian Bookworm ARM64 (on RK3566 based SBC).

这些年，同类剧本真是没少看。一言不合就闭源，一言不合就拉分支，完全不新鲜，具体就不多说了，开工干活。其实吧，作者给了迁移工具 lxd-to-incus ，所以实话说没啥可干的，执行一下就可以验证迁移后的结果了。

先检查系统现状。Check the system status at first.

# root @ bookworm-vm-host in ~ [17:55:15]
$ uname -a
Linux bookworm-vm-host 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

# root @ bookworm-vm-host in ~ [17:55:20]
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# root @ bookworm-vm-host in ~ [17:55:28]
$ lxc --version
5.0.2

# root @ bookworm-vm-host in ~ [17:55:35]
$ lxc list -c nsum4N
+-------------+---------+-----------+--------------+------------------------+-----------+
|    NAME     |  STATE  | CPU USAGE | MEMORY USAGE |          IPV4          | PROCESSES |
+-------------+---------+-----------+--------------+------------------------+-----------+
| d10-test    | RUNNING | 5s        | 94.54MiB     | 192.168.143.138 (eth0) | 6         |
+-------------+---------+-----------+--------------+------------------------+-----------+
| d12-ngx     | RUNNING | 6s        | 107.81MiB    | 192.168.143.2 (eth0)   | 19        |
+-------------+---------+-----------+--------------+------------------------+-----------+
| r8-app1     | RUNNING | 8s        | 213.93MiB    | 192.168.143.129 (eth0) | 235       |
+-------------+---------+-----------+--------------+------------------------+-----------+
| u18-redmine | RUNNING | 19s       | 402.67MiB    | 192.168.143.158 (eth0) | 16        |
+-------------+---------+-----------+--------------+------------------------+-----------+

# root @ bookworm-vm-host in ~ [17:55:39]
$

# root @ bookworm-vm-host in ~ [17:55:15]

$ uname -a

Linux bookworm-vm-host 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

# root @ bookworm-vm-host in ~ [17:55:20]

$ cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

NAME="Debian GNU/Linux"

VERSION_ID="12"

VERSION="12 (bookworm)"

VERSION_CODENAME=bookworm

ID=debian

HOME_URL="https://www.debian.org/"

SUPPORT_URL="https://www.debian.org/support"

BUG_REPORT_URL="https://bugs.debian.org/"

# root @ bookworm-vm-host in ~ [17:55:28]

$ lxc --version

5.0.2

# root @ bookworm-vm-host in ~ [17:55:35]

$ lxc list -c nsum4N

+-------------+---------+-----------+--------------+------------------------+-----------+

+-------------+---------+-----------+--------------+------------------------+-----------+

| d10-test | RUNNING | 5s | 94.54MiB | 192.168.143.138 (eth0) | 6 |

+-------------+---------+-----------+--------------+------------------------+-----------+

| d12-ngx | RUNNING | 6s | 107.81MiB | 192.168.143.2 (eth0) | 19 |

+-------------+---------+-----------+--------------+------------------------+-----------+

| r8-app1 | RUNNING | 8s | 213.93MiB | 192.168.143.129 (eth0) | 235 |

+-------------+---------+-----------+--------------+------------------------+-----------+

| u18-redmine | RUNNING | 19s | 402.67MiB | 192.168.143.158 (eth0) | 16 |

+-------------+---------+-----------+--------------+------------------------+-----------+

# root @ bookworm-vm-host in ~ [17:55:39]

然后根据文档，安装incus。Now install the incus (by Zabbly) according to the documentation.

从安装过程看，至少创建了一个用户，两个组，以及不少于6个systemd服务。

完整阅读本篇»

路由虚拟化，意义何在？

2023-06-04 作者： Fisherworks

见此题目，心急的路由玩家，可能等不及要说，我要all in one啊。

“主路由还要承担NAS、HA、运行docker，甚至一些通用win/linux虚拟机的脚本工作，我已经按大佬教程在ikuai/openwrt上搞了kvm，挺香，你不搞么？”

非也，我是反向操作，先虚拟化，再跑路由，理由也很简单 –

“首先，专业方案解决专业问题，所以尽管底层都是kvm，我不喜欢用一个路由系统做virtualization host，NAS系统也同理。其次，我要极致灵活性和对特殊需求的支持能力。”

对第二点，我举个简单的例子，我希望ikuai实现以下需求 –

对硬件#1物理口做成单臂路由，vlan id 3为WAN去拨号，vlan id 12为LAN，且开DHCP。
然后把#2物理口加入ikuai WAN2（第二条宽带，或者4G wwan转成有线接入做冗余连接备用）。
再把#3物理口加入LAN，而#3物理口vlan id 22放给二级路由的LLAN。
二级路由的WAN不走物理口，直接走host内部虚拟交换机接在ikuai LAN的下边。

如果路由裸装ikuai系统，我不知道是否方便实现，花点心思或许可以吧。但如果物理机是Proxmox VE，我实际遇到的使用场景应该比如上说的还复杂些，完全不是问题，ikuai完全不需要设置任何vlan，如上需求可以都在pve host的linux vlan和bridge的层面做好，进路由看到的完全是多块virtio独立网卡。

“那么今天你要讲，怎么在pve+ikuai上实现这个需求？这种需求一般人用不上，我为何要了解？”

非也，今天想讲下我在家中遇到一个更有意义的需求，给智能电视（尤其某些第三方APP）限速，且主要针对上传速度。

首先，为何要限速？观察下图，黑线两侧，是限速前后状态对比。

我们可以很明确的发现，限速前上传速度是4MBytes/s左右，可以说基本把家宽的上行带宽吃完了，此外我们的RK3399被迅速推高了15℃，温度达到70℃左右，别忘记现在还只是春末夏初。

完整阅读本篇»

基于CM4 Sensing双WAN冗余路由

2023-05-12 作者： Fisherworks

把手头能玩的板子全玩了一遍，完全停不下来。基于virt-manager和virsh cli的libvirt方案虽然没有PVE的纯web使用便利，但毕竟ARMv8有完全可用的libvirt支持已经很方便了，还要啥自行车哦。

既然Pi 4B据测已经能够很好的承担虚拟化路由职责，那么基于CM4并集成了4G LTE连接能力的CM4 Sensing就完全有能力实现双路外网的负载均衡+故障切换，对吧？

那即使技术实现上的选择已经很清晰，我们还是列一下目前已知的可能途径：

基于一般Linux发行版使用iptables + connmark + policy-based routing直接手打路由。我曾用一台Debian 11 vm做过实验并且跑通了最基本的双wan负载均衡，想来感兴趣这种原始手工方式的玩家想必不是很多，所以也没有过多记录。且继续往下，在Linux上做这些策略的持久化、多ISP定时监控、故障切换，都有大量的脚本工作；而这方面已有大量成熟方案，我的目的仅仅是通过实验理解原理，目的达到，见好就收。感兴趣的可以通过关键词检索相应文章学习，另外B站的“金枪鱼之夜”的课堂录像（上下两集），可以帮你很好的由浅入深搞懂iptables。
直接按Pi 4B编译/下载OpenWrt固件。如我们之前的mwan3负载均衡测试，功能实现上不应存在潜在问题，但这里显然要开始考虑4G/5G模块的驱动编译，wan口支持wwan的相应库的选择，最终编译结果固件的长期可靠性测试，硬件如果升级（比如4G模块，比如CM4载板）必然重新编译……一圈玩下来可以说是实现产品的精力了。
第三个选择就要轻松的多。完全无需重新编译，把我们已经玩6的armvirt镜像直接扔Sensing里，给vm多加一个虚拟网卡eth2，打完收工。

没理解是吧，没关系，先把上一篇《基于Raspberry Pi 4B单臂路由》复习一下，接下来我们看图说话。

完整阅读本篇»