We have a standard 3 tier web application that need to be migrated into cloud (more of VM based lift and shift instead of cloud native at this point).
Wondering which factors should I consider to make a decision if Azure Scale Set or Azure Availability Set should be used for Web and Application tiers.
Probably answer to questions like:
Can availability set autoscale like Scale set?
Any overhead of using either option for a simple web application?
Will both need load balancer in front of them ?
Might help to take a decision.
Any suggestions please?
You can refer to the N-tier architecture on virtual machines. Each of tier consists of two or more VMs, placed in an availability set or VM scale set. The load balancer is used to distribute requests across the VMs in a tier. Each tier is also placed inside its own subnet, and add NSG rules to restrict access to each tier and route tables to individual tiers.
For your questions:
No, The main difference is that a Scale Set have Identical VMs which makes it easy to add or remove VMs from the set whereas an Availability Set does not require them to be identical. An availability set is spread across fault domains that shared a set of hardware components, which means when you have more than one VM in different fault domains in a set it reduces the chances of losing all your VMs in event of a hardware failure in the host or rack. A regional (non-zonal) scale set uses placement groups, which act as an implicit availability set with five fault domains and five update domains. Refer to this question.
It's recommended to use VM Scale Sets for autoscaling. VMSS can automatically create and integrate with the Azure load balancer or Application Gateway.
Yes, both need Azure LB in front of them.
Generally speaking, both scenarios do not offer any way to magically make this happen, so you are kinda forced to use webapps if you want minimum overhead.
yes it can, but you need to prestage vms
yeah, you need to configure vms and for vmss you need automation so that scaling can happen automatically
yes, both will need a load balancer (web apps - not).
But your app might not work with webapps, so you are kinda forced to use vms or vmsses
Related
I am having difficulty understanding Azure Availability sets, specifically, what exactly i need to to do ensure my app running on my vm is utilizing Availability sets to be more available.
Lets say i am creating an application that runs on a single VM and i want to make it more resistant to hardware failure.
Option 1:
I create an Availability Set with 2 fault domains and then create a VM on this Availability set.
Is that it?
If there is a hardware failure on the rack hosting my VM, does azure now take care of ensuring the VM stays up and running?
Option 2:
i have to have two servers Vm1 & Vm2, both in the availability set but one on fault domain 1, one on fault domain 2.
i have to then set up a cluster of sorts for my application. In this case the availability set is simply allowing me to be sure that the two servers in my cluster are not on the same hardware, but the plumbing to ensure the application can take advantage of two servers and is highly available is still down to me.
Is option 1 or option 2 the correct way in which Availability Sets work in relation to fault domains?
Appreciate any clarity that can be provided.
Azure deals with hardware failure in two ways, Availability Sets and Availability Zones. AS is all about making sure that your app does not go down even if hardware failure happens within a Data center aka Zone itself. AZs are all about making sure your app does not go down even if the whole data center aka Zone is down. More details here.
Now to understand best practices around availability take a look at the best practices, specifically for VMs can be found here.
A Single VM instance is defined as follows, reference:
"Single Instance" is defined as any single Microsoft Azure Virtual Machine that either is not deployed in an Availability Set or has only one instance deployed in an Availability Set.
So one VM in or not in an availability set does not make any difference, for this you need at least two VMs and which are in an AS using FDs and UDs so Azure will take care of this by making sure that both VMs are running on separate Hardware to avoid your app going down.
One VM in an Availability set is nearly as good as a VM with no Availability set.
If you are placing two or more VMs in an AS and those are identical then you can add a load balancer to distribute traffic.
You can also use AS without a Load balancer if you are not interested in traffic distribution. One scenario can be where you want to switch to a secondary VM only when primary is unavailable.
Also, do understand it is not required to have identical VMs in an AS.
Virtual machine scale set is a good option if you are looking for a high availability solution with VMs.
Our issue:
The amount of time for provisioning a new instance takes a long time because of steps like certificate, encryption, domain join, TLS and Cipher changes,...
Solution:
In our use case, we end up to have two different VMSS for the purpose of deployment, re-imaging or blue green use case. Please note in our region (Azure Gov), we don't have access to low priority VMSS or Azure VM Spot to do pre-provisioning.
It only makes sense to have two different scales set behind a cloud-native load balancer (or private Traffic Manager - which is not available yet) to route request base on the VMSS prob readiness.
Ask:
How can we have two Azure Virtual Machine Scale Set behind a load balancer
I never tried this, but I dont see why this would not work with Standard Load Balancer (not basic, basic one is limited to 1 vmss, afair), if it doesnt - it should work with Application Gateway.
What is the difference between putting only one vm in availability set vs not putting the vm into any availability set?
What is the difference between putting one vm in availability set vs
not putting the vm into any availability set?
If only on VM in that availability set, there is no SLA for this VM, same as single VM without availability set.
I think the only difference it that, when this VM in availability set, we can create a new VM in this availability set to get HA. But a single VM without availability set, we can't add this VM to one availability set, if we want to add this VM to one availability set, we need recreate it(ARM).
In ASM(classic mode), we can add one VM to the availability set.
An availability set is designed to operate under a load balancer or an application gateway that distribute traffic among VMs. This helps to achieve high(er) availability (HA) than just a VM on its own (in case a VM goes offline or becomes unhealthy), or to distribute traffic for intensive applications by sharing the load across 2 or more machines. An Availability Set will also come with probes to detect unhealthy VM instances.
However, when you're dealing with one VM, are availability sets worth setting up? Short answer is no, unless you want to leverage the benefits of an application gateway which include: filtering & firewall, application level attacks and layer 7 benefits like SSL and session management.
If you're creating availability sets using ARM code for quick deployment (e.g if you had a production environment with multiple VMs), it does however make sense to deploy Availability Sets with one VM if you're repeating the same setup for test environments e.g. Dev and Staging environments may only use one VM within an availability set simply to preserve the same gateway architecture as your production environment.
Disadvantages of Availability Sets include not being able to easily restore to a VM backup into an availability set, as this feature does yet have a GUI. Restoring a VM on its own, much easier. And they involve a bit more architectural setup/design which is harder to replicate if you're not usimg ARM templates (code deployments).
I have one Website on Azure:
I use Standard tier so the autoscale is on. Do I need to set the metric by myself or there are defaults? For example: when the CPU is above 90%, a new instance will be turned on. Do I have to add this by myself?
I saw there are options for "Data In" and "Data Out". Can I use this as a load balancer so that I don't need to configure a separate load balancer?
Thanks!
Having your website in the Standard tier doesn't mean autoscale is configured. You still need to enable autoscale and configure the CPU target range for Azure to scale up/down the number of running instances.
Azure will load-balance requests to your running instances automatically so there is no need for you to "configure a separate load balancer".
The documentation on how to scale websites covers this topic in depth. It also shows you how to scale based on schedules if you have a need for that.
I am reading the explanation of Availability Sets on Microsoft' website but can't 100% understand the concept.
http://www.windowsazure.com/en-us/documentation/articles/manage-availability-virtual-machines/
There are many questions people ask in comments, but there is no technical support from Microsoft is there to answer them.
As I properly understand with availability sets you can duplicate your VM with IIS application and VM with SQL, which means you have to use 4 VM(pay for 4) instead of 2. This means that whenever IIS1 virtual machine is down, website will still be online with help of IIS2 virtual machine and vice versa? Same goes for SQL1 and SQL2 virtual machines?
Am I going to the right direction? If this is the case, how do I keep the data synchronized in SQL1 and SQL2, IIS1 and IIS2 virtual machines at the same time, so website will still be up with latest data and code if one VM is down for updates?
An availability set combines two concepts from the Windows Azure PaaS world - upgrade domains and fault domains - that help to make a service more robust. When several VMs are deployed into an availability set the Windows Azure fabric controller will distribute them among several upgrade domains and fault domains.
A fault domain represents a grouping of VMs which have a single point of failure - a convenient (although not precisely accurate) way to think about it is a rack with a single top or rack router. By deploying the VMs into different fault domains the fabric controller ensures that a single failure will not take the entire service offline.
The fabric controller uses upgrade domains to control the manner in which host OS upgrades (i.e., of the underlying physical server) are performed. The fabric controller performs these upgrades one upgrade domain at a time, only moving onto the next upgrade domain when the upgrade of the preceding upgrade domain has completed. Doing this ensures that the service remains available, although with reduced capacity, during a host OS upgrade. These upgrades appear to happen every month or two, and services in which all VMs are deployed into availability sets receive no warning since they are supposedly resilient towards the upgrade. Microsoft does provide warning about upgrades to subscriptions containing VMs deployed outside availability sets.
Furthermore, there is no SLA for services which have VMs deployed outside availability sets.
As regards SQL Server, you may want to look into the use of SQL Server Availability Groups which sit on top of Windows Server Failover Cluster and use synchronous replication of the data. For IIS, you may want to look at the possibility of deploying your application into a PaaS cloud service since that provides significant advantages over deploying it into an IaaS cloud service. You can create a service topology integrating PaaS and IaaS cloud services through the use of a VNET.
Availability set is combination of these two feature
Fault Domain(you have option to select max 3 when creating new Availability Set)
Update Domains (you have option to select max 20 when creating new Availability Set)
Fault Domain is the physical(like rack, power) set lets you selected 2 fault domain in your availability set and your machine in that availability set will have value 1 and 2 so at least one can be available in case of power failure at any physical set.
Update Domain is set which will be updated by azure system update at once.
if select 4 update domains and your 2 VM have value 2,3 that means they will not be updated together for any planed maintenance
For high availability duplicate VM should not be on same Fault Domain or same Update Domain
Now You can not change availability set after creation of a VM it should be set at the time of creation