The Best Deployment Practice of EOS BP Nodes(超级节点部署最佳实践)

in #eos6 years ago (edited)

Today I want to share with you the bp node cluster deployment. This is a good practice that I can think of, which can effectively avoid the DDoS attack, if you have a better idea, please leave a message below.  

今天和大家分享超级节点集群部署。这是我能想到的很好的方案,可以有效的避开DDoS攻击,如果您有更好的想法,欢迎在下面留言。 

Figure-1

Figure-2


As shown above, we have prepared a master BP node and two backup BP nodes. We (EOS Store) actually choose AWS to deploy these nodes, the master BP node and the backup BP node 1 are located in Tokyo, Japan, and the master BP node and the backup BP node 1 are located in different failure areas in Tokyo, and backup BP node 2 is located in Singapore.   

The IP of the green full node in the graph is needed to be exposed to other BP so that other BP can be connected, and the IP of these nodes is easily leaked to the hacker, so it is very easy to be attacked, but in this network structure, even if the green full node is attacked and down, it will not affect the normal operation of the BP node.       

The full node and BP node configuration files (config.ini) should be added as many "p2p-peer-address = ip:port" as possible.   For example, achieve 20, and try to connect each node to a number of different IPs. In this way, four full nodes and two BP nodes share a total of about 120 (20*6) IPs, which is already a relatively large number of connections. Even if two green full nodes is attacked, the entire cluster will still maintain 80 (20*4) connections. This structure is very solid.   

Most importantly, BP node (master BP node and backup BP nodes) and the blue nodes in the graph have no public net IP, all BP nodes and blue nodes communicate directly with the public network IP provided by other BP. I have tested that BP nodes can still produce block without public net IP, so that hackers can't attack BP nodes and blue full nodes.     

 You can also add or reduce the blue or green full node in the picture according to your situation. The simplest way is that you can have only one green full node and one BP node.    

 The P2P port of a green node can use 80 ports, or other well-known ports, not 9871 ports, hidden in well-known ports can make it difficult for hackers to find the IPs of the node.   

A reverse proxy is added to the API node to limit the flow to ensure the security of the back end full nodes. 

In addition, the configuration item of "p2p-peer-address =" in config.ini is not related to the configuration item "max-client = 25", the former is set by the node's active connection to other nodes, and the latter only restricts the number of connections from the external node. These two parameters are not related to each other.  


  如上图所示,我们准备了一个主BP节点和两个备用BP节点。我们(EOS Store)实际会选择AWS在日本和新加坡的云部署这些节点,主BP节点和备BP节点1位于日本东京,并且主BP节点和备BP节点1位于东京不同的失效区,备BP节点2位于新加坡。   图中绿色full node的ip是需要对其他BP公开的,好让其他BP进行p2p连接,这些节点的ip也很容易被泄漏给黑客,因此非常容易被攻击,但在这个网络结构里面,即使绿色的full node被攻击而宕机,也不会影响BP节点正常运行。   

图中full node和BP node的配置文件(config.ini)中应添加尽可能多的“p2p-peer-address = ip:port”,比如达到20个,并且尽量让每个节点连接多个不同的ip。这样,四个full node 和两个BP node总共和外界约120(20*6)个ip保持连接,已经是比较大的连接数量。就算两个绿色的full node被攻击,整个集群依然保持80(20*4)个连接。这样的结构是非常稳固的。

最最关键的是,任何BP节点(主BP和备BP节点)和图中的蓝色节点都没有公网ip,所有的BP节点和蓝色节点直接和其他BP提供的ip通信,我已经测试过,BP节点在没有公网ip的情况下依然可以正常出块,这样就让黑客无法攻击BP节点,也无法攻击蓝色节点。   也可以根据你的情况,增加或减少图中蓝色或绿色的full node。最简单的模式是,你可以只有一个绿色full node和一个BP node。   绿色节点的p2p端口可以使用80端口,或其他知名端口,而不是9871端口,隐蔽在常用的端口当中会让黑客很难发现节点的ip。   

为api节点增加反向代理,进行限流,以保证后端节点的安全。

另:在config.ini中“p2p-peer-address = ” 整个配置项和“max-client = 25”整个配置项是不相关的,前者设置的是本节点主动连接其他节点的连接数,后者仅仅限制的是外部节点主动连接本节点的连接数。这两个参数并没有关系。

Supported by EOS Store


Coin Marketplace

STEEM 0.16
TRX 0.15
JST 0.028
BTC 56586.95
ETH 2389.49
USDT 1.00
SBD 2.34