I am designing a learning management system and inflow for the website is more in some cases and less in another time. I would like to know about the getting the vCPU's which are scaled up to make it down after the stipulated time. I found a document regarding scaling up but didn't find a way to scale it down.
Any help is appreciated.
There is a chance of auto scaling for the normal services in azure cloud services, that means for stipulated time you can increase or decrease as mentioned in the link.
When it comes for vCPU which is cannot be performed automatically. vCPU can be scaled up based on the request criteria and in the same manner we need to request the support team to scale those down to the normal.
There is no specific procedure to make the auto scaling for vCPU operations. We can increase the capacity of core, but to reduce to the normal, we need to approach the support system for manual changing. You can change it from 10 cores to next level 16 cores, but cannot be performed automatic scaling down from 16 cores to 10 cores.
Related
I'm trying to find the optimal cloud architecture to host a software on Microsoft Azure.
The scenario is the following:
A (containerised) REST API is exposed to the users through which they can submit POST and GET requests. POST requests trigger a backend that needs a robust configuration to operate properly and GET requests are sent to fetch the result of the backend, if any. This component of the solution is currently hosted on an Azure Web App Service which does the job perfectly.
The (containerised) backend (triggered by POST requests) perform heavy calculations during a short amount of time (typically 5-10 minutes are allotted for the calculation). This backend needs (at least) 4 cores and 16 Gb RAM, but the more the better.
The current configuration consists in the backend hosted together with the REST API on the App Service with a plan that accommodates the backend's requirements. This is clearly not very cost-efficient, as the backend is idle ~90% of the time. On top of that it's not really scalable despite an automatic scaling rule to spawn new instances based on the CPU use: it's indeed possible that if several POST requests come at the same time, they are handled by the same instance and make it crash due to a lack of memory.
Azure Functions doesn't seem to be an option: the serverless (consumption plan) solution they propose is restricted to 1.5 Gb RAM and doesn't have Docker support.
Azure Container Instances neither, because first the max number of CPUs is 4 (which is really few for the needs here, although acceptable) and second there are cold starts of approximately 2 minutes (I imagine due to the creation of the container group, pull of the image, and so on). Despite the process is async from a user perspective, a high latency is not allowed as the result is expected within 5-10 minutes, so cold starts are a problem.
Azure Batch, which at first glance appears to be a perfect fit (beefy configurations available, made for hpc, cost effective, made for time limited tasks, ...) seems to be slow too (it takes a couple of minutes to create a pool and jobs don't run immediately when submitted).
Do you have any idea what I could use?
Thanks in advance!
Azure Functions
You could look at Azure Functions Elastic Premium plan. EP3 has 4 cores, 14GB of RAM and 250GB of storage.
Premium plan hosting provides the following benefits to your functions:
Avoid cold starts with perpetually warm instances
Virtual network connectivity.
Unlimited execution duration, with 60 minutes guaranteed.
Premium instance sizes: one core, two core, and four core instances.
More predictable pricing, compared with the Consumption plan.
High-density app allocation for plans with multiple function apps.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan?tabs=portal
Batch Considerations
When designing an application that uses Batch, you must consider the possibility of Batch not being available in a region. It's possible to encounter a rare situation where there is a problem with the region as a whole, the entire Batch service in the region, or your specific Batch account.
If the application or solution using Batch always needs to be available, then it should be designed to either failover to another region or always have the workload split between two or more regions. Both approaches require at least two Batch accounts, with each account located in a different region.
https://learn.microsoft.com/en-us/azure/batch/high-availability-disaster-recovery
We currently have an elastic pool of databases in Azure that we would like to scale based on high eDTU usage. There are 30+ databases in the pool and they currently use 100GB of storage (although this is likely to increase).
We were planning on increasing the eDTU's allocated to the pool when we detect high eDTU usage. However a few posts online have made me question how well this will work. The following quote is taken from the azure docs - https://learn.microsoft.com/en-us/azure/sql-database/sql-database-resource-limits
The duration to rescale pool eDTUs can depend on the total amount of storage space used by all databases in the pool. In general, the rescaling latency averages 90 minutes or less per 100 GB.
If i am understanding this correctly this means that if we want to increase the eDTUs we will have to wait for on average 90 minutes per 100GB. If this is the case scaling dynamically won't be suitable for us as 90 minutes to wait for an increase in performance is far too long.
Can anyone confirm if what i have said above is correct? And are there any alternative recommendations to increase eDTUs dynamically without having to wait for such a long period of time?
This would also mean if we wanted to scale based on a schedule, i.e. scale up eDTUs at 8am we would actually have to initiate the scaling at 6:30am to allow for the estimated 90mins of scaling time - if my understanding of this is correct.
When you scale the pool eDTUs, Azure may have to migrate data (this is a shared database service). This will take time, if required. I have seen scaling being instant and I have seen it take a lot of time. I think that Microsoft's intent is to offer cost savings via Elastic Pools and not the thru ability to quickly change eDTUs.
The following is the answer provided by a Microssoft Azure SQL Database manager:
For rescaling a Basic/Standard pool within the same tier, some service
optimizations have occurred so that the rescaling latency is now
generally proportional to the number of databases in the pool and
independent of their storage size. Typically, the latency is around
30 seconds per database for up to 8 databases in parallel provided
pool utilization isn’t too high and there aren’t long running
transactions. For example, a Standard pool with 500 databases
regardless of size can often be rescaled in around 30+ minutes (i.e.,
~ 500 databases * 30 seconds / 8 databases in parallel).
In the case of a Premium pool, the rescaling latency is still
proportional to size-of-data.
This Azure SQL Database manager promised to update Azure documentation as soon as they finish implementing more improvements.
Thank you for your patience waiting for this answer.
It is clear that the auto-scale service allows to automatically scale-in and scale-out an application horizontally. And that I can manually scale vertically my application too by MANUALLY increasing/decreasing the memory.
Is there a way to AUTOMATICALLY increase and decrease the memory associated to the node.js instances based on some rules?
Note Bluemix charges the application based on GB * Hour. So by large you will be charged similarly among vertical scaling and horizontal scaling. However, vertical scaling does improves memory usage efficiency because there is less memory overhead (e.g., you load the node.js runtime only once rather than twice ore more). But horizontal scaling also has its merits:
Better availability due to increased app instances;
Better concurrency due to distributed processes;
Potential better exploration of CPU resource (because of the way CGroup works for CPU allocation).
So if your application is memory-hungry, allocating large memory for each instance would make sense. Otherwise if the app is CPU hungry, then horizontal scaling may work better. You can do some benchmark to evaluate the response time and throughput impact of both options.
The Auto-Scaling add-on in Bluemix monitors the chosen resources against their policies and increases or decreases the number of instances, not vertical scaling (memory).
Why does your node app's memory requirements grow? Can you offload some of it by using a database or cashing service? Relying on increasing memory when needed is currently a bad practice because it will require a small downtime as your application restarts.
As Ram mentioned. The Auto-Scaling service doesn't currently support vertical scaling.
You can scale horizontally by discrete numbers of instances or by a % of the total number of instances.
See the docs for which metrics are supported by each application type
edit: typo!
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 am using a azure websites solution with 20 websites. Hosted on 4 cores, 8 GB RAM standard instance. I would like to know how I could do scaling in Azure websites and when to do it ?
Also I am reading some values from the new azure portal.
Can someone guide me on the values that I see here ?
Thank you
Averages
The Avg % is telling you, on average, how much of that resource is being used. So, if you have 8GB of ram, and you are typically using 66% of it, then you are averaging 5.28 Gb of ram used. Same goes for the CPU average listed below.
For the totals, I have no idea.
You're not using much of the CPU available to you here, but you are definitely taking advantage of the RAM. I'm not sure of what kind of web application you are running though, so it's dificult to determine what could be causing this.
Scaling
In terms of scaling, I always suggest starting with a small machine, then gradually scaling up.
Based on your usage, I'd drop to a machine that has fewer CPU cores, but more available RAM. From within your dashboard, you can see how to scale by clicking no your web app, then scrolling down. Click on the scale tab and it should appear as it does below:
You can now adjust what you want to scale by. The default setting is CPU Percentage, but that isn't particularly useful in this case. Instead, select Schedule and performance rules and a new panel wioll appear. On the right hand side, select Metric name and look for Memory Percentage.
In your particular case, this is helpful as we saw that your RAM is consistently being used.
Look at Action and you will want to Increase count by and change the number of VMs to 1. What this does is when your RAM reaches a certain usage %, Azure will auto-scale and generate a new VM for you. After a cool down period of 5 minutes (the default, listed at the bottom), your machine will revert to 1 machine.
Conclusion
With these settings, each time your website uses <= (Select your percentage) of RAM, Azure will increase the size of your machines.
In your case, I suggest using fewer cores, but more RAM.
Make sure you save your settings, with the Save button above.
Scott Hanselman as a great blog post on how to make sense of all of this.