This runbook explains how to take a new set of virtual machines (VMs) running upgraded software for one of our endpoints, deploy them to the endpoint, then remove the existing set of virtual machines running outdated software from our endpoints...ideally with zero downtime for our customers.
Contents
|
This runbook is based on several assumptions that must be met.
- This upgrade has been approved by all relevant stakeholders.
- You have an Amazon Web Services (AWS) IAM user account with the necessary permissions to perform the upgrade(s) in the
evm-testnet
and/orevm-mainnet
AWS accounts. - The new virtual machine(s):
- Are in the correct availability zones (AZs),
- Have been initialized with upgraded software,
- Are prepared to pass health checks if they are functioning correctly, and;
- Will fail health checks if they are not functioning correctly.
Here are the steps to take a new set of virtual machines (VMs) running upgraded software for one of our endpoints, deploy them to the endpoint, then remove the existing set of virtual machines running outdated software from our endpoints...ideally with zero downtime for our customers.
- Login to the AWS web console.
- Switch to the intended region in AWS.
- Perform all smoke tests on the existing endpoint to verify everything is working before making any changes.
- To guarantee your traffic is being served from these endpoints, use a public virtual private network (VPN) to connect to this part of the world for the smoke tests. After the smoke tests, you can disconnect.
- Perform all relevant smoke tests on each and every individual virtual machine to verify the new virtual machines are working as expected.
- EC2 > Target Groups >
${TARGET_GROUP_NAME}
> Targets > Register targets- For example, if you are upgrading the testnet RPC API in the Asia-Pacific datacenter,
${TARGET_GROUP_NAME}
might beevm-testnet-ap-api-tg
.
- For example, if you are upgrading the testnet RPC API in the Asia-Pacific datacenter,
- Under "Available instances," check the instances with the upgraded software.
- Following the previous example,
evm-testnet-ap-api-vm-1-v0.4.1
andevm-testnet-ap-api-vm-2-v0.4.1
.
- Following the previous example,
- Click "Include as pending below."
- Verify the upgraded virtual machines (VMs) appear in "Review targets," then click "Register pending targets."
- The "Health status" column of the new instances will be "initial."
Wait for the "Health status" column of the new instances to change from "initial" to "healthy."
- This took about one minute for me.
- If the health status changes to "unhealthy," or anything besides "healthy," stop here and escalate the situation! We need to investigate further.
- Under "Registered targets," check the VMs that are running the outdated software.
- Click "Deregister."
- The "Health status" column of the old instances will be "draining."
Wait until these old instances disappear.
- This took a long time for me, maybe ten minutes.
- This process is where AWS verifies no traffic is being routed to these instances before removing them.
- Perform a smoke test on the public endpoint to verify everything is working.
- To guarantee your traffic is being served from these endpoints, use a public virtual private network (VPN) to connect to this part of the world for the smoke test. After the smoke test, you can disconnect.
Repeat this process for the other regions.
You may want to leave the outdated virtual machines (VMs) up for 12-24 hours in case there is an issue with the upgrade and you need to rollback. The process to rollback is the same as the upgrade process, where the VMs running the previous version are added and the VMs running the current version are removed. After a sufficient amount of time with no reported issues using the upgraded software, the VMs running outdated software should be terminated to minimize costs.
- EOS-EVM Cloud Infrastructure
- eos-evm - core EOS Ethereum virtual machine source code
- Runbooks