I have many resources (App Services, SRV, VMs, Storage, LB, analytics, etc) in Azure and I'm looking to have them in availability zone. But I'm considering limitations.
So far, I have discovered that not all VM sizes are supported and not all regions are supported.
Are there other limitations, even those that are yet to be documented?
About the limit of the Azure Availablility Zone, you can have a look of this doc:
https://learn.microsoft.com/en-us/azure/availability-zones/az-overview#services-support-by-region
Only specfic combinations of Azure services and regions support Availability Zones.
For each service that supports Availability Zones, there are some things to note:
1, For virtual machines, pay attention to whether the virtual machine size is available in the area you need.
2, For virtual machine scale set, you need to be aware that when you deploy a scale set into one or more zones, you have the option to deploy with "max spreading" or "static 5 fault domain spreading". With max spreading, the scale set spreads your VMs across as many fault domains as possible within each zone. This spreading could be across greater or fewer than five fault domains per zone. With "static 5 fault domain spreading", the scale set spreads your VMs across exactly five fault domains per zone. If the scale set cannot find five distinct fault domains per zone to satisfy the allocation request, the request fails.
3, For databases, Zone redundant databases and elastic pools are currently only supported in the Premium and Business Critical service tiers in select regions. When using the Business Critical tier, zone redundant configuration is only available when the Gen5 compute hardware is selected. And This feature is not available in Managed instance.
4, For Azure Event hub, geographic disaster recovery related to Availability Zones is only available for the standard and dedicated SKUs.
5, For Azure Service Bus, this feature is available for Service Bus Premium SKUs and only ensures that metadata (queues, topics, subscriptions, filters) is copied from the primary namespace to the secondary namespace during disaster recovery when pairing.
Related
The scenario is as follows:
In company premise, there is a network that consists few machines.
The company has an Azure subscription.
Requirement:
To monitor the company's Network/Machines via Azure
If the company resource goes beyond a threshold limit then trigger alerts. Example, network bandwidth consumption, machine CPU/Memory usage, etc.
When such alerts occur then spin up new virtual machines or VM scale sets in Azure to handle the load.
The purpose is if the machines in on-prem goes above threshold limit then automatically provision VMs in Azure, as there are only few on-prem machines.
Please guide how to implement these use cases?
your question is a little confusing. You mention machines on premises and using Azure to monitor them. You can monitor on premises VMs using Azure but then you mention provisioning new Azure VMs via Scale Sets.
I'm not 100% where your workload is but assuming it is in Azure then if you are using VM Scale Sets it's very easy to scale in and out based on resource utilisation.
This can be configured as described here: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-autoscale-portal
I am studying about microsoft Azure. Not able to understand difference between availability zones and regions.
Actually azure has the doc to describe the details about what's Availability Zones.
Firstly check: What are Availability Zones in Azure?
Availability Zones is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.
In another doc explains what's regions.
A region is a set of datacenters deployed within a latency-defined
perimeter and connected through a dedicated regional low-latency
network.
Availability Zones are part of regions.
Availability Zones are physically separate locations within an Azure region.
Azure Availability zone
An availability zone is one or more data centers that are independent of another (power, water, natural disasters). An availability zone could have 1, 2, 3, or a million data centers. Usually, 3 is a good number: since data can be replicated to the other 2 in case of failure, you still have more than one data center operating. But you can see Availability zones with any number of data centers. The more data centers, the more resilient against shutdowns. What it can be a little bit confusing, is that an availability zone is not a physical location per se as a datacenter, but a latency-defined perimeter.
Azure Region
Now scale that up. Imagine those datacenter are connected directly from one to the other, by low latency connections. AKA: private cable network.
Each Azure region features datacenters deployed within a latency-defined perimeter. They're connected through a dedicated regional low-latency network. This design ensures that Azure services within any region offer the best possible performance and security.
Look at this graph:
Now, a region that has more availability zones, is more resilient than one with fewer availability zones.
Azure Geography
It is an area with one or more Azure Regions—for example, India, the United States, United Kingdom.
Availability Zones are not available in all regions in Azure yet.
So, in the absence of this feature what are some HA alternatives adopted by customers ?
usually its combination of built-in geo redundancy with the one you implement on your own (say, Azure SQL replication + VMs in 2 regions) and traffic manager\azure front door on top of that.
That's correct, not all regions have Availability Zones. For VM's, you can use Availability Sets to get pretty close to the SLA for AZ's.
You should not really use multiple regions as an high-availability option if your workload is latency-sensitive. Regions should be considered for DR.
I'm a little bit confused about when to use Azure Availability Set and when to use Azure Affinity Group.
Lets look at the key purpose of Availability set and Affinity Group briefly to begin with.
Availability Set: is predominately to provide High Availability for your deployment. Azure does this via Fault domains and Upgrade domains.
A fault domain: is basically a different hardware rack in the same datacenter. The solution will be deployed in two different hardware racks.
Upgrade domains: is exactly same like fault domains in function, but they support upgrades rather than failures. The Upgrade domain is a logical unit of instance separation that determines which instances in a particular service will be upgraded at a point in time.
Affinity Group: In order to explain it, we need to take peek into Azure DC . Windows Azure Data Centers are purpose build , you might see rows and rows of containers (something like shipping containers) that contain clusters and racks. Each of those Containers have specific services, for example, Compute and Storage, SQL Azure, Service Bus, Access Control Service, and so on. Those containers are spread across the data center.
When you deploy a service using Portal or PowerShell , the service will talk directly to RDFE (Red Dog Front End). The RDFE controls the DC and nodes. The Cluster of nodes is controlled by Fabric Controller.. When you specify Affinity Group , the Fabric controller will place all the required elements of a deployment together. This has number of advantages like reducing latency (since required elements are close together) , Networking.
There are new changes brought in related to Network Affinity group , you can refer them (https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-migrate-to-regional-vnet/).
To address you question
You would use Availability set when you want to have Highly Available system and also want to have SLA for Compute. Without Availability set there wont be SLA for your VM or PaaS Instances in other words will single instances of VM (IaaS) and PaaS wont have SLA and prone to downtime during HW failure and Upgrades of OS.
Availability set can be implemented after the deployment as well. Do note there is cost associated with the Availability set , since you are running additional instances , so they will be charged.
Affinity group you need to include them at the time of Creation of the services . It cannot be updated after the creation. So it very important to include Affinity group at the time of creation. There is no additional charges for including Affinity group.
Do share your feedback if the response addresses your question.
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/