Zero Downtime Upgrade for an application in Microsoft Azure. Part 2: IaaS
Last time, we looked at Zero Downtime Upgrade methods that can be applied as part of the PaaS deployment option for the Microsoft Azure application. Today, we will focus on methods that can be applied not only to cloud services, but to ordinary virtual machines as part of an IaaS deployment.
As we know, any virtual machine that discusses requests to your application does this through a specific open port (for example, 80, 8080, 443, etc.). If there are multiple virtual machines, Microsoft Azure’s internal load balancer distributes traffic between these virtual machines. Let's think about how you can use this feature for Zero Downtime Upgrade.
Imagine that we have several virtual machines within a single cloud service. Let me remind you that the internal load balancer redistributes traffic only within a single DNS, that is, within a single cloud service.
')
Let these virtual machines use version 1.0 of our application. The task, as always, is to update the application to version 1.1 imperceptibly for the user.
The Load Balanced Endpoint approach offers the following mechanism: you deploy additional virtual machines within an existing cloud service using the same ports and configuration as the original version. The easiest way to do this is by scaling. Suppose there were 2 cars, it became 4. It will also avoid the drawdown of the application performance during the update.
After that, one after another, you update the version of the application on virtual machines within the cloud service. Naturally, to avoid redirecting traffic to a virtual machine that is currently being updated, we must disable the corresponding port for it. After that, the internal load balancer begins to redistribute traffic between the old and new versions of the application.
You can update all virtual machines, and you can update, let's say, 2 of 4, and then just delete unnecessary ones with the old version of the application. Suppose again using scaling down.
Let's now look at the pros and cons of this approach.
Pros:
Minuses:
As we see this method is almost a tracing with the Fault / Update domains that Microsoft uses to provide 99.95% SLA for several virtual machines as part of cloud services or availability set. The only difference is that the update mechanism must be done manually or automated using Microsoft Azure Automation for example.
So this update mechanism is quite applicable in practice for applications deployed within IaaS.
All previous methods that we considered suitable for use only in the framework of one approach to the deployment of the application. However, a logical question arises. Is there really no such tool that could be used in both PaaS and IaaS deployments?
This service really is and it is called - Traffic Manager. While it’s not possible to configure an internal load balancer for a specific cloud service, Traffic Manager provides the ability to configure traffic distribution.
You can distribute traffic not only between different virtual machines, but also cloud services, as well as determine the algorithm by which this traffic will be distributed.
So, in order to implement the Zero Downtime Upgrade script when using Traffic Manager, we need to send user traffic not to the DNS of a specific cloud service, but to the DNS, which is determined when creating the Traffic Manager profile. It will look like {name} .trafficmanager.net. Naturally, if necessary, it can be tied to the desired CNAME registrar of names.
Suppose version 1.0 of our application is hosted within the cloud service prod.cloudapp.net. For the new version, we are creating a separate cloud service. Let's say stage.cloudapp.net. After deploying a new version of the application, we can redirect traffic from the old version of the application to the new one.
Accordingly, as soon as all traffic has gone to the new version of the application, the old environment can be deleted.
Let's now look at the pros and cons of this approach.
Pros:
Minuses:
The described service has several rather serious advantages over all described earlier. Its use in the production environment is fully justified, but you need to remember about the additional costs when using it.
This is all I wanted to tell you about the Zero Downtime Upgrade mechanisms that can be applied on the Microsoft Azure platform. It is possible that I missed something. Subscribe in the comments about this!
Thank you all for your attention!
Load Balanced Endpoint
As we know, any virtual machine that discusses requests to your application does this through a specific open port (for example, 80, 8080, 443, etc.). If there are multiple virtual machines, Microsoft Azure’s internal load balancer distributes traffic between these virtual machines. Let's think about how you can use this feature for Zero Downtime Upgrade.
Imagine that we have several virtual machines within a single cloud service. Let me remind you that the internal load balancer redistributes traffic only within a single DNS, that is, within a single cloud service.
')
Let these virtual machines use version 1.0 of our application. The task, as always, is to update the application to version 1.1 imperceptibly for the user.
The Load Balanced Endpoint approach offers the following mechanism: you deploy additional virtual machines within an existing cloud service using the same ports and configuration as the original version. The easiest way to do this is by scaling. Suppose there were 2 cars, it became 4. It will also avoid the drawdown of the application performance during the update.
After that, one after another, you update the version of the application on virtual machines within the cloud service. Naturally, to avoid redirecting traffic to a virtual machine that is currently being updated, we must disable the corresponding port for it. After that, the internal load balancer begins to redistribute traffic between the old and new versions of the application.
You can update all virtual machines, and you can update, let's say, 2 of 4, and then just delete unnecessary ones with the old version of the application. Suppose again using scaling down.
Let's now look at the pros and cons of this approach.
Pros:
- Simple scaling process
- Support IaaS deployment
- No performance drawdown during application update
- Additional financial costs are needed only at the time of the update.
Minuses:
- The update process is completely manual or requires automation.
- Additional costs in the update process
- The configuration of the virtual machines of the old and the new version must match
- Updating an application within a PaaS deployment is not supported.
As we see this method is almost a tracing with the Fault / Update domains that Microsoft uses to provide 99.95% SLA for several virtual machines as part of cloud services or availability set. The only difference is that the update mechanism must be done manually or automated using Microsoft Azure Automation for example.
So this update mechanism is quite applicable in practice for applications deployed within IaaS.
Traffic manager
All previous methods that we considered suitable for use only in the framework of one approach to the deployment of the application. However, a logical question arises. Is there really no such tool that could be used in both PaaS and IaaS deployments?
This service really is and it is called - Traffic Manager. While it’s not possible to configure an internal load balancer for a specific cloud service, Traffic Manager provides the ability to configure traffic distribution.
You can distribute traffic not only between different virtual machines, but also cloud services, as well as determine the algorithm by which this traffic will be distributed.
So, in order to implement the Zero Downtime Upgrade script when using Traffic Manager, we need to send user traffic not to the DNS of a specific cloud service, but to the DNS, which is determined when creating the Traffic Manager profile. It will look like {name} .trafficmanager.net. Naturally, if necessary, it can be tied to the desired CNAME registrar of names.
Suppose version 1.0 of our application is hosted within the cloud service prod.cloudapp.net. For the new version, we are creating a separate cloud service. Let's say stage.cloudapp.net. After deploying a new version of the application, we can redirect traffic from the old version of the application to the new one.
Accordingly, as soon as all traffic has gone to the new version of the application, the old environment can be deleted.
Let's now look at the pros and cons of this approach.
Pros:
- Isolated Test Environment
- Support for virtual machines, cloud services, and Microsoft Azure websites
- The configuration of the virtual machines of the new and old version of the application may differ
- If necessary, there is an opportunity to “return everything back”
Minuses:
- Additional costs for Traffic Manager service
- Additional costs in the update process
- The update process is completely manual or requires automation.
- DNS Name Cache DNS Update takes time
The described service has several rather serious advantages over all described earlier. Its use in the production environment is fully justified, but you need to remember about the additional costs when using it.
This is all I wanted to tell you about the Zero Downtime Upgrade mechanisms that can be applied on the Microsoft Azure platform. It is possible that I missed something. Subscribe in the comments about this!
Thank you all for your attention!
Source: https://habr.com/ru/post/226763/
All Articles