I have an Azure Application Service Environment.
Is it okay to have multiple App Service Plans (Dev,Test, and Production) all running in the same ASE?
Basically, I know they'll share the Front End Pool, which I'm assuming is fine because no app code is running there and it "...contains compute resources responsible for SSL termination as well automatic load balancing of app requests within an App Service Environment. "
I guess my confusion is around the Worker Pools and Instances.
If I have a Dev Test and Prod can I host each one in a Different Worker Pool? Or would I even need to, could I just host them all in the same worker pool but they'd be using different instances so they're separated? Would I need 2 Worker Pool Instances per App Service Plan to make sure I have redundancy? (Confused why the Website says you only need one additional Instance (for 1-20 instances).
Basically, is this okay? And if so, what would the worker pool setup look like?
Would I have 6 instances in 1 pool with auto-scale turned on?
2 Instances in each of the separate 3 pools with auto-scale turned on?
Or would I need 3 separate Application Service Environments?
I've spent the last 2 hours reading Microsoft articles but none speak clearly about this or have a real-world example setup.
The documentation clarity regarding ASEs is still very much a problem. This is troublesome as ASEs are sold as a premium integrated hosting product in Azure.
I have had a discussion with an engineer at Microsoft about this very question and I still cannot say I understand the resource enough to be happy. Here is what I understand:
An ASE comes with 3 worker pools (vm) by default
All worker pools run the applications defined in your worker pool 1
You can define a different set of ASP and Applications for your worker pool 3 for example and have production on 1 & 2 and dev on 3.
Instances in a worker pool affect all the applications of your configuration.
The way I see it ASE is designed for a very specific business scenario that I have yet to see. It is quite powerful but you will most likely never use it to it's potential. I guess that's why Microsoft engineers recommend using simple App Services in most scenarios.
Related
I was wondering what would be the minimal recommended instance count for azure app service web app in production scenario ?
We currently have app services under Isolated app service plan with Autoscale rule in place (scaling up to 10 instances).
However the minimal instance count is currently set to 1.
I was wondering if this number shouldn't be higher (at least 2)? Can this impact SLA and apps availability somehow ?
If availability is a concern you should use 2 or 3 instance to minimize impact. Having just one instance can cause downtime. If you have a web app running on 1 instance the Azure Portal warns you with the following advice:
Distributing your web app across multiple instances
The webapp is currently configured to run on only one instance.
Since you have only one instance you can expect downtime because when the App Service platform is upgraded, the instance on which your web app is running will be upgraded. Therefore, your web app process will be restarted and will experience downtime.
Having 2 instances mitigates this, but can still cause downtime if one instance is not available due to a platform upgrade and one instance is not available due to a new deployment. 3 is best since in that regards.
Do note that if high availability is a must, then you need to also think multi-region. Think worst case scenario such as a natural disaster taking the one data center offline that you are using. It would be best to have something like Azure Traffic Manager (ATM) in front of two web apps (each with 3+ instances) and if ATM detects one of your web app regions is offline, it can reroute traffic to minimize downtime. Customer's who are running storefronts and the availability of their app is tied directly to their app being online will often take this approach.
(source)
As I understand there is no concept of update domain in App Services (and in other PaaS offerings). I am wondering how Azure is handling OS updates if I have only a single instance of an App Service app. Do I need to plan for two and more instances if I want to avoid such cases when an app goes down during the OS/other updates or this is handled without downtime? According to docs App Service has 99.95% SLA - is this time reserved here?
First of all, welcome to the community.
Your application will not become unavailable when App Services is patching the OS, you don't have to worry about that. Imagine if that would be the case, it would be a huge problem. Instead, the PaaS service will make sure your application is replicated to an updated worker node before that happens.
But you should have multiple instances, as a best practice listed in this article:
To avoid a single point-of-failure, run your app with at least 2-3 instances.
Running more than one instance ensures that your application is available when App Service moves or upgrades the underlying VM instances
Have a look at this detailed blog post:
https://azure.github.io/AppService/2018/01/18/Demystifying-the-magic-behind-App-Service-OS-updates.html
When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances.
The SLA is the same regardless the number of instances, even if you select "1 instance":
We guarantee that Apps running in a customer subscription will be available 99.95% of the time
Have a look at Hyper-V and VMWare, it will give you a rough idea on how App Services handle that.
If you're looking for zero-downtime deployments with App Services, what you are looking for are deployment slots.
Managing versions can be confusing, take a look at this issue I opened, it gives you a detailed how-to approach about managing different slot versions, which is not clearly described by Microsoft docs.
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.
I was hoping I'd be able to find Azure billing 'use cases' somewhere on the MS site or on StackOverflow.
Maybe I'm being paranoid but I'm trying to be certain before I tell a customer that it'll cost $XXX.00 to move his app to Azure.
I've got an MVC site running on a server in his office. It's a data-based app using SQL-Server. Data intensive but just about 20-30 users. The purpose of going to "The Cloud" is not scalability but reliability.
Lets just say I need a Cloud Service with 2 medium VMs (2 so that we have fail-over capability) and a 1GB SQL Database. Say $2 worth of Bandwidth (15 gb) would probably be enough. Geo Redundant Storage: all the stuff besides the DB is comprised of Code. Very little in the way of resources, total less than 20 megs.
So, my question: By running a Web and Worker am I using two instances? One for Web and one for Worker? If so, can I run the app in just a Web Role? I don't run a separate service. What if I did run both Web and Worker roles for the same site, would that be an extra instance (4 instances instead of 2)?
So, by running a Web and/or Worker role am I ALSO incuring a Virtual Machine instance? If not, does the scenario change if I occasionally RDP into the Web/Worker instance?
Thanks for any insight into this. Also, does anyone know of a MS site that has billing 'use cases' like this?
Based on your description, I'm not sure why you'd want a Worker role. Worker roles are ideal for handling transactions, processing, etc. but I'm not sure if you need that. For example, worker roles can process submitted orders, resize images, etc. Basically any process that you'd like to abstract from the user interface.
Since you mention that you want fail-over capability, you should probably use at least two of whatever role(s) you choose. For example you will need a Web role for your MVC web site. You'll need two instances of whatever size you choose to qualify for Microsoft's Cloud Services SLA uptime guarantee of 99.5%.
Should you decide you need a Worker role, you'd need two instances of that as well.
It's not required to use a minimum of two instances per role type, but it's certainly recommended for production apps, and is required for SLA coverage.
you get charged for each role you activate, so web and worker role will be separate. as far as combining the worker and web together, not sure progrmatically how the
Ok lets take this one by one.
By running a Web Role and a Worker role while meeting the SLA criteria of having at least 2 instances of each role you are essentially creating 4 billable instances (2 Web Role instances and 2 Worker role instances)
You can definitely run a service within a web role if that suits your purposes and save on the worker instances. In that case you'd only have 2 billable instances.
No the VM role is a completely difference role type and you are not running a VM role by running Web/Workers. You can always safely RDP into the instances irrespective of the role type (However the merit of such an act is questionable once you are in production).
Is it possible to deploy multiple roles in the same instance?
I have three web roles (website in asp.net mvc3, and two WCF services instances) and two worker roles (windows services).
The load for this application is very small, so I don't want to create so many instances in Windows Azure and pay for all of the instances now. Instead I want to deploy all my application in the same instance and change it later if I will get some income from my applications.
I Googled and found some forum posts than it's possible and some than it's not possible... but I can't find information how to do it...
So two questions:
Is it possible?
How can I do it?
A slightly different answer than #Simon's... A Role is actually a template for a Windows Server 2008 VM (see my answer on this SO question as well). Each role has one or more instances, and you can run whatever you want on any role.
You can absolutely run your website and all your WCF services in a single role. You'll now scale your application up/down (VM size) and out/in (# of instances) as a single scale unit. If, say, your WCF services are CPU-intensive, causing the VM instances to slow down for your web visitors, you'll need to scale out enough to handle those visitors.
Once you reach a significant traffic load, it's worth considering separate roles. That way, you can decide on VM size and quantity per role. Maybe you have 2 or 3 Small instances of a Web role to handle your user traffic on the website, and maybe 2 Medium instances of a Worker role to handle WCF services (just as an example). The more roles you have, the finer-grain scaling you have, but you must run at least one instance of each role, which elevates your "system at rest" baseline cost.
No, roles are instances and each one takes up an entire VM. You can however deploy a number of websites into a single role, which will allow you to deploy all your MVC and WCF apps into a single web role. You need to add websites to the sites element in the ServiceDefinition. There seem to be a few blog posts on how this is done - here and here.
For worker roles, I suggest you create a single worker role and combine the work done in those roles, such as starting a separate thread for each queue being monitored. This StackOverflow answer by Eugenio Pace.
I wouldn't recommend trying to combine worker role functionality into the web role. Apart from it not making architectural sense, sense to the physical infrastructure (IIS vs not IIS), there are potential issues such as the with termination of running threads when worker roles recycle (a thread not started by IIS may terminate abruptly)
Check this episode of cloud cover.
you can put couple of web role in the same instance.
worker role you can always put multiple thread to work the data.
http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-37-Multiple-Websites-in-a-Web-Role.
Note that each time you upload a new version to azure you need to upload all the web roles/ worker roles to azure again
Check out this blog post 'Combining Multiple Azure Worker Roles into an Azure Web Role'
http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2012/02/combining-multiple-azure-worker-roles.html
I think this is what you need to do...
Also Wayne has variations of this on his blog: http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/how-to-combine-worker-and-web-role-in.html
HTH