HPC增补

HPC的生意目前来看还是集成,部分组件可以标准化,但是克雷、富士通、IBM、NVIDIA都有自己的盘子,库也都是为自家架构优化,这些都没有问题,理解。

想搞高性能向HPC技术方向学习,也没有问题,但是搞完过后想复制,那就铺人天了。一堆定制设备、一堆专有技术栈,加上已知最好的设备和软件都是国外垄断,生意做着做着就自己就成集成商了。集成商没啥不好,毕竟前十年150W刀一个P的算力,这生意走量。国产化版本堆算力早些年成本差不多两倍,但现在随着算力爆发进步整体可以进到200W RMB一个P算力了。

HPC的生意不好做,进不去圈子,但是汤可以喝,而且大厂们也想喝这个汤,不信你看GPFS都卖给了谁。后来做的纯软裸金属算是产品入局了,但是再往上走适配一个已经很很很完整的生态,想想都觉得累。

算了,回头把RDMA技术栈补一补,这样或许可以再搞些其他的花样,只是产品化的路没那么好走,但是集成的生意要啥产品化呢,还是要的,你看SAP模块化也厉害的一塌糊涂。

Windows中使用eBPF

背景

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

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

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

测试

编译eBPF for Windows

测试程序

VxLAN/NVGRE集成

关于产品如何定价的模型探讨

引言

昨天跟人聊到这个问题,但是从经验上说,定价似乎需要考虑很多,但也好像不需要考虑一样。定价格有一些已有的规律,比如产品独领风骚然后按毛利去定的、红海市场跟随友商打价格的、为了扩张亏本卖的等等。经验这种东西会很有效,但它也是阻止破圈的罪魁祸首。所以这篇文章尝试建立一个代理人模型从尽可能多的角度去探索,毕竟这是一个系统性的问题,我们不讲经验,一两条经验不足以适配所有问题,干了40年的老板也不一定解决新场景遇到的问题,要不然百年老店不是又比现在多了一些。

当然,我仍然会建立一个合适的动态模型来模拟尽可能多的情况,如果是沙盘推演也没有问题,只是可能局限性比较大,不能把一些极端的变量组合考虑进去。设计的时候尽量遵循ODD原则(overview, design, detail),以保证覆盖现实情况的同时模拟出更多意外。

这里我们抛开单个产品差异化定价策略,即可以把产品拆成很细的定价策略,比如一块盘按照不同iops和容量租出去最大化利益,只讨论一块固有iops和容量的情况,因为这种拆分算利益的话,更适合用最优解公式而不是建模分析,况且现在差异化定价你会别人也会,最后难免都是同质竞争。

设计

以我熟悉的云计算为例,首先我们尽可能多的列出agent,最明显的就是产品、客户、厂商、供应商,但是这还不够,有些过度抽象了。(我们暂且忽略渠道,主要是因为渠道与云厂商体量在实际情况中基本保持一致,所以这点确实可以忽略)

那接下来我们加入更多agent,产品嘛单纯一些只有一类,客户这一类金融行业客户、游戏行业客户、制造行业客户,厂商的话主要考虑外部竞争和内部团队(云计算部门的集团投入政策、销售体系等),即会有几个体量、质量、策略等不同的厂商agent,厂商除了考虑同类供应商,也要考虑它的上下游,比如代工厂、圆晶厂、渠道商这些(方便实现简化保留下游,仅为防止泰国又洪水产品生命周期有影响)。

梗概

至此,我们已经在这个世界里已经可以描述一个完整的故事了,某个客户(可控数量)向某个云厂商(可控数量)购买最多N个产品(有生命周期),客户会根据自己的偏好选择厂商,厂商提供的产品受限于供应商(价格极低),如果客户技术能力强或者价格敏感度高可能会直接向供应商下单(供应商参与竞争,适用于OEM产品),最后我们的输出是某个厂商在未来一段时间内的市场表现变化,包括收益和客户占有率。

属性与动作

客户

列出尽可能多的agent以后,我们开始构建每个agent的属性和行为。由于我不想写那么多一个个解释,所以列几个意思一下,以金融客户为例(属性值和动作来源于市场销售记录统计,无法确定的值没关系,模拟的时候机器可以范围内随机探索)。

产品价格敏感性:低(0.2)
产品质量要求:中(0.5)
服务质量要求:高(0.8)
客户直销忠诚度:中(0.0-1)
客户渠道销售忠诚度:中(0.0-1)
IT技术能力:中(0.5)
受他人影响程度:高(0.7)

然后是动作,这些动作暂且适用于所有客户agent。

- 客户的属性随着时间的增长保持不变
- 客户会根据自己的属性偏好选择厂商产品,各个属性加权值决定产品,比如质量要求高的会喜欢产品综合质量好一些的、渠道忠诚度高的会喜欢渠道多的、IT技术能力低的会喜欢厂商服务好的
- 客户的购买行为除了在与云厂商直接,也可以发生在与供应商之间
- 客户的某属性超过一定阈值的时候(比如忠诚度),虽然所有属性加权值不是最佳,但会导致其这次仍然选择上一家
- 客户的忠诚度会随着历年选择厂商的变化而变化

产品

列出产品的属性,这里可以先定义这么几个。

产品价格:可控变量,即客户每天使用需要付出的价格
产品状态:在厂、待售、使用、结束(这里假设每个产品从售出便不会再次回到产品池)
产品用户:产品用户 已经销售:是否已经销售到客户 产品成本:与供应链相关 产品质量:随时间、客户增加而增加,有一个逐步完善的过程 产品销售厂商:产品销售厂商
产品生产厂商:产品生产厂商 生命周期:产品从售出开始则开始消耗

厂商

然后是厂商的属性。

销售策略:盈利、求同、激进
产品最大数量:对应厂商体量
产品成本:与供应商有关

供应商

最后就是供应商的属性,为了减少复杂度,这里我们只有两类供应商,即可直接面向客户以及不可直接面向客户。

销售策略:盈利(供应商不赚就是亏)
产品供应周期:每天能够生产的产品数量
产品生产成本:可变量
可直销:是、否

再加一些全局变量进去,比如从Gartner的趋势报告里把云计算、各类产品的每年增长也算进去,主要操控的变量是某个或多个厂商的定价范围(0-100)。

周期事件

TBD 一个周期内,会发生哪些事件呢?

产品:
客户:
厂商:
供应商:

模拟

预期

在开始之前,我们根据经验应该是对这个世界有一些经验预期的,包括:

一定范围内,定价不能直接决定市场占有率;
产品做的晚的厂商即使定价再低也只能抢得一定份额的市场;
供应商供货不足时,体量大的厂商更能抗住黑天鹅事件从而保证客户产品交付,从而获得更高的客户忠诚度;
动态选择灵活的定价(销售)策略即使起步晚,也可以抢夺一部分可观的市场;
价格敏感、技术能力强、忠诚度低的客户更容易从供应商处买;
集团策略影响云厂商定价策略选择;
在没被针对的情况下,小厂商初期可以打价格战争夺部分客户后,不会赚甚至是亏,但获取一定客户后再改变价格策略是可以盈利的;
因为不同阶段采取不同的定价策略会影响市场表现,那么作为云厂商在期间的前端销售和供应商谈判策略也不尽相同,比如产品初期的时候很难从供应商要低价,平价甚至亏本抢占市场后可以再向供应商谈判出更低成本价;

行为空间模拟

最后我们来看看模拟的动态情况。

tbd model simulation

tbd 由结果我们先看到几种现象。。。

tbd 然后我们把自己的实际情况带入进去。。。

tbd

tbd 看的多了,再结合dikw模型,结论就是直觉可能就是对的。但是要给人展示数字,我们可以从各种渠道快速填充数字,从数字到推论,只是让人觉得你可信,至于你自己信或不信,就是另外一码事儿了。。。最后我们要把数字与经验结合起来,就是出几个概率数字,即未来几年内我们应该采取怎样的定价策略(保持毛利、争夺市场、自动动态调整)然后有百分之多少的概率占去多少这个产品的市场获得多少利益,根据概率做选择,虽然无法确信,但也不会犯错,平平淡淡才是真。

关于产品化的产品的一点思考

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

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

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

暂时先总结这么几个。

场景需求优先:先满足我的原始(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)

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。

网络

网络多数情况下是问题但又不是问题,我们选择智能网卡的原因是因为它可以解决大多数问题。虚拟网络资源直接给物理机的目的可以很容易地通过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网络/存储的接入,那对于提供虚拟化的云平台将善莫大焉。

TBD

虚拟桌面中通过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。

 

NVMe in the Cloud(ZStack),(适合)云原生的存储

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

Direct to Guest

NVMeOverTCP的特点就是,用户以极低的改造成本即可获得高性能、低延迟的高性能存储,以现在的单盘IOPS

PassThrough

DirectConnect

Via Host

Cluster Filesystem

Share Block

Windows中使用overlay网络的一些方案

引言

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

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

SDN交换机与智能网卡

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

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

GRE/VXLAN(Windows)

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

OVS

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