I'm new to Azure and am working on some basics that I can't find any consistent information on at the Microsoft Azure site.
My understanding is that the use of Affinity Groups makes sure your virtual resources are very close to each other. So I created an affinity group for West-US. Then I created a cloud service which I'm going to use for my AD controllers. I assigned my affinity group to it. When I created my VM and selected my ad cloud service, I could not select the local network I had created. I could only place a VM in my local network only if a region was assigned during the creation of a cloud service as opposed to using an affinity group.
Can someone please shed some light on the practical use of when and where I create affinity groups, if at all?
Thank you.
Affinity groups were historically a way to ensure proximity between Azure compute and Azure Storage. Until about three months ago a VNET also had to be created in an affinity group. One of the problems with this is that an affinity group is tied to physical hardware in a datacenter so that when new hardware came along (such as high-memory SKUs) a cloud service or VNET hosted in an existing affinity group could not get access to it. This led to some frustration.
Any VNET created now should be a regional VNET NOT an affinity-group VNET - i.e., one hosted in a region not an affinity group. In fact, you can only do the former in the Azure portal. I suspect that much of the motivation for using an affinity group disappeared when Azure migrated to a flat high-speed network a couple of years ago.
I recently blogged a more extended discussion of affinity groups.
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
Today I am noticing that the Azure Group, I dont know when Azure created the
"DefaultResourceGroup-EAU" resource group, and in this group two item is placed
I am not using any Azure Container Registry service and AKS, should I remove this group because it paying in my invoice, I just only have Azure Web Apps and Azure SQL databases and one VM only, should its impact on my above mentioned services after deletion?
certainly not in terms of how those services function, but monitoring might be impaired if you delete those.
Those resources look like they were created alongside AKS cluster. Doesn't mean that they were only being used for that, but highly likely.
I have been tasked with building a PoC in Azure to "simulate" a future global deployment where data transfer time is important factor. The actual deployment will be using fully on-prem resources. So, as odd as it sounds, I am looking for the worse performance possible between the two options.
Architecture A (single tenant):
Create a single Azure tenant in the US region
Create a Resource Group with a US-based location
Create another Resource Group with an EU-based location
Architecture B (dual tenant):
Create an Azure tenant in the US region with a US-based RG
Create an entirely separate Azure tenant in an EU region with a EU-based RG
Would the dual-tenant structure above make any measurable difference one way or the other from the single-tenant (assuming all vNetwork, VMs, etc are identical)? I am thinking the single-tenant setup would be faster since (presumably) the traffic never leaves the Azure Service Fabric. But that's just speculation.
Here is what I got back from a colleague. She is (obviously) far more versed in Azure IaaS than I am. Answer #3 below indicates that the closest analog to the client MPLS connection is via VPN/ER. Not really worth the cost but still good to know.
Can a single subscription be used to provision US and European region located resources? Yes
Can resources in US and European located regions be managed from a US based portal? Yes
When allowing resources in US and European located regions communicate with one another what are our options? A couple primary ways...
Intra-regional (tenant to tenant:region to region)
Communications can be provisioned to travel across the Microsoft Azure
backbone. It never hits the open Internet.
VPN or Express Route:
Travels either the open internet or a private in TLS like route from
one region to another. However express route, the mpls like option,
does require advanced routing (BGP) and dedicated circuits at I other
point from different connectivity providers. Also, expensive.
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.
I don't understand why some Azure resources can be aligned with an Affinity Group, but others can't.
Example: I just tried creating a Service Bus namespace. I'd like to align it with an existing affinity group, but I'm only able to select a region. I had the same issue trying to create a SQL Database server.
This is most likely a misunderstanding of exactly how Affinity Groups work on my part, but I don't understand the inconsistency.
What am I missing something here? Can someone please explain the reasoning behind not being able to align a Service Bus namespace with an Affinity Group?
It's not exactly a technical reason. It has to do with how Microsoft was internally aligned back when the platform called Windows Azure started. You have to remember that different teams created the Service Bus (used to be Biztalk Services), SQL Database (used to be SQL Azure, SQL Server Data Services, etc.), and Windows Azure (used to be Red Dog). Each service was created independently and in fact didn't even rely on the other (in the beginning at least).
I can't even recall now the myriad of different brandings and platforms that were there - it doesn't matter anymore. The reality is that there are still different teams that build those products and they don't always align at first. SQL Database used to be deployed into different clusters (not sure if that is true anymore) so affinity groups were not relevant. Same with Service Bus. For now, just remember that Affinity Groups only apply to Windows Azure compute and storage. Over time, I would expect a more cohesive experience (like the portal). However, some concepts are still rooted to where the team that built them resides.