I have set up an application gateway in almost five different regions in Azure and every time Azure take around 15-20 mins to complete the setup.
Whereas AWS will do it in a couple of minutes, why Azure requires such a long time?
You should try using Application Gateway V2, its a lot faster to create. updates are almost instantaneous (well, at least compared to V1). But I believe V1 is using windows VM's underneath, so it creates a set of vms for you, then it configures them. Each update would be a "sliding window" update, with 1 vm being recreated at a time.
As far as I know.
Application Gateway is a layer 7 load balancer which, as far as I understand, is a Windows VM (or collection of Windows VMs, depending on selected size) under the covers, which take some time to come up and be configured. In my experience, this time is usually around 15-30 minutes, depending on region and local time of day, capacity, etc.
Azure Load balancers on the other hand are layer 4 load balancers, which typically take in the order of 1-2 minutes to come up.
So, yes talking about the load balancer if you say it normally takes less than a minute to get deployed. But coming onto the Application gateway yeah it takes 15-20 minutes every time the reason being:
Configuration Settings: Microsoft has the set of the vacant load balancers ready at their backend and when they receive a request to deploy a particular load balancer in any region, they just assign it an IP as requested by the user and it gets deployed within a minute. But coming onto the Application gateway, azure need to start deploying the load balancer [App Gateway in this case] from the scratch, need to attach it to the VNET so deployed and making it ready for the backend pools IP Address configuration and all, which basically take time about [15-20 minutes]. Now, Azure has brought up the V2 of the Application Gateway, a lot faster to create usually 5 minutes. And also talking about updates they are also really quick and instantaneous.
Subscriptions: Secondly, the reason that it takes time is subscription. Suppose, you have the MSDN, free subscription in your Azure account. And another individual sitting at any different place is using the enterprise applications subscription [basically a pay as you go] in his azure account. Now, both of you raise a request to deploy an Application gateway in the same region at the same time then, Microsoft will give the person request with the enterprise subscription the higher priority than your free subscription request. Which is another reason that it results in a delay. As I am using the enterprise edition so it takes 2 minutes for a VM to deploy which gets deployed in 5-6 minutes if using the free subscription!
Thanks!
Related
Within the Web App Down page in Diagnose and Solve for my Azure App Service I am seeing a series of 502 errors that have been occurring consistently for the past few hours. My site is unreachable upon browsing. I have tried restarting the app, and this has not helped. There have been no recent code deployments or configuration changes that led to this error.
Looking at the Microsoft Documentation I see:
https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-troubleshooting-502#cause-1
This seems to be an issue with the connectivity to the back end address pool that is behind a gateway which should be managed by Azure.
As you said, 502s generally indicate being unable to connect to back-end instances.
A solution to this can be to scale up or scale down your app service plan ensuring that you remain within the same tier (i.e. standard vs premium), so as to not change your inbound virtual IP, wait ~5 minutes, and then scale back.
Examples: S1 -> S2 or P2v2 -> P1v2
This operation, also referred to as the "scaling trick", allocates both new instances to the app service plan hosting your web apps, as well as a new internal load balancer.
In the event that there is a process hang-up caused by another resource running on the same hardware hosting your instance(s) and your site, this is the most efficient way to move your site to a new instance. Essentially, this functions as a hard reset beyond the capabilities of the traditional restart.
Lastly, because Azure bills by the hour and this temporary scale is for only 5 minutes, in the event that you need to scale up to remain in the same app service plan tier
(i.e. standard vs premium), you will face either negligible cost or no cost at all.
For future reference, in order to prevent this issue from re-occurring, if you have multiple instances running for your app then please consider enabling health check feature: https://learn.microsoft.com/en-us/azure/azure-monitor/platform/autoscale-get-started#route-traffic-to-healthy-instances-app-service
You can find other best practices here: https://azure.github.io/AppService/2020/05/15/Robust-Apps-for-the-cloud.html
My app deployed in Azure with basic tier having 10GB space. Now it showing the usage warning error in Server. So I want change the scale from basic to standard. Then which instance size should choose having ( Small-1 core, Medium-2cores and Large- 4 cores) ? Also while saving following notifications are showing
In Standard mode, if a web app is stopped, billing continues, and changing the scaling for an app affects other apps. Are you sure you want to continue?
This will scale the following web apps in the East US 2 region. This can take several minutes to complete. Your web apps will keep running during the process.
please help
To answer your question, here is a table with App Service sizes in which you can see that the Standard size has 50GB and the Premium has 500GB of disk space.
To answer your other questions:
The reality is that you pay for the App Service Plan, each plan can host dozens of Apps. Think of it as a Platform running all the time that hosts your Apps, if you stop one App, the Platform is still running (because you might have other Apps running on it), and thus, you are still charged for it.
Like I said, because what you pay is the App Service Plan, scaling the Plan will automatically scale all the Apps contained in it, that's the reason of the second message.
Think of the App Service Plan as a server in which you run your Apps, the moment you delete all the Apps in the Plan, the Plan stops billing, but as long as you have at least one App (running or stopped) in it, it will keep charging.
Hi I have a web app deployed as a Cloud Service on Windows Azure. Now I am performing some load/stress test against this app. In the Azure Management Portal I have configured the web role to scale automatically when the CPU goes over 40%.
I start the tests with only one instance of this web role. As the test progresses, I have set the number of concurrent users to increase over time up to 2000 users.
After I start the test, I connect via remote desktop to the web role instance on Azure and I monitor the CPU usage. After 10 mins or so, the CPU is constantly at 100% (and in fact my requests in the test take a very long time to complete) but if I check the CPU of the very same web role on the Azure management portal it says 1, 2 or 6, there was a peak of 70% but it sunk back immediately (but never the values I see in its task manager when I am connected in remote desktop) or even does not display any value (I go to the dashboard page of my cloud service), which means the graph is not updated any more.
Furthermore, and this is the point of my question, NO SCALING of the web role instances is performed whatsoever.
Any ideas where/what I am missing? Feel free to ask if my explanation is incomplete.
Autoscaling on the CPU metric for a Cloud Service or Virtual Machine doesn't occur as fast as you are expecting (~10+ minutes). In this scenario, the CPU metric is averaged across all instances of the services for a period of 1 hour. Therefore, your autoscaling actions will not be immediate.
You can read more about this and some recommendations for configuring your autoscale settings here.
If you want to tighten this up a little more then take a look at this post where I show how to set the TimeWindow using the Monitoring Service Management Library. You may be able to get closer to what you want taking this approach.
A few things to consider:
1) As Rick pointed out, by default CPU is taken at an hour average
2) If you start at only 1 server, and then autoscale up to 2, your first server will get yanked out of load balancer during the scale operation. You should really always have a minimum of 2 servers at all time.
3) Feel free to check out AzureWatch (link in my profile).. it was designed to perform decently advanced scaling scenarios and allows you to configure scaling rules without touching APIs
We are in the process of moving our current IAAS solution over to azure where we host asp.net LOB web applications in IIS with an SQL Server backend.
I’m looking into availability sets. I stumbled upon this article at: http://michaelwasham.com/windows-azure-powershell-reference-guide/understanding_configuring_availability_sets_powershell/
This seems like how we want to setup our deployment on Azure where the “Web Servers” are our virtual machines. My question relates to how we setup our virtual machines. Currently we have about 200 separate hosted customers on our IAAS solution which means 200 separate web applications in IIS. With a highly available deployment should the Virtual machines be exact replica’s of each other i.e. 200 customers on box 1 and that again on box 2. Or should we spread them over multiple boxes i.e. 0-50 customers on box 1, 50-100 customers on box 2 and so on.
I cant see how the 2nd option spread would work in a highly available set because if 1 box goes down than all the customers on it go down with it?
Little confused, hoping someone has got advice on this?
Thanks
It would be best to duplicate everything, the azure load balancer (layer 4 balancer) ensures that load is spread across listening endpoints evenly and randomly, so you cannot know which server will answer a request, hence you must have the same configuration on both boxes. Here is some info on the Azure load balancer which you might find interesting, link
Also put them into an availability set so if one of the vm dies for some reason or during updates (which can happen from time to time with vms) you can be sure that at least one of your vms will always be online. You may need more than two vms, it really depends on the amount of traffic each of your clients generate and the load that that creates. But do have atleast two vms.
Just a side note if you haven't used Azure before; it may take you a bit of time to get the cost per vm right over time, but remember to use the schedule to scale up and down to reduce costs and anticipate load on your vms. Also having 4 smaller vms is better than 2 larger vms from a failure point of view and ultimately cost the same over a month. If one large vm dies, you've lost 50% of your capacity to serve your clients, where as if you lost one smaller vm you've only lost 25%.
The company I work for is looking to develop a few apps against the cloud.
An ASP.NET Web Api application hosted in an Azure web role.
A Windows Server type application hosted in an Azure worker role.
We are completely new to web or cloud development and would like to know the following:
When being served to the consumer, is the same instance of the application being served to all, is it one per request or are multiple roles being created and served to consumers?
When being served to the consumer, is the same instance of the application being served to all?
That depends on how many instances you've asked Azure to run your application on. If you've only deployed to 1 instance, then it will of course be the same instance that responds to all requests. But if you deploy to multiple instances, requests will be load-balanced, which means you have no guarantee that multiple requests from the same user will be handled by the same instance.
When you're asking this question, it could be because you might be tempted to store local data on the machine running the instance. However, this is not a good idea. Windows Azure can at any time tear down your instance and start your application on a completely different machine. They call this "healing", because it usually happens because Windows Azure tries to be helpful and avoid any potential problem that could mean downtime for your instance. But it also happens if your machine for some reason locks up or something else bad happens. This process of healing means that anything that's not part of your deployment package will be lost. So for example, if you're logging to a file on the disk, this log will be lost if Azure "heals" your instance.
is it one per request or are multiple roles being created and served to consumers?
I'm not completely sure what you mean here, so I'll take a guess and risk interpreting your question wrongly. My guess is that you're asking if there will be one instance per user request. No, there will only be the number of instances that you have decided. Remember that you have to pay per instance that's running, so it's only fair that the number of instances running is dictated by you.
When you have your application packaged and ready to be deployed to Windows Azure, you can decide how many instances of each role you want to have running. You set this number in the deployment package, so that when your package is deployed, Azure will automatically start the requested number of instances. However, you can change the number of running instances of each role after deployment and on-the-fly. This makes it possible for you to scale with more instances within minutes.
I hope this helps and that I understood your questions correctly. :-)
Azure Web and Worker roles in an Azure Cloud Service are deployed on at least one instance (managed VM). Azure allows you to size (memory, CPU) and scale (number of instances). Azure actually lets you scale dynamically, i.e. add more instances on demand. You pay by the hour for the size & number of instances deployed.
For example, a Cloud service can have a single instance of a worker role (background processing) and multiple instances of the Web role. Multiple instances are handled behind a load balancer and the client is unaware of what instance they are using (all instances are created equal).
An Azure role instance is a VM with some specific payload.
For example, in your service you declare you want three instances of "Frontend" web role and two instances of "Backend" worker role. When Azure deploys your service it starts five VMs and three of them will run "Frontend" payload and have IIS started and two of them will run "Backend" payload and have no IIS started.
Now until you ask Azure to change that configuration it remains persistent no matter what requests come and what load occurs. You have five VMs with 3+2 configurations. To change the configuration you need some action on your part.
There're two way to have the configuration changed. You can use Management Portal or an external program to change the "instance count" in either or both roles. You can also add auto-scaling code that will gather metrics and make Management API requests to alter the "instance count". Either way when "instance count" goes up Azure starts more VMs with the same payload and when it goes down it stops some of the VMs.