I have been digging without being able to wrap my head around this. It seems like once a role is deployed, you are charged for it in full, whether or not you scale it up or down?
Why would anyone scale down with this? I don't see the incentive to not just leave the role with all possible instances used to max?
I can see why an availability set, with several roles, might want to distribute the cores between them depending on load. But is that all it's for?
You pay the price of one instance of choosen size (A0 to D14) multiplied per the number of instance that are running.
Try with the Azure Princing Calculator, the number of instance increases charges.
When you try to use Autoscaling it clearly states :
Autoscale is saving you XX% off your current bill
Related
First I want to know if is possible to delete vmss instances based on cpu performance of the instances but not by using scaling.
I have a scale set in which the instances have different cpu average and I want to remove only the instances with the lowest cpu performance, let's say instances with less than 20% cpu performance.
The idea is to make a cycle to pass through all the instances and then a condition where I select all the vmss instances with less than 20% cpu performance. Inside the condition to delete the selected the vmss instances.
Why don't use the automatic scale, it's the best and simplest way to scale the VMSS. If you use the Runbook, you need to get the CPU performance yourself every interval. And I don't know a simple way to get it. You just can easily see the CPU performance in the Azure portal. Go to use the automatic scale, that's the way.
If I have an autoscaling group that consists of on-demand and spot instances with a minimum of 4 on-demand instances, and the extra capacity consisting of spot instances, what happens if it needs to scale up with a spot instance, and there isn't an available spot instance (because I've been outbid, or if there aren't any spare instances to fulfil the spot request)?
Will it still scale up using an on-demand instance?
Will the autoscaling group fail to scale up?
Other info:
I'm using a "Lowest Price" Spot Allocation Strategy
The max_spot_price is capped at the on-demand price.
My Google foo seems to be failing me as I can't seem to find any answers on the web. I would appreciate if anybody could shed some light on this issue.
Thanks in advance!
An AutoScaling Group in AWS will not failover to on demand if there's no spot capacity. This is essentially the trade off your getting for the lower price of spot instances. To work around this, try adding more AZs and/or instance types (not as much of an issue now that weights are supported and ALB can route based on Least Outstanding Requests)
If you have multiple instance types and AZs setup in the ASG, this happens after your on demand base is met:
1) Tries to launch the spot instance(s) based on your allocation strategy and number of spot pools
2) If the desired instance type(s) aren't available, try all the other types in that AZ
3) If no spot instances are available in that AZ, that launch request will fail and it will try again in another enabled AZ
4) If there are no spot instances, in any of the types you have selected, in any of the AZs you have on the ASG, then nothing will launch and the ASG will periodically retry until it reaches the desired capacity.
Think of it like this, there's only so many servers in their data centers. If spot evictions are happening because they need capacity for on demand instances, and everyone running spot failed over to ondemand for that instance type; there would probably suddenly also be an on demand instance capacity issue in that AZ.
I'm experiencing poor on Azure web apps when scaling out. Azure automatically picks up an issue from a set of rules I have set up (like CPU > 80% for 5 minutes). Then it increases the number of VMs by 1. Here is a screenshot of the settings on Azure:
This part works fine. But while it is scaling to one additional VM, I'm experiencing poor performance on the entire website. When the new VM is up and running, everything seems to work as expected.
I have previously observed similar issues when scaling up and down the VM size but this is "just" a new VM.
I have already tried to create application initialization in my Web.config:
<applicationInitialization doAppInitAfterRestart="true">
<add initializationPage="/" />
</applicationInitialization>
Still poor performance while scaling out. Does anyone know what this could be caused by? I wouldn't expect a website to perform worse while scaling. I know that the performance probably isn't that great when the VM reaches 80% CPU. But the performance is definitely worse as soon as Azure starts scaling.
Kindly ensure that the margin between the scale out\in are not small. I have seen cases where the auto scale flapping was the issue.
To avoid a "flapping" situation, where scale-in and scale-out actions continually go back and forth. It is recommended to choose an adequate margin between the scale-out and in thresholds.
Just a adding a few best practices guide for you to review the metric threshold.
Ensure the maximum and minimum values are different and have an adequate margin between them - E.g- If you have a setting that has minimum=2, maximum=2 and the current instance count is 2, no scale action can occur. Keep an adequate margin between the maximum and minimum instance counts, which are inclusive. Autoscale always scales between these limits.
Always use a scale-out and scale-in rule combination that performs an increase and decrease - If you use only one part of the combination, autoscale will only take action in a single direction (scale out, or in) until it reaches the maximum, or minimum instance counts of defined in the profile.
This is not optimal, ideally you want your resource to scale up at times of high usage to ensure availability. Similarly, at times of low usage you want your resource to scale down, so you can realize cost savings. I suggest you review the threshold for the metrics and example outlined in this documentation Autoscale best practices, and let us know if it helps.
I currently have a web application deployed to "Web Sites" - This is configured in standard mode and it performs really well from what I have seen so far.
I have a few questions:
1)My instance size is currently small - however I can scale out to 10 instances. Does this also mean that if I change my instance size to medium or large, I can still have 10 instances?
2)What is the maximum number of instances I can have for an azure web site?
3)Is there any SLA for a single azure instance?
4)Is it possible to change the instance size programatically or is better to just change the instance count
1) Yes
2) 10 for standard.
3) Yes, for Websites Basic and Standard, MS guarantee a 99.9% monthly availability.
4) It depends on a lot of factors. The real question is "Is it better for your app to scale up or scale out?"
Yes, the default limit is 10 instances regardless of the size.
The default limit is 10 instances, but you can contact Azure Support to have the limit increased. Default and "real" limits for Azure services are documented here.
According to the Websites pricing page Free and Shared sites have no SLA and Basic and Standard sites have 99.9% uptime SLA. Having a single instance means that during the 0.1% outage time (43.8 minutes per month) your site will be down. If you have multiple instances then most likely at least one will be up at any given time.
Typically instance auto-scaling is used to handle variation in demand while instance size would be used for application performance. If you only get 100 requests per day but each request is slow because it's maxing out CPU then adding more instances won't help you. Likewise if you're getting millions of requests that are being processed quickly but the volume is maxing out your resources then adding more instances is probably the better solution.
I'm an msdn subscriber and I'm looking at Azure as a possible platform for a new website that will test the water of a new service. This website is expecting low to very low traffic at the time of launch. I've heard that this kind of traffic levels is very expensive for Azure but since they have this msdn offer, I thought I'd finally take a look at Azure.
In the offer, I'm looking at getting "750 small compute hours per month". From the reading I've done, this seems that, if I purchase nothing more than what's given (although the subscription itself is thousands of dollars of course), that an entire month would be covered. Since 24 (hours) x 31 (max days in a month) = 744 I'm still below my allotted 750 for the month.
Am I missing something else from this simple equation? Is there further aspects that could cause the site to be "turned off" temporarily that should be considered?
Yes, you can indeed run a small instance during a whole month. Or you can have 2 extra-small instances instead (having 2 instances means you're covered by the SLA).
There are 2 other things you need to consider:
Depending on your subscription you can have maximum 45GB of storage (blob/table/queue). If you use Virtual Machines you need to know that the system disk (and additional data disks) are persisted as blobs, so make sure not to reach the limit here.
There are also other limits active, but the most important one besides storage is the data transfer limit which is also very limited (max 35GB out).
If you're expecting very low traffic, did you ever consider Windows Azure Web Sites? You get 10 of those for free during 12 months. The free ones run on shared instances, but they are perfect to host the first low-traffic version of your app.