I'm evaluating azure functions on-prem and would like to have the manager and worker roles separated. The install docs go through a scenario where both roles are on the same machine.
Does this mean that separating the roles on different VMs would not be supported/recommended?
If this is acceptable, would nested virtualization only be required on the worker VM since that's where the containers are spun up?
Is it common practice or even reasonable to use a role-based database prefix like "worker_" and "manager_"?
Appreciate all the help!
you cannot just install the manager in a role but what you can do is install many more workers on other machines, as mentioned in the documentation. To deploy additional workers just run the installer and choose the option Functions Worker Role and that will only install the functions worker on that machine.
In the preview, we install everything on one machine to get folks up and running quickly. This is good feedback to hear though.
Regarding the role-based prefix I'm not sure I understand your goal, there is only one database and that is for the whole of Functions Runtime preview and it is used by the management role, we do not create a separate database per worker.
Related
We have a bunch of Windows Services. We need to be able to continue to deploy our code as Windows service on premise, but would like to deploy to Azure where appropriate. The goal is to manage less infrastructure. I'm not keen on deploying dozens of bits an pieces as Azure Functions, but not entirely opposed to it either. Azure Batch / Webjobs are also another option. However, the long term goal is to move all of our services over to an orchestration server like Service Fabric so that all the services can be deployed and orchestrated from the one place. This is mainly a deployment consideration.
We will break the existing C# code in to .NET Core class libraries and reference them from either Service Fabric hosted in Azure, on-premise Service Fabric, or on-premise Windows Service. Is Service Fabric an appropriate choice? Or, is there a strong reason to run background jobs as Azure Batch / Functions / Webjobs?
This is Microsoft's diagram from here:
The answer to the question is that we don't really need full fledged orchestration right now, but it will become more important moving in to future. I have to balance being able to deploy all our code in one hit with the ease of ad hoc deployment that Azure Functions offer.
(Stateful) Services can be an excellent way to run background jobs. They offer the RunAsync entry point, in which you can run your job, check (and store) progress. SF really shines when multiple services collaborate on tasks, offering SF Remoting as a communication channel, with built-in retry support.
You can choose to containerize your software, which would free you from platform lock-in, but prevent you from using some platform features.
By automating delivery of services (CI/CD), you can deploy to any platform you choose. This is not something that is specific to SF.
If I have a Windows Azure Service consisting of only Worker Roles, do the worker roles start automatically or I need to start it manually?
I have some debugging print statements like Trace.WriteLine(...) in the Run and OnStart methods, but it seems those statements are not logged. What could be the causes?
When the service is deployed the role instances will start up automatically. Cory Fowler wrote up a great post explaining the Startup Lifecycle of a Windows Azure Role. The article is a little older as it still mentions the VM Role which as been deprecated in favor of the new Windows Azure Virtual Machine features. The information about the actual start up stuff is all still golden as far as I know.
As for why you are not seeing your trace writelines, where are you looking for them at? You may not have all the configuration setting correct to gather then up. Check out the Hands on Lab for Debugging Cloud Services for step by step and compare to your solution.
After searching over the Internet I found 2 ways to install an existing Windows service project on Windows Azure.
Create setup and add it startup task of web/worker role and spin up that role so it would install window service
Migrate logic of window service to worker role and spin up
My purpose is to get a Windows service on cloud as I have already application on windows azure websites (WAWS) so what should be best way to put window service on cloud from above.
and what would happened when I'll scale from 1 to more instance for above cases.
Thanks in advance for any help.
/Arun.
I would suggest that migrating to a worker role is the better approach as it is better aligned to the platform's design goals. for example - this will make it easier to integrate interaction with platform events such as starting and stopping, easier to use logging, etc.
The Scaling out story will be more or less the same with both options - you will end up with multiple instances of your code running, on multiple machines and so you must have a design that supports, and ideally benefits, from that.
What that means really depends on your exact scenario, but normally some co-ordination of which instance does what, handling incomplete operations by failed instances, etc...
Does windows Azure supports windows Services ?, ...
I develop an application that has among its components a windows service that every hour sends an email with information.
Is this supported in Windows Azure?,
Thanks!!
You might find the worker role is a better fit for running a process every hour. If you have the code for the WIndows Service it should not be hard to impleemnt it in a worker role.
You will, however, have to use a 3rd party service to send the email, as this is not supported in Azure.
Regards,
Alan
Yes, you can do this*. In order to install a Windows Service in a PaaS worker role (or web role), you will need to create a startup script that installs the service on boot (and checks to see if already installed on subsequent boots).
If you are using IaaS VMs, then the installation is straightforward - just do as you do today.
*Windows Azure Websites is a shared model, so installing services is not supported there.
To combine both Alan Smith's and dunnry's answers, both are correct -
You can install a windows services on a PaaS role using a startup script (other than web sites).
If you're using a Virtual Machine you just install the service on the VM
But Alan is completely correct that the best route forward in most cases is migrating the code to a worker role which is usually quite straight forward, would work best and would be easier to maintain.
Having said all of that - sending emails from within Azure is not necessarily a good idea as many mail servers black list the ips (turns out Azure is a great platform for spammers)
I want to make an extra addition to Alan and Yossi's answers. It's important to know the why, because simply installing the Windows Service shouldn't be a problem.
But if you do this you'll be missing out on something very important. If you run all of your code in the actual Worker Role process you'll get the monitoring for free. This means, if your process crashes for whatever reason, Windows Azure will restart the instance to make sure the process gets back online.
Now if you simply go and install a Windows Service through a startup script you won't be able to take advantage from this automated monitoring. You'll need to make sure you have some kind of recovery (this could be a setting on the Windows Service or a different process). But it's simply too much work for something you could get for free.
I would suggest using a Extra-Small VM using a windows template that is already offered. It's the same cost as the worker role and will let you provision your service without any issues. You would install your service the same as you would on any on premises server.
If you don't need to have the same sort of failover scenario that your web roles do then this s a good option.
We are thinking of using Windows Azure for simulation. ~100 VM nodes each working on it's problem set and reporting back the result to a Master node.
I have created VM instances from the web UI. In order for this to work, we would need to use Azure API to bring servers up and shut them down once they are done.
Does anyone have any experience with something like this? I am looking for advise, gotchas etc.
thanks.
You sure can do it and I have helped other to make it happen on hundreds on nodes. Take a look at Windows Azure Rest API to configure your role as described here. While others may have other idea, I think the general steps would be as below:
Create a master machine or a webrole to manage your roles using REST API
Create a worker role instance and use it to clone multiple instances as if needed
Use REST API to start and shutdown worker role along with update the instance count when in need
Use Azure Boot Strapper to bootstrap the VM depend on your requirement
Azure REST based Service Management API can work from a web app or a standalone app, so you can also have a web role to make it happen from anywhere in world. This way you don't need any on premise components at all as it will be totally cloud solution. If you need any help on creating web role I sure can help.
You can provision Virtual Machines using Service Management REST API (there's also a managed API on NuGet).
But in your case you might want to consider using Cloud Services (PaaS). With Cloud Services you simply build your application, you package it and deploy it. Then using the portal or the management API you can simply configure the number of instances. There is even a command line tool (csmanage.exe) which allows you to to change the number of instances through the service configuration.