Struggling to move Web Role to a smaller vmsize

Question

I want to move my web role to a smaller VM size for cost saving purposes.

I changed the vmsize attribute in WebRole in the ServiceDefinition.csdef accordingly. On publishing I received the following error:

Total requested resources are too large for the specified VM size

So I then reduced the size of the local storage resources in the ServiceDefinition.csdef. Then I got the error while publishing:

The size of local resources cannot be reduced. Affected local resource is DataFiles in role Website.

From what I have read online, I will need to delete the deployment and republish it. But this will assign a new IP to my cloud service. I can't have this happen.

Is there another solution to my problem?

Answer 1

To add on to what sharptooth said....

In your specific case you should deploy to the staging slot and then perform a VIP swap. This will leave you with your original IP address, and will put your new hosted service (with the smaller VM size) in the production slot. You can then delete your staging slot (your old service with the larger VM size).

If you can't do a VIP swap then you can deploy your updated application to a new hosted service which will result in a new IP address. You can then update whatever is dependent on the IP address (firewalls, whitelists, etc) to the new hosted service's IP address, then once everything is working correctly you can update your cname/arecord to the new hosted service and then delete the old hosted service.

However, while you can't do it for your scenario, an in-place upgrade is a better upgrade option than VIP swap whenever possible. With the VIP swap you have the potential to momentarily lose connectivity to external resources that rely on your public IP address. The issue is that outbound traffic can fail if connecting to a resource which does IP address whitelisting, which for most services effectively means that they are down.

Normally, outbound traffic (ie. a call to SQL Azure) is SNATed from the DIP to the VIP. If the resource being called (ie. SQL Azure) does IP whitelisting then this is no problem because the traffic will be coming from the VIP which is a known good IP address. During the VIP swap there is a short period of time, typically just a few seconds but in some cases can be a couple minutes or more, where the SNAT is in flux and does not happen. This means that traffic from an Azure VM appears to be coming from the DIP which will cause the connection to be blocked because the DIP IP address is not in the whitelist.