6

I have multiple applications running on my local system. I want to make them live, I need ethereum main net node of my own. I launch the ethereum node on AWS server using supervisory mode but it doesn't work as I think. Can someone suggest the proper, safe way to launch the node with maximum throughput? And what will be the best configuration of the server required?

Thanks in advance

Improve this question

2 Answers 2

Reset to default
6

Here's what I am using:

AWS Instance Setup New EC2 instance

  • Ubuntu Server 16.04 LTS (HVM), SSD Volume Type - ami-10547475
  • t2.large: 2 vCPUs, 8GB RAM
  • 250 GB (currently about 60gb is being used)
  • nginx reverse proxy server: for ssl/https access (for my site which is https)
  • tmux for persistence
  • set up parity as a daemon process

I am using parity instead of geth. Parity syncs more quickly, is usable within a few hours. I was previously using geth, which took days and often had failures during initial sync. Parity, for me, is much more reliable. I have never had a problem setting up a new node/initial sync.

Docker resulted in delays: I also created a docker/parity node but I found that this resulted in delays. There would be a lag in connecting to the node as a web3 provider, which also interfered with event watchers that were connected to the node (i.e. events not caught; if the node fell behind and caught up, then events in the catching up were not caught by event watchers).

So far, my setup has been running pretty well, but my app does not have a massive amount of users. We are scaling within the next few months and so will be testing the limits of how many users can connect to the node fairly soon. If scalability is a problem, then I'm considering setting up multiple nodes and using a load balancer, if that ever becomes required.

Improve this answer
7
  • Do you think Amazon's new Ethereum templates are a viable option? We're also looking at hosting a Parity node for use with 0x.js, however, I'm not sure we'll get the same flexibility with the templates as we would with our own node.
    – wild_nothing
    Apr 23, 2018 at 9:03
  • How did you scalability tests go? How many Parity nodes do you have now?
    – wild_nothing
    Apr 28, 2018 at 13:36
  • @wild_nothing I haven't looked too much yet into Amazon's templates, but that's a good idea, I should look into that. So having run quite a number of nodes with both parity/geth and different providers (aws/google cloud/digital ocean), a few observations: (1) the main thing that makes nodes unreliable is losing peers/connections. With all roughly having the same parameters (min/max peers), i) geth generally has fewer peers and pretty frequently loses all, ie zero connections, ii) digital ocean nodes generally seem to always have more peers than aws, and worst is google cloud.
    – carlolm
    Apr 30, 2018 at 19:19
  • (2) having nodes that are "too close" (I created scalable, stateful sets in kubernetes) creates a problem that if your nodes keep connecting to each other, if one of them has bad information, for whatever reason, then it may bring down all of those nodes -- other peers will drop all of them (I observed this particular on Ropsten testnet, where I was mining test ether on all nodes; they all ended up on a side chain and forked, which brought down all of the nodes) (3) nodes are inherently unreliable. So it's good to have redundancies and backups.
    – carlolm
    Apr 30, 2018 at 19:19
  • As for event watching, live real-time event watching is unreliable; so the best way to handle this is by replaying events (contractInstance.getPastEvents()) over intervals. And continuing from where you left off. So keeping track of the current block when you replay, so next time you retrieve past events, you set from to the current block from the last replay.
    – carlolm
    Apr 30, 2018 at 19:19
2

My configurations and experiences:

  • Ubuntu Server 16.04 LTS (HVM), SSD Volume Type.
  • Absolutely must have 8+ gb of RAM. Don't go any less or you'll run into strange problems.
  • The m5.large works well. Use a Fixed Performance Instance (e.g. M5, C5, and R5), and do not use a Burst Performance Instance (T2.* or T3.*). Because if your instance runs out of burst it'll be super slow. I've had this happen to other applications and it wrecks them and is very hard to detect what's causing the periodic slowness. Nodes don't use a ton of CPU so it may not be a big deal, but if you're relying on it for production software then make sure to remove that possibility for a whopping $2.30 more per month (t2.large compared to m5.large)
  • EBS General Purpose SSD (gp2) is very cost effective. You're paying per month for storage, so no need to allocate hundreds of GB of SSD space if you are using parity with pruning set to fast. You can always increase the size of your volume but you cannot conveniently decrease it. My parity nodes don't even break the 40 GB mark at the moment. If you're using archive mode, then you will need hundreds of GB.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.