跳转至

2021

关于产品的一点思考

最近在做一些小东西,但是也没匀出来时间写点啥,趁机整理整理吧。当然不能太抽象,太抽象就容易形而上学,而且让人觉得学究派。

一个系统甭管是啥,但凡需要作为产品输出,那就要有一些属性的,现代汉语对它的释义也挺准确的——“生产出来的物品”。

作为大千产品的用户,我有一些直观的体验,自己在做的时候也努力带给别人同样的体验。

暂时先总结这么几个。

场景需求优先:先满足我的原始(original)需求,即我这个需求的动力是什么,然后再扩展。

低学习成本:一定不要让我在使用的过程中老是咨询厂家、翻看说明书,对to B而言就是你不要老让厂商帮你运维。

无入侵:产品提供的服务不要给我造成额外困扰。

行为尊重:用户做的动作里哪些是需要的,哪些是多余的,产品行为里哪些是别人要看的,哪些别人甚至都不需要知道,想的越多,客户越觉得被尊重。

不要自大:厂商不要自大,做一个领域,和做这个领域的产品,是两码事儿。见过自诩很懂某领域的人,但是做的工作极难批量复制,那不叫卖产品叫卖人天。

不要遵守原则:只要保证客户人财安全,你可以随意创新,不要管别人的这黄金法则那必胜定律,用户的认知从长远来看可能都是错的。

可配置:产品化与某些场景追求的高性能并不冲突,一切皆可为配置。

测试即产品:毫不夸张,没有靠谱的测试团队那产品必然不行,不要吝啬在测试上的资源,他们可以以较小成本帮你发现成数以万计个潜在问题,也不要把客户当测试,你会很难堪。

隐藏复杂性:产品内部的行为可以很复杂,但是对客户呈现的一定是简单直白的行为,没人关心你的内部实现。

社会责任感:无论to B还是C的生意,做的东西要有严谨生命周期、升级策略、迁移方法,要不然就是对客户不负责像Google那样丢失B/C类用户的甩手掌柜。

实时操作系统中应用K8S

背景

想做这个东西的背景也很简单,就是KVM虚拟化里配上国产还是VxWorks的实时操作系统,实时性都比物理机差好几倍,无法满足某些客户的需求,常规的一些优化手段抓破头也不行了。看过WindRiver的StarlingX觉得它们的无论延迟还是抖动的控制都相对好一些,但是VxWorks本身是个黑盒子(可能对于某些有源码的人不是。。),所以就只能跳出来看这个问题,为了满足客户的需求,批量管理运维、快速发布回收、状态实时监控,都21世纪了我为什么要用虚拟化呢?(后来事实证明大家也很少用虚拟化做这个事儿。。)

那就实时Linux系统配K8s,满足大规模、边缘、嵌入式场景,雷达、舰载、攻防。。。而且这个场景下想象空间比虚拟化大点。

准备

OS:RHEL 8.4 with rt kernel

测试

懒了,直接上测试结果以演示容器配RTLINUX是否值得投入,如果性能满足需求,那做这个市场还需要个牌照和资质,不过问题不大。

裸金属笔记

裸金属相关,简单点就是尽量不用计算虚拟化。


动手做自己的Nitro SmartNIC(FPGA/ARM-based Bare Metal Hypervisor(2021-02-25)

0. BackGround

裸金属服务很酷,甲方都想要,但是最好不要有绑定。BlueField 1/2、AWS Nitro、Aliyun X-Dragon MOC之类的智能网卡也不错,虽然ZStack已经纯软件实现了类似功能,但是这篇文章仍然会探索一个如何低成本(不到100块)的“智能网卡”方案(要不然前期的调研都白瞎了)。

做弹性裸金属并不难,但是要高性能的同时又要安全,而且在私有云、产品化的语境下,我们就需要好好思考一番了。

1. 功能定义

1.1. 带外管理

带外管理也不是个问题,如果:

  1. 服务器自带BMC。
  2. 你有能力让服务器厂商给你定制,因为你需要定制BIOS部分功能以让其在启动时认到智能网卡提供的虚拟设备。
  3. 自己做OpenBMC。

但是,由于多数用户没有让服务器厂商高度定制服务器的能力,因而我们需要在“无米”的状态下做“炊”。

1.1.1. 电源管理

通过“智能网卡”我们至少要能实现主机的开关机,这个相对来说还比较容易实现,无论何种主板,电源控制接口现在服务器上都有,若干个高/低电平就可以控制。

但是考虑到集群断电的情况,“智能网卡”要优先启动才能进一步控制它管理的物理机,所以这个设备我们一定要轻、快、稳。

如果使用服务器内PCIE供电,那么我们又要修改BIOS来保证智能网卡优先启动,但是这个。。。成本不止100块了。

所以考虑使用独立供电的嵌入式设备,无论使用插到服务器PCIE插槽上的ARM/FPGA/X86 SoC还是树莓派,我们都要给它独立供电。

1.1.2. 与主机通信

这里的通信仅仅涉及控制面的内容,数据面(网络、存储)不涉及。

我们尊重传统,仅考虑两种情况,即与主机OS通信和与主机设备通信。

前者一个agent走TCP/IP就能搞定,后者我们需要与主板的I3CI2C/SPI接口通信。

1.2. 设备模拟/透传

存储

存储侧我们目前可以直接提供的baremetal设备有 SCSI(iSCSI)、NVMe(oF)、VirtIO等。

由于产品化必须考虑到适配各种硬件的问题,所以我们不会定制修改BIOS,这里只要一个小小的trick即可让服务器从智能网卡提供的vda或者其他接口的“虚拟”硬盘启动,从而保证云平台存储资源可以以较高性能提供给baremetal。

Option Rom

Option Rom 也是智能网卡带的选项了,启动后可以直接认到virtio/nvme的虚拟硬盘。

网络

网络多数情况下是问题但又不是问题,我们选择智能网卡的原因是因为它可以解决大多数问题。虚拟网络资源直接给物理机的目的可以很容易地通过SDN交换机实现,但是我们既然用了一个智能网卡设备那么就应该通过它来回避各种外部环境仍然需要定制的问题。以BF2为例,它内部集成的ovs-dpdk以及Mellanox传统的内部虚拟交换技术加持,我们可以给baremetal一个“虚拟”接口,但是所有流量都在云平台的管控下,用户极难自行修改。

如果不选择智能网卡,那么只有SDN交换机和系统内SDN两种方案,SDN交换机甚至比智能网卡的适配都简单,技术不是难点,同智能网卡一样你很难说服客户的采购来一套裸金属专用的SDN交换机,更不要说这个交换机不在他们的网工管辖范围内了。

那么只剩系统内的overlay网络接入方案了,Linux一直不是问题,Windows系统需要agent做一些小工作才可以,即使用户自己改了,我们也可以“内挂”anti-spoofing。

1.3. Hypervisor模拟

“智能网卡”中要模拟hypervisor,这里的模拟是为了让多数云平台的agent比如libvirt或者基于libvirt的定制agent能够对弹性裸金属设备的调用行为与虚拟机保持一致。为什么要做这个工作呢,我单独的控制面不行吗?

也行,但是不酷,更何况你后续的存储与网络设备不仅给裸金属也要给虚拟机,两套API两套数据库管理同一个网络/存储就是在给云平台的管控面开发找事儿。

所以这个我们一般要对agent(libvirt)做一些修改,这个难度相比下来不大。

2.1. Proof of Concept

2.1. ARM or X86作为智能网卡

如果使用ARM或者X86主机作为“智能网卡”,那么存储方案有iSCSI和NVMe-over-TCP,网络方案目前看只有系统内SDN的方法了,好处在于“智能网卡”的门槛低。

我们先做一个OpenBMC的原型机,准备如下材料:

笔记本; 树莓派/NVIDIA Jeston; 视频采集卡; 杜邦线; 网线; rtl-sdr(谁能拒绝一个可以听广播看电视的裸金属呢);

当然,一台服务器也是必要的。。。不会吧,你家里连台服务器都没有?你还做锤子钢铁侠哦?赶紧上咸鱼500块买个二手服务器吧,不想做钢铁侠了还可以卖掉。

算了,毕竟太吵,一个ATX或者其他类型主板的台式机就可以了。

TBD

2.2. FPGA ARM SoC作为智能网卡(有点小贵,1000多块,但是来都来了)

1000多一块的有PCI-E插槽的Xilinx ARM SoC开发版,贵,但是你可以基于PCI/PCI-E接口实现独立的网络、存储,非常有意思,但是难度在于FPGA编程。

不过还好,我们先尝试用Pynq写一些简单的PCI/PCI-E通信,然后再堆上复杂的,但是中间会有很多IP我们要购买,没钱怎么整,社区找现成的,low点,能用。

因为我们的目标是要基于这个FPGA实现存储和网络设备的接入,那么总归是一个大点的工程,如果做的先进点实现virtio网络/存储的接入,那对于提供虚拟化的云平台将善莫大焉。


"Windows中使用overlay网络的一些方案" "2020-05-21"

引言

21世纪了,智能网卡还是贵,交换机客户没法直接买,软件技术栈都好找,性能再加强,ebpf不错,要是Windows的Linux子系统里支持这个那软裸金属方案至此可以画上一个句(分)号了。

关于如何在Windows裸金属中给用户交付流畅且易配置的云平台overlay网络,从而跟虚拟化打通,也是个最近要考虑的点。

SDN交换机与智能网卡

我们可以用国内品牌,他们也提供ovs接口,but,对于小体量的客户或者采购严格的客户就很难,仅适合自有IDC且有决心的客户。

为了使用一个功能,软件绑定就算了,硬件你还要我买你的,固定资产无法二次利用,别想了。

GRE/VXLAN(Windows)

Windows从08/12后自带了NVGRE,VXLAN的话是从16开始支持,听起来也不错,所以这个对于新晋用户是可以接受的

OVS

Windows下有ovs,但是仅支持2012后的,这样就没法解决Windows2008的问题(再过几年就不用操心这个问题了),当然主要的问题还是没有官方背书。


"使用Xilinx/Intel FPGA加速虚拟化" "2019-04-29"

UPDATE: 老王的笔记中也总结了一些关于devconf的内容。

This article is just a collection of ideas and posts.

Recently I was doing some performance-tunning of QEMU/KVM with kinds of pure-software ways. However, it ended with the existence of QEMU/KVM's process load.

I just remembered that I used to do some co-sim work with National Instruments LabView about ten years ago...(during college life...fk...I'm still young...)

Trial No.1

TBD: Start QEMU instance(s) with passthrough-ed PCI(PCI-SRIOV) devices like ethernet controller or NVMe controller designed in PCI FPGA to offload the emulated works.

Trial No.2

TBD: Start QEMU instance with devices ported to passthrough-ed PCI FPGA as many as possible, i.e. usb controller, ethernet controller and etc..(Like a dock with kinds of devices...)

But I think it will be replaced by Trial No.1.

Trial No.3

TBD: Co-Sim.

Trial No.4

SoC FPGA, as DOM0.

Trial No.5

ASIC offload with slight host management.

References

[1] Running Xilinx in QEMU, https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842060/QEMU

[2] Building Xen Hypervisor with Petalinux 2019.1, https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/99188792/Building+Xen+Hypervisor+with+Petalinux+2019.1

[3] QEMU SystemC and TLM CoSimulation, https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842109/QEMU+SystemC+and+TLM+CoSimulation


"Windows中使用eBPF" "2022-02-10"

背景

也挺有意思的,前年念叨着Windows内的SDN方案咋做,去年微软终于就搞了个eBPF for Windows,如此以来结合Windows新版本自带的NVGRE/VxLAN网络,安全组、EIP、LB啥的在纯软裸金属里都好说了。

另外,迫于适配智能与半智能网卡的压力,ZStack已经提供了ovs与linux bridge两个技术栈的网络(新建集群的时候可以选,虽然不是第一个但早些时候收到的需求确实不硬开发也忙。。),所以现在看起来一切都很合理。

当然,产品的东西跟新技术并不是什么强绑定关系,技术只是锦上添花实现产品的工具,稳定优先。

测试

编译eBPF for Windows

测试程序

VxLAN/NVGRE集成


title: "Xilinx FPGA中应用P4网络数据面编程" date: 2019-07-11 categories: - "cloud-infra" - "devices"


0. Background

As we all know, P4 is about to be the future of OpenFlow 2.0, and to achieve an totally software defined network with programmable control plane and data plane.

1. Basic Knowledge

Since we've got P4 working on X86 server

In SDN controller ONOS.

2. Software/Hardware Plant

2.1. Pureway: P4 bitstream

2.2. Easyway: P4 on PetaLinux

3. Further Exploration

虚拟桌面中通过RDMA进行GPU跨节点调用从而加速渲染

许久没关注过VDI了,一直坚持的观点就是协议要牛逼,否则就是渣。

VOI、IDV都不太行,GPU本机显示还是有些小问题,要么远程的,要么就没有虚拟化。

直到离开VDI行业三年多后发现还有这个炫酷的东西满足了当时我对单机虚拟化的期望,https://looking-glass.io,虚拟机与宿主机可以共享显示(iGPU),或者独占显示但是键鼠仍然与原生一致。

PS:ArchLinux社区万岁,这是原文

之前Intel的老板说用iGVT可以,但是仅限于Intel集显,没有可复制性。现在发现这玩意儿以后,关于边缘计算的场景真的又可以展开一些了,朋友,之前机场工控机虚拟化管理还要大屏的需求我们再聊一聊?

原理说复杂也不复杂,作者思路从被广泛采用的桌面截取(OBS、DX API、NVIDIA Stream)到共享内存(IVSHMEM),纯内存交换。

很有意义,远程桌面协议换成共享内存协议,然后可以进一步用RDMA,再配上virtio-gpu,就可以跨节点渲染了,虚拟化版本的virgl。