Mention monitoring and updating for exchanges (#12953)
* Mention monitoring and updating for exchanges * Fix link syntax... * Apply suggestions from code review Co-authored-by: Tyera Eulberg <teulberg@gmail.com> Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com> * Apply suggestions from code review Co-authored-by: Tyera Eulberg <teulberg@gmail.com> * More review comments and word-wrapping Co-authored-by: Tyera Eulberg <teulberg@gmail.com> Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
This commit is contained in:
Ryo Onodera
GitHub
parent
4451042c76
commit
87311cce7f
|
|
@ -7,9 +7,19 @@ exchange.
|
|||
|
||||
## Node Setup
|
||||
|
||||
We highly recommend setting up at least two of your own Solana api nodes to
|
||||
give you a trusted entrypoint to the network, allow you full control over how
|
||||
much data is retained, and ensure you do not miss any data if one node fails.
|
||||
We highly recommend setting up at least two nodes on high-grade computers/cloud
|
||||
instances, upgrading to newer versions promptly, and keeping an eye on service
|
||||
operations with a bundled monitoring tool.
|
||||
|
||||
This setup enables you:
|
||||
- to have a trusted gateway to the Solana mainnet-beta cluster to get data and
|
||||
submit withdrawal transactions
|
||||
- to have full control over how much historical block data is retained
|
||||
- to maintain your service availability even if one node fails
|
||||
|
||||
Solana nodes demand relatively high computing power to handle our fast blocks
|
||||
and high TPS. For specific requirements, please see
|
||||
[hardware recommendations](../running-validator/validator-reqs.md).
|
||||
|
||||
To run an api node:
|
||||
|
||||
|
|
@ -43,12 +53,37 @@ Optional parameters to consider:
|
|||
- `--private-rpc` prevents your RPC port from being published for use by other nodes
|
||||
- `--rpc-bind-address` allows you to specify a different IP address to bind the RPC port
|
||||
|
||||
### Automatic Restarts
|
||||
### Automatic Restarts and Monitoring
|
||||
|
||||
We recommend configuring each of your nodes to restart automatically on exit, to
|
||||
ensure you miss as little data as possible. Running the solana software as a
|
||||
systemd service is one great option.
|
||||
|
||||
For monitoring, we provide
|
||||
[`solana-watchtower`](https://github.com/solana-labs/solana/blob/master/watchtower/README.md),
|
||||
which can monitor your validator and detect with the `solana-validator` process
|
||||
is unhealthy. It can directly be configured to alert you via Slack, Telegram,
|
||||
Discord, or Twillio. For details, run `solana-watchtower --help`.
|
||||
|
||||
```bash
|
||||
solana-watchtower --validator-identity <YOUR VALIDATOR IDENTITY>
|
||||
```
|
||||
|
||||
#### New Software Release Announcements
|
||||
|
||||
We release new software frequently (around 1 release / week).
|
||||
Sometimes newer versions include incompatible protocol changes, which
|
||||
necessitate timely software update to avoid errors in processing blocks.
|
||||
|
||||
Our official release announcements for all kinds of releases (normal and
|
||||
security) are communicated via a discord channel called
|
||||
[`#mb-announcement`](https://discord.com/channels/428295358100013066/669406841830244375)
|
||||
(`mb` stands for `mainnet-beta`).
|
||||
|
||||
Like staked validators, we expect any exchange-operated validators to be updated
|
||||
at your earliest convenience within a business day or two after a normal release
|
||||
announcement. For security-related releases, more urgent action may be needed.
|
||||
|
||||
### Ledger Continuity
|
||||
|
||||
By default, each of your nodes will boot from a snapshot provided by one of your
|
||||
|
|
|
|||
|
|
@ -32,6 +32,33 @@ Here are our recommendations for low, medium, and high end machine specification
|
|||
| Accounts Drive\(s\) | None | Samsung 970 Pro 1TB | 2x Samsung 970 Pro 1TB | |
|
||||
| GPU | Nvidia 1660ti | Nvidia 2080 Ti | 2x Nvidia 2080 Ti | Any number of cuda-capable GPUs are supported on Linux platforms. |
|
||||
|
||||
## Virtual machines on Cloud Platforms
|
||||
|
||||
While you can run a validator on a cloud computing platform, it may not
|
||||
be cost-efficient over the long term.
|
||||
|
||||
However, it may be convenient to run non-voting api nodes on VM instances for
|
||||
your own internal usage. This use case includes exchanges and services built on
|
||||
Solana.
|
||||
|
||||
In fact, the offical mainnet-beta API nodes are currently (Oct. 2020) run on GCE
|
||||
`n1-standard-32` (32 vCPUs, 120 GB memory) instances with 2048 GB SSD for
|
||||
operational convenience.
|
||||
|
||||
For other cloud platforms, select instance types with similar specs.
|
||||
|
||||
Also note that egress internet traffic usage may turn out to be high,
|
||||
especially for the case of running staked validators.
|
||||
|
||||
## Docker
|
||||
|
||||
Running validator for live clusters (including mainnet-beta) inside Docker is
|
||||
not recommended and generally not supported. This is due to concerns of general
|
||||
docker's containerzation overhead and resultant performance degradation unless
|
||||
specially configured.
|
||||
|
||||
We use docker only for development purpose.
|
||||
|
||||
## Software
|
||||
|
||||
- We build and run on Ubuntu 18.04. Some users have had trouble when running on Ubuntu 16.04
|
||||
|
|
|
|||
Loading…
Reference in New Issue