跳转至

cloud-infra

关于产品的一点思考

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

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

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

暂时先总结这么几个。

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

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

NVMe作为新的存储协议,更能将新的存储介质的性能发挥出来,与此同时,与SCSI存储对等的NVMeOverRDMA和NVMeOverTCP也已经开始在数据中心中崭露头角(忽略FC,发展太慢了)。 传统云平台中的对这些存储设备的使用是没有任何问题的,但是在不改变存储对接架构的情况下发挥出其原生性能则是一个挑战。 关于瓶颈的问题,我们可以从不同的存储对接路径去分析。

当然,不同于公有云的机器完全自定义,硬件自己随便攒,私有云为了要达成产品化需要考虑的因素比公有云更为繁杂(当然在私有云大规模这个方向上就弱很多了)。

NVMeOverTCP的好处除了其性能之外,还有就是万兆以上线速,有多少来多少。

作为对比,我们使用Linux新版本自带的NVMe over TCP/RoCEv2 target。

硬件测试设备与软件:LightBits, Linux NVMe over TCP target, Linux NVMe over ROCEv2 target

软件测试方法:https://blogs.oracle.com/linux/nvme-over-tcp

测试客户端:100Gb x 2、25Gb x 4

测试云平台:ZStack 3.8,io_uring,spdk

对接方法:

Direct to Guest

PassThrough

DirectConnect

Via Host

Cluster Filesystem

Shared Block

ARM/X86服务器的安卓市场(虚拟化、容器)

0. 背景

随着国产化进程的推进,相当的应用已经可在国产化服务器(ARM/X86)上运行,本文将使用容器以及虚拟化两种技术对ARM/X86服务器上运行高性能的Android桌面进行探索。

调研了一圈实现,业界性价比最高的还是用板卡。。但是初始研究成本高一些,决心做的话可以先买一些现成的深圳货,但是对于入门的厂商来说还是用arm服务器跑容器合适,毕竟是安卓。

1. ARM/X86服务器

1.1. 虚拟化

使用X86服务器去虚拟化Android的厂商确实不多,社区有提供X86版本Android模,使用X86去模拟ARM版本的Android几乎没人做(效率极差)。

但是随着国内这几年ARM服务器市场上来,不少厂商早就开始探索ARM服务器去虚拟ARM版Android了,虽然效率较X86有很大提升,但是相比容器技术代价仍然很高,模拟出的手机定价低导致大家都是探索性的尝试。

1.2. 容器

这已经是一个较为成熟的技术了,但是缺点在于虚拟出的设备不完善。

Docker-Android

Anbox(LXC)

Xdroid

2. GPU

NVIDIA

Mali

3. 桌面协议

凡上上规模的Android模拟都需要成熟的桌面协议,而这又与他采用GPU设备相关。

由于qemu的ARM模拟的VGA设备由于其天生架构问题,不能正常使用,因而暂时需要使用virtio-vga设备方可显示(https://www.linux-kvm.org//blog/images/0/09/Qemu-gfx-2016.pdf)。

3.1. 带内协议

VNC

SPICE

RDP/ICA

PCoIP

3.2. 带外协议

VNC

SPICE

PCoIP--- title: "Building the infrastructure for cloud security" date: 2015-02-08 categories: - "cloud-infra"


Host TPM Attesation Mt. Wilson Geo-tag HyTrust McAfee ePO

VM management SSO SDN VLAN Firewall

VM Appliance Mystery Hill

title: "Home-based hybridcloud(家庭作坊式混合云)" date: 2017-10-24 categories: - "cloud-infra" - "linux-admin"


名字起的不好听,不过无所谓,也是混合云了,做到了什么地步呢? 在数据层面,家中机器和linode以及gcp公有云全通,任意地点的客户端可以通过局域网地址访问家中和公有云,而这一且,只需要一个公网IP。那么如何组建呢?

  1. 选择一个趁手的VPN,这里我使用的是SoftEther,全平台全功能,图形界面客户端全都有,自带域名反向解析,自带公网,又那么稳定,为啥不用。 只要在家中的一台PC上装好服务端,把5555端口通过路由器(有公网IP)映射出去即可完成VPN服务器的搭建。

  2. Linode服务器集群选择一台作为网关(边界路由器),负责作为客户端接入VPN服务器,那么它就有了192.168.0段的地址,其它机器上因为linode没有VPC的概念,所以得加条到192.168.0.0/24的路由。

  3. 总结下来,接入到home的VPN服务器会给所有客户端一个home的IP地址,然后加的路由表(使linode集群的10段暴露出去)都围绕这个地址展开达到互通的目的。

  4. 目前我把linode上分散在全球8个机房的私有服务器都加了进来,当然,安全线路。尝试了一次kcptun加速VPN连接,但是linux下失败了,windows成功。

这是图,PC-Server为VPN服务器,LINODE为公有云,也加入了Google的公有云进去(没画),Windows-PC为个人服务器。

联通之后,Google的CDN、DNS可以混合到Linode去使用了,再展开点,大数据、数据库都可以结合Linode去跑了。

软件定义无线电(SDR)的设备、软件与应用指南

注意:本文内容仅限于实验室安全测试目的,禁止用于任何商业或违反当地法律法规的活动。

不管是较贵的Ettus还是入门的HackRF,抑或是最初级的RTL-SDR设备,都可以使用这篇教程中的绝大部分内容。

GRCon2019

https://www.gnuradio.org/grcon/grcon17/presentations/

https://www.gnuradio.org/grcon/grcon18/presentations/

https://www.gnuradio.org/grcon/grcon19/presentations/

https://github.com/mossmann/hackrf/wiki

https://www.hackrf.net/hackrf%E4%B8%8Egnuradio%E5%85%A5%E9%97%A8%E6%8C%87%E5%8D%97/

http://www.hackrf.net/faq/

https://wiki.myriadrf.org/LimeSDR

https://myriadrf.org/news/limesdr-made-simple-part-1/

雪碧0xroot的PPT

0. 环境准备

0.1 硬件

HackRF One Ettus B200 Ettus B210 BladeRF x40 LimeSDR LimeSDR mini
Frequency Range 1MHz-6GHz 70MHz-6GHz 70MHz-6GHz 300MHz-3.8GHz 100kHz-3.8GHz 100kHz-3.5GHz
RF Bandwidth 20MHz 61.44MHz 61.44MHz 40MHz 61.44MHz 30.72MHz
Sample Depth 8 bits 12 bits 12 bits 12 bits 12 bits 12 bits
Sample Rate 20MSPS 61.44MSPS 61.44MSPS 40MSPS 3.2MSPS 61.44MSPS
Transmitter Channels 1 1 2 1 2 1
Receivers 1 1 2 1 2 1
Duplex Half Full Full Full Full Full
Interface USB 2.0 USB 3.0 USB 3.0 USB 3.0 USB 3.0 USB 3.0
Programmable Logic Gates 64 macrocell CPLD 75k 100k 40k (115k avail) 40k 40k
Chipset MAX5864, MAX2837, RFFC5072 AD9364 AD9361 LMS6002M LMS7002M LMS7002M
Open Source Full Schematic, Firmware Schematic, Firmware Schematic, Firmware Full Full
Oscillator Precision +/-20ppm +/-2ppm +/-2ppm +/-1ppm  +/-1ppm initial
+/-4ppm stable  +/-1ppm initial

+/-4ppm stable | | Transmit Power | -10dBm+ (15dBm @ 2.4GHz) | 10dBm+ | 10dBm+ | 6dBm |  0 to 10dBm | 0 to 10dBm | | Price | 249€ euros VAT Exc. | 991€ euros VAT Exc. | 1658€ euros VAT Exc. | 625€ euros VAT Exc. | 332€ euros VAT Exc. | 190€ euros VAT Exc. |

0.2 驱动

0.3 软件

https://unicorn.360.com/blog/2017/04/12/LimeSDR-Getting-Started-Quickly/

https://oneguyoneblog.com/2016/09/15/sdrsharp-sdr-installing-windows-10/

下载SDR#后,重启按F7进入“禁用驱动签名”的运行模式,运行其中的install-rtlsdr.bat,替换第0个驱动

1. 接收信号

接收信号建议使用gqrx(MacOS、Linux),也可以用sdrsharp(Windows)。

https://www.rtl-sdr.com/big-list-rtl-sdr-supported-software/

$ port info gqrx

$ sudo port install gqrx

接收信号以后,你可以做的内容就比较多了,这里我会举一些比较有意思的例子。

1.1. 听广播/看电视

http://dalvikplanet.blogspot.com/2017/03/how-to-get-working-rtl2832u-r820t2-on.html

1.2. 接收气象云图

SDR软件

虚拟声卡

WXtoimg

gpredict/orbitron

https://www.rtl-sdr.com/rtl-sdr-tutorial-receiving-noaa-weather-satellite-/blog/images/

https://wischu.com/archives/528.html

GSM嗅探

https://www.cnblogs.com/k1two2/p/7000942.html

1.3. 接收GPS信息

https://swling.com/blog/2016/04/guest-post-using-the-hackrf-one-for-dgps-beacon-reception/

http://sdrgps.blogspot.com/2016/12/rtl-sdr-to-orbit-with-limesdr.html

1.4. 方向探测与被动雷达 Direction Finding and Passive Rador

https://www.rtl-sdr.com/ksdr/

1.5. 接收whatever you want LEGALLY

zigbee https://github.com/bastibl/gr-ieee802-15-4

https://github.com/BastilleResearch/scapy-radio/tree/master/gnuradio/gr-zigbee

2. 发送信号

2.1. 发送GPS信号

https://gist.github.com/gyaresu/343ae51ecbb70486e270

https://www.cnblogs.com/k1two2/p/5477291.html#4245780

https://gorgias.me/2017/07/30/HackRF-GPS-%E6%AC%BA%E9%AA%97/

https://github.com/osqzss/LimeGPS

2.2. 发送文字/音视频

Windows软件sdrangel

http://gareth.codes/hackrf-transmit/

https://github.com/fsphil/hacktv

http://www.irrational.net/2014/03/02/digital-atv/

http://www.hackrf.net/2014/06/hackrf_nbfm_tx_n_ctcss_squelch/

http://www.xn--hrdin-gra.se/blog/wp-content/uploads/2015/08/nbfm-tx.grc

https://gist.github.com/gyaresu/343ae51ecbb70486e270

https://nuclearrambo.com/wordpress/transferring-a-text-file-over-the-air-with-limesdr-mini/

https://github.com/martinmarinov/TempestSDR

3. 收发信号

GSM

https://www.evilsocket.net/2016/03/31/how-to-build-your-own-rogue-gsm-bts-for-fun-and-profit/

https://yatebts.com/open_source/

https://cn0xroot.com/2017/01/10/iot-mode-fuzzing-with-openbt/

LTE

https://yq.aliyun.com/articles/310348

https://www.cnblogs.com/k1two2/p/5666667.html

https://cn0xroot.com/2017/04/12/limesdr-getting-started-quickly/

OpenBTS+LimeSDR

Prepare:

Ubuntu Desktop 16.04 & LimeSDR 1.4s with LimeSuite 17.12(If not, OpenUSRP will fail.)

Install build-essential packages

packages for soapysdr available at myriadrf PPA

sudo add-apt-repository -y ppa:myriadrf/drivers sudo apt-get update

install core library and build dependencies

sudo apt-get install -y git g++ cmake libsqlite3-dev

install hardware support dependencies

sudo apt-get install -y libsoapysdr-dev libi2c-dev libusb-1.0-0-dev

install graphics dependencies

sudo apt-get install -y libwxgtk3.0-dev freeglut3-dev

Install for building uhd

sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-mako doxygen python-docutils cmake build-essential

Change to UHD driver via uhd

$ cd ~ # build and install limesuite $ git clone https://github.com/myriadrf/LimeSuite.git $ cd LimeSuite $ mkdir builddir && cd builddir $ cmake ../ $ make -j4 $ sudo make install $ sudo ldconfig

$ cd ~ # build uhd, install, enable lime, rebuild $ git clone https://github.com/EttusResearch/uhd.git $ cd uhd/host/ $ mkdir build && cd build $ cmake ../ $ make -j4 $ sudo make install $ git clone https://github.com/jocover/OpenUSRP.git lib/ursp/OpenUSRP # DO NOT GO OUT $ echo "INCLUDE_SUBDIRECTORY(OpenUSRP)">>lib/ursp/CMakeLists.txt $ cmake ../ $ make -j4 $ sudo make install

Or, Change to UHD driver via SoapySDR

$ git clone https://github.com/pothosware/SoapySDR $ cd SoapySDR $ mkdir builddir;cd builddir; cmake ../ $ make -j4 $ sudo make install

$ git clone https://github.com/myriadrf/LimeSuite $ cd LimeSuite

Build OpenBTS

4. SDR

软件定义无线电的内容即是可以灵活定义信号的处理过程,比如输出到TCP/UDP、文字音视频解码等。其中比较有名的有GNURadio、SoapySDR、Pothos(IDE)等(这里以GNURadio为例)。推荐在Linux中安装,当然也可在MacOS或者Windows中使用MacPorts进行安装,除此之外,也有PyBombs可选。

在MacOS中安装需要使用MacPorts、XQuartz,MacPorts安装内容如下。

$ port info gnuradio $ sudo port install gnuradio+wxgui gr-osmosdr sox $ port content gnuradio $ sudo port install hackrf $ sudo port install rtl-sdr $ sudo port search gr- # if you wanna more modules in gnuradio, don't be shy

然后打开XQuartz,将/opt/local/bin/gnuradio-companion加入到X自定义应用程序菜单中(建议修改默认的X终端程序内容为_xterm -e "source ~/.bash_profile;/bin/bash"_)。

https://greatscottgadgets.com/sdr/

https://gist.github.com/machinaut/addf3438ef0c1a9cad38

https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR#RTL-SDRSource

https://pypi.org/project/pyrtlsdr/#description

HPC相关

HPC入门指南(2018-08-13)

1. History

Wikipedia is good. https://en.wikipedia.org/wiki/Supercomputer

2. Stack

2.1. Hardware

Storage Network Server Cooler

2.2. Software

Infrastructure deployment Parallel Filesystem Workload Management Development

Finally, we've got a PPT.

但是这个PPT很长,我只能截一些出来。

HPC增补(2022-02)

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

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

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

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

title: "构建基于ARM的超算集群" date: 2019-08-26 categories: - "cloud-infra" - "devices" - "hpc"


Background

Nowadays ARM-based servers are being applied to many scenarios, so we are going to port some workload to the minimal ARM SoC with NVIDIA GPU to evaluate the feasibility of production usage.

Preparation

Hardware: Legacy ARM SoC boards, e.g. Raspberry Pi, Beagle Board, NVIDIA Jetson(GPU) and standard ARM-based servers.

MPI: OpenMPICH and MPICH2.

Share Storage: ARM-based Glusterfs with pNFS.

Application: ANY

Build/Installation

Ref:

[1] https://developer.arm.com/solutions/hpc

备份工具(迁云必备)

直接说结论吧,使用下来,UrBackup与Duplicati是较为合适的两个选择。

UrBackup采用传统的CS架构,对全平台提供支持,备份选项较为丰富,而且支持公网中继; Duplicati则是较为轻量级的选择,只要安装agent即可,支持备份目标地址较为丰富,除了传统接口外也支持AWS S3接口; Bacula与BareOS(前者变种)属于同一体系,但后者支持更好广泛些; Amanda除了硬盘文件备份,也多了一个MySQL数据库的备份产品; 最后一个KVMBackup则是一个脚本,限制比较多,适合单纯的KVM环境备份。

如果与ZStack对接,这俩都可以,备份存储地址可以选择FTP,这样就可以直接使用ZStack的ZStore镜像存储,格式使用raw,然后就直接启动了。

云计算笔记


"Use dhcp or dnsmasq as DHCP server in libvirt-based environment" "2015-08-26"

Default dhcp and dnsmasq are conflict in a OS. Just change to another if one failed.

1
# yum install dhcp

/etc/sysconfig/dhcpd is no longer needed in RHEL-7. However, it is still working in other distributions. Just assign an IP to the interface which in the subnet you want dhcp serve.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[root@localhost ~]# vi /etc/sysconfig/dhcpd
DHCPDARGS="eth0 eth1";

[root@localhost ~]# yum -y install dhcp
[root@localhost ~]# vi /etc/dhcp/dhcpd.conf
# create new
# specify domain name
option domain-name "example.com";
# specify name server's hostname or IP address
option domain-name-servers dhcp.example.com;
# default lease time
default-lease-time 600;
# max lease time
max-lease-time 7200;
# this DHCP server to be declared valid
authoritative;
# specify network address and subnet mask
subnet 10.0.0.0 netmask 255.255.255.0 {
    # specify the range of lease IP address
    range dynamic-bootp 10.0.0.200 10.0.0.254;
    # specify broadcast address
    option broadcast-address 10.0.0.255;
    # specify default gateway
    option routers 10.0.0.1;
    optiondomain-name-servers 192.168.188.11, 192.168.188.12
}
[root@localhost ~]# systemctl start dhcpd 
[root@localhost ~]# systemctl enable dhcpd 
ln -s '/usr/lib/systemd/system/dhcpd.service' '/etc/systemd/system/multi-user.target.wants/dhcpd.service'

Dnsmasq is very useful in libvirt/qemu/docker based environment. To bind 192.168.200.0/24 to interface br0(192.168.200.22-bridge2eth1):

1
2
#!/bin/bash
/usr/sbin/dnsmasq --strict-order --pid-file=/var/run/libvirt/network/br0--conf-file= --except-interface lo --bind-interfaces br0 --listen-address 192.168.200.22 --dhcp-range 192.168.200.2,192.168.200.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/br0.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/br0.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/br0.addnhosts

"《KVM私有云架构设计与实践》目录" "2015-09-18"

书籍目前已出版,购买链接在下文提供,也可直接联系作者购买,微信lofyer_org。

当当 亚马逊 京东


"OpenStack自动化部署与高可用虚拟控制节点设计" "2017-05-05"

为了大家的部署方便与维护着想,我决定把这俩东西再完善一下然后再把实现源码放出来,虽不能做到产品级但是也能对付很多场景了。

自动部署(类似mirantis但更友好) 0. livecd+独立配置分区 1. 环境配置 2. PXE安装 3. 自动化脚本

Hosted-crotroller(控制节点虚拟化) 1. etcd 2. 健康检查与评分 3. 脑裂防护 4. 使用Paxos写事务机制,如果时间差机制不工作的话。

下面给大家简单解释一Paxos和时间差机制的原理(解释的不够到位,有兴趣的看实现吧):

  1. Paxos,原文可参考https://www.quora.com/Distributed-Systems-What-is-a-simple-explanation-of-the-Paxos-algorithm

此场景实用于一写多。

两人结婚,牧师问他俩,“你们愿意吗?”,“我愿意”,“我愿意”。 那么OK,就结了。

这时候假如有一对姐妹同时喜欢一个男的,牧师问他仨,“你们愿意吗”,“我愿意”,“我愿意”,“我愿意”。 如果这样,那么男的就能娶俩,如果任何一个没回答,那抱歉了一个都娶不成。

在实现时,主节点问下面节点,我要给你们都写个东西,你们都准备好没?“好了”,“好了”,“好了”,“没好”。 75%(>50%)(Quorum)的人都准备好了,那么我就写了,没准备好的那个我记住你了。

  1. Paxos时间差机制(sanlock变种) 这个机制我设计成只针对这个场景的,要求时间同步至数秒级别(这要求已经极低了。。),多写一,也可以扩展。

控制节点要你们去存储上填个表格,你们现在都能写,对吧?“对”,“对”,“对”,“不能”。。 OK,不能的那个我记住你了,其他人都来写吧。

控制节点看看表,再看看这个地方之前记的时间,嗯,过去2分钟了,写一下,我在A身上跑着; 然后A看看表,再看看这个地方之前记的时间,嗯,还没过去2分钟,不写,之前体检合格,控制节点在我身上; 然后B看看表,再看看这个地方之前记的时间,嗯,过去2分钟了,签个到留个时间,体检优秀; 然后C看看表,再看看这个地方之前记的时间,嗯,过去2分钟了,签个到留个时间,体检合格;

然后控制节点每隔1分钟看一下,嗯,你们都很健康。 又过了3分钟,哎?那个C你没写啊,去跟D站一起。

忽然,大家在填表的时候发现,控制节点都过了3分钟没写了,B就启动一下控制节点。 A发现自己与外界失去联系,就把自己身上都控制节点关了,等待救援。

  1. 基于etcd的时间差机制 上述的简化版,填的表格更少,时间差一致 大家一起写etcd的那个地方。“好”,“好”,“好”。 哎?C你没写,再见。 哎?控制节点呢?来A你检查一下启一下控制节点,B现在状态不佳。 由于控制节点之前在你A上,它现在不行了,扣A个10分,现在分没B高啊。 A你清理下现场让B去启动吧。

试图设计一个任何场景都能应对的功能。

title: "Openstack 配置及其API的简单使用" date: 2013-07-18 categories: - "cloud-infra"


安装除Neutron(Quantum)以外所有东西

在开始之前,假设有三个NIC

禁用selinux,并修改网络配置/etc/sysconfig/network-scripts/ifcfg-ethX

Internal

DEVICE=eth0 TYPE=Ethernet BOOTPROTO=static IPADDR=192.168.1.11 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=192.168.1.1 DEFROUTE=yes ONBOOT=yes

External

DEVICE=eth1 TYPE=Ethernet BOOTPROTO=static IPADDR=192.168.1.12 NETMASK=255.255.255.0 DEFROUTE=yes ONBOOT=yes

Public Bridge

DEVICE=eth2 TYPE=Ethernet BOOTPROTO=static IPADDR=192.168.1.13 NETMASK=255.255.255.0 DEFROUTE=yes ONBOOT=yes

于Feodra18中安装Openstack,可参考文档,按照这个来的话对Openstack的设计理念将会有所了解 Getting started with OpenStack on Fedora 18 或者运行

/安装完成后管理员界面为http://localhost/dashboard用户名admin,密码secrete/

openstack-demo-install

以上两种方法把除了Neutron(quantum)其他的服务都配置好了,关于quantum的配置见文末

添加虚拟机实例

可参考文档 Getting started with OpenStack on Fedora 18 在终端操作之前需要设置环境变量,将它们两者之一写到一个文件,然后source一下

export OS_USERNAME=admin export OS_PASSWORD=secrete export OS_TENANT_NAME=admin export OS_AUTH_URL=http://127.0.0.1:5000/v2.0/

export ADMIN_TOKEN=\((openssl rand -hex 10) export SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0/ export SERVICE_TOKEN=\)ADMIN_TOKEN

source FileA

这个libvirt支持kvm以及xen虚拟化,所以支持的镜像也比较多,这里下载一个已经安装好的f17的qcow2镜像

axel -n 5 http://berrange.fedorapeople.org//blog/images/2012-11-15/f17-x86_64-openstack-sda.qcow2

/注册镜像/

glance add name=f17-jeos is_public=true disk_format=qcow2 container_format=bare < f17-x86_64-openstack-sda.qcow2

然后以demo用户进入dashboard,会看到添加进来的image,根据image启动实例,打开vnc界面(非localhost访问要改ip)。

安装操蛋的Neutron(quantum)服务

这东西刚改名,nova自带的有network服务,可这个可以虚拟L2 L3 switch,那就比较有意思了

/注册quantum/

keystone service-create --name quantum --type network --description 'OpenStack Networking Service'

keystone endpoint-create --region myregion --service-id 26a55b340e254ad5bb78c0b14391e153 --publicurl "http://192.168.1.11:9696/" --adminurl "http://192.168.1.11:9696/" --internalurl "http://192.168.1.11:9696/"

/(可选)添加quantum服务用户/ get_id.sh:

$ function get_id () { echo "$@" | awk '/ id / { print $4 }' }

ADMIN_ROLE=$(get_id keystone role-create --name=admin)

QUANTUM_USER=$(get_id keystone user-create --name=quantum --pass="servicepass" [email protected] --tenant-id service)

keystone user-role-add --user_id $QUANTUM_USER --role_id $ADMIN_ROLE --tenant_id service

/服务插件二选一,linuxbrideg和openvswitch,这里使用后者,先安装插件/

yum install openstack-quantum-openvswitch

/启动并添加服务/

quantum-server-setup --plugin openvswitch

quantum-node-setup --plugin openvswitch

service quantum-server start

chkconfig quantum-server on

service openvswitch start

chkconfig openvswitch on

ovs-vsctl add-br br-int

chkconfig quantum-openvswitch-agent on

service quantum-openvswitch-agent start

quantum-dhcp-setup --plugin openvswitch

chkconfig quantum-dhcp-agent on

service quantum-dhcp-agent start

ovs-vsctl add-br br-ex

ovs-vsctl add-port br-ex eth1

quantum-l3-setup --plugin openvswitch

chkconfig quantum-l3-agent on

service quantum-l3-agent start

chkconfig quantum-metadata-agent on

service quantum-metadata-agent start

修改并配置网络 /etc/sysconf/network-scripts/ifcfg-eth1,/etc/sysconf/network-scripts/ifcfg-br-ex

External

DEVICE=eth1 TYPE=Ethernet BOOTPROTO=none NM_CONTROLLED=no BRIDGE=br-ex ONBOOT=yes

Public Bridge

DEVICE=br-ex TYPE=Bridge BOOTPROTO=static IPADDR=192.168.2.11 NETMASK=255.255.255.0 NM_CONTROLLED=no ONBOOT=yes

ip addr del 10.0.0.9/24 dev eth1

ip addr add 10.0.0.9/24 dev br-ex

这里类似VPN的重写HEADER

echo 1 > /proc/sys/net/ipv4/conf/all/forwarding sysctl -w net.ipv4.ip_forward=1 iptables -A FORWARD -i eth0 -o br-ex -s 10.10.10.0/24 -m conntrack --ctstate NEW -j ACCEPT iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -s 10.10.10.0/24 -t nat -j MASQUERADE

最后重启机器即可

通过curl使用openstack api

参考这篇文章 注意区分token和固定id

获取可用镜像

curl -s http://10.199.0.250:8774/v2/51ad87714b86442d9a74537d6f890060/images -X GET -H "X-Auth-Project-Id: admin" -H "Accept: application/json" -H "X-Auth-Token: 6083193874684f38865b086a8a5f4b7b" | python -mjson.tool

创建虚拟机

curl -i http://10.199.0.250:8774/v2/51ad87714b86442d9a74537d6f890060/servers -X POST -H "X-Auth-Project-Id: admin" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: 6083193874684f38865b086a8a5f4b7b" -d '{"server": {"name": "instance1", "imageRef": "992f5732-af50-40fc-987f-25951cbce943", "key_name": "damion-flybook", "flavorRef": "3", "max_count": 1, "min_count": 1}}'


title: "A design of user frontend for kinds of Cloud with accounting." date: 2015-05-06 categories: - "cloud-infra" tags: - "Cloud Computing" - "TBD"


I like Linode.com very much, so I'd like to make a frontend with something like that in functions.

Here's the draft.

Untitled Page

更新一下,两年前的架构设计,终于在2017年的客户那用上了,而且上了人工干预的运行前调度器,哇哈哈。

title: "Cloud Init how to" date: 2015-03-10 categories: - "cloud-infra"


OS: CentOS 6

yum install -y cloud-init


title: "How to solve the 'boot storm' problem: BCACHE" date: 2013-05-27 categories: - "cloud-infra" - "linux-admin"


Some solutions Way 1. Add more cpus.(ABANDONED) Way 2. Add a SSD as "boot cache" Way 3. Sort the boot process

POC: Way 2: Sometimes we need cache the boot section of the OS into a SSD, since no SSD on hand, let's try to use a block device made in /dev/shm

Way 3: Considering that the parallelization of the "boot action", we have to predict the action in the near future

Experiment: Using BCACHE now...or flashcache

title: "A light-weighted VM webadmin" date: 2013-06-18 categories: - "cloud-infra" - "linux-admin"


The infrastructure of it: Management: Based on django, communicate with Agent Agent: A daemon, used for communicating with Management and managing the VMs

TO MAKE GREAT USE OF KVM. https://github.com/lofyer/webadmin

title: "MyIDC--Everything's traceable" date: 2013-12-11 categories: - "cloud-infra"


相关手册参考MyIDC_Book

细节索引: gluster hadoop(with ARM as an option) drbd/heartbeat foreman/puppet nagios ovirt openstack owncloud asterisk

配置细节参考: MyIDC Source

Infrastructure:

Board: x86小板 SBSA小板 Cabinet: 亚克力自制 网络: 电信拨号接入外网 SDN 资源分配: 高可用监视与控制服务(os1-2) 高可用存储(os3-n) 并行计算(os3-n) 高可用虚拟机服务(os1/2+os3-n) 独立外设接入设备 安全: 证书认证(在量子计算机面向大众之前这个还是很靠谱的) 应用商店: 社会工程学测试 leapmotion控制插件 语音控制插件 手机控制插件


title: "openvswitch howto" date: 2013-07-25 categories: - "linux-admin"


Here, I use kernel-3.4.58.

emerge =net-misc/openvswitch-1.11.0


title: "硬盘、RAID组与Ceph分布式存储IOPS计算公式" date: 2017-06-04 categories: - "linux-admin" tags: - "Storage" - "Performance"


防怼说明:本文用于速算,想把难以量化的环境变量以及各种组合拿来说事儿的请自行Google,或者问厂商和IDC要报告去。

机械硬盘

1
2
3
7200硬盘IOPS = 1000/(3 + 1000*(7200/60)/2) = 140
10k硬盘IOPS = 1000/(3 + 60000/10000/2) = 167
15k硬盘IOPS = 1000/(3 + 60000/15000/2) = 200

其中3为寻道延迟,7200/10k/15k为转速(rpm),1000*(7200/60)/2为旋转延迟(旋转延迟一般用转一圈所需时间的1/2表示),结果为理论峰值,实际还会有系统延迟导致测得IOPS一般低于此值。

RAID组 由于RAID组需要校验以提供恢复功能,所以会存在一定写惩罚,这个系数如下: RAID0: 1 RAID1: 2 RAID5: 4 RAID6: 6 RAID1-0: 2

所以RAID组IOPS = 硬盘写IOPS硬盘数量写操作百分比/写惩罚系数 + 硬盘读IOPS硬盘数量读操作百分比。

以4块IOPS为180的SAS硬盘组RAID 6然后百分百随机写操作为例:

IOPS = 180*4/6 = 120

Ceph的IOPS经验公式 由于Ceph存储结构不同于物理硬件,所以影响其IOPS的因素主要有网络、副本数量、日志、OSD(硬盘)数量、OSD服务器数量、OSD IOPS等,这里给出一个来自Mirantis的经验公式:

IOPS = 硬盘IOPS * 硬盘数量 * 0.88 / 副本数量, 其中0.88为4-8k随机读操作占比(88%)。

关于Ceph的IOPS计算仅供参考,计算结果可能会跟物理环境实测有较大偏差。