Raspberrypi

入手 2020年初的时候自己就已经规划未来自己的方向是往ARM设备边缘化计算方向发展，预计未来3-5年里ARM平台会在各个计算领域中崛起，从智能手机到小型Arduino边缘设备，再到大型的超算系统，在世界的每一个角落我们都可以看到ARM的身影。 为了促进SARS-Cov-2的疫苗研发，自己也组建了一套ARM64通用计算平台，硬件采用的是Raspberry Pi 4，系统采用Ubuntu 20.04 aarch64，因为主打低功耗，所以整个计算平台都是在家里运行，50台的树莓派电力消耗基本在300-400瓦特，同时自己也在组建Kubernets下的机器学习平台，能够在ARM上完成模型的训练，当然性能上和X86 + GPU无法相比，总体上自己可以学习到大型分布式项目的训练和集群的大规模管理经验。 后来传出消息，Nvidia准备收购ARM，消息一出，我就更加坚定，ARM绝对是以后低功耗通用计算平台的未来，虽然现在ARM的生态不是非常完善，很多开发者的工具链从X86移植到ARM平台会有很大的困难，然而到了Apple发布新款M1芯片时，所有的一切都发生了质变，如果说ARM引领我们走向另一个奇幻的CPU世界，那么Apple就是这个部落的首领他带领我们冲出敌人的团团包围，走出一条自己的道路，而这条路会由蜿蜒小道变成通往两个世界的高速公路。新款M1芯片发布后两天，我仔细看了官方的发布视频，就立刻下单购买一台Mac Mini M1，决定使用这台生产力设备来增加自己的收入，剪辑视频，制作App，当然还有玩玩Tensorflow + Swift，虽然机器要到12月份才能拿到，然而今天看推特时让我感觉我的选择果然没错。 SoC 架构 Apple将所有的处理元件，内存，处理器，存储全部封装在M1芯片中，采用5纳米工艺。 从图中可以观察到CPU和GPU都是共享统一内存，并且嵌入了Neural Engine神经网络处理引擎。从官方的介绍中可以得知，在处理图像和视频时，处理速度与前一代相比提升3-4倍，光这一点，我就觉得带M1的Mac很值得购买，还有未来Tensorflow肯定会支持M1，那么到时候可以测试下，直接在Mac Mini上训练深度学习模型，训练时间会缩短多少倍，相比于前一代的Mac Mini。 Apple 吹着牛说，自己的M1是最先进的，功耗最低的SoC，那么就让我们拭目以待。 golang on M1 参考文章链接: 在Apple M1上运行golang native 在Raspberry Pi 4 arm64上构建go-darwin-arm64-bootstrap git clone https://go.googlesource.com/go git fetch https://go.googlesource.com/go refs/changes/58/272258/2 && git checkout -b change-272258 FETCH_HEAD cd go/src GOOS=darwin GOARCH=arm64 ./bootstrap.bash

参考文献 Polkadot Lightpaper Polkadot 架构 Polkadot被称之为下一代区块链协议，它是一套多链系统，它允许在任意其他区块链链之间进行数据的交换，与常见的PoW挖矿相比，我更看好类似Polkadot通过NPoS这样的方式来生成区块，我们可以直接将节点运行在成千上万的边缘设备上，这样就使得整条链具有更强的安全性和去中心化。 Polkadot 采用分片机制，架构如下: Polkadot的核心链是Relay Chain，我们称之为中继链，所有的分片处理都是在所谓的ParaChain，我们称之为平行链。所有的交易处理都是在平行链中完成，这样就可以缓解核心链的拥堵，就像目前的ETH1.0，当链ETH MainNet上的交易量增加时，由于所有的节点都需要验证打包交易的区块，就会出现队列堵塞问题，最明显的表现就是，以太坊的gas手续费开始增加，如果保持原有的gas费用，那么用户发出的交易打包速度将会非常缓慢，所有我们才会看到ETH2.0被开发出来，ETH2.0也是基于分片模式来完善ETH1.0的架构，从而提升链中每秒的交易量。Polkadot中的平行链可以通过API接口与中继链进行通讯完成数据的传输。平行链会构造和提交候选区块到中继链中，中继链会通过最后的共识确认来敲定将哪一个区块加入到链上。通过分片的机制，Polkadot的很轻松的做到链性能和功能的扩展，举个例子，我们可以通过桥接，将以太坊和比特币这两条不同的链接入到Polkadot中继链中，这样我们从ETH兑换到BTC，或者BTC兑换到ETH，整个过程都是无缝的，我们实现了跨链支付。 组成 Relay Chain -> Polkadot的核心部件，保证网络的安全性，达成共识，完成跨链协议。 Para Chains -> 平行链中可以是一条独立的区块链，可以拥有自己的Token，平行链可以通过购买Slot对接中继链。 Bridges -> 通过桥，使得Polkadot可以和以太坊或者比特币这样的网络进行对接。 Validators && Nominators -> 通过质押代币DOTs来保证中继链的安全性，验证来自Collators的候选区块，并与其他验证着参与整个Relay Chain的共识，也可以让提名人向验证者发起提名，质押一定数量的DOTs代币给验证者，从而让提名人也参与到整个网络治理的过程中。 Collators && Fishermen -> 通过收集用户的分片交易信息，为验证者提供证明并维护分片。 Council Members -> 理事会成员主要的功能是: 提出公投，以及否决具有危害意义的公民投票。 Technical Committee -> 技术委员会由构建Polkadot的团队成员组成，可以和理事会一起提议紧急全名投票，快速进行投票和实现。 Dot Token -> 代币Dot的三个作用，治理，质押，绑定，用英文描述就是Governance，Staking，Bonding。 治理: 代币持有人拥有管理整个Relay Chain的特权，包括网络的升级和维护。 质押: 代币持有人通过质押一定数量的代币来保证网络的安全性，良好的参与者将获得奖赏，反过来破坏网络的参与者将损失他们质押的一部分代币。 绑定: 通过绑定代币来完成新平行链的加入。 如何参与 参考文档: How to Nominate on Polkadot Run a Validator 成为Validator 编写中… 成为Nominator 编写中…

从Rosetta@home到Folding@home 先从主要的原理入手，Rosetta@home只是预测能够Binding Covid-19外层刺突蛋白的人工合成药物的分子结构，可以想象成类似摄影中的拍照技术，Rosetta能够静态的预测某一个蛋白质的特征，但是它无法预测该蛋白质分子在时间的演化下是如何运作的，因为分子之间会有电势差异，产生电磁力的作用，所有分子内部的构成元素都会随着时间的变化相互影响而产生运动，当我们在Rosetta中设计出一种能够绑定SARS-COV-2病毒的合成药物时，需要进入测试阶段，观察该药物是否能稳定的与病毒蛋白质结合，因为预测的结构是静态的，我们无法知道蛋白质结构在相互作用运动的情况下是否能够很好的与病毒蛋白质结合，这里Folding@home就派上用场了，它就类似于摄影中的拍摄动态画面，我们可以从Rosetta@home上拿到静态的蛋白质结构链，然后在Folding@home中模拟该蛋白质随着时间的推移是否能够很好的与病毒蛋白质结合，从而产生抵抗病毒的作用。 加入计划 我会关闭之前一直在运行的Rosetta@home，目前Rosetta@home已经发表了论文，预测出了能够结合SARS-COV-2的人工蛋白质结构，所以现在需要做的就是进行大量分子动力学模拟，并且Folding@home已经支持ARM64架构，我会把自己运行的算力全部迁移到Folding@home，期望全世界的感染人数能够降下来，使得经济能够复苏。

本文图片来源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沟通。 ...

www.cineneural.com网站初版已经上线，主网站托管在自己搭建的树莓派4集群上，官网的主要功能就是提供医学影像处理的入口。 To Do list: 加密所有流量。 增加cloudflare <-> Home Raspberry Pi的网络稳定性。 提供医学影像检测入口，上传影像，以及下载分析结果。

概要 这篇文章不会过多讲述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 ...

Rosetta@home 新发现了一种抑制SARS-Cov-2的计算机合成药物，论文发表在Science科学杂志上，De novo design of picomolar SARS-CoV-2 miniprotein inhibitors。 下图为目前自己的算力贡献。 论文内容解析 Doing…

Kubernets Wiki 最近看了Large-scale cluster management at Google with Borg，Borg是谷歌公司自己内部开发的一套集群管理系统，后来开源社区也就慢慢开始孵化和推出了Kubernets集群管理系统，k8s和Borg有着很深的渊源关系。 先从Kubernets入手，我们来看下K8s的组件: Kubelet 在每一台节点上都会运行Kubelet，管理节点上的容器。 kube-apiServer 验证和配置关于Pods,Services,ReplicationControllers等数据，其他kube都需要通过调用api来获取所需的数据。 kube-Controller-Manager 用于控制系统的状态，通过API接口来同步系统数据，比如将系统从A状态同步更新到B状态。 kube-proxy 运行在每一台的节点上，主要作用充当网络代理，能够简单的处理TCP UDP 转发和轮询。 kube-scheduler 用来调度Pods，当有新的Pods需要创建时，调度器会给每一台工作节点打分，然后将Pods分配到满足要求的节点上。 然后再看关于Borg系统的描述，每一个集群都称之为一个Cell，每一个Cell都运行在一个独立的数据中心里。 Borg 架构 Borg 设计准则主要是以下三点: 隐藏对系统底层资源的管理以及容错处理，方便开发者将注意力集中在开发上，而不过多注意底层细节。 系统中运行的应用都是高可用的，某台节点的宕机，不会引起服务的不可用。 必须非常高效的在数万台节点上完成对应用的扩展。 Borg的用户基本上是google内部开发人员和SRE，正是因为google注重对SRE的发展，才慢慢在google内部形成了上述三点的认知体系，提到google SRE不得不提GOOGLE SRE How Google Runs Production Systems这本书，我只看过中文版，看完英文版之后会写一篇博客专门详细讨论这本书里的内容。 集群设计架构 Borg系统有一套自己的配置文件语法体系BCL，然后通过borgcfg加载到基于Paxos的分布式数据库存储中，在k8s中我们是通过编写Yaml状态配置文件，然后使用kubectl将状态配置通过kube-api接口提交到后端分布式ETCD存储中，在边缘设施的k8s场景中，像k3s，microk8s会默认使用基于SQL的数据库引擎Dqlite，dqlite也采用了Raft一致性存储协议，这样就可以做到边缘设备上的k8s高可用。 在Borg系统中，SRE工程师大部分通过Borgctl命令行工具对系统进行访问和修改。 Borg的核心组成部分有Scheduler，BorgMaster，Paxos Datastore，LinkShard，Borglet。 BorgMaster: master分为两部分，第一部分是对外处理请求，比如RPC调用获取集群状态，任务分配信息，获取borglet的状态，第二部分是用于处理集群内部的任务调度模块，master 支持高可用，所有的数据都是通过基于Paxos的数据库进行存储，当前master leader宕机之后，master 副本中会选举出新的master节点继续对外提供服务。最引人注目的是，master节点的数据存储使用了CheckPoint技术，每隔一段时间，系统都会自动保存当前的状态到checkpoint中，这样在集群发生问题的时候，我们就能将集群回退到前一个正常的checkpoint的状态，并且在线下使用这些point来做debug。 BorgScheduler: 当任务通过master提交之后，master会将数据存储到paxos中，并且将任务放到待处理队列中，Scheduler会根据这些任务的优先级进行先后处理，Scheduler拿到任务之后，计算哪些机器是符合要求的，根据一定的打分算法给这些机器打分，再根据分数将任务分配到对应的节点上。 Borglet: 运行在每一台节点上，用于管理任务的生命周期，比如停止运行重启，维护操作系统的内核配置，borgmaster会定期去拉取let上的状态信息，如果let没有应答那么master就认为这个对应节点已经下线或者宕机。 Jobs&&Tasks: Borgs运行的对象以Jobs Tasks来进行管理，一个Job可以由多个Tasks组成。以下是任务的生命周期。 当任务被提交到Borg Master时，如果任务被master接受则会进入Pending状态，等待Scheduler进行调度，调度完成之后，组成job’s Tasks就开始运行，如果超出系统的资源限制，Tasks就会被Evicted，然后进入Pending状态，继续等待被调度到新的节点上，当Tasks运行结束，任务的状态会被更新为Dead，有点像进程的生命周期，整个主干过程就是 Create -> Pending -> Scheduling -> Runing -> Dead。 然后我们看下k8s整个架构以及任务的调度是如何完成的，可以与Borg对比，发现两者的优缺点。 ...

Why 使用Mathematica + Python web framework提供对外的服务平台，由于机器上运行的都是AARCH64系统，而ARM Mathematica目前只支持32位的v6 v7，需要在aarch64上增加支持armhf v6 v7的运行时库。 Small TIPS 为了能够在Ubuntu 20.04 aarch64 系统上运行Mathematica ARM 32Bit，查阅了很多相关资料，最后试验成功，可以通过以下方式在aarch64系统上运行32位的Mathematica。 最主要的就是这一行：dpkg –add-architecture armhf 添加armhf源，后面就是安装对应的armhf libc libc++ zlib。 Mathematica 的相关程式安装包在这里 FROM ubuntu:20.04 RUN apt-get update RUN dpkg --add-architecture armhf RUN apt-get update RUN apt-get install libc6-dev:armhf libstdc++-9-dev:armhf zlib1g-dev:armhf COPY ./ /tmp/ WORKDIR /tmp RUN apt install ./wolframscript_1.4.0+2020081702_armhf.deb -y RUN apt install ./wolfram-engine_12.1.1+2020081901_armhf -y WORKDIR / Python Web and Wolfram Backend Demo 对应于Mathematica armhf位版本，安装gcc和g++都为armhf版本，所以我们安装的Python和Python Modules也需要对应到armhf。 ...