There has been a previous question on this and the accepted answer was Azure Elastic Job agent. The problem I have is that the feature is in preview and it still lacks a lot of functionality like diagnostics and alerting. I also find it to be very unreliable as job get randomly cancelled because of service restarts.
Azure Automation Accounts also works, but it only has a execution/running time of 3 hours. So if your maintenance takes more than 3 hours, this is not an option.
I have previously developed my own application for doing this, but the maintenance and management of this can become a headache.
Another alternative could be to just leverage Azure Data Factory perhaps, but this is a route I have not yet followed.
So what are people actually using to do long running maintenance against Azure SQL Databases that has enough diagnostic information in case something goes wrong and has at least some level of alerting?
PS: The database I need to do maintenance on is not small.
Related
I am planning to migrate my Azure resources from EA type of subscription to C-S-P subscription. I found a tool called as Migrate Azure(sorry cannot write the short form as this does not allow me to post). I am aware of its working, however i am just worried about one that.
Can the migration cause a downtime into any working of any resources like Azure Virtual machine, storage...etc. Point is i will be directly working on the production resources to migrate to the C-S-P subscription.
Can anyone give me an idea ?
As indicated by #HariHaran, you should follow the documentation mentioned in here
The subscription switching should not affect your workloads, since it's a subscription migration and not workload related(Assuming that all of your resources already reside in Azure). The safe approach to follow during your migration process is to do it incrementally. Then if all functions as normal, increase the migration rate. Do it all at once may not be the best. Redeployment issues can occur at times.
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)
We use the Northern Europe Azure Data Centre. We use SQL Azure Web Edition with Websites. Today we seem to be getting quite a few SQL Azure disconnections with error code 10054:
Symptom:
A transport-level error has occurred when receiving results from the server. An established connection was aborted by the software in your host machine
Mitigation:
Implement retry logic in your application
What is frustrating about this is that I cannot find any MS Azure Alerts to an issue. I suspect their SQL Azure systems will be ringing alarms. I have looked in Azure Status and Management Services.
Are there other places I can looks for these alerts, and also what is the best way to notify MS that there is an issue.
Finally how are folks monitoring SQL Azure for issues, throttling, disconnects etc? I have come across cotega.com.
P.s as a side note, I do understand the importance of putting in "retry logic", and but cannot happen quickly, and my code could be improved in this respect. However something does seem wrong with SQL Azure today. Up until now, the service has been by and large great.
EDIT 1:
Error Code:
Error Number:10054,State:0,Class:20
EDIT 2:
I think the moral of this story is to not underestimate the impact of throttling and scaling out, rather than scaling up, of SQL Azure services, and the importance of implementing retry logic/ MS Transient pattern logic. Still, this variable performance is a little frustrating, but perhaps this is the cloud for you, although with the new Data Tiers you can pay for more predictability.
EDIT 3: Interestingly SQL Azure is not performing more efficiently with no errors being noticed. So an issue with Azure. However difficult to identify apart from application error logs. I use Elmah.
Reconfigurations happen when upgrades are rolled-out to the service or when databases are load-balanced to avoid noisy neighbor issues.
The view sys.event_log in the master DB has information on why the disconnects happened (reconfiguration vs. throttling, etc.).
Service outages are reported in the portal.
I have got two database (SQL azure) in North America, I'm getting error that the applications can't Access to the server.
I didn't update the application or database, so I supose that there are a problem with sql azure service. How can I notify Microsoft of this problem?
To 'notify' Microsoft, you have very limited options.
They have their own support forums.
They have their own support ticketing system, that costs a pretty penny but is the fastest way to get their attention.
They have their dashboard, which in my own experience is terrible. It is not a true representation, ever. The updates are very very late.
You also have StackOverflow - but there will be little that we can advise on if there is a problem on the Azure infrastructure side of life.
To help aid in your Azure support woes, I would suggest you get an account with Pingdom and get MetricHubs for your subscription. These will help in showing what goes down, when, how often, and for how long. It can help show if the problem really is in your application or not.
I would also ensure you have diagnostics set up, and log everything you can.
Many many people forget or don't know about the transient error problems. Microsoft have a huge article on it, but it does trip people up a lot.
The Azure Management Portal should also be able to give you a quick summary of if your roles & instances are actually up, healthy and stable.
What guarantee does Microsoft give to providing long term support for Azure? If Microsoft was to shutdown Azure how long would they keep the Azure cloud up and running? Has anyone regretted using a SQL Azure feature as it harmed their ability to move off of SQL Azure?
OK. A few questions there. Some can really only be answered officially by Microsoft but I'll take a stab at providing at least some detail for you.
1. What guarantee does Microsoft give to providing long term support for Azure?
Microsoft commit to providing at least 12 months notice for any disruptive change. This is set out in their Online Services Support Lifecycle document. http://support.microsoft.com/gp/OSSLpolicy
2. If Microsoft was to shutdown Azure how long would they keep the Azure cloud up and running?
Per the above. I would consider that a disruptive change and expect them to provide a minimum of 12 months notice.
3. Has anyone regretted using a SQL Azure feature as it harmed their ability to move off of SQL Azure?
There are very few features that are only available in SQL Azure. IN terms of shipping features I can only think of Federations off the top of my head. It's a unique feature in that it's only somewhat interesting for on-premise deployments as you don't typically have elastic capacity on tap on premise and you can probably take other approaches such as a monolithic DB server + storage partitioning to solve your problems. In short I haven't had such regrets.