FYI, Azure runs Linux but does so on a Windows host.
Whenever Windows needs a security update, it has to be rebooted.
This means you need to plan for your Linux VM to go down weekly.
Whenever Windows needs a security update, it has to be rebooted.
This means you need to plan for your Linux VM to go down weekly.
Azure uses HyperV[1] as their virtualization technology. That isn't the same as Windows at all, although it is included in Windows Server.
While I have had more reboots on Azure than on AWS, it isn't weekly by any means - more like every 3 months or so. It hasn't been often enough for it to be a problem (low usage environment though, so YMMV).
[1] http://en.wikipedia.org/wiki/Hyper-V#Microsoft_Hyper-V_Serve...
However, each physical machine also runs an Azure Host Agent, which runs on top of Windows Server Core. While the use of Server Core helps cut down on reboots, it doesn't eliminate them.
But then, why doesn't Hyper-V just stay up while it reboots the VM containing the Host Agent? Because the virtual disk drivers are implemented for Windows Server. (Hyper-V has the concept of a management OS, which has privileged access to the hardware.)
Source: http://blogs.technet.com/b/markrussinovich/archive/2012/08/2...
That's a pretty serious disadvantage over VMWare.
But I guess the limited attack area of Windows Server Core means many people can avoid applying patches much of the time.
By hooking up Hyper-V to the Windows management OS, they get to leverage Windows device drivers. And this, in turn, ensures broader hardware compatibility.
Of course, this goal became unnecessary for Azure, where Microsoft controls the hardware. But Hyper-V had already been designed that way.
Certainly, Server Core is pretty stripped-down. The Russinovich blog says they reboot about once a month, but the Azure support blog says they reboot every 2-3 months.
http://blogs.msdn.com/b/wats/archive/2013/09/24/windows-azur...
"When this occurs, you loose connectivity..."
"While this type of proactive notification of planned maintenance is not currently provided, we encourage you to provide comments on this topic so we can take the feedback to the product teams."
Wow. They didn't notify at one point?
Edit: Looking back at my email history, it's much less often than that. The interval between the previous two reboots was 6 months. They also gave about two weeks notice when it happened.
The primary workload we were running was video game servers. The server stores all state ephemerally in RAM tied to the process. When it goes down, that play session is over and all players are booted. This was just a constraint of the software that we had to live with.
What I was looking for was some kind of heads up so that I could at least try and take down the process gracefully, but that wasn't possible.
As said, this was a while ago. Hopefully the situation is now different.
In practice, though, I often found myself getting annoyed that I had that enforced on me. On AWS or most other providers I've used, if you have a workload that isn't particularly mission critical you can get away with just expecting the machine to always stay up. It'll probably only go down once a year or so. Obviously not the best way to design a system, but a handy tradeoff to be able to make in order to save a little cash or complexity.
You have a cluster running, that does some work at certain times in a day. Out of the blue, Several machine would be "re-imaged" and that means it would delete all the logs, working directories etc.Its like a snapshot restore. So when this happens, you have lost any custom changes you had done on the cluster. You lose any 3rd party jars you had placed.
Those machines, join back your cluster and your jobs would no longer run because of missing jars Unless you program to download all files on every reboot.
Most important thing though is lack of prior notifications. I have had cases when a "re-image" happend when my CPU was 100% utilised and my RAM was used 90%. So my box was working on something and azure decided to apply a patch!!
As per frequency, its once every two weeks, sometimes more.
I haven't noticed any serious downtime on Azure for this reason. Probably 1 reboot in the last few months, with plenty of notice (and a fairly specific timespan).
So far, I had no issues regarding downtime at Azure at all. All downtimes were as stated in their policy.
Virtual PC supports live migration. Seems like an easy way to do maintenance on the hosts. Does azure use live migration ?
If users will favour GCE because of reduced downtime support due to the live migration support (or simply favour GCE because of they perceive it as a more advanced platform), then other providers will follow.
Right now it seems that it's all a price war, not yet a feature war. But prices can go down only to a point, then feature war will start showing it's effects, and it will be interesting.