Microsoft just sent out an email notifying our company that there will be scheduled maintenance for our Windows Azure environment.
We will be performing maintenance on our networking hardware. We are
scheduling the update to occur during nonbusiness hours as much as
possible, in each maintenance region. Single and multi-instance
Virtual Machines and Cloud Services deployments will reboot once
during this maintenance operation. Each instance reboot should last 30
to 45 minutes.
We suggest using availability sets in the architecture to protect
against downtime caused by planned maintenance. This maintenance will
proceed by updating instances in only one Fault Domain (FD) at a time
for the Cloud Services and Virtual Machines in an Availability Set.
Now our website consists of a Cloud Service with 8 (small) instances of a web role. With these 8 instances, is there still a possibilty of downtime for the website? Do we need to use 'Availability Sets' or are we safe? Thanks for any info..
Depends on which service you're referring to. From my understanding, because you mentioned "Web Role", you're talking about Cloud Services (PaaS).
In General:
If you have Cloud Services (PaaS), which is what you have based on my understanding, then you won't have any downtime, no.
If you have VMs (Virtual Machines) that don't belong to the same Availability Set, then there is a chance of downtime. To fix that, just make sure they are on the same Availability Set. If you don't have VMs, ignore this.
Hope it helps.
Related
I have a Linux Standard B2ms azure virtual machine. I have disabled the autoshutdown feature you see in your dashboard under operations. For some reason this server was still shutdown after running about 8 days.
What reasons are there which could shutdown this server if I haven't changed anything on it the last three days?
What reasons are there which could shutdown this server if I haven't
changed anything on it the last three days?
There are many reasons will shutdown this VM, maybe we should try to find some logs about this.
First, we should check Azure Alerts via Azure portal, try to find some logs about you VM.
Second, we should check this VM's performance, maybe high CPU usage or high memory usage, we can find logs in /var/log/*.
Also we can try to find are there some issue about Azure service, we can check service Health -> Health history to find are there some issues in your region.
By the way, if we just create one VM in Azure, we can't avoid a single point of failure. In Azure, Microsoft recommended that two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA.
An availability set is composed of two additional groupings that protect against hardware failures and allow updates to safely be applied - fault domains (FDs) and update domains (UDs).
Fault domains:
A fault domain is a logical group of underlying hardware that share a common power source and network switch, similar to a rack within an on-premises datacenter. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these fault domains. This approach limits the impact of potential physical hardware failures, network outages, or power interruptions.
Update domains:
An update domain is a logical group of underlying hardware that can undergo maintenance or be rebooted at the same time. As you create VMs within an availability set, the Azure platform automatically distributes your VMs across these update domains. This approach ensures that at least one instance of your application always remains running as the Azure platform undergoes periodic maintenance. The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time.
In your scenario, maybe there are some unplanned maintenance events,when Microsoft update the VM host, they will migrate your VM to another host, they will shutdown your VM then migrate it.
To achieve a highly available, maybe we should create at least two VMs in one availability set.
When Azure shuts down a VM for planned maintenance, what messages do running services see, if any?
For example, do they get a ServiceBase.OnShutdown() message and, if so, how long does the service / server get to complete shutdown processing?
Does MS give any extra leeway to its own apps? E.g. if a VM is running SQL Server, will Azure wait for SQL Server to stop cleanly before shutting down the VM?
[I can't find this in the documentation and, unfortunately, I don't have the access or the programming skills to try it out for myself.]
what messages do running services see, if any?
Based on my knowledge, for now, Azure does not support this. Please refer to this feedback.
Typically maintenance is performed at weekends for VMs not in an availability set to minimize impact on services. Normally notification is given 7 days in advance with the minimum being 3 business days. A start time for the maintenance is given with the expected duration. More information please refer to this link.
According to your description, I suggest you could provision another IaaS VM with your SQL server and put in the same Availability set. By doing this, Azure will ensure that both your VMs do not go down simultaneously.
I have worker role on azure, but want to make sure that it can now follow microsoft SLA of 99.95% availability.
My assumption, If I go to portal and increase the instance count to 2, it would be sufficiant.
But this wording on
http://azure.microsoft.com/en-us/support/legal/sla/
For Cloud Services, we guarantee that when you deploy two or more role instances in different fault and upgrade domains, your Internet facing roles will have external connectivity at least 99.95% of the time.
What exactly does different fault and upgrade domain signify here?
and do I need to perform any additional steps to guarantee SLA
See here for a good explanation of Azure Fault Domain and Upgrade Domains. When you deploy your worker role to two instances they'll automatically be allocated to different update and fault domains so your cloud service will be supported by the SLA. There's nothing extra you need to do.
We are working on architecture of new web application to be hosted on Azure. This application would run only in day time (Say 9AM to 5PM). What I read so far about Azure is we would continue be billed even when we stop the deployment.
However in case of Azure VM (IAAS) billing stops when we stop the VM.
Client is keenly interested in running the IT cost to the minimum. We are planning to use WASABi/Auto-scaling block to auto shutdown & auto-start the app to run only during (9AM-5PM)
Deploying application every morning & deleting every evening even programmatically doesn't sound like a good architecture.
Should we target the app for VM rather than Azure web role?
While hourly billing cost is definitely a consideration and it is true that if you stop a VM in IaaS, billing stops, there are other considerations as well. Some of them are:
With Cloud Services, you have to architect the application in a certain way to take advantage of statelessness there. So there may be a bit of a learning curve there. With Virtual Machines, in theory you can build an application the way you are used to and deploy that in the cloud.
With Cloud Services, the major advantage is that you don't have to maintain the VM. This is something Microsoft does that for you. So there's little or no IT-admin overhead. With VMs, maintaining the VM is your responsibility so that's an additional cost which is recurring as well (assuming you (or your client) have an IT Admin kind of guy on the payroll).
Generally speaking, if the application is a stand-alone application with quite simple deployment topology and is brand new application it is recommended that you write them as Cloud Service but do take the costs (development / IT admin) into consideration as well.
When you stop the virtual machine through a standard shutdown (through the machine itself for example), it does continue to incur charges. The portal will eventually show it as shutdown, but the VM still has resources allocated.
However, if you stop the machine through the portal, API, or PowerShell, it will stop and DEALLOCATE the machine. This means the VM will use storage space, but will not incur compute charges.
Simply schedule the deallocation of the machines during off-hours, and you will only page for the usage during the day.
How to autoscale virtual machines(IaaS approach) in azure instead of web/worker role autoscaling in azure?
You can now Autoscale Virtual machines in Azure directly in the Azure Management Portal. ScottGu has a post about it on his blog.
The important thing to autoscale VM's is you must proactively provision the Max # of VM's you think you'll need to handle your peak capacity, and add them to the same availability set.
For example, if on the busiest day of the week it takes 6 machines to handle all of your traffic, then you need to create 6 instances and install your application on it, configure it to handle traffic etc.... and then add it to an availability set with the other 5 machines.
Once you've done this, you can navigate to the Cloud Service that contains all of your virtual machines and click on the Scale tab. You should see a list of your availability sets, and it should tell you the # of machines you can scale over. Choose a metric (either CPU or Queue today), and then range of machines you want to scale between. You can scale between 1 and the total # of machines.
When load is low -- Azure will turn off machines (so you don't have to pay for them), and when load is high, Azure will turn those machines back on.
Auto-scaling on the IaaS level doesn't really make sense. Even if azure could detect high CPU usage and start a new VM based on it, what then? you still need to install your application on that VM automatically somehow.
What you are looking for is something that runs your app on azure, and installs new instances on new VM's if necessary. That "something" is called PaaS enabler. Basically it is another abstraction level between your app and the azure IaaS.
there are a couple of them out there :
Cloudify, CloudFoundary, Juju
as far as i know, only one that supports Azure is Cloudify. you can check out how to configure azure using Cloudify here : Configuring Azure
you can also check out the community - Cloudify Forum, or post questions here for assistance.
Disclaimer: I work for Gigaspaces, developing the Cloudify product line.
According to this it's possible to scale out IaaS with Availability sets by pre-provisioning the number of boxes: https://blogs.msdn.microsoft.com/kaevans/2015/02/20/autoscaling-azurevirtual-machines/