Physical setup and infrastructure scenarios

Question

Can anyone offer advice on blockchain architectures and operations?

Some of these may sound odd, but I think it would be good to know if anyone has attempted architectures and to what success! Even if you know one of these scenarios is a really bad idea or you have tried one of these and have a view, please comment and share experience.

• Mapped Drive? to hdd on same server
• Mapped Drive? to hdd on different server
• Mapped Drive? to folder on same hdd (benefits unknown)
• Dropbox or other cloud sync storage?
• Scenarios where disk space is full and a copy upgrade is required
• Website(Explorer) and RPC-Node on same server
• Website(Explorer) connecting to RPC-Node on other server
• Website(Explorer) connecting to different JSON-RPC on different nodes for different kinds of transactions.
• Architectural Layers and Queues between your application API and MultiChain RPC-API
• Other

 

 

Answer 1

I tried creating a chain on a mapped drive using https://tntdrive.com/

The idea was to connect to an S3 Bucket and specify the datadir to the mapped drive. This would allow 16GB of storage immediately and would facilitate an easier experience for our operations team (everything uses S3 from CI to database backups).

Tntdrive unfortunately caused multichain to slow down considerably..
TntDrive is overzealous in accessing the files, in an attempt to sync with S3 as fast as possible.

There were also a few times where tntdrive would lock a file while syncing which crashed multichain.

One error when starting up

MultiChain Core Daemon build 1.0 beta 2 protocol 10008

: Corrupted block database detected.

Please restart multichaind with reindex=1.

I also received an error when it could not rename a file.

and

connecting my second node created a runtime error. I tried to reproduce it, but failed to.

All errors are not multichain per se, but was from attempting to access files that were unexpectedly locked.

REMEDY? Does MultiChain check whether it can access a locked file? Would it be a terrible idea not to assume that it owns the files? Perhaps on rename it can retry on error?

Overall, I wont recommend tntdrive and multichain with S3 without some more investigation and strategy for avoid file lock problems.

 

 

 

 

 

Answer 2

We recommend having MultiChain's files on a locally-connected drive to the server on which it is running, because it is designed around rapid access to its own files.

The Explorer also has to run on a computer with local access to the blockchain files, because it doesn't only use the MultiChain API to retrieve data.

Anything else connecting to the MultiChain API can run wherever you like, based on the usual considerations of bandwidth and latency for the API calls.

If you need to take the node down and move it to another server (e.g. because of disk space requirements), that's a fairly easy process. All on-chain permissioning in MultiChain is via blockchain addresses rather than IP addresses, so it's easy to re-attach the node to its peers from another IP address.

There are a few reasons why you might want to implement an API queue between your application and MultiChain's endpoint. First, if you expect to have periods of very high activity (we're talking high 100s or 1000s of initiated transactions per second), where the node can't keep up, or transactions are not being validated fast enough. Second, for failover, if you want to run multiple MultiChain nodes on different servers with shared private keys, and automatically re-route API calls if a node server fails. Third, if you are concerned about durability, i.e. that every state change sent to MultiChain is preserved even if the node goes down immediately afterwards. Some things (in-memory unconfirmed transactions that weren't yet sent to peers, locked state of wallet outputs, changes to runtime parameters made via the API) are not currently persisted between runs of the MultiChain process.