QOS部署方案验证测试
Closed this issue · 2 comments
xyz2020 commented
QOS部署方案验证测试
wangkuanzzu commented
服务器列表: | IP地址(外网--内网) | 节点类型 | 权益分配 |
---|---|---|---|
阿里云(自用) | 39.106.57.34 | 全节点(通信自由) | |
阿里云(自用) | 47.98.253.9 | 全节点,验证人(通信自由) | (10亿)1000000000 |
金山云 | 110.43.131.104--10.7.0.12 | 全节点-哨兵角色(可连接其他全节点,也可供外网其他节点连接) | |
金山云 | 10.7.0.8 | 全节点,验证人(通信依赖中继) | (5亿)500000000 |
金山云 | 10.7.0.9 | 全节点,中继(通信依赖哨兵) | |
金山云 | 10.7.0.19 | 全节点,哨兵角色(只能连接其他全节点,不能供外网其他节点连接) | |
金山云 | 10.7.0.13 | 全节点,哨兵角色(只能连接其他全节点,不能供外网其他节点连接) | |
公司网络 | 192.168.1.200 | 全节点,验证人(通信依赖中继) | (0.5亿)50000000 |
公司网络 | 192.168.1.201 | 全节点,中继(通信依赖哨兵) | |
公司网络 | 192.168.1.199 | 全节点,哨兵角色(连接网络中其他节点通信) | |
公司网络 | 192.168.1.184 | 全节点,哨兵角色(连接网络中其他节点通信) |
搭建vpn通信 | 一 | 二 | 三 | |||
---|---|---|---|---|---|---|
server-wkuan | server-jlgy | server-ksyun | ||||
public ipv4 | 47.98.253.9 | 39.106.57.34 | 110.43.131.104 | |||
vpn addr | 192.168.100.1 | 192.168.100.2 | 192.168.100.3 | |||
inner net addr | 172.16.177.58 | 172.17.38.137 | 10.7.0.9 | |||
daemon name | kuanserver | jlgyserver | ksyunserver | |||
vpnname | linode | linode | linode | |||
server os | centos7 | centos7 | centos7 | |||
architecture | 64-bit | 64-bit | 64-bit |
vpn的安装说明:
按照参考资料的步骤安装:https://www.linode.com/docs/networking/vpn/how-to-set-up-tinc-peer-to-peer-vpn/
监测和测试记录
对以上搭建的网络的监控和测试:(部署方案一和方案二混合搭建) | 后续完成方案三节点部署,监控和测试(部署方案一,方案二和方案三混合搭建) |
---|---|
【1】监测出块速度,正常,时间分布在5-6s | 【1】监测出块速度,正常,时间维持在5s-6s |
【2】监测各个不同角色的全节点数据,查询交易信息,验证人信息,提议信息等,包含交易的块上链后,可以在任何角色的全节点进行正常查询。 | 【2】对于在不同角色的全节点发生交易,都可以在出块时间内传播至各个验证人节点进行共识,最后上链。且在上链后,用户在各个节点对交易可进行及时且正常查询。 |
【3】对验证人角色的全节点,监测其漏块漏签情况。在正常运行中,网络稳定,未发生漏签情况。 | 【3】在没有外部障碍情形下,所有验证人正常参与共识打块,所有节点数据同步正常,不存在漏块,无法出块的情况。 |
【4】手动制造网络通信障碍,使得验证人发生漏签,后进行验证。结果如预期,验证人发生漏签情况,当恢复后,重新开始打块。 | 【4】在某一验证节点的哨兵节点全部被攻击,无法实时与主网通信。模拟哨兵被攻击:手动停止qosd进程。此时验证人可以通过第三种方案搭建的vpn进行与其他验证节点通信,不会失去与主网的通信,已经参与共识打块。 |
【5】模拟验证节点被攻击,qosd进程挂掉,当该节点权益不足三分之一时候,qos网络依旧正常运行。 | 【5】tx的传播速度:由于目前只有阿里云和金山云的机器,所以tx的传播速度很快,交易都会及时打包至block中,然后由所有验证人共识。 |
wangkuanzzu commented
方案部署#267
搭建的测试网络图: