We have a VM say SampleVM depoyed & running on Azure Environment and on the same we have created 2 instances One is WebRole & other is WorkerRole running onto Slot staging.
My prob is I am able to Start/Stop SampleVM through powershell command but How can I Start/Stop a single instance(WebRole or WorkerRole) running on a SampleVM.
However when I stop SampleVM then both the Instance also stopped but I want to stop only one Instance/VM i.e. WebRole Or WorkerRole.
Please provide some powershell command with the argument pass to Stop/Start a single instance
Good answer by Gaurav, but I wanted to add a bit more detail, as I think there may be a bit of confusion around web and worker roles. Each role is a definition for a group of virtual machines that do the same thing, as constructed by you (you don't deal with the OS - you just kickstart your app, and Azure takes care of the VM itself).
When a Cloud Service is running, there will be a minimum of one instance of each role type. So in your case, running both a web role and worker role, you'll have at least two VMs running.
If you choose to scale out your web role to, say, 3 instances, and then decide to dial it back to 2 instances, you cannot choose which one to shut down; this is taken care of by Azure's fabric. Remember that each instance of a role is running identical code, and Azure load-balances traffic to your role instances (through external endpoints that you define). The only thing you need to worry about is shutdown. You have approx. 5 minutes to clean up any running processes (and you can easily take a particular instance out of the load balancer during shutdown, since you receive a Stopping() event).
You cannot shut down an entire role (e.g. all instances of a role) within a cloud service (so... you can't take down your worker role instances while leaving your web role instances running). If that's a requirement, then you can always consider running your web role in one Cloud Service and worker role in another Cloud Service. If they use queues to pass data, everything will still work as before. If the web role instances need direct access to worker role instances, you could put both Cloud Services into a Virtual Network.
One more thing to consider: You don't have to have separate roles. If cost is a factor, you can run all your code in your web role. Takes little work to spin up additional processes / threads in your web role, during OnStart() - remember that role instances are full Windows Server virtual machines; run whatever you want. With a single role definition, scaling is a bit coarse: Everything is scaled together. With separate roles, you can fine-tune your scaling (much more important when building larger systems).
David's broader points about how to model your PaaS service are all correct. But to add to it, there is a new Service Management API that has just been released called Delete Role Instance which will let you delete a specific instance of a role - http://msdn.microsoft.com/en-us/library/windowsazure/dn469418.aspx. This functionality is brand new to allow you to choose which instance to delete instead of being subject to the default fabric behavior that David describes (always deleting the last instance).
Simple answer is that as of today, you can't stop a single instance of your web/worker role. When you stop a role, all instances are stopped. You could remove instances from your role but again you can't specify which particular instance you want to remove. See #kwill's answer below.
You may also find following links useful for deleting specific role instances:
http://gauravmantri.com/2013/10/16/a-new-version-of-windows-azure-service-management-api-is-available-with-delete-specific-role-instances-and-more-goodies/
https://github.com/richorama/Two10.Azure.SelfDestruct
Related
I have few services which has very low usage, but they are quite hardware intensive when they are used. Right now they run separately. Every of them has its own Web Role and Worker Roles. Every of this roles run on its own VM with specified size and instances count. That is I believe standard way.
I would like to rent one quite powerful VM from Azure, on which I would like to deploy every of my services. Ideally without changing structure of code so I can keep them in separate projects/solutions. They will run simultaneously and all of them will be accessible.
You cannot deploy more than one cloud service package to a set of role instance vm's. If you want all of your services to run in a single role instance (or set of instances), you need to bundle all of your services into that role. How you do that, and how you organize your code, is strictly up to you.
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
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!