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?
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.
Related
I am testing azure right now and have some problems.
I am using new Azure portal (Resource manager). How do I add a static IP to my network and forward ports to different VM's? Then how do I add a static IP on my "Network Interface"?
I can't assign this interface to VM, because it says that only dynamic IP can be assigned, and static IP can only be assigned to load balancer. I have created load balancer, added static public IP, but then I try to add a Virtual machine and it asks me to define availability set. But I do not have availability set. So I have created Availability set, but now I cannot add virtual machine to availability set, because PowerShell cmdlet is only for classic VM's, and there is no cmdlet for resource manager VM.
So I have only two questions:
How can I add static Public IP in my Azure RM network (so that ip address newer changes) and forward ports to Azure RM VM's in my private network? Because there will be exchange server, web server and I need to forward basic ports to them.
If answer to previous question is "Load balancer", so how I can move Azure RM VM's to Availability Set? Do I have to recreate a Virtual Machine? That if there is important data?
I have been investigating some aspects of this as I move from Classic VMs (ASM) to ARM.
The documentation isn't clear or very complete, and this being Azure will probably be different in a months time. But, today....
A static public IP can only be assigned to a load balancer, not an individual VM. Search for "Reserved IP Address" in the following article where it states "Static Public IPs can only be assigned to a Load balancer right now.":
https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-azurerm-versus-azuresm/
(EDIT: Noticed that in portal.azure.com there is a switch on each public IP resource to change it from dynamic to static - though I haven't tested this).
Port forward definitely requires a load balancer. See the comments at the bottom of this article where I asked this exact question and Microsoft replied confirming this:
https://azure.microsoft.com/en-gb/documentation/articles/load-balancer-arm-powershell/
Basic VMs cannot use a load balancer today:
https://azure.microsoft.com/en-gb/pricing/details/load-balancer/
I also read somewhere (can't find the link now) that under a load balancer, there are some restrictions about which machines can be grouped together (based around sizing). From memory I think A0 to A4 could be grouped for example, then say A5 to A8 could be, but say A0 and A7 couldn't be.
The following page states "Currently with Resource Manager, you can only add a virtual machine to an availability set during its creation.":
https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-ps-create-preconfigure-windows-resource-manager-vms/
If you need an Availability Set, then you may need to delete and recreate the VM. You should be able to delete the VM but keep the VHDs, then recreate the VM with the existing VHDs so not lose data.
As well as the links above, I have also found the following helpful:
http://blogs.msdn.com/b/cloud_solution_architect/archive/2015/05/05/creating-azure-vms-with-arm-powershell-cmdlets.aspx
http://blogs.technet.com/b/parallel_universe_-_ms_tech_blog/archive/2015/11/04/deploy-a-vm-with-azure-powershell-preview-1-0-cmdlets.aspx
Hope that helps.
Chris
I published my Cloud Service from visual studio with the advanced setting Incremental Update selected. My understanding was that this would allow my service to keep the previous assigned IP address. However, after my publish my service had a new IP Address assigned to it.
Does anyone know why or what other factors may be involved? I don't think this should matter and I don't know why I got this error. While the package uploaded fine the overall deployment ended with the following message.
The deployment has timed out while waiting on the role to reach the
ready status.
I don't know that this should be a factor in the assigned IP Address though.
Any time Azure deploys a Cloud Service and provisions a new VM it can and most often will assign a new VIP (Virtual IP Address) to the Cloud Service. If you want/need the VIP to stay the same always then you will need to setup a Reserved IP for use with your Cloud Service.
I have created an Azure virtual network with a specific address space - 10.0.0.0/8. I created a subnet beneath it, 10.10.0.0/16, and added several machines to this subnet, including a PDC and a BDC, which are also acting as DNS servers.
Unfortunately, that is not exactly what I meant to do, I meant to create the address space as 10.10.0.0/16, with the intent of connecting it to some other virtual networks using S2S VPN gateways. The other virtual networks are set up using address spaces configured as: 10.x.0.0/16
To rectify the situation, based on what I could find here and on MSDN, I created a new virtual network in the same region with the correct address space (10.10.0.0/16), then deleted the VMs in the old virtual network (but left the VHDs) and recreated the VMs in the new virtual network using the old VHDs.
This seems to be working as expected. Now I am down to the domain controllers and one other machine. Will there be any issues with following the same process to move a domain controller? I realize the system GUID will be different, but was not sure if this impacts anything relative to AD and the DNS servers.
TIA for you help.
Looks like no impacts from the AD perspectives. From a DNS perspective, Azure assigned IP addresses to the machines in the order that they were restarted, so to avoid confusing DNS, I restarted the VMs in order of increasing IP address.
Needed to make sure SQL Server data volumes were attached before starting the machine, otherwise the database would show as being in a pending recovery state.
Also, apps that depend on MAC address (such as some license servers) did require new license files, as the MAC address changed.
Background. I have a service that is crawling a partners website. Their website blocks "bot like" behaviour by IP Address. They don't control their servers themselves, so they want me to change IP address of my crawler often (e.g. every minute). The crawler is currently running as an Azure Cloud Service.
So my question is. How would you programmatically change the IP address of an Azure server?
I could use a Proxy... but the site is running on SSL, so I'm not sure this is an option.
I could use a VPN connection... but I'm not sure if it's possible to programmatically dial a VPN from within a Cloud Service/VM? I'm using C#/.NET.
Finally. I tried to do a VIP Swap, which actually gives me a new IP in seconds. But unfortunately this only works when swapping form Staging to Production. I get an error when trying to swap from Production to Staging, if there is no staging running. Why is this blocked?
You cannot programmatically change a deployment's IP address, aside from shutting down the deployment (which releases the IP address) and then re-starting it (and that you can do programmatically, or through PowerShell). Also note that if you have several Virtual Machines in the same deployment, each VM will share the same public IP address.
Note that with Virtual Machines (vs. web/worker role cloud services), if you have a single Virtual Machine, you can stop the VM, then restart it, and you'll get a new IP address (ok, actually, there's no guarantee you'll get a different IP address, so more accurately you'll be assigned an IP address) while retaining the state of your VM. Shutdown and startup are not an instantaneous operatios however, and it's not going to provide you a per-minute IP address (and your VM will end up being offline shutting down or starting up pretty much all the time), so it won't satisfy your requirement.
Does Azure provide a static IP address to the web role or is it dynamically allocated each time I deploy or redeploy my application ?
Azure now supports reserving IP addresses: http://azure.microsoft.com/blog/2014/05/14/reserved-ip-addresses/
As long as you do not delete a deployment, but rather upgrade it, you will keep your "VIP" (Virtual IP address).
You also can deploy to a staging instance and "Swap VIP", which means moving your production VIP to your staging slot, and your staging VIP to your production slot. In effect, this moves your staging slot into production.
You cannot allocate an IP address permanently to a cloud service, however. They are permanent only within a deployment.
When you deploy your cloud service, the service is assigned an IP address. You can then update the deployment in several ways without losing your assigned IP address.
Take a look at this blog post which enumerates what you can do with in-place updates, while preserving your IP address.