I know that Azure Resource group must be created with a location, because that is where the metadata for that RG will reside.
Our application currently has a resource group in a location (eg : East US) that contain resources located in multiple regions. (eg : East US and Central US).
What happens to my Central US resources if East US goes down?
To be more specific :
Does the availability of the region hosting the RG itself affect the availability of the resources in another Region? (My guess in the example above is that the resources in Central US should still be running ok).
In the example above, is it still possible to manage the Central US resources if the location hosting the RG (East US) is down? This one is much less clear.
no, the availability of the region Resource Group hosted in doesn't affect availability of the resources in it.
you can only read those resources, as Resource Group region is responsible for writes
you won't be able to use template deployments as well
in regions with zones all zones have to go down for writes to be not available.
reading: https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#resource-groups
Related
I see that azure Microsoft-hosted build agents are allocated in the same geography as the Azure DevOps organization. However, is there anyway to request for Microsoft hosted build agents to be allocated in a different region?
Our issue is, that our Azure DevOps organization is in region eastus2, where offices are in US, EU and AU. For test setups we get resources from azure on the go. ex. rabbitmq containers. Different offices maintain their own subscriptions and maintain different resource groups in the same regions closer to their offices.
Given that, we observe if a one in AU setup a pipeline to use a rabbitmq container it is allocated in the same region as the resource group, where Microsoft hosted agents in US, tests timeout.
But if we change the resource group to EU/US or the resource to EU/US, tests do not timeout. Given, each office prefers to have their resources in the same region as the office, is there any suggestion to overcome the issue?
As it is written here
Your hosted agents run in the same Azure geography as your organization. Each geography contains one or more regions. While your agent may run in the same region as your organization, it is not guaranteed to do so. To obtain the complete list of possible IP ranges for your agent, you must use the IP ranges from all of the regions that are contained in your geography. For example, if your organization is located in the United States geography, you must use the IP ranges for all of the regions in that geography.
This is not necessarily true that your organization is in the same region as your agents. They are in the same geography.
But answering you question this is not possible to request for agent for another region. So if you need that you need to consider self hosted agents on your won infrastracture. You can create several agent pools and handle them to support your need.
I have a VM in Azure in location Central US . I have some restore points (fullbackups).
Can i restore the VM to a different resourcegroup in West US and reconnect to it with RDP ?
this is for disaster recovery if there is an issue with the Azure location or VM .
Also how can we guarantee that any location wont have issues ?
Interesting question.
You want to restore a VM hosted on the Central US to the West US.
Let's look into the Public Docs.
You could use the Cross Region (secondary region) restore to
restore Azure VMs in the secondary region, which is an Azure
paired region.
You can restore all the Azure VMs for the selected recovery point if
the backup is done in the secondary region.
During the backup, snapshots aren't replicated to the secondary
region. Only the data stored in the vault is replicated. So secondary
region restores are only vault tier restores. The restore time for the
secondary region will be almost the same as the vault tier restore
time for the primary region.
This feature is available for the options below:
Create a VM
Restore Disks
Unfortunately, I don't see the Central US region pairs with the West US region. So for your question if you can select your specific regional pair, answer is no.
Some Azure services rely upon regional pairs, such as Azure's
redundant storage. These services don't allow you to create new
regional pairings. Similarly, because Azure controls planned
maintenance and recovery prioritization for regional pairs, you can't
define your own regional pairs to take advantage of these services.
However, you can create your own disaster recovery solution by
building services in any number of regions and leveraging Azure
services to pair them.
I hope above helped to answer your questions.
Can we use same subscription in different Azure region. I want to create different Virtual Networks in different region and design protocol to communicate these regions.
Regards
Abdul
Yes, you can easily use the same subscription to spin up resources in other regions in Azure.
What regions you can use depends on your subscription type though. If you use any of the Azure credit offers you will find that certain offers has limits on the regions they can activate resources in.
I would recommend that you simply test by making a resource group in Azure in the region you want to test with, then create a new Azure Virtual Network in that resource group (which will per default have the same region).
This shows you the regions available to you. Repeat for each region you want a network in.
If you wish to connect the Azure Virtual Networks in different regions with each other you can setup Azure Virtual Network Peering
A little side note.
Not all types of resources are available in all regions. I would recommend checking what regions are available in the Azure Region Map, then check the Offers by Region page to see if the product you want to use is available in your chosen region.
I have a cloud service and a storage account deployed using the classic resource manager in the East US region; there is also a classic backup vault in the West Europe region.
Due to high latency, I want to move all of these resources to the UK South region, which is the closest one to me and others using these services. I have created a new resource group in the UK South region, however, when I try to move my existing classic resources to the new resource group, it says:
Classic resources must be moved separately and aren't displayed below.
Reading the article it linked to, it says that to move classic resources when experiencing this limitation, I need to contact support to have this operation done manually.
I do not have a support plan and am hoping not to buy one for this single task. Is there any other way around this limitation?
I think that you can walk around it by:
1. Create a new blank cloud service in your new resource group in UK South region.
2. Modify the deployment process to deploy the code to the newly created cloud service.
I hope this helps.
As you mentioned that it is limited by Azure. The following is snippet from the official document.
When moving resources from one resource group to another resource group within the same subscription, the following restrictions apply:
Virtual networks (classic) cannot be moved.
Virtual machines (classic) must be moved with the cloud service.
Cloud service can only be moved when the move includes all its virtual machines.
Only one cloud service can be moved at a time.
Only one storage account (classic) can be moved at a time.
Storage account (classic) cannot be moved in the same operation with a virtual machine or a cloud service.
As Toan nguyen mentioned that we need to redeploy it if you don't want to call Azure Support.
I'm new to Azure architecture and am trying to understand why Azure Resource Groups, which are logical deployment buckets for applications built on Azure, are associated with a region when they are defined.
At first I thought it was to provide global distribution for disaster recovery or geographic redundancy, but then I realized that a single Resource Group can contain web apps in different regions, which can provide those features via Traffic Manager. I suppose that using separate Resource Groups would help better identify which resources are in which region, but other than for organizational purposes, I can't understand what the region definition for Resource Groups implies.
(edit: removed general advice query to be more focused)
The main reason for specifying the location of a resource group is to specify a location for data/metadata for the deployment to be stored in... It also makes the API consistent (think of the paths in REST API calls) but the primary reason is storage during deployment.
The location of the resources in the group is independent/not related to the location of the group itself.
When creating a resource group, you need to provide a location for that resource group. You may be wondering, "Why does a resource group need a location? And, if the resources can have different locations than the resource group, why does the resource group location matter at all?" The resource group stores metadata about the resources. Therefore, when you specify a location for the resource group, you are specifying where that metadata is stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview
The meta data (definition) of the Azure resource group needs to be stored somewhere. hence the location. However, resources inside a resource group are location independent and can be placed in a different region\location.
Do note that dependencies between resources can exist. A Virtual machine in West Europe obviously needs a storage account in West Europe as well, but a SQL database in the same resource group can exist in West US.
Resource groups are basically for you to decide which resources in your application you want to manage together and by manage I mean you want to deploy, manage, and monitor them as a group so at a high level you do not see them as separate components.
In general in a big ecosystem, Azure resource groups are the ones that you do not see those components(resources) in them as separate entities, instead you see them as related and interdependent parts of a single entity so you put them in one Resource Group so that using the Azure Resource Group Manager tool You can deploy, update or delete all of the resources for your application in a single, coordinated operation.
You use a template for deployment and that template can work for different environments such as testing, staging and production. You can clarify billing for your organization by viewing the rolled-up costs for the entire group.
You can find more details on Azure Resource Manager here which I believe will help you better understand the idea behind the Azure Resource Groups:
https://azure.microsoft.com/en-us/documentation/articles/resource-group-overview/
Everything in Azure relates to a physical location/Datacenter, and ARM is no different. A little while ago, not every Datacenter supported ARM, so the reason for choosing made even more sense. Now, like any other Azure resource, the decision is for the user to make, often based on their required proximity to the end user and/or legal geographic requirements.
It appears there is no obvious way to determine what region a resource group is in after it has been created. This has caused me grief per the discussion here, when I ran into problems with CDN metadata conflicts. I had to start over. Now I name my resource groups with the region. e.g.: my-resourcegroup-westus