百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

【区块链】HyperLedger Besu Docker异地组网

nanshan 2024-10-22 12:54 22 浏览 0 评论

由于我们整个HyperLedger Besu区块链集群都是基于Docker搭建的,因此Docker异地组网是一个必须解决的问题。在调研期间找到的三种解决方法,

  1. 使用Consul集群实现。Consul会使用自己的通讯协议,通过配置Docker的daemon.json用cluster-store参数来实现通讯(填写配置的时候需要绑定本机网卡)。这种方式需要额外部署高可用的Consul集群且需要与Docker进行强绑定;
  2. 使用ETCD组网。虽然原理跟Consul一样但由于ETCD由C语言编写性能上会比Consul更出色。但由于本人能力有限搞了一阵子没搞定所以最终放弃了ETCD的实现方式;
  3. 使用Docker Swarm组网。Docker从1.12.0版本开始这个Swarm模式就可以使用,只需做小小的调整即可实现;

综上对比,Swarm简单、易用且与Docker无缝结合是我选择它的最主要原因。考虑到后期还会有其他节点接入且接入方式不可控(有可能是云服务器,有可能是本地机房服务器),这就要求组网难度必须要低且可靠性强,Swarm完全能够满足我当前的需要。

PS:在实际生产上由于云服务器的部分限制我们会采用另一种实现方式,这个会在后续的文章中提到。

1. Docker Swarm原理

从上图可以看出Docker Swarm提供了Cluster(集群管理模式)、node discovery(服务发现)、scheduler(滚动更新)等服务。其中通过服务发现能够记录到节点之间的访问地址,继而通过负载均衡自动寻址实现容器内部通讯。

2. Docker Swarm异地组网

异地组网达成标准为必须要求异地服务器能通过Docker容器内分配的IP相互“通讯”(本例则以“能ping通”作为达成通讯目标)。在这里我不会花篇幅去详细说明Swarm网络中LB转发和寻址的问题也不会深入overlay网络进行详解,这些网上一大把。我只分享能够立刻看到效果的东西就好......

2.1 服务器信息

为了验证Docker Swarm的可行性,本次例子采用了四台VM来做模拟

机器名称

机器ip

使用系统

Docker版本

node202

192.168.200.202

CentOS

18.09.3

node203

192.168.200.203

CentOS

18.06.3-ce

node204

192.168.200.204

CentOS

18.06.3-ce

node205

192.168.200.205

CentOS

18.06.3-ce

以上四台VM都是通过桥接来对局域网通讯的,这里做验证的情况下我们就先不考虑公网IP之间能否通讯的问题,如果服务器之间连最基本的通讯都无法实现的话就不用考虑组网问题了。

2.2 创建Swarm网络

这里使用node203作为主网络服务器,使用ssh登录服务器后执行

docker swarm init \
--advertise-addr 192.168.200.203

执行上面的语句后会得到其他工作节点加入需要命令

docker swarm join \
--token SWMTKN-1-5trsmvw8zfd84gxg9a71akao9hi0ro3tus6v2t8c2i0c9qtoi0-268axfn4r939lvj699whwiw7r 192.168.200.203:2377

若这命令丢失了的话可以在203机器上执行下面语句重新生成

docker swarm join-token manager

接下来将“docker swarm join --token”这段命令在需要成为节点的服务器中执行,全部执行后可以在node203服务器中通过docker node ls命令查看到节点加入情况,如下所示:

root@node203:/home/paohe/Documents/blockchain/vault/config# docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
swnvjvsxfeirdlaujbaznxhts     node202             Ready               Active                                  18.09.3
zb3nif68me9mvm0go3l2agkk7 *   node203             Ready               Active              Leader              18.06.3-ce
uk65wbkadgg6mwzk9h1yspdw4     node204             Ready               Active                                  18.06.3-ce
zx1elhm4oihcqm0bgggt2y283     node205             Ready               Active                                  18.06.3-ce

所需组网服务器都加入后通过docker network ls能够看到node203服务器上多了一个名为ingress的overlay网络,如下图:

root@node203:~# docker network ls
NETWORK ID          NAME                 DRIVER              SCOPE
f5a6b27119ef        bridge               bridge              local
e1902557eda0        docker_gwbridge      bridge              local
c5ad4fc3d434        host                 host                local
u5vjecempood        ingress              overlay             swarm
f96d226b8f69        none                 null                local
75f6834bc0cf        prometheus_default   bridge              local
173d62c10b82        vault_default        bridge              local

在这之后就能够创建自定义的Swarm网络了。

2.3 验证Overlay网络可用性

为了进一步验证Swarm网络的可用性,建立另一个overlay(覆盖网络)进行验证:

docker network create \
-d overlay \
--subnet=192.18.0.0/24 \
--gateway=192.18.0.254 \
--attachable besu_swarm

执行上面语句创建了一个名为besu_swarm的overlay网络并且设定了子网段范围从192.18.0.0开始,网关为192.18.0.254。在node203服务器执行docker network ls查看自定义网络besu_swarm,并且由于创建的是基于Swarm的overlay网络,因此node203服务器在创建besu_swarm后,自定义网络信息会同步到其他服务器中,如下所示:

root@node203:~# docker network ls
NETWORK ID          NAME                 DRIVER              SCOPE
z2w4r5fo1588        besu_swarm           overlay             swarm
f5a6b27119ef        bridge               bridge              local
e1902557eda0        docker_gwbridge      bridge              local
c5ad4fc3d434        host                 host                local
u5vjecempood        ingress              overlay             swarm
f96d226b8f69        none                 null                local
75f6834bc0cf        prometheus_default   bridge              local

网络创建后要验证子网IP是否可互相访问,为此需要下载一个busybox镜像并启动。如下所示:

docker pull busybox:latest
docker run -itd \
--name=busybox1 \
--network=besunetwork busybox:latest /bin/sh

通过docker network inspect besu_swarm能够查看到busybox1的ip地址,busybox1的ip地址为192.18.0.1。接着如法炮制,在其他服务器也以同样的方式启动busybox2、busybox3、busybox4并且查看其ip地址,下图以busybox2为例如下图所示:

显示当前busybox2的ip地址是192.18.0.3。最后通过docker exec -it $containerid sh进入到busybox容器内部,执行ping命令查看容器内部是否互通。下面以busybox1和busybox2为例,如下图所示:

例1:busybox1 ping通 busybox2

例2:busybox2 ping通 busybox1

如上图所示,双方都可以通过子网ip实现互ping,至此异地组网已完成。

相关推荐

服务器数据恢复—Raid5数据灾难不用愁,Raid5数据恢复原理了解下

Raid5数据恢复算法原理:分布式奇偶校验的独立磁盘结构(被称之为raid5)的数据恢复有一个“奇偶校验”的概念。可以简单的理解为二进制运算中的“异或运算”,通常使用的标识是xor。运算规则:若二者值...

服务器数据恢复—多次异常断电导致服务器raid不可用的数据恢复

服务器数据恢复环境&故障:由于机房多次断电导致一台服务器中raid阵列信息丢失。该阵列中存放的是文档,上层安装的是Windowsserver操作系统,没有配置ups。因为服务器异常断电重启后,rai...

服务器数据恢复-V7000存储更换磁盘数据同步失败的数据恢复案例

服务器数据恢复环境:P740+AIX+Sybase+V7000存储,存储阵列柜上共12块SAS机械硬盘(其中一块为热备盘)。服务器故障:存储阵列柜中有磁盘出现故障,工作人员发现后更换磁盘,新更换的磁盘...

「服务器数据恢复」重装系统导致XFS文件系统分区丢失的数据恢复

服务器数据恢复环境:DellPowerVault系列磁盘柜;用RAID卡创建的一组RAID5;分配一个LUN。服务器故障:在Linux系统层面对LUN进行分区,划分sdc1和sdc2两个分区。将sd...

服务器数据恢复-ESXi虚拟机被误删的数据恢复案例

服务器数据恢复环境:一台服务器安装的ESXi虚拟化系统,该虚拟化系统连接了多个LUN,其中一个LUN上运行了数台虚拟机,虚拟机安装WindowsServer操作系统。服务器故障&分析:管理员因误操作...

「服务器数据恢复」Raid5阵列两块硬盘亮黄灯掉线的数据恢复案例

服务器数据恢复环境:HPStorageWorks某型号存储;虚拟化平台为vmwareexsi;10块磁盘组成raid5(有1块热备盘)。服务器故障:raid5阵列中两块硬盘指示灯变黄掉线,无法读取...

服务器数据恢复—基于oracle数据库的SAP数据恢复案例

服务器存储数据恢复环境:某品牌服务器存储中有一组由6块SAS硬盘组建的RAID5阵列,其中有1块硬盘作为热备盘使用。上层划分若干lun,存放Oracle数据库数据。服务器存储故障&分析:该RAID5阵...

「服务器虚拟化数据恢复」Xen Server环境下数据库数据恢复案例

服务器虚拟化数据恢复环境:Dell某型号服务器;数块STAT硬盘通过raid卡组建的RAID10;XenServer服务器虚拟化系统;故障虚拟机操作系统:WindowsServer,部署Web服务...

服务器数据恢复—RAID故障导致oracle无法启动的数据恢复案例

服务器数据恢复环境:某品牌服务器中有一组由4块SAS磁盘做的RAID5磁盘阵列。该服务器操作系统为windowsserver,运行了一个单节点Oracle,数据存储为文件系统,无归档。该oracle...

服务器数据恢复—服务器磁盘阵列常见故障表现&解决方案

RAID(磁盘阵列)是一种将多块物理硬盘整合成一个虚拟存储的技术,raid模块相当于一个存储管理的中间层,上层接收并执行操作系统及文件系统的数据读写指令,下层管理数据在各个物理硬盘上的存储及读写。相对...

「服务器数据恢复」IBM某型号服务器RAID5磁盘阵列数据恢复案例

服务器数据恢复环境:IBM某型号服务器;5块SAS硬盘组成RAID5磁盘阵列;存储划分为1个LUN和3个分区:第一个分区存放windowsserver系统,第二个分区存放SQLServer数据库,...

服务器数据恢复—Zfs文件系统下误删除文件如何恢复数据?

服务器故障:一台zfs文件系统服务器,管理员误操作删除服务器上的数据。服务器数据恢复过程:1、将故障服务器所有磁盘编号后取出,硬件工程师检测所有硬盘后没有发现有磁盘存在硬件故障。以只读方式将全部磁盘做...

服务器数据恢复—Linux+raid5服务器数据恢复案例

服务器数据恢复环境:某品牌linux操作系统服务器,服务器中有4块SAS接口硬盘组建一组raid5阵列。服务器中存放的数据有数据库、办公文档、代码文件等。服务器故障&检测:服务器在运行过程中突然瘫痪,...

服务器数据恢复—Sql Server数据库数据恢复案例

服务器数据恢复环境:一台安装windowsserver操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。在windows服务器内装有SqlServer数据库。存储空间LU...

服务器数据恢复—阿里云ECS网站服务器数据恢复案例

云服务器数据恢复环境:阿里云ECS网站服务器,linux操作系统+mysql数据库。云服务器故障:在执行数据库版本更新测试时,在生产库误执行了本来应该在测试库执行的sql脚本,导致生产库部分表被tru...

取消回复欢迎 发表评论: