Rolling with additional batches it is a deployment strategy used when available servers can not respond to incoming traffic because of high load while other servers are updated during deployment. The solution is to create an additional number of servers available only during deployment process, those servers being in charge of processing incoming traffic and will be removed after deployment. This way, there will be no downtime during deployment and all traffic will be handled as expected.
To review some of load balancer concepts please visit this page.
How it works
Let’s consider this as our initial phase:
In our example we are using a load balancer with 3 servers. Let’s consider the additional batch number 2 (2 servers will be created for deployment)
Step 1 is to create another 2 servers with the same code version as the other ones, available in load balancer. This is called extra provisioning.
Step 2 is to remove 2 servers (the additional batch size) from load balancer taking into account the connection draining. So it will wait until all requests are processed and only after this they will be removed. A connection draining timeout can be used in order to wait a maximum of time after which the server is removed automatically
Step 3: Update software on the servers disconnected from load balancer.
Step 4: Reconnect servers to load balancer after deployment is complete
Step 5: wait for connection draining, be it for one server or a batch number of servers less or equal to the additional batch size. After this, the server will be removed from load balancer.
Step 6: Update server with new software
Step 7: Reconnect server to load balancer
Step 8 Wait for connection draining for additional servers, then remove them from load balancer
Step 9 Destroy additional servers
When should you use this method:
This is good alternative for rolling deployment strategy with the advantage of keeping the same capacity to handle all incoming transactions.
Also, it can be used when you need fast discovery of system fails with new software installed.
- Both versions of software will run in production at the same time.
- Ensure backwards compatibility for all shared resources between old software and new software (databases, cache etc.).
- Creating and removing new servers and resources may introduce some new costs.
- Fast detection of errors which implies executing rapid disaster-recovery procedure or rollback.
- The same amount of servers handles the traffic, so there is no downtime.
- The rollback can be done similarly, one batch at a time.
- Monitoring, logs and health check are an essential part of the deployment as we can see how the new software behaves right after fist batch update. If something went wrong, then all we have to do is to update those servers with the old version of software.
<a href=”https://www.bunnyshell.com/site-reliability-robot/” id=”check-out-srr-image”><img class=”alignnone wp-image-5107 size-medium” src=”https://www.bunnyshell.com/wp-content/uploads/2019/12/check-out-our-site-reliability-robot-300×55.png” alt=”check out our site reliability robot” width=”300″ height=”55″ /></a> <a href=”https://www.bunnyshell.com/devops/” id=”check-out-srr-image”><img class=”alignnone wp-image-5109 size-medium” src=”https://www.bunnyshell.com/wp-content/uploads/2019/12/check-out-our-devops-automation-platform-300×54.png” alt=”check out our devops automation platform” width=”300″ height=”54″ /></a>