HPC的生意目前来看还是集成，部分组件可以标准化，但是克雷、富士通、IBM、NVIDIA都有自己的盘子，库也都是为自家架构优化，这些都没有问题，理解。
想搞高性能向HPC技术方向学习，也没有问题，但是搞完过后想复制，那就铺人天了。一堆定制设备、一堆专有技术栈，加上已知最好的设备和软件都是国外垄断，生意做着做着就自己就成集成商了。集成商没啥不好，毕竟150W刀一个P的算力，这生意走量。国产化版本堆算力早些年成本差不多两倍，但现在差距在逐步缩小。
HPC的生意不好做，进不去圈子，但是汤可以喝，而且大厂们也想喝这个汤，不信你看GPFS都卖给了谁。后来做的纯软裸金属算是产品入局了，但是再往上走适配一个已经很很很完整的生态，想想都觉得累。
算了，回头把RDMA技术栈补一补，这样或许可以再搞些其他的花样，只是产品化的路没那么好走，但是集成的生意要啥产品化呢，还是要的，你看SAP模块化也厉害的一塌糊涂。
也挺有意思的，前年念叨着Windows内的SDN方案咋做，去年微软终于就搞了个eBPF for Windows，如此以来结合Windows新版本自带的NVGRE/VxLAN网络，安全组、EIP、LB啥的在纯软裸金属里都好说了。
另外，迫于适配智能与半智能网卡的压力，ZStack已经提供了ovs与linux bridge两个技术栈的网络（新建集群的时候可以选，虽然不是第一个但早些时候收到的需求确实不硬开发也忙。。），所以现在看起来一切都很合理。
当然，产品的东西跟新技术并不是什么强绑定关系，技术只是锦上添花实现产品的工具，稳定优先。
最近在做一些小东西，但是也没匀出来时间写点啥，趁机整理整理吧。当然不能太抽象，太抽象就容易形而上学，而且让人觉得学究派。
一个系统甭管是啥，但凡需要作为产品输出，那就要有一些属性的，现代汉语对它的释义也挺准确的——“生产出来的物品”。
作为大千产品的用户，我有一些直观的体验，自己在做的时候也努力带给别人同样的体验。
暂时先总结这么几个。
场景需求优先：先满足我的原始（original）需求，即我这个需求的动力是什么，然后再扩展。
低学习成本：一定不要让我在使用的过程中老是咨询厂家、翻看说明书，对to B而言就是你不要老让厂商帮你运维。
无入侵：产品提供的服务不要给我造成额外困扰。
行为尊重：用户做的动作里哪些是需要的，哪些是多余的，产品行为里哪些是别人要看的，哪些别人甚至都不需要知道，想的越多，客户越觉得被尊重。
不要自大：厂商不要自大，做一个领域，和做这个领域的产品，是两码事儿。见过自诩很懂某领域的人，但是做的工作极难批量复制，那不叫卖产品叫卖人天。
不要遵守原则：只要保证客户人财安全，你可以随意创新，不要管别人的这黄金法则那必胜定律，用户的认知从长远来看可能都是错的。
可配置：产品化与某些场景追求的高性能并不冲突，一切皆可为配置。
测试即产品：毫不夸张，没有靠谱的测试团队那产品必然不行，不要吝啬在测试上的资源，他们可以以较小成本帮你发现成数以万计个潜在问题，也不要把客户当测试，你会很难堪。
隐藏复杂性：产品内部的行为可以很复杂，但是对客户呈现的一定是简单直白的行为，没人关心你的内部实现。
社会责任感：无论to B还是C的生意，做的东西要有严谨生命周期、升级策略、迁移方法，要不然就是对客户不负责像Google那样丢失B/C类用户的甩手掌柜。
想做这个东西的背景也很简单，就是KVM虚拟化里配上国产还是VxWorks的实时操作系统，实时性都比物理机差好几倍，无法满足某些客户的需求，常规的一些优化手段抓破头也不行了。看过WindRiver的StarlingX觉得它们的无论延迟还是抖动的控制都相对好一些，但是VxWorks本身是个黑盒子（可能对于某些有源码的人不是。。），所以就只能跳出来看这个问题，为了满足客户的需求，批量管理运维、快速发布回收、状态实时监控，都21世纪了我为什么要用虚拟化呢？（后来事实证明大家也很少用虚拟化做这个事儿。。）
那就实时Linux系统配K8s，满足大规模、边缘、嵌入式场景，雷达、舰载、攻防。。。而且这个场景下想象空间比虚拟化大点。
OS：RHEL 8.4 with rt kernel
懒了，直接上测试结果以演示容器配RTLINUX是否值得投入，如果性能满足需求，那做这个市场还需要个牌照和资质，不过问题不大。
裸金属服务很酷，甲方都想要，但是最好不要有绑定。BlueField 1/2、AWS Nitro、Aliyun X-Dragon MOC之类的智能网卡也不错，虽然ZStack已经纯软件实现了类似功能，但是这篇文章仍然会探索一个如何低成本（不到100块）的“智能网卡”方案（要不然前期的调研都白瞎了）。
做弹性裸金属并不难，但是要高性能的同时又要安全，而且在私有云、产品化的语境下，我们就需要好好思考一番了。
带外管理也不是个问题，如果:
但是，由于多数用户没有让服务器厂商高度定制服务器的能力，因而我们需要在“无米”的状态下做“炊”。
通过“智能网卡”我们至少要能实现主机的开关机，这个相对来说还比较容易实现，无论何种主板，电源控制接口现在服务器上都有，若干个高/低电平就可以控制。
但是考虑到集群断电的情况，“智能网卡”要优先启动才能进一步控制它管理的物理机，所以这个设备我们一定要轻、快、稳。
如果使用服务器内PCIE供电，那么我们又要修改BIOS来保证智能网卡优先启动，但是这个。。。成本不止100块了。
所以考虑使用独立供电的嵌入式设备，无论使用插到服务器PCIE插槽上的ARM/FPGA/X86 SoC还是树莓派，我们都要给它独立供电。
这里的通信仅仅涉及控制面的内容，数据面（网络、存储）不涉及。
我们尊重传统，仅考虑两种情况，即与主机OS通信和与主机设备通信。
前者一个agent走TCP/IP就能搞定，后者我们需要与主板的I3CI2C/SPI接口通信。
存储侧我们目前可以直接提供的baremetal设备有 SCSI（iSCSI）、NVMe（oF）、VirtIO等。
由于产品化必须考虑到适配各种硬件的问题，所以我们不会定制修改BIOS，这里只要一个小小的trick即可让服务器从智能网卡提供的vda或者其他接口的“虚拟”硬盘启动，从而保证云平台存储资源可以以较高性能提供给baremetal。
网络多数情况下是问题但又不是问题，我们选择智能网卡的原因是因为它可以解决大多数问题。虚拟网络资源直接给物理机的目的可以很容易地通过SDN交换机实现，但是我们既然用了一个智能网卡设备那么就应该通过它来回避各种外部环境仍然需要定制的问题。以BF2为例，它内部集成的ovs-dpdk以及Mellanox传统的内部虚拟交换技术加持，我们可以给baremetal一个“虚拟”接口，但是所有流量都在云平台的管控下，用户极难自行修改。
如果不选择智能网卡，那么只有SDN交换机和系统内SDN两种方案，SDN交换机甚至比智能网卡的适配都简单，技术不是难点，同智能网卡一样你很难说服客户的采购来一套裸金属专用的SDN交换机，更不要说这个交换机不在他们的网工管辖范围内了。
那么只剩系统内的overlay网络接入方案了，Linux一直不是问题，Windows系统需要agent做一些小工作才可以，即使用户自己改了，我们也可以“内挂”anti-spoofing。
“智能网卡”中要模拟hypervisor，这里的模拟是为了让多数云平台的agent比如libvirt或者基于libvirt的定制agent能够对弹性裸金属设备的调用行为与虚拟机保持一致。为什么要做这个工作呢，我单独的控制面不行吗？
也行，但是不酷，更何况你后续的存储与网络设备不仅给裸金属也要给虚拟机，两套API两套数据库管理同一个网络/存储就是在给云平台的管控面开发找事儿。
所以这个我们一般要对agent（libvirt）做一些修改，这个难度相比下来不大。
如果使用ARM或者X86主机作为“智能网卡”，那么存储方案有iSCSI和NVMe-over-TCP，网络方案目前看只有系统内SDN的方法了，好处在于“智能网卡”的门槛低。
我们先做一个OpenBMC的原型机，准备如下材料:
笔记本; 树莓派/NVIDIA Jeston; 视频采集卡; 杜邦线; 网线； rtl-sdr（谁能拒绝一个可以听广播看电视的裸金属呢）；
当然，一台服务器也是必要的。。。不会吧，你家里连台服务器都没有？你还做锤子钢铁侠哦？赶紧上咸鱼500块买个二手服务器吧，不想做钢铁侠了还可以卖掉。
算了，毕竟太吵，一个ATX或者其他类型主板的台式机就可以了。
TBD
1000多一块的有PCI-E插槽的Xilinx ARM SoC开发版，贵，但是你可以基于PCI/PCI-E接口实现独立的网络、存储，非常有意思，但是难度在于FPGA编程。
不过还好，我们先尝试用Pynq写一些简单的PCI/PCI-E通信，然后再堆上复杂的，但是中间会有很多IP我们要购买，没钱怎么整，社区找现成的，low点，能用。
因为我们的目标是要基于这个FPGA实现存储和网络设备的接入，那么总归是一个大点的工程，如果做的先进点实现virtio网络/存储的接入，那对于提供虚拟化的云平台将善莫大焉。
TBD
许久没关注过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。
NVMe作为新的存储协议，更能将新的存储介质的性能发挥出来，与此同时，与SCSI存储对等的NVMeOverRDMA和NVMeOverTCP也已经开始在数据中心中崭露头角（忽略FC，发展太慢了）。
传统云平台中的对这些存储设备的使用是没有任何问题的，但是在不改变存储对接架构的情况下发挥出其原生性能则是一个挑战。
关于瓶颈的问题，我们可以从不同的存储对接路径去分析。
当然，不同于公有云的机器完全自定义，硬件自己随便攒，私有云为了要达成产品化需要考虑的因素比公有云更为繁杂（当然在私有云大规模这个方向上就弱很多了）。
NVMeOverTCP的好处除了其性能之外，还有就是万兆以上线速，有多少来多少。
硬件测试设备：LightBits
软件测试方法：https://blogs.oracle.com/linux/nvme-over-tcp
测试客户端：100Gb x 2、25Gb x 4
测试云平台：ZStack 3.8，io_uring，spdk
NVMeOverTCP的特点就是，用户以极低的改造成本即可获得高性能、低延迟的高性能存储，以现在的单盘IOPS
21世纪了，智能网卡还是贵，交换机客户没法直接买，软件技术栈都好找，性能再加强，ebpf不错，要是Windows的Linux子系统里支持这个那软裸金属方案至此可以画上一个句（分）号了。
关于如何在Windows裸金属中给用户交付流畅且易配置的云平台overlay网络，从而跟虚拟化打通，也是个最近要考虑的点。
我们可以用国内品牌，他们也提供ovs接口，but，对于小体量的客户或者采购严格的客户就很难，仅适合自有IDC且有决心的客户。
为了使用一个功能，软件绑定就算了，硬件你还要我买你的，固定资产无法二次利用，别想了。
Windows从08/12后自带了NVGRE，VXLAN的话是从16开始支持，听起来也不错，所以这个对于新晋用户是可以接受的。
Windows下有ovs，但是仅支持2012后的，这样就没法解决Windows2008的问题（再过几年就不用操心这个问题了），当然主要的问题还是没有官方背书。
https://github.com/Xilinx/PYNQ-Networking
随着国产化进程的推进，相当的应用已经可在国产化服务器（ARM/X86）上运行，本文将使用容器以及虚拟化两种技术对ARM/X86服务器上运行高性能的Android桌面进行探索。
调研了一圈实现，业界性价比最高的还是用板卡。。但是初始研究成本高一些，决心做的话可以先买一些现成的深圳货，但是对于入门的厂商来说还是用arm服务器跑容器合适，毕竟是安卓。
Docker-Android
Anbox(LXC)
Xdroid
由于qemu的ARM模拟的VGA设备由于其天生架构问题，不能正常使用，因而暂时需要使用virtio-vga设备方可显示（https://www.linux-kvm.org/images/0/09/Qemu-gfx-2016.pdf）。