Just wondering what happens when an Azyre region goes down? It states in the documentation
If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them. For more information about building reliable applications, see Designing reliable Azure applications.
This to me reads that all resources in that region are in a read only mode meaning we can't modify the resource however we can still for exaple write to app insights?
However, if I have a resource group situated in EUN and it contains resources for multiple regions (EUN and EUW) what happens to the resources in this resource group?
I know its not correct to bundle multiple resources in a single resource group but its hangover from work done previously
Your example is correct. In such a scenario a resource in the online region can't be modified but will continue to function.
If you have a resource group in a region and that resource group contains resources from another region those resources will be online but you will not be able to update them.
For example, you have a resource group in West US 2 and it contains 2 Function Apps, one in West US 2 and one in East US. The Function in West US 2 will be offline because the region is offline. The Function in East US will be available but you will be unable to update it.
Related
This is probably an elemental question, but why would you want to ensure that resources are deployed to the same locations as their resource groups? I'm getting out of compliance issues with HIPPA and from CloudSploit about this and I'd like to get some more details around it as I know it deals with meta data but I'm not crystal clear.
Thanks in advance
Resources within a resource group need not always be deployed in the same location as the resource group. But there is a built-in Azure Policy available to audit this condition that one may choose to enable.
The resource group location serves two purposes:
First: The resource group stores metadata about the resources. When you specify a location for the resource group, you're specifying where that metadata is stored. Now, for compliance reasons, you may need to ensure that your data is stored within a particular region.
Second: If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them.
For knowing more about the factors to consider while defining your resrouce groups, check the Azure Resource Manager documentation.
I have created one Azure Function App in an existing Azure Resource Group. While creating a Function App, by mistake I didn't notice the selected region, and it got created in "South Central US" region. After a significant development, I realized this mistake, and now want to move it to "West Europe" region, so it gets aligned with rest of my resources.
Any idea of how I can move a resource from one region to other region, without deleting and recreating?
There is still no way to change your deployment from one region to the other. You'll have to create another Azure Function in that correct region and redeploy your application.
Troy Hunt outlines his journey with an Azure Website here but the same steps still apply.
still, I don't see any new option (We can move resources from one resource group/ subscription level).
I think as of now 3 options available
Create a resource in the new region then delete existing resource.
Deploy new resource with the same configuration using PowerShell/CLI.
Deploy through portal (Export Template > Deploy > Select New region > change parameters then Purchase) similar to option 2, but you don't need to write any script.
Ultimately all three options would create a new resource and you need to update access key in the dependent services. I think option 2 is a good choice for a production workload.
I have an interesting issue in Azure where somehow I've had some resources assign themselves to "Default-Web-NorthEurope" and some to "Default-Web-northeurope". (Note capitalisation)
Lets say I have Website1 and Website2. I'd like both of these to belong to the same App Service Plan. If I create a new one for "Website1" named "WebsitesServicePlan" The UI won't show me that plan when trying to change the plan for "Website2".
Has anyone else come across this issue and have any idea of a solution?
First of all, Azure Resource Group naming is not case sensitive. So I've no idea how you created two resource groups with the name Default-Web-NorthEurope and Default-Web-northeurope successfully. I suggest you double check the names in the portal.
Assume that the Default-Web-NorthEurope and Default-Web-northeurope are different groups and as you descriped Website1 is in Default-Web-NorthEurope, Website2 in Default-Web-northeurope, UI will definitely not show you the App Service Plan you created for "Websites1" when trying to change the plan for "Website2". Because both apps and plans are contained in a resource group. Apps can be moved between plans as long as the plans are in the same resource group and geographical region. In other words, when you want to change plans for app, the plans must be in the same resource group and geographical region.
Check azure-web-sites-web-hosting-plans-in-depth-overview for details.
I would like to keep each VM in separate resource group for ease for lifecycle management. I have a cluster containing n VLMs.
So I create one resource group for common things like public IP, load balancer and put availabilitySet declaration into it because is also must be shared between VMs.
Then I create VM in separate resource group and reference to availabilitySet with
"availabilitySet": {
"id": "[resourceId('Microsoft.Compute/availabilitySets',variables('availabilitySetName'))]"
},
Of cause 'availabilitySetName' is defined.
When I deploy my template I get an error saying
{"error":{"code":"BadRequest","message":"Entity resourceGroupName in resource reference id /subscriptions/a719381f-1fa0-4b06-8e29-ad6ea7d3c90b/resourceGroups/TB_PIP_OPSRV_UAT/providers/Microsoft.Compute/availabilitySets/tb_avlbs_opsrv_uat is invalid."}}
I double checked that resource and availability set name are specified correctly.
Does it mean that I can't put a set in separate resource group from VM?
Unfortunately, having a VM use an availabilitySet in a different resource group is not supported :(.
First of all, let me ask you why you want different resource groups? I strongly believe that you're overthinking it with multiple resource groups. A resource group is basically your "Entire System" and within the boundaries of one solution, you should only have one resource group for production, one for beta/staging etc, but never mix.
If you're selling SaaS to your customers it would make sense to have one resource group for each of your customers.
And as you know, a Resource group is simply a way for you to link together and manage all of the assets in your solution; vm's, storage, databases etc under one common name. I am very doubtful as to why one would want to consider multiple resource groups in a single solution, however, I am always willing to learn :)
Availability groups
Now, Availability groups are a different thing. This has to do with "Update Domains" and "Fault Domains" for your VM instances. Because Azure does not keep 3 separate VM's for you, as it does with most of it's PaaS services, you have to manage these yourself to ensure full uptime. Basically, when you're adding two or more VM's in an Availability Set, you're ensured that planned or unplanned events, at least one of the VM's will be available to meet the SLA.
Trying to combine the two in an effort of preventing downtime may sound like a good idea, but it is not solving any problems that I'm aware of. Like the old saying goes: if it aint broke, don't fix it :)
I understand that resources from different locations can all reside within one resource group. But when creating a new Resource Group, what is the purpose of choosing a location? Does it have any meaning?
Thanks
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
Actually it does matter:
Azure Resource Manager overview:
If the resource group's region is temporarily unavailable, you can't update resources in the resource group because the metadata is unavailable. The resources in other regions will still function as expected, but you can't update them.
For more information about building reliable applications, see Designing reliable Azure applications.
So we could imagine a situation where resource group is defined in LocationA, and all resources in that group are located in different region. When resource group region is unavailble then they may be issues when accessing metadata. Without metadata, it may not be able to failover.
Most templates in Azure ask you to specify a location(which is Azure Data Center Location) for each of the resources in a resource group.
Every resource is located in an Azure data center, but not every Azure data center supports every resource type.
Select any location that supports the resource type. You do not have to create all of the resources in a resource group in the same location;
However, whenever possible, you will want to create resources in the same location to optimize performance.
In particular, you will want to make sure that your database is in the same location as the app accessing it.
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