How can I schedule my Hosted Service to shut down at night?

Question

I recall watching an MSDN video that talked about the features of Azure, one of them being that you could schedule the environment to "shut down" or pause during a scheduled time so that you aren't incurring costs during that time.  For example, if you know your development team leaves the office at 7PM and doesn't return until 8AM, you could shut things down during that time window.

Is this possible?  If so, how do I configure it?

Answer 1

You could make use of PowerShell Cmdlets to write a process which will delete your deployments at predefined time. You can either use Cmdlets provided by Microsoft (http://wappowershell.codeplex.com/) which are free and open source or you could use Cmdlets developed by us (http://www.cerebrata.com/Products/AzureManagementCmdlets) [Sorry for product plug :)].

We wrote a blog post some days back which uses our cmdlets to check the status of a hosted service (http://www.cerebrata.com/Blog/post/A-Simple-Windows-Azure-Hosted-Service-Deployment-Status-Tracking-Solution-Using-Cerebrata-Azure-Management-Cmdlets.aspx). You could basically write a PowerShell script similar to what we have written in the blog post which will check the current time and if the current time is 7:00 PM, it will call cmdlet to delete a deployment. In the same script you will call cmdlet to create the deployment if the current time is 8:00 AM. 

Both of the Cmdlets make use Service Management API so if you wish to write your own code, you can write C#/VB.Net wrapper around that API. The function you would want to use is Delete Deployment (http://msdn.microsoft.com/en-us/library/windowsazure/ee460815.aspx). You may also find this blog post useful as well: http://sanganakauthority.blogspot.in/2011/11/windows-azure-service-management-api-to_08.html.

Hope this helps.

Thanks

Gaurav Mantri

Cerebrata Software

http://www.cerebrata.com

Answer 2

Thanks, Gaurav, but I definitely don't want to delete my deployments and then have to recreate them.  I could have sworn this was a feature of Azure but I can't seem to find it.

Answer 3

Unfortunately the only option available to you is to delete deployments and recreate them if you don't want to incur charges during period of inactivity. Merely suspending the deployments will not help you. A few things you could do assuming this deployment is for your development team:

- Choose extra small instances to deploy your application. You will be charged $0.02/hour/instance.

- Reduce the number of instances to say 1 during off hours. This will certainly lower your bill during period of inactivity.

Hope this helps.

Thanks

Gaurav

Answer 4

Hi,

This thread makes me think on how I use my instances for high availability, yet lower cost.

Our Learning Management system is TYPICALLY used during day time (I cannot define this, nor am I assured of this). However, most of my 11000+ users could be using it between 0800 - 1900, while the application admin users could be using it until 2200 also.

Given that most of my users are in one time zone (India), I'm more or less assured that people dont stay awake late into the night to use it :)

We have been using only one small compute instance so far, and we're about to go by the rule book and use at least 2 instances - for higher availability. (I track performance of my compute instance using Opstera and the CPU usually hovers around 15-16%)

Here're my options

1) I could configure to use minimum of 2 small instances (only because it is recommended). In such a case, if I opt for the second instance also on a commitment-based pricing, I'd get a 20% discount on the second instance also. But, I'm still willing to bet that my application is UNUSED right through the night

2) I could configure to use minimum of 1 small instance. Configure auto-scaling to scale up to 2 instances if my CPU goes up beyond, say, 30% for over 15 min; scale down to 1 instance if my CPU goes below 10% for over 15 min. Sounds like I can have higher availability and higher CPU & memory during the day, and hopefully not pay for the non-usage at night

Any flaw in this idea?

Regards,

kk

Answer 5

One thing you must take into consideration when using just 1 instance is that your instance could go down any time without any prior notification. It could very well be because Microsoft decided to apply a patch and that resulted in your instance going down. This would leave your users high and dry without access to your application  :). IMHO, you must always run 2 instances of your application just for this reason only. Further more, I noticed noticed one thing: Let's say you are running 1 instance of your application. Now you scale to 2 instances. For some time, your 1st instance will go down. However increasing from 2 to 3 (or any higher number) will not result in any instance going down. This has something to do with the load balancer.

Another thing you might want to look into is running more X-Small instances. I haven't done any load testing but from the cost perspective you could run 6 X-Small instances ($0.02 / hour / instance) for the price of 1 Small instance ($0.12 / hour / instance). So for the same price you get better availability. Obviously the disadvantage in running an X-Small instance is that you don't get a dedicated CPU core.

Also I have attended a few sessions on availability where it was generally recommended that you run more instances of smaller size VM instead of lesser instances of a larger size VM if your application can afford it (i.e. it is not compute intensive requiring better VM capabilities in terms of CPU/RAM per instance).

Hope this helps.

Thanks

Gaurav

 

Answer 6

Thanks Gaurav!

1) I didnt consider the 'down-time' during scaling up from 1 instance to 2 - thats an interesting pointer - is that a documented fact, or is that your experience? If the scaling up from 1 to 2 instances is when the CPU load is at 30%, it may not be a single user who gets impacted, is more likely to be many! :(

2) I like the '6 XS at the price of 1S' proposal - in an XS, apart from shared CPU, even memory is less than half of that of a small instance - any guesses on how the performance could reduce for a user? Our application cannot be called compute-intensive - it is RDBMS-backed, OLTP application for most part!

Regards,

kk

Answer 7

1) I didnt consider the 'down-time' during scaling up from 1 instance to 2 - thats an interesting pointer - is that a documented fact, or is that your experience? If the scaling up from 1 to 2 instances is when the CPU load is at 30%, it may not be a single user who gets impacted, is more likely to be many! :(

It is not documented. It was first reported by one of our users and we were able to successfully simulate it both on the portal and in our tool as well.

2) I like the '6 XS at the price of 1S' proposal - in an XS, apart from shared CPU, even memory is less than half of that of a small instance - any guesses on how the performance could reduce for a user? Our application cannot be called compute-intensive - it is RDBMS-backed, OLTP application for most part!

Unfortunately, I could not find any study regarding this. I made the statement about choosing smaller sized VMs based on the information I gathered in some of Windows Azure related events. You may want to try it in your staging environment.

Answer 8

Once again, thanks Gaurav!

down-time during scale up from 1 to 2 instances - is that in the order of 1-2 seconds / 10-15 seconds or more?

Also, may I assume that the down-time is merely the time when the user requests dont reach the server, and not really a time during which the application server is really down?

Let me also experiment with our QA environment.

Regards,

kk

---

Regards, kk

Answer 9

You're welcome KK. In our experience we found it to be around 30 seconds+ during that time if you hit the website you get the favorite "Page Cannot Be Displayed Error" :). I agree that you should try and do this in your QA environment to measure the impact.