Linux

问题 raspberry pi zero w 的系统目前树莓派官方推出的镜像是armv6hf debian 11，而ROS2官方只支持ubuntu debian aarch64，不支持arm32，所以要在raspberry pi zero w上使用ROS2必须从源码构建。那么问题就在于如果直接在zero w上编译，显然因为硬件的原因(cpu: 1 core, memory: 512M)，编译将会极其缓慢，我也尝试使用armhf交叉编译工具链在aarch64系统上编译ROS源码，但是会出现系统库缺失问题。同时我还考虑到后续的开发环境和zero w原始系统环境的一致性问题，我决定采用zero w的原生debian 11 armhf系统做为rootfs，制作docker image，然后运行在aarch64系统上(比如树莓派4，jetson agx)，这样编译出来的ros2直接可以运行在zero w上，并且运行环境和编译环境都是保持一致的，这样对后续的调优以及debug处理都会非常方便。 兼容性 raspberry pi zero w 使用的是cpu arm1176jzf-s，armv6版本，raspberry pi 4 使用的是 ARM Cortex-A72 ARMv8-A版本，我们可以从Cortex-A72文档中看出AArch32 for full backward compatibility with Armv7，也就是armv8 aarch32指令集兼容armv7 aarch32，同时armv7指令集兼容armv6，那么也就意味着armv6的二进制文件是可以直接在raspberry pi 4 aarch64上运行，反之aarch64 binary当然无法在armv6系统上运行，这样思路一下子清晰了，我们可以将armhf的根文件系统制作成docker image，运行在aarch64系统上，然后编译ros2，最后将编译产物拷贝到zero w上直接运行。 解决问题 command line run on raspberry pi 4 ubuntu 20.04 aarch64 os donwload rpi zero w image (raspios-bullseye-armhf-lite) ...

我自己设计了一套简陋的k8s persistentvolumeclaims方案，后端采用Moosefs做为分布式数据存储，原理是基于kubernetes events机制，当接收到create pvc的消息时，后台control应用会在moosefs上创建对应的pv，并绑定相应的pvc，为了方便应用在各个节点间移动，我将moosefs文件系统挂载到了每一个worker节点下，这里就产生了一个问题：如何保证moosefs master高可用！moosefs官方有两个版本一个是opensource，另外一个是Pro，Pro版本自带HA功能，而opensource只有备份master的功能，当出现故障时只能通过手动恢复master。为了满足高可用的需求，我申请了Pro版本为期一个月的使用权限，购买永久授权官方价格是1425EUR/10TBi，其中包括了一年的维护费570EUR，这个价格对于我个人使用Raspberry Pi来说实在过于昂贵，并且我测试了mfsmaster pro的性能，发现和opensource版本相比没有显著的提升，考虑到mfsmaster是单线程应用，我决定以后自己维护一套mfs源码，增加它在kubernetes上的功能。这样经过调研，我发现了mfs master高可用的方案（上图所示）。 MFS Opensource Master HA 总共分为三部分： mfsmaster DRBD Keepalived mfsmaster：存储mfs的元数据。 DRBD：实现网络层块设备的实时复制，类似RAID 1。 Keepalived：监控两台mfsmaster的健康状况。 当mfsmaster A出现异常时，keepalived会将VIP迁移到mfsmaster B上，并将A由原先的master变成backup，同时卸载mfs metadata的DRBD USB磁盘，将B由原先的backup变成master，同时挂载mfs metadata的DRBD USB磁盘，启动mfsmaster，这样就完成了故障节点的恢复。 在使用moosefs之前，我测试过openebs，longhorn，beegfs，glusterfs这些分布式文件系统，对比了它们之间的性能和易用性，最终还是选择了moosefs，因为mfs的扩展实在是太方便了，并且客户端是通过fuse访问文件系统，像macos，freebsd，netbsd都可以使用，在ARM64平台上的读写性能也是优于其他几个分布式文件系统的。当然最后的缺点是官方好像停止维护mfs v3版本了（github一直没有更新），v4版本仍然处于闭源状态。

这是我目前使用的内容管理平台的架构，前端的两台google comput engine 用于连接全球互联网以及托管静态站点，后端的集群全部运行在自己托管的ARM64系统平台上，集群内部运行着Cloudflared隧道，当用户请求invisibleart时，请求会通过cloudflare edge network发送到隧道中，cloudflared会将请求发往目标地址wordpress engine，后端的数据库采用的是vitess mysql集群，前期使用过tidb，发现与wordpress存在兼容性问题，最后决定使用vitess，在备份，扩容，和灾难恢复中，vitess还是非常可靠的。

Reference TIDB architecture 为什么使用 TIDB 机器采用的架构是ARM64。 尝试使用分布式数据库架构。 解决高可用问题，当一台Raspberry Pi数据库节点宕机时，不会影响数据的写入。 对比了vitess和TIDB，TIDB更加兼容ARM64，容易上手实验。 为后面的金融交易系统作准备。 架构 组件及功能 TIDB Server TIDB Server 是一个无状态应用，它本身并不存储数据，前面可以放置负载均衡，外部应用请求到TIDB Cluster中的节点，TIDB server将分析和计算应用请求的SQL，并将请求转发给底层的数据存储TiKV。 PD Server 整个TiDB集群的元信息管理模块，存储每个TiKV节点的数据分布情况，以及集群的整体拓扑情况，根据TiKV节点实时上报的数据分布状态，PD server向TiKV节点发布数据调度命令。 Storage Server TiKV 负责数据存储，是一个提供事务的key-Value分布式存储引擎，存储的基本单位是Region，每个Region存储一个Key Range的数据，每个TiKV节点会负责多个Region，TiDB的SQL对SQL做完解析后，会将SQL的执行计划转化为对TiKV API的实际调用，所有的SQL数据全部存储在TiKV中。 TiFLASH Server 特殊的存储节点，数据存储是以列式的方式进行存储，主要功能式为分析型的场景加速。

简介 volcano是一个用于高性能工作负载场景下基于kubernets的容器批量引擎。 应用场景: 机器学习以及深度学习 生物以及基因计算 大数据应用 概念 Queue 容纳一组podgroup的队列 apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: distcc spec: weight: 1 reclaimable: false capability: cpu: 50 字段: weight -> 该queue在集群资源划分中所占有的比例，该queue占用的资源比例为: （weight / total-weight) * total-resource，资源软约束。 capability -> queue内所有podgroup使用资源之和的上限，资源硬约束。 reclaimable -> 当该queue在资源使用超过该queue限制时，是否允许其他queue回收该queue使用的超额资源。 使用场景 Total Cluster CPUS = 4cores --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test1 spec: weight: 1 --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test2 spec: weight: 3 # 创建p1 p2 podgroup分别属于test1,test2，分别向p1 p2中投入job1 job2，资源申请分别为1C和3C，两个job均能正常工作 --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test1 spec: weight: 1 # 首先创建test1 queue，创建podgroup p1，在p1中创建job1 job2，资源分配分别为1C和3C，job均能正常工作。 --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test2 spec: weight: 3 # 创建test2 queue， 在该queue中创建podgroup p2，在p2中创建job3资源申请为3C，由于test2 queue weight=3，从而job2将被驱逐，test1 3C资源将归还给test2。 --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test1 spec: capability: cpu: 2 # 创建test1 queue，容量设置为2，也就是资源上限使用为2C，创建p1 podgroup，在p1中创建job1 job2资源申请分别为1C和3C，那么job1正常运行，job2处于pending状态 --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test1 spec: weight: 1 reclaimable: false --- apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: test2 spec: weight: 1 # 创建 test1 queue，reclaimable为False，也就是该queue不归还多占用的资源，分别在test1 test2 queue 中创建p1 p2，在p1中创建job1，资源申请为3C，由于权重比例为1:1，此时 test1 多占用1C，在p2中创建job2，资源申请为2C，此时由于test1不归还多占用的资源，job2将处于pending状态。 PodGroup podgroup是一组强关联pod的集合，用于批处理工作负载场景。 ...

架构

本文图片来源Openebs 前言 关于 OpenEBS OpenEBS是一个运行在Kubernets上的开源存储项目，符合CAS(Container Attached Storage)架构， 它的所有组件全部运行在用户层，属于在k8s上云原生的分布式文件系统。 OpenEBS文件系统提供如下类别的特性，每个特性都可以用于某个特定环境下的解决方案。 cStor: 支持容错，高可用性，副本拷贝，支持快照，克隆等技术，其后端是由ZFS支持。 Jiva: 后端引擎为年轻的Longhorn，支持容错，副本拷贝，但没有cStor的快照和克隆技术。 Dynamic Local PV HostPath: 直接使用本地文件存储，优点是低延时，缺点是不支持高可用，一旦本地节点宕机或者本地磁盘损坏，则导致数据丢失， Dynamic Local PV Devices: 和HostPath类似，直接使用本地的硬盘进行存储，缺点也是无法支持高可用，但是低延迟。 Dynamic Local PV ZFS: 不支持高可用，但可以使用ZFS的功能(制作快照和克隆技术)，从而提升数据的保护能力，便于从灾难中恢复数据。 特性(Features) CAS 架构: PV和PVC都是容器化的，便于kubernets进行管理。 同步副本: 当采用cStor Jiva Mayastor存储引擎时，实现多副本同步拷贝，从而提供数据的高可用冗错机制。 快照和克隆: 采用cStor存储引擎时，支持写时复制快照技术，生成快照有助于我们可以回滚数据，克隆可以快速的生成一套生产环境数据以便开发在测试环境使用真实的生产数据。 备份和恢复: 使用备份工具及插件，快速的备份文件和恢复文件。 监控: openebs 组件会提供Metric接口，从而方便prometheus对其监控，进而调优整套存储方案的性能。 Alpha特性 支持ARM64，这也是我目前在使用的原因，自己在组建一套7*24小时运行的Polkadot委托节点，因为直接和收益挂钩，所以我调研了很多容器化的存储架构方案，虽然Openebs性能不如其他的老牌分布式存储系统，像Ceph，glusterfs这样的，但是它提供的CAS架构和高容错机制，以及支持ARM64，就让我决定选择它用于金融行业的云存储架构方案。 架构 基于单一服务的PV架构 整个PV的底层读写操作全部在内核层面完成，Kubernets只是增加了一层抽象，将PV通过底层的分布式文件读写接口导出到用户层，Pods通过PVC与PV绑定进行数据的读写处理。 基于微服务的PV架构 典型的CAS架构，数据的读写操作全部在用户层处理，CAS架构中的副本拷贝以及存储控制器全部由kubernets自身来进行调度，PV直接从CAS控制器的底层资源中获取存储设备，Pods通过PVC与PV绑定，从而完成数据的读写处理。 None CAS 与 CAS 对比 CAS的优势: 更加敏捷，可以直接在Pods层面去优化存储控制器。 更加精细的监控，能够直接监控到每一个Volume的IOPS，读写延迟。 解耦合，不依赖于第三方的云存储系统，比如你可以不改变yaml文件的情况下，将应用从一个集群，迁移到另一个集群，如果采用None CAS，则会非常依赖对于Kubenets不可见的存储管理系统，迁移过程中需要修改yaml文件中关于PV的描述。 云原生，好处就在于能够直接与其他系统对接，比如文件系统监控，管理，采用Kube CRD的方式直接调用底层的存储系统。 微服务架构 采用微服务的方式极大的提高了分布式文件系统的高可用性，因为整个存储的服务全部运行在用户层，每一个服务都可以从一个节点迁移到另外一个节点，只要我们满足副本的可用性，即使某一个节点宕机也不会影像我们线上的数据访问，保证系统的可用。 从上图中，我们可以看出Storage Controller直接管理底层的副本处理的相关Pods，应用层的Pods通过PV与Storage Controller沟通。 ...

NVIDIA CLARA DISCOVERY 生态 Nvidia进军医疗领域，从封面我们可以看到一个环状结构: 自然语言 -> 病毒基因序列 -> 病毒蛋白质结构 -> 新药物与病毒蛋白质对接 -> 分子对接动力学模拟 -> 候选药物临床试验检测病人肺部医疗影像 -> 自然语言 简介 在Nvidia GTC 2020秋季大会上，Nvidia发布了NVIDIA CLARA DISCOVERY 药物研发框架，目的就是加速全球药物研发的进度，之前Nvidia收购ARM的消息，我就意识到未来Nvidia有想要统治边缘计算领域的野心。不出所料，这次GTC发布会上Nvidia更新了很多产品线，包括大到数据中心的计算模块BlueField-2，小到边缘领域jetson Nano 2G，最让我激动的还是CLARA DISCOVERY，因为自己短期的目标就是如何将边缘计算用于医疗领域，比如个人可以通过边缘计算设备结合自己从医院检查获得的诊断数据来计算出自身疾病的现状，还有对Covid-19 CT，ChestXRay的判断检测。 是什么 Clara Discovery 集成了很多框架和应用，包括基因序列分析，蛋白质对接和结构预测，分子动力学模拟，医学图像识别和分割，自然语言处理。 基因序列生成 NVIDIA Clara Parabricks Collection 图像处理 NVIDIA Clara Imaging 蛋白质结构 RELION MELD 分子动力学模拟 GROMACS VMD NAMD 重点 NVIDIA Clara Imaging 主要分为两部分: Clara Train SDK -> 用于训练模型 架构图: Getting started with Clara Train SDK Clara Deploy Bootstrap -> 将模型部署到kubernets集群中 ...

概要 这篇文章不会过多讲述ETH的具体技术细节，主要会涉及如何成为ETH2.0的验证者。 今年年底，ETH将完成阶段0的升级，从PoW工作量证明迁移到PoS权益证明，之前自己在公司的黑马活动上思考了如何利用过剩的算力来做有价值的事情，PoW从理论上来说比较浪费能源，矿工购买大量矿机进行运算，而采用PoS机制之后，只要成为一名验证着，我们就能完成对区块的铸造，而不需要像PoW一样，购买大量矿机通过挖矿来产生新区块，但是要成为验证者中的一员，你需要将一定数量的加密货币进行锁仓做为权益的证明，如果你运行的验证节点验证一个区块，并检查里面的交易是否都是有效，如果通过，你将收到一笔奖励以做为回报。 ETH2.0 架构 架构图引用自prylabs Beacon Node 中文称之为信标链，是ETH2.0的核心部件，类似于海洋上的灯塔，引导船只前进的方向。 Validator Client 会连接信标链，并且管理质押的ETH密钥对。 如何加入 ETH 2.0 目前运行在 Medalla(已经更新为prater)测试网 访问Become a validator and help secure eth2 开始进入Get Started环节 Generate Key Pairs 这一步是用来生成验证者的密钥对 选择你使用的操作系统，然后安装eth2.0-deposit-cli 生成密钥对比如: python3 ./eth2deposit/deposit.py –num_validators 2 –chain medalla –folder ./keys/ 生成的keystore会保存在./keys文件夹下，因为目前是测试网所以需要指定 –chain medalla，像deposit_data-1600238876.json这样的文件里面存放了公共信息，下一步我们就需要上传该文件deposit_data-1600238876.json Upload Deposit File: 上传deposit_data-1600238876.json文件 Connect Wallet: 连接到你自己的本地钱包，这里我们使用Chrome MetaMask插件 如果你的钱包里面没有测试ETH，那么可以去这里申请，在自己的推特上发一条包含自己ETH地址的推文，比如0x0bDebe6eF5D0Ca744451946a70fEbd1B505dD92a my TestNet addr，然后将推文链接复制到上述网站的提交项中，最后选择87.5ETH/9days，你就会收到87.5个测试ETH，记住metamask上一定要选择goerli测试链。 下一步就是将32ETH打到对应的Medalla Beacon Contract合约地址上，如果你像我一样启动了两个验证者，那么总和就是64ETH，完成之后，我们就可以看到类似以下的页面。 0x0bDebe6eF5D0Ca744451946a70fEbd1B505dD92a 最后就是选择支持ETH2.0的多客户端，这里我们选择golang版本的prysm 完成对信标链beacon chain和验证者validator的部署 部署文档可以参考这里 获取prysm.sh: curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh –output prysm.sh && chmod +x prysm.sh ...