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
Related
I've deployed web sites and services to the cloud before but it was a while ago and I wanted to revisit my approach to inventorize my skills. During the research, I've been told to use a worker role but I'm not sure in what constellation to apply it.
The image presents my choices. I'll be setting up two things (preferably on the same base URL).
1. A web site (ASP.NET, most likely MVC powered by Razor)
2. A service layer (guessingly WCF, as there's not much else to pick from today)
So, in my naive ignorance, I added ASP.NET Web Role for the former and WCF Service Web Role for the latter. Then, according to the hint, I also added Worker Role. And this is where I got humble and started to suspect that my ignorance was rather an arrogance...
Do I need all the three of them? Or is it perhaps so that Worker Role covers the others? Or are the others sufficient and I need to Worker Role? Or am I totally confusing the concepts here?
I've tried to google those but I realize that I haven't reached the threshold of learning by doing in this area yet. I get more confused and headacheish the more I read. Admittedly, my problem might lie in the wrong choice of search words and/or linguistic misconception. If so, my apologies...
The answer is, it depends...
A web role is essentially a Worker role with IIS installed + configured. You could host a WebApi/MVC, WCF AND process events all from the same web role if you really wanted to, reducing costs.
Remember that each role is a separate VM that you have to pay for, so adding extras roles to keep everything separate may not always be the best idea.
In one of our projects for example, we use a web role to host a WebApi. A Worker role to process internal events, and a worker role to host WCF services (you can also use a web role for this). We split them because they take very different workloads and perform separate functions, so being able to scale them independently made sense.
HTH
There's no right answer to how many roles to use in a cloud service. But it's important to understand exactly what those roles are.
Adding a bit to #Peter's answer: Each role is a definition of a VM (its contents) - think of it as a VM template. And for each role (template), you must have a minimum of one instance (VM) running. If you have one role, your minimum footprint will be one VM (of whichever size you specify for that role). If you have three roles, you'll have minimum 3 VMs running.
Whether you have one role or many depends on how you want to scale your application. Each role defines not only what goes in it, but also the size of the VMs uses by the role instances. By having different roles for different parts of your architecture, you can choose to scale those parts differently. For example, you might only need low-resource instances to handle your web tier, but maybe more CPU power for your service tier. And maybe your web tier scales dynamically based on user traffic, but you're able to handle, say, your service tier with just one or two instances. Of course, you can put everything in one role definition, and scale everything together. It's totally up to you.
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).
What is established best practice in porting a Windows Service to Azure? Should it be changed into a Worker Role or moved into a VM Role? Are there other options? Assume that my services write to external persistence sources (MSMQ, databases, WCF) rather than to the file system directly.
You are far better off converting your Windows Services to Worker-Roles than VM roles. VM roles are meant to house applications that require complex un-automatable installation procedures. They are also a bigger pain to manage and you want to stay away from VM roles as much as possible. If you can find a way to automate deployment of your existing Windows Services via Worker-Roles, it is definitely the way to go.
You can also looking into HPC roles and depending on the on-prem/off-prem and load/compute requirements, adding Azure machines to your HPC cluster maybe of benefit.
All types of Roles (Web/Worker/VM/HPC) are stateless and require to be able to spin-up or tear-down from scratch on demand. All types of Roles are meant to run more than one VM instance at a time.
HTH
I wrote a blog post about this a while back. It is here:
http://blogs.msdn.com/b/golive/archive/2011/02/11/installing-a-windows-service-in-a-worker-role.aspx
Note that a Windows Service won't communicate directly with the fabric controller, so you need to ping it periodically to check health, then take remediative actions as needed.
Putting a Windows Service into a worker or web role is accepted practice. The main reason to go with VM Role is if there is significant (>10 minutes) setup required. My blog post details how to install your service.
Of course, if you want to move the code into a worker role, that's also fine. In this case you don't need any special steps to ensure the fabric controller is aware of its health.
If cost is an issue, combining functions into web/worker is also accepted practice. And you can save by not working over your code to get it into a web/worker.
Azure has a special type of Web Role called "WCF Service Web Role" which corresponds to a Windows WCF Service. This is a good point for migrating existing services.
Ideally the migration should be followed by taking advantage of Azure specific features, for instance using queues and work roles to maximise perfromance and scalability.
I have to run a web crawler in background using Azure.
According to what I understood I have to setup a worker role configured with the background task and I have to setup a web role to show the web site ASP.NET MVC.
A simple question: how does it work for the payment? Two different roles means two different instances? Or I can reuse the same instance hosting two different roles?
Each Role you define must contain 1 or more instances. Each instance is a VM and you will be billed currently .12/hr per CPU core (or fraction thereof for XS roles).
You can combine the web site with worker role capabilities very easily. By default, you should see a WebRole.cs that implements a RoleEntryPoint. That is your worker role entry point in a web role. You can combine whatever logic you want in there for the background task.
I know that you can only have 1 web role per instance but does this apply to Background roles as well? In more detail can 1 instance run a background role and a web role?
I think the terminology used in your question is confusing the other responders.
In Windows Azure compute, you have a cloud service. A cloud service can be thought of as your overall architecture, or at least the front end, the middle tier, etc (any tier where there is compute as opposed to storage). For example your application might have a presentation front end (ASP.Net MVC web application) and a middle tier (WCF service layer over basic http). We liken each of these tiers to "roles". So in my example above, I would have 2 web roles in my cloud service. I might also have some back end processing which does some sort of batch work, this would be a "role" also. Roles that respond to user interaction such as web sites, service layers, etc are hosted as "web roles" while those back end services are "worker roles".
Then we have instances. An instance is how many virtual machines are provisioned to provide the functionality of a given role. For example, I might need my presentation tier to have 5 instances because it takes a lot of load. So, my 1 web role has 5 instances. Likewise my middle tier, a service layer, might only need 3 instances (because of presentation tier caching) and so therefore my 1 web role has 3 instances. My back end service might only need 1 instance since its job can be done whenever, but if the back log gets too big, it could scale up to 10 instances to get through the work, then scale back down to 1 instance again.
So the key here is that you can have 1 or more instances per role. Because of this relationship it makes sense that you can have only one role per instance (since an instance is 'instantiated' from a single role template).
What Rinat was trying to say above was that you can cheat with the worker role and actually host a http end point in WCF, thus getting web role type behavior, however you don't get the load balancing of a web role when you do this. Likewise, a web role can have worker role style behavior by overriding the OnStart method in the WebRole.cs. However I would still argue this is just one role in both cases, and you can have multiple instances of that role.
Bjorn was indicating that by default you are capped at 20 instances per role, however you can get more (so he doesn't deserve a -1 IMHO).
Hope this clears it up.
You can have only one role per instance.
However, you can host Http endpoint in your worker role, effectively turning it into Web+Worker role.
References and samples:
Windows Azure Hosted Web Core Worker Role
Redirect Tcp Connections in Windows Azure
By default one web role can have 20 instances. If you need more you can contact the Azure Service Desk and they will turn it up!