am new to windows azure. I recently set up a vm and host a website, according to the SLA i need to have 2 VMs in the availability set. Now i did set up the second VM.
My questions what do i need to use the second VM for?
if i setup load balancing does azure redirect user to the second VM? this second VM has nothing in it.
Please i will like to know this and is it possible to replicate the content of the first VM to the second one, so each time the first one is down the second VM can take over.
Thanks
At first, You must understand the statement of minimum two machines to get 99.95% SLA. It is not about "reserving" resources for use in case of fault or update (fault domain and update domain in availability set). Your application must be created as multi-tenant, so You need to run Your application on two servers, connected to the availability set. You can synchronize storage with GlusterFS (if You use Linux) or other distributed file system. You also can use Azure Files service (SMB as a service) to share storage. For sharing DB (in example MySQL) You need a cluster (independent or distributed through Your two machines).
So... You must to start think in "cloud way" instead of typical one VM administration.
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.
I have few (around 10) Windows Services on my existing environment. We are planning to migrate to Azure with the following.
Host our database on Azure SQL Database.
Install all the 10 Windows Services in a Azure Virtual Machine. Please note that these Windows Services does bulk inserts into the Azure SQL databases.
Take 2 instances of VM (specified in #2 above) and configure them in an Availability Set to avail the SLA.
I have two questions.
Do I need to install all my 10 Services to both the VMs?
Will that NOT be reduntant running the Windows Services in both the VMs? So, the Bulk Inserts will be duplicated to the Azure SQL Databases.
Please let me know if I am thinking in the right direction or are there any alternate methods (like Worker Roles) of utilizing the existing Windows Services on Azure with minimum or no changes?
It looks like, I got an answer to my question. When there are two VMs in a given Availability Set, ONLY one will be up and running. The other VM will come into picture only when the primary VM is down.
Thanks,
Prawin
If you are to take advantage of Azures SLA you will need to have at least 2 VM's (from within the same family) in an availability set. The SLA covers the VM's in the availability set NOT what you are running on the OS. For example if you have all services running on one instance and that box goes down, you lose those services till the box recycles. Microsoft is still covered on their SLA because at least one of the VM's in the availability set is available.
I just created a standard vm inside Azure, and created a new Availability set.
I created another vm, with the same specs, in the same region, but when I go to configurare the availability set I don't see it in the list.
I'm missing something?
Luca
So... just posting this as an answer, to properly close the loop based on the comments under the question:
When setting up a Virtual Machine, you can choose which Cloud Service to place the Virtual Machine in. The Cloud Service is essentially a container which gets assigned a specific IP address, gets a cloudapp.net name (e.g. myservice.cloudapp.net), and gets assigned to a region (or affinity group, which is region-specific).
Availability Sets are specific to a given Cloud Service. You may place any of your Cloud Service's VMs in the same Availability Set (or even have multiple Availability Sets, with groups of VMs assigned to specific Availability Sets). However: An Availability Set does not span across Cloud Services.
So: When you went to set up your second Virtual Machine, and you didn't see your Availability Set, that is because you were attempting to deploy to a different Cloud Service.
Below screenshot shows the wizard page where we can select existing cloud service to which we can associate a new VM
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/
I would like to achieve a high-availability scenario on two VMs in Azure.
I understand and can follow the directions here:
https://www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/
However, my question is this: are the two VMs supposed to be exact replicas of each other, so that when one goes down, the other takes over? Or does the Availability Set look after this, so that the two VMs can have totally different content and still utilise each others' free resources?
If you're working with Virtual Machines (currently in Preview), then each VM lives in its own VHD. You can make additional instances by creating a VM from an image you build, but at that point, the new VM lives in its own VHD and the actual disk image will then deviate from any other instance as time goes forward. Of course, if each VM is created from the same image, with the same initialization tasks, etc., then they'd have the same software as well. You'd be responsible for upgrading software versions on all the VMs. If you then put these multiple Virtual Machines in an Availability Set, you'd be assured that the Host OS (underlying OS at machine-level) for the VMs you have would not be updated at the same time. You'd also know that different VMs in the Availability Set would be situated in different racks, network segments, etc.
More on Availability Sets: Within an Availability Set, you may have any variety of Virtual Machines - Linux, Windows, different functionality. And... you may define more than one Availability Set.
In the PaaS world, where you set up a Cloud Service with Web and/or Worker roles, those VMs are spawned the exact same way. So adding instances means adding more of the equivalent VMs. If the disk crashed, a new VM would be created just like the others. There are no persistent changes to those OS disks. In the case of Cloud Services, there's fault domains and upgrade domains, which are very similar to availability sets.