we have created azure durable function with timer trigger. We are not using Azure front door. Currently, function is deployed at east US2 & Central US region with Active -Active configuration.
Here problem is, both functions are executing and processing same data twice which is incorrect. I want to setup this configuration as Active-Passive but how it should be architect?
There is no out-of-the-box solution for this. You have to synchronize the work yourself by setting a lock for example, preventing the other timer from doing work when the work is already done. Or you disable the timer trigger function in the failover region, which means that in case of a failover you need to enable them yourself. Of course you could script that.
See also this blogpost describing the solution contained in this answer.
Related
I want to run a fully redundant failover environment in Azure. I have my webapps covered with an Azure Traffic Manager. I can run my storage queues in two different accounts. All is covered. The only thing I can't figure out is how timetriggers should be handled? I can't have them fire in both regions. Does anyone here have an idea or solution I could try?
Time triggers will run only instance at a time even though you have configured for multiple instances scale out. The timer trigger uses a storage lock to ensure that there is only one timer instance when a function app scales out to multiple instances. If two function apps share the same identifying configuration and each uses a timer trigger, only one timer runs.
I am using Azure Functions V2 with a Service Bus trigger using 1.0.23 of the C# Functions SDK. I'm using the following approach to get secrets from KeyVault and use them within the settings of the triggers: How to map Azure Functions secrets from Key Vault automatically
The function, especially when it has done nothing for a while, doesn't fire when there are messages on the subscription. If I then go to the portal and execute manually (yes, that particular execution is fired with a null message) it kicks it into life and picks up the other messages on the queue and processes them correctly.
This obviously isn't ideally for our automated tests. Has anybody seen this, or know of anything that will help?
Also, the Function App is running on a consumption plan.
App Service Plan
If you're using App Service plan then it's simple, just make use of Always on
Consumption Plan
If you're using Consumption plan, the issue could be that your triggers did not sync properly with the Azure Infrastructure (Central Listener). It could have happened due to the way you deployed/edited your trigger related settings as explained in issue #210 below.
When you access the function directly from Portal, it might be forcing your function app to come alive, but as you can see that's only a workaround. Something similar is mentioned here
Take a look at these issues:
Service Bus Topic Trigger goes to sleep - Consumption Plan
They also mention that it wakes up only on accessing it via the portal or calling a HTTP triggered function in the same app, which is similar to the behavior you are seeing.
Issue #210
Issue #681
There are 3 suggested ways to resolve it, mentioned as part of Issue #210 above
In order to synchronize triggers when these deployment options are
used, open the Azure Portal and click the Refresh button, or make a
API call to the sync triggers endpoint:
https://github.com/davidebbo/AzureWebsitesSamples/blob/master/ARMTemplates/FunctionsWebDeploy.json#L90
Powershell sample:
https://github.com/davidebbo/AzureWebsitesSamples/blob/master/PowerShell/HelperFunctions.ps1#L360-L365
I've had a similar issue. ServiceBus connection was injected using ServiceBus value in ConnectionStrings section of Function configuration. This is enough when Function is in hot state but after transitioning to cold state AzureWebJobsServiceBus value is used to connect to service bus. So in my case setting AzureWebJobsServiceBus to ServiceBus connection string in Function configuration fixed this.
We currently have a window service which send some notification emails to users after doing some processing on database(SQL database). Runs once in day.
We want to move this on azure cloud. One alternate is to put it on Azure VM as is. but I am finding some other best possible solution for that.
I study about recurring and on demand Web jobs but I am not sure is this is best solution.
Also is there any possibility to update configuration of service code in App.config without re-deploy the code of service on cloud. I means we can manage configuration from Azure portal.
Thanks in advance.
Update 11/4/2016
Since this was written, there are 2 additional features available in Azure that are both excellent choices depending on what functionality you need:
Azure Functions (which was based on the WebJobs described below): Serverless code that can be trigger/invoked in various ways, and has scaling support.
Azure Service Fabric: Microservice platform, with support for actor model, stateful and stateless services.
You've got 3 basic options:
Windows service running on VM
WebJob
Cloud service
There's a lot of information out there on the tradeoffs between these choices, but here's a brief summary.
VM - Advantages: you can move your service basically as it is without having to change much or any of your code. They also have the easiest connectivity with other resources in Azure (blob storage, virtual networks, etc). The disadvantage is you're giving up all the of PaaS advantages and are still stuck managing your own VM infrastructure
WebJob - Advantages: Multiple invocation options (queues, blobs, manually, queue receive loops, continuous while-loop style, etc), scheduled (would cover your case). Easy to deploy (can go with website, as a console app, automatically through Kudu), has some built in logging in Azure portal - and yes, to answer your question, you can alter the configuration in the portal itself for connection strings and app settings.
Disadvantages - you'll need to update code, you don't have access to underlying resources (if you need that), and more of something to keep in mind than a disadvantage - it uses the same resources as the webapp it's deployed with.
Web Jobs are the newest of the options, but at the same time appear to have active development going on to increase the functionality and usefulness.
Cloud Service - like a managed VM, has some deployment options, access to underlying VM if needed. Would require some code changes from your existing service.
There's nothing you've mentioned in your use case that makes me think a Web Job shouldn't be first thing you try.
(Edit: Troy Hunt has a great and relatively recent blog post illustrating most of the points I've mentioned about Web Jobs above: http://www.troyhunt.com/2015/01/azure-webjobs-are-awesome-and-you.html)
I'm working on an automation tool whereby I need to trap events that are occurring within an Azure subscription.
Taking an Azure VM as an example - how can I trap a shutdown event for a single VM so that for example, a web service is called?
Azure Scheduled Events (in Preview at time of post) is your best bet. This is built upon the Azure Instance Metadata Service (also in Preview at time of post) which surfaces historic and up-coming information from within the VM, allowing you to proactively react to events.
To my knowledge, there's no way to monitor for events such as this from outside the VM, however this article provides some great code examples which could be run from within the VM that you could use to trigger an alert/action outside the VM if you needed to.
A very simple question:
Why would someone use the Azure Scheduler if Azure WebJobs are free?
I couldnt find any topic regarding "azure webjobs vs azure scheduler"
The main difference is that the webjob contains everything that the scheduler can do:
Scheduler can make HTTP calls
WebJob can do that and more (run SQL commands, etc)
The actual scheduling bits of WebJobs are built on top of the scheduler. When you set up a Web Job on a schedule under the hood it uses the scheduler to kick it off. WebJobs provides a nice little location to host the code that gets executed. In fact, if you create WebJobs for a web site look in the Scheduler on the portal and you'll see them listed there as well.
Also note that the scheduler could call out to other systems not running Azure. If you have something running in a Cloud Service that needs to be called regularly, or even if something was hosted elsewhere (another provider or on premises) the scheduler is where you can set that up.
Regarding the cost aspect, there is a free tier to the scheduler as well: http://www.windowsazure.com/en-us/pricing/details/scheduler/.
It's 2016. The below answers are no longer accurate.
WebJobs now also has a built-in scheduler and the schedule can be defined by a cron expression.
When publishing to Azure, you can choose if you want to have the WebJob sparked off by the Scheduler or by the WebJob internal scheduler.
Important Note: The Azure Scheduler has limits to frequency of either 1hr or 1min depending on if paid or not. For the internal scheduler however, your App Service requires Always On to keep on running and firing off the job. This Always On status may affect your pricing.
Continuous jobs are monitored, and if they exit they are re-executed. In this way they act more like "services" in your local machine. There is a module that monitors and keeps your app working. Always-ON is a feature that will help your site stay alive and hence, your webjobs to continuously run.
Scheduler is used to trigger the webjobs. It uses the scheduler user account (not the back-end account). This way you can move out of the free tier for scheduler, sign up to higher tiers to suit your needs. But essentially, all the scheduler is doing is hitting an https endpoint (which is public, but required your auth).
Triggered jobs (scheduled and on demand) are invoked by an https call. These calls are load balanced - much in the same way that a web app with many instances is load balanced. Continuous jobs run concurrently by default, but can be set to be a singleton.
For Webjobs starting from version 2, there is no reason to use an Azure Scheduler anymore. As a matter of fact, the Azure Portal already flags this functionality as (Legacy).
From WebJob SDK v2 additional triggers have been introduced and one of them is TimerTrigger, which works with CRON expressions to schedule executions. This execution mode does not need any additional Azure construct, you just need the webapp to be set as AlwaysOn to guarantee the webjob to run.
Another azure service that works with TimerTriggers is Azure Functions, which is built on top of the WebJob SDK that allows a serverless execution.