Migrating a validator node to a new environment
Sometimes an organization needs to migrate their validator node into a new environment. Common reasons for this include:
Changing infrastructure providers (e.g. switching cloud or on-premise vendors)
Wanting to upgrade host environment configuration
Rotating access due to security procedures or policies.
If you are currently operating a validator node on Volta of the EW Chain and need to migrate it from its existing host environment to a new one, there are two options:
Install a new node and retire the existing one
This option requires provisioning a new host environment and following the installation procedures to establish an entirely new node (note: this will result in a new address, private key, EWT balance, etc.). Once your new node is installed, the current one will be removed from the network and you will be able to retire / deprecate the legacy node and host environment.
The benefits of this approach are:
It is easy to replicate the node installation process, so the overall migration is simpler;
You don't have to worry about independently modifying the installation script;
You can maintain continuity by simultaneously retiring the original node and adding the new one to the network;
The drawbacks of this approach are:
You must determine a secure way to maintain access to the legacy block rewards held on the original node address;
Depending on your organization's IT policies and procedures, it may be more complex and costly to procure multiple host environments during the migration.
You may need to replicate or modify access management policies and procedures for the new environment.
If you elect to install new node, make sure you transfer any EWT held in the original node address to a separate wallet that you can continue to access going forward, and/or maintain the private key to the original node to access old block reward balances.
Migrate your existing node to a new environment
This option involves migrating the existing node (i.e. maintaining the same address and private key) to a new host environment. To do this, you must extract the private key from the existing environment and then re-run a modified installation script in the new environment, using the private key of the validator node.
The benefits of this approach are:
You maintain continuity by keeping the same address and private key;
You don't need to operate two validator nodes (and thus host environments) simultaneously.
The drawbacks of this approach are:
Depending on the parameters of the existing vs. new environment, you may need to modify configurations and access management.
You must securely extract the private key from the existing node, temporarily store it, and import it into the new environment.
You will experience a period of "downtime" throughout the migration, during which your organization's validator node will not be operational.
As of 2023, if you select this option and you used the OpenEthereum client for your original node please note that your node will be migrated to the Nethermind client during this process due to the deprecation of the OpenEthereum client for EWC in 2022.
Follow the steps to migrate existing nodes to new node:
Migrate existing nodes: Follow the steps to migrate existing nodes to new node:
Collect and store the following necessary info from Old Instance -
You can stop containers in old instance.
docker-compose down
Value of
Validator Address
,InfluxDB Username
,InfluxDB Password
. You’ll find this info ininstall-summary.txt
file.Value of
docker-stack/keystore/.secret
To copy the .secret key to your local instance:scp -P 2222 -i YOURKEYS.pem user@YOUR_INSTANCE:/home/user/docker-stack/keystore/.secret ~/Downloads/
[optional] keep a backup of
docker-stack/
dir.
Commented out the following lines from script
[line from
180-213
] -from
echo "Creating Account..."
[line 180] tilldocker rm -f nethermind
[line 213] .Then run the script in the new instance.
The End Result would be the the following .
Validator Address
,Enode
,InfluxDB Username
andInfluxDB Password
field would be empty==== EWF Affiliate Node Install Summary ==== Company: Company_Name Validator Address: Enode: null IP Address: New_IP_ADDESSS InfluxDB Username: InfluxDB Password:
In the new Instance, There is the
docker-stack/
dir. Enter to the directory and rundocker-compose ps
and rundocker-compose down
to kill node and telemetry containers.The
.secret
file indocker-stack/keystore
dir needs to be updated with the older one. [.secret
file is in onlyreadonly
mode. Change mode before updating with old value.chmod 644 .secret
]The
.env
file indocker-stack/
dir needs to be updated.Update the
VALIDATOR_ADDRESS=
field with old value.Update the
NETHERMIND_KEY_FILE=./keystore/UTC--*
with correct name.
In the
docker-stack/configs/volta.cfg
ordocker-stack/configs/energyweb.cfg
, the following 2 value needs to be updated. In the new instance, this value would be empty. Update the value with oldValidator Address
"KeyStore": { "PasswordFiles": ["keystore/.secret"], "UnlockAccounts": ["Old Validator Address goes here..."], "BlockAuthorAccount": "Old Validator Address goes here..." },
Copy the Validator’s mining private key to your new instance
Copy the
UTC--*
file from old instance todocker-stack/keystore
dir or create that file indocker-stack/keystore/
dir with exact same name and same value. To copy the file to your local instance:scp -P 2222 -i YOURKEYS.pem user@YOUR_INSTANCE:/home/user/docker-stack/keystore/UTC_PART ~/Downloads/
[Optional] If you want a exact sync of database, you can copy db files from the old instance to the new instance -
DB Path -
docker-stack/database/volta
ordocker-stack/database/energyweb
Run
docker-compose up -d
Check logs of parity container -
docker-compose logs -f nethermind
docker-compose logs -f nethermind_telemetry
The Validator’s IP address and enode will change. Once you have completed the migration, fill out the installation summary form (for Volta here, and for Energy Web Chain here) to provide the new IP and enode information. You can also contact netops@energyweb.org to provide notification of the migration.
Last updated