Last Friday I talked about how you could reserve and manipulate cloud service VIPs. In this post I’m going to show you how to “upgrade” a service by moving to a new installation of that service running in a new cloud service – this can be done by moving the VIP of the original cloud service to the new cloud service.
Have you wondered how you will upgrade your WS2012 R2 VMs to WS2016 in Azure? The answer is that you won’t. You will have to migrate services to new VMs. Here’s a way to do that migration. This process will keep the original installation running while the new service is being built. Once ready, the VIP (the public IP of the original service) is migrated to the newer cloud service. If all goes well, you remove the old cloud service. If all sucks, you migrate the VIP back to the original cloud service.
In my lab I have two cloud services:
- OldWeb: This runs a WS2012 R2 VM with IIS
- NewWeb2016: This runs a WS2016 VM with IIS
Let’s say I have a site called http://www.joeelway.com. The A records for joeelway.com and http://www.joeelway.com will point to this VIP of the OldWeb cloud service; this is what allows a browser to connect to that site. If I don’t have a reserved VIP then I can create one easily enough with:
New-AzureReservedIP -ReservedIPName "WebsiteVIP" -Location "North Europe" -ServiceName "OldWeb"
This will reserve the existing IPv4 address that is used by OldWeb with the cloud service. This is a non-disruptive change that simply fixes the existing IP address with the cloud service. I can continue to browse to the website using the same VIP as when it was dynamic.
Now I can build up a new web application using the NewWeb2016 cloud service. This has zero impact on the OldWeb cloud service, running side-by-side but using a different (probably dynamic) VIP:
The A records for the joeelway.com domain continue to point at the reserved VIP for OldWeb, so users are still going to the old service.
And then we plan a switchover, with all of the necessary data copy/replication/synchronisation, change controls, reviews, communications, etc. How do I make the change? It’s simple; we run two cmdlets to change the reserved IP association.
The first cmdlet will remove the association of the reserved VIP from the OldWeb cloud service. This forces the old service to get a new dynamic VIP:
Remove-AzureReservedIPAssociation -ReservedIPName "WebsiteVIP" -ServiceName “OldWeb”
This cmdlet takes a few minutes to run so plan for the associated outage that will be caused. The A records for the joeelway.com domain continue to point at the reserved VIP, which is no longer associated with a service. If you browse to the VIP the connection will time out:
We want to avoid such a time out experience for the site’s users so we will very quickly associate the VIP with the new cloud service to minimise downtime (scripting is perfect for this!):
Set-AzureReservedIPAssociation -ReservedIPName "WebsiteVIP" -ServiceName "NewWeb2016"
The A records continue to resolve to the reserved VIP, and now the VIP is associated to the new cloud service:
If all goes well, you can decommission the old cloud service (VMs, etc), but you can leave them running for a little while as a rollback plan:
- Remove the VIP association from the new cloud service
- Set the VIP association with the old cloud service
You have to admit that, even if you are a PowerShell hater, this is a nice way to switch clients to a new version of a service.