It's pretty easy to do autoscaling with Azure web apps, and there's something called Virtual Machine Scale Sets (but that's still in beta and not working properly yet), so I'm wondering: how can we do autoscaling using normale Azure VMs?
1) I was thinking we could create a load balancer, availability set and VMs, pre-provision them and turn some off. But aside from using the API to build a DIY scaler: how can I automatically turn on more machines if the current set exceeds a certain threshold? Does Azure offer anything for this? How do big companies that use Azure handle this?
2) How can I make sure that the machines are all consistent and have the latest version of our software installed on it? Even if the machine has been offline for months?
Well, those are 2 separate questions. Nonetheless:
You can use VM Scale Sets to do that. Here's a nice compilation of resources
VM Scale sets can kinda achieve that, but not exactly. If the VM was offline nothing can configure it (at least in Azure). You can use Powershell DSC\Ansible\Chef\whatever to configure VM once it comes up. If you are using plain VM Scale Sets you would need to upgrade VM before bringing it up.
Related
i am a newbie and am planning to host iis server for my client in azure with auto-scale functionality.
we will test modules and update once in a week in iis server, my question is how to sync the files between vms while on auto-scaling and if we can use auto-scale only for identicals vms, then please suggest me the solution for this scenario. we will start min 2 max 10 vms in auto-scale.
Regards,
Kumar B
I first would ask why a VM, things do get more complicated using VMs. Scale Set would help support this however you still will have issues when you want to deploy new code. You said IIS so I am presuming Windows. Desired State Configuration is a great choice you can make a PowerShell script that will "configure" your VM for you, and potentially pull in any code updates. This is also where things like chef/puppet/salt can come into play to ensure the server is configured.
You could look at creating a custom image that every time you deploy new code gets baked into the image. Then you are basically doing a rolling update where you spin up a new server and then destroy one until they all have been updated. Technically this could be done, either way, just if they are baked into the image you would have a quicker start time.
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app
https://adamtheautomator.com/azure-vm-scale-sets-powershell/
Automatic - VMs may be rebooted in a random order even taking all VMs temporarily down at the same time.
Rolling - The scale set deploys updates to instances in batches with an optional pause time between batches.
Manual - Nothing happens to existing VMs when an update is initiated.
What files are you trying to sync if they are not code files, Azure Files would be a great fit as that supports SMB or you could just use cloud storage.
You can deploy your application to a virtual machine scale set using desired state configuration. See: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app
Not what you asked, but you should consider why you are hosting your app in IIS on VMs. If you are using Azure, then Azure App Service may be a better fit. See: https://learn.microsoft.com/en-us/azure/app-service/
I have a two websites on a VM with WHM/cPanel and MySql.
I am looking to move this into Azure and use vertical scaling. Visits to the website are usually stable but three or four times a year there is a big increase in traffic which historically has caused big problems for the existing host.
I am looking to move it into the A5-A7 range of servers for the vertical scaling.
I cannot find anything anywhere about whether there is any downtime involved when Azure scales up my VM from A5 to A6 or whatever.
Does anyone have any experience with this and can give me a definitive answer as to whether there is downtime when using vertical scaling, and if there is any downtime involved then the kind of downtime I would expect
Thank you for your time.
Yes, it will incur downtime. Post on it
Azure will restart your VM.
Quote from the page (I highlighted the important bit):
When considering the ability to resize virtual machines there are
three key concepts that will impact how simple it is to change the
size of your VM.
The region in which your VM is deployed. Different VM sizes require different physical hardware. In some instances, an Azure region may
not contain the hardware required to support the desired VM size. All
Azure regions support the VM sizes Standard_A0 – A7 and Basic_A0 – A4.
You can then find which other VM sizes are supported in each region
under the Services tab of the Azure Regions web page.
The physical hardware currently hosting your VM. If the physical hardware currently running your virtual machine also supports your
desired new size, then it is very easy to change the VM size through a
simple size change operation which results in a VM reboot.
The deployment model used for the VM. The two deployment models are Classic and Resource Manager. The Resource Manager model is the newer
model, and it supports some ease of use functionality not available in
the classic deployment model.
How to autoscale virtual machines(IaaS approach) in azure instead of web/worker role autoscaling in azure?
You can now Autoscale Virtual machines in Azure directly in the Azure Management Portal. ScottGu has a post about it on his blog.
The important thing to autoscale VM's is you must proactively provision the Max # of VM's you think you'll need to handle your peak capacity, and add them to the same availability set.
For example, if on the busiest day of the week it takes 6 machines to handle all of your traffic, then you need to create 6 instances and install your application on it, configure it to handle traffic etc.... and then add it to an availability set with the other 5 machines.
Once you've done this, you can navigate to the Cloud Service that contains all of your virtual machines and click on the Scale tab. You should see a list of your availability sets, and it should tell you the # of machines you can scale over. Choose a metric (either CPU or Queue today), and then range of machines you want to scale between. You can scale between 1 and the total # of machines.
When load is low -- Azure will turn off machines (so you don't have to pay for them), and when load is high, Azure will turn those machines back on.
Auto-scaling on the IaaS level doesn't really make sense. Even if azure could detect high CPU usage and start a new VM based on it, what then? you still need to install your application on that VM automatically somehow.
What you are looking for is something that runs your app on azure, and installs new instances on new VM's if necessary. That "something" is called PaaS enabler. Basically it is another abstraction level between your app and the azure IaaS.
there are a couple of them out there :
Cloudify, CloudFoundary, Juju
as far as i know, only one that supports Azure is Cloudify. you can check out how to configure azure using Cloudify here : Configuring Azure
you can also check out the community - Cloudify Forum, or post questions here for assistance.
Disclaimer: I work for Gigaspaces, developing the Cloudify product line.
According to this it's possible to scale out IaaS with Availability sets by pre-provisioning the number of boxes: https://blogs.msdn.microsoft.com/kaevans/2015/02/20/autoscaling-azurevirtual-machines/
Looking into it I came to find out that a 1 role of 1 small compute Cloud Service is almost 60% more expensive as the same 1 small "vitual machine"...
So why should i choose to use cloud service over virtual machine?
Searching the web I came across a lot articles about this including this article but none were clear enough for me... the comparison in the last one is plain useless in my opnion...
Is there a "perk" that i don't know about or is not being considered? something to justify the "extra-charge" for cloud service... Does a code running on cloud service perform better than running on a virtual machine (maybe because there's less overhead)? anything?
I think virtual machine would be used when we need to migrate our application to the cloud and make it 'just work'. We don't need many additional effort to move our legacy code to azure if using virtual machine. But it doesn't provide the rich PaaS features comparing with cloud service such as automatically deployment, automatically update, load balance, etc.
So if we have a legacy system and we wanted to quick move to azure, then we can choose virtual machine. But if we need to manage bunch of machines, cloud service would helps us a lot and make us focus on the business logic.
I would like to achieve a high-availability scenario on two VMs in Azure.
I understand and can follow the directions here:
https://www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/
However, my question is this: are the two VMs supposed to be exact replicas of each other, so that when one goes down, the other takes over? Or does the Availability Set look after this, so that the two VMs can have totally different content and still utilise each others' free resources?
If you're working with Virtual Machines (currently in Preview), then each VM lives in its own VHD. You can make additional instances by creating a VM from an image you build, but at that point, the new VM lives in its own VHD and the actual disk image will then deviate from any other instance as time goes forward. Of course, if each VM is created from the same image, with the same initialization tasks, etc., then they'd have the same software as well. You'd be responsible for upgrading software versions on all the VMs. If you then put these multiple Virtual Machines in an Availability Set, you'd be assured that the Host OS (underlying OS at machine-level) for the VMs you have would not be updated at the same time. You'd also know that different VMs in the Availability Set would be situated in different racks, network segments, etc.
More on Availability Sets: Within an Availability Set, you may have any variety of Virtual Machines - Linux, Windows, different functionality. And... you may define more than one Availability Set.
In the PaaS world, where you set up a Cloud Service with Web and/or Worker roles, those VMs are spawned the exact same way. So adding instances means adding more of the equivalent VMs. If the disk crashed, a new VM would be created just like the others. There are no persistent changes to those OS disks. In the case of Cloud Services, there's fault domains and upgrade domains, which are very similar to availability sets.