主动散热加持，应对夏天
没错，食言而肥。
但咱也是有理由的，看下Intel i210AT的spec页面，不难发现如下字样。嗯，虽说CPU飙到80℃没啥问题，但没法保证网卡芯片不会超过70吧，稳妥起见，试一下主动散热。毕竟小小一片网卡也要100大洋，总不算为醋买螃蟹吧。
12V供电，带数码管显示的控制器，可以显示温度（及3个阈值设定）以及当前风扇转速，设定可谓简便易用。
路由虚拟化，意义何在？
见此题目，心急的路由玩家，可能等不及要说，我要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℃左右，别忘记现在还只是春末夏初。
M.2转接Intel i210千兆
先说句题外话，个人不喜2.5G，一直觉得就是民用市场卷出来的临时产品。反正六类线跑电口万兆没问题，2.5G抑或10G都是贵，买个中间态产品？图便宜就留在千兆方案，不差钱直接万兆完事，2.5G这不上不下，就那么几个网卡方案不升级还断流，厂家重视与否么显而易见，对吧。
为什么要提2.5G，前两天说Tinker Board 2s带了一个key A+E的m.2，一旦做路由，这种wifi卡显见没啥用，可以考虑：
- 另一块网卡，这样路由就不再单臂，更实至名归一些（板子还是天生12v供电，你不做路由谁做路由？）。
- 扩SATA。也是好主意，但这板自带16GB emmc跑host和kvm足够，还空一个TF卡槽，需要的话插卡就很方便。再扩SATA就没啥必要了，并且SATA供电也得外接，板上并无接口，鸡肋了。
- 其他PCIe设备，意思不大。
某宝上转了一圈，其实基于i225V B3（或者RTL 8125）的m.2接口2.5G网卡，居然比i210的千兆还便宜20块，赫然写着新版绝不断流……
犹豫再三我还是入了i210版本，综合考虑了自己对2.5G的不感冒，以及RK3399的转发能力，适合自己才是最好的嘛。即使接单块2.5G网卡，再做2.5G单臂路由的话，还需要2.5G vlan switch，没事咱就别给自己挖坑了。
卡么，看板子糙了点儿，但外观毕竟不能当饭吃。
为RK3399换金属壳降温
这个没啥技术含量，就看愿不愿意为这么块小铁皮出90块。板子太冷门，周边没人做，所以商家估计本着开张吃半年的原则，这么个壳子收90，而且隔壁还有140的……我感觉140买x86的瘦客户端洋垃圾几乎能买整机了……
效果也比较明显，在室温影响差异不到1℃的前提下，同样被动散热能多拉下来6℃，只能说没有白花的钱，至于值不值就另说了。
基于CM4 Sensing双WAN冗余路由
把手头能玩的板子全玩了一遍，完全停不下来。基于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单臂路由》复习一下，接下来我们看图说话。
完整阅读本篇»简单RestAPI获取硬件状态
简单来说，我需要一个能从HA上直接浏览家里主路由的CPU温度的首屏，因为RK3399发热比较猛却只有被动散热。有人可能说，加个小风扇难度很大么？呃，具备Netgear R7000（博通方案）在夏天轻松面对75℃服役5年的经验，我觉得国货不妨一战。
所以这个小项目，其实提供了对运行在物理机上几乎任意Linux的cpu温度、磁盘余量、上电时间等参数的rest api获取。写的比较糙快猛，主要满足自己需求，所以莫要预期过高哈。
提供何种接口
随意运行一个http client，比如 curl http://[hostname]:9090/stats/[data_type]
data_type初期支持三种， du, temps, boot_time 分别代表磁盘用量，多个温度，和上电时间。然后就可以返回数据了。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
curl http://192.168.12.34:9090/stats/temps { "code": 0, "status": "success", "data": { "cpu_thermal": { "curr": 57.78, "crit": 100.0 }, "gpu_thermal": { "curr": 57.22, "crit": 95.0 } } } |
京公网安备 11011502004657号